[PATCH 3/4] [media] ad5820: DT new optional field enable-gpios

Document new enable-gpio field. It can be used to disable the part without turning down its regulator. Cc: devicet...@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado --- Documentation/devicetree/bindings/media/i2c/ad5820.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 2/4] [media] ad5820: Add support for enable pin

This patch adds support for a programmable enable pin. It can be used in situations where the ANA-vcc is not configurable (dummy-regulator), or just to have a more fine control of the power saving. The use of the enable pin is optional Signed-off-by: Ricardo Ribalda Delgado ---

Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line

On 2018年09月19日 10:43, Steven Rostedt wrote: > On Wed, 19 Sep 2018 11:39:32 +0900 > Sergey Senozhatsky wrote: > >> On (09/19/18 10:27), He Zhe wrote: >>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote: On (09/19/18 01:17), zhe...@windriver.com wrote: > @@ -1048,7 +1048,14 @@ static

Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line

On 2018年09月19日 10:43, Steven Rostedt wrote: > On Wed, 19 Sep 2018 11:39:32 +0900 > Sergey Senozhatsky wrote: > >> On (09/19/18 10:27), He Zhe wrote: >>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote: On (09/19/18 01:17), zhe...@windriver.com wrote: > @@ -1048,7 +1048,14 @@ static

Re: [PATCH] soc: qcom: smd-rpm: Add QCS404 compatible

On 19-09-18, 18:45, Bjorn Andersson wrote: > Signed-off-by: Bjorn Andersson Reviewed-by: Vinod Koul > --- > Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 + > drivers/soc/qcom/smd-rpm.c | 1 + > 2 files changed, 2 insertions(+) > > diff

Re: [PATCH] soc: qcom: smd-rpm: Add QCS404 compatible

On 19-09-18, 18:45, Bjorn Andersson wrote: > Signed-off-by: Bjorn Andersson Reviewed-by: Vinod Koul > --- > Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 + > drivers/soc/qcom/smd-rpm.c | 1 + > 2 files changed, 2 insertions(+) > > diff

Re: [PATCH] regulators: qcom: Add PMS405 regulators

On 19-09-18, 18:40, Bjorn Andersson wrote: > The PMS405 provdies 5 SMPS regulators and 13 LDOs, add these to the RPM > regulator driver. Reviewed-by: Vinod Koul > > Signed-off-by: Bjorn Andersson > --- > .../regulator/qcom,smd-rpm-regulator.txt | 23 ++ >

Re: [PATCH] regulators: qcom: Add PMS405 regulators

On 19-09-18, 18:40, Bjorn Andersson wrote: > The PMS405 provdies 5 SMPS regulators and 13 LDOs, add these to the RPM > regulator driver. Reviewed-by: Vinod Koul > > Signed-off-by: Bjorn Andersson > --- > .../regulator/qcom,smd-rpm-regulator.txt | 23 ++ >

Re: [PATCH] mailbox: qcom: Add QCS404 APPS Global compatible

On 19-09-18, 18:44, Bjorn Andersson wrote: > Add support for the QCS404 APPS Global block with IPC register at offset > 8. > > Signed-off-by: Bjorn Andersson Reviewed-by: Vinod Koul > --- > .../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt| 1 + >

Re: [PATCH] mailbox: qcom: Add QCS404 APPS Global compatible

On 19-09-18, 18:44, Bjorn Andersson wrote: > Add support for the QCS404 APPS Global block with IPC register at offset > 8. > > Signed-off-by: Bjorn Andersson Reviewed-by: Vinod Koul > --- > .../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt| 1 + >

Re: [PATCH v2 0/2] Compiler Attributes: (naked only, for v4.19)

On Thu, Sep 20, 2018 at 3:59 PM, Greg Kroah-Hartman wrote: > On Thu, Sep 20, 2018 at 03:57:48PM +0200, Greg Kroah-Hartman wrote: >> On Tue, Sep 18, 2018 at 06:55:40PM +0200, Miguel Ojeda wrote: >> > These two patches are the 5th and 6th of the Compiler Attributes series, >> > which Stefan and

Re: [PATCH v2 0/2] Compiler Attributes: (naked only, for v4.19)

On Thu, Sep 20, 2018 at 3:59 PM, Greg Kroah-Hartman wrote: > On Thu, Sep 20, 2018 at 03:57:48PM +0200, Greg Kroah-Hartman wrote: >> On Tue, Sep 18, 2018 at 06:55:40PM +0200, Miguel Ojeda wrote: >> > These two patches are the 5th and 6th of the Compiler Attributes series, >> > which Stefan and

