Re: [v1 0/9] Early boot time stamps for x86

Hi Peter, Thank you for looking at this patchset. Yes, I am certain it is 0 or near 0 on reset on this machine. Because, I actually wondered about it, and used stop watch as an alternative way to verify the result, twice. While, I suspect it is often the case that on reset tsc is 0, it is

Re: [v1 0/9] Early boot time stamps for x86

Hi Peter, Thank you for looking at this patchset. Yes, I am certain it is 0 or near 0 on reset on this machine. Because, I actually wondered about it, and used stop watch as an alternative way to verify the result, twice. While, I suspect it is often the case that on reset tsc is 0, it is

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

On Thu, Mar 23, 2017 at 12:44:18AM +0100, Rafael J. Wysocki wrote: > On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki wrote: > > > > It is not dead. > > > > Platform devices are actually created by it, but they never go away. > > IOW, they should never be created for

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

On Thu, Mar 23, 2017 at 12:44:18AM +0100, Rafael J. Wysocki wrote: > On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki wrote: > > > > It is not dead. > > > > Platform devices are actually created by it, but they never go away. > > IOW, they should never be created for anything hot-removable. >

[RFC PATCH v5 6/6] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table

This patch adds supports for SFDP (JESD216B) 4-byte Address Instruction Table. This table is optional but when available, we parse it to get the 4-byte address op codes supported by the memory. Using these op codes is stateless as opposed to entering the 4-byte address mode or setting the Base

[RFC PATCH v5 6/6] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table

This patch adds supports for SFDP (JESD216B) 4-byte Address Instruction Table. This table is optional but when available, we parse it to get the 4-byte address op codes supported by the memory. Using these op codes is stateless as opposed to entering the 4-byte address mode or setting the Base

Re: [PATCH v3 4/4] arm64: dts: rockchip: add regulator info for Kevin digitizer

Am Mittwoch, 22. März 2017, 11:14:42 CET schrieb Brian Norris: > On Wed, Mar 22, 2017 at 09:26:41AM +0100, Heiko Stuebner wrote: > > Am Montag, 20. März 2017, 16:53:44 CET schrieb Brian Norris: > > > We need to enable this regulator before the digitizer can be used. Wacom > > > recommended waiting

Re: [PATCH v3 4/4] arm64: dts: rockchip: add regulator info for Kevin digitizer

Am Mittwoch, 22. März 2017, 11:14:42 CET schrieb Brian Norris: > On Wed, Mar 22, 2017 at 09:26:41AM +0100, Heiko Stuebner wrote: > > Am Montag, 20. März 2017, 16:53:44 CET schrieb Brian Norris: > > > We need to enable this regulator before the digitizer can be used. Wacom > > > recommended waiting

Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs

On Mon, Mar 20, 2017 at 5:34 AM, Patrick Bellasi wrote: > On 20-Mar 09:26, Vincent Guittot wrote: >> On 20 March 2017 at 04:57, Viresh Kumar wrote: >> > On 19-03-17, 14:34, Rafael J. Wysocki wrote: >> >> From: Rafael J. Wysocki

Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs

On Mon, Mar 20, 2017 at 5:34 AM, Patrick Bellasi wrote: > On 20-Mar 09:26, Vincent Guittot wrote: >> On 20 March 2017 at 04:57, Viresh Kumar wrote: >> > On 19-03-17, 14:34, Rafael J. Wysocki wrote: >> >> From: Rafael J. Wysocki >> >> >> >> The PELT metric used by the schedutil governor

Re: [PATCHv2 10/11] ARM: dts: N900: Add bluetooth

* Rob Herring [170322 14:09]: > On Tue, Mar 21, 2017 at 5:32 PM, Sebastian Reichel wrote: > > Add bcm2048 node and its system clock to the N900 device tree file. > > Apart from that a reference to the new clock has been added to > > wl1251 (which uses it,

Re: [PATCHv2 10/11] ARM: dts: N900: Add bluetooth

* Rob Herring [170322 14:09]: > On Tue, Mar 21, 2017 at 5:32 PM, Sebastian Reichel wrote: > > Add bcm2048 node and its system clock to the N900 device tree file. > > Apart from that a reference to the new clock has been added to > > wl1251 (which uses it, too). > > > > Acked-by: Pavel Machek >

Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

On Tue 2017-02-28 16:16:21, Sakari Ailus wrote: > On Tue, Feb 28, 2017 at 03:09:21PM +0100, Pavel Machek wrote: > > Can I get you to apply this one? :-). > > Let me try to understand again what does that change actually do. I'll find > the time during the rest of this week. > > I'm starting to

Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

