On Sat, Oct 05, 2024 at 03:02:09PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > Ah, I see. I'd been under the impression that the generic machinery was
> > supposed to handle this already using the descriptions in
> > emulate-nested.c and we only needed handlers
On Sat, Oct 05, 2024 at 01:36:09PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > + // PSTATE.EXLOCK is set to 0 upon any exception to a higher
> > + // EL, or to GCSCR_ELx.EXLOCKEN for an exception to the same
> > + // exception level. See ARM DDI 0487 R
On Sat, Oct 05, 2024 at 02:18:57PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > On Sat, Oct 05, 2024 at 12:34:20PM +0100, Marc Zyngier wrote:
> > > Where is the handling of traps resulting of HFGITR_EL2.nGCSSTR_EL1?
> > These will trap with an EC of 0x2d wh
On Sat, Oct 05, 2024 at 12:34:20PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > + if (!kvm_has_gcs(kvm)) {
> > + kvm->arch.fgu[HFGxTR_GROUP] |= (HFGxTR_EL2_nGCS_EL0 |
> > + HFGxTR_EL2_nGCS_EL1);
>
GCS adds new registers GCSCR_EL1, GCSCRE0_EL1, GCSPR_EL1 and GCSPR_EL0. Add
these to those validated by get-reg-list.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 28 ++
1 file changed, 28 insertions
As per DDI 0487 RWTXBY we need to manage PSTATE.EXLOCK when entering an
exception, when the exception is entered from a lower EL the bit is cleared
while if entering from the same EL it is set to GCSCR_ELx.EXLOCKEN.
Implement this behaviour in enter_exception64().
Signed-off-by: Mark Brown
deliberately conservative choice to avoid errors due to oversights.
Further fields should be made writable in future.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/kvm_host.h | 12
arch/arm64/include/asm/vncr_mapping.h | 2 ++
arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
The initial EL2 setup for GCS did not include disabling of EL1 usage of
GCS instructions, also disable these traps. This is the first disabling
of instruction traps, use x2 to store the value to be written.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/el2_setup.h | 7 ++-
1 file
S1POE but removed S1PIE, meaning that the extension is no longer visible
to guests. Reenable support for S1PIE with VMM control.
Fixes: 70ed7238297f ("KVM: arm64: Sanitise ID_AA64MMFR3_EL1")
Signed-off-by: Mark Brown
---
arch/arm64/kvm/sys_regs.c | 4 +++-
1 file changed, 3 insertions(+),
h has also been sent separately as this
feature is a dependency for GCS. It is based on:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/gcs
Signed-off-by: Mark Brown
---
Changes in v14:
- Rebase onto arm64/for-next/gcs which includes all the non-KVM support.
- Manag
On Fri, Oct 04, 2024 at 02:18:45PM +0300, Catalin Marinas wrote:
> I think Szabolcs mentioned a GCS leak with v12:
> https://lore.kernel.org/r/ZtrihWQFyb2/x...@arm.com
> (and in some private messages IIRC)
> Has this been identified? The changelog only mentions a leak in v8.
Yes, it's this in
On Wed, Oct 02, 2024 at 08:29:28PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > They are, though really they should UNDEF if GCS isn't there (which I
> > had thought was what you were referencing here). Equally we only have
> > traps for a subset of GCS inst
On Wed, Oct 02, 2024 at 05:18:36PM -0600, Shuah Khan wrote:
> On 10/1/24 10:06, Deepak Gupta wrote:
> > +#ifndef __NR_prctl
> > +#define __NR_prctl 167
> > +#endif
> > +#ifndef __NR_map_shadow_stack
> > +#define __NR_map_shadow_stack 453
> Why do we need to define these? Shouldn't including
> as
On Wed, Oct 02, 2024 at 04:55:25PM +0100, Marc Zyngier wrote:
> Marc Zyngier wrote:
> > > + if (!kvm_has_gcs(kvm))
> > > + kvm->arch.fgu[HFGxTR_GROUP] |= (HFGxTR_EL2_nGCS_EL0 |
> > > + HFGxTR_EL2_nGCS_EL1);
> > Why are you still allowing the GCS in
-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 22 +++
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/mm/gcs.c| 79 ++
3 files changed, 102 insertions(+)
diff --git a/arch/arm64/include
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/mman.h | 9 +
arch/arm64/mm/mmap.c | 9 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
index 03b790fd0ad8..f6d784f8e6e0 100644
--- a/arch
Teach the framework about the GCS signal context, avoiding warnings on
the unknown context.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/signal/testcases/testcases.c | 7 +++
tools/testing/selftests/arm64/signal/testcases/testcases.h | 1
: Mark Brown
---
.../testing/selftests/arm64/signal/test_signals.h | 4 +++
.../selftests/arm64/signal/test_signals_utils.c| 29 ++
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/arm64/signal/test_signals.h
b/tools/testing
;t be interpreted as
a valid token or address.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 1 +
arch/arm64/kernel/signal.c | 118 +--
2 files changed, 114 insertions(+), 5 dele
it
attempts to do GCS operations outside a GCS.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/mm/fault.c | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64
sufficiently fast paths for this to be a problem.
Note that GCSSTTR is used to store to EL0.
Reviewed-by: Thiago Jung Bauermann
Acked-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 51
arch/arm64/include/asm/uaccess.h | 22
GCS adds new registers GCSCR_EL1, GCSCRE0_EL1, GCSPR_EL1 and GCSPR_EL0. Add
these to those validated by get-reg-list.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 28 ++
1 file changed, 28 insertions
they continue to work as before on systems without GCS.
Reviewed-by: Thiago Jung Bauermann
Tested-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/assembler.h | 15 +++
tools/testing/selftests/arm64/fp/fpsimd-test.S | 2 ++
tools/te
to not do that in the build system but there are no
such toolchains yet so it is not yet an issue.
Reviewed-by: Thiago Jung Bauermann
Tested-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/gcs/.gitignore| 1 +
tools/testing/selftests/arm64/gcs/Makefile
hiago Jung Bauermann
Reviewed-by: Catalin Marinas
Acked-by: Yury Khrustalev
Signed-off-by: Mark Brown
---
arch/arm64/mm/gcs.c | 64 +
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/mm/gcs.c b/arch/arm64/mm/gcs.c
index 61a80de6baf8..5c
Provide a hwcap to enable userspace to detect support for GCS.
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/elf_hwcaps.rst | 4
arch/arm64/include/asm/hwcap.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 3 +++
arch
are inserted when moving a GCS using task to another CPU. The test runs for
a configurable amount of time, defaulting to 10 seconds.
Reviewed-by: Thiago Jung Bauermann
Tested-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/gcs/.gitignore | 2 +
tools
Do some testing of the signal handling for GCS, checking that a GCS
frame has the expected information in it and that the expected signals
are delivered with invalid operations.
Reviewed-by: Thiago Jung Bauermann
Tested-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing
Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/gcs/.gitignore | 1 +
tools/testing/selftests/arm64/gcs/Makefile | 4 +-
tools/testing/selftests/arm64/gcs/gcs-util.h | 10 +
tools/testing/selftests/arm64/gcs/libc-gcs.c | 728 +++
4 files changed
This test program just covers the basic GCS ABI, covering aspects of the
ABI as standalone features without attempting to integrate things.
Reviewed-by: Thiago Jung Bauermann
Tested-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/Makefile| 2
anything with stacks that would cause problems with GCS we can sidestep
this issue by unconditionally enabling GCS on startup and exiting with a
call to exit() rather than a return from main().
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
.../testing/selftests/arm64/signal
-by: Mark Brown
---
arch/arm64/include/asm/pgtable-prot.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-prot.h
b/arch/arm64/include/asm/pgtable-prot.h
index 2a11d0c10760..4e4bcd676f4c 100644
--- a/arch/arm64/include/asm/pgtable
In preparation for testing GCS related signal handling add it as a feature
we check for in the signal handling support code.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/signal/test_signals.h | 2 ++
tools/testing/selftests/arm64/signal
Add coverage of the GCS hwcap to the hwcap selftest, using a read of
GCSPR_EL0 to generate SIGILL without having to worry about enabling GCS.
Reviewed-by: Thiago Jung Bauermann
Tested-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/abi/hwcap.c | 19
Provide a Kconfig option allowing the user to select if GCS support is
built into the kernel.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/Kconfig | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm64
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/uapi/asm/ptrace.h | 8 +
arch/arm64/kernel/ptrace.c | 62 +++-
include/uapi/linux/elf.h | 1 +
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a
, there is a conflict
between specifying GCSPR_EL0 and allocation of a new GCS and this is not
an ancticipated use case. We also enforce GCS configuration locking on
signal return.
Reviewed-by: Catalin Marinas
Reviewed-by: Thiago Jung Bauermann
Acked-by: Yury Khrustalev
Signed-off-by: Mark Brown
-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 9 +
arch/arm64/include/asm/mmu_context.h | 9 +
arch/arm64/kernel/process.c | 32 +
arch/arm64/mm/gcs.c | 69
4 files changed, 119 insertions
been disabled.
Reviewed-by: Catalin Marinas
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/gcs.h | 24 +++
arch/arm64/include/asm/processor.h | 6
arch/arm64/kernel/process.c| 62
ating any GCS
fault as fatal.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/esr.h | 28 +++-
arch/arm64/include/asm/exception.h | 2 ++
arch/arm64/kernel/entry-common.c
Hook up an override for GCS, allowing it to be disabled from the command
line by specifying arm64.nogcs in case there are problems.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Acked-by: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/admin-guide/kernel
deliberately conservative choice to avoid errors due to oversights.
Further fields should be made writable in future.
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/kvm_host.h | 12
arch/arm64/include/asm/vncr_mapping.h | 2 ++
arch/arm64
Use VM_HIGH_ARCH_5 for guarded control stack pages.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/filesystems/proc.rst | 2 +-
include/linux/mm.h | 12 +++-
2 files changed, 12 insertions(+), 2 deletions
Add a cpufeature for GCS, allowing other code to conditionally support it
at runtime.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/cpufeature.h | 6 ++
arch/arm64/kernel/cpufeature.c | 20
function call instructions without faulting regardless of the
state when the kernel is started.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/el2_setup.h | 30 ++
1 file changed, 30 insertions(+)
diff
In order for EL1 to write to an EL0 GCS it must use the GCSSTTR instruction
rather than a normal STTR. Provide a put_user_gcs() which does this.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/uaccess.h | 18
The architecture defines a format for guarded control stack caps, used
to mark the top of an unused GCS in order to limit the potential for
exploitation via stack switching. Add definitions associated with these.
Reviewed-by: Thiago Jung Bauermann
Acked-by: Catalin Marinas
Signed-off-by: Mark
: Catalin Marinas
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/booting.rst | 32
1 file changed, 32 insertions(+)
diff --git a/Documentation/arch/arm64/booting.rst
b/Documentation/arch/arm64/booting.rst
index b57776a68f15..aed6e9f47cf3 100644
--- a
Add some documentation of the userspace ABI for Guarded Control Stacks.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Acked-by: Yury Khrustalev
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/gcs.rst | 230 +
Documentation/arch
stack marker suitable for use by unwinders should be added
above that.
For arm64 the top of stack marker is all bits 0.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Acked-by: Yury Khrustalev
Signed-off-by: Mark Brown
---
arch/x86/include/uapi/asm/mman.h | 3 ---
include/uapi
locking interface reworked. The set status prctl()
is also reworked to just set flags, if setting/reading the shadow stack
pointer is required this could be a separate prctl.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Acked-by: Yury Khrustalev
Signed-off-by: Mark Brown
The addition of protection keys means that on arm64 we now use all of the
currently defined VM_HIGH_ARCH_x bits. In order to allow us to allocate a
new flag for GCS pages define VM_HIGH_ARCH_6.
Signed-off-by: Mark Brown
---
include/linux/mm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
.
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Catalin Marinas
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/mman.h | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
index 9e39217b4afb
Gupta
Reviewed-by: Rick Edgecombe
Reviewed-by: Mike Rapoport (IBM)
Reviewed-by: Catalin Marinas
Reviewed-by: Kees Cook
Tested-by: Kees Cook
Acked-by: Shuah Khan
Reviewed-by: Thiago Jung Bauermann
Signed-off-by: Mark Brown
---
arch/x86/Kconfig | 1 +
fs/proc/task_mmu.c | 2 +-
mm/Kconfig
-1-de...@rivosinc.com/
Signed-off-by: Mark Brown
---
Changes in v13:
- Rebase onto v6.12-rc1.
- Allocate VM_HIGH_ARCH_6 since protection keys used all the existing
bits.
- Implement mm_release() and free transparently allocated GCSs there.
- Use bit 32 of AT_HWCAP for GCS due to AT_HWCAP2 being f
On Tue, Oct 01, 2024 at 09:06:22AM -0700, Deepak Gupta wrote:
> From: Mark Brown
> This is based on a patch originally written by Deepak Gupta but later
> modified by Mark Brown for arm's GCS patch series.
>
> Signed-off-by: Mark Brown
> Co-developed-by: Deepak Gupta
On Thu, Sep 12, 2024 at 04:16:34PM -0700, Deepak Gupta wrote:
> This patch implements this syscall for riscv. riscv doesn't require token
> to be setup by kernel because user mode can do that by itself. However to
> provide compatibility and portability with other architectues, user mode
> can spe
b4 is now widely used and is quite helpful for a lot of the things that
submitting-patches covers, let's advertise it to submitters to try to make
their lives easier and reduce the number of procedural issues maintainers
see.
Reviewed-by: Shuah Khan
Signed-off-by: Mark Brown
---
Changes
On Wed, Sep 04, 2024 at 04:44:51AM +0200, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > +Tooling
> > +---
> > +Many of the technical aspects of this process can be automated using
> > +b4, documented at <https://b4.docs.kernel.org/en/latest/>. Th
b4 is now widely used and is quite helpful for a lot of the things that
submitting-patches covers, let's advertise it to submitters to try to make
their lives easier and reduce the number of procedural issues maintainers
see.
Signed-off-by: Mark Brown
---
Documentation/process/submi
b4 is now widely used and is quite helpful for a lot of the things that
submitting-patches covers, let's advertise it to submitters to try to make
their lives easier and reduce the number of procedural issues maintainers
see.
Signed-off-by: Mark Brown
---
Documentation/process/submi
b4 is now widely used and is quite helpful for a lot of the things that
submitting-patches covers, let's advertise it to submitters to try to make
their lives easier and reduce the number of procedural issues maintainers
see.
Signed-off-by: Mark Brown
---
Documentation/process/submi
On Sat, Jul 13, 2024 at 10:13:28AM +0200, Mauro Carvalho Chehab wrote:
> Jakub Kicinski escreveu:
> > I don't think so. If your boss comes to you and says "Dan, from now on
> > try not to reply to customers on the list, open a ticket first and only
> > reply once tickets is resolved". Is it more
ude discussions about security related issues.
Reviewed-by: Mark Brown
I do think it's fine for people to have open places like github as an
option as well, so long as they're optional for contributors and things
pass through the lists in a normal fashion at some point. Directing
peop
On Tue, Apr 23, 2024 at 05:30:49PM +0300, Jani Nikula wrote:
> The Cc's on the mailing list archive are harder to dig up, and do not
> accurately reflect the same information. A lot of patches get sent with
> more Cc's in the mail message than in the commit message.
These days with b4 and lore it
(dst_page + i);
>
> And it should be independent of architectural implementation
> differences.
>
> Let's provide guidance on coding style for requesting parameter
> evaluation or proposing the migration to a static inline
> function.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Mar 21, 2024 at 07:48:36AM +1300, Barry Song wrote:
> On Thu, Mar 21, 2024 at 4:49 AM Andrew Morton
> wrote:
> > Stronger than that please. Just tell people not to use macros in such
> > situations. Always code it in C.
> While I appreciate the consistency of always using "static inli
On Wed, Feb 14, 2024 at 03:46:12PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Mark Brown wrote:
> > There's an argument for many headphone volume related fixes too since
> > excessively large volumes can cause substantial distress and potential
> > injury to users
On Wed, Feb 14, 2024 at 02:43:48PM +0100, Jiri Kosina wrote:
> On Wed, 14 Feb 2024, Greg Kroah-Hartman wrote:
> > +No CVEs will be automatically assigned for unfixed security issues in
> > +the Linux kernel; assignment will only automatically happen after a fix
> > +is available and applied to a s
On Mon, Nov 20, 2023 at 12:01:09PM -0800, Jakub Kicinski wrote:
> +Emails saying just "ping" or "bump" are considered rude. If you can't figure
> +out the status of the patch from patchwork or where the discussion has
> +landed - describe your best guess and ask if it's correct. For example::
> +
On Tue, Oct 03, 2023 at 09:33:34AM -0600, Jonathan Corbet wrote:
> I was hoping to see some more comments on this; it is a fairly
> significant change in the expectations we put on our reviewers. Oh
> well, I've applied it. I wonder if we should add a note saying to look
> at the maintainer prof
While some subsystems do typically have very fast turnaround times on
review this is far from standard over the kernel and is likely to set
unrealistic expectations for submitters. Tell submitters to expect 2-3
weeks instead, this will cover more of the kernel.
Signed-off-by: Mark Brown
to spend time on this.
> For now I asked in the arm linux irc channel and got two people replying
> (both added to Cc:):
> Mark Brown (maintainer of SPI, regmap, ASoC and regulator) said:
> 1567019926 < broonie> ukleinek: I think that's a great idea and have
> t
On Tue, Aug 20, 2019 at 03:09:15PM +0100, John Garry wrote:
> On 19/08/2019 05:39, Vignesh Raghavendra wrote:
> > On 16/08/19 3:50 PM, John Garry wrote:
> > > About the child spi flash devices, is the recommendation to just use
> > > PRP0001 HID and "jedec,spi-nor" compatible?
> > I am not quite
d for the intended audience of the book.
> Mark Brown escreveu:
> > I don't know if it makes sense to have an embedded developer's
> > manual as well?
> Yeah, that's a good question.
> Jon is planning todo a documentation track at LPC. One of the things
> that
On Wed, Jul 31, 2019 at 05:26:13PM -0300, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > There were outstanding questions about where it was going to get moved
> > to but if I read the diff correctly it looks like it didn't actually get
> > moved in the end?
&
On Wed, Jul 31, 2019 at 02:17:34PM -0600, Jonathan Corbet wrote:
> Mauro Carvalho Chehab wrote:
> > As promised, this is the rebased version of the patches that were not
> > applied
> > from the /26 patch series because you had merge conflicts.
> >
> > They're all based on your docs-next branch
On Mon, Jul 22, 2019 at 10:10:35AM -0300, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > On Mon, Jul 22, 2019 at 08:07:31AM -0300, Mauro Carvalho Chehab wrote:
> > > While there's one file there with briefily describes the uAPI,
> > > the document
On Mon, Jul 22, 2019 at 08:07:31AM -0300, Mauro Carvalho Chehab wrote:
> While there's one file there with briefily describes the uAPI,
> the documentation was written just like most subsystems: focused
> on kernel developers. So, add it together with driver-api books.
Please use subject lines mat
On Wed, Jun 12, 2019 at 02:53:00PM -0300, Mauro Carvalho Chehab wrote:
> The conversion here is really trivial: just a bunch of title
> markups and very few puntual changes is enough to make it to
> be parsed by Sphinx and generate a nice html.
Acked-by: Mark Brown
signature.asc
De
Some new files got converted to yaml, but references weren't
updated accordingly.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mark Brown
---
Documentation/devicetree/bindings/media/st,stm32-dcmi.txt | 2 +-
Documentation/devicetree/bindings/sound/st,stm32-i2s.txt | 2 +-
Documentat
On Fri, Jun 07, 2019 at 03:54:33PM -0300, Mauro Carvalho Chehab wrote:
> Some new files got converted to yaml, but references weren't
> updated accordingly.
These should probably just be sent as normal patches rather than tied in
with the rest of this series...
signature.asc
Description: PGP sig
On Thu, Nov 15, 2018 at 01:57:31PM +0100, Boris Brezillon wrote:
> What we could do though, is expose I3C devices that do not have a
> driver in kernel space, like spidev does.
Yes, this is much safer and more robust especially if the bus has
enumeration requirements like you're saying it does.
On Wed, Dec 13, 2017 at 10:25:37AM +0100, Greg Kroah-Hartman wrote:
> Mark, can I get an Ack for this patch so I can take it through my tree
> with the other patches in this series?
I just gave a reviewed-by to the whole series. Might still make sense
for me to do this one patch, let me know if
ation, which is used to communicate with
> peripheral components like audio-codec.
Reviwed-by: Mark Brown
This all looks pretty good to me, I might've missed some stuff as this
is a fairly large series but I can't see there would be anything major
and re-reading it again definitely isn&
> On Mon, Dec 11, 2017 at 11:43:02PM +, srinivas.kandaga...@linaro.org
> wrote:
> Mark, can I get an Ack for this patch so I can take it through my tree
> with the other patches in this series?
I'm actually not seeing a direct dependency here (there's a depends in
place stopping the regmap c
On Wed, Dec 13, 2017 at 10:25:37AM +0100, Greg Kroah-Hartman wrote:
> Mark, can I get an Ack for this patch so I can take it through my tree
> with the other patches in this series?
Not until I've reviewed it (and the rest of the series).
signature.asc
Description: PGP signature
On Tue, Nov 28, 2017 at 05:22:02AM +0100, Jonathan Neuschäfer wrote:
> On Sun, Nov 19, 2017 at 06:09:06AM +0100, Jonathan Neuschäfer wrote:
> > Signed-off-by: Jonathan Neuschäfer
> > ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
>
> Ping.
>
> Should I resend this series with Cc:
.
Thanks,
Mark
>From c317fe585ca8244ac1768c7c8d29f14697995f8d Mon Sep 17 00:00:00 2001
From: Andrea Gelmini
Date: Sat, 21 May 2016 13:44:21 +0200
Subject: [PATCH] ASoC: dt: Fix typo
Signed-off-by: Andrea Gelmini
Signed-off-by: Mark Brown
---
Documentation/sound/alsa/soc/machine.txt | 2 +-
1 f
replying
to this mail.
Thanks,
Mark
>From 3208a1ccb23018c650ff9e08c4bd1c8b01f6d8f1 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven
Date: Tue, 10 May 2016 20:59:58 +0200
Subject: [PATCH] spi: dw-pci: Spelling s/paltforms/platforms/g
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Mark Br
On Mon, Apr 25, 2016 at 04:15:40PM +0200, Peter Rosin wrote:
> I've searched for a bit, and the best I can find is (IMHO)
> https://web.archive.org/web/20060702004954/http://www.semiconductors.philips.com/acrobat_download/various/I2SBUS.pdf
That looks best, length isn't an issue and they original
On Tue, Apr 19, 2016 at 12:11:28PM +0200, Peter Rosin wrote:
> +I2S
> +
> +LRC should have its flanks synchronized with a negative flank of BCLK.
> +The left channel word starts one BCLK cycle after a negative flank of LRC,
> and
Clock edges are normally referred to as such and have rising and f
On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote:
> Mark Brown wrote:
> >
> > There aren't any (beyond the usual references to the Wolfson datasheets
> > which I'd suggest should be in here) but that doesn't mean we should
> > ignore this sp
On Mon, Apr 18, 2016 at 12:55:23PM +, Peter Rosin wrote:
> Mark Brown wrote:
> > There is an actual spec for I2S which is going to be clearer than ASCII
> > art:
> >https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
> > is the first hit on
On Mon, Apr 18, 2016 at 11:39:50AM +0200, Peter Rosin wrote:
> +I2S
> + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-.
> +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-
There is an actual spec for I2S which is going to be clearer than ASCII
art:
On Thu, Apr 14, 2016 at 09:17:27PM +0200, Boris Brezillon wrote:
> The PWM framework has clarified the concept of reference PWM config
> (the platform dependent config retrieved from the DT or the PWM
> lookup table) and real PWM state.
Acked-by: Mark Brown
signature.asc
Descrip
On Tue, Apr 12, 2016 at 10:37:22AM +0200, Boris Brezillon wrote:
> Mark Brown wrote:
> > On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
> > I'm not sure there's a strong one, we don't really use the class device
> > for anything, but w
On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
> Is there any reason for calling set_machine_constraints() after
> device_register() in regulator_register()?
I'm not sure there's a strong one, we don't really use the class device
for anything, but without doing a full audit I co
gt; rounded the set_duty_cycle request.
> Moreover, this value is not valid until someone has modified the regulator
> output.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Wed, Mar 30, 2016 at 10:03:51PM +0200, Boris Brezillon wrote:
> pwm_config/enable/disable() have been deprecated in favor of
> pwm_apply_state().
> Replace all those calls with the equivalent pwm_get/apply_state().
Acked-by: Mark Brown
signature.asc
Description: PGP signature
1 - 100 of 101 matches
Mail list logo
