From: <Tristram.Ha@microchip.com>
To: <bastien.curutchet@bootlin.com>
Cc: <thomas.petazzoni@bootlin.com>, <miquel.raynal@bootlin.com>,
<Woojung.Huh@microchip.com>, <pascal.eberhard@se.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<UNGLinuxDriver@microchip.com>, <andrew@lunn.ch>,
<olteanv@gmail.com>, <kuba@kernel.org>, <davem@davemloft.net>,
<edumazet@google.com>, <pabeni@redhat.com>
Subject: RE: [PATCH net] net: dsa: microchip: Select SPI_MODE 0 for KSZ8463
Date: Thu, 11 Sep 2025 21:11:32 +0000 [thread overview]
Message-ID: <DM3PR11MB8736FE9FB85FC264B6399849EC09A@DM3PR11MB8736.namprd11.prod.outlook.com> (raw)
In-Reply-To: <85faa80c-0536-46d8-8f3a-00ae78499fd0@bootlin.com>
> On 9/11/25 12:10 AM, Tristram.Ha@microchip.com wrote:
> >> KSZ8463 expects the SPI clock to be low on idle and samples data on
> >> rising edges. This fits SPI mode 0 (CPOL = 0 / CPHA = 0) but the SPI
> >> mode is set to 3 for all the switches supported by the driver. This
> >> can lead to invalid read/write on the SPI bus.
> >>
> >> Set SPI mode to 0 for the KSZ8463.
> >> Leave SPI mode 3 as default for the other switches.
> >>
> >> Signed-off-by: Bastien Curutchet (Schneider Electric)
> >> <bastien.curutchet@bootlin.com>
> >> Fixes: 84c47bfc5b3b ("net: dsa: microchip: Add KSZ8463 switch support to KSZ DSA
> >> driver")
> >> ---
> >> drivers/net/dsa/microchip/ksz_spi.c | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/dsa/microchip/ksz_spi.c
> >> b/drivers/net/dsa/microchip/ksz_spi.c
> >> index
> >>
> d8001734b05741446fa78a1e88c2f82e894835ce..dcc0dbddf7b9d70fbfb31d4b260b80
> >> ca78a65975 100644
> >> --- a/drivers/net/dsa/microchip/ksz_spi.c
> >> +++ b/drivers/net/dsa/microchip/ksz_spi.c
> >> @@ -139,6 +139,7 @@ static int ksz_spi_probe(struct spi_device *spi)
> >> const struct regmap_config *regmap_config;
> >> const struct ksz_chip_data *chip;
> >> struct device *ddev = &spi->dev;
> >> + u32 spi_mode = SPI_MODE_3;
> >> struct regmap_config rc;
> >> struct ksz_device *dev;
> >> int i, ret = 0;
> >> @@ -155,8 +156,10 @@ static int ksz_spi_probe(struct spi_device *spi)
> >> dev->chip_id = chip->chip_id;
> >> if (chip->chip_id == KSZ88X3_CHIP_ID)
> >> regmap_config = ksz8863_regmap_config;
> >> - else if (chip->chip_id == KSZ8463_CHIP_ID)
> >> + else if (chip->chip_id == KSZ8463_CHIP_ID) {
> >> regmap_config = ksz8463_regmap_config;
> >> + spi_mode = SPI_MODE_0;
> >> + }
> >> else if (chip->chip_id == KSZ8795_CHIP_ID ||
> >> chip->chip_id == KSZ8794_CHIP_ID ||
> >> chip->chip_id == KSZ8765_CHIP_ID)
> >> @@ -185,7 +188,7 @@ static int ksz_spi_probe(struct spi_device *spi)
> >> dev->pdata = spi->dev.platform_data;
> >>
> >> /* setup spi */
> >> - spi->mode = SPI_MODE_3;
> >> + spi->mode = spi_mode;
> >> ret = spi_setup(spi);
> >> if (ret)
> >> return ret;
> >>
> >> ---
> >> base-commit: c65e2aee8971eb9d4bc2b8edc3a3a62dc98f0410
> >> change-id: 20250910-fix-omap-spi-d7c64f2416df
> >
> > Actually it is best to completely remove the code. The SPI mode should
> > be dictated by spi-cpol and spi-cpha settings in the device tree. I do
> > not know why that code was there from the beginning.
> >
>
> Ok, I didn't know these settings were available on the device-tree, I
> can remove the spi->mode setting in a new patch.
>
> > All KSZ switches can use SPI mode 0 and 3, and 3 is recommended for high
> > SPI frequency. Sometimes a bug/quirk in the SPI bus driver prevents the
> > very first SPI transfer to be successful in mode 3 because of a missed
> > rising edge clock signal, so it is forced to use mode 0. (The Atmel SPI
> > bus driver has this issue in some old kernel versions.)
> >
> > As for KSZ8463 I have always used mode 3 and do not know of any issue of
> > using that mode.
> >
>
> I have issues on the first transfer with the AM335x's spi-omap2-mcspi
> driver. I first tried to fix this driver but since the KSZ8463's
> datasheet explicitly mentions that it expects the CLK to be low at idle,
> I thought this was the right fix.
>
> But I'll fix the SPI driver then, thanks.
It seems you may have the same issue I faced before. A workaround in the
SPI bus driver may avoid the problem, but the change happens in spi.c, so
it may not be a good solution.
Your best bet is to remove the spi_setup call and use mode 0 in the
device tree.
Another quick fix is to do a dummy write in the DSA driver before reading
and checking the chip id.
prev parent reply other threads:[~2025-09-11 21:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 13:07 Bastien Curutchet
2025-09-10 22:10 ` Tristram.Ha
2025-09-11 6:16 ` Bastien Curutchet
2025-09-11 21:11 ` Tristram.Ha [this message]
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=DM3PR11MB8736FE9FB85FC264B6399849EC09A@DM3PR11MB8736.namprd11.prod.outlook.com \
--to=tristram.ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=andrew@lunn.ch \
--cc=bastien.curutchet@bootlin.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=pascal.eberhard@se.com \
--cc=thomas.petazzoni@bootlin.com \
/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
all inboxes | Powered by JetHome®