usb: chipidea: Add support for NPCM

Add Nuvoton NPCM BMC SoCs support to USB ChipIdea driver.
NPCM SoC includes ChipIdea IP block that is used for USB device controller
mode.

Signed-off-by: Tomer M

usb: chipidea: Add support for NPCM

Add Nuvoton NPCM BMC SoCs support to USB ChipIdea driver.
NPCM SoC includes ChipIdea IP block that is used for USB device controller
mode.

Signed-off-by: Tomer Maimon <[email protected]>
Acked-by: Peter Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: make configs for glue drivers visible with EXPERT

Commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT")
introduces CONFIG_EXPERT to carry the previous intent of CON

usb: chipidea: make configs for glue drivers visible with EXPERT

Commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT")
introduces CONFIG_EXPERT to carry the previous intent of CONFIG_EMBEDDED
and just gives that intent a much better name. That has been clearly a good
and long overdue renaming, and it is clearly an improvement to the kernel
build configuration that has shown to help managing the kernel build
configuration in the last decade.

However, rather than bravely and radically just deleting CONFIG_EMBEDDED,
this commit gives CONFIG_EMBEDDED a new intended semantics, but keeps it
open for future contributors to implement that intended semantics:

A new CONFIG_EMBEDDED option is added that automatically selects
CONFIG_EXPERT when enabled and can be used in the future to isolate
options that should only be considered for embedded systems (RISC
architectures, SLOB, etc).

Since then, this CONFIG_EMBEDDED implicitly had two purposes:

- It can make even more options visible beyond what CONFIG_EXPERT makes
visible. In other words, it may introduce another level of enabling the
visibility of configuration options: always visible, visible with
CONFIG_EXPERT and visible with CONFIG_EMBEDDED.

- Set certain default values of some configurations differently,
following the assumption that configuring a kernel build for an
embedded system generally starts with a different set of default values
compared to kernel builds for all other kind of systems.

Considering the first purpose, at the point in time where CONFIG_EMBEDDED
was renamed to CONFIG_EXPERT, CONFIG_EXPERT already made 130 more options
become visible throughout all different menus for the kernel configuration.
Over the last decade, this has gradually increased, so that currently, with
CONFIG_EXPERT, roughly 170 more options become visible throughout all
different menus for the kernel configuration. In comparison, currently with
CONFIG_EMBEDDED enabled, just seven more options are visible, one in x86,
one in arm, and five for the ChipIdea Highspeed Dual Role Controller.

As the numbers suggest, these two levels of enabling the visibility of even
more configuration options---beyond what CONFIG_EXPERT enables---never
evolved to a good solution in the last decade. In other words, this
additional level of visibility of configuration option with CONFIG_EMBEDDED
compared to CONFIG_EXPERT has since its introduction never become really
valuable. It requires quite some investigation to actually understand what
is additionally visible and it does not differ significantly in complexity
compared to just enabling CONFIG_EXPERT. This CONFIG_EMBEDDED---or any
other config to show more detailed options beyond CONFIG_EXPERT---is
unlikely to be valuable unless somebody puts significant effort in
identifying how such visibility options can be properly split and creating
clear criteria, when some config option is visible with CONFIG_EXPERT and
when some config option is visible only with some further option enabled
beyond CONFIG_EXPERT, such as CONFIG_EMBEDDED attempted to do. For now, it
is much more reasonable to simply make those additional seven options that
visible with CONFIG_EMBEDDED, visible with CONFIG_EXPERT, and then remove
CONFIG_EMBEDDED. If anyone spends significant effort in structuring the
visibility of config options, they may re-introduce suitable new config
options simply as they see fit.

Make the configs for usb chipidea glue drivers visible when CONFIG_EXPERT
is enabled.

Signed-off-by: Lukas Bulwahn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: tegra: Support host mode

Add USB host mode to the Tegra HDRC driver. This allows us to benefit from
support provided by the generic ChipIdea driver instead of duplicating the
effort i

usb: chipidea: tegra: Support host mode

Add USB host mode to the Tegra HDRC driver. This allows us to benefit from
support provided by the generic ChipIdea driver instead of duplicating the
effort in a separate ehci-tegra driver.

Tested-by: Matt Merhar <[email protected]>
Tested-by: Nicolas Chauvet <[email protected]>
Tested-by: Ion Agorria <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Peter Chen <[email protected]>
Signed-off-by: Peter Geis <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: tegra: Rename UDC to USB

Rename all occurrences in the code from "udc" to "usb" and change the
Kconfig entry in order to show that this driver supports USB modes other
than device-onl

usb: chipidea: tegra: Rename UDC to USB

Rename all occurrences in the code from "udc" to "usb" and change the
Kconfig entry in order to show that this driver supports USB modes other
than device-only mode. The follow up patch will add host-mode support and
it will be cleaner to perform the renaming separately, i.e. in this patch.

Tested-by: Matt Merhar <[email protected]>
Tested-by: Nicolas Chauvet <[email protected]>
Tested-by: Peter Geis <[email protected]>
Tested-by: Ion Agorria <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Peter Chen <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: allow disabling glue drivers if EMBEDDED

Allow to cut down on driver size for embedded config.

Signed-off-by: Michał Mirosław <[email protected]>
Signed-off-by: Peter Chen <pet

usb: chipidea: allow disabling glue drivers if EMBEDDED

Allow to cut down on driver size for embedded config.

Signed-off-by: Michał Mirosław <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

usb: chipidea: tegra: Add USB_TEGRA_PHY to driver's dependencies

Add build dependency on USB_TEGRA_PHY since UDC driver isn't usable
without the PHY.

Signed-off-by: Dmitry Osipenko <[email protected]

usb: chipidea: tegra: Add USB_TEGRA_PHY to driver's dependencies

Add build dependency on USB_TEGRA_PHY since UDC driver isn't usable
without the PHY.

Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: add role switch class support

