On Tue, Jul 4, 2023 at 10:21 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 6/30/23 16:45, Andy Shevchenko wrote: ... > >> + 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 see, you are right. The ACPI handle may not be the best for Linux kernel drivers. > 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. Sounds good. -- With Best Regards, Andy Shevchenko
