* Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level
From: rishabhb @ 2018-07-23 20:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, ckadabi, tsoni,
Vikram Mulukutla, rjwysocki
In-Reply-To: <CAJZ5v0gWqx5Op-Bbg7bAYALCyBPsc=-+homAYj2Q1qd3WsqmDw@mail.gmail.com>
On 2018-07-23 04:17, Rafael J. Wysocki wrote:
> On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
> <rishabhb@codeaurora.org> wrote:
>> Drivers that are registered at an initcall level may have to
>> wait until late_init before the probe deferral mechanism can
>> retry their probe functions. It is possible that their
>> dependencies were resolved much earlier, in some cases even
>> before the next initcall level. Invoke one probe retry cycle
>> at every _sync initcall level, allowing these drivers to be
>> probed earlier.
>
> Can you please say something about the actual use case this is
> expected to address?
We have a display driver that depends 3 other devices to be
probed so that it can bring-up the display. Because of dependencies
not being met the deferral mechanism defers the probes for a later time,
even though the dependencies might be met earlier. With this change
display can be brought up much earlier.
>
>> Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
>> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
>> ---
>> drivers/base/dd.c | 33 +++++++++++++++++++++++++++------
>> 1 file changed, 27 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 1435d72..e6a6821 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -224,23 +224,44 @@ void device_unblock_probing(void)
>> driver_deferred_probe_trigger();
>> }
>>
>> +static void enable_trigger_defer_cycle(void)
>> +{
>> + driver_deferred_probe_enable = true;
>> + driver_deferred_probe_trigger();
>> + /*
>> + * Sort as many dependencies as possible before the next
>> initcall
>> + * level
>> + */
>> + flush_work(&deferred_probe_work);
>> +}
>> +
>> /**
>> * deferred_probe_initcall() - Enable probing of deferred devices
>> *
>> * We don't want to get in the way when the bulk of drivers are
>> getting probed.
>> * Instead, this initcall makes sure that deferred probing is delayed
>> until
>> - * late_initcall time.
>> + * all the registered initcall functions at a particular level are
>> completed.
>> + * This function is invoked at every *_initcall_sync level.
>> */
>> static int deferred_probe_initcall(void)
>> {
>> - driver_deferred_probe_enable = true;
>> - driver_deferred_probe_trigger();
>> - /* Sort as many dependencies as possible before exiting
>> initcalls */
>> - flush_work(&deferred_probe_work);
>> + enable_trigger_defer_cycle();
>> + driver_deferred_probe_enable = false;
>> + return 0;
>> +}
>> +arch_initcall_sync(deferred_probe_initcall);
>> +subsys_initcall_sync(deferred_probe_initcall);
>> +fs_initcall_sync(deferred_probe_initcall);
>> +device_initcall_sync(deferred_probe_initcall);
>> +
>> +static int deferred_probe_enable_fn(void)
>> +{
>> + /* Enable deferred probing for all time */
>> + enable_trigger_defer_cycle();
>> initcalls_done = true;
>> return 0;
>> }
>> -late_initcall(deferred_probe_initcall);
>> +late_initcall(deferred_probe_enable_fn);
>>
>> /**
>> * device_is_bound() - Check if device is bound to a driver
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum,
>> a Linux Foundation Collaborative Project
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.IGT: success for tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases (rev5)
From: Patchwork @ 2018-07-23 20:23 UTC (permalink / raw)
To: Radhakrishna Sripada; +Cc: igt-dev
In-Reply-To: <20180723182545.19461-1-radhakrishna.sripada@intel.com>
== Series Details ==
Series: tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases (rev5)
URL : https://patchwork.freedesktop.org/series/40553/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4570_full -> IGTPW_1632_full =
== Summary - WARNING ==
Minor unknown changes coming with IGTPW_1632_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_1632_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/40553/revisions/5/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in IGTPW_1632_full:
=== IGT changes ===
==== Warnings ====
igt@gem_exec_schedule@deep-blt:
shard-kbl: PASS -> SKIP
igt@kms_atomic_interruptible@legacy-pageflip:
shard-snb: SKIP -> PASS +1
igt@pm_rc6_residency@rc6-accuracy:
shard-kbl: SKIP -> PASS +1
== Known issues ==
Here are the changes found in IGTPW_1632_full that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@gem_exec_schedule@pi-ringfull-vebox:
shard-glk: NOTRUN -> FAIL (fdo#103158)
igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
shard-hsw: PASS -> FAIL (fdo#100368)
shard-glk: PASS -> FAIL (fdo#100368)
igt@kms_flip@flip-vs-expired-vblank:
shard-glk: PASS -> FAIL (fdo#105189)
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
igt@perf_pmu@busy-idle-check-all-vcs0:
shard-snb: PASS -> INCOMPLETE (fdo#105411)
==== Possible fixes ====
igt@gem_mmap_gtt@coherency:
shard-glk: FAIL (fdo#100587) -> SKIP +1
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS
igt@kms_flip@plain-flip-ts-check-interruptible:
shard-glk: FAIL (fdo#100368) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
shard-glk: FAIL (fdo#103167) -> PASS
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-snb: FAIL (fdo#103166) -> PASS
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> PASS
igt@perf_pmu@multi-client-vcs1:
shard-snb: INCOMPLETE (fdo#105411) -> SKIP
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> SKIP +1
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1632
* Linux: CI_DRM_4519 -> CI_DRM_4521
CI_DRM_4519: f14c0ec8fe9acce6fd1be84766f854ab8874eb33 @ git://anongit.freedesktop.org/gfx-ci/linux
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1632: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1632/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1632/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: Consolidating RCU-bh, RCU-preempt, and RCU-sched
From: Paul E. McKenney @ 2018-07-23 20:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Lai Jiangshan, Josh Triplett, Mathieu Desnoyers, LKML,
Ingo Molnar, Linus Torvalds, Peter Zijlstra, oleg, Eric Dumazet,
davem, Thomas Gleixner
In-Reply-To: <20180723161041.5375b54f@gandalf.local.home>
On Mon, Jul 23, 2018 at 04:10:41PM -0400, Steven Rostedt wrote:
>
> Sorry for the late reply, just came back from the Caribbean :-) :-) :-)
Welcome back, and I hope that the Caribbean trip was a good one!
> On Fri, 13 Jul 2018 11:47:18 +0800
> Lai Jiangshan <jiangshanlai@gmail.com> wrote:
>
> > On Fri, Jul 13, 2018 at 8:02 AM, Paul E. McKenney
> > <paulmck@linux.vnet.ibm.com> wrote:
> > > Hello!
> > >
> > > I now have a semi-reasonable prototype of changes consolidating the
> > > RCU-bh, RCU-preempt, and RCU-sched update-side APIs in my -rcu tree.
> > > There are likely still bugs to be fixed and probably other issues as well,
> > > but a prototype does exist.
>
> What's the rational for all this churn? Linus's complaining that there
> are too many RCU variants?
A CVE stemming from someone getting confused between the different flavors
of RCU. The churn is large, as you say, but it does have the benefit of
making RCU a bit smaller.
Not necessarily simpler, but smaller.
> > > Assuming continued good rcutorture results and no objections, I am
> > > thinking in terms of this timeline:
> > >
> > > o Preparatory work and cleanups are slated for the v4.19 merge window.
> > >
> > > o The actual consolidation and post-consolidation cleanup is slated
> > > for the merge window after v4.19 (v5.0?). These cleanups include
> > > the replacements called out below within the RCU implementation
> > > itself (but excluding kernel/rcu/sync.c, see question below).
> > >
> > > o Replacement of now-obsolete update APIs is slated for the second
> > > merge window after v4.19 (v5.1?). The replacements are currently
> > > expected to be as follows:
> > >
> > > synchronize_rcu_bh() -> synchronize_rcu()
> > > synchronize_rcu_bh_expedited() -> synchronize_rcu_expedited()
> > > call_rcu_bh() -> call_rcu()
> > > rcu_barrier_bh() -> rcu_barrier()
> > > synchronize_sched() -> synchronize_rcu()
> > > synchronize_sched_expedited() -> synchronize_rcu_expedited()
> > > call_rcu_sched() -> call_rcu()
> > > rcu_barrier_sched() -> rcu_barrier()
> > > get_state_synchronize_sched() -> get_state_synchronize_rcu()
> > > cond_synchronize_sched() -> cond_synchronize_rcu()
> > > synchronize_rcu_mult() -> synchronize_rcu()
> > >
> > > I have done light testing of these replacements with good results.
> > >
> > > Any objections to this timeline?
> > >
> > > I also have some questions on the ultimate end point. I have default
> > > choices, which I will likely take if there is no discussion.
> > >
> > > o
> > > Currently, I am thinking in terms of keeping the per-flavor
> > > read-side functions. For example, rcu_read_lock_bh() would
> > > continue to disable softirq, and would also continue to tell
> > > lockdep about the RCU-bh read-side critical section. However,
> > > synchronize_rcu() will wait for all flavors of read-side critical
> > > sections, including those introduced by (say) preempt_disable(),
> > > so there will no longer be any possibility of mismatching (say)
> > > RCU-bh readers with RCU-sched updaters.
> > >
> > > I could imagine other ways of handling this, including:
> > >
> > > a. Eliminate rcu_read_lock_bh() in favor of
> > > local_bh_disable() and so on. Rely on lockdep
> > > instrumentation of these other functions to identify RCU
> > > readers, introducing such instrumentation as needed. I am
> > > not a fan of this approach because of the large number of
> > > places in the Linux kernel where interrupts, preemption,
> > > and softirqs are enabled or disabled "behind the scenes".
> > >
> > > b. Eliminate rcu_read_lock_bh() in favor of rcu_read_lock(),
> > > and required callers to also disable softirqs, preemption,
> > > or whatever as needed. I am not a fan of this approach
> > > because it seems a lot less convenient to users of RCU-bh
> > > and RCU-sched.
> > >
> > > At the moment, I therefore favor keeping the RCU-bh and RCU-sched
> > > read-side APIs. But are there better approaches?
> >
> > Hello, Paul
> >
> > Since local_bh_disable() will be guaranteed to be protected by RCU
> > and more general. I'm afraid it will be preferred over
> > rcu_read_lock_bh() which will be gradually being phased out.
> >
> > In other words, keeping the RCU-bh read-side APIs will be a slower
> > version of the option A. So will the same approach for the RCU-sched.
> > But it'll still be better than the hurrying option A, IMHO.
>
> Now when all this gets done, is synchronize_rcu() going to just wait
> for everything to pass? (scheduling, RCU readers, softirqs, etc) Is
> there any worry about lengthening the time of synchronize_rcu?
Yes, when all is said and done, synchronize_rcu() will wait for everything
to get done. I am not too worried about PREEMPT=y synchronize_rcu()'s
latency because the kernel usually doesn't spend that large a fraction
of its time disabled. I am not worried at all about PREEMPT=n
synchronize_rcu()'s latency because it will if anything be slightly
faster due to being able to take advantage of some softirq transitions.
But one reason for feeding this in over three successive merge windows
is to get more time on it before it all goes in.
Thanx, Paul
> -- Steve
>
>
> > >
> > > o How should kernel/rcu/sync.c be handled? Here are some
> > > possibilities:
> > >
> > > a. Leave the full gp_ops[] array and simply translate
> > > the obsolete update-side functions to their RCU
> > > equivalents.
> > >
> > > b. Leave the current gp_ops[] array, but only have
> > > the RCU_SYNC entry. The __INIT_HELD field would
> > > be set to a function that was OK with being in an
> > > RCU read-side critical section, an interrupt-disabled
> > > section, etc.
> > >
> > > This allows for possible addition of SRCU functionality.
> > > It is also a trivial change. Note that the sole user
> > > of sync.c uses RCU_SCHED_SYNC, and this would need to
> > > be changed to RCU_SYNC.
> > >
> > > But is it likely that we will ever add SRCU?
> > >
> > > c. Eliminate that gp_ops[] array, hard-coding the function
> > > pointers into their call sites.
> > >
> > > I don't really have a preference. Left to myself, I will be lazy
> > > and take option #a. Are there better approaches?
> > >
> > > o Currently, if a lock related to the scheduler's rq or pi locks is
> > > held across rcu_read_unlock(), that lock must be held across the
> > > entire read-side critical section in order to avoid deadlock.
> > > Now that the end of the RCU read-side critical section is
> > > deferred until sometime after interrupts are re-enabled, this
> > > requirement could be lifted. However, because the end of the RCU
> > > read-side critical section is detected sometime after interrupts
> > > are re-enabled, this means that a low-priority RCU reader might
> > > remain priority-boosted longer than need be, which could be a
> > > problem when running real-time workloads.
> > >
> > > My current thought is therefore to leave this constraint in
> > > place. Thoughts?
> > >
> > > Anything else that I should be worried about? ;-)
> > >
> > > Thanx, Paul
> > >
>
^ permalink raw reply
* [PATCH 00/12] i2c: quirks: add zero length checks and update drivers
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-arm-msm, linux-kernel, linux-renesas-soc, Wolfram Sang,
linux-tegra, linux-omap, linux-soc, linux-arm-kernel
I had this idea for quite some time on my todo list but a soon to be
implemented refactoring in the i2c-rcar driver now finally made me do it. Add a
'can't do 0 length messages' quirk to the quirk infrastructure for and remove
the manual handling from the drivers. This makes the quirk much more visible.
(Quite some prominent vendors in that list) We also have a centralized place to
handle updates to the quirk detection if that is ever needed.
I have tested this with the i2c-rcar and i2c-sh_mobile driver on a Renesas
SalvatorXS board equipped with M3-N (r8a77965).
A git branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/quirk-no-zero-len
Looking forward to comments, reviews, tests...
Thanks,
Wolfram
Wolfram Sang (12):
i2c: quirks: add zero length checks
i2c: designware-master: use core to detect 'no zero length' quirk
i2c: mxs: use core to detect 'no zero length' quirk
i2c: omap: use core to detect 'no zero length' quirk
i2c: pmcmsp: use core to detect 'no zero length' quirk
i2c: qup: use core to detect 'no zero length' quirk
i2c: stu300: use core to detect 'no zero length' quirk
i2c: tegra: use core to detect 'no zero length' quirk
i2c: zx2967: use core to detect 'no zero length' quirk
i2c: rcar: use core to detect 'no zero length' quirk
i2c: xlr: use core to detect 'no zero length' quirk
i2c: sh_mobile: use core to detect 'no zero length read' quirk
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
drivers/i2c/busses/i2c-omap.c | 8 +++++---
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
drivers/i2c/busses/i2c-rcar.c | 13 ++++++-------
drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
drivers/i2c/busses/i2c-tegra.c | 4 +---
drivers/i2c/busses/i2c-xlr.c | 11 +++++------
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
13 files changed, 60 insertions(+), 67 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 00/12] i2c: quirks: add zero length checks and update drivers
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-arm-kernel
I had this idea for quite some time on my todo list but a soon to be
implemented refactoring in the i2c-rcar driver now finally made me do it. Add a
'can't do 0 length messages' quirk to the quirk infrastructure for and remove
the manual handling from the drivers. This makes the quirk much more visible.
(Quite some prominent vendors in that list) We also have a centralized place to
handle updates to the quirk detection if that is ever needed.
I have tested this with the i2c-rcar and i2c-sh_mobile driver on a Renesas
SalvatorXS board equipped with M3-N (r8a77965).
A git branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/quirk-no-zero-len
Looking forward to comments, reviews, tests...
Thanks,
Wolfram
Wolfram Sang (12):
i2c: quirks: add zero length checks
i2c: designware-master: use core to detect 'no zero length' quirk
i2c: mxs: use core to detect 'no zero length' quirk
i2c: omap: use core to detect 'no zero length' quirk
i2c: pmcmsp: use core to detect 'no zero length' quirk
i2c: qup: use core to detect 'no zero length' quirk
i2c: stu300: use core to detect 'no zero length' quirk
i2c: tegra: use core to detect 'no zero length' quirk
i2c: zx2967: use core to detect 'no zero length' quirk
i2c: rcar: use core to detect 'no zero length' quirk
i2c: xlr: use core to detect 'no zero length' quirk
i2c: sh_mobile: use core to detect 'no zero length read' quirk
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
drivers/i2c/busses/i2c-omap.c | 8 +++++---
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
drivers/i2c/busses/i2c-rcar.c | 13 ++++++-------
drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
drivers/i2c/busses/i2c-tegra.c | 4 +---
drivers/i2c/busses/i2c-xlr.c | 11 +++++------
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
13 files changed, 60 insertions(+), 67 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 01/12] i2c: quirks: add zero length checks
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
Some adapters do not support a message length of 0. Add this as a quirk
so drivers don't have to open code it.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
2 files changed, 10 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 02d6f27b19e4..a26b3e9cc441 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1839,9 +1839,15 @@ static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs,
if (msgs[i].flags & I2C_M_RD) {
if (do_len_check && i2c_quirk_exceeded(len, q->max_read_len))
return i2c_quirk_error(adap, &msgs[i], "msg too long");
+
+ if (q->flags & I2C_AQ_NO_ZERO_LEN_READ && len == 0)
+ return i2c_quirk_error(adap, &msgs[i], "no zero length");
} else {
if (do_len_check && i2c_quirk_exceeded(len, q->max_write_len))
return i2c_quirk_error(adap, &msgs[i], "msg too long");
+
+ if (q->flags & I2C_AQ_NO_ZERO_LEN_WRITE && len == 0)
+ return i2c_quirk_error(adap, &msgs[i], "no zero length");
}
}
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index bc8d42f8544f..2a98d0886d2e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -661,6 +661,10 @@ struct i2c_adapter_quirks {
I2C_AQ_COMB_READ_SECOND | I2C_AQ_COMB_SAME_ADDR)
/* clock stretching is not supported */
#define I2C_AQ_NO_CLK_STRETCH BIT(4)
+/* message cannot have length of 0 */
+#define I2C_AQ_NO_ZERO_LEN_READ BIT(5)
+#define I2C_AQ_NO_ZERO_LEN_WRITE BIT(6)
+#define I2C_AQ_NO_ZERO_LEN (I2C_AQ_NO_ZERO_LEN_READ | I2C_AQ_NO_ZERO_LEN_WRITE)
/*
* i2c_adapter is the structure used to identify a physical i2c bus along
--
2.11.0
^ permalink raw reply related
* [PATCH 02/12] i2c: designware-master: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Jarkko Nikula, Andy Shevchenko,
Mika Westerberg, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c
index fc7c255c80af..a1717bff06a8 100644
--- a/drivers/i2c/busses/i2c-designware-master.c
+++ b/drivers/i2c/busses/i2c-designware-master.c
@@ -274,13 +274,6 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
break;
}
- if (msgs[dev->msg_write_idx].len == 0) {
- dev_err(dev->dev,
- "%s: invalid message length\n", __func__);
- dev->msg_err = -EINVAL;
- break;
- }
-
if (!(dev->status & STATUS_WRITE_IN_PROGRESS)) {
/* new i2c_msg */
buf = msgs[dev->msg_write_idx].buf;
@@ -523,6 +516,10 @@ static const struct i2c_algorithm i2c_dw_algo = {
.functionality = i2c_dw_func,
};
+static const struct i2c_adapter_quirks i2c_dw_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static u32 i2c_dw_read_clear_intrbits(struct dw_i2c_dev *dev)
{
u32 stat;
@@ -718,6 +715,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
"Synopsys DesignWare I2C adapter");
adap->retries = 3;
adap->algo = &i2c_dw_algo;
+ adap->quirks = &i2c_dw_quirks;
adap->dev.parent = dev->dev;
i2c_set_adapdata(adap, dev);
--
2.11.0
^ permalink raw reply related
* [PATCH 03/12] i2c: mxs: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 642c58946d8d..7d79317a1046 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -567,9 +567,6 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg,
dev_dbg(i2c->dev, "addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n",
msg->addr, msg->len, msg->flags, stop);
- if (msg->len == 0)
- return -EINVAL;
-
/*
* The MX28 I2C IP block can only do PIO READ for transfer of to up
* 4 bytes of length. The write transfer is not limited as it can use
@@ -683,6 +680,10 @@ static const struct i2c_algorithm mxs_i2c_algo = {
.functionality = mxs_i2c_func,
};
+static const struct i2c_adapter_quirks mxs_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static void mxs_i2c_derive_timing(struct mxs_i2c_dev *i2c, uint32_t speed)
{
/* The I2C block clock runs at 24MHz */
@@ -854,6 +855,7 @@ static int mxs_i2c_probe(struct platform_device *pdev)
strlcpy(adap->name, "MXS I2C adapter", sizeof(adap->name));
adap->owner = THIS_MODULE;
adap->algo = &mxs_i2c_algo;
+ adap->quirks = &mxs_i2c_quirks;
adap->dev.parent = dev;
adap->nr = pdev->id;
adap->dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
* [PATCH 04/12] i2c: omap: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Tony Lindgren, Aaro Koskinen,
linux-omap, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-omap.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 65d06a819307..b1086bfb0465 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -661,9 +661,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev_dbg(omap->dev, "addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n",
msg->addr, msg->len, msg->flags, stop);
- if (msg->len == 0)
- return -EINVAL;
-
omap->receiver = !!(msg->flags & I2C_M_RD);
omap_i2c_resize_fifo(omap, msg->len, omap->receiver);
@@ -1179,6 +1176,10 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
+static const struct i2c_adapter_quirks omap_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap2420_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
@@ -1453,6 +1454,7 @@ omap_i2c_probe(struct platform_device *pdev)
adap->class = I2C_CLASS_DEPRECATED;
strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name));
adap->algo = &omap_i2c_algo;
+ adap->quirks = &omap_i2c_quirks;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
adap->bus_recovery_info = &omap_i2c_bus_recovery_info;
--
2.11.0
^ permalink raw reply related
* [PATCH 05/12] i2c: pmcmsp: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pmcmsp.c b/drivers/i2c/busses/i2c-pmcmsp.c
index dae8ac618a52..0829cb696d9d 100644
--- a/drivers/i2c/busses/i2c-pmcmsp.c
+++ b/drivers/i2c/busses/i2c-pmcmsp.c
@@ -444,16 +444,6 @@ static enum pmcmsptwi_xfer_result pmcmsptwi_xfer_cmd(
{
enum pmcmsptwi_xfer_result retval;
- if ((cmd->type == MSP_TWI_CMD_WRITE && cmd->write_len == 0) ||
- (cmd->type == MSP_TWI_CMD_READ && cmd->read_len == 0) ||
- (cmd->type == MSP_TWI_CMD_WRITE_READ &&
- (cmd->read_len == 0 || cmd->write_len == 0))) {
- dev_err(&pmcmsptwi_adapter.dev,
- "%s: Cannot transfer less than 1 byte\n",
- __func__);
- return -EINVAL;
- }
-
mutex_lock(&data->lock);
dev_dbg(&pmcmsptwi_adapter.dev,
"Setting address to 0x%04x\n", cmd->addr);
@@ -532,11 +522,6 @@ static int pmcmsptwi_master_xfer(struct i2c_adapter *adap,
cmd.write_data = msg->buf;
}
- if (msg->len == 0) {
- dev_err(&adap->dev, "Zero-byte messages unsupported\n");
- return -EINVAL;
- }
-
cmd.addr = msg->addr;
if (msg->flags & I2C_M_TEN) {
@@ -578,7 +563,7 @@ static u32 pmcmsptwi_i2c_func(struct i2c_adapter *adapter)
}
static const struct i2c_adapter_quirks pmcmsptwi_i2c_quirks = {
- .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ | I2C_AQ_NO_ZERO_LEN,
.max_write_len = MSP_MAX_BYTES_PER_RW,
.max_read_len = MSP_MAX_BYTES_PER_RW,
.max_comb_1st_msg_len = MSP_MAX_BYTES_PER_RW,
--
2.11.0
^ permalink raw reply related
* [PATCH 06/12] i2c: qup: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Andy Gross, David Brown,
linux-arm-msm, linux-soc, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index c86c3ae1318f..e09cd0775ae9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -1088,11 +1088,6 @@ static int qup_i2c_xfer(struct i2c_adapter *adap,
writel(I2C_MINI_CORE | I2C_N_VAL, qup->base + QUP_CONFIG);
for (idx = 0; idx < num; idx++) {
- if (msgs[idx].len == 0) {
- ret = -EINVAL;
- goto out;
- }
-
if (qup_i2c_poll_state_i2c_master(qup)) {
ret = -EIO;
goto out;
@@ -1520,9 +1515,6 @@ qup_i2c_determine_mode_v2(struct qup_i2c_dev *qup,
/* All i2c_msgs should be transferred using either dma or cpu */
for (idx = 0; idx < num; idx++) {
- if (msgs[idx].len == 0)
- return -EINVAL;
-
if (msgs[idx].flags & I2C_M_RD)
max_rx_len = max_t(unsigned int, max_rx_len,
msgs[idx].len);
@@ -1636,9 +1628,14 @@ static const struct i2c_algorithm qup_i2c_algo_v2 = {
* which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
*/
static const struct i2c_adapter_quirks qup_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
.max_read_len = QUP_READ_LIMIT,
};
+static const struct i2c_adapter_quirks qup_i2c_quirks_v2 = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static void qup_i2c_enable_clocks(struct qup_i2c_dev *qup)
{
clk_prepare_enable(qup->clk);
@@ -1701,6 +1698,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
is_qup_v1 = true;
} else {
qup->adap.algo = &qup_i2c_algo_v2;
+ qup->adap.quirks = &qup_i2c_quirks_v2;
is_qup_v1 = false;
if (acpi_match_device(qup_i2c_acpi_match, qup->dev))
goto nodma;
--
2.11.0
^ permalink raw reply related
* [PATCH 07/12] i2c: stu300: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Linus Walleij, linux-arm-kernel,
linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index fce52bdab2b7..5503fa171df0 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -673,12 +673,6 @@ static int stu300_xfer_msg(struct i2c_adapter *adap,
msg->addr, msg->len, msg->flags, stop);
}
- /* Zero-length messages are not supported by this hardware */
- if (msg->len == 0) {
- ret = -EINVAL;
- goto exit_disable;
- }
-
/*
* For some reason, sending the address sometimes fails when running
* on the 13 MHz clock. No interrupt arrives. This is a work around,
@@ -863,6 +857,10 @@ static const struct i2c_algorithm stu300_algo = {
.functionality = stu300_func,
};
+static const struct i2c_adapter_quirks stu300_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static int stu300_probe(struct platform_device *pdev)
{
struct stu300_dev *dev;
@@ -920,6 +918,8 @@ static int stu300_probe(struct platform_device *pdev)
adap->algo = &stu300_algo;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
+ adap->quirks = &stu300_quirks;
+
i2c_set_adapdata(adap, dev);
/* i2c device drivers may be active on return from add_adapter() */
--
2.11.0
^ permalink raw reply related
* [PATCH 07/12] i2c: stu300: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index fce52bdab2b7..5503fa171df0 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -673,12 +673,6 @@ static int stu300_xfer_msg(struct i2c_adapter *adap,
msg->addr, msg->len, msg->flags, stop);
}
- /* Zero-length messages are not supported by this hardware */
- if (msg->len == 0) {
- ret = -EINVAL;
- goto exit_disable;
- }
-
/*
* For some reason, sending the address sometimes fails when running
* on the 13 MHz clock. No interrupt arrives. This is a work around,
@@ -863,6 +857,10 @@ static const struct i2c_algorithm stu300_algo = {
.functionality = stu300_func,
};
+static const struct i2c_adapter_quirks stu300_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static int stu300_probe(struct platform_device *pdev)
{
struct stu300_dev *dev;
@@ -920,6 +918,8 @@ static int stu300_probe(struct platform_device *pdev)
adap->algo = &stu300_algo;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
+ adap->quirks = &stu300_quirks;
+
i2c_set_adapdata(adap, dev);
/* i2c device drivers may be active on return from add_adapter() */
--
2.11.0
^ permalink raw reply related
* [PATCH 08/12] i2c: tegra: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Laxman Dewangan, Thierry Reding,
Jonathan Hunter, linux-tegra, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-tegra.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 60c8561fbe65..437294ea2f0a 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -684,9 +684,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
tegra_i2c_flush_fifos(i2c_dev);
- if (msg->len == 0)
- return -EINVAL;
-
i2c_dev->msg_buf = msg->buf;
i2c_dev->msg_buf_remaining = msg->len;
i2c_dev->msg_err = I2C_ERR_NONE;
@@ -831,6 +828,7 @@ static const struct i2c_algorithm tegra_i2c_algo = {
/* payload size is only 12 bit */
static const struct i2c_adapter_quirks tegra_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
.max_read_len = 4096,
.max_write_len = 4096,
};
--
2.11.0
^ permalink raw reply related
* [PATCH 09/12] i2c: zx2967: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-kernel, linux-renesas-soc, Wolfram Sang, Jun Nie,
Baoyou Xie, Shawn Guo, linux-arm-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
index 48281c1b30c6..b8f9e020d80e 100644
--- a/drivers/i2c/busses/i2c-zx2967.c
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -281,9 +281,6 @@ static int zx2967_i2c_xfer_msg(struct zx2967_i2c *i2c,
int ret;
int i;
- if (msg->len == 0)
- return -EINVAL;
-
zx2967_i2c_flush_fifos(i2c);
i2c->cur_trans = msg->buf;
@@ -498,6 +495,10 @@ static const struct i2c_algorithm zx2967_i2c_algo = {
.functionality = zx2967_i2c_func,
};
+static const struct i2c_adapter_quirks zx2967_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct of_device_id zx2967_i2c_of_match[] = {
{ .compatible = "zte,zx296718-i2c", },
{ },
@@ -568,6 +569,7 @@ static int zx2967_i2c_probe(struct platform_device *pdev)
strlcpy(i2c->adap.name, "zx2967 i2c adapter",
sizeof(i2c->adap.name));
i2c->adap.algo = &zx2967_i2c_algo;
+ i2c->adap.quirks = &zx2967_i2c_quirks;
i2c->adap.nr = pdev->id;
i2c->adap.dev.parent = &pdev->dev;
i2c->adap.dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
* [PATCH 09/12] i2c: zx2967: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
index 48281c1b30c6..b8f9e020d80e 100644
--- a/drivers/i2c/busses/i2c-zx2967.c
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -281,9 +281,6 @@ static int zx2967_i2c_xfer_msg(struct zx2967_i2c *i2c,
int ret;
int i;
- if (msg->len == 0)
- return -EINVAL;
-
zx2967_i2c_flush_fifos(i2c);
i2c->cur_trans = msg->buf;
@@ -498,6 +495,10 @@ static const struct i2c_algorithm zx2967_i2c_algo = {
.functionality = zx2967_i2c_func,
};
+static const struct i2c_adapter_quirks zx2967_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct of_device_id zx2967_i2c_of_match[] = {
{ .compatible = "zte,zx296718-i2c", },
{ },
@@ -568,6 +569,7 @@ static int zx2967_i2c_probe(struct platform_device *pdev)
strlcpy(i2c->adap.name, "zx2967 i2c adapter",
sizeof(i2c->adap.name));
i2c->adap.algo = &zx2967_i2c_algo;
+ i2c->adap.quirks = &zx2967_i2c_quirks;
i2c->adap.nr = pdev->id;
i2c->adap.dev.parent = &pdev->dev;
i2c->adap.dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
* [PATCH 10/12] i2c: rcar: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-rcar.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 2688520110d1..791a4aa34fdd 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -796,14 +796,8 @@ static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
if (ret < 0)
goto out;
- for (i = 0; i < num; i++) {
- /* This HW can't send STOP after address phase */
- if (msgs[i].len == 0) {
- ret = -EOPNOTSUPP;
- goto out;
- }
+ for (i = 0; i < num; i++)
rcar_i2c_request_dma(priv, msgs + i);
- }
/* init first message */
priv->msg = msgs;
@@ -890,6 +884,10 @@ static const struct i2c_algorithm rcar_i2c_algo = {
.unreg_slave = rcar_unreg_slave,
};
+static const struct i2c_adapter_quirks rcar_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
@@ -943,6 +941,7 @@ static int rcar_i2c_probe(struct platform_device *pdev)
adap->dev.parent = dev;
adap->dev.of_node = dev->of_node;
adap->bus_recovery_info = &rcar_i2c_bri;
+ adap->quirks = &rcar_i2c_quirks;
i2c_set_adapdata(adap, priv);
strlcpy(adap->name, pdev->name, sizeof(adap->name));
--
2.11.0
^ permalink raw reply related
* [PATCH 11/12] i2c: xlr: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-xlr.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-xlr.c b/drivers/i2c/busses/i2c-xlr.c
index 484bfa15d58e..34cd4b308540 100644
--- a/drivers/i2c/busses/i2c-xlr.c
+++ b/drivers/i2c/busses/i2c-xlr.c
@@ -173,9 +173,6 @@ static int xlr_i2c_tx(struct xlr_i2c_private *priv, u16 len,
u8 offset;
u32 xfer;
- if (!len)
- return -EOPNOTSUPP;
-
offset = buf[0];
xlr_i2c_wreg(priv->iobase, XLR_I2C_ADDR, offset);
xlr_i2c_wreg(priv->iobase, XLR_I2C_DEVADDR, addr);
@@ -241,9 +238,6 @@ static int xlr_i2c_rx(struct xlr_i2c_private *priv, u16 len, u8 *buf, u16 addr)
unsigned long timeout, stoptime, checktime;
int nbytes, timedout;
- if (!len)
- return -EOPNOTSUPP;
-
xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG,
XLR_I2C_CFG_NOADDR | priv->cfg->cfg_extra);
xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 1);
@@ -340,6 +334,10 @@ static const struct i2c_algorithm xlr_i2c_algo = {
.functionality = xlr_func,
};
+static const struct i2c_adapter_quirks xlr_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct xlr_i2c_config xlr_i2c_config_default = {
.status_busy = XLR_I2C_BUS_BUSY,
.cfg_extra = 0,
@@ -427,6 +425,7 @@ static int xlr_i2c_probe(struct platform_device *pdev)
priv->adap.owner = THIS_MODULE;
priv->adap.algo_data = priv;
priv->adap.algo = &xlr_i2c_algo;
+ priv->adap.quirks = &xlr_i2c_quirks;
priv->adap.nr = pdev->id;
priv->adap.class = I2C_CLASS_HWMON;
snprintf(priv->adap.name, sizeof(priv->adap.name), "xlr-i2c");
--
2.11.0
^ permalink raw reply related
* [PATCH 12/12] i2c: sh_mobile: use core to detect 'no zero length read' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 5fda4188a9e5..9c7f6f8ceb22 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -613,11 +613,6 @@ static void sh_mobile_i2c_xfer_dma(struct sh_mobile_i2c_data *pd)
static int start_ch(struct sh_mobile_i2c_data *pd, struct i2c_msg *usr_msg,
bool do_init)
{
- if (usr_msg->len == 0 && (usr_msg->flags & I2C_M_RD)) {
- dev_err(pd->dev, "Unsupported zero length i2c read\n");
- return -EOPNOTSUPP;
- }
-
if (do_init) {
/* Initialize channel registers */
iic_wr(pd, ICCR, ICCR_SCP);
@@ -758,6 +753,10 @@ static const struct i2c_algorithm sh_mobile_i2c_algorithm = {
.master_xfer = sh_mobile_i2c_xfer,
};
+static const struct i2c_adapter_quirks sh_mobile_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN_READ,
+};
+
/*
* r8a7740 chip has lasting errata on I2C I/O pad reset.
* this is work-around for it.
@@ -925,6 +924,7 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
adap->owner = THIS_MODULE;
adap->algo = &sh_mobile_i2c_algorithm;
+ adap->quirks = &sh_mobile_i2c_quirks;
adap->dev.parent = &dev->dev;
adap->retries = 5;
adap->nr = dev->id;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
From: David Rientjes @ 2018-07-23 20:28 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Yang Shi, Andrew Morton, kirill, hughd, aaron.lu, linux-mm,
linux-kernel
In-Reply-To: <20180722035156.GA12125@bombadil.infradead.org>
On Sat, 21 Jul 2018, Matthew Wilcox wrote:
> > The huge zero page can be reclaimed under memory pressure and, if it is,
> > it is attempted to be allocted again with gfp flags that attempt memory
> > compaction that can become expensive. If we are constantly under memory
> > pressure, it gets freed and reallocated millions of times always trying to
> > compact memory both directly and by kicking kcompactd in the background.
> >
> > It likely should also be per node.
>
> Have you benchmarked making the non-huge zero page per-node?
>
Not since we disable it :) I will, though. The more concerning issue for
us, modulo CVE-2017-1000405, is the cpu cost of constantly directly
compacting memory for allocating the hzp in real time after it has been
reclaimed. We've observed this happening tens or hundreds of thousands
of times on some systems. It will be 2MB per node on x86 if the data
suggests we should make it NUMA aware, I don't think the cost is too high
to leave it persistently available even under memory pressure if
use_zero_page is enabled.
^ permalink raw reply
* To remove packages from busybox
From: Simon Chamlian @ 2018-07-23 20:29 UTC (permalink / raw)
To: Yocto discussion list
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
Hi,
In order to remove package from busybox, I used:
$ bitbake -c menuconfig busybox
Under 'System Logging Itilities -->' I unchecked *syslogd*
Then ran
$ bitbake busybox
and I get the following error:
WARNING: busybox-1.24.1-r0 do_package: busybox: alternative target
(/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist, skipping...
WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative
provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist
ERROR: busybox-1.24.1-r0 do_package: SYSTEMD_SERVICE_busybox-syslog value
busybox-syslog.service does not exist
ERROR: busybox-1.24.1-r0 do_package: Function failed:
systemd_populate_packages
ERROR: Logfile of failure stored in:
/opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.30881
ERROR: Task
(/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_package)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 711 tasks of which 705 didn't need to be
rerun and 1 failed.
What am I doing wrong?
Thanks,
S
[-- Attachment #2: Type: text/html, Size: 3410 bytes --]
^ permalink raw reply
* [Fuego] Kyiv Fashion 2018
From: Frances Parker @ 2018-07-23 20:30 UTC (permalink / raw)
To: fuego
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hi,
Hope you are doing well!
I wanted to check whether you would be interested in purchasing the Kyiv
Fashion 2018, 34th International Festival of Vogue 2018 Attendees List?
Which includes complete contact information up to date?
Target Criteria:
ü Fashion
ü Underwear
ü Apparel
ü Clothing
ü Textile
ü Leather
ü Fur
If you’re interested please let me know I will assist you with counts and
pricing details.
Just WhatsApp the Target, you will get instant response, we are active 24/7
to help you
WhatsApp number +1 518-418-5838
Awaiting for your response.
With Regards,
Frances Parker
Marketing Coordinator.
[-- Attachment #2: Type: text/html, Size: 7272 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
From: David Rientjes @ 2018-07-23 20:31 UTC (permalink / raw)
To: Yang Shi
Cc: Kirill A. Shutemov, hughd, aaron.lu, akpm, linux-mm, linux-kernel
In-Reply-To: <3118b646-681e-a2aa-dc7b-71d4821fa50f@linux.alibaba.com>
On Fri, 20 Jul 2018, Yang Shi wrote:
> I agree to keep it for a while to let that security bug cool down, however, if
> there is no user anymore, it sounds pointless to still keep a dead knob.
>
It's not a dead knob. We use it, and for reasons other than
CVE-2017-1000405. To mitigate the cost of constantly compacting memory to
allocate it after it has been freed due to memry pressure, we can either
continue to disable it, allow it to be persistently available, or use a
new value for use_zero_page to specify it should be persistently
available.
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-next-queue:XDP-hints-EXPERIMENTAL] BUILD SUCCESS 58e0270bb7ac94a31ff0fe372385cfce4198b56c
From: kbuild test robot @ 2018-07-23 20:31 UTC (permalink / raw)
To: intel-wired-lan
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git XDP-hints-EXPERIMENTAL
branch HEAD: 58e0270bb7ac94a31ff0fe372385cfce4198b56c i40e: Initial support to add hw hints for xdp
elapsed time: 90m
configs tested: 121
The following configs have been built successfully.
More configs may be tested in the coming days.
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
i386 randconfig-n0-201829
i386 randconfig-i0-201829
i386 randconfig-i1-201829
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
x86_64 randconfig-x018-201829
x86_64 randconfig-x011-201829
x86_64 randconfig-x015-201829
x86_64 randconfig-x019-201829
x86_64 randconfig-x014-201829
x86_64 randconfig-x010-201829
x86_64 randconfig-x013-201829
x86_64 randconfig-x016-201829
x86_64 randconfig-x017-201829
x86_64 randconfig-x012-201829
i386 randconfig-a0-201829
i386 randconfig-a1-201829
openrisc or1ksim_defconfig
um i386_defconfig
um x86_64_defconfig
i386 alldefconfig
i386 allnoconfig
i386 defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
i386 randconfig-s0-201829
i386 randconfig-s1-201829
x86_64 allmodconfig
i386 allmodconfig
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
x86_64 randconfig-i0-201829
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
nios2 10m50_defconfig
xtensa common_defconfig
xtensa iss_defconfig
i386 tinyconfig
i386 randconfig-x012-201829
i386 randconfig-x017-201829
i386 randconfig-x014-201829
i386 randconfig-x016-201829
i386 randconfig-x013-201829
i386 randconfig-x011-201829
i386 randconfig-x018-201829
i386 randconfig-x010-201829
i386 randconfig-x015-201829
i386 randconfig-x019-201829
i386 randconfig-x078-201829
i386 randconfig-x070-201829
i386 randconfig-x075-201829
i386 randconfig-x076-201829
i386 randconfig-x074-201829
i386 randconfig-x079-201829
i386 randconfig-x071-201829
i386 randconfig-x073-201829
i386 randconfig-x072-201829
i386 randconfig-x077-201829
x86_64 randconfig-x007-201829
x86_64 randconfig-x003-201829
x86_64 randconfig-x000-201829
x86_64 randconfig-x005-201829
x86_64 randconfig-x004-201829
x86_64 randconfig-x008-201829
x86_64 randconfig-x001-201829
x86_64 randconfig-x009-201829
x86_64 randconfig-x002-201829
x86_64 randconfig-x006-201829
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm64 defconfig
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
x86_64 kexec
x86_64 kexec-CONFIG_DEBUG_INFO_REDUCED
x86_64 rhel
x86_64 rhel-7.2
x86_64 fedora-25
i386 randconfig-x008-201829
i386 randconfig-x009-201829
i386 randconfig-x005-201829
i386 randconfig-x000-201829
i386 randconfig-x003-201829
i386 randconfig-x001-201829
i386 randconfig-x004-201829
i386 randconfig-x006-201829
i386 randconfig-x007-201829
i386 randconfig-x002-201829
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH BlueZ] tools: Fix btmon-logger service unit
From: Andrzej Kaczmarek @ 2018-07-23 20:31 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
Bluetooth sockets can be only created in initial network namespace thus
btmon-logger will fail to open monitor socket with PrivateNetwork=true
since this sets up new network namespace for created process.
---
tools/bluetooth-logger.service.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/bluetooth-logger.service.in b/tools/bluetooth-logger.service.in
index 210bf59ac..026a2f130 100644
--- a/tools/bluetooth-logger.service.in
+++ b/tools/bluetooth-logger.service.in
@@ -12,7 +12,6 @@ ProtectHome=true
ProtectSystem=full
PrivateTmp=true
PrivateDevices=true
-PrivateNetwork=true
[Install]
WantedBy=bluetooth.target
--
2.18.0
^ 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.