| 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
| ||
|
Message-ID: <20150104090036.GA30683@amd>
Date: Sun, 4 Jan 2015 10:00:36 +0100
From: Pavel Machek <pavel@....cz>
To: Sakari Ailus <sakari.ailus@....fi>
Cc: pali.rohar@...il.com, sre@...ian.org, sre@...g0.de,
kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-omap@...r.kernel.org, tony@...mide.com, khilman@...nel.org,
aaro.koskinen@....fi, freemangordon@....bg, robh+dt@...nel.org,
pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
bcousson@...libre.com, m.chehab@...sung.com,
devicetree@...r.kernel.org, linux-media@...r.kernel.org,
j.anaszewski@...sung.com
Subject: Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
Hi!
> Thanks for the patch! A few comments below.
>
> On Wed, Dec 24, 2014 at 11:34:34PM +0100, Pavel Machek wrote:
> >
> > We are moving to device tree support on OMAP3, but that currently
> > breaks ADP1653 driver. This adds device tree support, plus required
> > documentation.
> >
> > Signed-off-by: Pavel Machek <pavel@....cz>
> >
> > ---
> >
> > Changed -microsec to -us, as requested by devicetree people.
> >
> > Fixed checkpatch issues.
> >
> > diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> > index 2d88816..2c6c7c5 100644
> > --- a/Documentation/devicetree/bindings/leds/common.txt
> > +++ b/Documentation/devicetree/bindings/leds/common.txt
> > @@ -14,6 +14,15 @@ Optional properties for child nodes:
> > "ide-disk" - LED indicates disk activity
> > "timer" - LED flashes at a fixed, configurable rate
> >
> > +- max-microamp : maximum intensity in microamperes of the LED
> > + (torch LED for flash devices)
>
> s/torch LED/torch mode/
>
> > +- flash-max-microamp : maximum intensity in microamperes of the
> > + flash LED; it is mandatory if the LED should
> > + support the flash mode
> > +- flash-timeout-microsec : timeout in microseconds after which the flash
> > + LED is turned off
>
> These should go to a different patch.
Actually these both should not be in this patch in the first place.
> > + - reg: I2C slave address
> > +
> > + - gpios: References to the GPIO that controls the power for the chip.
> > +
> > +There are two led outputs available - flash and indicator. One led is
> > +represented by one child node, nodes need to be named "flash" and "indicator".
>
> 80 characters per line.
Count them. It is.
> > +
> > +Required properties of the LED child node:
> > +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> > +
> > +Required properties of the flash LED child node:
> > +
> > +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> > +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
> > +
> > +Example:
> > +
> > + adp1653: led-controller@30 {
> > + compatible = "adi,adp1653";
> > + reg = <0x30>;
> > + gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
>
> Please use tabs for indentation above (and below).
Ok.
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -553,6 +558,22 @@
> >
> > ti,usb-charger-detection = <&isp1704>;
> > };
> > +
> > + adp1653: led-controller@30 {
> > + compatible = "adi,adp1653";
> > + reg = <0x30>;
> > + gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> > +
> > + flash {
> > + flash-timeout-us = <500000>;
> > + flash-max-microamp = <320000>;
> > + max-microamp = <50000>;
> > + };
> > +
> > + indicator {
> > + max-microamp = <17500>;
> > + };
> > + };
>
> This should go to a separate patch as well.
How many patches do I need to do for one trivial change? :-(.
> > + if (flash->platform_data->power)
> > + ret = flash->platform_data->power(&flash->subdev, on);
>
> if () {
> } else {
> }
Ok.
> > + else {
> > + gpio_set_value(flash->platform_data->power_gpio, on);
>
> Shouldn't you add this to the platform data struct?
I don't see what you mean.
> power_gpio is actually a poor name for this, as is the "power" callback.
> This is really "EN" gpio in the spec, I'd call it perhaps just "gpio", or
> "enable_gpio".
Feel free to clean that that up in followup patch.
> > + if (on) {
> > + /* Some delay is apparently required. */
> > + udelay(20);
>
> The driver should always handle the delay, platform data or not. This
> reminds me --- is there a need to retain the support for platform data? I
> don't think it's being used anywhere. I'm fine with both keeping and
> removing it.
Lets do that in followup patch, if needed.
> > + child = of_get_child_by_name(node, "indicator");
> > + if (!child)
> > + return -EINVAL;
>
> Do you require an indicator to be connected? I think it shouldn't be
> mandatory, at least the driver should work without it, even if it
> exposes
> the control (making that conditional would be a subject for another patch,
> but that doesn't need to be done now).
Another patch, if someone needs it, yes.
> > + if (of_property_read_u32(child, "max-microamp", &val))
> > + return -EINVAL;
> > + pd->max_indicator_intensity = val;
> > +
> > + if (!of_find_property(node, "gpios", NULL)) {
> > + dev_err(&client->dev, "No gpio node\n");
> > + return -EINVAL;
> > + }
> > +
> > + gpio = of_get_gpio_flags(node, 0, &flags);
>
> You could assign to pd->... here.
Ok.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists