linux-kernel - Re: [PATCH mlx5-next v1 05/11] net/mlx5: Register mlx5 devices to auxiliary virtual bus

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201106065629.GD5475@unreal>
Date:   Fri, 6 Nov 2020 08:56:29 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Jason Gunthorpe <jgg@...dia.com>, Saeed Mahameed <saeed@...nel.org>
Cc:     Doug Ledford <dledford@...hat.com>,
        gregkh <gregkh@...uxfoundation.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Jason Wang <jasowang@...hat.com>, linux-rdma@...r.kernel.org,
        "Michael S. Tsirkin" <mst@...hat.com>, netdev@...r.kernel.org,
        Parav Pandit <parav@...dia.com>, Roi Dayan <roid@...dia.com>,
        virtualization@...ts.linux-foundation.org,
        alsa-devel@...a-project.org, tiwai@...e.de, broonie@...nel.org,
        "David S . Miller" <davem@...emloft.net>,
        ranjani.sridharan@...ux.intel.com,
        pierre-louis.bossart@...ux.intel.com, fred.oh@...ux.intel.com,
        shiraz.saleem@...el.com, dan.j.williams@...el.com,
        kiran.patil@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH mlx5-next v1 05/11] net/mlx5: Register mlx5 devices to
 auxiliary virtual bus

On Thu, Nov 05, 2020 at 05:09:48PM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 05, 2020 at 12:59:20PM -0800, Saeed Mahameed wrote:
>
> > 2. you can always load a driver without its underlying device existed.
> > for example, you can load a pci device driver/module and it will load
> > and wait for pci devices to pop up, the subsysetem infrastructure will
> > match between drivers and devices and probe them.
>
> Yes, this works fine with this design
>
> > struct aux_driver mlx5_vpda_aux_driver {
> >
> >       .name = "vdpa",
> >        /* match this driver with mlx5_core devices */
> >       .id_table = {"mlx5_core"},
> >       .ops {
> >             /* called before probe on actual aux mlx5_core device */
> >            .is_supported(struct aux_device);
>
> This means module auto loading is impossible, we can't tell to load
> the module until we load the module to call the is_supported code ..

Right, and if we can, it will be violation of everything we know in
driver model, because the call "is_supported" will need to be called
for every registered driver without any relation to existed devices.

And mlx5_rescan_drivers() came as a need to overcome LAG and eswitch
craziness in everything related to their reprobe flows. Once they will
be changed to work like normal drivers, we will be able to simplify it.

So let's talk offline to see how can we improve mlx5_core even more
after this series is merged.

Thanks

>
> Jason