Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1312489 > unrolled thread

Re: Nokia N900: musb is in wrong state after boot

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Nokia N900: musb is in wrong state after boot Tony Lindgren <tony@atomide.com> - 2016-01-19 21:40 +0100
    Re: Nokia N900: musb is in wrong state after boot Pali Rohár <pali.rohar@gmail.com> - 2016-01-21 09:50 +0100
      Re: Nokia N900: musb is in wrong state after boot Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> - 2016-01-21 11:00 +0100
        Re: Nokia N900: musb is in wrong state after boot Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> - 2016-01-21 11:30 +0100
        Re: Nokia N900: musb is in wrong state after boot Pali Rohár <pali.rohar@gmail.com> - 2016-01-21 11:30 +0100
      Re: Nokia N900: musb is in wrong state after boot joerg Reisenweber <joerg@openmoko.org> - 2016-01-21 12:00 +0100
        Re: Nokia N900: musb is in wrong state after boot Tony Lindgren <tony@atomide.com> - 2016-01-21 18:50 +0100
          Re: Nokia N900: musb is in wrong state after boot joerg Reisenweber <joerg@openmoko.org> - 2016-01-21 19:50 +0100
            Re: Nokia N900: musb is in wrong state after boot Tony Lindgren <tony@atomide.com> - 2016-01-21 20:30 +0100
              Re: Nokia N900: musb is in wrong state after boot joerg Reisenweber <joerg@openmoko.org> - 2016-01-21 20:40 +0100
                Re: Nokia N900: musb is in wrong state after boot Tony Lindgren <tony@atomide.com> - 2016-01-21 21:40 +0100
                  Re: Nokia N900: musb is in wrong state after boot Pali Rohár <pali.rohar@gmail.com> - 2016-01-26 15:40 +0100
                    Re: Nokia N900: musb is in wrong state after boot Tony Lindgren <tony@atomide.com> - 2016-01-26 18:30 +0100
              Re: Nokia N900: musb is in wrong state after boot Pali Rohár <pali.rohar@gmail.com> - 2016-01-23 14:00 +0100

#1312489 — Re: Nokia N900: musb is in wrong state after boot

Hi,

* Pali Rohár <pali.rohar@gmail.com> [160109 07:16]:
> 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.

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

[toc] | [next] | [standalone]

#1314005

On Tuesday 19 January 2016 12:33:15 Tony Lindgren wrote:
> Hi,
> 
> * Pali Rohár <pali.rohar@gmail.com> [160109 07:16]:
> > 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.
> 
> 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?

> 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 :-(

> 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

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1314054

On 21.01.2016 10:40, Pali Rohár wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#1314076

On 21.01.2016 12:23, Pali Rohár wrote:
>
> 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.
>

Oh, sorry, I misunderstood what you wrote - I was under the impression 
that you can't find the schematics itself :)

Ivo

[toc] | [prev] | [next] | [standalone]

#1314081

On Thursday 21 January 2016 11:57:48 Ivaylo Dimitrov wrote:
> 
> 
> On 21.01.2016 10:40, Pali Rohár wrote:
> >
> >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.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1314095

[Multipart message — attachments visible in raw view] — view raw

On Thu 21 January 2016 09:40:07 Pali Rohár wrote:
> On Tuesday 19 January 2016 12:33:15 Tony Lindgren wrote:
> > Hi,
> > 
> > * Pali Rohár <pali.rohar@gmail.com> [160109 07:16]:
> > > 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.
> > 
> > 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.

> 
> I do not know now. I tried to find it in N900 schemantics, but do not
> see it.
> 
> CCing Joerg, do you know?
> 
> > 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 :-(
> 
> > 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


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)

cheers
jOERG
-- 
()  ascii ribbon campaign
/\  
against html e-mail - against proprietary attachments
http://www.georgedillon.com/web/html_email_is_evil.shtml          
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml    
http://www.gerstbach.at/2004/ascii/ (German)

[toc] | [prev] | [next] | [standalone]

#1314380

* joerg Reisenweber <joerg@openmoko.org> [160121 02:30]:
> On Thu 21 January 2016 09:40:07 Pali Rohár wrote:
> > On Tuesday 19 January 2016 12:33:15 Tony Lindgren wrote:
> > > Hi,
> > > 
> > > * Pali Rohár <pali.rohar@gmail.com> [160109 07:16]:
> > > > 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.
> > > 
> > > 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.

Right, I'm confusing things a bit here. If the VBUS detection is done in
twl4030, then it should notify the USB subsystem. But on n900 the USB
phy is not ti,twl4030-usb, it's the 1707 instead.

So my guess is that in drivers/phy/phy-twl4030-usb.c the interrupt never
gets enabled as the PHY driver never gets probed?

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.

> 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.

Yes so it seems.

> 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)

I also think there's also some related twl4030 errata where it's
recommended the USB PHY is in suspend mode instead of disabled.

Regards,

Tony

[toc] | [prev] | [next] | [standalone]

#1314415

[Multipart message — attachments visible in raw view] — view raw

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.

/jOERG
-- 
()  ascii ribbon campaign
/\  
against html e-mail - against proprietary attachments
http://www.georgedillon.com/web/html_email_is_evil.shtml          
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml    
http://www.gerstbach.at/2004/ascii/ (German)

[toc] | [prev] | [next] | [standalone]

#1314444

* joerg Reisenweber <joerg@openmoko.org> [160121 10:45]:
> 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.

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?

> 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.

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

Regards,

Tony

[toc] | [prev] | [next] | [standalone]

#1314464

[Multipart message — attachments visible in raw view] — view raw

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

/j

-- 
()  ascii ribbon campaign
/\  
against html e-mail - against proprietary attachments
http://www.georgedillon.com/web/html_email_is_evil.shtml          
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml    
http://www.gerstbach.at/2004/ascii/ (German)

[toc] | [prev] | [next] | [standalone]

#1314511

* joerg Reisenweber <joerg@openmoko.org> [160121 11:35]:
> 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.

Regards,

Tony

[toc] | [prev] | [next] | [standalone]

#1317978

On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:
> * joerg Reisenweber <joerg@openmoko.org> [160121 11:35]:
> > 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.

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.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1318192

* Pali Rohár <pali.rohar@gmail.com> [160126 06:35]:
> On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote:
> > * joerg Reisenweber <joerg@openmoko.org> [160121 11:35]:
> > > 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.
> 
> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#1315588

[Multipart message — attachments visible in raw view] — view raw

On Thursday 21 January 2016 20:21:13 Tony Lindgren wrote:
> * joerg Reisenweber <joerg@openmoko.org> [160121 10:45]:
> > 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.
> 
> 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?
> 
> > 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.
> 
> 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.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web