summaryrefslogtreecommitdiff
path: root/drivers/usb/chipidea/Kconfig
blob: 5e5b9eb7ebf6daa2f8a1764c60fe3dced6bee13f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
config USB_CHIPIDEA
	tristate "ChipIdea Highspeed Dual Role Controller"
	depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
	select EXTCON
	help
	  Say Y here if your system has a dual role high speed USB
	  controller based on ChipIdea silicon IP. It supports:
	  Dual-role switch (ID, OTG FSM, sysfs), Host-only, and
	  Peripheral-only.

	  When compiled dynamically, the module will be called ci-hdrc.ko.

if USB_CHIPIDEA

config USB_CHIPIDEA_OF
	tristate
	depends on OF
	default USB_CHIPIDEA

config USB_CHIPIDEA_PCI
	tristate
	depends on PCI
	depends on NOP_USB_XCEIV
	default USB_CHIPIDEA

config USB_CHIPIDEA_UDC
	bool "ChipIdea device controller"
	depends on USB_GADGET
	help
	  Say Y here to enable device controller functionality of the
	  ChipIdea driver.

config USB_CHIPIDEA_HOST
	bool "ChipIdea host controller"
	depends on USB_EHCI_HCD
	select USB_EHCI_ROOT_HUB_TT
	help
	  Say Y here to enable host controller functionality of the
	  ChipIdea driver.

endif
colspan='2' class='oid'>047487241ff59374fded8c477f21453681f5995c (diff)
Merge branch 'sparc64-non-resumable-user-error-recovery'
Liam R. Howlett says: ==================== sparc64: Recover from userspace non-resumable PIO & MEM errors A non-resumable error from userspace is able to cause a kernel panic or trap loop due to the setup and handling of the queued traps once in the kernel. This patch series addresses both of these issues. The queues are fixed by simply zeroing the memory before use. PIO errors from userspace will result in a SIGBUS being sent to the user process. The MEM errors form userspace will result in a SIGKILL and also cause the offending pages to be claimed so they are no longer used in future tasks. SIGKILL is used to ensure that the process does not try to coredump and result in an attempt to read the memory again from within kernel space. Although there is a HV call to scrub the memory (mem_scrub), there is no easy way to guarantee that the real memory address(es) are not used by other tasks. Clearing the error with mem_scrub would zero the memory and cause the other processes to proceed with bad data. The handling of other non-resumable errors remain unchanged and will cause a panic. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'sound/soc/mediatek/mt8173')