Remove the dpni_id and buffer_layout fields from device's
private structure. They're only used at probe so we don't
need to store them for further use.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introduce a helper macro for accessing the frame annotation
status field in a frame buffer.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a label to the ethtool statistics counters, to differentiate
between hardware counters and driver specific ones.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the Ethernet driver doesn't find any DPIO devices during probe,
it may be either because there's none available or because they
haven't been probed yet. Request deferred probing in case it's
the latter.
Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reset the buffer pool object before using it, like we do
for the other DPAA2 objects.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function itself checks whether GRO support is enabled
and acts accordingly, so we don't need to verify it in the
driver as well.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't use GFP_DMA when allocating memory for the hash key,
as we don't actually need to allocate from the lowest zone.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A few error/warning messages lacked a newline at the end
of the text. Add it for improved consistency and cosmetics.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Not having Rx hashing distribution enabled for an
interface is a valid configuration and shouldn't be
treated as an error.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ndo_start_xmit() returns a value of type netdev_tx_t. Update
our ndo function to use the correct type.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In dpni_get_irq_status(), status is both in and out parameter,
so initialize before use.
Issue found through static analysis tool.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make a couple of locally used functions and structures static.
Issue found through static analysis tool.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add pins, groups, and a function for EtherAVB on R-Car H3 ES2.0.
Extracted from a big patch in the BSP by Takeshi Kihara.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Setting an alt_speed using the ROCKET_SPD flags has been deprecated
since v2.1.69, and has been broken since commit 6865ff222c ("TTY: do
not warn about setting speed via SPD_*") without anyone noticing.
To make things worse commit 6df3526b66 ("rocket: first pass at termios
reporting") in v2.6.25 started reporting back the actual baud rate used,
something which also required 38400 to again be set whenever changing a
SPD flag.
Drop the broken alt-speed handling altogether, and add a ratelimited
warning about using TIOCCSERIAL to change speed as being deprecated.
Note that the rocket driver has never supported using a custom divisor
(ASYNC_SPD_CUST equivalent).
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Setting an alt_speed using the ASYNC_SPD flags has been deprecated since
v2.1.69, and has been broken since v3.10 and commit 6865ff222c ("TTY:
do not warn about setting speed via SPD_*") without anyone noticing.
Drop the broken alt-speed handling altogether, and add a ratelimited
warning about using TIOCCSERIAL to to change speed as being deprecated.
Note that using ASYNC_SPD_CUST is still supported.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Setting an alt_speed using the ASYNC_SPD flags has been deprecated since
v2.1.69, and has been broken since v3.10 and commit 6865ff222c ("TTY:
do not warn about setting speed via SPD_*") without anyone noticing.
Drop the broken alt-speed handling altogether, and add a ratelimited
warning about using TIOCCSERIAL to change speed as being deprecated.
Note that using ASYNC_SPD_CUST is still supported.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the broken alt_speed code, and warn when trying to set the line
speed using TIOCSSERIAL and SPD flags.
The use of SPD flags to set the line speed has been deprecated since
v2.1.69 and support for alt_speed (e.g. "warp") has even been removed
from TTY core in v3.10 by commit 6865ff222c ("TTY: do not warn about
setting speed via SPD_*"), effectively breaking all driver
implementations of this except for serial core.
Also remove the verbose and outdated comment on how to set baud rates.
Note that setting a custom divisor will continue to work with the
caveat that 38400 must again be selected every time the divisor is
changed since v2.6.24 and commit 669a6db103 ("USB: ftd_sio: cleanups
and updates for new termios work") which started reporting back the
actual baud rate used.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Contrary to what a comment claimed, the ASYNC_SPD flags and custom
divisor can be set by a non-privileged user so rate limit the
deprecation notice as was intended.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the new helper for reusing a device-tree node of another device
instead of managing the node references explicitly.
This also makes sure that the new of_node_reuse flag is set if the
device is ever reprobed, something which specifically now avoids driver
core from attempting to claim any pinmux resources already claimed by
the parent device.
Fixes: ec4664b3fd ("thermal: max77620: Add thermal driver for reporting junction temp")
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The thermal child device reuses the parent MFD-device device-tree node
when registering a thermal zone, but did not take a reference to the
node.
This leads to a reference imbalance, and potential use-after-free, when
the node reference is dropped by the platform-bus device destructor
(once for the child and later again for the parent).
Fix this by dropping any reference already held to a device-tree node
and getting a reference to the parent's node which will be balanced on
reprobe or on platform-device release, whichever comes first.
Note that simply clearing the of_node pointer on probe errors and on
driver unbind would not allow the use of device-managed resources as
specifically thermal_zone_of_sensor_unregister() claims that a valid
device-tree node pointer is needed during deregistration (even if it
currently does not seem to use it).
Fixes: ec4664b3fd ("thermal: max77620: Add thermal driver for reporting junction temp")
Cc: stable <stable@vger.kernel.org> # 4.9
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In an attempt to work around a pinmux over-allocation issue in driver
core, commit dc5878abf4 ("usb: core: move root hub's device node
assignment after it is added to bus") moved the device-tree node
assignment until after the root hub had been registered.
This not only makes the device-tree node unavailable to the usb driver
during probe, but also prevents the of_node from being linked to in
sysfs and causes a race with user-space for the (recently added) devspec
attribute.
Use the new device_set_of_node_from_dev() helper to reuse the node of
the sysdev device, something which now prevents driver core from trying
to reclaim any pinctrl pins during probe.
Fixes: dc5878abf4 ("usb: core: move root hub's device node assignment after it is added to bus")
Fixes: 51fa91475e ("usb/core: Added devspec sysfs entry for devices behind the usb hub")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit ab78029ecc ("drivers/pinctrl: grab default handles from device
core") added automatic pin-control management to driver core by looking
up and setting any default pinctrl state found in device tree while a
device is being probed.
This obviously runs into problems as soon as device-tree nodes are
reused for child devices which are later also probed as pins would
already have been claimed by the ancestor device.
For example if a USB host controller claims a pin, its root hub would
consequently fail to probe when its device-tree node is set to the node
of the controller:
pinctrl-single 48002030.pinmux: pin PIN204 already requested by 48064800.ehci; cannot claim for usb1
pinctrl-single 48002030.pinmux: pin-204 (usb1) status -22
pinctrl-single 48002030.pinmux: could not request pin 204 (PIN204) from group usb_dbg_pins on device pinctrl-single
usb usb1: Error applying setting, reverse things back
usb: probe of usb1 failed with error -22
Fix this by checking the new of_node_reused flag and skipping automatic
pinctrl configuration during probe if set.
Note that the flag is checked in driver core rather than in pinctrl
(e.g. in pinctrl_dt_to_map()) which would specifically have prevented
intentional use of a parent's pinctrl properties by a child device
(should such a need ever arise).
Fixes: ab78029ecc ("drivers/pinctrl: grab default handles from device core")
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a helper function to be used when reusing the device-tree node of
another device.
It is fairly common for drivers to reuse the device-tree node of a
parent (or other ancestor) device when creating class or bus devices
(e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
usb root hubs). But reusing a device-tree node may cause problems if the
new device is later probed as for example driver core would currently
attempt to reinitialise an already active associated pinmux
configuration.
Other potential issues include the platform-bus code unconditionally
dropping the device-tree node reference in its device destructor,
reinitialisation of other bus-managed resources such as clocks, and the
recently added DMA-setup in driver core.
Note that for most examples above this is currently not an issue as the
devices are never probed, but this is a problem for the USB bus which
has recently gained device-tree support. This was discovered and
worked-around in a rather ad-hoc fashion by commit dc5878abf4 ("usb:
core: move root hub's device node assignment after it is added to bus")
by not setting the of_node pointer until after the root-hub device has
been registered.
Instead we can allow devices to reuse a device-tree node by setting a
flag in their struct device that can be used by core, bus and driver
code to avoid resources from being over-allocated.
Note that the helper also grabs an extra reference to the device node,
which specifically balances the unconditional put in the platform-device
destructor.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Document that the child-node lookup helper takes a reference to the
device-tree node which needs to be dropped after use.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to release any OF device-node reference taken when creating
the USB device.
Note that we currently do not hold a reference to the root hub
device-tree node (i.e. the parent controller node).
Fixes: 69bec72598 ("USB: core: let USB device know device node")
Cc: stable <stable@vger.kernel.org> # v4.6
Acked-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trace_printk() was used to log debug messages in xhci-dbc.c where
printk() isn't feasible. As there should not be a single caller to
trace_printk() in normal kernels, replace them with empty functions.
Cc: Vlastimil Babka <vbabka.lkml@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Each vhci has 2*VHCI_HC_PORTS ports, in which VHCI_HC_PORTS
ports are HighSpeed (or below), and VHCI_HC_PORTS are SuperSpeed.
This new macro VHCI_PORTS reflects this configuration.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds a USB3 HCD to an existing USB2 HCD and provides
the support of SuperSpeed, in case the device can only be enumerated
with SuperSpeed.
The bulk of the added code in usb3_bos_desc and hub_control to support
SuperSpeed is borrowed from the commit 1cd8fd2887 ("usb: gadget:
dummy_hcd: add SuperSpeed support").
With this patch, each vhci will have VHCI_HC_PORTS HighSpeed ports
and VHCI_HC_PORTS SuperSpeed ports.
Suggested-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A vhci struct is added as the platform-specific data to the vhci
platform device, in order to get the vhci by its platform device.
This is done in vhci_hcd_init().
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to support SuperSpeed devices, a USB3 HCD is added to
share the USB2 HCD. As a result, a VHCI is composed of two
vhci_hcds associated with the two HCDs respectively. So we add
another level of abstraction, vhci, and thus this vhci structure.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These helper function names are renamed to have their full struct
names to avoid confusion:
- hcd_to_vhci() -> hcd_to_vhci_hcd()
- vhci_to_hcd() -> vhci_hcd_to_hcd()
- vdev_to_vhci() -> vdev_to_vhci_hcd()
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usbip stack dynamically allocates the transfer_buffer and
setup_packet of each urb that got generated by the tcp to usb stub code.
As these pointers are always used only once we will set them to NULL
after use. This is done likewise to the free_urb code in vudc_dev.c.
This patch fixes double kfree situations where the usbip remote side
added the URB_FREE_BUFFER.
Cc: stable@vger.kernel.org
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usbfs interface does not provide any way for the user to learn the
speed at which a device is connected. The current API includes a
USBDEVFS_CONNECTINFO ioctl, but all it provides is the device's
address and a one-bit value indicating whether the connection is low
speed. That may have sufficed in the era of USB-1.1, but it isn't
good enough today.
This patch introduces a new ioctl, USBDEVFS_GET_SPEED, which returns a
numeric value indicating the speed of the connection: unknown, low,
full, high, wireless, super, or super-plus.
Similar information (not exactly the same) is available through sysfs,
but it seems reasonable to provide the actual value in usbfs.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Reinhard Huck <reinhard.huck@thesycon.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I missed converting the last zram attribute to CLASS_ATTR_RO() after
removing CLASS_ATTR() from the kernel, causing a build breakage. This
patch fixes that problem.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The qcserial driver fails to expose the .tiocmget and .tiocmset methods
available from usb_wwan. These methods are required by ioctl commands
dealing with the modem control signals DTR, RTS, etc.
With these methods not set ioctl calls intended to control the DTR state
will fail. For example, pppd drops and raises DTR in preparation to
dialing the modem, which handles the case of the modem already being
connected by making it hang up and return to command mode. DTR control
being unavailable will lead to a protracted failure to connect as the
modem will be stuck in a state not responsive to command.
I have tested that with this patch the described case is handled
successfully. There is an analogous method for .ioctl available from
usb_wwan (as used in option.c) but I conservatively omitted that for
lack of familiarity.
Signed-off-by: Magnus Lynch <maglyx@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Remove unnecessary variable and refactor the code.
Addresses-Coverity-ID: 1365000
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
