The primary purpose of this series is to add support for vsc751x
switches that are wired up to be managed via MDIO. The current MFD
driver only has support for management over SPI.

While reworking the spi and core files to allow hooking up another
underlying bus, I found what I think might be a bug in the SPI
implementation, for the case where the SPI bus is set higher than
500kHz. But as I don't have such hardware, I don't know if the bug is
real, nor am I able to test my changes.

If desired, I can drop those changes, at the expense of having to
duplicate some logic around setting up the gcb_regmap and calling
reset in the mdio backend, but since I spotted it anyway I thought I'd
include it for the first iteration.

Also, if desired, I can put the mdio and spi backends behind separate
config options, with the spi option defaulting to y to preserve
behaviour of existing .configs setting CONFIG_MFD_OCELOT.

Rasmus Villemoes (8):
  mfd: ocelot: refactor bus-specific regmap initialization
  mfd: ocelot: move SPI specific macros to ocelot-spi.c
  mfd: ocelot: rework SPI (re-)initialization after chip reset
  mfd: ocelot: lift chip reset logic to ocelot-core.c
  mfd: ocelot: make ocelot_chip_init() static
  mfd: ocelot: correct Kconfig dependency
  mfd: ocelot: enable support for mdio management
  dt-bindings: mfd: ocelot: mention MDIO management and add example

 .../devicetree/bindings/mfd/mscc,ocelot.yaml  | 121 ++++++++++++-
 drivers/mfd/Kconfig                           |   5 +-
 drivers/mfd/Makefile                          |   2 +-
 drivers/mfd/ocelot-core.c                     |  44 ++++-
 drivers/mfd/ocelot-mdio.c                     | 161 ++++++++++++++++++
 drivers/mfd/ocelot-spi.c                      |  53 ++----
 drivers/mfd/ocelot.h                          |  18 +-
 7 files changed, 339 insertions(+), 65 deletions(-)
 create mode 100644 drivers/mfd/ocelot-mdio.c

-- 
2.49.0

Hi Rasmus,

On Wed, Mar 19, 2025 at 01:30:50PM +0100, Rasmus Villemoes wrote:
> The primary purpose of this series is to add support for vsc751x
> switches that are wired up to be managed via MDIO. The current MFD
> driver only has support for management over SPI.

Are you still intending to work on this? I understand if not, but maybe
the bugfix / documentation patches could be broken out, as I think
they'd be accepted pretty easily.

>   mfd: ocelot: rework SPI (re-)initialization after chip reset
>   mfd: ocelot: correct Kconfig dependency
>   dt-bindings: mfd: ocelot: mention MDIO management and add example

Is there anything you need from me?

Thanks,

Colin Foster

On Mon, Jun 30 2025, Colin Foster <colin.foster@in-advantage.com> wrote:

> Hi Rasmus,
>
> On Wed, Mar 19, 2025 at 01:30:50PM +0100, Rasmus Villemoes wrote:
>> The primary purpose of this series is to add support for vsc751x
>> switches that are wired up to be managed via MDIO. The current MFD
>> driver only has support for management over SPI.
>
> Are you still intending to work on this?

Sorry for dropping the ball, but the customer didn't want to fund
finishing the upstreaming, and I was assigned to other
projects/customers. I also no longer have their hardware, so couldn't
test a new version myself. So no, I don't expect to work on this
anymore.

> I understand if not, but maybe the bugfix / documentation patches
> could be broken out, as I think they'd be accepted pretty easily.

>>   mfd: ocelot: rework SPI (re-)initialization after chip reset
>>   mfd: ocelot: correct Kconfig dependency
>>   dt-bindings: mfd: ocelot: mention MDIO management and add example

Probably the first two, but I'm not sure the last one makes sense
without the actual support landing. And the first one, AFAIR, would need
to be reworked as it relied on the "mfd: ocelot: refactor bus-specific
regmap initialization" which Lee rejected.

There's also "mfd: ocelot: move SPI specific macros to ocelot-spi.c"
which is just a trivial cleanup.

Rasmus

Hi Rasmus,

On Wed, Mar 19, 2025 at 01:30:50PM +0100, Rasmus Villemoes wrote:
> While reworking the spi and core files to allow hooking up another
> underlying bus, I found what I think might be a bug in the SPI
> implementation, for the case where the SPI bus is set higher than
> 500kHz. But as I don't have such hardware, I don't know if the bug is
> real, nor am I able to test my changes.
>
> If desired, I can drop those changes

I ran the patch set on my setup and everything worked. I was hopeful
that it would solve a power sequencing issue that I came across a while
back. It didn't, but the logic works and seems sound, so I say keep it!

I'll review my parts and add the relevant testing tags.

Thanks for the update, and I'm glad it is being used!

Colin Foster