concat_lock() and concat_unlock() only differed in terms of the mtd_xx
operation they called. Refactor them to use a common helper function and
pass a boolean flag to indicate whether lock or unlock is needed.
Signed-off-by: Chris Packham
---
Changes in v2:
- Use a boolean flag instead of
];
^~~
We still want to ensure any padding bytes at the end are initialised, do
this with a explicit memset() rather than copy bytes past the end of
data. Apply the same logic to TCM_SET.
Signed-off-by: Chris Packham
---
Changes in v2:
- Ensure padding bytes are initialis
On 21/05/19 6:54 AM, Kees Cook wrote:
> [Adding Chris and Ard, who might have more compiler versions that me...]
Late to the thread but ...
>
> On Mon, May 20, 2019 at 07:08:39PM +0200, H. Nikolaus Schaller wrote:
>>> Am 20.05.2019 um 17:59 schrieb Kees Cook :
>>>
>>> On Mon, May 20, 2019 at 05:
The return from of_overlay_fdt_apply() just indicates success or fail.
The cookie is returned via reference.
Signed-off-by: Chris Packham
---
Documentation/devicetree/overlay-notes.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/overlay
Hi Frank,
On 8/04/19 1:05 PM, Frank Rowand wrote:
> Hi Chris,
>
> On 4/3/19 6:50 PM, Chris Packham wrote:
>> Hi,
>>
>> I'm implementing support for some modular Linux based systems using
>> device tree overlays. The code is working but it seems a little mo
On 28/03/19 9:32 PM, Boris Brezillon wrote:
> On Thu, 28 Mar 2019 17:02:15 +1300
> Chris Packham wrote:
>
>> When the gpio-addr-flash.c driver was merged with physmap-core.c the
>> code to store the current gpio_values was lost. This meant that once a
>> gpio w
I have a system with ADDR24 of the flash chip connected to a gpio pin. This
series fixes a bug in physmap-core.c and adds an example for using gpio-addrs
to the dt-binding based on the system I'm using.
Chris Packham (2):
mtd: maps: physmap: Store gpio_values correctly
dt-binding
Add an example showing how to use the addr-gpios property to deal with a
system with limited IO space.
Cc: devicet...@vger.kernel.org
Signed-off-by: Chris Packham
---
Changes in v2:
- None
.../devicetree/bindings/mtd/mtd-physmap.txt | 16
1 file changed, 16 insertions
("mtd: maps: Merge gpio-addr-flash.c into
physmap-core.c")
Cc:
Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
---
Changes in v2:
- Cc stable, add Boris' review
drivers/mtd/maps/physmap-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/maps/p
On 12/04/19 8:29 PM, Mark Brown wrote:
> On Fri, Apr 12, 2019 at 05:02:10PM +1200, Chris Packham wrote:
>
>> Unfortunately recent changes have stopped my hacks from working. I've
>> tried adapting cs-gpios to work with my particular hardware but I came
>> to the re
ive
path.
Signed-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]
Modul
Add documentation for the marvell,ecc-enable properties which can be
used to enable ECC on the Marvell aurora cache.
Signed-off-by: Chris Packham
Reviewed-by: Rob Herring
---
Notes:
Changes in v7:
- remove marvell,ecc-disable
Changes in v6:
- new (split binding doc from
From: Jan Luebbe
These defines will be used by subsequent patches to add support for the
parity check and error correction functionality in the Aurora L2 cache
controller.
Signed-off-by: Jan Luebbe
Signed-off-by: Chris Packham
---
.../include/asm/hardware/cache-aurora-l2.h| 48
The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "marvell,ecc-enable" device tree property
which can be used to enable this.
Signed-off-by: Chris Packham
[j...@pengutronix.de: use aurora specific define AURORA_ACR_ECC_EN]
Signed-o
64 bit (review comment by
Chris)
- Use of_match_ptr() (review comments by Chris)
- Minor checkpatch cleanups
Chris Packham (4):
ARM: l2x0: support parity-enable/disable on aurora
dt-bindings: ARM: document marvell,ecc-enable binding
ARM: l2x0: add marvell,ecc-enable property for aurora
EDAC
From: Jan Luebbe
Add support for the ECC functionality as found in the DDR RAM and L2
cache controllers on the MV78230/MV78x60 SoCs. This driver has been
tested on the MV78460 (on a custom board with a DDR3 ECC DIMM).
Signed-off-by: Jan Luebbe
[cp use SPDX license]
Signed-off-by: Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.
Signed-off-by: Chris Packham
[j...@pengutronix.de: use aurora specific define AURORA_ACR_PARITY_EN]
Signed-off-by: Jan Luebbe
---
arch/arm/mm/cache-l2x0.c | 7 +++
1
The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.
Signed-off-by: Chris Packham
---
drivers/edac/
From: Jan Luebbe
The macro name is too generic, so add a AURORA_ prefix.
Signed-off-by: Jan Luebbe
Reviewed-by: Gregory CLEMENT
Signed-off-by: Chris Packham
---
arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
arch/arm/mm/cache-l2x0.c| 4 ++--
2 files changed
From: Jan Luebbe
We already have wrappers for x8 and x16, so add the missing x32 one.
Signed-off-by: Jan Luebbe
Reviewed-by: Borislav Petkov
Signed-off-by: Chris Packham
---
Notes:
Changes in v9:
- Adapt debugfs_create_x32 to account for recent changes to debugfs apis
drivers/edac
which was
> marked __maybe_used remained.
>
> Since commit ed1cd6deb013 ("powerpc: Activate
> CONFIG_THREAD_INFO_IN_TASK") thread_info cannot be reached before mmu
> is properly set up.
>
> Drop this stale call to smp_processor_id() which make SMP hang
> when C
tion phase.
Signed-off-by: Chris Packham
---
Changes in v2:
- move setting to tipc_set_node_addr() as suggested
- reword commit message
net/tipc/addr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/addr.c b/net/tipc/addr.c
index b88d48d00913..0f1eaed1bd1b 100644
--- a/net/tipc/addr.c
ich I believe is the 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
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: Chr
On Wed, 2019-07-31 at 09:23 +0200, Christophe Leroy wrote:
>
> Le 30/07/2019 à 23:10, Chris Packham a écrit :
> >
> > Hi Christophe,
> >
> > On Tue, 2019-07-30 at 09:02 +0200, Christophe Leroy wrote:
> > >
> > >
&g
CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND can
be used to append the CMDLINE from the kernel config to the one provided
by the bootloader.
Signed-off-by: Chris Packham
---
While I'm at it does anyone think it's worth getting rid of the default CMDLINE
value if CMDLINE_BOOL and maybe CMDLINE_B
On Thu, 2019-08-01 at 08:14 +0200, Christophe Leroy wrote:
>
> Le 01/08/2019 à 04:12, Chris Packham a écrit :
> >
> > Bring powerpc in line with other architectures that support
> > extending or
> > overriding the bootloader provided command line.
> >
&g
CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND can
be used to append the CMDLINE from the kernel config to the one provided
by the bootloader.
Signed-off-by: Chris Packham
---
Changes in v3:
- don't use BUG_ON in prom_strlcat
- rearrange things to eliminate prom_strlcpy
Changes in v2:
- incorporate ideas
t
CONFIG_CMDLINE_BOOL=y also set CONFIG_CMDLINE to something else. For
these reasons remove the inaccessible default.
Signed-off-by: Chris Packham
---
This should be independent of http://patchwork.ozlabs.org/patch/1140811/ but
I've generated this patch on a stream that has it applied locally.
On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote:
> >
> >
> > >
> > >
> > > -Original Message-
> > > From: netdev-ow...@vger.kernel.org
> > > On
> > > Behal
Hi,
I'm having problems forming a TIPC cluster between 2 nodes.
This is the basic steps I'm going through on each node.
modprobe tipc
ip link set eth2 up
tipc node set addr 1.1.5 # or 1.1.6
tipc bearer enable media eth dev eth0
Then to confirm if the cluster is formed I use tipc link list
[roo
On Fri, 2019-08-02 at 07:18 +0200, Christophe Leroy wrote:
>
> Le 02/08/2019 à 07:02, Chris Packham a écrit :
> >
> > Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef
> > mess")
> > CONFIG_CMDLINE has always had a value regardless of
&g
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 thin
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
> https://lore.kernel.org/linux-mi
Hi Christophe,
On Tue, 2019-07-30 at 09:02 +0200, Christophe Leroy wrote:
>
> Le 24/07/2019 à 07:33, Chris Packham a écrit :
> >
> > Device tree aware platforms can make use of CMDLINE_EXTEND to
> > extend the
> > kernel command line provided by the bootlo
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > 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.
&
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> > >
> > > Chris Packham writes:
> > > >
> > > > On Mon, 2019-08-05 at 14:06 +1200
Hi Jon,
On Wed, 2019-08-07 at 02:55 +, Jon Maloy wrote:
>
> >
> > -Original Message-
> > From: Chris Packham
> > Sent: 4-Aug-19 19:05
> > To: Jon Maloy ; tipc-
> > discuss...@lists.sourceforge.net
> > Cc: net...@vger.kernel.org;
assume that the address is not yet valid and
unnecessarily delays the discovery phase. By setting addr_trail_end to
jiffies when using explicit addresses we ensure that we move straight to
discovery.
Signed-off-by: Chris Packham
---
net/tipc/discover.c | 2 ++
1 file changed, 2 insertions(+)
diff
parameter so removing the reference to the non-existent
function seems like the best thing to do.
Signed-off-by: Chris Packham
---
drivers/net/ethernet/freescale/fman/fman.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c
b/drivers/net/ethernet/freescale
-off-by: Chris Packham
---
arch/powerpc/Kconfig | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d8dcd8820369..cd9b3974aa36 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -851,6 +851,11 @@ config CMDLINE
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 hav
On 24/06/19 4:08 PM, Chris Packham wrote:
> Hi Thomas,
>
> On 21/06/19 6:17 PM, Thomas Petazzoni wrote:
>> Hello Chris,
>>
>> On Fri, 21 Jun 2019 04:03:27 +
>> Chris Packham wrote:
>>
>>> I'm in the process of updating the kernel version
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
x1135-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 MV98D
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.
On 26/06/19 12:27 AM, Linus Walleij wrote:
> On Mon, Jun 17, 2019 at 11:55 PM Chris Packham
> wrote:
>
>> 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 Pac
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 l
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
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. But
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 |
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 chip
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
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 jitt
On 8/07/19 8:18 PM, Eric Dumazet wrote:
>
>
> On 7/8/19 12:53 AM, Chris Packham wrote:
>> tipc_named_node_up() creates a skb list. It passes the list to
>> tipc_node_xmit() which has some code paths that can call
>> skb_queue_purge() which relies on the list->loc
On 9/07/19 8:43 AM, Chris Packham wrote:
> On 8/07/19 8:18 PM, Eric Dumazet wrote:
>>
>>
>> On 7/8/19 12:53 AM, Chris Packham wrote:
>>> tipc_named_node_up() creates a skb list. It passes the list to
>>> tipc_node_xmit() which has some code paths that can cal
On 11/07/19 1:10 AM, Jon Maloy wrote:
>> -Original Message-
>> From: Eric Dumazet
>> Sent: 10-Jul-19 04:00
>> To: Jon Maloy ; Eric Dumazet
>> ; Chris Packham
>> ; ying@windriver.com;
>> da...@davemloft.net
>> Cc: net...@vger.kernel.o
tened to FDT")
Signed-off-by: Chris Packham
---
include/linux/of.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index e240992e5cb6..28797e1a9982 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1449,7 +144
der
and in many cases users can't do anything about this. The message
probably should have been pr_info() to inform the user that the kernel
has been helpful but rather than than let's remove it entirely to make
the kernel less noisy.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/
used in a similar way if it is deemed that timer1 should be kept for
some other purpose.
Chris Packham (2):
watchdog: orion: remove orion_wdt_set_timeout
watchdog: orion_wdt: use timer1 as a pretimeout
arch/arm/boot/dts/armada-38x.dtsi | 1 +
drivers/watchdog/orion_wdt.c | 66
rovide
the possibility of gathering debug before the reset triggers.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-38x.dtsi | 1 +
drivers/watchdog/orion_wdt.c | 58 ---
2 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/
The watchdog core will do the same thing if no set_timeout
is supplied so we can safely remove orion_wdt_set_timeout.
Signed-off-by: Chris Packham
---
drivers/watchdog/orion_wdt.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog
On 5/03/19 1:57 PM, Andrew Lunn wrote:
> On Tue, Mar 05, 2019 at 11:51:52AM +1300, 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 watchdog e
: Chris Packham
---
Changes in v2:
- new, split out from "watchdog: orion_wdt: use timer1 as a pretimeout"
arch/arm/boot/dts/armada-38x.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 929459c42760..fc
It appears that the kernel has only ever used timer0 on the armada platforms so
timer1 appears to be spare on these. Timers 2 and 3 are also free which could
be used if it is deemed that timer1 should be kept for some other purpose.
Chris Packham (3):
ARM: dts: armada-38x: add interrupts for
The watchdog core will do the same thing if no set_timeout
is supplied so we can safely remove orion_wdt_set_timeout.
Signed-off-by: Chris Packham
Reviewed-by: Guenter Roeck
---
Changes in v2:
- Add Guenter's review
drivers/watchdog/orion_wdt.c | 8
1 file changed, 8 dele
the
reset triggers.
Signed-off-by: Chris Packham
---
Changes in v2:
- apply changes to armada-38x only
- use watchdog_notify_pretimeout() as suggested by Andrew and Guenter
drivers/watchdog/orion_wdt.c | 59 ++--
1 file changed, 50 insertions(+), 9 deletions(-)
di
On 7/03/19 9:20 AM, Brodie Greenfield wrote:
> We want to be able to keep more spaces available in our queue for
> processing incoming IPv6 multicast traffic (adding (S,G) entries) - this
> lets us learn more groups faster, rather than dropping them at this stage.
>
> Signed-off-by: Brodie Greenfi
On 24/09/18 21:54, Olof Johansson wrote:
> On Fri, Sep 21, 2018 at 12:05:48PM +0200, Gregory CLEMENT wrote:
>> Hi Chris,
>>
>> On jeu., juil. 26 2018, Chris Packham
>> wrote:
>>
>>> We need to maintain backwards compatibility with device trees that
This board has a Micron MT29F8G08ABACAWP chip which requires a ECC
strength of 8/512. Rather than hard coding any particular strength the
the nand controller auto-detect the ECC strength based on the ONFI data.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-385-db-88f6820-amc.dts | 2
On 21/09/18 03:57, Gregory CLEMENT wrote:
> Hi Chris,
>
> On jeu., juil. 26 2018, Chris Packham
> wrote:
>
>> This series updates the armada-xp-98dx3236 SoC and related boards to use the
>> new style dts bindings for nand.
>>
>> I've also added a
The Armada 98dx3236 SoCs don't have a different MPP sel value for nand
specific pins so "dev" was technically correct. But all the other Armada
SoCs use "nand" in their dts and the pin is specific to the nand
interface so use "nand" for the function
Add pin control information for the NAND interface on the Armada
98DX3236 and variants.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
b/arch/arm/boot/dts
The "dev" function is selected with the value 0x4 not 0x01.
Fixes: commit d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
Signed-off-by: Chris Packham
---
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 20 ++--
1 file changed, 10 inserti
From: Kalyan Kinthada
This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
from Marvell.
Signed-off-by: Kalyan Kinthada
Signed-off-by: Chris Packham
---
Changes in v2:
- include sdio support for the 98DX4251
.../pinctrl/marvell,armada-98dx3236-pinctrl.txt| 46
The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
The clock gating options are a subset of those on the Armada XP.
The core clock divider is different to the Armada XP also.
Signed-off-by: Chris
package as the switch.
Chris Packham (4):
clk: mvebu: support for 98DX3236 SoC
arm: mvebu: support for SMP on 98DX3336 SoC
arm: mvebu: Add device tree for 98DX3236 SoCs
arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
Kalyan Kinthada (1):
pinctrl: mvebu: pinctrl driver for
evice tree if it is set in the machine definition.
Signed-off-by: Chris Packham
---
Changes in v2:
- Document new enable-method value
- Correct some references from 98DX4521 to 98DX3236
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
.../bindings/arm/marvell/98dx3236-resume-ctrl.txt
The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
with integrated CPUs. They are similar to the Armada XP SoCs but have
different I/O interfaces.
Signed-off-by: Chris Packham
---
Changes in v2:
- Update devicetree binding documentation to reflect that 98DX3336 and
984251
These boards are Marvell's evaluation boards for the 98DX4251 and
98DX3336 SoCs.
Signed-off-by: Chris Packham
---
Chaqnges in v2:
- None
arch/arm/boot/dts/db-dxbc2.dts | 159
arch/arm/boot/dts/db-xc3-24g4xg.dts
On 05/01/17 17:07, Florian Fainelli wrote:
> Le 01/04/17 à 19:36, Chris Packham a écrit :
>> The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
>> integrated CPUs. They CPU block is common within these product lines and
>> (as far as I can tell/have been
On 05/01/17 17:06, Florian Fainelli wrote:
> Le 01/04/17 à 19:36, Chris Packham a écrit :
>> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
>> with integrated CPUs. They are similar to the Armada XP SoCs but have
>> different I/O interfaces.
>&
On 05/01/17 17:04, Florian Fainelli wrote:
> Le 01/04/17 à 19:36, Chris Packham a écrit :
>> Compared to the armada-xp the 98DX3336 uses different registers to set
>> the boot address for the secondary CPU so a new enable-method is needed.
>> This will only work if the machi
On 06/01/17 02:10, Andrew Lunn wrote:
>> I'd love to see a switchdev driver but it's a huge task (and no I'm not
>> committing to writing it). As it stands Marvell ship a switch SDK
>> largely executes in userspace with a small kernel module providing some
>> linkage to the underlying hardware.
>
>
_98DX3236_PLUS),
+MPP_VAR_FUNCTION(0x2, "sd0", "d2", V_98DX4251),
MPP_VAR_FUNCTION(0x4, "dev", "ready0",
V_98DX3236_PLUS)),
MPP_MODE(10,
MPP_VAR_FUNCTION(0x0, "gpio", NULL,
V_98DX3236_PLUS),
+
On 06/01/17 02:59, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:40PM +1300, Chris Packham wrote:
>> +internal-regs {
>> +coreclk: mvebu-sar@18230 {
>> +compatible = "mar
On 05/01/17 17:46, Chris Packham wrote:
> On 05/01/17 17:04, Florian Fainelli wrote:
>> Le 01/04/17 à 19:36, Chris Packham a écrit :
>>> +}
>>> +
>>> +static int __init mv98dx3236_resume_init(void)
>>> +{
>>> + struct device_node
On 06/01/17 03:01, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:37PM +1300, Chris Packham wrote:
>> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
>> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>>
>> The
package as the switch.
Chris Packham (4):
clk: mvebu: support for 98DX3236 SoC
Changes in v2:
- Update devicetree binding documentation for new compatible string
Changes in v3:
- Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a
new driver.
- Document
The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
The clock gating options are a subset of those on the Armada XP.
The core clock divider is different to the Armada XP also.
Signed-off-by: Chris
These boards are Marvell's evaluation boards for the 98DX4251 and
98DX3336 SoCs.
Signed-off-by: Chris Packham
---
Change in v2/v3:
- None
arch/arm/boot/dts/db-dxbc2.dts | 159
arch/arm/boot/dts/db-xc3-24g4xg.dts
evice tree if it is set in the machine definition.
Signed-off-by: Chris Packham
---
Changes in v2:
- Document new enable-method value
- Correct some references from 98DX4521 to 98DX3236
Changes in v3:
- Simplify mv98dx3236_resume_init by using of_io_request_an
301 - 400 of 832 matches
Mail list logo
