HI, On Wed, Mar 20, 2013 at 3:10 AM, Sylwester Nawrocki <sylvester.nawrocki@xxxxxxxxx> wrote: > On 03/18/2013 04:50 PM, Rob Herring wrote: >> >> On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: >>> >>> On 03/13/2013 03:39 PM, Rob Herring wrote: >>>> >>>> I fail to see what the hack is. The order of interrupt properties must >>>> be defined by the binding. interrupt-names is auxiliary data and must >>>> not be required by an OS. >>> >>> >>> It is clear that the order of the interrupts must be defined by the >>> bindings. But how useful<resource>-names properties are when we >>> cannot define them as required ? If an OS cannot rely on them then >>> it must use some other, reliable, method to identify the resources, >>> e.g. by hard coding the indexes. If we have to do it then why even >>> bother with the<resource>-names properties ? I can see interrupt-names >>> property specified as required in at least 2 bindings' documentation >>> and all bindings having reg-names property define it as required. >>> Are they wrong them ? >> >> >> You can require the name for a binding definition, but that does not >> remove the requirement that the order and index of interrupts also be >> defined by the binding. Then it is up to the OS to use names or >> hard-coded indexes. Hard-coded indexes are not a hack. This is how FDT >> and OF are defined to work. > > > OK, that makes it all crystal clear for me, thanks. > > >> I'm still not clear how changing the order of the interrupts removes a >> hack. > > > Originally the binding in question was not specifying the interrupt > order at all. And the drivers required order of the interrupt resources > different than in what they were normally defined in the SoC interrupt > combiner. So I suggested to use the interrupt-names property to make it > all more explicit and less error prone. I once had to fix the order of > the FIMD interrupts in the device tree to make the display work, since > I used a patch where the interrupts were listed in the IRQ combiner order, > and not the order expected by the driver. > > I wasn't really clear then whether the order of interrupts needs to be > still fixed by the binding when the interrupt-names property was used. > > That said I don't think there was previously any hack there. Just an > undocumented expected order of the interrupts in DT, different than the > normal order in the IRQ combiner. So it is really hard to agree with > what's written in the $subject patch description as it is now. > Yes, there was NO hack as such earlier, just the documentation was not clear. But IMO, as suggested by Sylwester using "interrupt-names" property makes it more explicit and less error prone. Regarding this patch, it will be abandoned, Leela will post a single patch by squash this patch and https://patchwork.kernel.org/patch/2184981/ > Thanks, > Sylwester > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |