Jeff Garzik writes:
On Mon, 2 Oct 2000, Rasmus Andersen wrote:
On Sun, Oct 01, 2000 at 09:14:49PM -0700, Linus Torvalds wrote:
Last pre-kernel - I'll do the real test9 before I fly off to Germany on
Tuesday.
Linus
---
- pre8:
- initialize to zero - put
Jeff Garzik writes:
> On Mon, 2 Oct 2000, Rasmus Andersen wrote:
> > On Sun, Oct 01, 2000 at 09:14:49PM -0700, Linus Torvalds wrote:
> > >
> > > Last pre-kernel - I'll do the real test9 before I fly off to Germany on
> > > Tuesday.
> > >
> > > Linus
> > > ---
> > > - pre8:
> > >
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 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 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 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 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 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 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 Wed, Jan 06, 2021 at 11:53:59AM +, Mark Rutland wrote:
> On Tue, Jan 05, 2021 at 03:47:26PM +0000, 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 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 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 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:23:38PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 03:21:38PM +0000, 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 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 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 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 Thu, Jan 07, 2021 at 11:18:41AM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 10:32:23PM +0000, 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 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 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 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 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 +0000, Russell King - ARM Linux admin
> > wrote:
> > > > The gcc bugzilla mentions backports
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: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 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: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: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: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 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 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 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 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, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> On Wed, Aug 5, 2020 at 7:34 AM Russell King
> wrote:
> >
> > Is this something you're willing to merge directly please?
>
> Done.
>
> That said:
>
> > -K: phylink
> > +K:
> >
On Wed, Aug 05, 2020 at 11:54:25AM -0700, Joe Perches wrote:
> On Wed, 2020-08-05 at 19:22 +0100, Russell King - ARM Linux admin wrote:
> > On Wed, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> > > On Wed, Aug 5, 2020 at 7:34 AM Russell King
> > > wrote
On Wed, Aug 05, 2020 at 11:47:38AM -0700, Joe Perches wrote:
> On Wed, 2020-08-05 at 19:22 +0100, Russell King - ARM Linux admin wrote:
> > On Wed, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> > > On Wed, Aug 5, 2020 at 7:34 AM Russell King
> > > wrote
On Wed, Aug 05, 2020 at 03:09:34PM -0700, Joe Perches wrote:
> On Wed, 2020-08-05 at 23:02 +0100, Russell King - ARM Linux admin wrote:
> > On Wed, Aug 05, 2020 at 11:54:25AM -0700, Joe Perches wrote:
> > > On Wed, 2020-08-05 at 19:22 +0100, Russell King - ARM Linux admin wro
On Thu, Aug 06, 2020 at 01:05:55AM +0200, Norbert Lange wrote:
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 434a16982e34..1af01bfe6638 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -614,7 +614,11 @@
On Fri, Oct 02, 2020 at 08:14:07AM -0700, Florian Fainelli wrote:
> On 10/2/2020 4:05 AM, Grant Likely wrote:
> > On 30/09/2020 17:04, Calvin Johnson wrote:
> > > Extract phy_id from compatible string. This will be used by
> > > fwnode_mdiobus_register_phy() to create phy device using the
> > >
On Sat, Oct 03, 2020 at 07:21:41PM +0300, Codrin Ciubotariu wrote:
> Starting with
> commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
> GPIO bus recovery is supported by the I2C core, so we can remove the
> driver implementation and use that one instead.
>
> Signed-off-by: Codrin
On Sun, Oct 04, 2020 at 12:16:56PM +0300, Codrin Ciubotariu wrote:
> Starting with
> commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
> GPIO bus recovery is supported by the I2C core, so we can remove the
> driver implementation and use that one instead.
>
> Signed-off-by: Codrin
On Wed, Sep 30, 2020 at 06:34:40PM +0200, Andrew Lunn wrote:
> > @@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(device_phy_find_device);
> > */
> > struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
> > {
> > - return fwnode_find_reference(fwnode, "phy-handle", 0);
> > +
On Wed, Oct 14, 2020 at 04:39:47PM +0200, Lukasz Stelmach wrote:
> It was <2020-10-14 śro 14:32>, when Russell King - ARM Linux admin wrote:
> > In any case, the mii.c code does fill in the advertising mask even
> > when autoneg is disabled, because, rightly or wrongly, the
On Thu, Oct 15, 2020 at 09:53:29AM +0200, Linus Walleij wrote:
> On Thu, Oct 8, 2020 at 5:46 PM Arnd Bergmann wrote:
>
> > With Arm EBSA110 gone, nothing uses it any more, so the corresponding
> > code and the Kconfig option can be removed.
> >
> > Signed-off-by: Arnd Bergmann
>
> Very nice
On Thu, Oct 08, 2020 at 12:45:30PM +0530, Maninder Singh wrote:
> Observed Stack Overflow on 8KB kernel stack on ARM specially
> incase on network interrupts, which results in undeterministic behaviour.
> So there is need for per cpu dedicated IRQ stack for ARM.
>
> As ARm does not have extra
On Thu, Oct 08, 2020 at 05:45:58PM +0200, Arnd Bergmann wrote:
> The ebsa110 platform is the last thing that uses
> CONFIG_ARCH_USES_GETTIMEOFFSET, and Russell has previously said that he
> thinks the platform can be retired now.
>
> Removing it allows us clean up the timer code by throwing out
On Fri, Oct 09, 2020 at 03:59:57PM +0800, Xiaoming Ni wrote:
> Printing raw pointer values in backtraces has potential security
> implications and are of questionable value anyway.
>
> This patch follows x86 and arm64's lead and removes the "Exception stack:"
> dump from kernel backtraces:
>
On Fri, Oct 09, 2020 at 10:18:20AM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-10-09 09:08:50 [+0100], Russell King - ARM Linux admin wrote:
> > I am really not happy about this - it hurts at least my ability to
> > debug the kernel when people post oopses to the mailing list
On Mon, Oct 12, 2020 at 12:03:18PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-10-11 22:32:38 [+0100], Russell King - ARM Linux admin wrote:
> > I don't have a problem getting rid of the hex numbers in [< >]
> > although then I will need to convert the symbol back to
On Mon, Oct 12, 2020 at 04:57:24AM -0700, Bernard Zhao wrote:
> Functions armada_drm_crtc_atomic_flush &
> armada_drm_crtc_atomic_enable don`t use the second parameter.
> So we may get warning like :
> warning: unused parameter ‘***’ [-Wunused-parameter].
> This change is to fix the compile
On Thu, Sep 17, 2020 at 07:32:28PM +0200, Christoph Hellwig wrote:
> The DMA API removed support for not passing in a device a long time
> ago, so remove the NULL checks.
What happens with ISA devices?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps
On Thu, Sep 17, 2020 at 07:32:27PM +0200, Christoph Hellwig wrote:
> static int __init cats_pci_init(void)
> {
> - if (machine_is_cats())
> - pci_common_init(_pci);
> + if (!machine_is_cats())
> + return 0;
> + bus_register_notifier(_bus_type, _pci_dma_nb);
>
On Thu, Jul 30, 2020 at 09:00:36AM +, codrin.ciubota...@microchip.com wrote:
> On 27.07.2020 13:50, Russell King - ARM Linux admin wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Mon, Jul 2
On Mon, Aug 03, 2020 at 03:34:39PM +0200, Krzysztof Kozlowski wrote:
> On Wed, Jul 29, 2020 at 02:47:31PM +0100, Guillaume Tucker wrote:
> > The L220_AUX_CTRL_NS_LOCKDOWN flag is set during the L2C enable
> > sequence. There is no need to set it in the default register value,
> > this was done
Dear syzbot,
Please explain why you are spamming me with all these reports - four so
far. I don't understand why you think I should be doing anything with
these.
Thanks.
On Mon, Aug 03, 2020 at 08:05:21AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:
On Mon, Aug 03, 2020 at 10:21:04AM -0700, Eric Biggers wrote:
> On Mon, Aug 03, 2020 at 06:12:33PM +0100, Russell King - ARM Linux admin
> wrote:
> > Dear syzbot,
> >
> > Please explain why you are spamming me with all these reports - four so
> > far. I don't und
On Sun, Aug 23, 2020 at 09:10:25PM +0200, Christian Gmeiner wrote:
> Hi
>
> > I have formally tested the patch with 5.7.10 - and it doesn't resolve
> > the issue - sadly :(
> >
> > From my testing, the reads on
> > VIVS_HI_CHIP_PRODUCT_ID
> > VIVS_HI_CHIP_ECO_ID
> > need to be conditional - while
On Thu, Sep 10, 2020 at 08:31:54PM +0200, Andrew Lunn wrote:
> Generally the driver will default to the hardware reset blink
> pattern. There are a few PHY drivers which change this at probe, but
> not many. The silicon defaults are pretty good.
The "right" blink pattern can be a matter of how
On Thu, Sep 10, 2020 at 10:31:12PM +0200, Marek Behun wrote:
> On Thu, 10 Sep 2020 19:34:35 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Thu, Sep 10, 2020 at 08:31:54PM +0200, Andrew Lunn wrote:
> > > Generally the driver will default to the hardware r
On Thu, Sep 10, 2020 at 05:31:42PM -0700, Nathan Chancellor wrote:
> On Thu, Sep 10, 2020 at 03:28:11PM -0700, David Miller wrote:
> > From: Nathan Chancellor
> > Date: Thu, 10 Sep 2020 10:48:27 -0700
> >
> > > Clang warns (trimmed for brevity):
> > >
> > >
On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
> The DMA offset notifier can only be used if PHYS_OFFSET is at least
> KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
> phys_addr_t. Currently the code compiles fine despite that, a pending
> change to the DMA
On Fri, Sep 11, 2020 at 09:01:01AM -0700, Nathan Chancellor wrote:
> On Fri, Sep 11, 2020 at 08:22:36AM -0700, Jakub Kicinski wrote:
> > On Fri, 11 Sep 2020 12:11:58 +0100 Russell King - ARM Linux admin wrote:
> > > On Thu, Sep 10, 2020 at 05:31:42PM -0700, Nathan Chancellor
On Tue, Sep 15, 2020 at 09:16:15PM +0800, Zhen Lei wrote:
> Currently, only support the kernels where the base of physical memory is
> at a 16MiB boundary. Because the add/sub instructions only contains 8bits
> unrotated value. But we can use one more "add/sub" instructions to handle
> bits 23-16.
On Tue, Sep 15, 2020 at 09:16:13PM +0800, Zhen Lei wrote:
> v1 --> v2:
> Nothing changed, but add mail list: patc...@armlinux.org.uk
It isn't a mailing list, it's a bot, and it should only be copied
when you're ready to submit the patches, and only after they've been
reviewed. It queues the
On Wed, Sep 16, 2020 at 09:57:15AM +0800, Leizhen (ThunderTown) wrote:
> On 2020/9/16 3:01, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 15, 2020 at 09:16:15PM +0800, Zhen Lei wrote:
> >> Currently, only support the kernels where the base of physical memory is
> &
On Fri, Dec 11, 2020 at 03:41:47PM +0100, Marcin Wojtas wrote:
> Since its creation Marvell NIC driver for Armada 375/7k8k and
> CN913x SoC families mvpp2 has been lacking an entry in MAINTAINERS,
> which sometimes lead to unhandled bugs that persisted
> across several kernel releases.
Can you
On Sat, Dec 26, 2020 at 10:18:08AM +0800, Leizhen (ThunderTown) wrote:
> On 2020/12/25 19:44, 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
On Fri, Dec 25, 2020 at 07:44:58PM +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 Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote:
> On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers
> wrote:
> >
> > - On Dec 27, 2020, at 1:28 PM, Andy Lutomirski l...@kernel.org wrote:
> >
>
> > >
> > > I admit that I'm rather surprised that the code worked at all on
On Mon, Dec 28, 2020 at 09:14:23AM -0800, Andy Lutomirski wrote:
> On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote:
> > > On Sun, Dec 27, 2020 at 12:18 PM Mat
On Fri, Dec 18, 2020 at 01:48:09PM +, Guillaume Tucker wrote:
> Please see the bisection report below about a boot failure on
> ox820-cloudengines-pogoplug-series-3. There was also a bisection
> yesterday with next-20201216 which landed on the same commit, on
> the same platform and also with
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 Tue, Jan 05, 2021 at 10:27:28AM -0800, Darrick J. Wong wrote:
> On Tue, Jan 05, 2021 at 03:47:26PM +0000, Russell King - ARM Linux admin
> wrote:
> > Hi,
> >
> > This is an update on where I am with this long standing issue at the
> > current time.
> >
&
On Thu, Dec 17, 2020 at 12:00:49PM +0100, Marcin Wojtas wrote:
> Hi Stefan,
>
> czw., 17 gru 2020 o 10:42 napisał(a):
> >
> > From: Stefan Chulski
> >
> > Force link UP can be enabled by bootloader during tftpboot
> > and breaks NFS support.
> > Force link UP disabled during port init
On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> After chatting with rmk about this (but without claiming that any of
> this is his opinion), based on the manpage, I think membarrier()
> currently doesn't really claim to be synchronizing caches? It just
> serializes cores. So arguably
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
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 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 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 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 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 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 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 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 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: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 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 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 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 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: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 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 Fri, Oct 23, 2020 at 05:14:36PM +0800, Miles Chen wrote:
> From: Minchan Kim
>
> This patch introduces L_PTE_SPECIAL and pte functions for supporting
> get_user_pages_fast.
>
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Minchan Kim
> Cc: Suren
On Fri, Oct 23, 2020 at 05:14:37PM +0800, Miles Chen wrote:
> Since kernel no longer writes to the vector, try to replace
> the vector mem type with read-only type and remove L_PTE_MT_VECTORS.
>
> from Catalin in [1]:
> "
> > I don't think this matters since the kernel no longer writes to the
> >
On Fri, Oct 23, 2020 at 05:14:35PM +0800, Miles Chen wrote:
> From: Minchan Kim
>
> To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that.
> It seems we don't need 4 bits for the memory type with ARMv6+.
> If it's true, let's reorder bits to make bit 5 free.
>
> We will use the
On Fri, Oct 23, 2020 at 10:59:42AM +, Parshuram Raju Thombare wrote:
> Hi,
>
> I was trying to find out any ethernet driver where this issue of selecting
> appropriate
> pcs_ops due to phylink changing interface mode dynamically is handled.
> But, apparently, so far only mvpp2 has adapted
On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
> - The upcoming CAN SIC and CAN SIC XL PHYs use a different interface to
> the CAN controller. This means the controller needs to know which type
> of PHY is attached to configure the interface in the correct mode. Use
> PHY
On Fri, Oct 23, 2020 at 02:14:09PM +0200, Marc Kleine-Budde wrote:
> On 10/23/20 1:45 PM, Russell King - ARM Linux admin wrote:
> > On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
> >> - The upcoming CAN SIC and CAN SIC XL PHYs use a different interface to
> &g
On Fri, Oct 23, 2020 at 01:34:09PM +, Parshuram Raju Thombare wrote:
> >Whenever the interface changes, we go through the full reconfiguration
> >procedure that I've already outlined. This involves calling the
> >mac_prepare() method which calls into mvpp2_mac_prepare() and its
> >child
On Sat, Oct 24, 2020 at 07:17:05PM +0200, Andrew Lunn wrote:
> > - Every PHY driver gains a .handle_interrupt() implementation that, for
> > the most part, would look like below:
> >
> > irq_status = phy_read(phydev, INTR_STATUS);
> > if (irq_status < 0) {
> >
On Fri, Nov 13, 2020 at 03:43:27PM +, Guillaume Tucker wrote:
> On 13/11/2020 10:35, Ard Biesheuvel wrote:
> > On Fri, 13 Nov 2020 at 11:31, Guillaume Tucker
> > wrote:
> >>
> >> Hi Ard,
> >>
> >> Please see the bisection report below about a boot failure on
> >> RPi-2b.
> >>
> >> Reports
1 - 100 of 783 matches
Mail list logo
