From: Andre Przywara <andre.przywara@arm.com>
To: Sam Edwards <cfsworks@gmail.com>
Cc: u-boot@lists.denx.de, Jagan Teki <jagan@amarulasolutions.com>,
Marek Vasut <marex@denx.de>,
Maksim Kiselev <bigunclemax@gmail.com>
Subject: Re: [PATCH 1/3] usb: musb-new: sunxi: do not attempt to access NULL SRAMC
Date: Mon, 5 Jun 2023 12:04:24 +0100 [thread overview]
Message-ID: <20230605120424.7ed91fb4@donnerap.cambridge.arm.com> (raw)
In-Reply-To: <20230602214958.167909-2-CFSworks@gmail.com>
On Fri, 2 Jun 2023 15:49:56 -0600
Sam Edwards <cfsworks@gmail.com> wrote:
Hi Sam,
thanks for taking care and sending patched!
> I believe that some sunxis (ncat2?) lack a SRAMC block,
> as accessing this region results in a data abort.
Ah, that's a good find, but I think it goes a bit deeper:
Just to be clear, "SRAMC" stands for "SRAM controller", not "SRAM memory
block C" (which other SoCs have, but indeed not the D1/T113s). However
we (sort of) have an "SRAM controller", although the manual and DT call
this IP block "syscon" these days. The address currently in ncat2.h is
just plain wrong, it's actually 0x3000000.
Now looking at the Linux MUSB driver, only the older SoCs (A10, A20,
F1C100s) need to switch some SRAM block to the OTG controller:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/musb/sunxi.c#n817
So the code is already wrong, we should not touch SYSCON+0x04 for any
newer SoCs, based on the compatible. We seem to be just lucky that newer
syscons don't have any register at offset 0x4.
And using SUNXI_SRAMC_BASE is somewhat dodgy to begin with, we should use
the "allwinner,sram" property from the DT, although this is surely more
complicated.
Do you have spare cycles to convert this over to look at the DT for this
SRAM part? For now you might just change the SRAM address in ncat2.h to
0x03000000, to be inline with the other SoCs.
Cheers,
Andre
> Checking
> that it's non-null before accessing it allows this to be
> set to NULL for SoCs where it's not present.
>
> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
> ---
> drivers/usb/musb-new/sunxi.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index dc4cfc2194..6e60dd47e0 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -174,13 +174,15 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base)
>
> static void USBC_ConfigFIFO_Base(void)
> {
> - u32 reg_value;
> -
> - /* config usb fifo, 8kb mode */
> - reg_value = readl(SUNXI_SRAMC_BASE + 0x04);
> - reg_value &= ~(0x03 << 0);
> - reg_value |= BIT(0);
> - writel(reg_value, SUNXI_SRAMC_BASE + 0x04);
> + if (SUNXI_SRAMC_BASE) {
> + u32 reg_value;
> +
> + /* config usb fifo, 8kb mode */
> + reg_value = readl(SUNXI_SRAMC_BASE + 0x04);
> + reg_value &= ~(0x03 << 0);
> + reg_value |= BIT(0);
> + writel(reg_value, SUNXI_SRAMC_BASE + 0x04);
> + }
> }
>
> /******************************************************************************
next prev parent reply other threads:[~2023-06-05 11:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 21:49 [PATCH 0/3] Allwinner sunxi USB gadget improvements Sam Edwards
2023-06-02 21:49 ` [PATCH 1/3] usb: musb-new: sunxi: do not attempt to access NULL SRAMC Sam Edwards
2023-06-05 10:00 ` Marek Vasut
2023-06-05 11:04 ` Andre Przywara [this message]
2023-06-07 5:39 ` Sam Edwards
2023-06-07 10:45 ` Andre Przywara
2023-06-07 23:29 ` Sam Edwards
2023-06-02 21:49 ` [PATCH 2/3] usb: musb-new: sunxi: fix error check Sam Edwards
2023-06-05 10:01 ` Marek Vasut
2023-06-02 21:49 ` [PATCH 3/3] usb: musb-new: sunxi: make compatible with UDC/DM gadget model Sam Edwards
2023-06-05 10:02 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230605120424.7ed91fb4@donnerap.cambridge.arm.com \
--to=andre.przywara@arm.com \
--cc=bigunclemax@gmail.com \
--cc=cfsworks@gmail.com \
--cc=jagan@amarulasolutions.com \
--cc=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox