On 23/01/2024 09:34, Tudor Ambarus wrote: > > > On 1/23/24 07:52, Krzysztof Kozlowski wrote: >> On 19/01/2024 12:11, Tudor Ambarus wrote: >>> USI8 I2C is used to communicate with an eeprom found on the battery >>> connector. Define USI8 in I2C configuration. >>> >>> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8 >>> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the >>> selection of the protocol is intentionally left for the board dts file. >> >> ... and dropped, because this patch does not build: >> https://krzk.eu/#/builders/29/builds/3869 >> and I missed weird dependency mentioned in cover letter: >> >> "This patch set shall be queued after the cmu_misc clock name fixes from:" >> >> Sorry, this cannot work like that. DTS for new features cannot build >> depend on driver changes. > > No worries. What shall I do so that you re-consider the dropped patches? > I'm not yet familiar with your release management, but I guess that if > you submit your "fixes-clk" branch for integration into v6.8-rc2, and > then merge v6.8-rc2 into your "next/dt64", you'll then be able to queue > the dropped patches as well. It is nothing specific to my release management but years old rule: DTS branch cannot contain driver commits. It is nothing new, discussed on mailing lists for various SoC architectures many times. However I don't fully understand why that dependency - except patch hunk context - exists. You shouldn't have such dependency. Best regards, Krzysztof
