Re: Panda: USB crash with today's linux-next

Re: Panda: USB crash with today's linux-next

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3977 bytes --]

Hi,

On Mon, May 14, 2012 at 02:49:11PM +0300, Tomi Valkeinen wrote:
> Hi Felipe,
> 
> I'm seeing the following crash on Panda, when booting with today's
> linux-next, using the attached config.
> 
>  Tomi
> 
> 
> [    1.923400] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [    1.923400] Unable to handle kernel NULL pointer dereference at virtual address 00000036
> [    1.938171] pgd = c0004000
> [    1.941009] [00000036] *pgd=00000000
> [    1.944763] Internal error: Oops: 5 [#1] SMP ARM
> [    1.949584] Modules linked in:
> [    1.952789] CPU: 0    Not tainted  (3.4.0-rc7-next-20120514-10436-g7769ab8 #450)
> [    1.960540] PC is at kobject_get+0xc/0x4c
> [    1.964721] LR is at get_device+0x14/0x1c
> [    1.968933] pc : [<c0250d60>]    lr : [<c02ac47c>]    psr: 20000113
> sp : ebc31d98  ip : 00000003  fp : eb36d1dc
> [    1.979553] r10: eb36c128  r9 : eb349880  r8 : fc0ab000
> [    1.985015] r7 : eb348408  r6 : c06f2830  r5 : eb348408  r4 : 0000001a
> [    1.991851] r3 : eb349880  r2 : 00000000  r1 : c04bf2b4  r0 : 0000001a
> [    1.998687] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> [    2.006317] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
> [    2.012329] Process swapper/0 (pid: 1, stack limit = 0xebc302f8)
> [    2.018615] Stack: (0xebc31d98 to 0xebc32000)
> [    2.023162] 1d80:                                                       eb349880 c0c788f4
> [    2.031707] 1da0: eb348408 c02ac47c eb349880 c033d604 eb36c128 c035bdc8 c035bdb0 0000007c
> [    2.040283] 1dc0: eb348400 00000010 eb348408 c047dddc ebeba630 00000000 c0c76fd8 eb348408
> [    2.048828] 1de0: c0c76fd8 c0c76fe8 00000000 c071c0ac 00000000 c0728b80 0000009e c02b0e68
> [    2.057373] 1e00: c02b0e50 c02afab8 c02b10f0 eb348408 c02afcd0 00000000 00000000 c0c76f94
> [    2.065948] 1e20: c0728b80 c02ae1dc ebc412d8 ebebbe94 eb348408 eb34843c c070fbc0 c02af9dc
> [    2.074493] 1e40: eb348408 eb348408 c070fbc0 c02aefb8 eb348408 eb348410 ebd7c808 c02ad840
> [    2.083038] 1e60: c06f8438 00000000 ebebbd78 eb3498c0 ebebbd40 c0690444 00000000 eb348400
> [    2.091583] 1e80: eb348408 00000003 eb3498c0 ebebbd40 c0690444 c0728b80 0000009e c02b1480
> [    2.100158] 1ea0: eb348400 00000000 ebd7c808 eb3498c0 ebd7dd00 c047e7a0 ebd7c808 c0c76fd8
> [    2.108703] 1ec0: c0c76fe8 00000000 c071c16c c02b0e68 c02b0e50 c02afab8 22222222 ebd7c808
> [    2.117248] 1ee0: c071c16c ebd7c83c 00000000 c067882c c0728b80 c02afccc c071c16c c02afc38
> [    2.125793] 1f00: 00000000 c02ae258 ebc412a8 ebd76790 c071c16c c070fbc0 ebebbdc0 c02af16c
> [    2.134368] 1f20: c0598c20 00000000 ebc489c0 c071c16c c0728b80 ebc30000 00000000 c067882c
> [    2.142913] 1f40: c0690444 c0728b80 0000009e c02b0200 00000000 c0678844 c0728b80 ebc30000
> [    2.151458] 1f60: 00000000 c067882c c0728b80 c0008730 c061fe04 c06207e4 c149014e c066dbe4
> [    2.160003] 1f80: c0678850 00000000 c05dc310 00000001 00000006 00000006 c058cec4 c0678844
> [    2.168579] 1fa0: 0000001c 00000006 c0678850 c067882c c0690444 c0728b80 0000009e c0647928
> [    2.177124] 1fc0: 00000006 00000006 c06471c4 00000000 00000000 00000000 c0647810 c0014f34
> [    2.185668] 1fe0: 00000013 00000000 00000000 00000000 00000000 c0014f34 81aaaa8a 3a80a8aa
> [    2.194244] [<c0250d60>] (kobject_get+0xc/0x4c) from [<c02ac47c>] (get_device+0x14/0x1c)
> [    2.202697] [<c02ac47c>] (get_device+0x14/0x1c) from [<c033d604>] (usb_get_transceiver+0x1c/0x28)
> [    2.212005] [<c033d604>] (usb_get_transceiver+0x1c/0x28) from [<c035bdc8>] (omap2430_musb_init+0x
> 18/0x184)
> [    2.222106] [<c035bdc8>] (omap2430_musb_init+0x18/0x184) from [<c047dddc>] (musb_probe+0x1bc/0x5a
> 0)
> [    2.231567] [<c047dddc>] (musb_probe+0x1bc/0x5a0) from [<c02b0e68>] (platform_drv_probe+0x18/0x1c

looks like MUSB is probing before transceiver driver... could it be ?
Can you check transceiver has actually probed ? I guess panda's using
twl6030-usb.c

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Panda: USB crash with today's linux-next

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:

> looks like MUSB is probing before transceiver driver... could it be ?
> Can you check transceiver has actually probed ? I guess panda's using
> twl6030-usb.c

Ah. Perhaps it's then about this?

[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
[    0.356079] VUSB: 3300 mV normal standby
[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Panda: USB crash with today's linux-next

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
> On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
> 
> > looks like MUSB is probing before transceiver driver... could it be ?
> > Can you check transceiver has actually probed ? I guess panda's using
> > twl6030-usb.c
> 
> Ah. Perhaps it's then about this?
> 
> [    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
> [    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
> [    0.356079] VUSB: 3300 mV normal standby
> [    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
> [    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
> [    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22

sounds about right. Now, why can't it get the IRQ... Benoit, is this
related to your sparse irq/irq_domain changes ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Panda: USB crash with today's linux-next

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

Hi,

On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
> On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
> > On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
> > 
> > > looks like MUSB is probing before transceiver driver... could it be ?
> > > Can you check transceiver has actually probed ? I guess panda's using
> > > twl6030-usb.c
> > 
> > Ah. Perhaps it's then about this?
> > 
> > [    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
> > [    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
> > [    0.356079] VUSB: 3300 mV normal standby
> > [    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
> > [    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
> > [    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
> 
> sounds about right. Now, why can't it get the IRQ... Benoit, is this
> related to your sparse irq/irq_domain changes ?

Looks like twl6030-irq still missed conversion to threaded IRQ. It still
has that ugly ass kthread to handle the IRQs. Oh well, yet another
broken OMAP driver...

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Panda: USB crash with today's linux-next

[Cousson, Benoit]

On 5/14/2012 2:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
>> On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
>>> On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
>>>
>>>> looks like MUSB is probing before transceiver driver... could it be ?
>>>> Can you check transceiver has actually probed ? I guess panda's using
>>>> twl6030-usb.c
>>>
>>> Ah. Perhaps it's then about this?
>>>
>>> [    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
>>> [    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
>>> [    0.356079] VUSB: 3300 mV normal standby
>>> [    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
>>> [    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
>>> [    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
>>
>> sounds about right. Now, why can't it get the IRQ... Benoit, is this
>> related to your sparse irq/irq_domain changes ?
>
> Looks like twl6030-irq still missed conversion to threaded IRQ. It still
> has that ugly ass kthread to handle the IRQs. Oh well, yet another
> broken OMAP driver...

Well, yeah, I did not clean all that mess.

That being said, we did have some issue recently as well, but due to the 
increase of IRQ number and the fact the NR_IRQS is still used since 
SPARSE_IRQ migration is not completed.

At least we saw similar issue with OMAP5.

Maybe increasing NR_IRQS will fix that, but in this case, it looks like 
the IRQ might already been used by someone else.
This is probably because something is still using the hard coded IRQ 
BASE number from the irqs.h define.

I was planning to get rid of them to highlight the broken driver / board 
that might still used them. But this is on my TODO list :-(

Regards,
Benoit

Re: Panda: USB crash with today's linux-next

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]

Hi,

On Mon, May 14, 2012 at 07:06:25PM +0200, Cousson, Benoit wrote:
> On 5/14/2012 2:47 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
> >>On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
> >>>On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
> >>>
> >>>>looks like MUSB is probing before transceiver driver... could it be ?
> >>>>Can you check transceiver has actually probed ? I guess panda's using
> >>>>twl6030-usb.c
> >>>
> >>>Ah. Perhaps it's then about this?
> >>>
> >>>[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
> >>>[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
> >>>[    0.356079] VUSB: 3300 mV normal standby
> >>>[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
> >>>[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
> >>>[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
> >>
> >>sounds about right. Now, why can't it get the IRQ... Benoit, is this
> >>related to your sparse irq/irq_domain changes ?
> >
> >Looks like twl6030-irq still missed conversion to threaded IRQ. It still
> >has that ugly ass kthread to handle the IRQs. Oh well, yet another
> >broken OMAP driver...
> 
> Well, yeah, I did not clean all that mess.
> 
> That being said, we did have some issue recently as well, but due to
> the increase of IRQ number and the fact the NR_IRQS is still used
> since SPARSE_IRQ migration is not completed.
> 
> At least we saw similar issue with OMAP5.
> 
> Maybe increasing NR_IRQS will fix that, but in this case, it looks
> like the IRQ might already been used by someone else.
> This is probably because something is still using the hard coded IRQ
> BASE number from the irqs.h define.
> 
> I was planning to get rid of them to highlight the broken driver /
> board that might still used them. But this is on my TODO list :-(

another thing you might want to add to your TODO list is implementing
irq_chip properly on twl6030-irq:

$ git grep -e EXPORT_SYMBOL drivers/mfd/twl6030-irq.c
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask);
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask);
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect);

$ git grep -e "twl6030_interrupt_\(mask\|unmask\)" drivers/
drivers/mfd/twl6030-irq.c:int twl6030_interrupt_unmask(u8 bit_mask, u8 offset)
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask);
drivers/mfd/twl6030-irq.c:int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask);
drivers/mfd/twl6030-irq.c:	twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
drivers/mfd/twl6030-irq.c:	twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_mask(TWL6030_RTC_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_mask(TWL6030_RTC_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(0x05, REG_INT_MSK_LINE_C);
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(0x05, REG_INT_MSK_STS_C);
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK,

That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
can you guys look into that ? Probably making something generic using a
threaded IRQ handler ?

I mean, all the MMC core should need is an IRQ number (through GPIOs or
not doesn't/shouldn't matter) and it should be able to use a threaded
IRQ handler to kick the card detection/initialization.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Panda: USB crash with today's linux-next

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [120514 11:04]:
> 
> That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
> can you guys look into that ? Probably making something generic using a
> threaded IRQ handler ?
> 
> I mean, all the MMC core should need is an IRQ number (through GPIOs or
> not doesn't/shouldn't matter) and it should be able to use a threaded
> IRQ handler to kick the card detection/initialization.

That's mostly done.. Just need to update the patches for it.

I posted some patches to take care of the card detection in the MMC
driver by leaving out the platform callbacks:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087303.html

That's using gpiochip_find_by_name(), but after talking with Grant
about that, we agreed gpiochip_find_by_name() should be local as there's
no guarantees about anything with the gpiochip names. 

Regards,

Tony

Re: Panda: USB crash with today's linux-next

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120514 11:19]:
> * Felipe Balbi <balbi@ti.com> [120514 11:04]:
> > 
> > That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
> > can you guys look into that ? Probably making something generic using a
> > threaded IRQ handler ?
> > 
> > I mean, all the MMC core should need is an IRQ number (through GPIOs or
> > not doesn't/shouldn't matter) and it should be able to use a threaded
> > IRQ handler to kick the card detection/initialization.
> 
> That's mostly done.. Just need to update the patches for it.

Mostly done meaning "all the MMC core should need is an IRQ number"
part that is :)
 
> I posted some patches to take care of the card detection in the MMC
> driver by leaving out the platform callbacks:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087303.html
> 
> That's using gpiochip_find_by_name(), but after talking with Grant
> about that, we agreed gpiochip_find_by_name() should be local as there's
> no guarantees about anything with the gpiochip names. 
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Panda: USB crash with today's linux-next

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [120514 11:19]:
> > * Felipe Balbi <balbi@ti.com> [120514 11:04]:
> > > 
> > > That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
> > > can you guys look into that ? Probably making something generic using a
> > > threaded IRQ handler ?
> > > 
> > > I mean, all the MMC core should need is an IRQ number (through GPIOs or
> > > not doesn't/shouldn't matter) and it should be able to use a threaded
> > > IRQ handler to kick the card detection/initialization.
> > 
> > That's mostly done.. Just need to update the patches for it.
> 
> Mostly done meaning "all the MMC core should need is an IRQ number"
> part that is :)

but you've done it for omap_hsmmc.c, right ? What I meant is that the
whole card detection should be done at the MMC framework level.

I mean, if we tell MMC core what's the card detect IRQ number, it should
be able to implement a generic version of omap_hsmmc_detect(). All that
thing does is read the current gpio status number and call
mmc_detect_change().

mmc_detect_change() then kicks a delayed work, which shouldn't be needed
because omap_hsmmc_detect() (or the generic of it) is already using a
threaded IRQ.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Panda: USB crash with today's linux-next

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [120514 12:41]:
> On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120514 11:19]:
> > > * Felipe Balbi <balbi@ti.com> [120514 11:04]:
> > > > 
> > > > That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
> > > > can you guys look into that ? Probably making something generic using a
> > > > threaded IRQ handler ?
> > > > 
> > > > I mean, all the MMC core should need is an IRQ number (through GPIOs or
> > > > not doesn't/shouldn't matter) and it should be able to use a threaded
> > > > IRQ handler to kick the card detection/initialization.
> > > 
> > > That's mostly done.. Just need to update the patches for it.
> > 
> > Mostly done meaning "all the MMC core should need is an IRQ number"
> > part that is :)
> 
> but you've done it for omap_hsmmc.c, right ? What I meant is that the
> whole card detection should be done at the MMC framework level.

Yes what I did was just try to start gettting rid of the platform
callbacks.
 
> I mean, if we tell MMC core what's the card detect IRQ number, it should
> be able to implement a generic version of omap_hsmmc_detect(). All that
> thing does is read the current gpio status number and call
> mmc_detect_change().
> 
> mmc_detect_change() then kicks a delayed work, which shouldn't be needed
> because omap_hsmmc_detect() (or the generic of it) is already using a
> threaded IRQ.

Yeah maybe it's doable.. The MMC driver needs to read the status of the
card insert, but maybe that should be just just gpio_get_value().

Then ideally the MMC driver would not have any knowledge how the GPIO
is handled as it can come from whatever gpiochip using internal GPIO
or TWL GPIO.

Regards,

Tony

Re: Panda: USB crash with today's linux-next

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

On Tue, May 15, 2012 at 01:14:29PM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [120514 12:41]:
> > On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [120514 11:19]:
> > > > * Felipe Balbi <balbi@ti.com> [120514 11:04]:
> > > > > 
> > > > > That whole MMC card detection is also pretty screwed up. Balaji/Venkat,
> > > > > can you guys look into that ? Probably making something generic using a
> > > > > threaded IRQ handler ?
> > > > > 
> > > > > I mean, all the MMC core should need is an IRQ number (through GPIOs or
> > > > > not doesn't/shouldn't matter) and it should be able to use a threaded
> > > > > IRQ handler to kick the card detection/initialization.
> > > > 
> > > > That's mostly done.. Just need to update the patches for it.
> > > 
> > > Mostly done meaning "all the MMC core should need is an IRQ number"
> > > part that is :)
> > 
> > but you've done it for omap_hsmmc.c, right ? What I meant is that the
> > whole card detection should be done at the MMC framework level.
> 
> Yes what I did was just try to start gettting rid of the platform
> callbacks.
>  
> > I mean, if we tell MMC core what's the card detect IRQ number, it should
> > be able to implement a generic version of omap_hsmmc_detect(). All that
> > thing does is read the current gpio status number and call
> > mmc_detect_change().
> > 
> > mmc_detect_change() then kicks a delayed work, which shouldn't be needed
> > because omap_hsmmc_detect() (or the generic of it) is already using a
> > threaded IRQ.
> 
> Yeah maybe it's doable.. The MMC driver needs to read the status of the
> card insert, but maybe that should be just just gpio_get_value().
> 
> Then ideally the MMC driver would not have any knowledge how the GPIO
> is handled as it can come from whatever gpiochip using internal GPIO
> or TWL GPIO.

correct.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]