Re: [PATCH v3] cpufreq: qcom-kryo: Fix section annotations

On 19-09-18, 17:22, Nathan Chancellor wrote: > There is currently a warning when building the Kryo cpufreq driver into > the kernel image: > > WARNING: vmlinux.o(.text+0x8aa424): Section mismatch in reference from > the function qcom_cpufreq_kryo_probe() to the function >

Re: [PATCH v10 04/26] s390: vfio-ap: base implementation of VFIO AP device driver

On 09/20/2018 11:31 AM, Cornelia Huck wrote: On Wed, 12 Sep 2018 15:42:54 -0400 Tony Krowiak wrote: From: Tony Krowiak Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough

Re: [PATCH v3] cpufreq: qcom-kryo: Fix section annotations

On 19-09-18, 17:22, Nathan Chancellor wrote: > There is currently a warning when building the Kryo cpufreq driver into > the kernel image: > > WARNING: vmlinux.o(.text+0x8aa424): Section mismatch in reference from > the function qcom_cpufreq_kryo_probe() to the function >

Re: [PATCH v10 04/26] s390: vfio-ap: base implementation of VFIO AP device driver

On 09/20/2018 11:31 AM, Cornelia Huck wrote: On Wed, 12 Sep 2018 15:42:54 -0400 Tony Krowiak wrote: From: Tony Krowiak Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough

Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared

