Re: [PATCH v3 0/4] Export APIs to copy device properties & more

On Wed, Feb 01, 2017 at 09:31:21AM -0800, Dmitry Torokhov wrote: > Hi, > > Here is the refreshed series exporting APIs to copy statically declared > device properties. The reason is that we want to augment ACPI-based devices > with properties, and drivers usually have a largish DMI table for

Re: [PATCH v3 0/4] Export APIs to copy device properties & more

On Wed, Feb 01, 2017 at 09:31:21AM -0800, Dmitry Torokhov wrote: > Hi, > > Here is the refreshed series exporting APIs to copy statically declared > device properties. The reason is that we want to augment ACPI-based devices > with properties, and drivers usually have a largish DMI table for

[PATCH] x86, mpx: re-add MPX to selftests Makefile

From: Dave Hansen Ingo pointed out that the MPX tests were no longer in the selftests Makefile. It appears that I shot myself in the foot on this one and accidentally removed them when I added the pkeys tests, probably from bungling a merge conflict.

[PATCH] x86, mpx: re-add MPX to selftests Makefile

From: Dave Hansen Ingo pointed out that the MPX tests were no longer in the selftests Makefile. It appears that I shot myself in the foot on this one and accidentally removed them when I added the pkeys tests, probably from bungling a merge conflict. Signed-off-by: Dave Hansen Fixes:

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

Hello Dmitry, On 02/01/2017 07:28 PM, Dmitry Torokhov wrote: [snip] >> >> As said, changing the core is trivial. A RFC patch is [0]. >> >> The problem is how to make sure that this change won't cause regressions >> in existing drivers. > > If the concern with drivers having I2C or SPI device

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

Hello Dmitry, On 02/01/2017 07:28 PM, Dmitry Torokhov wrote: [snip] >> >> As said, changing the core is trivial. A RFC patch is [0]. >> >> The problem is how to make sure that this change won't cause regressions >> in existing drivers. > > If the concern with drivers having I2C or SPI device

Re: [PATCH] initity: try to improve __nocapture annotations

On Wed, Feb 1, 2017 at 1:05 PM, Rafael J. Wysocki wrote: > On Wed, Feb 1, 2017 at 5:11 PM, Arnd Bergmann wrote: >> There are some additional declarations that got missed in the original patch, >> and some annotated functions that use the pointer is a correct but

Re: [PATCH] initity: try to improve __nocapture annotations

On Wed, Feb 1, 2017 at 1:05 PM, Rafael J. Wysocki wrote: > On Wed, Feb 1, 2017 at 5:11 PM, Arnd Bergmann wrote: >> There are some additional declarations that got missed in the original patch, >> and some annotated functions that use the pointer is a correct but nonobvious >> way: >> >>

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On 02/01/2017 02:40 PM, Dan Williams wrote: > On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote: >> On 02/01/2017 02:05 PM, Dan Williams wrote: >>> Warnings of the following form occur because scsi reuses a devt number >>> while the block layer still has it referenced as the name

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On 02/01/2017 02:40 PM, Dan Williams wrote: > On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote: >> On 02/01/2017 02:05 PM, Dan Williams wrote: >>> Warnings of the following form occur because scsi reuses a devt number >>> while the block layer still has it referenced as the name of the bdi >>>

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On 01/02/17 10:04, Ingo Molnar wrote: > > * Nicolas Iooss wrote: > >> Adding such an attribute helps to detect errors in the format string at >> build time. After doing this, the compiler complains about such issues: >> >> arch/x86/tools/relocs.c:460:5: error:

Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 11:25:07PM +0100, Borislav Petkov wrote: > On Wed, Feb 01, 2017 at 09:55:44PM +, Ghannam, Yazen wrote: > > Okay, in that case I would prefer to define a synthetic bit. I think it'll > > be a lot > > more clear. > > No need - it is ok this way too. Now let me apply

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On 01/02/17 10:04, Ingo Molnar wrote: > > * Nicolas Iooss wrote: > >> Adding such an attribute helps to detect errors in the format string at >> build time. After doing this, the compiler complains about such issues: >> >> arch/x86/tools/relocs.c:460:5: error: format specifies type 'int' >>

Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 11:25:07PM +0100, Borislav Petkov wrote: > On Wed, Feb 01, 2017 at 09:55:44PM +, Ghannam, Yazen wrote: > > Okay, in that case I would prefer to define a synthetic bit. I think it'll > > be a lot > > more clear. > > No need - it is ok this way too. Now let me apply

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote: > On 02/01/2017 02:05 PM, Dan Williams wrote: >> Warnings of the following form occur because scsi reuses a devt number >> while the block layer still has it referenced as the name of the bdi >> [1]: >> >> WARNING: CPU: 1 PID: 93

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote: > On 02/01/2017 02:05 PM, Dan Williams wrote: >> Warnings of the following form occur because scsi reuses a devt number >> while the block layer still has it referenced as the name of the bdi >> [1]: >> >> WARNING: CPU: 1 PID: 93 at

