Hi Jakub, On Mon, May 11, 2020 at 04:40:05PM +0300, Andy Shevchenko wrote: > On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > On 5/11/20 1:44 PM, Andy Shevchenko wrote: > > ... > > > > I would rather disable them and issue a firmware bug. > > > Vendors, including us, should do something sane about this. > > > > I have to partially disagree here. I agree that for future hardware > > versions the firmware team of those devices should offer a saner > > interface. But for the current hardware gen I guess we are stuck > > with this and having a DMI table for popular models (well any model > > a Linux user is willing to submit a quirk for) is better then simply > > not having things working under Linux. > > > > I do wonder what Windows does here though. Perhaps the INT3513 device > > has some ACPI methods to query for more info, like how many Type-C > > controllers there actually are? > > I think they do silly things there in usual obscure MS way, i.e. > hardcoding everything in the driver per platform. > That's why I'm really disappointed how things are going on. I've been trying to figure out which exact NUC10i3 your NUC is? I can't find a NUC10i3 that uses Comet Lake -S? If your NUC isn't actually "-S" variant, then the ACPI device entry with HID INT3515 should return 0 from its _STA method. But can you please share the full name of your board (like NUC10i3FNH or something like that - should read on the bottom of the device). Also, dmesg output would be useful. thanks, -- heikki