On Thu, Sep 20, 2018 at 9:36 AM, Dominique Martinet wrote: > Greg Kroah-Hartman wrote on Thu, Sep 20, 2018: >> Why not just route these through Andrew? He takes lots of stuff like >> this for this very reason. > > That works for me (although it might have helped if Andrew had been in > Cc at any

md: dead code in md_alloc()

Hi, Kirill noticed that the following piece of code from md_alloc(dev, name) is dead: if (name && dev) /* * Creating /dev/mdNNN via "newarray", so adjust hold_active. */ mddev->hold_active = UNTIL_STOP; md_alloc() is always

Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared

On Thu, Sep 20, 2018 at 9:36 AM, Dominique Martinet wrote: > Greg Kroah-Hartman wrote on Thu, Sep 20, 2018: >> Why not just route these through Andrew? He takes lots of stuff like >> this for this very reason. > > That works for me (although it might have helped if Andrew had been in > Cc at any

md: dead code in md_alloc()

Hi, Kirill noticed that the following piece of code from md_alloc(dev, name) is dead: if (name && dev) /* * Creating /dev/mdNNN via "newarray", so adjust hold_active. */ mddev->hold_active = UNTIL_STOP; md_alloc() is always

[PATCH v8 6/7] iommu/io-pgtable-arm-v7s: Add support for non-strict mode

As for LPAE, it's simply a case of skipping the leaf invalidation for a regular unmap, and ensuring that the one in split_blk_unmap() is paired with an explicit sync ASAP rather than relying on one which might only eventually happen way down the line. Signed-off-by: Robin Murphy --- v8: Do this

[PATCH v8 5/7] iommu/arm-smmu-v3: Add support for non-strict mode

From: Zhen Lei Now that io-pgtable knows how to dodge strict TLB maintenance, all that's left to do is bridge the gap between the IOMMU core requesting DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE for default domains, and showing the appropriate IO_PGTABLE_QUIRK_NON_STRICT flag to alloc_io_pgtable_ops().

[PATCH v8 4/7] iommu/io-pgtable-arm: Add support for non-strict mode

From: Zhen Lei Non-strict mode is simply a case of skipping 'regular' leaf TLBIs, since the sync is already factored out into ops->iotlb_sync at the core API level. Non-leaf invalidations where we change the page table structure itself still have to be issued synchronously in order to maintain

Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library

On Thu, Sep 20, 2018 at 8:41 AM Ard Biesheuvel wrote: > > (+ Arnd, Eric) > > On 18 September 2018 at 09:16, Jason A. Donenfeld wrote: > ... > > > diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile > > new file mode 100644 > > index ..83dfd63988c0 > > --- /dev/null > > +++

[PATCH v8 2/7] iommu/dma: Add support for non-strict mode

From: Zhen Lei With the flush queue infrastructure already abstracted into IOVA domains, hooking it up in iommu-dma is pretty simple. Since there is a degree of dependency on the IOMMU driver knowing what to do to play along, we key the whole thing off a domain attribute which will be set on

[PATCH v8 7/7] iommu/arm-smmu: Support non-strict mode

All we need is to wire up .flush_iotlb_all properly and implement the domain attribute, and iommu-dma and io-pgtable will do the rest for us. The only real subtlety is documenting the barrier semantics we're introducing between io-pgtable and the drivers for non-strict flushes. Signed-off-by:

Re: [PATCH 02/10] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath

On Mon, Apr 09, 2018 at 06:19:59PM +0100, Will Deacon wrote: > On Mon, Apr 09, 2018 at 05:54:20PM +0200, Peter Zijlstra wrote: > > On Mon, Apr 09, 2018 at 03:54:09PM +0100, Will Deacon wrote: > > > +/** > > > + * set_pending_fetch_acquire - set the pending bit and return the old > > > lock > > >

Re: [RESEND PATCH v3 0/3] sh: make early_platform code SuperH-specific

On 20/09/2018 15:00, Bartosz Golaszewski wrote: [ ... ] > Ping for 4.20. This is the third release cycle I'm trying to get this > merged and there never were any objections. Thanks for the heads up, it is in the pipe. -- Daniel -- Linaro.org │ Open source

[PATCH v8 6/7] iommu/io-pgtable-arm-v7s: Add support for non-strict mode

As for LPAE, it's simply a case of skipping the leaf invalidation for a regular unmap, and ensuring that the one in split_blk_unmap() is paired with an explicit sync ASAP rather than relying on one which might only eventually happen way down the line. Signed-off-by: Robin Murphy --- v8: Do this

[PATCH v8 5/7] iommu/arm-smmu-v3: Add support for non-strict mode

From: Zhen Lei Now that io-pgtable knows how to dodge strict TLB maintenance, all that's left to do is bridge the gap between the IOMMU core requesting DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE for default domains, and showing the appropriate IO_PGTABLE_QUIRK_NON_STRICT flag to alloc_io_pgtable_ops().

[PATCH v8 4/7] iommu/io-pgtable-arm: Add support for non-strict mode

From: Zhen Lei Non-strict mode is simply a case of skipping 'regular' leaf TLBIs, since the sync is already factored out into ops->iotlb_sync at the core API level. Non-leaf invalidations where we change the page table structure itself still have to be issued synchronously in order to maintain

Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library

On Thu, Sep 20, 2018 at 8:41 AM Ard Biesheuvel wrote: > > (+ Arnd, Eric) > > On 18 September 2018 at 09:16, Jason A. Donenfeld wrote: > ... > > > diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile > > new file mode 100644 > > index ..83dfd63988c0 > > --- /dev/null > > +++

[PATCH v8 2/7] iommu/dma: Add support for non-strict mode

From: Zhen Lei With the flush queue infrastructure already abstracted into IOVA domains, hooking it up in iommu-dma is pretty simple. Since there is a degree of dependency on the IOMMU driver knowing what to do to play along, we key the whole thing off a domain attribute which will be set on

[PATCH v8 7/7] iommu/arm-smmu: Support non-strict mode

All we need is to wire up .flush_iotlb_all properly and implement the domain attribute, and iommu-dma and io-pgtable will do the rest for us. The only real subtlety is documenting the barrier semantics we're introducing between io-pgtable and the drivers for non-strict flushes. Signed-off-by:

Re: [PATCH 02/10] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath

On Mon, Apr 09, 2018 at 06:19:59PM +0100, Will Deacon wrote: > On Mon, Apr 09, 2018 at 05:54:20PM +0200, Peter Zijlstra wrote: > > On Mon, Apr 09, 2018 at 03:54:09PM +0100, Will Deacon wrote: > > > +/** > > > + * set_pending_fetch_acquire - set the pending bit and return the old > > > lock > > >

Re: [RESEND PATCH v3 0/3] sh: make early_platform code SuperH-specific

On 20/09/2018 15:00, Bartosz Golaszewski wrote: [ ... ] > Ping for 4.20. This is the third release cycle I'm trying to get this > merged and there never were any objections. Thanks for the heads up, it is in the pipe. -- Daniel -- Linaro.org │ Open source

Re: [PATCH V8 1/2] clocksource: add gx6605s SOC system timer

On 20/09/2018 10:03, Guo Ren wrote: > Changelog: > - Add License and Copyright > - Use timer-of framework > - Change name with upstream feedback > - Use clksource_mmio framework > > Signed-off-by: Guo Ren > --- > drivers/clocksource/Kconfig | 8 ++ > drivers/clocksource/Makefile

Re: [PATCH v2] cpufreq: qcom-kryo: Fix section mismatch warning

On 20-09-18, 00:45, Rafael J. Wysocki wrote: > Because __init things go away at one point and calling them from the > other sections is a bad idea. OTOH, __exit things are simply not > needed in built-in drivers and they are never there if the driver is > built-in, so calling them from the other

[PATCH v8 0/7] Add non-strict mode support for iommu-dma

Hi all, Hopefully this is the last spin of the series - I've now dropped my light touch and fixed up all the various prose text, plus implemented the proper quirk support for short-descriptor because it's actually just a trivial cut-and-paste job. Robin. Robin Murphy (2):

Re: [PATCH V8 1/2] clocksource: add gx6605s SOC system timer

On 20/09/2018 10:03, Guo Ren wrote: > Changelog: > - Add License and Copyright > - Use timer-of framework > - Change name with upstream feedback > - Use clksource_mmio framework > > Signed-off-by: Guo Ren > --- > drivers/clocksource/Kconfig | 8 ++ > drivers/clocksource/Makefile

Re: [PATCH v2] cpufreq: qcom-kryo: Fix section mismatch warning

On 20-09-18, 00:45, Rafael J. Wysocki wrote: > Because __init things go away at one point and calling them from the > other sections is a bad idea. OTOH, __exit things are simply not > needed in built-in drivers and they are never there if the driver is > built-in, so calling them from the other

[PATCH v8 0/7] Add non-strict mode support for iommu-dma

Hi all, Hopefully this is the last spin of the series - I've now dropped my light touch and fixed up all the various prose text, plus implemented the proper quirk support for short-descriptor because it's actually just a trivial cut-and-paste job. Robin. Robin Murphy (2):

Re: [PATCH 0/4] ARM: dts: mvebu: updates and new board

Hi Chris, On jeu., juil. 26 2018, Chris Packham wrote: > This series updates the armada-xp-98dx3236 SoC and related boards to use the > new style dts bindings for nand. > > I've also added a new db-88f6820-amc board which is an Armada-385 based > reference board from Marvell's switch team.

Re: [PATCH 0/4] ARM: dts: mvebu: updates and new board

Hi Chris, On jeu., juil. 26 2018, Chris Packham wrote: > This series updates the armada-xp-98dx3236 SoC and related boards to use the > new style dts bindings for nand. > > I've also added a new db-88f6820-amc board which is an Armada-385 based > reference board from Marvell's switch team.

Re: [PATCH] ARM: dts: stm32: update SPI6 dmas property on stm32mp157c

Hi Amélie On 09/17/2018 10:04 AM, Amelie Delaunay wrote: Remove unused parameter from SPI6 dmas property on stm32mp157c SoC. Fixes: dc3f8c86c10d ("ARM: dts: stm32: add SPI support on stm32mp157c") Signed-off-by: Amelie Delaunay --- arch/arm/boot/dts/stm32mp157c.dtsi | 4 ++-- 1 file

Re: [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function

From: YueHaibing Date: Thu, 20 Sep 2018 20:32:44 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to

Re: [PATCH] ARM: dts: stm32: update SPI6 dmas property on stm32mp157c

Hi Amélie On 09/17/2018 10:04 AM, Amelie Delaunay wrote: Remove unused parameter from SPI6 dmas property on stm32mp157c SoC. Fixes: dc3f8c86c10d ("ARM: dts: stm32: add SPI support on stm32mp157c") Signed-off-by: Amelie Delaunay --- arch/arm/boot/dts/stm32mp157c.dtsi | 4 ++-- 1 file

Re: [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function

From: YueHaibing Date: Thu, 20 Sep 2018 20:32:44 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to

Re: [PATCH v10 05/26] s390: vfio-ap: register matrix device with VFIO mdev framework

On Wed, 12 Sep 2018 15:42:55 -0400 Tony Krowiak wrote: > From: Tony Krowiak > > Registers the matrix device created by the VFIO AP device > driver with the VFIO mediated device framework. > Registering the matrix device will create the sysfs > structures needed to create mediated matrix

Re: [PATCH v10 05/26] s390: vfio-ap: register matrix device with VFIO mdev framework

On Wed, 12 Sep 2018 15:42:55 -0400 Tony Krowiak wrote: > From: Tony Krowiak > > Registers the matrix device created by the VFIO AP device > driver with the VFIO mediated device framework. > Registering the matrix device will create the sysfs > structures needed to create mediated matrix

Re: [PATCH] clocksource/drivers/fttmr010: fix set_next_event handler

On Wed, Sep 19, 2018 at 3:13 PM Tao Ren wrote: > Currently, the aspeed MATCH1 register is updated to cycles> in set_next_event handler, with the assumption that COUNT > register value is preserved when the timer is disabled and it continues > decrementing after the timer is enabled. But the

Re: [PATCH] clocksource/drivers/fttmr010: fix set_next_event handler

On Wed, Sep 19, 2018 at 3:13 PM Tao Ren wrote: > Currently, the aspeed MATCH1 register is updated to cycles> in set_next_event handler, with the assumption that COUNT > register value is preserved when the timer is disabled and it continues > decrementing after the timer is enabled. But the

Re: [PATCH V4 2/4] dt-bindings: soc: qcom: GENI SE SPI controller device tree binding

Quoting Dilip Kota (2018-09-18 11:07:24) > Move GENI SE SPI controller device-tree bindings > from devicetree/bindings/soc/qcom/qcom,geni-se.txt > to devicetree/bindings/spi/qcom,spi-geni-qcom.txt. > > Signed-off-by: Dilip Kota > --- Reviewed-by: Stephen Boyd

Re: [PATCH V4 2/4] dt-bindings: soc: qcom: GENI SE SPI controller device tree binding

Quoting Dilip Kota (2018-09-18 11:07:24) > Move GENI SE SPI controller device-tree bindings > from devicetree/bindings/soc/qcom/qcom,geni-se.txt > to devicetree/bindings/spi/qcom,spi-geni-qcom.txt. > > Signed-off-by: Dilip Kota > --- Reviewed-by: Stephen Boyd

Re: [PATCH V4 1/4] dt-bindings: soc: qcom: Remove SPI controller maximum frequency binding

Quoting Dilip Kota (2018-09-18 11:07:23) > SPI controller driver should maintain the maximum frequency > of the controller instead of relying on device tree bindings. > Because maximum frequency is specific property of SPI > controller. > > Signed-off-by: Dilip Kota > --- Reviewed-by: Stephen

Re: [PATCH V4 1/4] dt-bindings: soc: qcom: Remove SPI controller maximum frequency binding

Quoting Dilip Kota (2018-09-18 11:07:23) > SPI controller driver should maintain the maximum frequency > of the controller instead of relying on device tree bindings. > Because maximum frequency is specific property of SPI > controller. > > Signed-off-by: Dilip Kota > --- Reviewed-by: Stephen

Re: [PATCH v5] mtd: rawnand: ams-delta: use GPIO lookup table

On Wed, Sep 19, 2018 at 3:17 PM Janusz Krzysztofik wrote: > Now as Amstrad Delta board - the only user of this driver - provides > GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and > use the table to locate required GPIO pins. > > Declare static variables for storing GPIO

Re: [PATCH v5] mtd: rawnand: ams-delta: use GPIO lookup table

On Wed, Sep 19, 2018 at 3:17 PM Janusz Krzysztofik wrote: > Now as Amstrad Delta board - the only user of this driver - provides > GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and > use the table to locate required GPIO pins. > > Declare static variables for storing GPIO

Re: [PATCH 3/4] dt-bindings: pinctrl: qcom: Add QCS404 pinctrl binding

Quoting Bjorn Andersson (2018-09-19 18:37:11) > + > +Example: > + > + tlmm: pinctrl@0100 { Drop leading 0. > + compatible = "qcom,qcs404-pinctrl"; > + reg = <0x0100 0x20>, > + <0x0130 0x20>, > +

Re: [PATCH 3/4] dt-bindings: pinctrl: qcom: Add QCS404 pinctrl binding

Quoting Bjorn Andersson (2018-09-19 18:37:11) > + > +Example: > + > + tlmm: pinctrl@0100 { Drop leading 0. > + compatible = "qcom,qcs404-pinctrl"; > + reg = <0x0100 0x20>, > + <0x0130 0x20>, > +

Re: [PATCH v3 4/5] KVM/x86/vPMU: Add APIs to support host save/restore the guest lbr stack

> +int intel_pmu_enable_save_guest_lbr(struct kvm_vcpu *vcpu) > +{ > + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > + struct perf_event *event; > + struct perf_event_attr attr = { > + .type = PERF_TYPE_RAW, > + .size = sizeof(attr), > + .pinned = true,

Re: [PATCH v3 4/5] KVM/x86/vPMU: Add APIs to support host save/restore the guest lbr stack

> +int intel_pmu_enable_save_guest_lbr(struct kvm_vcpu *vcpu) > +{ > + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > + struct perf_event *event; > + struct perf_event_attr attr = { > + .type = PERF_TYPE_RAW, > + .size = sizeof(attr), > + .pinned = true,

Re: [PATCH v10 04/26] s390: vfio-ap: base implementation of VFIO AP device driver

On Wed, 12 Sep 2018 15:42:54 -0400 Tony Krowiak wrote: > From: Tony Krowiak > > Introduces a new AP device driver. This device driver > is built on the VFIO mediated device framework. The framework > provides sysfs interfaces that facilitate passthrough > access by guests to devices installed

Re: [PATCH v10 04/26] s390: vfio-ap: base implementation of VFIO AP device driver

On Wed, 12 Sep 2018 15:42:54 -0400 Tony Krowiak wrote: > From: Tony Krowiak > > Introduces a new AP device driver. This device driver > is built on the VFIO mediated device framework. The framework > provides sysfs interfaces that facilitate passthrough > access by guests to devices installed

Re: [PATCH] ARM: dts: stm32: enable display on stm32mp157c-ev1 board

Hi Yannick On 08/21/2018 02:58 PM, Yannick Fertré wrote: Enable panel raydium RM68200, DSI bridge & display controller. Signed-off-by: Yannick Fertré --- Applied on stm32-next. Thanks. Alex

Re: [PATCH] pinctrl: qcom: spmi-gpio: Add pms405 gpio support

Quoting Bjorn Andersson (2018-09-19 18:47:05) > diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > index a29efbe08f48..b54891998caa 100644 > --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > @@

Re: [PATCH] pinctrl: qcom: spmi-gpio: Add pms405 gpio support

Quoting Bjorn Andersson (2018-09-19 18:47:05) > diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > index a29efbe08f48..b54891998caa 100644 > --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c > @@

Re: [PATCH] ARM: dts: stm32: enable display on stm32mp157c-ev1 board

Hi Yannick On 08/21/2018 02:58 PM, Yannick Fertré wrote: Enable panel raydium RM68200, DSI bridge & display controller. Signed-off-by: Yannick Fertré --- Applied on stm32-next. Thanks. Alex

Re: [PATCH v2] ARM: multi_v7_defconfig: enable STM32 SPI

Hi Amélie On 08/22/2018 12:49 PM, Amelie Delaunay wrote: Enable the STM32 SPI driver, implemented on STM32MP1 SoC. Signed-off-by: Amelie Delaunay --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig

Re: [PATCH v2] ARM: multi_v7_defconfig: enable STM32 SPI

Hi Amélie On 08/22/2018 12:49 PM, Amelie Delaunay wrote: Enable the STM32 SPI driver, implemented on STM32MP1 SoC. Signed-off-by: Amelie Delaunay --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig

Re: [PATCH] pinctrl: intel: Do pin translation in other GPIO operations as well

On Tue, Sep 18, 2018 at 8:36 AM Mika Westerberg wrote: > For some reason I thought GPIOLIB handles translation from GPIO ranges > to pinctrl pins but it turns out not to be the case. This means that > when GPIOs operations are performed for a pin controller having a custom > GPIO base such as

Re: [PATCH] pinctrl: intel: Do pin translation in other GPIO operations as well

On Tue, Sep 18, 2018 at 8:36 AM Mika Westerberg wrote: > For some reason I thought GPIOLIB handles translation from GPIO ranges > to pinctrl pins but it turns out not to be the case. This means that > when GPIOs operations are performed for a pin controller having a custom > GPIO base such as

IT Decision Makers Across the Globe

Hello, Hope all is well! We are a database organization. We provide business executives' contact information. Below, I've included a few examples: Industry-Specific Lists: Agriculture, Business Services, Chambers of Commerce, Cities, Towns & Municipalities, Construction, Consumer

IT Decision Makers Across the Globe

Hello, Hope all is well! We are a database organization. We provide business executives' contact information. Below, I've included a few examples: Industry-Specific Lists: Agriculture, Business Services, Chambers of Commerce, Cities, Towns & Municipalities, Construction, Consumer

Re: [PATCH 2/2] pinctrl: tegra: move probe to __init section

On Tue, Sep 18, 2018 at 6:24 PM Stefan Agner wrote: > The Tegra pinctrl drivers are always built-in. This allows to use > platform_driver_probe() and mark several functions as __init. > This allows the kernel to free about 1KiB of memory if Tegra > pinctrl drivers are not used. > >

Re: [PATCH 2/2] pinctrl: tegra: move probe to __init section

On Tue, Sep 18, 2018 at 6:24 PM Stefan Agner wrote: > The Tegra pinctrl drivers are always built-in. This allows to use > platform_driver_probe() and mark several functions as __init. > This allows the kernel to free about 1KiB of memory if Tegra > pinctrl drivers are not used. > >

[PATCH] staging: greybus: control.c: fixed some coding style issues

fixed some "Alignment should match open parenthesis" checks. Signing up for the kernel clean up crew while I learn C Signed-off-by: Aaron Williams --- drivers/staging/greybus/control.c | 39 +++ 1 file changed, 19 insertions(+), 20 deletions(-) diff --git

[PATCH] staging: greybus: control.c: fixed some coding style issues

fixed some "Alignment should match open parenthesis" checks. Signing up for the kernel clean up crew while I learn C Signed-off-by: Aaron Williams --- drivers/staging/greybus/control.c | 39 +++ 1 file changed, 19 insertions(+), 20 deletions(-) diff --git

Re: [PATCH 1/2] pinctrl: tegra: do not export tegra_pinctrl_probe

On Tue, Sep 18, 2018 at 6:24 PM Stefan Agner wrote: > No user of tegra_pinctrl_probe can be built as a module, hence > exporting the symbol is not necessary. Drop EXPORT_SYMBOL_GPL. > > Signed-off-by: Stefan Agner Patch applied. Yours, Linus Walleij

Re: [PATCH 1/2] pinctrl: tegra: do not export tegra_pinctrl_probe

On Tue, Sep 18, 2018 at 6:24 PM Stefan Agner wrote: > No user of tegra_pinctrl_probe can be built as a module, hence > exporting the symbol is not necessary. Drop EXPORT_SYMBOL_GPL. > > Signed-off-by: Stefan Agner Patch applied. Yours, Linus Walleij

Re: pinctrl-icelake: driver writes to wrong offsets?

Good bug hunting in this thread! Please see if you can use libgpiod or the tools from the kernel tools/gpio directory to test GPIO lines, I usually use that since the global GPIO numberspace only constantly confuse me. Especially when there is a really many many GPIOs the local numberspace and

Re: pinctrl-icelake: driver writes to wrong offsets?

Good bug hunting in this thread! Please see if you can use libgpiod or the tools from the kernel tools/gpio directory to test GPIO lines, I usually use that since the global GPIO numberspace only constantly confuse me. Especially when there is a really many many GPIOs the local numberspace and

[PATCH 0/6] mount-api: fixes and cleanups

These fix issues with handling subtype (fuse specific thing) and rename some constants on the new API to make me happy. I realize the last patch could be viewed as bikeshedding, but I do think suggesting falsehood in a constant name can lead to painful real life bugs, so now is the time to think

[PATCH 3/6] mount: fix regression in setting "subtype" from legacy API

Subtype was initilized at the wrong place from the wrong source (fstype->fs_type->name, which does not ever contain a subtype). Set subtype from do_new_mount(), where it actually does something. Verified with fuse. Signed-off-by: Miklos Szeredi --- fs/fs_context.c | 34

[PATCH 1/6] selinux: fold superblock_doinit() into only caller

...and remove the unused option parsing part as well. Signed-off-by: Miklos Szeredi --- security/selinux/hooks.c | 37 + 1 file changed, 9 insertions(+), 28 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index

[PATCH 0/6] mount-api: fixes and cleanups

These fix issues with handling subtype (fuse specific thing) and rename some constants on the new API to make me happy. I realize the last patch could be viewed as bikeshedding, but I do think suggesting falsehood in a constant name can lead to painful real life bugs, so now is the time to think

[PATCH 3/6] mount: fix regression in setting "subtype" from legacy API

Subtype was initilized at the wrong place from the wrong source (fstype->fs_type->name, which does not ever contain a subtype). Set subtype from do_new_mount(), where it actually does something. Verified with fuse. Signed-off-by: Miklos Szeredi --- fs/fs_context.c | 34

[PATCH 1/6] selinux: fold superblock_doinit() into only caller

...and remove the unused option parsing part as well. Signed-off-by: Miklos Szeredi --- security/selinux/hooks.c | 37 + 1 file changed, 9 insertions(+), 28 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index

[PATCH 6/6] fsconfig: rename FSCONFIG_CMD_CREATE to FSCONFIG_CMD_OBTAIN

The old name strongly implies that a new superblock will be created from the fs_context. This is not true: filesystems are free to retuse an existing superblock and return that (for good reason). To avoid confusion, rename this command to something more appropriate. Signed-off-by: Miklos

[PATCH 6/6] fsconfig: rename FSCONFIG_CMD_CREATE to FSCONFIG_CMD_OBTAIN

The old name strongly implies that a new superblock will be created from the fs_context. This is not true: filesystems are free to retuse an existing superblock and return that (for good reason). To avoid confusion, rename this command to something more appropriate. Signed-off-by: Miklos

[PATCH 5/6] fsmount: do not use legacy MS_ flags

What happens if we introduce new flags for fsmount(2) and are already out of flags for mount(2)? I see a big mess that way. So let's instead start a clean new set, to be used in the new API. The MS_RELATIME flag was accepted but ignored. Simply leave this out of the new set, since "relatime"

[PATCH 2/6] vfs_submount: use SB_SUBMOUNT instead of MS_SUBMOUNT

The latter is for the legacy userspace API only and should not be used internally. Signed-off-by: Miklos Szeredi --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index a28b713164bf..865b6f2c5e7d 100644 --- a/fs/namespace.c

[PATCH 4/6] fsconfig: parse "subtype" param for old internal API

This subtype thing is specific to "fuse" and "fuseblk" filesystems. When these are switched over to the new context API, the handling of this parameter can be moved from legacy_parse_param() into fuse. Signed-off-by: Miklos Szeredi --- fs/fs_context.c | 10 ++ 1 file changed, 10

[PATCH 5/6] fsmount: do not use legacy MS_ flags

What happens if we introduce new flags for fsmount(2) and are already out of flags for mount(2)? I see a big mess that way. So let's instead start a clean new set, to be used in the new API. The MS_RELATIME flag was accepted but ignored. Simply leave this out of the new set, since "relatime"

[PATCH 2/6] vfs_submount: use SB_SUBMOUNT instead of MS_SUBMOUNT

The latter is for the legacy userspace API only and should not be used internally. Signed-off-by: Miklos Szeredi --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index a28b713164bf..865b6f2c5e7d 100644 --- a/fs/namespace.c

[PATCH 4/6] fsconfig: parse "subtype" param for old internal API

This subtype thing is specific to "fuse" and "fuseblk" filesystems. When these are switched over to the new context API, the handling of this parameter can be moved from legacy_parse_param() into fuse. Signed-off-by: Miklos Szeredi --- fs/fs_context.c | 10 ++ 1 file changed, 10

Re: [PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

On 9/20/18 8:01 AM, Joe Lawrence wrote: > On Mon, Aug 27, 2018 at 12:45:25AM -0700, Kees Cook wrote: >> On Tue, May 29, 2018 at 6:27 AM, Andy Whitcroft >> wrote: >>> On Wed, Mar 07, 2018 at 04:02:45PM -0800, Brian Belleville wrote: The final field of a floppy_struct is the field "name",

Re: [PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

On 9/20/18 8:01 AM, Joe Lawrence wrote: > On Mon, Aug 27, 2018 at 12:45:25AM -0700, Kees Cook wrote: >> On Tue, May 29, 2018 at 6:27 AM, Andy Whitcroft >> wrote: >>> On Wed, Mar 07, 2018 at 04:02:45PM -0800, Brian Belleville wrote: The final field of a floppy_struct is the field "name",

[PATCH] tools: PCI: exit with error code when test fails

This makes it easier to use pcitest in automated setups. Signed-off-by: Jean-Jacques Hiblot --- tools/pci/pcitest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c index af146bb..5adc8cd 100644 --- a/tools/pci/pcitest.c +++

[PATCH] tools: PCI: exit with error code when test fails

This makes it easier to use pcitest in automated setups. Signed-off-by: Jean-Jacques Hiblot --- tools/pci/pcitest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c index af146bb..5adc8cd 100644 --- a/tools/pci/pcitest.c +++

<    3   4   5   6   7   8   9   10   11   12   >