Re: [bug] kpti, perf_event, bts: sporadic truncated trace
On Thu, Jul 12, 2018 at 06:22:13PM -0700, Hugh Dickins wrote: > A little "optimization" crept into alloc_bts_buffer() along the way, > which now places bts_interrupt_threshold not on a record boundary. > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says > "This address must point to an offset from the BTS buffer base that > is a multiple of the BTS record size." > > Please give the patch below a try, and let us know if it helps (if it > does not, then I think we'll need perfier expertise than I can give). Ooh, good find! > --- 4.18-rc4/arch/x86/events/intel/ds.c 2018-06-03 14:15:21.0 > -0700 > +++ linux/arch/x86/events/intel/ds.c 2018-07-12 17:38:28.471378616 -0700 > @@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu) > ds->bts_buffer_base = (unsigned long) cea; > ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL); > ds->bts_index = ds->bts_buffer_base; > - max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE); > - ds->bts_absolute_maximum = ds->bts_buffer_base + max; > - ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16); > + max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE; > + ds->bts_absolute_maximum = ds->bts_buffer_base + > + max * BTS_RECORD_SIZE; > + ds->bts_interrupt_threshold = ds->bts_absolute_maximum - > + (max / 16) * BTS_RECORD_SIZE; > return 0; > } >
Re: [bug] kpti, perf_event, bts: sporadic truncated trace
On Thu, Jul 12, 2018 at 06:22:13PM -0700, Hugh Dickins wrote: > A little "optimization" crept into alloc_bts_buffer() along the way, > which now places bts_interrupt_threshold not on a record boundary. > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says > "This address must point to an offset from the BTS buffer base that > is a multiple of the BTS record size." > > Please give the patch below a try, and let us know if it helps (if it > does not, then I think we'll need perfier expertise than I can give). Ooh, good find! > --- 4.18-rc4/arch/x86/events/intel/ds.c 2018-06-03 14:15:21.0 > -0700 > +++ linux/arch/x86/events/intel/ds.c 2018-07-12 17:38:28.471378616 -0700 > @@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu) > ds->bts_buffer_base = (unsigned long) cea; > ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL); > ds->bts_index = ds->bts_buffer_base; > - max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE); > - ds->bts_absolute_maximum = ds->bts_buffer_base + max; > - ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16); > + max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE; > + ds->bts_absolute_maximum = ds->bts_buffer_base + > + max * BTS_RECORD_SIZE; > + ds->bts_interrupt_threshold = ds->bts_absolute_maximum - > + (max / 16) * BTS_RECORD_SIZE; > return 0; > } >
Re: [PATCH v6 14/21] s390: vfio-ap: implement mediated device open callback
On 07/12/2018 06:03 PM, Tony Krowiak wrote:
+static int vfio_ap_mdev_open(struct mdev_device *mdev)
+{
+struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
+struct ap_matrix_dev *matrix_dev =
+to_ap_matrix_dev(mdev_parent_dev(mdev));
+unsigned long events;
+int ret;
+
+if (!try_module_get(THIS_MODULE))
+return -ENODEV;
+
+ret = vfio_ap_verify_queues_reserved(matrix_dev, matrix_mdev->name,
+ _mdev->matrix);
+if (ret)
+goto out_err;
+
+ matrix_mdev->group_notifier.notifier_call = vfio_ap_mdev_group_notifier;
+events = VFIO_GROUP_NOTIFY_SET_KVM;
+
+ret = vfio_register_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
+ , _mdev->group_notifier);
+if (ret)
+goto out_err;
+
+ret = kvm_ap_validate_crypto_setup(matrix_mdev->kvm);
At this point you assume that your vfio_ap_mdev_group_notifier callback
was called with VFIO_GROUP_NOTIFY_SET_KVM and that you do have
matrix_mdev->kvm set up properly.
Based on how callbacks usually work this seems rather strange. It's
probably cleaner to set up he cyrcb (including all the validation
that needs to be done immediately before) in the callback
(vfio_ap_mdev_group_notifier).
If that is not viable I think we need a comment here explaining why is this
OK (at least).
This was originally in the callback and moved out, to the best of my
recollection,
because the validation at that time was done on the CRYCB and if that validation
failed, there was no way to notify the client (QEMU) that configuration of the
guest's CRYCB failed from the notification callback. This works - at least as
far
as I can tell from testing - because the registration of the notifier invokes
the
notification callback if KVM has already been set and that appears to be the
case.
You are correct, however; we probably shouldn't bank on that given that
I don't think we can guarantee that to be the case 100% of the time.
Consequently,
I will move this back into the notification callback and since consistency
checking
is now being done on the mdev devices instead of the CRYCB, we don't need KVM
at open
time.
Sounds good to me. Making the open fail was not a good way to communicate this
error condition to userspace anyway.
Regards,
Halil
Re: [PATCH 1/6] swap: Add comments to lock_cluster_or_swap_info()
> +/* > + * At most times, fine grained cluster lock is sufficient to protect Can we call out those times, please? > + * the operations on sis->swap_map. Please be careful with the naming. You can call it 'si' because that's what the function argument is named. Or, swap_info_struct because that's the struct name. Calling it 'sis' is a bit sloppy, no? > No need to acquire gross grained "coarse" is a conventional antonym for "fine". > + * sis->lock. But cluster and cluster lock isn't available for HDD, > + * so sis->lock will be instead for them. > + */ > static inline struct swap_cluster_info *lock_cluster_or_swap_info( > struct swap_info_struct *si, > unsigned long offset) What I already knew was: there are two locks. We use one sometimes and the other at other times. What I don't know is why there are two locks, and the heuristics why we choose between them. This comment doesn't help explain the things I don't know.
Re: [PATCH v6 14/21] s390: vfio-ap: implement mediated device open callback
On 07/12/2018 06:03 PM, Tony Krowiak wrote:
+static int vfio_ap_mdev_open(struct mdev_device *mdev)
+{
+struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
+struct ap_matrix_dev *matrix_dev =
+to_ap_matrix_dev(mdev_parent_dev(mdev));
+unsigned long events;
+int ret;
+
+if (!try_module_get(THIS_MODULE))
+return -ENODEV;
+
+ret = vfio_ap_verify_queues_reserved(matrix_dev, matrix_mdev->name,
+ _mdev->matrix);
+if (ret)
+goto out_err;
+
+ matrix_mdev->group_notifier.notifier_call = vfio_ap_mdev_group_notifier;
+events = VFIO_GROUP_NOTIFY_SET_KVM;
+
+ret = vfio_register_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
+ , _mdev->group_notifier);
+if (ret)
+goto out_err;
+
+ret = kvm_ap_validate_crypto_setup(matrix_mdev->kvm);
At this point you assume that your vfio_ap_mdev_group_notifier callback
was called with VFIO_GROUP_NOTIFY_SET_KVM and that you do have
matrix_mdev->kvm set up properly.
Based on how callbacks usually work this seems rather strange. It's
probably cleaner to set up he cyrcb (including all the validation
that needs to be done immediately before) in the callback
(vfio_ap_mdev_group_notifier).
If that is not viable I think we need a comment here explaining why is this
OK (at least).
This was originally in the callback and moved out, to the best of my
recollection,
because the validation at that time was done on the CRYCB and if that validation
failed, there was no way to notify the client (QEMU) that configuration of the
guest's CRYCB failed from the notification callback. This works - at least as
far
as I can tell from testing - because the registration of the notifier invokes
the
notification callback if KVM has already been set and that appears to be the
case.
You are correct, however; we probably shouldn't bank on that given that
I don't think we can guarantee that to be the case 100% of the time.
Consequently,
I will move this back into the notification callback and since consistency
checking
is now being done on the mdev devices instead of the CRYCB, we don't need KVM
at open
time.
Sounds good to me. Making the open fail was not a good way to communicate this
error condition to userspace anyway.
Regards,
Halil
Re: [PATCH 1/6] swap: Add comments to lock_cluster_or_swap_info()
> +/* > + * At most times, fine grained cluster lock is sufficient to protect Can we call out those times, please? > + * the operations on sis->swap_map. Please be careful with the naming. You can call it 'si' because that's what the function argument is named. Or, swap_info_struct because that's the struct name. Calling it 'sis' is a bit sloppy, no? > No need to acquire gross grained "coarse" is a conventional antonym for "fine". > + * sis->lock. But cluster and cluster lock isn't available for HDD, > + * so sis->lock will be instead for them. > + */ > static inline struct swap_cluster_info *lock_cluster_or_swap_info( > struct swap_info_struct *si, > unsigned long offset) What I already knew was: there are two locks. We use one sometimes and the other at other times. What I don't know is why there are two locks, and the heuristics why we choose between them. This comment doesn't help explain the things I don't know.
Re: [LKP] [lkp-robot] 9cf57731b6 [ 8.051016] WARNING: CPU: 1 PID: 58 at lib/list_debug.c:28 __list_add_valid
On Fri, Jul 13, 2018 at 12:32:41PM +0800, Rong Chen wrote:
> Thanks, it's fixed with the patch.
Ingo, could you merge?
---
Subject: watchdog/softlockup: Fix cpu_stop_queue_work double-queue
From: Peter Zijlstra
Date: Wed, 11 Jul 2018 14:34:36 +0200
When scheduling is delayed for longer than the softlockup interrupt
period it is possible to double-queue the cpu_stop_work, causing list
corruption.
Cure this by adding a completion to track the cpu_stop_work's
progress.
Reported-by: kernel test robot
Tested-by: Rong Chen
Fixes: 9cf57731b63e ("watchdog/softlockup: Replace "watchdog/%u" threads with
cpu_stop_work")
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/watchdog.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index b81f777838d5..5470dce212c0 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -330,6 +330,9 @@ static void watchdog_interrupt_count(void)
__this_cpu_inc(hrtimer_interrupts);
}
+static DEFINE_PER_CPU(struct completion, softlockup_completion);
+static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
+
/*
* The watchdog thread function - touches the timestamp.
*
@@ -343,12 +346,11 @@ static int softlockup_fn(void *data)
__this_cpu_write(soft_lockup_hrtimer_cnt,
__this_cpu_read(hrtimer_interrupts));
__touch_watchdog();
+ complete(this_cpu_ptr(_completion));
return 0;
}
-static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
-
/* watchdog kicker functions */
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
{
@@ -364,9 +366,12 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
watchdog_interrupt_count();
/* kick the softlockup detector */
- stop_one_cpu_nowait(smp_processor_id(),
- softlockup_fn, NULL,
- this_cpu_ptr(_stop_work));
+ if (completion_done(this_cpu_ptr(_completion))) {
+ reinit_completion(this_cpu_ptr(_completion));
+ stop_one_cpu_nowait(smp_processor_id(),
+ softlockup_fn, NULL,
+ this_cpu_ptr(_stop_work));
+ }
/* .. and repeat */
hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));
@@ -467,9 +472,13 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
static void watchdog_enable(unsigned int cpu)
{
struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);
+ struct completion *done = this_cpu_ptr(_completion);
WARN_ON_ONCE(cpu != smp_processor_id());
+ init_completion(done);
+ complete(done);
+
/*
* Start the timer first to prevent the NMI watchdog triggering
* before the timer has a chance to fire.
@@ -499,6 +508,7 @@ static void watchdog_disable(unsigned int cpu)
*/
watchdog_nmi_disable(cpu);
hrtimer_cancel(hrtimer);
+ wait_for_completion(this_cpu_ptr(_completion));
}
static int softlockup_stop_fn(void *data)
Re: [LKP] [lkp-robot] 9cf57731b6 [ 8.051016] WARNING: CPU: 1 PID: 58 at lib/list_debug.c:28 __list_add_valid
On Fri, Jul 13, 2018 at 12:32:41PM +0800, Rong Chen wrote:
> Thanks, it's fixed with the patch.
Ingo, could you merge?
---
Subject: watchdog/softlockup: Fix cpu_stop_queue_work double-queue
From: Peter Zijlstra
Date: Wed, 11 Jul 2018 14:34:36 +0200
When scheduling is delayed for longer than the softlockup interrupt
period it is possible to double-queue the cpu_stop_work, causing list
corruption.
Cure this by adding a completion to track the cpu_stop_work's
progress.
Reported-by: kernel test robot
Tested-by: Rong Chen
Fixes: 9cf57731b63e ("watchdog/softlockup: Replace "watchdog/%u" threads with
cpu_stop_work")
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/watchdog.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index b81f777838d5..5470dce212c0 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -330,6 +330,9 @@ static void watchdog_interrupt_count(void)
__this_cpu_inc(hrtimer_interrupts);
}
+static DEFINE_PER_CPU(struct completion, softlockup_completion);
+static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
+
/*
* The watchdog thread function - touches the timestamp.
*
@@ -343,12 +346,11 @@ static int softlockup_fn(void *data)
__this_cpu_write(soft_lockup_hrtimer_cnt,
__this_cpu_read(hrtimer_interrupts));
__touch_watchdog();
+ complete(this_cpu_ptr(_completion));
return 0;
}
-static DEFINE_PER_CPU(struct cpu_stop_work, softlockup_stop_work);
-
/* watchdog kicker functions */
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
{
@@ -364,9 +366,12 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
watchdog_interrupt_count();
/* kick the softlockup detector */
- stop_one_cpu_nowait(smp_processor_id(),
- softlockup_fn, NULL,
- this_cpu_ptr(_stop_work));
+ if (completion_done(this_cpu_ptr(_completion))) {
+ reinit_completion(this_cpu_ptr(_completion));
+ stop_one_cpu_nowait(smp_processor_id(),
+ softlockup_fn, NULL,
+ this_cpu_ptr(_stop_work));
+ }
/* .. and repeat */
hrtimer_forward_now(hrtimer, ns_to_ktime(sample_period));
@@ -467,9 +472,13 @@ static enum hrtimer_restart watchdog_timer_fn(struct
hrtimer *hrtimer)
static void watchdog_enable(unsigned int cpu)
{
struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);
+ struct completion *done = this_cpu_ptr(_completion);
WARN_ON_ONCE(cpu != smp_processor_id());
+ init_completion(done);
+ complete(done);
+
/*
* Start the timer first to prevent the NMI watchdog triggering
* before the timer has a chance to fire.
@@ -499,6 +508,7 @@ static void watchdog_disable(unsigned int cpu)
*/
watchdog_nmi_disable(cpu);
hrtimer_cancel(hrtimer);
+ wait_for_completion(this_cpu_ptr(_completion));
}
static int softlockup_stop_fn(void *data)
Re: INFO: task hung in __sb_start_write
Dmitry noticed what is wrong and fixed the bug as https://github.com/google/syzkaller/commit/06c33b3af0ff4072fb002879f83077c9d162a224 . Since the bug did not reproduce for last 24 hours, it is OK to close this report. #syz invalid Thanks all.
Re: INFO: task hung in __sb_start_write
Dmitry noticed what is wrong and fixed the bug as https://github.com/google/syzkaller/commit/06c33b3af0ff4072fb002879f83077c9d162a224 . Since the bug did not reproduce for last 24 hours, it is OK to close this report. #syz invalid Thanks all.
Re: [PATCH] soc: imx6qp: Use GENPD_FLAG_ALWAYS_ON for PU errata
Am Freitag, den 13.07.2018, 13:01 +0300 schrieb Leonard Crestez:
> This is functionally identical but simpler and slightly faster.
>
> The PU domain is turned on at boot time and never turned off. In the
> current implementation the pm core will repeatedly call power_off when
> the domain is unused and get -EBUSY back. If the domain is marked as
> "always on" instead the pm core won't even attempt to turn it off.
>
> In theory on 6qp it is safe to turn PU off in suspend, however that is
> best accomplished with a new core flag.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Lucas Stach
> ---
> drivers/soc/imx/gpc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> Previous discussion:
> * https://lkml.org/lkml/2018/7/11/431
> * https://lkml.org/lkml/2018/7/10/103
>
> Attempt at turning PU off in suspend:
> * https://lkml.org/lkml/2018/7/6/698
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index faf13a0b85d6..f31978e5af20 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -45,11 +45,10 @@ struct imx_pm_domain {
> > struct clk *clk[GPC_CLK_MAX];
> > int num_clks;
> > unsigned int reg_offs;
> > signed char cntr_pdn_bit;
> > unsigned int ipg_rate_mhz;
> > - unsigned int flags;
> };
>
> static inline struct imx_pm_domain *
> to_imx_pm_domain(struct generic_pm_domain *genpd)
> {
> @@ -60,13 +59,10 @@ static int imx6_pm_domain_power_off(struct
> generic_pm_domain *genpd)
> {
> > struct imx_pm_domain *pd = to_imx_pm_domain(genpd);
> > int iso, iso2sw;
> > u32 val;
>
> > - if (pd->flags & PGC_DOMAIN_FLAG_NO_PD)
> > - return -EBUSY;
> -
> > /* Read ISO and ISO2SW power down delays */
> > regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, );
> > iso = val & 0x3f;
> > iso2sw = (val >> 8) & 0x3f;
>
> @@ -419,12 +415,12 @@ static int imx_gpc_probe(struct platform_device *pdev)
> > return ret;
> > }
>
> > /* Disable PU power down in normal operation if ERR009619 is present */
> > if (of_id_data->err009619_present)
> > - imx_gpc_domains[GPC_PGC_DOMAIN_PU].flags |=
> > - PGC_DOMAIN_FLAG_NO_PD;
> > + imx_gpc_domains[GPC_PGC_DOMAIN_PU].base.flags |=
> > + GENPD_FLAG_ALWAYS_ON;
>
> > /* Keep DISP always on if ERR006287 is present */
> > if (of_id_data->err006287_present)
> > imx_gpc_domains[GPC_PGC_DOMAIN_DISPLAY].base.flags |=
> > GENPD_FLAG_ALWAYS_ON;
Re: [PATCH] soc: imx6qp: Use GENPD_FLAG_ALWAYS_ON for PU errata
Am Freitag, den 13.07.2018, 13:01 +0300 schrieb Leonard Crestez:
> This is functionally identical but simpler and slightly faster.
>
> The PU domain is turned on at boot time and never turned off. In the
> current implementation the pm core will repeatedly call power_off when
> the domain is unused and get -EBUSY back. If the domain is marked as
> "always on" instead the pm core won't even attempt to turn it off.
>
> In theory on 6qp it is safe to turn PU off in suspend, however that is
> best accomplished with a new core flag.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Lucas Stach
> ---
> drivers/soc/imx/gpc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> Previous discussion:
> * https://lkml.org/lkml/2018/7/11/431
> * https://lkml.org/lkml/2018/7/10/103
>
> Attempt at turning PU off in suspend:
> * https://lkml.org/lkml/2018/7/6/698
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index faf13a0b85d6..f31978e5af20 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -45,11 +45,10 @@ struct imx_pm_domain {
> > struct clk *clk[GPC_CLK_MAX];
> > int num_clks;
> > unsigned int reg_offs;
> > signed char cntr_pdn_bit;
> > unsigned int ipg_rate_mhz;
> > - unsigned int flags;
> };
>
> static inline struct imx_pm_domain *
> to_imx_pm_domain(struct generic_pm_domain *genpd)
> {
> @@ -60,13 +59,10 @@ static int imx6_pm_domain_power_off(struct
> generic_pm_domain *genpd)
> {
> > struct imx_pm_domain *pd = to_imx_pm_domain(genpd);
> > int iso, iso2sw;
> > u32 val;
>
> > - if (pd->flags & PGC_DOMAIN_FLAG_NO_PD)
> > - return -EBUSY;
> -
> > /* Read ISO and ISO2SW power down delays */
> > regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, );
> > iso = val & 0x3f;
> > iso2sw = (val >> 8) & 0x3f;
>
> @@ -419,12 +415,12 @@ static int imx_gpc_probe(struct platform_device *pdev)
> > return ret;
> > }
>
> > /* Disable PU power down in normal operation if ERR009619 is present */
> > if (of_id_data->err009619_present)
> > - imx_gpc_domains[GPC_PGC_DOMAIN_PU].flags |=
> > - PGC_DOMAIN_FLAG_NO_PD;
> > + imx_gpc_domains[GPC_PGC_DOMAIN_PU].base.flags |=
> > + GENPD_FLAG_ALWAYS_ON;
>
> > /* Keep DISP always on if ERR006287 is present */
> > if (of_id_data->err006287_present)
> > imx_gpc_domains[GPC_PGC_DOMAIN_DISPLAY].base.flags |=
> > GENPD_FLAG_ALWAYS_ON;
[PATCH] clk: mvebu: armada-37xx-periph: Fix wrong return value in get_parent
The return value of the get_parent operation is a u8, whereas a -EINVAL
was returned. This wrong value was return if the value was bigger that
the number of parent but this case was already handled by the core.
So we can just remove this chunk of code to fix the issue.
Reported-by: Dan Carpenter
Fixes: 9818a7a4fd10 ("clk: mvebu: armada-37xx-periph: prepare cpu clk to
be used with DVFS")
Signed-off-by: Gregory CLEMENT
---
drivers/clk/mvebu/armada-37xx-periph.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c
b/drivers/clk/mvebu/armada-37xx-periph.c
index a51edaab0c5c..287e98a7cff4 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -426,9 +426,6 @@ static u8 clk_pm_cpu_get_parent(struct clk_hw *hw)
val &= pm_cpu->mask_mux;
}
- if (val >= num_parents)
- return -EINVAL;
-
return val;
}
--
2.18.0
[PATCH] clk: mvebu: armada-37xx-periph: Fix wrong return value in get_parent
The return value of the get_parent operation is a u8, whereas a -EINVAL
was returned. This wrong value was return if the value was bigger that
the number of parent but this case was already handled by the core.
So we can just remove this chunk of code to fix the issue.
Reported-by: Dan Carpenter
Fixes: 9818a7a4fd10 ("clk: mvebu: armada-37xx-periph: prepare cpu clk to
be used with DVFS")
Signed-off-by: Gregory CLEMENT
---
drivers/clk/mvebu/armada-37xx-periph.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c
b/drivers/clk/mvebu/armada-37xx-periph.c
index a51edaab0c5c..287e98a7cff4 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -426,9 +426,6 @@ static u8 clk_pm_cpu_get_parent(struct clk_hw *hw)
val &= pm_cpu->mask_mux;
}
- if (val >= num_parents)
- return -EINVAL;
-
return val;
}
--
2.18.0
Re: [PATCH V2 00/19] C-SKY(csky) Linux Kernel Port
Sandra Loosemore wrote: > I'm not familiar with the Fedora tools, but to build a complete toolchain > you'll need library support as well and I'm not sure what the submission > status/plans for that are. The idea behind the cross-gcc package in Fedora is that it's for kernel builds and bootloader-type things only. It builds libgcc, but doesn't use kernel headers or a C library[*] as this enormously simplifies things. The reasons being: (1) Not all arches can use the same set of C libraries (some can't use glibc and some don't have a uClibc port). (2) I can only build each individual compiler against a single C library - so if you have two or more incompatible environments, you're out of luck - I can only use one. (3) Building lots more compilers for individual environments would massively increase the build size and time. A full cross-gcc build now takes the best part of a day to build. [*] Yes, there's one exception: it builds the arm compiler against an arm cross-glibc - not my idea. David
Re: [PATCH V2 00/19] C-SKY(csky) Linux Kernel Port
Sandra Loosemore wrote: > I'm not familiar with the Fedora tools, but to build a complete toolchain > you'll need library support as well and I'm not sure what the submission > status/plans for that are. The idea behind the cross-gcc package in Fedora is that it's for kernel builds and bootloader-type things only. It builds libgcc, but doesn't use kernel headers or a C library[*] as this enormously simplifies things. The reasons being: (1) Not all arches can use the same set of C libraries (some can't use glibc and some don't have a uClibc port). (2) I can only build each individual compiler against a single C library - so if you have two or more incompatible environments, you're out of luck - I can only use one. (3) Building lots more compilers for individual environments would massively increase the build size and time. A full cross-gcc build now takes the best part of a day to build. [*] Yes, there's one exception: it builds the arm compiler against an arm cross-glibc - not my idea. David
Re: [PATCH 2/3] mtd: atmel nand: fix build warning on 64-bit
On Fri, Jul 13, 2018 at 11:56 AM, Tudor Ambarus wrote: > Hi, Arnd, > > On 07/09/2018 06:57 PM, Arnd Bergmann wrote: >> + nc->ebi_csa_offs = (uintptr_t)match->data; > > I guess we should declare ebi_csa_offs as size_t, right? Yes, that would make sense, though it doesn't change the behavior. Arnd
Re: [PATCH 2/3] mtd: atmel nand: fix build warning on 64-bit
On Fri, Jul 13, 2018 at 11:56 AM, Tudor Ambarus wrote: > Hi, Arnd, > > On 07/09/2018 06:57 PM, Arnd Bergmann wrote: >> + nc->ebi_csa_offs = (uintptr_t)match->data; > > I guess we should declare ebi_csa_offs as size_t, right? Yes, that would make sense, though it doesn't change the behavior. Arnd
[PATCH] fs: Add to super_blocks list after SB_BORN is set.
More simple version. Is this assumption correct?
>From 52f10183f2b921cd946dd4c83d9b1d99bc48914e Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 13 Jul 2018 12:15:54 +0900
Subject: [PATCH] fs: Add to super_blocks list after SB_BORN is set.
syzbot is reporting hung tasks at iterate_supers() [1]. This is because
iterate_supers() is calling down_read(>s_umount) on all superblocks
found by traversing super_blocks list while sget_userns() adds "newly
created superblock to super_blocks list with ->s_umount held by
alloc_super() for write" before "mount_fs() sets SB_BORN flag after
returning from type->mount()".
If type->mount() took long time after returning from sget() for some
reason, e.g. sync() request will be blocked on !SB_BORN superblocks.
Also, since security_sb_kern_mount() which is called after SB_BORN is
set might involve GFP_KERNEL memory allocation, we can't guarantee that
up_write(>s_umount) is called as soon as SB_BORN was set.
Therefore, this patch makes sure that newly created superblock is added
to super_blocks list immediately before calling up_write(>s_umount).
[1]
https://syzkaller.appspot.com/bug?id=3c0c173ff55822aacb81ce7ae27a6676fba29a5c
Signed-off-by: Tetsuo Handa
---
fs/super.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/super.c b/fs/super.c
index 50728d9..8b2c8cc 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -236,6 +236,7 @@ static struct super_block *alloc_super(struct
file_system_type *type, int flags,
s->s_flags = flags;
if (s->s_user_ns != _user_ns)
s->s_iflags |= SB_I_NODEV;
+ INIT_LIST_HEAD(>s_list);
INIT_HLIST_NODE(>s_instances);
INIT_HLIST_BL_HEAD(>s_roots);
mutex_init(>s_sync_lock);
@@ -527,8 +528,6 @@ struct super_block *sget_userns(struct file_system_type
*type,
}
s->s_type = type;
strlcpy(s->s_id, type->name, sizeof(s->s_id));
- list_add_tail(>s_list, _blocks);
- hlist_add_head(>s_instances, >fs_supers);
spin_unlock(_lock);
get_filesystem(type);
register_shrinker_prepared(>s_shrink);
@@ -1305,6 +1304,12 @@ mount_fs(struct file_system_type *type, int flags, const
char *name, void *data)
WARN((sb->s_maxbytes < 0), "%s set sb->s_maxbytes to "
"negative value (%lld)\n", type->name, sb->s_maxbytes);
+ if (list_empty(>s_list)) {
+ spin_lock(_lock);
+ list_add_tail(>s_list, _blocks);
+ hlist_add_head(>s_instances, >fs_supers);
+ spin_unlock(_lock);
+ }
up_write(>s_umount);
free_secdata(secdata);
return root;
--
2.7.4
[PATCH] fs: Add to super_blocks list after SB_BORN is set.
More simple version. Is this assumption correct?
>From 52f10183f2b921cd946dd4c83d9b1d99bc48914e Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 13 Jul 2018 12:15:54 +0900
Subject: [PATCH] fs: Add to super_blocks list after SB_BORN is set.
syzbot is reporting hung tasks at iterate_supers() [1]. This is because
iterate_supers() is calling down_read(>s_umount) on all superblocks
found by traversing super_blocks list while sget_userns() adds "newly
created superblock to super_blocks list with ->s_umount held by
alloc_super() for write" before "mount_fs() sets SB_BORN flag after
returning from type->mount()".
If type->mount() took long time after returning from sget() for some
reason, e.g. sync() request will be blocked on !SB_BORN superblocks.
Also, since security_sb_kern_mount() which is called after SB_BORN is
set might involve GFP_KERNEL memory allocation, we can't guarantee that
up_write(>s_umount) is called as soon as SB_BORN was set.
Therefore, this patch makes sure that newly created superblock is added
to super_blocks list immediately before calling up_write(>s_umount).
[1]
https://syzkaller.appspot.com/bug?id=3c0c173ff55822aacb81ce7ae27a6676fba29a5c
Signed-off-by: Tetsuo Handa
---
fs/super.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/super.c b/fs/super.c
index 50728d9..8b2c8cc 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -236,6 +236,7 @@ static struct super_block *alloc_super(struct
file_system_type *type, int flags,
s->s_flags = flags;
if (s->s_user_ns != _user_ns)
s->s_iflags |= SB_I_NODEV;
+ INIT_LIST_HEAD(>s_list);
INIT_HLIST_NODE(>s_instances);
INIT_HLIST_BL_HEAD(>s_roots);
mutex_init(>s_sync_lock);
@@ -527,8 +528,6 @@ struct super_block *sget_userns(struct file_system_type
*type,
}
s->s_type = type;
strlcpy(s->s_id, type->name, sizeof(s->s_id));
- list_add_tail(>s_list, _blocks);
- hlist_add_head(>s_instances, >fs_supers);
spin_unlock(_lock);
get_filesystem(type);
register_shrinker_prepared(>s_shrink);
@@ -1305,6 +1304,12 @@ mount_fs(struct file_system_type *type, int flags, const
char *name, void *data)
WARN((sb->s_maxbytes < 0), "%s set sb->s_maxbytes to "
"negative value (%lld)\n", type->name, sb->s_maxbytes);
+ if (list_empty(>s_list)) {
+ spin_lock(_lock);
+ list_add_tail(>s_list, _blocks);
+ hlist_add_head(>s_instances, >fs_supers);
+ spin_unlock(_lock);
+ }
up_write(>s_umount);
free_secdata(secdata);
return root;
--
2.7.4
RE: [bug] kpti, perf_event, bts: sporadic truncated trace
Hello Hugh, > A little "optimization" crept into alloc_bts_buffer() along the way, which now > places bts_interrupt_threshold not on a record boundary. > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This > address must point to an offset from the BTS buffer base that is a multiple > of the > BTS record size." > > Please give the patch below a try, and let us know if it helps (if it does > not, then I > think we'll need perfier expertise than I can give). > > Hugh > > --- 4.18-rc4/arch/x86/events/intel/ds.c 2018-06-03 14:15:21.0 > -0700 > +++ linux/arch/x86/events/intel/ds.c 2018-07-12 17:38:28.471378616 -0700 > @@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu) > ds->bts_buffer_base = (unsigned long) cea; > ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL); > ds->bts_index = ds->bts_buffer_base; > - max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE); > - ds->bts_absolute_maximum = ds->bts_buffer_base + max; > - ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16); > + max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE; > + ds->bts_absolute_maximum = ds->bts_buffer_base + > + max * BTS_RECORD_SIZE; > + ds->bts_interrupt_threshold = ds->bts_absolute_maximum - > + (max / 16) * BTS_RECORD_SIZE; > return 0; > } > Your patch fixes it. Will you send it to the list for inclusion? I'd appreciate if it could also be backported to 4.15, 4.16, and 4.17. Thanks, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
RE: [bug] kpti, perf_event, bts: sporadic truncated trace
Hello Hugh, > A little "optimization" crept into alloc_bts_buffer() along the way, which now > places bts_interrupt_threshold not on a record boundary. > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This > address must point to an offset from the BTS buffer base that is a multiple > of the > BTS record size." > > Please give the patch below a try, and let us know if it helps (if it does > not, then I > think we'll need perfier expertise than I can give). > > Hugh > > --- 4.18-rc4/arch/x86/events/intel/ds.c 2018-06-03 14:15:21.0 > -0700 > +++ linux/arch/x86/events/intel/ds.c 2018-07-12 17:38:28.471378616 -0700 > @@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu) > ds->bts_buffer_base = (unsigned long) cea; > ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL); > ds->bts_index = ds->bts_buffer_base; > - max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE); > - ds->bts_absolute_maximum = ds->bts_buffer_base + max; > - ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16); > + max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE; > + ds->bts_absolute_maximum = ds->bts_buffer_base + > + max * BTS_RECORD_SIZE; > + ds->bts_interrupt_threshold = ds->bts_absolute_maximum - > + (max / 16) * BTS_RECORD_SIZE; > return 0; > } > Your patch fixes it. Will you send it to the list for inclusion? I'd appreciate if it could also be backported to 4.15, 4.16, and 4.17. Thanks, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Re: [PATCH v10 5/6] spi: at91-usart: add driver for at91-usart as spi
On 13/07/2018 12:56:22+0300, Radu Pirea wrote: > > > On 07/10/2018 09:15 PM, Mark Brown wrote: > > On Mon, Jun 25, 2018 at 08:22:29PM +0300, Radu Pirea wrote: > > > > This is mostly good, just a couple of small things: > > > > > +config SPI_AT91_USART > > > + tristate "Atmel USART Controller SPI driver" > > > + depends on HAS_DMA > > > + depends on (ARCH_AT91 || COMPILE_TEST) > > > + select MFD_AT91_USART > > > > Why is this selecting rather than depending on the MFD like we normally > > do? > > > > Hi Mark, > > If I add depends instead of select, current defconfigs will be broken and > the proper driver will not be selected. Like this, there is no required > change in any defconfig. Selecting the serial or spi driver from menuconfig > makes the MFD completely transparent. I would say that this is true for the USART part but the SPI part can use a depends on as it didn't exist before. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v10 5/6] spi: at91-usart: add driver for at91-usart as spi
On 13/07/2018 12:56:22+0300, Radu Pirea wrote: > > > On 07/10/2018 09:15 PM, Mark Brown wrote: > > On Mon, Jun 25, 2018 at 08:22:29PM +0300, Radu Pirea wrote: > > > > This is mostly good, just a couple of small things: > > > > > +config SPI_AT91_USART > > > + tristate "Atmel USART Controller SPI driver" > > > + depends on HAS_DMA > > > + depends on (ARCH_AT91 || COMPILE_TEST) > > > + select MFD_AT91_USART > > > > Why is this selecting rather than depending on the MFD like we normally > > do? > > > > Hi Mark, > > If I add depends instead of select, current defconfigs will be broken and > the proper driver will not be selected. Like this, there is no required > change in any defconfig. Selecting the serial or spi driver from menuconfig > makes the MFD completely transparent. I would say that this is true for the USART part but the SPI part can use a depends on as it didn't exist before. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH 05/39] x86/entry/32: Unshare NMI return path
On Thu, Jul 12, 2018 at 01:53:19PM -0700, Andy Lutomirski wrote: > > On Jul 11, 2018, at 4:29 AM, Joerg Roedel wrote: > > NMI will no longer use most of the shared return path, > > because NMI needs special handling when the CR3 switches for > > PTI are added. > > Why? What would go wrong? > > How many return-to-usermode paths will we have? 64-bit has only one. In the non-NMI return path we make a decission on whether we return to user-space or kernel-space and do different things based on that. For example, when returning to user-space we call prepare_exit_to_usermode(). With the CR3 switches added later we also unconditionally switch to user-cr3 when we are in the return-to-user path. The NMI return path does not need any of that, as it doesn't call prepare_exit_to_usermode() even when it returns to user-space. It doesn't even care where it returns to. It just remembers stack and cr3 on entry in callee-safed registers and restores that on exit. This works in the NMI path because it is pretty simple and doesn't do any fancy work on exit. While working on a previous version I also tried to store stack and cr3 in a callee-safed register and restore that on exit again, but it didn't work, most likley because something in-between overwrote one of the registers. I also found it a bit fragile to make make two registers untouchable in the whole entry-code. It doesn't make future changes simpler or more robust. So long story short, the NMI path can be simpler wrt. stack and cr3 handling as the other entry/exit points, and therefore it is handled differently. Regards, Joerg
Re: [PATCH 05/39] x86/entry/32: Unshare NMI return path
On Thu, Jul 12, 2018 at 01:53:19PM -0700, Andy Lutomirski wrote: > > On Jul 11, 2018, at 4:29 AM, Joerg Roedel wrote: > > NMI will no longer use most of the shared return path, > > because NMI needs special handling when the CR3 switches for > > PTI are added. > > Why? What would go wrong? > > How many return-to-usermode paths will we have? 64-bit has only one. In the non-NMI return path we make a decission on whether we return to user-space or kernel-space and do different things based on that. For example, when returning to user-space we call prepare_exit_to_usermode(). With the CR3 switches added later we also unconditionally switch to user-cr3 when we are in the return-to-user path. The NMI return path does not need any of that, as it doesn't call prepare_exit_to_usermode() even when it returns to user-space. It doesn't even care where it returns to. It just remembers stack and cr3 on entry in callee-safed registers and restores that on exit. This works in the NMI path because it is pretty simple and doesn't do any fancy work on exit. While working on a previous version I also tried to store stack and cr3 in a callee-safed register and restore that on exit again, but it didn't work, most likley because something in-between overwrote one of the registers. I also found it a bit fragile to make make two registers untouchable in the whole entry-code. It doesn't make future changes simpler or more robust. So long story short, the NMI path can be simpler wrt. stack and cr3 handling as the other entry/exit points, and therefore it is handled differently. Regards, Joerg
[PATCH] soc: imx6qp: Use GENPD_FLAG_ALWAYS_ON for PU errata
This is functionally identical but simpler and slightly faster.
The PU domain is turned on at boot time and never turned off. In the
current implementation the pm core will repeatedly call power_off when
the domain is unused and get -EBUSY back. If the domain is marked as
"always on" instead the pm core won't even attempt to turn it off.
In theory on 6qp it is safe to turn PU off in suspend, however that is
best accomplished with a new core flag.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
Previous discussion:
* https://lkml.org/lkml/2018/7/11/431
* https://lkml.org/lkml/2018/7/10/103
Attempt at turning PU off in suspend:
* https://lkml.org/lkml/2018/7/6/698
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index faf13a0b85d6..f31978e5af20 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -45,11 +45,10 @@ struct imx_pm_domain {
struct clk *clk[GPC_CLK_MAX];
int num_clks;
unsigned int reg_offs;
signed char cntr_pdn_bit;
unsigned int ipg_rate_mhz;
- unsigned int flags;
};
static inline struct imx_pm_domain *
to_imx_pm_domain(struct generic_pm_domain *genpd)
{
@@ -60,13 +59,10 @@ static int imx6_pm_domain_power_off(struct
generic_pm_domain *genpd)
{
struct imx_pm_domain *pd = to_imx_pm_domain(genpd);
int iso, iso2sw;
u32 val;
- if (pd->flags & PGC_DOMAIN_FLAG_NO_PD)
- return -EBUSY;
-
/* Read ISO and ISO2SW power down delays */
regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, );
iso = val & 0x3f;
iso2sw = (val >> 8) & 0x3f;
@@ -419,12 +415,12 @@ static int imx_gpc_probe(struct platform_device *pdev)
return ret;
}
/* Disable PU power down in normal operation if ERR009619 is present */
if (of_id_data->err009619_present)
- imx_gpc_domains[GPC_PGC_DOMAIN_PU].flags |=
- PGC_DOMAIN_FLAG_NO_PD;
+ imx_gpc_domains[GPC_PGC_DOMAIN_PU].base.flags |=
+ GENPD_FLAG_ALWAYS_ON;
/* Keep DISP always on if ERR006287 is present */
if (of_id_data->err006287_present)
imx_gpc_domains[GPC_PGC_DOMAIN_DISPLAY].base.flags |=
GENPD_FLAG_ALWAYS_ON;
--
2.17.1
[PATCH] soc: imx6qp: Use GENPD_FLAG_ALWAYS_ON for PU errata
This is functionally identical but simpler and slightly faster.
The PU domain is turned on at boot time and never turned off. In the
current implementation the pm core will repeatedly call power_off when
the domain is unused and get -EBUSY back. If the domain is marked as
"always on" instead the pm core won't even attempt to turn it off.
In theory on 6qp it is safe to turn PU off in suspend, however that is
best accomplished with a new core flag.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
Previous discussion:
* https://lkml.org/lkml/2018/7/11/431
* https://lkml.org/lkml/2018/7/10/103
Attempt at turning PU off in suspend:
* https://lkml.org/lkml/2018/7/6/698
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index faf13a0b85d6..f31978e5af20 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -45,11 +45,10 @@ struct imx_pm_domain {
struct clk *clk[GPC_CLK_MAX];
int num_clks;
unsigned int reg_offs;
signed char cntr_pdn_bit;
unsigned int ipg_rate_mhz;
- unsigned int flags;
};
static inline struct imx_pm_domain *
to_imx_pm_domain(struct generic_pm_domain *genpd)
{
@@ -60,13 +59,10 @@ static int imx6_pm_domain_power_off(struct
generic_pm_domain *genpd)
{
struct imx_pm_domain *pd = to_imx_pm_domain(genpd);
int iso, iso2sw;
u32 val;
- if (pd->flags & PGC_DOMAIN_FLAG_NO_PD)
- return -EBUSY;
-
/* Read ISO and ISO2SW power down delays */
regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, );
iso = val & 0x3f;
iso2sw = (val >> 8) & 0x3f;
@@ -419,12 +415,12 @@ static int imx_gpc_probe(struct platform_device *pdev)
return ret;
}
/* Disable PU power down in normal operation if ERR009619 is present */
if (of_id_data->err009619_present)
- imx_gpc_domains[GPC_PGC_DOMAIN_PU].flags |=
- PGC_DOMAIN_FLAG_NO_PD;
+ imx_gpc_domains[GPC_PGC_DOMAIN_PU].base.flags |=
+ GENPD_FLAG_ALWAYS_ON;
/* Keep DISP always on if ERR006287 is present */
if (of_id_data->err006287_present)
imx_gpc_domains[GPC_PGC_DOMAIN_DISPLAY].base.flags |=
GENPD_FLAG_ALWAYS_ON;
--
2.17.1
Re: [PATCH] locking/rwsem: Take read lock immediate if empty queue with no writer
On Tue, Jul 10, 2018 at 02:31:30PM -0400, Waiman Long wrote:
> It was found that a constant stream of readers might cause the count to
> go negative most of the time after an initial trigger by a writer even
> if no writer was present afterward. As a result, most of the readers
> would have to go through the slowpath reducing their performance.
>
> To avoid that from happening, an additional check is added to detect
> the special case that the reader in the critical section is the only
> one in the wait queue and no writer is present. When that happens, it
> can just have the lock and return immediately without further action.
> Other incoming readers won't see a waiter is present and be forced
> into the slowpath.
>
> After the list_empty() calls, the CPU should have the lock cacheline
> anyway, so an additional semaphore count check shouldn't have any
> performance impact.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
This looks ok to me, but it would be nice to include some performance
figures in the commit log. Do you have any? Phrases such as "shouldn't have
any performance impact" and "probably generate better code" don't fill me
with good feelings ;)
Will
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 3064c50..ef8a5f3 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -233,8 +233,22 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem,
> waiter.type = RWSEM_WAITING_FOR_READ;
>
> raw_spin_lock_irq(>wait_lock);
> - if (list_empty(>wait_list))
> + if (list_empty(>wait_list)) {
> + /*
> + * In the unlikely event that the task is the only one in
> + * the wait queue and a writer isn't present, it can have
> + * the lock and return immediately without going through
> + * the remaining slowpath code.
> + *
> + * Count won't be 0, but allowing it will probably generate
> + * better code.
> + */
> + if (unlikely(atomic_long_read(>count) >= 0)) {
> + raw_spin_unlock_irq(>wait_lock);
> + return sem;
> + }
> adjustment += RWSEM_WAITING_BIAS;
> + }
> list_add_tail(, >wait_list);
>
> /* we're now waiting on the lock, but no longer actively locking */
> --
> 1.8.3.1
>
Re: [PATCH] locking/rwsem: Take read lock immediate if empty queue with no writer
On Tue, Jul 10, 2018 at 02:31:30PM -0400, Waiman Long wrote:
> It was found that a constant stream of readers might cause the count to
> go negative most of the time after an initial trigger by a writer even
> if no writer was present afterward. As a result, most of the readers
> would have to go through the slowpath reducing their performance.
>
> To avoid that from happening, an additional check is added to detect
> the special case that the reader in the critical section is the only
> one in the wait queue and no writer is present. When that happens, it
> can just have the lock and return immediately without further action.
> Other incoming readers won't see a waiter is present and be forced
> into the slowpath.
>
> After the list_empty() calls, the CPU should have the lock cacheline
> anyway, so an additional semaphore count check shouldn't have any
> performance impact.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
This looks ok to me, but it would be nice to include some performance
figures in the commit log. Do you have any? Phrases such as "shouldn't have
any performance impact" and "probably generate better code" don't fill me
with good feelings ;)
Will
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 3064c50..ef8a5f3 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -233,8 +233,22 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem,
> waiter.type = RWSEM_WAITING_FOR_READ;
>
> raw_spin_lock_irq(>wait_lock);
> - if (list_empty(>wait_list))
> + if (list_empty(>wait_list)) {
> + /*
> + * In the unlikely event that the task is the only one in
> + * the wait queue and a writer isn't present, it can have
> + * the lock and return immediately without going through
> + * the remaining slowpath code.
> + *
> + * Count won't be 0, but allowing it will probably generate
> + * better code.
> + */
> + if (unlikely(atomic_long_read(>count) >= 0)) {
> + raw_spin_unlock_irq(>wait_lock);
> + return sem;
> + }
> adjustment += RWSEM_WAITING_BIAS;
> + }
> list_add_tail(, >wait_list);
>
> /* we're now waiting on the lock, but no longer actively locking */
> --
> 1.8.3.1
>
Re: [RESEND PATCH] tee: add kernel internal client interface
On Fri, 13 Jul 2018 at 14:54, Jens Wiklander wrote:
>
> [+Sumit]
>
> On Mon, Jul 09, 2018 at 08:15:49AM +0200, Jens Wiklander wrote:
> > Adds a kernel internal TEE client interface to be used by other drivers.
> >
> > Signed-off-by: Jens Wiklander
> > ---
Thanks Jens for this patch. I have reviewed and tested this patch on
Developerbox [1]. Following is brief description of my test-case:
Developerbox doesn't have support for hardware based TRNG. But it does
have 7 on-chip thermal sensors accessible from Secure world only. So I
wrote OP-TEE static TA to collect Entropy using thermal noise from
these sensors.
After using the interface provided by this patch, I am able to write
"hw_random" char driver for Developerbox to get Entropy from OP-TEE
static TA which could be further used by user-space daemon (rngd).
Reviewed-by: Sumit Garg
Tested-by: Sumit Garg
[1] https://www.96boards.org/product/developerbox/
-Sumit
> > drivers/tee/tee_core.c | 113 +---
> > include/linux/tee_drv.h | 73 ++
> > 2 files changed, 179 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > index dd46b758852a..7b2bb4c50058 100644
> > --- a/drivers/tee/tee_core.c
> > +++ b/drivers/tee/tee_core.c
> > @@ -38,15 +38,13 @@ static DEFINE_SPINLOCK(driver_lock);
> > static struct class *tee_class;
> > static dev_t tee_devt;
> >
> > -static int tee_open(struct inode *inode, struct file *filp)
> > +static struct tee_context *teedev_open(struct tee_device *teedev)
> > {
> > int rc;
> > - struct tee_device *teedev;
> > struct tee_context *ctx;
> >
> > - teedev = container_of(inode->i_cdev, struct tee_device, cdev);
> > if (!tee_device_get(teedev))
> > - return -EINVAL;
> > + return ERR_PTR(-EINVAL);
> >
> > ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> > if (!ctx) {
> > @@ -57,16 +55,16 @@ static int tee_open(struct inode *inode, struct file
> > *filp)
> > kref_init(>refcount);
> > ctx->teedev = teedev;
> > INIT_LIST_HEAD(>list_shm);
> > - filp->private_data = ctx;
> > rc = teedev->desc->ops->open(ctx);
> > if (rc)
> > goto err;
> >
> > - return 0;
> > + return ctx;
> > err:
> > kfree(ctx);
> > tee_device_put(teedev);
> > - return rc;
> > + return ERR_PTR(rc);
> > +
> > }
> >
> > void teedev_ctx_get(struct tee_context *ctx)
> > @@ -100,6 +98,18 @@ static void teedev_close_context(struct tee_context
> > *ctx)
> > teedev_ctx_put(ctx);
> > }
> >
> > +static int tee_open(struct inode *inode, struct file *filp)
> > +{
> > + struct tee_context *ctx;
> > +
> > + ctx = teedev_open(container_of(inode->i_cdev, struct tee_device,
> > cdev));
> > + if (IS_ERR(ctx))
> > + return PTR_ERR(ctx);
> > +
> > + filp->private_data = ctx;
> > + return 0;
> > +}
> > +
> > static int tee_release(struct inode *inode, struct file *filp)
> > {
> > teedev_close_context(filp->private_data);
> > @@ -928,6 +938,95 @@ void *tee_get_drvdata(struct tee_device *teedev)
> > }
> > EXPORT_SYMBOL_GPL(tee_get_drvdata);
> >
> > +struct match_dev_data {
> > + struct tee_ioctl_version_data *vers;
> > + const void *data;
> > + int (*match)(struct tee_ioctl_version_data *, const void *);
> > +};
> > +
> > +static int match_dev(struct device *dev, const void *data)
> > +{
> > + const struct match_dev_data *match_data = data;
> > + struct tee_device *teedev = container_of(dev, struct tee_device, dev);
> > +
> > + teedev->desc->ops->get_version(teedev, match_data->vers);
> > + return match_data->match(match_data->vers, match_data->data);
> > +}
> > +
> > +struct tee_context *
> > +tee_client_open_context(struct tee_context *start,
> > + int (*match)(struct tee_ioctl_version_data *,
> > + const void *),
> > + const void *data, struct tee_ioctl_version_data *vers)
> > +{
> > + struct device *dev = NULL;
> > + struct device *put_dev = NULL;
> > + struct tee_context *ctx = NULL;
> > + struct tee_ioctl_version_data v;
> > + struct match_dev_data match_data = { vers ? vers : , data, match };
> > +
> > + if (start)
> > + dev = >teedev->dev;
> > +
> > + do {
> > + dev = class_find_device(tee_class, dev, _data,
> > match_dev);
> > + if (!dev) {
> > + ctx = ERR_PTR(-ENOENT);
> > + break;
> > + }
> > +
> > + put_device(put_dev);
> > + put_dev = dev;
> > +
> > + ctx = teedev_open(container_of(dev, struct tee_device, dev));
> > + } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM);
> > +
> > + put_device(put_dev);
> > + return ctx;
> > +}
> > +EXPORT_SYMBOL_GPL(tee_client_open_context);
> > +
> > +void tee_client_close_context(struct
Re: [RESEND PATCH] tee: add kernel internal client interface
On Fri, 13 Jul 2018 at 14:54, Jens Wiklander wrote:
>
> [+Sumit]
>
> On Mon, Jul 09, 2018 at 08:15:49AM +0200, Jens Wiklander wrote:
> > Adds a kernel internal TEE client interface to be used by other drivers.
> >
> > Signed-off-by: Jens Wiklander
> > ---
Thanks Jens for this patch. I have reviewed and tested this patch on
Developerbox [1]. Following is brief description of my test-case:
Developerbox doesn't have support for hardware based TRNG. But it does
have 7 on-chip thermal sensors accessible from Secure world only. So I
wrote OP-TEE static TA to collect Entropy using thermal noise from
these sensors.
After using the interface provided by this patch, I am able to write
"hw_random" char driver for Developerbox to get Entropy from OP-TEE
static TA which could be further used by user-space daemon (rngd).
Reviewed-by: Sumit Garg
Tested-by: Sumit Garg
[1] https://www.96boards.org/product/developerbox/
-Sumit
> > drivers/tee/tee_core.c | 113 +---
> > include/linux/tee_drv.h | 73 ++
> > 2 files changed, 179 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > index dd46b758852a..7b2bb4c50058 100644
> > --- a/drivers/tee/tee_core.c
> > +++ b/drivers/tee/tee_core.c
> > @@ -38,15 +38,13 @@ static DEFINE_SPINLOCK(driver_lock);
> > static struct class *tee_class;
> > static dev_t tee_devt;
> >
> > -static int tee_open(struct inode *inode, struct file *filp)
> > +static struct tee_context *teedev_open(struct tee_device *teedev)
> > {
> > int rc;
> > - struct tee_device *teedev;
> > struct tee_context *ctx;
> >
> > - teedev = container_of(inode->i_cdev, struct tee_device, cdev);
> > if (!tee_device_get(teedev))
> > - return -EINVAL;
> > + return ERR_PTR(-EINVAL);
> >
> > ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> > if (!ctx) {
> > @@ -57,16 +55,16 @@ static int tee_open(struct inode *inode, struct file
> > *filp)
> > kref_init(>refcount);
> > ctx->teedev = teedev;
> > INIT_LIST_HEAD(>list_shm);
> > - filp->private_data = ctx;
> > rc = teedev->desc->ops->open(ctx);
> > if (rc)
> > goto err;
> >
> > - return 0;
> > + return ctx;
> > err:
> > kfree(ctx);
> > tee_device_put(teedev);
> > - return rc;
> > + return ERR_PTR(rc);
> > +
> > }
> >
> > void teedev_ctx_get(struct tee_context *ctx)
> > @@ -100,6 +98,18 @@ static void teedev_close_context(struct tee_context
> > *ctx)
> > teedev_ctx_put(ctx);
> > }
> >
> > +static int tee_open(struct inode *inode, struct file *filp)
> > +{
> > + struct tee_context *ctx;
> > +
> > + ctx = teedev_open(container_of(inode->i_cdev, struct tee_device,
> > cdev));
> > + if (IS_ERR(ctx))
> > + return PTR_ERR(ctx);
> > +
> > + filp->private_data = ctx;
> > + return 0;
> > +}
> > +
> > static int tee_release(struct inode *inode, struct file *filp)
> > {
> > teedev_close_context(filp->private_data);
> > @@ -928,6 +938,95 @@ void *tee_get_drvdata(struct tee_device *teedev)
> > }
> > EXPORT_SYMBOL_GPL(tee_get_drvdata);
> >
> > +struct match_dev_data {
> > + struct tee_ioctl_version_data *vers;
> > + const void *data;
> > + int (*match)(struct tee_ioctl_version_data *, const void *);
> > +};
> > +
> > +static int match_dev(struct device *dev, const void *data)
> > +{
> > + const struct match_dev_data *match_data = data;
> > + struct tee_device *teedev = container_of(dev, struct tee_device, dev);
> > +
> > + teedev->desc->ops->get_version(teedev, match_data->vers);
> > + return match_data->match(match_data->vers, match_data->data);
> > +}
> > +
> > +struct tee_context *
> > +tee_client_open_context(struct tee_context *start,
> > + int (*match)(struct tee_ioctl_version_data *,
> > + const void *),
> > + const void *data, struct tee_ioctl_version_data *vers)
> > +{
> > + struct device *dev = NULL;
> > + struct device *put_dev = NULL;
> > + struct tee_context *ctx = NULL;
> > + struct tee_ioctl_version_data v;
> > + struct match_dev_data match_data = { vers ? vers : , data, match };
> > +
> > + if (start)
> > + dev = >teedev->dev;
> > +
> > + do {
> > + dev = class_find_device(tee_class, dev, _data,
> > match_dev);
> > + if (!dev) {
> > + ctx = ERR_PTR(-ENOENT);
> > + break;
> > + }
> > +
> > + put_device(put_dev);
> > + put_dev = dev;
> > +
> > + ctx = teedev_open(container_of(dev, struct tee_device, dev));
> > + } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM);
> > +
> > + put_device(put_dev);
> > + return ctx;
> > +}
> > +EXPORT_SYMBOL_GPL(tee_client_open_context);
> > +
> > +void tee_client_close_context(struct
Re: [PATCH v5 0/5] sparse_init rewrite
On Thu, Jul 12, 2018 at 04:37:25PM -0400, Pavel Tatashin wrote: > Changelog: > v5 - v4 > - Fixed the issue that was reported on ppc64 when > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER is removed > - Consolidated the new buffer allocation between vmemmap > and non-vmemmap variants of sparse layout. > - Removed all review-by comments, because I had to do > significant amount of changes compared to previous version > and need another round of review. > - I also would appreciate if those who reported problems with > PPC64 could test this change. About PPC64, your patchset fixes the issue as the population gets followed by a sparse_init_one_section(). It can be seen here: Before: kernel: vmemmap_populate f000..f0004000, node 0 kernel: * f000..f001 allocated at (ptrval) kernel: vmemmap_populate f000..f0008000, node 0 kernel: * f000..f001 allocated at (ptrval) kernel: vmemmap_populate f000..f000c000, node 0 kernel: * f000..f001 allocated at (ptrval) After: kernel: vmemmap_populate f000..f0004000, node 0 kernel: * f000..f001 allocated at (ptrval) kernel: vmemmap_populate f000..f0008000, node 0 kernel: vmemmap_populate f000..f000c000, node 0 kernel: vmemmap_populate f000..f001, node 0 kernel: vmemmap_populate f001..f0014000, node 0 kernel: * f001..f002 allocated at (ptrval) As can be seen, before the patchset, we keep calling vmemmap_create_mapping() even if we populated that section already, because of vmemmap_populated() checking for SECTION_HAS_MEM_MAP. After the patchset, since each population is being followed by a call to sparse_init_one_section(), when vmemmap_populated() gets called, we have SECTION_HAS_MEM_MAP already in case the section was populated. -- Oscar Salvador SUSE L3
Re: [PATCH v5 0/5] sparse_init rewrite
On Thu, Jul 12, 2018 at 04:37:25PM -0400, Pavel Tatashin wrote: > Changelog: > v5 - v4 > - Fixed the issue that was reported on ppc64 when > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER is removed > - Consolidated the new buffer allocation between vmemmap > and non-vmemmap variants of sparse layout. > - Removed all review-by comments, because I had to do > significant amount of changes compared to previous version > and need another round of review. > - I also would appreciate if those who reported problems with > PPC64 could test this change. About PPC64, your patchset fixes the issue as the population gets followed by a sparse_init_one_section(). It can be seen here: Before: kernel: vmemmap_populate f000..f0004000, node 0 kernel: * f000..f001 allocated at (ptrval) kernel: vmemmap_populate f000..f0008000, node 0 kernel: * f000..f001 allocated at (ptrval) kernel: vmemmap_populate f000..f000c000, node 0 kernel: * f000..f001 allocated at (ptrval) After: kernel: vmemmap_populate f000..f0004000, node 0 kernel: * f000..f001 allocated at (ptrval) kernel: vmemmap_populate f000..f0008000, node 0 kernel: vmemmap_populate f000..f000c000, node 0 kernel: vmemmap_populate f000..f001, node 0 kernel: vmemmap_populate f001..f0014000, node 0 kernel: * f001..f002 allocated at (ptrval) As can be seen, before the patchset, we keep calling vmemmap_create_mapping() even if we populated that section already, because of vmemmap_populated() checking for SECTION_HAS_MEM_MAP. After the patchset, since each population is being followed by a call to sparse_init_one_section(), when vmemmap_populated() gets called, we have SECTION_HAS_MEM_MAP already in case the section was populated. -- Oscar Salvador SUSE L3
Re: [PATCH 2/3] mtd: atmel nand: fix build warning on 64-bit
Hi, Arnd, On 07/09/2018 06:57 PM, Arnd Bergmann wrote: > + nc->ebi_csa_offs = (uintptr_t)match->data; I guess we should declare ebi_csa_offs as size_t, right? Best, ta
Re: [PATCH 2/3] mtd: atmel nand: fix build warning on 64-bit
Hi, Arnd, On 07/09/2018 06:57 PM, Arnd Bergmann wrote: > + nc->ebi_csa_offs = (uintptr_t)match->data; I guess we should declare ebi_csa_offs as size_t, right? Best, ta
[PATCH RFC 5/7] mmc: sdhci-msm: Kconfig: select devfreq ondemand for sdhci-msm
SDHCI-MSM platform is using devfreq ondemand governor. Select devfreq governor for SDHCI-MSM platform. Signed-off-by: Ritesh Harjani Signed-off-by: Sayali Lokhande --- drivers/mmc/host/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 0581c19..2ba2c62 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -442,6 +442,8 @@ config MMC_SDHCI_MSM tristate "Qualcomm SDHCI Controller Support" depends on ARCH_QCOM || (ARM && COMPILE_TEST) depends on MMC_SDHCI_PLTFM + select PM_DEVFREQ + select DEVFREQ_GOV_SIMPLE_ONDEMAND select MMC_SDHCI_IO_ACCESSORS help This selects the Secure Digital Host Controller Interface (SDHCI) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC 5/7] mmc: sdhci-msm: Kconfig: select devfreq ondemand for sdhci-msm
SDHCI-MSM platform is using devfreq ondemand governor. Select devfreq governor for SDHCI-MSM platform. Signed-off-by: Ritesh Harjani Signed-off-by: Sayali Lokhande --- drivers/mmc/host/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 0581c19..2ba2c62 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -442,6 +442,8 @@ config MMC_SDHCI_MSM tristate "Qualcomm SDHCI Controller Support" depends on ARCH_QCOM || (ARM && COMPILE_TEST) depends on MMC_SDHCI_PLTFM + select PM_DEVFREQ + select DEVFREQ_GOV_SIMPLE_ONDEMAND select MMC_SDHCI_IO_ACCESSORS help This selects the Secure Digital Host Controller Interface (SDHCI) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v10 5/6] spi: at91-usart: add driver for at91-usart as spi
On 07/10/2018 09:15 PM, Mark Brown wrote: On Mon, Jun 25, 2018 at 08:22:29PM +0300, Radu Pirea wrote: This is mostly good, just a couple of small things: +config SPI_AT91_USART + tristate "Atmel USART Controller SPI driver" + depends on HAS_DMA + depends on (ARCH_AT91 || COMPILE_TEST) + select MFD_AT91_USART Why is this selecting rather than depending on the MFD like we normally do? Hi Mark, If I add depends instead of select, current defconfigs will be broken and the proper driver will not be selected. Like this, there is no required change in any defconfig. Selecting the serial or spi driver from menuconfig makes the MFD completely transparent. @@ -0,0 +1,432 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for AT91 USART Controllers as SPI + * + * Copyright (C) 2018 Microchip Technology Inc. + * Author: Radu Pirea + */ Please use C++ comments for the whole block so it looks a bit more intentional. Ok. I will change it. Otherwise Reviwed-by: Mark Brown
[PATCH RFC 7/7] mmc: core: Add a debugfs entry to set max clock rate
Limiting the max frequency supported by host controller
to a certain value can be useful for testing power consumption
at various frequencies that are supported by the host.
Note: If the card supports less than desired value then the
frequency of operation would be limited to that frequency.
Usage:
mount -t debugfs none /sys/kernel/debug
echo > /sys/kernel/debug/mmcX/max_clock
cat /sys/kernel/debug/mmcX/max_clock
Signed-off-by: Sujit Reddy Thumma
Signed-off-by: Sayali Lokhande
---
drivers/mmc/core/debugfs.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 630ca8e..26499f7 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -262,6 +262,46 @@ static int mmc_scale_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(mmc_scale_fops, mmc_scale_get, mmc_scale_set,
"%llu\n");
+static int mmc_max_clock_get(void *data, u64 *val)
+{
+ struct mmc_host *host = data;
+
+ if (!host)
+ return -EINVAL;
+
+ *val = host->f_max;
+
+ return 0;
+}
+
+static int mmc_max_clock_set(void *data, u64 val)
+{
+ struct mmc_host *host = data;
+ int err = -EINVAL;
+ unsigned long freq = val;
+ unsigned int old_freq;
+
+ if (!host || (val < host->f_min))
+ goto out;
+
+ mmc_claim_host(host);
+ if (host->bus_ops && host->bus_ops->change_bus_speed) {
+ old_freq = host->f_max;
+ host->f_max = freq;
+
+ err = host->bus_ops->change_bus_speed(host, );
+
+ if (err)
+ host->f_max = old_freq;
+ }
+ mmc_release_host(host);
+out:
+ return err;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(mmc_max_clock_fops, mmc_max_clock_get,
+ mmc_max_clock_set, "%llu\n");
+
void mmc_add_host_debugfs(struct mmc_host *host)
{
struct dentry *root;
@@ -290,6 +330,10 @@ void mmc_add_host_debugfs(struct mmc_host *host)
_clock_fops))
goto err_node;
+ if (!debugfs_create_file("max_clock", 0600, root, host,
+ _max_clock_fops))
+ goto err_node;
+
if (!debugfs_create_file("scale", 0600, root, host,
_scale_fops))
goto err_node;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v10 5/6] spi: at91-usart: add driver for at91-usart as spi
On 07/10/2018 09:15 PM, Mark Brown wrote: On Mon, Jun 25, 2018 at 08:22:29PM +0300, Radu Pirea wrote: This is mostly good, just a couple of small things: +config SPI_AT91_USART + tristate "Atmel USART Controller SPI driver" + depends on HAS_DMA + depends on (ARCH_AT91 || COMPILE_TEST) + select MFD_AT91_USART Why is this selecting rather than depending on the MFD like we normally do? Hi Mark, If I add depends instead of select, current defconfigs will be broken and the proper driver will not be selected. Like this, there is no required change in any defconfig. Selecting the serial or spi driver from menuconfig makes the MFD completely transparent. @@ -0,0 +1,432 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for AT91 USART Controllers as SPI + * + * Copyright (C) 2018 Microchip Technology Inc. + * Author: Radu Pirea + */ Please use C++ comments for the whole block so it looks a bit more intentional. Ok. I will change it. Otherwise Reviwed-by: Mark Brown
[PATCH RFC 7/7] mmc: core: Add a debugfs entry to set max clock rate
Limiting the max frequency supported by host controller
to a certain value can be useful for testing power consumption
at various frequencies that are supported by the host.
Note: If the card supports less than desired value then the
frequency of operation would be limited to that frequency.
Usage:
mount -t debugfs none /sys/kernel/debug
echo > /sys/kernel/debug/mmcX/max_clock
cat /sys/kernel/debug/mmcX/max_clock
Signed-off-by: Sujit Reddy Thumma
Signed-off-by: Sayali Lokhande
---
drivers/mmc/core/debugfs.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 630ca8e..26499f7 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -262,6 +262,46 @@ static int mmc_scale_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(mmc_scale_fops, mmc_scale_get, mmc_scale_set,
"%llu\n");
+static int mmc_max_clock_get(void *data, u64 *val)
+{
+ struct mmc_host *host = data;
+
+ if (!host)
+ return -EINVAL;
+
+ *val = host->f_max;
+
+ return 0;
+}
+
+static int mmc_max_clock_set(void *data, u64 val)
+{
+ struct mmc_host *host = data;
+ int err = -EINVAL;
+ unsigned long freq = val;
+ unsigned int old_freq;
+
+ if (!host || (val < host->f_min))
+ goto out;
+
+ mmc_claim_host(host);
+ if (host->bus_ops && host->bus_ops->change_bus_speed) {
+ old_freq = host->f_max;
+ host->f_max = freq;
+
+ err = host->bus_ops->change_bus_speed(host, );
+
+ if (err)
+ host->f_max = old_freq;
+ }
+ mmc_release_host(host);
+out:
+ return err;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(mmc_max_clock_fops, mmc_max_clock_get,
+ mmc_max_clock_set, "%llu\n");
+
void mmc_add_host_debugfs(struct mmc_host *host)
{
struct dentry *root;
@@ -290,6 +330,10 @@ void mmc_add_host_debugfs(struct mmc_host *host)
_clock_fops))
goto err_node;
+ if (!debugfs_create_file("max_clock", 0600, root, host,
+ _max_clock_fops))
+ goto err_node;
+
if (!debugfs_create_file("scale", 0600, root, host,
_scale_fops))
goto err_node;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC 4/7] mmc: core: add support for devfreq suspend/resume
This change adds support for devfreq suspend/resume
to be called on each system suspend/resume, runtime
suspend/resume, power restore.
Signed-off-by: Talel Shenhar
Signed-off-by: Subhash Jadavani
Signed-off-by: Sayali Lokhande
---
drivers/mmc/core/core.c | 112
drivers/mmc/core/core.h | 2 +
drivers/mmc/core/host.c | 8 +++-
drivers/mmc/core/mmc.c | 27
drivers/mmc/core/sd.c | 13 ++
5 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0eaee42..49103cf 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -618,6 +618,111 @@ int mmc_init_clk_scaling(struct mmc_host *host)
EXPORT_SYMBOL(mmc_init_clk_scaling);
/**
+ * mmc_suspend_clk_scaling() - suspend clock scaling
+ * @host: pointer to mmc host structure
+ *
+ * This API will suspend devfreq feature for the specific host.
+ * The statistics collected by mmc will be cleared.
+ * This function is intended to be called by the pm callbacks
+ * (e.g. runtime_suspend, suspend) of the mmc device
+ */
+int mmc_suspend_clk_scaling(struct mmc_host *host)
+{
+ int err;
+
+ if (!host) {
+ WARN(1, "bad host parameter\n");
+ return -EINVAL;
+ }
+
+ if (!mmc_can_scale_clk(host) || !host->clk_scaling.enable)
+ return 0;
+
+ if (!host->clk_scaling.devfreq) {
+ pr_err("%s: %s: no devfreq is assosiated with this device\n",
+ mmc_hostname(host), __func__);
+ return -EPERM;
+ }
+
+ atomic_inc(>clk_scaling.devfreq_abort);
+ wake_up(>wq);
+ err = devfreq_suspend_device(host->clk_scaling.devfreq);
+ if (err) {
+ pr_err("%s: %s: failed to suspend devfreq\n",
+ mmc_hostname(host), __func__);
+ return err;
+ }
+ host->clk_scaling.enable = false;
+
+ host->clk_scaling.total_busy_time_us = 0;
+
+ pr_debug("%s: devfreq was removed\n", mmc_hostname(host));
+
+ return 0;
+}
+EXPORT_SYMBOL(mmc_suspend_clk_scaling);
+
+/**
+ * mmc_resume_clk_scaling() - resume clock scaling
+ * @host: pointer to mmc host structure
+ *
+ * This API will resume devfreq feature for the specific host.
+ * This API is intended to be called by the pm callbacks
+ * (e.g. runtime_suspend, suspend) of the mmc device
+ */
+int mmc_resume_clk_scaling(struct mmc_host *host)
+{
+ int err = 0;
+ u32 max_clk_idx = 0;
+ u32 devfreq_max_clk = 0;
+ u32 devfreq_min_clk = 0;
+
+ if (!host) {
+ WARN(1, "bad host parameter\n");
+ return -EINVAL;
+ }
+
+ if (!mmc_can_scale_clk(host))
+ return 0;
+
+ /*
+* If clock scaling is already exited when resume is called, like
+* during mmc shutdown, it is not an error and should not fail the
+* API calling this.
+*/
+ if (!host->clk_scaling.devfreq) {
+ pr_warn("%s: %s: no devfreq is assosiated with this device\n",
+ mmc_hostname(host), __func__);
+ return 0;
+ }
+
+ atomic_set(>clk_scaling.devfreq_abort, 0);
+
+ max_clk_idx = host->clk_scaling.freq_table_sz - 1;
+ devfreq_max_clk = host->clk_scaling.freq_table[max_clk_idx];
+ devfreq_min_clk = host->clk_scaling.freq_table[0];
+
+ host->clk_scaling.curr_freq = devfreq_max_clk;
+ if (host->ios.clock < host->clk_scaling.freq_table[max_clk_idx])
+ host->clk_scaling.curr_freq = devfreq_min_clk;
+
+ host->clk_scaling.clk_scaling_in_progress = false;
+ host->clk_scaling.need_freq_change = false;
+
+ err = devfreq_resume_device(host->clk_scaling.devfreq);
+ if (err) {
+ pr_err("%s: %s: failed to resume devfreq (%d)\n",
+ mmc_hostname(host), __func__, err);
+ } else {
+ host->clk_scaling.enable = true;
+ pr_debug("%s: devfreq resumed\n", mmc_hostname(host));
+ }
+
+ return err;
+}
+EXPORT_SYMBOL(mmc_resume_clk_scaling);
+
+/**
* mmc_exit_devfreq_clk_scaling() - Disable clock scaling
* @host: pointer to mmc host structure
*
@@ -642,6 +747,13 @@ int mmc_exit_clk_scaling(struct mmc_host *host)
return -EPERM;
}
+ err = mmc_suspend_clk_scaling(host);
+ if (err) {
+ pr_err("%s: %s: fail to suspend clock scaling (%d)\n",
+ mmc_hostname(host), __func__, err);
+ return err;
+ }
+
err = devfreq_remove_device(host->clk_scaling.devfreq);
if (err) {
pr_err("%s: remove devfreq failed (%d)\n",
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index fc0a9b7..249c20d 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -97,6 +97,8 @@ static inline void mmc_delay(unsigned int
[PATCH RFC 6/7] mmc: sdhci-msm: Enable clock scaling property
This change enables clock scaling capability for sdhci-msm platform driver. Signed-off-by: Sayali Lokhande --- drivers/mmc/host/sdhci-msm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index e9fe8c6..8846a76 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -1803,6 +1803,7 @@ static int sdhci_msm_probe(struct platform_device *pdev) msm_offset = msm_host->offset; sdhci_get_of_property(pdev); + msm_host->mmc->caps2 |= MMC_CAP2_CLK_SCALE; msm_host->saved_tuning_phase = INVALID_TUNING_PHASE; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC 4/7] mmc: core: add support for devfreq suspend/resume
This change adds support for devfreq suspend/resume
to be called on each system suspend/resume, runtime
suspend/resume, power restore.
Signed-off-by: Talel Shenhar
Signed-off-by: Subhash Jadavani
Signed-off-by: Sayali Lokhande
---
drivers/mmc/core/core.c | 112
drivers/mmc/core/core.h | 2 +
drivers/mmc/core/host.c | 8 +++-
drivers/mmc/core/mmc.c | 27
drivers/mmc/core/sd.c | 13 ++
5 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0eaee42..49103cf 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -618,6 +618,111 @@ int mmc_init_clk_scaling(struct mmc_host *host)
EXPORT_SYMBOL(mmc_init_clk_scaling);
/**
+ * mmc_suspend_clk_scaling() - suspend clock scaling
+ * @host: pointer to mmc host structure
+ *
+ * This API will suspend devfreq feature for the specific host.
+ * The statistics collected by mmc will be cleared.
+ * This function is intended to be called by the pm callbacks
+ * (e.g. runtime_suspend, suspend) of the mmc device
+ */
+int mmc_suspend_clk_scaling(struct mmc_host *host)
+{
+ int err;
+
+ if (!host) {
+ WARN(1, "bad host parameter\n");
+ return -EINVAL;
+ }
+
+ if (!mmc_can_scale_clk(host) || !host->clk_scaling.enable)
+ return 0;
+
+ if (!host->clk_scaling.devfreq) {
+ pr_err("%s: %s: no devfreq is assosiated with this device\n",
+ mmc_hostname(host), __func__);
+ return -EPERM;
+ }
+
+ atomic_inc(>clk_scaling.devfreq_abort);
+ wake_up(>wq);
+ err = devfreq_suspend_device(host->clk_scaling.devfreq);
+ if (err) {
+ pr_err("%s: %s: failed to suspend devfreq\n",
+ mmc_hostname(host), __func__);
+ return err;
+ }
+ host->clk_scaling.enable = false;
+
+ host->clk_scaling.total_busy_time_us = 0;
+
+ pr_debug("%s: devfreq was removed\n", mmc_hostname(host));
+
+ return 0;
+}
+EXPORT_SYMBOL(mmc_suspend_clk_scaling);
+
+/**
+ * mmc_resume_clk_scaling() - resume clock scaling
+ * @host: pointer to mmc host structure
+ *
+ * This API will resume devfreq feature for the specific host.
+ * This API is intended to be called by the pm callbacks
+ * (e.g. runtime_suspend, suspend) of the mmc device
+ */
+int mmc_resume_clk_scaling(struct mmc_host *host)
+{
+ int err = 0;
+ u32 max_clk_idx = 0;
+ u32 devfreq_max_clk = 0;
+ u32 devfreq_min_clk = 0;
+
+ if (!host) {
+ WARN(1, "bad host parameter\n");
+ return -EINVAL;
+ }
+
+ if (!mmc_can_scale_clk(host))
+ return 0;
+
+ /*
+* If clock scaling is already exited when resume is called, like
+* during mmc shutdown, it is not an error and should not fail the
+* API calling this.
+*/
+ if (!host->clk_scaling.devfreq) {
+ pr_warn("%s: %s: no devfreq is assosiated with this device\n",
+ mmc_hostname(host), __func__);
+ return 0;
+ }
+
+ atomic_set(>clk_scaling.devfreq_abort, 0);
+
+ max_clk_idx = host->clk_scaling.freq_table_sz - 1;
+ devfreq_max_clk = host->clk_scaling.freq_table[max_clk_idx];
+ devfreq_min_clk = host->clk_scaling.freq_table[0];
+
+ host->clk_scaling.curr_freq = devfreq_max_clk;
+ if (host->ios.clock < host->clk_scaling.freq_table[max_clk_idx])
+ host->clk_scaling.curr_freq = devfreq_min_clk;
+
+ host->clk_scaling.clk_scaling_in_progress = false;
+ host->clk_scaling.need_freq_change = false;
+
+ err = devfreq_resume_device(host->clk_scaling.devfreq);
+ if (err) {
+ pr_err("%s: %s: failed to resume devfreq (%d)\n",
+ mmc_hostname(host), __func__, err);
+ } else {
+ host->clk_scaling.enable = true;
+ pr_debug("%s: devfreq resumed\n", mmc_hostname(host));
+ }
+
+ return err;
+}
+EXPORT_SYMBOL(mmc_resume_clk_scaling);
+
+/**
* mmc_exit_devfreq_clk_scaling() - Disable clock scaling
* @host: pointer to mmc host structure
*
@@ -642,6 +747,13 @@ int mmc_exit_clk_scaling(struct mmc_host *host)
return -EPERM;
}
+ err = mmc_suspend_clk_scaling(host);
+ if (err) {
+ pr_err("%s: %s: fail to suspend clock scaling (%d)\n",
+ mmc_hostname(host), __func__, err);
+ return err;
+ }
+
err = devfreq_remove_device(host->clk_scaling.devfreq);
if (err) {
pr_err("%s: remove devfreq failed (%d)\n",
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index fc0a9b7..249c20d 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -97,6 +97,8 @@ static inline void mmc_delay(unsigned int
[PATCH RFC 6/7] mmc: sdhci-msm: Enable clock scaling property
This change enables clock scaling capability for sdhci-msm platform driver. Signed-off-by: Sayali Lokhande --- drivers/mmc/host/sdhci-msm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index e9fe8c6..8846a76 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -1803,6 +1803,7 @@ static int sdhci_msm_probe(struct platform_device *pdev) msm_offset = msm_host->offset; sdhci_get_of_property(pdev); + msm_host->mmc->caps2 |= MMC_CAP2_CLK_SCALE; msm_host->saved_tuning_phase = INVALID_TUNING_PHASE; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC 2/7] mmc: core: devfreq: Add devfreq based clock scaling support
This change adds the use of devfreq to MMC.
Both eMMC and SD card will use it.
For some workloads, such as video playback, it isn't
necessary for these cards to run at high speed.
Running at lower frequency, for example 52MHz, in such
cases can still meet the deadlines for data transfers.
Scaling down the clock frequency dynamically has power
savings not only because the bus is running at lower frequency
but also has an advantage of scaling down the system core
voltage, if supported.
Provide an ondemand clock scaling support similar to the
cpufreq ondemand governor having two thresholds,
up_threshold and down_threshold to decide whether to
increase the frequency or scale it down respectively.
The sampling interval is in the order of milliseconds.
If sampling interval is too low, frequent switching of
frequencies can lead to high power consumption and if
sampling interval is too high, the clock scaling logic
would take long time to realize that the underlying
hardware (controller and card) is busy and scale up
the clocks.
Signed-off-by: Talel Shenhar
Signed-off-by: Sayali Lokhande
---
.../devicetree/bindings/mmc/sdhci-msm.txt | 10 +
drivers/mmc/core/core.c| 560 +
drivers/mmc/core/core.h| 7 +
drivers/mmc/core/debugfs.c | 46 ++
drivers/mmc/core/host.c| 8 +
drivers/mmc/core/mmc.c | 200 +++-
drivers/mmc/core/sd.c | 72 ++-
drivers/mmc/host/sdhci-msm.c | 37 ++
drivers/mmc/host/sdhci-pltfm.c | 11 +
drivers/mmc/host/sdhci.c | 27 +
drivers/mmc/host/sdhci.h | 8 +
include/linux/mmc/card.h | 5 +
include/linux/mmc/host.h | 70 +++
13 files changed, 1059 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index 502b3b8..bd8470a 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -26,6 +26,15 @@ Required properties:
"cal" - reference clock for RCLK delay calibration (optional)
"sleep" - sleep clock for RCLK delay calibration (optional)
+Optional Properties:
+- qcom,devfreq,freq-table - specifies supported frequencies for clock scaling.
+ Clock scaling logic shall toggle between
these frequencies based
+ on card load. In case the defined
frequencies are over or below
+ the supported card frequencies, they will
be overridden
+ during card init. In case this entry is not
supplied,
+ the driver will construct one based on the
card
+ supported max and min frequencies.
+ The frequencies must be ordered from lowest
to highest.
Example:
sdhc_1: sdhci@f9824900 {
@@ -43,6 +52,7 @@ Example:
clocks = < GCC_SDCC1_APPS_CLK>, < GCC_SDCC1_AHB_CLK>;
clock-names = "core", "iface";
+ qcom,devfreq,freq-table = <5200 2>;
};
sdhc_2: sdhci@f98a4900 {
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 281826d..0eaee42 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +113,556 @@ static inline void mmc_should_fail_request(struct
mmc_host *host,
#endif /* CONFIG_FAIL_MMC_REQUEST */
+static bool mmc_is_data_request(struct mmc_request *mmc_request)
+{
+ switch (mmc_request->cmd->opcode) {
+ case MMC_READ_SINGLE_BLOCK:
+ case MMC_READ_MULTIPLE_BLOCK:
+ case MMC_WRITE_BLOCK:
+ case MMC_WRITE_MULTIPLE_BLOCK:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void mmc_clk_scaling_start_busy(struct mmc_host *host, bool lock_needed)
+{
+ struct mmc_devfeq_clk_scaling *clk_scaling = >clk_scaling;
+
+ if (!clk_scaling->enable)
+ return;
+
+ if (lock_needed)
+ spin_lock_bh(_scaling->lock);
+
+ clk_scaling->start_busy = ktime_get();
+ clk_scaling->is_busy_started = true;
+
+ if (lock_needed)
+ spin_unlock_bh(_scaling->lock);
+}
+
+static void mmc_clk_scaling_stop_busy(struct mmc_host *host, bool lock_needed)
+{
+ struct mmc_devfeq_clk_scaling *clk_scaling = >clk_scaling;
+
+ if (!clk_scaling->enable)
+ return;
+
+ if (lock_needed)
+ spin_lock_bh(_scaling->lock);
+
+ if (!clk_scaling->is_busy_started) {
+
[PATCH RFC 3/7] mmc: core: Add sysfs entries for dynamic control of clock scaling
Add sysfs attributes to allow dynamic control of clock scaling
parameters. These attributes are used to enable/disable clock
scaling at runtime and change the up_threshold, down_threshold,
and polling_interval values. Complete documentation for these
sysfs entries are provided at "Documentation/mmc/mmc-dev-attrs.txt".
Signed-off-by: Sujit Reddy Thumma
Signed-off-by: Subhash Jadavani
Signed-off-by: Sayali Lokhande
---
Documentation/mmc/mmc-dev-attrs.txt | 38 +
drivers/mmc/core/host.c | 151 +++-
2 files changed, 188 insertions(+), 1 deletion(-)
diff --git a/Documentation/mmc/mmc-dev-attrs.txt
b/Documentation/mmc/mmc-dev-attrs.txt
index 4ad0bb1..b02b2b4 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -75,3 +75,41 @@ Note on raw_rpmb_size_mult:
"raw_rpmb_size_mult" is a multiple of 128kB block.
RPMB size in byte is calculated by using the following equation:
RPMB partition size = 128kB x raw_rpmb_size_mult
+
+SD/MMC Clock Scaling Attributes
+
+
+Read and write accesses are provided to following attributes.
+
+ polling_intervalMeasured in milliseconds, this attribute
+ defines how often we need to check the card
+ usage and make decisions on frequency scaling.
+
+ up_thresholdThis attribute defines what should be the
+ average card usage between the polling
+ interval for the mmc core to make a decision
+ on whether it should increase the frequency.
+ For example when it is set to '35' it means
+ that between the checking intervals the card
+ needs to be on average more than 35% in use to
+ scale up the frequency. The value should be
+ between 0 - 100 so that it can be compared
+ against load percentage.
+
+ down_threshold Similar to up_threshold, but on lowering the
+ frequency. For example, when it is set to '2'
+ it means that between the checking intervals
+ the card needs to be on average less than 2%
+ in use to scale down the clocks to minimum
+ frequency. The value should be between 0 - 100
+ so that it can be compared against load
+ percentage.
+
+ enable Enable clock scaling for hosts (and cards)
+ that support ultrahigh speed modes
+ (SDR104, DDR50, HS200).
+
+echo > /sys/class/mmc_host/mmcX/clk_scaling/polling_interval
+echo > /sys/class/mmc_host/mmcX/clk_scaling/up_threshold
+echo > /sys/class/mmc_host/mmcX/clk_scaling/down_threshold
+echo > /sys/class/mmc_host/mmcX/clk_scaling/enable
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 1e46aa4..0504610 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -419,6 +419,151 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*dev)
EXPORT_SYMBOL(mmc_alloc_host);
+static ssize_t show_enable(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+
+ if (!host)
+ return -EINVAL;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", mmc_can_scale_clk(host));
+}
+
+static ssize_t store_enable(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+ unsigned long value;
+
+ if (!host || !host->card || kstrtoul(buf, 0, ))
+ return -EINVAL;
+
+ mmc_get_card(host->card, NULL);
+
+ if (!value) {
+ /* mask host capability */
+ host->caps2 &= ~MMC_CAP2_CLK_SCALE;
+ host->clk_scaling.state = MMC_LOAD_HIGH;
+ /* Set to max. frequency when disabling */
+ mmc_clk_update_freq(host, host->card->clk_scaling_highest,
+ host->clk_scaling.state);
+ } else if (value) {
+ /* Unmask host capability*/
+ host->caps2 |= MMC_CAP2_CLK_SCALE;
+ }
+
+ mmc_put_card(host->card, NULL);
+
+ return count;
+}
+
+static ssize_t show_up_threshold(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+
+ if (!host)
+ return -EINVAL;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", host->clk_scaling.upthreshold);
+}
+
[PATCH RFC 2/7] mmc: core: devfreq: Add devfreq based clock scaling support
This change adds the use of devfreq to MMC.
Both eMMC and SD card will use it.
For some workloads, such as video playback, it isn't
necessary for these cards to run at high speed.
Running at lower frequency, for example 52MHz, in such
cases can still meet the deadlines for data transfers.
Scaling down the clock frequency dynamically has power
savings not only because the bus is running at lower frequency
but also has an advantage of scaling down the system core
voltage, if supported.
Provide an ondemand clock scaling support similar to the
cpufreq ondemand governor having two thresholds,
up_threshold and down_threshold to decide whether to
increase the frequency or scale it down respectively.
The sampling interval is in the order of milliseconds.
If sampling interval is too low, frequent switching of
frequencies can lead to high power consumption and if
sampling interval is too high, the clock scaling logic
would take long time to realize that the underlying
hardware (controller and card) is busy and scale up
the clocks.
Signed-off-by: Talel Shenhar
Signed-off-by: Sayali Lokhande
---
.../devicetree/bindings/mmc/sdhci-msm.txt | 10 +
drivers/mmc/core/core.c| 560 +
drivers/mmc/core/core.h| 7 +
drivers/mmc/core/debugfs.c | 46 ++
drivers/mmc/core/host.c| 8 +
drivers/mmc/core/mmc.c | 200 +++-
drivers/mmc/core/sd.c | 72 ++-
drivers/mmc/host/sdhci-msm.c | 37 ++
drivers/mmc/host/sdhci-pltfm.c | 11 +
drivers/mmc/host/sdhci.c | 27 +
drivers/mmc/host/sdhci.h | 8 +
include/linux/mmc/card.h | 5 +
include/linux/mmc/host.h | 70 +++
13 files changed, 1059 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index 502b3b8..bd8470a 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -26,6 +26,15 @@ Required properties:
"cal" - reference clock for RCLK delay calibration (optional)
"sleep" - sleep clock for RCLK delay calibration (optional)
+Optional Properties:
+- qcom,devfreq,freq-table - specifies supported frequencies for clock scaling.
+ Clock scaling logic shall toggle between
these frequencies based
+ on card load. In case the defined
frequencies are over or below
+ the supported card frequencies, they will
be overridden
+ during card init. In case this entry is not
supplied,
+ the driver will construct one based on the
card
+ supported max and min frequencies.
+ The frequencies must be ordered from lowest
to highest.
Example:
sdhc_1: sdhci@f9824900 {
@@ -43,6 +52,7 @@ Example:
clocks = < GCC_SDCC1_APPS_CLK>, < GCC_SDCC1_AHB_CLK>;
clock-names = "core", "iface";
+ qcom,devfreq,freq-table = <5200 2>;
};
sdhc_2: sdhci@f98a4900 {
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 281826d..0eaee42 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +113,556 @@ static inline void mmc_should_fail_request(struct
mmc_host *host,
#endif /* CONFIG_FAIL_MMC_REQUEST */
+static bool mmc_is_data_request(struct mmc_request *mmc_request)
+{
+ switch (mmc_request->cmd->opcode) {
+ case MMC_READ_SINGLE_BLOCK:
+ case MMC_READ_MULTIPLE_BLOCK:
+ case MMC_WRITE_BLOCK:
+ case MMC_WRITE_MULTIPLE_BLOCK:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void mmc_clk_scaling_start_busy(struct mmc_host *host, bool lock_needed)
+{
+ struct mmc_devfeq_clk_scaling *clk_scaling = >clk_scaling;
+
+ if (!clk_scaling->enable)
+ return;
+
+ if (lock_needed)
+ spin_lock_bh(_scaling->lock);
+
+ clk_scaling->start_busy = ktime_get();
+ clk_scaling->is_busy_started = true;
+
+ if (lock_needed)
+ spin_unlock_bh(_scaling->lock);
+}
+
+static void mmc_clk_scaling_stop_busy(struct mmc_host *host, bool lock_needed)
+{
+ struct mmc_devfeq_clk_scaling *clk_scaling = >clk_scaling;
+
+ if (!clk_scaling->enable)
+ return;
+
+ if (lock_needed)
+ spin_lock_bh(_scaling->lock);
+
+ if (!clk_scaling->is_busy_started) {
+
[PATCH RFC 3/7] mmc: core: Add sysfs entries for dynamic control of clock scaling
Add sysfs attributes to allow dynamic control of clock scaling
parameters. These attributes are used to enable/disable clock
scaling at runtime and change the up_threshold, down_threshold,
and polling_interval values. Complete documentation for these
sysfs entries are provided at "Documentation/mmc/mmc-dev-attrs.txt".
Signed-off-by: Sujit Reddy Thumma
Signed-off-by: Subhash Jadavani
Signed-off-by: Sayali Lokhande
---
Documentation/mmc/mmc-dev-attrs.txt | 38 +
drivers/mmc/core/host.c | 151 +++-
2 files changed, 188 insertions(+), 1 deletion(-)
diff --git a/Documentation/mmc/mmc-dev-attrs.txt
b/Documentation/mmc/mmc-dev-attrs.txt
index 4ad0bb1..b02b2b4 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -75,3 +75,41 @@ Note on raw_rpmb_size_mult:
"raw_rpmb_size_mult" is a multiple of 128kB block.
RPMB size in byte is calculated by using the following equation:
RPMB partition size = 128kB x raw_rpmb_size_mult
+
+SD/MMC Clock Scaling Attributes
+
+
+Read and write accesses are provided to following attributes.
+
+ polling_intervalMeasured in milliseconds, this attribute
+ defines how often we need to check the card
+ usage and make decisions on frequency scaling.
+
+ up_thresholdThis attribute defines what should be the
+ average card usage between the polling
+ interval for the mmc core to make a decision
+ on whether it should increase the frequency.
+ For example when it is set to '35' it means
+ that between the checking intervals the card
+ needs to be on average more than 35% in use to
+ scale up the frequency. The value should be
+ between 0 - 100 so that it can be compared
+ against load percentage.
+
+ down_threshold Similar to up_threshold, but on lowering the
+ frequency. For example, when it is set to '2'
+ it means that between the checking intervals
+ the card needs to be on average less than 2%
+ in use to scale down the clocks to minimum
+ frequency. The value should be between 0 - 100
+ so that it can be compared against load
+ percentage.
+
+ enable Enable clock scaling for hosts (and cards)
+ that support ultrahigh speed modes
+ (SDR104, DDR50, HS200).
+
+echo > /sys/class/mmc_host/mmcX/clk_scaling/polling_interval
+echo > /sys/class/mmc_host/mmcX/clk_scaling/up_threshold
+echo > /sys/class/mmc_host/mmcX/clk_scaling/down_threshold
+echo > /sys/class/mmc_host/mmcX/clk_scaling/enable
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 1e46aa4..0504610 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -419,6 +419,151 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*dev)
EXPORT_SYMBOL(mmc_alloc_host);
+static ssize_t show_enable(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+
+ if (!host)
+ return -EINVAL;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", mmc_can_scale_clk(host));
+}
+
+static ssize_t store_enable(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+ unsigned long value;
+
+ if (!host || !host->card || kstrtoul(buf, 0, ))
+ return -EINVAL;
+
+ mmc_get_card(host->card, NULL);
+
+ if (!value) {
+ /* mask host capability */
+ host->caps2 &= ~MMC_CAP2_CLK_SCALE;
+ host->clk_scaling.state = MMC_LOAD_HIGH;
+ /* Set to max. frequency when disabling */
+ mmc_clk_update_freq(host, host->card->clk_scaling_highest,
+ host->clk_scaling.state);
+ } else if (value) {
+ /* Unmask host capability*/
+ host->caps2 |= MMC_CAP2_CLK_SCALE;
+ }
+
+ mmc_put_card(host->card, NULL);
+
+ return count;
+}
+
+static ssize_t show_up_threshold(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+
+ if (!host)
+ return -EINVAL;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", host->clk_scaling.upthreshold);
+}
+
[PATCH RFC 1/7] devfreq: Add new flag to do simple clock scaling
From: Sahitya Tummala
Add new flag "simple_scaling" to on demand governor so that
the clocks can be scaled up only when the load is more than
up threshold and can be scaled down only when the load is less
than down differential data as provided within
struct devfreq_simple_ondemand_data.
Signed-off-by: Sahitya Tummala
Signed-off-by: Venkat Gopalakrishnan
Signed-off-by: Sayali Lokhande
---
drivers/devfreq/governor_simpleondemand.c | 25 +++--
include/linux/devfreq.h | 4
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/devfreq/governor_simpleondemand.c
b/drivers/devfreq/governor_simpleondemand.c
index 28e0f2d..532801b 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -28,6 +28,7 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
unsigned int dfso_downdifferential = DFSO_DOWNDIFFERENCTIAL;
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ unsigned long min = (df->min_freq) ? df->min_freq : 0;
err = devfreq_update_stats(df);
if (err)
@@ -45,18 +46,30 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
dfso_upthreshold < dfso_downdifferential)
return -EINVAL;
- /* Assume MAX if it is going to be divided by zero */
- if (stat->total_time == 0) {
- *freq = max;
- return 0;
- }
-
/* Prevent overflow */
if (stat->busy_time >= (1 << 24) || stat->total_time >= (1 << 24)) {
stat->busy_time >>= 7;
stat->total_time >>= 7;
}
+ if (data && data->simple_scaling) {
+ if (stat->busy_time * 100 >
+ stat->total_time * dfso_upthreshold)
+ *freq = max;
+ else if (stat->busy_time * 100 <
+ stat->total_time * dfso_downdifferential)
+ *freq = min;
+ else
+ *freq = df->previous_freq;
+ return 0;
+ }
+
+ /* Assume MAX if it is going to be divided by zero */
+ if (stat->total_time == 0) {
+ *freq = max;
+ return 0;
+ }
+
/* Set MAX if it's busy enough */
if (stat->busy_time * 100 >
stat->total_time * dfso_upthreshold) {
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 3aae5b3..2957fd8 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -236,6 +236,9 @@ extern struct devfreq
*devfreq_get_devfreq_by_phandle(struct device *dev,
* the governor may consider slowing the frequency down.
* Specify 0 to use the default. Valid value = 0 to 100.
* downdifferential < upthreshold must hold.
+ * @simple_scaling:Setting this flag will scale the clocks up only if the
+ * load is above @upthreshold and will scale the clocks
+ * down only if the load is below @downdifferential.
*
* If the fed devfreq_simple_ondemand_data pointer is NULL to the governor,
* the governor uses the default values.
@@ -243,6 +246,7 @@ extern struct devfreq
*devfreq_get_devfreq_by_phandle(struct device *dev,
struct devfreq_simple_ondemand_data {
unsigned int upthreshold;
unsigned int downdifferential;
+ unsigned int simple_scaling;
};
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC 1/7] devfreq: Add new flag to do simple clock scaling
From: Sahitya Tummala
Add new flag "simple_scaling" to on demand governor so that
the clocks can be scaled up only when the load is more than
up threshold and can be scaled down only when the load is less
than down differential data as provided within
struct devfreq_simple_ondemand_data.
Signed-off-by: Sahitya Tummala
Signed-off-by: Venkat Gopalakrishnan
Signed-off-by: Sayali Lokhande
---
drivers/devfreq/governor_simpleondemand.c | 25 +++--
include/linux/devfreq.h | 4
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/devfreq/governor_simpleondemand.c
b/drivers/devfreq/governor_simpleondemand.c
index 28e0f2d..532801b 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -28,6 +28,7 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
unsigned int dfso_downdifferential = DFSO_DOWNDIFFERENCTIAL;
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ unsigned long min = (df->min_freq) ? df->min_freq : 0;
err = devfreq_update_stats(df);
if (err)
@@ -45,18 +46,30 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
dfso_upthreshold < dfso_downdifferential)
return -EINVAL;
- /* Assume MAX if it is going to be divided by zero */
- if (stat->total_time == 0) {
- *freq = max;
- return 0;
- }
-
/* Prevent overflow */
if (stat->busy_time >= (1 << 24) || stat->total_time >= (1 << 24)) {
stat->busy_time >>= 7;
stat->total_time >>= 7;
}
+ if (data && data->simple_scaling) {
+ if (stat->busy_time * 100 >
+ stat->total_time * dfso_upthreshold)
+ *freq = max;
+ else if (stat->busy_time * 100 <
+ stat->total_time * dfso_downdifferential)
+ *freq = min;
+ else
+ *freq = df->previous_freq;
+ return 0;
+ }
+
+ /* Assume MAX if it is going to be divided by zero */
+ if (stat->total_time == 0) {
+ *freq = max;
+ return 0;
+ }
+
/* Set MAX if it's busy enough */
if (stat->busy_time * 100 >
stat->total_time * dfso_upthreshold) {
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 3aae5b3..2957fd8 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -236,6 +236,9 @@ extern struct devfreq
*devfreq_get_devfreq_by_phandle(struct device *dev,
* the governor may consider slowing the frequency down.
* Specify 0 to use the default. Valid value = 0 to 100.
* downdifferential < upthreshold must hold.
+ * @simple_scaling:Setting this flag will scale the clocks up only if the
+ * load is above @upthreshold and will scale the clocks
+ * down only if the load is below @downdifferential.
*
* If the fed devfreq_simple_ondemand_data pointer is NULL to the governor,
* the governor uses the default values.
@@ -243,6 +246,7 @@ extern struct devfreq
*devfreq_get_devfreq_by_phandle(struct device *dev,
struct devfreq_simple_ondemand_data {
unsigned int upthreshold;
unsigned int downdifferential;
+ unsigned int simple_scaling;
};
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH RFC 0/7] Add devfreq based clock scaling support for mmc
This change adds the use of devfreq based clock scaling to MMC. Both eMMC and SD card can use it. For some workloads, such as video playback, it isn't necessary for these cards to run at high speed. Running at lower frequency, in such cases can still meet the deadlines for data transfers. Scaling down the clock frequency dynamically has power savings not only because the bus is running at lower frequency but also has an advantage of scaling down the system core voltage, if supported. Provide an ondemand clock scaling support similar to the cpufreq ondemand governor having two thresholds, up_threshold and down_threshold to decide whether to increase the frequency or scale it down respectively as per load. Sahitya Tummala (1): devfreq: Add new flag to do simple clock scaling Sayali Lokhande (6): mmc: core: devfreq: Add devfreq based clock scaling support mmc: core: Add sysfs entries for dynamic control of clock scaling mmc: core: add support for devfreq suspend/resume mmc: sdhci-msm: Kconfig: select devfreq ondemand for sdhci-msm mmc: sdhci-msm: Enable clock scaling property mmc: core: Add a debugfs entry to set max clock rate .../devicetree/bindings/mmc/sdhci-msm.txt | 10 + Documentation/mmc/mmc-dev-attrs.txt| 38 ++ drivers/devfreq/governor_simpleondemand.c | 25 +- drivers/mmc/core/core.c| 672 + drivers/mmc/core/core.h| 9 + drivers/mmc/core/debugfs.c | 90 +++ drivers/mmc/core/host.c| 163 - drivers/mmc/core/mmc.c | 227 ++- drivers/mmc/core/sd.c | 85 ++- drivers/mmc/host/Kconfig | 2 + drivers/mmc/host/sdhci-msm.c | 38 ++ drivers/mmc/host/sdhci-pltfm.c | 11 + drivers/mmc/host/sdhci.c | 27 + drivers/mmc/host/sdhci.h | 8 + include/linux/devfreq.h| 4 + include/linux/mmc/card.h | 5 + include/linux/mmc/host.h | 70 +++ 17 files changed, 1475 insertions(+), 9 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RFC 0/7] Add devfreq based clock scaling support for mmc
This change adds the use of devfreq based clock scaling to MMC. Both eMMC and SD card can use it. For some workloads, such as video playback, it isn't necessary for these cards to run at high speed. Running at lower frequency, in such cases can still meet the deadlines for data transfers. Scaling down the clock frequency dynamically has power savings not only because the bus is running at lower frequency but also has an advantage of scaling down the system core voltage, if supported. Provide an ondemand clock scaling support similar to the cpufreq ondemand governor having two thresholds, up_threshold and down_threshold to decide whether to increase the frequency or scale it down respectively as per load. Sahitya Tummala (1): devfreq: Add new flag to do simple clock scaling Sayali Lokhande (6): mmc: core: devfreq: Add devfreq based clock scaling support mmc: core: Add sysfs entries for dynamic control of clock scaling mmc: core: add support for devfreq suspend/resume mmc: sdhci-msm: Kconfig: select devfreq ondemand for sdhci-msm mmc: sdhci-msm: Enable clock scaling property mmc: core: Add a debugfs entry to set max clock rate .../devicetree/bindings/mmc/sdhci-msm.txt | 10 + Documentation/mmc/mmc-dev-attrs.txt| 38 ++ drivers/devfreq/governor_simpleondemand.c | 25 +- drivers/mmc/core/core.c| 672 + drivers/mmc/core/core.h| 9 + drivers/mmc/core/debugfs.c | 90 +++ drivers/mmc/core/host.c| 163 - drivers/mmc/core/mmc.c | 227 ++- drivers/mmc/core/sd.c | 85 ++- drivers/mmc/host/Kconfig | 2 + drivers/mmc/host/sdhci-msm.c | 38 ++ drivers/mmc/host/sdhci-pltfm.c | 11 + drivers/mmc/host/sdhci.c | 27 + drivers/mmc/host/sdhci.h | 8 + include/linux/devfreq.h| 4 + include/linux/mmc/card.h | 5 + include/linux/mmc/host.h | 70 +++ 17 files changed, 1475 insertions(+), 9 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 03/39] x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler
On Thu, Jul 12, 2018 at 01:49:13PM -0700, Andy Lutomirski wrote: > > On Jul 11, 2018, at 4:29 AM, Joerg Roedel wrote: > >/* Offset from the sysenter stack to tss.sp0 */ > > -DEFINE(TSS_entry_stack, offsetof(struct cpu_entry_area, > > tss.x86_tss.sp0) - > > +DEFINE(TSS_entry_stack, offsetof(struct cpu_entry_area, > > tss.x86_tss.sp1) - > > offsetofend(struct cpu_entry_area, entry_stack_page.stack)); > > > > The code reads differently. Did you perhaps mean TSS_task_stack? Well, the offset name came from TSS_sysenter_sp0, which was the offset from the sysenter_sp0 (==sysenter-stack) to the task stack in TSS, now sysenter_sp0 became entry_stack, because its used for all entry points and not only sysenter. So with the old convention the naming makes still sense, no? > Also, the “top of task stack” is a bit weird on 32-bit due to vm86. > Can you document *exactly* what goes in sp1? Will do, thanks for your feedback! Joerg
Re: [PATCH 03/39] x86/entry/32: Load task stack from x86_tss.sp1 in SYSENTER handler
On Thu, Jul 12, 2018 at 01:49:13PM -0700, Andy Lutomirski wrote: > > On Jul 11, 2018, at 4:29 AM, Joerg Roedel wrote: > >/* Offset from the sysenter stack to tss.sp0 */ > > -DEFINE(TSS_entry_stack, offsetof(struct cpu_entry_area, > > tss.x86_tss.sp0) - > > +DEFINE(TSS_entry_stack, offsetof(struct cpu_entry_area, > > tss.x86_tss.sp1) - > > offsetofend(struct cpu_entry_area, entry_stack_page.stack)); > > > > The code reads differently. Did you perhaps mean TSS_task_stack? Well, the offset name came from TSS_sysenter_sp0, which was the offset from the sysenter_sp0 (==sysenter-stack) to the task stack in TSS, now sysenter_sp0 became entry_stack, because its used for all entry points and not only sysenter. So with the old convention the naming makes still sense, no? > Also, the “top of task stack” is a bit weird on 32-bit due to vm86. > Can you document *exactly* what goes in sp1? Will do, thanks for your feedback! Joerg
Re: REGRESSION: [PATCH] mmc: tegra: Use sdhci_pltfm_clk_get_max_clock
On Fri, 13 Jul 2018 01:43:05 +
Marcel Ziswiler wrote:
> On Mon, 2018-07-02 at 15:16 +0200, Ulf Hansson wrote:
> > On 4 June 2018 at 17:35, Aapo Vienamo wrote:
> > > The sdhci get_max_clock callback is set to
> > > sdhci_pltfm_clk_get_max_clock
> > > and tegra_sdhci_get_max_clock is removed. It appears that the
> > > shdci-tegra specific callback was originally introduced due to the
> > > requirement that the host clock has to be twice the bus clock on
> > > DDR50
> > > mode. As far as I can tell the only effect the removal has on DDR50
> > > mode
> > > is in cases where the parent clock is unable to supply the
> > > requested
> > > clock rate, causing the DDR50 mode to run at a lower frequency.
> > > Currently the DDR50 mode isn't enabled on any of the SoCs and would
> > > also
> > > require configuring the SDHCI clock divider register to function
> > > properly.
> > >
> > > The problem with tegra_sdhci_get_max_clock is that it divides the
> > > clock
> > > rate by two and thus artificially limits the maximum frequency of
> > > faster
> > > signaling modes which don't have the host-bus frequency ratio
> > > requirement
> > > of DDR50 such as SDR104 and HS200. Furthermore, the call to
> > > clk_round_rate() may return an error which isn't handled by
> > > tegra_sdhci_get_max_clock.
> > >
> > > Signed-off-by: Aapo Vienamo
> >
> > Thanks, applied for next!
> >
> > Kind regards
> > Uffe
> >
> > > ---
> > > drivers/mmc/host/sdhci-tegra.c | 15 ++-
> > > 1 file changed, 2 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci-tegra.c
> > > b/drivers/mmc/host/sdhci-tegra.c
> > > index 970d38f6..c8745b5 100644
> > > --- a/drivers/mmc/host/sdhci-tegra.c
> > > +++ b/drivers/mmc/host/sdhci-tegra.c
> > > @@ -234,17 +234,6 @@ static void
> > > tegra_sdhci_set_uhs_signaling(struct sdhci_host *host,
> > > sdhci_set_uhs_signaling(host, timing);
> > > }
> > >
> > > -static unsigned int tegra_sdhci_get_max_clock(struct sdhci_host
> > > *host)
> > > -{
> > > - struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > > -
> > > - /*
> > > -* DDR modes require the host to run at double the card
> > > frequency, so
> > > -* the maximum rate we can support is half of the module
> > > input clock.
> > > -*/
> > > - return clk_round_rate(pltfm_host->clk, UINT_MAX) / 2;
> > > -}
> > > -
> > > static void tegra_sdhci_set_tap(struct sdhci_host *host, unsigned
> > > int tap)
> > > {
> > > u32 reg;
> > > @@ -309,7 +298,7 @@ static const struct sdhci_ops tegra_sdhci_ops =
> > > {
> > > .platform_execute_tuning = tegra_sdhci_execute_tuning,
> > > .set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
> > > .voltage_switch = tegra_sdhci_voltage_switch,
> > > - .get_max_clock = tegra_sdhci_get_max_clock,
> > > + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > > };
> > >
> > > static const struct sdhci_pltfm_data sdhci_tegra20_pdata = {
> > > @@ -357,7 +346,7 @@ static const struct sdhci_ops
> > > tegra114_sdhci_ops = {
> > > .platform_execute_tuning = tegra_sdhci_execute_tuning,
> > > .set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
> > > .voltage_switch = tegra_sdhci_voltage_switch,
> > > - .get_max_clock = tegra_sdhci_get_max_clock,
> > > + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > > };
> > >
> > > static const struct sdhci_pltfm_data sdhci_tegra114_pdata = {
> > > --
> > > 2.7.4
>
> Hm, for us this definitely breaks stuff. While using Stefan's patch set
> [1] we may not only run eMMC at DDR52 even SD cards run stable at
> SDR104. With this patch however the clock gets crippled to 45.33 resp.
> 48 MHz always. This is observed both on Apalis/Colibri T30 as well as
> Apalis TK1.
Well, strictly speaking this isn't a regression as DDR52/50 modes were
not enable at the time when the patch was applied. However, these issues
should be addressed properly none the less.
The patch was written in preparation of implementing support for higher
speed modes like HS200 and HS400, where limiting the max_clock like that
isn't an option. Some other solution than reverting the patch has to be
found.
> Current next-20180712 just with Stefan's 3 patches:
>
> root@apalis-t30:~# cat /sys/kernel/debug/mmc1/ios
> clock: 4800 Hz
> actual clock: 4533 Hz
> vdd:21 (3.3 ~ 3.4 V)
> bus mode: 2 (push-pull)
> chip select:0 (don't care)
> power mode: 2 (on)
> bus width: 3 (8 bits)
> timing spec:8 (mmc DDR52)
> signal voltage: 1 (1.80 V)
> driver type:0 (driver type B)
> root@apalis-t30:~# hdparm -t /dev/mmcblk1
>
> /dev/mmcblk1:
> Timing buffered disk reads: 218 MB in 3.03 seconds = 71.95 MB/sec
>
> root@apalis-t30:~# cat /sys/kernel/debug/mmc2/ios
> clock: 4800 Hz
> actual clock: 4800 Hz
> vdd:21 (3.3 ~ 3.4 V)
> bus mode: 2 (push-pull)
> chip select:
[PATCH 2/2] pinctrl: berlin: add the as370 SoC pinctrl driver
Add the pin-controller driver for Synaptics AS370 SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.
Signed-off-by: Jisheng Zhang
---
drivers/pinctrl/berlin/Kconfig | 5 +
drivers/pinctrl/berlin/Makefile| 1 +
drivers/pinctrl/berlin/pinctrl-as370.c | 369 +
3 files changed, 375 insertions(+)
create mode 100644 drivers/pinctrl/berlin/pinctrl-as370.c
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index 8fe6ad7795dc..0dd60278e973 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -5,6 +5,11 @@ config PINCTRL_BERLIN
select PINMUX
select REGMAP_MMIO
+config PINCTRL_AS370
+ bool "Synaptics as370 pin controller driver"
+ depends on OF
+ select PINCTRL_BERLIN
+
config PINCTRL_BERLIN_BG2
def_bool MACH_BERLIN_BG2
depends on OF
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index 6f641ce2c830..00c53ca3676d 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PINCTRL_BERLIN_BG2)+= berlin-bg2.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2CD) += berlin-bg2cd.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2Q) += berlin-bg2q.o
obj-$(CONFIG_PINCTRL_BERLIN_BG4CT) += berlin-bg4ct.o
+obj-$(CONFIG_PINCTRL_AS370)+= pinctrl-as370.o
diff --git a/drivers/pinctrl/berlin/pinctrl-as370.c
b/drivers/pinctrl/berlin/pinctrl-as370.c
new file mode 100644
index ..5d8352d801dd
--- /dev/null
+++ b/drivers/pinctrl/berlin/pinctrl-as370.c
@@ -0,0 +1,369 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Synaptics AS370 pinctrl driver
+ *
+ * Copyright (C) 2018 Synaptics Incorporated
+ *
+ * Author: Jisheng Zhang
+ */
+
+#include
+#include
+#include
+#include
+
+#include "berlin.h"
+
+static const struct berlin_desc_group as370_soc_pinctrl_groups[] = {
+ BERLIN_PINCTRL_GROUP("I2S1_BCLKIO", 0x0, 0x3, 0x00,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO0 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* BCLKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG0 */
+ BERLIN_PINCTRL_GROUP("I2S1_LRCKIO", 0x0, 0x3, 0x03,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO1 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* LRCKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG1 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO0", 0x0, 0x3, 0x06,
+ BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* 1P8V RSTB*/
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO0 */
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO2 */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG2 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO1", 0x0, 0x3, 0x09,
+ BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* 3P3V RSTB */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO1 */
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO3 */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG3 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO2", 0x0, 0x3, 0x0c,
+ BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* CORE RSTB */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO2 */
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm4"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO4 */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG4 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO3", 0x0, 0x3, 0x0f,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO5 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO3 */
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm5"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "spififib"), /* SPDIFIB */
+ BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG5 */
+ BERLIN_PINCTRL_GROUP("I2S1_MCLK", 0x0, 0x3, 0x12,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO6 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* MCLK */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG6 */
+ BERLIN_PINCTRL_GROUP("I2S2_BCLKIO", 0x0, 0x3, 0x15,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO7 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* BCLKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG7 */
+ BERLIN_PINCTRL_GROUP("I2S2_LRCKIO", 0x0, 0x3, 0x18,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO8 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* LRCKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG8 */
+
Re: REGRESSION: [PATCH] mmc: tegra: Use sdhci_pltfm_clk_get_max_clock
On Fri, 13 Jul 2018 01:43:05 +
Marcel Ziswiler wrote:
> On Mon, 2018-07-02 at 15:16 +0200, Ulf Hansson wrote:
> > On 4 June 2018 at 17:35, Aapo Vienamo wrote:
> > > The sdhci get_max_clock callback is set to
> > > sdhci_pltfm_clk_get_max_clock
> > > and tegra_sdhci_get_max_clock is removed. It appears that the
> > > shdci-tegra specific callback was originally introduced due to the
> > > requirement that the host clock has to be twice the bus clock on
> > > DDR50
> > > mode. As far as I can tell the only effect the removal has on DDR50
> > > mode
> > > is in cases where the parent clock is unable to supply the
> > > requested
> > > clock rate, causing the DDR50 mode to run at a lower frequency.
> > > Currently the DDR50 mode isn't enabled on any of the SoCs and would
> > > also
> > > require configuring the SDHCI clock divider register to function
> > > properly.
> > >
> > > The problem with tegra_sdhci_get_max_clock is that it divides the
> > > clock
> > > rate by two and thus artificially limits the maximum frequency of
> > > faster
> > > signaling modes which don't have the host-bus frequency ratio
> > > requirement
> > > of DDR50 such as SDR104 and HS200. Furthermore, the call to
> > > clk_round_rate() may return an error which isn't handled by
> > > tegra_sdhci_get_max_clock.
> > >
> > > Signed-off-by: Aapo Vienamo
> >
> > Thanks, applied for next!
> >
> > Kind regards
> > Uffe
> >
> > > ---
> > > drivers/mmc/host/sdhci-tegra.c | 15 ++-
> > > 1 file changed, 2 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci-tegra.c
> > > b/drivers/mmc/host/sdhci-tegra.c
> > > index 970d38f6..c8745b5 100644
> > > --- a/drivers/mmc/host/sdhci-tegra.c
> > > +++ b/drivers/mmc/host/sdhci-tegra.c
> > > @@ -234,17 +234,6 @@ static void
> > > tegra_sdhci_set_uhs_signaling(struct sdhci_host *host,
> > > sdhci_set_uhs_signaling(host, timing);
> > > }
> > >
> > > -static unsigned int tegra_sdhci_get_max_clock(struct sdhci_host
> > > *host)
> > > -{
> > > - struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > > -
> > > - /*
> > > -* DDR modes require the host to run at double the card
> > > frequency, so
> > > -* the maximum rate we can support is half of the module
> > > input clock.
> > > -*/
> > > - return clk_round_rate(pltfm_host->clk, UINT_MAX) / 2;
> > > -}
> > > -
> > > static void tegra_sdhci_set_tap(struct sdhci_host *host, unsigned
> > > int tap)
> > > {
> > > u32 reg;
> > > @@ -309,7 +298,7 @@ static const struct sdhci_ops tegra_sdhci_ops =
> > > {
> > > .platform_execute_tuning = tegra_sdhci_execute_tuning,
> > > .set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
> > > .voltage_switch = tegra_sdhci_voltage_switch,
> > > - .get_max_clock = tegra_sdhci_get_max_clock,
> > > + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > > };
> > >
> > > static const struct sdhci_pltfm_data sdhci_tegra20_pdata = {
> > > @@ -357,7 +346,7 @@ static const struct sdhci_ops
> > > tegra114_sdhci_ops = {
> > > .platform_execute_tuning = tegra_sdhci_execute_tuning,
> > > .set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
> > > .voltage_switch = tegra_sdhci_voltage_switch,
> > > - .get_max_clock = tegra_sdhci_get_max_clock,
> > > + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > > };
> > >
> > > static const struct sdhci_pltfm_data sdhci_tegra114_pdata = {
> > > --
> > > 2.7.4
>
> Hm, for us this definitely breaks stuff. While using Stefan's patch set
> [1] we may not only run eMMC at DDR52 even SD cards run stable at
> SDR104. With this patch however the clock gets crippled to 45.33 resp.
> 48 MHz always. This is observed both on Apalis/Colibri T30 as well as
> Apalis TK1.
Well, strictly speaking this isn't a regression as DDR52/50 modes were
not enable at the time when the patch was applied. However, these issues
should be addressed properly none the less.
The patch was written in preparation of implementing support for higher
speed modes like HS200 and HS400, where limiting the max_clock like that
isn't an option. Some other solution than reverting the patch has to be
found.
> Current next-20180712 just with Stefan's 3 patches:
>
> root@apalis-t30:~# cat /sys/kernel/debug/mmc1/ios
> clock: 4800 Hz
> actual clock: 4533 Hz
> vdd:21 (3.3 ~ 3.4 V)
> bus mode: 2 (push-pull)
> chip select:0 (don't care)
> power mode: 2 (on)
> bus width: 3 (8 bits)
> timing spec:8 (mmc DDR52)
> signal voltage: 1 (1.80 V)
> driver type:0 (driver type B)
> root@apalis-t30:~# hdparm -t /dev/mmcblk1
>
> /dev/mmcblk1:
> Timing buffered disk reads: 218 MB in 3.03 seconds = 71.95 MB/sec
>
> root@apalis-t30:~# cat /sys/kernel/debug/mmc2/ios
> clock: 4800 Hz
> actual clock: 4800 Hz
> vdd:21 (3.3 ~ 3.4 V)
> bus mode: 2 (push-pull)
> chip select:
[PATCH 2/2] pinctrl: berlin: add the as370 SoC pinctrl driver
Add the pin-controller driver for Synaptics AS370 SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.
Signed-off-by: Jisheng Zhang
---
drivers/pinctrl/berlin/Kconfig | 5 +
drivers/pinctrl/berlin/Makefile| 1 +
drivers/pinctrl/berlin/pinctrl-as370.c | 369 +
3 files changed, 375 insertions(+)
create mode 100644 drivers/pinctrl/berlin/pinctrl-as370.c
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index 8fe6ad7795dc..0dd60278e973 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -5,6 +5,11 @@ config PINCTRL_BERLIN
select PINMUX
select REGMAP_MMIO
+config PINCTRL_AS370
+ bool "Synaptics as370 pin controller driver"
+ depends on OF
+ select PINCTRL_BERLIN
+
config PINCTRL_BERLIN_BG2
def_bool MACH_BERLIN_BG2
depends on OF
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index 6f641ce2c830..00c53ca3676d 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PINCTRL_BERLIN_BG2)+= berlin-bg2.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2CD) += berlin-bg2cd.o
obj-$(CONFIG_PINCTRL_BERLIN_BG2Q) += berlin-bg2q.o
obj-$(CONFIG_PINCTRL_BERLIN_BG4CT) += berlin-bg4ct.o
+obj-$(CONFIG_PINCTRL_AS370)+= pinctrl-as370.o
diff --git a/drivers/pinctrl/berlin/pinctrl-as370.c
b/drivers/pinctrl/berlin/pinctrl-as370.c
new file mode 100644
index ..5d8352d801dd
--- /dev/null
+++ b/drivers/pinctrl/berlin/pinctrl-as370.c
@@ -0,0 +1,369 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Synaptics AS370 pinctrl driver
+ *
+ * Copyright (C) 2018 Synaptics Incorporated
+ *
+ * Author: Jisheng Zhang
+ */
+
+#include
+#include
+#include
+#include
+
+#include "berlin.h"
+
+static const struct berlin_desc_group as370_soc_pinctrl_groups[] = {
+ BERLIN_PINCTRL_GROUP("I2S1_BCLKIO", 0x0, 0x3, 0x00,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO0 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* BCLKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG0 */
+ BERLIN_PINCTRL_GROUP("I2S1_LRCKIO", 0x0, 0x3, 0x03,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO1 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* LRCKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG1 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO0", 0x0, 0x3, 0x06,
+ BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* 1P8V RSTB*/
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO0 */
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO2 */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG2 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO1", 0x0, 0x3, 0x09,
+ BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* 3P3V RSTB */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO1 */
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO3 */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG3 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO2", 0x0, 0x3, 0x0c,
+ BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* CORE RSTB */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO2 */
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm4"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO4 */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG4 */
+ BERLIN_PINCTRL_GROUP("I2S1_DO3", 0x0, 0x3, 0x0f,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO5 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO3 */
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm5"),
+ BERLIN_PINCTRL_FUNCTION(0x3, "spififib"), /* SPDIFIB */
+ BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG5 */
+ BERLIN_PINCTRL_GROUP("I2S1_MCLK", 0x0, 0x3, 0x12,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO6 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* MCLK */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG6 */
+ BERLIN_PINCTRL_GROUP("I2S2_BCLKIO", 0x0, 0x3, 0x15,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO7 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* BCLKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG7 */
+ BERLIN_PINCTRL_GROUP("I2S2_LRCKIO", 0x0, 0x3, 0x18,
+ BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO8 */
+ BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* LRCKIO */
+ BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG8 */
+
[PATCH 1/2] dt-binding: pinctrl: berlin: document AS370 SoC pinctrl
Add as370 to existing berlin pinctrl device tree binding. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt index f8fa28ce163e..0a2d5516e1f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt @@ -23,7 +23,8 @@ Required properties: "marvell,berlin2q-system-pinctrl", "marvell,berlin4ct-avio-pinctrl", "marvell,berlin4ct-soc-pinctrl", - "marvell,berlin4ct-system-pinctrl" + "marvell,berlin4ct-system-pinctrl", + "syna,as370-soc-pinctrl" Required subnode-properties: - groups: a list of strings describing the group names. -- 2.18.0
[PATCH 1/2] dt-binding: pinctrl: berlin: document AS370 SoC pinctrl
Add as370 to existing berlin pinctrl device tree binding. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt index f8fa28ce163e..0a2d5516e1f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt @@ -23,7 +23,8 @@ Required properties: "marvell,berlin2q-system-pinctrl", "marvell,berlin4ct-avio-pinctrl", "marvell,berlin4ct-soc-pinctrl", - "marvell,berlin4ct-system-pinctrl" + "marvell,berlin4ct-system-pinctrl", + "syna,as370-soc-pinctrl" Required subnode-properties: - groups: a list of strings describing the group names. -- 2.18.0
[PATCH 0/2] pinctrl: berlin: add as370 SoC support
This series is to add the Synaptics AS370 SoC pinctrl driver. Jisheng Zhang (2): dt-binding: pinctrl: berlin: document AS370 SoC pinctrl pinctrl: berlin: add the as370 SoC pinctrl driver .../bindings/pinctrl/berlin,pinctrl.txt | 3 +- drivers/pinctrl/berlin/Kconfig| 5 + drivers/pinctrl/berlin/Makefile | 1 + drivers/pinctrl/berlin/pinctrl-as370.c| 369 ++ 4 files changed, 377 insertions(+), 1 deletion(-) create mode 100644 drivers/pinctrl/berlin/pinctrl-as370.c -- 2.18.0
[PATCH 0/2] pinctrl: berlin: add as370 SoC support
This series is to add the Synaptics AS370 SoC pinctrl driver. Jisheng Zhang (2): dt-binding: pinctrl: berlin: document AS370 SoC pinctrl pinctrl: berlin: add the as370 SoC pinctrl driver .../bindings/pinctrl/berlin,pinctrl.txt | 3 +- drivers/pinctrl/berlin/Kconfig| 5 + drivers/pinctrl/berlin/Makefile | 1 + drivers/pinctrl/berlin/pinctrl-as370.c| 369 ++ 4 files changed, 377 insertions(+), 1 deletion(-) create mode 100644 drivers/pinctrl/berlin/pinctrl-as370.c -- 2.18.0
Re: [PATCH 22/32] vfs: Provide documentation for new mount API [ver #9]
Randy Dunlap wrote: > I would review this but it sounds like I should just wait for the > next version. Probably a good idea. Thanks for the consideration anyway. David
Re: [PATCH 22/32] vfs: Provide documentation for new mount API [ver #9]
Randy Dunlap wrote: > I would review this but it sounds like I should just wait for the > next version. Probably a good idea. Thanks for the consideration anyway. David
Re: [PATCH 04/10] staging:rtl8192u: Rename file macro to avoid camel case - Coding Style
On Wed, Jul 11, 2018 at 08:21:43PM +0100, John Whitmore wrote: > Simple rename of the preprosessor switch, protecting against multiple > inclusion of the header file. Change to clear the checkpatch coding style > issue. > > Signed-off-by: John Whitmore > --- > drivers/staging/rtl8192u/r8192U.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/rtl8192u/r8192U.h > b/drivers/staging/rtl8192u/r8192U.h > index a653a51f7b90..86cf3ef3a970 100644 > --- a/drivers/staging/rtl8192u/r8192U.h > +++ b/drivers/staging/rtl8192u/r8192U.h > @@ -15,8 +15,8 @@ > * project Authors. > */ > > -#ifndef R819xU_H > -#define R819xU_H > +#ifndef R819U_H > +#define R819U_H Shouldn't this be R8192U_H? thanks, greg k-h
Re: [PATCH 04/10] staging:rtl8192u: Rename file macro to avoid camel case - Coding Style
On Wed, Jul 11, 2018 at 08:21:43PM +0100, John Whitmore wrote: > Simple rename of the preprosessor switch, protecting against multiple > inclusion of the header file. Change to clear the checkpatch coding style > issue. > > Signed-off-by: John Whitmore > --- > drivers/staging/rtl8192u/r8192U.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/rtl8192u/r8192U.h > b/drivers/staging/rtl8192u/r8192U.h > index a653a51f7b90..86cf3ef3a970 100644 > --- a/drivers/staging/rtl8192u/r8192U.h > +++ b/drivers/staging/rtl8192u/r8192U.h > @@ -15,8 +15,8 @@ > * project Authors. > */ > > -#ifndef R819xU_H > -#define R819xU_H > +#ifndef R819U_H > +#define R819U_H Shouldn't this be R8192U_H? thanks, greg k-h
Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On Fri, Jul 13, 2018 at 11:07:11AM +0200, Andrea Parri wrote: > On Thu, Jul 12, 2018 at 07:05:39PM -0700, Daniel Lustig wrote: > > On 7/12/2018 11:10 AM, Linus Torvalds wrote: > > > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra > > > wrote: > > >> > > >> The locking pattern is fairly simple and shows where RCpc comes apart > > >> from expectation real nice. > > > > > > So who does RCpc right now for the unlock-lock sequence? Somebody > > > mentioned powerpc. Anybody else? > > > > > > How nasty would be be to make powerpc conform? I will always advocate > > > tighter locking and ordering rules over looser ones.. > > > > > > Linus > > > > RISC-V probably would have been RCpc if we weren't having this discussion. > > Depending on how we map atomics/acquire/release/unlock/lock, we can end up > > producing RCpc, "RCtso" (feel free to find a better name here...), or RCsc > > behaviors, and we're trying to figure out which we actually need. > > > > I think the debate is this: > > > > Obviously programmers would prefer just to have RCsc and not have to figure > > out > > all the complexity of the other options. On x86 or architectures with > > native > > RCsc operations (like ARMv8), that's generally easy enough to get. > > > > For weakly-ordered architectures that use fences for ordering (including > > PowerPC and sometimes RISC-V, see below), though, it takes extra fences to > > go > > from RCpc to either "RCtso" or RCsc. People using these architectures are > > concerned about whether there's a negative performance impact from those > > extra > > fences. > > > > However, some scheduler code, some RCU code, and probably some other > > examples > > already implicitly or explicitly assume unlock()/lock() provides stronger > > ordering than RCpc. So, we have to decide whether to: > > 1) define unlock()/lock() to enforce "RCtso" or RCsc, insert more fences on > > PowerPC and RISC-V accordingly, and probably negatively regress PowerPC > > 2) leave unlock()/lock() as enforcing only RCpc, fix any code that currently > > assumes something stronger than RCpc is being provided, and hope people > > don't > > get it wrong in the future > > 3) some mixture like having unlock()/lock() be "RCtso" but > > smp_store_release()/ > > smp_cond_load_acquire() be only RCpc > > > > Also, FWIW, if other weakly-ordered architectures come along in the future > > and > > also use any kind of lightweight fence rather than native RCsc operations, > > they'll likely be in the same boat as RISC-V and Power here, in the sense of > > not providing RCsc by default either. > > > > Is that a fair assessment everyone? > > It's for me, thank you! And as we've seen, there are arguments for each of > the above three choices. I'm afraid that (despite Linus's statement ;-)), > my preference would currently go to (2). And, since we're stating preferences, I'll reiterate my preference towards: * RCsc unlock/lock * RCpc release/acquire * Not fussed about atomic rmws, but having them closer to RCsc would make it easier to implement and reason about generic locking implementations (i.e. reduce the number of special ordering cases and/or magic barrier macros) Will
Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On Fri, Jul 13, 2018 at 11:07:11AM +0200, Andrea Parri wrote: > On Thu, Jul 12, 2018 at 07:05:39PM -0700, Daniel Lustig wrote: > > On 7/12/2018 11:10 AM, Linus Torvalds wrote: > > > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra > > > wrote: > > >> > > >> The locking pattern is fairly simple and shows where RCpc comes apart > > >> from expectation real nice. > > > > > > So who does RCpc right now for the unlock-lock sequence? Somebody > > > mentioned powerpc. Anybody else? > > > > > > How nasty would be be to make powerpc conform? I will always advocate > > > tighter locking and ordering rules over looser ones.. > > > > > > Linus > > > > RISC-V probably would have been RCpc if we weren't having this discussion. > > Depending on how we map atomics/acquire/release/unlock/lock, we can end up > > producing RCpc, "RCtso" (feel free to find a better name here...), or RCsc > > behaviors, and we're trying to figure out which we actually need. > > > > I think the debate is this: > > > > Obviously programmers would prefer just to have RCsc and not have to figure > > out > > all the complexity of the other options. On x86 or architectures with > > native > > RCsc operations (like ARMv8), that's generally easy enough to get. > > > > For weakly-ordered architectures that use fences for ordering (including > > PowerPC and sometimes RISC-V, see below), though, it takes extra fences to > > go > > from RCpc to either "RCtso" or RCsc. People using these architectures are > > concerned about whether there's a negative performance impact from those > > extra > > fences. > > > > However, some scheduler code, some RCU code, and probably some other > > examples > > already implicitly or explicitly assume unlock()/lock() provides stronger > > ordering than RCpc. So, we have to decide whether to: > > 1) define unlock()/lock() to enforce "RCtso" or RCsc, insert more fences on > > PowerPC and RISC-V accordingly, and probably negatively regress PowerPC > > 2) leave unlock()/lock() as enforcing only RCpc, fix any code that currently > > assumes something stronger than RCpc is being provided, and hope people > > don't > > get it wrong in the future > > 3) some mixture like having unlock()/lock() be "RCtso" but > > smp_store_release()/ > > smp_cond_load_acquire() be only RCpc > > > > Also, FWIW, if other weakly-ordered architectures come along in the future > > and > > also use any kind of lightweight fence rather than native RCsc operations, > > they'll likely be in the same boat as RISC-V and Power here, in the sense of > > not providing RCsc by default either. > > > > Is that a fair assessment everyone? > > It's for me, thank you! And as we've seen, there are arguments for each of > the above three choices. I'm afraid that (despite Linus's statement ;-)), > my preference would currently go to (2). And, since we're stating preferences, I'll reiterate my preference towards: * RCsc unlock/lock * RCpc release/acquire * Not fussed about atomic rmws, but having them closer to RCsc would make it easier to implement and reason about generic locking implementations (i.e. reduce the number of special ordering cases and/or magic barrier macros) Will
Re: [PATCH V5 0/5] add iwdg2 support for stm32mp157c
Hi Ludovic On 06/25/2018 05:42 PM, Ludovic Barre wrote: From: Ludovic Barre This patch series updates stm32_iwdg driver to manage pclk clock by compatible. stm32mp1 requires a pclk clock. v5: -update stm32f429.dtsi v4: -dt-bindings: split and review v3: -remove stm32_iwdg_config structure, just assign the boolean directly to .dat Ludovic Barre (5): dt-bindings: watchdog: add stm32mp1 support watchdog: stm32: add pclk feature for stm32mp1 ARM: dts: stm32: add iwdg2 support for stm32mp157c ARM: dts: stm32: add iwdg2 support for stm32mp157c-ed1 ARM: dts: stm32: update iwdg with lsi clock name for stm32f429 .../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 13 ++- arch/arm/boot/dts/stm32f429.dtsi | 1 + arch/arm/boot/dts/stm32mp157c-ed1.dts | 5 + arch/arm/boot/dts/stm32mp157c.dtsi | 8 ++ drivers/watchdog/stm32_iwdg.c | 116 + 5 files changed, 98 insertions(+), 45 deletions(-) STM32 DT patches applied on stm32-next. Regards Alex
Re: [PATCH] connector: hide unused procfs helpers
pls ignore this,my bad.
On 2018/7/13 15:11, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/connector/connector.c:242:12: warning: ‘cn_proc_show’ defined but not
> used [-Wunused-function]
> static int cn_proc_show(struct seq_file *m, void *v)
> ^
> fix this by adding #ifdef around it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/connector/connector.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
> index e718b8c..e2636d4 100644
> --- a/drivers/connector/connector.c
> +++ b/drivers/connector/connector.c
> @@ -239,6 +239,7 @@ void cn_del_callback(struct cb_id *id)
> }
> EXPORT_SYMBOL_GPL(cn_del_callback);
>
> +#ifdef CONFIG_PROC_FS
> static int cn_proc_show(struct seq_file *m, void *v)
> {
> struct cn_queue_dev *dev = cdev.cbdev;
> @@ -259,6 +260,7 @@ static int cn_proc_show(struct seq_file *m, void *v)
>
> return 0;
> }
> +#endif
>
> static struct cn_dev cdev = {
> .input = cn_rx_skb,
>
Re: [PATCH V5 0/5] add iwdg2 support for stm32mp157c
Hi Ludovic On 06/25/2018 05:42 PM, Ludovic Barre wrote: From: Ludovic Barre This patch series updates stm32_iwdg driver to manage pclk clock by compatible. stm32mp1 requires a pclk clock. v5: -update stm32f429.dtsi v4: -dt-bindings: split and review v3: -remove stm32_iwdg_config structure, just assign the boolean directly to .dat Ludovic Barre (5): dt-bindings: watchdog: add stm32mp1 support watchdog: stm32: add pclk feature for stm32mp1 ARM: dts: stm32: add iwdg2 support for stm32mp157c ARM: dts: stm32: add iwdg2 support for stm32mp157c-ed1 ARM: dts: stm32: update iwdg with lsi clock name for stm32f429 .../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 13 ++- arch/arm/boot/dts/stm32f429.dtsi | 1 + arch/arm/boot/dts/stm32mp157c-ed1.dts | 5 + arch/arm/boot/dts/stm32mp157c.dtsi | 8 ++ drivers/watchdog/stm32_iwdg.c | 116 + 5 files changed, 98 insertions(+), 45 deletions(-) STM32 DT patches applied on stm32-next. Regards Alex
Re: [PATCH] connector: hide unused procfs helpers
pls ignore this,my bad.
On 2018/7/13 15:11, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/connector/connector.c:242:12: warning: ‘cn_proc_show’ defined but not
> used [-Wunused-function]
> static int cn_proc_show(struct seq_file *m, void *v)
> ^
> fix this by adding #ifdef around it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/connector/connector.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
> index e718b8c..e2636d4 100644
> --- a/drivers/connector/connector.c
> +++ b/drivers/connector/connector.c
> @@ -239,6 +239,7 @@ void cn_del_callback(struct cb_id *id)
> }
> EXPORT_SYMBOL_GPL(cn_del_callback);
>
> +#ifdef CONFIG_PROC_FS
> static int cn_proc_show(struct seq_file *m, void *v)
> {
> struct cn_queue_dev *dev = cdev.cbdev;
> @@ -259,6 +260,7 @@ static int cn_proc_show(struct seq_file *m, void *v)
>
> return 0;
> }
> +#endif
>
> static struct cn_dev cdev = {
> .input = cn_rx_skb,
>
Re: [PATCH] ACPI: button: hide unused procfs helpers
sorry for noise,there has a fix:
[PATCH] acpi/button.c: fix defined but not used warning
https://lkml.org/lkml/2018/7/11/231
On 2018/7/13 15:19, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/acpi/button.c:255:12: warning: ‘acpi_button_state_seq_show’ defined
> but not used [-Wunused-function]
> static int acpi_button_state_seq_show(struct seq_file *seq, void *offset)
> ^
> fix this by adding #ifdef around it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/acpi/button.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 2345a5e..8538e25 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -252,6 +252,7 @@ static int acpi_lid_notify_state(struct acpi_device
> *device, int state)
> return ret;
> }
>
> +#ifdef CONFIG_PROC_FS
> static int acpi_button_state_seq_show(struct seq_file *seq, void *offset)
> {
> struct acpi_device *device = seq->private;
> @@ -262,6 +263,7 @@ static int acpi_button_state_seq_show(struct seq_file
> *seq, void *offset)
> state < 0 ? "unsupported" : (state ? "open" : "closed"));
> return 0;
> }
> +#endif
>
> static int acpi_button_add_fs(struct acpi_device *device)
> {
>
Re: [PATCH] ACPI: button: hide unused procfs helpers
sorry for noise,there has a fix:
[PATCH] acpi/button.c: fix defined but not used warning
https://lkml.org/lkml/2018/7/11/231
On 2018/7/13 15:19, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/acpi/button.c:255:12: warning: ‘acpi_button_state_seq_show’ defined
> but not used [-Wunused-function]
> static int acpi_button_state_seq_show(struct seq_file *seq, void *offset)
> ^
> fix this by adding #ifdef around it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/acpi/button.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 2345a5e..8538e25 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -252,6 +252,7 @@ static int acpi_lid_notify_state(struct acpi_device
> *device, int state)
> return ret;
> }
>
> +#ifdef CONFIG_PROC_FS
> static int acpi_button_state_seq_show(struct seq_file *seq, void *offset)
> {
> struct acpi_device *device = seq->private;
> @@ -262,6 +263,7 @@ static int acpi_button_state_seq_show(struct seq_file
> *seq, void *offset)
> state < 0 ? "unsupported" : (state ? "open" : "closed"));
> return 0;
> }
> +#endif
>
> static int acpi_button_add_fs(struct acpi_device *device)
> {
>
[PATCH 3/3] arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
Add initial dtsi file to support Synaptics AS370 SoC with quad
Cortex-A53 CPUs.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/synaptics/as370.dtsi | 177 +++
1 file changed, 177 insertions(+)
create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
diff --git a/arch/arm64/boot/dts/synaptics/as370.dtsi
b/arch/arm64/boot/dts/synaptics/as370.dtsi
new file mode 100644
index ..20f3d658c566
--- /dev/null
+++ b/arch/arm64/boot/dts/synaptics/as370.dtsi
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Synaptics Incorporated
+ *
+ * Author: Jisheng Zhang
+ */
+
+#include
+
+/ {
+ compatible = "syna,as370";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 =
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ l2: cache {
+ compatible = "cache";
+ };
+
+ idle-states {
+ entry-method = "psci";
+ CPU_SLEEP_0: cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ arm,psci-suspend-param = <0x001>;
+ entry-latency-us = <75>;
+ exit-latency-us = <155>;
+ min-residency-us = <1000>;
+ };
+ };
+ };
+
+ osc: osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <>,
+<>,
+<>,
+<>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ soc@f700 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0xf700 0x100>;
+
+ gic: interrupt-controller@901000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x901000 0x1000>,
+ <0x902000 0x2000>,
+ <0x904000 0x2000>,
+ <0x906000 0x2000>;
+ interrupts = ;
+ };
+
+ apb@e8 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xe8 0x1>;
+
+ uart0: uart@0c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0c00 0x100>;
+ interrupts = ;
+ clocks = <>;
+ reg-shift = <2>;
+
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > > + if (uport) > > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't > > > > > > you > > > > > > doing that? > > > > > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > > > and I get the warning I mentioned here if I use them: > > > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > > > What horrible version of gcc are you using that give you that? Don't > > > > open-code things just because of a broken compiler. > > > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > > here but not elsewhere in the file is because there's an actual > > > function call (free_page()) in the critical section. > > > > > > If we move that out, something like the below patch, it all works for > > > me. > > > > Ick. Which version of this series had the problem? Let me test it out > > here... > > v3, if you remove the initialization of flags from both functions you > should see it. Ok, I tried v3 out and yes, you are right, removing the "= 0" causes gcc to complain. The compiler is being dumb here, so I'll just leave it as-is. I've queued up the v3 version now, thanks for sticking with this. greg k-h
[PATCH 3/3] arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
Add initial dtsi file to support Synaptics AS370 SoC with quad
Cortex-A53 CPUs.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/synaptics/as370.dtsi | 177 +++
1 file changed, 177 insertions(+)
create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
diff --git a/arch/arm64/boot/dts/synaptics/as370.dtsi
b/arch/arm64/boot/dts/synaptics/as370.dtsi
new file mode 100644
index ..20f3d658c566
--- /dev/null
+++ b/arch/arm64/boot/dts/synaptics/as370.dtsi
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Synaptics Incorporated
+ *
+ * Author: Jisheng Zhang
+ */
+
+#include
+
+/ {
+ compatible = "syna,as370";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 =
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ cpu-idle-states = <_SLEEP_0>;
+ };
+
+ l2: cache {
+ compatible = "cache";
+ };
+
+ idle-states {
+ entry-method = "psci";
+ CPU_SLEEP_0: cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ arm,psci-suspend-param = <0x001>;
+ entry-latency-us = <75>;
+ exit-latency-us = <155>;
+ min-residency-us = <1000>;
+ };
+ };
+ };
+
+ osc: osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <>,
+<>,
+<>,
+<>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ soc@f700 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0xf700 0x100>;
+
+ gic: interrupt-controller@901000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x901000 0x1000>,
+ <0x902000 0x2000>,
+ <0x904000 0x2000>,
+ <0x906000 0x2000>;
+ interrupts = ;
+ };
+
+ apb@e8 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xe8 0x1>;
+
+ uart0: uart@0c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0c00 0x100>;
+ interrupts = ;
+ clocks = <>;
+ reg-shift = <2>;
+
Re: [PATCH v4] uart: fix race between uart_put_char() and uart_shutdown()
On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote: > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote: > > > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote: > > > > > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote: > > > > > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote: > > > > > > > + if (uport) > > > > > > > + spin_lock_irqsave(>lock, flags); > > > > > > > > > > > > That's the same thing as just calling uart_port_lock(), why aren't > > > > > > you > > > > > > doing that? > > > > > > > > > > Because the compiler can't seem to "see" through the macros/ref calls, > > > > > and I get the warning I mentioned here if I use them: > > > > > > > > > > https://lkml.org/lkml/2018/7/6/840 > > > > > > > > What horrible version of gcc are you using that give you that? Don't > > > > open-code things just because of a broken compiler. > > > > > > I've tried with both 7.3.0 and 5.4.0. I think the reason we see this > > > here but not elsewhere in the file is because there's an actual > > > function call (free_page()) in the critical section. > > > > > > If we move that out, something like the below patch, it all works for > > > me. > > > > Ick. Which version of this series had the problem? Let me test it out > > here... > > v3, if you remove the initialization of flags from both functions you > should see it. Ok, I tried v3 out and yes, you are right, removing the "= 0" causes gcc to complain. The compiler is being dumb here, so I'll just leave it as-is. I've queued up the v3 version now, thanks for sticking with this. greg k-h
[PATCH 2/3] dt-bindings: arm: syna: add support for the AS370 SoC
The AS370 SoC is a new derivative of the berlin family. The only difference is the SoC isn't named as berlin*. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/arm/syna.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt index 3bab18409b7a..3ba1d7b5ee74 100644 --- a/Documentation/devicetree/bindings/arm/syna.txt +++ b/Documentation/devicetree/bindings/arm/syna.txt @@ -1,4 +1,4 @@ -Marvell Berlin SoC Family Device Tree Bindings +Synaptics SoC Device Tree Bindings --- Work in progress statement: @@ -13,6 +13,10 @@ stable binding/ABI. --- +Boards with the Synaptics AS370 SoC shall have the following properties: + Required root node property: +compatible: "syna,as370" + Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500 shall have the following properties: -- 2.18.0
[PATCH 2/3] dt-bindings: arm: syna: add support for the AS370 SoC
The AS370 SoC is a new derivative of the berlin family. The only difference is the SoC isn't named as berlin*. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/arm/syna.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt index 3bab18409b7a..3ba1d7b5ee74 100644 --- a/Documentation/devicetree/bindings/arm/syna.txt +++ b/Documentation/devicetree/bindings/arm/syna.txt @@ -1,4 +1,4 @@ -Marvell Berlin SoC Family Device Tree Bindings +Synaptics SoC Device Tree Bindings --- Work in progress statement: @@ -13,6 +13,10 @@ stable binding/ABI. --- +Boards with the Synaptics AS370 SoC shall have the following properties: + Required root node property: +compatible: "syna,as370" + Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500 shall have the following properties: -- 2.18.0
Re: [PATCH] staging/rtl8192u: hide unused procfs helpers
Pls ignore this, there has a fix.
[PATCH] staging/rtl8192u: fix defined but not used build warnings
On 2018/7/13 16:01, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/staging/rtl8192u/r8192U_core.c:508:12: warning: ‘proc_get_stats_ap’
> defined but not used [-Wunused-function]
> static int proc_get_stats_ap(struct seq_file *m, void *v)
> ^
> drivers/staging/rtl8192u/r8192U_core.c:527:12: warning: ‘proc_get_registers’
> defined but not used [-Wunused-function]
> static int proc_get_registers(struct seq_file *m, void *v)
> ^
> drivers/staging/rtl8192u/r8192U_core.c:568:12: warning: ‘proc_get_stats_tx’
> defined but not used [-Wunused-function]
> static int proc_get_stats_tx(struct seq_file *m, void *v)
> ^
> drivers/staging/rtl8192u/r8192U_core.c:627:12: warning: ‘proc_get_stats_rx’
> defined but not used [-Wunused-function]
> static int proc_get_stats_rx(struct seq_file *m, void *v)
> ^
> fix this by adding #ifdef around them.
>
> Signed-off-by: YueHaibing
> ---
> drivers/staging/rtl8192u/r8192U_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 8b17400..b9724d9 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -505,6 +505,7 @@ static void watch_dog_timer_callback(struct timer_list
> *t);
>
> static struct proc_dir_entry *rtl8192_proc;
>
> +#ifdef CONFIG_PROC_FS
> static int proc_get_stats_ap(struct seq_file *m, void *v)
> {
> struct net_device *dev = m->private;
> @@ -639,6 +640,7 @@ static int proc_get_stats_rx(struct seq_file *m, void *v)
>
> return 0;
> }
> +#endif
>
> static void rtl8192_proc_module_init(void)
> {
>
Re: [PATCH] staging/rtl8192u: hide unused procfs helpers
Pls ignore this, there has a fix.
[PATCH] staging/rtl8192u: fix defined but not used build warnings
On 2018/7/13 16:01, YueHaibing wrote:
> When CONFIG_PROC_FS isn't set, gcc warning this:
>
> drivers/staging/rtl8192u/r8192U_core.c:508:12: warning: ‘proc_get_stats_ap’
> defined but not used [-Wunused-function]
> static int proc_get_stats_ap(struct seq_file *m, void *v)
> ^
> drivers/staging/rtl8192u/r8192U_core.c:527:12: warning: ‘proc_get_registers’
> defined but not used [-Wunused-function]
> static int proc_get_registers(struct seq_file *m, void *v)
> ^
> drivers/staging/rtl8192u/r8192U_core.c:568:12: warning: ‘proc_get_stats_tx’
> defined but not used [-Wunused-function]
> static int proc_get_stats_tx(struct seq_file *m, void *v)
> ^
> drivers/staging/rtl8192u/r8192U_core.c:627:12: warning: ‘proc_get_stats_rx’
> defined but not used [-Wunused-function]
> static int proc_get_stats_rx(struct seq_file *m, void *v)
> ^
> fix this by adding #ifdef around them.
>
> Signed-off-by: YueHaibing
> ---
> drivers/staging/rtl8192u/r8192U_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 8b17400..b9724d9 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -505,6 +505,7 @@ static void watch_dog_timer_callback(struct timer_list
> *t);
>
> static struct proc_dir_entry *rtl8192_proc;
>
> +#ifdef CONFIG_PROC_FS
> static int proc_get_stats_ap(struct seq_file *m, void *v)
> {
> struct net_device *dev = m->private;
> @@ -639,6 +640,7 @@ static int proc_get_stats_rx(struct seq_file *m, void *v)
>
> return 0;
> }
> +#endif
>
> static void rtl8192_proc_module_init(void)
> {
>
Re: [RESEND PATCH] tee: add kernel internal client interface
[+Sumit]
On Mon, Jul 09, 2018 at 08:15:49AM +0200, Jens Wiklander wrote:
> Adds a kernel internal TEE client interface to be used by other drivers.
>
> Signed-off-by: Jens Wiklander
> ---
> drivers/tee/tee_core.c | 113 +---
> include/linux/tee_drv.h | 73 ++
> 2 files changed, 179 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> index dd46b758852a..7b2bb4c50058 100644
> --- a/drivers/tee/tee_core.c
> +++ b/drivers/tee/tee_core.c
> @@ -38,15 +38,13 @@ static DEFINE_SPINLOCK(driver_lock);
> static struct class *tee_class;
> static dev_t tee_devt;
>
> -static int tee_open(struct inode *inode, struct file *filp)
> +static struct tee_context *teedev_open(struct tee_device *teedev)
> {
> int rc;
> - struct tee_device *teedev;
> struct tee_context *ctx;
>
> - teedev = container_of(inode->i_cdev, struct tee_device, cdev);
> if (!tee_device_get(teedev))
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
>
> ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> if (!ctx) {
> @@ -57,16 +55,16 @@ static int tee_open(struct inode *inode, struct file
> *filp)
> kref_init(>refcount);
> ctx->teedev = teedev;
> INIT_LIST_HEAD(>list_shm);
> - filp->private_data = ctx;
> rc = teedev->desc->ops->open(ctx);
> if (rc)
> goto err;
>
> - return 0;
> + return ctx;
> err:
> kfree(ctx);
> tee_device_put(teedev);
> - return rc;
> + return ERR_PTR(rc);
> +
> }
>
> void teedev_ctx_get(struct tee_context *ctx)
> @@ -100,6 +98,18 @@ static void teedev_close_context(struct tee_context *ctx)
> teedev_ctx_put(ctx);
> }
>
> +static int tee_open(struct inode *inode, struct file *filp)
> +{
> + struct tee_context *ctx;
> +
> + ctx = teedev_open(container_of(inode->i_cdev, struct tee_device, cdev));
> + if (IS_ERR(ctx))
> + return PTR_ERR(ctx);
> +
> + filp->private_data = ctx;
> + return 0;
> +}
> +
> static int tee_release(struct inode *inode, struct file *filp)
> {
> teedev_close_context(filp->private_data);
> @@ -928,6 +938,95 @@ void *tee_get_drvdata(struct tee_device *teedev)
> }
> EXPORT_SYMBOL_GPL(tee_get_drvdata);
>
> +struct match_dev_data {
> + struct tee_ioctl_version_data *vers;
> + const void *data;
> + int (*match)(struct tee_ioctl_version_data *, const void *);
> +};
> +
> +static int match_dev(struct device *dev, const void *data)
> +{
> + const struct match_dev_data *match_data = data;
> + struct tee_device *teedev = container_of(dev, struct tee_device, dev);
> +
> + teedev->desc->ops->get_version(teedev, match_data->vers);
> + return match_data->match(match_data->vers, match_data->data);
> +}
> +
> +struct tee_context *
> +tee_client_open_context(struct tee_context *start,
> + int (*match)(struct tee_ioctl_version_data *,
> + const void *),
> + const void *data, struct tee_ioctl_version_data *vers)
> +{
> + struct device *dev = NULL;
> + struct device *put_dev = NULL;
> + struct tee_context *ctx = NULL;
> + struct tee_ioctl_version_data v;
> + struct match_dev_data match_data = { vers ? vers : , data, match };
> +
> + if (start)
> + dev = >teedev->dev;
> +
> + do {
> + dev = class_find_device(tee_class, dev, _data, match_dev);
> + if (!dev) {
> + ctx = ERR_PTR(-ENOENT);
> + break;
> + }
> +
> + put_device(put_dev);
> + put_dev = dev;
> +
> + ctx = teedev_open(container_of(dev, struct tee_device, dev));
> + } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM);
> +
> + put_device(put_dev);
> + return ctx;
> +}
> +EXPORT_SYMBOL_GPL(tee_client_open_context);
> +
> +void tee_client_close_context(struct tee_context *ctx)
> +{
> + teedev_close_context(ctx);
> +}
> +EXPORT_SYMBOL_GPL(tee_client_close_context);
> +
> +void tee_client_get_version(struct tee_context *ctx,
> + struct tee_ioctl_version_data *vers)
> +{
> + ctx->teedev->desc->ops->get_version(ctx->teedev, vers);
> +}
> +EXPORT_SYMBOL_GPL(tee_client_get_version);
> +
> +int tee_client_open_session(struct tee_context *ctx,
> + struct tee_ioctl_open_session_arg *arg,
> + struct tee_param *param)
> +{
> + if (!ctx->teedev->desc->ops->open_session)
> + return -EINVAL;
> + return ctx->teedev->desc->ops->open_session(ctx, arg, param);
> +}
> +EXPORT_SYMBOL_GPL(tee_client_open_session);
> +
> +int tee_client_close_session(struct tee_context *ctx, u32 session)
> +{
> + if (!ctx->teedev->desc->ops->close_session)
> + return -EINVAL;
> + return ctx->teedev->desc->ops->close_session(ctx, session);
> +}
>
Re: [RESEND PATCH] tee: add kernel internal client interface
[+Sumit]
On Mon, Jul 09, 2018 at 08:15:49AM +0200, Jens Wiklander wrote:
> Adds a kernel internal TEE client interface to be used by other drivers.
>
> Signed-off-by: Jens Wiklander
> ---
> drivers/tee/tee_core.c | 113 +---
> include/linux/tee_drv.h | 73 ++
> 2 files changed, 179 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> index dd46b758852a..7b2bb4c50058 100644
> --- a/drivers/tee/tee_core.c
> +++ b/drivers/tee/tee_core.c
> @@ -38,15 +38,13 @@ static DEFINE_SPINLOCK(driver_lock);
> static struct class *tee_class;
> static dev_t tee_devt;
>
> -static int tee_open(struct inode *inode, struct file *filp)
> +static struct tee_context *teedev_open(struct tee_device *teedev)
> {
> int rc;
> - struct tee_device *teedev;
> struct tee_context *ctx;
>
> - teedev = container_of(inode->i_cdev, struct tee_device, cdev);
> if (!tee_device_get(teedev))
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
>
> ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> if (!ctx) {
> @@ -57,16 +55,16 @@ static int tee_open(struct inode *inode, struct file
> *filp)
> kref_init(>refcount);
> ctx->teedev = teedev;
> INIT_LIST_HEAD(>list_shm);
> - filp->private_data = ctx;
> rc = teedev->desc->ops->open(ctx);
> if (rc)
> goto err;
>
> - return 0;
> + return ctx;
> err:
> kfree(ctx);
> tee_device_put(teedev);
> - return rc;
> + return ERR_PTR(rc);
> +
> }
>
> void teedev_ctx_get(struct tee_context *ctx)
> @@ -100,6 +98,18 @@ static void teedev_close_context(struct tee_context *ctx)
> teedev_ctx_put(ctx);
> }
>
> +static int tee_open(struct inode *inode, struct file *filp)
> +{
> + struct tee_context *ctx;
> +
> + ctx = teedev_open(container_of(inode->i_cdev, struct tee_device, cdev));
> + if (IS_ERR(ctx))
> + return PTR_ERR(ctx);
> +
> + filp->private_data = ctx;
> + return 0;
> +}
> +
> static int tee_release(struct inode *inode, struct file *filp)
> {
> teedev_close_context(filp->private_data);
> @@ -928,6 +938,95 @@ void *tee_get_drvdata(struct tee_device *teedev)
> }
> EXPORT_SYMBOL_GPL(tee_get_drvdata);
>
> +struct match_dev_data {
> + struct tee_ioctl_version_data *vers;
> + const void *data;
> + int (*match)(struct tee_ioctl_version_data *, const void *);
> +};
> +
> +static int match_dev(struct device *dev, const void *data)
> +{
> + const struct match_dev_data *match_data = data;
> + struct tee_device *teedev = container_of(dev, struct tee_device, dev);
> +
> + teedev->desc->ops->get_version(teedev, match_data->vers);
> + return match_data->match(match_data->vers, match_data->data);
> +}
> +
> +struct tee_context *
> +tee_client_open_context(struct tee_context *start,
> + int (*match)(struct tee_ioctl_version_data *,
> + const void *),
> + const void *data, struct tee_ioctl_version_data *vers)
> +{
> + struct device *dev = NULL;
> + struct device *put_dev = NULL;
> + struct tee_context *ctx = NULL;
> + struct tee_ioctl_version_data v;
> + struct match_dev_data match_data = { vers ? vers : , data, match };
> +
> + if (start)
> + dev = >teedev->dev;
> +
> + do {
> + dev = class_find_device(tee_class, dev, _data, match_dev);
> + if (!dev) {
> + ctx = ERR_PTR(-ENOENT);
> + break;
> + }
> +
> + put_device(put_dev);
> + put_dev = dev;
> +
> + ctx = teedev_open(container_of(dev, struct tee_device, dev));
> + } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM);
> +
> + put_device(put_dev);
> + return ctx;
> +}
> +EXPORT_SYMBOL_GPL(tee_client_open_context);
> +
> +void tee_client_close_context(struct tee_context *ctx)
> +{
> + teedev_close_context(ctx);
> +}
> +EXPORT_SYMBOL_GPL(tee_client_close_context);
> +
> +void tee_client_get_version(struct tee_context *ctx,
> + struct tee_ioctl_version_data *vers)
> +{
> + ctx->teedev->desc->ops->get_version(ctx->teedev, vers);
> +}
> +EXPORT_SYMBOL_GPL(tee_client_get_version);
> +
> +int tee_client_open_session(struct tee_context *ctx,
> + struct tee_ioctl_open_session_arg *arg,
> + struct tee_param *param)
> +{
> + if (!ctx->teedev->desc->ops->open_session)
> + return -EINVAL;
> + return ctx->teedev->desc->ops->open_session(ctx, arg, param);
> +}
> +EXPORT_SYMBOL_GPL(tee_client_open_session);
> +
> +int tee_client_close_session(struct tee_context *ctx, u32 session)
> +{
> + if (!ctx->teedev->desc->ops->close_session)
> + return -EINVAL;
> + return ctx->teedev->desc->ops->close_session(ctx, session);
> +}
>
Re: [PATCH 08/10] psi: pressure stall information for CPU, memory, and IO
On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> +static inline void psi_ttwu_dequeue(struct task_struct *p)
> +{
> + if (psi_disabled)
> + return;
> + /*
> + * Is the task being migrated during a wakeup? Make sure to
> + * deregister its sleep-persistent psi states from the old
> + * queue, and let psi_enqueue() know it has to requeue.
> + */
> + if (unlikely(p->in_iowait || (p->flags & PF_MEMSTALL))) {
> + struct rq_flags rf;
> + struct rq *rq;
> + int clear = 0;
> +
> + if (p->in_iowait)
> + clear |= TSK_IOWAIT;
> + if (p->flags & PF_MEMSTALL)
> + clear |= TSK_MEMSTALL;
> +
> + rq = __task_rq_lock(p, );
> + update_rq_clock(rq);
> + psi_task_change(p, rq_clock(rq), clear, 0);
> + p->sched_psi_wake_requeue = 1;
> + __task_rq_unlock(rq, );
> + }
> +}
Still NAK, what happened to this here:
https://lkml.kernel.org/r/20180514083353.gn12...@hirez.programming.kicks-ass.net
Re: [PATCH 08/10] psi: pressure stall information for CPU, memory, and IO
On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> +static inline void psi_ttwu_dequeue(struct task_struct *p)
> +{
> + if (psi_disabled)
> + return;
> + /*
> + * Is the task being migrated during a wakeup? Make sure to
> + * deregister its sleep-persistent psi states from the old
> + * queue, and let psi_enqueue() know it has to requeue.
> + */
> + if (unlikely(p->in_iowait || (p->flags & PF_MEMSTALL))) {
> + struct rq_flags rf;
> + struct rq *rq;
> + int clear = 0;
> +
> + if (p->in_iowait)
> + clear |= TSK_IOWAIT;
> + if (p->flags & PF_MEMSTALL)
> + clear |= TSK_MEMSTALL;
> +
> + rq = __task_rq_lock(p, );
> + update_rq_clock(rq);
> + psi_task_change(p, rq_clock(rq), clear, 0);
> + p->sched_psi_wake_requeue = 1;
> + __task_rq_unlock(rq, );
> + }
> +}
Still NAK, what happened to this here:
https://lkml.kernel.org/r/20180514083353.gn12...@hirez.programming.kicks-ass.net
[PATCH 1/3] dt-bindings: arm: move berlin binding documentation to syna.txt
Move berlin binding documentation as part of transition from Marvell
berlin to Synaptics SoC.
Signed-off-by: Jisheng Zhang
---
.../bindings/arm/{marvell/marvell,berlin.txt => syna.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/arm/{marvell/marvell,berlin.txt =>
syna.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
b/Documentation/devicetree/bindings/arm/syna.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
rename to Documentation/devicetree/bindings/arm/syna.txt
--
2.18.0
[PATCH 1/3] dt-bindings: arm: move berlin binding documentation to syna.txt
Move berlin binding documentation as part of transition from Marvell
berlin to Synaptics SoC.
Signed-off-by: Jisheng Zhang
---
.../bindings/arm/{marvell/marvell,berlin.txt => syna.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/arm/{marvell/marvell,berlin.txt =>
syna.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
b/Documentation/devicetree/bindings/arm/syna.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
rename to Documentation/devicetree/bindings/arm/syna.txt
--
2.18.0
[PATCH 0/3] arm64: dts: add Synaptics AS370 SoC support
Add initial dtsi file for Synaptics AS370 SoC.
patch1 moves berlin binding to syna.txt.
patch2 add dt-binding for the AS370 SoC.
patch3 add the initial dtsi file for the SoC.
Jisheng Zhang (3):
dt-bindings: arm: move berlin binding documentation to syna.txt
dt-bindings: arm: syna: add support for the AS370 SoC
arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
.../{marvell/marvell,berlin.txt => syna.txt} | 6 +-
arch/arm64/boot/dts/synaptics/as370.dtsi | 177 ++
2 files changed, 182 insertions(+), 1 deletion(-)
rename Documentation/devicetree/bindings/arm/{marvell/marvell,berlin.txt =>
syna.txt} (94%)
create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
--
2.18.0
[PATCH 0/3] arm64: dts: add Synaptics AS370 SoC support
Add initial dtsi file for Synaptics AS370 SoC.
patch1 moves berlin binding to syna.txt.
patch2 add dt-binding for the AS370 SoC.
patch3 add the initial dtsi file for the SoC.
Jisheng Zhang (3):
dt-bindings: arm: move berlin binding documentation to syna.txt
dt-bindings: arm: syna: add support for the AS370 SoC
arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
.../{marvell/marvell,berlin.txt => syna.txt} | 6 +-
arch/arm64/boot/dts/synaptics/as370.dtsi | 177 ++
2 files changed, 182 insertions(+), 1 deletion(-)
rename Documentation/devicetree/bindings/arm/{marvell/marvell,berlin.txt =>
syna.txt} (94%)
create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
--
2.18.0
[PATCH] ext4: fix warning message to output correct type.
Output the warning message before we clobber type and be -1 all the time.
The error message would now be
[1.519791] EXT4-fs warning (device vdb): ext4_enable_quotas:5402:
Failed to enable quota tracking (type=0, err=-3). Please run e2fsck to fix.
Signed-off-by: Junichi Uekawa
---
fs/ext4/super.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ba2396a7bd04..1b90f619663c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5670,13 +5670,13 @@ static int ext4_enable_quotas(struct super_block *sb)
DQUOT_USAGE_ENABLED |
(quota_mopt[type] ? DQUOT_LIMITS_ENABLED : 0));
if (err) {
- for (type--; type >= 0; type--)
- dquot_quota_off(sb, type);
-
ext4_warning(sb,
"Failed to enable quota tracking "
"(type=%d, err=%d). Please run "
"e2fsck to fix.", type, err);
+ for (type--; type >= 0; type--)
+ dquot_quota_off(sb, type);
+
return err;
}
}
--
2.18.0.203.gfac676dfb9-goog
[PATCH] ext4: fix warning message to output correct type.
Output the warning message before we clobber type and be -1 all the time.
The error message would now be
[1.519791] EXT4-fs warning (device vdb): ext4_enable_quotas:5402:
Failed to enable quota tracking (type=0, err=-3). Please run e2fsck to fix.
Signed-off-by: Junichi Uekawa
---
fs/ext4/super.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ba2396a7bd04..1b90f619663c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5670,13 +5670,13 @@ static int ext4_enable_quotas(struct super_block *sb)
DQUOT_USAGE_ENABLED |
(quota_mopt[type] ? DQUOT_LIMITS_ENABLED : 0));
if (err) {
- for (type--; type >= 0; type--)
- dquot_quota_off(sb, type);
-
ext4_warning(sb,
"Failed to enable quota tracking "
"(type=%d, err=%d). Please run "
"e2fsck to fix.", type, err);
+ for (type--; type >= 0; type--)
+ dquot_quota_off(sb, type);
+
return err;
}
}
--
2.18.0.203.gfac676dfb9-goog
Re: [RFC PATCH v2 2/2] ata: ahci: Enable DEVSLP by default on x86 with SLP_S0
Hi,
On 13-07-18 00:27, Srinivas Pandruvada wrote:
From: Srinivas
One of the requirement for modern x86 system to enter lowest power mode
(SLP_S0) is SATA IP block to be off. This is true even during when
platform is suspended to idle and not only in opportunistic (runtime)
suspend.
Several of these system don't have traditional ACPI S3, so it is
important that they enter SLP_S0 state, to avoid draining battery even
during suspend. So it is important that out of the box Linux installation
reach this state.
SATA IP block doesn't get turned off till SATA is in DEVSLP mode. Here
user has to either use scsi-host sysfs or tools like powertop to set
the sata-host link_power_management_policy to min_power.
This change sets by default link power management policy to min_power
with partial (preferred) or slumber support on idle for some platforms.
To avoid regressions, the following conditions are used:
- The kernel config is already set to use med_power_with_dipm or deeper
- System is a SLP_S0 capable using ACPI low power idle flag
This combination will make sure that systems are fairly recent and
since getting shipped with SLP_S0 support, the DEVSLP function
is already validated.
Signed-off-by: Srinivas Pandruvada
---
drivers/ata/ahci.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index b2b9eba1d214..e8d425823f9b 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1604,6 +1604,19 @@ static int ahci_init_msi(struct pci_dev *pdev, unsigned
int n_ports,
return pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX);
}
+static void ahci_update_mobile_policy(struct ahci_host_priv *hpriv)
+{
+#ifdef CONFIG_ACPI
+ if (mobile_lpm_policy > ATA_LPM_MED_POWER &&
+ (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)) {
+ if (hpriv->cap & HOST_CAP_PART)
+ mobile_lpm_policy = ATA_LPM_MIN_POWER_WITH_ASP;
+ else if (hpriv->cap & HOST_CAP_SSC)
+ mobile_lpm_policy = ATA_LPM_MIN_POWER;
You are checking hpriv flags here and changing global state based on that.
Instead it would be better to add a new:
int ahci_get_initial_lpm_policy(struct ahci_host_priv *hpriv);
Function and replace this:
if ((hpriv->flags & AHCI_HFLAG_IS_MOBILE) &&
mobile_lpm_policy >= ATA_LPM_UNKNOWN &&
mobile_lpm_policy <= ATA_LPM_MIN_POWER)
ap->target_lpm_policy = mobile_lpm_policy;
With:
ap->target_lpm_policy = ahci_get_initial_lpm_policy(priv);
And do the original checks + your new checks all in the
ahci_get_initial_lpm_policy() function.
Regards,
Hans
+ }
+#endif
+}
+
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
unsigned int board_id = ent->driver_data;
@@ -1796,6 +1809,8 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (pi.flags & ATA_FLAG_EM)
ahci_reset_em(host);
+ ahci_update_mobile_policy(hpriv);
+
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap = host->ports[i];
Re: [RFC PATCH v2 2/2] ata: ahci: Enable DEVSLP by default on x86 with SLP_S0
Hi,
On 13-07-18 00:27, Srinivas Pandruvada wrote:
From: Srinivas
One of the requirement for modern x86 system to enter lowest power mode
(SLP_S0) is SATA IP block to be off. This is true even during when
platform is suspended to idle and not only in opportunistic (runtime)
suspend.
Several of these system don't have traditional ACPI S3, so it is
important that they enter SLP_S0 state, to avoid draining battery even
during suspend. So it is important that out of the box Linux installation
reach this state.
SATA IP block doesn't get turned off till SATA is in DEVSLP mode. Here
user has to either use scsi-host sysfs or tools like powertop to set
the sata-host link_power_management_policy to min_power.
This change sets by default link power management policy to min_power
with partial (preferred) or slumber support on idle for some platforms.
To avoid regressions, the following conditions are used:
- The kernel config is already set to use med_power_with_dipm or deeper
- System is a SLP_S0 capable using ACPI low power idle flag
This combination will make sure that systems are fairly recent and
since getting shipped with SLP_S0 support, the DEVSLP function
is already validated.
Signed-off-by: Srinivas Pandruvada
---
drivers/ata/ahci.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index b2b9eba1d214..e8d425823f9b 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1604,6 +1604,19 @@ static int ahci_init_msi(struct pci_dev *pdev, unsigned
int n_ports,
return pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX);
}
+static void ahci_update_mobile_policy(struct ahci_host_priv *hpriv)
+{
+#ifdef CONFIG_ACPI
+ if (mobile_lpm_policy > ATA_LPM_MED_POWER &&
+ (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)) {
+ if (hpriv->cap & HOST_CAP_PART)
+ mobile_lpm_policy = ATA_LPM_MIN_POWER_WITH_ASP;
+ else if (hpriv->cap & HOST_CAP_SSC)
+ mobile_lpm_policy = ATA_LPM_MIN_POWER;
You are checking hpriv flags here and changing global state based on that.
Instead it would be better to add a new:
int ahci_get_initial_lpm_policy(struct ahci_host_priv *hpriv);
Function and replace this:
if ((hpriv->flags & AHCI_HFLAG_IS_MOBILE) &&
mobile_lpm_policy >= ATA_LPM_UNKNOWN &&
mobile_lpm_policy <= ATA_LPM_MIN_POWER)
ap->target_lpm_policy = mobile_lpm_policy;
With:
ap->target_lpm_policy = ahci_get_initial_lpm_policy(priv);
And do the original checks + your new checks all in the
ahci_get_initial_lpm_policy() function.
Regards,
Hans
+ }
+#endif
+}
+
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
unsigned int board_id = ent->driver_data;
@@ -1796,6 +1809,8 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (pi.flags & ATA_FLAG_EM)
ahci_reset_em(host);
+ ahci_update_mobile_policy(hpriv);
+
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap = host->ports[i];
Re: [PATCH v13 14/18] x86/tsc: initialize cyc2ns when tsc freq. is determined
At 07/12/2018 08:04 AM, Pavel Tatashin wrote:
cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data
structure.
Currently, the setup code for c2ns data for every possible CPU goes through
the same sequence of calculations as for the boot CPU, but is based on the
same tsc frequency as the boot CPU, and thus this is not necessary.
Initialize the boot cpu when tsc frequency is determined. Copy the
calculated data from the boot CPU to the other CPUs in tsc_init().
In addition do the following:
- Remove unnecessary zeroing of c2ns data by removing cyc2ns_data_init()
- Split set_cyc2ns_scale() into two functions, so set_cyc2ns_scale() can be
called when system is up, and wraps around __set_cyc2ns_scale() that can
be called directly when system is booting but avoids saving restoring
IRQs and going and waking up from idle.
Suggested-by: Thomas Gleixner
Signed-off-by: Pavel Tatashin
---
arch/x86/kernel/tsc.c | 94 ---
1 file changed, 53 insertions(+), 41 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index bc8eb82050a3..0b1abe7fdd8e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -103,23 +103,6 @@ void cyc2ns_read_end(void)
* -johns...@us.ibm.com "math is hard, lets go shopping!"
*/
-static void cyc2ns_data_init(struct cyc2ns_data *data)
-{
- data->cyc2ns_mul = 0;
- data->cyc2ns_shift = 0;
- data->cyc2ns_offset = 0;
-}
-
-static void __init cyc2ns_init(int cpu)
-{
- struct cyc2ns *c2n = _cpu(cyc2ns, cpu);
-
- cyc2ns_data_init(>data[0]);
- cyc2ns_data_init(>data[1]);
-
- seqcount_init(>seq);
-}
-
static inline unsigned long long cycles_2_ns(unsigned long long cyc)
{
struct cyc2ns_data data;
@@ -135,18 +118,11 @@ static inline unsigned long long cycles_2_ns(unsigned
long long cyc)
return ns;
}
-static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_now)
+static void __set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long
tsc_now)
{
unsigned long long ns_now;
struct cyc2ns_data data;
struct cyc2ns *c2n;
- unsigned long flags;
-
- local_irq_save(flags);
- sched_clock_idle_sleep_event();
-
- if (!khz)
- goto done;
ns_now = cycles_2_ns(tsc_now);
@@ -178,12 +154,55 @@ static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_
c2n->data[0] = data;
raw_write_seqcount_latch(>seq);
c2n->data[1] = data;
+}
+
+static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long
tsc_now)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ sched_clock_idle_sleep_event();
+
+ if (khz)
+ __set_cyc2ns_scale(khz, cpu, tsc_now);
-done:
sched_clock_idle_wakeup_event();
local_irq_restore(flags);
} >
+/*
+ * Initialize cyc2ns for boot cpu
+ */
+static void __init cyc2ns_init_boot_cpu(void)
+{
+ struct cyc2ns *c2n = this_cpu_ptr();
+
+ seqcount_init(>seq);
+ __set_cyc2ns_scale(tsc_khz, smp_processor_id(), rdtsc());
+}
Hi Paval,
Here we didn't protect it with local_irq_save()/local_irq_restore()
+
+/*
+ * Secondary CPUs do not run through cyc2ns_init(), so set up
+ * all the scale factors for all CPUs, assuming the same
+ * speed as the bootup CPU. (cpufreq notifiers will fix this
+ * up if their speed diverges)
+ */
+static void __init cyc2ns_init_secondary_cpus(void)
+{
+ unsigned int cpu, this_cpu = smp_processor_id();
+ struct cyc2ns *c2n = this_cpu_ptr();
+ struct cyc2ns_data *data = c2n->data;
+
+ for_each_possible_cpu(cpu) {
+ if (cpu != this_cpu) {
+ seqcount_init(>seq);
+ c2n = per_cpu_ptr(, cpu);
+ c2n->data[0] = data[0];
+ c2n->data[1] = data[1];
+ }
+ }
+}
+
/*
* Scheduler clock - returns current time in nanosec units.
*/
@@ -1385,6 +1404,10 @@ void __init tsc_early_init(void)
if (!determine_cpu_tsc_frequncies())
return;
loops_per_jiffy = get_loops_per_jiffy();
+
+ /* Sanitize TSC ADJUST before cyc2ns gets initialized */
+ tsc_store_and_check_tsc_adjust(true);
+ cyc2ns_init_boot_cpu();
}
void __init tsc_init(void)
@@ -1400,23 +1423,12 @@ void __init tsc_init(void)
mark_tsc_unstable("could not calculate TSC khz");
return;
}
+ /* Sanitize TSC ADJUST before cyc2ns gets initialized */
+ tsc_store_and_check_tsc_adjust(true);
+ cyc2ns_init_boot_cpu();
In tsc_init(), the timer interrupt has worked, Is that OK?
IMO, no need to change so much, just use the original code,
eg:
+static void __init cyc2ns_init_bsp(void)
+{
+ cyc2ns_init(0);
+
Re: [PATCH v13 14/18] x86/tsc: initialize cyc2ns when tsc freq. is determined
At 07/12/2018 08:04 AM, Pavel Tatashin wrote:
cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data
structure.
Currently, the setup code for c2ns data for every possible CPU goes through
the same sequence of calculations as for the boot CPU, but is based on the
same tsc frequency as the boot CPU, and thus this is not necessary.
Initialize the boot cpu when tsc frequency is determined. Copy the
calculated data from the boot CPU to the other CPUs in tsc_init().
In addition do the following:
- Remove unnecessary zeroing of c2ns data by removing cyc2ns_data_init()
- Split set_cyc2ns_scale() into two functions, so set_cyc2ns_scale() can be
called when system is up, and wraps around __set_cyc2ns_scale() that can
be called directly when system is booting but avoids saving restoring
IRQs and going and waking up from idle.
Suggested-by: Thomas Gleixner
Signed-off-by: Pavel Tatashin
---
arch/x86/kernel/tsc.c | 94 ---
1 file changed, 53 insertions(+), 41 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index bc8eb82050a3..0b1abe7fdd8e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -103,23 +103,6 @@ void cyc2ns_read_end(void)
* -johns...@us.ibm.com "math is hard, lets go shopping!"
*/
-static void cyc2ns_data_init(struct cyc2ns_data *data)
-{
- data->cyc2ns_mul = 0;
- data->cyc2ns_shift = 0;
- data->cyc2ns_offset = 0;
-}
-
-static void __init cyc2ns_init(int cpu)
-{
- struct cyc2ns *c2n = _cpu(cyc2ns, cpu);
-
- cyc2ns_data_init(>data[0]);
- cyc2ns_data_init(>data[1]);
-
- seqcount_init(>seq);
-}
-
static inline unsigned long long cycles_2_ns(unsigned long long cyc)
{
struct cyc2ns_data data;
@@ -135,18 +118,11 @@ static inline unsigned long long cycles_2_ns(unsigned
long long cyc)
return ns;
}
-static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_now)
+static void __set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long
tsc_now)
{
unsigned long long ns_now;
struct cyc2ns_data data;
struct cyc2ns *c2n;
- unsigned long flags;
-
- local_irq_save(flags);
- sched_clock_idle_sleep_event();
-
- if (!khz)
- goto done;
ns_now = cycles_2_ns(tsc_now);
@@ -178,12 +154,55 @@ static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_
c2n->data[0] = data;
raw_write_seqcount_latch(>seq);
c2n->data[1] = data;
+}
+
+static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long
tsc_now)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ sched_clock_idle_sleep_event();
+
+ if (khz)
+ __set_cyc2ns_scale(khz, cpu, tsc_now);
-done:
sched_clock_idle_wakeup_event();
local_irq_restore(flags);
} >
+/*
+ * Initialize cyc2ns for boot cpu
+ */
+static void __init cyc2ns_init_boot_cpu(void)
+{
+ struct cyc2ns *c2n = this_cpu_ptr();
+
+ seqcount_init(>seq);
+ __set_cyc2ns_scale(tsc_khz, smp_processor_id(), rdtsc());
+}
Hi Paval,
Here we didn't protect it with local_irq_save()/local_irq_restore()
+
+/*
+ * Secondary CPUs do not run through cyc2ns_init(), so set up
+ * all the scale factors for all CPUs, assuming the same
+ * speed as the bootup CPU. (cpufreq notifiers will fix this
+ * up if their speed diverges)
+ */
+static void __init cyc2ns_init_secondary_cpus(void)
+{
+ unsigned int cpu, this_cpu = smp_processor_id();
+ struct cyc2ns *c2n = this_cpu_ptr();
+ struct cyc2ns_data *data = c2n->data;
+
+ for_each_possible_cpu(cpu) {
+ if (cpu != this_cpu) {
+ seqcount_init(>seq);
+ c2n = per_cpu_ptr(, cpu);
+ c2n->data[0] = data[0];
+ c2n->data[1] = data[1];
+ }
+ }
+}
+
/*
* Scheduler clock - returns current time in nanosec units.
*/
@@ -1385,6 +1404,10 @@ void __init tsc_early_init(void)
if (!determine_cpu_tsc_frequncies())
return;
loops_per_jiffy = get_loops_per_jiffy();
+
+ /* Sanitize TSC ADJUST before cyc2ns gets initialized */
+ tsc_store_and_check_tsc_adjust(true);
+ cyc2ns_init_boot_cpu();
}
void __init tsc_init(void)
@@ -1400,23 +1423,12 @@ void __init tsc_init(void)
mark_tsc_unstable("could not calculate TSC khz");
return;
}
+ /* Sanitize TSC ADJUST before cyc2ns gets initialized */
+ tsc_store_and_check_tsc_adjust(true);
+ cyc2ns_init_boot_cpu();
In tsc_init(), the timer interrupt has worked, Is that OK?
IMO, no need to change so much, just use the original code,
eg:
+static void __init cyc2ns_init_bsp(void)
+{
+ cyc2ns_init(0);
+
Re: [PATCH v5 5/5] mm/sparse: delete old sprase_init and enable new one
> -#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
> -static void __init sparse_early_mem_maps_alloc_node(void *data,
> - unsigned long pnum_begin,
> - unsigned long pnum_end,
> - unsigned long map_count, int nodeid)
> -{
> - struct page **map_map = (struct page **)data;
> -
> - sparse_buffer_init(section_map_size() * map_count, nodeid);
> - sparse_mem_maps_populate_node(map_map, pnum_begin, pnum_end,
> - map_count, nodeid);
> - sparse_buffer_fini();
> -}
>From now on, sparse_mem_maps_populate_node() is not being used anymore, so I
>guess we can just
remove it from sparse.c, right? (as it is done in sparse-vmemmap.c).
--
Oscar Salvador
SUSE L3
Re: [PATCH v5 5/5] mm/sparse: delete old sprase_init and enable new one
> -#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
> -static void __init sparse_early_mem_maps_alloc_node(void *data,
> - unsigned long pnum_begin,
> - unsigned long pnum_end,
> - unsigned long map_count, int nodeid)
> -{
> - struct page **map_map = (struct page **)data;
> -
> - sparse_buffer_init(section_map_size() * map_count, nodeid);
> - sparse_mem_maps_populate_node(map_map, pnum_begin, pnum_end,
> - map_count, nodeid);
> - sparse_buffer_fini();
> -}
>From now on, sparse_mem_maps_populate_node() is not being used anymore, so I
>guess we can just
remove it from sparse.c, right? (as it is done in sparse-vmemmap.c).
--
Oscar Salvador
SUSE L3
