On Thu, Oct 01, 2015 at 12:29:32PM -0500, Felipe Balbi wrote:
> Frankly, I wanted all of this to be decided in userland with the
> kernel just providing notification and basic safety checks (we don't
> want to allow a bogus userspace daemon frying anybody's devices).
What's the advantage of pushi
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
rrent inputs without drawing more current than specified from others.
>
> Signed-off-by: Mark Brown
> Signed-off-by: Baolin Wang
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 to dupl
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 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:
> > >
On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote:
> On 14 August 2015 at 23:27, Greg KH 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 the GNU General P
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
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 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, 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
signature.asc
Description: Digital signature
On Wed, Oct 29, 2014 at 03:30:18PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 29, 2014 at 10:10:12PM +0000, 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
&g
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 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, yo
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,
> >> + "unsupporte
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 p
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, a
From: Liviu Dudau
Signed-off-by: Liviu Dudau
Signed-off-by: Ryan Harkin
Signed-off-by: Mark Brown
---
drivers/usb/phy/phy-ulpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/phy/phy-ulpi.c b/drivers/usb/phy/phy-ulpi.c
index 17ea3f271bd8..4e3877c329f2 100644
--- a/drivers
From: Liviu Dudau
arm64 architecture handles correctly 64bit DMAs and can enable support
for 64bit EHCI host controllers.
Signed-off-by: Liviu Dudau
Signed-off-by: Ryan Harkin
Signed-off-by: Mark Brown
---
drivers/usb/host/ehci-hcd.c | 12 +---
1 file changed, 9 insertions(+), 3
From: Liviu Dudau
Signed-off-by: Liviu Dudau
Signed-off-by: Ryan Harkin
Signed-off-by: Mark Brown
---
drivers/usb/phy/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index bbe8f15ac014..2a7f6ea1ccfe 100644
--- a
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/ext
On Mon, Apr 14, 2014 at 01:46:12PM +0200, Robert Baldyga wrote:
That's quite some CC list you've got there, and the mail seems a bit
corrupted too (it confused my MUA).
> This patch adds extcon devicetree bindings. Documentation describes in general
> client and provider bindings, and contains de
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 l
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 platform_devic
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 de
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 s
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 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 Tue, Aug 20, 2013 at 09:19:07PM +0800, Ming Lei wrote:
> On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown 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 mea
On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
> On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern 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 little more than a
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
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
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
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 g
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 platfor
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 mec
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 nee
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 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
> &g
On Wed, Aug 14, 2013 at 12:15:13PM -0700, Greg KH wrote:
> On Wed, Aug 14, 2013 at 08:04:10PM +0100, Mark Brown wrote:
> > In order for deferred probing to help the device would need to acquire
> > some resource from the parent USB controller once active, allowing it to
> > d
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 probi
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
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 curr
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 _wo
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
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 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 c
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
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 Sun, Aug 11, 2013 at 11:08:37PM +0100, Grant Likely wrote:
> full enumerating like that with either ACPI or FDT, but we could allow
> for sparse population of devices when something is fixed like a
> soldered down USB hub or USB Ethernet MAC.
I agree, there's no point in listing things that ca
On Wed, Aug 07, 2013 at 08:51:27AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Using SIMPLE_DEV_PM_OPS can make the code simpler and cleaner.
>
> Signed-off-by: Fabio Estevam
Reviewed-by: Mark Brown
signature.asc
Description: Digital signature
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 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 drive
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
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 wher
From: Mark Brown
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 to be fully idle when not in
From: Mark Brown
Make functions that are only referenced from ops structures static, they
do not need to be in the global namespace and sparse complains about this.
Signed-off-by: Mark Brown
---
drivers/net/usb/ax88172a.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff
From: Mark Brown
Ensure that the definition of ax88172a_info matches the declaration seen
by users and silence sparse warnings about symbols without declarations
in the global namespace by moving the declaration into the shared header
asix.h.
Signed-off-by: Mark Brown
---
drivers/net/usb
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
From: Mark Brown
Saves us a bit of code.
Signed-off-by: Mark Brown
---
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/usb3503.c
index 8c06eb2..2e9e100
From: Mark Brown
Signed-off-by: Mark Brown
---
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/usb3503.c
+++ b/drivers/usb/misc
From: Mark Brown
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
Cc: devicet
From: Mark Brown
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
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/usb/usb3503.txt | 2 ++
1 file
From: Mark Brown
This will give access to the diagnostic infrastructure regmap has but
the main point is to support future refactoring.
Signed-off-by: Mark Brown
---
drivers/usb/misc/Kconfig | 1 +
drivers/usb/misc/usb3503.c | 93 ++
2 files
From: Mark Brown
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
---
drivers/usb/misc/usb3503.c | 4
From: Mark Brown
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
---
drivers/usb/misc/usb3503.c
From: Mark Brown
If the connect signal is pulled high then the device will start up meaning
that if we just pull it high on probe then the device will start running
prior to the configuration being written out. Fix this by pulling the GPIO
low when we reset and only pulling it high when
From: Mark Brown
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
---
Documentation/devicetree/bindings/usb/usb3503.txt | 2 +-
drivers/usb/misc/usb3503.c
From: Mark Brown
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.c b/driver
From: Mark Brown
Since there is no runtime interface for changing modes this is probably
the most sensible default.
Signed-off-by: Mark Brown
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc
From: Mark Brown
Systems with the common clock API need clk_prepare() as well as the enable
step.
Signed-off-by: Mark Brown
---
drivers/usb/phy/phy-nop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index f52b7f8
From: Mark Brown
If someone provided meaningful error codes from reset() we should tell the
user what they were.
Signed-off-by: Mark Brown
---
drivers/usb/core/hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index
From: Mark Brown
Saves us a bit of code.
Signed-off-by: Mark Brown
---
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 insertions(+), 35
From: Mark Brown
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
---
drivers/usb/misc/usb3503.c | 4
On Tue, Aug 06, 2013 at 10:35:52PM -0300, Fabio Estevam wrote:
> On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown wrote:
> > From: Andy Green
> >
> > You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
> > case these are unused.
> >
> > Si
From: Andy Green
You might have CONFIG_PM, but you might not have CONFIG_SUSPEND, in which
case these are unused.
Signed-off-by: Andy Green
Signed-off-by: Mark Brown
---
drivers/usb/dwc3/dwc3-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3
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 neede
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 wha
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 dri
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
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 all
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 dri
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
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
signature.asc
Description: Digital signature
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 th
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
> poi
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 t
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
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
>
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 kern
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 th
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 dep
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
D
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 res
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
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 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. S
101 - 197 of 197 matches
Mail list logo
