Re: [PATCH 0/3] ti,ads7950 device tree bindings

On 01/15/2017 07:58 AM, Jonathan Cameron wrote: On 11/01/17 17:52, David Lechner wrote: This series adds device tree bindings for the TI ADS7950 family of A/DC chips. The series includes the bindings documentation and some fixes to the iio driver to make it work with the device tree bindings.

Re: [PATCH 0/3] ti,ads7950 device tree bindings

On 01/15/2017 07:58 AM, Jonathan Cameron wrote: On 11/01/17 17:52, David Lechner wrote: This series adds device tree bindings for the TI ADS7950 family of A/DC chips. The series includes the bindings documentation and some fixes to the iio driver to make it work with the device tree bindings.

Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

On Sat, Jan 14, 2017 at 01:09:57PM +0100, Arnd Bergmann wrote: > On Jan 13, 2017 10:42 PM, "Dmitry Torokhov" wrote: > > On Fri, Jan 13, 2017 at 10:34:32PM +0100, Arnd Bergmann wrote: > > > config RMI4_F03_SERIO > > >tristate > > >depends on RMI4_CORE > >

Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

On Sat, Jan 14, 2017 at 01:09:57PM +0100, Arnd Bergmann wrote: > On Jan 13, 2017 10:42 PM, "Dmitry Torokhov" wrote: > > On Fri, Jan 13, 2017 at 10:34:32PM +0100, Arnd Bergmann wrote: > > > config RMI4_F03_SERIO > > >tristate > > >depends on RMI4_CORE > > >depends on

Re: [PATCH RFC V2] Input: cyapa: use time based retry loop

On Sun, Jan 15, 2017 at 12:12:38PM +0100, Nicholas Mc Guire wrote: > Using counter based retry loops for peripherals results in the delay > being significantly overrun during high-load situations where delay > functions tend to be vary imprecise and overrun there timeouts. So > condition the

Re: [PATCH RFC V2] Input: cyapa: use time based retry loop

On Sun, Jan 15, 2017 at 12:12:38PM +0100, Nicholas Mc Guire wrote: > Using counter based retry loops for peripherals results in the delay > being significantly overrun during high-load situations where delay > functions tend to be vary imprecise and overrun there timeouts. So > condition the

Re: [PATCH] Input: cyapa_gen3: use msleep() for long delay

On Sun, Jan 15, 2017 at 12:13:07PM +0100, Nicholas Mc Guire wrote: > ulseep_range() uses hrtimers and provides no advantage over msleep() > for larger delays. Fix up the 50ms delays here to use msleep() and > reduce the load on the hrtimer subsystem. > > Signed-off-by: Nicholas Mc Guire

Re: [PATCH] Input: cyapa_gen3: use msleep() for long delay

On Sun, Jan 15, 2017 at 12:13:07PM +0100, Nicholas Mc Guire wrote: > ulseep_range() uses hrtimers and provides no advantage over msleep() > for larger delays. Fix up the 50ms delays here to use msleep() and > reduce the load on the hrtimer subsystem. > > Signed-off-by: Nicholas Mc Guire

Re: [PATCH 06/10] sata: ahci_da850: implement a softreset quirk

