Nokia N900: musb is in wrong state after boot

Hello,

when I boot 4.4.0-rc7+ kernel compiled with g_nokia into zImage on Nokia N900 into userspace then usb gadget (g_nokia) does not work. Notebook, connected on other side does not see any usb device... Connecting and disconnecting cable does not change anything, still not work.

But if I run this command

$ echo peripheral > /sys/bus/platform/devices/musb-hdrc.0.auto/mode 

then gadget starts working. Other side see usb device and can use it. Also connecting and disconnecting usb cable working fine. After connecting it again, usb device OK.

Hi,

Quoted 9 lines · Pali Rohár

Hello,

when I boot 4.4.0-rc7+ kernel compiled with g_nokia into zImage on Nokia N900 into userspace then usb gadget (g_nokia) does not work. Notebook, connected on other side does not see any usb device... Connecting and disconnecting cable does not change anything, still not work.

But if I run this command

$ echo peripheral > /sys/bus/platform/devices/musb-hdrc.0.auto/mode 

Quoted 3 lines

then gadget starts working. Other side see usb device and can use it. Also connecting and disconnecting usb cable working fine. After connecting it again, usb device OK.

N900 had the PHY interrupt wired to the bq chip instead of twl4030, right?

You can fix this issue similar to phy-twl4030-usb.c. In function twl4030_phy_power_on() we call schedule_delayed_work() that checks the state of the ID pin on boot up.

I think that's only needed for the i2c based PHY's with MUSB, with the others the USB driver has a better idea of the current state.

Regards,

Tony

I do not know now. I tried to find it in N900 schemantics, but do not see it.

CCing Joerg, do you know?

Quoted 1 line · Pali Rohár

Quoted 5 lines

I do not know now. I tried to find it in N900 schemantics, but do not see it.

CCing Joerg, do you know?

http://plan9.stanleylieber.com/hardware/n900/n900.schematics.pdf

You probably forgot to specify page in PDF or other location where is that PHY interrupt. As I wrote I tried to find it, but do not see it there.

Quoted 14 lines · On Tuesday 19 January 2016 12:33:15 Tony Lindgren wrote:

Hi,

Quoted 11 lines · Pali Rohár

Hello,

when I boot 4.4.0-rc7+ kernel compiled with g_nokia into zImage on Nokia N900 into userspace then usb gadget (g_nokia) does not work. Notebook, connected on other side does not see any usb device... Connecting and disconnecting cable does not change anything, still not work.

But if I run this command

$ echo peripheral > /sys/bus/platform/devices/musb-hdrc.0.auto/mode

Quoted 5 lines

Quoted 3 lines

then gadget starts working. Other side see usb device and can use it. Also connecting and disconnecting usb cable working fine. After connecting it again, usb device OK.

N900 had the PHY interrupt wired to the bq chip instead of twl4030, right?

I do not know now. I tried to find it in N900 schemantics, but do not see it.

CCing Joerg, do you know?

Quoted 3 lines

You can fix this issue similar to phy-twl4030-usb.c. In function twl4030_phy_power_on() we call schedule_delayed_work() that checks the state of the ID pin on boot up.

