From: Alan Stern <stern@rowland.harvard.edu>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Sekhar Nori <nsekhar@ti.com>, Kevin Hilman <khilman@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
<linux-usb@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 0/3] ARM: davinci: ohci-da8xx: model the vbus GPIO as a fixed regulator
Date: Thu, 28 Mar 2019 10:38:02 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1903281036290.1291-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CAMRc=Memgo9LwgmZqGcDZpGz02qSLst2xdMhED6_fxJkLDBowg@mail.gmail.com>
On Thu, 28 Mar 2019, Bartosz Golaszewski wrote:
> czw., 28 mar 2019 o 15:11 Alan Stern <stern@rowland.harvard.edu> napisał(a):
> >
> > On Thu, 28 Mar 2019, Sekhar Nori wrote:
> >
> > > >> Can you document why the current solution is not optimal? Is it to make
> > > >> future device-tree conversion for these boards easier? Or?
> > > >>
> > > >
> > > > It's sub-optimal from the HW modeling in SW PoV - it is in fact a
> > > > regulator enabled/disabled by a GPIO. Also: it's code duplication as
> > > > currently we check if the vbus GPIO exists and then use it or check if
> > > > the regulator exists and use this as the second choice. The third
> > > > patch actually shrinks the driver.
> > >
> > > I see now that the driver supports controlling the VBUS gpio as
> > > regulator already. Something I should have caught in review last time
> > > around.
> > >
> > > I agree this patch is an improvement. Lets see what Alan feels.
> >
> > I'm not an expert on this stuff, but the patch looks reasonable.
> > However, I do wish that in the devm_request_threaded_irq() call, the
> > indentation of the continuation lines was left unchanged.
> >
>
> I don't think it's possible - the function name is longer and the
> first line exceeds the 80 characters limit. I can put all the
> parameters below the function name if you prefer that?
Which line the arguments go on doesn't matter. But increasing the
amount of indentation, like the patch did, makes the whole thing less
readable, IMO. It makes everything end up crammed against the right
margin.
Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Kevin Hilman <khilman@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, Sekhar Nori <nsekhar@ti.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/3] ARM: davinci: ohci-da8xx: model the vbus GPIO as a fixed regulator
Date: Thu, 28 Mar 2019 10:38:02 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1903281036290.1291-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CAMRc=Memgo9LwgmZqGcDZpGz02qSLst2xdMhED6_fxJkLDBowg@mail.gmail.com>
On Thu, 28 Mar 2019, Bartosz Golaszewski wrote:
> czw., 28 mar 2019 o 15:11 Alan Stern <stern@rowland.harvard.edu> napisał(a):
> >
> > On Thu, 28 Mar 2019, Sekhar Nori wrote:
> >
> > > >> Can you document why the current solution is not optimal? Is it to make
> > > >> future device-tree conversion for these boards easier? Or?
> > > >>
> > > >
> > > > It's sub-optimal from the HW modeling in SW PoV - it is in fact a
> > > > regulator enabled/disabled by a GPIO. Also: it's code duplication as
> > > > currently we check if the vbus GPIO exists and then use it or check if
> > > > the regulator exists and use this as the second choice. The third
> > > > patch actually shrinks the driver.
> > >
> > > I see now that the driver supports controlling the VBUS gpio as
> > > regulator already. Something I should have caught in review last time
> > > around.
> > >
> > > I agree this patch is an improvement. Lets see what Alan feels.
> >
> > I'm not an expert on this stuff, but the patch looks reasonable.
> > However, I do wish that in the devm_request_threaded_irq() call, the
> > indentation of the continuation lines was left unchanged.
> >
>
> I don't think it's possible - the function name is longer and the
> first line exceeds the 80 characters limit. I can put all the
> parameters below the function name if you prefer that?
Which line the arguments go on doesn't matter. But increasing the
amount of indentation, like the patch did, makes the whole thing less
readable, IMO. It makes everything end up crammed against the right
margin.
Alan Stern
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-28 14:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 15:57 [PATCH 0/3] ARM: davinci: ohci-da8xx: model the vbus GPIO as a fixed regulator Bartosz Golaszewski
2019-03-26 15:57 ` Bartosz Golaszewski
2019-03-26 15:57 ` [PATCH 1/3] ARM: davinci: omapl138-hawk: add a fixed regulator for ohci-da8xx Bartosz Golaszewski
2019-03-26 15:57 ` Bartosz Golaszewski
2019-03-26 15:57 ` [1/3] " Bartosz Golaszewski
2019-03-26 15:57 ` [PATCH 2/3] ARM: davinci: da830-evm: " Bartosz Golaszewski
2019-03-26 15:57 ` Bartosz Golaszewski
2019-03-26 15:57 ` [2/3] " Bartosz Golaszewski
2019-03-26 15:57 ` [PATCH 3/3] usb: ohci-da8xx: drop the vbus GPIO Bartosz Golaszewski
2019-03-26 15:57 ` Bartosz Golaszewski
2019-03-26 15:57 ` [3/3] " Bartosz Golaszewski
2019-03-27 11:37 ` [PATCH 0/3] ARM: davinci: ohci-da8xx: model the vbus GPIO as a fixed regulator Sekhar Nori
2019-03-27 11:37 ` Sekhar Nori
2019-03-27 13:16 ` Bartosz Golaszewski
2019-03-27 13:16 ` Bartosz Golaszewski
2019-03-28 10:10 ` Sekhar Nori
2019-03-28 10:10 ` Sekhar Nori
2019-03-28 14:11 ` Alan Stern
2019-03-28 14:11 ` Alan Stern
2019-03-28 14:29 ` Bartosz Golaszewski
2019-03-28 14:29 ` Bartosz Golaszewski
2019-03-28 14:38 ` Alan Stern [this message]
2019-03-28 14:38 ` Alan Stern
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=Pine.LNX.4.44L0.1903281036290.1291-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nsekhar@ti.com \
/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.