RE: When USB PHY framework should be used?
> > > I think you should have a wrapper driver to EHCI/OHCI to handle this > reset. > > Thank you Kishon and Peter for the quick replies. Is there any good > example of such a wrapper driver in the kernel already? > chipidea, dwc3, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: When USB PHY framework should be used?
I think you should have a wrapper driver to EHCI/OHCI to handle this reset. Thank you Kishon and Peter for the quick replies. Is there any good example of such a wrapper driver in the kernel already? chipidea, dwc3, etc. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Build regressions/improvements in v3.11-rc3
My patches "usb: chipidea: fix the build error with randconfig" fixes chipidea
problem.
It has already at USB fixes for 3.11-rc4.
On Tue, 30 Jul 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.11-rc3 to v3.11-rc2[3], the summaries are:
> - build errors: +38/-14
+ arch/powerpc/kvm/book3s_emulate.c: error: 'bat' may be used uninitialized
in this function [-Werror=uninitialized]: => 349:2
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_ANDCOND' undeclared (first use
in this function): => 161:17, 86:16
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_AVPN' undeclared (first use in
this function): => 160:17, 85:16, 192:16
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_BULK_REMOVE' undeclared (first
use in this function): => 246:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_CEDE' undeclared (first use in
this function): => 250:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_CPPR' undeclared (first use in
this function): => 257:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_ENTER' undeclared (first use
in this function): => 240:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_EOI' undeclared (first use in
this function): => 258:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_EXACT' undeclared (first use
in this function): => 50:6
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_IPI' undeclared (first use in
this function): => 259:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_IPOLL' undeclared (first use
in this function): => 260:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_NOT_FOUND' undeclared (first
use in this function): => 193:27, 87:27
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PARAMETER' undeclared (first
use in this function): => 138:10
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PROTECT' undeclared (first use
in this function): => 244:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PTEG_FULL' undeclared (first
use in this function): => 54:12
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PUT_TCE' undeclared (first use
in this function): => 248:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_REMOVE' undeclared (first use
in this function): => 242:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_RTAS' undeclared (first use in
this function): => 265:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_SUCCESS' undeclared (first use
in this function): => 67:26, 96:26, 211:26, 125:12
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_TOO_HARD' undeclared (first
use in this function): => 224:12
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_XIRR' undeclared (first use in
this function): => 256:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_XIRR_X' undeclared (first use
in this function): => 261:7
+ arch/powerpc/platforms/pseries/hotplug-memory.c: error: 'SECTION_SIZE_BITS'
undeclared (first use in this function): => 24:31
+ mm/memory_hotplug.c: error: 'PAGES_PER_SECTION' undeclared (first use in
this function): => 1630:46
+ mm/memory_hotplug.c: error: implicit declaration of function
'__nr_to_section' [-Werror=implicit-function-declaration]: => 1635:3
+ mm/memory_hotplug.c: error: implicit declaration of function
'find_memory_block_hinted' [-Werror=implicit-function-declaration]: => 1642:3
+ mm/memory_hotplug.c: error: implicit declaration of function
'pfn_to_section_nr' [-Werror=implicit-function-declaration]: => 1631:3
+ mm/memory_hotplug.c: error: implicit declaration of function
'present_section_nr' [-Werror=implicit-function-declaration]: => 1632:3
powerpc-randconfig
+ drivers/md/dm-cache-policy-mq.c: error: conflicting types for
'remove_mapping': => 962:13
sparc-allmodconfig, not a regression (was hidden due to a sparc64/sparc32
mixup on kissb), patch submitted
+ error: "usb_add_gadget_udc" [drivers/usb/chipidea/ci_hdrc.ko] undefined!:
=> N/A
+ error: "usb_del_gadget_udc" [drivers/usb/chipidea/ci_hdrc.ko] undefined!:
=> N/A
+ error: "usb_gadget_map_request" [drivers/usb/chipidea/ci_hdrc.ko]
undefined!: => N/A
+ error: "usb_gadget_unmap_request" [drivers/usb/chipidea/ci_hdrc.ko]
undefined!: => N/A
x86_64-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/6490/ (all 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6461/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
RE: Build regressions/improvements in v3.11-rc3
My patches usb: chipidea: fix the build error with randconfig fixes chipidea
problem.
It has already at USB fixes for 3.11-rc4.
On Tue, 30 Jul 2013, Geert Uytterhoeven wrote:
JFYI, when comparing v3.11-rc3 to v3.11-rc2[3], the summaries are:
- build errors: +38/-14
+ arch/powerpc/kvm/book3s_emulate.c: error: 'bat' may be used uninitialized
in this function [-Werror=uninitialized]: = 349:2
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_ANDCOND' undeclared (first use
in this function): = 161:17, 86:16
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_AVPN' undeclared (first use in
this function): = 160:17, 85:16, 192:16
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_BULK_REMOVE' undeclared (first
use in this function): = 246:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_CEDE' undeclared (first use in
this function): = 250:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_CPPR' undeclared (first use in
this function): = 257:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_ENTER' undeclared (first use
in this function): = 240:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_EOI' undeclared (first use in
this function): = 258:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_EXACT' undeclared (first use
in this function): = 50:6
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_IPI' undeclared (first use in
this function): = 259:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_IPOLL' undeclared (first use
in this function): = 260:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_NOT_FOUND' undeclared (first
use in this function): = 193:27, 87:27
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PARAMETER' undeclared (first
use in this function): = 138:10
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PROTECT' undeclared (first use
in this function): = 244:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PTEG_FULL' undeclared (first
use in this function): = 54:12
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_PUT_TCE' undeclared (first use
in this function): = 248:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_REMOVE' undeclared (first use
in this function): = 242:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_RTAS' undeclared (first use in
this function): = 265:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_SUCCESS' undeclared (first use
in this function): = 67:26, 96:26, 211:26, 125:12
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_TOO_HARD' undeclared (first
use in this function): = 224:12
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_XIRR' undeclared (first use in
this function): = 256:7
+ arch/powerpc/kvm/book3s_pr_papr.c: error: 'H_XIRR_X' undeclared (first use
in this function): = 261:7
+ arch/powerpc/platforms/pseries/hotplug-memory.c: error: 'SECTION_SIZE_BITS'
undeclared (first use in this function): = 24:31
+ mm/memory_hotplug.c: error: 'PAGES_PER_SECTION' undeclared (first use in
this function): = 1630:46
+ mm/memory_hotplug.c: error: implicit declaration of function
'__nr_to_section' [-Werror=implicit-function-declaration]: = 1635:3
+ mm/memory_hotplug.c: error: implicit declaration of function
'find_memory_block_hinted' [-Werror=implicit-function-declaration]: = 1642:3
+ mm/memory_hotplug.c: error: implicit declaration of function
'pfn_to_section_nr' [-Werror=implicit-function-declaration]: = 1631:3
+ mm/memory_hotplug.c: error: implicit declaration of function
'present_section_nr' [-Werror=implicit-function-declaration]: = 1632:3
powerpc-randconfig
+ drivers/md/dm-cache-policy-mq.c: error: conflicting types for
'remove_mapping': = 962:13
sparc-allmodconfig, not a regression (was hidden due to a sparc64/sparc32
mixup on kissb), patch submitted
+ error: usb_add_gadget_udc [drivers/usb/chipidea/ci_hdrc.ko] undefined!:
= N/A
+ error: usb_del_gadget_udc [drivers/usb/chipidea/ci_hdrc.ko] undefined!:
= N/A
+ error: usb_gadget_map_request [drivers/usb/chipidea/ci_hdrc.ko]
undefined!: = N/A
+ error: usb_gadget_unmap_request [drivers/usb/chipidea/ci_hdrc.ko]
undefined!: = N/A
x86_64-randconfig
[1] http://kisskb.ellerman.id.au/kisskb/head/6490/ (all 120 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/6461/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RE: [PATCH] usb: udc: add gadget state kobject uevent
> > On Wed, Jul 17, 2013 at 10:36 AM, Peter Chen > wrote: > > On Mon, Jul 15, 2013 at 11:31:17PM -0700, Greg KH wrote: > >> On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote: > >> > Hi Greg, > >> > > >> > The USB on our platform can change roles between HOST and GADGET, > but > >> > it is not capable of OTG. > >> > >> That kind of sounds like the definition of OTG :) > >> > >> > When the USB changes between roles the udev will run some scripts > >> > automatically according to the udev rules. > >> > >> What exactly does udev/userspace see when the roles change? > >> > >> And what can trigger the change in roles? > >> > >> > The default role is GADGET, and we bind the g_mass_storage to the > USB > >> > GADGET role. > >> > > >> > We should secure the back end file storage between the device and > the > >> > host PC connecting to our device. > >> > We need to know when the GADGET is really connect to a host PC, then > >> > we can umount the file on the device > >> > and export it to the g_mass_storage. > >> > >> I thought you already get an event for this, otherwise no one would be > >> able to properly deal with this. > >> > >> > The question is since we default GADGET, so the g_mass_storage.ko is > >> > installed early but connecting to a host PC > >> > is randomly, But the udev has no idea when a host PC connects our > device. > >> > > >> > So we consider it's reasonable to let the udev know the GADGET > device state. > >> > Is there any alternative to our question? > >> > >> I thought we already export events for gadget device states, have you > >> looked for them? I can't dig through the code at the moment, but this > >> seems like a pretty common issue... > >> > > > > If I understand correctly, what Rong wants is udev can be notified the > > udc state changes, like connect/disconnect event. Currently, we only > > export it to /sys. > > OK. Thanks for your share. > > And you develop a new utility rather than udev to monitor that file? > And you probably create a work queue in your udc driver to do this work? > Not yet, no one complains it, so I haven't added it. But, it is a useful user interface, Android has implemented similar functions at its gadget driver. Best regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb: udc: add gadget state kobject uevent
On Wed, Jul 17, 2013 at 10:36 AM, Peter Chen peter.c...@freescale.com wrote: On Mon, Jul 15, 2013 at 11:31:17PM -0700, Greg KH wrote: On Tue, Jul 16, 2013 at 11:49:07AM +0800, Rong Wang wrote: Hi Greg, The USB on our platform can change roles between HOST and GADGET, but it is not capable of OTG. That kind of sounds like the definition of OTG :) When the USB changes between roles the udev will run some scripts automatically according to the udev rules. What exactly does udev/userspace see when the roles change? And what can trigger the change in roles? The default role is GADGET, and we bind the g_mass_storage to the USB GADGET role. We should secure the back end file storage between the device and the host PC connecting to our device. We need to know when the GADGET is really connect to a host PC, then we can umount the file on the device and export it to the g_mass_storage. I thought you already get an event for this, otherwise no one would be able to properly deal with this. The question is since we default GADGET, so the g_mass_storage.ko is installed early but connecting to a host PC is randomly, But the udev has no idea when a host PC connects our device. So we consider it's reasonable to let the udev know the GADGET device state. Is there any alternative to our question? I thought we already export events for gadget device states, have you looked for them? I can't dig through the code at the moment, but this seems like a pretty common issue... If I understand correctly, what Rong wants is udev can be notified the udc state changes, like connect/disconnect event. Currently, we only export it to /sys. OK. Thanks for your share. And you develop a new utility rather than udev to monitor that file? And you probably create a work queue in your udc driver to do this work? Not yet, no one complains it, so I haven't added it. But, it is a useful user interface, Android has implemented similar functions at its gadget driver. Best regards, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH] drivers: phy: add generic PHY framework
> > The PHY framework provides a set of API's for the PHY drivers to > create/remove a PHY and the PHY users to obtain a reference to the PHY > using or without using phandle. If the PHY users has to obtain a > reference to > the PHY without using phandle, the platform specfic intialization code > (say > from board file) should have already called phy_bind with the binding > information. The binding information consists of phy's device name, phy > user device name and an index. The index is used when the same phy user > binds to mulitple phys. > What's an example of "the same phy user binds to multiple phys"? I only remembered that Felipe said there are two phy users for one single phy at omap5 that is both usb3 and sata uses the same phy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH] drivers: phy: add generic PHY framework
The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. What's an example of the same phy user binds to multiple phys? I only remembered that Felipe said there are two phy users for one single phy at omap5 that is both usb3 and sata uses the same phy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
