Messages in this thread | | | From | Andy Shevchenko <> | Date | Thu, 18 May 2017 13:56:15 +0300 | Subject | Re: [PATCH 8/8] serial: exar: Add support for IOT2040 device |
| |
On Thu, May 18, 2017 at 1:37 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 2017-05-18 12:17, Andy Shevchenko wrote: >> On Thu, May 18, 2017 at 8:06 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> On 2017-05-13 15:54, Andy Shevchenko wrote:
>>>> Please, refactor that using properly formed DMI structrure and use its >>>> callback and driver data facilities/ >>> >>> Could you point to a specific example? The callback of the dmi_system_id >>> structure is not designed to handle device initializations like this one >>> - not to speak of having those two different initialization points here. >> >> Sure. >> >> drivers/platform/x86/dell-laptop.c: >> >> static const struct dmi_system_id dell_quirks[] __initconst = { >> { >> .callback = dmi_matched, >> .ident = "Dell Vostro V130", >> .matches = { >> DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), >> DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V130"), >> }, >> .driver_data = &quirk_dell_vostro_v130, >> }, >> >> >> (just in case, dmi_matched() is part of that module) >> > > OK, but that would basically replace the two lines for matching against > the DMI values with the structure above. We would still need the > existing hooks at the two points where we have them right now.
Right.
> Doesn't > look to me as if the code would become clearer or better separated or > easier extensible (the latter being hard anyway without knowing any > potential third special case).
stmmac, that you chose as an example, should go that way in the first place because it was my though behind which is on-to-one to yours above.
-- With Best Regards, Andy Shevchenko
| |