On Thu, Jan 25, 2024 at 12:55:12PM +0100, esben@xxxxxxxxxx wrote: > Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> writes: > > > On 25/01/2024 10:10, esben@xxxxxxxxxx wrote: > >> Conor Dooley <conor@xxxxxxxxxx> writes: > >> > >>> On Wed, Jan 24, 2024 at 03:33:06PM +0100, Esben Haabendal wrote: > >>>> Time Based Scheduling can be enabled per TX queue, if supported by the > >>>> controller. > >>> > >>> If time based scheduling is not supported by the controller, then the > >>> property should not be present! The presence of a property like this > >>> should mean that the feature is supported, using it is up to the > >>> operating system. > >>> > >>> That said, why is this a property that should be in DT? > >> > >> It is added to the tx-queues-config object of snps,dwmac bindings. This > >> entire object is about configuration of the ethernet controller, which > >> is also what the purpose of the snps,time-based-scheduling. > >> So yes, it is not specifically about describing what the hardware is > >> capable of, but how the hardware is configured. It is a continuation of > >> the current driver design. > >> > >>> If support is per controller is it not sufficient to use the > >>> compatible to determine if this is supported? > >> > >> Are you suggesting to include the mapping from all supported compatible > >> controllers to which TX queues supports TBS in the driver code? What > >> would the benefit of that compared to describing it explicitly in the > >> binding? > > > > The benefit is complying with DT bindings rules, saying that bindings > > describe hardware pieces, not drivers. > > Understood. > > >> And for the purpose of the above question, I am talking about it as if > >> the binding was describing the hardware capability and not the > >> configuration. > > > > "if"? You wrote it is for driver design... > > If you look at the current driver, all the devicetree bindings under > rx-queues-config and tx-queues-config are violating the DT binding > rules. > Cleaning up that requires quite some work and I guess will break > backwards compatibility to some extend. Let bygones be bygones. If something undesirable got in previously, breaking backwards compatibility there is not justified IMO.
Attachment:
signature.asc
Description: PGP signature