Re: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()

On Tue, 8 Nov 2016 08:20:48 -0800 Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 8:16 AM, Linus Torvalds > wrote: > > So I definitely approve of the change, but I wonder if we should go > > one step further: > > > > On Mon, Nov 7, 2016 at

Re: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()

On Tue, 8 Nov 2016 08:20:48 -0800 Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 8:16 AM, Linus Torvalds > wrote: > > So I definitely approve of the change, but I wonder if we should go > > one step further: > > > > On Mon, Nov 7, 2016 at 1:26 PM, Steven Rostedt wrote: > > > >> > >>

Re: [Linux-ima-devel] [PATCH v6 03/10] ima: permit duplicate measurement list entries

On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann wrote: > From: Mimi Zohar > > Measurements carried across kexec need to be added to the IMA > measurement list, but should not prevent measurements of the newly > booted kernel from

Re: [Linux-ima-devel] [PATCH v6 03/10] ima: permit duplicate measurement list entries

On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann wrote: > From: Mimi Zohar > > Measurements carried across kexec need to be added to the IMA > measurement list, but should not prevent measurements of the newly > booted kernel from being added to the measurement list. This patch > adds

Re: [Linux-ima-devel] [PATCH v6 02/10] ima: on soft reboot, restore the measurement list

On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann wrote: > From: Mimi Zohar > > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the

Re: [Linux-ima-devel] [PATCH v6 02/10] ima: on soft reboot, restore the measurement list

On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann wrote: > From: Mimi Zohar > > The TPM PCRs are only reset on a hard reboot. In order to validate a > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list > of the running kernel must be saved and restored on boot. This

Re: net/l2tp: use-after-free write in l2tp_ip6_close

Hi Cong, Tried with your patch, still seeing the reports. Thanks! On Tue, Nov 8, 2016 at 12:02 AM, Cong Wang wrote: > On Mon, Nov 7, 2016 at 2:35 PM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while running the

Re: net/l2tp: use-after-free write in l2tp_ip6_close

Hi Cong, Tried with your patch, still seeing the reports. Thanks! On Tue, Nov 8, 2016 at 12:02 AM, Cong Wang wrote: > On Mon, Nov 7, 2016 at 2:35 PM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while running the syzkaller fuzzer: >> >>

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

On Tue, Nov 08, 2016 at 08:21:04PM +0100, Luis R. Rodriguez wrote: > On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > > We have no explicit semantics to check if a driver / subsystem > > > supports

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

On Tue, Nov 08, 2016 at 08:21:04PM +0100, Luis R. Rodriguez wrote: > On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > > We have no explicit semantics to check if a driver / subsystem > > > supports

Re: [PATCH v2] irqchip/renesas-irqc: Postpone driver initialization

On 11/08/2016 11:35 AM, Geert Uytterhoeven wrote: > Currently the renesas-irqc driver uses postcore_initcall(). > > However, the new CPG/MSSR driver uses subsys_initcall(). Hence the > IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to > not find its interrupt on R-Car Gen2

Re: [PATCH v2] irqchip/renesas-irqc: Postpone driver initialization

On 11/08/2016 11:35 AM, Geert Uytterhoeven wrote: > Currently the renesas-irqc driver uses postcore_initcall(). > > However, the new CPG/MSSR driver uses subsys_initcall(). Hence the > IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to > not find its interrupt on R-Car Gen2

Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support

On Tue, Nov 8, 2016 at 11:06 AM, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Kyle Huey wrote: > >> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. >> When enabled, the processor will fault on attempts to execute the CPUID >> instruction with CPL>0.

Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support

On Tue, Nov 8, 2016 at 11:06 AM, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Kyle Huey wrote: > >> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. >> When enabled, the processor will fault on attempts to execute the CPUID >> instruction with CPL>0. This will allow a

[PATCH 2/2] kasan: improve error reports

1. Change header format. 2. Unify header format between different kinds of bad accesses. 3. Add empty lines between parts of the report to improve readability. 4. Improve slab object description. 5. Improve mm/kasan/report.c readability. Signed-off-by: Andrey Konovalov ---

[PATCH 2/2] kasan: improve error reports

1. Change header format. 2. Unify header format between different kinds of bad accesses. 3. Add empty lines between parts of the report to improve readability. 4. Improve slab object description. 5. Improve mm/kasan/report.c readability. Signed-off-by: Andrey Konovalov --- mm/kasan/report.c |

[PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice

Right now print_stack_trace prints timestamp twice, the first time it's done by printk when printing spaces, the second - by print_ip_sym. As a result, stack traces in KASAN reports have double timestamps: [ 18.822232] Allocated by task 3838: [ 18.822232] [ 18.822232] []

[PATCH 0/2] kasan,stacktrace: improve error reports

This patchset improves KASAN reports by making the following changes: 1. Changes header format from: [ 24.247214] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan] at addr 88006bbb38a8 [ 24.247301] Write of size 1 by task insmod/3852 to [ 19.338308] BUG: KASAN:

[PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice

Right now print_stack_trace prints timestamp twice, the first time it's done by printk when printing spaces, the second - by print_ip_sym. As a result, stack traces in KASAN reports have double timestamps: [ 18.822232] Allocated by task 3838: [ 18.822232] [ 18.822232] []

[PATCH 0/2] kasan,stacktrace: improve error reports

This patchset improves KASAN reports by making the following changes: 1. Changes header format from: [ 24.247214] BUG: KASAN: use-after-free in kmalloc_uaf+0xad/0xb9 [test_kasan] at addr 88006bbb38a8 [ 24.247301] Write of size 1 by task insmod/3852 to [ 19.338308] BUG: KASAN:

[PATCH v4 6/8] iio: dpot-dac: DAC driver based on a digital potentiometer

It is assumed that the dpot is used as a voltage divider between the current dpot wiper setting and the maximum resistance of the dpot. The divided voltage is provided by a vref regulator. .--. .---. | | | vref |--'.---. | regulator |--.|

[PATCH v4 6/8] iio: dpot-dac: DAC driver based on a digital potentiometer

It is assumed that the dpot is used as a voltage divider between the current dpot wiper setting and the maximum resistance of the dpot. The divided voltage is provided by a vref regulator. .--. .---. | | | vref |--'.---. | regulator |--.|

[PATCH v4 3/8] iio: mcp4531: provide range of available raw values

Example: $ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available' [0 1 256] Meaning: min 0, step 1 and max 256. Signed-off-by: Peter Rosin --- .../testing/sysfs-bus-iio-potentiometer-mcp4531| 8 ++ MAINTAINERS| 1 +

[PATCH v4 3/8] iio: mcp4531: provide range of available raw values

Example: $ cat '/sys/bus/iio/devices/iio:device0/out_resistance_raw_available' [0 1 256] Meaning: min 0, step 1 and max 256. Signed-off-by: Peter Rosin --- .../testing/sysfs-bus-iio-potentiometer-mcp4531| 8 ++ MAINTAINERS| 1 +

[PATCH v2] irqchip/renesas-irqc: Postpone driver initialization

Currently the renesas-irqc driver uses postcore_initcall(). However, the new CPG/MSSR driver uses subsys_initcall(). Hence the IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to not find its interrupt on R-Car Gen2 and RZ/G, as the of_mdio subsystem does not support deferred

[PATCH v2] irqchip/renesas-irqc: Postpone driver initialization

Currently the renesas-irqc driver uses postcore_initcall(). However, the new CPG/MSSR driver uses subsys_initcall(). Hence the IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to not find its interrupt on R-Car Gen2 and RZ/G, as the of_mdio subsystem does not support deferred

[PATCH v4 4/8] dt-bindings: add axentia to vendor-prefixes

Acked-by: Rob Herring Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH v4 4/8] dt-bindings: add axentia to vendor-prefixes

Acked-by: Rob Herring Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen wrote: > On Nov 8 09:16, Hisashi T Fujinaka wrote: >> On Tue, 8 Nov 2016, Corinna Vinschen wrote: >> > On Nov 8 15:06, Cao jin wrote: >> > > When running as guest, under certain condition, it will oops as >> > > following.

Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen wrote: > On Nov 8 09:16, Hisashi T Fujinaka wrote: >> On Tue, 8 Nov 2016, Corinna Vinschen wrote: >> > On Nov 8 15:06, Cao jin wrote: >> > > When running as guest, under certain condition, it will oops as >> > > following. >> > > writel() in

Re: [PATCH 5/6] mm: workingset: switch shadow entry tracking to radix tree exceptional counting

On Tue, Nov 08, 2016 at 11:27:16AM +0100, Jan Kara wrote: > On Mon 07-11-16 14:07:40, Johannes Weiner wrote: > > Currently, we track the shadow entries in the page cache in the upper > > bits of the radix_tree_node->count, behind the back of the radix tree > > implementation. Because the radix

Re: [PATCH 5/6] mm: workingset: switch shadow entry tracking to radix tree exceptional counting

On Tue, Nov 08, 2016 at 11:27:16AM +0100, Jan Kara wrote: > On Mon 07-11-16 14:07:40, Johannes Weiner wrote: > > Currently, we track the shadow entries in the page cache in the upper > > bits of the radix_tree_node->count, behind the back of the radix tree > > implementation. Because the radix

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 07:05 PM, Peter Zijlstra wrote: >> > >> > I know what we want to do, but there's some momentous problems that >> > need to be solved first. > Like what? The problem is that using RT_RUNTIME_SHARE a CPU will almost always borrow enough runtime to make a CPU intensive rt task to

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 07:05 PM, Peter Zijlstra wrote: >> > >> > I know what we want to do, but there's some momentous problems that >> > need to be solved first. > Like what? The problem is that using RT_RUNTIME_SHARE a CPU will almost always borrow enough runtime to make a CPU intensive rt task to

RE: [Resend] [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, November 7, 2016 11:00 PM > To: Long Li > Cc: KY Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas ; >

RE: [Resend] [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, November 7, 2016 11:00 PM > To: Long Li > Cc: KY Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas ; > de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux- > p...@vger.kernel.org > Subject:

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

On 08/11/2016 10:32 πμ, Viresh Kumar wrote: > On 8 November 2016 at 12:49, Stratos Karafotis wrote: >> I think we shouldn't. That's why the patch first decreases the frequency >> by n freq steps (where n the number of deferred periods). >> Then the normal processing takes

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

On 08/11/2016 10:32 πμ, Viresh Kumar wrote: > On 8 November 2016 at 12:49, Stratos Karafotis wrote: >> I think we shouldn't. That's why the patch first decreases the frequency >> by n freq steps (where n the number of deferred periods). >> Then the normal processing takes place. > > The problem

Re: [RFC][ATCH 3/3] syscalls: Remove start and number from syscall_get_arguments() args

On Mon, 7 Nov 2016 15:54:14 -0800 Andy Lutomirski wrote: > On Mon, Nov 7, 2016 at 1:26 PM, Steven Rostedt wrote: > > From: Steven Rostedt > > > > > diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h > >

Re: [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver

On Tue, Nov 8, 2016 at 1:00 PM, Paul Gortmaker wrote: > On Mon, Sep 19, 2016 at 1:47 PM, Frank Li wrote: >> From: Zhengyu Shen >> >> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64 >> and LPDDR2 two

Re: [RFC][ATCH 3/3] syscalls: Remove start and number from syscall_get_arguments() args

On Mon, 7 Nov 2016 15:54:14 -0800 Andy Lutomirski wrote: > On Mon, Nov 7, 2016 at 1:26 PM, Steven Rostedt wrote: > > From: Steven Rostedt > > > > > diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h > > index e3c95e8e61c5..050891169b51 100644 > > ---

Re: [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver

On Tue, Nov 8, 2016 at 1:00 PM, Paul Gortmaker wrote: > On Mon, Sep 19, 2016 at 1:47 PM, Frank Li wrote: >> From: Zhengyu Shen >> >> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64 >> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high >>

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > We have no explicit semantics to check if a driver / subsystem > > supports deferred probe. > > Why would we need such a thing? It depends on the impact of

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > We have no explicit semantics to check if a driver / subsystem > > supports deferred probe. > > Why would we need such a thing? It depends on the impact of

Re: [PATCH 2/2] ARM: dts: apq8064: add support to pm8821

On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote: > Signed-off-by: Srinivas Kandagatla > --- > arch/arm/boot/dts/qcom-apq8064.dtsi | 28 > 1 file changed, 28 insertions(+) > > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi

Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops

On Wed, 9 Nov 2016 00:17:53 +0530 Kirti Wankhede wrote: > On 11/8/2016 10:09 PM, Alex Williamson wrote: > > On Tue, 8 Nov 2016 19:25:35 +0530 > > Kirti Wankhede wrote: > > > ... > > - > +int (*pin_pages)(void

Re: [PATCH 2/2] ARM: dts: apq8064: add support to pm8821

On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote: > Signed-off-by: Srinivas Kandagatla > --- > arch/arm/boot/dts/qcom-apq8064.dtsi | 28 > 1 file changed, 28 insertions(+) > > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi >

Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops

On Wed, 9 Nov 2016 00:17:53 +0530 Kirti Wankhede wrote: > On 11/8/2016 10:09 PM, Alex Williamson wrote: > > On Tue, 8 Nov 2016 19:25:35 +0530 > > Kirti Wankhede wrote: > > > ... > > - > +int (*pin_pages)(void *iommu_data, unsigned long > *user_pfn, >

KASAN & the vmalloc area

Hi, I see a while back [1] there was a discussion of what to do about KASAN and vmapped stacks, but it doesn't look like that was solved, judging by the vmapped stacks pull [2] for v4.9. I wondered whether anyone had looked at that since? I have an additional reason to want to dynamically

KASAN & the vmalloc area

Hi, I see a while back [1] there was a discussion of what to do about KASAN and vmapped stacks, but it doesn't look like that was solved, judging by the vmapped stacks pull [2] for v4.9. I wondered whether anyone had looked at that since? I have an additional reason to want to dynamically

Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support

On Tue, 8 Nov 2016, Kyle Huey wrote: > Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. > When enabled, the processor will fault on attempts to execute the CPUID > instruction with CPL>0. This will allow a ptracer to emulate the CPUID > instruction. > > Bit 31 of

Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support

On Tue, 8 Nov 2016, Kyle Huey wrote: > Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. > When enabled, the processor will fault on attempts to execute the CPUID > instruction with CPL>0. This will allow a ptracer to emulate the CPUID > instruction. > > Bit 31 of

Re: Summary of LPC guest MSI discussion in Santa Fe

On Tue, Nov 08, 2016 at 02:02:39PM -0500, Don Dutile wrote: > On 11/08/2016 12:54 PM, Will Deacon wrote: > >A first step would be making all this opt-in, and only supporting GICv3 > >ITS for now. > You're trying to support a config that is < GICv3 and no ITS ? ... > That would be the equiv. of x86

Re: Summary of LPC guest MSI discussion in Santa Fe

On Tue, Nov 08, 2016 at 02:02:39PM -0500, Don Dutile wrote: > On 11/08/2016 12:54 PM, Will Deacon wrote: > >A first step would be making all this opt-in, and only supporting GICv3 > >ITS for now. > You're trying to support a config that is < GICv3 and no ITS ? ... > That would be the equiv. of x86

Re: [RFC v3 1/6] Track the active utilisation

Hi again, On Tue, 8 Nov 2016 18:53:09 + Juri Lelli wrote: [...] > > > Also, AFAIU, do_exit() works on current and the TASK_DEAD case is > > > handled in finish_task_switch(), so I don't think we are taking > > > care of the "task is dying" condition. > > Ok, so I am

Re: [RFC v3 1/6] Track the active utilisation

Hi again, On Tue, 8 Nov 2016 18:53:09 + Juri Lelli wrote: [...] > > > Also, AFAIU, do_exit() works on current and the TASK_DEAD case is > > > handled in finish_task_switch(), so I don't think we are taking > > > care of the "task is dying" condition. > > Ok, so I am missing something... The

Re: [PATCH v4 1/3] leds: Introduce userspace leds driver

On 11/8/16 5:26 AM, Jacek Anaszewski wrote: Hi David, +struct uleds_device { +struct uleds_user_devuser_dev; +struct led_classdevled_cdev; +struct mutexmutex; +enum uleds_statestate; +wait_queue_head_twaitq; +unsigned charbrightness;

Re: [PATCH v4 1/3] leds: Introduce userspace leds driver

On 11/8/16 5:26 AM, Jacek Anaszewski wrote: Hi David, +struct uleds_device { +struct uleds_user_devuser_dev; +struct led_classdevled_cdev; +struct mutexmutex; +enum uleds_statestate; +wait_queue_head_twaitq; +unsigned charbrightness;

Re: [PATCH net-next v4] cadence: Add LSO support.

On 11/08/2016 05:41 AM, Rafal Ozieblo wrote: > New Cadence GEM hardware support Large Segment Offload (LSO): > TCP segmentation offload (TSO) as well as UDP fragmentation > offload (UFO). Support for those features was added to the driver. > > Signed-off-by: Rafal Ozieblo >

Re: [PATCH net-next v4] cadence: Add LSO support.

On 11/08/2016 05:41 AM, Rafal Ozieblo wrote: > New Cadence GEM hardware support Large Segment Offload (LSO): > TCP segmentation offload (TSO) as well as UDP fragmentation > offload (UFO). Support for those features was added to the driver. > > Signed-off-by: Rafal Ozieblo > --- > -#define

Re: [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams

Hi Sören, On Tue, Nov 8, 2016 at 10:32 AM, Sören Brinkmann wrote: > On Sun, 2016-11-06 at 17:13:25 -0700, Moritz Fischer wrote: >> Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching >> capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly >> decryption of

Re: [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams

Hi Sören, On Tue, Nov 8, 2016 at 10:32 AM, Sören Brinkmann wrote: > On Sun, 2016-11-06 at 17:13:25 -0700, Moritz Fischer wrote: >> Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching >> capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly >> decryption of an encrypted bitstream. >>

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

On 11/02/2016 04:48 AM, Suresh Mangipudi wrote: Add GPIO driver for T186 based platforms. Adds support for MAIN and AON GPIO's from T186. I'm not sure how you/Thierry will approach merging this with the other GPIO driver he has, but here's a very quick review of this one in case it's useful.

Re: [PATCH 1/2] mfd: pm8921: add support to pm8821

On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote: > This patch adds support to PM8821 PMIC and interrupt support. > PM8821 is companion device that supplements primary PMIC PM8921 IC. > Linus Walleij has a patch out for renaming a lot of things in this file, so we should probably make

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

On 11/02/2016 04:48 AM, Suresh Mangipudi wrote: Add GPIO driver for T186 based platforms. Adds support for MAIN and AON GPIO's from T186. I'm not sure how you/Thierry will approach merging this with the other GPIO driver he has, but here's a very quick review of this one in case it's useful.

Re: [PATCH 1/2] mfd: pm8921: add support to pm8821

On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote: > This patch adds support to PM8821 PMIC and interrupt support. > PM8821 is companion device that supplements primary PMIC PM8921 IC. > Linus Walleij has a patch out for renaming a lot of things in this file, so we should probably make

[PATCH 1/2] USB: ohci: da8xx: Remove ohci platform callbacks

Now that all ohci users are are using a regulator, we can remove the platform callbacks and data. potpgt is no longer necessary as a power on delay time can be specified for the regulator itself. Signed-off-by: Axel Haslam --- drivers/usb/host/ohci-da8xx.c |

[PATCH 2/2] USB: ohci: da8xx: use a flag instead of mask for ocic

Now that the platform callback is removed, we can move the over current indictor changed flag to the private data structure. Since the driver only handles a single port, there is no need for ocic to be a mask, we can use a simple flag instead. Signed-off-by: Axel Haslam

[PATCH 1/2] USB: ohci: da8xx: Remove ohci platform callbacks

Now that all ohci users are are using a regulator, we can remove the platform callbacks and data. potpgt is no longer necessary as a power on delay time can be specified for the regulator itself. Signed-off-by: Axel Haslam --- drivers/usb/host/ohci-da8xx.c | 84

[PATCH 2/2] USB: ohci: da8xx: use a flag instead of mask for ocic

Now that the platform callback is removed, we can move the over current indictor changed flag to the private data structure. Since the driver only handles a single port, there is no need for ocic to be a mask, we can use a simple flag instead. Signed-off-by: Axel Haslam ---

[PATCH 0/2] [PART 3/4] USB: ohci-da8xx: Remove platform callbacks

There are no more users of the platform callbacks as all of them have been converted to use a regulator. We can now remove the plafrom callbacks from the driver and the platform data structure. DEPENDENCIES: 1. [PATCH 0/3] fix ohci phy name https://lkml.org/lkml/2016/11/2/208 2. [PATCH/RFC v2

[PATCH 0/2] [PART 3/4] USB: ohci-da8xx: Remove platform callbacks

There are no more users of the platform callbacks as all of them have been converted to use a regulator. We can now remove the plafrom callbacks from the driver and the platform data structure. DEPENDENCIES: 1. [PATCH 0/3] fix ohci phy name https://lkml.org/lkml/2016/11/2/208 2. [PATCH/RFC v2

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/08/2016 12:54 PM, Will Deacon wrote: On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote: On 08/11/2016 03:45, Will Deacon wrote: Rather than treat these as separate problems, a better interface is to tell userspace about a set of reserved regions, and have this include the MSI

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/08/2016 12:54 PM, Will Deacon wrote: On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote: On 08/11/2016 03:45, Will Deacon wrote: Rather than treat these as separate problems, a better interface is to tell userspace about a set of reserved regions, and have this include the MSI

[PATCH 1/3] ARM: davinci: da830: Handle vbus with a regulator

The usb driver can now take a regulator instead of the platform callbacks for vbus handling. Lets use a regulator so we can remove the callbacks in a later patch. Signed-off-by: Axel Haslam --- arch/arm/mach-davinci/board-da830-evm.c | 108 +++-

[PATCH 1/3] ARM: davinci: da830: Handle vbus with a regulator

The usb driver can now take a regulator instead of the platform callbacks for vbus handling. Lets use a regulator so we can remove the callbacks in a later patch. Signed-off-by: Axel Haslam --- arch/arm/mach-davinci/board-da830-evm.c | 108 +++- 1 file changed, 38

[PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios

The hawk board VBUS is fixed to a 5v source, and the over current pin is actually not connected to the SoC. Do not reseve these gpios for OHCI as they are not related to usb. Signed-off-by: Axel Haslam --- arch/arm/mach-davinci/board-omapl138-hawk.c | 99

[PATCH 3/3] ARM: davinci: remove ohci platform usage

As all users of ohci platform data have been converted to use a regulator, we dont need to pass platform data to register the ohci device anymore. Signed-off-by: Axel Haslam --- arch/arm/mach-davinci/board-da830-evm.c | 2 +- arch/arm/mach-davinci/board-omapl138-hawk.c

[PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios

The hawk board VBUS is fixed to a 5v source, and the over current pin is actually not connected to the SoC. Do not reseve these gpios for OHCI as they are not related to usb. Signed-off-by: Axel Haslam --- arch/arm/mach-davinci/board-omapl138-hawk.c | 99 ++--- 1 file

[PATCH 3/3] ARM: davinci: remove ohci platform usage

As all users of ohci platform data have been converted to use a regulator, we dont need to pass platform data to register the ohci device anymore. Signed-off-by: Axel Haslam --- arch/arm/mach-davinci/board-da830-evm.c | 2 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-

[PATCH V2] perf/x86: add more Intel uncore IMC PCI IDs for SkyLake

From: Kan Liang Several uncore IMC PCI IDs are missed for Intel SkyLake. Adds the PCI IDs for SkyLake Y, U, H and S platforms. Rename the ID macros for 0x191f and 0x190c. The issue has been logged in the kernel org bugzilla. The bug id is 187301.

[PATCH V2] perf/x86: add more Intel uncore IMC PCI IDs for SkyLake

From: Kan Liang Several uncore IMC PCI IDs are missed for Intel SkyLake. Adds the PCI IDs for SkyLake Y, U, H and S platforms. Rename the ID macros for 0x191f and 0x190c. The issue has been logged in the kernel org bugzilla. The bug id is 187301.

Re: [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver

On Mon, Sep 19, 2016 at 1:47 PM, Frank Li wrote: > From: Zhengyu Shen > > MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64 > and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high > performance, and optimized. MMDC

[PATCH 0/3] [PART 4/4] USB: ohci-da8xx: Add DT support

This series defines the bindings and adds device tree support for the davinci OHCI driver. DEPENDENCIES: 1. [PATCH 0/3] fix ohci phy name https://lkml.org/lkml/2016/11/2/208 2. [PATCH/RFC v2 0/3] regulator: handling of error conditions for usb drivers https://lkml.org/lkml/2016/11/3/188 3. [PATCH

[PATCH v4 1/3] USB: ohci: da8xx: use ohci priv data instead of globals

Instead of global variables, use the extra_priv_size of the ohci driver. We cannot yet move the ocic mask because this is used on the interrupt handler which is registerded through platform data and does not have an hcd pointer. This will be moved on a later patch. Signed-off-by: Axel Haslam

[PATCH 3/3] ARM: dts: da850: add usb device node

This adds the ohci device node for the da850 soc. It also enables it for the omapl138 hawk board. Signed-off-by: Axel Haslam --- arch/arm/boot/dts/da850-lcdk.dts | 8 arch/arm/boot/dts/da850.dtsi | 8 2 files changed, 16 insertions(+) diff --git

Re: [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver

On Mon, Sep 19, 2016 at 1:47 PM, Frank Li wrote: > From: Zhengyu Shen > > MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64 > and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high > performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6 >

[PATCH 0/3] [PART 4/4] USB: ohci-da8xx: Add DT support

This series defines the bindings and adds device tree support for the davinci OHCI driver. DEPENDENCIES: 1. [PATCH 0/3] fix ohci phy name https://lkml.org/lkml/2016/11/2/208 2. [PATCH/RFC v2 0/3] regulator: handling of error conditions for usb drivers https://lkml.org/lkml/2016/11/3/188 3. [PATCH

[PATCH v4 1/3] USB: ohci: da8xx: use ohci priv data instead of globals

Instead of global variables, use the extra_priv_size of the ohci driver. We cannot yet move the ocic mask because this is used on the interrupt handler which is registerded through platform data and does not have an hcd pointer. This will be moved on a later patch. Signed-off-by: Axel Haslam

[PATCH 3/3] ARM: dts: da850: add usb device node

This adds the ohci device node for the da850 soc. It also enables it for the omapl138 hawk board. Signed-off-by: Axel Haslam --- arch/arm/boot/dts/da850-lcdk.dts | 8 arch/arm/boot/dts/da850.dtsi | 8 2 files changed, 16 insertions(+) diff --git

[PATCH v4 2/3] USB: ohci: da8xx: Prepare to remove platform callbacks

Wrap the platform data callbacks into separate functions. This will help migrate to using a regulator by providing a well defined place to implement the regulator functions while the platform calls are still in place and users have not been converted. The platform callbacks will be removed on a

[PATCH 2/3] USB: ohci: da8xx: Allow probing from DT

This adds the compatible string to the ohci driver to be able to probe from DT Signed-off-by: Axel Haslam --- drivers/usb/host/ohci-da8xx.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c index

[PATCH v4 2/3] USB: ohci: da8xx: Prepare to remove platform callbacks

Wrap the platform data callbacks into separate functions. This will help migrate to using a regulator by providing a well defined place to implement the regulator functions while the platform calls are still in place and users have not been converted. The platform callbacks will be removed on a

[PATCH 2/3] USB: ohci: da8xx: Allow probing from DT

This adds the compatible string to the ohci driver to be able to probe from DT Signed-off-by: Axel Haslam --- drivers/usb/host/ohci-da8xx.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c index 83b182e..bbfe342 100644 ---

[PATCH 0/3] [PART 2/4] ARM: davinci: OHCI: Use a regulator instead of callbacks

With the ultimate goal to able to probe the ohci driver form DT, convert users of OHCI pdata to use a regulator instead of passing platform function pointers. This will help to remove the platform callbacks in a future series. DEPENDENCIES: 1. [PATCH 0/3] fix ohci phy name

[PATCH v4 3/3] USB: ohci: da8xx: Allow a regulator to handle VBUS

We need to remove the platform callbacks to be able to probe the driver using device tree. Using a regulator to handle VBUS will eliminate the need for these callbacks once all users are converted to use a regulator. The regulator equivalents to the platform callbacks are: set_power ->

[PATCH 0/3] [PART 2/4] ARM: davinci: OHCI: Use a regulator instead of callbacks

With the ultimate goal to able to probe the ohci driver form DT, convert users of OHCI pdata to use a regulator instead of passing platform function pointers. This will help to remove the platform callbacks in a future series. DEPENDENCIES: 1. [PATCH 0/3] fix ohci phy name

[PATCH v4 3/3] USB: ohci: da8xx: Allow a regulator to handle VBUS

We need to remove the platform callbacks to be able to probe the driver using device tree. Using a regulator to handle VBUS will eliminate the need for these callbacks once all users are converted to use a regulator. The regulator equivalents to the platform callbacks are: set_power ->

[PATCH v3] USB hub_probe: rework ugly goto-into-compound-statement

Rework smelling code (goto inside compound statement). Perhaps this is legacy. Anyway such code is not appropriate for Linux kernel. Changes since v2: extract the code to static function Changes since v1: fix spaces instead of tab, add missing 'Signed-off-by' Signed-off-by: Eugene Korenevsky

[PATCH v3] USB hub_probe: rework ugly goto-into-compound-statement

Rework smelling code (goto inside compound statement). Perhaps this is legacy. Anyway such code is not appropriate for Linux kernel. Changes since v2: extract the code to static function Changes since v1: fix spaces instead of tab, add missing 'Signed-off-by' Signed-off-by: Eugene Korenevsky

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