On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
I fully agree that a simple, single string will not scale even in some, not
so uncommon cases, but there is already a lot of existing lookup solutions
over the kernel and
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote:
On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote:
What are the problems you are seeing with doing things with lookups?
You don't know the id of the device you are looking up, due to
multiple devices being in the system
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote:
Sorry for jumping in to the middle of the discussion, but why does a *new*
framework even bother defining an interface for board files?
Can't we just drop any interfaces for platform data passing in the phy
framework and put the
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote:
I'm not saying that we can't support legacy board files with the common
PHY framework, but I'd expect things to be much easier if we focus on those
platforms that are actively being worked on for now, to bring an end to the
On Wed, Jul 24, 2013 at 01:52:19AM +0200, Tomasz Figa wrote:
Changes since v2:
- Reworked to use new PLL registration method introduced by Yadwinder
Singh Brar's patch series:
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
I'm not able to test this series since that
On Tue, Jul 23, 2013 at 01:49:22AM +0200, Tomasz Figa wrote:
This patch modifies s3c64xx DMA driver to prepare and unprepare clocks
in addition to enableind and disabling, since it is required by common
clock framework.
Tested-by: Mark Brown broo...@linaro.org
signature.asc
Description
On Wed, Jul 31, 2013 at 10:46:45AM +0200, Uwe Kleine-König wrote:
OK, so the possible problem is that remove is called while the irq is
still active. That means you have to assert that all resources the irq
handler is using (e.g. ioremap, clk_prepare_enable) are only freed
*after* the irq is
On Wed, Jul 31, 2013 at 05:54:11AM -0400, Tejun Heo wrote:
On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-König wrote:
OK, so the possible problem is that remove is called while the irq is
still active. That means you have to assert that all resources the irq
If your driver
On Wed, Jul 31, 2013 at 07:32:44AM -0400, Tejun Heo wrote:
Yeah, if all resources are allocated using devm - note that you can
hook in non-devm resources using devres_alloc() - all resources which
would be necessary for the interrupt handler would have been allocated
before the irq was
On Wed, Jul 31, 2013 at 07:55:27AM -0400, Tejun Heo wrote:
If you have DMA / IRQ / command engine deactivations in devm path
which often is the case with full conversions, freeing any resources
including DMA areas and host private data in the wrong order is a
horrible idea. It's worse as it
On Wed, Jul 31, 2013 at 09:42:15AM -0400, Tejun Heo wrote:
On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:
It's really only interrupts that affect most devices - if there's DMA or
anything going on after the remove() then as you said earlier the driver
is probably doing
On Wed, Jul 31, 2013 at 10:07:58AM -0400, Tejun Heo wrote:
On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:
That's the only API I've ever heard of doing that. Everything else is
just using it to do deallocation.
I'm not sure why or what you're trying to argue here but take
On Wed, Jul 31, 2013 at 11:29:32AM -0400, Tejun Heo wrote:
Yeah, sure, thank you very much for your input. It is of course
strictly ordered and the documentation needs to be updated.
While I note the way you're saying this given the widespread adoption I
think there's a bit more effort needed
From: Andy Green andy.gr...@linaro.org
You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
case these are unused.
Signed-off-by: Andy Green andy.gr...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/dwc3/dwc3-pci.c | 2 +-
1 file changed, 1
On Tue, Aug 06, 2013 at 10:35:52PM -0300, Fabio Estevam wrote:
On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown broo...@kernel.org wrote:
From: Andy Green andy.gr...@linaro.org
You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
case these are unused.
Signed-off
From: Mark Brown broo...@linaro.org
The intn and connect GPIO properties are swapped in the code which will
cause failures at runtime if these are connected, fix the code.
There are currently no in-tree users of this device to check or update.
Signed-off-by: Mark Brown broo...@linaro.org
From: Mark Brown broo...@linaro.org
Saves us a bit of code.
Signed-off-by: Mark Brown broo...@linaro.org
---
This depends on my previous patch usb: misc: Fix swapped properties in
usb3503 DT parsing.
drivers/usb/misc/usb3503.c | 42 +++---
1 file changed, 7
From: Mark Brown broo...@linaro.org
If someone provided meaningful error codes from reset() we should tell the
user what they were.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/core/hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hcd.c
From: Mark Brown broo...@linaro.org
Systems with the common clock API need clk_prepare() as well as the enable
step.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/phy/phy-nop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-nop.c b
From: Mark Brown broo...@linaro.org
Since there is no runtime interface for changing modes this is probably
the most sensible default.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc
From: Mark Brown broo...@linaro.org
There are no software visible differences that I am aware of but in case
any are discovered allow the DTS to specify exactly which device is
present.
Signed-off-by: Mark Brown broo...@linaro.org
---
Documentation/devicetree/bindings/usb/usb3503.txt | 2
From: Mark Brown broo...@linaro.org
The /RESET GPIO is not manipulated from atomic context so support GPIOs
that can't be written from atomic context by using _cansleep().
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503
From: Mark Brown broo...@linaro.org
The intn and connect GPIO properties are swapped in the code which will
cause failures at runtime if these are connected, fix the code.
There are currently no in-tree users of this device to check or update.
Signed-off-by: Mark Brown broo...@linaro.org
From: Mark Brown broo...@linaro.org
In preparation for supporting operation without an I2C control interface
factor out the I2C-specific parts of the probe routine from those that
don't do any register I/O.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/misc/usb3503.c | 77
From: Mark Brown broo...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/misc/usb3503.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index ca0f789..777102e 100644
--- a/drivers/usb/misc
From: Mark Brown broo...@linaro.org
Refactor so that register writes for configuration are only performed if
the device has a regmap provided and also register as a platform driver.
This allows the driver to be used to manage GPIO based control of the
device.
Signed-off-by: Mark Brown broo
From: Mark Brown broo...@linaro.org
The binding document says that all properties are required but in fact
almost all are optional (and should be) - update the document to reflect
this.
Signed-off-by: Mark Brown broo...@linaro.org
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree
From: Mark Brown broo...@linaro.org
This will give access to the diagnostic infrastructure regmap has but
the main point is to support future refactoring.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/misc/Kconfig | 1 +
drivers/usb/misc/usb3503.c | 93
From: Mark Brown broo...@linaro.org
Saves us a bit of code.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/misc/usb3503.c | 42 +++---
1 file changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc
On Fri, Aug 09, 2013 at 05:38:57PM +0300, Felipe Balbi wrote:
On Thu, Aug 08, 2013 at 12:35:04PM +0100, Mark Brown wrote:
Systems with the common clock API need clk_prepare() as well as the enable
step.
clk_prepare() is done on probe()... -ECONFUSED
Ah, so it is, missed that - though
From: Mark Brown broo...@linaro.org
Since we only enable the PHY clock on init and the PHY init and shutdown
does not occur in atomitc context there is no need to prepare the clock
before it is enabled. Move the clk_prepare() operations to go along
with the enables, allowing the clock
Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration. Similarly currently all the DT bindings in the kernel I've
been able to notice cover only non-enumerable buses. This generally
makes sense
On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
On Sun, 11 Aug 2013, Mark Brown wrote:
One example that's bugging me right now is that on the Insignal Arndale
platform there's a USB hub connected to one of the USB ports on the SoC
(not as a PHY, it seems we also need
On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote:
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
I know there's been some discussion of this topic but do we have any
general consensus on how to handle such things both from a Linux driver
model point of view
On Mon, Aug 12, 2013 at 12:07:14PM +0100, Mark Rutland wrote:
As I understand it, the wifi chip on the Snow Chromebook has a similar
issue -- it hangs off of a probeable SDIO bus, but needs a regulator
poked for it to turn on and become probeable (see
exynos_wifi_bt_set_power in [1]).
Yes,
On Wed, Aug 07, 2013 at 08:51:27AM -0300, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
Using SIMPLE_DEV_PM_OPS can make the code simpler and cleaner.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Reviewed-by: Mark Brown broo...@linaro.org
signature.asc
On Mon, Aug 12, 2013 at 12:08:17PM -0600, Stephen Warren wrote:
In a similar way, I wonder if the USB case can be considered the same
way? This seems less like a good fit since I don't expect the resources
are always so similar there, and also there's the case of the bus being
potentially
On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote:
On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:
I don't think they're bus specific - the main issue with a lot of this
is that they're outside the infrastructure that the bus standardises so
we should have
On Wed, Aug 14, 2013 at 09:19:44AM +0800, Peter Chen wrote:
If CONFIG_PM_SLEEP is not defined, the current value is .pm = NULL,
but your version .pm != NULL (its content is NULL).
I am not sure if it will cause any problems.
It would cause a small amount of additional memory usage if the
On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:
The bus code would need hooks installed wherever the platform wants to
do something extra. This could end up growing to a lot of hooks. How
can the whole thing be done in a reasonable fashion?
I'd expect that we're just looking
On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
I'd expect that we're just looking at hooks around connection and
disconnection here here - if we're looking at much more it seems like we
must be doing something wrong.
Connection
On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
Yes, so you'd want callbacks when the device actually appears and
disappears.
No, no -- this is exactly the point I was trying to make. The on-board
hub _won't_ appear on the USB bus until
On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
What I'm proposing is that we have a way of telling buses that devices
exist via a mechanism other than their actually being visible on the bus
at the current time. If you're doing
On Wed, Aug 14, 2013 at 10:30:44AM -0600, Stephen Warren wrote:
On 08/14/2013 10:14 AM, Alan Stern wrote:
No, no -- this is exactly the point I was trying to make. The on-board
hub _won't_ appear on the USB bus until the GPIOs are set. Therefore
the callback to set the GPIOs needs to be
On Wed, Aug 14, 2013 at 11:22:39AM -0700, Greg KH wrote:
On Wed, Aug 14, 2013 at 03:59:31PM +0530, Tushar Behera wrote:
Currently there is no other way to ensure that USB3503 chip is probed
after the USB PHY has been initialized, hence the last resort.
Are you sure that deferred probing
On Wed, Aug 14, 2013 at 12:47:44PM -0700, Greg KH wrote:
On Wed, Aug 14, 2013 at 08:39:50PM +0100, Mark Brown wrote:
That resource is the USB bus I think (I suspect the issue is that the
fact that power is always present confuses the USB enumeration protocol
if the device gets brought out
On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:
I don't see the point of all this. Obviously the device can't be used
until it physically appears on the bus. What benefit do you get from
registering it and making it available to userspace before that?
Two things. One is that
On Wed, Aug 14, 2013 at 08:16:56PM +, Paul Zimmerman wrote:
Mark's original complaint about USB was this:
the device). The hub needs to be plugged into the SoC after the SoC
USB controller has started with some GPIOs so we need to tell the system
that the hub exists and needs to be
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
On Thu, 15 Aug 2013, Mark Brown wrote:
So why not bring the device to full power as soon as possible during
boot, and have it registered on the bus in the usual way? Once that's
done, the ordinary runtime PM mechanism will allow
On Thu, Aug 15, 2013 at 01:55:18PM -0400, Alan Stern wrote:
On Thu, 15 Aug 2013, Mark Brown wrote:
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
To be honest I don't see how that helps much if you're going to handle
the case where platform data is required to enumerate
On Thu, Aug 15, 2013 at 04:42:01PM -0400, Alan Stern wrote:
Okay. Here's a restatement of what you wrote above:
In the case where platform data is required to enumerate the
device, you need to know about the device prior to enumeration.
Obviously true.
You need to get
On Fri, Aug 16, 2013 at 10:42:10AM -0400, Alan Stern wrote:
Okay, let's see if I understand your problem. You've got a driver that
...
Is that it?
Yes, I think that's it.
The difficulty with the first proposal is that subsystems aren't
designed to allow that sort of thing. They expect to
On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote:
On Fri, 16 Aug 2013, Mark Brown wrote:
or those for getting platform data to a device when it
does enumerate.
? I can't make any sense out of that comment. For one thing, why do
you need to send platform data to a device
On Fri, Aug 16, 2013 at 04:39:47PM -0400, Alan Stern wrote:
On Fri, 16 Aug 2013, Mark Brown wrote:
The device in this context is a running instance of the driver.
It's kind of difficult to understand what you're saying. Obviously the
literal meaning is not what you had in mind, because
On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu wrote:
Aong those lines, I would like to point out that the device concept
embodied in the kernel's data structures can be pretty thin. For
example, it might be
On Tue, Aug 20, 2013 at 09:19:07PM +0800, Ming Lei wrote:
On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown broo...@kernel.org wrote:
I can't parse this at all well - why would DT want to refer to ACPI, do
you mean people may wish to look at the code as an example? As Grant
I mean usb-acpi
On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote:
Please fix your mailer to word wrap within paragraphs, not doing this
makes your mail very hard to read. It looks like your mailer has also
reflowed Daniel's mail.
On 09/08/2013 04:50 PM, Daniel Santos wrote:
Even better, thank
On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
So do i create an IRQ domain and then call generic_handle_irq() from
my URB complete() function? If so, which type of IRQ Domain is
appropriate for this? Unlike typical platform devices, these are
dynamically added and removed
On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote:
Am 09.09.2013 13:02, schrieb Mark Brown:
makes your mail very hard to read. It looks like your mailer has also
reflowed Daniel's mail.
That's just wrong. Mail readers should wrap lines, not senders. And
readers can do
On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
On 09/09/2013 06:06 AM, Mark Brown wrote:
On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
I have some secondary (and less important) questions about how to
integrate this with device drivers that want a DT / open
Today's linux-next merge of the usb-gadget tree got conflicts in
drivers/usb/musb/davinci.c caused by an add in ea78201e2 (usb: musb:
davinci: fix resources passed to MUSB driver for DM6467) adjacent to
the modification of the device registration in 4c9ad1059 (DMA-API: usb:
musb: use
On Tue, Jun 18, 2013 at 11:34:26AM +0300, Felipe Balbi wrote:
MUSB alone has 8 different arch choices. Before, it used to be that core
driver was dependendent on all of them, so whenever someone wanted to
build MUSB for another arch, they had to introdude their glue code and
modify the
On Mon, Aug 06, 2012 at 03:14:36PM +0200, Lukasz Majewski wrote:
On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote:
I got a kernel panic when try hsotg of ok6410 which is based on
s3c6410:
As you said, you are using the ok6410. And it is based on the s3c6410
CPU. S3C6410 is a
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote:
The first five branches are scheduled to go through the arm-soc tree, so
I'm fine with that. For the sound/for-3.7 branch, I'd like to know when
to expect that hitting mainline. If it always gets in very early during the
merge
On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote:
On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote:
It's usually pretty early but Takashi will be on holiday this time so
I'm not sure if things might be different (he was going to send the pull
request from holiday). I
On Fri, Sep 21, 2012 at 01:26:43AM -0700, Olof Johansson wrote:
I'll take a look at merging it tomorrow after I've dealt with smp_ops;
if it looks reasonably conflict-free I'll pull it in. We need the
sound dependency sorted out (or agreed upon) first though.
I guess in the light of the rest
On Fri, Apr 25, 2014 at 03:19:59PM +0200, Robert Baldyga wrote:
On 04/22/2014 09:51 PM, Mark Brown wrote:
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60
+++
.../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++
.../devicetree/bindings
From: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Ryan Harkin ryan.har...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/phy/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy
From: Liviu Dudau liviu.du...@arm.com
arm64 architecture handles correctly 64bit DMAs and can enable support
for 64bit EHCI host controllers.
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Ryan Harkin ryan.har...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers
From: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Ryan Harkin ryan.har...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/usb/phy/phy-ulpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/phy/phy-ulpi.c b
On Thu, May 15, 2014 at 04:17:44PM +0100, Liviu Dudau wrote:
On Thu, May 15, 2014 at 03:11:48PM +0100, Alan Stern wrote:
On Wed, 14 May 2014, Mark Brown wrote:
Did you folks tested this for all sorts of host controllers? I have no
way to verify that it works, and last I heard, many
On Tue, May 20, 2014 at 01:53:42PM +0200, Marek Szyprowski wrote:
+ hub-clk = devm_clk_get(dev, refclk);
+ if (!IS_ERR(hub-clk)) {
This won't handle deferred probe - the driver should error out if it
gets -EPROBE_DEFER since it means the clock exists and might be
On Tue, May 20, 2014 at 02:18:30PM +0200, Marek Szyprowski wrote:
On 2014-05-20 13:57, Mark Brown wrote:
+ else
+ dev_err(dev,
+ unsupported reference clock rate
(%d)\n,
+ rate
On Tue, Dec 17, 2013 at 02:55:48PM -0800, Sarah Sharp wrote:
I plugged in a USB speaker, and ran lsof to see which files were open
(output is attached). AFAICT, only the USB sound device's control files
are open, and I don't have any midi files.
The attachment seems to have gone AWOL (at
On Fri, Nov 16, 2012 at 12:23:43PM +0200, Roger Quadros wrote:
How is this supposed to work? How does phandle supplied in vin-supply
map to config-input_supply?
You should provide a separate property to name the supply, or just pick
a fixed name in the fixed voltage driver.
signature.asc
On Thu, Oct 23, 2014 at 12:18:15PM +0100, One Thousand Gnomes wrote:
drivers/usb/serial/ftdi_sio.c | 111
+-
drivers/usb/serial/ftdi_sio.h | 41
2 files changed, 151 insertions(+), 1 deletion(-)
Funny patch, you should have
Hi,
One of the Linaro stable kernel users has suggested 2c4e3dbf63b39d (usb:
phy: return -ENODEV on failure of try_module_get) as a fix for the
stable kernel. While it's error handling that's being fixed this does
seem like a reasonable candidate, it's a very simple fix and the
behaviour without
On Wed, Oct 29, 2014 at 03:30:18PM -0700, Greg Kroah-Hartman wrote:
On Wed, Oct 29, 2014 at 10:10:12PM +, Mark Brown wrote:
One of the Linaro stable kernel users has suggested 2c4e3dbf63b39d (usb:
phy: return -ENODEV on failure of try_module_get) as a fix for the
stable kernel. While
On Mon, Nov 10, 2014 at 10:58:56AM -0800, Joe Perches wrote:
Using the return value of seq_puts is error-prone, so
make it return void instead.
Acked-by: Mark Brown broo...@kernel.org
signature.asc
Description: Digital signature
On Wed, Feb 11, 2015 at 07:35:26PM -0800, Bjorn Andersson wrote:
Changing the name of the regulator_set_optimum_mode() to
regulator_set_load() better reflects that the API is doing.
Applied all, thanks.
signature.asc
Description: Digital signature
On Wed, Feb 25, 2015 at 03:40:31PM -0800, Bjorn Andersson wrote:
Any comments on this?
I'm going to propose a patch to the mmc framework calling this api, so
it would be good to know before I add another consumer of the api.
Please don't send content free nags. They just add to the volume
On Mon, Aug 17, 2015 at 06:58:16PM -0500, Felipe Balbi wrote:
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
+ if (wm831x_pdata wm831x_pdata
On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
+ 1500,
+ 1800,
+ 550,
+};
Why 550 is the last, but not 1800?
You'd have to ask the hardware engineers who designed the chip. I
suspect it's because 550 was
On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote:
On 14 August 2015 at 23:27, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of
without drawing more current than specified from others.
Signed-off-by: Mark Brown broo...@kernel.org
Signed-off-by: Baolin Wang baolin.w...@linaro.org
When people (like Charles and Lee have) have reviewed a change you
should add any tags they gave when you resend the change so they don't
have
On Wed, Aug 19, 2015 at 08:02:37AM +0800, Peter Chen wrote:
Below code may be correct for the goal you expressed.
for (i = 0; i ARRAY_SIZE(wm831x_usb_limits); i++) {
if (limit = wm831x_usb_limits[i]
wm831x_usb_limits[best] wm831x_usb_limits[i])
On Tue, Aug 18, 2015 at 01:20:12PM +0800, Peter Chen wrote:
ok, I just had suspected below function's correctness, after looking
it again, it always set 1800 as charging limit, does it be expected?
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i
On Thu, Aug 06, 2015 at 09:39:05AM -0700, Greg KH wrote:
On Thu, Aug 06, 2015 at 03:03:48PM +0800, Baolin Wang wrote:
+static void usb_charger_release(struct device *dev)
+{
+ struct usb_charger *uchger = dev_get_drvdata(dev);
+ if (!atomic_dec_and_test(uchger-count)) {
+
On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> Well, I'm not quite sure why exactly everyone is so focused on probing here.
Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> > To be clear, I was saying that this series should NOT affect total
> > boot times much.
> I'm confused. If I understood correctly, improving boot time was
> the key justification for
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:
> Something like this. I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:
> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem. I think the fact is, there is no data.
> Someone prove me wrong.
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > more in the l
On Fri, Nov 06, 2015 at 08:56:44AM -0800, Greg KH wrote:
> On Fri, Nov 06, 2015 at 07:35:10PM +0800, Baolin Wang wrote:
> > Thus this patch adds a notifier mechanism for usb gadget to report a
> > event to usb charger when the usb gadget state is changed.
> I thought we said we did not want
On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of
On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> > > I can't see adding calls like this all over the tree just to solve a
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > Do you mean firmware rather than bus here? I think that's the confusion
> > I have...
> Certainly, if it literally is adding of_* calls th
On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:
> > Generic subsystem code -> DT
1 - 100 of 185 matches
Mail list logo
