Re: [PATCH 1/3] ARM: dts: rockchip: phycore: Remove 1.8 GHz operation point
Am Dienstag, 13. Februar 2018, 10:44:32 CET schrieb Daniel Schultz: > Rockchip recommends to run the CPU cores only with operations points of > 1.6 GHz or lower. > > Removed the cpu0 node with too high operation points and use the default > values instead. > > Signed-off-by: Daniel Schultz applied all 3 for 4.17 Thanks Heiko
Re: [RFC PATCH 3/3] fs: fsnotify: account fsnotify metadata to kmemcg
On Wed, Feb 14, 2018 at 4:56 AM, Shakeel Butt wrote:
> This is RFC patch and the discussion on the API is still happening at
> the following link but I am sending the early draft for feedback.
> [link] https://marc.info/?l=linux-api&m=151850343717274
>
> A lot of memory can be consumed by the events generated for the huge or
> unlimited queues if there is either no or slow listener. This can cause
> system level memory pressure or OOMs. So, it's better to account the
> fsnotify kmem caches to the memcg of the listener.
>
> There are seven fsnotify kmem caches and among them allocations from
> dnotify_struct_cache, dnotify_mark_cache, fanotify_mark_cache and
> inotify_inode_mark_cachep happens in the context of syscall from the
fsnotify_mark_connector_cachep as well.
> listener. So, SLAB_ACCOUNT is enough for these caches. The allocations
> from the remaining caches can happen in the context of the event
I would rephrase: "The allocations from the event caches happen in the
context of the event producer".
> producer. For such caches we will need to remote charge the allocations
> to the listener's memcg. Thus we save the memcg reference in the
> fsnotify_group structure of the listener.
>
> This patch has also moved the members of fsnotify_group to keep the
> size same, at least for 64 bit build, even with additional member by
> filling the holes.
>
> Signed-off-by: Shakeel Butt
Other than connector cache and the API issue, this looks good.
Only some nit picking below.
[...]
> diff --git a/include/linux/fsnotify_backend.h
> b/include/linux/fsnotify_backend.h
> index 067d52e95f02..e1ed0f32ff92 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -84,6 +84,8 @@ struct fsnotify_event_private_data;
> struct fsnotify_fname;
> struct fsnotify_iter_info;
>
> +struct mem_cgroup;
> +
> /*
> * Each group much define these ops. The fsnotify infrastructure will call
> * these operations for each relevant group.
> @@ -129,6 +131,8 @@ struct fsnotify_event {
> * everything will be cleaned up.
> */
> struct fsnotify_group {
> + const struct fsnotify_ops *ops; /* how this group handles things */
> +
> /*
> * How the refcnt is used is up to each group. When the refcnt hits 0
> * fsnotify will clean up all of the resources associated with this
> group.
> @@ -139,8 +143,6 @@ struct fsnotify_group {
> */
> refcount_t refcnt; /* things with interest in this group
> */
>
> - const struct fsnotify_ops *ops; /* how this group handles things */
> -
> /* needed to send notification to userspace */
> spinlock_t notification_lock; /* protect the
> notification_list */
> struct list_head notification_list; /* list of event_holder this
> group needs to send to userspace */
> @@ -162,6 +164,8 @@ struct fsnotify_group {
> atomic_t num_marks; /* 1 for each mark and 1 for not being
> * past the point of no return when
> freeing
> * a group */
> + atomic_t user_waits;/* Number of tasks waiting for user
> +* response */
> struct list_head marks_list;/* all inode marks for this group */
>
> struct fasync_struct *fsn_fa;/* async notification */
> @@ -169,8 +173,8 @@ struct fsnotify_group {
> struct fsnotify_event *overflow_event; /* Event we queue when the
> * notification list is too
> * full */
> - atomic_t user_waits;/* Number of tasks waiting for user
> -* response */
> +
> + struct mem_cgroup *memcg_to_charge; /* memcg to charge allocations */
>
I am for brevity. IMO 'memcg' would be descriptive enough.
> /* groups can define private fields here or use the void *private */
> union {
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 9dec8a5c0ca2..0c877ddae4ef 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -352,6 +352,7 @@ struct mem_cgroup *mem_cgroup_from_css(struct
> cgroup_subsys_state *css){
> return css ? container_of(css, struct mem_cgroup, css) : NULL;
> }
>
> +struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm);
Missing newline.
> static inline void mem_cgroup_put(struct mem_cgroup *memcg)
> {
> css_put(&memcg->css);
Thanks,
Amir.
Re: [PATCH v3 0/4] optimize memory hotplug
* Andrew Morton wrote: > On Tue, 13 Feb 2018 14:31:55 -0500 Pavel Tatashin > wrote: > > > This patchset: > > - Improves hotplug performance by eliminating a number of > > struct page traverses during memory hotplug. > > > > - Fixes some issues with hotplugging, where boundaries > > were not properly checked. And on x86 block size was not properly aligned > > with end of memory > > > > - Also, potentially improves boot performance by eliminating condition from > > __init_single_page(). > > > > - Adds robustness by verifying that that struct pages are correctly > > poisoned when flags are accessed. > > I'm now attempting to get a 100% review rate on MM patches, which is > why I started adding my Reviewed-by: when I do that thing. > > I'm not familiar enough with this code to add my own Reviewed-by:, and > we'll need to figure out what to do in such cases. I shall be sending > out periodic review-status summaries. > > If you're able to identify a suitable reviewer for this work and to > offer them beer, that would help. Let's see what happens as the weeks > unfold. The largest patch, fix patch #2, looks good to me and fixes a real bug. Patch #1 and #3 also look good to me (assuming the runtime overhead added by patch #3 is OK to you): Reviewed-by: Ingo Molnar (I suspect patch #1 and patch #2 should also get a Cc: stable.) Patch #4 is too large to review IMO: it should be split up into as many patches as practically possible. That will also help bisectability, should anything break. Before applying these patches please fix changelog and code comment spelling. But it's all good stuff AFAICS! Thanks, Ingo
Re: [PATCH v3 2/3] arm64: dts: sdm845: Add minimal dts files for sdm845 SoC/MTP
[]..
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> new file mode 100644
>> index ..617c7bb25fb1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> @@ -0,0 +1,13 @@
>> +// SPDX-License-Identifier: GPL-2.0
>
> It would, of course, be up to Qualcomm. ...but might I suggest instead:
>
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> The device tree files really don't have any special secret sauce in
> them and IIRC allowing them to have a more permissive MIT license _or_
> a GPL allowed people to run other operating systems on these boards.
> This kind of thing is better to fix now so we don't have to go and get
> everyone's permission later on.
sure, sounds reasonable, but I am told I need to get this reviewed once
by qualcomm legal before we go ahead and use the dual licensing copyright.
I will update based on what I hear.
[]..
>
>> +/*
>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> + */
>
> IMHO add an extra line to this comment with a description to avoid the
> bike shedding of how we're supposed to do 1-line comments in device
> tree files. AKA:
>
> /*
> * SDM845 MTP board device tree source
> *
> * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> */
sure will update.
>
>
>> +
>> +/dts-v1/;
>> +
>> +#include "sdm845.dtsi"
>> +
>> +/ {
>> + model = "Qualcomm Technologies, Inc. SDM845 MTP";
>> + compatible = "qcom,sdm845-mtp";
>
> For me checkpatch complains about this. It looks like the file
> "Documentation/devicetree/bindings/arm/qcom.txt" needs to be updated
> with "sdm845". I don't think that will make checkpatch be quiet
> (since that file doesn't have a full list of every board), but it
> still should be the correct thing to do.
sure, I missed updating it, will fix.
>
>
>> +};
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> new file mode 100644
>> index ..55a7e0b454e1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -0,0 +1,275 @@
>> +// SPDX-License-Identifier: GPL-2.0
>
> As per above, suggest dual licensed?
>
>
>> +/*
>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>
> As per above, suggest adding an extra line to avoid the bikeshed.
>
> SDM845 SoC device tree source
>
>
> Besides those things, everything looks good as far as I can see. I'm
> not an expert on every one of the devices used in this file, but
> reading through bindings docs and looking at other users of them, it
> looks sane enough. Thus, with the above nits fixed you can feel free
> to add my Reviewed-by.
Thanks, the only thing I need to wait for before I respin this is to
get a go ahead from legal for the dual licensing copyright header.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support
I added all three patches to my next tree
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git/log/?h=next
This will hoepfully reveal any fallout.
Would be good to have an ACK from the score, tile and um maintainers in case
they verified that this change did not break anything.
On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
>
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on
>>> HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to
>>> build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
>
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
>
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?
>
>>> Signed-off-by: Farhan Ali
>>> Tested-by: Dong Jia Shi
>>
>> This also enables several PCI based graphic device driver on s390.
>> This makes no sense but they all compile fine so I guess this is ok.
>>
>> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
>> Also ccing Bart. Can we maybe get an ack to carry this patch also via the
>> s390
>> tree?
>>
>>
>>> ---
>>> drivers/video/Kconfig | 1 -
>>> drivers/video/fbdev/Kconfig | 2 +-
>>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..41e7ba9 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -3,7 +3,6 @@
>>> #
>>>
>>> menu "Graphics support"
>>> - depends on HAS_IOMEM
>>>
>>> config HAVE_FB_ATMEL
>>> bool
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2f615b7..ec9c9ce 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -966,7 +966,7 @@ config FB_PVR2
>>>
>>> config FB_OPENCORES
>>> tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
>>> - depends on FB && HAS_DMA
>>> + depends on FB && HAS_DMA && HAS_IOMEM
>>> select FB_CFB_FILLRECT
>>> select FB_CFB_COPYAREA
>>> select FB_CFB_IMAGEBLIT
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Re: [PATCH 2/2] x86: msr-index.h: Correct SNB_C1/C3_AUTO_UNDEMOTE defines
* Matt Turner wrote:
> According to the Intel Software Developers' Manual, Vol. 4, Order No.
> 335592, these macros have been reversed since they were added in the
> initial turbostat commit. The reversed definitions were presumably
> copied from turbostat.c to this file.
>
> Fixes: 9c63a650bb10 ("tools/power/x86/turbostat: share kernel MSR #defines")
> Signed-off-by: Matt Turner
Acked-by: Ingo Molnar
Thanks,
Ingo
[PATCH -mm 1/3] proc: randomize "struct pde_opener"
The more the merrier.
Signed-off-by: Alexey Dobriyan
---
fs/proc/internal.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -177,7 +177,7 @@ struct pde_opener {
struct list_head lh;
bool closing;
struct completion *c;
-};
+} __randomize_layout;
extern const struct inode_operations proc_link_inode_operations;
extern const struct inode_operations proc_pid_link_inode_operations;
Re: efi/apple-properties: Checking error handling in unmarshal_devices()
> While the allocator does print an error when allocations fail, > it may not be immediately apparent to the user what the > *consequences* are. In this case, the consequence is that the > device properties will not be available for consumption by > drivers and they may fail to probe or behave in entirely > unexpected ways. Would it make sense to indicate such a questionable software situation be any return code? > Hence I deliberately printed an error message here so that the user > can make the connection between erratic behavior of drivers later on > and the memory allocation error here. Do you find this terse message really sufficient? Can the mentioned properties be required for the desired system configuration? Regards, Markus
[PATCH -mm 2/3] proc: move "struct pde_opener" to kmem cache
"struct pde_opener" is fixed size and we can have more granular approach
to debugging.
For those who don't know, per cache SLUB poisoning and red zoning
don't work if there is at least one object allocated which is hopeless
in case of kmalloc-64 but not in case of standalone cache.
Although systemd opens 2 files from the get go, so it is hopeless after
all.
Signed-off-by: Alexey Dobriyan
---
fs/proc/inode.c| 12
fs/proc/internal.h |2 +-
fs/proc/root.c |2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -54,6 +54,7 @@ static void proc_evict_inode(struct inode *inode)
}
static struct kmem_cache *proc_inode_cachep __ro_after_init;
+static struct kmem_cache *pde_opener_cache __ro_after_init;
static struct inode *proc_alloc_inode(struct super_block *sb)
{
@@ -92,7 +93,7 @@ static void init_once(void *foo)
inode_init_once(&ei->vfs_inode);
}
-void __init proc_init_inodecache(void)
+void __init proc_init_kmemcache(void)
{
proc_inode_cachep = kmem_cache_create("proc_inode_cache",
sizeof(struct proc_inode),
@@ -100,6 +101,9 @@ void __init proc_init_inodecache(void)
SLAB_MEM_SPREAD|SLAB_ACCOUNT|
SLAB_PANIC),
init_once);
+ pde_opener_cache =
+ kmem_cache_create("pde_opener", sizeof(struct pde_opener), 0,
+ SLAB_PANIC, NULL);
}
static int proc_show_options(struct seq_file *seq, struct dentry *root)
@@ -172,7 +176,7 @@ static void close_pdeo(struct proc_dir_entry *pde, struct
pde_opener *pdeo)
spin_unlock(&pde->pde_unload_lock);
if (unlikely(c))
complete(c);
- kfree(pdeo);
+ kmem_cache_free(pde_opener_cache, pdeo);
}
}
@@ -347,7 +351,7 @@ static int proc_reg_open(struct inode *inode, struct file
*file)
release = pde->proc_fops->release;
if (release) {
- pdeo = kmalloc(sizeof(struct pde_opener), GFP_KERNEL);
+ pdeo = kmem_cache_alloc(pde_opener_cache, GFP_KERNEL);
if (!pdeo) {
rv = -ENOMEM;
goto out_unuse;
@@ -368,7 +372,7 @@ static int proc_reg_open(struct inode *inode, struct file
*file)
list_add(&pdeo->lh, &pde->pde_openers);
spin_unlock(&pde->pde_unload_lock);
} else
- kfree(pdeo);
+ kmem_cache_free(pde_opener_cache, pdeo);
}
out_unuse:
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -182,7 +182,7 @@ extern const struct inode_operations
proc_link_inode_operations;
extern const struct inode_operations proc_pid_link_inode_operations;
-extern void proc_init_inodecache(void);
+void proc_init_kmemcache(void);
void set_proc_pid_nlink(void);
extern struct inode *proc_get_inode(struct super_block *, struct
proc_dir_entry *);
extern int proc_fill_super(struct super_block *, void *data, int flags);
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -125,7 +125,7 @@ void __init proc_root_init(void)
{
int err;
- proc_init_inodecache();
+ proc_init_kmemcache();
set_proc_pid_nlink();
err = register_filesystem(&proc_fs_type);
if (err)
Re: [PATCH v2 0/8] Add support for PWM input capture on STM32
On 01/26/2018 04:11 PM, Fabrice Gasnier wrote: > This series adds support for capture to stm32-pwm driver. > Capture is based on DMAs. > - First two patches are precursor patches > - Subsequent two patches add support for requesting DMAs to MFD core > - Next three patches add support for capture to stm32-pwm driver > - This has been tested on stm32429i-eval board. > > --- > Changes in v2: > - Abstract DMA handling from child driver: move it to MFD core > - Rework pwm capture routines to adopt this change > - Comment on optional dma support, beautify DMAs probe Hi all, Gentle ping for v2 driver review since DT Bindings has been reviewed by Rob and the series by Benjamin. Many thanks in advance Regards Fabrice > > Fabrice Gasnier (8): > pwm: stm32: fix, remove unused struct device > pwm: stm32: protect common prescaler for all channels > dt-bindings: mfd: stm32-timers: add support for dmas > mfd: stm32-timers: add support for dmas > pwm: stm32: add capture support > pwm: stm32: improve capture by tuning counter prescaler > pwm: stm32: use input prescaler to improve period capture > ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval > > .../devicetree/bindings/mfd/stm32-timers.txt | 20 ++ > arch/arm/boot/dts/stm32429i-eval.dts | 3 + > drivers/mfd/stm32-timers.c | 215 +++- > drivers/pwm/pwm-stm32.c| 276 > - > include/linux/mfd/stm32-timers.h | 39 +++ > 5 files changed, 547 insertions(+), 6 deletions(-) >
[PATCH -mm 3/3] proc: account "struct pde_opener"
The allocation is persistent in fact as any fool can open a file in
/proc and sit on it.
Signed-off-by: Alexey Dobriyan
---
fs/proc/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -103,7 +103,7 @@ void __init proc_init_kmemcache(void)
init_once);
pde_opener_cache =
kmem_cache_create("pde_opener", sizeof(struct pde_opener), 0,
- SLAB_PANIC, NULL);
+ SLAB_ACCOUNT|SLAB_PANIC, NULL);
}
static int proc_show_options(struct seq_file *seq, struct dentry *root)
Re: [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
On Tue, Feb 13, 2018 at 7:22 PM, Tomasz Figa wrote: > On Tue, Feb 13, 2018 at 9:57 PM, Robin Murphy wrote: >> On 13/02/18 08:24, Tomasz Figa wrote: >>> >>> Hi Vivek, >>> >>> Thanks for the patch. Please see my comments inline. >>> >>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam >>> wrote: From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those places separately. Signed-off-by: Sricharan R [vivek: Cleanup pm runtime calls] Signed-off-by: Vivek Gautam --- drivers/iommu/arm-smmu.c | 42 ++ 1 file changed, 38 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 9e2f917e16c2..c024f69c1682 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct iommu_domain *domain) struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); struct arm_smmu_device *smmu = smmu_domain->smmu; struct arm_smmu_cfg *cfg = &smmu_domain->cfg; - int irq; + int ret, irq; if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY) return; + ret = pm_runtime_get_sync(smmu->dev); + if (ret) + return; >>> >>> >>> pm_runtime_get_sync() will return 0 if the device was powered off, 1 >>> if it was already/still powered on or runtime PM is not compiled in, >>> or a negative value on error, so shouldn't the test be (ret < 0)? >>> >>> Moreover, I'm actually wondering if it makes any sense to power up the >>> hardware just to program it and power it down again. In a system where >>> the IOMMU is located within a power domain, it would cause the IOMMU >>> block to lose its state anyway. >> >> >> This is generally for the case where the SMMU internal state remains active, >> but the programming interface needs to be powered up in order to access it. > > That's true for Qualcomm SMMU, but I think that would be different for > existing users of the driver? > >> >>> Actually, reflecting back on "[PATCH v7 2/6] iommu/arm-smmu: Add >>> pm_runtime/sleep ops", perhaps it would make more sense to just >>> control the clocks independently of runtime PM? Then, runtime PM could >>> be used for real power management, e.g. really powering the block up >>> and down, for further power saving. >> >> >> Unfortunately that ends up pretty much unmanageable, because there are >> numerous different SMMU microarchitectures with fundamentally different >> clock/power domain schemes (multiplied by individual SoC integration >> possibilities). Since this is fundamentally a generic architectural driver, >> adding explicit clock support would probably make the whole thing about 50% >> clock code, with complicated decision trees around every hardware access >> calculating which clocks are necessary for a given operation on a given >> system. That maintainability aspect is why we've already nacked such a >> fine-grained approach in the past. > > Hmm, I think we are talking about different things here. My suggestion > would not add much more code to the driver than this patch does, calls > to arm_smmu_enable_clocks() instead of pm_runtime_get_sync() and > arm_smmu_disable_clocks() instead of pm_runtime_put(). The > implementation of both functions would be a simple call to clk_bulk_ > API (possibly even no need to put this into functions, just call > directly). Well, things are not so straight on msm. The IP clocks on msm are usually powered by (or i should rather say, controlled by) the same power domain that provides the VDD supply to iommu block. This is the behavior on msm8996 atleast that we are testing on right now. On later SoCs too things don't change drastically. So, you can't have the block in low power state until you program the register space and then power on the block to let it do its magic. Clocks and power domains are linked, and that's why we add them to the pm callbacks. This approach also looks generic to me since the platforms will either have such a link or they will not have. But, in either case you will have power and clocks available at the time when you need them. Thanks & regards Vivek > > Best regards, > Tomasz > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
Hi Tomasz, On Tue, Feb 13, 2018 at 1:54 PM, Tomasz Figa wrote: > Hi Vivek, > > Thanks for the patch. Please see my comments inline. > > On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam > wrote: >> From: Sricharan R >> >> The smmu device probe/remove and add/remove master device callbacks >> gets called when the smmu is not linked to its master, that is without >> the context of the master device. So calling runtime apis in those places >> separately. >> >> Signed-off-by: Sricharan R >> [vivek: Cleanup pm runtime calls] >> Signed-off-by: Vivek Gautam >> --- >> drivers/iommu/arm-smmu.c | 42 ++ >> 1 file changed, 38 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index 9e2f917e16c2..c024f69c1682 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct >> iommu_domain *domain) >> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >> struct arm_smmu_device *smmu = smmu_domain->smmu; >> struct arm_smmu_cfg *cfg = &smmu_domain->cfg; >> - int irq; >> + int ret, irq; >> >> if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY) >> return; >> >> + ret = pm_runtime_get_sync(smmu->dev); >> + if (ret) >> + return; > > pm_runtime_get_sync() will return 0 if the device was powered off, 1 > if it was already/still powered on or runtime PM is not compiled in, > or a negative value on error, so shouldn't the test be (ret < 0)? Yes, I too noticed it while i was testing on a different platform, and was hitting a failure case. Will update at all places. > > Moreover, I'm actually wondering if it makes any sense to power up the > hardware just to program it and power it down again. In a system where > the IOMMU is located within a power domain, it would cause the IOMMU > block to lose its state anyway. > > Actually, reflecting back on "[PATCH v7 2/6] iommu/arm-smmu: Add > pm_runtime/sleep ops", perhaps it would make more sense to just > control the clocks independently of runtime PM? Then, runtime PM could > be used for real power management, e.g. really powering the block up > and down, for further power saving. > > +Generally similar comments for other places in this patch. > >> + >> /* >> * Disable the context bank and free the page tables before freeing >> * it. >> @@ -932,6 +936,8 @@ static void arm_smmu_destroy_domain_context(struct >> iommu_domain *domain) >> >> free_io_pgtable_ops(smmu_domain->pgtbl_ops); >> __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx); >> + >> + pm_runtime_put_sync(smmu->dev); > > Is there any point in the put being sync here? No, I don't think. Can manage with just a 'put' here. Will modify. best regards Vivek > > [snip] > >> @@ -2131,6 +2152,14 @@ static int arm_smmu_device_probe(struct >> platform_device *pdev) >> if (err) >> return err; >> >> + platform_set_drvdata(pdev, smmu); >> + >> + pm_runtime_enable(dev); > > I suspect this may be a disaster for systems where IOMMUs are located > inside power domains, because the driver doesn't take care of the > IOMMU block losing its state on physical power down, as I mentioned in > my comments above. > > Best regards, > Tomasz -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [patch] kvm: suppress KVM_SET_GSI_ROUTING allocation failure
On 02/14/2018 02:03 AM, David Rientjes wrote:
> On Tue, 13 Feb 2018, Paolo Bonzini wrote:
>
The KVM_SET_GSI_ROUTING ioctl does a vmalloc() of
sizeof(struct kvm_irq_routing_entry) multiplied by a user-supplied value.
This can be up to 4096 entries on architectures such as arm64 and s390
(and the upper bound may be increased on s390 eventually).
This can produce a vmalloc allocation failure warning:
>>> [...]
kvm_vm_ioctl+0x910/0x15e0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4153
>>>
>>>^
>>>
@@ -3063,7 +3063,8 @@ static long kvm_vm_ioctl(struct file *filp,
>>>
>>> ^
>>>
>>>
>>> Are you sure that you got the right vmalloc?
>>
>> Nice catch! But well, it's the only one in the whole file. :)
>>
>> That seems very much like an old patch then. I'm unqueuing it.
>>
>
> It's not a catch at all, the fact that I saw this warning with an older
> kernel for KVM_SET_GSI_ROUTING doesn't mean that I can't patch it with an
> upstream kernel. Would you prefer I remove the stack trace completely?
FWIW, your stack trace did not complain about a too big allocation, it
complained about 0 allocation:
- snip --
vmalloc: allocation failure: 0 bytes, mode:0x24000c2(GFP_KERNEL|__GFP_HIGHMEM)
- snip --
After commit f8c1b85b2523 ("KVM: x86: avoid vmalloc(0) in the KVM_SET_CPUID)"
this case should be prevented. The only question is does your patch makes sense
nevertheless as we gracefully handle the ENOMEM case? So a reproducer on
a newer kernel would be good. Maybe use the "vmalloc" kernel parameter to force
this.
Re: [PATCH] lib/scatterlist: Add SG_CHAIN and SG_EMARK macros for LSB encodings
On Wed, 2018-02-14 at 10:28 +0530, Anshuman Khandual wrote:
> This replaces scatterlist->page_link LSB encodings with SG_CHAIN and
> SG_EMARK definitions without any functional change.
>
> Signed-off-by: Anshuman Khandual
> ---
> include/linux/scatterlist.h | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/scatterlist.h
> b/include/linux/scatterlist.h
> index 22b2131bcdcd..63d00bdb2fb3 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -65,16 +65,18 @@ struct sg_table {
> */
>
> #define SG_MAGIC 0x87654321
> +#define SG_CHAIN 0x01
> +#define SG_EMARK 0x02
SG_EMARK sounds strange, what about SG_END?
--
Johannes Thumshirn Storage
jthu
msh...@suse.de +49 911 74053 689
SUSE
LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane
Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38
9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH] perf: Add support for creating offline events
On Tue, Feb 13, 2018 at 02:17:07PM -0800, Sodagudi Prasad wrote: > > This is horrible.. and you seem to have forgotten to explain why you > > care about offline CPUs. > > Up to 4.9 kernel, drivers can register cpu hotplug notfiters and drivers are > able to create perf events dynamically based cpu notifies callback events. > As cpu hot plug is converted to state machine approach from hot plug > notifiers, every driver need to define a cpuhp state and registers with cpu > hotplug state machine for creating perf events dynamically. > > Qualcomm have use cases to monitor the cpu cycles and other hw events > continuously on all cpus from kernel and profiling tools. > So we are thinking that there could be other soc vendors, who are interested > in perf events preserving across cpu hot plug and perf events creation on > hot plugged cores. But _why_ are you hotplugging to begin with? Just don't do that.
RE: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
Hi Kees, When I raised the question of whether we want to add support for "asm goto" in llvm I got some feedback from the community that "asm goto" might not be the best solution for the problem it was invented for (optimizing support for tracepoints), so I stopped perusing this issue. I'm CC-ing the developers that participated in the original thread and a few developers that might be interested in adding support of "asm goto". I'm also adding the llvm-dev mailing list, in case there are additional parties interested in voicing their opinion. I hope this will give this issue a push forward and we will find a solution that will not prevent llvm from compiling linux kernel. Thanks, Marina -Original Message- From: Kees Cook [mailto:keesc...@google.com] Sent: Wednesday, February 14, 2018 02:29 To: David Woodhouse ; Chandler Carruth ; Yatsina, Marina Cc: Guenter Roeck ; X86 ML ; LKML ; Alan Cox ; Rik van Riel ; Andi Kleen ; Josh Poimboeuf ; Tom Lendacky ; Peter Zijlstra ; Linus Torvalds ; Jiri Kosina ; Andy Lutomirski ; Hansen, Dave ; Tim Chen ; Greg Kroah-Hartman ; Paul Turner ; Stephen Hines ; Nick Desaulniers Subject: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support) On Tue, Feb 13, 2018 at 4:10 PM, David Woodhouse wrote: > We also need to resolve the asm-goto thing. Yes, this is becoming much more urgent, assuming we'll be raising the minimum GCC version soon and drop support for lacking asm-goto... Do you happen to know who the right people are to include to move the discussion forward? I know various kernel folks that are passionate about it, but I'm still getting to know who to talk with from llvm. I see an earlier thread here: http://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.html It seems to end there? I'm still coming up to speed on it, so I'm likely missing other context. -Kees -- Kees Cook Pixel Security - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [PATCH 1/2] vfio: platform: Fix reset module leak in error path
Hi Geert,
On 13/02/18 17:36, Geert Uytterhoeven wrote:
> If the IOMMU group setup fails, the reset module is not released.
>
> Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by
> default")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/vfio/platform/vfio_platform_common.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vfio/platform/vfio_platform_common.c
> b/drivers/vfio/platform/vfio_platform_common.c
> index 35469af87f88678e..b60bb5326668498c 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct
> vfio_platform_device *vdev,
Thanks for fixing this.
If I am not wrong we also leak the reset_module if
vfio_platform_get_reset() fails to find the reset function (of_reset ==
NULL), in which case we should do the module_put() in
vfio_platform_get_reset().
Thanks
Eric
> group = vfio_iommu_group_get(dev);
> if (!group) {
> pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto put_reset;
> }
>
> ret = vfio_add_group_dev(dev, &vfio_platform_ops, vdev);
> - if (ret) {
> - vfio_iommu_group_put(group, dev);
> - return ret;
> - }
> + if (ret)
> + goto put_iommu;
>
> mutex_init(&vdev->igate);
>
> return 0;
> +
> +put_iommu:
> + vfio_iommu_group_put(group, dev);
> +put_reset:
> + vfio_platform_put_reset(vdev);
> + return ret;
> }
> EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
>
>
[tip:x86/pti] x86/cpu: Change type of x86_cache_size variable to unsigned int
Commit-ID: 0bfa9f1c5d3d290461f554520b8f24316ec971e0
Gitweb: https://git.kernel.org/tip/0bfa9f1c5d3d290461f554520b8f24316ec971e0
Author: Gustavo A. R. Silva
AuthorDate: Tue, 13 Feb 2018 13:22:08 -0600
Committer: Ingo Molnar
CommitDate: Wed, 14 Feb 2018 09:14:44 +0100
x86/cpu: Change type of x86_cache_size variable to unsigned int
Currently, x86_cache_size is of type int, which makes no sense as we
will never have a valid cache size equal or less than 0. So instead of
initializing this variable to -1, it can perfectly be initialized to 0
and use it as an unsigned variable instead.
Suggested-by: Thomas Gleixner
Signed-off-by: Gustavo A. R. Silva
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Addresses-Coverity-ID: 1464429
Link: http://lkml.kernel.org/r/20180213192208.ga26...@embeddedor.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/processor.h | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/microcode/intel.c | 2 +-
arch/x86/kernel/cpu/proc.c| 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b7c8583..44c2c4e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -109,7 +109,7 @@ struct cpuinfo_x86 {
charx86_vendor_id[16];
charx86_model_id[64];
/* in KB - valid for CPUS which support this call: */
- int x86_cache_size;
+ unsigned intx86_cache_size;
int x86_cache_alignment;/* In bytes */
/* Cache QoS architectural values: */
int x86_cache_max_rmid; /* max index */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a7d8df6..824aee0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1184,7 +1184,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
int i;
c->loops_per_jiffy = loops_per_jiffy;
- c->x86_cache_size = -1;
+ c->x86_cache_size = 0;
c->x86_vendor = X86_VENDOR_UNKNOWN;
c->x86_model = c->x86_stepping = 0; /* So far unknown... */
c->x86_vendor_id[0] = '\0'; /* Unset */
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index b94279b..a15db2b 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -982,7 +982,7 @@ static struct microcode_ops microcode_intel_ops = {
static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c)
{
- u64 llc_size = c->x86_cache_size * 1024;
+ u64 llc_size = c->x86_cache_size * 1024ULL;
do_div(llc_size, c->x86_max_cores);
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index ee4cc38..2c8522a 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -91,8 +91,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)
}
/* Cache size */
- if (c->x86_cache_size >= 0)
- seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
+ if (c->x86_cache_size)
+ seq_printf(m, "cache size\t: %u KB\n", c->x86_cache_size);
show_cpuinfo_core(m, c, cpu);
show_cpuinfo_misc(m, c);
Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg
On Wed, Feb 14, 2018 at 3:59 AM, Shakeel Butt wrote: > On Tue, Feb 13, 2018 at 2:20 PM, Shakeel Butt wrote: [...] > Something like FAN_GROUP_QUEUE (better name is welcome) > which is mutually exclusive (?) with FAN_UNLIMITED_QUEUE. > >> >> How about FAN_CHARGE_MEMCG? >> I am not crazy about this name. Imagine a user that writes a file system listener that is going to run inside a container. The user doesn't need to know about the container or what is memcg and what is memcg charging. IMO, we need to hide those implementation details from the user and yet encourage user to opt-in for memcg charging... or do we? > > Also should there be a similar flag for inotify_init1() as well? > This question changed my perspective on the fanotify_init() flag. Unlike with fanotify, for inotify, is it the sysadmin that determines the size of the queue of future listeners by setting /proc/sys/fs/inotify/max_queued_events IMO, there is little justification for a program to opt-out of memcg charging if the sysadmin opts-in for memcg charging. Anyone disagrees with that claim? So how about /proc/sys/fs/inotify/charge_memcg which defaults to CONFIG_INOTIFY_CHARGE_MEMCG which defaults to N. Then sysadmin can opt-in/out of new behavior and distro can opt-in for new behavior by default and programs don't need to be recompiled. I think that should be enough to address the concern of changing existing behavior. The same logic could also apply to fanotify, excpet we may want to use sysfs instead of procfs. The question is: do we need a separate knob for charging memcg for inotify and fanotify or same knob can control both? I can't think of a reason why we really need 2 knobs, but maybe its just nicer to have the inotify knob next to the existing max_queued_events knob. Thanks, Amir.
Re: [PATCH v2 2/4] arm64: dts: renesas: r8a77995: add VSP instances
Hi Laurent,
Thanks for the review,
On 13/02/18 22:03, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Tuesday, 13 February 2018 21:30:35 EET Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> The r8a77995 has a VSPBS to support image processing such as blending of
>> two input images, and has two VSPDs to handle display pipelines with a
>> DU.
>>
>> Signed-off-by: Kieran Bingham
>>
>> ---
>> v2:
>> - Fix VSPD register map size
>> - Squash VSPBS and VSPD patches together
>>
>> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 30
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
>> 196a917afea6..19bd8be9926a 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> @@ -692,6 +692,16 @@
>> status = "disabled";
>> };
>>
>> +vspbs: vsp@fe96 {
>> +compatible = "renesas,vsp2";
>> +reg = <0 0xfe96 0 0x4000>;
>
> The VSPBS also has OSD-CLUT support in its RPFs, so you need to extend the
> registers range too.
>
Wait, but I already changed this ...
Yup - this change is already in my tree ... which means I must have made the
change *after* calling git format-patch. Not helpful.
Orz
> Apart from that,
>
> Reviewed-by: Laurent Pinchart
I'll collect the tag and repost, this time with the correctly updated version.
(And I'll add in that missing vspd3 from the es1 tree too)
>> +interrupts = ;
>> +clocks = <&cpg CPG_MOD 627>;
>> +power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>> +resets = <&cpg 627>;
>> +renesas,fcp = <&fcpvb0>;
>> +};
>> +
>> fcpvb0: fcp@fe96f000 {
>> compatible = "renesas,fcpv";
>> reg = <0 0xfe96f000 0 0x200>;
>> @@ -701,6 +711,16 @@
>> iommus = <&ipmmu_vp0 5>;
>> };
>>
>> +vspd0: vsp@fea2 {
>> +compatible = "renesas,vsp2";
>> +reg = <0 0xfea2 0 0x8000>;
>> +interrupts = ;
>> +clocks = <&cpg CPG_MOD 623>;
>> +power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>> +resets = <&cpg 623>;
>> +renesas,fcp = <&fcpvd0>;
>> +};
>> +
>> fcpvd0: fcp@fea27000 {
>> compatible = "renesas,fcpv";
>> reg = <0 0xfea27000 0 0x200>;
>> @@ -710,6 +730,16 @@
>> iommus = <&ipmmu_vi0 8>;
>> };
>>
>> +vspd1: vsp@fea8 {
>> +compatible = "renesas,vsp2";
>> +reg = <0 0xfea28000 0 0x8000>;
>> +interrupts = ;
>> +clocks = <&cpg CPG_MOD 622>;
>> +power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>> +resets = <&cpg 622>;
>> +renesas,fcp = <&fcpvd1>;
>> +};
>> +
>> fcpvd1: fcp@fea2f000 {
>> compatible = "renesas,fcpv";
>> reg = <0 0xfea2f000 0 0x200>;
>
[tip:x86/pti] x86/spectre: Fix an error message
Commit-ID: b4764623932ff364df9a6bc8664ab7697c475339
Gitweb: https://git.kernel.org/tip/b4764623932ff364df9a6bc8664ab7697c475339
Author: Dan Carpenter
AuthorDate: Wed, 14 Feb 2018 10:14:17 +0300
Committer: Ingo Molnar
CommitDate: Wed, 14 Feb 2018 08:23:07 +0100
x86/spectre: Fix an error message
If i == ARRAY_SIZE(mitigation_options) then we accidentally print
garbage from one space beyond the end of the mitigation_options[] array.
Signed-off-by: Dan Carpenter
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: KarimAllah Ahmed
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: kernel-janit...@vger.kernel.org
Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing")
Link: http://lkml.kernel.org/r/20180214071416.GA26677@mwanda
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 4acf16a..d71c8b5 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -174,7 +174,7 @@ static enum spectre_v2_mitigation_cmd __init
spectre_v2_parse_cmdline(void)
}
if (i >= ARRAY_SIZE(mitigation_options)) {
- pr_err("unknown option (%s). Switching to AUTO
select\n", mitigation_options[i].option);
+ pr_err("unknown option (%s). Switching to AUTO
select\n", arg);
return SPECTRE_V2_CMD_AUTO;
}
}
Re: WARNING in kvmalloc_node
On Tue 13-02-18 18:55:33, Matthew Wilcox wrote: > On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote: [...] > > kvmalloc include/linux/mm.h:541 [inline] > > kvmalloc_array include/linux/mm.h:557 [inline] > > __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline] > > ptr_ring_init include/linux/ptr_ring.h:492 [inline] > > __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline] > > cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490 > > map_update_elem kernel/bpf/syscall.c:698 [inline] > > Blame the BPF people, not the MM people ;-) Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic. -- Michal Hocko SUSE Labs
Re: [PATCH v3] ASoC: use DEFINE_SHOW_ATTRIBUTE() to decrease code duplication
On Mon, Feb 12, 2018 at 3:49 AM, Mark Brown wrote: > On Fri, Feb 09, 2018 at 11:10:55PM +0800, Donglin Peng wrote: > >> --- a/sound/soc/soc-core.c >> +++ b/sound/soc/soc-core.c >> @@ -349,7 +349,7 @@ static void soc_init_codec_debugfs(struct >> snd_soc_component *component) >> "ASoC: Failed to create codec register debugfs file\n"); > > Your patch has been corrupted somewhere (probably in your mail client) - > there's word wrapping here. Sorry, I will check it.
Re: [PATCH 00/31 v2] PTI support for x86_32
On Tue, Feb 13, 2018 at 09:25:34AM -0800, Linus Torvalds wrote:
> On Tue, Feb 13, 2018 at 12:54 AM, Greg KH wrote:
> > On Sun, Feb 11, 2018 at 09:40:41AM -0800, Mark D Rustad wrote:
> >>
> >> ISTR that iscsi doesn't work when running a 64-bit kernel with a
> >> 32-bit userspace. I remember someone offered kernel patches to fix it,
> >> but I think they were rejected. I haven't messed with that stuff in
> >> many years, so perhaps the userspace side now has accommodation for
> >> it. It might be something to check on.
> >
> > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now.
> >
> > Back in 2015 someone started to work on that, and properly marked that
> > the kernel could not handle this with commit 74005991b78a ("xfrm: Do not
> > parse 32bits compiled xfrm netlink msg on 64bits host")
> >
> > This is starting to be hit by some Android systems that are moving
> > (yeah, slowly) to 4.4 :(
>
> Does anybody have test-programs/harnesses for this?
Lorenzo (now on the To: line), is the one that I think is looking into
this, and should have some sort of test for it. Lorenzo?
> This is an area I care deeply about: I really want people to not have
> any excuses for not upgrading to a 64-bit kernel. It used to be
> autofs (I actually added that whole "packetized pipe" model just to
> make automount "just w ork" even though the stupid protocol used a
> pipe to send command packets that had different layout on 32-bit and
> 64-bit).
>
> See commit 64f371bc3107 ("autofs: make the autofsv5 packet file
> descriptor use a packetized pipe") for some discussion of that
> particular saga.
>
> Some drm people used to run 32-bit kernels because of compat worries,
> and that would have been a disaster. They got very good about not
> having compat issues.
>
> So let's try to fix the iscsi and ipsec issues. Not that anybody sane
> should use that overly complex ipsec thing, and I think we should
> strive to merge WireGuard and get people moved over to that instead,
> but I haven't heard anything from davem about it since I last asked..
> I have some hope that it's slowly happening.
WireGuard is still being worked on, it needs some crypto library changes
that should be coming soon, but will probably be 6 months out at the
earliest to get merged. There are still lots of people using IPSEC :(
thanks,
greg k-h
[PATCH] ARM64: dts: allwinner: sun50i-h5-orangepi-zero-plus2: rename mmc0_pins_a to mmc0_pins
mmc0_pins_a were renamed in arch/arm but not in arch/arm64 resulting in
a build failure.
Fixes: 813f2c8fa119 ("ARM: dts: sunxi: h3-h5: rename mmc0_pins_a and
mmc1_pins_a")
Signed-off-by: Corentin Labbe
---
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index feee125a4e9a..87c1a0dace5f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -82,7 +82,7 @@
&mmc1 {
pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins_a>;
+ pinctrl-0 = <&mmc1_pins>;
vmmc-supply = <®_vcc3v3>;
vqmmc-supply = <®_vcc3v3>;
mmc-pwrseq = <&wifi_pwrseq>;
--
2.13.6
Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware
On Tue, Feb 13, 2018 at 05:49:47PM -0800, Tim Chen wrote:
> static inline void firmware_restrict_branch_speculation_start(void)
> {
> + if (this_cpu_inc_return(spec_ctrl_ibrs_fw_depth) == 1)
> + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> X86_FEATURE_USE_IBRS_FW);
> }
>
> static inline void firmware_restrict_branch_speculation_end(void)
> {
> + if (this_cpu_dec_return(spec_ctrl_ibrs_fw_depth) == 0)
> + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
> + X86_FEATURE_USE_IBRS_FW);
> }
At the very least this must disable and re-enable preemption, such that
we guarantee we inc/dec the same counter. ISTR some firmware calls (EFI)
actually are preemptible so that wouldn't work.
Further, consider:
this_cpu_inc_return() // 0->1
this_cpu_inc_return() // 1->2
call_broken_arse_firmware()
this_cpu_dec_return() // 2->1
wrmsr(SPEC_CTRL, IBRS);
/* from dodgy firmware crap */
this_cpu_dec_return() // 1->0
wrmsr(SPEC_CTRL, 0);
Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware
On Wed, Feb 14, 2018 at 09:56:14AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 13, 2018 at 05:49:47PM -0800, Tim Chen wrote:
>
> > static inline void firmware_restrict_branch_speculation_start(void)
> > {
> > + if (this_cpu_inc_return(spec_ctrl_ibrs_fw_depth) == 1)
> > + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> > X86_FEATURE_USE_IBRS_FW);
> > }
> >
> > static inline void firmware_restrict_branch_speculation_end(void)
> > {
> > + if (this_cpu_dec_return(spec_ctrl_ibrs_fw_depth) == 0)
> > + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
> > + X86_FEATURE_USE_IBRS_FW);
> > }
>
>
> At the very least this must disable and re-enable preemption, such that
> we guarantee we inc/dec the same counter. ISTR some firmware calls (EFI)
> actually are preemptible so that wouldn't work.
>
> Further, consider:
>
> this_cpu_inc_return() // 0->1
>
> this_cpu_inc_return() // 1->2
> call_broken_arse_firmware()
> this_cpu_dec_return() // 2->1
>
> wrmsr(SPEC_CTRL, IBRS);
>
> /* from dodgy firmware crap */
s/from/more/
typing hard.
> this_cpu_dec_return() // 1->0
> wrmsr(SPEC_CTRL, 0);
Re: [PATCH v2] reset: add support for non-DT systems
2018-02-13 20:17 GMT+01:00 Andy Shevchenko :
> On Tue, Feb 13, 2018 at 8:39 PM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski
>>
>> The reset framework only supports device-tree. There are some platforms
>> however, which need to use it even in legacy, board-file based mode.
>>
>> An example of such architecture is the DaVinci family of SoCs which
>> supports both device tree and legacy boot modes and we don't want to
>> introduce any regressions.
>>
>> We're currently working on converting the platform from its hand-crafted
>> clock API to using the common clock framework. Part of the overhaul will
>> be representing the chip's power sleep controller's reset lines using
>> the reset framework.
>>
>> This changeset extends the core reset code with a new field in the
>> reset controller struct which contains an array of lookup entries. Each
>> entry contains the device name and an additional, optional identifier
>> string.
>>
>> Drivers can register a set of reset lines using this lookup table and
>> concerned devices can access them using the regular reset_control API.
>>
>> This new function is only called as a fallback in case the of_node
>> field is NULL and doesn't change anything for current users.
>>
>> Tested with a dummy reset driver with several lookup entries.
>>
>> An example lookup table can look like this:
>>
>> static const struct reset_lookup foobar_reset_lookup[] = {
>> [FOO_RESET] = { .dev = "foo", .id = "foo_id" },
>> [BAR_RESET] = { .dev = "bar", .id = NULL },
>> { }
>> };
>>
>> where FOO_RESET and BAR_RESET will correspond with the id parameters
>> of reset callbacks.
>
>> +static struct reset_control *
>> +__reset_control_get_from_lookup(struct device *dev, const char *id,
>> + bool shared, bool optional)
>> +{
>> + struct reset_controller_dev *rcdev;
>> + const char *dev_id = dev_name(dev);
>> + struct reset_control *rstc = NULL;
>> + const struct reset_lookup *lookup;
>> + int index;
>> +
>> + mutex_lock(&reset_list_mutex);
>> +
>> + list_for_each_entry(rcdev, &reset_controller_list, list) {
>> + if (!rcdev->lookup)
>> + continue;
>> +
>> + lookup = rcdev->lookup;
>
>> + for (index = 0; lookup->dev; index++, lookup++) {
>> + if (strcmp(dev_id, lookup->dev))
>> + continue;
>> +
>> + if ((!id && !lookup->id) ||
>> + (id && lookup->id && !strcmp(id, lookup->id))) {
>> + rstc = __reset_control_get_internal(rcdev,
>> + index,
>> shared);
>> + break;
>> + }
>
> Wouldn't be slightly more readable
>
> if (id && lookup->id) {
> if (strcmp(id, lookup->id))
> continue;
> } else if (id || lookup->id) {
> continue;
> }
>
> rstc = __reset_control_get_internal(rcdev, index, shared);
> break;
>
You'd get less indentations, yes but I wanted to emphasize the
condition on which we want to stop in this line.
>> + }
>> + }
>> +
>> + mutex_unlock(&reset_list_mutex);
>> +
>
>> + if (!rstc)
>> + return optional ? NULL : ERR_PTR(-ENOENT);
>
> Isn't simpler
>
> if (!optional && !rstc) // or other way around, depending which might
> be more offten
> return ERR_PTR(...);
>
IMO it's just a matter of taste.
Thanks,
Bartosz
Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg
On Wed, Feb 14, 2018 at 12:20 AM, Shakeel Butt wrote: > On Tue, Feb 13, 2018 at 1:54 PM, Amir Goldstein wrote: >> On Tue, Feb 13, 2018 at 11:10 PM, Shakeel Butt wrote: [...] The question is, do we need the user to also explicitly opt-in for Q_OVERFLOW on ENOMEM with FAN_Q_ERR mark mask? Should these 2 new APIs be coupled or independent? >>> >>> Are there any error which are not related to queue overflows? I see >>> the mention of ENODEV and EOVERFLOW in the discussion. If there are >>> such errors and might be interesting to the listener then we should >>> have 2 independent APIs. >>> >> >> These are indeed 2 different use cases. >> A Q_OVERFLOW event is only expected one of ENOMEM or >> EOVERFLOW in event->fd, but other events (like open of special device >> file) can have ENODEV in event->fd. >> >> But I am not convinced that those require 2 independent APIs. >> Specifying FAN_Q_ERR means that the user expects to reads errors >> from event->fd. >> > > Can you please explain what you mean by 2 independent APIs? I thought > "no independent APIs" means FAN_Q_ERR can only be used with > FAN_Q_OVERFLOW and without FAN_Q_OVERFLOW, FAN_Q_ERR is ignored. Is > that right or I misunderstood? > What I initially meant to say was, we actually consider several behavior changes: 1. Charge event allocations to memcg of listener 2. Queue a Q_OVERFLOW event on ENOMEM of event allocation 3. Report the error to user on metadata->fd (instead of FAN_NOFD) 4. Allow non Q_OVERFLOW event to have negative metadata->fd. #3 is applicable both to Q_OVERFLOW event and other events that can't provide and open file descriptor for some reason (i.e. ENODEV). #1 and #2 could be independent, but they both make sense together. When enabling #1 user increases the chance of ENOMEM and therefore #2 is desired. So if we are going to let distro/admin/programmer to opt-in for what we believe to be a "change of behavior for the best", then we could consider that opting-in for #1 will also imply opting-in for #2 and #3 (as the means to report Q_OVERFLOW due to ENOMEM). I guess we will need to allow user to opt-in to #4 and #3 by FAN_Q_ERR mask flag to cover the ENODEV case independently from opting-in to charging memcg. How was I doing in the balance of adding clarity vs. adding confusion? Thanks, Amir.
[PATCH] srcu: Fix incorrect condition in srcu_funnel_exp_start()
We should've kept sp->srcu_gp_seq_needed_exp the furthest. But it probably fails because of the incorrect condition. Fix it. Signed-off-by: Byungchul Park --- kernel/rcu/srcutree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index d5cea81..44bc0fa 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -626,7 +626,7 @@ static void srcu_funnel_exp_start(struct srcu_struct *sp, struct srcu_node *snp, spin_unlock_irqrestore_rcu_node(snp, flags); } spin_lock_irqsave_rcu_node(sp, flags); - if (!ULONG_CMP_LT(sp->srcu_gp_seq_needed_exp, s)) + if (ULONG_CMP_LT(sp->srcu_gp_seq_needed_exp, s)) sp->srcu_gp_seq_needed_exp = s; spin_unlock_irqrestore_rcu_node(sp, flags); } -- 1.9.1
Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME
On Wed, Feb 14, 2018 at 08:30:20PM +1300, Kai Huang wrote: > On Tue, 2018-02-13 at 22:57 -0600, Tom Lendacky wrote: > > On 2/13/2018 10:21 PM, Kirill A. Shutemov wrote: > > > On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: > > > > On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > > > > > AMD SME claims one bit from physical address to indicate > > > > > whether the > > > > > page is encrypted or not. To achieve that we clear out the bit > > > > > from > > > > > __PHYSICAL_MASK. > > > > > > > > I was actually working on a suggestion by Linus to use one of the > > > > software > > > > page table bits to indicate encryption and translate that to the > > > > hardware > > > > bit when writing the actual page table entry. With that, > > > > __PHYSICAL_MASK > > > > would go back to its original definition. > > > > > > But you would need to mask it on reading of pfn from page table > > > entry, > > > right? I expect it to have more overhead than this one. > > > > When reading back an entry it would translate the hardware bit > > position > > back to the software bit position. The suggestion for changing it > > was > > to make _PAGE_ENC a constant and not tied to the sme_me_mask. But is it really constant? I thought it's enumerated at boot-time. Can we step onto a problem for future AMD CPUs? In case of MKTME the bits we need to clear are not constant. Depends on CPU and BIOS settings. By making _PAGE_ENC constant we would effectively lower maximum physical address space the kernel can handle, regardless if the system has SME enabled. I can imagine some people wouldn't be happy about this. And I think it would collide with 5-level paging. I would leave it as variable for now and look on this later once we would have infrastructure to patch constants in kernel text. -- Kirill A. Shutemov
[RESEND PATCH net-next] r8169: add module param for control of ASPM disable.
The patch is from Todd Broch .
ASPM has been disabled in this driver by default as its been
implicated in stability issues on at least one platform. This CL adds
a module parameter to allow control of ASPM disable. The default
value is to enable ASPM again as its provides signficant (200mW) power
savings on the platform I tested.
I make some modification that let this patch only for RTL8168G and later.
Signed-off-by: Chunhao Lin
---
drivers/net/ethernet/realtek/r8169.c | 73
1 file changed, 50 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 0bf7d17..87d3136 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -346,6 +346,7 @@ static const struct pci_device_id rtl8169_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl);
static int rx_buf_sz = 16383;
+static int aspm_disable = 0;
static int use_dac = -1;
static struct {
u32 msg_enable;
@@ -867,6 +868,8 @@ struct rtl8169_private {
MODULE_AUTHOR("Realtek and the Linux r8169 crew ");
MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
+module_param(aspm_disable, int, 0444);
+MODULE_PARM_DESC(aspm_disable, "Disable ASPM completely.");
module_param(use_dac, int, 0);
MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
module_param_named(debug, debug.msg_enable, int, 0);
@@ -5878,6 +5881,20 @@ static void rtl_pcie_state_l2l3_enable(struct
rtl8169_private *tp, bool enable)
RTL_W8(Config3, data);
}
+static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp,
+ bool enable)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ if (enable) {
+ RTL_W8(Config2, RTL_R8(Config2) | ClkReqEn);
+ RTL_W8(Config5, RTL_R8(Config5) | ASPM_en);
+ } else {
+ RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
+ RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ }
+}
+
#define R8168_CPCMD_QUIRK_MASK (\
EnableBist | \
Mac_dbgo_oe | \
@@ -6264,7 +6281,6 @@ static void rtl_hw_start_8168g(struct rtl8169_private *tp)
static void rtl_hw_start_8168g_1(struct rtl8169_private *tp)
{
- void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8168g_1[] = {
{ 0x00, 0x, 0x0008 },
{ 0x0c, 0x37d0, 0x0820 },
@@ -6275,14 +6291,14 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private
*tp)
rtl_hw_start_8168g(tp);
/* disable aspm and clock request before access ephy */
- RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
- RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168g_1, ARRAY_SIZE(e_info_8168g_1));
+ if (!aspm_disable)
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
{
- void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8168g_2[] = {
{ 0x00, 0x, 0x0008 },
{ 0x0c, 0x3df0, 0x0200 },
@@ -6293,14 +6309,14 @@ static void rtl_hw_start_8168g_2(struct rtl8169_private
*tp)
rtl_hw_start_8168g(tp);
/* disable aspm and clock request before access ephy */
- RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
- RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168g_2, ARRAY_SIZE(e_info_8168g_2));
+ if (!aspm_disable)
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
{
- void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8411_2[] = {
{ 0x00, 0x, 0x0008 },
{ 0x0c, 0x3df0, 0x0200 },
@@ -6312,9 +6328,10 @@ static void rtl_hw_start_8411_2(struct rtl8169_private
*tp)
rtl_hw_start_8168g(tp);
/* disable aspm and clock request before access ephy */
- RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
- RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8411_2, ARRAY_SIZE(e_info_8411_2));
+ if (!aspm_disable)
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
@@ -6333,8 +6350,7 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private
*tp)
};
/* disable aspm and clock request before access ephy */
- RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
- RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168h_1, ARRAY_SIZE(e
[PATCH] srcu: Remove dead code in srcu_gp_end()
Of course, compilers will optimize out a dead code. Anyway, remove
any dead code for better readibility.
Signed-off-by: Byungchul Park
---
kernel/rcu/srcutree.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 44bc0fa..829453b 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -531,7 +531,6 @@ static void srcu_gp_end(struct srcu_struct *sp)
unsigned long flags;
unsigned long gpseq;
int idx;
- int idxnext;
unsigned long mask;
struct srcu_data *sdp;
struct srcu_node *snp;
@@ -555,7 +554,6 @@ static void srcu_gp_end(struct srcu_struct *sp)
/* Initiate callback invocation as needed. */
idx = rcu_seq_ctr(gpseq) % ARRAY_SIZE(snp->srcu_have_cbs);
- idxnext = (idx + 1) % ARRAY_SIZE(snp->srcu_have_cbs);
rcu_for_each_node_breadth_first(sp, snp) {
spin_lock_irq_rcu_node(snp);
cbs = false;
--
1.9.1
Re: [PATCH 2/2] vfio: platform: Add generic DT reset support
Hi Geert,
On 13/02/18 17:36, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal reset controller,
> and can be reset in a generic way. Hence add support to reset such
> devices using the reset controller subsystem, provided the reset
> hierarchy is described correctly in DT using the "resets" property.
I first acknowledge I am not familiar with what those reset controllers
do in practice. My fear is that we may rely on generic SW pieces that
may not be adapted to passthrough constraints. We must guarantee that
any DMA access attempted by the devices are stopped and any interrupts
gets stopped. Can we guarantee that the reset controller always induce
that? Otherwise we may leave the door opened to badly reset assigned
devices.
>
> Devices that require a more complex reset procedure can still
> provide a device-specific reset driver, as that takes precedence.
>
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op if reset controller support is disabled.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/vfio/platform/vfio_platform_common.c | 23 +--
> drivers/vfio/platform/vfio_platform_private.h | 1 +
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/platform/vfio_platform_common.c
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..5d1e48f96e423508 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -112,7 +113,13 @@ static bool vfio_platform_has_reset(struct
> vfio_platform_device *vdev)
> if (VFIO_PLATFORM_IS_ACPI(vdev))
> return vfio_platform_acpi_has_reset(vdev);
>
> - return vdev->of_reset ? true : false;
> + if (vdev->of_reset)
> + return true;
> +
> + if (!IS_ERR_OR_NULL(vdev->reset_control))
> + return true;
> +
> + return false;
> }
>
> static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
> @@ -127,8 +134,15 @@ static int vfio_platform_get_reset(struct
> vfio_platform_device *vdev)
> vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
> &vdev->reset_module);
> }
> + if (vdev->of_reset)
> + return 0;
> +
> + vdev->reset_control = __of_reset_control_get(vdev->device->of_node,
> + NULL, 0, false, false);
> + if (!IS_ERR(vdev->reset_control))
> + return 0;
>
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(vdev->reset_control);
> }
>
> static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> @@ -138,6 +152,8 @@ static void vfio_platform_put_reset(struct
> vfio_platform_device *vdev)
>
> if (vdev->of_reset)
> module_put(vdev->reset_module);
> +
if (vdev->reset_control) ?
reset_control_put seems to only check IS_ERR()
Thanks
Eric
> + reset_control_put(vdev->reset_control);
> }
>
> static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> @@ -217,6 +233,9 @@ static int vfio_platform_call_reset(struct
> vfio_platform_device *vdev,
> } else if (vdev->of_reset) {
> dev_info(vdev->device, "reset\n");
> return vdev->of_reset(vdev);
> + } else if (!IS_ERR_OR_NULL(vdev->reset_control)) {
> + dev_info(vdev->device, "reset\n");
> + return reset_control_reset(vdev->reset_control);
> }
>
> dev_warn(vdev->device, "no reset function found!\n");
> diff --git a/drivers/vfio/platform/vfio_platform_private.h
> b/drivers/vfio/platform/vfio_platform_private.h
> index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -60,6 +60,7 @@ struct vfio_platform_device {
> const char *compat;
> const char *acpihid;
> struct module *reset_module;
> + struct reset_control*reset_control;
> struct device *device;
>
> /*
>
Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
On Wed, Feb 14, 2018 at 08:33:39AM +, Yatsina, Marina wrote: > I hope this will give this issue a push forward and we will find a > solution that will not prevent llvm from compiling linux kernel. That solution is asm-goto. We (linux kernel) are not going to support something like it. It's going to be asm-goto or bust. The feature is over 7 years old by now, deal with it. If you ever get to the point where it makes sense to build a kernel with LLVM, then you can bike-shed with the GCC team on new features, until then tough luck.
Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
On Wed, Feb 14, 2018 at 08:41:43AM +, Chandler Carruth wrote: > Marina, Kees: > > I think the combination of LKML and the LLVM developer's list is probably > too large a set of folks to have a (somewhat) lengthy exploration of > options and how to go about this and find a good path forward. As one of the original authors of the jump-label implementation I'm saying there are no options. We're not going to do a second parallel implementation. If you want to build the kernel, you get to implement asm-goto, teh end.
Re: [RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling
On 02/09/2018 11:05 PM, Rohit Jain wrote:
On 02/09/2018 07:46 AM, Dietmar Eggemann wrote:
On 02/09/2018 01:53 PM, Peter Zijlstra wrote:
On Mon, Jan 29, 2018 at 03:27:09PM -0800, Rohit Jain wrote:
[...]
@@ -6173,8 +6183,15 @@ static int select_idle_cpu(struct task_struct
*p, struct sched_domain *sd, int t
return -1;
if (!cpumask_test_cpu(cpu, &p->cpus_allowed))
continue;
+ if (idle_cpu(cpu)) {
+ if (full_capacity(cpu)) {
+ best_cpu = cpu;
+ break;
+ } else if (capacity_of(cpu) > best_cap) {
+ best_cap = capacity_of(cpu);
+ best_cpu = cpu;
+ }
+ }
No need for the else. And you'll note you're once again inconsistent
with your previous self.
But here I worry about big.little a wee bit. I think we're allowed big
and little cores on the same L3 these days, and you can't directly
compare capacity between them.
Morten / Dietmar, any comments?
Yes, for DynamIQ (big.little successor) systems, those cpus can have
different capacity_orig_of() values already.
OK, given that there are asymmetric capacities in L3 cores, we would
probably have something like the below(?) in select_idle_cpu:
if (!cpumask_test_cpu(cpu, &p->cpus_allowed))
continue;
+ if (idle_cpu(cpu) && !reduced_capacity(cpu))
+ break;
Only returning the first idle cpu w/o reduced capacity will definitely
work better here on future DynamIQ systems than trying to find the
best_cap cpu by taking capacity_of() into consideration.
Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers
Hi Tomasz, On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa wrote: > On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam > wrote: >> Hi Tomasz, >> >> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote: >>> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote: On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote: > On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote: >> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: >>> Hi Vivek, >>> >>> Thanks for the patch. Please see my comments inline. >>> >>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam >>> wrote: While handling the concerned iommu, there should not be a need to power control the drm devices from iommu interface. If these drm devices need to be powered around this time, the respective drivers should take care of this. Replace the pm_runtime_get/put_sync() with pm_runtime_get/put_suppliers() calls, to power-up the connected iommu through the device link interface. In case the device link is not setup these get/put_suppliers() calls will be a no-op, and the iommu driver should take care of powering on its devices accordingly. Signed-off-by: Vivek Gautam --- drivers/gpu/drm/msm/msm_iommu.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c index b23d33622f37..1ab629bbee69 100644 --- a/drivers/gpu/drm/msm/msm_iommu.c +++ b/drivers/gpu/drm/msm/msm_iommu.c @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char * const *names, struct msm_iommu *iommu = to_msm_iommu(mmu); int ret; - pm_runtime_get_sync(mmu->dev); + pm_runtime_get_suppliers(mmu->dev); ret = iommu_attach_device(iommu->domain, mmu->dev); - pm_runtime_put_sync(mmu->dev); + pm_runtime_put_suppliers(mmu->dev); >>> >>> For me, it looks like a wrong place to handle runtime PM of IOMMU >>> here. iommu_attach_device() calls into IOMMU driver's attach_device() >>> callback and that's where necessary runtime PM gets should happen, if >>> any. In other words, driver A (MSM DRM driver) shouldn't be dealing >>> with power state of device controlled by driver B (ARM SMMU). >> >> Note that we end up having to do the same, because of iommu_unmap() >> while DRM driver is powered off.. it might be cleaner if it was all >> self contained in the iommu driver, but that would make it so other >> drivers couldn't call iommu_unmap() from an irq handler, which is >> apparently something that some of them want to do.. > > I'd assume that runtime PM status is already guaranteed to be active > when the IRQ handler is running, by some other means (e.g. > pm_runtime_get_sync() called earlier, when queuing some work to the > hardware). Otherwise, I'm not sure how a powered down device could > trigger an IRQ. > > So, if the master device power is already on, suppliers should be > powered on as well, thanks to device links. > umm, that is kindof the inverse of the problem.. the problem is things like gpu driver (and v4l2 drivers that import dma-buf's, afaict).. they will potentially call iommu->unmap() when device is not active (due to userspace or things beyond the control of the driver).. so *they* would want iommu to do pm get/put calls. >>> >>> Which is fine and which is actually already done by one of the patches >>> in this series, not for map/unmap, but probe, add_device, >>> remove_device. Having parts of the API doing it inside the callback >>> and other parts outside sounds at least inconsistent. >>> But other drivers trying to unmap from irq ctx would not. Which is the contradictory requirement that lead to the idea of iommu user powering up iommu for unmap. >>> >>> Sorry, maybe I wasn't clear. My last message was supposed to show that >>> it's not contradictory at all, because "other drivers trying to unmap >>> from irq ctx" would already have called pm_runtime_get_*() earlier >>> from a non-irq ctx, which would have also done the same on all the >>> linked suppliers, including the IOMMU. The ultimate result would be >>> that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync() >>> would do nothing besides incrementing the reference count. >> >> The entire point was to avoid the slowpath that pm_runtime_get/put_sync() >> would add in map/unmap. It would not be correct to add a slowpath in irq_ctx >> for taking care of non-irq_ctx and for the situations where master is already >> powered-off. > > Correct me if I'm wrong, but I believe that with what I'm proposing > there wouldn't
Re: [PATCH v3 01/25] dt-bindings: soc: qcom: Add bindings for APR bus
Thanks for the review,
On 13/02/18 23:12, Rob Herring wrote:
On Tue, Feb 13, 2018 at 04:58:13PM +, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
bus driver. This bus is used for communicating with DSP which provides
audio and various other services to cpu.
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/soc/qcom/qcom,apr.txt | 83 ++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
new file mode 100644
index ..1b95fbfed348
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
@@ -0,0 +1,83 @@
+Qualcomm APR (Asynchronous Packet Router) binding
+
+This binding describes the Qualcomm APR. APR is a IPC protocol for
+communication between Application processor and QDSP. APR is mainly
+used for audio/voice services on the QDSP.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,apr-v", example "qcom,apr-v2"
+
+- qcom,apr-dest-domain-id
+ Usage: required
+ Value type:
+ Definition: Destination processor ID.
+ Possible values are :
+ 1 - APR simulator
+ 2 - PC
+ 3 - MODEM
+ 4 - ADSP
+ 5 - APPS
+ 6 - MODEM2
+ 7 - APPS2
+
+= APR SERVICES
+Each subnode of the APR node can represent service tied to this apr. The name
+of the nodes are not important. The properties of these nodes are defined
+by the individual bindings for the specific service
+- but must contain the following property:
+
...
+= APR DEVICES:
+Each subnode of the APR node can represent devices tied to this apr, like
+sound-card. The properties of these nodes are defined by the individual
+bindings for the specific device.
It's not a good design generally to mix different types of nodes at one
level.
I agree, may be I can split the services and devices into different
subnodes like below, which should avoid mixing different types of nodes.
Does this sound good to you?
apr {
compatible = "qcom,apr-v2";
qcom,smd-channels = "apr_audio_svc";
qcom,apr-dest-domain-id = ;
apr-services {
q6core {
qcom,apr-svc-name = "CORE";
qcom,apr-svc-id = ;
compatible = "qcom,q6core";
};
q6afe: q6afe {
compatible = "qcom,q6afe";
qcom,apr-svc-name = "AFE";
qcom,apr-svc-id = ;
#sound-dai-cells = <1>;
};
q6asm: q6asm {
compatible = "qcom,q6asm";
qcom,apr-svc-name = "ASM";
qcom,apr-svc-id = ;
#sound-dai-cells = <1>;
};
q6adm: q6adm {
compatible = "qcom,q6adm";
qcom,apr-svc-name = "ADM";
qcom,apr-svc-id = ;
#sound-dai-cells = <0>;
};
};
apr-devices {
audio {
compatible = "qcom,msm8996-snd-card";
...
};
};
};
+
+= EXAMPLE
+The following example represents a QDSP based sound card on a MSM8996 device
+which uses apr as communication between Apps and QDSP.
+
+ apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,apr-dest-domain-id = ;
+
+ q6core {
+ compatible = "qcom,q6core";
+ qcom,apr-svc-name = "CORE";
+ qcom,apr-svc-id = ;
+ };
+
+ q6afe {
+ compatible = "qcom,q6afe";
+ qcom,apr-svc-name = "AFE";
+ qcom,apr-svc-id = ;
+ };
+
+ audio {
+ compatible = "qcom,msm8996-snd-card";
+ ...
+ };
+ };
--
2.15.1
Re: [PATCH v2 1/3] Documentation: bindings: add dt documentation for cdn DP controller
Am Dienstag, 13. Februar 2018, 15:35:47 CET schrieb Enric Balletbo i Serra: > From: Chris Zhong > > This patch adds a binding that describes the cdn DP controller for > rk3399. > > Signed-off-by: Chris Zhong > Acked-by: Rob Herring > Signed-off-by: Enric Balletbo i Serra > --- > Changes since v1: > - Add the cdn-dp bindings as requested by Heiko > - The bindingis were sent already and acked by Rob but for some reason > never landed. So as these series are related I incorporated this > patch again [1]. > > [1] https://patchwork.kernel.org/patch/9278077/ applied for 4.17 (into drm-misc). The driver uses 3 additional resets now, which I just added to the reset-names. Heiko
Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig
On Tue 13-02-18 13:27:30, Kees Cook wrote:
> On Tue, Feb 13, 2018 at 2:32 AM, Michal Hocko wrote:
> > On Tue 13-02-18 21:16:55, Michael Ellerman wrote:
> >> Kees Cook writes:
> >>
> >> > On Mon, Feb 12, 2018 at 7:25 PM, Michael Ellerman
> >> > wrote:
> >> >> Michal Hocko writes:
> >> >>> Hi,
> >> >>> my build test machinery chokes on samples/seccomp when cross compiling
> >> >>> s390 and ppc64 allyesconfig. This has been the case for quite some
> >> >>> time already but I never found time to look at the problem and report
> >> >>> it. It seems this is not new issue and similar thing happend for
> >> >>> MIPS e9107f88c985 ("samples/seccomp/Makefile: do not build tests if
> >> >>> cross-compiling for MIPS").
> >> >>>
> >> >>> The build logs are attached.
> >> >>>
> >> >>> What is the best way around this? Should we simply skip compilation on
> >> >>> cross compile or is actually anybody relying on that? Or should I
> >> >>> simply
> >> >>> disable it for s390 and ppc?
> >> >>
> >> >> The whole thing seems very confused. It's not building for the target,
> >> >> it's building for the host, ie. the Makefile sets hostprogs-m and
> >> >> HOSTCFLAGS etc.
> >> >>
> >> >> So it can't possibly work with cross compiling as it's currently
> >> >> written.
> >> >>
> >> >> Either the Makefile needs some serious work to properly support cross
> >> >> compiling or it should just be disabled when cross compiling.
> >> >
> >> > Hrm, yeah, the goal was to entirely disable cross compiling, but I
> >> > guess we didn't hit it with a hard enough hammer. :)
> >>
> >> Do you know why it is written that way? Why doesn't it just try to cross
> >> compile like normal code?
> >
> > No idea, sorry. All I know about this code is that it breaks my build
> > testing.
>
> IIRC, one of the problems is with build ordering problems: the kernel
> headers used by the samples aren't available when cross compiling.
>
> I'm happy to kill it entirely with Michal's patch, though. Feel free
> to carry in your tree!
>
> Acked-by: Kees Cook
OK, so let's try to nuke it. How should I route this patch?
>From 8d8457e96296538508e478f598d1c8b3406a8626 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 14 Feb 2018 10:15:12 +0100
Subject: [PATCH] samples/seccomp: do not compile when cross compiled
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
samples/seccomp relies on the host setting which is not suitable for
crosscompilation and it actually fails when crosscompiling s390 and
powerpc all{yes,mod}config on x86_64 with
samples/seccomp/bpf-helper.h:135:2: error: #error __BITS_PER_LONG value
unusable.
#error __BITS_PER_LONG value unusable.
^
In file included from samples/seccomp/bpf-fancy.c:13:0:
samples/seccomp/bpf-fancy.c: In function ‘main’:
samples/seccomp/bpf-fancy.c:38:11: error: ‘__NR_exit’ undeclared (first use in
this function)
SYSCALL(__NR_exit, ALLOW),
and many others. I am doing these for compile testing and it's been
quite useful to catch issues. Crosscompiling sample code on the other
hand doesn't seem all that important so it seems like the easiest way to
simply disable samples/seccomp when crosscompiling.
Fixing this properly is not that easy as Kees explains:
: IIRC, one of the problems is with build ordering problems: the kernel
: headers used by the samples aren't available when cross compiling.
Acked-by: Kees Cook
Signed-off-by: Michal Hocko
---
samples/seccomp/Makefile | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index 0e349b80686e..ba942e3ead89 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+ifndef CROSS_COMPILE
hostprogs-$(CONFIG_SAMPLE_SECCOMP) := bpf-fancy dropper bpf-direct
HOSTCFLAGS_bpf-fancy.o += -I$(objtree)/usr/include
@@ -16,7 +17,6 @@ HOSTCFLAGS_bpf-direct.o += -idirafter $(objtree)/include
bpf-direct-objs := bpf-direct.o
# Try to match the kernel target.
-ifndef CROSS_COMPILE
ifndef CONFIG_64BIT
# s390 has -m31 flag to build 31 bit binaries
@@ -35,12 +35,4 @@ HOSTLOADLIBES_bpf-fancy += $(MFLAG)
HOSTLOADLIBES_dropper += $(MFLAG)
endif
always := $(hostprogs-m)
-else
-# MIPS system calls are defined based on the -mabi that is passed
-# to the toolchain which may or may not be a valid option
-# for the host toolchain. So disable tests if target architecture
-# is MIPS but the host isn't.
-ifndef CONFIG_MIPS
-always := $(hostprogs-m)
-endif
endif
--
2.15.1
--
Michal Hocko
SUSE Labs
Re: [PATCH v13 7/9] ACPI: Translate the I/O range of non-MMIO devices before scanning
On Tue, Feb 13, 2018 at 6:45 PM, John Garry wrote:
> On some platforms (such as arm64-based hip06/hip07), access to legacy
> ISA/LPC devices through access IO space is required, similar to x86
> platforms. As the I/O for these devices are not memory mapped like
> PCI/PCIE MMIO host bridges, they require special low-level device
> operations through some host to generate IO accesses, i.e. a non-
> transparent bridge.
>
> Through the logical PIO framework, hosts are able to register address
> ranges in the logical PIO space for IO accesses. For hosts which require
> a LLDD to generate the IO accesses, through the logical PIO framework
> the host also registers accessors as a backend to generate the physical
> bus transactions for IO space accesses (called indirect IO).
>
> When describing the indirect IO child device in APCI tables, the IO
> resource is the host-specific address for the child (generally a
> bus address).
> An example is as follows:
> Device (LPC0) {
> Name (_HID, "HISI0191") // HiSi LPC
> Name (_CRS, ResourceTemplate () {
> Memory32Fixed (ReadWrite, 0xa01b, 0x1000)
> })
> }
>
> Device (LPC0.IPMI) {
> Name (_HID, "IPI0001")
> Name (LORS, ResourceTemplate() {
> QWordIO (
> ResourceConsumer,
> MinNotFixed, // _MIF
> MaxNotFixed, // _MAF
> PosDecode,
> EntireRange,
> 0x0, // _GRA
> 0xe4,// _MIN
> 0x3fff, // _MAX
> 0x0, // _TRA
> 0x04,// _LEN
> , ,
> BTIO
> )
> })
>
> Since the IO resource for the child is a host-specific address,
> special translation are required to retrieve the logical PIO address
> for that child.
>
> To overcome the problem of associating this logical PIO address
> with the child device, a scan handler is added to scan the ACPI
> namespace for known indirect IO hosts. This scan handler creates an
> MFD per child with the translated logical PIO address as it's IO
> resource, as a substitute for the normal platform device which ACPI
> would create during device enumeration.
>
> Signed-off-by: John Garry
> Signed-off-by: Zhichang Yuan
> Signed-off-by: Gabriele Paoloni
Just a few minor nits below.
> ---
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/acpi_indirectio.c | 250
> +++
> drivers/acpi/internal.h | 5 +
> drivers/acpi/scan.c | 1 +
> 4 files changed, 257 insertions(+)
> create mode 100644 drivers/acpi/arm64/acpi_indirectio.c
>
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> index 1017def..f4a7f46 100644
> --- a/drivers/acpi/arm64/Makefile
> +++ b/drivers/acpi/arm64/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_ACPI_IORT)+= iort.o
> obj-$(CONFIG_ACPI_GTDT)+= gtdt.o
> +obj-$(CONFIG_INDIRECT_PIO) += acpi_indirectio.o
> diff --git a/drivers/acpi/arm64/acpi_indirectio.c
> b/drivers/acpi/arm64/acpi_indirectio.c
> new file mode 100644
> index 000..51a1b92
> --- /dev/null
> +++ b/drivers/acpi/arm64/acpi_indirectio.c
> @@ -0,0 +1,250 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 HiSilicon Limited, All Rights Reserved.
> + * Author: Gabriele Paoloni
> + * Author: Zhichang Yuan
> + * Author: John Garry
> + *
> + * This file implements functunality to scan the ACPI namespace and config
> + * devices under "indirect IO" hosts. An "indirect IO" host allows child
> + * devices to use logical IO accesses when the host, itself, does not provide
> + * a transparent bridge. The device setup creates a per-child MFD with a
> + * logical port IO resource.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +ACPI_MODULE_NAME("indirect IO");
> +
> +#define ACPI_INDIRECT_IO_NAME_LEN 255
> +
> +struct acpi_indirect_io_mfd_cell {
> + struct mfd_cell_acpi_match acpi_match;
> + char name[ACPI_INDIRECT_IO_NAME_LEN];
> + char pnpid[ACPI_INDIRECT_IO_NAME_LEN];
> +};
> +
> +static int acpi_indirect_io_xlat_res(struct acpi_device *adev,
> +struct acpi_device *host,
> +struct resource *res)
> +{
> + unsigned long sys_port;
> + resource_size_t len = res->end - res->start;
> +
> + sys_port = logic_pio_trans_hwaddr(&host->fwnode, res->start, len);
> + if (sys_port == -1UL)
> + return -EFAULT;
> +
> + res->start = sys_port;
> + res->end = sys_port + len;
> +
> + return 0;
> +}
> +
> +/*
> + * acpi_indirect_io_set_res - set the resources for a child device
> + * (MFD) of an "indirect IO" host.
The above should fit into a single line.
I'd make it something like "acpi_indirect_io_set_res - set "indirect
IO" host child (MFD) resources" and it already is explained in the
comment below.
> + * @child: the device node to be updated the I/O resource
> + * @hostdev: the
Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers
On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam wrote: > Hi Tomasz, > > On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa wrote: >> On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam >> wrote: >>> Hi Tomasz, >>> >>> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote: On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote: > On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote: >> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote: >>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: Hi Vivek, Thanks for the patch. Please see my comments inline. On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam wrote: > While handling the concerned iommu, there should not be a > need to power control the drm devices from iommu interface. > If these drm devices need to be powered around this time, > the respective drivers should take care of this. > > Replace the pm_runtime_get/put_sync() with > pm_runtime_get/put_suppliers() calls, to power-up > the connected iommu through the device link interface. > In case the device link is not setup these get/put_suppliers() > calls will be a no-op, and the iommu driver should take care of > powering on its devices accordingly. > > Signed-off-by: Vivek Gautam > --- > drivers/gpu/drm/msm/msm_iommu.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/msm/msm_iommu.c > b/drivers/gpu/drm/msm/msm_iommu.c > index b23d33622f37..1ab629bbee69 100644 > --- a/drivers/gpu/drm/msm/msm_iommu.c > +++ b/drivers/gpu/drm/msm/msm_iommu.c > @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, > const char * const *names, > struct msm_iommu *iommu = to_msm_iommu(mmu); > int ret; > > - pm_runtime_get_sync(mmu->dev); > + pm_runtime_get_suppliers(mmu->dev); > ret = iommu_attach_device(iommu->domain, mmu->dev); > - pm_runtime_put_sync(mmu->dev); > + pm_runtime_put_suppliers(mmu->dev); For me, it looks like a wrong place to handle runtime PM of IOMMU here. iommu_attach_device() calls into IOMMU driver's attach_device() callback and that's where necessary runtime PM gets should happen, if any. In other words, driver A (MSM DRM driver) shouldn't be dealing with power state of device controlled by driver B (ARM SMMU). >>> >>> Note that we end up having to do the same, because of iommu_unmap() >>> while DRM driver is powered off.. it might be cleaner if it was all >>> self contained in the iommu driver, but that would make it so other >>> drivers couldn't call iommu_unmap() from an irq handler, which is >>> apparently something that some of them want to do.. >> >> I'd assume that runtime PM status is already guaranteed to be active >> when the IRQ handler is running, by some other means (e.g. >> pm_runtime_get_sync() called earlier, when queuing some work to the >> hardware). Otherwise, I'm not sure how a powered down device could >> trigger an IRQ. >> >> So, if the master device power is already on, suppliers should be >> powered on as well, thanks to device links. >> > > umm, that is kindof the inverse of the problem.. the problem is > things like gpu driver (and v4l2 drivers that import dma-buf's, > afaict).. they will potentially call iommu->unmap() when device is not > active (due to userspace or things beyond the control of the driver).. > so *they* would want iommu to do pm get/put calls. Which is fine and which is actually already done by one of the patches in this series, not for map/unmap, but probe, add_device, remove_device. Having parts of the API doing it inside the callback and other parts outside sounds at least inconsistent. > But other drivers > trying to unmap from irq ctx would not. Which is the contradictory > requirement that lead to the idea of iommu user powering up iommu for > unmap. Sorry, maybe I wasn't clear. My last message was supposed to show that it's not contradictory at all, because "other drivers trying to unmap from irq ctx" would already have called pm_runtime_get_*() earlier from a non-irq ctx, which would have also done the same on all the linked suppliers, including the IOMMU. The ultimate result would be that the map/unmap() of the IOMMU driver calling pm_runtime_get_sync() would do nothing besides incrementing the reference count. >>> >>> The entire point was to avoid the slowpath that pm_runtime_get/put_sync() >>> would add in map/unmap. It would not be correct to add a slowpath in irq_ctx >>> for taking care of non-irq
Re: [PATCH v3 3/3] arm64: dts: sdm845: Add serial console support
On 02/14/2018 06:02 AM, Doug Anderson wrote:
> Hi,
>
> On Sun, Feb 11, 2018 at 10:28 PM, Rajendra Nayak
> wrote:
>> Add the qup uart node and geni se instance needed to
>> support the serial console on the MTP.
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 34
>> arch/arm64/boot/dts/qcom/sdm845.dtsi| 39
>> +
>> 2 files changed, 73 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> index 617c7bb25fb1..9eab2b815e0d 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> @@ -10,4 +10,38 @@
>> / {
>> model = "Qualcomm Technologies, Inc. SDM845 MTP";
>> compatible = "qcom,sdm845-mtp";
>> +
>> + aliases {
>> + serial0 = &qup_uart2;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0";
>> + };
>> +};
>> +
>> +&soc {
>> + geni-se@ac {
>> + serial@a84000 {
>> + status = "okay";
>> + };
>> + };
>
> If others at QC have already decided that they like the style above
> then it's OK with me, but I'd prefer instead (at the top level):
>
> &qup_uart2 {
> status = "okay";
> };
>
> ...then you don't need to replicate all the hierarchy.
>
>> + pinctrl@340 {
>
> Similar here. This could be:
>
> &qup_uart2_default {
> pinconf {
> ...
> }
> };
>
> If you're upset about things being in a "random" order at the top
> level, you can still create commented sections in the "dts" file to
> organize things, but the above means that you don't end up tabbed in
> several levels of indentation for no reason.
Yes, I kept it this way mainly because of Bjorn's concerns about things
being in random order.
Bjorn/Andy, any thoughts?
>
>
>> + qup-uart2-default {
>> + pinconf {
>> + pins = "gpio4", "gpio5";
>> + drive-strength = <2>;
>> + bias-disable;
>
> Possibly you'd want some sort of pull on the "receive" pin unless
> you're guaranteed that on this board that the other side will always
> be driving the pin. As far as I can tell this UART goes to a debug
> connector. If that debug connector is not populated this pin will be
> floating, no?
>
>
>> + };
>> + };
>> +
>> + qup-uart2-sleep {
>> + pinconf {
>> + pins = "gpio4", "gpio5";
>> + drive-strength = <2>;
>
> Does specifying the "drive-strength" in this case actually do anything
> useful? If not can we leave it out?
>
>
>> + bias-disable;
>
> Feel free to ignore if I'm being ignorant, but I would have expected a
> "pull" of some sort to be turned on for the "transmit" pin when you're
> in sleep mode. Otherwise the line will be left floating which could
> generate noise to the other side, no? ...or is there some sort of
> external pull present on this board?
>
> Depending on the board you might also want a pull on the "receive" pin
> (assuming we wanted one in the "default" state--see above). With my
> extremely limited EE understanding I have the impression that
> transitions on a line can still cause power draw even if software
> isn't paying attention to them, so it's best to prevent them by adding
> a pull.
What you are suggesting seems to make sense, however, given I blindly
pulled these in from the internal kernels, I am looping in Karthik/Girish
if they have anything to chime in.
>
>
>> + };
>> + };
>> + };
>> };
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index 55a7e0b454e1..8cf8df25b06d 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -4,6 +4,7 @@
>> */
>>
>> #include
>> +#include
>>
>> / {
>> interrupt-parent = <&intc>;
>> @@ -193,6 +194,20 @@
>> #gpio-cells = <2>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> +
>> + qup_uart2_default: qup-uart2-default {
>> + pinmux {
>> + function = "qup9";
>> + pins = "gpio4", "gpio5";
>> + };
>> + };
>> +
>> + qup_uart2_sleep: qup-uart2-sleep {
>> + pinmux {
>> + function = "gpio";
>> + pins = "gpio4", "gpio5";
>> + };
>> + };
>> }
[PATCH] staging: typec: handle vendor defined part and modify drp toggling flow
From: ShuFanLee
Handle vendor defined behavior in tcpci_init and tcpci_irq.
More operations can be extended in tcpci_vendor_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the TCPM
writes to the COMMAND register to start DRP toggling.
DRP toggling flow is chagned as following:
- Write DRP = 0 & Rd/Rd
- Write DRP = 1
- Set LOOK4CONNECTION command
Signed-off-by: ShuFanLee
---
drivers/staging/typec/tcpci.c | 98 ---
drivers/staging/typec/tcpci.h | 15 +++
2 files changed, 97 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 9bd4412..b3a97b3 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -30,6 +30,7 @@ struct tcpci {
bool controls_vbus;
struct tcpc_dev tcpc;
+ struct tcpci_vendor_data *vdata;
};
static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
@@ -37,16 +38,29 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev
*tcpc)
return container_of(tcpc, struct tcpci, tcpc);
}
-static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
- u16 *val)
+int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16 *val)
{
return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
}
+EXPORT_SYMBOL_GPL(tcpci_read16);
-static int tcpci_write16(struct tcpci *tcpci, unsigned int reg, u16 val)
+int tcpci_write16(struct tcpci *tcpci, unsigned int reg, u16 val)
{
return regmap_raw_write(tcpci->regmap, reg, &val, sizeof(u16));
}
+EXPORT_SYMBOL_GPL(tcpci_write16);
+
+int tcpci_read8(struct tcpci *tcpci, unsigned int reg, u8 *val)
+{
+ return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u8));
+}
+EXPORT_SYMBOL_GPL(tcpci_read8);
+
+int tcpci_write8(struct tcpci *tcpci, unsigned int reg, u8 val)
+{
+ return regmap_raw_write(tcpci->regmap, reg, &val, sizeof(u8));
+}
+EXPORT_SYMBOL_GPL(tcpci_write8);
static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
{
@@ -98,8 +112,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum
typec_cc_status cc)
static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
enum typec_cc_status cc)
{
+ int ret;
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
- unsigned int reg = TCPC_ROLE_CTRL_DRP;
+ unsigned int reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+ (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
switch (cc) {
default:
@@ -116,8 +132,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
TCPC_ROLE_CTRL_RP_VAL_SHIFT);
break;
}
-
- return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+ ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+ if (ret < 0)
+ return ret;
+ usleep_range(500, 1000);
+ reg |= TCPC_ROLE_CTRL_DRP;
+ ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+ if (ret < 0)
+ return ret;
+ ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+ TCPC_CMD_LOOK4CONNECTION);
+ if (ret < 0)
+ return ret;
+ return 0;
}
static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
@@ -323,6 +350,15 @@ static int tcpci_init(struct tcpc_dev *tcpc)
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
+ /* Handle vendor init */
+ if (tcpci->vdata) {
+ if (tcpci->vdata->init) {
+ ret = (*tcpci->vdata->init)(tcpci, tcpci->vdata);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
/* Clear all events */
ret = tcpci_write16(tcpci, TCPC_ALERT, 0x);
if (ret < 0)
@@ -351,6 +387,13 @@ static irqreturn_t tcpci_irq(int irq, void *dev_id)
tcpci_read16(tcpci, TCPC_ALERT, &status);
+ /* Handle vendor defined interrupt */
+ if (tcpci->vdata) {
+ if (tcpci->vdata->irq_handler)
+ (*tcpci->vdata->irq_handler)(tcpci, tcpci->vdata,
+&status);
+ }
+
/*
* Clear alert status for everything except RX_STATUS, which shouldn't
* be cleared until we have successfully retrieved message.
@@ -417,7 +460,7 @@ static irqreturn_t tcpci_irq(int irq, void *dev_id)
.reg_bits = 8,
.val_bits = 8,
- .max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
+ .max_register = 0xFF, /* 0x80 .. 0xFF are vendor defined */
};
static const struct tcpc_config tcpci_tcpc_config = {
@@ -435,22 +478,22 @@ static int tcpci_parse_config(struct tcpci *tcpci)
return 0;
}
-static int tcpci_probe(struct i2c_client
[PATCH] Build: Scripts/Makefile: Remove Repeated Lines
Last two lines of code was repreated and was causing build error. Signed-off-by: Progyan Bhattacharya Cc: Arnd Bergmann Cc: Daniel Golle Cc: Joe Perches Cc: Neil Armstrong Cc: Andrew Morton Cc: Stephen Rothwell --- scripts/Makefile.kasan | 4 1 file changed, 4 deletions(-) diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan index b7b9ecef44cc..69552a39951d 100644 --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -45,7 +45,3 @@ endif CFLAGS_KASAN_NOSANITIZE := -fno-builtin endif - -CFLAGS_KASAN_NOSANITIZE := -fno-builtin - -endif -- 2.16.1
Re: WARNING in kvmalloc_node
[ +Jason, +Jesper ]
On 02/14/2018 09:43 AM, Michal Hocko wrote:
> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
> [...]
>>> kvmalloc include/linux/mm.h:541 [inline]
>>> kvmalloc_array include/linux/mm.h:557 [inline]
>>> __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>> ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>> __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>> cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>> map_update_elem kernel/bpf/syscall.c:698 [inline]
>>
>> Blame the BPF people, not the MM people ;-)
Heh, not really. ;-)
> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.
Agree, that doesn't work.
Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc()
fails").
Jason, please take a look at fixing this, thanks!
Re: [PATCH] ACPI: SPCR: Mark expected switch fall-through in acpi_parse_spcr
On Friday, February 9, 2018 7:08:21 PM CET Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Addresses-Coverity-ID: 1465078
> Signed-off-by: Gustavo A. R. Silva
> ---
> This code was compiled with GCC 7.3.0
>
> drivers/acpi/spcr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> index 89e97d2..9d52743 100644
> --- a/drivers/acpi/spcr.c
> +++ b/drivers/acpi/spcr.c
> @@ -115,6 +115,7 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool
> enable_console)
> table->serial_port.access_width))) {
> default:
> pr_err("Unexpected SPCR Access Width. Defaulting to
> byte size\n");
> + /* fall through */
> case 8:
> iotype = "mmio";
> break;
>
Applied, thanks!
Re: [PATCH v2 0/2] acpi: document sysfs interfaces
On Saturday, February 10, 2018 9:55:53 AM CET Aishwarya Pant wrote: > Patchset contains documentation for two acpi drivers- dock and dptf. > Description > was collected from git history and reading through code. This might be useful > for tracking changes in the ABI. > > Changes in v2: > - Split up multiple attribute definitions > > Aishwarya Pant (2): > acpi/dptf: document sysfs atttributes > acpi/dock: document sysfs interface > > .../ABI/testing/sysfs-devices-platform-dock| 39 + > Documentation/ABI/testing/sysfs-platform-dptf | 40 > ++ > 2 files changed, 79 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-dock > create mode 100644 Documentation/ABI/testing/sysfs-platform-dptf Both patches applied with minor modifications, thanks!
Re: [PATCH v2 2/3] arm64: dts: rockchip: add cdn-dp node for rk3399.
Am Dienstag, 13. Februar 2018, 15:35:48 CET schrieb Enric Balletbo i Serra: > From: Chris Zhong > > Add a node for the cdn DP controller which is embedded in the rk3399 > SoC. > > Signed-off-by: Chris Zhong > Signed-off-by: Enric Balletbo i Serra applied for 4.17 after some fixups: - the patch used whitespaces instead of tabs for indentation - address+size-cells are only necessary above the endpoint nodes (see the hdmi node for example) - the interrupts property had the wrong number of elements dtc should have warned about that Heiko
Re: [PATCH 1/2] vfio: platform: Fix reset module leak in error path
Hi Eric,
On Wed, Feb 14, 2018 at 9:36 AM, Auger Eric wrote:
> If I am not wrong we also leak the reset_module if
> vfio_platform_get_reset() fails to find the reset function (of_reset ==
> NULL), in which case we should do the module_put() in
> vfio_platform_get_reset().
Correct. Will look into fixing it...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from NMI context
* Tim Chen wrote:
> Dave Hansen and I had some discussions on how to handle the nested NMI and
> firmware calls. We thought of using a per cpu counter to record the nesting
> call depth and toggle IBRS appropriately for the depth 0->1 and 1->0
> transition.
> Will this change be sufficient?
Yeah, so I think the first question should be: does the firmware call from NMI
context make sense to begin with?
Because in this particular case it does not appear to be so: the reason for the
BIOS/firmware call appears to be to determine how we nmi_panic() after
receiving
an NMI that no other NMI handler handled: with a passive-aggressive "I don't
know"
panic message or with a slightly more informative panic message.
That's not a real value-add to users - so we can avoid all these complications
by
applying the patch below:
drivers/watchdog/hpwdt.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
As a bonus the spinlock use can be removed as well.
Thanks,
Ingo
>
>From b038428a739a3fcf0b9678305c131f60af7422ca Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Wed, 14 Feb 2018 10:24:41 +0100
Subject: [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from
NMI context
Taking a spinlock and calling into the firmware are problematic things to
do from NMI callbacks.
It also seems completely pointless in this particular case:
- cmn_regs is updated by the firmware call in the hpwdt_pretimeout() NMI
callback, but there's almost no use for it: we use it only to determine
whether to panic with an 'unknown NMI' or a slightly more descriptive
message.
- cmn_regs and rom_lock is not used anywhere else, other than early detection
of the firmware capability.
So remove rom_lock, make the cmn_regs call from the detection routine only,
and thus make the NMI callback a lot more robust.
Signed-off-by: Ingo Molnar
---
drivers/watchdog/hpwdt.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
index f1f00dfc0e68..2544fe482fe3 100644
--- a/drivers/watchdog/hpwdt.c
+++ b/drivers/watchdog/hpwdt.c
@@ -150,9 +150,7 @@ static unsigned int hpwdt_nmi_decoding;
static unsigned int allow_kdump = 1;
static unsigned int is_icru;
static unsigned int is_uefi;
-static DEFINE_SPINLOCK(rom_lock);
static void *cru_rom_addr;
-static struct cmn_registers cmn_regs;
extern asmlinkage void asminline_call(struct cmn_registers *pi86Regs,
unsigned long *pRomEntry);
@@ -225,6 +223,7 @@ static int cru_detect(unsigned long map_entry,
unsigned long physical_bios_base = 0;
unsigned long physical_bios_offset = 0;
int retval = -ENODEV;
+ struct cmn_registers cmn_regs = { };
bios32_map = ioremap(map_entry, (2 * PAGE_SIZE));
@@ -486,32 +485,18 @@ static int hpwdt_my_nmi(void)
*/
static int hpwdt_pretimeout(unsigned int ulReason, struct pt_regs *regs)
{
- unsigned long rom_pl;
- static int die_nmi_called;
-
if (!hpwdt_nmi_decoding)
return NMI_DONE;
if ((ulReason == NMI_UNKNOWN) && !hpwdt_my_nmi())
return NMI_DONE;
- spin_lock_irqsave(&rom_lock, rom_pl);
- if (!die_nmi_called && !is_icru && !is_uefi)
- asminline_call(&cmn_regs, cru_rom_addr);
- die_nmi_called = 1;
- spin_unlock_irqrestore(&rom_lock, rom_pl);
-
if (allow_kdump)
hpwdt_stop();
- if (!is_icru && !is_uefi) {
- if (cmn_regs.u1.ral == 0) {
- nmi_panic(regs, "An NMI occurred, but unable to
determine source.\n");
- return NMI_HANDLED;
- }
- }
- nmi_panic(regs, "An NMI occurred. Depending on your system the reason "
- "for the NMI is logged in any one of the following "
+ nmi_panic(regs,
+ "An NMI occurred. Depending on your system the reason "
+ "for the NMI might be logged in any one of the following "
"resources:\n"
"1. Integrated Management Log (IML)\n"
"2. OA Syslog\n"
@@ -744,13 +729,6 @@ static int hpwdt_init_nmi_decoding(struct pci_dev *dev)
HPWDT_ARCH);
return retval;
}
-
- /*
- * We know this is the only CRU call we need to make so lets
keep as
- * few instructions as possible once the NMI comes in.
- */
- cmn_regs.u1.rah = 0x0D;
- cmn_regs.u1.ral = 0x02;
}
/*
Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups
On 7 February 2018 at 20:11, Wolfram Sang wrote: > >> I picked patch5 and patch6, as those seemed trivial. Unless there is a >> rc9, let's aim for 4.17 for the rest. > > I can't find the branch where you picked these patches? I wanted to use > it to apply the rest of the patches. They don't seem to fit on v4.15 > or current linus/master. Can you share this branch? You need to check again. :-) Patches up and to patch6 is already in Linus' tree v.16rc1, those I carried for quite a while on my next branch before sending them in the PR to Linus. > > I will do reviewing now "visually". But please wait until I tested them > before applying. I am eager to apply those patches you already have reviewed (to patch14), as those mostly seemed rather trivial and should be nice cleanups. Do you mind me going ahead, then you can continue and review/test the rest? Kind regards Uffe
Re: [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from NMI context
On Wed, Feb 14, 2018 at 10:31:59AM +0100, Ingo Molnar wrote: > Because in this particular case it does not appear to be so: the reason for > the > BIOS/firmware call appears to be to determine how we nmi_panic() after > receiving > an NMI that no other NMI handler handled: with a passive-aggressive "I don't > know" > panic message or with a slightly more informative panic message. However much I like just ripping all that out, I think the ROM call actually does that logging, or that is how I read things. If you look at the original Changelog for that driver: Hp is providing a Hardware WatchDog Timer driver that will only work with the specific HW Timer located in the HP ProLiant iLO 2 ASIC. The iLO 2 HW Timer will generate a Non-maskable Interrupt (NMI) 9 seconds before physically resetting the server, by removing power, so that the event can be logged to the HP Integrated Management Log (IML), a Non-Volatile Random Access Memory (NVRAM). The logging of the event is performed using the HP ProLiant ROM via an Industry Standard access known as a BIOS Service Directory Entry.
Re: [PATCH v2 0/8] Add support for PWM input capture on STM32
On Wed, 14 Feb 2018, Fabrice Gasnier wrote: > On 01/26/2018 04:11 PM, Fabrice Gasnier wrote: > > This series adds support for capture to stm32-pwm driver. > > Capture is based on DMAs. > > - First two patches are precursor patches > > - Subsequent two patches add support for requesting DMAs to MFD core > > - Next three patches add support for capture to stm32-pwm driver > > - This has been tested on stm32429i-eval board. > > > > --- > > Changes in v2: > > - Abstract DMA handling from child driver: move it to MFD core > > - Rework pwm capture routines to adopt this change > > - Comment on optional dma support, beautify DMAs probe > > Hi all, > > Gentle ping for v2 driver review since DT Bindings has been reviewed by > Rob and the series by Benjamin. Best thing to do is collect the Acks you have and send the set out as a [RESEND]. -- Lee Jones Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/2] vfio: platform: Add generic DT reset support
Hi Eric,
On Wed, Feb 14, 2018 at 10:09 AM, Auger Eric wrote:
> On 13/02/18 17:36, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller,
>> and can be reset in a generic way. Hence add support to reset such
>> devices using the reset controller subsystem, provided the reset
>> hierarchy is described correctly in DT using the "resets" property.
>
> I first acknowledge I am not familiar with what those reset controllers
> do in practice. My fear is that we may rely on generic SW pieces that
> may not be adapted to passthrough constraints. We must guarantee that
> any DMA access attempted by the devices are stopped and any interrupts
> gets stopped. Can we guarantee that the reset controller always induce
> that? Otherwise we may leave the door opened to badly reset assigned
> devices.
An on-SoC reset controller is basically a block controlling signals to the
reset inputs of the individual on-SoC devices.
On Renesas ARM SoCs, this allows to do a full reset of the attached device.
Of course the exact semantics depend on the actual SoC.
If e.g. DMA and interrupts are not stopped for a specific device on a
specific SoC, it still needs a device-specific reset driver, matching against
the appropriate compatible value, cfr. the quoted paragraph below.
You could add a whitelist for of_machine_is_compatible() or
of_device_is_compatible(), but that will grow large fast.
>> Devices that require a more complex reset procedure can still
>> provide a device-specific reset driver, as that takes precedence.
>> @@ -138,6 +152,8 @@ static void vfio_platform_put_reset(struct
>> vfio_platform_device *vdev)
>>
>> if (vdev->of_reset)
>> module_put(vdev->reset_module);
>> +
> if (vdev->reset_control) ?
> reset_control_put seems to only check IS_ERR()
void reset_control_put(struct reset_control *rstc)
{
if (IS_ERR_OR_NULL(rstc))
return;
So it does handle NULL.
>> + reset_control_put(vdev->reset_control);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups
Hi Ulf, 2018-02-14 18:36 GMT+09:00 Ulf Hansson : > On 7 February 2018 at 20:11, Wolfram Sang wrote: >> >>> I picked patch5 and patch6, as those seemed trivial. Unless there is a >>> rc9, let's aim for 4.17 for the rest. >> >> I can't find the branch where you picked these patches? I wanted to use >> it to apply the rest of the patches. They don't seem to fit on v4.15 >> or current linus/master. Can you share this branch? > > You need to check again. :-) > > Patches up and to patch6 is already in Linus' tree v.16rc1, those I > carried for quite a while on my next branch before sending them in the > PR to Linus. > >> >> I will do reviewing now "visually". But please wait until I tested them >> before applying. > > I am eager to apply those patches you already have reviewed (to > patch14), as those mostly seemed rather trivial and should be nice > cleanups. > > Do you mind me going ahead, then you can continue and review/test the rest? > If you move forward, please fix-up the commit log of the patch 11. (https://patchwork.kernel.org/patch/10170007/) Documentation/devicetree/bindings/mmc/tmio_mmc.txt -> Documentation/devicetree/bindings/mmc/mmc.txt Thanks. -- Best Regards Masahiro Yamada
Re: [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from NMI context
+ Jerry
On Wed, Feb 14, 2018 at 10:31:59AM +0100, Ingo Molnar wrote:
>
> * Tim Chen wrote:
>
> > Dave Hansen and I had some discussions on how to handle the nested NMI and
> > firmware calls. We thought of using a per cpu counter to record the
> > nesting
> > call depth and toggle IBRS appropriately for the depth 0->1 and 1->0
> > transition.
> > Will this change be sufficient?
>
> Yeah, so I think the first question should be: does the firmware call from
> NMI
> context make sense to begin with?
>
> Because in this particular case it does not appear to be so: the reason for
> the
> BIOS/firmware call appears to be to determine how we nmi_panic() after
> receiving
> an NMI that no other NMI handler handled: with a passive-aggressive "I don't
> know"
> panic message or with a slightly more informative panic message.
>
> That's not a real value-add to users - so we can avoid all these
> complications by
> applying the patch below:
>
> drivers/watchdog/hpwdt.c | 30 --
> 1 file changed, 4 insertions(+), 26 deletions(-)
>
> As a bonus the spinlock use can be removed as well.
>
> Thanks,
>
> Ingo
>
> >
> From b038428a739a3fcf0b9678305c131f60af7422ca Mon Sep 17 00:00:00 2001
> From: Ingo Molnar
> Date: Wed, 14 Feb 2018 10:24:41 +0100
> Subject: [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from
> NMI context
>
> Taking a spinlock and calling into the firmware are problematic things to
> do from NMI callbacks.
>
> It also seems completely pointless in this particular case:
>
> - cmn_regs is updated by the firmware call in the hpwdt_pretimeout() NMI
>callback, but there's almost no use for it: we use it only to determine
>whether to panic with an 'unknown NMI' or a slightly more descriptive
>message.
>
> - cmn_regs and rom_lock is not used anywhere else, other than early detection
>of the firmware capability.
>
> So remove rom_lock, make the cmn_regs call from the detection routine only,
> and thus make the NMI callback a lot more robust.
>
> Signed-off-by: Ingo Molnar
> ---
> drivers/watchdog/hpwdt.c | 30 --
> 1 file changed, 4 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> index f1f00dfc0e68..2544fe482fe3 100644
> --- a/drivers/watchdog/hpwdt.c
> +++ b/drivers/watchdog/hpwdt.c
> @@ -150,9 +150,7 @@ static unsigned int hpwdt_nmi_decoding;
> static unsigned int allow_kdump = 1;
> static unsigned int is_icru;
> static unsigned int is_uefi;
> -static DEFINE_SPINLOCK(rom_lock);
> static void *cru_rom_addr;
> -static struct cmn_registers cmn_regs;
>
> extern asmlinkage void asminline_call(struct cmn_registers *pi86Regs,
> unsigned long *pRomEntry);
> @@ -225,6 +223,7 @@ static int cru_detect(unsigned long map_entry,
> unsigned long physical_bios_base = 0;
> unsigned long physical_bios_offset = 0;
> int retval = -ENODEV;
> + struct cmn_registers cmn_regs = { };
>
> bios32_map = ioremap(map_entry, (2 * PAGE_SIZE));
>
> @@ -486,32 +485,18 @@ static int hpwdt_my_nmi(void)
> */
> static int hpwdt_pretimeout(unsigned int ulReason, struct pt_regs *regs)
> {
> - unsigned long rom_pl;
> - static int die_nmi_called;
> -
> if (!hpwdt_nmi_decoding)
> return NMI_DONE;
>
> if ((ulReason == NMI_UNKNOWN) && !hpwdt_my_nmi())
> return NMI_DONE;
>
> - spin_lock_irqsave(&rom_lock, rom_pl);
> - if (!die_nmi_called && !is_icru && !is_uefi)
> - asminline_call(&cmn_regs, cru_rom_addr);
> - die_nmi_called = 1;
> - spin_unlock_irqrestore(&rom_lock, rom_pl);
> -
> if (allow_kdump)
> hpwdt_stop();
>
> - if (!is_icru && !is_uefi) {
> - if (cmn_regs.u1.ral == 0) {
> - nmi_panic(regs, "An NMI occurred, but unable to
> determine source.\n");
> - return NMI_HANDLED;
> - }
> - }
> - nmi_panic(regs, "An NMI occurred. Depending on your system the reason "
> - "for the NMI is logged in any one of the following "
> + nmi_panic(regs,
> + "An NMI occurred. Depending on your system the reason "
> + "for the NMI might be logged in any one of the following "
> "resources:\n"
> "1. Integrated Management Log (IML)\n"
> "2. OA Syslog\n"
> @@ -744,13 +729,6 @@ static int hpwdt_init_nmi_decoding(struct pci_dev *dev)
> HPWDT_ARCH);
> return retval;
> }
> -
> - /*
> - * We know this is the only CRU call we need to make so lets
> keep as
> - * few instructions as possible once the NMI comes in.
> - */
> - cmn_regs.u1.rah = 0x0D;
> - cmn_regs.u1.ral = 0x02;
> }
>
>
Re: [PATCH 0/2] Update lockdep doc and add section about annotations
On Tue, Feb 13, 2018 at 07:55:17PM +0100, Juri Lelli wrote: > Hi, > > a couple of patches to lockdep docs. > > First one is a small fix for that fact that Peter made documentation > stale (as usual :P). > > Second one is an RFC. I thought that adding some info about lockdep > asserts might help spread adoption even wider (mostly regarding > lockdep_pin_lock stuff, which is pretty new and maybe got unnoticed > outside of the scheduler?). Thanks for writing that Juri! Acked-by: Peter Zijlstra (Intel)
Re: [PATCH 19/31] x86/mm/pae: Populate valid user PGD entries
On 09/02/18 10:25, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Generic page-table code populates all non-leaf entries with
> _KERNPG_TABLE bits set. This is fine for all paging modes
> except PAE.
>
> In PAE mode only a subset of the bits is allowed to be set.
> Make sure we only set allowed bits by masking out the
> reserved bits.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/pgtable_types.h | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index 3696398..5027470 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -50,6 +50,7 @@
> #define _PAGE_GLOBAL (_AT(pteval_t, 1) << _PAGE_BIT_GLOBAL)
> #define _PAGE_SOFTW1 (_AT(pteval_t, 1) << _PAGE_BIT_SOFTW1)
> #define _PAGE_SOFTW2 (_AT(pteval_t, 1) << _PAGE_BIT_SOFTW2)
> +#define _PAGE_SOFTW3 (_AT(pteval_t, 1) << _PAGE_BIT_SOFTW3)
> #define _PAGE_PAT(_AT(pteval_t, 1) << _PAGE_BIT_PAT)
> #define _PAGE_PAT_LARGE (_AT(pteval_t, 1) << _PAGE_BIT_PAT_LARGE)
> #define _PAGE_SPECIAL(_AT(pteval_t, 1) << _PAGE_BIT_SPECIAL)
> @@ -267,14 +268,35 @@ typedef struct pgprot { pgprotval_t pgprot; } pgprot_t;
>
> typedef struct { pgdval_t pgd; } pgd_t;
>
> +#ifdef CONFIG_X86_PAE
> +
> +/*
> + * PHYSICAL_PAGE_MASK might be non-constant when SME is compiled in, so we
> can't
> + * use it here.
> + */
> +#define PGD_PAE_PHYS_MASK(((1ULL << __PHYSICAL_MASK_SHIFT)-1) &
> PAGE_MASK)
I think PAGE_MASK is a 32 bit value here, so you are chopping off
the high physical address bits.
With that corrected the kernel is coming up as Xen PV guest.
Juergen
Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups
On 14 February 2018 at 10:43, Masahiro Yamada wrote: > Hi Ulf, > > > 2018-02-14 18:36 GMT+09:00 Ulf Hansson : >> On 7 February 2018 at 20:11, Wolfram Sang wrote: >>> I picked patch5 and patch6, as those seemed trivial. Unless there is a rc9, let's aim for 4.17 for the rest. >>> >>> I can't find the branch where you picked these patches? I wanted to use >>> it to apply the rest of the patches. They don't seem to fit on v4.15 >>> or current linus/master. Can you share this branch? >> >> You need to check again. :-) >> >> Patches up and to patch6 is already in Linus' tree v.16rc1, those I >> carried for quite a while on my next branch before sending them in the >> PR to Linus. >> >>> >>> I will do reviewing now "visually". But please wait until I tested them >>> before applying. >> >> I am eager to apply those patches you already have reviewed (to >> patch14), as those mostly seemed rather trivial and should be nice >> cleanups. >> >> Do you mind me going ahead, then you can continue and review/test the rest? >> > > > If you move forward, please fix-up the commit log of the patch 11. > (https://patchwork.kernel.org/patch/10170007/) > > > Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > -> > > Documentation/devicetree/bindings/mmc/mmc.txt Thanks for the reminder. Yes I can amend the patch, no worries. Kind regards Uffe
Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
On Wed, Feb 14, 2018 at 08:41:43AM +, Chandler Carruth wrote: > Marina, Kees: > > I think the combination of LKML and the LLVM developer's list is probably > too large a set of folks to have a (somewhat) lengthy exploration of > options and how to go about this and find a good path forward. Why is there any need to discuss "options" here? What is preventing the implementation of "asm goto" in llvm? Is it the lack of a working patch, or something else? thanks, greg k-h
Re: [PATCH v2 08/16] mmc: sdhci-omap: Add support to override f_max and iodelay from pdata
On 5 February 2018 at 13:50, Kishon Vijay Abraham I wrote: > DRA74x EVM Rev H EVM comes with revision 2.0 silicon. However, earlier > versions of EVM can come with either revision 1.1 or revision 1.0 of > silicon. > > The device-tree file is written to support rev 2.0 of silicon. > pdata-quirks are used to then override the settings needed for > PG 1.1 silicon. > > PG 1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3 > can operate as well as different IOdelay numbers. I fail to understand the need for platform data. Why can't DT be used for the older revisions as well? > > Add support in sdhci-omap driver to get platform data if available > (added using pdata quirks) and override the data (max-frequency and > iodelay data) obtained from device tree. [...] Kind regards Uffe
RE: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
Hi Peter, When I started the original thread last year I was in favor of adding "asm goto" and didn't understand why it wasn't done by that time. The feedback I got is that this feature (optimizing tracepoints) is very useful and that we do want it in llvm, but perhaps there's a cleaner way of implementing than "asm goto". An alternative suggestion arose as well. I'm sure you can provide a lot of background for the decisions of why "asm goto" was chosen and which other alternatives were considered, as you were the one to implement this. This may shed a lot of light on the alternative suggestions that arose in my thread in the llvm community. I think that including GCC folks in the "small team" discussion Chandler suggested might be a very good idea, so if you have some contacts, please send them to Chandler. Anyway, I think we should consider the alternatives and not take "asm goto" as a given, even though this is the implementation of this feature for the past 7 years and it works well. I'm not saying linux kernel needs to rush and adopt an alternative solution ASAP, but we cannot ignore that it exists and may (or may not) be the direction of the future (for both gcc and llvm). Thanks, Marina -Original Message- From: Peter Zijlstra [mailto:pet...@infradead.org] Sent: Wednesday, February 14, 2018 11:09 To: Yatsina, Marina Cc: Kees Cook ; David Woodhouse ; Chandler Carruth ; Kreitzer, David L ; Grischenko, Andrei L ; r...@google.com; LLVM Developers ; eh...@mozilla.com; Tayree, Coby ; Matthias Braun ; Dean Michael Berris ; James Y Knight ; Guenter Roeck ; X86 ML ; LKML ; Alan Cox ; Rik van Riel ; Andi Kleen ; Josh Poimboeuf ; Tom Lendacky ; Linus Torvalds ; Jiri Kosina ; Andy Lutomirski ; Hansen, Dave ; Tim Chen ; Greg Kroah-Hartman ; Paul Turner ; Stephen Hines ; Nick Desaulniers Subject: Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support) On Wed, Feb 14, 2018 at 08:33:39AM +, Yatsina, Marina wrote: > I hope this will give this issue a push forward and we will find a > solution that will not prevent llvm from compiling linux kernel. That solution is asm-goto. We (linux kernel) are not going to support something like it. It's going to be asm-goto or bust. The feature is over 7 years old by now, deal with it. If you ever get to the point where it makes sense to build a kernel with LLVM, then you can bike-shed with the GCC team on new features, until then tough luck. - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[PATCH v3 1/5] arm64: dts: renesas: r8a77995: add FCPV nodes
From: Kieran Bingham
The FCPVB handles the interface between the VSPB and memory, while the
FCPVD handles the interface between the VSPD and memory.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index cd3c6a30fc47..196a917afea6 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -691,6 +691,33 @@
#phy-cells = <0>;
status = "disabled";
};
+
+ fcpvb0: fcp@fe96f000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfe96f000 0 0x200>;
+ clocks = <&cpg CPG_MOD 607>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 607>;
+ iommus = <&ipmmu_vp0 5>;
+ };
+
+ fcpvd0: fcp@fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ iommus = <&ipmmu_vi0 8>;
+ };
+
+ fcpvd1: fcp@fea2f000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea2f000 0 0x200>;
+ clocks = <&cpg CPG_MOD 602>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 602>;
+ iommus = <&ipmmu_vi0 9>;
+ };
};
timer {
--
2.7.4
[PATCH v3 3/5] arm64: dts: renesas: r8a7795-es1: Fix register mappings on VSPs
From: Kieran Bingham
The VSPD includes a CLUT on RPF2. Ensure that the register space is
mapped correctly to support this.
Signed-off-by: Kieran Bingham
---
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index ed553338b4d4..1adfe6cad268 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -80,7 +80,7 @@
vspd3: vsp@fea38000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea38000 0 0x4000>;
+ reg = <0 0xfea38000 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 620>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
--
2.7.4
[PATCH v3 5/5] arm64: dts: renesas: r8a7796: Fix register mappings on VSPs
From: Kieran Bingham
The VSPD includes a CLUT on RPF2. Ensure that the register space is
mapped correctly to support this.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 60755117cba5..3fe5566e0630 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2285,7 +2285,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x4000>;
+ reg = <0 0xfea2 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 623>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
@@ -2305,7 +2305,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x4000>;
+ reg = <0 0xfea28000 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 622>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
@@ -2325,7 +2325,7 @@
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
- reg = <0 0xfea3 0 0x4000>;
+ reg = <0 0xfea3 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 621>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
--
2.7.4
[PATCH v3 4/5] arm64: dts: renesas: r8a7795: Fix register mappings on VSPs
From: Kieran Bingham
The VSPD includes a CLUT on RPF2. Ensure that the register space is
mapped correctly to support this.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1f32340af2d1..772991db8820 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2607,7 +2607,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x4000>;
+ reg = <0 0xfea2 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 623>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
@@ -2627,7 +2627,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x4000>;
+ reg = <0 0xfea28000 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 622>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
@@ -2647,7 +2647,7 @@
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
- reg = <0 0xfea3 0 0x4000>;
+ reg = <0 0xfea3 0 0x8000>;
interrupts = ;
clocks = <&cpg CPG_MOD 621>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
--
2.7.4
[PATCH v3 2/5] arm64: dts: renesas: r8a77995: add VSP instances
From: Kieran Bingham
The r8a77995 has a VSPBS to support image processing such as blending of
two input images, and has two VSPDs to handle display pipelines with a
DU.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- Fix VSPD register map size
- Squash VSPBS and VSPD patches together
v3:
- Fix VSPBS register map size too :-)
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 196a917afea6..0db242114bc5 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -692,6 +692,16 @@
status = "disabled";
};
+ vspbs: vsp@fe96 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfe96 0 0x8000>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 627>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 627>;
+ renesas,fcp = <&fcpvb0>;
+ };
+
fcpvb0: fcp@fe96f000 {
compatible = "renesas,fcpv";
reg = <0 0xfe96f000 0 0x200>;
@@ -701,6 +711,16 @@
iommus = <&ipmmu_vp0 5>;
};
+ vspd0: vsp@fea2 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea2 0 0x8000>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp@fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
@@ -710,6 +730,16 @@
iommus = <&ipmmu_vi0 8>;
};
+ vspd1: vsp@fea8 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea28000 0 0x8000>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 622>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 622>;
+ renesas,fcp = <&fcpvd1>;
+ };
+
fcpvd1: fcp@fea2f000 {
compatible = "renesas,fcpv";
reg = <0 0xfea2f000 0 0x200>;
--
2.7.4
Re: [PATCH 00/17] Add kexec_file_load support to s390
Hi Dave, I just browsed AKASHI's patches (v7). The way I see it the common code changes are on different areas of kexec_file and shouldn't get in conflict. Only in the arch code (s390 and arm64) some function calls might need an update. But I have to take a closer look on the patches first. @AKASHI: Welcome to the list. While browsing I couldn't find any arch_apply_relocation function for arm64. These require the biggest changes in my patch set. Did I just miss it or does arm64 work differently? @Dave: Happy holiday Thanks Philipp On Wed, 14 Feb 2018 15:35:43 +0800 Dave Young wrote: > Hi Philipp, > > I added AKASHI in cc, he posted arm64 kexec_file series previously. > I would like to read both series especially the general part, but > maybe at the end of this month because of a holiday.. > > From the patch log the cleanup looks nice, but still need read the > details. > > On 02/12/18 at 11:07am, Philipp Rudo wrote: > > Hi everybody > > > > resending the series as there was no reaction, yet. Furthermore i was told > > that Andrew and the x86 list should also be CCed, so welcome. > > > > No changes made to the patches since first time i sent them. The patches > > apply to the current master (v4.16-rc1). > > > > Thanks > > Philipp > > > > --- > > > > this series adds the kexec_file_load system call to s390. Before the system > > call is added there are some preparations/clean ups to common > > kexec_file_load. In detail this series contains: > > > > Patch #1&2: Minor cleanups/fixes. > > > > Patch #3-9: Clean up the purgatory load/relocation code. Especially remove > > the mis-use of the purgatory_info->sechdrs->sh_offset field, currently > > holding a pointer into either kexec_purgatory (ro) or purgatory_buf (rw) > > depending on the section. With these patches the section address will be > > calculated verbosely and sh_offset will contain the offset of the section > > in the stripped purgatory binary (purgatory_buf). > > > > Patch #10: Allows architectures to set the purgaory load address. This > > patch is important for s390 as the kernel and purgatory have to be loaded > > to fixed addresses. In current code this is impossible as the purgatory > > load is opaque to the architecture. > > > > Patch #11: Moves x86 purgatories sha implementation to common lib/ > > directory. > > > > Patches #12-17 finally adds the kexec_file_load system call to s390. > > > > Please note that I had to touch arch code for x86 and power a little. In > > theory this should not change the behavior but I don't have a way to test > > it. Cross-compiling with defconfig(*) works fine for both. > > > > Thanks > > Philipp > > > > (*) On x86 with the orc unwinder turned off. objtool SEGFAULTs on s390... > > > > Philipp Rudo (17): > > kexec_file: Silence compile warnings > > kexec_file: Remove checks in kexec_purgatory_load > > kexec_file: Make purgatory_info->ehdr const > > kexec_file: Search symbols in read-only kexec_purgatory > > kexec_file: Use read-only sections in arch_kexec_apply_relocations* > > kexec_file: Split up __kexec_load_puragory > > kexec_file: Simplify kexec_purgatory_setup_sechdrs 1 > > kexec_file: Simplify kexec_purgatory_setup_sechdrs 2 > > kexec_file: Remove mis-use of sh_offset field > > kexec_file: Allow archs to set purgatory load address > > kexec_file: Move purgatories sha256 to common code > > s390/kexec_file: Prepare setup.h for kexec_file_load > > s390/kexec_file: Add purgatory > > s390/kexec_file: Add kexec_file_load system call > > s390/kexec_file: Add image loader > > s390/kexec_file: Add crash support to image loader > > s390/kexec_file: Add ELF loader > > > > arch/powerpc/kernel/kexec_elf_64.c | 9 +- > > arch/s390/Kbuild | 1 + > > arch/s390/Kconfig | 4 + > > arch/s390/include/asm/kexec.h | 23 ++ > > arch/s390/include/asm/purgatory.h | 17 ++ > > arch/s390/include/asm/setup.h | 40 ++- > > arch/s390/kernel/Makefile | 1 + > > arch/s390/kernel/asm-offsets.c | 5 + > > arch/s390/kernel/compat_wrapper.c | 1 + > > arch/s390/kernel/kexec_elf.c | 149 ++ > > arch/s390/kernel/kexec_image.c | 78 + > > arch/s390/kernel/machine_kexec_file.c | 291 +++ > > arch/s390/kernel/syscalls/syscall.tbl | 1 + > > arch/s390/purgatory/Makefile | 37 +++ > > arch/s390/purgatory/head.S | 279 ++ > > arch/s390/purgatory/purgatory.c| 42 +++ > > arch/x86/kernel/kexec-bzimage64.c | 8 +- > > arch/x86/kernel/machine_kexec_64.c | 66 ++--- > > arch/x86/purgatory/Makefile| 3 + > > arch/x86/purgatory/purgatory.c | 2 +- > > include/linux/kexec.h
Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent
On Mon 12-02-18 16:24:25, David Rientjes wrote: > Both kernelcore= and movablecore= can be used to define the amount of > ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires > the system memory capacity to be known when specifying the command line, > however. > > This introduces the ability to define both kernelcore= and movablecore= > as a percentage of total system memory. This is convenient for systems > software that wants to define the amount of ZONE_MOVABLE, for example, as > a proportion of a system's memory rather than a hardcoded byte value. > > To define the percentage, the final character of the parameter should be > a '%'. I do not have any objections regarding the extension. What I am more interested in is _why_ people are still using this command line parameter at all these days. Why would anybody want to introduce lowmem issues from 32b days. I can see the CMA/Hotplug usecases for ZONE_MOVABLE but those have their own ways to define zone movable. I was tempted to simply remove the kernelcore already. Could you be more specific what is your usecase which triggered a need of an easier scaling of the size? -- Michal Hocko SUSE Labs
Re: [PATCH,RESEND2] regulator: fixed, gpio: dt: regulator-name is required property
Mark Brown writes: > On Tue, Feb 13, 2018 at 02:43:08PM +, Harald Geyer wrote: > > > BTW, it took me a bit to figure out that by "content free ping" you are > > refering to the quoting of the patch. Maybe you can reword your canned > > response to make it easier to understand. > > No, a content free ping is when you just send a reply saying something > to the effect of "hey, what's going on with this?". Well, I did quote the entire patch and gave a summary of the status as far as I know it. So I really don't understand why I got the "no content free pings" response ... > As I said in my > reply best case the answer is going to be "I have no idea, you need to > resend since I'll need the patch to do anything with it" and worst case > it just won't get seen at all if the thing really did get buried > somehow. So you are saying you don't want pings as followups to patches at all, if the patch is old enough that it probably got lost? I guess that would make sense too, but again it's not obvious to read the canned response that way.
Re: [PATCH 19/31] x86/mm/pae: Populate valid user PGD entries
Hi Juergen, On Wed, Feb 14, 2018 at 10:45:53AM +0100, Juergen Gross wrote: > On 09/02/18 10:25, Joerg Roedel wrote: > > +#ifdef CONFIG_X86_PAE > > + > > +/* > > + * PHYSICAL_PAGE_MASK might be non-constant when SME is compiled in, so we > > can't > > + * use it here. > > + */ > > +#define PGD_PAE_PHYS_MASK (((1ULL << __PHYSICAL_MASK_SHIFT)-1) & > > PAGE_MASK) > > I think PAGE_MASK is a 32 bit value here, so you are chopping off > the high physical address bits. > > With that corrected the kernel is coming up as Xen PV guest. Cool, thanks for testing these patches and debugging the breakage on Xen-PV. I'll fix that in the next version. Thanks again, Joerg
Re: [PATCH 01/15] Documentation: devicetree: R-Car M3-N SoC DT bindings
On Tue, Feb 13, 2018 at 10:45:48AM +0100, Jacopo Mondi wrote: > Add device tree bindings documentation for Renesas R-Car M3-N (r8a77965) > SoC. > > Signed-off-by: Jacopo Mondi Thanks, this looks fine to me but I think the subject should be updated to dt-bindings: arm: document R8A77965 SoC bindings I'll let this sit for a few days to see if any other review is forthcoming. > --- > Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt > b/Documentation/devicetree/bindings/arm/shmobile.txt > index 5c3af7e..7eb4830 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -39,6 +39,8 @@ SoCs: > compatible = "renesas,r8a7795" >- R-Car M3-W (R8A77960) > compatible = "renesas,r8a7796" > + - R-Car M3-N (R8A77965) > +compatible = "renesas,r8a77965" >- R-Car V3M (R8A77970) > compatible = "renesas,r8a77970" >- R-Car D3 (R8A77995) > -- > 2.7.4 >
Re: [PATCH 06/18] thunderbolt: Wait a bit longer for ICM to authenticate the active NVM
On Tue, Feb 13, 2018 at 05:21:33PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > Sent: Tuesday, February 13, 2018 11:00 AM
> > To: linux-kernel@vger.kernel.org
> > Cc: Andreas Noever ; Michael Jamet
> > ; Yehezkel Bernat ;
> > Bjorn
> > Helgaas ; Limonciello, Mario
> > ; Radion Mirchevsky
> > ; Mika Westerberg
> >
> > Subject: [PATCH 06/18] thunderbolt: Wait a bit longer for ICM to
> > authenticate the
> > active NVM
> >
> > Sometimes during cold boot ICM has not yet authenticated the active NVM
> > image leading to timeout and failing the driver probe. Allow ICM to take
> > some more time and increase the timeout to 3 seconds before we give up.
> >
> > While there fix icm_firmware_init() to return the real error code
> > without overwriting it with -ENODEV.
> >
> > Signed-off-by: Mika Westerberg
> > ---
> > drivers/thunderbolt/icm.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
> > index 1183321586c5..611d28e8e5f2 100644
> > --- a/drivers/thunderbolt/icm.c
> > +++ b/drivers/thunderbolt/icm.c
> > @@ -736,14 +736,14 @@ static bool icm_ar_is_supported(struct tb *tb)
> > static int icm_ar_get_mode(struct tb *tb)
> > {
> > struct tb_nhi *nhi = tb->nhi;
> > - int retries = 5;
> > + int retries = 60;
> > u32 val;
> >
> > do {
> > val = ioread32(nhi->iobase + REG_FW_STS);
> > if (val & REG_FW_STS_NVM_AUTH_DONE)
> > break;
> > - msleep(30);
> > + msleep(50);
> > } while (--retries);
> >
> > if (!retries) {
> > @@ -1063,6 +1063,9 @@ static int icm_firmware_init(struct tb *tb)
> > break;
> >
> > default:
> > + if (ret < 0)
> > + return ret;
> > +
> > tb_err(tb, "ICM firmware is in wrong mode: %u\n", ret);
> > return -ENODEV;
> > }
> > --
> > 2.15.1
>
> Mika,
>
> Some of your patches in this series already have the stable tag, but I think
> especially this one is probably a good candidate to add to @stable.
You are right. I'll add stable tag for v2.
Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
On 1/24/2018 7:19 PM, Robin Murphy wrote:
On 24/01/18 10:35, Jeffy Chen wrote:
From: Tomasz Figa
Current code relies on master driver enabling necessary clocks before
IOMMU is accessed, however there are cases when the IOMMU should be
accessed while the master is not running yet, for example allocating
V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
mapping API and doesn't engage the master driver at all.
This patch fixes the problem by letting clocks needed for IOMMU
operation to be listed in Device Tree and making the driver enable them
for the time of accessing the hardware.
Signed-off-by: Jeffy Chen
Signed-off-by: Tomasz Figa
---
Changes in v5:
Use clk_bulk APIs.
Changes in v4: None
Changes in v3: None
Changes in v2: None
[snip]
+static int rk_iommu_of_get_clocks(struct rk_iommu *iommu)
+{
+ struct device_node *np = iommu->dev->of_node;
+ int ret;
+ int i;
+
+ ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+ if (ret == -ENOENT)
+ return 0;
+ else if (ret < 0)
+ return ret;
+
+ iommu->num_clocks = ret;
+ iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
+ sizeof(*iommu->clocks), GFP_KERNEL);
+ if (!iommu->clocks)
+ return -ENOMEM;
+
+ for (i = 0; i < iommu->num_clocks; ++i) {
+ iommu->clocks[i].clk = of_clk_get(np, i);
+ if (IS_ERR(iommu->clocks[i].clk)) {
+ ret = PTR_ERR(iommu->clocks[i].clk);
+ goto err_clk_put;
+ }
+ }
Just to confirm my understanding from a quick scan through the code,
the reason we can't use clk_bulk_get() here is that currently,
clocks[i].id being NULL means we'd end up just getting the first clock
multiple times, right?
I guess there could be other users who also want "just get whatever
clocks I have" functionality, so it might be worth proposing that for
the core API as a separate/follow-up patch, but it definitely doesn't
need to be part of this series.
Just to understand. Is it okay to make the driver "just get whatever
clocks device node gives"?
Doesn't the driver need to be aware of which all clocks are supposed to
be obtained and enabled
It's should good for debug to let the world know which clock we failed
to get.
regards
Vivek
I really don't know enough about correct clk API usage, but modulo the
binding comments it certainly looks nice and tidy now;
Acked-by: Robin Murphy
Thanks,
Robin.
[snip]
___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RESEND PATCH v2 3/8] dt-bindings: mfd: stm32-timers: add support for dmas
Add support for DMAs to STM32 timers. STM32 Timers can support up to 7
dma requests: up to 4 channels, update, compare and trigger.
DMAs may be used to transfer data from pwm capture for instance.
DMA support is made optional, PWM capture support is also an option.
This is much more wise system-wide to avoid shortage on DMA request
lines as there's significant amount of timer instances that can
request up to 7 channels.
Signed-off-by: Fabrice Gasnier
Reviewed-by: Rob Herring
Reviewed-by: Benjamin Gaignard
---
.../devicetree/bindings/mfd/stm32-timers.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
index 1db6e00..0e900b5 100644
--- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
+++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
@@ -19,6 +19,11 @@ Required parameters:
Optional parameters:
- resets: Phandle to the parent reset controller.
See ../reset/st,stm32-rcc.txt
+- dmas:List of phandle to dma channels that can be
used for
+ this timer instance. There may be up to 7 dma channels.
+- dma-names: List of dma names. Must match 'dmas' property. Valid
+ names are: "ch1", "ch2", "ch3", "ch4", "up", "trig",
+ "com".
Optional subnodes:
- pwm: See ../pwm/pwm-stm32.txt
@@ -44,3 +49,18 @@ Example:
reg = <0>;
};
};
+
+Example with all dmas:
+ timer@4001 {
+ ...
+ dmas = <&dmamux1 11 0x400 0x0>,
+ <&dmamux1 12 0x400 0x0>,
+ <&dmamux1 13 0x400 0x0>,
+ <&dmamux1 14 0x400 0x0>,
+ <&dmamux1 15 0x400 0x0>,
+ <&dmamux1 16 0x400 0x0>,
+ <&dmamux1 17 0x400 0x0>;
+ dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig", "com";
+ ...
+ child nodes...
+ };
--
1.9.1
[RESEND PATCH v2 4/8] mfd: stm32-timers: add support for dmas
STM32 Timers can support up to 7 DMA requests:
- 4 channels, update, compare and trigger.
Optionally request part, or all DMAs from stm32-timers MFD core.
Also add routine to implement burst reads using DMA from timer registers.
This is exported. So, it can be used by child drivers, PWM capture
for instance (but not limited to).
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Add comments on optional dma support
---
drivers/mfd/stm32-timers.c | 215 ++-
include/linux/mfd/stm32-timers.h | 27 +
2 files changed, 238 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
index a6675a4..2cdad2c 100644
--- a/drivers/mfd/stm32-timers.c
+++ b/drivers/mfd/stm32-timers.c
@@ -6,16 +6,166 @@
* License terms: GNU General Public License (GPL), version 2
*/
+#include
+#include
+#include
#include
#include
#include
#include
+#define STM32_TIMERS_MAX_REGISTERS 0x3fc
+
+struct stm32_timers_priv {
+ struct device *dev;
+ struct completion completion;
+ phys_addr_t phys_base; /* timers physical addr for dma */
+ struct mutex lock; /* protect dma access */
+ struct dma_chan *dma_chan; /* dma channel in use */
+ struct dma_chan *dmas[STM32_TIMERS_MAX_DMAS];
+ struct stm32_timers ddata;
+};
+
+static struct stm32_timers_priv *to_stm32_timers_priv(struct stm32_timers *d)
+{
+ return container_of(d, struct stm32_timers_priv, ddata);
+}
+
+/* DIER register DMA enable bits */
+static const u32 stm32_timers_dier_dmaen[STM32_TIMERS_MAX_DMAS] = {
+ TIM_DIER_CC1DE, TIM_DIER_CC2DE, TIM_DIER_CC3DE, TIM_DIER_CC4DE,
+ TIM_DIER_UIE, TIM_DIER_TDE, TIM_DIER_COMDE
+};
+
+static void stm32_timers_dma_done(void *p)
+{
+ struct stm32_timers_priv *priv = p;
+ struct dma_chan *dma_chan = priv->dma_chan;
+ struct dma_tx_state state;
+ enum dma_status status;
+
+ status = dmaengine_tx_status(dma_chan, dma_chan->cookie, &state);
+ if (status == DMA_COMPLETE)
+ complete(&priv->completion);
+}
+
+/**
+ * stm32_timers_dma_burst_read - Read from timers registers using DMA.
+ *
+ * Read from STM32 timers registers using DMA on a single event.
+ * @ddata: reference to stm32_timers
+ * @buf: dma'able destination buffer
+ * @id: stm32_timers_dmas event identifier (ch[1..4], up, trig or com)
+ * @reg: registers start offset for DMA to read from (like CCRx for capture)
+ * @num_reg: number of registers to read upon each dma request, starting @reg.
+ * @bursts: number of bursts to read (e.g. like two for pwm period capture)
+ * @tmo_ms: timeout (milliseconds)
+ */
+int stm32_timers_dma_burst_read(struct stm32_timers *ddata, u32 *buf,
+ enum stm32_timers_dmas id, u32 reg,
+ unsigned int num_reg, unsigned int bursts,
+ unsigned long tmo_ms)
+{
+ struct stm32_timers_priv *priv = to_stm32_timers_priv(ddata);
+ unsigned long timeout = msecs_to_jiffies(tmo_ms);
+ struct regmap *regmap = priv->ddata.regmap;
+ size_t len = num_reg * bursts * sizeof(u32);
+ struct dma_async_tx_descriptor *desc;
+ struct dma_slave_config config;
+ dma_cookie_t cookie;
+ dma_addr_t dma_buf;
+ u32 dbl, dba;
+ long err;
+ int ret;
+
+ /* sanity check */
+ if (id < STM32_TIMERS_DMA_CH1 || id >= STM32_TIMERS_MAX_DMAS)
+ return -EINVAL;
+
+ if (!num_reg || !bursts || reg > STM32_TIMERS_MAX_REGISTERS ||
+ (reg + num_reg * sizeof(u32)) > STM32_TIMERS_MAX_REGISTERS)
+ return -EINVAL;
+
+ if (!priv->dmas[id])
+ return -ENODEV;
+ mutex_lock(&priv->lock);
+ priv->dma_chan = priv->dmas[id];
+
+ dma_buf = dma_map_single(priv->dev, buf, len, DMA_FROM_DEVICE);
+ ret = dma_mapping_error(priv->dev, dma_buf);
+ if (ret)
+ goto unlock;
+
+ /* Prepare DMA read from timer registers, using DMA burst mode */
+ memset(&config, 0, sizeof(config));
+ config.src_addr = (dma_addr_t)priv->phys_base + TIM_DMAR;
+ config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ ret = dmaengine_slave_config(priv->dma_chan, &config);
+ if (ret)
+ goto unmap;
+
+ desc = dmaengine_prep_slave_single(priv->dma_chan, dma_buf, len,
+ DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
+ if (!desc) {
+ ret = -EBUSY;
+ goto unmap;
+ }
+
+ desc->callback = stm32_timers_dma_done;
+ desc->callback_param = priv;
+ cookie = dmaengine_submit(desc);
+ ret = dma_submit_error(cookie);
+ if (ret)
+ goto dma_term;
+
+ reinit_completion(&priv->completion);
+
[RESEND PATCH v2 1/8] pwm: stm32: fix, remove unused struct device
dev is never assigned nor used. remove it.
Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
drivers/pwm/pwm-stm32.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 6139512..59524f9 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -21,7 +21,6 @@
struct stm32_pwm {
struct pwm_chip chip;
- struct device *dev;
struct clk *clk;
struct regmap *regmap;
u32 max_arr;
--
1.9.1
[RESEND PATCH v2 6/8] pwm: stm32: improve capture by tuning counter prescaler
Currently, capture is based on timeout window to configure prescaler.
PWM capture framework provides 1s window at the time of writing.
There's place for improvement, after input signal has been captured once:
- Finer tune counter clock prescaler, by using 1st capture result (with
arbitrary margin).
- Do a 2nd capture, with scaled capture window.
This increases accuracy, especially at high rates.
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
Changes in v2:
- Adopt DMA read from MFD core.
---
drivers/pwm/pwm-stm32.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index f3a92fc..5dfb296 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -169,7 +169,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
- unsigned int psc = 0;
+ unsigned int psc = 0, scale;
u32 raw_prd, raw_dty;
int ret = 0;
@@ -220,6 +220,28 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct
pwm_device *pwm,
if (ret)
goto stop;
+ /*
+* Got a capture. Try to improve accuracy at high rates:
+* - decrease counter clock prescaler, scale up to max rate.
+*/
+ if (raw_prd) {
+ u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
+
+ scale = max_arr / min(max_arr, raw_prd);
+ } else {
+ scale = priv->max_arr; /* bellow resolution, use max scale */
+ }
+
+ if (psc && scale > 1) {
+ /* 2nd measure with new scale */
+ psc /= scale;
+ regmap_write(priv->regmap, TIM_PSC, psc);
+ ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd,
+ &raw_dty);
+ if (ret)
+ goto stop;
+ }
+
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
result->period = DIV_ROUND_UP_ULL(prd, rate);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
--
1.9.1
[RESEND PATCH v2 7/8] pwm: stm32: use input prescaler to improve period capture
Using input prescaler, capture unit will trigger DMA once every
configurable /2, /4 or /8 events (rising edge). This helps improve
period (only) capture accuracy at high rates.
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
Changes in v2:
- Adopt DMA read from MFD core.
---
drivers/pwm/pwm-stm32.c | 63 ++--
include/linux/mfd/stm32-timers.h | 1 +
2 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 5dfb296..67964f5 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -9,6 +9,7 @@
* pwm-atmel.c from Bo Shen
*/
+#include
#include
#include
#include
@@ -169,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
- unsigned int psc = 0, scale;
+ unsigned int psc = 0, icpsc, scale;
u32 raw_prd, raw_dty;
int ret = 0;
@@ -223,6 +224,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct
pwm_device *pwm,
/*
* Got a capture. Try to improve accuracy at high rates:
* - decrease counter clock prescaler, scale up to max rate.
+* - use input prescaler, capture once every /2 /4 or /8 edges.
*/
if (raw_prd) {
u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
@@ -242,8 +244,65 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct
pwm_device *pwm,
goto stop;
}
+ /* Compute intermediate period not to exceed timeout at low rates */
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
- result->period = DIV_ROUND_UP_ULL(prd, rate);
+ do_div(prd, rate);
+
+ for (icpsc = 0; icpsc < MAX_TIM_ICPSC ; icpsc++) {
+ /* input prescaler: also keep arbitrary margin */
+ if (raw_prd >= (priv->max_arr - 0x1000) >> (icpsc + 1))
+ break;
+ if (prd >= (tmo_ms * NSEC_PER_MSEC) >> (icpsc + 2))
+ break;
+ }
+
+ if (!icpsc)
+ goto done;
+
+ /* Last chance to improve period accuracy, using input prescaler */
+ regmap_update_bits(priv->regmap,
+ pwm->hwpwm < 2 ? TIM_CCMR1 : TIM_CCMR2,
+ TIM_CCMR_IC1PSC | TIM_CCMR_IC2PSC,
+ FIELD_PREP(TIM_CCMR_IC1PSC, icpsc) |
+ FIELD_PREP(TIM_CCMR_IC2PSC, icpsc));
+
+ ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd, &raw_dty);
+ if (ret)
+ goto stop;
+
+ if (raw_dty >= (raw_prd >> icpsc)) {
+ /*
+* We may fall here using input prescaler, when input
+* capture starts on high side (before falling edge).
+* Example with icpsc to capture on each 4 events:
+*
+* start 1st capture 2nd capture
+* v v v
+* ___ _ _ _ _
+* TI1..4 |__||__||__||__||__|
+*v v. .. .. v v
+* icpsc1/3: . 0. 1. 2. 3. 0
+* icpsc2/4: 0 1 2 3 0
+*v vv v
+* CCR1/3 ..t0..t2
+* CCR2/4 ..t1..t1'...
+* .. .
+* Capture0: .<->.
+* Capture1: .<-->. .
+* .. .
+* Period: .<-->. .
+* Low side: .<>.
+*
+* Result:
+* - Period = Capture0 / icpsc
+* - Duty = Period - Low side = Period - (Capture0 - Capture1)
+*/
+ raw_dty = (raw_prd >> icpsc) - (raw_prd - raw_dty);
+ }
+
+done:
+ prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
+ result->period = DIV_ROUND_UP_ULL(prd, rate << icpsc);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
result->duty_cycle = DIV_ROUND_UP_ULL(dty, rate);
stop:
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
index 3abfa04..734cbca 100644
--- a/include/linux/mfd/stm32-timers.h
+++ b/include/linux/mfd/stm32-timers.h
@@ -82,6 +82,7 @@
#define TIM_DCR_DBLGENMASK(12, 8) /* DMA burst len */
#define MAX_TIM_PSC0
[RESEND PATCH v2 0/8] Add support for PWM input capture on STM32
This series adds support for capture to stm32-pwm driver. Capture is based on DMAs. - First two patches are precursor patches - Subsequent two patches add support for requesting DMAs to MFD core - Next three patches add support for capture to stm32-pwm driver - This has been tested on stm32429i-eval board. --- Resend v2: - Add collected Acks Changes in v2: - Abstract DMA handling from child driver: move it to MFD core - Rework pwm capture routines to adopt this change - Comment on optional dma support, beautify DMAs probe Fabrice Gasnier (8): pwm: stm32: fix, remove unused struct device pwm: stm32: protect common prescaler for all channels dt-bindings: mfd: stm32-timers: add support for dmas mfd: stm32-timers: add support for dmas pwm: stm32: add capture support pwm: stm32: improve capture by tuning counter prescaler pwm: stm32: use input prescaler to improve period capture ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval .../devicetree/bindings/mfd/stm32-timers.txt | 20 ++ arch/arm/boot/dts/stm32429i-eval.dts | 3 + drivers/mfd/stm32-timers.c | 215 +++- drivers/pwm/pwm-stm32.c| 276 - include/linux/mfd/stm32-timers.h | 39 +++ 5 files changed, 547 insertions(+), 6 deletions(-) -- 1.9.1
[RESEND PATCH v2 2/8] pwm: stm32: protect common prescaler for all channels
There may be a race, when configuring two pwm channels, with different
prescaler values, when there's no active channel yet.
Add mutex lock to avoid concurrent access on pwm apply state.
This is also precursor patch for pwm capture support.
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
drivers/pwm/pwm-stm32.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 59524f9..3ac55df 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -21,6 +21,7 @@
struct stm32_pwm {
struct pwm_chip chip;
+ struct mutex lock; /* protect pwm config/enable */
struct clk *clk;
struct regmap *regmap;
u32 max_arr;
@@ -213,9 +214,23 @@ static int stm32_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return ret;
}
+static int stm32_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device
*pwm,
+ struct pwm_state *state)
+{
+ struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
+ int ret;
+
+ /* protect common prescaler for all active channels */
+ mutex_lock(&priv->lock);
+ ret = stm32_pwm_apply(chip, pwm, state);
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
static const struct pwm_ops stm32pwm_ops = {
.owner = THIS_MODULE,
- .apply = stm32_pwm_apply,
+ .apply = stm32_pwm_apply_locked,
};
static int stm32_pwm_set_breakinput(struct stm32_pwm *priv,
@@ -335,6 +350,7 @@ static int stm32_pwm_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
+ mutex_init(&priv->lock);
priv->regmap = ddata->regmap;
priv->clk = ddata->clk;
priv->max_arr = ddata->max_arr;
--
1.9.1
[RESEND PATCH v2 8/8] ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval
Enable pwm3 input capture on stm32f429i-eval, by using DMA.
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
arch/arm/boot/dts/stm32429i-eval.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 293ecb9..d5498dd 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -271,6 +271,9 @@
&timers3 {
status = "okay";
+ /* Enable PWM input capture by using dma */
+ dmas = <&dma1 4 5 0x400 0x0>;
+ dma-names = "ch1";
pwm {
pinctrl-0 = <&pwm3_pins>;
pinctrl-names = "default";
--
1.9.1
[RESEND PATCH v2 5/8] pwm: stm32: add capture support
Add support for PMW input mode on pwm-stm32. STM32 timers support
period and duty cycle capture as long as they have at least two PWM
channels. One capture channel is used for period (rising-edge), one
for duty-cycle (falling-edge).
When there's only one channel available, only period can be captured.
Duty-cycle is simply zero'ed in such a case.
Capture requires exclusive access (e.g. no pwm output running at the
same time, to protect common prescaler).
Timer DMA burst mode (from MFD core) is being used, to take two
snapshots of capture registers (upon each period rising edge).
Signed-off-by: Fabrice Gasnier
Reviewed-by: Benjamin Gaignard
---
Changes in v2:
- DMA handling has been moved to MFD core. Rework capture routines to
use it.
---
drivers/pwm/pwm-stm32.c | 176 +++
include/linux/mfd/stm32-timers.h | 11 +++
2 files changed, 187 insertions(+)
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 3ac55df..f3a92fc 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -26,6 +26,7 @@ struct stm32_pwm {
struct regmap *regmap;
u32 max_arr;
bool have_complementary_output;
+ u32 capture[4] cacheline_aligned; /* DMA'able buffer */
};
struct stm32_breakinput {
@@ -63,6 +64,178 @@ static int write_ccrx(struct stm32_pwm *dev, int ch, u32
value)
return -EINVAL;
}
+#define TIM_CCER_CC12P (TIM_CCER_CC1P | TIM_CCER_CC2P)
+#define TIM_CCER_CC12E (TIM_CCER_CC1E | TIM_CCER_CC2E)
+#define TIM_CCER_CC34P (TIM_CCER_CC3P | TIM_CCER_CC4P)
+#define TIM_CCER_CC34E (TIM_CCER_CC3E | TIM_CCER_CC4E)
+
+/*
+ * Capture using PWM input mode:
+ * ___ ___
+ * TI[1, 2, 3 or 4]: ._| ||
+ * ^0 ^1 ^2
+ * . ..
+ * . .X
+ * . . X |
+ * . X .|
+ *X ..|
+ * COUNTER:__X . ..|_XXX
+ * start^ . ..^stop
+ * . . ..
+ * v v .v
+ * v
+ * CCR1/CCR3: tx..t0...t2
+ * CCR2/CCR4: tx..t1.
+ *
+ * DMA burst transfer: ||
+ * vv
+ * DMA buffer: { t0, tx } { t2, t1 }
+ * DMA done: ^
+ *
+ * 0: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t0, tx: doesn't care)
+ * 1: IC2/4 snapchot on falling edge: counter value -> CCR2/CCR4
+ * 2: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t2, t1)
+ *
+ * DMA done, compute:
+ * - Period = t2 - t0
+ * - Duty cycle = t1 - t0
+ */
+static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device
*pwm,
+unsigned long tmo_ms, u32 *raw_prd,
+u32 *raw_dty)
+{
+ struct stm32_timers *ddata = dev_get_drvdata(priv->chip.dev->parent);
+ enum stm32_timers_dmas dma_id;
+ u32 ccen, ccr;
+ int ret;
+
+ /* Ensure registers have been updated, enable counter and capture */
+ regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+ regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
+
+ /* Use cc1 or cc3 DMA resp for PWM input channels 1 & 2 or 3 & 4 */
+ dma_id = pwm->hwpwm < 2 ? STM32_TIMERS_DMA_CH1 : STM32_TIMERS_DMA_CH3;
+ ccen = pwm->hwpwm < 2 ? TIM_CCER_CC12E : TIM_CCER_CC34E;
+ ccr = pwm->hwpwm < 2 ? TIM_CCR1 : TIM_CCR3;
+ regmap_update_bits(priv->regmap, TIM_CCER, ccen, ccen);
+
+ /*
+* Timer DMA burst mode. Request 2 registers, 2 bursts, to get both
+* CCR1 & CCR2 (or CCR3 & CCR4) on each capture event.
+* We'll get two capture snapchots: { CCR1, CCR2 }, { CCR1, CCR2 }
+* or { CCR3, CCR4 }, { CCR3, CCR4 }
+*/
+ ret = stm32_timers_dma_burst_read(ddata, priv->capture, dma_id, ccr, 2,
+ 2, tmo_ms);
+ if (ret)
+ goto stop;
+
+ /* Period: t2 - t0 (take care of counter overflow) */
+ if (priv->capture[0] <= priv->capture[2])
+ *raw_prd = priv->capture[2] - priv->capture[0];
+ else
+ *raw_prd = priv->max_arr - priv->capture[0] + priv->capture[2];
+
+ /* Duty cycle capture requires at least two capture units */
+ if (pwm->chip->npwm < 2)
+ *raw_dty = 0;
+ else if (priv->capture[0] <= priv->capture[3])
+ *raw_dty = priv->capture[3] - priv->capture[0];
+ else
+ *raw
Re: [PATCH v3 3/5] arm64: dts: renesas: r8a7795-es1: Fix register mappings on VSPs
Hi Kieran,
Thank you for the patch.
On Wednesday, 14 February 2018 11:55:06 EET Kieran Bingham wrote:
> From: Kieran Bingham
>
> The VSPD includes a CLUT on RPF2. Ensure that the register space is
> mapped correctly to support this.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi index
> ed553338b4d4..1adfe6cad268 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> @@ -80,7 +80,7 @@
>
> vspd3: vsp@fea38000 {
> compatible = "renesas,vsp2";
> - reg = <0 0xfea38000 0 0x4000>;
> + reg = <0 0xfea38000 0 0x8000>;
> interrupts = ;
> clocks = <&cpg CPG_MOD 620>;
> power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
--
Regards,
Laurent Pinchart
Re: [RFC PATCH 2/2] KVM: SVM: Add MSR feature support for serializing LFENCE
On 14/02/2018 05:39, Tom Lendacky wrote: > On 2/13/2018 10:22 AM, Paolo Bonzini wrote: >> On 08/02/2018 23:58, Tom Lendacky wrote: >>> Create an entry in the new MSR as a feature framework to allow a guest to >>> recognize LFENCE as a serializing instruction on AMD processors. The MSR >>> can only be set by the host, any write by the guest will be ignored. A >>> read by the guest will return the value as set by the host. In this way, >>> the support to expose the feature to the guest is controlled by the >>> hypervisor. >>> >>> Signed-off-by: Tom Lendacky >>> --- >>> arch/x86/kvm/svm.c | 16 >>> arch/x86/kvm/x86.c |6 ++ >>> 2 files changed, 22 insertions(+) >>> >>> @@ -4047,6 +4052,17 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct >>> msr_data *msr) >>> case MSR_VM_IGNNE: >>> vcpu_unimpl(vcpu, "unimplemented wrmsr: 0x%x data 0x%llx\n", >>> ecx, data); >>> break; >>> + case MSR_F10H_DECFG: >>> + /* Only the host can set this MSR, silently ignore */ >>> + if (!msr->host_initiated) >>> + break; >> >> Just one thing I'm wondering, should we #GP if the guest attempts to >> clear MSR_F10H_DECFG_LFENCE_SERIALIZE? > > It would be more consistent with other entries to do "return 1" here > instead. The current kernel code that writes this bit is using > msr_set_bit(), so a #GP is caught and handled. That's also okay. We don't know about Windows though... Paolo
Re: [PATCH 17/18] thunderbolt: Introduce USB only (SL4) security level
On Tue, Feb 13, 2018 at 04:29:42PM -0800, Randy Dunlap wrote: > On 02/13/2018 09:00 AM, Mika Westerberg wrote: > > This new security level works so that it creates one PCIe tunnel to the > > connected Thunderbolt dock, removing PCIe links downstream of the dock. > > This leaves only the internal USB controller visible. > > > > Display Port tunnels are created normally. > > > > While there make sure security sysfs attribute returns "unknown" for any > > future security level. > > > > Signed-off-by: Mika Westerberg > > Hi, > > Also update Documentation/admin-guide/thunderbolt.rst ?? Good point. I'll do that in v2.
Re: [patch] kvm: suppress KVM_SET_GSI_ROUTING allocation failure
On 14/02/2018 02:03, David Rientjes wrote: > On Tue, 13 Feb 2018, Paolo Bonzini wrote: > The KVM_SET_GSI_ROUTING ioctl does a vmalloc() of sizeof(struct kvm_irq_routing_entry) multiplied by a user-supplied value. This can be up to 4096 entries on architectures such as arm64 and s390 (and the upper bound may be increased on s390 eventually). This can produce a vmalloc allocation failure warning: >>> [...] kvm_vm_ioctl+0x910/0x15e0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4153 >>> >>>^ >>> @@ -3063,7 +3063,8 @@ static long kvm_vm_ioctl(struct file *filp, >>> >>> ^ >>> >>> >>> Are you sure that you got the right vmalloc? >> >> Nice catch! But well, it's the only one in the whole file. :) >> >> That seems very much like an old patch then. I'm unqueuing it. >> > > It's not a catch at all, the fact that I saw this warning with an older > kernel for KVM_SET_GSI_ROUTING doesn't mean that I can't patch it with an > upstream kernel. Would you prefer I remove the stack trace completely? The upstream kernel doesn't warn. It checks "if (routing.nr)" before calling vmalloc. Paolo
RE: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
I believe we do have the infrastructure in llvm to implement a working patch. The "asm goto" was introduced as a solution to a problem (optimizing tracepoints/ nop patching). When we started the discussion in llvm about adding this feature, questions arose if we can design a better solution for this problem than "asm goto". You can find a more about the discussion in the llvm community here: http://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.html * This is the middle of the thread, and there are more messages later on. Thanks, Marina -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linux-foundation.org] Sent: Wednesday, February 14, 2018 11:53 To: Chandler Carruth Cc: Yatsina, Marina ; Kees Cook ; David Woodhouse ; Kreitzer, David L ; Grischenko, Andrei L ; r...@google.com; LLVM Developers ; eh...@mozilla.com; Tayree, Coby ; Matthias Braun ; Dean Michael Berris ; James Y Knight ; Guenter Roeck ; X86 ML ; LKML ; Alan Cox ; Rik van Riel ; Andi Kleen ; Josh Poimboeuf ; Tom Lendacky ; Peter Zijlstra ; Linus Torvalds ; Jiri Kosina ; Andy Lutomirski ; Hansen, Dave ; Tim Chen ; Paul Turner ; Stephen Hines ; Nick Desaulniers Subject: Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support) On Wed, Feb 14, 2018 at 08:41:43AM +, Chandler Carruth wrote: > Marina, Kees: > > I think the combination of LKML and the LLVM developer's list is > probably too large a set of folks to have a (somewhat) lengthy > exploration of options and how to go about this and find a good path forward. Why is there any need to discuss "options" here? What is preventing the implementation of "asm goto" in llvm? Is it the lack of a working patch, or something else? thanks, greg k-h - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [PATCH 2/2] vfio: platform: Add generic DT reset support
Hi Geert,
On 14/02/18 10:43, Geert Uytterhoeven wrote:
> Hi Eric,
>
> On Wed, Feb 14, 2018 at 10:09 AM, Auger Eric wrote:
>> On 13/02/18 17:36, Geert Uytterhoeven wrote:
>>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>>> platforms, by a device-specific reset driver matching against the
>>> device's compatible value.
>>>
>>> On many SoCs, devices are connected to an SoC-internal reset controller,
>>> and can be reset in a generic way. Hence add support to reset such
>>> devices using the reset controller subsystem, provided the reset
>>> hierarchy is described correctly in DT using the "resets" property.
>>
>> I first acknowledge I am not familiar with what those reset controllers
>> do in practice. My fear is that we may rely on generic SW pieces that
>> may not be adapted to passthrough constraints. We must guarantee that
>> any DMA access attempted by the devices are stopped and any interrupts
>> gets stopped. Can we guarantee that the reset controller always induce
>> that? Otherwise we may leave the door opened to badly reset assigned
>> devices.
>
> An on-SoC reset controller is basically a block controlling signals to the
> reset inputs of the individual on-SoC devices.
> On Renesas ARM SoCs, this allows to do a full reset of the attached device.
>
> Of course the exact semantics depend on the actual SoC.
that's the issue actually.
> If e.g. DMA and interrupts are not stopped for a specific device on a
> specific SoC, it still needs a device-specific reset driver, matching against
> the appropriate compatible value, cfr. the quoted paragraph below.
yes but by default we still accept the reset controller solution.
>
> You could add a whitelist for of_machine_is_compatible() or
> of_device_is_compatible(), but that will grow large fast.
Could be the kind of solution needed. At the moment the list of assigned
platform devices is pretty reduced.
Couldn't we imagine additional dt properties to emphasize the fact a
platform device is passthrough friendly in terms of reset, either
through a reset controller or exposing a single reg that need to be
reset for full reset to be achieved, in accordance with assignment
constraints. That way, the driver writer would somehow certify the
device is eligible for passthrough. One of the issue today is that the
vfio platform reset driver is not maintained by the native driver
maintainer.
I think if people want to do platform passthrough, they need to devise
their HW IPs so that this reset modality is simplified by exposing this
kind of single reg and then dt description may expose this. Also if
possible, the dt node must be as simple/generic as possible to avoid
writing a huge dt node creation function on QEMU side and avoid
dependencies on other nodes.
>
>>> Devices that require a more complex reset procedure can still
>>> provide a device-specific reset driver, as that takes precedence.
>
>>> @@ -138,6 +152,8 @@ static void vfio_platform_put_reset(struct
>>> vfio_platform_device *vdev)
>>>
>>> if (vdev->of_reset)
>>> module_put(vdev->reset_module);
>>> +
>> if (vdev->reset_control) ?
>> reset_control_put seems to only check IS_ERR()
>
> void reset_control_put(struct reset_control *rstc)
> {
> if (IS_ERR_OR_NULL(rstc))
> return;
>
> So it does handle NULL.
Sorry I checked an older 4.3 kernel version.
Thanks
Eric
>
>>> + reset_control_put(vdev->reset_control);
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
Re: [PATCH 03/11] mmc: kconfig: Remove blank help text
On 1 February 2018 at 18:09, Masahiro Yamada wrote: > 2018-01-31 18:34 GMT+09:00 Ulf Magnusson : >> Blank help texts are probably either a typo, a Kconfig misunderstanding, >> or some kind of half-committing to adding a help text (in which case a >> TODO comment would be clearer, if the help text really can't be added >> right away). >> >> Best to remove them, IMO. >> >> Signed-off-by: Ulf Magnusson >> --- > > > FYI. > > I picked up this patch to kbuild > because I need this to suppress warning messages > introduced by 11/11. Okay. Feel free to add my ack. [...] Kind regards Uffe
[PATCH 0/4] Ux500 crypto: Adjustments for ux500_cryp_probe()
From: Markus Elfring Date: Wed, 14 Feb 2018 11:12:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation Adjust two condition checks Adjust an error message Delete two unnecessary variable initialisations drivers/crypto/ux500/cryp/cryp_core.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) -- 2.16.1
Re: plan9 semantics on Linux - mount namespaces
On 14.02.2018 04:54, Aleksa Sarai wrote: It depends how old your kernel is and what distro you use. Arch Linux > disables user namespaces entirely, Debian requires that you set a sysctl> to enable unprivileged user namespaces, and RHEL requires you to set> both a sysctl and a kernel boot-flag. Also check how old your kernel is> (unprivileged user namespace support was added in 3.8). Just tried on a mainline kernel (4.15). Same problem: root@alphabox:~ unshare -U -r unshare: unshare(0x1400): Invalid argument root@alphabox:/proc/sys/user cat max_user_namespaces 5922 Am I missing something ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
[PATCH 1/4] crypto: ux500: Delete an error message for a failed memory allocation in ux500_cryp_probe()
From: Markus Elfring
Date: Wed, 14 Feb 2018 10:12:38 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/crypto/ux500/cryp/cryp_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c
b/drivers/crypto/ux500/cryp/cryp_core.c
index 765f53e548ab..50bfc7b4c641 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1416,7 +1416,6 @@ static int ux500_cryp_probe(struct platform_device *pdev)
dev_dbg(dev, "[%s]", __func__);
device_data = devm_kzalloc(dev, sizeof(*device_data), GFP_ATOMIC);
if (!device_data) {
- dev_err(dev, "[%s]: kzalloc() failed!", __func__);
ret = -ENOMEM;
goto out;
}
--
2.16.1
[PATCH 2/4] crypto: ux500: Adjust two condition checks in ux500_cryp_probe()
From: Markus Elfring
Date: Wed, 14 Feb 2018 10:38:44 +0100
The local variable "cryp_error" was used only for two condition checks.
* Check the return values from these function calls directly instead.
* Delete this variable which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/crypto/ux500/cryp/cryp_core.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c
b/drivers/crypto/ux500/cryp/cryp_core.c
index 50bfc7b4c641..07cc92f88933 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1404,7 +1404,6 @@ static void cryp_algs_unregister_all(void)
static int ux500_cryp_probe(struct platform_device *pdev)
{
int ret;
- int cryp_error = 0;
struct resource *res = NULL;
struct resource *res_irq = NULL;
struct cryp_device_data *device_data;
@@ -1478,15 +1477,13 @@ static int ux500_cryp_probe(struct platform_device
*pdev)
goto out_clk_unprepare;
}
- cryp_error = cryp_check(device_data);
- if (cryp_error != 0) {
+ if (cryp_check(device_data)) {
dev_err(dev, "[%s]: cryp_init() failed!", __func__);
ret = -EINVAL;
goto out_power;
}
- cryp_error = cryp_configure_protection(device_data, &prot);
- if (cryp_error != 0) {
+ if (cryp_configure_protection(device_data, &prot)) {
dev_err(dev, "[%s]: cryp_configure_protection() failed!",
__func__);
ret = -EINVAL;
--
2.16.1
[PATCH 3/4] crypto: ux500: Adjust an error message in ux500_cryp_probe()
From: Markus Elfring
Date: Wed, 14 Feb 2018 10:47:31 +0100
Replace the function name in this error message so that the same name
is mentioned according to what was called before.
Signed-off-by: Markus Elfring
---
drivers/crypto/ux500/cryp/cryp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c
b/drivers/crypto/ux500/cryp/cryp_core.c
index 07cc92f88933..7c811d7eb274 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1478,7 +1478,7 @@ static int ux500_cryp_probe(struct platform_device *pdev)
}
if (cryp_check(device_data)) {
- dev_err(dev, "[%s]: cryp_init() failed!", __func__);
+ dev_err(dev, "[%s]: cryp_check() failed!", __func__);
ret = -EINVAL;
goto out_power;
}
--
2.16.1
Re: [PATCH 16/18] thunderbolt: Add support for preboot ACL
On Tue, Feb 13, 2018 at 08:19:45PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 13, 2018 at 7:00 PM, Mika Westerberg
> wrote:
> > Preboot ACL is a mechanism that allows connecting Thunderbolt devices
> > boot time in more secure way than the legacy Thunderbolt boot support.
> > As with the legacy boot option, this also needs to be enabled from the
> > BIOS before booting is allowed. Difference to the legacy mode is that
> > the userspace software explicitly adds device UUIDs by sending a special
> > message to the ICM firmware. Only the devices listed in the boot ACL are
> > connected automatically during the boot. This works in both "user" and
> > "secure" security levels.
> >
> > We implement this in Linux by exposing a new sysfs attribute (boot_acl)
> > below each Thunderbolt domain. The userspace software can then update
> > the full list as needed.
>
> > + if (mutex_lock_interruptible(&tb->lock)) {
> > + ret = -ERESTARTSYS;
> > + goto out;
> > + }
>
> > + ret = tb->cm_ops->get_boot_acl(tb, uuids, tb->nboot_acl);
> > + mutex_unlock(&tb->lock);
> > +
> > + if (ret)
> > + goto out;
>
> Can we use more traditional pattern, i.e.
> mutex_lock();
> ret = ...;
> if (ret) {
> ...
> mutex_unlock();
> goto ...;
> }
> mutex_unlock();
>
> ?
OK.
> > + for (ret = 0, i = 0; i < tb->nboot_acl; i++) {
>
> Wouldn't be slightly better to check for overflow beforehand
>
> i < min(PAGE_SIZE / (UUID_STRING_LEN + 1), tb->nboot_acl)
>
> and then simple
>
> ret = sprintf(buf + ret, "%pUb", &uuids[i]);
>
> ?
Well, this follows the common pattern used with formatting sysfs
attributes.
> > + if (!uuid_is_null(&uuids[i]))
> > + ret += snprintf(buf + ret, PAGE_SIZE - ret, "%pUb",
> > + &uuids[i]);
> > +
> > + ret += snprintf(buf + ret, PAGE_SIZE - ret, "%s",
> > + i < tb->nboot_acl - 1 ? "," : "\n");
> > + }
>
>
> > +static ssize_t boot_acl_store(struct device *dev, struct device_attribute
> > *attr,
> > + const char *buf, size_t count)
> > +{
>
> > + int i = 0;
>
> > + uuid_str = strim(str);
>
> > + while ((s = strsep(&uuid_str, ",")) != NULL && i < tb->nboot_acl) {
>
> for (i = 0; (s = strsep(&uuid_str, ",")) != NULL && i < tb->nboot_acl; i++) {
> size_t len = strlen(s);
>
> if (!len)
> continue;
> ...
> }
>
> ?
I think the way it is done in this patch is more readable than what you
are proposing ;-)
> Btw, nboot_acl can be 0, right? Perhaps check it first? (Or in other
> words: which one is anticipated to be more frequent: nboot_acl = 0, or
> string w/o any ',' in it?)
If nboot_acl is 0 the sysfs attribute is not visible at all.
> > + size_t len = strlen(s);
> > +
> > + if (len) {
>
>
> > + if (len != UUID_STRING_LEN) {
> > + ret = -EINVAL;
> > + goto err_free_acl;
> > + }
>
> uuid_parse() does this check. No need to duplicate.
It does not actually. Only thing it checks that the string is at least
UUID_STRING_LEN. If the string is longer it just ignores the rest. We
on the other side want to have strictly UUID_STRING_LEN strings.
Thanks for the comments :)
[PATCH 4/4] crypto: ux500: Delete two unnecessary variable initialisations in ux500_cryp_probe()
From: Markus Elfring
Date: Wed, 14 Feb 2018 10:56:38 +0100
Two local variables will eventually be set to appropriate pointers
a bit later. Thus omit their explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/crypto/ux500/cryp/cryp_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c
b/drivers/crypto/ux500/cryp/cryp_core.c
index 7c811d7eb274..cb31b59c9d53 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1404,8 +1404,8 @@ static void cryp_algs_unregister_all(void)
static int ux500_cryp_probe(struct platform_device *pdev)
{
int ret;
- struct resource *res = NULL;
- struct resource *res_irq = NULL;
+ struct resource *res;
+ struct resource *res_irq;
struct cryp_device_data *device_data;
struct cryp_protection_config prot = {
.privilege_access = CRYP_STATE_ENABLE
--
2.16.1
