Hi,
On 6/30/23 16:45, Andy Shevchenko wrote:
>> + sensor->lanes = gmin_cfg_get_int(adev, "CsiLanes", lanes);
>> + if (sensor->lanes > IPU_MAX_LANES) {
>> + dev_err(&adev->dev, "Invalid lane-count: %d\n", sensor->lanes);
>
> Yeah, I think we would be consistent in using the ACPI handle to print
> the messages from ACPI sensor devices.
I do agree that we need to be consistent, but I regret having switched
to using the handle for this in the csi2-bridge code. The dmesg logs
this results in are much harder to read. Most devices typically have
2 different sensors and normally it is quite easy to see in the logs
which GPIOs, etc. are being used for the sensor.
But after the move to using the ACPI handle for logging the logs
show up prefixed with \_SB_.I2C2.CAM8 resp CAM2 rather then with
OVTI2680 and INT0310 making it much harder to figure on what
is going on (first need to do
"cat /sys/bus/i2c/devices/i2c-OVTI2680:00/firmware_node/path"
to find out which path belongs to which sensor).
So I would rather get rid of the handle based logging, because it
is very cumbersome to use.
I'll add an extra patch to the next version of the set to switch all
the logging to using the acpi_device for logging.
Regards,
Hans
