Hi guys ...
new to the list. need help ?
can anyone please guide to me to an how-to or documentation on how to make a
custom boot.img & initrd.img ?
thanks in advance..
parag mehta
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
Hi Romain
yes, i wuld love to help you out, in anyways if you require any help just
mail me.
regards,
parag mehta
- Original Message -
From: "Romain Kang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 29, 2001 7:57 AM
Subject: [META] proposal to set up digestifier fo
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, Feb 27, 2019 at 06:47:32PM +0100, Marcin Wojtas wrote:
> Current version of the driver was configuring XLG MAC
> in a way to wait 3 IDLE frames before allowing for the
> link-up interrupt to be triggered. This resulted in an
> issue, preventing to detect the link change during RX
> traffic
Hi all,
While looking at hdmi-codec issues, I spotted this code:
static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
{
...
if (params_width(params) >
On Thu, Feb 28, 2019 at 02:54:29PM +0200, Jyri Sarha wrote:
> On 28/02/2019 14:15, Russell King - ARM Linux admin wrote:
> > Hi all,
> >
> > While looking at hdmi-codec issues, I spotted this code:
> >
> > static int hdmi_codec_hw_params(st
On Thu, Feb 28, 2019 at 04:17:01PM +0300, Dmitry Osipenko wrote:
> +#ifdef CONFIG_CACHE_L2X0
> +static void tf_cache_write_sec(unsigned long val, unsigned int reg)
> +{
> + u32 l2x0_way_mask = 0xff;
> +
> + switch (reg) {
> + case L2X0_CTRL:
> + if (l2x0_saved_regs.aux_ctrl
On Thu, Feb 28, 2019 at 04:35:29PM +0200, Jyri Sarha wrote:
> On 28/02/2019 15:10, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 28, 2019 at 02:54:29PM +0200, Jyri Sarha wrote:
> >> On 28/02/2019 14:15, Russell King - ARM Linux admin wrote:
> >>> Hi all,
>
On Sun, Apr 14, 2019 at 10:51:09PM -0700, Christoph Hellwig wrote:
> On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote:
> > This patch avoids
> > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
> > observed when compiling v4.19.34.
> >
> > The xen-privcmd dr
On Wed, Apr 17, 2019 at 11:03:51AM +0100, Catalin Marinas wrote:
> On Wed, Apr 17, 2019 at 10:41:37AM +0100, Russell King wrote:
> > On Sun, Apr 14, 2019 at 10:51:09PM -0700, Christoph Hellwig wrote:
> > > On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote:
> > > > This patch avoid
On Tue, Feb 05, 2019 at 05:21:07PM +0100, Daniel Vetter wrote:
> Someone owes me a beer ...
I find that deeply offensive - it is clearly directed at me personally
as author of the component helper.
There are double-standards in the kernel ecosystem with respect to
documentation - there are entire
On Fri, Jan 25, 2019 at 03:43:59PM +, Catalin Marinas wrote:
> On Fri, Jan 18, 2019 at 05:18:13PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> > index 86de9eb34296..20ed7e026723 100644
> > --- a/arch/arm/tools/syscall.tbl
> > +++ b/arch/
On Wed, Mar 27, 2019 at 10:37:19AM -0700, Tim Harvey wrote:
> On Sun, Mar 17, 2019 at 10:00 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Sun, Mar 17, 2019 at 04:48:24PM +, Måns Rullgård wrote:
> > > Stefan Agner writes:
> > >
> > > &g
On Mon, Apr 08, 2019 at 10:00:02AM -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2019-04-08 03:49:41)
> > On Fri, Apr 05, 2019 at 01:37:24PM -0700, Stephen Boyd wrote:
> > > Quoting Vaittinen, Matti (2019-04-04 23:51:43)
> > > > On Thu, 2019-04-04 at 14:53 -0700, Stephen Boyd wrote:
> > > >
On Tue, Apr 09, 2019 at 05:31:48AM +, Vaittinen, Matti wrote:
> On Mon, 2019-04-08 at 23:21 +0100, Russell King - ARM Linux admin
> wrote:
> > On Mon, Apr 08, 2019 at 10:00:02AM -0700, Stephen Boyd wrote:
> > > Quoting Matti Vaittinen (2019-04-08 03:49:41)
> > > &
On Tue, Apr 09, 2019 at 11:17:14PM +0900, Jinyoung Park wrote:
> If the console lock is held by other CPU running while the system is
> restarting or shutting down, the Kernel messages in the printk log buffer
> can not be printed out to the console drivers. The Kernel messages can be
> lost or mes
On Tue, Feb 26, 2019 at 01:55:37PM +0530, Sameer Pujar wrote:
> The requirement for this came while adding runtime PM support for HDA
> driver. There were concerns about driver explicitly handling !PM case.
> In general, drivers need to handle !PM case with work arounds for
> managing clocks and po
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 Arm
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 up
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: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 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 s
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 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 hunk
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
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 == PHY_
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 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 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 s
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. You
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: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: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 betwee
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.
>
> Signed-off-
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
> +++ b/drivers/net/ethern
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 readl(priv->cm3
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));
> +
> + if
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 pat
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 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 ev
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 eMMC
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: f40ddce88593482919761f74910f42f4b84c004b
> > commit: c281634c865202e2776b0250678ff93c77
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 an
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 P
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 boa
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 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 ++
> arch/arm64/boot/dts/marvel
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...@vger.kernel.org;
> > and...@lunn.ch; j..
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 i
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 pol
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 Pa
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 b
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
spamco
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
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 s
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 b/ar
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 kexec_
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 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 you
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 var
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 struct
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 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 n
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 it.
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/next-20210203-ard-fix/
>
>
> +clang
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 XG
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 archite
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.
I
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/
On Thu, Feb 04, 2021 at 09:31:06PM +, Guillaume Tucker wrote:
> On 04/02/2021 18:23, Nick Desaulniers wrote:
> > You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should
> > permit fallback to BFD.
>
> That was close, except we're cross-compiling with GCC for arm.
> So I've now built
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 ve
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 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 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 *phy_
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: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: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 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 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 i
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, val)
On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
> wrote:
> >
> > Ard,
> >
> > Please take a look. Obviously, whatever the resolution is going to be
> > needed when Linus opens the m
On Sat, May 30, 2020 at 10:51:32AM +0200, Ard Biesheuvel wrote:
> On Sat, 30 May 2020 at 10:41, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 28 May 2020 at 01:23, Russell King - A
On Sat, May 30, 2020 at 09:35:55AM +0200, Christophe JAILLET wrote:
> The dev_id used in 'request_irq()' and 'free_irq()' should match.
> So use 'host' in both cases.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Christophe JAILLET
This is itself wrong. cumanascsi_2_intr() requi
On Sun, May 31, 2020 at 12:43:15AM +0300, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> In kernel 4.19 (and probably earlier too) there are issues surrounding
> the PHY_AN state.
>
> For example, if a PHY is in PHY_AN state and AN has not finished, then
> what is supposed to happen is that
On Mon, Jun 01, 2020 at 12:00:16AM +0300, Vladimir Oltean wrote:
> On Sun, 31 May 2020 at 03:19, Russell King - ARM Linux admin
> wrote:
> >
> > On Sun, May 31, 2020 at 12:43:15AM +0300, Vladimir Oltean wrote:
> > > From: Vladimir Oltean
> > >
> >
On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
> Move the definition of malloc pool size of the decompressor to
> a single place. This value will be exposed later for kexec_file loader.
>
> Signed-off-by: Łukasz Stelmach
> ---
> arch/arm/boot/compressed/Makefile | 2 ++
> arch/
On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
> requirements of the decompressor code.
Why do we need to know the stack and BSS size, when the userspace
kexec tool doesn't need to know this to perform the same f
On Mon, Jun 01, 2020 at 04:27:53PM +0200, Łukasz Stelmach wrote:
> Add kexec_image_info to print detailed information about a kexec image.
Isn't this already visible through kexec debugging? Why do we need
to duplicate the same output in the kernel? Do we think that the
kexec interfaces are that
On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
> This is kexec_file_load implementation for ARM. It loads zImage and
> initrd from file descripters and resuses DTB.
>
> Most code is derived from arm64 kexec_file_load implementation
> and from kexec-tools.
Please make the uImage
On Mon, Jun 01, 2020 at 04:56:40PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 15:46>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
> >> Move the definition of malloc pool size of the decompresso
On Mon, Jun 01, 2020 at 04:07:45PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
> > diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
> > new file mode 100644
> > index 0
On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc
On Mon, Jun 01, 2020 at 10:27:45PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 19:25>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
> >> It was <2020-06-01 pon 15:55>, when Russell King - AR
On Mon, Jun 01, 2020 at 11:57:30PM +0300, Vladimir Oltean wrote:
> On Mon, 1 Jun 2020 at 03:28, Russell King - ARM Linux admin
> wrote:
> > And yes, I do have some copper SFP modules that have an (inaccessible)
> > AR803x PHY on them - Microtik S-RJ01 to be exact. I forget
On Tue, May 19, 2020 at 10:53:52AM +0200, Lukasz Stelmach wrote:
> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > Currently, the start address of physical memory is obtained by masking
> > the program counter with a fixed mask of 0xf800. This mask value
> > was chosen as a b
On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> Hi Łukasz
>
> Thanks for your report!
>
> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach
> wrote:
> > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > Currently, the start address of physical memory is ob
On Sat, May 09, 2020 at 09:20:50PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, May 09, 2020 at 08:52:46PM +0100, Russell King - ARM Linux admin
> wrote:
> > It is highly likely that 895586d5dc32 is responsible for this breakage.
> > I've been investigating this a
On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> CC devicetree
>
> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> wrote:
> > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > > On Tue
On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM
1 - 100 of 784 matches
Mail list logo