[PATCH 2/2] net: ethernet: bgmac: mac address change bug

From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas Signed-off-by: Jon Mason

[PATCH 1/2] net: ethernet: bgmac: init sequence bug

From: Zac Schroff Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating. Signed-off-by: Zac Schroff Signed-off-by: Jon Mason

[PATCH 2/2] net: ethernet: bgmac: mac address change bug

From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas Signed-off-by: Jon Mason Fixes: 4e209001b86 ("bgmac: write mac

[PATCH 1/2] net: ethernet: bgmac: init sequence bug

From: Zac Schroff Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating. Signed-off-by: Zac Schroff Signed-off-by: Jon Mason Fixes: f6a95a24957 ("net: ethernet: bgmac: Add

[PATCH 0/2] net: ethernet: bgmac: bug fixes

Bug fixes for bgmac driver Hari Vyas (1): net: ethernet: bgmac: mac address change bug Zac Schroff (1): net: ethernet: bgmac: init sequence bug drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++--- drivers/net/ethernet/broadcom/bgmac.c | 6 +-

[PATCH 0/2] net: ethernet: bgmac: bug fixes

Bug fixes for bgmac driver Hari Vyas (1): net: ethernet: bgmac: mac address change bug Zac Schroff (1): net: ethernet: bgmac: init sequence bug drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++--- drivers/net/ethernet/broadcom/bgmac.c | 6 +-

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On 02/01/2017 02:05 PM, Dan Williams wrote: > Warnings of the following form occur because scsi reuses a devt number > while the block layer still has it referenced as the name of the bdi > [1]: > > WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 > sysfs: cannot create

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On 02/01/2017 02:05 PM, Dan Williams wrote: > Warnings of the following form occur because scsi reuses a devt number > while the block layer still has it referenced as the name of the bdi > [1]: > > WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 > sysfs: cannot create

Re: [PATCH] block: queue lock must be acquired when iterating over rls

On 01/31/2017 10:36 PM, Tahsin Erdogan wrote: > blk_set_queue_dying() does not acquire queue lock before it calls > blk_queue_for_each_rl(). This allows a racing blkg_destroy() to > remove blkg->q_node from the linked list and have > blk_queue_for_each_rl() loop infitely over the removed

Re: [PATCH] block: queue lock must be acquired when iterating over rls

On 01/31/2017 10:36 PM, Tahsin Erdogan wrote: > blk_set_queue_dying() does not acquire queue lock before it calls > blk_queue_for_each_rl(). This allows a racing blkg_destroy() to > remove blkg->q_node from the linked list and have > blk_queue_for_each_rl() loop infitely over the removed

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote: > Hello Nikolaus, > > On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote: > > Hi Dmitry, Javier, > > > >> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller : > >> > >> Hi Dmitry, > >> > >>> Am

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote: > Hello Nikolaus, > > On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote: > > Hi Dmitry, Javier, > > > >> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller : > >> > >> Hi Dmitry, > >> > >>> Am 29.01.2017 um 19:01 schrieb

Re: [PATCH v2 3/5] userfaultfd: non-cooperative: add event for exit() notification

On Wed, 1 Feb 2017 08:35:07 +0200 Mike Rapoport wrote: > On Tue, Jan 31, 2017 at 04:41:32PM -0800, Andrew Morton wrote: > > On Fri, 27 Jan 2017 20:44:31 +0200 Mike Rapoport > > wrote: > > > > > Allow userfaultfd monitor track termination of

Re: [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.10-rc6 next-20170201] [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/Tyler-Baicar/Add-UEFI-2-6-and-ACPI-6-1

Re: [PATCH v2 3/5] userfaultfd: non-cooperative: add event for exit() notification

On Wed, 1 Feb 2017 08:35:07 +0200 Mike Rapoport wrote: > On Tue, Jan 31, 2017 at 04:41:32PM -0800, Andrew Morton wrote: > > On Fri, 27 Jan 2017 20:44:31 +0200 Mike Rapoport > > wrote: > > > > > Allow userfaultfd monitor track termination of the processes that have > > > memory backed by the

Re: [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.10-rc6 next-20170201] [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/Tyler-Baicar/Add-UEFI-2-6-and-ACPI-6-1

Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 09:55:44PM +, Ghannam, Yazen wrote: > Okay, in that case I would prefer to define a synthetic bit. I think it'll be > a lot > more clear. No need - it is ok this way too. Now let me apply your changes ontop. I'd like to have two separate patches for this. Something

Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 09:55:44PM +, Ghannam, Yazen wrote: > Okay, in that case I would prefer to define a synthetic bit. I think it'll be > a lot > more clear. No need - it is ok this way too. Now let me apply your changes ontop. I'd like to have two separate patches for this. Something

[PATCH v7 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

The Marvell devices may have many gpio pins, and hence for wakeup on these out-of-band pins, the chip needs to be told which pin is to be used for wakeup, using an hci command. Thus, we read the pin number etc from the device tree node and send a command to the chip. Signed-off-by: Rajat Jain

[PATCH v7 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

The Marvell devices may have many gpio pins, and hence for wakeup on these out-of-band pins, the chip needs to be told which pin is to be used for wakeup, using an hci command. Thus, we read the pin number etc from the device tree node and send a command to the chip. Signed-off-by: Rajat Jain

[PATCH v7 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that can be connected to a gpio on the CPU side, and can be used to wakeup the host out-of-band. This can be useful in situations where the in-band wakeup is not possible or not preferable (e.g. the in-band wakeup may require the USB

[PATCH v7 2/3] Bluetooth: btusb: Add out-of-band wakeup support

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that can be connected to a gpio on the CPU side, and can be used to wakeup the host out-of-band. This can be useful in situations where the in-band wakeup is not possible or not preferable (e.g. the in-band wakeup may require the USB

[PATCH v7 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. Signed-off-by: Rajat Jain Reviewed-by: Brian Norris --- v7: same as v6 v6: same as v5 v5: same as v4 v4: same as v3 v3: Added Brian's "Reviewed-by" v2: same as v1

[PATCH v7 1/3] Bluetooth: btusb: Use an error label for error paths

Use a label to remove the repetetive cleanup, for error cases. Signed-off-by: Rajat Jain Reviewed-by: Brian Norris --- v7: same as v6 v6: same as v5 v5: same as v4 v4: same as v3 v3: Added Brian's "Reviewed-by" v2: same as v1 drivers/bluetooth/btusb.c | 19 +-- 1 file changed,

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On Wed, 2017-02-01 at 14:05 -0800, Dan Williams wrote: > Warnings of the following form occur because scsi reuses a devt number > while the block layer still has it referenced as the name of the bdi Thanks! Reviewed-by: Bart Van Assche

Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes

On Wed, 2017-02-01 at 14:05 -0800, Dan Williams wrote: > Warnings of the following form occur because scsi reuses a devt number > while the block layer still has it referenced as the name of the bdi Thanks! Reviewed-by: Bart Van Assche

Re: Radix tree range entries

On Wed, Feb 01, 2017 at 10:48:08AM -0800, Dan Williams wrote: > On Tue, Jan 31, 2017 at 8:59 AM, Matthew Wilcox wrote: > > We have a confirmed customer in the shape of devm_memremap_pages(), so > > add support for range entries. The documentation lists caveats on

regulator_get_optional() no longer returning NULL?

Hi Mark, It appears that [devm_]regulator_get_optional() and [devm_]gpiod_get_optional() behave irritatingly differently. While the latter returns NULL for non-existing GPIOs, the former started returning -ENODEV instead of NULL, starting with commit below. Why did we do that? It is much more

Re: Radix tree range entries

On Wed, Feb 01, 2017 at 10:48:08AM -0800, Dan Williams wrote: > On Tue, Jan 31, 2017 at 8:59 AM, Matthew Wilcox wrote: > > We have a confirmed customer in the shape of devm_memremap_pages(), so > > add support for range entries. The documentation lists caveats on their > > use, but

regulator_get_optional() no longer returning NULL?

Hi Mark, It appears that [devm_]regulator_get_optional() and [devm_]gpiod_get_optional() behave irritatingly differently. While the latter returns NULL for non-existing GPIOs, the former started returning -ENODEV instead of NULL, starting with commit below. Why did we do that? It is much more

[PATCH v2] ARM: dts: i.MX25: add AIPS control registers

The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of control registers. Add the memory regions for the control registers to the Device Tree. Signed-off-by: Martin Kaiser --- v2: removed the "fsl,imx53-aipstz" property as per Sascha's request

[PATCH v2] ARM: dts: i.MX25: add AIPS control registers

The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of control registers. Add the memory regions for the control registers to the Device Tree. Signed-off-by: Martin Kaiser --- v2: removed the "fsl,imx53-aipstz" property as per Sascha's request

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

On 1 February 2017 at 14:33, Mathieu Poirier wrote: > ) > > On 1 February 2017 at 05:46, Alexander Shishkin > wrote: >> Mathieu Poirier writes: >> >>> On 27 January 2017 at 05:12, Alexander Shishkin >>>

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

On 1 February 2017 at 14:33, Mathieu Poirier wrote: > ) > > On 1 February 2017 at 05:46, Alexander Shishkin > wrote: >> Mathieu Poirier writes: >> >>> On 27 January 2017 at 05:12, Alexander Shishkin >>> wrote: But "range" is not an action, it's a type of a filter. It determines the

[PATCH] arm64: hwpoison: add VM_FAULT_HWPOISON[_LARGE] handling

From: "Jonathan (Zhixiong) Zhang" Add VM_FAULT_HWPOISON[_LARGE] handling to the arm64 page fault handler. Handling of VM_FAULT_HWPOISON[_LARGE] is very similar to VM_FAULT_OOM, the only difference is that a different si_code (BUS_MCEERR_AR) is passed to user space and

[PATCH] arm64: hwpoison: add VM_FAULT_HWPOISON[_LARGE] handling

From: "Jonathan (Zhixiong) Zhang" Add VM_FAULT_HWPOISON[_LARGE] handling to the arm64 page fault handler. Handling of VM_FAULT_HWPOISON[_LARGE] is very similar to VM_FAULT_OOM, the only difference is that a different si_code (BUS_MCEERR_AR) is passed to user space and si_addr_lsb field is

Re: [PATCH] MAINTAINERS: Update for the current location of the bcm2835 tree.

On 01/31/2017 11:48 AM, Eric Anholt wrote: > I've been maintaining the bcm2835 branches here for a year or so. > > Signed-off-by: Eric Anholt Applied, thanks Eric. -- Florian

Re: [PATCH] MAINTAINERS: Update for the current location of the bcm2835 tree.

On 01/31/2017 11:48 AM, Eric Anholt wrote: > I've been maintaining the bcm2835 branches here for a year or so. > > Signed-off-by: Eric Anholt Applied, thanks Eric. -- Florian

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

Hi Andrew, > > We would need a tri-state device tree properly: > > > > 1. Not defined - do nothing > > 2. Defined as 0 -> explicitly disable port mirroring > > 3. Defined as 1 -> explicitly enable port mirriring > > > > The "net-phy-lane-swap" only fulfills points 1 and 3 above. > > > > In my

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

Hi Andrew, > > We would need a tri-state device tree properly: > > > > 1. Not defined - do nothing > > 2. Defined as 0 -> explicitly disable port mirroring > > 3. Defined as 1 -> explicitly enable port mirriring > > > > The "net-phy-lane-swap" only fulfills points 1 and 3 above. > > > > In my

Re: [PATCH v3] initramfs: finish fput() before accessing any binary from initramfs

On Wed, 1 Feb 2017 19:35:40 +0530 Lokesh Vutla wrote: > commit 4a9d4b024a31 ("switch fput to task_work_add") implements a > schedule_work() for completing fput(), but did not guarantee calling > __fput() after unpacking initramfs. Because of this, there is a > possibility

Re: [PATCH v3] initramfs: finish fput() before accessing any binary from initramfs

On Wed, 1 Feb 2017 19:35:40 +0530 Lokesh Vutla wrote: > commit 4a9d4b024a31 ("switch fput to task_work_add") implements a > schedule_work() for completing fput(), but did not guarantee calling > __fput() after unpacking initramfs. Because of this, there is a > possibility that during boot a

Re: [PATCH v2 0/4] Style fixes: open code obfuscating macros

Cool, Thanks. Let me know if you need anything from me. Logan On 01/02/17 01:08 PM, Jon Mason wrote: > On Thu, Jan 26, 2017 at 3:00 PM, Logan Gunthorpe wrote: >> Hi, >> >> It's been a couple weeks... Any thoughts on this? > > My apologies for not responding sooner. A

Re: [PATCH v2 0/4] Style fixes: open code obfuscating macros

Cool, Thanks. Let me know if you need anything from me. Logan On 01/02/17 01:08 PM, Jon Mason wrote: > On Thu, Jan 26, 2017 at 3:00 PM, Logan Gunthorpe wrote: >> Hi, >> >> It's been a couple weeks... Any thoughts on this? > > My apologies for not responding sooner. A large rework of the core

Re: [PATCH] staging: vt6656: Avoid multiple line dereference

On Wed, 2017-02-01 at 21:43 +, Craig Kewley wrote: > This patch fixes the checkpatch.pl warning: > WARNING: Avoid multiple line dereference Hi Craig. Please try to make the code more sensible in preference to just fixing checkpatch warnings. > diff --git a/drivers/staging/vt6656/rxtx.c

Re: [PATCH] staging: vt6656: Avoid multiple line dereference

On Wed, 2017-02-01 at 21:43 +, Craig Kewley wrote: > This patch fixes the checkpatch.pl warning: > WARNING: Avoid multiple line dereference Hi Craig. Please try to make the code more sensible in preference to just fixing checkpatch warnings. > diff --git a/drivers/staging/vt6656/rxtx.c

[PATCH v3] scsi, block: fix duplicate bdi name registration crashes

Warnings of the following form occur because scsi reuses a devt number while the block layer still has it referenced as the name of the bdi [1]: WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192' [..] Call

[PATCH v3] scsi, block: fix duplicate bdi name registration crashes

Warnings of the following form occur because scsi reuses a devt number while the block layer still has it referenced as the name of the bdi [1]: WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192' [..] Call

Re: [PATCH v2 2/4] net: phy: Initialize mdio clock at probe function

On 01/17/2017 08:14 AM, Yendapally Reddy Dhananjaya Reddy wrote: > Initialize mdio clock divisor in probe function. The ext bus > bit available in the same register will be used by mdio mux > to enable external mdio. > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy >

Re: [PATCH v2 2/4] net: phy: Initialize mdio clock at probe function

On 01/17/2017 08:14 AM, Yendapally Reddy Dhananjaya Reddy wrote: > Initialize mdio clock divisor in probe function. The ext bus > bit available in the same register will be used by mdio mux > to enable external mdio. > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > David, this patch

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

On Wed, 1 Feb 2017 20:47:06 +0100 Helge Deller wrote: > Hi Andrew, > > On 01.02.2017 01:26, Andrew Morton wrote: > > On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller wrote: > > > >> The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but > >> implemented

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

On Wed, 1 Feb 2017 20:47:06 +0100 Helge Deller wrote: > Hi Andrew, > > On 01.02.2017 01:26, Andrew Morton wrote: > > On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller wrote: > > > >> The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but > >> implemented for PowerPC only. > >> This

Re: [PATCH] staging: rtl8192e: Aligning the * on each line in block comments

On Thu, 2017-02-02 at 03:22 +0530, Arushi wrote: > This patch fixes the issue by aligning the * on each line in block comments. [] > diff --git a/drivers/staging/speakup/speakup_decpc.c > b/drivers/staging/speakup/speakup_decpc.c [] > @@ -85,8 +85,8 @@ > #define CTRL_io_priority

Re: [PATCH] staging: rtl8192e: Aligning the * on each line in block comments

On Thu, 2017-02-02 at 03:22 +0530, Arushi wrote: > This patch fixes the issue by aligning the * on each line in block comments. [] > diff --git a/drivers/staging/speakup/speakup_decpc.c > b/drivers/staging/speakup/speakup_decpc.c [] > @@ -85,8 +85,8 @@ > #define CTRL_io_priority

RE: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, February 1, 2017 4:44 PM > > > To get around this we can set cu_id for all TOPOEXT systems, and update > > cpu_core_id, etc. for SMT enabled systems. This way we can just change > > cpu_core_id to

RE: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, February 1, 2017 4:44 PM > > > To get around this we can set cu_id for all TOPOEXT systems, and update > > cpu_core_id, etc. for SMT enabled systems. This way we can just change > > cpu_core_id to

Re: initify plugin crashes on arm allmodconfig

I ran into three more problems now that I haven't analysed yet: 1. I suspect this one is from a string that got deduplicated but is used from both __init and non-__init functions now. Same tree, randconfig output at http://pastebin.com/dl/XA3fXTtp ==> build/x86/0x27D13D98_defconfig/log <==

Re: initify plugin crashes on arm allmodconfig

I ran into three more problems now that I haven't analysed yet: 1. I suspect this one is from a string that got deduplicated but is used from both __init and non-__init functions now. Same tree, randconfig output at http://pastebin.com/dl/XA3fXTtp ==> build/x86/0x27D13D98_defconfig/log <==

[PATCH] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. Signed-off-by: Arushi --- drivers/staging/speakup/fakekey.c| 10 +- drivers/staging/speakup/i18n.c | 14 +++--- drivers/staging/speakup/main.c

[PATCH] staging: rtl8192e: Aligning the * on each line in block comments

This patch fixes the issue by aligning the * on each line in block comments. Signed-off-by: Arushi --- drivers/staging/speakup/fakekey.c| 10 +- drivers/staging/speakup/i18n.c | 14 +++--- drivers/staging/speakup/main.c | 2 +-

Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness

On 02/01/2017 09:36 AM, Ard Biesheuvel wrote: > On 1 February 2017 at 16:58, Laura Abbott wrote: >> On 10/19/2016 09:22 AM, Will Deacon wrote: >>> On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote: On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf

Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness

On 02/01/2017 09:36 AM, Ard Biesheuvel wrote: > On 1 February 2017 at 16:58, Laura Abbott wrote: >> On 10/19/2016 09:22 AM, Will Deacon wrote: >>> On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote: On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf wrote: > On

Re: [PATCH] Staging: ks7010: Fix tabs in ks_hostif.h.

On Wed, 2017-02-01 at 12:59 -0800, Logan Gorence wrote: > Convert spaces to tabs in ks_hostif.h, according to > the checkpatch.pl script. [] > diff --git a/drivers/staging/ks7010/ks_hostif.h > b/drivers/staging/ks7010/ks_hostif.h [] > @@ -569,18 +569,18 @@ struct hostif_mic_failure_confirm_t { >

Re: [PATCH] Staging: ks7010: Fix tabs in ks_hostif.h.

On Wed, 2017-02-01 at 12:59 -0800, Logan Gorence wrote: > Convert spaces to tabs in ks_hostif.h, according to > the checkpatch.pl script. [] > diff --git a/drivers/staging/ks7010/ks_hostif.h > b/drivers/staging/ks7010/ks_hostif.h [] > @@ -569,18 +569,18 @@ struct hostif_mic_failure_confirm_t { >

Re: [PATCH] kprobes: move kprobe declarations to asm-generic/kprobes.h

On Thu, Jan 19, 2017 at 03:47:35PM +0900, Masami Hiramatsu wrote: > OK, then it is OK to me. > > Acked-by: Masami Hiramatsu Aha, actually I *did* send this out separately already :) -- who's tree should this go through ? Luis

Re: [PATCH] kprobes: move kprobe declarations to asm-generic/kprobes.h

On Thu, Jan 19, 2017 at 03:47:35PM +0900, Masami Hiramatsu wrote: > OK, then it is OK to me. > > Acked-by: Masami Hiramatsu Aha, actually I *did* send this out separately already :) -- who's tree should this go through ? Luis

[PATCH] staging: vt6656: Avoid multiple line dereference

This patch fixes the checkpatch.pl warning: WARNING: Avoid multiple line dereference Signed-off-by: Craig Kewley --- drivers/staging/vt6656/rxtx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vt6656/rxtx.c

[PATCH] staging: vt6656: Avoid multiple line dereference

This patch fixes the checkpatch.pl warning: WARNING: Avoid multiple line dereference Signed-off-by: Craig Kewley --- drivers/staging/vt6656/rxtx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c index

Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 09:37:02PM +, Ghannam, Yazen wrote: > This hunk won't work for SMT enabled systems. It'll cause all threads under > an LLC to be considered SMT siblings. For example, threads 0 &2 will have > different cpu_core_id, so the first check will fail. But it'll match on the >

Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 09:37:02PM +, Ghannam, Yazen wrote: > This hunk won't work for SMT enabled systems. It'll cause all threads under > an LLC to be considered SMT siblings. For example, threads 0 &2 will have > different cpu_core_id, so the first check will fail. But it'll match on the >

Re: initify plugin crashes on arm allmodconfig

playground.git randconfig-4.11-next >From git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground * branchrandconfig-4.11-next -> FETCH_HEAD arnd@wuerfel:~/git/arm-soc$ git checkout FETCH_HEAD HEAD is now at fbb1b68... fixup! [SUBMITTED 20170201] [RFC v2] sched: make DECLARE_

Re: initify plugin crashes on arm allmodconfig

nfig-4.11-next >From git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground * branchrandconfig-4.11-next -> FETCH_HEAD arnd@wuerfel:~/git/arm-soc$ git checkout FETCH_HEAD HEAD is now at fbb1b68... fixup! [SUBMITTED 20170201] [RFC v2] sched: make DECLARE_COMPLETION_ONSTACK() work

[PATCH] arm64: kconfig: allow support for memory failure handling

From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery when such memory failure is reported through ACPI APEI. APEI (ACPI Platform Error Interfaces) provides a means for the

[PATCH] arm64: kconfig: allow support for memory failure handling

From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery when such memory failure is reported through ACPI APEI. APEI (ACPI Platform Error Interfaces) provides a means for the platform to convey error

[PATCH] NTB: Add IDT 89HPESxNTx PCIe-switches support

IDT 89HPESxNTx device series is PCIe-switches, which support Non-Transparent bridging between domains connected to the device ports. Since new NTB API exposes multi-port interface and messaging API, the IDT NT-functions can be now supported in the kernel. This driver adds the following

[PATCH] NTB: Add IDT 89HPESxNTx PCIe-switches support

IDT 89HPESxNTx device series is PCIe-switches, which support Non-Transparent bridging between domains connected to the device ports. Since new NTB API exposes multi-port interface and messaging API, the IDT NT-functions can be now supported in the kernel. This driver adds the following

RE: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, February 1, 2017 3:03 PM > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 548da5a8013e..f06fa338076b 100644 > --- a/arch/x86/kernel/smpboot.c > +++

RE: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, February 1, 2017 3:03 PM > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 548da5a8013e..f06fa338076b 100644 > --- a/arch/x86/kernel/smpboot.c > +++

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

) On 1 February 2017 at 05:46, Alexander Shishkin wrote: > Mathieu Poirier writes: > >> On 27 January 2017 at 05:12, Alexander Shishkin >> wrote: >>> But "range" is not an action, it's a type of

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

) On 1 February 2017 at 05:46, Alexander Shishkin wrote: > Mathieu Poirier writes: > >> On 27 January 2017 at 05:12, Alexander Shishkin >> wrote: >>> But "range" is not an action, it's a type of a filter. It determines the >>> condition that triggers an action. An action, however, is what we

[PATCH] scatterlist: don't overflow length field

When called with a region of contiguous pages totaling > 4 GB of memory, sg_alloc_table_from_pages() will overflow the length field, leading to a corrupt scatter list. Fix this by tracking the number of pages we've merged and start a new chunk when we would overflow. Tested by building various

[PATCH] scatterlist: don't overflow length field

When called with a region of contiguous pages totaling > 4 GB of memory, sg_alloc_table_from_pages() will overflow the length field, leading to a corrupt scatter list. Fix this by tracking the number of pages we've merged and start a new chunk when we would overflow. Tested by building various

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 13:16 -0800, Eric Dumazet wrote: > This would permanently leave the kernel in the netstamp_needed state. > > I would prefer the patch using a process context to perform the > cleanup ? Note there is a race window, but probably not a big deal. > > net/core/dev.c | 30

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 13:16 -0800, Eric Dumazet wrote: > This would permanently leave the kernel in the netstamp_needed state. > > I would prefer the patch using a process context to perform the > cleanup ? Note there is a race window, but probably not a big deal. > > net/core/dev.c | 30

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