* Re: [PATCH 2/4] drm/i915/ttm: only fault WILLNEED objects
From: Thomas Hellström @ 2022-01-05 15:09 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <20220105145835.142950-2-matthew.auld@intel.com>
On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> Don't attempt to fault and re-populate purged objects. By some fluke
> this passes the dontneed-after-mmap IGT, but for the wrong reasons.
>
> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 923cc7ad8d70..8d61d4538a64 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -883,6 +883,11 @@ static vm_fault_t vm_fault_ttm(struct vm_fault
> *vmf)
> if (ret)
> return ret;
>
> + if (obj->mm.madv != I915_MADV_WILLNEED) {
> + dma_resv_unlock(bo->base.resv);
> + return VM_FAULT_SIGBUS;
> + }
> +
> if (drm_dev_enter(dev, &idx)) {
> ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma-
> >vm_page_prot,
>
> TTM_BO_VM_NUM_PREFAULT);
^ permalink raw reply
* [PATCH v3 15/16] job.c: enable job lock/unlock and remove Aiocontext locks
From: Emanuele Giuseppe Esposito @ 2022-01-05 14:02 UTC (permalink / raw)
To: qemu-block
Cc: Kevin Wolf, Fam Zheng, Vladimir Sementsov-Ogievskiy, Wen Congyang,
Xie Changlong, Emanuele Giuseppe Esposito, Markus Armbruster,
qemu-devel, Hanna Reitz, Stefan Hajnoczi, Paolo Bonzini,
John Snow
In-Reply-To: <20220105140208.365608-1-eesposit@redhat.com>
Change the job_{lock/unlock} and macros to use job_mutex.
Now that they are not nop anymore, remove the aiocontext
to avoid deadlocks.
Therefore:
- when possible, remove completely the aiocontext lock/unlock pair
- if it is used by some other functions too, reduce the locking
section as much as possible, leaving the job API outside.
There is only one JobDriver callback, ->free() that assumes that
the aiocontext lock is held (because it calls bdrv_unref), so for
now keep that under aiocontext lock.
Also remove real_job_{lock/unlock}, as they are replaced by the
public functions.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
---
blockdev.c | 65 ++++-----------------------
include/qemu/job.h | 11 +----
job-qmp.c | 41 ++++-------------
job.c | 76 +++-----------------------------
tests/unit/test-bdrv-drain.c | 4 +-
tests/unit/test-block-iothread.c | 2 +-
tests/unit/test-blockjob.c | 13 ++----
7 files changed, 31 insertions(+), 181 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 1fbd9b9e04..ebc14daa86 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -159,12 +159,7 @@ void blockdev_mark_auto_del(BlockBackend *blk)
for (job = block_job_next(NULL); job; job = block_job_next(job)) {
if (block_job_has_bdrv(job, blk_bs(blk))) {
- AioContext *aio_context = job->job.aio_context;
- aio_context_acquire(aio_context);
-
job_cancel_locked(&job->job, false);
-
- aio_context_release(aio_context);
}
}
@@ -1829,16 +1824,9 @@ static void drive_backup_abort(BlkActionState *common)
DriveBackupState *state = DO_UPCAST(DriveBackupState, common, common);
if (state->job) {
- AioContext *aio_context;
-
- aio_context = bdrv_get_aio_context(state->bs);
- aio_context_acquire(aio_context);
-
WITH_JOB_LOCK_GUARD() {
job_cancel_sync_locked(&state->job->job, true);
}
-
- aio_context_release(aio_context);
}
}
@@ -1932,16 +1920,9 @@ static void blockdev_backup_abort(BlkActionState *common)
BlockdevBackupState *state = DO_UPCAST(BlockdevBackupState, common, common);
if (state->job) {
- AioContext *aio_context;
-
- aio_context = bdrv_get_aio_context(state->bs);
- aio_context_acquire(aio_context);
-
WITH_JOB_LOCK_GUARD() {
job_cancel_sync_locked(&state->job->job, true);
}
-
- aio_context_release(aio_context);
}
}
@@ -3305,18 +3286,13 @@ out:
aio_context_release(aio_context);
}
-/*
- * Get a block job using its ID and acquire its AioContext.
- * Returns with job_lock held on success.
- */
-static BlockJob *find_block_job(const char *id, AioContext **aio_context,
- Error **errp)
+/* Get a block job using its ID. Returns with job_lock held on success */
+static BlockJob *find_block_job(const char *id, Error **errp)
{
BlockJob *job;
assert(id != NULL);
- *aio_context = NULL;
job_lock();
job = block_job_get(id);
@@ -3328,31 +3304,25 @@ static BlockJob *find_block_job(const char *id, AioContext **aio_context,
return NULL;
}
- *aio_context = blk_get_aio_context(job->blk);
- aio_context_acquire(*aio_context);
-
return job;
}
void qmp_block_job_set_speed(const char *device, int64_t speed, Error **errp)
{
- AioContext *aio_context;
- BlockJob *job = find_block_job(device, &aio_context, errp);
+ BlockJob *job = find_block_job(device, errp);
if (!job) {
return;
}
block_job_set_speed(job, speed, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_block_job_cancel(const char *device,
bool has_force, bool force, Error **errp)
{
- AioContext *aio_context;
- BlockJob *job = find_block_job(device, &aio_context, errp);
+ BlockJob *job = find_block_job(device, errp);
if (!job) {
return;
@@ -3371,14 +3341,12 @@ void qmp_block_job_cancel(const char *device,
trace_qmp_block_job_cancel(job);
job_user_cancel_locked(&job->job, force, errp);
out:
- aio_context_release(aio_context);
job_unlock();
}
void qmp_block_job_pause(const char *device, Error **errp)
{
- AioContext *aio_context;
- BlockJob *job = find_block_job(device, &aio_context, errp);
+ BlockJob *job = find_block_job(device, errp);
if (!job) {
return;
@@ -3386,14 +3354,12 @@ void qmp_block_job_pause(const char *device, Error **errp)
trace_qmp_block_job_pause(job);
job_user_pause_locked(&job->job, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_block_job_resume(const char *device, Error **errp)
{
- AioContext *aio_context;
- BlockJob *job = find_block_job(device, &aio_context, errp);
+ BlockJob *job = find_block_job(device, errp);
if (!job) {
return;
@@ -3401,14 +3367,12 @@ void qmp_block_job_resume(const char *device, Error **errp)
trace_qmp_block_job_resume(job);
job_user_resume_locked(&job->job, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_block_job_complete(const char *device, Error **errp)
{
- AioContext *aio_context;
- BlockJob *job = find_block_job(device, &aio_context, errp);
+ BlockJob *job = find_block_job(device, errp);
if (!job) {
return;
@@ -3416,14 +3380,12 @@ void qmp_block_job_complete(const char *device, Error **errp)
trace_qmp_block_job_complete(job);
job_complete_locked(&job->job, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_block_job_finalize(const char *id, Error **errp)
{
- AioContext *aio_context;
- BlockJob *job = find_block_job(id, &aio_context, errp);
+ BlockJob *job = find_block_job(id, errp);
if (!job) {
return;
@@ -3433,21 +3395,13 @@ void qmp_block_job_finalize(const char *id, Error **errp)
job_ref_locked(&job->job);
job_finalize_locked(&job->job, errp);
- /*
- * Job's context might have changed via job_finalize_locked
- * (and job_txn_apply automatically acquires the new one),
- * so make sure we release the correct one.
- */
- aio_context = blk_get_aio_context(job->blk);
job_unref_locked(&job->job);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_block_job_dismiss(const char *id, Error **errp)
{
- AioContext *aio_context;
- BlockJob *bjob = find_block_job(id, &aio_context, errp);
+ BlockJob *bjob = find_block_job(id, errp);
Job *job;
if (!bjob) {
@@ -3457,7 +3411,6 @@ void qmp_block_job_dismiss(const char *id, Error **errp)
trace_qmp_block_job_dismiss(bjob);
job = &bjob->job;
job_dismiss_locked(&job, errp);
- aio_context_release(aio_context);
job_unlock();
}
diff --git a/include/qemu/job.h b/include/qemu/job.h
index c95f9fa8d1..602ee56ae6 100644
--- a/include/qemu/job.h
+++ b/include/qemu/job.h
@@ -326,9 +326,9 @@ typedef enum JobCreateFlags {
extern QemuMutex job_mutex;
-#define JOB_LOCK_GUARD() /* QEMU_LOCK_GUARD(&job_mutex) */
+#define JOB_LOCK_GUARD() QEMU_LOCK_GUARD(&job_mutex)
-#define WITH_JOB_LOCK_GUARD() /* WITH_QEMU_LOCK_GUARD(&job_mutex) */
+#define WITH_JOB_LOCK_GUARD() WITH_QEMU_LOCK_GUARD(&job_mutex)
/**
* job_lock:
@@ -667,8 +667,6 @@ void job_user_cancel_locked(Job *job, bool force, Error **errp);
*
* Returns the return value from the job if the job actually completed
* during the call, or -ECANCELED if it was canceled.
- *
- * Callers must hold the AioContext lock of job->aio_context.
*/
int job_cancel_sync_locked(Job *job, bool force);
@@ -692,9 +690,6 @@ void job_cancel_sync_all(void);
* function).
*
* Returns the return value from the job.
- *
- * Callers must hold the AioContext lock of job->aio_context.
- *
* Called between job_lock and job_unlock.
*/
int job_complete_sync_locked(Job *job, Error **errp);
@@ -726,8 +721,6 @@ void job_dismiss_locked(Job **job, Error **errp);
* Returns 0 if the job is successfully completed, -ECANCELED if the job was
* cancelled before completing, and -errno in other error cases.
*
- * Callers must hold the AioContext lock of job->aio_context.
- *
* Called between job_lock and job_unlock.
*/
int job_finish_sync_locked(Job *job, void (*finish)(Job *, Error **errp),
diff --git a/job-qmp.c b/job-qmp.c
index 615e056fc4..858b3a28f5 100644
--- a/job-qmp.c
+++ b/job-qmp.c
@@ -29,15 +29,11 @@
#include "qapi/error.h"
#include "trace/trace-root.h"
-/*
- * Get a block job using its ID and acquire its AioContext.
- * Returns with job_lock held on success.
- */
-static Job *find_job(const char *id, AioContext **aio_context, Error **errp)
+/* Get a job using its ID. Returns with job_lock held on success. */
+static Job *find_job(const char *id, Error **errp)
{
Job *job;
- *aio_context = NULL;
job_lock();
job = job_get_locked(id);
@@ -47,16 +43,12 @@ static Job *find_job(const char *id, AioContext **aio_context, Error **errp)
return NULL;
}
- *aio_context = job->aio_context;
- aio_context_acquire(*aio_context);
-
return job;
}
void qmp_job_cancel(const char *id, Error **errp)
{
- AioContext *aio_context;
- Job *job = find_job(id, &aio_context, errp);
+ Job *job = find_job(id, errp);
if (!job) {
return;
@@ -64,14 +56,12 @@ void qmp_job_cancel(const char *id, Error **errp)
trace_qmp_job_cancel(job);
job_user_cancel_locked(job, true, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_job_pause(const char *id, Error **errp)
{
- AioContext *aio_context;
- Job *job = find_job(id, &aio_context, errp);
+ Job *job = find_job(id, errp);
if (!job) {
return;
@@ -79,14 +69,12 @@ void qmp_job_pause(const char *id, Error **errp)
trace_qmp_job_pause(job);
job_user_pause_locked(job, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_job_resume(const char *id, Error **errp)
{
- AioContext *aio_context;
- Job *job = find_job(id, &aio_context, errp);
+ Job *job = find_job(id, errp);
if (!job) {
return;
@@ -94,14 +82,12 @@ void qmp_job_resume(const char *id, Error **errp)
trace_qmp_job_resume(job);
job_user_resume_locked(job, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_job_complete(const char *id, Error **errp)
{
- AioContext *aio_context;
- Job *job = find_job(id, &aio_context, errp);
+ Job *job = find_job(id, errp);
if (!job) {
return;
@@ -109,14 +95,12 @@ void qmp_job_complete(const char *id, Error **errp)
trace_qmp_job_complete(job);
job_complete_locked(job, errp);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_job_finalize(const char *id, Error **errp)
{
- AioContext *aio_context;
- Job *job = find_job(id, &aio_context, errp);
+ Job *job = find_job(id, errp);
if (!job) {
return;
@@ -126,21 +110,13 @@ void qmp_job_finalize(const char *id, Error **errp)
job_ref_locked(job);
job_finalize_locked(job, errp);
- /*
- * Job's context might have changed via job_finalize_locked
- * (and job_txn_apply automatically acquires the new one),
- * so make sure we release the correct one.
- */
- aio_context = job->aio_context;
job_unref_locked(job);
- aio_context_release(aio_context);
job_unlock();
}
void qmp_job_dismiss(const char *id, Error **errp)
{
- AioContext *aio_context;
- Job *job = find_job(id, &aio_context, errp);
+ Job *job = find_job(id, errp);
if (!job) {
return;
@@ -148,7 +124,6 @@ void qmp_job_dismiss(const char *id, Error **errp)
trace_qmp_job_dismiss(job);
job_dismiss_locked(&job, errp);
- aio_context_release(aio_context);
job_unlock();
}
diff --git a/job.c b/job.c
index 8a5b710d9b..9fa0f34565 100644
--- a/job.c
+++ b/job.c
@@ -98,21 +98,11 @@ struct JobTxn {
};
void job_lock(void)
-{
- /* nop */
-}
-
-void job_unlock(void)
-{
- /* nop */
-}
-
-static void real_job_lock(void)
{
qemu_mutex_lock(&job_mutex);
}
-static void real_job_unlock(void)
+void job_unlock(void)
{
qemu_mutex_unlock(&job_mutex);
}
@@ -180,7 +170,6 @@ static int job_txn_apply_locked(Job *job, int fn(Job *))
* twice - which would break AIO_WAIT_WHILE from within fn.
*/
job_ref_locked(job);
- aio_context_release(job->aio_context);
QLIST_FOREACH_SAFE(other_job, &txn->jobs, txn_list, next) {
rc = fn(other_job);
@@ -189,11 +178,6 @@ static int job_txn_apply_locked(Job *job, int fn(Job *))
}
}
- /*
- * Note that job->aio_context might have been changed by calling fn, so we
- * can't use a local variable to cache it.
- */
- aio_context_acquire(job->aio_context);
job_unref_locked(job);
return rc;
}
@@ -477,7 +461,10 @@ void job_unref_locked(Job *job)
if (job->driver->free) {
job_unlock();
+ /* FIXME: aiocontext lock is required because cb calls blk_unref */
+ aio_context_acquire(job_get_aio_context(job));
job->driver->free(job);
+ aio_context_release(job_get_aio_context(job));
job_lock();
}
@@ -550,21 +537,17 @@ void job_enter_cond_locked(Job *job, bool(*fn)(Job *job))
return;
}
- real_job_lock();
if (job->busy) {
- real_job_unlock();
return;
}
if (fn && !fn(job)) {
- real_job_unlock();
return;
}
assert(!job->deferred_to_main_loop);
timer_del(&job->sleep_timer);
job->busy = true;
- real_job_unlock();
job_unlock();
aio_co_enter(job_get_aio_context(job), job->co);
job_lock();
@@ -587,13 +570,11 @@ void job_enter(Job *job)
*/
static void coroutine_fn job_do_yield_locked(Job *job, uint64_t ns)
{
- real_job_lock();
if (ns != -1) {
timer_mod(&job->sleep_timer, ns);
}
job->busy = false;
job_event_idle_locked(job);
- real_job_unlock();
job_unlock();
qemu_coroutine_yield();
job_lock();
@@ -922,7 +903,6 @@ static void job_cancel_async_locked(Job *job, bool force)
/* Called with job_mutex held. */
static void job_completed_txn_abort_locked(Job *job)
{
- AioContext *ctx;
JobTxn *txn = job->txn;
Job *other_job;
@@ -935,54 +915,28 @@ static void job_completed_txn_abort_locked(Job *job)
txn->aborting = true;
job_txn_ref_locked(txn);
- /*
- * We can only hold the single job's AioContext lock while calling
- * job_finalize_single_locked() because the finalization callbacks can
- * involve calls of AIO_WAIT_WHILE(), which could deadlock otherwise.
- * Note that the job's AioContext may change when it is finalized.
- */
- job_ref_locked(job);
- aio_context_release(job->aio_context);
-
/* Other jobs are effectively cancelled by us, set the status for
* them; this job, however, may or may not be cancelled, depending
* on the caller, so leave it. */
QLIST_FOREACH(other_job, &txn->jobs, txn_list) {
if (other_job != job) {
- ctx = other_job->aio_context;
- aio_context_acquire(ctx);
/*
* This is a transaction: If one job failed, no result will matter.
* Therefore, pass force=true to terminate all other jobs as
* quickly as possible.
*/
job_cancel_async_locked(other_job, true);
- aio_context_release(ctx);
}
}
while (!QLIST_EMPTY(&txn->jobs)) {
other_job = QLIST_FIRST(&txn->jobs);
- /*
- * The job's AioContext may change, so store it in @ctx so we
- * release the same context that we have acquired before.
- */
- ctx = other_job->aio_context;
- aio_context_acquire(ctx);
if (!job_is_completed_locked(other_job)) {
assert(job_cancel_requested_locked(other_job));
job_finish_sync_locked(other_job, NULL, NULL);
}
job_finalize_single_locked(other_job);
- aio_context_release(ctx);
}
- /*
- * Use job_ref_locked()/job_unref_locked() so we can read the AioContext
- * here even if the job went away during job_finalize_single_locked().
- */
- aio_context_acquire(job->aio_context);
- job_unref_locked(job);
-
job_txn_unref_locked(txn);
}
@@ -1101,11 +1055,7 @@ static void job_completed_locked(Job *job)
static void job_exit(void *opaque)
{
Job *job = (Job *)opaque;
- AioContext *ctx;
-
JOB_LOCK_GUARD();
- job_ref_locked(job);
- aio_context_acquire(job->aio_context);
/* This is a lie, we're not quiescent, but still doing the completion
* callbacks. However, completion callbacks tend to involve operations that
@@ -1115,16 +1065,6 @@ static void job_exit(void *opaque)
job_event_idle_locked(job);
job_completed_locked(job);
-
- /*
- * Note that calling job_completed_locked can move the job to a different
- * aio_context, so we cannot cache from above. job_txn_apply_locked takes
- * care of acquiring the new lock, and we ref/unref to avoid
- * job_completed_locked freeing the job underneath us.
- */
- ctx = job->aio_context;
- job_unref_locked(job);
- aio_context_release(ctx);
}
/**
@@ -1249,14 +1189,10 @@ int job_cancel_sync_locked(Job *job, bool force)
void job_cancel_sync_all(void)
{
Job *job;
- AioContext *aio_context;
JOB_LOCK_GUARD();
while ((job = job_next_locked(NULL))) {
- aio_context = job->aio_context;
- aio_context_acquire(aio_context);
job_cancel_sync_locked(job, true);
- aio_context_release(aio_context);
}
}
@@ -1302,8 +1238,8 @@ int job_finish_sync_locked(Job *job, void (*finish)(Job *, Error **errp),
}
job_unlock();
- AIO_WAIT_WHILE(job_get_aio_context(job),
- (job_enter(job), !job_is_completed(job)));
+ AIO_WAIT_WHILE_UNLOCKED(job_get_aio_context(job),
+ (job_enter(job), !job_is_completed(job)));
job_lock();
ret = (job_is_cancelled_locked(job) && job->ret == 0) ?
diff --git a/tests/unit/test-bdrv-drain.c b/tests/unit/test-bdrv-drain.c
index c03560e63d..dae207e24e 100644
--- a/tests/unit/test-bdrv-drain.c
+++ b/tests/unit/test-bdrv-drain.c
@@ -928,9 +928,9 @@ static void test_blockjob_common_drain_node(enum drain_type drain_type,
tjob->prepare_ret = -EIO;
break;
}
+ aio_context_release(ctx);
job_start(&job->job);
- aio_context_release(ctx);
if (use_iothread) {
/* job_co_entry() is run in the I/O thread, wait for the actual job
@@ -994,12 +994,12 @@ static void test_blockjob_common_drain_node(enum drain_type drain_type,
g_assert_false(job_get_paused(&job->job));
g_assert_true(job_get_busy(&job->job)); /* We're in qemu_co_sleep_ns() */
- aio_context_acquire(ctx);
job_lock();
ret = job_complete_sync_locked(&job->job, &error_abort);
job_unlock();
g_assert_cmpint(ret, ==, (result == TEST_JOB_SUCCESS ? 0 : -EIO));
+ aio_context_acquire(ctx);
if (use_iothread) {
blk_set_aio_context(blk_src, qemu_get_aio_context(), &error_abort);
assert(blk_get_aio_context(blk_target) == qemu_get_aio_context());
diff --git a/tests/unit/test-block-iothread.c b/tests/unit/test-block-iothread.c
index addcb5846b..e09e440342 100644
--- a/tests/unit/test-block-iothread.c
+++ b/tests/unit/test-block-iothread.c
@@ -455,10 +455,10 @@ static void test_attach_blockjob(void)
aio_poll(qemu_get_aio_context(), false);
}
- aio_context_acquire(ctx);
job_lock();
job_complete_sync_locked(&tjob->common.job, &error_abort);
job_unlock();
+ aio_context_acquire(ctx);
blk_set_aio_context(blk, qemu_get_aio_context(), &error_abort);
aio_context_release(ctx);
diff --git a/tests/unit/test-blockjob.c b/tests/unit/test-blockjob.c
index ec9128dbb5..c926db7b5d 100644
--- a/tests/unit/test-blockjob.c
+++ b/tests/unit/test-blockjob.c
@@ -228,10 +228,6 @@ static void cancel_common(CancelJob *s)
BlockJob *job = &s->common;
BlockBackend *blk = s->blk;
JobStatus sts = job->job.status;
- AioContext *ctx;
-
- ctx = job->job.aio_context;
- aio_context_acquire(ctx);
job_lock();
job_cancel_sync_locked(&job->job, true);
@@ -244,7 +240,6 @@ static void cancel_common(CancelJob *s)
job_unlock();
destroy_blk(blk);
- aio_context_release(ctx);
}
static void test_cancel_created(void)
@@ -381,11 +376,9 @@ static void test_cancel_concluded(void)
aio_poll(qemu_get_aio_context(), true);
assert(job_get_status(job) == JOB_STATUS_PENDING);
- aio_context_acquire(job->aio_context);
job_lock();
job_finalize_locked(job, &error_abort);
job_unlock();
- aio_context_release(job->aio_context);
assert(job_get_status(job) == JOB_STATUS_CONCLUDED);
cancel_common(s);
@@ -478,9 +471,7 @@ static void test_complete_in_standby(void)
/* Wait for the job to become READY */
job_start(job);
- aio_context_acquire(ctx);
- AIO_WAIT_WHILE(ctx, job_get_status(job) != JOB_STATUS_READY);
- aio_context_release(ctx);
+ AIO_WAIT_WHILE_UNLOCKED(ctx, job_get_status(job) != JOB_STATUS_READY);
/* Begin the drained section, pausing the job */
bdrv_drain_all_begin();
@@ -498,6 +489,7 @@ static void test_complete_in_standby(void)
job_complete_locked(job, &error_abort);
/* The test is done now, clean up. */
+ aio_context_release(ctx);
job_finish_sync_locked(job, NULL, &error_abort);
assert(job->status == JOB_STATUS_PENDING);
@@ -507,6 +499,7 @@ static void test_complete_in_standby(void)
job_dismiss_locked(&job, &error_abort);
job_unlock();
+ aio_context_acquire(ctx);
destroy_blk(blk);
aio_context_release(ctx);
iothread_join(iothread);
--
2.31.1
^ permalink raw reply related
* QEMU issue on Windows with WHPX Acceleration
From: Sam Williams @ 2022-01-05 13:43 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
See reddit post:
https://www.reddit.com/r/VFIO/comments/l9bl8b/anyone_able_to_run_qemu_52_git_master_on_windows/
This is all the info I have on this, it's all in the reddit post.
[-- Attachment #2: Type: text/html, Size: 355 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] y2038: cond_wait_prologue64 and related fixes
From: Bezdeka, Florian @ 2022-01-05 15:08 UTC (permalink / raw)
To: xenomai@xenomai.org, jan.kiszka@siemens.com
In-Reply-To: <e5af2c61-57be-55c6-4c03-e9b4670fa5fb@siemens.com>
On Wed, 2022-01-05 at 15:58 +0100, Jan Kiszka wrote:
> On 05.01.22 15:56, Bezdeka, Florian (T CED SES-DE) wrote:
> > On Wed, 2022-01-05 at 15:43 +0100, Jan Kiszka wrote:
> > > On 05.01.22 15:06, Florian Bezdeka wrote:
> > > > Hi all,
> > > >
> > > > this is the last missing POSIX related y2038 affected syscall in
> > > > Xenomai. With this applied we have two Xenomai specific syscalls
> > > > missing:
> > > >
> > > > - sc_cobalt_thread_setschedparam_ex
> > > > - sc_cobalt_thread_getschedparam_ex
> > > >
> > > > While adding tests for the introduced cond_wait_prologue64 I hit a
> > > > kernel OOPS due to insuficient validation of user provided pointers.
> > > > That has been addressed as well.
> > >
> > > Thanks for both! Is it possibly to move the fixes the front? That would
> > > also ensure that I can easily pick them into stable.
> >
> > Yes. Patch 4 and 7 could be moved to the front easily. Do you want me
> > to split patch 2 into the y2038 and non y2038 part, or does that not
> > qualify for stable at all?
>
> Can I reorder things myself, or does patch 4 break (patch 7 does not,
> already checked)? Then I just change the application order while doing
> git am.
No breakage expected. The only "problematic" one would be patch 2 as it
touches y2038 as well as non-y2038 syscall definitions. Let me know if
I should split that into two parts (which would allow the non y2038
related cleanup to be applied to stable separately)
>
> Jan
>
^ permalink raw reply
* [PATCH v2] btrfs: Remove redundant assignment of slot and leaf
From: Jiapeng Chong @ 2022-01-05 15:07 UTC (permalink / raw)
To: clm; +Cc: josef, dsterba, linux-btrfs, linux-kernel, chongjiapeng,
Abaci Robot
From: chongjiapeng <jiapeng.chong@linux.alibaba.com>
slot and leaf are being initialized to path->slots[0] and
path->nodes[0], but this is never read as slot and leaf
is overwritten later on. Remove the redundant assignment.
Cleans up the following clang-analyzer warning:
fs/btrfs/tree-log.c:6125:7: warning: Value stored to 'slot' during its
initialization is never read [clang-analyzer-deadcode.DeadStores].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: chongjiapeng <jiapeng.chong@linux.alibaba.com>
---
Changes in v2:
-Remove redundant assignment of leaf.
fs/btrfs/tree-log.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 4b89ac769347..d99cda0acd95 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -6188,8 +6188,6 @@ static int log_new_ancestors(struct btrfs_trans_handle *trans,
if (ret < 0)
return ret;
- leaf = path->nodes[0];
- slot = path->slots[0];
if (slot >= btrfs_header_nritems(leaf)) {
ret = btrfs_next_leaf(root, path);
if (ret < 0)
--
2.19.1.6.gb485710b
^ permalink raw reply related
* [PATCH 10/11] PCI: mvebu: Implement support for legacy INTx interrupts
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Marc Zyngier
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
This adds support for legacy INTx interrupts received from other PCIe
devices and which are reported by a new INTx irq chip.
With this change, kernel can distinguish between INTA, INTB, INTC and INTD
interrupts.
Note that for this support, device tree files has to be properly adjusted
to provide "interrupts" or "interrupts-extended" property with intx
interrupt source, "interrupt-names" property with "intx" string and also
'interrupt-controller' subnode must be defined.
If device tree files do not provide these nodes then driver would work as
before.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 182 +++++++++++++++++++++++++++--
1 file changed, 174 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 1e90ab888075..04bcdd7b7a6d 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -54,9 +54,10 @@
PCIE_CONF_ADDR_EN)
#define PCIE_CONF_DATA_OFF 0x18fc
#define PCIE_INT_CAUSE_OFF 0x1900
+#define PCIE_INT_UNMASK_OFF 0x1910
+#define PCIE_INT_INTX(i) BIT(24+i)
#define PCIE_INT_PM_PME BIT(28)
-#define PCIE_MASK_OFF 0x1910
-#define PCIE_MASK_ENABLE_INTS 0x0f000000
+#define PCIE_INT_ALL_MASK GENMASK(31, 0)
#define PCIE_CTRL_OFF 0x1a00
#define PCIE_CTRL_X1_MODE 0x0001
#define PCIE_CTRL_RC_MODE BIT(1)
@@ -110,6 +111,10 @@ struct mvebu_pcie_port {
struct mvebu_pcie_window iowin;
u32 saved_pcie_stat;
struct resource regs;
+ struct irq_domain *intx_irq_domain;
+ struct irq_chip intx_irq_chip;
+ raw_spinlock_t irq_lock;
+ int intx_irq;
};
static inline void mvebu_writel(struct mvebu_pcie_port *port, u32 val, u32 reg)
@@ -235,7 +240,7 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
- u32 ctrl, lnkcap, cmd, dev_rev, mask;
+ u32 ctrl, lnkcap, cmd, dev_rev, unmask;
/* Setup PCIe controller to Root Complex mode. */
ctrl = mvebu_readl(port, PCIE_CTRL_OFF);
@@ -288,10 +293,30 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
/* Point PCIe unit MBUS decode windows to DRAM space. */
mvebu_pcie_setup_wins(port);
- /* Enable interrupt lines A-D. */
- mask = mvebu_readl(port, PCIE_MASK_OFF);
- mask |= PCIE_MASK_ENABLE_INTS;
- mvebu_writel(port, mask, PCIE_MASK_OFF);
+ /* Mask all interrupt sources. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
+
+ /* Clear all interrupt causes. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
+
+ if (port->intx_irq <= 0) {
+ /*
+ * When neither "summary" interrupt, nor "intx" interrupt was
+ * specified in DT then unmask all legacy INTx interrupts as in
+ * this case driver does not provide a way for masking and
+ * unmasking of individual legacy INTx interrupts. In this case
+ * all interrupts, including legacy INTx are reported via one
+ * shared GIC source and therefore kernel cannot distinguish
+ * which individual legacy INTx was triggered. These interrupts
+ * are shared, so it should not cause any issue. Just
+ * performance penalty as every PCIe interrupt handler needs to
+ * be called when some interrupt is triggered.
+ */
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask |= PCIE_INT_INTX(0) | PCIE_INT_INTX(1) |
+ PCIE_INT_INTX(2) | PCIE_INT_INTX(3);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ }
}
static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie,
@@ -924,6 +949,109 @@ static struct pci_ops mvebu_pcie_ops = {
.write = mvebu_pcie_wr_conf,
};
+static void mvebu_pcie_intx_irq_mask(struct irq_data *d)
+{
+ struct mvebu_pcie_port *port = d->domain->host_data;
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 unmask;
+
+ raw_spin_lock_irqsave(&port->irq_lock, flags);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask &= ~PCIE_INT_INTX(hwirq);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static void mvebu_pcie_intx_irq_unmask(struct irq_data *d)
+{
+ struct mvebu_pcie_port *port = d->domain->host_data;
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 unmask;
+
+ raw_spin_lock_irqsave(&port->irq_lock, flags);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask |= PCIE_INT_INTX(hwirq);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static int mvebu_pcie_intx_irq_map(struct irq_domain *h,
+ unsigned int virq, irq_hw_number_t hwirq)
+{
+ struct mvebu_pcie_port *port = h->host_data;
+
+ irq_set_status_flags(virq, IRQ_LEVEL);
+ irq_set_chip_and_handler(virq, &port->intx_irq_chip, handle_level_irq);
+ irq_set_chip_data(virq, port);
+
+ return 0;
+}
+
+static const struct irq_domain_ops mvebu_pcie_intx_irq_domain_ops = {
+ .map = mvebu_pcie_intx_irq_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+static int mvebu_pcie_init_irq_domain(struct mvebu_pcie_port *port)
+{
+ struct device *dev = &port->pcie->pdev->dev;
+ struct device_node *pcie_intc_node;
+
+ raw_spin_lock_init(&port->irq_lock);
+
+ port->intx_irq_chip.name = devm_kasprintf(dev, GFP_KERNEL,
+ "mvebu-%s-INTx",
+ port->name);
+ port->intx_irq_chip.irq_mask = mvebu_pcie_intx_irq_mask;
+ port->intx_irq_chip.irq_unmask = mvebu_pcie_intx_irq_unmask;
+
+ pcie_intc_node = of_get_next_child(port->dn, NULL);
+ if (!pcie_intc_node) {
+ dev_err(dev, "No PCIe Intc node found for %s\n", port->name);
+ return -ENODEV;
+ }
+
+ port->intx_irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
+ &mvebu_pcie_intx_irq_domain_ops,
+ port);
+ of_node_put(pcie_intc_node);
+ if (!port->intx_irq_domain) {
+ devm_kfree(dev, port->intx_irq_chip.name);
+ dev_err(dev, "Failed to get INTx IRQ domain for %s\n", port->name);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void mvebu_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct mvebu_pcie_port *port = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct device *dev = &port->pcie->pdev->dev;
+ u32 cause, unmask, status;
+ int i;
+
+ chained_irq_enter(chip, desc);
+
+ cause = mvebu_readl(port, PCIE_INT_CAUSE_OFF);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ status = cause & unmask;
+
+ /* Process legacy INTx interrupts */
+ for (i = 0; i < PCI_NUM_INTX; i++) {
+ if (!(status & PCIE_INT_INTX(i)))
+ continue;
+
+ if (generic_handle_domain_irq(port->intx_irq_domain, i) == -EINVAL)
+ dev_err_ratelimited(dev, "unexpected INT%c IRQ\n", (char)i+'A');
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
static int mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
/* Interrupt support on mvebu emulated bridges is not implemented yet */
@@ -1121,6 +1249,16 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
port->io_attr = -1;
}
+ /*
+ * Old DT bindings do not contain "intx" interrupt
+ * so do not fail probing driver when interrupt does not exist.
+ */
+ port->intx_irq = of_irq_get_byname(child, "intx");
+ if (port->intx_irq == -EPROBE_DEFER) {
+ ret = port->intx_irq;
+ goto err;
+ }
+
reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
if (reset_gpio == -EPROBE_DEFER) {
ret = reset_gpio;
@@ -1317,6 +1455,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
+ int irq = port->intx_irq;
child = port->dn;
if (!child)
@@ -1344,6 +1483,22 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
continue;
}
+ if (irq > 0) {
+ ret = mvebu_pcie_init_irq_domain(port);
+ if (ret) {
+ dev_err(dev, "%s: cannot init irq domain\n",
+ port->name);
+ pci_bridge_emul_cleanup(&port->bridge);
+ devm_iounmap(dev, port->base);
+ port->base = NULL;
+ mvebu_pcie_powerdown(port);
+ continue;
+ }
+ irq_set_chained_handler_and_data(irq,
+ mvebu_pcie_irq_handler,
+ port);
+ }
+
/*
* PCIe topology exported by mvebu hw is quite complicated. In
* reality has something like N fully independent host bridges
@@ -1448,6 +1603,7 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
+ int irq = port->intx_irq;
if (!port->base)
continue;
@@ -1458,7 +1614,17 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
mvebu_writel(port, cmd, PCIE_CMD_OFF);
/* Mask all interrupt sources. */
- mvebu_writel(port, 0, PCIE_MASK_OFF);
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
+
+ /* Clear all interrupt causes. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
+
+ /* Remove IRQ domains. */
+ if (port->intx_irq_domain)
+ irq_domain_remove(port->intx_irq_domain);
+
+ if (irq > 0)
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
/* Free config space for emulated root bridge. */
pci_bridge_emul_cleanup(&port->bridge);
--
2.20.1
_______________________________________________
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] trace-events,pci: unify trace events format
From: Laurent Vivier @ 2022-01-05 14:56 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel
In-Reply-To: <e5011077-3285-cb70-9948-27f84b407dba@redhat.com>
On 15/12/2021 11:57, Laurent Vivier wrote:
> On 07/11/2021 09:38, Michael S. Tsirkin wrote:
>> On Fri, Nov 05, 2021 at 08:25:41PM +0100, Laurent Vivier wrote:
>>> Unify format used by trace_pci_update_mappings_del(),
>>> trace_pci_update_mappings_add(), trace_pci_cfg_write() and
>>> trace_pci_cfg_read() to print the device name and bus number,
>>> slot number and function number.
>>>
>>> For instance:
>>>
>>> pci_cfg_read virtio-net-pci 00:0 @0x20 -> 0xffffc00c
>>> pci_cfg_write virtio-net-pci 00:0 @0x20 <- 0xfea0000c
>>> pci_update_mappings_del d=0x555810b92330 01:00.0 4,0xffffc000+0x4000
>>> pci_update_mappings_add d=0x555810b92330 01:00.0 4,0xfea00000+0x4000
>>>
>>> becomes
>>>
>>> pci_cfg_read virtio-net-pci 01:00.0 @0x20 -> 0xffffc00c
>>> pci_cfg_write virtio-net-pci 01:00.0 @0x20 <- 0xfea0000c
>>> pci_update_mappings_del virtio-net-pci 01:00.0 4,0xffffc000+0x4000
>>> pci_update_mappings_add virtio-net-pci 01:00.0 4,0xfea00000+0x4000
>>>
>>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>>
>> Looks good to me. We are in freeze, will queue. Pls ping after
>> the release to make sure it's not lost.
>
> Ping ?
Well, it seems really lost...
Thanks,
Laurent
^ permalink raw reply
* [PATCH 11/11] ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx interrupts
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Andrew Lunn, Gregory Clement
Cc: linux-pci, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
With this change legacy INTA, INTB, INTC and INTD interrupts are reported
separately and not mixed into one Linux virq source anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
arch/arm/boot/dts/armada-385.dtsi | 52 ++++++++++++++++++++++++++-----
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
index f0022d10c715..83392b92dae2 100644
--- a/arch/arm/boot/dts/armada-385.dtsi
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -69,16 +69,25 @@
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
0x81000000 0 0 0x81000000 0x1 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 0>,
+ <0 0 0 2 &pcie1_intc 1>,
+ <0 0 0 3 &pcie1_intc 2>,
+ <0 0 0 4 &pcie1_intc 3>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 8>;
status = "disabled";
+ pcie1_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/* x1 port */
@@ -88,16 +97,25 @@
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
0x81000000 0 0 0x81000000 0x2 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie2_intc 0>,
+ <0 0 0 2 &pcie2_intc 1>,
+ <0 0 0 3 &pcie2_intc 2>,
+ <0 0 0 4 &pcie2_intc 3>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 5>;
status = "disabled";
+ pcie2_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/* x1 port */
@@ -107,16 +125,25 @@
reg = <0x1800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
0x81000000 0 0 0x81000000 0x3 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie3_intc 0>,
+ <0 0 0 2 &pcie3_intc 1>,
+ <0 0 0 3 &pcie3_intc 2>,
+ <0 0 0 4 &pcie3_intc 3>;
marvell,pcie-port = <2>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 6>;
status = "disabled";
+ pcie3_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/*
@@ -129,16 +156,25 @@
reg = <0x2000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
0x81000000 0 0 0x81000000 0x4 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie4_intc 0>,
+ <0 0 0 2 &pcie4_intc 1>,
+ <0 0 0 3 &pcie4_intc 2>,
+ <0 0 0 4 &pcie4_intc 3>;
marvell,pcie-port = <3>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 7>;
status = "disabled";
+ pcie4_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
};
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 09/16] jobs: remove aiocontext locks since the functions are under BQL
From: Emanuele Giuseppe Esposito @ 2022-01-05 14:02 UTC (permalink / raw)
To: qemu-block
Cc: Kevin Wolf, Fam Zheng, Vladimir Sementsov-Ogievskiy, Wen Congyang,
Xie Changlong, Emanuele Giuseppe Esposito, Markus Armbruster,
qemu-devel, Hanna Reitz, Stefan Hajnoczi, Paolo Bonzini,
John Snow
In-Reply-To: <20220105140208.365608-1-eesposit@redhat.com>
In preparation to the job_lock/unlock patch, remove these
aiocontext locks.
The main reason these two locks are removed here is because
they are inside a loop iterating on the jobs list. Once the
job_lock is added, it will have to protect the whole loop,
wrapping also the aiocontext acquire/release.
We don't want this, as job_lock can only be *wrapped by*
the aiocontext lock, and not vice-versa, to avoid deadlocks.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
---
blockdev.c | 4 ----
job-qmp.c | 4 ----
2 files changed, 8 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 11fd651bde..ee35aff13a 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3707,15 +3707,11 @@ BlockJobInfoList *qmp_query_block_jobs(Error **errp)
for (job = block_job_next(NULL); job; job = block_job_next(job)) {
BlockJobInfo *value;
- AioContext *aio_context;
if (block_job_is_internal(job)) {
continue;
}
- aio_context = blk_get_aio_context(job->blk);
- aio_context_acquire(aio_context);
value = block_job_query(job, errp);
- aio_context_release(aio_context);
if (!value) {
qapi_free_BlockJobInfoList(head);
return NULL;
diff --git a/job-qmp.c b/job-qmp.c
index de4120a1d4..f6f9840436 100644
--- a/job-qmp.c
+++ b/job-qmp.c
@@ -173,15 +173,11 @@ JobInfoList *qmp_query_jobs(Error **errp)
for (job = job_next_locked(NULL); job; job = job_next_locked(job)) {
JobInfo *value;
- AioContext *aio_context;
if (job_is_internal(job)) {
continue;
}
- aio_context = job->aio_context;
- aio_context_acquire(aio_context);
value = job_query_single(job, errp);
- aio_context_release(aio_context);
if (!value) {
qapi_free_JobInfoList(head);
return NULL;
--
2.31.1
^ permalink raw reply related
* [PATCH] fixed argument order for keymap-get in build
From: Dorian Bourgeoisat @ 2022-01-05 12:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Dorian Bourgeoisat, Gerd Hoffmann
Hello, trying to compile QEMU on the latest ArchLinux update (2022-01-05), I encounter a bug where keymap-gen is called with the wrong argument order.
$ ../ui/keycodemapdb/tools/keymap-gen code-map --lang glib2 --varname qemu_input_map_linux_to_qcode ../ui/keycodemapdb/data/keymaps.csv linux qcode
usage: keymap-gen [-h] [--lang LANG] [--varname VARNAME]
{code-map,code-table,name-map,name-table,code-docs,name-docs} ...
keymap-gen: error: unrecognized arguments: --lang --varname linux qcode
This patch makes the meson build file compliant with the new argument order.
Signed-off-by: Dorian Bourgeoisat <dorian.bourgeoisat@telecom-paris.fr>
---
ui/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/meson.build b/ui/meson.build
index 64286ba150..87ecace041 100644
--- a/ui/meson.build
+++ b/ui/meson.build
@@ -161,9 +161,9 @@ if have_system or xkbcommon.found()
capture: true,
input: files('keycodemapdb/data/keymaps.csv'),
command: [python, files('keycodemapdb/tools/keymap-gen'),
- 'code-map',
'--lang', 'glib2',
'--varname', 'qemu_input_map_@0@_to_@1@'.format(e[0], e[1]),
+ 'code-map',
'@INPUT0@', e[0], e[1]])
endforeach
endif
--
2.34.1
^ permalink raw reply related
* [PATCH 09/11] dt-bindings: PCI: mvebu: Update information about intx interrupts
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Andrew Lunn, Gregory Clement
Cc: linux-pci, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 24225852bce0..6d022a9d36ee 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -81,6 +81,11 @@ and the following optional properties:
- reset-gpios: optional GPIO to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion, if not
specified will default to 100ms, as required by the PCIe specification.
+- interrupt-names: list of interrupt names, supported are:
+ - "intx" - interrupt line triggered by one of the legacy interrupt
+- interrupts or interrupts-extended: List of the interrupt sources which
+ corresponding to the "interrupt-names". If non-empty then also additional
+ 'interrupt-controller' subnode must be defined.
Example:
--
2.20.1
_______________________________________________
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 net-next v2] net/smc: Reduce overflow of smc clcsock listen queue
From: D. Wythe @ 2022-01-05 15:06 UTC (permalink / raw)
To: Karsten Graul; +Cc: dust.li, kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <b98aefce-e425-9501-aacc-8e5a4a12953e@linux.ibm.com>
LGTM. Fallback makes the restrictions on SMC dangling
connections more meaningful to me, compared to dropping them.
Overall, i see there are two scenario.
1. Drop the overflow connections limited by userspace application
accept.
2. Fallback the overflow connections limited by the heavy process of
current SMC handshake. ( We can also control its behavior through
sysctl.)
I'll follow those advise to improve my patch, more advise will be highly
appreciated.
Thanks all.
On Wed, Jan 05, 2022 at 02:17:41PM +0100, Karsten Graul wrote:
> On 05/01/2022 09:57, dust.li wrote:
> > On Wed, Jan 05, 2022 at 12:40:49PM +0800, D. Wythe wrote:
> > I'm thinking maybe we can actively fall back to TCP in this case ? Not
> > sure if this is a good idea.
>
> I think its a good decision to switch new connections to use the TCP fallback when the
> current queue of connections waiting for a SMC handshake is too large.
> With this the application is able to accept all incoming connections and they are not
> dropped. The only thing that is be different compared to TCP is that the order of the
> accepted connections is changed, connections that came in later might reach the user space
> application earlier than connections that still run the SMC hand shake processing.
> But I think that is semantically okay.
^ permalink raw reply
* Re: [PATCH 3/3] net: usb: r8152: remove unused definition
From: Greg KH @ 2022-01-05 15:06 UTC (permalink / raw)
To: Henning Schild
Cc: Aaron Ma, kuba, linux-usb, netdev, linux-kernel, davem, hayeswang,
tiwai
In-Reply-To: <20220105155106.400e0285@md1za8fc.ad001.siemens.net>
On Wed, Jan 05, 2022 at 03:51:06PM +0100, Henning Schild wrote:
> Am Wed, 5 Jan 2022 22:23:51 +0800
> schrieb Aaron Ma <aaron.ma@canonical.com>:
>
> Maybe add a
> Fixes: f77b83b5bbab ("net: usb: r8152: Add MAC passthrough support for more Lenovo Docks")
How can removing an unused #define fix anything?
^ permalink raw reply
* [PATCH 08/11] PCI: mvebu: Use child_ops API
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Split struct pci_ops between ops and child_ops. Member ops is used for
accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for
accessing real PCIe cards.
There is no need to mix these two struct pci_ops into one as PCI core code
already provides separate callbacks via bridge->ops and bridge->child_ops.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 82 ++++++++++++++++--------------
1 file changed, 44 insertions(+), 38 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 9ea2f6a7c2b0..1e90ab888075 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -294,11 +294,29 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
mvebu_writel(port, mask, PCIE_MASK_OFF);
}
-static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
- struct pci_bus *bus,
- u32 devfn, int where, int size, u32 *val)
+static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie,
+ struct pci_bus *bus,
+ int devfn);
+
+static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+ int size, u32 *val)
{
- void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF;
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+ void __iomem *conf_data;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port) {
+ *val = 0xffffffff;
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ if (!mvebu_pcie_link_up(port)) {
+ *val = 0xffffffff;
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ conf_data = port->base + PCIE_CONF_DATA_OFF;
mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
PCIE_CONF_ADDR_OFF);
@@ -321,11 +339,21 @@ static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
return PCIBIOS_SUCCESSFUL;
}
-static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
- struct pci_bus *bus,
- u32 devfn, int where, int size, u32 val)
+static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
+ int where, int size, u32 val)
{
- void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF;
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+ void __iomem *conf_data;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!mvebu_pcie_link_up(port))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ conf_data = port->base + PCIE_CONF_DATA_OFF;
mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
PCIE_CONF_ADDR_OFF);
@@ -347,6 +375,11 @@ static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
return PCIBIOS_SUCCESSFUL;
}
+static struct pci_ops mvebu_pcie_child_ops = {
+ .read = mvebu_pcie_child_rd_conf,
+ .write = mvebu_pcie_child_wr_conf,
+};
+
/*
* Remove windows, starting from the largest ones to the smallest
* ones.
@@ -862,25 +895,12 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
{
struct mvebu_pcie *pcie = bus->sysdata;
struct mvebu_pcie_port *port;
- int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- /* Access the emulated PCI-to-PCI bridge */
- if (bus->number == 0)
- return pci_bridge_emul_conf_write(&port->bridge, where,
- size, val);
-
- if (!mvebu_pcie_link_up(port))
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- /* Access the real PCIe interface */
- ret = mvebu_pcie_hw_wr_conf(port, bus, devfn,
- where, size, val);
-
- return ret;
+ return pci_bridge_emul_conf_write(&port->bridge, where, size, val);
}
/* PCI configuration space read function */
@@ -889,7 +909,6 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct mvebu_pcie *pcie = bus->sysdata;
struct mvebu_pcie_port *port;
- int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
if (!port) {
@@ -897,21 +916,7 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
return PCIBIOS_DEVICE_NOT_FOUND;
}
- /* Access the emulated PCI-to-PCI bridge */
- if (bus->number == 0)
- return pci_bridge_emul_conf_read(&port->bridge, where,
- size, val);
-
- if (!mvebu_pcie_link_up(port)) {
- *val = 0xffffffff;
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- /* Access the real PCIe interface */
- ret = mvebu_pcie_hw_rd_conf(port, bus, devfn,
- where, size, val);
-
- return ret;
+ return pci_bridge_emul_conf_read(&port->bridge, where, size, val);
}
static struct pci_ops mvebu_pcie_ops = {
@@ -1421,6 +1426,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
bridge->sysdata = pcie;
bridge->ops = &mvebu_pcie_ops;
+ bridge->child_ops = &mvebu_pcie_child_ops;
bridge->align_resource = mvebu_pcie_align_resource;
bridge->map_irq = mvebu_pcie_map_irq;
--
2.20.1
_______________________________________________
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: [RFC PATCH 0/3] mm/memcg: Address PREEMPT_RT problems instead of disabling it.
From: Sebastian Andrzej Siewior @ 2022-01-05 15:06 UTC (permalink / raw)
To: Michal Koutný
Cc: cgroups, linux-mm, Johannes Weiner, Michal Hocko,
Vladimir Davydov, Andrew Morton, Thomas Gleixner, Waiman Long,
Peter Zijlstra
In-Reply-To: <20220105145956.GB6464@blackbody.suse.cz>
On 2022-01-05 15:59:56 [+0100], Michal Koutný wrote:
> On Wed, Dec 22, 2021 at 12:41:08PM +0100, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> > - lockdep complains were triggered by test_core and test_freezer (both
> > had to run):
>
> This doesn't happen on the patched kernel, correct?
I saw it first on the patched kernel (with this series) then went back
to the -rc and saw it there, too.
> Thanks,
> Michal
Sebastian
^ permalink raw reply
* Re: [PATCH 5/5] tools/xl: Fix potential deallocation bug
From: Anthony PERARD @ 2022-01-05 15:05 UTC (permalink / raw)
To: Elliott Mitchell; +Cc: xen-devel, Wei Liu
In-Reply-To: <2d1335a4056558d172d9aa3e59982eb761647418.1640590794.git.ehem+xen@m5p.com>
On Thu, Dec 10, 2020 at 03:09:06PM -0800, Elliott Mitchell wrote:
> There is potential for the info and info_free variable's purposes to
> diverge. If info was overwritten with a distinct value, yet info_free
> still needed deallocation a bug would occur on this line. Preemptively
> address this issue (making use of divergent info/info_free values is
> under consideration).
>
> Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
> ---
> tools/xl/xl_info.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
> index 3647468420..938f06f1a8 100644
> --- a/tools/xl/xl_info.c
> +++ b/tools/xl/xl_info.c
> @@ -579,7 +579,7 @@ int main_list(int argc, char **argv)
> info, nb_domain);
>
> if (info_free)
> - libxl_dominfo_list_free(info, nb_domain);
> + libxl_dominfo_list_free(info_free, nb_domain);
>
> libxl_dominfo_dispose(&info_buf);
>
I don't think this is the right thing to do with this patch.
libxl_dominfo_list_free() should use the same variable that is used by
libxl_list_domain(). What we want to free is the allocation made by
libxl_list_domain().
"info_free" in the function seems to be used as a boolean which tell
if "info" have been allocated or not. Actually, it probably say if
"info" is a list of "libxl_dominfo" or not.
So instead of just replacing "info" by "info_free" here, we should
instead store the result from libxl_list_domain() into a different
variable and free that, like it is done with "info_buf".
I hope that makes sense?
Thanks,
--
Anthony PERARD
^ permalink raw reply
* Re: [PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax
From: Laurent Vivier @ 2022-01-05 14:49 UTC (permalink / raw)
To: Daniel P. Berrangé, qemu-devel
Cc: Kevin Wolf, Eduardo Habkost, Thomas Huth, Peter Krempa,
Markus Armbruster, Paolo Bonzini, Eric Blake
In-Reply-To: <20220105123847.4047954-2-berrange@redhat.com>
On 05/01/2022 13:38, Daniel P. Berrangé wrote:
> The -device JSON syntax impl leaks a reference on the created
> DeviceState instance. As a result when you hot-unplug the
> device, the device_finalize method won't be called and thus
> it will fail to emit the required DEVICE_DELETED event.
>
> A 'json-cli' feature was previously added against the
> 'device_add' QMP command QAPI schema to indicated to mgmt
> apps that -device supported JSON syntax. Given the hotplug
> bug that feature flag is no unusable for its purpose, so
Not sure to understand: do you mean "now unusable"?
> we add a new 'json-cli-hotplug' feature to indicate the
> -device supports JSON without breaking hotplug.
>
> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/802
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
> qapi/qdev.json | 5 ++++-
> softmmu/vl.c | 4 +++-
> tests/qtest/device-plug-test.c | 19 +++++++++++++++++++
> 3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/qapi/qdev.json b/qapi/qdev.json
> index 69656b14df..26cd10106b 100644
> --- a/qapi/qdev.json
> +++ b/qapi/qdev.json
> @@ -44,6 +44,9 @@
> # @json-cli: If present, the "-device" command line option supports JSON
> # syntax with a structure identical to the arguments of this
> # command.
> +# @json-cli-hotplug: If present, the "-device" command line option supports JSON
> +# syntax without the reference counting leak that broke
> +# hot-unplug
> #
> # Notes:
> #
> @@ -74,7 +77,7 @@
> { 'command': 'device_add',
> 'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
> 'gen': false, # so we can get the additional arguments
> - 'features': ['json-cli'] }
> + 'features': ['json-cli', 'json-cli-hotplug'] }
>
> ##
> # @device_del:
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index d9e4c619d3..b1fc7da104 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -2684,6 +2684,7 @@ static void qemu_create_cli_devices(void)
> qemu_opts_foreach(qemu_find_opts("device"),
> device_init_func, NULL, &error_fatal);
> QTAILQ_FOREACH(opt, &device_opts, next) {
> + DeviceState *dev;
> loc_push_restore(&opt->loc);
> /*
> * TODO Eventually we should call qmp_device_add() here to make sure it
> @@ -2692,7 +2693,8 @@ static void qemu_create_cli_devices(void)
> * from the start, so call qdev_device_add_from_qdict() directly for
> * now.
> */
> - qdev_device_add_from_qdict(opt->opts, true, &error_fatal);
> + dev = qdev_device_add_from_qdict(opt->opts, true, &error_fatal);
> + object_unref(OBJECT(dev));
> loc_pop(&opt->loc);
> }
> rom_reset_order_override();
> diff --git a/tests/qtest/device-plug-test.c b/tests/qtest/device-plug-test.c
> index 559d47727a..ad79bd4c14 100644
> --- a/tests/qtest/device-plug-test.c
> +++ b/tests/qtest/device-plug-test.c
> @@ -77,6 +77,23 @@ static void test_pci_unplug_request(void)
> qtest_quit(qtest);
> }
>
> +static void test_pci_unplug_json_request(void)
> +{
> + QTestState *qtest = qtest_initf(
> + "-device '{\"driver\": \"virtio-mouse-pci\", \"id\": \"dev0\"}'");
> +
> + /*
> + * Request device removal. As the guest is not running, the request won't
> + * be processed. However during system reset, the removal will be
> + * handled, removing the device.
> + */
> + device_del(qtest, "dev0");
> + system_reset(qtest);
You can use qpci_unplug_acpi_device_test() to process the request... but I see this is
done like that too in test_pci_unplug_request()
> + wait_device_deleted_event(qtest, "dev0");
> +
> + qtest_quit(qtest);
> +}
> +
> static void test_ccw_unplug(void)
> {
> QTestState *qtest = qtest_initf("-device virtio-balloon-ccw,id=dev0");
> @@ -145,6 +162,8 @@ int main(int argc, char **argv)
> */
> qtest_add_func("/device-plug/pci-unplug-request",
> test_pci_unplug_request);
> + qtest_add_func("/device-plug/pci-unplug-json-request",
> + test_pci_unplug_json_request);
>
> if (!strcmp(arch, "s390x")) {
> qtest_add_func("/device-plug/ccw-unplug",
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
^ permalink raw reply
* Re: [RFC PATCH 0/3] mm/memcg: Address PREEMPT_RT problems instead of disabling it.
From: Sebastian Andrzej Siewior @ 2022-01-05 15:06 UTC (permalink / raw)
To: Michal Koutný
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
Johannes Weiner, Michal Hocko, Vladimir Davydov, Andrew Morton,
Thomas Gleixner, Waiman Long, Peter Zijlstra
In-Reply-To: <20220105145956.GB6464-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
On 2022-01-05 15:59:56 [+0100], Michal Koutný wrote:
> On Wed, Dec 22, 2021 at 12:41:08PM +0100, Sebastian Andrzej Siewior <bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> wrote:
> > - lockdep complains were triggered by test_core and test_freezer (both
> > had to run):
>
> This doesn't happen on the patched kernel, correct?
I saw it first on the patched kernel (with this series) then went back
to the -rc and saw it there, too.
> Thanks,
> Michal
Sebastian
^ permalink raw reply
* RE: [PATCH 0/8] Support btime and other NFSv4 specific attributes
From: Ondrej Valousek @ 2022-01-05 15:05 UTC (permalink / raw)
To: Trond Myklebust, bfields@fieldses.org, trondmy@kernel.org
Cc: linux-nfs@vger.kernel.org, anna.schumaker@netapp.com
In-Reply-To: <2b27da48604aaa34acce22188bfd429037540a89.camel@hammerspace.com>
Hi all,
Sorry for confusion and maybe dumb questions:
- The aim is to transfer these attributes via RFC8276 (File System Extended attributes in NFSv4)?
- AFAIK support for RFC8276 in NFS (only version 4.2) server is since kernel 5.9, right? NFS client supports these as well?
- The patches below implements the feature in both, nfs client AND server, right?
I am bit confused as "btime" does not seem to be stored as extended attribute in most local filesystems (checked ext4) but is in standard inode structure.
Thanks,
Ondrej
-----Original Message-----
From: Trond Myklebust <trondmy@hammerspace.com>
Sent: pondělí 3. ledna 2022 21:52
To: bfields@fieldses.org; trondmy@kernel.org
Cc: linux-nfs@vger.kernel.org; anna.schumaker@netapp.com
Subject: Re: [PATCH 0/8] Support btime and other NFSv4 specific attributes
On Mon, 2022-01-03 at 15:51 -0500, J. Bruce Fields wrote:
> On Fri, Dec 17, 2021 at 03:48:46PM -0500, trondmy@kernel.org wrote:
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> >
> > NFSv4 has support for a number of extra attributes that are of
> > interest to Samba when it is used to re-export a filesystem to
> > Windows clients.
> > Aside from the btime, which is of interest in statx(), Windows
> > clients have an interest in determining the status of the 'hidden',
> > and 'system'
> > flags.
> > Backup programs want to read the 'archive' flags and the 'time
> > backup'
> > attribute.
> > Finally, the 'offline' flag can tell whether or not a file needs to
> > be staged by an HSM system before it can be read or written to.
> >
> > The patch series also adds an ioctl() to allow userspace retrieval
> > and setting of these attributes where appropriate. It also adds an
> > ioctl()
> > to allow retrieval of the raw NFSv4 ACCESS information, to allow
> > more fine grained determination of the user's access rights to a
> > file or directory. All of this information is of use for Samba.
>
> Same question, what filesystem and server are you testing against?
>
Same answer.
> --b.
>
> >
> > Anne Marie Merritt (3):
> > nfs: Add timecreate to nfs inode
> > nfs: Add 'archive', 'hidden' and 'system' fields to nfs inode
> > nfs: Add 'time backup' to nfs inode
> >
> > Richard Sharpe (1):
> > NFS: Support statx_get and statx_set ioctls
> >
> > Trond Myklebust (4):
> > NFS: Expand the type of nfs_fattr->valid
> > NFS: Return the file btime in the statx results when appropriate
> > NFSv4: Support the offline bit
> > NFSv4: Add an ioctl to allow retrieval of the NFS raw ACCESS mask
> >
> > fs/nfs/dir.c | 71 ++---
> > fs/nfs/getroot.c | 3 +-
> > fs/nfs/inode.c | 147 +++++++++-
> > fs/nfs/internal.h | 10 +
> > fs/nfs/nfs3proc.c | 1 +
> > fs/nfs/nfs4_fs.h | 31 +++
> > fs/nfs/nfs4file.c | 550
> > ++++++++++++++++++++++++++++++++++++++
> > fs/nfs/nfs4proc.c | 175 +++++++++++-
> > fs/nfs/nfs4trace.h | 8 +-
> > fs/nfs/nfs4xdr.c | 240 +++++++++++++++--
> > fs/nfs/nfstrace.c | 5 +
> > fs/nfs/nfstrace.h | 9 +-
> > fs/nfs/proc.c | 1 +
> > include/linux/nfs4.h | 1 +
> > include/linux/nfs_fs.h | 15 ++
> > include/linux/nfs_fs_sb.h | 2 +-
> > include/linux/nfs_xdr.h | 80 ++++--
> > include/uapi/linux/nfs.h | 101 +++++++
> > 18 files changed, 1356 insertions(+), 94 deletions(-)
> >
> > --
> > 2.33.1
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace trond.myklebust@hammerspace.com
Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
^ permalink raw reply
* Re: [PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax
From: Daniel P. Berrangé @ 2022-01-05 14:55 UTC (permalink / raw)
To: Laurent Vivier
Cc: Kevin Wolf, Eduardo Habkost, Thomas Huth, Peter Krempa,
qemu-devel, Markus Armbruster, Paolo Bonzini, Eric Blake
In-Reply-To: <a2a94c4c-190f-9be6-eadf-bd1404a2e272@redhat.com>
On Wed, Jan 05, 2022 at 03:49:12PM +0100, Laurent Vivier wrote:
> On 05/01/2022 13:38, Daniel P. Berrangé wrote:
> > The -device JSON syntax impl leaks a reference on the created
> > DeviceState instance. As a result when you hot-unplug the
> > device, the device_finalize method won't be called and thus
> > it will fail to emit the required DEVICE_DELETED event.
> >
> > A 'json-cli' feature was previously added against the
> > 'device_add' QMP command QAPI schema to indicated to mgmt
> > apps that -device supported JSON syntax. Given the hotplug
> > bug that feature flag is no unusable for its purpose, so
>
> Not sure to understand: do you mean "now unusable"?
An application wants to known whether QEMU can support JSON
syntax with -device. If they look for the 'json-cli' feature
as a witness, they'll end up using JSON with QEMU 6.2 which
is giving them broken hotplug. This is unusable for any
non-trivial use cases. So we need a new witness to indicate
whether JSON is viable with -device, that only the newly
fixed QEMU will report.
>
> > we add a new 'json-cli-hotplug' feature to indicate the
> > -device supports JSON without breaking hotplug.
> >
> > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/802
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > qapi/qdev.json | 5 ++++-
> > softmmu/vl.c | 4 +++-
> > tests/qtest/device-plug-test.c | 19 +++++++++++++++++++
> > 3 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/qapi/qdev.json b/qapi/qdev.json
> > index 69656b14df..26cd10106b 100644
> > --- a/qapi/qdev.json
> > +++ b/qapi/qdev.json
> > @@ -44,6 +44,9 @@
> > # @json-cli: If present, the "-device" command line option supports JSON
> > # syntax with a structure identical to the arguments of this
> > # command.
> > +# @json-cli-hotplug: If present, the "-device" command line option supports JSON
> > +# syntax without the reference counting leak that broke
> > +# hot-unplug
> > #
> > # Notes:
> > #
> > @@ -74,7 +77,7 @@
> > { 'command': 'device_add',
> > 'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
> > 'gen': false, # so we can get the additional arguments
> > - 'features': ['json-cli'] }
> > + 'features': ['json-cli', 'json-cli-hotplug'] }
> > ##
> > # @device_del:
> > diff --git a/softmmu/vl.c b/softmmu/vl.c
> > index d9e4c619d3..b1fc7da104 100644
> > --- a/softmmu/vl.c
> > +++ b/softmmu/vl.c
> > @@ -2684,6 +2684,7 @@ static void qemu_create_cli_devices(void)
> > qemu_opts_foreach(qemu_find_opts("device"),
> > device_init_func, NULL, &error_fatal);
> > QTAILQ_FOREACH(opt, &device_opts, next) {
> > + DeviceState *dev;
> > loc_push_restore(&opt->loc);
> > /*
> > * TODO Eventually we should call qmp_device_add() here to make sure it
> > @@ -2692,7 +2693,8 @@ static void qemu_create_cli_devices(void)
> > * from the start, so call qdev_device_add_from_qdict() directly for
> > * now.
> > */
> > - qdev_device_add_from_qdict(opt->opts, true, &error_fatal);
> > + dev = qdev_device_add_from_qdict(opt->opts, true, &error_fatal);
> > + object_unref(OBJECT(dev));
> > loc_pop(&opt->loc);
> > }
> > rom_reset_order_override();
> > diff --git a/tests/qtest/device-plug-test.c b/tests/qtest/device-plug-test.c
> > index 559d47727a..ad79bd4c14 100644
> > --- a/tests/qtest/device-plug-test.c
> > +++ b/tests/qtest/device-plug-test.c
> > @@ -77,6 +77,23 @@ static void test_pci_unplug_request(void)
> > qtest_quit(qtest);
> > }
> > +static void test_pci_unplug_json_request(void)
> > +{
> > + QTestState *qtest = qtest_initf(
> > + "-device '{\"driver\": \"virtio-mouse-pci\", \"id\": \"dev0\"}'");
> > +
> > + /*
> > + * Request device removal. As the guest is not running, the request won't
> > + * be processed. However during system reset, the removal will be
> > + * handled, removing the device.
> > + */
> > + device_del(qtest, "dev0");
> > + system_reset(qtest);
>
> You can use qpci_unplug_acpi_device_test() to process the request... but I
> see this is done like that too in test_pci_unplug_request()
>
> > + wait_device_deleted_event(qtest, "dev0");
> > +
> > + qtest_quit(qtest);
> > +}
> > +
> > static void test_ccw_unplug(void)
> > {
> > QTestState *qtest = qtest_initf("-device virtio-balloon-ccw,id=dev0");
> > @@ -145,6 +162,8 @@ int main(int argc, char **argv)
> > */
> > qtest_add_func("/device-plug/pci-unplug-request",
> > test_pci_unplug_request);
> > + qtest_add_func("/device-plug/pci-unplug-json-request",
> > + test_pci_unplug_json_request);
> > if (!strcmp(arch, "s390x")) {
> > qtest_add_func("/device-plug/ccw-unplug",
>
> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply
* [PATCH 07/11] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
AER registers start at mvebu offset 0x0100. Registers PCI_ERR_ROOT_COMMAND,
PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC are not supported on pre-XP
hardware and returns zeros.
Note that AER interrupt is not supported yet as mvebu emulated bridge does
not implement interrupts support at all yet.
Also remove custom macro PCIE_HEADER_LOG_4_OFF as it is unused and
correctly this register should be referenced via standard macros with
offset, e.g. as: PCIE_CAP_PCIERR_OFF + PCI_ERR_HEADER_LOG + 4.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 67 +++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 811af9e6ede5..9ea2f6a7c2b0 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -34,7 +34,7 @@
#define PCIE_BAR_HI_OFF(n) (0x0014 + ((n) << 3))
#define PCIE_SSDEV_ID_OFF 0x002c
#define PCIE_CAP_PCIEXP 0x0060
-#define PCIE_HEADER_LOG_4_OFF 0x0128
+#define PCIE_CAP_PCIERR_OFF 0x0100
#define PCIE_BAR_CTRL_OFF(n) (0x1804 + (((n) - 1) * 4))
#define PCIE_WIN04_CTRL_OFF(n) (0x1820 + ((n) << 4))
#define PCIE_WIN04_BASE_OFF(n) (0x1824 + ((n) << 4))
@@ -603,6 +603,37 @@ mvebu_pci_bridge_emul_pcie_conf_read(struct pci_bridge_emul *bridge,
return PCI_BRIDGE_EMUL_HANDLED;
}
+static pci_bridge_emul_read_status_t
+mvebu_pci_bridge_emul_ext_conf_read(struct pci_bridge_emul *bridge,
+ int reg, u32 *value)
+{
+ struct mvebu_pcie_port *port = bridge->data;
+
+ switch (reg) {
+ case 0:
+ case PCI_ERR_UNCOR_STATUS:
+ case PCI_ERR_UNCOR_MASK:
+ case PCI_ERR_UNCOR_SEVER:
+ case PCI_ERR_COR_STATUS:
+ case PCI_ERR_COR_MASK:
+ case PCI_ERR_CAP:
+ case PCI_ERR_HEADER_LOG+0:
+ case PCI_ERR_HEADER_LOG+4:
+ case PCI_ERR_HEADER_LOG+8:
+ case PCI_ERR_HEADER_LOG+12:
+ case PCI_ERR_ROOT_COMMAND:
+ case PCI_ERR_ROOT_STATUS:
+ case PCI_ERR_ROOT_ERR_SRC:
+ *value = mvebu_readl(port, PCIE_CAP_PCIERR_OFF + reg);
+ break;
+
+ default:
+ return PCI_BRIDGE_EMUL_NOT_HANDLED;
+ }
+
+ return PCI_BRIDGE_EMUL_HANDLED;
+}
+
static void
mvebu_pci_bridge_emul_base_conf_write(struct pci_bridge_emul *bridge,
int reg, u32 old, u32 new, u32 mask)
@@ -715,11 +746,45 @@ mvebu_pci_bridge_emul_pcie_conf_write(struct pci_bridge_emul *bridge,
}
}
+static void
+mvebu_pci_bridge_emul_ext_conf_write(struct pci_bridge_emul *bridge,
+ int reg, u32 old, u32 new, u32 mask)
+{
+ struct mvebu_pcie_port *port = bridge->data;
+
+ switch (reg) {
+ /* These are W1C registers, so clear other bits */
+ case PCI_ERR_UNCOR_STATUS:
+ case PCI_ERR_COR_STATUS:
+ case PCI_ERR_ROOT_STATUS:
+ new &= mask;
+ fallthrough;
+
+ case PCI_ERR_UNCOR_MASK:
+ case PCI_ERR_UNCOR_SEVER:
+ case PCI_ERR_COR_MASK:
+ case PCI_ERR_CAP:
+ case PCI_ERR_HEADER_LOG+0:
+ case PCI_ERR_HEADER_LOG+4:
+ case PCI_ERR_HEADER_LOG+8:
+ case PCI_ERR_HEADER_LOG+12:
+ case PCI_ERR_ROOT_COMMAND:
+ case PCI_ERR_ROOT_ERR_SRC:
+ mvebu_writel(port, new, PCIE_CAP_PCIERR_OFF + reg);
+ break;
+
+ default:
+ break;
+ }
+}
+
static const struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
.read_base = mvebu_pci_bridge_emul_base_conf_read,
.write_base = mvebu_pci_bridge_emul_base_conf_write,
.read_pcie = mvebu_pci_bridge_emul_pcie_conf_read,
.write_pcie = mvebu_pci_bridge_emul_pcie_conf_write,
+ .read_ext = mvebu_pci_bridge_emul_ext_conf_read,
+ .write_ext = mvebu_pci_bridge_emul_ext_conf_write,
};
/*
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/11] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Register with Subsystem Device/Vendor ID is at offset 0x2c. Export is via
emulated bridge.
After this change Subsystem ID is visible in lspci output at line:
Capabilities: [40] Subsystem
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 0f2ec0a17874..811af9e6ede5 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -32,6 +32,7 @@
#define PCIE_DEV_REV_OFF 0x0008
#define PCIE_BAR_LO_OFF(n) (0x0010 + ((n) << 3))
#define PCIE_BAR_HI_OFF(n) (0x0014 + ((n) << 3))
+#define PCIE_SSDEV_ID_OFF 0x002c
#define PCIE_CAP_PCIEXP 0x0060
#define PCIE_HEADER_LOG_4_OFF 0x0128
#define PCIE_BAR_CTRL_OFF(n) (0x1804 + (((n) - 1) * 4))
@@ -731,6 +732,7 @@ static int mvebu_pci_bridge_emul_init(struct mvebu_pcie_port *port)
struct pci_bridge_emul *bridge = &port->bridge;
u32 dev_id = mvebu_readl(port, PCIE_DEV_ID_OFF);
u32 dev_rev = mvebu_readl(port, PCIE_DEV_REV_OFF);
+ u32 ssdev_id = mvebu_readl(port, PCIE_SSDEV_ID_OFF);
u32 pcie_cap = mvebu_readl(port, PCIE_CAP_PCIEXP);
u8 pcie_cap_ver = ((pcie_cap >> 16) & PCI_EXP_FLAGS_VERS);
@@ -752,6 +754,8 @@ static int mvebu_pci_bridge_emul_init(struct mvebu_pcie_port *port)
*/
bridge->pcie_conf.cap = cpu_to_le16(pcie_cap_ver);
+ bridge->subsystem_vendor_id = ssdev_id & 0xffff;
+ bridge->subsystem_id = ssdev_id >> 16;
bridge->has_pcie = true;
bridge->data = port;
bridge->ops = &mvebu_pci_bridge_emul_ops;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/11] dt-bindings: PCI: mvebu: Add num-lanes property
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Andrew Lunn, Gregory Clement
Cc: linux-pci, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Controller driver needs to correctly configure PCIe link if it contains 1
or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for
mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard
way how number of lanes is specified in other PCIe controllers.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6173af6885f8..24225852bce0 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -77,6 +77,7 @@ and the following optional properties:
- marvell,pcie-lane: the physical PCIe lane number, for ports having
multiple lanes. If this property is not found, we assume that the
value is 0.
+- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
- reset-gpios: optional GPIO to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion, if not
specified will default to 100ms, as required by the PCIe specification.
@@ -141,6 +142,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 58>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
/* low-active PERST# reset on GPIO 25 */
reset-gpios = <&gpio0 25 1>;
/* wait 20ms for device settle after reset deassertion */
@@ -161,6 +163,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 59>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <1>;
+ num-lanes = <1>;
clocks = <&gateclk 6>;
};
@@ -177,6 +180,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 60>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <2>;
+ num-lanes = <1>;
clocks = <&gateclk 7>;
};
@@ -193,6 +197,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 61>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <3>;
+ num-lanes = <1>;
clocks = <&gateclk 8>;
};
@@ -209,6 +214,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 62>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 9>;
};
@@ -225,6 +231,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 63>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <1>;
+ num-lanes = <1>;
clocks = <&gateclk 10>;
};
@@ -241,6 +248,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 64>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <2>;
+ num-lanes = <1>;
clocks = <&gateclk 11>;
};
@@ -257,6 +265,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 65>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <3>;
+ num-lanes = <1>;
clocks = <&gateclk 12>;
};
@@ -273,6 +282,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 99>;
marvell,pcie-port = <2>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 26>;
};
@@ -289,6 +299,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 103>;
marvell,pcie-port = <3>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 27>;
};
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/11] PCI: mvebu: Correctly configure x1/x4 mode
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
If x1/x4 mode is not set correctly then link with endpoint card is not
established.
Use DTS property 'num-lanes' to deteriminate x1/x4 mode.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index a075ba26cff1..0f2ec0a17874 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -93,6 +93,7 @@ struct mvebu_pcie_port {
void __iomem *base;
u32 port;
u32 lane;
+ bool is_x4;
int devfn;
unsigned int mem_target;
unsigned int mem_attr;
@@ -233,13 +234,25 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
- u32 ctrl, cmd, dev_rev, mask;
+ u32 ctrl, lnkcap, cmd, dev_rev, mask;
/* Setup PCIe controller to Root Complex mode. */
ctrl = mvebu_readl(port, PCIE_CTRL_OFF);
ctrl |= PCIE_CTRL_RC_MODE;
mvebu_writel(port, ctrl, PCIE_CTRL_OFF);
+ /*
+ * Set Maximum Link Width to X1 or X4 in Root Port's PCIe Link
+ * Capability register. This register is defined by PCIe specification
+ * as read-only but this mvebu controller has it as read-write and must
+ * be set to number of SerDes PCIe lanes (1 or 4). If this register is
+ * not set correctly then link with endpoint card is not established.
+ */
+ lnkcap = mvebu_readl(port, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
+ lnkcap &= ~PCI_EXP_LNKCAP_MLW;
+ lnkcap |= (port->is_x4 ? 4 : 1) << 4;
+ mvebu_writel(port, lnkcap, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
+
/* Disable Root Bridge I/O space, memory space and bus mastering. */
cmd = mvebu_readl(port, PCIE_CMD_OFF);
cmd &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
@@ -986,6 +999,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
struct device *dev = &pcie->pdev->dev;
enum of_gpio_flags flags;
int reset_gpio, ret;
+ u32 num_lanes;
port->pcie = pcie;
@@ -998,6 +1012,9 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
if (of_property_read_u32(child, "marvell,pcie-lane", &port->lane))
port->lane = 0;
+ if (!of_property_read_u32(child, "num-lanes", &num_lanes) && num_lanes == 4)
+ port->is_x4 = true;
+
port->name = devm_kasprintf(dev, GFP_KERNEL, "pcie%d.%d", port->port,
port->lane);
if (!port->name) {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Patch "Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40" has been added to the 5.4-stable tree
From: gregkh @ 2022-01-05 15:04 UTC (permalink / raw)
To: anders.roxell, gregkh, llvm, nathan, ndesaulniers, sashal; +Cc: stable-commits
In-Reply-To: <20220103192935.3438038-1-nathan@kernel.org>
This is a note to let you know that I've just added the patch titled
Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
input-touchscreen-fix-backport-of-a02dcde595f7cbd240ccd64de96034ad91cffc40.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From nathan@kernel.org Wed Jan 5 16:03:30 2022
From: Nathan Chancellor <nathan@kernel.org>
Date: Mon, 3 Jan 2022 12:29:35 -0700
Subject: Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sasha Levin <sashal@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>, stable@vger.kernel.org, llvm@lists.linux.dev, Anders Roxell <anders.roxell@linaro.org>, Nathan Chancellor <nathan@kernel.org>
Message-ID: <20220103192935.3438038-1-nathan@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
Upstream commit a02dcde595f7 ("Input: touchscreen - avoid bitwise vs
logical OR warning") was applied as commit f6e9e7be9b80 ("Input:
touchscreen - avoid bitwise vs logical OR warning") in linux-5.4.y but
it did not properly account for commit d9265e8a878a ("Input:
of_touchscreen - add support for touchscreen-min-x|y"), which means the
warning mentioned in the commit message is not fully fixed:
drivers/input/touchscreen/of_touchscreen.c:78:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/touchscreen/of_touchscreen.c:78:17: note: cast one or both operands to int to silence this warning
drivers/input/touchscreen/of_touchscreen.c:92:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/touchscreen/of_touchscreen.c:92:17: note: cast one or both operands to int to silence this warning
2 warnings generated.
It seems like the 4.19 backport was applied to the 5.4 tree, which did
not have any conflicts so no issue was noticed at that point.
Fix up the backport to bring it more in line with the upstream version
so that there is no warning.
Fixes: f6e9e7be9b80 ("Input: touchscreen - avoid bitwise vs logical OR warning")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/of_touchscreen.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -77,8 +77,8 @@ void touchscreen_parse_properties(struct
axis = multitouch ? ABS_MT_POSITION_X : ABS_X;
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
input_abs_get_min(input, axis),
- &minimum) |
- touchscreen_get_prop_u32(dev, "touchscreen-size-x",
+ &minimum);
+ data_present |= touchscreen_get_prop_u32(dev, "touchscreen-size-x",
input_abs_get_max(input,
axis) + 1,
&maximum);
@@ -91,8 +91,8 @@ void touchscreen_parse_properties(struct
axis = multitouch ? ABS_MT_POSITION_Y : ABS_Y;
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
input_abs_get_min(input, axis),
- &minimum) |
- touchscreen_get_prop_u32(dev, "touchscreen-size-y",
+ &minimum);
+ data_present |= touchscreen_get_prop_u32(dev, "touchscreen-size-y",
input_abs_get_max(input,
axis) + 1,
&maximum);
Patches currently in stable-queue which might be from nathan@kernel.org are
queue-5.4/input-touchscreen-fix-backport-of-a02dcde595f7cbd240ccd64de96034ad91cffc40.patch
^ permalink raw reply
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.