12:05 <mort> Does anyone publish end-user-targeted changes to devicetree stuff? Something like, "<date>: msm8916.dtsi changed how USB configuration works. Instead of a separate `phy` node, consumers should now define all the properties on the `usb` node." or something

12:07 <jn> it might be in some of the commit messages

12:08 <jn> which is fair, IMO, because it's still targetted at developers (of board dts files), which i wouldn't consider end-users

12:09 <mort> I was hoping for something slightly more targeted at the consumers of dtsi files

12:10 <mort> imagine going through all of https://github.com/torvalds/linux/commits/master/arch/arm64/boot/dts/qcom/msm8916.dtsi, analyzing each commit closely, until you find

12:10 <mort> https://github.com/torvalds/linux/commits/master?after=614124bea77e452aa6df7a8714e8bc820b489922+69&branch=master&path%5B%5D=arch&path%5B%5D=arm64&path%5B%5D=boot&path%5B%5D=dts&path%5B%5D=qcom&path%5B%5D=msm8916.dtsi, and notice that you will have to change your own sdhci nodes to match the dtsi's removal of a leading zero

12:11 <mort> that's *a lot* of work just for a kernel upgrade

12:11 <mort> but I suppose it's just inherently difficult to upgrade a linux kernel

12:13 <jn> your second link somehow didn't point at the right thing

12:13 <mort> oh, weird

12:13 <jn> anyway, yes, that's the pain of downstream development :(

12:13 <mort> https://github.com/torvalds/linux/commit/d8bcaabee40521b33af8ab9b44b5df56eb4cd929#diff-d5be6e8b9eb729f7f7cbd493a22b184acdbb3814cce67d1e938cf651f7abc9f2

12:13 <mort> does that work

12:14 <mort> maybe I copied the wrong thing, who knows

12:14 <jn> you can possibly mitigate it a bit in this case, by using phandles instead of paths

12:14 <jn> &sdhc_1 { ... }; instead of sdhci@7824000 { ... }

12:15 <mort> our dts is based mostly on our soc vendor's dts

12:16 <mort> going through the history of that might be a better idea than going through the history of the included dtsi files

12:16 <jn> true

12:16 <mort> (that has been renamed over time though, which makes it really fun to read through the history)

12:18 <jn> (ah, i forgot to answer: yes, the last link works)

14:51 <mripard> broonie: how do you want to merge the hdmi-codec between alsa/asoc and DRM?

14:52 <broonie> Like I said a pull request for the shared bit would be good.

14:54 <mripard> yeah, but who should do it? I'd assume you don't want to pull the entire DRM stuff

14:55 <mripard> or should I send a PR to both DRM and you?

14:56 <broonie> I was expecting you to apply everything and send me a tag with just the subset that needed to be shared.

14:56 <broonie> (you or whoever applies things to DRM, that's all super confusing)

14:59 <mripard> ack, I'll do that then

14:59 <mripard> thanks!

15:04 <broonie> Basically it looked like mainly a DRM series.

15:18 <mort> I have a USB device which shows up in `lsusb` (Bus 001 Device 003: ID 1286:2052 Marvell Semiconductor, Inc.). In theory, it should work with the driver mwifiex_usb, but 1) mwifiex_usb isn't loaded automatically, and 2) it doesn't get used when I manually load mwifiex_usb. Is there some nice way to debug why the driver doesn't detect the USB device

15:18 <mort> it should be driving?

15:57 <mkl_> mort: modinfo mwifiex_usb|grep 2052

15:58 <mkl_> mort: does 2052 show up in the modinfo output?

17:15 <mort> mkl_: yeah, it's in an alias line

17:15 <mort> mkl_: https://p.mort.coffee/qWo