linux-kernel - Re: [GIT PULL] Staging/IIO driver fixes for 5.11-rc5

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] [day] [month] [year] [list]

Date:   Thu, 28 Jan 2021 19:45:51 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        devel@...uxdriverproject.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        William Breathitt Gray <vilhelm.gray@...il.com>
Subject: Re: [GIT PULL] Staging/IIO driver fixes for 5.11-rc5

On Mon, 25 Jan 2021 15:08:17 +0100
Greg KH <gregkh@...uxfoundation.org> wrote:

> On Sun, Jan 24, 2021 at 11:31:59AM -0800, Linus Torvalds wrote:
> > On Sun, Jan 24, 2021 at 4:58 AM Greg KH <gregkh@...uxfoundation.org> wrote:  
> > >
> > > David Lechner (1):
> > >       counter:ti-eqep: remove floor  
> > 
> > I'm not sure why that ti-eqep counter driver seems to be in your
> > "iio/staging" pile rather than "char/misc", but whatever..  
> 
> Jonathan said why that was needed, I think it was due to fixes in the
> counter core code, but he can verify this better than I can...

Hi Linus / Greg,

Bit of history involved here...

The counter drivers started out as just another sensor type
under IIO, but ended up pushing the boundaries of the ABI a lot -
ultimately making it clear that they really didn't fit in IIO.
William came up with a better abstraction / framework that
became drivers/counter/, but currently the patch flow for
drivers/counter/ is sufficiently low that I handle their
patches along side IIO rather than via a separate tree.

There is also a cross dependency because of legacy IIO ABI
though we are aiming to drop that either this cycle or next.

Hope that clears it up.  If either of you would prefer
it a different way in future let me know.

This particular fix was local to the driver - it was pretending
it supported something that hardware couldn't actually do.

Thanks,

Jonathan

> 
> thanks,
> 
> greg k-h