Re: Adding ABI to htmldocs - Was: Re: [PATCH 2/2] w1: w1_therm: Add support for GXCAS GX20MH01 device.
Em Wed, 21 Oct 2020 18:58:19 +0200 Greg Kroah-Hartman escreveu: > On Wed, Oct 21, 2020 at 06:28:43PM +0200, Mauro Carvalho Chehab wrote: > > Hi greg, > > > > Em Wed, 7 Oct 2020 13:59:34 +0200 > > Mauro Carvalho Chehab escreveu: > > > > > Em Wed, 7 Oct 2020 13:43:59 +0200 > > > Greg Kroah-Hartman escreveu: > > > > > > > On Wed, Oct 07, 2020 at 01:05:49PM +0200, Mauro Carvalho Chehab wrote: > > > > > Em Wed, 7 Oct 2020 11:06:19 +0200 > > > > > Greg Kroah-Hartman escreveu: > > > > > > > > > > > On Wed, Oct 07, 2020 at 10:57:02AM +0200, Mauro Carvalho Chehab > > > > > > wrote: > > > > > > > Em Wed, 7 Oct 2020 10:32:27 +0300 > > > > > > > Ivan Zaentsev escreveu: > > > > > > > > > > > > > > > Tuesday, October 6, 2020, 4:19:15 PM, Mauro Carvalho Chehab > > > > > > > > wrote: > > > > > > > > > > > > > > > > >> diff --git a/Documentation/w1/slaves/w1_therm.rst > > > > > > > > >> b/Documentation/w1/slaves/w1_therm.rst > > > > > > > > >> index f1148181f53e..00376501a5ef 100644 > > > > > > > > >> --- a/Documentation/w1/slaves/w1_therm.rst > > > > > > > > >> +++ b/Documentation/w1/slaves/w1_therm.rst > > > > > > > > > > > > > > > > >> > > > > > > > > >> @@ -130,4 +131,12 @@ conversion and temperature reads 85.00 > > > > > > > > >> (powerup value) or 127.94 (insufficient > > > > > > > > >> power), the driver returns a conversion error. Bit mask > > > > > > > > >> ``2`` enables poll for > > > > > > > > >> conversion completion (normal power only) by generating > > > > > > > > >> read cycles on the bus > > > > > > > > >> after conversion starts. In parasite power mode this > > > > > > > > >> feature is not available. > > > > > > > > >> -Feature bit masks may be combined (OR). > > > > > > > > >> +Feature bit masks may be combined (OR). See accompanying > > > > > > > > >> sysfs documentation: > > > > > > > > >> +:ref:`Documentation/w1/slaves/w1_therm.rst ` > > > > > > > > >> + > > > > > > > > > > > > > > > > > As warned by Sphinx, this cross-reference is broken: > > > > > > > > > > > > > > > > > .../Documentation/w1/slaves/w1_therm.rst:125: WARNING: > > > > > > > > > undefined label: w1_therm (if the link has no caption the > > > > > > > > > label must precede a section header) > > > > > > > > > > > > > > > > Would this be ok? > > > > > > > > > > > > > > Yeah, sure! > > > > > > > > > > > > > > > > > > > > > > > "More details in > > > > > > > > Documentation/ABI/testing/sysfs-driver-w1_therm" > > > > > > > > > > > > > > > > > Not sure what you wanted to point here. > > > > > > > > > > > > > > > > A link to a driver's sysfs interface, but sysfs docs are text > > > > > > > > files and seem to not be included in Sphynx Docs. > > > > > > > > > > > > > > I sent upstream sometime ago a patch series adding ABI to Sphinx, > > > > > > > but I > > > > > > > was not merged, not sure why: > > > > > > > > > > > > > > > > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=abi_patches_v5.6 > > > > > > > > > > > > > > > > > > > I think the raft of different patches floating around at the time > > > > > > made > > > > > > me totally confused as to what was, and was not, the latest > > > > > > versions. > > > > > > > > > > Yeah, there were lots of patches floating around that time. > > > > > > > > > > I also recall that someone (Jeni?) asked if the best wouldn't be to > > > > > just convert the ABI files to ReST directly. > > > > > > > > > > > I'll be glad to look at them again, if you want to rebase after > > > > > > 5.10-rc1 > > > > > > is out and resend them, as I think this should be showing up in the > > > > > > documentation. > > > > > > > > > > Surely. I'll rebase them after 5.10-rc1 and re-submit. > > > > > > > > > > What strategy do you prefer? Keep the files with the same format as > > > > > today (allowing them to optionally have ReST markups) or to convert > > > > > them to .rst directly? > > > > > > > > > > In the latter case, the best would be to apply it as early as possible > > > > > after 5.10-rc1, as it may cause conflicts with other patches being > > > > > submitted for 5.11. > > > > > > > > The existing format if at all possible, doing wholesale changes is a > > > > mess and wouldn't be recommended. > > > > > > Yeah, merging it would indeed be a mess. At long term, though, it could > > > be easier to maintain. > > > > > > > I think you already fixed up the entries that had problems being parsed > > > > in the past, if not, we can resolve those as well. > > > > > > Yes. The series start with fixes. I suspect several of them > > > (if not all) were already merged, but if anything is missing, I can fix > > > at the upcoming rebased series. > > > > Rebasing the patch series was easier than what I expected: > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=abi_patches_v6 > > > > Yet, while fixing
RE: [PATCH v2 6/6] crypto: lib/sha - Combine round constants and message schedule
From: Eric Biggers
> Sent: 22 October 2020 05:35
>
> On Tue, Oct 20, 2020 at 04:39:57PM -0400, Arvind Sankar wrote:
> > Putting the round constants and the message schedule arrays together in
> > one structure saves one register, which can be a significant benefit on
> > register-constrained architectures. On x86-32 (tested on Broadwell
> > Xeon), this gives a 10% performance benefit.
> >
> > Signed-off-by: Arvind Sankar
> > Suggested-by: David Laight
> > ---
> > lib/crypto/sha256.c | 49 ++---
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
> > index 3a8802d5f747..985cd0560d79 100644
> > --- a/lib/crypto/sha256.c
> > +++ b/lib/crypto/sha256.c
> > @@ -29,6 +29,11 @@ static const u32 SHA256_K[] = {
> > 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb,
> > 0xbef9a3f7, 0xc67178f2,
> > };
> >
> > +struct KW {
> > + u32 K[64];
> > + u32 W[64];
> > +};
>
> Note that this doubles the stack usage from 256 to 512 bytes. That's pretty
> large for kernel code, especially when compiler options can increase the stack
> usage well beyond the "expected" value.
>
> So unless this gives a big performance improvement on architectures other than
> 32-bit x86 (which people don't really care about these days), we probably
> shouldn't do this.
IIRC the gain came from an odd side effect - which can probably
be got (for some compiler versions) by other means.
> FWIW, it's possible to reduce the length of 'W' to 16 words by computing the
> next W value just before each round 16-63,
I was looking at that.
You'd need to do the first 16 rounds then rounds 17-63 in a second
loop to avoid the conditional.
The problem is that it needs too many registers.
You'd need registers for 16 W values, the 8 a-h and a few spare.
...
Looking closely each round is like:
t1 = h + e1(e) + Ch(e, f, g) + 0x428a2f98 + W[0];
t2 = e0(a) + Maj(a, b, c);
h = t1 + t2; // Not used for a few rounds
d += t1; // Needed next round
So only needs 4 of the state variables (e, f, g, h).
The next round uses d, e, f and g.
So with extreme care d and h can use the same register.
Although I'm not sure how you'd get the compiler to do it.
Possibly making state[] volatile (or using READ/WRITE_ONCE).
So the last two lines become:
state[7] = t1 + t2;
d = state[3] + t1;
That might stop the x86 (32bit) spilling registers.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
[PATCH v8 0/4] userspace MHI client interface driver
This patch series adds support for UCI driver. UCI driver enables userspace clients to communicate to external MHI devices like modem and WLAN. UCI driver probe creates standard character device file nodes for userspace clients to perform open, read, write, poll and release file operations. These file operations call MHI core layer APIs to perform data transfer using MHI bus to communicate with MHI device. Patch is tested using arm64 based platform. V8: - Fixed kernel test robot compilation error by changing %lu to %zu for size_t. - Replaced uci with UCI in Kconfig, commit text, and comments in driver code. - Fixed minor style related comments. V7: - Decoupled uci device and uci channel objects. uci device is associated with device file node. uci channel is associated with MHI channels. uci device refers to uci channel to perform MHI channel operations for device file operations like read() and write(). uci device increments its reference count for every open(). uci device calls mhi_uci_dev_start_chan() to start the MHI channel. uci channel object is tracking number of times MHI channel is referred. This allows to keep the MHI channel in start state until last release() is called. After that uci channel reference count goes to 0 and uci channel clean up is performed which stops the MHI channel. After the last call to release() if driver is removed uci reference count becomes 0 and uci object is cleaned up. - Use separate uci channel read and write lock to fine grain locking between reader and writer. - Use uci device lock to synchronize open, release and driver remove. - Optimize for downlink only or uplink only UCI device. V6: - Moved uci.c to mhi directory. - Updated Kconfig to add module information. - Updated Makefile to rename uci object file name as mhi_uci - Removed kref for open count V5: - Removed mhi_uci_drv structure. - Used idr instead of creating global list of uci devices. - Used kref instead of local ref counting for uci device and open count. - Removed unlikely macro. V4: - Fix locking to protect proper struct members. - Updated documentation describing uci client driver use cases. - Fixed uci ref counting in mhi_uci_open for error case. - Addressed style related review comments. V3: Added documentation for MHI UCI driver. V2: Added mutex lock to prevent multiple readers to access same mhi buffer which can result into use after free. Hemant Kumar (4): bus: mhi: core: Add helper API to return number of free TREs bus: mhi: core: Move MHI_MAX_MTU to external header file docs: Add documentation for userspace client interface bus: mhi: Add userspace client interface driver Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 83 + drivers/bus/mhi/Kconfig | 13 + drivers/bus/mhi/Makefile| 4 + drivers/bus/mhi/core/internal.h | 1 - drivers/bus/mhi/core/main.c | 12 + drivers/bus/mhi/uci.c | 657 include/linux/mhi.h | 12 + 8 files changed, 782 insertions(+), 1 deletion(-) create mode 100644 Documentation/mhi/uci.rst create mode 100644 drivers/bus/mhi/uci.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v8 2/4] bus: mhi: core: Move MHI_MAX_MTU to external header file
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 7989269..4abf0cf 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
#define CMD_EL_PER_RING128
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
-#define MHI_MAX_MTU0x
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 7829b1d..6e1122c 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
#include
#include
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0x
+
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
struct mhi_chan;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v8 1/4] bus: mhi: core: Add helper API to return number of free TREs
Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/main.c | 12
include/linux/mhi.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 2cff5dd..3950792 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -258,6 +258,18 @@ int mhi_destroy_device(struct device *dev, void *data)
return 0;
}
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir)
+{
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+ struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
+ mhi_dev->ul_chan : mhi_dev->dl_chan;
+ struct mhi_ring *tre_ring = _chan->tre_ring;
+
+ return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
+}
+EXPORT_SYMBOL_GPL(mhi_get_free_desc_count);
+
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
{
struct mhi_driver *mhi_drv;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d4841e5..7829b1d 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -597,6 +597,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
/**
+ * mhi_get_free_desc_count - Get transfer ring length
+ * Get # of TD available to queue buffers
+ * @mhi_dev: Device associated with the channels
+ * @dir: Direction of the channel
+ */
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir);
+
+/**
* mhi_prepare_for_power_up - Do pre-initialization before power up.
*This is optional, call this before power up if
*the controller does not want bus framework to
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v8 4/4] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/mhi__
Currently it supports LOOPBACK channel.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 4 +
drivers/bus/mhi/uci.c| 657 +++
3 files changed, 674 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index e841c10..476cc55 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,16 @@ config MHI_BUS_DEBUG
Enable debugfs support for use with the MHI transport. Allows
reading and/or modifying some values within the MHI controller
for debug and test purposes.
+
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, and close operations
+ are supported by this driver. Please check mhi_uci_match_table for
+ all supported channels that are exposed to userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..80feefb 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,6 @@
# core layer
obj-y += core/
+
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..472bd63
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,657 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_lock: spin lock
+ * @pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending and cur_buf members in bh context, channel release,
+* read and poll
+*/
+ spinlock_t dl_lock;
+
+ struct list_head pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+ struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+ struct uci_buf *buf_itr, *tmp;
+ struct uci_chan *uchan =
+ container_of(ref, struct uci_chan, ref_count);
+
+ if (uchan->udev->enabled)
+ mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
+ spin_lock_bh(>dl_lock);
+
[PATCH v8 3/4] docs: Add documentation for userspace client interface
MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently Loopback MHI channel is supported by this driver. Signed-off-by: Hemant Kumar --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 83 + 2 files changed, 84 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..fe901c4 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Userspace Client Interface (UCI) += + +UCI driver enables userspace clients to communicate to external MHI devices +like modem and WLAN. UCI driver probe creates standard character device file +nodes for userspace clients to perform open, read, write, poll and release file +operations. + +Operations +== + +open + + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read + + +When data transfer is completed on downlink channel, TRE buffer is copied to +pending list. Reader is unblocked and data is copied to userspace buffer. TRE +buffer is queued back to downlink channel transfer ring. + +write +- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll + + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. Returns EPOLLERR when UCI driver is removed. MHI channels +move to disabled state upon driver remove. + +release +--- + +Decrements UCI device reference count and UCI channel reference count upon last +release(). UCI channel clean up is performed. MHI channel moves to disabled +state and inbound buffers are freed. + +Usage += + +Device file node is created with format:- + +/dev/mhi__ + +controller_name is the name of underlying bus used to transfer data. mhi_device +name is the name of the MHI channel being used by MHI client in userspace to +send or receive data using MHI protocol. + +There is a separate character device file node created for each channel +specified in mhi device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +LOOPBACK Channel + + +Userspace MHI client using LOOPBACK channel opens device file node. As part of +open operation TREs to transfer ring of LOOPBACK channel 1 gets queued and channel +doorbell is rung. When userspace MHI client performs write operation on device node, +data buffer gets queued as a TRE to transfer ring of LOOPBACK channel 0. MHI Core +driver rings the channel doorbell for MHI device to move data over underlying bus. +When userspace MHI client driver performs read operation, same data gets looped back +to MHI host using LOOPBACK channel 1. LOOPBACK channel is used to verify data path +and data integrity between MHI Host and MHI device. + +Other Use Cases +--- + +Getting MHI device specific diagnostics information to userspace MHI diag client +using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
* Topi Miettinen: >> The dynamic loader has to process the LOAD segments to get to the ELF >> note that says to enable BTI. Maybe we could do a first pass and >> load only the segments that cover notes. But that requires lots of >> changes to generic code in the loader. > > What if the loader always enabled BTI for PROT_EXEC pages, but then > when discovering that this was a mistake, mprotect() the pages without > BTI? Is that architecturally supported? How costly is the mprotect change if the pages have not been faulted in yet? > Then both BTI and MDWX would work and the penalty of not getting > MDWX would fall to non-BTI programs. What's the expected proportion of > BTI enabled code vs. disabled in the future, is it perhaps expected > that a distro would enable the flag globally so eventually only a few > legacy programs might be unprotected? Eventually, I expect that mainstream distributions build everything for BTI, so yes, the PROT_BTI removal would only be needed for legacy programs. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
RE: [PATCH v5 0/5] Add r8a77965 DRIF support
Hi Laurent, > From: Laurent Pinchart > Sent: 21 October 2020 22:43 > Subject: Re: [PATCH v5 0/5] Add r8a77965 DRIF support > > Hi Fabrizio, > > On Wed, Oct 21, 2020 at 02:53:27PM +0100, Fabrizio Castro wrote: > > Dear All, > > > > this series is to add DRIF support for the r8a77965 > > (a.k.a. R-Car M3-N). Version 5 fixes a warning reported > > by 'make dt_binding_check', as reported by Rob. > > Patch 1/5 to 4/5 taken in my tree, I'll send a pull request to > linux-media when the merge window closes. I expect Geert to handle 5/5. Great, thank you. Fab > > > Fabrizio Castro (5): > > MAINTAINERS: Update MAINTAINERS for Renesas DRIF driver > > media: dt-bindings: media: renesas,drif: Convert to json-schema > > media: dt-bindings: media: renesas,drif: Add r8a77990 support > > media: dt-bindings: media: renesas,drif: Add r8a77965 support > > arm64: dts: r8a77965: Add DRIF support > > > > .../bindings/media/renesas,drif.txt | 177 --- > > .../bindings/media/renesas,drif.yaml | 279 ++ > > MAINTAINERS | 4 +- > > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 120 > > 4 files changed, 401 insertions(+), 179 deletions(-) > > delete mode 100644 > Documentation/devicetree/bindings/media/renesas,drif.txt > > create mode 100644 > Documentation/devicetree/bindings/media/renesas,drif.yaml > > -- > Regards, > > Laurent Pinchart
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: > On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > > On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > > > From: David Laight > > > > > > This lets the compiler inline it into import_iovec() generating > > > much better code. > > > > > > Signed-off-by: David Laight > > > Signed-off-by: Christoph Hellwig > > > --- > > > fs/read_write.c | 179 > > > lib/iov_iter.c | 176 +++ > > > 2 files changed, 176 insertions(+), 179 deletions(-) > > > > Strangely, this commit causes a regression in Linus's tree right now. > > > > I can't really figure out what the regression is, only that this commit > > triggers a "large Android system binary" from working properly. There's > > no kernel log messages anywhere, and I don't have any way to strace the > > thing in the testing framework, so any hints that people can provide > > would be most appreciated. > > It's a pure move - modulo changed line breaks in the argument lists > the functions involved are identical before and after that (just checked > that directly, by checking out the trees before and after, extracting two > functions in question from fs/read_write.c and lib/iov_iter.c (before and > after, resp.) and checking the diff between those. > > How certain is your bisection? The bisection is very reproducable. But, this looks now to be a compiler bug. I'm using the latest version of clang and if I put "noinline" at the front of the function, everything works. Nick, any ideas here as to who I should report this to? I'll work on a fixup patch for the Android kernel tree to see if I can work around it there, but others will hit this in Linus's tree sooner or later... thanks, greg k-h
Re: [PATCH 3/5] xen/events: only register debug interrupt for 2-level events
On 22.10.20 09:54, Jan Beulich wrote:
On 22.10.2020 09:42, Juergen Gross wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
static inline void xen_alloc_callback_vector(void) {}
#endif
-static bool fifo_events = true;
+bool fifo_events = true;
When making this non-static, perhaps better to also prefix it with
xen_?
Fine with me.
Juergen
Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
On Wed, Oct 21 2020 at 17:02, Jakub Kicinski wrote: > On Wed, 21 Oct 2020 22:25:48 +0200 Thomas Gleixner wrote: >> The right answer to this is to utilize managed interrupts and have >> according logic in your network driver to handle CPU hotplug. When a CPU >> goes down, then the queue which is associated to that CPU is quiesced >> and the interrupt core shuts down the relevant interrupt instead of >> moving it to an online CPU (which causes the whole vector exhaustion >> problem on x86). When the CPU comes online again, then the interrupt is >> reenabled in the core and the driver reactivates the queue. > > I think Mellanox folks made some forays into managed irqs, but I don't > remember/can't find the details now. > > For networking the locality / queue per core does not always work, > since the incoming traffic is usually spread based on a hash. Many That makes it problematic and is fundamentally different from block I/O. > applications perform better when network processing is done on a small > subset of CPUs, and application doesn't get interrupted every 100us. > So we do need extra user control here. Ok. > We have a bit of a uAPI problem since people had grown to depend on > IRQ == queue == NAPI to configure their systems. "The right way" out > would be a proper API which allows associating queues with CPUs rather > than IRQs, then we can use managed IRQs and solve many other problems. > > Such new API has been in the works / discussions for a while now. If there is anything which needs to be done/extended on the irq side please let me know. Thanks tglx
Re: [PATCH 4/5] xen/events: unmask a fifo event channel only if it was masked
On 22.10.20 09:55, Jan Beulich wrote:
On 22.10.2020 09:42, Juergen Gross wrote:
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
w = *word;
+ if (!(w & (1 << EVTCHN_FIFO_MASKED)))
+ return true;
Maybe better move this ...
do {
if (w & (1 << EVTCHN_FIFO_PENDING))
return false;
... into the loop, above this check?
Yes, that should be better.
Juergen
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote: > On 22.10.2020 10.54, Florian Weimer wrote: > > * Lennart Poettering: > > > Did you see Topi's comments on the systemd issue? > > > > > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > > > > > I think I agree with this: it's a bit weird to alter the bits after > > > the fact. Can't glibc set up everything right from the begining? That > > > would keep both concepts working. > > > > The dynamic loader has to process the LOAD segments to get to the ELF > > note that says to enable BTI. Maybe we could do a first pass and load > > only the segments that cover notes. But that requires lots of changes > > to generic code in the loader. > > What if the loader always enabled BTI for PROT_EXEC pages, but then when > discovering that this was a mistake, mprotect() the pages without BTI? Then > both BTI and MDWX would work and the penalty of not getting MDWX would fall > to non-BTI programs. What's the expected proportion of BTI enabled code vs. > disabled in the future, is it perhaps expected that a distro would enable > the flag globally so eventually only a few legacy programs might be > unprotected? i thought mprotect(PROT_EXEC) would get filtered with or without bti, is that not the case? then i guess we can do the protection that way around, but then i don't see why the filter cannot treat PROT_EXEC|PROT_BTI the same as PROT_EXEC.
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On Do, 22.10.20 09:05, Szabolcs Nagy (szabolcs.n...@arm.com) wrote: > > > Various changes have been suggested, replacing the mprotect with mmap > > > calls > > > having PROT_BTI set on the original mapping, re-mmapping the segments, > > > implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set, > > > and various modification to seccomp to allow particular mprotect cases to > > > bypass the filters. In each case there seems to be an undesirable > > > attribute > > > to the solution. > > > > > > So, whats the best solution? > > > > Did you see Topi's comments on the systemd issue? > > > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > > > I think I agree with this: it's a bit weird to alter the bits after > > the fact. Can't glibc set up everything right from the begining? That > > would keep both concepts working. > > that's hard to do and does not work for the main exe currently > (which is mmaped by the kernel). > > (it's hard to do because to know that the elf module requires > bti the PT_GNU_PROPERTY notes have to be accessed that are > often in the executable load segment, so either you mmap that > or have to read that, but the latter has a lot more failure > modes, so if i have to get the mmap flags right i'd do a mmap > and then re-mmap if the flags were not right) Only other option I then see is to neuter one of the two mechanisms. We could certainly turn off MDWE on arm in systemd, if people want that. Or make it a build-time choice, so that distros make the choice: build everything with BTI xor suppport MDWE. (Might make sense for glibc to gracefully fallback to non-BTI mode if the mprotect() fails though, to make sure BTI-built binaries work everywhere.) I figure your interest in ARM system security is bigger than mine. I am totally fine to turn off MDWE on ARM if that's what the Linux ARM folks want. I ave no horse in the race. Just let me know. [An acceptable compromise might be to allow mprotect(PROT_EXEC|PROT_BTI) if MDWE is on, but prohibit mprotect(PROT_EXEC) without PROT_BTI. Then at least you get one of the two protections, but not both. I mean, MDWE is not perfect anyway on non-x86-64 already: on 32bit i386 MDWE protection is not complete, due to ipc() syscall multiplexing being unmatchable with seccomp. I personally am happy as long as it works fully on x86-64] Lennart -- Lennart Poettering, Berlin
Re: [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util()
Hi Peter, Since Lukasz asked me to hold on to this stuff so he can propose something in its place, I stayed away from discussing this patchset for sometime. But now that he agrees [1] that we may take this forward and he can work on top of it as and when he can, I am looking to find the way out to get this stuff merged in some form. On 16-07-20, 13:56, Peter Zijlstra wrote: > So there's a number of things... let me recap a bunch of things that > got mentioned on IRC earlier this week and then continue from there.. > > So IPA* (or any other thermal governor) needs energy estimates for the > various managed devices, cpufreq_cooling, being the driver for the CPU > device, needs to provide that and in return receives feedback on how > much energy it is allowed to consume, cpufreq_cooling then dynamically > enables/disables OPP states. > > There are actually two methods the thermal governor will use: > get_real_power() and get_requested_power(). > > The first isn't used anywhere in mainline, but could be implemented on > hardware that has energy counters (like say x86 RAPL). > > The second attempts to guesstimate power, and is the subject of this > patch. > > Currently cpufreq_cooling appears to estimate the CPU energy usage by > calculating the percentage of idle time using the per-cpu cpustat stuff, > which is pretty horrific. > > This patch then attempts to improve upon that by using the scheduler's > cpu_util(ENERGY_UTIL) estimate, which is also used to select OPP state > and improves upon avg idle. This should be a big improvement as higher > frequency consumes more energy Exactly and that's the motivation behind this change. > , but should we not also consider that: > > E = C V^2 f > > The EAS energy model has tables for the OPPs that contain this, but in > this case we seem to be assuming a linear enery/frequency curve, which > is just not the case. > > I suppose we could do something like **: > > 100 * util^3 / max^3 > > which assumes V~f. > > Another point is that cpu_util() vs turbo is a bit iffy, and to that, > things like x86-APERF/MPERF and ARM-AMU got mentioned. Those might also > have the benefit of giving you values that match your own sampling > interval (100ms), where the sched stuff is PELT (64,32.. based). I believe the above stuff is more around additional improvements that we can do over this change, and probably Lukasz was looking to do that. > So what I've been thinking is that cpufreq drivers ought to be able to > supply this method, and only when they lack, can the cpufreq-governor > (schedutil) install a fallback. One of the issues I see with this is that schedutil may not be available in all configurations and it is still absolutely fine to using the suggested helper to get the energy numbers in such cases, so we shouldn't really make it scheutil dependent. > And then cpufreq-cooling can use > whatever is provided (through the cpufreq interfaces). > > That way, we: > > 1) don't have to export anything Yeah, I understand that the exports are annoying and specially this line :) +#include "../../kernel/sched/sched.h" But this is the best I could think of then as we don't want to export them for anyone else to use sched specific stuff. And there was other core kernel stuff that was already doing it :) > 2) get arch drivers to provide something 'better' > > > Does that sounds like something sensible? -- viresh [1] http://lore.kernel.org/lkml/d2a75b18-1eae-f396-4dc5-af41b539e...@arm.com
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On 22.10.20 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: From: David Laight This lets the compiler inline it into import_iovec() generating much better code. Signed-off-by: David Laight Signed-off-by: Christoph Hellwig --- fs/read_write.c | 179 lib/iov_iter.c | 176 +++ 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. -- Thanks, David / dhildenb
[PATCH] selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic
The eeh-basic test got its own 60 seconds timeout (defined in commit 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable device. And we have discovered that the number of breakable devices varies on different hardware. The device recovery time ranges from 0 to 35 seconds. In our test pool it will take about 30 seconds to run on a Power8 system that with 5 breakable devices, 60 seconds to run on a Power9 system that with 4 breakable devices. Thus it's better to disable the default 45 seconds timeout setting in the kselftest framework to give it a chance to finish. And let the test to take care of the timeout control. Signed-off-by: Po-Hsu Lin --- tools/testing/selftests/powerpc/eeh/Makefile | 2 +- tools/testing/selftests/powerpc/eeh/settings | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/powerpc/eeh/settings diff --git a/tools/testing/selftests/powerpc/eeh/Makefile b/tools/testing/selftests/powerpc/eeh/Makefile index b397bab..ae963eb 100644 --- a/tools/testing/selftests/powerpc/eeh/Makefile +++ b/tools/testing/selftests/powerpc/eeh/Makefile @@ -3,7 +3,7 @@ noarg: $(MAKE) -C ../ TEST_PROGS := eeh-basic.sh -TEST_FILES := eeh-functions.sh +TEST_FILES := eeh-functions.sh settings top_srcdir = ../../../../.. include ../../lib.mk diff --git a/tools/testing/selftests/powerpc/eeh/settings b/tools/testing/selftests/powerpc/eeh/settings new file mode 100644 index 000..e7b9417 --- /dev/null +++ b/tools/testing/selftests/powerpc/eeh/settings @@ -0,0 +1 @@ +timeout=0 -- 2.7.4
Re: [PATCH v2 1/2] cifs: convert to add_to_page_cache()
you can add my reviewed-by if you would like
On Thu, Oct 22, 2020 at 1:48 AM Kent Overstreet
wrote:
>
> This is just open coding add_to_page_cache(), and the next patch will
> delete add_to_page_cache_locked().
>
> Signed-off-by: Kent Overstreet
> ---
> fs/cifs/file.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index be46fab4c9..b3ee790532 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -4296,20 +4296,11 @@ readpages_get_pages(struct address_space *mapping,
> struct list_head *page_list,
>
> page = lru_to_page(page_list);
>
> - /*
> -* Lock the page and put it in the cache. Since no one else
> -* should have access to this page, we're safe to simply set
> -* PG_locked without checking it first.
> -*/
> - __SetPageLocked(page);
> - rc = add_to_page_cache_locked(page, mapping,
> - page->index, gfp);
> + rc = add_to_page_cache(page, mapping, page->index, gfp);
>
> /* give up if we can't stick it in the cache */
> - if (rc) {
> - __ClearPageLocked(page);
> + if (rc)
> return rc;
> - }
>
> /* move first page to the tmplist */
> *offset = (loff_t)page->index << PAGE_SHIFT;
> @@ -4328,12 +4319,9 @@ readpages_get_pages(struct address_space *mapping,
> struct list_head *page_list,
> if (*bytes + PAGE_SIZE > rsize)
> break;
>
> - __SetPageLocked(page);
> - rc = add_to_page_cache_locked(page, mapping, page->index,
> gfp);
> - if (rc) {
> - __ClearPageLocked(page);
> + rc = add_to_page_cache(page, mapping, page->index, gfp);
> + if (rc)
> break;
> - }
> list_move_tail(>lru, tmplist);
> (*bytes) += PAGE_SIZE;
> expected_index++;
> --
> 2.28.0
>
--
Thanks,
Steve
Re: [PATCH v4 0/3] time namespace aware system boot time
On Mon, Oct 19, 2020 at 09:52:54PM +0200, Michael Weiß wrote: > Time namespaces make it possible to virtualize time inside of > containers, e.g., it is feasible to reset the uptime of a container > to zero by setting the time namespace offset for boottime to the > negated current value of the CLOCK_BOOTTIME. > > However, the boot time stamp provided by getboottime64() does not > take care of time namespaces. The resulting boot time stamp 'btime' > provided by /proc/stat does not show a plausible time stamp inside > the time namespace of a container. > > We address this by shifting the value returned by getboottime64() > by subtracting the boottime offset of the time namespace. > (A selftest to check the expected /proc/stat 'btime' inside the > namespace is provided.) > > Further, to avoid to show processes as time travelers inside of the > time namespace the boottime offset then needs to be added to the > start_boottime provided by the task_struct. > > v4 Changes: > Avoid type conversions back and forth between timespec64 and ktime_t > in 'proc/stat.c' as suggested by Andrei. > Introduced timens_sub_boottime() in 'time_namespace.h' to provide > better coder readability/consistency. > Reviewed-by: Andrei Vagin Thanks, Andrei
Re: [PATCH 0/3] warn and suppress irqflood
On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote: > I hit a irqflood bug on powerpc platform, and two years ago, on a x86 > platform. > When the bug happens, the kernel is totally occupies by irq. Currently, there > may be nothing or just soft lockup warning showed in console. It is better > to warn users with irq flood info. > > In the kdump case, the kernel can move on by suppressing the irq flood. You're curing the symptom not the cause and the cure is just magic and can't work reliably. Where is that irq flood originated from and why is none of the mechanisms we have in place to shut it up working? Thanks, tglx
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote: > > > The dynamic loader has to process the LOAD segments to get to the ELF > > > note that says to enable BTI. Maybe we could do a first pass and load > > > only the segments that cover notes. But that requires lots of changes > > > to generic code in the loader. > > > > What if the loader always enabled BTI for PROT_EXEC pages, but then when > > discovering that this was a mistake, mprotect() the pages without BTI? Then > > both BTI and MDWX would work and the penalty of not getting MDWX would fall > > to non-BTI programs. What's the expected proportion of BTI enabled code vs. > > disabled in the future, is it perhaps expected that a distro would enable > > the flag globally so eventually only a few legacy programs might be > > unprotected? > > i thought mprotect(PROT_EXEC) would get filtered > with or without bti, is that not the case? We can adjust the filter in systemd to match any combination of flags to allow and to deny. Lennart -- Lennart Poettering, Berlin
[PATCH v1 0/5] Introduce a new helper marco DEFINE_STORE_ATTRIBUTE at seq_file.c
We already own DEFINE_SHOW_ATTRIBUTE() helper macro for defining attribute for read-only file, but we found many of drivers also want a helper marco for read-write file too. So we try to add this macro to help decrease code duplication. Luo Jiaxing (5): seq_file: Introduce DEFINE_STORE_ATTRIBUTE() helper macro scsi: hisi_sas: Introduce DEFINE_STORE_ATTRIBUTE for debugfs scsi: qla2xxx: Introduce DEFINE_STORE_ATTRIBUTE for debugfs usb: dwc3: debugfs: Introduce DEFINE_STORE_ATTRIBUTE drm/i915/display: Introduce DEFINE_STORE_ATTRIBUTE for debugfs .../gpu/drm/i915/display/intel_display_debugfs.c | 55 + drivers/scsi/hisi_sas/hisi_sas_main.c | 135 +++-- drivers/scsi/qla2xxx/qla_dfs.c | 19 +-- drivers/usb/dwc3/debugfs.c | 52 +--- include/linux/seq_file.h | 15 +++ 5 files changed, 41 insertions(+), 235 deletions(-) -- 2.7.4
[PATCH] nvme-rdma: handle nvme completion data length
Hit a kernel warning:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 0 at lib/refcount.c:28
RIP: 0010:refcount_warn_saturate+0xd9/0xe0
Call Trace:
nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma]
__ib_process_cq+0x76/0x150 [ib_core]
...
The reason is that a zero bytes message received from target, and the
host side continues to process without length checking, then the
previous CQE is processed twice.
Handle data length, ignore zero bytes message, and try to recovery for
corrupted CQE case.
Signed-off-by: zhenwei pi
---
drivers/nvme/host/rdma.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 9e378d0a0c01..9f5112040d43 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1767,6 +1767,17 @@ static void nvme_rdma_recv_done(struct ib_cq *cq, struct
ib_wc *wc)
return;
}
+ if (unlikely(!wc->byte_len)) {
+ /* zero bytes message could be ignored */
+ return;
+ } else if (unlikely(wc->byte_len < len)) {
+ /* Corrupted completion, try to recovry */
+ dev_err(queue->ctrl->ctrl.device,
+ "Unexpected nvme completion length(%d)\n",
wc->byte_len);
+ nvme_rdma_error_recovery(queue->ctrl);
+ return;
+ }
+
ib_dma_sync_single_for_cpu(ibdev, qe->dma, len, DMA_FROM_DEVICE);
/*
* AEN requests are special as they don't time out and can
--
2.11.0
[PATCH v1 3/5] scsi: qla2xxx: Introduce DEFINE_STORE_ATTRIBUTE for debugfs
Seq instroduce a new helper marco DEFINE_STORE_ATTRIBUTE for
Read-Write file, So we apply it at qla2xxx to reduce some duplicate code.
Signed-off-by: Luo Jiaxing
---
drivers/scsi/qla2xxx/qla_dfs.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_dfs.c b/drivers/scsi/qla2xxx/qla_dfs.c
index f89ad32..d7796e3 100644
--- a/drivers/scsi/qla2xxx/qla_dfs.c
+++ b/drivers/scsi/qla2xxx/qla_dfs.c
@@ -513,14 +513,6 @@ qla_dfs_naqp_show(struct seq_file *s, void *unused)
return 0;
}
-static int
-qla_dfs_naqp_open(struct inode *inode, struct file *file)
-{
- struct scsi_qla_host *vha = inode->i_private;
-
- return single_open(file, qla_dfs_naqp_show, vha);
-}
-
static ssize_t
qla_dfs_naqp_write(struct file *file, const char __user *buffer,
size_t count, loff_t *pos)
@@ -569,14 +561,7 @@ qla_dfs_naqp_write(struct file *file, const char __user
*buffer,
return rc;
}
-static const struct file_operations dfs_naqp_ops = {
- .open = qla_dfs_naqp_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
- .write = qla_dfs_naqp_write,
-};
-
+DEFINE_STORE_ATTRIBUTE(qla_dfs_naqp);
int
qla2x00_dfs_setup(scsi_qla_host_t *vha)
@@ -622,7 +607,7 @@ qla2x00_dfs_setup(scsi_qla_host_t *vha)
if (IS_QLA27XX(ha) || IS_QLA83XX(ha) || IS_QLA28XX(ha)) {
ha->tgt.dfs_naqp = debugfs_create_file("naqp",
- 0400, ha->dfs_dir, vha, _naqp_ops);
+ 0400, ha->dfs_dir, vha, _dfs_naqp_ops);
if (!ha->tgt.dfs_naqp) {
ql_log(ql_log_warn, vha, 0xd011,
"Unable to create debugFS naqp node.\n");
--
2.7.4
[PATCH v1 2/5] scsi: hisi_sas: Introduce DEFINE_STORE_ATTRIBUTE for debugfs
Seq instroduce a new helper marco DEFINE_STORE_ATTRIBUTE for
Read-Write file, So we use it at our code to reduce some duplicate code.
Signed-off-by: Luo Jiaxing
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 135 --
1 file changed, 16 insertions(+), 119 deletions(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 128583d..12a4fdb 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -3403,22 +3403,7 @@ static ssize_t
hisi_sas_debugfs_bist_linkrate_write(struct file *filp,
return count;
}
-
-static int hisi_sas_debugfs_bist_linkrate_open(struct inode *inode,
- struct file *filp)
-{
- return single_open(filp, hisi_sas_debugfs_bist_linkrate_show,
- inode->i_private);
-}
-
-static const struct file_operations hisi_sas_debugfs_bist_linkrate_ops = {
- .open = hisi_sas_debugfs_bist_linkrate_open,
- .read = seq_read,
- .write = hisi_sas_debugfs_bist_linkrate_write,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_STORE_ATTRIBUTE(hisi_sas_debugfs_bist_linkrate);
static const struct {
int value;
@@ -3493,22 +3478,7 @@ static ssize_t
hisi_sas_debugfs_bist_code_mode_write(struct file *filp,
return count;
}
-
-static int hisi_sas_debugfs_bist_code_mode_open(struct inode *inode,
- struct file *filp)
-{
- return single_open(filp, hisi_sas_debugfs_bist_code_mode_show,
- inode->i_private);
-}
-
-static const struct file_operations hisi_sas_debugfs_bist_code_mode_ops = {
- .open = hisi_sas_debugfs_bist_code_mode_open,
- .read = seq_read,
- .write = hisi_sas_debugfs_bist_code_mode_write,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_STORE_ATTRIBUTE(hisi_sas_debugfs_bist_code_mode);
static ssize_t hisi_sas_debugfs_bist_phy_write(struct file *filp,
const char __user *buf,
@@ -3542,22 +3512,7 @@ static int hisi_sas_debugfs_bist_phy_show(struct
seq_file *s, void *p)
return 0;
}
-
-static int hisi_sas_debugfs_bist_phy_open(struct inode *inode,
- struct file *filp)
-{
- return single_open(filp, hisi_sas_debugfs_bist_phy_show,
- inode->i_private);
-}
-
-static const struct file_operations hisi_sas_debugfs_bist_phy_ops = {
- .open = hisi_sas_debugfs_bist_phy_open,
- .read = seq_read,
- .write = hisi_sas_debugfs_bist_phy_write,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_STORE_ATTRIBUTE(hisi_sas_debugfs_bist_phy);
static const struct {
int value;
@@ -3621,22 +3576,7 @@ static ssize_t hisi_sas_debugfs_bist_mode_write(struct
file *filp,
return count;
}
-
-static int hisi_sas_debugfs_bist_mode_open(struct inode *inode,
- struct file *filp)
-{
- return single_open(filp, hisi_sas_debugfs_bist_mode_show,
- inode->i_private);
-}
-
-static const struct file_operations hisi_sas_debugfs_bist_mode_ops = {
- .open = hisi_sas_debugfs_bist_mode_open,
- .read = seq_read,
- .write = hisi_sas_debugfs_bist_mode_write,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_STORE_ATTRIBUTE(hisi_sas_debugfs_bist_mode);
static ssize_t hisi_sas_debugfs_bist_enable_write(struct file *filp,
const char __user *buf,
@@ -3677,22 +3617,7 @@ static int hisi_sas_debugfs_bist_enable_show(struct
seq_file *s, void *p)
return 0;
}
-
-static int hisi_sas_debugfs_bist_enable_open(struct inode *inode,
-struct file *filp)
-{
- return single_open(filp, hisi_sas_debugfs_bist_enable_show,
- inode->i_private);
-}
-
-static const struct file_operations hisi_sas_debugfs_bist_enable_ops = {
- .open = hisi_sas_debugfs_bist_enable_open,
- .read = seq_read,
- .write = hisi_sas_debugfs_bist_enable_write,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_STORE_ATTRIBUTE(hisi_sas_debugfs_bist_enable);
static const struct {
char *name;
@@ -3730,21 +3655,7 @@ static int hisi_sas_debugfs_show(struct seq_file *s,
void *p)
return 0;
}
-
-static int hisi_sas_debugfs_open(struct inode *inode, struct file *filp)
-{
- return single_open(filp, hisi_sas_debugfs_show,
- inode->i_private);
-}
-
-static const struct file_operations hisi_sas_debugfs_ops = {
- .open =
[PATCH v1 5/5] drm/i915/display: Introduce DEFINE_STORE_ATTRIBUTE for debugfs
Seq instroduce a new helper marco DEFINE_STORE_ATTRIBUTE for
Read-Write file, So we apply it at drm/i915/display to reduce some
duplicate code.
Signed-off-by: Luo Jiaxing
---
.../gpu/drm/i915/display/intel_display_debugfs.c | 55 ++
1 file changed, 4 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 0bf31f9..89d38d2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1329,21 +1329,7 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
return 0;
}
-static int i915_displayport_test_active_open(struct inode *inode,
-struct file *file)
-{
- return single_open(file, i915_displayport_test_active_show,
- inode->i_private);
-}
-
-static const struct file_operations i915_displayport_test_active_fops = {
- .owner = THIS_MODULE,
- .open = i915_displayport_test_active_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .write = i915_displayport_test_active_write
-};
+DEFINE_STORE_ATTRIBUTE(i915_displayport_test_active);
static int i915_displayport_test_data_show(struct seq_file *m, void *data)
{
@@ -1733,19 +1719,7 @@ static ssize_t i915_hpd_storm_ctl_write(struct file
*file,
return len;
}
-static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
-{
- return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
-}
-
-static const struct file_operations i915_hpd_storm_ctl_fops = {
- .owner = THIS_MODULE,
- .open = i915_hpd_storm_ctl_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .write = i915_hpd_storm_ctl_write
-};
+DEFINE_STORE_ATTRIBUTE(i915_hpd_storm_ctl);
static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
{
@@ -1811,14 +1785,7 @@ static ssize_t i915_hpd_short_storm_ctl_write(struct
file *file,
return len;
}
-static const struct file_operations i915_hpd_short_storm_ctl_fops = {
- .owner = THIS_MODULE,
- .open = i915_hpd_short_storm_ctl_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .write = i915_hpd_short_storm_ctl_write,
-};
+DEFINE_STORE_ATTRIBUTE(i915_hpd_short_storm_ctl);
static int i915_drrs_ctl_set(void *data, u64 val)
{
@@ -2181,21 +2148,7 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
return len;
}
-static int i915_dsc_fec_support_open(struct inode *inode,
-struct file *file)
-{
- return single_open(file, i915_dsc_fec_support_show,
- inode->i_private);
-}
-
-static const struct file_operations i915_dsc_fec_support_fops = {
- .owner = THIS_MODULE,
- .open = i915_dsc_fec_support_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .write = i915_dsc_fec_support_write
-};
+DEFINE_STORE_ATTRIBUTE(i915_dsc_fec_support);
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
--
2.7.4
[PATCH v1 1/5] seq_file: Introduce DEFINE_STORE_ATTRIBUTE() helper macro
We already own DEFINE_SHOW_ATTRIBUTE() helper macro for defining attribute
for read-only file, but we found many of drivers want a helper marco for
read-write file too.
So we try to make one to decrease code duplication.
Signed-off-by: Luo Jiaxing
---
include/linux/seq_file.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index 813614d..3b3b797 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -191,6 +191,21 @@ static const struct proc_ops __name ## _proc_ops = {
\
.proc_release = single_release, \
}
+#define DEFINE_STORE_ATTRIBUTE(__name) \
+static int __name ## _open(struct inode *inode, struct file *file) \
+{ \
+ return single_open(file, __name ## _show, inode->i_private);\
+} \
+ \
+static const struct file_operations __name ## _fops = {
\
+ .owner = THIS_MODULE, \
+ .open = __name ## _open, \
+ .read = seq_read, \
+ .write = __name ## _write, \
+ .llseek = seq_lseek,\
+ .release= single_release, \
+}
+
static inline struct user_namespace *seq_user_ns(struct seq_file *seq)
{
#ifdef CONFIG_USER_NS
--
2.7.4
[PATCH v1 4/5] usb: dwc3: debugfs: Introduce DEFINE_STORE_ATTRIBUTE
Seq instroduce a new helper marco DEFINE_STORE_ATTRIBUTE for
Read-Write file, So we apply it at dwc3 debugfs to reduce some duplicate
code.
Signed-off-by: Luo Jiaxing
---
drivers/usb/dwc3/debugfs.c | 52 --
1 file changed, 4 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 5da4f60..27074cb 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -348,11 +348,6 @@ static int dwc3_lsp_show(struct seq_file *s, void *unused)
return 0;
}
-static int dwc3_lsp_open(struct inode *inode, struct file *file)
-{
- return single_open(file, dwc3_lsp_show, inode->i_private);
-}
-
static ssize_t dwc3_lsp_write(struct file *file, const char __user *ubuf,
size_t count, loff_t *ppos)
{
@@ -377,13 +372,7 @@ static ssize_t dwc3_lsp_write(struct file *file, const
char __user *ubuf,
return count;
}
-static const struct file_operations dwc3_lsp_fops = {
- .open = dwc3_lsp_open,
- .write = dwc3_lsp_write,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_STORE_ATTRIBUTE(dwc3_lsp);
static int dwc3_mode_show(struct seq_file *s, void *unused)
{
@@ -412,11 +401,6 @@ static int dwc3_mode_show(struct seq_file *s, void *unused)
return 0;
}
-static int dwc3_mode_open(struct inode *inode, struct file *file)
-{
- return single_open(file, dwc3_mode_show, inode->i_private);
-}
-
static ssize_t dwc3_mode_write(struct file *file,
const char __user *ubuf, size_t count, loff_t *ppos)
{
@@ -445,13 +429,7 @@ static ssize_t dwc3_mode_write(struct file *file,
return count;
}
-static const struct file_operations dwc3_mode_fops = {
- .open = dwc3_mode_open,
- .write = dwc3_mode_write,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_STORE_ATTRIBUTE(dwc3_mode);
static int dwc3_testmode_show(struct seq_file *s, void *unused)
{
@@ -491,11 +469,6 @@ static int dwc3_testmode_show(struct seq_file *s, void
*unused)
return 0;
}
-static int dwc3_testmode_open(struct inode *inode, struct file *file)
-{
- return single_open(file, dwc3_testmode_show, inode->i_private);
-}
-
static ssize_t dwc3_testmode_write(struct file *file,
const char __user *ubuf, size_t count, loff_t *ppos)
{
@@ -528,13 +501,7 @@ static ssize_t dwc3_testmode_write(struct file *file,
return count;
}
-static const struct file_operations dwc3_testmode_fops = {
- .open = dwc3_testmode_open,
- .write = dwc3_testmode_write,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_STORE_ATTRIBUTE(dwc3_testmode);
static int dwc3_link_state_show(struct seq_file *s, void *unused)
{
@@ -564,11 +531,6 @@ static int dwc3_link_state_show(struct seq_file *s, void
*unused)
return 0;
}
-static int dwc3_link_state_open(struct inode *inode, struct file *file)
-{
- return single_open(file, dwc3_link_state_show, inode->i_private);
-}
-
static ssize_t dwc3_link_state_write(struct file *file,
const char __user *ubuf, size_t count, loff_t *ppos)
{
@@ -620,13 +582,7 @@ static ssize_t dwc3_link_state_write(struct file *file,
return count;
}
-static const struct file_operations dwc3_link_state_fops = {
- .open = dwc3_link_state_open,
- .write = dwc3_link_state_write,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_STORE_ATTRIBUTE(dwc3_link_state);
struct dwc3_ep_file_map {
const char name[25];
--
2.7.4
RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: David Hildenbrand > Sent: 22 October 2020 09:35 > > On 22.10.20 10:26, Greg KH wrote: > > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: > >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > From: David Laight > > This lets the compiler inline it into import_iovec() generating > much better code. > > Signed-off-by: David Laight > Signed-off-by: Christoph Hellwig > --- > fs/read_write.c | 179 > lib/iov_iter.c | 176 +++ > 2 files changed, 176 insertions(+), 179 deletions(-) > >>> > >>> Strangely, this commit causes a regression in Linus's tree right now. > >>> > >>> I can't really figure out what the regression is, only that this commit > >>> triggers a "large Android system binary" from working properly. There's > >>> no kernel log messages anywhere, and I don't have any way to strace the > >>> thing in the testing framework, so any hints that people can provide > >>> would be most appreciated. > >> > >> It's a pure move - modulo changed line breaks in the argument lists > >> the functions involved are identical before and after that (just checked > >> that directly, by checking out the trees before and after, extracting two > >> functions in question from fs/read_write.c and lib/iov_iter.c (before and > >> after, resp.) and checking the diff between those. > >> > >> How certain is your bisection? > > > > The bisection is very reproducable. > > > > But, this looks now to be a compiler bug. I'm using the latest version > > of clang and if I put "noinline" at the front of the function, > > everything works. > > Well, the compiler can do more invasive optimizations when inlining. If > you have buggy code that relies on some unspecified behavior, inlining > can change the behavior ... but going over that code, there isn't too > much action going on. At least nothing screamed at me. Apart from all the optimisations that get rid off the 'pass be reference' parameters and strange conditional tests. Plenty of scope for the compiler getting it wrong. But nothing even vaguely illegal. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH v6 1/6] dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague.
The Czech Technical University in Prague (CTU) is one of the biggest and oldest (founded 1707) technical universities in Europe. The abbreviation in Czech language is ČVUT according to official name in Czech language České vysoké učení technické v Praze The English translation The Czech Technical University in Prague The university pages in English https://www.cvut.cz/en Signed-off-by: Pavel Pisa Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 967e78c5ec0a..dedb10f1b250 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -215,6 +215,8 @@ patternProperties: description: Hangzhou C-SKY Microsystems Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. + "^ctu,.*": +description: Czech Technical University in Prague "^cubietech,.*": description: Cubietech, Ltd. "^cypress,.*": -- 2.20.1
[PATCH v6 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
The device-tree bindings for open-source/open-hardware CAN FD IP core
designed at the Czech Technical University in Prague.
CTU CAN FD IP core and other CTU CAN bus related projects
listing and documentation page
http://canbus.pages.fel.cvut.cz/
Signed-off-by: Pavel Pisa
Reviewed-by: Rob Herring
---
.../bindings/net/can/ctu,ctucanfd.yaml| 63 +++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
new file mode 100644
index ..5113bb419ec1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/ctu,ctucanfd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CTU CAN FD Open-source IP Core Device Tree Bindings
+
+description: |
+ Open-source CAN FD IP core developed at the Czech Technical University in
Prague
+
+ The core sources and documentation on project page
+[1] sources : https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core
+[2] datasheet :
https://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf
+
+ Integration in Xilinx Zynq SoC based system together with
+ OpenCores SJA1000 compatible controllers
+[3] project : https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top
+ Martin Jerabek dimploma thesis with integration and testing
+ framework description
+[4] PDF :
https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf
+
+maintainers:
+ - Pavel Pisa
+ - Ondrej Ille
+ - Martin Jerabek
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: ctu,ctucanfd-2
+ - const: ctu,ctucanfd
+ - const: ctu,ctucanfd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+description: |
+ phandle of reference clock (100 MHz is appropriate
+ for FPGA implementation on Zynq-7000 system).
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ctu_can_fd_0: can@43c3 {
+ compatible = "ctu,ctucanfd";
+ interrupts = <0 30 4>;
+ clocks = < 15>;
+ reg = <0x43c3 0x1>;
+};
--
2.20.1
[GIT PULL] exfat update for 5.10-rc1
Hi Linus, This is exfat update pull request for v5.10-rc1. I add description of this pull request on below. Please pull exfat with following ones. Thanks! The following changes since commit bbf5c979011a099af5dc76498918ed7df445635b: Linux 5.9 (2020-10-11 14:15:50 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git tags/exfat-for-5.10-rc1 for you to fetch changes up to eae503f7eb0509594076a951e422e29082385c96: exfat: remove useless check in exfat_move_file() (2020-10-22 08:29:12 +0900) Description for this pull request: - Replace memcpy with structure assignment. - Remove unneeded codes and use helper function i_blocksize(). - Fix typos found by codespell. Namjae Jeon (1): exfat: fix misspellings using codespell tool Tetsuhiro Kohada (5): exfat: eliminate dead code in exfat_find() exfat: remove useless directory scan in exfat_add_entry() exfat: replace memcpy with structure assignment exfat: remove 'rwoffset' in exfat_inode_info exfat: remove useless check in exfat_move_file() Xianting Tian (1): exfat: use i_blocksize() to get blocksize fs/exfat/dir.c | 29 -- fs/exfat/exfat_fs.h | 4 +- fs/exfat/file.c | 4 +- fs/exfat/inode.c| 5 +- fs/exfat/namei.c| 153 +++- fs/exfat/nls.c | 2 +- fs/exfat/super.c| 1 - 7 files changed, 71 insertions(+), 127 deletions(-)
[PATCH v6 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
From: Martin Jerabek This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). More about CAN bus related projects used and developed at CTU FEE at http://canbus.pages.fel.cvut.cz/ . Signed-off-by: Martin Jerabek Signed-off-by: Ondrej Ille Signed-off-by: Pavel Pisa --- drivers/net/can/Kconfig |1 + drivers/net/can/Makefile|1 + drivers/net/can/ctucanfd/Kconfig| 15 + drivers/net/can/ctucanfd/Makefile |7 + drivers/net/can/ctucanfd/ctu_can_fd.c | 1105 +++ drivers/net/can/ctucanfd/ctu_can_fd.h | 87 ++ drivers/net/can/ctucanfd/ctu_can_fd_frame.h | 189 drivers/net/can/ctucanfd/ctu_can_fd_hw.c| 790 + drivers/net/can/ctucanfd/ctu_can_fd_hw.h| 916 +++ drivers/net/can/ctucanfd/ctu_can_fd_regs.h | 971 10 files changed, 4082 insertions(+) create mode 100644 drivers/net/can/ctucanfd/Kconfig create mode 100644 drivers/net/can/ctucanfd/Makefile create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd.c create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_frame.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_hw.c create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_hw.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_regs.h diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 17c166cc8482..458afc4b81f2 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -168,6 +168,7 @@ config PCH_CAN source "drivers/net/can/c_can/Kconfig" source "drivers/net/can/cc770/Kconfig" +source "drivers/net/can/ctucanfd/Kconfig" source "drivers/net/can/ifi_canfd/Kconfig" source "drivers/net/can/m_can/Kconfig" source "drivers/net/can/mscan/Kconfig" diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index 22164300122d..28b39cd122f0 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -21,6 +21,7 @@ obj-y += softing/ obj-$(CONFIG_CAN_AT91) += at91_can.o obj-$(CONFIG_CAN_CC770)+= cc770/ obj-$(CONFIG_CAN_C_CAN)+= c_can/ +obj-$(CONFIG_CAN_CTUCANFD) += ctucanfd/ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o obj-$(CONFIG_CAN_GRCAN)+= grcan.o obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/ diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig new file mode 100644 index ..b6d47bba7150 --- /dev/null +++ b/drivers/net/can/ctucanfd/Kconfig @@ -0,0 +1,15 @@ +config CAN_CTUCANFD + tristate "CTU CAN-FD IP core" + help + This driver adds support for the CTU CAN FD open-source IP core. + More documentation and core sources at project page + (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). + The core integration to Xilinx Zynq system as platform driver + is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). + Implementation on Intel FPGA-based PCI Express board is available + from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). + Guidepost CTU FEE CAN bus projects page http://canbus.pages.fel.cvut.cz/ . + +if CAN_CTUCANFD + +endif diff --git a/drivers/net/can/ctucanfd/Makefile b/drivers/net/can/ctucanfd/Makefile new file mode 100644 index ..8d47008d0076 --- /dev/null +++ b/drivers/net/can/ctucanfd/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Makefile for the CTU CAN-FD IP module drivers +# + +obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o +ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o diff --git a/drivers/net/can/ctucanfd/ctu_can_fd.c b/drivers/net/can/ctucanfd/ctu_can_fd.c new file mode 100644 index ..c8953627a9f9 --- /dev/null +++ b/drivers/net/can/ctucanfd/ctu_can_fd.c @@ -0,0 +1,1105 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/*** + * + * CTU CAN FD IP Core + * + * Copyright (C) 2015-2018 Ondrej Ille FEE CTU + * Copyright (C) 2018-2020 Ondrej Ille self-funded + * Copyright (C) 2018-2019 Martin Jerabek FEE CTU + * Copyright (C) 2018-2020 Pavel Pisa FEE CTU/self-funded + * + * Project advisors: + * Jiri Novak + * Pavel Pisa + * + * Department of Measurement (http://meas.fel.cvut.cz/) + * Faculty of Electrical Engineering (http://www.fel.cvut.cz) + * Czech Technical University(http://www.cvut.cz/) + * + * This program is free software; you can redistribute it
[PATCH v6 4/6] can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.
PCI bus adaptation for CTU CAN FD open-source IP core.
The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
PCIe board with PiKRON.com designed transceiver riser shield is available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 9 +
drivers/net/can/ctucanfd/Makefile | 3 +
drivers/net/can/ctucanfd/ctu_can_fd_pci.c | 314 ++
3 files changed, 326 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_pci.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index b6d47bba7150..fb4d3cda6885 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -12,4 +12,13 @@ config CAN_CTUCANFD
if CAN_CTUCANFD
+config CAN_CTUCANFD_PCI
+ tristate "CTU CAN-FD IP core PCI/PCIe driver"
+ depends on PCI
+ help
+ This driver adds PCI/PCIe support for CTU CAN-FD IP core.
+ The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
+ PCIe board with PiKRON.com designed transceiver riser shield is
available
+ at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
+
endif
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index 8d47008d0076..eb945260952d 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -5,3 +5,6 @@
obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o
ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
+ctucanfd_pci-y := ctu_can_fd_pci.o
diff --git a/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
b/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
new file mode 100644
index ..c4542eac2747
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+
+#include "ctu_can_fd.h"
+
+#define DRV_NAME "ctucanfd_pci"
+
+#ifndef PCI_DEVICE_DATA
+#define PCI_DEVICE_DATA(vend, dev, data) \
+.vendor = PCI_VENDOR_ID_##vend, \
+.device = PCI_DEVICE_ID_##vend##_##dev, \
+.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0, \
+.driver_data = (kernel_ulong_t)(data)
+#endif
+#ifndef PCI_VENDOR_ID_TEDIA
+#define PCI_VENDOR_ID_TEDIA 0x1760
+#endif
+
+#define PCI_DEVICE_ID_ALTERA_CTUCAN_TEST 0xCAFD
+#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00
+
+#define CTUCAN_BAR0_CTUCAN_ID 0x
+#define CTUCAN_BAR0_CRA_BASE 0x4000
+#define CYCLONE_IV_CRA_A2P_IE (0x0050)
+
+#define CTUCAN_WITHOUT_CTUCAN_ID 0
+#define CTUCAN_WITH_CTUCAN_ID 1
+
+static bool use_msi = 1;
+module_param(use_msi, bool, 0444);
+MODULE_PARM_DESC(use_msi, "PCIe implementation use MSI interrupts. Default: 1
(yes)");
+
+static bool pci_use_second = 1;
+module_param(pci_use_second, bool, 0444);
+MODULE_PARM_DESC(pci_use_second, "Use the second CAN core on PCIe card.
Default: 1 (yes)");
+
+struct ctucan_pci_board_data {
+ void __iomem *bar0_base;
+ void __iomem *cra_base;
+ void __iomem *bar1_base;
+ struct list_head ndev_list_head;
+ int use_msi;
+};
+
+static struct ctucan_pci_board_data *ctucan_pci_get_bdata(struct pci_dev *pdev)
+{
+ return (struct ctucan_pci_board_data *)pci_get_drvdata(pdev);
+}
+
+static void ctucan_pci_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct ctucan_priv *priv = netdev_priv(ndev);
+ struct ctucan_pci_board_data *bdata = ctucan_pci_get_bdata(pdev);
+
+ list_add(>peers_on_pdev, >ndev_list_head);
+ priv->irq_flags = IRQF_SHARED;
+}
+
+/**
+ * ctucan_pci_probe -
[PATCH v6 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support.
Platform bus adaptation for CTU CAN FD open-source IP core.
The core has been tested together with OpenCores SJA1000
modified to be CAN FD frames tolerant on MicroZed Zynq based
MZ_APO education kits designed by Petr Porazil from PiKRON.com
company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
The kit description at the Computer Architectures course pages
https://cw.fel.cvut.cz/wiki/courses/b35apo/documentation/mz_apo/start .
Kit carrier board and mechanics design source files
https://gitlab.com/pikron/projects/mz_apo/microzed_apo
The work is documented in Martin Jeřábek's diploma theses
Open-source and Open-hardware CAN FD Protocol Support
https://dspace.cvut.cz/handle/10467/80366
.
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 11 ++
drivers/net/can/ctucanfd/Makefile | 3 +
.../net/can/ctucanfd/ctu_can_fd_platform.c| 142 ++
3 files changed, 156 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_platform.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index fb4d3cda6885..01fcfe5873cc 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
PCIe board with PiKRON.com designed transceiver riser shield is
available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
+config CAN_CTUCANFD_PLATFORM
+ tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver"
+ depends on OF || COMPILE_TEST
+ help
+ The core has been tested together with OpenCores SJA1000
+ modified to be CAN FD frames tolerant on MicroZed Zynq based
+ MZ_APO education kits designed by Petr Porazil from PiKRON.com
+ company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
+ The kit description at the Computer Architectures course pages
+ https://cw.fel.cvut.cz/b182/courses/b35apo/documentation/mz_apo/start
.
+
endif
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index eb945260952d..a77ca72d534e 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -8,3 +8,6 @@ ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
ctucanfd_pci-y := ctu_can_fd_pci.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PLATFORM) += ctucanfd_platform.o
+ctucanfd_platform-y += ctu_can_fd_platform.o
diff --git a/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
b/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
new file mode 100644
index ..c35b16b8566b
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ctu_can_fd.h"
+
+#define DRV_NAME "ctucanfd"
+
+static void ctucan_platform_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct platform_device *pdev = container_of(dev, struct platform_device,
+ dev);
+
+ platform_set_drvdata(pdev, ndev);
+}
+
+/**
+ * ctucan_platform_probe - Platform registration call
+ * @pdev: Handle to the platform device structure
+ *
+ * This function does all the memory allocation and registration for the CAN
+ * device.
+ *
+ * Return: 0 on success and failure value on error
+ */
+static int ctucan_platform_probe(struct platform_device *pdev)
+{
+ struct resource *res; /* IO mem resources */
+ struct device *dev = >dev;
+ void __iomem *addr;
+ int ret;
+ unsigned int
Re: [PATCH v1 7/8] perf c2c: Add option '-d llc' for sorting with LLC load
On Tue, Oct 20, 2020 at 04:08:39PM +0800, Leo Yan wrote:
SNIP
> >
> > please update man page with this
> >
> > > else {
> > > pr_err("failed: unknown display type: %s\n", str);
> > > return -1;
> > > @@ -2766,9 +2795,10 @@ static int build_cl_output(char *cl_sort, bool
> > > no_source)
> > > }
> > >
> > > if (asprintf(_output,
> > > - "%s%s%s%s%s%s%s%s%s%s",
> > > + "%s%s%s%s%s%s%s%s%s%s%s",
> >
> > why is there extra '%s' when we did not add new argument.. ?
>
> This is deliberate. The change is as below:
>
> if (asprintf(_output,
> - "%s%s%s%s%s%s%s%s%s%s",
> + "%s%s%s%s%s%s%s%s%s%s%s",
> c2c.use_stdio ? "cl_num_empty," : "",
> - "percent_rmt_hitm,"
> + c2c.display == DISPLAY_LLC ? "percent_llc_hit," :
> +"percent_rmt_hitm,",
> "percent_lcl_hitm,"
>
> In the old code the string "percent_rmt_hitm," is merged with later
> lines (the second string is "percent_lcl_hitm,") into single string.
>
> In this patch, it needs to check condition c2c.display and pass
> different string ("percent_llc_hit," vs "percent_rmt_hitm,"), thus
> the string ("percent_llc_hit," or "percent_rmt_hitm,") is passed
> independently, it's _NOT_ jointed with sequnetial lines.
ah right, it's now 2 arguments instead of one
thanks,
jirka
Re: [PATCH v2 1/3] x86, sched: check for counters overflow in frequency invariant accounting
On Sun, May 31, 2020 at 08:24:51PM +0200, Giovanni Gherdovich wrote:
Hi Giovanni!
> +error:
> + pr_warn("Scheduler frequency invariance went wobbly, disabling!\n");
> + schedule_work(_freq_invariance_work);
> +}
I'm getting reports that we trigger this on resume. Would it make sense
to hook into tsc_{save,restore}_sched_clock_state() (or somewhere near
there) to reset the state (basically call init_counter_refs() again to
ensure we're not having to deal with crazy ?
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On 22.10.20 10:40, David Laight wrote: > From: David Hildenbrand >> Sent: 22 October 2020 09:35 >> >> On 22.10.20 10:26, Greg KH wrote: >>> On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: >> From: David Laight >> >> This lets the compiler inline it into import_iovec() generating >> much better code. >> >> Signed-off-by: David Laight >> Signed-off-by: Christoph Hellwig >> --- >> fs/read_write.c | 179 >> lib/iov_iter.c | 176 +++ >> 2 files changed, 176 insertions(+), 179 deletions(-) > > Strangely, this commit causes a regression in Linus's tree right now. > > I can't really figure out what the regression is, only that this commit > triggers a "large Android system binary" from working properly. There's > no kernel log messages anywhere, and I don't have any way to strace the > thing in the testing framework, so any hints that people can provide > would be most appreciated. It's a pure move - modulo changed line breaks in the argument lists the functions involved are identical before and after that (just checked that directly, by checking out the trees before and after, extracting two functions in question from fs/read_write.c and lib/iov_iter.c (before and after, resp.) and checking the diff between those. How certain is your bisection? >>> >>> The bisection is very reproducable. >>> >>> But, this looks now to be a compiler bug. I'm using the latest version >>> of clang and if I put "noinline" at the front of the function, >>> everything works. >> >> Well, the compiler can do more invasive optimizations when inlining. If >> you have buggy code that relies on some unspecified behavior, inlining >> can change the behavior ... but going over that code, there isn't too >> much action going on. At least nothing screamed at me. > > Apart from all the optimisations that get rid off the 'pass be reference' > parameters and strange conditional tests. > Plenty of scope for the compiler getting it wrong. > But nothing even vaguely illegal. Not the first time that people blame the compiler to then figure out that something else is wrong ... but maybe this time is different :) -- Thanks, David / dhildenb
[PATCH][v2] PM / sysfs: Expose suspend resume driver flags in sysfs
Currently there are 4 driver flags to control system suspend/resume
behavior: DPM_FLAG_NO_DIRECT_COMPLETE, DPM_FLAG_SMART_PREPARE,
DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME. Make these flags
visible in sysfs as read-only to get a brief understanding of the
expected behavior of each device during suspend/resume, so as to
facilitate suspend/resume debugging/tuning.
For example:
/sys/devices/pci:00/:00:15.1/power/driver_flags:4
(DPM_FLAG_SMART_SUSPEND)
/sys/devices/pci:00/:00:07.3/power/driver_flags:5
(DPM_FLAG_NO_DIRECT_COMPLETE | DPM_FLAG_SMART_SUSPEND)
Acked-by: Len Brown
Signed-off-by: Chen Yu
---
v2: Adding description in Documentation/ABI/testing/sysfs-devices-power
according to Greg's suggestion.
--
Documentation/ABI/testing/sysfs-devices-power | 11 +++
drivers/base/power/sysfs.c| 29 ++-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-devices-power
b/Documentation/ABI/testing/sysfs-devices-power
index 1763e64dd152..8ea68639ab3a 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -269,3 +269,14 @@ Description:
the current runtime PM status of the device, which may be
"suspended", "suspending", "resuming", "active", "error" (fatal
error), or "unsupported" (runtime PM is disabled).
+
+What: /sys/devices/.../power/driver_flags
+Date: October 2020
+Contact: Chen Yu
+Description:
+ The /sys/devices/.../driver_flags attribute contains the driver
+ flags to control system suspend/resume. The flag is a
combination
+ of DPM_FLAG_NO_DIRECT_COMPLETE, DPM_FLAG_SMART_PREPARE,
+ DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME, or 0 if the
+ driver has not set any flag. This attribute is read-only. If
+ CONFIG_PM_ADVANCED_DEBUG is not set this attribute is empty.
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index a1474fb67db9..48313a1040a5 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -607,6 +607,13 @@ static ssize_t async_store(struct device *dev, struct
device_attribute *attr,
static DEVICE_ATTR_RW(async);
+static ssize_t driver_flags_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ return sysfs_emit(buf, "%x\n", dev->power.driver_flags);
+}
+static DEVICE_ATTR_RO(driver_flags);
+
#endif /* CONFIG_PM_SLEEP */
#endif /* CONFIG_PM_ADVANCED_DEBUG */
@@ -691,6 +698,20 @@ static const struct attribute_group
pm_qos_flags_attr_group = {
.attrs = pm_qos_flags_attrs,
};
+static struct attribute *pm_driver_flags_attrs[] = {
+#ifdef CONFIG_PM_ADVANCED_DEBUG
+#ifdef CONFIG_PM_SLEEP
+ _attr_driver_flags.attr,
+#endif
+#endif
+ NULL,
+};
+
+static const struct attribute_group pm_driver_flags_attr_group = {
+ .name = power_group_name,
+ .attrs = pm_driver_flags_attrs,
+};
+
int dpm_sysfs_add(struct device *dev)
{
int rc;
@@ -719,11 +740,17 @@ int dpm_sysfs_add(struct device *dev)
if (rc)
goto err_wakeup;
}
- rc = pm_wakeup_source_sysfs_add(dev);
+ rc = sysfs_merge_group(>kobj, _driver_flags_attr_group);
if (rc)
goto err_latency;
+
+ rc = pm_wakeup_source_sysfs_add(dev);
+ if (rc)
+ goto err_flags;
return 0;
+ err_flags:
+ sysfs_unmerge_group(>kobj, _driver_flags_attr_group);
err_latency:
sysfs_unmerge_group(>kobj, _qos_latency_tolerance_attr_group);
err_wakeup:
--
2.17.1
[PATCH 11/11] dt-bindings: interrupt-controller: update bindings for supporting more SoCs
From: Biwen Li Update bindings for Layerscape external irqs, support more SoCs(LS1043A, LS1046A, LS1088A, LS208xA, LX216xA) Signed-off-by: Biwen Li --- .../bindings/interrupt-controller/fsl,ls-extirq.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt index f0ad7801e8cf..6c55eb25cf93 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt @@ -1,6 +1,7 @@ * Freescale Layerscape external IRQs -Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting +Some Layerscape SOCs (LS1021A, LS1043A, LS1046A +LS1088A, LS208xA, LX216xA) support inverting the polarity of certain external interrupt lines. The device node must be a child of the node representing the @@ -8,6 +9,9 @@ Supplemental Configuration Unit (SCFG). Required properties: - compatible: should be "fsl,-extirq", e.g. "fsl,ls1021a-extirq". + "fsl,ls1043a-extirq": for LS1043A, LS1046A. + "fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA. + - #interrupt-cells: Must be 2. The first element is the index of the external interrupt line. The second element is the trigger type. - #address-cells: Must be 0. -- 2.17.1
[PATCH 03/11] arm64: dts: ls1046a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index d4c1da3d4bde..5580aa0430d4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -3,7 +3,7 @@
* Device Tree Include file for Freescale Layerscape-1046A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018-2020 NXP
*
* Mingkai Hu
*/
@@ -233,6 +233,31 @@
compatible = "fsl,ls1046a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
big-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x157 0x1>;
+
+ extirq: interrupt-controller@1ac {
+ compatible = "fsl,ls1046a-extirq",
"fsl,ls1043a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x1ac 4>;
+ interrupt-map =
+ <0 0 GIC_SPI 131
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 GIC_SPI 132
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 GIC_SPI 133
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 GIC_SPI 135
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 GIC_SPI 136
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 GIC_SPI 137
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 GIC_SPI 145
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 GIC_SPI 146
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 GIC_SPI 147
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 GIC_SPI 149
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 GIC_SPI 150
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 GIC_SPI 151
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
};
crypto: crypto@170 {
--
2.17.1
[PATCH 08/11] arm64: dts: ls208xa-rdb: add interrupt line for RTC node
From: Biwen Li
Add interrupt line for RTC node on ls208xa-rdb
Signed-off-by: Biwen Li
---
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
index d0d670227ae2..4b71c4fcb35f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
@@ -3,7 +3,7 @@
* Device Tree file for Freescale LS2080A RDB Board.
*
* Copyright 2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Abhimanyu Saini
*
@@ -56,6 +56,8 @@
rtc@68 {
compatible = "dallas,ds3232";
reg = <0x68>;
+ /* IRQ_RTC_B -> IRQ06, active low */
+ interrupts-extended = < 6
IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.17.1
[PATCH 02/11] arm64: dts: ls1043a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
.../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index c084c7a4b6a6..59c4365a51e0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -3,7 +3,7 @@
* Device Tree Include file for Freescale Layerscape-1043A family SoC.
*
* Copyright 2014-2015 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018-2020 NXP
*
* Mingkai Hu
*/
@@ -230,6 +230,31 @@
compatible = "fsl,ls1043a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
big-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x157 0x1>;
+
+ extirq: interrupt-controller@1ac {
+ compatible = "fsl,ls1043a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x1ac 4>;
+ interrupt-map =
+ <0 0 GIC_SPI 131
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 GIC_SPI 132
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 GIC_SPI 133
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 GIC_SPI 135
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 GIC_SPI 136
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 GIC_SPI 137
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 GIC_SPI 145
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 GIC_SPI 146
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 GIC_SPI 147
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 GIC_SPI 149
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 GIC_SPI 150
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 GIC_SPI 151
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
};
crypto: crypto@170 {
--
2.17.1
[PATCH 04/11] arm64: dts: ls1046ardb: Add interrupt line for RTC node
From: Hou Zhiqiang
Add interrupt line for RTC node, which is low level active.
Signed-off-by: Hou Zhiqiang
---
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index d53ccc56bb63..60acdf0b689e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -3,6 +3,7 @@
* Device Tree Include file for Freescale Layerscape-1046A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2019-2020 NXP
*
* Mingkai Hu
*/
@@ -74,6 +75,8 @@
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
+ /* IRQ_RTC_B -> IRQ05, active low */
+ interrupts-extended = < 5 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.17.1
[PATCH 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
From: Hou Zhiqiang Add an new IRQ chip declaration for LS1043A and LS1088A - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA Signed-off-by: Hou Zhiqiang Signed-off-by: Biwen Li --- drivers/irqchip/irq-ls-extirq.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/irqchip/irq-ls-extirq.c b/drivers/irqchip/irq-ls-extirq.c index 4d1179fed77c..564e6de0bd8e 100644 --- a/drivers/irqchip/irq-ls-extirq.c +++ b/drivers/irqchip/irq-ls-extirq.c @@ -1,4 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 +// Copyright 2019-2020 NXP #define pr_fmt(fmt) "irq-ls-extirq: " fmt @@ -183,6 +184,9 @@ ls_extirq_of_init(struct device_node *node, struct device_node *parent) priv->bit_reverse = (revcr != 0); } + if (of_device_is_compatible(node, "fsl,ls1043a-extirq")) + priv->bit_reverse = true; + domain = irq_domain_add_hierarchy(parent_domain, 0, priv->nirq, node, _domain_ops, priv); if (!domain) @@ -195,3 +199,5 @@ ls_extirq_of_init(struct device_node *node, struct device_node *parent) } IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq", ls_extirq_of_init); +IRQCHIP_DECLARE(ls1043a_extirq, "fsl,ls1043a-extirq", ls_extirq_of_init); +IRQCHIP_DECLARE(ls1088a_extirq, "fsl,ls1088a-extirq", ls_extirq_of_init); -- 2.17.1
[PATCH 09/11] arm64: dts: lx2160a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index ae1b113ab162..8de845c08d0d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -540,6 +540,37 @@
little-endian;
};
+ isc: syscon@1f7 {
+ compatible = "fsl,lx2160a-isc", "syscon";
+ reg = <0x0 0x1f7 0x0 0x1>;
+ little-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x1f7 0x1>;
+
+ extirq: interrupt-controller@14 {
+ compatible = "fsl,lx2160a-extirq",
"fsl,ls1088a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x14 4>;
+ interrupt-map =
+ <0 0 GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 GIC_SPI 11
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
+ };
+
tmu: tmu@1f8 {
compatible = "fsl,qoriq-tmu";
reg = <0x0 0x1f8 0x0 0x1>;
--
2.17.1
[PATCH 07/11] arm64: dts: ls208xa: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 3944ef16ec60..cf1af8b8cd5f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -3,7 +3,7 @@
* Device Tree Include file for Freescale Layerscape-2080A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Abhimanyu Saini
*
@@ -153,6 +153,37 @@
little-endian;
};
+ isc: syscon@1f7 {
+ compatible = "fsl,ls2080a-isc", "syscon";
+ reg = <0x0 0x1f7 0x0 0x1>;
+ little-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x1f7 0x1>;
+
+ extirq: interrupt-controller@14 {
+ compatible = "fsl,ls2080a-extirq",
"fsl,ls1088a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x14 4>;
+ interrupt-map =
+ <0 0 GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 GIC_SPI 11
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
+ };
+
tmu: tmu@1f8 {
compatible = "fsl,qoriq-tmu";
reg = <0x0 0x1f8 0x0 0x1>;
--
2.17.1
[PATCH 06/11] arm64: dts: ls1088ardb: fix interrupt line for RTC node
From: Biwen Li
Fix interrupt line for RTC node on ls1088ardb
Signed-off-by: Biwen Li
---
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 5633e59febc3..89c40d3f9a50 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -2,7 +2,7 @@
/*
* Device Tree file for NXP LS1088A RDB Board.
*
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Harninder Rai
*
@@ -51,8 +51,8 @@
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
- /* IRQ10_B */
- interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+ /* IRQ_RTC_B -> IRQ0_B(CPLD) -> IRQ00(CPU),
active low */
+ interrupts-extended = < 0
IRQ_TYPE_LEVEL_LOW>;
};
};
};
--
2.17.1
[PATCH 05/11] arm64: dts: ls1088a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 36a799554620..c8b583cb2b9f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -2,7 +2,7 @@
/*
* Device Tree Include file for NXP Layerscape-1088A family SoC.
*
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Harninder Rai
*
@@ -205,6 +205,37 @@
little-endian;
};
+ isc: syscon@1f7 {
+ compatible = "fsl,ls1088a-isc", "syscon";
+ reg = <0x0 0x1f7 0x0 0x1>;
+ little-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x1f7 0x1>;
+
+ extirq: interrupt-controller@14 {
+ compatible = "fsl,ls1088a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x14 4>;
+ interrupt-map =
+ <0 0 GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 GIC_SPI 11
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
+ };
+
tmu: tmu@1f8 {
compatible = "fsl,qoriq-tmu";
reg = <0x0 0x1f8 0x0 0x1>;
--
2.17.1
Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used ring
Hi Sherry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on soc/for-next linus/master v5.9 next-20201022]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sherry-Sun/Change-vring-space-from-nomal-memory-to-dma-coherent-memory/20201022-131008
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
f3277cbfba763cd2826396521b9296de67cf1bbc
config: i386-randconfig-s002-20201022 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-dirty
#
https://github.com/0day-ci/linux/commit/6ae9d6d36b63c7bb8170f4c0409470d8e7101880
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sherry-Sun/Change-vring-space-from-nomal-memory-to-dma-coherent-memory/20201022-131008
git checkout 6ae9d6d36b63c7bb8170f4c0409470d8e7101880
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/misc/mic/vop/vop_main.c:339:14: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@ expected void *used @@ got
>> void [noderef] __iomem * @@
>> drivers/misc/mic/vop/vop_main.c:339:14: sparse: expected void *used
>> drivers/misc/mic/vop/vop_main.c:339:14: sparse: got void [noderef]
>> __iomem *
>> drivers/misc/mic/vop/vop_main.c:357:35: sparse: sparse: restricted __le64
>> degrades to integer
vim +339 drivers/misc/mic/vop/vop_main.c
289
290 /*
291 * This routine will assign vring's allocated in host/io memory. Code in
292 * virtio_ring.c however continues to access this io memory as if it
were local
293 * memory without io accessors.
294 */
295 static struct virtqueue *vop_find_vq(struct virtio_device *dev,
296 unsigned index,
297 void (*callback)(struct virtqueue
*vq),
298 const char *name, bool ctx)
299 {
300 struct _vop_vdev *vdev = to_vopvdev(dev);
301 struct vop_device *vpdev = vdev->vpdev;
302 struct mic_vqconfig __iomem *vqconfig;
303 struct mic_vqconfig config;
304 struct virtqueue *vq;
305 void __iomem *va;
306 struct _mic_vring_info __iomem *info;
307 void *used;
308 int vr_size, _vr_size, err, magic;
309 u8 type = ioread8(>desc->type);
310
311 if (index >= ioread8(>desc->num_vq))
312 return ERR_PTR(-ENOENT);
313
314 if (!name)
315 return ERR_PTR(-ENOENT);
316
317 /* First assign the vring's allocated in host memory */
318 vqconfig = _vop_vq_config(vdev->desc) + index;
319 memcpy_fromio(, vqconfig, sizeof(config));
320 _vr_size = round_up(vring_size(le16_to_cpu(config.num),
MIC_VIRTIO_RING_ALIGN), 4);
321 vr_size = PAGE_ALIGN(_vr_size + sizeof(struct _mic_vring_info));
322 va = vpdev->hw_ops->remap(vpdev, le64_to_cpu(config.address),
vr_size);
323 if (!va)
324 return ERR_PTR(-ENOMEM);
325 vdev->vr[index] = va;
326 memset_io(va, 0x0, _vr_size);
327
328 info = va + _vr_size;
329 magic = ioread32(>magic);
330
331 if (WARN(magic != MIC_MAGIC + type + index, "magic mismatch")) {
332 err = -EIO;
333 goto unmap;
334 }
335
336 vdev->used_size[index] = PAGE_ALIGN(sizeof(__u16) * 3 +
337 sizeof(struct
vring_used_elem) *
338 le16_to_cpu(config.num));
> 339 used = va + PAGE_ALIGN(sizeof(struct vring_desc) *
> le16_to_cpu(config.num) +
340 sizeof(__u16) * (3 +
le16_to_cpu(config.num)));
341 vdev->used_virt[index] = used;
342 if (!used) {
343 err = -ENOMEM;
344 dev_err(_vop_dev(vdev), "%s %d err %d\n",
345 __func__, __LINE__, err);
346 goto unmap;
347 }
348
349 vq = vop_new_virtqueue(index, le16_to_cpu(config.num), dev,
[PATCH 10/11] arm64: dts: lx2160ardb: fix interrupt line for RTC node
From: Biwen Li
Fix interrupt line for RTC node on lx2160ardb
Signed-off-by: Biwen Li
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 22d0308eb13b..05f977974d11 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -2,7 +2,7 @@
//
// Device Tree file for LX2160ARDB
//
-// Copyright 2018 NXP
+// Copyright 2018-2020 NXP
/dts-v1/;
@@ -151,8 +151,8 @@
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
- // IRQ10_B
- interrupts = <0 150 0x4>;
+ /* IRQ_RTC_B -> IRQ08, active low */
+ interrupts-extended = < 8 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.17.1
Re: [PATCH v6 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
On Thu 2020-10-22 10:36:17, Pavel Pisa wrote: > The device-tree bindings for open-source/open-hardware CAN FD IP core > designed at the Czech Technical University in Prague. > > CTU CAN FD IP core and other CTU CAN bus related projects > listing and documentation page > >http://canbus.pages.fel.cvut.cz/ > > Signed-off-by: Pavel Pisa > Reviewed-by: Rob Herring 1,2: Acked-by: Pavel Machek -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
[PATCH] scsi: mptfusion: Fix null pointer dereferences in mptscsih_remove()
The mptscsih_remove() function triggers a kernel oops if the
Scsi_Host pointer (ioc->sh) is NULL, as can be seen in this syslog:
ioc0: LSI53C1030 B2: Capabilities={Initiator,Target}
Begin: Waiting for root file system ...
scsi host2: error handler thread failed to spawn, error = -4
mptspi: ioc0: WARNING - Unable to register controller with SCSI subsystem
Backtrace:
[<1045b7cc>] mptspi_probe+0x248/0x3d0 [mptspi]
[<40946470>] pci_device_probe+0x1ac/0x2d8
[<40add668>] really_probe+0x1bc/0x988
[<40ade704>] driver_probe_device+0x160/0x218
[<40adee24>] device_driver_attach+0x160/0x188
[<40adef90>] __driver_attach+0x144/0x320
[<40ad7c78>] bus_for_each_dev+0xd4/0x158
[<40adc138>] driver_attach+0x4c/0x80
[<40adb3ec>] bus_add_driver+0x3e0/0x498
[<40ae0130>] driver_register+0xf4/0x298
[<409450c4>] __pci_register_driver+0x78/0xa8
[<0007d248>] mptspi_init+0x18c/0x1c4 [mptspi]
This patch adds the necessary NULL-pointer checks.
Successfully tested on a HP C8000 parisc workstation with buggy SCSI drives.
Signed-off-by: Helge Deller
Cc:
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index 8543f0324d5a..0d1b2b0eb843 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -1176,8 +1176,10 @@ mptscsih_remove(struct pci_dev *pdev)
MPT_SCSI_HOST *hd;
int sz1;
- if((hd = shost_priv(host)) == NULL)
- return;
+ if (host == NULL)
+ hd = NULL;
+ else
+ hd = shost_priv(host);
mptscsih_shutdown(pdev);
@@ -1193,14 +1195,15 @@ mptscsih_remove(struct pci_dev *pdev)
"Free'd ScsiLookup (%d) memory\n",
ioc->name, sz1));
- kfree(hd->info_kbuf);
+ if (hd)
+ kfree(hd->info_kbuf);
/* NULL the Scsi_Host pointer
*/
ioc->sh = NULL;
- scsi_host_put(host);
-
+ if (host)
+ scsi_host_put(host);
mpt_detach(pdev);
}
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On Thu, Oct 22, 2020 at 10:48:59AM +0200, David Hildenbrand wrote: > On 22.10.20 10:40, David Laight wrote: > > From: David Hildenbrand > >> Sent: 22 October 2020 09:35 > >> > >> On 22.10.20 10:26, Greg KH wrote: > >>> On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: > On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > > On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > >> From: David Laight > >> > >> This lets the compiler inline it into import_iovec() generating > >> much better code. > >> > >> Signed-off-by: David Laight > >> Signed-off-by: Christoph Hellwig > >> --- > >> fs/read_write.c | 179 > >> lib/iov_iter.c | 176 +++ > >> 2 files changed, 176 insertions(+), 179 deletions(-) > > > > Strangely, this commit causes a regression in Linus's tree right now. > > > > I can't really figure out what the regression is, only that this commit > > triggers a "large Android system binary" from working properly. There's > > no kernel log messages anywhere, and I don't have any way to strace the > > thing in the testing framework, so any hints that people can provide > > would be most appreciated. > > It's a pure move - modulo changed line breaks in the argument lists > the functions involved are identical before and after that (just checked > that directly, by checking out the trees before and after, extracting two > functions in question from fs/read_write.c and lib/iov_iter.c (before and > after, resp.) and checking the diff between those. > > How certain is your bisection? > >>> > >>> The bisection is very reproducable. > >>> > >>> But, this looks now to be a compiler bug. I'm using the latest version > >>> of clang and if I put "noinline" at the front of the function, > >>> everything works. > >> > >> Well, the compiler can do more invasive optimizations when inlining. If > >> you have buggy code that relies on some unspecified behavior, inlining > >> can change the behavior ... but going over that code, there isn't too > >> much action going on. At least nothing screamed at me. > > > > Apart from all the optimisations that get rid off the 'pass be reference' > > parameters and strange conditional tests. > > Plenty of scope for the compiler getting it wrong. > > But nothing even vaguely illegal. > > Not the first time that people blame the compiler to then figure out > that something else is wrong ... but maybe this time is different :) I agree, I hate to blame the compiler, that's almost never the real problem, but this one sure "feels" like it. I'm running some more tests, trying to narrow things down as just adding a "noinline" to the function that got moved here doesn't work on Linus's tree at the moment because the function was split into multiple functions. Give me a few hours... thanks, greg k-h
Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support
On Wed, Oct 21, 2020 at 08:02:17PM -0700, Richard Cochran wrote: > On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote: > > So how _does_ that work for TI PHYTER? > > > > As far as we understand, the PHYTER appears to autonomously mangle PTP > > packets > > in the following way: > > - subtracting t2 on RX from the correctionField of the Pdelay_Req > > - adding t3 on TX to the correctionField of the Pdelay_Resp > > The Phyter does not support peer-to-peer one step. Ok, that's my mistake for not double-checking, sorry. > The only driver that implements it is ptp_ines.c. > > And *that* driver/HW implements it correctly. Is there documentation available for this timestamping block? I might be missing some data, as the kernel driver is fairly pass-through for the TX timestamping of the Pdelay_Resp, so the hardware might just 'do the right thing'. I believe the answer lies within the timestamper's per-port RX FIFO. Just guessing here, but I suspect that the RX FIFO doesn't get cleared immediately after the host queries it, and the hardware caches the last 100 events from the pool and uses the RX timestamps of Pdelay_Req as t2 in the process of updating the correctionField of Pdelay_Resp on TX. Would that be correct?
Re: [PATCH v2 2/6] spi: cadence-quadspi: Disable the DAC for Intel LGM SoC
On 22/10/20 10:17AM, Ramuthevar, Vadivel MuruganX wrote:
> Hi Pratyush,
>
> On 21/10/2020 11:17 pm, Pratyush Yadav wrote:
> > Hi,
> >
> > On 21/10/20 10:55AM, Ramuthevar,Vadivel MuruganX wrote:
> > > From: Ramuthevar Vadivel Murugan
> > >
> > >
> > > On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
> > > Direct Access Controller(DAC).
> > >
> > > This patch adds a quirk to disable the Direct Access Controller
> > > for data transfer instead it uses indirect data transfer.
> > >
> > > Signed-off-by: Ramuthevar Vadivel Murugan
> > >
> > > ---
> > > drivers/spi/spi-cadence-quadspi.c | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/spi/spi-cadence-quadspi.c
> > > b/drivers/spi/spi-cadence-quadspi.c
> > > index d7b10c46fa70..3d017b484114 100644
> > > --- a/drivers/spi/spi-cadence-quadspi.c
> > > +++ b/drivers/spi/spi-cadence-quadspi.c
> > > @@ -1106,6 +1106,13 @@ static void cqspi_controller_init(struct cqspi_st
> > > *cqspi)
> > > reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
> > > writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
> > > + /* Disable direct access controller */
> > > + if (!cqspi->use_direct_mode) {
> > > + reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
> > > + reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
> > > + writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
> > > + }
> > > +
> >
> > Do you really need to disable the DAC controller? cqspi_read() and
> > cqspi_write() already check for cqspi->use_direct_mode and avoid using
> > direct mode if it is false. While I don't think it would do any harm I'm
> > curious what prompted you to do this instead of just setting the quirk
> > like cdns_qspi does.
> >
> > Anyway, if you do insist on doing it, it does not make any sense to set
> > a bit and then unset it immediately after. The datasheet I have says
> > this bit resets to 1 so the block above the code you added should be
> > removed.
> Thank you for your review comments..
> yes, we need this patch to disable DAC for our SoC to avoid any conflicts in
> future as well since Intel LGM SoC doesn't support DAC at all.
I'm not sure you got my point here. I understand that LGM SoCs don't
support DAC. I'm not arguing if this _patch_ is needed. I'm arguing if
this _hunk_ is needed. Does DAC mode need to be explicitly disabled
here? Why will the check in cqspi_read() and cqspi_write() not be
enough?
My other point is that if you absolutely need to disable DAC mode, then
instead of the code you have added, it would make more sense to do
something like below in cqspi_controller_init(). Because the bit resets
to 1 so the block of code to enable it is useless [0].
--- 8< ---
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index d7ad8b198a11..d2c5d448a944 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -2156,10 +2156,12 @@ static void cqspi_controller_init(struct cqspi_st
*cqspi)
writel(cqspi->fifo_depth * cqspi->fifo_width / 8,
cqspi->iobase + CQSPI_REG_INDIRECTWRWATERMARK);
- /* Enable Direct Access Controller */
- reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
- reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
- writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable Direct Access Controller */
+ if (!cqspi->use_dac_mode) {
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ }
cqspi_controller_enable(cqspi, 1);
}
--- >8 ---
Disclaimer: not tested at all.
[0] Git blames Vignesh for that block of code added in a27f2eaf2b27.
Vignesh, was this simply an oversight or was there any real reason to
set the bit?
> Regards
> Vadivel
> >
> > > cqspi_controller_enable(cqspi, 1);
> > > }
> > > @@ -1388,6 +1395,10 @@ static const struct cqspi_driver_platdata
> > > am654_ospi = {
> > > .quirks = CQSPI_NEEDS_WR_DELAY,
> > > };
> > > +static const struct cqspi_driver_platdata intel_lgm_qspi = {
> > > + .quirks = CQSPI_DISABLE_DAC_MODE,
> > > +};
> > > +
> > > static const struct of_device_id cqspi_dt_ids[] = {
> > > {
> > > .compatible = "cdns,qspi-nor",
> > > @@ -1403,6 +1414,7 @@ static const struct of_device_id cqspi_dt_ids[] = {
> > > },
> > > {
> > > .compatible = "intel,lgm-qspi",
> > > + .data = _lgm_qspi,
> > > },
> > > { /* end of table */ }
> > > };
> >
--
Regards,
Pratyush Yadav
Texas Instruments India
Question on io-wq
Hi Jens Axboe There are some problem in 'io_wqe_worker' thread, when the 'io_wqe_worker' be create and Setting the affinity of CPUs in NUMA nodes, due to CPU hotplug, When the last CPU going down, the 'io_wqe_worker' thread will run anywhere. when the CPU in the node goes online again, we should restore their cpu bindings? Thanks Qiang
Question on io-wq
Hi Jens Axboe There are some problem in 'io_wqe_worker' thread, when the 'io_wqe_worker' be create and Setting the affinity of CPUs in NUMA nodes, due to CPU hotplug, When the last CPU going down, the 'io_wqe_worker' thread will run anywhere. when the CPU in the node goes online again, we should restore their cpu bindings? Thanks Qiang
RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: David Hildenbrand > Sent: 22 October 2020 09:49 ... > >>> But, this looks now to be a compiler bug. I'm using the latest version > >>> of clang and if I put "noinline" at the front of the function, > >>> everything works. > >> > >> Well, the compiler can do more invasive optimizations when inlining. If > >> you have buggy code that relies on some unspecified behavior, inlining > >> can change the behavior ... but going over that code, there isn't too > >> much action going on. At least nothing screamed at me. > > > > Apart from all the optimisations that get rid off the 'pass be reference' > > parameters and strange conditional tests. > > Plenty of scope for the compiler getting it wrong. > > But nothing even vaguely illegal. > > Not the first time that people blame the compiler to then figure out > that something else is wrong ... but maybe this time is different :) Usually down to missing asm 'memory' constraints... Need to read the obj file to see what the compiler did. The code must be 'approximately right' or nothing would run. So I'd guess it has to do with > 8 fragments. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v2 05/10] KVM: VMX: Invalidate hv_tlb_eptp to denote an EPTP mismatch
Sean Christopherson writes:
> On Wed, Oct 21, 2020 at 02:39:20PM +0200, Vitaly Kuznetsov wrote:
>> Sean Christopherson writes:
>>
>> > Drop the dedicated 'ept_pointers_match' field in favor of stuffing
>> > 'hv_tlb_eptp' with INVALID_PAGE to mark it as invalid, i.e. to denote
>> > that there is at least one EPTP mismatch. Use a local variable to
>> > track whether or not a mismatch is detected so that hv_tlb_eptp can be
>> > used to skip redundant flushes.
>> >
>> > No functional change intended.
>> >
>> > Signed-off-by: Sean Christopherson
>> > ---
>> > arch/x86/kvm/vmx/vmx.c | 16
>> > arch/x86/kvm/vmx/vmx.h | 7 ---
>> > 2 files changed, 8 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>> > index 52cb9eec1db3..4dfde8b64750 100644
>> > --- a/arch/x86/kvm/vmx/vmx.c
>> > +++ b/arch/x86/kvm/vmx/vmx.c
>> > @@ -498,13 +498,13 @@ static int hv_remote_flush_tlb_with_range(struct kvm
>> > *kvm,
>> >struct kvm_vmx *kvm_vmx = to_kvm_vmx(kvm);
>> >struct kvm_vcpu *vcpu;
>> >int ret = 0, i;
>> > + bool mismatch;
>> >u64 tmp_eptp;
>> >
>> >spin_lock(_vmx->ept_pointer_lock);
>> >
>> > - if (kvm_vmx->ept_pointers_match != EPT_POINTERS_MATCH) {
>> > - kvm_vmx->ept_pointers_match = EPT_POINTERS_MATCH;
>> > - kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
>> > + if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp)) {
>> > + mismatch = false;
>> >
>> >kvm_for_each_vcpu(i, vcpu, kvm) {
>> >tmp_eptp = to_vmx(vcpu)->ept_pointer;
>> > @@ -515,12 +515,13 @@ static int hv_remote_flush_tlb_with_range(struct kvm
>> > *kvm,
>> >if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp))
>> >kvm_vmx->hv_tlb_eptp = tmp_eptp;
>> >else
>> > - kvm_vmx->ept_pointers_match
>> > - = EPT_POINTERS_MISMATCH;
>> > + mismatch = true;
>> >
>> >ret |= hv_remote_flush_eptp(tmp_eptp, range);
>> >}
>> > - } else if (VALID_PAGE(kvm_vmx->hv_tlb_eptp)) {
>> > + if (mismatch)
>> > + kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
>> > + } else {
>> >ret = hv_remote_flush_eptp(kvm_vmx->hv_tlb_eptp, range);
>> >}
>>
>> Personally, I find double negations like 'mismatch = false' hard to read
>> :-).
>
> Paolo also dislikes double negatives (I just wasted a minute of my life trying
> to work a double negative into that sentence).
>
>> What if we write this all like
>>
>> if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp)) {
>> kvm_vmx->hv_tlb_eptp = to_vmx(vcpu0)->ept_pointer;
>> kvm_for_each_vcpu() {
>> tmp_eptp = to_vmx(vcpu)->ept_pointer;
>> if (!VALID_PAGE(tmp_eptp) || tmp_eptp != kvm_vmx->hv_tlb_eptp)
>> kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
>> if (VALID_PAGE(tmp_eptp))
>> ret |= hv_remote_flush_eptp(tmp_eptp, range);
>> }
>> } else {
>> ret = hv_remote_flush_eptp(kvm_vmx->hv_tlb_eptp, range);
>> }
>>
>> (not tested and I've probably missed something)
>
> It works, but doesn't optimize the case where one or more vCPUs has an invalid
> EPTP. E.g. if vcpuN->ept_pointer is INVALID_PAGE, vcpuN+1..vcpuZ will flush,
> even if they all match. Now, whether or not it's worth optimizing
> that case...
Yea. As KVM is already running on Hyper-V, nesting on top of it is
likely out of question so IMO it's not even worth optimizing...
>
> This is also why I named it "mismatch", i.e. it tracks whether or not there
> was
> a mismatch between valid EPTPs, not that all EPTPs matched.
>
> What about replacing "mismatch" with a counter that tracks the number of
> unique,
> valid PGDs that are encountered?
>
> if (!VALID_PAGE(kvm_vmx->hv_tlb_pgd)) {
> unique_valid_pgd_cnt = 0;
>
> kvm_for_each_vcpu(i, vcpu, kvm) {
> tmp_pgd = to_vmx(vcpu)->hv_tlb_pgd;
> if (!VALID_PAGE(tmp_pgd) ||
> tmp_pgd == kvm_vmx->hv_tlb_pgd)
> continue;
>
> unique_valid_pgd_cnt++;
>
> if (!VALID_PAGE(kvm_vmx->hv_tlb_pgd))
> kvm_vmx->hv_tlb_pgd = tmp_pgd;
>
> if (!ret)
> ret = hv_remote_flush_pgd(tmp_pgd, range);
>
> if (ret && unique_valid_pgd_cnt > 1)
> break;
> }
> if (unique_valid_pgd_cnt > 1)
> kvm_vmx->hv_tlb_pgd = INVALID_PAGE;
> } else {
> ret = hv_remote_flush_pgd(kvm_vmx->hv_tlb_pgd, range);
> }
>
>
> Alternatively, the pgd_cnt adjustment could be used to update hv_tlb_pgd, e.g.
>
> if (++unique_valid_pgd_cnt == 1)
>
Re: [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util()
On Thu, Oct 22, 2020 at 02:02:55PM +0530, Viresh Kumar wrote: > On 16-07-20, 13:56, Peter Zijlstra wrote: > > Another point is that cpu_util() vs turbo is a bit iffy, and to that, > > things like x86-APERF/MPERF and ARM-AMU got mentioned. Those might also > > have the benefit of giving you values that match your own sampling > > interval (100ms), where the sched stuff is PELT (64,32.. based). > > I believe the above stuff is more around additional improvements that > we can do over this change, and probably Lukasz was looking to do > that. > > > So what I've been thinking is that cpufreq drivers ought to be able to > > supply this method, and only when they lack, can the cpufreq-governor > > (schedutil) install a fallback. > > One of the issues I see with this is that schedutil may not be > available in all configurations and it is still absolutely fine to > using the suggested helper to get the energy numbers in such cases, so > we shouldn't really make it scheutil dependent. The only constraint on schedutil is SMP I think; aside from that it should/could always be available. Given the trainwreck here: 20201022071145.gm2...@hirez.programming.kicks-ass.net (you're on Cc), I'm starting to lean more and more towards making it unconditionally available (when SMP). Anybody forcing it off either sets performance (in which case we don't care about energy usage anyway) or they select one of the old (broken) ondemand/conservative things and I don't give a crap.
Re: [PATCH] arm64: dts: imx8m: use generic name for tmu
On Thu, Oct 22, 2020 at 03:21:18PM +0800, peng@nxp.com wrote:
> From: Peng Fan
>
> Per devicetree specification, generic names are recommended
> to be used, such as temperature-sensor.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index b83f400def8b..327f1d44ced9 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -404,7 +404,7 @@ gpio5: gpio@3024 {
> gpio-ranges = < 0 119 30>;
> };
>
> - tmu: tmu@3026 {
> + tmu: temperature-sensor@3026 {
No, TMU is not a temperature-sensor. It does much more. TMU is quite
generic name for this class of device.
Best regards,
Krzysztof
RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: Greg KH > Sent: 22 October 2020 10:02 ... > I'm running some more tests, trying to narrow things down as just adding > a "noinline" to the function that got moved here doesn't work on Linus's > tree at the moment because the function was split into multiple > functions. I was going to look at that once rc2 is in - and the kernel is likely to work. I suspect the split version doesn't get inlined the same way? Which leaves the horrid argument conversion the inline got rid of back there again. Which all rather begs the question of why the compiler doesn't generate the expected code. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH v6 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation
This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FPGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). The CTU CAN FD core emulation send for review for QEMU mainline. Development repository for QEMU emulation - ctu-canfd branch of https://gitlab.fel.cvut.cz/canbus/qemu-canbus More about CAN bus related projects used and developed at CTU FEE on the guidepost page http://canbus.pages.fel.cvut.cz/ . Martin Jerabek (1): can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part. Pavel Pisa (5): dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. dt-bindings: net: can: binding for CTU CAN FD open-source IP core. can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support. can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support. docs: ctucanfd: CTU CAN FD open-source IP core documentation. The version 6 changes: - sent at 2020-10-22 - the driver has been tested with 5.9 bigendian MIPS kernel against QEMU CTU CAN FD model and correct behavior on PCIe virtual board for big-endian system passed - documentation updated to reflect inclusion of SocketCAN FD and CTU CAN FD functional model support into QEMU mainline - the integration for Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board used for SkodaAuto research projects at our university has been clean up by its author (Jaroslav Beran) and published https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd - Xilinx Zynq Microzed MZ_APO based target for automatic test updated to Debian 10 base. The version 5 changes: - sent at 2020-08-15 - correct Kconfig formatting according to Randy Dunlap - silence warnings reported by make W=1 C=1 flags. Changes suggested by Jakub Kicinski - big thanks for core patch review by Pavel Machek resulting in more readability and formating updates - fix power management errors found by Pavel Machek - removed comments from d-t bindings as suggested by Rob Herring - selected ctu,ctucanfd-2 as alternative name to ctu,ctucanfd which allows to bind to actual major HDL core sources version 2.x if for some reason driver adaptation would not work on version read from the core - line length limit relaxed to 100 characters on some cases where it helps to readability The version 4 changes: - sent at 2020-08-04 - changes summary, 169 non-merge commits, 6 driver, 32 IP core sources enhancements and fixes, 58 tests in master and about additional 30 iso-testbench preparation branch. - convert device-tree binding documentation to YAML - QEMU model of CTU CAN FD IP core and generic extension of QEMU CAN bus emulation developed by Jan Charvat. - driver tested on QEMU emulated Malta big-endian MIPS platform and big endian-support fixed. - checkpatch from 5.4 kernel used to cleanup driver formatting - header files generated from IP core IP-Xact description updated to include protocol exception (pex) field. Mechanism to set it from the driver is not provided yet. The version 3 changes: - sent at 2019-12-21 - adapts device tree bindings documentation according to Rob Herring suggestions. - the driver has been separated to individual modules for core support, PCI bus integration and platform, SoC integration. - the FPGA design has been cleaned up and CAN protocol FSM redesigned by Ondrej Ille (the core redesign has been reason to pause attempts to driver submission) - the work from February 2019 on core, test framework and driver 1601 commits in total, 436 commits in the core sources, 144 commits in the driver, 151 documentation, 502 in tests. - not all continuous integration tests updated for latest design version yet https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/pipelines - Zynq hardware in the loop test show no issues for after driver PCI and platform separation and latest VHDL sources updates. - driver code has been periodically tested on 4.18.5-rt3 and 4.19 long term stable kernels. - test of the patches before submission is run on 5.4 kernel - the core has been integrated by Jaroslav Beran into Intel FPGA based SoC used in the tester developed for Skoda auto at Department of Measurement, Faculty of Electrical Engineering, Czech Technical University https://meas.fel.cvut.cz/ . He has contributed feedback and fixes to the project. The version 2 sent at 2019-02-27 The version 1 sent at 2019-02-22 Ondrej Ille has prepared the CTU CAN IP Core sources for new release. We are waiting with it for the driver review, our
Re: [PATCH v2 2/6] spi: cadence-quadspi: Disable the DAC for Intel LGM SoC
Hi,
On 22/10/2020 5:01 pm, Pratyush Yadav wrote:
On 22/10/20 10:17AM, Ramuthevar, Vadivel MuruganX wrote:
Hi Pratyush,
On 21/10/2020 11:17 pm, Pratyush Yadav wrote:
Hi,
On 21/10/20 10:55AM, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).
This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index d7b10c46fa70..3d017b484114 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1106,6 +1106,13 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable direct access controller */
+ if (!cqspi->use_direct_mode) {
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ }
+
Do you really need to disable the DAC controller? cqspi_read() and
cqspi_write() already check for cqspi->use_direct_mode and avoid using
direct mode if it is false. While I don't think it would do any harm I'm
curious what prompted you to do this instead of just setting the quirk
like cdns_qspi does.
Anyway, if you do insist on doing it, it does not make any sense to set
a bit and then unset it immediately after. The datasheet I have says
this bit resets to 1 so the block above the code you added should be
removed.
Thank you for your review comments..
yes, we need this patch to disable DAC for our SoC to avoid any conflicts in
future as well since Intel LGM SoC doesn't support DAC at all.
I'm not sure you got my point here.
Got your point, thanks!
I understand that LGM SoCs don't
support DAC. I'm not arguing if this _patch_ is needed. I'm arguing if
this _hunk_ is needed.
Needed, my previous patches added DAC disabled in cqspi_read() and
cqspi_write() function then Vignesh suggested me to move
cqspi_controller_init() function part so I have add it now.
you are saying that add hunk at the end of cqspi_controller_init().
that's also okay for me, anyhow DAC should be disabled at any case.
Regards
Vadivel
Does DAC mode need to be explicitly disabled
here? Why will the check in cqspi_read() and cqspi_write() not be
enough?
My other point is that if you absolutely need to disable DAC mode, then
instead of the code you have added, it would make more sense to do
something like below in cqspi_controller_init(). Because the bit resets
to 1 so the block of code to enable it is useless [0].
--- 8< ---
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index d7ad8b198a11..d2c5d448a944 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -2156,10 +2156,12 @@ static void cqspi_controller_init(struct cqspi_st
*cqspi)
writel(cqspi->fifo_depth * cqspi->fifo_width / 8,
cqspi->iobase + CQSPI_REG_INDIRECTWRWATERMARK);
- /* Enable Direct Access Controller */
- reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
- reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
- writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable Direct Access Controller */
+ if (!cqspi->use_dac_mode) {
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ }
cqspi_controller_enable(cqspi, 1);
}
--- >8 ---
Disclaimer: not tested at all.
[0] Git blames Vignesh for that block of code added in a27f2eaf2b27.
Vignesh, was this simply an oversight or was there any real reason to
set the bit?
Regards
Vadivel
cqspi_controller_enable(cqspi, 1);
}
@@ -1388,6 +1395,10 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
};
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1403,6 +1414,7 @@ static const struct of_device_id cqspi_dt_ids[] = {
},
{
.compatible = "intel,lgm-qspi",
+ .data = _lgm_qspi,
},
{ /* end of table */ }
};
Re: [PATCH][v2] PM / sysfs: Expose suspend resume driver flags in sysfs
On Thu, Oct 22, 2020 at 04:52:44PM +0800, Chen Yu wrote:
> Currently there are 4 driver flags to control system suspend/resume
> behavior: DPM_FLAG_NO_DIRECT_COMPLETE, DPM_FLAG_SMART_PREPARE,
> DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME. Make these flags
> visible in sysfs as read-only to get a brief understanding of the
> expected behavior of each device during suspend/resume, so as to
> facilitate suspend/resume debugging/tuning.
>
> For example:
> /sys/devices/pci:00/:00:15.1/power/driver_flags:4
> (DPM_FLAG_SMART_SUSPEND)
>
> /sys/devices/pci:00/:00:07.3/power/driver_flags:5
> (DPM_FLAG_NO_DIRECT_COMPLETE | DPM_FLAG_SMART_SUSPEND)
>
> Acked-by: Len Brown
> Signed-off-by: Chen Yu
> ---
> v2: Adding description in Documentation/ABI/testing/sysfs-devices-power
> according to Greg's suggestion.
> --
> Documentation/ABI/testing/sysfs-devices-power | 11 +++
> drivers/base/power/sysfs.c| 29 ++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-power
> b/Documentation/ABI/testing/sysfs-devices-power
> index 1763e64dd152..8ea68639ab3a 100644
> --- a/Documentation/ABI/testing/sysfs-devices-power
> +++ b/Documentation/ABI/testing/sysfs-devices-power
> @@ -269,3 +269,14 @@ Description:
> the current runtime PM status of the device, which may be
> "suspended", "suspending", "resuming", "active", "error" (fatal
> error), or "unsupported" (runtime PM is disabled).
> +
> +What:/sys/devices/.../power/driver_flags
> +Date:October 2020
> +Contact: Chen Yu
> +Description:
> + The /sys/devices/.../driver_flags attribute contains the driver
> + flags to control system suspend/resume. The flag is a
> combination
> + of DPM_FLAG_NO_DIRECT_COMPLETE, DPM_FLAG_SMART_PREPARE,
> + DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME, or 0 if the
> + driver has not set any flag. This attribute is read-only. If
> + CONFIG_PM_ADVANCED_DEBUG is not set this attribute is empty.
You are now exporting random internal kernel values to userspace, so
they are now going to become a userspace API value that you must ensure
works for the next 20+ years.
Are you _SURE_ you want to do this? What is this velue being exported
going to show you? Who is going to use it? For what?
And if you are going to export it to userspace, you need to actually
give userspace the values so that it knows what they are, by moving them
to a uapi file.
And if you do that, you need to name them a lot better...
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index a1474fb67db9..48313a1040a5 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -607,6 +607,13 @@ static ssize_t async_store(struct device *dev, struct
> device_attribute *attr,
>
> static DEVICE_ATTR_RW(async);
>
> +static ssize_t driver_flags_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sysfs_emit(buf, "%x\n", dev->power.driver_flags);
> +}
> +static DEVICE_ATTR_RO(driver_flags);
> +
> #endif /* CONFIG_PM_SLEEP */
> #endif /* CONFIG_PM_ADVANCED_DEBUG */
>
> @@ -691,6 +698,20 @@ static const struct attribute_group
> pm_qos_flags_attr_group = {
> .attrs = pm_qos_flags_attrs,
> };
>
> +static struct attribute *pm_driver_flags_attrs[] = {
> +#ifdef CONFIG_PM_ADVANCED_DEBUG
> +#ifdef CONFIG_PM_SLEEP
> + _attr_driver_flags.attr,
> +#endif
> +#endif
As this is for debugging only, why is it in sysfs and not debugfs?
> + NULL,
> +};
> +
> +static const struct attribute_group pm_driver_flags_attr_group = {
> + .name = power_group_name,
> + .attrs = pm_driver_flags_attrs,
> +};
> +
> int dpm_sysfs_add(struct device *dev)
> {
> int rc;
> @@ -719,11 +740,17 @@ int dpm_sysfs_add(struct device *dev)
> if (rc)
> goto err_wakeup;
> }
> - rc = pm_wakeup_source_sysfs_add(dev);
> + rc = sysfs_merge_group(>kobj, _driver_flags_attr_group);
Ick, really? Why not make it part of the other attribute group? Why
make it a stand-alone one? This feels like extra uneeded work if you
really are going to do this.
thanks,
greg k-h
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On 22.10.20 11:01, Greg KH wrote: > On Thu, Oct 22, 2020 at 10:48:59AM +0200, David Hildenbrand wrote: >> On 22.10.20 10:40, David Laight wrote: >>> From: David Hildenbrand Sent: 22 October 2020 09:35 On 22.10.20 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: From: David Laight This lets the compiler inline it into import_iovec() generating much better code. Signed-off-by: David Laight Signed-off-by: Christoph Hellwig --- fs/read_write.c | 179 lib/iov_iter.c | 176 +++ 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. >>> >>> Apart from all the optimisations that get rid off the 'pass be reference' >>> parameters and strange conditional tests. >>> Plenty of scope for the compiler getting it wrong. >>> But nothing even vaguely illegal. >> >> Not the first time that people blame the compiler to then figure out >> that something else is wrong ... but maybe this time is different :) > > I agree, I hate to blame the compiler, that's almost never the real > problem, but this one sure "feels" like it. > > I'm running some more tests, trying to narrow things down as just adding > a "noinline" to the function that got moved here doesn't work on Linus's > tree at the moment because the function was split into multiple > functions. > > Give me a few hours... I might be wrong but a) import_iovec() uses: - unsigned nr_segs -> int - unsigned fast_segs -> int b) rw_copy_check_uvector() uses: - unsigned long nr_segs -> long - unsigned long fast_seg -> long So when calling rw_copy_check_uvector(), we have to zero-extend the registers used for passing the arguments. That's definitely done when calling the function explicitly. Maybe when inlining something is messed up? Just a thought ... -- Thanks, David / dhildenb
[sparc64] lockdep: Fix lockdep recursion - call trace
Hello!
Bisected the following linux calltrace after v5.9 :
[8.650198] systemd[1]: Started Journal Service.
[9.028125] [ cut here ]
[9.028171] WARNING: CPU: 11 PID: 499 at
net/netfilter/nf_tables_api.c:622 nft_chain_parse_hook+0x7c/0x360
[nf_tables]
[9.028185] Modules linked in: nf_tables nfnetlink sunrpc ip_tables
x_tables ipv6 crc_ccitt autofs4 ext4 crc16 mbcache jbd2 raid10 raid456
async_raid6_recov async_mem
cpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath
linear md_mod crc32c_sparc64
[9.028243] CPU: 11 PID: 499 Comm: nft Tainted: GW
5.9.0-rc8-00209-gbaffd723e44d #111
[9.028255] Call Trace:
[9.028269] [<004727e8>] __warn+0xa8/0x120
[9.028278] [<00472c20>] warn_slowpath_fmt+0x34/0x74
[9.028291] [<100c19fc>] nft_chain_parse_hook+0x7c/0x360 [nf_tables]
[9.028305] [<100c4ca8>]
nf_tables_addchain.constprop.0+0x48/0x5a0 [nf_tables]
[9.028320] [<100c5908>] nf_tables_newchain+0x708/0x820 [nf_tables]
[9.028331] [<100ae9c4>] nfnetlink_rcv_batch+0x4a4/0x780 [nfnetlink]
[9.028341] [<100aedb0>] nfnetlink_rcv+0x110/0x140 [nfnetlink]
[9.028353] [<00b2acb0>] netlink_unicast+0x150/0x2a0
[9.028362] [<00b2bc1c>] netlink_sendmsg+0x3dc/0x460
[9.028374] [<00a96f14>] sock_sendmsg+0x34/0x80
[9.028382] [<00a985ec>] sys_sendmsg+0x1ac/0x220
[9.028392] [<00a9a688>] ___sys_sendmsg+0x48/0x80
[9.028400] [<00a9a768>] __sys_sendmsg+0x48/0x80
[9.028409] [<00a9a7b8>] sys_sendmsg+0x18/0x40
[9.028419] [<004062b4>] linux_sparc_syscall+0x34/0x44
[9.028428] irq event stamp: 0
[9.028437] hardirqs last enabled at (0): [<>] 0x0
[9.028447] hardirqs last disabled at (0): [<004703f8>]
copy_process+0x738/0x1840
[9.028459] softirqs last enabled at (0): [<004703f8>]
copy_process+0x738/0x1840
[9.028470] softirqs last disabled at (0): [<>] 0x0
[9.028479] ---[ end trace 87e5247a47db0aa8 ]---
[ 10.691838] sha1_sparc64: Using sparc64 sha1 opcode optimized SHA-1
implementation
git commit id:
$ git bisect good
4d004099a668c41522242aa146a38cc4eb59cb1e is the first bad commit
commit 4d004099a668c41522242aa146a38cc4eb59cb1e
Author: Peter Zijlstra
Date: Fri Oct 2 11:04:21 2020 +0200
lockdep: Fix lockdep recursion
Steve reported that lockdep_assert*irq*(), when nested inside lockdep
itself, will trigger a false-positive.
One example is the stack-trace code, as called from inside lockdep,
triggering tracing, which in turn calls RCU, which then uses
lockdep_assert_irqs_disabled().
Fixes: a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context}
to per-cpu variables")
Reported-by: Steven Rostedt
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
include/linux/lockdep.h | 13 ---
kernel/locking/lockdep.c | 99 +---
2 files changed, 67 insertions(+), 45 deletions(-)
full bisect log:
$ git bisect log
git bisect start
# bad: [7cf726a59435301046250c42131554d9ccc566b8] Merge tag
'linux-kselftest-kunit-5.10-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
git bisect bad 7cf726a59435301046250c42131554d9ccc566b8
# good: [bbf5c979011a099af5dc76498918ed7df445635b] Linux 5.9
git bisect good bbf5c979011a099af5dc76498918ed7df445635b
# bad: [726eb70e0d34dc4bc4dada71f52bba8ed638431e] Merge tag
'char-misc-5.10-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad 726eb70e0d34dc4bc4dada71f52bba8ed638431e
# bad: [527f6750d92beb9c787d8aba48477b1e834d64e5] kasan: remove
mentions of unsupported Clang versions
git bisect bad 527f6750d92beb9c787d8aba48477b1e834d64e5
# bad: [647412daeb454b6dad12a6c6961ab90aac9e5d29] Merge tag
'mmc-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 647412daeb454b6dad12a6c6961ab90aac9e5d29
# bad: [3bff6112c80cecb76af5fe485506f96e8adb6122] Merge tag
'perf-core-2020-10-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 3bff6112c80cecb76af5fe485506f96e8adb6122
# good: [f5f59336a9ae8f683772d6b8cb2d6732b5e567ea] Merge tag
'timers-core-2020-10-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good f5f59336a9ae8f683772d6b8cb2d6732b5e567ea
# good: [edaa5ddf3833669a25654d42c0fb653dfdd906df] Merge tag
'sched-core-2020-10-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good edaa5ddf3833669a25654d42c0fb653dfdd906df
# bad: [e6412f9833db23740ee848ab3d6e7af18dff82a6] Merge tag
'efi-core-2020-10-12' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad e6412f9833db23740ee848ab3d6e7af18dff82a6
# bad: [e705d397965811ac528d7213b42d74ffe43caf38] Merge branch
'locking/urgent' into locking/core, to pick up fixes
git bisect bad
Re: [PATCH 1/2] x86: Conditional init of pcengines leds/keys gpios
On 21.10.20 23:41, Ed Wildgoose wrote:
Hi,
> The pcengines bios/firmware includes ACPI tables (since 4.10.0.1) which
> will cause the kernel to automatically create led + gpio_key devices for
> the platform. This means that the platform setup now creates duplicates
> of all these led/key devices.
>
> Driver conditionally initialises leds/keys only for older bios.
still breaks existing userlands as device names change - LEDs as well as
keys, and keycodes also change.
IOW: userland needs to be depending on specific BIOS versions.
--mtx
>
> Signed-off-by: Ed Wildgoose
> ---
> drivers/platform/x86/pcengines-apuv2.c | 115 +++--
> 1 file changed, 90 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/platform/x86/pcengines-apuv2.c
> b/drivers/platform/x86/pcengines-apuv2.c
> index c37349f97..45f7a89de 100644
> --- a/drivers/platform/x86/pcengines-apuv2.c
> +++ b/drivers/platform/x86/pcengines-apuv2.c
> @@ -128,6 +128,18 @@ static struct gpiod_lookup_table gpios_key_table = {
>
> /* Board setup */
>
> +struct apu_driver_data {
> + const struct amd_fch_gpio_pdata *board_data;
> + const struct gpio_keys_platform_data *apu_keys_pdata;
> + const struct gpio_led_platform_data *apu_leds_pdata;
> +};
> +
> +static struct apu_driver_data apu2_driver_data = {
> + .board_data = _apu2,
> + .apu_keys_pdata = _keys_pdata,
> + .apu_leds_pdata = _leds_pdata
> +};
> +
> /* Note: matching works on string prefix, so "apu2" must come before "apu" */
> static const struct dmi_system_id apu_gpio_dmi_table[] __initconst = {
>
> @@ -138,7 +150,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "APU2")
> },
> - .driver_data= (void *)_apu2,
> + .driver_data= (void *)_driver_data,
> },
> /* APU2 w/ legacy BIOS >= 4.0.8 */
> {
> @@ -147,7 +159,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "apu2")
> },
> - .driver_data= (void *)_apu2,
> + .driver_data= (void *)_driver_data,
> },
> /* APU2 w/ mainline BIOS */
> {
> @@ -156,7 +168,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "PC Engines apu2")
> },
> - .driver_data= (void *)_apu2,
> + .driver_data= (void *)_driver_data,
> },
>
> /* APU3 w/ legacy BIOS < 4.0.8 */
> @@ -166,7 +178,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "APU3")
> },
> - .driver_data = (void *)_apu2,
> + .driver_data = (void *)_driver_data,
> },
> /* APU3 w/ legacy BIOS >= 4.0.8 */
> {
> @@ -175,7 +187,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "apu3")
> },
> - .driver_data = (void *)_apu2,
> + .driver_data = (void *)_driver_data,
> },
> /* APU3 w/ mainline BIOS */
> {
> @@ -184,7 +196,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "PC Engines apu3")
> },
> - .driver_data = (void *)_apu2,
> + .driver_data = (void *)_driver_data,
> },
> /* APU4 w/ legacy BIOS < 4.0.8 */
> {
> @@ -193,7 +205,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "APU4")
> },
> - .driver_data = (void *)_apu2,
> + .driver_data = (void *)_driver_data,
> },
> /* APU4 w/ legacy BIOS >= 4.0.8 */
> {
> @@ -202,7 +214,7 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
> DMI_MATCH(DMI_BOARD_NAME, "apu4")
> },
> - .driver_data = (void *)_apu2,
> + .driver_data = (void *)_driver_data,
> },
> /* APU4 w/ mainline BIOS */
> {
> @@ -211,11 +223,42 @@ static const struct dmi_system_id apu_gpio_dmi_table[]
> __initconst = {
> DMI_MATCH(DMI_SYS_VENDOR, "PC Engines"),
>
Re: [PATCH] gpio: bd70528: remove unneeded break
Hello, On Wed, 2020-10-21 at 07:39 -0700, Joe Perches wrote: > On Wed, 2020-10-21 at 07:25 +, Vaittinen, Matti wrote: > > Hello Joe & All, > > On Tue, 2020-10-20 at 11:36 -0700, Joe Perches wrote: > > > On Tue, 2020-10-20 at 11:48 +, Vaittinen, Matti wrote: > [] > > > > And for peeps who have not been following - following function > > > > triggers the checkpatch error above: > > > > > > Huh? what version of checkpatch are you using? > > > Send it to me please. > [] > > Please find my version of checkpatch and the patch to trigger the > > warning attached. > > Thanks. This test wasn't particularly useful > (and had some false positives) and was removed by > > commit ef3c005c0eb07a60949191bc6ee407d5f43cc502 > Author: Joe Perches > Date: Tue Aug 11 18:35:19 2020 -0700 > > checkpatch: remove missing switch/case break test > > This test doesn't work well and newer compilers are much better > at emitting this warning. > > Signed-off-by: Joe Perches > Signed-off-by: Andrew Morton > Cc: Cambda Zhu > Link: > http://lkml.kernel.org/r/7e25090c79f6a69d502ab8219863300790192fe2.ca...@perches.com > Signed-off-by: Linus Torvalds > Thanks for checking this Joe! And note to self - always check with newest kernel... ;) (Sorry for bothering) Br, Matti Vaittinen
Re: [PATCH] x86/alternative: don't call text_poke() in lazy TLB mode
On 09.10.20 16:42, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can be problematic in case kernel code is being modified via
text_poke() in a kernel thread, and on another processor exit_mmap()
is active for the process which was running on the first cpu before
the kernel thread.
As text_poke() is using a temporary address space and the former
address space (obtained via cpu_tlbstate.loaded_mm) is restored
afterwards, there is a race possible in case the cpu on which
exit_mmap() is running wants to make sure there are no stale
references to that address space on any cpu active (this e.g. is
required when running as a Xen PV guest, where this problem has been
observed and analyzed).
In order to avoid that, drop off TLB lazy mode before switching to the
temporary address space.
Fixes: cefa929c034eb5d ("x86/mm: Introduce temporary mm structs")
Signed-off-by: Juergen Gross
Can anyone look at this, please? It is fixing a real problem which has
been seen several times.
Juergen
---
arch/x86/kernel/alternative.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index cdaab30880b9..cd6be6f143e8 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -807,6 +807,15 @@ static inline temp_mm_state_t use_temporary_mm(struct
mm_struct *mm)
temp_mm_state_t temp_state;
lockdep_assert_irqs_disabled();
+
+ /*
+* Make sure not to be in TLB lazy mode, as otherwise we'll end up
+* with a stale address space WITHOUT being in lazy mode after
+* restoring the previous mm.
+*/
+ if (this_cpu_read(cpu_tlbstate.is_lazy))
+ leave_mm(smp_processor_id());
+
temp_state.mm = this_cpu_read(cpu_tlbstate.loaded_mm);
switch_mm_irqs_off(NULL, mm, current);
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On 22.10.20 11:19, David Hildenbrand wrote: > On 22.10.20 11:01, Greg KH wrote: >> On Thu, Oct 22, 2020 at 10:48:59AM +0200, David Hildenbrand wrote: >>> On 22.10.20 10:40, David Laight wrote: From: David Hildenbrand > Sent: 22 October 2020 09:35 > > On 22.10.20 10:26, Greg KH wrote: >> On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >>> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > From: David Laight > > This lets the compiler inline it into import_iovec() generating > much better code. > > Signed-off-by: David Laight > Signed-off-by: Christoph Hellwig > --- > fs/read_write.c | 179 > > lib/iov_iter.c | 176 +++ > 2 files changed, 176 insertions(+), 179 deletions(-) Strangely, this commit causes a regression in Linus's tree right now. I can't really figure out what the regression is, only that this commit triggers a "large Android system binary" from working properly. There's no kernel log messages anywhere, and I don't have any way to strace the thing in the testing framework, so any hints that people can provide would be most appreciated. >>> >>> It's a pure move - modulo changed line breaks in the argument lists >>> the functions involved are identical before and after that (just checked >>> that directly, by checking out the trees before and after, extracting >>> two >>> functions in question from fs/read_write.c and lib/iov_iter.c (before >>> and >>> after, resp.) and checking the diff between those. >>> >>> How certain is your bisection? >> >> The bisection is very reproducable. >> >> But, this looks now to be a compiler bug. I'm using the latest version >> of clang and if I put "noinline" at the front of the function, >> everything works. > > Well, the compiler can do more invasive optimizations when inlining. If > you have buggy code that relies on some unspecified behavior, inlining > can change the behavior ... but going over that code, there isn't too > much action going on. At least nothing screamed at me. Apart from all the optimisations that get rid off the 'pass be reference' parameters and strange conditional tests. Plenty of scope for the compiler getting it wrong. But nothing even vaguely illegal. >>> >>> Not the first time that people blame the compiler to then figure out >>> that something else is wrong ... but maybe this time is different :) >> >> I agree, I hate to blame the compiler, that's almost never the real >> problem, but this one sure "feels" like it. >> >> I'm running some more tests, trying to narrow things down as just adding >> a "noinline" to the function that got moved here doesn't work on Linus's >> tree at the moment because the function was split into multiple >> functions. >> >> Give me a few hours... > > I might be wrong but > > a) import_iovec() uses: > - unsigned nr_segs -> int > - unsigned fast_segs -> int > b) rw_copy_check_uvector() uses: > - unsigned long nr_segs -> long > - unsigned long fast_seg -> long > > So when calling rw_copy_check_uvector(), we have to zero-extend the > registers used for passing the arguments. That's definitely done when > calling the function explicitly. Maybe when inlining something is messed up? > > Just a thought ... > ... especially because I recall that clang and gcc behave slightly differently: https://github.com/hjl-tools/x86-psABI/issues/2 "Function args are different: narrow types are sign or zero extended to 32 bits, depending on their type. clang depends on this for incoming args, but gcc doesn't make that assumption. But both compilers do it when calling, so gcc code can call clang code. The upper 32 bits of registers are always undefined garbage for types smaller than 64 bits." Again, just a thought. -- Thanks, David / dhildenb
Re: [PATCH 1/2] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf()
On 10/22/20 9:02 AM, Sai Prakash Ranjan wrote: On 2020-10-21 15:38, Suzuki Poulose wrote: On 10/21/20 8:29 AM, Sai Prakash Ranjan wrote: On 2020-10-20 21:40, Sai Prakash Ranjan wrote: On 2020-10-14 21:29, Sai Prakash Ranjan wrote: On 2020-10-14 18:46, Suzuki K Poulose wrote: On 10/14/2020 10:36 AM, Sai Prakash Ranjan wrote: On 2020-10-13 22:05, Suzuki K Poulose wrote: On 10/07/2020 02:00 PM, Sai Prakash Ranjan wrote: There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink and not ETR. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in tmc_enable_etf_sink_perf() and with owner being NULL, we get a NULL pointer dereference. Looking at the ETR and other places in the kernel, ETF and the ETB are the only places trying to dereference the task(owner) in tmc_enable_etf_sink_perf() which is also called from the sched_in path as in the call trace. Owner(task) is NULL even in the case of ETR in tmc_enable_etr_sink_perf(), but since we cache the PID in alloc_buffer() callback and it is done as part of etm_setup_aux() when allocating buffer for ETR sink, we never dereference this NULL pointer and we are safe. So lets do the The patch is necessary to fix some of the issues. But I feel it is not complete. Why is it safe earlier and not later ? I believe we are simply reducing the chances of hitting the issue, by doing this earlier than later. I would say we better fix all instances to make sure that the event->owner is valid. (e.g, I can see that the for kernel events event->owner == -1 ?) struct task_struct *tsk = READ_ONCE(event->owner); if (!tsk || is_kernel_event(event)) /* skip ? */ Looking at it some more, is_kernel_event() is not exposed outside events core and probably for good reason. Why do we need to check for this and not just tsk? Because the event->owner could be : = NULL = -1UL // kernel event = valid. Yes I understood that part, but here we were trying to fix the NULL pointer dereference right and hence the question as to why we need to check for kernel events? I am no expert in perf but I don't see anywhere in the kernel checking for is_kernel_event(), so I am a bit skeptical if exporting that is actually right or not. I have stress tested with the original patch many times now, i.e., without a check for event->owner and is_kernel_event() and didn't observe any crash. Plus on ETR where this was already done, no crashes were reported till date and with ETF, the issue was quickly reproducible, so I am fairly confident that this doesn't just delay the original issue but actually fixes it. I will run an overnight test again to confirm this. I ran the overnight test which collected aroung 4G data(see below), with the following small change to see if the two cases (event->owner=NULL and is_kernel_event()) are triggered with suggested changes and it didn't trigger at all. Do we still need those additional checks? Yes. Please see perf_event_create_kernel_event(), which is an exported function allowing any kernel code (including modules) to use the PMU (just like the userspace perf tool would do). Just because your use case doesn't trigger this (because you don't run something that can trigger this) doesn't mean this can't be triggered. Thanks for that pointer, I will add them in the next version. And instead of redefining TASK_TOMBSTONE in the driver, you may simply use IS_ERR_OR_NULL(tsk) to cover both NULL case and kernel event. Cheers Suzuki
RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: David Hildenbrand > Sent: 22 October 2020 10:19 > > On 22.10.20 11:01, Greg KH wrote: > > On Thu, Oct 22, 2020 at 10:48:59AM +0200, David Hildenbrand wrote: > >> On 22.10.20 10:40, David Laight wrote: > >>> From: David Hildenbrand > Sent: 22 October 2020 09:35 > > On 22.10.20 10:26, Greg KH wrote: > > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: > >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: > >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > From: David Laight > > This lets the compiler inline it into import_iovec() generating > much better code. > > Signed-off-by: David Laight > Signed-off-by: Christoph Hellwig > --- > fs/read_write.c | 179 > > lib/iov_iter.c | 176 > +++ > 2 files changed, 176 insertions(+), 179 deletions(-) > >>> > >>> Strangely, this commit causes a regression in Linus's tree right now. > >>> > >>> I can't really figure out what the regression is, only that this > >>> commit > >>> triggers a "large Android system binary" from working properly. > >>> There's > >>> no kernel log messages anywhere, and I don't have any way to strace > >>> the > >>> thing in the testing framework, so any hints that people can provide > >>> would be most appreciated. > >> > >> It's a pure move - modulo changed line breaks in the argument lists > >> the functions involved are identical before and after that (just > >> checked > >> that directly, by checking out the trees before and after, extracting > >> two > >> functions in question from fs/read_write.c and lib/iov_iter.c (before > >> and > >> after, resp.) and checking the diff between those. > >> > >> How certain is your bisection? > > > > The bisection is very reproducable. > > > > But, this looks now to be a compiler bug. I'm using the latest version > > of clang and if I put "noinline" at the front of the function, > > everything works. > > Well, the compiler can do more invasive optimizations when inlining. If > you have buggy code that relies on some unspecified behavior, inlining > can change the behavior ... but going over that code, there isn't too > much action going on. At least nothing screamed at me. > >>> > >>> Apart from all the optimisations that get rid off the 'pass be reference' > >>> parameters and strange conditional tests. > >>> Plenty of scope for the compiler getting it wrong. > >>> But nothing even vaguely illegal. > >> > >> Not the first time that people blame the compiler to then figure out > >> that something else is wrong ... but maybe this time is different :) > > > > I agree, I hate to blame the compiler, that's almost never the real > > problem, but this one sure "feels" like it. > > > > I'm running some more tests, trying to narrow things down as just adding > > a "noinline" to the function that got moved here doesn't work on Linus's > > tree at the moment because the function was split into multiple > > functions. > > > > Give me a few hours... > > I might be wrong but > > a) import_iovec() uses: > - unsigned nr_segs -> int > - unsigned fast_segs -> int > b) rw_copy_check_uvector() uses: > - unsigned long nr_segs -> long > - unsigned long fast_seg -> long > > So when calling rw_copy_check_uvector(), we have to zero-extend the > registers used for passing the arguments. That's definitely done when > calling the function explicitly. Maybe when inlining something is messed up? That's also not needed on x86-64 - the high bits get cleared by 32bit writes. But, IIRC, arm64 leaves them unchanged or undefined. I guessing that every array access uses a *(Rx + Ry) addressing mode. So indexing an array even with 'unsigned int' requires an explicit zero-extend on arm64? (x86-64 ends up with an explicit sign extend when indexing an array with 'signed int'.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH v3 2/3] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
From: Mathieu Desnoyers
The placeholder for instruction selection should use the second
argument's operand, which is %1, not %0. This could generate incorrect
assembly code if the memory addressing of operand %0 is a different
form from that of operand %1.
Also remove the %Un placeholder because having %Un placeholders
for two operands which are based on the same local var (ptep) doesn't
make much sense. By the way, it doesn't change the current behaviour
because "<>" constraint is missing for the associated "=m".
Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
Signed-off-by: Mathieu Desnoyers
Cc: Christophe Leroy
Cc: Kumar Gala
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
Cc: # v2.6.28+
Acked-by: Segher Boessenkool
[chleroy: revised commit log iaw segher's comments and removed %U0]
Signed-off-by: Christophe Leroy
---
v3: Remove %Un
v2: Changed commit log.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 4 ++--
arch/powerpc/include/asm/nohash/pgtable.h| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 36443cda8dcf..41d8bc6db303 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -522,9 +522,9 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
if (pte_val(*ptep) & _PAGE_HASHPTE)
flush_hash_entry(mm, ptep, addr);
__asm__ __volatile__("\
- stw%U0%X0 %2,%0\n\
+ stw%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index 6277e7596ae5..ac75f4ab0dba 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -192,9 +192,9 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
*/
if (IS_ENABLED(CONFIG_PPC32) && IS_ENABLED(CONFIG_PTE_64BIT) &&
!percpu) {
__asm__ __volatile__("\
- stw%U0%X0 %2,%0\n\
+ stw%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
return;
--
2.25.0
[PATCH v3 1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9
GCC 4.9 sometimes fails to build with "m<>" constraint in
inline assembly.
CC lib/iov_iter.o
In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
from ./arch/powerpc/include/asm/atomic.h:11,
from ./include/linux/atomic.h:7,
from ./include/linux/crypto.h:15,
from ./include/crypto/hash.h:11,
from lib/iov_iter.c:2:
lib/iov_iter.c: In function 'iovec_from_user.part.30':
./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has impossible
constraints
__asm__ __volatile__(\
^
./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro
'unsafe_op_wrap'
#define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
^
./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro
'__get_user_asm'
case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
^
./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro
'__get_user_size_allowed'
__get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
^
./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro
'__get_user_nocheck'
__get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
^
./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro
'__get_user_allowed'
#define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
^
lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
unsafe_get_user(len, [i].iov_len, uaccess_end);
^
make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
Define a UPD_CONSTR macro that is "<>" by default and
only "" with GCC prior to GCC 5.
Fixes: fcf1f26895a4 ("powerpc/uaccess: Add pre-update addressing to
__put_user_asm_goto()")
Fixes: 2f279eeb68b8 ("powerpc/uaccess: Add pre-update addressing to
__get_user_asm() and __put_user_asm()")
Signed-off-by: Christophe Leroy
Acked-by: Segher Boessenkool
---
v2: Moved UPD_CONSTR to asm-const.h to avoid circular inclusion issues with
patch 3.
---
arch/powerpc/include/asm/asm-const.h | 13 +
arch/powerpc/include/asm/uaccess.h | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/asm-const.h
b/arch/powerpc/include/asm/asm-const.h
index 082c1538c562..0ce2368bd20f 100644
--- a/arch/powerpc/include/asm/asm-const.h
+++ b/arch/powerpc/include/asm/asm-const.h
@@ -11,4 +11,17 @@
# define __ASM_CONST(x) x##UL
# define ASM_CONST(x) __ASM_CONST(x)
#endif
+
+/*
+ * Inline assembly memory constraint
+ *
+ * GCC 4.9 doesn't properly handle pre update memory constraint "m<>"
+ *
+ */
+#if defined(GCC_VERSION) && GCC_VERSION < 5
+#define UPD_CONSTR ""
+#else
+#define UPD_CONSTR "<>"
+#endif
+
#endif /* _ASM_POWERPC_ASM_CONST_H */
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 604d705f1bb8..8f27ea48fadb 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -223,7 +223,7 @@ do {
\
"1: " op "%U1%X1 %0,%1 # put_user\n" \
EX_TABLE(1b, %l2) \
: \
- : "r" (x), "m<>" (*addr)\
+ : "r" (x), "m"UPD_CONSTR (*addr)\
: \
: label)
@@ -294,7 +294,7 @@ extern long __get_user_bad(void);
".previous\n" \
EX_TABLE(1b, 3b)\
: "=r" (err), "=r" (x) \
- : "m<>" (*addr), "i" (-EFAULT), "0" (err))
+ : "m"UPD_CONSTR (*addr), "i" (-EFAULT), "0" (err))
#ifdef __powerpc64__
#define __get_user_asm2(x, addr, err) \
--
2.25.0
[PATCH v3 3/3] powerpc: Fix update form addressing in inline assembly
In several places, inline assembly uses the "%Un" modifier
to enable the use of instruction with update form addressing,
but the associated "<>" constraint is missing.
As mentioned in previous patch, this fails with gcc 4.9, so
"<>" can't be used directly.
Use UPD_CONSTR macro everywhere %Un modifier is used.
Signed-off-by: Christophe Leroy
Reviewed-by: Segher Boessenkool
---
v3: __set_pte_at() not impacted anymore (%U0 removed in previous patch)
v2: Build failure (circular inclusion) fixed by change in patch 1
---
arch/powerpc/include/asm/atomic.h | 9 +
arch/powerpc/include/asm/io.h | 4 ++--
arch/powerpc/kvm/powerpc.c| 4 ++--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 8a55eb8cc97b..61c6e8b200e8 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/*
* Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
@@ -26,14 +27,14 @@ static __inline__ int atomic_read(const atomic_t *v)
{
int t;
- __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
+ __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) :
"m"UPD_CONSTR(v->counter));
return t;
}
static __inline__ void atomic_set(atomic_t *v, int i)
{
- __asm__ __volatile__("stw%U0%X0 %1,%0" : "=m"(v->counter) : "r"(i));
+ __asm__ __volatile__("stw%U0%X0 %1,%0" : "=m"UPD_CONSTR(v->counter) :
"r"(i));
}
#define ATOMIC_OP(op, asm_op) \
@@ -316,14 +317,14 @@ static __inline__ s64 atomic64_read(const atomic64_t *v)
{
s64 t;
- __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
+ __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) :
"m"UPD_CONSTR(v->counter));
return t;
}
static __inline__ void atomic64_set(atomic64_t *v, s64 i)
{
- __asm__ __volatile__("std%U0%X0 %1,%0" : "=m"(v->counter) : "r"(i));
+ __asm__ __volatile__("std%U0%X0 %1,%0" : "=m"UPD_CONSTR(v->counter) :
"r"(i));
}
#define ATOMIC64_OP(op, asm_op)
\
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 58635960403c..87964dfb838e 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -122,7 +122,7 @@ static inline u##size name(const volatile u##size __iomem
*addr)\
{ \
u##size ret;\
__asm__ __volatile__("sync;"#insn"%U1%X1 %0,%1;twi 0,%0,0;isync"\
- : "=r" (ret) : "m" (*addr) : "memory"); \
+ : "=r" (ret) : "m"UPD_CONSTR (*addr) : "memory"); \
return ret; \
}
@@ -130,7 +130,7 @@ static inline u##size name(const volatile u##size __iomem
*addr)\
static inline void name(volatile u##size __iomem *addr, u##size val) \
{ \
__asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0" \
- : "=m" (*addr) : "r" (val) : "memory"); \
+ : "=m"UPD_CONSTR (*addr) : "r" (val) : "memory"); \
mmiowb_set_pending(); \
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 13999123b735..cf52d26f49cd 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1087,7 +1087,7 @@ static inline u64 sp_to_dp(u32 fprs)
preempt_disable();
enable_kernel_fp();
- asm ("lfs%U1%X1 0,%1; stfd%U0%X0 0,%0" : "=m" (fprd) : "m" (fprs)
+ asm ("lfs%U1%X1 0,%1; stfd%U0%X0 0,%0" : "=m"UPD_CONSTR (fprd) :
"m"UPD_CONSTR (fprs)
: "fr0");
preempt_enable();
return fprd;
@@ -1099,7 +1099,7 @@ static inline u32 dp_to_sp(u64 fprd)
preempt_disable();
enable_kernel_fp();
- asm ("lfd%U1%X1 0,%1; stfs%U0%X0 0,%0" : "=m" (fprs) : "m" (fprd)
+ asm ("lfd%U1%X1 0,%1; stfs%U0%X0 0,%0" : "=m"UPD_CONSTR (fprs) :
"m"UPD_CONSTR (fprd)
: "fr0");
preempt_enable();
return fprs;
--
2.25.0
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote:
> On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
> > > > The dynamic loader has to process the LOAD segments to get to the ELF
> > > > note that says to enable BTI. Maybe we could do a first pass and load
> > > > only the segments that cover notes. But that requires lots of changes
> > > > to generic code in the loader.
> > >
> > > What if the loader always enabled BTI for PROT_EXEC pages, but then when
> > > discovering that this was a mistake, mprotect() the pages without BTI?
> > > Then
> > > both BTI and MDWX would work and the penalty of not getting MDWX would
> > > fall
> > > to non-BTI programs. What's the expected proportion of BTI enabled code
> > > vs.
> > > disabled in the future, is it perhaps expected that a distro would enable
> > > the flag globally so eventually only a few legacy programs might be
> > > unprotected?
> >
> > i thought mprotect(PROT_EXEC) would get filtered
> > with or without bti, is that not the case?
>
> We can adjust the filter in systemd to match any combination of
> flags to allow and to deny.
Yes but Szabolcs' point to Topi was that if we can adjust the filters to
allow mprotect(PROT_EXEC), why not allow mprotect(PROT_EXEC|PROT_BTI)
instead? Anyway, I see the MDWX and BTI as complementary policies so
ideally we shouldn't have to choose between one or the other. If we
allow mprotect(PROT_EXEC), that would override MDWX and also disable
BTI.
IIUC, the problem is with the main executable which is mapped by the
kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but
does not have the original file descriptor to be able to remap. Its only
choice is mprotect() and this fails because of the MDWX policy.
Not sure whether the kernel has the right information but could it map
the main executable with PROT_BTI if the corresponding PT_GNU_PROPERTY
is found? The current ABI states it only sets PROT_BTI for the
interpreter who'd be responsible for setting the PROT_BTI on the main
executable. I can't tell whether it would break anything but it's worth
a try:
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 4784011cecac..0a08fb9133e8 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -730,14 +730,6 @@ asmlinkage void __sched arm64_preempt_schedule_irq(void)
int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state,
bool has_interp, bool is_interp)
{
- /*
-* For dynamically linked executables the interpreter is
-* responsible for setting PROT_BTI on everything except
-* itself.
-*/
- if (is_interp != has_interp)
- return prot;
-
if (!(state->flags & ARM64_ELF_BTI))
return prot;
--
Catalin
Re: [RFC] Have insn decoder functions return success/failure
On Thu, Oct 22, 2020 at 04:31:00PM +0900, Masami Hiramatsu wrote: > No, insn_get_length() implies it decodes whole of the instruction. > (yeah, we need an alias of that, something like insn_get_complete()) That's exactly what I'm trying to point out: the whole API is not entirely wrong - it just needs a better naming and documentation. Now, the implication that getting the length of the insn will give you a full decode is a totally internal detail which users don't need and have to know. > I need insn.length too. Of course we can split it into 2 calls. But > as I said, since the insn_get_length() implies it decodes all other > parts, I just called it once. Yes, I have noticed that and wrote about it further on. The intent was to show that the API needs work. > Hm, it is better to call insn_get_immediate() if it doesn't use length later. Ok, so you see the problem. This thing wants to decode the whole insn - that's what the function is called. But it reads like it does something else. > Would you mean we'd better have something like insn_get_until_immediate() ? > > Since the x86 instruction is CISC, we can not decode intermediate > parts. The APIs follows that. If you are confused, I'm sorry about that. No, I'm not confused - again, I'd like for the API to be properly defined and callers should not have to care which parts of the insn they need to decode in order to get something else they actually need. So the main API should be: insn_decode_insn() or so and it should give you everything you need. If this succeeds, you can go poke at insn. and you know you have valid data there. If there are specialized uses, you can call some of the insn_get_* helpers if you're not interested in decoding the full insn. But if simply calling insn_decode_insn() would give you everything and that is not that expensive, we can do that - API simplicity. What I don't want to have is calling insn_get_length() or so and then inspecting the opcode bytes because that's totally non-transparent. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: David Hildenbrand > Sent: 22 October 2020 10:25 ... > ... especially because I recall that clang and gcc behave slightly > differently: > > https://github.com/hjl-tools/x86-psABI/issues/2 > > "Function args are different: narrow types are sign or zero extended to > 32 bits, depending on their type. clang depends on this for incoming > args, but gcc doesn't make that assumption. But both compilers do it > when calling, so gcc code can call clang code. It really is best to use 'int' (or even 'long') for all numeric arguments (and results) regardless of the domain of the value. Related, I've always worried about 'bool' > The upper 32 bits of registers are always undefined garbage for types > smaller than 64 bits." On x86-64 the high bits are zeroed by all 32bit loads. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] Kconfig: Move CONFIG_DEBUG_KMEMLEAK_TEST to samples/Kconfig
On Thu, Oct 22, 2020 at 02:12:34AM +, Chen Jun wrote:
> From: Chen Jun
>
> commit 1abbef4f51724fb11f09adf0e75275f7cb422a8a
> ("mm,kmemleak-test.c: move kmemleak-test.c to samples dir")
> make CONFIG_DEBUG_KMEMLEAK_TEST depend on CONFIG_SAMPLES implicitly.
> And the dependency cannot be guaranteed by Kconfig.
>
> move the definition of CONFIG_DEBUG_KMEMLEAK_TEST from lib/Kconfig.debug
> to samples/Kconfig.
>
> Signed-off-by: Chen Jun
Acked-by: Catalin Marinas
Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
On 22.10.20 11:32, David Laight wrote: > From: David Hildenbrand >> Sent: 22 October 2020 10:25 > ... >> ... especially because I recall that clang and gcc behave slightly >> differently: >> >> https://github.com/hjl-tools/x86-psABI/issues/2 >> >> "Function args are different: narrow types are sign or zero extended to >> 32 bits, depending on their type. clang depends on this for incoming >> args, but gcc doesn't make that assumption. But both compilers do it >> when calling, so gcc code can call clang code. > > It really is best to use 'int' (or even 'long') for all numeric > arguments (and results) regardless of the domain of the value. > > Related, I've always worried about 'bool' > >> The upper 32 bits of registers are always undefined garbage for types >> smaller than 64 bits." > > On x86-64 the high bits are zeroed by all 32bit loads. Yeah, but does not help here. My thinking: if the compiler that calls import_iovec() has garbage in the upper 32 bit a) gcc will zero it out and not rely on it being zero. b) clang will not zero it out, assuming it is zero. But a) will zero it out when calling the !inlined variant b) clang will zero it out when calling the !inlined variant When inlining, b) strikes. We access garbage. That would mean that we have calling code that's not generated by clang/gcc IIUC. We can test easily by changing the parameters instead of adding an "inline". -- Thanks, David / dhildenb
Re: [PATCH 1/2] x86: Conditional init of pcengines leds/keys gpios
On 22/10/2020 10:22, Enrico Weigelt, metux IT consult wrote: > On 21.10.20 23:41, Ed Wildgoose wrote: > > Hi, > >> The pcengines bios/firmware includes ACPI tables (since 4.10.0.1) which >> will cause the kernel to automatically create led + gpio_key devices for >> the platform. This means that the platform setup now creates duplicates >> of all these led/key devices. >> >> Driver conditionally initialises leds/keys only for older bios. > still breaks existing userlands as device names change - LEDs as well as > keys, and keycodes also change. > > IOW: userland needs to be depending on specific BIOS versions. > > > --mtx As a compromise can you change your userland to cope with dynamic names? I see two simple ways: 1) udev rule to set name as you wish 2) I uploaded a little script which uses simple globs to just figure out the base name depending on the board (also handles different board types entirely as well) I realise you have some stuff running with this, I don't know your situation specifically, but this feels like a really, really, small change to work around? Can you elaborate a little on why your users will be updating kernels without updating user code? Is there really no way to stick a compatibility udev rule in for your situation? To recap though, the situation for many years was that the naming convention was board specific. There is then just a small window (less than a year I think?) where users saw the name change to be non board specific (ie your new module). I would hazard a guess that given the speed of mainstream releases, few end users actually saw this change yet, or would notice? Those who did already accommodated the name change, so I would hazard a guess they can cope with the revert? (or not even notice?) Look, just propose a solution, I don't really mind. To me this is SUCH a TRIVIAL rename that I've already incorporated support for both naming conventions into my apps. I just want to get APU5/6 support in, which is affecting some real boards I want to use in volume. I don't feel the current situation of duplicate devices should stay though. My opinion is that we punt "this breaks userland" to being the board vendors problem now. The board is configured largely through ACPI, so if the upstream changes the ACPI, then it's on them, not us. This seems to be the direction the kernel is heading, with ACPI and device trees being used to configure the boards, in preference to heavy platform drivers? Hans, can you arbitrate here please? Your previous suggestion was to implement a compatibility shim for older BIOS, that's done here. Happy to implement something else, just need a guide? Thanks all Ed W
[PATCH] usb: typec: Prevent setting invalid opmode value
Setting opmode to invalid values would lead to a
paging fault failure when there is an access to the
power_operation_mode.
Prevent this by checking the validity of the value
that the opmode is being set.
Cc:
Fixes: fab9288428ec ("usb: USB Type-C connector class")
Signed-off-by: Sriharsha Allenki
---
drivers/usb/typec/class.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 35eec70..63efe16 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -1427,7 +1427,8 @@ void typec_set_pwr_opmode(struct typec_port *port,
{
struct device *partner_dev;
- if (port->pwr_opmode == opmode)
+ if ((port->pwr_opmode == opmode) || (opmode < TYPEC_PWR_MODE_USB) ||
+ (opmode > TYPEC_PWR_MODE_PD))
return;
port->pwr_opmode = opmode;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH 0/2] block layer filter and block device snapshot module
The 10/22/2020 08:58, Hannes Reinecke wrote: > On 10/21/20 4:10 PM, Sergei Shtepa wrote: > > The 10/21/2020 16:31, Hannes Reinecke wrote: > >> I do understand where you are coming from, but then we already have a > >> dm-snap which does exactly what you want to achieve. > >> Of course, that would require a reconfiguration of the storage stack on > >> the machine, which is not always possible (or desired). > > > > Yes, reconfiguring the storage stack on a machine is almost impossible. > > > >> > >> What I _could_ imagine would be a 'dm-intercept' thingie, which > >> redirects the current submit_bio() function for any block device, and > >> re-routes that to a linear device-mapper device pointing back to the > >> original block device. > >> > >> That way you could attach it to basically any block device, _and_ can > >> use the existing device-mapper functionality to do fancy stuff once the > >> submit_io() callback has been re-routed. > >> > >> And it also would help in other scenarios, too; with such a > >> functionality we could seamlessly clone devices without having to move > >> the whole setup to device-mapper first. > > > > Hm... > > Did I understand correctly that the filter itself can be left approximately > > as it is, but the blk-snap module can be replaced with 'dm-intercept', > > which would use the re-route mechanism from the dm? > > I think I may be able to implement it, if you describe your idea in more > > detail. > > > > > Actually, once we have an dm-intercept, why do you need the block-layer > filter at all? > From you initial description the block-layer filter was implemented > such that blk-snap could work; but if we have dm-intercept (and with it > the ability to use device-mapper functionality even for normal block > devices) there wouldn't be any need for the block-layer filter, no? Maybe, but the problem is that I can't imagine how to implement dm-intercept yet. How to use dm to implement interception without changing the stack of block devices. We'll have to make a hook somewhere, isn`t it? > > Cheers, > > Hannes > -- > Dr. Hannes ReineckeKernel Storage Architect > h...@suse.de +49 911 74053 688 > SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg > HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer -- Sergei Shtepa Veeam Software developer.
[PATCH] soc: mediatek: cmdq: fixup possible timeout issue
Fixes: 576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper")
There may be possible timeout issue when lots of cmdq packets are
flushed to the same cmdq client. The necessary modifications are as
below.
1.Adjust the timer timeout period as client->timeout_ms * client->pkt_cnt.
2.Optimize the time to start the timer.
Signed-off-by: Houlong Wei
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index dc644cfb6419..31142c193527 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -350,7 +350,8 @@ static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data
data)
del_timer(>timer);
else
mod_timer(>timer, jiffies +
- msecs_to_jiffies(client->timeout_ms));
+ msecs_to_jiffies(client->timeout_ms *
+ client->pkt_cnt));
spin_unlock_irqrestore(>lock, flags);
}
@@ -379,9 +380,7 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
cmdq_async_flush_cb cb,
if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
spin_lock_irqsave(>lock, flags);
- if (client->pkt_cnt++ == 0)
- mod_timer(>timer, jiffies +
- msecs_to_jiffies(client->timeout_ms));
+ client->pkt_cnt++;
spin_unlock_irqrestore(>lock, flags);
}
@@ -391,6 +390,21 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
cmdq_async_flush_cb cb,
/* We can send next packet immediately, so just call txdone. */
mbox_client_txdone(client->chan, 0);
+ if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
+ spin_lock_irqsave(>lock, flags);
+ /*
+* GCE HW maybe execute too quickly and the callback function
+* may be invoked earlier. If this happens, pkt_cnt is reduced
+* by 1 in cmdq_pkt_flush_async_cb(). The timer is set only if
+* pkt_cnt is greater than 0.
+*/
+ if (client->pkt_cnt > 0)
+ mod_timer(>timer, jiffies +
+ msecs_to_jiffies(client->timeout_ms *
+ client->pkt_cnt));
+ spin_unlock_irqrestore(>lock, flags);
+ }
+
return 0;
}
EXPORT_SYMBOL(cmdq_pkt_flush_async);
--
2.18.0
Re: [PATCH 1/2] perf jevents: Tidy error handling
On 21/10/2020 14:37, kajoljain wrote:
May be we can use similar checks:
if( verbose)
pr_info("%s: Error walking file tree %s%s\n", prog,
ldirname,err_string_ext);
if(rc > 0)
empty_map = 1;
else
ret = 1;
Not that it matters much, this logic is slightly different for verbose set and rc
< 0. I don't mind going with that, so let me know.
Yes right. Sure if required we can made changes on these checks and include
appropriate condition for verbose set and rc < 0. Seems fine to me.
I will just revert to the original logic for now. Someone can try to
change later if they want.
Thanks
Re: [PATCH v3 3/3] ARM: dts: add Van der Laan LANMCU board
On Thu, Oct 22, 2020 at 09:35:45AM +0200, Oleksij Rempel wrote:
> Van der Laan LANMCU is a module for the food storage rooms to control
> proper gas composition.
>
> Co-Developed-by: Robin van der Gracht
> Signed-off-by: Robin van der Gracht
> Signed-off-by: Oleksij Rempel
> Reviewed-by: Krzysztof Kozlowski
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6dl-lanmcu.dts | 469
> 2 files changed, 470 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-lanmcu.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 2289a28c0ff6..dc2543a7b7e9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -447,6 +447,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-icore.dtb \
> imx6dl-icore-mipi.dtb \
> imx6dl-icore-rqs.dtb \
> + imx6dl-lanmcu.dtb \
> imx6dl-mamoj.dtb \
> imx6dl-nit6xlite.dtb \
> imx6dl-nitrogen6x.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-lanmcu.dts
> b/arch/arm/boot/dts/imx6dl-lanmcu.dts
> new file mode 100644
> index ..bda2c7a304ba
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-lanmcu.dts
> @@ -0,0 +1,469 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2019 Protonic Holland
> + * Copyright (c) 2020 Oleksij Rempel , Pengutronix
> + */
> +
[...]
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17099
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10099
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17099
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17099
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17099
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17099
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17099
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17099
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17099
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17099
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x1b0b1
> + >;
> + };
> +
> + pinctrl_wifi_npd: wifinpd {
I missed this one last time, I am sorry. The dtschema for IMX requires
pinctrl groups to end with "grp", so "wifinpdgrp" or just "wifigrp".
Best regards,
Krzysztof
[PATCH v2 4/5] xen/events: unmask a fifo event channel only if it was masked
Unmasking an event channel with fifo events channels being used can
require a hypercall to be made, so try to avoid that by checking
whether the event channel was really masked.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V2:
- move test for already unmasked into loop (Jan Beulich)
---
drivers/xen/events/events_fifo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 243e7b6d7b96..b234f1766810 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -237,6 +237,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
w = *word;
do {
+ if (!(w & (1 << EVTCHN_FIFO_MASKED)))
+ return true;
+
if (w & (1 << EVTCHN_FIFO_PENDING))
return false;
--
2.26.2
[PATCH v2 0/5] xen: event handling cleanup
Do some cleanups in Xen event handling code. Changes in V2: - addressed comments Juergen Gross (5): xen: remove no longer used functions xen/events: make struct irq_info private to events_base.c xen/events: only register debug interrupt for 2-level events xen/events: unmask a fifo event channel only if it was masked Documentation: add xen.fifo_events kernel parameter description .../admin-guide/kernel-parameters.txt | 7 ++ arch/x86/xen/smp.c| 19 ++-- arch/x86/xen/xen-ops.h| 2 + drivers/xen/events/events_2l.c| 7 +- drivers/xen/events/events_base.c | 94 +-- drivers/xen/events/events_fifo.c | 9 +- drivers/xen/events/events_internal.h | 70 ++ include/xen/events.h | 8 -- 8 files changed, 102 insertions(+), 114 deletions(-) -- 2.26.2
[PATCH v2 2/5] xen/events: make struct irq_info private to events_base.c
The struct irq_info of Xen's event handling is used only for two
evtchn_ops functions outside of events_base.c. Those two functions
can easily be switched to avoid that usage.
This allows to make struct irq_info and its related access functions
private to events_base.c.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
drivers/xen/events/events_2l.c | 7 +--
drivers/xen/events/events_base.c | 63 ++---
drivers/xen/events/events_fifo.c | 6 +--
drivers/xen/events/events_internal.h | 70
4 files changed, 73 insertions(+), 73 deletions(-)
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index fe5ad0e89cd8..da87f3a1e351 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -47,10 +47,11 @@ static unsigned evtchn_2l_max_channels(void)
return EVTCHN_2L_NR_CHANNELS;
}
-static void evtchn_2l_bind_to_cpu(struct irq_info *info, unsigned cpu)
+static void evtchn_2l_bind_to_cpu(evtchn_port_t evtchn, unsigned int cpu,
+ unsigned int old_cpu)
{
- clear_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, info->cpu)));
- set_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
+ clear_bit(evtchn, BM(per_cpu(cpu_evtchn_mask, old_cpu)));
+ set_bit(evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
}
static void evtchn_2l_clear_pending(evtchn_port_t port)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 436682db41c5..1c25580c7691 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -70,6 +70,57 @@
#undef MODULE_PARAM_PREFIX
#define MODULE_PARAM_PREFIX "xen."
+/* Interrupt types. */
+enum xen_irq_type {
+ IRQT_UNBOUND = 0,
+ IRQT_PIRQ,
+ IRQT_VIRQ,
+ IRQT_IPI,
+ IRQT_EVTCHN
+};
+
+/*
+ * Packed IRQ information:
+ * type - enum xen_irq_type
+ * event channel - irq->event channel mapping
+ * cpu - cpu this event channel is bound to
+ * index - type-specific information:
+ *PIRQ - vector, with MSB being "needs EIO", or physical IRQ of the HVM
+ * guest, or GSI (real passthrough IRQ) of the device.
+ *VIRQ - virq number
+ *IPI - IPI vector
+ *EVTCHN -
+ */
+struct irq_info {
+ struct list_head list;
+ struct list_head eoi_list;
+ short refcnt;
+ short spurious_cnt;
+ enum xen_irq_type type; /* type */
+ unsigned irq;
+ evtchn_port_t evtchn; /* event channel */
+ unsigned short cpu; /* cpu bound */
+ unsigned short eoi_cpu; /* EOI must happen on this cpu-1 */
+ unsigned int irq_epoch; /* If eoi_cpu valid: irq_epoch of event */
+ u64 eoi_time; /* Time in jiffies when to EOI. */
+
+ union {
+ unsigned short virq;
+ enum ipi_vector ipi;
+ struct {
+ unsigned short pirq;
+ unsigned short gsi;
+ unsigned char vector;
+ unsigned char flags;
+ uint16_t domid;
+ } pirq;
+ } u;
+};
+
+#define PIRQ_NEEDS_EOI (1 << 0)
+#define PIRQ_SHAREABLE (1 << 1)
+#define PIRQ_MSI_GROUP (1 << 2)
+
static uint __read_mostly event_loop_timeout = 2;
module_param(event_loop_timeout, uint, 0644);
@@ -110,7 +161,7 @@ static DEFINE_PER_CPU(int [NR_VIRQS], virq_to_irq) = {[0
... NR_VIRQS-1] = -1};
/* IRQ <-> IPI mapping */
static DEFINE_PER_CPU(int [XEN_NR_IPIS], ipi_to_irq) = {[0 ... XEN_NR_IPIS-1]
= -1};
-int **evtchn_to_irq;
+static int **evtchn_to_irq;
#ifdef CONFIG_X86
static unsigned long *pirq_eoi_map;
#endif
@@ -190,7 +241,7 @@ int get_evtchn_to_irq(evtchn_port_t evtchn)
}
/* Get info for IRQ */
-struct irq_info *info_for_irq(unsigned irq)
+static struct irq_info *info_for_irq(unsigned irq)
{
if (irq < nr_legacy_irqs())
return legacy_info_ptrs[irq];
@@ -228,7 +279,7 @@ static int xen_irq_info_common_setup(struct irq_info *info,
irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
- return xen_evtchn_port_setup(info);
+ return xen_evtchn_port_setup(evtchn);
}
static int xen_irq_info_evtchn_setup(unsigned irq,
@@ -351,7 +402,7 @@ static enum xen_irq_type type_from_irq(unsigned irq)
return info_for_irq(irq)->type;
}
-unsigned cpu_from_irq(unsigned irq)
+static unsigned cpu_from_irq(unsigned irq)
{
return info_for_irq(irq)->cpu;
}
@@ -391,7 +442,7 @@ static void bind_evtchn_to_cpu(evtchn_port_t evtchn,
unsigned int cpu)
#ifdef CONFIG_SMP
cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(cpu));
#endif
- xen_evtchn_port_bind_to_cpu(info, cpu);
+ xen_evtchn_port_bind_to_cpu(evtchn, cpu, info->cpu);
info->cpu = cpu;
}
@@ -745,7 +796,7 @@ static unsigned int __startup_pirq(unsigned int irq)
info->evtchn = evtchn;
bind_evtchn_to_cpu(evtchn,
[PATCH v2 1/5] xen: remove no longer used functions
With the switch to the lateeoi model for interdomain event channels
some functions are no longer in use. Remove them.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
drivers/xen/events/events_base.c | 21 -
include/xen/events.h | 8
2 files changed, 29 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index cc317739e786..436682db41c5 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1145,14 +1145,6 @@ static int bind_interdomain_evtchn_to_irq_chip(unsigned
int remote_domain,
chip);
}
-int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
- evtchn_port_t remote_port)
-{
- return bind_interdomain_evtchn_to_irq_chip(remote_domain, remote_port,
- _dynamic_chip);
-}
-EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irq);
-
int bind_interdomain_evtchn_to_irq_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port)
{
@@ -1320,19 +1312,6 @@ static int bind_interdomain_evtchn_to_irqhandler_chip(
return irq;
}
-int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
- evtchn_port_t remote_port,
- irq_handler_t handler,
- unsigned long irqflags,
- const char *devname,
- void *dev_id)
-{
- return bind_interdomain_evtchn_to_irqhandler_chip(remote_domain,
- remote_port, handler, irqflags, devname,
- dev_id, _dynamic_chip);
-}
-EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irqhandler);
-
int bind_interdomain_evtchn_to_irqhandler_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port,
irq_handler_t handler,
diff --git a/include/xen/events.h b/include/xen/events.h
index 3b8155c2ea03..8ec418e30c7f 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -35,16 +35,8 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi,
unsigned long irqflags,
const char *devname,
void *dev_id);
-int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
- evtchn_port_t remote_port);
int bind_interdomain_evtchn_to_irq_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port);
-int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
- evtchn_port_t remote_port,
- irq_handler_t handler,
- unsigned long irqflags,
- const char *devname,
- void *dev_id);
int bind_interdomain_evtchn_to_irqhandler_lateeoi(unsigned int remote_domain,
evtchn_port_t remote_port,
irq_handler_t handler,
--
2.26.2
[PATCH v2 3/5] xen/events: only register debug interrupt for 2-level events
xen_debug_interrupt() is specific to 2-level event handling. So don't
register it with fifo event handling being active.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V2:
- rename fifo_events variable to xen_fifo_events (Jan Beulich)
---
arch/x86/xen/smp.c | 19 +++
arch/x86/xen/xen-ops.h | 2 ++
drivers/xen/events/events_base.c | 10 ++
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2097fa0ebdb5..c1b2f764b29a 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -88,14 +88,17 @@ int xen_smp_intr_init(unsigned int cpu)
per_cpu(xen_callfunc_irq, cpu).irq = rc;
per_cpu(xen_callfunc_irq, cpu).name = callfunc_name;
- debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu);
- rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu, xen_debug_interrupt,
-IRQF_PERCPU | IRQF_NOBALANCING,
-debug_name, NULL);
- if (rc < 0)
- goto fail;
- per_cpu(xen_debug_irq, cpu).irq = rc;
- per_cpu(xen_debug_irq, cpu).name = debug_name;
+ if (!xen_fifo_events) {
+ debug_name = kasprintf(GFP_KERNEL, "debug%d", cpu);
+ rc = bind_virq_to_irqhandler(VIRQ_DEBUG, cpu,
+xen_debug_interrupt,
+IRQF_PERCPU | IRQF_NOBALANCING,
+debug_name, NULL);
+ if (rc < 0)
+ goto fail;
+ per_cpu(xen_debug_irq, cpu).irq = rc;
+ per_cpu(xen_debug_irq, cpu).name = debug_name;
+ }
callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu);
rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR,
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 45d556f71858..9546c3384c75 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -29,6 +29,8 @@ extern struct start_info *xen_start_info;
extern struct shared_info xen_dummy_shared_info;
extern struct shared_info *HYPERVISOR_shared_info;
+extern bool xen_fifo_events;
+
void xen_setup_mfn_list_list(void);
void xen_build_mfn_list_list(void);
void xen_setup_machphys_mapping(void);
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 1c25580c7691..6038c4c35db5 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2050,8 +2050,8 @@ void xen_setup_callback_vector(void) {}
static inline void xen_alloc_callback_vector(void) {}
#endif
-static bool fifo_events = true;
-module_param(fifo_events, bool, 0);
+bool xen_fifo_events = true;
+module_param_named(fifo_events, xen_fifo_events, bool, 0);
static int xen_evtchn_cpu_prepare(unsigned int cpu)
{
@@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
int ret = -EINVAL;
evtchn_port_t evtchn;
- if (fifo_events)
+ if (xen_fifo_events)
ret = xen_evtchn_fifo_init();
- if (ret < 0)
+ if (ret < 0) {
xen_evtchn_2l_init();
+ xen_fifo_events = false;
+ }
xen_cpu_init_eoi(smp_processor_id());
--
2.26.2
[PATCH v2 5/5] Documentation: add xen.fifo_events kernel parameter description
The kernel boot parameter xen.fifo_events isn't listed in Documentation/admin-guide/kernel-parameters.txt. Add it. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- Documentation/admin-guide/kernel-parameters.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 02d4adbf98d2..526d65d8573a 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5978,6 +5978,13 @@ After which time (jiffies) the event handling loop should start to delay EOI handling. Default is 2. + xen.fifo_events=[XEN] + Boolean parameter to disable using fifo event handling + even if available. Normally fifo event handling is + preferred over the 2-level event handling, as it is + fairer and the number of possible event channels is + much higher. Default is on (use fifo events). + nopv= [X86,XEN,KVM,HYPER_V,VMWARE] Disables the PV optimizations forcing the guest to run as generic guest with no PV drivers. Currently support -- 2.26.2
Context expectations in ALSA
Hi! We currently have an issue reported by lockdep on the RaspberryPi and its HDMI audio output where, at startup, we end up scheduling in atomic context. This is caused by the HDMI driver polling some status bit that reports that the infoframes have been properly sent, and calling usleep_range between each iteration[1], and that is done in our trigger callback that seems to be run with a spinlock taken and the interrupt disabled (snd_pcm_action_lock_irq) as part of snd_pcm_start_lock_irq. This is the entire stack trace: # aplay --channels=2 -D 'iec958:CARD=vc4hdmi0,DEV=0' /root/test-tone.wav Playing WAVE '/root/test-tone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo [ 14.732730] BUG: sleeping function called from invalid context at drivers/gpu/drm/vc4/vc4_hdmi.c:276 [ 14.742005] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 140, name: aplay [ 14.749955] CPU: 0 PID: 140 Comm: aplay Not tainted 5.9.0-rc5-v7l+ #66 [ 14.756578] Hardware name: BCM2711 [ 14.760026] Backtrace: [ 14.762524] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 14.770209] r7:c167c9e4 r6:600e0093 r5: r4:c167c9e4 [ 14.775960] [] (show_stack) from [] (dump_stack+0xb8/0xd8) [ 14.783297] [] (dump_stack) from [] (___might_sleep+0x138/0x17c) [ 14.791159] r10:0084 r9:f0979b00 r8:c10ffd50 r7:0010 r6: r5:0114 [ 14.799105] r4:c10fe000 r3:600e0093 [ 14.802736] [] (___might_sleep) from [] (__might_sleep+0x70/0xb0) [ 14.810680] r4:c0e8f5f4 [ 14.813256] [] (__might_sleep) from [] (vc4_hdmi_stop_packet+0x120/0x330) [ 14.821907] r6:ef21f280 r5:0003 r4:73e746f9 [ 14.826598] [] (vc4_hdmi_stop_packet) from [] (vc4_hdmi_write_infoframe+0x140/0x5d0) [ 14.836220] r9:f0979b00 r8:c10ffd50 r7:ef219900 r6:ef248840 r5: r4:ef21f280 [ 14.844084] [] (vc4_hdmi_write_infoframe) from [] (vc4_hdmi_set_audio_infoframe+0x5c/0x80) [ 14.854236] r10:efac7738 r9:ef3ea240 r8:0001 r7:ef219900 r6:ef248840 r5:ef21f040 [ 14.862180] r4:ef21f280 [ 14.864756] [] (vc4_hdmi_set_audio_infoframe) from [] (vc4_hdmi_audio_trigger+0x38/0x238) [ 14.874815] r4:0001 [ 14.877392] [] (vc4_hdmi_audio_trigger) from [] (snd_soc_pcm_dai_trigger+0x64/0xcc) [ 14.886923] r5:efac5a00 r4: [ 14.890555] [] (snd_soc_pcm_dai_trigger) from [] (soc_pcm_trigger+0x70/0xac) [ 14.899472] r9:ef3ea240 r8:c1133540 r7:0003 r6:ef219900 r5:ef219900 r4:0001 [ 14.907336] [] (soc_pcm_trigger) from [] (snd_pcm_do_start+0x3c/0x40) [ 14.915633] r5:c0c749dc r4: [ 14.919264] [] (snd_pcm_do_start) from [] (snd_pcm_action_single+0x48/0x88) [ 14.928094] [] (snd_pcm_action_single) from [] (snd_pcm_action+0x6c/0x78) [ 14.936746] r7:0003 r6:c0c749dc r5: r4:ef219900 [ 14.942493] [] (snd_pcm_action) from [] (snd_pcm_action_lock_irq+0x38/0x50) [ 14.951320] r7:0030 r6:0003 r5:c0c749dc r4:ef219900 [ 14.957069] [] (snd_pcm_action_lock_irq) from [] (snd_pcm_ioctl+0x930/0x14e4) [ 14.966073] r7:0030 r6: r5:0085ee60 r4:ef219900 [ 14.971823] [] (snd_pcm_ioctl) from [] (sys_ioctl+0xe4/0x9e4) [ 14.979420] r10:efac7738 r9:0004 r8:c1133540 r7:0085ee60 r6:5624 r5:c1133540 [ 14.987364] r4:4142 [ 14.989940] [] (sys_ioctl) from [] (ret_fast_syscall+0x0/0x28) [ 14.997621] Exception stack(0xc10fffa8 to 0xc100) [ 15.002749] ffa0: 00869260 b6fa8000 0004 4142 0085ee60 0001 [ 15.011050] ffc0: 00869260 b6fa8000 5624 0036 1589 1589 [ 15.019350] ffe0: b6fa8504 bedb59fc b6f2ff68 b6da515c [ 15.024479] r10:0036 r9:c10fe000 r8:c0200204 r7:0036 r6:5624 r5:b6fa8000 [ 15.032423] r4:00869260 We could switch to a udelay instead, but the idea of busy-waiting for up to a 100ms while having the interrupt disabled doesn't sound ideal either. It looks like the snd_soc_dai_link structure has a nonatomic flag that seems to be made to address more or less that issue, taking a mutex instead of a spinlock. However setting that flag results in another lockdep issue, since the dmaengine controller doing the DMA transfer would call snd_pcm_period_elapsed on completion, in a tasklet, this time taking a mutex in an atomic context which is just as bad as the initial issue. This is the stacktrace this time: # aplay --channels=2 -D 'iec958:CARD=vc4hdmi0,DEV=0' /root/test-tone.wav Playing WAVE '/root/test-tone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo [ 43.078900] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 43.087485] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0 [ 43.095452] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.0-rc5-v7l+ #67 [ 43.102252] Hardware name: BCM2711 [ 43.105701] Backtrace: [ 43.108199] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 43.115884] r7:c167c9e4 r6:600e0113 r5: r4:c167c9e4 [
Re: [PATCH] HID: uclogic: Add ID for Trust Flex Design Tablet
On Fri, 16 Oct 2020, Martijn van de Streek wrote: > The Trust Flex Design Tablet has an UGTizer USB ID and requires the same > initialization as the UGTizer GP0610 to be detected as a graphics tablet > instead of a mouse. > > Signed-off-by: Martijn van de Streek Applied, thanks Martijn. -- Jiri Kosina SUSE Labs
Re: [PATCH] nvme-rdma: handle nvme completion data length
On 2020/10/22 16:38, zhenwei pi wrote:
Hit a kernel warning:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 0 at lib/refcount.c:28
RIP: 0010:refcount_warn_saturate+0xd9/0xe0
Call Trace:
nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma]
__ib_process_cq+0x76/0x150 [ib_core]
...
The reason is that a zero bytes message received from target, and the
host side continues to process without length checking, then the
previous CQE is processed twice.
Handle data length, ignore zero bytes message, and try to recovery for
corrupted CQE case.
Signed-off-by: zhenwei pi
---
drivers/nvme/host/rdma.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 9e378d0a0c01..9f5112040d43 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1767,6 +1767,17 @@ static void nvme_rdma_recv_done(struct ib_cq *cq, struct
ib_wc *wc)
return;
}
+ if (unlikely(!wc->byte_len)) {
+ /* zero bytes message could be ignored */
+ return;
+ } else if (unlikely(wc->byte_len < len)) {
+ /* Corrupted completion, try to recovry */
+ dev_err(queue->ctrl->ctrl.device,
+ "Unexpected nvme completion length(%d)\n",
wc->byte_len);
+ nvme_rdma_error_recovery(queue->ctrl);
+ return;
+ }
!wc->byte_len and wc->byte_len < len may be the same type of anomaly.
Why do different error handling?
In which scenario zero bytes message received from target? fault inject test or
normal test/run?
+
ib_dma_sync_single_for_cpu(ibdev, qe->dma, len, DMA_FROM_DEVICE);
/*
* AEN requests are special as they don't time out and can
Re: [PATCH] HID: multitouch: Re-enable trackpoint and buttons on Lenovo X1 Tab gen2
On Fri, 16 Oct 2020, David Edmondson wrote:
> Use the FORCE_MULTI_INPUT class and quirk added in
> commit 40d5bb87377a ("HID: multitouch: enable multi-input as a quirk
> for some devices")
> to enable event reporting from both the trackpad and the
> trackpoint/buttons in the Lenovo X1 Tab gen2.
>
> Signed-off-by: David Edmondson
Hi David,
there is already a patch in Linus' tree doing this (4a6a4c966ccf38).
Thanks,
--
Jiri Kosina
SUSE Labs
Re: [PATCH] HID: logitech-hidpp: Add PID for MX Anywhere 2
On Wed, 21 Oct 2020, Harry Cutts wrote:
> It seems that the PID 0x4072 was missing from the list Logitech gave me
> for this mouse, as I found one with it in the wild (with which I tested
> this patch).
>
> Fixes: 4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on
> Logitech mice")
> Signed-off-by: Harry Cutts
Applied, thank you.
--
Jiri Kosina
SUSE Labs