On Tue 2017-02-28 16:16:21, Sakari Ailus wrote: > On Tue, Feb 28, 2017 at 03:09:21PM +0100, Pavel Machek wrote: > > Can I get you to apply this one? :-). > > Let me try to understand again what does that change actually do. I'll find > the time during the rest of this week. > > I'm starting to

[PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a multiplexing USB PHY. This USB PHY can operate at least in four modes using pin multiplexing and two control GPIOS: - Pass through companion PHY for the SoC USB PHY - ULPI PHY for the SoC - Pass through USB for the modem - UART

[PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a multiplexing USB PHY. This USB PHY can operate at least in four modes using pin multiplexing and two control GPIOS: - Pass through companion PHY for the SoC USB PHY - ULPI PHY for the SoC - Pass through USB for the modem - UART

[PATCH 1/5] cpufreq: intel_pstate: Support HWP processors in all operation modes

From: Rafael J. Wysocki Currently, some processors supporting HWP are only supported by intel_pstate if HWP is actually going to be used and not supported otherwise which is confusing. Specifically, they are not supported if "intel_pstate=no_hwp" is passed to the

[PATCH 1/5] cpufreq: intel_pstate: Support HWP processors in all operation modes

From: Rafael J. Wysocki Currently, some processors supporting HWP are only supported by intel_pstate if HWP is actually going to be used and not supported otherwise which is confusing. Specifically, they are not supported if "intel_pstate=no_hwp" is passed to the kernel in the command line or

[PATCH 0/5] cpufreq: intel_pstate: HW support changes, limits rework and documentation

Hi All, This series of patches makes changes to intel_pstate that will modify its behavior in visible ways and add documentation describing the driver's interface and behavior after those changes. It is targeted at 4.12. The functional patches are based on the current linux-next branch of the

[PATCH 0/5] cpufreq: intel_pstate: HW support changes, limits rework and documentation

Hi All, This series of patches makes changes to intel_pstate that will modify its behavior in visible ways and add documentation describing the driver's interface and behavior after those changes. It is targeted at 4.12. The functional patches are based on the current linux-next branch of the

[PATCH 2/5] cpufreq: intel_pstate: Use load-based P-state selection more widely

From: Rafael J. Wysocki Extend the set of systems for which intel_pstate will use the "powersave" P-state selection algorithm based on CPU load in the active mode by systems with ACPI preferred profile set to "tablet", "appliance PC", "desktop", or "workstation" (ie.

[PATCH 2/5] cpufreq: intel_pstate: Use load-based P-state selection more widely

From: Rafael J. Wysocki Extend the set of systems for which intel_pstate will use the "powersave" P-state selection algorithm based on CPU load in the active mode by systems with ACPI preferred profile set to "tablet", "appliance PC", "desktop", or "workstation" (ie. everything with a specified

[PATCH 3/5] cpufreq: intel_pstate: Active mode P-state limits rework

From: Rafael J. Wysocki The coordination of P-state limits used by intel_pstate in the active mode (ie. by default) is problematic, because it synchronizes all of the limits (ie. the global ones and the per-policy ones) so as to use one common pair of P-state limits

[PATCH 3/5] cpufreq: intel_pstate: Active mode P-state limits rework

From: Rafael J. Wysocki The coordination of P-state limits used by intel_pstate in the active mode (ie. by default) is problematic, because it synchronizes all of the limits (ie. the global ones and the per-policy ones) so as to use one common pair of P-state limits (min and max) across all CPUs

[PATCH 5/5] cpufreq: intel_pstate: Document the current behavior and user interface

From: Rafael J. Wysocki Add a document describing the current behavior and user space interface of the intel_pstate driver in the RST format and drop the existing outdated intel_pstate.txt document. Also update admin-guide/pm/cpufreq.rst with proper RST references to

[PATCH 4/5] cpufreq: intel_pstate: Avoid transient updates of cpuinfo.max_freq

From: Rafael J. Wysocki Both intel_pstate_verify_policy() and intel_cpufreq_verify_policy() set policy->cpuinfo.max_freq depending on the turbo status, but the updates made by them are discarded by the core, because the policy object passed to them by the core is

[PATCH 5/5] cpufreq: intel_pstate: Document the current behavior and user interface

From: Rafael J. Wysocki Add a document describing the current behavior and user space interface of the intel_pstate driver in the RST format and drop the existing outdated intel_pstate.txt document. Also update admin-guide/pm/cpufreq.rst with proper RST references to the new intel_pstate.rst

[PATCH 4/5] cpufreq: intel_pstate: Avoid transient updates of cpuinfo.max_freq

From: Rafael J. Wysocki Both intel_pstate_verify_policy() and intel_cpufreq_verify_policy() set policy->cpuinfo.max_freq depending on the turbo status, but the updates made by them are discarded by the core, because the policy object passed to them by the core is temporary and cpuinfo.max_freq

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki wrote: > On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel wrote: >> Hi Rafael, >> >> On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote: >>> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki wrote: > On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel wrote: >> Hi Rafael, >> >> On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote: >>> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote: >>> > From: Joerg Roedel >>>

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel wrote: > Hi Rafael, > > On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote: >> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote: >> > From: Joerg Roedel >> > >> > No platform-device is

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel wrote: > Hi Rafael, > > On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote: >> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote: >> > From: Joerg Roedel >> > >> > No platform-device is required for IO(x)APICs, so don't even

Re: [PATCH v2] sched/deadline: Make find_later_rq() choose a closer cpu in topology

On Wed, Mar 22, 2017 at 01:37:28PM +0100, Peter Zijlstra wrote: > On Tue, Mar 21, 2017 at 04:52:24PM +0900, Byungchul Park wrote: > > When cpudl_find() returns any among free_cpus, the cpu might not be > > closer than others, considering sched domain. For example: > > > >this_cpu: 15 > >

Re: [PATCH v2] sched/deadline: Make find_later_rq() choose a closer cpu in topology

On Wed, Mar 22, 2017 at 01:37:28PM +0100, Peter Zijlstra wrote: > On Tue, Mar 21, 2017 at 04:52:24PM +0900, Byungchul Park wrote: > > When cpudl_find() returns any among free_cpus, the cpu might not be > > closer than others, considering sched domain. For example: > > > >this_cpu: 15 > >

[PATCH net-next v4 0/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to

[PATCH net-next v4 0/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to

Re: [PATCH v1] mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd()

On Wed, Mar 22, 2017 at 03:39:00PM +0100, Christian Borntraeger wrote: > On 03/22/2017 01:53 PM, Christian Borntraeger wrote: > > On 03/22/2017 03:31 AM, Naoya Horiguchi wrote: > >> I found the race condition which triggers the following bug when > >> move_pages() and soft offline are called on a

Re: [PATCH v1] mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd()

On Wed, Mar 22, 2017 at 03:39:00PM +0100, Christian Borntraeger wrote: > On 03/22/2017 01:53 PM, Christian Borntraeger wrote: > > On 03/22/2017 03:31 AM, Naoya Horiguchi wrote: > >> I found the race condition which triggers the following bug when > >> move_pages() and soft offline are called on a

race condition in kernel/padata.c

Hey Steffen, WireGuard makes really heavy use of padata, feeding it units of work from different cores in different contexts all at the same time. For the most part, everything has been fine, but one particular user has consistently run into mysterious bugs. He's using a rather old dual core CPU,

race condition in kernel/padata.c

Hey Steffen, WireGuard makes really heavy use of padata, feeding it units of work from different cores in different contexts all at the same time. For the most part, everything has been fine, but one particular user has consistently run into mysterious bugs. He's using a rather old dual core CPU,

[PATCH net-next v4 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to

Re: [PATCH net-next v4 1/2] New kernel function to get IP overhead on a socket.

On Wed, Mar 22, 2017 at 3:59 PM, R. Parameswaran wrote: > > A new function, kernel_sock_ip_overhead(), is provided > to calculate the cumulative overhead imposed by the IP > Header and IP options, if any, on a socket's payload. > The new function returns an overhead of

[PATCH net-next v4 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to

Re: [PATCH net-next v4 1/2] New kernel function to get IP overhead on a socket.

On Wed, Mar 22, 2017 at 3:59 PM, R. Parameswaran wrote: > > A new function, kernel_sock_ip_overhead(), is provided > to calculate the cumulative overhead imposed by the IP > Header and IP options, if any, on a socket's payload. > The new function returns an overhead of zero for sockets > that do

[PATCH net-next v4 1/2] New kernel function to get IP overhead on a socket.

A new function, kernel_sock_ip_overhead(), is provided to calculate the cumulative overhead imposed by the IP Header and IP options, if any, on a socket's payload. The new function returns an overhead of zero for sockets that do not belong to the IPv4 or IPv6 address families. Signed-off-by: R.

[PATCH net-next v4 1/2] New kernel function to get IP overhead on a socket.

A new function, kernel_sock_ip_overhead(), is provided to calculate the cumulative overhead imposed by the IP Header and IP options, if any, on a socket's payload. The new function returns an overhead of zero for sockets that do not belong to the IPv4 or IPv6 address families. Signed-off-by: R.

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

Hi Rafael, On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote: > On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote: > > From: Joerg Roedel > > > > No platform-device is required for IO(x)APICs, so don't even > > create them. > > > > Signed-off-by:

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

Hi Rafael, On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote: > On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote: > > From: Joerg Roedel > > > > No platform-device is required for IO(x)APICs, so don't even > > create them. > > > > Signed-off-by: Joerg Roedel > > If

Re: [PATCHv2 09/11] Bluetooth: add nokia driver

Hi, On Wed, Mar 22, 2017 at 04:26:28PM -0500, Rob Herring wrote: > On Tue, Mar 21, 2017 at 5:32 PM, Sebastian Reichel wrote: > > This adds a driver for the Nokia H4+ protocol, which is used > > at least on the Nokia N9, N900 & N950. > > > > Signed-off-by: Sebastian Reichel

Re: [PATCHv2 09/11] Bluetooth: add nokia driver

Hi, On Wed, Mar 22, 2017 at 04:26:28PM -0500, Rob Herring wrote: > On Tue, Mar 21, 2017 at 5:32 PM, Sebastian Reichel wrote: > > This adds a driver for the Nokia H4+ protocol, which is used > > at least on the Nokia N9, N900 & N950. > > > > Signed-off-by: Sebastian Reichel > > --- > > > +

Re: [RESEND v1] UBI: add debugfs file for tracking PEB state

Zach, I think we can merge this in the next merge window, I have only some minor comments. Am 22.03.2017 um 17:04 schrieb Zach Brown: > From: Ben Shelton > > Add a file under debugfs to allow easy access to the erase count for > each physical erase block on an UBI device.

Re: [RESEND v1] UBI: add debugfs file for tracking PEB state

Zach, I think we can merge this in the next merge window, I have only some minor comments. Am 22.03.2017 um 17:04 schrieb Zach Brown: > From: Ben Shelton > > Add a file under debugfs to allow easy access to the erase count for > each physical erase block on an UBI device. This is useful when

Re: 32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

On Wednesday, March 22, 2017 11:58:55 AM Kees Cook wrote: > On Wed, Mar 22, 2017 at 5:50 AM, Evgenii Shatokhin > wrote: > > On 21.03.2017 23:40, Kees Cook wrote: > >> > >> On Tue, Mar 21, 2017 at 6:54 AM, Evgenii Shatokhin > >> wrote: > >>>

Re: 32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

On Wednesday, March 22, 2017 11:58:55 AM Kees Cook wrote: > On Wed, Mar 22, 2017 at 5:50 AM, Evgenii Shatokhin > wrote: > > On 21.03.2017 23:40, Kees Cook wrote: > >> > >> On Tue, Mar 21, 2017 at 6:54 AM, Evgenii Shatokhin > >> wrote: > >>> > >>> Hi, > >>> > >>> One of my x86 machines with a

Re: [RFC 1/2] firmware class: Add stream_firmware API.

Alan On 3/20/2017 1:34 PM, Alan Tull wrote: On Mon, Mar 20, 2017 at 1:00 PM, Alan Tull wrote: +int +stream_firmware(const struct firmware **firmware_p, const char *name, +struct device *device, size_t offset, size_t length) +{ + size_t ret;

Re: [RFC 1/2] firmware class: Add stream_firmware API.

Alan On 3/20/2017 1:34 PM, Alan Tull wrote: On Mon, Mar 20, 2017 at 1:00 PM, Alan Tull wrote: +int +stream_firmware(const struct firmware **firmware_p, const char *name, +struct device *device, size_t offset, size_t length) +{ + size_t ret; + + /* Need to pin

Re: [PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

* Sebastian Reichel [170321 19:20]: > Hi, > > On Thu, Mar 16, 2017 at 08:51:52PM -0700, Tony Lindgren wrote: > > Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a > > multiplexing USB PHY. > > > > This USB PHY can operate at least in four modes using pin

Re: [PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

* Sebastian Reichel [170321 19:20]: > Hi, > > On Thu, Mar 16, 2017 at 08:51:52PM -0700, Tony Lindgren wrote: > > Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a > > multiplexing USB PHY. > > > > This USB PHY can operate at least in four modes using pin multiplexing > > and

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Wed 22 Mar 11:44 PDT 2017, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 20 Mar 2017 16:35:42 -0700 > > > By moving these client drivers to use RPMSG instead of the direct SMD > > API we can reuse them ontop of the newly added GLINK wire-protocol > >

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Wed 22 Mar 11:44 PDT 2017, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 20 Mar 2017 16:35:42 -0700 > > > By moving these client drivers to use RPMSG instead of the direct SMD > > API we can reuse them ontop of the newly added GLINK wire-protocol > > support found in the 820 and

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Wed, Mar 22, 2017 at 11:44:39AM -0700, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 20 Mar 2017 16:35:42 -0700 > > > By moving these client drivers to use RPMSG instead of the direct SMD > > API we can reuse them ontop of the newly added GLINK

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Wed, Mar 22, 2017 at 11:44:39AM -0700, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 20 Mar 2017 16:35:42 -0700 > > > By moving these client drivers to use RPMSG instead of the direct SMD > > API we can reuse them ontop of the newly added GLINK wire-protocol > > support found in

Re: [PATCH 3/3] soc: qcom: smd-rpm: Add msm8996 compatibility

On Mon, Mar 20, 2017 at 04:35:44PM -0700, Bjorn Andersson wrote: > With the RPM driver transitioned to RPMSG we can reuse the SMD-RPM > driver ontop of GLINK for 8996, without any modifications. > > Signed-off-by: Bjorn Andersson Acked-by: Andy Gross

Re: [PATCH 3/3] soc: qcom: smd-rpm: Add msm8996 compatibility

On Mon, Mar 20, 2017 at 04:35:44PM -0700, Bjorn Andersson wrote: > With the RPM driver transitioned to RPMSG we can reuse the SMD-RPM > driver ontop of GLINK for 8996, without any modifications. > > Signed-off-by: Bjorn Andersson Acked-by: Andy Gross

Re: [PATCH 2/3] soc: qcom: smd: Remove standalone driver

On Mon, Mar 20, 2017 at 04:35:43PM -0700, Bjorn Andersson wrote: > Remove the standalone SMD implementation as we have transitioned the > client drivers to use the RPMSG based one. > > Also remove all dependencies on QCOM_SMD from Kconfig files, in order to > keep them selectable in the absence

Re: [PATCH 2/3] soc: qcom: smd: Remove standalone driver

On Mon, Mar 20, 2017 at 04:35:43PM -0700, Bjorn Andersson wrote: > Remove the standalone SMD implementation as we have transitioned the > client drivers to use the RPMSG based one. > > Also remove all dependencies on QCOM_SMD from Kconfig files, in order to > keep them selectable in the absence

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Mon, Mar 20, 2017 at 04:35:42PM -0700, Bjorn Andersson wrote: > By moving these client drivers to use RPMSG instead of the direct SMD > API we can reuse them ontop of the newly added GLINK wire-protocol > support found in the 820 and 835 Qualcomm platforms. > > As the new (RPMSG-based) and old

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

On Mon, Mar 20, 2017 at 04:35:42PM -0700, Bjorn Andersson wrote: > By moving these client drivers to use RPMSG instead of the direct SMD > API we can reuse them ontop of the newly added GLINK wire-protocol > support found in the 820 and 835 Qualcomm platforms. > > As the new (RPMSG-based) and old

Re: [PATCH v2 1/9] Coccinelle: locks: identify callers of spin_lock{,_irq,_irqsave}() in irqchip implementations

On Wed, 22 Mar 2017, Julia Cartwright wrote: > On Wed, Mar 22, 2017 at 10:54:15AM +0100, Julia Lawall wrote: > > On Tue, 21 Mar 2017, Julia Cartwright wrote: > > > On PREEMPT_RT, the spinlock_t type becomes an object which sleeps under > > > contention. The codepaths used to support scheduling

Re: [PATCH v2 1/9] Coccinelle: locks: identify callers of spin_lock{,_irq,_irqsave}() in irqchip implementations

On Wed, 22 Mar 2017, Julia Cartwright wrote: > On Wed, Mar 22, 2017 at 10:54:15AM +0100, Julia Lawall wrote: > > On Tue, 21 Mar 2017, Julia Cartwright wrote: > > > On PREEMPT_RT, the spinlock_t type becomes an object which sleeps under > > > contention. The codepaths used to support scheduling

Re: [Outreachy kernel] [PATCH v2] staging: iio: Replace a bit shift by a use of BIT.

On Wed, 22 Mar 2017, Arushi Singhal wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro. > This was done with coccinelle: > @@ > constant c; > @@ > > -1 << c > +BIT(c) > > Signed-off-by: Arushi Singhal > --- > changes in v2 > -remove/correct

Re: [Outreachy kernel] [PATCH v2] staging: iio: Replace a bit shift by a use of BIT.

On Wed, 22 Mar 2017, Arushi Singhal wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro. > This was done with coccinelle: > @@ > constant c; > @@ > > -1 << c > +BIT(c) > > Signed-off-by: Arushi Singhal > --- > changes in v2 > -remove/correct the wrong code. > >

Re: [Nbd] [RFC PATCH 1/1] nbd: replace kill_bdev() with __invalidate_device()

Hey sorry I just got back from LSF, I’ll look at this in the morning. Thanks, Josef On 3/22/17, 4:48 PM, "Ming Lin" wrote: On Mon, Mar 20, 2017 at 3:58 PM, Ming Lin wrote: > From: Ratna Manoj Bolla > > When a filesystem is mounted on a

Re: [Nbd] [RFC PATCH 1/1] nbd: replace kill_bdev() with __invalidate_device()

Hey sorry I just got back from LSF, I’ll look at this in the morning. Thanks, Josef On 3/22/17, 4:48 PM, "Ming Lin" wrote: On Mon, Mar 20, 2017 at 3:58 PM, Ming Lin wrote: > From: Ratna Manoj Bolla > > When a filesystem is mounted on a nbd device and on a disconnect, because > of

RE: [PATCH v2 2/4] x86/mce/AMD; EDAC,amd64: Move find_umc_channel() to AMD mcheck

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, March 22, 2017 5:17 PM > To: Ghannam, Yazen > Cc: linux-e...@vger.kernel.org; Tony Luck ; > x...@kernel.org; linux-kernel@vger.kernel.org > Subject: Re:

RE: [PATCH v2 2/4] x86/mce/AMD; EDAC,amd64: Move find_umc_channel() to AMD mcheck

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, March 22, 2017 5:17 PM > To: Ghannam, Yazen > Cc: linux-e...@vger.kernel.org; Tony Luck ; > x...@kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 2/4] x86/mce/AMD; EDAC,amd64: Move >

RE: [PATCH v2 4/4] x86/mce: Add AMD SMCA support to SRAO notifier

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, March 22, 2017 5:13 PM > To: Ghannam, Yazen > Cc: linux-e...@vger.kernel.org; Tony Luck ; > x...@kernel.org; linux-kernel@vger.kernel.org > Subject: Re:

RE: [PATCH v2 4/4] x86/mce: Add AMD SMCA support to SRAO notifier

> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Wednesday, March 22, 2017 5:13 PM > To: Ghannam, Yazen > Cc: linux-e...@vger.kernel.org; Tony Luck ; > x...@kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 4/4] x86/mce: Add AMD SMCA support to

Re: [RESEND PATCH v2 00/53] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb

Hi Masahiro, On Thu, 23 Mar 2017 05:06:59 +0900 Masahiro Yamada wrote: > It took a couple months to update this series, but finally here is v2. > (v1: https://lkml.org/lkml/2016/11/26/144 ) > > This driver includes many problems. > > One of the biggest one is a

Re: [RESEND PATCH v2 00/53] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb

Hi Masahiro, On Thu, 23 Mar 2017 05:06:59 +0900 Masahiro Yamada wrote: > It took a couple months to update this series, but finally here is v2. > (v1: https://lkml.org/lkml/2016/11/26/144 ) > > This driver includes many problems. > > One of the biggest one is a bunch of hard-coded parameters.

Re: [RESEND PATCH v2 26/53] mtd: nand: denali: support 1024 byte ECC step size

On Thu, 23 Mar 2017 05:07:25 +0900 Masahiro Yamada wrote: > This driver was originally written for the Intel MRST platform with > several platform specific parameters hard-coded. Another thing we > need to fix is the hard-coded ECC step size. Currently, it is >

Re: [RESEND PATCH v2 26/53] mtd: nand: denali: support 1024 byte ECC step size

On Thu, 23 Mar 2017 05:07:25 +0900 Masahiro Yamada wrote: > This driver was originally written for the Intel MRST platform with > several platform specific parameters hard-coded. Another thing we > need to fix is the hard-coded ECC step size. Currently, it is > defined as follows: > >

[PATCH 5/7] x86/gdt: Get rid of the get_*_gdt_*_vaddr() helpers

There's a single caller that is only there because it's passing a pointer into a function (vmcs_writel()) that takes an unsigned long. Let's just cast it in place rather than having a bunch of trivial helpers. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 20

[PATCH 5/7] x86/gdt: Get rid of the get_*_gdt_*_vaddr() helpers

There's a single caller that is only there because it's passing a pointer into a function (vmcs_writel()) that takes an unsigned long. Let's just cast it in place rather than having a bunch of trivial helpers. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 20

[PATCH 4/7] x86/boot/32: Defer resyncing initial_page_table until percpu is set up

The x86 smpboot trampoline expects initial_page_table to have the GDT mapped. If the GDT ends up in a virtually mapped percpu page, then it won't be in the page tables at all until percpu areas are set up. The result will be a triple fault the first time that the CPU attempts to access the GDT

[PATCH 4/7] x86/boot/32: Defer resyncing initial_page_table until percpu is set up

The x86 smpboot trampoline expects initial_page_table to have the GDT mapped. If the GDT ends up in a virtually mapped percpu page, then it won't be in the page tables at all until percpu areas are set up. The result will be a triple fault the first time that the CPU attempts to access the GDT

[PATCH 6/7] x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup

Xen imposes special requirements on the GDT. Rather than using a global variable for the pgprot, just use an explicit special case for Xen -- this makes it clearer what's going on. It also debloats 64-bit kernels very slightly. Cc: Boris Ostrovsky Cc: Juergen Gross

[PATCH 6/7] x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup

Xen imposes special requirements on the GDT. Rather than using a global variable for the pgprot, just use an explicit special case for Xen -- this makes it clearer what's going on. It also debloats 64-bit kernels very slightly. Cc: Boris Ostrovsky Cc: Juergen Gross Signed-off-by: Andy

[PATCH 2/7] x86/gdt: Fix setup_fixmap_gdt() to use the correct PA

__pa() cannot be used on percpu pointers because they may be virtually mapped. Use per_cpu_ptr_to_phys() instead. This fixes a boot crash on a some 32-bit configurations. I assume this is related to which allocation strategy is chosen by the percpu core. Fixes: 69218e47994d x86: ("Remap GDT

[PATCH 2/7] x86/gdt: Fix setup_fixmap_gdt() to use the correct PA

__pa() cannot be used on percpu pointers because they may be virtually mapped. Use per_cpu_ptr_to_phys() instead. This fixes a boot crash on a some 32-bit configurations. I assume this is related to which allocation strategy is chosen by the percpu core. Fixes: 69218e47994d x86: ("Remap GDT

[PATCH 3/7] x86/efi/32: Fix EFI on systems where the percpu GDT is virtually mapped

__pa on a percpu pointer is invalid. This bug appears to go *waaay* back, and I guess it's just never been triggered. Cc: Matt Fleming Cc: Ard Biesheuvel Cc: linux-...@vger.kernel.org Signed-off-by: Andy Lutomirski ---

[PATCH 3/7] x86/efi/32: Fix EFI on systems where the percpu GDT is virtually mapped

__pa on a percpu pointer is invalid. This bug appears to go *waaay* back, and I guess it's just never been triggered. Cc: Matt Fleming Cc: Ard Biesheuvel Cc: linux-...@vger.kernel.org Signed-off-by: Andy Lutomirski --- arch/x86/platform/efi/efi_32.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 1/7] selftests/x86/ldt_gdt_32: Work around a glibc sigaction bug

i386 glibc is buggy and calls the sigaction syscall incorrectly. This is asymptomatic for normal programs, but it blows up on programs that do evil things with segmentation. ldt_gdt an example of such an evil program. This doesn't appear to be a regression -- I think I just got lucky with the

[PATCH 1/7] selftests/x86/ldt_gdt_32: Work around a glibc sigaction bug

i386 glibc is buggy and calls the sigaction syscall incorrectly. This is asymptomatic for normal programs, but it blows up on programs that do evil things with segmentation. ldt_gdt an example of such an evil program. This doesn't appear to be a regression -- I think I just got lucky with the

[PATCH 7/7] x86/boot/32: Rewrite test_wp_bit()

This code seems to be very old and has gotten only minor updates. Nowadays we have a shiny function probe_kernel_write() that does more or less exactly what we need. Use it. While we're at it, remove cpuinfo_x86::wp_works_ok, since we panic on kernels where wp doesn't work okay. Signed-off-by:

[PATCH 7/7] x86/boot/32: Rewrite test_wp_bit()

This code seems to be very old and has gotten only minor updates. Nowadays we have a shiny function probe_kernel_write() that does more or less exactly what we need. Use it. While we're at it, remove cpuinfo_x86::wp_works_ok, since we panic on kernels where wp doesn't work okay. Signed-off-by:

[PATCH 0/7] Misc GDT fixes and a cleanup

Hi all- This applies to tip:x86/mm. For ease of testing, the series is here, too: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/tag/?h=review_20170322_gdt_and_wp This fixes a few issues, most of which appear to be rather old. For whatever reason, Thomas' GDT series unearthed

[PATCH 0/7] Misc GDT fixes and a cleanup

Hi all- This applies to tip:x86/mm. For ease of testing, the series is here, too: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/tag/?h=review_20170322_gdt_and_wp This fixes a few issues, most of which appear to be rather old. For whatever reason, Thomas' GDT series unearthed

Re: [PATCH] asm-generic: fix compilation failure in cmpxchg_double()

On Wed, Mar 22, 2017 at 12:27 PM, Arnd Bergmann wrote: > On Wed, Mar 22, 2017 at 12:10 PM, Dmitry Vyukov wrote: >> Arnd reported that the new code leads to compilation failures >> with some versions of gcc. I've filed gcc issue 72873, >> but we need a kernel

Re: [PATCH] asm-generic: fix compilation failure in cmpxchg_double()

On Wed, Mar 22, 2017 at 12:27 PM, Arnd Bergmann wrote: > On Wed, Mar 22, 2017 at 12:10 PM, Dmitry Vyukov wrote: >> Arnd reported that the new code leads to compilation failures >> with some versions of gcc. I've filed gcc issue 72873, >> but we need a kernel fix as well. >> >> Remove

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