Re: [alsa-devel] [PATCH v10 08/13] regmap: add SLIMbus support
On Wed, Dec 13, 2017 at 04:06:11PM +, Mark Brown wrote: > > 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 code building if the Slimbus core isn't > enabled) so if you want you can go ahead and apply the main stuff and I > can apply the regmap change separately, it'll avoid Makefile/Kconfig > conflicts anyway. + Takashi FWIW, since this is another MIPI Audio specfic bus, would it make sense for this series to go thru sound/ tree? I have discussed with Takashi and Greg for soundwire and we are taking sound path. Would that be okay here too? Either ways I dont mind :) Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
On 12/13/2017 06:45 AM, Lorenzo Pieralisi wrote: +/* + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as + * occasionally getting stuck as 1. To avoid the potential for a hang, check + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART + * implementations, so only do so if an affected platform is detected in + * acpi_parse_spcr(). + */ +bool qdf2400_e44_present; +EXPORT_SYMBOL(qdf2400_e44_present); My eyes, this is horrible but it is not introduced by this patch. It would have been much better if: drivers/tty/serial/amba-pl011.c parsed the SPCR table (again) to detect it instead of relying on this horrible exported flag. I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c made the most sense. I agree the global variable is ugly. If you have a better idea, I'm all ears. If it's any consolation, this erratum affects only 1.x silicon, which is technically pre-production (although a lot of people have them). This work-around will eventually be reverted. diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 46505396869e..9ae98eeada76 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER endif config ACPI_SPCR_TABLE - bool + bool "ACPI Serial Port Console Redirection Support" + default y if ARM64 You need to remove the selection in arch/arm64 then. Also, moving away from a non-visible config may have consequences on ARM64, Graeme and Mark are more familiar with the SPCR dependencies so please chime in. I did raise this as a concern in the previous version of the patch. I also think it should not be a selectable option. Keeping the "select" does force SPCR to be enabled on ARM64 ACPI platforms, but if it's an option for x86, it should be an option for ARM. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cgroup, docs: document cgroup v2 device controller
On Wed, Dec 13, 2017 at 07:49:03PM +, Roman Gushchin wrote: > Add the corresponding section in cgroup v2 documentation. > > Signed-off-by: Roman Gushchin > Cc: Tejun Heo > Cc: Alexei Starovoitov > Cc: kernel-t...@fb.com > Cc: cgro...@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-ker...@vger.kernel.org Applied to cgroup/for-4.16. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cgroup, docs: document cgroup v2 device controller
Add the corresponding section in cgroup v2 documentation. Signed-off-by: Roman Gushchin Cc: Tejun Heo Cc: Alexei Starovoitov Cc: kernel-t...@fb.com Cc: cgro...@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- Documentation/cgroup-v2.txt | 33 + 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index 2cddab7efb20..d6efabb487e3 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -53,10 +53,11 @@ v1 is available under Documentation/cgroup-v1/. 5-3-2. Writeback 5-4. PID 5-4-1. PID Interface Files - 5-5. RDMA - 5-5-1. RDMA Interface Files - 5-6. Misc - 5-6-1. perf_event + 5-5. Device + 5-6. RDMA + 5-6-1. RDMA Interface Files + 5-7. Misc + 5-7-1. perf_event 6. Namespace 6-1. Basics 6-2. The Root and Views @@ -1429,6 +1430,30 @@ through fork() or clone(). These will return -EAGAIN if the creation of a new process would cause a cgroup policy to be violated. +Device controller +- + +Device controller manages access to device files. It includes both +creation of new device files (using mknod), and access to the +existing device files. + +Cgroup v2 device controller has no interface files and is implemented +on top of cgroup BPF. To control access to device files, a user may +create bpf programs of the BPF_CGROUP_DEVICE type and attach them +to cgroups. On an attempt to access a device file, corresponding +BPF programs will be executed, and depending on the return value +the attempt will succeed or fail with -EPERM. + +A BPF_CGROUP_DEVICE program takes a pointer to the bpf_cgroup_dev_ctx +structure, which describes the device access attempt: access type +(mknod/read/write) and device (type, major and minor numbers). +If the program returns 0, the attempt fails with -EPERM, otherwise +it succeeds. + +An example of BPF_CGROUP_DEVICE program may be found in the kernel +source tree in the tools/testing/selftests/bpf/dev_cgroup.c file. + + RDMA -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] i3c: Add core I3C infrastructure
On Wed, Dec 13, 2017 at 05:20:43PM +0100, Boris Brezillon wrote: > Hi Greg, > > On Tue, 1 Aug 2017 19:13:27 -0700 > Greg Kroah-Hartman wrote: > > > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep > > > > > it > > > > > this way because master IPs are likely to implement advanced queuing > > > > > mechanism (allows one to queue new transfers even if the master is > > > > > already busy processing other requests), and serializing things at the > > > > > framework level will just prevent us from using this kind of > > > > > optimization. > > > > > > > > Unless you can prove otherwise, using a rw lock is almost always worse > > > > than just a mutex. > > > > > > Is it still true when it's taken in non-exclusive mode most of the > > > time, and the time you spend in the critical section is non-negligible? > > > > > > I won't pretend I know better than you do what is preferable, it's just > > > that the RW lock seemed appropriate to me for the situation I tried to > > > described here. > > > > Again, measure it. If you can't measure it, then don't use it. Use a > > simple lock instead. Seriously, don't make it more complex until you > > really have to. It sounds like you didn't measure it at all, which > > isn't good, please do so. > > > > I'm resurrecting this thread because I finally had the time to implement > message queuing in Cadence I3C master driver. So I did a test with 2 > I3C devices on the bus, and their drivers sending as much SDR messages > as they can in 10s. Here are the results: > > |mutex|rwsem| > --- > dev1 |19087|29532| > dev2 |19341|29118| > === > total |38428|58650| > msg/sec |~3843|~5865| > > > The results I'm obtaining here are not so surprising since all normal > transfers are taking the lock in read mode, so there's no contention. > I didn't measure the impact on performances when there's one > maintenance operation taking the lock in write mode and several normal > transfers waiting for this lock, but really, maintenance operations are > infrequent, and that's not where performance matters in our use case. > > I also did the same test with only one device doing transfers on the > bus, and this time the mutex wins, but there's not a huge difference. > > |mutex|rwsem| > --- > total |67116|66561| > msg/sec |~6712|~6656| > > Let me know if you want more information on the test procedure. Nice, thanks for testing, so it is a real win here, good! greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] i3c: Add core I3C infrastructure
Hi Greg, On Tue, 1 Aug 2017 19:13:27 -0700 Greg Kroah-Hartman wrote: > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep it > > > > this way because master IPs are likely to implement advanced queuing > > > > mechanism (allows one to queue new transfers even if the master is > > > > already busy processing other requests), and serializing things at the > > > > framework level will just prevent us from using this kind of > > > > optimization. > > > > > > Unless you can prove otherwise, using a rw lock is almost always worse > > > than just a mutex. > > > > Is it still true when it's taken in non-exclusive mode most of the > > time, and the time you spend in the critical section is non-negligible? > > > > I won't pretend I know better than you do what is preferable, it's just > > that the RW lock seemed appropriate to me for the situation I tried to > > described here. > > Again, measure it. If you can't measure it, then don't use it. Use a > simple lock instead. Seriously, don't make it more complex until you > really have to. It sounds like you didn't measure it at all, which > isn't good, please do so. > I'm resurrecting this thread because I finally had the time to implement message queuing in Cadence I3C master driver. So I did a test with 2 I3C devices on the bus, and their drivers sending as much SDR messages as they can in 10s. Here are the results: |mutex|rwsem| --- dev1 |19087|29532| dev2 |19341|29118| === total |38428|58650| msg/sec |~3843|~5865| The results I'm obtaining here are not so surprising since all normal transfers are taking the lock in read mode, so there's no contention. I didn't measure the impact on performances when there's one maintenance operation taking the lock in write mode and several normal transfers waiting for this lock, but really, maintenance operations are infrequent, and that's not where performance matters in our use case. I also did the same test with only one device doing transfers on the bus, and this time the mutex wins, but there's not a huge difference. |mutex|rwsem| --- total |67116|66561| msg/sec |~6712|~6656| Let me know if you want more information on the test procedure. Regards, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 08/13] regmap: add SLIMbus support
> 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 code building if the Slimbus core isn't enabled) so if you want you can go ahead and apply the main stuff and I can apply the regmap change separately, it'll avoid Makefile/Kconfig conflicts anyway. signature.asc Description: PGP signature
Re: [PATCH] docs: ftrace-uses.rst fix varios code-block directives
On Tue, 12 Dec 2017 11:22:25 +0100 Markus Heiser wrote: > ftrace-uses.rst is not yet included into any toctree, but since it is > a .rst file, it is parsed by the Sphinx build. Thats, why we see some > WARNINGS: > > - trace/ftrace-uses.rst:53: WARNING: Definition list ends without a blank > line; unexpected unindent. > - trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without > end-string. > - trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without > end-strin > > Fixing the code-block directives results in a less noisy build, but the 'not > included' WARNING will be stay: > > - trace/ftrace-uses.rst: WARNING: document isn't included in any toctree > > Signed-off-by: Markus Heiser Acked-by: Steven Rostedt (VMware) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Documentation: Add Luis R. Rodriguez to list of enforcement statement endorsers
From: "Luis R. Rodriguez" Add my name to the list. Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 99a9135a965c..417cb975992f 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -145,6 +145,7 @@ we might work for today, have in the past, or will in the future. - Linus Torvalds - Thierry Reding - Rik van Riel + - Luis R. Rodriguez - Geert Uytterhoeven (Glider bvba) - Eduardo Valentin (Amazon.com) - Daniel Vetter -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Documentation: Add Kees Cook to list of enforcement statement endorsers
From: Kees Cook Add my name to the list. Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index bfa6a78103d8..99a9135a965c 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -68,6 +68,7 @@ we might work for today, have in the past, or will in the future. - Paul Burton - Javier Martinez Canillas - Rob Clark + - Kees Cook (Google) - Jonathan Corbet - Dennis Dalessandro - Vivien Didelot (Savoir-faire Linux) -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Documentation: Add myself to the enforcement statement list
From: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- Documentation/process/kernel-enforcement-statement.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst index 417cb975992f..6816c12d6956 100644 --- a/Documentation/process/kernel-enforcement-statement.rst +++ b/Documentation/process/kernel-enforcement-statement.rst @@ -138,6 +138,7 @@ we might work for today, have in the past, or will in the future. - Anna Schumaker - Jes Sorensen - K.Y. Srinivasan + - David Sterba (SUSE) - Heiko Stuebner - Jiri Kosina (SUSE) - Willy Tarreau -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Documentation: more names to the enforcement statement
Hi Jon, Here are 3 patches for the kernel-enforcement-statement file that came in after the file was originally added to the kernel tree. thanks, greg k-h David Sterba (1): Documentation: Add myself to the enforcement statement list Kees Cook (1): Documentation: Add Kees Cook to list of enforcement statement endorsers Luis R. Rodriguez (1): Documentation: Add Luis R. Rodriguez to list of enforcement statement endorsers Documentation/process/kernel-enforcement-statement.rst | 3 +++ 1 file changed, 3 insertions(+) -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
[+Mark, Graeme]
In $SUBJECT, s/avialable/available
On Mon, Dec 11, 2017 at 10:50:58AM -0500, Prarit Bhargava wrote:
> Other architectures can use SPCR to setup an early console or console
> but the current code is ARM64 specific.
I see nothing ARM64 specific in current code (apart from some
ACPICA macros with an ARM tag in them) please explain to me
what's preventing you to reuse current code on x86.
> Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
> function acpi_arch_setup_console() that can be used for arch-specific
> setup. Move flags into ACPI code. Update the Documention on the use of
> the SPCR.
>
> [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
> mmio value. Move baud rate check earlier.
This does not belong in the commit log.
> Signed-off-by: Prarit Bhargava
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux...@vger.kernel.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: Bhupesh Sharma
> Cc: Lv Zheng
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Jonathan Corbet
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: "Rafael J. Wysocki"
> Cc: Timur Tabi
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 +-
> arch/arm64/kernel/acpi.c| 128 -
> drivers/acpi/Kconfig| 7 +-
> drivers/acpi/spcr.c | 175
> ++--
> drivers/tty/serial/earlycon.c | 15 +-
> include/linux/acpi.h| 11 +-
> include/linux/serial_core.h | 2 -
> 7 files changed, 184 insertions(+), 160 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 6571fbfdb2a1..0d173289c67e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -914,9 +914,9 @@
>
> earlycon= [KNL] Output early console device and options.
>
> - When used with no options, the early console is
> - determined by the stdout-path property in device
> - tree's chosen node.
> + [ARM64] The early console is determined by the
> + stdout-path property in device tree's chosen node,
> + or determined by the ACPI SPCR table.
>
> cdns,[,options]
> Start an early, polled-mode console on a Cadence
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index b3162715ed78..b3e33bbdf3b7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
> return ret;
> }
>
> +/*
> + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> + * occasionally getting stuck as 1. To avoid the potential for a hang, check
> + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> + * implementations, so only do so if an affected platform is detected in
> + * acpi_parse_spcr().
> + */
> +bool qdf2400_e44_present;
> +EXPORT_SYMBOL(qdf2400_e44_present);
My eyes, this is horrible but it is not introduced by this patch. It
would have been much better if:
drivers/tty/serial/amba-pl011.c
parsed the SPCR table (again) to detect it instead of relying on this
horrible exported flag.
> +
> +/*
> + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> + * Detect them by examining the OEM fields in the SPCR header, similar to PCI
> + * quirk detection in pci_mcfg.c.
> + */
> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> +{
> + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> + return false;
> +
> + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> + return true;
> +
> + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> + h->oem_revision == 1)
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> + * register aligned to 32-bit. In addition, the BIOS also encoded the
> + * access width to be 8 bits. This function detects this errata condition.
> + */
> +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> +{
> + bool xgene_8250 = false;
> +
> + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> + return false;
> +
> + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> + memcmp(tb->header
Re: [PATCH v10 08/13] regmap: add SLIMbus support
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
Re: [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
On 2017/12/13 18:09, Suzuki K Poulose wrote: >> Reviewed-by: Dave Martin > > Looks good to me. > > Reviewed-by: Suzuki K Poulose Thanks a lot to Suzuki's review. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
On 13/12/17 10:13, Dongjiu Geng wrote: ARM v8.4 extensions add new neon instructions for performing a multiplication of each FP16 element of one vector with the corresponding FP16 element of a second vector, and to add or subtract this without an intermediate rounding to the corresponding FP32 element in a third vector. This patch detects this feature and let the userspace know about it via a HWCAP bit and MRS emulation. Cc: Dave Martin Cc: Suzuki K Poulose Signed-off-by: Dongjiu Geng Reviewed-by: Dave Martin Looks good to me. Reviewed-by: Suzuki K Poulose -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
[adding Lorenzo, Sudeep and Hanjun -- see Rafael's comment below]
On Wed, Dec 13, 2017 at 01:22:59AM +0100, Rafael J. Wysocki wrote:
> On Monday, December 11, 2017 4:50:58 PM CET Prarit Bhargava wrote:
> > Other architectures can use SPCR to setup an early console or console
> > but the current code is ARM64 specific.
> >
> > Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
> > function acpi_arch_setup_console() that can be used for arch-specific
> > setup. Move flags into ACPI code. Update the Documention on the use of
> > the SPCR.
> >
> > [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> > Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
> > mmio value. Move baud rate check earlier.
> >
> > Signed-off-by: Prarit Bhargava
>
> This mostly affects ARM64, so ACKs from that side are requisite for it.
>
> > Cc: linux-doc@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux...@vger.kernel.org
> > Cc: linux-a...@vger.kernel.org
> > Cc: linux-ser...@vger.kernel.org
> > Cc: Bhupesh Sharma
> > Cc: Lv Zheng
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: "H. Peter Anvin"
> > Cc: x...@kernel.org
> > Cc: Jonathan Corbet
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Cc: "Rafael J. Wysocki"
> > Cc: Timur Tabi
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 6 +-
> > arch/arm64/kernel/acpi.c| 128 -
> > drivers/acpi/Kconfig| 7 +-
> > drivers/acpi/spcr.c | 175
> > ++--
> > drivers/tty/serial/earlycon.c | 15 +-
> > include/linux/acpi.h| 11 +-
> > include/linux/serial_core.h | 2 -
> > 7 files changed, 184 insertions(+), 160 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 6571fbfdb2a1..0d173289c67e 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -914,9 +914,9 @@
> >
> > earlycon= [KNL] Output early console device and options.
> >
> > - When used with no options, the early console is
> > - determined by the stdout-path property in device
> > - tree's chosen node.
> > + [ARM64] The early console is determined by the
> > + stdout-path property in device tree's chosen node,
> > + or determined by the ACPI SPCR table.
> >
> > cdns,[,options]
> > Start an early, polled-mode console on a Cadence
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index b3162715ed78..b3e33bbdf3b7 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -25,7 +25,6 @@
> > #include
> > #include
> > #include
> > -#include
> >
> > #include
> > #include
> > @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
> > return ret;
> > }
> >
> > +/*
> > + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> > + * occasionally getting stuck as 1. To avoid the potential for a hang,
> > check
> > + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> > + * implementations, so only do so if an affected platform is detected in
> > + * acpi_parse_spcr().
> > + */
> > +bool qdf2400_e44_present;
> > +EXPORT_SYMBOL(qdf2400_e44_present);
> > +
> > +/*
> > + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY
> > bit.
> > + * Detect them by examining the OEM fields in the SPCR header, similar to
> > PCI
> > + * quirk detection in pci_mcfg.c.
> > + */
> > +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > +{
> > + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> > + return false;
> > +
> > + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > + return true;
> > +
> > + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > + h->oem_revision == 1)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +/*
> > + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> > + * register aligned to 32-bit. In addition, the BIOS also encoded the
> > + * access width to be 8 bits. This function detects this errata condition.
> > + */
> > +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > +{
> > + bool xgene_8250 = false;
> > +
> > + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> > + return false;
> > +
> > + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> > + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> > + return false;
> >
Re: [PATCH v10 08/13] regmap: add SLIMbus support
On Mon, Dec 11, 2017 at 11:43:02PM +, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch adds support to read/write SLIMbus value elements. > Currently it only supports byte read/write. Adding this support in > regmap would give codec drivers more flexibility when there are more > than 2 control interfaces like SLIMbus, i2c. > > Without this patch each codec driver has to directly call SLIMbus value > element apis, and this could would get messy once we want to add i2c > interface to it. > > Signed-off-by: Srinivas Kandagatla > --- > drivers/base/regmap/Kconfig | 4 ++ > drivers/base/regmap/Makefile | 1 + > drivers/base/regmap/regmap-slimbus.c | 80 > > include/linux/regmap.h | 18 > 4 files changed, 103 insertions(+) > create mode 100644 drivers/base/regmap/regmap-slimbus.c Mark, can I get an Ack for this patch so I can take it through my tree with the other patches in this series? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver
On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor Interface) alliance. > SLIMbus is a 2-wire implementation, which is used to communicate with > peripheral components like audio-codec. > SLIMbus uses Time-Division-Multiplexing to accommodate multiple data > channels, and control channel. Control channel has messages to do > device-enumeration, messages to send/receive control-data to/from > SLIMbus devices, messages for port/channel management, and messages to > do bandwidth allocation. > Framework is introduced to support multiple instances of the bus > (1 controller per bus), and multiple slave devices per controller. > SPI and I2C frameworks, and comments from last time when I submitted > the patches were referred-to while working on this framework. > > These patchsets introduce device-management, OF helpers, and messaging > APIs, controller driver for Qualcomm's SLIMbus controller, and > clock-pause feature for entering/exiting low-power mode for SLIMbus. > Framework patches to do channel, port and bandwidth > management are work-in-progress and will be sent out once these > initial patches are accepted. > > These patchsets were tested on IFC6410 board with Qualcomm APQ8064 > processor using the controller driver, and a WCD9310 codec. > > v9: https://lkml.org/lkml/2017/12/7/289 > > Changes from v9 to v10: > * Added kernel-doc reference into slimbus driver api doc suggested by > Jonathan Corbet These all look good to me. I can take this through my tree if I get the ack from Mark for the regmap changes. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
