[PATCH linux-next] driver/gpu: Fix mismatch in funciton argument type
Fix the following warning:
drivers/gpu/drm/nouveau/dispnv50/wndw.c:570:1: error: symbol 'nv50_wndw_new_'
redeclared with different type
(originally declared at drivers/gpu/drm/nouveau/dispnv50/wndw.h:39) -
incompatible argument 7 (different signedness)
Signed-off-by: zhong jiang
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index b0b6428..0770683 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -38,8 +38,8 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads, enum nv50_disp_interlock_type,
+ u32 interlock_data, struct nv50_wndw **);
void nv50_wndw_init(struct nv50_wndw *);
void nv50_wndw_fini(struct nv50_wndw *);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
--
1.7.12.4
[PATCH linux-next] driver/gpu: Fix mismatch in funciton argument type
Fix the following warning:
drivers/gpu/drm/nouveau/dispnv50/wndw.c:570:1: error: symbol 'nv50_wndw_new_'
redeclared with different type
(originally declared at drivers/gpu/drm/nouveau/dispnv50/wndw.h:39) -
incompatible argument 7 (different signedness)
Signed-off-by: zhong jiang
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index b0b6428..0770683 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -38,8 +38,8 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads, enum nv50_disp_interlock_type,
+ u32 interlock_data, struct nv50_wndw **);
void nv50_wndw_init(struct nv50_wndw *);
void nv50_wndw_fini(struct nv50_wndw *);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
--
1.7.12.4
Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
On Sat, 21 Jul 2018 12:26:10 -0400 William Breathitt Gray wrote: > >Also, many many drivers deal with signals-as-an-electrical-thing - is > >it appropriate for this particular driver to take that namespace? > > In the context of the Generic Counter paradigm, a "Signal" is an > abstraction for the stream of data that is fed to the counter device for > evaluation (triggering updates for the readable "Count"). In many cases > a "Signal" correlates with a physical electrical line (for example the A > and B electrical lines for a quadrature encoder), but this isn't a hard > requirement as the paradigm permits more abstract data streams. > > I decided on "Signal" to match the naming convention that appears in the > datasheets of many counter devices, but "Line" may be a decent > alternative name we could use to indicate a counter device input data > stream. > > I'd like to get some other opinions as well before I make a naming > change to "Signal" -- whether to stay with "Signal," switch to "Line," or > rename to something else. For what it's worth, I think it's unlikely for > a counter device driver author to confuse a Counter Signal with the > Linux OS signal within the context of the Generic Counter paradigm and > their respective counter device datasheet. gc_signal_* would be better. That retains "signal", but makes it clear that the symbols belong to generic counter.
Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
On Sat, 21 Jul 2018 12:26:10 -0400 William Breathitt Gray wrote: > >Also, many many drivers deal with signals-as-an-electrical-thing - is > >it appropriate for this particular driver to take that namespace? > > In the context of the Generic Counter paradigm, a "Signal" is an > abstraction for the stream of data that is fed to the counter device for > evaluation (triggering updates for the readable "Count"). In many cases > a "Signal" correlates with a physical electrical line (for example the A > and B electrical lines for a quadrature encoder), but this isn't a hard > requirement as the paradigm permits more abstract data streams. > > I decided on "Signal" to match the naming convention that appears in the > datasheets of many counter devices, but "Line" may be a decent > alternative name we could use to indicate a counter device input data > stream. > > I'd like to get some other opinions as well before I make a naming > change to "Signal" -- whether to stay with "Signal," switch to "Line," or > rename to something else. For what it's worth, I think it's unlikely for > a counter device driver author to confuse a Counter Signal with the > Linux OS signal within the context of the Generic Counter paradigm and > their respective counter device datasheet. gc_signal_* would be better. That retains "signal", but makes it clear that the symbols belong to generic counter.
[PATCH linux-next] kernel/exit: fix mismatch in function argument types
Fix following warning: kernel/exit.c:1634:6: error: symbol 'kernel_wait4' redeclared with different type (originally declared at ./include/linux/sched/task.h:78) - incompatible argument 2 (different address spaces) Signed-off-by: zhong jiang --- include/linux/sched/task.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h index 5be31eb..108ede9 100644 --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -75,7 +75,7 @@ static inline void exit_thread(struct task_struct *tsk) extern long do_fork(unsigned long, unsigned long, unsigned long, int __user *, int __user *); struct task_struct *fork_idle(int); extern pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags); -extern long kernel_wait4(pid_t, int *, int, struct rusage *); +extern long kernel_wait4(pid_t, int __user *, int, struct rusage *); extern void free_task(struct task_struct *tsk); -- 1.7.12.4
[PATCH linux-next] kernel/exit: fix mismatch in function argument types
Fix following warning: kernel/exit.c:1634:6: error: symbol 'kernel_wait4' redeclared with different type (originally declared at ./include/linux/sched/task.h:78) - incompatible argument 2 (different address spaces) Signed-off-by: zhong jiang --- include/linux/sched/task.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h index 5be31eb..108ede9 100644 --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -75,7 +75,7 @@ static inline void exit_thread(struct task_struct *tsk) extern long do_fork(unsigned long, unsigned long, unsigned long, int __user *, int __user *); struct task_struct *fork_idle(int); extern pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags); -extern long kernel_wait4(pid_t, int *, int, struct rusage *); +extern long kernel_wait4(pid_t, int __user *, int, struct rusage *); extern void free_task(struct task_struct *tsk); -- 1.7.12.4
Re: [PATCH v2 12/12] sched/core: uclamp: use percentage clamp values
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> The utilization is a well defined property of tasks and CPUs with an
> in-kernel representation based on power-of-two values.
> The current representation, in the [0..SCHED_CAPACITY_SCALE] range,
> allows efficient computations in hot-paths and a sufficient fixed point
> arithmetic precision.
> However, the utilization values range is still an implementation detail
> which is also possibly subject to changes in the future.
>
> Since we don't want to commit new user-space APIs to any in-kernel
> implementation detail, let's add an abstraction layer on top of the APIs
> used by util_clamp, i.e. sched_{set,get}attr syscalls and the cgroup's
> cpu.util_{min,max} attributes.
>
> We do that by adding a couple of conversion function which can be used
couple of conversion functions
> to conveniently transform utilization/capacity values from/to the internal
> SCHED_FIXEDPOINT_SCALE representation to/from a more generic percentage
> in the standard [0..100] range.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Rafael J. Wysocki
> Cc: Paul Turner
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
> Documentation/admin-guide/cgroup-v2.rst | 6 +++---
> include/linux/sched.h | 20
> include/uapi/linux/sched/types.h| 14 --
> kernel/sched/core.c | 18 --
> 4 files changed, 43 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index 328c011cc105..08b8062e55cd 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -973,7 +973,7 @@ All time durations are in microseconds.
> A read-write single value file which exists on non-root cgroups.
> The default is "0", i.e. no bandwidth boosting.
>
> -The minimum utilization in the range [0, 1023].
> +The minimum percentage of utilization in the range [0, 100].
>
> This interface allows reading and setting minimum utilization clamp
> values similar to the sched_setattr(2). This minimum utilization
> @@ -981,9 +981,9 @@ All time durations are in microseconds.
>
>cpu.util_max
> A read-write single value file which exists on non-root cgroups.
> -The default is "1023". i.e. no bandwidth clamping
> +The default is "100". i.e. no bandwidth clamping
>
> -The maximum utilization in the range [0, 1023].
> +The maximum percentage of utilization in the range [0, 100].
>
> This interface allows reading and setting maximum utilization clamp
> values similar to the sched_setattr(2). This maximum utilization
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5dd76a27ec17..f5970903c187 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -321,6 +321,26 @@ struct sched_info {
> # define SCHED_FIXEDPOINT_SHIFT10
> # define SCHED_FIXEDPOINT_SCALE(1L << SCHED_FIXEDPOINT_SHIFT)
>
> +static inline unsigned int scale_from_percent(unsigned int pct)
> +{
> + WARN_ON(pct > 100);
> +
> + return ((SCHED_FIXEDPOINT_SCALE * pct) / 100);
> +}
> +
> +static inline unsigned int scale_to_percent(unsigned int value)
> +{
> + unsigned int rounding = 0;
> +
> + WARN_ON(value > SCHED_FIXEDPOINT_SCALE);
> +
> + /* Compensate rounding errors for: 0, 256, 512, 768, 1024 */
> + if (likely((value & 0xFF) && ~(value & 0x700)))
> + rounding = 1;
Hmm. I don't think ~(value & 0x700) will ever yield FALSE... What am I missing?
> +
> + return (rounding + ((100 * value) / SCHED_FIXEDPOINT_SCALE));
> +}
> +
> struct load_weight {
> unsigned long weight;
> u32 inv_weight;
> diff --git a/include/uapi/linux/sched/types.h
> b/include/uapi/linux/sched/types.h
> index 7421cd25354d..e2c2acb1c6af 100644
> --- a/include/uapi/linux/sched/types.h
> +++ b/include/uapi/linux/sched/types.h
> @@ -84,15 +84,17 @@ struct sched_param {
> *
> * @sched_util_minrepresents the minimum utilization
> * @sched_util_maxrepresents the maximum utilization
> + * @sched_util_minrepresents the minimum utilization percentage
> + * @sched_util_maxrepresents the maximum utilization percentage
> *
> - * Utilization is a value in the range [0..SCHED_CAPACITY_SCALE] which
> - * represents the percentage of CPU time used by a task when running at the
> - * maximum frequency on the highest capacity CPU of the system. Thus, for
> - * example, a 20% utilization task is a task running for 2ms every 10ms.
> + * Utilization is a value in the range [0..100] which represents the
> + * percentage of CPU time
Re: [PATCH v2 12/12] sched/core: uclamp: use percentage clamp values
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> The utilization is a well defined property of tasks and CPUs with an
> in-kernel representation based on power-of-two values.
> The current representation, in the [0..SCHED_CAPACITY_SCALE] range,
> allows efficient computations in hot-paths and a sufficient fixed point
> arithmetic precision.
> However, the utilization values range is still an implementation detail
> which is also possibly subject to changes in the future.
>
> Since we don't want to commit new user-space APIs to any in-kernel
> implementation detail, let's add an abstraction layer on top of the APIs
> used by util_clamp, i.e. sched_{set,get}attr syscalls and the cgroup's
> cpu.util_{min,max} attributes.
>
> We do that by adding a couple of conversion function which can be used
couple of conversion functions
> to conveniently transform utilization/capacity values from/to the internal
> SCHED_FIXEDPOINT_SCALE representation to/from a more generic percentage
> in the standard [0..100] range.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Rafael J. Wysocki
> Cc: Paul Turner
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
> Documentation/admin-guide/cgroup-v2.rst | 6 +++---
> include/linux/sched.h | 20
> include/uapi/linux/sched/types.h| 14 --
> kernel/sched/core.c | 18 --
> 4 files changed, 43 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index 328c011cc105..08b8062e55cd 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -973,7 +973,7 @@ All time durations are in microseconds.
> A read-write single value file which exists on non-root cgroups.
> The default is "0", i.e. no bandwidth boosting.
>
> -The minimum utilization in the range [0, 1023].
> +The minimum percentage of utilization in the range [0, 100].
>
> This interface allows reading and setting minimum utilization clamp
> values similar to the sched_setattr(2). This minimum utilization
> @@ -981,9 +981,9 @@ All time durations are in microseconds.
>
>cpu.util_max
> A read-write single value file which exists on non-root cgroups.
> -The default is "1023". i.e. no bandwidth clamping
> +The default is "100". i.e. no bandwidth clamping
>
> -The maximum utilization in the range [0, 1023].
> +The maximum percentage of utilization in the range [0, 100].
>
> This interface allows reading and setting maximum utilization clamp
> values similar to the sched_setattr(2). This maximum utilization
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5dd76a27ec17..f5970903c187 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -321,6 +321,26 @@ struct sched_info {
> # define SCHED_FIXEDPOINT_SHIFT10
> # define SCHED_FIXEDPOINT_SCALE(1L << SCHED_FIXEDPOINT_SHIFT)
>
> +static inline unsigned int scale_from_percent(unsigned int pct)
> +{
> + WARN_ON(pct > 100);
> +
> + return ((SCHED_FIXEDPOINT_SCALE * pct) / 100);
> +}
> +
> +static inline unsigned int scale_to_percent(unsigned int value)
> +{
> + unsigned int rounding = 0;
> +
> + WARN_ON(value > SCHED_FIXEDPOINT_SCALE);
> +
> + /* Compensate rounding errors for: 0, 256, 512, 768, 1024 */
> + if (likely((value & 0xFF) && ~(value & 0x700)))
> + rounding = 1;
Hmm. I don't think ~(value & 0x700) will ever yield FALSE... What am I missing?
> +
> + return (rounding + ((100 * value) / SCHED_FIXEDPOINT_SCALE));
> +}
> +
> struct load_weight {
> unsigned long weight;
> u32 inv_weight;
> diff --git a/include/uapi/linux/sched/types.h
> b/include/uapi/linux/sched/types.h
> index 7421cd25354d..e2c2acb1c6af 100644
> --- a/include/uapi/linux/sched/types.h
> +++ b/include/uapi/linux/sched/types.h
> @@ -84,15 +84,17 @@ struct sched_param {
> *
> * @sched_util_minrepresents the minimum utilization
> * @sched_util_maxrepresents the maximum utilization
> + * @sched_util_minrepresents the minimum utilization percentage
> + * @sched_util_maxrepresents the maximum utilization percentage
> *
> - * Utilization is a value in the range [0..SCHED_CAPACITY_SCALE] which
> - * represents the percentage of CPU time used by a task when running at the
> - * maximum frequency on the highest capacity CPU of the system. Thus, for
> - * example, a 20% utilization task is a task running for 2ms every 10ms.
> + * Utilization is a value in the range [0..100] which represents the
> + * percentage of CPU time
Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
On Fri, Jul 20, 2018 at 02:05:52PM -0700, David Rientjes 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?
Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
On Fri, Jul 20, 2018 at 02:05:52PM -0700, David Rientjes 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?
HELLO.
HELLO. This might come to you as a surprise, especially since we have never met or discuss before, basically the message might sound strange but it is factual in reality if only you care to listen to me. The truth is that I should have notified you first through a more confidential means, (even if it's at least to respect your integrity) please accept my humble apologies if I Had caught you unawares, I frankly do not mean any harm in passing my message. For security reason and also due to what is happening all over the internet now are days, please the details of my personality and that of my late husband will be directed to you via my private email as soon as I receive your response to my request below. I am woman and i am undergoing medical treatment at moment. I married to a lovely and gentle man who worked with JAPAN embassy in NAIROBI KENYA for nine years before he died in 2014. He died after a brief illness, I decided not to re-marry or get a child outside my matrimonial home. When my late husband was alive he deposited some amount of U.S. Dollars) in a Finance/Bank. Presently, this money is still with the Finance/Bank. What is actually disturbing me now is my stroke, Having known my condition I decided to donate this fund to church or better still a Christian/individual that will utilize this money the way I am going to instruct here in. I want you to use this funds help the widows, orphanage. I took this decision because I don't have any child that will inherit the money and my husband relatives are not Christians Nor Muslims, and I don't want my husband's hard earned money to be misused. I don't want situation where this money will be used in an ungodly manner, hence the reason for taking this bold decision. Please, for now i don't need any telephone communication in this regard because of my health, and because of the presence of my husband's relatives around me always. I don't want them to know about this development. As soon as I receive your reply I shall give you the contact of the Finance/Bank. I shall also send a letter of authority to the Bank that will empower you as the original- beneficiary of this fund. Please, if you do not have confidence in this message, kindly delete it and accept my sincere apology for contacting you in this manner. And any delay in your reply will give me room in sourcing for a church or Christian individual for this same purpose. Please assure me that you will act accordingly as I stated herein. Hope to hear from you. Remain blessed in the name of the Lord
HELLO.
HELLO. This might come to you as a surprise, especially since we have never met or discuss before, basically the message might sound strange but it is factual in reality if only you care to listen to me. The truth is that I should have notified you first through a more confidential means, (even if it's at least to respect your integrity) please accept my humble apologies if I Had caught you unawares, I frankly do not mean any harm in passing my message. For security reason and also due to what is happening all over the internet now are days, please the details of my personality and that of my late husband will be directed to you via my private email as soon as I receive your response to my request below. I am woman and i am undergoing medical treatment at moment. I married to a lovely and gentle man who worked with JAPAN embassy in NAIROBI KENYA for nine years before he died in 2014. He died after a brief illness, I decided not to re-marry or get a child outside my matrimonial home. When my late husband was alive he deposited some amount of U.S. Dollars) in a Finance/Bank. Presently, this money is still with the Finance/Bank. What is actually disturbing me now is my stroke, Having known my condition I decided to donate this fund to church or better still a Christian/individual that will utilize this money the way I am going to instruct here in. I want you to use this funds help the widows, orphanage. I took this decision because I don't have any child that will inherit the money and my husband relatives are not Christians Nor Muslims, and I don't want my husband's hard earned money to be misused. I don't want situation where this money will be used in an ungodly manner, hence the reason for taking this bold decision. Please, for now i don't need any telephone communication in this regard because of my health, and because of the presence of my husband's relatives around me always. I don't want them to know about this development. As soon as I receive your reply I shall give you the contact of the Finance/Bank. I shall also send a letter of authority to the Bank that will empower you as the original- beneficiary of this fund. Please, if you do not have confidence in this message, kindly delete it and accept my sincere apology for contacting you in this manner. And any delay in your reply will give me room in sourcing for a church or Christian individual for this same purpose. Please assure me that you will act accordingly as I stated herein. Hope to hear from you. Remain blessed in the name of the Lord
Re: [PATCH v2 11/12] sched/core: uclamp: update CPU's refcount on TG's clamp changes
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> When a task group refcounts a new clamp group, we need to ensure that
> the new clamp values are immediately enforced to all its tasks which are
> currently RUNNABLE. This is to ensure that all currently RUNNABLE task
tasks
> are boosted and/or clamped as requested as soon as possible.
>
> Let's ensure that, whenever a new clamp group is refcounted by a task
> group, all its RUNNABLE tasks are correctly accounted in their
> respective CPUs. We do that by slightly refactoring uclamp_group_get()
> to get an additional parameter *cgroup_subsys_state which, when
> provided, it's used to walk the list of tasks in the correspond TGs and
corresponding TGs
> update the RUNNABLE ones.
>
> This is a "brute force" solution which allows to reuse the same refcount
> update code already used by the per-task API. That's also the only way
> to ensure a prompt enforcement of new clamp constraints on RUNNABLE
> tasks, as soon as a task group attribute is tweaked.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Paul Turner
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
> kernel/sched/core.c | 42 ++
> 1 file changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 50613d3d5b83..42cff5ffddae 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1198,21 +1198,43 @@ static inline void uclamp_group_put(int clamp_id, int
> group_id)
> raw_spin_unlock_irqrestore(_map[group_id].se_lock, flags);
> }
>
> +static inline void uclamp_group_get_tg(struct cgroup_subsys_state *css,
> + int clamp_id, unsigned int group_id)
> +{
> + struct css_task_iter it;
> + struct task_struct *p;
> +
> + /* Update clamp groups for RUNNABLE tasks in this TG */
> + css_task_iter_start(css, 0, );
> + while ((p = css_task_iter_next()))
> + uclamp_task_update_active(p, clamp_id, group_id);
> + css_task_iter_end();
> +}
> +
> /**
> * uclamp_group_get: increase the reference count for a clamp group
> * @p: the task which clamp value must be tracked
> - * @clamp_id: the clamp index affected by the task
> - * @uc_se: the utilization clamp data for the task
> - * @clamp_value: the new clamp value for the task
> + * @css: the task group which clamp value must be tracked
> + * @clamp_id: the clamp index affected by the task (group)
> + * @uc_se: the utilization clamp data for the task (group)
> + * @clamp_value: the new clamp value for the task (group)
> *
> * Each time a task changes its utilization clamp value, for a specified
> clamp
> * index, we need to find an available clamp group which can be used to track
> * this new clamp value. The corresponding clamp group index will be used by
> * the task to reference count the clamp value on CPUs while enqueued.
> *
> + * When the cgroup's cpu controller utilization clamping support is enabled,
> + * each task group has a set of clamp values which are used to restrict the
> + * corresponding task specific clamp values.
> + * When a clamp value for a task group is changed, all the (active) tasks
> + * belonging to that task group must be update to ensure they are refcounting
must be updated
> + * the correct CPU's clamp value.
> + *
> * Return: -ENOSPC if there are no available clamp groups, 0 on success.
> */
> static inline int uclamp_group_get(struct task_struct *p,
> + struct cgroup_subsys_state *css,
>int clamp_id, struct uclamp_se *uc_se,
>unsigned int clamp_value)
> {
> @@ -1240,6 +1262,10 @@ static inline int uclamp_group_get(struct task_struct
> *p,
> uc_map[next_group_id].se_count += 1;
> raw_spin_unlock_irqrestore(_map[next_group_id].se_lock, flags);
>
> + /* Newly created TG don't have tasks assigned */
> + if (css)
> + uclamp_group_get_tg(css, clamp_id, next_group_id);
> +
> /* Update CPU's clamp group refcounts of RUNNABLE task */
> if (p)
> uclamp_task_update_active(p, clamp_id, next_group_id);
> @@ -1307,7 +1333,7 @@ static inline int alloc_uclamp_sched_group(struct
> task_group *tg,
> uc_se->value = parent->uclamp[clamp_id].value;
> uc_se->group_id = UCLAMP_NONE;
>
> - if (uclamp_group_get(NULL, clamp_id, uc_se,
> + if (uclamp_group_get(NULL, NULL, clamp_id, uc_se,
> parent->uclamp[clamp_id].value)) {
> ret = 0;
> goto out;
> @@ -1362,12 +1388,12 @@ static inline int
Re: [PATCH v2 11/12] sched/core: uclamp: update CPU's refcount on TG's clamp changes
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> When a task group refcounts a new clamp group, we need to ensure that
> the new clamp values are immediately enforced to all its tasks which are
> currently RUNNABLE. This is to ensure that all currently RUNNABLE task
tasks
> are boosted and/or clamped as requested as soon as possible.
>
> Let's ensure that, whenever a new clamp group is refcounted by a task
> group, all its RUNNABLE tasks are correctly accounted in their
> respective CPUs. We do that by slightly refactoring uclamp_group_get()
> to get an additional parameter *cgroup_subsys_state which, when
> provided, it's used to walk the list of tasks in the correspond TGs and
corresponding TGs
> update the RUNNABLE ones.
>
> This is a "brute force" solution which allows to reuse the same refcount
> update code already used by the per-task API. That's also the only way
> to ensure a prompt enforcement of new clamp constraints on RUNNABLE
> tasks, as soon as a task group attribute is tweaked.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Paul Turner
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
> kernel/sched/core.c | 42 ++
> 1 file changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 50613d3d5b83..42cff5ffddae 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1198,21 +1198,43 @@ static inline void uclamp_group_put(int clamp_id, int
> group_id)
> raw_spin_unlock_irqrestore(_map[group_id].se_lock, flags);
> }
>
> +static inline void uclamp_group_get_tg(struct cgroup_subsys_state *css,
> + int clamp_id, unsigned int group_id)
> +{
> + struct css_task_iter it;
> + struct task_struct *p;
> +
> + /* Update clamp groups for RUNNABLE tasks in this TG */
> + css_task_iter_start(css, 0, );
> + while ((p = css_task_iter_next()))
> + uclamp_task_update_active(p, clamp_id, group_id);
> + css_task_iter_end();
> +}
> +
> /**
> * uclamp_group_get: increase the reference count for a clamp group
> * @p: the task which clamp value must be tracked
> - * @clamp_id: the clamp index affected by the task
> - * @uc_se: the utilization clamp data for the task
> - * @clamp_value: the new clamp value for the task
> + * @css: the task group which clamp value must be tracked
> + * @clamp_id: the clamp index affected by the task (group)
> + * @uc_se: the utilization clamp data for the task (group)
> + * @clamp_value: the new clamp value for the task (group)
> *
> * Each time a task changes its utilization clamp value, for a specified
> clamp
> * index, we need to find an available clamp group which can be used to track
> * this new clamp value. The corresponding clamp group index will be used by
> * the task to reference count the clamp value on CPUs while enqueued.
> *
> + * When the cgroup's cpu controller utilization clamping support is enabled,
> + * each task group has a set of clamp values which are used to restrict the
> + * corresponding task specific clamp values.
> + * When a clamp value for a task group is changed, all the (active) tasks
> + * belonging to that task group must be update to ensure they are refcounting
must be updated
> + * the correct CPU's clamp value.
> + *
> * Return: -ENOSPC if there are no available clamp groups, 0 on success.
> */
> static inline int uclamp_group_get(struct task_struct *p,
> + struct cgroup_subsys_state *css,
>int clamp_id, struct uclamp_se *uc_se,
>unsigned int clamp_value)
> {
> @@ -1240,6 +1262,10 @@ static inline int uclamp_group_get(struct task_struct
> *p,
> uc_map[next_group_id].se_count += 1;
> raw_spin_unlock_irqrestore(_map[next_group_id].se_lock, flags);
>
> + /* Newly created TG don't have tasks assigned */
> + if (css)
> + uclamp_group_get_tg(css, clamp_id, next_group_id);
> +
> /* Update CPU's clamp group refcounts of RUNNABLE task */
> if (p)
> uclamp_task_update_active(p, clamp_id, next_group_id);
> @@ -1307,7 +1333,7 @@ static inline int alloc_uclamp_sched_group(struct
> task_group *tg,
> uc_se->value = parent->uclamp[clamp_id].value;
> uc_se->group_id = UCLAMP_NONE;
>
> - if (uclamp_group_get(NULL, clamp_id, uc_se,
> + if (uclamp_group_get(NULL, NULL, clamp_id, uc_se,
> parent->uclamp[clamp_id].value)) {
> ret = 0;
> goto out;
> @@ -1362,12 +1388,12 @@ static inline int
Re: [lkp-robot] [tracing] ecadccb31b: kernel_selftests.ftrace.ftracetest.fail
On Sat, 21 Jul 2018 18:40:32 +0900
Masami Hiramatsu wrote:
> Hi,
>
> OK, I'll handle this.
> The reason why this error is that kprobe event tests probe ftrace itself for
> test.
So one possible fix is below patch.
Another possible way to fix is to allow instrumentation on trace_kprobe.c as
same as trace_selftest_dynamic.c .
Thank you,
-
selftests/ftrace: Fix kprobe string testcase to not probe notrace function
From: Masami Hiramatsu
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
index a000256..1ad70cd 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
@@ -9,28 +9,22 @@ echo > kprobe_events
case `uname -m` in
x86_64)
- ARG2=%si
- OFFS=8
+ ARG1=%di
;;
i[3456]86)
- ARG2=%cx
- OFFS=4
+ ARG1=%ax
;;
aarch64)
- ARG2=%x1
- OFFS=8
+ ARG1=%x0
;;
arm*)
- ARG2=%r1
- OFFS=4
+ ARG1=%r0
;;
ppc64*)
- ARG2=%r4
- OFFS=8
+ ARG1=%r3
;;
ppc*)
- ARG2=%r4
- OFFS=4
+ ARG1=%r3
;;
*)
echo "Please implement other architecture here"
@@ -38,17 +32,17 @@ ppc*)
esac
: "Test get argument (1)"
-echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string" >
kprobe_events
+echo "p:testprobe tracefs_create_dir arg1=+0(${ARG1}):string" > kprobe_events
echo 1 > events/kprobes/testprobe/enable
-! echo test >> kprobe_events
-tail -n 1 trace | grep -qe "testprobe.* arg1=\"test\""
+echo "p:test _do_fork" >> kprobe_events
+grep -qe "testprobe.* arg1=\"test\"" trace
echo 0 > events/kprobes/testprobe/enable
: "Test get argument (2)"
-echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string
arg2=+0(+${OFFS}(${ARG2})):string" > kprobe_events
+echo "p:testprobe tracefs_create_dir arg1=+0(${ARG1}):string
arg2=+0(${ARG1}):string" > kprobe_events
echo 1 > events/kprobes/testprobe/enable
-! echo test1 test2 >> kprobe_events
-tail -n 1 trace | grep -qe "testprobe.* arg1=\"test1\" arg2=\"test2\""
+echo "p:test _do_fork" >> kprobe_events
+grep -qe "testprobe.* arg1=\"test\" arg2=\"test\"" trace
echo 0 > events/enable
echo > kprobe_events
Re: [lkp-robot] [tracing] ecadccb31b: kernel_selftests.ftrace.ftracetest.fail
On Sat, 21 Jul 2018 18:40:32 +0900
Masami Hiramatsu wrote:
> Hi,
>
> OK, I'll handle this.
> The reason why this error is that kprobe event tests probe ftrace itself for
> test.
So one possible fix is below patch.
Another possible way to fix is to allow instrumentation on trace_kprobe.c as
same as trace_selftest_dynamic.c .
Thank you,
-
selftests/ftrace: Fix kprobe string testcase to not probe notrace function
From: Masami Hiramatsu
Fix kprobe string argument testcase to not probe notrace
function. Instead, it probes tracefs function which must
be available with ftrace.
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 30
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
index a000256..1ad70cd 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
@@ -9,28 +9,22 @@ echo > kprobe_events
case `uname -m` in
x86_64)
- ARG2=%si
- OFFS=8
+ ARG1=%di
;;
i[3456]86)
- ARG2=%cx
- OFFS=4
+ ARG1=%ax
;;
aarch64)
- ARG2=%x1
- OFFS=8
+ ARG1=%x0
;;
arm*)
- ARG2=%r1
- OFFS=4
+ ARG1=%r0
;;
ppc64*)
- ARG2=%r4
- OFFS=8
+ ARG1=%r3
;;
ppc*)
- ARG2=%r4
- OFFS=4
+ ARG1=%r3
;;
*)
echo "Please implement other architecture here"
@@ -38,17 +32,17 @@ ppc*)
esac
: "Test get argument (1)"
-echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string" >
kprobe_events
+echo "p:testprobe tracefs_create_dir arg1=+0(${ARG1}):string" > kprobe_events
echo 1 > events/kprobes/testprobe/enable
-! echo test >> kprobe_events
-tail -n 1 trace | grep -qe "testprobe.* arg1=\"test\""
+echo "p:test _do_fork" >> kprobe_events
+grep -qe "testprobe.* arg1=\"test\"" trace
echo 0 > events/kprobes/testprobe/enable
: "Test get argument (2)"
-echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string
arg2=+0(+${OFFS}(${ARG2})):string" > kprobe_events
+echo "p:testprobe tracefs_create_dir arg1=+0(${ARG1}):string
arg2=+0(${ARG1}):string" > kprobe_events
echo 1 > events/kprobes/testprobe/enable
-! echo test1 test2 >> kprobe_events
-tail -n 1 trace | grep -qe "testprobe.* arg1=\"test1\" arg2=\"test2\""
+echo "p:test _do_fork" >> kprobe_events
+grep -qe "testprobe.* arg1=\"test\" arg2=\"test\"" trace
echo 0 > events/enable
echo > kprobe_events
Re: [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> When a task's util_clamp value is configured via sched_setattr(2), this
> value has to be properly accounted in the corresponding clamp group
> every time the task is enqueued and dequeued. When cgroups are also in
> use, per-task clamp values have to be aggregated to those of the CPU's
> controller's Task Group (TG) in which the task is currently living.
>
> Let's update uclamp_cpu_get() to provide aggregation between the task
> and the TG clamp values. Every time a task is enqueued, it will be
> accounted in the clamp_group which defines the smaller clamp between the
> task specific value and its TG value.
So choosing smallest for both UCLAMP_MIN and UCLAMP_MAX means the
least boosted value and the most clamped value between syscall and TG
will be used. My understanding is that boost means "at least this
much" and clamp means "at most this much". So to satisfy both TG and
syscall requirements I think you would need to choose the largest
value for UCLAMP_MIN and the smallest one for UCLAMP_MAX, meaning the
most boosted and most clamped range. Current implementation choses the
least boosted value, so effectively one of the UCLAMP_MIN requirements
(either from TG or from syscall) are being ignored...
Could you please clarify why this choice is made?
>
> This also mimics what already happen for a task's CPU affinity mask when
> the task is also living in a cpuset. he overall idea is that cgroup
typo: The overall...
> attributes are always used to restrict the per-task attributes.
>
> Thus, this implementation allows to:
>
> 1. ensure cgroup clamps are always used to restrict task specific
>requests, i.e. boosted only up to a granted value or clamped at least
>to a certain value
> 2. implements a "nice-like" policy, where tasks are still allowed to
>request less then what enforced by their current TG
>
> For this mecanisms to work properly, we need to implement a concept of
> "effective" clamp group, which is used to track the currently most
> restrictive clamp value each task is subject to.
> The effective clamp is computed at enqueue time, by using an additional
>task_struct::uclamp_group_id
> to keep track of the clamp group in which each task is currently
> accounted into. This solution allows to update task constrains on
> demand, only when they became RUNNABLE, to always get the least
> restrictive clamp depending on the current TG's settings.
>
> This solution allows also to better decouple the slow-path, where task
> and task group clamp values are updated, from the fast-path, where the
> most appropriate clamp value is tracked by refcounting clamp groups.
>
> For consistency purposes, as well as to properly inform userspace, the
> sched_getattr(2) call is updated to always return the properly
> aggregated constrains as described above. This will also make
> sched_getattr(2) a convenient userpace API to know the utilization
> constraints enforced on a task by the cgroup's CPU controller.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Paul Turner
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
> include/linux/sched.h | 2 ++
> kernel/sched/core.c | 40 +++-
> kernel/sched/sched.h | 2 +-
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 260aa8d3fca9..5dd76a27ec17 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -676,6 +676,8 @@ struct task_struct {
> struct sched_dl_entity dl;
>
> #ifdef CONFIG_UCLAMP_TASK
> + /* Clamp group the task is currently accounted into */
> + int uclamp_group_id[UCLAMP_CNT];
> /* Utlization clamp values for this task */
> struct uclamp_seuclamp[UCLAMP_CNT];
> #endif
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 04e758224e22..50613d3d5b83 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -971,8 +971,15 @@ static inline void uclamp_cpu_update(struct rq *rq, int
> clamp_id,
> * @rq: the CPU's rq where the clamp group has to be reference counted
> * @clamp_id: the utilization clamp (e.g. min or max utilization) to
> reference
> *
> - * Once a task is enqueued on a CPU's RQ, the clamp group currently defined
> by
> - * the task's uclamp.group_id is reference counted on that CPU.
> + * Once a task is enqueued on a CPU's RQ, the most restrictive clamp group,
> + * among the task specific and that of the task's cgroup one, is reference
> + * counted on that CPU.
> + *
> + * Since the CPUs reference counted clamp group can be either that of the
> task
> + * or of its cgroup, we keep track of the reference counted clamp group by
> + *
Re: [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> When a task's util_clamp value is configured via sched_setattr(2), this
> value has to be properly accounted in the corresponding clamp group
> every time the task is enqueued and dequeued. When cgroups are also in
> use, per-task clamp values have to be aggregated to those of the CPU's
> controller's Task Group (TG) in which the task is currently living.
>
> Let's update uclamp_cpu_get() to provide aggregation between the task
> and the TG clamp values. Every time a task is enqueued, it will be
> accounted in the clamp_group which defines the smaller clamp between the
> task specific value and its TG value.
So choosing smallest for both UCLAMP_MIN and UCLAMP_MAX means the
least boosted value and the most clamped value between syscall and TG
will be used. My understanding is that boost means "at least this
much" and clamp means "at most this much". So to satisfy both TG and
syscall requirements I think you would need to choose the largest
value for UCLAMP_MIN and the smallest one for UCLAMP_MAX, meaning the
most boosted and most clamped range. Current implementation choses the
least boosted value, so effectively one of the UCLAMP_MIN requirements
(either from TG or from syscall) are being ignored...
Could you please clarify why this choice is made?
>
> This also mimics what already happen for a task's CPU affinity mask when
> the task is also living in a cpuset. he overall idea is that cgroup
typo: The overall...
> attributes are always used to restrict the per-task attributes.
>
> Thus, this implementation allows to:
>
> 1. ensure cgroup clamps are always used to restrict task specific
>requests, i.e. boosted only up to a granted value or clamped at least
>to a certain value
> 2. implements a "nice-like" policy, where tasks are still allowed to
>request less then what enforced by their current TG
>
> For this mecanisms to work properly, we need to implement a concept of
> "effective" clamp group, which is used to track the currently most
> restrictive clamp value each task is subject to.
> The effective clamp is computed at enqueue time, by using an additional
>task_struct::uclamp_group_id
> to keep track of the clamp group in which each task is currently
> accounted into. This solution allows to update task constrains on
> demand, only when they became RUNNABLE, to always get the least
> restrictive clamp depending on the current TG's settings.
>
> This solution allows also to better decouple the slow-path, where task
> and task group clamp values are updated, from the fast-path, where the
> most appropriate clamp value is tracked by refcounting clamp groups.
>
> For consistency purposes, as well as to properly inform userspace, the
> sched_getattr(2) call is updated to always return the properly
> aggregated constrains as described above. This will also make
> sched_getattr(2) a convenient userpace API to know the utilization
> constraints enforced on a task by the cgroup's CPU controller.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Paul Turner
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Steve Muckle
> Cc: Juri Lelli
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
> include/linux/sched.h | 2 ++
> kernel/sched/core.c | 40 +++-
> kernel/sched/sched.h | 2 +-
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 260aa8d3fca9..5dd76a27ec17 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -676,6 +676,8 @@ struct task_struct {
> struct sched_dl_entity dl;
>
> #ifdef CONFIG_UCLAMP_TASK
> + /* Clamp group the task is currently accounted into */
> + int uclamp_group_id[UCLAMP_CNT];
> /* Utlization clamp values for this task */
> struct uclamp_seuclamp[UCLAMP_CNT];
> #endif
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 04e758224e22..50613d3d5b83 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -971,8 +971,15 @@ static inline void uclamp_cpu_update(struct rq *rq, int
> clamp_id,
> * @rq: the CPU's rq where the clamp group has to be reference counted
> * @clamp_id: the utilization clamp (e.g. min or max utilization) to
> reference
> *
> - * Once a task is enqueued on a CPU's RQ, the clamp group currently defined
> by
> - * the task's uclamp.group_id is reference counted on that CPU.
> + * Once a task is enqueued on a CPU's RQ, the most restrictive clamp group,
> + * among the task specific and that of the task's cgroup one, is reference
> + * counted on that CPU.
> + *
> + * Since the CPUs reference counted clamp group can be either that of the
> task
> + * or of its cgroup, we keep track of the reference counted clamp group by
> + *
[PATCH] sparc: fix header problem in sparc32 build
From: Randy Dunlap Add a "struct page;" "stub" to fix a build error in sparc32. Fixes this error: ../include/linux/highmem.h: In function 'clear_user_highpage': ../include/linux/highmem.h:137:31: error: passing argument 1 of 'sparc_flush_page_to_ram' from incompatible pointer type [-Werror=incompatible-pointer-types] clear_user_page(addr, vaddr, page); ^~~~ ../arch/sparc/include/asm/page_32.h:24:27: note: in definition of macro 'clear_user_page' sparc_flush_page_to_ram(page); \ ^~~~ Signed-off-by: Randy Dunlap --- arch/sparc/include/asm/cacheflush_32.h |1 + 1 file changed, 1 insertion(+) --- linux-next-20180717.orig/arch/sparc/include/asm/cacheflush_32.h +++ linux-next-20180717/arch/sparc/include/asm/cacheflush_32.h @@ -37,6 +37,7 @@ #define flush_page_for_dma(addr) \ sparc32_cachetlb_ops->page_for_dma(addr) +struct page; void sparc_flush_page_to_ram(struct page *page); #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
[PATCH] sparc: fix header problem in sparc32 build
From: Randy Dunlap Add a "struct page;" "stub" to fix a build error in sparc32. Fixes this error: ../include/linux/highmem.h: In function 'clear_user_highpage': ../include/linux/highmem.h:137:31: error: passing argument 1 of 'sparc_flush_page_to_ram' from incompatible pointer type [-Werror=incompatible-pointer-types] clear_user_page(addr, vaddr, page); ^~~~ ../arch/sparc/include/asm/page_32.h:24:27: note: in definition of macro 'clear_user_page' sparc_flush_page_to_ram(page); \ ^~~~ Signed-off-by: Randy Dunlap --- arch/sparc/include/asm/cacheflush_32.h |1 + 1 file changed, 1 insertion(+) --- linux-next-20180717.orig/arch/sparc/include/asm/cacheflush_32.h +++ linux-next-20180717/arch/sparc/include/asm/cacheflush_32.h @@ -37,6 +37,7 @@ #define flush_page_for_dma(addr) \ sparc32_cachetlb_ops->page_for_dma(addr) +struct page; void sparc_flush_page_to_ram(struct page *page); #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
Re: kernel %rsp code at sysenter PTI vs no-PTI
On Thu, Jul 5, 2018 at 10:14 AM, Dave Hansen wrote: > The PTI path does this: > > ... > SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp > /* Load the top of the task stack into RSP */ > movqCPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp > > And the non-PTI entry path does this: > > ... > movq%rsp, PER_CPU_VAR(rsp_scratch) > movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp > > Both "mov ___, %rsp" instructions have the kernel %GS value in place and > both are running on a good kernel CR3. Does anybody remember why we > don't use cpu_current_top_of_stack in the PTI-on case? > > I'm wondering if it was because we, at some point, did the mov ..., > %rsp before CR3 was good. But it doesn't look like we do that now, so > should we maybe make both copies do: > > movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp Speed, sort of. Without the CR3 switch there (i.e. PTI off, but trampoline still in use, which is the path that actually gets used), there's no forced serialization between swapgs and that movq. And it turns out that the RIP-relative load avoids a pipeline stall that the %gs-relative access right after swapgs would cause. So, with all the mitigations off, the trampoline ends up being *faster*, at least in a tight loop, than the non-trampolined path. Of course, on a retpolined kernel, the retpoline at the end kills performance. > > for consistency?
Re: kernel %rsp code at sysenter PTI vs no-PTI
On Thu, Jul 5, 2018 at 10:14 AM, Dave Hansen wrote: > The PTI path does this: > > ... > SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp > /* Load the top of the task stack into RSP */ > movqCPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp > > And the non-PTI entry path does this: > > ... > movq%rsp, PER_CPU_VAR(rsp_scratch) > movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp > > Both "mov ___, %rsp" instructions have the kernel %GS value in place and > both are running on a good kernel CR3. Does anybody remember why we > don't use cpu_current_top_of_stack in the PTI-on case? > > I'm wondering if it was because we, at some point, did the mov ..., > %rsp before CR3 was good. But it doesn't look like we do that now, so > should we maybe make both copies do: > > movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp Speed, sort of. Without the CR3 switch there (i.e. PTI off, but trampoline still in use, which is the path that actually gets used), there's no forced serialization between swapgs and that movq. And it turns out that the RIP-relative load avoids a pipeline stall that the %gs-relative access right after swapgs would cause. So, with all the mitigations off, the trampoline ends up being *faster*, at least in a tight loop, than the non-trampolined path. Of course, on a retpolined kernel, the retpoline at the end kills performance. > > for consistency?
Re: [PATCH] x86: vdso: Use $LD instead of $CC to link
On Wed, Jul 18, 2018 at 3:41 PM, Alistair Strachan wrote:
> The vdso{32,64}.so can fail to link with CC=clang when clang tries to
> find a suitable GCC toolchain to link these libraries with.
>
> /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o:
> access beyond end of merged section (782)
>
> This happens because the host environment leaked into the cross
> compiler environment due to the way clang searches for suitable GCC
> toolchains.
>
> Clang is a retargetable compiler, and each invocation of it must
> provide --target= --gcc-toolchain= to allow it
> to find the correct binutils for cross compilation. These flags had
> been added to KBUILD_CFLAGS, but the vdso code uses CC and not
> KBUILD_CFLAGS (for various reasons) which breaks clang's ability to
> find the correct linker when cross compiling.
>
> Most of the time this goes unnoticed because the host linker is new
> enough to work anyway, or is incompatible and skipped, but this cannot
> be reliably assumed.
>
> This change alters the vdso makefile to just use LD directly, which
> bypasses clang and thus the searching problem. The makefile will just
> use ${CROSS_COMPILE}ld instead, which is always what we want. This
> matches the method used to link vmlinux.
Acked-by: Andy Lutomirski
>
> Cc: Andy Lutomirski
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Greg Kroah-Hartman
> Cc: x...@kernel.org
> Cc: kernel-t...@android.com
> Cc: j...@joelfernandes.com
> Signed-off-by: Alistair Strachan
> ---
> Supersedes "x86: vdso: Fix leaky vdso link with CC=clang"
> arch/x86/entry/vdso/Makefile | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 1943aebadede..896a55204386 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -48,10 +48,8 @@ targets += $(vdso_img_sodbg)
>
> export CPPFLAGS_vdso.lds += -P -C
>
> -VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
> - -Wl,--no-undefined \
> - -Wl,-z,max-page-size=4096
> -Wl,-z,common-page-size=4096 \
> - $(DISABLE_LTO)
> +VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -soname linux-vdso.so.1 --no-undefined
> \
> + -z max-page-size=4096 -z common-page-size=4096
>
> $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
> $(call if_changed,vdso)
> @@ -97,10 +95,8 @@ CFLAGS_REMOVE_vvar.o = -pg
> #
>
> CPPFLAGS_vdsox32.lds = $(CPPFLAGS_vdso.lds)
> -VDSO_LDFLAGS_vdsox32.lds = -Wl,-m,elf32_x86_64 \
> - -Wl,-soname=linux-vdso.so.1 \
> - -Wl,-z,max-page-size=4096 \
> - -Wl,-z,common-page-size=4096
> +VDSO_LDFLAGS_vdsox32.lds = -m elf32_x86_64 -soname linux-vdso.so.1 \
> + -z max-page-size=4096 -z common-page-size=4096
>
> # 64-bit objects to re-brand as x32
> vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
> @@ -128,7 +124,7 @@ $(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s)
> FORCE
> $(call if_changed,vdso)
>
> CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
> -VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1
> +VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -soname linux-gate.so.1
>
> targets += vdso32/vdso32.lds
> targets += vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
> @@ -162,13 +158,13 @@ $(obj)/vdso32.so.dbg: FORCE \
> # The DSO images are built using a special linker script.
> #
> quiet_cmd_vdso = VDSO$@
> - cmd_vdso = $(CC) -nostdlib -o $@ \
> + cmd_vdso = $(LD) -nostdlib -o $@ \
>$(VDSO_LDFLAGS) $(VDSO_LDFLAGS_$(filter %.lds,$(^F))) \
> - -Wl,-T,$(filter %.lds,$^) $(filter %.o,$^) && \
> + -T $(filter %.lds,$^) $(filter %.o,$^) && \
> sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
>
> -VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption,
> -Wl$(comma)--hash-style=both) \
> - $(call cc-ldoption, -Wl$(comma)--build-id) -Wl,-Bsymbolic
> $(LTO_CFLAGS)
> +VDSO_LDFLAGS = -shared $(call ld-option, --hash-style=both) \
> + $(call ld-option, --build-id) -Bsymbolic
> GCOV_PROFILE := n
>
> #
Re: [PATCH] x86: vdso: Use $LD instead of $CC to link
On Wed, Jul 18, 2018 at 3:41 PM, Alistair Strachan wrote:
> The vdso{32,64}.so can fail to link with CC=clang when clang tries to
> find a suitable GCC toolchain to link these libraries with.
>
> /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o:
> access beyond end of merged section (782)
>
> This happens because the host environment leaked into the cross
> compiler environment due to the way clang searches for suitable GCC
> toolchains.
>
> Clang is a retargetable compiler, and each invocation of it must
> provide --target= --gcc-toolchain= to allow it
> to find the correct binutils for cross compilation. These flags had
> been added to KBUILD_CFLAGS, but the vdso code uses CC and not
> KBUILD_CFLAGS (for various reasons) which breaks clang's ability to
> find the correct linker when cross compiling.
>
> Most of the time this goes unnoticed because the host linker is new
> enough to work anyway, or is incompatible and skipped, but this cannot
> be reliably assumed.
>
> This change alters the vdso makefile to just use LD directly, which
> bypasses clang and thus the searching problem. The makefile will just
> use ${CROSS_COMPILE}ld instead, which is always what we want. This
> matches the method used to link vmlinux.
Acked-by: Andy Lutomirski
>
> Cc: Andy Lutomirski
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Greg Kroah-Hartman
> Cc: x...@kernel.org
> Cc: kernel-t...@android.com
> Cc: j...@joelfernandes.com
> Signed-off-by: Alistair Strachan
> ---
> Supersedes "x86: vdso: Fix leaky vdso link with CC=clang"
> arch/x86/entry/vdso/Makefile | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 1943aebadede..896a55204386 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -48,10 +48,8 @@ targets += $(vdso_img_sodbg)
>
> export CPPFLAGS_vdso.lds += -P -C
>
> -VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
> - -Wl,--no-undefined \
> - -Wl,-z,max-page-size=4096
> -Wl,-z,common-page-size=4096 \
> - $(DISABLE_LTO)
> +VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -soname linux-vdso.so.1 --no-undefined
> \
> + -z max-page-size=4096 -z common-page-size=4096
>
> $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
> $(call if_changed,vdso)
> @@ -97,10 +95,8 @@ CFLAGS_REMOVE_vvar.o = -pg
> #
>
> CPPFLAGS_vdsox32.lds = $(CPPFLAGS_vdso.lds)
> -VDSO_LDFLAGS_vdsox32.lds = -Wl,-m,elf32_x86_64 \
> - -Wl,-soname=linux-vdso.so.1 \
> - -Wl,-z,max-page-size=4096 \
> - -Wl,-z,common-page-size=4096
> +VDSO_LDFLAGS_vdsox32.lds = -m elf32_x86_64 -soname linux-vdso.so.1 \
> + -z max-page-size=4096 -z common-page-size=4096
>
> # 64-bit objects to re-brand as x32
> vobjs64-for-x32 := $(filter-out $(vobjs-nox32),$(vobjs-y))
> @@ -128,7 +124,7 @@ $(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s)
> FORCE
> $(call if_changed,vdso)
>
> CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
> -VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1
> +VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -soname linux-gate.so.1
>
> targets += vdso32/vdso32.lds
> targets += vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
> @@ -162,13 +158,13 @@ $(obj)/vdso32.so.dbg: FORCE \
> # The DSO images are built using a special linker script.
> #
> quiet_cmd_vdso = VDSO$@
> - cmd_vdso = $(CC) -nostdlib -o $@ \
> + cmd_vdso = $(LD) -nostdlib -o $@ \
>$(VDSO_LDFLAGS) $(VDSO_LDFLAGS_$(filter %.lds,$(^F))) \
> - -Wl,-T,$(filter %.lds,$^) $(filter %.o,$^) && \
> + -T $(filter %.lds,$^) $(filter %.o,$^) && \
> sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
>
> -VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption,
> -Wl$(comma)--hash-style=both) \
> - $(call cc-ldoption, -Wl$(comma)--build-id) -Wl,-Bsymbolic
> $(LTO_CFLAGS)
> +VDSO_LDFLAGS = -shared $(call ld-option, --hash-style=both) \
> + $(call ld-option, --build-id) -Bsymbolic
> GCOV_PROFILE := n
>
> #
Re: [GIT PULL 3/3] ARM: uniphier: UniPhier SoC updates for v4.19
Hi Olof, 2018-07-22 6:24 GMT+09:00 Olof Johansson : > On Thu, Jul 19, 2018 at 08:05:03AM +0900, Masahiro Yamada wrote: >> Hi Arnd, Olof, >> >> Please pull UniPhier SoC changes for the v4.19 MW. >> >> Thanks! >> >> >> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: >> >> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git >> tags/uniphier-soc-v4.19 >> >> for you to fetch changes up to ae93e694440a454609fa40725e16619c5a781768: >> >> ARM: uniphier: remove empty Makefile (2018-07-19 06:53:16 +0900) >> >> >> UniPhier ARM SoC updates for v4.19 >> >> - enable ethernet and thermal drivers from multi_v7_defconfig >> >> - select RESET_CONTROLLER >> >> - remove empty arch/arm/mach-uniphier/Makefile >> >> >> Kunihiko Hayashi (1): >> ARM: multi_v7_defconfig: add CONFIG_UNIPHIER_THERMAL and CONFIG_SNI_AVE > > I renormalied multi_v7_defconfig for 4.18-rc3, so please base your branch > on that to avoid conflicts. > > Also, we separate out defconfig updates to branches on their own. I can > cherry-pick the branch apart but wanted to check with you before I do > so in case it messes up your workflow. If it does, send a fresh pull > request for SoC, and either one for the defconfig or just the patch and > we can apply it directly. > Can you do cherry-pick please? Thanks! -- Best Regards Masahiro Yamada
Re: [GIT PULL 3/3] ARM: uniphier: UniPhier SoC updates for v4.19
Hi Olof, 2018-07-22 6:24 GMT+09:00 Olof Johansson : > On Thu, Jul 19, 2018 at 08:05:03AM +0900, Masahiro Yamada wrote: >> Hi Arnd, Olof, >> >> Please pull UniPhier SoC changes for the v4.19 MW. >> >> Thanks! >> >> >> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: >> >> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git >> tags/uniphier-soc-v4.19 >> >> for you to fetch changes up to ae93e694440a454609fa40725e16619c5a781768: >> >> ARM: uniphier: remove empty Makefile (2018-07-19 06:53:16 +0900) >> >> >> UniPhier ARM SoC updates for v4.19 >> >> - enable ethernet and thermal drivers from multi_v7_defconfig >> >> - select RESET_CONTROLLER >> >> - remove empty arch/arm/mach-uniphier/Makefile >> >> >> Kunihiko Hayashi (1): >> ARM: multi_v7_defconfig: add CONFIG_UNIPHIER_THERMAL and CONFIG_SNI_AVE > > I renormalied multi_v7_defconfig for 4.18-rc3, so please base your branch > on that to avoid conflicts. > > Also, we separate out defconfig updates to branches on their own. I can > cherry-pick the branch apart but wanted to check with you before I do > so in case it messes up your workflow. If it does, send a fresh pull > request for SoC, and either one for the defconfig or just the patch and > we can apply it directly. > Can you do cherry-pick please? Thanks! -- Best Regards Masahiro Yamada
regulator: bcm590xx: of_node_put(np) missing
Hello, bcm590xx_parse_dt_reg_data() calls of_node_get(np), but there is nowhere of_node_put(np) in the driver. Should we add of_node_put(np) and what is timeframe of_node_get(np) required for? Found by Linux Driver Verification project (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS web: http://linuxtesting.org
regulator: bcm590xx: of_node_put(np) missing
Hello, bcm590xx_parse_dt_reg_data() calls of_node_get(np), but there is nowhere of_node_put(np) in the driver. Should we add of_node_put(np) and what is timeframe of_node_get(np) required for? Found by Linux Driver Verification project (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS web: http://linuxtesting.org
[PATCH] x86: czc-tablet: add driver that fixes the buttons on CZC P10T tablet
This driver switches the P10T tablet to "Android" mode, where the Home
button sends a single sancode instead of a Windows-specific key
combination and the other button doesn't disable the Wi-Fi.
The driver also supports the ViewSonic ViewPad 10 which is almost identical
to P10T.
Complementary hwdb patch with the scan code mapping:
https://github.com/systemd/systemd/commit/40a3078b.patch
Signed-off-by: Lubomir Rintel
---
MAINTAINERS | 6 +++
drivers/platform/x86/Kconfig | 8
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/czc-tablet.c | 80 +++
4 files changed, 95 insertions(+)
create mode 100644 drivers/platform/x86/czc-tablet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 07d1576fc766..64bd3f330f85 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3979,6 +3979,12 @@ S: Supported
F: drivers/input/touchscreen/cyttsp*
F: include/linux/input/cyttsp.h
+CZC TABLET DRIVER
+M: Lubomir Rintel
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/czc-tablet.c
+
D-LINK DIR-685 TOUCHKEYS DRIVER
M: Linus Walleij
L: linux-in...@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ac4d48830415..4ec8576129dc 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1218,6 +1218,14 @@ config INTEL_CHTDC_TI_PWRBTN
To compile this driver as a module, choose M here: the module
will be called intel_chtdc_ti_pwrbtn.
+config CZC_TABLET
+tristate "CZC Tablet Extras"
+help
+ This driver adds support for buttons on a CZC ODEON TPC-10 ("P10T")
+ and ViewSonic ViewPad 10 tablet computers.
+
+ If you have an 10" CZC or ViewSonic tablet, say Y or M here.
+
endif # X86_PLATFORM_DEVICES
config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 2ba6cb795338..5cb772bbbfb6 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_SURFACE3_WMI)+= surface3-wmi.o
obj-$(CONFIG_TOPSTAR_LAPTOP) += topstar-laptop.o
obj-$(CONFIG_WMI_BMOF) += wmi-bmof.o
obj-$(CONFIG_INTEL_WMI_THUNDERBOLT)+= intel-wmi-thunderbolt.o
+obj-$(CONFIG_CZC_TABLET) += czc-tablet.o
# toshiba_acpi must link after wmi to ensure that wmi devices are found
# before toshiba_acpi initializes
diff --git a/drivers/platform/x86/czc-tablet.c
b/drivers/platform/x86/czc-tablet.c
new file mode 100644
index ..8ff94c4bfe43
--- /dev/null
+++ b/drivers/platform/x86/czc-tablet.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CZC Tablet Support
+ *
+ * Copyright (C) 2018 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+
+static bool force;
+module_param(force, bool, 0);
+MODULE_PARM_DESC(force, "Disable the DMI check and force the driver to be
loaded");
+
+/*
+ * The device boots up in "Windows 7" mode, when the home button sends a
+ * Windows specific key sequence (Left Meta + D) and the second button
+ * sends an unknown one while also toggling the Radio Kill Switch.
+ * This is a surprising behavior when the second button is labeled "Back".
+ *
+ * The vendor-supplied Android-x86 build switches the device to a "Android"
+ * mode by writing value 0x63 to the I/O port 0x68. This just seems to just
+ * set bit 6 on address 0x96 in the EC region; switching the bit directly
+ * seems to achieve the same result. It uses a "p10t_switcher" to do the
+ * job. It doesn't seem to be able to do anything else, and no other use
+ * of the port 0x68 is known.
+ *
+ * In the Android mode, the home button sends just a single scancode,
+ * which can be handled in Linux userspace more reasonably and the back
+ * button only sends a scancode without toggling the kill switch.
+ * The scancode can then be mapped either to Back or RF Kill functionality
+ * in userspace, depending on how the button is labeled on that particular
+ * model.
+ */
+
+#define CZC_EC_EXTRA_PORT 0x68
+
+#define CZC_EC_ANDROID_KEYS 0x63
+
+static const struct dmi_system_id czc_tablet_table[] __initconst = {
+ {
+ .ident = "CZC ODEON TPC-10 (\"P10T\")",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CZC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ODEON*TPC-10"),
+ },
+ },
+ {
+ .ident = "ViewSonic ViewPad 10",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ViewSonic"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VPAD10"),
+ },
+ },
+ { }
+};
+
+static int __init czc_tablet_init(void)
+{
+ if (!force && !dmi_check_system(czc_tablet_table))
+ return -ENODEV;
+
+ outb(CZC_EC_ANDROID_KEYS, CZC_EC_EXTRA_PORT);
+
+ return 0;
+}
+
+static void __exit czc_tablet_exit(void)
+{
+}
+
[PATCH] x86: czc-tablet: add driver that fixes the buttons on CZC P10T tablet
This driver switches the P10T tablet to "Android" mode, where the Home
button sends a single sancode instead of a Windows-specific key
combination and the other button doesn't disable the Wi-Fi.
The driver also supports the ViewSonic ViewPad 10 which is almost identical
to P10T.
Complementary hwdb patch with the scan code mapping:
https://github.com/systemd/systemd/commit/40a3078b.patch
Signed-off-by: Lubomir Rintel
---
MAINTAINERS | 6 +++
drivers/platform/x86/Kconfig | 8
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/czc-tablet.c | 80 +++
4 files changed, 95 insertions(+)
create mode 100644 drivers/platform/x86/czc-tablet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 07d1576fc766..64bd3f330f85 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3979,6 +3979,12 @@ S: Supported
F: drivers/input/touchscreen/cyttsp*
F: include/linux/input/cyttsp.h
+CZC TABLET DRIVER
+M: Lubomir Rintel
+L: platform-driver-...@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/czc-tablet.c
+
D-LINK DIR-685 TOUCHKEYS DRIVER
M: Linus Walleij
L: linux-in...@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ac4d48830415..4ec8576129dc 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1218,6 +1218,14 @@ config INTEL_CHTDC_TI_PWRBTN
To compile this driver as a module, choose M here: the module
will be called intel_chtdc_ti_pwrbtn.
+config CZC_TABLET
+tristate "CZC Tablet Extras"
+help
+ This driver adds support for buttons on a CZC ODEON TPC-10 ("P10T")
+ and ViewSonic ViewPad 10 tablet computers.
+
+ If you have an 10" CZC or ViewSonic tablet, say Y or M here.
+
endif # X86_PLATFORM_DEVICES
config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 2ba6cb795338..5cb772bbbfb6 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_SURFACE3_WMI)+= surface3-wmi.o
obj-$(CONFIG_TOPSTAR_LAPTOP) += topstar-laptop.o
obj-$(CONFIG_WMI_BMOF) += wmi-bmof.o
obj-$(CONFIG_INTEL_WMI_THUNDERBOLT)+= intel-wmi-thunderbolt.o
+obj-$(CONFIG_CZC_TABLET) += czc-tablet.o
# toshiba_acpi must link after wmi to ensure that wmi devices are found
# before toshiba_acpi initializes
diff --git a/drivers/platform/x86/czc-tablet.c
b/drivers/platform/x86/czc-tablet.c
new file mode 100644
index ..8ff94c4bfe43
--- /dev/null
+++ b/drivers/platform/x86/czc-tablet.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CZC Tablet Support
+ *
+ * Copyright (C) 2018 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+
+static bool force;
+module_param(force, bool, 0);
+MODULE_PARM_DESC(force, "Disable the DMI check and force the driver to be
loaded");
+
+/*
+ * The device boots up in "Windows 7" mode, when the home button sends a
+ * Windows specific key sequence (Left Meta + D) and the second button
+ * sends an unknown one while also toggling the Radio Kill Switch.
+ * This is a surprising behavior when the second button is labeled "Back".
+ *
+ * The vendor-supplied Android-x86 build switches the device to a "Android"
+ * mode by writing value 0x63 to the I/O port 0x68. This just seems to just
+ * set bit 6 on address 0x96 in the EC region; switching the bit directly
+ * seems to achieve the same result. It uses a "p10t_switcher" to do the
+ * job. It doesn't seem to be able to do anything else, and no other use
+ * of the port 0x68 is known.
+ *
+ * In the Android mode, the home button sends just a single scancode,
+ * which can be handled in Linux userspace more reasonably and the back
+ * button only sends a scancode without toggling the kill switch.
+ * The scancode can then be mapped either to Back or RF Kill functionality
+ * in userspace, depending on how the button is labeled on that particular
+ * model.
+ */
+
+#define CZC_EC_EXTRA_PORT 0x68
+
+#define CZC_EC_ANDROID_KEYS 0x63
+
+static const struct dmi_system_id czc_tablet_table[] __initconst = {
+ {
+ .ident = "CZC ODEON TPC-10 (\"P10T\")",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CZC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ODEON*TPC-10"),
+ },
+ },
+ {
+ .ident = "ViewSonic ViewPad 10",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ViewSonic"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VPAD10"),
+ },
+ },
+ { }
+};
+
+static int __init czc_tablet_init(void)
+{
+ if (!force && !dmi_check_system(czc_tablet_table))
+ return -ENODEV;
+
+ outb(CZC_EC_ANDROID_KEYS, CZC_EC_EXTRA_PORT);
+
+ return 0;
+}
+
+static void __exit czc_tablet_exit(void)
+{
+}
+
Re: [GIT PULL 3/3] ARM: uniphier: UniPhier SoC updates for v4.19
On Thu, Jul 19, 2018 at 08:05:03AM +0900, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull UniPhier SoC changes for the v4.19 MW. > > Thanks! > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-soc-v4.19 > > for you to fetch changes up to ae93e694440a454609fa40725e16619c5a781768: > > ARM: uniphier: remove empty Makefile (2018-07-19 06:53:16 +0900) > > > UniPhier ARM SoC updates for v4.19 > > - enable ethernet and thermal drivers from multi_v7_defconfig > > - select RESET_CONTROLLER > > - remove empty arch/arm/mach-uniphier/Makefile > > > Kunihiko Hayashi (1): > ARM: multi_v7_defconfig: add CONFIG_UNIPHIER_THERMAL and CONFIG_SNI_AVE I renormalied multi_v7_defconfig for 4.18-rc3, so please base your branch on that to avoid conflicts. Also, we separate out defconfig updates to branches on their own. I can cherry-pick the branch apart but wanted to check with you before I do so in case it messes up your workflow. If it does, send a fresh pull request for SoC, and either one for the defconfig or just the patch and we can apply it directly. Thanks! -Olof
Re: [GIT PULL] ARM: at91: DT for 4.19
On Fri, Jul 20, 2018 at 10:18:59AM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Here are the unusually large DT PR for AT91. It contains mainly new DTs. > > There is a pm.c change that I'm including here so it is along with the > corresponding DT changes. > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-4.19-dt > > for you to fetch changes up to c8cbc1c20c29697e7335a5044fe6c60aa5c6e922: > > ARM: dts: at91: fix typos for SSC TD functions (2018-07-20 10:05:14 +0200) > > > AT91 DT for 4.19: > > - New boards from Laird: WB45N, WB50N, SOM60 modules and DVK, Gatwick > - fix the PMC compatibles > > > Alexandre Belloni (4): > dt-bindings: arm: remove PMC bindings > dt-bindings: clk: at91: Document all the PMC compatibles > ARM: at91: fix USB clock detection handling I guess this patch should have gone in a soc branch? Anyway, merged as-is, unlikely to cause conflicts. -Olof
Re: [GIT PULL 3/3] ARM: uniphier: UniPhier SoC updates for v4.19
On Thu, Jul 19, 2018 at 08:05:03AM +0900, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull UniPhier SoC changes for the v4.19 MW. > > Thanks! > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-soc-v4.19 > > for you to fetch changes up to ae93e694440a454609fa40725e16619c5a781768: > > ARM: uniphier: remove empty Makefile (2018-07-19 06:53:16 +0900) > > > UniPhier ARM SoC updates for v4.19 > > - enable ethernet and thermal drivers from multi_v7_defconfig > > - select RESET_CONTROLLER > > - remove empty arch/arm/mach-uniphier/Makefile > > > Kunihiko Hayashi (1): > ARM: multi_v7_defconfig: add CONFIG_UNIPHIER_THERMAL and CONFIG_SNI_AVE I renormalied multi_v7_defconfig for 4.18-rc3, so please base your branch on that to avoid conflicts. Also, we separate out defconfig updates to branches on their own. I can cherry-pick the branch apart but wanted to check with you before I do so in case it messes up your workflow. If it does, send a fresh pull request for SoC, and either one for the defconfig or just the patch and we can apply it directly. Thanks! -Olof
Re: [GIT PULL] ARM: at91: DT for 4.19
On Fri, Jul 20, 2018 at 10:18:59AM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Here are the unusually large DT PR for AT91. It contains mainly new DTs. > > There is a pm.c change that I'm including here so it is along with the > corresponding DT changes. > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-4.19-dt > > for you to fetch changes up to c8cbc1c20c29697e7335a5044fe6c60aa5c6e922: > > ARM: dts: at91: fix typos for SSC TD functions (2018-07-20 10:05:14 +0200) > > > AT91 DT for 4.19: > > - New boards from Laird: WB45N, WB50N, SOM60 modules and DVK, Gatwick > - fix the PMC compatibles > > > Alexandre Belloni (4): > dt-bindings: arm: remove PMC bindings > dt-bindings: clk: at91: Document all the PMC compatibles > ARM: at91: fix USB clock detection handling I guess this patch should have gone in a soc branch? Anyway, merged as-is, unlikely to cause conflicts. -Olof
Re: [GIT PULL] ARM: at91: SoC for 4.19
On Fri, Jul 20, 2018 at 10:20:30AM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Here is the SoC PR for 4.19. It is a cleanup of pm.c and the addition of > a new low power mode. > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-4.19-soc > > for you to fetch changes up to d7484f5c6b3b0565d2395aece2862f183581e1c1: > > ARM: at91: pm: configure wakeup sources for ULP1 mode (2018-07-17 15:08:12 > +0200) Merged, thanks! -Olof
Re: [GIT PULL 2/3] arm64: dts: uniphier: UniPhier DT updates for v4.19
On Thu, Jul 19, 2018 at 08:01:44AM +0900, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull UniPhier DT (64bit) updates for the v4.19 MW. > > Thanks! > > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-dt64-v4.19 > > for you to fetch changes up to 1470075d5e354da8f46f5aa2e6956de794eb406a: > > arm64: dts: uniphier: add headphone detect gpio for LD11 global > board (2018-07-19 06:43:12 +0900) Merged, thanks! -Olof
Re: [GIT PULL 1/3] ARM: dts: uniphier: UniPhier DT updates for v4.19
On Thu, Jul 19, 2018 at 08:01:06AM +0900, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull UniPhier DT (32bit) updates for the v4.19 MW. > > Thanks! > > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-dt-v4.19 > > for you to fetch changes up to 38dc27c85e642cd6229f3a4b2c85128501852158: > > ARM: dts: uniphier: Add missing cooling device properties for CPUs > (2018-07-19 06:42:16 +0900) Merged, thanks. -Olof
Re: [GIT PULL] ARM: at91: SoC for 4.19
On Fri, Jul 20, 2018 at 10:20:30AM +0200, Alexandre Belloni wrote: > Arnd, Olof, > > Here is the SoC PR for 4.19. It is a cleanup of pm.c and the addition of > a new low power mode. > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git > tags/at91-ab-4.19-soc > > for you to fetch changes up to d7484f5c6b3b0565d2395aece2862f183581e1c1: > > ARM: at91: pm: configure wakeup sources for ULP1 mode (2018-07-17 15:08:12 > +0200) Merged, thanks! -Olof
Re: [GIT PULL 2/3] arm64: dts: uniphier: UniPhier DT updates for v4.19
On Thu, Jul 19, 2018 at 08:01:44AM +0900, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull UniPhier DT (64bit) updates for the v4.19 MW. > > Thanks! > > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-dt64-v4.19 > > for you to fetch changes up to 1470075d5e354da8f46f5aa2e6956de794eb406a: > > arm64: dts: uniphier: add headphone detect gpio for LD11 global > board (2018-07-19 06:43:12 +0900) Merged, thanks! -Olof
Re: [GIT PULL 1/3] ARM: dts: uniphier: UniPhier DT updates for v4.19
On Thu, Jul 19, 2018 at 08:01:06AM +0900, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull UniPhier DT (32bit) updates for the v4.19 MW. > > Thanks! > > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-dt-v4.19 > > for you to fetch changes up to 38dc27c85e642cd6229f3a4b2c85128501852158: > > ARM: dts: uniphier: Add missing cooling device properties for CPUs > (2018-07-19 06:42:16 +0900) Merged, thanks. -Olof
Re: [PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
On 07/21/2018 01:00 PM, Anders Roxell wrote:
> JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
> error:
> drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
> drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of
> function ‘of_read_number’; did you mean ‘down_read_nested’?
> [-Werror=implicit-function-declaration]
>bank = of_read_number(prop, 1);
> ^~
> down_read_nested
>
> Make JZ4780_NEMC depend on OF.
>
> Fixes: ab99e11062c1 ("memory: jz4780-nemc: Allow selection of this driver
> when COMPILE_TEST=y")
> Reported-by: Randy Dunlap
> Signed-off-by: Anders Roxell
Acked-by: Randy Dunlap
Thanks.
> ---
> drivers/memory/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index a642552dfdc9..63389f075f1d 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -123,7 +123,7 @@ config JZ4780_NEMC
> bool "Ingenic JZ4780 SoC NEMC driver"
> default y
> depends on MACH_JZ4780 || COMPILE_TEST
> - depends on HAS_IOMEM
> + depends on HAS_IOMEM && OF
> help
> This driver is for the NAND/External Memory Controller (NEMC) in
> the Ingenic JZ4780. This controller is used to handle external
>
--
~Randy
Re: [PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
On 07/21/2018 01:00 PM, Anders Roxell wrote:
> JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
> error:
> drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
> drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of
> function ‘of_read_number’; did you mean ‘down_read_nested’?
> [-Werror=implicit-function-declaration]
>bank = of_read_number(prop, 1);
> ^~
> down_read_nested
>
> Make JZ4780_NEMC depend on OF.
>
> Fixes: ab99e11062c1 ("memory: jz4780-nemc: Allow selection of this driver
> when COMPILE_TEST=y")
> Reported-by: Randy Dunlap
> Signed-off-by: Anders Roxell
Acked-by: Randy Dunlap
Thanks.
> ---
> drivers/memory/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index a642552dfdc9..63389f075f1d 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -123,7 +123,7 @@ config JZ4780_NEMC
> bool "Ingenic JZ4780 SoC NEMC driver"
> default y
> depends on MACH_JZ4780 || COMPILE_TEST
> - depends on HAS_IOMEM
> + depends on HAS_IOMEM && OF
> help
> This driver is for the NAND/External Memory Controller (NEMC) in
> the Ingenic JZ4780. This controller is used to handle external
>
--
~Randy
[PATCH] drivers/pci/probe: Move variable bridge inside ifdef
When CONFIG_PCI_QUIRKS isn't enabled we get the warning below:
drivers/pci/probe.c: In function ‘pci_bus_read_dev_vendor_id’:
drivers/pci/probe.c:2221:18: warning: unused variable ‘bridge’
[-Wunused-variable]
struct pci_dev *bridge = bus->self;
^~
Move the declaration of variable bridge to inside the ifdef
CONFIG_PCI_QUIRKS.
Fixes: ac5ea104a279 ("PCI: Workaround IDT switch ACS Source Validation erratum")
Signed-off-by: Anders Roxell
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 1c581346c5b9..7a5323798312 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2218,9 +2218,9 @@ bool pci_bus_generic_read_dev_vendor_id(struct pci_bus
*bus, int devfn, u32 *l,
bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
int timeout)
{
+#ifdef CONFIG_PCI_QUIRKS
struct pci_dev *bridge = bus->self;
-#ifdef CONFIG_PCI_QUIRKS
/*
* Certain IDT switches have an issue where they improperly trigger
* ACS Source Validation errors on completions for config reads.
--
2.18.0
Re: [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen
On Sat, Jul 21, 2018 at 12:49 PM, M. Vefa Bicakci wrote:
> Commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
> exceptions/interrupts, to reduce speculation attack surface") unintendedly
> broke Xen PV virtual machines by clearing the %rbx register at the end of
> xen_failsafe_callback before the latter jumps to error_exit.
> error_exit expects the %rbx register to be a flag indicating whether
> there should be a return to kernel mode.
>
> This commit makes sure that the %rbx register is not cleared by
> the PUSH_AND_CLEAR_REGS macro, when the macro in question is instantiated
> by xen_failsafe_callback, to avoid the issue.
Seems like a genuine problem, but:
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index c7449f377a77..96e8ff34129e 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1129,7 +1129,7 @@ ENTRY(xen_failsafe_callback)
> addq$0x30, %rsp
> UNWIND_HINT_IRET_REGS
> pushq $-1 /* orig_ax = -1 => not a system call */
> - PUSH_AND_CLEAR_REGS
> + PUSH_AND_CLEAR_REGS clear_rbx=0
> ENCODE_FRAME_POINTER
> jmp error_exit
The old code first set RBX to zero then, if frame pointers are on,
sets it to some special non-zero value, then crosses its fingers and
hopes for the best. Your patched code just skips the zeroing part, so
RBX either contains the ENCODE_FRAME_POINTER result or is
uninitialized.
How about actually initializing rbx to something sensible like, say, 1?
[PATCH] drivers/pci/probe: Move variable bridge inside ifdef
When CONFIG_PCI_QUIRKS isn't enabled we get the warning below:
drivers/pci/probe.c: In function ‘pci_bus_read_dev_vendor_id’:
drivers/pci/probe.c:2221:18: warning: unused variable ‘bridge’
[-Wunused-variable]
struct pci_dev *bridge = bus->self;
^~
Move the declaration of variable bridge to inside the ifdef
CONFIG_PCI_QUIRKS.
Fixes: ac5ea104a279 ("PCI: Workaround IDT switch ACS Source Validation erratum")
Signed-off-by: Anders Roxell
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 1c581346c5b9..7a5323798312 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2218,9 +2218,9 @@ bool pci_bus_generic_read_dev_vendor_id(struct pci_bus
*bus, int devfn, u32 *l,
bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
int timeout)
{
+#ifdef CONFIG_PCI_QUIRKS
struct pci_dev *bridge = bus->self;
-#ifdef CONFIG_PCI_QUIRKS
/*
* Certain IDT switches have an issue where they improperly trigger
* ACS Source Validation errors on completions for config reads.
--
2.18.0
Re: [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen
On Sat, Jul 21, 2018 at 12:49 PM, M. Vefa Bicakci wrote:
> Commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
> exceptions/interrupts, to reduce speculation attack surface") unintendedly
> broke Xen PV virtual machines by clearing the %rbx register at the end of
> xen_failsafe_callback before the latter jumps to error_exit.
> error_exit expects the %rbx register to be a flag indicating whether
> there should be a return to kernel mode.
>
> This commit makes sure that the %rbx register is not cleared by
> the PUSH_AND_CLEAR_REGS macro, when the macro in question is instantiated
> by xen_failsafe_callback, to avoid the issue.
Seems like a genuine problem, but:
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index c7449f377a77..96e8ff34129e 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1129,7 +1129,7 @@ ENTRY(xen_failsafe_callback)
> addq$0x30, %rsp
> UNWIND_HINT_IRET_REGS
> pushq $-1 /* orig_ax = -1 => not a system call */
> - PUSH_AND_CLEAR_REGS
> + PUSH_AND_CLEAR_REGS clear_rbx=0
> ENCODE_FRAME_POINTER
> jmp error_exit
The old code first set RBX to zero then, if frame pointers are on,
sets it to some special non-zero value, then crosses its fingers and
hopes for the best. Your patched code just skips the zeroing part, so
RBX either contains the ENCODE_FRAME_POINTER result or is
uninitialized.
How about actually initializing rbx to something sensible like, say, 1?
Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements
On Sat, Jul 21, 2018 at 09:43:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote:
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> > allows disabling it, rendering such characters with a bright background
> > instead.
> > * due to my error, 256-color mode uses a much darker palette for conversion,
> > resulting in behaving inconsistently with 24-bit mode.
> >
> > The new code uses bright backgrounds when possible, enabled with \e[100m or
> > \e[48;m.
> >
> > Despite the whole idea following a VGA capability, this patchset doesn't
> > change vgacon yet, just fbcon. [Not breaking nvidia-proprietary.]
> >
> > Thus, let's enable unblinking on fbcon for now. We can flip that bit (in
> > register 0x10) later.
> >
> > This fixes the display of catimg and similar tools.
>
> I've applied the first patch, as it was obvious :)
>
> For the rest, can you make it a config option as Alan said? And I
> agree, we don't care about breaking nvidia systems, go ahead :)
The only thing such an option would be able to set is disabling blinking on
vgacon, which is not yet implemented. fbcon never blinks, and the only case
it can't display bright background is 1-bit black
I probably should change the line in fbcon:
+ vc->vc_unblinking = vc->vc_can_do_color;
to always use 1, but it doesn't matter either way. Only difference would be
matching the variable name ("unblinking" vs "shows_bright_bg").
Console drivers can interpret that bit of attribute as:
* blinking (vc_unblinking = 0)
* bright background (vc_unblinking = 1)
* neither (result is ignored down the pipeline)
The matrix is:
color b
---+---+--
fbbright bg neither
mda N/A blink
newport ?bright bg? ?N/A?
sti ?neither??
vga CGA/VGA: hardware switch (write to port) MDA: blink
sisusb??
Technically, every console can be made to blink by drawing/clearing affected
characters a few times per second, but that'd be quite a waste of coding
time and kernel size. There's a reason browsers dropped support for
and text-decoration:blink.
This patchset doesn't drop blink in any case that was supported before,
though. I did the easy part used by most people first (fbcon), so it can be
reviewed/merged. Doing the hard part is quite pointless if this is NAKed
(but obviously doesn't require actual merging).
But perhaps by "option" you mean letting the user drop blink with no
replacement, which might also be a good idea if configurable?
Meow!
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements
On Sat, Jul 21, 2018 at 09:43:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote:
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> > allows disabling it, rendering such characters with a bright background
> > instead.
> > * due to my error, 256-color mode uses a much darker palette for conversion,
> > resulting in behaving inconsistently with 24-bit mode.
> >
> > The new code uses bright backgrounds when possible, enabled with \e[100m or
> > \e[48;m.
> >
> > Despite the whole idea following a VGA capability, this patchset doesn't
> > change vgacon yet, just fbcon. [Not breaking nvidia-proprietary.]
> >
> > Thus, let's enable unblinking on fbcon for now. We can flip that bit (in
> > register 0x10) later.
> >
> > This fixes the display of catimg and similar tools.
>
> I've applied the first patch, as it was obvious :)
>
> For the rest, can you make it a config option as Alan said? And I
> agree, we don't care about breaking nvidia systems, go ahead :)
The only thing such an option would be able to set is disabling blinking on
vgacon, which is not yet implemented. fbcon never blinks, and the only case
it can't display bright background is 1-bit black
I probably should change the line in fbcon:
+ vc->vc_unblinking = vc->vc_can_do_color;
to always use 1, but it doesn't matter either way. Only difference would be
matching the variable name ("unblinking" vs "shows_bright_bg").
Console drivers can interpret that bit of attribute as:
* blinking (vc_unblinking = 0)
* bright background (vc_unblinking = 1)
* neither (result is ignored down the pipeline)
The matrix is:
color b
---+---+--
fbbright bg neither
mda N/A blink
newport ?bright bg? ?N/A?
sti ?neither??
vga CGA/VGA: hardware switch (write to port) MDA: blink
sisusb??
Technically, every console can be made to blink by drawing/clearing affected
characters a few times per second, but that'd be quite a waste of coding
time and kernel size. There's a reason browsers dropped support for
and text-decoration:blink.
This patchset doesn't drop blink in any case that was supported before,
though. I did the easy part used by most people first (fbcon), so it can be
reviewed/merged. Doing the hard part is quite pointless if this is NAKed
(but obviously doesn't require actual merging).
But perhaps by "option" you mean letting the user drop blink with no
replacement, which might also be a good idea if configurable?
Meow!
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
Hi Jerome,
On Sat, Jul 21, 2018 at 10:42 PM Jerome Brunet wrote:
>
> On Sat, 2018-07-21 at 22:01 +0200, Martin Blumenstingl wrote:
> > > +static struct clk_regmap gxbb_hdmi_pll_od = {
> > > + .data = &(struct clk_regmap_div_data){
> > > + .offset = HHI_HDMI_PLL_CNTL2,
> > > + .shift = 16,
> > > + .width = 2,
> > > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> > > + },
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "hdmi_pll_od",
> > > + .ops = _regmap_divider_ro_ops,
> > > + .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > > + .num_parents = 1,
> > > + .flags = CLK_GET_RATE_NOCACHE,
> >
> > why do we need CLK_GET_RATE_NOCACHE here?
> > also, shouldn't all _od clocks use CLK_SET_RATE_PARENT?
> > (this applies to all new _od clocks, not just this one)
>
> The goal was to retain the original behavior of the clock.
> The pll has CLK_GET_RATE_NOCACHE, which is why I put it again in the od
> dividers. Same goes for ro_ops
I missed that - thanks for the explanation!
> For the particular case of the HDMI PLL, the display driver still set the pll
> parameters m, n and ods directly which justify CLK_GET_RATE_NOCACHE for now.
> Of course, the goal is to remove this flag someday. I think there has been
> some
> good progress in the DRM driver to reach this goal.
>
> If we think the use CLK_GET_RATE_NOCACHE is not justified for some other
> plls, I
> would prefer if it was addressed in another patchset.
now that the reason is clear to me: I fully agree!
> Regarding SET_RATE_PARENT, with the pll set with ro_ops, it does not change
> anything but, I agree, it would be better to set flag for the future.
I see
adding SET_RATE_PARENT will probably save a bit of headache later on
when enabling the write operation of the PLL and then wondering why
the frequency is not changed
Regards
Martin
Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
Hi Jerome,
On Sat, Jul 21, 2018 at 10:42 PM Jerome Brunet wrote:
>
> On Sat, 2018-07-21 at 22:01 +0200, Martin Blumenstingl wrote:
> > > +static struct clk_regmap gxbb_hdmi_pll_od = {
> > > + .data = &(struct clk_regmap_div_data){
> > > + .offset = HHI_HDMI_PLL_CNTL2,
> > > + .shift = 16,
> > > + .width = 2,
> > > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> > > + },
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "hdmi_pll_od",
> > > + .ops = _regmap_divider_ro_ops,
> > > + .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > > + .num_parents = 1,
> > > + .flags = CLK_GET_RATE_NOCACHE,
> >
> > why do we need CLK_GET_RATE_NOCACHE here?
> > also, shouldn't all _od clocks use CLK_SET_RATE_PARENT?
> > (this applies to all new _od clocks, not just this one)
>
> The goal was to retain the original behavior of the clock.
> The pll has CLK_GET_RATE_NOCACHE, which is why I put it again in the od
> dividers. Same goes for ro_ops
I missed that - thanks for the explanation!
> For the particular case of the HDMI PLL, the display driver still set the pll
> parameters m, n and ods directly which justify CLK_GET_RATE_NOCACHE for now.
> Of course, the goal is to remove this flag someday. I think there has been
> some
> good progress in the DRM driver to reach this goal.
>
> If we think the use CLK_GET_RATE_NOCACHE is not justified for some other
> plls, I
> would prefer if it was addressed in another patchset.
now that the reason is clear to me: I fully agree!
> Regarding SET_RATE_PARENT, with the pll set with ro_ops, it does not change
> anything but, I agree, it would be better to set flag for the future.
I see
adding SET_RATE_PARENT will probably save a bit of headache later on
when enabling the write operation of the PLL and then wondering why
the frequency is not changed
Regards
Martin
Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables
Hi Jerome, On Sat, Jul 21, 2018 at 10:46 PM Jerome Brunet wrote: > > On Sat, 2018-07-21 at 22:16 +0200, Martin Blumenstingl wrote: > > > We could even add ranges instead of table when we know the PLL supports a > > > well-known continuous dividers range. > > > > I had a look at the sys_pll settings on Meson8b, here's what > > Meson8/Meson8b/Meson8m2 support for sys_pll: > > - 50..74 > > - 76 > > - 78 > > - 80 > > - 82 > > - 84 > > - 86 > > - 88 > > - 90 > > - 92 > > - 94 > > - 96 > > - 98 > > Are those values with the same predivider (n) value ? yes, all are using n = 1 > I suspect the ability of the DCO to lock might depends on its input rate and > an > m range > > So if n change, it might possible that the m range will be different. > > ... at least, that's my guess :) for the Meson8b's SYS_PLL Amlogic's GPL kernel is using bits 15:14 in HHI_SYS_PLL_CNTL for frequencies above 1.64GHz (below that these reserved bits are always 0). if the values are useful for you (format is: frequency, m, n, od and bits 15:14. what's missing here is the "cpu_scale_div" divider which is for example why you'll see the "56, 1, 2, 0" tuple multiple times): SYS_PLL(24000, 56, 1, 2, 0) SYS_PLL(48000, 64, 1, 2, 0) SYS_PLL(72000, 72, 1, 2, 0) SYS_PLL(96000, 64, 1, 2, 0) SYS_PLL(12, 80, 1, 2, 0) SYS_PLL(144000, 96, 1, 2, 0) SYS_PLL(168000, 56, 1, 1, 0) SYS_PLL(192000, 64, 1, 1, 0) SYS_PLL(216000, 72, 1, 1, 0) SYS_PLL(24, 80, 1, 1, 0) SYS_PLL(264000, 88, 1, 1, 0) SYS_PLL(288000, 96, 1, 1, 0) SYS_PLL(312000, 52, 1, 2, 0) SYS_PLL(336000, 56, 1, 2, 0) SYS_PLL(36, 60, 1, 2, 0) SYS_PLL(384000, 64, 1, 2, 0) SYS_PLL(408000, 68, 1, 2, 0) SYS_PLL(432000, 72, 1, 2, 0) SYS_PLL(456000, 76, 1, 2, 0) SYS_PLL(48, 80, 1, 2, 0) SYS_PLL(504000, 84, 1, 2, 0) SYS_PLL(528000, 88, 1, 2, 0) SYS_PLL(552000, 92, 1, 2, 0) SYS_PLL(576000, 96, 1, 2, 0) SYS_PLL(60, 50, 1, 1, 0) SYS_PLL(624000, 52, 1, 1, 0) SYS_PLL(648000, 54, 1, 1, 0) SYS_PLL(672000, 56, 1, 1, 0) SYS_PLL(696000, 58, 1, 1, 0) SYS_PLL(72, 60, 1, 1, 0) SYS_PLL(744000, 62, 1, 1, 0) SYS_PLL(768000, 64, 1, 1, 0) SYS_PLL(792000, 66, 1, 1, 0) SYS_PLL(816000, 68, 1, 1, 0) SYS_PLL(84, 70, 1, 1, 0) SYS_PLL(864000, 72, 1, 1, 0) SYS_PLL(888000, 74, 1, 1, 0) SYS_PLL(912000, 76, 1, 1, 0) SYS_PLL(936000, 78, 1, 1, 0) SYS_PLL(96, 80, 1, 1, 0) SYS_PLL(984000, 82, 1, 1, 0) SYS_PLL(1008000, 84, 1, 1, 0) SYS_PLL(1032000, 86, 1, 1, 0) SYS_PLL(1056000, 88, 1, 1, 0) SYS_PLL(108, 90, 1, 1, 0) SYS_PLL(1104000, 92, 1, 1, 0) SYS_PLL(1128000, 94, 1, 1, 0) SYS_PLL(1152000, 96, 1, 1, 0) SYS_PLL(1176000, 98, 1, 1, 0) SYS_PLL(120, 50, 1, 0, 0) SYS_PLL(1224000, 51, 1, 0, 0) SYS_PLL(1248000, 52, 1, 0, 0) SYS_PLL(1272000, 53, 1, 0, 0) SYS_PLL(1296000, 54, 1, 0, 0) SYS_PLL(132, 55, 1, 0, 0) SYS_PLL(1344000, 56, 1, 0, 0) SYS_PLL(1368000, 57, 1, 0, 0) SYS_PLL(1392000, 58, 1, 0, 0) SYS_PLL(1416000, 59, 1, 0, 0) SYS_PLL(144, 60, 1, 0, 0) SYS_PLL(1464000, 61, 1, 0, 0) SYS_PLL(1488000, 62, 1, 0, 0) SYS_PLL(1512000, 63, 1, 0, 0) SYS_PLL(1536000, 64, 1, 0, 0) SYS_PLL(156, 65, 1, 0, 0) SYS_PLL(1584000, 66, 1, 0, 0) SYS_PLL(1608000, 67, 1, 0, 0) SYS_PLL(1632000, 68, 1, 0, 0) SYS_PLL(1656000, 68, 1, 0, 1) SYS_PLL(168, 68, 1, 0, 2) SYS_PLL(1704000, 68, 1, 0, 3) SYS_PLL(1728000, 69, 1, 0, 0) SYS_PLL(1752000, 69, 1, 0, 1) SYS_PLL(1776000, 69, 1, 0, 2) SYS_PLL(180, 69, 1, 0, 3) SYS_PLL(1824000, 70, 1, 0, 0) SYS_PLL(1848000, 70, 1, 0, 1) SYS_PLL(1872000, 70, 1, 0, 2) SYS_PLL(1896000, 70, 1, 0, 3) SYS_PLL(192, 71, 1, 0, 0) SYS_PLL(1944000, 71, 1, 0, 1) SYS_PLL(1968000, 71, 1, 0, 2) SYS_PLL(1992000, 71, 1, 0, 3) SYS_PLL(2016000, 72, 1, 0, 0) SYS_PLL(204, 72, 1, 0, 1) SYS_PLL(2064000, 72, 1, 0, 2) SYS_PLL(2088000, 72, 1, 0, 3) SYS_PLL(2112000, 73, 1, 0, 0) Regards Martin
Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables
Hi Jerome, On Sat, Jul 21, 2018 at 10:46 PM Jerome Brunet wrote: > > On Sat, 2018-07-21 at 22:16 +0200, Martin Blumenstingl wrote: > > > We could even add ranges instead of table when we know the PLL supports a > > > well-known continuous dividers range. > > > > I had a look at the sys_pll settings on Meson8b, here's what > > Meson8/Meson8b/Meson8m2 support for sys_pll: > > - 50..74 > > - 76 > > - 78 > > - 80 > > - 82 > > - 84 > > - 86 > > - 88 > > - 90 > > - 92 > > - 94 > > - 96 > > - 98 > > Are those values with the same predivider (n) value ? yes, all are using n = 1 > I suspect the ability of the DCO to lock might depends on its input rate and > an > m range > > So if n change, it might possible that the m range will be different. > > ... at least, that's my guess :) for the Meson8b's SYS_PLL Amlogic's GPL kernel is using bits 15:14 in HHI_SYS_PLL_CNTL for frequencies above 1.64GHz (below that these reserved bits are always 0). if the values are useful for you (format is: frequency, m, n, od and bits 15:14. what's missing here is the "cpu_scale_div" divider which is for example why you'll see the "56, 1, 2, 0" tuple multiple times): SYS_PLL(24000, 56, 1, 2, 0) SYS_PLL(48000, 64, 1, 2, 0) SYS_PLL(72000, 72, 1, 2, 0) SYS_PLL(96000, 64, 1, 2, 0) SYS_PLL(12, 80, 1, 2, 0) SYS_PLL(144000, 96, 1, 2, 0) SYS_PLL(168000, 56, 1, 1, 0) SYS_PLL(192000, 64, 1, 1, 0) SYS_PLL(216000, 72, 1, 1, 0) SYS_PLL(24, 80, 1, 1, 0) SYS_PLL(264000, 88, 1, 1, 0) SYS_PLL(288000, 96, 1, 1, 0) SYS_PLL(312000, 52, 1, 2, 0) SYS_PLL(336000, 56, 1, 2, 0) SYS_PLL(36, 60, 1, 2, 0) SYS_PLL(384000, 64, 1, 2, 0) SYS_PLL(408000, 68, 1, 2, 0) SYS_PLL(432000, 72, 1, 2, 0) SYS_PLL(456000, 76, 1, 2, 0) SYS_PLL(48, 80, 1, 2, 0) SYS_PLL(504000, 84, 1, 2, 0) SYS_PLL(528000, 88, 1, 2, 0) SYS_PLL(552000, 92, 1, 2, 0) SYS_PLL(576000, 96, 1, 2, 0) SYS_PLL(60, 50, 1, 1, 0) SYS_PLL(624000, 52, 1, 1, 0) SYS_PLL(648000, 54, 1, 1, 0) SYS_PLL(672000, 56, 1, 1, 0) SYS_PLL(696000, 58, 1, 1, 0) SYS_PLL(72, 60, 1, 1, 0) SYS_PLL(744000, 62, 1, 1, 0) SYS_PLL(768000, 64, 1, 1, 0) SYS_PLL(792000, 66, 1, 1, 0) SYS_PLL(816000, 68, 1, 1, 0) SYS_PLL(84, 70, 1, 1, 0) SYS_PLL(864000, 72, 1, 1, 0) SYS_PLL(888000, 74, 1, 1, 0) SYS_PLL(912000, 76, 1, 1, 0) SYS_PLL(936000, 78, 1, 1, 0) SYS_PLL(96, 80, 1, 1, 0) SYS_PLL(984000, 82, 1, 1, 0) SYS_PLL(1008000, 84, 1, 1, 0) SYS_PLL(1032000, 86, 1, 1, 0) SYS_PLL(1056000, 88, 1, 1, 0) SYS_PLL(108, 90, 1, 1, 0) SYS_PLL(1104000, 92, 1, 1, 0) SYS_PLL(1128000, 94, 1, 1, 0) SYS_PLL(1152000, 96, 1, 1, 0) SYS_PLL(1176000, 98, 1, 1, 0) SYS_PLL(120, 50, 1, 0, 0) SYS_PLL(1224000, 51, 1, 0, 0) SYS_PLL(1248000, 52, 1, 0, 0) SYS_PLL(1272000, 53, 1, 0, 0) SYS_PLL(1296000, 54, 1, 0, 0) SYS_PLL(132, 55, 1, 0, 0) SYS_PLL(1344000, 56, 1, 0, 0) SYS_PLL(1368000, 57, 1, 0, 0) SYS_PLL(1392000, 58, 1, 0, 0) SYS_PLL(1416000, 59, 1, 0, 0) SYS_PLL(144, 60, 1, 0, 0) SYS_PLL(1464000, 61, 1, 0, 0) SYS_PLL(1488000, 62, 1, 0, 0) SYS_PLL(1512000, 63, 1, 0, 0) SYS_PLL(1536000, 64, 1, 0, 0) SYS_PLL(156, 65, 1, 0, 0) SYS_PLL(1584000, 66, 1, 0, 0) SYS_PLL(1608000, 67, 1, 0, 0) SYS_PLL(1632000, 68, 1, 0, 0) SYS_PLL(1656000, 68, 1, 0, 1) SYS_PLL(168, 68, 1, 0, 2) SYS_PLL(1704000, 68, 1, 0, 3) SYS_PLL(1728000, 69, 1, 0, 0) SYS_PLL(1752000, 69, 1, 0, 1) SYS_PLL(1776000, 69, 1, 0, 2) SYS_PLL(180, 69, 1, 0, 3) SYS_PLL(1824000, 70, 1, 0, 0) SYS_PLL(1848000, 70, 1, 0, 1) SYS_PLL(1872000, 70, 1, 0, 2) SYS_PLL(1896000, 70, 1, 0, 3) SYS_PLL(192, 71, 1, 0, 0) SYS_PLL(1944000, 71, 1, 0, 1) SYS_PLL(1968000, 71, 1, 0, 2) SYS_PLL(1992000, 71, 1, 0, 3) SYS_PLL(2016000, 72, 1, 0, 0) SYS_PLL(204, 72, 1, 0, 1) SYS_PLL(2064000, 72, 1, 0, 2) SYS_PLL(2088000, 72, 1, 0, 3) SYS_PLL(2112000, 73, 1, 0, 0) Regards Martin
[PATCH 1/1] x86/apic: Future-proof TSC_DEADLINE quirk for SKX
From: Len Brown
All SKX with stepping higher than 4 support the TSC_DEADLINE,
no matter the microcode version.
Fixes: 616dd5872e ("x86/apic: Update TSC_DEADLINE quirk with additional SKX
stepping")
Signed-off-by: Len Brown
---
Without this patch, upcoming SKX steppings will not be able to use
their TSC_DEADLINE timer.
arch/x86/kernel/apic/apic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b203af0855b5..5caf8890fbe4 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -573,6 +573,9 @@ static u32 skx_deadline_rev(void)
case 0x04: return 0x0214;
}
+ if (boot_cpu_data.x86_stepping > 4)
+ return 0;
+
return ~0U;
}
--
2.18.0-rc0
[PATCH 1/1] x86/apic: Future-proof TSC_DEADLINE quirk for SKX
From: Len Brown
All SKX with stepping higher than 4 support the TSC_DEADLINE,
no matter the microcode version.
Fixes: 616dd5872e ("x86/apic: Update TSC_DEADLINE quirk with additional SKX
stepping")
Signed-off-by: Len Brown
---
Without this patch, upcoming SKX steppings will not be able to use
their TSC_DEADLINE timer.
arch/x86/kernel/apic/apic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b203af0855b5..5caf8890fbe4 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -573,6 +573,9 @@ static u32 skx_deadline_rev(void)
case 0x04: return 0x0214;
}
+ if (boot_cpu_data.x86_stepping > 4)
+ return 0;
+
return ~0U;
}
--
2.18.0-rc0
Re: [PATCH 1/3] iio: adc: add support for mcp3911
Hello,
> MCP3911 is a dual channel Analog Front End (AFE) containing two
> synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
some comments below...
> Signed-off-by: Marcus Folkesson
> Signed-off-by: Kent Gustavsson
> ---
> drivers/iio/adc/Kconfig | 10 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/mcp3911.c | 444
> ++
> 3 files changed, 455 insertions(+)
> create mode 100644 drivers/iio/adc/mcp3911.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 15606f237480..f9a41fa96fcc 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -501,6 +501,16 @@ config MCP3422
> This driver can also be built as a module. If so, the module will be
> called mcp3422.
>
> +config MCP3911
> + tristate "Microchip Technology MCP3911 driver"
> + depends on SPI
> + help
> + Say yes here to build support for Microchip Technology's MCP3911
> + analog to digital converter.
> +
> + This driver can also be built as a module. If so, the module will be
> + called mcp3911.
> +
> config MEDIATEK_MT6577_AUXADC
> tristate "MediaTek AUXADC driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 28a9423997f3..3cfebfff7d26 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o
> obj-$(CONFIG_MAX9611) += max9611.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> +obj-$(CONFIG_MCP3911) += mcp3911.o
> obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
> new file mode 100644
> index ..be74cb15827b
> --- /dev/null
> +++ b/drivers/iio/adc/mcp3911.c
> @@ -0,0 +1,444 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Microchip MCP3911, Two-channel Analog Front End
> + *
> + * Copyright (C) 2018 Marcus Folkesson
> + * Copyright (C) 2018 Kent Gustavsson
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MCP3911_REG_CHANNEL0 0x00
> +#define MCP3911_REG_CHANNEL1 0x03
> +#define MCP3911_REG_MOD 0x06
> +#define MCP3911_REG_PHASE0x07
> +
> +#define MCP3911_REG_GAIN 0x09
> +#define MCP3911_GAIN_MASK(ch)(0x7 << 3*ch)
space around * operator, maybe parenthesis around variable, i.e
(0x07 << (3 * (ch)))
> +#define MCP3911_GAIN_VAL(ch, val)((val << 3*ch) & MCP3911_GAIN_MASK(ch))
> +
> +#define MCP3911_REG_STATUSCOM0x0a
> +#define MCP3911_STATUSCOM_CH1_24WIDTHBIT(4)
> +#define MCP3911_STATUSCOM_CH0_24WIDTHBIT(3)
> +#define MCP3911_STATUSCOM_EN_OFFCAL BIT(2)
> +#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1)
> +
> +#define MCP3911_REG_CONFIG 0x0c
> +#define MCP3911_CONFIG_CLKEXTBIT(1)
> +#define MCP3911_CONFIG_VREFEXT BIT(2)
> +
> +#define MCP3911_REG_OFFCAL_CH0 0x0e
> +#define MCP3911_REG_GAINCAL_CH0 0x11
> +#define MCP3911_REG_OFFCAL_CH1 0x14
> +#define MCP3911_REG_GAINCAL_CH1 0x17
> +#define MCP3911_REG_VREFCAL 0x1a
> +
> +#define MCP3911_CHANNEL(x) (MCP3911_REG_CHANNEL0 + x * 3)
> +#define MCP3911_OFFCAL(x)(MCP3911_REG_OFFCAL_CH0 + x * 6)
> +#define MCP3911_GAINCAL(x) (MCP3911_REG_GAINCAL_CH0 + x * 6)
> +
delete newline
> +
> +/* Internal voltage reference in uV */
> +#define MCP3911_INT_VREF_UV 120
> +
> +#define REG_READ(reg, id)(((reg << 1) | (id << 5) | (1 << 0)) & 0xff)
> +#define REG_WRITE(reg, id) (((reg << 1) | (id << 5) | (0 << 0)) & 0xff)
MCP3911_ prefix please
parenthesis around variables
> +
> +#define MCP3911_NUM_CHANNELS 2
> +
> +
> +struct mcp3911 {
> + struct spi_device *spi;
> + struct device_node *np;
> + struct mutex lock;
> +
> + u32 gain[MCP3911_NUM_CHANNELS];
> + u32 width[MCP3911_NUM_CHANNELS];
> +
> + u32 dev_addr;
> + bool vrefext;
> + struct regulator *vref;
> +};
> +
> +static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
> +{
> + int ret;
> +
> + reg = REG_READ(reg, adc->dev_addr);
> + ret = spi_write_then_read(adc->spi, , 1, val, len);
> + if (ret < 0)
> + return ret;
> +
> + *val <<= ((4-len)*8);
space around - and * operator, here and elsewhere
shouldn't the endiness conversion happen before the value is shifted?
(here and below)?
> + be32_to_cpus(val);
> + dev_dbg(>spi->dev, "Reading 0x%x from register 0x%x\n", *val,
> + reg>>1);
> + return ret;
> +}
> +
> +static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32
Re: [PATCH 1/3] iio: adc: add support for mcp3911
Hello,
> MCP3911 is a dual channel Analog Front End (AFE) containing two
> synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
some comments below...
> Signed-off-by: Marcus Folkesson
> Signed-off-by: Kent Gustavsson
> ---
> drivers/iio/adc/Kconfig | 10 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/mcp3911.c | 444
> ++
> 3 files changed, 455 insertions(+)
> create mode 100644 drivers/iio/adc/mcp3911.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 15606f237480..f9a41fa96fcc 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -501,6 +501,16 @@ config MCP3422
> This driver can also be built as a module. If so, the module will be
> called mcp3422.
>
> +config MCP3911
> + tristate "Microchip Technology MCP3911 driver"
> + depends on SPI
> + help
> + Say yes here to build support for Microchip Technology's MCP3911
> + analog to digital converter.
> +
> + This driver can also be built as a module. If so, the module will be
> + called mcp3911.
> +
> config MEDIATEK_MT6577_AUXADC
> tristate "MediaTek AUXADC driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 28a9423997f3..3cfebfff7d26 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o
> obj-$(CONFIG_MAX9611) += max9611.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> +obj-$(CONFIG_MCP3911) += mcp3911.o
> obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
> new file mode 100644
> index ..be74cb15827b
> --- /dev/null
> +++ b/drivers/iio/adc/mcp3911.c
> @@ -0,0 +1,444 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Microchip MCP3911, Two-channel Analog Front End
> + *
> + * Copyright (C) 2018 Marcus Folkesson
> + * Copyright (C) 2018 Kent Gustavsson
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MCP3911_REG_CHANNEL0 0x00
> +#define MCP3911_REG_CHANNEL1 0x03
> +#define MCP3911_REG_MOD 0x06
> +#define MCP3911_REG_PHASE0x07
> +
> +#define MCP3911_REG_GAIN 0x09
> +#define MCP3911_GAIN_MASK(ch)(0x7 << 3*ch)
space around * operator, maybe parenthesis around variable, i.e
(0x07 << (3 * (ch)))
> +#define MCP3911_GAIN_VAL(ch, val)((val << 3*ch) & MCP3911_GAIN_MASK(ch))
> +
> +#define MCP3911_REG_STATUSCOM0x0a
> +#define MCP3911_STATUSCOM_CH1_24WIDTHBIT(4)
> +#define MCP3911_STATUSCOM_CH0_24WIDTHBIT(3)
> +#define MCP3911_STATUSCOM_EN_OFFCAL BIT(2)
> +#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1)
> +
> +#define MCP3911_REG_CONFIG 0x0c
> +#define MCP3911_CONFIG_CLKEXTBIT(1)
> +#define MCP3911_CONFIG_VREFEXT BIT(2)
> +
> +#define MCP3911_REG_OFFCAL_CH0 0x0e
> +#define MCP3911_REG_GAINCAL_CH0 0x11
> +#define MCP3911_REG_OFFCAL_CH1 0x14
> +#define MCP3911_REG_GAINCAL_CH1 0x17
> +#define MCP3911_REG_VREFCAL 0x1a
> +
> +#define MCP3911_CHANNEL(x) (MCP3911_REG_CHANNEL0 + x * 3)
> +#define MCP3911_OFFCAL(x)(MCP3911_REG_OFFCAL_CH0 + x * 6)
> +#define MCP3911_GAINCAL(x) (MCP3911_REG_GAINCAL_CH0 + x * 6)
> +
delete newline
> +
> +/* Internal voltage reference in uV */
> +#define MCP3911_INT_VREF_UV 120
> +
> +#define REG_READ(reg, id)(((reg << 1) | (id << 5) | (1 << 0)) & 0xff)
> +#define REG_WRITE(reg, id) (((reg << 1) | (id << 5) | (0 << 0)) & 0xff)
MCP3911_ prefix please
parenthesis around variables
> +
> +#define MCP3911_NUM_CHANNELS 2
> +
> +
> +struct mcp3911 {
> + struct spi_device *spi;
> + struct device_node *np;
> + struct mutex lock;
> +
> + u32 gain[MCP3911_NUM_CHANNELS];
> + u32 width[MCP3911_NUM_CHANNELS];
> +
> + u32 dev_addr;
> + bool vrefext;
> + struct regulator *vref;
> +};
> +
> +static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
> +{
> + int ret;
> +
> + reg = REG_READ(reg, adc->dev_addr);
> + ret = spi_write_then_read(adc->spi, , 1, val, len);
> + if (ret < 0)
> + return ret;
> +
> + *val <<= ((4-len)*8);
space around - and * operator, here and elsewhere
shouldn't the endiness conversion happen before the value is shifted?
(here and below)?
> + be32_to_cpus(val);
> + dev_dbg(>spi->dev, "Reading 0x%x from register 0x%x\n", *val,
> + reg>>1);
> + return ret;
> +}
> +
> +static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 13e66ceea1600f1061181acc2d4e0fac1a7d0333: Merge tag 'omap-for-v4.18/fixes-rc4-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2018-07-14 15:14:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to 5858610f0dd76151c4e12420fd11801d23737663: Merge tag 'imx-fixes-4.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes (2018-07-20 14:22:11 -0700) ARM: SoC fixes for 4.18-rc - Fix interrupt type on ethernet switch for i.MX-based RDU2 - GPC on i.MX exposed too large a register window which resulted in userspace being able to crash the machine. - Fixup of bad merge resolution moving GPIO DT nodes under pinctrl on droid4. Anson Huang (1): soc: imx: gpc: restrict register range for regmap access Olof Johansson (3): Merge tag 'omap-for-v4.18/fixes-rc5-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'imx-fixes-4.18-3' of git://git.kernel.org/.../shawnguo/linux into fixes Merge tag 'imx-fixes-4.18-4' of git://git.kernel.org/.../shawnguo/linux into fixes Pavel Machek (1): ARM: dts: omap4-droid4: fix dts w.r.t. pwm Uwe Kleine-König (1): ARM: dts: imx6: RDU2: fix irq type for mv88e6xxx switch arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 +- arch/arm/boot/dts/omap4-droid4-xt894.dts | 9 +++-- drivers/soc/imx/gpc.c| 21 + 3 files changed, 25 insertions(+), 7 deletions(-)
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 13e66ceea1600f1061181acc2d4e0fac1a7d0333: Merge tag 'omap-for-v4.18/fixes-rc4-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2018-07-14 15:14:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to 5858610f0dd76151c4e12420fd11801d23737663: Merge tag 'imx-fixes-4.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes (2018-07-20 14:22:11 -0700) ARM: SoC fixes for 4.18-rc - Fix interrupt type on ethernet switch for i.MX-based RDU2 - GPC on i.MX exposed too large a register window which resulted in userspace being able to crash the machine. - Fixup of bad merge resolution moving GPIO DT nodes under pinctrl on droid4. Anson Huang (1): soc: imx: gpc: restrict register range for regmap access Olof Johansson (3): Merge tag 'omap-for-v4.18/fixes-rc5-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'imx-fixes-4.18-3' of git://git.kernel.org/.../shawnguo/linux into fixes Merge tag 'imx-fixes-4.18-4' of git://git.kernel.org/.../shawnguo/linux into fixes Pavel Machek (1): ARM: dts: omap4-droid4: fix dts w.r.t. pwm Uwe Kleine-König (1): ARM: dts: imx6: RDU2: fix irq type for mv88e6xxx switch arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 +- arch/arm/boot/dts/omap4-droid4-xt894.dts | 9 +++-- drivers/soc/imx/gpc.c| 21 + 3 files changed, 25 insertions(+), 7 deletions(-)
Re: [PATCH 1/3] perf/core: Make sure the ring-buffer is mapped in all page-tables
On Fri, Jul 20, 2018 at 3:20 PM Andy Lutomirski wrote: > Thanks for digging! The problem was presumably that vmalloc_fault() will > IRET and re-enable NMIs on the way out. > But we’ve supported page faults on user memory in NMI handlers on 32-bit and > 64-bit for quite a while, and it’s fine now. > > I would remove the warning, re-test, and revert the other patch. Agreed. I don't think we have any issues with page faults during NMI any more. Afaik the kprobe people depend on it. That said, 64-bit mode has that scary PV-op case (arch_flush_lazy_mmu_mode). Being PV mode, I can't find it in myself to worry about it, I'm assuming it's ok. Linus
Re: [PATCH 1/3] perf/core: Make sure the ring-buffer is mapped in all page-tables
On Fri, Jul 20, 2018 at 3:20 PM Andy Lutomirski wrote: > Thanks for digging! The problem was presumably that vmalloc_fault() will > IRET and re-enable NMIs on the way out. > But we’ve supported page faults on user memory in NMI handlers on 32-bit and > 64-bit for quite a while, and it’s fine now. > > I would remove the warning, re-test, and revert the other patch. Agreed. I don't think we have any issues with page faults during NMI any more. Afaik the kprobe people depend on it. That said, 64-bit mode has that scary PV-op case (arch_flush_lazy_mmu_mode). Being PV mode, I can't find it in myself to worry about it, I'm assuming it's ok. Linus
Re: [PATCH 0/3] clk: meson: clk-pll driver update
On Sat, 2018-07-21 at 22:17 +0200, Martin Blumenstingl wrote: > > This series has been tested on the gxl libretech cc and axg s400. > > I did not test it on meson8b yet. > > I had some comments on patch #2 > once that is fixed I can help testing on Meson8b (if you give me a few > days...) I don't intend to make another PR to clk in this cycle, unless something critical comes up. No rush.
Re: [PATCH 0/3] clk: meson: clk-pll driver update
On Sat, 2018-07-21 at 22:17 +0200, Martin Blumenstingl wrote: > > This series has been tested on the gxl libretech cc and axg s400. > > I did not test it on meson8b yet. > > I had some comments on patch #2 > once that is fixed I can help testing on Meson8b (if you give me a few > days...) I don't intend to make another PR to clk in this cycle, unless something critical comes up. No rush.
Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables
On Sat, 2018-07-21 at 22:16 +0200, Martin Blumenstingl wrote: > > We could even add ranges instead of table when we know the PLL supports a > > well-known continuous dividers range. > > I had a look at the sys_pll settings on Meson8b, here's what > Meson8/Meson8b/Meson8m2 support for sys_pll: > - 50..74 > - 76 > - 78 > - 80 > - 82 > - 84 > - 86 > - 88 > - 90 > - 92 > - 94 > - 96 > - 98 Are those values with the same predivider (n) value ? I suspect the ability of the DCO to lock might depends on its input rate and an m range So if n change, it might possible that the m range will be different. ... at least, that's my guess :) > > (I'm providing this info because it may help finding a decision > whether ranges are good or not. I have no preference)
Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables
On Sat, 2018-07-21 at 22:16 +0200, Martin Blumenstingl wrote: > > We could even add ranges instead of table when we know the PLL supports a > > well-known continuous dividers range. > > I had a look at the sys_pll settings on Meson8b, here's what > Meson8/Meson8b/Meson8m2 support for sys_pll: > - 50..74 > - 76 > - 78 > - 80 > - 82 > - 84 > - 86 > - 88 > - 90 > - 92 > - 94 > - 96 > - 98 Are those values with the same predivider (n) value ? I suspect the ability of the DCO to lock might depends on its input rate and an m range So if n change, it might possible that the m range will be different. ... at least, that's my guess :) > > (I'm providing this info because it may help finding a decision > whether ranges are good or not. I have no preference)
Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
On Sat, 2018-07-21 at 22:01 +0200, Martin Blumenstingl wrote:
> > +static struct clk_regmap gxbb_hdmi_pll_od = {
> > + .data = &(struct clk_regmap_div_data){
> > + .offset = HHI_HDMI_PLL_CNTL2,
> > + .shift = 16,
> > + .width = 2,
> > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> > + },
> > + .hw.init = &(struct clk_init_data){
> > + .name = "hdmi_pll_od",
> > + .ops = _regmap_divider_ro_ops,
> > + .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > + .num_parents = 1,
> > + .flags = CLK_GET_RATE_NOCACHE,
>
> why do we need CLK_GET_RATE_NOCACHE here?
> also, shouldn't all _od clocks use CLK_SET_RATE_PARENT?
> (this applies to all new _od clocks, not just this one)
The goal was to retain the original behavior of the clock.
The pll has CLK_GET_RATE_NOCACHE, which is why I put it again in the od
dividers. Same goes for ro_ops
For the particular case of the HDMI PLL, the display driver still set the pll
parameters m, n and ods directly which justify CLK_GET_RATE_NOCACHE for now.
Of course, the goal is to remove this flag someday. I think there has been some
good progress in the DRM driver to reach this goal.
If we think the use CLK_GET_RATE_NOCACHE is not justified for some other plls, I
would prefer if it was addressed in another patchset.
Regarding SET_RATE_PARENT, with the pll set with ro_ops, it does not change
anything but, I agree, it would be better to set flag for the future.
Cheers
Jerome
Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
On Sat, 2018-07-21 at 22:01 +0200, Martin Blumenstingl wrote:
> > +static struct clk_regmap gxbb_hdmi_pll_od = {
> > + .data = &(struct clk_regmap_div_data){
> > + .offset = HHI_HDMI_PLL_CNTL2,
> > + .shift = 16,
> > + .width = 2,
> > + .flags = CLK_DIVIDER_POWER_OF_TWO,
> > + },
> > + .hw.init = &(struct clk_init_data){
> > + .name = "hdmi_pll_od",
> > + .ops = _regmap_divider_ro_ops,
> > + .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > + .num_parents = 1,
> > + .flags = CLK_GET_RATE_NOCACHE,
>
> why do we need CLK_GET_RATE_NOCACHE here?
> also, shouldn't all _od clocks use CLK_SET_RATE_PARENT?
> (this applies to all new _od clocks, not just this one)
The goal was to retain the original behavior of the clock.
The pll has CLK_GET_RATE_NOCACHE, which is why I put it again in the od
dividers. Same goes for ro_ops
For the particular case of the HDMI PLL, the display driver still set the pll
parameters m, n and ods directly which justify CLK_GET_RATE_NOCACHE for now.
Of course, the goal is to remove this flag someday. I think there has been some
good progress in the DRM driver to reach this goal.
If we think the use CLK_GET_RATE_NOCACHE is not justified for some other plls, I
would prefer if it was addressed in another patchset.
Regarding SET_RATE_PARENT, with the pll set with ro_ops, it does not change
anything but, I agree, it would be better to set flag for the future.
Cheers
Jerome
Re: [PATCH 1/3] clk: meson: clk-pll: add enable bit
On Sat, 2018-07-21 at 21:48 +0200, Martin Blumenstingl wrote:
> > @@ -250,11 +264,15 @@ static const struct reg_sequence axg_hifi_init_regs[]
> > = {
> > { .reg = HHI_HIFI_PLL_CNTL3,.def = 0x0a6a3a88 },
> > { .reg = HHI_HIFI_PLL_CNTL4,.def = 0xc04d },
> > { .reg = HHI_HIFI_PLL_CNTL5,.def = 0x00058000 },
> > - { .reg = HHI_HIFI_PLL_CNTL, .def = 0x40010250 },
>
> is this change on purpose? this line set en, m, n, l and od before
> maybe you can document it in the commit message
Yes the change is on purpose, but as you pointed out it is worth a comment
Actually, when taking od out of the pll driver, I remembered this 'initial
setting' and it kinda bothered me
If the od divider registers after the DCO, the value could have changed with it,
which is why I wanted to remove the write on this register
As you pointed out, in this register, we find m, n, od ... and enable. In a way,
removing this register setting was the reason why I wanted to add the enable bit
to begin with :)
Re: [PATCH 1/3] clk: meson: clk-pll: add enable bit
On Sat, 2018-07-21 at 21:48 +0200, Martin Blumenstingl wrote:
> > @@ -250,11 +264,15 @@ static const struct reg_sequence axg_hifi_init_regs[]
> > = {
> > { .reg = HHI_HIFI_PLL_CNTL3,.def = 0x0a6a3a88 },
> > { .reg = HHI_HIFI_PLL_CNTL4,.def = 0xc04d },
> > { .reg = HHI_HIFI_PLL_CNTL5,.def = 0x00058000 },
> > - { .reg = HHI_HIFI_PLL_CNTL, .def = 0x40010250 },
>
> is this change on purpose? this line set en, m, n, l and od before
> maybe you can document it in the commit message
Yes the change is on purpose, but as you pointed out it is worth a comment
Actually, when taking od out of the pll driver, I remembered this 'initial
setting' and it kinda bothered me
If the od divider registers after the DCO, the value could have changed with it,
which is why I wanted to remove the write on this register
As you pointed out, in this register, we find m, n, od ... and enable. In a way,
removing this register setting was the reason why I wanted to add the enable bit
to begin with :)
[PATCH 2/3] dt-bindings: iio: adc: add bindings for mcp3911
MCP3911 is a dual channel Analog Front End (AFE) containing two
synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
Signed-off-by: Marcus Folkesson
Signed-off-by: Kent Gustavsson
---
.../devicetree/bindings/iio/adc/mcp3911.txt| 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/mcp3911.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
new file mode 100644
index ..e233ee94ad96
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
@@ -0,0 +1,33 @@
+* Microchip MCP3911 Dual channel analog front end (ADC)
+
+Required properties:
+ - compatible: Should be "microchip,mcp3911"
+ - reg: SPI chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+Documentation/devicetree/bindings/spi/spi-bus.txt.
+Max frequency for this chip is 20MHz.
+
+Optional properties:
+ - device-addr: Device address when multiple MCP3911 chips are present on the
+ same SPI bus. Valid values are 0-3. Defaults to 0.
+ - external-clock: Use external clock instead of crystal oscillator.
+ - external-vref: Use external voltage reference
+ - vref-supply:Phandle to the external reference voltage supply. (only
valid in combination with `external-vref`)
+ - ch0-width: width for channel0. Valid widths are 16 and 24bits.
+ - ch1-width: width for channel1. Valid widths are 16 and 24bits.
+
+
+Example:
+adc@0 {
+ compatible = "microchip,mcp3911";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ device-addr = <0>;
+ ch0-width = <16>;
+ ch1-width = <24>;
+ external-clock;
+ external-vref;
+ vref-supply = <_reg>;
+};
--
2.11.0.rc2
[PATCH 2/3] dt-bindings: iio: adc: add bindings for mcp3911
MCP3911 is a dual channel Analog Front End (AFE) containing two
synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
Signed-off-by: Marcus Folkesson
Signed-off-by: Kent Gustavsson
---
.../devicetree/bindings/iio/adc/mcp3911.txt| 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/mcp3911.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
new file mode 100644
index ..e233ee94ad96
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
@@ -0,0 +1,33 @@
+* Microchip MCP3911 Dual channel analog front end (ADC)
+
+Required properties:
+ - compatible: Should be "microchip,mcp3911"
+ - reg: SPI chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+Documentation/devicetree/bindings/spi/spi-bus.txt.
+Max frequency for this chip is 20MHz.
+
+Optional properties:
+ - device-addr: Device address when multiple MCP3911 chips are present on the
+ same SPI bus. Valid values are 0-3. Defaults to 0.
+ - external-clock: Use external clock instead of crystal oscillator.
+ - external-vref: Use external voltage reference
+ - vref-supply:Phandle to the external reference voltage supply. (only
valid in combination with `external-vref`)
+ - ch0-width: width for channel0. Valid widths are 16 and 24bits.
+ - ch1-width: width for channel1. Valid widths are 16 and 24bits.
+
+
+Example:
+adc@0 {
+ compatible = "microchip,mcp3911";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ device-addr = <0>;
+ ch0-width = <16>;
+ ch1-width = <24>;
+ external-clock;
+ external-vref;
+ vref-supply = <_reg>;
+};
--
2.11.0.rc2
[PATCH 3/3] MAINTAINERS: Add entry for mcp3911 ADC driver
Add an entry for mcp3911 ADC driver and add myself and Kent Gustavsson as maintainers of this driver. Signed-off-by: Marcus Folkesson Signed-off-by: Kent Gustavsson --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 79bb02ff812f..9276da915d9d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9271,6 +9271,14 @@ L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/microchip/lan743x_* +MICROCHIP / ATMEL MCP3911 ADC DRIVER +M: Marcus Folkesson +M: Kent Gustavsson +L: linux-...@vger.kernel.org +S: Supported +F: drivers/iio/adc/mcp3911.c +F: Documentation/devicetree/bindings/iio/adc/mcp3911.txt + MICROCHIP USB251XB DRIVER M: Richard Leitner L: linux-...@vger.kernel.org -- 2.11.0.rc2
[PATCH 3/3] MAINTAINERS: Add entry for mcp3911 ADC driver
Add an entry for mcp3911 ADC driver and add myself and Kent Gustavsson as maintainers of this driver. Signed-off-by: Marcus Folkesson Signed-off-by: Kent Gustavsson --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 79bb02ff812f..9276da915d9d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9271,6 +9271,14 @@ L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/microchip/lan743x_* +MICROCHIP / ATMEL MCP3911 ADC DRIVER +M: Marcus Folkesson +M: Kent Gustavsson +L: linux-...@vger.kernel.org +S: Supported +F: drivers/iio/adc/mcp3911.c +F: Documentation/devicetree/bindings/iio/adc/mcp3911.txt + MICROCHIP USB251XB DRIVER M: Richard Leitner L: linux-...@vger.kernel.org -- 2.11.0.rc2
[PATCH 1/3] iio: adc: add support for mcp3911
MCP3911 is a dual channel Analog Front End (AFE) containing two
synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
Signed-off-by: Marcus Folkesson
Signed-off-by: Kent Gustavsson
---
drivers/iio/adc/Kconfig | 10 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mcp3911.c | 444 ++
3 files changed, 455 insertions(+)
create mode 100644 drivers/iio/adc/mcp3911.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 15606f237480..f9a41fa96fcc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -501,6 +501,16 @@ config MCP3422
This driver can also be built as a module. If so, the module will be
called mcp3422.
+config MCP3911
+ tristate "Microchip Technology MCP3911 driver"
+ depends on SPI
+ help
+ Say yes here to build support for Microchip Technology's MCP3911
+ analog to digital converter.
+
+ This driver can also be built as a module. If so, the module will be
+ called mcp3911.
+
config MEDIATEK_MT6577_AUXADC
tristate "MediaTek AUXADC driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 28a9423997f3..3cfebfff7d26 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MAX9611) += max9611.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MCP3911) += mcp3911.o
obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
new file mode 100644
index ..be74cb15827b
--- /dev/null
+++ b/drivers/iio/adc/mcp3911.c
@@ -0,0 +1,444 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Microchip MCP3911, Two-channel Analog Front End
+ *
+ * Copyright (C) 2018 Marcus Folkesson
+ * Copyright (C) 2018 Kent Gustavsson
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MCP3911_REG_CHANNEL0 0x00
+#define MCP3911_REG_CHANNEL1 0x03
+#define MCP3911_REG_MOD0x06
+#define MCP3911_REG_PHASE 0x07
+
+#define MCP3911_REG_GAIN 0x09
+#define MCP3911_GAIN_MASK(ch) (0x7 << 3*ch)
+#define MCP3911_GAIN_VAL(ch, val) ((val << 3*ch) & MCP3911_GAIN_MASK(ch))
+
+#define MCP3911_REG_STATUSCOM 0x0a
+#define MCP3911_STATUSCOM_CH1_24WIDTH BIT(4)
+#define MCP3911_STATUSCOM_CH0_24WIDTH BIT(3)
+#define MCP3911_STATUSCOM_EN_OFFCALBIT(2)
+#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1)
+
+#define MCP3911_REG_CONFIG 0x0c
+#define MCP3911_CONFIG_CLKEXT BIT(1)
+#define MCP3911_CONFIG_VREFEXT BIT(2)
+
+#define MCP3911_REG_OFFCAL_CH0 0x0e
+#define MCP3911_REG_GAINCAL_CH00x11
+#define MCP3911_REG_OFFCAL_CH1 0x14
+#define MCP3911_REG_GAINCAL_CH10x17
+#define MCP3911_REG_VREFCAL0x1a
+
+#define MCP3911_CHANNEL(x) (MCP3911_REG_CHANNEL0 + x * 3)
+#define MCP3911_OFFCAL(x) (MCP3911_REG_OFFCAL_CH0 + x * 6)
+#define MCP3911_GAINCAL(x) (MCP3911_REG_GAINCAL_CH0 + x * 6)
+
+
+/* Internal voltage reference in uV */
+#define MCP3911_INT_VREF_UV120
+
+#define REG_READ(reg, id) (((reg << 1) | (id << 5) | (1 << 0)) & 0xff)
+#define REG_WRITE(reg, id) (((reg << 1) | (id << 5) | (0 << 0)) & 0xff)
+
+#define MCP3911_NUM_CHANNELS 2
+
+
+struct mcp3911 {
+ struct spi_device *spi;
+ struct device_node *np;
+ struct mutex lock;
+
+ u32 gain[MCP3911_NUM_CHANNELS];
+ u32 width[MCP3911_NUM_CHANNELS];
+
+ u32 dev_addr;
+ bool vrefext;
+ struct regulator *vref;
+};
+
+static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
+{
+ int ret;
+
+ reg = REG_READ(reg, adc->dev_addr);
+ ret = spi_write_then_read(adc->spi, , 1, val, len);
+ if (ret < 0)
+ return ret;
+
+ *val <<= ((4-len)*8);
+ be32_to_cpus(val);
+ dev_dbg(>spi->dev, "Reading 0x%x from register 0x%x\n", *val,
+ reg>>1);
+ return ret;
+}
+
+static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32 val, u8 len)
+{
+ dev_dbg(>spi->dev, "Writing 0x%x to register 0x%x\n", val, reg);
+
+ cpu_to_be32s();
+ val >>= (3-len)*8;
+ val |= REG_WRITE(reg, adc->dev_addr);
+
+ return spi_write(adc->spi, , len+1);
+}
+
+static int mcp3911_update(struct mcp3911 *adc, u8 reg, u32 mask,
+ u32 val, u8 len)
+{
+ u32 tmp;
+ int ret;
+
+ ret = mcp3911_read(adc, reg, , len);
+ if (ret)
+ return ret;
+
+ val &= mask;
+ val |= tmp & ~mask;
+ return mcp3911_write(adc, reg, val,
[PATCH 1/3] iio: adc: add support for mcp3911
MCP3911 is a dual channel Analog Front End (AFE) containing two
synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
Signed-off-by: Marcus Folkesson
Signed-off-by: Kent Gustavsson
---
drivers/iio/adc/Kconfig | 10 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mcp3911.c | 444 ++
3 files changed, 455 insertions(+)
create mode 100644 drivers/iio/adc/mcp3911.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 15606f237480..f9a41fa96fcc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -501,6 +501,16 @@ config MCP3422
This driver can also be built as a module. If so, the module will be
called mcp3422.
+config MCP3911
+ tristate "Microchip Technology MCP3911 driver"
+ depends on SPI
+ help
+ Say yes here to build support for Microchip Technology's MCP3911
+ analog to digital converter.
+
+ This driver can also be built as a module. If so, the module will be
+ called mcp3911.
+
config MEDIATEK_MT6577_AUXADC
tristate "MediaTek AUXADC driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 28a9423997f3..3cfebfff7d26 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MAX9611) += max9611.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MCP3911) += mcp3911.o
obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
new file mode 100644
index ..be74cb15827b
--- /dev/null
+++ b/drivers/iio/adc/mcp3911.c
@@ -0,0 +1,444 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Microchip MCP3911, Two-channel Analog Front End
+ *
+ * Copyright (C) 2018 Marcus Folkesson
+ * Copyright (C) 2018 Kent Gustavsson
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MCP3911_REG_CHANNEL0 0x00
+#define MCP3911_REG_CHANNEL1 0x03
+#define MCP3911_REG_MOD0x06
+#define MCP3911_REG_PHASE 0x07
+
+#define MCP3911_REG_GAIN 0x09
+#define MCP3911_GAIN_MASK(ch) (0x7 << 3*ch)
+#define MCP3911_GAIN_VAL(ch, val) ((val << 3*ch) & MCP3911_GAIN_MASK(ch))
+
+#define MCP3911_REG_STATUSCOM 0x0a
+#define MCP3911_STATUSCOM_CH1_24WIDTH BIT(4)
+#define MCP3911_STATUSCOM_CH0_24WIDTH BIT(3)
+#define MCP3911_STATUSCOM_EN_OFFCALBIT(2)
+#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1)
+
+#define MCP3911_REG_CONFIG 0x0c
+#define MCP3911_CONFIG_CLKEXT BIT(1)
+#define MCP3911_CONFIG_VREFEXT BIT(2)
+
+#define MCP3911_REG_OFFCAL_CH0 0x0e
+#define MCP3911_REG_GAINCAL_CH00x11
+#define MCP3911_REG_OFFCAL_CH1 0x14
+#define MCP3911_REG_GAINCAL_CH10x17
+#define MCP3911_REG_VREFCAL0x1a
+
+#define MCP3911_CHANNEL(x) (MCP3911_REG_CHANNEL0 + x * 3)
+#define MCP3911_OFFCAL(x) (MCP3911_REG_OFFCAL_CH0 + x * 6)
+#define MCP3911_GAINCAL(x) (MCP3911_REG_GAINCAL_CH0 + x * 6)
+
+
+/* Internal voltage reference in uV */
+#define MCP3911_INT_VREF_UV120
+
+#define REG_READ(reg, id) (((reg << 1) | (id << 5) | (1 << 0)) & 0xff)
+#define REG_WRITE(reg, id) (((reg << 1) | (id << 5) | (0 << 0)) & 0xff)
+
+#define MCP3911_NUM_CHANNELS 2
+
+
+struct mcp3911 {
+ struct spi_device *spi;
+ struct device_node *np;
+ struct mutex lock;
+
+ u32 gain[MCP3911_NUM_CHANNELS];
+ u32 width[MCP3911_NUM_CHANNELS];
+
+ u32 dev_addr;
+ bool vrefext;
+ struct regulator *vref;
+};
+
+static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
+{
+ int ret;
+
+ reg = REG_READ(reg, adc->dev_addr);
+ ret = spi_write_then_read(adc->spi, , 1, val, len);
+ if (ret < 0)
+ return ret;
+
+ *val <<= ((4-len)*8);
+ be32_to_cpus(val);
+ dev_dbg(>spi->dev, "Reading 0x%x from register 0x%x\n", *val,
+ reg>>1);
+ return ret;
+}
+
+static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32 val, u8 len)
+{
+ dev_dbg(>spi->dev, "Writing 0x%x to register 0x%x\n", val, reg);
+
+ cpu_to_be32s();
+ val >>= (3-len)*8;
+ val |= REG_WRITE(reg, adc->dev_addr);
+
+ return spi_write(adc->spi, , len+1);
+}
+
+static int mcp3911_update(struct mcp3911 *adc, u8 reg, u32 mask,
+ u32 val, u8 len)
+{
+ u32 tmp;
+ int ret;
+
+ ret = mcp3911_read(adc, reg, , len);
+ if (ret)
+ return ret;
+
+ val &= mask;
+ val |= tmp & ~mask;
+ return mcp3911_write(adc, reg, val,
Re: [PATCH 0/3] clk: meson: clk-pll driver update
Hi Jerome, On Tue, Jul 17, 2018 at 11:56 AM Jerome Brunet wrote: > > This patchset is yet another round of update to the amlogic pll driver. > > 1) Enable bit is added so we don't rely on the bootloader or the init > value to enable to pll device. > 2) OD post dividers are removed from the pll driver. This simplify the > driver and let us provide the clocks which exist between those > dividera. Some device are actually using these clocks. > 3) The rates hard coded in parameter tables are remove. Instead, we > only rely on the parent rate and the parameters to calculate the > output rate, which is a lot better. > > This series has been tested on the gxl libretech cc and axg s400. > I did not test it on meson8b yet. I had some comments on patch #2 once that is fixed I can help testing on Meson8b (if you give me a few days...) Regards Martin
Re: [PATCH 0/3] clk: meson: clk-pll driver update
Hi Jerome, On Tue, Jul 17, 2018 at 11:56 AM Jerome Brunet wrote: > > This patchset is yet another round of update to the amlogic pll driver. > > 1) Enable bit is added so we don't rely on the bootloader or the init > value to enable to pll device. > 2) OD post dividers are removed from the pll driver. This simplify the > driver and let us provide the clocks which exist between those > dividera. Some device are actually using these clocks. > 3) The rates hard coded in parameter tables are remove. Instead, we > only rely on the parent rate and the parameters to calculate the > output rate, which is a lot better. > > This series has been tested on the gxl libretech cc and axg s400. > I did not test it on meson8b yet. I had some comments on patch #2 once that is fixed I can help testing on Meson8b (if you give me a few days...) Regards Martin
Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables
On Thu, Jul 19, 2018 at 10:44 AM Neil Armstrong wrote:
>
> On 17/07/2018 11:56, Jerome Brunet wrote:
> > Putting hard-coded rates inside the parameter tables assumes that
> > the parent is known and will never change. That's a big assumption
> > we should not make.
> >
> > We have everything we need to recalculate the output rate using
> > the parent rate and the rest of the parameters. Let's do so and
> > drop the rates from the tables.
> >
> > Signed-off-by: Jerome Brunet
> > ---
> > drivers/clk/meson/axg.c | 73 +--
> > drivers/clk/meson/clk-pll.c | 69 -
> > drivers/clk/meson/clkc.h| 8 ++-
> > drivers/clk/meson/gxbb.c| 120
> > ++--
> > drivers/clk/meson/meson8b.c | 34 ++---
> > 5 files changed, 162 insertions(+), 142 deletions(-)
> >
> > diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> > index 572358062459..d34954bd8c5e 100644
> > --- a/drivers/clk/meson/axg.c
> > +++ b/drivers/clk/meson/axg.c
> > @@ -130,36 +130,36 @@ static struct clk_regmap axg_sys_pll = {
> > },
> > };
> >
> > -static const struct pll_rate_table axg_gp0_pll_rate_table[] = {
> > - PLL_RATE(96000, 40, 1),
> > - PLL_RATE(98400, 41, 1),
> > - PLL_RATE(100800, 42, 1),
> > - PLL_RATE(103200, 43, 1),
> > - PLL_RATE(105600, 44, 1),
> > - PLL_RATE(108000, 45, 1),
> > - PLL_RATE(110400, 46, 1),
> > - PLL_RATE(112800, 47, 1),
> > - PLL_RATE(115200, 48, 1),
> > - PLL_RATE(117600, 49, 1),
> > - PLL_RATE(12, 50, 1),
> > - PLL_RATE(122400, 51, 1),
> > - PLL_RATE(124800, 52, 1),
> > - PLL_RATE(127200, 53, 1),
> > - PLL_RATE(129600, 54, 1),
> > - PLL_RATE(132000, 55, 1),
> > - PLL_RATE(134400, 56, 1),
> > - PLL_RATE(136800, 57, 1),
> > - PLL_RATE(139200, 58, 1),
> > - PLL_RATE(141600, 59, 1),
> > - PLL_RATE(144000, 60, 1),
> > - PLL_RATE(146400, 61, 1),
> > - PLL_RATE(148800, 62, 1),
> > - PLL_RATE(151200, 63, 1),
> > - PLL_RATE(153600, 64, 1),
> > - PLL_RATE(156000, 65, 1),
> > - PLL_RATE(158400, 66, 1),
> > - PLL_RATE(160800, 67, 1),
> > - PLL_RATE(163200, 68, 1),
> > +static const struct pll_params_table axg_gp0_pll_params_table[] = {
> > + PLL_PARAMS(40, 1),
> > + PLL_PARAMS(41, 1),
> > + PLL_PARAMS(42, 1),
> > + PLL_PARAMS(43, 1),
> > + PLL_PARAMS(44, 1),
> > + PLL_PARAMS(45, 1),
> > + PLL_PARAMS(46, 1),
> > + PLL_PARAMS(47, 1),
> > + PLL_PARAMS(48, 1),
> > + PLL_PARAMS(49, 1),
> > + PLL_PARAMS(50, 1),
> > + PLL_PARAMS(51, 1),
> > + PLL_PARAMS(52, 1),
> > + PLL_PARAMS(53, 1),
> > + PLL_PARAMS(54, 1),
> > + PLL_PARAMS(55, 1),
> > + PLL_PARAMS(56, 1),
> > + PLL_PARAMS(57, 1),
> > + PLL_PARAMS(58, 1),
> > + PLL_PARAMS(59, 1),
> > + PLL_PARAMS(60, 1),
> > + PLL_PARAMS(61, 1),
> > + PLL_PARAMS(62, 1),
> > + PLL_PARAMS(63, 1),
> > + PLL_PARAMS(64, 1),
> > + PLL_PARAMS(65, 1),
> > + PLL_PARAMS(66, 1),
> > + PLL_PARAMS(67, 1),
> > + PLL_PARAMS(68, 1),
> > { /* sentinel */ },
> > };
> >
> > @@ -203,7 +203,7 @@ static struct clk_regmap axg_gp0_pll_dco = {
> > .shift = 29,
> > .width = 1,
> > },
> > - .table = axg_gp0_pll_rate_table,
> > + .table = axg_gp0_pll_params_table,
> > .init_regs = axg_gp0_init_regs,
> > .init_count = ARRAY_SIZE(axg_gp0_init_regs),
> > },
> > @@ -271,7 +271,7 @@ static struct clk_regmap axg_hifi_pll_dco = {
> > .shift = 29,
> > .width = 1,
> > },
> > - .table = axg_gp0_pll_rate_table,
> > + .table = axg_gp0_pll_params_table,
> > .init_regs = axg_hifi_init_regs,
> > .init_count = ARRAY_SIZE(axg_hifi_init_regs),
> > .flags = CLK_MESON_PLL_ROUND_CLOSEST,
> > @@ -627,11 +627,10 @@ static struct clk_regmap axg_mpll3 = {
> > },
> > };
> >
> > -static const struct pll_rate_table axg_pcie_pll_rate_table[] = {
> > +static const struct pll_params_table axg_pcie_pll_params_table[] = {
> > {
> > - .rate = 16,
> > - .m = 200,
> > - .n = 3,
> > + .m = 200,
> > + .n = 3,
> > },
> > { /* sentinel */ },
> > };
> > @@ -678,7 +677,7 @@ static struct clk_regmap axg_pcie_pll_dco = {
> > .shift = 29,
> > .width = 1,
> > },
> > - .table = axg_pcie_pll_rate_table,
> > + .table = axg_pcie_pll_params_table,
> > .init_regs = axg_pcie_init_regs,
> > .init_count = ARRAY_SIZE(axg_pcie_init_regs),
> >
Re: [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables
On Thu, Jul 19, 2018 at 10:44 AM Neil Armstrong wrote:
>
> On 17/07/2018 11:56, Jerome Brunet wrote:
> > Putting hard-coded rates inside the parameter tables assumes that
> > the parent is known and will never change. That's a big assumption
> > we should not make.
> >
> > We have everything we need to recalculate the output rate using
> > the parent rate and the rest of the parameters. Let's do so and
> > drop the rates from the tables.
> >
> > Signed-off-by: Jerome Brunet
> > ---
> > drivers/clk/meson/axg.c | 73 +--
> > drivers/clk/meson/clk-pll.c | 69 -
> > drivers/clk/meson/clkc.h| 8 ++-
> > drivers/clk/meson/gxbb.c| 120
> > ++--
> > drivers/clk/meson/meson8b.c | 34 ++---
> > 5 files changed, 162 insertions(+), 142 deletions(-)
> >
> > diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> > index 572358062459..d34954bd8c5e 100644
> > --- a/drivers/clk/meson/axg.c
> > +++ b/drivers/clk/meson/axg.c
> > @@ -130,36 +130,36 @@ static struct clk_regmap axg_sys_pll = {
> > },
> > };
> >
> > -static const struct pll_rate_table axg_gp0_pll_rate_table[] = {
> > - PLL_RATE(96000, 40, 1),
> > - PLL_RATE(98400, 41, 1),
> > - PLL_RATE(100800, 42, 1),
> > - PLL_RATE(103200, 43, 1),
> > - PLL_RATE(105600, 44, 1),
> > - PLL_RATE(108000, 45, 1),
> > - PLL_RATE(110400, 46, 1),
> > - PLL_RATE(112800, 47, 1),
> > - PLL_RATE(115200, 48, 1),
> > - PLL_RATE(117600, 49, 1),
> > - PLL_RATE(12, 50, 1),
> > - PLL_RATE(122400, 51, 1),
> > - PLL_RATE(124800, 52, 1),
> > - PLL_RATE(127200, 53, 1),
> > - PLL_RATE(129600, 54, 1),
> > - PLL_RATE(132000, 55, 1),
> > - PLL_RATE(134400, 56, 1),
> > - PLL_RATE(136800, 57, 1),
> > - PLL_RATE(139200, 58, 1),
> > - PLL_RATE(141600, 59, 1),
> > - PLL_RATE(144000, 60, 1),
> > - PLL_RATE(146400, 61, 1),
> > - PLL_RATE(148800, 62, 1),
> > - PLL_RATE(151200, 63, 1),
> > - PLL_RATE(153600, 64, 1),
> > - PLL_RATE(156000, 65, 1),
> > - PLL_RATE(158400, 66, 1),
> > - PLL_RATE(160800, 67, 1),
> > - PLL_RATE(163200, 68, 1),
> > +static const struct pll_params_table axg_gp0_pll_params_table[] = {
> > + PLL_PARAMS(40, 1),
> > + PLL_PARAMS(41, 1),
> > + PLL_PARAMS(42, 1),
> > + PLL_PARAMS(43, 1),
> > + PLL_PARAMS(44, 1),
> > + PLL_PARAMS(45, 1),
> > + PLL_PARAMS(46, 1),
> > + PLL_PARAMS(47, 1),
> > + PLL_PARAMS(48, 1),
> > + PLL_PARAMS(49, 1),
> > + PLL_PARAMS(50, 1),
> > + PLL_PARAMS(51, 1),
> > + PLL_PARAMS(52, 1),
> > + PLL_PARAMS(53, 1),
> > + PLL_PARAMS(54, 1),
> > + PLL_PARAMS(55, 1),
> > + PLL_PARAMS(56, 1),
> > + PLL_PARAMS(57, 1),
> > + PLL_PARAMS(58, 1),
> > + PLL_PARAMS(59, 1),
> > + PLL_PARAMS(60, 1),
> > + PLL_PARAMS(61, 1),
> > + PLL_PARAMS(62, 1),
> > + PLL_PARAMS(63, 1),
> > + PLL_PARAMS(64, 1),
> > + PLL_PARAMS(65, 1),
> > + PLL_PARAMS(66, 1),
> > + PLL_PARAMS(67, 1),
> > + PLL_PARAMS(68, 1),
> > { /* sentinel */ },
> > };
> >
> > @@ -203,7 +203,7 @@ static struct clk_regmap axg_gp0_pll_dco = {
> > .shift = 29,
> > .width = 1,
> > },
> > - .table = axg_gp0_pll_rate_table,
> > + .table = axg_gp0_pll_params_table,
> > .init_regs = axg_gp0_init_regs,
> > .init_count = ARRAY_SIZE(axg_gp0_init_regs),
> > },
> > @@ -271,7 +271,7 @@ static struct clk_regmap axg_hifi_pll_dco = {
> > .shift = 29,
> > .width = 1,
> > },
> > - .table = axg_gp0_pll_rate_table,
> > + .table = axg_gp0_pll_params_table,
> > .init_regs = axg_hifi_init_regs,
> > .init_count = ARRAY_SIZE(axg_hifi_init_regs),
> > .flags = CLK_MESON_PLL_ROUND_CLOSEST,
> > @@ -627,11 +627,10 @@ static struct clk_regmap axg_mpll3 = {
> > },
> > };
> >
> > -static const struct pll_rate_table axg_pcie_pll_rate_table[] = {
> > +static const struct pll_params_table axg_pcie_pll_params_table[] = {
> > {
> > - .rate = 16,
> > - .m = 200,
> > - .n = 3,
> > + .m = 200,
> > + .n = 3,
> > },
> > { /* sentinel */ },
> > };
> > @@ -678,7 +677,7 @@ static struct clk_regmap axg_pcie_pll_dco = {
> > .shift = 29,
> > .width = 1,
> > },
> > - .table = axg_pcie_pll_rate_table,
> > + .table = axg_pcie_pll_params_table,
> > .init_regs = axg_pcie_init_regs,
> > .init_count = ARRAY_SIZE(axg_pcie_init_regs),
> >
Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
Hi Jerome,
On Tue, Jul 17, 2018 at 11:56 AM Jerome Brunet wrote:
>
> Remove od parameters from pll clocks and add post dividers clocks
> instead. Some clock, especially the one which feature several ods,
> may provide output between those ods. Also, some drivers, such
> as the hdmi driver, may require a more detailed control of the
> clock dividers, compared to what CCF would perform automatically.
>
> One added benefit of removing ods is that it also greatly reduce the
> size of the rate parameter tables.
>
> In the future, we could possibly take the predivider 'n' out of this
> driver as well. To do so, we will need to understand the constraints
> for the PLL to lock and whether or not it depends on the input clock
> rate.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/clk/meson/axg.c | 279 ++
> drivers/clk/meson/axg.h | 8 +-
> drivers/clk/meson/clk-pll.c | 40 ++--
> drivers/clk/meson/clkc.h| 9 +-
> drivers/clk/meson/gxbb.c| 474
> +---
> drivers/clk/meson/gxbb.h| 10 +-
> drivers/clk/meson/meson8b.c | 148 +++---
> drivers/clk/meson/meson8b.h | 5 +-
> 8 files changed, 480 insertions(+), 493 deletions(-)
>
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 6d8976554656..572358062459 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -22,7 +22,7 @@
>
> static DEFINE_SPINLOCK(meson_clk_lock);
>
> -static struct clk_regmap axg_fixed_pll = {
> +static struct clk_regmap axg_fixed_pll_dco = {
> .data = &(struct meson_clk_pll_data){
> .en = {
> .reg_off = HHI_MPLL_CNTL,
> @@ -39,11 +39,6 @@ static struct clk_regmap axg_fixed_pll = {
> .shift = 9,
> .width = 5,
> },
> - .od = {
> - .reg_off = HHI_MPLL_CNTL,
> - .shift = 16,
> - .width = 2,
> - },
> .frac = {
> .reg_off = HHI_MPLL_CNTL2,
> .shift = 0,
> @@ -61,14 +56,29 @@ static struct clk_regmap axg_fixed_pll = {
> },
> },
> .hw.init = &(struct clk_init_data){
> - .name = "fixed_pll",
> + .name = "fixed_pll_dco",
> .ops = _clk_pll_ro_ops,
> .parent_names = (const char *[]){ "xtal" },
> .num_parents = 1,
> },
> };
>
> -static struct clk_regmap axg_sys_pll = {
> +static struct clk_regmap axg_fixed_pll = {
> + .data = &(struct clk_regmap_div_data){
> + .offset = HHI_MPLL_CNTL,
> + .shift = 16,
> + .width = 2,
> + .flags = CLK_DIVIDER_POWER_OF_TWO,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "fixed_pll",
> + .ops = _regmap_divider_ro_ops,
> + .parent_names = (const char *[]){ "fixed_pll_dco" },
> + .num_parents = 1,
> + },
> +};
> +
> +static struct clk_regmap axg_sys_pll_dco = {
> .data = &(struct meson_clk_pll_data){
> .en = {
> .reg_off = HHI_SYS_PLL_CNTL,
> @@ -85,11 +95,6 @@ static struct clk_regmap axg_sys_pll = {
> .shift = 9,
> .width = 5,
> },
> - .od = {
> - .reg_off = HHI_SYS_PLL_CNTL,
> - .shift = 16,
> - .width = 2,
> - },
> .l = {
> .reg_off = HHI_SYS_PLL_CNTL,
> .shift = 31,
> @@ -102,7 +107,7 @@ static struct clk_regmap axg_sys_pll = {
> },
> },
> .hw.init = &(struct clk_init_data){
> - .name = "sys_pll",
> + .name = "sys_pll_dco",
> .ops = _clk_pll_ro_ops,
> .parent_names = (const char *[]){ "xtal" },
> .num_parents = 1,
> @@ -110,94 +115,51 @@ static struct clk_regmap axg_sys_pll = {
> },
> };
>
> +static struct clk_regmap axg_sys_pll = {
> + .data = &(struct clk_regmap_div_data){
> + .offset = HHI_SYS_PLL_CNTL,
> + .shift = 16,
> + .width = 2,
> + .flags = CLK_DIVIDER_POWER_OF_TWO,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "sys_pll",
> + .ops = _regmap_divider_ro_ops,
> + .parent_names = (const char *[]){ "sys_pll_dco" },
> + .num_parents = 1,
> + },
> +};
> +
> static const struct pll_rate_table axg_gp0_pll_rate_table[] = {
> - PLL_RATE(24000, 40, 1, 2),
> - PLL_RATE(24600, 41, 1, 2),
> - PLL_RATE(25200, 42, 1, 2),
> - PLL_RATE(25800, 43, 1, 2),
> -
Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
Hi Jerome,
On Tue, Jul 17, 2018 at 11:56 AM Jerome Brunet wrote:
>
> Remove od parameters from pll clocks and add post dividers clocks
> instead. Some clock, especially the one which feature several ods,
> may provide output between those ods. Also, some drivers, such
> as the hdmi driver, may require a more detailed control of the
> clock dividers, compared to what CCF would perform automatically.
>
> One added benefit of removing ods is that it also greatly reduce the
> size of the rate parameter tables.
>
> In the future, we could possibly take the predivider 'n' out of this
> driver as well. To do so, we will need to understand the constraints
> for the PLL to lock and whether or not it depends on the input clock
> rate.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/clk/meson/axg.c | 279 ++
> drivers/clk/meson/axg.h | 8 +-
> drivers/clk/meson/clk-pll.c | 40 ++--
> drivers/clk/meson/clkc.h| 9 +-
> drivers/clk/meson/gxbb.c| 474
> +---
> drivers/clk/meson/gxbb.h| 10 +-
> drivers/clk/meson/meson8b.c | 148 +++---
> drivers/clk/meson/meson8b.h | 5 +-
> 8 files changed, 480 insertions(+), 493 deletions(-)
>
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 6d8976554656..572358062459 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -22,7 +22,7 @@
>
> static DEFINE_SPINLOCK(meson_clk_lock);
>
> -static struct clk_regmap axg_fixed_pll = {
> +static struct clk_regmap axg_fixed_pll_dco = {
> .data = &(struct meson_clk_pll_data){
> .en = {
> .reg_off = HHI_MPLL_CNTL,
> @@ -39,11 +39,6 @@ static struct clk_regmap axg_fixed_pll = {
> .shift = 9,
> .width = 5,
> },
> - .od = {
> - .reg_off = HHI_MPLL_CNTL,
> - .shift = 16,
> - .width = 2,
> - },
> .frac = {
> .reg_off = HHI_MPLL_CNTL2,
> .shift = 0,
> @@ -61,14 +56,29 @@ static struct clk_regmap axg_fixed_pll = {
> },
> },
> .hw.init = &(struct clk_init_data){
> - .name = "fixed_pll",
> + .name = "fixed_pll_dco",
> .ops = _clk_pll_ro_ops,
> .parent_names = (const char *[]){ "xtal" },
> .num_parents = 1,
> },
> };
>
> -static struct clk_regmap axg_sys_pll = {
> +static struct clk_regmap axg_fixed_pll = {
> + .data = &(struct clk_regmap_div_data){
> + .offset = HHI_MPLL_CNTL,
> + .shift = 16,
> + .width = 2,
> + .flags = CLK_DIVIDER_POWER_OF_TWO,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "fixed_pll",
> + .ops = _regmap_divider_ro_ops,
> + .parent_names = (const char *[]){ "fixed_pll_dco" },
> + .num_parents = 1,
> + },
> +};
> +
> +static struct clk_regmap axg_sys_pll_dco = {
> .data = &(struct meson_clk_pll_data){
> .en = {
> .reg_off = HHI_SYS_PLL_CNTL,
> @@ -85,11 +95,6 @@ static struct clk_regmap axg_sys_pll = {
> .shift = 9,
> .width = 5,
> },
> - .od = {
> - .reg_off = HHI_SYS_PLL_CNTL,
> - .shift = 16,
> - .width = 2,
> - },
> .l = {
> .reg_off = HHI_SYS_PLL_CNTL,
> .shift = 31,
> @@ -102,7 +107,7 @@ static struct clk_regmap axg_sys_pll = {
> },
> },
> .hw.init = &(struct clk_init_data){
> - .name = "sys_pll",
> + .name = "sys_pll_dco",
> .ops = _clk_pll_ro_ops,
> .parent_names = (const char *[]){ "xtal" },
> .num_parents = 1,
> @@ -110,94 +115,51 @@ static struct clk_regmap axg_sys_pll = {
> },
> };
>
> +static struct clk_regmap axg_sys_pll = {
> + .data = &(struct clk_regmap_div_data){
> + .offset = HHI_SYS_PLL_CNTL,
> + .shift = 16,
> + .width = 2,
> + .flags = CLK_DIVIDER_POWER_OF_TWO,
> + },
> + .hw.init = &(struct clk_init_data){
> + .name = "sys_pll",
> + .ops = _regmap_divider_ro_ops,
> + .parent_names = (const char *[]){ "sys_pll_dco" },
> + .num_parents = 1,
> + },
> +};
> +
> static const struct pll_rate_table axg_gp0_pll_rate_table[] = {
> - PLL_RATE(24000, 40, 1, 2),
> - PLL_RATE(24600, 41, 1, 2),
> - PLL_RATE(25200, 42, 1, 2),
> - PLL_RATE(25800, 43, 1, 2),
> -
[PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
error:
drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of
function ‘of_read_number’; did you mean ‘down_read_nested’?
[-Werror=implicit-function-declaration]
bank = of_read_number(prop, 1);
^~
down_read_nested
Make JZ4780_NEMC depend on OF.
Fixes: ab99e11062c1 ("memory: jz4780-nemc: Allow selection of this driver when
COMPILE_TEST=y")
Reported-by: Randy Dunlap
Signed-off-by: Anders Roxell
---
drivers/memory/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index a642552dfdc9..63389f075f1d 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -123,7 +123,7 @@ config JZ4780_NEMC
bool "Ingenic JZ4780 SoC NEMC driver"
default y
depends on MACH_JZ4780 || COMPILE_TEST
- depends on HAS_IOMEM
+ depends on HAS_IOMEM && OF
help
This driver is for the NAND/External Memory Controller (NEMC) in
the Ingenic JZ4780. This controller is used to handle external
--
2.18.0
[PATCH] drivers/memory/Kconfig: Add CONFIG_OF dependency
JZ4780_NEMC doesn't depend on OF, and if OF isn't enabled we get this
error:
drivers/memory/jz4780-nemc.c: In function ‘jz4780_nemc_num_banks’:
drivers/memory/jz4780-nemc.c:72:10: error: implicit declaration of
function ‘of_read_number’; did you mean ‘down_read_nested’?
[-Werror=implicit-function-declaration]
bank = of_read_number(prop, 1);
^~
down_read_nested
Make JZ4780_NEMC depend on OF.
Fixes: ab99e11062c1 ("memory: jz4780-nemc: Allow selection of this driver when
COMPILE_TEST=y")
Reported-by: Randy Dunlap
Signed-off-by: Anders Roxell
---
drivers/memory/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index a642552dfdc9..63389f075f1d 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -123,7 +123,7 @@ config JZ4780_NEMC
bool "Ingenic JZ4780 SoC NEMC driver"
default y
depends on MACH_JZ4780 || COMPILE_TEST
- depends on HAS_IOMEM
+ depends on HAS_IOMEM && OF
help
This driver is for the NAND/External Memory Controller (NEMC) in
the Ingenic JZ4780. This controller is used to handle external
--
2.18.0
Re: [PATCH 1/3] clk: meson: clk-pll: add enable bit
Hi Jerome,
On Tue, Jul 17, 2018 at 11:56 AM Jerome Brunet wrote:
>
> Add the enable the bit of the pll clocks.
> These pll clocks may be disabled but we can't model this as an external
> gate since the pll needs to lock when enabled.
>
> Signed-off-by: Jerome Brunet
I have some questions inline, but with those answered:
Acked-by: Martin Blumenstingl
> ---
> drivers/clk/meson/axg.c | 28 ---
> drivers/clk/meson/clk-pll.c | 47
> -
> drivers/clk/meson/clkc.h| 1 +
> drivers/clk/meson/gxbb.c| 32 --
> drivers/clk/meson/meson8b.c | 15 +++
> 5 files changed, 113 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 00ce62ad6416..6d8976554656 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -24,6 +24,11 @@ static DEFINE_SPINLOCK(meson_clk_lock);
>
> static struct clk_regmap axg_fixed_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_MPLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_MPLL_CNTL,
> .shift = 0,
> @@ -65,6 +70,11 @@ static struct clk_regmap axg_fixed_pll = {
>
> static struct clk_regmap axg_sys_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_SYS_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_SYS_PLL_CNTL,
> .shift = 0,
> @@ -197,11 +207,15 @@ static const struct reg_sequence axg_gp0_init_regs[] = {
> { .reg = HHI_GP0_PLL_CNTL3, .def = 0x0a59a288 },
> { .reg = HHI_GP0_PLL_CNTL4, .def = 0xc04d },
> { .reg = HHI_GP0_PLL_CNTL5, .def = 0x00078000 },
> - { .reg = HHI_GP0_PLL_CNTL, .def = 0x40010250 },
> };
>
> static struct clk_regmap axg_gp0_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_GP0_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_GP0_PLL_CNTL,
> .shift = 0,
> @@ -250,11 +264,15 @@ static const struct reg_sequence axg_hifi_init_regs[] =
> {
> { .reg = HHI_HIFI_PLL_CNTL3,.def = 0x0a6a3a88 },
> { .reg = HHI_HIFI_PLL_CNTL4,.def = 0xc04d },
> { .reg = HHI_HIFI_PLL_CNTL5,.def = 0x00058000 },
> - { .reg = HHI_HIFI_PLL_CNTL, .def = 0x40010250 },
is this change on purpose? this line set en, m, n, l and od before
maybe you can document it in the commit message
> };
>
> static struct clk_regmap axg_hifi_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_HIFI_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_HIFI_PLL_CNTL,
> .shift = 0,
> @@ -637,7 +655,6 @@ static const struct pll_rate_table
> axg_pcie_pll_rate_table[] = {
> };
>
> static const struct reg_sequence axg_pcie_init_regs[] = {
> - { .reg = HHI_PCIE_PLL_CNTL, .def = 0x400106c8 },
same as above: is this change on purpose?
> { .reg = HHI_PCIE_PLL_CNTL1,.def = 0x0084a2aa },
> { .reg = HHI_PCIE_PLL_CNTL2,.def = 0xb75020be },
> { .reg = HHI_PCIE_PLL_CNTL3,.def = 0x0a47488e },
> @@ -648,6 +665,11 @@ static const struct reg_sequence axg_pcie_init_regs[] = {
>
> static struct clk_regmap axg_pcie_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_PCIE_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_PCIE_PLL_CNTL,
> .shift = 0,
> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> index 3e04617ac47f..8aaefe67025f 100644
> --- a/drivers/clk/meson/clk-pll.c
> +++ b/drivers/clk/meson/clk-pll.c
> @@ -185,12 +185,45 @@ static void meson_clk_pll_init(struct clk_hw *hw)
> }
> }
>
> +static int meson_clk_pll_enable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
> +
> + /* Make sure the pll is in reset */
> + meson_parm_write(clk->map, >rst, 1);
> +
> + /* Enable the pll */
> + meson_parm_write(clk->map, >en, 1);
> +
> + /*
Re: [PATCH 1/3] clk: meson: clk-pll: add enable bit
Hi Jerome,
On Tue, Jul 17, 2018 at 11:56 AM Jerome Brunet wrote:
>
> Add the enable the bit of the pll clocks.
> These pll clocks may be disabled but we can't model this as an external
> gate since the pll needs to lock when enabled.
>
> Signed-off-by: Jerome Brunet
I have some questions inline, but with those answered:
Acked-by: Martin Blumenstingl
> ---
> drivers/clk/meson/axg.c | 28 ---
> drivers/clk/meson/clk-pll.c | 47
> -
> drivers/clk/meson/clkc.h| 1 +
> drivers/clk/meson/gxbb.c| 32 --
> drivers/clk/meson/meson8b.c | 15 +++
> 5 files changed, 113 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index 00ce62ad6416..6d8976554656 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -24,6 +24,11 @@ static DEFINE_SPINLOCK(meson_clk_lock);
>
> static struct clk_regmap axg_fixed_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_MPLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_MPLL_CNTL,
> .shift = 0,
> @@ -65,6 +70,11 @@ static struct clk_regmap axg_fixed_pll = {
>
> static struct clk_regmap axg_sys_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_SYS_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_SYS_PLL_CNTL,
> .shift = 0,
> @@ -197,11 +207,15 @@ static const struct reg_sequence axg_gp0_init_regs[] = {
> { .reg = HHI_GP0_PLL_CNTL3, .def = 0x0a59a288 },
> { .reg = HHI_GP0_PLL_CNTL4, .def = 0xc04d },
> { .reg = HHI_GP0_PLL_CNTL5, .def = 0x00078000 },
> - { .reg = HHI_GP0_PLL_CNTL, .def = 0x40010250 },
> };
>
> static struct clk_regmap axg_gp0_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_GP0_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_GP0_PLL_CNTL,
> .shift = 0,
> @@ -250,11 +264,15 @@ static const struct reg_sequence axg_hifi_init_regs[] =
> {
> { .reg = HHI_HIFI_PLL_CNTL3,.def = 0x0a6a3a88 },
> { .reg = HHI_HIFI_PLL_CNTL4,.def = 0xc04d },
> { .reg = HHI_HIFI_PLL_CNTL5,.def = 0x00058000 },
> - { .reg = HHI_HIFI_PLL_CNTL, .def = 0x40010250 },
is this change on purpose? this line set en, m, n, l and od before
maybe you can document it in the commit message
> };
>
> static struct clk_regmap axg_hifi_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_HIFI_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_HIFI_PLL_CNTL,
> .shift = 0,
> @@ -637,7 +655,6 @@ static const struct pll_rate_table
> axg_pcie_pll_rate_table[] = {
> };
>
> static const struct reg_sequence axg_pcie_init_regs[] = {
> - { .reg = HHI_PCIE_PLL_CNTL, .def = 0x400106c8 },
same as above: is this change on purpose?
> { .reg = HHI_PCIE_PLL_CNTL1,.def = 0x0084a2aa },
> { .reg = HHI_PCIE_PLL_CNTL2,.def = 0xb75020be },
> { .reg = HHI_PCIE_PLL_CNTL3,.def = 0x0a47488e },
> @@ -648,6 +665,11 @@ static const struct reg_sequence axg_pcie_init_regs[] = {
>
> static struct clk_regmap axg_pcie_pll = {
> .data = &(struct meson_clk_pll_data){
> + .en = {
> + .reg_off = HHI_PCIE_PLL_CNTL,
> + .shift = 30,
> + .width = 1,
> + },
> .m = {
> .reg_off = HHI_PCIE_PLL_CNTL,
> .shift = 0,
> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> index 3e04617ac47f..8aaefe67025f 100644
> --- a/drivers/clk/meson/clk-pll.c
> +++ b/drivers/clk/meson/clk-pll.c
> @@ -185,12 +185,45 @@ static void meson_clk_pll_init(struct clk_hw *hw)
> }
> }
>
> +static int meson_clk_pll_enable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
> +
> + /* Make sure the pll is in reset */
> + meson_parm_write(clk->map, >rst, 1);
> +
> + /* Enable the pll */
> + meson_parm_write(clk->map, >en, 1);
> +
> + /*
Re: UBSAN: Undefined behaviour in arch/x86/events/amd/ibs.c:582:24: member access within null pointer of type 'struct perf_event'
Dear Thomas,
Am 20.07.2018 um 10:39 schrieb Thomas Gleixner:
On Fri, 20 Jul 2018, Paul Menzel wrote:
Enabling the undefined behavior sanitizer and building GNU/Linux 4.18-rc5+
(with some unrelated commits) with GCC 8.1.0 from Debian Sid/unstable, the
warning below is shown.
[2.111913]
[2.111917] UBSAN: Undefined behaviour in
arch/x86/events/amd/ibs.c:582:24
[2.111919] member access within null pointer of type 'struct perf_event'
[2.111926] CPU: 0 PID: 144 Comm: udevadm Not tainted
4.18.0-rc5-00316-g4864b68cedf2 #104
[2.111928] Hardware name: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
[2.111930] Call Trace:
[2.111943] dump_stack+0x55/0x89
[2.111949] ubsan_epilogue+0xb/0x33
[2.111953] handle_null_ptr_deref+0x7f/0x90
[2.111958] __ubsan_handle_type_mismatch_v1+0x55/0x60
[2.111964] perf_ibs_handle_irq+0x596/0x620
Right, the code dereferences event before checking the STARTED bit. Patch
below should cure the issue. The warning should not trigger, if I analyzed
the thing correctly. Emphasis on *should*
8<
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 4b98101209a1..d50bb4dc0650 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -579,7 +579,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
{
struct cpu_perf_ibs *pcpu = this_cpu_ptr(perf_ibs->pcpu);
struct perf_event *event = pcpu->event;
- struct hw_perf_event *hwc = >hw;
+ struct hw_perf_event *hwc;
struct perf_sample_data data;
struct perf_raw_record raw;
struct pt_regs regs;
@@ -602,6 +602,10 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
return 0;
}
+ if (WARN_ON_ONCE(!event))
+ goto fail;
+
+ hwc = >hw;
msr = hwc->config_base;
buf = ibs_data.regs;
rdmsrl(msr, *buf);
Thank you very much. The warning is gone after applying it.
Tested-by: Paul Menzel
Kind regards,
Paul
Re: UBSAN: Undefined behaviour in arch/x86/events/amd/ibs.c:582:24: member access within null pointer of type 'struct perf_event'
Dear Thomas,
Am 20.07.2018 um 10:39 schrieb Thomas Gleixner:
On Fri, 20 Jul 2018, Paul Menzel wrote:
Enabling the undefined behavior sanitizer and building GNU/Linux 4.18-rc5+
(with some unrelated commits) with GCC 8.1.0 from Debian Sid/unstable, the
warning below is shown.
[2.111913]
[2.111917] UBSAN: Undefined behaviour in
arch/x86/events/amd/ibs.c:582:24
[2.111919] member access within null pointer of type 'struct perf_event'
[2.111926] CPU: 0 PID: 144 Comm: udevadm Not tainted
4.18.0-rc5-00316-g4864b68cedf2 #104
[2.111928] Hardware name: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
[2.111930] Call Trace:
[2.111943] dump_stack+0x55/0x89
[2.111949] ubsan_epilogue+0xb/0x33
[2.111953] handle_null_ptr_deref+0x7f/0x90
[2.111958] __ubsan_handle_type_mismatch_v1+0x55/0x60
[2.111964] perf_ibs_handle_irq+0x596/0x620
Right, the code dereferences event before checking the STARTED bit. Patch
below should cure the issue. The warning should not trigger, if I analyzed
the thing correctly. Emphasis on *should*
8<
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 4b98101209a1..d50bb4dc0650 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -579,7 +579,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
{
struct cpu_perf_ibs *pcpu = this_cpu_ptr(perf_ibs->pcpu);
struct perf_event *event = pcpu->event;
- struct hw_perf_event *hwc = >hw;
+ struct hw_perf_event *hwc;
struct perf_sample_data data;
struct perf_raw_record raw;
struct pt_regs regs;
@@ -602,6 +602,10 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
return 0;
}
+ if (WARN_ON_ONCE(!event))
+ goto fail;
+
+ hwc = >hw;
msr = hwc->config_base;
buf = ibs_data.regs;
rdmsrl(msr, *buf);
Thank you very much. The warning is gone after applying it.
Tested-by: Paul Menzel
Kind regards,
Paul
[PATCH v2 0/2] iio: adc: ti-ads7950: allow simultaneous use of buffer and direct mode
v2 changes: - add new patch to use SPDX-License-Identifier (since we are touching this file anyway) - don't add struct iio_device *indio_dev as field to private data - fix indent on return statement David Lechner (2): iio: adc: ti-ads7950: use SPDX-License-Identifier iio: adc: ti-ads7950: allow simultaneous use of buffer and direct mode drivers/iio/adc/ti-ads7950.c | 42 1 file changed, 19 insertions(+), 23 deletions(-) -- 2.17.1
[PATCH v2 1/2] iio: adc: ti-ads7950: use SPDX-License-Identifier
This updates the ti-ads7950.c file to use SPDX-License-Identifier instead of more verbose license text. Signed-off-by: David Lechner --- drivers/iio/adc/ti-ads7950.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c index 0225c1b333ab..f08c4de2bd10 100644 --- a/drivers/iio/adc/ti-ads7950.c +++ b/drivers/iio/adc/ti-ads7950.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Texas Instruments ADS7950 SPI ADC driver * @@ -10,15 +11,6 @@ * And also on hwmon/ads79xx.c * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ * Nishanth Menon - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include -- 2.17.1
[PATCH v2 0/2] iio: adc: ti-ads7950: allow simultaneous use of buffer and direct mode
v2 changes: - add new patch to use SPDX-License-Identifier (since we are touching this file anyway) - don't add struct iio_device *indio_dev as field to private data - fix indent on return statement David Lechner (2): iio: adc: ti-ads7950: use SPDX-License-Identifier iio: adc: ti-ads7950: allow simultaneous use of buffer and direct mode drivers/iio/adc/ti-ads7950.c | 42 1 file changed, 19 insertions(+), 23 deletions(-) -- 2.17.1
[PATCH v2 1/2] iio: adc: ti-ads7950: use SPDX-License-Identifier
This updates the ti-ads7950.c file to use SPDX-License-Identifier instead of more verbose license text. Signed-off-by: David Lechner --- drivers/iio/adc/ti-ads7950.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c index 0225c1b333ab..f08c4de2bd10 100644 --- a/drivers/iio/adc/ti-ads7950.c +++ b/drivers/iio/adc/ti-ads7950.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Texas Instruments ADS7950 SPI ADC driver * @@ -10,15 +11,6 @@ * And also on hwmon/ads79xx.c * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ * Nishanth Menon - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include -- 2.17.1
[PATCH v2 2/2] iio: adc: ti-ads7950: allow simultaneous use of buffer and direct mode
This modifies the TI ADS7950 A/DC driver to allow the simultaneous use
of both the triggered buffer and reading channels directly (via in-
kernel API or sysfs).
The use case for this is on LEGO MINDSTORMS EV3. Two of the voltage
channels are used in-kernel by a power supply driver, which reads the
values using iio_read_channel_processed(). These channels are only read
at a slow rate (<= 1Hz). However, we want to be able to read 12 other
channels at the same time using the triggered buffer at a high rate (>=
100Hz).
Signed-off-by: David Lechner
---
drivers/iio/adc/ti-ads7950.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
index f08c4de2bd10..eae987bef994 100644
--- a/drivers/iio/adc/ti-ads7950.c
+++ b/drivers/iio/adc/ti-ads7950.c
@@ -60,6 +60,8 @@ struct ti_ads7950_state {
unsigned intvref_mv;
unsigned intsettings;
+ __be16 single_tx;
+ __be16 single_rx;
/*
* DMA (thus cache coherency maintenance) requires the
@@ -287,18 +289,26 @@ static irqreturn_t ti_ads7950_trigger_handler(int irq,
void *p)
return IRQ_HANDLED;
}
-static int ti_ads7950_scan_direct(struct ti_ads7950_state *st, unsigned int ch)
+static int ti_ads7950_scan_direct(struct iio_dev *indio_dev, unsigned int ch)
{
+ struct ti_ads7950_state *st = iio_priv(indio_dev);
int ret, cmd;
+ mutex_lock(_dev->mlock);
+
cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings;
- st->tx_buf[0] = cpu_to_be16(cmd);
+ st->single_tx = cpu_to_be16(cmd);
ret = spi_sync(st->spi, >scan_single_msg);
if (ret)
- return ret;
+ goto out;
+
+ ret = be16_to_cpu(st->single_rx);
+
+out:
+ mutex_unlock(_dev->mlock);
- return be16_to_cpu(st->rx_buf[0]);
+ return ret;
}
static int ti_ads7950_get_range(struct ti_ads7950_state *st)
@@ -330,13 +340,7 @@ static int ti_ads7950_read_raw(struct iio_dev *indio_dev,
switch (m) {
case IIO_CHAN_INFO_RAW:
-
- ret = iio_device_claim_direct_mode(indio_dev);
- if (ret < 0)
- return ret;
-
- ret = ti_ads7950_scan_direct(st, chan->address);
- iio_device_release_direct_mode(indio_dev);
+ ret = ti_ads7950_scan_direct(indio_dev, chan->address);
if (ret < 0)
return ret;
@@ -402,13 +406,13 @@ static int ti_ads7950_probe(struct spi_device *spi)
* was read at the end of the first transfer.
*/
- st->scan_single_xfer[0].tx_buf = >tx_buf[0];
+ st->scan_single_xfer[0].tx_buf = >single_tx;
st->scan_single_xfer[0].len = 2;
st->scan_single_xfer[0].cs_change = 1;
- st->scan_single_xfer[1].tx_buf = >tx_buf[0];
+ st->scan_single_xfer[1].tx_buf = >single_tx;
st->scan_single_xfer[1].len = 2;
st->scan_single_xfer[1].cs_change = 1;
- st->scan_single_xfer[2].rx_buf = >rx_buf[0];
+ st->scan_single_xfer[2].rx_buf = >single_rx;
st->scan_single_xfer[2].len = 2;
spi_message_init_with_transfers(>scan_single_msg,
--
2.17.1
[PATCH v2 2/2] iio: adc: ti-ads7950: allow simultaneous use of buffer and direct mode
This modifies the TI ADS7950 A/DC driver to allow the simultaneous use
of both the triggered buffer and reading channels directly (via in-
kernel API or sysfs).
The use case for this is on LEGO MINDSTORMS EV3. Two of the voltage
channels are used in-kernel by a power supply driver, which reads the
values using iio_read_channel_processed(). These channels are only read
at a slow rate (<= 1Hz). However, we want to be able to read 12 other
channels at the same time using the triggered buffer at a high rate (>=
100Hz).
Signed-off-by: David Lechner
---
drivers/iio/adc/ti-ads7950.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
index f08c4de2bd10..eae987bef994 100644
--- a/drivers/iio/adc/ti-ads7950.c
+++ b/drivers/iio/adc/ti-ads7950.c
@@ -60,6 +60,8 @@ struct ti_ads7950_state {
unsigned intvref_mv;
unsigned intsettings;
+ __be16 single_tx;
+ __be16 single_rx;
/*
* DMA (thus cache coherency maintenance) requires the
@@ -287,18 +289,26 @@ static irqreturn_t ti_ads7950_trigger_handler(int irq,
void *p)
return IRQ_HANDLED;
}
-static int ti_ads7950_scan_direct(struct ti_ads7950_state *st, unsigned int ch)
+static int ti_ads7950_scan_direct(struct iio_dev *indio_dev, unsigned int ch)
{
+ struct ti_ads7950_state *st = iio_priv(indio_dev);
int ret, cmd;
+ mutex_lock(_dev->mlock);
+
cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings;
- st->tx_buf[0] = cpu_to_be16(cmd);
+ st->single_tx = cpu_to_be16(cmd);
ret = spi_sync(st->spi, >scan_single_msg);
if (ret)
- return ret;
+ goto out;
+
+ ret = be16_to_cpu(st->single_rx);
+
+out:
+ mutex_unlock(_dev->mlock);
- return be16_to_cpu(st->rx_buf[0]);
+ return ret;
}
static int ti_ads7950_get_range(struct ti_ads7950_state *st)
@@ -330,13 +340,7 @@ static int ti_ads7950_read_raw(struct iio_dev *indio_dev,
switch (m) {
case IIO_CHAN_INFO_RAW:
-
- ret = iio_device_claim_direct_mode(indio_dev);
- if (ret < 0)
- return ret;
-
- ret = ti_ads7950_scan_direct(st, chan->address);
- iio_device_release_direct_mode(indio_dev);
+ ret = ti_ads7950_scan_direct(indio_dev, chan->address);
if (ret < 0)
return ret;
@@ -402,13 +406,13 @@ static int ti_ads7950_probe(struct spi_device *spi)
* was read at the end of the first transfer.
*/
- st->scan_single_xfer[0].tx_buf = >tx_buf[0];
+ st->scan_single_xfer[0].tx_buf = >single_tx;
st->scan_single_xfer[0].len = 2;
st->scan_single_xfer[0].cs_change = 1;
- st->scan_single_xfer[1].tx_buf = >tx_buf[0];
+ st->scan_single_xfer[1].tx_buf = >single_tx;
st->scan_single_xfer[1].len = 2;
st->scan_single_xfer[1].cs_change = 1;
- st->scan_single_xfer[2].rx_buf = >rx_buf[0];
+ st->scan_single_xfer[2].rx_buf = >single_rx;
st->scan_single_xfer[2].len = 2;
spi_message_init_with_transfers(>scan_single_msg,
--
2.17.1
[PATCH] mtd: solutionengine.c: fix printk format warnings
From: Randy Dunlap
Fix 2 printk format warnings (this driver is currently SUPERH only)
by using "%pap" instead of "%lx".
(or we could just cast the physical addresses to unsigned int)
Fixes these build warnings:
../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Signed-off-by: Randy Dunlap
---
drivers/mtd/maps/solutionengine.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- linux-next-20180720.orig/drivers/mtd/maps/solutionengine.c
+++ linux-next-20180720/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,13 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
- printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at
0x%08lx\n",
- soleng_flash_map.phys & 0x1fff,
- soleng_eprom_map.phys & 0x1fff);
+ {
+ resource_size_t fl_phys = soleng_flash_map.phys & 0x1fff;
+ resource_size_t ep_phys = soleng_eprom_map.phys & 0x1fff;
+
+ printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at
0x%pap\n",
+ _phys, _phys);
+ }
flash_mtd->owner = THIS_MODULE;
eprom_mtd = do_map_probe("map_rom", _eprom_map);
[PATCH] mtd: solutionengine.c: fix printk format warnings
From: Randy Dunlap
Fix 2 printk format warnings (this driver is currently SUPERH only)
by using "%pap" instead of "%lx".
(or we could just cast the physical addresses to unsigned int)
Fixes these build warnings:
../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Signed-off-by: Randy Dunlap
---
drivers/mtd/maps/solutionengine.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- linux-next-20180720.orig/drivers/mtd/maps/solutionengine.c
+++ linux-next-20180720/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,13 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
- printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at
0x%08lx\n",
- soleng_flash_map.phys & 0x1fff,
- soleng_eprom_map.phys & 0x1fff);
+ {
+ resource_size_t fl_phys = soleng_flash_map.phys & 0x1fff;
+ resource_size_t ep_phys = soleng_eprom_map.phys & 0x1fff;
+
+ printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at
0x%pap\n",
+ _phys, _phys);
+ }
flash_mtd->owner = THIS_MODULE;
eprom_mtd = do_map_probe("map_rom", _eprom_map);
[PATCH v2 05/10] staging:rtl8192u: Rename CountryIeLen > country_ie_len - Style
Rename CountryIeLen to country_ie_len, coding style change to clear
checkpatch issue with CamelCase naming. The change should have no
impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/dot11d.c | 6 +++---
drivers/staging/rtl8192u/ieee80211/dot11d.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c
b/drivers/staging/rtl8192u/ieee80211/dot11d.c
index 3d2eb19a7f48..87af2ddae349 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.c
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.c
@@ -10,7 +10,7 @@ void Dot11d_Init(struct ieee80211_device *ieee)
pDot11dInfo->enabled = false;
pDot11dInfo->State = DOT11D_STATE_NONE;
- pDot11dInfo->CountryIeLen = 0;
+ pDot11dInfo->country_ie_len = 0;
memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER + 1);
memset(pDot11dInfo->MaxTxPwrDbmList, 0xFF, MAX_CHANNEL_NUMBER+1);
RESET_CIE_WATCHDOG(ieee);
@@ -35,7 +35,7 @@ void Dot11d_Reset(struct ieee80211_device *ieee)
(pDot11dInfo->channel_map)[i] = 2;
pDot11dInfo->State = DOT11D_STATE_NONE;
- pDot11dInfo->CountryIeLen = 0;
+ pDot11dInfo->country_ie_len = 0;
RESET_CIE_WATCHDOG(ieee);
}
EXPORT_SYMBOL(Dot11d_Reset);
@@ -93,7 +93,7 @@ void Dot11d_UpdateCountryIe(struct ieee80211_device *dev, u8
*pTaddr,
UPDATE_CIE_SRC(dev, pTaddr);
- pDot11dInfo->CountryIeLen = CoutryIeLen;
+ pDot11dInfo->country_ie_len = CoutryIeLen;
memcpy(pDot11dInfo->CountryIeBuf, pCoutryIe, CoutryIeLen);
pDot11dInfo->State = DOT11D_STATE_LEARNED;
}
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.h
b/drivers/staging/rtl8192u/ieee80211/dot11d.h
index cfe342d0b4bb..a15b21456101 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.h
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.h
@@ -21,7 +21,7 @@ struct rt_dot11d_info {
bool enabled; /* dot11MultiDomainCapabilityEnabled */
- u16 CountryIeLen; /* > 0 if CountryIeBuf[] contains valid country
information element. */
+ u16 country_ie_len; /* > 0 if CountryIeBuf[] contains valid country
information element. */
u8 CountryIeBuf[MAX_IE_LEN];
u8 CountryIeSrcAddr[6]; /* Source AP of the country IE. */
u8 CountryIeWatchdog;
@@ -42,13 +42,13 @@ struct rt_dot11d_info {
#define GET_DOT11D_INFO(__pIeeeDev) ((struct rt_dot11d_info
*)((__pIeeeDev)->pDot11dInfo))
#define IS_DOT11D_ENABLE(__pIeeeDev) (GET_DOT11D_INFO(__pIeeeDev)->enabled)
-#define IS_COUNTRY_IE_VALID(__pIeeeDev)
(GET_DOT11D_INFO(__pIeeeDev)->CountryIeLen > 0)
+#define IS_COUNTRY_IE_VALID(__pIeeeDev)
(GET_DOT11D_INFO(__pIeeeDev)->country_ie_len > 0)
#define IS_EQUAL_CIE_SRC(__pIeeeDev, __pTa)
eqMacAddr(GET_DOT11D_INFO(__pIeeeDev)->CountryIeSrcAddr, __pTa)
#define UPDATE_CIE_SRC(__pIeeeDev, __pTa)
cpMacAddr(GET_DOT11D_INFO(__pIeeeDev)->CountryIeSrcAddr, __pTa)
#define IS_COUNTRY_IE_CHANGED(__pIeeeDev, __Ie) \
- (((__Ie).Length == 0 || (__Ie).Length !=
GET_DOT11D_INFO(__pIeeeDev)->CountryIeLen) ? \
+ (((__Ie).Length == 0 || (__Ie).Length !=
GET_DOT11D_INFO(__pIeeeDev)->country_ie_len) ? \
FALSE : \
(!memcmp(GET_DOT11D_INFO(__pIeeeDev)->CountryIeBuf, (__Ie).Octet,
(__Ie).Length)))
--
2.18.0
[PATCH v2 04/10] staging:rtl8192u: Rename bEnabled > enabled - Style
Rename the member variable bEnabled to enabled. This change clears the
checkpatch issue with CamelCase. Purely a coding style change which should not
impact runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/dot11d.c | 2 +-
drivers/staging/rtl8192u/ieee80211/dot11d.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c
b/drivers/staging/rtl8192u/ieee80211/dot11d.c
index cd63e158c7c8..3d2eb19a7f48 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.c
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.c
@@ -7,7 +7,7 @@ void Dot11d_Init(struct ieee80211_device *ieee)
{
struct rt_dot11d_info *pDot11dInfo = GET_DOT11D_INFO(ieee);
- pDot11dInfo->bEnabled = false;
+ pDot11dInfo->enabled = false;
pDot11dInfo->State = DOT11D_STATE_NONE;
pDot11dInfo->CountryIeLen = 0;
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.h
b/drivers/staging/rtl8192u/ieee80211/dot11d.h
index 8f7426333da5..cfe342d0b4bb 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.h
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.h
@@ -19,7 +19,7 @@ enum dot11d_state {
struct rt_dot11d_info {
/* DECLARE_RT_OBJECT(rt_dot11d_info); */
- bool bEnabled; /* dot11MultiDomainCapabilityEnabled */
+ bool enabled; /* dot11MultiDomainCapabilityEnabled */
u16 CountryIeLen; /* > 0 if CountryIeBuf[] contains valid country
information element. */
u8 CountryIeBuf[MAX_IE_LEN];
@@ -41,7 +41,7 @@ struct rt_dot11d_info {
(des)[5] = (src)[5])
#define GET_DOT11D_INFO(__pIeeeDev) ((struct rt_dot11d_info
*)((__pIeeeDev)->pDot11dInfo))
-#define IS_DOT11D_ENABLE(__pIeeeDev) (GET_DOT11D_INFO(__pIeeeDev)->bEnabled)
+#define IS_DOT11D_ENABLE(__pIeeeDev) (GET_DOT11D_INFO(__pIeeeDev)->enabled)
#define IS_COUNTRY_IE_VALID(__pIeeeDev)
(GET_DOT11D_INFO(__pIeeeDev)->CountryIeLen > 0)
#define IS_EQUAL_CIE_SRC(__pIeeeDev, __pTa)
eqMacAddr(GET_DOT11D_INFO(__pIeeeDev)->CountryIeSrcAddr, __pTa)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index cf39c0bc2a26..c99923d467a7 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -211,7 +211,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct
r8192_priv *priv)
/* this flag enabled to follow 11d country IE setting,
* otherwise, it shall follow global domain settings.
*/
- GET_DOT11D_INFO(ieee)->bEnabled = 0;
+ GET_DOT11D_INFO(ieee)->enabled = 0;
Dot11d_Reset(ieee);
ieee->bGlobalDomain = true;
break;
--
2.18.0
[PATCH v2 00/10] staging:rtl8192u: Coding style changes
These patches are previously failed patches from two seperate series of coding style changes. I've just combined the failed from both into this series. I compiled the patches with 'format-patch -v2' Never used the '-v' option previously so hope it's not a mistake to do so. Guess I'll find out if it is. Thanks John Whitmore (10): staging:rtl8192u: Rename TClasProc > t_clas_proc - Style staging:rtl8192u: Rename TClasNum > t_clas_num - Style staging:rtl8192u: Remove typedef and rename struct RT_DOT11D_INFO - Style staging:rtl8192u: Rename bEnabled > enabled - Style staging:rtl8192u: Rename CountryIeLen > country_ie_len - Style staging:rtl8192u: Rename CountryIeBuf to country_ie_buf - Style staging:rtl8192u: Rename variable CountryIeSrcAddr - Style staging:rtl8192u: Rename CountryIeWatchdog > country_ie_watchdog - Style staging:rtl8192u: Rename MaxTxPwrDbmList > max_tx_pwr_dbm_list - Style staging:rtl8192u: Rename variable State > state - Style drivers/staging/rtl8192u/ieee80211/dot11d.c | 44 +-- drivers/staging/rtl8192u/ieee80211/dot11d.h | 39 .../rtl8192u/ieee80211/ieee80211_softmac.c| 2 +- .../staging/rtl8192u/ieee80211/rtl819x_TS.h | 4 +- .../rtl8192u/ieee80211/rtl819x_TSProc.c | 8 ++-- drivers/staging/rtl8192u/r8192U_core.c| 2 +- 6 files changed, 50 insertions(+), 49 deletions(-) -- 2.18.0
[PATCH v2 09/10] staging:rtl8192u: Rename MaxTxPwrDbmList > max_tx_pwr_dbm_list - Style
Rename the member variable MaxTxPwrDbmList to max_tx_pwr_dbm_list. This
change clears the checkpatch issue with CamelCase naming. The change is
a simple coding style change which should not impact runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/dot11d.c | 10 +-
drivers/staging/rtl8192u/ieee80211/dot11d.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c
b/drivers/staging/rtl8192u/ieee80211/dot11d.c
index b1205345a7e0..21912b2d728d 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.c
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.c
@@ -12,7 +12,7 @@ void Dot11d_Init(struct ieee80211_device *ieee)
pDot11dInfo->State = DOT11D_STATE_NONE;
pDot11dInfo->country_ie_len = 0;
memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER + 1);
- memset(pDot11dInfo->MaxTxPwrDbmList, 0xFF, MAX_CHANNEL_NUMBER+1);
+ memset(pDot11dInfo->max_tx_pwr_dbm_list, 0xFF, MAX_CHANNEL_NUMBER+1);
RESET_CIE_WATCHDOG(ieee);
netdev_info(ieee->dev, "Dot11d_Init()\n");
@@ -26,7 +26,7 @@ void Dot11d_Reset(struct ieee80211_device *ieee)
struct rt_dot11d_info *pDot11dInfo = GET_DOT11D_INFO(ieee);
/* Clear old channel map */
memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER+1);
- memset(pDot11dInfo->MaxTxPwrDbmList, 0xFF, MAX_CHANNEL_NUMBER+1);
+ memset(pDot11dInfo->max_tx_pwr_dbm_list, 0xFF, MAX_CHANNEL_NUMBER+1);
/* Set new channel map */
for (i = 1; i <= 11; i++)
(pDot11dInfo->channel_map)[i] = 1;
@@ -57,7 +57,7 @@ void Dot11d_UpdateCountryIe(struct ieee80211_device *dev, u8
*pTaddr,
struct chnl_txpower_triple *pTriple;
memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER+1);
- memset(pDot11dInfo->MaxTxPwrDbmList, 0xFF, MAX_CHANNEL_NUMBER+1);
+ memset(pDot11dInfo->max_tx_pwr_dbm_list, 0xFF, MAX_CHANNEL_NUMBER+1);
MaxChnlNum = 0;
NumTriples = (CoutryIeLen - 3) / 3; /* skip 3-byte country string. */
pTriple = (struct chnl_txpower_triple *)(pCoutryIe + 3);
@@ -79,7 +79,7 @@ void Dot11d_UpdateCountryIe(struct ieee80211_device *dev, u8
*pTaddr,
for (j = 0; j < pTriple->num_channels; j++) {
pDot11dInfo->channel_map[pTriple->first_channel + j] =
1;
- pDot11dInfo->MaxTxPwrDbmList[pTriple->first_channel +
j] = pTriple->max_tx_pwr_dbm;
+ pDot11dInfo->max_tx_pwr_dbm_list[pTriple->first_channel
+ j] = pTriple->max_tx_pwr_dbm;
MaxChnlNum = pTriple->first_channel + j;
}
@@ -109,7 +109,7 @@ u8 DOT11D_GetMaxTxPwrInDbm(struct ieee80211_device *dev, u8
Channel)
return MaxTxPwrInDbm;
}
if (pDot11dInfo->channel_map[Channel])
- MaxTxPwrInDbm = pDot11dInfo->MaxTxPwrDbmList[Channel];
+ MaxTxPwrInDbm = pDot11dInfo->max_tx_pwr_dbm_list[Channel];
return MaxTxPwrInDbm;
}
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.h
b/drivers/staging/rtl8192u/ieee80211/dot11d.h
index a7fa1a7f01bd..0c7652a2ebb3 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.h
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.h
@@ -27,7 +27,7 @@ struct rt_dot11d_info {
u8 country_ie_watchdog;
u8 channel_map[MAX_CHANNEL_NUMBER+1]; /* !Value 0: Invalid, 1: Valid
(active scan), 2: Valid (passive scan) */
- u8 MaxTxPwrDbmList[MAX_CHANNEL_NUMBER+1];
+ u8 max_tx_pwr_dbm_list[MAX_CHANNEL_NUMBER+1];
enum dot11d_state State;
};
--
2.18.0
[PATCH v2 05/10] staging:rtl8192u: Rename CountryIeLen > country_ie_len - Style
Rename CountryIeLen to country_ie_len, coding style change to clear
checkpatch issue with CamelCase naming. The change should have no
impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/dot11d.c | 6 +++---
drivers/staging/rtl8192u/ieee80211/dot11d.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c
b/drivers/staging/rtl8192u/ieee80211/dot11d.c
index 3d2eb19a7f48..87af2ddae349 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.c
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.c
@@ -10,7 +10,7 @@ void Dot11d_Init(struct ieee80211_device *ieee)
pDot11dInfo->enabled = false;
pDot11dInfo->State = DOT11D_STATE_NONE;
- pDot11dInfo->CountryIeLen = 0;
+ pDot11dInfo->country_ie_len = 0;
memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER + 1);
memset(pDot11dInfo->MaxTxPwrDbmList, 0xFF, MAX_CHANNEL_NUMBER+1);
RESET_CIE_WATCHDOG(ieee);
@@ -35,7 +35,7 @@ void Dot11d_Reset(struct ieee80211_device *ieee)
(pDot11dInfo->channel_map)[i] = 2;
pDot11dInfo->State = DOT11D_STATE_NONE;
- pDot11dInfo->CountryIeLen = 0;
+ pDot11dInfo->country_ie_len = 0;
RESET_CIE_WATCHDOG(ieee);
}
EXPORT_SYMBOL(Dot11d_Reset);
@@ -93,7 +93,7 @@ void Dot11d_UpdateCountryIe(struct ieee80211_device *dev, u8
*pTaddr,
UPDATE_CIE_SRC(dev, pTaddr);
- pDot11dInfo->CountryIeLen = CoutryIeLen;
+ pDot11dInfo->country_ie_len = CoutryIeLen;
memcpy(pDot11dInfo->CountryIeBuf, pCoutryIe, CoutryIeLen);
pDot11dInfo->State = DOT11D_STATE_LEARNED;
}
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.h
b/drivers/staging/rtl8192u/ieee80211/dot11d.h
index cfe342d0b4bb..a15b21456101 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.h
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.h
@@ -21,7 +21,7 @@ struct rt_dot11d_info {
bool enabled; /* dot11MultiDomainCapabilityEnabled */
- u16 CountryIeLen; /* > 0 if CountryIeBuf[] contains valid country
information element. */
+ u16 country_ie_len; /* > 0 if CountryIeBuf[] contains valid country
information element. */
u8 CountryIeBuf[MAX_IE_LEN];
u8 CountryIeSrcAddr[6]; /* Source AP of the country IE. */
u8 CountryIeWatchdog;
@@ -42,13 +42,13 @@ struct rt_dot11d_info {
#define GET_DOT11D_INFO(__pIeeeDev) ((struct rt_dot11d_info
*)((__pIeeeDev)->pDot11dInfo))
#define IS_DOT11D_ENABLE(__pIeeeDev) (GET_DOT11D_INFO(__pIeeeDev)->enabled)
-#define IS_COUNTRY_IE_VALID(__pIeeeDev)
(GET_DOT11D_INFO(__pIeeeDev)->CountryIeLen > 0)
+#define IS_COUNTRY_IE_VALID(__pIeeeDev)
(GET_DOT11D_INFO(__pIeeeDev)->country_ie_len > 0)
#define IS_EQUAL_CIE_SRC(__pIeeeDev, __pTa)
eqMacAddr(GET_DOT11D_INFO(__pIeeeDev)->CountryIeSrcAddr, __pTa)
#define UPDATE_CIE_SRC(__pIeeeDev, __pTa)
cpMacAddr(GET_DOT11D_INFO(__pIeeeDev)->CountryIeSrcAddr, __pTa)
#define IS_COUNTRY_IE_CHANGED(__pIeeeDev, __Ie) \
- (((__Ie).Length == 0 || (__Ie).Length !=
GET_DOT11D_INFO(__pIeeeDev)->CountryIeLen) ? \
+ (((__Ie).Length == 0 || (__Ie).Length !=
GET_DOT11D_INFO(__pIeeeDev)->country_ie_len) ? \
FALSE : \
(!memcmp(GET_DOT11D_INFO(__pIeeeDev)->CountryIeBuf, (__Ie).Octet,
(__Ie).Length)))
--
2.18.0
[PATCH v2 04/10] staging:rtl8192u: Rename bEnabled > enabled - Style
Rename the member variable bEnabled to enabled. This change clears the
checkpatch issue with CamelCase. Purely a coding style change which should not
impact runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/dot11d.c | 2 +-
drivers/staging/rtl8192u/ieee80211/dot11d.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c
b/drivers/staging/rtl8192u/ieee80211/dot11d.c
index cd63e158c7c8..3d2eb19a7f48 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.c
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.c
@@ -7,7 +7,7 @@ void Dot11d_Init(struct ieee80211_device *ieee)
{
struct rt_dot11d_info *pDot11dInfo = GET_DOT11D_INFO(ieee);
- pDot11dInfo->bEnabled = false;
+ pDot11dInfo->enabled = false;
pDot11dInfo->State = DOT11D_STATE_NONE;
pDot11dInfo->CountryIeLen = 0;
diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.h
b/drivers/staging/rtl8192u/ieee80211/dot11d.h
index 8f7426333da5..cfe342d0b4bb 100644
--- a/drivers/staging/rtl8192u/ieee80211/dot11d.h
+++ b/drivers/staging/rtl8192u/ieee80211/dot11d.h
@@ -19,7 +19,7 @@ enum dot11d_state {
struct rt_dot11d_info {
/* DECLARE_RT_OBJECT(rt_dot11d_info); */
- bool bEnabled; /* dot11MultiDomainCapabilityEnabled */
+ bool enabled; /* dot11MultiDomainCapabilityEnabled */
u16 CountryIeLen; /* > 0 if CountryIeBuf[] contains valid country
information element. */
u8 CountryIeBuf[MAX_IE_LEN];
@@ -41,7 +41,7 @@ struct rt_dot11d_info {
(des)[5] = (src)[5])
#define GET_DOT11D_INFO(__pIeeeDev) ((struct rt_dot11d_info
*)((__pIeeeDev)->pDot11dInfo))
-#define IS_DOT11D_ENABLE(__pIeeeDev) (GET_DOT11D_INFO(__pIeeeDev)->bEnabled)
+#define IS_DOT11D_ENABLE(__pIeeeDev) (GET_DOT11D_INFO(__pIeeeDev)->enabled)
#define IS_COUNTRY_IE_VALID(__pIeeeDev)
(GET_DOT11D_INFO(__pIeeeDev)->CountryIeLen > 0)
#define IS_EQUAL_CIE_SRC(__pIeeeDev, __pTa)
eqMacAddr(GET_DOT11D_INFO(__pIeeeDev)->CountryIeSrcAddr, __pTa)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index cf39c0bc2a26..c99923d467a7 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -211,7 +211,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct
r8192_priv *priv)
/* this flag enabled to follow 11d country IE setting,
* otherwise, it shall follow global domain settings.
*/
- GET_DOT11D_INFO(ieee)->bEnabled = 0;
+ GET_DOT11D_INFO(ieee)->enabled = 0;
Dot11d_Reset(ieee);
ieee->bGlobalDomain = true;
break;
--
2.18.0