USB role is fully controlled by usb role switch consumer(e.g. typec),
usb port can be at host mode(USB_ROLE_HOST), device mode connected to
host(USB_ROLE

usb: chipidea: add role switch class support

USB role is fully controlled by usb role switch consumer(e.g. typec),
usb port can be at host mode(USB_ROLE_HOST), device mode connected to
host(USB_ROLE_DEVICE), or not connecting any partner(USB_ROLE_NONE).

Signed-off-by: Li Jun <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

USB: add missing SPDX lines to Kconfig and Makefiles

There are a few remaining drivers/usb/ files that do not have SPDX
identifiers in them, all of these are either Kconfig or Makefiles. Add
the co

USB: add missing SPDX lines to Kconfig and Makefiles

There are a few remaining drivers/usb/ files that do not have SPDX
identifiers in them, all of these are either Kconfig or Makefiles. Add
the correct GPL-2.0 identifier to them to make scanning tools happy.

Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: Always build ULPI code

Commit 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51") causes a kernel
hang on imx51 systems that use the ULPI interface and do not select the
CONFIG_USB_CHIP

usb: chipidea: Always build ULPI code

Commit 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51") causes a kernel
hang on imx51 systems that use the ULPI interface and do not select the
CONFIG_USB_CHIPIDEA_ULPI option.

In order to avoid such potential misuse, let's always build the
chipidea ULPI code into the final ci_hdrc object.

Tested on a imx51-babbage board.

Fixes: 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51")
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

usb: chipidea: fix trivial typo in Kconfig

This patch fixes a trivial typo to get the module name ci_hdrc.ko correct.

Signed-off-by: Christoph Fritz <[email protected]>
Signed-off-by: Peter

usb: chipidea: fix trivial typo in Kconfig

This patch fixes a trivial typo to get the module name ci_hdrc.ko correct.

Signed-off-by: Christoph Fritz <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

usb: add CONFIG_USB_PCI for system have both PCI HW and non-PCI based USB HW

a lot of embeded system SOC (e.g. freescale T2080) have both
PCI and USB modules. But USB module is controlled by registe

usb: add CONFIG_USB_PCI for system have both PCI HW and non-PCI based USB HW

a lot of embeded system SOC (e.g. freescale T2080) have both
PCI and USB modules. But USB module is controlled by registers directly,
it have no relationship with PCI module.

when say N here it will not build PCI related code in USB driver.

Signed-off-by: yuan linyu <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: msm: Add reset controller for PHY POR bit

The MSM chipidea wrapper has two bits that are used to reset the
first or second phy. Add support for these bits via the reset
controller fra

usb: chipidea: msm: Add reset controller for PHY POR bit

The MSM chipidea wrapper has two bits that are used to reset the
first or second phy. Add support for these bits via the reset
controller framework, so that phy drivers can reset their
hardware at the right time during initialization.

Acked-by: Peter Chen <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

usb: chipidea: Add support for ULPI PHY bus

Some phys for the chipidea controller are controlled via the ULPI
viewport. Add support for the ULPI bus so that these sorts of
phys can be probed and rea

usb: chipidea: Add support for ULPI PHY bus

Some phys for the chipidea controller are controlled via the ULPI
viewport. Add support for the ULPI bus so that these sorts of
phys can be probed and read/written automatically without having
to duplicate the viewport logic in each phy driver.

Acked-by: Peter Chen <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Heikki Krogerus <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

usb: chipidea: Kconfig: improve Kconfig help text

Chipidea driver has been updated a lot, and more functions are supported,
update Kconfig help text accordingly.

Signed-off-by: Peter Chen <peter.ch

usb: chipidea: Kconfig: improve Kconfig help text

Chipidea driver has been updated a lot, and more functions are supported,
update Kconfig help text accordingly.

Signed-off-by: Peter Chen <[email protected]>

show more ...

usb: chipidea: delete static debug support

Since we have dynamic debug support, delete static debug for chipidea

Signed-off-by: Peter Chen <[email protected]>

usb: chipidea: Use extcon framework for VBUS and ID detect

On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disco

usb: chipidea: Use extcon framework for VBUS and ID detect

On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disconnect ID and VBUS notification.

Signed-off-by: Ivan T. Ivanov <[email protected]>
Signed-off-by: Peter Chen <[email protected]>

show more ...

chipidea: pci: make it depends on NOP_USB_XCEIV

After commit ba1aff67f99a (chipidea: pci: register nop PHY) the PCI glue driver
requires nop-PHY to be selected. Thus, make it an explicit dependency.

chipidea: pci: make it depends on NOP_USB_XCEIV

After commit ba1aff67f99a (chipidea: pci: register nop PHY) the PCI glue driver
requires nop-PHY to be selected. Thus, make it an explicit dependency.

Reported-by: kbuild test robot <[email protected]>
Fixes: ba1aff67f99a (chipidea: pci: register nop PHY)
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

chipidea: introduce specific Kconfig options for glue drivers

This patch introduces USB_CHIPIDEA_PCI and USB_CHIPIDEA_OF Kconfig options, one
per each specific glue driver. This is needed to provide

chipidea: introduce specific Kconfig options for glue drivers

This patch introduces USB_CHIPIDEA_PCI and USB_CHIPIDEA_OF Kconfig options, one
per each specific glue driver. This is needed to provide different dependencies
they have.

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'

Re

usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA

If NO_DMA=y:

drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'

Reviewed-and-tested-by: Peter Chen <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: improve kconfig 2.0

This patch provides a cleaner solution to the problem described in
commit 20a677fd ("usb: chipidea: improve kconfig").

The goal to be achieved is to force USB_CHI

usb: chipidea: improve kconfig 2.0

This patch provides a cleaner solution to the problem described in
commit 20a677fd ("usb: chipidea: improve kconfig").

The goal to be achieved is to force USB_CHIPIDEA=m if either
USB_EHCI_HCD=m or USB_GADGET=m.
If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'.

The old patch had the drawback, that USB_CHIPIDEA could be chosen as
'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a
situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from
the config options producing a compilable but dysfunctional driver.

Signed-off-by: Lothar Waßmann <[email protected]>
Reviewed-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: fix the build error with randconfig

Using below configs, the compile will have error:
ERROR: "ehci_init_driver" undefined!

.config:
CONFIG_USB_CHIPIDEA=m
CONFIG_USB_CHIPIDEA_HOST=y

usb: chipidea: fix the build error with randconfig

Using below configs, the compile will have error:
ERROR: "ehci_init_driver" undefined!

.config:
CONFIG_USB_CHIPIDEA=m
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_USB_CHIPIDEA_DEBUG=y

The reason is chipidea host uses symbol from ehci, but ehci
is not compiled. Let the chipidea host depend on
ehci even it is built as module.

Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: chipidea: improve kconfig

Randy Dunlap <[email protected]> reported this problem
on i386:

> drivers/built-in.o: In function `ci_hdrc_host_init':
> (.text+0x2ce75c): undefined reference to

usb: chipidea: improve kconfig

Randy Dunlap <[email protected]> reported this problem
on i386:

> drivers/built-in.o: In function `ci_hdrc_host_init':
> (.text+0x2ce75c): undefined reference to `ehci_init_driver'
>
> When USB_EHCI_HCD=m and USB_CHIPIDEA=y.

In fact, this problem is existed on all platforms which are using
chipidea driver. The root cause of this problem is the chipidea host
uses symbol exported from ehci-hcd, but chipidea core
does not depends on USB_EHCI_HCD. So, chipidea driver
will not be compiled as module if USB_EHCI_HCD=m.

It is very hard to give a perfect solution since chipidea core
depends on USB || USB_GADGET, and chipdiea host depends on
both USB_EHCI_HCD and USB_CHIPIDEA, the same problem exists for
gadget.

To fix this problem, we had to have below assumptions:

- If USB_EHCI_HCD=y && USB_GADGET=y, USB_CHIPIDEA can be 'y'.

- If USB_EHCI_HCD=m && USB_GADGET=y, USB_CHIPIDEA=m
or USB_CHIPIDEA_HOST can't be seen if USB_CHIPIDEA=y.
It will cause compile error due to no glue layer for ehci:

> error: #error "missing bus glue for ehci-hcd"

So, we had to compile USB_CHIPIDEA=m if USB_EHCI_HCD=m,
current ehci hcd core guarantee it.

- If USB_EHCI_HCD=y && USB_GADGET=m, USB_CHIPIDEA=m
or USB_CHIPIDEA_UDC can't be seen if USB_CHIPIDEA=y.
Of cos, the gadget will out of working at this situation,
so the user had to compile USB_CHIPIDEA=m.

- USB_EHCI_HCD=m && USB_GADGET=m, we can't see
USB_CHIPIDEA_HOST and USB_CHIPIDEA_UDC unless
USB_CHIPIDEA=m.

The reason why it has above assumptions:
- If both ehci core and gadget core build as module,
the chipidea has to build as module.
- If one of ehci core or gadget core is built in, another
is built as module, we can only enable the function which
is built in, or enable both roles as modules (USB_CHIPIDEA=m),
since chipidea core driver takes care of both host and device roles.

Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb, chipidea: fix link error when USB_EHCI_HCD is a module

Fixes link error when USB_EHCI_HCD=m and USB_CHIPIDEA_HOST=y:

drivers/built-in.o: In function `ci_hdrc_host_init':
drivers/usb/chipidea

usb, chipidea: fix link error when USB_EHCI_HCD is a module

Fixes link error when USB_EHCI_HCD=m and USB_CHIPIDEA_HOST=y:

drivers/built-in.o: In function `ci_hdrc_host_init':
drivers/usb/chipidea/host.c:104: undefined reference to `ehci_init_driver'

as a result of commit 09f6ffde2ece ("USB: EHCI: fix build error by making
ChipIdea host a normal EHCI driver").

Cc: [email protected] [v3.7+]
Signed-off-by: David Rientjes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: EHCI: fix build error by making ChipIdea host a normal EHCI driver

This patch (as1627) splits the ehci-hcd core code, which has become a
separate library module, out from the ChipIdea host driv

USB: EHCI: fix build error by making ChipIdea host a normal EHCI driver

This patch (as1627) splits the ehci-hcd core code, which has become a
separate library module, out from the ChipIdea host driver. Instead
of #include-ing ehci-hcd.c directly, the ChipIdea module will now use
the ehci-hcd library in a normal fashion.

This fixes a build error caused by commit
3e0232039967d7a1a06c013d097458b4d5892af1 (USB: EHCI: prepare to make
ehci-hcd a library module); I had forgotten about the unorthodox way
the ChipIdea driver uses the ehci-hcd code.

Signed-off-by: Alan Stern <[email protected]>
Acked-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: gadget: get rid of USB_GADGET_{DUAL,SUPER}SPEED

This commit removes USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
Kconfig options. Since now kernel allows many UDC drivers to be
compiled, tho

usb: gadget: get rid of USB_GADGET_{DUAL,SUPER}SPEED

This commit removes USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
Kconfig options. Since now kernel allows many UDC drivers to be
compiled, those options may turn to no longer be valid. For
instance, if someone decides to build UDC that supports super
speed and UDC that supports high speed only, the latter will be
"assumed" to support super speed since USB_GADGET_SUPERSPEED will
be selected by the former.

The test of whether CONFIG_USB_GADGET_*SPEED was defined was just
an optimisation which removed otherwise dead code (ie. if UDC is
not dual speed, there is no need to handle cases that can happen
if speed is high). This commit removes those checks.

Signed-off-by: Michal Nazarewicz <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>

show more ...