<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb/misc/Kconfig, branch v6.6.132</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-10-15T09:57:55+00:00</updated>
<entry>
<title>usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls</title>
<updated>2025-10-15T09:57:55+00:00</updated>
<author>
<name>Komal Bajaj</name>
<email>komal.bajaj@oss.qualcomm.com</email>
</author>
<published>2025-07-31T09:01:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac4d189aaa93205b99f8a88d4ef22ec88da59bd8'/>
<id>urn:sha1:ac4d189aaa93205b99f8a88d4ef22ec88da59bd8</id>
<content type='text'>
[ Upstream commit c0485e864a2eaa1d5a84c71e573dd236d0e885ae ]

EUD_MODE_MANAGER2 register is mapped to a memory region that is marked
as read-only for operating system running at EL1, enforcing access
restrictions that prohibit direct memory-mapped writes via writel().

Attempts to write to this region from HLOS can result in silent failures
or memory access violations, particularly when toggling EUD (Embedded
USB Debugger) state. To ensure secure register access, modify the driver
to use qcom_scm_io_writel(), which routes the write operation to Qualcomm
Secure Channel Monitor (SCM). SCM has the necessary permissions to access
protected memory regions, enabling reliable control over EUD state.

SC7280, the only user of EUD is also affected, indicating that this could
never have worked on a properly fused device.

Fixes: 9a1bf58ccd44 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)")
Signed-off-by: Melody Olvera &lt;quic_molvera@quicinc.com&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Reviewed-by: Souradeep Chowdhury &lt;quic_schowdhu@quicinc.com&gt;
Signed-off-by: Komal Bajaj &lt;komal.bajaj@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: move config USB_USS720 to usb's misc Kconfig</title>
<updated>2023-03-29T08:34:08+00:00</updated>
<author>
<name>Lukas Bulwahn</name>
<email>lukas.bulwahn@gmail.com</email>
</author>
<published>2023-03-29T07:51:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d629c0e221cd99198b843d8351a0a9bfec6c0423'/>
<id>urn:sha1:d629c0e221cd99198b843d8351a0a9bfec6c0423</id>
<content type='text'>
The USS720 parport driver source code is in drivers/usb/misc/, the
corresponding config is defined in drivers/usb/Kconfig. Some digging in the
kernel's history revealed no good reason why it needs to be defined in
USB's top-level Kconfig file, and why the config for the USS720 parport
driver should be the first in the list of USB port drivers, while all other
configs for drivers in drivers/usb/misc are in the USB Miscellaneous driver
configuration file.

Most probably, it was simply considered a bit more special when the USB
Miscellaneous driver configuration file (drivers/usb/misc/Config.in back
then) was initially created, and this config simply survived to remain at
the top-level USB Kconfig file with all further code/Kconfig
transformations and additions later on. Users rarely notice this config
being at this position, as CONFIG_PARPORT (Parallel port support) needs to
be enabled and only few users enable that. Nowadays, this USB_USS720 driver
is probably not that special that it needs to be listed as first item of
the USB port drivers.

Move the configuration of the USS720 parport driver to the top of the USB
Miscellaneous drivers section, as the configurations does not have a lot of
specific ordering USB Miscellaneous drivers. This way, the USS720 parport
driver is moved to the comment "USB Miscellaneous drivers", fitting to the
driver's source code location, but still is at the top of the list for
those few acquainted users of Kconfig UIs that might be looking for the
config that was once at the top of the list of the USB port drivers.

Put this config definition to a more local place. No semantic change.

Signed-off-by: Lukas Bulwahn &lt;lukas.bulwahn@gmail.com&gt;
Link: https://lore.kernel.org/r/20230329075125.32352-1-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: ftdi-elan: Delete driver</title>
<updated>2023-03-21T15:31:59+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2023-03-21T15:09:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8be174835f07b2c106b9961c0775486d06112a3c'/>
<id>urn:sha1:8be174835f07b2c106b9961c0775486d06112a3c</id>
<content type='text'>
This driver didn't see real maintainance since several years. It has
several trivial issues (check $(scripts/checkpatch.pl -f
drivers/usb/misc/ftdi-elan.c)) and some harder ones (difficult locking,
explict kref handling, ...). Also today it's hard to find hardware to
make actually use of such a card and I suspect the driver is completely
unused.

