From: Long Li
The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will
return an invalid DMA address for a buffer on stack. Even worse, this
incorrect address can't be detected by ib_dma_mapping_error. Sending data
from this address to hardware will not
Hi Dan,
On 04/19/2018 12:15 AM, Dan Carpenter wrote:
Several people have asked me to write this and I think one person was
maybe working on writing it themselves...
The point of this check is to find place which might be vulnerable to
the Spectre vulnerability. In the kernel we have the
From: Long Li
The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will
return an invalid DMA address for a buffer on stack. Even worse, this
incorrect address can't be detected by ib_dma_mapping_error. Sending data
from this address to hardware will not fail, but the remote
Hi Dan,
On 04/19/2018 12:15 AM, Dan Carpenter wrote:
Several people have asked me to write this and I think one person was
maybe working on writing it themselves...
The point of this check is to find place which might be vulnerable to
the Spectre vulnerability. In the kernel we have the
> From: Jan Kara
> Sent: Thursday, April 19, 2018 13:23
> Good news guys, Robert has just spotted a bug which looks like what I'd
> expect can cause your lockups / crashes. I've merged his patch to my tree
> and will push it to Linus for -rc3 so eventually it should land in
> appropriate stable
> From: Jan Kara
> Sent: Thursday, April 19, 2018 13:23
> Good news guys, Robert has just spotted a bug which looks like what I'd
> expect can cause your lockups / crashes. I've merged his patch to my tree
> and will push it to Linus for -rc3 so eventually it should land in
> appropriate stable
Hi Uwe,
On 16.04.2018 17:35, Stefan Agner wrote:
> To reset the UART the SRST needs be cleared (low active). According
> to the documentation the bit will remain active for 4 module clocks
> until it is cleared (set to 1).
>
> Hence the real register need to be read in case the cached register
>
Hi Uwe,
On 16.04.2018 17:35, Stefan Agner wrote:
> To reset the UART the SRST needs be cleared (low active). According
> to the documentation the bit will remain active for 4 module clocks
> until it is cleared (set to 1).
>
> Hence the real register need to be read in case the cached register
>
On Tue, Apr 03, 2018 at 08:02:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +)
> Merge tag 'pm-4.17-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> syzbot
On Tue, Apr 03, 2018 at 08:02:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +)
> Merge tag 'pm-4.17-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> syzbot
On Thu, 19 Apr 2018, Michael S. Tsirkin wrote:
> Maybe make it conditional on CONFIG_DEBUG_SG too?
> Otherwise I think you just trigger a hard to debug memory corruption.
OK, here I resend the patch with CONFIG_DEBUG_SG. With CONFIG_DEBUG_SG,
the DMA API will print a stacktrace where the
On Thu, 19 Apr 2018, Michael S. Tsirkin wrote:
> Maybe make it conditional on CONFIG_DEBUG_SG too?
> Otherwise I think you just trigger a hard to debug memory corruption.
OK, here I resend the patch with CONFIG_DEBUG_SG. With CONFIG_DEBUG_SG,
the DMA API will print a stacktrace where the
On 04/18/2018 12:59 PM, Andrew Morton wrote:
> Dave, fb43d6cb91ef57 ("x86/mm: Do not auto-massage page protections")
> looks like a culprit?
This looks like a problem when a 32-bit kernel runs on hardware without
NX support. I'm digging into it but haven't found a root cause yet.
On 04/18/2018 12:59 PM, Andrew Morton wrote:
> Dave, fb43d6cb91ef57 ("x86/mm: Do not auto-massage page protections")
> looks like a culprit?
This looks like a problem when a 32-bit kernel runs on hardware without
NX support. I'm digging into it but haven't found a root cause yet.
On Thu, Apr 19, 2018 at 2:16 PM, Pavlos Parissis
wrote:
> On 19/04/2018 10:23 μμ, Jan Kara wrote:
>> On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
>>> On 17/04/2018 02:12 μμ, Jan Kara wrote:
On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> On 16/04/2018
On Thu, Apr 19, 2018 at 2:16 PM, Pavlos Parissis
wrote:
> On 19/04/2018 10:23 μμ, Jan Kara wrote:
>> On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
>>> On 17/04/2018 02:12 μμ, Jan Kara wrote:
On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> On 16/04/2018 04:40 μμ, Jan Kara wrote:
On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote:
> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman
> wrote:
>> I suspect you want to use __kernel_ulong_t here instead of a raw
>> unsigned long. If nothing else it seems inconsistent to use typedefs
On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann wrote:
> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman
> wrote:
>> I suspect you want to use __kernel_ulong_t here instead of a raw
>> unsigned long. If nothing else it seems inconsistent to use typedefs
>> in one half of the structure and no
On 4/19/2018 10:43 AM, Johannes Thumshirn wrote:
Provide a descriptive error in case an lport to rport association
isn't found when creating the FC-NVME controller.
Currently it's very hard to debug the reason for a failed connect
attempt without a look at the source.
Signed-off-by: Johannes
On 4/19/2018 10:43 AM, Johannes Thumshirn wrote:
Provide a descriptive error in case an lport to rport association
isn't found when creating the FC-NVME controller.
Currently it's very hard to debug the reason for a failed connect
attempt without a look at the source.
Signed-off-by: Johannes
On Thu, 19 Apr 2018, Andrew Morton wrote:
> On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka
> wrote:
>
> > The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> > kmalloc fails.
> >
> > Unfortunatelly, some kernel code has bugs - it uses
On Thu, 19 Apr 2018, Andrew Morton wrote:
> On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka
> wrote:
>
> > The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> > kmalloc fails.
> >
> > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> >
On 19/04/2018 10:23 μμ, Jan Kara wrote:
> On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
>> On 17/04/2018 02:12 μμ, Jan Kara wrote:
>>> On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
On 16/04/2018 04:40 μμ, Jan Kara wrote:
>>>
>>>
>>>
> How easily can you hit this?
Very
On 19/04/2018 10:23 μμ, Jan Kara wrote:
> On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
>> On 17/04/2018 02:12 μμ, Jan Kara wrote:
>>> On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
On 16/04/2018 04:40 μμ, Jan Kara wrote:
>>>
>>>
>>>
> How easily can you hit this?
Very
Introduces a new function to reset the crypto attributes for all
vcpus whether they are running or not. Each vcpu in KVM will
be removed from SIE prior to resetting the crypto attributes in its
SIE state description. After all vcpus have had their crypto attributes
reset the vcpus will be restored
Introduces a new function to reset the crypto attributes for all
vcpus whether they are running or not. Each vcpu in KVM will
be removed from SIE prior to resetting the crypto attributes in its
SIE state description. After all vcpus have had their crypto attributes
reset the vcpus will be restored
From: Bjorn Helgaas
When in the ASPM L1.0 state (but not the PCI-PM L1.0 state), the most
recent LTR value and the LTR_L1.2_THRESHOLD determines whether the link
enters the L1.2 substate.
If we don't have LTR enabled, prevent the use of ASPM L1.2.
PCI-PM L1.2 may still be
From: Bjorn Helgaas
When in the ASPM L1.0 state (but not the PCI-PM L1.0 state), the most
recent LTR value and the LTR_L1.2_THRESHOLD determines whether the link
enters the L1.2 substate.
If we don't have LTR enabled, prevent the use of ASPM L1.2.
PCI-PM L1.2 may still be used because it
From: Bjorn Helgaas
Per the PCI Firmware spec r3.2, sec 4.5, an ACPI-based OS should use _OSC
to request control of Latency Tolerance Reporting (LTR) before using it.
Request control of LTR, and if the platform does not grant control, don't
use it.
N.B. If the hardware
From: Bjorn Helgaas
Per the PCI Firmware spec r3.2, sec 4.5, an ACPI-based OS should use _OSC
to request control of Latency Tolerance Reporting (LTR) before using it.
Request control of LTR, and if the platform does not grant control, don't
use it.
N.B. If the hardware supports LTR and the
The ASPM L1.2 substate depends on LTR information. Per the PCI
Firmware spec, the OS is supposed to negotiate with the platform for
control of the LTR feature, but previously we didn't do that.
In addition, we must not enable LTR in an endpoint unless the Root
Complex and all intermediate
The ASPM L1.2 substate depends on LTR information. Per the PCI
Firmware spec, the OS is supposed to negotiate with the platform for
control of the LTR feature, but previously we didn't do that.
In addition, we must not enable LTR in an endpoint unless the Root
Complex and all intermediate
On 04/19/2018 04:39 PM, Alexey Dobriyan wrote:
>>
>> Yes, that can probably help.
>>
>> This is the data from the problematic skylake server:
>>
>> model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz
>> 56 sosreport-carevalo.02076935-20180413085327/proc/stat
>> Interrupts: 5370
>> Interrupts
On 04/19/2018 04:39 PM, Alexey Dobriyan wrote:
>>
>> Yes, that can probably help.
>>
>> This is the data from the problematic skylake server:
>>
>> model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz
>> 56 sosreport-carevalo.02076935-20180413085327/proc/stat
>> Interrupts: 5370
>> Interrupts
On 04/19/2018 04:39 PM, Alexey Dobriyan wrote:
> On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote:
>> On 04/19/2018 03:55 PM, Alexey Dobriyan wrote:
>>> On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote:
On 04/19/2018 03:08 PM, Alexey Dobriyan wrote:
>> Therefore,
On 04/19/2018 04:39 PM, Alexey Dobriyan wrote:
> On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote:
>> On 04/19/2018 03:55 PM, Alexey Dobriyan wrote:
>>> On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote:
On 04/19/2018 03:08 PM, Alexey Dobriyan wrote:
>> Therefore,
On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote:
> We quiesce and freeze the queue before tearing it down, so it won't be
> NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you,
> though ;)
blk_cleanup_queue() waits until all I/O requests have finished. Since the
block
On Thu, 2018-04-19 at 12:24 -0700, Omar Sandoval wrote:
> We quiesce and freeze the queue before tearing it down, so it won't be
> NULL while we're still doing I/O. Cc'ing Bart in case I'm lying to you,
> though ;)
blk_cleanup_queue() waits until all I/O requests have finished. Since the
block
Hi Wolfram,
On 04/19/2018 11:00 PM, Wolfram Sang wrote:
> There are no platform_data users anymore. Move the structs into the
> driver.
>
> Signed-off-by: Wolfram Sang
Acked-by: Vladimir Zapolskiy
Thank you for the nice change!
--
With best wishes,
Hi Wolfram,
On 04/19/2018 11:00 PM, Wolfram Sang wrote:
> There are no platform_data users anymore. Move the structs into the
> driver.
>
> Signed-off-by: Wolfram Sang
Acked-by: Vladimir Zapolskiy
Thank you for the nice change!
--
With best wishes,
Vladimir
On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote:
> On 04/19/2018 03:55 PM, Alexey Dobriyan wrote:
> > On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote:
> >> On 04/19/2018 03:08 PM, Alexey Dobriyan wrote:
> Therefore, application performance can be impacted if the
On Thu, Apr 19, 2018 at 04:21:14PM -0400, Waiman Long wrote:
> On 04/19/2018 03:55 PM, Alexey Dobriyan wrote:
> > On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote:
> >> On 04/19/2018 03:08 PM, Alexey Dobriyan wrote:
> Therefore, application performance can be impacted if the
On 4/19/2018 4:26 PM, Jason Gunthorpe wrote:
> On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote:
>> The infiniband adapter might be connected to a PCI hotplug slot. Performing
>> secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
>>
>> Hotplug driver removes the
On 4/19/2018 4:26 PM, Jason Gunthorpe wrote:
> On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote:
>> The infiniband adapter might be connected to a PCI hotplug slot. Performing
>> secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
>>
>> Hotplug driver removes the
From: "Michael S. Tsirkin"
Date: Thu, 19 Apr 2018 08:30:47 +0300
> Here are a couple of fixes related to the virtio control buffer.
> Lightly tested on x86 only.
Thanks for taking care of the control buffer DMA'ability issue.
Want any of these queued up for -stable?
From: "Michael S. Tsirkin"
Date: Thu, 19 Apr 2018 08:30:47 +0300
> Here are a couple of fixes related to the virtio control buffer.
> Lightly tested on x86 only.
Thanks for taking care of the control buffer DMA'ability issue.
Want any of these queued up for -stable?
On Thu, Apr 19, 2018 at 9:31 AM, David Howells wrote:
> Add LSM hooks for use by the filesystem context code. This includes:
>
> (1) Hooks to handle allocation, duplication and freeing of the security
> record attached to a filesystem context.
>
> (2) A hook to snoop
On Thu, Apr 19, 2018 at 9:31 AM, David Howells wrote:
> Add LSM hooks for use by the filesystem context code. This includes:
>
> (1) Hooks to handle allocation, duplication and freeing of the security
> record attached to a filesystem context.
>
> (2) A hook to snoop a mount options in
From: dann frazier
Date: Wed, 18 Apr 2018 21:55:41 -0600
> When longer interface names are used, the action names exposed in
> /proc/interrupts and /proc/irq/* maybe truncated. For example, when
> using the predictable name algorithm in systemd on a HiSilicon D05,
> I
From: dann frazier
Date: Wed, 18 Apr 2018 21:55:41 -0600
> When longer interface names are used, the action names exposed in
> /proc/interrupts and /proc/irq/* maybe truncated. For example, when
> using the predictable name algorithm in systemd on a HiSilicon D05,
> I see:
>
> ubuntu@d05-3:~$
On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote:
> The infiniband adapter might be connected to a PCI hotplug slot. Performing
> secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
>
> Hotplug driver removes the device from system when a link down interrupt
> is
On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote:
> The infiniband adapter might be connected to a PCI hotplug slot. Performing
> secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
>
> Hotplug driver removes the device from system when a link down interrupt
> is
* Wolfram Sang [180419 20:02]:
> This header only contains platform_data. Move it to the proper directory.
Acked-by: Tony Lindgren
* Wolfram Sang [180419 20:02]:
> This header only contains platform_data. Move it to the proper directory.
Acked-by: Tony Lindgren
* Wolfram Sang [180419 20:02]:
> This header only contains platform_data. Move it to the proper directory.
Acked-by: Tony Lindgren
* Wolfram Sang [180419 20:02]:
> This header only contains platform_data. Move it to the proper directory.
Acked-by: Tony Lindgren
On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
> On 17/04/2018 02:12 μμ, Jan Kara wrote:
> > On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> >> On 16/04/2018 04:40 μμ, Jan Kara wrote:
> >
> >
> >
> >>> How easily can you hit this?
> >>
> >> Very easily, I only need to wait 1-2 days for a
On Wed 18-04-18 10:32:21, Pavlos Parissis wrote:
> On 17/04/2018 02:12 μμ, Jan Kara wrote:
> > On Tue 17-04-18 01:31:24, Pavlos Parissis wrote:
> >> On 16/04/2018 04:40 μμ, Jan Kara wrote:
> >
> >
> >
> >>> How easily can you hit this?
> >>
> >> Very easily, I only need to wait 1-2 days for a
On Wed 2018-04-18 15:00:41, Mark Brown wrote:
> On Wed, Apr 18, 2018 at 03:29:36PM +0200, Geert Uytterhoeven wrote:
>
> > Any comments/suggestions?
>
> > In case you lost the patches from the thread:
> > https://www.spinics.net/lists/linux-renesas-soc/msg24955.html
>
> Please don't send content
On Wed 2018-04-18 15:00:41, Mark Brown wrote:
> On Wed, Apr 18, 2018 at 03:29:36PM +0200, Geert Uytterhoeven wrote:
>
> > Any comments/suggestions?
>
> > In case you lost the patches from the thread:
> > https://www.spinics.net/lists/linux-renesas-soc/msg24955.html
>
> Please don't send content
On Thu 19-04-18 12:44:56, Theodore Y. Ts'o wrote:
> On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote:
> > On Mon 19-03-18 16:34:09, zhenwei.pi wrote:
> > > "mark_unwritten" in comment and "unwritten" in variable
> > > argument lists is mismatch.
> > >
> > > Signed-off-by: zhenwei.pi
On Thu 19-04-18 12:44:56, Theodore Y. Ts'o wrote:
> On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote:
> > On Mon 19-03-18 16:34:09, zhenwei.pi wrote:
> > > "mark_unwritten" in comment and "unwritten" in variable
> > > argument lists is mismatch.
> > >
> > > Signed-off-by: zhenwei.pi
> >
Jason Andryuk:
> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
> wrote:
>> Jason Andryuk:
>>> A toolstack may delete the vif frontend and backend xenstore entries
>>> while xen-netfront is in the removal code path. In that case, the
>>> checks for
Jason Andryuk:
> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
> wrote:
>> Jason Andryuk:
>>> A toolstack may delete the vif frontend and backend xenstore entries
>>> while xen-netfront is in the removal code path. In that case, the
>>> checks for xenbus_read_driver_state would return
On Thu, Apr 19, 2018 at 04:06:29PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Guenter Roeck
>
On Thu, Apr 19, 2018 at 04:06:29PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Guenter Roeck
> ---
>
> Build tested only. buildbot is happy. Please
On Thu, Apr 19, 2018 at 04:03:05PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote:
> > >
> > > Can you try 'git bisect'? I'll hold off on releasing 4.9.y until this
> > > gets figured out.
> >
> > After reverting this patch, network started
On Thu, Apr 19, 2018 at 04:03:05PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 19, 2018 at 04:42:56PM +0530, Naresh Kamboju wrote:
> > >
> > > Can you try 'git bisect'? I'll hold off on releasing 4.9.y until this
> > > gets figured out.
> >
> > After reverting this patch, network started
On Thu, Apr 19, 2018 at 12:43:19PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote:
>
> > It was found that reading /proc/stat could be time consuming on
> > systems with a lot of irqs. For example, reading /proc/stat in a
> > certain
On Thu, Apr 19, 2018 at 12:43:19PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote:
>
> > It was found that reading /proc/stat could be time consuming on
> > systems with a lot of irqs. For example, reading /proc/stat in a
> > certain 2-socket Skylake server
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/busses/i2c-ocores| 2 +-
drivers/i2c/busses/i2c-ocores.c| 2 +-
drivers/mfd/timberdale.c | 2 +-
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/busses/i2c-ocores| 2 +-
drivers/i2c/busses/i2c-ocores.c| 2 +-
drivers/mfd/timberdale.c | 2 +-
include/linux/{ =>
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/muxes/i2c-mux-gpio | 4 ++--
MAINTAINERS | 2 +-
drivers/i2c/busses/i2c-i801.c| 2
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
MAINTAINERS | 4 ++--
arch/arm/mach-omap1/common.h | 2 +-
arch/arm/mach-omap1/i2c.c| 2 +-
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/muxes/i2c-mux-gpio | 4 ++--
MAINTAINERS | 2 +-
drivers/i2c/busses/i2c-i801.c| 2 +-
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
MAINTAINERS | 4 ++--
arch/arm/mach-omap1/common.h | 2 +-
arch/arm/mach-omap1/i2c.c| 2 +-
arch/arm/mach-omap2/common.h
There are no platform_data users anymore. Move the structs into the
driver.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-pnx.c | 21 -
include/linux/i2c-pnx.h | 38 --
2 files changed, 20 insertions(+),
There are no platform_data users anymore. Move the structs into the
driver.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-pnx.c | 21 -
include/linux/i2c-pnx.h | 38 --
2 files changed, 20 insertions(+), 39 deletions(-)
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
arch/sh/boards/board-sh7785lcr.c | 2 +-
drivers/i2c/busses/i2c-pca-platform.c| 2 +-
include/linux/{ =>
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
arch/sh/boards/board-sh7785lcr.c | 2 +-
drivers/i2c/busses/i2c-pca-platform.c| 2 +-
include/linux/{ => platform_data}/i2c-pca-platform.h | 0
3 files
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-xiic.c| 2 +-
drivers/mfd/timberdale.c | 2 +-
include/linux/{ => platform_data}/i2c-xiic.h | 0
3 files
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-xiic.c| 2 +-
drivers/mfd/timberdale.c | 2 +-
include/linux/{ => platform_data}/i2c-xiic.h | 0
3 files changed, 2 insertions(+),
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
MAINTAINERS | 2 +-
arch/arm/mach-ks8695/board-acs5k.c | 2 +-
arch/arm/mach-omap1/board-htcherald.c| 2 +-
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
MAINTAINERS | 2 +-
arch/arm/mach-ks8695/board-acs5k.c | 2 +-
arch/arm/mach-omap1/board-htcherald.c| 2 +-
Move all plain platform_data includes to the platform_data-dir
(except for i2c-pnx which can be moved into the driver itself).
My preference is to take these patches via the i2c tree. I can provide an
immutable branch if needed. But we can also discuss those going in via
arch-trees if
Move all plain platform_data includes to the platform_data-dir
(except for i2c-pnx which can be moved into the driver itself).
My preference is to take these patches via the i2c tree. I can provide an
immutable branch if needed. But we can also discuss those going in via
arch-trees if
On 04/19/2018 03:43 PM, Andrew Morton wrote:
> On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote:
>
>> It was found that reading /proc/stat could be time consuming on
>> systems with a lot of irqs. For example, reading /proc/stat in a
>> certain 2-socket Skylake server took
On 04/19/2018 03:43 PM, Andrew Morton wrote:
> On Thu, 19 Apr 2018 13:09:29 -0400 Waiman Long wrote:
>
>> It was found that reading /proc/stat could be time consuming on
>> systems with a lot of irqs. For example, reading /proc/stat in a
>> certain 2-socket Skylake server took about 4.6ms because
The endpoint observing AER_FATAL error might be connected to a PCI hotplug
slot. Performing secondary bus reset on a hotplug slot causes PCI link
up/down interrupts.
Hotplug driver removes the device from system when a link down interrupt
is observed and performs re-enumeration when link up
The endpoint observing AER_FATAL error might be connected to a PCI hotplug
slot. Performing secondary bus reset on a hotplug slot causes PCI link
up/down interrupts.
Hotplug driver removes the device from system when a link down interrupt
is observed and performs re-enumeration when link up
The infiniband adapter might be connected to a PCI hotplug slot. Performing
secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
Hotplug driver removes the device from system when a link down interrupt
is observed and performs re-enumeration when link up interrupt is
The infiniband adapter might be connected to a PCI hotplug slot. Performing
secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
Hotplug driver removes the device from system when a link down interrupt
is observed and performs re-enumeration when link up interrupt is
On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote:
> On 04/19/2018 03:08 PM, Alexey Dobriyan wrote:
> >> Therefore, application performance can be impacted if the application
> >> reads /proc/stat rather frequently.
> > [nods]
> > Text interfaces can be designed in a very stupid way.
> >
On Thu, Apr 19, 2018 at 03:28:40PM -0400, Waiman Long wrote:
> On 04/19/2018 03:08 PM, Alexey Dobriyan wrote:
> >> Therefore, application performance can be impacted if the application
> >> reads /proc/stat rather frequently.
> > [nods]
> > Text interfaces can be designed in a very stupid way.
> >
On Wed, Apr 18, 2018 at 03:49:02PM +0200, Miklos Szeredi wrote:
> On Wed, Apr 18, 2018 at 3:38 PM, Steven Rostedt wrote:
> > On Wed, 18 Apr 2018 13:42:03 +0200
> > Miklos Szeredi wrote:
> >
> >> On Wed, Apr 18, 2018 at 10:19 AM, Amir Goldstein
On Wed, Apr 18, 2018 at 03:49:02PM +0200, Miklos Szeredi wrote:
> On Wed, Apr 18, 2018 at 3:38 PM, Steven Rostedt wrote:
> > On Wed, 18 Apr 2018 13:42:03 +0200
> > Miklos Szeredi wrote:
> >
> >> On Wed, Apr 18, 2018 at 10:19 AM, Amir Goldstein
> >> wrote:
> >> > On Thu, Apr 12, 2018 at 6:08
On Thu, 19 Apr 2018 10:19:26 -0600
Alex Williamson wrote:
> [cc +Kirti]
>
> On Wed, 18 Apr 2018 18:55:45 +0800
> Xu Yandong wrote:
>
> > The task structure in vfio_dma struct used to identify the same
> > task who map it or other task who
On Thu, 19 Apr 2018 10:19:26 -0600
Alex Williamson wrote:
> [cc +Kirti]
>
> On Wed, 18 Apr 2018 18:55:45 +0800
> Xu Yandong wrote:
>
> > The task structure in vfio_dma struct used to identify the same
> > task who map it or other task who shares same adress space is
> > allowed to unmap. But
> -Original Message-
> From: Pandruvada, Srinivas [mailto:srinivas.pandruv...@intel.com]
> Sent: Thursday, April 19, 2018 2:46 PM
> To: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
> dgilm...@redhat.com; Limonciello, Mario
> Subject: Re: issues with suspend on Dell XPS 13
> -Original Message-
> From: Pandruvada, Srinivas [mailto:srinivas.pandruv...@intel.com]
> Sent: Thursday, April 19, 2018 2:46 PM
> To: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
> dgilm...@redhat.com; Limonciello, Mario
> Subject: Re: issues with suspend on Dell XPS 13
301 - 400 of 2008 matches
Mail list logo