linux-kernel - Re: [PATCH V5 0/6] Raspberry Pi Sense HAT driver

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: <ff321353fa27a156a0eab9cc9674dfad760f22a8.camel@redhat.com>
Date:   Mon, 13 Dec 2021 12:29:52 +0100
From:   Nicolas Saenz Julienne <nsaenzju@...hat.com>
To:     Charles Mirabile <cmirabil@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     Serge Schneider <serge@...pberrypi.org>,
        Stefan Wahren <stefan.wahren@...e.com>,
        Mattias Brugger <mbrugger@...e.com>,
        linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, fedora-rpi@...glegroups.com,
        Mwesigwa Guma <mguma@...hat.com>,
        Joel Savitz <jsavitz@...hat.com>
Subject: Re: [PATCH V5 0/6] Raspberry Pi Sense HAT driver

Hi Charles, Thanks for iterating on this.

On Fri, 2021-12-10 at 17:10 -0500, Charles Mirabile wrote:
> Suggestions from v4 not addressed yet:
> 	- Use mfd_cells for the joystick and display platform devices
> 	  (as suggested by Matthias Brugger) or remove sensehat-core.c
> 	  entirely and use simple-mfd-i2c instead (as suggested by
> 	  Nicolás Sáenz Julienne).
> 	  	- while these suggestions might make great improvements
> 	  	  for a version two of the driver they would require a
> 	  	  large rewrite to move all of the complexity in core
> 	  	  elsewhere. While certainly possible and something
> 	  	  we want to iterate on and achieve eventually, we
> 	  	  think saving it for down the road makes sense at this
> 	  	  time.

Sorry for insisting, but I'm not convinced by this approach. The way you design
your driver affects its devicetree bindings, once we settle on those any
upgrade will have to be backwards compatible (i.e. an old DT would have to work
with the new implementation). This makes changing this further down the road
unlikely.

In terms of complexity, most of it is there due to not using the APIs and
facilities the mfd subsystem provides. See my comments in the driver.

Regards,

-- 
Nicolás Sáenz