linux-kernel - Re: [PATCH 2/2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0100016022e49231-8c4ef123-bd0d-49b4-a217-0d81100ce322-000000@email.amazonses.com>
Date:   Mon, 4 Dec 2017 18:58:13 +0000
From:   Jeremy Cline <jeremy@...ine.org>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Hans de Goede <hdegoede@...hat.com>,
        Lars Kellogg-Stedman <lars@...bit.com>,
        Steven Presser <steve@...ssers.name>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Wolfram Sang <wsa@...-dreams.de>
Subject: Re: [PATCH 2/2] iio: accel: bmc150: Check for a second ACPI device
 for BOSC0200

On Sat, Dec 02, 2017 at 12:19:27PM +0000, Jonathan Cameron wrote:
> > diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h
> > index c38754452883..7f49a09b136f 100644
> > --- a/drivers/iio/accel/bmc150-accel.h
> > +++ b/drivers/iio/accel/bmc150-accel.h
> > @@ -47,6 +47,7 @@ struct bmc150_accel_data {
> >  	int ev_enable_state;
> >  	int64_t timestamp, old_timestamp; /* Only used in hw fifo mode. */
> >  	const struct bmc150_accel_chip_info *chip_info;
> > +	void *driver_priv;
> 
> I'd be explicit about what this is rather than just calling it driver_priv.

Ah, okay. I was worried about putting i2c-specific stuff in there.

> Also patch 1 was entirely to expose this data element.  Adding simple
> bmc150_get_second_device() / bcm150_set_second_device call would avoid that.

That hadn't occurred to me. I'll take a look at doing it that way.

Thanks for the feedback!

Regards,
Jeremy