So far, the binding and driver have relied on the fact that the H6
clocks are both a prefix and a subset of the R40 clocks. This allows
them to share the clocks/clock-names items and the clock-output-names
order between the hardware variants.
However, the D1 hardware has TCON TV0 and DSI, but no TCON TV1. This
cannot be supported by the existing scheme because it puts a gap in the
middle of the item lists. To prepare for adding D1 support, use separate
lists for variants with different combinations of clocks.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-2-samuel@sholland.org
For SCSI hosts which enable host_tagset the NUMA node returned from
blk_mq_hw_queue_to_node() is NUMA_NO_NODE always. Then, since in
scsi_mq_setup_tags() the default we choose for the tag_set NUMA node is
NUMA_NO_NODE, we always evaluate the NUMA node as NUMA_NO_NODE in functions
like blk_mq_alloc_rq_map().
The reason we get NUMA_NO_NODE from blk_mq_hw_queue_to_node() is that the
hctx_idx passed is BLK_MQ_NO_HCTX_IDX - so we can't match against a (HW)
queue mapping index.
Improve this by defaulting the tag_set NUMA node to the same NUMA node of
the SCSI host DMA dev.
Link: https://lore.kernel.org/r/1648640315-21419-1-git-send-email-john.garry@huawei.com
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If the user sets the usb_request's no_interrupt, then there will be no
completion event for the request. Currently the driver incorrectly uses
the event status of a different request to report the status for a
request with no_interrupt. The dwc3 driver needs to check the TRB status
associated with the request when reporting its status.
Note: this is only applicable to missed_isoc TRB completion status, but
the other status are also listed for completeness/documentation.
Fixes: 6d8a019614 ("usb: dwc3: gadget: check for Missed Isoc from event status")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/db2c80108286cfd108adb05bad52138b78d7c3a7.1650673655.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ARASAN MMC controller on Keystone 3 class of devices need the SDCD
line to be connected for proper functioning. Similar to the issue pointed
out in sdhci-of-arasan.c driver, commit 3794c54264 ("mmc:
sdhci-of-arasan: Set controller to test mode when no CD bit").
In cases where this can't be connected, add a quirk to force the
controller into test mode and set the TESTCD bit. Use the flag
"ti,fails-without-test-cd", to implement this above quirk when required.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20220425063120.10135-3-a-govindraju@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The ARASAN MMC controller on Keystone 3 class of devices needs the SDCD
line to be connected for proper functioning. Similar to the issue pointed
out in sdhci-of-arasan.c driver, commit 3794c54264 ("mmc:
sdhci-of-arasan: Set controller to test mode when no CD bit").
In cases where SDCD line is not connected, adding
"ti,fails-without-test-cd" in the DT node helps to indicate the
controller, that the SDCD line has been pulled down, using the TESTCD bit.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20220425063120.10135-2-a-govindraju@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We iterate an extra time through the IRQ status handling
loop despite nothing had fired. Enabling the debug prints:
mmci-pl18x 80005000.mmc: op 01 arg 00000000 flags 000000e1
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000001
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000000
mmci-pl18x 80005000.mmc: op 01 arg 40ff8080 flags 000000e1
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000001
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000000
It is pointless to loop through the function when status
is zero. Just break the loop if the status is zero.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220416224549.627623-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SDHC controller in the imx8mn and imx8mp have the same controller
as the imx8mm which is slightly different than that of the imx7d.
Using the fallback of the imx8mm enables the controllers to support
HS400-ES which is not available on the imx7d. After discussion with NXP,
it turns out that the imx8qm should fall back to the imx8qxp, because
those have some additional flags not present in the imx8mm.
Mark the current state of the fallbacks as deprecated, and add the
proper fallbacks so in the future, the deprecated combination can be
removed and prevent any future devices from using the wrong fallback.
Suggested-by: haibo.chen@nxp.com
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220410193544.1745684-1-aford173@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver, OMAP specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP custom implementation of clock API. However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.
Update the driver to be compatible with CCF implementation of clock API.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20220402112004.129886-1-jmkrzyszt@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Despite mmc_ioc_multi_cmd::num_of_cmds is a 64-bit field, its maximum
value is limited to MMC_IOC_MAX_CMDS (only 255); using a 64-bit local
variable to hold a copy of that field leads to gcc generating ineffective
loop code: despite the source code using an *int* variable for the loop
counters, the 32-bit object code uses 64-bit unsigned counters. Also,
gcc has to drop the most significant word of that 64-bit variable when
calling kcalloc() and assigning to mmc_queue_req::ioc_count anyway.
Using the *unsigned int* variable instead results in a better code.
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/eea3b0bd-6091-f005-7189-b5b7868abdb6@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Convert the marvell,xenon-sdhci binding to JSON schema. Currently the
in-tree dts files don't validate because they use sdhci@ instead of mmc@
as required by the generic mmc-controller schema.
The compatible "marvell,sdhci-xenon" was not documented in the old
binding but it accompanies the of "marvell,armada-3700-sdhci" in the
armada-37xx SoC dtsi so this combination is added to the new binding
document.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220329220544.2132135-3-chris.packham@alliedtelesis.co.nz
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In SDIO mode, the sg list for requests can be unaligned with what the
STM32 SDMMC internal DMA can support. In that case, instead of failing,
use a temporary bounce buffer to copy from/to the sg list.
This buffer is limited to 1MB. But for that we need to also limit
max_req_size to 1MB. It has not shown any throughput penalties for
SD-cards or eMMC.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Link: https://lore.kernel.org/r/20220328145114.334577-1-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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).
Note: the current series only supports hubs connected directly to
a root hub, support for other configurations could be added if
needed.
Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220217104219.v21.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds a "gadget" bus and uses it for registering gadgets and
their drivers. From now on, bindings will be managed by the driver
core rather than through ad-hoc manipulations in the UDC core.
As part of this change, the driver_pending_list is removed. The UDC
core won't need to keep track of unbound drivers for later binding,
because the driver core handles all of that for us.
However, we do need one new feature: a way to prevent gadget drivers
from being bound to more than one gadget at a time. The existing code
does this automatically, but the driver core doesn't -- it's perfectly
happy to bind a single driver to all the matching devices on the bus.
The patch adds a new bitflag to the usb_gadget_driver structure for
this purpose.
A nice side effect of this change is a reduction in the total lines of
code, since now the driver core will do part of the work that the UDC
used to do.
A possible future patch could add udc devices to the gadget bus, say
as a separate device type.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YmSpdxaDNeC2BBOf@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation for adding a "gadget" bus, this patch reverses the
order of registration of udc and gadget devices in usb_add_gadget().
The current code adds the gadget device first, probably because that
was more convenient at the time and the order didn't really matter.
But with the upcoming change, adding the gadget will cause driver
probing to occur. Unwinding that on the error pathway will become
much more obtrusive, not to mention the fact that a gadget driver
might not work properly before the udc is registered. It's better to
register the udc device first, particularly since that doesn't involve
a bus or driver binding and therefore is simpler to unwind.
For symmetry, the order of unregistration in usb_del_gadget() is
likewise reversed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YmSo6fU1FlNq8cOZ@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation for adding a "gadget" bus, this patch renames
usb_gadget_probe_driver() to usb_gadget_register_driver(). The new
name will be more accurate, since gadget drivers will be registered on
the gadget bus and the probing will be done by the driver core, not
the UDC core.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YmSc29YZvxgT5fEJ@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
