linux-kernel - Re: [v14 0/2] Support pwm driver for aspeed ast26xx

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: <Ya/P+4CNTnUUqlG9@robh.at.kernel.org>
Date:   Tue, 7 Dec 2021 15:19:55 -0600
From:   Rob Herring <robh@...nel.org>
To:     Joel Stanley <joel@....id.au>
Cc:     Billy Tsai <billy_tsai@...eedtech.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Jean Delvare <jdelvare@...e.com>,
        Andrew Jeffery <andrew@...id.au>,
        Lee Jones <lee.jones@...aro.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Uwe Kleine-Konig <u.kleine-koenig@...gutronix.de>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        linux-hwmon@...r.kernel.org,
        devicetree <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-aspeed <linux-aspeed@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-pwm@...r.kernel.org, BMC-SW <BMC-SW@...eedtech.com>
Subject: Re: [v14 0/2] Support pwm driver for aspeed ast26xx

On Tue, Dec 07, 2021 at 06:45:47AM +0000, Joel Stanley wrote:
> Hi Billy,
> 
> On Tue, 30 Nov 2021 at 05:58, Billy Tsai <billy_tsai@...eedtech.com> wrote:
> >
> > The legacy driver of aspeed pwm is binding with tach controller and it
> > doesn't follow the pwm framworks usage. In addition, the pwm register
> > usage of the 6th generation of ast26xx has drastic change. So these
> > patch serials add the new aspeed pwm driver to fix up the problem above.
> 
> Sorry for not taking a look earlier. Well done on making it this far.
> 
> There's a few things that need to be addressed before merging this.
> 
> Firstly, the bindings need fixing up. I think these should be the one
> file. The device tree bindings are supposed to describe the hardware,
> and it doesn't make sense to separate them out just because we plan on
> using two subsystems to implement the functionality.
> 
> Rob, please chime in if you would prefer something different.

I prefer to see a common binding for fans which I said multiple times 
on this series. As the same thing keeps getting posted, I've stopped 
looking at this one.

Rob