The MMP2 platform, that uses device tree, has this controller. Let's add
devicetree alongside platform & PCI.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 73 +++---
include/linux/pxa2xx_ssp.h | 1 +
2 files changed, 45 insertions(+), 29
The MMP2 platform, that uses device tree, has this controller. Let's add
devicetree alongside platform & PCI.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 73 +++---
include/linux/pxa2xx_ssp.h | 1 +
2 files changed, 45 insertions(+), 29
Strobe a GPIO line when the slave TX FIFO is filled. This is how the
Embedded Controller on an OLPC XO-1.75 machine, that happens to be a SPI
master, learns that it can initiate a transaction.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 12
drivers/spi/spi-pxa2xx.h
Strobe a GPIO line when the slave TX FIFO is filled. This is how the
Embedded Controller on an OLPC XO-1.75 machine, that happens to be a SPI
master, learns that it can initiate a transaction.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 12
drivers/spi/spi-pxa2xx.h
Hi.
This patchset adds devicetree and slave mode support to pxa2xx SPI
controller. The objective is that it will be able to support the
OLPC XO 1.75 embedded controller that is a SPI master talking to a
MMP2 SOC. The EC driver will be submitted in a separate patch set
shortly.
These patches
This is the SPI controller found on Marvel MMP2 and perhaps more
platforms.
Reviewed-by: Rob Herring
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- s/ssp@d4035000/spi@d4035000/
.../devicetree/bindings/spi/spi-pxa2xx.txt| 24 +++
1 file changed, 24 insertions(+)
That seems to be the correct type.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 6 +++---
include/linux/pxa2xx_ssp.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 14f4ea59caff..f674541675bb
There seem to be SSP2, SSP4 and perhaps SSP5 too, but Marvel keeps their
base addresses secret.
The SSP1 and SSP3 addresses were taken from OLPC 1.75, OpenFirmware and
kernel respectively.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Dropped the aliases
arch/arm/boot/dts/mmp2.dtsi |
Hi.
This patchset adds devicetree and slave mode support to pxa2xx SPI
controller. The objective is that it will be able to support the
OLPC XO 1.75 embedded controller that is a SPI master talking to a
MMP2 SOC. The EC driver will be submitted in a separate patch set
shortly.
These patches
This is the SPI controller found on Marvel MMP2 and perhaps more
platforms.
Reviewed-by: Rob Herring
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- s/ssp@d4035000/spi@d4035000/
.../devicetree/bindings/spi/spi-pxa2xx.txt| 24 +++
1 file changed, 24 insertions(+)
That seems to be the correct type.
Signed-off-by: Lubomir Rintel
---
drivers/spi/spi-pxa2xx.c | 6 +++---
include/linux/pxa2xx_ssp.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 14f4ea59caff..f674541675bb
There seem to be SSP2, SSP4 and perhaps SSP5 too, but Marvel keeps their
base addresses secret.
The SSP1 and SSP3 addresses were taken from OLPC 1.75, OpenFirmware and
kernel respectively.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Dropped the aliases
arch/arm/boot/dts/mmp2.dtsi |
On Wed, Oct 10, 2018 at 04:25:03PM +0200, Lubomir Rintel wrote:
> Without the clock, the keyboard controller won't operate.
> Tested on an OLPC XO 1.75.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/input/serio/olpc_apsp.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff
On Wed, Oct 10, 2018 at 04:25:03PM +0200, Lubomir Rintel wrote:
> Without the clock, the keyboard controller won't operate.
> Tested on an OLPC XO 1.75.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/input/serio/olpc_apsp.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff
On Fri, Oct 05, 2018 at 04:17:30PM +0100, Marc Zyngier wrote:
> On Fri, 05 Oct 2018 15:13:48 +0100,
> Matthias Brugger wrote:
> >
> >
> >
> > On 05/10/2018 15:42, Marc Zyngier wrote:
> > > On 05/10/18 13:33, Matthias Brugger wrote:
> > >>
> > >>
> > >> On 05/10/2018 12:55, Marc Zyngier wrote:
On 10/10/2018 09:34 AM, Juri Lelli wrote:
> On 10/10/18 15:08, Vincent Guittot wrote:
>> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
>>>
>>> On 10/10/18 14:34, Vincent Guittot wrote:
Hi Juri,
On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
>
> On 10/10/18 14:04,
On Fri, Oct 05, 2018 at 04:17:30PM +0100, Marc Zyngier wrote:
> On Fri, 05 Oct 2018 15:13:48 +0100,
> Matthias Brugger wrote:
> >
> >
> >
> > On 05/10/2018 15:42, Marc Zyngier wrote:
> > > On 05/10/18 13:33, Matthias Brugger wrote:
> > >>
> > >>
> > >> On 05/10/2018 12:55, Marc Zyngier wrote:
On 10/10/2018 09:34 AM, Juri Lelli wrote:
> On 10/10/18 15:08, Vincent Guittot wrote:
>> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote:
>>>
>>> On 10/10/18 14:34, Vincent Guittot wrote:
Hi Juri,
On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote:
>
> On 10/10/18 14:04,
On Wed, Oct 10, 2018 at 09:55:17AM -0700, Stephen Boyd wrote:
> This irq handler is always reading bytes from the device into a
> kmalloced buffer, so it's safe to mark this transaction as DMA safe.
> This avoids bouncing the buffer when an i2c controller decides to use
> DMA for a transaction.
>
On Wed, Oct 10, 2018 at 09:55:17AM -0700, Stephen Boyd wrote:
> This irq handler is always reading bytes from the device into a
> kmalloced buffer, so it's safe to mark this transaction as DMA safe.
> This avoids bouncing the buffer when an i2c controller decides to use
> DMA for a transaction.
>
Hello Quentin,
On 10/10/2018 05:55 AM, Quentin Perret wrote:
> Hi Vincent,
>
> On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
>> The problem with reflecting directly the capping is that it happens
>> far more often than the pace at which cpu_capacity_orig is updated in
>>
Hello Quentin,
On 10/10/2018 05:55 AM, Quentin Perret wrote:
> Hi Vincent,
>
> On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
>> The problem with reflecting directly the capping is that it happens
>> far more often than the pace at which cpu_capacity_orig is updated in
>>
On Wed, Oct 10, 2018 at 10:29:58AM -0400, Sasha Levin wrote:
> On Mon, Oct 08, 2018 at 12:20:26PM -0700, Dmitry Torokhov wrote:
> > Hi Michael,
> >
> > On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz
> > wrote:
> > >
> > > Dmitry,
> > >
> > > someone on debian-68k reported the bug, which (to
Quoting Linus Walleij (2018-10-10 05:05:18)
> On Mon, Oct 8, 2018 at 6:32 PM Stephen Boyd wrote:
>
> >
> > Let's leave around one unsigned int in the gpio_irq_chip struct for the
> > single parent irq case and repoint the 'parents' array at it. This way
> > code is left mostly intact to setup
On Wed, Oct 10, 2018 at 10:29:58AM -0400, Sasha Levin wrote:
> On Mon, Oct 08, 2018 at 12:20:26PM -0700, Dmitry Torokhov wrote:
> > Hi Michael,
> >
> > On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz
> > wrote:
> > >
> > > Dmitry,
> > >
> > > someone on debian-68k reported the bug, which (to
Quoting Linus Walleij (2018-10-10 05:05:18)
> On Mon, Oct 8, 2018 at 6:32 PM Stephen Boyd wrote:
>
> >
> > Let's leave around one unsigned int in the gpio_irq_chip struct for the
> > single parent irq case and repoint the 'parents' array at it. This way
> > code is left mostly intact to setup
This irq handler is always reading bytes from the device into a
kmalloced buffer, so it's safe to mark this transaction as DMA safe.
This avoids bouncing the buffer when an i2c controller decides to use
DMA for a transaction.
Cc: Wolfram Sang
Signed-off-by: Stephen Boyd
---
This irq handler is always reading bytes from the device into a
kmalloced buffer, so it's safe to mark this transaction as DMA safe.
This avoids bouncing the buffer when an i2c controller decides to use
DMA for a transaction.
Cc: Wolfram Sang
Signed-off-by: Stephen Boyd
---
On 10/10/2018 17:35, Lukasz Luba wrote:
> Hi Thara,
>
> I have run it on Exynos5433 mainline.
> When it is enabled with step_wise thermal governor,
> some of my tests are showing ~30-50% regression (i.e. hackbench),
> dhrystone ~10%.
>
> Could you tell me which thermal governor was used in your
On 10/10/2018 17:35, Lukasz Luba wrote:
> Hi Thara,
>
> I have run it on Exynos5433 mainline.
> When it is enabled with step_wise thermal governor,
> some of my tests are showing ~30-50% regression (i.e. hackbench),
> dhrystone ~10%.
>
> Could you tell me which thermal governor was used in your
On 08/10/2018 21:28, Vitaly Kuznetsov wrote:
> Change since v3 [Sean Christopherson]:
> - Add Reviewed-by tags (thanks!).
> - Drop stale role initializer in kvm_calc_shadow_ept_root_page_role
> (interim change in PATCH4, the end result is the same).
> - Use '!!' instead of '!= 0' for
On 08/10/2018 21:28, Vitaly Kuznetsov wrote:
> Change since v3 [Sean Christopherson]:
> - Add Reviewed-by tags (thanks!).
> - Drop stale role initializer in kvm_calc_shadow_ept_root_page_role
> (interim change in PATCH4, the end result is the same).
> - Use '!!' instead of '!= 0' for
Hi Prasad,
On Tue, Oct 09, 2018 at 01:56:14PM -0700, Sodagudi Prasad wrote:
> This is regarding - thread "try to fix contention between expire_timers and
> try_to_del_timer_sync".
> https://lkml.org/lkml/2017/7/28/172
>
> I think this live lockup issue was discussed earlier but the final set of
Hi Prasad,
On Tue, Oct 09, 2018 at 01:56:14PM -0700, Sodagudi Prasad wrote:
> This is regarding - thread "try to fix contention between expire_timers and
> try_to_del_timer_sync".
> https://lkml.org/lkml/2017/7/28/172
>
> I think this live lockup issue was discussed earlier but the final set of
Hi,
The function of_get_named_gpiod_flags in older versions of the kernel (up to
4.7.10 -
https://elixir.bootlin.com/linux/v4.7.10/source/drivers/gpio/gpiolib-of.c#L75 )
contained an important workaround:
/* .of_xlate might decide to not fill in the flags, so clear it. */if (flags)
*flags =
Hi,
The function of_get_named_gpiod_flags in older versions of the kernel (up to
4.7.10 -
https://elixir.bootlin.com/linux/v4.7.10/source/drivers/gpio/gpiolib-of.c#L75 )
contained an important workaround:
/* .of_xlate might decide to not fill in the flags, so clear it. */if (flags)
*flags =
On 10/10/2018 2:58 AM, Michal Hocko wrote:
On Tue 09-10-18 13:26:41, Alexander Duyck wrote:
[...]
I would think with that being the case we still probably need the call to
__SetPageReserved to set the bit with the expectation that it will not be
cleared for device-pages since the pages are not
On 10/10/2018 2:58 AM, Michal Hocko wrote:
On Tue 09-10-18 13:26:41, Alexander Duyck wrote:
[...]
I would think with that being the case we still probably need the call to
__SetPageReserved to set the bit with the expectation that it will not be
cleared for device-pages since the pages are not
[adding linux-gpio + Linus W.]
On 10/10/18 9:13 AM, wzab wrote:
> Hi,
>
> The function of_get_named_gpiod_flags in older versions of the kernel
> (up to 4.7.10 -
> https://elixir.bootlin.com/linux/v4.7.10/source/drivers/gpio/gpiolib-of.c#L75
> )
> contained an important workaround:
>
> /*
[adding linux-gpio + Linus W.]
On 10/10/18 9:13 AM, wzab wrote:
> Hi,
>
> The function of_get_named_gpiod_flags in older versions of the kernel
> (up to 4.7.10 -
> https://elixir.bootlin.com/linux/v4.7.10/source/drivers/gpio/gpiolib-of.c#L75
> )
> contained an important workaround:
>
> /*
One Laptop Per Child is a non-profit that produced the XO series of
eductional laptops for children.
Signed-off-by: Lubomir Rintel
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
One Laptop Per Child is a non-profit that produced the XO series of
eductional laptops for children.
Signed-off-by: Lubomir Rintel
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
Lemme paste some of tglx's review comments from last time.
On Wed, Oct 10, 2018 at 09:26:07AM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> For bug workarounds or checks it is useful to check for specific
> microcode versions. Add a new table format to check for steppings
Lemme paste some of tglx's review comments from last time.
On Wed, Oct 10, 2018 at 09:26:07AM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> For bug workarounds or checks it is useful to check for specific
> microcode versions. Add a new table format to check for steppings
> > Signed-off-by: James Bottomley
> > ---
> > Documentation/process/code-of-conduct.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/process/code-of-conduct.rst
> > b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c..aa40e34e7785
> > Signed-off-by: James Bottomley
> > ---
> > Documentation/process/code-of-conduct.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/process/code-of-conduct.rst
> > b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c..aa40e34e7785
Hi,
The function of_get_named_gpiod_flags in older versions of the kernel
(up to 4.7.10 -
https://elixir.bootlin.com/linux/v4.7.10/source/drivers/gpio/gpiolib-of.c#L75 )
contained an important workaround:
/* .of_xlate might decide to not fill in the flags, so clear it. */if (flags)
*flags =
Hi,
The function of_get_named_gpiod_flags in older versions of the kernel
(up to 4.7.10 -
https://elixir.bootlin.com/linux/v4.7.10/source/drivers/gpio/gpiolib-of.c#L75 )
contained an important workaround:
/* .of_xlate might decide to not fill in the flags, so clear it. */if (flags)
*flags =
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode versions. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite difference
From: Andi Kleen
For bug workarounds or checks it is useful to check for specific
microcode versions. Add a new table format to check for steppings
with min microcode revisions.
This does not change the existing x86_cpu_id because it's an ABI
shared with modutils, and also has quite difference
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates on
From: Andi Kleen
KVM added a workaround for PEBS events leaking
into guests with 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
This uses the VT entry/exit list to add an extra disable of the PEBS_ENABLE MSR.
Intel also added a fix for this issue to microcode updates on
On 10/10/18 9:12 AM, Pavel Machek wrote:
> Hi!
>
>>> Personally I'm not happy at all with how the new code of conduct was
>>> rushed in, least because I still don't understand why it happened,
>>> but also for all the other reasons we've discussed here in the past
>>> few weeks.
>
> These are
On 10/10/18 9:12 AM, Pavel Machek wrote:
> Hi!
>
>>> Personally I'm not happy at all with how the new code of conduct was
>>> rushed in, least because I still don't understand why it happened,
>>> but also for all the other reasons we've discussed here in the past
>>> few weeks.
>
> These are
The core code already has a check for pXd_none(), so remove it from the
architecture implementation.
Cc: Chintan Pandya
Cc: Toshi Kani
Cc: Michal Hocko
Cc: Andrew Morton
Acked-by: Thomas Gleixner
Reviewed-by: Toshi Kani
Signed-off-by: Will Deacon
---
arch/x86/mm/pgtable.c | 6 --
1
The core code already has a check for pXd_none(), so remove it from the
architecture implementation.
Cc: Chintan Pandya
Cc: Toshi Kani
Cc: Michal Hocko
Cc: Andrew Morton
Acked-by: Thomas Gleixner
Reviewed-by: Toshi Kani
Signed-off-by: Will Deacon
---
arch/x86/mm/pgtable.c | 6 --
1
The core code already has a check for pXd_none(), so remove it from the
architecture implementation.
Cc: Chintan Pandya
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Michal Hocko
Cc: Andrew Morton
Signed-off-by: Will Deacon
---
arch/arm64/mm/mmu.c | 8 ++--
1 file changed, 2 insertions(+), 6
The core code already has a check for pXd_none(), so remove it from the
architecture implementation.
Cc: Chintan Pandya
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Michal Hocko
Cc: Andrew Morton
Signed-off-by: Will Deacon
---
arch/arm64/mm/mmu.c | 8 ++--
1 file changed, 2 insertions(+), 6
The current ioremap() code uses a phys_addr variable at each level of
page table, which is confusingly offset by subtracting the base virtual
address being mapped so that adding the current virtual address back on
when iterating through the page table entries gives back the corresponding
physical
Hi all,
This is version three of the patches I previously posted here:
v1:
http://lkml.kernel.org/r/1536747974-25875-1-git-send-email-will.dea...@arm.com
v2:
http://lkml.kernel.org/r/1538478363-16255-1-git-send-email-will.dea...@arm.com
The only changes since v2 are to the commit
Hi all,
This is version three of the patches I previously posted here:
v1:
http://lkml.kernel.org/r/1536747974-25875-1-git-send-email-will.dea...@arm.com
v2:
http://lkml.kernel.org/r/1538478363-16255-1-git-send-email-will.dea...@arm.com
The only changes since v2 are to the commit
The current ioremap() code uses a phys_addr variable at each level of
page table, which is confusingly offset by subtracting the base virtual
address being mapped so that adding the current virtual address back on
when iterating through the page table entries gives back the corresponding
physical
Whilst no architectures actually enable support for huge p4d mappings
in the vmap area, the code that is implemented should be using
break-before-make, as we do for pud and pmd huge entries.
Cc: Chintan Pandya
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Michal Hocko
Cc: Andrew Morton
Reviewed-by:
Whilst no architectures actually enable support for huge p4d mappings
in the vmap area, the code that is implemented should be using
break-before-make, as we do for pud and pmd huge entries.
Cc: Chintan Pandya
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Michal Hocko
Cc: Andrew Morton
Reviewed-by:
The recently merged API for ensuring break-before-make on page-table
entries when installing huge mappings in the vmalloc/ioremap region is
fairly counter-intuitive, resulting in the arch freeing functions
(e.g. pmd_free_pte_page()) being called even on entries that aren't
present. This resulted
The recently merged API for ensuring break-before-make on page-table
entries when installing huge mappings in the vmalloc/ioremap region is
fairly counter-intuitive, resulting in the arch freeing functions
(e.g. pmd_free_pte_page()) being called even on entries that aren't
present. This resulted
This patch allows to have a different binfmt_misc configuration
for each new user namespace. By default, the binfmt_misc configuration
is the one of the previous level, but if the binfmt_misc filesystem is
mounted in the new namespace a new empty binfmt instance is created and
used in this
This patch allows to have a different binfmt_misc configuration
for each new user namespace. By default, the binfmt_misc configuration
is the one of the previous level, but if the binfmt_misc filesystem is
mounted in the new namespace a new empty binfmt instance is created and
used in this
Hi guys,
On 10/10/18 14:47, Quentin Perret wrote:
> On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
>> On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
>>>
>>> On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
This patchset doesn't touch
Hi guys,
On 10/10/18 14:47, Quentin Perret wrote:
> On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
>> On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
>>>
>>> On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
This patchset doesn't touch
v6: Return _binfmt_ns instead of NULL in binfmt_ns()
This should never happen, but to stay safe return a
value we can use.
change subject from "RFC" to "PATCH"
v5: Use READ_ONCE()/WRITE_ONCE()
move mount pointer struct init to bm_fill_super() and add smp_wmb()
remove useless
v6: Return _binfmt_ns instead of NULL in binfmt_ns()
This should never happen, but to stay safe return a
value we can use.
change subject from "RFC" to "PATCH"
v5: Use READ_ONCE()/WRITE_ONCE()
move mount pointer struct init to bm_fill_super() and add smp_wmb()
remove useless
On Wed, Oct 03, 2018 at 03:03:01PM +0200, Peter Zijlstra wrote:
> On x86 we cannot do fetch_or with a single instruction and thus end up
> using a cmpxchg loop, this reduces determinism. Replace the fetch_or
> with a composite operation: tas-pending + load.
>
> Using two instructions of course
On Wed, Oct 03, 2018 at 03:03:01PM +0200, Peter Zijlstra wrote:
> On x86 we cannot do fetch_or with a single instruction and thus end up
> using a cmpxchg loop, this reduces determinism. Replace the fetch_or
> with a composite operation: tas-pending + load.
>
> Using two instructions of course
On Wed, Oct 03, 2018 at 03:02:59PM +0200, Peter Zijlstra wrote:
> While working my way through the code again; I felt the comments could
> use help.
>
> Cc: mi...@kernel.org
> Cc: will.dea...@arm.com
> Cc: t...@linutronix.de
> Cc: long...@redhat.com
> Cc: andrea.pa...@amarulasolutions.com
>
Hi!
> > Personally I'm not happy at all with how the new code of conduct was
> > rushed in, least because I still don't understand why it happened,
> > but also for all the other reasons we've discussed here in the past
> > few weeks.
These are exactly my thoughts.
> > But I also understand
On Wed, Oct 03, 2018 at 03:02:59PM +0200, Peter Zijlstra wrote:
> While working my way through the code again; I felt the comments could
> use help.
>
> Cc: mi...@kernel.org
> Cc: will.dea...@arm.com
> Cc: t...@linutronix.de
> Cc: long...@redhat.com
> Cc: andrea.pa...@amarulasolutions.com
>
Hi!
> > Personally I'm not happy at all with how the new code of conduct was
> > rushed in, least because I still don't understand why it happened,
> > but also for all the other reasons we've discussed here in the past
> > few weeks.
These are exactly my thoughts.
> > But I also understand
On Wed, Oct 10, 2018 at 6:36 PM Dmitry Vyukov wrote:
>
> On Wed, Oct 10, 2018 at 5:22 PM, Thomas Gleixner wrote:
> > On Wed, 10 Oct 2018, syzbot wrote:
> >
> > Cc+: Miklos
>
> It seems reasonable to ignore arch/.*/mm/physaddr.c as suspected
> guilty file in future -- we already ignore everything
On Wed, Oct 10, 2018 at 6:36 PM Dmitry Vyukov wrote:
>
> On Wed, Oct 10, 2018 at 5:22 PM, Thomas Gleixner wrote:
> > On Wed, 10 Oct 2018, syzbot wrote:
> >
> > Cc+: Miklos
>
> It seems reasonable to ignore arch/.*/mm/physaddr.c as suspected
> guilty file in future -- we already ignore everything
On Wed, Oct 10, 2018 at 7:28 AM Anders Roxell wrote:
>
> When test_flow_dissector.sh runs it complains that it can't find script
> with_addr.sh:
>
> ./test_flow_dissector.sh: line 81: ./with_addr.sh: No such file or
> directory
>
> Rework so that with_addr.sh gets installed, add it to
>
On Wed, Oct 10, 2018 at 7:28 AM Anders Roxell wrote:
>
> When test_flow_dissector.sh runs it complains that it can't find script
> with_addr.sh:
>
> ./test_flow_dissector.sh: line 81: ./with_addr.sh: No such file or
> directory
>
> Rework so that with_addr.sh gets installed, add it to
>
On Wed, Oct 10, 2018 at 05:13:13PM +0200, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *ret* is checked
> in an IF statement, and then its value is used to report an error at
> line 659 without being properly initialized previously:
>
> 659 if (ret)
> 660
On Wed, Oct 10, 2018 at 05:13:13PM +0200, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *ret* is checked
> in an IF statement, and then its value is used to report an error at
> line 659 without being properly initialized previously:
>
> 659 if (ret)
> 660
Hi!
[Oops. I wrote this but forgot to send it? Anyway.. I guess it is
redundant now.]
> > +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> > @@ -0,0 +1,76 @@
> > +What: /sys/class/leds//pattern
> > +Date: September 2018
> > +KernelVersion: 4.20
> >
Hi!
[Oops. I wrote this but forgot to send it? Anyway.. I guess it is
redundant now.]
> > +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> > @@ -0,0 +1,76 @@
> > +What: /sys/class/leds//pattern
> > +Date: September 2018
> > +KernelVersion: 4.20
> >
Cache the config space size from VF0 and use it for all other VFs instead
of reading it from the config space of each VF. We assume that it will be
the same across all associated VFs.
This is an optimization when enabling SR-IOV on a device with many VFs.
Cc: Bjorn Helgaas
Cc:
Cache the config space size from VF0 and use it for all other VFs instead
of reading it from the config space of each VF. We assume that it will be
the same across all associated VFs.
This is an optimization when enabling SR-IOV on a device with many VFs.
Cc: Bjorn Helgaas
Cc:
Check return value of nand_read_data_op.
Notice that, currently, all instances of nand_read_data_op() are
being checked, with the exception of two of them in marvell_nand
driver, in which the caller function explicitly returns 0 every
time.
Also, notice that I moved the declaration of *ret* to
Check return value of nand_read_data_op.
Notice that, currently, all instances of nand_read_data_op() are
being checked, with the exception of two of them in marvell_nand
driver, in which the caller function explicitly returns 0 every
time.
Also, notice that I moved the declaration of *ret* to
Hi
I just tested this kernel and saw the stall output below. I think there is
something
fishy with the ethernet driver. I had one time where it just locked up on
network traffic on issuing "ip a" via serial port on the device. All the
problems i see,
seem to be related to network traffic via
Hi
I just tested this kernel and saw the stall output below. I think there is
something
fishy with the ethernet driver. I had one time where it just locked up on
network traffic on issuing "ip a" via serial port on the device. All the
problems i see,
seem to be related to network traffic via
> -Maintainers have the right and responsibility to remove, edit, or reject
> +Maintainers may remove, edit, or reject
> comments, commits, code, wiki edits, issues, and other contributions that are
> not aligned to this Code of Conduct, or to ban temporarily or permanently any
> contributor
> -Maintainers have the right and responsibility to remove, edit, or reject
> +Maintainers may remove, edit, or reject
> comments, commits, code, wiki edits, issues, and other contributions that are
> not aligned to this Code of Conduct, or to ban temporarily or permanently any
> contributor
Hi Peter,
On 08/10/2018 23:43, Peter Rosin wrote:
> On 2018-10-03 17:19, Luca Ceresoli wrote:
>> From: Luca Ceresoli
>>
>> i2c-mux instantiates one i2c_algorithm for each downstream adapter.
>> However these algorithms are all identical, depending only on the
>> parent adapter.
>>
>> Avoid
Hi Peter,
On 08/10/2018 23:43, Peter Rosin wrote:
> On 2018-10-03 17:19, Luca Ceresoli wrote:
>> From: Luca Ceresoli
>>
>> i2c-mux instantiates one i2c_algorithm for each downstream adapter.
>> However these algorithms are all identical, depending only on the
>> parent adapter.
>>
>> Avoid
On Mon, Oct 8, 2018 at 11:23 AM Steven Rostedt wrote:
>
> On Mon, 8 Oct 2018 19:02:51 +0200
> Dmitry Vyukov wrote:
>
> > On Wed, Sep 19, 2018 at 7:13 PM, Dhaval Giani
> > wrote:
> > > Hi folks,
> > >
> > > Sasha and I are pleased to announce the Testing and Fuzzing track at
> > > LPC [ 1 ]. We
On Mon, Oct 8, 2018 at 11:23 AM Steven Rostedt wrote:
>
> On Mon, 8 Oct 2018 19:02:51 +0200
> Dmitry Vyukov wrote:
>
> > On Wed, Sep 19, 2018 at 7:13 PM, Dhaval Giani
> > wrote:
> > > Hi folks,
> > >
> > > Sasha and I are pleased to announce the Testing and Fuzzing track at
> > > LPC [ 1 ]. We
So I am flummoxed. I am reading through the code and I don't see
anything that could trigger this, and when I ran the supplied reproducer
it did not reproduce for me.
Plus there is the noise from the kmalloc_slab test that is goofing up
the subject line.
Is there any chance I can get a
So I am flummoxed. I am reading through the code and I don't see
anything that could trigger this, and when I ran the supplied reproducer
it did not reproduce for me.
Plus there is the noise from the kmalloc_slab test that is goofing up
the subject line.
Is there any chance I can get a
701 - 800 of 1504 matches
Mail list logo