On Fri, Jan 13, 2017 at 01:38:00PM +0100, Bartosz Golaszewski wrote: > +static int ahci_da850_softreset(struct ata_link *link, > + unsigned int *class, unsigned long deadline) > +{ > + int pmp, ret; > + > + pmp = sata_srst_pmp(link); > + > + ret =

Re: [PATCH 06/10] sata: ahci_da850: implement a softreset quirk

On Fri, Jan 13, 2017 at 01:38:00PM +0100, Bartosz Golaszewski wrote: > +static int ahci_da850_softreset(struct ata_link *link, > + unsigned int *class, unsigned long deadline) > +{ > + int pmp, ret; > + > + pmp = sata_srst_pmp(link); > + > + ret =

Re: [PATCH 04/10] sata: hardreset: retry if phys link is down

Hello, On Fri, Jan 13, 2017 at 01:37:58PM +0100, Bartosz Golaszewski wrote: > The sata core driver already retries to resume the link because some > controllers ignore writes to the SControl register. > > We have a use case with the da850 SATA controller where at PLL0 > frequency of 456MHz

Re: [PATCH 04/10] sata: hardreset: retry if phys link is down

Hello, On Fri, Jan 13, 2017 at 01:37:58PM +0100, Bartosz Golaszewski wrote: > The sata core driver already retries to resume the link because some > controllers ignore writes to the SControl register. > > We have a use case with the da850 SATA controller where at PLL0 > frequency of 456MHz

Re: [tip:sched/core] locking/mutex, sched/wait: Fix the mutex_lock_io_nested() define

On Sun, Jan 15, 2017 at 01:26:16AM -0800, tip-bot for Ingo Molnar wrote: > Commit-ID: f21860bac05b609d71757338361d26209ff0759b > Gitweb: http://git.kernel.org/tip/f21860bac05b609d71757338361d26209ff0759b > Author: Ingo Molnar > AuthorDate: Sat, 14 Jan 2017 17:11:36

Re: [tip:sched/core] locking/mutex, sched/wait: Fix the mutex_lock_io_nested() define

On Sun, Jan 15, 2017 at 01:26:16AM -0800, tip-bot for Ingo Molnar wrote: > Commit-ID: f21860bac05b609d71757338361d26209ff0759b > Gitweb: http://git.kernel.org/tip/f21860bac05b609d71757338361d26209ff0759b > Author: Ingo Molnar > AuthorDate: Sat, 14 Jan 2017 17:11:36 +0100 > Committer:

[PATCH] partitions/efi: Fix integer overflow in GPT size calculation

If a GUID Partition Table claims to have more than 2**25 entries, the calculation of the partition table size in alloc_read_gpt_entries() will overflow a 32-bit integer and not enough space will be allocated for the table. Nothing seems to get written out of bounds, but later efi_partition() will

[PATCH] partitions/efi: Fix integer overflow in GPT size calculation

If a GUID Partition Table claims to have more than 2**25 entries, the calculation of the partition table size in alloc_read_gpt_entries() will overflow a 32-bit integer and not enough space will be allocated for the table. Nothing seems to get written out of bounds, but later efi_partition() will

[PATCH v2 tip/core/rcu 3/3] rcutorture: Add CBMC-based formal verification for SRCU

From: Lance Roy This commit creates a formal/srcu-cbmc directory containing scripts that pull SRCU in from the source code, filter it to remove things that CBMC cannot handle, and run a series of verifications on it. This has a number of shortcomings: 1. It does not yet

[PATCH v2 tip/core/rcu 3/3] rcutorture: Add CBMC-based formal verification for SRCU

From: Lance Roy This commit creates a formal/srcu-cbmc directory containing scripts that pull SRCU in from the source code, filter it to remove things that CBMC cannot handle, and run a series of verifications on it. This has a number of shortcomings: 1. It does not yet hook into the

[PATCH v2 tip/core/rcu 1/3] srcu: Implement more-efficient reader counts

From: Lance Roy SRCU uses two per-cpu counters: a nesting counter to count the number of active critical sections, and a sequence counter to ensure that the nesting counters don't change while they are being added together in srcu_readers_active_idx_check(). This patch instead

[PATCH v2 tip/core/rcu 2/3] srcu: Force full grace-period ordering

If a process invokes synchronize_srcu(), is delayed just the right amount of time, and thus does not sleep when waiting for the grace period to complete, there is no ordering between the end of the grace period and the code following the synchronize_srcu(). Similarly, there can be a lack of

[PATCH v2 tip/core/rcu 1/3] srcu: Implement more-efficient reader counts

From: Lance Roy SRCU uses two per-cpu counters: a nesting counter to count the number of active critical sections, and a sequence counter to ensure that the nesting counters don't change while they are being added together in srcu_readers_active_idx_check(). This patch instead uses per-cpu lock

[PATCH v2 tip/core/rcu 2/3] srcu: Force full grace-period ordering

If a process invokes synchronize_srcu(), is delayed just the right amount of time, and thus does not sleep when waiting for the grace period to complete, there is no ordering between the end of the grace period and the code following the synchronize_srcu(). Similarly, there can be a lack of

[PATCH tip/core/rcu v2 0/3] SRCU updates for 4.11

Hello! This series provides updates to SRCU: 1. This is a rewrite of the algorithm simplifying reader-count tracking. Algorithm courtesy of Mathieu Desnoyers, implementation courtesy of Lance Roy. 2. Force full grace-period ordering in SRCU. 3. Add CBMC-based

[PATCH tip/core/rcu v2 0/3] SRCU updates for 4.11

Hello! This series provides updates to SRCU: 1. This is a rewrite of the algorithm simplifying reader-count tracking. Algorithm courtesy of Mathieu Desnoyers, implementation courtesy of Lance Roy. 2. Force full grace-period ordering in SRCU. 3. Add CBMC-based

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

On Monday, January 2, 2017 at 5:31:15 PM UTC-8, Logan Gunthorpe wrote: > Hi, > > I had copied some poor code style from the NTB drivers into an unrelated > driver. Upon review of my new code, I learned it was not a good idea > to sweep dirty things under the rug^W macro. See [1], where Gregg k-h

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

On Monday, January 2, 2017 at 5:31:15 PM UTC-8, Logan Gunthorpe wrote: > Hi, > > I had copied some poor code style from the NTB drivers into an unrelated > driver. Upon review of my new code, I learned it was not a good idea > to sweep dirty things under the rug^W macro. See [1], where Gregg k-h

[PATCH] net: jme: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/jme.c | 34

[PATCH] net: jme: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/jme.c | 34 +-

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, 2017-01-15 at 11:49 -0800, James Bottomley wrote: > On Sun, 2017-01-15 at 11:41 -0800, Linus Torvalds wrote: > > On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley > > wrote: > > > > > > Can we compromise on "try not to revert a fix ...". > > > >

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, 2017-01-15 at 11:49 -0800, James Bottomley wrote: > On Sun, 2017-01-15 at 11:41 -0800, Linus Torvalds wrote: > > On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley > > wrote: > > > > > > Can we compromise on "try not to revert a fix ...". > > > > No. > > > > It's about timing, and about

[PATCH 2/2] ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"

From: Jagan Teki Fixed code indent tabs in respetcive imx6qdl dtsi files and also add space on imx6qdl-icore-rqs.dtsi on usdhc bus-width nodes. Cc: Shawn Guo Signed-off-by: Jagan Teki ---

[PATCH 1/2] ARM: dts: imx6ul-isiot: Add eMMC node

From: Jagan Teki Add usdhc2 node, which is eMMC for Engicam Is.IoT MX6UL modules. dmesg: - mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA mmc1: new DDR MMC card at address 0001 mmcblk1: mmc1:0001 M62704 3.53 GiB Cc: Matteo Lisi

[PATCH 2/2] ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"

From: Jagan Teki Fixed code indent tabs in respetcive imx6qdl dtsi files and also add space on imx6qdl-icore-rqs.dtsi on usdhc bus-width nodes. Cc: Shawn Guo Signed-off-by: Jagan Teki --- arch/arm/boot/dts/imx6qdl-gw52xx.dtsi| 2 +- arch/arm/boot/dts/imx6qdl-gw53xx.dtsi| 2 +-

[PATCH 1/2] ARM: dts: imx6ul-isiot: Add eMMC node

From: Jagan Teki Add usdhc2 node, which is eMMC for Engicam Is.IoT MX6UL modules. dmesg: - mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA mmc1: new DDR MMC card at address 0001 mmcblk1: mmc1:0001 M62704 3.53 GiB Cc: Matteo Lisi Cc: Michael Trimarchi Cc: Signed-off-by:

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin wrote: > On 2017/1/13 13:29, Matt Ranostay wrote: >> >> Allow power sequencing for the Marvell SD8787 Wifi/BT chip. >> This can be abstracted to other chipsets if needed in the future. >> >> Cc: Tony Lindgren

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin wrote: > On 2017/1/13 13:29, Matt Ranostay wrote: >> >> Allow power sequencing for the Marvell SD8787 Wifi/BT chip. >> This can be abstracted to other chipsets if needed in the future. >> >> Cc: Tony Lindgren >> Cc: Ulf Hansson >> Signed-off-by: Matt

llist code relies on undefined behaviour, upsets llvm/clang

Hi, I was debugging a hang on a ppc64le kernel built with clang, and it looks to be undefined behaviour with pointer wrapping in the llist code. A test case is below. llist_for_each_entry() does container_of() on a NULL pointer, which wraps our pointer negative, then adds the same offset back in

llist code relies on undefined behaviour, upsets llvm/clang

Hi, I was debugging a hang on a ppc64le kernel built with clang, and it looks to be undefined behaviour with pointer wrapping in the llist code. A test case is below. llist_for_each_entry() does container_of() on a NULL pointer, which wraps our pointer negative, then adds the same offset back in

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

Hi Robin, On Friday 13 Jan 2017 12:17:24 Robin Murphy wrote: > On 13/01/17 11:59, Geert Uytterhoeven wrote: > > On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy wrote: > >> On 13/01/17 11:07, Geert Uytterhoeven wrote: > >>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code. >

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

Hi Robin, On Friday 13 Jan 2017 12:17:24 Robin Murphy wrote: > On 13/01/17 11:59, Geert Uytterhoeven wrote: > > On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy wrote: > >> On 13/01/17 11:07, Geert Uytterhoeven wrote: > >>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code. >

Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats

On Sun, Jan 15, 2017 at 06:29:59PM +0100, Dmitry Vyukov wrote: > Hello, > > I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and > now I am seeing lots of: > If I'm not mistaken, its because thats specifically what that option does. From the Kconfig: onfig

Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats

On Sun, Jan 15, 2017 at 06:29:59PM +0100, Dmitry Vyukov wrote: > Hello, > > I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and > now I am seeing lots of: > If I'm not mistaken, its because thats specifically what that option does. From the Kconfig: onfig

Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

On Sun, Jan 15, 2017 at 11:09:31AM +0100, Borislav Petkov wrote: > On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote: > > > Which means, you probably should tag your fix CC:stable and add > > > > > > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue") > > > >

Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

On Sun, Jan 15, 2017 at 11:09:31AM +0100, Borislav Petkov wrote: > On Sat, Jan 14, 2017 at 09:24:43PM -0800, Paul E. McKenney wrote: > > > Which means, you probably should tag your fix CC:stable and add > > > > > > Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue") > > > >

[GIT RFC PULL rcu/urgent] Make RCU synchronous grace periods work throughout boot

Hello, Ingo, This series contains a pair of commits that permit RCU synchronous grace periods (synchronize_rcu() and friends) to work correctly throughout boot. This eliminates the current "dead time" starting when the scheduler spawns its first taks and ending when the last of RCU's kthreads is

[GIT RFC PULL rcu/urgent] Make RCU synchronous grace periods work throughout boot

Hello, Ingo, This series contains a pair of commits that permit RCU synchronous grace periods (synchronize_rcu() and friends) to work correctly throughout boot. This eliminates the current "dead time" starting when the scheduler spawns its first taks and ending when the last of RCU's kthreads is

Re: [PATCH] char: ipmi: constify ipmi_smi_handlers structures

On 01/15/2017 01:15 PM, Bhumika Goyal wrote: Declare ipmi_smi_handlers structures as const as they are only passed as an argument to the function ipmi_register_smi. This argument is of type const, so ipmi_smi_handlers structures having similar properties can be declared const too. Done using

Re: [PATCH] char: ipmi: constify ipmi_smi_handlers structures

On 01/15/2017 01:15 PM, Bhumika Goyal wrote: Declare ipmi_smi_handlers structures as const as they are only passed as an argument to the function ipmi_register_smi. This argument is of type const, so ipmi_smi_handlers structures having similar properties can be declared const too. Done using

[PATCH v5 8/8] thunderbolt: Runtime suspend NHI when idle

Runtime suspend the NHI when no Thunderbolt devices have been plugged in for 10 sec (user-configurable via autosuspend_delay_ms in sysfs). The NHI is not able to detect plug events while suspended, it relies on the GPE handler to resume it on hotplug. After the NHI resumes, it takes about 700 ms

[PATCH v5 8/8] thunderbolt: Runtime suspend NHI when idle

Runtime suspend the NHI when no Thunderbolt devices have been plugged in for 10 sec (user-configurable via autosuspend_delay_ms in sysfs). The NHI is not able to detect plug events while suspended, it relies on the GPE handler to resume it on hotplug. After the NHI resumes, it takes about 700 ms

[PATCH v5 7/8] thunderbolt: Power down controller when idle

Document and implement Apple's ACPI-based (but nonstandard) pm mechanism for Thunderbolt. Briefly, an ACPI method provided by Apple is used to cut power to the controller. A GPE is enabled while the controller is powered down which sideband-signals a plug event, whereupon we reinstate power

[PATCH v5 7/8] thunderbolt: Power down controller when idle

Document and implement Apple's ACPI-based (but nonstandard) pm mechanism for Thunderbolt. Briefly, an ACPI method provided by Apple is used to cut power to the controller. A GPE is enabled while the controller is powered down which sideband-signals a plug event, whereupon we reinstate power

[PATCH v5 6/8] PM / sleep: Define constant for direct_complete

From: Chen Yu The PM core introduced the ability to keep devices runtime suspended during the entire system sleep process with commit aae4518b3124 ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily"). Drivers opt in to this so-called

[PATCH v5 6/8] PM / sleep: Define constant for direct_complete

From: Chen Yu The PM core introduced the ability to keep devices runtime suspended during the entire system sleep process with commit aae4518b3124 ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily"). Drivers opt in to this so-called "direct_complete" mechanism by

[PATCH v5 5/8] PM: Make requirements of dev_pm_domain_set() more precise

Since commit 989561de9b51 ("PM / Domains: add setter for dev.pm_domain") a PM domain may only be assigned to unbound devices. The motivation was not made explicit in the changelog other than "in the general case that can cause problems and also [...] we can simplify code quite a bit if we can

[PATCH v5 5/8] PM: Make requirements of dev_pm_domain_set() more precise

Since commit 989561de9b51 ("PM / Domains: add setter for dev.pm_domain") a PM domain may only be assigned to unbound devices. The motivation was not made explicit in the changelog other than "in the general case that can cause problems and also [...] we can simplify code quite a bit if we can

[PATCH v5 4/8] Revert "PM / Runtime: Remove the exported function pm_children_suspended()"

This reverts commit 62006c1702b3b1be0c0726949e0ee0ea2326be9c which removed pm_children_suspended() because it had only a single caller. We're about to add a second caller, so establish the status quo ante. Cc: Ulf Hansson Cc: Rafael J. Wysocki

[PATCH v5 4/8] Revert "PM / Runtime: Remove the exported function pm_children_suspended()"

This reverts commit 62006c1702b3b1be0c0726949e0ee0ea2326be9c which removed pm_children_suspended() because it had only a single caller. We're about to add a second caller, so establish the status quo ante. Cc: Ulf Hansson Cc: Rafael J. Wysocki Signed-off-by: Lukas Wunner ---

[PATCH v5 2/8] PCI: Allow runtime PM on Thunderbolt ports

Currently PCIe ports are only allowed to go to D3 if the BIOS is dated 2015 or newer to avoid potential issues with old chipsets. However for Thunderbolt we know that even the oldest controller, Light Ridge (2010), is able to suspend its ports to D3 just fine. We're about to add runtime PM for

[PATCH v5 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

Hotplug ports generally block their parents from suspending to D3hot as otherwise their interrupts couldn't be delivered. An exception are Thunderbolt host controllers: They have a separate GPIO pin to side-band signal plug events even if the controller is powered down or its parent ports are

[PATCH v5 2/8] PCI: Allow runtime PM on Thunderbolt ports

Currently PCIe ports are only allowed to go to D3 if the BIOS is dated 2015 or newer to avoid potential issues with old chipsets. However for Thunderbolt we know that even the oldest controller, Light Ridge (2010), is able to suspend its ports to D3 just fine. We're about to add runtime PM for

[PATCH v5 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

Hotplug ports generally block their parents from suspending to D3hot as otherwise their interrupts couldn't be delivered. An exception are Thunderbolt host controllers: They have a separate GPIO pin to side-band signal plug events even if the controller is powered down or its parent ports are

[PATCH v5 0/8] Runtime PM for Thunderbolt on Macs

Power down Thunderbolt controllers on Macs when nothing is plugged in to save around 2W per controller. For background info please see the cover letter of v3: https://lkml.org/lkml/2016/12/17/56 Patches [1/8] to [3/8] need an ack from Bjorn and/or Rafael. Patches [4/8] to [6/8] need an ack from

[PATCH v5 0/8] Runtime PM for Thunderbolt on Macs

Power down Thunderbolt controllers on Macs when nothing is plugged in to save around 2W per controller. For background info please see the cover letter of v3: https://lkml.org/lkml/2016/12/17/56 Patches [1/8] to [3/8] need an ack from Bjorn and/or Rafael. Patches [4/8] to [6/8] need an ack from

[PATCH v5 1/8] PCI: Recognize Thunderbolt devices

We're about to allow runtime PM on Thunderbolt ports in pci_bridge_d3_possible() and unblock runtime PM for Thunderbolt host hotplug ports in pci_dev_check_d3cold(). In both cases we need to uniquely identify if a PCI device belongs to a Thunderbolt controller. We also have the need to detect

[PATCH v5 1/8] PCI: Recognize Thunderbolt devices

We're about to allow runtime PM on Thunderbolt ports in pci_bridge_d3_possible() and unblock runtime PM for Thunderbolt host hotplug ports in pci_dev_check_d3cold(). In both cases we need to uniquely identify if a PCI device belongs to a Thunderbolt controller. We also have the need to detect

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, 2017-01-15 at 11:41 -0800, Linus Torvalds wrote: > On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley > wrote: > > > > Can we compromise on "try not to revert a fix ...". > > No. > > It's about timing, and about how serious the regression is. > >

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, 2017-01-15 at 11:41 -0800, Linus Torvalds wrote: > On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley > wrote: > > > > Can we compromise on "try not to revert a fix ...". > > No. > > It's about timing, and about how serious the regression is. > > For example, if this happened in rc7, I

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > > [sounds of rummaging around in the Git tree] > > > > > > I found this commit of yours from ancient history (more than a year ago!): > > > > > > commit

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > > [sounds of rummaging around in the Git tree] > > > > > > I found this commit of yours from ancient history (more than a year ago!): > > > > > > commit 12d560f4ea87030667438a169912380be00cea4b

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley wrote: > > Can we compromise on "try not to revert a fix ...". No. It's about timing, and about how serious the regression is. For example, if this happened in rc7, I would have reverted immediately. No

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley wrote: > > Can we compromise on "try not to revert a fix ...". No. It's about timing, and about how serious the regression is. For example, if this happened in rc7, I would have reverted immediately. No questions asked. In this case, the "fix"

Re: [PATCH v6 0/5] x86: Cleanup and simplify cpu-specific data

Sorry for top-posting but I'm reviving an old thread so I'm excused :-) So looking at those in my mbox, they look like nice cleanup and are not upstream. What's the story, was there a "we don't want them because ..." argument somewhere or what's up? If not, we probably should redo them and get

Re: [PATCH v6 0/5] x86: Cleanup and simplify cpu-specific data

Sorry for top-posting but I'm reviving an old thread so I'm excused :-) So looking at those in my mbox, they look like nice cleanup and are not upstream. What's the story, was there a "we don't want them because ..." argument somewhere or what's up? If not, we probably should redo them and get

Re: [PATCH] KVM: VMX: downgrade warning on unexpected exit code

On Fri, Jan 13, 2017 at 6:59 PM, Radim Krčmář wrote: > 2017-01-02 11:23+0100, Dmitry Vyukov: >> Hello, >> >> I've got the following warning while running syzkaller fuzzer: >> >> WARNING: CPU: 2 PID: 13257 at arch/x86/kvm/vmx.c:8633 >> vmx_handle_exit+0x262b/0x38b0

Re: [PATCH] KVM: VMX: downgrade warning on unexpected exit code

On Fri, Jan 13, 2017 at 6:59 PM, Radim Krčmář wrote: > 2017-01-02 11:23+0100, Dmitry Vyukov: >> Hello, >> >> I've got the following warning while running syzkaller fuzzer: >> >> WARNING: CPU: 2 PID: 13257 at arch/x86/kvm/vmx.c:8633 >> vmx_handle_exit+0x262b/0x38b0 arch/x86/kvm/vmx.c:8633 >> vmx:

Re: [PATCH 1/1] ASoC: fsl_asrc: use dma_transfer_direction enum when calling dmaengine_prep_dma_cyclic

On Sun, Jan 15, 2017 at 01:43:31PM +0100, Nicolas Iooss wrote: > When fsl_asrc_dma_prepare_and_submit() calls > dmaengine_prep_dma_cyclic(), it uses either DMA_TO_DEVICE or > DMA_FROM_DEVICE. These values are both items of dma_data_direction enum, > not of dma_data_direction enum, which is the

Re: [PATCH 1/1] ASoC: fsl_asrc: use dma_transfer_direction enum when calling dmaengine_prep_dma_cyclic

On Sun, Jan 15, 2017 at 01:43:31PM +0100, Nicolas Iooss wrote: > When fsl_asrc_dma_prepare_and_submit() calls > dmaengine_prep_dma_cyclic(), it uses either DMA_TO_DEVICE or > DMA_FROM_DEVICE. These values are both items of dma_data_direction enum, > not of dma_data_direction enum, which is the

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

> > What exactly is the relationship between these devices (a ascii-art tree > > or sysfs tree output might be nice) so I can try to understand what is > > going on here. Hi Greg, Florian A few diagrams and trees which might help understand what is going on. The first diagram comes from the

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

> > What exactly is the relationship between these devices (a ascii-art tree > > or sysfs tree output might be nice) so I can try to understand what is > > going on here. Hi Greg, Florian A few diagrams and trees which might help understand what is going on. The first diagram comes from the

[PATCH] char: ipmi: constify ipmi_smi_handlers structures

Declare ipmi_smi_handlers structures as const as they are only passed as an argument to the function ipmi_register_smi. This argument is of type const, so ipmi_smi_handlers structures having similar properties can be declared const too. Done using Coccinelle: @r1 disable optional_qualifier@

[PATCH] char: ipmi: constify ipmi_smi_handlers structures

Declare ipmi_smi_handlers structures as const as they are only passed as an argument to the function ipmi_register_smi. This argument is of type const, so ipmi_smi_handlers structures having similar properties can be declared const too. Done using Coccinelle: @r1 disable optional_qualifier@

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, 2017-01-15 at 10:54 -0800, Linus Torvalds wrote: > On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley > wrote: > > > > We're not reverting a fix that would cause regressions for others. > > Oh HELL YES we are. > > The rule is that we never break old

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, 2017-01-15 at 10:54 -0800, Linus Torvalds wrote: > On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley > wrote: > > > > We're not reverting a fix that would cause regressions for others. > > Oh HELL YES we are. > > The rule is that we never break old stuff. Some new fix that fixes >

Re: [PATCH linux v1 2/2] drivers: hwmon: hwmon driver for ASPEED AST2400/2500 PWM and Fan tach controller

On 01/09/2017 01:59 PM, Jaghathiswari Rankappagounder Natarajan wrote: The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports. The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer inputs. PWM clock types M, N and 0 are three types just to have three independent PWM

Re: [PATCH linux v1 2/2] drivers: hwmon: hwmon driver for ASPEED AST2400/2500 PWM and Fan tach controller

On 01/09/2017 01:59 PM, Jaghathiswari Rankappagounder Natarajan wrote: The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports. The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer inputs. PWM clock types M, N and 0 are three types just to have three independent PWM

Re: Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker

On 01/15/2017 12:05 PM, Pavel Machek wrote: >>> So regression seems to be between v4.9 and v4.10. Any ideas? >> >> Interesting... seems there are no sound relevant changes after v4.9. >> >> Looks like there are only three commits after v4.9 for sound/soc which >> are built for Nokia N900: >> >>

Re: Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker

On 01/15/2017 12:05 PM, Pavel Machek wrote: >>> So regression seems to be between v4.9 and v4.10. Any ideas? >> >> Interesting... seems there are no sound relevant changes after v4.9. >> >> Looks like there are only three commits after v4.9 for sound/soc which >> are built for Nokia N900: >> >>

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley wrote: > > We're not reverting a fix that would cause regressions for others. Oh HELL YES we are. The rule is that we never break old stuff. Some new fix that fixes something that never used to work, but

Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"

On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley wrote: > > We're not reverting a fix that would cause regressions for others. Oh HELL YES we are. The rule is that we never break old stuff. Some new fix that fixes something that never used to work, but breaks something else, gets reverted very

[PATCH] drm: etnaviv: constify etnaviv_iommu_ops structures

Declare etnaviv_iommu_ops structure as const as it is only used when the reference of one of its field is stored in the ops field of a iommu_domain structure. This ops field is of type const, so etnaviv_iommu_ops structures having similar properties can be declared const too. Done using

[PATCH] drm: etnaviv: constify etnaviv_iommu_ops structures

Declare etnaviv_iommu_ops structure as const as it is only used when the reference of one of its field is stored in the ops field of a iommu_domain structure. This ops field is of type const, so etnaviv_iommu_ops structures having similar properties can be declared const too. Done using

Re: [PATCH linux v2 0/6] drivers: hwmon: Add On-Chip Controller driver

On 01/11/2017 10:10 AM, eajames@gmail.com wrote: From: "Edward A. James" This patchset adds a hwmon driver to support the OCC (On-Chip Controller) on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The OCC is an embedded processor

Re: [PATCH linux v2 0/6] drivers: hwmon: Add On-Chip Controller driver

On 01/11/2017 10:10 AM, eajames@gmail.com wrote: From: "Edward A. James" This patchset adds a hwmon driver to support the OCC (On-Chip Controller) on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The OCC is an embedded processor that provides real time

Re: [PATCH linux v2 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC

On 01/11/2017 10:10 AM, eajames@gmail.com wrote: From: "Edward A. James" Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as well as probe the entire driver from the I2C bus. I2C is the communication method between the BMC and the P8 OCC.

Re: [PATCH linux v2 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC

On 01/11/2017 10:10 AM, eajames@gmail.com wrote: From: "Edward A. James" Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as well as probe the entire driver from the I2C bus. I2C is the communication method between the BMC and the P8 OCC. Signed-off-by: Edward A.

[RFC for GIT] pull-request: add praise to people doing QA

Asking for opinions on lkml and git... Getting enough quality assurance is likely one of the bigger upcoming tasks in the near future. To improve the situation, praise the people already doing that by adding their names to pull requests in the same manner that patch authors are credited. Here is

[RFC for GIT] pull-request: add praise to people doing QA

Asking for opinions on lkml and git... Getting enough quality assurance is likely one of the bigger upcoming tasks in the near future. To improve the situation, praise the people already doing that by adding their names to pull requests in the same manner that patch authors are credited. Here is

Re: [PATCH linux v2 2/6] hwmon: occ: Add sysfs interface

On 01/11/2017 10:10 AM, eajames@gmail.com wrote: From: "Edward A. James" Add a generic mechanism to expose the sensors provided by the OCC in sysfs. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery ---

Re: [PATCH linux v2 2/6] hwmon: occ: Add sysfs interface

On 01/11/2017 10:10 AM, eajames@gmail.com wrote: From: "Edward A. James" Add a generic mechanism to expose the sensors provided by the OCC in sysfs. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ | 62 ++

<    1   2   3   4   5   6   7   >