[PATCH v3 1/3] dt-bindings: usb: Update documentation for Qualcomm DWC3 driver

Existing documentation has lot of incorrect information as it was originally added for a driver that no longer exists. Signed-off-by: Manu Gautam --- .../devicetree/bindings/usb/qcom,dwc3.txt | 85 -- 1 file changed, 63 insertions(+), 22

[PATCH v3 1/3] dt-bindings: usb: Update documentation for Qualcomm DWC3 driver

Existing documentation has lot of incorrect information as it was originally added for a driver that no longer exists. Signed-off-by: Manu Gautam --- .../devicetree/bindings/usb/qcom,dwc3.txt | 85 -- 1 file changed, 63 insertions(+), 22 deletions(-) diff --git

[PATCH v3 0/3] usb: dwc3: support for Qualcomm DWC3 glue

Add separate dwc3-qcom glue driver for Qualcomm SOCs having dwc3 core. It is needed to support peripheral mode. Patches also add support to invoke PHY runtime PM functions on host mode bus-suspend. Changes since v2: - Addressed Rob's comments for DT binding documentation. Changes since v1: -

[PATCH v3 0/3] usb: dwc3: support for Qualcomm DWC3 glue

Add separate dwc3-qcom glue driver for Qualcomm SOCs having dwc3 core. It is needed to support peripheral mode. Patches also add support to invoke PHY runtime PM functions on host mode bus-suspend. Changes since v2: - Addressed Rob's comments for DT binding documentation. Changes since v1: -

Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote: > On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote: > > From: Anna-Maria Gleixner > > > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure > > the softirq context for

Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote: > On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote: > > From: Anna-Maria Gleixner > > > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure > > the softirq context for the subsequent

