From: Hans de Goede <hdegoede@redhat.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 0/2] simplefb: Add regulator handling support
Date: Mon, 19 Oct 2015 07:59:25 +0000 [thread overview]
Message-ID: <5624A2DD.4020101@redhat.com> (raw)
In-Reply-To: <20151018195719.GC14956@sirena.org.uk>
Hi,
On 18-10-15 21:57, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 01:31:52PM +0200, Hans de Goede wrote:
>
>> I like your idea in your other mail where you suggest to actually
>> use foo-supply and bar-supply names in the simplefb node, and then have
>> some code simple iterate over all the properties and check for *-supply
>> properties, so that the proper, schematic matching names can be used.
>
>> But surely if we go this way having a helper for this so that others
>> can re-use that likely not entirely trivial code is a good idea ?
>
> Yeah. It's trying to come up with a way to do this that is easy to
> avoid abuse that's tricky.
>
>> One user which comes to mind immediately here is the generic mmc-pwrseq
>> driver.
>
>> I agree that we need to be careful to not use a helper like this too
>> much, but I do believe it will make sense to have it in some rare cases.
>> We can put a big warning in both the header declaring it and above
>> the implementation to use it scarcely.
>
> I'd rather have something that was visible in the code, not everyone
> reads the documentation especially not subsystem maintainers reviewing
> drivers that use APIs they're not familiar with.
I'm afraid there is not really a good way to do this though, so a big fat
warning in the header declaring the function is really the bets we can
do IMHO.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 0/2] simplefb: Add regulator handling support
Date: Mon, 19 Oct 2015 09:59:25 +0200 [thread overview]
Message-ID: <5624A2DD.4020101@redhat.com> (raw)
In-Reply-To: <20151018195719.GC14956@sirena.org.uk>
Hi,
On 18-10-15 21:57, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 01:31:52PM +0200, Hans de Goede wrote:
>
>> I like your idea in your other mail where you suggest to actually
>> use foo-supply and bar-supply names in the simplefb node, and then have
>> some code simple iterate over all the properties and check for *-supply
>> properties, so that the proper, schematic matching names can be used.
>
>> But surely if we go this way having a helper for this so that others
>> can re-use that likely not entirely trivial code is a good idea ?
>
> Yeah. It's trying to come up with a way to do this that is easy to
> avoid abuse that's tricky.
>
>> One user which comes to mind immediately here is the generic mmc-pwrseq
>> driver.
>
>> I agree that we need to be careful to not use a helper like this too
>> much, but I do believe it will make sense to have it in some rare cases.
>> We can put a big warning in both the header declaring it and above
>> the implementation to use it scarcely.
>
> I'd rather have something that was visible in the code, not everyone
> reads the documentation especially not subsystem maintainers reviewing
> drivers that use APIs they're not familiar with.
I'm afraid there is not really a good way to do this though, so a big fat
warning in the header declaring the function is really the bets we can
do IMHO.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
Jean-Christophe Plagniol-Villard
<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH RFC 0/2] simplefb: Add regulator handling support
Date: Mon, 19 Oct 2015 09:59:25 +0200 [thread overview]
Message-ID: <5624A2DD.4020101@redhat.com> (raw)
In-Reply-To: <20151018195719.GC14956-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi,
On 18-10-15 21:57, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 01:31:52PM +0200, Hans de Goede wrote:
>
>> I like your idea in your other mail where you suggest to actually
>> use foo-supply and bar-supply names in the simplefb node, and then have
>> some code simple iterate over all the properties and check for *-supply
>> properties, so that the proper, schematic matching names can be used.
>
>> But surely if we go this way having a helper for this so that others
>> can re-use that likely not entirely trivial code is a good idea ?
>
> Yeah. It's trying to come up with a way to do this that is easy to
> avoid abuse that's tricky.
>
>> One user which comes to mind immediately here is the generic mmc-pwrseq
>> driver.
>
>> I agree that we need to be careful to not use a helper like this too
>> much, but I do believe it will make sense to have it in some rare cases.
>> We can put a big warning in both the header declaring it and above
>> the implementation to use it scarcely.
>
> I'd rather have something that was visible in the code, not everyone
> reads the documentation especially not subsystem maintainers reviewing
> drivers that use APIs they're not familiar with.
I'm afraid there is not really a good way to do this though, so a big fat
warning in the header declaring the function is really the bets we can
do IMHO.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
linux-fbdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 0/2] simplefb: Add regulator handling support
Date: Mon, 19 Oct 2015 09:59:25 +0200 [thread overview]
Message-ID: <5624A2DD.4020101@redhat.com> (raw)
In-Reply-To: <20151018195719.GC14956@sirena.org.uk>
Hi,
On 18-10-15 21:57, Mark Brown wrote:
> On Wed, Oct 14, 2015 at 01:31:52PM +0200, Hans de Goede wrote:
>
>> I like your idea in your other mail where you suggest to actually
>> use foo-supply and bar-supply names in the simplefb node, and then have
>> some code simple iterate over all the properties and check for *-supply
>> properties, so that the proper, schematic matching names can be used.
>
>> But surely if we go this way having a helper for this so that others
>> can re-use that likely not entirely trivial code is a good idea ?
>
> Yeah. It's trying to come up with a way to do this that is easy to
> avoid abuse that's tricky.
>
>> One user which comes to mind immediately here is the generic mmc-pwrseq
>> driver.
>
>> I agree that we need to be careful to not use a helper like this too
>> much, but I do believe it will make sense to have it in some rare cases.
>> We can put a big warning in both the header declaring it and above
>> the implementation to use it scarcely.
>
> I'd rather have something that was visible in the code, not everyone
> reads the documentation especially not subsystem maintainers reviewing
> drivers that use APIs they're not familiar with.
I'm afraid there is not really a good way to do this though, so a big fat
warning in the header declaring the function is really the bets we can
do IMHO.
Regards,
Hans
next prev parent reply other threads:[~2015-10-19 7:59 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 17:04 [PATCH RFC 0/2] simplefb: Add regulator handling support Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-12 17:04 ` [PATCH RFC 1/2] dt-bindings: simplefb: Support a list of regulator supply properties Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-12 17:10 ` Mark Rutland
2015-10-12 17:10 ` Mark Rutland
2015-10-12 17:10 ` Mark Rutland
2015-10-12 17:10 ` Mark Rutland
2015-10-13 2:22 ` Chen-Yu Tsai
2015-10-13 2:22 ` Chen-Yu Tsai
2015-10-13 2:22 ` Chen-Yu Tsai
2015-10-13 7:08 ` Hans de Goede
2015-10-13 7:08 ` Hans de Goede
2015-10-13 7:08 ` Hans de Goede
2015-10-14 10:36 ` Mark Brown
2015-10-14 10:36 ` Mark Brown
2015-10-14 10:36 ` Mark Brown
2015-10-12 17:04 ` [PATCH RFC 2/2] simplefb: Claim and enable regulators Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-12 17:04 ` Chen-Yu Tsai
2015-10-13 7:16 ` [PATCH RFC 0/2] simplefb: Add regulator handling support Hans de Goede
2015-10-13 7:16 ` Hans de Goede
2015-10-13 7:16 ` Hans de Goede
2015-10-13 7:16 ` Hans de Goede
2015-10-14 10:55 ` Mark Brown
2015-10-14 10:55 ` Mark Brown
2015-10-14 10:55 ` Mark Brown
2015-10-14 11:31 ` Hans de Goede
2015-10-14 11:31 ` Hans de Goede
2015-10-14 11:31 ` Hans de Goede
2015-10-18 19:57 ` Mark Brown
2015-10-18 19:57 ` Mark Brown
2015-10-18 19:57 ` Mark Brown
2015-10-19 7:59 ` Hans de Goede [this message]
2015-10-19 7:59 ` Hans de Goede
2015-10-19 7:59 ` Hans de Goede
2015-10-19 7:59 ` Hans de Goede
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=5624A2DD.4020101@redhat.com \
--to=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.