Netlink support of extended packet number cipher suites,
allows adding and updating XPN macsec interfaces.
Added support in:
* Creating interfaces with GCM-AES-XPN-128 and GCM-AES-XPN-256 suites.
* Setting and getting 64bit packet numbers with of SAs.
* Setting (only on SA creation) and getting ssci of SAs.
* Setting salt when installing a SAK.
Added 2 cipher suite identifiers according to 802.1AE-2018 table 14-1:
* MACSEC_CIPHER_ID_GCM_AES_XPN_128
* MACSEC_CIPHER_ID_GCM_AES_XPN_256
In addition, added 2 new netlink attribute types:
* MACSEC_SA_ATTR_SSCI
* MACSEC_SA_ATTR_SALT
Depends on: macsec: Support XPN frame handling - IEEE 802.1AEbw.
Change-Id: Ia7efe40e1c9f7434a025faec075020717220327d
Signed-off-by: Era Mayflower <mayflowerera@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: 48ef50fa866aae087f63c7de8a47e76537f88691
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
Support extended packet number cipher suites (802.1AEbw) frames handling.
This does not include the needed netlink patches.
* Added xpn boolean field to `struct macsec_secy`.
* Added ssci field to `struct_macsec_tx_sa` (802.1AE figure 10-5).
* Added ssci field to `struct_macsec_rx_sa` (802.1AE figure 10-5).
* Added salt field to `struct macsec_key` (802.1AE 10.7 NOTE 1).
* Created pn_t type for easy access to lower and upper halves.
* Created salt_t type for easy access to the "ssci" and "pn" parts.
* Created `macsec_fill_iv_xpn` function to create IV in XPN mode.
* Support in PN recovery and preliminary replay check in XPN mode.
In addition, according to IEEE 802.1AEbw figure 10-5, the PN of incoming
frame can be 0 when XPN cipher suite is used, so fixed the function
`macsec_validate_skb` to fail on PN=0 only if XPN is off.
Change-Id: I2558cd6ecfbfac3a183095278bcaafc6e8b19f23
Signed-off-by: Era Mayflower <mayflowerera@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: a21ecf0e033807b976967286e6c392f48ee2049f
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
Allow to call macsec_pn_wrapped from hardware drivers to notify when a
PN rolls over. Some drivers might used an interrupt to implement this.
Change-Id: Icf37413f1c35a78f3edaecbf514a7cd85d3bdbe9
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: 5c937de78b39e47ce9924fc4b863c5b727edc328
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
MACsec offloading to underlying hardware devices is disabled by default
(the software implementation is used). This patch adds support for
changing this setting through the MACsec netlink interface. Many checks
are done when enabling offloading on a given MACsec interface as there
are limitations (it must be supported by the hardware, only a single
interface can be offloaded on a given physical device at a time, rules
can't be moved for now).
Change-Id: Ia0b0898e7972f24e79eefcd65ff480ac819a4bb9
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: dcb780fb279514f268826f2e9f4df3bc75610703
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
This patch introduces the MACsec hardware offloading infrastructure.
The main idea here is to re-use the logic and data structures of the
software MACsec implementation. This allows not to duplicate definitions
and structure storing the same kind of information. It also allows to
use a unified genlink interface for both MACsec implementations (so that
the same userspace tool, `ip macsec`, is used with the same arguments).
The MACsec offloading support cannot be disabled if an interface
supports it at the moment.
The MACsec configuration is passed to device drivers supporting it
through macsec_ops which are called from the MACsec genl helpers. Those
functions call the macsec ops of PHY and Ethernet drivers in two steps:
a preparation one, and a commit one. The first step is allowed to fail
and should be used to check if a provided configuration is compatible
with the features provided by a MACsec engine, while the second step is
not allowed to fail and should only be used to enable a given MACsec
configuration. Two extra calls are made: when a virtual MACsec interface
is created and when it is deleted, so that the hardware driver can stay
in sync.
The Rx and TX handlers are modified to take in account the special case
were the MACsec transformation happens in the hardware, whether in a PHY
or in a MAC, as the packets seen by the networking stack on both the
physical and MACsec virtual interface are exactly the same. This leads
to some limitations: the hardware and software implementations can't be
used on the same physical interface, as the policies would be impossible
to fulfill (such as strict validation of the frames). Also only a single
virtual MACsec interface can be offloaded to a physical port supporting
hardware offloading as it would be impossible to guess onto which
interface a given packet should go (for ingress traffic).
Another limitation as of now is that the counters and statistics are not
reported back from the hardware to the software MACsec implementation.
This isn't an issue when using offloaded MACsec transformations, but it
should be added in the future so that the MACsec state can be reported
to the user (which would also improve the debug).
Change-Id: Ie705609ae0d11797e6f7adb203739958287a419c
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: 3cf3227a21d1fb020fe26128e60321bd2151e922
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[quic_krudrapa@quicinc.com: Fixed Merge conflicts ]
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
This patch adds a reference to MACsec ops in the phy_device, to allow
PHYs to support offloading MACsec operations. The phydev lock will be
held while calling those helpers.
Change-Id: I7076430d419c1ff260380e42f48d6077d673ba3f
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: 2e18135845b359f26c37df38ba56565496517c10
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[quic_krudrapa@quicinc.com: Fixed Merge conflicts ]
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
This patch introduces MACsec ops for drivers to support offloading
MACsec operations.
Change-Id: I860013e7872f19f0611d07dfd9d69284076c45fd
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: 0830e20b62ad156f7df5ff5b9c4cea280ebe8fef
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
This patch introduces the macsec_context structure. It will be used
in the kernel to exchange information between the common MACsec
implementation (macsec.c) and the MACsec hardware offloading
implementations. This structure contains pointers to MACsec specific
structures which contain the actual MACsec configuration, and to the
underlying device (phydev for now).
Change-Id: Ib7d4e6f1667c2f4679e4d51d68671075462237db
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: 76564261a7db80c5f5c624e0122a28787f266bdf
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
This patch moves some structure, type and identifier definitions into a
MACsec specific header. This patch does not modify how the MACsec code
is running and only move things around. This is a preparation for the
future MACsec hardware offloading support, which will re-use those
definitions outside macsec.c.
Change-Id: If052b8bf048951d915ea9def85512adb41b20520
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-commit: c0e4eadfb8daf2e9557c7450f9b237c08b404419
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[quic_krudrapa@quicinc.com: Fixed merge conflicts]
Signed-off-by: Karthik Rudrapatna <quic_krudrapa@quicinc.com>
Currently when dtr high is send by the host, dsr high should be
sent by the device by performing a term io to acm conversion.
But if dtr high is received twice, serial state which is converted
to acm signal is again converted, leading to serial state becoming
null. Fix this by clearing ACM bits from previous conversion before
performing uart to acm conversion.
Change-Id: Iaad3f200599f6bd4224db0c3987420cc022b34ef
Signed-off-by: Rohith Kollalsi <quic_rkollals@quicinc.com>
commit 50252e4b5e989ce64555c7aef7516bdefc2fea72 upstream.
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838c ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 185125206
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I87b4b20981f4283b15d51c48c8e422fcf0612ba8
commit 363bee27e25804d8981dd1c025b4ad49dc39c530 upstream.
Currently, aio_poll_wake() will always remove the poll request from the
waitqueue. Then, if aio_poll_complete_work() sees that none of the
polled events are ready and the request isn't cancelled, it re-adds the
request to the waitqueue. (This can easily happen when polling a file
that doesn't pass an event mask when waking up its waitqueue.)
This is fundamentally broken for two reasons:
1. If a wakeup occurs between vfs_poll() and the request being
re-added to the waitqueue, it will be missed because the request
wasn't on the waitqueue at the time. Therefore, IOCB_CMD_POLL
might never complete even if the polled file is ready.
2. When the request isn't on the waitqueue, there is no way to be
notified that the waitqueue is being freed (which happens when its
lifetime is shorter than the struct file's). This is supposed to
happen via the waitqueue entries being woken up with POLLFREE.
Therefore, leave the requests on the waitqueue until they are actually
completed (or cancelled). To keep track of when aio_poll_complete_work
needs to be scheduled, use new fields in struct poll_iocb. Remove the
'done' field which is now redundant.
Note that this is consistent with how sys_poll() and eventpoll work;
their wakeup functions do *not* remove the waitqueue entries.
Fixes: 2c14fa838c ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 185125206
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib42bf5a65b2e21f15ae3f223f8949719c8ffeea5
commit 9537bae0da1f8d1e2361ab6d0479e8af7824e160 upstream.
wake_up_poll() uses nr_exclusive=1, so it's not guaranteed to wake up
all exclusive waiters. Yet, POLLFREE *must* wake up all waiters. epoll
and aio poll are fortunately not affected by this, but it's very
fragile. Thus, the new function wake_up_pollfree() has been introduced.
Convert signalfd to use wake_up_pollfree().
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes: d80e731eca ("epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree()")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211209010455.42744-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 185125206
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2534cce4e3d5be1b439b01eb8717903e08bb8e65
commit a880b28a71e39013e357fd3adccd1d8a31bc69a8 upstream.
wake_up_poll() uses nr_exclusive=1, so it's not guaranteed to wake up
all exclusive waiters. Yet, POLLFREE *must* wake up all waiters. epoll
and aio poll are fortunately not affected by this, but it's very
fragile. Thus, the new function wake_up_pollfree() has been introduced.
Convert binder to use wake_up_pollfree().
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes: f5cb779ba1 ("ANDROID: binder: remove waitqueue when thread exits.")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211209010455.42744-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 185125206
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0f08d9f9a40348d7d2381607fabe3648416ab2a2
commit 42288cb44c4b5fff7653bc392b583a2b8bd6a8c0 upstream.
Several ->poll() implementations are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, using 'wake_up_poll(wq, EPOLLHUP | POLLFREE);'.
However, that has a bug: wake_up_poll() calls __wake_up() with
nr_exclusive=1. Therefore, if there are multiple "exclusive" waiters,
and the wakeup function for the first one returns a positive value, only
that one will be called. That's *not* what's needed for POLLFREE;
POLLFREE is special in that it really needs to wake up everyone.
Considering the three non-blocking poll systems:
- io_uring poll doesn't handle POLLFREE at all, so it is broken anyway.
- aio poll is unaffected, since it doesn't support exclusive waits.
However, that's fragile, as someone could add this feature later.
- epoll doesn't appear to be broken by this, since its wakeup function
returns 0 when it sees POLLFREE. But this is fragile.
Although there is a workaround (see epoll), it's better to define a
function which always sends POLLFREE to all waiters. Add such a
function. Also make it verify that the queue really becomes empty after
all waiters have been woken up.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211209010455.42744-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 185125206
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1ec70169a39be42640172af512f4b47827ef5569
Under some conditions, USB gadget devices can show allocated buffer
contents to a host. Fix this up by zero-allocating them so that any
extra data will all just be zeros.
Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com>
Tested-by: Szymon Heidrich <szymon.heidrich@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 86ebbc11bb3f60908a51f3e41a17e3f477c2eaa3)
Bug: 210292367
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I72b4376cd4296a8b8af0ade2d702cd420146f3aa
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Sometimes USB hosts can ask for buffers that are too large from endpoint
0, which should not be allowed. If this happens for OUT requests, stall
the endpoint, but for IN requests, trim the request size to the endpoint
buffer size.
Co-developed-by: Szymon Heidrich <szymon.heidrich@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 153a2d7e3350cc89d406ba2d35be8793a64c2038)
Bug: 210292367
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9bbd6154177d7a1fb6c2e3a3dffa96634d85bb7f
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Many HID drivers assume that the HID device assigned to them is a USB
device as that was the only way HID devices used to be able to be
created in Linux. However, with the additional ways that HID devices
can be created for many different bus types, that is no longer true, so
properly check that we have a USB device associated with the HID device
before allowing a driver that makes this assumption to claim it.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Michael Zaidman <michael.zaidman@gmail.com>
Cc: Stefan Achatz <erazor_de@users.sourceforge.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-input@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[bentiss: amended for thrustmater.c hunk to apply]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211201183503.2373082-3-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 93020953d0fa7035fd036ad87a47ae2b7aa4ae33)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7908d6af9e70865a6db17fac75624064165449ad
The wacom driver accepts devices of more than just USB types, but some
code paths can cause problems if the device being controlled is not a
USB device due to a lack of checking. Add the needed checks to ensure
that the USB device accesses are only happening on a "real" USB device,
and not one on some other bus.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Cc: stable@vger.kernel.org
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211201183503.2373082-2-gregkh@linuxfoundation.org
(cherry picked from commit 720ac467204a70308bd687927ed475afb904e11b)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I605a7a3598b54693ce2104d4afdbdf879bb7fb2e
When emulating the device through uhid, there is a chance we don't have
output reports and so report_field is null.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211202095334.14399-3-benjamin.tissoires@redhat.com
(cherry picked from commit 918aa1ef104d286d16b9e7ef139a463ac7a296f0)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia6fb77a7bd9426ce055e090fb2c1f3a21a2011cc
commit f237d9028f844a86955fc9da59d7ac4a5c55d7d5 upstream.
Some HID drivers are only for USB drivers, yet did not depend on
CONFIG_USB_HID. This was hidden by the fact that the USB functions were
stubbed out in the past, but now that drivers are checking for USB
devices properly, build errors can occur with some random
configurations.
Reported-by: kernel test robot <lkp@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211202114819.2511954-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f237d9028f844a86955fc9da59d7ac4a5c55d7d5)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia755dc2803f1111c33d1c4b06b02913eebdf34c0
The chicony HID driver only controls USB devices, yet did not have a
dependancy on USB_HID. This causes build errors on some configurations
like sparc when building due to new changes to the chicony driver.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: stable@vger.kernel.org
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211203075927.2829218-1-gregkh@linuxfoundation.org
(cherry picked from commit d080811f27936f712f619f847389f403ac873b8f)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic65d7879192eb876683d13eb18628dd0f4594e98
The prodikeys HID driver only controls USB devices, yet did not have a
dependancy on USB_HID. This causes build errors on some configurations
like nios2 when building due to new changes to the prodikeys driver.
Reported-by: kernel test robot <lkp@intel.com>
Cc: stable@vger.kernel.org
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211203081231.2856936-1-gregkh@linuxfoundation.org
(cherry picked from commit 30cb3c2ad24b66fb7639a6d1f4390c74d6e68f94)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifbff6c7522a684fab6974565570a92e61651ae0a
A number of HID drivers already call hid_is_using_ll_driver() but only
for the detection of if this is a USB device or not. Make this more
obvious by creating hid_is_usb() and calling the function that way.
Also converts the existing hid_is_using_ll_driver() functions to use the
new call.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Cc: stable@vger.kernel.org
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211201183503.2373082-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f83baa0cb6cfc92ebaf7f9d3a99d7e34f2e77a8a)
Bug: 188677105
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibfa4252d4b6501a09a997bb9efbab46fae3fd1dc
Perform ep config space dword read and write using 16-bit BDF,
offset and value to write as input.
To perform config space read for vendor and device id for BDF
0x200
echo 0x200 0x0 > config_dwrod_read
To perform config space write on status and control offset with
write value 0x400 for BDF 0x200
echo 0x200 0x4 0x400 > config_dword_write
Usage information is provided by reading config_dword_read and
config_dword_write.
Change-Id: Ia733b7102bb5961e7ab3b27d4438460e52a51c57
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
There is a requirement to scale both CX and GX rails during the gpu core
clock scaling, thus add the corresponding vdd data.
Change-Id: Ib27f4697a84ece1d0d1ce2b5297c03bf8ed955c6
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
There is no need to keep around the debugfs "root" directory for the
dwc3 device. Instead, look it up anytime we need to find it. This will
help when callers get out-of-order and we had the potential to have a
"stale" pointer around for the root dentry, as has happened in the past.
Change-Id: I7fd1973704cd2a9e193fd77e01f7e09236f41117
Tested-by: Jack Pham <jackp@codeaurora.org>
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/20210609093924.3293230-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 8562d5bfc0fcdfd3aef32991e17dca585ae5ae7d
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[quic_ppratap@quicinc.com: resolved trivial merge conflicts]
Signed-off-by: Pratham Pratap <quic_ppratap@quicinc.com>
If the net dev init process is scheduled out in between registering
a callback for in-channel and out-channel and start command for these
channels gets processed at this time (after registering the callback
for out channel but before registeringthe callback for in-channel)
then with existing logic, we never register with the network interface.
Checking the out channel status directly rather than using local bool
variable out_channel_started before calling
mhi_dev_net_open_chan_create_netif API. If out channel status is
connected the mhi_dev_net_open_chan_create_netif API is called.
Change-Id: I69af6c49ee565ffd04c4d0ac22b686ff986b7bc7
Signed-off-by: Sai Chaitanya Kaveti <quic_skaveti@quicinc.com>
M0 (mhi resume) processing and doorbell interrupt processing are done
in different contexts. And there can be a chance that DB processing
can proceed even before the resume is completely done.
Say while processing M0, MHI has issued M0-ack but not updated channel
state to running state for *all* channels yet. The host can start ringing
DB the moment it sees M0-ack and it's the channel is in running state.
To avoid this race condition, ensure MHI doesn't process any CHDB
interrupt until it's completely done with the resume.
Change-Id: Ie8f7fec034be6b17c71e3b7437ab8e6effb63365
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
If there is page fault only for read case on inline inode, we don't need
to convert inline inode, instead, let's do conversion for write case.
Bug: 208371174
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 58c3b33eb9f1)
Change-Id: I68168bc08a77d8d8f039189d44d23f83a7eda1f5
Given RO feature in superblock, we don't need to check provisioning/reserve
spaces and SSA area.
Bug: 208371174
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 60bad8157831)
Change-Id: I2ec5fda15948bb17bd34b3b1c3efc356f527b515
Meta area is not included in section_count computation.
So the minimum number of total_sections is 1 meanwhile it cannot be
greater than segment_count_main.
The minimum number of meta segments is 8 (SB + 2 (CP + SIT + NAT) + SSA).
Bug: 208371174
Signed-off-by: Wang Xiaojun <wangxiaojun11@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 56faf97ebce8)
Change-Id: I36a97300e13bd760c29958bc36d85b441dd40eaa
Currently there is a chance that release for the fence was already called
before we call dma_fence_get during kgsl_timeline_signal and
kgsl_ioctl_timeline_destroy. This can cause use-after-free issue as we can
access fence after release. Fix this by signalling fence only if the last
refcount on the fence was not yet put. This makes sure that release for the
fence will not be called until we are done signalling.
Change-Id: I6bdcefa1f128febb7a0f7aef133757268a3b9ae3
Signed-off-by: Puranam V G Tejaswi <quic_pvgtejas@quicinc.com>
In ETR sg buff mode, at most 4K data can be obtained
at a time. This change to support this mode.
Change-Id: I26da71e7210f0a85dbd969c6ff047598a1cbddcd
Signed-off-by: Yuanfang Zhang <quic_yuanfang@quicinc.com>
