00:18 <steev> it looks like they do boarid-whatever for the chromeos ones, so maybe that instead?

01:51 <robclark> I guess in theory as long as the dt and firmware path agree it should be all good (assuming you don't end up with conflicts with differently signed fw for a given laptop).. and yeah, I've been pushing to get CrOS to follow (modulo not dmi) that approach so that a single /lib/firmware could work on multiple devices

02:48 <steev> i'm not familiar with the other aarch64 laptops in the topic, but my understanding is that they all require signed firmwares, sadly, so they can't intermingle

02:58 <steev> it would be nice, since most of them are EOL, if they didn't still require signed firmware, but i'm guessing that's far too much to ask

03:15 <bamse> robclark: right, it could be named whatever...but it seems we might be able to set some precedence in linux-firmware...

03:16 <bamse> robclark: one question that i'm sure someone will ask is "why keep the qcom/ part in there", what's your opinion on the google firmware wrt to that?

03:16 <robclark> agreed on that

03:17 <robclark> I'm not sure why we wouldn't keep "qcom" in the path.. but otoh I've just been pushing people to follow the upstream qcom windows laptop precedent ;-)

03:17 <bamse> the good thing with keeping it in qcom/LENOVO, qcom/google etc is that i see a few distros that has split linux-firmware/qcom into a separate linux-firmware-qcom package

03:18 <bamse> to reduce the size of that thing

03:18 <bamse> and keeping it all in qcom/ i think would make it simpler to find the right package

03:18 <robclark> yeah, makes sense

03:18 <bamse> i.e. it's just always linux-firmware + linux-firmware-qcom for all our devices

03:19 <bamse> then i'll stick to that as my reasoning and continue with the qcom/LENOVO/<dmiid>/ plan

03:19 <robclark> +1

03:19 <bamse> thanks :)

16:00 <steev> bamse: robclark: the other option would be to do something similar to what brcmfmac devices do, which is use a specific name, and then fall back to the more generic versions if they don't exist, so whatever firmware grabbing scripts we pass out, or tell people to use would copy the files over to e.g. qcom/sdm845/qcdxkmsuc850,lenovo-81jl.mbn qcom/sc8180x/qcdxkmsuc8180x,lenovo-82ak.mbn

16:02 <robclark> IIRC we didn't do fallback to generic because using wrongly signed fw (in at least some cases) would silently fail followed by "bad things"(TM).. or something along those lines

16:03 <steev> oh, right

16:03 <robclark> anyways, I'd advocate following the existing approach rather than introducing a new standard ;-)

16:04 <steev> i forgot that bad things happen :)

16:07 <robclark> there are also some cases where fw is kinda "optional".. ie. zap fw is not used on CrOS devices.. the driver figures that out by lack of firmware-name property in dt..

16:07 <robclark> so wouldn't want to try to fallback to default in that case either

16:12 <steev> true

16:44 <steev> bamse: can i have aux-bus stuffs? :D