On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote: > On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote: > > Add documentation for the new optional flag added for SRAM driver. > > > diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml > > > + reserved-only: > > + description: > > + The flag indicating, that only SRAM reserved regions have to be remapped. > > + remapping type is selected depending upon no-memory-wc as usual. > > + type: boolean > > This feels a bit like a SW flag rather than a HW description, so I'm not > sure it's appropriate to put it into DT. Reserved regions themselves are software descriptions, no? Then we have 'pool' flag which is again a software flag and so on. This flag falls into same category and nothing out of ordinary. > > Are there any cases where the SW should map all of the SRAM, i.e. where > we wouldn't expect to set reserved-only? [...] Yes, here are a few examples: arch/arm/boot/dts/aspeed-g*.dtsi arch/arm/boot/dts/at91*.dtsi arch/arm/boot/dts/bcm7445.dtsi Then arch/arm/boot/dts/dra7.dtsi is an example where we should map everything except the reserved region. > [...] I'd expect reserved-only to be > the default, and perhaps only, mode of operation for the SRAM driver. It will break compatibility with existing dtbs. > If we can't do that because some SW currently expects to be able to map > arbitrary portions of the SRAM, shouldn't that SW be fixed to tell the > SRAM driver which parts it's using, hence still allowing the driver to > only map in-use portions? User doesn’t need sram driver in that case. It can use genalloc api directly. BR, Yousaf
