* [PATCH v2] PCI: hv: Fix a timing issue which causes kdump to fail occasionally
From: Wei Hu @ 2020-07-17 2:55 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, lorenzo.pieralisi, robh,
bhelgaas, linux-hyperv, linux-pci, linux-kernel, decui, mikelley
Cc: Wei Hu
Kdump could fail sometime on HyperV guest over Accerlated Network
interface. This is because the retry in hv_pci_enter_d0() relies on
an asynchronous host event to arrive guest before calling
hv_send_resources_allocated(). This fixes the problem by moving retry
to hv_pci_probe(), removing this dependence and making the calling
sequence synchronous.
v2: Adding Fixes tag according to Michael Kelley's review comment.
Fixes: c81992e7f4aa ("PCI: hv: Retry PCI bus D0 entry on invalid device state")
Signed-off-by: Wei Hu <weh@microsoft.com>
---
drivers/pci/controller/pci-hyperv.c | 66 ++++++++++++++---------------
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index bf40ff09c99d..738ee30f3334 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -2759,10 +2759,8 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
struct pci_bus_d0_entry *d0_entry;
struct hv_pci_compl comp_pkt;
struct pci_packet *pkt;
- bool retry = true;
int ret;
-enter_d0_retry:
/*
* Tell the host that the bus is ready to use, and moved into the
* powered-on state. This includes telling the host which region
@@ -2789,38 +2787,6 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
if (ret)
goto exit;
- /*
- * In certain case (Kdump) the pci device of interest was
- * not cleanly shut down and resource is still held on host
- * side, the host could return invalid device status.
- * We need to explicitly request host to release the resource
- * and try to enter D0 again.
- */
- if (comp_pkt.completion_status < 0 && retry) {
- retry = false;
-
- dev_err(&hdev->device, "Retrying D0 Entry\n");
-
- /*
- * Hv_pci_bus_exit() calls hv_send_resource_released()
- * to free up resources of its child devices.
- * In the kdump kernel we need to set the
- * wslot_res_allocated to 255 so it scans all child
- * devices to release resources allocated in the
- * normal kernel before panic happened.
- */
- hbus->wslot_res_allocated = 255;
-
- ret = hv_pci_bus_exit(hdev, true);
-
- if (ret == 0) {
- kfree(pkt);
- goto enter_d0_retry;
- }
- dev_err(&hdev->device,
- "Retrying D0 failed with ret %d\n", ret);
- }
-
if (comp_pkt.completion_status < 0) {
dev_err(&hdev->device,
"PCI Pass-through VSP failed D0 Entry with status %x\n",
@@ -3058,6 +3024,7 @@ static int hv_pci_probe(struct hv_device *hdev,
struct hv_pcibus_device *hbus;
u16 dom_req, dom;
char *name;
+ bool enter_d0_retry = true;
int ret;
/*
@@ -3178,11 +3145,42 @@ static int hv_pci_probe(struct hv_device *hdev,
if (ret)
goto free_fwnode;
+retry:
ret = hv_pci_query_relations(hdev);
if (ret)
goto free_irq_domain;
ret = hv_pci_enter_d0(hdev);
+ /*
+ * In certain case (Kdump) the pci device of interest was
+ * not cleanly shut down and resource is still held on host
+ * side, the host could return invalid device status.
+ * We need to explicitly request host to release the resource
+ * and try to enter D0 again.
+ * The retry should start from hv_pci_query_relations() call.
+ */
+ if (ret == -EPROTO && enter_d0_retry) {
+ enter_d0_retry = false;
+
+ dev_err(&hdev->device, "Retrying D0 Entry\n");
+
+ /*
+ * Hv_pci_bus_exit() calls hv_send_resources_released()
+ * to free up resources of its child devices.
+ * In the kdump kernel we need to set the
+ * wslot_res_allocated to 255 so it scans all child
+ * devices to release resources allocated in the
+ * normal kernel before panic happened.
+ */
+ hbus->wslot_res_allocated = 255;
+ ret = hv_pci_bus_exit(hdev, true);
+
+ if (ret == 0)
+ goto retry;
+
+ dev_err(&hdev->device,
+ "Retrying D0 failed with ret %d\n", ret);
+ }
if (ret)
goto free_irq_domain;
--
2.20.1
^ permalink raw reply related
* [PATCH RFC 3/3] improve raid10 discard request
From: Xiao Ni @ 2020-07-17 2:52 UTC (permalink / raw)
To: song, linux-raid
In-Reply-To: <1594954368-5646-1-git-send-email-xni@redhat.com>
Now the discard request is split by chunk size. So it takes a long time to finish mkfs on
disks which support discard function. This patch improve handling raid10 discard request.
It uses the similar way with raid0(29efc390b).
But it's a little complex than raid0. Because raid10 has different layout. If raid10 is
offset layout and the discard request is smaller than stripe size. There are some holes
when we submit discard bio to underlayer disks.
For example: five disks (disk1 - disk5)
D01 D02 D03 D04 D05
D05 D01 D02 D03 D04
D06 D07 D08 D09 D10
D10 D06 D07 D08 D09
The discard bio just wants to discard from D03 to D10. For disk3, there is a hole between
D03 and D08. For disk4, there is a hole between D04 and D09. D03 is a chunk, raid10_write_request
can handle one chunk perfectly. So the part that is not aligned with stripe size is still
handled by raid10_write_request.
If reshape is running when discard bio comes and the discard bio spans the reshape position,
raid10_write_request is responsible to handle this discard bio.
I did a test with this patch set.
Without patch:
time mkfs.xfs /dev/md0
real4m39.775s
user0m0.000s
sys0m0.298s
With patch:
time mkfs.xfs /dev/md0
real0m0.105s
user0m0.000s
sys0m0.007s
nvme3n1 259:1 0 477G 0 disk
└─nvme3n1p1 259:10 0 50G 0 part
nvme4n1 259:2 0 477G 0 disk
└─nvme4n1p1 259:11 0 50G 0 part
nvme5n1 259:6 0 477G 0 disk
└─nvme5n1p1 259:12 0 50G 0 part
nvme2n1 259:9 0 477G 0 disk
└─nvme2n1p1 259:15 0 50G 0 part
nvme0n1 259:13 0 477G 0 disk
└─nvme0n1p1 259:14 0 50G 0 part
Signed-off-by: Xiao Ni <xni@redhat.com>
---
drivers/md/raid10.c | 266 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 265 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 2a7423e..417a1ff 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1518,6 +1518,261 @@ static void __make_request(struct mddev *mddev, struct bio *bio, int sectors)
raid10_write_request(mddev, bio, r10_bio);
}
+static void wait_blocked_dev(struct mddev *mddev, int cnt)
+{
+ int i;
+ struct r10conf *conf = mddev->private;
+ struct md_rdev *blocked_rdev = NULL;
+
+retry_wait:
+ rcu_read_lock();
+ for (i = 0; i < cnt; i++) {
+ struct md_rdev *rdev = rcu_dereference(conf->mirrors[i].rdev);
+ struct md_rdev *rrdev = rcu_dereference(
+ conf->mirrors[i].replacement);
+ if (rdev == rrdev)
+ rrdev = NULL;
+ if (rdev && unlikely(test_bit(Blocked, &rdev->flags))) {
+ atomic_inc(&rdev->nr_pending);
+ blocked_rdev = rdev;
+ break;
+ }
+ if (rrdev && unlikely(test_bit(Blocked, &rrdev->flags))) {
+ atomic_inc(&rrdev->nr_pending);
+ blocked_rdev = rrdev;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ if (unlikely(blocked_rdev)) {
+ /* Have to wait for this device to get unblocked, then retry */
+ allow_barrier(conf);
+ raid10_log(conf->mddev, "%s wait rdev %d blocked", __func__, blocked_rdev->raid_disk);
+ md_wait_for_blocked_rdev(blocked_rdev, mddev);
+ wait_barrier(conf);
+ goto retry_wait;
+ }
+}
+
+static struct bio *raid10_split_bio(struct r10conf *conf,
+ struct bio *bio, int sectors, bool want_first)
+{
+ struct bio *split;
+
+ split = bio_split(bio, sectors, GFP_NOIO, &conf->bio_split);
+ bio_chain(split, bio);
+ allow_barrier(conf);
+ if (want_first) {
+ submit_bio_noacct(bio);
+ bio = split;
+ } else
+ submit_bio_noacct(split);
+ wait_barrier(conf);
+
+ return bio;
+}
+
+static void raid10_end_discard_request(struct bio *bio)
+{
+ struct r10bio *r10_bio = bio->bi_private;
+ struct r10conf *conf = r10_bio->mddev->private;
+ struct md_rdev *rdev = NULL;
+ int dev;
+ int slot, repl;
+
+ /*
+ * We don't care the return value of discard bio
+ */
+ set_bit(R10BIO_Uptodate, &r10_bio->state);
+
+ dev = find_bio_disk(conf, r10_bio, bio, &slot, &repl);
+ if (repl)
+ rdev = conf->mirrors[dev].replacement;
+ if (!rdev) {
+ smp_rmb();
+ repl = 0;
+ rdev = conf->mirrors[dev].rdev;
+ }
+
+ if (atomic_dec_and_test(&r10_bio->remaining)) {
+ md_write_end(r10_bio->mddev);
+ raid_end_bio_io(r10_bio);
+ }
+
+ rdev_dec_pending(rdev, conf->mddev);
+}
+
+static bool raid10_handle_discard(struct mddev *mddev, struct bio *bio)
+{
+ struct r10conf *conf = mddev->private;
+ struct geom geo = conf->geo;
+ struct r10bio *r10_bio;
+
+ int disk;
+ sector_t chunk;
+ int stripe_size, stripe_mask;
+
+ sector_t bio_start, bio_end;
+ sector_t first_stripe_index, last_stripe_index;
+ sector_t start_disk_offset;
+ unsigned int start_disk_index;
+ sector_t end_disk_offset;
+ unsigned int end_disk_index;
+
+ wait_barrier(conf);
+
+ if (conf->reshape_progress != MaxSector &&
+ ((bio->bi_iter.bi_sector >= conf->reshape_progress) !=
+ conf->mddev->reshape_backwards))
+ geo = conf->prev;
+
+ stripe_size = (1<<geo.chunk_shift) * geo.raid_disks;
+ stripe_mask = stripe_size - 1;
+
+ if (bio_sectors(bio) < stripe_size)
+ goto out;
+
+ if (test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) &&
+ bio->bi_iter.bi_sector < conf->reshape_progress &&
+ bio->bi_iter.bi_sector + bio_sectors(bio) > conf->reshape_progress)
+ goto out;
+
+ r10_bio = mempool_alloc(&conf->r10bio_pool, GFP_NOIO);
+ r10_bio->mddev = mddev;
+ r10_bio->state = 0;
+ memset(r10_bio->devs, 0, sizeof(r10_bio->devs[0]) * conf->geo.raid_disks);
+
+ wait_blocked_dev(mddev, geo.raid_disks);
+
+ /* For far offset layout, if bio is not aligned with stripe size, it splits
+ * the part that is not aligned with strip size.
+ */
+
+ bio_start = bio->bi_iter.bi_sector;
+ bio_end = bio_end_sector(bio);
+ if (geo.far_offset && (bio_start & stripe_mask)) {
+ sector_t split_size;
+ split_size = round_up(bio_start, stripe_size) - bio_start;
+ bio = raid10_split_bio(conf, bio, split_size, false);
+ }
+ if (geo.far_offset && ((bio_end & stripe_mask) != stripe_mask)) {
+ sector_t split_size;
+ split_size = bio_end - (bio_end & stripe_mask);
+ bio = raid10_split_bio(conf, bio, split_size, true);
+ }
+ r10_bio->master_bio = bio;
+
+ bio_start = bio->bi_iter.bi_sector;
+ bio_end = bio_end_sector(bio);
+
+ chunk = bio_start >> geo.chunk_shift;
+ chunk *= geo.near_copies;
+ first_stripe_index = chunk;
+ start_disk_index = sector_div(first_stripe_index, geo.raid_disks);
+ if (geo.far_offset)
+ first_stripe_index *= geo.far_copies;
+ start_disk_offset = (bio_start & geo.chunk_mask) +
+ (first_stripe_index << geo.chunk_shift);
+
+ chunk = bio_end >> geo.chunk_shift;
+ chunk *= geo.near_copies;
+ last_stripe_index = chunk;
+ end_disk_index = sector_div(last_stripe_index, geo.raid_disks);
+ if (geo.far_offset)
+ last_stripe_index *= geo.far_copies;
+ end_disk_offset = (bio_end & geo.chunk_mask) +
+ (last_stripe_index << geo.chunk_shift);
+
+ rcu_read_lock();
+ for (disk = 0; disk < geo.raid_disks; disk++) {
+ struct md_rdev *rdev = rcu_dereference(conf->mirrors[disk].rdev);
+ struct md_rdev *rrdev = rcu_dereference(
+ conf->mirrors[disk].replacement);
+
+ r10_bio->devs[disk].bio = NULL;
+ r10_bio->devs[disk].repl_bio = NULL;
+
+ if (rdev && (test_bit(Faulty, &rdev->flags)))
+ rdev = NULL;
+ if (rrdev && (test_bit(Faulty, &rrdev->flags)))
+ rrdev = NULL;
+ if (!rdev && !rrdev)
+ continue;
+
+ if (rdev) {
+ r10_bio->devs[disk].bio = bio;
+ atomic_inc(&rdev->nr_pending);
+ }
+ if (rrdev) {
+ r10_bio->devs[disk].repl_bio = bio;
+ atomic_inc(&rrdev->nr_pending);
+ }
+ }
+ rcu_read_unlock();
+
+ atomic_set(&r10_bio->remaining, 1);
+ for (disk = 0; disk < geo.raid_disks; disk++) {
+ sector_t dev_start, dev_end;
+ struct bio *mbio, *rbio = NULL;
+ struct md_rdev *rdev = rcu_dereference(conf->mirrors[disk].rdev);
+ struct md_rdev *rrdev = rcu_dereference(
+ conf->mirrors[disk].replacement);
+
+ /*
+ * Now start to calculate the start and end address for each disk.
+ * The space between start and end is the discard region.
+ */
+ if (disk < start_disk_index)
+ dev_start = (first_stripe_index + 1) * mddev->chunk_sectors;
+ else if (disk > start_disk_index)
+ dev_start = first_stripe_index * mddev->chunk_sectors;
+ else
+ dev_start = start_disk_offset;
+
+ if (disk < end_disk_index)
+ dev_end = (last_stripe_index + 1) * mddev->chunk_sectors;
+ else if (disk > end_disk_index)
+ dev_end = last_stripe_index * mddev->chunk_sectors;
+ else
+ dev_end = end_disk_offset;
+
+ /* It only handles discard bio which size is >= stripe size, so
+ * dev_end > dev_start all the time
+ */
+ if (r10_bio->devs[disk].bio) {
+ mbio = bio_clone_fast(bio, GFP_NOIO, &mddev->bio_set);
+ mbio->bi_end_io = raid10_end_discard_request;
+ mbio->bi_private = r10_bio;
+ r10_bio->devs[disk].bio = mbio;
+ r10_bio->devs[disk].devnum = disk;
+ atomic_inc(&r10_bio->remaining);
+ md_submit_discard_bio(mddev, rdev, mbio, dev_start, dev_end);
+ bio_endio(mbio);
+ }
+ if (r10_bio->devs[disk].repl_bio) {
+ rbio = bio_clone_fast(bio, GFP_NOIO, &mddev->bio_set);
+ rbio->bi_end_io = raid10_end_discard_request;
+ rbio->bi_private = r10_bio;
+ r10_bio->devs[disk].repl_bio = rbio;
+ r10_bio->devs[disk].devnum = disk;
+ atomic_inc(&r10_bio->remaining);
+ md_submit_discard_bio(mddev, rrdev, rbio, dev_start, dev_end);
+ bio_endio(rbio);
+ }
+ }
+
+ if (atomic_dec_and_test(&r10_bio->remaining)) {
+ md_write_end(r10_bio->mddev);
+ raid_end_bio_io(r10_bio);
+ }
+
+ return 0;
+out:
+ allow_barrier(conf);
+ return -EAGAIN;
+}
+
static bool raid10_make_request(struct mddev *mddev, struct bio *bio)
{
struct r10conf *conf = mddev->private;
@@ -1532,6 +1787,15 @@ static bool raid10_make_request(struct mddev *mddev, struct bio *bio)
if (!md_write_start(mddev, bio))
return false;
+ /* There are some limitations to handle discard bio
+ * 1st, the discard size is bigger than stripe size.
+ * 2st, if the discard bio spans reshape progress, we use the old way to
+ * handle discard bio
+ */
+ if (unlikely(bio_op(bio) == REQ_OP_DISCARD))
+ if (!raid10_handle_discard(mddev, bio))
+ return true;
+
/*
* If this request crosses a chunk boundary, we need to split
* it.
@@ -3762,7 +4026,7 @@ static int raid10_run(struct mddev *mddev)
chunk_size = mddev->chunk_sectors << 9;
if (mddev->queue) {
blk_queue_max_discard_sectors(mddev->queue,
- mddev->chunk_sectors);
+ UINT_MAX);
blk_queue_max_write_same_sectors(mddev->queue, 0);
blk_queue_max_write_zeroes_sectors(mddev->queue, 0);
blk_queue_io_min(mddev->queue, chunk_size);
--
2.7.5
^ permalink raw reply related
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Alan Stern @ 2020-07-16 21:24 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <595582123.17106.1594925921537.JavaMail.zimbra@efficios.com>
On Thu, Jul 16, 2020 at 02:58:41PM -0400, Mathieu Desnoyers wrote:
> ----- On Jul 16, 2020, at 12:03 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
>
> > ----- On Jul 16, 2020, at 11:46 AM, Mathieu Desnoyers
> > mathieu.desnoyers@efficios.com wrote:
> >
> >> ----- On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npiggin@gmail.com wrote:
> >>> I should be more complete here, especially since I was complaining
> >>> about unclear barrier comment :)
> >>>
> >>>
> >>> CPU0 CPU1
> >>> a. user stuff 1. user stuff
> >>> b. membarrier() 2. enter kernel
> >>> c. smp_mb() 3. smp_mb__after_spinlock(); // in __schedule
> >>> d. read rq->curr 4. rq->curr switched to kthread
> >>> e. is kthread, skip IPI 5. switch_to kthread
> >>> f. return to user 6. rq->curr switched to user thread
> >>> g. user stuff 7. switch_to user thread
> >>> 8. exit kernel
> >>> 9. more user stuff
> >>>
> >>> What you're really ordering is a, g vs 1, 9 right?
> >>>
> >>> In other words, 9 must see a if it sees g, g must see 1 if it saw 9,
> >>> etc.
> >>>
> >>> Userspace does not care where the barriers are exactly or what kernel
> >>> memory accesses might be being ordered by them, so long as there is a
> >>> mb somewhere between a and g, and 1 and 9. Right?
> >>
> >> This is correct.
> >
> > Actually, sorry, the above is not quite right. It's been a while
> > since I looked into the details of membarrier.
> >
> > The smp_mb() at the beginning of membarrier() needs to be paired with a
> > smp_mb() _after_ rq->curr is switched back to the user thread, so the
> > memory barrier is between store to rq->curr and following user-space
> > accesses.
> >
> > The smp_mb() at the end of membarrier() needs to be paired with the
> > smp_mb__after_spinlock() at the beginning of schedule, which is
> > between accesses to userspace memory and switching rq->curr to kthread.
> >
> > As to *why* this ordering is needed, I'd have to dig through additional
> > scenarios from https://lwn.net/Articles/573436/. Or maybe Paul remembers ?
>
> Thinking further about this, I'm beginning to consider that maybe we have been
> overly cautious by requiring memory barriers before and after store to rq->curr.
>
> If CPU0 observes a CPU1's rq->curr->mm which differs from its own process (current)
> while running the membarrier system call, it necessarily means that CPU1 had
> to issue smp_mb__after_spinlock when entering the scheduler, between any user-space
> loads/stores and update of rq->curr.
>
> Requiring a memory barrier between update of rq->curr (back to current process's
> thread) and following user-space memory accesses does not seem to guarantee
> anything more than what the initial barrier at the beginning of __schedule already
> provides, because the guarantees are only about accesses to user-space memory.
>
> Therefore, with the memory barrier at the beginning of __schedule, just observing that
> CPU1's rq->curr differs from current should guarantee that a memory barrier was issued
> between any sequentially consistent instructions belonging to the current process on
> CPU1.
>
> Or am I missing/misremembering an important point here ?
Is it correct to say that the switch_to operations in 5 and 7 include
memory barriers? If they do, then skipping the IPI should be okay.
The reason is as follows: The guarantee you need to enforce is that
anything written by CPU0 before the membarrier() will be visible to CPU1
after it returns to user mode. Let's say that a writes to X and 9
reads from X.
Then we have an instance of the Store Buffer pattern:
CPU0 CPU1
a. Write X 6. Write rq->curr for user thread
c. smp_mb() 7. switch_to memory barrier
d. Read rq->curr 9. Read X
In this pattern, the memory barriers make it impossible for both reads
to miss their corresponding writes. Since d does fail to read 6 (it
sees the earlier value stored by 4), 9 must read a.
The other guarantee you need is that g on CPU0 will observe anything
written by CPU1 in 1. This is easier to see, using the fact that 3 is a
memory barrier and d reads from 4.
Alan Stern
^ permalink raw reply
* [PATCH RFC 2/3] extend r10bio devs to raid disks
From: Xiao Ni @ 2020-07-17 2:52 UTC (permalink / raw)
To: song, linux-raid
In-Reply-To: <1594954368-5646-1-git-send-email-xni@redhat.com>
Now it allocs r10bio->devs[conf->copies]. Discard bio needs to submit to all member disks
and it needs to use r10bio. So extend to r10bio->devs[geo.raid_disks].
Signed-off-by: Xiao Ni <xni@redhat.com>
---
drivers/md/raid10.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e45fd56..2a7423e 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -91,7 +91,7 @@ static inline struct r10bio *get_resync_r10bio(struct bio *bio)
static void * r10bio_pool_alloc(gfp_t gfp_flags, void *data)
{
struct r10conf *conf = data;
- int size = offsetof(struct r10bio, devs[conf->copies]);
+ int size = offsetof(struct r10bio, devs[conf->geo.raid_disks]);
/* allocate a r10bio with room for raid_disks entries in the
* bios array */
@@ -238,7 +238,7 @@ static void put_all_bios(struct r10conf *conf, struct r10bio *r10_bio)
{
int i;
- for (i = 0; i < conf->copies; i++) {
+ for (i = 0; i < conf->geo.raid_disks; i++) {
struct bio **bio = & r10_bio->devs[i].bio;
if (!BIO_SPECIAL(*bio))
bio_put(*bio);
@@ -327,7 +327,7 @@ static int find_bio_disk(struct r10conf *conf, struct r10bio *r10_bio,
int slot;
int repl = 0;
- for (slot = 0; slot < conf->copies; slot++) {
+ for (slot = 0; slot < conf->geo.raid_disks; slot++) {
if (r10_bio->devs[slot].bio == bio)
break;
if (r10_bio->devs[slot].repl_bio == bio) {
@@ -336,7 +336,7 @@ static int find_bio_disk(struct r10conf *conf, struct r10bio *r10_bio,
}
}
- BUG_ON(slot == conf->copies);
+ BUG_ON(slot == conf->geo.raid_disks);
update_head_pos(slot, r10_bio);
if (slotp)
@@ -1510,7 +1510,7 @@ static void __make_request(struct mddev *mddev, struct bio *bio, int sectors)
r10_bio->mddev = mddev;
r10_bio->sector = bio->bi_iter.bi_sector;
r10_bio->state = 0;
- memset(r10_bio->devs, 0, sizeof(r10_bio->devs[0]) * conf->copies);
+ memset(r10_bio->devs, 0, sizeof(r10_bio->devs[0]) * conf->geo.raid_disks);
if (bio_data_dir(bio) == READ)
raid10_read_request(mddev, bio, r10_bio);
--
2.7.5
^ permalink raw reply related
* [PATCH RFC 1/3] Move codes related with submitting discard bio into one function
From: Xiao Ni @ 2020-07-17 2:52 UTC (permalink / raw)
To: song, linux-raid
In-Reply-To: <1594954368-5646-1-git-send-email-xni@redhat.com>
These codes can be used in raid10. So we can move these codes into md.c. raid0 and raid10
can share these codes.
Signed-off-by: Xiao Ni <xni@redhat.com>
---
drivers/md/md.c | 22 ++++++++++++++++++++++
drivers/md/md.h | 3 +++
drivers/md/raid0.c | 15 ++-------------
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 07e5b67..2b8f654 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8559,6 +8559,28 @@ void md_write_end(struct mddev *mddev)
EXPORT_SYMBOL(md_write_end);
+void md_submit_discard_bio(struct mddev *mddev, struct md_rdev *rdev,
+ struct bio *bio,
+ sector_t dev_start, sector_t dev_end)
+{
+ struct bio *discard_bio = NULL;
+
+ if (__blkdev_issue_discard(rdev->bdev,
+ dev_start + rdev->data_offset,
+ dev_end - dev_start, GFP_NOIO, 0, &discard_bio) ||
+ !discard_bio)
+ return;
+
+ bio_chain(discard_bio, bio);
+ bio_clone_blkg_association(discard_bio, bio);
+ if (mddev->gendisk)
+ trace_block_bio_remap(bdev_get_queue(rdev->bdev),
+ discard_bio, disk_devt(mddev->gendisk),
+ bio->bi_iter.bi_sector);
+ submit_bio_noacct(discard_bio);
+}
+EXPORT_SYMBOL(md_submit_discard_bio);
+
/* md_allow_write(mddev)
* Calling this ensures that the array is marked 'active' so that writes
* may proceed without blocking. It is important to call this before
diff --git a/drivers/md/md.h b/drivers/md/md.h
index c26fa8b..83ae77e 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -710,6 +710,9 @@ extern void md_write_end(struct mddev *mddev);
extern void md_done_sync(struct mddev *mddev, int blocks, int ok);
extern void md_error(struct mddev *mddev, struct md_rdev *rdev);
extern void md_finish_reshape(struct mddev *mddev);
+extern void md_submit_discard_bio(struct mddev *mddev, struct md_rdev *rdev,
+ struct bio *bio,
+ sector_t dev_start, sector_t dev_end);
extern int mddev_congested(struct mddev *mddev, int bits);
extern bool __must_check md_flush_request(struct mddev *mddev, struct bio *bio);
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index e9e91c8..e37fe8a 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -525,7 +525,6 @@ static void raid0_handle_discard(struct mddev *mddev, struct bio *bio)
for (disk = 0; disk < zone->nb_dev; disk++) {
sector_t dev_start, dev_end;
- struct bio *discard_bio = NULL;
struct md_rdev *rdev;
if (disk < start_disk_index)
@@ -548,18 +547,8 @@ static void raid0_handle_discard(struct mddev *mddev, struct bio *bio)
rdev = conf->devlist[(zone - conf->strip_zone) *
conf->strip_zone[0].nb_dev + disk];
- if (__blkdev_issue_discard(rdev->bdev,
- dev_start + zone->dev_start + rdev->data_offset,
- dev_end - dev_start, GFP_NOIO, 0, &discard_bio) ||
- !discard_bio)
- continue;
- bio_chain(discard_bio, bio);
- bio_clone_blkg_association(discard_bio, bio);
- if (mddev->gendisk)
- trace_block_bio_remap(bdev_get_queue(rdev->bdev),
- discard_bio, disk_devt(mddev->gendisk),
- bio->bi_iter.bi_sector);
- submit_bio_noacct(discard_bio);
+ dev_start += zone->dev_start;
+ md_submit_discard_bio(mddev, rdev, bio, dev_start, dev_end);
}
bio_endio(bio);
}
--
2.7.5
^ permalink raw reply related
* [PATCH RFC 0/3] Improve handling raid10 discard request
From: Xiao Ni @ 2020-07-17 2:52 UTC (permalink / raw)
To: song, linux-raid
Hi all
Now mkfs on raid10 which is combined with ssd/nvme disks takes a long time.
This patch set tries to resolve this problem.
Xiao Ni (3):
Move codes related with submitting discard bio into one function
extend r10bio devs to raid disks
improve raid10 discard request
drivers/md/md.c | 22 +++++
drivers/md/md.h | 3 +
drivers/md/raid0.c | 15 +--
drivers/md/raid10.c | 276 ++++++++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 297 insertions(+), 19 deletions(-)
--
2.7.5
^ permalink raw reply
* [RESEND] [PATCH v2] dax: print error message by pr_info() in __generic_fsdax_supported()
From: Coly Li @ 2020-07-17 2:52 UTC (permalink / raw)
To: dan.j.williams, linux-nvdimm
Cc: Coly Li, Michal Suchanek, Jan Kara, Anthony Iliopoulos
In struct dax_operations, the callback routine dax_supported() returns
a bool type result. For false return value, the caller has no idea
whether the device does not support dax at all, or it is just some mis-
configuration issue.
An example is formatting an Ext4 file system on pmem device on top of
a NVDIMM namespace by,
# mkfs.ext4 /dev/pmem0
If the fs block size does not match kernel space memory page size (which
is possible on non-x86 platform), mount this Ext4 file system will fail,
# mount -o dax /dev/pmem0 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/pmem0,
missing codepage or helper program, or other error.
And from the dmesg output there is only the following information,
[ 307.853148] EXT4-fs (pmem0): DAX unsupported by block device.
The above information is quite confusing. Because definiately the pmem0
device supports dax operation, and the super block is consistent as how
it was created by mkfs.ext4.
Indeed the failure is from __generic_fsdax_supported() by the following
code piece,
if (blocksize != PAGE_SIZE) {
pr_debug("%s: error: unsupported blocksize for dax\n",
bdevname(bdev, buf));
return false;
}
It is because the Ext4 block size is 4KB and kernel page size is 8KB or
16KB.
It is not simple to make dax_supported() from struct dax_operations
or __generic_fsdax_supported() to return exact failure type right now.
So the simplest fix is to use pr_info() to print all the error messages
inside __generic_fsdax_supported(). Then users may find informative clue
from the kernel message at least.
Message printed by pr_debug() is very easy to be ignored by users. This
patch prints error message by pr_info() in __generic_fsdax_supported(),
when then mount fails, following lines can be found from dmesg output,
[ 2705.500885] pmem0: error: unsupported blocksize for dax
[ 2705.500888] EXT4-fs (pmem0): DAX unsupported by block device.
Now the users may have idea the mount failure is from pmem driver for
unsupported block size.
Reported-by: Michal Suchanek <msuchanek@suse.com>
Suggested-by: Jan Kara <jack@suse.com>
Signed-off-by: Coly Li <colyli@suse.de>
Reviewed-by: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Anthony Iliopoulos <ailiopoulos@suse.com>
---
Changelog:
v2: Add reviewed-by from Jan Kara
v1: initial version.
drivers/dax/super.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 8e32345be0f7..de0d02ec0347 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -80,14 +80,14 @@ bool __generic_fsdax_supported(struct dax_device
*dax_dev,
int err, id;
if (blocksize != PAGE_SIZE) {
- pr_debug("%s: error: unsupported blocksize for dax\n",
+ pr_info("%s: error: unsupported blocksize for dax\n",
bdevname(bdev, buf));
return false;
}
err = bdev_dax_pgoff(bdev, start, PAGE_SIZE, &pgoff);
if (err) {
- pr_debug("%s: error: unaligned partition for dax\n",
+ pr_info("%s: error: unaligned partition for dax\n",
bdevname(bdev, buf));
return false;
}
@@ -95,7 +95,7 @@ bool __generic_fsdax_supported(struct dax_device *dax_dev,
last_page = PFN_DOWN((start + sectors - 1) * 512) * PAGE_SIZE / 512;
err = bdev_dax_pgoff(bdev, last_page, PAGE_SIZE, &pgoff_end);
if (err) {
- pr_debug("%s: error: unaligned partition for dax\n",
+ pr_info("%s: error: unaligned partition for dax\n",
bdevname(bdev, buf));
return false;
}
@@ -106,7 +106,7 @@ bool __generic_fsdax_supported(struct dax_device
*dax_dev,
dax_read_unlock(id);
if (len < 1 || len2 < 1) {
- pr_debug("%s: error: dax access failed (%ld)\n",
+ pr_info("%s: error: dax access failed (%ld)\n",
bdevname(bdev, buf), len < 1 ? len : len2);
return false;
}
@@ -139,7 +139,7 @@ bool __generic_fsdax_supported(struct dax_device
*dax_dev,
}
if (!dax_enabled) {
- pr_debug("%s: error: dax support not enabled\n",
+ pr_info("%s: error: dax support not enabled\n",
bdevname(bdev, buf));
return false;
}
--
2.26.2
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply related
* [PATCH] net: ethernet: ave: Fix error returns in ave_init
From: Wang Hai @ 2020-07-17 2:50 UTC (permalink / raw)
To: hayashi.kunihiko, davem, kuba, p.zabel, yamada.masahiro
Cc: netdev, linux-kernel, wanghai38
When regmap_update_bits failed in ave_init(), calls of the functions
reset_control_assert() and clk_disable_unprepare() were missed.
Add goto out_reset_assert to do this.
Fixes: 57878f2f4697 ("net: ethernet: ave: add support for phy-mode setting of system controller")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
---
drivers/net/ethernet/socionext/sni_ave.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/socionext/sni_ave.c b/drivers/net/ethernet/socionext/sni_ave.c
index f2638446b62e..81b554dd7221 100644
--- a/drivers/net/ethernet/socionext/sni_ave.c
+++ b/drivers/net/ethernet/socionext/sni_ave.c
@@ -1191,7 +1191,7 @@ static int ave_init(struct net_device *ndev)
ret = regmap_update_bits(priv->regmap, SG_ETPINMODE,
priv->pinmode_mask, priv->pinmode_val);
if (ret)
- return ret;
+ goto out_reset_assert;
ave_global_reset(ndev);
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] ALSA: hda: Add support for Loongson 7A1000 controller
From: Kaige Li @ 2020-07-17 2:51 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai
Cc: alsa-devel, linux-kernel, Xuefeng Li, Tiezhu Yang
In-Reply-To: <1594954292-1703-1-git-send-email-likaige@loongson.cn>
Add the new PCI ID 0x0014 0x7a07 to support Loongson 7A1000 controller.
Signed-off-by: Kaige Li <likaige@loongson.cn>
---
sound/pci/hda/hda_intel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1625721..ea1d535 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2735,6 +2735,8 @@ static const struct pci_device_id azx_ids[] = {
.driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI },
/* Zhaoxin */
{ PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN },
+ /* Loongson */
+ { PCI_DEVICE(0x0014, 0x7a07), .driver_data = AZX_DRIVER_GENERIC },
{ 0, }
};
MODULE_DEVICE_TABLE(pci, azx_ids);
--
2.1.0
^ permalink raw reply related
* [PATCH 1/2] ALSA: hda/realtek: Fix headset mic on Loongson platform
From: Kaige Li @ 2020-07-17 2:51 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai
Cc: alsa-devel, linux-kernel, Xuefeng Li, Tiezhu Yang
Add pin quirks to enable use of the headset mic on Loongson platform.
Signed-off-by: Kaige Li <likaige@loongson.cn>
---
sound/pci/hda/patch_realtek.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4c7e191..b227be3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6041,6 +6041,7 @@ enum {
ALC290_FIXUP_SUBWOOFER_HSJACK,
ALC269_FIXUP_THINKPAD_ACPI,
ALC269_FIXUP_DMIC_THINKPAD_ACPI,
+ ALC269_FIXUP_LOONGSON_HDA,
ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
@@ -6381,6 +6382,14 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC269_FIXUP_LOONGSON_HDA] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x1b, 0x02214c40 }, /* Front Mic */
+ { 0x15, 0x01014030 }, /* Rear Mic */
+ { }
+ },
+ },
[ALC269_FIXUP_DELL4_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
@@ -7654,6 +7663,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
+ SND_PCI_QUIRK(0x10ec, 0x0269, "Loongson HDA", ALC269_FIXUP_LOONGSON_HDA),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
SND_PCI_QUIRK(0x1d72, 0x1901, "RedmiBook 14", ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x10ec, 0x118c, "Medion EE4254 MD62100", ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE),
--
2.1.0
^ permalink raw reply related
* [PATCH] rtw88: 8821c: coex: add functions and parameters
From: yhchuang @ 2020-07-17 2:49 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, tehuang, bigeasy
From: jupiter <pc.chen@realtek.com>
Without this patch, RTL8821CE will not have coex support,
and will crash the system because of the NULL pointers
for the coex functions.
While RTL8822C series are WiFi + BT combo chips, it needs
the co-existence mechanism for the device to work on both
WiFi and BT without interfering each other. And the coex
support has already been added before, most of the mechanisms
are implemented. The driver should just add corresponding
functions to operate on different types of chips and its
coex parameters.
Fixes: f745eb9ca5bf ("rtw88: 8821c: Add 8821CE to Kconfig and Makefile")
Signed-off-by: Ping-Cheng Chen <pc.chen@realtek.com>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
drivers/net/wireless/realtek/rtw88/reg.h | 1 +
drivers/net/wireless/realtek/rtw88/rtw8821c.c | 403 ++++++++++++++++++
drivers/net/wireless/realtek/rtw88/rtw8821c.h | 26 ++
3 files changed, 430 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/reg.h b/drivers/net/wireless/realtek/rtw88/reg.h
index f1275757f6b4..8f468d6b5f78 100644
--- a/drivers/net/wireless/realtek/rtw88/reg.h
+++ b/drivers/net/wireless/realtek/rtw88/reg.h
@@ -61,6 +61,7 @@
#define BIT_FSPI_EN BIT(19)
#define BIT_EN_SIC BIT(12)
#define BIT_BT_AOD_GPIO3 BIT(9)
+#define BIT_PO_BT_PTA_PINS BIT(9)
#define BIT_BT_PTA_EN BIT(5)
#define BIT_WLRFE_4_5_EN BIT(2)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
index c41c61ee2fb6..0ac8c005c8e1 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
@@ -649,6 +649,197 @@ static void rtw8821c_phy_calibration(struct rtw_dev *rtwdev)
rtw8821c_do_iqk(rtwdev);
}
+/* for coex */
+static void rtw8821c_coex_cfg_init(struct rtw_dev *rtwdev)
+{
+ /* enable TBTT nterrupt */
+ rtw_write8_set(rtwdev, REG_BCN_CTRL, BIT_EN_BCN_FUNCTION);
+
+ /* BT report packet sample rate */
+ rtw_write8_mask(rtwdev, REG_BT_TDMA_TIME, SAMPLE_RATE_MASK,
+ SAMPLE_RATE);
+
+ /* enable BT counter statistics */
+ rtw_write8(rtwdev, REG_BT_STAT_CTRL, BT_CNT_ENABLE);
+
+ /* enable PTA (3-wire function form BT side) */
+ rtw_write32_set(rtwdev, REG_GPIO_MUXCFG, BIT_BT_PTA_EN);
+ rtw_write32_set(rtwdev, REG_GPIO_MUXCFG, BIT_PO_BT_PTA_PINS);
+
+ /* enable PTA (tx/rx signal form WiFi side) */
+ rtw_write8_set(rtwdev, REG_QUEUE_CTRL, BIT_PTA_WL_TX_EN);
+ /* wl tx signal to PTA not case EDCCA */
+ rtw_write8_clr(rtwdev, REG_QUEUE_CTRL, BIT_PTA_EDCCA_EN);
+ /* GNT_BT=1 while select both */
+ rtw_write16_set(rtwdev, REG_BT_COEX_V2, BIT_GNT_BT_POLARITY);
+
+ /* beacon queue always hi-pri */
+ rtw_write8_mask(rtwdev, REG_BT_COEX_TABLE_H + 3, BIT_BCN_QUEUE,
+ BCN_PRI_EN);
+}
+
+static void rtw8821c_coex_cfg_ant_switch(struct rtw_dev *rtwdev, u8 ctrl_type,
+ u8 pos_type)
+{
+ struct rtw_coex *coex = &rtwdev->coex;
+ struct rtw_coex_dm *coex_dm = &coex->dm;
+ struct rtw_coex_rfe *coex_rfe = &coex->rfe;
+ u32 switch_status = FIELD_PREP(CTRL_TYPE_MASK, ctrl_type) | pos_type;
+ bool polarity_inverse;
+ u8 regval = 0;
+
+ if (switch_status == coex_dm->cur_switch_status)
+ return;
+
+ coex_dm->cur_switch_status = switch_status;
+
+ if (coex_rfe->ant_switch_diversity &&
+ ctrl_type == COEX_SWITCH_CTRL_BY_BBSW)
+ ctrl_type = COEX_SWITCH_CTRL_BY_ANTDIV;
+
+ polarity_inverse = (coex_rfe->ant_switch_polarity == 1);
+
+ switch (ctrl_type) {
+ default:
+ case COEX_SWITCH_CTRL_BY_BBSW:
+ rtw_write32_clr(rtwdev, REG_LED_CFG, BIT_DPDT_SEL_EN);
+ rtw_write32_set(rtwdev, REG_LED_CFG, BIT_DPDT_WL_SEL);
+ /* BB SW, DPDT use RFE_ctrl8 and RFE_ctrl9 as ctrl pin */
+ rtw_write8_mask(rtwdev, REG_RFE_CTRL8, BIT_MASK_RFE_SEL89,
+ DPDT_CTRL_PIN);
+
+ if (pos_type == COEX_SWITCH_TO_WLG_BT) {
+ if (coex_rfe->rfe_module_type != 0x4 &&
+ coex_rfe->rfe_module_type != 0x2)
+ regval = 0x3;
+ else
+ regval = (!polarity_inverse ? 0x2 : 0x1);
+ } else if (pos_type == COEX_SWITCH_TO_WLG) {
+ regval = (!polarity_inverse ? 0x2 : 0x1);
+ } else {
+ regval = (!polarity_inverse ? 0x1 : 0x2);
+ }
+
+ rtw_write8_mask(rtwdev, REG_RFE_CTRL8, BIT_MASK_R_RFE_SEL_15,
+ regval);
+ break;
+ case COEX_SWITCH_CTRL_BY_PTA:
+ rtw_write32_clr(rtwdev, REG_LED_CFG, BIT_DPDT_SEL_EN);
+ rtw_write32_set(rtwdev, REG_LED_CFG, BIT_DPDT_WL_SEL);
+ /* PTA, DPDT use RFE_ctrl8 and RFE_ctrl9 as ctrl pin */
+ rtw_write8_mask(rtwdev, REG_RFE_CTRL8, BIT_MASK_RFE_SEL89,
+ PTA_CTRL_PIN);
+
+ regval = (!polarity_inverse ? 0x2 : 0x1);
+ rtw_write8_mask(rtwdev, REG_RFE_CTRL8, BIT_MASK_R_RFE_SEL_15,
+ regval);
+ break;
+ case COEX_SWITCH_CTRL_BY_ANTDIV:
+ rtw_write32_clr(rtwdev, REG_LED_CFG, BIT_DPDT_SEL_EN);
+ rtw_write32_set(rtwdev, REG_LED_CFG, BIT_DPDT_WL_SEL);
+ rtw_write8_mask(rtwdev, REG_RFE_CTRL8, BIT_MASK_RFE_SEL89,
+ ANTDIC_CTRL_PIN);
+ break;
+ case COEX_SWITCH_CTRL_BY_MAC:
+ rtw_write32_set(rtwdev, REG_LED_CFG, BIT_DPDT_SEL_EN);
+
+ regval = (!polarity_inverse ? 0x0 : 0x1);
+ rtw_write8_mask(rtwdev, REG_PAD_CTRL1, BIT_SW_DPDT_SEL_DATA,
+ regval);
+ break;
+ case COEX_SWITCH_CTRL_BY_FW:
+ rtw_write32_clr(rtwdev, REG_LED_CFG, BIT_DPDT_SEL_EN);
+ rtw_write32_set(rtwdev, REG_LED_CFG, BIT_DPDT_WL_SEL);
+ break;
+ case COEX_SWITCH_CTRL_BY_BT:
+ rtw_write32_clr(rtwdev, REG_LED_CFG, BIT_DPDT_SEL_EN);
+ rtw_write32_clr(rtwdev, REG_LED_CFG, BIT_DPDT_WL_SEL);
+ break;
+ }
+
+ if (ctrl_type == COEX_SWITCH_CTRL_BY_BT) {
+ rtw_write32_clr(rtwdev, REG_CTRL_TYPE, BIT_CTRL_TYPE1);
+ rtw_write32_clr(rtwdev, REG_CTRL_TYPE, BIT_CTRL_TYPE2);
+ } else {
+ rtw_write32_set(rtwdev, REG_CTRL_TYPE, BIT_CTRL_TYPE1);
+ rtw_write32_set(rtwdev, REG_CTRL_TYPE, BIT_CTRL_TYPE2);
+ }
+}
+
+static void rtw8821c_coex_cfg_gnt_fix(struct rtw_dev *rtwdev)
+{}
+
+static void rtw8821c_coex_cfg_gnt_debug(struct rtw_dev *rtwdev)
+{
+ rtw_write32_clr(rtwdev, REG_PAD_CTRL1, BIT_BTGP_SPI_EN);
+ rtw_write32_clr(rtwdev, REG_PAD_CTRL1, BIT_BTGP_JTAG_EN);
+ rtw_write32_clr(rtwdev, REG_GPIO_MUXCFG, BIT_FSPI_EN);
+ rtw_write32_clr(rtwdev, REG_PAD_CTRL1, BIT_LED1DIS);
+ rtw_write32_clr(rtwdev, REG_SYS_SDIO_CTRL, BIT_SDIO_INT);
+ rtw_write32_clr(rtwdev, REG_SYS_SDIO_CTRL, BIT_DBG_GNT_WL_BT);
+}
+
+static void rtw8821c_coex_cfg_rfe_type(struct rtw_dev *rtwdev)
+{
+ struct rtw_coex *coex = &rtwdev->coex;
+ struct rtw_coex_rfe *coex_rfe = &coex->rfe;
+ struct rtw_efuse *efuse = &rtwdev->efuse;
+
+ coex_rfe->rfe_module_type = efuse->rfe_option;
+ coex_rfe->ant_switch_polarity = 0;
+ coex_rfe->ant_switch_exist = true;
+ coex_rfe->wlg_at_btg = false;
+
+ switch (coex_rfe->rfe_module_type) {
+ case 0:
+ case 8:
+ case 1:
+ case 9: /* 1-Ant, Main, WLG */
+ default: /* 2-Ant, DPDT, WLG */
+ break;
+ case 2:
+ case 10: /* 1-Ant, Main, BTG */
+ case 7:
+ case 15: /* 2-Ant, DPDT, BTG */
+ coex_rfe->wlg_at_btg = true;
+ break;
+ case 3:
+ case 11: /* 1-Ant, Aux, WLG */
+ coex_rfe->ant_switch_polarity = 1;
+ break;
+ case 4:
+ case 12: /* 1-Ant, Aux, BTG */
+ coex_rfe->wlg_at_btg = true;
+ coex_rfe->ant_switch_polarity = 1;
+ break;
+ case 5:
+ case 13: /* 2-Ant, no switch, WLG */
+ case 6:
+ case 14: /* 2-Ant, no antenna switch, WLG */
+ coex_rfe->ant_switch_exist = false;
+ break;
+ }
+}
+
+static void rtw8821c_coex_cfg_wl_tx_power(struct rtw_dev *rtwdev, u8 wl_pwr)
+{
+ struct rtw_coex *coex = &rtwdev->coex;
+ struct rtw_coex_dm *coex_dm = &coex->dm;
+ struct rtw_efuse *efuse = &rtwdev->efuse;
+ bool share_ant = efuse->share_ant;
+
+ if (share_ant)
+ return;
+
+ if (wl_pwr == coex_dm->cur_wl_pwr_lvl)
+ return;
+
+ coex_dm->cur_wl_pwr_lvl = wl_pwr;
+}
+
+static void rtw8821c_coex_cfg_wl_rx_gain(struct rtw_dev *rtwdev, bool low_gain)
+{}
+
static void
rtw8821c_txagc_swing_offset(struct rtw_dev *rtwdev, u8 pwr_idx_offset,
s8 pwr_idx_offset_lower,
@@ -1293,8 +1484,166 @@ static struct rtw_chip_ops rtw8821c_ops = {
.config_bfee = rtw8821c_bf_config_bfee,
.set_gid_table = rtw_bf_set_gid_table,
.cfg_csi_rate = rtw_bf_cfg_csi_rate,
+
+ .coex_set_init = rtw8821c_coex_cfg_init,
+ .coex_set_ant_switch = rtw8821c_coex_cfg_ant_switch,
+ .coex_set_gnt_fix = rtw8821c_coex_cfg_gnt_fix,
+ .coex_set_gnt_debug = rtw8821c_coex_cfg_gnt_debug,
+ .coex_set_rfe_type = rtw8821c_coex_cfg_rfe_type,
+ .coex_set_wl_tx_power = rtw8821c_coex_cfg_wl_tx_power,
+ .coex_set_wl_rx_gain = rtw8821c_coex_cfg_wl_rx_gain,
+};
+
+/* rssi in percentage % (dbm = % - 100) */
+static const u8 wl_rssi_step_8821c[] = {101, 45, 101, 40};
+static const u8 bt_rssi_step_8821c[] = {101, 101, 101, 101};
+
+/* Shared-Antenna Coex Table */
+static const struct coex_table_para table_sant_8821c[] = {
+ {0x55555555, 0x55555555}, /* case-0 */
+ {0x55555555, 0x55555555},
+ {0x66555555, 0x66555555},
+ {0xaaaaaaaa, 0xaaaaaaaa},
+ {0x5a5a5a5a, 0x5a5a5a5a},
+ {0xfafafafa, 0xfafafafa}, /* case-5 */
+ {0x6a5a5555, 0xaaaaaaaa},
+ {0x6a5a56aa, 0x6a5a56aa},
+ {0x6a5a5a5a, 0x6a5a5a5a},
+ {0x66555555, 0x5a5a5a5a},
+ {0x66555555, 0x6a5a5a5a}, /* case-10 */
+ {0x66555555, 0xaaaaaaaa},
+ {0x66555555, 0x6a5a5aaa},
+ {0x66555555, 0x6aaa6aaa},
+ {0x66555555, 0x6a5a5aaa},
+ {0x66555555, 0xaaaaaaaa}, /* case-15 */
+ {0xffff55ff, 0xfafafafa},
+ {0xffff55ff, 0x6afa5afa},
+ {0xaaffffaa, 0xfafafafa},
+ {0xaa5555aa, 0x5a5a5a5a},
+ {0xaa5555aa, 0x6a5a5a5a}, /* case-20 */
+ {0xaa5555aa, 0xaaaaaaaa},
+ {0xffffffff, 0x55555555},
+ {0xffffffff, 0x5a5a5a5a},
+ {0xffffffff, 0x5a5a5a5a},
+ {0xffffffff, 0x5a5a5aaa}, /* case-25 */
+ {0x55555555, 0x5a5a5a5a},
+ {0x55555555, 0xaaaaaaaa},
+ {0x66555555, 0x6a5a6a5a},
+ {0x66556655, 0x66556655},
+ {0x66556aaa, 0x6a5a6aaa}, /* case-30 */
+ {0xffffffff, 0x5aaa5aaa},
+ {0x56555555, 0x5a5a5aaa}
+};
+
+/* Non-Shared-Antenna Coex Table */
+static const struct coex_table_para table_nsant_8821c[] = {
+ {0xffffffff, 0xffffffff}, /* case-100 */
+ {0xffff55ff, 0xfafafafa},
+ {0x66555555, 0x66555555},
+ {0xaaaaaaaa, 0xaaaaaaaa},
+ {0x5a5a5a5a, 0x5a5a5a5a},
+ {0xffffffff, 0xffffffff}, /* case-105 */
+ {0x5afa5afa, 0x5afa5afa},
+ {0x55555555, 0xfafafafa},
+ {0x66555555, 0xfafafafa},
+ {0x66555555, 0x5a5a5a5a},
+ {0x66555555, 0x6a5a5a5a}, /* case-110 */
+ {0x66555555, 0xaaaaaaaa},
+ {0xffff55ff, 0xfafafafa},
+ {0xffff55ff, 0x5afa5afa},
+ {0xffff55ff, 0xaaaaaaaa},
+ {0xffff55ff, 0xffff55ff}, /* case-115 */
+ {0xaaffffaa, 0x5afa5afa},
+ {0xaaffffaa, 0xaaaaaaaa},
+ {0xffffffff, 0xfafafafa},
+ {0xffff55ff, 0xfafafafa},
+ {0xffffffff, 0xaaaaaaaa}, /* case-120 */
+ {0xffff55ff, 0x5afa5afa},
+ {0xffff55ff, 0x5afa5afa},
+ {0x55ff55ff, 0x55ff55ff}
+};
+
+/* Shared-Antenna TDMA */
+static const struct coex_tdma_para tdma_sant_8821c[] = {
+ { {0x00, 0x00, 0x00, 0x00, 0x00} }, /* case-0 */
+ { {0x61, 0x45, 0x03, 0x11, 0x11} }, /* case-1 */
+ { {0x61, 0x3a, 0x03, 0x11, 0x11} },
+ { {0x61, 0x35, 0x03, 0x11, 0x11} },
+ { {0x61, 0x20, 0x03, 0x11, 0x11} },
+ { {0x61, 0x3a, 0x03, 0x11, 0x11} }, /* case-5 */
+ { {0x61, 0x45, 0x03, 0x11, 0x10} },
+ { {0x61, 0x35, 0x03, 0x11, 0x10} },
+ { {0x61, 0x30, 0x03, 0x11, 0x10} },
+ { {0x61, 0x20, 0x03, 0x11, 0x10} },
+ { {0x61, 0x10, 0x03, 0x11, 0x10} }, /* case-10 */
+ { {0x61, 0x08, 0x03, 0x11, 0x15} },
+ { {0x61, 0x08, 0x03, 0x10, 0x14} },
+ { {0x51, 0x08, 0x03, 0x10, 0x54} },
+ { {0x51, 0x08, 0x03, 0x10, 0x55} },
+ { {0x51, 0x08, 0x07, 0x10, 0x54} }, /* case-15 */
+ { {0x51, 0x45, 0x03, 0x10, 0x50} },
+ { {0x51, 0x3a, 0x03, 0x11, 0x50} },
+ { {0x51, 0x30, 0x03, 0x10, 0x50} },
+ { {0x51, 0x21, 0x03, 0x10, 0x50} },
+ { {0x51, 0x10, 0x03, 0x10, 0x50} }, /* case-20 */
+ { {0x51, 0x4a, 0x03, 0x10, 0x50} },
+ { {0x51, 0x08, 0x03, 0x30, 0x54} },
+ { {0x55, 0x08, 0x03, 0x10, 0x54} },
+ { {0x65, 0x10, 0x03, 0x11, 0x10} },
+ { {0x51, 0x10, 0x03, 0x10, 0x51} }, /* case-25 */
+ { {0x51, 0x21, 0x03, 0x10, 0x50} },
+ { {0x61, 0x08, 0x03, 0x11, 0x11} }
+};
+
+/* Non-Shared-Antenna TDMA */
+static const struct coex_tdma_para tdma_nsant_8821c[] = {
+ { {0x00, 0x00, 0x00, 0x40, 0x00} }, /* case-100 */
+ { {0x61, 0x45, 0x03, 0x11, 0x11} },
+ { {0x61, 0x25, 0x03, 0x11, 0x11} },
+ { {0x61, 0x35, 0x03, 0x11, 0x11} },
+ { {0x61, 0x20, 0x03, 0x11, 0x11} },
+ { {0x61, 0x10, 0x03, 0x11, 0x11} }, /* case-105 */
+ { {0x61, 0x45, 0x03, 0x11, 0x10} },
+ { {0x61, 0x30, 0x03, 0x11, 0x10} },
+ { {0x61, 0x30, 0x03, 0x11, 0x10} },
+ { {0x61, 0x20, 0x03, 0x11, 0x10} },
+ { {0x61, 0x10, 0x03, 0x11, 0x10} }, /* case-110 */
+ { {0x61, 0x10, 0x03, 0x11, 0x11} },
+ { {0x61, 0x08, 0x03, 0x10, 0x14} },
+ { {0x51, 0x08, 0x03, 0x10, 0x54} },
+ { {0x51, 0x08, 0x03, 0x10, 0x55} },
+ { {0x51, 0x08, 0x07, 0x10, 0x54} }, /* case-115 */
+ { {0x51, 0x45, 0x03, 0x10, 0x50} },
+ { {0x51, 0x3a, 0x03, 0x10, 0x50} },
+ { {0x51, 0x30, 0x03, 0x10, 0x50} },
+ { {0x51, 0x21, 0x03, 0x10, 0x50} },
+ { {0x51, 0x21, 0x03, 0x10, 0x50} }, /* case-120 */
+ { {0x51, 0x10, 0x03, 0x10, 0x50} }
};
+static const struct coex_5g_afh_map afh_5g_8821c[] = { {0, 0, 0} };
+
+/* wl_tx_dec_power, bt_tx_dec_power, wl_rx_gain, bt_rx_lna_constrain */
+static const struct coex_rf_para rf_para_tx_8821c[] = {
+ {0, 0, false, 7}, /* for normal */
+ {0, 20, false, 7}, /* for WL-CPT */
+ {8, 17, true, 4},
+ {7, 18, true, 4},
+ {6, 19, true, 4},
+ {5, 20, true, 4}
+};
+
+static const struct coex_rf_para rf_para_rx_8821c[] = {
+ {0, 0, false, 7}, /* for normal */
+ {0, 20, false, 7}, /* for WL-CPT */
+ {3, 24, true, 5},
+ {2, 26, true, 5},
+ {1, 27, true, 5},
+ {0, 28, true, 5}
+};
+
+static_assert(ARRAY_SIZE(rf_para_tx_8821c) == ARRAY_SIZE(rf_para_rx_8821c));
+
static const u8 rtw8821c_pwrtrk_5gb_n[][RTW_PWR_TRK_TBL_SZ] = {
{0, 1, 1, 2, 3, 3, 3, 4, 4, 5, 5, 6, 6, 6, 7, 8, 8, 8, 9, 9, 9, 10, 10,
11, 11, 12, 12, 12, 12, 12},
@@ -1394,6 +1743,31 @@ const struct rtw_pwr_track_tbl rtw8821c_rtw_pwr_track_tbl = {
.pwrtrk_2g_ccka_p = rtw8821c_pwrtrk_2g_cck_a_p,
};
+static const struct rtw_reg_domain coex_info_hw_regs_8821c[] = {
+ {0xCB0, MASKDWORD, RTW_REG_DOMAIN_MAC32},
+ {0xCB4, MASKDWORD, RTW_REG_DOMAIN_MAC32},
+ {0xCBA, MASKBYTE0, RTW_REG_DOMAIN_MAC8},
+ {0, 0, RTW_REG_DOMAIN_NL},
+ {0x430, MASKDWORD, RTW_REG_DOMAIN_MAC32},
+ {0x434, MASKDWORD, RTW_REG_DOMAIN_MAC32},
+ {0x42a, MASKLWORD, RTW_REG_DOMAIN_MAC16},
+ {0x426, MASKBYTE0, RTW_REG_DOMAIN_MAC8},
+ {0x45e, BIT(3), RTW_REG_DOMAIN_MAC8},
+ {0x454, MASKLWORD, RTW_REG_DOMAIN_MAC16},
+ {0, 0, RTW_REG_DOMAIN_NL},
+ {0x4c, BIT(24) | BIT(23), RTW_REG_DOMAIN_MAC32},
+ {0x64, BIT(0), RTW_REG_DOMAIN_MAC8},
+ {0x4c6, BIT(4), RTW_REG_DOMAIN_MAC8},
+ {0x40, BIT(5), RTW_REG_DOMAIN_MAC8},
+ {0x1, RFREG_MASK, RTW_REG_DOMAIN_RF_A},
+ {0, 0, RTW_REG_DOMAIN_NL},
+ {0x550, MASKDWORD, RTW_REG_DOMAIN_MAC32},
+ {0x522, MASKBYTE0, RTW_REG_DOMAIN_MAC8},
+ {0x953, BIT(1), RTW_REG_DOMAIN_MAC8},
+ {0xc50, MASKBYTE0, RTW_REG_DOMAIN_MAC8},
+ {0x60A, MASKBYTE0, RTW_REG_DOMAIN_MAC8},
+};
+
struct rtw_chip_info rtw8821c_hw_spec = {
.ops = &rtw8821c_ops,
.id = RTW_CHIP_TYPE_8821C,
@@ -1440,6 +1814,35 @@ struct rtw_chip_info rtw8821c_hw_spec = {
.iqk_threshold = 8,
.bfer_su_max_num = 2,
.bfer_mu_max_num = 1,
+
+ .coex_para_ver = 0x19092746,
+ .bt_desired_ver = 0x46,
+ .scbd_support = true,
+ .new_scbd10_def = false,
+ .pstdma_type = COEX_PSTDMA_FORCE_LPSOFF,
+ .bt_rssi_type = COEX_BTRSSI_RATIO,
+ .ant_isolation = 15,
+ .rssi_tolerance = 2,
+ .wl_rssi_step = wl_rssi_step_8821c,
+ .bt_rssi_step = bt_rssi_step_8821c,
+ .table_sant_num = ARRAY_SIZE(table_sant_8821c),
+ .table_sant = table_sant_8821c,
+ .table_nsant_num = ARRAY_SIZE(table_nsant_8821c),
+ .table_nsant = table_nsant_8821c,
+ .tdma_sant_num = ARRAY_SIZE(tdma_sant_8821c),
+ .tdma_sant = tdma_sant_8821c,
+ .tdma_nsant_num = ARRAY_SIZE(tdma_nsant_8821c),
+ .tdma_nsant = tdma_nsant_8821c,
+ .wl_rf_para_num = ARRAY_SIZE(rf_para_tx_8821c),
+ .wl_rf_para_tx = rf_para_tx_8821c,
+ .wl_rf_para_rx = rf_para_rx_8821c,
+ .bt_afh_span_bw20 = 0x24,
+ .bt_afh_span_bw40 = 0x36,
+ .afh_5g_num = ARRAY_SIZE(afh_5g_8821c),
+ .afh_5g = afh_5g_8821c,
+
+ .coex_info_hw_regs_num = ARRAY_SIZE(coex_info_hw_regs_8821c),
+ .coex_info_hw_regs = coex_info_hw_regs_8821c,
};
EXPORT_SYMBOL(rtw8821c_hw_spec);
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.h b/drivers/net/wireless/realtek/rtw88/rtw8821c.h
index 166bd0e9294e..bd01e82b6bcd 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.h
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.h
@@ -160,6 +160,18 @@ _rtw_write32s_mask(struct rtw_dev *rtwdev, u32 addr, u32 mask, u32 data)
le32_get_bits(*((__le32 *)(phy_stat) + 0x01), GENMASK(11, 8))
#define GET_PHY_STAT_P1_HT_RXSC(phy_stat) \
le32_get_bits(*((__le32 *)(phy_stat) + 0x01), GENMASK(15, 12))
+#define GET_PHY_STAT_P1_RXEVM_A(phy_stat) \
+ le32_get_bits(*((__le32 *)(phy_stat) + 0x04), GENMASK(7, 0))
+#define GET_PHY_STAT_P1_RXEVM_B(phy_stat) \
+ le32_get_bits(*((__le32 *)(phy_stat) + 0x04), GENMASK(15, 8))
+#define GET_PHY_STAT_P1_CFO_TAIL_A(phy_stat) \
+ le32_get_bits(*((__le32 *)(phy_stat) + 0x05), GENMASK(7, 0))
+#define GET_PHY_STAT_P1_CFO_TAIL_B(phy_stat) \
+ le32_get_bits(*((__le32 *)(phy_stat) + 0x05), GENMASK(15, 8))
+#define GET_PHY_STAT_P1_RXSNR_A(phy_stat) \
+ le32_get_bits(*((__le32 *)(phy_stat) + 0x06), GENMASK(7, 0))
+#define GET_PHY_STAT_P1_RXSNR_B(phy_stat) \
+ le32_get_bits(*((__le32 *)(phy_stat) + 0x06), GENMASK(15, 8))
#define REG_INIRTS_RATE_SEL 0x0480
#define REG_HTSTFWT 0x800
@@ -217,6 +229,20 @@ _rtw_write32s_mask(struct rtw_dev *rtwdev, u32 addr, u32 mask, u32 data)
#define REG_CCA_CCK 0xfcc
#define REG_ANTWT 0x1904
#define REG_IQKFAILMSK 0x1bf0
+#define BIT_MASK_R_RFE_SEL_15 GENMASK(31, 28)
+#define BIT_SDIO_INT BIT(18)
+#define SAMPLE_RATE_MASK GENMASK(5, 0)
+#define SAMPLE_RATE 0x5
+#define BT_CNT_ENABLE 0x1
+#define BIT_BCN_QUEUE BIT(3)
+#define BCN_PRI_EN 0x1
+#define PTA_CTRL_PIN 0x66
+#define DPDT_CTRL_PIN 0x77
+#define ANTDIC_CTRL_PIN 0x88
+#define REG_CTRL_TYPE 0x67
+#define BIT_CTRL_TYPE1 BIT(5)
+#define BIT_CTRL_TYPE2 BIT(4)
+#define CTRL_TYPE_MASK GENMASK(15, 8)
#define RF18_BAND_MASK (BIT(16) | BIT(9) | BIT(8))
#define RF18_BAND_2G (0)
--
2.17.1
^ permalink raw reply related
* RE: [PATCH 2/2] VT-d: use clear_page() in alloc_pgtable_maddr()
From: Tian, Kevin @ 2020-07-17 2:49 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xenproject.org
In-Reply-To: <14f8b940-252f-9837-8958-5e76e1c3f06f@suse.com>
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, July 15, 2020 6:04 PM
>
> For full pages this is (meant to be) more efficient. Also change the
> type and reduce the scope of the involved local variable.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -199,7 +199,6 @@ static void sync_cache(const void *addr,
> uint64_t alloc_pgtable_maddr(unsigned long npages, nodeid_t node)
> {
> struct page_info *pg, *cur_pg;
> - u64 *vaddr;
> unsigned int i;
>
> pg = alloc_domheap_pages(NULL, get_order_from_pages(npages),
> @@ -210,8 +209,9 @@ uint64_t alloc_pgtable_maddr(unsigned lo
> cur_pg = pg;
> for ( i = 0; i < npages; i++ )
> {
> - vaddr = __map_domain_page(cur_pg);
> - memset(vaddr, 0, PAGE_SIZE);
> + void *vaddr = __map_domain_page(cur_pg);
> +
> + clear_page(vaddr);
>
> if ( (iommu_ops.init ? &iommu_ops : &vtd_ops)->sync_cache )
> sync_cache(vaddr, PAGE_SIZE);
^ permalink raw reply
* RE: [PATCH 1/2] VT-d: install sync_cache hook on demand
From: Tian, Kevin @ 2020-07-17 2:48 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xenproject.org
In-Reply-To: <0036b69f-0d56-9ac4-1afa-06640c9007de@suse.com>
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, July 15, 2020 6:04 PM
>
> Instead of checking inside the hook whether any non-coherent IOMMUs are
> present, simply install the hook only when this is the case.
>
> To prove that there are no other references to the now dynamically
> updated ops structure (and hence that its updating happens early
> enough), make it static and rename it at the same time.
>
> Note that this change implies that sync_cache() shouldn't be called
> directly unless there are unusual circumstances, like is the case in
> alloc_pgtable_maddr(), which gets invoked too early for iommu_ops to
> be set already (and therefore we also need to be careful there to
> avoid accessing vtd_ops later on, as it lives in .init).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
>
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -28,7 +28,6 @@
> struct pci_ats_dev;
> extern bool_t rwbf_quirk;
> extern const struct iommu_init_ops intel_iommu_init_ops;
> -extern const struct iommu_ops intel_iommu_ops;
>
> void print_iommu_regs(struct acpi_drhd_unit *drhd);
> void print_vtd_entries(struct vtd_iommu *iommu, int bus, int devfn, u64
> gmfn);
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -59,6 +59,7 @@ bool __read_mostly iommu_snoop = true;
>
> int nr_iommus;
>
> +static struct iommu_ops vtd_ops;
> static struct tasklet vtd_fault_tasklet;
>
> static int setup_hwdom_device(u8 devfn, struct pci_dev *);
> @@ -146,16 +147,11 @@ static int context_get_domain_id(struct
> return domid;
> }
>
> -static int iommus_incoherent;
> -
> static void sync_cache(const void *addr, unsigned int size)
> {
> static unsigned long clflush_size = 0;
> const void *end = addr + size;
>
> - if ( !iommus_incoherent )
> - return;
> -
> if ( clflush_size == 0 )
> clflush_size = get_cache_line_size();
>
> @@ -217,7 +213,8 @@ uint64_t alloc_pgtable_maddr(unsigned lo
> vaddr = __map_domain_page(cur_pg);
> memset(vaddr, 0, PAGE_SIZE);
>
> - sync_cache(vaddr, PAGE_SIZE);
> + if ( (iommu_ops.init ? &iommu_ops : &vtd_ops)->sync_cache )
> + sync_cache(vaddr, PAGE_SIZE);
> unmap_domain_page(vaddr);
> cur_pg++;
> }
> @@ -1227,7 +1224,7 @@ int __init iommu_alloc(struct acpi_drhd_
> iommu->nr_pt_levels = agaw_to_level(agaw);
>
> if ( !ecap_coherent(iommu->ecap) )
> - iommus_incoherent = 1;
> + vtd_ops.sync_cache = sync_cache;
>
> /* allocate domain id bitmap */
> nr_dom = cap_ndoms(iommu->cap);
> @@ -2737,7 +2734,7 @@ static int __init intel_iommu_quarantine
> return level ? -ENOMEM : rc;
> }
>
> -const struct iommu_ops __initconstrel intel_iommu_ops = {
> +static struct iommu_ops __initdata vtd_ops = {
> .init = intel_iommu_domain_init,
> .hwdom_init = intel_iommu_hwdom_init,
> .quarantine_init = intel_iommu_quarantine_init,
> @@ -2768,11 +2765,10 @@ const struct iommu_ops __initconstrel in
> .iotlb_flush_all = iommu_flush_iotlb_all,
> .get_reserved_device_memory =
> intel_iommu_get_reserved_device_memory,
> .dump_p2m_table = vtd_dump_p2m_table,
> - .sync_cache = sync_cache,
> };
>
> const struct iommu_init_ops __initconstrel intel_iommu_init_ops = {
> - .ops = &intel_iommu_ops,
> + .ops = &vtd_ops,
> .setup = vtd_setup,
> .supports_x2apic = intel_iommu_supports_eim,
> };
^ permalink raw reply
* [f2fs-dev] [Bug 208565] There may be dead lock for cp_rwsem during checkpoint
From: bugzilla-daemon @ 2020-07-17 2:47 UTC (permalink / raw)
To: linux-f2fs-devel
In-Reply-To: <bug-208565-202145@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=208565
--- Comment #5 from Zhiguo.Niu (Zhiguo.Niu@unisoc.com) ---
(In reply to Jaegeuk Kim from comment #1)
> Thank you for the report.
>
> I think this is valid point that we need to fix.
> I'm testing a RFC patch like this. Thanks.
>
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1926,8 +1926,12 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> goto continue_unlock;
> }
>
> - /* flush inline_data, if it's async context. */
> - if (do_balance && is_inline_node(page)) {
> + /* flush inline_data/inode, if it's async context. */
> + if (!do_balance)
> + goto write_node;
> +
> + /* flush inline_data */
> + if (is_inline_node(page)) {
> clear_inline_node(page);
> unlock_page(page);
> flush_inline_data(sbi, ino_of_node(page));
> @@ -1940,7 +1944,7 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> if (flush_dirty_inode(page))
> goto lock_node;
> }
> -
> +write_node:
> f2fs_wait_on_page_writeback(page, NODE, true, true);
>
> if (!clear_page_dirty_for_io(page))
Hi Jaegeuk Kim
for comment 1, can you help provide a full diff for this patch, I can not apply
it directly because of the following error:
> fatal: patch fragment without header at line 3: @@ -1926,8 +1926,12 @@ int
> f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
or Should I merge it by Manually?
thanks a lot~
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/perf: Whitelist OA report trigger registers
From: Patchwork @ 2020-07-17 2:47 UTC (permalink / raw)
To: Umesh Nerlige Ramappa; +Cc: intel-gfx
In-Reply-To: <20200717015716.37671-1-umesh.nerlige.ramappa@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 13854 bytes --]
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: Whitelist OA report trigger registers
URL : https://patchwork.freedesktop.org/series/79571/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8759 -> Patchwork_18199
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_18199 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18199, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_18199:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live@workarounds:
- fi-tgl-u2: [PASS][1] -> [DMESG-FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-u2/igt@i915_selftest@live@workarounds.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-u2/igt@i915_selftest@live@workarounds.html
- fi-skl-6700k2: [PASS][3] -> [DMESG-FAIL][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-skl-6700k2/igt@i915_selftest@live@workarounds.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-skl-6700k2/igt@i915_selftest@live@workarounds.html
- fi-cml-s: [PASS][5] -> [DMESG-FAIL][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-cml-s/igt@i915_selftest@live@workarounds.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-cml-s/igt@i915_selftest@live@workarounds.html
- fi-icl-y: [PASS][7] -> [DMESG-FAIL][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-y/igt@i915_selftest@live@workarounds.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-icl-y/igt@i915_selftest@live@workarounds.html
- fi-kbl-x1275: [PASS][9] -> [DMESG-FAIL][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@i915_selftest@live@workarounds.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-x1275/igt@i915_selftest@live@workarounds.html
- fi-cfl-guc: [PASS][11] -> [DMESG-FAIL][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-cfl-guc/igt@i915_selftest@live@workarounds.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-cfl-guc/igt@i915_selftest@live@workarounds.html
- fi-tgl-y: [PASS][13] -> [DMESG-FAIL][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@i915_selftest@live@workarounds.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-y/igt@i915_selftest@live@workarounds.html
- fi-skl-guc: [PASS][15] -> [DMESG-FAIL][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-skl-guc/igt@i915_selftest@live@workarounds.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-skl-guc/igt@i915_selftest@live@workarounds.html
- fi-skl-6600u: [PASS][17] -> [DMESG-FAIL][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-skl-6600u/igt@i915_selftest@live@workarounds.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-skl-6600u/igt@i915_selftest@live@workarounds.html
- fi-kbl-8809g: [PASS][19] -> [DMESG-FAIL][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-8809g/igt@i915_selftest@live@workarounds.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-8809g/igt@i915_selftest@live@workarounds.html
- fi-cfl-8700k: [PASS][21] -> [DMESG-FAIL][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-cfl-8700k/igt@i915_selftest@live@workarounds.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-cfl-8700k/igt@i915_selftest@live@workarounds.html
- fi-kbl-r: [PASS][23] -> [DMESG-FAIL][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-r/igt@i915_selftest@live@workarounds.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-r/igt@i915_selftest@live@workarounds.html
- fi-icl-u2: [PASS][25] -> [DMESG-FAIL][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-u2/igt@i915_selftest@live@workarounds.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-icl-u2/igt@i915_selftest@live@workarounds.html
- fi-cfl-8109u: [PASS][27] -> [DMESG-FAIL][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-cfl-8109u/igt@i915_selftest@live@workarounds.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-cfl-8109u/igt@i915_selftest@live@workarounds.html
- fi-skl-lmem: [PASS][29] -> [DMESG-FAIL][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-skl-lmem/igt@i915_selftest@live@workarounds.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-skl-lmem/igt@i915_selftest@live@workarounds.html
- fi-kbl-7500u: [PASS][31] -> [DMESG-FAIL][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-7500u/igt@i915_selftest@live@workarounds.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-7500u/igt@i915_selftest@live@workarounds.html
- fi-kbl-guc: [PASS][33] -> [DMESG-FAIL][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-guc/igt@i915_selftest@live@workarounds.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-guc/igt@i915_selftest@live@workarounds.html
- fi-kbl-soraka: [PASS][35] -> [DMESG-FAIL][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-soraka/igt@i915_selftest@live@workarounds.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-soraka/igt@i915_selftest@live@workarounds.html
- fi-whl-u: [PASS][37] -> [DMESG-FAIL][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-whl-u/igt@i915_selftest@live@workarounds.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-whl-u/igt@i915_selftest@live@workarounds.html
- fi-cml-u2: [PASS][39] -> [DMESG-FAIL][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-cml-u2/igt@i915_selftest@live@workarounds.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-cml-u2/igt@i915_selftest@live@workarounds.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@workarounds:
- {fi-tgl-dsi}: [PASS][41] -> [DMESG-FAIL][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-dsi/igt@i915_selftest@live@workarounds.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-dsi/igt@i915_selftest@live@workarounds.html
- {fi-ehl-1}: [PASS][43] -> [DMESG-FAIL][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-ehl-1/igt@i915_selftest@live@workarounds.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-ehl-1/igt@i915_selftest@live@workarounds.html
- {fi-kbl-7560u}: [PASS][45] -> [DMESG-FAIL][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-7560u/igt@i915_selftest@live@workarounds.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-7560u/igt@i915_selftest@live@workarounds.html
Known issues
------------
Here are the changes found in Patchwork_18199 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_selftest@live@workarounds:
- fi-apl-guc: [PASS][47] -> [DMESG-FAIL][48] ([i915#1635])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-apl-guc/igt@i915_selftest@live@workarounds.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-apl-guc/igt@i915_selftest@live@workarounds.html
- fi-bxt-dsi: [PASS][49] -> [DMESG-FAIL][50] ([i915#1635])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-bxt-dsi/igt@i915_selftest@live@workarounds.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-bxt-dsi/igt@i915_selftest@live@workarounds.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [PASS][51] -> [DMESG-WARN][52] ([i915#1982])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-vga1:
- fi-elk-e7500: [PASS][53] -> [FAIL][54] ([i915#2122])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-elk-e7500/igt@kms_flip@basic-flip-vs-wf_vblank@b-vga1.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-elk-e7500/igt@kms_flip@basic-flip-vs-wf_vblank@b-vga1.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][55] -> [DMESG-WARN][56] ([i915#402]) +1 similar issue
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@vgem_basic@setversion.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-y/igt@vgem_basic@setversion.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][57] ([i915#1888]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [DMESG-WARN][59] ([i915#1982]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@kms_busy@basic@flip.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-y/igt@kms_busy@basic@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][61] ([i915#1982]) -> [PASS][62] +1 similar issue
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1.html
* igt@prime_vgem@basic-write:
- fi-tgl-y: [DMESG-WARN][63] ([i915#402]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@prime_vgem@basic-write.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-tgl-y/igt@prime_vgem@basic-write.html
#### Warnings ####
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][65] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][66] ([i915#62] / [i915#92])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][67] ([i915#62] / [i915#92]) -> [DMESG-WARN][68] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][69] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][70] ([i915#62] / [i915#92]) +3 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@prime_vgem@basic-fence-flip.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/fi-kbl-x1275/igt@prime_vgem@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (45 -> 40)
------------------------------
Missing (5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper
Build changes
-------------
* Linux: CI_DRM_8759 -> Patchwork_18199
CI-20190529: 20190529
CI_DRM_8759: 9136d875406863759c4c7939f4b32edf7d76b007 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5738: bc8b56fe177af34fbde7b96f1f66614a0014c6ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18199: 54031bcae51f6d6403036e81ab52bdaa55d4cdf5 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
54031bcae51f drm/i915/perf: Map OA buffer to user space for gen12 performance query
9c529f1bfafe drm/i915/perf: Whitelist OA counter and buffer registers
451a46ae0075 drm/i915/perf: Whitelist OA report trigger registers
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18199/index.html
[-- Attachment #1.2: Type: text/html, Size: 16252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v2] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros
From: Saravana Kannan @ 2020-07-17 2:44 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger
Cc: CC Hwang, Saravana Kannan, Hanks Chen, Loda Chou, linux-kernel,
John Stultz, linux-mediatek, kernel-team, linux-arm-kernel
Compiling an irqchip driver as a platform driver needs to bunch of
things to be done right:
- Making sure the parent domain is initialized first
- Making sure the device can't be unbound from sysfs
- Disallowing module unload if it's built as a module
- Finding the parent node
- Etc.
Instead of trying to make sure all future irqchip platform drivers get
this right, provide boilerplate macros that take care of all of this.
An example use would look something like this. Where acme_foo_init and
acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE.
IRQCHIP_PLATFORM_DRIVER_BEGIN
IRQCHIP_MATCH(foo, "acme,foo", acme_foo_init)
IRQCHIP_MATCH(bar, "acme,bar", acme_bar_init)
IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/irqchip/irqchip.c | 22 ++++++++++++++++++++++
include/linux/irqchip.h | 23 +++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index 2b35e68bea82..236ea793f01c 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -10,8 +10,10 @@
#include <linux/acpi.h>
#include <linux/init.h>
+#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/irqchip.h>
+#include <linux/platform_device.h>
/*
* This special of_device_id is the sentinel at the end of the
@@ -29,3 +31,23 @@ void __init irqchip_init(void)
of_irq_init(__irqchip_of_table);
acpi_probe_device_table(irqchip);
}
+
+int platform_irqchip_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *par_np = of_irq_find_parent(np);
+ of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev);
+
+ if (!irq_init_cb)
+ return -EINVAL;
+
+ if (par_np == np)
+ par_np = NULL;
+
+ /* If there's a parent irqchip, make sure it has been initialized. */
+ if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY))
+ return -EPROBE_DEFER;
+
+ return irq_init_cb(np, par_np);
+}
+EXPORT_SYMBOL_GPL(platform_irqchip_probe);
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
index 950e4b2458f0..6d5eba7cbbb7 100644
--- a/include/linux/irqchip.h
+++ b/include/linux/irqchip.h
@@ -13,6 +13,7 @@
#include <linux/acpi.h>
#include <linux/of.h>
+#include <linux/platform_device.h>
/*
* This macro must be used by the different irqchip drivers to declare
@@ -26,6 +27,28 @@
*/
#define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn)
+extern int platform_irqchip_probe(struct platform_device *pdev);
+
+#define IRQCHIP_PLATFORM_DRIVER_BEGIN \
+static const struct of_device_id __irqchip_match_table[] = {
+
+#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn },
+
+#define IRQCHIP_PLATFORM_DRIVER_END(drv_name) \
+ {}, \
+}; \
+MODULE_DEVICE_TABLE(of, __irqchip_match_table); \
+static struct platform_driver drv_name##_driver = { \
+ .probe = platform_irqchip_probe, \
+ .driver = { \
+ .name = #drv_name, \
+ .owner = THIS_MODULE, \
+ .of_match_table = __irqchip_match_table,\
+ .suppress_bind_attrs = true, \
+ }, \
+}; \
+builtin_platform_driver(drv_name##_driver)
+
/*
* This macro must be used by the different irqchip drivers to declare
* the association between their version and their initialization function.
--
2.28.0.rc0.105.gf9edc3c819-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 0/3] Off-load TLB invalidations to host for !GTSE
From: Nicholas Piggin @ 2020-07-17 2:44 UTC (permalink / raw)
To: Bharata B Rao, Qian Cai
Cc: sfr, aneesh.kumar, linux-kernel, linux-next, linuxppc-dev
In-Reply-To: <1594950229.jn9ipe6td1.astroid@bobo.none>
Excerpts from Nicholas Piggin's message of July 17, 2020 12:08 pm:
> Excerpts from Qian Cai's message of July 17, 2020 3:27 am:
>> On Fri, Jul 03, 2020 at 11:06:05AM +0530, Bharata B Rao wrote:
>>> Hypervisor may choose not to enable Guest Translation Shootdown Enable
>>> (GTSE) option for the guest. When GTSE isn't ON, the guest OS isn't
>>> permitted to use instructions like tblie and tlbsync directly, but is
>>> expected to make hypervisor calls to get the TLB flushed.
>>>
>>> This series enables the TLB flush routines in the radix code to
>>> off-load TLB flushing to hypervisor via the newly proposed hcall
>>> H_RPT_INVALIDATE.
>>>
>>> To easily check the availability of GTSE, it is made an MMU feature.
>>> The OV5 handling and H_REGISTER_PROC_TBL hcall are changed to
>>> handle GTSE as an optionally available feature and to not assume GTSE
>>> when radix support is available.
>>>
>>> The actual hcall implementation for KVM isn't included in this
>>> patchset and will be posted separately.
>>>
>>> Changes in v3
>>> =============
>>> - Fixed a bug in the hcall wrapper code where we were missing setting
>>> H_RPTI_TYPE_NESTED while retrying the failed flush request with
>>> a full flush for the nested case.
>>> - s/psize_to_h_rpti/psize_to_rpti_pgsize
>>>
>>> v2: https://lore.kernel.org/linuxppc-dev/20200626131000.5207-1-bharata@linux.ibm.com/T/#t
>>>
>>> Bharata B Rao (2):
>>> powerpc/mm: Enable radix GTSE only if supported.
>>> powerpc/pseries: H_REGISTER_PROC_TBL should ask for GTSE only if
>>> enabled
>>>
>>> Nicholas Piggin (1):
>>> powerpc/mm/book3s64/radix: Off-load TLB invalidations to host when
>>> !GTSE
>>
>> Reverting the whole series fixed random memory corruptions during boot on
>> POWER9 PowerNV systems below.
>
> If I s/mmu_has_feature(MMU_FTR_GTSE)/(1)/g in radix_tlb.c, then the .o
> disasm is the same as reverting my patch.
>
> Feature bits not being set right? PowerNV should be pretty simple, seems
> to do the same as FTR_TYPE_RADIX.
Might need this fix
---
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9cc49f265c86..54c9bcea9d4e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -163,7 +163,7 @@ static struct ibm_pa_feature {
{ .pabyte = 0, .pabit = 6, .cpu_features = CPU_FTR_NOEXECUTE },
{ .pabyte = 1, .pabit = 2, .mmu_features = MMU_FTR_CI_LARGE_PAGE },
#ifdef CONFIG_PPC_RADIX_MMU
- { .pabyte = 40, .pabit = 0, .mmu_features = MMU_FTR_TYPE_RADIX },
+ { .pabyte = 40, .pabit = 0, .mmu_features = (MMU_FTR_TYPE_RADIX | MMU_FTR_GTSE) },
#endif
{ .pabyte = 1, .pabit = 1, .invert = 1, .cpu_features = CPU_FTR_NODSISRALIGN },
{ .pabyte = 5, .pabit = 0, .cpu_features = CPU_FTR_REAL_LE,
^ permalink raw reply related
* Re: [PATCH] block: align max append sectors to physical block size
From: Damien Le Moal @ 2020-07-17 2:45 UTC (permalink / raw)
To: hch@infradead.org, Johannes Thumshirn
Cc: Jens Axboe, linux-block@vger.kernel.org
In-Reply-To: <20200716143441.GA937@infradead.org>
On 2020/07/16 23:35, Christoph Hellwig wrote:
> On Thu, Jul 16, 2020 at 07:09:33PM +0900, Johannes Thumshirn wrote:
>> Max append sectors needs to be aligned to physical block size, otherwise
>> we can end up in a situation where it's off by 1-3 sectors which would
>> cause short writes with asynchronous zone append submissions from an FS.
>
> Huh? The physical block size is purely a hint.
For ZBC/ZAC SMR drives, all writes must be aligned to the physical sector size.
However, sd/sd_zbc does not change max_hw_sectors_kb to ensure alignment to 4K
on 512e disks. There is also nullblk which uses the default max_hw_sectors_kb to
255 x 512B sectors, which is not 4K aligned if the nullb device is created with
4K block size.
So we can fix each driver separately to ensure that we end up with a sensible
max_hw_sectors_kb and by extension a sensible value for max_zone_append_sectors,
or we could force this alignment in blk_queue_max_hw_sectors().
Right now, without any fix, there are setups that end up having weird values
that the user have to sort through and may have a hard time making sense of.
>
>>
>> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>> ---
>> block/blk-settings.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/block/blk-settings.c b/block/blk-settings.c
>> index 9a2c23cd9700..d75c4cc34a7a 100644
>> --- a/block/blk-settings.c
>> +++ b/block/blk-settings.c
>> @@ -231,6 +231,7 @@ EXPORT_SYMBOL(blk_queue_max_write_zeroes_sectors);
>> void blk_queue_max_zone_append_sectors(struct request_queue *q,
>> unsigned int max_zone_append_sectors)
>> {
>> + unsigned int phys = queue_physical_block_size(q);
>> unsigned int max_sectors;
>>
>> if (WARN_ON(!blk_queue_is_zoned(q)))
>> @@ -246,6 +247,13 @@ void blk_queue_max_zone_append_sectors(struct request_queue *q,
>> */
>> WARN_ON(!max_sectors);
>>
>> + /*
>> + * Max append sectors needs to be aligned to physical block size,
>> + * otherwise we can end up in a situation where it's off by 1-3 sectors
>> + * which would cause short writes with asynchronous zone append
>> + * submissions from an FS.
>> + */
>> + max_sectors = ALIGN_DOWN(max_sectors << 9, phys) >> 9;
>> q->limits.max_zone_append_sectors = max_sectors;
>> }
>> EXPORT_SYMBOL_GPL(blk_queue_max_zone_append_sectors);
>> --
>> 2.26.2
>>
> ---end quoted text---
>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* [PATCH v2] mm: mmap: Merge vma after call_mmap() if possible
From: linmiaohe @ 2020-07-17 2:47 UTC (permalink / raw)
To: akpm; +Cc: linux-mm, linux-kernel, linmiaohe
From: Miaohe Lin <linmiaohe@huawei.com>
The vm_flags may be changed after call_mmap() because drivers may set some
flags for their own purpose. As a result, we failed to merge the adjacent
vma due to the different vm_flags as userspace can't pass in the same one.
Try to merge vma after call_mmap() to fix this issue.
Signed-off-by: Hongxiang Lou <louhongxiang@huawei.com>
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
Changes in v2:
update vm_flags and possible addr to pick up the change
---
mm/mmap.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 59a4682ebf3f..720721877b89 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1689,7 +1689,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
struct list_head *uf)
{
struct mm_struct *mm = current->mm;
- struct vm_area_struct *vma, *prev;
+ struct vm_area_struct *vma, *prev, *merge;
int error;
struct rb_node **rb_link, *rb_parent;
unsigned long charged = 0;
@@ -1773,6 +1773,25 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
if (error)
goto unmap_and_free_vma;
+ /* If vm_flags changed after call_mmap(), we should try merge vma again
+ * as we may succeed this time.
+ */
+ if (unlikely(vm_flags != vma->vm_flags && prev)) {
+ merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
+ NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
+ if (merge) {
+ fput(file);
+ vm_area_free(vma);
+ vma = merge;
+ /* Update vm_flags and possible addr to pick up the change. We don't
+ * warn here if addr changed as the vma is not linked by vma_link().
+ */
+ addr = vma->vm_start;
+ vm_flags = vma->vm_flags;
+ goto unmap_writable;
+ }
+ }
+
/* Can addr have changed??
*
* Answer: Yes, several device drivers can do it in their
@@ -1795,6 +1814,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
vma_link(mm, vma, prev, rb_link, rb_parent);
/* Once vma denies write, undo our temporary denial count */
if (file) {
+unmap_writable:
if (vm_flags & VM_SHARED)
mapping_unmap_writable(file->f_mapping);
if (vm_flags & VM_DENYWRITE)
--
2.19.1
^ permalink raw reply related
* [linux-nvme:nvme-5.9] BUILD SUCCESS 84c2c94f1adc59eaed24554666f755bcdd0140e8
From: kernel test robot @ 2020-07-17 2:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-nvme
tree/branch: git://git.infradead.org/nvme.git nvme-5.9
branch HEAD: 84c2c94f1adc59eaed24554666f755bcdd0140e8 drivers/nvme: add support for ACPI StorageD3Enable property
elapsed time: 722m
configs tested: 74
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [linux-nvme:nvme-5.8] BUILD SUCCESS 05b29021fba5e725dd385151ef00b6340229b500
From: kernel test robot @ 2020-07-17 2:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-nvme
tree/branch: git://git.infradead.org/nvme.git nvme-5.8
branch HEAD: 05b29021fba5e725dd385151ef00b6340229b500 nvme: explicitly update mpath disk capacity on revalidation
elapsed time: 722m
configs tested: 92
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200716
i386 randconfig-a005-20200716
i386 randconfig-a002-20200716
i386 randconfig-a006-20200716
i386 randconfig-a003-20200716
i386 randconfig-a004-20200716
x86_64 randconfig-a012-20200716
x86_64 randconfig-a011-20200716
x86_64 randconfig-a016-20200716
x86_64 randconfig-a014-20200716
x86_64 randconfig-a013-20200716
x86_64 randconfig-a015-20200716
i386 randconfig-a016-20200716
i386 randconfig-a011-20200716
i386 randconfig-a015-20200716
i386 randconfig-a012-20200716
i386 randconfig-a013-20200716
i386 randconfig-a014-20200716
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH] bcmgenet: fix DMA buffer management
From: Jason Wessel @ 2020-07-17 2:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <c3510a60-f064-af67-f7c3-d51ed96a211e@windriver.com>
On 7/16/20 11:02 AM, Jason Wessel wrote:
>
>
> On 7/16/20 7:02 AM, Jason Wessel wrote:
>> On 7/9/20 3:11 AM, etienne.duble at gmail.com wrote:
>>> From: Etienne Dubl? <etienne.duble@imag.fr>
>>>
>>> This commit fixes a serious issue occuring when several network
>>> commands are run on a raspberry pi 4 board: for instance a "dhcp"
>>> command and then one or several "tftp" commands. In this case,
>>> packet recv callbacks were called several times on the same packets,
>>> and send function was failing most of the time.
>>>
>>> note: if the boot procedure is made of a single network
>>> command, the issue is not visible.
>>>
>>> The issue is related to management of the packet ring buffers
>>> (producer / consumer) and DMA.
>>> Each time a packet is received, the ethernet device stores it
>>> in the buffer and increments an index called RDMA_PROD_INDEX.
>>> Each time the driver outputs a received packet, it increments
>>> another index called RDMA_CONS_INDEX.
>>>
>>> Between each pair of network commands, as part of the driver
>>> 'start' function, previous code tried to reset both RDMA_CONS_INDEX
>>> and RDMA_PROD_INDEX to 0. But RDMA_PROD_INDEX cannot be written from
>>> driver side, thus its value was actually not updated, and only
>>> RDMA_CONS_INDEX was reset to 0. This was resulting in a major
>>> synchronization issue between the driver and the device. Most
>>> visible bahavior was that the driver seemed to receive again the
>>> packets from the previous commands (e.g. DHCP response packets
>>> "received" again when performing the first TFTP command).
>>>
>>> This fix consists in setting RDMA_CONS_INDEX to the same
>>> value as RDMA_PROD_INDEX, when resetting the driver.
>>>
>>> The same kind of fix was needed on the TX side, and a few variables
>>> had to be reset accordingly (c_index, tx_index, rx_index).
>>
>>
>> While there is some kind of problem with the driver, because I too
>> have observed a problem with multiple requests timing out or failing,
>> this patch makes the problem much worse. I was only able to complete
>> a single tftp request.
>>
>> In my case I am using a static IP address and serverip.
>>
>> Also your patch was missing the sign-off line. Please consider
>> running your patches through scripts/checkpatch.pl.
>>
>> Cheers,
>> Jason.
>>
>>> ---
>>> drivers/net/bcmgenet.c | 15 +++++++--------
>>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
>>> index 11b6148ab6..a4facfd63f 100644
>>> --- a/drivers/net/bcmgenet.c
>>> +++ b/drivers/net/bcmgenet.c
>>> @@ -378,8 +378,6 @@ static void rx_descs_init(struct bcmgenet_eth_priv *priv)
>>> u32 len_stat, i;
>>> void *desc_base = priv->rx_desc_base;
>>>
>>> - priv->c_index = 0;
>>> -
>>> len_stat = (RX_BUF_LENGTH << DMA_BUFLENGTH_SHIFT) | DMA_OWN;
>>>
>>> for (i = 0; i < RX_DESCS; i++) {
>>> @@ -403,8 +401,10 @@ static void rx_ring_init(struct bcmgenet_eth_priv *priv)
>>> writel(RX_DESCS * DMA_DESC_SIZE / 4 - 1,
>>> priv->mac_reg + RDMA_RING_REG_BASE + DMA_END_ADDR);
>>>
>>> - writel(0x0, priv->mac_reg + RDMA_PROD_INDEX);
>>> - writel(0x0, priv->mac_reg + RDMA_CONS_INDEX);
>>> + /* cannot init RDMA_PROD_INDEX to 0, so align RDMA_CONS_INDEX on it instead */
>>> + priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
>>> + writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
>>> + priv->rx_index = priv->c_index;
>
>
> printf("before RX_IDX: 0x%x\n", priv->rx_index);
>
> I added a printf() like above for the RX and TX to see what is going on when
> I try and transfer a kernel Image file the second time.
>
>
> U-Boot> tftp ${loadaddr} bootfs/Image
> before RX_IDX: 0x0
> before TX_IDX: 0x0
> Using ethernet at 7d580000 device
> Filename 'bootfs/Image'.
> Load address: 0x80000
> Loading: ## Warning: gatewayip needed but not set
> ################################################## 16.8 MiB
> 6.1 MiB/s
> done
> Bytes transferred = 17615360 (10cca00 hex)
> U-Boot> tftp ${loadaddr} bootfs/Image
> before RX_IDX: 0xe4
> before TX_IDX: 0x2ee3
> Using ethernet at 7d580000 device
> Filename 'bootfs/Image'.
> Load address: 0x80000
> Loading: ## Warning: gatewayip needed but not set
>
>
>
> The TX_IDX is now 0x2ee3 which is definitely not going to work.
>
> According to the driver file there are only 256 (0xFF) slots,
> which is why it hangs, with your change.
>
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index a4facfd63f..1b7e7ba2bf 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -405,6 +405,7 @@ static void rx_ring_init(struct bcmgenet_eth_priv *priv)
priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
priv->rx_index = priv->c_index;
+ priv->rx_index &= 0xFF;
writel((RX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
priv->mac_reg + RDMA_RING_REG_BASE + DMA_RING_BUF_SIZE);
writel(DMA_FC_THRESH_VALUE, priv->mac_reg + RDMA_XON_XOFF_THRESH);
@@ -424,6 +425,7 @@ static void tx_ring_init(struct bcmgenet_eth_priv *priv)
/* cannot init TDMA_CONS_INDEX to 0, so align TDMA_PROD_INDEX on it instead */
priv->tx_index = readl(priv->mac_reg + TDMA_CONS_INDEX);
writel(priv->tx_index, priv->mac_reg + TDMA_PROD_INDEX);
+ priv->tx_index &= 0xFF;
writel(0x1, priv->mac_reg + TDMA_RING_REG_BASE + DMA_MBUF_DONE_THRESH);
writel(0x0, priv->mac_reg + TDMA_FLOW_PERIOD);
writel((TX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
After some testing it turns the lower 8 bits of the indexes will always match up with the DMA buffer index.
If you also apply the patch above the ethernet becomes reliable.
Jason.
>
>>> writel((RX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
>>> priv->mac_reg + RDMA_RING_REG_BASE + DMA_RING_BUF_SIZE);
>>> writel(DMA_FC_THRESH_VALUE, priv->mac_reg + RDMA_XON_XOFF_THRESH);
>>> @@ -421,8 +421,9 @@ static void tx_ring_init(struct bcmgenet_eth_priv *priv)
>>> writel(0x0, priv->mac_reg + TDMA_WRITE_PTR);
>>> writel(TX_DESCS * DMA_DESC_SIZE / 4 - 1,
>>> priv->mac_reg + TDMA_RING_REG_BASE + DMA_END_ADDR);
>>> - writel(0x0, priv->mac_reg + TDMA_PROD_INDEX);
>>> - writel(0x0, priv->mac_reg + TDMA_CONS_INDEX);
>>> + /* cannot init TDMA_CONS_INDEX to 0, so align TDMA_PROD_INDEX on it instead */
>>> + priv->tx_index = readl(priv->mac_reg + TDMA_CONS_INDEX);
>>> + writel(priv->tx_index, priv->mac_reg + TDMA_PROD_INDEX);
>>> writel(0x1, priv->mac_reg + TDMA_RING_REG_BASE + DMA_MBUF_DONE_THRESH);
>>> writel(0x0, priv->mac_reg + TDMA_FLOW_PERIOD);
>>> writel((TX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
>>> @@ -469,8 +470,6 @@ static int bcmgenet_gmac_eth_start(struct udevice *dev)
>>>
>>> priv->tx_desc_base = priv->mac_reg + GENET_TX_OFF;
>>> priv->rx_desc_base = priv->mac_reg + GENET_RX_OFF;
>>> - priv->tx_index = 0x0;
>>> - priv->rx_index = 0x0;
>>>
>>> bcmgenet_umac_reset(priv);
>>>
>>>
^ permalink raw reply related
* [PATCH v2] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros
From: Saravana Kannan @ 2020-07-17 2:44 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger
Cc: CC Hwang, Saravana Kannan, Hanks Chen, Loda Chou, linux-kernel,
John Stultz, linux-mediatek, kernel-team, linux-arm-kernel
Compiling an irqchip driver as a platform driver needs to bunch of
things to be done right:
- Making sure the parent domain is initialized first
- Making sure the device can't be unbound from sysfs
- Disallowing module unload if it's built as a module
- Finding the parent node
- Etc.
Instead of trying to make sure all future irqchip platform drivers get
this right, provide boilerplate macros that take care of all of this.
An example use would look something like this. Where acme_foo_init and
acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE.
IRQCHIP_PLATFORM_DRIVER_BEGIN
IRQCHIP_MATCH(foo, "acme,foo", acme_foo_init)
IRQCHIP_MATCH(bar, "acme,bar", acme_bar_init)
IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/irqchip/irqchip.c | 22 ++++++++++++++++++++++
include/linux/irqchip.h | 23 +++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index 2b35e68bea82..236ea793f01c 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -10,8 +10,10 @@
#include <linux/acpi.h>
#include <linux/init.h>
+#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/irqchip.h>
+#include <linux/platform_device.h>
/*
* This special of_device_id is the sentinel at the end of the
@@ -29,3 +31,23 @@ void __init irqchip_init(void)
of_irq_init(__irqchip_of_table);
acpi_probe_device_table(irqchip);
}
+
+int platform_irqchip_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *par_np = of_irq_find_parent(np);
+ of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev);
+
+ if (!irq_init_cb)
+ return -EINVAL;
+
+ if (par_np == np)
+ par_np = NULL;
+
+ /* If there's a parent irqchip, make sure it has been initialized. */
+ if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY))
+ return -EPROBE_DEFER;
+
+ return irq_init_cb(np, par_np);
+}
+EXPORT_SYMBOL_GPL(platform_irqchip_probe);
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
index 950e4b2458f0..6d5eba7cbbb7 100644
--- a/include/linux/irqchip.h
+++ b/include/linux/irqchip.h
@@ -13,6 +13,7 @@
#include <linux/acpi.h>
#include <linux/of.h>
+#include <linux/platform_device.h>
/*
* This macro must be used by the different irqchip drivers to declare
@@ -26,6 +27,28 @@
*/
#define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn)
+extern int platform_irqchip_probe(struct platform_device *pdev);
+
+#define IRQCHIP_PLATFORM_DRIVER_BEGIN \
+static const struct of_device_id __irqchip_match_table[] = {
+
+#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn },
+
+#define IRQCHIP_PLATFORM_DRIVER_END(drv_name) \
+ {}, \
+}; \
+MODULE_DEVICE_TABLE(of, __irqchip_match_table); \
+static struct platform_driver drv_name##_driver = { \
+ .probe = platform_irqchip_probe, \
+ .driver = { \
+ .name = #drv_name, \
+ .owner = THIS_MODULE, \
+ .of_match_table = __irqchip_match_table,\
+ .suppress_bind_attrs = true, \
+ }, \
+}; \
+builtin_platform_driver(drv_name##_driver)
+
/*
* This macro must be used by the different irqchip drivers to declare
* the association between their version and their initialization function.
--
2.28.0.rc0.105.gf9edc3c819-goog
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH] ocfs2: fix remounting needed after setfacl command
From: Gang He @ 2020-07-17 2:37 UTC (permalink / raw)
To: mark, jlbec, joseph.qi; +Cc: Gang He, linux-kernel, ocfs2-devel, akpm
When use setfacl command to change a file's acl, the user cannot
get the latest acl information from the file via getfacl command,
until remounting the file system.
e.g.
setfacl -m u:ivan:rw /ocfs2/ivan
getfacl /ocfs2/ivan
getfacl: Removing leading '/' from absolute path names
file: ocfs2/ivan
owner: root
group: root
user::rw-
group::r--
mask::r--
other::r--
The latest acl record("u:ivan:rw") cannot be returned via getfacl
command until remounting.
Signed-off-by: Gang He <ghe@suse.com>
---
fs/ocfs2/acl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bb981ec76456..7b07f5df3a29 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -256,6 +256,8 @@ static int ocfs2_set_acl(handle_t *handle,
ret = ocfs2_xattr_set(inode, name_index, "", value, size, 0);
kfree(value);
+ if (!ret)
+ set_cached_acl(inode, type, acl);
return ret;
}
--
2.12.3
^ permalink raw reply related
* [PATCH v2] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros
From: Saravana Kannan @ 2020-07-17 2:44 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Matthias Brugger
Cc: Saravana Kannan, John Stultz, CC Hwang, Loda Chou, Hanks Chen,
kernel-team, linux-kernel, linux-arm-kernel, linux-mediatek
Compiling an irqchip driver as a platform driver needs to bunch of
things to be done right:
- Making sure the parent domain is initialized first
- Making sure the device can't be unbound from sysfs
- Disallowing module unload if it's built as a module
- Finding the parent node
- Etc.
Instead of trying to make sure all future irqchip platform drivers get
this right, provide boilerplate macros that take care of all of this.
An example use would look something like this. Where acme_foo_init and
acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE.
IRQCHIP_PLATFORM_DRIVER_BEGIN
IRQCHIP_MATCH(foo, "acme,foo", acme_foo_init)
IRQCHIP_MATCH(bar, "acme,bar", acme_bar_init)
IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/irqchip/irqchip.c | 22 ++++++++++++++++++++++
include/linux/irqchip.h | 23 +++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index 2b35e68bea82..236ea793f01c 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -10,8 +10,10 @@
#include <linux/acpi.h>
#include <linux/init.h>
+#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/irqchip.h>
+#include <linux/platform_device.h>
/*
* This special of_device_id is the sentinel at the end of the
@@ -29,3 +31,23 @@ void __init irqchip_init(void)
of_irq_init(__irqchip_of_table);
acpi_probe_device_table(irqchip);
}
+
+int platform_irqchip_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *par_np = of_irq_find_parent(np);
+ of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev);
+
+ if (!irq_init_cb)
+ return -EINVAL;
+
+ if (par_np == np)
+ par_np = NULL;
+
+ /* If there's a parent irqchip, make sure it has been initialized. */
+ if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY))
+ return -EPROBE_DEFER;
+
+ return irq_init_cb(np, par_np);
+}
+EXPORT_SYMBOL_GPL(platform_irqchip_probe);
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
index 950e4b2458f0..6d5eba7cbbb7 100644
--- a/include/linux/irqchip.h
+++ b/include/linux/irqchip.h
@@ -13,6 +13,7 @@
#include <linux/acpi.h>
#include <linux/of.h>
+#include <linux/platform_device.h>
/*
* This macro must be used by the different irqchip drivers to declare
@@ -26,6 +27,28 @@
*/
#define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, compat, fn)
+extern int platform_irqchip_probe(struct platform_device *pdev);
+
+#define IRQCHIP_PLATFORM_DRIVER_BEGIN \
+static const struct of_device_id __irqchip_match_table[] = {
+
+#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn },
+
+#define IRQCHIP_PLATFORM_DRIVER_END(drv_name) \
+ {}, \
+}; \
+MODULE_DEVICE_TABLE(of, __irqchip_match_table); \
+static struct platform_driver drv_name##_driver = { \
+ .probe = platform_irqchip_probe, \
+ .driver = { \
+ .name = #drv_name, \
+ .owner = THIS_MODULE, \
+ .of_match_table = __irqchip_match_table,\
+ .suppress_bind_attrs = true, \
+ }, \
+}; \
+builtin_platform_driver(drv_name##_driver)
+
/*
* This macro must be used by the different irqchip drivers to declare
* the association between their version and their initialization function.
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.