Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > On Mon, 2017-08-28 at 08:49 +0200, Greg KH wrote: > > On Mon, Aug 28, 2017 at 04:41:27PM +1000, Stephen Rothwell wrote: > > > Hi James, > > > > > > Today's linux-next merge of the scsi tree got a conflict in: > > > > > >

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > On Mon, 2017-08-28 at 08:49 +0200, Greg KH wrote: > > On Mon, Aug 28, 2017 at 04:41:27PM +1000, Stephen Rothwell wrote: > > > Hi James, > > > > > > Today's linux-next merge of the scsi tree got a conflict in: > > > > > >

Re: [PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

Hi, On 16-08-17 22:28, Liam Breck wrote: Hi Hans, On Tue, Aug 15, 2017 at 1:04 PM, Hans de Goede wrote: On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another

Re: [PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

Hi, On 16-08-17 22:28, Liam Breck wrote: Hi Hans, On Tue, Aug 15, 2017 at 1:04 PM, Hans de Goede wrote: On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another (charger) IC. It has

Re: [RESEND PATCH v5 01/16] dt-bindings: i2c: eeprom: Document vendor to be used and deprecated ones

On Thu, Jun 15, 2017 at 08:54:03PM +0200, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. >

Re: [RESEND PATCH v5 01/16] dt-bindings: i2c: eeprom: Document vendor to be used and deprecated ones

On Thu, Jun 15, 2017 at 08:54:03PM +0200, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. >

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, 28 Aug 2017 17:26:05 +0200, Bernhard Held wrote: > > On 08/27/2017 at 02:35 PM, Adam Borowski wrote: > > 4.13-rc5 retested fails > > Crashed only after two hours or so of testing. > > > > 4.13-rc4 apparently works > > It survived several hours of varied tests (like 5 debian-installer

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, 28 Aug 2017 17:26:05 +0200, Bernhard Held wrote: > > On 08/27/2017 at 02:35 PM, Adam Borowski wrote: > > 4.13-rc5 retested fails > > Crashed only after two hours or so of testing. > > > > 4.13-rc4 apparently works > > It survived several hours of varied tests (like 5 debian-installer

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

> > But there is a dependency, no? If I apply the driver patch, > > non-converted device trees will not find their eeproms anymore. So, I > > I don't think that's correct. If you apply this patch before the DTS > changes, the driver will still match using the I2C device ID table > like it has

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

> > But there is a dependency, no? If I apply the driver patch, > > non-converted device trees will not find their eeproms anymore. So, I > > I don't think that's correct. If you apply this patch before the DTS > changes, the driver will still match using the I2C device ID table > like it has

Re: [PATCH 2/3] iio: Introduce the generic counter interface

On Sun, Aug 20, 2017 at 12:40:02PM +0100, Jonathan Cameron wrote: >On Mon, 31 Jul 2017 12:03:23 -0400 >William Breathitt Gray wrote: > >> This patch introduces the IIO generic counter interface for supporting >> counter devices. The generic counter interface serves as a

Re: [PATCH 2/3] iio: Introduce the generic counter interface

On Sun, Aug 20, 2017 at 12:40:02PM +0100, Jonathan Cameron wrote: >On Mon, 31 Jul 2017 12:03:23 -0400 >William Breathitt Gray wrote: > >> This patch introduces the IIO generic counter interface for supporting >> counter devices. The generic counter interface serves as a catch-all to >> enable

RE: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Monday, August 28, 2017 11:16 AM > To: Eduardo Otubo > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Haiyang > Zhang ; Stephen Hemminger

RE: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Monday, August 28, 2017 11:16 AM > To: Eduardo Otubo > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Haiyang > Zhang ; Stephen Hemminger > ; David Miller > Subject: Re:

Re: [PATCH] fork: fix incorrect fput of ->exe_file causing use-after-free

On Fri, Aug 25, 2017 at 04:40:36PM +0200, Oleg Nesterov wrote: > On 08/24, Eric Biggers wrote: > > > > On Thu, Aug 24, 2017 at 03:20:41PM +0200, Oleg Nesterov wrote: > > > On 08/23, Eric Biggers wrote: > > > > > > > > From: Eric Biggers > > > > > > > > Commit 7c051267931a

Re: [PATCH] fork: fix incorrect fput of ->exe_file causing use-after-free

On Fri, Aug 25, 2017 at 04:40:36PM +0200, Oleg Nesterov wrote: > On 08/24, Eric Biggers wrote: > > > > On Thu, Aug 24, 2017 at 03:20:41PM +0200, Oleg Nesterov wrote: > > > On 08/23, Eric Biggers wrote: > > > > > > > > From: Eric Biggers > > > > > > > > Commit 7c051267931a ("mm, fork: make

Re: [PATCH 3/3] iommu: s390: constify iommu_ops

On Mon, 28 Aug 2017 17:42:50 +0530 Arvind Yadav wrote: > iommu_ops are not supposed to change at runtime. > Functions 'bus_set_iommu' working with const iommu_ops provided > by . So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [PATCH 3/3] iommu: s390: constify iommu_ops

On Mon, 28 Aug 2017 17:42:50 +0530 Arvind Yadav wrote: > iommu_ops are not supposed to change at runtime. > Functions 'bus_set_iommu' working with const iommu_ops provided > by . So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav > --- > drivers/iommu/s390-iommu.c | 2 +-

[PATCH] libnvdimm: clean up command definitions

Remove the command payloads that do not have an associated libnvdimm ioctl. I.e. remove the payloads that would only ever be carried in the ND_CMD_CALL envelope. This prevents userspace from growing unnecessary dependencies on this kernel header when userspace already has everything it needs to

[PATCH] libnvdimm: clean up command definitions

Remove the command payloads that do not have an associated libnvdimm ioctl. I.e. remove the payloads that would only ever be carried in the ND_CMD_CALL envelope. This prevents userspace from growing unnecessary dependencies on this kernel header when userspace already has everything it needs to

Re: [PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

On Fri, Jul 28, 2017 at 07:27:04AM -0700, Andrey Smirnov wrote: > Cc: cphe...@gmail.com > Cc: Lucas Stach > Cc: Nikita Yushchenko > Cc: Rob Herring > Cc: Mark Rutland > Cc:

Re: [PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

On Fri, Jul 28, 2017 at 07:27:04AM -0700, Andrey Smirnov wrote: > Cc: cphe...@gmail.com > Cc: Lucas Stach > Cc: Nikita Yushchenko > Cc: Rob Herring > Cc: Mark Rutland > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Acked-by: Rob Herring > Acked-for-MFD-by: Lee Jones >

Re: [RFC] ARM: Orion: Check DRAM window size

On Mon, Aug 28, 2017 at 05:30:39PM +0200, Jan Luebbe wrote: > This is a corresponding change as "PCI: mvebu: Check DRAM window size" applied > to the Orion PCIe driver. I don't have the relevant hardware myself, but the > patch may still be useful for someone who has. This is completely untested.

Re: [RFC] ARM: Orion: Check DRAM window size

On Mon, Aug 28, 2017 at 05:30:39PM +0200, Jan Luebbe wrote: > This is a corresponding change as "PCI: mvebu: Check DRAM window size" applied > to the Orion PCIe driver. I don't have the relevant hardware myself, but the > patch may still be useful for someone who has. This is completely untested.

Re: [PATCH v5 0/2] ZII RAVE platform driver

On Wed, Aug 02, 2017 at 04:03:34PM -0700, Greg Kroah-Hartman wrote: > On Wed, Aug 02, 2017 at 01:31:51PM -0700, Andrey Smirnov wrote: > > On Fri, Jul 28, 2017 at 5:07 PM, Andrey Smirnov > > wrote: > > > On Fri, Jul 28, 2017 at 4:30 PM, Greg Kroah-Hartman > > >

Re: [PATCH v5 0/2] ZII RAVE platform driver

On Wed, Aug 02, 2017 at 04:03:34PM -0700, Greg Kroah-Hartman wrote: > On Wed, Aug 02, 2017 at 01:31:51PM -0700, Andrey Smirnov wrote: > > On Fri, Jul 28, 2017 at 5:07 PM, Andrey Smirnov > > wrote: > > > On Fri, Jul 28, 2017 at 4:30 PM, Greg Kroah-Hartman > > > wrote: > > >> On Fri, Jul 28, 2017

Re: [PATCH v2 2/3] rtc: Add Realtek RTD1295

Hi, On 27/08/2017 at 13:30:59 +0200, Andreas Färber wrote: > Well, I found your rtc_year_days rather confusing and had to play with > the arguments until I got it working as expected, so I wanted an inline > function (or macro) as abstraction from my three callers. > > Sadly the naming is rather

Re: [PATCH v2 2/3] rtc: Add Realtek RTD1295

Hi, On 27/08/2017 at 13:30:59 +0200, Andreas Färber wrote: > Well, I found your rtc_year_days rather confusing and had to play with > the arguments until I got it working as expected, so I wanted an inline > function (or macro) as abstraction from my three callers. > > Sadly the naming is rather

Re: mmotm 2017-08-25-15-50 uploaded

> On Mon 28-08-17 18:27:05, Stephen Rothwell wrote: > > Hi Michal, > > > > On Mon, 28 Aug 2017 09:59:31 +0200 Michal Hocko wrote: > > > > > > From 31d551dbcb1b7987a4cd07767c1e2805849b7a26 Mon Sep 17 00:00:00 2001 > > > From: Michal Hocko > > > Date: Mon, 28

Re: mmotm 2017-08-25-15-50 uploaded

> On Mon 28-08-17 18:27:05, Stephen Rothwell wrote: > > Hi Michal, > > > > On Mon, 28 Aug 2017 09:59:31 +0200 Michal Hocko wrote: > > > > > > From 31d551dbcb1b7987a4cd07767c1e2805849b7a26 Mon Sep 17 00:00:00 2001 > > > From: Michal Hocko > > > Date: Mon, 28 Aug 2017 09:41:39 +0200 > > >

Re: [PATCH] scsi: ufs: Make use of UFS_BIT macro wherever possible

On Mon, 2017-08-28 at 17:49 +0530, Alim Akhtar wrote: > This entire file uses UFS_BIT macro for bits definition, expect for few > places. This patch convert those defines to use UFS_BIT macro to be aligned > with reset of the file. This is the definition of the UFS_BIT() macro I found in

Re: [PATCH] scsi: ufs: Make use of UFS_BIT macro wherever possible

On Mon, 2017-08-28 at 17:49 +0530, Alim Akhtar wrote: > This entire file uses UFS_BIT macro for bits definition, expect for few > places. This patch convert those defines to use UFS_BIT macro to be aligned > with reset of the file. This is the definition of the UFS_BIT() macro I found in

Re: [PATCH] reset: uniphier: add ethernet reset control support

2017-08-28 18:59 GMT+09:00 Kunihiko Hayashi : > Add reset lines for ethernet controller on Pro4, PXs2, LD11 and > LD20 SoCs. > > Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Thanks! --

Re: [PATCH] reset: uniphier: add ethernet reset control support

2017-08-28 18:59 GMT+09:00 Kunihiko Hayashi : > Add reset lines for ethernet controller on Pro4, PXs2, LD11 and > LD20 SoCs. > > Signed-off-by: Kunihiko Hayashi Acked-by: Masahiro Yamada Thanks! -- Best Regards Masahiro Yamada

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, 2017-08-28 at 08:49 +0200, Greg KH wrote: > On Mon, Aug 28, 2017 at 04:41:27PM +1000, Stephen Rothwell wrote: > > Hi James, > > > > Today's linux-next merge of the scsi tree got a conflict in: > > > > drivers/staging/unisys/visorhba/visorhba_main.c > > > > between commits: > > > >

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, 2017-08-28 at 08:49 +0200, Greg KH wrote: > On Mon, Aug 28, 2017 at 04:41:27PM +1000, Stephen Rothwell wrote: > > Hi James, > > > > Today's linux-next merge of the scsi tree got a conflict in: > > > > drivers/staging/unisys/visorhba/visorhba_main.c > > > > between commits: > > > >

Re: [PATCH] clk: uniphier: add ethernet clock control support

2017-08-28 18:57 GMT+09:00 Kunihiko Hayashi : > Add clock control for ethernet controller on Pro4, PXs2, LD11 and LD20. > > Signed-off-by: Kunihiko Hayashi > --- Acked-by: Masahiro Yamada Thanks!

Re: [PATCH] clk: uniphier: add ethernet clock control support

2017-08-28 18:57 GMT+09:00 Kunihiko Hayashi : > Add clock control for ethernet controller on Pro4, PXs2, LD11 and LD20. > > Signed-off-by: Kunihiko Hayashi > --- Acked-by: Masahiro Yamada Thanks! -- Best Regards Masahiro Yamada

Re: [PATCH] dmaengine: pl08x: constify amba_id

On Wed, Aug 23, 2017 at 09:57:12PM +0530, Arvind Yadav wrote: > amba_id are not supposed to change at runtime. All functions > working with const amba_id. So mark the non-const structs as const. Applied both, thanks -- ~Vinod

Re: [PATCH] dmaengine: pl08x: constify amba_id

On Wed, Aug 23, 2017 at 09:57:12PM +0530, Arvind Yadav wrote: > amba_id are not supposed to change at runtime. All functions > working with const amba_id. So mark the non-const structs as const. Applied both, thanks -- ~Vinod

Re: [PATCH v3 0/3] cpuinfo: implement cpuinfo in sysfs

On Mon, Aug 28, 2017 at 05:29:06PM +0200, Greg KH wrote: > On Wed, Aug 09, 2017 at 07:37:23PM +0200, Felix Schnizlein wrote: > > Make data from current /proc/cpuinfo available in sysfs. > > > > Some parts of /proc/cpuinfo are already accessible through sysfs like > > microcode, topology and cache

Re: [PATCH v3 0/3] cpuinfo: implement cpuinfo in sysfs

On Mon, Aug 28, 2017 at 05:29:06PM +0200, Greg KH wrote: > On Wed, Aug 09, 2017 at 07:37:23PM +0200, Felix Schnizlein wrote: > > Make data from current /proc/cpuinfo available in sysfs. > > > > Some parts of /proc/cpuinfo are already accessible through sysfs like > > microcode, topology and cache

Re: [PATCH v2] eeprom: idt_89hpesx: Support both ACPI and OF probing

On Wed, Aug 09, 2017 at 10:08:46AM +0700, quochuybk2...@gmail.com wrote: > From: Huy Duong > > Allow the idt_89hpesx driver to get information from child nodes from > both OF and ACPI by using more generic fwnode_property_read*() functions. > > Below is an example of

Re: [PATCH v2] eeprom: idt_89hpesx: Support both ACPI and OF probing

On Wed, Aug 09, 2017 at 10:08:46AM +0700, quochuybk2...@gmail.com wrote: > From: Huy Duong > > Allow the idt_89hpesx driver to get information from child nodes from > both OF and ACPI by using more generic fwnode_property_read*() functions. > > Below is an example of instantiating idt_89hpesx

Re: [PATCH v4 3/4] mmc: sdhci: enable/disable the clock in sdhci_pltfm_suspend/resume

> On 23/08/17 07:15, Masahiro Yamada wrote: > > This commit provides similar cleanups as commit 83eacdfa2529 ("mmc: > > sdhci: disable the clock in sdhci_pltfm_unregister()") did for > > unregister hooks. > > > > sdhci-brcmstb.c and sdhci-sirf.c implement their own suspend/resume > > hooks to

Re: [PATCH v4 3/4] mmc: sdhci: enable/disable the clock in sdhci_pltfm_suspend/resume

> On 23/08/17 07:15, Masahiro Yamada wrote: > > This commit provides similar cleanups as commit 83eacdfa2529 ("mmc: > > sdhci: disable the clock in sdhci_pltfm_unregister()") did for > > unregister hooks. > > > > sdhci-brcmstb.c and sdhci-sirf.c implement their own suspend/resume > > hooks to

Re: [3/7,media] dvb: don't use 'time_t' in event ioctl

On Tue, Sep 15, 2015 at 05:49:04PM +0200, Arnd Bergmann wrote: > 'struct video_event' is used for the VIDEO_GET_EVENT ioctl, implemented > by drivers/media/pci/ivtv/ivtv-ioctl.c and > drivers/media/pci/ttpci/av7110_av.c. The structure contains a 'time_t', > which will be redefined in the future to

Re: [3/7,media] dvb: don't use 'time_t' in event ioctl

On Tue, Sep 15, 2015 at 05:49:04PM +0200, Arnd Bergmann wrote: > 'struct video_event' is used for the VIDEO_GET_EVENT ioctl, implemented > by drivers/media/pci/ivtv/ivtv-ioctl.c and > drivers/media/pci/ttpci/av7110_av.c. The structure contains a 'time_t', > which will be redefined in the future to

Re: [PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

On 8/25/2017 7:03 PM, Grygorii Strashko wrote: > > > On 08/25/2017 01:02 PM, Adam Wallis wrote: >> The dma ops from the parent DWC device are not getting passed to the >> child xhci-hcd device. This patch makes use of >> platform_device_register_full to set the DMA ops. For the DT/OF case, >>

Re: [PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

On 8/25/2017 7:03 PM, Grygorii Strashko wrote: > > > On 08/25/2017 01:02 PM, Adam Wallis wrote: >> The dma ops from the parent DWC device are not getting passed to the >> child xhci-hcd device. This patch makes use of >> platform_device_register_full to set the DMA ops. For the DT/OF case, >>

[RFC] ARM: Orion: Check DRAM window size

This is a corresponding change as "PCI: mvebu: Check DRAM window size" applied to the Orion PCIe driver. I don't have the relevant hardware myself, but the patch may still be useful for someone who has. This is completely untested. Signed-off-by: Jan Luebbe ---

[RFC] ARM: Orion: Check DRAM window size

This is a corresponding change as "PCI: mvebu: Check DRAM window size" applied to the Orion PCIe driver. I don't have the relevant hardware myself, but the patch may still be useful for someone who has. This is completely untested. Signed-off-by: Jan Luebbe --- arch/arm/mach-dove/pcie.c| 3

[GIT PULL] arm64: dts: uniphier: UniPhier DT updates (64bit) for v4.14 (2nd)

Hi Arnd, Olof, Sorry for my last-minute pull request. Please pull a little more for the upcoming merge window. Here are some trivial + new SoC support for UniPhier DT (64bit). Please pull! The following changes since commit e5aefb380eafe176de066ddde1d354a167a9d474: arm64: dts: uniphier: add

Re: [PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

On 8/28/2017 9:05 AM, Felipe Balbi wrote: > > Hi, > > Adam Wallis writes: >> The dma ops from the parent DWC device are not getting passed to the >> child xhci-hcd device. This patch makes use of >> platform_device_register_full to set the DMA ops. For the DT/OF case, >>

Re: [PATCH] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

On 8/28/2017 9:05 AM, Felipe Balbi wrote: > > Hi, > > Adam Wallis writes: >> The dma ops from the parent DWC device are not getting passed to the >> child xhci-hcd device. This patch makes use of >> platform_device_register_full to set the DMA ops. For the DT/OF case, >> dma_ops were still null

[GIT PULL] arm64: dts: uniphier: UniPhier DT updates (64bit) for v4.14 (2nd)

Hi Arnd, Olof, Sorry for my last-minute pull request. Please pull a little more for the upcoming merge window. Here are some trivial + new SoC support for UniPhier DT (64bit). Please pull! The following changes since commit e5aefb380eafe176de066ddde1d354a167a9d474: arm64: dts: uniphier: add

Re: [PATCH v3 0/3] cpuinfo: implement cpuinfo in sysfs

On Wed, Aug 09, 2017 at 07:37:23PM +0200, Felix Schnizlein wrote: > Make data from current /proc/cpuinfo available in sysfs. > > Some parts of /proc/cpuinfo are already accessible through sysfs like > microcode, topology and cache info. > Now migrate the rest of worthful cpuinfo data. > > While

Re: [PATCH v3 0/3] cpuinfo: implement cpuinfo in sysfs

On Wed, Aug 09, 2017 at 07:37:23PM +0200, Felix Schnizlein wrote: > Make data from current /proc/cpuinfo available in sysfs. > > Some parts of /proc/cpuinfo are already accessible through sysfs like > microcode, topology and cache info. > Now migrate the rest of worthful cpuinfo data. > > While

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, Aug 28, 2017 at 03:31:16PM +0200, Peter Zijlstra wrote: > On Mon, Aug 28, 2017 at 03:23:06PM +0200, Frederic Weisbecker wrote: > > On Mon, Aug 28, 2017 at 12:09:57PM +0200, Peter Zijlstra wrote: > > > On Wed, Aug 23, 2017 at 03:51:11AM +0200, Frederic Weisbecker wrote: > > > > We want to

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, Aug 28, 2017 at 03:31:16PM +0200, Peter Zijlstra wrote: > On Mon, Aug 28, 2017 at 03:23:06PM +0200, Frederic Weisbecker wrote: > > On Mon, Aug 28, 2017 at 12:09:57PM +0200, Peter Zijlstra wrote: > > > On Wed, Aug 23, 2017 at 03:51:11AM +0200, Frederic Weisbecker wrote: > > > > We want to

Re: [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12

Hi Al. On Mon, Aug 28, 2017 at 05:41:49AM +0100, Al Viro wrote: > On Sun, Aug 06, 2017 at 07:22:03PM +0100, Al Viro wrote: > > > assuming I'll have any sanity left by that time). > > ... and that hope had turned out to be far too optimistic. Ohh, looking forward to what impact this will have

Re: [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12

Hi Al. On Mon, Aug 28, 2017 at 05:41:49AM +0100, Al Viro wrote: > On Sun, Aug 06, 2017 at 07:22:03PM +0100, Al Viro wrote: > > > assuming I'll have any sanity left by that time). > > ... and that hope had turned out to be far too optimistic. Ohh, looking forward to what impact this will have

Re: [PATCH v3] ARM: dts: stm32: change pinctrl bindings definition

Hi Rob, On 08/03/2017 10:21 PM, Rob Herring wrote: On Thu, Jul 27, 2017 at 03:49:53PM +0200, Alexandre Torgue wrote: Initially each pin was declared in "include/dt-bindings/stm32-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was

Re: [PATCH v3] ARM: dts: stm32: change pinctrl bindings definition

Hi Rob, On 08/03/2017 10:21 PM, Rob Herring wrote: On Thu, Jul 27, 2017 at 03:49:53PM +0200, Alexandre Torgue wrote: Initially each pin was declared in "include/dt-bindings/stm32-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was

Re: kvm splat in mmu_spte_clear_track_bits

On 08/27/2017 at 02:35 PM, Adam Borowski wrote: 4.13-rc5 retested fails Crashed only after two hours or so of testing. 4.13-rc4 apparently works It survived several hours of varied tests (like 5 debian-installer runs, a win10 point release upgrade, some hurd package building, openbsd, etc), all

Re: kvm splat in mmu_spte_clear_track_bits

On 08/27/2017 at 02:35 PM, Adam Borowski wrote: 4.13-rc5 retested fails Crashed only after two hours or so of testing. 4.13-rc4 apparently works It survived several hours of varied tests (like 5 debian-installer runs, a win10 point release upgrade, some hurd package building, openbsd, etc), all

[PATCH 2/2] PCI: mvebu: Check DRAM window size

The sum of the DRAM windows may exceed 4GB (at least on Armada XP). Return an error in that case. Signed-off-by: Jan Luebbe --- drivers/pci/host/pci-mvebu.c | 27 ++- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git

[PATCH 2/2] PCI: mvebu: Check DRAM window size

The sum of the DRAM windows may exceed 4GB (at least on Armada XP). Return an error in that case. Signed-off-by: Jan Luebbe --- drivers/pci/host/pci-mvebu.c | 27 ++- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/drivers/pci/host/pci-mvebu.c

[PATCH 1/2] bus: mbus: fix window size calculation for 4GB windows

At least the Armada XP SoC supports 4GB on a single DRAM window. Because the size register values contain the actual size - 1, the MSB is set in that case. For example, the SDRAM window's control register's value is 0xffe1 for 4GB (bits 31 to 24 contain the size). The MBUS driver reads back

[PATCH 1/2] bus: mbus: fix window size calculation for 4GB windows

At least the Armada XP SoC supports 4GB on a single DRAM window. Because the size register values contain the actual size - 1, the MSB is set in that case. For example, the SDRAM window's control register's value is 0xffe1 for 4GB (bits 31 to 24 contain the size). The MBUS driver reads back

[PATCH 0/2] fix 4GB DRAM window support on mvebu

The current MBUS DRAM window calculation fails for 4GB windows because it overflows. This is fixed in the first patch by using u64 instead of u32 to store the size. The second excplicitly checks that we don't try to configure a too large memory window in the pci driver. As they don't depend on

[PATCH 0/2] fix 4GB DRAM window support on mvebu

The current MBUS DRAM window calculation fails for 4GB windows because it overflows. This is fixed in the first patch by using u64 instead of u32 to store the size. The second excplicitly checks that we don't try to configure a too large memory window in the pci driver. As they don't depend on

[GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.14

Hi Arnd, Olof, Sorry for my last-minute pull request. Please pull a little more for the upcoming merge window. Here are some trivial UniPhier DT (32bit) updates. Please pull! The following changes since commit 69f9cdc63319e5ccc210b30d1cec1dfda7096b04: ARM: dts: uniphier: add Denali NAND

[GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.14

Hi Arnd, Olof, Sorry for my last-minute pull request. Please pull a little more for the upcoming merge window. Here are some trivial UniPhier DT (32bit) updates. Please pull! The following changes since commit 69f9cdc63319e5ccc210b30d1cec1dfda7096b04: ARM: dts: uniphier: add Denali NAND

Re: [PATCH linux v5 1/3] drivers: w1: add hwmon support structures

On Mon, Jul 17, 2017 at 04:09:04PM -0700, Jaghathiswari Rankappagounder Natarajan wrote: > This patch has changes to w1.h/w1.c/w1_family.h generic files to > add (optional) hwmon support structures. > > Signed-off-by: Jaghathiswari Rankappagounder Natarajan > Acked-by: Evgeniy

Re: [PATCH linux v5 1/3] drivers: w1: add hwmon support structures

On Mon, Jul 17, 2017 at 04:09:04PM -0700, Jaghathiswari Rankappagounder Natarajan wrote: > This patch has changes to w1.h/w1.c/w1_family.h generic files to > add (optional) hwmon support structures. > > Signed-off-by: Jaghathiswari Rankappagounder Natarajan > Acked-by: Evgeniy Polyakov >

[RFC RESEND tip 5/5] lockdep: Take read/write status in consideration when generate chainkey

Currently, the chainkey of a lock chain is a hash sum of the class_idx of all the held locks, the read/write status are not taken in to consideration while generating the chainkey. This could result into a problem, if we have: P1() { read_lock(B);

[RFC RESEND tip 5/5] lockdep: Take read/write status in consideration when generate chainkey

Currently, the chainkey of a lock chain is a hash sum of the class_idx of all the held locks, the read/write status are not taken in to consideration while generating the chainkey. This could result into a problem, if we have: P1() { read_lock(B);

[RFC RESEND tip 4/5] lockdep: Support deadlock detection for recursive read locks in check_noncircular()

Currently, lockdep only has limit support for deadlock detection for recursive read locks. The basic idea of the detection is: Firstly we add recursive read lock into the graph, so now we have four types of dependency: 1) non-recursive to recursive(NR), 2) non-recursive to non-recursive(NN), 3)

[RFC RESEND tip 4/5] lockdep: Support deadlock detection for recursive read locks in check_noncircular()

Currently, lockdep only has limit support for deadlock detection for recursive read locks. The basic idea of the detection is: Firstly we add recursive read lock into the graph, so now we have four types of dependency: 1) non-recursive to recursive(NR), 2) non-recursive to non-recursive(NN), 3)

Re: Send a large patch right now or is it better to do it later?

On Fri, Jul 28, 2017 at 05:16:56PM +0200, Marcus Wolf wrote: > Hi Greg, > > according to the proposals of Walter Harms, I revised the rf69.c: I replaced > some macros with inline functions and removed some obsolete ifdefs. According > to > walter this will improve the resource situation. In

Re: Send a large patch right now or is it better to do it later?

On Fri, Jul 28, 2017 at 05:16:56PM +0200, Marcus Wolf wrote: > Hi Greg, > > according to the proposals of Walter Harms, I revised the rf69.c: I replaced > some macros with inline functions and removed some obsolete ifdefs. According > to > walter this will improve the resource situation. In

[PATCH 1/2] media:imx274 device tree binding file

From: Leon Luo The binding file for imx274 CMOS sensor V4l2 driver Signed-off-by: Leon Luo Acked-by: Sören Brinkmann --- .../devicetree/bindings/media/i2c/imx274.txt | 32 ++ 1 file

[PATCH 1/2] media:imx274 device tree binding file

From: Leon Luo The binding file for imx274 CMOS sensor V4l2 driver Signed-off-by: Leon Luo Acked-by: Sören Brinkmann --- .../devicetree/bindings/media/i2c/imx274.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644

[RFC RESEND tip 3/5] lockdep: Demagic the return value of BFS

__bfs() could return four magic numbers: 1: search succeeds, but none match. 0: search succeeds, find one match. -1: search fails because of the cq is full. -2: search fails because a invalid node is found. This patch cleans things up by making a enum type for the

[RFC RESEND tip 3/5] lockdep: Demagic the return value of BFS

__bfs() could return four magic numbers: 1: search succeeds, but none match. 0: search succeeds, find one match. -1: search fails because of the cq is full. -2: search fails because a invalid node is found. This patch cleans things up by making a enum type for the

[RFC RESEND tip 1/5] lockdep/selftest: Add a R-L/L-W test case specific to chain cache behavior

As our chain cache doesn't differ read/write locks, so even we can detect a read-lock/lock-write deadlock in check_noncircular(), we can still be fooled if a read-lock/lock-read case(which is not a deadlock) comes first. So introduce this test case to test specific to the chain cache behavior on

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

On Mon, 28 Aug 2017 12:01:21 +0200 Eduardo Otubo wrote: > v2: The script is now a little bit safer so it doesn't conflicts with > network daemon trying to set configurations at the same time. > > This patch fixes the behavior of the hv_set_ifconfig script when setting > the

[RFC RESEND tip 1/5] lockdep/selftest: Add a R-L/L-W test case specific to chain cache behavior

As our chain cache doesn't differ read/write locks, so even we can detect a read-lock/lock-write deadlock in check_noncircular(), we can still be fooled if a read-lock/lock-read case(which is not a deadlock) comes first. So introduce this test case to test specific to the chain cache behavior on

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

On Mon, 28 Aug 2017 12:01:21 +0200 Eduardo Otubo wrote: > v2: The script is now a little bit safer so it doesn't conflicts with > network daemon trying to set configurations at the same time. > > This patch fixes the behavior of the hv_set_ifconfig script when setting > the interface ip.

[RFC RESEND tip 2/5] lockdep/selftest: Add more recursive read related test cases

Add those four test cases: 1. CPU1CPU2CPU3 = = = write_lock(X); write_lock(Y); write_lock(Z); read_lock(Y);

[RFC RESEND tip 2/5] lockdep/selftest: Add more recursive read related test cases

Add those four test cases: 1. CPU1CPU2CPU3 = = = write_lock(X); write_lock(Y); write_lock(Z); read_lock(Y);

[PATCH 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

From: Leon Luo The imx274 is a Sony CMOS image sensor that has 1/2.5 image size. It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface is 4-lane MIPI running at 1.44Gbps each. This driver has been tested on Xilinx ZCU102 platform with a Leopard

[PATCH 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

From: Leon Luo The imx274 is a Sony CMOS image sensor that has 1/2.5 image size. It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface is 4-lane MIPI running at 1.44Gbps each. This driver has been tested on Xilinx ZCU102 platform with a Leopard LI-IMX274MIPI-FMC camera board.

[RFC RESEND tip 0/5] lockdep: Support deadlock detection for recursive read locks

(Resend because getting weird reject, Sorry) Hi Ingo and Peter, As Peter pointed out: https://marc.info/?l=linux-kernel=150349072023540 The lockdep current has a limit support for recursive read locks, the deadlock case as follow could not be detected: read_lock(A);

[RFC RESEND tip 0/5] lockdep: Support deadlock detection for recursive read locks

(Resend because getting weird reject, Sorry) Hi Ingo and Peter, As Peter pointed out: https://marc.info/?l=linux-kernel=150349072023540 The lockdep current has a limit support for recursive read locks, the deadlock case as follow could not be detected: read_lock(A);

Re: [PATCH v5 1/2] sched/clock: interface to allow timestamps early in boot

On Mon, 28 Aug 2017, Pasha Tatashin wrote: > > > +/* > > > + * Called once during to boot to initialize boot time. > > > + */ > > > +void read_boot_clock64(struct timespec64 *ts) > > > > And because its called only once, it does not need to be marked __init() > > and must be kept around forever,

Re: [PATCH v5 1/2] sched/clock: interface to allow timestamps early in boot

On Mon, 28 Aug 2017, Pasha Tatashin wrote: > > > +/* > > > + * Called once during to boot to initialize boot time. > > > + */ > > > +void read_boot_clock64(struct timespec64 *ts) > > > > And because its called only once, it does not need to be marked __init() > > and must be kept around forever,

Re: [PATCH v5 1/2] sched/clock: interface to allow timestamps early in boot

On Mon, 28 Aug 2017, Pasha Tatashin wrote: > This makes sense. Changing order in timekeeping_init(void) should take care of > this: > > Change to: > > void __init timekeeping_init(void) > { > /* >* We must determine boot timestamp before getting current >* persistent

Re: [PATCH v5 1/2] sched/clock: interface to allow timestamps early in boot

On Mon, 28 Aug 2017, Pasha Tatashin wrote: > This makes sense. Changing order in timekeeping_init(void) should take care of > this: > > Change to: > > void __init timekeeping_init(void) > { > /* >* We must determine boot timestamp before getting current >* persistent

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