[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ed9d28e0-f879-41f3-8679-7ed5e0eec7ce@linaro.org>
Date: Wed, 6 Dec 2023 18:56:35 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Guenter Roeck <linux@...ck-us.net>
Cc: Billy Tsai <billy_tsai@...eedtech.com>, jdelvare@...e.com,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
joel@....id.au, andrew@...id.au, corbet@....net,
thierry.reding@...il.com, p.zabel@...gutronix.de,
naresh.solanki@...ements.com, linux-hwmon@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-pwm@...r.kernel.org,
BMC-SW@...eedtech.com, patrick@...cx.xyz
Subject: Re: [PATCH RESEND v10 0/3] Support pwm/tach driver for aspeed ast26xx
On 06/12/2023 18:48, Uwe Kleine-König wrote:
> On Tue, Nov 07, 2023 at 11:02:43AM -0800, Guenter Roeck wrote:
>> On 11/7/23 02:50, Billy Tsai wrote:
>>> Unlike the old design that the register setting of the TACH should based
>>> on the configure of the PWM. In ast26xx, the dependency between pwm and
>>> tach controller is eliminated and becomes a separate hardware block. One
>>> is used to provide pwm output and another is used to monitor the frequency
>>> of the input. This driver implements them by exposing two kernel
>>> subsystems: PWM and HWMON. The PWM subsystem can be utilized alongside
>>> existing drivers for controlling elements such as fans (pwm-fan.c),
>>> beepers (pwm-beeper.c) and so on. Through the HWMON subsystem, the driver
>>> provides sysfs interfaces for fan.
>>>
>>> Changes since v9:
>>> Change the type of fan-driving-mode to string
>>> Fix some typos and formatting issues.
>>>
>>
>> What is the resend about ?
>
> And to the original v10 there is a reply by Krzysztof;
> see https://lore.kernel.org/linux-pwm/3d9e50db-19f0-43b3-8042-2f80a1e7b79e@linaro.org/ .
>
> I'll mark the original and this resend as "changes-requested" in our
> patchwork. Probably the most cooperative way to object is to send a v11
> and point out the changes compared to v10.
The resend might be fixing issues from v10, but who knows which and how
many. In any case it should be v11, not a resend.
Best regards,
Krzysztof
Powered by blists - more mailing lists