Re: [PATCH v3 4/6] iio: imu: bmi270: Add support for BMI260

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 25, 2024 at 08:42:59AM -0700, Justin Weiss wrote:
> Jonathan Cameron <jic23@xxxxxxxxxx> writes:
> > On Tue, 22 Oct 2024 19:54:03 +0300
> > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> >> On Tue, Oct 22, 2024 at 08:50:43AM -0700, Justin Weiss wrote:
> >> > Justin Weiss <justin@xxxxxxxxxxxxxxx> writes:

...

> >> > I can't find any evidence of BOSC0260 being used, besides existing in
> >> > the Windows driver. As suggested in an earlier review, I added it here
> >> > to encourage people looking at this driver in the future to use the
> >> > correct ACPI ID.  
> >> 
> >> Are you official representative of Bosch or do you have a proof by the vendor
> >> that they allocated this ID? Otherwise we may NOT allocate IDs on their behalf
> >> and has not to be added.
> > Fair point. The provenance of the driver is a little disconnected from Bosch:
> > https://ayaneo-1305909189.cos.accelerate.myqcloud.com/ayaneo_com/download/2023/UMDF2.0_BMI260_V1.0.23_5ID_signed_20H1.zip
> >
> > Justin, if you have contacts at ayaneo, maybe they can confirm if the IDs come
> > from Bosch. Or maybe we can find someone at Bosch?
> 
> I've asked around a bit but haven't been able to find a contact at Bosch
> to help answer these questions. I also haven't heard back from AYANEO.

Hmm... Maybe we can grep for the added BOSC IDs in the kernel and see if it
gives any contacts / clues whom to contact, but I'm not insisting you to go
this way, only if you want to.

> In the meantime, I can reorder the patches to add the triggers and
> attributes first and leave the BMI260 support / ACPI ID additions at the
> end.
> 
> I'll include the BMI0160 ID (and DSDT) in the patch adding the initial
> support, since we know that one exists in the wild, and hold on adding
> BOSC0260 until there's a way to move forward on it.

Sounds like a plan!

> I'll also remove all ACPI IDs from the SPI driver since we haven't seen
> them at all yet. If we get clarification on the correct ACPI IDs to use,
> we can add it later on.

Since ACPI has the different resource types for these busses it's usually okay
to have the same ID in both, but there is no special requirement for following
or not following that. And taking a history of fake ACPI IDs in the past,
I would go defensive way as you put it here, i.e. no ID should be added until
we have a proof of them being used in the real products.

-- 
With Best Regards,
Andy Shevchenko






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux