On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote:
>
> We often have merge conflicts with RDMA, how do you prefer to get the
> PR? I'm actually not very clear on this part of the process.
I generally prefer the non-merged version, but with comments about
the conflicts.
In fact, the really
On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote:
>
> We often have merge conflicts with RDMA, how do you prefer to get the
> PR? I'm actually not very clear on this part of the process.
I generally prefer the non-merged version, but with comments about
the conflicts.
In fact, the really
Pulling in stable releases into v4.14-rt I triggered this with my CPU
hotplug test:
[ cut here ]
kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!
invalid opcode: [#1] PREEMPT SMP PTI
Modules linked in: sunrpc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6
Pulling in stable releases into v4.14-rt I triggered this with my CPU
hotplug test:
[ cut here ]
kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!
invalid opcode: [#1] PREEMPT SMP PTI
Modules linked in: sunrpc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6
On 08/16/2018 02:09 PM, Dan Jacobson wrote:
> The kernel should really say what the
> [ cut here ]
> lines are called, else users will say things like:
>
> "I discovered that the user needs to use xrandr in _two_ steps for
> certain resolutions, else he will trigger a
>
On 08/16/2018 02:09 PM, Dan Jacobson wrote:
> The kernel should really say what the
> [ cut here ]
> lines are called, else users will say things like:
>
> "I discovered that the user needs to use xrandr in _two_ steps for
> certain resolutions, else he will trigger a
>
While compiling the mainline kernel in android env with latest gcc 8 the
compiler threw this warning Thanks to the advantage of improved static analysis
in newer gcc we are now able to
see this warning this patch resolves the detected compiler warnings.
Signed-off-by: Harshit Jain
---
While compiling the mainline kernel in android env with latest gcc 8 the
compiler threw this warning Thanks to the advantage of improved static analysis
in newer gcc we are now able to
see this warning this patch resolves the detected compiler warnings.
Signed-off-by: Harshit Jain
---
Added PCI ID for Sunrise Point-H ISH.
Signed-off-by: Andreas Bosch
---
I hope this patch arrives correctly.
---
drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
Added PCI ID for Sunrise Point-H ISH.
Signed-off-by: Andreas Bosch
---
I hope this patch arrives correctly.
---
drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
On Fri, Aug 17, 2018 at 12:31:00PM -0700, Linus Torvalds wrote:
> On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote:
> >
> > This time there are many merge conflicts, all due to various tree-wide or
> > RDMA
> > subystem wide changes done by various people. The resolution is tricky, as
> >
On Fri, Aug 17, 2018 at 12:31:00PM -0700, Linus Torvalds wrote:
> On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote:
> >
> > This time there are many merge conflicts, all due to various tree-wide or
> > RDMA
> > subystem wide changes done by various people. The resolution is tricky, as
> >
On Fri, Aug 17, 2018 at 12:22:44PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > > The "favourite compressor" seems to roughly change every year, so if
> > > we keep adding new ones things will get more and more convoluted.
> >
> > The above
On Fri, Aug 17, 2018 at 12:22:44PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > > The "favourite compressor" seems to roughly change every year, so if
> > > we keep adding new ones things will get more and more convoluted.
> >
> > The above
On Fri, Aug 17, 2018 at 03:56:41PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 17, 2018 at 03:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa
On Fri, Aug 17, 2018 at 03:56:41PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 17, 2018 at 03:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa
Jacek
On 08/17/2018 02:37 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 08/16/2018 10:44 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> Thank you for the patch.
>>>
>>> I didn't review DT parsing details in v3, but now I've produced
>>> diff
Jacek
On 08/17/2018 02:37 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 08/16/2018 10:44 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> Thank you for the patch.
>>>
>>> I didn't review DT parsing details in v3, but now I've produced
>>> diff
On Fri, Aug 17, 2018 at 12:31 PM Linus Torvalds
wrote:
>
> Oh well. I'll look at what the conflicts were, but may end up just
> taking your resolution.
Ok, everything but the max_sge thing was trivial. I just took yours.
Linus
On Fri, Aug 17, 2018 at 12:31 PM Linus Torvalds
wrote:
>
> Oh well. I'll look at what the conflicts were, but may end up just
> taking your resolution.
Ok, everything but the max_sge thing was trivial. I just took yours.
Linus
Dan,
On 08/16/2018 10:44 PM, Dan Murphy wrote:
> Jacek
>
> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> Thank you for the patch.
>>
>> I didn't review DT parsing details in v3, but now I've produced
>> diff between v3 and v4 to check what has changed.
>>
>> I'm quite surprised
Dan,
On 08/16/2018 10:44 PM, Dan Murphy wrote:
> Jacek
>
> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> Thank you for the patch.
>>
>> I didn't review DT parsing details in v3, but now I've produced
>> diff between v3 and v4 to check what has changed.
>>
>> I'm quite surprised
On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote:
>
> This time there are many merge conflicts, all due to various tree-wide or RDMA
> subystem wide changes done by various people. The resolution is tricky, as git
> does not highlight two areas that need revision.
I was confused by this,
On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote:
>
> This time there are many merge conflicts, all due to various tree-wide or RDMA
> subystem wide changes done by various people. The resolution is tricky, as git
> does not highlight two areas that need revision.
I was confused by this,
Please ignore this series. The series is incorrectly marked as v2. I am
resending it as v1.
On Fri, Aug 17 2018 at 10:39 -0600, Lina Iyer wrote:
Hi,
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume
Please ignore this series. The series is incorrectly marked as v2. I am
resending it as v1.
On Fri, Aug 17 2018 at 10:39 -0600, Lina Iyer wrote:
Hi,
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume
On Fri, 17 Aug 2018 13:46:36 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> > wrote:
> >>
> >> Recently syzbot reported crashes in send_sigio_to_task and
> >> send_sigurg_to_task in linux-next. Despite
On Fri, 17 Aug 2018 13:46:36 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> > wrote:
> >>
> >> Recently syzbot reported crashes in send_sigio_to_task and
> >> send_sigurg_to_task in linux-next. Despite
On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > The "favourite compressor" seems to roughly change every year, so if
> > we keep adding new ones things will get more and more convoluted.
>
> The above patchset drops just bzip2. It is the only one that's strictly
> beaten in
On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > The "favourite compressor" seems to roughly change every year, so if
> > we keep adding new ones things will get more and more convoluted.
>
> The above patchset drops just bzip2. It is the only one that's strictly
> beaten in
Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc:
Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc:
Hi,
Resending as v1. The series was sent incorrectly as v2.
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume callbacks
- Dropped PDC DT bindings (see dependencies)
Dependencies:
Hi,
Resending as v1. The series was sent incorrectly as v2.
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume callbacks
- Dropped PDC DT bindings (see dependencies)
Dependencies:
GPIOs that are wakeup capable have interrupt lines that are routed to
the always-on interrupt controller (PDC) in parallel to the pinctrl. The
interrupts listed here are the wake up lines corresponding to GPIOs.
Signed-off-by: Lina Iyer
---
Changes in v1:
- Use interrupt-extended for all
From: Marc Zyngier
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
Reported-by: Lina Iyer
Signed-off-by: Marc
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.
To avoid
From: Marc Zyngier
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
Reported-by: Lina Iyer
Signed-off-by: Marc
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.
To avoid
GPIOs that are wakeup capable have interrupt lines that are routed to
the always-on interrupt controller (PDC) in parallel to the pinctrl. The
interrupts listed here are the wake up lines corresponding to GPIOs.
Signed-off-by: Lina Iyer
---
Changes in v1:
- Use interrupt-extended for all
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 2ab7a8885757..cc333b8afb99 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 2ab7a8885757..cc333b8afb99 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++
On 08/17/2018 09:27 AM, Cornelia Huck wrote:
On Fri, 17 Aug 2018 09:18:51 -0400
Tony Krowiak wrote:
On 08/14/2018 04:43 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:01 -0400
Tony Krowiak wrote:
From: Harald Freudenberger
Move all the inline functions from the ap bus header
file
On 08/17/2018 09:27 AM, Cornelia Huck wrote:
On Fri, 17 Aug 2018 09:18:51 -0400
Tony Krowiak wrote:
On 08/14/2018 04:43 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:01 -0400
Tony Krowiak wrote:
From: Harald Freudenberger
Move all the inline functions from the ap bus header
file
On 08/17/2018 05:38 AM, Cornelia Huck wrote:
On Wed, 15 Aug 2018 17:05:48 -0400
Tony Krowiak wrote:
On 08/15/2018 12:38 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:15 -0400
Tony Krowiak wrote:
+ case VFIO_DEVICE_RESET:
+ ret = vfio_ap_mdev_reset_queues(mdev,
On 08/17/2018 05:38 AM, Cornelia Huck wrote:
On Wed, 15 Aug 2018 17:05:48 -0400
Tony Krowiak wrote:
On 08/15/2018 12:38 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:15 -0400
Tony Krowiak wrote:
+ case VFIO_DEVICE_RESET:
+ ret = vfio_ap_mdev_reset_queues(mdev,
On 08/17/2018 04:43 AM, Cornelia Huck wrote:
On Thu, 16 Aug 2018 12:24:16 -0400
Tony Krowiak wrote:
On 08/14/2018 07:19 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:06 -0400
Tony Krowiak wrote:
+static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+{
+
On 08/17/2018 04:43 AM, Cornelia Huck wrote:
On Thu, 16 Aug 2018 12:24:16 -0400
Tony Krowiak wrote:
On 08/14/2018 07:19 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:06 -0400
Tony Krowiak wrote:
+static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+{
+
On Fri, Aug 17, 2018 at 6:20 PM Boris Brezillon
wrote:
>
> On Fri, 17 Aug 2018 15:56:23 +
> "Luck, Tony" wrote:
>
> > >> - Some targets don't have any support for I/O space on their PCI bus and
> > >> just
> > >>want to get things to compile by setting PCI_IOBASE to zero, this
> > >>
On Fri, Aug 17, 2018 at 6:20 PM Boris Brezillon
wrote:
>
> On Fri, 17 Aug 2018 15:56:23 +
> "Luck, Tony" wrote:
>
> > >> - Some targets don't have any support for I/O space on their PCI bus and
> > >> just
> > >>want to get things to compile by setting PCI_IOBASE to zero, this
> > >>
Em Fri, Aug 17, 2018 at 03:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> > > static const struct {
> > > const char *fmt;
> > > int
Em Fri, Aug 17, 2018 at 03:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> > > static const struct {
> > > const char *fmt;
> > > int
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> wrote:
>>
>> Recently syzbot reported crashes in send_sigio_to_task and
>> send_sigurg_to_task in linux-next. Despite finding a reproducer
>> syzbot apparently did not bisected this or otherwise track down the
>>
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> wrote:
>>
>> Recently syzbot reported crashes in send_sigio_to_task and
>> send_sigurg_to_task in linux-next. Despite finding a reproducer
>> syzbot apparently did not bisected this or otherwise track down the
>>
On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman
wrote:
> Dmitry Vyukov writes:
>
>> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
>> wrote:
>>> Dmitry Vyukov writes:
>>>
On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
wrote:
> On Mon, Aug 13, 2018 at 06:33:02AM
On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman
wrote:
> Dmitry Vyukov writes:
>
>> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
>> wrote:
>>> Dmitry Vyukov writes:
>>>
On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
wrote:
> On Mon, Aug 13, 2018 at 06:33:02AM
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > wrote:
> >> Dmitry Vyukov writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> >>> wrote:
> On Mon, Aug 13, 2018 at
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > wrote:
> >> Dmitry Vyukov writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> >>> wrote:
> On Mon, Aug 13, 2018 at
The constant sHTCLng causes a checkpatch issue, due to its use of
CamelCase naming. To correct the issue the constant has been renamed
to HTCLNG.
I'm not sure this is a good name as it communicates very little and
contradicts the block comment above its definition. MCS_LEN might
be a better name
The constant sHTCLng causes a checkpatch issue, due to its use of
CamelCase naming. To correct the issue the constant has been renamed
to HTCLNG.
I'm not sure this is a good name as it communicates very little and
contradicts the block comment above its definition. MCS_LEN might
be a better name
The structure HT_CAPABILITY_ELE causes a number of checkpatch / coding
style issues. The structure uses a 'typedef' directive causing an
issue regarding defining new types in the code. The name of the
structure should be lowercase, and the '__packed' directive is prefered
over the attribute
The structure HT_CAPABILITY_ELE causes a number of checkpatch / coding
style issues. The structure uses a 'typedef' directive causing an
issue regarding defining new types in the code. The name of the
structure should be lowercase, and the '__packed' directive is prefered
over the attribute
Correct the block comments so they conform to coding standard.
This is a coding style change which should not impact on runtime
code execution.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_HT.h | 73 +--
1 file changed, 36 insertions(+), 37
The enumerated type CHNLOP is only used as a member variable of the
structure RT_HIGH_THROUGHPUT. Whilst this member variable is initialised
it is never actually used in the code. To simplify the code both the
enumerated type and the member variable have been removed.
This is a coding style
Two unions HT_CAPABILITY and HT_CAPABILITY_MACPARA have previously been
commented out of code. Since they are obviously not used in code and
the commented out unions add nothing to the code they have been removed.
This is a coding style change which should have no impact on runtime
code
The macro CHHLOP_IN_PROGRESS is never used in code, so has been
removed.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4
1 file changed, 4 deletions(-)
diff --git
The enumerated type CHNLOP is only used as a member variable of the
structure RT_HIGH_THROUGHPUT. Whilst this member variable is initialised
it is never actually used in the code. To simplify the code both the
enumerated type and the member variable have been removed.
This is a coding style
Correct the block comments so they conform to coding standard.
This is a coding style change which should not impact on runtime
code execution.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_HT.h | 73 +--
1 file changed, 36 insertions(+), 37
Two unions HT_CAPABILITY and HT_CAPABILITY_MACPARA have previously been
commented out of code. Since they are obviously not used in code and
the commented out unions add nothing to the code they have been removed.
This is a coding style change which should have no impact on runtime
code
The macro CHHLOP_IN_PROGRESS is never used in code, so has been
removed.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4
1 file changed, 4 deletions(-)
diff --git
A few coding style changes in the file rtl819x_HT.h
John Whitmore (10):
staging:rtl8192u: Replace magic number with defined constant - Style
staging:rtl8192u: Rename sHTCLng - Style
staging:rtl8192u: Remove unnecessary blank lines - Style
staging:rtl8192u: Add required spaces - Style
A few coding style changes in the file rtl819x_HT.h
John Whitmore (10):
staging:rtl8192u: Replace magic number with defined constant - Style
staging:rtl8192u: Rename sHTCLng - Style
staging:rtl8192u: Remove unnecessary blank lines - Style
staging:rtl8192u: Add required spaces - Style
Remove unused constants, this is a coding style change which should
have no impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
Remove unused constants, this is a coding style change which should
have no impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
The defined constant MIMO_PS_STATIC is used for this test for zero
elsewhere in code so the magic number '0' has been replaced with that
comment, which was actually explicitly mentioned in the comment.
This is a simple coding style change which should have no impact on
runtime code execution.
Add spaces required by coding style to clear checkpatch issues.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 12 ++--
1 file changed, 6 insertions(+), 6
Removed blank lines which cause checkpatch issues.
This is a simple coding style change which should have no impact on
runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 9 -
1 file changed, 9 deletions(-)
diff --git
The defined constant MIMO_PS_STATIC is used for this test for zero
elsewhere in code so the magic number '0' has been replaced with that
comment, which was actually explicitly mentioned in the comment.
This is a simple coding style change which should have no impact on
runtime code execution.
Add spaces required by coding style to clear checkpatch issues.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 12 ++--
1 file changed, 6 insertions(+), 6
Removed blank lines which cause checkpatch issues.
This is a simple coding style change which should have no impact on
runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 9 -
1 file changed, 9 deletions(-)
diff --git
Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> > static const struct {
> > const char *fmt;
> > int (*decompress)(const char *input, int output);
> > } compressions[] = {
> > +
Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> > static const struct {
> > const char *fmt;
> > int (*decompress)(const char *input, int output);
> > } compressions[] = {
> > +
From: John Dias
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated while still in the fair class
- task is boosted
From: John Dias
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated while still in the fair class
- task is boosted
Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> Storing decompression ID in the struct kmod_path, so it
> can be later stored in the struct dso.
>
> Switching the struct kmod_path::comp from bool to int
> to return the compressions array index. Adding 0 index
> item into
Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> Storing decompression ID in the struct kmod_path, so it
> can be later stored in the struct dso.
>
> Switching the struct kmod_path::comp from bool to int
> to return the compressions array index. Adding 0 index
> item into
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> wrote:
>> Dmitry Vyukov writes:
>>
>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>>> wrote:
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> wrote:
>> Dmitry Vyukov writes:
>>
>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>>> wrote:
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following
On Fri, Aug 17, 2018 at 11:25:34AM -0500, Bjorn Helgaas wrote:
> The "bind driver, then set dev->added = 1" order seems to have been
> there since the beginning of dev->is_added:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a1bc9013a03
>
> This patch seems
On Fri, Aug 17, 2018 at 11:25:34AM -0500, Bjorn Helgaas wrote:
> The "bind driver, then set dev->added = 1" order seems to have been
> there since the beginning of dev->is_added:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a1bc9013a03
>
> This patch seems
Something is amiss. A "make install" of an already compiled 4.18.1
kernel is taking 10 minutes or so. The same thing for a 4.17.14 kernel
takes all of a minute.
And during that 10 minutes
or so we seem hung up on i915.ko
2626 pts/8S+ 0:00 make -f ./scripts/Makefile.build
Something is amiss. A "make install" of an already compiled 4.18.1
kernel is taking 10 minutes or so. The same thing for a 4.17.14 kernel
takes all of a minute.
And during that 10 minutes
or so we seem hung up on i915.ko
2626 pts/8S+ 0:00 make -f ./scripts/Makefile.build
Hi Naga,
On Fri, 17 Aug 2018 18:49:24 +0530
Naga Sureshkumar Relli wrote:
> +static int anfc_exec_op_cmd(struct nand_chip *chip,
> +const struct nand_subop *subop)
> +{
> + const struct nand_op_instr *instr;
> + struct anfc_op nfc_op = {};
> + struct
Hi Naga,
On Fri, 17 Aug 2018 18:49:24 +0530
Naga Sureshkumar Relli wrote:
> +static int anfc_exec_op_cmd(struct nand_chip *chip,
> +const struct nand_subop *subop)
> +{
> + const struct nand_op_instr *instr;
> + struct anfc_op nfc_op = {};
> + struct
On Fri, Aug 17, 2018 at 09:54:03AM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> > Hey,
> >
> > is there any mainline future for this zstd support?
> > Currently my most favourite compressor for this, and for what it’s worth
> > zstd/initrd now even
On Fri, Aug 17, 2018 at 09:54:03AM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> > Hey,
> >
> > is there any mainline future for this zstd support?
> > Currently my most favourite compressor for this, and for what it’s worth
> > zstd/initrd now even
On Tue, Aug 14, 2018 at 7:26 PM Frank Rowand wrote:
>
> On 08/14/18 07:46, 张波 wrote:
> > /delete-node/ /delete-prop/ could be used in dtsi files without device
> > tree overlay.
> >
> > but with device tree overlay, /delete-node/ and /delete-prop/ are not
> > work.
> > How to delete property
On Tue, Aug 14, 2018 at 7:26 PM Frank Rowand wrote:
>
> On 08/14/18 07:46, 张波 wrote:
> > /delete-node/ /delete-prop/ could be used in dtsi files without device
> > tree overlay.
> >
> > but with device tree overlay, /delete-node/ and /delete-prop/ are not
> > work.
> > How to delete property
On Mon, Aug 13, 2018 at 5:39 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=164fecc440
> kernel config:
On Mon, Aug 13, 2018 at 5:39 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=164fecc440
> kernel config:
101 - 200 of 714 matches
Mail list logo
