Hi Hans, On Mon, Jan 18, 2021 at 04:32:54PM +0100, Hans de Goede wrote: > On 1/18/21 4:23 PM, andriy.shevchenko@xxxxxxxxxxxxxxx wrote: > > On Mon, Jan 18, 2021 at 02:51:30PM +0000, Barnabás Pőcze wrote: > >> 2021. január 18., hétfő 14:51 keltezéssel, Andy Shevchenko írta: > >> > >>> On Mon, Jan 18, 2021 at 11:12:34AM +0000, Barnabás Pőcze wrote: > >>>> 2021. január 18., hétfő 1:34 keltezéssel, Daniel Scally írta: > >>> > >>>> Have you considered putting the source (and header) files into a dedicated > >>>> folder? I think it'd help manageability in the long run, and it'd be immediately > >>>> obvious that these source files form a single "unit". > >>> > >>> What would be the folder name? Because, for example, intel_cht_int33fe* have no > >>> folder (yet?) and here it's kinda similar case when HID describes something > >>> else than just one IP. > >> > >> I think "intel_skl_int3472" would not be a bad name for the folder. And I believe > >> "intel_cht_int33fe" could be given its own folder as well. > > > > I;m not objecting (at some point in the past I had proposed moving Intel stuff > > to a separate folder, but at that time PDx86 has no folders at all and Darren > > was kinda not in favour of creating ones, but things changed), just let's hear > > Hans on this. > > I'm in favor of using a folder for this and "intel_skl_int3472" is fine with me. > > With that said I'm not entirely sure if I'm in favor of the _skl_ part of > the folder and driver name or not. > > The INT3472 ACPI device is used with other CPUs, e.g. Apollo Lake too and > I think the driver should work fine with those. It should work on Kabylake as well, although there are some differences in the way the INT3472 device is modelled in the DSDT between those two platforms. Hopefully nothing that couldn't be supported in a single driver without adding too many hacks. > The intel_cht_int33fe case is special because the driver only applies > to some models with an INT33FE ACPI device (the whole INT33FE ACPI device > is a horrible thing which seems to stem from Intel rushing Bay Trail to > market to try and compete on the tablet market). The INT3472 ACPI device is also horrible. It reminds me of Intercal, the programming language that was created by gathering features of several well known languages and then making sure that none of them would be used: the ACPI model of the device was probably created by someone who has studied ACPI extensively and decided to break every single best practice rule. I lack English words strong enough to express my dismay on this topic (but I still have hope to find solace in Finnish). > With that all said SKL probably is the first SoC to feature this and I > guess future IPUs may still use INT3472 given Intel's BAD habit of > re-using ACPI HIDs for multiple incompatible generations. So I guess > that keeping it is fine; and if we then need an incompatible INT3472 > driver for newer IPUs we can use a different prefix for those. > > TL;DR: > > 1. Using a folder is fine, desirable even > 2. I've some concerns about the name, but I'm not really objecting, > just giving my 2 cents. -- Regards, Laurent Pinchart
