[PATCH v6 2/4] block: add blk_interposer
blk_interposer allows to intercept bio requests, remap bio
to another devices or add new bios.
Signed-off-by: Sergei Shtepa
---
block/bio.c | 2 +
block/blk-core.c | 36 +++
block/genhd.c | 93 +++
include/linux/blk_types.h | 4 ++
include/linux/blkdev.h| 17 +++
5 files changed, 152 insertions(+)
diff --git a/block/bio.c b/block/bio.c
index a1c4d2900c7a..0bfbf06475ee 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -640,6 +640,8 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
bio_set_flag(bio, BIO_THROTTLED);
if (bio_flagged(bio_src, BIO_REMAPPED))
bio_set_flag(bio, BIO_REMAPPED);
+ if (bio_flagged(bio_src, BIO_INTERPOSED))
+ bio_set_flag(bio, BIO_INTERPOSED);
bio->bi_opf = bio_src->bi_opf;
bio->bi_ioprio = bio_src->bi_ioprio;
bio->bi_write_hint = bio_src->bi_write_hint;
diff --git a/block/blk-core.c b/block/blk-core.c
index fc60ff208497..e749507cadd3 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1018,6 +1018,34 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)
return ret;
}
+static blk_qc_t __submit_bio_interposed(struct bio *bio)
+{
+ struct bio_list bio_list[2] = { };
+ blk_qc_t ret = BLK_QC_T_NONE;
+
+ current->bio_list = bio_list;
+ if (likely(bio_queue_enter(bio) == 0)) {
+ struct block_device *bdev = bio->bi_bdev;
+
+ if (likely(bdev_has_interposer(bdev))) {
+ bio_set_flag(bio, BIO_INTERPOSED);
+ bdev->bd_interposer->ip_submit_bio(bio);
+ } else {
+ /* interposer was removed */
+ bio_list_add(>bio_list[0], bio);
+ }
+
+ blk_queue_exit(bdev->bd_disk->queue);
+ }
+ current->bio_list = NULL;
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1043,6 +1071,14 @@ blk_qc_t submit_bio_noacct(struct bio *bio)
return BLK_QC_T_NONE;
}
+ /*
+* Checking the BIO_INTERPOSED flag is necessary so that the bio
+* created by the bdev_interposer do not get to it for processing.
+*/
+ if (bdev_has_interposer(bio->bi_bdev) &&
+ !bio_flagged(bio, BIO_INTERPOSED))
+ return __submit_bio_interposed(bio);
+
if (!bio->bi_bdev->bd_disk->fops->submit_bio)
return __submit_bio_noacct_mq(bio);
return __submit_bio_noacct(bio);
diff --git a/block/genhd.c b/block/genhd.c
index fcc530164b5a..1ae8516643c8 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -30,6 +30,11 @@
static struct kobject *block_depr;
DECLARE_RWSEM(bdev_lookup_sem);
+/*
+ * Prevents different block-layer interposers from attaching or detaching
+ * to the block device at the same time.
+ */
+DEFINE_MUTEX(bdev_interposer_attach_lock);
/* for extended dynamic devt allocation, currently only one major is used */
#define NR_EXT_DEVT(1 << MINORBITS)
@@ -1941,3 +1946,91 @@ static void disk_release_events(struct gendisk *disk)
WARN_ON_ONCE(disk->ev && disk->ev->block != 1);
kfree(disk->ev);
}
+
+/**
+ * bdev_interposer_attach - Attach interposer to block device
+ * @bdev: target block device
+ * @interposer: block device interposer
+ * @ip_submit_bio: hook for submit_bio()
+ *
+ * Returns:
+ * -EINVAL if @interposer is NULL.
+ * -EPERM if queue is not frozen.
+ * -EBUSY if the block device already has @interposer.
+ * -EALREADY if the block device already has @interposer with same
callback.
+ * -ENODEV if the block device cannot be referenced.
+ *
+ * Disk must be frozen by blk_mq_freeze_queue().
+ */
+int bdev_interposer_attach(struct block_device *bdev, struct bdev_interposer
*interposer,
+ const ip_submit_bio_t ip_submit_bio)
+{
+ int ret = 0;
+
+ if (WARN_ON(!interposer))
+ return -EINVAL;
+
+ if (!blk_mq_is_queue_frozen(bdev->bd_disk->queue))
+ return -EPERM;
+
+ mutex_lock(_interposer_attach_lock);
+ if (bdev_has_interposer(bdev)) {
+ if (bdev->bd_interposer->ip_submit_bio == ip_submit_bio)
+ ret = -EALREADY;
+ else
+ ret = -EBUSY;
+ goto out;
+ }
+
+ interposer->ip_submit_bio = ip_submit_bio;
+
+ interposer->bdev = bdgrab(bdev);
+ if (!interposer->bdev) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ bdev->bd_interposer = interposer;
+out:
+ mutex_unlock(_interposer_attach_lock);
+
+ return
Re: [PATCH] SoC: codecs: fix platform_no_drv_owner.cocci warnings
On Wed, Mar 03, 2021 at 05:08:01PM +0800, Yang Li wrote: > ./sound/soc/codecs/lpass-rx-macro.c:3588:3-8: No need to set .owner here. > The core will do it. Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone. signature.asc Description: PGP signature
[PATCH] iio: accel: mma8452: convert to regmap
It will be easier to configure various device registers.
No functional change.
Signed-off-by: Sean Nyekjaer
---
drivers/iio/accel/mma8452.c | 291 +++-
1 file changed, 156 insertions(+), 135 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 33f0c419d8ff..fc29a6e16428 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define MMA8452_STATUS 0x00
#define MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
@@ -102,7 +103,8 @@
#define MMA8452_AUTO_SUSPEND_DELAY_MS 2000
struct mma8452_data {
- struct i2c_client *client;
+ struct regmap *regmap;
+ struct device *dev;
struct mutex lock;
u8 ctrl_reg1;
u8 data_cfg;
@@ -163,6 +165,11 @@ static const struct mma8452_event_regs trans_ev_regs = {
.ev_count = MMA8452_TRANSIENT_COUNT,
};
+static const struct regmap_config mma8452_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
/**
* struct mma_chip_info - chip specific data
* @chip_id: WHO_AM_I register's value
@@ -194,13 +201,14 @@ enum {
static int mma8452_drdy(struct mma8452_data *data)
{
int tries = 150;
+ unsigned int reg;
while (tries-- > 0) {
- int ret = i2c_smbus_read_byte_data(data->client,
- MMA8452_STATUS);
+ int ret = regmap_read(data->regmap, MMA8452_STATUS, );
if (ret < 0)
return ret;
- if ((ret & MMA8452_STATUS_DRDY) == MMA8452_STATUS_DRDY)
+
+ if ((reg & MMA8452_STATUS_DRDY) == MMA8452_STATUS_DRDY)
return 0;
if (data->sleep_val <= 20)
@@ -210,28 +218,28 @@ static int mma8452_drdy(struct mma8452_data *data)
msleep(20);
}
- dev_err(>client->dev, "data not ready\n");
+ dev_err(data->dev, "data not ready\n");
return -EIO;
}
-static int mma8452_set_runtime_pm_state(struct i2c_client *client, bool on)
+static int mma8452_set_runtime_pm_state(struct device *dev, bool on)
{
#ifdef CONFIG_PM
int ret;
if (on) {
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_get_sync(dev);
} else {
- pm_runtime_mark_last_busy(>dev);
- ret = pm_runtime_put_autosuspend(>dev);
+ pm_runtime_mark_last_busy(dev);
+ ret = pm_runtime_put_autosuspend(dev);
}
if (ret < 0) {
- dev_err(>dev,
+ dev_err(dev,
"failed to change power state to %d\n", on);
if (on)
- pm_runtime_put_noidle(>dev);
+ pm_runtime_put_noidle(dev);
return ret;
}
@@ -247,14 +255,17 @@ static int mma8452_read(struct mma8452_data *data, __be16
buf[3])
if (ret < 0)
return ret;
- ret = mma8452_set_runtime_pm_state(data->client, true);
+ ret = mma8452_set_runtime_pm_state(data->dev, true);
if (ret)
return ret;
- ret = i2c_smbus_read_i2c_block_data(data->client, MMA8452_OUT_X,
- 3 * sizeof(__be16), (u8 *)buf);
+ ret = regmap_bulk_read(data->regmap, MMA8452_OUT_X, (u8 *)buf, 3 *
sizeof(__be16));
+ if (ret < 0) {
+ dev_err(data->dev, "failed to read axes\n");
+ return ret;
+ }
- ret = mma8452_set_runtime_pm_state(data->client, false);
+ ret = mma8452_set_runtime_pm_state(data->dev, false);
return ret;
}
@@ -358,12 +369,12 @@ static const u16 mma8452_os_ratio[4][8] = {
static int mma8452_get_power_mode(struct mma8452_data *data)
{
- int reg;
+ int ret;
+ unsigned int reg;
- reg = i2c_smbus_read_byte_data(data->client,
- MMA8452_CTRL_REG2);
- if (reg < 0)
- return reg;
+ ret = regmap_read(data->regmap, MMA8452_CTRL_REG2, );
+ if (ret < 0)
+ return ret;
return ((reg & MMA8452_CTRL_REG2_MODS_MASK) >>
MMA8452_CTRL_REG2_MODS_SHIFT);
@@ -468,8 +479,9 @@ static int mma8452_get_hp_filter_index(struct mma8452_data
*data,
static int mma8452_read_hp_filter(struct mma8452_data *data, int *hz, int *uHz)
{
int j, i, ret;
+ unsigned int reg;
- ret = i2c_smbus_read_byte_data(data->client, MMA8452_HP_FILTER_CUTOFF);
+ ret = regmap_read(data->regmap, MMA8452_HP_FILTER_CUTOFF, );
if (ret < 0)
return ret;
@@ -479,8 +491,8 @@ static int mma8452_read_hp_filter(struct mma8452_data
*data, int *hz, int *uHz)
return j;
ret &= MMA8452_HP_FILTER_CUTOFF_SEL_MASK;
- *hz =
Re: [PATCH/v4] bpf: add bpf_skb_adjust_room flag BPF_F_ADJ_ROOM_ENCAP_L2_ETH
Thanks Cong!
Thanks to your suggestion, I try to add a simple test case to test_tc_tunnel.
It works
for me :)
Thanks for your review.
> 2021年3月3日 下午8:33，Xuesen Huang 写道：
>
> From: Xuesen Huang
>
> bpf_skb_adjust_room sets the inner_protocol as skb->protocol for packets
> encapsulation. But that is not appropriate when pushing Ethernet header.
>
> Add an option to further specify encap L2 type and set the inner_protocol
> as ETH_P_TEB.
>
> Update test_tc_tunnel to verify adding vxlan encapsulation works with
> this flag.
>
> Suggested-by: Willem de Bruijn
> Signed-off-by: Xuesen Huang
> Signed-off-by: Zhiyong Cheng
> Signed-off-by: Li Wang
> ---
> include/uapi/linux/bpf.h | 5 +
> net/core/filter.c | 11 ++-
> tools/include/uapi/linux/bpf.h | 5 +
> tools/testing/selftests/bpf/progs/test_tc_tunnel.c | 107 ++---
> tools/testing/selftests/bpf/test_tc_tunnel.sh | 15 ++-
> 5 files changed, 124 insertions(+), 19 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 77d7c1b..d791596 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1751,6 +1751,10 @@ struct bpf_stack_build_id {
> * Use with ENCAP_L3/L4 flags to further specify the tunnel
> * type; *len* is the length of the inner MAC header.
> *
> + * * **BPF_F_ADJ_ROOM_ENCAP_L2_ETH**:
> + * Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the
> + * L2 type as Ethernet.
> + *
> *A call to this helper is susceptible to change the underlying
> *packet buffer. Therefore, at load time, all checks on pointers
> *previously done by the verifier are invalidated and must be
> @@ -4088,6 +4092,7 @@ enum {
> BPF_F_ADJ_ROOM_ENCAP_L4_GRE = (1ULL << 3),
> BPF_F_ADJ_ROOM_ENCAP_L4_UDP = (1ULL << 4),
> BPF_F_ADJ_ROOM_NO_CSUM_RESET= (1ULL << 5),
> + BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
> };
>
> enum {
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 255aeee..8d1fb61 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -3412,6 +3412,7 @@ static u32 bpf_skb_net_base_len(const struct sk_buff
> *skb)
>BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
>BPF_F_ADJ_ROOM_ENCAP_L4_GRE | \
>BPF_F_ADJ_ROOM_ENCAP_L4_UDP | \
> + BPF_F_ADJ_ROOM_ENCAP_L2_ETH | \
>BPF_F_ADJ_ROOM_ENCAP_L2( \
> BPF_ADJ_ROOM_ENCAP_L2_MASK))
>
> @@ -3448,6 +3449,10 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32
> off, u32 len_diff,
> flags & BPF_F_ADJ_ROOM_ENCAP_L4_UDP)
> return -EINVAL;
>
> + if (flags & BPF_F_ADJ_ROOM_ENCAP_L2_ETH &&
> + inner_mac_len < ETH_HLEN)
> + return -EINVAL;
> +
> if (skb->encapsulation)
> return -EALREADY;
>
> @@ -3466,7 +3471,11 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32
> off, u32 len_diff,
> skb->inner_mac_header = inner_net - inner_mac_len;
> skb->inner_network_header = inner_net;
> skb->inner_transport_header = inner_trans;
> - skb_set_inner_protocol(skb, skb->protocol);
> +
> + if (flags & BPF_F_ADJ_ROOM_ENCAP_L2_ETH)
> + skb_set_inner_protocol(skb, htons(ETH_P_TEB));
> + else
> + skb_set_inner_protocol(skb, skb->protocol);
>
> skb->encapsulation = 1;
> skb_set_network_header(skb, mac_len);
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 77d7c1b..d791596 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -1751,6 +1751,10 @@ struct bpf_stack_build_id {
> * Use with ENCAP_L3/L4 flags to further specify the tunnel
> * type; *len* is the length of the inner MAC header.
> *
> + * * **BPF_F_ADJ_ROOM_ENCAP_L2_ETH**:
> + * Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the
> + * L2 type as Ethernet.
> + *
> *A call to this helper is susceptible to change the underlying
> *packet buffer. Therefore, at load time, all checks on pointers
> *previously done by the verifier are invalidated and must be
> @@ -4088,6 +4092,7 @@ enum {
> BPF_F_ADJ_ROOM_ENCAP_L4_GRE = (1ULL << 3),
> BPF_F_ADJ_ROOM_ENCAP_L4_UDP = (1ULL << 4),
> BPF_F_ADJ_ROOM_NO_CSUM_RESET= (1ULL << 5),
> + BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
> };
>
> enum {
> diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
>
Re: Need some help on "Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2"
Hi, resending this once again, hoping it wouldn't contain any HTML and wouldn't be filtered by LKML. 03.03.2021 13:11, Nikolai Kostrigin пишет: > Hi, > > 25.02.2021 12:38, Wolfram Sang пишет: >> Hi, >> >>> I had a preliminary discussion with Benjamin Tissoires and according to >>> our agreement I repost it for wider audience. >>> Blacklisting the device was decided to be a bad idea. >>> But actually I managed to get touchpad totally operational via SMBus >>> using a following hack: >>> >>> providing a parameter to i2c_i801 driver: >>> >>> modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer). >> So, from an I2C perspective, there are two things to mention here: >> >> a) I am in the process of extending the I2C core to allow block >> transfers > 32 byte. This is a slow process, though, because we need to >> pay attention to not break userspace ABI. If this is done *and* the i801 >> driver supports length > 32 bytes, too, then it would work natively. If >> the i801 can do this, this is a question for Jean Delvare. >> >> b) I don't know Elantech HW but there are devices out there which allow >> configuration for the block size. Something like a bit specifying if >> block transfers > 32 are allowed. Or the SMBus version to support. Block >> transfers > 32 are SMBus 3.0+ only. If your HW does not have that, >> disabling SMBus is an option, too. Disabling it in the i801 driver is >> too much of a hammer, I'd say. >> >> Hope this helps! Happy hacking, >> >>Wolfram > Thank you for the information, Wolfram! > > Finally it turned out that the solution was near me from the very > beginning, but I failed to check mainline code at that moment (which is > now 5.11). > Happily Jingle Wu has pointed me to a couple of patches of his > (co-authored by Dmitry Torokhov): > > https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next=056115daede8d01f71732bc7d778fb85acee8eb6 > > https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next=e4c9062717feda88900b566463228d1c4910af6d > > I applied those to 5.10.17 and trackpoint works like a charm. > So I guess theese patches are worth being backported to the longterm > 5.10 branch. > I'm really sorry for the noise. > -- Best regards, Nikolai Kostrigin
[PATCH V2 0/2] Add virtual hardware module
This patchset adds support for emulating virtual hardware with VKMS. The virtual hardware mode can be enabled by using the following command while loading the module: sudo modprobe vkms enable_virtual_hw=1 The first patch adds virtual hardware support as a module option. The second patch adds new atomic helper functions for the virtual mode and modifies the existing atomic helpers for usage by the vblank mode This gives us two sets of drm_crtc_helper_funcs struct for both modes, making the code flow cleaner and easier to debug. This patchset has been tested with the igt tests, kms_writeback, kms_atomic, kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for subtests related to crc reads and skips tests that rely on vertical blanking. This patchset must be tested after incorporating the igt-tests patch: https://lists.freedesktop.org/archives/igt-dev/2021-February/029355.html . Sumera Priyadarsini (2): drm/vkms: Add support for virtual hardware mode drm/vkms: Add crtc atomic helper functions for virtual mode drivers/gpu/drm/vkms/vkms_composer.c | 88 +--- drivers/gpu/drm/vkms/vkms_crtc.c | 45 ++ drivers/gpu/drm/vkms/vkms_drv.c | 18 -- drivers/gpu/drm/vkms/vkms_drv.h | 4 ++ 4 files changed, 106 insertions(+), 49 deletions(-) -- 2.25.1
Re: [PATCH 1/2] mm: disable LRU pagevec during the migration temporarily
On Tue 02-03-21 13:09:48, Minchan Kim wrote:
> LRU pagevec holds refcount of pages until the pagevec are drained.
> It could prevent migration since the refcount of the page is greater
> than the expection in migration logic. To mitigate the issue,
> callers of migrate_pages drains LRU pagevec via migrate_prep or
> lru_add_drain_all before migrate_pages call.
>
> However, it's not enough because pages coming into pagevec after the
> draining call still could stay at the pagevec so it could keep
> preventing page migration. Since some callers of migrate_pages have
> retrial logic with LRU draining, the page would migrate at next trail
> but it is still fragile in that it doesn't close the fundamental race
> between upcoming LRU pages into pagvec and migration so the migration
> failure could cause contiguous memory allocation failure in the end.
>
> To close the race, this patch disables lru caches(i.e, pagevec)
> during ongoing migration until migrate is done.
>
> Since it's really hard to reproduce, I measured how many times
> migrate_pages retried with force mode below debug code.
>
> int migrate_pages(struct list_head *from, new_page_t get_new_page,
> ..
> ..
>
> if (rc && reason == MR_CONTIG_RANGE && pass > 2) {
>printk(KERN_ERR, "pfn 0x%lx reason %d\n", page_to_pfn(page), rc);
>dump_page(page, "fail to migrate");
> }
>
> The test was repeating android apps launching with cma allocation
> in background every five seconds. Total cma allocation count was
> about 500 during the testing. With this patch, the dump_page count
> was reduced from 400 to 30.
Have you seen any improvement on the CMA allocation success rate?
> Signed-off-by: Minchan Kim
> ---
> * from RFC -
> http://lore.kernel.org/linux-mm/20210216170348.1513483-1-minc...@kernel.org
> * use atomic and lru_add_drain_all for strict ordering - mhocko
> * lru_cache_disable/enable - mhocko
>
> fs/block_dev.c | 2 +-
> include/linux/migrate.h | 6 +++--
> include/linux/swap.h| 4 ++-
> mm/compaction.c | 4 +--
> mm/fadvise.c| 2 +-
> mm/gup.c| 2 +-
> mm/khugepaged.c | 2 +-
> mm/ksm.c| 2 +-
> mm/memcontrol.c | 4 +--
> mm/memfd.c | 2 +-
> mm/memory-failure.c | 2 +-
> mm/memory_hotplug.c | 2 +-
> mm/mempolicy.c | 6 +
> mm/migrate.c| 15 ++-
> mm/page_alloc.c | 5 +++-
> mm/swap.c | 55 +++--
> 16 files changed, 85 insertions(+), 30 deletions(-)
The churn seems to be quite big for something that should have been a
very small change. Have you considered not changing lru_add_drain_all
but rather introduce __lru_add_dain_all that would implement the
enforced flushing?
[...]
> +static atomic_t lru_disable_count = ATOMIC_INIT(0);
> +
> +bool lru_cache_disabled(void)
> +{
> + return atomic_read(_disable_count);
> +}
> +
> +void lru_cache_disable(void)
> +{
> + /*
> + * lru_add_drain_all's IPI will make sure no new pages are added
> + * to the pcp lists and drain them all.
> + */
> + atomic_inc(_disable_count);
As already mentioned in the last review. The IPI reference is more
cryptic than useful. I would go with something like this instead
/*
* lru_add_drain_all in the force mode will schedule draining on
* all online CPUs so any calls of lru_cache_disabled wrapped by
* local_lock or preemption disabled would be ordered by that.
* The atomic operation doesn't need to have stronger ordering
* requirements because that is enforece by the scheduling
* guarantees.
*/
> +
> + /*
> + * Clear the LRU lists so pages can be isolated.
> + */
> + lru_add_drain_all(true);
> +}
--
Michal Hocko
SUSE Labs
Re: [PATCH v3] x86/fault: Send a SIGBUS to user process always for hwpoison page access.
On Wed, 3 Mar 2021 20:24:02 +0800 Aili Yao wrote: > On Mon, 1 Mar 2021 11:09:36 -0800 > Andy Lutomirski wrote: > > > > On Mar 1, 2021, at 11:02 AM, Luck, Tony wrote: > > > > > > > > >> > > >> Some programs may use read(2), write(2), etc as ways to check if > > >> memory is valid without getting a signal. They might not want > > >> signals, which means that this feature might need to be configurable. > > > > > > That sounds like an appalling hack. If users need such a mechanism > > > we should create some better way to do that. > > > > > > > Appalling hack or not, it works. So, if we’re going to send a signal to > > user code that looks like it originated from a bina fide architectural > > recoverable fault, it needs to be recoverable. A load from a failed NVDIMM > > page is such a fault. A *kernel* load is not. So we need to distinguish it > > somehow. > > Sorry for my previous mis-understanding, and i have some questions: > if programs use read,write to check if if memory is valid, does it really > want to cover the poison case? > When for such a case, an error is returned, can the program realize it's > hwposion issue not other software error and process correctly? > > if this is the proper action, the original posion flow in current code from > read and write need to change too. > Sorry, another question: When programs use read(2), write(2) as ways to check if memory is valid, does it really want to check if the user page the program provided is valid, not the destination or disk space valid? the patch will not affect this purpose as it's only valid for user page which program provide to write or some syscall similiar parameter. -- Thanks! Aili Yao
[PATCH V2 1/2] drm/vkms: Add support for virtual hardware mode
Add a virtual hardware or vblank-less mode as a module to enable
VKMS to emulate virtual graphic drivers.
Two new functions vkms_composer_common() and vkms_crtc_composer() have
been added. The actual plane composition work has been moved to
vkms_composer_common() which is called by both vkms_composer_worker()
and vkms_crtc_composer(). vkms_crtc_composer() is used in case of
vblank mode and is called directly in the atomic hook in
vkms_atomic_begin(). However, some crc captures still use vblanks
which causes the crc-based igt tests to crash. Currently, I am unsure
about how to approach one-shot implementation of crc reads so I am
still working on that.
The patch is based on Rodrigo Siqueira's
patch(https://patchwork.freedesktop.org/patch/316851/?series=48469=3)
and the ensuing review.
Signed-off-by: Sumera Priyadarsini
Changes in V2:
- Remove spinlock across 'vkms_output->lock' in vkms_crtc.c(Daniel)
- Add vkms_composer_common() (Daniel)
---
drivers/gpu/drm/vkms/vkms_composer.c | 88 +---
drivers/gpu/drm/vkms/vkms_crtc.c | 24 ++--
drivers/gpu/drm/vkms/vkms_drv.c | 18 --
drivers/gpu/drm/vkms/vkms_drv.h | 4 ++
4 files changed, 91 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 66c6842d70db..df5b946f001f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -169,6 +169,44 @@ static int compose_planes(void **vaddr_out,
return 0;
}
+int vkms_composer_common(struct vkms_crtc_state *crtc_state,
+ struct vkms_output *out, bool wb_pending, uint32_t
*crc32)
+{
+ struct vkms_composer *primary_composer = NULL;
+ struct vkms_composer *cursor_composer = NULL;
+ void *vaddr_out = NULL;
+ int ret;
+
+ if (crtc_state->num_active_planes >= 1)
+ primary_composer = crtc_state->active_planes[0]->composer;
+ if (crtc_state->num_active_planes == 2)
+ cursor_composer = crtc_state->active_planes[1]->composer;
+ if (!primary_composer)
+ return -EINVAL;
+ if (wb_pending)
+ vaddr_out = crtc_state->active_writeback;
+
+ ret = compose_planes(_out, primary_composer, cursor_composer);
+ if (ret) {
+ if (ret == -EINVAL && !wb_pending)
+ kfree(vaddr_out);
+ return -EINVAL;
+ }
+
+ *crc32 = compute_crc(vaddr_out, primary_composer);
+
+ if (wb_pending) {
+ drm_writeback_signal_completion(>wb_connector, 0);
+ spin_lock_irq(>composer_lock);
+ crtc_state->wb_pending = false;
+ spin_unlock_irq(>composer_lock);
+ } else {
+ kfree(vaddr_out);
+ }
+
+ return 0;
+}
+
/**
* vkms_composer_worker - ordered work_struct to compute CRC
*
@@ -185,12 +223,9 @@ void vkms_composer_worker(struct work_struct *work)
composer_work);
struct drm_crtc *crtc = crtc_state->base.crtc;
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
- struct vkms_composer *primary_composer = NULL;
- struct vkms_composer *cursor_composer = NULL;
bool crc_pending, wb_pending;
- void *vaddr_out = NULL;
- u32 crc32 = 0;
u64 frame_start, frame_end;
+ u32 crc32 = 0;
int ret;
spin_lock_irq(>composer_lock);
@@ -210,36 +245,9 @@ void vkms_composer_worker(struct work_struct *work)
if (!crc_pending)
return;
- if (crtc_state->num_active_planes >= 1)
- primary_composer = crtc_state->active_planes[0]->composer;
-
- if (crtc_state->num_active_planes == 2)
- cursor_composer = crtc_state->active_planes[1]->composer;
-
- if (!primary_composer)
- return;
-
- if (wb_pending)
- vaddr_out = crtc_state->active_writeback;
-
- ret = compose_planes(_out, primary_composer, cursor_composer);
- if (ret) {
- if (ret == -EINVAL && !wb_pending)
- kfree(vaddr_out);
+ ret = vkms_composer_common(crtc_state, out, crtc_state->wb_pending,
);
+ if (ret == -EINVAL)
return;
- }
-
- crc32 = compute_crc(vaddr_out, primary_composer);
-
- if (wb_pending) {
- drm_writeback_signal_completion(>wb_connector, 0);
- spin_lock_irq(>composer_lock);
- crtc_state->wb_pending = false;
- spin_unlock_irq(>composer_lock);
- } else {
- kfree(vaddr_out);
- }
-
/*
* The worker can fall behind the vblank hrtimer, make sure we catch up.
*/
@@ -247,6 +255,20 @@ void vkms_composer_worker(struct work_struct *work)
drm_crtc_add_crc_entry(crtc, true, frame_start++, );
}
+void vkms_crtc_composer(struct
[RESEND 1/1] arch: arm: mach-at91: pm: Move prototypes to mutually included header
Both the caller and the supplier's source file should have access to
the include file containing the prototypes.
Fixes the following W=1 kernel build warning(s):
drivers/pinctrl/pinctrl-at91.c:1637:6: warning: no previous prototype for
‘at91_pinctrl_gpio_suspend’ [-Wmissing-prototypes]
1637 | void at91_pinctrl_gpio_suspend(void)
| ^
drivers/pinctrl/pinctrl-at91.c:1661:6: warning: no previous prototype for
‘at91_pinctrl_gpio_resume’ [-Wmissing-prototypes]
1661 | void at91_pinctrl_gpio_resume(void)
| ^~~~
Cc: Russell King
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Signed-off-by: Lee Jones
---
arch/arm/mach-at91/pm.c| 19 ---
drivers/pinctrl/pinctrl-at91.c | 2 ++
include/soc/at91/pm.h | 16
3 files changed, 26 insertions(+), 11 deletions(-)
create mode 100644 include/soc/at91/pm.h
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 120f9aa6fff32..90dcdfe3b3d0d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -17,6 +17,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -25,17 +27,6 @@
#include "generic.h"
#include "pm.h"
-/*
- * FIXME: this is needed to communicate between the pinctrl driver and
- * the PM implementation in the machine. Possibly part of the PM
- * implementation should be moved down into the pinctrl driver and get
- * called as part of the generic suspend/resume path.
- */
-#ifdef CONFIG_PINCTRL_AT91
-extern void at91_pinctrl_gpio_suspend(void);
-extern void at91_pinctrl_gpio_resume(void);
-#endif
-
struct at91_soc_pm {
int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
@@ -326,6 +317,12 @@ static void at91_pm_suspend(suspend_state_t state)
static int at91_pm_enter(suspend_state_t state)
{
#ifdef CONFIG_PINCTRL_AT91
+ /*
+* FIXME: this is needed to communicate between the pinctrl driver and
+* the PM implementation in the machine. Possibly part of the PM
+* implementation should be moved down into the pinctrl driver and get
+* called as part of the generic suspend/resume path.
+*/
at91_pinctrl_gpio_suspend();
#endif
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 8003d1bd16953..fc61aaec34cc9 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -23,6 +23,8 @@
/* Since we request GPIOs from ourself */
#include
+#include
+
#include "pinctrl-at91.h"
#include "core.h"
diff --git a/include/soc/at91/pm.h b/include/soc/at91/pm.h
new file mode 100644
index 0..7a41e53a3ffa3
--- /dev/null
+++ b/include/soc/at91/pm.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Atmel Power Management
+ *
+ * Copyright (C) 2020 Atmel
+ *
+ * Author: Lee Jones
+ */
+
+#ifndef __SOC_ATMEL_PM_H
+#define __SOC_ATMEL_PM_H
+
+void at91_pinctrl_gpio_suspend(void);
+void at91_pinctrl_gpio_resume(void);
+
+#endif /* __SOC_ATMEL_PM_H */
--
2.27.0
Re: [PATCH v3 RFC 14/14] mm: speedup page alloc for MPOL_PREFERRED_MANY by adding a NO_SLOWPATH gfp bit
On Wed 03-03-21 20:18:33, Feng Tang wrote: > On Wed, Mar 03, 2021 at 08:07:17PM +0800, Tang, Feng wrote: > > Hi Michal, > > > > On Wed, Mar 03, 2021 at 12:39:57PM +0100, Michal Hocko wrote: > > > On Wed 03-03-21 18:20:58, Feng Tang wrote: > > > > When doing broader test, we noticed allocation slowness in one test > > > > case that malloc memory with size which is slightly bigger than free > > > > memory of targeted nodes, but much less then the total free memory > > > > of system. > > > > > > > > The reason is the code enters the slowpath of __alloc_pages_nodemask(), > > > > which takes quite some time. As alloc_pages_policy() will give it a 2nd > > > > try with NULL nodemask, so there is no need to enter the slowpath for > > > > the first try. Add a new gfp bit to skip the slowpath, so that user > > > > cases > > > > like this can leverage. > > > > > > > > With it, the malloc in such case is much accelerated as it never enters > > > > the slowpath. > > > > > > > > Adding a new gfp_mask bit is generally not liked, and another idea is to > > > > add another nodemask to struct 'alloc_context', so it has 2: > > > > 'preferred-nmask' > > > > and 'fallback-nmask', and they will be tried in turn if not NULL, with > > > > it we can call __alloc_pages_nodemask() only once. > > > > > > Yes, it is very much disliked. Is there any reason why you cannot use > > > GFP_NOWAIT for that purpose? > > > > I did try that at the first place, but it didn't obviously change the > > slowness. > > I assumed the direct claim was still involved as GFP_NOWAIT only impact > > kswapd > > reclaim. I assume you haven't really created gfp mask correctly. What was the exact gfp mask you have used? > > One thing I tried which can fix the slowness is: > > + gfp_mask &= ~(__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM); > > which explicitly clears the 2 kinds of reclaim. And I thought it's too > hacky and didn't mention it in the commit log. Clearing __GFP_DIRECT_RECLAIM would be the right way to achieve GFP_NOWAIT semantic. Why would you want to exclude kswapd as well? -- Michal Hocko SUSE Labs
[PATCH V2 2/2] drm/vkms: Add crtc atomic helper functions for virtual mode
Add a new drm_crtc_helper_funcs struct,
vkms_virtual_crtc_helper_funcs() which holds the atomic helpers
for virtual hardware mode. Change the existing
vkms_crtc_helper_funcs struct to vkms_vblank_crtc_helper_funcs
which holds atomic helpers for the vblank mode.
This patch makes the code flow clearer and easier to test
virtual hardware mode.
Signed-off-by: Sumera Priyadarsini
---
Changes in V2:
- Add atomic helper functions in a separate struct for virtual hardware
mode (Daniel)
---
drivers/gpu/drm/vkms/vkms_crtc.c | 69 ++--
1 file changed, 39 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 6cc8dc23bd5d..7d5562ab5ce6 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -221,48 +221,35 @@ static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
-static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
- struct drm_atomic_state *state)
+static void vkms_vblank_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_atomic_state *state)
{
- struct vkms_device *vkmsdev = drm_device_to_vkms_device(crtc->dev);
-
- if (!vkmsdev->config->virtual_hw)
- drm_crtc_vblank_on(crtc);
+ drm_crtc_vblank_on(crtc);
}
-static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
+static void vkms_vblank_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct vkms_device *vkmsdev = drm_device_to_vkms_device(crtc->dev);
-
- if (!vkmsdev->config->virtual_hw)
- drm_crtc_vblank_off(crtc);
+ drm_crtc_vblank_off(crtc);
}
-static void vkms_crtc_atomic_begin(struct drm_crtc *crtc,
+static void vkms_vblank_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
- struct vkms_device *vkmsdev = drm_device_to_vkms_device(crtc->dev);
/* This lock is held across the atomic commit to block vblank timer
* from scheduling vkms_composer_worker until the composer is updated
*/
- if (!vkmsdev->config->virtual_hw)
- spin_lock_irq(_output->lock);
+ spin_lock_irq(_output->lock);
}
-static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
+static void vkms_vblank_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
- struct vkms_crtc_state *vkms_state = to_vkms_crtc_state(crtc->state);
- struct vkms_device *vkmsdev = drm_device_to_vkms_device(crtc->dev);
-
- if (vkmsdev->config->virtual_hw)
- vkms_crtc_composer(vkms_state);
- if (crtc->state->event && !vkmsdev->config->virtual_hw) {
+ if (crtc->state->event) {
spin_lock(>dev->event_lock);
if (drm_crtc_vblank_get(crtc) != 0)
@@ -277,22 +264,41 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
vkms_output->composer_state = to_vkms_crtc_state(crtc->state);
- if (!vkmsdev->config->virtual_hw)
- spin_unlock_irq(_output->lock);
+ spin_unlock_irq(_output->lock);
}
-static const struct drm_crtc_helper_funcs vkms_crtc_helper_funcs = {
+/*
+ * Crtc functions for virtual hardware/vblankless mode
+ */
+static void vkms_virtual_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_atomic_state *state)
+{
+ struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);
+ struct vkms_crtc_state *vkms_state = to_vkms_crtc_state(crtc->state);
+
+ vkms_crtc_composer(vkms_state);
+
+ vkms_output->composer_state = to_vkms_crtc_state(crtc->state);
+}
+
+static const struct drm_crtc_helper_funcs vkms_vblank_crtc_helper_funcs = {
.atomic_check = vkms_crtc_atomic_check,
- .atomic_begin = vkms_crtc_atomic_begin,
- .atomic_flush = vkms_crtc_atomic_flush,
- .atomic_enable = vkms_crtc_atomic_enable,
- .atomic_disable = vkms_crtc_atomic_disable,
+ .atomic_begin = vkms_vblank_crtc_atomic_begin,
+ .atomic_flush = vkms_vblank_crtc_atomic_flush,
+ .atomic_enable = vkms_vblank_crtc_atomic_enable,
+ .atomic_disable = vkms_vblank_crtc_atomic_disable,
+};
+
+static const struct drm_crtc_helper_funcs vkms_virtual_crtc_helper_funcs = {
+ .atomic_check = vkms_crtc_atomic_check,
+ .atomic_flush = vkms_virtual_crtc_atomic_flush,
};
int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor)
{
struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+ struct vkms_device *vkmsdev =
Re: [PATCH v2 2/2] arm64: dts: fsl: add support for Kontron pitx-imx8m board
Hi Fabio,
Am Di., 2. März 2021 um 15:43 Uhr schrieb Fabio Estevam :
>
> Hi Heiko,
>
> On Mon, Feb 22, 2021 at 11:08 AM Heiko Thiery wrote:
>
> > + reg_usdhc2_vmmc: regulator-v-3v3-sd {
>
> reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
I used the same name as used on imx8mq-evk. Do you think a better name
is the one you proposed?
> > + tpm_reset: tpm-reset {
> > + compatible = "gpio-reset";
>
> I don't see this compatible string documented.
This comes from the linux-imx tree [1]. Nethertheless the reset seems
not to be used by the tpm driver for the infineon chip.
[1]
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/reset/gpio-reset.c?h=imx_5.4.70_2.3.0
So I think I can remove it here.
>
> > + reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> > + reset-delay-us = <2>;
> > + reset-post-delay-ms = <60>;
> > + #reset-cells = <0>;
> > + };
> > +
> > + usb_hub_reset: usb-hub-reset {
> > + compatible = "gpio-reset";
>
> Same here.
Also the usb-hub-reset can be removed.
>
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_fec1>;
> > + phy-mode = "rgmii-id";
> > + phy-handle = <>;
> > + phy-reset-gpios = < 11 GPIO_ACTIVE_LOW>;
>
> This property is deprecated. Please consider using reset-gpios inside
> ethernet-phy instead.
Done
> > + /* TODO: configure audio, as of now just put a placeholder */
> > + wm8904: audio-codec@1a {
> > + compatible = "wlf,wm8904";
> > + reg = <0x1a>;
> > + clocks = < IMX8MQ_CLK_SAI2_ROOT>;
> > + clock-names = "mclk";
> > + clock-frequency = <2400>;
>
> Not a valid property.
The whole node is removed since v3.
> > +/* M.2 B-key slot */
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pcie0>;
> > + disable-gpio = < 29 GPIO_ACTIVE_LOW>;
>
> Not a valid property.
This comes from the linux-imx tree [2]. but in mainline it is not
valid. So I will remove it.
[2]
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/pci/controller/dwc/pci-imx6.c?h=imx_5.4.70_2.3.0#n2436
> > + reset-gpio = < 9 GPIO_ACTIVE_LOW>;
> > + clocks = < IMX8MQ_CLK_PCIE1_ROOT>,
> > +< IMX8MQ_CLK_PCIE1_AUX>,
> > +< IMX8MQ_CLK_PCIE1_PHY>,
> > +<_refclk>;
> > + clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> > + ext_osc = <1>;
>
> Not a valid property.
This comes from the linux-imx tree [3]. but in mainline it is not
valid. So I will remove it.
[3]
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/pci/controller/dwc/pci-imx6.c?h=imx_5.4.70_2.3.0#n2422
> > +/* Intel Ethernet Controller I210/I211 */
> > + {
> > + clocks = < IMX8MQ_CLK_PCIE2_ROOT>,
> > +< IMX8MQ_CLK_PCIE2_AUX>,
> > +< IMX8MQ_CLK_PCIE2_PHY>,
> > +<_refclk>;
> > + clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> > + ext_osc = <1>;
>
> Not a valid property.
same as commented before.
Thank you for the review. I will prepare v4.
--
Heiko
回复: possible deadlock in io_poll_double_wake (2)
发件人: Zhang, Qiang
发送时间: 2021年3月3日 20:15
收件人: Jens Axboe; syzbot; asml.sile...@gmail.com; io-ur...@vger.kernel.org;
linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
syzkaller-b...@googlegroups.com; v...@zeniv.linux.org.uk
主题: 回复: possible deadlock in io_poll_double_wake (2)
发件人: Jens Axboe
发送时间: 2021年3月3日 1:20
收件人: syzbot; asml.sile...@gmail.com; io-ur...@vger.kernel.org;
linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
syzkaller-b...@googlegroups.com; v...@zeniv.linux.org.uk
主题: Re: possible deadlock in io_poll_double_wake (2)
[Please note: This e-mail is from an EXTERNAL e-mail address]
On 2/28/21 9:18 PM, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering
> an issue:
> possible deadlock in io_poll_double_wake
>
>
> WARNING: possible recursive locking detected
> 5.11.0-syzkaller #0 Not tainted
>
> syz-executor.0/10241 is trying to acquire lock:
> 888012e09130 (>sleep){..-.}-{2:2}, at: spin_lock
> include/linux/spinlock.h:354 [inline]
> 888012e09130 (>sleep){..-.}-{2:2}, at:
> io_poll_double_wake+0x25f/0x6a0 fs/io_uring.c:4921
>
> but task is already holding lock:
> 888013b00130 (>sleep){..-.}-{2:2}, at:
> __wake_up_common_lock+0xb4/0x130 kernel/sched/wait.c:137
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(>sleep);
> lock(>sleep);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
>Since the fix is in yet this keeps failing (and I didn't get it), >I looked
>closer at this report. While the names of the locks are the >same, they are
>really two different locks. So let's try this...
>Hello Jens Axboe
Sorry for I make noise, please ignore this information.
>Sorry, I provided the wrong information before.
>I'm not very familiar with io_uring, before we start >vfs_poll again, should
>we set 'poll->head = NULL' ?
>
>diff --git a/fs/io_uring.c b/fs/io_uring.c
>index 42b675939582..cae605c14510 100644
>--- a/fs/io_uring.c
>+++ b/fs/io_uring.c
>@@ -4824,7 +4824,7 @@ static bool io_poll_rewait(struct >io_kiocb *req, struct
>io_poll_iocb *poll)
>
>if (!req->result && !READ_ONCE(poll->canceled)) {
>struct poll_table_struct pt = { ._key = poll->events >};
>-
>+ poll->head = NULL;
>req->result = vfs_poll(req->file, ) & >poll->events;
>}
>Thanks
>Qiang
>
>#syz test: git://git.kernel.dk/linux-block syzbot-test
>
>--
>Jens Axboe
[RESEND 1/1] powerpc: asm: hvconsole: Move 'hvc_vio_init_early's prototype to shared location
Fixes the following W=1 kernel build warning(s): drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for ‘hvc_vio_init_early’ [-Wmissing-prototypes] 385 | void __init hvc_vio_init_early(void) | ^~ Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-...@lists.ozlabs.org Signed-off-by: Lee Jones Acked-by: Michael Ellerman --- arch/powerpc/include/asm/hvconsole.h | 3 +++ arch/powerpc/platforms/pseries/pseries.h | 3 --- arch/powerpc/platforms/pseries/setup.c | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/hvconsole.h b/arch/powerpc/include/asm/hvconsole.h index 999ed5ac90531..ccb2034506f0f 100644 --- a/arch/powerpc/include/asm/hvconsole.h +++ b/arch/powerpc/include/asm/hvconsole.h @@ -24,5 +24,8 @@ extern int hvc_get_chars(uint32_t vtermno, char *buf, int count); extern int hvc_put_chars(uint32_t vtermno, const char *buf, int count); +/* Provided by HVC VIO */ +void hvc_vio_init_early(void); + #endif /* __KERNEL__ */ #endif /* _PPC64_HVCONSOLE_H */ diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h index 4fe48c04c6c20..a13438fca10a8 100644 --- a/arch/powerpc/platforms/pseries/pseries.h +++ b/arch/powerpc/platforms/pseries/pseries.h @@ -43,9 +43,6 @@ extern void pSeries_final_fixup(void); /* Poweron flag used for enabling auto ups restart */ extern unsigned long rtas_poweron_auto; -/* Provided by HVC VIO */ -extern void hvc_vio_init_early(void); - /* Dynamic logical Partitioning/Mobility */ extern void dlpar_free_cc_nodes(struct device_node *); extern void dlpar_free_cc_property(struct property *); diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c index 46e1540abc229..145e3f4c999af 100644 --- a/arch/powerpc/platforms/pseries/setup.c +++ b/arch/powerpc/platforms/pseries/setup.c @@ -71,6 +71,7 @@ #include #include #include +#include #include "pseries.h" #include "../../../../drivers/pci/pci.h" -- 2.27.0
Re: [PATCH] ARM: dts: imx6qdl-wandboard: add scl/sda gpios definitions for i2c bus recovery
On Sun, Jan 31, 2021 at 06:54:46PM +0300, Dima Azarkin wrote: > The i2c bus on imx6qdl-wandboard has intermittent issues where SDA can freeze > on low level at the end of transaction so the bus can no longer work. This > impacts reading of EDID data leading to incorrect TV resolution and no audio. > > This scenario is improved by adding scl/sda gpios definitions to implement the > i2c bus recovery mechanism. > > Signed-off-by: Dima Azarkin Applied, thanks.
[PATCH 10/53] drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field overwritten' issue
Fixes the following W=1 kernel build warning(s):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:59:
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58:
warning: initialized field overwritten [-Woverride-init]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in
expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in
expansion of macro ‘AUX_SF’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note:
in expansion of macro ‘DCE_AUX_MASK_SH_LIST’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10014:58:
note: (near initialization for ‘aux_shift.AUX_SW_AUTOINCREMENT_DISABLE’)
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in
expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE__SHIFT’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in
expansion of macro ‘AUX_SF’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:177:2: note:
in expansion of macro ‘DCE_AUX_MASK_SH_LIST’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56:
warning: initialized field overwritten [-Woverride-init]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in
expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in
expansion of macro ‘AUX_SF’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:181:2: note:
in expansion of macro ‘DCE_AUX_MASK_SH_LIST’
drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_11_2_sh_mask.h:10013:56:
note: (near initialization for ‘aux_mask.AUX_SW_AUTOINCREMENT_DISABLE’)
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:214:16: note: in
expansion of macro ‘AUX_SW_DATA__AUX_SW_AUTOINCREMENT_DISABLE_MASK’
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.h:127:2: note: in
expansion of macro ‘AUX_SF’
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
index 775e24926380e..566b1bddd8cc6 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
@@ -100,7 +100,6 @@ struct dce110_aux_registers {
AUX_SF(AUX_SW_CONTROL, AUX_SW_GO, mask_sh),\
AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\
AUX_SF(AUX_SW_DATA, AUX_SW_DATA_RW, mask_sh),\
- AUX_SF(AUX_SW_DATA, AUX_SW_AUTOINCREMENT_DISABLE, mask_sh),\
AUX_SF(AUX_SW_DATA, AUX_SW_INDEX, mask_sh),\
AUX_SF(AUX_SW_DATA, AUX_SW_DATA, mask_sh),\
AUX_SF(AUX_SW_STATUS, AUX_SW_REPLY_BYTE_COUNT, mask_sh),\
--
2.27.0
Re: [PATCH v3 1/3] ARM: imx7d-remarkable2.dts: Initial device tree for reMarkable2
On Wed, Feb 03, 2021 at 07:03:14PM -0800, Alistair Francis wrote:
> The reMarkable2 (https://remarkable.com) is an e-ink tablet based on
> the imx7d SoC.
>
> This commit is based on the DTS provide by reMarkable but ported to the
> latest kernel (instead of 4.14). I have removed references to
> non-upstream devices and have changed the UART so that the console can
> be accessed without having to open up the device via the OTG pogo pins.
Just out of curiosity, this is a DIY cable or something generally
available from vendor?
>
> Currently the kernel boots, but there is no support for the dispaly,
> WiFi or the power controller chips.
There are still some WiFi related devices. Can we drop all those
untested stuff?
>
> Signed-off-by: Alistair Francis
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx7d-remarkable2.dts | 253
> 2 files changed, 254 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx7d-remarkable2.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 3d1ea0b25168..9608c363b25f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -658,6 +658,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
> imx7d-pico-hobbit.dtb \
> imx7d-pico-nymph.dtb \
> imx7d-pico-pi.dtb \
> + imx7d-remarkable2.dtb \
> imx7d-sbc-imx7.dtb \
> imx7d-sdb.dtb \
> imx7d-sdb-reva.dtb \
> diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts
> b/arch/arm/boot/dts/imx7d-remarkable2.dts
> new file mode 100644
> index ..0aae13f5eed6
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
> @@ -0,0 +1,253 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "imx7d.dtsi"
> +
> +/ {
> + model = "reMarkable 2.0";
> + compatible = "fsl,imx7d-remarkable2", "fsl,imx7d";
The new compatible needs to be documented. Also the compatible doesn't
look right, as this is a device from reMarkable rather than FSL.
Shawn
> +
> + chosen {
> + stdout-path =
> + };
> +
> + memory {
> + reg = <0x8000 0x4000>;
> + };
> +
> + reg_brcm: regulator-brcm {
> + compatible = "regulator-fixed";
> + regulator-name = "brcm_reg";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_brcm_reg>;
> + gpio = < 13 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + startup-delay-us = <150>;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <_wifi>;
> + reset-gpios = < 9 GPIO_ACTIVE_LOW>;
> + clocks = < IMX7D_CLKO2_ROOT_DIV>;
> + clock-names = "ext_clock";
> + };
> +};
> +
> + {
> + assigned-clocks = < IMX7D_CLKO2_ROOT_SRC>,
> + < IMX7D_CLKO2_ROOT_DIV>;
> + assigned-clock-parents = < IMX7D_CKIL>;
> + assigned-clock-rates = <0>, <32768>;
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> +_apbh {
> + status = "disabled";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart1>;
> + assigned-clocks = < IMX7D_UART1_ROOT_SRC>;
> + assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart6>;
> + assigned-clocks = < IMX7D_UART6_ROOT_SRC>;
> + assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
> + status = "okay";
> +};
> +
> + {
> + srp-disable;
> + hnp-disable;
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default", "state_100mhz", "sleep";
> + pinctrl-0 = <_usdhc2>;
> + pinctrl-1 = <_usdhc2_100mhz>;
> + pinctrl-2 = <_usdhc2>;
> + mmc-pwrseq = <_pwrseq>;
> + vmmc-supply = <_brcm>;
> + bus-width = <4>;
> + non-removable;
> + keep-power-in-suspend;
> + cap-power-off-card;
> + status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + };
> +};
> +
> + {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> + pinctrl-0 = <_usdhc3>;
> + pinctrl-1 = <_usdhc3_100mhz>;
> + pinctrl-2 = <_usdhc3_200mhz>;
> + pinctrl-3 = <_usdhc3>;
> + assigned-clocks = < IMX7D_USDHC3_ROOT_CLK>;
> + assigned-clock-rates = <4>;
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_wdog>;
> +
[PATCH 01/53] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
parameter or member 'init' not described in 'init_reserved'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function
parameter or member 'init' not described in 'init_done'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function
parameter or member 'init' not described in 'init_io_restrict_prog'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function
parameter or member 'init' not described in 'init_repeat'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function
parameter or member 'init' not described in 'init_io_restrict_pll'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function
parameter or member 'init' not described in 'init_end_repeat'
NB: Trimmed for brevity (lots of these!)
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 204 ++
1 file changed, 68 insertions(+), 136 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2a..5a91dc4e5c8ec 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -575,9 +575,8 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
* init opcode handlers
*/
-/**
+/*
* init_reserved - stub for various unknown/unused single-byte opcodes
- *
*/
static void
init_reserved(struct nvbios_init *init)
@@ -602,9 +601,8 @@ init_reserved(struct nvbios_init *init)
init->offset += length;
}
-/**
+/*
* INIT_DONE - opcode 0x71
- *
*/
static void
init_done(struct nvbios_init *init)
@@ -613,9 +611,8 @@ init_done(struct nvbios_init *init)
init->offset = 0x;
}
-/**
+/*
* INIT_IO_RESTRICT_PROG - opcode 0x32
- *
*/
static void
init_io_restrict_prog(struct nvbios_init *init)
@@ -650,9 +647,8 @@ init_io_restrict_prog(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_REPEAT - opcode 0x33
- *
*/
static void
init_repeat(struct nvbios_init *init)
@@ -676,9 +672,8 @@ init_repeat(struct nvbios_init *init)
init->repeat = repeat;
}
-/**
+/*
* INIT_IO_RESTRICT_PLL - opcode 0x34
- *
*/
static void
init_io_restrict_pll(struct nvbios_init *init)
@@ -716,9 +711,8 @@ init_io_restrict_pll(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_END_REPEAT - opcode 0x36
- *
*/
static void
init_end_repeat(struct nvbios_init *init)
@@ -732,9 +726,8 @@ init_end_repeat(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_COPY - opcode 0x37
- *
*/
static void
init_copy(struct nvbios_init *init)
@@ -759,9 +752,8 @@ init_copy(struct nvbios_init *init)
init_wrvgai(init, port, index, data);
}
-/**
+/*
* INIT_NOT - opcode 0x38
- *
*/
static void
init_not(struct nvbios_init *init)
@@ -771,9 +763,8 @@ init_not(struct nvbios_init *init)
init_exec_inv(init);
}
-/**
+/*
* INIT_IO_FLAG_CONDITION - opcode 0x39
- *
*/
static void
init_io_flag_condition(struct nvbios_init *init)
@@ -788,9 +779,8 @@ init_io_flag_condition(struct nvbios_init *init)
init_exec_set(init, false);
}
-/**
+/*
* INIT_GENERIC_CONDITION - opcode 0x3a
- *
*/
static void
init_generic_condition(struct nvbios_init *init)
@@ -840,9 +830,8 @@ init_generic_condition(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_MASK_OR - opcode 0x3b
- *
*/
static void
init_io_mask_or(struct nvbios_init *init)
@@ -859,9 +848,8 @@ init_io_mask_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
}
-/**
+/*
* INIT_IO_OR - opcode 0x3c
- *
*/
static void
init_io_or(struct nvbios_init *init)
@@ -878,9 +866,8 @@ init_io_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data | (1 << or));
}
-/**
+/*
* INIT_ANDN_REG - opcode 0x47
- *
*/
static void
init_andn_reg(struct nvbios_init *init)
@@ -895,9 +882,8 @@ init_andn_reg(struct nvbios_init *init)
init_mask(init, reg, mask, 0);
}
-/**
+/*
* INIT_OR_REG - opcode 0x48
- *
*/
static void
init_or_reg(struct nvbios_init *init)
@@ -912,9 +898,8 @@ init_or_reg(struct nvbios_init *init)
init_mask(init, reg, 0, mask);
}
-/**
+/*
* INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
- *
*/
static void
init_idx_addr_latched(struct nvbios_init *init)
@@ -942,9 +927,8 @@ init_idx_addr_latched(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_RESTRICT_PLL2 - opcode 0x4a
- *
*/
static void
init_io_restrict_pll2(struct nvbios_init *init)
@@ -977,9 +961,8 @@ init_io_restrict_pll2(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
*
[PATCH 09/53] drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from the stack
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function
‘bw_calcs_init’:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2726:1: warning:
the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 1122 +
1 file changed, 567 insertions(+), 555 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
index 4f0474a3bbcad..53f5c170d9c97 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -2043,707 +2043,719 @@ void bw_calcs_init(struct bw_calcs_dceip *bw_dceip,
struct bw_calcs_vbios *bw_vbios,
struct hw_asic_id asic_id)
{
- struct bw_calcs_dceip dceip = { 0 };
- struct bw_calcs_vbios vbios = { 0 };
+ struct bw_calcs_dceip *dceip;
+ struct bw_calcs_vbios *vbios;
enum bw_calcs_version version = bw_calcs_version_from_asic_id(asic_id);
- dceip.version = version;
+ dceip = kzalloc(sizeof(dceip), GFP_KERNEL);
+ if (!dceip)
+ return;
+
+ vbios = kzalloc(sizeof(vbios), GFP_KERNEL);
+ if (!vbios) {
+ kfree(dceip);
+ return;
+ }
+
+ dceip->version = version;
switch (version) {
case BW_CALCS_VERSION_CARRIZO:
- vbios.memory_type = bw_def_gddr5;
- vbios.dram_channel_width_in_bits = 64;
- vbios.number_of_dram_channels = asic_id.vram_width /
vbios.dram_channel_width_in_bits;
- vbios.number_of_dram_banks = 8;
- vbios.high_yclk = bw_int_to_fixed(1600);
- vbios.mid_yclk = bw_int_to_fixed(1600);
- vbios.low_yclk = bw_frc_to_fixed(6, 100);
- vbios.low_sclk = bw_int_to_fixed(200);
- vbios.mid1_sclk = bw_int_to_fixed(300);
- vbios.mid2_sclk = bw_int_to_fixed(300);
- vbios.mid3_sclk = bw_int_to_fixed(300);
- vbios.mid4_sclk = bw_int_to_fixed(300);
- vbios.mid5_sclk = bw_int_to_fixed(300);
- vbios.mid6_sclk = bw_int_to_fixed(300);
- vbios.high_sclk = bw_frc_to_fixed(62609, 100);
- vbios.low_voltage_max_dispclk = bw_int_to_fixed(352);
- vbios.mid_voltage_max_dispclk = bw_int_to_fixed(467);
- vbios.high_voltage_max_dispclk = bw_int_to_fixed(643);
- vbios.low_voltage_max_phyclk = bw_int_to_fixed(540);
- vbios.mid_voltage_max_phyclk = bw_int_to_fixed(810);
- vbios.high_voltage_max_phyclk = bw_int_to_fixed(810);
- vbios.data_return_bus_width = bw_int_to_fixed(32);
- vbios.trc = bw_int_to_fixed(50);
- vbios.dmifmc_urgent_latency = bw_int_to_fixed(4);
- vbios.stutter_self_refresh_exit_latency = bw_frc_to_fixed(153,
10);
- vbios.stutter_self_refresh_entry_latency = bw_int_to_fixed(0);
- vbios.nbp_state_change_latency = bw_frc_to_fixed(19649, 1000);
- vbios.mcifwrmc_urgent_latency = bw_int_to_fixed(10);
- vbios.scatter_gather_enable = true;
- vbios.down_spread_percentage = bw_frc_to_fixed(5, 10);
- vbios.cursor_width = 32;
- vbios.average_compression_rate = 4;
- vbios.number_of_request_slots_gmc_reserves_for_dmif_per_channel
= 256;
- vbios.blackout_duration = bw_int_to_fixed(0); /* us */
- vbios.maximum_blackout_recovery_time = bw_int_to_fixed(0);
-
-
dceip.max_average_percent_of_ideal_port_bw_display_can_use_in_normal_system_operation
= 100;
-
dceip.max_average_percent_of_ideal_drambw_display_can_use_in_normal_system_operation
= 100;
- dceip.percent_of_ideal_port_bw_received_after_urgent_latency =
100;
- dceip.large_cursor = false;
- dceip.dmif_request_buffer_size = bw_int_to_fixed(768);
- dceip.dmif_pipe_en_fbc_chunk_tracker = false;
- dceip.cursor_max_outstanding_group_num = 1;
- dceip.lines_interleaved_into_lb = 2;
- dceip.chunk_width = 256;
- dceip.number_of_graphics_pipes = 3;
- dceip.number_of_underlay_pipes = 1;
- dceip.low_power_tiling_mode = 0;
- dceip.display_write_back_supported = false;
- dceip.argb_compression_support = false;
- dceip.underlay_vscaler_efficiency6_bit_per_component =
+ vbios->memory_type = bw_def_gddr5;
+
[PATCH 11/53] drm/amd/display/dc/dce80/dce80_resource: Make local functions static
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:527:17:
warning: no previous prototype for ‘dce80_aux_engine_create’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:565:20:
warning: no previous prototype for ‘dce80_i2c_hw_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:581:20:
warning: no previous prototype for ‘dce80_i2c_sw_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:715:22:
warning: no previous prototype for ‘dce80_link_encoder_create’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:754:22:
warning: no previous prototype for ‘dce80_clock_source_create’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:778:6:
warning: no previous prototype for ‘dce80_clock_source_destroy’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:868:6:
warning: no previous prototype for ‘dce80_validate_bandwidth’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:913:16:
warning: no previous prototype for ‘dce80_validate_global’
[-Wmissing-prototypes]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Anthony Koo
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../drm/amd/display/dc/dce80/dce80_resource.c| 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
index 612450f992782..725d92e40cd30 100644
--- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
@@ -526,7 +526,7 @@ static struct output_pixel_processor *dce80_opp_create(
return >base;
}
-struct dce_aux *dce80_aux_engine_create(
+static struct dce_aux *dce80_aux_engine_create(
struct dc_context *ctx,
uint32_t inst)
{
@@ -564,7 +564,7 @@ static const struct dce_i2c_mask i2c_masks = {
I2C_COMMON_MASK_SH_LIST_DCE_COMMON_BASE(_MASK)
};
-struct dce_i2c_hw *dce80_i2c_hw_create(
+static struct dce_i2c_hw *dce80_i2c_hw_create(
struct dc_context *ctx,
uint32_t inst)
{
@@ -580,7 +580,7 @@ struct dce_i2c_hw *dce80_i2c_hw_create(
return dce_i2c_hw;
}
-struct dce_i2c_sw *dce80_i2c_sw_create(
+static struct dce_i2c_sw *dce80_i2c_sw_create(
struct dc_context *ctx)
{
struct dce_i2c_sw *dce_i2c_sw =
@@ -714,7 +714,7 @@ static const struct encoder_feature_support
link_enc_feature = {
.flags.bits.IS_TPS3_CAPABLE = true
};
-struct link_encoder *dce80_link_encoder_create(
+static struct link_encoder *dce80_link_encoder_create(
const struct encoder_init_data *enc_init_data)
{
struct dce110_link_encoder *enc110 =
@@ -753,7 +753,7 @@ static struct panel_cntl *dce80_panel_cntl_create(const
struct panel_cntl_init_d
return _cntl->base;
}
-struct clock_source *dce80_clock_source_create(
+static struct clock_source *dce80_clock_source_create(
struct dc_context *ctx,
struct dc_bios *bios,
enum clock_source_id id,
@@ -777,7 +777,7 @@ struct clock_source *dce80_clock_source_create(
return NULL;
}
-void dce80_clock_source_destroy(struct clock_source **clk_src)
+static void dce80_clock_source_destroy(struct clock_source **clk_src)
{
kfree(TO_DCE110_CLK_SRC(*clk_src));
*clk_src = NULL;
@@ -867,7 +867,7 @@ static void dce80_resource_destruct(struct
dce110_resource_pool *pool)
}
}
-bool dce80_validate_bandwidth(
+static bool dce80_validate_bandwidth(
struct dc *dc,
struct dc_state *context,
bool fast_validate)
@@ -912,7 +912,7 @@ static bool dce80_validate_surface_sets(
return true;
}
-enum dc_status dce80_validate_global(
+static enum dc_status dce80_validate_global(
struct dc *dc,
struct dc_state *context)
{
--
2.27.0
[PATCH 12/53] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function parameter or member 'gr' not described in 'gf100_gr_wait_idle' Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c index 397ff4fe9df89..69e6008f99196 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c @@ -982,7 +982,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr) } } -/** +/* * Wait until GR goes idle. GR is considered idle if it is disabled by the * MC (0x200) register, or GR is not busy and a context switch is not in * progress. -- 2.27.0
[PATCH] scsi: target: vhost-scsi: remove redundant initialization of variable ret
From: Colin Ian King
The variable ret is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/vhost/scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index d16c04dcc144..9129ab8187fd 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -2465,7 +2465,7 @@ static const struct target_core_fabric_ops vhost_scsi_ops
= {
static int __init vhost_scsi_init(void)
{
- int ret = -ENOMEM;
+ int ret;
pr_debug("TCM_VHOST fabric module %s on %s/%s"
" on "UTS_RELEASE"\n", VHOST_SCSI_VERSION, utsname()->sysname,
--
2.30.0
[PATCH 06/53] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
parameter or member 'coef' not described in 'gk20a_volt_get_cvb_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 'temp' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 's_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 't_scale' not described in 'gk20a_volt_get_cvb_t_voltage'
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:69: warning: Function
parameter or member 'coef' not described in 'gk20a_volt_get_cvb_t_voltage'
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
index 8c2faa9645111..ccac88da88648 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
@@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
/* 852 */ { 1608418, -21643, -269, 0,763, -48},
};
-/**
+/*
* cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
*/
static inline int
@@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const
struct cvb_coef *coef)
return mv;
}
-/**
+/*
* cvb_t_mv =
* ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
* ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
--
2.27.0
[PATCH 43/53] drm/vmwgfx/vmwgfx_stdu: Add some missing param/member descriptions
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:77: warning: Function parameter or member
'pitch' not described in 'vmw_stdu_dirty'
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:125: warning: Function parameter or
member 'content_fb_type' not described in 'vmw_screen_target_display_unit'
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:125: warning: Function parameter or
member 'display_width' not described in 'vmw_screen_target_display_unit'
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:125: warning: Function parameter or
member 'display_height' not described in 'vmw_screen_target_display_unit'
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:125: warning: Function parameter or
member 'cpp' not described in 'vmw_screen_target_display_unit'
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:682: warning: Function parameter or
member 'user_fence_rep' not described in 'vmw_kms_stdu_dma'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-41-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index fbe9778813648..01567534f4fae 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -61,6 +61,7 @@ enum stdu_content_type {
* @bottom: Bottom side of bounding box.
* @fb_left: Left side of the framebuffer/content bounding box
* @fb_top: Top of the framebuffer/content bounding box
+ * @pitch: framebuffer pitch (stride)
* @buf: buffer object when DMA-ing between buffer and screen targets.
* @sid: Surface ID when copying between surface and screen targets.
*/
@@ -109,8 +110,11 @@ struct vmw_stdu_update_gb_image {
* content_vfbs dimensions, then this is a pointer into the
* corresponding field in content_vfbs. If not, then this
* is a separate buffer to which content_vfbs will blit to.
- * @content_type: content_fb type
- * @defined: true if the current display unit has been initialized
+ * @content_fb_type: content_fb type
+ * @display_width: display width
+ * @display_height: display height
+ * @defined: true if the current display unit has been initialized
+ * @cpp: Bytes per pixel
*/
struct vmw_screen_target_display_unit {
struct vmw_display_unit base;
@@ -652,6 +656,7 @@ static void vmw_stdu_bo_cpu_commit(struct vmw_kms_dirty
*dirty)
* @file_priv: Pointer to a struct drm-file identifying the caller. May be
* set to NULL, but then @user_fence_rep must also be set to NULL.
* @vfb: Pointer to the buffer-object backed framebuffer.
+ * @user_fence_rep: User-space provided structure for fence information.
* @clips: Array of clip rects. Either @clips or @vclips must be NULL.
* @vclips: Alternate array of clip rects. Either @clips or @vclips must
* be NULL.
--
2.27.0
[PATCH 52/53] drm/vmwgfx/vmwgfx_thp: Add description for 'vmw_thp_manager's member 'manager'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_thp.c:21: warning: Function parameter or member 'manager' not described in 'vmw_thp_manager' Cc: VMware Graphics Cc: Roland Scheidegger Cc: Zack Rusin Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-11-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c index e8e79de255cf7..eb63cbe64909d 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c @@ -11,6 +11,7 @@ /** * struct vmw_thp_manager - Range manager implementing huge page alignment * + * @manager: TTM resource manager. * @mm: The underlying range manager. Protected by @lock. * @lock: Manager lock. */ -- 2.27.0
[PATCH 39/53] drm/vmwgfx/vmwgfx_cmdbuf_res: Rename param description and remove another
Also fix a small formatting issue.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:83: warning: Function parameter or
member 'res_type' not described in 'vmw_cmdbuf_res_lookup'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:83: warning: Excess function
parameter 'resource_type' description in 'vmw_cmdbuf_res_lookup'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:161: warning: Excess function
parameter 'man' description in 'vmw_cmdbuf_res_revert'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:330: warning: Cannot understand *
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-36-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 44d858ce4ce7f..92509fbf2fd1d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -69,7 +69,7 @@ struct vmw_cmdbuf_res_manager {
* vmw_cmdbuf_res_lookup - Look up a command buffer resource
*
* @man: Pointer to the command buffer resource manager
- * @resource_type: The resource type, that combined with the user key
+ * @res_type: The resource type, that combined with the user key
* identifies the resource.
* @user_key: The user key.
*
@@ -148,7 +148,6 @@ void vmw_cmdbuf_res_commit(struct list_head *list)
/**
* vmw_cmdbuf_res_revert - Revert a list of command buffer resource actions
*
- * @man: Pointer to the command buffer resource manager
* @list: Caller's list of command buffer resource action
*
* This function reverts a list of command buffer resource
@@ -327,7 +326,6 @@ void vmw_cmdbuf_res_man_destroy(struct
vmw_cmdbuf_res_manager *man)
}
/**
- *
* vmw_cmdbuf_res_man_size - Return the size of a command buffer managed
* resource manager
*
--
2.27.0
[PATCH 46/53] drm/vmwgfx/vmwgfx_so: Add description for 'vmw_view's 'rcu' member
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_so.c:73: warning: Function parameter or member 'rcu' not described in 'vmw_view' Cc: VMware Graphics Cc: Roland Scheidegger Cc: Zack Rusin Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-4-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c index 7369dd86d3a9c..2877c7b43bd78 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c @@ -42,6 +42,7 @@ /** * struct vmw_view - view metadata * + * @rcu: RCU callback head * @res: The struct vmw_resource we derive from * @ctx: Non-refcounted pointer to the context this view belongs to. * @srf: Refcounted pointer to the surface pointed to by this view. -- 2.27.0
[PATCH 47/53] drm/vmwgfx/vmwgfx_binding: Provide some missing param descriptions and remove others
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:340: warning: Function parameter or member 'shader_slot' not described in 'vmw_binding_add' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:340: warning: Function parameter or member 'slot' not described in 'vmw_binding_add' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:376: warning: Function parameter or member 'from' not described in 'vmw_binding_transfer' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:498: warning: Function parameter or member 'to' not described in 'vmw_binding_state_commit' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:498: warning: Excess function parameter 'ctx' description in 'vmw_binding_state_commit' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:498: warning: Excess function parameter 'scrubbed' description in 'vmw_binding_state_commit' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:520: warning: Function parameter or member 'cbs' not described in 'vmw_binding_rebind_all' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:520: warning: Excess function parameter 'ctx' description in 'vmw_binding_rebind_all' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c:795: warning: Function parameter or member 'shader_slot' not described in 'vmw_emit_set_sr' Cc: VMware Graphics Cc: Roland Scheidegger Cc: Zack Rusin Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-5-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c index 180f6dbc9460d..81f525a82b77f 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c @@ -330,6 +330,8 @@ static void vmw_binding_drop(struct vmw_ctx_bindinfo *bi) * * @cbs: Pointer to the context binding state tracker. * @bi: Information about the binding to track. + * @shader_slot: The shader slot of the binding. + * @slot: The slot of the binding. * * Starts tracking the binding in the context binding * state structure @cbs. @@ -367,6 +369,7 @@ void vmw_binding_add_uav_index(struct vmw_ctx_binding_state *cbs, uint32 slot, * vmw_binding_transfer: Transfer a context binding tracking entry. * * @cbs: Pointer to the persistent context binding state tracker. + * @from: Staged binding info built during execbuf * @bi: Information about the binding to track. * */ @@ -484,9 +487,8 @@ void vmw_binding_res_list_scrub(struct list_head *head) /** * vmw_binding_state_commit - Commit staged binding info * - * @ctx: Pointer to context to commit the staged binding info to. + * @to: Staged binding info area to copy into to. * @from: Staged binding info built during execbuf. - * @scrubbed: Transfer only scrubbed bindings. * * Transfers binding info from a temporary structure * (typically used by execbuf) to the persistent @@ -511,7 +513,7 @@ void vmw_binding_state_commit(struct vmw_ctx_binding_state *to, /** * vmw_binding_rebind_all - Rebind all scrubbed bindings of a context * - * @ctx: The context resource + * @cbs: Pointer to the context binding state tracker. * * Walks through the context binding list and rebinds all scrubbed * resources. @@ -789,6 +791,7 @@ static void vmw_collect_dirty_view_ids(struct vmw_ctx_binding_state *cbs, * vmw_binding_emit_set_sr - Issue delayed DX shader resource binding commands * * @cbs: Pointer to the context's struct vmw_ctx_binding_state + * @shader_slot: The shader slot of the binding. */ static int vmw_emit_set_sr(struct vmw_ctx_binding_state *cbs, int shader_slot) -- 2.27.0
[PATCH 35/53] drm/vmwgfx/vmwgfx_bo: Remove superfluous param description and supply another
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:142: warning: Excess function parameter 'pin' description in 'vmw_bo_pin_in_vram_or_gmr' drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:647: warning: Function parameter or member 'p_base' not described in 'vmw_user_bo_alloc' Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-28-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c index 63dbc44eebe0b..ab0844b47d4d7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c @@ -131,7 +131,6 @@ int vmw_bo_pin_in_placement(struct vmw_private *dev_priv, * * @dev_priv: Driver private. * @buf: DMA buffer to move. - * @pin: Pin buffer if true. * @interruptible: Use interruptible wait. * Return: Zero on success, Negative error code on failure. In particular * -ERESTARTSYS if interrupted by a signal @@ -635,6 +634,7 @@ static void vmw_user_bo_ref_obj_release(struct ttm_base_object *base, * @handle: Pointer to where the handle value should be assigned. * @p_vbo: Pointer to where the refcounted struct vmw_buffer_object pointer * should be assigned. + * @p_base: The TTM base object pointer about to be allocated. * Return: Zero on success, negative error code on error. */ int vmw_user_bo_alloc(struct vmw_private *dev_priv, -- 2.27.0
Re: [PATCH] arch: arm: mach-imx: Fix a spelling in the file pm-imx5.c
On Fri, Feb 05, 2021 at 02:08:31PM +0530, Bhaskar Chowdhury wrote: > > s/confgiured/configured/ > > > Signed-off-by: Bhaskar Chowdhury Applied, thanks.
[PATCH v2 2/2] arm64: Drop support for CMDLINE_EXTEND
The documented behaviour for CMDLINE_EXTEND is that the arguments from
the bootloader are appended to the built-in kernel command line. This
also matches the option parsing behaviour for the EFI stub and early ID
register overrides.
Bizarrely, the fdt behaviour is the other way around: appending the
built-in command line to the bootloader arguments, resulting in a
command-line that doesn't necessarily line-up with the parsing order and
definitely doesn't line-up with the documented behaviour.
As it turns out, there is a proposal [1] to replace CMDLINE_EXTEND with
CMDLINE_PREPEND and CMDLINE_APPEND options which should hopefully make
the intended behaviour much clearer. While we wait for those to land,
drop CMDLINE_EXTEND for now as there appears to be little enthusiasm for
changing the current FDT behaviour.
[1] https://lore.kernel.org/lkml/20190319232448.45964-2-danie...@cisco.com/
Cc: Max Uvarov
Cc: Rob Herring
Cc: Ard Biesheuvel
Cc: Marc Zyngier
Cc: Doug Anderson
Cc: Tyler Hicks
Cc: Frank Rowand
Cc: Catalin Marinas
Link:
https://lore.kernel.org/r/CAL_JsqJX=TCCs7=gg486r9tn4nyscmtclnfqjf9crskkpq-...@mail.gmail.com
Signed-off-by: Will Deacon
---
arch/arm64/Kconfig | 6 --
arch/arm64/kernel/idreg-override.c | 5 +
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f212b47a48a..f15418332d16 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1855,12 +1855,6 @@ config CMDLINE_FROM_BOOTLOADER
the boot loader doesn't provide any, the default kernel command
string provided in CMDLINE will be used.
-config CMDLINE_EXTEND
- bool "Extend bootloader kernel arguments"
- help
- The command-line arguments provided by the boot loader will be
- appended to the default kernel command string.
-
config CMDLINE_FORCE
bool "Always use the default kernel command string"
help
diff --git a/arch/arm64/kernel/idreg-override.c
b/arch/arm64/kernel/idreg-override.c
index cc071712c6f9..83f1c4b92095 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -188,11 +188,8 @@ static __init void parse_cmdline(void)
{
const u8 *prop = get_bootargs_cmdline();
- if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
- IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
- !prop) {
+ if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || !prop)
__parse_cmdline(CONFIG_CMDLINE, true);
- }
if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
__parse_cmdline(prop, true);
--
2.30.1.766.gb4fecdf3b7-goog
Re: [PATCH V3 0/2] ata: ahci: ceva: Update the driver to support xilinx GT phy
On 2/8/21 11:03 AM, Piyush Mehta wrote: > This patch series updates the ceva driver to add support for Xilinx GT phy. > This also updates the documentation with the device tree binding required > for working with Xilinx GT phy. Applied for 5.13, thanks. -- Jens Axboe
[PATCH v2 0/2] Fix arm64 CONFIG_CMDLINE handling and remove CMDLINE_EXTEND
Hi again, This is version two of the series I previously posted here: https://lore.kernel.org/r/20210225125921.13147-1-w...@kernel.org The main change since v1 is that, rather than "fix" the FDT code to follow the documented behaviour for CMDLINE_EXTEND, I've opted to remove the thing entirely for arm64 while a less ambiguous and generic replacement is developed, probably based on either [1] or [2]. I've left the first-patch as-is so that it's easier to incorporate whatever ends up replacing CMDLINE_EXTEND in future. Cheers, Will [1] https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.le...@c-s.fr/ [2] https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190319232448.45964-2-danie...@cisco.com/ --->8 Cc: Max Uvarov Cc: Rob Herring Cc: Ard Biesheuvel Cc: Marc Zyngier Cc: Doug Anderson Cc: Tyler Hicks Cc: Frank Rowand Cc: Arnd Bergmann Cc: Palmer Dabbelt Cc: Greg Kroah-Hartman Cc: Catalin Marinas Cc: Cc: Cc: Will Deacon (2): arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides arm64: Drop support for CMDLINE_EXTEND arch/arm64/Kconfig | 6 - arch/arm64/kernel/idreg-override.c | 43 -- 2 files changed, 23 insertions(+), 26 deletions(-) -- 2.30.1.766.gb4fecdf3b7-goog
Re: [PATCH next v4 12/15] printk: introduce a kmsg_dump iterator
On Wed 2021-03-03 11:15:25, John Ogness wrote: > Rather than storing the iterator information in the registered > kmsg_dumper structure, create a separate iterator structure. The > kmsg_dump_iter structure can reside on the stack of the caller, thus > allowing lockless use of the kmsg_dump functions. > > Update code that accesses the kernel logs using the kmsg_dumper > structure to use the new kmsg_dump_iter structure. For kmsg_dumpers, > this also means adding a call to kmsg_dump_rewind() to initialize > the iterator. > > All this is in preparation for removal of @logbuf_lock. > > Signed-off-by: John Ogness > Reviewed-by: Kees Cook # pstore Reviewed-by: Petr Mladek Best Regards, Petr
Re: [PATCH RESEND] rsxx: Return -EFAULT if copy_to_user() fails
On 3/3/21 3:59 AM, Dan Carpenter wrote:
> The copy_to_user() function returns the number of bytes remaining but
> we want to return -EFAULT to the user if it can't complete the copy.
> The "st" variable only holds zero on success or negative error codes on
> failure so the type should be int.
>
> Fixes: 36f988e978f8 ("rsxx: Adding in debugfs entries.")
> Signed-off-by: Dan Carpenter
> ---
> I sent this last June as part of a 2 patch series. No one responded
> to the patches. The first patch was a NULL derefence fix but I now
> think that the correct fix for that is to remove the "enable_blkdev"
> module option... Anyway, this patch is uncontroversial so I'm going to
> resend it.
Thanks Dan, applied.
--
Jens Axboe
[PATCH] Revert "perf/x86: Allow zero PEBS status with only single active event"
From: Kan Liang
This reverts commit 01330d7288e0 ("perf/x86: Allow zero PEBS status with
only single active event")
A repeatable crash can be triggered by the perf_fuzzer on some Haswell
system.
https://lore.kernel.org/lkml/7170d3b-c17f-1ded-52aa-cc6d9ae99...@maine.edu/
For some old CPUs (HSW and earlier), the PEBS status in a PEBS record
may be mistakenly set to 0. To minimize the impact of the defect, the
commit was introduced to try to avoid dropping the PEBS record for some
cases. It adds a check in the intel_pmu_drain_pebs_nhm(), and updates
the local pebs_status accordingly. However, it doesn't correct the PEBS
status in the PEBS record, which may trigger the crash, especially for
the large PEBS.
It's possible that all the PEBS records in a large PEBS have the PEBS
status 0. If so, the first get_next_pebs_record_by_bit() in the
__intel_pmu_pebs_event() returns NULL. The at = NULL. Since it's a large
PEBS, the 'count' parameter must > 1. The second
get_next_pebs_record_by_bit() will crash.
Two solutions were considered to fix the crash.
- Keep the SW workaround and add extra checks in the
get_next_pebs_record_by_bit() to workaround the issue. The
get_next_pebs_record_by_bit() is a critical path. The extra checks
will bring extra overhead for the latest CPUs which don't have the
defect. Also, the defect can only be observed on some old CPUs
(For example, the issue can be reproduced on an HSW client, but I
didn't observe the issue on my Haswell server machine.). The impact
of the defect should be limit.
This solution is dropped.
- Drop the SW workaround and revert the commit.
It seems that the commit never works, because the PEBS status in the
PEBS record never be changed. The get_next_pebs_record_by_bit() only
checks the PEBS status in the PEBS record. The record is dropped
eventually. Reverting the commit should not change the current
behavior.
Fixes: 01330d7288e0 ("perf/x86: Allow zero PEBS status with only single active
event")
Reported-by: Vince Weaver
Signed-off-by: Kan Liang
Cc: sta...@vger.kernel.org
---
arch/x86/events/intel/ds.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 7ebae18..9c90d1e 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -2000,18 +2000,6 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs
*iregs, struct perf_sample_d
continue;
}
- /*
-* On some CPUs the PEBS status can be zero when PEBS is
-* racing with clearing of GLOBAL_STATUS.
-*
-* Normally we would drop that record, but in the
-* case when there is only a single active PEBS event
-* we can assume it's for that event.
-*/
- if (!pebs_status && cpuc->pebs_enabled &&
- !(cpuc->pebs_enabled & (cpuc->pebs_enabled-1)))
- pebs_status = cpuc->pebs_enabled;
-
bit = find_first_bit((unsigned long *)_status,
x86_pmu.max_pebs_events);
if (bit >= x86_pmu.max_pebs_events)
--
2.7.4
[PATCH 53/53] drm/vmwgfx/ttm_object: Reorder header to immediately precede its struct
Also add missing description for 'refcount'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/ttm_object.c:60: error: Cannot parse struct or union!
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Dave Airlie
Cc: Rob Clark
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-30-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/ttm_object.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c
b/drivers/gpu/drm/vmwgfx/ttm_object.c
index b3fdc630497cb..112394dd0ab6a 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -42,6 +42,14 @@
*/
+#define pr_fmt(fmt) "[TTM] " fmt
+
+#include
+#include
+#include
+#include
+#include "ttm_object.h"
+
/**
* struct ttm_object_file
*
@@ -55,16 +63,9 @@
*
* @ref_hash: Hash tables of ref objects, one per ttm_ref_type,
* for fast lookup of ref objects given a base object.
+ *
+ * @refcount: reference/usage count
*/
-
-#define pr_fmt(fmt) "[TTM] " fmt
-
-#include
-#include
-#include
-#include
-#include "ttm_object.h"
-
struct ttm_object_file {
struct ttm_object_device *tdev;
spinlock_t lock;
--
2.27.0
[PATCH 34/53] drm/vmwgfx/vmwgfx_fence: Add, remove and demote various documentation params/headers
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:82: warning: Function parameter or
member 'event' not described in 'vmw_event_fence_action'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:113: warning: Function parameter or
member 'f' not described in 'vmw_fence_obj_destroy'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:261: warning: Function parameter or
member 'work' not described in 'vmw_fence_work_func'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:720: warning: Function parameter or
member 'fman' not described in 'vmw_fence_fifo_down'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:963: warning: Function parameter or
member 'fence' not described in 'vmw_fence_obj_add_action'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:963: warning: Function parameter or
member 'action' not described in 'vmw_fence_obj_add_action'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:1021: warning: Function parameter or
member 'tv_sec' not described in 'vmw_event_fence_action_queue'
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:1021: warning: Function parameter or
member 'tv_usec' not described in 'vmw_event_fence_action_queue'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-27-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 378ec7600154b..23523eb3cac2a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -58,13 +58,11 @@ struct vmw_user_fence {
/**
* struct vmw_event_fence_action - fence action that delivers a drm event.
*
- * @e: A struct drm_pending_event that controls the event delivery.
* @action: A struct vmw_fence_action to hook up to a fence.
+ * @event: A pointer to the pending event.
* @fence: A referenced pointer to the fence to keep it alive while @action
* hangs on it.
* @dev: Pointer to a struct drm_device so we can access the event stuff.
- * @kref: Both @e and @action has destructors, so we need to refcount.
- * @size: Size accounted for this object.
* @tv_sec: If non-null, the variable pointed to will be assigned
* current time tv_sec val when the fence signals.
* @tv_usec: Must be set if @tv_sec is set, and the variable pointed to will
@@ -87,7 +85,7 @@ fman_from_fence(struct vmw_fence_obj *fence)
return container_of(fence->base.lock, struct vmw_fence_manager, lock);
}
-/**
+/*
* Note on fencing subsystem usage of irqs:
* Typically the vmw_fences_update function is called
*
@@ -250,7 +248,7 @@ static const struct dma_fence_ops vmw_fence_ops = {
};
-/**
+/*
* Execute signal actions on fences recently signaled.
* This is done from a workqueue so we don't have to execute
* signal actions from atomic context.
@@ -708,7 +706,7 @@ int vmw_wait_dma_fence(struct vmw_fence_manager *fman,
}
-/**
+/*
* vmw_fence_fifo_down - signal all unsignaled fence objects.
*/
@@ -948,8 +946,8 @@ static void vmw_event_fence_action_cleanup(struct
vmw_fence_action *action)
/**
* vmw_fence_obj_add_action - Add an action to a fence object.
*
- * @fence - The fence object.
- * @action - The action to add.
+ * @fence: The fence object.
+ * @action: The action to add.
*
* Note that the action callbacks may be executed before this function
* returns.
@@ -1001,6 +999,10 @@ static void vmw_fence_obj_add_action(struct vmw_fence_obj
*fence,
* @fence: The fence object on which to post the event.
* @event: Event to be posted. This event should've been alloced
* using k[mz]alloc, and should've been completely initialized.
+ * @tv_sec: If non-null, the variable pointed to will be assigned
+ * current time tv_sec val when the fence signals.
+ * @tv_usec: Must be set if @tv_sec is set, and the variable pointed to will
+ * be assigned the current time tv_usec val when the fence signals.
* @interruptible: Interruptible waits if possible.
*
* As a side effect, the object pointed to by @event may have been
--
2.27.0
[PATCH v2 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides
The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
three different ways:
1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
any bootloader args.
The early cmdline parsing to detect idreg overrides gets (2) and (3)
slightly wrong: in the case of (2) the bootloader args are parsed first
and in the case of (3) the CMDLINE is always parsed.
Fix these issues by moving the bootargs parsing out into a helper
function and following the same logic as that used by the EFI stub.
Reviewed-by: Marc Zyngier
Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature
override facility")
Signed-off-by: Will Deacon
---
arch/arm64/kernel/idreg-override.c | 44 +-
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/kernel/idreg-override.c
b/arch/arm64/kernel/idreg-override.c
index dffb16682330..cc071712c6f9 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline,
bool parse_aliases)
} while (1);
}
-static __init void parse_cmdline(void)
+static __init const u8 *get_bootargs_cmdline(void)
{
- if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
- const u8 *prop;
- void *fdt;
- int node;
+ const u8 *prop;
+ void *fdt;
+ int node;
- fdt = get_early_fdt_ptr();
- if (!fdt)
- goto out;
+ fdt = get_early_fdt_ptr();
+ if (!fdt)
+ return NULL;
- node = fdt_path_offset(fdt, "/chosen");
- if (node < 0)
- goto out;
+ node = fdt_path_offset(fdt, "/chosen");
+ if (node < 0)
+ return NULL;
- prop = fdt_getprop(fdt, node, "bootargs", NULL);
- if (!prop)
- goto out;
+ prop = fdt_getprop(fdt, node, "bootargs", NULL);
+ if (!prop)
+ return NULL;
- __parse_cmdline(prop, true);
+ return strlen(prop) ? prop : NULL;
+}
- if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
- return;
+static __init void parse_cmdline(void)
+{
+ const u8 *prop = get_bootargs_cmdline();
+
+ if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+ IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+ !prop) {
+ __parse_cmdline(CONFIG_CMDLINE, true);
}
-out:
- __parse_cmdline(CONFIG_CMDLINE, true);
+ if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
+ __parse_cmdline(prop, true);
}
/* Keep checkers quiet */
--
2.30.1.766.gb4fecdf3b7-goog
[no subject]
-- Good Afternoon from UK, How are you? we guess you're well, Our office has sent you a message last week but there is no answer from you to date, did you read our notice? get back to us upon the receipt of this mail. Thank You, Mr. Hennager James Craig IMF Office London United Kingdom
[PATCH 48/53] drm/vmwgfx/vmwgfx_msg: Fix misspelling of 'msg'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_msg.c:261: warning: Function parameter or member 'msg' not described in 'vmw_send_msg' drivers/gpu/drm/vmwgfx/vmwgfx_msg.c:261: warning: Excess function parameter 'logmsg' description in 'vmw_send_msg' Cc: VMware Graphics Cc: Roland Scheidegger Cc: Zack Rusin Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-6-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c index 15b5bde693242..609269625468d 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c @@ -253,7 +253,7 @@ static unsigned long vmw_port_hb_in(struct rpc_channel *channel, char *reply, * vmw_send_msg: Sends a message to the host * * @channel: RPC channel - * @logmsg: NULL terminated string + * @msg: NULL terminated string * * Returns: 0 on success */ -- 2.27.0
[PATCH 51/53] drm/vmwgfx/ttm_object: Demote half-assed headers and fix-up another
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/ttm_object.c:60: error: Cannot parse struct or union!
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member
'mem_glob' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member
'ops' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member
'dmabuf_release' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member
'dma_buf_size' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:97: warning: Function parameter or member
'idr' not described in 'ttm_object_device'
drivers/gpu/drm/vmwgfx/ttm_object.c:128: warning: Function parameter or member
'rcu_head' not described in 'ttm_ref_object'
drivers/gpu/drm/vmwgfx/ttm_object.c:128: warning: Function parameter or member
'tfile' not described in 'ttm_ref_object'
drivers/gpu/drm/vmwgfx/ttm_object.c:582: warning: Function parameter or member
'dmabuf' not described in 'get_dma_buf_unless_doomed'
drivers/gpu/drm/vmwgfx/ttm_object.c:582: warning: Excess function parameter
'dma_buf' description in 'get_dma_buf_unless_doomed'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Dave Airlie
Cc: Rob Clark
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-10-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/ttm_object.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c
b/drivers/gpu/drm/vmwgfx/ttm_object.c
index 0fe869d0fad12..b3fdc630497cb 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -73,7 +73,7 @@ struct ttm_object_file {
struct kref refcount;
};
-/**
+/*
* struct ttm_object_device
*
* @object_lock: lock that protects the object_hash hash table.
@@ -96,7 +96,7 @@ struct ttm_object_device {
struct idr idr;
};
-/**
+/*
* struct ttm_ref_object
*
* @hash: Hash entry for the per-file object reference hash.
@@ -568,7 +568,7 @@ void ttm_object_device_release(struct ttm_object_device
**p_tdev)
/**
* get_dma_buf_unless_doomed - get a dma_buf reference if possible.
*
- * @dma_buf: Non-refcounted pointer to a struct dma-buf.
+ * @dmabuf: Non-refcounted pointer to a struct dma-buf.
*
* Obtain a file reference from a lookup structure that doesn't refcount
* the file, but synchronizes with its release method to make sure it has
--
2.27.0
[PATCH 28/53] drm/vmwgfx/vmwgfx_resource: Fix worthy function headers demote some others
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:215: warning: Excess function parameter 'obj_type' description in 'vmw_resource_init' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:303: warning: Excess function parameter 'p_res' description in 'vmw_user_resource_noref_lookup_handle' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:328: warning: Function parameter or member 'dev_priv' not described in 'vmw_user_lookup_handle' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:328: warning: Function parameter or member 'tfile' not described in 'vmw_user_lookup_handle' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:328: warning: Function parameter or member 'handle' not described in 'vmw_user_lookup_handle' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:328: warning: Function parameter or member 'out_surf' not described in 'vmw_user_lookup_handle' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:328: warning: Function parameter or member 'out_buf' not described in 'vmw_user_lookup_handle' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:398: warning: Function parameter or member 'dirtying' not described in 'vmw_resource_do_validate' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:601: warning: Function parameter or member 'interruptible' not described in 'vmw_resource_reserve' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:601: warning: Function parameter or member 'no_backup' not described in 'vmw_resource_reserve' drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:987: warning: Function parameter or member 'interruptible' not described in 'vmw_resource_pin' Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-11-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index d1e7b9608145b..c4df51a2a9262 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c @@ -202,7 +202,6 @@ int vmw_resource_alloc_id(struct vmw_resource *res) * * @dev_priv: Pointer to a device private struct. * @res:The struct vmw_resource to initialize. - * @obj_type: Resource object type. * @delay_id: Boolean whether to defer device id allocation until * the first validation. * @res_free: Resource destructor. @@ -288,8 +287,6 @@ int vmw_user_resource_lookup_handle(struct vmw_private *dev_priv, * @tfile:Pointer to a struct ttm_object_file identifying the caller * @handle: The TTM user-space handle * @converter:Pointer to an object describing the resource type - * @p_res:On successful return the location pointed to will contain - *a pointer to a refcounted struct vmw_resource. * * If the handle can't be found or is associated with an incorrect resource * type, -EINVAL will be returned. @@ -315,7 +312,7 @@ vmw_user_resource_noref_lookup_handle(struct vmw_private *dev_priv, return converter->base_obj_to_res(base); } -/** +/* * Helper function that looks either a surface or bo. * * The pointer this pointed at by out_surf and out_buf needs to be null. @@ -388,6 +385,7 @@ static int vmw_resource_buf_alloc(struct vmw_resource *res, * @res:The resource to make visible to the device. * @val_buf:Information about a buffer possibly * containing backup data if a bind operation is needed. + * @dirtying: Transfer dirty regions. * * On hardware resource shortage, this function returns -EBUSY and * should be retried once resources have been freed up. @@ -586,7 +584,7 @@ vmw_resource_check_buffer(struct ww_acquire_ctx *ticket, return ret; } -/** +/* * vmw_resource_reserve - Reserve a resource for command submission * * @res:The resource to reserve. @@ -973,7 +971,7 @@ void vmw_resource_evict_all(struct vmw_private *dev_priv) mutex_unlock(_priv->cmdbuf_mutex); } -/** +/* * vmw_resource_pin - Add a pin reference on a resource * * @res: The resource to add a pin reference on -- 2.27.0
[PATCH 29/53] drm/vmwgfx/vmwgfx_ttm_buffer: Supply some missing parameter descriptions
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:275: warning: Function parameter or member 'p_offset' not described in 'vmw_piter_start' drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c:676: warning: Function parameter or member 'evict' not described in 'vmw_move_notify' Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-12-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index dbb068830d800..6a44567e4ba52 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -265,6 +265,7 @@ static dma_addr_t __vmw_piter_sg_addr(struct vmw_piter *viter) * * @viter: Pointer to the iterator to initialize * @vsgt: Pointer to a struct vmw_sg_table to initialize from + * @p_offset: Pointer offset used to update current array position * * Note that we're following the convention of __sg_page_iter_start, so that * the iterator doesn't point to a valid page after initialization; it has @@ -664,6 +665,7 @@ static int vmw_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_resourc * vmw_move_notify - TTM move_notify_callback * * @bo: The TTM buffer object about to move. + * @evict: Unused * @mem: The struct ttm_resource indicating to what memory * region the move is taking place. * -- 2.27.0
[PATCH 26/53] drm/vmwgfx/vmwgfx_drv: Fix some kernel-doc misdemeanours
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:164: warning: Function parameter or member
'ioctl' not described in 'VMW_IOCTL_DEF'
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:164: warning: Function parameter or member
'func' not described in 'VMW_IOCTL_DEF'
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:164: warning: Function parameter or member
'flags' not described in 'VMW_IOCTL_DEF'
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:170: warning: cannot understand function
prototype: 'const struct drm_ioctl_desc vmw_ioctls[] = '
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:542: warning: Function parameter or member
'dev_priv' not described in 'vmw_get_initial_size'
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:611: warning: Function parameter or member
'dev_priv' not described in 'vmw_dma_masks'
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:611: warning: Excess function parameter
'dev' description in 'vmw_dma_masks'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-9-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index dd69b51c40e41..ef81a68dd4bd4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -153,7 +153,7 @@
DRM_IOWR(DRM_COMMAND_BASE + DRM_VMW_MSG,\
struct drm_vmw_msg_arg)
-/**
+/*
* The core DRM version of this macro doesn't account for
* DRM_COMMAND_BASE.
*/
@@ -161,7 +161,7 @@
#define VMW_IOCTL_DEF(ioctl, func, flags) \
[DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {DRM_IOCTL_##ioctl,
flags, func}
-/**
+/*
* Ioctl definitions.
*/
@@ -526,7 +526,7 @@ static void vmw_release_device_late(struct vmw_private
*dev_priv)
vmw_fifo_release(dev_priv, _priv->fifo);
}
-/**
+/*
* Sets the initial_[width|height] fields on the given vmw_private.
*
* It does so by reading SVGA_REG_[WIDTH|HEIGHT] regs and then
@@ -599,7 +599,7 @@ static int vmw_dma_select_mode(struct vmw_private *dev_priv)
/**
* vmw_dma_masks - set required page- and dma masks
*
- * @dev: Pointer to struct drm-device
+ * @dev_priv: Pointer to struct drm-device
*
* With 32-bit we can only handle 32 bit PFNs. Optionally set that
* restriction also for 64-bit systems.
--
2.27.0
Re: [PATCH v3 RFC 14/14] mm: speedup page alloc for MPOL_PREFERRED_MANY by adding a NO_SLOWPATH gfp bit
On Wed, Mar 03, 2021 at 09:18:32PM +0800, Tang, Feng wrote: > On Wed, Mar 03, 2021 at 01:32:11PM +0100, Michal Hocko wrote: > > On Wed 03-03-21 20:18:33, Feng Tang wrote: > > > On Wed, Mar 03, 2021 at 08:07:17PM +0800, Tang, Feng wrote: > > > > Hi Michal, > > > > > > > > On Wed, Mar 03, 2021 at 12:39:57PM +0100, Michal Hocko wrote: > > > > > On Wed 03-03-21 18:20:58, Feng Tang wrote: > > > > > > When doing broader test, we noticed allocation slowness in one test > > > > > > case that malloc memory with size which is slightly bigger than free > > > > > > memory of targeted nodes, but much less then the total free memory > > > > > > of system. > > > > > > > > > > > > The reason is the code enters the slowpath of > > > > > > __alloc_pages_nodemask(), > > > > > > which takes quite some time. As alloc_pages_policy() will give it a > > > > > > 2nd > > > > > > try with NULL nodemask, so there is no need to enter the slowpath > > > > > > for > > > > > > the first try. Add a new gfp bit to skip the slowpath, so that user > > > > > > cases > > > > > > like this can leverage. > > > > > > > > > > > > With it, the malloc in such case is much accelerated as it never > > > > > > enters > > > > > > the slowpath. > > > > > > > > > > > > Adding a new gfp_mask bit is generally not liked, and another idea > > > > > > is to > > > > > > add another nodemask to struct 'alloc_context', so it has 2: > > > > > > 'preferred-nmask' > > > > > > and 'fallback-nmask', and they will be tried in turn if not NULL, > > > > > > with > > > > > > it we can call __alloc_pages_nodemask() only once. > > > > > > > > > > Yes, it is very much disliked. Is there any reason why you cannot use > > > > > GFP_NOWAIT for that purpose? > > > > > > > > I did try that at the first place, but it didn't obviously change the > > > > slowness. > > > > I assumed the direct claim was still involved as GFP_NOWAIT only impact > > > > kswapd > > > > reclaim. > > > > I assume you haven't really created gfp mask correctly. What was the > > exact gfp mask you have used? > > The testcase is a malloc with multi-preferred-node policy, IIRC, the gfp > mask is HIGHUSER_MOVABLE originally, and code here ORs (__GFP_RETRY_MAYFAIL | > __GFP_NOWARN). > > As GFP_WAIT == __GFP_KSWAPD_RECLAIM, in this test case, the bit is already > set. > > > > > > > One thing I tried which can fix the slowness is: > > > > > > + gfp_mask &= ~(__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM); > > > > > > which explicitly clears the 2 kinds of reclaim. And I thought it's too > > > hacky and didn't mention it in the commit log. > > > > Clearing __GFP_DIRECT_RECLAIM would be the right way to achieve > > GFP_NOWAIT semantic. Why would you want to exclude kswapd as well? > > When I tried gfp_mask &= ~__GFP_DIRECT_RECLAIM, the slowness couldn't > be fixed. I just double checked by rerun the test, 'gfp_mask &= ~__GFP_DIRECT_RECLAIM' can also accelerate the allocation much! though is still a little slower than this patch. Seems I've messed some of the tries, and sorry for the confusion! Could this be used as the solution? or the adding another fallback_nodemask way? but the latter will change the current API quite a bit. Thanks, Feng
[PATCH 31/53] drm/vmwgfx/vmwgfx_ldu: Supply descriptions for 'state' function parameter
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:55: warning: cannot understand function
prototype: 'struct vmw_legacy_display_unit '
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:218: warning: Function parameter or member
'state' not described in 'vmw_ldu_crtc_atomic_enable'
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:228: warning: Function parameter or member
'state' not described in 'vmw_ldu_crtc_atomic_disable'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-14-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 9a9508edbc9ed..acae92a07f4f3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -49,7 +49,7 @@ struct vmw_legacy_display {
struct vmw_framebuffer *fb;
};
-/**
+/*
* Display unit using the legacy register interface.
*/
struct vmw_legacy_display_unit {
@@ -206,6 +206,7 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc
*crtc)
* vmw_ldu_crtc_atomic_enable - Noop
*
* @crtc: CRTC associated with the new screen
+ * @state: Unused
*
* This is called after a mode set has been completed. Here's
* usually a good place to call vmw_ldu_add_active/vmw_ldu_del_active
@@ -221,6 +222,7 @@ static void vmw_ldu_crtc_atomic_enable(struct drm_crtc
*crtc,
* vmw_ldu_crtc_atomic_disable - Turns off CRTC
*
* @crtc: CRTC to be turned off
+ * @state: Unused
*/
static void vmw_ldu_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
--
2.27.0
Re: [PATCH v3 3/3] ARM: imx_v6_v7_defconfig: Regenerate
On Wed, Feb 03, 2021 at 07:03:16PM -0800, Alistair Francis wrote: > Run make imx_v6_v7_defconfig; make savedefconfig to regenerate the > defconfig. > > Signed-off-by: Alistair Francis We can leave it to future updates on the defconfig. Shawn
[PATCH 30/53] drm/vmwgfx/vmwgfx_fifo: Demote non-conformant kernel-doc header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c:299: warning: Function parameter or member 'dev_priv' not described in 'vmw_local_fifo_reserve' drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c:299: warning: Function parameter or member 'bytes' not described in 'vmw_local_fifo_reserve' Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-13-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c index 7400d617ae3cc..20246a7c97c9d 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c @@ -276,7 +276,7 @@ static int vmw_fifo_wait(struct vmw_private *dev_priv, return ret; } -/** +/* * Reserve @bytes number of bytes in the fifo. * * This function will return NULL (error) on two conditions: -- 2.27.0
Re: [PATCH v2 3/3] mm/slub: Use percpu partial free counter
On 3/2/21 5:14 PM, Christoph Lameter wrote:
> On Mon, 10 Aug 2020, Xunlei Pang wrote:
>
>>
>> diff --git a/mm/slab.h b/mm/slab.h
>> index c85e2fa..a709a70 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>> @@ -616,7 +616,7 @@ struct kmem_cache_node {
>> #ifdef CONFIG_SLUB
>> unsigned long nr_partial;
>> struct list_head partial;
>> -atomic_long_t partial_free_objs;
>> +atomic_long_t __percpu *partial_free_objs;
>
> A percpu counter is never atomic. Just use unsigned long and use this_cpu
> operations for this thing. That should cut down further on the overhead.
>
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -1775,11 +1775,21 @@ static void discard_slab(struct kmem_cache *s,
>> struct page *page)
>> /*
>> * Management of partially allocated slabs.
>> */
>> +static inline long get_partial_free(struct kmem_cache_node *n)
>> +{
>> +long nr = 0;
>> +int cpu;
>> +
>> +for_each_possible_cpu(cpu)
>> +nr += atomic_long_read(per_cpu_ptr(n->partial_free_objs, cpu));
>
> this_cpu_read(*n->partial_free_objs)
>
>> static inline void
>> __update_partial_free(struct kmem_cache_node *n, long delta)
>> {
>> -atomic_long_add(delta, >partial_free_objs);
>> +atomic_long_add(delta, this_cpu_ptr(n->partial_free_objs));
>
> this_cpu_add()
>
> and so on.
>
Thanks, I changed them both to use "unsigned long", and will send v3 out
after our internal performance regression test passes.
[PATCH 27/53] drm/vmwgfx/vmwgfx_ioctl: Provide missing '@' sign required by kernel-doc
Fixes the following W=1 kernel build warning(s): In file included from drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c:30: drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c:448: warning: Function parameter or member 'offset' not described in 'vmw_fops_read' Cc: VMware Graphics Cc: Roland Scheidegger Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-10-lee.jo...@linaro.org --- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c index 80af8772b8c24..b36032964b2fe 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c @@ -437,7 +437,7 @@ __poll_t vmw_fops_poll(struct file *filp, struct poll_table_struct *wait) * @filp: See the linux fops read documentation. * @buffer: See the linux fops read documentation. * @count: See the linux fops read documentation. - * offset: See the linux fops read documentation. + * @offset: See the linux fops read documentation. * * Wrapper around the drm_read function that makes sure the device is * processing the fifo if drm_read decides to wait. -- 2.27.0
[PATCH 38/53] drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or
member 'prime' not described in 'vmw_user_surface'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or
member 'backup_base' not described in 'vmw_user_surface'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:78: warning: cannot understand
function prototype: 'struct vmw_surface_dirty '
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or
member 'header' not described in 'vmw_surface_dma'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or
member 'body' not described in 'vmw_surface_dma'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or
member 'cb' not described in 'vmw_surface_dma'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or
member 'suffix' not described in 'vmw_surface_dma'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:181: warning: Function parameter or
member 'header' not described in 'vmw_surface_define'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:181: warning: Function parameter or
member 'body' not described in 'vmw_surface_define'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:189: warning: Function parameter or
member 'header' not described in 'vmw_surface_destroy'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:189: warning: Function parameter or
member 'body' not described in 'vmw_surface_destroy'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:555: warning: Function parameter or
member 'readback' not described in 'vmw_legacy_srf_unbind'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:1067: warning: Function parameter or
member 'res' not described in 'vmw_gb_surface_create'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:1067: warning: Excess function
parameter 'srf' description in 'vmw_gb_surface_create'
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:1067: warning: Excess function
parameter 'cmd_space' description in 'vmw_gb_surface_create'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-34-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index f6cab77075a04..c3e55c1376eb8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -41,10 +41,12 @@
/**
* struct vmw_user_surface - User-space visible surface resource
*
+ * @prime: The TTM prime object.
* @base: The TTM base object handling user-space visibility.
* @srf:The surface metadata.
* @size: TTM accounting size for the surface.
- * @master: master of the creating client. Used for security check.
+ * @master: Master of the creating client. Used for security check.
+ * @backup_base:The TTM base object of the backup buffer.
*/
struct vmw_user_surface {
struct ttm_prime_object prime;
@@ -69,7 +71,7 @@ struct vmw_surface_offset {
};
/**
- * vmw_surface_dirty - Surface dirty-tracker
+ * struct vmw_surface_dirty - Surface dirty-tracker
* @cache: Cached layout information of the surface.
* @size: Accounting size for the struct vmw_surface_dirty.
* @num_subres: Number of subresources.
@@ -162,7 +164,7 @@ static const struct vmw_res_func vmw_gb_surface_func = {
.clean = vmw_surface_clean,
};
-/**
+/*
* struct vmw_surface_dma - SVGA3D DMA command
*/
struct vmw_surface_dma {
@@ -172,7 +174,7 @@ struct vmw_surface_dma {
SVGA3dCmdSurfaceDMASuffix suffix;
};
-/**
+/*
* struct vmw_surface_define - SVGA3D Surface Define command
*/
struct vmw_surface_define {
@@ -180,7 +182,7 @@ struct vmw_surface_define {
SVGA3dCmdDefineSurface body;
};
-/**
+/*
* struct vmw_surface_destroy - SVGA3D Surface Destroy command
*/
struct vmw_surface_destroy {
@@ -544,6 +546,7 @@ static int vmw_legacy_srf_bind(struct vmw_resource *res,
*
* @res:Pointer to a struct vmw_res embedded in a struct
* vmw_surface.
+ * @readback: Readback - only true if dirty
* @val_buf:Pointer to a struct ttm_validate_buffer containing
* information about the backup buffer.
*
@@ -1060,8 +1063,8 @@ int vmw_surface_reference_ioctl(struct drm_device *dev,
void *data,
/**
* vmw_surface_define_encode - Encode a surface_define command.
*
- * @srf: Pointer to a struct vmw_surface object.
- * @cmd_space: Pointer to memory area in which the commands should be encoded.
+ * @res:Pointer to a struct vmw_resource embedded in a struct
+ * vmw_surface.
*/
static int vmw_gb_surface_create(struct vmw_resource *res)
{
--
2.27.0
[PATCH 32/53] drm/vmwgfx/vmwgfx_kms: Update worthy function headers and demote others
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:37:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:483: warning: Function parameter or member
'new_state' not described in 'vmw_du_cursor_plane_atomic_check'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:483: warning: Excess function parameter
'state' description in 'vmw_du_cursor_plane_atomic_check'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1069: warning: Function parameter or
member 'vfb' not described in 'vmw_framebuffer_pin'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1281: warning: Function parameter or
member 'dev_priv' not described in 'vmw_kms_srf_ok'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1907: warning: Function parameter or
member 'crtc' not described in 'vmw_get_vblank_counter'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1915: warning: Function parameter or
member 'crtc' not described in 'vmw_enable_vblank'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1923: warning: Function parameter or
member 'crtc' not described in 'vmw_disable_vblank'
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:2131: warning: Function parameter or
member 'mode' not described in 'vmw_guess_mode_timing'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-21-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 9293dc19a7683..84143b707cd32 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -467,7 +467,7 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
*plane,
* vmw_du_cursor_plane_atomic_check - check if the new state is okay
*
* @plane: cursor plane
- * @state: info on the new plane state
+ * @new_state: info on the new plane state
*
* This is a chance to fail if the new cursor state does not fit
* our requirements.
@@ -1057,7 +1057,7 @@ static const struct drm_framebuffer_funcs
vmw_framebuffer_bo_funcs = {
.dirty = vmw_framebuffer_bo_dirty_ext,
};
-/**
+/*
* Pin the bofer in a location suitable for access by the
* display system.
*/
@@ -1267,6 +1267,7 @@ static int vmw_kms_new_framebuffer_bo(struct vmw_private
*dev_priv,
/**
* vmw_kms_srf_ok - check if a surface can be created
*
+ * @dev_priv: Pointer to device private struct.
* @width: requested width
* @height: requested height
*
@@ -1896,7 +1897,7 @@ bool vmw_kms_validate_mode_vram(struct vmw_private
*dev_priv,
}
-/**
+/*
* Function called by DRM code called with vbl_lock held.
*/
u32 vmw_get_vblank_counter(struct drm_crtc *crtc)
@@ -1904,7 +1905,7 @@ u32 vmw_get_vblank_counter(struct drm_crtc *crtc)
return 0;
}
-/**
+/*
* Function called by DRM code called with vbl_lock held.
*/
int vmw_enable_vblank(struct drm_crtc *crtc)
@@ -1912,7 +1913,7 @@ int vmw_enable_vblank(struct drm_crtc *crtc)
return -EINVAL;
}
-/**
+/*
* Function called by DRM code called with vbl_lock held.
*/
void vmw_disable_vblank(struct drm_crtc *crtc)
@@ -2120,7 +2121,7 @@ static struct drm_display_mode
vmw_kms_connector_builtin[] = {
* vmw_guess_mode_timing - Provide fake timings for a
* 60Hz vrefresh mode.
*
- * @mode - Pointer to a struct drm_display_mode with hdisplay and vdisplay
+ * @mode: Pointer to a struct drm_display_mode with hdisplay and vdisplay
* members filled in.
*/
void vmw_guess_mode_timing(struct drm_display_mode *mode)
--
2.27.0
Re: [PATCH v3 2/3] ARM: dts: imx7d: remarkable2: Enable the power button
On Wed, Feb 03, 2021 at 07:03:15PM -0800, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> arch/arm/boot/dts/imx7d-remarkable2.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts
> b/arch/arm/boot/dts/imx7d-remarkable2.dts
> index 0aae13f5eed6..0978e26f5db5 100644
> --- a/arch/arm/boot/dts/imx7d-remarkable2.dts
> +++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
> @@ -62,6 +62,10 @@ {
> status = "okay";
> };
>
> +_pwrkey {
> + status = "okay";
> +};
> +
Please merge it into patch #1.
Shawn
> {
> pinctrl-names = "default";
> pinctrl-0 = <_uart1>;
> --
> 2.30.0
>
[PATCH][next] drm/amdgpu/display: remove redundant continue statement
From: Colin Ian King
The continue statement in a for-loop is redudant and can be removed.
Clean up the code to address this.
Addresses-Coverity: ("Continue as no effect")
Fixes: b6f91fc183f7 ("drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT
interrupt work")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index 8ce10d0973c5..d3c687d07ee6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
@@ -520,9 +520,7 @@ static void amdgpu_dm_irq_schedule_work(struct
amdgpu_device *adev,
return;
list_for_each_entry (handler_data, handler_list, list) {
- if (!queue_work(system_highpri_wq, _data->work)) {
- continue;
- } else {
+ if (queue_work(system_highpri_wq, _data->work)) {
work_queued = true;
break;
}
--
2.30.0
[PATCH 15/53] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or member 'crtc' not described in 'nv_crtc_mode_set_regs' drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or member 'mode' not described in 'nv_crtc_mode_set_regs' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'crtc' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'mode' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'adjusted_mode' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'x' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'y' not described in 'nv_crtc_mode_set' drivers/gpu/drm/nouveau/dispnv04/crtc.c:640: warning: Function parameter or member 'old_fb' not described in 'nv_crtc_mode_set' Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index f9e962fd94d0d..f9a276ea5a9e0 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct drm_display_mode *mode) regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00; } -/** +/* * Sets up registers for the given mode/adjusted_mode pair. * * The clocks, CRTCs and outputs attached to this CRTC must be off. @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct drm_framebuffer *old_fb) return ret; } -/** +/* * Sets up registers for the given mode/adjusted_mode pair. * * The clocks, CRTCs and outputs attached to this CRTC must be off. -- 2.27.0
[PATCH 18/53] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions
Fixes the following build error: drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for ‘nv50_display_fini’ In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71: drivers/gpu/drm/nouveau/nv50_display.h:36:6: note: previous declaration of ‘nv50_display_fini’ was her In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71: drivers/gpu/drm/nouveau/nv50_display.h:35:6: note: previous declaration of ‘nv50_display_init’ was here drivers/gpu/drm/nouveau/dispnv50/disp.c:2581:1: error: static declaration of ‘nv50_display_destroy’ follows non-static declaration In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71: drivers/gpu/drm/nouveau/nv50_display.h:34:6: note: previous declaration of ‘nv50_display_destroy’ was here Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nv50_display.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.h b/drivers/gpu/drm/nouveau/nv50_display.h index fbd3b15583bc8..2421401d12636 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.h +++ b/drivers/gpu/drm/nouveau/nv50_display.h @@ -31,7 +31,4 @@ #include "nouveau_reg.h" int nv50_display_create(struct drm_device *); -void nv50_display_destroy(struct drm_device *); -int nv50_display_init(struct drm_device *); -void nv50_display_fini(struct drm_device *); #endif /* __NV50_DISPLAY_H__ */ -- 2.27.0
[PATCH 16/53] drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c51efca82ac78..828f48d5bdd4e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1386,12 +1386,11 @@ nv50_mstm_cleanup(struct nv50_mstm *mstm)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm cleanup\n", mstm->outp->base.base.name);
- ret = drm_dp_check_act_status(>mgr);
+ drm_dp_check_act_status(>mgr);
- ret = drm_dp_update_payload_part2(>mgr);
+ drm_dp_update_payload_part2(>mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
--
2.27.0
[PATCH 14/53] drm/nouveau/nouveau_display: Remove set but unused variable 'width'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_display.c: In function
‘nouveau_framebuffer_new’:
drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable ‘width’
set but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 17831ee897ea4..0849f367631a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -306,7 +306,7 @@ nouveau_framebuffer_new(struct drm_device *dev,
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct drm_framebuffer *fb;
const struct drm_format_info *info;
- unsigned int width, height, i;
+ unsigned int height, i;
uint32_t tile_mode;
uint8_t kind;
int ret;
@@ -346,9 +346,9 @@ nouveau_framebuffer_new(struct drm_device *dev,
info = drm_get_format_info(dev, mode_cmd);
for (i = 0; i < info->num_planes; i++) {
- width = drm_format_info_plane_width(info,
- mode_cmd->width,
- i);
+ drm_format_info_plane_width(info,
+ mode_cmd->width,
+ i);
height = drm_format_info_plane_height(info,
mode_cmd->height,
i);
--
2.27.0
[PATCH 24/53] drm/vmwgfx/vmwgfx_kms: Remove unused variable 'ret' from 'vmw_du_primary_plane_atomic_check()'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c: In function
‘vmw_du_primary_plane_atomic_check’:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:460:31: warning: variable ‘vcs’ set but
not used [-Wunused-but-set-variable]
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-5-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 9a89f658e501c..9293dc19a7683 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -453,10 +453,9 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
*plane,
if (!ret && new_fb) {
struct drm_crtc *crtc = state->crtc;
- struct vmw_connector_state *vcs;
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
- vcs = vmw_connector_state_to_vcs(du->connector.state);
+ vmw_connector_state_to_vcs(du->connector.state);
}
--
2.27.0
[PATCH 25/53] drm/vmwgfx/vmwgfx_kms: Mark vmw_{cursor,primary}_plane_formats as __maybe_unused
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:256:23: warning:
‘vmw_cursor_plane_formats’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:248:23: warning:
‘vmw_primary_plane_formats’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:256:23: warning:
‘vmw_cursor_plane_formats’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:248:23: warning:
‘vmw_primary_plane_formats’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:256:23: warning:
‘vmw_cursor_plane_formats’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h:248:23: warning:
‘vmw_primary_plane_formats’ defined but not used [-Wunused-const-variable=]
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-8-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 03f3694015cec..6267ccf54944e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -245,7 +245,7 @@ struct vmw_framebuffer_bo {
};
-static const uint32_t vmw_primary_plane_formats[] = {
+static const uint32_t __maybe_unused vmw_primary_plane_formats[] = {
DRM_FORMAT_XRGB1555,
DRM_FORMAT_RGB565,
DRM_FORMAT_RGB888,
@@ -253,7 +253,7 @@ static const uint32_t vmw_primary_plane_formats[] = {
DRM_FORMAT_ARGB,
};
-static const uint32_t vmw_cursor_plane_formats[] = {
+static const uint32_t __maybe_unused vmw_cursor_plane_formats[] = {
DRM_FORMAT_ARGB,
};
--
2.27.0
[PATCH 23/53] drm/vmwgfx/vmwgfx_execbuf: Fix some kernel-doc related issues
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:89: warning: Enum value
'vmw_res_rel_max' not described in enum 'vmw_resource_relocation_type'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:136: warning: Function parameter or
member 'func' not described in 'vmw_cmd_entry'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:136: warning: Function parameter or
member 'cmd_name' not described in 'vmw_cmd_entry'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:212: warning: Function parameter or
member 'res' not described in 'vmw_cmd_ctx_first_setup'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:523: warning: Function parameter or
member 'sw_context' not described in 'vmw_resource_relocation_add'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:523: warning: Excess function
parameter 'list' description in 'vmw_resource_relocation_add'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:653: warning: Function parameter or
member 'p_res' not described in 'vmw_cmd_res_check'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:653: warning: Excess function
parameter 'p_val' description in 'vmw_cmd_res_check'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:1716: warning: Function parameter or
member 'res' not described in 'vmw_cmd_res_switch_backup'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:1716: warning: Excess function
parameter 'val_node' description in 'vmw_cmd_res_switch_backup'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3757: warning: Function parameter or
member 'file_priv' not described in 'vmw_execbuf_fence_commands'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3757: warning: Function parameter or
member 'dev_priv' not described in 'vmw_execbuf_fence_commands'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3757: warning: Function parameter or
member 'p_fence' not described in 'vmw_execbuf_fence_commands'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3757: warning: Function parameter or
member 'p_handle' not described in 'vmw_execbuf_fence_commands'
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3954: warning: Function parameter or
member 'kernel_commands' not described in 'vmw_execbuf_cmdbuf'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-4-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 462f173207085..7a24196f92c38 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -80,7 +80,8 @@ struct vmw_relocation {
* with a NOP.
* @vmw_res_rel_cond_nop: Conditional NOP relocation. If the resource id after
* validation is -1, the command is replaced with a NOP. Otherwise no action.
- */
+ * @vmw_res_rel_max: Last value in the enum - used for error checking
+*/
enum vmw_resource_relocation_type {
vmw_res_rel_normal,
vmw_res_rel_nop,
@@ -122,9 +123,11 @@ struct vmw_ctx_validation_info {
/**
* struct vmw_cmd_entry - Describe a command for the verifier
*
+ * @func: Call-back to handle the command.
* @user_allow: Whether allowed from the execbuf ioctl.
* @gb_disable: Whether disabled if guest-backed objects are available.
* @gb_enable: Whether enabled iff guest-backed objects are available.
+ * @cmd_name: Name of the command.
*/
struct vmw_cmd_entry {
int (*func) (struct vmw_private *, struct vmw_sw_context *,
@@ -203,6 +206,7 @@ static void vmw_bind_dx_query_mob(struct vmw_sw_context
*sw_context)
*
* @dev_priv: Pointer to the device private:
* @sw_context: The command submission context
+ * @res: Pointer to the resource
* @node: The validation node holding the context resource metadata
*/
static int vmw_cmd_ctx_first_setup(struct vmw_private *dev_priv,
@@ -509,7 +513,7 @@ static int vmw_resource_context_res_add(struct vmw_private
*dev_priv,
/**
* vmw_resource_relocation_add - Add a relocation to the relocation list
*
- * @list: Pointer to head of relocation list.
+ * @sw_context: Pointer to the software context.
* @res: The resource.
* @offset: Offset into the command buffer currently being parsed where the id
* that needs fixup is located. Granularity is one byte.
@@ -639,7 +643,7 @@ static int vmw_resources_reserve(struct vmw_sw_context
*sw_context)
* @converter: User-space visisble type specific information.
* @id_loc: Pointer to the location in the command buffer currently being
parsed
* from where the user-space resource id handle is located.
- * @p_val: Pointer to pointer to resource validalidation node. Populated on
+ * @p_res: Pointer to pointer to resource validalidation node. Populated on
* exit.
*/
static int
@@
[PATCH 36/53] drm/vmwgfx/vmwgfx_context: Demote kernel-doc abuses
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_context.c:121: warning: Function parameter or
member 'dev_priv' not described in 'vmw_context_cotables_unref'
drivers/gpu/drm/vmwgfx/vmwgfx_context.c:121: warning: Function parameter or
member 'uctx' not described in 'vmw_context_cotables_unref'
drivers/gpu/drm/vmwgfx/vmwgfx_context.c:681: warning: Function parameter or
member 'base' not described in 'vmw_user_context_base_to_res'
drivers/gpu/drm/vmwgfx/vmwgfx_context.c:707: warning: Function parameter or
member 'p_base' not described in 'vmw_user_context_base_release'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-29-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 6f4d0da11ad87..4a5a3e246216d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -112,7 +112,7 @@ static const struct vmw_res_func vmw_dx_context_func = {
.unbind = vmw_dx_context_unbind
};
-/**
+/*
* Context management:
*/
@@ -672,7 +672,7 @@ static int vmw_dx_context_destroy(struct vmw_resource *res)
return 0;
}
-/**
+/*
* User-space context management:
*/
@@ -698,7 +698,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
vmw_user_context_size);
}
-/**
+/*
* This function is called when user space has no more references on the
* base object. It releases the base-object's reference on the resource object.
*/
--
2.27.0
[PATCH 40/53] drm/vmwgfx/vmwgfx_shader: Demote kernel-doc abuses and fix-up worthy headers
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:134: warning: Function parameter or
member 'res' not described in 'vmw_res_to_shader'
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:663: warning: Function parameter or
member 'base' not described in 'vmw_user_shader_base_to_res'
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:695: warning: Function parameter or
member 'p_base' not described in 'vmw_user_shader_base_release'
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:965: warning: Function parameter or
member 'dev_priv' not described in 'vmw_compat_shader_add'
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:965: warning: Function parameter or
member 'size' not described in 'vmw_compat_shader_add'
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c:965: warning: Excess function parameter
'tfile' description in 'vmw_compat_shader_add'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-37-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
index 905ae50aaa2ae..a0db065640131 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
@@ -125,7 +125,7 @@ static const struct vmw_res_func vmw_dx_shader_func = {
.commit_notify = vmw_dx_shader_commit_notify,
};
-/**
+/*
* Shader management:
*/
@@ -654,7 +654,7 @@ int vmw_dx_shader_add(struct vmw_cmdbuf_res_manager *man,
-/**
+/*
* User-space shader management:
*/
@@ -686,7 +686,7 @@ static void vmw_shader_free(struct vmw_resource *res)
vmw_shader_size);
}
-/**
+/*
* This function is called when user space has no more references on the
* base object. It releases the base-object's reference on the resource object.
*/
@@ -945,13 +945,13 @@ int vmw_shader_remove(struct vmw_cmdbuf_res_manager *man,
* vmw_compat_shader_add - Create a compat shader and stage it for addition
* as a command buffer managed resource.
*
+ * @dev_priv: Pointer to device private structure.
* @man: Pointer to the compat shader manager identifying the shader namespace.
* @user_key: The key that is used to identify the shader. The key is
* unique to the shader type.
* @bytecode: Pointer to the bytecode of the shader.
* @shader_type: Shader type.
- * @tfile: Pointer to a struct ttm_object_file that the guest-backed shader is
- * to be created with.
+ * @size: Command size.
* @list: Caller's list of staged command buffer resource actions.
*
*/
--
2.27.0
[PATCH 37/53] drm/vmwgfx/vmwgfx_scrn: Demote unworthy kernel-doc headers and update others
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:90: warning: cannot understand function
prototype: 'struct vmw_screen_object_unit '
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:122: warning: Function parameter or
member 'dev_priv' not described in 'vmw_sou_fifo_create'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:122: warning: Function parameter or
member 'sou' not described in 'vmw_sou_fifo_create'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:122: warning: Function parameter or
member 'x' not described in 'vmw_sou_fifo_create'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:122: warning: Function parameter or
member 'y' not described in 'vmw_sou_fifo_create'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:122: warning: Function parameter or
member 'mode' not described in 'vmw_sou_fifo_create'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:168: warning: Function parameter or
member 'dev_priv' not described in 'vmw_sou_fifo_destroy'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:168: warning: Function parameter or
member 'sou' not described in 'vmw_sou_fifo_destroy'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:283: warning: Function parameter or
member 'state' not described in 'vmw_sou_crtc_atomic_enable'
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:293: warning: Function parameter or
member 'state' not described in 'vmw_sou_crtc_atomic_disable'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-30-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index b0db059b8cfbe..6feb61a1a3041 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -84,7 +84,7 @@ struct vmw_kms_sou_define_gmrfb {
SVGAFifoCmdDefineGMRFB body;
};
-/**
+/*
* Display unit using screen objects.
*/
struct vmw_screen_object_unit {
@@ -112,7 +112,7 @@ static void vmw_sou_crtc_destroy(struct drm_crtc *crtc)
vmw_sou_destroy(vmw_crtc_to_sou(crtc));
}
-/**
+/*
* Send the fifo command to create a screen.
*/
static int vmw_sou_fifo_create(struct vmw_private *dev_priv,
@@ -160,7 +160,7 @@ static int vmw_sou_fifo_create(struct vmw_private *dev_priv,
return 0;
}
-/**
+/*
* Send the fifo command to destroy a screen.
*/
static int vmw_sou_fifo_destroy(struct vmw_private *dev_priv,
@@ -263,7 +263,7 @@ static void vmw_sou_crtc_mode_set_nofb(struct drm_crtc
*crtc)
/**
* vmw_sou_crtc_helper_prepare - Noop
*
- * @crtc: CRTC associated with the new screen
+ * @crtc: CRTC associated with the new screen
*
* Prepares the CRTC for a mode set, but we don't need to do anything here.
*/
@@ -275,6 +275,7 @@ static void vmw_sou_crtc_helper_prepare(struct drm_crtc
*crtc)
* vmw_sou_crtc_atomic_enable - Noop
*
* @crtc: CRTC associated with the new screen
+ * @state: Unused
*
* This is called after a mode set has been completed.
*/
@@ -287,6 +288,7 @@ static void vmw_sou_crtc_atomic_enable(struct drm_crtc
*crtc,
* vmw_sou_crtc_atomic_disable - Turns off CRTC
*
* @crtc: CRTC to be turned off
+ * @state: Unused
*/
static void vmw_sou_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
--
2.27.0
[PATCH 44/53] drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should be plural
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:137: warning: Function parameter or
member 'headers' not described in 'vmw_cmdbuf_man'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-2-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 3158924ffa852..2e23e537cdf52 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -89,7 +89,7 @@ struct vmw_cmdbuf_context {
* @max_hw_submitted: Max number of in-flight command buffers the device can
* handle. Immutable.
* @lock: Spinlock protecting command submission queues.
- * @header: Pool of DMA memory for device command buffer headers.
+ * @headers: Pool of DMA memory for device command buffer headers.
* Internal protection.
* @dheaders: Pool of DMA memory for device command buffer headers with
trailing
* space for inline data. Internal protection.
--
2.27.0
[PATCH 33/53] drm/vmwgfx/vmwgfx_overlay: Demote kernel-doc abuses to standard comment blocks
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:48: warning: cannot understand
function prototype: 'struct vmw_overlay '
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:98: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_send_put'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:98: warning: Function parameter or
member 'buf' not described in 'vmw_overlay_send_put'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:98: warning: Function parameter or
member 'arg' not described in 'vmw_overlay_send_put'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:98: warning: Function parameter or
member 'interruptible' not described in 'vmw_overlay_send_put'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:186: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_send_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:186: warning: Function parameter or
member 'stream_id' not described in 'vmw_overlay_send_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:186: warning: Function parameter or
member 'interruptible' not described in 'vmw_overlay_send_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:228: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_move_buffer'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:228: warning: Function parameter or
member 'buf' not described in 'vmw_overlay_move_buffer'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:228: warning: Function parameter or
member 'pin' not described in 'vmw_overlay_move_buffer'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:228: warning: Function parameter or
member 'inter' not described in 'vmw_overlay_move_buffer'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:253: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:253: warning: Function parameter or
member 'stream_id' not described in 'vmw_overlay_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:253: warning: Function parameter or
member 'pause' not described in 'vmw_overlay_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:253: warning: Function parameter or
member 'interruptible' not described in 'vmw_overlay_stop'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:301: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_update_stream'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:301: warning: Function parameter or
member 'buf' not described in 'vmw_overlay_update_stream'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:301: warning: Function parameter or
member 'arg' not described in 'vmw_overlay_update_stream'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:301: warning: Function parameter or
member 'interruptible' not described in 'vmw_overlay_update_stream'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:364: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_resume_all'
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:398: warning: Function parameter or
member 'dev_priv' not described in 'vmw_overlay_pause_all'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-24-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index d6d282c13b7f7..ac4a9b7222795 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -42,7 +42,7 @@ struct vmw_stream {
struct drm_vmw_control_stream_arg saved;
};
-/**
+/*
* Overlay control
*/
struct vmw_overlay {
@@ -85,7 +85,7 @@ static inline void fill_flush(struct vmw_escape_video_flush
*cmd,
cmd->flush.streamId = stream_id;
}
-/**
+/*
* Send put command to hw.
*
* Returns
@@ -174,7 +174,7 @@ static int vmw_overlay_send_put(struct vmw_private
*dev_priv,
return 0;
}
-/**
+/*
* Send stop command to hw.
*
* Returns
@@ -216,7 +216,7 @@ static int vmw_overlay_send_stop(struct vmw_private
*dev_priv,
return 0;
}
-/**
+/*
* Move a buffer to vram or gmr if @pin is set, else unpin the buffer.
*
* With the introduction of screen objects buffers could now be
@@ -235,7 +235,7 @@ static int vmw_overlay_move_buffer(struct vmw_private
*dev_priv,
return vmw_bo_pin_in_vram_or_gmr(dev_priv, buf, inter);
}
-/**
+/*
* Stop or pause a stream.
*
* If the stream is paused the no evict flag is removed from the buffer
@@ -285,7 +285,7 @@ static int vmw_overlay_stop(struct vmw_private *dev_priv,
return 0;
}
-/**
+/*
* Update a stream and send any put or stop fifo commands needed.
*
* The caller must hold the overlay lock.
@@ -353,7 +353,7 @@ static int vmw_overlay_update_stream(struct vmw_private
*dev_priv,
return 0;
}
[PATCH 42/53] drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c: In function
‘vmw_cmdbuf_res_revert’:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:162:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-40-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 92509fbf2fd1d..b262d61d839d5 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -159,7 +159,6 @@ void vmw_cmdbuf_res_commit(struct list_head *list)
void vmw_cmdbuf_res_revert(struct list_head *list)
{
struct vmw_cmdbuf_res *entry, *next;
- int ret;
list_for_each_entry_safe(entry, next, list, head) {
switch (entry->state) {
@@ -167,8 +166,7 @@ void vmw_cmdbuf_res_revert(struct list_head *list)
vmw_cmdbuf_res_free(entry->man, entry);
break;
case VMW_CMDBUF_RES_DEL:
- ret = drm_ht_insert_item(>man->resources,
->hash);
+ drm_ht_insert_item(>man->resources,
>hash);
list_del(>head);
list_add_tail(>head, >man->list);
entry->state = VMW_CMDBUF_RES_COMMITTED;
--
2.27.0
[PATCH 45/53] drm/vmwgfx/vmwgfx_cotable: Fix a couple of simple documentation problems
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c:72: warning: Function parameter or
member 'unbind_func' not described in 'vmw_cotable_info'
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c:308: warning: Function parameter or
member 'val_buf' not described in 'vmw_cotable_unbind'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-3-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index ba658fa9cf6c6..42321b9c8129f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -63,6 +63,7 @@ struct vmw_cotable {
* @min_initial_entries: Min number of initial intries at cotable allocation
* for this cotable type.
* @size: Size of each entry.
+ * @unbind_func: Unbind call-back function.
*/
struct vmw_cotable_info {
u32 min_initial_entries;
@@ -297,7 +298,7 @@ int vmw_cotable_scrub(struct vmw_resource *res, bool
readback)
*
* @res: Pointer to the cotable resource.
* @readback: Whether to read back cotable data to the backup buffer.
- * val_buf: Pointer to a struct ttm_validate_buffer prepared by the caller
+ * @val_buf: Pointer to a struct ttm_validate_buffer prepared by the caller
* for convenience / fencing.
*
* Unbinds the cotable from the device and fences the backup buffer.
--
2.27.0
[PATCH 41/53] drm/vmwgfx/vmwgfx_cmdbuf: Fix a bunch of missing or incorrectly formatted/named params
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:58: warning: Function parameter or
member 'block_submission' not described in 'vmw_cmdbuf_context'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:109: warning: cannot understand
function prototype: 'struct vmw_cmdbuf_man '
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:164: warning: Function parameter or
member 'handle' not described in 'vmw_cmdbuf_header'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:257: warning: Function parameter or
member 'header' not described in '__vmw_cmdbuf_header_free'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:380: warning: Function parameter or
member 'notempty' not described in 'vmw_cmdbuf_ctx_process'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:1168: warning: Function parameter or
member 'context' not described in 'vmw_cmdbuf_preempt'
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:1193: warning: Function parameter or
member 'context' not described in 'vmw_cmdbuf_startstop'
Cc: VMware Graphics
Cc: Roland Scheidegger
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
Signed-off-by: Zack Rusin
Link:
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-38-lee.jo...@linaro.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 45fbc41440f1e..3158924ffa852 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -48,6 +48,7 @@
* @hw_submitted: List of command buffers submitted to hardware.
* @preempted: List of preempted command buffers.
* @num_hw_submitted: Number of buffers currently being processed by hardware
+ * @block_submission: Identifies a block command submission.
*/
struct vmw_cmdbuf_context {
struct list_head submitted;
@@ -58,7 +59,7 @@ struct vmw_cmdbuf_context {
};
/**
- * struct vmw_cmdbuf_man: - Command buffer manager
+ * struct vmw_cmdbuf_man - Command buffer manager
*
* @cur_mutex: Mutex protecting the command buffer used for incremental small
* kernel command submissions, @cur.
@@ -143,7 +144,7 @@ struct vmw_cmdbuf_man {
* @cb_context: The device command buffer context.
* @list: List head for attaching to the manager lists.
* @node: The range manager node.
- * @handle. The DMA address of @cb_header. Handed to the device on command
+ * @handle: The DMA address of @cb_header. Handed to the device on command
* buffer submission.
* @cmd: Pointer to the command buffer space of this buffer.
* @size: Size of the command buffer space of this buffer.
@@ -249,7 +250,7 @@ static void vmw_cmdbuf_header_inline_free(struct
vmw_cmdbuf_header *header)
* __vmw_cmdbuf_header_free - Free a struct vmw_cmdbuf_header and its
* associated structures.
*
- * header: Pointer to the header to free.
+ * @header: Pointer to the header to free.
*
* For internal use. Must be called with man::lock held.
*/
@@ -365,10 +366,11 @@ static void vmw_cmdbuf_ctx_submit(struct vmw_cmdbuf_man
*man,
}
/**
- * vmw_cmdbuf_ctx_submit: Process a command buffer context.
+ * vmw_cmdbuf_ctx_process - Process a command buffer context.
*
* @man: The command buffer manager.
* @ctx: The command buffer context.
+ * @notempty: Pass back count of non-empty command submitted lists.
*
* Submit command buffers to hardware if possible, and process finished
* buffers. Typically freeing them, but on preemption or error take
@@ -1161,6 +1163,7 @@ static int vmw_cmdbuf_send_device_command(struct
vmw_cmdbuf_man *man,
* context.
*
* @man: The command buffer manager.
+ * @context: Device context to pass command through.
*
* Synchronously sends a preempt command.
*/
@@ -1184,6 +1187,7 @@ static int vmw_cmdbuf_preempt(struct vmw_cmdbuf_man *man,
u32 context)
* context.
*
* @man: The command buffer manager.
+ * @context: Device context to start/stop.
* @enable: Whether to enable or disable the context.
*
* Synchronously sends a device start / stop context command.
--
2.27.0
[PATCH 19/53] drm/nouveau/dispnv50/disp: Include header containing our prototypes
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous prototype for ‘nv50_display_create’ [-Wmissing-prototypes] Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 828f48d5bdd4e..cd16431422198 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -68,6 +68,8 @@ #include +#include "nv50_display.h" + /** * EVO channel */ -- 2.27.0
Re: [PATCH 08/53] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap
Hi Lee, I'm not an expert for the DC code base, but I think that this won't work. This function is not allowed to sleep and the structures are a bit large to be allocated on the heap in an atomic context. Regards, Christian. Am 03.03.21 um 14:42 schrieb Lee Jones: Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function ‘calculate_bandwidth’: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: warning: the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=] Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Colin Ian King Cc: amd-...@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: Lee Jones --- .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 29 --- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c index e633f8a51edb6..4f0474a3bbcad 100644 --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c @@ -98,16 +98,16 @@ static void calculate_bandwidth( int32_t num_cursor_lines; int32_t i, j, k; - struct bw_fixed yclk[3]; - struct bw_fixed sclk[8]; + struct bw_fixed *yclk; + struct bw_fixed *sclk; bool d0_underlay_enable; bool d1_underlay_enable; bool fbc_enabled; bool lpt_enabled; enum bw_defines sclk_message; enum bw_defines yclk_message; - enum bw_defines tiling_mode[maximum_number_of_surfaces]; - enum bw_defines surface_type[maximum_number_of_surfaces]; + enum bw_defines *tiling_mode; + enum bw_defines *surface_type; enum bw_defines voltage; enum bw_defines pipe_check; enum bw_defines hsr_check; @@ -122,6 +122,22 @@ static void calculate_bandwidth( int32_t number_of_displays_enabled_with_margin = 0; int32_t number_of_aligned_displays_with_no_margin = 0; + yclk = kcalloc(3, sizeof(*yclk), GFP_KERNEL); + if (!yclk) + return; + + sclk = kcalloc(8, sizeof(*sclk), GFP_KERNEL); + if (!sclk) + return; + + tiling_mode = kcalloc(maximum_number_of_surfaces, sizeof(*tiling_mode), GFP_KERNEL); + if (!tiling_mode) + return; + + surface_type = kcalloc(maximum_number_of_surfaces, sizeof(*surface_type), GFP_KERNEL); + if (!surface_type) + return; + yclk[low] = vbios->low_yclk; yclk[mid] = vbios->mid_yclk; yclk[high] = vbios->high_yclk; @@ -2013,6 +2029,11 @@ static void calculate_bandwidth( } } } + + kfree(tiling_mode); + kfree(surface_type); + kfree(yclk); + kfree(sclk); } /***
[PATCH 04/53] drm/amd/display/dc/bios/command_table: Remove unused variable
None of the surrounding code was removed just in case even a small
fraction of it was functional.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c: In function
‘adjust_display_pll_v2’:
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1459:35:
warning: variable ‘params’ set but not used [-Wunused-but-set-variable]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Qinglang Miao
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/bios/command_table.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index afc10b954ffa7..9d3bc3a073821 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -1517,20 +1517,14 @@ static enum bp_result adjust_display_pll_v2(
struct bp_adjust_pixel_clock_parameters *bp_params)
{
enum bp_result result = BP_RESULT_FAILURE;
- ADJUST_DISPLAY_PLL_PS_ALLOCATION params = { 0 };
/* We need to convert from KHz units into 10KHz units and then convert
* output pixel clock back 10KHz-->KHz */
uint32_t pixel_clock_10KHz_in = bp_params->pixel_clock / 10;
- params.usPixelClock = cpu_to_le16((uint16_t)(pixel_clock_10KHz_in));
- params.ucTransmitterID =
- bp->cmd_helper->encoder_id_to_atom(
- dal_graphics_object_id_get_encoder_id(
-
bp_params->encoder_object_id));
- params.ucEncodeMode =
- (uint8_t)bp->cmd_helper->encoder_mode_bp_to_atom(
- bp_params->signal_type, false);
+ bp->cmd_helper->encoder_id_to_atom(
+
dal_graphics_object_id_get_encoder_id(bp_params->encoder_object_id));
+ bp->cmd_helper->encoder_mode_bp_to_atom(bp_params->signal_type, false);
return result;
}
--
2.27.0
[PATCH 03/53] drm/msm/dp/dp_display: Remove unused variable 'hpd'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’ set but
not used [-Wunused-but-set-variable]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kuogee Hsieh
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6e1eaf2..31bf2a40a9eb2 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -493,7 +493,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
int rc = 0;
u32 sink_request;
struct dp_display_private *dp;
- struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -507,8 +506,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
return -ENODEV;
}
- hpd = dp->usbpd;
-
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
if (!rc) {
--
2.27.0
[PATCH 13/53] drm/nouveau/nouveau_bo: Remove unused variables 'dev'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set but
not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_unpopulate’:
drivers/gpu/drm/nouveau/nouveau_bo.c:1252:17: warning: variable ‘dev’ set but
not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Jeremy Kolb
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2375711877cf3..0b94f8ae77291 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1251,7 +1251,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
{
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (ttm_tt_is_populated(ttm))
@@ -1264,7 +1263,6 @@ nouveau_ttm_tt_populate(struct ttm_bo_device *bdev,
}
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_alloc(>ttm.bdev.pool, ttm, ctx);
}
@@ -1274,14 +1272,12 @@ nouveau_ttm_tt_unpopulate(struct ttm_bo_device *bdev,
struct ttm_tt *ttm)
{
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (slave)
return;
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_free(>ttm.bdev.pool, ttm);
}
--
2.27.0
[PATCH 22/53] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or member 'filp' not described in 'nouveau_compat_ioctl' drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or member 'cmd' not described in 'nouveau_compat_ioctl' drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or member 'arg' not described in 'nouveau_compat_ioctl' Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c b/drivers/gpu/drm/nouveau/nouveau_ioc32.c index 8ddf9b2325a42..2af3615c5205c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c @@ -38,7 +38,7 @@ #include "nouveau_ioctl.h" -/** +/* * Called whenever a 32-bit process running under a 64-bit kernel * performs an ioctl on /dev/dri/card. * -- 2.27.0
[PATCH 17/53] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lyude Paul
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index fd51527b56b83..bdcfd240d61c8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -169,7 +169,7 @@ headc57d_olut_load(struct drm_color_lut *in, int size, void
__iomem *mem)
writew(readw(mem - 4), mem + 4);
}
-bool
+static bool
headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
{
if (size != 0 && size != 256 && size != 1024)
--
2.27.0
[PATCH 20/53] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * file mga_ioc32.c Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c b/drivers/gpu/drm/nouveau/nouveau_ioc32.c index adf01ca9e035d..8ddf9b2325a42 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c +++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c @@ -1,4 +1,4 @@ -/** +/* * \file mga_ioc32.c * * 32-bit ioctl compatibility routines for the MGA DRM. -- 2.27.0
[PATCH 21/53] drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 1c3f890377d2c..26af6ee915368 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -811,7 +811,6 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
unsigned long addr, u64 *pfns, unsigned long npages)
{
struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
- int ret;
args->p.addr = addr;
args->p.size = npages << PAGE_SHIFT;
@@ -819,8 +818,8 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
mutex_lock(>mutex);
svmm->vmm->vmm.object.client->super = true;
- ret = nvif_object_ioctl(>vmm->vmm.object, args, sizeof(*args) +
- npages * sizeof(args->p.phys[0]), NULL);
+ nvif_object_ioctl(>vmm->vmm.object, args, sizeof(*args) +
+ npages * sizeof(args->p.phys[0]), NULL);
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(>mutex);
--
2.27.0
A long standing issue with RAM usage reporting
Hello everyone, I'd love to bring kernel developers' attention to this long standing issue: https://bugzilla.kernel.org/show_bug.cgi?id=201675 It would be great if something was done about it because otherwise htop, top and free and numerous other utilities in Linux have to implement hacks and workarounds to properly report free/used RAM. https://github.com/htop-dev/htop/issues/556 https://gitlab.com/procps-ng/procps/-/issues/196 There's also another related issue: https://bugzilla.kernel.org/show_bug.cgi?id=201673 but it will be automatically solved once the initial bug report has been dealt with. Best regards, Artem
lkml delivery: was: Re: [PATCH next v4 00/15] printk: remove logbuf_lock
Hi John, On Wed 2021-03-03 11:15:13, John Ogness wrote: > Hello, > > Here is v4 of a series to remove @logbuf_lock, exposing the > ringbuffer locklessly to both readers and writers. v3 is > here [0]. Have you got some reply from lkml that it has not delivered there, please? I am not able to get the patchset using b4 tool: $> b4 am -o test 20210303101528.29901-1-john.ogn...@linutronix.de Looking up https://lore.kernel.org/r/20210303101528.29901-1-john.ogness%40linutronix.de Grabbing thread from lore.kernel.org/linux-hyperv Analyzing 2 messages in the thread --- Thread incomplete, attempting to backfill Grabbing thread from lore.kernel.org/lkml Server returned an error: 404 Grabbing thread from lore.kernel.org/linux-mtd Server returned an error: 404 Grabbing thread from lore.kernel.org/linuxppc-dev Loaded 2 messages from https://lore.kernel.org/linuxppc-dev/ --- Writing test/v4_20210303_john_ogness_printk_remove_logbuf_lock.mbx ERROR: missing [1/15]! ERROR: missing [2/15]! ERROR: missing [3/15]! ERROR: missing [4/15]! ERROR: missing [5/15]! ERROR: missing [6/15]! ERROR: missing [7/15]! ERROR: missing [8/15]! ERROR: missing [9/15]! ERROR: missing [10/15]! [PATCH next v4 11/15] printk: kmsg_dumper: remove @active field ✓ [PATCH next v4 12/15] printk: introduce a kmsg_dump iterator ERROR: missing [13/15]! [PATCH next v4 14/15] printk: kmsg_dump: remove _nolock() variants ERROR: missing [15/15]! --- Total patches: 3 --- WARNING: Thread incomplete! Cover: test/v4_20210303_john_ogness_printk_remove_logbuf_lock.cover Link: https://lore.kernel.org/r/20210303101528.29901-1-john.ogn...@linutronix.de Base: not found git am test/v4_20210303_john_ogness_printk_remove_logbuf_lock.mbx and I do not see it at lore. It has only found copies in linux-hyperv and linux-ppcdev mailing lists, see https://lore.kernel.org/lkml/20210303101528.29901-2-john.ogn...@linutronix.de/ Best Regards, Petr
Re: [PATCH] recordmcount: Fix the wrong use of w* in arm64_is_fake_mcount()
On Tue, Mar 02, 2021 at 05:33:35PM -0500, Steven Rostedt wrote: > On Tue, 2 Mar 2021 17:30:58 -0500 > Steven Rostedt wrote: > > > I just realized that I received this patch twice, and thought it was the > > same patch! Chen was three days ahead of you, so he get's the credit ;-) > > > > https://lore.kernel.org/r/20210222135840.56250-1-chenjun...@huawei.com > > I'm applying this patch (same one here but came earlier). > > Will, you still OK with your acked-by on it? Absolutely! Will
Re: [PATCH v6 09/40] xattr: handle idmapped mounts
Christian Brauner wrote:
> diff --git a/fs/cachefiles/xattr.c b/fs/cachefiles/xattr.c
> index 72e42438f3d7..a591b5e09637 100644
> --- a/fs/cachefiles/xattr.c
> +++ b/fs/cachefiles/xattr.c
> @@ -39,8 +39,8 @@ int cachefiles_check_object_type(struct cachefiles_object
> *object)
> _enter("%p{%s}", object, type);
>
> /* attempt to install a type label directly */
> - ret = vfs_setxattr(dentry, cachefiles_xattr_cache, type, 2,
> -XATTR_CREATE);
> + ret = vfs_setxattr(_user_ns, dentry, cachefiles_xattr_cache, type,
> +2, XATTR_CREATE);
Actually, on further consideration, this might be the wrong thing to do in
cachefiles. The creds are (or should be) overridden when accesses to the
underlying filesystem are being made.
I wonder if this should be using current_cred()->user_ns or
cache->cache_cred->user_ns instead.
David
Re: Why do kprobes and uprobes singlestep?
On 03/02, Alexei Starovoitov wrote: > > Especially if such tightening will come with performance boost for > uprobe on a nop and unprobe at the start (which is typically push or > alu on %sp). > That would be a great step forward. Just in case, nop and push are emulated without additional overhead. Oleg.
Re: [External] Re: [PATCH v2] mm: memcontrol: fix kernel stack account
On Wed, Mar 3, 2021 at 6:25 PM Michal Hocko wrote:
>
> On Wed 03-03-21 17:39:56, Muchun Song wrote:
> > For simplification 991e7673859e ("mm: memcontrol: account kernel stack
> > per node") has changed the per zone vmalloc backed stack pages
> > accounting to per node. By doing that we have lost a certain precision
> > because those pages might live in different NUMA nodes. In the end
> > NR_KERNEL_STACK_KB exported to the userspace might be over estimated on
> > some nodes while underestimated on others.
> >
> > This doesn't impose any real problem to correctnes of the kernel
> > behavior as the counter is not used for any internal processing but it
> > can cause some confusion to the userspace.
>
> You have skipped over one part of the changelog I have proposed and that
> is to provide an actual data.
Because this is a problem I found by looking at the code, not a real world
problem. I do not have any actual data. :-(
>
> > Address the problem by accounting each vmalloc backing page to its own
> > node.
> >
> > Fixes: 991e7673859e ("mm: memcontrol: account kernel stack per node")
>
> Fixes tag might make somebody assume this is worth backporting but I
> highly doubt so.
OK. I can remove the Fixes tag.
>
> > Signed-off-by: Muchun Song
> > Reviewed-by: Shakeel Butt
>
> Anyway
> Acked-by: Michal Hocko
Thanks for your review.
>
> as the patch is correct with one comment below
>
> > ---
> > Changelog in v2:
> > - Rework commit log suggested by Michal.
> >
> > Thanks to Michal and Shakeel for review.
> >
> > kernel/fork.c | 15 ++-
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index d66cd1014211..6e2201feb524 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -379,14 +379,19 @@ static void account_kernel_stack(struct task_struct
> > *tsk, int account)
> > void *stack = task_stack_page(tsk);
> > struct vm_struct *vm = task_stack_vm_area(tsk);
> >
> > + if (vm) {
> > + int i;
> >
> > - /* All stack pages are in the same node. */
> > - if (vm)
> > - mod_lruvec_page_state(vm->pages[0], NR_KERNEL_STACK_KB,
> > - account * (THREAD_SIZE / 1024));
> > - else
> > + BUG_ON(vm->nr_pages != THREAD_SIZE / PAGE_SIZE);
>
> I do not think we need this BUG_ON. What kind of purpose does it serve?
vm->nr_pages should be always equal to THREAD_SIZE / PAGE_SIZE
if the system is not corrupted. It makes sense to remove the BUG_ON.
I will remove it in the next version. Thanks.
>
> > +
> > + for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++)
> > + mod_lruvec_page_state(vm->pages[i],
> > NR_KERNEL_STACK_KB,
> > + account * (PAGE_SIZE / 1024));
> > + } else {
> > + /* All stack pages are in the same node. */
> > mod_lruvec_kmem_state(stack, NR_KERNEL_STACK_KB,
> > account * (THREAD_SIZE / 1024));
> > + }
> > }
> >
> > static int memcg_charge_kernel_stack(struct task_struct *tsk)
> > --
> > 2.11.0
>
> --
> Michal Hocko
> SUSE Labs
Re: [PATCH v3] ARM: imx: avic: Convert to using IRQCHIP_DECLARE
On Thu, Feb 04, 2021 at 05:38:46PM -0800, Saravana Kannan wrote:
> Using IRQCHIP_DECLARE lets fw_devlink know that it should not wait for
> these interrupt controllers to be populated as struct devices. Without
> this change, fw_devlink=on will make the consumers of these interrupt
> controllers wait for the struct device to be added and thereby block the
> consumers' probes forever. Converting to IRQCHIP_DECLARE addresses boot
> issues on imx25 with fw_devlink=on that were reported by Martin.
>
> This also removes a lot of boilerplate code.
>
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Reported-by: Martin Kaiser
> Signed-off-by: Saravana Kannan
> Tested-by: Martin Kaiser
Applied, thanks.
Re: [PATCH v3 RFC 14/14] mm: speedup page alloc for MPOL_PREFERRED_MANY by adding a NO_SLOWPATH gfp bit
On Wed, Mar 03, 2021 at 01:32:11PM +0100, Michal Hocko wrote: > On Wed 03-03-21 20:18:33, Feng Tang wrote: > > On Wed, Mar 03, 2021 at 08:07:17PM +0800, Tang, Feng wrote: > > > Hi Michal, > > > > > > On Wed, Mar 03, 2021 at 12:39:57PM +0100, Michal Hocko wrote: > > > > On Wed 03-03-21 18:20:58, Feng Tang wrote: > > > > > When doing broader test, we noticed allocation slowness in one test > > > > > case that malloc memory with size which is slightly bigger than free > > > > > memory of targeted nodes, but much less then the total free memory > > > > > of system. > > > > > > > > > > The reason is the code enters the slowpath of > > > > > __alloc_pages_nodemask(), > > > > > which takes quite some time. As alloc_pages_policy() will give it a > > > > > 2nd > > > > > try with NULL nodemask, so there is no need to enter the slowpath for > > > > > the first try. Add a new gfp bit to skip the slowpath, so that user > > > > > cases > > > > > like this can leverage. > > > > > > > > > > With it, the malloc in such case is much accelerated as it never > > > > > enters > > > > > the slowpath. > > > > > > > > > > Adding a new gfp_mask bit is generally not liked, and another idea is > > > > > to > > > > > add another nodemask to struct 'alloc_context', so it has 2: > > > > > 'preferred-nmask' > > > > > and 'fallback-nmask', and they will be tried in turn if not NULL, with > > > > > it we can call __alloc_pages_nodemask() only once. > > > > > > > > Yes, it is very much disliked. Is there any reason why you cannot use > > > > GFP_NOWAIT for that purpose? > > > > > > I did try that at the first place, but it didn't obviously change the > > > slowness. > > > I assumed the direct claim was still involved as GFP_NOWAIT only impact > > > kswapd > > > reclaim. > > I assume you haven't really created gfp mask correctly. What was the > exact gfp mask you have used? The testcase is a malloc with multi-preferred-node policy, IIRC, the gfp mask is HIGHUSER_MOVABLE originally, and code here ORs (__GFP_RETRY_MAYFAIL | __GFP_NOWARN). As GFP_WAIT == __GFP_KSWAPD_RECLAIM, in this test case, the bit is already set. > > > > One thing I tried which can fix the slowness is: > > > > + gfp_mask &= ~(__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM); > > > > which explicitly clears the 2 kinds of reclaim. And I thought it's too > > hacky and didn't mention it in the commit log. > > Clearing __GFP_DIRECT_RECLAIM would be the right way to achieve > GFP_NOWAIT semantic. Why would you want to exclude kswapd as well? When I tried gfp_mask &= ~__GFP_DIRECT_RECLAIM, the slowness couldn't be fixed. Thanks, Feng > -- > Michal Hocko > SUSE Labs
Re: [PATCH v5 04/16] rpmsg: char: export eptdev create an destroy functions
Hi Mathieu,
On 3/2/21 6:57 PM, Mathieu Poirier wrote:
> Good morning,
>
> I have started to review this set - comments will be staggered over several
> days.
>
> On Fri, Feb 19, 2021 at 12:14:49PM +0100, Arnaud Pouliquen wrote:
>> To prepare the split code related to the control and the endpoint
>> devices in separate files:
>> - suppress the dependency with the rpmsg_ctrldev struct,
>> - rename and export the functions in rpmsg_char.h.
>>
>> Suggested-by: Mathieu Poirier
>> Signed-off-by: Arnaud Pouliquen
>> ---
>> drivers/rpmsg/rpmsg_char.c | 22 ++--
>> drivers/rpmsg/rpmsg_char.h | 51 ++
>> 2 files changed, 66 insertions(+), 7 deletions(-)
>> create mode 100644 drivers/rpmsg/rpmsg_char.h
>>
>> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
>> index 9e33b53bbf56..78a6d19fdf82 100644
>> --- a/drivers/rpmsg/rpmsg_char.c
>> +++ b/drivers/rpmsg/rpmsg_char.c
>> @@ -1,5 +1,6 @@
>> // SPDX-License-Identifier: GPL-2.0
>> /*
>> + * Copyright (C) 2021, STMicroelectronics
>> * Copyright (c) 2016, Linaro Ltd.
>> * Copyright (c) 2012, Michal Simek
>> * Copyright (c) 2012, PetaLogix
>> @@ -22,6 +23,7 @@
>> #include
>> #include
>>
>> +#include "rpmsg_char.h"
>> #include "rpmsg_internal.h"
>>
>> #define RPMSG_DEV_MAX (MINORMASK + 1)
>> @@ -78,7 +80,7 @@ struct rpmsg_eptdev {
>> wait_queue_head_t readq;
>> };
>>
>> -static int rpmsg_eptdev_destroy(struct device *dev, void *data)
>> +static int rpmsg_eptdev_destroy(struct device *dev)
>> {
>> struct rpmsg_eptdev *eptdev = dev_to_eptdev(dev);
>>
>> @@ -277,7 +279,7 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned
>> int cmd,
>> if (cmd != RPMSG_DESTROY_EPT_IOCTL)
>> return -EINVAL;
>>
>> -return rpmsg_eptdev_destroy(>dev, NULL);
>> +return rpmsg_eptdev_destroy(>dev);
>> }
>>
>> static const struct file_operations rpmsg_eptdev_fops = {
>> @@ -336,10 +338,15 @@ static void rpmsg_eptdev_release_device(struct device
>> *dev)
>> kfree(eptdev);
>> }
>>
>> -static int rpmsg_eptdev_create(struct rpmsg_ctrldev *ctrldev,
>> +int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
>> +{
>> +return rpmsg_eptdev_destroy(dev);
>> +}
>> +EXPORT_SYMBOL(rpmsg_chrdev_eptdev_destroy);
>
> Below we have rpmsg_chrdev_create_eptdev() so it would make sense to have
> rpmsg_chrdev_destroy_ept().
>
> I would also rename rpmsg_eptdev_destroy() to rpmsg_chrdev_destroy_ept() and
> export that symbol rather than introducing a function that only calls another
> one. You did exactly that for rpmsg_chrdev_create_eptdev().
This function is used in rpmsg_ctrl to remove eptdev devices.
As device_for_each_child request a specific function prototype I do not only
export but change function prototype.
I can squash all in one function but that means that the "data" parameter is
just always unused.
>
>> +
>> +int rpmsg_chrdev_create_eptdev(struct rpmsg_device *rpdev, struct device
>> *parent,
>> struct rpmsg_channel_info chinfo)
>> {
>> -struct rpmsg_device *rpdev = ctrldev->rpdev;
>> struct rpmsg_eptdev *eptdev;
>> struct device *dev;
>> int ret;
>> @@ -359,7 +366,7 @@ static int rpmsg_eptdev_create(struct rpmsg_ctrldev
>> *ctrldev,
>>
>> device_initialize(dev);
>> dev->class = rpmsg_class;
>> -dev->parent = >dev;
>> +dev->parent = parent;
>> dev->groups = rpmsg_eptdev_groups;
>> dev_set_drvdata(dev, eptdev);
>>
>> @@ -402,6 +409,7 @@ static int rpmsg_eptdev_create(struct rpmsg_ctrldev
>> *ctrldev,
>>
>> return ret;
>> }
>> +EXPORT_SYMBOL(rpmsg_chrdev_create_eptdev);
>>
>> static int rpmsg_ctrldev_open(struct inode *inode, struct file *filp)
>> {
>> @@ -441,7 +449,7 @@ static long rpmsg_ctrldev_ioctl(struct file *fp,
>> unsigned int cmd,
>> chinfo.src = eptinfo.src;
>> chinfo.dst = eptinfo.dst;
>>
>> -return rpmsg_eptdev_create(ctrldev, chinfo);
>> +return rpmsg_chrdev_create_eptdev(ctrldev->rpdev, >dev,
>> chinfo);
>
> Not sure why we have to change the signature of rpmsg_eptdev_create() but I
> may
> find an answer to that question later on in the patchset.
Here I need to break dependency with rpmsg_ctrldev that will move to the
rpmsg_ctrl.c. rpmsg_eptdev_create doesn't need it but just parent devices to be
attached to.
I will add more explicit information about this, in the commit message.
Thanks,
Arnaud
>
>> };
>>
>> static const struct file_operations rpmsg_ctrldev_fops = {
>> @@ -527,7 +535,7 @@ static void rpmsg_chrdev_remove(struct rpmsg_device
>> *rpdev)
>> int ret;
>>
>> /* Destroy all endpoints */
>> -ret = device_for_each_child(>dev, NULL, rpmsg_eptdev_destroy);
>> +ret = device_for_each_child(>dev, NULL,
>> rpmsg_chrdev_eptdev_destroy);
>> if (ret)
>> dev_warn(>dev, "failed to nuke endpoints: %d\n", ret);
>>
>> diff --git
Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames
On 2021-03-03 00:30, Jakub Kicinski wrote: On Tue, 02 Mar 2021 08:04:20 +0100 Martin Schiller wrote: On 2021-03-01 09:56, Xie He wrote: > On Sun, Feb 28, 2021 at 10:56 PM Martin Schiller wrote: >> I mean the change from only one hdlc interface to both hdlc and >> hdlc_x25. >> >> I can't estimate how many users are out there and how their setup >> looks >> like. > > I'm also thinking about solving this issue by adding new APIs to the > HDLC subsystem (hdlc_stop_queue / hdlc_wake_queue) for hardware > drivers to call instead of netif_stop_queue / netif_wake_queue. This > way we can preserve backward compatibility. > > However I'm reluctant to change the code of all the hardware drivers > because I'm afraid of introducing bugs, etc. When I look at the code > of "wan/lmc/lmc_main.c", I feel I'm not able to make sure there are no > bugs (related to stop_queue / wake_queue) after my change (and even > before my change, actually). There are even serious style problems: > the majority of its lines are indented by spaces. > > So I don't want to mess with all the hardware drivers. Hardware driver > developers (if they wish to properly support hdlc_x25) should do the > change themselves. This is not a problem for me, because I use my own > out-of-tree hardware driver. However if I add APIs with no user code > in the kernel, other developers may think these APIs are not > necessary. I don't think a change that affects the entire HDLC subsystem is justified, since the actual problem only affects the hdlc_x25 area. The approach with the additional hdlc_x25 is clean and purposeful and I personally could live with it. I just don't see myself in the position to decide such a change at the moment. @Jakub: What is your opinion on this. Hard question to answer, existing users seem happy and Xie's driver isn't upstream, so the justification for potentially breaking backward compatibility isn't exactly "strong". Can we cop out and add a knob somewhere to control spawning the extra netdev? Let people who just want a newer kernel carry on without distractions and those who want the extra layer can flip the switch? Yes, that would be a good compromise. I think a compile time selection option is enough here. We could introduce a new config option CONFIG_HDLC_X25_LEGACY (or something like that) and then implement the new or the old behavior in the driver accordingly. A switch that can be toggled at runtime (e.g. via sethdlc) would also be conceivable, but I don't think this is necessary.
Re: [RESEND 1/1] arch: arm: mach-at91: pm: Move prototypes to mutually included header
On 03/03/2021 12:41:49+, Lee Jones wrote:
> Both the caller and the supplier's source file should have access to
> the include file containing the prototypes.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/pinctrl/pinctrl-at91.c:1637:6: warning: no previous prototype for
> ‘at91_pinctrl_gpio_suspend’ [-Wmissing-prototypes]
> 1637 | void at91_pinctrl_gpio_suspend(void)
> | ^
> drivers/pinctrl/pinctrl-at91.c:1661:6: warning: no previous prototype for
> ‘at91_pinctrl_gpio_resume’ [-Wmissing-prototypes]
> 1661 | void at91_pinctrl_gpio_resume(void)
> | ^~~~
>
> Cc: Russell King
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Signed-off-by: Lee Jones
I'm pretty sure you had my ack on v3 ;)
Acked-by: Alexandre Belloni
or again, alternatively, I can apply it with Linus' ack
> ---
> arch/arm/mach-at91/pm.c| 19 ---
> drivers/pinctrl/pinctrl-at91.c | 2 ++
> include/soc/at91/pm.h | 16
> 3 files changed, 26 insertions(+), 11 deletions(-)
> create mode 100644 include/soc/at91/pm.h
>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 120f9aa6fff32..90dcdfe3b3d0d 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -17,6 +17,8 @@
> #include
> #include
>
> +#include
> +
> #include
> #include
> #include
> @@ -25,17 +27,6 @@
> #include "generic.h"
> #include "pm.h"
>
> -/*
> - * FIXME: this is needed to communicate between the pinctrl driver and
> - * the PM implementation in the machine. Possibly part of the PM
> - * implementation should be moved down into the pinctrl driver and get
> - * called as part of the generic suspend/resume path.
> - */
> -#ifdef CONFIG_PINCTRL_AT91
> -extern void at91_pinctrl_gpio_suspend(void);
> -extern void at91_pinctrl_gpio_resume(void);
> -#endif
> -
> struct at91_soc_pm {
> int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
> int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
> @@ -326,6 +317,12 @@ static void at91_pm_suspend(suspend_state_t state)
> static int at91_pm_enter(suspend_state_t state)
> {
> #ifdef CONFIG_PINCTRL_AT91
> + /*
> + * FIXME: this is needed to communicate between the pinctrl driver and
> + * the PM implementation in the machine. Possibly part of the PM
> + * implementation should be moved down into the pinctrl driver and get
> + * called as part of the generic suspend/resume path.
> + */
> at91_pinctrl_gpio_suspend();
> #endif
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index 8003d1bd16953..fc61aaec34cc9 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -23,6 +23,8 @@
> /* Since we request GPIOs from ourself */
> #include
>
> +#include
> +
> #include "pinctrl-at91.h"
> #include "core.h"
>
> diff --git a/include/soc/at91/pm.h b/include/soc/at91/pm.h
> new file mode 100644
> index 0..7a41e53a3ffa3
> --- /dev/null
> +++ b/include/soc/at91/pm.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Atmel Power Management
> + *
> + * Copyright (C) 2020 Atmel
> + *
> + * Author: Lee Jones
> + */
> +
> +#ifndef __SOC_ATMEL_PM_H
> +#define __SOC_ATMEL_PM_H
> +
> +void at91_pinctrl_gpio_suspend(void);
> +void at91_pinctrl_gpio_resume(void);
> +
> +#endif /* __SOC_ATMEL_PM_H */
> --
> 2.27.0
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 1/8] ARM: ARMv7-M: Fix register restore corrupt after svc call
Hi Vladimir,
Thanks for the review.
On Wed, Mar 3, 2021 at 5:52 PM Vladimir Murzin wrote:
>
> On 3/3/21 8:05 AM, dillon.min...@gmail.com wrote:
> > From: dillon min
> >
> > For some case, kernel not boot by u-boot(single thread),
> > but by rtos , as most rtos use pendsv to do context switch.
>
>
> Hmm, does it mean that it starts kernel from process context?
Yes, kernel might be started from process context, since u-boot not
switch context, so kernel always startup under msp.
>
> I'd assume that it is not only kernel who expects MSP. So, what
> if RTOS you mentioned want to boot other RTOS (even itself)? What
> if you have no access to the source code for those RTOS(es) to
> patch MSP/PSP switch?
My case is a little complicated.
stm32h7 only have 128Kbytes internal flash, can't store u-boot.bin (>200K),
so, set a bootloader (rt-thread rtos) to internal flash, load
linux/u-boot from serial port via ymodem
store to qspi flash(8Mbytes), then jump to u-boot.
qspi flash layout:
0 - 512K:u-boot
512K- 8M : kernel(xip)
load process : rt-thread -> u-boot -> linux
before add psp/msp check after svc call, register restore corrupt.
add a printhex8 around svc call, found the sp stack is 0x2404c0ffcff8
it should be 0xc0ffcdf8c0ffcff8. 0x2404 is the sp stack address
assigned by u-boot
i've no idea how it's become to u-boot's sp.
I have the rtos code, and will try to fix it on the rtos side.
Can you give more explanation about why linux relies on MSP ? thanks
>
> I'd very much prefer to keep stack switching logic outside kernel,
> say, in some shim which RTOS/bootloader can maintain.
>
> Cheers
> Vladimir
>
> >
> > So, we need add an lr check after svc call, to find out should
> > use psp or msp. else register restore after svc call might be
> > corrupted.
> >
> > Fixes: b70cd406d7fe ("ARM: 8671/1: V7M: Preserve registers across switch
> > from Thread to Handler mode")
> > Signed-off-by: dillon min
> > ---
> > arch/arm/mm/proc-v7m.S | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
> > index 84459c1d31b8..c93d2757312d 100644
> > --- a/arch/arm/mm/proc-v7m.S
> > +++ b/arch/arm/mm/proc-v7m.S
> > @@ -137,7 +137,10 @@ __v7m_setup_cont:
> > 1: cpsid i
> > /* Calculate exc_ret */
> > orr r10, lr, #EXC_RET_THREADMODE_PROCESSSTACK
> > - ldmia sp, {r0-r3, r12}
> > + tst lr, #EXC_RET_STACK_MASK
> > + mrsne r4, psp
> > + moveq r4, sp
> > + ldmia r4!, {r0-r3, r12}
> > str r5, [r12, #11 * 4] @ restore the original SVC vector
> > entry
> > mov lr, r6 @ restore LR
> >
> >
>
Re: arch/powerpc/sysdev/xive/common.c:279 xmon_xive_get_irq_config() warn: variable dereferenced before check 'd' (see line 261)
On 2/27/21 10:30 AM, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 8b83369ddcb3fb9cab5c1088987ce477565bb630
> commit: 97ef275077932c65b1b8ec5022abd737a9fbf3e0 powerpc/xive: Fix xmon
> support on the PowerNV platform
> config: powerpc64-randconfig-m031-20210226 (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
>
> smatch warnings:
> arch/powerpc/sysdev/xive/common.c:279 xmon_xive_get_irq_config() warn:
> variable dereferenced before check 'd' (see line 261)
Yes. That's ugly :/
I would prefer to address this issue after the cleanup provided
by the patchset adding an IRQ domain for IPIs.
http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=228762
Most of the mess comes from the XIVE IPI HW IRQ number which
hijacks IRQ number 0. It should be easier after this is fixed.
Thanks,
C.
> vim +/d +279 arch/powerpc/sysdev/xive/common.c
>
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 259 int
> xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)
> b4868ff55d082bc Cédric Le Goater 2019-08-14 260 {
> 97ef275077932c6 Cédric Le Goater 2020-03-06 @261 struct irq_chip *chip =
> irq_data_get_irq_chip(d);
>
> ^
> Dereferenced inside function
>
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 262 int rc;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 263 u32 target;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 264 u8 prio;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 265 u32 lirq;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 266
> 97ef275077932c6 Cédric Le Goater 2020-03-06 267 if (!is_xive_irq(chip))
> 97ef275077932c6 Cédric Le Goater 2020-03-06 268 return -EINVAL;
> 97ef275077932c6 Cédric Le Goater 2020-03-06 269
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 270 rc =
> xive_ops->get_irq_config(hw_irq, , , );
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 271 if (rc) {
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 272
> xmon_printf("IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 273 return rc;
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 274 }
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 275
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 276 xmon_printf("IRQ 0x%08x
> : target=0x%x prio=%02x lirq=0x%x ",
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 277 hw_irq,
> target, prio, lirq);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 278
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 @279 if (d) {
> ^^
> Checked too late
>
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 280 struct
> xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 281 u64 val =
> xive_esb_read(xd, XIVE_ESB_GET);
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 282
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 283
> xmon_printf("PQ=%c%c",
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 284 val
> & XIVE_ESB_VAL_P ? 'P' : '-',
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 285 val
> & XIVE_ESB_VAL_Q ? 'Q' : '-');
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 286 }
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 287
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 288 xmon_printf("\n");
> 5896163f7f91c05 Cédric Le Goater 2019-09-10 289 return 0;
> b4868ff55d082bc Cédric Le Goater 2019-08-14 290 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
Re: [PATCH next v4 07/15] printk: introduce CONSOLE_LOG_MAX
On Wed 2021-03-03 11:15:20, John Ogness wrote: > Instead of using "LOG_LINE_MAX + PREFIX_MAX" for temporary buffer > sizes, introduce CONSOLE_LOG_MAX. This represents the maximum size > that is allowed to be printed to the console for a single record. > > Signed-off-by: John Ogness Reviewed-by: Petr Mladek Best Regards, Petr
Re: [PATCH] ASoC: hdmi-codec: fix platform_no_drv_owner.cocci warnings
Hi Yang, On Wed, Mar 3, 2021 at 5:54 AM Yang Li wrote: > > ./sound/soc/fsl/imx-hdmi.c:226:3-8: No need to set .owner here. The core > will do it. > > Remove .owner field if calls are used which set it automatically > > Reported-by: Abaci Robot > Signed-off-by: Yang Li The patch looks good, but please send a v2 with the correct Subject. It should mention imx-hdmi instead of hdmi-codec. Thanks
Re: [PATCH 2/2] mm: fs: Invalidate BH LRU during page migration
Hi Minchan,
I love your patch! Yet something to improve:
[auto build test ERROR on block/for-next]
[also build test ERROR on linux/master linus/master v5.12-rc1 next-20210303]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Minchan-Kim/mm-disable-LRU-pagevec-during-the-migration-temporarily/20210303-191809
base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
for-next
config: arm-randconfig-r031-20210303 (attached as .config)
compiler: arm-linux-gnueabi-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://github.com/0day-ci/linux/commit/a1c74fba81d1258e320ef52bc995cb0333e3e083
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Minchan-Kim/mm-disable-LRU-pagevec-during-the-migration-temporarily/20210303-191809
git checkout a1c74fba81d1258e320ef52bc995cb0333e3e083
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
mm/swap.c: In function 'lru_add_drain_cpu':
>> mm/swap.c:671:2: error: implicit declaration of function
>> 'invalidate_bh_lru'; did you mean 'invalidate_bdev'?
>> [-Werror=implicit-function-declaration]
671 | invalidate_bh_lru(NULL);
| ^
| invalidate_bdev
mm/swap.c: At top level:
mm/swap.c:874:6: error: conflicting types for 'lru_add_drain_all'
874 | void lru_add_drain_all(void)
| ^
In file included from mm/swap.c:20:
include/linux/swap.h:348:13: note: previous declaration of
'lru_add_drain_all' was here
348 | extern void lru_add_drain_all(bool force_all_cpus);
| ^
cc1: some warnings being treated as errors
vim +671 mm/swap.c
634
635 /*
636 * Drain pages out of the cpu's pagevecs.
637 * Either "cpu" is the current CPU, and preemption has already been
638 * disabled; or "cpu" is being hot-unplugged, and is already dead.
639 */
640 void lru_add_drain_cpu(int cpu)
641 {
642 struct pagevec *pvec = _cpu(lru_pvecs.lru_add, cpu);
643
644 if (pagevec_count(pvec))
645 __pagevec_lru_add(pvec);
646
647 pvec = _cpu(lru_rotate.pvec, cpu);
648 /* Disabling interrupts below acts as a compiler barrier. */
649 if (data_race(pagevec_count(pvec))) {
650 unsigned long flags;
651
652 /* No harm done if a racing interrupt already did this
*/
653 local_lock_irqsave(_rotate.lock, flags);
654 pagevec_lru_move_fn(pvec, pagevec_move_tail_fn);
655 local_unlock_irqrestore(_rotate.lock, flags);
656 }
657
658 pvec = _cpu(lru_pvecs.lru_deactivate_file, cpu);
659 if (pagevec_count(pvec))
660 pagevec_lru_move_fn(pvec, lru_deactivate_file_fn);
661
662 pvec = _cpu(lru_pvecs.lru_deactivate, cpu);
663 if (pagevec_count(pvec))
664 pagevec_lru_move_fn(pvec, lru_deactivate_fn);
665
666 pvec = _cpu(lru_pvecs.lru_lazyfree, cpu);
667 if (pagevec_count(pvec))
668 pagevec_lru_move_fn(pvec, lru_lazyfree_fn);
669
670 activate_page_drain(cpu);
> 671 invalidate_bh_lru(NULL);
672 }
673
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent
On Wed, Mar 3, 2021 at 11:38 AM Krzysztof Kozlowski wrote: > On Wed, Mar 03, 2021 at 11:30:38AM +0100, Greg Kroah-Hartman wrote: > > On Wed, Mar 03, 2021 at 11:24:01AM +0100, Krzysztof Kozlowski wrote: > > > On 03/03/2021 03:26, taehyun cho wrote: > > > > 'ARCH_EXYNOS' is not suitable for DWC3_EXYNOS config. > > > > 'USB_DWC3_EXYNOS' is glue layer which can be used with > > > > Synopsys DWC3 controller on Exynos SoCs. USB_DWC3_EXYNOS' > > > > can be used from Exynos5 to Exynos9. > > > > > > > > Signed-off-by: taehyun cho > > > > > > NACK because you ignored comments from March. Please respond to them > > > instead > > > of resending the same patch. > > > > > > Anyway, when resending you need to version your patches and explain the > > > differences. Please also Cc reviewers and other maintainers. I pointed out > > > this before: > > > scripts/get_maintainer.pl -f drivers/usb/dwc3/dwc3-exynos.c > > > > > > The driver - in current form - should not be available for other > > > architectures. It would clutter other platforms and kernel config > > > selection. > > > If you want to change this, you need to provide rationale (usually by > > > adding > > > support to new non-Exynos platform). > > > > No, these crazy "ARCH_FOO" things need to go away. For systems that > > want to build "universal" kernels, why are they being forced to enable > > "ARCH_*" just so they can pick specific drivers? That is not done on > > other architectures, why is ARM64 so "special" in this regard. > > > > How do you "know" that these cores/devices are tied to specific ARCH_ > > platforms? We don't, so that dependency should not be there. > > > > Just let any arch pick any driver if it can be built, you never know > > what it might be run on. Removing ARCH_ dependencies in Kconfig files > > is a good thing, please do not discourage that from happening. > > It's getting more generic topic, so let me Cc Arnd and Guenter (I think > once I discussed this with Guenter around watchdog). > > This is so far component of a SoC, so it cannot be re-used outside of > SoC. Unless it appears in a new SoC (just like recent re-use of Samsung > serial driver for Apple M1). Because of the architecture, you cannot > build universal kernel without ARCH_EXYNOS. You need it. Otherwise the > kernel won't boot on hardware with DWC Exynos. > > Since DWC Exynos won't work without ARCH_EXYNOS - the user will not get > any usable binary - I think all, or almost all, SoC specific drivers are > limited per ARCH. This limits the amount of choices for distro people > and other kernel configuring folks, so they won't have to consider > useless options. > > Anyway, that's the convention or consensus so far for entire SoC. If we > want to change it - sure, but let's make it for everyone, not for just > this one USB driver. I think we should keep it like this, and have most platform specific drivers be guarded in Kconfig like this. There are two main advantages for this: - Linus has mentioned several times that he does not want to be asked about new drivers that cannot run on x86 when doing 'make oldconfig', and I'm fairly sure this applies to other users as well. Life is too short to know 19000 Kconfig symbols and whether you should enable them or not. Drivers tend to not be tied to an instruction set, so if a driver is used on mips32, arm32 and arm64, but is tied to a particular SoC manufacturer, it should only need to depend on that platform (|| COMPILE_TEST). - A default config enables tons of device drivers, most of which are only ever used on a small number of SoCs. I like the convenience of being able to turn a generic config into one for my particular SoC by turning off all other platforms, and letting the platform specific drivers disappear because of the dependency. There are two related points: - For the specific question of drivers like DWC3_EXYNOS, I would indeed like to see fewer questions asked, and more of the customization done in a generic driver. The same is true for a lot of designware drivers (ethernet, pci, mmc, ...) and similar IP blocks from other vendors. We know these are all the same hardware design, just wired up in slightly different ways, but without help from the hardware designers we have no good way to come up with a generic driver that understands all the possible ways it can be wired up. - I don't like the way we deal with a lot of platform specific irqchip and clocksource drivers. Unlike most other subsystems, these drivers just get selected implicitly from a platform specific Kconfig symbol. The main disadvantage is that this is inconsistent with the rest of the kernel, but there is also a more general problem with the use of 'select' that causes a couple of issues when used too much. Arnd
Re: [PATCH v2 2/2] arm64: dts: fsl: add support for Kontron pitx-imx8m board
Hi Heiko,
On Wed, Mar 3, 2021 at 9:54 AM Heiko Thiery wrote:
> > reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
>
> I used the same name as used on imx8mq-evk. Do you think a better name
> is the one you proposed?
Yes, the way I proposed is the preferred one. Thanks
[rcu:dev.2021.02.26a] BUILD SUCCESS 4ee0eb7c0cbccaae8e5e3681d852d4e7f50c4378
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2021.02.26a branch HEAD: 4ee0eb7c0cbccaae8e5e3681d852d4e7f50c4378 rcu/tree: Add a trace event for RCU CPU stall warnings elapsed time: 720m configs tested: 94 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig sh urquell_defconfig arm cns3420vb_defconfig sh secureedge5410_defconfig mips malta_defconfig arm assabet_defconfig arm tct_hammer_defconfig mips bigsur_defconfig m68k bvme6000_defconfig arm collie_defconfig nds32alldefconfig h8300h8300h-sim_defconfig powerpccell_defconfig mips maltasmvp_defconfig armspear6xx_defconfig pariscgeneric-64bit_defconfig arm versatile_defconfig arc alldefconfig sh magicpanelr2_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20210303 i386 randconfig-a003-20210303 i386 randconfig-a002-20210303 i386 randconfig-a004-20210303 i386 randconfig-a006-20210303 i386 randconfig-a001-20210303 i386 randconfig-a016-20210303 i386 randconfig-a012-20210303 i386 randconfig-a014-20210303 i386 randconfig-a013-20210303 i386 randconfig-a011-20210303 i386 randconfig-a015-20210303 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a013-20210302 x86_64 randconfig-a016-20210302 x86_64 randconfig-a015-20210302 x86_64 randconfig-a014-20210302 x86_64 randconfig-a012-20210302 x86_64 randconfig-a011-20210302 x86_64 randconfig-a006-20210303 x86_64 randconfig-a001-20210303 x86_64 randconfig-a004-20210303 x86_64 randconfig-a002-20210303 x86_64 randconfig-a005-20210303 x86_64 randconfig-a003-20210303 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v7 3/3] arm64: dts: reset: add microchip sparx5 switch reset driver
On 03/03/2021 09:11:58+0100, Steen Hegelund wrote:
> This provides reset driver support for the Microchip Sparx5 PCB134 and
> PCB135 reference boards.
>
> Signed-off-by: Steen Hegelund
Reviewed-by: Alexandre Belloni
> ---
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> index 380281f312d8..dc3ada5cf9fc 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> @@ -132,9 +132,12 @@ mux: mux-controller {
> };
> };
>
> - reset@611010008 {
> - compatible = "microchip,sparx5-chip-reset";
> + reset: reset-controller@611010008 {
> + compatible = "microchip,sparx5-switch-reset";
> reg = <0x6 0x11010008 0x4>;
> + reg-names = "gcb";
> + #reset-cells = <1>;
> + cpu-syscon = <_ctrl>;
> };
>
> uart0: serial@60010 {
> --
> 2.30.1
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
