lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