From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>,
Thierry Reding <thierry.reding@gmail.com>,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-pwm@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v2 4/6] pwm: lpss: Allow other drivers to enable PWM LPSS
Date: Fri, 11 Nov 2022 15:50:50 +0200 [thread overview]
Message-ID: <Y25TOsMCQEezhnN0@smile.fi.intel.com> (raw)
In-Reply-To: <20221110102317.ea64tgqd77kvygvt@pengutronix.de>
On Thu, Nov 10, 2022 at 11:23:17AM +0100, Uwe Kleine-König wrote:
> On Thu, Nov 10, 2022 at 11:58:53AM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 10, 2022 at 9:28 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > > On Tue, Nov 08, 2022 at 04:22:24PM +0200, Andy Shevchenko wrote:
> > > > The PWM LPSS device can be embedded in another device.
> > > > In order to enable it, allow that drivers to probe
> > > > a corresponding device.
...
> > > Now that pwm_lpss_boardinfo lives in a different file, this makes the
> > > move of pwm_lpss_chip in patch 3 somewhat redundant.
> >
> > But they are independent changes. At each stage (after each patch) we
> > should have a finished step, right? Not touching that makes me feel
> > that the step is half-baked. If you insist I can drop that move from
> > the other patch.
>
> Given that the move is something you do just en passant in the earlier
> patch , I consider my suggestion cleaner. I'd call that 0.5 * insist.
I have looked again and I have noticed that in the current state we have
sturct pwm_lpss_chip {
...
};
struct pwm_lpss_boardinfo {
...
};
extern struct pwm_lpss_boardinfo ...;
In the proposed change (with move included) it becomes
#include <...>
extern struct pwm_lpss_boardinfo ...;
sturct pwm_lpss_chip {
...
};
and without
#include <...>
sturct pwm_lpss_chip {
...
};
extern struct pwm_lpss_boardinfo ...;
And I consider that my way is slightly better in terms of ordering.
That said, I will leave it as is for v3. We may continue discussing
it further there.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-11-11 13:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 14:22 [PATCH v2 0/6] pinctrl: intel: Enable PWM optional feature Andy Shevchenko
2022-11-08 14:22 ` [PATCH v2 1/6] pwm: Add a stub for devm_pwmchip_add() Andy Shevchenko
2022-11-10 7:07 ` Uwe Kleine-König
2022-11-10 9:54 ` Andy Shevchenko
2022-11-08 14:22 ` [PATCH v2 2/6] pwm: lpss: Rename MAX_PWMS --> LPSS_MAX_PWMS Andy Shevchenko
2022-11-08 15:07 ` Uwe Kleine-König
2022-11-08 14:22 ` [PATCH v2 3/6] pwm: lpss: Include headers we are direct user of Andy Shevchenko
2022-11-10 7:21 ` Uwe Kleine-König
2022-11-10 9:53 ` Andy Shevchenko
2022-11-10 10:20 ` Uwe Kleine-König
2022-11-10 10:24 ` Andy Shevchenko
2022-11-08 14:22 ` [PATCH v2 4/6] pwm: lpss: Allow other drivers to enable PWM LPSS Andy Shevchenko
2022-11-10 7:28 ` Uwe Kleine-König
2022-11-10 7:35 ` Uwe Kleine-König
2022-11-10 9:58 ` Andy Shevchenko
2022-11-10 10:23 ` Uwe Kleine-König
2022-11-11 13:50 ` Andy Shevchenko [this message]
2022-11-08 14:22 ` [PATCH v2 5/6] pwm: lpss: Add pwm_lpss_probe() stub Andy Shevchenko
2022-11-10 7:38 ` Uwe Kleine-König
2022-11-10 10:01 ` Andy Shevchenko
2022-11-11 13:57 ` Andy Shevchenko
2022-11-08 14:22 ` [PATCH v2 6/6] pinctrl: intel: Enumerate PWM device when community has a capabilitty Andy Shevchenko
2022-11-09 9:08 ` Linus Walleij
2022-11-09 9:56 ` Andy Shevchenko
2022-11-09 10:08 ` Linus Walleij
2022-11-09 10:40 ` Andy Shevchenko
2022-11-10 7:44 ` Uwe Kleine-König
2022-11-10 10:03 ` Andy Shevchenko
2022-11-09 9:01 ` [PATCH v2 0/6] pinctrl: intel: Enable PWM optional feature Linus Walleij
2022-11-09 17:40 ` Thierry Reding
2022-11-09 17:49 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y25TOsMCQEezhnN0@smile.fi.intel.com \
--to=andy.shevchenko@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.