linux-kernel - Re: [RFC PATCH v4 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

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: <c2694d50-db7c-84ee-288a-06802e10ca8d@linux.intel.com>
Date: Wed, 2 Oct 2024 13:01:05 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Pavel Machek <pavel@....cz>
cc: Werner Sembach <wse@...edocomputers.com>, 
    Hans de Goede <hdegoede@...hat.com>, bentiss@...nel.org, 
    dri-devel@...ts.freedesktop.org, jelle@...aa.nl, jikos@...nel.org, 
    lee@...nel.org, linux-input@...r.kernel.org, 
    LKML <linux-kernel@...r.kernel.org>, linux-leds@...r.kernel.org, 
    miguel.ojeda.sandonis@...il.com, ojeda@...nel.org, onitake@...il.com, 
    cs@...edo.de, platform-driver-x86@...r.kernel.org
Subject: Re: [RFC PATCH v4 1/1] platform/x86/tuxedo: Add virtual LampArray
 for TUXEDO NB04 devices

On Wed, 2 Oct 2024, Pavel Machek wrote:

> Hi!
> 
> > > +static struct wmi_driver tuxedo_nb04_wmi_ab_driver = {
> > > +	.driver = {
> > > +		.name = "tuxedo_nb04_wmi_ab",
> > > +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > > +	},
> > > +	.id_table = tuxedo_nb04_wmi_ab_device_ids,
> > > +	.probe = probe,
> > > +	.remove = remove,
> > > +	.no_singleton = true,
> > > +};
> > > +
> > > +// We don't know if the WMI API is stable and how unique the GUID is for this ODM. To be on the safe
> > > +// side we therefore only run this driver on tested devices defined by this list.
> > 
> > Please limit comment length to 80 chars and since you need multiple lines 
> > here anyway, use the usual /* */ multiline comment formatting.
> 
> This driver needs to be split into generic part + hw specific part,
> and reasonable kernel/user API needs to be defined for the generic
> part. It is really too soon to tweak comment lengths.

Coding style is not something you add on top of everything after 
everything else is done. It's much better to start with that right from 
the beginning.

-- 
 i.