On Thu, Jun 28, 2018 at 02:13:15PM -0700, Joel Fernandes wrote:
> On Thu, Jun 28, 2018 at 01:02:05PM -0700, Paul E. McKenney wrote:
> > > > wrote:
> [..]
> > > > > > > > > So why this function-call structure? Well, you see, NMI
> > > > > > > > > handlers can
> > > > > > > > > take what appear
On Thu, Jun 28, 2018 at 02:13:15PM -0700, Joel Fernandes wrote:
> On Thu, Jun 28, 2018 at 01:02:05PM -0700, Paul E. McKenney wrote:
> > > > wrote:
> [..]
> > > > > > > > > So why this function-call structure? Well, you see, NMI
> > > > > > > > > handlers can
> > > > > > > > > take what appear
Hi Joe,
On Fri, Jun 22, 2018 at 11:29:28PM -0700, Joe Perches wrote:
> random_ether_addr is a #define for eth_random_addr which is
> generally preferred in kernel code by ~3:1
>
> Convert the uses of random_ether_addr to enable removing the #define
>
> Signed-off-by: Joe Perches
> ---
>
Hi Joe,
On Fri, Jun 22, 2018 at 11:29:28PM -0700, Joe Perches wrote:
> random_ether_addr is a #define for eth_random_addr which is
> generally preferred in kernel code by ~3:1
>
> Convert the uses of random_ether_addr to enable removing the #define
>
> Signed-off-by: Joe Perches
> ---
>
On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> > > On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> > > [...]
> > > > 3. Something else?
> > >
> > > How
On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> On Wed 27-06-18 07:31:25, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 09:22:07AM +0200, Michal Hocko wrote:
> > > On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
> > > [...]
> > > > 3. Something else?
> > >
> > > How
On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>
> This is okay with me for a fix outside the merge window. Can you do a
> followup for the next merge window that fixes it better, though? In
> particular, TASK_SIZE is generally garbage. I think a better fix
> would be something like
On Thu, Jun 28, 2018 at 1:23 PM Andy Lutomirski wrote:
>
> This is okay with me for a fix outside the merge window. Can you do a
> followup for the next merge window that fixes it better, though? In
> particular, TASK_SIZE is generally garbage. I think a better fix
> would be something like
On Thu, Jun 28, 2018 at 02:12:38PM -0700, Bart Van Assche wrote:
> Regarding the above patch: have you considered to use the existing function
> blk_mq_unique_tag_to_hwq() instead of introducing this new function?
Interesting. I think the usage I need using that is something like:
On Thu, Jun 28, 2018 at 02:12:38PM -0700, Bart Van Assche wrote:
> Regarding the above patch: have you considered to use the existing function
> blk_mq_unique_tag_to_hwq() instead of introducing this new function?
Interesting. I think the usage I need using that is something like:
On 6/28/18, 1:37 PM, "Jason Gunthorpe" wrote:
> On Thu, Jun 28, 2018 at 03:45:26PM -0400, Neil Horman wrote:
> > On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> > > On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > > > On repeated module load/unload cycles, its
On 6/28/18, 1:37 PM, "Jason Gunthorpe" wrote:
> On Thu, Jun 28, 2018 at 03:45:26PM -0400, Neil Horman wrote:
> > On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> > > On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > > > On repeated module load/unload cycles, its
On Thu, Jun 28, 2018 at 01:02:05PM -0700, Paul E. McKenney wrote:
> > > wrote:
[..]
> > > > > > > > So why this function-call structure? Well, you see, NMI
> > > > > > > > handlers can
> > > > > > > > take what appear to RCU to be normal interrupts...
> > > > > > > >
> > > > > > > > (And I just
On Thu, Jun 28, 2018 at 01:02:05PM -0700, Paul E. McKenney wrote:
> > > wrote:
[..]
> > > > > > > > So why this function-call structure? Well, you see, NMI
> > > > > > > > handlers can
> > > > > > > > take what appear to RCU to be normal interrupts...
> > > > > > > >
> > > > > > > > (And I just
On 06/28/18 14:03, Keith Busch wrote:
Signed-off-by: Keith Busch
---
block/blk-mq.c | 6 ++
include/linux/blk-mq.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index b429d515b568..c6478833464d 100644
--- a/block/blk-mq.c
+++
On 06/28/18 14:03, Keith Busch wrote:
Signed-off-by: Keith Busch
---
block/blk-mq.c | 6 ++
include/linux/blk-mq.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index b429d515b568..c6478833464d 100644
--- a/block/blk-mq.c
+++
This adds the spmi-temp-alarm node to pm8998 based on the examples in the
bindings.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
This adds the spmi-temp-alarm node to pm8998 based on the examples in the
bindings.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
Add pm8998 thermal zone based on the examples in the spmi-temp-alarm
bindings.
Note: devices with the pm8998 need to have a 'thermal-zones' node (which
may be empty) with a label 'thermal_zones'.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 28
The node is empty for now. It is needed to allow other DT snippets
to add thermal zone entries.
Signed-off-by: Matthias Kaehlcke
---
Sorry if you received this twice, lists were missing in cc in the first attempt
...
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4
1 file changed, 4
Add pm8998 thermal zone based on the examples in the spmi-temp-alarm
bindings.
Note: devices with the pm8998 need to have a 'thermal-zones' node (which
may be empty) with a label 'thermal_zones'.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 28
The node is empty for now. It is needed to allow other DT snippets
to add thermal zone entries.
Signed-off-by: Matthias Kaehlcke
---
Sorry if you received this twice, lists were missing in cc in the first attempt
...
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4
1 file changed, 4
This will print the disk name if the disk name for disk based requests
so a user can better distinguish traffic to different disks. This allows
disk based filters. For example, to see only nvme0n2 traffic:
echo "disk_name == nvme0n2" > /sys/kernel/debug/tracing/events/nvme/filter
This will print the disk name if the disk name for disk based requests
so a user can better distinguish traffic to different disks. This allows
disk based filters. For example, to see only nvme0n2 traffic:
echo "disk_name == nvme0n2" > /sys/kernel/debug/tracing/events/nvme/filter
Signed-off-by: Keith Busch
---
block/blk-mq.c | 6 ++
include/linux/blk-mq.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index b429d515b568..c6478833464d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -466,6 +466,12 @@ struct request
Signed-off-by: Keith Busch
---
block/blk-mq.c | 6 ++
include/linux/blk-mq.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index b429d515b568..c6478833464d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -466,6 +466,12 @@ struct request
We can not match up a command to its completion based on the command
id alone. We need to pair this up with the submitting queue identifier,
so this patch adds that to the trace buffer.
This patch is also collapsing the admin and io submission traces into
a single one since we don't need to
From: Sagi Grimberg
We will need to reference the controller in the setup and completion
time for tracing and future traffic based keep alive support.
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/fc.c | 1 +
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c| 2 ++
This appends the controller instance to the trace buffer for nvme commands
to distinguish what controller is dispatching a command.
Signed-off-by: Keith Busch
---
drivers/nvme/host/trace.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
This appends the controller instance to the trace buffer for nvme commands
to distinguish what controller is dispatching a command.
Signed-off-by: Keith Busch
---
drivers/nvme/host/trace.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
We can not match up a command to its completion based on the command
id alone. We need to pair this up with the submitting queue identifier,
so this patch adds that to the trace buffer.
This patch is also collapsing the admin and io submission traces into
a single one since we don't need to
From: Sagi Grimberg
We will need to reference the controller in the setup and completion
time for tracing and future traffic based keep alive support.
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/fc.c | 1 +
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c| 2 ++
On Thu, Jun 28, 2018 at 09:48:24AM +0200, Johannes Thumshirn wrote:
> On Wed, Jun 27, 2018 at 10:37:06AM -0600, Keith Busch wrote:
> > It looks like you want the # assigned to /dev/nvme<#>. Do you want to
> > use ctrl->instance here instead?
>
> Right.
>
> As it'll conflict with your other trace
On Thu, Jun 28, 2018 at 09:48:24AM +0200, Johannes Thumshirn wrote:
> On Wed, Jun 27, 2018 at 10:37:06AM -0600, Keith Busch wrote:
> > It looks like you want the # assigned to /dev/nvme<#>. Do you want to
> > use ctrl->instance here instead?
>
> Right.
>
> As it'll conflict with your other trace
- On Jun 28, 2018, at 4:22 PM, Andy Lutomirski l...@kernel.org wrote:
> On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
> wrote:
>> Validating the abort_ip field of rseq_cs ensures that the kernel don't
>> return to an invalid address when returning to userspace after an abort.
>> I don't
- On Jun 28, 2018, at 4:22 PM, Andy Lutomirski l...@kernel.org wrote:
> On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
> wrote:
>> Validating the abort_ip field of rseq_cs ensures that the kernel don't
>> return to an invalid address when returning to userspace after an abort.
>> I don't
- On Jun 28, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
> Hi Mathieu,
>
> On Thu, Jun 28, 2018 at 12:23:59PM -0400, Mathieu Desnoyers wrote:
>> On 32-bit kernels, the rseq->rseq_cs_padding field is never read by the
>> kernel. However, 64-bit kernels dealing with 32-bit compat
- On Jun 28, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
> Hi Mathieu,
>
> On Thu, Jun 28, 2018 at 12:23:59PM -0400, Mathieu Desnoyers wrote:
>> On 32-bit kernels, the rseq->rseq_cs_padding field is never read by the
>> kernel. However, 64-bit kernels dealing with 32-bit compat
- On Jun 28, 2018, at 12:47 PM, Will Deacon will.dea...@arm.com wrote:
> Hi Mathieu,
>
> On Tue, Jun 26, 2018 at 12:11:52PM -0400, Mathieu Desnoyers wrote:
>> - On Jun 26, 2018, at 11:14 AM, Will Deacon will.dea...@arm.com wrote:
>> > On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu
- On Jun 28, 2018, at 12:47 PM, Will Deacon will.dea...@arm.com wrote:
> Hi Mathieu,
>
> On Tue, Jun 26, 2018 at 12:11:52PM -0400, Mathieu Desnoyers wrote:
>> - On Jun 26, 2018, at 11:14 AM, Will Deacon will.dea...@arm.com wrote:
>> > On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu
On Thu 2018-06-28 22:29:57, Andreas Klinger wrote:
> Hi Pavel,
>
> Pavel Machek schrieb am Thu, 28. Jun 20:56:
> > Hi!
> >
> > > Send out a morse code by using LEDs.
> > >
> > > This is useful especially on embedded systems without displays to tell the
> > > user about error conditions and
Pin setup may be optional in some cases such as the reset default works
or the pin setup is done by the bootloader. In these cases, it is optional
for the OS to support managing the pin controller and pin setup. In order
to support this scenario, add a property 'pinctrl-use-default' to indicate
On Thu 2018-06-28 22:29:57, Andreas Klinger wrote:
> Hi Pavel,
>
> Pavel Machek schrieb am Thu, 28. Jun 20:56:
> > Hi!
> >
> > > Send out a morse code by using LEDs.
> > >
> > > This is useful especially on embedded systems without displays to tell the
> > > user about error conditions and
Pin setup may be optional in some cases such as the reset default works
or the pin setup is done by the bootloader. In these cases, it is optional
for the OS to support managing the pin controller and pin setup. In order
to support this scenario, add a property 'pinctrl-use-default' to indicate
On June 28, 2018 1:33:24 PM PDT, Andy Lutomirski wrote:
>On Wed, Jun 27, 2018 at 11:22 AM, wrote:
>> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski
>wrote:
>>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>
>>>wrote:
> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
>>>
On June 28, 2018 1:33:24 PM PDT, Andy Lutomirski wrote:
>On Wed, Jun 27, 2018 at 11:22 AM, wrote:
>> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski
>wrote:
>>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>
>>>wrote:
> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
>>>
On Thu, Jun 28, 2018 at 03:45:26PM -0400, Neil Horman wrote:
> On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> > On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > > On repeated module load/unload cycles, its possible for the pvrmda
> > > driver to encounter this
On Thu, Jun 28, 2018 at 03:45:26PM -0400, Neil Horman wrote:
> On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> > On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > > On repeated module load/unload cycles, its possible for the pvrmda
> > > driver to encounter this
On Thu, 21 Jun 2018, Arnaldo Carvalho de Melo wrote:
Em Thu, Jun 21, 2018 at 11:19:15AM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Jun 20, 2018 at 07:45:46PM -0500, Kim Phillips escreveu:
On Wed, 20 Jun 2018 10:46:22 -0300
Arnaldo Carvalho de Melo wrote:
[...]
Would be good if we
On Thu, 21 Jun 2018, Arnaldo Carvalho de Melo wrote:
Em Thu, Jun 21, 2018 at 11:19:15AM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Jun 20, 2018 at 07:45:46PM -0500, Kim Phillips escreveu:
On Wed, 20 Jun 2018 10:46:22 -0300
Arnaldo Carvalho de Melo wrote:
[...]
Would be good if we
On Thu, 2018-06-28 at 11:34 +0200, Bastien Nocera wrote:
> On Thu, 2018-06-28 at 10:22 +0200, Hans de Goede wrote:
> > On 28-06-18 09:43, Michael Straube wrote:
> > > ret = rtw_resume_process(padapter)
> > > Is this a bug or is the if else construct just pointless?
> > It probably is just
On Thu, 2018-06-28 at 11:34 +0200, Bastien Nocera wrote:
> On Thu, 2018-06-28 at 10:22 +0200, Hans de Goede wrote:
> > On 28-06-18 09:43, Michael Straube wrote:
> > > ret = rtw_resume_process(padapter)
> > > Is this a bug or is the if else construct just pointless?
> > It probably is just
On Wed, Jun 27, 2018 at 11:22 AM, wrote:
> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski wrote:
>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>>wrote:
>>>
>>>
>>>
On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
>> wrote:
> On 06/22/18 07:24, Andy Lutomirski wrote:
>
On Wed, Jun 27, 2018 at 11:22 AM, wrote:
> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski wrote:
>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>>wrote:
>>>
>>>
>>>
On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
>> wrote:
> On 06/22/18 07:24, Andy Lutomirski wrote:
>
Hi Pavel,
> Hi!
>
> > Send out a morse code by using LEDs.
> >
> > This is useful especially on embedded systems without displays to tell the
> > user about error conditions and status information.
> >
> > The trigger will be called "morse"
> >
> > The string to be send is written into the
Hi Pavel,
> Hi!
>
> > Send out a morse code by using LEDs.
> >
> > This is useful especially on embedded systems without displays to tell the
> > user about error conditions and status information.
> >
> > The trigger will be called "morse"
> >
> > The string to be send is written into the
Hi Pavel,
Pavel Machek schrieb am Thu, 28. Jun 20:56:
> Hi!
>
> > Send out a morse code by using LEDs.
> >
> > This is useful especially on embedded systems without displays to tell the
> > user about error conditions and status information.
> >
> > The trigger will be called "morse"
> >
> >
Hi Pavel,
Pavel Machek schrieb am Thu, 28. Jun 20:56:
> Hi!
>
> > Send out a morse code by using LEDs.
> >
> > This is useful especially on embedded systems without displays to tell the
> > user about error conditions and status information.
> >
> > The trigger will be called "morse"
> >
> >
Hi Ryan,
On 2018/6/13 19:03, Ryan Grachek wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with
Hi Ryan,
On 2018/6/13 19:03, Ryan Grachek wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with
Hi Ryan,
On 2018/6/13 16:13, Ryan Grachek wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with
Hi Ryan,
On 2018/6/13 16:13, Ryan Grachek wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with
On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
wrote:
> Validating the abort_ip field of rseq_cs ensures that the kernel don't
> return to an invalid address when returning to userspace after an abort.
> I don't fully trust each architecture code to cleanly deal with invalid
> return
On Thu, Jun 28, 2018 at 9:23 AM, Mathieu Desnoyers
wrote:
> Validating the abort_ip field of rseq_cs ensures that the kernel don't
> return to an invalid address when returning to userspace after an abort.
> I don't fully trust each architecture code to cleanly deal with invalid
> return
On 06/20/2018 07:00 AM, Michal Hocko wrote:
> On Fri 15-06-18 15:36:07, Jason Baron wrote:
>>
>>
>> On 06/13/2018 03:15 AM, Michal Hocko wrote:
>>> On Wed 13-06-18 08:32:19, Vlastimil Babka wrote:
> [...]
BTW I didn't get why we should allow this for MADV_DONTNEED but not
MADV_FREE.
On 06/20/2018 07:00 AM, Michal Hocko wrote:
> On Fri 15-06-18 15:36:07, Jason Baron wrote:
>>
>>
>> On 06/13/2018 03:15 AM, Michal Hocko wrote:
>>> On Wed 13-06-18 08:32:19, Vlastimil Babka wrote:
> [...]
BTW I didn't get why we should allow this for MADV_DONTNEED but not
MADV_FREE.
Dear Friend
I am Mr Akain Karim,The Head of File Department in Bank Of Africa.I seek your
assistance and i assured of your capability to champion this business
opportunity to remit ($10.5 million USD) Into your bank account, if you are
interested let me know so that i can send you the
Dear Friend
I am Mr Akain Karim,The Head of File Department in Bank Of Africa.I seek your
assistance and i assured of your capability to champion this business
opportunity to remit ($10.5 million USD) Into your bank account, if you are
interested let me know so that i can send you the
On Wed, 2018-06-27 at 11:10 -0700, Andy Lutomirski wrote:
>
> You left this comment:
>
> /*
> * We don't currently support having a real mm loaded
> without
> * our cpu set in mm_cpumask(). We have all the
> bookkeeping
> * in
On Wed, 2018-06-27 at 11:10 -0700, Andy Lutomirski wrote:
>
> You left this comment:
>
> /*
> * We don't currently support having a real mm loaded
> without
> * our cpu set in mm_cpumask(). We have all the
> bookkeeping
> * in
Add an implementation to get the current GPIO state.
The callback is used by the leds-gpio driver for example, in case the
current LED/GPIO state should be kept during driver load.
Signed-off-by: Mathias Kresin
---
drivers/gpio/gpio-stp-xway.c | 15 +++
1 file changed, 15
Add an implementation to get the current GPIO state.
The callback is used by the leds-gpio driver for example, in case the
current LED/GPIO state should be kept during driver load.
Signed-off-by: Mathias Kresin
---
drivers/gpio/gpio-stp-xway.c | 15 +++
1 file changed, 15
On Sat, Jun 23, 2018 at 10:53:56AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 22, 2018 at 03:03:35PM -0700, Andy Lutomirski wrote:
> > On Fri, Jun 22, 2018 at 2:14 PM Paul E. McKenney
> > wrote:
> > >
> > > On Fri, Jun 22, 2018 at 05:00:42PM -0400, Steven Rostedt wrote:
> > > > On Fri, 22 Jun
On Sat, Jun 23, 2018 at 10:53:56AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 22, 2018 at 03:03:35PM -0700, Andy Lutomirski wrote:
> > On Fri, Jun 22, 2018 at 2:14 PM Paul E. McKenney
> > wrote:
> > >
> > > On Fri, Jun 22, 2018 at 05:00:42PM -0400, Steven Rostedt wrote:
> > > > On Fri, 22 Jun
On 28/06/2018 20:34, Alexandre Belloni wrote:
> On 28/06/2018 17:15:39+0200, Daniel Lezcano wrote:
>> On 19/06/2018 23:19, Alexandre Belloni wrote:
>>> Add registers and bits definitions for the timer counter blocks found on
>>> Atmel ARM SoCs.
>>>
>>> Tested-by: Alexander Dahl
>>> Tested-by:
On 28/06/2018 20:34, Alexandre Belloni wrote:
> On 28/06/2018 17:15:39+0200, Daniel Lezcano wrote:
>> On 19/06/2018 23:19, Alexandre Belloni wrote:
>>> Add registers and bits definitions for the timer counter blocks found on
>>> Atmel ARM SoCs.
>>>
>>> Tested-by: Alexander Dahl
>>> Tested-by:
Hello,
In 4.18.0-rc1 and rc2, we're seeing a kernel oops on the SCSI target host when
an initiator issues an "iscsiadm -m discovery" command.
Stack trace is below.
It seems to be the same bug discussed on the target-devel list in this thread:
Hello,
In 4.18.0-rc1 and rc2, we're seeing a kernel oops on the SCSI target host when
an initiator issues an "iscsiadm -m discovery" command.
Stack trace is below.
It seems to be the same bug discussed on the target-devel list in this thread:
On Thu, Jun 28, 2018 at 12:03 PM Petr Mladek wrote:
>
> I am sorry for confusion. Anyway, it seems that Andrew is going to
> send it as well in the meantime.
Hmm. I got a patch queue from Andrew this morning that didn't contain
that revert, so I pulled your tree.
Linus
On Thu, Jun 28, 2018 at 12:03 PM Petr Mladek wrote:
>
> I am sorry for confusion. Anyway, it seems that Andrew is going to
> send it as well in the meantime.
Hmm. I got a patch queue from Andrew this morning that didn't contain
that revert, so I pulled your tree.
Linus
On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > On repeated module load/unload cycles, its possible for the pvrmda
> > driver to encounter this crash:
> >
> > ...
> > 297.032448] RIP: 0010:[] []
> >
On Thu, Jun 28, 2018 at 12:59:46PM -0600, Jason Gunthorpe wrote:
> On Thu, Jun 28, 2018 at 09:59:38AM -0400, Neil Horman wrote:
> > On repeated module load/unload cycles, its possible for the pvrmda
> > driver to encounter this crash:
> >
> > ...
> > 297.032448] RIP: 0010:[] []
> >
Signed-off-by: Michael Heimpold
---
include/uapi/linux/ethtool.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 4ca65b56084f..7363f18e65a5 100644
--- a/include/uapi/linux/ethtool.h
+++
Signed-off-by: Michael Heimpold
---
include/uapi/linux/ethtool.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 4ca65b56084f..7363f18e65a5 100644
--- a/include/uapi/linux/ethtool.h
+++
On Thu, Jun 28, 2018 at 11:23 AM Thomas Gleixner wrote:
>
> On Thu, 28 Jun 2018, Thomas Gleixner wrote:
> > I still want to document the unholy mess of what is initialized and
> > available when. We have 5 hypervisors and 3 different points in early boot
> > where the calibrate_* callbacks are
On Thu, Jun 28, 2018 at 11:23 AM Thomas Gleixner wrote:
>
> On Thu, 28 Jun 2018, Thomas Gleixner wrote:
> > I still want to document the unholy mess of what is initialized and
> > available when. We have 5 hypervisors and 3 different points in early boot
> > where the calibrate_* callbacks are
commit 01fd61c0b9bd ("PCI: Add a return type for
pci_reset_bridge_secondary_bus()") added a return value to the function to
return if a device is accessible following a reset. Callers are not
checking the value.
Pass error code up high in the stack if device is not accessible.
Signed-off-by:
commit 01fd61c0b9bd ("PCI: Add a return type for
pci_reset_bridge_secondary_bus()") added a return value to the function to
return if a device is accessible following a reset. Callers are not
checking the value.
Pass error code up high in the stack if device is not accessible.
Signed-off-by:
Now that the old implementation of pci_reset_bus() is gone, replace
pci_try_reset_bus() with pci_reset_bus().
Compared to the old implementation, new code will fail immmediately with
-EAGAIN if object lock cannot be obtained.
Signed-off-by: Sinan Kaya
---
drivers/infiniband/hw/hfi1/pcie.c | 2
Now that the old implementation of pci_reset_bus() is gone, replace
pci_try_reset_bus() with pci_reset_bus().
Compared to the old implementation, new code will fail immmediately with
-EAGAIN if object lock cannot be obtained.
Signed-off-by: Sinan Kaya
---
drivers/infiniband/hw/hfi1/pcie.c | 2
If a bridge supports hotplug and observes a PCIe fatal error, the following
events happen:
1. AER driver removes the devices from PCI tree on fatal error
2. AER driver brings down the link by issuing a secondary bus reset waits
for the link to come up.
3. Hotplug driver observes a link down
If a bridge supports hotplug and observes a PCIe fatal error, the following
events happen:
1. AER driver removes the devices from PCI tree on fatal error
2. AER driver brings down the link by issuing a secondary bus reset waits
for the link to come up.
3. Hotplug driver observes a link down
Drivers are expected to call pci_try_reset_slot() or pci_try_reset_bus() by
querying if a system supports hotplug or not. A survey showed that most
drivers don't do this and we are leaking hotplug capability to the user.
Hide pci_try_slot_reset() from drivers and embed into pci_try_bus_reset().
pci_reset_bus() and pci_reset_slot() functions are not being used by
any code. Remove them from the kernel in favor of pci_try_reset_bus()
and pci_try_reset_slot() functions.
Signed-off-by: Sinan Kaya
---
drivers/pci/pci.c | 55 ++---
Drivers are expected to call pci_try_reset_slot() or pci_try_reset_bus() by
querying if a system supports hotplug or not. A survey showed that most
drivers don't do this and we are leaking hotplug capability to the user.
Hide pci_try_slot_reset() from drivers and embed into pci_try_bus_reset().
pci_reset_bus() and pci_reset_slot() functions are not being used by
any code. Remove them from the kernel in favor of pci_try_reset_bus()
and pci_try_reset_slot() functions.
Signed-off-by: Sinan Kaya
---
drivers/pci/pci.c | 55 ++---
Rename pci_reset_bridge_secondary_bus() to pci_bridge_secondary_bus_reset()
and move the declartation from linux/pci.h to drivers/pci.h to be used
internally in PCI directory only.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_hpc.c | 2 +-
drivers/pci/pci.c| 11
Rename pci_reset_bridge_secondary_bus() to pci_bridge_secondary_bus_reset()
and move the declartation from linux/pci.h to drivers/pci.h to be used
internally in PCI directory only.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_hpc.c | 2 +-
drivers/pci/pci.c| 11
Getting ready to hide pci_reset_bridge_secondary_bus() from the drivers.
pci_reset_bridge_secondary_bus() should only be used internally by the
PCI code itself.
Other drivers should rely on higher level pci_try_reset_bus() API.
Signed-off-by: Sinan Kaya
---
drivers/infiniband/hw/hfi1/pcie.c |
Getting ready to hide pci_reset_bridge_secondary_bus() from the drivers.
pci_reset_bridge_secondary_bus() should only be used internally by the
PCI code itself.
Other drivers should rely on higher level pci_try_reset_bus() API.
Signed-off-by: Sinan Kaya
---
drivers/infiniband/hw/hfi1/pcie.c |
201 - 300 of 1130 matches
Mail list logo
