de
> #include
> +#include
> #include
> #include
> #include
The rule of thumb when extending a header inclusion block is that try to
squeeze the new inclusion in the longest sorted part of the list.
Rationale behind is easy maintenance.
--
With Best Regards,
Andy Shevchenko
gt; + if (!polling)
> + schedule();
> + else
> + udelay(100);
What the point to use negative conditional when it's pretty straightforward and
positive may be used?
--
With Best Regards,
Andy Shevchenko
pproach to handle it?
> + if (IS_ERR_OR_NULL(usb3->host_dev)) {
> + /* If not found, this driver will not use a role sw */
> + usb_role_switch_unregister(usb3->role_sw);
> + usb3->role_sw = NULL;
> + }
&g
ssage.
And now even better to ask, why platform_get_irq() wouldn't work for DT case?
> +
> + if (!pp->has_irq)
> dev_warn(dev, "no irq for port%d\n", pp->idx);
This could be issued in the actual function which will try to allocate
IRQs (perhaps on debug level)
P.S. Just think about it, perhaps you find even better solutions.
--
With Best Regards,
Andy Shevchenko
> + .pm = _usb3_role_switch_pm_ops,
> + .of_match_table =
> of_match_ptr(rcar_usb3_role_switch_of_match),
Is it possible to have this driver w/o OF? Does it make sense in that case?
Otherwise remove of_match_ptr() call and below modalias.
> + },
> +};
> +MODULE_ALIAS("platform:rcar_usb3_role_switch");
--
With Best Regards,
Andy Shevchenko
pp->has_irq = true;
> + }
> + }
So, on the first glance the patch looks either superfluous or taking
wrong approach. Please, elaborate more why it's done in this way and
what the case for all this in practice.
--
With Best Regards,
Andy Shevchenko
hould conform to Rusty Russell's API hierarchy.
>
> Interested in fixing it, or should I?
> I can almost ACK it before you write the patch.
I vote for this type of API, and agree with Wolfram !_get_direction() is
confusing.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
(gpiod_get_direction(bri->sda_gpiod) == GPIOF_DIR_OUT)
P.S. Yep, I saw some other upstreamed patch doing this kind of
comparison.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
*unprepare_recovery)(struct i2c_adapter *);
It seems inconsistent with the rest of the members even from this
visible piece.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
On Mon, May 22, 2017 at 4:11 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Add an example SPI slave handler to allow remote control of system
> reboot, power off, halt, and suspend.
>
FWIW:
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
> Signed-of
On Mon, May 22, 2017 at 1:13 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Thu, May 18, 2017 at 6:01 PM, Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
>> On Wed, May 17, 2017 at 3:47 PM, Geert Uytterhoeven
>> <geert+rene...@glider.be> wr
form data
> +*/
> + spi->bits_per_word = 8;
Is it worth to define it? If so, can we use device properties for that?
--
With Best Regards,
Andy Shevchenko
On Mon, May 8, 2017 at 8:02 PM, Chris Brandt <chris.bra...@renesas.com> wrote:
> On Monday, May 08, 2017, Andy Shevchenko wrote:
>> On Mon, May 8, 2017 at 7:01 PM, jmondi <jac...@jmondi.org> wrote:
>> > On Sun, May 07, 2017 at 09:52:49AM +0200, Linus Walleij wrote:
&
On Mon, May 8, 2017 at 8:25 PM, jmondi <jac...@jmondi.org> wrote:
> Andy,
>
> On Mon, May 08, 2017 at 07:08:32PM +0300, Andy Shevchenko wrote:
>> On Mon, May 8, 2017 at 7:01 PM, jmondi <jac...@jmondi.org> wrote:
>> > On Sun, May 07, 2017 at 09:52:49AM +0200, Li
On Mon, May 8, 2017 at 7:01 PM, jmondi <jac...@jmondi.org> wrote:
> On Sun, May 07, 2017 at 09:52:49AM +0200, Linus Walleij wrote:
>> On Fri, Apr 28, 2017 at 4:53 PM, Andy Shevchenko
>> <andy.shevche...@gmail.com> wrote:
>>
>> > Linus, for me it looks l
fer static inlines over macros because they are easier
> to read.
Not only. It adds type checking as well AFAIUC.
--
With Best Regards,
Andy Shevchenko
On Fri, Apr 28, 2017 at 6:16 PM, Chris Brandt <chris.bra...@renesas.com> wrote:
> On Friday, April 28, 2017, Andy Shevchenko wrote:
>> Had you read the following, esp. Note there?
>>
>> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does
>&g
On Fri, Apr 28, 2017 at 4:18 PM, Chris Brandt <chris.bra...@renesas.com> wrote:
> On Friday, April 28, 2017, Andy Shevchenko wrote:
>> > In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control
>> Logical Diagram (but that wasn't obvious to me at first).
&
" is used to enable the
> input buffer as well.
> In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control Logical
> Diagram (but that wasn't obvious to me at first).
Please, post a link to it or copy essential parts.
I'm quite skeptical that cheap hardware can implement something more
costable than simplest open-source / open-drain + bias.
--
With Best Regards,
Andy Shevchenko
connected to VDD.
> + * @PIN_CONFIG_BIDIRECTIONAL: the pin will be configured to allow
> simultaneous
> + * input and output operations.
> * @PIN_CONFIG_DRIVE_OPEN_DRAIN: the pin will be driven with open drain (open
> * collector) which means it is usually wired with other output ports
> * which are then pulled up with an external resistor. Setting this
> @@ -96,6 +98,7 @@ enum pin_config_param {
> PIN_CONFIG_BIAS_PULL_DOWN,
> PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
> PIN_CONFIG_BIAS_PULL_UP,
> + PIN_CONFIG_BIDIRECTIONAL,
> PIN_CONFIG_DRIVE_OPEN_DRAIN,
> PIN_CONFIG_DRIVE_OPEN_SOURCE,
> PIN_CONFIG_DRIVE_PUSH_PULL,
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
20 matches
Mail list logo
