Re: WMI and Kernel:User interface

On Tuesday 13 June 2017 19:40:27 Darren Hart wrote: > On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote: > > On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > > > I'll mention this again I suspect in this thread, but rather than > > > a "WMI filter" we can implement a "WMI proxy". If

Re: WMI and Kernel:User interface

On Tuesday 13 June 2017 19:40:27 Darren Hart wrote: > On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote: > > On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > > > I'll mention this again I suspect in this thread, but rather than > > > a "WMI filter" we can implement a "WMI proxy". If

Re: [PATCH v3] ASoC: sgtl5000: add avc support

On Tue, Jun 13, 2017 at 08:57:34AM +0200, Richard Leitner wrote: > +static int avc_put_threshold(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); > + int db; > + u16

Re: [PATCH v3] ASoC: sgtl5000: add avc support

On Tue, Jun 13, 2017 at 08:57:34AM +0200, Richard Leitner wrote: > +static int avc_put_threshold(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); > + int db; > + u16

Re: [PATCH v11 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

On 06/13/2017 10:56 AM, Michael S. Tsirkin wrote: >> +/* The size of one page_bmap used to record inflated/deflated pages. */ >> +#define VIRTIO_BALLOON_PAGE_BMAP_SIZE (8 * PAGE_SIZE) > At this size, you probably want alloc_pages to avoid kmalloc > overhead. For slub, at least, kmalloc()

Re: [PATCH v11 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

On 06/13/2017 10:56 AM, Michael S. Tsirkin wrote: >> +/* The size of one page_bmap used to record inflated/deflated pages. */ >> +#define VIRTIO_BALLOON_PAGE_BMAP_SIZE (8 * PAGE_SIZE) > At this size, you probably want alloc_pages to avoid kmalloc > overhead. For slub, at least, kmalloc()

[PATCH V2 2/2] powerpc/powernv : Add support for OPAL-OCC command/response interface

In P9, OCC (On-Chip-Controller) supports shared memory based commad-response interface. Within the shared memory there is an OPAL command buffer and OCC response buffer that can be used to send inband commands to OCC. This patch adds a platform driver to support the command/response interface

[PATCH V2 0/2] Add support for OCC command/response interface

In P9, OCC(On Chip Controller) can be sent commands inband via shared memory based command response interface. This patch adds a platform driver to support the OCC command-response interface. The skiboot patch for the interface is posted here:

[PATCH V2 2/2] powerpc/powernv : Add support for OPAL-OCC command/response interface

In P9, OCC (On-Chip-Controller) supports shared memory based commad-response interface. Within the shared memory there is an OPAL command buffer and OCC response buffer that can be used to send inband commands to OCC. This patch adds a platform driver to support the command/response interface

[PATCH V2 0/2] Add support for OCC command/response interface

In P9, OCC(On Chip Controller) can be sent commands inband via shared memory based command response interface. This patch adds a platform driver to support the OCC command-response interface. The skiboot patch for the interface is posted here:

Re: [PATCH 04/12] coresight: Add support for reading 64bit registers

On 13/06/17 18:45, Mathieu Poirier wrote: On Mon, Jun 12, 2017 at 03:36:43PM +0100, Suzuki K Poulose wrote: Add support for reading a lower and upper 32bits of a register as a single 64bit register. Cc: Mathieu Poirier Signed-off-by: Suzuki K Poulose

Re: [PATCH 04/12] coresight: Add support for reading 64bit registers

On 13/06/17 18:45, Mathieu Poirier wrote: On Mon, Jun 12, 2017 at 03:36:43PM +0100, Suzuki K Poulose wrote: Add support for reading a lower and upper 32bits of a register as a single 64bit register. Cc: Mathieu Poirier Signed-off-by: Suzuki K Poulose Just a few cosmetic details... Will

[PATCH V2 1/2] powerpc/powernv: Get a unique token for async completions

This patch adds support to get a unique token for async completion requests. This will be used for creating non-repititive request handles for consecutive requests in OPAL-OCC command/response interface. Signed-off-by: Shilpasri G Bhat --- No changes from V1

[PATCH V2 1/2] powerpc/powernv: Get a unique token for async completions

This patch adds support to get a unique token for async completion requests. This will be used for creating non-repititive request handles for consecutive requests in OPAL-OCC command/response interface. Signed-off-by: Shilpasri G Bhat --- No changes from V1 arch/powerpc/include/asm/opal.h

Re: [PATCH 01/12] coresight replicator: Cleanup programmable replicator naming

On 13/06/17 17:55, Mathieu Poirier wrote: On Mon, Jun 12, 2017 at 03:36:40PM +0100, Suzuki K Poulose wrote: The Linux coresight drivers define the programmable ATB replicator as Qualcom replicator, while this is designed by ARM. This can cause confusion to a user selecting the driver. Cleanup

Re: [PATCH v11 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

On Fri, Jun 09, 2017 at 06:41:38PM +0800, Wei Wang wrote: > Add a new feature, VIRTIO_BALLOON_F_PAGE_CHUNKS, which enables > the transfer of the ballooned (i.e. inflated/deflated) pages in > chunks to the host. so now these chunks are just s/g list entry. So let's rename this VIRTIO_BALLOON_F_SG

Re: [PATCH 01/12] coresight replicator: Cleanup programmable replicator naming

On 13/06/17 17:55, Mathieu Poirier wrote: On Mon, Jun 12, 2017 at 03:36:40PM +0100, Suzuki K Poulose wrote: The Linux coresight drivers define the programmable ATB replicator as Qualcom replicator, while this is designed by ARM. This can cause confusion to a user selecting the driver. Cleanup

Re: [PATCH v11 3/6] virtio-balloon: VIRTIO_BALLOON_F_PAGE_CHUNKS

On Fri, Jun 09, 2017 at 06:41:38PM +0800, Wei Wang wrote: > Add a new feature, VIRTIO_BALLOON_F_PAGE_CHUNKS, which enables > the transfer of the ballooned (i.e. inflated/deflated) pages in > chunks to the host. so now these chunks are just s/g list entry. So let's rename this VIRTIO_BALLOON_F_SG

Re: [PATCH][netdev-next] net: hns: make guid hns_dsaf_acpi_dsm_guid static

From: Colin King Date: Tue, 13 Jun 2017 14:03:21 +0100 > From: Colin Ian King > > The guid hns_dsaf_acpi_dsm_guid does not need to be in global > scope, so make it static. > > Cleans up sparse warning: > "symbol 'hns_dsaf_acpi_dsm_guid' was

Re: [PATCH][netdev-next] net: hns: make guid hns_dsaf_acpi_dsm_guid static

From: Colin King Date: Tue, 13 Jun 2017 14:03:21 +0100 > From: Colin Ian King > > The guid hns_dsaf_acpi_dsm_guid does not need to be in global > scope, so make it static. > > Cleans up sparse warning: > "symbol 'hns_dsaf_acpi_dsm_guid' was not declared. Should it be static?" > >

Re: [PATCH 03/12] coresight: Extend the PIDR mask to cover relevant bits in PIDR2

On 13/06/17 18:53, Mathieu Poirier wrote: On Mon, Jun 12, 2017 at 03:36:42PM +0100, Suzuki K Poulose wrote: As per coresight standards, PIDR2 register has the following format : [2-0] - JEP106_bits6to4 [3]- JEDEC, designer ID is specified by JEDEC. However some of the drivers only use

Re: [PATCH 03/12] coresight: Extend the PIDR mask to cover relevant bits in PIDR2

On 13/06/17 18:53, Mathieu Poirier wrote: On Mon, Jun 12, 2017 at 03:36:42PM +0100, Suzuki K Poulose wrote: As per coresight standards, PIDR2 register has the following format : [2-0] - JEP106_bits6to4 [3]- JEDEC, designer ID is specified by JEDEC. However some of the drivers only use

[PATCH 2/2] power: supply: sbs-battery: Don't needlessly set CAPACITY_MODE

According to the smart battery spec (1), the CAPACITY_MODE bit does not influence the value read from RelativeStateOfCharge(), so don't bother changing CAPACITY_MODE when doing such a read. (1) - Smart Battery Data Specification, Rev 1.1, Dec. 11, 1998 Signed-off-by: Shawn Nematbakhsh

Re: [PATCH 03/12] coresight: Extend the PIDR mask to cover relevant bits in PIDR2

On Mon, Jun 12, 2017 at 03:36:42PM +0100, Suzuki K Poulose wrote: > As per coresight standards, PIDR2 register has the following format : > > [2-0]- JEP106_bits6to4 > [3] - JEDEC, designer ID is specified by JEDEC. > > However some of the drivers only use mask of 0x3 for the PIDR2

[PATCH 2/2] power: supply: sbs-battery: Don't needlessly set CAPACITY_MODE

According to the smart battery spec (1), the CAPACITY_MODE bit does not influence the value read from RelativeStateOfCharge(), so don't bother changing CAPACITY_MODE when doing such a read. (1) - Smart Battery Data Specification, Rev 1.1, Dec. 11, 1998 Signed-off-by: Shawn Nematbakhsh ---

Re: [PATCH 03/12] coresight: Extend the PIDR mask to cover relevant bits in PIDR2

On Mon, Jun 12, 2017 at 03:36:42PM +0100, Suzuki K Poulose wrote: > As per coresight standards, PIDR2 register has the following format : > > [2-0]- JEP106_bits6to4 > [3] - JEDEC, designer ID is specified by JEDEC. > > However some of the drivers only use mask of 0x3 for the PIDR2

[PATCH 1/2] power: supply: sbs-battery: Prevent CAPACITY_MODE races

A subset of smart battery commands return charge or energy depending on the CAPACITY_MODE bit setting of BatteryMode(). In order to unambiguously read a charge or energy value, it is necessary to ensure that CAPACITY_MODE is set as desired, and not changed for the duration of the attribute read.

[PATCH 1/2] power: supply: sbs-battery: Prevent CAPACITY_MODE races

A subset of smart battery commands return charge or energy depending on the CAPACITY_MODE bit setting of BatteryMode(). In order to unambiguously read a charge or energy value, it is necessary to ensure that CAPACITY_MODE is set as desired, and not changed for the duration of the attribute read.

Re: [PATCH] Add printk for bonding module packets_per_slave parameter

On 13/06/17 20:00, Joe Perches wrote: > On Tue, 2017-06-13 at 12:42 -0400, Jonathan Toppins wrote: >> On 06/13/2017 12:21 PM, Joe Perches wrote: >>> On Tue, 2017-06-13 at 11:34 -0400, David Miller wrote: From: Michael Dilmore Date: Tue, 13 Jun 2017 14:42:46

Re: [PATCH] Add printk for bonding module packets_per_slave parameter

On 13/06/17 20:00, Joe Perches wrote: > On Tue, 2017-06-13 at 12:42 -0400, Jonathan Toppins wrote: >> On 06/13/2017 12:21 PM, Joe Perches wrote: >>> On Tue, 2017-06-13 at 11:34 -0400, David Miller wrote: From: Michael Dilmore Date: Tue, 13 Jun 2017 14:42:46 +0100 > The packets

Re: Lockdep splat with tc filter on 4.11

On Tue, Jun 13, 2017 at 10:28 AM, Laura Abbott wrote: > Hi, > > Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626 > of a hang on 4.11.3 with lockdep splat: > > [ 129.100206] BUG: sleeping function called from invalid context at > mm/slab.h:432 > [

Re: Lockdep splat with tc filter on 4.11

On Tue, Jun 13, 2017 at 10:28 AM, Laura Abbott wrote: > Hi, > > Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626 > of a hang on 4.11.3 with lockdep splat: > > [ 129.100206] BUG: sleeping function called from invalid context at > mm/slab.h:432 > [ 129.100237]

Re: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi

On Tue, Jun 13, 2017 at 01:25:43PM +0800, Jeffy Chen wrote: > The cros_ec requires CS line to be active after last message. But the CS > would be toggled when powering off/on rockchip spi, which breaks ec xfer. > Use GPIO CS to prevent that. I suppose this change is fine. (At least, I don't have

Re: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi

On Tue, Jun 13, 2017 at 01:25:43PM +0800, Jeffy Chen wrote: > The cros_ec requires CS line to be active after last message. But the CS > would be toggled when powering off/on rockchip spi, which breaks ec xfer. > Use GPIO CS to prevent that. I suppose this change is fine. (At least, I don't have

Re: [PATCH v2 1/2] regulator: include 'enabled' status in debugfs/regulator_summary

On Tue, Jun 13, 2017 at 04:50:35PM +0200, Michał Mirosław wrote: > Extend regulator's info line with enabled/disabled status. Like I say please don't send new patches in reply to old ones - I can't tell what's going on here, I've got this mail but no v2 to go with it? signature.asc Description:

Re: [PATCH v2 1/2] regulator: include 'enabled' status in debugfs/regulator_summary

On Tue, Jun 13, 2017 at 04:50:35PM +0200, Michał Mirosław wrote: > Extend regulator's info line with enabled/disabled status. Like I say please don't send new patches in reply to old ones - I can't tell what's going on here, I've got this mail but no v2 to go with it? signature.asc Description:

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

On 13/06/17 10:35 AM, Greg Kroah-Hartman wrote: > For char devices, I doubt it, but we can't take the chance, which is why > you make it an option. Then, it's enabled for 'allmodconfig' builds, > which helps testers out. Well I took a look at this and it looks like a lot of work to modify all

Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

On 13/06/17 10:35 AM, Greg Kroah-Hartman wrote: > For char devices, I doubt it, but we can't take the chance, which is why > you make it an option. Then, it's enabled for 'allmodconfig' builds, > which helps testers out. Well I took a look at this and it looks like a lot of work to modify all

Re: [PATCH v2 2/2] regulator: tps65910: Allow supply references to the same chip

On Tue, Jun 13, 2017 at 04:41:58PM +0200, Michał Mirosław wrote: > This allows for (acyclic) references from tps6591x supplies to > its outputs. This is clearly not something that should be open coded in individual drivers, aside from the code duplication it is obviously possible to have two

Re: [PATCH v2 2/2] regulator: tps65910: Allow supply references to the same chip

On Tue, Jun 13, 2017 at 04:41:58PM +0200, Michał Mirosław wrote: > This allows for (acyclic) references from tps6591x supplies to > its outputs. This is clearly not something that should be open coded in individual drivers, aside from the code duplication it is obviously possible to have two

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Hi Richard, On 17-06-12 10:09 PM, Richard Cochran wrote: > On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote: >> +Example: >> + >> +ptp_dte: ptp_dte@180af650 { >> +compatible = "brcm,ptp-dte"; >> +reg = <0x180af650 0x10>; >> +status = "okay"; >> +}; > This patch set

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Hi Richard, On 17-06-12 10:09 PM, Richard Cochran wrote: > On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote: >> +Example: >> + >> +ptp_dte: ptp_dte@180af650 { >> +compatible = "brcm,ptp-dte"; >> +reg = <0x180af650 0x10>; >> +status = "okay"; >> +}; > This patch set

Re: [PATCH 04/12] coresight: Add support for reading 64bit registers

On Mon, Jun 12, 2017 at 03:36:43PM +0100, Suzuki K Poulose wrote: > Add support for reading a lower and upper 32bits of a register > as a single 64bit register. > > Cc: Mathieu Poirier > Signed-off-by: Suzuki K Poulose Just a few cosmetic

Re: [PATCH 04/12] coresight: Add support for reading 64bit registers

On Mon, Jun 12, 2017 at 03:36:43PM +0100, Suzuki K Poulose wrote: > Add support for reading a lower and upper 32bits of a register > as a single 64bit register. > > Cc: Mathieu Poirier > Signed-off-by: Suzuki K Poulose Just a few cosmetic details... > --- >

Re: [PATCH v4] Introduce v3 namespaced file capabilities

On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote: > Hi Stefan, > > On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote: > > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: > > > Root in a non-initial user ns cannot be trusted to write a > > > traditional

Re: [PATCH v4] Introduce v3 namespaced file capabilities

On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote: > Hi Stefan, > > On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote: > > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: > > > Root in a non-initial user ns cannot be trusted to write a > > > traditional

[GIT PULL 4/4] bcm2835-dt-64-next-2017-06-08

Hi Florian, Here's the last pull request in this series. I've based this summary on the bcm2835-dt-next tag, to clarify what's in this patch series, but it does require being careful since it involves a cross-merge between branches. The following changes since commit

Re: [PATCH v2 1/2] regulator: tps65910: check TPS65910_NUM_REGS at build time

On Tue, Jun 13, 2017 at 04:41:56PM +0200, Michał Mirosław wrote: > Check TPS65910_NUM_REGS at build time instead of silently registering > not all regulators at runtime. Please don't send new versions of patches in reply to existing threads, it makes it hard to figure out what the current

Re: usb/gadget: potential deadlock in gadgetfs_suspend

On Tue, 13 Jun 2017, Andrey Konovalov wrote: > Hi Alan, > > Thanks for the patch! > > I've been testing with your patch applied and the "bad spinlock magic" > crashes seem to be gone. However I got another crash (happened only > once over the night), which happens during "spin_lock_irqsave >

[GIT PULL 4/4] bcm2835-dt-64-next-2017-06-08

Hi Florian, Here's the last pull request in this series. I've based this summary on the bcm2835-dt-next tag, to clarify what's in this patch series, but it does require being careful since it involves a cross-merge between branches. The following changes since commit

Re: [PATCH v2 1/2] regulator: tps65910: check TPS65910_NUM_REGS at build time

On Tue, Jun 13, 2017 at 04:41:56PM +0200, Michał Mirosław wrote: > Check TPS65910_NUM_REGS at build time instead of silently registering > not all regulators at runtime. Please don't send new versions of patches in reply to existing threads, it makes it hard to figure out what the current

Re: usb/gadget: potential deadlock in gadgetfs_suspend

On Tue, 13 Jun 2017, Andrey Konovalov wrote: > Hi Alan, > > Thanks for the patch! > > I've been testing with your patch applied and the "bad spinlock magic" > crashes seem to be gone. However I got another crash (happened only > once over the night), which happens during "spin_lock_irqsave >

[GIT PULL 3/4] bcm2835-dt-next-2017-06-12

The following changes since commit 1f8216e7f78c2e55b07117c77887a314bc36f690: Merge tag 'bcm2835-dt-next-2017-03-30' into devicetree/next (2017-05-13 20:22:59 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2017-06-12 for you to fetch

[GIT PULL 3/4] bcm2835-dt-next-2017-06-12

The following changes since commit 1f8216e7f78c2e55b07117c77887a314bc36f690: Merge tag 'bcm2835-dt-next-2017-03-30' into devicetree/next (2017-05-13 20:22:59 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2017-06-12 for you to fetch

[GIT PULL 2/4] bcm2835-maintainers-next-2017-06-08

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-maintainers-next-2017-06-08 for you to fetch changes up to

[GIT PULL 1/4] bcm2835-defconfig-next-2017-06-12

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-defconfig-next-2017-06-12 for you to fetch changes up to

[GIT PULL 2/4] bcm2835-maintainers-next-2017-06-08

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-maintainers-next-2017-06-08 for you to fetch changes up to

[GIT PULL 1/4] bcm2835-defconfig-next-2017-06-12

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-defconfig-next-2017-06-12 for you to fetch changes up to

Re: WMI and Kernel:User interface

Hi Greg! I will try to explain that problem with calling WMI functions. On Tuesday 13 June 2017 18:57:14 Greg KH wrote: > > Getting there requires work in a few areas: > > 1) The OEM/IBV exports the methods and the MOF (in binary form) > > that describes the objects that can be interacted with

Re: WMI and Kernel:User interface

Hi Greg! I will try to explain that problem with calling WMI functions. On Tuesday 13 June 2017 18:57:14 Greg KH wrote: > > Getting there requires work in a few areas: > > 1) The OEM/IBV exports the methods and the MOF (in binary form) > > that describes the objects that can be interacted with

[PATCH] af_iucv: Move sockaddr length checks to before accessing sa_family in bind and connect handlers

Verify that the caller-provided sockaddr structure is large enough to contain the sa_family field, before accessing it in bind() and connect() handlers of the AF_IUCV socket. Since neither syscall enforces a minimum size of the corresponding memory region, very short sockaddrs (zero or one byte

[PATCH] af_iucv: Move sockaddr length checks to before accessing sa_family in bind and connect handlers

Verify that the caller-provided sockaddr structure is large enough to contain the sa_family field, before accessing it in bind() and connect() handlers of the AF_IUCV socket. Since neither syscall enforces a minimum size of the corresponding memory region, very short sockaddrs (zero or one byte

Re: [PATCH v4] Introduce v3 namespaced file capabilities

On 06/13/2017 01:14 PM, Tycho Andersen wrote: Hi Stefan, On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote: On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: Root in a non-initial user ns cannot be trusted to write a traditional security.capability xattr. If it were allowed to do

Re: [PATCH v4] Introduce v3 namespaced file capabilities

On 06/13/2017 01:14 PM, Tycho Andersen wrote: Hi Stefan, On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote: On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: Root in a non-initial user ns cannot be trusted to write a traditional security.capability xattr. If it were allowed to do

Re: WMI and Kernel:User interface

On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote: > On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > > I'll mention this again I suspect in this thread, but rather than a > > "WMI filter" we can implement a "WMI proxy". If a kernel driver > > needs to own certain WMI calls for LED

Re: WMI and Kernel:User interface

On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote: > On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > > I'll mention this again I suspect in this thread, but rather than a > > "WMI filter" we can implement a "WMI proxy". If a kernel driver > > needs to own certain WMI calls for LED

Re: [PATCH v2 2/4] spi: rockchip: add support for "cs-gpios" dts property

Hi Jeffy, On Tue, Jun 13, 2017 at 01:25:41PM +0800, Jeffy Chen wrote: > Support using "cs-gpios" property to specify cs gpios. > > Signed-off-by: Jeffy Chen > 1/ request cs gpios in probe for better error handling > 2/ use gpiod* function > (suggested by Heiko

Re: [PATCH v2 2/4] spi: rockchip: add support for "cs-gpios" dts property

Hi Jeffy, On Tue, Jun 13, 2017 at 01:25:41PM +0800, Jeffy Chen wrote: > Support using "cs-gpios" property to specify cs gpios. > > Signed-off-by: Jeffy Chen > 1/ request cs gpios in probe for better error handling > 2/ use gpiod* function > (suggested by Heiko Stuebner) > > 3/ split dt-binding

Re: [PATCH 3/3] livepatch: add shadow variable sample program

On 06/13/2017 07:00 AM, Miroslav Benes wrote: > On Thu, 1 Jun 2017, Joe Lawrence wrote: > >> Modify the sample livepatch to demonstrate the shadow variable API. >> >> Signed-off-by: Joe Lawrence >> --- >> samples/livepatch/livepatch-sample.c | 39 >>

Re: [PATCH 3/3] livepatch: add shadow variable sample program

On 06/13/2017 07:00 AM, Miroslav Benes wrote: > On Thu, 1 Jun 2017, Joe Lawrence wrote: > >> Modify the sample livepatch to demonstrate the shadow variable API. >> >> Signed-off-by: Joe Lawrence >> --- >> samples/livepatch/livepatch-sample.c | 39 >> +++- >> 1

Re: CRASH : RCU detected stall

On Tue, Jun 13, 2017 at 07:35:37PM +0430, Ramin Farajpour Cami wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller > version (4.12-rc5) > > https://groups.google.com/forum/#!topic/syzkaller/4e8MkNnRFRQ Can you reliably reproduce this failure? If so,

Re: CRASH : RCU detected stall

On Tue, Jun 13, 2017 at 07:35:37PM +0430, Ramin Farajpour Cami wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller > version (4.12-rc5) > > https://groups.google.com/forum/#!topic/syzkaller/4e8MkNnRFRQ Can you reliably reproduce this failure? If so,

Re: [PATCH 0/3] livepatch: add shadow variable API

On 06/13/2017 06:19 AM, Miroslav Benes wrote: >> If you are referring to stacking livepatches ... to be honest I hadn't >> thought of that scenario. In that case, we might be able to get away >> with pushing something like this into the hash: >> >> klp #1: klp_shadow_attach(ptr, "shadow_var",

Re: [PATCH 0/3] livepatch: add shadow variable API

On 06/13/2017 06:19 AM, Miroslav Benes wrote: >> If you are referring to stacking livepatches ... to be honest I hadn't >> thought of that scenario. In that case, we might be able to get away >> with pushing something like this into the hash: >> >> klp #1: klp_shadow_attach(ptr, "shadow_var",

Re: [PATCH v2 1/4] spi: rockchip: fix error handling when probe

On Tue, Jun 13, 2017 at 01:25:40PM +0800, Jeffy Chen wrote: > After failed to request dma tx chain, we need to disable pm_runtime. > Also cleanup error labels for better readability. > > Signed-off-by: Jeffy Chen > --- > > Changes in v2: None Looks good to me. I

Re: [PATCH v2 1/4] spi: rockchip: fix error handling when probe

On Tue, Jun 13, 2017 at 01:25:40PM +0800, Jeffy Chen wrote: > After failed to request dma tx chain, we need to disable pm_runtime. > Also cleanup error labels for better readability. > > Signed-off-by: Jeffy Chen > --- > > Changes in v2: None Looks good to me. I guess the original code was

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

[+cc Rafael, linux-pm] On Tue, Jun 13, 2017 at 12:21:15PM +0800, Kai-Heng Feng wrote: > On Mon, Jun 12, 2017 at 10:18 PM, Alan Stern > wrote: > > Let's get some help from people who understand PCI well. > > > > Here's the general problem: Kai-Heng has a PCI-based USB

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

[+cc Rafael, linux-pm] On Tue, Jun 13, 2017 at 12:21:15PM +0800, Kai-Heng Feng wrote: > On Mon, Jun 12, 2017 at 10:18 PM, Alan Stern > wrote: > > Let's get some help from people who understand PCI well. > > > > Here's the general problem: Kai-Heng has a PCI-based USB host > > controller that

Lockdep splat with tc filter on 4.11

Hi, Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626 of a hang on 4.11.3 with lockdep splat: [ 129.100206] BUG: sleeping function called from invalid context at mm/slab.h:432 [ 129.100237] in_atomic(): 1, irqs_disabled(): 0, pid: 1793, name: tc [ 129.100239] 2

Lockdep splat with tc filter on 4.11

Hi, Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1459626 of a hang on 4.11.3 with lockdep splat: [ 129.100206] BUG: sleeping function called from invalid context at mm/slab.h:432 [ 129.100237] in_atomic(): 1, irqs_disabled(): 0, pid: 1793, name: tc [ 129.100239] 2

Re: [PATCH 3/3] x86/build: Specify stack alignment for clang

El Tue, Jun 13, 2017 at 08:38:00AM +0200 Ingo Molnar ha dit: > > * Matthias Kaehlcke wrote: > > > For gcc stack alignment is configured with -mpreferred-stack-boundary=N, > > clang has the option -mstack-alignment=N for that purpose. Use the same > > alignment as for gcc. >

Re: [PATCH 3/3] x86/build: Specify stack alignment for clang

El Tue, Jun 13, 2017 at 08:38:00AM +0200 Ingo Molnar ha dit: > > * Matthias Kaehlcke wrote: > > > For gcc stack alignment is configured with -mpreferred-stack-boundary=N, > > clang has the option -mstack-alignment=N for that purpose. Use the same > > alignment as for gcc. > > > > If the

Re: [PATCH v2 2/4] spi: rockchip: add support for "cs-gpios" dts property

Hi Jeffy, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.12-rc5 next-20170613] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jeffy-Chen/spi-rockchip-fix-error

Re: [PATCH v2 2/4] spi: rockchip: add support for "cs-gpios" dts property

Hi Jeffy, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.12-rc5 next-20170613] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jeffy-Chen/spi-rockchip-fix-error

[PATCH] via-rhine: add support for changing MTU

AN MTU is limited to less than 1500. Signed-off-by: Magnus Damm <damm+rene...@opensource.se> --- Developed on top of next-20170613 drivers/net/ethernet/via/via-rhine.c | 19 +++ 1 file changed, 19 insertions(+) --- 0001/drivers/net/ethernet/via/via-rhine.c +++ work/drivers/

[PATCH] via-rhine: add support for changing MTU

. Signed-off-by: Magnus Damm --- Developed on top of next-20170613 drivers/net/ethernet/via/via-rhine.c | 19 +++ 1 file changed, 19 insertions(+) --- 0001/drivers/net/ethernet/via/via-rhine.c +++ work/drivers/net/ethernet/via/via-rhine.c 2017-06-14 02:05:25.410607110 +0900

Re: [PATCH v4] Introduce v3 namespaced file capabilities

Quoting Stefan Berger (stef...@linux.vnet.ibm.com): > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: > >Root in a non-initial user ns cannot be trusted to write a traditional > >security.capability xattr. If it were allowed to do so, then any > >unprivileged user on the host could map his own uid

[PATCH net-next 1/3] rtnetlink: add NEWCACHEREPORT message type

New NEWCACHEREPORT message type to be used for cache reports sent via Netlink, effectively allowing splitting cache report reception from mroute programming. Suggested-by: Ryan Halbrook Signed-off-by: Julien Gomes --- include/uapi/linux/rtnetlink.h | 3

Re: [PATCH v4] Introduce v3 namespaced file capabilities

Quoting Stefan Berger (stef...@linux.vnet.ibm.com): > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: > >Root in a non-initial user ns cannot be trusted to write a traditional > >security.capability xattr. If it were allowed to do so, then any > >unprivileged user on the host could map his own uid

[PATCH net-next 1/3] rtnetlink: add NEWCACHEREPORT message type

New NEWCACHEREPORT message type to be used for cache reports sent via Netlink, effectively allowing splitting cache report reception from mroute programming. Suggested-by: Ryan Halbrook Signed-off-by: Julien Gomes --- include/uapi/linux/rtnetlink.h | 3 +++ security/selinux/nlmsgtab.c| 3

[PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

Currently, all ipmr/ip6mr cache reports are sent through the mroute/mroute6 socket only. This forces the use of a single socket for mroute programming, cache reports and, regarding ipmr, IGMP messages without Router Alert option reception. The present patches are aiming to send Netlink

[PATCH net-next 0/3] ipmr/ip6mr: add Netlink notifications on cache reports

Currently, all ipmr/ip6mr cache reports are sent through the mroute/mroute6 socket only. This forces the use of a single socket for mroute programming, cache reports and, regarding ipmr, IGMP messages without Router Alert option reception. The present patches are aiming to send Netlink

[PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports

Add Netlink notifications on cache reports in ipmr, in addition to the existing igmpmsg sent to mroute_sk. Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE. MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the same data as their equivalent fields in the igmpmsg

[PATCH net-next 3/3] ip6mr: add netlink notifications on mrt6msg cache reports

Add Netlink notifications on cache reports in ip6mr, in addition to the existing mrt6msg sent to mroute6_sk. Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV6_MROUTE. MSGTYPE, MIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the same data as their equivalent fields in the mrt6msg

[PATCH net-next 3/3] ip6mr: add netlink notifications on mrt6msg cache reports

Add Netlink notifications on cache reports in ip6mr, in addition to the existing mrt6msg sent to mroute6_sk. Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV6_MROUTE. MSGTYPE, MIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the same data as their equivalent fields in the mrt6msg

[PATCH net-next 2/3] ipmr: add netlink notifications on igmpmsg cache reports

Add Netlink notifications on cache reports in ipmr, in addition to the existing igmpmsg sent to mroute_sk. Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE. MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the same data as their equivalent fields in the igmpmsg

RE: [PATCH net-next 8/9] net: hns3: Add support of debugfs interface to HNS3 driver

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Saturday, June 10, 2017 5:36 PM > To: Mintz, Yuval > Cc: Salil Mehta; da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; > lipeng (Y); mehta.salil@gmail.com; net...@vger.kernel.org; linux- >

RE: [PATCH net-next 8/9] net: hns3: Add support of debugfs interface to HNS3 driver

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Saturday, June 10, 2017 5:36 PM > To: Mintz, Yuval > Cc: Salil Mehta; da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; > lipeng (Y); mehta.salil@gmail.com; net...@vger.kernel.org; linux- >

Re: WMI and Kernel:User interface

On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > I'll mention this again I suspect in this thread, but rather than a > "WMI filter" we can implement a "WMI proxy". If a kernel driver > needs to own certain WMI calls for LED or Radio management, for > example, all such calls can be proxied

Re: WMI and Kernel:User interface

On Tuesday 13 June 2017 17:38:57 Darren Hart wrote: > I'll mention this again I suspect in this thread, but rather than a > "WMI filter" we can implement a "WMI proxy". If a kernel driver > needs to own certain WMI calls for LED or Radio management, for > example, all such calls can be proxied

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