On Sun, Aug 19, 2018 at 06:31:32PM +0100, Jonathan Cameron wrote:
> On Sat, 11 Aug 2018 15:48:33 +0530
> Himanshu Jha <himanshujha199640@xxxxxxxxx> wrote:
>
> > On Tue, Aug 07, 2018 at 05:06:05PM +0300, Alexandru Ardelean wrote:
> > > Fixes ef89f4b96a2 ("iio: adxl345: Add support for the ADXL375").
> > >
> > > This was found via static checker.
> > > After looking into the code a bit, it's unlikely that there will be a NULL
> > > dereference if the `id` object in that specific code path.
> > > However, it's safe to add a NULL (paranoid) check just to make sure and
> > > remove any uncertainties.
> >
> > I would like to know when would that case happen actually ?
> >
> > Because probe will only be called only when a match occurs either
> > through DT or id matching. Isn't it ?
> >
> Yes. Alternative would have just not been to check it, but this is fine
> so applied. I'm not going to rush this through stable though given
> I don't think it can actually happen.
Thanks for the confirmation.
So, I have another doubt and it seems to be right time to ask.
BME680 currently supports both ACPI matching and traditional ID
matching. So, it there any priority list to which patch the driver
would choose to match the device.
ACPI > ID matching ? (In my case this happens)
Because this matching tends to decide the `name` attribute of loaded
driver.
For ACPI: BME0680 (not sure maybe it was I2C0:BME0680)
For ID: bme680
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology
