On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > I'm glad to take this through my char/misc
On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> I'm glad to take this through my char/misc tree, as that's where the
> other coresight changes flow through. So if no one else objects, I will
> do so...
Greg, did you end up pulling this after all? If not, Uwe produced a v2.
On Thu, Feb 04, 2021 at 03:25:20PM +0100, Ard Biesheuvel wrote:
> Pushing contents of the cache hierarchy to main memory is *not* a
> valid use of set/way ops, and so there is no point in pretending that
> set/way ops will produce the same results as by-VA ops. Only the by-VA
> ops give the
On Thu, Feb 04, 2021 at 12:26:44PM +, Marc Zyngier wrote:
> I agree. With set/way CMOs, there is no way to reach the PoC if
> it beyond the system cache, leading to an unbootable kernel.
> This is actually pretty well documented in the architecture,
> and it did bite us for the first time on
On Thu, Feb 04, 2021 at 11:32:05AM +, Guillaume Tucker wrote:
> Yes it does fix the issue:
>
> https://lava.collabora.co.uk/scheduler/job/3173819
>
> with Ard's fix applied to this test branch:
>
> https://gitlab.collabora.com/gtucker/linux/-/commits/
On Thu, Feb 04, 2021 at 11:27:16AM +0100, Ard Biesheuvel wrote:
> Hi Russell,
>
> If Guillaume is willing to do the experiment, and it fixes the issue,
> it proves that rk3288 is relying on the flush before the MMU is
> disabled, and so in that case, the fix is trivial, and we can just
> apply
On Thu, Feb 04, 2021 at 10:07:58AM +0100, Ard Biesheuvel wrote:
> On Thu, 4 Feb 2021 at 09:43, Guillaume Tucker
> wrote:
> >
> > Hi Ard,
> >
> > Please see the bisection report below about a boot failure on
> > rk3288 with next-20210203. It was also bisected on
> > imx6q-var-dt6customboard with
On Wed, Feb 03, 2021 at 02:50:45PM +, Kostya Porotchkin wrote:
> [KP] So for older systems this "slow mode" parameter could be set on the
> board level.
> When it is set in ap80x,dtsi file it downgrades all systems to HS-SDR52, even
> if they support HS400 on AP side.
> MacchiatoBIN AP eMMC
On Wed, Feb 03, 2021 at 02:37:22PM +, Kostya Porotchkin wrote:
> Hi, Baruch,
>
> > -Original Message-
> > From: Baruch Siach
> > Sent: Wednesday, February 3, 2021 15:59
> > To: Kostya Porotchkin
> > Cc: linux-kernel@vger.kernel.org; devicet...@vg
On Wed, Feb 03, 2021 at 03:31:30PM +0200, kos...@marvell.com wrote:
> From: Konstantin Porotchkin
>
> Add SDIO mode pin control configration for CP0 on A8K DB.
>
> Signed-off-by: Konstantin Porotchkin
> ---
> arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 6 ++
>
On Wed, Feb 03, 2021 at 10:18:55AM +0100, Oleksij Rempel wrote:
> This fixup removes the Lpi_en bit.
>
> If this patch breaks functionality of your board, use following device
> tree properties:
>
> ethernet-phy@X {
> reg = <0xX>;
> eee-broken-1000t;
>
On Wed, Feb 03, 2021 at 10:18:50AM +0100, Oleksij Rempel wrote:
> This patch series tries to remove most of the imx6 and imx7 board
> specific PHY configuration via fixup, as this breaks the PHYs when
> connected to switch chips or USB Ethernet MACs.
>
> Each patch has the possibility to break
On Mon, Feb 01, 2021 at 10:22:51PM +0300, Ivan Bornyakov wrote:
> +/* PMD Transmit Disable */
> +#define MV_TX_DISABLE 0x0009
> +#define MV_TX_DISABLE_GLOBALBIT(0)
Please use MDIO_PMA_TXDIS and MDIO_PMD_TXDIS_GLOBAL; this is an
IEEE802.3 defined register.
> +/* 10GBASE-R
On Tue, Feb 02, 2021 at 07:47:04PM +0800, Ding Tianhong wrote:
> On 2021/2/2 19:13, Russell King - ARM Linux admin wrote:
> > On Tue, Feb 02, 2021 at 09:05:02PM +1000, Nicholas Piggin wrote:
> >> diff --git a/arch/arm/include/asm/pgtable.h
> >> b/arch/arm/inclu
On Tue, Feb 02, 2021 at 09:05:02PM +1000, Nicholas Piggin wrote:
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index c02f24400369..d63a5bb6bd0c 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -166,6 +166,9 @@ extern
On Tue, Jan 26, 2021 at 05:58:30PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
> Hello,
>
> Changes since v2 sent with Message-Id:
> 20201124133139.3072124-1-...@kleine-koenig.org:
>
> - Rebase to v5.11-rc1 (which resulted in a few conflicts in
>drivers/hwtracing).
> - Add
On Mon, Feb 01, 2021 at 08:07:37PM +, Giancarlo Ferrari wrote:
> Hi,
Hi,
> Why we should align 3 ? For the fncpy I suppose.
Slightly arbitary really - it gives a nice 8-byte alignment to the data.
.align 2 would also be sufficient.
> I don't know now how to proceed now, as you (Mark and
On Mon, Feb 01, 2021 at 04:32:40PM +, Mark Rutland wrote:
> I reckon here we need:
>
> __cpuc_flush_dcache_area(reboot_code_buffer,
>relocate_new_kernel_size + sizeof(*data));
>
> ... to make sure both the instructions and data are visible with the MMU
>
On Mon, Feb 01, 2021 at 01:57:14PM +, Mark Rutland wrote:
> We could simplify this slightly if we moved the kexec_& variables into a
> struct (using asm-offset KEXEC_VAR_* offsets and a KEXEC_VAR_SIZE region
> reserved in the asm), then here we could do something like:
>
> static struct
On Mon, Feb 01, 2021 at 12:47:20PM +, Mark Rutland wrote:
> 1. copy reloc code into buffer
> 2. alter variables in copy of reloc code
> 3. branch to buffer
>
> ... which would avoid this class of problem too.
Yep, slightly messy to do though:
diff --git a/arch/arm/kernel/machine_kexec.c
I wish others who know this code would get involved, and such stuff
wasn't left to me to research and work out whether a patch is correct
or not.
On Mon, Feb 01, 2021 at 12:44:56AM +, Giancarlo Ferrari wrote:
> machine_kexec() need to set rw permission in text and rodata sections
> to assign
On Sun, Jan 31, 2021 at 02:45:24PM +, Russell King - ARM Linux admin wrote:
> On Sun, Jan 31, 2021 at 02:23:20PM +, Stefan Chulski wrote:
> > I still don't see all patches in
> > https://patchwork.kernel.org/project/netdevbpf/list/?series=424949
> > I would redu
On Sun, Jan 31, 2021 at 02:23:20PM +, Stefan Chulski wrote:
> I still don't see all patches in
> https://patchwork.kernel.org/project/netdevbpf/list/?series=424949
> I would reduce patch series to 15 patches and repost again.
kernel.org email is currently broken for everyone due to the
On Fri, Jan 29, 2021 at 11:26:38AM +0100, Arnd Bergmann wrote:
> Another clarification, as there are actually two independent
> points here:
>
> * if you can completely remove the readl() above and just write a
> hardcoded value into the register, or perhaps read the original
> value once at
On Wed, Jan 27, 2021 at 01:43:16PM +0200, stef...@marvell.com wrote:
> Armada hardware has a pause generation mechanism in GOP (MAC).
> The GOP generate flow control frames based on an indication programmed in
> Ports Control 0 Register. There is a bit per port.
> However assertion of the PortX
On Wed, Jan 27, 2021 at 06:41:32PM +, Stefan Chulski wrote:
>
> >
> > > From: Stefan Chulski
> > >
> > > RXQ non occupied descriptor threshold would be used by Flow Control
> > > Firmware feature to move to the XOFF mode.
> > > RXQ non occupied threshold would change interrupt cause that
On Thu, Jan 28, 2021 at 01:00:57AM +0100, Andrew Lunn wrote:
> On Tue, Jan 26, 2021 at 01:49:38PM +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote:
> > > On Tue, Jan 26, 2021 at 08:33:37AM +0100,
On Wed, Jan 27, 2021 at 02:37:34PM +, Stefan Chulski wrote:
> Your mcbin-ss is A8K AX or A8K B0? On AX revisions we do not have FC support
> in firmware.
How do I tell? I don't want to remove the heatsink, and I don't see
anything in MV-S88-00E. I didn't grab a copy of the Errata before
On Wed, Jan 27, 2021 at 03:10:11PM +, Stefan Chulski wrote:
> You can devmem 0xF2400240(Device ID Status Register).
> #define A8040_B0_DEVICE_ID 0x8045
> #define A8040_AX_DEVICE_ID 0x8040
> #define A7040_B0_DEVICE_ID 0x7045
> #define A7040_AX_DEVICE_ID 0x7040
> #define
On Wed, Jan 27, 2021 at 01:43:35PM +0200, stef...@marvell.com wrote:
> if (priv->global_tx_fc && priv->hw_version != MVPP21) {
> - val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
> - val |= FLOW_CONTROL_ENABLE_BIT;
> - mvpp2_cm3_write(priv, MSS_FC_COM_REG,
On Tue, Jan 26, 2021 at 06:56:52PM +0100, Uwe Kleine-König wrote:
> I'm surprised to see that the remove callback introduced in 2952ecf5df33
> ("coresight: etm4x: Refactor probing routine") has an __exit annotation.
In general, remove callbacks should not have an __exit annotation.
__exit _can_
; Look for a phrase "TPM returned invalid status"
>
> We've had other reports of this:
>
> https://lore.kernel.org/linux-integrity/ghsgagsnag@gouders.net/
> https://lore.kernel.org/linux-integrity/374e918c-f167-9308-2bea-ae6bc6a3d2e3@elloe.vision/
>
> The problem i
On Mon, Jan 25, 2021 at 03:09:57PM +0100, Pali Rohár wrote:
> On Monday 18 January 2021 10:34:35 Pali Rohár wrote:
> > On Monday 11 January 2021 12:39:07 Pali Rohár wrote:
> > > This is a third version of patches which add workarounds for
> > > RTL8672/RTL9601C EEPROMs and Ubiquiti U-Fiber Instant
On Tue, Jan 26, 2021 at 11:01:50PM +0800, Lecopzer Chen wrote:
> > On 2021-01-26 10:59:32 [+], Russell King - ARM Linux admin wrote:
> > > On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote:
> > > > Hi all,
> > > >
> > > > I
On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote:
> On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote:
> > The mdio_bus reset code first de-asserted the reset by allocating with
> > GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if
> > the reset signal
On Tue, Jan 26, 2021 at 02:02:40PM +0100, Wolfram Sang wrote:
> Hi Russell,
>
> > Those who cause breakage really should be the ones to look at patches
> > that fix their breakage.
>
> Does it mean you want an explicit ack from Thomas or that it should go
> via his tree?
What I'm saying is...
On Tue, Jan 26, 2021 at 11:04:47AM +0100, Geert Uytterhoeven wrote:
> Hi Wolfram,
>
> On Mon, Dec 28, 2020 at 1:03 PM Wolfram Sang
> wrote:
> > Not used anymore after refactoring:
> >
> > arch/arm/kernel/smp.c: In function ‘show_ipi_list’:
> > arch/arm/kernel/smp.c:543:16: warning: variable
On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote:
> Hi all,
>
> I don't see any fix for this issue now(maybe I missed it..?),
> could we fix this if there is better solution?
> This issue exists almost two years.
I don't think anyone provided an acceptable patch.
The first patch
On Mon, Jan 25, 2021 at 03:23:01PM +0100, Pali Rohár wrote:
> On Monday 25 January 2021 14:16:44 Russell King - ARM Linux admin wrote:
> > On Mon, Jan 25, 2021 at 03:09:57PM +0100, Pali Rohár wrote:
> > > On Monday 18 January 2021 10:34:35 Pali Rohár wrote:
> > > > O
On Sun, Jan 24, 2021 at 01:43:53PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch add PPv23 version definition.
> PPv23 is new packet processor in CP115.
> Everything that supported by PPv22, also supported by PPv23.
> No functional changes in this stage.
>
>
On Sun, Jan 24, 2021 at 01:43:58PM +0200, stef...@marvell.com wrote:
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 9d69752..0f5069f 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++
On Sun, Jan 24, 2021 at 01:43:52PM +0200, stef...@marvell.com wrote:
> + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> + if (!priv->sram_pool) {
> + if (!defer_once) {
> + defer_once = true;
> +
On Sun, Jan 24, 2021 at 01:44:02PM +0200, stef...@marvell.com wrote:
> @@ -6407,6 +6490,29 @@ static void mvpp2_mac_link_up(struct phylink_config
> *config,
>val);
> }
>
> + if (tx_pause && port->priv->global_tx_fc) {
> + port->tx_fc = true;
> +
On Sun, Jan 24, 2021 at 01:43:52PM +0200, stef...@marvell.com wrote:
> +static int mvpp2_get_sram(struct platform_device *pdev,
> + struct mvpp2 *priv)
> +{
> + struct device_node *dn = pdev->dev.of_node;
> + static bool defer_once;
> + struct resource *res;
> +
>
On Sun, Jan 24, 2021 at 01:43:57PM +0200, stef...@marvell.com wrote:
> +/* Set Flow Control timer x140 faster than pause quanta to ensure that link
> + * partner won't send taffic if port in XOFF mode.
Can you explain more why 140 times faster is desirable here? Why 140
times and not, say, 10
On Fri, Jan 22, 2021 at 06:14:44PM -0800, Jakub Kicinski wrote:
> On Thu, 21 Jan 2021 07:08:02 -0800 Richard Cochran wrote:
> > On Thu, Jan 21, 2021 at 10:27:54AM +, Russell King - ARM Linux admin
> > wrote:
> > > On Wed, Jan 20, 2021 at 08:06:01PM -080
on NETWORK_PHY_TIMESTAMPING
> depends on (PTP_1588_CLOCK = y && MVPP2 = y) || \
> (PTP_1588_CLOCK && MVPP2 = m)
>
> --
> 2.20.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-a
On Mon, Jan 18, 2021 at 09:21:53PM +0530, Manivannan Sadhasivam wrote:
> @@ -27,10 +29,18 @@ UNWIND( .fnstart)
> UNWIND( .save {r4-r7})
> ldm r12, {r4-r7}
> \instr
> + mov r9, r6 // Copy r6 before popping from stack
> pop {r4-r7}
>
On Mon, Jan 18, 2021 at 09:01:40AM +0800, Kefeng Wang wrote:
>
> On 2021/1/17 18:09, Russell King - ARM Linux admin wrote:
> > On Sun, Jan 17, 2021 at 12:57:55PM +0800, Kefeng Wang wrote:
> > > Correct Russell's mail address (from li...@armlinux.org.uk to
> > > rmk+
rd.h
> >initramfs: Provide a common initrd reserve function
> >ARM: Covert to reserve_initrd_mem()
> >riscv: Covert to reserve_initrd_mem()
> >
> > arch/arm/mm/init.c | 43 +----
> > arch/riscv/mm/init.c | 5
On Wed, Jan 13, 2021 at 12:56:26PM +0100, Bjarni Jonasson wrote:
> Add support for 100Base-FX, 100Base-LX, 100Base-PX and 100Base-BX10 modules
> This is needed for Sparx-5 switch.
>
> Signed-off-by: Bjarni Jonasson
Reviewed-by: Russell King
Thanks!
--
RMK's Patch system:
On Wed, Jan 13, 2021 at 12:56:25PM +0100, Bjarni Jonasson wrote:
> Sparx-5 supports this mode and it is missing in the PHY core.
>
> Signed-off-by: Bjarni Jonasson
Reviewed-by: Russell King
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps
On Thu, Jan 14, 2021 at 10:12:13AM +, claudiu.bez...@microchip.com wrote:
> Up to this moment we treat this backup mode as S2R mode since the memory
> was kept in self-refresh mode. Each driver was saving/restoring in/from RAM
> the content of associated registers in the suspend/resume phase.
here was a similar bug on e.g. sparc, but they patched the kernel.
*digs through irc logs...*
https://patchwork.kernel.org/project/linux-crypto/patch/20170602.112854.571030442583332811.da...@davemloft.net/
https://marc.info/?l=linux-sparc=149636946609980=2
(and they even reference the arm
e based on request for standby or
> >>> suspend-to-mem:
> >>> echo mem > /sys/power/state
> >>> echo standby > /sys/power/state
This is a standard way to enter S2R - I've used it many times in the
past on platforms that support it.
> I'm not a Linux P
On Tue, Jan 12, 2021 at 03:33:34PM +0100, Bjarni Jonasson wrote:
> On Mon, 2021-01-11 at 14:18 +, Russell King - ARM Linux admin
> wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > On Mon, Jan 11, 20
On Sat, Jan 09, 2021 at 10:34:57PM +0100, Arnd Bergmann wrote:
> On Sat, Jan 9, 2021 at 6:43 PM Russell King - ARM Linux admin
> wrote:
> > On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> > > * dove -- added in 2009, obsoleted by mach-mvebu in 2015
> >
On Mon, Jan 11, 2021 at 02:06:56PM +0100, Bjarni Jonasson wrote:
> Sparx-5 supports this mode and it is missing in the PHY core.
>
> Signed-off-by: Bjarni Jonasson
Oh, I forgot - please can we have the new PHY mode documented in
Documentation/networking/phy.rst under the "PHY interface modes"
On Mon, Jan 11, 2021 at 02:06:57PM +0100, Bjarni Jonasson wrote:
> Add support for 100Base-FX, 100Base-LX, 100Base-PX and 100Base-BX10 modules
> This is needed for Sparx-5 switch.
>
> Signed-off-by: Bjarni Jonasson
> ---
> drivers/net/phy/sfp-bus.c | 9 +
> 1 file changed, 9
On Mon, Jan 11, 2021 at 02:06:56PM +0100, Bjarni Jonasson wrote:
> Sparx-5 supports this mode and it is missing in the PHY core.
>
> Signed-off-by: Bjarni Jonasson
Looks good, thanks.
Reviewed-by: Russell King
> ---
> include/linux/phy.h | 4
> 1 file changed, 4 inser
On Mon, Jan 11, 2021 at 02:06:55PM +0100, Bjarni Jonasson wrote:
> Adding support for 100 base-x in phylink.
> The Sparx5 switch supports 100 base-x pcs (IEEE 802.3 Clause 24) 4b5b encoded.
> These patches adds phylink support for that mode.
>
> Tested in Sparx5, using sfp modules:
> Axcen 100fx
On Mon, Jan 11, 2021 at 09:40:00PM +0800, DENG Qingfang wrote:
> On Mon, Jan 11, 2021 at 7:04 PM Russell King - ARM Linux admin
> wrote:
> >
> > FYI, Documentation/driver-api/gpio/consumer.rst says:
> >
> > For output GPIOs, the value provided becomes the initial
On Mon, Jan 11, 2021 at 01:32:57PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 11, 2021 at 1:33 AM Russell King - ARM Linux admin
> wrote:
> > On Sun, Jan 10, 2021 at 10:33:56PM +0100, Linus Walleij wrote:
> > > On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt wrote:
> > >
On Mon, Jan 11, 2021 at 01:44:28PM +0800, DENG Qingfang wrote:
> +static int
> +mt7530_gpio_direction_output(struct gpio_chip *gc, unsigned int offset, int
> value)
> +{
> + struct mt7530_priv *priv = gpiochip_get_data(gc);
> + u32 bit = mt7530_gpio_to_bit(offset);
> +
> +
added in 2013, no notable changes after 2015
> >
> > Most of the platform is just the DT sources and some small drivers around
> > it,
> > so it's actually fairly low maintenance. So far the migration away from
> > panel-simple in 2019
> > (https://lore.kernel
On Sun, Jan 10, 2021 at 06:55:11PM +, Stefan Chulski wrote:
> > > not connected to the GOP flow control generation mechanism.
> > > To solve this issue Armada has firmware running on CM3 CPU dedectated
> > > for Flow Control support. Firmware monitors Packet Processor resources
> > > and
On Sun, Jan 10, 2021 at 06:27:57PM +, Stefan Chulski wrote:
> > What also concerns me is whether flow control is supported in the existing
> > driver at all, given this patch set. If it isn't supported without the
> > firmware's
> > help, then we should _not_ be negotiating flow control with
On Sun, Jan 10, 2021 at 06:24:30PM +, Stefan Chulski wrote:
> > >
> > > +/* Routine calculate single queue shares address space */ static int
> > > +mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
> > > + /* If number of CPU's greater than number of threads, return last
> > > + *
On Sun, Jan 10, 2021 at 06:09:39PM +, Stefan Chulski wrote:
> > > > > + } else {
> > > > > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > > > + if (!priv->sram_pool) {
> > > > > + dev_warn(>dev, "DT is too old, TX FC
> > > >
Hi,
On Sun, Jan 10, 2021 at 05:30:04PM +0200, stef...@marvell.com wrote:
> Armada hardware has a pause generation mechanism in GOP (MAC).
> GOP has to generate flow control frames based on an indication
> programmed in Ports Control 0 Register. There is a bit per port.
> However assertion of the
On Sun, Jan 10, 2021 at 05:30:18PM +0200, stef...@marvell.com wrote:
> @@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct
> net_device *dev,
>struct ethtool_pauseparam *pause)
> {
> struct mvpp2_port *port = netdev_priv(dev);
> +
On Sun, Jan 10, 2021 at 05:30:16PM +0200, stef...@marvell.com wrote:
> + /* Enable global Flow Control only if hanler to SRAM not NULL */
I think this comment needs fixing. I'm not sure what a "hanler" is,
and "handler" doesn't make sense here.
--
RMK's Patch system:
On Sun, Jan 10, 2021 at 05:30:15PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch did not change any functionality.
> Added flow control RXQ and BM pool config callbacks that would be
> used to configure RXQ and BM pool thresholds.
> APIs also will disable/enable RXQ and
On Sun, Jan 10, 2021 at 05:30:07PM +0200, stef...@marvell.com wrote:
> + } else {
> + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> + if (!priv->sram_pool) {
> + dev_warn(>dev, "DT is too old, TX FC disabled\n");
I don't see anything in
machine that's able to boot an old installation just means
it can run, but it doesn't guarantee that it will be useful once
booted to move old data onto newer machines.
Over Christmas, I booted my Acorn A5000 (the very first machine to run
Linux on ARM) to retrieve some old data off it - thankful
On Sat, Jan 09, 2021 at 08:14:47PM +0100, Pali Rohár wrote:
> On Saturday 09 January 2021 15:46:01 Russell King - ARM Linux admin wrote:
> > On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> >
one
Yes, and still running:
Linux flint 5.6.12+ #94 Sat Oct 17 23:44:28 BST 2020 armv4l armv4l armv4l
GNU/Linux
> * iop32x -- added in 2006, no notable changes other than my cleanup, but
> I think there are still users
I have two TheCUS N2100s here, one still powered up and running and
o
On Sat, Jan 09, 2021 at 04:54:22PM +0100, Andrew Lunn wrote:
> On Sat, Jan 09, 2021 at 03:46:01PM +, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > From: Russell King
> >
> > Some GPON SFP modules (e.g. Ubiquiti U-Fiber Instant) have set both
> > SFP_OPTIONS_LOS_INVERTED and SFP_OPTIONS_LOS_NORMAL bits in their
On Fri, Jan 08, 2021 at 12:02:53PM -0800, Linus Torvalds wrote:
> Well, honestly, I'm always in favor of having people not use ancient
> compilers, but both of the issues at hand do seem to be specific to
> arm64.
>
> The "gcc before 5.1 generates incorrect stack pointer writes on arm64"
> sounds
On Thu, Jan 07, 2021 at 10:48:05PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 7, 2021 at 5:27 PM Theodore Ts'o wrote:
> >
> > On Thu, Jan 07, 2021 at 01:37:47PM +, Russell King - ARM Linux admin
> > wrote:
> > > > The gcc bugzilla mentions backports
On Thu, Jan 07, 2021 at 06:19:23PM +0100, Andrew Lunn wrote:
> > -static int sfp_quirk_i2c_block_size(const struct sfp_eeprom_base *base)
> > +static bool sfp_id_needs_byte_io(struct sfp *sfp, void *buf, size_t len)
> > {
> > - if (!memcmp(base->vendor_name, "VSOL", 16))
> > -
is and the number
> of workaround we need, we should try to document as much as we cam, so
> we don't break stuff when adding more workarounds.
It is _not_ why 16 is used at all.
We used to read the whole lot in one go. However, some modules could
not cope with a full read - also some Lin
On Thu, Jan 07, 2021 at 02:16:25PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 7, 2021 at 1:47 PM Russell King - ARM Linux admin
> wrote:
>
> > Arnd has found via bisecting gcc:
> >
> > 7e8c2bd54af ("[AArch64] fix unsafe access to deallocated stack")
> >
On Thu, Jan 07, 2021 at 11:18:41AM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 10:32:23PM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Jan 06, 2021 at 05:20:34PM +, Will Deacon wrote:
> > > With that, I see the following af
On Wed, Jan 06, 2021 at 10:32:23PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 05:20:34PM +, Will Deacon wrote:
> > With that, I see the following after ten seconds or so:
> >
> > EXT4-fs error (device sda2): ext4_lookup:1707: inode #674497: c
On Wed, Jan 06, 2021 at 05:20:34PM +, Will Deacon wrote:
> With that, I see the following after ten seconds or so:
>
> EXT4-fs error (device sda2): ext4_lookup:1707: inode #674497: comm md5sum:
> iget: checksum invalid
>
> Russell, Mark -- does this recipe explode reliably for you too?
close as I can to rmk's
>setup. I don't know if this is necessary or not, but the toolchain is
>here:
>
>
> https://kernel.org/pub/tools/crosstool/files/bin/arm64/4.9.4/arm64-gcc-4.9.4-nolibc-aarch64-linux-gnu.tar.xz
>
>and I needed to pull down an old libm
On Wed, Jan 06, 2021 at 03:23:38PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 03:21:38PM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Jan 06, 2021 at 03:55:32PM +0100, Pali Rohár wrote:
> > > On my teste
On Wed, Jan 06, 2021 at 03:21:38PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 03:55:32PM +0100, Pali Rohár wrote:
> > On my tested CarlitoxxPro module is:
> >
> > Option values : 0x00 0x
On Wed, Jan 06, 2021 at 03:55:32PM +0100, Pali Rohár wrote:
> On my tested CarlitoxxPro module is:
>
> Option values : 0x00 0x1c
> Option: RX_LOS implemented,
> inverted
> Option
ast!
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 5.9.0 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (GCC) 4.9.4"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40904
CONFIG_LD_VERSION=23101
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONF
On Wed, Jan 06, 2021 at 11:53:59AM +, Mark Rutland wrote:
> On Tue, Jan 05, 2021 at 03:47:26PM +, Russell King - ARM Linux admin
> wrote:
> > Hi,
>
> Hi Russell,
>
> > This is an update on where I am with this long standing issue at the
> > current time
On Tue, Jan 05, 2021 at 10:27:28AM -0800, Darrick J. Wong wrote:
> On Tue, Jan 05, 2021 at 03:47:26PM +, Russell King - ARM Linux admin
> wrote:
> > Hi,
> >
> > This is an update on where I am with this long standing issue at the
> > current time.
> >
&
Hi,
This is an update on where I am with this long standing issue at the
current time.
Since 5.4, I have been struggling with several of my ARM64 systems, of
different SoC vendors and differing filesystem media, were sporadically
reporting inode checksum failures on their root filesystems. The
On Wed, Dec 30, 2020 at 08:30:52PM +0100, Andrew Lunn wrote:
> > Ok!
> >
> > So should we completely skip hwmon_device_register_with_info() call
> > if (i2c_block_size < 2) ?
>
> Yep. That would be a nice simple test.
>
> But does ethtool -m still export the second page? That is also
>
On Wed, Dec 30, 2020 at 06:31:52PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 17:05:46 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> > > This change is really required for those Realte
On Wed, Dec 30, 2020 at 06:27:07PM +0100, Marek Behún wrote:
> On Wed, 30 Dec 2020 18:06:52 +0100
> Pali Rohár wrote:
>
> > if (!sfp->type->module_supported() &&
> > (memcmp(id.base.vendor_name, "UBNT", 16) ||
> > memcmp(id.base.vendor_pn, "UF-INSTANT ",
not care about 3rd parties.
Which shows why it's pointless producing an EEPROM validation tool that
runs under Linux (as has been your suggestion). They won't use it,
since their testing only goes as far as "does it work in our product?"
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Dec 30, 2020 at 05:57:58PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 16:13:10 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 04:47:54PM +0100, Pali Rohár wrote:
> > > Some GPON SFP modules (e.g. Ubiquiti U-Fiber Inst
101 - 200 of 10001 matches
Mail list logo