So remove it.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20230321150919.351947-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: host: u132-hcd: Delete driver</title>
<updated>2023-03-21T13:06:11+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2023-03-21T10:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=213acadd21a080fc8cda8eebe6d14cc2d4ad1332'/>
<id>urn:sha1:213acadd21a080fc8cda8eebe6d14cc2d4ad1332</id>
<content type='text'>
This driver got its last actual change in 2006 and is probably unused as
nowbody should use a cardbus to USB adapter any more.

If it were still used, the driver was in urgent need for maintainer
love. (Explicit kref handling, underdocumented locking, .remove() can
return errors ...)

Also the link in the (now removed) help text doesn't look actively
maintained. According to archive.org it forwarded to
http://www.copenhagen-hotel.net/ already back in 2018.

So don't waste more time on this driver and just delete it.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20230321103638.343886-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: misc: onboard_usb_hub: Drop obsolete dependency on COMPILE_TEST</title>
<updated>2022-11-29T07:56:09+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2022-11-27T14:52:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22683e480b370ad1b3a34cfa461028d1f51da12d'/>
<id>urn:sha1:22683e480b370ad1b3a34cfa461028d1f51da12d</id>
<content type='text'>
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.

It is actually better to always build such drivers with OF enabled,
so that the test builds are closer to how each driver will actually be
built on its intended target. Building them without OF may not test
much as the compiler will optimize out potentially large parts of the
code. In the worst case, this could even pop false positive warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.

Cc: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Link: https://lore.kernel.org/r/20221127155230.144886b7@endymion.delvare
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: misc: Add onboard_usb_hub driver</title>
<updated>2022-07-08T12:53:50+00:00</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2022-06-30T19:35:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8bc063641cebf9d555e41d135db2b5035b521768'/>
<id>urn:sha1:8bc063641cebf9d555e41d135db2b5035b521768</id>
<content type='text'>
The main issue this driver addresses is that a USB hub needs to be
powered before it can be discovered. For discrete onboard hubs (an
example for such a hub is the Realtek RTS5411) this is often solved
by supplying the hub with an 'always-on' regulator, which is kind
of a hack. Some onboard hubs may require further initialization
steps, like changing the state of a GPIO or enabling a clock, which
requires even more hacks. This driver creates a platform device
representing the hub which performs the necessary initialization.
Currently it only supports switching on a single regulator, support
for multiple regulators or other actions can be added as needed.
Different initialization sequences can be supported based on the
compatible string.

Besides performing the initialization the driver can be configured
to power the hub off during system suspend. This can help to extend
battery life on battery powered devices which have no requirements
to keep the hub powered during suspend. The driver can also be
configured to leave the hub powered when a wakeup capable USB device
is connected when suspending, and power it off otherwise.

Technically the driver consists of two drivers, the platform driver
described above and a very thin USB driver that subclasses the
generic driver. The purpose of this driver is to provide the platform
driver with the USB devices corresponding to the hub(s) (a hub
controller may provide multiple 'logical' hubs, e.g. one to support
USB 2.0 and another for USB 3.x).

Co-developed-by: Ravi Chandra Sadineni &lt;ravisadineni@chromium.org&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Ravi Chandra Sadineni &lt;ravisadineni@chromium.org&gt;
Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Link: https://lore.kernel.org/r/20220630123445.v24.3.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: misc: USB_QCOM_EUD should depend on ARCH_QCOM</title>
<updated>2022-02-24T10:19:55+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2022-02-23T15:33:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a352fa58c0ee5c91714cd31a36b5cd308085fcbf'/>
<id>urn:sha1:a352fa58c0ee5c91714cd31a36b5cd308085fcbf</id>
<content type='text'>
The Qualcomm Embedded USB Debugger is not a pluggable USB device, and
can only be present on Qualcomm SoCs.  Hence add a dependency on
ARCH_QCOM, to prevent asking the user about this driver when configuring
a kernel without Qualcomm SoC support.

