[RFC v1 19/26] x86/tdx: Forcefully disable legacy PIC for TDX guests
From: Sean Christopherson Disable the legacy PIC (8259) for TDX guests as the PIC cannot be supported by the VMM. TDX Module does not allow direct IRQ injection, and using posted interrupt style delivery requires the guest to EOI the IRQ, which diverges from the legacy PIC behavior. Signed-off-by: Sean Christopherson Reviewed-by: Andi Kleen Signed-off-by: Kuppuswamy Sathyanarayanan --- arch/x86/kernel/tdx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c index a36b6ae14942..ae37498df981 100644 --- a/arch/x86/kernel/tdx.c +++ b/arch/x86/kernel/tdx.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include #include @@ -410,6 +411,8 @@ void __init tdx_early_init(void) pv_ops.irq.safe_halt = tdx_safe_halt; pv_ops.irq.halt = tdx_halt; + legacy_pic = _legacy_pic; + cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "tdx:cpu_hotplug", NULL, tdx_cpu_offline_prepare); -- 2.25.1
[PATCH v4 7/8] PM: domains: Mark fwnodes when their powerdomain is added/removed
This allows fw_devlink to recognize power domain drivers that don't use the device-driver model to initialize the device. fw_devlink will use this information to make sure consumers of such power domain aren't indefinitely blocked from probing, waiting for the power domain device to appear and bind to a driver. Signed-off-by: Saravana Kannan --- drivers/base/power/domain.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index 9a14eedacb92..6ac52a038bb9 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -2164,6 +2164,7 @@ static int genpd_add_provider(struct device_node *np, genpd_xlate_t xlate, cp->node = of_node_get(np); cp->data = data; cp->xlate = xlate; + fwnode_dev_initialized(>fwnode, true); mutex_lock(_genpd_mutex); list_add(>link, _genpd_providers); @@ -2353,6 +2354,7 @@ void of_genpd_del_provider(struct device_node *np) } } + fwnode_dev_initialized(>node->fwnode, false); list_del(>link); of_node_put(cp->node); kfree(cp); -- 2.30.0.478.g8a0d178c01-goog
Re: [PATCH v3 1/7] seqnum_ops: Introduce Sequence Number Ops
On Fri, Feb 05, 2021 at 01:03:18PM -0700, Shuah Khan wrote:
> On 2/5/21 2:58 AM, Greg KH wrote:
> > On Wed, Feb 03, 2021 at 11:11:57AM -0700, Shuah Khan wrote:
> > > +static inline u32 seqnum32_inc(struct seqnum32 *seq)
> > > +{
> > > + atomic_t val = ATOMIC_INIT(seq->seqnum);
> > > +
> > > + seq->seqnum = (u32) atomic_inc_return();
> > > + if (seq->seqnum >= UINT_MAX)
> > > + pr_info("Sequence Number overflow %u detected\n",
> > > + seq->seqnum);
> > > + return seq->seqnum;
> >
> > As Peter points out, this is doing doing what you think it is doing :(
> >
> > Why do you not just have seq->seqnum be a real atomic variable? Trying
> > to switch to/from one like this does not work as there is no
> > "atomic-ness" happening here at all.
> >
>
> Yes. This is sloppy on my part. As Peter and Rafael also pointed. I have
> to start paying more attention to my inner voice.
What's the end goal with this sequence number type?
Apart from the functional issues with this code already pointed
out, it doesn't seem overly useful to just print the *value* of
the sequence number when it hits the max value. It might be
more helpful if each instance had a seq->name field that is
used here to tell the user *which* user of sequence numbers
had seen the wrap arounnd.
But that just begs the question of what should users of sequence
numbers do when wrap around occurs? Any user that can run through
sequence numbers at greater than 10 Hz is going to cause a problem
for systems that stay running for years.
Maybe you should force users to code for wraparound by initializing
to something like 0xff00 so that they all get a wraparound event
quickly, rather than slowly, (same as was done with jiffies)?
[PATCH v5 30/34] misc:intel_tsens: Intel Keem Bay tsens driver.
From: "C, Udhayakumar"
Add keembey_thermal driver to expose on chip temperature
sensors, and register call back functions for periodic sampling.
This driver does following:
* Reads temperature data from on chip sensors present in Keem Bay
platform.
* Registers callback function to intel tsens driver for sampling
temperature values periodically.
* Decode the raw values from registers to Celsius.
Acked-by: mark gross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
drivers/misc/intel_tsens/Kconfig | 12 +
drivers/misc/intel_tsens/Makefile | 1 +
drivers/misc/intel_tsens/keembay_thermal.c | 169 ++
drivers/misc/intel_tsens/keembay_tsens.h | 366 +
4 files changed, 548 insertions(+)
create mode 100644 drivers/misc/intel_tsens/keembay_thermal.c
create mode 100644 drivers/misc/intel_tsens/keembay_tsens.h
diff --git a/drivers/misc/intel_tsens/Kconfig b/drivers/misc/intel_tsens/Kconfig
index be8d27e81864..5cfe6b4004e5 100644
--- a/drivers/misc/intel_tsens/Kconfig
+++ b/drivers/misc/intel_tsens/Kconfig
@@ -28,6 +28,18 @@ config INTEL_TSENS_I2C_SLAVE
Say Y if using a processor that includes the Intel VPU such as
Keem Bay. If unsure, say N.
+config KEEMBAY_THERMAL
+ tristate "Temperature sensor driver for intel Keem Bay"
+ depends on INTEL_TSENS_LOCAL_HOST && ARCH_KEEMBAY
+ help
+ Enable this option if you want to have support for Keem Bay
+ thermal management sensors.
+
+ This driver is used for reading onchip temperature sensor
+ values from Keem Bay SoC.
+ Say Y if using a processor that includes the Intel VPU such as
+ Keem Bay. If unsure, say N.
+
config INTEL_TSENS_IA_HOST
tristate "Temperature sensor driver for intel tsens remote host"
depends on I2C && THERMAL
diff --git a/drivers/misc/intel_tsens/Makefile
b/drivers/misc/intel_tsens/Makefile
index f6f41bbca80c..00f63c2d5b2f 100644
--- a/drivers/misc/intel_tsens/Makefile
+++ b/drivers/misc/intel_tsens/Makefile
@@ -7,3 +7,4 @@
obj-$(CONFIG_INTEL_TSENS_LOCAL_HOST) += intel_tsens_thermal.o
obj-$(CONFIG_INTEL_TSENS_I2C_SLAVE)+= intel_tsens_i2c.o
obj-$(CONFIG_INTEL_TSENS_IA_HOST) += intel_tsens_host.o
+obj-$(CONFIG_KEEMBAY_THERMAL) += keembay_thermal.o
diff --git a/drivers/misc/intel_tsens/keembay_thermal.c
b/drivers/misc/intel_tsens/keembay_thermal.c
new file mode 100644
index ..d6c8fa8fc3aa
--- /dev/null
+++ b/drivers/misc/intel_tsens/keembay_thermal.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ *
+ * Intel Keem Bay thermal Driver
+ *
+ * Copyright (C) 2020 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_tsens_thermal.h"
+#include "keembay_tsens.h"
+
+struct keembay_thermal_priv {
+ const char *name;
+ void __iomem *base_addr;
+ /* sensor lock*/
+ spinlock_t lock;
+ int current_temp[KEEMBAY_SENSOR_MAX];
+ struct intel_tsens_plat_data *plat_data;
+};
+
+static void kmb_sensor_read_temp(void __iomem *regs_val,
+int offset,
+int sample_valid_mask,
+int sample_value,
+int bit_shift,
+int *temp)
+{
+ int reg_val, kmb_raw_index;
+
+ /* clear the bit of TSENS_EN and re-enable again */
+ iowrite32(0x00, regs_val + AON_TSENS_CFG);
+ iowrite32(CFG_MASK_MANUAL, regs_val + AON_TSENS_CFG);
+ reg_val = ioread32(regs_val + offset);
+ if (reg_val & sample_valid_mask) {
+ reg_val = (reg_val >> bit_shift) & sample_value;
+ kmb_raw_index = reg_val - KEEMBAY_SENSOR_BASE_TEMP;
+ if (kmb_raw_index < 0)
+ reg_val = raw_kmb[0];
+ else if (kmb_raw_index > (raw_kmb_size - 1))
+ reg_val = raw_kmb[raw_kmb_size - 1];
+ else
+ reg_val = raw_kmb[kmb_raw_index];
+ *temp = reg_val;
+ } else {
+ *temp = -255;
+ }
+}
+
+/*The lock is assumed to be held by the caller.*/
+static int keembay_get_temp(struct platform_device *pdev, int type, int *temp)
+{
+ struct keembay_thermal_priv *priv = platform_get_drvdata(pdev);
+
+ spin_lock(>lock);
+ switch (type) {
+ case KEEMBAY_SENSOR_MSS:
+ kmb_sensor_read_temp(priv->base_addr,
+AON_TSENS_DATA0,
+MSS_T_SAMPLE_VALID,
+MSS_T_SAMPLE,
+MSS_BIT_SHIFT,
+temp);
+ priv->current_temp[KEEMBAY_SENSOR_MSS] = *temp;
+ break;
+
+ case KEEMBAY_SENSOR_CSS:
+
[PATCH 5/5] loop: increment sequence number
From: Matteo Croce On a very loaded system, if there are many events queued up from multiple attach/detach cycles, it's impossible to match them up with the LOOP_CONFIGURE or LOOP_SET_FD call, since we don't know where the position of our own association in the queue is[1]. Not even an empty uevent queue is a reliable indication that we already received the uevent we were waiting for, since with multi-partition block devices each partition's event is queued asynchronously and might be delivered later. Increment the disk sequence number when setting or changing the backing file, so the userspace knows which backing file generated the event. [1] https://github.com/systemd/systemd/issues/17469#issuecomment-762919781 Signed-off-by: Matteo Croce --- drivers/block/loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index e5ff328f0917..c12b3faae3ab 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -734,6 +734,7 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev, goto out_err; /* and ... switch */ + inc_diskseq(lo->lo_disk); blk_mq_freeze_queue(lo->lo_queue); mapping_set_gfp_mask(old_file->f_mapping, lo->old_gfp_mask); lo->lo_backing_file = file; @@ -1122,6 +1123,8 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, if (error) goto out_unlock; + inc_diskseq(lo->lo_disk); + if (!(file->f_mode & FMODE_WRITE) || !(mode & FMODE_WRITE) || !file->f_op->write_iter) lo->lo_flags |= LO_FLAGS_READ_ONLY; -- 2.29.2
[PATCH net-next v2 5/7] net: ipa: use a Boolean rather than count when replenishing
The count argument to ipa_endpoint_replenish() is only ever 0 or 1,
and always will be (because we always handle each receive buffer in
a single transaction). Rename the argument to be add_one and change
it to be Boolean.
Update the function description to reflect the current code.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_endpoint.c | 35 ++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ipa/ipa_endpoint.c b/drivers/net/ipa/ipa_endpoint.c
index 7a46c790afbef..bff5d6ffd1186 100644
--- a/drivers/net/ipa/ipa_endpoint.c
+++ b/drivers/net/ipa/ipa_endpoint.c
@@ -1020,31 +1020,34 @@ static int ipa_endpoint_replenish_one(struct
ipa_endpoint *endpoint)
}
/**
- * ipa_endpoint_replenish() - Replenish the Rx packets cache.
+ * ipa_endpoint_replenish() - Replenish endpoint receive buffers
* @endpoint: Endpoint to be replenished
- * @count: Number of buffers to send to hardware
+ * @add_one: Whether this is replacing a just-consumed buffer
*
- * Allocate RX packet wrapper structures with maximal socket buffers
- * for an endpoint. These are supplied to the hardware, which fills
- * them with incoming data.
+ * The IPA hardware can hold a fixed number of receive buffers for an RX
+ * endpoint, based on the number of entries in the underlying channel ring
+ * buffer. If an endpoint's "backlog" is non-zero, it indicates how many
+ * more receive buffers can be supplied to the hardware. Replenishing for
+ * an endpoint can be disabled, in which case requests to replenish a
+ * buffer are "saved", and transferred to the backlog once it is re-enabled
+ * again.
*/
-static void ipa_endpoint_replenish(struct ipa_endpoint *endpoint, u32 count)
+static void ipa_endpoint_replenish(struct ipa_endpoint *endpoint, bool add_one)
{
struct gsi *gsi;
u32 backlog;
if (!endpoint->replenish_enabled) {
- if (count)
- atomic_add(count, >replenish_saved);
+ if (add_one)
+ atomic_inc(>replenish_saved);
return;
}
-
while (atomic_dec_not_zero(>replenish_backlog))
if (ipa_endpoint_replenish_one(endpoint))
goto try_again_later;
- if (count)
- atomic_add(count, >replenish_backlog);
+ if (add_one)
+ atomic_inc(>replenish_backlog);
return;
@@ -1052,8 +1055,8 @@ static void ipa_endpoint_replenish(struct ipa_endpoint
*endpoint, u32 count)
/* The last one didn't succeed, so fix the backlog */
backlog = atomic_inc_return(>replenish_backlog);
- if (count)
- atomic_add(count, >replenish_backlog);
+ if (add_one)
+ atomic_inc(>replenish_backlog);
/* Whenever a receive buffer transaction completes we'll try to
* replenish again. It's unlikely, but if we fail to supply even
@@ -1080,7 +1083,7 @@ static void ipa_endpoint_replenish_enable(struct
ipa_endpoint *endpoint)
/* Start replenishing if hardware currently has no buffers */
max_backlog = gsi_channel_tre_max(gsi, endpoint->channel_id);
if (atomic_read(>replenish_backlog) == max_backlog)
- ipa_endpoint_replenish(endpoint, 0);
+ ipa_endpoint_replenish(endpoint, false);
}
static void ipa_endpoint_replenish_disable(struct ipa_endpoint *endpoint)
@@ -1099,7 +1102,7 @@ static void ipa_endpoint_replenish_work(struct
work_struct *work)
endpoint = container_of(dwork, struct ipa_endpoint, replenish_work);
- ipa_endpoint_replenish(endpoint, 0);
+ ipa_endpoint_replenish(endpoint, false);
}
static void ipa_endpoint_skb_copy(struct ipa_endpoint *endpoint,
@@ -1300,7 +1303,7 @@ static void ipa_endpoint_rx_complete(struct ipa_endpoint
*endpoint,
{
struct page *page;
- ipa_endpoint_replenish(endpoint, 1);
+ ipa_endpoint_replenish(endpoint, true);
if (trans->cancelled)
return;
--
2.20.1
[PATCH net-next v2 6/7] net: ipa: get rid of status size constraint
There is a build-time check that the packet status structure is a
multiple of 4 bytes in size. It's not clear where that constraint
comes from, but the structure defines what hardware provides so its
definition won't change. Get rid of the check; it adds no value.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_endpoint.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ipa/ipa_endpoint.c b/drivers/net/ipa/ipa_endpoint.c
index bff5d6ffd1186..7209ee3c31244 100644
--- a/drivers/net/ipa/ipa_endpoint.c
+++ b/drivers/net/ipa/ipa_endpoint.c
@@ -174,9 +174,6 @@ static bool ipa_endpoint_data_valid(struct ipa *ipa, u32
count,
enum ipa_endpoint_name name;
u32 limit;
- /* Not sure where this constraint come from... */
- BUILD_BUG_ON(sizeof(struct ipa_status) % 4);
-
if (count > IPA_ENDPOINT_COUNT) {
dev_err(dev, "too many endpoints specified (%u > %u)\n",
count, IPA_ENDPOINT_COUNT);
--
2.20.1
[PATCH 2/4] fs/btrfs: Use memcpy_[to|from]_page()
From: Ira Weiny
Development of this patch was aided by the coccinelle script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/memcpy/kunmap pattern and replace with memcpy*page calls
//
// NOTE: Offsets and other expressions may be more complex than what the script
// will automatically generate. Therefore a catchall rule is provided to find
// the pattern which then must be evaluated by hand.
//
// Confidence: Low
// Copyright: (C) 2021 Intel Corporation
// URL: http://coccinelle.lip6.fr/
// Comments:
// Options:
//
// simple memcpy version
//
@ memcpy_rule1 @
expression page, T, F, B, Off;
identifier ptr;
type VP;
@@
(
-VP ptr = kmap(page);
|
-ptr = kmap(page);
|
-VP ptr = kmap_atomic(page);
|
-ptr = kmap_atomic(page);
)
<+...
(
-memcpy(ptr + Off, F, B);
+memcpy_to_page(page, Off, F, B);
|
-memcpy(ptr, F, B);
+memcpy_to_page(page, 0, F, B);
|
-memcpy(T, ptr + Off, B);
+memcpy_from_page(T, page, Off, B);
|
-memcpy(T, ptr, B);
+memcpy_from_page(T, page, 0, B);
)
...+>
(
-kunmap(page);
|
-kunmap_atomic(ptr);
)
// Remove any pointers left unused
@
depends on memcpy_rule1
@
identifier memcpy_rule1.ptr;
type VP, VP1;
@@
-VP ptr;
... when != ptr;
? VP1 ptr;
//
// Some callers kmap without a temp pointer
//
@ memcpy_rule2 @
expression page, T, Off, F, B;
@@
<+...
(
-memcpy(kmap(page) + Off, F, B);
+memcpy_to_page(page, Off, F, B);
|
-memcpy(kmap(page), F, B);
+memcpy_to_page(page, 0, F, B);
|
-memcpy(T, kmap(page) + Off, B);
+memcpy_from_page(T, page, Off, B);
|
-memcpy(T, kmap(page), B);
+memcpy_from_page(T, page, 0, B);
)
...+>
-kunmap(page);
// No need for the ptr variable removal
//
// Catch all
//
@ memcpy_rule3 @
expression page;
expression GenTo, GenFrom, GenSize;
identifier ptr;
type VP;
@@
(
-VP ptr = kmap(page);
|
-ptr = kmap(page);
|
-VP ptr = kmap_atomic(page);
|
-ptr = kmap_atomic(page);
)
<+...
(
//
// Some call sites have complex expressions within the memcpy
// match a catch all to be evaluated by hand.
//
-memcpy(GenTo, GenFrom, GenSize);
+memcpy_to_pageExtra(page, GenTo, GenFrom, GenSize);
+memcpy_from_pageExtra(GenTo, page, GenFrom, GenSize);
)
...+>
(
-kunmap(page);
|
-kunmap_atomic(ptr);
)
// Remove any pointers left unused
@
depends on memcpy_rule3
@
identifier memcpy_rule3.ptr;
type VP, VP1;
@@
-VP ptr;
... when != ptr;
? VP1 ptr;
//
Signed-off-by: Ira Weiny
squash: memcpy
---
fs/btrfs/compression.c | 6 ++
fs/btrfs/lzo.c | 4 ++--
fs/btrfs/reflink.c | 6 +-
fs/btrfs/send.c| 7 ++-
fs/btrfs/zlib.c| 5 ++---
fs/btrfs/zstd.c| 6 ++
6 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 5ae3fa0386b7..047b632b4139 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -1231,7 +1231,6 @@ int btrfs_decompress_buf2page(const char *buf, unsigned
long buf_start,
unsigned long prev_start_byte;
unsigned long working_bytes = total_out - buf_start;
unsigned long bytes;
- char *kaddr;
struct bio_vec bvec = bio_iter_iovec(bio, bio->bi_iter);
/*
@@ -1262,9 +1261,8 @@ int btrfs_decompress_buf2page(const char *buf, unsigned
long buf_start,
PAGE_SIZE - (buf_offset % PAGE_SIZE));
bytes = min(bytes, working_bytes);
- kaddr = kmap_atomic(bvec.bv_page);
- memcpy(kaddr + bvec.bv_offset, buf + buf_offset, bytes);
- kunmap_atomic(kaddr);
+ memcpy_to_page(bvec.bv_page, bvec.bv_offset, buf + buf_offset,
+ bytes);
flush_dcache_page(bvec.bv_page);
buf_offset += bytes;
diff --git a/fs/btrfs/lzo.c b/fs/btrfs/lzo.c
index aa9cd11f4b78..9084a950dc09 100644
--- a/fs/btrfs/lzo.c
+++ b/fs/btrfs/lzo.c
@@ -467,7 +467,7 @@ int lzo_decompress(struct list_head *ws, unsigned char
*data_in,
destlen = min_t(unsigned long, destlen, PAGE_SIZE);
bytes = min_t(unsigned long, destlen, out_len - start_byte);
- kaddr = kmap_atomic(dest_page);
+ kaddr = kmap_local_page(dest_page);
memcpy(kaddr, workspace->buf + start_byte, bytes);
/*
@@ -477,7 +477,7 @@ int lzo_decompress(struct list_head *ws, unsigned char
*data_in,
*/
if (bytes < destlen)
memset(kaddr+bytes, 0, destlen-bytes);
- kunmap_atomic(kaddr);
+ kunmap_local(kaddr);
out:
return ret;
}
diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
index b03e7891394e..74c62e49c0c9 100644
--- a/fs/btrfs/reflink.c
+++ b/fs/btrfs/reflink.c
@@ -103,12 +103,8 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
set_bit(BTRFS_INODE_NO_DELALLOC_FLUSH, >runtime_flags);
if (comp_type == BTRFS_COMPRESS_NONE) {
- char *map;
-
- map = kmap(page);
- memcpy(map, data_start, datal);
+ memcpy_to_page(page, 0, data_start, datal);
[PATCH 3/4] fs/btrfs: Use copy_highpage() instead of 2 kmaps()
From: Ira Weiny
Development of this patch was aided by the following coccinelle script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/copypage/kunmap pattern and replace with copy_highpage calls
//
// NOTE: The expressions in the copy page version of this kmap pattern are
// overly complex and so these all need individual attention.
//
// Confidence: Low
// Copyright: (C) 2021 Intel Corporation
// URL: http://coccinelle.lip6.fr/
// Comments:
// Options:
//
// Then a copy_page where we have 2 pages involved.
//
@ copy_page_rule @
expression page, page2, To, From, Size;
identifier ptr, ptr2;
type VP, VP2;
@@
/* kmap */
(
-VP ptr = kmap(page);
...
-VP2 ptr2 = kmap(page2);
|
-VP ptr = kmap_atomic(page);
...
-VP2 ptr2 = kmap_atomic(page2);
|
-ptr = kmap(page);
...
-ptr2 = kmap(page2);
|
-ptr = kmap_atomic(page);
...
-ptr2 = kmap_atomic(page2);
)
// 1 or more copy versions of the entire page
<+...
(
-copy_page(To, From);
+copy_highpage(To, From);
|
-memmove(To, From, Size);
+memmoveExtra(To, From, Size);
)
...+>
/* kunmap */
(
-kunmap(page2);
...
-kunmap(page);
|
-kunmap(page);
...
-kunmap(page2);
|
-kmap_atomic(ptr2);
...
-kmap_atomic(ptr);
)
// Remove any pointers left unused
@
depends on copy_page_rule
@
identifier copy_page_rule.ptr;
identifier copy_page_rule.ptr2;
type VP, VP1;
type VP2, VP21;
@@
-VP ptr;
... when != ptr;
? VP1 ptr;
-VP2 ptr2;
... when != ptr2;
? VP21 ptr2;
//
Signed-off-by: Ira Weiny
---
fs/btrfs/raid56.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index dbf52f1a379d..7c3f6dc918c1 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -250,8 +250,6 @@ int btrfs_alloc_stripe_hash_table(struct btrfs_fs_info
*info)
static void cache_rbio_pages(struct btrfs_raid_bio *rbio)
{
int i;
- char *s;
- char *d;
int ret;
ret = alloc_rbio_pages(rbio);
@@ -262,13 +260,7 @@ static void cache_rbio_pages(struct btrfs_raid_bio *rbio)
if (!rbio->bio_pages[i])
continue;
- s = kmap(rbio->bio_pages[i]);
- d = kmap(rbio->stripe_pages[i]);
-
- copy_page(d, s);
-
- kunmap(rbio->bio_pages[i]);
- kunmap(rbio->stripe_pages[i]);
+ copy_highpage(rbio->stripe_pages[i], rbio->bio_pages[i]);
SetPageUptodate(rbio->stripe_pages[i]);
}
set_bit(RBIO_CACHE_READY_BIT, >flags);
--
2.28.0.rc0.12.gb6a658bd00c9
[PATCH 0/3] drivers/net/ethernet/amd: Follow style guide
This patchset updates atarilance.c and sun3lance.c to follow the kernel style guide. Each patch tackles a different issue in the style guide. -Amy IP Amy Parker (3): drivers/net/ethernet/amd: Correct spacing around C keywords drivers/net/ethernet/amd: Fix bracket matching and line levels drivers/net/ethernet/amd: Break apart one-lined expressions drivers/net/ethernet/amd/atarilance.c | 64 ++- drivers/net/ethernet/amd/sun3lance.c | 64 +++ 2 files changed, 69 insertions(+), 59 deletions(-) -- 2.29.2
[PATCH v2 2/5] dax-device: Properly handle drivers without remove callback
If all resources are allocated in .probe() using devm_ functions it
might make sense to not provide a .remove() callback. Then the right
thing is to just return success.
Signed-off-by: Uwe Kleine-König
---
drivers/dax/bus.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 72fc4b9b9ae6..2c9e3f6f615f 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -178,8 +178,12 @@ static int dax_bus_remove(struct device *dev)
{
struct dax_device_driver *dax_drv = to_dax_drv(dev->driver);
struct dev_dax *dev_dax = to_dev_dax(dev);
+ int ret = 0;
- return dax_drv->remove(dev_dax);
+ if (dax_drv->remove)
+ ret = dax_drv->remove(dev_dax);
+
+ return ret;
}
static struct bus_type dax_bus_type = {
--
2.29.2
[RFC v1 16/26] x86/boot: Avoid #VE during compressed boot for TDX platforms
From: Sean Christopherson Avoid operations which will inject #VE during compressed boot, which is obviously fatal for TDX platforms. Details are, 1. TDX module injects #VE if a TDX guest attempts to write EFER. So skip the WRMSR to set EFER.LME=1 if it's already set. TDX also forces EFER.LME=1, i.e. the branch will always be taken and thus the #VE avoided. 2. TDX module also injects a #VE if the guest attempts to clear CR0.NE. Ensure CR0.NE is set when loading CR0 during compressed boot. The Setting CR0.NE should be a nop on all CPUs that support 64-bit mode. Signed-off-by: Sean Christopherson Reviewed-by: Andi Kleen Signed-off-by: Kuppuswamy Sathyanarayanan --- arch/x86/boot/compressed/head_64.S | 5 +++-- arch/x86/boot/compressed/pgtable.h | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S index e94874f4bbc1..37c2f37d4a0d 100644 --- a/arch/x86/boot/compressed/head_64.S +++ b/arch/x86/boot/compressed/head_64.S @@ -616,8 +616,9 @@ SYM_CODE_START(trampoline_32bit_src) movl$MSR_EFER, %ecx rdmsr btsl$_EFER_LME, %eax + jc 1f wrmsr - popl%edx +1: popl%edx popl%ecx /* Enable PAE and LA57 (if required) paging modes */ @@ -636,7 +637,7 @@ SYM_CODE_START(trampoline_32bit_src) pushl %eax /* Enable paging again */ - movl$(X86_CR0_PG | X86_CR0_PE), %eax + movl$(X86_CR0_PG | X86_CR0_NE | X86_CR0_PE), %eax movl%eax, %cr0 lret diff --git a/arch/x86/boot/compressed/pgtable.h b/arch/x86/boot/compressed/pgtable.h index 6ff7e81b5628..cc9b2529a086 100644 --- a/arch/x86/boot/compressed/pgtable.h +++ b/arch/x86/boot/compressed/pgtable.h @@ -6,7 +6,7 @@ #define TRAMPOLINE_32BIT_PGTABLE_OFFSET0 #define TRAMPOLINE_32BIT_CODE_OFFSET PAGE_SIZE -#define TRAMPOLINE_32BIT_CODE_SIZE 0x70 +#define TRAMPOLINE_32BIT_CODE_SIZE 0x80 #define TRAMPOLINE_32BIT_STACK_END TRAMPOLINE_32BIT_SIZE -- 2.25.1
[PATCH 1/4] mm/highmem: Lift memcpy_[to|from]_page to core
From: Ira Weiny
Working through a conversion to a call kmap_local_page() instead of
kmap() revealed many places where the pattern kmap/memcpy/kunmap
occurred.
Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
Viro all suggested putting this code into helper functions. Al Viro
further pointed out that these functions already existed in the iov_iter
code.[1]
Various locations for the lifted functions were considered.
Headers like mm.h or string.h seem ok but don't really portray the
functionality well. pagemap.h made some sense but is for page cache
functionality.[2]
Another alternative would be to create a new header for the promoted
memcpy functions, but it masks the fact that these are designed to copy
to/from pages using the kernel direct mappings and complicates matters
with a new header.
Placing these functions in 'highmem.h' is suboptimal especially with the
changes being proposed in the functionality of kmap. From a caller
perspective including/using 'highmem.h' implies that the functions
defined in that header are only required when highmem is in use which is
increasingly not the case with modern processors. However, highmem.h is
where all the current functions like this reside (zero_user(),
clear_highpage(), clear_user_highpage(), copy_user_highpage(), and
copy_highpage()). So it makes the most sense even though it is
distasteful for some.[3]
Lift memcpy_to_page() and memcpy_from_page() to pagemap.h.
Remove memzero_page() in favor of zero_user() to zero a page.
Add a memcpy_page(), memmove_page, and memset_page() to cover more
kmap/mem*/kunmap. patterns.
Add BUG_ON bounds checks to ensure the newly lifted page memory
operations do not result in corrupted data in neighbor pages and to make
them consistent with zero_user().[4]
Finally use kmap_local_page() in all the new calls.
[1] https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/
https://lore.kernel.org/lkml/20201013112544.ga5...@infradead.org/
[2] https://lore.kernel.org/lkml/20201208122316.gh7...@casper.infradead.org/
[3] https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/#t
https://lore.kernel.org/lkml/20201208163814.gn1563...@iweiny-desk2.sc.intel.com/
[4]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com/
Cc: Boris Pismenny
Cc: Or Gerlitz
Cc: Dave Hansen
Suggested-by: Matthew Wilcox
Suggested-by: Christoph Hellwig
Suggested-by: Dan Williams
Suggested-by: Al Viro
Suggested-by: Eric Biggers
Signed-off-by: Ira Weiny
---
Chagnes for V4:
Update commit message to say kmap_local_page() since
kmap_thread() is no longer valid
Changes for V3:
From Matthew Wilcox
Move calls to highmem.h
Add BUG_ON()
Changes for V2:
From Thomas Gleixner
Change kmap_atomic() to kmap_local_page() after basing
on tip/core/mm
From Joonas Lahtinen
Reverse offset/val in memset_page()
---
include/linux/highmem.h | 53 +
lib/iov_iter.c | 26 +++-
2 files changed, 56 insertions(+), 23 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index d2c70d3772a3..c642dd64ea3f 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -276,4 +276,57 @@ static inline void copy_highpage(struct page *to, struct
page *from)
#endif
+static inline void memcpy_page(struct page *dst_page, size_t dst_off,
+ struct page *src_page, size_t src_off,
+ size_t len)
+{
+ char *dst = kmap_local_page(dst_page);
+ char *src = kmap_local_page(src_page);
+
+ BUG_ON(dst_off + len > PAGE_SIZE || src_off + len > PAGE_SIZE);
+ memcpy(dst + dst_off, src + src_off, len);
+ kunmap_local(src);
+ kunmap_local(dst);
+}
+
+static inline void memmove_page(struct page *dst_page, size_t dst_off,
+ struct page *src_page, size_t src_off,
+ size_t len)
+{
+ char *dst = kmap_local_page(dst_page);
+ char *src = kmap_local_page(src_page);
+
+ BUG_ON(dst_off + len > PAGE_SIZE || src_off + len > PAGE_SIZE);
+ memmove(dst + dst_off, src + src_off, len);
+ kunmap_local(src);
+ kunmap_local(dst);
+}
+
+static inline void memcpy_from_page(char *to, struct page *page, size_t
offset, size_t len)
+{
+ char *from = kmap_local_page(page);
+
+ BUG_ON(offset + len > PAGE_SIZE);
+ memcpy(to, from + offset, len);
+ kunmap_local(from);
+}
+
+static inline void memcpy_to_page(struct page *page, size_t offset, const char
*from, size_t len)
+{
+ char *to = kmap_local_page(page);
+
+ BUG_ON(offset + len > PAGE_SIZE);
+ memcpy(to + offset, from, len);
+ kunmap_local(to);
+}
+
+static inline void memset_page(struct page *page, size_t offset, int val,
Re: [PATCH] drm/msm/dp: reset dp controller only at boot up and pm_resume
Quoting Kuogee Hsieh (2021-02-05 12:44:38)
> DP_SW_RESET is the global SW reset that is used to initialize DP
> controller. If DP_SW_RESET executed during connection setup,
> two HPD related side effects may occurred,
> 1) pending HPD interrupts cleared unexpected
> 2) re start debounce logic which trigger another interrupt
> This patch only issue DP_SW_RESET at boot up and pm_resume.
> This patch also reinit video_comp before configure dp controller
> to avoid missing VIDEO_READY interrupt.
>
> Fixes: 9fc418430c65 ("drm/msm/dp: unplug interrupt missed after irq_hpd
> handler")
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
[PATCH v4 1/8] driver core: fw_devlink: Detect supplier devices that will never be added
During the initial parsing of firmware by fw_devlink, fw_devlink might
infer that some supplier firmware nodes would get populated as devices.
But the inference is not always correct. This patch tries to logically
detect and fix such mistakes as boot progresses or more devices probe.
fw_devlink makes a fundamental assumption that once a device binds to a
driver, it will populate (i.e: add as struct devices) all the child
firmware nodes that could be populated as devices (if they aren't
populated already).
So, whenever a device probes, we check all its child firmware nodes. If
a child firmware node has a corresponding device populated, we don't
modify the child node or its descendants. However, if a child firmware
node has not been populated as a device, we delete all the fwnode links
where the child node or its descendants are suppliers. This ensures that
no other device is blocked on a firmware node that will never be
populated as a device. We also mark such fwnodes as NOT_DEVICE, so that
no new fwnode links are created with these nodes as suppliers.
Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
Signed-off-by: Saravana Kannan
Acked-by: Rafael J. Wysocki
---
drivers/base/core.c| 31 ---
include/linux/fwnode.h | 2 ++
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 484a942884ba..c95b1daabac7 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -148,6 +148,21 @@ void fwnode_links_purge(struct fwnode_handle *fwnode)
fwnode_links_purge_consumers(fwnode);
}
+static void fw_devlink_purge_absent_suppliers(struct fwnode_handle *fwnode)
+{
+ struct fwnode_handle *child;
+
+ /* Don't purge consumer links of an added child */
+ if (fwnode->dev)
+ return;
+
+ fwnode->flags |= FWNODE_FLAG_NOT_DEVICE;
+ fwnode_links_purge_consumers(fwnode);
+
+ fwnode_for_each_available_child_node(fwnode, child)
+ fw_devlink_purge_absent_suppliers(child);
+}
+
#ifdef CONFIG_SRCU
static DEFINE_MUTEX(device_links_lock);
DEFINE_STATIC_SRCU(device_links_srcu);
@@ -1154,12 +1169,22 @@ void device_links_driver_bound(struct device *dev)
LIST_HEAD(sync_list);
/*
-* If a device probes successfully, it's expected to have created all
+* If a device binds successfully, it's expected to have created all
* the device links it needs to or make new device links as it needs
-* them. So, it no longer needs to wait on any suppliers.
+* them. So, fw_devlink no longer needs to create device links to any
+* of the device's suppliers.
+*
+* Also, if a child firmware node of this bound device is not added as
+* a device by now, assume it is never going to be added and make sure
+* other devices don't defer probe indefinitely by waiting for such a
+* child device.
*/
- if (dev->fwnode && dev->fwnode->dev == dev)
+ if (dev->fwnode && dev->fwnode->dev == dev) {
+ struct fwnode_handle *child;
fwnode_links_purge_suppliers(dev->fwnode);
+ fwnode_for_each_available_child_node(dev->fwnode, child)
+ fw_devlink_purge_absent_suppliers(child);
+ }
device_remove_file(dev, _attr_waiting_for_supplier);
device_links_write_lock();
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index fde4ad97564c..21082f11473f 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -19,8 +19,10 @@ struct device;
* fwnode link flags
*
* LINKS_ADDED: The fwnode has already be parsed to add fwnode links.
+ * NOT_DEVICE: The fwnode will never be populated as a struct device.
*/
#define FWNODE_FLAG_LINKS_ADDEDBIT(0)
+#define FWNODE_FLAG_NOT_DEVICE BIT(1)
struct fwnode_handle {
struct fwnode_handle *secondary;
--
2.30.0.478.g8a0d178c01-goog
Re: [PATCH] printk: Userspace format enumeration support
Hi Steven, Steven Rostedt writes: Interesting, because when I was looking at the original patch (looked at the lore link before reading your reply), I thought to myself "this looks exactly like what I did for trace_printk formats", which the above file is where it is shown. I'm curious if this work was inspired by that? The double __builtin_constant_p() trick was suggested by Johannes based on prior art in trace_puts() just prior to patch submission. Other than that, it seems we came up with basically the same solution independently. :-) Anyway, there is something wrong at the moment. The output looks fine with cat. But "less" says that it is a binary format and the output is a bit messy: Hmm, that's usually the case when lseek gets messed up. Not sure how that happened. It looks as intended to me -- none of the newlines, nulls, or other control sequences are escaped currently, since I didn't immediately see a reason to do that. If that's a blocker though, I'm happy to change it. $> less /proc/printk_formats "/proc/printk_formats" may be a binary file. See it anyway? vmlinux,^A3Warning: unable to open an initial console. ^@vmlinux,^A3Failed to execute %s (error %d) ^@vmlinux,^A6Kernel memory protection disabled. ^@vmlinux,^A3Starting init: %s exists but couldn't execute it (error %d) That is for now. I still have to think about it. And I am also curious about what others thing about this idea. I'm not against the idea. I don't think it belongs in /proc. Perhaps debugfs is a better place to put it. Any location is fine with me, as long as it gets to userspace. How does /printk/formats or /printk/formats/ sound to you? Thanks, Chris
[PATCH] KVM: SVM: Delay restoration of host MSR_TSC_AUX until return to userspace
Use KVM's "user return MSRs" framework to defer restoring the host's
MSR_TSC_AUX until the CPU returns to userspace. Add/improve comments to
clarify why MSR_TSC_AUX is intercepted on both RDMSR and WRMSR, and why
it's safe for KVM to keep the guest's value loaded even if KVM is
scheduled out.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/svm.c | 50 ++
arch/x86/kvm/svm/svm.h | 7 --
2 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 4141caea857a..a5231a8841ff 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -220,6 +220,15 @@ struct kvm_ldttss_desc {
DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
+/*
+ * Only MSR_TSC_AUX is switched via the user return hook. EFER is switched via
+ * the VMCB, and the SYSCALL/SYSENTER MSRs are handled by VMLOAD/VMSAVE.
+ *
+ * RDTSCP and RDPID are not used in the kernel, specifically to allow KVM to
+ * defer the restoration of TSC_AUX until the CPU returns to userspace.
+ */
+#define TSC_AUX_URET_SLOT 0
+
static const u32 msrpm_ranges[] = {0, 0xc000, 0xc001};
#define NUM_MSR_MAPS ARRAY_SIZE(msrpm_ranges)
@@ -965,6 +974,9 @@ static __init int svm_hardware_setup(void)
kvm_tsc_scaling_ratio_frac_bits = 32;
}
+ if (boot_cpu_has(X86_FEATURE_RDTSCP))
+ kvm_define_user_return_msr(TSC_AUX_URET_SLOT, MSR_TSC_AUX);
+
/* Check for pause filtering support */
if (!boot_cpu_has(X86_FEATURE_PAUSEFILTER)) {
pause_filter_count = 0;
@@ -1418,19 +1430,10 @@ static void svm_prepare_guest_switch(struct kvm_vcpu
*vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
struct svm_cpu_data *sd = per_cpu(svm_data, vcpu->cpu);
- unsigned int i;
if (svm->guest_state_loaded)
return;
- /*
-* Certain MSRs are restored on VMEXIT (sev-es), or vmload of host save
-* area (non-sev-es). Save ones that aren't so we can restore them
-* individually later.
-*/
- for (i = 0; i < NR_HOST_SAVE_USER_MSRS; i++)
- rdmsrl(host_save_user_msrs[i], svm->host_user_msrs[i]);
-
/*
* Save additional host state that will be restored on VMEXIT (sev-es)
* or subsequent vmload of host save area.
@@ -1449,29 +1452,15 @@ static void svm_prepare_guest_switch(struct kvm_vcpu
*vcpu)
}
}
- /* This assumes that the kernel never uses MSR_TSC_AUX */
if (static_cpu_has(X86_FEATURE_RDTSCP))
- wrmsrl(MSR_TSC_AUX, svm->tsc_aux);
+ kvm_set_user_return_msr(TSC_AUX_URET_SLOT, svm->tsc_aux, -1ull);
svm->guest_state_loaded = true;
}
static void svm_prepare_host_switch(struct kvm_vcpu *vcpu)
{
- struct vcpu_svm *svm = to_svm(vcpu);
- unsigned int i;
-
- if (!svm->guest_state_loaded)
- return;
-
- /*
-* Certain MSRs are restored on VMEXIT (sev-es), or vmload of host save
-* area (non-sev-es). Restore the ones that weren't.
-*/
- for (i = 0; i < NR_HOST_SAVE_USER_MSRS; i++)
- wrmsrl(host_save_user_msrs[i], svm->host_user_msrs[i]);
-
- svm->guest_state_loaded = false;
+ to_svm(vcpu)->guest_state_loaded = false;
}
static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
@@ -2948,12 +2937,15 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr)
return 1;
/*
-* This is rare, so we update the MSR here instead of using
-* direct_access_msrs. Doing that would require a rdmsr in
-* svm_vcpu_put.
+* TSC_AUX is usually changed only during boot and never read
+* directly. Intercept TSC_AUX instead of exposing it to the
+* guest via direct_acess_msrs, and switch it via user return.
*/
svm->tsc_aux = data;
- wrmsrl(MSR_TSC_AUX, svm->tsc_aux);
+
+ preempt_disable();
+ kvm_set_user_return_msr(TSC_AUX_URET_SLOT, data, -1ull);
+ preempt_enable();
break;
case MSR_IA32_DEBUGCTLMSR:
if (!boot_cpu_has(X86_FEATURE_LBRV)) {
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 39e071fdab0c..4053f564e27e 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -23,11 +23,6 @@
#define __sme_page_pa(x) __sme_set(page_to_pfn(x) << PAGE_SHIFT)
-static const u32 host_save_user_msrs[] = {
- MSR_TSC_AUX,
-};
-#define NR_HOST_SAVE_USER_MSRS ARRAY_SIZE(host_save_user_msrs)
-
#define MAX_DIRECT_ACCESS_MSRS 18
#define MSRPM_OFFSETS 16
extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly;
@@ -115,8 +110,6 @@ struct vcpu_svm {
u64 next_rip;
- u64 host_user_msrs[NR_HOST_SAVE_USER_MSRS];
-
u64
Re: [PATCH RESEND V12 2/8] fuse: 32-bit user space ioctl compat for fuse device
On Thu, Jan 28, 2021 at 10:15 PM Alessio Balsini wrote:
>
> Hi all,
>
> I'm more than happy to change the interface into something that is
> objectively better and accepted by everyone.
> I would really love to reach the point at which we have a "stable-ish"
> UAPI as soon as possible.
>
> I've been thinking about a few possible approaches to fix the issue, yet
> to preserve its flexibility. These are mentioned below.
>
>
> Solution 1: Size
>
> As mentioned in my previous email, one solution could be to introduce
> the "size" field to allow the structure to grow in the future.
>
> struct fuse_passthrough_out {
> uint32_tsize; // Size of this data structure
> uint32_tfd;
> };
>
> The problem here is that we are making the promise that all the upcoming
> fields are going to be maintained forever and at the offsets they were
> originally defined.
>
>
> Solution 2: Version
>
> Another solution could be to s/size/version, where for every version of
> FUSE passthrough we reserve the right to modifying the fields over time,
> casting them to the right data structure according to the version.
>
>
> Solution 3: Type
>
> Using an enumerator to define the data structure content and purpose is
> the most flexible solution I can think of. This would for example allow
> us to substitute FUSE_DEV_IOC_PASSTHROUGH_OPEN with the generic
> FUSE_DEV_IOC_PASSTHROUGH and having a single ioctl for any eventually
> upcoming passthrough requests.
>
> enum fuse_passthrough_type {
> FUSE_PASSTHROUGH_OPEN
> };
>
> struct fuse_passthrough_out {
> uint32_t type; /* as defined by enum fuse_passthrough_type */
> union {
> uint32_t fd;
> };
> };
>
> This last is my favorite, as regardless the minimal logic required to
> detect the size and content of the struct (not required now as we only
> have a single option), it would also allow to do some kind of interface
> versioning (e.g., in case we want to implement
> FUSE_PASSTHROUGH_OPEN_V2).
>
Usually a new type of ioctl will be added in such cases. If we want to
stick to the same ioctl number, it might be easier to add a `flags`
field to differentiate compatible passthrough ioctls. So in future, if
a new interface is compatible with the existing one, we can use flags
to tell it. If it is not compatible, we still need to add a new ioctl.
wdyt?
struct fuse_passthrough_out {
uint32_t flags;
union {
uint32_t fd;
};
};
This somehow follows the "Flags as a system call API design pattern"
(https://lwn.net/Articles/585415/).
Just my two cents.
Cheers,
Tao
--
Into Sth. Rich & Strange
[PATCH] ARM: configs: at91: enable drivers for sam9x60
Enable drivers for sam9x60/sam9x60-ek: - shutdown controller - CAN - AT24 EEPROM (present on SAM9X60-EK) - MCP23S08 (present on SAM9X60-EK) - AES, TDES, SHA And use "make savedefconfig". Signed-off-by: Claudiu Beznea --- arch/arm/configs/at91_dt_defconfig | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 5f3415c743ec..e274f8c492d2 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -17,8 +17,6 @@ CONFIG_SOC_SAM9X60=y # CONFIG_ATMEL_CLOCKSOURCE_PIT is not set CONFIG_AEABI=y CONFIG_UACCESS_WITH_MEMCPY=y -CONFIG_ZBOOT_ROM_TEXT=0x0 -CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x2110,25165824 root=/dev/ram0 rw" @@ -38,6 +36,8 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_INET_DIAG is not set CONFIG_IPV6_SIT_6RD=y +CONFIG_CAN=y +CONFIG_CAN_AT91=y CONFIG_CFG80211=y CONFIG_MAC80211=y CONFIG_DEVTMPFS=y @@ -58,6 +58,7 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_ATMEL_SSC=y +CONFIG_EEPROM_AT24=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y # CONFIG_SCSI_LOWLEVEL is not set @@ -91,7 +92,6 @@ CONFIG_RT2800USB_UNKNOWN=y CONFIG_RTL8187=m CONFIG_RTL8192CU=m # CONFIG_RTLWIFI_DEBUG is not set -CONFIG_INPUT_POLLDEV=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y # CONFIG_KEYBOARD_ATKBD is not set @@ -111,8 +111,8 @@ CONFIG_I2C_GPIO=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y CONFIG_SPI_ATMEL_QUADSPI=y +CONFIG_PINCTRL_MCP23S08=m CONFIG_POWER_RESET=y -# CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC is not set CONFIG_POWER_SUPPLY=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y @@ -208,7 +208,9 @@ CONFIG_NLS_UTF8=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m -# CONFIG_CRYPTO_HW is not set +CONFIG_CRYPTO_DEV_ATMEL_AES=y +CONFIG_CRYPTO_DEV_ATMEL_TDES=y +CONFIG_CRYPTO_DEV_ATMEL_SHA=y CONFIG_CRC_CCITT=y CONFIG_FONTS=y CONFIG_FONT_8x8=y -- 2.7.4
Re: [External] Re: [PATCH] mm: memcontrol: fix missing wakeup oom task
On Fri, Feb 5, 2021 at 4:24 PM Michal Hocko wrote:
>
> On Fri 05-02-21 14:23:10, Muchun Song wrote:
> > We call memcg_oom_recover() in the uncharge_batch() to wakeup OOM task
> > when page uncharged, but for the slab pages, we do not do this when page
> > uncharged.
>
> How does the patch deal with this?
When we uncharge a slab page via __memcg_kmem_uncharge,
actually, this path forgets to do this for us compared to
uncharge_batch(). Right?
>
> > When we drain per cpu stock, we also should do this.
>
> Can we have anything the per-cpu stock while entering the OOM path. IIRC
> we do drain all cpus before entering oom path.
You are right. I did not notice this. Thank you.
>
> > The memcg_oom_recover() is small, so make it inline.
>
> Does this lead to any code generation improvements? I would expect
> compiler to be clever enough to inline static functions if that pays
> off. If yes make this a patch on its own.
I have disassembled the code, I see memcg_oom_recover is not
inline. Maybe because memcg_oom_recover has a lot of callers.
Just guess.
(gdb) disassemble uncharge_batch
[...]
0x81341c73 <+227>: callq 0x8133c420
0x81341c78 <+232>: jmpq 0x81341bc0
0x81341c7d <+237>: callq 0x8133e2c0
>
> > And the parameter
> > of memcg cannot be NULL, so remove the check.
>
> 2bd9bb206b338 has introduced the check without any explanation
> whatsoever. I indeed do not see any potential path to provide a NULL
> memcg here. This is an internal function so the check is unnecessary
> indeed. Please make it a patch on its own.
OK. Will do this. Thanks.
>
> > Signed-off-by: Muchun Song
> > ---
> > mm/memcontrol.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 8c035846c7a4..8569f4dbea2a 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -1925,7 +1925,7 @@ static int memcg_oom_wake_function(wait_queue_entry_t
> > *wait,
> > return autoremove_wake_function(wait, mode, sync, arg);
> > }
> >
> > -static void memcg_oom_recover(struct mem_cgroup *memcg)
> > +static inline void memcg_oom_recover(struct mem_cgroup *memcg)
> > {
> > /*
> >* For the following lockless ->under_oom test, the only required
> > @@ -1935,7 +1935,7 @@ static void memcg_oom_recover(struct mem_cgroup
> > *memcg)
> >* achieved by invoking mem_cgroup_mark_under_oom() before
> >* triggering notification.
> >*/
> > - if (memcg && memcg->under_oom)
> > + if (memcg->under_oom)
> > __wake_up(_oom_waitq, TASK_NORMAL, 0, memcg);
> > }
> >
> > @@ -2313,6 +2313,7 @@ static void drain_stock(struct memcg_stock_pcp *stock)
> > page_counter_uncharge(>memory, stock->nr_pages);
> > if (do_memsw_account())
> > page_counter_uncharge(>memsw, stock->nr_pages);
> > + memcg_oom_recover(old);
> > stock->nr_pages = 0;
> > }
> >
> > --
> > 2.11.0
>
> --
> Michal Hocko
> SUSE Labs
Re: [PATCH] sound: x86: Trivial spell fixes throughout the file intel_hdmi_audio.c
On 10:39 Fri 05 Feb 2021, Takashi Iwai wrote: On Fri, 05 Feb 2021 10:32:14 +0100, Bhaskar Chowdhury wrote: s/confgiuration/configuration/ s/Calculte/Calculate/ s/unreference/unreferenced/ The last one isn't correct. It was meant as a positive form, so if any, it's "unrefer", but "reference" could be used as a verb in the tech term, so IMO we can keep as is. Good catch...thanks Takashi! As you like. :) thanks, Takashi Signed-off-by: Bhaskar Chowdhury --- sound/x86/intel_hdmi_audio.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c index 9f9fcd2749f2..89ddd9dd8fde 100644 --- a/sound/x86/intel_hdmi_audio.c +++ b/sound/x86/intel_hdmi_audio.c @@ -342,7 +342,7 @@ static int had_prog_status_reg(struct snd_pcm_substream *substream, /* * function to initialize audio - * registers and buffer confgiuration registers + * registers and buffer configuration registers * This function is called in the prepare callback */ static int had_init_audio_ctrl(struct snd_pcm_substream *substream, @@ -611,7 +611,7 @@ static void had_prog_dip(struct snd_pcm_substream *substream, frame2.regx.chnl_cnt = substream->runtime->channels - 1; frame3.regx.chnl_alloc = ca; - /* Calculte the byte wide checksum for all valid DIP words */ + /* Calculate the byte wide checksum for all valid DIP words */ for (i = 0; i < BYTES_PER_WORD; i++) checksum += (info_frame >> (i * 8)) & 0xff; for (i = 0; i < BYTES_PER_WORD; i++) @@ -1109,7 +1109,7 @@ static int had_pcm_close(struct snd_pcm_substream *substream) intelhaddata = snd_pcm_substream_chip(substream); - /* unreference and sync with the pending PCM accesses */ + /* unreferenced and sync with the pending PCM accesses */ spin_lock_irq(>had_spinlock); intelhaddata->stream_info.substream = NULL; intelhaddata->stream_info.substream_refcount--; -- 2.30.0 signature.asc Description: PGP signature
Re: [PATCH V7 4/6] kbuild: Add support to build overlays (%.dtbo)
On 05-02-21, 10:41, Geert Uytterhoeven wrote: > Hi Viresh, > > On Fri, Feb 5, 2021 at 10:25 AM Viresh Kumar wrote: > > On 05-02-21, 10:02, Geert Uytterhoeven wrote: > > > Thanks for your patch > > > (which I only noticed because it appeared in dt-rh/for-next ;-) > > > > > > On Fri, Jan 29, 2021 at 8:31 AM Viresh Kumar > > > wrote: > > > > Add support for building DT overlays (%.dtbo). The overlay's source file > > > > will have the usual extension, i.e. .dts, though the blob will have > > > > > > Why use .dts and not .dtso for overlays? > > > Because you originally (until v5) had a single rule for building .dtb > > > and .dtbo files? > > > > I am fine with doing that as well if Rob and David agree to it. Rob > > did suggest that at one point but we didn't do much about it later on > > for some reason. > > > > FWIW, this will also require a change in the DTC compiler. > > Care to explain why? I've been using .dtsi for ages in > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/renesas-overlays I don't see you building them anywhere, they aren't added to the Makefile ever. What am I missing ? actually none of the dtso's were added to any makefile in that branch. Anyway, the DTC needs to know how to treat the dtso format and it will error out currently with unknown format kind of errors. Below email [1] have some information on the kind of changes required here. Also note that we had to do similar changes for dtbo earlier [2]. -- viresh [1] https://lore.kernel.org/lkml/cak7lnasvicotgr7ydtfh0o+pau+x-p2nwdy4opmuxrr51aw...@mail.gmail.com/ [2] https://lore.kernel.org/lkml/30fd0e5f2156665c713cf191c5fea9a5548360c0.1609926856.git.viresh.ku...@linaro.org/
Re: [PATCH] perf metricgroup: Fix system PMU metrics
that's fixing the issue for me, this was crashing:
# perf stat -a -I 1000 -M L1D_Cache_Fill_BW,L2_Cache_Fill_BW
To cover this scenario (multiple metrics listed), how about a simple
addition like:
>8
From bd2ded1b0ef4962a9443cd180eed4e5c5b75ae5f Mon Sep 17 00:00:00 2001
From: John Garry
Date: Fri, 5 Feb 2021 09:50:54 +
Subject: [PATCH] perf test: Add parse-metric list test scenario
diff --git a/tools/perf/tests/parse-metric.c
b/tools/perf/tests/parse-metric.c
index ce7be37f0d88..0626e389354c 100644
--- a/tools/perf/tests/parse-metric.c
+++ b/tools/perf/tests/parse-metric.c
@@ -201,6 +201,13 @@ static int compute_metric_group(const char *name,
struct value *vals,
return __compute_metric(name, vals, name1, ratio1, name2, ratio2);
}
+static int compute_metric_list(const char *list, struct value *vals,
+ const char *name1, double *ratio1,
+ const char *name2, double *ratio2)
+{
+ return __compute_metric(list, vals, name1, ratio1, name2, ratio2);
+}
+
static int test_ipc(void)
{
double ratio;
@@ -279,7 +286,7 @@ static int test_cache_miss_cycles(void)
*/
static int test_dcache_l2(void)
{
- double ratio;
+ double ratio, ratio1, ratio2;
struct value vals[] = {
{ .event = "l2_rqsts.demand_data_rd_hit", .val = 100 },
{ .event = "l2_rqsts.pf_hit", .val = 200 },
@@ -301,6 +308,15 @@ static int test_dcache_l2(void)
TEST_ASSERT_VAL("DCache_L2_Misses failed, wrong ratio",
ratio == 0.7);
+
+ TEST_ASSERT_VAL("failed to compute metric",
+ compute_metric_list("DCache_L2_Hits,DCache_L2_Misses", vals,
"DCache_L2_Hits", , "DCache_L2_Misses", ) == 0);
+
+ TEST_ASSERT_VAL("DCache_L2_Hits failed, wrong ratio",
+ ratio1 == 0.3);
+
+ TEST_ASSERT_VAL("DCache_L2_Misses failed, wrong ratio",
+ ratio2 == 0.7);
return 0;
}
8<
could you please send it formaly, so it can be merged?
I can't reproduce the original patch issue and I need
to check the code in more depth
Thanks,
John
AW: [PATCH v2 1/4] leds: lp50xx: add setting of default intensity from DT
Hello Pavel, hello Dan,
> > diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> > b/Documentation/devicetree/bindings/leds/leds-
> lp50xx.yaml
> > index c192b5feadc7..2bc25b2fc94d 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> > +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> > @@ -65,6 +65,11 @@ patternProperties:
> >This property denotes the LED module number(s) that is used on
> > the
> >for the child node. The LED modules can either be used stand
> > alone
> >or grouped into a module bank.
> > + default-intensity:
> > +minItems: 1
> > +maxItems: 3
> > +description:
>
> Do we need more than three for RGBW and similar?
AFAIK the lp50xx supports only RGB. So I would go for that.
> > patternProperties:
> >"(^led-[0-9a-f]$|led)":
> > @@ -99,6 +104,7 @@ examples:
> > reg = <0x1>;
> > color = ;
> > function = LED_FUNCTION_CHARGING;
> > + default-intensity = <100 0 0>;
> >
> > led-0 {
> > color = ;
>
> Should this go to leds-class-multicolor.yaml ?
I think then all drivers should support it, but I cannot change all drivers.
So I would only leave it in there.
> Can you make example
> <255 120 0> or something like that, so make it clear it is not
> percent?
Sure
Best Regards,
Sven
Re: [PATCH v3 1/7] seqnum_ops: Introduce Sequence Number Ops
On Wed, Feb 03, 2021 at 11:11:57AM -0700, Shuah Khan wrote:
> +static inline u32 seqnum32_inc(struct seqnum32 *seq)
> +{
> + atomic_t val = ATOMIC_INIT(seq->seqnum);
> +
> + seq->seqnum = (u32) atomic_inc_return();
> + if (seq->seqnum >= UINT_MAX)
> + pr_info("Sequence Number overflow %u detected\n",
> + seq->seqnum);
> + return seq->seqnum;
As Peter points out, this is doing doing what you think it is doing :(
Why do you not just have seq->seqnum be a real atomic variable? Trying
to switch to/from one like this does not work as there is no
"atomic-ness" happening here at all.
Oh, and checkpatch should have complained about the extra ' ' in your
cast :)
thanks,
greg k-h
Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init
On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
>
> On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> > [+cc Oliver, Pali, Krzysztof]
>
> Just to note that extending or using sysfs_initialized introduces
> another race condition into kernel code which results in PCI fatal
> errors. Details are in email discussion which Bjorn already sent.
Yeah I wondered why this doesn't race, but since the history goes back
to pre-git times I figured it would have been addressed somehow
already if it indeed does race.
-Daniel
> > s/also/Also/ in subject
> >
> > On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > > We are already doing this for all the regular sysfs files on PCI
> > > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > > now problem, but in the next patch I want to wire up iomem revoke
> > > support. That needs the vfs up an running already to make so that
> > > iomem_get_mapping() works.
> >
> > s/now problem/no problem/
> > s/an running/and running/
> > s/so that/sure that/ ?
> >
> > iomem_get_mapping() doesn't exist; I don't know what that should be.
> >
> > > Wire it up exactly like the existing code. Note that
> > > pci_remove_legacy_files() doesn't need a check since the one for
> > > pci_bus->legacy_io is sufficient.
> >
> > I'm not sure exactly what you mean by "the existing code." I could
> > probably figure it out, but it would save time to mention the existing
> > function here.
> >
> > This looks like another instance where we should really apply Oliver's
> > idea of converting these to attribute_groups [1].
> >
> > The cover letter mentions options discussed with Greg in [2], but I
> > don't think the "sysfs_initialized" hack vs attribute_groups was part
> > of that discussion.
> >
> > It's not absolutely a show-stopper, but it *is* a shame to extend the
> > sysfs_initialized hack if attribute_groups could do this more cleanly
> > and help solve more than one issue.
> >
> > Bjorn
> >
> > [1]
> > https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
> > [2]
> > https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/
> >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Stephen Rothwell
> > > Cc: Jason Gunthorpe
> > > Cc: Kees Cook
> > > Cc: Dan Williams
> > > Cc: Andrew Morton
> > > Cc: John Hubbard
> > > Cc: Jérôme Glisse
> > > Cc: Jan Kara
> > > Cc: Dan Williams
> > > Cc: Greg Kroah-Hartman
> > > Cc: linux...@kvack.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-samsung-...@vger.kernel.org
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: Bjorn Helgaas
> > > Cc: linux-...@vger.kernel.org
> > > ---
> > > drivers/pci/pci-sysfs.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > index fb072f4b3176..0c45b4f7b214 100644
> > > --- a/drivers/pci/pci-sysfs.c
> > > +++ b/drivers/pci/pci-sysfs.c
> > > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > {
> > > int error;
> > >
> > > + if (!sysfs_initialized)
> > > + return;
> > > +
> > > b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> > >GFP_ATOMIC);
> > > if (!b->legacy_io)
> > > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev
> > > *pdev)
> > > static int __init pci_sysfs_init(void)
> > > {
> > > struct pci_dev *pdev = NULL;
> > > + struct pci_bus *pbus = NULL;
> > > int retval;
> > >
> > > sysfs_initialized = 1;
> > > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> > > }
> > > }
> > >
> > > + while ((pbus = pci_find_next_bus(pbus)))
> > > + pci_create_legacy_files(pbus);
> > > +
> > > return 0;
> > > }
> > > late_initcall(pci_sysfs_init);
> > > --
> > > 2.30.0
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC][PATCH 2/2] x86: add extra serialization for non-serializing MSRs
On Thu, Feb 04, 2021 at 04:11:12PM -0800, Andy Lutomirski wrote:
> I'm wondering if a more mild violation is possible:
>
> Initialize *addr = 0.
>
> mov $1, (addr)
> wrmsr
>
> remote cpu's IDT vector:
>
> mov (addr), %rax
> %rax == 0!
>
> There's no speculative-execution-becoming-visible-even-if-it-doesn't-retire
> here -- there's just an ordering violation. For Linux, this would
> presumably only manifest as a potential deadlock or confusion if the
> IPI vector code looks at the list of pending work and doesn't find the
> expected work in it.
>
> Dave? hpa? What is the SDM trying to tell us?
[ Big caveat, I've not spoken to any hardware people about this. The
below is purely my own understanding. ]
This is my interpretation as well. Without the MFENCE+LFENCE there is no
guarantee the store is out of the store-buffer and the remote load isn't
guaranteed to observe it.
What I think the SDM is trying to tell us, is that the IPI, even if it
goes on the same regular coherency fabric as memory transfers, is not
subject to the regular memory ordering rules.
Normal TSO rules tells us that when:
P1() {
x = 1;
y = 1;
}
P2() {
r1 = y;
r2 = x;
}
r2 must not be 0 when r1 is 1. Because if we see store to y, we must
also see store to x. But the IPI thing doesn't behave like a store. The
(fast) wrmsr isn't even considered a memop.
The thing is, the above ordering does not guarantee we have r2 != 0.
r2==0 is allowed when r1==0. And that's an entirely sane outcome even if
we run the instructions like:
CPU1CPU2
cycle-1 mov $1, ([x])
cycle-2 mov $1, ([y])
cycle-3 mov ([y]), rax
cycle-4 mov ([x]), rbx
There is no guarantee _any_ of the stores will have made it out. And
that's exactly the issue. The IPI might make it out of the core before
any of the stores will.
Furthermore, since there is no dependency between:
mov $1, ([x])
wrmsr
The CPU is allowed to reorder the execution and retire the wrmsr before
the store. Very much like it would for normal non-dependent
instructions.
And presumably it is still allowed to do that when we write it like:
mov $1, ([x])
mfence
wrmsr
because, mfence only has dependencies to memops and (fast) wrmsr is not
a memop.
Which then brings us to:
mov $1, ([x])
mfence
lfence
wrmsr
In this case, the lfence acts like the newly minted ifence (see
spectre), and will block execution of (any) later instructions until
completion of all prior instructions. This, and only this ensures the
wrmsr happens after the mfence, which in turn ensures the store to x is
globally visible.
Re: [PATCH v1] gpiolib: Don't probe gpio_device if it's not the primary device
On Fri, Feb 5, 2021 at 3:08 AM Saravana Kannan wrote:
>
> Dmitry reported[1] boot error messages caused by
> commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
> fw_devlink=on by default").
>
> gpio-1022 (cpu-pwr-req-hog): hogged as input
> max77620-pinctrl max77620-pinctrl: pin gpio4 already requested by
> max77620-pinctrl; cannot claim for gpiochip1
> max77620-pinctrl max77620-pinctrl: pin-4 (gpiochip1) status -22
> max77620-pinctrl max77620-pinctrl: could not request pin 4 (gpio4) from group
> gpio4 on device max77620-pinctrl
> gpio_stub_drv gpiochip1: Error applying setting, reverse things back
> gpio_stub_drv: probe of gpiochip1 failed with error -22
>
> This happens because when we try to probe a device, driver core calls
> into pinctrl to set up the pins. However, if the GPIO DT node already
> has a proper device created and probed, trying to probe the gpio_device
> with a stub driver makes the pins be claimed twice. pinctrl doesn't like
> this and throws an error.
>
> So, this patch makes sure the gpio_stub_drv doesn't match with a
> gpio_device if it's not the primary device for the fwnode.
>
> [1] -
> https://lore.kernel.org/lkml/544ad0e4-0954-274c-8e77-866aaa566...@gmail.com/
> Fixes: 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
> fw_devlink=on by default")
> Signed-off-by: Saravana Kannan
> Tested-by: Dmitry Osipenko
> ---
> Greg/Linus,
>
> This will need to go into driver-core because the Fixes is in
> driver-core too.
>
> Thanks,
> Saravana
>
> drivers/gpio/gpiolib.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 8e0564c50840..8ad679a928b0 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -56,8 +56,10 @@
> static DEFINE_IDA(gpio_ida);
> static dev_t gpio_devt;
> #define GPIO_DEV_MAX 256 /* 256 GPIO chip devices supported */
> +static int gpio_bus_match(struct device *dev, struct device_driver *drv);
> static struct bus_type gpio_bus_type = {
> .name = "gpio",
> + .match = gpio_bus_match,
> };
>
> /*
> @@ -4199,6 +4201,18 @@ void gpiod_put_array(struct gpio_descs *descs)
> }
> EXPORT_SYMBOL_GPL(gpiod_put_array);
>
> +
> +static int gpio_bus_match(struct device *dev, struct device_driver *drv)
> +{
> + /*
> +* Only match if the fwnode doesn't already have a proper struct
> device
> +* created for it.
> +*/
> + if (dev->fwnode && dev->fwnode->dev != dev)
> + return 0;
> + return 1;
> +}
> +
> static int gpio_stub_drv_probe(struct device *dev)
> {
> /*
> --
> 2.30.0.365.g02bc693789-goog
>
Acked-by: Bartosz Golaszewski
[RESEND RFC: timer passthrough 0/9] Support timer passthrough for VM
The main motivation for this patch is to improve the performance of VM. This patch series introduces how to enable the timer passthrough in non-root mode. The main idea is to offload the host timer to the preemtion timer in non-root mode. Through doing this, guest can write tscdeadline msr directly in non-root mode and host timer isn't lost. If CPU is in root mode, guest timer is switched to software timer. Testing on Intel(R) Xeon(R) Platinum 8260 server. The guest OS is Debian(kernel: 4.19.28). The specific configuration is is as follows: 8 cpu, 16GB memory, guest idle=poll memcached in guest(memcached -d -t 8 -u root) I use the memtier_benchmark tool to test performance (memtier_benchmark -P memcache_text -s guest_ip -c 16 -t 32 --key-maximum=100 --random-data --data-size-range=64-128 -p 11211 --generate-keys --ratio 5:1 --test-time=500) Total Ops can be improved 25% and Avg.Latency can be improved 20% when the timer-passthrough is enabled. = | Enable timer-passth | Disable timer-passth | = Totals Ops/sec |514869.67| 411766.67| - Avg.Latency|0.99483 | 1.24294 | = Zhimin Feng (9): KVM: vmx: hook set_next_event for getting the host tscd KVM: vmx: enable host lapic timer offload preemtion timer KVM: vmx: enable passthrough timer to guest KVM: vmx: enable passth timer switch to sw timer KVM: vmx: use tsc_adjust to enable tsc_offset timer passthrough KVM: vmx: check enable_timer_passth strictly KVM: vmx: save the initial value of host tscd KVM: vmx: Dynamically open or close the timer-passthrough for pre-vm KVM: vmx: query the state of timer-passth for vm arch/x86/include/asm/kvm_host.h | 27 arch/x86/kvm/lapic.c| 1 + arch/x86/kvm/vmx/vmx.c | 331 +++- arch/x86/kvm/x86.c | 26 +++- include/linux/kvm_host.h| 1 + include/uapi/linux/kvm.h| 3 + kernel/time/tick-common.c | 1 + tools/include/uapi/linux/kvm.h | 3 + virt/kvm/kvm_main.c | 1 + 9 files changed, 389 insertions(+), 5 deletions(-) -- 2.11.0
[RFC: timer passthrough 2/9] KVM: vmx: enable host lapic timer offload preemtion timer
Use preemption timer to handle host timer
Signed-off-by: Zhimin Feng
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/vmx/vmx.c | 54 +
arch/x86/kvm/x86.c | 1 +
3 files changed, 56 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index eb6a611963b7..82a51f0d01a2 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -826,6 +826,7 @@ struct kvm_vcpu_arch {
} pv_cpuid;
bool timer_passth_enable;
+ u64 tscd;
};
struct kvm_lpage_info {
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 38b8d80fa157..0bf9941df842 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -5629,6 +5629,13 @@ static fastpath_t
handle_fastpath_preemption_timer(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
+ if (vcpu->arch.timer_passth_enable) {
+ local_irq_disable();
+ apic->send_IPI_mask(get_cpu_mask(vcpu->cpu),
LOCAL_TIMER_VECTOR);
+ local_irq_enable();
+
+ return EXIT_FASTPATH_NONE;
+ }
if (!vmx->req_immediate_exit &&
!unlikely(vmx->loaded_vmcs->hv_timer_soft_disabled)) {
kvm_lapic_expired_hv_timer(vcpu);
@@ -6640,6 +6647,51 @@ static fastpath_t vmx_exit_handlers_fastpath(struct
kvm_vcpu *vcpu)
bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned long *regs, bool launched);
+static void vmx_host_lapic_timer_offload(struct kvm_vcpu *vcpu)
+{
+ struct timer_passth_info *local_timer_info;
+ u64 tscl;
+ u64 guest_tscl;
+ u64 delta_tsc;
+ struct hrtimer *timer;
+
+ if (!vcpu->arch.timer_passth_enable)
+ return;
+
+ local_timer_info = _cpu(passth_info, smp_processor_id());
+
+ tscl = rdtsc();
+ guest_tscl = kvm_read_l1_tsc(vcpu, tscl);
+
+ timer = >arch.apic->lapic_timer.timer;
+ if (hrtimer_active(timer))
+ hrtimer_cancel(timer);
+
+ if (local_timer_info->host_tscd > tscl) {
+ delta_tsc = (u32)((local_timer_info->host_tscd - tscl) >>
+ cpu_preemption_timer_multi);
+ vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, delta_tsc);
+ vmcs_set_bits(PIN_BASED_VM_EXEC_CONTROL,
+ PIN_BASED_VMX_PREEMPTION_TIMER);
+ } else {
+ vmcs_clear_bits(PIN_BASED_VM_EXEC_CONTROL,
+ PIN_BASED_VMX_PREEMPTION_TIMER);
+ }
+
+ wrmsrl(MSR_IA32_TSCDEADLINE, 0);
+ if (vcpu->arch.tscd > guest_tscl) {
+ wrmsrl(MSR_IA32_TSCDEADLINE, vcpu->arch.tscd);
+ } else {
+ if (vcpu->arch.tscd > 0) {
+ if
(!atomic_read(>arch.apic->lapic_timer.pending)) {
+
atomic_inc(>arch.apic->lapic_timer.pending);
+ kvm_inject_pending_timer_irqs(vcpu);
+ kvm_x86_ops.sync_pir_to_irr(vcpu);
+ }
+ }
+ }
+}
+
static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu,
struct vcpu_vmx *vmx)
{
@@ -6761,6 +6813,8 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
kvm_wait_lapic_expire(vcpu);
+ vmx_host_lapic_timer_offload(vcpu);
+
/*
* If this vCPU has touched SPEC_CTRL, restore the guest's value if
* it's non-zero. Since vmentry is serialising on affected CPUs, there
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5d353a9c9881..e51fd52a4862 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9912,6 +9912,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
vcpu->arch.pending_external_vector = -1;
vcpu->arch.preempted_in_kernel = false;
vcpu->arch.timer_passth_enable = false;
+ vcpu->arch.tscd = 0;
kvm_hv_vcpu_init(vcpu);
--
2.11.0
[RFC: timer passthrough 3/9] KVM: vmx: enable passthrough timer to guest
Allow Guest to write tscdeadline msr directly.
Signed-off-by: Zhimin Feng
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/lapic.c| 9 +++
arch/x86/kvm/vmx/vmx.c | 56 +
3 files changed, 68 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 82a51f0d01a2..500fa031297d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -533,6 +533,7 @@ struct tick_device {
struct timer_passth_info {
u64 host_tscd;
+ bool host_in_tscdeadline;
struct clock_event_device *curr_dev;
void (*orig_event_handler)(struct clock_event_device *dev);
@@ -1302,6 +1303,8 @@ struct kvm_x86_ops {
void (*migrate_timers)(struct kvm_vcpu *vcpu);
void (*msr_filter_changed)(struct kvm_vcpu *vcpu);
+ void (*set_timer_passthrough)(struct kvm_vcpu *vcpu, bool enable);
+ int (*host_timer_can_passth)(struct kvm_vcpu *vcpu);
};
struct kvm_x86_nested_ops {
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 86c33d53c90a..9b2f8b99fbf6 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1508,6 +1508,15 @@ static void apic_update_lvtt(struct kvm_lapic *apic)
}
apic->lapic_timer.timer_mode = timer_mode;
limit_periodic_timer_frequency(apic);
+
+ if (kvm_x86_ops.host_timer_can_passth(apic->vcpu)) {
+ if (apic_lvtt_tscdeadline(apic)) {
+ kvm_x86_ops.set_timer_passthrough(apic->vcpu,
true);
+ } else {
+ if (apic->vcpu->arch.timer_passth_enable)
+
kvm_x86_ops.set_timer_passthrough(apic->vcpu, false);
+ }
+ }
}
}
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 0bf9941df842..0c1b5ee4bb8e 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include "capabilities.h"
#include "cpuid.h"
@@ -705,6 +706,8 @@ static bool is_valid_passthrough_msr(u32 msr)
case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B:
/* PT MSRs. These are handled in pt_update_intercept_for_msr()
*/
return true;
+ case MSR_IA32_TSC_DEADLINE:
+ return true;
}
r = possible_passthrough_msr_slot(msr) != -ENOENT;
@@ -7670,6 +7673,54 @@ static void vmx_migrate_timers(struct kvm_vcpu *vcpu)
}
}
+static void host_lapic_timer_in_deadline(void *junk)
+{
+ unsigned int v;
+ struct timer_passth_info *local_timer_info;
+ int cpu = smp_processor_id();
+
+ local_timer_info = _cpu(passth_info, cpu);
+ v = apic_read(APIC_LVTT);
+ local_timer_info->host_in_tscdeadline = (v &
APIC_LVT_TIMER_TSCDEADLINE);
+}
+
+static bool host_all_cpu_in_tscdeadline(void)
+{
+ int cpu;
+ struct timer_passth_info *local_timer_info;
+
+ for_each_online_cpu(cpu) {
+ local_timer_info = _cpu(passth_info, cpu);
+ if (!local_timer_info->host_in_tscdeadline)
+ return false;
+ }
+
+ return true;
+}
+
+static int vmx_host_timer_can_passth(struct kvm_vcpu *vcpu)
+{
+ if (!enable_timer_passth || !cpu_has_vmx_msr_bitmap() ||
+ !host_all_cpu_in_tscdeadline())
+ return 0;
+ return 1;
+}
+
+static void vmx_set_timer_passthrough(struct kvm_vcpu *vcpu, bool enable)
+{
+ if (enable) {
+ vmx_disable_intercept_for_msr(vcpu, MSR_IA32_TSC_DEADLINE,
+
MSR_TYPE_RW);
+ vcpu->arch.timer_passth_enable = 1;
+ } else {
+ vmx_enable_intercept_for_msr(vcpu, MSR_IA32_TSC_DEADLINE,
+
MSR_TYPE_RW);
+ vmcs_clear_bits(PIN_BASED_VM_EXEC_CONTROL,
+ PIN_BASED_VMX_PREEMPTION_TIMER);
+ vcpu->arch.timer_passth_enable = 0;
+ }
+}
+
static void hardware_unsetup(void)
{
if (enable_timer_passth)
@@ -7817,6 +7868,8 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
.migrate_timers = vmx_migrate_timers,
.msr_filter_changed = vmx_msr_filter_changed,
+ .set_timer_passthrough = vmx_set_timer_passthrough,
+ .host_timer_can_passth = vmx_host_timer_can_passth,
};
static __init int hardware_setup(void)
@@ -7987,6 +8040,9 @@ static __init int hardware_setup(void)
vmx_set_cpu_caps();
if (enable_timer_passth)
+ on_each_cpu(host_lapic_timer_in_deadline, NULL, 1);
+
+ if (enable_timer_passth)
on_each_cpu(vmx_host_timer_passth_init, NULL, 1);
r = alloc_kvm_area();
--
2.11.0
[RFC: timer passthrough 1/9] KVM: vmx: hook set_next_event for getting the host tscd
In order to get the host tscd value,
we need to hook set_next_event function
Signed-off-by: Zhimin Feng
---
arch/x86/include/asm/kvm_host.h | 21 +
arch/x86/kvm/vmx/vmx.c | 51 +
arch/x86/kvm/x86.c | 1 +
kernel/time/tick-common.c | 1 +
4 files changed, 74 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7e5f33a0d0e2..eb6a611963b7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#define __KVM_HAVE_ARCH_VCPU_DEBUGFS
@@ -520,6 +521,24 @@ struct kvm_vcpu_hv {
cpumask_t tlb_flush;
};
+enum tick_device_mode {
+ TICKDEV_MODE_PERIODIC,
+ TICKDEV_MODE_ONESHOT,
+};
+
+struct tick_device {
+ struct clock_event_device *evtdev;
+ enum tick_device_mode mode;
+};
+
+struct timer_passth_info {
+ u64 host_tscd;
+ struct clock_event_device *curr_dev;
+
+ void (*orig_event_handler)(struct clock_event_device *dev);
+ int (*orig_set_next_event)(unsigned long evt, struct clock_event_device
*dev);
+};
+
struct kvm_vcpu_arch {
/*
* rip and regs accesses must go through
@@ -805,6 +824,8 @@ struct kvm_vcpu_arch {
*/
bool enforce;
} pv_cpuid;
+
+ bool timer_passth_enable;
};
struct kvm_lpage_info {
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 47b8357b9751..38b8d80fa157 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -128,6 +128,11 @@ static bool __read_mostly enable_preemption_timer = 1;
module_param_named(preemption_timer, enable_preemption_timer, bool, S_IRUGO);
#endif
+static bool __read_mostly enable_timer_passth;
+#ifdef CONFIG_X86_64
+module_param_named(timer_passth, enable_timer_passth, bool, 0444);
+#endif
+
extern bool __read_mostly allow_smaller_maxphyaddr;
module_param(allow_smaller_maxphyaddr, bool, S_IRUGO);
@@ -220,6 +225,46 @@ static const struct {
[VMENTER_L1D_FLUSH_NOT_REQUIRED] = {"not required", false},
};
+#define TSC_DIVISOR 8
+static DEFINE_PER_CPU(struct timer_passth_info, passth_info);
+
+static int override_lapic_next_event(unsigned long delta,
+ struct clock_event_device *evt)
+{
+ struct timer_passth_info *local_timer_info;
+ u64 tsc;
+ u64 tscd;
+
+ local_timer_info = _cpu(passth_info, smp_processor_id());
+ tsc = rdtsc();
+ tscd = tsc + (((u64) delta) * TSC_DIVISOR);
+ local_timer_info->host_tscd = tscd;
+ wrmsrl(MSR_IA32_TSCDEADLINE, tscd);
+
+ return 0;
+}
+
+static void vmx_host_timer_passth_init(void *junk)
+{
+ struct timer_passth_info *local_timer_info;
+ int cpu = smp_processor_id();
+
+ local_timer_info = _cpu(passth_info, cpu);
+ local_timer_info->curr_dev = per_cpu(tick_cpu_device, cpu).evtdev;
+ local_timer_info->orig_set_next_event =
+ local_timer_info->curr_dev->set_next_event;
+ local_timer_info->curr_dev->set_next_event = override_lapic_next_event;
+}
+
+static void vmx_host_timer_restore(void *junk)
+{
+ struct timer_passth_info *local_timer_info;
+
+ local_timer_info = _cpu(passth_info, smp_processor_id());
+ local_timer_info->curr_dev->set_next_event =
+ local_timer_info->orig_set_next_event;
+}
+
#define L1D_CACHE_ORDER 4
static void *vmx_l1d_flush_pages;
@@ -7573,6 +7618,9 @@ static void vmx_migrate_timers(struct kvm_vcpu *vcpu)
static void hardware_unsetup(void)
{
+ if (enable_timer_passth)
+ on_each_cpu(vmx_host_timer_restore, NULL, 1);
+
if (nested)
nested_vmx_hardware_unsetup();
@@ -7884,6 +7932,9 @@ static __init int hardware_setup(void)
vmx_set_cpu_caps();
+ if (enable_timer_passth)
+ on_each_cpu(vmx_host_timer_passth_init, NULL, 1);
+
r = alloc_kvm_area();
if (r)
nested_vmx_hardware_unsetup();
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e545a8a613b1..5d353a9c9881 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9911,6 +9911,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
vcpu->arch.pending_external_vector = -1;
vcpu->arch.preempted_in_kernel = false;
+ vcpu->arch.timer_passth_enable = false;
kvm_hv_vcpu_init(vcpu);
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 6c9c342dd0e5..bc50f4a1a7c0 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -26,6 +26,7 @@
* Tick devices
*/
DEFINE_PER_CPU(struct tick_device, tick_cpu_device);
+EXPORT_SYMBOL_GPL(tick_cpu_device);
/*
* Tick next event: keeps track of the tick time
*/
--
2.11.0
[RFC: timer passthrough 4/9] KVM: vmx: enable passth timer switch to sw timer
Switch the guest timer to software timer when the
VCPU is scheduled.
Signed-off-by: Zhimin Feng
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/vmx/vmx.c | 65 +
arch/x86/kvm/x86.c | 12 ++--
3 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 500fa031297d..be8fc230f7c4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1305,6 +1305,7 @@ struct kvm_x86_ops {
void (*msr_filter_changed)(struct kvm_vcpu *vcpu);
void (*set_timer_passthrough)(struct kvm_vcpu *vcpu, bool enable);
int (*host_timer_can_passth)(struct kvm_vcpu *vcpu);
+ void (*switch_to_sw_timer)(struct kvm_vcpu *vcpu);
};
struct kvm_x86_nested_ops {
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 42cf0a3ad493..f824ee46e2d3 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -6702,6 +6704,27 @@ static void vmx_host_lapic_timer_offload(struct kvm_vcpu
*vcpu)
}
}
+static void vmx_restore_passth_timer(struct kvm_vcpu *vcpu)
+{
+ struct timer_passth_info *local_timer_info;
+ u64 host_tscd;
+ u64 guest_tscd;
+
+ if (vcpu->arch.timer_passth_enable) {
+ local_timer_info = _cpu(passth_info, smp_processor_id());
+ host_tscd = local_timer_info->host_tscd;
+ rdmsrl(MSR_IA32_TSC_DEADLINE, guest_tscd);
+
+ if (guest_tscd != 0 &&
+ guest_tscd != host_tscd) {
+ vcpu->arch.tscd = guest_tscd;
+ }
+
+ if (host_tscd > rdtsc())
+ wrmsrl(MSR_IA32_TSC_DEADLINE, host_tscd);
+ }
+}
+
static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu,
struct vcpu_vmx *vmx)
{
@@ -6836,6 +6859,7 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
/* The actual VMENTER/EXIT is in the .noinstr.text section. */
vmx_vcpu_enter_exit(vcpu, vmx);
+ vmx_restore_passth_timer(vcpu);
/*
* We do not use IBRS in the kernel. If this vCPU has used the
* SPEC_CTRL MSR it may have left it on; save the value and
@@ -7589,11 +7613,50 @@ static void vmx_enable_log_dirty_pt_masked(struct kvm
*kvm,
kvm_mmu_clear_dirty_pt_masked(kvm, memslot, offset, mask);
}
+static void vmx_passth_switch_to_sw_timer(struct kvm_vcpu *vcpu)
+{
+ struct kvm_timer *ktimer;
+ ktime_t expire;
+ u64 guest_tscl;
+ ktime_t now;
+ u64 ns;
+ unsigned long flags;
+ unsigned long this_tsc_khz = vcpu->arch.virtual_tsc_khz;
+
+ ktimer = >arch.apic->lapic_timer;
+ if (hrtimer_active(>timer))
+ return;
+
+ local_irq_save(flags);
+ now = ktime_get();
+
+ guest_tscl = kvm_read_l1_tsc(vcpu, rdtsc());
+ ns = (vcpu->arch.tscd - guest_tscl) * 100ULL;
+ do_div(ns, this_tsc_khz);
+ if (likely(vcpu->arch.tscd > guest_tscl) &&
+ likely(ns > ktimer->timer_advance_ns)) {
+ expire = ktime_add_ns(now, ns);
+ expire = ktime_sub_ns(expire, ktimer->timer_advance_ns);
+ hrtimer_start(>timer, expire, HRTIMER_MODE_ABS_PINNED);
+ } else {
+ if (vcpu->arch.tscd > 0) {
+ if
(!atomic_read(>arch.apic->lapic_timer.pending)) {
+
atomic_inc(>arch.apic->lapic_timer.pending);
+ kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu);
+ }
+ }
+ }
+
+ local_irq_restore(flags);
+}
+
static int vmx_pre_block(struct kvm_vcpu *vcpu)
{
if (pi_pre_block(vcpu))
return 1;
+ vmx_passth_switch_to_sw_timer(vcpu);
+
if (kvm_lapic_hv_timer_in_use(vcpu))
kvm_lapic_switch_to_sw_timer(vcpu);
@@ -7722,6 +7785,7 @@ static void vmx_set_timer_passthrough(struct kvm_vcpu
*vcpu, bool enable)
} else {
vmx_enable_intercept_for_msr(vcpu, MSR_IA32_TSC_DEADLINE,
MSR_TYPE_RW);
+ vmx_passth_switch_to_sw_timer(vcpu);
vmcs_clear_bits(PIN_BASED_VM_EXEC_CONTROL,
PIN_BASED_VMX_PREEMPTION_TIMER);
vcpu->arch.timer_passth_enable = 0;
@@ -7877,6 +7941,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
.msr_filter_changed = vmx_msr_filter_changed,
.set_timer_passthrough = vmx_set_timer_passthrough,
.host_timer_can_passth = vmx_host_timer_can_passth,
+ .switch_to_sw_timer = vmx_passth_switch_to_sw_timer,
};
static __init int hardware_setup(void)
diff --git a/arch/x86/kvm/x86.c
[RFC: timer passthrough 5/9] KVM: vmx: use tsc_adjust to enable tsc_offset timer passthrough
when in vm:
rdtsc = host_tsc * (TSC multiplier) + tsc_offset(<0)
so when vm write tsc_deadline_msr the value always less than
tsc stampcounter msr value, the irq never be triggered.
the tsc_adjust msr use as below, host execute
rdtsc = host_tsc + tsc_adjust
when vmentry, we set the tsc_adjust equal tsc_offset and vmcs
tsc offset filed equal 0, so the vm execute rdtsc the result like this:
rdtsc = host_tsc + tsc_adjust + 0
the tsc_deadline_msr value will equal tsc stampcounter msr and
the irq will trigger success.
Signed-off-by: Zhimin Feng
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/vmx/vmx.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index be8fc230f7c4..7971c9e755a4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -534,6 +534,7 @@ struct tick_device {
struct timer_passth_info {
u64 host_tscd;
bool host_in_tscdeadline;
+ u64 host_tsc_adjust;
struct clock_event_device *curr_dev;
void (*orig_event_handler)(struct clock_event_device *dev);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index f824ee46e2d3..44b2fd59587e 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6659,6 +6659,27 @@ static fastpath_t vmx_exit_handlers_fastpath(struct
kvm_vcpu *vcpu)
bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned long *regs, bool launched);
+static void vmx_adjust_tsc_offset(struct kvm_vcpu *vcpu, bool to_host)
+{
+ u64 tsc_adjust;
+ struct timer_passth_info *local_timer_info;
+
+ local_timer_info = _cpu(passth_info, smp_processor_id());
+
+ if (to_host) {
+ tsc_adjust = local_timer_info->host_tsc_adjust;
+ wrmsrl(MSR_IA32_TSC_ADJUST, tsc_adjust);
+ vmcs_write64(TSC_OFFSET, vcpu->arch.tsc_offset);
+ } else {
+ rdmsrl(MSR_IA32_TSC_ADJUST, tsc_adjust);
+ local_timer_info->host_tsc_adjust = tsc_adjust;
+
+ wrmsrl(MSR_IA32_TSC_ADJUST, tsc_adjust + vcpu->arch.tsc_offset);
+ vmcs_write64(TSC_OFFSET, 0);
+
+ }
+}
+
static void vmx_host_lapic_timer_offload(struct kvm_vcpu *vcpu)
{
struct timer_passth_info *local_timer_info;
@@ -6690,6 +6711,7 @@ static void vmx_host_lapic_timer_offload(struct kvm_vcpu
*vcpu)
PIN_BASED_VMX_PREEMPTION_TIMER);
}
+ vmx_adjust_tsc_offset(vcpu, false);
wrmsrl(MSR_IA32_TSCDEADLINE, 0);
if (vcpu->arch.tscd > guest_tscl) {
wrmsrl(MSR_IA32_TSCDEADLINE, vcpu->arch.tscd);
@@ -6711,6 +6733,7 @@ static void vmx_restore_passth_timer(struct kvm_vcpu
*vcpu)
u64 guest_tscd;
if (vcpu->arch.timer_passth_enable) {
+ vmx_adjust_tsc_offset(vcpu, true);
local_timer_info = _cpu(passth_info, smp_processor_id());
host_tscd = local_timer_info->host_tscd;
rdmsrl(MSR_IA32_TSC_DEADLINE, guest_tscd);
--
2.11.0
[RFC: timer passthrough 9/9] KVM: vmx: query the state of timer-passth for vm
query the state of timer passthrough of specific vm
Signed-off-by: Zhimin Feng
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/vmx/vmx.c | 11 +++
arch/x86/kvm/x86.c | 6 ++
include/uapi/linux/kvm.h| 1 +
tools/include/uapi/linux/kvm.h | 1 +
5 files changed, 20 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 9855ef419793..189c4f6f9d5d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1306,6 +1306,7 @@ struct kvm_x86_ops {
void (*msr_filter_changed)(struct kvm_vcpu *vcpu);
void (*switch_to_sw_timer)(struct kvm_vcpu *vcpu);
int (*set_timer_passth_state)(struct kvm *kvm, void *argp);
+ int (*get_timer_passth_state)(struct kvm *kvm, void __user *argp);
};
struct kvm_x86_nested_ops {
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b88f744478e9..b760aa7bc6d5 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7883,6 +7883,16 @@ static int vmx_set_timer_passth_state(struct kvm *kvm,
void *argp)
return r;
}
+static int vmx_get_timer_passth_state(struct kvm *kvm, void __user *argp)
+{
+ int state = atomic_read(>timer_passth_state);
+
+ if (copy_to_user(argp, , sizeof(state)))
+ return -1;
+
+ return 0;
+}
+
static struct kvm_x86_ops vmx_x86_ops __initdata = {
.hardware_unsetup = hardware_unsetup,
@@ -8013,6 +8023,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
.msr_filter_changed = vmx_msr_filter_changed,
.switch_to_sw_timer = vmx_passth_switch_to_sw_timer,
.set_timer_passth_state = vmx_set_timer_passth_state,
+ .get_timer_passth_state = vmx_get_timer_passth_state,
};
static __init int hardware_setup(void)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7db74bd9d362..a32927697e82 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5698,6 +5698,12 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_x86_ops.set_timer_passth_state(kvm, argp);
break;
}
+ case KVM_GET_TIMER_PASSTH_STATE: {
+ r = -EFAULT;
+ if (kvm_x86_ops.get_timer_passth_state)
+ r = kvm_x86_ops.get_timer_passth_state(kvm, argp);
+ break;
+ }
default:
r = -ENOTTY;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 6e26bc342599..2c0cefb8ffe2 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1558,6 +1558,7 @@ struct kvm_pv_cmd {
#define KVM_X86_SET_MSR_FILTER _IOW(KVMIO, 0xc6, struct kvm_msr_filter)
#define KVM_SET_TIMER_PASSTH_STATE _IO(KVMIO, 0xc7)
+#define KVM_GET_TIMER_PASSTH_STATE _IO(KVMIO, 0xc8)
/* Secure Encrypted Virtualization command */
enum sev_cmd_id {
diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
index 6e26bc342599..2c0cefb8ffe2 100644
--- a/tools/include/uapi/linux/kvm.h
+++ b/tools/include/uapi/linux/kvm.h
@@ -1558,6 +1558,7 @@ struct kvm_pv_cmd {
#define KVM_X86_SET_MSR_FILTER _IOW(KVMIO, 0xc6, struct kvm_msr_filter)
#define KVM_SET_TIMER_PASSTH_STATE _IO(KVMIO, 0xc7)
+#define KVM_GET_TIMER_PASSTH_STATE _IO(KVMIO, 0xc8)
/* Secure Encrypted Virtualization command */
enum sev_cmd_id {
--
2.11.0
[RFC: timer passthrough 6/9] KVM: vmx: check enable_timer_passth strictly
preemption timer is default disabled
timer passthrough is default enabled
Signed-off-by: Zhimin Feng
---
arch/x86/kvm/vmx/vmx.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 44b2fd59587e..a12da3cef86d 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -126,12 +126,12 @@ module_param(dump_invalid_vmcs, bool, 0644);
/* Guest_tsc -> host_tsc conversion requires 64-bit division. */
static int __read_mostly cpu_preemption_timer_multi;
-static bool __read_mostly enable_preemption_timer = 1;
+static bool __read_mostly enable_preemption_timer;
#ifdef CONFIG_X86_64
module_param_named(preemption_timer, enable_preemption_timer, bool, S_IRUGO);
#endif
-static bool __read_mostly enable_timer_passth;
+static bool __read_mostly enable_timer_passth = 1;
#ifdef CONFIG_X86_64
module_param_named(timer_passth, enable_timer_passth, bool, 0444);
#endif
@@ -8108,12 +8108,17 @@ static __init int hardware_setup(void)
enable_preemption_timer = false;
}
- if (!enable_preemption_timer) {
+ if (!enable_preemption_timer || enable_timer_passth) {
vmx_x86_ops.set_hv_timer = NULL;
vmx_x86_ops.cancel_hv_timer = NULL;
vmx_x86_ops.request_immediate_exit =
__kvm_request_immediate_exit;
}
+ if (enable_preemption_timer && enable_timer_passth) {
+ pr_err("cannot enable timer passthrough and preemption timer
same timer\n");
+ return -EINVAL;
+ }
+
kvm_set_posted_intr_wakeup_handler(pi_wakeup_handler);
kvm_mce_cap_supported |= MCG_LMCE_P;
--
2.11.0
Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init
On Friday 05 February 2021 10:59:50 Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
> >
> > On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> > > [+cc Oliver, Pali, Krzysztof]
> >
> > Just to note that extending or using sysfs_initialized introduces
> > another race condition into kernel code which results in PCI fatal
> > errors. Details are in email discussion which Bjorn already sent.
>
> Yeah I wondered why this doesn't race.
It races, but with smaller probability. I have not seen this race
condition on x86. But I was able to reproduce it with native PCIe
drivers on ARM64 (Marvell Armada 3720; pci-aardvark). In mentioned
discussion I wrote when this race condition happen. But I understand
that it is hard to simulate it.
> but since the history goes back
> to pre-git times I figured it would have been addressed somehow
> already if it indeed does race.
> -Daniel
>
> > > s/also/Also/ in subject
> > >
> > > On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > > > We are already doing this for all the regular sysfs files on PCI
> > > > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > > > now problem, but in the next patch I want to wire up iomem revoke
> > > > support. That needs the vfs up an running already to make so that
> > > > iomem_get_mapping() works.
> > >
> > > s/now problem/no problem/
> > > s/an running/and running/
> > > s/so that/sure that/ ?
> > >
> > > iomem_get_mapping() doesn't exist; I don't know what that should be.
> > >
> > > > Wire it up exactly like the existing code. Note that
> > > > pci_remove_legacy_files() doesn't need a check since the one for
> > > > pci_bus->legacy_io is sufficient.
> > >
> > > I'm not sure exactly what you mean by "the existing code." I could
> > > probably figure it out, but it would save time to mention the existing
> > > function here.
> > >
> > > This looks like another instance where we should really apply Oliver's
> > > idea of converting these to attribute_groups [1].
> > >
> > > The cover letter mentions options discussed with Greg in [2], but I
> > > don't think the "sysfs_initialized" hack vs attribute_groups was part
> > > of that discussion.
> > >
> > > It's not absolutely a show-stopper, but it *is* a shame to extend the
> > > sysfs_initialized hack if attribute_groups could do this more cleanly
> > > and help solve more than one issue.
> > >
> > > Bjorn
> > >
> > > [1]
> > > https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
> > > [2]
> > > https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/
> > >
> > > > Signed-off-by: Daniel Vetter
> > > > Cc: Stephen Rothwell
> > > > Cc: Jason Gunthorpe
> > > > Cc: Kees Cook
> > > > Cc: Dan Williams
> > > > Cc: Andrew Morton
> > > > Cc: John Hubbard
> > > > Cc: Jérôme Glisse
> > > > Cc: Jan Kara
> > > > Cc: Dan Williams
> > > > Cc: Greg Kroah-Hartman
> > > > Cc: linux...@kvack.org
> > > > Cc: linux-arm-ker...@lists.infradead.org
> > > > Cc: linux-samsung-...@vger.kernel.org
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: Bjorn Helgaas
> > > > Cc: linux-...@vger.kernel.org
> > > > ---
> > > > drivers/pci/pci-sysfs.c | 7 +++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > > index fb072f4b3176..0c45b4f7b214 100644
> > > > --- a/drivers/pci/pci-sysfs.c
> > > > +++ b/drivers/pci/pci-sysfs.c
> > > > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > > {
> > > > int error;
> > > >
> > > > + if (!sysfs_initialized)
> > > > + return;
> > > > +
> > > > b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> > > >GFP_ATOMIC);
> > > > if (!b->legacy_io)
> > > > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev
> > > > *pdev)
> > > > static int __init pci_sysfs_init(void)
> > > > {
> > > > struct pci_dev *pdev = NULL;
> > > > + struct pci_bus *pbus = NULL;
> > > > int retval;
> > > >
> > > > sysfs_initialized = 1;
> > > > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> > > > }
> > > > }
> > > >
> > > > + while ((pbus = pci_find_next_bus(pbus)))
> > > > + pci_create_legacy_files(pbus);
> > > > +
> > > > return 0;
> > > > }
> > > > late_initcall(pci_sysfs_init);
> > > > --
> > > > 2.30.0
> > > >
> > > >
> > > > ___
> > > > linux-arm-kernel mailing list
> > > > linux-arm-ker...@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH v2 1/2] ima: Free IMA measurement buffer on error
On Thu, Feb 04, 2021 at 09:49:50AM -0800, Lakshmi Ramasubramanian wrote:
> IMA allocates kernel virtual memory to carry forward the measurement
> list, from the current kernel to the next kernel on kexec system call,
> in ima_add_kexec_buffer() function. In error code paths this memory
> is not freed resulting in memory leak.
>
> Free the memory allocated for the IMA measurement list in
> the error code paths in ima_add_kexec_buffer() function.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggested-by: Tyler Hicks
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
> ---
> security/integrity/ima/ima_kexec.c | 1 +
> 1 file changed, 1 insertion(+)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: linux-next: build failure after merge of the kvm tree
On 05/02/21 06:02, Stephen Rothwell wrote:
Hi all,
After merging the kvm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: modpost: ".follow_pte" [arch/powerpc/kvm/kvm.ko] undefined!
Caused by commit
bd2fae8da794 ("KVM: do not assume PTE is writable after follow_pfn")
follow_pte is not EXPORTed.
I have used the kvm tree from next-20210204 for today.
Stephen, can you squash in the following for the time being?
diff --git a/mm/memory.c b/mm/memory.c
index feff48e1465a..15cbd10afd59 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4775,6 +4775,7 @@ int follow_pte(struct mm_struct *mm, unsigned long
address,
out:
return -EINVAL;
}
+EXPORT_SYMBOL_GPL(follow_pte);
/**
* follow_pfn - look up PFN at a user virtual address
A similar patch has been posted already, but Jason Gunthorpe asked to
add some kerneldoc comments. Therefore it will not be in kvm/next for a
few more days.
Paolo
Re: [PATCH v2 2/2] of: property: Add fw_devlink support for interrupts
On Fri, Feb 5, 2021 at 12:06 AM Geert Uytterhoeven wrote:
>
> Hi Marek,
>
> On Fri, Feb 5, 2021 at 8:38 AM Marek Szyprowski
> wrote:
> > On 04.02.2021 22:31, Saravana Kannan wrote:
> > > On Thu, Feb 4, 2021 at 3:52 AM Marek Szyprowski
> > > wrote:
> > >> On 21.01.2021 23:57, Saravana Kannan wrote:
> > >>> This allows fw_devlink to create device links between consumers of an
> > >>> interrupt and the supplier of the interrupt.
> > >>>
> > >>> Cc: Marc Zyngier
> > >>> Cc: Kevin Hilman
> > >>> Cc: Greg Kroah-Hartman
> > >>> Reviewed-by: Rob Herring
> > >>> Reviewed-by: Thierry Reding
> > >>> Reviewed-by: Linus Walleij
> > >>> Signed-off-by: Saravana Kannan
> > >> This patch landed some time ago in linux-next as commit 4104ca776ba3
> > >> ("of: property: Add fw_devlink support for interrupts"). It breaks MMC
> > >> host controller operation on ARM Juno R1 board (the mmci@5 device
> > >> defined in arch/arm64/boot/dts/arm/juno-motherboard.dtsi). I didn't
> > > I grepped around and it looks like the final board file is this or
> > > whatever includes it?
> > > arch/arm64/boot/dts/arm/juno-base.dtsi
> > The final board file is arch/arm64/boot/dts/arm/juno-r1.dts
> > > This patch just finds the interrupt-parent and then tries to use that
> > > as a supplier if "interrupts" property is listed. But the only
> > > interrupt parent I can see is:
> > > gic: interrupt-controller@2c01 {
> > > compatible = "arm,gic-400", "arm,cortex-a15-gic";
> > >
> > > And the driver uses IRQCHIP_DECLARE() and hence should be pretty much
> > > a NOP since those suppliers are never devices and are ignored.
> > > $ git grep "arm,gic-400" -- drivers/
> > > drivers/irqchip/irq-gic.c:IRQCHIP_DECLARE(gic_400, "arm,gic-400",
> > > gic_of_init);
> > >
> > > This doesn't make any sense. Am I looking at the right files? Am I
> > > missing something?
> >
> > Okay, I've added displaying a list of deferred devices when mounting
> > rootfs fails and got following items:
> >
> > Deferred devices:
> > 1800.ethernetplatform: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > 1c05.mmciamba: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > 1c1d.gpioamba: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > 2b60.iommu platform: probe deferral - wait for supplier
> > scpi-power-domains
> > 7ff5.hdlcd platform: probe deferral - wait for supplier scpi-clk
> > 7ff6.hdlcd platform: probe deferral - wait for supplier scpi-clk
> > 1c06.kmi amba: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > 1c07.kmi amba: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > 1c17.rtc amba: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > 1c0f.wdt amba: probe deferral - supplier
> > bus@800:motherboard-bus not ready
> > gpio-keys
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(0,0)
> >
> > I don't see the 'bus@800:motherboard-bus' on the deferred devices
> > list, so it looks that device core added a link to something that is not
> > a platform device...
Probe deferred devices (even platform devices) not showing up in that
list is not unusual. That's because devices end up on that list only
after a driver for them is matched and then it fails.
>
> Lemme guess: bus@800 is a simple bus, but it has an
> interrupt-map, and the devlink code doesn't follow the mapping?
>
No, what's happening is that (and this is something I just learned)
that if a parent has an "#interrupt-cells" property, it becomes your
interrupt parent. In this case, the motherboard-bus (still a platform
device) is the parent, but it never probes (because it's simple-bus
and "arm,vexpress,v2p-p1"). But it becomes the interrupt parent. And
this mmci device is marked as a consumer of this bus (while still a
grand-child). Yeah, I'm working on patches (multiple rewrites) to take
care of cases like this.
-Saravana
Re: [PATCH v2 2/2] ima: Free IMA measurement buffer after kexec syscall
On Thu, Feb 04, 2021 at 09:49:51AM -0800, Lakshmi Ramasubramanian wrote:
> IMA allocates kernel virtual memory to carry forward the measurement
> list, from the current kernel to the next kernel on kexec system call,
> in ima_add_kexec_buffer() function. This buffer is not freed before
> completing the kexec system call resulting in memory leak.
>
> Add ima_buffer field in "struct kimage" to store the virtual address
> of the buffer allocated for the IMA measurement list.
> Free the memory allocated for the IMA measurement list in
> kimage_file_post_load_cleanup() function.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggested-by: Tyler Hicks
> Reviewed-by: Thiago Jung Bauermann
> Reviewed-by: Tyler Hicks
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
> ---
> include/linux/kexec.h | 5 +
> kernel/kexec_file.c| 5 +
> security/integrity/ima/ima_kexec.c | 2 ++
> 3 files changed, 12 insertions(+)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: {standard input}:577: Error: unsupported relocation against base
Hi Christophe and Michael,
On Mon, Jan 18, 2021 at 10:24:08PM +0800, Christophe Leroy wrote:
>
>
> Le 05/01/2021 ? 11:58, kernel test robot a 閏rit :
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
> > commit: 8b8319b181fd9d6821703fef1228b4dcde613a16 powerpc/44x: Don't support
> > 440 when CONFIG_PPC_47x is set
>
> I see no link with that commit. Looks like the problem has been existing for
> some time.
> It exists on the commit before that one, it exists on v5.9 and it exists on
> v5.10 with that commit
> reverted.
Yes, this seems to be a long-standing issue, and we just double checked
this compile error.
It happend when compiling arch/powerpc/platforms/44x/fsp2.c, macro
'mfdcr' requirs an instant number as parameter, while is not met by
show_plbopb_regs(). Changing show_plbopb_regs() from function to
a macro fixes the error, as the patch below:
Thanks,
Feng
>From 3bcb9638afc873d0e803aea1aad4f77bf1c2f6f6 Mon Sep 17 00:00:00 2001
From: Feng Tang
Date: Fri, 5 Feb 2021 16:08:43 +0800
Subject: [PATCH] powerpc/44x/fsp2: fix a compiling error regarding macro
'mdfcr'
0day's kbuild test found error:
"
CC arch/powerpc/platforms/44x/fsp2.o
{standard input}:577: Error: unsupported relocation against base
{standard input}:580: Error: unsupported relocation against base
{standard input}:583: Error: unsupported relocation against base
"
The reason is macro 'mfdcr' requirs an instant number as parameter,
which is not met by show_plbopb_regs().
Fix it by converting show_plbopb_regs() from function to macro.
Reported-by: kernel test robot
Signed-off-by: Feng Tang
---
arch/powerpc/platforms/44x/fsp2.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/44x/fsp2.c
b/arch/powerpc/platforms/44x/fsp2.c
index b299e43..4732669 100644
--- a/arch/powerpc/platforms/44x/fsp2.c
+++ b/arch/powerpc/platforms/44x/fsp2.c
@@ -66,15 +66,15 @@ static void l2regs(void)
pr_err("LOG5: 0x%08x\n", mfl2(L2LOG5));
}
-static void show_plbopb_regs(u32 base, int num)
-{
- pr_err("\nPLBOPB Bridge %d:\n", num);
- pr_err("GESR0: 0x%08x\n", mfdcr(base + PLB4OPB_GESR0));
- pr_err("GESR1: 0x%08x\n", mfdcr(base + PLB4OPB_GESR1));
- pr_err("GESR2: 0x%08x\n", mfdcr(base + PLB4OPB_GESR2));
- pr_err("GEARU: 0x%08x\n", mfdcr(base + PLB4OPB_GEARU));
- pr_err("GEAR: 0x%08x\n", mfdcr(base + PLB4OPB_GEAR));
-}
+#define show_plbopb_regs(base, num) \
+ { \
+ pr_err("\nPLBOPB Bridge %d:\n", num); \
+ pr_err("GESR0: 0x%08x\n", mfdcr(base + PLB4OPB_GESR0)); \
+ pr_err("GESR1: 0x%08x\n", mfdcr(base + PLB4OPB_GESR1)); \
+ pr_err("GESR2: 0x%08x\n", mfdcr(base + PLB4OPB_GESR2)); \
+ pr_err("GEARU: 0x%08x\n", mfdcr(base + PLB4OPB_GEARU)); \
+ pr_err("GEAR: 0x%08x\n", mfdcr(base + PLB4OPB_GEAR)); \
+ }
static irqreturn_t bus_err_handler(int irq, void *data)
{
--
2.7.4
> > date: 5 weeks ago
> > config: powerpc-randconfig-p002-20210105 (attached as .config)
> > compiler: powerpc-linux-gcc (GCC) 9.3.0
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > #
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b8319b181fd9d6821703fef1228b4dcde613a16
> > git remote add linus
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > git fetch --no-tags linus master
> > git checkout 8b8319b181fd9d6821703fef1228b4dcde613a16
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> > ARCH=powerpc
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> > All errors (new ones prefixed by >>):
> >
> > {standard input}: Assembler messages:
> >>> {standard input}:577: Error: unsupported relocation against base
> > {standard input}:580: Error: unsupported relocation against base
> > {standard input}:583: Error: unsupported relocation against base
> > {standard input}:586: Error: unsupported relocation against base
> > {standard input}:589: Error: unsupported relocation against base
> > {standard input}:592: Error: unsupported relocation against base
> > {standard input}:595: Error: unsupported relocation against base
> > {standard input}:598: Error: unsupported relocation against base
> > {standard input}:601: Error: unsupported relocation against base
> > {standard input}:604: Error: unsupported relocation against base
> > {standard input}:607: Error: unsupported relocation against base
> > {standard input}:610: Error: unsupported
Re: [GIT PULL] interconnect changes for 5.12
On Fri, Feb 05, 2021 at 11:52:46AM +0200, Georgi Djakov wrote: > Hello Greg, > > This is the pull request with the interconnect changes for the 5.12-rc1 > merge window. These include two new drivers some driver consolidation. > > Patches have been in linux-next without any reported issues. Please pull > into char-misc-next. > > Thanks, > Georgi > > The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: > > Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc.git > tags/icc-5.12-rc1 Pulled and pushed out, thanks. greg k-h
Re: [PATCH] ARM: configs: at91: enable drivers for sam9x60
On 2/5/21 11:54 AM, Claudiu Beznea wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Enable drivers for sam9x60/sam9x60-ek: > - shutdown controller > - CAN > - AT24 EEPROM (present on SAM9X60-EK) > - MCP23S08 (present on SAM9X60-EK) > - AES, TDES, SHA Crypto IPs are present only sam9x60. Should we have them as modules? > > And use "make savedefconfig". > > Signed-off-by: Claudiu Beznea With or without the Crypto IPs as modules: Reviewed-by: Tudor Ambarus > --- > arch/arm/configs/at91_dt_defconfig | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/configs/at91_dt_defconfig > b/arch/arm/configs/at91_dt_defconfig > index 5f3415c743ec..e274f8c492d2 100644 > --- a/arch/arm/configs/at91_dt_defconfig > +++ b/arch/arm/configs/at91_dt_defconfig > @@ -17,8 +17,6 @@ CONFIG_SOC_SAM9X60=y > # CONFIG_ATMEL_CLOCKSOURCE_PIT is not set > CONFIG_AEABI=y > CONFIG_UACCESS_WITH_MEMCPY=y > -CONFIG_ZBOOT_ROM_TEXT=0x0 > -CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x2110,25165824 > root=/dev/ram0 rw" > @@ -38,6 +36,8 @@ CONFIG_IP_PNP_BOOTP=y > CONFIG_IP_PNP_RARP=y > # CONFIG_INET_DIAG is not set > CONFIG_IPV6_SIT_6RD=y > +CONFIG_CAN=y > +CONFIG_CAN_AT91=y > CONFIG_CFG80211=y > CONFIG_MAC80211=y > CONFIG_DEVTMPFS=y > @@ -58,6 +58,7 @@ CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_COUNT=4 > CONFIG_BLK_DEV_RAM_SIZE=8192 > CONFIG_ATMEL_SSC=y > +CONFIG_EEPROM_AT24=m > CONFIG_SCSI=y > CONFIG_BLK_DEV_SD=y > # CONFIG_SCSI_LOWLEVEL is not set > @@ -91,7 +92,6 @@ CONFIG_RT2800USB_UNKNOWN=y > CONFIG_RTL8187=m > CONFIG_RTL8192CU=m > # CONFIG_RTLWIFI_DEBUG is not set > -CONFIG_INPUT_POLLDEV=y > CONFIG_INPUT_JOYDEV=y > CONFIG_INPUT_EVDEV=y > # CONFIG_KEYBOARD_ATKBD is not set > @@ -111,8 +111,8 @@ CONFIG_I2C_GPIO=y > CONFIG_SPI=y > CONFIG_SPI_ATMEL=y > CONFIG_SPI_ATMEL_QUADSPI=y > +CONFIG_PINCTRL_MCP23S08=m > CONFIG_POWER_RESET=y > -# CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC is not set > CONFIG_POWER_SUPPLY=y > # CONFIG_HWMON is not set > CONFIG_WATCHDOG=y > @@ -208,7 +208,9 @@ CONFIG_NLS_UTF8=y > CONFIG_CRYPTO_ECB=y > CONFIG_CRYPTO_USER_API_HASH=m > CONFIG_CRYPTO_USER_API_SKCIPHER=m > -# CONFIG_CRYPTO_HW is not set > +CONFIG_CRYPTO_DEV_ATMEL_AES=y > +CONFIG_CRYPTO_DEV_ATMEL_TDES=y > +CONFIG_CRYPTO_DEV_ATMEL_SHA=y > CONFIG_CRC_CCITT=y > CONFIG_FONTS=y > CONFIG_FONT_8x8=y > -- > 2.7.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
[PATCH 3/3] crypto: hisilicon/sec - fixes shash test error
If this configuration item is not turned on, the allocation of crypto_tfm will fail when the shash algorithm calculates the hash through the software. Signed-off-by: Longfang Liu --- arch/arm64/configs/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 8383016..7cfc9b6 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -117,7 +117,7 @@ CONFIG_KVM=y CONFIG_ARM64_CRYPTO=y CONFIG_CRYPTO_SHA1_ARM64_CE=y CONFIG_CRYPTO_SHA2_ARM64_CE=y -CONFIG_CRYPTO_SHA512_ARM64_CE=m +CONFIG_CRYPTO_SHA512_ARM64_CE=y CONFIG_CRYPTO_SHA3_ARM64=m CONFIG_CRYPTO_SM3_ARM64_CE=m CONFIG_CRYPTO_GHASH_ARM64_CE=y -- 2.8.1
[PATCH 0/3] crypto:hisilicon/sec - fixes some coding style
1. Fix two problems. 2. Fix some coding style. Longfang Liu (3): crypto: hisilicon/sec - fixes some log printing style crypto: hisilicon/sec - fixes some driver coding style crypto: hisilicon/sec - fixes shash test error arch/arm64/configs/defconfig | 2 +- drivers/crypto/hisilicon/sec2/sec.h| 5 +- drivers/crypto/hisilicon/sec2/sec_crypto.c | 82 +- drivers/crypto/hisilicon/sec2/sec_crypto.h | 2 - drivers/crypto/hisilicon/sec2/sec_main.c | 131 + 5 files changed, 119 insertions(+), 103 deletions(-) -- 2.8.1
[PATCH v4 03/22] media: camss: Replace trace_printk() with dev_dbg()
trace_printk() should not be used in production code,
since extra memory is used for special buffers whenever
trace_puts() is used.
Replace it with dev_dbg() which provides all of the desired
debugging functionality.
Signed-off-by: Robert Foss
Suggested-by: Nicolas Boichat
---
Changes since v3:
- Nicolas: Create this patch
drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 5 +++--
drivers/media/platform/qcom/camss/camss-vfe-4-7.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index a1b56b89130d..85b9bcbc7321 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -12,6 +12,7 @@
#include
#include
+#include "camss.h"
#include "camss-vfe.h"
#define VFE_0_HW_VERSION 0x000
@@ -936,8 +937,8 @@ static irqreturn_t vfe_isr(int irq, void *dev)
vfe->ops->isr_read(vfe, , );
- trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
-value0, value1);
+ dev_dbg(vfe->camss->dev, "VFE: status0 = 0x%08x, status1 = 0x%08x\n",
+ value0, value1);
if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
vfe->isr_ops.reset_ack(vfe);
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
index 84c33b8f9fe3..f7e00a2de393 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
@@ -12,6 +12,7 @@
#include
#include
+#include "camss.h"
#include "camss-vfe.h"
#define VFE_0_HW_VERSION 0x000
@@ -1069,8 +1070,8 @@ static irqreturn_t vfe_isr(int irq, void *dev)
vfe->ops->isr_read(vfe, , );
- trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
-value0, value1);
+ dev_dbg(vfe->camss->dev, "VFE: status0 = 0x%08x, status1 = 0x%08x\n",
+ value0, value1);
if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
vfe->isr_ops.reset_ack(vfe);
--
2.27.0
[PATCH 1/3] crypto: hisilicon/sec - fixes some log printing style
1. Fix a problem of error log printing
2. Modify error log printing style
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec.h| 5 +-
drivers/crypto/hisilicon/sec2/sec_crypto.c | 82 +++---
drivers/crypto/hisilicon/sec2/sec_crypto.h | 2 -
3 files changed, 42 insertions(+), 47 deletions(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec.h
b/drivers/crypto/hisilicon/sec2/sec.h
index 0849191..a8c10e3 100644
--- a/drivers/crypto/hisilicon/sec2/sec.h
+++ b/drivers/crypto/hisilicon/sec2/sec.h
@@ -4,8 +4,6 @@
#ifndef __HISI_SEC_V2_H
#define __HISI_SEC_V2_H
-#include
-
#include "../qm.h"
#include "sec_crypto.h"
@@ -50,7 +48,7 @@ struct sec_req {
int err_type;
int req_id;
- int flag;
+ u32 flag;
/* Status of the SEC request */
bool fake_busy;
@@ -139,6 +137,7 @@ struct sec_ctx {
bool pbuf_supported;
struct sec_cipher_ctx c_ctx;
struct sec_auth_ctx a_ctx;
+ struct device *dev;
};
enum sec_endian {
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2eaa516..d2c4a2c 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -43,7 +43,6 @@
#define SEC_TOTAL_IV_SZ(SEC_IV_SIZE * QM_Q_DEPTH)
#define SEC_SGL_SGE_NR 128
-#define SEC_CTX_DEV(ctx) (&(ctx)->sec->qm.pdev->dev)
#define SEC_CIPHER_AUTH0xfe
#define SEC_AUTH_CIPHER0x1
#define SEC_MAX_MAC_LEN64
@@ -96,7 +95,7 @@ static int sec_alloc_req_id(struct sec_req *req, struct
sec_qp_ctx *qp_ctx)
0, QM_Q_DEPTH, GFP_ATOMIC);
mutex_unlock(_ctx->req_lock);
if (unlikely(req_id < 0)) {
- dev_err(SEC_CTX_DEV(req->ctx), "alloc req id fail!\n");
+ dev_err(req->ctx->dev, "alloc req id fail!\n");
return req_id;
}
@@ -112,7 +111,7 @@ static void sec_free_req_id(struct sec_req *req)
int req_id = req->req_id;
if (unlikely(req_id < 0 || req_id >= QM_Q_DEPTH)) {
- dev_err(SEC_CTX_DEV(req->ctx), "free request id invalid!\n");
+ dev_err(req->ctx->dev, "free request id invalid!\n");
return;
}
@@ -138,7 +137,7 @@ static int sec_aead_verify(struct sec_req *req)
aead_req->cryptlen + aead_req->assoclen -
authsize);
if (unlikely(sz != authsize || memcmp(mac_out, mac, sz))) {
- dev_err(SEC_CTX_DEV(req->ctx), "aead verify failure!\n");
+ dev_err(req->ctx->dev, "aead verify failure!\n");
return -EBADMSG;
}
@@ -177,7 +176,7 @@ static void sec_req_cb(struct hisi_qp *qp, void *resp)
if (unlikely(req->err_type || done != SEC_SQE_DONE ||
(ctx->alg_type == SEC_SKCIPHER && flag != SEC_SQE_CFLAG) ||
(ctx->alg_type == SEC_AEAD && flag != SEC_SQE_AEAD_FLAG))) {
- dev_err(SEC_CTX_DEV(ctx),
+ dev_err_ratelimited(ctx->dev,
"err_type[%d],done[%d],flag[%d]\n",
req->err_type, done, flag);
err = -EIO;
@@ -326,8 +325,8 @@ static int sec_alloc_pbuf_resource(struct device *dev,
struct sec_alg_res *res)
static int sec_alg_resource_alloc(struct sec_ctx *ctx,
struct sec_qp_ctx *qp_ctx)
{
- struct device *dev = SEC_CTX_DEV(ctx);
struct sec_alg_res *res = qp_ctx->res;
+ struct device *dev = ctx->dev;
int ret;
ret = sec_alloc_civ_resource(dev, res);
@@ -360,7 +359,7 @@ static int sec_alg_resource_alloc(struct sec_ctx *ctx,
static void sec_alg_resource_free(struct sec_ctx *ctx,
struct sec_qp_ctx *qp_ctx)
{
- struct device *dev = SEC_CTX_DEV(ctx);
+ struct device *dev = ctx->dev;
sec_free_civ_resource(dev, qp_ctx->res);
@@ -373,7 +372,7 @@ static void sec_alg_resource_free(struct sec_ctx *ctx,
static int sec_create_qp_ctx(struct hisi_qm *qm, struct sec_ctx *ctx,
int qp_ctx_id, int alg_type)
{
- struct device *dev = SEC_CTX_DEV(ctx);
+ struct device *dev = ctx->dev;
struct sec_qp_ctx *qp_ctx;
struct hisi_qp *qp;
int ret = -ENOMEM;
@@ -428,7 +427,7 @@ static int sec_create_qp_ctx(struct hisi_qm *qm, struct
sec_ctx *ctx,
static void sec_release_qp_ctx(struct sec_ctx *ctx,
struct sec_qp_ctx *qp_ctx)
{
- struct device *dev = SEC_CTX_DEV(ctx);
+ struct device *dev = ctx->dev;
hisi_qm_stop_qp(qp_ctx->qp);
sec_alg_resource_free(ctx, qp_ctx);
@@ -452,6 +451,7 @@ static int sec_ctx_base_init(struct sec_ctx *ctx)
sec = container_of(ctx->qps[0]->qm, struct sec_dev, qm);
ctx->sec = sec;
+ ctx->dev =
[PATCH v4 01/22] media: camss: Fix vfe_isr_comp_done() documentation
Function name is comment is wrong, and was changed to be the same as the actual function name. The comment was changed to kerneldoc format. Signed-off-by: Robert Foss --- Changes since v1 - Bjorn: Fix function doc name & use kerneldoc format drivers/media/platform/qcom/camss/camss-vfe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c index fae2b513b2f9..94c9ca7d5cbb 100644 --- a/drivers/media/platform/qcom/camss/camss-vfe.c +++ b/drivers/media/platform/qcom/camss/camss-vfe.c @@ -1076,8 +1076,8 @@ static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm) spin_unlock_irqrestore(>output_lock, flags); } -/* - * vfe_isr_wm_done - Process composite image done interrupt +/** + * vfe_isr_comp_done() - Process composite image done interrupt * @vfe: VFE Device * @comp: Composite image id */ -- 2.27.0
[PATCH v4 05/22] media: camss: Make ISPIF subdevice optional
This driver supports multiple architecture versions of the Qualcomm ISP.
The CAMSS architecure which this driver is name after, and with the
introduction of this series, the Titan architecture.
The ISPIF is an IP-block that is only present in the CAMSS generation of
the architecture. In order to support the Titan generation, make the
ISPIF an optional subdevice.
Signed-off-by: Robert Foss
---
Changes since v1:
- Björn: Improved commit message
- Björn: Use local 'dev' ptr instead of 'camss->dev'
- Björn: Remove res/ispif NULL checks
- Björn: Remove ispif NULL checks before calling
msm_ispif_unregister_entities()
- Andrey: Fixed incorrect allocation size
.../media/platform/qcom/camss/camss-ispif.c | 114 ++
.../media/platform/qcom/camss/camss-ispif.h | 3 +-
drivers/media/platform/qcom/camss/camss.c | 111 +++--
drivers/media/platform/qcom/camss/camss.h | 2 +-
4 files changed, 142 insertions(+), 88 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c
b/drivers/media/platform/qcom/camss/camss-ispif.c
index adeb92808998..c36570042082 100644
--- a/drivers/media/platform/qcom/camss/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss/camss-ispif.c
@@ -161,6 +161,7 @@ static const u32 ispif_formats_8x96[] = {
static irqreturn_t ispif_isr_8x96(int irq, void *dev)
{
struct ispif_device *ispif = dev;
+ struct camss *camss = ispif->camss;
u32 value0, value1, value2, value3, value4, value5;
value0 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_0(0));
@@ -186,34 +187,34 @@ static irqreturn_t ispif_isr_8x96(int irq, void *dev)
complete(>reset_complete[1]);
if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 pix0 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 pix0 overflow\n");
if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 rdi0 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 rdi0 overflow\n");
if (unlikely(value1 & ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 pix1 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 pix1 overflow\n");
if (unlikely(value1 & ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 rdi1 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 rdi1 overflow\n");
if (unlikely(value2 & ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 rdi2 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 rdi2 overflow\n");
if (unlikely(value3 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE1 pix0 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE1 pix0 overflow\n");
if (unlikely(value3 & ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE1 rdi0 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE1 rdi0 overflow\n");
if (unlikely(value4 & ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE1 pix1 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE1 pix1 overflow\n");
if (unlikely(value4 & ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE1 rdi1 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE1 rdi1 overflow\n");
if (unlikely(value5 & ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE1 rdi2 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE1 rdi2 overflow\n");
return IRQ_HANDLED;
}
@@ -228,6 +229,7 @@ static irqreturn_t ispif_isr_8x96(int irq, void *dev)
static irqreturn_t ispif_isr_8x16(int irq, void *dev)
{
struct ispif_device *ispif = dev;
+ struct camss *camss = ispif->camss;
u32 value0, value1, value2;
value0 = readl_relaxed(ispif->base + ISPIF_VFE_m_IRQ_STATUS_0(0));
@@ -244,30 +246,32 @@ static irqreturn_t ispif_isr_8x16(int irq, void *dev)
complete(>reset_complete[0]);
if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 pix0 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 pix0 overflow\n");
if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW))
- dev_err_ratelimited(to_device(ispif), "VFE0 rdi0 overflow\n");
+ dev_err_ratelimited(camss->dev, "VFE0 rdi0 overflow\n");
if (unlikely(value1 & ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW))
-
[PATCH v4 00/22] Add support for the SDM845 Camera Subsystem
This series implements support for the camera subsystem found in the SDM845 SOCs and the Titan 170 ISP. The support is partial in that it implements CSIPHY, CSID, and partial VFE support. The Titan generation of the ISP diverges a fair amount from the design of the previous architecture generation, CAMSS. As a result some pretty invasive refactoring is done in this series. It also means that at this time we're unable to implement support for all of the IP blocks contained. This is due to a combination of legal considerations with respect to the IP and its owner Qualcomm and time & man hour constrains on the Linaro side. The CSIPHY (CSI Physical Layer) & CSID (CSI Decoder) support is complete, but the VFE (Video Front End, which is referred to as IFE (Image Front End) in the Titan generation of ISPs) only has support for the RDI (Raw Dump Interface) which allows the raw output of the CSID to be written to memory. The 2nd interface implemented in the VFE silicon is the PIX interface, and camss does not support it for this generation of ISPs. The reason for this is that the PIX interface is used for sending image data to the BPS (Bayer Processing Section) & IPE (Image Processing Engine), but both of these units are beyond the scope of enabling basic ISP functionality for the SDM845. Since the Titan architecture generation diverges quite a bit from the CAMSS generation, a lot of pretty major refactoring is carried out in this series. Both the CSID & VFE core paths are made more general and hardware version specific parts are broken out. The CSIPHY didn't require quite as radical changes and therefore keeps its current form. Tested on: - Qcom RB3 / db845c + camera mezzanine, which is SDM845 based - db410c + D3 Camera mezzanine, which is APQ8016 based Branch: - https://git.linaro.org/people/robert.foss/linux.git/log/?h=camss_sdm845_v1 - https://git.linaro.org/people/robert.foss/linux.git/log/?h=camss_sdm845_v2 - https://git.linaro.org/people/robert.foss/linux.git/log/?h=camss_sdm845_v3 Due to the dt-bindings supporting sdm660-camss, this series depends the sdm660 clock driver being upstreamed. I've linked this series below. SDM630/660 Multimedia and GPU clock controllers https://lkml.org/lkml/2020/9/26/166 Robert Foss (22): media: camss: Fix vfe_isr_comp_done() documentation media: camss: Fix vfe_isr comment typo media: camss: Replace trace_printk() with dev_dbg() media: camss: Add CAMSS_845 camss version media: camss: Make ISPIF subdevice optional media: camss: Refactor VFE HW version support media: camss: Add support for VFE hardware version Titan 170 media: camss: Add missing format identifiers media: camss: Refactor CSID HW version support media: camss: Add support for CSID hardware version Titan 170 media: camss: Add support for CSIPHY hardware version Titan 170 media: camss: Remove per VFE power domain toggling media: camss: Enable SDM845 dt-bindings: media: camss: Add qcom,msm8916-camss binding dt-bindings: media: camss: Add qcom,msm8996-camss binding dt-bindings: media: camss: Add qcom,sdm660-camss binding dt-bindings: media: camss: Add qcom,sdm845-camss binding MAINTAINERS: Change CAMSS documentation to use dtschema bindings media: dt-bindings: media: Remove qcom,camss documentation arm64: dts: sdm845: Add CAMSS ISP node arm64: dts: sdm845-db845c: Configure regulators for camss node arm64: dts: sdm845-db845c: Enable ov8856 sensor and connect to ISP .../devicetree/bindings/media/qcom,camss.txt | 236 .../bindings/media/qcom,msm8916-camss.yaml| 256 .../bindings/media/qcom,msm8996-camss.yaml| 387 ++ .../bindings/media/qcom,sdm660-camss.yaml | 398 ++ .../bindings/media/qcom,sdm845-camss.yaml | 370 ++ MAINTAINERS |2 +- arch/arm64/boot/dts/qcom/sdm845-db845c.dts| 23 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 135 ++ drivers/media/platform/qcom/camss/Makefile|6 + .../platform/qcom/camss/camss-csid-170.c | 602 + .../platform/qcom/camss/camss-csid-4-1.c | 338 + .../platform/qcom/camss/camss-csid-4-7.c | 406 ++ .../media/platform/qcom/camss/camss-csid.c| 620 + .../media/platform/qcom/camss/camss-csid.h| 178 ++- .../qcom/camss/camss-csiphy-3ph-1-0.c | 182 ++- .../media/platform/qcom/camss/camss-csiphy.c | 66 +- .../media/platform/qcom/camss/camss-ispif.c | 117 +- .../media/platform/qcom/camss/camss-ispif.h |3 +- .../media/platform/qcom/camss/camss-vfe-170.c | 804 .../media/platform/qcom/camss/camss-vfe-4-1.c | 123 +- .../media/platform/qcom/camss/camss-vfe-4-7.c | 244 ++-- .../media/platform/qcom/camss/camss-vfe-4-8.c | 1164 + .../platform/qcom/camss/camss-vfe-gen1.c | 763 +++ .../platform/qcom/camss/camss-vfe-gen1.h | 110 ++ drivers/media/platform/qcom/camss/camss-vfe.c | 840 +---
[PATCH v4 10/22] media: camss: Add support for CSID hardware version Titan 170
Add register definitions for version 170 of the Titan architecture and implement support for the CSID subdevice. Signed-off-by: Robert Foss --- Changes since v3 - Sakari: Make variable const drivers/media/platform/qcom/camss/Makefile| 1 + .../platform/qcom/camss/camss-csid-170.c | 602 ++ .../media/platform/qcom/camss/camss-csid.c| 4 + .../media/platform/qcom/camss/camss-csid.h| 2 + .../media/platform/qcom/camss/camss-vfe-170.c | 1 - drivers/media/platform/qcom/camss/camss.c | 62 ++ 6 files changed, 671 insertions(+), 1 deletion(-) create mode 100644 drivers/media/platform/qcom/camss/camss-csid-170.c diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile index cff388b653ba..0752c46ea37b 100644 --- a/drivers/media/platform/qcom/camss/Makefile +++ b/drivers/media/platform/qcom/camss/Makefile @@ -6,6 +6,7 @@ qcom-camss-objs += \ camss-csid.o \ camss-csid-4-1.o \ camss-csid-4-7.o \ + camss-csid-170.o \ camss-csiphy-2ph-1-0.o \ camss-csiphy-3ph-1-0.o \ camss-csiphy.o \ diff --git a/drivers/media/platform/qcom/camss/camss-csid-170.c b/drivers/media/platform/qcom/camss/camss-csid-170.c new file mode 100644 index ..0e9b08ed38c2 --- /dev/null +++ b/drivers/media/platform/qcom/camss/camss-csid-170.c @@ -0,0 +1,602 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * camss-csid-4-7.c + * + * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module + * + * Copyright (C) 2020 Linaro Ltd. + */ +#include +#include +#include +#include +#include + +#include "camss-csid.h" +#include "camss.h" + +/* The CSID 2 IP-block is different from the others, + * and is of a bare-bones Lite version, with no PIX + * interface support. As a result of that it has an + * alternate register layout. + */ +#define IS_LITE(csid->id == 2 ? 1 : 0) + +#define CSID_HW_VERSION0x0 +#defineHW_VERSION_STEPPING 0 +#defineHW_VERSION_REVISION 16 +#defineHW_VERSION_GENERATION 28 + +#define CSID_RST_STROBES 0x10 +#defineRST_STROBES 0 + +#define CSID_CSI2_RX_IRQ_STATUS0x20 +#defineCSID_CSI2_RX_IRQ_MASK 0x24 +#define CSID_CSI2_RX_IRQ_CLEAR 0x28 + +#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) ((IS_LITE ? 0x30 : 0x40) \ ++ 0x10 * (rdi)) +#define CSID_CSI2_RDIN_IRQ_MASK(rdi) ((IS_LITE ? 0x34 : 0x44) \ ++ 0x10 * (rdi)) +#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) ((IS_LITE ? 0x38 : 0x48) \ ++ 0x10 * (rdi)) +#define CSID_CSI2_RDIN_IRQ_SET(rdi)((IS_LITE ? 0x3C : 0x4C) \ ++ 0x10 * (rdi)) + +#define CSID_TOP_IRQ_STATUS0x70 +#defineTOP_IRQ_STATUS_RESET_DONE 0 +#define CSID_TOP_IRQ_MASK 0x74 +#define CSID_TOP_IRQ_CLEAR 0x78 +#define CSID_TOP_IRQ_SET 0x7C +#define CSID_IRQ_CMD 0x80 +#defineIRQ_CMD_CLEAR 0 +#defineIRQ_CMD_SET 4 + +#define CSID_CSI2_RX_CFG0 0x100 +#defineCSI2_RX_CFG0_NUM_ACTIVE_LANES 0 +#defineCSI2_RX_CFG0_DL0_INPUT_SEL 4 +#defineCSI2_RX_CFG0_DL1_INPUT_SEL 8 +#defineCSI2_RX_CFG0_DL2_INPUT_SEL 12 +#defineCSI2_RX_CFG0_DL3_INPUT_SEL 16 +#defineCSI2_RX_CFG0_PHY_NUM_SEL20 +#defineCSI2_RX_CFG0_PHY_TYPE_SEL 24 + +#define CSID_CSI2_RX_CFG1 0x104 +#defineCSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN 0 +#defineCSI2_RX_CFG1_DE_SCRAMBLE_EN 1 +#defineCSI2_RX_CFG1_VC_MODE2 +#defineCSI2_RX_CFG1_COMPLETE_STREAM_EN 4 +#defineCSI2_RX_CFG1_COMPLETE_STREAM_FRAME_TIMING 5 +#defineCSI2_RX_CFG1_MISR_EN6 +#defineCSI2_RX_CFG1_CGC_MODE 7 +#defineCGC_MODE_DYNAMIC_GATING 0 +#defineCGC_MODE_ALWAYS_ON 1 + +#define CSID_RDI_CFG0(rdi) ((IS_LITE ? 0x200 : 0x300) \ ++ 0x100 * (rdi)) +#defineRDI_CFG0_BYTE_CNTR_EN 0 +#defineRDI_CFG0_FORMAT_MEASURE_EN 1 +#defineRDI_CFG0_TIMESTAMP_EN 2 +#defineRDI_CFG0_DROP_H_EN 3 +#defineRDI_CFG0_DROP_V_EN 4 +#defineRDI_CFG0_CROP_H_EN 5 +#defineRDI_CFG0_CROP_V_EN 6 +#define
[PATCH v4 11/22] media: camss: Add support for CSIPHY hardware version Titan 170
Add register definitions for version 170 of the Titan architecture
and implement support for the CSIPHY subdevice.
Signed-off-by: Robert Foss
---
.../qcom/camss/camss-csiphy-3ph-1-0.c | 182 --
.../media/platform/qcom/camss/camss-csiphy.c | 66 +--
drivers/media/platform/qcom/camss/camss.c | 74 +++
3 files changed, 290 insertions(+), 32 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 97cb9de85031..148b8c50382c 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -47,6 +47,105 @@
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_IDBIT(1)
#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(n) (0x8b0 + 0x4 * (n))
+#define CSIPHY_DEFAULT_PARAMS0
+#define CSIPHY_LANE_ENABLE 1
+#define CSIPHY_SETTLE_CNT_LOWER_BYTE 2
+#define CSIPHY_SETTLE_CNT_HIGHER_BYTE3
+#define CSIPHY_DNP_PARAMS4
+#define CSIPHY_2PH_REGS 5
+#define CSIPHY_3PH_REGS 6
+
+struct csiphy_reg_t {
+ int32_t reg_addr;
+ int32_t reg_data;
+ int32_t delay;
+ uint32_t csiphy_param_type;
+};
+
+static const struct
+csiphy_reg_t lane_regs_sdm845[5][14] = {
+ {
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x000c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0060, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0064, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ },
+ {
+ {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0734, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x071C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0708, 0x14, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x070C, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0710, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0760, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0764, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ },
+ {
+ {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0234, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x021C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0200, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0208, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x020C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0210, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0260, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0264, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ },
+ {
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0400, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x040C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0460, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0464, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ },
+ {
+ {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+
[PATCH v4 16/22] dt-bindings: media: camss: Add qcom,sdm660-camss binding
Add bindings for qcom,sdm660-camss in order to support the camera subsystem on SDM630/660 and SDA variants. Signed-off-by: Robert Foss Reviewed-by: Rob Herring --- Changes since v2 - Rob: Add new line at end of file - Rob: Remove redundant descriptions - Rob: Add power domain description - Rob: Make clock-lanes a constant - Rob: Rework to conform to new port schema - Add max & minItems to data-lanes - Remove ports requirement - endpoint & reg - Added Angelo as binding maintainer - Removed Todor as binding maintainer Changes since v3: - Rob: Added r-b .../bindings/media/qcom,sdm660-camss.yaml | 398 ++ 1 file changed, 398 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml new file mode 100644 index ..841a1aafdd13 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -0,0 +1,398 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#; +$schema: "http://devicetree.org/meta-schemas/core.yaml#; + +title: Qualcomm CAMSS ISP + +maintainers: + - Robert Foss + - AngeloGioacchino Del Regno + +description: | + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms + +properties: + compatible: +const: qcom,sdm660-camss + + clocks: +minItems: 42 +maxItems: 42 + + clock-names: +items: + - const: ahb + - const: cphy_csid0 + - const: cphy_csid1 + - const: cphy_csid2 + - const: cphy_csid3 + - const: csi0_ahb + - const: csi0 + - const: csi0_phy + - const: csi0_pix + - const: csi0_rdi + - const: csi1_ahb + - const: csi1 + - const: csi1_phy + - const: csi1_pix + - const: csi1_rdi + - const: csi2_ahb + - const: csi2 + - const: csi2_phy + - const: csi2_pix + - const: csi2_rdi + - const: csi3_ahb + - const: csi3 + - const: csi3_phy + - const: csi3_pix + - const: csi3_rdi + - const: csiphy0_timer + - const: csiphy1_timer + - const: csiphy2_timer + - const: csiphy_ahb2crif + - const: csi_vfe0 + - const: csi_vfe1 + - const: ispif_ahb + - const: throttle_axi + - const: top_ahb + - const: vfe0_ahb + - const: vfe0 + - const: vfe0_stream + - const: vfe1_ahb + - const: vfe1 + - const: vfe1_stream + - const: vfe_ahb + - const: vfe_axi + + interrupts: +minItems: 10 +maxItems: 10 + + interrupt-names: +items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid3 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: ispif + - const: vfe0 + - const: vfe1 + + iommus: +maxItems: 4 + + power-domains: +items: + - description: VFE0 GDSC - Video Front End, Global Distributed Switch Controller. + - description: VFE1 GDSC - Video Front End, Global Distributed Switch Controller. + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +description: + CSI input ports. + +properties: + port@0: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@1: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@2: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +
Re: [PATCH v2] dma-mapping: benchmark: pretend DMA is transmitting
On Fri, Feb 05, 2021 at 10:52:37AM +, Song Bao Hua (Barry Song) wrote:
> I assume there is no need to keep the same size with 5.11-rc, so
> could change the struct to:
>
> struct map_benchmark {
> __u64 avg_map_100ns; /* average map latency in 100ns */
> __u64 map_stddev; /* standard deviation of map latency */
> __u64 avg_unmap_100ns; /* as above */
> __u64 unmap_stddev;
> __u32 threads; /* how many threads will do map/unmap in parallel */
> __u32 seconds; /* how long the test will last */
> __s32 node; /* which numa node this benchmark will run on */
> __u32 dma_bits; /* DMA addressing capability */
> __u32 dma_dir; /* DMA data direction */
> __u8 expansion[84]; /* For future use */
> };
>
> This won't increase size on 64bit system, but it increases 4bytes
> on 32bits system comparing to 5.11-rc. How do you think about it?
Yes, that sounds good. Please send me a two patch series with the
first one changing the alignment, and the second adding the delay.
I'll send the first one off to Linus ASAP then.
Re: Possible deny of service with memfd_create()
Am 05.02.21 um 11:50 schrieb Michal Hocko: On Fri 05-02-21 08:54:31, Christian König wrote: Am 05.02.21 um 01:32 schrieb Hugh Dickins: On Thu, 4 Feb 2021, Michal Hocko wrote: On Thu 04-02-21 17:32:20, Christian Koenig wrote: Hi Michal, as requested in the other mail thread the following sample code gets my test system down within seconds. The issue is that the memory allocated for the file descriptor is not accounted to the process allocating it, so the OOM killer pics whatever process it things is good but never my small test program. Since memfd_create() doesn't need any special permission this is a rather nice deny of service and as far as I can see also works with a standard Ubuntu 5.4.0-65-generic kernel. Thanks for following up. This is really nasty but now that I am looking at it more closely, this is not really different from tmpfs in general. You are free to create files and eat the memory without being accounted for that memory because that is not seen as your memory from the sysstem POV. You would have to map that memory to be part of your rss. I mostly agree. The big difference is that tmpfs is only available when mounted. And tmpfs can be restricted in size per mount point as well as per user quotas IIRC. Looking at my desktop system those restrictions are actually exactly what I see there. I cannot find anything about per user quotas for tmpfs in the tmpfs man page. Or maybe I am looking at a wrong layer and there is a generic handling somewhere in the vfs core? I think so, yes. I briefly remember a discussion about how to implement quotas for tmpfs, but that was a really long time ago and I didn't followed it till the end. But memfd_create() is just free for all, you don't have any size limit nor access restriction as far as I can see. Yes, this is unfortunate and a design decision that should have been considered when the syscall has been introduced. But this boat has sailed looong ago to change that without risking a userspace breakage. The only existing protection right now is to use memoery cgroup controller because the tmpfs memory is accounted to the process which faults the memory in (or write to the file). Agreed, but having to rely on cgroup is not really satisfying when you have to maintain a hardened server. Yes I do recognize the pain. The only other way to mitigate the risk is to disallow the syscall to untrusted users in a hardened environment. You should be very strict in tmpfs usage there already. Well it is perfectly valid for a process to use as much memory as it wants, the problem is that we are not holding the process accountable for it. As I said we have similar problems with GPU drivers and I think we just need a way to do this. Let me think about it a bit, maybe we can somehow use the file owner for this. Thanks, Christian.
[PATCH v4 02/22] media: camss: Fix vfe_isr comment typo
Comment refers to ISPIF, but this is incorrect. Only the VFE interrupts are handled by this function. Signed-off-by: Robert Foss Reviewed-by: Bjorn Andersson --- Changes since v1 - Bjorn: Add r-b drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 2 +- drivers/media/platform/qcom/camss/camss-vfe-4-7.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c index 174a36be6f5d..a1b56b89130d 100644 --- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c @@ -922,7 +922,7 @@ static void vfe_violation_read(struct vfe_device *vfe) } /* - * vfe_isr - ISPIF module interrupt handler + * vfe_isr - VFE module interrupt handler * @irq: Interrupt line * @dev: VFE device * diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c index b5704a2f119b..84c33b8f9fe3 100644 --- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c @@ -1055,7 +1055,7 @@ static void vfe_violation_read(struct vfe_device *vfe) } /* - * vfe_isr - ISPIF module interrupt handler + * vfe_isr - VFE module interrupt handler * @irq: Interrupt line * @dev: VFE device * -- 2.27.0
Re: [PATCH] perf record: Fix continue profiling after draining the buffer
On Fri, Feb 05, 2021 at 07:35:22PM +0900, Namhyung Kim wrote:
> Hello,
>
> On Fri, Feb 5, 2021 at 3:50 PM Yang Jihong wrote:
> >
> > commit da231338ec9c098707c8a1e4d8a50e2400e2fe17 uses eventfd to solve rare
> > race
> > where the setting and checking of 'done' which add done_fd to pollfd.
> > When draining buffer, revents of done_fd is 0 and evlist__filter_pollfd
> > function returns a non-zero value.
> > As a result, perf record does not stop profiling.
> >
> > The following simple scenarios can trigger this condition:
> >
> > sleep 10 &
> > perf record -p $!
> >
> > After the sleep process exits, perf record should stop profiling and exit.
> > However, perf record keeps running.
> >
> > If pollfd revents contains only POLLERR or POLLHUP,
> > perf record indicates that buffer is draining and need to stop profiling.
> > Use fdarray_flag__nonfilterable to set done eventfd to nonfilterable
> > objects,
> > so that evlist__filter_pollfd does not filter and check done eventfd.
> >
> > Fixes: da231338ec9c (perf record: Use an eventfd to wakeup when done)
> > Signed-off-by: Yang Jihong
> > ---
> > tools/perf/builtin-record.c | 2 +-
> > tools/perf/util/evlist.c| 8
> > tools/perf/util/evlist.h| 4
> > 3 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> > index fd3911650612..51e593e896ea 100644
> > --- a/tools/perf/builtin-record.c
> > +++ b/tools/perf/builtin-record.c
> > @@ -1663,7 +1663,7 @@ static int __cmd_record(struct record *rec, int argc,
> > const char **argv)
> > status = -1;
> > goto out_delete_session;
> > }
> > - err = evlist__add_pollfd(rec->evlist, done_fd);
> > + err = evlist__add_wakeup_eventfd(rec->evlist, done_fd);
> > if (err < 0) {
> > pr_err("Failed to add wakeup eventfd to poll list\n");
> > status = err;
> > diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> > index 05363a7247c4..fea4c1e8010d 100644
> > --- a/tools/perf/util/evlist.c
> > +++ b/tools/perf/util/evlist.c
> > @@ -572,6 +572,14 @@ int evlist__filter_pollfd(struct evlist *evlist, short
> > revents_and_mask)
> > return perf_evlist__filter_pollfd(>core, revents_and_mask);
> > }
> >
> > +#ifdef HAVE_EVENTFD_SUPPORT
> > +int evlist__add_wakeup_eventfd(struct evlist *evlist, int fd)
> > +{
> > + return perf_evlist__add_pollfd(>core, fd, NULL, POLLIN,
> > + fdarray_flag__nonfilterable);
> > +}
> > +#endif
>
> Does it build when HAVE_EVENTFD_SUPPORT is not defined?
yea, I was wondering the same.. but it's called only from
code within HAVE_EVENTFD_SUPPORT ifdef
jirka
>
> Thanks,
> Namhyung
>
>
> > +
> > int evlist__poll(struct evlist *evlist, int timeout)
> > {
> > return perf_evlist__poll(>core, timeout);
> > diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
> > index 1aae75895dea..6d4d62151bc8 100644
> > --- a/tools/perf/util/evlist.h
> > +++ b/tools/perf/util/evlist.h
> > @@ -142,6 +142,10 @@ struct evsel *evlist__find_tracepoint_by_name(struct
> > evlist *evlist, const char
> > int evlist__add_pollfd(struct evlist *evlist, int fd);
> > int evlist__filter_pollfd(struct evlist *evlist, short revents_and_mask);
> >
> > +#ifdef HAVE_EVENTFD_SUPPORT
> > +int evlist__add_wakeup_eventfd(struct evlist *evlist, int fd);
> > +#endif
> > +
> > int evlist__poll(struct evlist *evlist, int timeout);
> >
> > struct evsel *evlist__id2evsel(struct evlist *evlist, u64 id);
> > --
> > 2.17.1
> >
>
[RESEND PATCH 2/2] ASoC: stm32: i2s: add master clock provider
From: Olivier Moysan
Add master clock generation support in STM32 I2S driver.
The master clock provided by I2S can be used to feed a codec.
Signed-off-by: Olivier Moysan
---
sound/soc/stm/stm32_i2s.c | 310 --
1 file changed, 266 insertions(+), 44 deletions(-)
diff --git a/sound/soc/stm/stm32_i2s.c b/sound/soc/stm/stm32_i2s.c
index 7c4d63c33f15..7d1672cf78cc 100644
--- a/sound/soc/stm/stm32_i2s.c
+++ b/sound/soc/stm/stm32_i2s.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -196,6 +197,9 @@ enum i2s_datlen {
#define STM32_I2S_IS_MASTER(x) ((x)->ms_flg == I2S_MS_MASTER)
#define STM32_I2S_IS_SLAVE(x) ((x)->ms_flg == I2S_MS_SLAVE)
+#define STM32_I2S_NAME_LEN 32
+#define STM32_I2S_RATE_11K 11025
+
/**
* struct stm32_i2s_data - private data of I2S
* @regmap_conf: I2S register map configuration pointer
@@ -206,6 +210,7 @@ enum i2s_datlen {
* @dma_data_rx: dma configuration data for tx channel
* @substream: PCM substream data pointer
* @i2sclk: kernel clock feeding the I2S clock generator
+ * @i2smclk: master clock from I2S mclk provider
* @pclk: peripheral clock driving bus interface
* @x8kclk: I2S parent clock for sampling frequencies multiple of 8kHz
* @x11kclk: I2S parent clock for sampling frequencies multiple of 11kHz
@@ -215,6 +220,9 @@ enum i2s_datlen {
* @irq_lock: prevent race condition with IRQ
* @mclk_rate: master clock frequency (Hz)
* @fmt: DAI protocol
+ * @divider: prescaler division ratio
+ * @div: prescaler div field
+ * @odd: prescaler odd field
* @refcount: keep count of opened streams on I2S
* @ms_flg: master mode flag.
*/
@@ -227,6 +235,7 @@ struct stm32_i2s_data {
struct snd_dmaengine_dai_dma_data dma_data_rx;
struct snd_pcm_substream *substream;
struct clk *i2sclk;
+ struct clk *i2smclk;
struct clk *pclk;
struct clk *x8kclk;
struct clk *x11kclk;
@@ -236,10 +245,210 @@ struct stm32_i2s_data {
spinlock_t irq_lock; /* used to prevent race condition with IRQ */
unsigned int mclk_rate;
unsigned int fmt;
+ unsigned int divider;
+ unsigned int div;
+ bool odd;
int refcount;
int ms_flg;
};
+struct stm32_i2smclk_data {
+ struct clk_hw hw;
+ unsigned long freq;
+ struct stm32_i2s_data *i2s_data;
+};
+
+#define to_mclk_data(_hw) container_of(_hw, struct stm32_i2smclk_data, hw)
+
+static int stm32_i2s_calc_clk_div(struct stm32_i2s_data *i2s,
+ unsigned long input_rate,
+ unsigned long output_rate)
+{
+ unsigned int ratio, div, divider = 1;
+ bool odd;
+
+ ratio = DIV_ROUND_CLOSEST(input_rate, output_rate);
+
+ /* Check the parity of the divider */
+ odd = ratio & 0x1;
+
+ /* Compute the div prescaler */
+ div = ratio >> 1;
+
+ /* If div is 0 actual divider is 1 */
+ if (div) {
+ divider = ((2 * div) + odd);
+ dev_dbg(>pdev->dev, "Divider: 2*%d(div)+%d(odd) = %d\n",
+ div, odd, divider);
+ }
+
+ /* Division by three is not allowed by I2S prescaler */
+ if ((div == 1 && odd) || div > I2S_CGFR_I2SDIV_MAX) {
+ dev_err(>pdev->dev, "Wrong divider setting\n");
+ return -EINVAL;
+ }
+
+ if (input_rate % divider)
+ dev_dbg(>pdev->dev,
+ "Rate not accurate. requested (%ld), actual (%ld)\n",
+ output_rate, input_rate / divider);
+
+ i2s->div = div;
+ i2s->odd = odd;
+ i2s->divider = divider;
+
+ return 0;
+}
+
+static int stm32_i2s_set_clk_div(struct stm32_i2s_data *i2s)
+{
+ u32 cgfr, cgfr_mask;
+
+ cgfr = I2S_CGFR_I2SDIV_SET(i2s->div) | (i2s->odd << I2S_CGFR_ODD_SHIFT);
+ cgfr_mask = I2S_CGFR_I2SDIV_MASK | I2S_CGFR_ODD;
+
+ return regmap_update_bits(i2s->regmap, STM32_I2S_CGFR_REG,
+ cgfr_mask, cgfr);
+}
+
+static int stm32_i2s_set_parent_clock(struct stm32_i2s_data *i2s,
+ unsigned int rate)
+{
+ struct platform_device *pdev = i2s->pdev;
+ struct clk *parent_clk;
+ int ret;
+
+ if (!(rate % STM32_I2S_RATE_11K))
+ parent_clk = i2s->x11kclk;
+ else
+ parent_clk = i2s->x8kclk;
+
+ ret = clk_set_parent(i2s->i2sclk, parent_clk);
+ if (ret)
+ dev_err(>dev,
+ "Error %d setting i2sclk parent clock\n", ret);
+
+ return ret;
+}
+
+static long stm32_i2smclk_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *prate)
+{
+ struct stm32_i2smclk_data *mclk = to_mclk_data(hw);
+ struct stm32_i2s_data *i2s = mclk->i2s_data;
+ int ret;
+
+ ret =
[PATCH v4 07/22] media: camss: Add support for VFE hardware version Titan 170
Add register definitions for version 170 of the Titan architecture and implement support for the RDI output mode. The RDI mode as opposed to the PIX output mode for the VFE unit does not support any ISP functionality. This means essentially only supporting dumping the output of the whatever the CSI decoder receives from the sensor. For example will a sensor outputting YUV pixel format frames, only allow the VFE to dump those frames as they are received by the ISP to memory through the RDI interface. Signed-off-by: Robert Foss --- Changes since v1: - Andrey: Removed commented out chunk - Remove left over WIP comments drivers/media/platform/qcom/camss/Makefile| 1 + .../media/platform/qcom/camss/camss-vfe-170.c | 805 ++ drivers/media/platform/qcom/camss/camss-vfe.c | 59 +- drivers/media/platform/qcom/camss/camss-vfe.h | 25 +- .../media/platform/qcom/camss/camss-video.c | 100 +++ drivers/media/platform/qcom/camss/camss.c | 61 ++ 6 files changed, 1031 insertions(+), 20 deletions(-) create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-170.c diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile index 940c0ae3e003..052c4f405fa3 100644 --- a/drivers/media/platform/qcom/camss/Makefile +++ b/drivers/media/platform/qcom/camss/Makefile @@ -11,6 +11,7 @@ qcom-camss-objs += \ camss-vfe-4-1.o \ camss-vfe-4-7.o \ camss-vfe-4-8.o \ + camss-vfe-170.o \ camss-vfe-gen1.o \ camss-vfe.o \ camss-video.o \ diff --git a/drivers/media/platform/qcom/camss/camss-vfe-170.c b/drivers/media/platform/qcom/camss/camss-vfe-170.c new file mode 100644 index ..b8ac3a137c8a --- /dev/null +++ b/drivers/media/platform/qcom/camss/camss-vfe-170.c @@ -0,0 +1,805 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * camss-vfe-4-7.c + * + * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v4.7 + * + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * Copyright (C) 2015-2018 Linaro Ltd. + */ + +#include +#include +#include +#include + +#include "camss.h" +#include "camss-vfe.h" + +#define VFE_HW_VERSION (0x000) + +#define VFE_GLOBAL_RESET_CMD (0x018) +#defineGLOBAL_RESET_CMD_CORE BIT(0) +#defineGLOBAL_RESET_CMD_CAMIF BIT(1) +#defineGLOBAL_RESET_CMD_BUSBIT(2) +#defineGLOBAL_RESET_CMD_BUS_BDGBIT(3) +#defineGLOBAL_RESET_CMD_REGISTER BIT(4) +#defineGLOBAL_RESET_CMD_PM BIT(5) +#defineGLOBAL_RESET_CMD_BUS_MISR BIT(6) +#defineGLOBAL_RESET_CMD_TESTGENBIT(7) +#defineGLOBAL_RESET_CMD_DSPBIT(8) +#defineGLOBAL_RESET_CMD_IDLE_CGC BIT(9) + +#define VFE_CORE_CFG (0x050) +#defineCFG_PIXEL_PATTERN_YCBYCR(0x4) +#defineCFG_PIXEL_PATTERN_YCRYCB(0x5) +#defineCFG_PIXEL_PATTERN_CBYCRY(0x6) +#defineCFG_PIXEL_PATTERN_CRYCBY(0x7) +#defineCFG_COMPOSITE_REG_UPDATE_EN BIT(4) + +#define VFE_IRQ_CMD(0x058) +#defineCMD_GLOBAL_CLEARBIT(0) + +#define VFE_IRQ_MASK_0 (0x05c) +#defineMASK_0_CAMIF_SOFBIT(0) +#defineMASK_0_CAMIF_EOFBIT(1) +#defineMASK_0_RDIn_REG_UPDATE(n) BIT((n) + 5) +#defineMASK_0_line_n_REG_UPDATE(n) \ + ((n) == VFE_LINE_PIX ? \ + BIT(4) : MASK_0_RDIn_REG_UPDATE(n)) +#defineMASK_0_IMAGE_MASTER_n_PING_PONG(n) BIT((n) + 8) +#defineMASK_0_IMAGE_COMPOSITE_DONE_n(n)BIT((n) + 25) +#defineMASK_0_RESET_ACKBIT(31) + +#define VFE_IRQ_MASK_1 (0x060) +#defineMASK_1_CAMIF_ERROR BIT(0) +#defineMASK_1_VIOLATIONBIT(7) +#defineMASK_1_BUS_BDG_HALT_ACK BIT(8) +#defineMASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n) BIT((n) + 9) +#defineMASK_1_RDIn_SOF(n) BIT((n) + 29) + +#define VFE_IRQ_CLEAR_0(0x064) +#define VFE_IRQ_CLEAR_1(0x068) + +#define VFE_IRQ_STATUS_0 (0x06c) +#defineSTATUS_0_CAMIF_SOF BIT(0) +#defineSTATUS_0_RDIn_REG_UPDATE(n) BIT((n) + 5) +#define
Re: [GIT PULL] immutable branch for amba changes targeting v5.12-rc1
On Fri, Feb 05, 2021 at 11:18:17AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> > Hello Russell, hello Greg,
> >
> > On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin
> > > wrote:
> > > > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux
> > > > > admin wrote:
> > > > > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > > > > > I'm glad to take this through my char/misc tree, as that's where
> > > > > > > the
> > > > > > > other coresight changes flow through. So if no one else objects,
> > > > > > > I will
> > > > > > > do so...
> > > > > >
> > > > > > Greg, did you end up pulling this after all? If not, Uwe produced a
> > > > > > v2.
> > > > > > I haven't merged v2 yet as I don't know what you've done.
> > > > >
> > > > > I thought you merged this?
> > > >
> > > > I took v1, and put it in a branch I've promised in the past not to
> > > > rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch
> > > > on top.
> > > >
> > > > The only reason to produce an "immutable" branch is if it's the basis
> > > > for some dependent work and you need that branch merged into other
> > > > people's trees... so the whole "lets produce a v2" is really odd
> > > > workflow... I'm confused about what I should do, and who has to be
> > > > informed which option I take.
> > > >
> > > > I'm rather lost here too.
> > >
> > > Sorry to have cause this confusion. After I saw that my initial tag
> > > missed to adapt a driver I wanted to make it easy for you to fix the
> > > situation.
> > > So I created a patch to fix it and created a second tag with the patch
> > > squashed in. Obviously only one of them have to be picked and I hoped
> > > you (= Russell + Greg) would agree which option to pick.
> > >
> > > My preference would be if you both pick up v2 of the tag to yield a
> > > history that is bisectable without build problems, but if Russell (who
> > > already picked up the broken tag) considers his tree immutable and so
> > > isn't willing to rebase, then picking up the patch is the way to go.
> >
> > OK, the current state is that Russell applied the patch fixing
> > drivers/mailbox/arm_mhuv2.c on top of merging my first tag.
> >
> > So the way forward now is that Greg pulls
> >
> > git://git.armlinux.org.uk/~rmk/linux-arm.git devel-stable
> >
> > which currently points to
> >
> > 860660fd829e ("ARM: 9055/1: mailbox: arm_mhuv2: make remove callback
> > return void")
> >
> > , into his tree that contains the hwtracing changes that conflict with my
> > changes. @Greg: Is this good enough, or do you require a dedicated tag
> > to pull that?
> >
> > I think these conflicting hwtracing changes are not yet in any of Greg's
> > trees (at least they are not in next).
> >
> > When I pull
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next
> >
> > (currently pointing to 4e73ff249184 ("coresight: etm4x: Handle accesses
> > to TRCSTALLCTLR")) into 860660fd829e, I get a conflict in
> > drivers/hwtracing/coresight/coresight-etm4x-core.c as expected. My
> > resolution looks as follows:
>
> Ok, my resolution looked a bit different.
>
> Can you pull my char-misc-testing branch and verify I got this all
> pulled in correctly?
minor side-note: mentioning the repo url would have simplified that test.
I looked at
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-testing
commit 0573d3fa48640f0fa6b105ff92dcb02b94d6c1ab now.
I didn't compile test, but I'm willing to bet your resolution is wrong.
You have no return statement in etm4_remove_dev() but its return type is
int and etm4_remove_amba() still returns int but should return void.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[PATCH 3/5] clk: rockchip: add clock id for SCLK_VIP_OUT on rk3368
From: Heiko Stuebner Needed to provide clocks for cameras. Signed-off-by: Heiko Stuebner --- include/dt-bindings/clock/rk3368-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3368-cru.h b/include/dt-bindings/clock/rk3368-cru.h index f89683295935..83c72a163fd3 100644 --- a/include/dt-bindings/clock/rk3368-cru.h +++ b/include/dt-bindings/clock/rk3368-cru.h @@ -78,6 +78,7 @@ #define SCLK_TIMER13 136 #define SCLK_TIMER14 137 #define SCLK_TIMER15 138 +#define SCLK_VIP_OUT 139 #define DCLK_VOP 190 #define MCLK_CRYPTO191 -- 2.29.2
[PATCH 4/5] clk: rockchip: use clock id for SCLK_VIP_OUT on rk3368
From: Heiko Stuebner
Export the vip-out clock via the newly added clock-id.
Signed-off-by: Heiko Stuebner
---
drivers/clk/rockchip/clk-rk3368.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3368.c
b/drivers/clk/rockchip/clk-rk3368.c
index 76fb04120089..61413be48d1a 100644
--- a/drivers/clk/rockchip/clk-rk3368.c
+++ b/drivers/clk/rockchip/clk-rk3368.c
@@ -474,7 +474,7 @@ static struct rockchip_clk_branch rk3368_clk_branches[]
__initdata = {
COMPOSITE_NODIV(0, "vip_src", mux_pll_src_cpll_gpll_p, 0,
RK3368_CLKSEL_CON(21), 15, 1, MFLAGS,
RK3368_CLKGATE_CON(4), 5, GFLAGS),
- COMPOSITE_NOGATE(0, "sclk_vip_out", mux_vip_out_p, 0,
+ COMPOSITE_NOGATE(SCLK_VIP_OUT, "sclk_vip_out", mux_vip_out_p, 0,
RK3368_CLKSEL_CON(21), 14, 1, MFLAGS, 8, 5, DFLAGS),
COMPOSITE_NODIV(SCLK_EDP_24M, "sclk_edp_24m", mux_edp_24m_p, 0,
--
2.29.2
[PATCH 1/5] clk: rockchip: add clock ids for PCLK_DPHYRX and PCLK_DPHYTX0 on rk3368
From: Heiko Stuebner Needed by the mipi dphys. The naming follows the clock names in the manual. Signed-off-by: Heiko Stuebner --- include/dt-bindings/clock/rk3368-cru.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dt-bindings/clock/rk3368-cru.h b/include/dt-bindings/clock/rk3368-cru.h index 0a06c5f514d7..f89683295935 100644 --- a/include/dt-bindings/clock/rk3368-cru.h +++ b/include/dt-bindings/clock/rk3368-cru.h @@ -148,6 +148,8 @@ #define PCLK_VIP 367 #define PCLK_WDT 368 #define PCLK_EFUSE256 369 +#define PCLK_DPHYRX370 +#define PCLK_DPHYTX0 371 /* hclk gates */ #define HCLK_SFC 448 -- 2.29.2
[PATCH v3 2/2] dma-mapping: benchmark: pretend DMA is transmitting
In a real dma mapping user case, after dma_map is done, data will be
transmit. Thus, in multi-threaded user scenario, IOMMU contention
should not be that severe. For example, if users enable multiple
threads to send network packets through 1G/10G/100Gbps NIC, usually
the steps will be: map -> transmission -> unmap. Transmission delay
reduces the contention of IOMMU.
Here a delay is added to simulate the transmission between map and unmap
so that the tested result could be more accurate for TX and simple RX.
A typical TX transmission for NIC would be like: map -> TX -> unmap
since the socket buffers come from OS. Simple RX model eg. disk driver,
is also map -> RX -> unmap, but real RX model in a NIC could be more
complicated considering packets can come spontaneously and many drivers
are using pre-mapped buffers pool. This is in the TBD list.
Signed-off-by: Barry Song
---
kernel/dma/map_benchmark.c| 12 ++-
.../testing/selftests/dma/dma_map_benchmark.c | 21 ---
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c
index da95df381483..e0e64f8b0739 100644
--- a/kernel/dma/map_benchmark.c
+++ b/kernel/dma/map_benchmark.c
@@ -21,6 +21,7 @@
#define DMA_MAP_BENCHMARK _IOWR('d', 1, struct map_benchmark)
#define DMA_MAP_MAX_THREADS1024
#define DMA_MAP_MAX_SECONDS300
+#define DMA_MAP_MAX_TRANS_DELAY(10 * NSEC_PER_MSEC)
#define DMA_MAP_BIDIRECTIONAL 0
#define DMA_MAP_TO_DEVICE 1
@@ -36,7 +37,8 @@ struct map_benchmark {
__s32 node; /* which numa node this benchmark will run on */
__u32 dma_bits; /* DMA addressing capability */
__u32 dma_dir; /* DMA data direction */
- __u8 expansion[84]; /* For future use */
+ __u32 dma_trans_ns; /* time for DMA transmission in ns */
+ __u8 expansion[80]; /* For future use */
};
struct map_benchmark_data {
@@ -87,6 +89,9 @@ static int map_benchmark_thread(void *data)
map_etime = ktime_get();
map_delta = ktime_sub(map_etime, map_stime);
+ /* Pretend DMA is transmitting */
+ ndelay(map->bparam.dma_trans_ns);
+
unmap_stime = ktime_get();
dma_unmap_single(map->dev, dma_addr, PAGE_SIZE, map->dir);
unmap_etime = ktime_get();
@@ -218,6 +223,11 @@ static long map_benchmark_ioctl(struct file *file,
unsigned int cmd,
return -EINVAL;
}
+ if (map->bparam.dma_trans_ns > DMA_MAP_MAX_TRANS_DELAY) {
+ pr_err("invalid transmission delay\n");
+ return -EINVAL;
+ }
+
if (map->bparam.node != NUMA_NO_NODE &&
!node_possible(map->bparam.node)) {
pr_err("invalid numa node\n");
diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c
b/tools/testing/selftests/dma/dma_map_benchmark.c
index 537d65968c48..fb23ce9617ea 100644
--- a/tools/testing/selftests/dma/dma_map_benchmark.c
+++ b/tools/testing/selftests/dma/dma_map_benchmark.c
@@ -12,9 +12,12 @@
#include
#include
+#define NSEC_PER_MSEC 100L
+
#define DMA_MAP_BENCHMARK _IOWR('d', 1, struct map_benchmark)
#define DMA_MAP_MAX_THREADS1024
#define DMA_MAP_MAX_SECONDS 300
+#define DMA_MAP_MAX_TRANS_DELAY(10 * NSEC_PER_MSEC)
#define DMA_MAP_BIDIRECTIONAL 0
#define DMA_MAP_TO_DEVICE 1
@@ -36,7 +39,8 @@ struct map_benchmark {
__s32 node; /* which numa node this benchmark will run on */
__u32 dma_bits; /* DMA addressing capability */
__u32 dma_dir; /* DMA data direction */
- __u8 expansion[84]; /* For future use */
+ __u32 dma_trans_ns; /* time for DMA transmission in ns */
+ __u8 expansion[80]; /* For future use */
};
int main(int argc, char **argv)
@@ -46,12 +50,12 @@ int main(int argc, char **argv)
/* default single thread, run 20 seconds on NUMA_NO_NODE */
int threads = 1, seconds = 20, node = -1;
/* default dma mask 32bit, bidirectional DMA */
- int bits = 32, dir = DMA_MAP_BIDIRECTIONAL;
+ int bits = 32, xdelay = 0, dir = DMA_MAP_BIDIRECTIONAL;
int cmd = DMA_MAP_BENCHMARK;
char *p;
- while ((opt = getopt(argc, argv, "t:s:n:b:d:")) != -1) {
+ while ((opt = getopt(argc, argv, "t:s:n:b:d:x:")) != -1) {
switch (opt) {
case 't':
threads = atoi(optarg);
@@ -68,6 +72,9 @@ int main(int argc, char **argv)
case 'd':
dir = atoi(optarg);
break;
+ case 'x':
+ xdelay = atoi(optarg);
+ break;
default:
return -1;
}
@@ -85,6 +92,12 @@ int main(int argc, char **argv)
exit(1);
}
Re: [PATCH 05/24] perf daemon: Add client socket support
On Sun, Jan 31, 2021 at 8:49 AM Jiri Olsa wrote:
>
> Adding support for client socket side that will be used
> to send commands to daemon server socket.
>
> This patch adds only the core support, all commands using
> this functionality are coming in following patches.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/builtin-daemon.c | 105
> 1 file changed, 105 insertions(+)
>
> diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
> index 756d60616d7d..eada3ceb9b0c 100644
> --- a/tools/perf/builtin-daemon.c
> +++ b/tools/perf/builtin-daemon.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "builtin.h"
> #include "perf.h"
> @@ -42,6 +43,50 @@ static void sig_handler(int sig __maybe_unused)
> done = true;
> }
>
> +static int client_config(const char *var, const char *value, void *cb)
> +{
> + struct daemon *daemon = cb;
> +
> + if (!strcmp(var, "daemon.base") && !daemon->base_user) {
> + daemon->base = strdup(value);
> + if (!daemon->base)
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static int check_base(struct daemon *daemon)
> +{
> + struct stat st;
> +
> + if (!daemon->base) {
> + pr_err("failed: base not defined\n");
> + return -EINVAL;
> + }
> +
> + if (stat(daemon->base, )) {
> + pr_err("failed: base '%s' does not exists\n", daemon->base);
Well, it could be a permission error or something..
> + return -EINVAL;
> + }
You may also check whether it's a directory.
> +
> + return 0;
> +}
> +
> +static int setup_client_config(struct daemon *daemon)
> +{
> + struct perf_config_set *set;
> + int err = -ENOMEM;
> +
> + set = perf_config_set__load_file(daemon->config_real);
> + if (set) {
> + err = perf_config_set(set, client_config, daemon);
> + perf_config_set__delete(set);
> + }
> +
> + return err ?: check_base(daemon);
> +}
> +
> static int setup_server_socket(struct daemon *daemon)
> {
> struct sockaddr_un addr;
> @@ -114,6 +159,32 @@ static int handle_server_socket(struct daemon *daemon
> __maybe_unused, int sock_f
> return ret;
> }
>
> +static int setup_client_socket(struct daemon *daemon)
> +{
> + struct sockaddr_un addr;
> + char path[100];
> + int fd;
> +
> + fd = socket(AF_UNIX, SOCK_STREAM, 0);
> + if (fd == -1) {
> + perror("failed: socket");
> + return -1;
> + }
> +
> + scnprintf(path, PATH_MAX, "%s/control", daemon->base);
Same as the previous patch. The path is 100 bytes..
Thanks,
Namhyung
> +
> + memset(, 0, sizeof(addr));
> + addr.sun_family = AF_UNIX;
> + strncpy(addr.sun_path, path, sizeof(addr.sun_path) - 1);
> +
> + if (connect(fd, (struct sockaddr *) , sizeof(addr)) == -1) {
> + perror("failed: connect");
> + return -1;
> + }
> +
> + return fd;
> +}
[PATCH v3 1/8] dt-bindings: usb: convert rockchip,dwc3.txt to yaml
In the past Rockchip dwc3 usb nodes were manually checked.
With the conversion of snps,dwc3.yaml as common document
we now can convert rockchip,dwc3.txt to yaml as well.
Remove node wrapper.
Added properties for rk3399 are:
power-domains
resets
reset-names
Signed-off-by: Johan Jonker
---
Changed V3:
remove aclk_usb3_rksoc_axi_perf
remove aclk_usb3
Changed V2:
remove node wrapper
---
.../devicetree/bindings/usb/rockchip,dwc3.txt | 56 -
.../devicetree/bindings/usb/rockchip,dwc3.yaml | 95 ++
2 files changed, 95 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
deleted file mode 100644
index 945204932..0
--- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Rockchip SuperSpeed DWC3 USB SoC controller
-
-Required properties:
-- compatible: should contain "rockchip,rk3399-dwc3" for rk3399 SoC
-- clocks: A list of phandle + clock-specifier pairs for the
- clocks listed in clock-names
-- clock-names: Should contain the following:
- "ref_clk"Controller reference clk, have to be 24 MHz
- "suspend_clk"Controller suspend clk, have to be 24 MHz or 32 KHz
- "bus_clk"Master/Core clock, have to be >= 62.5 MHz for SS
- operation and >= 30MHz for HS operation
- "grf_clk"Controller grf clk
-
-Required child node:
-A child node must exist to represent the core DWC3 IP block. The name of
-the node is not important. The content of the node is defined in dwc3.txt.
-
-Phy documentation is provided in the following places:
-Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml - USB2.0 PHY
-Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt - Type-C PHY
-
-Example device nodes:
-
- usbdrd3_0: usb@fe80 {
- compatible = "rockchip,rk3399-dwc3";
- clocks = < SCLK_USB3OTG0_REF>, < SCLK_USB3OTG0_SUSPEND>,
-< ACLK_USB3OTG0>, < ACLK_USB3_GRF>;
- clock-names = "ref_clk", "suspend_clk",
- "bus_clk", "grf_clk";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- usbdrd_dwc3_0: dwc3@fe80 {
- compatible = "snps,dwc3";
- reg = <0x0 0xfe80 0x0 0x10>;
- interrupts = ;
- dr_mode = "otg";
- };
- };
-
- usbdrd3_1: usb@fe90 {
- compatible = "rockchip,rk3399-dwc3";
- clocks = < SCLK_USB3OTG1_REF>, < SCLK_USB3OTG1_SUSPEND>,
-< ACLK_USB3OTG1>, < ACLK_USB3_GRF>;
- clock-names = "ref_clk", "suspend_clk",
- "bus_clk", "grf_clk";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- usbdrd_dwc3_1: dwc3@fe90 {
- compatible = "snps,dwc3";
- reg = <0x0 0xfe90 0x0 0x10>;
- interrupts = ;
- dr_mode = "otg";
- };
- };
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
new file mode 100644
index 0..d815aacfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/rockchip,dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Heiko Stuebner
+
+description:
+ The common content of the node is defined in snps,dwc3.yaml.
+
+ Phy documentation is provided in the following places.
+
+ USB2.0 PHY
+ Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
+
+ Type-C PHY
+ Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+
+allOf:
+ - $ref: snps,dwc3.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - rockchip,rk3399-dwc3
+ - const: snps,dwc3
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description:
+ Controller reference clock, must to be 24 MHz
+ - description:
+ Controller suspend clock, must to be 24 MHz or 32 KHz
+ - description:
+ Master/Core clock, must to be >= 62.5 MHz for SS
+ operation and >= 30MHz for HS operation
+ - description:
+ Controller grf clock
+
+ clock-names:
+items:
+ - const: ref_clk
+ - const: suspend_clk
+ - const: bus_clk
+ - const: grf_clk
+
+
[PATCH v3 2/8] arm64: dts: rockchip: optimize clks for rk3399 dwc3
From: Wu Liang feng Remove unnecessary clocks, refer to rk3399 TRM, aclk_usb3 is the parent of aclk_usb3otg0/1 and aclk_usb3_grf, and we will enable aclk_usb3otg0/1 and aclk_usb3_grf, so don't need to enable aclk_usb3 again. In addition, the aclk_usb3_rksoc_axi_perf clk is used for usb3 performance monitor module which we don't use now, so don't need to enable it. Signed-off-by: Wu Liang feng Signed-off-by: Johan Jonker --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 04f7cc5c3..b125cac89 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -399,11 +399,9 @@ #size-cells = <2>; ranges; clocks = < SCLK_USB3OTG0_REF>, < SCLK_USB3OTG0_SUSPEND>, -< ACLK_USB3OTG0>, < ACLK_USB3_RKSOC_AXI_PERF>, -< ACLK_USB3>, < ACLK_USB3_GRF>; +< ACLK_USB3OTG0>, < ACLK_USB3_GRF>; clock-names = "ref_clk", "suspend_clk", - "bus_clk", "aclk_usb3_rksoc_axi_perf", - "aclk_usb3", "grf_clk"; + "bus_clk", "grf_clk"; resets = < SRST_A_USB3_OTG0>; reset-names = "usb3-otg"; status = "disabled"; @@ -435,11 +433,9 @@ #size-cells = <2>; ranges; clocks = < SCLK_USB3OTG1_REF>, < SCLK_USB3OTG1_SUSPEND>, -< ACLK_USB3OTG1>, < ACLK_USB3_RKSOC_AXI_PERF>, -< ACLK_USB3>, < ACLK_USB3_GRF>; +< ACLK_USB3OTG1>, < ACLK_USB3_GRF>; clock-names = "ref_clk", "suspend_clk", - "bus_clk", "aclk_usb3_rksoc_axi_perf", - "aclk_usb3", "grf_clk"; + "bus_clk", "grf_clk"; resets = < SRST_A_USB3_OTG1>; reset-names = "usb3-otg"; status = "disabled"; -- 2.11.0
[PATCH v3 3/8] arm64: dts: rockchip: restyle rk3399 usbdrd3_0 node
For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
so restyle the rk3399 usbdrd3_0 node before more new SoC types are
added with the same IP.
Signed-off-by: Johan Jonker
---
Changed V3:
remove aclk_usb3_rksoc_axi_perf
remove aclk_usb3
---
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts| 6 +---
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 6 +---
.../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 4 ---
arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts | 6 +---
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 4 ---
.../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 4 ---
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi| 4 ---
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-rock960.dts| 2 +-
arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 4 ---
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 37 --
.../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi | 4 ---
18 files changed, 24 insertions(+), 95 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 1ce85a581..95110d065 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -153,7 +153,7 @@
status = "okay";
};
-_dwc3_0 {
+_0 {
dr_mode = "host";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 6db18808b..4017b0e8c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -773,12 +773,8 @@
};
_0 {
- status = "okay";
-};
-
-_dwc3_0 {
- status = "okay";
dr_mode = "otg";
+ status = "okay";
};
_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 32dcaf210..e42783cb7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -618,13 +618,9 @@ ap_i2c_audio: {
};
_0 {
- status = "okay";
+ dr_mode = "host";
extcon = <_extcon0>;
-};
-
-_dwc3_0 {
status = "okay";
- dr_mode = "host";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
index 341d074ed..daf14f732 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
@@ -731,12 +731,8 @@
};
_0 {
- status = "okay";
-};
-
-_dwc3_0 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
index 635afdd99..d028285fb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
@@ -797,12 +797,8 @@
};
_0 {
- status = "okay";
-};
-
-_dwc3_0 {
- status = "okay";
dr_mode = "otg";
+ status = "okay";
};
_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
index 1fa80ac15..1c0b48a71 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -611,12 +611,8 @@
};
_0 {
- status = "okay";
-};
-
-_dwc3_0 {
- status = "okay";
dr_mode = "otg";
+ status = "okay";
};
_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a9..90a6ea1d7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -715,10 +715,6 @@
status = "okay";
};
-_dwc3_0 {
- status = "okay";
-};
-
_dwc3_1 {
dr_mode = "host";
status = "okay";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
index ad7c4d008..7b633622c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
@@ -854,12 +854,8 @@
};
_0 {
- status = "okay";
-};
-
-_dwc3_0 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index 219b7507a..f00e11075 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++
[PATCH v3 4/8] arm64: dts: rockchip: restyle rk3399 usbdrd3_1 node
For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
so restyle the rk3399 usbdrd3_1 node before more new SoC types are
added with the same IP.
Signed-off-by: Johan Jonker
---
Changed V3:
remove aclk_usb3_rksoc_axi_perf
remove aclk_usb3
---
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts| 6 +---
.../boot/dts/rockchip/rk3399-gru-chromebook.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 6 +---
.../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 4 ---
arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts | 6 +---
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 4 ---
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi| 6 +---
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-rock960.dts| 2 +-
arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 4 ---
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 6 +---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 37 --
17 files changed, 26 insertions(+), 93 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 95110d065..4392780db 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -157,7 +157,7 @@
dr_mode = "host";
};
-_dwc3_1 {
+_1 {
dr_mode = "host";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 4017b0e8c..28e5895de 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -778,12 +778,8 @@
};
_1 {
- status = "okay";
-};
-
-_dwc3_1 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index 1384dabbd..c996c688d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -351,13 +351,9 @@ ap_i2c_tp: {
};
_1 {
- status = "okay";
+ dr_mode = "host";
extcon = <_extcon1>;
-};
-
-_dwc3_1 {
status = "okay";
- dr_mode = "host";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
index daf14f732..397050703 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
@@ -736,12 +736,8 @@
};
_1 {
- status = "okay";
-};
-
-_dwc3_1 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
index d028285fb..30e6e3e41 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
@@ -802,12 +802,8 @@
};
_1 {
- status = "okay";
-};
-
-_dwc3_1 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
index 1c0b48a71..a7092fda3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -616,12 +616,8 @@
};
_1 {
- status = "okay";
-};
-
-_dwc3_1 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 90a6ea1d7..1e835a682 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -712,10 +712,6 @@
};
_1 {
- status = "okay";
-};
-
-_dwc3_1 {
dr_mode = "host";
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
index 7b633622c..fdc027ff3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
@@ -859,12 +859,8 @@
};
_1 {
- status = "okay";
-};
-
-_dwc3_1 {
- status = "okay";
dr_mode = "host";
+ status = "okay";
};
{
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index f00e11075..80ac8ab6a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++
Re: [PATCH v6 0/7] common SVDM version and VDO from dt
On 2/5/21 3:42 AM, Heikki Krogerus wrote: [ ... ] >> Kyle Tso (7): >> usb: typec: Manage SVDM version >> usb: pd: Make SVDM Version configurable in VDM header >> usb: typec: tcpm: Determine common SVDM Version >> usb: typec: ucsi: Determine common SVDM Version >> usb: typec: displayport: Fill the negotiated SVDM Version in the header >> dt-bindings: connector: Add SVDM VDO properties >> usb: typec: tcpm: Get Sink VDO from fwnode > > These are OK by me, but I think it would be great if Guenter could > give them the once-over, as usual. I hope he has time. FWIW, for all I'll try my best, but I'll need a couple of days. Guenter
Re: [External] Re: [PATCH] mm: memcontrol: fix missing wakeup oom task
On Fri 05-02-21 19:04:19, Muchun Song wrote: > On Fri, Feb 5, 2021 at 6:21 PM Michal Hocko wrote: > > > > On Fri 05-02-21 17:55:10, Muchun Song wrote: > > > On Fri, Feb 5, 2021 at 4:24 PM Michal Hocko wrote: > > > > > > > > On Fri 05-02-21 14:23:10, Muchun Song wrote: > > > > > We call memcg_oom_recover() in the uncharge_batch() to wakeup OOM task > > > > > when page uncharged, but for the slab pages, we do not do this when > > > > > page > > > > > uncharged. > > > > > > > > How does the patch deal with this? > > > > > > When we uncharge a slab page via __memcg_kmem_uncharge, > > > actually, this path forgets to do this for us compared to > > > uncharge_batch(). Right? > > > > Yes this was more more or less clear (still would have been nicer to be > > explicit). But you still haven't replied to my question I believe. I > > assume you rely on refill_stock doing draining but how does this address > > the problem? Is it sufficient to do wakeups in the batched way? > > Sorry, the subject title may not be suitable. IIUC, memcg_oom_recover > aims to wake up the OOM task when we uncharge the page. Yes, your understanding is correct. This is a way to pro-actively wake up oom victims when the memcg oom handling is outsourced to the userspace. Please note that I haven't objected to the problem statement. I was questioning the fix for the problem. > I see uncharge_batch always do this. I am confused why > __memcg_kmem_uncharge does not. Very likely an omission. I haven't checked closely but I suspect this has been introduced by the recent kmem accounting changes. Why didn't you simply do the same thing and call memcg_oom_recover unconditionally and instead depend on the draining? I suspect this was because you wanted to recover also when draining which is not necessary as pointed out in other email. [...] > > > > Does this lead to any code generation improvements? I would expect > > > > compiler to be clever enough to inline static functions if that pays > > > > off. If yes make this a patch on its own. > > > > > > I have disassembled the code, I see memcg_oom_recover is not > > > inline. Maybe because memcg_oom_recover has a lot of callers. > > > Just guess. > > > > > > (gdb) disassemble uncharge_batch > > > [...] > > > 0x81341c73 <+227>: callq 0x8133c420 > > > > > > 0x81341c78 <+232>: jmpq 0x81341bc0 > > > 0x81341c7d <+237>: callq 0x8133e2c0 > > > > So does it really help to do the inlining? > > I just think memcg_oom_recover is very small, inline maybe > a good choice. Maybe I am wrong. In general I am not overly keen on changes without a proper justification. In this particular case I would understand that a function call that will almost never do anything but the test (because oom_disabled is a rarely used) is just waste of cycles in some hot paths (e.g. kmem uncharge). Maybe this even has some visible performance benefit. If this is really the case then would it make sense to guard this test by the existing cgroup_subsys_on_dfl(memory_cgrp_subsys)? -- Michal Hocko SUSE Labs
Re: [PATCH v2 2/2] s390/kvm: VSIE: correctly handle MVPG when in VSIE
On Thu, 4 Feb 2021 18:10:01 +0100
Janosch Frank wrote:
> On 2/2/21 7:00 PM, Claudio Imbrenda wrote:
> > Correctly handle the MVPG instruction when issued by a VSIE guest.
> >
> > Fixes: a3508fbe9dc6d ("KVM: s390: vsie: initial support for nested
> > virtualization") Cc: sta...@vger.kernel.org
> > Signed-off-by: Claudio Imbrenda
>
> So far the patch looks ok to me and way better to understand than v1,
> good job
>
> > ---
> > arch/s390/kvm/vsie.c | 94
> > +--- 1 file changed, 89
> > insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> > index 7db022141db3..2db49749e27b 100644
> > --- a/arch/s390/kvm/vsie.c
> > +++ b/arch/s390/kvm/vsie.c
> > @@ -416,11 +416,6 @@ static void unshadow_scb(struct kvm_vcpu
> > *vcpu, struct vsie_page *vsie_page) memcpy((void *)((u64)scb_o +
> > 0xc0), (void *)((u64)scb_s + 0xc0), 0xf0 - 0xc0);
>
> Magic offsets being magic
> Another item for my todo list.
>
> > break;
> > - case ICPT_PARTEXEC:
> > - /* MVPG only */
> > - memcpy((void *)((u64)scb_o + 0xc0),
> > - (void *)((u64)scb_s + 0xc0), 0xd0 - 0xc0);
> > - break;
> > }
> >
> > if (scb_s->ihcpu != 0xU)
> > @@ -982,6 +977,91 @@ static int handle_stfle(struct kvm_vcpu *vcpu,
> > struct vsie_page *vsie_page) return 0;
> > }
> >
> > +static u64 vsie_get_register(struct kvm_vcpu *vcpu, struct
> > vsie_page *vsie_page, u8 reg) +{
> > + reg &= 0xf;
> > + switch (reg) {
> > + case 15:
> > + return vsie_page->scb_s.gg15;
> > + case 14:
> > + return vsie_page->scb_s.gg14;
> > + default:
> > + return vcpu->run->s.regs.gprs[reg];
> > + }
> > +}
> > +
> > +static int vsie_handle_mvpg(struct kvm_vcpu *vcpu, struct
> > vsie_page *vsie_page) +{
> > + struct kvm_s390_sie_block *scb_s = _page->scb_s;
> > + unsigned long pei1, pei2, src, dest, mask = PAGE_MASK;
> > + u64 *pei_block = _page->scb_o->mcic;
> > + int edat, rc1, rc2;
>
> Can use a src/dst prefix or suffix please?
> 1/2 is confusing.
will do
> > + union ctlreg0 cr0;
> > +
> > + cr0.val = vcpu->arch.sie_block->gcr[0];
> > + edat = cr0.edat && test_kvm_facility(vcpu->kvm, 8);
> > + if (psw_bits(scb_s->gpsw).eaba == PSW_BITS_AMODE_24BIT)
> > + mask = 0xfff000;
> > + else if (psw_bits(scb_s->gpsw).eaba ==
> > PSW_BITS_AMODE_31BIT)
> > + mask = 0x7000;
> > +
> > + dest = vsie_get_register(vcpu, vsie_page, scb_s->ipb >>
> > 16) & mask;
> > + src = vsie_get_register(vcpu, vsie_page, scb_s->ipb >> 20)
> > & mask; +
> > + rc1 = kvm_s390_shadow_fault(vcpu, vsie_page->gmap, dest,
> > );
> > + rc2 = kvm_s390_shadow_fault(vcpu, vsie_page->gmap, src,
> > );
> > + /*
> > +* Either everything went well, or something non-critical
> > went wrong
> > +* e.g. beause of a race. In either case, simply retry.
> > +*/
> > + if (rc1 == -EAGAIN || rc2 == -EAGAIN || (!rc1 && !rc2)) {
> > + retry_vsie_icpt(vsie_page);
> > + return -EAGAIN;
> > + }
> > + /* Something more serious went wrong, propagate the error
> > */
> > + if (rc1 < 0)
> > + return rc1;
> > + if (rc2 < 0)
> > + return rc2;
> > +
> > + /* The only possible suppressing exception: just deliver
> > it */
> > + if (rc1 == PGM_TRANSLATION_SPEC || rc2 ==
> > PGM_TRANSLATION_SPEC) {
> > + clear_vsie_icpt(vsie_page);
> > + rc1 = kvm_s390_inject_program_int(vcpu,
> > PGM_TRANSLATION_SPEC);
> > + WARN_ON_ONCE(rc1);
> > + return 1;
> > + }
> > +
> > + /*
> > +* Forward the PEI intercept to the guest if it was a page
> > fault, or
> > +* also for segment and region table faults if EDAT
> > applies.
> > +*/
> > + if (edat) {
> > + rc1 = rc1 == PGM_ASCE_TYPE ? rc1 : 0;
> > + rc2 = rc2 == PGM_ASCE_TYPE ? rc2 : 0;
> > + }
> > + if ((!rc1 || rc1 == PGM_PAGE_TRANSLATION) && (!rc2 || rc2
> > == PGM_PAGE_TRANSLATION)) {
> > + pei_block[0] = pei1;
> > + pei_block[1] = pei2;
> > + return 1;
> > + }
> > +
> > + retry_vsie_icpt(vsie_page);
> > +
> > + /*
> > +* The host has edat, and the guest does not, or it was an
> > ASCE type
> > +* exception. The host needs to inject the appropriate DAT
> > interrupts
> > +* into the guest.
> > +*/
> > + if (rc1)
> > + return inject_fault(vcpu, rc1, dest, 1);
> > + if (rc2)> + return inject_fault(vcpu, rc2,
> > src, 0); +
> > + /* This should never be reached */
>
> BUG()?
look at the code, if it's reached, it's a bug in the compiler :)
maybe I should rewrite it so that there won't be any unreachable code at
all
> > + return 0;
> > +}
> > +
> > /*
> > * Run the vsie on a shadow scb and a shadow gmap, without any
> > further
> > * sanity checks, handling SIE faults.
> > @@ -1068,6 +1148,10 @@ static int do_vsie_run(struct
Re: [RFC][PATCH 2/2] x86: add extra serialization for non-serializing MSRs
On Fri, Feb 05, 2021 at 11:02:10AM +0100, Peter Zijlstra wrote: > And presumably it is still allowed to do that when we write it like: > > mov $1, ([x]) > mfence > wrmsr > > because, mfence only has dependencies to memops and (fast) wrmsr is not > a memop. > > Which then brings us to: > > mov $1, ([x]) > mfence > lfence > wrmsr > > In this case, the lfence acts like the newly minted ifence (see > spectre), and will block execution of (any) later instructions until > completion of all prior instructions. This, and only this ensures the > wrmsr happens after the mfence, which in turn ensures the store to x is > globally visible. Note that I too do have a few questions. Supposedly MFENCE is our LOAD/STORE completion fence of choice, and this obviously works with MMIO, since that's memops. The MMIO write of the buffer address to the DMA device must happen after completion of the previous data writes etc.. But what about the legacy IN/OUT ports? Are those memops? If not, we might need additional LFENCEs there too. Also, would SFENCE+LFENCE be sufficient for the WRMSR case? AFAIU SFENCE is the store completion barrier and should be strong enough to flush all store buffers. If not, why not?
[PATCH] fs: notify: inotify: Replace a common bad word with better common word
s/fucked/messed/
Signed-off-by: Bhaskar Chowdhury
---
fs/notify/inotify/inotify_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 59c177011a0f..0a9d1a81edf0 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -455,7 +455,7 @@ static void inotify_remove_from_idr(struct fsnotify_group
*group,
/*
* We found an mark in the idr at the right wd, but it's
* not the mark we were told to remove. eparis seriously
-* fucked up somewhere.
+* messed up somewhere.
*/
if (unlikely(found_i_mark != i_mark)) {
WARN_ONCE(1, "%s: i_mark=%p i_mark->wd=%d i_mark->group=%p "
--
2.30.0
Re: [PATCH net-next 7/7] net: marvell: prestera: fix port event handling on init
Hi Jakub,
On Thu, Feb 04, 2021 at 09:19:34PM -0800, Jakub Kicinski wrote:
> On Wed, 3 Feb 2021 18:54:58 +0200 Vadym Kochan wrote:
> > For some reason there might be a crash during ports creation if port
> > events are handling at the same time because fw may send initial
> > port event with down state.
> >
> > The crash points to cancel_delayed_work() which is called when port went
> > is down. Currently I did not find out the real cause of the issue, so
> > fixed it by cancel port stats work only if previous port's state was up
> > & runnig.
>
> Maybe you just need to move the DELAYED_WORK_INIT() earlier?
> Not sure why it's at the end of prestera_port_create(), it
> just initializes some fields.
>
Thanks for suggestion, but it does not help. Will try to find-out the
real root cause but this is the only fix I 'v came up.
> > [ 28.489791] Call trace:
> > [ 28.492259] get_work_pool+0x48/0x60
> > [ 28.495874] cancel_delayed_work+0x38/0xb0
> > [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera]
> > [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera]
> > [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci]
> > [ 28.516660] process_one_work+0x1e8/0x360
> > [ 28.520710] worker_thread+0x44/0x480
> > [ 28.524412] kthread+0x154/0x160
> > [ 28.527670] ret_from_fork+0x10/0x38
> > [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020)
> > [ 28.537429] ---[ end trace 5eced933df3a080b ]---
> >
> > Signed-off-by: Vadym Kochan
> > ---
> > drivers/net/ethernet/marvell/prestera/prestera_main.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/prestera/prestera_main.c
> > b/drivers/net/ethernet/marvell/prestera/prestera_main.c
> > index 39465e65d09b..122324dae47d 100644
> > --- a/drivers/net/ethernet/marvell/prestera/prestera_main.c
> > +++ b/drivers/net/ethernet/marvell/prestera/prestera_main.c
> > @@ -433,7 +433,8 @@ static void prestera_port_handle_event(struct
> > prestera_switch *sw,
> > netif_carrier_on(port->dev);
> > if (!delayed_work_pending(caching_dw))
> > queue_delayed_work(prestera_wq, caching_dw, 0);
> > - } else {
> > + } else if (netif_running(port->dev) &&
> > + netif_carrier_ok(port->dev)) {
> > netif_carrier_off(port->dev);
> > if (delayed_work_pending(caching_dw))
> > cancel_delayed_work(caching_dw);
>
Re: [PATCH v4 3/3] drm/bridge: anx7625: add MIPI DPI input feature support
Hey Xin,
On Thu, 28 Jan 2021 at 04:12, Xin Ji wrote:
>
> Add MIPI rx DPI input support
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 326
> --
> drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +-
> 2 files changed, 285 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 04536cc..628ae43 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
> return anx7625_reg_write(ctx, client, offset, (val & (mask)));
> }
>
> -static int anx7625_write_and_or(struct anx7625_data *ctx,
> - struct i2c_client *client,
> - u8 offset, u8 and_mask, u8 or_mask)
> +static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
> {
> - int val;
> + int i, ret;
>
> - val = anx7625_reg_read(ctx, client, offset);
> - if (val < 0)
> - return val;
> + ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CONTROL_REGISTER, 0x80);
> + for (i = 0; i < 13; i++)
> + ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> +VIDEO_BIT_MATRIX_12 + i,
> +0x18 + i);
>
> - return anx7625_reg_write(ctx, client,
> -offset, (val & and_mask) | (or_mask));
> + return ret;
> }
>
> static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
> @@ -195,6 +195,60 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
> return 0;
> }
>
> +static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
> +u8 addrh, u8 addrm, u8 addrl,
> +u8 len, u8 *buf)
> +{
> + struct device *dev = >client->dev;
> + int ret;
> + u8 cmd;
> +
> + if (len > MAX_DPCD_BUFFER_SIZE) {
> + DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
> + return -EINVAL;
> + }
> +
> + cmd = ((len - 1) << 4) | 0x09;
> +
> + /* Set command and length */
> + ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> + AP_AUX_COMMAND, cmd);
> +
> + /* Set aux access address */
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_7_0, addrl);
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_15_8, addrm);
> + ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_19_16, addrh);
> +
> + /* Enable aux access */
> + ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
> + AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
> +
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
> + return -EIO;
> + }
> +
> + usleep_range(2000, 2100);
> +
> + ret = wait_aux_op_finish(ctx);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
> + return ret;
> + }
> +
> + ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_BUFF_START, len, buf);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "read dpcd register failed\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> static int anx7625_video_mute_control(struct anx7625_data *ctx,
> u8 status)
> {
> @@ -219,38 +273,6 @@ static int anx7625_video_mute_control(struct
> anx7625_data *ctx,
> return ret;
> }
>
> -static int anx7625_config_audio_input(struct anx7625_data *ctx)
> -{
> - struct device *dev = >client->dev;
> - int ret;
> -
> - /* Channel num */
> - ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
> -
> - /* FS */
> - ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_4,
> - 0xf0, AUDIO_FS_48K);
> - /* Word length */
> - ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_5,
> - 0xf0, AUDIO_W_LEN_24_24MAX);
> - /* I2S */
> - ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
> - ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
> -
Re: [PATCH v3 08/11] iio: buffer: wrap all buffer attributes into iio_dev_attr
On Fri, 5 Feb 2021 11:17:04 +0200 Alexandru Ardelean wrote: > On Thu, Feb 4, 2021 at 8:26 PM Jonathan Cameron > wrote: > > > > On Mon, 1 Feb 2021 16:51:02 +0200 > > Alexandru Ardelean wrote: > > > > > This change wraps all buffer attributes into iio_dev_attr objects, and > > > assigns a reference to the IIO buffer they belong to. > > > > > > With the addition of multiple IIO buffers per one IIO device, we need a > > > way > > > to know which IIO buffer is being enabled/disabled/controlled. > > > > > > We know that all buffer attributes are device_attributes. So we can wrap > > > them with a iio_dev_attr types. In the iio_dev_attr type, we can also hold > > > a reference to an IIO buffer. > > > So, we end up being able to allocate wrapped attributes for all buffer > > > attributes (even the one from other drivers). > > > > > > The neat part with this mechanism, is that we don't need to add any extra > > > cleanup, because these attributes are being added to a dynamic list that > > > will get cleaned up via iio_free_chan_devattr_list(). > > > > > > > > > > With this change, the 'buffer->scan_el_dev_attr_list' list is being > > > renamed > > > to 'buffer->buffer_attr_list', effectively merging (or finalizing the > > > merge) of the buffer/ & scan_elements/ attributes internally. > > > > > > Accessing these new buffer attributes can now be done via > > > 'to_iio_dev_attr(attr)->buffer' inside the show/store handlers. > > > > That is going to look a bit odd in any drivers that use it given they > > will appear to not be embedded. > > > > There seem to be very few such attributes from a quick grep, so maybe > > we may want to unwind this and change all the types. Might still need > > to set .buffer for some of them though (only applying to new drivers as > > clearly current ones don't care!) > > > > Looking at what they actually are, some perhaps shouldn't have been in the > > buffer > > directory in the first place (with hindsight!). > > > > Anyhow, aside from that oddity this looks good to me. > > I'm a little vague here. > If there is a suggestion for a change, I may have missed it. It was vague because I wasn't sure if it it made sense :) > > I'm a bit vague on the part of "we may want to unwind this and change > all the types" > Is it referring to something like this patch? > > https://lore.kernel.org/linux-iio/20210122162529.84978-10-alexandru.ardel...@analog.com/ Exactly, that was what I was wondering about. > We could do a show/store version that takes an iio_buf_attr or > iio_dev_attr parameter. > But maybe at a later point? > I don't feel it adds much benefit over the current usage of > buffer->attrs, because we need to kmalloc these iio_dev_attr anyways > to store the reference to the iio_buffer. > > I would have liked to get rid of these user/external buffer->attrs. > That would have made things easier. > > But, it looks like there are several drivers using them. > I usually find them by grepping for iio_triggered_buffer_setup_ext > It's only 5 drivers that provide these attributes. > It used to be a bit easier to find them by grepping > iio_buffer_set_attrs(), but I removed that. We could look at whether some can be brought into the core. They tend to be around hwfifo parameters. Those could be specific to individual buffers rather than device wide so at least some of them are correctly placed in the buffer directory (I think - I've argued with myself about this a few times in the past). The only oddity we'll get from current approach is callbacks appearing to access a container structure that they aren't associated with in the driver. Its the sort of interface that no one would ever realize was possible. Jonathan > > > > > > Jonathan > > > > > > > > Signed-off-by: Alexandru Ardelean > > > --- > > > drivers/iio/industrialio-buffer.c | 66 +-- > > > include/linux/iio/buffer_impl.h | 4 +- > > > 2 files changed, 48 insertions(+), 22 deletions(-) > > > > > > diff --git a/drivers/iio/industrialio-buffer.c > > > b/drivers/iio/industrialio-buffer.c > > > index a525e88b302f..49996bed5f4c 100644 > > > --- a/drivers/iio/industrialio-buffer.c > > > +++ b/drivers/iio/industrialio-buffer.c > > > @@ -448,7 +448,7 @@ static int iio_buffer_add_channel_sysfs(struct > > > iio_dev *indio_dev, > > >IIO_SEPARATE, > > >_dev->dev, > > >buffer, > > > - >scan_el_dev_attr_list); > > > + >buffer_attr_list); > > > if (ret) > > > return ret; > > > attrcount++; > > > @@ -460,7 +460,7 @@ static int iio_buffer_add_channel_sysfs(struct > > > iio_dev *indio_dev, > > >0, > > >_dev->dev, > > >buffer, > > > -
Re: [PATCH] ntp: Use freezable workqueue for RTC synchronization
On Tue, Jan 26, 2021 at 6:48 AM Geert Uytterhoeven
wrote:
>
> The bug fixed by commit e3fab2f3de081e98 ("ntp: Fix RTC synchronization
> on 32-bit platforms") revealed an underlying issue: RTC synchronization
> may happen anytime, even while the system is partially suspended.
>
> On systems where the RTC is connected to an I2C bus, the I2C bus
> controller may already or still be suspended, triggering a WARNING
> during suspend or resume from s2ram:
>
> WARNING: CPU: 0 PID: 124 at drivers/i2c/i2c-core.h:54
> __i2c_transfer+0x634/0x680
> i2c i2c-6: Transfer while suspended
> [...]
> Workqueue: events_power_efficient sync_hw_clock
> [...]
> [] (__i2c_transfer) from [] (i2c_transfer+0x58/0xf8)
> [] (i2c_transfer) from [] (regmap_i2c_read+0x58/0x94)
> [] (regmap_i2c_read) from []
> (_regmap_raw_read+0x19c/0x2f4)
> [] (_regmap_raw_read) from []
> (_regmap_bus_read+0x44/0x68)
> [] (_regmap_bus_read) from []
> (_regmap_read+0x84/0x1a4)
> [] (_regmap_read) from []
> (_regmap_update_bits+0xa8/0xf4)
> [] (_regmap_update_bits) from []
> (_regmap_select_page+0xe4/0x100)
> [] (_regmap_select_page) from []
> (_regmap_raw_write_impl+0xd4/0x6c4)
> [] (_regmap_raw_write_impl) from []
> (_regmap_raw_write+0xd8/0x114)
> [] (_regmap_raw_write) from []
> (regmap_raw_write+0x58/0x7c)
> [] (regmap_raw_write) from []
> (regmap_bulk_write+0x118/0x13c)
> [] (regmap_bulk_write) from []
> (da9063_rtc_set_time+0x44/0x8c)
> [] (da9063_rtc_set_time) from []
> (rtc_set_time+0xc8/0x228)
> [] (rtc_set_time) from [] (sync_hw_clock+0x128/0x1fc)
> [] (sync_hw_clock) from []
> (process_one_work+0x330/0x550)
> [] (process_one_work) from []
> (worker_thread+0x22c/0x2ec)
>
> Fix this race condition by using the freezable instead of the normal
> power-efficient workqueue.
>
> Signed-off-by: Geert Uytterhoeven
LGTM
Acked-by: Rafael J. Wysocki
> ---
> kernel/time/ntp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index 54d52fab201d283e..6310328fe398406a 100644
> --- a/kernel/time/ntp.c
> +++ b/kernel/time/ntp.c
> @@ -502,7 +502,7 @@ static struct hrtimer sync_hrtimer;
>
> static enum hrtimer_restart sync_timer_callback(struct hrtimer *timer)
> {
> - queue_work(system_power_efficient_wq, _work);
> + queue_work(system_freezable_power_efficient_wq, _work);
>
> return HRTIMER_NORESTART;
> }
> @@ -668,7 +668,7 @@ void ntp_notify_cmos_timer(void)
> * just a pointless work scheduled.
> */
> if (ntp_synced() && !hrtimer_is_queued(_hrtimer))
> - queue_work(system_power_efficient_wq, _work);
> + queue_work(system_freezable_power_efficient_wq, _work);
> }
>
> static void __init ntp_init_cmos_sync(void)
> --
> 2.25.1
>
Re: [PATCH v3 11/11] iio: buffer: add ioctl() to support opening extra buffers for IIO device
On Fri, 5 Feb 2021 11:51:13 +0200
Alexandru Ardelean wrote:
> On Thu, Feb 4, 2021 at 9:06 PM Jonathan Cameron
> wrote:
> >
> > On Mon, 1 Feb 2021 16:51:05 +0200
> > Alexandru Ardelean wrote:
> >
> > > With this change, an ioctl() call is added to open a character device for
> > > a
> > > buffer. The ioctl() number is 'i' 0x91, which follows the
> > > IIO_GET_EVENT_FD_IOCTL ioctl.
> > >
> > > The ioctl() will return a 0 FD for the first buffer, as that FD for
> > > buffer0
> > > is the same FD as the one used for this ioctl().
> >
> > That sounds dangerous as code might just use it without checking properly.
> > Perhaps take a leaf out of open() and return negative?
>
> So, initially this returned -EBUSY.
> But that is also confusing.
> And returning 0 isn't great either.
>
> I've been thinking about this for the last few days.
> Would it be too bad if return another FD for the same buffer0 ?
> Admittedly, you'd be able to access the same buffer0 via 2 FDs, but
> coming back to the idea of creating a new API and having to live with
> the old one as well, it feels like these 2 FDs for buffer0 are falling
> under the same principle.
It would be in the crazy category if anyone actually tried to read from
both, unless we did something to spin up a clone of the data and that's
getting complex. I guess we could do something like return errors on
all the original FD activities related to the new one (i.e. poll, read)
That might work. What do you think?
>
> >
> > What would happen if we just returned an error in this path?
>
> We need to find a good error code [if we return an error].
> -EBUSY would sound the closest to something correct.
range error maybe? or just -EINVAL if we do go this way.
Jonathan
>
> >
> > >
> > > For any other extra buffer, this ioctl() will return an anon inode FD that
> > > would access any extra buffer.
> > >
> > > Right now, there doesn't seem to be (or I couldn't find) a way for this
> > > ioctl() to return the FD for buffer0 (i.e. to return the same FD as used
> > > for the ioctl()).
> > > So, usespace would need to know that ioctl(fd,
> > > IIO_GET_EVENT_FD_IOCTL, 0) will return FD 0.
> > > We could also return another FD for buffer 0, but duplicating FDs for the
> > > same IIO buffer sounds problematic.
> > >
> > > Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl() implemented, as the
> > > index for each buffer (and the count) can be deduced from the
> > > '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the number of
> > > bufferY folders).
> > >
> > > Used following C code to test this:
> > > ---
> > >
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include > > #include
> > >
> > > #define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
> > >
> > > int main(int argc, char *argv[])
> > > {
> > > int fd;
> > > int fd1;
> > > int ret;
> > >
> > > if ((fd = open("/dev/iio:device0", O_RDWR))<0) {
> > > fprintf(stderr, "Error open() %d errno %d\n",fd, errno);
> > > return -1;
> > > }
> > >
> > > fprintf(stderr, "Using FD %d\n", fd);
> > >
> > > fd1 = atoi(argv[1]);
> > >
> > > ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, );
> > > if (ret < 0) {
> > > fprintf(stderr, "Error for buffer %d ioctl() %d errno
> > > %d\n", fd1, ret, errno);
> > > close(fd);
> > > return -1;
> > > }
> > >
> > > fprintf(stderr, "Got FD %d\n", fd1);
> > >
> > > close(fd1);
> > > close(fd);
> > >
> > > return 0;
> > > }
> > > ---
> > >
> > > Results are:
> > > ---
> > > # ./test 0
> > > Using FD 3
> > > Got FD 0
> > >
> > > # ./test 1
> > > Using FD 3
> > > Got FD 4
> > >
> > > # ./test 2
> > > Using FD 3
> > > Got FD 4
> > >
> > > # ./test 3
> > > Using FD 3
> > > Got FD 4
> > >
> > > # ls /sys/bus/iio/devices/iio\:device0
> > > buffer buffer0 buffer1 buffer2 buffer3 dev
> > > in_voltage_sampling_frequency in_voltage_scale
> > > in_voltage_scale_available
> > > name of_node power scan_elements subsystem uevent
> > > ---
> > >
> > > iio:device0 has some fake kfifo buffers attached to an IIO device.
> > If you get a chance to add a parameter to the tools/iio/ buffer
> > program that does much the same as above that would be great.
>
> will take a look
>
> >
> > >
> > > Signed-off-by: Alexandru Ardelean
> >
> > Otherwise a few trivials inline.
> >
> > Good work on bringing this new approach together so quickly.
> >
> > It's a lot simpler which is good and still gives us a reasonable interface.
> >
> > If you can update the example code in tree and perhaps add
Re: [PATCH 1/2] powercap/intel_rapl: Use topology interface in rapl_add_package()
On Sat, Jan 23, 2021 at 11:07 AM Yunfeng Ye wrote:
>
> It's not a good way to access phys_proc_id and cpu_die_id directly.
> So using topology_physical_package_id(cpu) and topology_die_id(cpu)
> instead.
>
> Signed-off-by: Yunfeng Ye
Srinivas, Rui, any concerns?
> ---
> drivers/powercap/intel_rapl_common.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/powercap/intel_rapl_common.c
> b/drivers/powercap/intel_rapl_common.c
> index c9e57237d778..5f3d39b8212a 100644
> --- a/drivers/powercap/intel_rapl_common.c
> +++ b/drivers/powercap/intel_rapl_common.c
> @@ -1309,7 +1309,6 @@ struct rapl_package *rapl_add_package(int cpu, struct
> rapl_if_priv *priv)
> {
> int id = topology_logical_die_id(cpu);
> struct rapl_package *rp;
> - struct cpuinfo_x86 *c = _data(cpu);
> int ret;
>
> if (!rapl_defaults)
> @@ -1326,10 +1325,11 @@ struct rapl_package *rapl_add_package(int cpu, struct
> rapl_if_priv *priv)
>
> if (topology_max_die_per_package() > 1)
> snprintf(rp->name, PACKAGE_DOMAIN_NAME_LENGTH,
> -"package-%d-die-%d", c->phys_proc_id, c->cpu_die_id);
> +"package-%d-die-%d",
> +topology_physical_package_id(cpu),
> topology_die_id(cpu));
> else
> snprintf(rp->name, PACKAGE_DOMAIN_NAME_LENGTH, "package-%d",
> -c->phys_proc_id);
> +topology_physical_package_id(cpu));
>
> /* check if the package contains valid domains */
> if (rapl_detect_domains(rp, cpu) || rapl_defaults->check_unit(rp,
> cpu)) {
> --
> 2.27.0
>
[PATCH] iommu/mediatek: Fix error code in probe()
This error path is supposed to return -EINVAL. It used to return
directly but we added some clean up and accidentally removed the
error code. Also I fixed a typo in the error message.
Fixes: c0b57581b73b ("iommu/mediatek: Add power-domain operation")
Signed-off-by: Dan Carpenter
---
drivers/iommu/mtk_iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 0ad14a7604b1..5f78ac0dc30e 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -886,7 +886,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
link = device_link_add(data->smicomm_dev, dev,
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
if (!link) {
- dev_err(dev, "Unable link %s.\n", dev_name(data->smicomm_dev));
+ dev_err(dev, "Unable to link %s.\n",
dev_name(data->smicomm_dev));
+ ret = -EINVAL;
goto out_runtime_disable;
}
--
2.30.0
Re: [PATCH] fs: notify: inotify: Replace a common bad word with better common word
On Fri, Feb 5, 2021 at 2:20 PM Bhaskar Chowdhury wrote:
>
>
>
> s/fucked/messed/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> fs/notify/inotify/inotify_user.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/notify/inotify/inotify_user.c
> b/fs/notify/inotify/inotify_user.c
> index 59c177011a0f..0a9d1a81edf0 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -455,7 +455,7 @@ static void inotify_remove_from_idr(struct fsnotify_group
> *group,
> /*
> * We found an mark in the idr at the right wd, but it's
> * not the mark we were told to remove. eparis seriously
> -* fucked up somewhere.
> +* messed up somewhere.
> */
> if (unlikely(found_i_mark != i_mark)) {
> WARN_ONCE(1, "%s: i_mark=%p i_mark->wd=%d i_mark->group=%p "
> --
> 2.30.0
>
Same comment as the previous attempt:
https://lore.kernel.org/linux-fsdevel/20181205094913.gc22...@quack2.suse.cz/
Please remove the part of the comment that adds no valuable information
and fix grammar mistakes.
Thanks,
Amir.
Re: [PATCH 1/2] x86/hw_breakpoint: Prevent data breakpoints on __per_cpu_offset
On Fri, Feb 05, 2021 at 12:45:54PM +0100, Thomas Gleixner wrote: > On Thu, Feb 04 2021 at 16:11, Andy Lutomirski wrote: > > On Thu, Feb 4, 2021 at 6:26 AM Lai Jiangshan wrote: > >> When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU > >> GSBASE value via __per_cpu_offset or pcpu_unit_offsets. > >> > >> When data breakpoint is set on __per_cpu_offset[cpu] (read-write > >> operation), the specific cpu will be stuck in the infinite #DB loop. > >> RCU will try to send NMI to the specific cpu, but it is not working > >> either since NMI also relies on paranoid_entry(). > > > > Should we consider having a .percpu..noinstr section and having > > objtool enforce this? > > I think so. I'll put it on the TODO list somewhere ...
[PATCH] drivers: net: ethernet: sun: Fix couple of spells in the file sunhme.c
s/fuck/mess/
s/fucking/s/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/ethernet/sun/sunhme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunhme.c
b/drivers/net/ethernet/sun/sunhme.c
index 54b53dbdb33c..98ff9300b5ee 100644
--- a/drivers/net/ethernet/sun/sunhme.c
+++ b/drivers/net/ethernet/sun/sunhme.c
@@ -982,7 +982,7 @@ static void happy_meal_poll_stop(struct happy_meal *hp,
void __iomem *tregs)
ASD(("done\n"));
}
-/* Only Sun can take such nice parts and fuck up the programming interface
+/* Only Sun can take such nice parts and mess up the programming interface
* like this. Good job guys...
*/
#define TCVR_RESET_TRIES 16 /* It should reset quickly*/
@@ -2074,7 +2074,7 @@ static void happy_meal_rx(struct happy_meal *hp, struct
net_device *dev)
skb = copy_skb;
}
- /* This card is _fucking_ hot... */
+ /* This card is _so_ hot... */
skb->csum = csum_unfold(~(__force __sum16)htons(csum));
skb->ip_summed = CHECKSUM_COMPLETE;
--
2.30.0
Re: [PATCH net-next 3/8] net: dsa: microchip: add DSA support for microchip lan937x
On Fri, 2021-01-29 at 02:07 +0100, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
Thanks for your time on reviewing the patches.
>
> > +bool lan937x_is_internal_phy_port(struct ksz_device *dev, int
> > port)
> > +{
> > + /* Check if the port is RGMII */
> > + if (port == LAN937X_RGMII_1_PORT || port ==
> > LAN937X_RGMII_2_PORT)
> > + return false;
> > +
> > + /* Check if the port is SGMII */
> > + if (port == LAN937X_SGMII_PORT &&
> > + GET_CHIP_ID_LSB(dev->chip_id) == CHIP_ID_73)
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > +static u32 lan937x_get_port_addr(int port, int offset)
> > +{
> > + return PORT_CTRL_ADDR(port, offset);
> > +}
> > +
> > +bool lan937x_is_internal_tx_phy_port(struct ksz_device *dev, int
> > port)
> > +{
> > + /* Check if the port is internal tx phy port */
>
> What is an internal TX phy port? Is it actually a conventional t2
> Fast
> Ethernet port, as opposed to a t1 port?
This is 100 Base-Tx phy which is compliant with
802.3/802.3u standards. Two of the SKUs have both T1 and TX integrated
Phys as mentioned in the patch intro mail.
>
> > + if (lan937x_is_internal_phy_port(dev, port) && port ==
> > LAN937X_TXPHY_PORT)
> > + if ((GET_CHIP_ID_LSB(dev->chip_id) == CHIP_ID_71) ||
> > + (GET_CHIP_ID_LSB(dev->chip_id) == CHIP_ID_72))
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +bool lan937x_is_internal_t1_phy_port(struct ksz_device *dev, int
> > port)
> > +{
> > + /* Check if the port is internal t1 phy port */
> > + if (lan937x_is_internal_phy_port(dev, port) &&
> > + !lan937x_is_internal_tx_phy_port(dev, port))
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +int lan937x_t1_tx_phy_write(struct ksz_device *dev, int addr,
> > + int reg, u16 val)
> > +{
> > + u16 temp, addr_base;
> > + unsigned int value;
> > + int ret;
> > +
> > + /* Check for internal phy port */
> > + if (!lan937x_is_internal_phy_port(dev, addr))
> > + return 0;
>
> All this t1 and tx is confusing. I think lan937x_internal_phy_write()
> would be better.
Sure, will rename it to lan937x_internal_phy_write()
>
> I also wonder if -EOPNOTSUPP would be better, or -EINVAL?
-EOPNOTSUPP would be better. Currently return value has not checked for
phy_write() calls, i will add that as well in the list
>
> > +
> > + if (lan937x_is_internal_tx_phy_port(dev, addr))
> > + addr_base = REG_PORT_TX_PHY_CTRL_BASE;
> > + else
> > + addr_base = REG_PORT_T1_PHY_CTRL_BASE;
> > +
> > + temp = PORT_CTRL_ADDR(addr, (addr_base + (reg << 2)));
> > +
> > + ksz_write16(dev, REG_VPHY_IND_ADDR__2, temp);
> > +
> > + /* Write the data to be written to the VPHY reg */
> > + ksz_write16(dev, REG_VPHY_IND_DATA__2, val);
> > +
> > + /* Write the Write En and Busy bit */
> > + ksz_write16(dev, REG_VPHY_IND_CTRL__2, (VPHY_IND_WRITE
> > + | VPHY_IND_BUSY));
> > +
> > + ret = regmap_read_poll_timeout(dev->regmap[1],
> > +REG_VPHY_IND_CTRL__2,
> > + value, !(value & VPHY_IND_BUSY), 10,
> > 1000);
> > +
> > + /* failed to write phy register. get out of loop */
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to write phy register\n");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +int lan937x_t1_tx_phy_read(struct ksz_device *dev, int addr,
> > +int reg, u16 *val)
> > +{
> > + u16 temp, addr_base;
> > + unsigned int value;
> > + int ret;
> > +
> > + if (lan937x_is_internal_phy_port(dev, addr)) {
> > + if (lan937x_is_internal_tx_phy_port(dev, addr))
> > + addr_base = REG_PORT_TX_PHY_CTRL_BASE;
> > + else
> > + addr_base = REG_PORT_T1_PHY_CTRL_BASE;
>
> You could reduce the indentation by doing what you did above:
Sure, will change it.
>
> > + /* Check for internal phy port */
> > + if (!lan937x_is_internal_phy_port(dev, addr))
> > + return 0;
>
> You might want to return 0x here, which is what a read on a
> non-existent device on an MDIO bus should return.
Sure, will change it
>
>
> > +
> > + /* get register address based on the logical port */
> > + temp = PORT_CTRL_ADDR(addr, (addr_base + (reg <<
> > 2)));
> > +
> > + ksz_write16(dev, REG_VPHY_IND_ADDR__2, temp);
> > + /* Write Read and Busy bit to start the transaction*/
> > + ksz_write16(dev, REG_VPHY_IND_CTRL__2,
> > VPHY_IND_BUSY);
> > +
> > + ret = regmap_read_poll_timeout(dev->regmap[1],
> > +REG_VPHY_IND_CTRL__2,
> > +
Re: [PATCH] include: acpi: Correct spelling in the file acoutput.h is optimzation to optimization
On Wed, Feb 3, 2021 at 4:45 PM Bhaskar Chowdhury wrote: > > > s/optimzation/optimization/ > > Signed-off-by: Bhaskar Chowdhury > --- > include/acpi/acoutput.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h > index c5d900c0ecda..1ba212372e79 100644 > --- a/include/acpi/acoutput.h > +++ b/include/acpi/acoutput.h > @@ -362,7 +362,7 @@ > * > * A less-safe version of the macros is provided for optional use if the > * compiler uses excessive CPU stack (for example, this may happen in the > - * debug case if code optimzation is disabled.) > + * debug case if code optimization is disabled.) > */ > > /* Exit trace helper macro */ > -- The file being updated is part of ACPICA, so I'm leaving this to Erik & Bob, thanks!
Re: [PATCH] apei: erst: remove unneeded semicolon
On Tue, Feb 2, 2021 at 7:52 AM Yang Li wrote: > > Eliminate the following coccicheck warning: > ./drivers/acpi/apei/erst.c:691:2-3: Unneeded semicolon > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > drivers/acpi/apei/erst.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c > index 2e0b0fc..b959721 100644 > --- a/drivers/acpi/apei/erst.c > +++ b/drivers/acpi/apei/erst.c > @@ -688,7 +688,7 @@ static int __erst_read_from_storage(u64 record_id, u64 > offset) > break; > if (erst_timedout(, SPIN_UNIT)) > return -EIO; > - }; > + } > rc = apei_exec_run(, ACPI_ERST_GET_COMMAND_STATUS); > if (rc) > return rc; > -- Applied as 5.12 material, thanks!
Re: [PATCH v2 1/2] EDAC/ghes: Add EDAC device for reporting the CPU cache errors
On Fri, Jan 29, 2021 at 1:03 PM Shiju Jose wrote: > > CPU L2 cache corrected errors are detected occasionally on > few of our ARM64 hardware boards. Though it is rare, the > probability of the CPU cache errors frequently occurring > can't be avoided. The earlier failure detection by monitoring > the cache corrected errors for the frequent occurrences and > taking preventive action could prevent more serious hardware > faults. > > On Intel architectures, cache corrected errors are reported and > the affected cores are offlined in the architecture specific method. > http://www.mcelog.org/cache.html > > However for the firmware-first error reporting, specifically on > ARM64 architectures, there is no provision present for reporting > the cache corrected error count to the user-space and taking > preventive action such as offline the affected cores. > > For this purpose, it was suggested to create the CPU EDAC > device for the CPU caches for reporting the cache error count > for the firmware-first error reporting. > The EDAC device blocks for the CPU caches would be created > based on the cache information obtained from the cpu_cacheinfo. > > User-space application could monitor the recorded corrected error > count for the earlier hardware failure detection and could take > preventive action, such as offline the corresponding CPU core/s. > > Add an EDAC device and device blocks for the CPU caches > based on the cache information from the cpu_cacheinfo. > The cache's corrected error count would be stored in the > /sys/devices/system/edac/cpu/cpu*/cache*/ce_count. > > Issues and possible solutions, > 1.Cache info is not available for the CPUs offline. > EDAC device interface requires creating EDAC device > and device blocks together. It requires the number > of caches per CPU as device blocks for the creation. > However, this info is not available for the > offlined CPUs. > Tested Solution: Find the max number of caches among > online CPUs, create the EDAC device for CPUs caches > and get and populate the cache info for an offline > CPU later, when the error is reported on that CPU for > the first time. > > 2. Reporting error count for the Shared caches. >There are few possible solutions, > Tested Solution: > Kernel would report a new error count for a shared cache > through the EDAC device block for that CPU on which the error > is reported. Then user-space application would sum the total > error count from EDAC device block of all the CPUs in the > shared CPU list of that shared cache. > > For the firmware-first error reporting, add an interface in the > ghes_edac allow to report a CPU corrected error count. > > Suggested-by: James Morse > Signed-off-by: Shiju Jose Boris, James, I need your input here. > --- > Documentation/ABI/testing/sysfs-devices-edac | 15 ++ > drivers/acpi/apei/ghes.c | 8 +- > drivers/edac/Kconfig | 12 ++ > drivers/edac/ghes_edac.c | 186 +++ > include/acpi/ghes.h | 27 +++ > 5 files changed, 247 insertions(+), 1 deletion(-) > > diff --git a/Documentation/ABI/testing/sysfs-devices-edac > b/Documentation/ABI/testing/sysfs-devices-edac > index 256a9e990c0b..56a18b0af419 100644 > --- a/Documentation/ABI/testing/sysfs-devices-edac > +++ b/Documentation/ABI/testing/sysfs-devices-edac > @@ -155,3 +155,18 @@ Description: This attribute file displays the > total count of uncorrectable > errors that have occurred on this DIMM. If panic_on_ue is > set, this > counter will not have a chance to increment, since EDAC will > panic the > system > + > +What: /sys/devices/system/edac/cpu/cpu*/cache*/ce_count > +Date: December 2020 > +Contact:linux-e...@vger.kernel.org > +Description:This attribute file displays the total count of correctable > +errors that have occurred on this CPU cache. This count is > very important > +to examine. CEs provide early indications that a cache is > beginning > +to fail. This count field should be monitored for non-zero > values > +and report such information to the system administrator. > + > +What: /sys/devices/system/edac/cpu/cpu*/cache*/ue_count > +Date: December 2020 > +Contact:linux-e...@vger.kernel.org > +Description:This attribute file displays the total count of uncorrectable > +errors that have occurred on this CPU cache. > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > index fce7ade2aba9..139540f2c8f4 100644 > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -1452,4 +1452,10 @@ static int __init ghes_init(void) > err: > return rc; > } > -device_initcall(ghes_init); > + > +/* > + * device_initcall_sync() is added instead of the device_initcall() > +
[PATCH] drivers: scsi: Describe and replace a word with better one in the file qlogicpti.h
s/fucking/awful/
Signed-off-by: Bhaskar Chowdhury
---
drivers/scsi/qlogicpti.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/qlogicpti.h b/drivers/scsi/qlogicpti.h
index 2b6374e08a7d..4a47631b22ea 100644
--- a/drivers/scsi/qlogicpti.h
+++ b/drivers/scsi/qlogicpti.h
@@ -62,7 +62,7 @@
#define REQUEST_QUEUE_WAKEUP 0x8005
#define EXECUTION_TIMEOUT_RESET0x8006
-/* Am I fucking pedantic or what? */
+/* Am I awful pedantic or what? */
struct Entry_header {
#ifdef __BIG_ENDIAN
u8 entry_cnt;
--
2.30.0
Re: [External] Re: [PATCH] mm: memcontrol: remove rcu_read_lock from get_mem_cgroup_from_page
On Fri, Feb 5, 2021 at 6:32 PM Michal Hocko wrote: > > On Fri 05-02-21 17:14:30, Muchun Song wrote: > > On Fri, Feb 5, 2021 at 4:36 PM Michal Hocko wrote: > > > > > > On Fri 05-02-21 14:27:19, Muchun Song wrote: > > > > The get_mem_cgroup_from_page() is called under page lock, so the page > > > > memcg cannot be changed under us. > > > > > > Where is the page lock enforced? > > > > Because it is called from alloc_page_buffers(). This path is under > > page lock. > > I do not see any page lock enforecement there. There is not even a > comment requiring that. Can we grow more users where this is not the > case? There is no actual relation between alloc_page_buffers and > get_mem_cgroup_from_page except that the former is the only _current_ > existing user. I would be careful to dictate locking based solely on > that. Yeah, there is no comment requiring that. I have seen all the callers of the alloc_page_buffers. I found that it is under page lock. But it seems it is not the key point here. I should delete those comments from the commit log. > > > > > Also, css_get is enough because page > > > > has a reference to the memcg. > > > > > > tryget used to be there to guard against offlined memcg but we have > > > concluded this is impossible in this path. tryget stayed there to catch > > > some unexpected cases IIRC. > > > > Yeah, it can catch some unexpected cases. But why is this path > > special so that we need a tryget? > > I do not remember details and the changelog of that change is not > explicit but I suspect it was just because this one could trigger as > there are external callers to memcg. Is this protection needed? I am not > sure, this is for you to justify if you want to remove it. I am sure it is not needed. > > > > > If we really want to make the get_mem_cgroup_from_page() suitable for > > > > arbitrary page, we should use page_memcg_rcu() instead of page_memcg() > > > > and call it after rcu_read_lock(). > > > > > > What is the primary motivation to change this code? is the overhead of > > > tryget/RCU something that needs optimizing? > > > > Actually, the rcu_read_lock() is not necessary here. So it is better to > > remove it (indeed reduce some code). > > Please state your reasoning in the changelog including benefits we get > from it. OK. > -- > Michal Hocko > SUSE Labs
Re: [PATCH 06/24] perf daemon: Add config file support
On Fri, Feb 05, 2021 at 09:14:54PM +0900, Namhyung Kim wrote:
> On Sun, Jan 31, 2021 at 8:49 AM Jiri Olsa wrote:
> [SNIP]
> > @@ -263,9 +605,16 @@ static int __cmd_start(struct daemon *daemon, struct
> > option parent_options[],
> > signal(SIGTERM, sig_handler);
> >
> > while (!done && !err) {
> > - if (fdarray__poll(, -1)) {
> > + err = daemon__reconfig(daemon);
>
> I think it's confusing since you put the reconfig function here.
> What not split normal and reconfig passes?
hum, not sure what's confusing in here? I've been known to
produce confusing code, but this one seems clear to me
>
> I mean something like below
>
> __cmd_start()
> {
> setup_server_config();
> daemon__run();
what's daemon__run? the daemon operates in the while loop below
>
> while (!done && !err) {
> ...
> if (reconfig) {
> daemon__kill();
you don't kill daemon for each reconfig change,
we detect changed sessions and kill/restart only them
> setup_server_config();
> daemon__reconfig();
> }
> }
so basically the current workflow is:
setup_server_config <--- reads
config file, prepares session objects
while (!done) {
daemon__reconfig<--- check
session objects states and run/stop them
if (fdarray__poll(, -1)) {
handle_config_changes()<--- was there
a config file change?
if (reconfig) <--- yes,
setup_server_config <---
change session objects/states
}
}
thanks,
jirka
Re: [PATCH v3 08/11] iio: buffer: wrap all buffer attributes into iio_dev_attr
On Fri, Feb 5, 2021 at 2:40 PM Jonathan Cameron wrote: > > On Fri, 5 Feb 2021 11:17:04 +0200 > Alexandru Ardelean wrote: > > > On Thu, Feb 4, 2021 at 8:26 PM Jonathan Cameron > > wrote: > > > > > > On Mon, 1 Feb 2021 16:51:02 +0200 > > > Alexandru Ardelean wrote: > > > > > > > This change wraps all buffer attributes into iio_dev_attr objects, and > > > > assigns a reference to the IIO buffer they belong to. > > > > > > > > With the addition of multiple IIO buffers per one IIO device, we need a > > > > way > > > > to know which IIO buffer is being enabled/disabled/controlled. > > > > > > > > We know that all buffer attributes are device_attributes. So we can wrap > > > > them with a iio_dev_attr types. In the iio_dev_attr type, we can also > > > > hold > > > > a reference to an IIO buffer. > > > > So, we end up being able to allocate wrapped attributes for all buffer > > > > attributes (even the one from other drivers). > > > > > > > > The neat part with this mechanism, is that we don't need to add any > > > > extra > > > > cleanup, because these attributes are being added to a dynamic list that > > > > will get cleaned up via iio_free_chan_devattr_list(). > > > > > > > > > > > > > > With this change, the 'buffer->scan_el_dev_attr_list' list is being > > > > renamed > > > > to 'buffer->buffer_attr_list', effectively merging (or finalizing the > > > > merge) of the buffer/ & scan_elements/ attributes internally. > > > > > > > > Accessing these new buffer attributes can now be done via > > > > 'to_iio_dev_attr(attr)->buffer' inside the show/store handlers. > > > > > > That is going to look a bit odd in any drivers that use it given they > > > will appear to not be embedded. > > > > > > There seem to be very few such attributes from a quick grep, so maybe > > > we may want to unwind this and change all the types. Might still need > > > to set .buffer for some of them though (only applying to new drivers as > > > clearly current ones don't care!) > > > > > > Looking at what they actually are, some perhaps shouldn't have been in > > > the buffer > > > directory in the first place (with hindsight!). > > > > > > Anyhow, aside from that oddity this looks good to me. > > > > I'm a little vague here. > > If there is a suggestion for a change, I may have missed it. > > It was vague because I wasn't sure if it it made sense :) > > > > I'm a bit vague on the part of "we may want to unwind this and change > > all the types" > > Is it referring to something like this patch? > > > > https://lore.kernel.org/linux-iio/20210122162529.84978-10-alexandru.ardel...@analog.com/ > > Exactly, that was what I was wondering about. So, from a perspective of API for drivers, it would probably make sense to have those sort of store/show hook types. But I am leaning towards maybe moving the HW fifo stuff into IIO core somehow. Which would make these [new] store/show hooks unneeded [for now at least]. > > > We could do a show/store version that takes an iio_buf_attr or > > iio_dev_attr parameter. > > But maybe at a later point? > > I don't feel it adds much benefit over the current usage of > > buffer->attrs, because we need to kmalloc these iio_dev_attr anyways > > to store the reference to the iio_buffer. > > > > I would have liked to get rid of these user/external buffer->attrs. > > That would have made things easier. > > > > But, it looks like there are several drivers using them. > > I usually find them by grepping for iio_triggered_buffer_setup_ext > > It's only 5 drivers that provide these attributes. > > It used to be a bit easier to find them by grepping > > iio_buffer_set_attrs(), but I removed that. > > We could look at whether some can be brought into the core. They tend > to be around hwfifo parameters. Those could be specific to individual > buffers rather than device wide so at least some of them are correctly > placed in the buffer directory (I think - I've argued with myself about > this a few times in the past). I think they could be brought into core. But they would take some time (because of testing) These HW Fifo attributes were copied around between drivers and ended being the same. So, some IIO core logic would make sense. It's 5 drivers now. > > The only oddity we'll get from current approach is callbacks appearing > to access a container structure that they aren't associated with in the > driver. Its the sort of interface that no one would ever realize was > possible. > > Jonathan > > > > > > > > > > > Jonathan > > > > > > > > > > > Signed-off-by: Alexandru Ardelean > > > > --- > > > > drivers/iio/industrialio-buffer.c | 66 +-- > > > > include/linux/iio/buffer_impl.h | 4 +- > > > > 2 files changed, 48 insertions(+), 22 deletions(-) > > > > > > > > diff --git a/drivers/iio/industrialio-buffer.c > > > > b/drivers/iio/industrialio-buffer.c > > > > index a525e88b302f..49996bed5f4c 100644 > > > > --- a/drivers/iio/industrialio-buffer.c > > > > +++
Re: [PATCH v2 1/2] s390/kvm: extend kvm_s390_shadow_fault to return entry pointer
On 2/5/21 1:15 PM, Claudio Imbrenda wrote:
> On Thu, 4 Feb 2021 17:34:00 +0100
> Janosch Frank wrote:
>
>> On 2/2/21 7:00 PM, Claudio Imbrenda wrote:
>>> Extend kvm_s390_shadow_fault to return the pointer to the valid leaf
>>> DAT table entry, or to the invalid entry.
>>>
>>> Also return some flags in the lower bits of the address:
>>> DAT_PROT: indicates that DAT protection applies because of the
>>> protection bit in the segment (or, if EDAT, region) tables
>>> NOT_PTE: indicates that the address of the DAT table entry returned
>>> does not refer to a PTE, but to a segment or region table.
>>>
>>> Signed-off-by: Claudio Imbrenda
>>> Cc: sta...@vger.kernel.org
>>> ---
>>> arch/s390/kvm/gaccess.c | 26 ++
>>> arch/s390/kvm/gaccess.h | 5 -
>>> arch/s390/kvm/vsie.c| 8
>>> 3 files changed, 30 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/s390/kvm/gaccess.c b/arch/s390/kvm/gaccess.c
>>> index 6d6b57059493..2d7bcbfb185e 100644
>>> --- a/arch/s390/kvm/gaccess.c
>>> +++ b/arch/s390/kvm/gaccess.c
>>> @@ -1034,6 +1034,7 @@ static int kvm_s390_shadow_tables(struct gmap
>>> *sg, unsigned long saddr, rfte.val = ptr;
>>> goto shadow_r2t;
>>> }
>>> + *pgt = ptr + vaddr.rfx * 8;
>>
>> So pgt either is a table entry if rc > 0 or a pointer to the first pte
>> on rc == 0 after this change?
>
> yes
>
>> Hrm, if it is really based on RCs than I might be able to come to
>> terms with having two things in a ptr with the name pgt. But it needs
>> a comment change.
>
> will do.
>
>>> rc = gmap_read_table(parent, ptr + vaddr.rfx * 8,
>>> ); if (rc)
>>> return rc;
>>> @@ -1060,6 +1061,7 @@ static int kvm_s390_shadow_tables(struct gmap
>>> *sg, unsigned long saddr, rste.val = ptr;
>>> goto shadow_r3t;
>>> }
>>> + *pgt = ptr + vaddr.rsx * 8;
>>> rc = gmap_read_table(parent, ptr + vaddr.rsx * 8,
>>> ); if (rc)
>>> return rc;
>>> @@ -1087,6 +1089,7 @@ static int kvm_s390_shadow_tables(struct gmap
>>> *sg, unsigned long saddr, rtte.val = ptr;
>>> goto shadow_sgt;
>>> }
>>> + *pgt = ptr + vaddr.rtx * 8;
>>> rc = gmap_read_table(parent, ptr + vaddr.rtx * 8,
>>> ); if (rc)
>>> return rc;
>>> @@ -1123,6 +1126,7 @@ static int kvm_s390_shadow_tables(struct gmap
>>> *sg, unsigned long saddr, ste.val = ptr;
>>> goto shadow_pgt;
>>> }
>>> + *pgt = ptr + vaddr.sx * 8;
>>> rc = gmap_read_table(parent, ptr + vaddr.sx * 8,
>>> ); if (rc)
>>> return rc;
>>> @@ -1157,6 +1161,8 @@ static int kvm_s390_shadow_tables(struct gmap
>>> *sg, unsigned long saddr,
>>> * @vcpu: virtual cpu
>>> * @sg: pointer to the shadow guest address space structure
>>> * @saddr: faulting address in the shadow gmap
>>> + * @pteptr: will contain the address of the faulting DAT table
>>> entry, or of
>>> + * the valid leaf, plus some flags
>>
>> pteptr is not the right name if it can be two things
>
> it cannot be two things there, kvm_s390_shadow_fault always returns a
> DAT _entry_ (pte, segment, region).
And that's exactly what I meant, it's not a pteptr i.e. not a (pte_t *)
as the name would suggest.
>
>>> *
>>> * Returns: - 0 if the shadow fault was successfully resolved
>>> * - > 0 (pgm exception code) on exceptions while
>>> faulting @@ -1165,11 +1171,11 @@ static int
>>> kvm_s390_shadow_tables(struct gmap *sg, unsigned long saddr,
>>> * - -ENOMEM if out of memory
>>> */
>>> int kvm_s390_shadow_fault(struct kvm_vcpu *vcpu, struct gmap *sg,
>>> - unsigned long saddr)
>>> + unsigned long saddr, unsigned long
>>> *pteptr) {
>>> union vaddress vaddr;
>>> union page_table_entry pte;
>>> - unsigned long pgt;
>>> + unsigned long pgt = 0;
>>> int dat_protection, fake;
>>> int rc;
>>>
>>> @@ -1191,8 +1197,20 @@ int kvm_s390_shadow_fault(struct kvm_vcpu
>>> *vcpu, struct gmap *sg, pte.val = pgt + vaddr.px * PAGE_SIZE;
>>> goto shadow_page;
>>> }
>>> - if (!rc)
>>> - rc = gmap_read_table(sg->parent, pgt + vaddr.px *
>>> 8, ); +
>>> + switch (rc) {
>>> + case PGM_SEGMENT_TRANSLATION:
>>> + case PGM_REGION_THIRD_TRANS:
>>> + case PGM_REGION_SECOND_TRANS:
>>> + case PGM_REGION_FIRST_TRANS:
>>> + pgt |= NOT_PTE;
>>
>> GACC_TRANSL_ENTRY_INV ?
>
> no, this is only for non-pte entries
>
>>> + break;
>>> + case 0:
>>> + pgt += vaddr.px * 8;
>>> + rc = gmap_read_table(sg->parent, pgt, );
>>> + }
>>> + if (*pteptr)
>>> + *pteptr = pgt | dat_protection * DAT_PROT;
>>> if (!rc && pte.i)
>>> rc = PGM_PAGE_TRANSLATION;
>>> if (!rc && pte.z)
>>> diff --git a/arch/s390/kvm/gaccess.h b/arch/s390/kvm/gaccess.h
Re: [PATCH 6/9] perf report: Support instruction latency
> On 04-Feb-2021, at 8:49 PM, Liang, Kan wrote:
>
>
>
> On 2/4/2021 8:11 AM, Athira Rajeev wrote:
>>> On 03-Feb-2021, at 1:39 AM, kan.li...@linux.intel.com wrote:
>>>
>>> From: Kan Liang
>>>
>>> The instruction latency information can be recorded on some platforms,
>>> e.g., the Intel Sapphire Rapids server. With both memory latency
>>> (weight) and the new instruction latency information, users can easily
>>> locate the expensive load instructions, and also understand the time
>>> spent in different stages. The users can optimize their applications
>>> in different pipeline stages.
>>>
>>> The 'weight' field is shared among different architectures. Reusing the
>>> 'weight' field may impacts other architectures. Add a new field to store
>>> the instruction latency.
>>>
>>> Like the 'weight' support, introduce a 'ins_lat' for the global
>>> instruction latency, and a 'local_ins_lat' for the local instruction
>>> latency version.
>>>
>>> Add new sort functions, INSTR Latency and Local INSTR Latency,
>>> accordingly.
>>>
>>> Add local_ins_lat to the default_mem_sort_order[].
>>>
>>> Signed-off-by: Kan Liang
>>> ---
>>> tools/perf/Documentation/perf-report.txt | 6 +++-
>>> tools/perf/util/event.h | 1 +
>>> tools/perf/util/evsel.c | 4 ++-
>>> tools/perf/util/hist.c | 12 ++--
>>> tools/perf/util/hist.h | 2 ++
>>> tools/perf/util/intel-pt.c | 5 ++--
>>> tools/perf/util/session.c| 8 --
>>> tools/perf/util/sort.c | 47
>>> +++-
>>> tools/perf/util/sort.h | 3 ++
>>> tools/perf/util/synthetic-events.c | 4 ++-
>>> 10 files changed, 81 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/tools/perf/Documentation/perf-report.txt
>>> b/tools/perf/Documentation/perf-report.txt
>>> index 826b5a9..0565b7c 100644
>>> --- a/tools/perf/Documentation/perf-report.txt
>>> +++ b/tools/perf/Documentation/perf-report.txt
>>> @@ -108,6 +108,9 @@ OPTIONS
>>> - period: Raw number of event count of sample
>>> - time: Separate the samples by time stamp with the resolution
>>> specified by
>>> --time-quantum (default 100ms). Specify with overhead and before it.
>>> + - ins_lat: Instruction latency in core cycles. This is the global
>>> + instruction latency
>>> + - local_ins_lat: Local instruction latency version
>>>
>>> By default, comm, dso and symbol keys are used.
>>> (i.e. --sort comm,dso,symbol)
>>> @@ -154,7 +157,8 @@ OPTIONS
>>> - blocked: reason of blocked load access for the data at the time of
>>> the sample
>>>
>>> And the default sort keys are changed to local_weight, mem, sym, dso,
>>> - symbol_daddr, dso_daddr, snoop, tlb, locked, blocked, see '--mem-mode'.
>>> + symbol_daddr, dso_daddr, snoop, tlb, locked, blocked, local_ins_lat,
>>> + see '--mem-mode'.
>>>
>>> If the data file has tracepoint event(s), following (dynamic) sort keys
>>> are also available:
>>> diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
>>> index ff403ea..5d50a49 100644
>>> --- a/tools/perf/util/event.h
>>> +++ b/tools/perf/util/event.h
>>> @@ -141,6 +141,7 @@ struct perf_sample {
>>> u16 insn_len;
>>> u8 cpumode;
>>> u16 misc;
>>> + u16 ins_lat;
>>> bool no_hw_idx; /* No hw_idx collected in branch_stack */
>>> char insn[MAX_INSN];
>>> void *raw_data;
>>> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
>>> index 0a2a307..24c0b59 100644
>>> --- a/tools/perf/util/evsel.c
>>> +++ b/tools/perf/util/evsel.c
>>> @@ -2337,8 +2337,10 @@ int evsel__parse_sample(struct evsel *evsel, union
>>> perf_event *event,
>>> weight.full = *array;
>>> if (type & PERF_SAMPLE_WEIGHT)
>>> data->weight = weight.full;
>>> - else
>>> + else {
>>> data->weight = weight.var1_dw;
>>> + data->ins_lat = weight.var2_w;
>>> + }
>>> array++;
>>> }
>>>
>>> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
>>> index 6866ab0..8a432f8 100644
>>> --- a/tools/perf/util/hist.c
>>> +++ b/tools/perf/util/hist.c
>>> @@ -209,6 +209,8 @@ void hists__calc_col_len(struct hists *hists, struct
>>> hist_entry *h)
>>> hists__new_col_len(hists, HISTC_LOCAL_WEIGHT, 12);
>>> hists__new_col_len(hists, HISTC_GLOBAL_WEIGHT, 12);
>>> hists__new_col_len(hists, HISTC_MEM_BLOCKED, 10);
>>> + hists__new_col_len(hists, HISTC_LOCAL_INS_LAT, 13);
>>> + hists__new_col_len(hists, HISTC_GLOBAL_INS_LAT, 13);
>>> if (symbol_conf.nanosecs)
>>> hists__new_col_len(hists, HISTC_TIME, 16);
>>> else
>>> @@ -286,12 +288,13 @@ static long hist_time(unsigned long htime)
>>> }
>>>
>>> static void he_stat__add_period(struct he_stat *he_stat, u64 period,
>>> - u64 weight)
>>> + u64 weight, u64
[PATCH] drivers: drm: nouveau: nvkm: Replace a word with a better phonetic word in the file macros.fuc
s/fuck/heck/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index 3737bd27f74e..1407a1b16d95 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc @@ -46,7 +46,7 @@ #define NV_PPWR_INTR_EN_SET_SUBINTR 0x0800 #define NV_PPWR_INTR_EN_SET_WATCHDOG 0x0002 #define NV_PPWR_INTR_EN_CLR 0x0014 -#define NV_PPWR_INTR_EN_CLR_MASK/* fuck i hate envyas */ -1 +#define NV_PPWR_INTR_EN_CLR_MASK/* heck, i hate envyas */ -1 #define NV_PPWR_INTR_ROUTE 0x001c #define NV_PPWR_TIMER_LOW0x002c #define NV_PPWR_WATCHDOG_TIME0x0034 -- 2.30.0
[GIT PULL] MHI changes for v5.12
Hi Greg, Here is the MHI Pull request for the v5.12 cycle. As like last time, I needed to do PR this time due to the immutable branches with net-next and ath11k-next. Patch details are in the signed tag, please consider merging! Thanks, Mani --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi.git tags/mhi-for-v5.12 for you to fetch changes up to 026c5b1ec29cb9904406c7b3090eaf54e345e7f2: bus: mhi: pci_generic: Increase num of elements in hw event ring (2021-02-05 17:59:29 +0530) MHI changes for v5.12 Loic improved the MHI PCI generic controller by adding support for DIAG channel, PCI error handling, suspend/recovery/resume, and health check. Loic also added support for resetting the MHI device as per the MHI specification. This includes writing to a specific register for default cases and looking for controller specific callback when provided. Along with this Loic, also added a new API which gets the number for free TREs (Transfer Ring Elements) from the MHI core. The client drivers can make use of this API and the current consumer is the "mhi-net" driver. For taking both the "mhi-net" driver change and the API change, we created "mhi-net-immutable" branch for this patch and merged the same into net-next and mhi-next. Carl added a patch which lets the controller driver to pass the custom IRQ flags for BHI and MHI event interrupts to the MHI core. The current consumer of this feature is the ath11k MHI controller driver. For taking both the changes, we created "mhi-ath11k-immutable" branch for this patch and merged into ath11k-next and mhi-next. Finally, Loic cleaned up the MHI queue APIs and fixed the shared MSI vector support. Carl Huang (1): mhi: use irq_flags if controller driver configures it Hemant Kumar (1): bus: mhi: core: Add helper API to return number of free TREs Loic Poulain (16): bus: mhi: core: Add device hardware reset support mhi: pci-generic: Increase number of hardware events mhi: pci_generic: Enable burst mode for hardware channels mhi: pci_generic: Add support for reset mhi: pci_generic: Add suspend/resume/recovery procedure mhi: pci_generic: Add PCI error handlers mhi: pci_generic: Add health-check mhi: pci_generic: Increase controller timeout value mhi: pci_generic: Add diag channels mhi: pci_generic: Set irq moderation value to 1ms for hw channels bus: mhi: Ensure correct ring update ordering with memory barrier mhi: unconstify mhi_event_config mhi: pci_generic: Fix shared MSI vector support mhi: core: Factorize mhi queuing mhi: pci_generic: Print warning in case of firmware crash bus: mhi: pci_generic: Increase num of elements in hw event ring Manivannan Sadhasivam (2): Merge branch 'mhi-ath11k-immutable' into mhi-next Merge branch 'mhi-net-immutable' into mhi-next drivers/bus/mhi/core/init.c | 9 ++- drivers/bus/mhi/core/main.c | 194 +++ drivers/bus/mhi/pci_generic.c | 381 include/linux/mhi.h | 22 ++- 4 files changed, 461 insertions(+), 145 deletions(-)
Re: [PATCH] media: pwc: Fix the URB buffer allocation
On Fri, 05 Feb 2021 13:53:21 +0100, Andrew Lunn wrote: > > On Fri, Feb 05, 2021 at 01:36:43PM +0100, Hans Verkuil wrote: > > Hi Takashi, > > > > Thank you for this patch, but it clashes with another patch trying to do > > the same thing > > that has already been merged in our tree: > > > > https://patchwork.linuxtv.org/project/linux-media/patch/20210104170007.20625-1-mat...@sai.msu.ru/ > > > > I do prefer your patch over the one already merged since it is a bit > > simpler, but > > shouldn't the calls to dma_sync_single_for_cpu() and > > dma_sync_single_for_device() > > in pwc-if.c also use urb->dev->bus->controller? > > > > Also, Matwey's patch uses urb->dev->bus->sysdev instead of > > urb->dev->bus->controller. > > How does 'sysdev' relate to 'controller'? I think 'controller' is the right > > device to > > use, but either seems to work when I test it with my pwc webcam. > > Hi Hans > > A quick grep in driver/usb show that all but one dma mapping operation > use sysdev. The one other case uses controller. So the numbers suggest > controller is wrong, sysdev is correct. Indeed, looks so. In most cases, this doesn't matter since both point to the same device object. In some cases like xhci-plat HCD, they differ. And sysdev might be a better choice from the consistency POV. But this brought an interesting question, too. eg. USB chipidea HCD uses platform devices for both controller and sysdev, and I couldn't find any DMA mask setup. So, no matter what to use, the uwc driver would be broken on this... Maybe it's just not covered. > But maybe ask GregKH? To be certain, better to involve with USB people, yeah. thanks, Takashi
Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip
On Fri, Feb 05, 2021 at 12:50:42AM +0100, Lino Sanfilippo wrote:
> From: Lino Sanfilippo
>
> The following sequence of operations results in a refcount warning:
>
> 1. Open device /dev/tpmrm
> 2. Remove module tpm_tis_spi
> 3. Write a TPM command to the file descriptor opened at step 1.
>
> WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
> refcount_t: addition on 0; use-after-free.
> Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
> sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
> brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
> raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
> snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
> CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
> Hardware name: BCM2711
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xc4/0xd8)
> [] (dump_stack) from [] (__warn+0x104/0x108)
> [] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)
> [] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4)
> [] (kobject_get) from [] (tpm_try_get_ops+0x14/0x54 [tpm])
> [] (tpm_try_get_ops [tpm]) from []
> (tpm_common_write+0x38/0x60 [tpm])
> [] (tpm_common_write [tpm]) from [] (vfs_write+0xc4/0x3c0)
> [] (vfs_write) from [] (ksys_write+0x58/0xcc)
> [] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)
> Exception stack(0xc226bfa8 to 0xc226bff0)
> bfa0: 000105b4 0003 beafe664 0014
> bfc0: 000105b4 000103f8 0004 b6f9c000 beafe684
> bfe0: 006c beafe648 0001056c b6eb6944
>
> The reason for this warning is the attempt to get the chip->dev reference
> in tpm_common_write() although the reference counter is already zero.
> Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the
> extra reference used to prevent a premature zero counter is never taken,
> because the required TPM_CHIP_FLAG_TPM2 flag is never set.
>
> Fix this by removing the flag condition.
>
> Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
> already introduced function tpm_devs_release() to release the extra
> reference but did not implement the required put on chip->devs that results
> in the call of this function.
Seems wonky, the devs is just supposed to be a side thing, nothing
should be using it as a primary reference count for a tpm.
The bug here is only that tpm_common_open() did not get a kref on the
chip before putting it in priv and linking it to the fd. See the
comment before tpm_try_get_ops() indicating the caller must already
have taken care to ensure the chip is valid.
This should be all you need to fix the oops:
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 1784530b8387bb..1b738dca7fffb5 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -105,6 +105,7 @@ static void tpm_timeout_work(struct work_struct *work)
void tpm_common_open(struct file *file, struct tpm_chip *chip,
struct file_priv *priv, struct tpm_space *space)
{
+ get_device(>chip.dev);
priv->chip = chip;
priv->space = space;
priv->response_read = true;
@@ -261,6 +262,7 @@ void tpm_common_release(struct file *file, struct file_priv
*priv)
flush_work(>timeout_work);
file->private_data = NULL;
priv->response_length = 0;
+ put_device(>dev);
}
int __init tpm_dev_common_init(void)
> Fix this also by installing an action handler that puts chip->devs as soon
> as the chip is unregistered.
>
> Fixes: fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
> Fixes: 8979b02aaf1d ("tpm: Fix reference count to main device")
> Signed-off-by: Lino Sanfilippo
> drivers/char/tpm/tpm-chip.c | 18 +++---
> drivers/char/tpm/tpm_ftpm_tee.c | 2 ++
> drivers/char/tpm/tpm_vtpm_proxy.c | 1 +
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index ddaeceb..3ace199 100644
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -360,8 +360,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
>* while cdevs is in use. The corresponding put
>* is in the tpm_devs_release (TPM2 only)
>*/
> - if (chip->flags & TPM_CHIP_FLAG_TPM2)
> - get_device(>dev);
> + get_device(>dev);
>
> if (chip->dev_num == 0)
> chip->dev.devt = MKDEV(MISC_MAJOR, TPM_MINOR);
> @@ -422,8 +421,21 @@ struct tpm_chip *tpmm_chip_alloc(struct device *pdev,
> rc = devm_add_action_or_reset(pdev,
> (void (*)(void *)) put_device,
> >dev);
> - if (rc)
> + if (rc) {
> + put_device(>devs);
> return ERR_PTR(rc);
This isn't right read what 'or_reset' does
Jason
Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson wrote: > > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko > wrote: > > > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko > > wrote: > > >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > > > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > > > immutable tag I provided. I think they can pull and resolve conflicts > > > themselves. Alternatively it would be easy to resolve by Linus by > > > removing Kconfig lines along with mentioned files, > > > > Patrik, I have sent a PR again, so you may consider pulling it, thanks! > > Daniel, is this something you can pull into drm or ask one of the > drm-misc maintainers to do? We've already created the conflict, and my understanding is that Linus wants to have visibility into conflict-y stuff and doesn't mind at all resolving conflicts. Hence for 5.12 I think we're fine as-is. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
