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
ryone due to the
spamcop.net RBL domain having expired. Please don't resend until
this has been resolved. The problem has been reported to a
kernel.org admin (John Hawley) and others via IRC.
If you didn't get bounce messages from the attempt to send to
kernel.org email addresses, your email server is broken.
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_
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 Wed, Jan 20, 2021 at 08:06:01PM -0800, Richard Cochran wrote:
> The mvpp2 is an Ethernet driver, and it implements MAC style time
> stamping of PTP frames. It has no need of the expensive option to
> enable PHY time stamping. Remove the incorrect dependency.
>
> Signed-off-by: Richard
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+
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+ker...@armlinux.org.uk, should update the MAINTAINERS)
No. MAINTAINERS is correct.
> On 2021/1/15 13:46, Kefeng Wang wrote:
> > Use the same implementation of initrd
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.
On Wed, Jan 13, 2021 at 11:15:09AM -0800, Linus Torvalds wrote:
> On Wed, Jan 13, 2021 at 9:58 AM Masahiro Yamada wrote:
> >
> > Maybe, we can raise the minimal version to gcc 5.1
> > for all architectures.
>
> It was discussed, but the immediate reason for this thing really does
> seem to be
On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote:
> On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote:
> > On 13.01.2021 13:09, Heiner Kallweit wrote:
> >> On 13.01.2021 10:29, claudiu.bez...@microchip.com wrote:
> >>> It could enter in this mode based on request for standby
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 insertions(+)
>
> diff
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);
> +
> +
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:
> > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang wrote:
>
> > > > * nspire -- added in 2013, no notable changes
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
On Sun, Jan 10, 2021 at 07:21:13AM +0100, Willy Tarreau wrote:
> On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote:
> (... i486 ...)
> > As with the other older platforms, the main question to ask is:
> > Are there users that are better off running a future LTS kernel on this
> >
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:
> >
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015
May be obsoleted, but I still use this for my dove cubox with
additional patches.
> * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW
> have one
Yes,
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))
> > -
On Thu, Jan 07, 2021 at 06:19:23PM +0100, Andrew Lunn wrote:
> Did we loose the comment:
>
> /* Some modules (Nokia 3FE46541AA) lock up if byte 0x51 is read as a
> * single read. Switch back to reading 16 byte blocks ...
>
> That explains why 16 is used. Given how broken stuff is and the number
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?
On Wed, Jan 06, 2021 at 05:20:34PM +, Will Deacon wrote:
> I've managed to reproduce the corruption on my AMD Seattle board (8x A57).
> I haven't had a chance to dig deeper yet, but here's the recipe which works
> for me:
>
> 1. I'm using GCC 4.9.4 simply to try to get as close as I can to
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
On Wed, Jan 06, 2021 at 11:53:59AM +, Mark Rutland wrote:
> ... and are you using defconfig or something else?
Not sure I replied to this. I'm not using the defconfig, I've my own
.config
As I mentioned, Will has built a 5.10 kernel using Arnd's gcc 4.9.4
and hasn't been able to reproduce
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 ",
On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > Hi Pali
> >
> > I have to agree with Russell here. I would rather have no diagnostics
> > than untrustable diagnostics.
>
> Ok!
>
> So should we completely skip
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
On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> This change is really required for those Realtek chips. I thought that
> it is obvious that from *both* addresses 0x50 and 0x51 can be read only
> one byte at the same time. Reading 2 bytes (for be16 value) cannot be
> really done by
On Wed, Dec 30, 2020 at 04:47:54PM +0100, Pali Rohár wrote:
> 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 EEPROM.
>
> Such combination of bits is meaningless so assume that LOS signal is not
> implemented.
On Wed, Dec 30, 2020 at 04:47:53PM +0100, Pali Rohár wrote:
> Some GPON SFP modules (e.g. Ubiquiti U-Fiber Instant) have set SFF phys_id
> in their EEPROM. Kernel SFP subsystem currently does not allow to use
> modules detected as SFF.
>
> This change extends check for SFP modules so also those
On Wed, Dec 30, 2020 at 04:47:52PM +0100, Pali Rohár wrote:
> Workaround for GPON SFP modules based on VSOL V2801F brand was added in
> commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
> v2.0 workaround"). But it works only for ids explicitly added to the list.
> As there
On Wed, Dec 30, 2020 at 10:00:28AM +, Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
> > Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
> > 8:44 pm:
> > > On Tue, Dec 29, 2020 at 01
On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
> Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
> 8:44 pm:
> > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
> >> I think it should certainly be documented in terms of what guarantees
On Wed, Dec 30, 2020 at 04:28:05PM +0800, Zhen Lei wrote:
> The outercache of some Hisilicon SOCs support physical addresses wider
> than 32-bits. The unsigned long datatype is not sufficient for mapping
> physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE:
> use phys_addr_t
On Tue, Dec 29, 2020 at 04:00:59PM +, David Brazdil wrote:
> The KVM/arm64 PSCI relay assumes that SYSTEM_OFF and SYSTEM_RESET should
> not return, as dictated by the PSCI spec. However, there is firmware out
> there which breaks this assumption, leading to a hyp panic. Make KVM
> more robust
On Mon, Dec 28, 2020 at 08:00:00AM +0100, Arnd Bergmann wrote:
> Wouldn't this also be needed by an Armada XP that supports
> more than 4GB of RAM but has an outer cache?
While Armada XP has an outer cache, it requires no maintanence; the
only support the kernel has is for configuring it at boot
On Tue, Dec 29, 2020 at 02:30:56PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2020/12/26 20:13, Russell King - ARM Linux admin wrote:
> > On Fri, Dec 25, 2020 at 07:44:58PM +0800, Zhen Lei wrote:
> >> The outercache of some Hisilicon SOCs support physical addresses
On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
> I think it should certainly be documented in terms of what guarantees
> it provides to application, _not_ the kinds of instructions it may or
> may not induce the core to execute. And if existing API can't be
> re-documented
On Mon, Dec 28, 2020 at 11:44:33AM -0800, Andy Lutomirski wrote:
> On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> > > After chatting with rmk about this (bu
101 - 200 of 1139 matches
Mail list logo