Fixes: 9a1bf58ccd443268 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://lore.kernel.org/r/f3ba3ea0d7f5e628c71cb7a9d62c9fb4589297b1.1645630266.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)</title>
<updated>2022-02-11T11:01:02+00:00</updated>
<author>
<name>Souradeep Chowdhury</name>
<email>quic_schowdhu@quicinc.com</email>
</author>
<published>2022-02-08T17:54:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a1bf58ccd4432688cee28a8e77726d7962fed13'/>
<id>urn:sha1:9a1bf58ccd4432688cee28a8e77726d7962fed13</id>
<content type='text'>
Add support for control peripheral of EUD (Embedded USB Debugger) to
listen to events such as USB attach/detach, pet EUD to indicate software
is functional.Reusing the platform device kobj, sysfs entry 'enable' is
created to enable or disable EUD.

To enable the eud the following needs to be done
echo 1 &gt; /sys/bus/platform/.../enable

To disable eud, following is the command
echo 0 &gt; /sys/bus/platform/.../enable

Signed-off-by: Souradeep Chowdhury &lt;quic_schowdhu@quicinc.com&gt;
Link: https://lore.kernel.org/r/0ac5c2b2c8e4ce4f4f342a08b48cfc61aeaf7ee8.1644339918.git.quic_schowdhu@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: Add driver to allow any GPIO to be used for 7211 USB signals</title>
<updated>2020-10-28T11:24:15+00:00</updated>
<author>
<name>Al Cooper</name>
<email>alcooperx@gmail.com</email>
</author>
<published>2020-10-12T20:00:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=517c4c44b32372d2fdf4421822e21083c45e89f9'/>
<id>urn:sha1:517c4c44b32372d2fdf4421822e21083c45e89f9</id>
<content type='text'>
The Broadcom 7211 has new functionality that allows some USB low
speed side band signals, that go from the XHCI host controller to
pins on the chip, to be remapped to use any GPIO pin instead of the
limited set selectable by hardware. This can be done without changing
the standard driver for the host controller. There is currently
support for three USB signals, PWRON, VBUS_PRESENT and PWRFLT. This
driver will allow the remapping of any of these three signals based
on settings in the Device Tree node for the driver. The driver was
written so that it could handle additional signals added in the
future by just adding the correct properties to the DT node.

Below is an example of a DT node that would remap all three
signals:

usb_pinmap: usb-pinmap@22000d0 {
	compatible = "brcm,usb-pinmap";
	reg = &lt;0x22000d0 0x4&gt;;
	in-gpios = &lt;&amp;gpio 18 0&gt;, &lt;&amp;gpio 19 0&gt;;
	brcm,in-functions = "VBUS", "PWRFLT";
	brcm,in-masks = &lt;0x8000 0x40000 0x10000 0x80000&gt;;
	out-gpios = &lt;&amp;gpio 20 0&gt;;
	brcm,out-functions = "PWRON";
	brcm,out-masks = &lt;0x20000 0x800000 0x400000 0x200000&gt;;
	interrupts = &lt;0x0 0xb2 0x4&gt;;
};

Signed-off-by: Al Cooper &lt;alcooperx@gmail.com&gt;
Link: https://lore.kernel.org/r/20201012200007.8862-3-alcooperx@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: Replace HTTP links with HTTPS ones</title>
<updated>2020-07-21T11:41:57+00:00</updated>
<author>
<name>Alexander A. Klimov</name>
<email>grandmaster@al2klimov.de</email>
</author>
<published>2020-07-19T16:09:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ffeb1e9e897b8d36b197275592d121c96d3bdb95'/>
<id>urn:sha1:ffeb1e9e897b8d36b197275592d121c96d3bdb95</id>
<content type='text'>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov &lt;grandmaster@al2klimov.de&gt;
Link: https://lore.kernel.org/r/20200719160910.60018-1-grandmaster@al2klimov.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
