Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757089AbcLOXHk (ORCPT ); Thu, 15 Dec 2016 18:07:40 -0500 Received: from mail-qk0-f182.google.com ([209.85.220.182]:33966 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755915AbcLOXHi (ORCPT ); Thu, 15 Dec 2016 18:07:38 -0500 MIME-Version: 1.0 In-Reply-To: <20161214114051.GC14217@n2100.armlinux.org.uk> References: <1481702104-8617-1-git-send-email-jaghu@google.com> <1481702104-8617-5-git-send-email-jaghu@google.com> <3917905.e4iOqADnVQ@wuerfel> <10697525.O7CkPN6Gfl@wuerfel> <20161214110635.GB14217@n2100.armlinux.org.uk> <20161214114051.GC14217@n2100.armlinux.org.uk> From: Linus Walleij Date: Fri, 16 Dec 2016 00:07:36 +0100 Message-ID: Subject: Re: [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius To: Russell King - ARM Linux Cc: Arnd Bergmann , Mark Rutland , Jaghathiswari Rankappagounder Natarajan , "devicetree@vger.kernel.org" , Greg KH , OpenBMC Maillist , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Rob Herring , Joel Stanley , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1204 Lines: 31 On Wed, Dec 14, 2016 at 12:40 PM, Russell King - ARM Linux wrote: > Looking at this more, it's a SPI driver, presumably because the first > case where it appeared was on a SPI bus. > > However, it's not a SPI device as such, it's a piece of standard, > general purpose logic that's been around for many years, pre-dating > the SPI bus. Indeed. > I think a much more sensible approach would be to turn the GPIO side > of the 74x164 driver into a library, which can be re-used by multiple > bus-specific drivers - one for SPI which allows it to be used in its > current form, one for our platform bus which takes the GPIO lines for > the data, clock and clear signals. > > I also don't see why they shouldn't use the same compatible - they're > the same _device_ at the end of the day, just wired up differently. > It makes the binding documentation a little fun wrt what are required > and optional properties, but nothing that shouldn't be too difficult. I agree on both accounts. Sorry for not seeing this in the first place, I was well aware that this is a standard component and may be connected in a myriad of ways, so I should have known better :( Yours, Linus Walleij