drm/amdgpu: add mmhub v3_0_2 ip callback functions
Unlike mmhub v3_0_0, there is no atc_l2 related
registers available in mmhub v3_0_2. Split the mmhub
v3_0_2 callback implementations from mmhub v3_0 so we
don't need to add ip version check when atc related
programming needs to be added to mmhub v3_0_0.
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:376:6: warning: variable 'index' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (ring->is_mes_queue) {
^~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:433:30: note: uninitialized use occurs here
amdgpu_device_wb_free(adev, index);
^~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:376:2: note: remove the 'if' if its condition is always false
if (ring->is_mes_queue) {
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:364:16: note: initialize the variable 'index' to silence this warning
unsigned index;
^
= 0
Signed-off-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3846:6: warning: variable 'index' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (ring->is_mes_queue) {
^~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3903:30: note: uninitialized use occurs here
amdgpu_device_wb_free(adev, index);
^~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3846:2: note: remove the 'if' if its condition is always false
if (ring->is_mes_queue) {
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3839:16: note: initialize the variable 'index' to silence this warning
unsigned index;
^
= 0
Signed-off-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This was added a helper for amdgpu to workaround a runtime pm regression
caused by a runtime pm fix in efifb. We now have a better workaround
in amdgpu in
commit f95af4a9236695 ("drm/amdgpu: don't runtime suspend if there are displays attached (v3)")
so this workaround is no longer necessary. Since amdgpu was the only
user of this interface, we can remove it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This workaround is no longer necessary. We have a better workaround
in commit f95af4a9236695 ("drm/amdgpu: don't runtime suspend if there are displays attached (v3)").
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
tty: hvc: dcc: Bind driver to CPU core0 for reads and writes
Some external debuggers do not handle reads/writes from/to DCC
on secondary cores. Each core has its own DCC device registers,
so when a core reads or writes from/to DCC, it only accesses
its own DCC device. Since kernel code can run on any core,
every time the kernel wants to write to the console, it might
write to a different DCC.
In SMP mode, external debugger creates multiple windows, and
each window shows the DCC output only from that core's DCC.
The result is that console output is either lost or scattered
across windows.
Selecting this debug option will enable code that serializes all
console input and output to core 0. The DCC driver will create
input and output FIFOs that all cores will use. Reads and writes
from/to DCC are handled by a workqueue that runs only core 0.
This is a debug feature to be used only in early stage development
where debug serial console support would not be present. It disables
PM feature like CPU hotplug and is not suitable for production
environment.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> Acked-by: Adam Wallis <awallis@codeaurora.org> Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Elliot Berman <eberman@codeaurora.org> Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com> Link: https://lore.kernel.org/r/20220428090858.14489-1-quic_saipraka@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilpo Järvinen [Wed, 4 May 2022 07:20:46 +0000 (10:20 +0300)]
termbits: Convert octal defines to hex
Many archs have termbits.h as octal numbers. It makes hard for humans
to parse the magnitude of large numbers correctly and to compare with
hex ones of the same define.
Convert octal values to hex.
First step is an automated conversion with:
for i in $(git ls-files | grep 'termbits\.h'); do
awk --non-decimal-data '/^#define\s+[A-Z][A-Z0-9]*\s+0[0-9]/ {
l=int(((length($3) - 1) * 3 + 3) / 4);
repl = sprintf("0x%0" l "x", $3);
print gensub(/[^[:blank:]]+/, repl, 3);
next} {print}' $i > $i~;
mv $i~ $i;
done
On top of that, some manual processing on alignment and number of zeros.
In addition, small tweaks to formatting of a few comments on the same
lines.
Jiri Slaby [Tue, 3 May 2022 08:08:04 +0000 (10:08 +0200)]
serial: pch: decomission pch_uart_hal_write()
It's horrid and if we inline it into callers, we can get rid of a lot of
sugar around.
So:
* x_char handling becomes a single iowrite8.
* xmit->buf handling is a single loop simply writing characters one by
one directly from the buf instead of complex cnt_to_end computations.
Until the buf is empty or fifo size is reached.
Jiri Slaby [Tue, 3 May 2022 08:08:03 +0000 (10:08 +0200)]
serial: pch: don't overwrite xmit->buf[0] by x_char
When x_char is to be sent, the TX path overwrites whatever is in the
circular buffer at offset 0 with x_char and sends it using
pch_uart_hal_write(). I don't understand how this was supposed to work
if xmit->buf[0] already contained some character. It must have been
lost.
Remove this whole pop_tx_x() concept and do the work directly in the
callers. (Without printing anything using dev_dbg().)
Jiri Slaby [Tue, 3 May 2022 08:06:07 +0000 (10:06 +0200)]
serial: pch: move size check from pop_tx one level up
'count' is zero in the pop_tx()'s comparison against 'size'. So the 'if'
tries to find out if 'size' is negative or zero and returns in that
case. But it cannot be negative, due to previous (size < 0) check in the
caller: handle_tx().
So simply move this check from pop_tx() to handle_tx(). Now it's clear
that pop_tx() is called only if fifo_size is non-zero.
Jiri Slaby [Tue, 3 May 2022 06:31:22 +0000 (08:31 +0200)]
serial: pic32: restore disabled irqs in pic32_uart_startup()
pic32_uart_startup() disables interrupts by local_irq_save(). But the
function never enables them. The serial core only holds a mutex, so irqs
are not restored.
So how could this driver work? This irq handling was already present in
the driver's initial commit 157b9394709ed (serial: pic32_uart: Add PIC32
UART driver).
So is it a candidate for removal? Anyone has a contact to the author:
Andrei Pistirica (I believe the one below -- @microchip.com -- will
bounce)? Or to someone else @microchip.com?
Jiri Slaby [Tue, 3 May 2022 06:31:21 +0000 (08:31 +0200)]
serial: pic32: free up irq names correctly
struct pic32_sport contains built-up names for irqs. These are freed
only in error path of pic32_uart_startup(). And even there, the freeing
happens before free_irq().
So fix this by:
* moving frees after free_irq(), and
* add frees to pic32_uart_shutdown() -- the opposite of
pic32_uart_startup().
Jiri Slaby [Tue, 3 May 2022 06:31:18 +0000 (08:31 +0200)]
serial: pic32: convert to_pic32_sport() to an inline
'c' is not in wrapped in parentheses in the to_pic32_sport() macro, so
it might be problematic wrt macro expansion. Using an inline is always
safer in these cases. Both type-wise and macro-expansion-wise. So switch
the macro to an inline.
Jiri Slaby [Tue, 3 May 2022 06:31:17 +0000 (08:31 +0200)]
serial: pic32: remove pic32_get_port() macro
It's just &sport->port. First, sport was not in parenthesis, so macro
expansion could be an issue. Second, it's so simple, that we can expand
the macro and make the code really straightforward.
Jiri Slaby [Tue, 3 May 2022 06:31:15 +0000 (08:31 +0200)]
serial: pic32: simplify clk handling
struct pic32_sport::ref_clk is only set, but not read. That means we can
remove it. And when we do so, pic32_enable_clock() and
pic32_disable_clock() are simple wrappers around clk_prepare_enable()
and clk_disable_unprepare() respectively. So we can remove the former
two from the code and replace it by the latter two.
Marek Vasut [Sat, 30 Apr 2022 16:28:45 +0000 (18:28 +0200)]
serial: stm32: Use TC interrupt to deassert GPIO RTS in RS485 mode
In case the RS485 mode is emulated using GPIO RTS, use the TC interrupt
to deassert the GPIO RTS, otherwise the GPIO RTS stays asserted after a
transmission ended and the RS485 cannot work.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Erwan Le Ray <erwan.leray@foss.st.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jean Philippe Romain <jean-philippe.romain@foss.st.com> Cc: Valentin Caron <valentin.caron@foss.st.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-serial@vger.kernel.org Link: https://lore.kernel.org/r/20220430162845.244655-2-marex@denx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The `clkin_rate' member of `struct sifive_serial_port' now duplicates
`uartclk' from nested `struct uart_port', so use `uartclk' throughout
and remove `clkin_rate'.
serial: sifive: Report actual baud base rather than fixed 115200
The base baud value reported is supposed to be the highest baud rate
that can be set for a serial port. The SiFive FU740-C000 SOC's on-chip
UART supports baud rates of up to 1/16 of the input clock rate, which is
the bus clock `tlclk'[1], often at 130MHz in the case of the HiFive
Unmatched board.
However the sifive UART driver reports a fixed value of 115200 instead:
10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 115200) is a SiFive UART v0 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 115200) is a SiFive UART v0
even though we already support setting higher baud rates, e.g.:
$ tty
/dev/ttySIF1
$ stty speed
230400
The baud base value is computed by the serial core by dividing the UART
clock recorded in `struct uart_port' by 16, which is also the minimum
value of the clock divider supported, so correct the baud base value
reported by setting the UART clock recorded to the input clock rate
rather than 115200:
10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 8125000) is a SiFive UART v0 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 8125000) is a SiFive UART v0
serial: 8250: Add proper clock handling for OxSemi PCIe devices
Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven
by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock.
We currently drive the device using its default oversampling rate of 16
and the clock prescaler disabled, consequently yielding the baud base of 3906250. This base is inadequate for some of the high-speed baud rates
such as 460800bps, for which the closest rate possible can be obtained
by dividing the baud base by 8, yielding the baud rate of 488281.25bps,
which is off by 5.9638%. This is enough for data communication to break
with the remote end talking actual 460800bps, where missed stop bits
have been observed.
We can do better however, by taking advantage of a reduced oversampling
rate, which can be set to any integer value from 4 to 16 inclusive by
programming the TCR register, and by using the clock prescaler, which
can be set to any value from 1 to 63.875 in increments of 0.125 in the
CPR/CPR2 register pair. The prescaler has to be explicitly enabled
though by setting bit 7 in the MCR or otherwise it is bypassed (in the
enhanced mode that we enable) as if the value of 1 was used.
Make use of these features then as follows:
- Set the baud base to 15625000, reflecting the minimum oversampling
rate of 4 with the clock prescaler and divisor both set to 1.
- Override the `set_mctrl' and set the MCR shadow there so as to have
MCR[7] always set and have the 8250 core propagate these settings.
- Override the `get_divisor' handler and determine a good combination of
parameters by using a lookup table with predetermined value pairs of
the oversampling rate and the clock prescaler and finding a pair that
divides the input clock such that the quotient, when rounded to the
nearest integer, deviates the least from the exact result. Calculate
the clock divisor accordingly.
Scale the resulting oversampling rate (only by powers of two) if
possible so as to maximise it, reducing the divisor accordingly, and
avoid a divisor overflow for very low baud rates by scaling the
oversampling rate and/or the prescaler even if that causes some
accuracy loss.
Also handle the historic spd_cust feature so as to allow one to set
all the three parameters manually to arbitrary values, by keeping the
low 16 bits for the divisor and then putting TCR in bits 19:16 and
CPR/CPR2 in bits 28:20, sanitising the bit pattern supplied such as
to clamp CPR/CPR2 values between 0.000 and 0.875 inclusive to 33.875.
This preserves compatibility with any existing setups, that is where
requesting a custom divisor that only has any bits set among the low
16 the oversampling rate of 16 and the clock prescaler of 33.875 will
be used as with the original 8250.
Finally abuse the `frac' argument to store the determined bit patterns
for the TCR, CPR and CPR2 registers.
- Override the `set_divisor' handler so as to set the TCR, CPR and CPR2
registers from the `frac' value supplied. Set the divisor as usual.
With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX
limitation imposed by `serial8250_get_baud_rate' standard baud rates
below 300bps become unavailable in the regular way, e.g. the rate of
200bps requires the baud base to be divided by 78125 and that is beyond
the unsigned 16-bit range. The historic spd_cust feature can still be
used to obtain such rates if so required.
See Documentation/tty/device_drivers/oxsemi-tornado.rst for more details.
serial: 8250: Export ICR access helpers for internal use
Make ICR access helpers available outside 8250_port.c, however retain
them as ordinary static functions so as not to regress code generation.
This is because `serial_icr_write' is currently automatically inlined by
GCC, however `serial_icr_read' is not. Making them both static inline
would grow code produced, e.g.:
$ i386-linux-gnu-size --format=gnu 8250_port-{old,new}.o
text data bss total filename
15065 3378 0 18443 8250_port-old.o
15289 3378 0 18667 8250_port-new.o
and:
$ riscv64-linux-gnu-size --format=gnu 8250_port-{old,new}.o
text data bss total filename
16980 5306 0 22286 8250_port-old.o
17124 5306 0 22430 8250_port-new.o
while making them external would needlessly add a new module interface
and lose the benefit from `serial_icr_write' getting inlined outside
8250_port.o.
serial: 8250: Fold EndRun device support into OxSemi Tornado code
The EndRun PTP/1588 dual serial port device is based on the Oxford
Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set
for EndRun Technologies and uses the same sequence to determine the
number of ports available. Despite that we have duplicate code
specific to the EndRun device.
Remove redundant code then and factor out OxSemi Tornado device
detection.
Alex Deucher [Thu, 5 May 2022 03:17:38 +0000 (23:17 -0400)]
drm/amdgpu/gfx11: remove some register fields that no longer exist
Some copy paste leftovers for older asics. They were protected
by __BIG_ENDIAN, so we didn't notice them initially.
Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dan Vacura [Tue, 3 May 2022 20:10:38 +0000 (15:10 -0500)]
usb: gadget: uvc: allow for application to cleanly shutdown
Several types of kernel panics can occur due to timing during the uvc
gadget removal. This appears to be a problem with gadget resources being
managed by both the client application's v4l2 open/close and the UDC
gadget bind/unbind. Since the concept of USB_GADGET_DELAYED_STATUS
doesn't exist for unbind, add a wait to allow for the application to
close out.
usb: typec: tcpci: Don't skip cleanup in .remove() on error
Returning an error value in an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
In this case the remove callback even returns early without stopping the
tcpm worker thread and various timers. A work scheduled on the work
queue, or a firing timer after tcpci_remove() returned probably results
in a use-after-free situation because the regmap and driver data were
freed. So better make sure that tcpci_unregister_port() is called even
if disabling the irq failed.
Also emit a more specific error message instead of the i2c core's
"remove failed (EIO), will be ignored" and return 0 to suppress the
core's warning.
This patch is (also) a preparation for making i2c remove callbacks
return void.
Sergey Ryazanov [Sun, 1 May 2022 17:58:28 +0000 (20:58 +0300)]
usb: cdc-wdm: fix reading stuck on device close
cdc-wdm tracks whether a response reading request is in-progress and
blocks the next request from being sent until the previous request is
completed. As soon as last user closes the cdc-wdm device file, the
driver cancels any ongoing requests, resets the pending response
counter, but leaves the response reading in-progress flag
(WDM_RESPONDING) untouched.
So if the user closes the device file during the response receive
request is being performed, no more data will be obtained from the
modem. The request will be cancelled, effectively preventing the
WDM_RESPONDING flag from being reseted. Keeping the flag set will
prevent a new response receive request from being sent, permanently
blocking the read path. The read path will staying blocked until the
module will be reloaded or till the modem will be re-attached.
This stuck has been observed with a Huawei E3372 modem attached to an
OpenWrt router and using the comgt utility to set up a network
connection.
Fix this issue by clearing the WDM_RESPONDING flag on the device file
close.
Without this fix, the device reading stuck can be easily reproduced in a
few connection establishing attempts. With this fix, a load test for
modem connection re-establishing worked for several hours without any
issues.
Fixes: 922a5eadd5a3 ("usb: cdc-wdm: Fix race between autosuspend and reading from the device") Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Cc: stable <stable@vger.kernel.org> Acked-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20220501175828.8185-1-ryazanov.s.a@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just like the header is tracking the formats in a linked list, in this
patch we track the frames in a linked list of the formats. It
simplifies the parsing of the configfs structure.
The functions and structs of the configfs interface should also be used
by the uvc gadget driver. This patch prepares the stack by moving the
common structs and functions to the common header file.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220421211427.3400834-5-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arm64: dts: qcom: correct DWC3 node names and unit addresses
Align DWC3 USB node names with DT schema ("usb" is expected) and correct
the unit addresses to match the "reg" property. This also implies
overriding nodes by label, instead of full path.
The bindings defined strict clocks but several variants do not use them
in such order. Split the clocks and clock-names per variants to match
current DTS usage. In few cases this might not be complete match, due
to incomplete DTS.
dt-bindings: usb: qcom,dwc3: add IPQ8074, MSM8994, QCS404 and SM6125
Add compatibles for dedicated USB DWC3 blocks on Qualcomm IPQ8074,
MSM8994, QCS404 and SM6125. They differ against other variants in clock
and/or interrupts.
If the controller hasn't DMA'ed the Setup data from its fifo, it won't
process the End Transfer command. Polling for the command completion may
block the driver from servicing the Setup phase and cause a timeout.
Previously we only check and delay issuing End Transfer in the case of
endpoint dequeue. Let's do that for all End Transfer scenarios.
usb: dwc3: gadget: Only End Transfer for ep0 data phase
The driver shouldn't be able to issue End Transfer to the control
endpoint at anytime. Typically we should only do so in error cases such
as invalid/unexpected direction of Data Phase as described in the
control transfer flow of the programming guide. It _may_ end started
data phase during controller deinitialization from soft disconnect or
driver removal. However, that should not happen because the driver
should be maintained in EP0_SETUP_PHASE during driver tear-down. On
soft-connect, the controller should be reset from a soft-reset and there
should be no issue starting the control endpoint.
Since we can't guarantee that the host won't send new Setup packet
before going through the device-initiated disconnect, don't prepare
beyond the Setup stage and keep the device in EP0_SETUP_PHASE. This
ensures that the device-initated disconnect sequence can go through
gracefully. Note that the controller won't service the End Transfer
command if it can't DMA out the Setup packet.
usb: dwc3: gadget: Don't modify GEVNTCOUNT in pullup()
If the GEVNTCOUNT indicates events in the event buffer, the driver needs
to acknowledge them before the controller can halt. Simply let the
interrupt handler acknowledges the remaining event generated by the
controller while polling for DSTS.DEVCTLHLT. This avoids disabling irq
and taking care of race condition between the interrupt handlers and
pullup().
Don't do soft-disconnect if it's previously done. Likewise, don't do
soft-connect if the device is currently connected and running. It would
break normal operation.
Currently the caller of pullup() (udc's sysfs soft_connect) only checks
if it had initiated disconnect to prevent repeating soft-disconnect. It
doesn't check for soft-connect. To be safe, let's keep the check here
regardless whether the udc core is fixed.
Piyush Mehta [Wed, 4 May 2022 07:53:09 +0000 (13:23 +0530)]
usb: dwc3: xilinx: Add gpio-reset support
This patch adds a USB GPIO based reset for dwc3-xilinx driver. The PHY
needs to be reset after the completion of phy initialization. As part
of the reset, check for gpio-reset binding before toggling the pin.
This feature is advantageous when the user toggle GPIO to trigger the
ULPI-PHY reset.
Delay of milliseconds is added in between low and high to meet the setup
and hold time requirement of the reset. The reset-gpio error handling is
added for error notification.
Some GPIO controllers must be accessed using message-based buses, like
I2C or SPI, to address this problem, updates GPIO access with sleep API.
Kushagra Verma [Mon, 2 May 2022 09:07:14 +0000 (14:37 +0530)]
usb: dwc3: remove a possible unnecessary 'out of memory' message
This patch removes a possible unnecessary out of memory message from
core.c as reported by checkpatch.pl:
WARNING: Possible unnecessary 'out of memory' message
Heikki Krogerus [Thu, 28 Apr 2022 11:10:56 +0000 (14:10 +0300)]
usb: dwc3: host: Stop setting the ACPI companion
It is no longer needed. The sysdev pointer is now used when
assigning the ACPI companions to the xHCI ports and USB
devices.
Assigning the ACPI companion here resulted in the
fwnode->secondary pointer to be replaced also for the parent
dwc3 device since the primary fwnode (the ACPI companion)
was shared. That was unintentional and it created potential
side effects like resource leaks.
Heikki Krogerus [Thu, 28 Apr 2022 11:10:55 +0000 (14:10 +0300)]
usb: core: acpi: Use the sysdev pointer instead of controller device
The controller device (hcd) does not always have the ACPI
companion assigned to it at all. We can not rely on it when
finding the ACPI companion for the root hub. Instead we need
to use the sysdev pointer.
projects / people / ms / linux.git / log