Re: [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver

Hi Mark, On Thu, Apr 26, 2018 at 4:29 PM, Mark Rutland wrote: > Hi, > > On Wed, Apr 25, 2018 at 02:30:47PM +0530, Ganapatrao Kulkarni wrote: >> + >> +/* L3c and DMC has 16 and 8 channels per socket respectively. >> + * Each Channel supports UNCORE PMU device and consists of

Re: [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver

Hi Mark, On Thu, Apr 26, 2018 at 4:29 PM, Mark Rutland wrote: > Hi, > > On Wed, Apr 25, 2018 at 02:30:47PM +0530, Ganapatrao Kulkarni wrote: >> + >> +/* L3c and DMC has 16 and 8 channels per socket respectively. >> + * Each Channel supports UNCORE PMU device and consists of >> + * 4 independent

Re: [PATCH] mtd: spi-nor: add support for Microchip 25LC256

On Fri, 4 May 2018 18:54:04 +0300 Radu Pirea wrote: > Added geometry description for Microchip 25LC256 memory. Same as for the dataflash stuff you posted a few weeks ago: I don't think this device belongs in the SPI NOR framework. > > Signed-off-by: Radu Pirea

Re: [PATCH] mtd: spi-nor: add support for Microchip 25LC256

On Fri, 4 May 2018 18:54:04 +0300 Radu Pirea wrote: > Added geometry description for Microchip 25LC256 memory. Same as for the dataflash stuff you posted a few weeks ago: I don't think this device belongs in the SPI NOR framework. > > Signed-off-by: Radu Pirea > --- >

Re: [PATCH] spi-nor: Add support for Atmel Dataflash memories

Hi Radu, Sorry for the late reply. On Wed, 28 Feb 2018 13:55:01 +0200 Radu Pirea wrote: > This patch add support in spi-nor for allmost all dataflash memories > supported by old mtd_dataflash driver. Those devices clearly use a different instruction set, so I don't

Re: [PATCH] spi-nor: Add support for Atmel Dataflash memories

Hi Radu, Sorry for the late reply. On Wed, 28 Feb 2018 13:55:01 +0200 Radu Pirea wrote: > This patch add support in spi-nor for allmost all dataflash memories > supported by old mtd_dataflash driver. Those devices clearly use a different instruction set, so I don't think they fit in this

Re: rcu-bh design

On Fri, May 4, 2018 at 10:42 AM Paul E. McKenney wrote: [...] > > > > But preemptible RCU *does not* use context-switch as a quiescent state. > > > It doesn't? > > > > I thought that's what preemptible rcu is about. You can get preempted but > > you shouldn't block in

Re: rcu-bh design

On Fri, May 4, 2018 at 10:42 AM Paul E. McKenney wrote: [...] > > > > But preemptible RCU *does not* use context-switch as a quiescent state. > > > It doesn't? > > > > I thought that's what preemptible rcu is about. You can get preempted but > > you shouldn't block in a read-section. Is that not

Re: [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

On Fri, May 4, 2018 at 6:53 PM, Pavel Tatashin wrote: >> I'm wondering, ain't simple enabling of config >> DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the >> case then it seems like this series is not needed at all, right? >> I am not sure why is

Re: [PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64

On Fri, May 4, 2018 at 6:53 PM, Pavel Tatashin wrote: >> I'm wondering, ain't simple enabling of config >> DEFERRED_STRUCT_PAGE_INIT provide even better speed-up? If that is the >> case then it seems like this series is not needed at all, right? >> I am not sure why is this config optional. It

Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote: > From: Anna-Maria Gleixner > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure > the softirq context for the subsequent netif_receive_skb() call. That's not in fact

Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote: > From: Anna-Maria Gleixner > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure > the softirq context for the subsequent netif_receive_skb() call. That's not in fact what it does though; so

RE: drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

Darren, Is this with that fix of mine merged? > -Original Message- > From: kbuild test robot [mailto:l...@intel.com] > Sent: Friday, May 4, 2018 1:24 PM > To: Limonciello, Mario > Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart (VMware) > Subject:

RE: drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

Darren, Is this with that fix of mine merged? > -Original Message- > From: kbuild test robot [mailto:l...@intel.com] > Sent: Friday, May 4, 2018 1:24 PM > To: Limonciello, Mario > Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart (VMware) > Subject:

Re: [PATCH] async_pq: Remove VLA usage

Hi Kyle, Thank you for the patch! Yet something to improve: [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH] async_pq: Remove VLA usage

Hi Kyle, Thank you for the patch! Yet something to improve: [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

Hi Mario, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 625e2001e99e82ea3eb5b0370a428a4328b9166b commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: Link all dell-smbios-* modules together

drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

Hi Mario, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 625e2001e99e82ea3eb5b0370a428a4328b9166b commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: Link all dell-smbios-* modules together

Re: [PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

On Fri, May 04, 2018 at 07:09:09PM +0100, Mark Rutland wrote: > On Fri, May 04, 2018 at 08:01:05PM +0200, Peter Zijlstra wrote: > > On Fri, May 04, 2018 at 06:39:32PM +0100, Mark Rutland wrote: > > > include/asm-generic/atomic-instrumented.h | 1195 > > > - > > > 1

Re: [PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

On Fri, May 04, 2018 at 07:09:09PM +0100, Mark Rutland wrote: > On Fri, May 04, 2018 at 08:01:05PM +0200, Peter Zijlstra wrote: > > On Fri, May 04, 2018 at 06:39:32PM +0100, Mark Rutland wrote: > > > include/asm-generic/atomic-instrumented.h | 1195 > > > - > > > 1

Re: [PATCH] IB/umem: use tgid instead of pid in ib_umem structure

On Fri, May 04, 2018 at 04:51:15PM +0800, 858585 jemmy wrote: > On Fri, May 4, 2018 at 11:14 AM, 858585 jemmy wrote: > > On Thu, May 3, 2018 at 11:33 PM, Jason Gunthorpe wrote: > >> On Thu, May 03, 2018 at 10:04:34PM +0800, Lidong Chen wrote: > >>> The

Re: [PATCH] IB/umem: use tgid instead of pid in ib_umem structure

On Fri, May 04, 2018 at 04:51:15PM +0800, 858585 jemmy wrote: > On Fri, May 4, 2018 at 11:14 AM, 858585 jemmy wrote: > > On Thu, May 3, 2018 at 11:33 PM, Jason Gunthorpe wrote: > >> On Thu, May 03, 2018 at 10:04:34PM +0800, Lidong Chen wrote: > >>> The userspace may invoke ibv_reg_mr and

Re: [PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

On Fri, May 04, 2018 at 08:01:05PM +0200, Peter Zijlstra wrote: > On Fri, May 04, 2018 at 06:39:32PM +0100, Mark Rutland wrote: > > Currently only instruments the fully > > ordered variants of atomic functions, ignoring the {relaxed,acquire,release} > > ordering variants. > > > > This patch

Re: [PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

On Fri, May 04, 2018 at 08:01:05PM +0200, Peter Zijlstra wrote: > On Fri, May 04, 2018 at 06:39:32PM +0100, Mark Rutland wrote: > > Currently only instruments the fully > > ordered variants of atomic functions, ignoring the {relaxed,acquire,release} > > ordering variants. > > > > This patch

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Thu, 3 May 2018 21:46:16 -0700 Jacob Pan wrote: > On Wed, 2 May 2018 10:31:50 +0100 > Jean-Philippe Brucker wrote: > > > On 01/05/18 23:58, Jacob Pan wrote: > > Maybe this should be called "NG_PAGE_PASID", > > >>>

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Thu, 3 May 2018 21:46:16 -0700 Jacob Pan wrote: > On Wed, 2 May 2018 10:31:50 +0100 > Jean-Philippe Brucker wrote: > > > On 01/05/18 23:58, Jacob Pan wrote: > > Maybe this should be called "NG_PAGE_PASID", > > >>> Sure. I was thinking page range already implies non-global > >

Re: [PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

On Fri, May 04, 2018 at 06:39:32PM +0100, Mark Rutland wrote: > Currently only instruments the fully > ordered variants of atomic functions, ignoring the {relaxed,acquire,release} > ordering variants. > > This patch reworks the header to instrument all ordering variants of the > atomic >

Re: [PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

On Fri, May 04, 2018 at 06:39:32PM +0100, Mark Rutland wrote: > Currently only instruments the fully > ordered variants of atomic functions, ignoring the {relaxed,acquire,release} > ordering variants. > > This patch reworks the header to instrument all ordering variants of the > atomic >

Hello

I have a business to discuss with you, can we talk? Regards Faruk Sakawo

Hello

I have a business to discuss with you, can we talk? Regards Faruk Sakawo

[PATCH] x86/vdso: remove unused file

commit da861e18eccc ("x86, vdso: Get rid of the fake section mechanism") left this file behind; nothing is using it anymore. Signed-off-by: Jann Horn --- arch/x86/entry/vdso/vdso32/vdso-fakesections.c | 1 - 1 file changed, 1 deletion(-) delete mode 100644

[PATCH] x86/vdso: remove unused file

commit da861e18eccc ("x86, vdso: Get rid of the fake section mechanism") left this file behind; nothing is using it anymore. Signed-off-by: Jann Horn --- arch/x86/entry/vdso/vdso32/vdso-fakesections.c | 1 - 1 file changed, 1 deletion(-) delete mode 100644

Re: [PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

* Sebastian Andrzej Siewior [180504 17:50]: > On 2018-05-04 10:39:31 [-0700], Tony Lindgren wrote: > > Uhh sorry I managed to commit also a patch I was testing while > > updating patch comments.. Will send out v3 shortly, this can be > > ignored. > > I assumed you were

Re: [PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

* Sebastian Andrzej Siewior [180504 17:50]: > On 2018-05-04 10:39:31 [-0700], Tony Lindgren wrote: > > Uhh sorry I managed to commit also a patch I was testing while > > updating patch comments.. Will send out v3 shortly, this can be > > ignored. > > I assumed you were helping out to sneak a

drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 625e2001e99e82ea3eb5b0370a428a4328b9166b commit: eb27fde2731b6cb5818493b8ac18e01f427e335f eeprom: at24: drop redundant variable in at24_read() date: 6 weeks ago config: x86_64-randconfig-g0-05042232

drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 625e2001e99e82ea3eb5b0370a428a4328b9166b commit: eb27fde2731b6cb5818493b8ac18e01f427e335f eeprom: at24: drop redundant variable in at24_read() date: 6 weeks ago config: x86_64-randconfig-g0-05042232

Re: [V5 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On 5/1/2018 12:33 PM, Jiri Olsa wrote: On Tue, May 01, 2018 at 07:31:36AM -0700, kan.li...@linux.intel.com wrote: From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e

Re: [V5 PATCH] perf parse-events: Specially handle uncore event alias in small groups

On 5/1/2018 12:33 PM, Jiri Olsa wrote: On Tue, May 01, 2018 at 07:31:36AM -0700, kan.li...@linux.intel.com wrote: From: Kan Liang Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a

[RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

From: Anna-Maria Gleixner The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure the softirq context for the subsequent netif_receive_skb() call. The check could be moved into the netif_receive_skb() function to prevent all calling functions implement

[RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

From: Anna-Maria Gleixner The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure the softirq context for the subsequent netif_receive_skb() call. The check could be moved into the netif_receive_skb() function to prevent all calling functions implement the checks on their own.

[RFC PATCH 1/2] lockdep: Add a assert_in_softirq()

From: Anna-Maria Gleixner Instead of directly warn on wrong context, check if softirq context is set. This check could be a nop on RT. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Sebastian Andrzej Siewior ---

[RFC PATCH 1/2] lockdep: Add a assert_in_softirq()

From: Anna-Maria Gleixner Instead of directly warn on wrong context, check if softirq context is set. This check could be a nop on RT. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Sebastian Andrzej Siewior --- include/linux/lockdep.h | 6 ++ 1 file changed, 6 insertions(+) diff

[PATCH] f2fs: avoid fsync() failure caused by EAGAIN in writepage()

pageout() in MM traslates EAGAIN, so calls handle_write_error() -> mapping_set_error() -> set_bit(AS_EIO, ...). file_write_and_wait_range() will see EIO error, which is critical to return value of fsync() followed by atomic_write failure to user. Signed-off-by: Jaegeuk Kim

[PATCH] f2fs: avoid fsync() failure caused by EAGAIN in writepage()

pageout() in MM traslates EAGAIN, so calls handle_write_error() -> mapping_set_error() -> set_bit(AS_EIO, ...). file_write_and_wait_range() will see EIO error, which is critical to return value of fsync() followed by atomic_write failure to user. Signed-off-by: Jaegeuk Kim --- fs/f2fs/data.c

[RFC PATCH 0/2] Introduce assert_in_softirq()

ieee80211_rx_napi() has a check to ensure that it is invoked in softirq context / with BH disabled. It is there because it invokes netif_receive_skb() which has this requirement. On -RT this check does not work as expected so there is always this warning. Tree wide there are two users of this

Re: [PATCH 2/4] phy: rockchip-typec: support variable phy config value

Hi Lin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on rockchip/for-next] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

[RFC PATCH 0/2] Introduce assert_in_softirq()

ieee80211_rx_napi() has a check to ensure that it is invoked in softirq context / with BH disabled. It is there because it invokes netif_receive_skb() which has this requirement. On -RT this check does not work as expected so there is always this warning. Tree wide there are two users of this

Re: [PATCH 2/4] phy: rockchip-typec: support variable phy config value

Hi Lin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on rockchip/for-next] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

On Fri, May 04, 2018 at 12:17:20PM -0500, Eric W. Biederman wrote: > Sebastian Andrzej Siewior writes: > > > On 2018-05-04 11:59:08 [-0500], Eric W. Biederman wrote: > >> Sebastian Andrzej Siewior writes: > >> > From: Anna-Maria Gleixner

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

On Fri, May 04, 2018 at 12:17:20PM -0500, Eric W. Biederman wrote: > Sebastian Andrzej Siewior writes: > > > On 2018-05-04 11:59:08 [-0500], Eric W. Biederman wrote: > >> Sebastian Andrzej Siewior writes: > >> > From: Anna-Maria Gleixner > > … > >> > This long-term fix has been made in commit

Re: [v3] [media] Use common error handling code in 19 functions

Em Fri, 4 May 2018 18:08:59 +0200 SF Markus Elfring escreveu: > > Adjust jump targets so that a bit of exception handling can be better > > reused at the end of these functions. > > Why was this update suggestion rejected once more a moment ago? > >

Re: [v3] [media] Use common error handling code in 19 functions

Em Fri, 4 May 2018 18:08:59 +0200 SF Markus Elfring escreveu: > > Adjust jump targets so that a bit of exception handling can be better > > reused at the end of these functions. > > Why was this update suggestion rejected once more a moment ago? > > https://patchwork.linuxtv.org/patch/47827/

RE: [External] Re: [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone

> On Fri, May 04, 2018 at 03:35:33PM +0200, Michal Hocko wrote: > > On Fri 04-05-18 14:52:08, Huaisheng Ye wrote: > > > Suggest using unsigned int instead of int for bit within gfp_zone. > > > @@ -401,7 +401,7 @@ static inline bool gfpflags_allow_blocking(const > gfp_t gfp_flags) > > > static

RE: [External] Re: [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone

> On Fri, May 04, 2018 at 03:35:33PM +0200, Michal Hocko wrote: > > On Fri 04-05-18 14:52:08, Huaisheng Ye wrote: > > > Suggest using unsigned int instead of int for bit within gfp_zone. > > > @@ -401,7 +401,7 @@ static inline bool gfpflags_allow_blocking(const > gfp_t gfp_flags) > > > static

Re: [v2] mm: access to uninitialized struct page

On Fri, May 4, 2018 at 7:03 PM, Pavel Tatashin wrote: > Thank you, I will try to figure out what is happening. +1 is here. The last message I have seen on the console are: [4.690972] Non-volatile memory driver v1.3 [4.703360] Linux agpgart interface v0.103 [

Re: [v2] mm: access to uninitialized struct page

On Fri, May 4, 2018 at 7:03 PM, Pavel Tatashin wrote: > Thank you, I will try to figure out what is happening. +1 is here. The last message I have seen on the console are: [4.690972] Non-volatile memory driver v1.3 [4.703360] Linux agpgart interface v0.103 [4.710282] loop: module

Re: [PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

On 2018-05-04 10:39:31 [-0700], Tony Lindgren wrote: > Uhh sorry I managed to commit also a patch I was testing while > updating patch comments.. Will send out v3 shortly, this can be > ignored. I assumed you were helping out to sneak a patch in. > Regards, > > Tony Sebastian

Re: [PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

On 2018-05-04 10:39:31 [-0700], Tony Lindgren wrote: > Uhh sorry I managed to commit also a patch I was testing while > updating patch comments.. Will send out v3 shortly, this can be > ignored. I assumed you were helping out to sneak a patch in. > Regards, > > Tony Sebastian

[PATCH v5 1/6] firmware: wrap FW_OPT_* into an enum

From: Andres Rodriguez This should let us associate enum kdoc to these values. While at it, kdocify the fw_opt. Signed-off-by: Andres Rodriguez Acked-by: Luis R. Rodriguez [mcgrof: coding style fixes, merge kdoc with enum move]

[PATCH v5 1/6] firmware: wrap FW_OPT_* into an enum

From: Andres Rodriguez This should let us associate enum kdoc to these values. While at it, kdocify the fw_opt. Signed-off-by: Andres Rodriguez Acked-by: Luis R. Rodriguez [mcgrof: coding style fixes, merge kdoc with enum move] Signed-off-by: Luis R. Rodriguez ---

Re: [PATCH v7 02/24] soc: qcom: Add APR bus driver

On Tue 01 May 05:07 PDT 2018, Srinivas Kandagatla wrote: > This patch adds support to APR bus (Asynchronous Packet Router) driver. > APR driver is made as a bus driver so that the apr devices can added removed > more dynamically depending on the state of the services on the dsp. > APR is used for

Re: [PATCH v7 02/24] soc: qcom: Add APR bus driver

On Tue 01 May 05:07 PDT 2018, Srinivas Kandagatla wrote: > This patch adds support to APR bus (Asynchronous Packet Router) driver. > APR driver is made as a bus driver so that the apr devices can added removed > more dynamically depending on the state of the services on the dsp. > APR is used for

[PATCH v5 3/6] firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()

From: Andres Rodriguez This is done since this call is now exposed through kernel-doc, and since this also paves the way for different future types of fallback mechanims. Signed-off-by: Andres Rodriguez Acked-by: Luis R. Rodriguez

[PATCH v5 3/6] firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()

From: Andres Rodriguez This is done since this call is now exposed through kernel-doc, and since this also paves the way for different future types of fallback mechanims. Signed-off-by: Andres Rodriguez Acked-by: Luis R. Rodriguez [mcgrof: small coding style changes] Signed-off-by: Luis R.

[PATCH v5 2/6] firmware: use () to terminate kernel-doc function names

From: Andres Rodriguez The kernel-doc spec dictates a function name ends in (). Signed-off-by: Andres Rodriguez Acked-by: Randy Dunlap Acked-by: Luis R. Rodriguez Signed-off-by: Luis R. Rodriguez

[PATCH v5 4/6] firmware_loader: document firmware_sysfs_fallback()

This also sets the expecations for future fallback interfaces, even if they are not exported. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_loader/fallback.c | 20 1 file changed, 20 insertions(+) diff --git

[PATCH v5 2/6] firmware: use () to terminate kernel-doc function names

From: Andres Rodriguez The kernel-doc spec dictates a function name ends in (). Signed-off-by: Andres Rodriguez Acked-by: Randy Dunlap Acked-by: Luis R. Rodriguez Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_loader/fallback.c | 8 drivers/base/firmware_loader/main.c

[PATCH v5 4/6] firmware_loader: document firmware_sysfs_fallback()

This also sets the expecations for future fallback interfaces, even if they are not exported. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_loader/fallback.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/base/firmware_loader/fallback.c

[PATCH v5 6/6] firmware_loader: move kconfig FW_LOADER entries to its own file

This will make it easier to track and easier to understand what components and features are part of the FW_LOADER. There are some components related to firmware which have *nothing* to do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD. Signed-off-by: Luis R. Rodriguez ---

[PATCH v5 6/6] firmware_loader: move kconfig FW_LOADER entries to its own file

This will make it easier to track and easier to understand what components and features are part of the FW_LOADER. There are some components related to firmware which have *nothing* to do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD. Signed-off-by: Luis R. Rodriguez ---

[PATCHv3] serial: 8250: omap: Fix idling of clocks for unused uarts

I noticed that unused UARTs won't necessarily idle properly always unless at least one byte tx transfer is done first. After some debugging I narrowed down the problem to the scr register dma configuration bits that need to be set before softreset for the clocks to idle. Unless we do this, the

[PATCHv3] serial: 8250: omap: Fix idling of clocks for unused uarts

I noticed that unused UARTs won't necessarily idle properly always unless at least one byte tx transfer is done first. After some debugging I narrowed down the problem to the scr register dma configuration bits that need to be set before softreset for the clocks to idle. Unless we do this, the

[PATCH v5 5/6] firmware_loader: enhance Kconfig documentation over FW_LOADER

If you try to read FW_LOADER today it speaks of old riddles and unless you have been following development closely you will loose track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD is a bit fuzzy and how it fits into this big picture. Give the FW_LOADER kconfig documentation

[PATCH v5 5/6] firmware_loader: enhance Kconfig documentation over FW_LOADER

If you try to read FW_LOADER today it speaks of old riddles and unless you have been following development closely you will loose track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD is a bit fuzzy and how it fits into this big picture. Give the FW_LOADER kconfig documentation

[PATCH v5 0/6] firmware_loader: cleanups for v4.18

folks. These patches are based on top of linux-next next-20180504, they are also available in a respective git branch, both for linux-next [1] and linux [2]. Question, and specially rants are greatly appreciated, and of course... may the 4th be with you. [0] https://github.com/teg/firmwared [1]

[PATCH v5 0/6] firmware_loader: cleanups for v4.18

folks. These patches are based on top of linux-next next-20180504, they are also available in a respective git branch, both for linux-next [1] and linux [2]. Question, and specially rants are greatly appreciated, and of course... may the 4th be with you. [0] https://github.com/teg/firmwared [1]

Re: rcu-bh design

On Fri, May 04, 2018 at 05:15:11PM +, Joel Fernandes wrote: > Hi Steven, > Just for a warning/disclaimer, I am new to RCU-land and trying to make > sense ;-) So forgive me if something sounds too outlandish. > > On Fri, May 4, 2018 at 9:30 AM Steven Rostedt wrote: > > >

Re: rcu-bh design

On Fri, May 04, 2018 at 05:15:11PM +, Joel Fernandes wrote: > Hi Steven, > Just for a warning/disclaimer, I am new to RCU-land and trying to make > sense ;-) So forgive me if something sounds too outlandish. > > On Fri, May 4, 2018 at 9:30 AM Steven Rostedt wrote: > > > On Fri, 04 May 2018

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 09:09:32AM -0400, Theodore Y. Ts'o wrote: > On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote: > > On Fri, 04 May 2018, David Howells wrote: > > > Sasha Levin via Ksummit-discuss wrote: > > > > > >> Cc: sta...@vger.kernel.org #

[PATCH 3/6] arm64: use for cmpxchg

Currently a number of arm64-specific files include for the definition of the cmpxchg helpers. This works fine today, but won't when we switch over to instrumented atomics, and as noted in Documentation/core-api/atomic_ops.rst: If someone wants to use xchg(), cmpxchg() and their variants,

Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 09:09:32AM -0400, Theodore Y. Ts'o wrote: > On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote: > > On Fri, 04 May 2018, David Howells wrote: > > > Sasha Levin via Ksummit-discuss wrote: > > > > > >> Cc: sta...@vger.kernel.org # commit-id-of-(2) > > > > This has

[PATCH 3/6] arm64: use for cmpxchg

Currently a number of arm64-specific files include for the definition of the cmpxchg helpers. This works fine today, but won't when we switch over to instrumented atomics, and as noted in Documentation/core-api/atomic_ops.rst: If someone wants to use xchg(), cmpxchg() and their variants,

[PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

Currently only instruments the fully ordered variants of atomic functions, ignoring the {relaxed,acquire,release} ordering variants. This patch reworks the header to instrument all ordering variants of the atomic functions, so that architectures implementing these are instrumented appropriately.

[PATCH 1/6] locking/atomic, asm-generic: instrument ordering variants

Currently only instruments the fully ordered variants of atomic functions, ignoring the {relaxed,acquire,release} ordering variants. This patch reworks the header to instrument all ordering variants of the atomic functions, so that architectures implementing these are instrumented appropriately.

[PATCH 5/6] arm64: use instrumented atomics

As our atomics are written in inline assembly, they don't get instrumented when we enable KASAN, and thus we can miss when they are used on erroneous memory locations. As with x86, let's use atomic-instrumented.h to give arm64 instrumented atomics. This requires that we add an arch_ prefix to our

[PATCH 5/6] arm64: use instrumented atomics

As our atomics are written in inline assembly, they don't get instrumented when we enable KASAN, and thus we can miss when they are used on erroneous memory locations. As with x86, let's use atomic-instrumented.h to give arm64 instrumented atomics. This requires that we add an arch_ prefix to our

[PATCH 6/6] arm64: instrument smp_{load_acquire,store_release}

Our __smp_store_release() and __smp_load_acquire() macros use inline assembly, which is opaque to kasan. This means that kasan can't catch erroneous use of these. This patch adds kasan instrumentation to both. It might be better to turn these into __arch_* variants, as we do for the atomics, but

[PATCH 6/6] arm64: instrument smp_{load_acquire,store_release}

Our __smp_store_release() and __smp_load_acquire() macros use inline assembly, which is opaque to kasan. This means that kasan can't catch erroneous use of these. This patch adds kasan instrumentation to both. It might be better to turn these into __arch_* variants, as we do for the atomics, but

[PATCH 0/6] arm64: add instrumented atomics

This series (based on v4.17-rc3) allows arm64's atomics to be instrumented, which should make it easier to catch bugs where atomics are used on erroneous memory locations. The bulk of the diffstat is teaching the generic instrumentation about the acquire/release/relaxed variants of each atomic,

[PATCH 0/6] arm64: add instrumented atomics

This series (based on v4.17-rc3) allows arm64's atomics to be instrumented, which should make it easier to catch bugs where atomics are used on erroneous memory locations. The bulk of the diffstat is teaching the generic instrumentation about the acquire/release/relaxed variants of each atomic,

[PATCH 4/6] arm64: fix assembly constraints for cmpxchg

Our LL/SC cmpxchg assembly uses "Lr" as the constraint for old, which allows either an integer constant suitable for a 64-bit logical oepration, or a register. However, this assembly is also used for 32-bit cases (where we explicitly add a 'w' prefix to the output format), where the set of valid

[PATCH 4/6] arm64: fix assembly constraints for cmpxchg

Our LL/SC cmpxchg assembly uses "Lr" as the constraint for old, which allows either an integer constant suitable for a 64-bit logical oepration, or a register. However, this assembly is also used for 32-bit cases (where we explicitly add a 'w' prefix to the output format), where the set of valid

[PATCH 2/6] locking/atomic, asm-generic: instrument atomic*andnot*()

We don't currently define instrumentation wrappers for the various forms of atomic*andnot*(), as these aren't implemented directly by x86. So that we can instrument architectures which provide these, let's define wrappers for all the variants of these atomics. Signed-off-by: Mark Rutland

[PATCH 2/6] locking/atomic, asm-generic: instrument atomic*andnot*()

We don't currently define instrumentation wrappers for the various forms of atomic*andnot*(), as these aren't implemented directly by x86. So that we can instrument architectures which provide these, let's define wrappers for all the variants of these atomics. Signed-off-by: Mark Rutland Cc:

<    1   2   3   4   5   6   7   8   9   10   >