Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221122154934.13937-1-mailhol.vincent@wanadoo.fr>
 <Y33sD/atEWBTPinG@nanopsycho> <CAMZ6Rq+jG=iAHCfFED7SE3jP8EnSSCWc2LLFv+YDKAf0ABe0YA@mail.gmail.com>
 <Y34NsilOe8BICA9Q@nanopsycho>
In-Reply-To: <Y34NsilOe8BICA9Q@nanopsycho>
From:   Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Date:   Fri, 25 Nov 2022 01:20:14 +0900
Message-ID: <CAMZ6RqJ6dBxBOBETim5aY-by2qpfHpqffwtKpYGS6K6K5=jvag@mail.gmail.com>
Subject: Re: [RFC PATCH] net: devlink: devlink_nl_info_fill: populate default information
To:     Jiri Pirko <jiri@nvidia.com>
Cc:     netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Wed. 23 Nov. 2022 at 21:10, Jiri Pirko <jiri@nvidia.com> wrote:
> Wed, Nov 23, 2022 at 12:00:44PM CET, mailhol.vincent@wanadoo.fr wrote:
> >On Wed. 23 nov. 2022 à 18:46, Jiri Pirko <jiri@nvidia.com> wrote:
> >> Tue, Nov 22, 2022 at 04:49:34PM CET, mailhol.vincent@wanadoo.fr wrote:

(...)

> >> >+      if (!strcmp(dev->parent->type->name, "usb_device")) {
> >>
> >> Comparing to string does not seem correct here.
> >
> >There is a is_usb_device() which does the check:
> >  https://elixir.bootlin.com/linux/v6.1-rc1/source/drivers/usb/core/usb.h#L152
> >
> >but this macro is not exposed outside of the usb core. The string
> >comparison was the only solution I found.
>
> Find a different one. String check here is wrong.

After looking again, I found no alternative and so I asked the USB
mailing list and got an answer from Greg. There is no ways to do so
and the class code is not supposed to do this:
https://lore.kernel.org/linux-usb/Y3+VfNdt%2FK7UtRcw@kroah.com/

So I guess that there will be no code factorization for device specific values.

@Jakub, with this in mind, does it still make sense to add the bitmap?
Aside from the driver name, it seems that there will be no code
factorization for other types dependent values. If we only set the
driver name at the core level, I would rather just clean up the
existing. (Side comment, I finished implementing the bitmap just
before receiving Greg's answer; I guess my code will go to the trash
can...)