Re: [RFC PATCH 2/9] cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem based qcom socs
Hi Niklas,
On 4/4/2019 10:39 AM, Niklas Cassel wrote:
> From: Sricharan R
>
> The kryo cpufreq driver reads the nvmem cell and uses that data to
> populate the opps. There are other qcom cpufreq socs like krait which
> does similar thing. Except for the interpretation of the read data,
> rest of the driver is same for both the cases. So pull the common things
> out for reuse.
>
> Signed-off-by: Sricharan R
> Signed-off-by: Niklas Cassel
> ---
Thanks for reposting this patch again. Sorry, got completely lost track
on this. Please let me know if you are planning to rework etc or anything
you need from me on this.
Regards,
Sricharan
> ...ryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} | 16 +--
> drivers/cpufreq/Kconfig.arm | 4 +-
> drivers/cpufreq/Makefile | 2 +-
> ...om-cpufreq-kryo.c => qcom-cpufreq-nvmem.c} | 124 +++---
> 4 files changed, 85 insertions(+), 61 deletions(-)
> rename Documentation/devicetree/bindings/opp/{kryo-cpufreq.txt =>
> qcom-nvmem-cpufreq.txt} (97%)
> rename drivers/cpufreq/{qcom-cpufreq-kryo.c => qcom-cpufreq-nvmem.c} (69%)
>
> diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
> b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
> similarity index 97%
> rename from Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
> rename to Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
> index c2127b96805a..f4a7123730c3 100644
> --- a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
> +++ b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
> @@ -1,13 +1,13 @@
> -Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
> +Qualcomm Technologies, Inc. NVMEM CPUFreq and OPP bindings
> ===
>
> -In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
> -that have KRYO processors, the CPU ferequencies subset and voltage value
> -of each OPP varies based on the silicon variant in use.
> +In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996,
> +the CPU frequencies subset and voltage value of each OPP varies based on
> +the silicon variant in use.
> Qualcomm Technologies, Inc. Process Voltage Scaling Tables
> defines the voltage and frequency value based on the msm-id in SMEM
> and speedbin blown in the efuse combination.
> -The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
> +The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC
> to provide the OPP framework with required information (existing HW bitmap).
> This is used to determine the voltage and frequency value for each OPP of
> operating-points-v2 table when it is parsed by the OPP framework.
> @@ -19,7 +19,7 @@ In 'cpus' nodes:
>
> In 'operating-points-v2' table:
> - compatible: Should be
> - - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
> + - 'operating-points-v2-qcom-cpu' for apq8096 and msm8996.
> - nvmem-cells: A phandle pointing to a nvmem-cells node representing the
> efuse registers that has information about the
> speedbin that is used to select the right frequency/voltage
> @@ -127,7 +127,7 @@ Example 1:
> };
>
> cluster0_opp: opp_table0 {
> - compatible = "operating-points-v2-kryo-cpu";
> + compatible = "operating-points-v2-qcom-cpu";
> nvmem-cells = <&speedbin_efuse>;
> opp-shared;
>
> @@ -338,7 +338,7 @@ Example 1:
> };
>
> cluster1_opp: opp_table1 {
> - compatible = "operating-points-v2-kryo-cpu";
> + compatible = "operating-points-v2-qcom-cpu";
> nvmem-cells = <&speedbin_efuse>;
> opp-shared;
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 179a1d302f48..2e4aefa0f34d 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -110,8 +110,8 @@ config ARM_OMAP2PLUS_CPUFREQ
> depends on ARCH_OMAP2PLUS
> default ARCH_OMAP2PLUS
>
> -config ARM_QCOM_CPUFREQ_KRYO
> - tristate "Qualcomm Kryo based CPUFreq"
> +config ARM_QCOM_CPUFREQ_NVMEM
> + tristate "Qualcomm nvmem based CPUFreq"
> depends on ARM64
> depends on QCOM_QFPROM
> depends on QCOM_SMEM
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 689b26c6f949..8e83fd73bd2d 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -63,7 +63,7 @@ obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
> obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
> obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)+= qcom-cpufreq-hw.o
> -obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
> +obj-$(CONFIG_ARM_QCOM_CPUFREQ_NVMEM) += qcom-cpufreq-nvmem.o
> obj-$(CONFIG_ARM_S3C2410_CPUFREQ)+= s3c2410-cpufreq.o
> obj-$(CONFIG_ARM_S3C2412_CPUFREQ)+= s3c2412-c
Re: [RESENT PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
On 08.04.19 06:07, zhong jiang wrote:
> When adding the memory by probing memory block in sysfs interface, there is an
> obvious issue that we will unlock the device_hotplug_lock when fails to takes
> it.
>
> That issue was introduced in Commit 8df1d0e4a265
> ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
>
> We should drop out in time when fails to take the device_hotplug_lock.
>
> Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the
> device_hotplug_lock")
> Reported-by: Yang yingliang
> Signed-off-by: zhong jiang
> ---
> drivers/base/memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index d9ebb89..0c9e22f 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -507,7 +507,7 @@ static ssize_t probe_store(struct device *dev, struct
> device_attribute *attr,
>
> ret = lock_device_hotplug_sysfs();
> if (ret)
> - goto out;
> + return ret;
>
> nid = memory_add_physaddr_to_nid(phys_addr);
> ret = __add_memory(nid, phys_addr,
>
Indeed
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH] s390/mm: Silence compiler warning when compiling without CONFIG_PGSTE
On 07.04.19 14:55, Thomas Huth wrote:
> If CONFIG_PGSTE is not set (e.g. when compiling without KVM), GCC complains:
>
> CC arch/s390/mm/pgtable.o
> arch/s390/mm/pgtable.c:413:15: warning: ‘pmd_alloc_map’ defined but not
> used [-Wunused-function]
> static pmd_t *pmd_alloc_map(struct mm_struct *mm, unsigned long addr)
>^
>
> Wrap the function with "#ifdef CONFIG_PGSTE" to silence the warning.
>
> Signed-off-by: Thomas Huth
> ---
> arch/s390/mm/pgtable.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index 8485d6dc2754..9ebd01219812 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -410,6 +410,7 @@ static inline pmd_t pmdp_flush_lazy(struct mm_struct *mm,
> return old;
> }
>
> +#ifdef CONFIG_PGSTE
> static pmd_t *pmd_alloc_map(struct mm_struct *mm, unsigned long addr)
> {
> pgd_t *pgd;
> @@ -427,6 +428,7 @@ static pmd_t *pmd_alloc_map(struct mm_struct *mm,
> unsigned long addr)
> pmd = pmd_alloc(mm, pud, addr);
> return pmd;
> }
> +#endif
>
We could also move the function down to the functions where it is used
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH] soundwire: fix pm_runtime_get_sync return code checks
> On 5 Apr 2019, at 17:04, Pierre-Louis Bossart
> wrote:
>
> On 4/5/19 2:26 AM, Jan Kotas wrote:
>>
>>
>> ret = pm_runtime_get_sync(slave->bus->dev);
>> -if (ret < 0)
>> +if (ret < 0 && ret != -EACCES)
>>
> There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested an
> alternate solution for exactly the same code.
>
> + if (pm_runtime_enabled(slave->bus->dev)) {
> + ret = pm_runtime_get_sync(slave->bus->dev);
> + if (ret < 0)
> + return ret;
>
> I am far from an expert on pm_runtime but Srinivas' solution looks more
> elegant to me.
Hello Pierre,
Please take a look at this patch, that was my inspiration:
https://lists.linuxfoundation.org/pipermail/linux-pm/2011-June/031930.html
I also took a look, and it seems the value returned by
pm_runtime_get_syncis simply ignored in a lot of places,
so checking its value may be excessive.
Regards,
Jan
Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
On 4/4/19 3:03 PM, Peter Zijlstra wrote:
> On Thu, Apr 04, 2019 at 01:09:09PM +0200, Peter Zijlstra wrote:
>
>> That is not entirely the scenario I talked about, but *groan*.
>>
>> So what I meant was:
>>
>> CPU-0 CPU-n
>>
>> __schedule()
>>local_irq_disable()
>>
>>...
>> deactivate_task(prev);
>>
>>
>> try_to_wake_up(@p)
>>...
>>
>> smp_cond_load_acquire(&p->on_cpu, !VAL);
>>
>>
>> ..
>> perf_event_disable_inatomic()
>>event->pending_disable = 1;
>>irq_work_queue() /* self-IPI */
>>
>>
>>context_switch()
>> prepare_task_switch()
>>perf_event_task_sched_out()
>> // the above chain that clears pending_disable
>>
>> finish_task_switch()
>>finish_task()
>> smp_store_release(prev->on_cpu, 0);
>>/*
>> finally */
>> // take woken
>> //
>> context_switch to @p
>>finish_lock_switch()
>> raw_spin_unlock_irq()
>> /* w00t, IRQs enabled, self-IPI time */
>>
>>perf_pending_event()
>> // event->pending_disable == 0
>>
>>
>>
>> What you're suggesting, is that the time between:
>>
>> smp_store_release(prev->on_cpu, 0);
>>
>> and
>>
>>
>>
>> on CPU-0 is sufficient for CPU-n to context switch to the task, enable
>> the event there, trigger a PMI that calls perf_event_disable_inatomic()
>> _again_ (this would mean irq_work_queue() failing, which we don't check)
>> (and schedule out again, although that's not required).
>>
>> This being virt that might actually be possible if (v)CPU-0 takes a nap
>> I suppose.
>>
>> Let me think about this a little more...
>
> Does the below cure things? It's not exactly pretty, but it could just
> do the trick.
>
> ---
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index dfc4bab0b02b..d496e6911442 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2009,8 +2009,8 @@ event_sched_out(struct perf_event *event,
> event->pmu->del(event, 0);
> event->oncpu = -1;
>
> - if (event->pending_disable) {
> - event->pending_disable = 0;
> + if (event->pending_disable == smp_processor_id()) {
> + event->pending_disable = -1;
> state = PERF_EVENT_STATE_OFF;
> }
> perf_event_set_state(event, state);
> @@ -2198,7 +2198,7 @@ EXPORT_SYMBOL_GPL(perf_event_disable);
>
> void perf_event_disable_inatomic(struct perf_event *event)
> {
> - event->pending_disable = 1;
> + event->pending_disable = smp_processor_id();
> irq_work_queue(&event->pending);
> }
>
> @@ -5822,8 +5822,8 @@ static void perf_pending_event(struct irq_work *entry)
>* and we won't recurse 'further'.
>*/
>
> - if (event->pending_disable) {
> - event->pending_disable = 0;
> + if (event->pending_disable == smp_processor_id()) {
> + event->pending_disable = -1;
> perf_event_disable_local(event);
> }
>
> @@ -10236,6 +10236,7 @@ perf_event_alloc(struct perf_event_attr *attr, int
> cpu,
>
>
> init_waitqueue_head(&event->waitq);
> + event->pending_disable = -1;
> init_irq_work(&event->pending, perf_pending_event);
>
> mutex_init(&event->mmap_mutex);
>
Peter,
very good news, your fix ran over the weekend without any hit!!!
Thanks very much for your help. Do you submit this patch to the kernel mailing
list?
--
Thomas Richter, Dept 3252, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On 08.04.2019 9:05, Hugh Dickins wrote:
On Fri, 5 Apr 2019, Konstantin Khlebnikov wrote:
On 05.04.2019 5:12, Hugh Dickins wrote:
Hi Alex, could you please give the patch below a try? It fixes a
problem, but I'm not sure that it's your problem - please let us know.
I've not yet written up the commit description, and this should end up
as 4/4 in a series fixing several new swapoff issues: I'll wait to post
the finished series until heard back from you.
I did first try following the suggestion Konstantin had made back then,
for a similar shmem_writepage() case: atomic_inc_not_zero(&sb->s_active).
But it turned out to be difficult to get right in shmem_unuse(), because
of the way that relies on the inode as a cursor in the list - problem
when you've acquired an s_active reference, but fail to acquire inode
reference, and cannot safely release the s_active reference while still
holding the swaplist mutex.
If VFS offered an isgrab(inode), like igrab() but acquiring s_active
reference while holding i_lock, that would drop very easily into the
current shmem_unuse() as a replacement there for igrab(). But the rest
of the world has managed without that for years, so I'm disinclined to
add it just for this. And the patch below seems good enough without it.
Thanks,
Hugh
---
include/linux/shmem_fs.h |1 +
mm/shmem.c | 39 ++-
2 files changed, 19 insertions(+), 21 deletions(-)
--- 5.1-rc3/include/linux/shmem_fs.h2019-03-17 16:18:15.181820820 -0700
+++ linux/include/linux/shmem_fs.h 2019-04-04 16:18:08.193512968 -0700
@@ -21,6 +21,7 @@ struct shmem_inode_info {
struct list_headswaplist; /* chain of maybes on swap */
struct shared_policypolicy; /* NUMA memory alloc policy
*/
struct simple_xattrsxattrs; /* list of xattrs */
+ atomic_tstop_eviction; /* hold when working on inode
*/
struct inodevfs_inode;
};
--- 5.1-rc3/mm/shmem.c 2019-03-17 16:18:15.701823872 -0700
+++ linux/mm/shmem.c2019-04-04 16:18:08.193512968 -0700
@@ -1081,9 +1081,15 @@ static void shmem_evict_inode(struct ino
}
spin_unlock(&sbinfo->shrinklist_lock);
}
- if (!list_empty(&info->swaplist)) {
+ while (!list_empty(&info->swaplist)) {
+ /* Wait while shmem_unuse() is scanning this inode...
*/
+ wait_var_event(&info->stop_eviction,
+ !atomic_read(&info->stop_eviction));
mutex_lock(&shmem_swaplist_mutex);
list_del_init(&info->swaplist);
+ /* ...but beware of the race if we peeked too early
*/
+ if (!atomic_read(&info->stop_eviction))
+ list_del_init(&info->swaplist);
mutex_unlock(&shmem_swaplist_mutex);
}
}
@@ -1227,36 +1233,27 @@ int shmem_unuse(unsigned int type, bool
unsigned long *fs_pages_to_unuse)
{
struct shmem_inode_info *info, *next;
- struct inode *inode;
- struct inode *prev_inode = NULL;
int error = 0;
if (list_empty(&shmem_swaplist))
return 0;
mutex_lock(&shmem_swaplist_mutex);
-
- /*
-* The extra refcount on the inode is necessary to safely dereference
-* p->next after re-acquiring the lock. New shmem inodes with swap
-* get added to the end of the list and we will scan them all.
-*/
list_for_each_entry_safe(info, next, &shmem_swaplist, swaplist) {
if (!info->swapped) {
list_del_init(&info->swaplist);
continue;
}
-
- inode = igrab(&info->vfs_inode);
- if (!inode)
- continue;
-
+ /*
+* Drop the swaplist mutex while searching the inode for
swap;
+* but before doing so, make sure shmem_evict_inode() will
not
+* remove placeholder inode from swaplist, nor let it be
freed
+* (igrab() would protect from unlink, but not from unmount).
+*/
+ atomic_inc(&info->stop_eviction);
mutex_unlock(&shmem_swaplist_mutex);
- if (prev_inode)
- iput(prev_inode);
- prev_inode = inode;
This seems too ad hoc solution.
I see what you mean by "ad hoc", but disagree with "too" ad hoc:
it's an appropriate solution, and a general one - I didn't invent it
for this, but for the huge tmpfs recoveries work items four years ago;
just changed the name from "info->recoveries" to "info->stop_eviction"
to let it be generalized to this swapoff case.
I prefer mine, since it simplifies shmem_unuse() (no igrab!), and has
the
[REGRESSION] AppArmor module parameter layout changed with c5459b829b716
Hi A recent commit changed how `/sys/module/apparmor/parameters/enabled` looks. It was "Y"/"N" before, now it is an integer. I *think* the commit that changed this was: commit c5459b829b716dafd226ad270f25c9a3050f7586 Author: Kees Cook Date: Thu Sep 13 22:28:48 2018 -0700 LSM: Plumb visibility into optional "enabled" state I haven't recompiled with a revert, but changing the module-parameter type looks like the obvious culprit. I don't see how this change can be safe? This breaks the AppArmor detection of `dbus-broker`. Can the commit be reverted? Thanks David
Re: [PATCH V2 19/20] DT bindings: spi: document tx/rx clock delay properties
On Thu, Apr 04, 2019 at 05:14:18PM -0700, Sowjanya Komatineni wrote: > Tegra SPI controller has TX and RX trimmers to tuning the delay of > SPI master clock with respect to the data. Please use subject lines matching the style for the subsystem. This makes it easier for people to identify relevant patches. signature.asc Description: PGP signature
RE: [PATCH 1/2] dt-bindings: rtc: add battery-low-hw-alarm property
HI, > On 06/04/2019 01:07:13-0500, Rob Herring wrote: > > On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote: > > > Some RTC devices have a battery-low automatic detection circuit. > > > The battery-low event is usually reported with: > > > > > > - a bit change in a RTC status register > > > - a hw signaling (generally using an interrupt generation), changing > > > the hw level of a specific pin; > > > > > > The new property "battery-low-hw-alarm" enable the RTC to generate the > > > hw signaling in case of battery-low event. > > > > > > Signed-off-by: Flavio Suligoi > > > --- > > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt > b/Documentation/devicetree/bindings/rtc/rtc.txt > > > index a97fc6a..f93a44d 100644 > > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt > > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt > > > @@ -31,6 +31,9 @@ below. > > > expressed in femto Farad (fF). > > > The default value shall be listed (if > optional), > > > and likewise all valid values. > > > +- battery-low-hw-alarm :Enable the "battery-low" output pin. This > function > > > +is available on the following devices: > > > +- pcf2127 - pin used for alarm: INTn > > > > Boolean? If there's cases where which pin is selectable, then we'd need > > this to take a value. Not sure how likely that is? > > > > Indeed, there is at least the pcf85363 that has two possible pins for > that interrupt. How would you select the pin then? a zero based index? a > string? I think the string could be clearer for the final user and would give more freedom for future changes. For example, we can call this property, instead of "battery-low-alarm" or "low-voltage-alarm", simply: "alarm-pin_1" and then the string argument can describe the function used; for example: alarm-pin_1 = "backup-supply-low-voltage-alarm"; alarm-pin_2 = ".."; Flavio Suligoi
Applied "ASoC: Intel: bytcht_es8316: Add quirk for the Teclast X98+ II" to the asoc tree
The patch
ASoC: Intel: bytcht_es8316: Add quirk for the Teclast X98+ II
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a8d218f4fe8116395e4c4a13b63029ecf00d4035 Mon Sep 17 00:00:00 2001
From: Paul Cercueil
Date: Fri, 29 Mar 2019 22:50:45 +0100
Subject: [PATCH] ASoC: Intel: bytcht_es8316: Add quirk for the Teclast X98+ II
The Teclast X98+ II is a Cherrytrail tablet, which require two quirks:
- it has stereo speakers,
- its jack detection mechanism is inverted.
Signed-off-by: Paul Cercueil
Signed-off-by: Mark Brown
---
sound/soc/intel/boards/bytcht_es8316.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/sound/soc/intel/boards/bytcht_es8316.c
b/sound/soc/intel/boards/bytcht_es8316.c
index ccf552e92d53..38975827e276 100644
--- a/sound/soc/intel/boards/bytcht_es8316.c
+++ b/sound/soc/intel/boards/bytcht_es8316.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -441,11 +442,25 @@ static const struct acpi_gpio_mapping
byt_cht_es8316_gpios[] = {
{ },
};
+/* Please keep this list alphabetically sorted */
+static const struct dmi_system_id byt_cht_es8316_quirk_table[] = {
+ { /* Teclast X98 Plus II */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X98 Plus II"),
+ },
+ .driver_data = (void *)(BYT_CHT_ES8316_INTMIC_IN1_MAP
+ | BYT_CHT_ES8316_JD_INVERTED),
+ },
+ {}
+};
+
static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev)
{
static const char * const mic_name[] = { "in1", "in2" };
struct property_entry props[MAX_NO_PROPS] = {};
struct byt_cht_es8316_private *priv;
+ const struct dmi_system_id *dmi_id;
struct device *dev = &pdev->dev;
struct snd_soc_acpi_mach *mach;
const char *platform_name;
@@ -488,7 +503,10 @@ static int snd_byt_cht_es8316_mc_probe(struct
platform_device *pdev)
return ret;
/* Check for BYTCR or other platform and setup quirks */
- if (x86_match_cpu(baytrail_cpu_ids) &&
+ dmi_id = dmi_first_match(byt_cht_es8316_quirk_table);
+ if (dmi_id) {
+ quirk = (int)dmi_id->driver_data;
+ } else if (x86_match_cpu(baytrail_cpu_ids) &&
mach->mach_params.acpi_ipc_irq_index == 0) {
/* On BYTCR default to SSP0, internal-mic-in2-map, mono-spk */
quirk = BYT_CHT_ES8316_SSP0 | BYT_CHT_ES8316_INTMIC_IN2_MAP |
--
2.20.1
Applied "ASoC: wm1133-ev1: Switch to SPDX identifier" to the asoc tree
The patch ASoC: wm1133-ev1: Switch to SPDX identifier has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From a03584b75a28450a2a64646e3c1b3d6c48aacf3b Mon Sep 17 00:00:00 2001 From: Andra Danciu Date: Fri, 5 Apr 2019 14:50:10 +0300 Subject: [PATCH] ASoC: wm1133-ev1: Switch to SPDX identifier Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Andra Danciu Signed-off-by: Mark Brown --- sound/soc/fsl/wm1133-ev1.c | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/sound/soc/fsl/wm1133-ev1.c b/sound/soc/fsl/wm1133-ev1.c index 2f80b21b2921..aad24ccbef90 100644 --- a/sound/soc/fsl/wm1133-ev1.c +++ b/sound/soc/fsl/wm1133-ev1.c @@ -1,16 +1,11 @@ -/* - * wm1133-ev1.c - Audio for WM1133-EV1 on i.MX31ADS - * - * Copyright (c) 2010 Wolfson Microelectronics plc - * Author: Mark Brown - * - * Based on an earlier driver for the same hardware by Liam Girdwood. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ +// SPDX-License-Identifier: GPL-2.0+ +// +// wm1133-ev1.c - Audio for WM1133-EV1 on i.MX31ADS +// +// Copyright (c) 2010 Wolfson Microelectronics plc +// Author: Mark Brown +// +// Based on an earlier driver for the same hardware by Liam Girdwood. #include #include -- 2.20.1
Applied "ASoC: phycore-ac97: Switch to SPDX identifier" to the asoc tree
The patch ASoC: phycore-ac97: Switch to SPDX identifier has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From e5eec5ee98a6379b6a515beb27db4f9a80bd9276 Mon Sep 17 00:00:00 2001 From: Andra Danciu Date: Fri, 5 Apr 2019 14:50:09 +0300 Subject: [PATCH] ASoC: phycore-ac97: Switch to SPDX identifier Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Andra Danciu Signed-off-by: Mark Brown --- sound/soc/fsl/phycore-ac97.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c index 66fb6c4614d2..fe7ba6db7c96 100644 --- a/sound/soc/fsl/phycore-ac97.c +++ b/sound/soc/fsl/phycore-ac97.c @@ -1,14 +1,8 @@ -/* - * phycore-ac97.c -- SoC audio for imx_phycore in AC97 mode - * - * Copyright 2009 Sascha Hauer, Pengutronix - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - */ +// SPDX-License-Identifier: GPL-2.0+ +// +// phycore-ac97.c -- SoC audio for imx_phycore in AC97 mode +// +// Copyright 2009 Sascha Hauer, Pengutronix #include #include -- 2.20.1
Re: [PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
Hi zhong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on v5.1-rc4 next-20190405]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/zhong-jiang/mm-memory_hotplug-Do-not-unlock-when-fails-to-take-the-device_hotplug_lock/20190408-142325
config: x86_64-randconfig-x007-201914 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/base/memory.c: In function 'probe_store':
>> drivers/base/memory.c:509:3: error: label 'ret' used but not defined
goto ret;
^~~~
vim +/ret +509 drivers/base/memory.c
485
486 /*
487 * Some architectures will have custom drivers to do this, and
488 * will not need to do it from userspace. The fake hot-add code
489 * as well as ppc64 will do all of their discovery in userspace
490 * and will require this interface.
491 */
492 #ifdef CONFIG_ARCH_MEMORY_PROBE
493 static ssize_t probe_store(struct device *dev, struct device_attribute
*attr,
494 const char *buf, size_t count)
495 {
496 u64 phys_addr;
497 int nid, ret;
498 unsigned long pages_per_block = PAGES_PER_SECTION *
sections_per_block;
499
500 ret = kstrtoull(buf, 0, &phys_addr);
501 if (ret)
502 return ret;
503
504 if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1))
505 return -EINVAL;
506
507 ret = lock_device_hotplug_sysfs();
508 if (ret)
> 509 goto ret;
510
511 nid = memory_add_physaddr_to_nid(phys_addr);
512 ret = __add_memory(nid, phys_addr,
513 MIN_MEMORY_BLOCK_SIZE * sections_per_block);
514
515 if (ret)
516 goto out;
517
518 ret = count;
519 out:
520 unlock_device_hotplug();
521 return ret;
522 }
523
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Applied "ASoC: p1022_rdk: Switch to SPDX identifier" to the asoc tree
The patch ASoC: p1022_rdk: Switch to SPDX identifier has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 8acfeb65cbaa92ff2e4f3305c7a18a6edabd1d92 Mon Sep 17 00:00:00 2001 From: Andra Danciu Date: Fri, 5 Apr 2019 14:50:07 +0300 Subject: [PATCH] ASoC: p1022_rdk: Switch to SPDX identifier Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Andra Danciu Signed-off-by: Mark Brown --- sound/soc/fsl/p1022_rdk.c | 32 ++-- 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/sound/soc/fsl/p1022_rdk.c b/sound/soc/fsl/p1022_rdk.c index 4afbdd610bfa..1c32c2d8c6b0 100644 --- a/sound/soc/fsl/p1022_rdk.c +++ b/sound/soc/fsl/p1022_rdk.c @@ -1,21 +1,17 @@ -/** - * Freescale P1022RDK ALSA SoC Machine driver - * - * Author: Timur Tabi - * - * Copyright 2012 Freescale Semiconductor, Inc. - * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed "as is" without any warranty of any - * kind, whether express or implied. - * - * Note: in order for audio to work correctly, the output controls need - * to be enabled, because they control the clock. So for playback, for - * example: - * - * amixer sset 'Left Output Mixer PCM' on - * amixer sset 'Right Output Mixer PCM' on - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Freescale P1022RDK ALSA SoC Machine driver +// +// Author: Timur Tabi +// +// Copyright 2012 Freescale Semiconductor, Inc. +// +// Note: in order for audio to work correctly, the output controls need +// to be enabled, because they control the clock. So for playback, for +// example: +// +// amixer sset 'Left Output Mixer PCM' on +// amixer sset 'Right Output Mixer PCM' on #include #include -- 2.20.1
Applied "ASoC: mpc5200_psc_ac97: Switch to SPDX identifier" to the asoc tree
The patch ASoC: mpc5200_psc_ac97: Switch to SPDX identifier has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 1af301d46246942a00e15294603dbd3abfb41a82 Mon Sep 17 00:00:00 2001 From: Andra Danciu Date: Fri, 5 Apr 2019 14:50:02 +0300 Subject: [PATCH] ASoC: mpc5200_psc_ac97: Switch to SPDX identifier Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Andra Danciu Signed-off-by: Mark Brown --- sound/soc/fsl/mpc5200_psc_ac97.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c index 07ee355ee385..e5b9c04d1565 100644 --- a/sound/soc/fsl/mpc5200_psc_ac97.c +++ b/sound/soc/fsl/mpc5200_psc_ac97.c @@ -1,13 +1,9 @@ -/* - * linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip. - * - * Copyright (C) 2009 Jon Smirl, Digispeaker - * Author: Jon Smirl - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip. +// +// Copyright (C) 2009 Jon Smirl, Digispeaker +// Author: Jon Smirl #include #include -- 2.20.1
Re: [RESENT PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
On Mon, Apr 08, 2019 at 12:07:17PM +0800, zhong jiang wrote:
> When adding the memory by probing memory block in sysfs interface, there is an
> obvious issue that we will unlock the device_hotplug_lock when fails to takes
> it.
>
> That issue was introduced in Commit 8df1d0e4a265
> ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
>
> We should drop out in time when fails to take the device_hotplug_lock.
>
> Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the
> device_hotplug_lock")
> Reported-by: Yang yingliang
> Signed-off-by: zhong jiang
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
Applied "ASoC: mpc5200_dma: Switch to SPDX identifier" to the asoc tree
The patch ASoC: mpc5200_dma: Switch to SPDX identifier has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 1edfc2485d8dcf4c766a5be8049cab1cddc6700d Mon Sep 17 00:00:00 2001 From: Andra Danciu Date: Fri, 5 Apr 2019 14:50:01 +0300 Subject: [PATCH] ASoC: mpc5200_dma: Switch to SPDX identifier Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Andra Danciu Signed-off-by: Mark Brown --- sound/soc/fsl/mpc5200_dma.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c index c1a4544eb16b..4396442c2fdd 100644 --- a/sound/soc/fsl/mpc5200_dma.c +++ b/sound/soc/fsl/mpc5200_dma.c @@ -1,10 +1,10 @@ -/* - * Freescale MPC5200 PSC DMA - * ALSA SoC Platform driver - * - * Copyright (C) 2008 Secret Lab Technologies Ltd. - * Copyright (C) 2009 Jon Smirl, Digispeaker - */ +// SPDX-License-Identifier: GPL +// +// Freescale MPC5200 PSC DMA +// ALSA SoC Platform driver +// +// Copyright (C) 2008 Secret Lab Technologies Ltd. +// Copyright (C) 2009 Jon Smirl, Digispeaker #include #include -- 2.20.1
Applied "ASoC: stm32: fix sai driver name initialisation" to the asoc tree
The patch
ASoC: stm32: fix sai driver name initialisation
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 17d3069ccf06970e2db3f7cbf4335f207524279e Mon Sep 17 00:00:00 2001
From: Arnaud Pouliquen
Date: Fri, 5 Apr 2019 11:19:11 +0200
Subject: [PATCH] ASoC: stm32: fix sai driver name initialisation
This patch fixes the sai driver structure overwriting which results in
a cpu dai name equal NULL.
Fixes: 3e086ed ("ASoC: stm32: add SAI driver")
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Mark Brown
---
sound/soc/stm/stm32_sai_sub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 55d802f51c15..83d8a7ac56f4 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -1419,7 +1419,6 @@ static int stm32_sai_sub_dais_init(struct platform_device
*pdev,
if (!sai->cpu_dai_drv)
return -ENOMEM;
- sai->cpu_dai_drv->name = dev_name(&pdev->dev);
if (STM_SAI_IS_PLAYBACK(sai)) {
memcpy(sai->cpu_dai_drv, &stm32_sai_playback_dai,
sizeof(stm32_sai_playback_dai));
@@ -1429,6 +1428,7 @@ static int stm32_sai_sub_dais_init(struct platform_device
*pdev,
sizeof(stm32_sai_capture_dai));
sai->cpu_dai_drv->capture.stream_name = sai->cpu_dai_drv->name;
}
+ sai->cpu_dai_drv->name = dev_name(&pdev->dev);
return 0;
}
--
2.20.1
Applied "ASoC: fsl-dma: Switch to SPDX identifier" to the asoc tree
The patch ASoC: fsl-dma: Switch to SPDX identifier has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From e073564fe653eacbef6723a0a5210131b3998000 Mon Sep 17 00:00:00 2001 From: Andra Danciu Date: Fri, 5 Apr 2019 14:49:54 +0300 Subject: [PATCH] ASoC: fsl-dma: Switch to SPDX identifier Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Andra Danciu Signed-off-by: Mark Brown --- sound/soc/fsl/fsl_dma.c | 26 +++--- sound/soc/fsl/fsl_dma.h | 5 + 2 files changed, 12 insertions(+), 19 deletions(-) diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c index 78871de35086..e22508301412 100644 --- a/sound/soc/fsl/fsl_dma.c +++ b/sound/soc/fsl/fsl_dma.c @@ -1,18 +1,14 @@ -/* - * Freescale DMA ALSA SoC PCM driver - * - * Author: Timur Tabi - * - * Copyright 2007-2010 Freescale Semiconductor, Inc. - * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed "as is" without any warranty of any - * kind, whether express or implied. - * - * This driver implements ASoC support for the Elo DMA controller, which is - * the DMA controller on Freescale 83xx, 85xx, and 86xx SOCs. In ALSA terms, - * the PCM driver is what handles the DMA buffer. - */ +// SPDX-License-Identifier: GPL-2.0 +// +// Freescale DMA ALSA SoC PCM driver +// +// Author: Timur Tabi +// +// Copyright 2007-2010 Freescale Semiconductor, Inc. +// +// This driver implements ASoC support for the Elo DMA controller, which is +// the DMA controller on Freescale 83xx, 85xx, and 86xx SOCs. In ALSA terms, +// the PCM driver is what handles the DMA buffer. #include #include diff --git a/sound/soc/fsl/fsl_dma.h b/sound/soc/fsl/fsl_dma.h index 78fee97e8036..f19ae765b656 100644 --- a/sound/soc/fsl/fsl_dma.h +++ b/sound/soc/fsl/fsl_dma.h @@ -1,9 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * mpc8610-pcm.h - ALSA PCM interface for the Freescale MPC8610 SoC - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. */ #ifndef _MPC8610_PCM_H -- 2.20.1
Applied "regulator: s2mpa01: Convert to use simplified DT parsing" to the regulator tree
The patch
regulator: s2mpa01: Convert to use simplified DT parsing
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0677c3ea53dcb38314718e8ed7d851972eabf102 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Thu, 4 Apr 2019 23:07:09 +0800
Subject: [PATCH] regulator: s2mpa01: Convert to use simplified DT parsing
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/s2mpa01.c | 39 ++---
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 58a1fe583a6c..da11ac5c09f2 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -20,7 +20,6 @@
#define S2MPA01_REGULATOR_CNT ARRAY_SIZE(regulators)
struct s2mpa01_info {
- struct of_regulator_match rdata[S2MPA01_REGULATOR_MAX];
int ramp_delay24;
int ramp_delay3;
int ramp_delay5;
@@ -232,6 +231,8 @@ static const struct regulator_ops s2mpa01_buck_ops = {
#define regulator_desc_ldo(num, step) {\
.name = "LDO"#num,\
+ .of_match = of_match_ptr("LDO"#num), \
+ .regulators_node = of_match_ptr("regulators"), \
.id = S2MPA01_LDO##num, \
.ops= &s2mpa01_ldo_ops, \
.type = REGULATOR_VOLTAGE,\
@@ -247,6 +248,8 @@ static const struct regulator_ops s2mpa01_buck_ops = {
#define regulator_desc_buck1_4(num){ \
.name = "BUCK"#num, \
+ .of_match = of_match_ptr("BUCK"#num), \
+ .regulators_node = of_match_ptr("regulators"), \
.id = S2MPA01_BUCK##num,\
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
@@ -263,6 +266,8 @@ static const struct regulator_ops s2mpa01_buck_ops = {
#define regulator_desc_buck5 { \
.name = "BUCK5", \
+ .of_match = of_match_ptr("BUCK5"),\
+ .regulators_node = of_match_ptr("regulators"), \
.id = S2MPA01_BUCK5,\
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
@@ -279,6 +284,8 @@ static const struct regulator_ops s2mpa01_buck_ops = {
#define regulator_desc_buck6_10(num, min, step) { \
.name = "BUCK"#num, \
+ .of_match = of_match_ptr("BUCK"#num), \
+ .regulators_node = of_match_ptr("regulators"), \
.id = S2MPA01_BUCK##num,\
.ops= &s2mpa01_buck_ops,\
.type = REGULATOR_VOLTAGE,\
@@ -336,9 +343,7 @@ static int s2mpa01_pmic_probe(struct platform_device *pdev)
{
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct sec_platform_data *pdata = dev_get_platdata(iodev->dev);
- struct device_node *reg_np = NULL;
struct regulator_config config = { };
- struct of_regulator_match *rdata;
struct s2mpa01_info *s2mpa01;
int i;
@@ -346,39 +351,15 @@ static int s2mpa01_pmic_probe(struct platform_device
*pdev)
if (!s2mpa01)
return -ENOMEM;
- rdata = s2mpa01->rdata;
- for (i = 0; i < S2MPA01_REGULATOR_CNT; i++)
- rdata[i].name = regulators[i].name;
-
- if (iodev->dev->of_node) {
- reg_np = of_get_child_by_name(iodev->dev->of_node,
- "regulators");
- if (!reg_np) {
- dev_err(&pdev->dev,
- "could not find regulators sub-node\n");
- return -EI
Applied "regulator: bd718x7: Use rdev_get_id() to get regulator id" to the regulator tree
The patch
regulator: bd718x7: Use rdev_get_id() to get regulator id
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0a245f0efcb5f5d70f3512bfd0ed8277256503c5 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Sun, 7 Apr 2019 17:03:02 +0800
Subject: [PATCH] regulator: bd718x7: Use rdev_get_id() to get regulator id
Use rdev_get_id() instead of directly access rdev->desc->id.
While at it also remove unneeded init for ramp_value variable.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/bd718x7-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/bd718x7-regulator.c
b/drivers/regulator/bd718x7-regulator.c
index b2191be49670..fde4264da6ff 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -27,8 +27,8 @@
static int bd718xx_buck1234_set_ramp_delay(struct regulator_dev *rdev,
int ramp_delay)
{
- int id = rdev->desc->id;
- unsigned int ramp_value = BUCK_RAMPRATE_10P00MV;
+ int id = rdev_get_id(rdev);
+ unsigned int ramp_value;
dev_dbg(&rdev->dev, "Buck[%d] Set Ramp = %d\n", id + 1,
ramp_delay);
--
2.20.1
Applied "ASoC: ab8500: add range to usleep_range" to the regulator tree
The patch
ASoC: ab8500: add range to usleep_range
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 45a310136b3ed52267e757c57e835f583140aa5f Mon Sep 17 00:00:00 2001
From: Nicholas Mc Guire
Date: Sun, 7 Apr 2019 04:59:34 +0200
Subject: [PATCH] ASoC: ab8500: add range to usleep_range
Providing a range for usleep_range() allows the hrtimer subsystem to
coalesce timers - as this delay has no upper limit anyway (interrupts
or context switch is possible) it should not hurt to extend this
from 2 to 2-4 milliseconds.
Signed-off-by: Nicholas Mc Guire
Signed-off-by: Mark Brown
---
sound/soc/codecs/ab8500-codec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c
index 03bbbcd3b6c1..dac207dc5b65 100644
--- a/sound/soc/codecs/ab8500-codec.c
+++ b/sound/soc/codecs/ab8500-codec.c
@@ -1062,10 +1062,10 @@ static void anc_iir(struct snd_soc_component
*component, unsigned int bnk,
snd_soc_component_update_bits(component,
AB8500_ANCCONF1,
BIT(AB8500_ANCCONF1_ANCIIRINIT),
BIT(AB8500_ANCCONF1_ANCIIRINIT));
- usleep_range(AB8500_ANC_SM_DELAY, AB8500_ANC_SM_DELAY);
+ usleep_range(AB8500_ANC_SM_DELAY,
AB8500_ANC_SM_DELAY*2);
snd_soc_component_update_bits(component,
AB8500_ANCCONF1,
BIT(AB8500_ANCCONF1_ANCIIRINIT), 0);
- usleep_range(AB8500_ANC_SM_DELAY, AB8500_ANC_SM_DELAY);
+ usleep_range(AB8500_ANC_SM_DELAY,
AB8500_ANC_SM_DELAY*2);
} else {
snd_soc_component_update_bits(component,
AB8500_ANCCONF1,
BIT(AB8500_ANCCONF1_ANCIIRUPDATE),
--
2.20.1
Applied "spi: document tx/rx clock delay properties" to the spi tree
The patch
spi: document tx/rx clock delay properties
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7558f978f9b66a2bc284a0e8c0764b88305bc29f Mon Sep 17 00:00:00 2001
From: Sowjanya Komatineni
Date: Thu, 4 Apr 2019 17:14:18 -0700
Subject: [PATCH] spi: document tx/rx clock delay properties
Tegra SPI controller has TX and RX trimmers to tuning the delay of
SPI master clock with respect to the data.
TX and RX tap values are based on the platform validation across the
PVT and the trimmer values vary based on the trace lengths to the
corresponding SPI devices.
Signed-off-by: Sowjanya Komatineni
Signed-off-by: Mark Brown
---
.../bindings/spi/nvidia,tegra114-spi.txt | 20 +++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
index 9ba7c5a273b4..db8e0d71c5bc 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
@@ -23,6 +23,18 @@ Required properties:
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
+Optional properties:
+- nvidia,tx-clk-tap-delay: Delays the clock going out to the external device
+ with this tap value. This property is used to tune the outgoing data from
+ Tegra SPI master with respect to outgoing Tegra SPI master clock.
+ Tap values vary based on the platform design trace lengths from Tegra SPI
+ to corresponding slave devices. Valid tap values are from 0 thru 63.
+- nvidia,rx-clk-tap-delay: Delays the clock coming in from the external device
+ with this tap value. This property is used to adjust the Tegra SPI master
+ clock with respect to the data from the SPI slave device.
+ Tap values vary based on the platform design trace lengths from Tegra SPI
+ to corresponding slave devices. Valid tap values are from 0 thru 63.
+
Example:
spi@7000d600 {
@@ -38,4 +50,12 @@ spi@7000d600 {
reset-names = "spi";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
+ @ {
+ ...
+ ...
+ nvidia,rx-clk-tap-delay = <0>;
+ nvidia,tx-clk-tap-delay = <16>;
+ ...
+ };
+
};
--
2.20.1
Applied "spi: add a method for configuring CS timing" to the spi tree
The patch
spi: add a method for configuring CS timing
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From f1ca9992ced71029735784de138f53446363087f Mon Sep 17 00:00:00 2001
From: Sowjanya Komatineni
Date: Thu, 4 Apr 2019 17:14:16 -0700
Subject: [PATCH] spi: add a method for configuring CS timing
This patch creates set_cs_timing SPI master optional method for
SPI masters to implement configuring CS timing if applicable.
This patch also creates spi_cs_timing accessory for SPI clients to
use for requesting SPI master controllers to configure device requested
CS setup time, hold time and inactive delay.
Signed-off-by: Sowjanya Komatineni
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 15 +++
include/linux/spi/spi.h | 15 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index fd1372fe0505..bf4027b54a19 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2995,6 +2995,21 @@ int spi_setup(struct spi_device *spi)
}
EXPORT_SYMBOL_GPL(spi_setup);
+/**
+ * spi_set_cs_timing - configure CS setup, hold, and inactive delays
+ * @spi: the device that requires specific CS timing configuration
+ * @setup: CS setup time in terms of clock count
+ * @hold: CS hold time in terms of clock count
+ * @inactive_dly: CS inactive delay between transfers in terms of clock count
+ */
+void spi_set_cs_timing(struct spi_device *spi, u8 setup, u8 hold,
+ u8 inactive_dly)
+{
+ if (spi->controller->set_cs_timing)
+ spi->controller->set_cs_timing(spi, setup, hold, inactive_dly);
+}
+EXPORT_SYMBOL_GPL(spi_set_cs_timing);
+
static int __spi_validate(struct spi_device *spi, struct spi_message *message)
{
struct spi_controller *ctlr = spi->controller;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index a0975cf76cf6..589f9dc9ac2b 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -330,6 +330,9 @@ static inline void spi_unregister_driver(struct spi_driver
*sdrv)
* must fail if an unrecognized or unsupported mode is requested.
* It's always safe to call this unless transfers are pending on
* the device whose settings are being modified.
+ * @set_cs_timing: optional hook for SPI devices to request SPI master
+ * controller for configuring specific CS setup time, hold time and inactive
+ * delay interms of clock counts
* @transfer: adds a message to the controller's transfer queue.
* @cleanup: frees controller-specific state
* @can_dma: determine whether this controller supports DMA
@@ -363,6 +366,7 @@ static inline void spi_unregister_driver(struct spi_driver
*sdrv)
* @unprepare_transfer_hardware: there are currently no more messages on the
* queue so the subsystem notifies the driver that it may relax the
* hardware by issuing this call
+ *
* @set_cs: set the logic level of the chip select line. May be called
* from interrupt context.
* @prepare_message: set up the controller to transfer a single message,
@@ -488,6 +492,17 @@ struct spi_controller {
*/
int (*setup)(struct spi_device *spi);
+ /*
+* set_cs_timing() method is for SPI controllers that supports
+* configuring CS timing.
+*
+* This hook allows SPI client drivers to request SPI controllers
+* to configure specific CS timing through spi_set_cs_timing() after
+* spi_setup().
+*/
+ void (*set_cs_timing)(struct spi_device *spi, u8 setup_clk_cycles,
+ u8 hold_clk_cycles, u8 inactive_clk_cycles);
+
/* bidirectional bulk transfers
*
* + The transfer() method may not sleep; its main role is
--
2.20.1
Applied "spi: tegra114: add 3 wire transfer mode support" to the spi tree
The patch
spi: tegra114: add 3 wire transfer mode support
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9d199231b000414e420a35912760f2d67e9c56d7 Mon Sep 17 00:00:00 2001
From: Sowjanya Komatineni
Date: Thu, 4 Apr 2019 17:14:08 -0700
Subject: [PATCH] spi: tegra114: add 3 wire transfer mode support
This patch adds 3 wire transfer support to SPI mode list along with
its implementation.
3 wire or Bi-directional mode uses only one serial data pin for the
transfer. SPI in master mode uses MOSI data line only and MISO data
line is not used.
Signed-off-by: Sowjanya Komatineni
Signed-off-by: Mark Brown
---
drivers/spi/spi-tegra114.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 1e749ce13029..751672b3bc16 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -754,6 +754,11 @@ static u32 tegra_spi_setup_transfer_one(struct spi_device
*spi,
else
command1 &= ~SPI_LSBIT_FE;
+ if (spi->mode & SPI_3WIRE)
+ command1 |= SPI_BIDIROE;
+ else
+ command1 &= ~SPI_BIDIROE;
+
if (tspi->cs_control) {
if (tspi->cs_control != spi)
tegra_spi_writel(tspi, command1, SPI_COMMAND1);
@@ -1158,7 +1163,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST |
- SPI_TX_DUAL | SPI_RX_DUAL;
+ SPI_TX_DUAL | SPI_RX_DUAL | SPI_3WIRE;
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
master->setup = tegra_spi_setup;
master->transfer_one_message = tegra_spi_transfer_one_message;
--
2.20.1
Applied "spi: bitbang: Introduce spi_bitbang_init()" to the spi tree
The patch
spi: bitbang: Introduce spi_bitbang_init()
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 45beec3519983cb11768cd3ee350f44975bf4cea Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Tue, 2 Apr 2019 21:01:32 -0700
Subject: [PATCH] spi: bitbang: Introduce spi_bitbang_init()
Move all of the code doing struct spi_bitbang initialization, so that
it can be paired with devm_spi_register_master() in order to avoid
having to call spi_bitbang_stop() explicitly.
Signed-off-by: Andrey Smirnov
Cc: Mark Brown
Cc: Chris Healy
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown
---
drivers/spi/spi-bitbang.c | 66 +++--
include/linux/spi/spi_bitbang.h | 1 +
2 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/spi-bitbang.c b/drivers/spi/spi-bitbang.c
index dd9a8c54a693..4243e53f9f7b 100644
--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -335,6 +335,42 @@ static void spi_bitbang_set_cs(struct spi_device *spi,
bool enable)
/*--*/
+int spi_bitbang_init(struct spi_bitbang *bitbang)
+{
+ struct spi_master *master = bitbang->master;
+
+ if (!master || !bitbang->chipselect)
+ return -EINVAL;
+
+ mutex_init(&bitbang->lock);
+
+ if (!master->mode_bits)
+ master->mode_bits = SPI_CPOL | SPI_CPHA | bitbang->flags;
+
+ if (master->transfer || master->transfer_one_message)
+ return -EINVAL;
+
+ master->prepare_transfer_hardware = spi_bitbang_prepare_hardware;
+ master->unprepare_transfer_hardware = spi_bitbang_unprepare_hardware;
+ master->transfer_one = spi_bitbang_transfer_one;
+ master->set_cs = spi_bitbang_set_cs;
+
+ if (!bitbang->txrx_bufs) {
+ bitbang->use_dma = 0;
+ bitbang->txrx_bufs = spi_bitbang_bufs;
+ if (!master->setup) {
+ if (!bitbang->setup_transfer)
+ bitbang->setup_transfer =
+spi_bitbang_setup_transfer;
+ master->setup = spi_bitbang_setup;
+ master->cleanup = spi_bitbang_cleanup;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(spi_bitbang_init);
+
/**
* spi_bitbang_start - start up a polled/bitbanging SPI master driver
* @bitbang: driver handle
@@ -368,33 +404,9 @@ int spi_bitbang_start(struct spi_bitbang *bitbang)
struct spi_master *master = bitbang->master;
int ret;
- if (!master || !bitbang->chipselect)
- return -EINVAL;
-
- mutex_init(&bitbang->lock);
-
- if (!master->mode_bits)
- master->mode_bits = SPI_CPOL | SPI_CPHA | bitbang->flags;
-
- if (master->transfer || master->transfer_one_message)
- return -EINVAL;
-
- master->prepare_transfer_hardware = spi_bitbang_prepare_hardware;
- master->unprepare_transfer_hardware = spi_bitbang_unprepare_hardware;
- master->transfer_one = spi_bitbang_transfer_one;
- master->set_cs = spi_bitbang_set_cs;
-
- if (!bitbang->txrx_bufs) {
- bitbang->use_dma = 0;
- bitbang->txrx_bufs = spi_bitbang_bufs;
- if (!master->setup) {
- if (!bitbang->setup_transfer)
- bitbang->setup_transfer =
-spi_bitbang_setup_transfer;
- master->setup = spi_bitbang_setup;
- master->cleanup = spi_bitbang_cleanup;
- }
- }
+ ret = spi_bitbang_init(bitbang);
+ if (ret)
+ return ret;
/* driver may get busy before register() returns, especially
* if someone registered boardinfo for devices
diff --git a/include/linux/spi/spi_bitbang.h b/include/linux/spi/spi_bitbang.h
index b7e021b274dc..c2a992cb 100644
--- a/include/linux/spi/spi_bitbang.h
+++ b/include/linux/spi/spi_bitbang.h
@@ -44,6 +44,7 @@ extern int spi_bitbang_setup_transfe
Applied "spi: gpio: Use devm_spi_register_master()" to the spi tree
The patch
spi: gpio: Use devm_spi_register_master()
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 79567c1a321e7396e734135d56950311dde07db2 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Tue, 2 Apr 2019 21:01:33 -0700
Subject: [PATCH] spi: gpio: Use devm_spi_register_master()
Replace spi_bitbang_start() with a combination of spi_bitbang_init()
and devm_spi_register_master() and drop all of the explicit
cleanup-related code that's no longer necessary.
Signed-off-by: Andrey Smirnov
Cc: Mark Brown
Cc: Chris Healy
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown
---
drivers/spi/spi-gpio.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index d4a22f22b04c..487ee55d26f7 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -396,8 +396,6 @@ static int spi_gpio_probe(struct platform_device *pdev)
spi_gpio = spi_master_get_devdata(master);
- platform_set_drvdata(pdev, spi_gpio);
-
status = spi_gpio_request(dev, spi_gpio);
if (status)
return status;
@@ -437,19 +435,11 @@ static int spi_gpio_probe(struct platform_device *pdev)
}
bb->setup_transfer = spi_bitbang_setup_transfer;
- return spi_bitbang_start(&spi_gpio->bitbang);
-}
-
-static int spi_gpio_remove(struct platform_device *pdev)
-{
- struct spi_gpio *spi_gpio;
-
- spi_gpio = platform_get_drvdata(pdev);
-
- /* stop() unregisters child devices too */
- spi_bitbang_stop(&spi_gpio->bitbang);
+ status = spi_bitbang_init(&spi_gpio->bitbang);
+ if (status)
+ return status;
- return 0;
+ return devm_spi_register_master(&pdev->dev, spi_master_get(master));
}
MODULE_ALIAS("platform:" DRIVER_NAME);
@@ -460,7 +450,6 @@ static struct platform_driver spi_gpio_driver = {
.of_match_table = of_match_ptr(spi_gpio_dt_ids),
},
.probe = spi_gpio_probe,
- .remove = spi_gpio_remove,
};
module_platform_driver(spi_gpio_driver);
--
2.20.1
Applied "spi-summary: document set_cs_timing" to the spi tree
The patch spi-summary: document set_cs_timing has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 24496da6927fa7399f7f60ab31b4cea27ec3ed00 Mon Sep 17 00:00:00 2001 From: Sowjanya Komatineni Date: Thu, 4 Apr 2019 17:14:15 -0700 Subject: [PATCH] spi-summary: document set_cs_timing This patch documents set_cs_timing SPI master method. Signed-off-by: Sowjanya Komatineni Signed-off-by: Mark Brown --- Documentation/spi/spi-summary | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 1721c1b570c3..1a63194b74d7 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -572,6 +572,12 @@ SPI MASTER METHODS 0: transfer is finished 1: transfer is still in progress +master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, + u8 hold_clk_cycles, u8 inactive_clk_cycles) + This method allows SPI client drivers to request SPI master controller + for configuring device specific CS setup, hold and inactive timing + requirements. + DEPRECATED METHODS master->transfer(struct spi_device *spi, struct spi_message *message) -- 2.20.1
Applied "spi: gpio: Make sure spi_master_put() is called in every error path" to the spi tree
The patch
spi: gpio: Make sure spi_master_put() is called in every error path
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 8b797490b4db09492acda4b4a4a4355d2311a614 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Tue, 2 Apr 2019 21:01:31 -0700
Subject: [PATCH] spi: gpio: Make sure spi_master_put() is called in every
error path
There's a number of failure paths in spi_gpio_probe() that do not call
spi_master_put() potentially leaking memory. Fix this problem by
registering a cleanup funciont via devm_add_action_or_reset() right
after SPI controller is allocated.
Signed-off-by: Andrey Smirnov
Cc: Mark Brown
Cc: Chris Healy
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown
---
drivers/spi/spi-gpio.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 5ac9ae192ddf..d4a22f22b04c 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -362,6 +362,11 @@ static int spi_gpio_probe_pdata(struct platform_device
*pdev,
return 0;
}
+static void spi_gpio_put(void *data)
+{
+ spi_master_put(data);
+}
+
static int spi_gpio_probe(struct platform_device *pdev)
{
int status;
@@ -377,6 +382,10 @@ static int spi_gpio_probe(struct platform_device *pdev)
if (!master)
return -ENOMEM;
+ status = devm_add_action_or_reset(&pdev->dev, spi_gpio_put, master);
+ if (status)
+ return status;
+
if (of_id)
status = spi_gpio_probe_dt(pdev, master);
else
@@ -428,11 +437,7 @@ static int spi_gpio_probe(struct platform_device *pdev)
}
bb->setup_transfer = spi_bitbang_setup_transfer;
- status = spi_bitbang_start(&spi_gpio->bitbang);
- if (status)
- spi_master_put(master);
-
- return status;
+ return spi_bitbang_start(&spi_gpio->bitbang);
}
static int spi_gpio_remove(struct platform_device *pdev)
@@ -444,8 +449,6 @@ static int spi_gpio_remove(struct platform_device *pdev)
/* stop() unregisters child devices too */
spi_bitbang_stop(&spi_gpio->bitbang);
- spi_master_put(spi_gpio->bitbang.master);
-
return 0;
}
--
2.20.1
Applied "spi: tegra114: add dual mode support" to the spi tree
The patch spi: tegra114: add dual mode support has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 9877a347f2056f7aa4e770de9a20048ad288f545 Mon Sep 17 00:00:00 2001 From: Sowjanya Komatineni Date: Thu, 4 Apr 2019 17:14:07 -0700 Subject: [PATCH] spi: tegra114: add dual mode support This patch adds support for dual mode SPI transfer. Dual mode uses both MOSI and MISO lines in parallel where the data is interleaved on MOSI and MISO lines increasing the throughput. Packet from Tx FIFO is transmitted on both MOSI and MISO lines and packet to Rx FIFO is received from both MOSI and MISO lines. Even bits are transmitted or received on the MOSI data line and odd bits are transmitted or received on the MISO data line. Signed-off-by: Sowjanya Komatineni Signed-off-by: Mark Brown --- drivers/spi/spi-tegra114.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c index 402799c7f6b7..1e749ce13029 100644 --- a/drivers/spi/spi-tegra114.c +++ b/drivers/spi/spi-tegra114.c @@ -786,6 +786,11 @@ static int tegra_spi_start_transfer_one(struct spi_device *spi, total_fifo_words = tegra_spi_calculate_curr_xfer_param(spi, tspi, t); + if (t->rx_nbits == SPI_NBITS_DUAL || t->tx_nbits == SPI_NBITS_DUAL) + command1 |= SPI_BOTH_EN_BIT; + else + command1 &= ~SPI_BOTH_EN_BIT; + if (tspi->is_packed) command1 |= SPI_PACKED; else @@ -1152,7 +1157,8 @@ static int tegra_spi_probe(struct platform_device *pdev) master->max_speed_hz = 2500; /* 25MHz */ /* the spi->mode bits understood by this driver: */ - master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST; + master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST | + SPI_TX_DUAL | SPI_RX_DUAL; master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32); master->setup = tegra_spi_setup; master->transfer_one_message = tegra_spi_transfer_one_message; -- 2.20.1
Applied "spi: bcm2835aux: Fix build error without CONFIG_DEBUG_FS" to the spi tree
The patch
spi: bcm2835aux: Fix build error without CONFIG_DEBUG_FS
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9b186e9a65bffaef5ed56878095544b64584c29c Mon Sep 17 00:00:00 2001
From: YueHaibing
Date: Sat, 6 Apr 2019 23:14:57 +0800
Subject: [PATCH] spi: bcm2835aux: Fix build error without CONFIG_DEBUG_FS
When building CONFIG_DEBUG_FS is not set
gcc warn this:
drivers/spi/spi-bcm2835aux.c: In function bcm2835aux_spi_probe:
drivers/spi/spi-bcm2835aux.c:591:2: error: too many arguments to function
bcm2835aux_debugfs_create
bcm2835aux_debugfs_create(bs, dev_name(&pdev->dev));
^
drivers/spi/spi-bcm2835aux.c:145:13: note: declared here
static void bcm2835aux_debugfs_create(struct bcm2835aux_spi *bs)
Reported-by: Hulk Robot
Fixes: 8048d151eb4d ("spi: bcm2835aux: add driver stats to debugfs")
Signed-off-by: YueHaibing
Reviewed-by: Mukesh Ojha
Signed-off-by: Mark Brown
---
drivers/spi/spi-bcm2835aux.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index fd8252dce4a2..bbf87adb3ff8 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -142,7 +142,8 @@ static void bcm2835aux_debugfs_remove(struct bcm2835aux_spi
*bs)
bs->debugfs_dir = NULL;
}
#else
-static void bcm2835aux_debugfs_create(struct bcm2835aux_spi *bs)
+static void bcm2835aux_debugfs_create(struct bcm2835aux_spi *bs,
+ const char *dname)
{
}
--
2.20.1
[PATCH] lightnvm: pblk: fix crash in pblk_end_partial_read due to multipage bvecs
From: Hans Holmberg
Ever since '07173c3ec276 ("block: enable multipage bvecs")' we
need to handle bios with multipage bvecs in pblk.
Currently, a multipage bvec results in a crash[1].
Fix this by using bvec iterators in stead of direct bvec indexing.
Also add a dcache flush, for the same reasons as in:
'6e6e811d747b ("block: Add missing flush_dcache_page() call")'
[1] https://github.com/OpenChannelSSD/linux/issues/61
Reported-by: Klaus Jensen
Signed-off-by: Hans Holmberg
---
It ain't pretty, but let's fix the breakage while waiting for Igor's
partial read cleanup to be ready.
drivers/lightnvm/pblk-read.c | 50
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
index f08f7d9bd3be..27f8a76d8bd8 100644
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -230,14 +230,14 @@ static void pblk_end_partial_read(struct nvm_rq *rqd)
struct pblk_sec_meta *meta;
struct bio *new_bio = rqd->bio;
struct bio *bio = pr_ctx->orig_bio;
- struct bio_vec src_bv, dst_bv;
void *meta_list = rqd->meta_list;
- int bio_init_idx = pr_ctx->bio_init_idx;
unsigned long *read_bitmap = pr_ctx->bitmap;
+ struct bvec_iter orig_iter = BVEC_ITER_ALL_INIT;
+ struct bvec_iter new_iter = BVEC_ITER_ALL_INIT;
int nr_secs = pr_ctx->orig_nr_secs;
int nr_holes = nr_secs - bitmap_weight(read_bitmap, nr_secs);
void *src_p, *dst_p;
- int hole, i;
+ int bit, i;
if (unlikely(nr_holes == 1)) {
struct ppa_addr ppa;
@@ -256,33 +256,39 @@ static void pblk_end_partial_read(struct nvm_rq *rqd)
/* Fill the holes in the original bio */
i = 0;
- hole = find_first_zero_bit(read_bitmap, nr_secs);
- do {
- struct pblk_line *line;
+ for (bit = 0; bit < nr_secs; bit++) {
+ if (!test_bit(bit, read_bitmap)) {
+ struct bio_vec dst_bv, src_bv;
+ struct pblk_line *line;
- line = pblk_ppa_to_line(pblk, rqd->ppa_list[i]);
- kref_put(&line->ref, pblk_line_put);
+ line = pblk_ppa_to_line(pblk, rqd->ppa_list[i]);
+ kref_put(&line->ref, pblk_line_put);
- meta = pblk_get_meta(pblk, meta_list, hole);
- meta->lba = cpu_to_le64(pr_ctx->lba_list_media[i]);
+ meta = pblk_get_meta(pblk, meta_list, bit);
+ meta->lba = cpu_to_le64(pr_ctx->lba_list_media[i]);
- src_bv = new_bio->bi_io_vec[i++];
- dst_bv = bio->bi_io_vec[bio_init_idx + hole];
+ dst_bv = bio_iter_iovec(bio, orig_iter);
+ src_bv = bio_iter_iovec(new_bio, new_iter);
- src_p = kmap_atomic(src_bv.bv_page);
- dst_p = kmap_atomic(dst_bv.bv_page);
+ src_p = kmap_atomic(src_bv.bv_page);
+ dst_p = kmap_atomic(dst_bv.bv_page);
- memcpy(dst_p + dst_bv.bv_offset,
- src_p + src_bv.bv_offset,
- PBLK_EXPOSED_PAGE_SIZE);
+ memcpy(dst_p + dst_bv.bv_offset,
+ src_p + src_bv.bv_offset,
+ PBLK_EXPOSED_PAGE_SIZE);
- kunmap_atomic(src_p);
- kunmap_atomic(dst_p);
+ kunmap_atomic(src_p);
+ kunmap_atomic(dst_p);
- mempool_free(src_bv.bv_page, &pblk->page_bio_pool);
+ flush_dcache_page(dst_bv.bv_page);
+ mempool_free(src_bv.bv_page, &pblk->page_bio_pool);
- hole = find_next_zero_bit(read_bitmap, nr_secs, hole + 1);
- } while (hole < nr_secs);
+ bio_advance_iter(new_bio, &new_iter,
+ PBLK_EXPOSED_PAGE_SIZE);
+ i++;
+ }
+ bio_advance_iter(bio, &orig_iter, PBLK_EXPOSED_PAGE_SIZE);
+ }
bio_put(new_bio);
kfree(pr_ctx);
--
2.17.1
Applied "spi: pxa2xxx: change "no DMA channels..." msg from debug to warning" to the spi tree
The patch
spi: pxa2xxx: change "no DMA channels..." msg from debug to warning
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 8b57b11bc45ee512566513259cd3c302df3c9dae Mon Sep 17 00:00:00 2001
From: Flavio Suligoi
Date: Fri, 5 Apr 2019 14:40:22 +0200
Subject: [PATCH] spi: pxa2xxx: change "no DMA channels..." msg from debug to
warning
Change the type of the diagnostic message:
"no DMA channels available, using PIO"
from debug to warning.
The lack of an available DMA channel is very important regard the
spi-pxa2xx performance. The transfer speed can be reduced more than 50%.
So it is very important to warn the user about this, without enabling
the full SPI debug with CONFIG_SPI_DEBUG.
Moreover, enabling the full SPI debug only to enable this specific
debug message, the dmesg buffer fills quickly with a lot of
repetitive information during the SPI data transfer.
This cause the loss of all the first important messages
written during the initialization.
Signed-off-by: Flavio Suligoi
Signed-off-by: Mark Brown
---
drivers/spi/spi-pxa2xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 6160fe0ce7ab..f7068ccfe7d2 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1696,7 +1696,7 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
if (platform_info->enable_dma) {
status = pxa2xx_spi_dma_setup(drv_data);
if (status) {
- dev_dbg(dev, "no DMA channels available, using PIO\n");
+ dev_warn(dev, "no DMA channels available, using PIO\n");
platform_info->enable_dma = false;
} else {
controller->can_dma = pxa2xx_spi_can_dma;
--
2.20.1
Re: Removing pcap? (EZX support in mainline linux)
On Sun, 7 Apr 2019 16:07:41 +0200
Alexandre Belloni wrote:
> Hello Antonio, Harald,
>
Hi everyone,
adding Robert to CC as he is listed as the current maintainer of
ARM/EZX SMARTPHONES in the MAINTAINERS file.
> I've had a look at the PCAP RTC driver because I'm removing a few
> deprecated APIs. While doing so, I've discovered that the driver has
> never worked properly because PCAP_RTC_TOD_MASK and PCAP_RTC_DAY_MASK
> are both missing a bit so every day would roll over at 18:12:15 and the
> whole the date would roll over in 2014.
>
> I discussed with Arnd about 59ee93a528b9 ("ARM: pxa: remove irq_to_gpio
> from ezx-pcap driver") and it seems the whole EZX support has been
> broken for a while.
>
As Harald said in another message I tried taking over OpenEZX for a
while, but eventually lost interest.
JFTR some parts of the project has been backed up here:
https://gitlab.com/openezx
I should also have a git backup of the wiki somewhere.
> Is it worth fixing the RTC driver or could I remove it?
>
I am not aware of any active user but I'd leave the final word to
Robert, IIRC he received some EZX hardware "recently".
FWIW I think EZX code can be removed if it is a maintenance burden for
anyone.
Thank you,
Antonio
--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Re: [PATCH v3 19/36] thunderbolt: Extend tunnel creation to more than 2 adjacent switches
On Sun, Apr 07, 2019 at 06:54:25PM +0200, Lukas Wunner wrote:
> On Thu, Mar 28, 2019 at 03:36:16PM +0300, Mika Westerberg wrote:
> > +struct tb_path *tb_path_alloc(struct tb *tb, struct tb_port *src, int
> > src_hopid,
> > + struct tb_port *dst, int dst_hopid, int link_nr,
> > + const char *name)
> > {
> [...]
> > + in_hopid = src_hopid;
> > + out_port = NULL;
> > +
> > + for (i = 0; i < num_hops; i++) {
> > + in_port = tb_next_port_on_path(src, dst, out_port);
> > + if (!in_port)
> > + goto err;
> > +
> > + if (in_port->dual_link_port && in_port->link_nr != link_nr)
> > + in_port = in_port->dual_link_port;
> > +
> > + ret = tb_port_alloc_in_hopid(in_port, in_hopid, -1);
> > + if (ret < 0)
> > + goto err;
> > + in_hopid = ret;
> > +
> > + out_port = tb_next_port_on_path(src, dst, in_port);
> > + if (!out_port)
> > + goto err;
> > +
> > + if (out_port->dual_link_port && out_port->link_nr != link_nr)
> > + out_port = out_port->dual_link_port;
> > +
> > + if (i == num_hops - 1)
> > + ret = tb_port_alloc_out_hopid(out_port, dst_hopid,
> > + dst_hopid);
> > + else
> > + ret = tb_port_alloc_out_hopid(out_port, -1, -1);
> > +
> > + if (ret < 0)
> > + goto err;
> > + out_hopid = ret;
> > +
> > + path->hops[i].in_hop_index = in_hopid;
> > + path->hops[i].in_port = in_port;
> > + path->hops[i].in_counter_index = -1;
> > + path->hops[i].out_port = out_port;
> > + path->hops[i].next_hop_index = out_hopid;
> > +
> > + in_hopid = out_hopid;
> > + }
>
> According to the code comment in struct tb_regs_hop (in tb_regs.h),
> the out_hopid ("next_hop" in struct tb_regs_hop) denotes the
> "hop to take after sending the packet through out_port (on the
> incoming port of the next switch)".
>
> So intuitively, the hop config space is like a routing table and
> the entry in in_port's hop config space specifies through which
> out_port the packets shall be routed, and which entry to look up
> on the remote port reachable through out_port.
>
> This means that the out_hopid must always be identical to the in_hopid
> of out_port->remote. Otherwise the routing wouldn't work.
>
> And yet, you've introduced *two* struct ida for each port in
> patch 16. This doesn't seem to make sense: The out_hopids ida
> of a port always has to be identical to the in_hopids ida of that
> port's remote. But if it's identical, why does it have to exist
> twice?
The reason for two HopID allocators (struct idas) is to make it possible
to track HopIDs to each direction. The same port can be output for one
path and input for another. I'm not sure how that can be done without
having two struct idas per port.
You are right, in case of out port HopID connecter to remote in port,
they should use the same HopID.
> Also, the above algorithm fails to ensure that the two struct ida
> are always identical: It uses the out_hopid on the previous switch
> as *minimum* for the in_hopid on the current switch. If that hopid
> is already taken by an existing tunnel, tb_port_alloc_in_hopid()
> will allocate a *different* hopid and thereby break the routing.
>
> So either the code comment in struct tb_regs_hop is wrong, or this
> algorithm and the duplicate struct ida in patch 16 are wrong, or I'm
> missing something.
No you are right. I think the above code should look like:
ret = tb_port_alloc_in_hopid(in_port, in_hopid, in_hopid);
instead of
ret = tb_port_alloc_in_hopid(in_port, in_hopid, -1);
to make sure out port and in port of a remote use the same HopID. Will
fix.
Re: [PATCH 1/4] clk: meson: mpll: add init callback and regs
On Fri, 2019-04-05 at 13:43 -0700, Stephen Boyd wrote:
> Quoting Michael Turquette (2019-04-05 08:43:40)
> > Hi Jerome,
> >
> > On Fri, Mar 29, 2019 at 3:58 PM Jerome Brunet wrote:
> > > On Fri, 2019-03-29 at 15:14 -0700, Stephen Boyd wrote:
> > > > > > We actively discourage using init callbacks. Can you do this some
> > > > > > other
> > > > > > way?
> > > > >
> > > > > Yes I'm aware of that but init it the right place to do this.
> > > > > To be clear, this is not initializing the clock to some particular
> > > > > rate, the
> > > > > rate is preserved.
> > > > >
> > > > > It just applies the necessary settings that needs to be done only
> > > > > once to make
> > > > > sure the clock is in working order and that the rate calculated is
> > > > > actually
> > > > > accurate.
> > > >
> > > > Ok, but can you do that in your driver's probe routine instead of
> > > > attaching to the init callback? We want to get rid of "init" at some
> > > > point so throwing the init sequence stuff into the driver probe around
> > > > registration is a solution. Or we should think about not discouraging
> > > > the init callback
> > >
> > > Is is callback really a problem after all ?
> >
> > It is a problem, insofar as Stephen and I want to remove .init some day.
> >
> > > I think we should actively prevent using it to set a particular rate.
> > >
> > > Here, the goal is put the clock in working order. The bootloader does not
> > > always do that for us.
> >
> > The above two sentences make it sound like this sequence belongs in
> > .prepare().
> >
> > I know that you're concerned with setting rate, but I guess it is safe
> > to assume that you'll always complete .prepare() before you begin to
> > execute .set_rate(), no? This also avoids the ugliness of putting it
> > in the .probe(), which I agree doesn't feel like an accurate thing to
> > do for a clock's own programming sequence.
> >
> > .probe() is an OK place to put policy (turn these clocks on or set
> > them to this rate, for a known-good configuration).
> >
>
> Following along with this reasoning, maybe we need a 'prepare_once'
> callback that does this the first time the clk is prepared or set_rate
> is called on it. The problem I have with the init callback is that the
> semantics of when it's called and what has happened before it's called
> isn't clearly defined. I'm afraid to remove it and also afraid to move
> around where it's called from. I've been itching to get it out of under
> all the locks we're holding at registration time, but I don't know if
> that's feasible, for example.
>
If removing .init() is important for you, I would prefer to help guys. That
being said, we need a decent solution to some use case if this is going to
work.
I'll illustrate with examples from the meson code but I think they represent
fairly common cases:
1) clk-pll: Without the work done init(), the pll just won't lock ...
I agree that we would see the problem when the clock is finally enabled, so we
could do "init" sequence in .prepare() each time it is called. The sequence
might be "long" (with a couple of delays in it) so doing it on each call to
.prepare() is wasting time but it could work.
Something like .prepare_once would help for this.
2) clk-mpll: Without the work done in .init(), the fractional part of the
divider will not work, only the integer part works => the rate calculated is
off by a significant margin. IOW, until the initial setup is done, the result
of .recalc_rate() is off and cannot be trusted.
.prepare() (and .prepare_once() if called a the same stage) is too late. We
would need something that runs before any call to .recalc_rate() is made.
We could also think about clocks with the ability to observe and feedback
(read-only) on the actual output signal. Such thing might need an initial()
setup as well.
3) sclk: This is a kind of divider which gates when the value is zero. We need
to save the divider value on .disable() to restore it on .enable(). In
.init(), if divider value is 0 (gated) we init cached value to the maximum
divider value. This done so a call to .enable() works, even without prior
calls to .set_rate().
Here, again, I think .prepare() is a too late.
Maybe it is a bit extreme but we could also think about weird muxes not
reporting the parent accurately until some prior setting is done. For those
you need something that runs before all the orphan mechanism in the clock
register.
Whatever the name we give it, It think it would help if we had a (not
discouraged) callback that is guaranteed to run before anything else is called
on the clock. This is what I tried to do with 541debae0adf ("clk: call the
clock init() callback before any other ops callback").
Having the counterpart callback, guaranteed to run last, would allow a clock
to allocate (and de-allocate) stuff. It would be an interesting addition IMO.
For clocks which needs to store things (such as sclk), it would allow to take
the runtime data out of the ini
Re: [PATCH] pinctrl:intel: Retain HOSTSW_OWN for requested gpio pin
On Mon, Apr 08, 2019 at 12:21:03PM +0800, Chris Chiu wrote:
> +static void
> +intel_gpio_update_pad_mode(void __iomem *hostown, u32 mask, u32 value)
> +{
> + u32 curr = readl(hostown);
> + u32 updated = (curr & ~mask) | (value & mask);
I think here we should first complain if the expected ownership is not
correct. Warning or info level probably enough.
> +
> + return writel(updated, hostown);
Also if the pin is not requested and not changed we should not touch the
register.
Otherwise this looks good to me.
Re: [PATCH] intel-lpss: Set the device in reset state when init
On Mon, Apr 08, 2019 at 01:41:58PM +0800, Binbin Wu wrote: > In virtualized setup, when system reboots due to warm > reset interrupt storm is seen. > > Call Trace: > > dump_stack+0x70/0xa5 > __report_bad_irq+0x2e/0xc0 > note_interrupt+0x248/0x290 > ? add_interrupt_randomness+0x30/0x220 > handle_irq_event_percpu+0x54/0x80 > handle_irq_event+0x39/0x60 > handle_fasteoi_irq+0x91/0x150 > handle_irq+0x108/0x180 > do_IRQ+0x52/0xf0 > common_interrupt+0xf/0xf > > RIP: 0033:0x76fc2cfabc1d > Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e > 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 > <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04 > 24 > RSP: 002b:7ffd247c1fc0 EFLAGS: 0293 ORIG_RAX: ffda > RAX: RBX: 7ffd247c1ff0 RCX: 0003d3ce > RDX: RSI: 7ffd247c1ff0 RDI: 76fc2cbb6010 > RBP: 76fc2cded010 R08: 7ffd247c2210 R09: 7ffd247c22a0 > R10: 76fc29465470 R11: R12: 7ffd247c1fc0 > R13: 76fc2ce8e470 R14: 76fc27ec9960 R15: 0414 > handlers: > [<0d3fa913>] idma64_irq > Disabling IRQ #27 > > To avoid interrupt storm, set the device in reset state > before bringing out the device from reset state. > > Signed-off-by: Binbin Wu I think the correct subject line should be: "mfd: intel-lpss: Set the device in reset state when init" Regardless of that, Acked-by: Mika Westerberg
Re: [PATCH 0/5] Handle MCA banks in a per_cpu way
On Sun, Apr 07, 2019 at 11:13:47PM +, Ghannam, Yazen wrote: > Yazen Ghannam (5): > x86/MCE: Make struct mce_banks[] static > x86/MCE: Handle MCA controls in a per_cpu way > x86/MCE/AMD: Don't cache block addresses on SMCA systems > x86/MCE: Make number of MCA banks per_cpu > x86/MCE: Save MCA control bits that get set in hardware > > arch/x86/kernel/cpu/mce/amd.c | 87 +- > arch/x86/kernel/cpu/mce/core.c | 138 +++-- > arch/x86/kernel/cpu/mce/inject.c | 7 +- > arch/x86/kernel/cpu/mce/internal.h | 12 +-- > 4 files changed, 137 insertions(+), 107 deletions(-) This patchset doesn't apply cleanly. Please redo it against current tip/master. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
On Sat, Apr 06, 2019 at 01:45:10AM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index 91fecab58836..dccad79da90c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -238,6 +238,15 @@
> bias-pull-up;
> };
>
> +
Extra line
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> +"PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
Is that the only muxing option?
If so, then it should be assigned by default to mmc1
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
[PATCH] ARM: dts: imx6dl-sabreauto: update opp table for auto part
Update i.MX6DL automotive part's opp table according to i.MX6DL
automotive datasheet Rev.9, 11/2018, it adds 996MHz set-point
support as below:
LDO enabled(min value):
996MHz: VDDARM: 1.275V, VDDSOC: 1.175V;
792MHz: VDDARM: 1.150V, VDDSOC: 1.150V;
396MHz: VDDARM: 1.125V, VDDSOC: 1.150V;
Adding 25mV to cover board IR drop, for LDO enabled mode of 996MHz,
as the max value of LDO output can NOT exceed 1.3V, so 25mV is NOT
added for VDDARM.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6dl-sabreauto.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-sabreauto.dts
b/arch/arm/boot/dts/imx6dl-sabreauto.dts
index 660d52a..ff3283c8 100644
--- a/arch/arm/boot/dts/imx6dl-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6dl-sabreauto.dts
@@ -11,3 +11,18 @@
model = "Freescale i.MX6 DualLite/Solo SABRE Automotive Board";
compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl";
};
+
+&cpu0 {
+ operating-points = <
+ /* kHzuV */
+ 996000 1275000
+ 792000 1175000
+ 396000 115
+ >;
+ fsl,soc-operating-points = <
+ /* ARM kHz SOC-PU uV */
+ 996000 120
+ 792000 1175000
+ 396000 1175000
+ >;
+};
--
2.7.4
Re: [MD] 4bc034d353: aim7.jobs-per-min -86.0% regression
On Mon, Apr 08 2019, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -86.0% regression of aim7.jobs-per-min due to commit:
That is expected. The following commit
2bc13b83e6298486371761de503faeffd15b7534
should restore the performance.
NeilBrown
>
>
> commit: 4bc034d35377196c854236133b07730a777c4aba ("Revert "MD: fix lock
> contention for flush bios"")
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git
> for-5.2/block
>
> in testcase: aim7
> on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with
> 384G memory
> with following parameters:
>
> disk: 4BRD_12G
> md: RAID0
> fs: xfs
> test: sync_disk_rw
> load: 300
> cpufreq_governor: performance
>
> test-description: AIM7 is a traditional UNIX system level benchmark suite
> which is used to test and measure the performance of multiuser system.
> test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
>
>
signature.asc
Description: PGP signature
Re: [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs
* Alexey Dobriyan: >> >> Patch overloads sched_getaffinity(len=0) to simply return "nr_cpu_ids". >> >> This will make gettting CPU mask require at most 2 system calls >> >> and will eliminate unnecessary code. >> >> >> >> len=0 is chosen so that >> >> * passing zeroes is the simplest thing >> >> >> >> syscall(__NR_sched_getaffinity, 0, 0, NULL) >> >> >> >> will simply do the right thing, >> >> >> >> * old kernels returned -EINVAL unconditionally. >> >> >> >> Note: glibc segfaults upon exiting from system call because it tries to >> >> clear the rest of the buffer if return value is positive, so >> >> applications will have to use syscall(3). >> >> Good news is that it proves noone uses sched_getaffinity(pid, 0, NULL). >> >> Given that old kernels fail with EINVAL, that evidence is fairly >> restricted. >> >> I'm not sure if it's a good idea to overload this interface. I expect >> that users will want to call sched_getaffinity (the system call wrapper) >> with cpusetsize == 0 to query the value, so there will be pressure on >> glibc to remove the memset. At that point we have an API that obscurely >> fails with old glibc versions, but suceeds with newer ones, which isn't >> great. > > I can do "if (len == 536870912)" so that bit count overflows on old > kernels into EINVAL and is unlikely to be used ever. I don't see how this solves this particular issue. It will still result in a mysterious crash if programs use an updated system call wrapper. Thanks, Florian
Re: [PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of memory region initial size
On 04/06/19 at 06:43am, Borislav Petkov wrote: > On Sat, Apr 06, 2019 at 09:51:19AM +0800, Baoquan He wrote: > > It's KASLR happened in kernel_randomize_memory() of arch/x86/mm/kaslr.c . > > What is "KASLR happened in"? This doesn't make any sense. When you look > at that function, there's a comment above it: > > /* Initialize base and padding for each memory region randomized with KASLR */ > > Do you mean, that, per chance? > > > In fact, I don't know how to call it. Previously, I wrote it as mm > > KASLR, to distinguish from KASLR during kernel decompression. Ingo > > blamed the name, > > Of course he did, because it didn't make any sense to him either. > > > so I changed it to memory region KASLR. Seems Thomas > > Garnier called it KASLR for kernel memory regions in his original KASLR > > adding patch. May I call it 'KASLR for kernel memory regions', or 'KASLR > > for memory regions'? > > So you're fixing kaslr_regions[0].size_tb. It's base gets initialized to > page_offset_base. > > Now, if you look at > > Documentation/x86/x86_64/mm.txt > > it says there: > > 8880 | -119.5 TB | c87f | 64 TB | direct mapping > of all physical memory (page_offset_base) > > so that is the direct mapping memory region of all physical memory. > > Now, you're apparently fixing its size. > > Am I making sense and are you catching my drift? Yes, makes sense. I will make it more specific, and use kernel_randomize_memory() instead to indicate the place where code issue is found out. Thanks. > > You need to explain what you change in your commit messages in > *understandable* english so that reviewer/committer or even a person > who's not deeply involved in KASLR inner workings, can at least get an > idea about what the commit message is talking about. > > If you come up with strange constructs like "memory region KASLR" or > "KASLR happened in" or "mm KASLR" which only make sense in your head, > you're not doing anyone any favour. > > Commit messages need to be very understandable when someone is looking > at them months or even years from now. And you need to restrain yourself > when you write them. You will appreciate that the first time you have to > do git archeology, dig out an ancient commit and wonder why we did it > this way. > > Because we didn't document as good in previous years and our commits > from the past suck big time. > > Thanks! > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH 3/3] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2
is only generated and included by arch/arm/mach-omap2/, so it does not need to reside in the globally visible include/generated/. I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix 'omap2-' is just redundant in mach-omap2/. Signed-off-by: Masahiro Yamada --- Can this be applied to ARM-SOC tree in a series? (with Ack from the platform sub-maintainer.) ti-pm-asm-offsets.h does not need to reside in include/generated/, but you may ask "Why must it get out of include/generated/?" My main motivation is to avoid a race condition in the currently proposed patch: https://lore.kernel.org/patchwork/patch/1052763/ This patch tries to embed some build artifacts into the kernel. If arch/arm/mach-omap2/ and kernel/ are built at the same time, it may embed a truncated file. arch/arm/mach-omap2/.gitignore | 1 + arch/arm/mach-omap2/Makefile| 5 +++-- arch/arm/mach-omap2/sleep33xx.S | 2 +- arch/arm/mach-omap2/sleep43xx.S | 2 +- 4 files changed, 6 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-omap2/.gitignore diff --git a/arch/arm/mach-omap2/.gitignore b/arch/arm/mach-omap2/.gitignore new file mode 100644 index ..79a8d6ea7152 --- /dev/null +++ b/arch/arm/mach-omap2/.gitignore @@ -0,0 +1 @@ +pm-asm-offsets.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 85d1b13c9215..26baeb6477af 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -236,9 +236,10 @@ obj-y += omap_phy_internal.o obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o -include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s FORCE +$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__) -$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h +$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h targets += pm-asm-offsets.s +clean-files += pm-asm-offsets.h diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S index 47a816468cdb..a003769121aa 100644 --- a/arch/arm/mach-omap2/sleep33xx.S +++ b/arch/arm/mach-omap2/sleep33xx.S @@ -6,7 +6,6 @@ * Dave Gerlach, Vaibhav Bedia */ -#include #include #include #include @@ -15,6 +14,7 @@ #include "iomap.h" #include "cm33xx.h" +#include "pm-asm-offsets.h" #define AM33XX_CM_CLKCTRL_MODULESTATE_DISABLED 0x0003 #define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE 0x0003 diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S index 5b9343b58fc7..aa288f361c5e 100644 --- a/arch/arm/mach-omap2/sleep43xx.S +++ b/arch/arm/mach-omap2/sleep43xx.S @@ -6,7 +6,6 @@ * Dave Gerlach, Vaibhav Bedia */ -#include #include #include #include @@ -19,6 +18,7 @@ #include "iomap.h" #include "omap-secure.h" #include "omap44xx.h" +#include "pm-asm-offsets.h" #include "prm33xx.h" #include "prcm43xx.h" -- 2.17.1
[PATCH 2/3] ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91
is only generated and included by arch/arm/mach-at91/, so it does not need to reside in the globally visible include/generated/. I moved and renamed it to arch/arm/mach-at91/pm_data-offsets.h since the prefix 'at91_' is just redundant in mach-at91/. Signed-off-by: Masahiro Yamada --- Can this be applied to ARM-SOC tree in a series? (with Ack from the platform sub-maintainer.) at91_pm_data-offsets.h header does not need to reside in include/generated/, but you may ask "Why must it get out of include/generated/?" My main motivation is to avoid a race condition in the currently proposed patch: https://lore.kernel.org/patchwork/patch/1052763/ This patch tries to embed some build artifacts into the kernel. If arch/arm/mach-at91/ and kernel/ are built at the same time, it may embed a truncated file. arch/arm/mach-at91/.gitignore | 1 + arch/arm/mach-at91/Makefile | 5 +++-- arch/arm/mach-at91/pm_suspend.S | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-at91/.gitignore diff --git a/arch/arm/mach-at91/.gitignore b/arch/arm/mach-at91/.gitignore new file mode 100644 index ..2ecd6f51c8a9 --- /dev/null +++ b/arch/arm/mach-at91/.gitignore @@ -0,0 +1 @@ +pm_data-offsets.h diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile index 31b61f0e1c07..de64301dcff2 100644 --- a/arch/arm/mach-at91/Makefile +++ b/arch/arm/mach-at91/Makefile @@ -19,9 +19,10 @@ ifeq ($(CONFIG_PM_DEBUG),y) CFLAGS_pm.o += -DDEBUG endif -include/generated/at91_pm_data-offsets.h: arch/arm/mach-at91/pm_data-offsets.s FORCE +$(obj)/pm_data-offsets.h: $(obj)/pm_data-offsets.s FORCE $(call filechk,offsets,__PM_DATA_OFFSETS_H__) -arch/arm/mach-at91/pm_suspend.o: include/generated/at91_pm_data-offsets.h +$(obj)/pm_suspend.o: $(obj)/pm_data-offsets.h targets += pm_data-offsets.s +clean-files += pm_data-offsets.h diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S index bfe1c4d06901..a31c1b20f3fa 100644 --- a/arch/arm/mach-at91/pm_suspend.S +++ b/arch/arm/mach-at91/pm_suspend.S @@ -14,7 +14,7 @@ #include #include #include "pm.h" -#include "generated/at91_pm_data-offsets.h" +#include "pm_data-offsets.h" #defineSRAMC_SELF_FRESH_ACTIVE 0x01 #defineSRAMC_SELF_FRESH_EXIT 0x00 -- 2.17.1
[PATCH 1/3] ARM: visit mach-* and plat-* directories when cleaning
When you run "make clean" for arm, it never visits mach-* or plat-* directories because machine-y and plat-y are just empty. When cleaning, all machine, plat directories are accumulated to machine-, plat-, respectively. So, let's pass them to core- to clean up those directories. Signed-off-by: Masahiro Yamada --- arch/arm/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 807a7d06c2a0..b6693a3ddcca 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -293,6 +293,10 @@ core-y += arch/arm/crypto/ core-y += arch/arm/firmware/ core-y += $(machdirs) $(platdirs) +# For cleaning +core- += $(patsubst %,arch/arm/mach-%/, $(machine-)) +core- += $(patsubst %,arch/arm/plat-%/, $(plat-)) + drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/ libs-y := arch/arm/lib/ $(libs-y) -- 2.17.1
[PATCH v3 1/3] ARM: dts: da850: add cpu node and operating points to DT
From: David Lechner
This adds a cpu node and operating points to the common da850.dtsi file.
Additionally, a regulator is added to the LEGO EV3 board along with
some board-specific CPU configuration.
Regulators need to be hooked up on other boards to get them working.
Signed-off-by: David Lechner
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 31 +++
arch/arm/boot/dts/da850-lego-ev3.dts | 30 +++
arch/arm/boot/dts/da850.dtsi | 56
3 files changed, 117 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 26f453dc8370..f29ed9010812 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -155,12 +155,43 @@
};
};
};
+
+ cvdd: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "cvdd";
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <130>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&ref_clk {
clock-frequency = <2400>;
};
+&cpu {
+ cpu-supply = <&cvdd>;
+};
+
+/* LCDK has a fixed CVDD of 1.3V, so only op points >= 300MHz are valid */
+
+&opp_100 {
+ status = "disabled";
+};
+
+&opp_200 {
+ status = "disabled";
+};
+
+&opp_375 {
+ status = "okay";
+};
+
+&opp_456 {
+ status = "okay";
+};
+
&pmx_core {
status = "okay";
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 66fcadf0ba91..553717f84483 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -125,6 +125,15 @@
amp-supply = <&>;
};
+ cvdd: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "cvdd";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
/*
* This is a 5V current limiting regulator that is shared by USB,
* the sensor (input) ports, the motor (output) ports and the A/DC.
@@ -204,6 +213,27 @@
clock-frequency = <2400>;
};
+&cpu {
+ cpu-supply = <&cvdd>;
+};
+
+/* since we have a fixed regulator, we can't run at these points */
+&opp_100 {
+ status = "disabled";
+};
+
+&opp_200 {
+ status = "disabled";
+};
+
+/*
+ * The SoC is actually the 456MHz version, but because of the fixed regulator
+ * This is the fastest we can go.
+ */
+&opp_375 {
+ status = "okay";
+};
+
&pmx_core {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 559659b399d0..ee61d1253b58 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -20,6 +20,62 @@
reg = <0xc000 0x0>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu: cpu@0 {
+ compatible = "arm,arm926ej-s";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&psc0 14>;
+ operating-points-v2 = <&opp_table>;
+ };
+ };
+
+ opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp_100: opp100-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <100 95 105>;
+ };
+
+ opp_200: opp110-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <110 105 116>;
+ };
+
+ opp_300: opp120-3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <120 114 132>;
+ };
+
+ /*
+* Original silicon was 300MHz max, so higher frequencies
+* need to be enabled on a per-board basis if the chip is
+* capable.
+*/
+
+ opp_375: opp120-37500 {
+ status = "disabled";
+ opp-hz = /bits/ 64 <37500>;
+ opp-microvolt = <120 114 132>;
+ };
+
+ opp_415: opp130-41500 {
+ status = "disabled";
+ opp-hz = /bits/ 64 <41500>;
+ opp-microvolt = <130 125 135>;
+ };
+
+ opp_456: opp130-45600 {
+ status = "disabled";
+ opp-hz = /bits/ 64 <45600>;
+ opp-microvolt = <130 125 135>;
+ };
+
[PATCH v3 0/3] ARM: da850: enable cpufreq in DT mode
From: Bartosz Golaszewski This series adds cpufreq-dt operating points for da850 boards supported with device tree (da850-lcdk, da850-lego-ev3, da850-evm). Last patch enables CPUFREQ_DT in davinci_all_defconfig. v1 -> v2: - use the VDCDC3_1.2V regulator as cpu-supply on da850-evm v2 -> v3: - drop patch 1, as the revision tag is in fact correctly passed to the kernel by u-boot - only enable the 375 operating point for da850-evm as this is the standard frequency for this board Bartosz Golaszewski (1): ARM: dts: da850-evm: enable cpufreq David Lechner (2): ARM: dts: da850: add cpu node and operating points to DT ARM: davinci_all_defconfig: Enable CPUFREQ_DT arch/arm/boot/dts/da850-evm.dts| 13 ++ arch/arm/boot/dts/da850-lcdk.dts | 31 ++ arch/arm/boot/dts/da850-lego-ev3.dts | 30 ++ arch/arm/boot/dts/da850.dtsi | 56 ++ arch/arm/configs/davinci_all_defconfig | 1 + 5 files changed, 131 insertions(+) -- 2.21.0
[PATCH v3 3/3] ARM: davinci_all_defconfig: Enable CPUFREQ_DT
From: David Lechner This sets CONFIG_CPUFREQ_DT=m in davinci_all_defconfig. This is used for frequency scaling on device tree boards. Signed-off-by: David Lechner Signed-off-by: Bartosz Golaszewski --- arch/arm/configs/davinci_all_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index 207962a656a2..c3502236132e 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -45,6 +45,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m +CONFIG_CPUFREQ_DT=m CONFIG_CPU_IDLE=y CONFIG_NET=y CONFIG_PACKET=y -- 2.21.0
[PATCH v3 2/3] ARM: dts: da850-evm: enable cpufreq
From: Bartosz Golaszewski
Enable cpufreq-dt support for da850-evm. The cvdd is supplied by the
tps6507 pmic with configurable output voltage, so all operating points
can be enabled.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-evm.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index f04bc3e15332..f94bb38fdad9 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -191,6 +191,19 @@
};
};
+&cpu {
+ cpu-supply = <&vdcdc3_reg>;
+};
+
+/*
+ * The standard da850-evm kits and SOM's are 375MHz so enable this operating
+ * point by default. Higher frequencies must be enabled for custom boards with
+ * other variants of the SoC.
+ */
+&opp_375 {
+ status = "okay";
+};
+
&sata {
status = "okay";
};
--
2.21.0
Re: [PATCH 0/4] clk: meson: g12a audio clock controller support
On 29/03/2019 17:06, Jerome Brunet wrote: > This patchset updates the axg audio controller to support the audio > controller of the g12a SoC family. > > Jerome Brunet (3): > dt-bindings: clk: axg-audio: add g12a support > clk: meson: axg_audio: replace prefix axg by aud > clk: meson: axg-audio: don't register inputs in the onecell data > > Maxime Jourdan (1): > clk: meson: axg-audio: add g12a support > > .../bindings/clock/amlogic,axg-audio-clkc.txt |3 +- > drivers/clk/meson/axg-audio.c | 1219 ++--- > drivers/clk/meson/axg-audio.h | 36 +- > include/dt-bindings/clock/axg-audio-clkc.h| 10 + > 4 files changed, 736 insertions(+), 532 deletions(-) > Applied patch 1 to next/headers and patch [2, 3, 4] to next/drivers for Linux 5.2-rc1 Neil
Re: [PATCH v3 3/4] lib: logic_pio: Reject accesses to unregistered CPU MMIO regions
On 05/04/2019 19:06, Bjorn Helgaas wrote:
On Fri, Apr 05, 2019 at 09:10:27AM +0100, John Garry wrote:
On 04/04/2019 19:58, Bjorn Helgaas wrote:
On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote:
On Thu, Apr 04, 2019 at 05:52:35PM +0100, John Garry wrote:
Note that the f71805f driver does not call
request_{muxed_}region(), as it should.
... which is the real problem, one that is not solved by this
patch. This may result in parallel and descructive accesses if
there is another device on the LPC bus, and another driver
accessing that device. Personally I'd rather have
request_muxed_region() added to the f71805f driver.
Right, we should and will still fix f71805f. If you recall, I did
have the f71805f fix in the v1 series, but you committed that it
was orthogonal, so I decided to take it out of this work for now.
And even if we fix up f71805f and other known drivers which don't
call request_muxed_region(), we still need to police against these
rogue accesses, which is what this patch attempts to do.
Do we ? I am personally not convinced that LPC accesses _have_ to
occur through PCI on any given system.
On current systems, I suspect ISA/LPC devices are typically connected
via a PCI-to-ISA/LPC bridge. But AFAIK there's no actual requirement
for that bridge, and there certainly *were* systems with ISA devices
but no PCI at all.
IMO, if you want to build ISA drivers on your arch, you need to make
sure the inb() probing done by those drivers works like it does on
x86. If there's no device there, the inb() should return 0xff with no
fuss and no crash.
Right, and this is what I am attempting to do here.
So today a call to request_muxed_region() can still succeed even if no IO
space mapped.
As such, even well-behaved drivers like f71882fg can still crash the system,
as noted in RFC patch 1/4 ("resource: Request IO port regions from children
of ioport_resource").
Correction:
"As such, *on arm* even well-behaved drivers like f71882fg can still
crash the system, ...
So, yes, x86 - which has native IO ports - would not have this issue.
Maybe I'm missing something, but on x86, drivers like f71882fg do not
crash the system because inb() *never* causes a crash.
If you want to build that driver for ARM, I think you need to make
sure that inb() on ARM also *never* causes a crash. I don't think
changing f71882fg and all the similar drivers is the right answer.
Right, so this is the intention of this patch.
However it would be still good to find a way to fail a request to claim
an IO port region if none is accessible or mapped.
Thanks,
John
Bjorn
.
Re: [PATCH] modpost: make KBUILD_MODPOST_WARN also configurable for external modules
Hi!
On 07.04.2019 11:04, Masahiro Yamada wrote:
> (+CC Jonas Gorski)
>
>
> On Tue, Mar 26, 2019 at 6:58 PM Wiebe, Wladislav (Nokia - DE/Ulm)
> wrote:
>>
>> Commit ea837f1c0503 ("kbuild: make modpost processing configurable")
>> was intended to give KBUILD_MODPOST_WARN flexibility to be configurable.
>> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is
>> set which happens per default when building modules out of the tree.
>>
>> This change gives the opportunity to define module build behaving also
>> in case of out of tree builds and default will become exit on error.
>> Errors which can be detected by the build should be trapped out of the box
>> there, unless somebody wants to notice broken stuff later at runtime.
>
> If an external module refers to a symbol
> provided by another external module,
> this patch will turn the warning into the error by default,
> which is probably a bad idea.
Indeed, exactly this should happen. You should fix your external module
dependencies by providing their symbols. Please use e.g.
KBUILD_EXTRA_SYMBOLS instead of converting errors to warning and hoping
that things will work. Or how do you want to make sure module A still
delivers all symbols needed by module B after an update/changes?
Manually comparing the logs after an update or waiting until it turns
out broken during run-time? I wouldn't say this is a good idea :-)
> I suggested a desired change in the following.
> https://patchwork.kernel.org/patch/9980691/
>
> I am poking Jonas Gorski
> if he plans to send v2.
I wouldn't vote for v2 based on explanation above.
- Wladislav
>
>
>> Signed-off-by: Wladislav Wiebe
>> ---
>> scripts/Makefile.modpost | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
>> index 6b7f354f189a..fec6ec2ffa47 100644
>> --- a/scripts/Makefile.modpost
>> +++ b/scripts/Makefile.modpost
>> @@ -78,7 +78,7 @@ modpost = scripts/mod/modpost\
>>$(if $(KBUILD_EXTRA_SYMBOLS), $(patsubst %, -e
>> %,$(KBUILD_EXTRA_SYMBOLS))) \
>>$(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \
>>$(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E) \
>> - $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
>> + $(if $(KBUILD_MODPOST_WARN),-w)
>>
>> MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS)))
>>
>> --
>> 2.19.2
>
>
>
RE: [PATCH] intel-lpss: Set the device in reset state when init
Hi Mika, Will correct the title line in the next version. Thanks. -- Best wishes, Binbin > -Original Message- > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: Monday, April 8, 2019 3:43 PM > To: Wu, Binbin > Cc: r...@rjwysocki.net; linux...@vger.kernel.org; > gre...@linuxfoundation.org; lee.jo...@linaro.org; linux- > ker...@vger.kernel.org; dmaeng...@vger.kernel.org; > andriy.shevche...@linux.intel.com > Subject: Re: [PATCH] intel-lpss: Set the device in reset state when init > > On Mon, Apr 08, 2019 at 01:41:58PM +0800, Binbin Wu wrote: > > In virtualized setup, when system reboots due to warm reset interrupt > > storm is seen. > > > > Call Trace: > > > > dump_stack+0x70/0xa5 > > __report_bad_irq+0x2e/0xc0 > > note_interrupt+0x248/0x290 > > ? add_interrupt_randomness+0x30/0x220 > > handle_irq_event_percpu+0x54/0x80 > > handle_irq_event+0x39/0x60 > > handle_fasteoi_irq+0x91/0x150 > > handle_irq+0x108/0x180 > > do_IRQ+0x52/0xf0 > > common_interrupt+0xf/0xf > > > > RIP: 0033:0x76fc2cfabc1d > > Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e > > 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 <48> > > 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04 > > 24 > > RSP: 002b:7ffd247c1fc0 EFLAGS: 0293 ORIG_RAX: ffda > > RAX: RBX: 7ffd247c1ff0 RCX: 0003d3ce > > RDX: RSI: 7ffd247c1ff0 RDI: 76fc2cbb6010 > > RBP: 76fc2cded010 R08: 7ffd247c2210 R09: 7ffd247c22a0 > > R10: 76fc29465470 R11: R12: 7ffd247c1fc0 > > R13: 76fc2ce8e470 R14: 76fc27ec9960 R15: 0414 > > handlers: > > [<0d3fa913>] idma64_irq > > Disabling IRQ #27 > > > > To avoid interrupt storm, set the device in reset state before > > bringing out the device from reset state. > > > > Signed-off-by: Binbin Wu > > I think the correct subject line should be: > > "mfd: intel-lpss: Set the device in reset state when init" > > Regardless of that, > > Acked-by: Mika Westerberg
[PATCH v2] Add COMPILE_TEST to CONFIG_ARM_TIMER_SP804
This is only used on arm and arm64 platforms. Add COMPILE_TEST option. Tested with 5.1-rc3+ on Fedora/RISCV. CONFIG_ARM_TIMER_SP804 no more shows up in riscv config. Signed-off-by: David Abdurachmanov --- drivers/clocksource/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 171502a356aa..ede5d20299b9 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -379,7 +379,7 @@ config ARM_GLOBAL_TIMER This options enables support for the ARM global timer unit config ARM_TIMER_SP804 - bool "Support for Dual Timer SP804 module" + bool "Support for Dual Timer SP804 module" if COMPILE_TEST depends on GENERIC_SCHED_CLOCK && CLKDEV_LOOKUP select CLKSRC_MMIO select TIMER_OF if OF -- 2.20.1
Re: [PATCH v3 6/9] arm64: dts: qcom: qcs404: Add rpmpd node
On 2019-03-27 18:08, Sibi Sankar wrote:
From: Bjorn Andersson
Add the rpmpd node on the qcs404 and define the available levels.
Signed-off-by: Bjorn Andersson
[sibis: fixup available levels]
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 55
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index e8fd26633d57..a7d46647c416 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -230,6 +231,60 @@
compatible = "qcom,rpmcc-qcs404";
#clock-cells = <1>;
};
+
+ rpmpd: power-controller {
+ compatible = "qcom,qcs404-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmpd_opp_table>;
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ rpmpd_opp_ret: opp1 {
+ opp-level =
;
+ };
+
+ rpmpd_opp_ret_plus: opp2 {
+ opp-level =
;
+ };
+
+ rpmpd_opp_min_svs: opp3 {
+ opp-level =
;
+ };
+
+ rpmpd_opp_low_svs: opp4 {
+ opp-level =
;
+ };
+
typo in opp5 - opp11 rpmhpd/rpmpd
will fix it in the next re-spin
+ rpmhpd_opp_svs: opp5 {
+ opp-level = ;
+ };
+
+ rpmhpd_opp_svs_plus: opp6 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_nom: opp7 {
+ opp-level = ;
+ };
+
+ rpmhpd_opp_nom_plus: opp8 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_turbo_no_cpr: opp10 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_turbo_plus: opp11 {
+ opp-level =
;
+ };
+ };
+ };
};
};
--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH v3 9/9] arm64: dts: qcom: msm8998: Add rpmpd node
On 2019-03-27 18:08, Sibi Sankar wrote:
Add the rpmpd node on the msm8998 and define the available levels.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 3fd0769fe648..b7e3e0646b9b 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -272,6 +273,56 @@
compatible = "qcom,rpmcc-msm8998", "qcom,rpmcc";
#clock-cells = <1>;
};
+
+ rpmpd: power-controller {
+ compatible = "qcom,msm8998-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmpd_opp_table>;
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ rpmpd_opp_ret: opp1 {
+ opp-level =
;
+ };
+
+ rpmpd_opp_ret_plus: opp2 {
+ opp-level =
;
+ };
+
+ rpmpd_opp_min_svs: opp3 {
+ opp-level =
;
+ };
+
+ rpmpd_opp_low_svs: opp4 {
+ opp-level =
;
+ };
+
typo in opp5 - opp10 rpmhpd/rpmpd
will fix it in the next re-spin
+ rpmhpd_opp_svs: opp5 {
+ opp-level = ;
+ };
+
+ rpmhpd_opp_svs_plus: opp6 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_nom: opp7 {
+ opp-level = ;
+ };
+
+ rpmhpd_opp_nom_plus: opp8 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ opp-level =
;
+ };
+
+ rpmhpd_opp_turbo_plus: opp10 {
+ opp-level =
;
+ };
+ };
+ };
};
};
--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[RFC PATCH v3 1/4] x86: Add new config symbol to unify conditional definition of hv_irq_callback_count
Now the CONFIG_HYPERV and CONFIG_XEN can be used to control the definition
/usage of hv_irq_callback_count. If another linux guest also needs to use
the hv_irq_callback_count, current conditional definition looks unreadable.
Signed-off-by: Zhao Yakui
---
arch/x86/Kconfig | 3 +++
arch/x86/include/asm/hardirq.h | 2 +-
arch/x86/kernel/irq.c | 2 +-
arch/x86/xen/Kconfig | 1 +
drivers/hv/Kconfig | 1 +
5 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5ad9241..54d1fbc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,9 @@ config QUEUED_LOCK_STAT
behavior of paravirtualized queued spinlocks and report
them on debugfs.
+config X86_HV_CALLBACK_VECTOR
+ def_bool n
+
source "arch/x86/xen/Kconfig"
config KVM_GUEST
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index d9069bb..0753379 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -37,7 +37,7 @@ typedef struct {
#ifdef CONFIG_X86_MCE_AMD
unsigned int irq_deferred_error_count;
#endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#ifdef CONFIG_X86_HV_CALLBACK_VECTOR
unsigned int irq_hv_callback_count;
#endif
#if IS_ENABLED(CONFIG_HYPERV)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 59b5f2e..a147826 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -134,7 +134,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_printf(p, "%10u ", per_cpu(mce_poll_count, j));
seq_puts(p, " Machine check polls\n");
#endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#ifdef CONFIG_X86_HV_CALLBACK_VECTOR
if (test_bit(HYPERVISOR_CALLBACK_VECTOR, system_vectors)) {
seq_printf(p, "%*s: ", prec, "HYP");
for_each_online_cpu(j)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index e07abef..ba5a418 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -7,6 +7,7 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
+ select X86_HV_CALLBACK_VECTOR
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 1c1a251..cafcb97 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -6,6 +6,7 @@ config HYPERV
tristate "Microsoft Hyper-V client drivers"
depends on X86 && ACPI && X86_LOCAL_APIC && HYPERVISOR_GUEST
select PARAVIRT
+ select X86_HV_CALLBACK_VECTOR
help
Select this option to run Linux as a Hyper-V client operating
system.
--
2.7.4
[PATCH v2] mfd: intel-lpss: Set the device in reset state when init
In virtualized setup, when system reboots due to warm
reset interrupt storm is seen.
Call Trace:
dump_stack+0x70/0xa5
__report_bad_irq+0x2e/0xc0
note_interrupt+0x248/0x290
? add_interrupt_randomness+0x30/0x220
handle_irq_event_percpu+0x54/0x80
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x91/0x150
handle_irq+0x108/0x180
do_IRQ+0x52/0xf0
common_interrupt+0xf/0xf
RIP: 0033:0x76fc2cfabc1d
Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
24
RSP: 002b:7ffd247c1fc0 EFLAGS: 0293 ORIG_RAX: ffda
RAX: RBX: 7ffd247c1ff0 RCX: 0003d3ce
RDX: RSI: 7ffd247c1ff0 RDI: 76fc2cbb6010
RBP: 76fc2cded010 R08: 7ffd247c2210 R09: 7ffd247c22a0
R10: 76fc29465470 R11: R12: 7ffd247c1fc0
R13: 76fc2ce8e470 R14: 76fc27ec9960 R15: 0414
handlers:
[<0d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state
before bringing out the device from reset state.
Changelog v2:
- correct the subject line by adding "mfd: "
Signed-off-by: Binbin Wu
Acked-by: Mika Westerberg
---
drivers/mfd/intel-lpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 50bffc3..ff3fba1 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss
*lpss)
{
u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+ /* Set the device in reset state */
+ writel(0, lpss->priv + LPSS_PRIV_RESETS);
+
intel_lpss_deassert_reset(lpss);
intel_lpss_set_remap_addr(lpss);
--
2.7.4
[RFC PATCH v3 0/4] x86: Add the support of ACRN guest under arch/x86
ACRN is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform. It is built for embedded IOT with small footprint and real-time features. More details can be found in https://projectacrn.org/ This is the patch set that allows the Linux to work on ACRN hypervisor and it can work with the following patch set to manage the Linux guest on acrn-hypervisor. It includes the detection of acrn_hypervisor, upcall notification vector from hypervisor, hypercall. The hypervisor detection is similar to Xen/VMWARE/Hyperv. ACRN also uses the upcall notification mechanism similar to that in Xen/Microsoft HyperV when it needs to send the notification to Linux OS. The hypercall provides the mechanism that can be used to query/configure the acrn-hypervisor by Linux guest. Following this patch set, we will send acrn driver part, which provides the interface that can be used to manage the virtualized CPU/memory/device/interrupt for other guest OS after the acrn hypervisor is detected. v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to understand. Remove the export of x86_hyper_acrn. Remove the unused API definition of acrn_setup_intr_handler and acrn_remove_intr_handler. Adjust the order of header file Add the declaration of acrn_hv_vector_handler and tracing definition of acrn_hv_callback_vector. Refine the comments for the function of acrn_hypercall0/1/2 v2-v3: Add one new config symbol to unify the conditional definition of hv_irq_callback_count Use the "vmcall" mnemonic to replace the hard-code byte definition Remove the unnecessary dependency of CONFIG_PARAVIRT for ACRN_GUEST Zhao Yakui (4): x86: Add new config symbol to unify conditional definition of hv_irq_callback_count x86: Add the support of ACRN guest x86: Use HYPERVISOR_CALLBACK_VECTOR for acrn_guest upcall vector x86: Add hypercall for acrn_guest arch/x86/Kconfig | 12 + arch/x86/entry/entry_64.S | 5 +++ arch/x86/include/asm/acrn_hypercall.h | 82 +++ arch/x86/include/asm/acrnhyper.h | 19 arch/x86/include/asm/hardirq.h| 2 +- arch/x86/include/asm/hypervisor.h | 1 + arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/acrn.c| 57 arch/x86/kernel/cpu/hypervisor.c | 4 ++ arch/x86/kernel/irq.c | 2 +- arch/x86/xen/Kconfig | 1 + drivers/hv/Kconfig| 1 + 12 files changed, 185 insertions(+), 2 deletions(-) create mode 100644 arch/x86/include/asm/acrn_hypercall.h create mode 100644 arch/x86/include/asm/acrnhyper.h create mode 100644 arch/x86/kernel/cpu/acrn.c -- 2.7.4
[RFC PATCH v3 4/4] x86: Add hypercall for acrn_guest
When acrn_hypervisor is detected, the hypercall is needed so that the
acrn guest can query/config some settings. For example: it can be used
to query the resources in hypervisor and manage the CPU/memory/device/
interrupt for Guest system.
So the hypercall is added so that the kernel can communicate with the
low-level acrn-hypervisor. On x86 it is implemented by using vmacll when
the acrn hypervisor is enabled.
Co-developed-by: Jason Chen CJ
Signed-off-by: Jason Chen CJ
Signed-off-by: Zhao Yakui
---
V1->V2: Refine the comments for the function of acrn_hypercall0/1/2
v2->v3: Use the "vmcall" mnemonic to replace hard-code byte definition
---
arch/x86/include/asm/acrn_hypercall.h | 82 +++
1 file changed, 82 insertions(+)
create mode 100644 arch/x86/include/asm/acrn_hypercall.h
diff --git a/arch/x86/include/asm/acrn_hypercall.h
b/arch/x86/include/asm/acrn_hypercall.h
new file mode 100644
index 000..82c1577
--- /dev/null
+++ b/arch/x86/include/asm/acrn_hypercall.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_X86_ACRNHYPERCALL_H
+#define _ASM_X86_ACRNHYPERCALL_H
+
+#include
+
+#ifdef CONFIG_ACRN_GUEST
+
+/*
+ * Hypercalls for ACRN Guest
+ *
+ * Hypercall number is passed in r8 register.
+ * Return value will be placed in rax.
+ * Up to 2 arguments are passed in rdi, rsi.
+ */
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+ register unsigned long r8 asm("r8") = hcall_id;
+ register long result asm("rax");
+
+ /* vmcall is used to implment the hypercall.
+* asm volatile is used to avoid that it is dropped because of
+* compiler optimization.
+*/
+ asm volatile("vmcall"
+ : "=r"(result)
+ : "r"(r8));
+
+ return result;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+ unsigned long param1)
+{
+ register unsigned long r8 asm("r8") = hcall_id;
+ register long result asm("rax");
+
+ asm volatile("vmcall"
+ : "=r"(result)
+ : "D"(param1), "r"(r8));
+
+ return result;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+ unsigned long param1,
+ unsigned long param2)
+{
+ register unsigned long r8 asm("r8") = hcall_id;
+ register long result asm("rax");
+
+ asm volatile("vmcall"
+ : "=r"(result)
+ : "D"(param1), "S"(param2), "r"(r8));
+
+ return result;
+}
+
+#else
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+ return -ENOTSUPP;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+ unsigned long param1)
+{
+ return -ENOTSUPP;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+ unsigned long param1,
+ unsigned long param2)
+{
+ return -ENOTSUPP;
+}
+#endif
+
+#endif /* _ASM_X86_ACRNHYPERCALL_H */
--
2.7.4
[RFC PATCH v3 3/4] x86: Use HYPERVISOR_CALLBACK_VECTOR for acrn_guest upcall vector
Linux kernel uses the HYPERVISOR_CALLBACK_VECTOR for hypervisor upcall
vector. And it is already used for Xen and HyperV.
After Acrn hypervisor is detected, it will also use this defined vector
to notify kernel.
Co-developed-by: Jason Chen CJ
Signed-off-by: Jason Chen CJ
Signed-off-by: Zhao Yakui
---
V1->V2: Remove the unused API definition of acrn_setup_intr_handler and
acrn_remove_intr_handler.
Adjust the order of header file
Add the declaration of acrn_hv_vector_handler and tracing
definition of acrn_hv_callback_vector.
---
arch/x86/Kconfig | 1 +
arch/x86/entry/entry_64.S| 5 +
arch/x86/include/asm/acrnhyper.h | 19 +++
arch/x86/kernel/cpu/acrn.c | 22 ++
4 files changed, 47 insertions(+)
create mode 100644 arch/x86/include/asm/acrnhyper.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d77d215..ae4d38b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -848,6 +848,7 @@ config JAILHOUSE_GUEST
config ACRN_GUEST
bool "ACRN Guest support"
depends on X86_64
+ select X86_HV_CALLBACK_VECTOR
help
This option allows to run Linux as guest in ACRN hypervisor. Enabling
this will allow the kernel to boot in virtualized environment under
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1f0efdb..d1b8ad3 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1129,6 +1129,11 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
hv_stimer0_callback_vector hv_stimer0_vector_handler
#endif /* CONFIG_HYPERV */
+#if IS_ENABLED(CONFIG_ACRN_GUEST)
+apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
+ acrn_hv_callback_vector acrn_hv_vector_handler
+#endif
+
idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
idtentry int3 do_int3 has_error_code=0
idtentry stack_segment do_stack_segmenthas_error_code=1
diff --git a/arch/x86/include/asm/acrnhyper.h b/arch/x86/include/asm/acrnhyper.h
new file mode 100644
index 000..9f9c239
--- /dev/null
+++ b/arch/x86/include/asm/acrnhyper.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ACRNHYPER_H
+#define _ASM_X86_ACRNHYPER_H
+
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_ACRN_GUEST
+void acrn_hv_callback_vector(void);
+#ifdef CONFIG_TRACING
+#define trace_acrn_hv_callback_vector acrn_hv_callback_vector
+#endif
+
+void acrn_hv_vector_handler(struct pt_regs *regs);
+#endif
+
+#endif
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index 3956567..7a233b5 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -9,7 +9,11 @@
*
*/
+#include
#include
+#include
+#include
+#include
static uint32_t __init acrn_detect(void)
{
@@ -18,6 +22,8 @@ static uint32_t __init acrn_detect(void)
static void __init acrn_init_platform(void)
{
+ alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
+ acrn_hv_callback_vector);
}
static bool acrn_x2apic_available(void)
@@ -26,6 +32,22 @@ static bool acrn_x2apic_available(void)
return false;
}
+static void (*acrn_intr_handler)(void);
+
+__visible void __irq_entry acrn_hv_vector_handler(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+
+ entering_ack_irq();
+ inc_irq_stat(irq_hv_callback_count);
+
+ if (acrn_intr_handler)
+ acrn_intr_handler();
+
+ exiting_irq();
+ set_irq_regs(old_regs);
+}
+
const __initconst struct hypervisor_x86 x86_hyper_acrn = {
.name = "ACRN",
.detect = acrn_detect,
--
2.7.4
[RFC PATCH v3 2/4] x86: Add the support of ACRN guest
ACRN is an open-source hypervisor maintained by Linuxfoundation.
This is to add the Linux guest support on acrn-hypervisor.
Add x86_hyper_acrn into supported hypervisors array, which enables
Linux ACRN guest running on ACRN hypervisor. It is restricted to X86_64.
Co-developed-by: Jason Chen CJ
Signed-off-by: Jason Chen CJ
Signed-off-by: Zhao Yakui
---
v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to
understand.
Remove the export of x86_hyper_acrn.
v2->v3: Remove the unnecessary dependency of PARAVIRT
---
arch/x86/Kconfig | 8
arch/x86/include/asm/hypervisor.h | 1 +
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/acrn.c| 35 +++
arch/x86/kernel/cpu/hypervisor.c | 4
5 files changed, 49 insertions(+)
create mode 100644 arch/x86/kernel/cpu/acrn.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 54d1fbc..d77d215 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -845,6 +845,14 @@ config JAILHOUSE_GUEST
cell. You can leave this option disabled if you only want to start
Jailhouse and run Linux afterwards in the root cell.
+config ACRN_GUEST
+ bool "ACRN Guest support"
+ depends on X86_64
+ help
+ This option allows to run Linux as guest in ACRN hypervisor. Enabling
+ this will allow the kernel to boot in virtualized environment under
+ the ACRN hypervisor.
+
endif #HYPERVISOR_GUEST
source "arch/x86/Kconfig.cpu"
diff --git a/arch/x86/include/asm/hypervisor.h
b/arch/x86/include/asm/hypervisor.h
index 8c5aaba..50a30f6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -29,6 +29,7 @@ enum x86_hypervisor_type {
X86_HYPER_XEN_HVM,
X86_HYPER_KVM,
X86_HYPER_JAILHOUSE,
+ X86_HYPER_ACRN,
};
#ifdef CONFIG_HYPERVISOR_GUEST
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index cfd24f9..17a7cdf 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_X86_CPU_RESCTRL) += resctrl/
obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
obj-$(CONFIG_HYPERVISOR_GUEST) += vmware.o hypervisor.o mshyperv.o
+obj-$(CONFIG_ACRN_GUEST) += acrn.o
ifdef CONFIG_X86_FEATURE_NAMES
quiet_cmd_mkcapflags = MKCAP $@
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
new file mode 100644
index 000..3956567
--- /dev/null
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ACRN detection support
+ *
+ * Copyright (C) 2019 Intel Corporation. All rights reserved.
+ *
+ * Jason Chen CJ
+ * Zhao Yakui
+ *
+ */
+
+#include
+
+static uint32_t __init acrn_detect(void)
+{
+ return hypervisor_cpuid_base("ACRNACRNACRN\0\0", 0);
+}
+
+static void __init acrn_init_platform(void)
+{
+}
+
+static bool acrn_x2apic_available(void)
+{
+ /* do not support x2apic */
+ return false;
+}
+
+const __initconst struct hypervisor_x86 x86_hyper_acrn = {
+ .name = "ACRN",
+ .detect = acrn_detect,
+ .type = X86_HYPER_ACRN,
+ .init.init_platform = acrn_init_platform,
+ .init.x2apic_available = acrn_x2apic_available,
+};
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 479ca47..87e39ad 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -32,6 +32,7 @@ extern const struct hypervisor_x86 x86_hyper_xen_pv;
extern const struct hypervisor_x86 x86_hyper_xen_hvm;
extern const struct hypervisor_x86 x86_hyper_kvm;
extern const struct hypervisor_x86 x86_hyper_jailhouse;
+extern const struct hypervisor_x86 x86_hyper_acrn;
static const __initconst struct hypervisor_x86 * const hypervisors[] =
{
@@ -49,6 +50,9 @@ static const __initconst struct hypervisor_x86 * const
hypervisors[] =
#ifdef CONFIG_JAILHOUSE_GUEST
&x86_hyper_jailhouse,
#endif
+#ifdef CONFIG_ACRN_GUEST
+ &x86_hyper_acrn,
+#endif
};
enum x86_hypervisor_type x86_hyper_type;
--
2.7.4
[PATCH V3 1/2] trace,x86: Add external_interrupts to the irq_vectors class
Currently, the irq_vectors is showing the entry and exit events for
the interrupts of the architecture, but not for external interrupts.
Adds the tracepoints for external interrupts.
Example of output:
-0 [000] d.h. 102.890935: external_interrupt_entry: vector=35
-0 [000] d.h. 102.890960: external_interrupt_exit: vector=35
Changes from V1:
- Fix a compilation problem when CONFIG_X86_LOCAL_APIC is not set.
(kbuild test)
Signed-off-by: Daniel Bristot de Oliveira
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Andy Lutomirski
Cc: Clark Williams
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
---
arch/x86/include/asm/trace/irq_vectors.h | 10 +-
arch/x86/kernel/irq.c| 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/trace/irq_vectors.h
b/arch/x86/include/asm/trace/irq_vectors.h
index 33b9d0f0aafe..38e73d56db70 100644
--- a/arch/x86/include/asm/trace/irq_vectors.h
+++ b/arch/x86/include/asm/trace/irq_vectors.h
@@ -138,6 +138,12 @@ DEFINE_IRQ_VECTOR_EVENT(deferred_error_apic);
DEFINE_IRQ_VECTOR_EVENT(thermal_apic);
#endif
+/*
+ * external_interrupt - called when entering/exiting from regular device
+ * interrupt vector handler.
+ */
+DEFINE_IRQ_VECTOR_EVENT(external_interrupt);
+
TRACE_EVENT(vector_config,
TP_PROTO(unsigned int irq, unsigned int vector,
@@ -385,7 +391,9 @@ TRACE_EVENT(vector_free_moved,
__entry->is_managed)
);
-
+#else /* CONFIG_X86_LOCAL_APIC */
+#define trace_external_interrupt_entry(vector) do {} while(0)
+#define trace_external_interrupt_exit(vector) do {} while(0)
#endif /* CONFIG_X86_LOCAL_APIC */
#undef TRACE_INCLUDE_PATH
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 59b5f2ea7c2f..715afe3a4f24 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -237,6 +237,7 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs
*regs)
unsigned vector = ~regs->orig_ax;
entering_irq();
+ trace_external_interrupt_entry(vector);
/* entering_irq() tells RCU that we're not quiescent. Check it. */
RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
@@ -255,6 +256,7 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs
*regs)
}
}
+ trace_external_interrupt_exit(vector);
exiting_irq();
set_irq_regs(old_regs);
--
2.20.1
Re: [PATCH v2] ARM: sun8i: h3: bluetooth for Banana Pi M2 Zero board
On Sun, Apr 07, 2019 at 10:23:21PM +0200, Andreas Kemnade wrote: > ping > > On Fri, 1 Mar 2019 19:52:12 +0100 > Andreas Kemnade wrote: > > > The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip > > with broadcom internals attached to UART1 and some gpios. > > This addition is in line with similar boards > > > > Signed-off-by: Andreas Kemnade I never received that patch, who did you send it to? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH V3 2/2] trace,x86: Add nmi to the irq_vectors class
Currently, the irq_vector class of tracepoints does not include the NMI
entry. The NMI was in the first set of tracepoints for IRQs, but it was
dropped off because of the logic of switching IDT when enabling trace[1].
However, as the switching IDT logic was removed [2], it is possible to add
the NMI tracepoints back.
The tracepoints looks like:
-0 [000] d.Z. 179.594315: nmi_entry: vector=2
-0 [000] d.Z. 179.594396: nmi_exit: vector=2
[1] trace,x86: irq vector tracepoint support
https://lwn.net/Articles/555465/
[2] commit 4b9a8dca0e58 ("x86/idt: Remove the tracing IDT completely")
Changes from V2:
- Use the #define NMI_VECTOR to identify the NMI's vector number.
(Steven Rostedt)
Changes from V1:
- Fix a compilation problem when CONFIG_X86_LOCAL_APIC is not set.
(kbuild test)
Signed-off-by: Daniel Bristot de Oliveira
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Andy Lutomirski
Cc: Clark Williams
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
---
arch/x86/include/asm/trace/irq_vectors.h | 7 +++
arch/x86/kernel/nmi.c| 4
2 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/trace/irq_vectors.h
b/arch/x86/include/asm/trace/irq_vectors.h
index 38e73d56db70..a68885e90e16 100644
--- a/arch/x86/include/asm/trace/irq_vectors.h
+++ b/arch/x86/include/asm/trace/irq_vectors.h
@@ -144,6 +144,11 @@ DEFINE_IRQ_VECTOR_EVENT(thermal_apic);
*/
DEFINE_IRQ_VECTOR_EVENT(external_interrupt);
+/*
+ * nmi - called when entering/exiting from nmi vector handler.
+ */
+DEFINE_IRQ_VECTOR_EVENT(nmi);
+
TRACE_EVENT(vector_config,
TP_PROTO(unsigned int irq, unsigned int vector,
@@ -394,6 +399,8 @@ TRACE_EVENT(vector_free_moved,
#else /* CONFIG_X86_LOCAL_APIC */
#define trace_external_interrupt_entry(vector) do {} while(0)
#define trace_external_interrupt_exit(vector) do {} while(0)
+#define trace_nmi_entry(vector) do {} while(0)
+#define trace_nmi_exit(vector) do {} while(0)
#endif /* CONFIG_X86_LOCAL_APIC */
#undef TRACE_INCLUDE_PATH
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 18bc9b51ac9b..6883eb78117b 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -37,6 +37,8 @@
#define CREATE_TRACE_POINTS
#include
+#undef CREATE_TRACE_POINTS
+#include
struct nmi_desc {
raw_spinlock_t lock;
@@ -514,12 +516,14 @@ do_nmi(struct pt_regs *regs, long error_code)
#endif
nmi_enter();
+ trace_nmi_entry(NMI_VECTOR);
inc_irq_stat(__nmi_count);
if (!ignore_nmis)
default_do_nmi(regs);
+ trace_nmi_exit(NMI_VECTOR);
nmi_exit();
#ifdef CONFIG_X86_64
--
2.20.1
Re: [v3 PATCH 5/6] usb: roles: add USB Type-B GPIO connector driver
Hi, On Thu, 2019-04-04 at 23:35 +0700, Linus Walleij wrote: > On Wed, Apr 3, 2019 at 9:09 AM Chunfeng Yun wrote: > > > Due to the requirement of usb-connector.txt binding, the old way > > using extcon to support USB Dual-Role switch is now deprecated > > when use Type-B connector. > > This patch introduces a driver of Type-B connector which typically > > uses an input GPIO to detect USB ID pin, and try to replace the > > function provided by extcon-usb-gpio driver > > > > Signed-off-by: Chunfeng Yun > (...) > > +#include > > If you need this include in a consumer, something is wrong. Just delete it, Ok > > > + info->id_gpiod = devm_gpiod_get_from_of_node( > > + dev, child, "id-gpios", 0, GPIOD_IN, > > "idpin"); > > This is OK if the child does not have any Linux device (struct platform_device > etc) created from it. Is this the case? Yes, it is. Thanks > > Yours, > Linus Walleij
Re: linux-next: manual merge of the staging tree with the staging.current tree
On Mon, 8 Apr 2019 13:02:12 +1000
Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the staging tree got a conflict in:
>
> drivers/iio/industrialio-buffer.c
>
> between commit:
>
> 20ea39ef9f2f ("iio: Fix scan mask selection")
>
> from the staging.current tree and commit:
>
> 3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
>
> from the staging tree.
>
> I fixed it up (I just used the staging tree version) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging. You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
>
Thanks Stephen,
That is the correct resolution.
Jonathan
Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT
Hi,
On 07-04-19 22:58, Robert R. Howell wrote:
On 4/3/19 2:54 AM, Hans de Goede wrote:
Hi,
On 03-04-19 07:43, Kai-Heng Feng wrote:
i2c-designware-platdrv fails to work after the system restored from
hibernation:
[ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type:
0x
Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
doesn't gets called by acpi_lpss_resume_early(), and this causes the
issue.
...
The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
so I think it would be better to do this instead to fix this problem:
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..cf768608437e 100644
...
If people affected by the problem can give my version of the fix a test,
then that would be great.
Regards,
Hans
I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel, instead
of what I had
been doing previously, which was reverting commit 02e45646d53b. I tested it on
an ASUS T100TA
and unfortunately with both kernels after resume from hibernation I still get
errors like those
listed below, and sound no longer works. I also tried applying the patch from
Kai-Heng Feng
(instead of Hans' patch or my revert) on both kernels and again in both cases I
get these same errors.
In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem is
fixed. Because
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to merge the
new code
and the 02e45646d53b revert without causing worse problems. But that's probably
because
I don't really understand the details of that code.
[ 120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[ 120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.
[ 132.782634] i2c_designware 80860F41:01: controller timed out
[ 133.806538] i2c_designware 80860F41:01: controller timed out
[ 134.830991] i2c_designware 80860F41:01: controller timed out
[ 135.855183] i2c_designware 80860F41:01: controller timed out
Let me know if I can do any other testing to help.
Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?
I must admit I never try hibernation myself, in experience it tends to
have more issues then regular suspend/resume and there are already enough
other issues to worry about on Bay and Cherry Trail based devices.
But if it works on the T100TA and 02e45646d53b broke it then I will
try to fix this, I've a T100TA myself. Currently my T100TA is at my
local hackerspace, so I will not have access to it until coming Friday.
Regards,
Hans
Re: [PATCH 2/2] arm64: dts: h6: Add watchdog node
On Sun, Apr 07, 2019 at 04:27:36PM +0200, Clément Péron wrote: > Hi, > > On Fri, 5 Apr 2019 at 18:24, Clément Péron wrote: > > > > Hi, > > > > On Fri, 5 Apr 2019 at 17:08, Maxime Ripard > > wrote: > > > > > > On Fri, Apr 05, 2019 at 10:59:35PM +0800, Chen-Yu Tsai wrote: > > > > On Fri, Apr 5, 2019 at 10:50 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Fri, Apr 05, 2019 at 10:35:08PM +0800, Chen-Yu Tsai wrote: > > > > > > On Fri, Apr 5, 2019 at 5:02 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Apr 04, 2019 at 03:57:36PM +0200, Clément Péron wrote: > > > > > > > > Allwinner H6 has a watchog compatible with A31. > > > > > > > > > > > > > > > > Declare it in the device tree. > > > > > > > > > > > > > > > > Signed-off-by: Clément Péron > > > > > > > > > > > > > > Applied both, thanks! > > > > > > > Maxime > > > > > > > > > > > > IIRC there are 3 watchdogs on the H6. One is the trusted watchdog, > > > > > > which should be reserved for underlying firmware. > > > > > > > > > > > > The other two are the normal and R-block watchdog. Although they > > > > > > look the same, the "normal" one can't reset the system. :( > > > > > > That one is actually the one ATF currently uses. So reboot doesn't > > > > > > work on the H6. > > > > Some users report that the reboot on the PineH64 actually works. > > > > Clement > > > > > > > > > > > > So that patch will not do anything then? > > Did some test and only interrupts are working right now. If the WDOG > is configured to make the board reboot the system will be stuck :S > Maybe better to disabled it for now and leave a comment. I dropped the two patches Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: PRINTER BUG LINUX MINT 19 TARA
On 07.04.19 23:09, Khz2020 wrote: > Please see attached. It was working fine prior to installing Canon linux > drivers. CUPS disconnect maybe? Wrong list. This maillist is about the linux KERNEL, whilst your problem is about CUPS. So, please ask the CUPS folks. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote:
> > Does the below cure things? It's not exactly pretty, but it could just
> > do the trick.
> >
> > ---
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index dfc4bab0b02b..d496e6911442 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -2009,8 +2009,8 @@ event_sched_out(struct perf_event *event,
> > event->pmu->del(event, 0);
> > event->oncpu = -1;
> >
> > - if (event->pending_disable) {
> > - event->pending_disable = 0;
> > + if (event->pending_disable == smp_processor_id()) {
> > + event->pending_disable = -1;
> > state = PERF_EVENT_STATE_OFF;
> > }
> > perf_event_set_state(event, state);
> > @@ -2198,7 +2198,7 @@ EXPORT_SYMBOL_GPL(perf_event_disable);
> >
> > void perf_event_disable_inatomic(struct perf_event *event)
> > {
> > - event->pending_disable = 1;
> > + event->pending_disable = smp_processor_id();
> > irq_work_queue(&event->pending);
> > }
> >
> > @@ -5822,8 +5822,8 @@ static void perf_pending_event(struct irq_work *entry)
> > * and we won't recurse 'further'.
> > */
> >
> > - if (event->pending_disable) {
> > - event->pending_disable = 0;
> > + if (event->pending_disable == smp_processor_id()) {
> > + event->pending_disable = -1;
> > perf_event_disable_local(event);
> > }
> >
> > @@ -10236,6 +10236,7 @@ perf_event_alloc(struct perf_event_attr *attr, int
> > cpu,
> >
> >
> > init_waitqueue_head(&event->waitq);
> > + event->pending_disable = -1;
> > init_irq_work(&event->pending, perf_pending_event);
> >
> > mutex_init(&event->mmap_mutex);
> >
>
> Peter,
>
> very good news, your fix ran over the weekend without any hit!!!
>
> Thanks very much for your help. Do you submit this patch to the kernel
> mailing list?
Most excellent, let me go write a Changelog.
Could I convince you to implement arch_irq_work_raise() for s390?
I Need An Investment Partner
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh, Dear Friend, I came across your e-mail contact prior a private search while in need of your assistance. I am Aisha Al-Qaddafi, the only biological Daughter of Former President of Libya Col. Muammar Al-Qaddafi. Am a single Mother and a Widow with three Children. I have investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need a trusted investment Manager/Partner because of my current refugee status, however, I am interested in you for investment project assistance in your country, may be from there, we can build business relationship in the nearest future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you more information about the investment funds. PLEASE REPLY ME THROUGH THIS EMAIL mgaddafi...@gmail.com Your Urgent Reply Will Be Appreciated Best Regards Mrs Aisha Al-Qaddafi
[PATCH v2 0/2] Preparing memhotplug for allocating memmap from hot-added range
v1 -> v2: Added David's feedback and his Reviewed-by Hi, these patches were posted as part of patchset [1], but it was agreed that patch#3 must be further discussed. Whole discussion can be seen in the cover letter. But the first two patches make sense by themselves, as the first one is a nice code cleanup, and the second one sets up the interface that the feature implemented in [1] will use. We decided to go this way because there are other people working on the same area, and conflicts can arise easily, so better merge it now. Also, it is safe as they do not implement any functional changes. [1] https://patchwork.kernel.org/cover/10875017/ Michal Hocko (2): mm, memory_hotplug: cleanup memory offline path mm, memory_hotplug: provide a more generic restrictions for memory hotplug arch/arm64/mm/mmu.c| 6 ++--- arch/ia64/mm/init.c| 6 ++--- arch/powerpc/mm/mem.c | 6 ++--- arch/s390/mm/init.c| 6 ++--- arch/sh/mm/init.c | 6 ++--- arch/x86/mm/init_32.c | 6 ++--- arch/x86/mm/init_64.c | 10 include/linux/memory_hotplug.h | 32 ++-- kernel/memremap.c | 12 ++--- mm/memory_hotplug.c| 56 ++ mm/page_alloc.c| 11 +++-- 11 files changed, 84 insertions(+), 73 deletions(-) -- 2.13.7
[PATCH v2 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug
From: Michal Hocko
arch_add_memory, __add_pages take a want_memblock which controls whether
the newly added memory should get the sysfs memblock user API (e.g.
ZONE_DEVICE users do not want/need this interface). Some callers even
want to control where do we allocate the memmap from by configuring
altmap.
Add a more generic hotplug context for arch_add_memory and __add_pages.
struct mhp_restrictions contains flags which contains additional
features to be enabled by the memory hotplug (MHP_MEMBLOCK_API
currently) and altmap for alternative memmap allocator.
This patch shouldn't introduce any functional change.
Signed-off-by: Michal Hocko
Signed-off-by: Oscar Salvador
---
arch/arm64/mm/mmu.c| 6 +++---
arch/ia64/mm/init.c| 6 +++---
arch/powerpc/mm/mem.c | 6 +++---
arch/s390/mm/init.c| 6 +++---
arch/sh/mm/init.c | 6 +++---
arch/x86/mm/init_32.c | 6 +++---
arch/x86/mm/init_64.c | 10 +-
include/linux/memory_hotplug.h | 29 +++--
kernel/memremap.c | 12 +---
mm/memory_hotplug.c| 11 +++
10 files changed, 62 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e6acfa7be4c7..aa81713a01da 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1046,8 +1046,8 @@ int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
}
#ifdef CONFIG_MEMORY_HOTPLUG
-int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
- bool want_memblock)
+int arch_add_memory(int nid, u64 start, u64 size,
+ struct mhp_restrictions *restrictions)
{
int flags = 0;
@@ -1058,6 +1058,6 @@ int arch_add_memory(int nid, u64 start, u64 size, struct
vmem_altmap *altmap,
size, PAGE_KERNEL, pgd_pgtable_alloc, flags);
return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
- altmap, want_memblock);
+ restrictions);
}
#endif
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index e49200e31750..379eb1f9adc9 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -666,14 +666,14 @@ mem_init (void)
}
#ifdef CONFIG_MEMORY_HOTPLUG
-int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
- bool want_memblock)
+int arch_add_memory(int nid, u64 start, u64 size,
+ struct mhp_restrictions *restrictions)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
- ret = __add_pages(nid, start_pfn, nr_pages, altmap, want_memblock);
+ ret = __add_pages(nid, start_pfn, nr_pages, restrictions);
if (ret)
printk("%s: Problem encountered in __add_pages() as ret=%d\n",
__func__, ret);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1aa27aac73c5..76deaa8525db 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -109,8 +109,8 @@ int __weak remove_section_mapping(unsigned long start,
unsigned long end)
return -ENODEV;
}
-int __meminit arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap
*altmap,
- bool want_memblock)
+int __meminit arch_add_memory(int nid, u64 start, u64 size,
+ struct mhp_restrictions *restrictions)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@@ -127,7 +127,7 @@ int __meminit arch_add_memory(int nid, u64 start, u64 size,
struct vmem_altmap *
}
flush_inval_dcache_range(start, start + size);
- return __add_pages(nid, start_pfn, nr_pages, altmap, want_memblock);
+ return __add_pages(nid, start_pfn, nr_pages, restrictions);
}
#ifdef CONFIG_MEMORY_HOTREMOVE
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 25e3113091ea..f5db961ad792 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -216,8 +216,8 @@ device_initcall(s390_cma_mem_init);
#endif /* CONFIG_CMA */
-int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
- bool want_memblock)
+int arch_add_memory(int nid, u64 start, u64 size,
+ struct mhp_restrictions *restrictions)
{
unsigned long start_pfn = PFN_DOWN(start);
unsigned long size_pages = PFN_DOWN(size);
@@ -227,7 +227,7 @@ int arch_add_memory(int nid, u64 start, u64 size, struct
vmem_altmap *altmap,
if (rc)
return rc;
- rc = __add_pages(nid, start_pfn, size_pages, altmap, want_memblock);
+ rc = __add_pages(nid, start_pfn, size_pages, restrictions);
if (rc)
vmem_remove_mapping(start, size);
return rc;
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 8e004b2f1a6a..168d3a6b9358 100644
--- a/arch/sh/mm/init.c
+++ b/arch/s
[PATCH v2 1/2] mm, memory_hotplug: cleanup memory offline path
From: Michal Hocko
check_pages_isolated_cb currently accounts the whole pfn range as being
offlined if test_pages_isolated suceeds on the range. This is based on
the assumption that all pages in the range are freed which is currently
the case in most cases but it won't be with later changes, as pages
marked as vmemmap won't be isolated.
Move the offlined pages counting to offline_isolated_pages_cb and
rely on __offline_isolated_pages to return the correct value.
check_pages_isolated_cb will still do it's primary job and check the pfn
range.
While we are at it remove check_pages_isolated and offline_isolated_pages
and use directly walk_system_ram_range as do in online_pages.
Signed-off-by: Michal Hocko
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
include/linux/memory_hotplug.h | 3 ++-
mm/memory_hotplug.c| 45 +++---
mm/page_alloc.c| 11 +--
3 files changed, 22 insertions(+), 37 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 8ade08c50d26..3c8cf347804c 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -87,7 +87,8 @@ extern int add_one_highpage(struct page *page, int pfn, int
bad_ppro);
extern int online_pages(unsigned long, unsigned long, int);
extern int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn,
unsigned long *valid_start, unsigned long *valid_end);
-extern void __offline_isolated_pages(unsigned long, unsigned long);
+extern unsigned long __offline_isolated_pages(unsigned long start_pfn,
+ unsigned long end_pfn);
typedef void (*online_page_callback_t)(struct page *page, unsigned int order);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f206b8b66af1..d167737f888e 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1451,15 +1451,10 @@ static int
offline_isolated_pages_cb(unsigned long start, unsigned long nr_pages,
void *data)
{
- __offline_isolated_pages(start, start + nr_pages);
- return 0;
-}
+ unsigned long *offlined_pages = (unsigned long *)data;
-static void
-offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
-{
- walk_system_ram_range(start_pfn, end_pfn - start_pfn, NULL,
- offline_isolated_pages_cb);
+ *offlined_pages += __offline_isolated_pages(start, start + nr_pages);
+ return 0;
}
/*
@@ -1469,26 +1464,7 @@ static int
check_pages_isolated_cb(unsigned long start_pfn, unsigned long nr_pages,
void *data)
{
- int ret;
- long offlined = *(long *)data;
- ret = test_pages_isolated(start_pfn, start_pfn + nr_pages, true);
- offlined = nr_pages;
- if (!ret)
- *(long *)data += offlined;
- return ret;
-}
-
-static long
-check_pages_isolated(unsigned long start_pfn, unsigned long end_pfn)
-{
- long offlined = 0;
- int ret;
-
- ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn, &offlined,
- check_pages_isolated_cb);
- if (ret < 0)
- offlined = (long)ret;
- return offlined;
+ return test_pages_isolated(start_pfn, start_pfn + nr_pages, true);
}
static int __init cmdline_parse_movable_node(char *p)
@@ -1573,7 +1549,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
unsigned long end_pfn)
{
unsigned long pfn, nr_pages;
- long offlined_pages;
+ unsigned long offlined_pages = 0;
int ret, node, nr_isolate_pageblock;
unsigned long flags;
unsigned long valid_start, valid_end;
@@ -1649,14 +1625,15 @@ static int __ref __offline_pages(unsigned long
start_pfn,
goto failed_removal_isolated;
}
/* check again */
- offlined_pages = check_pages_isolated(start_pfn, end_pfn);
- } while (offlined_pages < 0);
+ ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn,
+ NULL, check_pages_isolated_cb);
+ } while (ret);
- pr_info("Offlined Pages %ld\n", offlined_pages);
/* Ok, all of our target is isolated.
We cannot do rollback at this point. */
- offline_isolated_pages(start_pfn, end_pfn);
-
+ walk_system_ram_range(start_pfn, end_pfn - start_pfn,
+ &offlined_pages, offline_isolated_pages_cb);
+ pr_info("Offlined Pages %ld\n", offlined_pages);
/*
* Onlining will reset pagetype flags and makes migrate type
* MOVABLE, so just need to decrease the number of isolated
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0c53807a2943..d36ca67064c9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8375,7 +8375,7 @@ void zone_pcp_reset(struct zone *zone)
* A
Re: [PATCH v2] ARM: sun8i: h3: bluetooth for Banana Pi M2 Zero board
On Sat, Mar 2, 2019 at 2:53 AM Andreas Kemnade wrote: > > The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip > with broadcom internals attached to UART1 and some gpios. ^ Broadcom > This addition is in line with similar boards This sentence is unfinished. > > Signed-off-by: Andreas Kemnade ChenYu
Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
On 2019-04-05 20:38, Marc Gonzalez wrote: On 27/03/2019 13:38, Sibi Sankar wrote: Add the shared cx/mx and sensor sub-system's cx and mx power-domains found on MSM8998. Signed-off-by: Sibi Sankar --- drivers/soc/qcom/rpmpd.c | 36 1 file changed, 36 insertions(+) diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c index 238a9e02e890..706a3f63038e 100644 --- a/drivers/soc/qcom/rpmpd.c +++ b/drivers/soc/qcom/rpmpd.c @@ -19,9 +19,12 @@ /* Resource types */ #define RPMPD_SMPA 0x61706d73 /* smpa */ #define RPMPD_LDOA 0x616f646c /* ldoa */ +#define RPMPD_RWCX 0x78637772 /* rwcx */ #define RPMPD_RWMX 0x786d7772 /* rwmx */ #define RPMPD_RWLC 0x636c7772 /* rwlc */ #define RPMPD_RWLM 0x6d6c7772 /* rwlm */ +#define RPMPD_RWSC 0x63737772 /* rwsc */ +#define RPMPD_RWSM 0x6d737772 /* rwsm */ I do not see any value in the comments. Maybe remove them? comments were included to add value though, however I guess the comments were definitely not clear enough. The magic values for the resources are calculated as follows: ascii to hex in reverse order eg: smpa -> 0x61706d73 0x61 0x70 0x6d 0x73 apms I will take a closer look at patches 7-9 on Monday. Thanks for taking time to review this series. Regards. -- -- Sibi Sankar -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [v2] Updated locking documentation for transaction_t
Thanks, Ted, for your feedback! I'll submit a modified version. - Alex On 07.04.19 18:52, Theodore Ts'o wrote: > On Mon, Mar 18, 2019 at 07:42:37PM +0100, Alexander Lochmann wrote: >> /*t >> - * Where in the log does this transaction's commit start? [no locking] >> + * Where in the log does this transaction's commit start? >> + * [journal_t.j_state_lock] >> */ >> unsigned long t_log_start; > > Well, technically, that's not quite right. It's only assigned in one > location, and we hold j_state_lock, yes. But that's because we need > to access journal->j_head. At the point where we set t_log_start, the > transaction has already been locked down (transaction->t_state > > T_LOCKED). > > Similarly, we happen to be holding j_state where it is currently being > accessed, but it's not because we needed the lock in order to access > t_log_start safely. > >> /* >> - * When transaction started >> + * When transaction started [journal_t.j_state_lock] >> */ >> unsigned long t_start; > > And again, not really. The primary place where t_start is set is when > the transaction is firstt created, before it's visible anywhere else. > after that, it is used exclusively by the commit thread, and so no > locking is necessary. It's true that in the places where it is used, > j_state_lock happens to be taken, but it's strictly not necessary. > >> >> /* >> - * When commit was requested >> + * When commit was requested [journal_t.j_state_lock] >> */ >> unsigned long t_requested; > > Yes, that appears to be correct. > >> >> /* >> - * Checkpointing stats [j_checkpoint_sem] >> + * Checkpointing stats [journal_t.j_list_lock] >> */ >> struct transaction_chp_stats_s t_chp_stats; >> > > This appears to be correct. > > - Ted > -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax:+49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al signature.asc Description: OpenPGP digital signature
[PATCH v3] Updated locking documentation for transaction_t
We used LockDoc to derive locking rules for each member
of struct transaction_t.
Based on those results, we extended the existing documentation
by more members of struct transaction_t, and updated the existing
documentation.
Signed-off-by: Alexander Lochmann
Signed-off-by: Horst Schirmeier
---
include/linux/jbd2.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 0f919d5fe84f..34b728e2b702 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -534,6 +534,7 @@ struct transaction_chp_stats_s {
* The transaction keeps track of all of the buffers modified by a
* running transaction, and all of the buffers committed but not yet
* flushed to home for finished transactions.
+ * (Locking Documentation improved by LockDoc)
*/
/*
@@ -652,12 +653,12 @@ struct transaction_s
unsigned long t_start;
/*
-* When commit was requested
+* When commit was requested [journal_t.j_state_lock]
*/
unsigned long t_requested;
/*
-* Checkpointing stats [j_checkpoint_sem]
+* Checkpointing stats [journal_t.j_list_lock]
*/
struct transaction_chp_stats_s t_chp_stats;
--
2.20.1
Re: [PATCH V3 1/2] trace,x86: Add external_interrupts to the irq_vectors class
On 4/8/19 10:14 AM, Daniel Bristot de Oliveira wrote: > Currently, the irq_vectors is showing the entry and exit events for > the interrupts of the architecture, but not for external interrupts. Oops... Sorry... Please, ignore this version... -- Daniel
Re: [PATCH 2/3] arm64: kdump: support more than one crash kernel regions
Hi Mike,
On 2019/4/8 14:57, Mike Rapoport wrote:
> Hi,
>
> On Fri, Apr 05, 2019 at 11:47:27AM +0800, Chen Zhou wrote:
>> Hi Mike,
>>
>> On 2019/4/5 10:17, Chen Zhou wrote:
>>> Hi Mike,
>>>
>>> On 2019/4/4 22:44, Mike Rapoport wrote:
Hi,
On Wed, Apr 03, 2019 at 09:51:27PM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/3 19:29, Mike Rapoport wrote:
>> On Wed, Apr 03, 2019 at 11:05:45AM +0800, Chen Zhou wrote:
>>> After commit (arm64: kdump: support reserving crashkernel above 4G),
>>> there may be two crash kernel regions, one is below 4G, the other is
>>> above 4G.
>>>
>>> Crash dump kernel reads more than one crash kernel regions via a dtb
>>> property under node /chosen,
>>> linux,usable-memory-range =
>>>
>>> Signed-off-by: Chen Zhou
>>> ---
>>> arch/arm64/mm/init.c | 37 +
>>> include/linux/memblock.h | 1 +
>>> mm/memblock.c| 40
>>> 3 files changed, 66 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index ceb2a25..769c77a 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -64,6 +64,8 @@ EXPORT_SYMBOL(memstart_addr);
>>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>
>>> #ifdef CONFIG_KEXEC_CORE
>>> +# define CRASH_MAX_USABLE_RANGES2
>>> +
>>> static int __init reserve_crashkernel_low(void)
>>> {
>>> unsigned long long base, low_base = 0, low_size = 0;
>>> @@ -346,8 +348,8 @@ static int __init
>>> early_init_dt_scan_usablemem(unsigned long node,
>>> const char *uname, int depth, void *data)
>>> {
>>> struct memblock_region *usablemem = data;
>>> - const __be32 *reg;
>>> - int len;
>>> + const __be32 *reg, *endp;
>>> + int len, nr = 0;
>>>
>>> if (depth != 1 || strcmp(uname, "chosen") != 0)
>>> return 0;
>>> @@ -356,22 +358,33 @@ static int __init
>>> early_init_dt_scan_usablemem(unsigned long node,
>>> if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
>>> return 1;
>>>
>>> - usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
>>> - usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
>>> + endp = reg + (len / sizeof(__be32));
>>> + while ((endp - reg) >= (dt_root_addr_cells +
>>> dt_root_size_cells)) {
>>> + usablemem[nr].base =
>>> dt_mem_next_cell(dt_root_addr_cells, ®);
>>> + usablemem[nr].size =
>>> dt_mem_next_cell(dt_root_size_cells, ®);
>>> +
>>> + if (++nr >= CRASH_MAX_USABLE_RANGES)
>>> + break;
>>> + }
>>>
>>> return 1;
>>> }
>>>
>>> static void __init fdt_enforce_memory_region(void)
>>> {
>>> - struct memblock_region reg = {
>>> - .size = 0,
>>> - };
>>> -
>>> - of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> -
>>> - if (reg.size)
>>> - memblock_cap_memory_range(reg.base, reg.size);
>>> + int i, cnt = 0;
>>> + struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
>>> +
>>> + memset(regs, 0, sizeof(regs));
>>> + of_scan_flat_dt(early_init_dt_scan_usablemem, regs);
>>> +
>>> + for (i = 0; i < CRASH_MAX_USABLE_RANGES; i++)
>>> + if (regs[i].size)
>>> + cnt++;
>>> + else
>>> + break;
>>> + if (cnt)
>>> + memblock_cap_memory_ranges(regs, cnt);
>>
>> Why not simply call memblock_cap_memory_range() for each region?
>
> Function memblock_cap_memory_range() removes all memory type ranges
> except specified range.
> So if we call memblock_cap_memory_range() for each region simply, there
> will be no usable-memory
> on kdump capture kernel.
Thanks for the clarification.
I still think that memblock_cap_memory_ranges() is overly complex.
How about doing something like this:
Cap the memory range for [min(regs[*].start, max(regs[*].end)] and then
removing the range in the middle?
>>>
>>> Yes, that would be ok. But that would do one more memblock_cap_memory_range
>>> operation.
>>> That is, if there are n regions, we need to do (n + 1) operations, which
>>> doesn't seem to
>>> matter.
>>>
>>> I agree with you, your idea is better.
>>>
>>> Thanks,
>>> Chen Zhou
>>
>> Sorry, just ignore my previous reply, I got that wrong.
>>
>> I think it carefully, we can cap the memory range for [min(regs[*].start,
>> max(regs[*].end)]
>> firstly. But how to remove t
Re: [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add Microchip PIT64B support
Hi Claudiu,
On 14/03/2019 17:26, claudiu.bez...@microchip.com wrote:
> From: Claudiu Beznea
>
> Add driver for Microchip PIT64B timer. Timer could be used in continuous
> mode or oneshot mode. The hardware has 2x32 bit registers for period
> emulating a 64 bit timer. The LSB_PR and MSB_PR registers are used to set
> the period value (compare value). TLSB and TMSB keeps the current value
> of the counter. After a compare the TLSB and TMSB register resets. Apart
> from this the hardware has SMOD bit in mode register that allow to
> reconfigure the timer without reset and start commands (start command
> while timer is active is ignored).
> The driver uses PIT64B timer as clocksource or clockevent. First requested
> timer would be registered as clockevent, second one would be registered as
> clocksource.
Even if that was done this way before, assuming the DT describes the
clockevent at the first place and then the clocksource, it is a fragile
approach.
What about using one of these approach?
eg.
arch/arm/boot/dts/at91sam9261ek.dts
chosen {
bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw";
stdout-path = "serial0:115200n8";
clocksource {
timer = <&timer0>;
};
clockevent {
timer = <&timer1>;
};
};
or
arch/arm/boot/dts/integratorap.dts
aliases {
arm,timer-primary = &timer2;
arm,timer-secondary = &timer1;
};
So we can have control of what is the clocksource or the clockevent.
That is particulary handy in case of multiple channels.
Not sure if we can replace the 'arm,timer_primary' to 'clocksource'.
Rob? What is your opinion?
> Individual PIT64B hardware resources were used for clocksource
> and clockevent to be able to support high resolution timers with this
> hardware implementation.
>
> Signed-off-by: Claudiu Beznea
> ---
> drivers/clocksource/Kconfig | 6 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-microchip-pit64b.c | 464
> +++
> 3 files changed, 471 insertions(+)
> create mode 100644 drivers/clocksource/timer-microchip-pit64b.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 5d93e580e5dc..2ad6f881a0bb 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -448,6 +448,12 @@ config OXNAS_RPS_TIMER
> config SYS_SUPPORTS_SH_CMT
> bool
>
> +config MICROCHIP_PIT64B
> + bool "Microchip PIT64B support"
> + depends on OF || COMPILE_TEST
> + help
> + This option enables Microchip PIT64B timer.
> +
> config MTK_TIMER
> bool "Mediatek timer driver" if COMPILE_TEST
> depends on HAS_IOMEM
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index c4a8e9ef932a..c53fa12b9b94 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_U300_TIMER)+= timer-u300.o
> obj-$(CONFIG_SUN4I_TIMER)+= timer-sun4i.o
> obj-$(CONFIG_SUN5I_HSTIMER) += timer-sun5i.o
> obj-$(CONFIG_MESON6_TIMER) += timer-meson6.o
> +obj-$(CONFIG_MICROCHIP_PIT64B) += timer-microchip-pit64b.o
> obj-$(CONFIG_TEGRA_TIMER)+= timer-tegra20.o
> obj-$(CONFIG_VT8500_TIMER) += timer-vt8500.o
> obj-$(CONFIG_NSPIRE_TIMER) += timer-zevio.o
> diff --git a/drivers/clocksource/timer-microchip-pit64b.c
> b/drivers/clocksource/timer-microchip-pit64b.c
> new file mode 100644
> index ..6787aa98ef01
> --- /dev/null
> +++ b/drivers/clocksource/timer-microchip-pit64b.c
> @@ -0,0 +1,464 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2019 Microchip Technology Inc.
> +// Copyright (C) 2019 Claudiu Beznea (claudiu.bez...@microchip.com)
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MCHP_PIT64B_CR 0x00/* Control Register */
> +#define MCHP_PIT64B_CR_START BIT(0)
> +#define MCHP_PIT64B_CR_SWRST BIT(8)
> +
> +#define MCHP_PIT64B_MR 0x04/* Mode Register */
> +#define MCHP_PIT64B_MR_CONT BIT(0)
> +#define MCHP_PIT64B_MR_SGCLK BIT(3)
> +#define MCHP_PIT64B_MR_SMOD BIT(4)
> +#define MCHP_PIT64B_MR_PRES GENMASK(11, 8)
> +
> +#define MCHP_PIT64B_LSB_PR 0x08/* LSB Period Register */
> +
> +#define MCHP_PIT64B_MSB_PR 0x0C/* MSB Period Register */
> +
> +#define MCHP_PIT64B_IER 0x10/* Interrupt Enable Register */
> +#define MCHP_PIT64B_IER_PERIOD BIT(0)
> +
> +#define MCHP_PIT64B_ISR 0x1C/* Interrupt Status Register */
> +#define MCHP_PIT64B_ISR_PERIOD BIT(0)
> +
> +#define MCHP_PIT64B_TLSBR0x20/* Timer LSB Register */
> +
> +#define MCHP_PIT64B_TMSBR0x24/* Timer MSB Register */
> +
> +#define MCHP_PIT64B_PRES_MAX 0x10
> +#define MCHP_PIT64B_DEF_FREQ 250UL /* 2.5 MHz */
> +#define MCHP_PIT64B_LSBMASK GENMASK_ULL(31, 0)
> +#define MCHP_PIT64B_PRESCAL
Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
On 4/8/19 10:22 AM, Peter Zijlstra wrote:
> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote:
>>> Does the below cure things? It's not exactly pretty, but it could just
>>> do the trick.
>>>
>>> ---
>>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>>> index dfc4bab0b02b..d496e6911442 100644
>>> --- a/kernel/events/core.c
>>> +++ b/kernel/events/core.c
>>> @@ -2009,8 +2009,8 @@ event_sched_out(struct perf_event *event,
>>> event->pmu->del(event, 0);
>>> event->oncpu = -1;
>>>
>>> - if (event->pending_disable) {
>>> - event->pending_disable = 0;
>>> + if (event->pending_disable == smp_processor_id()) {
>>> + event->pending_disable = -1;
>>> state = PERF_EVENT_STATE_OFF;
>>> }
>>> perf_event_set_state(event, state);
>>> @@ -2198,7 +2198,7 @@ EXPORT_SYMBOL_GPL(perf_event_disable);
>>>
>>> void perf_event_disable_inatomic(struct perf_event *event)
>>> {
>>> - event->pending_disable = 1;
>>> + event->pending_disable = smp_processor_id();
>>> irq_work_queue(&event->pending);
>>> }
>>>
>>> @@ -5822,8 +5822,8 @@ static void perf_pending_event(struct irq_work *entry)
>>> * and we won't recurse 'further'.
>>> */
>>>
>>> - if (event->pending_disable) {
>>> - event->pending_disable = 0;
>>> + if (event->pending_disable == smp_processor_id()) {
>>> + event->pending_disable = -1;
>>> perf_event_disable_local(event);
>>> }
>>>
>>> @@ -10236,6 +10236,7 @@ perf_event_alloc(struct perf_event_attr *attr, int
>>> cpu,
>>>
>>>
>>> init_waitqueue_head(&event->waitq);
>>> + event->pending_disable = -1;
>>> init_irq_work(&event->pending, perf_pending_event);
>>>
>>> mutex_init(&event->mmap_mutex);
>>>
>>
>> Peter,
>>
>> very good news, your fix ran over the weekend without any hit!!!
>>
>> Thanks very much for your help. Do you submit this patch to the kernel
>> mailing list?
>
> Most excellent, let me go write a Changelog.
>
> Could I convince you to implement arch_irq_work_raise() for s390?
>
Yes, I am convinced, however I need to discuss this with the s390 maintainers
Martin Schwidesfky and Heiko Carstens first.
--
Thomas Richter, Dept 3252, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
kernel/time/ntp.c: Possible off-by-one error in TAI range check?
Hello,
while writing tests for clock adjustment auditing [1] [2], I stumbled
upon a strange behavior of adjtimex(2) when setting the TAI offset...
Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to
change the TAI offset from userspace via adjtimex(2). The code checks
if the input value (txc->constant) is greater than 0 and if it is not,
then it doesn't modify the value. Ignoring the fact that this check
should probably be in timekeeping_validate_timex() and cause -EINVAL
to be returned when false, I find it strange that the check doesn't
allow to set the value to 0, which seems to be the default value...
Was this behavior intended or should the code actually check for
txc->constant >= 0 instead of txc->constant > 0?
Thanks,
[1] https://github.com/linux-audit/audit-kernel/issues/10
[2]
https://github.com/linux-audit/audit-kernel/wiki/RFE-More-detailed-auditing-of-changes-to-system-clock
--
Ondrej Mosnacek
Software Engineer, Security Technologies
Red Hat, Inc.
Re: [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm
On 04/04/19 4:44 PM, Adam Ford wrote:
> On Thu, Apr 4, 2019 at 5:01 AM Bartosz Golaszewski wrote:
>>
>> śr., 3 kwi 2019 o 17:49 Adam Ford napisał(a):
>>>
>>> On Wed, Apr 3, 2019 at 7:50 AM Bartosz Golaszewski wrote:
śr., 27 mar 2019 o 12:14 Sekhar Nori napisał(a):
>
> Hi Bart,
>
> On 26/03/19 11:21 PM, Bartosz Golaszewski wrote:
>> wt., 26 mar 2019 o 15:00 Adam Ford napisał(a):
>>>
>>> On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski
>>> wrote:
From: Bartosz Golaszewski
The system_rev variable is never set on davinci and is always 0, so
we're using the default max operating point of 300MHz. The cvdd supply
comes from the tps6507 pmic and the voltage can go all the way to 1.3V
so the maximum supported rate should be 456MHz.
>>>
>>> My understanding is that only certain revisions of the silicon can go
>>> to 456MHz. The L138's Datasheet lists both a 456 and 375 version. I
>>> cannot find a way to read a register to determine which version of the
>>> silicon is available. Maybe Sekhar can confirm.
>>>
>>
>> Commit 28bd2c341120 ("davinci: am18x/da850/omap-l138 evm: add support
>> for higher speed grades") mentions the following:
>>
>> ---
>> U-Boot on the EVM sets up ATAG_REVISION to inform the OS
>> regarding the speed grade supported by the silicon. We use
>> this information to pass on the speed grade information to
>> the SoC code.
>> ---
>>
>> Should the system_rev somehow reflect that revision? Any way I can check
>> it?
>
> Can you check if the procedure in doc/README.davinci in U-Boot sources
> still works?
>
> Environment Variables
> =
>
> The DA850 EVM allows the user to specify the maximum cpu clock allowed by
> the
> silicon, in Hz, via an environment variable "maxcpuclk".
>
> The maximum clock rate allowed depends on the silicon populated on the
> EVM.
> Please make sure you understand the restrictions placed on this clock in
> the
> device specific datasheet before setting up this variable. This
> information is
> passed to the Linux kernel using the ATAG_REVISION atag.
>
> If "maxcpuclk" is not defined, the configuration
> CONFIG_DA850_EVM_MAX_CPU_CLK
> is used to obtain this information.
>
> Thanks,
> Sekhar
Hi Sekhar,
I built the current upstream u-boot and the get_board_rev() function
for da850-evm doesn't seem to be called at all. For instance the
lego-ev3 platform does this:
./lego/ev3/legoev3.c:108: board_rev = get_board_rev();
but in davinci this function seems to be unused and I don't see it
called from any other core u-boot component. I don't see any commit
that would mention this function but there are a lot of commits
removing get_board_rev() for other boards in git log. Is it possible
it stopped being used at some point?
>>>
>>> Look for setup_revision_tag in arch/arm/lib/bootm.c
>>>
>>> The function appears to be called from there.
>>>
>>> There is a __weak reference in the header file which I think allows
>>> people to remove them without breaking bootm.
>>>
>>> adam
Bart
>>
>> Thanks, now verified that this still works in board file mode for
>> da850-evm. Now the questions is - what about DT mode? Should we only
>> enable the lowest possible mode (300MHz) and leave it to the user to
>> enable any higher frequencies?
>
> From everything that I can find in Logic PD's database, the standard
> da850-evm kits and SOM's are 375MHz, so I think it's safe to run up to
> that speed. I would disable the speed options for 408 and 456, but
> leave them shown for anyone who may have purchased a custom version
> with the 456MHz variant which I can also see there are some. At least
> for the L138 and AM1808 SOM's, those customers who who they are, so
> making it obvious how to enable it would be a good thing.
>
> Just my two cents.
Sounds good to me.
Thanks,
Sekhar
Re: [PATCH 1/1] rtc: ds3232: get SRAM access using NVMEM Framework
On 4/6/19 12:44 AM, Alexandre Belloni wrote:
Hi,
On 05/04/2019 11:14:35+, Han Nandor wrote:
`
# hexdump -n 10 -C /sys/bus/nvmem/devices/ds3232_sram0/nvmem
74 65 73 74 69 6e 67 0a 00 00|testing...|
000a
`
Thanks for that nice description!
Glad that you like it. :)
drivers/rtc/rtc-ds3232.c | 41 ++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index 7184e5145f12..fe615aedaa9a 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -24,6 +24,8 @@
#include
#include
+#include "rtc-core.h"
+
The drivers should not have to include that header, see
fd5cd21d995e67f87b3eb4adf938be85fe83ef4b (from 4.16).
Ahh...right. I did the implementation on 4.14 and it was needed there.
I will change the implementation but I'll not be able to fully test it.
struct ds3232 {
struct device *dev;
struct regmap *regmap;
int irq;
struct rtc_device *rtc;
+ struct nvmem_config nvmem_cfg;
You don't actually need to keep that structure for the whole life of the
device as it is copied as soon as it is registered. I usually prefer to
have it on the stack.
Very true. Done
+ ds3232->nvmem_cfg.stride = 1;
+ ds3232->nvmem_cfg.size = DS3232_REG_SRAM_SIZE;
+ ds3232->nvmem_cfg.word_size = 1;
+ ds3232->nvmem_cfg.reg_read = ds3232_nvmem_read;
+ ds3232->nvmem_cfg.reg_write = ds3232_nvmem_write;
+ ds3232->nvmem_cfg.priv = ds3232;
Please also set the type (battery backed).
Done.
+ ds3232->rtc->dev.of_node = dev->of_node;
Please don't mess with rtc->dev.
In my use-case I do use the device tree to declare a nvmem cell in this
RTC node, which is used by another driver. Without this change finding
the cell (using `devm_nvmem_cell_get` function) was failing because of
missing `of_node` (again this was on 4.14).
I can do a bit of digging to see if something was changed, but I will
really appreciate your advice, because I'm not be able to test the fix
on linux-next.
+ ds3232->rtc->nvmem_config = &ds3232->nvmem_cfg;
+ rtc_nvmem_register(ds3232->rtc);
This part will not compile on v5.1-rc1.
Sorry. I will fix this, and I will at least see that it builds on
linux-next.
Thanks for review,
Nandor
[PATCH v2 1/1] rtc: ds3232: get SRAM access using NVMEM Framework
DS3232 RTC has 236 bytes of persistent memory.
Add RTC SRAM read and write access using
the NVMEM Framework.
Signed-off-by: Nandor Han
---
Description
---
Provides DS3232 RTC SRAM access using NVMEM framework.
Testing
---
The test was done on a custom board which contains a
DS3232 RTC device.
Kernel Version: 4.14.60 (Just for clarity, the patch is against master)
1. Verify that SRAM is accessible using NVMEM interface: PASS
`
# hexdump /sys/bus/nvmem/devices/ds3232_sram0/nvmem
000
*
0e0
`
2. Modify the content.
`
# echo testing > /sys/bus/nvmem/devices/ds3232_sram0/nvmem
#
`
3. Power cycle the board and verify that contents are preserved: PASS
`
# hexdump -n 10 -C /sys/bus/nvmem/devices/ds3232_sram0/nvmem
74 65 73 74 69 6e 67 0a 00 00|testing...|
000a
`
Testing on Kernel v5.1.0-rc3
1. Update `arch/arm/configs/imx_v6_v7_defconfig` to contain
`CONFIG_RTC_DRV_DS3232=y`
2. Verify that building the kernel is successful: PASS
`
make ARCH=arm CROSS_COMPILE=arm-linux-gnu- imx_v6_v7_defconfig zImage
...
CC drivers/rtc/rtc-ds3232.o
...
Kernel: arch/arm/boot/zImage is ready
`
Changes since v1
- remove the unnecessary header "rtc-core.h"
- use nvmem_config from the stack
- configure the nvmem type
- remove the `of_node` configuration
drivers/rtc/rtc-ds3232.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index 7184e5145f12..77908c9e5e09 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -48,6 +48,10 @@
# define DS3232_REG_SR_A1F 0x01
#define DS3232_REG_TEMPERATURE 0x11
+#define DS3232_REG_SRAM_START 0x14
+#define DS3232_REG_SRAM_END 0xFF
+
+#define DS3232_REG_SRAM_SIZE236
struct ds3232 {
struct device *dev;
@@ -461,11 +465,30 @@ static const struct rtc_class_ops ds3232_rtc_ops = {
.alarm_irq_enable = ds3232_alarm_irq_enable,
};
+static int ds3232_nvmem_read(void *priv, unsigned int offset, void *val,
+size_t bytes)
+{
+ struct ds3232 *ds3232 = (struct ds3232 *)priv;
+
+ return regmap_bulk_read(ds3232->regmap, DS3232_REG_SRAM_START + offset,
+ val, bytes);
+}
+
+static int ds3232_nvmem_write(void *priv, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct ds3232 *ds3232 = (struct ds3232 *)priv;
+
+ return regmap_bulk_write(ds3232->regmap, DS3232_REG_SRAM_START + offset,
+val, bytes);
+}
+
static int ds3232_probe(struct device *dev, struct regmap *regmap, int irq,
const char *name)
{
struct ds3232 *ds3232;
int ret;
+ struct nvmem_config nvmem_cfg;
ds3232 = devm_kzalloc(dev, sizeof(*ds3232), GFP_KERNEL);
if (!ds3232)
@@ -476,6 +499,15 @@ static int ds3232_probe(struct device *dev, struct regmap
*regmap, int irq,
ds3232->dev = dev;
dev_set_drvdata(dev, ds3232);
+ nvmem_cfg.name = "ds3232_sram";
+ nvmem_cfg.stride = 1;
+ nvmem_cfg.size = DS3232_REG_SRAM_SIZE;
+ nvmem_cfg.word_size = 1;
+ nvmem_cfg.reg_read = ds3232_nvmem_read;
+ nvmem_cfg.reg_write = ds3232_nvmem_write;
+ nvmem_cfg.priv = ds3232;
+ nvmem_cfg.type = NVMEM_TYPE_BATTERY_BACKED;
+
ret = ds3232_check_rtc_status(dev);
if (ret)
return ret;
@@ -490,6 +522,10 @@ static int ds3232_probe(struct device *dev, struct regmap
*regmap, int irq,
if (IS_ERR(ds3232->rtc))
return PTR_ERR(ds3232->rtc);
+ ret = rtc_nvmem_register(ds3232->rtc, &nvmem_cfg);
+ if(ret)
+ return ret;
+
if (ds3232->irq > 0) {
ret = devm_request_threaded_irq(dev, ds3232->irq, NULL,
ds3232_irq,
@@ -542,7 +578,7 @@ static int ds3232_i2c_probe(struct i2c_client *client,
static const struct regmap_config config = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = 0x13,
+ .max_register = DS3232_REG_SRAM_END,
};
regmap = devm_regmap_init_i2c(client, &config);
@@ -609,7 +645,7 @@ static int ds3234_probe(struct spi_device *spi)
static const struct regmap_config config = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = 0x13,
+ .max_register = DS3232_REG_SRAM_END,
.write_flag_mask = 0x80,
};
struct regmap *regmap;
--
2.17.2
Re: [PATCH v3 19/36] thunderbolt: Extend tunnel creation to more than 2 adjacent switches
On Mon, Apr 08, 2019 at 10:35:17AM +0300, Mika Westerberg wrote:
> On Sun, Apr 07, 2019 at 06:54:25PM +0200, Lukas Wunner wrote:
> > According to the code comment in struct tb_regs_hop (in tb_regs.h),
> > the out_hopid ("next_hop" in struct tb_regs_hop) denotes the
> > "hop to take after sending the packet through out_port (on the
> > incoming port of the next switch)".
> >
> > So intuitively, the hop config space is like a routing table and
> > the entry in in_port's hop config space specifies through which
> > out_port the packets shall be routed, and which entry to look up
> > on the remote port reachable through out_port.
> >
> > This means that the out_hopid must always be identical to the in_hopid
> > of out_port->remote. Otherwise the routing wouldn't work.
> >
> > And yet, you've introduced *two* struct ida for each port in
> > patch 16. This doesn't seem to make sense: The out_hopids ida
> > of a port always has to be identical to the in_hopids ida of that
> > port's remote. But if it's identical, why does it have to exist
> > twice?
>
> The reason for two HopID allocators (struct idas) is to make it possible
> to track HopIDs to each direction. The same port can be output for one
> path and input for another. I'm not sure how that can be done without
> having two struct idas per port.
>
> You are right, in case of out port HopID connecter to remote in port,
> they should use the same HopID.
Hm, what other cases are there, i.e. what is the meaning of a tb_regs_hop's
"next_hop" field if "out_port" doesn't have a remote? (And why does it
need to be tracked on the out_port? In case a remote is added later?)
Thanks,
Lukas
Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
On 08/04/2019 10:30, Sibi Sankar wrote: > On 2019-04-05 20:38, Marc Gonzalez wrote: >> On 27/03/2019 13:38, Sibi Sankar wrote: >> >>> Add the shared cx/mx and sensor sub-system's cx and mx >>> power-domains found on MSM8998. >>> >>> Signed-off-by: Sibi Sankar >>> --- >>> drivers/soc/qcom/rpmpd.c | 36 >>> 1 file changed, 36 insertions(+) >>> >>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c >>> index 238a9e02e890..706a3f63038e 100644 >>> --- a/drivers/soc/qcom/rpmpd.c >>> +++ b/drivers/soc/qcom/rpmpd.c >>> @@ -19,9 +19,12 @@ >>> /* Resource types */ >>> #define RPMPD_SMPA 0x61706d73 /* smpa */ >>> #define RPMPD_LDOA 0x616f646c /* ldoa */ >>> +#define RPMPD_RWCX 0x78637772 /* rwcx */ >>> #define RPMPD_RWMX 0x786d7772 /* rwmx */ >>> #define RPMPD_RWLC 0x636c7772 /* rwlc */ >>> #define RPMPD_RWLM 0x6d6c7772 /* rwlm */ >>> +#define RPMPD_RWSC 0x63737772 /* rwsc */ >>> +#define RPMPD_RWSM 0x6d737772 /* rwsm */ >> >> I do not see any value in the comments. Maybe remove them? > > comments were included to add value > though, however I guess the comments > were definitely not clear enough. > The magic values for the resources > are calculated as follows: > > ascii to hex in reverse order > eg: smpa -> 0x61706d73 > > 0x61 0x70 0x6d 0x73 >apms Ah... I see now. I agree that explaining *why* e.g. RPMPD_SMPA is defined as 0x61706d73 is worthwhile indeed. What I meant is that adding /* smpa */ to a macro named RPMPD_SMPA does not really bring any new information ;-) How about prefixing the whole block with a small blurb, for example /* The value of RPMPD_X is X encoded as a little-endian, lower-case, ASCII string */ Regards.
[PATCH] tools/power turbostat: fix leak of file descriptor on error return path
From: Colin Ian King
Currently the error return path does not close the file fp and leaks
a file descriptor. Fix this by closing the file.
Fixes: 5ea7647b333f ("tools/power turbostat: Warn on bad ACPI LPIT data")
Signed-off-by: Colin Ian King
---
tools/power/x86/turbostat/turbostat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index c7727be9719f..4e6e3f194d2c 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -2950,6 +2950,7 @@ int snapshot_sys_lpi_us(void)
if (retval != 1) {
fprintf(stderr, "Disabling Low Power Idle System output\n");
BIC_NOT_PRESENT(BIC_SYS_LPI);
+ fclose(fp);
return -1;
}
fclose(fp);
--
2.20.1
Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
Hey Marc, Thanks for the review! On 2019-04-08 14:24, Marc Gonzalez wrote: On 08/04/2019 10:30, Sibi Sankar wrote: On 2019-04-05 20:38, Marc Gonzalez wrote: On 27/03/2019 13:38, Sibi Sankar wrote: Add the shared cx/mx and sensor sub-system's cx and mx power-domains found on MSM8998. Signed-off-by: Sibi Sankar --- drivers/soc/qcom/rpmpd.c | 36 1 file changed, 36 insertions(+) diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c index 238a9e02e890..706a3f63038e 100644 --- a/drivers/soc/qcom/rpmpd.c +++ b/drivers/soc/qcom/rpmpd.c @@ -19,9 +19,12 @@ /* Resource types */ #define RPMPD_SMPA 0x61706d73 /* smpa */ #define RPMPD_LDOA 0x616f646c /* ldoa */ +#define RPMPD_RWCX 0x78637772 /* rwcx */ #define RPMPD_RWMX 0x786d7772 /* rwmx */ #define RPMPD_RWLC 0x636c7772 /* rwlc */ #define RPMPD_RWLM 0x6d6c7772 /* rwlm */ +#define RPMPD_RWSC 0x63737772 /* rwsc */ +#define RPMPD_RWSM 0x6d737772 /* rwsm */ I do not see any value in the comments. Maybe remove them? comments were included to add value though, however I guess the comments were definitely not clear enough. The magic values for the resources are calculated as follows: ascii to hex in reverse order eg: smpa -> 0x61706d73 0x61 0x70 0x6d 0x73 apms Ah... I see now. I agree that explaining *why* e.g. RPMPD_SMPA is defined as 0x61706d73 is worthwhile indeed. What I meant is that adding /* smpa */ to a macro named RPMPD_SMPA does not really bring any new information ;-) yeah I got that How about prefixing the whole block with a small blurb, for example /* The value of RPMPD_X is X encoded as a little-endian, lower-case, ASCII string */ sure will add this ^^ instead in the next re-spin Regards. -- -- Sibi Sankar -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: Regression in suspend-to-ram (TPM related) with 5.1-rc1 (BISECTED)
On 08.04.19 08:59, Paul Zimmerman wrote: > On Sun, Apr 7, 2019 at 10:53 PM Martin Kepplinger > wrote: >> >> On 21.03.19 14:41, Jarkko Sakkinen wrote: >>> On Tue, Mar 19, 2019 at 04:03:37PM -0700, Paul Zimmerman wrote: So I bisected this down to: # first bad commit: [a3fbfae82b4cb3ff9928e29f34c64d0507cad874] tpm: take TPM chip power gating out of tpm_transmit() but this doesn't revert cleanly on Linus' HEAD. Anyone have an idea what could be wrong here? >>> >>> Sorry I've been in flu for the early week. I spotted the bug >>> immediately. When I did these patches I did not have TPM 1.x at my >>> hand. I used fTPM 2.0 and dTPM 2.0. Stefan did TPM 1.x testing but I >>> probably forgot to ask him to try out suspend. >>> >>> Anyway, the bug is obvious and I'll send you a patch to try out. >>> Thanks a lot for bisecting this! >>> >>> /Jarkko >> >> Hi, >> >> Any news on this? It seems not to be fixed in -rc4. I'd happily test a >> patch too. >> > Hi Martin, > Patch is here: https://patchwork.kernel.org/patch/10865495/ > Don't know what the status of it is though. > > -- Paul > thanks. lgtm. Tested-by: Martin Kepplinger smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v3 19/36] thunderbolt: Extend tunnel creation to more than 2 adjacent switches
On Mon, Apr 08, 2019 at 10:53:37AM +0200, Lukas Wunner wrote: > Hm, what other cases are there, i.e. what is the meaning of a tb_regs_hop's > "next_hop" field if "out_port" doesn't have a remote? (And why does it > need to be tracked on the out_port? In case a remote is added later?) We also need to program HopIDs for adapter ports (PCIe, DP, NHI) in order to enable a path. The "next_hop" from NULL port to an adapter port tells the HopID a packet gets when it is routed to the adapter port and the adapter port registers then are used to specify which HopID means what (for PCIe there is only 8 but for DP there is 8 and 9, for NHI it can be anything the service driver has negotiated).
[PATCH -v5] x86/kvm: Implement HWCR support
Hi all,
here's v5 which keeps the HWCR functionality in kvm/x86.c so that
emulation of AMD guests on Intel hw still can work.
--
From: Borislav Petkov
The AMD hardware configuration register has some useful bits which can
be used by guests. Implement McStatusWrEn which can be used by guests
when injecting MCEs with the in-kernel mce-inject module.
For that, we need to set bit 18 - McStatusWrEn - first, before writing
the MCi_STATUS registers (otherwise we #GP).
Add the required machinery to do so.
Signed-off-by: Borislav Petkov
Cc: Jim Mattson
Cc: Joerg Roedel
Cc: KVM
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Sean Christopherson
Cc: Tom Lendacky
Cc: Tony Luck
Cc: Yazen Ghannam
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/x86.c | 45 -
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 159b5988292f..541c431df806 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -780,6 +780,9 @@ struct kvm_vcpu_arch {
/* Flush the L1 Data cache for L1TF mitigation on VMENTER */
bool l1tf_flush_l1d;
+
+ /* AMD MSRC001_0015 Hardware Configuration */
+ u64 msr_hwcr;
};
struct kvm_lpage_info {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 099b851dabaf..e07f21c1d2d4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2273,6 +2273,30 @@ static void kvmclock_sync_fn(struct work_struct *work)
KVMCLOCK_SYNC_PERIOD);
}
+/*
+ * On AMD, HWCR[McStatusWrEn] controls whether setting MCi_STATUS results in
#GP.
+ */
+static bool __set_mci_status(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+{
+ if (guest_cpuid_is_amd(vcpu)) {
+ struct msr_data tmp;
+
+ tmp.index = MSR_K7_HWCR;
+
+ if (kvm_get_msr_common(vcpu, &tmp))
+ return false;
+
+ /* McStatusWrEn enabled? */
+ if (tmp.data & BIT_ULL(18))
+ return true;
+ }
+
+ if (msr_info->data != 0)
+ return false;
+
+ return true;
+}
+
static int set_msr_mce(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
u64 mcg_cap = vcpu->arch.mcg_cap;
@@ -2304,9 +2328,13 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
if ((offset & 0x3) == 0 &&
data != 0 && (data | (1 << 10)) != ~(u64)0)
return -1;
- if (!msr_info->host_initiated &&
- (offset & 0x3) == 1 && data != 0)
- return -1;
+
+ /* MCi_STATUS */
+ if ((offset & 0x3) == 1 && !msr_info->host_initiated) {
+ if (!__set_mci_status(vcpu, msr_info))
+ return -1;
+ }
+
vcpu->arch.mce_banks[offset] = data;
break;
}
@@ -2455,8 +2483,11 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
data &= ~(u64)0x40; /* ignore flush filter disable */
data &= ~(u64)0x100;/* ignore ignne emulation enable */
data &= ~(u64)0x8; /* ignore TLB cache disable */
- data &= ~(u64)0x4; /* ignore Mc status write enable */
- if (data != 0) {
+
+ /* Handle McStatusWrEn */
+ if (data == BIT_ULL(18)) {
+ vcpu->arch.msr_hwcr = data;
+ } else if (data != 0) {
vcpu_unimpl(vcpu, "unimplemented HWCR wrmsr: 0x%llx\n",
data);
return 1;
@@ -2730,7 +2761,6 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
case MSR_K8_SYSCFG:
case MSR_K8_TSEG_ADDR:
case MSR_K8_TSEG_MASK:
- case MSR_K7_HWCR:
case MSR_VM_HSAVE_PA:
case MSR_K8_INT_PENDING_MSG:
case MSR_AMD64_NB_CFG:
@@ -2894,6 +2924,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
case MSR_MISC_FEATURES_ENABLES:
msr_info->data = vcpu->arch.msr_misc_features_enables;
break;
+ case MSR_K7_HWCR:
+ msr_info->data = vcpu->arch.msr_hwcr;
+ break;
default:
if (kvm_pmu_is_valid_msr(vcpu, msr_info->index))
return kvm_pmu_get_msr(vcpu, msr_info->index,
&msr_info->data);
--
2.21.0
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 1/4] rtc: coh901331: set range
On Sun, Apr 7, 2019 at 11:10 PM Alexandre Belloni wrote: > The COH 901 331 is a 32bit seconds counter. > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing
On Mon, 1 Apr 2019 10:17:19 -0700
Douglas Anderson wrote:
> From: Sean Paul
>
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
>
> - panel must not specify fixed mode (since the override mode will
> either be the same as the fixed mode, or we'll be unable to
> check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
> used to ensure the override mode fits within its bounds
>
> Changes in v2:
> - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
> - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
> - Don't add mode from timing if override was specified (Thierry)
> - Add warning if timing and fixed mode was specified (Thierry)
> - Don't add fixed mode if timing was specified (Thierry)
> - Refactor/rename a bit to avoid extra indentation from "if" tests
> - i should be unsigned (Thierry)
> - Add annoying WARN_ONs for some cases (Thierry)
> - Simplify 'No display_timing found' handling (Thierry)
> - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
> - Added Heiko's Tested-by
>
> Cc: Doug Anderson
> Cc: Eric Anholt
> Cc: Heiko Stuebner
> Cc: Jeffy Chen
> Cc: Rob Herring
> Cc: Stéphane Marchesin
> Cc: Thierry Reding
> Cc: devicet...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Sean Paul
> Tested-by: Enric Balletbo i Serra
> Signed-off-by: Douglas Anderson
> Tested-by: Heiko Stuebner
Reviewed-by: Boris Brezillon
> ---
>
> drivers/gpu/drm/panel/panel-simple.c | 109 +--
> 1 file changed, 104 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..ad4f4aac2d44 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
> #include
>
> #include
> +#include
> #include
>
> struct panel_desc {
> @@ -91,6 +92,8 @@ struct panel_simple {
> struct i2c_adapter *ddc;
>
> struct gpio_desc *enable_gpio;
> +
> + struct drm_display_mode override_mode;
> };
>
> static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -98,16 +101,13 @@ static inline struct panel_simple
> *to_panel_simple(struct drm_panel *panel)
> return container_of(panel, struct panel_simple, base);
> }
>
> -static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +static unsigned int panel_simple_get_timings_modes(struct panel_simple
> *panel)
> {
> struct drm_connector *connector = panel->base.connector;
> struct drm_device *drm = panel->base.drm;
> struct drm_display_mode *mode;
> unsigned int i, num = 0;
>
> - if (!panel->desc)
> - return 0;
> -
> for (i = 0; i < panel->desc->num_timings; i++) {
> const struct display_timing *dt = &panel->desc->timings[i];
> struct videomode vm;
> @@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct
> panel_simple *panel)
> num++;
> }
>
> + return num;
> +}
> +
> +static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +{
> + struct drm_connector *connector = panel->base.connector;
> + struct drm_device *drm = panel->base.drm;
> + struct drm_display_mode *mode;
> + unsigned int i, num = 0;
> +
> for (i = 0; i < panel->desc->num_modes; i++) {
> const struct drm_display_mode *m = &panel->desc->modes[i];
>
> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct
> panel_simple *panel)
> num++;
> }
>
> + return num;
> +}
> +
> +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> +{
> + struct drm_connector *connector = panel->base.connector;
> + struct drm_device *drm = panel->base.drm;
> + struct drm_display_mode *mode;
> + bool has_override = panel->override_mode.type;
> + unsigned int num = 0;
> +
> + if (!panel->desc)
> + return 0;
> +
> + if (has_override) {
> + mode = drm_mode_duplicate(drm, &panel->override_mode);
> + if (mode) {
> + drm_mode_probed_add(connector, mode);
> + num = 1;
> + } else {
> + dev_err(drm->dev, "failed to add override mode\n");
> + }
> + }
> +
> + /* Only add timings if override was not there or failed to validate */
> + if (num == 0 && panel->desc->num_timings)
> + num = panel_simple_get_timings_modes(panel);
> +
> + /*
> + * Only add fixed modes if timings/override added no mode.
> +
Re: [PATCH 2/4] rtc: coh901331: switch to rtc_time64_to_tm/rtc_tm_to_time64
On Sun, Apr 7, 2019 at 11:10 PM Alexandre Belloni wrote: > Call the 64bit versions of rtc_tm time conversion now that the range is > enforced by the core. > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 3/4] rtc: coh901331: use .set_time
On Sun, Apr 7, 2019 at 11:10 PM Alexandre Belloni wrote: > Use .set_time instead of the deprecated .set_mmss. > > Signed-off-by: Alexandre Belloni Acked-by: Linus Walleij Yours, Linus Walleij
