* Lokesh Vutla [off-list ref] [190214 17:32]:

Hi Tony,
	Please do not snip the on going discussion.

On 2/14/2019 9:11 PM, Tony Lindgren wrote:

quoted

* Lokesh Vutla [off-list ref] [190214 08:39]:

quoted

IMHO, device ids are something which can be used in DT. There are many other
things like the interrupt ranges etc.. which are discoverable from sysfw and we
are implementing it.

We need to describe hardware in the device tree, not firmware.

If you have something discoverable from the firmware, you should
have the device driver query it from sysfw based on a hardware
property, not based on some invented enumeration in the firmware.

Yes we are already querying sysfw for all the irq ranges that can be
discoverable. The topic of discussion here is about the parent interrupt
controller id. I am not sure how you are expecting an id be discoverable
from system firmware especially with a name.

Well names are quite standard in dts (but should be used with
the phandle + offset). Think for example interrupt-names and
reg-names :)

quoted

If there is some device to firmware translation needed, hide that
into the device driver and keep it out of the device tree.

If preferred this can be moved to of_match_data attached to each
compatible property. Then for each SoC a new compatible needs to be created.

Hiding the ID into the device driver and compatible property
makes sense to me if the id is based on SoC + firmware.

But I'd rather have a proper hardware based phandle + index
type mapping in the dts if possible though.

What does this id really consist of?

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel