On 1/23/24 08:39, Krzysztof Kozlowski wrote: > 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. Okay, thanks for the explanation. > > However I don't fully understand why that dependency - except patch hunk > context - exists. You shouldn't have such dependency. > Let me try offline, I'll get back to you.
