On Sun, 2019-08-04 at 21:53 +, Jon Maloy wrote:
>
> >
> > -Original Message-
> > From: netdev-ow...@vger.kernel.org
> > On
> > Behalf Of Chris Packham
> > Sent: 2-Aug-19 01:11
> > To: Jon Maloy ; tipc-
> > discuss...@lists.sourcefor
Hi All,
I have a custom board that uses the Freescale/NXP T2080 SoC.
The board boots fine using v4.19.60 but when I use v5.1.21 it locks up
waiting for the other CPUs to come online (earlyprintk output below).
If I set maxcpus=0 then the system boots all the way through to
userland. The same
On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> Hi All,
>
> I have a custom board that uses the Freescale/NXP T2080 SoC.
>
> The board boots fine using v4.19.60 but when I use v5.1.21 it locks
> up
> waiting for the other CPUs to come online (earlyprintk outp
On Mon, 2019-08-05 at 14:02 +, Tommy Jin wrote:
> Hi Chris,
>
> My name is Tommy, from wave computing Co,Ltd, our team is working on
> the maintenance of the MIPS kernel.
>
> You raised a MIPS cache coherency patch which can be found in the
> following links
>
the L2 cache parity and ecc support.
Chris Packham (3):
ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
ARM: dts: mvebu: add sdram controller node to Armada-38x
ARM: dts: armada-xp: add label to sdram-controller node
arch/arm/boot/dts/armada-38x.dtsi | 5
The Armada-38x uses an SDRAM controller that is compatible with the
Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
is 32/16). The SDRAM controller registers are the same between the two
SoCs.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-38x.dtsi | 5
Enable L2 cache parity and ECC on the db-xc3-24g4xg board so that cache
operations are protected and errors can be flagged to the EDAC
subsystem.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot
Add the label "sdramc" to the sdram-controller nodes for the Armada-XP
and 98dx3236 SoCs.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi All,
On Fri, 2019-08-02 at 06:40 +0200, Christophe Leroy wrote:
>
> Le 02/08/2019 à 00:50, Chris Packham a écrit :
> > Bring powerpc in line with other architectures that support extending or
> > overriding the bootloader provided command line.
> >
> > The
Hi,
We have a platform using the BCM53344 integrated switch/CPU. This is
part of the Hurricane 2 (technically Wolfhound) family of devices.
Currently we're using pieces of Broadcom's "iProc" SDK based on an out
of date kernel and we'd very much like to be running as close to
upstream as
Hi Florian,
On Mon, 2019-09-30 at 19:54 -0700, Florian Fainelli wrote:
>
> On 9/30/2019 7:33 PM, Chris Packham wrote:
> > Hi,
> >
> > We have a platform using the BCM53344 integrated switch/CPU. This is
> > part of the Hurricane 2 (technically Wolfhound) family
On Thu, 2019-08-29 at 05:46 -0700, Guenter Roeck wrote:
> On 8/29/19 1:50 AM, Chris Packham wrote:
> > The orion watchdog can either reset the CPU or generate an interrupt.
> > The interrupt would be useful for debugging as it provides panic()
> > output about the wat
triggers.
Signed-off-by: Chris Packham
---
Changes in v6:
- Fix bitwise operation in armada375_stop()
- Add comment about 2nd interrupt being optional
Changes in v5:
- Group bit values with register addresses
- Address review comments from Gunter
Changes in v3:
- rebase against linux/master
Changes
On Tue, 2019-10-01 at 16:04 +1300, Chris Packham wrote:
> Hi Florian,
>
> On Mon, 2019-09-30 at 19:54 -0700, Florian Fainelli wrote:
> >
> > On 9/30/2019 7:33 PM, Chris Packham wrote:
> > > Hi,
> > >
> > > We have a platform using the BC
platform_get_irq() can return an error code. Allow for this when getting
the irq. While we're here use the dev_name(dev) for the irqc->name so
that we get unique names when we have multiple instances of this driver.
Signed-off-by: Chris Packham
---
Noticed this while debugging another prob
I noticed these when debugging another issue. The first patch is a fix
to address some error handling. The second is just cosmetic.
Changes in v2:
- split bug-fix from cosmetic change
Chris Packham (2):
pinctrl: iproc: allow for error from platform_get_irq()
pinctrl: iproc: use unique name
platform_get_irq() can return an error code. Allow for this when getting
the irq.
Fixes: 6f265e5d4da7 ("pinctrl: bcm-iproc: Pass irqchip when adding gpiochip")
Signed-off-by: Chris Packham
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Use the dev_name(dev) for the irqc->name so that we get unique names
when we have multiple instances of this driver.
Signed-off-by: Chris Packham
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-ip
itself is halfway between pinctrl-nsp-gpio.c
and pinctrl-iproc-gpio.c.
Chris Packham (2):
dt-bindings: gpio: brcm: Add bindings for xgs-iproc
gpio: Add xgs-iproc driver
.../bindings/gpio/brcm,xgs-iproc.txt | 41 ++
drivers/gpio/Kconfig | 9 +
drivers/gpio
This GPIO controller is present on a number of Broadcom switch ASICs
with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio
blocks but different enough to require a separate driver.
Signed-off-by: Chris Packham
---
.../bindings/gpio/brcm,xgs-iproc.txt | 41
XLDK 5.0.3 retaining only the CCA
support (pinctrl-iproc-gpio covers CCB).
Signed-off-by: Chris Packham
---
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-xgs-iproc.c | 422 ++
3 files changed, 432 insertions
From: Jan Luebbe
This include file will be used by the AURORA EDAC code.
Signed-off-by: Jan Luebbe
Reviewed-by: Gregory CLEMENT
Signed-off-by: Chris Packham
---
KernelVersion: 5.3rc
Hi Russell,
This is the missing first patch for the Armada EDAC series
https://www.armlinux.org.uk/developer
On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
wrote:
> On Mon, Aug 26, 2019 at 12:46:44AM +0000, Chris Packham wrote:
> > Hi Russell,
> >
> > On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Fri, Aug 2
On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
wrote:
> On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > wrote:
> > > Just send the single patch to the patch tra
triggers.
Signed-off-by: Chris Packham
---
This was submitted previously[1], the other patches two from the series have
been picked up but this one seems to have fallen through the gaps.
Changes in v3:
- rebase against linux/master
Changes in v2:
- apply changes to armada-38x only
[1] -
https
On Wed, 2019-08-28 at 21:45 -0700, Guenter Roeck wrote:
> On 8/28/19 6:53 PM, Chris Packham wrote:
> > The orion watchdog can either reset the CPU or generate an interrupt.
> > The interrupt would be useful for debugging as it provides panic()
> > output about the wat
triggers.
Signed-off-by: Chris Packham
---
Changes in v5:
- Group bit values with register addresses
- Address review comments from Gunter
Changes in v4:
- rebase against linux/master
Changes in v2:
- apply changes to armada-38x only
drivers/watchdog/orion_wdt.c | 65
same core as the
BMIPS4355.
> I probably couldn't get a broadcom BMIPS4350, is there any simulator
> for this board(e.g. QEMU)?
Yeah it's a pretty old chip. I'm not aware of any QEMU support, but I
haven't looked.
>
> Best regards,
> Tommy
> From: linux-mips-ow...@vger.kernel
We set the field 'addr_trial_end' to 'jiffies', instead of the current
value 0, at the moment the node address is initialized. This guarantees
we don't inadvertently enter an address trial period when the node
address is explicitly set by the user.
Signed-off-by: Chris Packham
Acked-by: Jon
XLDK 5.0.3 retaining only the CCA
support (pinctrl-iproc-gpio covers CCB).
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- use more of the generic infrastructure for gpio chips
- handling the root interrupt is still done manually due to sharing with
uart0.
drivers/gpio
with
other drivers. The driver itself is halfway between pinctrl-nsp-gpio.c
and pinctrl-iproc-gpio.c.
Chris Packham (2):
dt-bindings: gpio: brcm: Add bindings for xgs-iproc
gpio: Add xgs-iproc driver
.../bindings/gpio/brcm,xgs-iproc.yaml | 83 +
drivers/gpio/Kconfig
This GPIO controller is present on a number of Broadcom switch ASICs
with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio
blocks but different enough to require a separate driver.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- Document as DT schema
- Include
This allows boards the option of adding properties or disabling the
watchdog entirely.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/bcm-hr2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index
> >
> > > On Thu, Oct 3, 2019 at 2:03 AM Chris Packham
> > > wrote:
> > > > Use the dev_name(dev) for the irqc->name so that we get unique names
> > > > when we have multiple instances of this driver.
> > > >
> > > >
On Fri, 2019-10-11 at 09:43 +0200, Linus Walleij wrote:
> Hi Chris!
>
> Thanks for your patch!
>
> On Fri, Oct 4, 2019 at 3:25 AM Chris Packham
> wrote:
>
> > This driver supports the Chip Common A GPIO controller present on a
> > number of Broadcom
On 23/07/20 10:11 am, Chris Packham wrote:
>
> On 22/07/20 4:19 pm, Chris Packham wrote:
>> Hi,
>>
>> I've just fired up linux kernel v5.7 on a p2040 based system and I'm
>> getting the following new warning
>>
>> OF: Can't handle multiple dma-range
a power interruption.
Signed-off-by: Chris Packham
---
Changes in v2:
- Set bootstatus to WDIOF_CARDRESET and let userspace decide what to do with
the information.
drivers/rtc/rtc-ds1307.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc
a power interruption.
Signed-off-by: Chris Packham
---
Changes in v3:
- Check for watchdog flag in ds1307_wdt_register()
Changes in v2:
- Set bootstatus to WDIOF_CARDRESET and let userspace decide what to do with
the information.
drivers/rtc/rtc-ds1307.c | 6 ++
1 file changed, 6 insertions
Hi,
I'm in the process updating our platforms from a v4.4.x based kernel to
a v5.7 based one.
On one of our Marvell Kirkwood based boards I'm seeing a problem where a
gpio isn't being driven (the gpio happens to be a reset to a PHY chip
that our userspace switching code is attempting to talk
to try and recover the bus.
>
> Signed-off-by: Mark Tomlinson
Reviewed-by: Chris Packham
One additional comment below
> ---
> drivers/i2c/busses/i2c-mv64xxx.c | 77 +++-
> 1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/driver
On 15/07/20 1:51 am, Jonathan Corbet wrote:
> On Tue, 14 Jul 2020 21:06:43 +1200
> Chris Packham wrote:
>
>> When processing proc.rst sphinx complained
>>
>>Documentation/filesystems/proc.rst:548: WARNING: Malformed table.
>>Text in column margin in
Hi Jon,
On 14/07/20 9:06 pm, Chris Packham wrote:
> Sphinx complains
>
>Documentation/filesystems/proc.rst:2194: WARNING: Inconsistent literal
> block quoting.
>
> Update the command line snippets to be properly formed literal blocks.
>
> Signed-off-by: Chris Packham
Hi,
Not sure exactly where to direct this so I'm just hitting linux-mm and
linux-kernel and hoping someone sees it.
We're in the process of updating our embedded targets from Linux 4.4.x
to the latest kernel (currently v5.6 but we're planning to go to v5.7
and maybe v5.8 depending on timing).
On 24/07/20 1:31 am, Andrew Lunn wrote:
> On Thu, Jul 23, 2020 at 03:59:41PM +1200, Chris Packham wrote:
>> Add implementations for the mv88e6xxx switches to connect with the
>> generic dsa operations for configuring the port MTU.
> Hi Chris
>
> What tree is th
On 24/07/20 1:34 am, Andrew Lunn wrote:
> On Thu, Jul 23, 2020 at 03:59:42PM +1200, Chris Packham wrote:
>> Some of the chips in the mv88e6xxx family don't support jumbo
>> configuration per port. But they do have a chip-wide max frame size that
>> can be used. Us
On 24/07/20 9:02 am, Andrew Lunn wrote:
> On Thu, Jul 23, 2020 at 08:50:27PM +0000, Chris Packham wrote:
>> On 24/07/20 1:31 am, Andrew Lunn wrote:
>>> On Thu, Jul 23, 2020 at 03:59:41PM +1200, Chris Packham wrote:
>>>> Add implementations for the
Some of the chips in the mv88e6xxx family don't support jumbo
configuration per port. But they do have a chip-wide max frame size that
can be used. Use this to approximate the behaviour of configuring a port
based MTU.
Signed-off-by: Chris Packham
---
The only hardware I have access to uses
The MV88E6190 and MV88E6190X both support per port jumbo configuration
just like the other GE switches. Install the appropriate ops.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
I'm including this change in my series for completeness. Looking at the
datasheets I think
are unchanged (aside from adding
Andrew's Reviewed-by). Patch 3 is reworked to make use of the existing mtu
support.
Chris Packham (3):
net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration
net: dsa: mv88e6xxx: Support jumbo configuration on 6190/6190X
net: dsa: mv88e6xxx: Use
: dsa: mv88e6xxx: Refactor setting of jumbo frames")
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Changes in v2:
- Add review from Andrew
drivers/net/dsa/mv88e6xxx/chip.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6
There's not much feedback when the ds1388 watchdog fires. Generally it
yanks on the reset line and the board reboots. To provide some feedback
indicate that the watchdog has fired in the past. This should help
distinguish a watchdog triggered reset from a power interruption.
Signed-off-by: Chris
Hi,
I've just fired up linux kernel v5.7 on a p2040 based system and I'm
getting the following new warning
OF: Can't handle multiple dma-ranges with different offsets on
node(/pcie@ffe202000)
OF: Can't handle multiple dma-ranges with different offsets on
node(/pcie@ffe202000)
The warning
On 22/07/20 4:19 pm, Chris Packham wrote:
> Hi,
>
> I've just fired up linux kernel v5.7 on a p2040 based system and I'm
> getting the following new warning
>
> OF: Can't handle multiple dma-ranges with different offsets on
> node(/pcie@ffe202000)
> OF: Can't ha
Add implementations for the mv88e6xxx switches to connect with the
generic dsa operations for configuring the port MTU.
Signed-off-by: Chris Packham
---
drivers/net/dsa/mv88e6xxx/chip.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx
The MV88E6190 and MV88E6190X both support per port jumbo configuration
just like the other GE switches. Install the appropriate ops.
Signed-off-by: Chris Packham
---
I'm including this change in my series for completeness. Looking at the
datasheets I think this is an unintentional omission
: dsa: mv88e6xxx: Refactor setting of jumbo frames")
Signed-off-by: Chris Packham
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 7627ea61e0ea..fbfa4087eb7b 100644
--- a/drive
This series connects up the mv88e6xxx switches to the dsa infrastructure for
configuring the port MTU. The first patch is also a bug fix which might be a
candiatate for stable.
Chris Packham (4):
net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration
net: dsa: mv88e6xxx: Support
Some of the chips in the mv88e6xxx family don't support jumbo
configuration per port. But they do have a chip-wide max frame size that
can be used. Use this to approximate the behaviour of configuring a port
based MTU.
Signed-off-by: Chris Packham
---
The only hardware I have access to uses
Hi,
I'm trying to port a fairly old Broadcom integrated chip (BCM6818) to
the latest Linux kernel using the mips/bmips support.
The chip has a BMIPS4355 core. This has two "thread processors" (cpu
cores) with separate I-caches but a shared D-cache.
I've got things booting but I encounter the
On 28/05/19 2:52 PM, Chris Packham wrote:
> Hi,
>
> I'm trying to port a fairly old Broadcom integrated chip (BCM6818) to
> the latest Linux kernel using the mips/bmips support.
>
> The chip has a BMIPS4355 core. This has two "thread processors" (cpu
> cores) with
Hi Paul,
On 29/05/19 9:01 AM, Paul Burton wrote:
> Hi Chris,
>
> On Tue, May 28, 2019 at 05:19:37AM +0000, Chris Packham wrote:
>> On 28/05/19 2:52 PM, Chris Packham wrote:
>>> Hi,
>>>
>>> I'm trying to port a fairly old Broadcom integrated chip (BCM
flush_cache_vmap() and flush_cache_vunmap() were calling
r4k_blast_dcache() which is not safe to do on a SMP system. Redefine
them to call r4k_flush_kernel_vmap_range() which will correctly handle
the SMP/UP cases.
Signed-off-by: Chris Packham
---
I don't know if passing 0, dcache_size
Hi All,
I'm in the process of updating the kernel version used on our products
from 4.4 -> 5.1.
We have one product that uses a Kirkwood CPU, IDT PCI bridge and Marvell
Switch ASIC. The Switch ASIC presents as multiple PCI devices.
The hardware setup looks like this
Hi Thomas,
On 21/06/19 6:17 PM, Thomas Petazzoni wrote:
> Hello Chris,
>
> On Fri, 21 Jun 2019 04:03:27 +0000
> Chris Packham wrote:
>
>> I'm in the process of updating the kernel version used on our products
>> from 4.4 -> 5.1.
>>
>> We have one
The 98DX1135 is a switch chip with an integrated CPU. This is similar to
the 98DX4122 except that the core clock speed is fixed to 166Mhz.
Signed-off-by: Chris Packham
---
drivers/clk/mvebu/kirkwood.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/clk/mvebu
The 98DX1135 is a switch chip with an integrated CPU. This is similar to
the 98DX4122 except the MPP assignments differ.
Signed-off-by: Chris Packham
---
drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 576 ---
1 file changed, 297 insertions(+), 279 deletions(-)
diff --git
Add compatible string for the core clock on the 98dx1135 switch with
integrated CPU.
Signed-off-by: Chris Packham
---
Documentation/devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
b
The Marvell 98DX1135 is a switch chip with an integrated ARMv5 CPU, it is
similar to the 98DX4122 with differences in clocking and pin control.
I haven't added a separate dts for the SoC since it would be so similar to
kirkwood-98dx4122.dtsi.
Chris Packham (4):
dt-bindings: pinctrl: mvebu
The 98DX1135 is similar to the 98DX4122 except the MPP options differ.
Signed-off-by: Chris Packham
---
.../pinctrl/marvell,kirkwood-pinctrl.txt | 44 ++-
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/pinctrl/marvell
Hi Andrew,
On 18/06/19 5:09 AM, Andrew Lunn wrote:
> On Mon, Jun 17, 2019 at 10:04:30PM +1200, Chris Packham wrote:
>> Add compatible string for the core clock on the 98dx1135 switch with
>> integrated CPU.
>
> Hi Chris
>
> Should there be a list of provider IDs and
The 98DX1135 is similar to the 98DX4122 except the MPP options differ.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
.../pinctrl/marvell,kirkwood-pinctrl.txt | 44 ++-
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree
The 98DX1135 is a switch chip with an integrated CPU. This is similar to
the 98DX4122 except the MPP assignments differ.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 576 ---
1 file changed, 297 insertions(+), 279
Add compatible string for the core clock on the 98dx1135 switch with
integrated CPU.
Signed-off-by: Chris Packham
---
Changes in v2:
- Update description to make it clear the clock names are the same as Kirkwood
Documentation/devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
1 file changed
The 98DX1135 is a switch chip with an integrated CPU. This is similar to
the 98DX4122 except that the core clock speed is fixed to 166Mhz.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
drivers/clk/mvebu/kirkwood.c | 17 +
1 file changed, 17 insertions(+)
diff --git
-core-clock
- Collect review from Andrew
Chris Packham (4):
dt-bindings: pinctrl: mvebu: Document bindings for 98DX1135
dt-bindings: clock: mvebu: Add compatible string for 98dx1135 core
clock
pinctrl: mvebu: Add support for MV98DX1135
clk: kirkwood: Add support for MV98DX1135
On 18/06/19 10:08 AM, Richard Weinberger wrote:
> On Fri, Jun 14, 2019 at 5:26 AM Chris Packham
> wrote:
>>
>> Hi All,
>>
>> Ping?
>
> Your patch is not lost. We start soon with collecting all material for
> the merge window. :-)
>
OK thanks for the confirmation and sorry for the noise.
Hi LinusW, Bartosz,
I was debugging something else and I noticed a problem with the gpio
framework or the gpio-mmio driver (or both) in 5.2.0-rc6.
I have some gpio hogs in my device tree which seem to get requested at
startup as expected
...
GPIO line 456 (sw-reset) hogged as output/low
GPIO
On 3/07/19 6:28 PM, Linus Walleij wrote:
> On Wed, Jul 3, 2019 at 7:35 AM Chris Packham
> wrote:
>
>> Doing a bit of debugging so far I see that after startup the desc->flags
>> for those gpios is 0. But for the hogged ones it should be 0x800 (or 0x801).
>
> Yea
Hi All,
On 10/05/19 10:15 PM, Chris Packham wrote:
> The Reviews/Acks have been given so this should be good to go in via the ARM
> tree as planned.
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html
>
> This series adds drivers for the L2 cac
On 3/07/19 9:29 PM, Chris Packham wrote:
> On 3/07/19 6:28 PM, Linus Walleij wrote:
>> On Wed, Jul 3, 2019 at 7:35 AM Chris Packham
>> wrote:
>>
>>> Doing a bit of debugging so far I see that after startup the desc->flags
>>> for those gpios is 0.
desc->flags may already have values set by of_gpiochip_add() so make
sure that this isn't undone when setting the initial direction.
Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning")
Signed-off-by: Chris Packham
---
drivers/gpio/gpiolib.c | 8 +++
desc->flags may already have values set by of_gpiochip_add() so make
sure that this isn't undone when setting the initial direction.
Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning")
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
Hi,
I'm in the process of updating our products from a 4.4 based kernel to
5.1 (and probably 5.2 since that release is imminent).
On one product which uses a Freescale/NXP P2041 CPU, IDT pcie bridge and
Marvell switch chip[1].
Annoyingly the hardware has a reset line that holds the switch
desc->flags may already have values set by of_gpiochip_add() so make
sure that this isn't undone when setting the initial direction.
Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning")
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
off-by: Chris Packham
---
I'm updating our products to use the latest kernel. One change that we have that
doesn't appear to have been upstreamed is related to the following soft lockup.
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [swapper/3:0]
Modules linked in: tipc jitterentropy_
On 10/05/20 12:20 pm, Serge Semin wrote:
> On Fri, May 08, 2020 at 12:37:51PM +0100, Mark Brown wrote:
>>> + writel(BIT(req->cs), bs->regs + BC_SPI_SER);
>>> + if (req->cs_gpiod) {
>>> + gpiod_set_value_cansleep(req->cs_gpiod,
>>> +
On Fri, 2019-07-26 at 15:53 +0100, James Morse wrote:
> Hi Chris,
>
> On 12/07/2019 04:48, Chris Packham wrote:
> >
> > I still seem to be struggling to get this on anyone's radar.
> Whose radar does it need to cross?
>
That's a good question. The last solid guidance
On Fri, 2019-07-26 at 15:51 +0100, James Morse wrote:
> Hi Chris,
>
> On 12/07/2019 04:49, Chris Packham wrote:
> >
> > The Armada 38x and other integrated SoCs use a reduced pin count so
> > the
> > width of the SDRAM interface is smaller than the A
On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote:
>
> >
> > -Original Message-
> > From: netdev-ow...@vger.kernel.org
> > On
> > Behalf Of Chris Packham
> > Sent: 25-Jul-19 19:37
> > To: tipc-discuss...@lists.sourceforge.net
> > Cc: n
for both chips. The PCA9564 should not return 0x78 for any valid
state and the PCA9665 should not return 0x90.
Signed-off-by: Chris Packham
---
Changes in v2:
- Note which status corresponds to which chip
- Move patch commentary to commit message
drivers/i2c/algos/i2c-algo-pca.c | 3 ++-
1 file
Hi,
I was just browsing
https://www.kernel.org/doc/html/latest/filesystems/proc.html
The "VmFlags" description seems to be missing a table. It's there in
Documentation/filesystems/proc.rst so I assume it's some sphinx/rst
problem. Possibly the table is over indented?
Anyway I thought I'd let
On 14/07/20 6:06 pm, Randy Dunlap wrote:
> On 7/13/20 10:11 PM, Chris Packham wrote:
>> Hi,
>>
>> I was just browsing
>> https://www.kernel.org/doc/html/latest/filesystems/proc.html
>>
>> The "VmFlags" description seems to be missing a table. It's
When processing proc.rst sphinx complained
Documentation/filesystems/proc.rst:548: WARNING: Malformed table.
Text in column margin in table line 29.
This caused the entire table to be dropped. Removing the stray '-'
resolves the error and produces the desired table.
Signed-off-by: Chris
Sphinx complains
Documentation/filesystems/proc.rst:2194: WARNING: Inconsistent literal block
quoting.
Update the command line snippets to be properly formed literal blocks.
Signed-off-by: Chris Packham
---
Documentation/filesystems/proc.rst | 38 +-
1 file
The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck
low, this differs to the PCA9564 which uses 90h for this indication.
Treat either 0x78 or 0x90 as an indication that the SCL line is stuck.
Signed-off-by: Chris Packham
---
Based on looking through the PCA9564 and PCA9665
CONFIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONFIG_CMDLINE_BOOL' ineffective.
$ ./scripts/config --enable CONFIG_CMDLINE_BOOL
$ cat .config
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Remove CONFIG_CMDLINE_BOOL and the inaccessible default.
Signed-off-by
On 11/06/20 5:46 pm, Christophe Leroy wrote:
>
>
> Le 11/06/2020 à 05:41, Chris Packham a écrit :
>> Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
>> CONFIG_CMDLINE has always had a value regardless of CONFIG_CMDLINE_BOOL.
>>
>&g
This series cleans up the config options related to the boot command line.
Chris Packham (2):
powerpc: Remove inaccessible CMDLINE default
powerpc: configs: remove CMDLINE_BOOL
arch/powerpc/Kconfig | 6 +-
arch/powerpc/configs/44x/akebono_defconfig | 2
Regenerate defconfigs to remove CONFIG_CMDLINE_BOOL and the default
CONFIG_CMDLINE where applicable.
Signed-off-by: Chris Packham
---
Changes in v3:
- new
arch/powerpc/configs/44x/akebono_defconfig | 2 --
arch/powerpc/configs/44x/arches_defconfig | 2 --
arch/powerpc/configs/44x
CONFIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONFIG_CMDLINE_BOOL' ineffective.
$ ./scripts/config --enable CONFIG_CMDLINE_BOOL
$ cat .config
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Remove CONFIG_CMDLINE_BOOL and the inaccessible default.
Signed-off-by
701 - 800 of 1277 matches
Mail list logo