I looked at that code, but do not see what and how can be fixed :-(

Quoted 6 lines

I think that's only needed for the i2c based PHY's with MUSB, with the others the USB driver has a better idea of the current state.

Regards,

Tony

Quoted 19 lines · On Thu 21 January 2016 09:40:07 Pali Rohár wrote:

Quoted 18 lines · On Tuesday 19 January 2016 12:33:15 Tony Lindgren wrote:

Hi,

Quoted 14 lines · Pali Rohár

Hello,

when I boot 4.4.0-rc7+ kernel compiled with g_nokia into zImage on Nokia N900 into userspace then usb gadget (g_nokia) does not work. Notebook, connected on other side does not see any usb device... Connecting and disconnecting cable does not change anything, still not work.

But if I run this command

$ echo peripheral > /sys/bus/platform/devices/musb-hdrc.0.auto/mode

then gadget starts working. Other side see usb device and can use it. Also connecting and disconnecting usb cable working fine. After connecting it again, usb device OK.

Quoted 1 line

Quoted 1 line

N900 had the PHY interrupt wired to the bq chip instead of twl4030, right?

which interrupt? I'll try to answer based on assumptions: 1707 PHY connects to bq24150 charger via CHRG_DET signal.
I guess you're talking about the VBUS detection which is done in twl4030 VBUS- pin R8.

N900 PHY (1707) is connected to musb core via ULPI
(https://www.mentor.com/products/ip/usb/usb20otg/phy_interfaces), it has no I2C interface and no other IRQ than what's implemented in (normally powered- down?) ULPI already.
I guess the problem in this case is along the USB VBUS and ID pin A/B OTG
detection: the USB jack's ID pin is _not_ connected to the PHY in N900 but rather is connected to TWL4030 aka GAIA ID pin R11 which afaik is part of the otherwise unused (except VBUS detection?) PHY in TWL4030.
It seems to me the actually used PHY 1707 does not support ID, neither does it support a dedicated IRQ line for VBUS.

Generally musb-core and buses should be suspended/off by default, for energy conservation reasons (seemingly ~40mA on Vbatt!), and only get enabled when twl4030 detects +5V on VBUS (also before my hostmode botch tries to talk to the musb core debug registers which needs to happen before VBUS gets applied)

Then for supporting the USB host mode.. We should add regulator support to the USB PHY driver so if the ID pin is grounded, the PHY driver enables the VBUS regulator. That too seems to need some coordination between the drivers/phy/phy-twl4030-usb.c and 1707 driver if the ID pin interrupt is only detected in drivers/phy/phy-twl4030-usb.c.

Quoted 5 lines · On Thu 21 January 2016 09:41:46 Tony Lindgren wrote:

Then for supporting the USB host mode.. We should add regulator support to the USB PHY driver so if the ID pin is grounded, the PHY driver enables the VBUS regulator. That too seems to need some coordination between the drivers/phy/phy-twl4030-usb.c and 1707 driver if the ID pin interrupt is only detected in drivers/phy/phy-twl4030-usb.c.

Note that, while this is probably a good thing to do, it needs to be sufficiently loose coupling to allow user to 'intercept' this VBOOS regulator enabling and instead allow device charging while in externally powered hostmode. There's even a spec for this in USB-docs-foo iirc, something along a certain resistor value on ID to GND - alas I guess the twl4030 is not capable to detect such sophisticated signaling, and anyway it's always desirable to allow user to manually override the VBOOST and enable VBUS-charging while in hostmode.

On N900 the situation is even more complex since the 1707 doesn't support genuine ID detection, neither does it support emulated ID grounding. And there's no other method than a ID=GND message from PHY to musb core to make the musb core state engine transfer into proper hostmode. Thus my H-E-N hostmode botch abuses debug flags to force the musb core into a "emulated" hostmode and this mode doesn't support USB speed detection. Thus speed settings are forced onto musb core and PHY by software, and the musb core speed bits are only effective before session enabled.
Bottom line: you need VBUS to try and negotiate speed with the attached device in hostmode, but to actually set this speed you detected by software means, you need to disable and discharge VBUS again, or musb core won't care about the speed you set. To be utterly clear: unconditional enabling of VBUS in ID=GND won't work.

This is quite complex and it's questionable if it could get handled reasonably in kernel space. *Very* N900 specific niche solution, I'd not think it's suited for upstreaming.

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 11 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

Quoted 13 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 11 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

First I would like to have fully working peripheral mode on Nokia N900 and then we can try to hack host mode (if possible).

But peripheral mode is a must due to development, because it provides usb network or usb tty.

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

Quoted 5 lines

First I would like to have fully working peripheral mode on Nokia N900 and then we can try to hack host mode (if possible).

But peripheral mode is a must due to development, because it provides usb network or usb tty.

Totally.

Regards,

Tony

Quoted 16 lines · On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote:

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

Quoted 17 lines · Pali Rohár

Quoted 16 lines · On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote:

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

about why peripheral mode doesn't work on n900 ? No idea. that's always the default role of MUSB and last I checked, before stopping working on this, BBB was working just fine.

N900 is odd in that it has two PHYs (1701 handles data lines while twl4030 handles power lines, IIRC), but peripheral should be working.

The only reason for MUSB to not start would be that it's not detecting VBUS being above session valid threshold, however twl4030 should have an IRQ for that.

What happens when cable is attached ? Any IRQs anywhere firing ?

Quoted 38 lines · On Monday 22 February 2016 09:31:50 Felipe Balbi wrote:

Quoted 17 lines · Pali Rohár

Quoted 16 lines · On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote:

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

about why peripheral mode doesn't work on n900 ? No idea. that's always the default role of MUSB and last I checked, before stopping working on this, BBB was working just fine.

N900 is odd in that it has two PHYs (1701 handles data lines while twl4030 handles power lines, IIRC), but peripheral should be working.

The only reason for MUSB to not start would be that it's not detecting VBUS being above session valid threshold, however twl4030 should have an IRQ for that.

Quoted 2 lines

What happens when cable is attached ? Any IRQs anywhere firing ?

Just to note, when I call echo peripheral > mode then detecting usb cable starts working and usb peripheral mode also works fine (also after disconnecting and connecting usb cable again). Read my first post in this thread, there are also some logs:
https://lkml.org/lkml/2016/1/9/69

Quoted 38 lines · On Monday 22 February 2016 09:31:50 Felipe Balbi wrote:

Quoted 17 lines · Pali Rohár

Quoted 16 lines · On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote:

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

about why peripheral mode doesn't work on n900 ? No idea. that's always the default role of MUSB and last I checked, before stopping working on this, BBB was working just fine.

N900 is odd in that it has two PHYs (1701 handles data lines while twl4030 handles power lines, IIRC), but peripheral should be working.

The only reason for MUSB to not start would be that it's not detecting VBUS being above session valid threshold, however twl4030 should have an IRQ for that.

Quoted 2 lines

What happens when cable is attached ? Any IRQs anywhere firing ?

Just to note, when I call echo peripheral > mode then detecting usb cable starts working and usb peripheral mode also works fine (also after disconnecting and connecting usb cable again). Read my first post in this thread, there are also some logs:
https://lkml.org/lkml/2016/1/9/69

Hi,

Quoted 39 lines · Pali Rohár

Quoted 38 lines · On Monday 22 February 2016 09:31:50 Felipe Balbi wrote:

Quoted 17 lines · Pali Rohár

Quoted 16 lines · On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote:

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

about why peripheral mode doesn't work on n900 ? No idea. that's always the default role of MUSB and last I checked, before stopping working on this, BBB was working just fine.

N900 is odd in that it has two PHYs (1701 handles data lines while twl4030 handles power lines, IIRC), but peripheral should be working.

The only reason for MUSB to not start would be that it's not detecting VBUS being above session valid threshold, however twl4030 should have an IRQ for that.

Quoted 8 lines

Quoted 2 lines

What happens when cable is attached ? Any IRQs anywhere firing ?

Just to note, when I call echo peripheral > mode then detecting usb cable starts working and usb peripheral mode also works fine (also after disconnecting and connecting usb cable again). Read my first post in this thread, there are also some logs:
https://lkml.org/lkml/2016/1/9/69

interesting... that softconnect interface looks odd. We _know_ the value of softconnect from musb->softconnect. /me reads commit which added it... Oh okay, that's only valid for host mode. Argh!

Okay, the session bit is _NOT_ set when it should be. Note that DevCtl reads as 0x98. Bit 0 is Session bit and that's not set. MUSB _is_ in the device mode (bit 7 set).

For some reason DevCtl didn't get set. Care to add a print to musb_gadget_pullup() to see when/if it's called ?

BTW, Bin will be maintaining MUSB going forward.

Signature · 1 line

balbi

Hi,

Quoted 52 lines · Felipe Balbi

Hi,

Quoted 39 lines · Pali Rohár

Quoted 38 lines · On Monday 22 February 2016 09:31:50 Felipe Balbi wrote:

Quoted 17 lines · Pali Rohár

Quoted 16 lines · On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote:

Quoted 15 lines · Pali Rohár

Quoted 14 lines · On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:

Quoted 12 lines · joerg Reisenweber

Quoted 3 lines · On Thu 21 January 2016 11:21:13 Tony Lindgren wrote:

Do you have some pointer
to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

""Three additional ID pin states are defined[4] at the nominal resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect to the ground pin. These permit the device to work with USB Accessory Charger Adapters that allows the OTG device to be attached to both a charger and another device simultaneously. [6]""
https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

OK thanks. So it's the "accessory charger" part of the battery charging specification 1.1.

So, Tony, do you have some idea what needs to be changed and how to fix peripheral mode after boot on Nokia N900?

No, I'm waiting to hear an educated guess from Felipe on this one.

about why peripheral mode doesn't work on n900 ? No idea. that's always the default role of MUSB and last I checked, before stopping working on this, BBB was working just fine.

N900 is odd in that it has two PHYs (1701 handles data lines while twl4030 handles power lines, IIRC), but peripheral should be working.

The only reason for MUSB to not start would be that it's not detecting VBUS being above session valid threshold, however twl4030 should have an IRQ for that.

Quoted 8 lines

Quoted 2 lines

What happens when cable is attached ? Any IRQs anywhere firing ?

Just to note, when I call echo peripheral > mode then detecting usb cable starts working and usb peripheral mode also works fine (also after disconnecting and connecting usb cable again). Read my first post in this thread, there are also some logs:
https://lkml.org/lkml/2016/1/9/69

Quoted 3 lines

interesting... that softconnect interface looks odd. We _know_ the value of softconnect from musb->softconnect. /me reads commit which added it... Oh okay, that's only valid for host mode. Argh!

softconnet bit is only valid for *peripheral* mode, but the bit is not set in this case, so the host will not be able to detect the device.

Pali,

Is this never worked or just broken recently? If latter, possible to git-bisect to find out which patch causes softconnect bit not set?

Regards,
-Bin.

Quoted 10 lines

Okay, the session bit is _NOT_ set when it should be. Note that DevCtl reads as 0x98. Bit 0 is Session bit and that's not set. MUSB _is_ in the device mode (bit 7 set).

For some reason DevCtl didn't get set. Care to add a print to musb_gadget_pullup() to see when/if it's called ?

BTW, Bin will be maintaining MUSB going forward.

Quoted 2 lines

--
balbi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 8 lines · joerg Reisenweber

Quoted 6 lines · On Thu 21 January 2016 09:41:46 Tony Lindgren wrote:

Then for supporting the USB host mode.. We should add regulator support to the USB PHY driver so if the ID pin is grounded, the PHY driver enables the VBUS regulator. That too seems to need some coordination between the drivers/phy/phy-twl4030-usb.c and 1707 driver if the ID pin interrupt is only detected in drivers/phy/phy-twl4030-usb.c.

Quoted 9 lines

Note that, while this is probably a good thing to do, it needs to be sufficiently loose coupling to allow user to 'intercept' this VBOOS regulator enabling and instead allow device charging while in externally powered hostmode. There's even a spec for this in USB-docs-foo iirc, something along a certain resistor value on ID to GND - alas I guess the twl4030 is not capable to detect such sophisticated signaling, and anyway it's always desirable to allow user to manually override the VBOOST and enable VBUS-charging while in hostmode.

OK, I think this is what's happening with the Motorola LapDock BTW. It always feeds the VBUS, well most of the time. Do you have some pointer to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

Quoted 16 lines

On N900 the situation is even more complex since the 1707 doesn't support genuine ID detection, neither does it support emulated ID grounding. And there's no other method than a ID=GND message from PHY to musb core to make the musb core state engine transfer into proper hostmode. Thus my H-E-N hostmode botch abuses debug flags to force the musb core into a "emulated" hostmode and this mode doesn't support USB speed detection. Thus speed settings are forced onto musb core and PHY by software, and the musb core speed bits are only effective before session enabled.
Bottom line: you need VBUS to try and negotiate speed with the attached device in hostmode, but to actually set this speed you detected by software means, you need to disable and discharge VBUS again, or musb core won't care about the speed you set. To be utterly clear: unconditional enabling of VBUS in ID=GND won't work.

Quoted 3 lines

This is quite complex and it's questionable if it could get handled reasonably in kernel space. *Very* N900 specific niche solution, I'd not think it's suited for upstreaming.

Yeah OK. I think we should be able to support the aux VBUS regulator part with mainline kernel though.

Regards,

Tony

Quoted 44 lines · On Thursday 21 January 2016 20:21:13 Tony Lindgren wrote:

Quoted 8 lines · joerg Reisenweber

Quoted 6 lines · On Thu 21 January 2016 09:41:46 Tony Lindgren wrote:

Then for supporting the USB host mode.. We should add regulator support to the USB PHY driver so if the ID pin is grounded, the PHY driver enables the VBUS regulator. That too seems to need some coordination between the drivers/phy/phy-twl4030-usb.c and 1707 driver if the ID pin interrupt is only detected in drivers/phy/phy-twl4030-usb.c.

Quoted 9 lines

Note that, while this is probably a good thing to do, it needs to be sufficiently loose coupling to allow user to 'intercept' this VBOOS regulator enabling and instead allow device charging while in externally powered hostmode. There's even a spec for this in USB-docs-foo iirc, something along a certain resistor value on ID to GND - alas I guess the twl4030 is not capable to detect such sophisticated signaling, and anyway it's always desirable to allow user to manually override the VBOOST and enable VBUS-charging while in hostmode.

OK, I think this is what's happening with the Motorola LapDock BTW. It always feeds the VBUS, well most of the time. Do you have some pointer to the "certain resistor value on ID to GND" spec? Is it maybe part of the carkit related parts of the USB spec?

Quoted 16 lines

On N900 the situation is even more complex since the 1707 doesn't support genuine ID detection, neither does it support emulated ID grounding. And there's no other method than a ID=GND message from PHY to musb core to make the musb core state engine transfer into proper hostmode. Thus my H-E-N hostmode botch abuses debug flags to force the musb core into a "emulated" hostmode and this mode doesn't support USB speed detection. Thus speed settings are forced onto musb core and PHY by software, and the musb core speed bits are only effective before session enabled.
Bottom line: you need VBUS to try and negotiate speed with the attached device in hostmode, but to actually set this speed you detected by software means, you need to disable and discharge VBUS again, or musb core won't care about the speed you set. To be utterly clear: unconditional enabling of VBUS in ID=GND won't work.

Quoted 3 lines

This is quite complex and it's questionable if it could get handled reasonably in kernel space. *Very* N900 specific niche solution, I'd not think it's suited for upstreaming.

Quoted 6 lines

Yeah OK. I think we should be able to support the aux VBUS regulator part with mainline kernel though.

Regards,

Tony

Hello, attached patch for musb debugfs adds option to force both hostmode with speed. It is just example, I tested only compilation.

Something like that will be needed for usb host mode on Nokia N900.

Signature · 12 lines

Pali Rohár
[email protected]

From fd67b58e3538c0732750ecad915cde736da099dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <[email protected]>
Date: Sat, 9 Jan 2016 16:57:59 +0100
Subject: [PATCH] musb: debugfs: Add support in testmode for forcing host mode
 together with speed

---
 drivers/usb/musb/musb_debugfs.c |   44 +++++++++++++++++++++++++--------------
 1 file changed, 28 insertions(+), 16 deletions(-)

drivers/usb/musb/musb_debugfs.c +28 -16

index 9b22d94..62c13a2 100644
@@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, void *unused)
 
 	test = musb_readb(musb->mregs, MUSB_TESTMODE);
 
-	if (test & MUSB_TEST_FORCE_HOST)
+	if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+		seq_printf(s, "force host full-speed\n");
+
+	else if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+		seq_printf(s, "force host high-speed\n");
+
+	else if (test & MUSB_TEST_FORCE_HOST)
 		seq_printf(s, "force host\n");
 
-	if (test & MUSB_TEST_FIFO_ACCESS)
+	else if (test & MUSB_TEST_FIFO_ACCESS)
 		seq_printf(s, "fifo access\n");
 
-	if (test & MUSB_TEST_FORCE_FS)
+	else if (test & MUSB_TEST_FORCE_FS)
 		seq_printf(s, "force full-speed\n");
 
-	if (test & MUSB_TEST_FORCE_HS)
+	else if (test & MUSB_TEST_FORCE_HS)
 		seq_printf(s, "force high-speed\n");
 
-	if (test & MUSB_TEST_PACKET)
+	else if (test & MUSB_TEST_PACKET)
 		seq_printf(s, "test packet\n");
 
-	if (test & MUSB_TEST_K)
+	else if (test & MUSB_TEST_K)
 		seq_printf(s, "test K\n");
 
-	if (test & MUSB_TEST_J)
+	else if (test & MUSB_TEST_J)
 		seq_printf(s, "test J\n");
 
-	if (test & MUSB_TEST_SE0_NAK)
+	else if (test & MUSB_TEST_SE0_NAK)
 		seq_printf(s, "test SE0 NAK\n");
 
 	return 0;

@@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
 	if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
 		return -EFAULT;
 
-	if (strstarts(buf, "force host"))
+	if (strstarts(buf, "force host full-speed"))
+		test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+	else if (strstarts(buf, "force host high-speed"))
+		test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+	else if (strstarts(buf, "force host"))
 		test = MUSB_TEST_FORCE_HOST;
 
-	if (strstarts(buf, "fifo access"))
+	else if (strstarts(buf, "fifo access"))
 		test = MUSB_TEST_FIFO_ACCESS;
 
-	if (strstarts(buf, "force full-speed"))
+	else if (strstarts(buf, "force full-speed"))
 		test = MUSB_TEST_FORCE_FS;
 
-	if (strstarts(buf, "force high-speed"))
+	else if (strstarts(buf, "force high-speed"))
 		test = MUSB_TEST_FORCE_HS;
 
-	if (strstarts(buf, "test packet")) {
+	else if (strstarts(buf, "test packet")) {
 		test = MUSB_TEST_PACKET;
 		musb_load_testpacket(musb);
 	}
 
-	if (strstarts(buf, "test K"))
+	else if (strstarts(buf, "test K"))
 		test = MUSB_TEST_K;
 
-	if (strstarts(buf, "test J"))
+	else if (strstarts(buf, "test J"))
 		test = MUSB_TEST_J;
 
-	if (strstarts(buf, "test SE0 NAK"))
+	else if (strstarts(buf, "test SE0 NAK"))
 		test = MUSB_TEST_SE0_NAK;
 
 	musb_writeb(musb->mregs, MUSB_TESTMODE, test);

Signature · 1 line

1.7.9.5

Quoted 101 lines

From fd67b58e3538c0732750ecad915cde736da099dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <[email protected]>
Date: Sat, 9 Jan 2016 16:57:59 +0100
Subject: [PATCH] musb: debugfs: Add support in testmode for forcing host mode
together with speed

---
 drivers/usb/musb/musb_debugfs.c |   44 +++++++++++++++++++++++++--------------
 1 file changed, 28 insertions(+), 16 deletions(-)

drivers/usb/musb/musb_debugfs.c +28 -16

index 9b22d94..62c13a2 100644
@@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, void *unused)
 
 	test = musb_readb(musb->mregs, MUSB_TESTMODE);
 
-	if (test & MUSB_TEST_FORCE_HOST)
+	if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+		seq_printf(s, "force host full-speed\n");
+
+	else if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+		seq_printf(s, "force host high-speed\n");
+
+	else if (test & MUSB_TEST_FORCE_HOST)
 		seq_printf(s, "force host\n");
 
-	if (test & MUSB_TEST_FIFO_ACCESS)
+	else if (test & MUSB_TEST_FIFO_ACCESS)
 		seq_printf(s, "fifo access\n");
 
-	if (test & MUSB_TEST_FORCE_FS)
+	else if (test & MUSB_TEST_FORCE_FS)
 		seq_printf(s, "force full-speed\n");
 
-	if (test & MUSB_TEST_FORCE_HS)
+	else if (test & MUSB_TEST_FORCE_HS)
 		seq_printf(s, "force high-speed\n");
 
-	if (test & MUSB_TEST_PACKET)
+	else if (test & MUSB_TEST_PACKET)
 		seq_printf(s, "test packet\n");
 
-	if (test & MUSB_TEST_K)
+	else if (test & MUSB_TEST_K)
 		seq_printf(s, "test K\n");
 
-	if (test & MUSB_TEST_J)
+	else if (test & MUSB_TEST_J)
 		seq_printf(s, "test J\n");
 
-	if (test & MUSB_TEST_SE0_NAK)
+	else if (test & MUSB_TEST_SE0_NAK)
 		seq_printf(s, "test SE0 NAK\n");
 
 	return 0;

@@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
 	if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
 		return -EFAULT;
 
-	if (strstarts(buf, "force host"))
+	if (strstarts(buf, "force host full-speed"))
+		test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+	else if (strstarts(buf, "force host high-speed"))
+		test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+	else if (strstarts(buf, "force host"))
 		test = MUSB_TEST_FORCE_HOST;
 
-	if (strstarts(buf, "fifo access"))
+	else if (strstarts(buf, "fifo access"))
 		test = MUSB_TEST_FIFO_ACCESS;
 
-	if (strstarts(buf, "force full-speed"))
+	else if (strstarts(buf, "force full-speed"))
 		test = MUSB_TEST_FORCE_FS;
 
-	if (strstarts(buf, "force high-speed"))
+	else if (strstarts(buf, "force high-speed"))
 		test = MUSB_TEST_FORCE_HS;
 
-	if (strstarts(buf, "test packet")) {
+	else if (strstarts(buf, "test packet")) {
 		test = MUSB_TEST_PACKET;
 		musb_load_testpacket(musb);
 	}
 
-	if (strstarts(buf, "test K"))
+	else if (strstarts(buf, "test K"))
 		test = MUSB_TEST_K;
 
-	if (strstarts(buf, "test J"))
+	else if (strstarts(buf, "test J"))
 		test = MUSB_TEST_J;
 
-	if (strstarts(buf, "test SE0 NAK"))
+	else if (strstarts(buf, "test SE0 NAK"))
 		test = MUSB_TEST_SE0_NAK;
 

Quoted 4 lines

drivers/usb/musb/musb_debugfs.c +0 -0

 	musb_writeb(musb->mregs, MUSB_TESTMODE, test);

Signature · 1 line

1.7.9.5

Tony, what do you think about that patch?

Quoted 2 lines

Tony, what do you think about that patch?

Tony, PING

Quoted 4 lines · Pali Rohár

Quoted 2 lines

Tony, what do you think about that patch?

Tony, PING

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY registers directly, that should be the generic musb_set_mode() that we've been wondering about for years.

Hi,

Quoted 10 lines · Tony Lindgren

Quoted 3 lines · Pali Rohár

Quoted 1 line

Tony, what do you think about that patch?

Tony, PING

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY registers directly, that should be the generic musb_set_mode() that we've been wondering about for years.

#define MUSB_TEST_FORCE_HOST 0x80

Can someone confirm on MUSB's docs (and actual running system) that this does what's supposed to do?

Hi,

Quoted 2 lines · Tony Lindgren

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured

#define MUSB_TEST_FORCE_HOST 0x80

Can someone confirm on MUSB's docs (and actual running system) that this does what's supposed to do?

Quoted 11 lines · Pali Rohár

Quoted 4 lines

Quoted 2 lines

Tony, what do you think about that patch?

Tony, PING

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY registers directly, that should be the generic musb_set_mode() that we've been wondering about for years.

#define MUSB_TEST_FORCE_HOST 0x80

Can someone confirm on MUSB's docs (and actual running system) that this does what's supposed to do?

Quoted 13 lines · Felipe Balbi

Quoted 10 lines · Pali Rohár

Quoted 3 lines

Quoted 1 line

Tony, what do you think about that patch?

Tony, PING

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY registers directly, that should be the generic musb_set_mode() that we've been wondering about for years.

#define MUSB_TEST_FORCE_HOST 0x80

Quoted 2 lines

Can someone confirm on MUSB's docs (and actual running system) that this does what's supposed to do?

The MUSB programmer's guide says the CID (sic) input is ignored when the
Force_Host bit is set. The host mode is entered when the Session bit is set. But I don't have a MUSB hardware readily available to confirm.

MBR, Sergei

Quoted 12 lines

Quoted 12 lines

Quoted 9 lines

Quoted 3 lines

Quoted 1 line

Tony, what do you think about that patch?

Tony, PING

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY registers directly, that should be the generic musb_set_mode() that we've been wondering about for years.

#define MUSB_TEST_FORCE_HOST 0x80

Quoted 8 lines

Quoted 2 lines

Can someone confirm on MUSB's docs (and actual running system) that this does what's supposed to do?

The MUSB programmer's guide says the CID (sic) input is ignored when the
Force_Host bit is set. The host mode is entered when the Session bit is set. But I don't have a MUSB hardware readily available to confirm.

MBR, Sergei

also says:

While the FORCE_HOST bit remains set, the core will enter Host mode when the Session bit is set and **remain in Host mode until the Session bit is cleared even if a connected device is disconnected during the session.** The operating speed while in this mode **is determined for the setting of the FORCE_HS and FORCE_FS bits of the Testmode register** in Section 23.1.4.11.

/j

Hi,

Quoted 11 lines · Tony Lindgren

Quoted 4 lines · Pali Rohár

Quoted 2 lines

Tony, what do you think about that patch?

Tony, PING

Yeah I don't know, AFAIK we don't have a generic way to force MUSB to change mode without ID pin. If you have figured something generic for that which does not actually tinker with the PHY registers directly, that should be the generic musb_set_mode() that we've been wondering about for years.

#define MUSB_TEST_FORCE_HOST 0x80

Can someone confirm on MUSB's docs (and actual running system) that this does what's supposed to do?

Quoted 110 lines

Hello, attached patch for musb debugfs adds option to force both hostmode with speed. It is just example, I tested only compilation.

Something like that will be needed for usb host mode on Nokia N900.

Signature · 12 lines

Pali Rohár
[email protected]

From fd67b58e3538c0732750ecad915cde736da099dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <[email protected]>
Date: Sat, 9 Jan 2016 16:57:59 +0100
Subject: [PATCH] musb: debugfs: Add support in testmode for forcing host mode
 together with speed

---
 drivers/usb/musb/musb_debugfs.c |   44 +++++++++++++++++++++++++--------------
 1 file changed, 28 insertions(+), 16 deletions(-)

drivers/usb/musb/musb_debugfs.c +28 -16

index 9b22d94..62c13a2 100644
@@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, void *unused)
 
 	test = musb_readb(musb->mregs, MUSB_TESTMODE);
 
-	if (test & MUSB_TEST_FORCE_HOST)
+	if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+		seq_printf(s, "force host full-speed\n");
+
+	else if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+		seq_printf(s, "force host high-speed\n");
+
+	else if (test & MUSB_TEST_FORCE_HOST)
 		seq_printf(s, "force host\n");
 
-	if (test & MUSB_TEST_FIFO_ACCESS)
+	else if (test & MUSB_TEST_FIFO_ACCESS)
 		seq_printf(s, "fifo access\n");
 
-	if (test & MUSB_TEST_FORCE_FS)
+	else if (test & MUSB_TEST_FORCE_FS)
 		seq_printf(s, "force full-speed\n");
 
-	if (test & MUSB_TEST_FORCE_HS)
+	else if (test & MUSB_TEST_FORCE_HS)
 		seq_printf(s, "force high-speed\n");
 
-	if (test & MUSB_TEST_PACKET)
+	else if (test & MUSB_TEST_PACKET)
 		seq_printf(s, "test packet\n");
 
-	if (test & MUSB_TEST_K)
+	else if (test & MUSB_TEST_K)
 		seq_printf(s, "test K\n");
 
-	if (test & MUSB_TEST_J)
+	else if (test & MUSB_TEST_J)
 		seq_printf(s, "test J\n");
 
-	if (test & MUSB_TEST_SE0_NAK)
+	else if (test & MUSB_TEST_SE0_NAK)
 		seq_printf(s, "test SE0 NAK\n");
 
 	return 0;

@@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
 	if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
 		return -EFAULT;
 
-	if (strstarts(buf, "force host"))
+	if (strstarts(buf, "force host full-speed"))
+		test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+	else if (strstarts(buf, "force host high-speed"))
+		test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+	else if (strstarts(buf, "force host"))
 		test = MUSB_TEST_FORCE_HOST;
 
-	if (strstarts(buf, "fifo access"))
+	else if (strstarts(buf, "fifo access"))
 		test = MUSB_TEST_FIFO_ACCESS;
 
-	if (strstarts(buf, "force full-speed"))
+	else if (strstarts(buf, "force full-speed"))
 		test = MUSB_TEST_FORCE_FS;
 
-	if (strstarts(buf, "force high-speed"))
+	else if (strstarts(buf, "force high-speed"))
 		test = MUSB_TEST_FORCE_HS;
 
-	if (strstarts(buf, "test packet")) {
+	else if (strstarts(buf, "test packet")) {
 		test = MUSB_TEST_PACKET;
 		musb_load_testpacket(musb);
 	}
 
-	if (strstarts(buf, "test K"))
+	else if (strstarts(buf, "test K"))
 		test = MUSB_TEST_K;
 
-	if (strstarts(buf, "test J"))
+	else if (strstarts(buf, "test J"))
 		test = MUSB_TEST_J;
 
-	if (strstarts(buf, "test SE0 NAK"))
+	else if (strstarts(buf, "test SE0 NAK"))
 		test = MUSB_TEST_SE0_NAK;
 

Quoted 4 lines

drivers/usb/musb/musb_debugfs.c +0 -0

 	musb_writeb(musb->mregs, MUSB_TESTMODE, test);

Signature · 1 line

1.7.9.5

Tony, what do you think about that patch?

But I am not sure how this will fix n900 host mode problem, since testmode is not used in normal operation.

Quoted 2 lines · On Thu 09 June 2016 15:58:56 Bin Liu wrote:

But I am not sure how this will fix n900 host mode problem, since testmode is not used in normal operation.

Please see http://talk.maemo.org/showthread.php?p=685367 and
http://maemo.org/packages/view/hostmode-gui/ which indeed is _no_ normal hostmode but an implementation of a workaround that exploits the force host test mode (among others)

Hi,

Quoted 4 lines · joerg Reisenweber

Quoted 2 lines · On Thu 09 June 2016 15:58:56 Bin Liu wrote:

But I am not sure how this will fix n900 host mode problem, since testmode is not used in normal operation.

Quoted 5 lines

Please see http://talk.maemo.org/showthread.php?p=685367 and
http://maemo.org/packages/view/hostmode-gui/ which indeed is _no_ normal hostmode but an implementation of a workaround that exploits the force host
test mode (among others)

What I meant was that it is okay for hobby, but you don't want to something that the IP vender does not support in real products.

Quoted 1 line

Quoted 1 line

But I am not sure how this will fix n900 host mode problem

Quoted 13 lines · On Fri 10 June 2016 10:08:08 Bin Liu wrote:

Hi,

Quoted 9 lines · joerg Reisenweber

Quoted 2 lines · On Thu 09 June 2016 15:58:56 Bin Liu wrote:

But I am not sure how this will fix n900 host mode problem, since testmode is not used in normal operation.

Please see http://talk.maemo.org/showthread.php?p=685367 and
http://maemo.org/packages/view/hostmode-gui/ which indeed is _no_ normal hostmode but an implementation of a workaround that exploits the force host
test mode (among others)

Quoted 2 lines

What I meant was that it is okay for hobby, but you don't want to something that the IP vender does not support in real products.

You lost me.

The musb ug says the testmde is not used in normal operation, so my opinion is force_host should not be used for hacking n900 host mode if this is for real product development or support.

Quoted 3 lines

The musb ug says the testmde is not used in normal operation, so my opinion is force_host should not be used for hacking n900 host mode if this is for real product development or support.

You're aware N900 OS aka maemo is a) FOSS, and b) EOL at least from Nokia's POV? So there's neither "product development" nor any _'official'_ support involved.
And c) we (community) already _did_ use it since it was the only chance to make hostmode sort of work for N900, it's not like we could redesign N900 hardware to support regular hostmode, we need to work with what RL gave us. It evades me why you discourage resp reject this established solution. Just Nokia not supporting hostmode evidently doesn't mean we can't get anything done, and I don't see why we should refrain from doing so.

I think there was some unfortunately choice of words used in the thread. It is TI intention to support community effort

software, unfortunately these modes do not tend to be well tested and the typical "official disclaimer" is "Not for 'production device usage' and 'user might be on his/her own' "

Quoted 3 lines · On Fri 10 June 2016 10:59:40 Bin Liu wrote:

The musb ug says the testmde is not used in normal operation, so my opinion is force_host should not be used for hacking n900 host mode if this is for real product development or support.

You're aware N900 OS aka maemo is a) FOSS, and b) EOL at least from Nokia's POV? So there's neither "product development" nor any _'official'_ support involved.
And c) we (community) already _did_ use it since it was the only chance to make hostmode sort of work for N900, it's not like we could redesign N900 hardware to support regular hostmode, we need to work with what RL gave us.

It evades me why you discourage resp reject this established solution.

Just Nokia not supporting hostmode evidently doesn't mean we can't get anything done, and I don't see why we should refrain from doing so.