[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4370398e-fe9b-44f6-bba5-c0bb2ead9d58@lunn.ch>
Date: Sat, 15 Jul 2023 05:17:17 +0200
From: Andrew Lunn <andrew@...n.ch>
To: SIMON BABY <simonkbaby@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: Query on acpi support for dsa driver
On Fri, Jul 14, 2023 at 07:46:27PM -0700, SIMON BABY wrote:
> Thanks Andrew . So if I add a platform driver, will it get triggered
> by ACPI table or Device Tree or by some other mechanism?
There are a couple of options.
You can just load the module, e.g. via /etc/modules. That is the
simplest solution.
If your board has unique BIOS identity strings, you can use that to
trigger loading. e.g. look at drivers/platform/x86/pcengines-apuv2.c.
apu_gpio_dmi_table[] __initconst = {
/* APU2 w/ legacy BIOS < 4.0.8 */
{
.ident = "apu2",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
DMI_MATCH(DMI_BOARD_NAME, "APU2")
},
.driver_data = (void *)&board_apu2,
},
But they BIOS strings need to be unique to your product. If you have a
generic ComExpress module for example as the core of your product, you
need to customise the BIOS strings. Otherwise this platform driver
module will be loaded for any product which happens to have that
ComExpress card, not just your product.
> My goal is to see all the switch ports in Linux kernel . The switch
> is connected via I2C bus .
Yes, that is the idea of DSA. You can treat the switch ports as Linux
interfaces. All you need is the control plain bus, i2c in your case,
and a 'SoC' Ethernet interface connected to one of the ports of the
switch. I say 'SoC' because such systems are typically ARM or MIPS
systems with an integrated Ethernet controller, but i guess you have a
PCIe NIC? i210 or something like that? That works equally as well.
Andrew
Powered by blists - more mailing lists