+ if (!val1 && !val2)
+ break;
+
+ addr = buf2[1] | (buf2[0] << 8) | (buf1[3] << 16) |
+ ((u64)buf1[2] << 24) | ((u64)buf1[1] << 32) |
+ ((u64)buf1[0] << 40);
+
+ sdw_extract_slave_id(bus, addr, &id);
+ /* Now compare with entries */
+ list_for_each_entry_safe(slave, _s, &bus->slaves, node) {
+ if (sdw_compare_devid(slave, id) == 0) {
+ u32 status = qcom_swrm_get_n_device_status(ctrl,
i);
+ if (status == SDW_SLAVE_ATTACHED) {
+ slave->dev_num = i;
+ mutex_lock(&bus->bus_lock);
+ set_bit(i, bus->assigned);
+ mutex_unlock(&bus->bus_lock);
+
+ }
And that part is strange as well. The bus->assigned bit should be
set even if the Slave is not in the list provided by platform
firmware. It's really tracking the state of the hardware, and it
should not be influenced by what software knows to manage.
Am not 100% sure If I understand the concern here, but In normal
(non auto enum) cases this bit is set by the bus code while its
doing enumeration to assign a dev number from the assigned bitmap!
However in this case where auto enumeration happens it makes sense
to set this here with matching dev number!
AFAIU from code, each bit in this bitmap corresponds to slave dev
number!
Yes, but the point was "why do you compare with information coming
from platform firmware"? if the hardware reports the presence of
devices on
This is the logic that hardware IP document suggests to use to get
get the correct the device number associated with the slave!
the link, why not use the information as is?
You recently added code that helps us deal with devices that are not
listed in DT or ACPI tables, so why would we filter in this specific
loop?
I don't think my point was understood, so let me try to explain it
differently.
it's my understanding that the hardware reads the DevID registers and
writes a Device Number - so that the entire enumeration sequence
started by reading DevID0 and finished by a successful write to
SCP_DevNum is handled in hardware.
The question is: what happens if that device is NOT described in the
Device Tree data? The loop over bus->slaves will not find this device
by comparing with known devID values, so the set_bit(i, bus->assigned)
will not happen.
yes, that is true, There is no way we can assign a dev_number to the
device which is not enumerated on the bus!
Am sure this is the same behavior with soundwire core too, atleast form
the code I can see it sets the assigned bit for only the devices that
are enumerated on the bus! Not all the devices specified in DT!
Unless I missed something!
I am talking about the other way around, where a device is present and
enumerated on the bus but not listed in DT. In that case the hardware
did assign a device number but bus->assigned will not be set.
