Hello:
This series was applied to riscv/linux.git (fixes)
by Palmer Dabbelt :
On Thu, 30 Nov 2023 13:15:27 +0100 you wrote:
> From: Björn Töpel
>
> NB! Song told me that he would not have the time work on this series,
> so I picked it up.
>
> This series includes a three ftrace improvements
Hello:
This series was applied to riscv/linux.git (fixes)
by Masahiro Yamada :
On Sat, 14 Oct 2023 19:54:35 +0900 you wrote:
> Currently, there is no standard implementation for vdso_install,
> leading to various issues:
>
> 1. Code duplication
>
> Many architectures duplicate similar
Hello:
This patch was applied to riscv/linux.git (fixes)
by Palmer Dabbelt :
On Tue, 3 Oct 2023 20:24:07 +0200 you wrote:
> ftrace creates entries for each syscall in the tracefs but has failed
> since commit 08d0ce30e0e4 ("riscv: Implement syscall wrappers") which
> prefixes all riscv syscalls
Hello:
This patch was applied to riscv/linux.git (fixes)
by Palmer Dabbelt :
On Tue, 12 Sep 2023 08:56:19 +0200 you wrote:
> From: Björn Töpel
>
> RISC-V software breakpoint trap handlers are used for {k,u}probes.
>
> When trapping from kernelmode, only the kernelmode handlers should be
>
Hi Andrew,
On Tue, Apr 13, 2021 at 03:12:05PM +0200, Andrew Lunn wrote:
> Is there something like this in the marvell10 driver?
No, it doesn't seem to be necessary there - I haven't seen spontaneous
link-ups with the 88x3310 there. Even if we did, that would cause other
issues beyond a nusience
On Tue, Apr 13, 2021 at 11:59:20AM +0800, DENG Qingfang wrote:
> Within 12 hours, I got some spontaneous link down/ups when EEE is enabled:
>
> [16334.236233] mt7530 mdio-bus:1f wan: Link is Down
> [16334.241340] br-lan: port 3(wan) entered disabled state
> [16337.355988] mt7530 mdio-bus:1f wan:
On Tue, Apr 13, 2021 at 12:00:45PM +0200, Lucas Stach wrote:
> I agree with the opinion that those PHY fixups introduce more harm than
> good. Essentially they are pushing board specific configuration values
> into the PHY, without any checks that the fixup is even running on the
> specific board
On Tue, Apr 13, 2021 at 10:19:30AM +0300, Ivan Bornyakov wrote:
> On Tue, Apr 13, 2021 at 01:40:32AM +0200, Andrew Lunn wrote:
> > On Mon, Apr 12, 2021 at 03:16:59PM +0300, Ivan Bornyakov wrote:
> > > Some SFP modules uses RX_LOS for link indication. In such cases link
> > > will be always up,
On Tue, Apr 13, 2021 at 11:45:31AM +0300, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> Add parser entries for different IPv4 IHL values.
> Each entry will set the L4 header offset according to the IPv4 IHL field.
> L3 header offset will set during the parsing of the IPv4 protocol.
What
On Mo, 2021-04-12 at 13:54 +0300, Andy Shevchenko wrote:
> CAUTION: External Email!!
>
>
> On Mon, Apr 12, 2021 at 1:39 PM linux-kernel-dev
> wrote:
> > On Mo, 2021-04-12 at 12:43 +0300, Andy Shevchenko wrote:
> > > On Mon, Apr 12, 2021 at 12:29 PM S
On Mo, 2021-04-12 at 12:43 +0300, Andy Shevchenko wrote:
>
> On Mon, Apr 12, 2021 at 12:29 PM Steffen Dirkwinkel
> wrote:
> >
> > From: Steffen Dirkwinkel
> >
> > pmc_plt_clk* clocks are used for ethernet controllers so need to stay
> > turned on. This adds the affected board family to
On Fri, Apr 09, 2021 at 09:41:06PM +0300, Radu Pirea (NXP OSS) wrote:
> +#define B100T1_PMAPMD_CTL0x0834
> +#define B100T1_PMAPMD_CONFIG_EN BIT(15)
> +#define B100T1_PMAPMD_MASTER BIT(14)
> +#define MASTER_MODE (B100T1_PMAPMD_CONFIG_EN |
>
On Sat, Apr 10, 2021 at 03:06:52PM +0100, Matthew Wilcox wrote:
> How about moving the flags into the union? A bit messy, but we don't
> have to play games with __packed__.
Yes, that is probably the better solution, avoiding the games to try
and get the union appropriately placed on 32-bit
On Wed, Apr 07, 2021 at 02:44:39PM +0200, Andrew Lunn wrote:
> > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> > multi-gige PHY can do rate adaption right?
>
> The Marvell/Marvell multi-gige PHY can also do rate
> adaptation. Marvell buying Aquantia made naming messy :-(
>
On Wed, Apr 07, 2021 at 10:07:29AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 07, 2021 at 09:02:29AM +0100, Russell King - ARM Linux admin
> wrote:
> > On Wed, Apr 07, 2021 at 09:46:18AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Apr 07, 2021 at 09:18:11AM +0200, Gee
On Wed, Apr 07, 2021 at 09:46:18AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 07, 2021 at 09:18:11AM +0200, Geert Uytterhoeven wrote:
> > Hi Greg,
> >
> > Thanks for your series!
> >
> > On Wed, Apr 7, 2021 at 7:34 AM Greg Kroah-Hartman
> > wrote:
> > > Almost every architecture has copied
On Mon, Apr 05, 2021 at 08:58:07PM +0200, Danilo Krummrich wrote:
> On Mon, Apr 05, 2021 at 03:33:55PM +0200, Andrew Lunn wrote:
> However, this was about something else - Russell wrote:
> > > > We have established that MDIO drivers need to reject accesses for
> > > > reads/writes that they do not
On Fri, Apr 02, 2021 at 03:10:49AM +0200, Danilo Krummrich wrote:
> On Thu, Apr 01, 2021 at 09:48:58AM +0100, Russell King - ARM Linux admin
> wrote:
> > Do you actually have a requirement for this?
> >
> Yes, the Marvell 88Q2112 1000Base-T1 PHY. But actually, I just recogniz
On Thu, Apr 01, 2021 at 11:01:51PM +0800, Michael Sit Wei Hong wrote:
> + /* 2.5G mode only support 2500baseT full duplex only */
> + if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> + phylink_set(mac_supported, 2500baseT_Full);
> + phylink_set(mask,
On Thu, Apr 01, 2021 at 03:23:05AM +0200, danilokrummr...@dk-develop.de wrote:
> On 2021-03-31 20:35, Russell King - ARM Linux admin wrote:
> > On Wed, Mar 31, 2021 at 07:58:33PM +0200, danilokrummr...@dk-develop.de
> > wrote:
> > > For this cited change
On Wed, Mar 31, 2021 at 07:58:33PM +0200, danilokrummr...@dk-develop.de wrote:
> For this cited change the only thing happening is that if get_phy_device()
> already failed for probing with is_c45==false (C22 devices) it tries to
> probe with is_c45==true (C45 devices) which then either results
On Wed, Mar 17, 2021 at 09:52:10AM +0800, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen
> Signed-off-by: Kefeng Wang
Acked-by: Russell King # for
Why do you have 9016/2 in the subject line? That's an identifier from
the patch system which shouldn't be in the subject line.
If you want to refer to something already committed, please do so via
the sha1 git hash and quote the first line of the commit description
within ("...") in the body of
On Thu, Mar 25, 2021 at 09:32:35PM +0800, Liu Xiang wrote:
> Russell King - ARM Linux admin 于2021年3月25日周四 下午6:06写道：
> >
> > On Thu, Mar 25, 2021 at 05:50:49PM +0800, Liu Xiang wrote:
> > > When CONFIG_HARDEN_BRANCH_PREDICTOR is selected and user aborts occur,
On Fri, Mar 05, 2021 at 11:53:39PM +0900, Masahiro Yamada wrote:
> On Fri, Mar 5, 2021 at 7:04 PM Linus Walleij wrote:
> >
> > On Mon, Mar 1, 2021 at 3:29 PM Masahiro Yamada wrote:
> >
> > > Many architectures duplicate similar shell scripts.
> > >
> > > This commit converts ARM to use
On Thu, Mar 25, 2021 at 05:50:49PM +0800, Liu Xiang wrote:
> When CONFIG_HARDEN_BRANCH_PREDICTOR is selected and user aborts occur,
> there is a warning:
>
> BUG: using smp_processor_id() in preemptible [] code: errnotest/577
> caller is __do_user_fault.constprop.4+0x24/0x88
> CPU: 1 PID:
On Thu, Mar 25, 2021 at 04:38:06PM +0800, Michael Sit Wei Hong wrote:
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 12a047d47dec..c95dfe4e5310 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -290,6 +290,8 @@ static int
On Mon, Mar 22, 2021 at 06:10:01PM +0100, Cye Borg wrote:
> PWS 500au:
>
> snow / # lspci -vvx -s 7.1
> 00:07.1 IDE interface: Contaq Microsystems 82c693 (prog-if 80 [ISA
> Compatibility mode-only controller, supports bus mastering])
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV-
On Mon, Mar 22, 2021 at 04:33:14PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote:
> > On Mon, Mar 22, 2021 at 03:15:03PM +, Russell King - ARM Linux admin
> > wrote:
> > > It gets worse than that though - d
On Tue, Mar 23, 2021 at 02:20:23PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Passing an 8-bit constant into delay() triggers a warning when building
> with 'make W=1' using clang:
>
> drivers/clk/actions/owl-pll.c:182:2: error: result of comparison of constant
> 2000 with
On Tue, Mar 23, 2021 at 02:14:13PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Dereferencing a zero-length array is always a bug, and we get a warning
> with 'make W=1' here:
>
> arch/arm/mm/dma-mapping.c: In function 'dma_contiguous_early_fixup':
> arch/arm/mm/dma-mapping.c:395:15:
On Mon, Mar 22, 2021 at 05:09:13PM +0100, John Paul Adrian Glaubitz wrote:
> On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote:
> > I'm quite surprised that the CY82C693 even works on Alpha - I've
> > asked for a lspci for that last week but nothing has yet been
> > for
On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 03:15:03PM +, Russell King - ARM Linux admin
> wrote:
> > It gets worse than that though - due to a change to remove
> > pcibios_min_io from the generic code, moving it into the AR
On Mon, Mar 22, 2021 at 03:54:03PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 19, 2021 at 05:53:12PM +, Russell King - ARM Linux admin
> wrote:
> > If I extend the arch/arm/kernel/bios32.c code to kill BARs 2/3 (which
> > actually are not present on the CY82C693) then th
On Fri, Mar 19, 2021 at 05:07:53PM +, Russell King - ARM Linux admin wrote:
> On Thu, Mar 18, 2021 at 05:56:58AM +0100, Christoph Hellwig wrote:
> > footbridge_defconfig enables CONFIG_IDE but no actual host controller
> > driver, so just drop it.
>
> I have been using t
On Thu, Mar 18, 2021 at 05:56:58AM +0100, Christoph Hellwig wrote:
> footbridge_defconfig enables CONFIG_IDE but no actual host controller
> driver, so just drop it.
I have been using the Cypress 82C693 IDE driver on Footbridge for a
CD ROM drive, and I know it doesn't work with the PATA driver -
On Fri, Mar 19, 2021 at 10:54:48AM +0100, Dmitry Vyukov wrote:
> .On Fri, Mar 19, 2021 at 10:44 AM syzbot
> wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit:8b12a62a Merge tag 'drm-fixes-2021-03-19' of git://anongit..
> > git tree: upstream
> > console output:
On Fri, Mar 19, 2021 at 08:40:45AM +0100, Heiner Kallweit wrote:
> Is there a specific reason why c22 is probed first? Reversing the order
> would solve the issue we speak about here.
> c45-probing of c22-only PHY's shouldn't return false positives
> (at least at a first glance).
That would
red an ABI breakage,
> unless we filter out what we report to user-space via SIOGCMIIREG and
> /sys/class/mdio_bus/*/*/phy_id
>
> Ideally we would have assigned an unique PHY OUI to the fixed PHY but
> that would have required registering Linux as a vendor, and the process
>
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov wrote:
> > On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann wrote:
> > > > On Tue, Mar 16, 2021 at 8:18 AM syzbot
> >
> > > > > [<8073772c>] (integrity_kernel_read) from [<8073a904>]
>
On Tue, Mar 16, 2021 at 03:28:51PM +, Stefan Chulski wrote:
> No XDP doesn't require this. One of the use cases of the port reservation
> feature is the Marvell User Space SDK (MUSDK) which its latest code is
> publicly available here:
>
On Tue, Mar 16, 2021 at 08:59:17AM +0100, Dmitry Vyukov wrote:
> On Tue, Mar 16, 2021 at 8:18 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:1e28eed1 Linux 5.12-rc3
> > gi
> During port reservation all common configurations are preserved and
> only RXQ, TXQ, and interrupt vectors are disabled.
If a port is reserved for use by the CM3, what are the implications
for Linux running on the AP? Should Linux have knowledge of the port?
What configurations of the por
itmem is static
> memory. I'm using linux 5.4, as that is what is used in the next OpenWrt
> version.
>
> [ 92.198989] WARNING: CPU: 0 PID: 2015 at kernel/locking/lockdep.c:1119
> alloc_netdev_mqs+0xb4/0x3b0
>
> I guess CONFIG_PREEMT just changes the timing of alloca
On Sun, Mar 07, 2021 at 02:29:07PM +, Paul Cercueil wrote:
> Hi,
>
> Le dim. 7 mars 2021 à 14:27, Russell King - ARM Linux admin
> a écrit :
> > On Sun, Mar 07, 2021 at 02:06:26PM +, Paul Cercueil wrote:
> > > On error, or when the passed paramete
On Sun, Mar 07, 2021 at 02:06:26PM +, Paul Cercueil wrote:
> On error, or when the passed parameter is NULL, the return value is NULL
> and not a PTR_ERR()-encoded value.
No, the documentation is accurate. The CCF is just an implementation
of the API, the file you are modifying is the
On Wed, Mar 03, 2021 at 08:08:44PM -0800, Saravana Kannan wrote:
> Marek,
>
> I tested it and saw the device get added before the resources were
> available and the uevent file looked okay. Would you mind testing it
> further?
To put it bluntly, if you have tested this, the testing was not very
On Wed, Mar 03, 2021 at 09:53:38AM -0800, Paul E. McKenney wrote:
> drivers/net: #ifdef mdio_bus_phy_suspend() and mdio_bus_phy_suspend()
>
> The following build error is emitted by rcutorture builds of v5.12-rc1:
>
> drivers/net/phy/phy_device.c:293:12: warning: ‘mdio_bus_phy_resume’ defined
>
Hi,
Mostly great, but just a couple more points.
On Wed, Mar 03, 2021 at 01:57:57PM +0300, Ivan Bornyakov wrote:
> + adv = 0;
> +
> + if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT,
> + priv->supported))
> + adv |= ADVERTISE_1000XFULL;
>
On Tue, Mar 02, 2021 at 11:17:21PM -0800, menglong8.d...@gmail.com wrote:
> From: Zhang Yunkai
>
> 'linux/tty.h' included in 'arch/arm/mach-sa1100/hackkit.c' is duplicated.
>
> Signed-off-by: Zhang Yunkai
I don't see this change has anything to do with module code, so wha
On Tue, Mar 02, 2021 at 06:04:22PM -0800, menglong8.d...@gmail.com wrote:
> From: Zhang Yunkai
>
> 'asm-generic/pgtable-nopud.h' included in 'pgtable.h' is duplicated.
>
> Signed-off-by: Zhang Yunkai
I don't see this change has anything to do with module code, so what is
the reason for
On Sun, Feb 28, 2021 at 07:59:16PM +0300, Alexey Dobriyan wrote:
> From 72842f89ae91a4d02ea29604f87c373052bd3f64 Mon Sep 17 00:00:00 2001
> From: Alexey Dobriyan
> Date: Tue, 9 Feb 2021 14:37:40 +0300
> Subject: [PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types
>
> Generate
On Wed, Feb 24, 2021 at 06:07:34PM +0530, Maninder Singh wrote:
> +bool slab_page_object(unsigned long address, void **object, struct
> kmem_cache **cache)
> +{
> + void *addr = (void *)address;
> + struct page *page;
> +
> + if ((addr >= (void *)PAGE_OFFSET) &&
> +
On Wed, Feb 24, 2021 at 07:14:54PM +0800, liang wang wrote:
> Hi Russell,
>
> On Wed, 24 Feb 2021 at 18:39, Russell King - ARM Linux admin
> wrote:
> >
> > On Wed, Feb 24, 2021 at 06:35:47PM +0800, liang wang wrote:
> > > Hi,all
> > >
> > > ftr
On Wed, Feb 24, 2021 at 06:35:47PM +0800, liang wang wrote:
> Hi,all
>
> ftrace function_graph tracer always cause kernel panic on my ARM device with
> multiple CPUs, I found a solution for the problem on ARM64, refers to
> the patch above,
> I was wondering why this bugfix on ARM64 hasn't been
On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 269967c4fc1b..146b75a79d9e 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -121,6 +121,16 @@ choice
>
> endchoice
>
>
On Sat, Feb 20, 2021 at 10:47:48AM -0800, Randy Dunlap wrote:
> ---
> KernelVersion: v5.11
> I don't know what format is used for KernelVersion.
> This patch applies to any Linux kernel v5.x and probably even older.
I normally ask for it to be the kernel version (without git) th
| 1 +
> drivers/net/phy/marvell-88x2222.c | 510 ++
> include/linux/marvell_phy.h | 1 +
> 4 files changed, 518 insertions(+)
> create mode 100644 drivers/net/phy/marvell-88x.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 698bea312adc..
On Thu, Feb 18, 2021 at 05:19:54PM +, Jari Ruusu wrote:
> In-tree iwlwifi worked half-ok on early 4.9.y stable. If
> connection somehow de-autheticated (out of radio range or
> whatever) it crashed the kernel spectacularly. Eventually that was
> fixed and in-tree iwlwifi worked fine on 4.9.y
On Wed, Feb 17, 2021 at 09:56:08PM -0800, Randy Dunlap wrote:
> On 2/17/21 9:26 PM, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: f40ddce88593482919761f74910f42
On Thu, Feb 11, 2021 at 05:13:19PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> The condition should be skipped if CPU ID equal to nthreads.
> The patch doesn't fix any actual issue since
> nthreads = min_t(unsigned int, num_present_cpus(), MVPP2_MAX_THREADS).
> On all current
On Thu, Feb 11, 2021 at 01:57:25PM +, Kostya Porotchkin wrote:
>
> > --
> > On Wed, Feb 10, 2021 at 04:09:38PM +0200, kos...@marvell.com wrote:
> > > From: Konstantin Porotchkin
> > >
> > > Replace wrong regulator in AP0
On Thu, Feb 11, 2021 at 01:22:35PM +, Stefan Chulski wrote:
> > Ditto.
> >
> > I don't think these need to be fixed in the net tree, but it would still be
> > nice
> > to fix the problem. Please do so, as an initial patch in your series - so
> > we can
> > then backport if it turns out to
On Thu, Feb 11, 2021 at 01:02:14PM +, Stefan Chulski wrote:
> > On Thu, Feb 11, 2021 at 12:48:55PM +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 761f745..8b4073c 100644
>
On Thu, Feb 11, 2021 at 12:49:01PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch fix GMAC TX flow control autoneg.
> Flow control autoneg wrongly were disabled with enabled TX
> flow control.
>
> Signed-off-by: Stefan Chulski
> Acked-by: Marcin Wojtas
Should this
On Thu, Feb 11, 2021 at 12:49:00PM +0200, stef...@marvell.com wrote:
> +/* Configure Rx FIFO Flow control thresholds */
> +void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en)
> +{
> + int val;
u32 ?
> +
> + val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
> +
> +
On Thu, Feb 11, 2021 at 12:48:56PM +0200, stef...@marvell.com wrote:
> +static void mvpp2_cm3_write(struct mvpp2 *priv, u32 offset, u32 data)
> +{
> + writel(data, priv->cm3_base + offset);
> +}
> +
> +static u32 mvpp2_cm3_read(struct mvpp2 *priv, u32 offset)
> +{
> + return
On Thu, Feb 11, 2021 at 12:48:54PM +0200, stef...@marvell.com wrote:
> @@ -751,6 +760,10 @@
> #define MVPP2_TX_FIFO_THRESHOLD(kb) \
> ((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
>
> +/* MSS Flow control */
> +#define FC_QUANTA0x
> +#define FC_CLK_DIVIDER
On Thu, Feb 11, 2021 at 12:48:55PM +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 761f745..8b4073c 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++
On Thu, Feb 11, 2021 at 12:48:52PM +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 Thu, Feb 11, 2021 at 12:48:53PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> BM pool and RXQ size increased to support Firmware Flow Control.
> Minimum depletion thresholds to support FC are 1024 buffers.
> BM pool size increased to 2048 to have some 1024 buffers
> space
On Thu, Feb 11, 2021 at 12:48:51PM +0200, stef...@marvell.com wrote:
> @@ -1199,7 +1199,7 @@ static bool mvpp2_port_supports_xlg(struct mvpp2_port
> *port)
>
> static bool mvpp2_port_supports_rgmii(struct mvpp2_port *port)
> {
> - return !(port->priv->hw_version == MVPP22 && port->gop_id
On Thu, Feb 11, 2021 at 12:48:50PM +0200, stef...@marvell.com wrote:
> +static int mvpp2_get_sram(struct platform_device *pdev,
> + struct mvpp2 *priv)
> +{
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (!res) {
> +
On Thu, Feb 11, 2021 at 12:48:48PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> Patch adds CM3 address space and PPv2.3 description.
>
> Signed-off-by: Stefan Chulski
> Acked-by: Marcin Wojtas
It seems this is missing the ack that you got from Rob in your previous
posting.
On Wed, Feb 10, 2021 at 04:09:38PM +0200, kos...@marvell.com wrote:
> From: Konstantin Porotchkin
>
> Replace wrong regulator in AP0 eMMC definition on MacchiatoBIN
> board with 3.3V regulator.
> The MacchiatoBIN board has no 1.8V regulator connected to AP0
> eMMC (ap0_sdhci0) interface.
There
On Wed, Feb 10, 2021 at 04:09:39PM +0200, kos...@marvell.com wrote:
> From: Konstantin Porotchkin
>
> Select the AP SDHCI PHY slow mode for AP806 die only (move it
> from armada-ap80x.dtsi to armada-ap806.dtsi). This will allow
> running AP807 based devices at HS400 speed.
> Remove Ap SDHCI slow
On Wed, Feb 10, 2021 at 07:47:20PM +0300, Serge Semin wrote:
> On Tue, Feb 09, 2021 at 10:56:46AM +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > > Right, adding something like a genphy_{read,writ
On Wed, Feb 10, 2021 at 12:20:02PM +0100, Michael Walle wrote:
>
> Am 2021-02-09 17:38, schrieb Michael Walle:
> > --- a/drivers/net/phy/phy.c
> > +++ b/drivers/net/phy/phy.c
> > @@ -308,7 +308,7 @@ void phy_ethtool_ksettings_get(struct phy_device
> > *phydev,
> > if (phydev->interface ==
On Wed, Feb 10, 2021 at 12:14:35PM +0100, Michael Walle wrote:
> Am 2021-02-10 11:49, schrieb Russell King - ARM Linux admin:
> The PHY doesn't support fiber and register 0..15 are always available
> regardless of the selected page for the IP101G.
>
> genphy_() stuff will work, but
On Wed, Feb 10, 2021 at 02:51:34AM +0100, Andrew Lunn wrote:
> This is a general comment, not a problem specific to this patch.
>
> There is some interesting race conditions here. The marvell driver
> first checks the fibre page and gets the status of the fiber port. As
> you can see from the
On Wed, Feb 10, 2021 at 11:38:18AM +0100, Michael Walle wrote:
> Am 2021-02-10 11:30, schrieb Russell King - ARM Linux admin:
> > On Wed, Feb 10, 2021 at 08:03:07AM +0100, Heiner Kallweit wrote:
> > > On 09.02.2021 17:40, Michael Walle wrote:
> > > > +out:
> >
On Wed, Feb 10, 2021 at 08:03:07AM +0100, Heiner Kallweit wrote:
> On 09.02.2021 17:40, Michael Walle wrote:
> > +out:
> > + return phy_restore_page(phydev, oldpage, err);
>
> If a random page was set before entering config_init, do we actually want
> to restore it? Or wouldn't it be better to
On Tue, Feb 09, 2021 at 10:42:31AM +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, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> Right, adding something like a genphy_{read,write}_mmd() doesn't make
> too much sense for now. What I meant is just exporting mmd_phy_indirect().
> Then you don't have to open-code the first three steps of a mmd read/write.
> And
On Tue, Feb 09, 2021 at 01:15:28PM +0300, Serge Semin wrote:
> On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote:
> > Nice analysis. Alternatively to duplicating this code piece we could
> > export mmd_phy_indirect(). But up to you.
>
> I also considered creating a generic method to
On Mon, Feb 08, 2021 at 08:42:36PM +0530, Calvin Johnson wrote:
> +int fwnode_mdiobus_register_phy(struct mii_bus *bus,
> + struct fwnode_handle *child, u32 addr)
> +{
> + struct mii_timestamper *mii_ts;
If you initialise this to NULL...
> + struct phy_device
On Mon, Feb 08, 2021 at 08:42:44PM +0530, Calvin Johnson wrote:
> Modify dpaa2_mac_connect() to support ACPI along with DT.
> Modify dpaa2_mac_get_node() to get the dpmac fwnode from either
> DT or ACPI.
>
> Replace of_get_phy_mode with fwnode_get_phy_mode to get
> phy-mode for a dpmac_node.
>
>
On Mon, Feb 08, 2021 at 08:42:42PM +0530, Calvin Johnson wrote:
> Define phylink_fwnode_phy_connect() to connect phy specified by
> a fwnode to a phylink instance.
>
> Signed-off-by: Calvin Johnson
Also, the subject line should be "net: phylink: ..." Consistency is
really appreciated.
Thanks.
On Mon, Feb 08, 2021 at 08:42:42PM +0530, Calvin Johnson wrote:
> +int phylink_fwnode_phy_connect(struct phylink *pl,
> +struct fwnode_handle *fwnode,
> +u32 flags)
> +{
> + struct fwnode_handle *phy_fwnode;
> + struct phy_device
On Mon, Feb 08, 2021 at 10:20:38AM +0100, Oleksij Rempel wrote:
> On Wed, Feb 03, 2021 at 09:56:28AM +, Russell King - ARM Linux admin
> wrote:
> > That is the historical fix for this problem, but there is a better
> > solution now in net-next - configuring the Tw par
On Fri, Feb 05, 2021 at 12:40:54AM +, Giancarlo Ferrari wrote:
> Russell,
>
> On Fri, Feb 05, 2021 at 12:18:33AM +, Russell King - ARM Linux admin
> wrote:
> > On Thu, Feb 04, 2021 at 11:48:42PM +, Giancarlo Ferrari wrote:
> > > Can I ask about having it i
On Thu, Feb 04, 2021 at 11:48:42PM +, Giancarlo Ferrari wrote:
> Can I ask about having it integrated ?
Thanks for testing. Are you willing for me to add:
Tested-by: Giancarlo Ferrari
to the commit log?
I can move it into the fixes branch which I want to send to Linus by
Saturday at the
or arm.
> So I've now built a plain next-20210203 (without Ard's fix) using
> this command line:
>
> make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm
> CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage
>
> I'm using a modified Docker image gtucker/ke
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
1 - 100 of 9994 matches
Mail list logo
