Re: [PATCH 1/2] perf tools powerpc: Fix callchain ip filtering
On 04/12/2018 10:41 PM, Sandipan Das wrote:
> For powerpc64, if a probe is added for a function without specifying
> a line number, the corresponding trap instruction is placed at offset
> 0 (for big endian) or 8 (for little endian) from the start address of
> the function. This address is in the function prologue and the trap
> instruction preceeds the instructions to set up the stack frame.
>
> Therefore, at this point during execution, the return address for the
> function is yet to be written to its caller's stack frame. So, the LR
> value at index 2 of the callchain ips provided by the kernel is still
> valid and must not be skipped.
>
> This can be observed on a powerpc64le system running Fedora 27 as
> shown below.
>
> # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton
> # perf record -e probe_libc:inet_pton/max-stack=3/ ping -6 -c 1 ::1
> # perf script
>
> Without this patch, the output is:
>
> ping 27909 [007] 532219.943481: probe_libc:inet_pton: (7fff99b0af28)
>15af28 __GI___inet_pton (/usr/lib64/libc-2.26.so)
>1105b4 getaddrinfo (/usr/lib64/libc-2.26.so)
>
> With this patch applied, the output is:
>
> ping 27909 [007] 532219.943481: probe_libc:inet_pton: (7fff99b0af28)
>15af28 __GI___inet_pton (/usr/lib64/libc-2.26.so)
>10fa54 gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
>1105b4 getaddrinfo (/usr/lib64/libc-2.26.so)
>
> Fixes: a60335ba3298 ("perf tools powerpc: Adjust callchain based on DWARF
> debug info")
> Signed-off-by: Sandipan Das
> ---
This change looks good to me but seems it fixed the issue
partially.Ex,
# readelf --debug-dump=frames-interp /lib64/libc-2.26.so | less
...
5778 0024 577c FDE cie=
pc=00048b30..00048c64
LOC CFA r31 ra
00048b30 r1+0 u u
00048b40 r1+0 c-8 r0
00048b58 r1+64 c-8 c+16
00048bd8 r1+0 c-8 c+16
00048be4 r1+0 u
00048bf0 r1+64 c-8 c+16
00048b30..00048c64 is arandom() function from libc:
00048b30 :
48b30: 1c 00 4c 3c addis r2,r12,28
48b34: d0 e5 42 38 addi r2,r2,-6704
48b38: a6 02 08 7c mflr r0
48b3c: f8 ff e1 fb std r31,-8(r1)
48b40: 00 00 00 60 nop
48b44: 00 00 20 39 li r9,0
48b48: 80 b5 e2 3b addi r31,r2,-19072
48b4c: 01 00 00 39 li r8,1
48b50: 10 00 01 f8 std r0,16(r1)
48b54: c1 ff 21 f8 stdu r1,-64(r1)
48b58: f0 8f 4d e9 ld r10,-28688(r13)
...
Your change fixed the issue for 48b30..48b40. But not for
48b40..48b58.
I probed at 0x48b40.
# ./perf record -g -e probe_libc:abs_48b40 ~/rand
perf report without Suka's and your change:
# Children Self Trace output
# ..
#
100.00% 100.00% (7fffb7d28b40)
|
---0
__libc_start_main
generic_start_main.isra.0
main
rand
__random
perf report with only Suka's change:
# Children Self Trace output
# ..
#
100.00% 100.00% (7fffb7d28b40)
|
---0
__libc_start_main
generic_start_main.isra.0
main
__random
perf report with Suka's and your change:
# Children Self Trace output
# ..
#
100.00% 100.00% (7fffb7d28b40)
|
---0
__libc_start_main
generic_start_main.isra.0
main
__random
I think rand() is a valid entry which is missing in last two cases.
[PATCH 1/2] hfs: fix potential refcnt problem of nls module
When specifying iocharset/codepage multiple times in a mount,
current option parsing will cause inaccurate refcount of nls
module. Hence, call unload_nls for previous one in this case.
Signed-off-by: Chengguang Xu
---
fs/hfs/super.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/hfs/super.c b/fs/hfs/super.c
index 1738767..6a5f6fd 100644
--- a/fs/hfs/super.c
+++ b/fs/hfs/super.c
@@ -329,8 +329,10 @@ static int parse_options(char *options, struct hfs_sb_info
*hsb)
return 0;
}
p = match_strdup(&args[0]);
- if (p)
+ if (p) {
+ unload_nls(hsb->nls_disk);
hsb->nls_disk = load_nls(p);
+ }
if (!hsb->nls_disk) {
pr_err("unable to load codepage \"%s\"\n", p);
kfree(p);
@@ -344,8 +346,10 @@ static int parse_options(char *options, struct hfs_sb_info
*hsb)
return 0;
}
p = match_strdup(&args[0]);
- if (p)
+ if (p) {
+ unload_nls(hsb->nls_io);
hsb->nls_io = load_nls(p);
+ }
if (!hsb->nls_io) {
pr_err("unable to load iocharset \"%s\"\n", p);
kfree(p);
--
1.8.3.1
[PATCH 2/2] hfsplus: fix potential refcnt problem of nls module
When specifying nls option multiple times in a mount,
current option parsing will cause inaccurate refcount of nls
module. Hence, call unload_nls for previous one in this case.
Signed-off-by: Chengguang Xu
---
fs/hfsplus/options.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/hfsplus/options.c b/fs/hfsplus/options.c
index 047e05c..068d4e2 100644
--- a/fs/hfsplus/options.c
+++ b/fs/hfsplus/options.c
@@ -171,8 +171,10 @@ int hfsplus_parse_options(char *input, struct
hfsplus_sb_info *sbi)
return 0;
}
p = match_strdup(&args[0]);
- if (p)
+ if (p) {
+ unload_nls(sbi->nls);
sbi->nls = load_nls(p);
+ }
if (!sbi->nls) {
pr_err("unable to load nls mapping \"%s\"\n",
p);
--
1.8.3.1
Re: [PATCH 3/3] USB: musb: dsps: propagate device-tree node
On Mon, Apr 16, 2018 at 03:03:12PM -0500, Bin Liu wrote: > Johan, > > On Fri, Apr 13, 2018 at 05:15:05PM +0200, Johan Hovold wrote: > > To be able to use DSPS-based controllers with device-tree descriptions > > of the USB topology, we need to associate the glue device's device-tree > > node with the child controller device. > > > > Note that this can also be used to eventually let USB core manage > > generic phys. > > > > Also note that the other glue drivers will require similar changes to be > > able to describe their buses in DT. > > > > Signed-off-by: Johan Hovold > > I will take other two patches for v4.17 rc cycles, but is there any > problem if I take this patch for v4.18-rc1? None at all. That sounds good to me. Thanks, Johan
Re: [PATCH 2/2] f2fs: support {d,id,did,x}node checksum
On 2018/4/17 11:38, Jaegeuk Kim wrote:
> On 04/13, Chao Yu wrote:
>> Ping again..
>>
>> Do you have time to discuss this?
>
> We may need a time to have a chat in person. Do you have any chance to visit
> US?
I prefer to, just count on LSF, but...
I think I need to find a conference which is opened in US first.
Just checked events.linuxfoundation.org, and didn't find any suitable conference
I could attend recently in US.
Location: US
Apr 18-20 Boston, Could Foundry Summit
Apr 23-25 Park City, LSF
Sep 24-26 Nashville, API strategy & practice
Oct 10-11 New York, Open FinTech Forum
Dec 11-13 Seattle, KubeCon & CloudNativeCon
Any other conferences?
Thanks,
>
>>
>> On 2018/2/27 22:16, Chao Yu wrote:
>>> Ping,
>>>
>>> On 2018/2/13 15:34, Chao Yu wrote:
Hi Jaegeuk,
On 2018/2/10 10:52, Chao Yu wrote:
> On 2018/2/10 9:41, Jaegeuk Kim wrote:
>> On 02/01, Chao Yu wrote:
>>>
>>>
>>> On 2018/2/1 6:15, Jaegeuk Kim wrote:
On 01/31, Chao Yu wrote:
> On 2018/1/31 10:02, Jaegeuk Kim wrote:
>> What if we want to add more entries in addition to node_checksum? Do
>> we have
>> to add a new feature flag at every time? How about adding a layout
>> value instead
>
> Hmm.. for previous implementation, IMO, we'd better add a new feature
> flag at
> every time, otherwise, w/ extra_nsize only, in current image, we can
> know a
> valid range of extended area in node block, but we don't know which
> fields/features are valid/enabled or not.
>
> One more thing is that if we can add one feature flag for each field,
> we got one
> more chance to disable it dynamically.
>
>> of extra_nsize? For example, layout #1 means node_checksum with
>> extra_nsize=X?
>>
>>
>> What does 1017 mean? We need to make this structure more flexibly
>> for new
>
> Yes, using raw 1017 is not appropriate here.
>
>> entries. Like this?
>> union {
>> struct node_v1;
>> struct node_v2;
>> struct node_v3;
>> ...
>> struct direct_node dn;
>> struct indirect_node in;
>> };
>> };
>>
>> struct node_v1 {
>> __le32 data[DEF_ADDRS_PER_BLOCK - V1_NSIZE=1];
>> __le32 node_checksum;
>> }
>>
>> struct node_v2 {
>> __le32 data[DEF_ADDRS_PER_BLOCK - V2_NSIZE=500];
>
> Hmm.. If we only need to add one more 4 bytes field in struct
> node_v2, but
> V2_NSIZE is defined as fixed 500, there must be 492 bytes wasted.
>
> Or we can define V2_NSIZE as 8, but if there comes more and more
> extended
> fields, node version count can be a large number, it results in
> complicated
> version recognization and handling.
>
> One more question is how can we control which fields are valid or not
> in
> comp[Vx_NSIZE]?
>
>
> Anyway, what I'm thinking is maybe we can restructure layout of node
> block like
> the one used by f2fs_inode:
>
> struct f2fs_node {
> union {
> struct f2fs_inode i;
> union {
> struct {
> __le32 node_checksum;
> __le32 feature_field_1;
> __le32 feature_field_2;
>
> __le32 addr[];
>
> };
> struct direct_node dn;
> struct indirect_node in;
> };
> };
> struct node_footer footer;
> } __packed;
>
> Moving all extended fields to the head of f2fs_node, so we don't have
> to use
> macro to indicate actual size of addr.
Thinking what'd be the best way. My concern is, once getting more
entries, we
>>>
>>> OK, I think we need more discussion.. ;)
>>>
can't set each of features individually. Like the second entry should
have
>>>
>>> Oh, that will be hard. If we have to avoid that, we have to tag in
>>> somewhere
>>> e.g. f2fs_inode::i_flags2 to indicate which new field in f2fs_node is
>>> valid, for
>>> example:
>>>
>>> #define F2FS_NODE_CHECKSUM 0x0001
>>> #define F2FS_NODE_FIELD10x0002
>>> #define F
Re: [PATCH v4 2/6] mfd: stm32-timers: add support for dmas
On Mon, 16 Apr 2018, Fabrice Gasnier wrote:
> 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 v4:
> - Lee's comments: Add kerneldoc header, better format comments.
> Changes in v3:
> - Basically Lee's comments:
> - rather create a struct stm32_timers_dma, and place a reference to it
> in existing ddata (instead of adding priv struct).
> - rather use a struct device in exported routine prototype, and use
> standard helpers instead of ddata. Get rid of to_stm32_timers_priv().
> - simplify error handling in probe (remove a goto)
> - comment on devm_of_platform_*populate() usage.
>
> 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 | 227
> ++-
> include/linux/mfd/stm32-timers.h | 32 ++
> 2 files changed, 257 insertions(+), 2 deletions(-)
[...]
> diff --git a/include/linux/mfd/stm32-timers.h
> b/include/linux/mfd/stm32-timers.h
> index 2aadab6..a04d7a1 100644
> --- a/include/linux/mfd/stm32-timers.h
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -8,6 +8,8 @@
> #define _LINUX_STM32_GPTIMER_H_
>
> #include
> +#include
> +#include
> #include
[...]
> +struct stm32_timers_dma;
> +
> struct stm32_timers {
> struct clk *clk;
> struct regmap *regmap;
> u32 max_arr;
> + struct stm32_timers_dma *dma; /* Only to be used by the parent */
I'm confused. I thought the point of putting this comment in was so
that you could place the definition of 'stm32_timers_dma' and remove
the forward declaration?
> };
> +
> +int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
> + enum stm32_timers_dmas id, u32 reg,
> + unsigned int num_reg, unsigned int bursts,
> + unsigned long tmo_ms);
> #endif
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH] blkcg: not hold blkcg lock when deactivating policy.
As described in the comment of blkcg_activate_policy(),
*Update of each blkg is protected by both queue and blkcg locks so
that holding either lock and testing blkcg_policy_enabled() is
always enough for dereferencing policy data.*
with queue lock held, there is no need to hold blkcg lock in
blkcg_deactivate_policy(). Similar case is in
blkcg_activate_policy(), which has removed holding of blkcg lock in
commit 4c55f4f9ad3001ac1fefdd8d8ca7641d18558e23.
Signed-off-by: Jiang Biao
Signed-off-by: Wen Yang
CC: Tejun Heo
CC: Jens Axboe
---
block/blk-cgroup.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index c2033a2..2b7f8d0 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1367,17 +1367,12 @@ void blkcg_deactivate_policy(struct request_queue *q,
__clear_bit(pol->plid, q->blkcg_pols);
list_for_each_entry(blkg, &q->blkg_list, q_node) {
- /* grab blkcg lock too while removing @pd from @blkg */
- spin_lock(&blkg->blkcg->lock);
-
if (blkg->pd[pol->plid]) {
if (pol->pd_offline_fn)
pol->pd_offline_fn(blkg->pd[pol->plid]);
pol->pd_free_fn(blkg->pd[pol->plid]);
blkg->pd[pol->plid] = NULL;
}
-
- spin_unlock(&blkg->blkcg->lock);
}
spin_unlock_irq(q->queue_lock);
--
2.7.4
Re: [PATCH 11/25] staging: lustre: libcfs: invert error handling for cfs_cpt_table_print
On Mon, Apr 16, 2018 at 12:09:53AM -0400, James Simmons wrote:
> From: Amir Shehata
>
> Instead of setting rc to -EFBIG for several cases in the loop lets
> initialize rc to -EFBIG and just break out of the loop in case of
> failure. Just set rc to zero once we successfully finish the loop.
>
> Signed-off-by: Amir Shehata
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7734
> Reviewed-on: http://review.whamcloud.com/18916
> Reviewed-by: Olaf Weber
> Reviewed-by: Doug Oucharek
> Signed-off-by: James Simmons
> ---
> .../staging/lustre/lnet/libcfs/linux/linux-cpu.c | 22
> ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> index bbf89b8..6d8dcd3 100644
> --- a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> +++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> @@ -158,29 +158,26 @@ struct cfs_cpt_table *
> cfs_cpt_table_print(struct cfs_cpt_table *cptab, char *buf, int len)
> {
> char *tmp = buf;
> - int rc = 0;
> + int rc = -EFBIG;
> int i;
> int j;
>
> for (i = 0; i < cptab->ctb_nparts; i++) {
> - if (len > 0) {
> - rc = snprintf(tmp, len, "%d\t:", i);
> - len -= rc;
> - }
> + if (len <= 0)
> + goto out;
> +
> + rc = snprintf(tmp, len, "%d\t:", i);
> + len -= rc;
>
> - if (len <= 0) {
> - rc = -EFBIG;
> + if (len <= 0)
> goto out;
This patch says it's a cleanup but the only thing it does is introduce
"forgot to set the error" bugs.
regards,
dan carpenter
Re: [PATCH] x86/xen: Remove use of VLAs
On 16/04/18 15:27, Boris Ostrovsky wrote:
> On 04/13/2018 06:11 PM, Laura Abbott wrote:
>> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
>> turn on -Wvla. The few VLAs in use have an upper bound based on a size
>> of 64K. This doesn't produce an excessively large stack so just switch
>> the upper bound.
>>
>> [1] https://lkml.org/lkml/2018/3/7/621
>>
>> Signed-off-by: Laura Abbott
>> ---
>> arch/x86/xen/enlighten_pv.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>> index c36d23aa6c35..d96a5a535cbb 100644
>> --- a/arch/x86/xen/enlighten_pv.c
>> +++ b/arch/x86/xen/enlighten_pv.c
>> @@ -421,8 +421,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
>> {
>> unsigned long va = dtr->address;
>> unsigned int size = dtr->size + 1;
>> -unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
>
>
>
> Isn't dtr->size always either GDT_SIZE or 0?
GDT_SIZE - 1 :-)
>> -unsigned long frames[pages];
>> +unsigned long frames[DIV_ROUND_UP(SZ_64K, PAGE_SIZE)];
So we could just go with one frame and modify the BUG_ON() further below
accordingly.
Juergen
Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver
On 16/04/2018 16:22, Lorenzo Pieralisi wrote:
> On Mon, Apr 16, 2018 at 03:57:03PM +0200, Daniel Lezcano wrote:
>> On 16/04/2018 14:30, Lorenzo Pieralisi wrote:
>>> On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote:
On 16/04/2018 12:10, Viresh Kumar wrote:
> On 16-04-18, 12:03, Daniel Lezcano wrote:
>> On 16/04/2018 11:50, Viresh Kumar wrote:
>>> On 16-04-18, 11:45, Daniel Lezcano wrote:
Can you elaborate a bit ? I'm not sure to get the point.
>>>
>>> Sure. With your current code on Hikey960 (big/LITTLE), you end up
>>> creating two cooling devices, one for the big cluster and one for
>>> small cluster. Which is the right thing to do, as we also have two
>>> cpufreq cooling devices.
>>>
>>> But with the change Sudeep is referring to, the helper you used to get
>>> cluster id will return 0 (SoC id) for all the 8 CPUs. So your code
>>> will end up creating a single cpuidle cooling device for all the CPUs.
>>> Which would be wrong.
>>
>> Is the semantic of topology_physical_package_id changing ?
>
> That's what I understood from his email.
>
>> I don't
>> understand the change Sudeep is referring to.
Actually there is no impact with the change Sudeep is referring to. It
is for ACPI, we are DT based. Confirmed with Jeremy.
So AFAICT, it is not a problem.
>>>
>>> It is a problem - DT or ACPI alike. Sudeep was referring to the notion
>>> of "cluster" that has no architectural meaning whatsoever and using
>>> topology_physical_package_id() to detect a "cluster" was/is/will always
>>> be the wrong thing to do. The notion of cluster must not appear in the
>>> kernel at all, it has no architectural meaning. I understand you need
>>> to group CPUs but that has to be done in a different way, through
>>> cooling devices, thermal domains or power domains DT/ACPI bindings but
>>> not by using topology masks.
>>
>> I don't get it. What is the cluster concept defined in the ARM
>> documentation?
>>
>> ARM Cortex-A53 MPCore Processor Technical Reference Manual
>>
>> 4.5.2. Multiprocessor Affinity Register
>>
>> I see the documentation says:
>>
>> A cluster with two cores, three cores, ...
>>
>> How the kernel can represent that if you kill the
>> topology_physical_package_id() ?
>
> From an Arm ARM perspective (ARM v8 reference manual), the MPIDR_EL1 has
> no notion of cluster which means that a cluster is not architecturally
> defined on Arm systems.
Sorry, I'm lost :/ You say the MPIDR_EL1 has no notion of cluster but
the documentation describing this register is all talking about cluster.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500g/BABHBJCI.html
> Currently, as Morten explained today, topology_physical_package_id()
> is supposed to represent a "cluster" and that's completely wrong
> because a "cluster" cannot be defined from an architectural perspective.
>
> It was a bodge used as a shortcut, wrongly. We should have never used
> that API for that purpose and there must be no code in the kernel
> relying on:
>
> topology_physical_package_id()
>
> to define a cluster; the information you require to group CPUs must
> come from something else, which is firmware bindings(DT or ACPI) as
> I mentioned.
Why not ?
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index c4f2d50..ac0776d 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -14,7 +14,8 @@ struct cpu_topology {
extern struct cpu_topology cpu_topology[NR_CPUS];
-#define topology_physical_package_id(cpu)
(cpu_topology[cpu].cluster_id)
+#define topology_physical_package_id(cpu) (0)
+#define topology_physical_cluster_id(cpu)
(cpu_topology[cpu].cluster_id)
#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
#define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling)
#define topology_sibling_cpumask(cpu) (&cpu_topology[cpu].thread_sibling)
> Please speak to Sudeep who will fill you on the reasoning above.
Yes, Sudeep is next to me but I would prefer to keep the discussion on
the mailing list so everyone can get the reasoning.
--
Facebook |
Twitter |
Re: KASAN: global-out-of-bounds Write in string
syzbot has found reproducer for the following crash on upstream commit a27fc14219f2e3c4a46ba9177b04d9b52c875532 (Mon Apr 16 21:07:39 2018 +) Merge branch 'parisc-4.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=b890b3335a4d8c608963 So far this crash happened 3 times on upstream. C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4639432657338368 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=5739177354199040 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=5837965024559104 Kernel config: https://syzkaller.appspot.com/x/.config?id=-5914490758943236750 compiler: gcc (GCC) 8.0.1 20180413 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+b890b3335a4d8c608...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop5. == BUG: KASAN: global-out-of-bounds in string+0x291/0x2c0 lib/vsprintf.c:608 Write of size 1 at addr 8a5405c0 by task syzkaller915239/4487 CPU: 1 PID: 4487 Comm: syzkaller915239 Not tainted 4.17.0-rc1+ #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435 string+0x291/0x2c0 lib/vsprintf.c:608 vsnprintf+0x4b7/0x1b40 lib/vsprintf.c:2292 vsprintf+0x2a/0x40 lib/vsprintf.c:2472 prepare_error_buf+0x23b/0x1aa0 fs/reiserfs/prints.c:240 __reiserfs_warning+0xb0/0xd0 fs/reiserfs/prints.c:267 reiserfs_getopt fs/reiserfs/super.c:1044 [inline] reiserfs_parse_options+0x11f4/0x27f0 fs/reiserfs/super.c:1194 reiserfs_fill_super+0x520/0x3900 fs/reiserfs/super.c:1946 mount_bdev+0x30c/0x3e0 fs/super.c:1165 get_super_block+0x34/0x40 fs/reiserfs/super.c:2605 mount_fs+0xae/0x328 fs/super.c:1268 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:1027 [inline] do_new_mount fs/namespace.c:2517 [inline] do_mount+0x564/0x3070 fs/namespace.c:2847 ksys_mount+0x12d/0x140 fs/namespace.c:3063 __do_sys_mount fs/namespace.c:3077 [inline] __se_sys_mount fs/namespace.c:3074 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3074 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x448bca RSP: 002b:7f33571ccc68 EFLAGS: 0202 ORIG_RAX: 00a5 RAX: ffda RBX: 2040 RCX: 00448bca RDX: 2000 RSI: 2040 RDI: 7f33571ccc80 RBP: 0004 R08: 2380 R09: 000a R10: 0100 R11: 0202 R12: 0043 R13: 0044 R14: 0100 R15: 0004 The buggy address belongs to the variable: error_buf+0x400/0x420 Memory state around the buggy address: 8a540480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8a540500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8a540580: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa ^ 8a540600: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa 8a540680: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa ==
Re: [PATCH][next] iwlwifi: mvm: remove division by size of sizeof(struct ieee80211_wmm_rule)
On Wed, 2018-04-11 at 14:05 +0100, Colin King wrote:
> From: Colin Ian King
>
> The subtraction of two struct ieee80211_wmm_rule pointers leaves a
> result
> that is automatically scaled down by the size of the size of pointed-
> to
> type, hence the division by sizeof(struct ieee80211_wmm_rule) is
> bogus and should be removed.
>
> Detected by CoverityScan, CID#146 ("Extra sizeof expression")
>
> Fixes: 77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if
> needed")
> Signed-off-by: Colin Ian King
> ---
Thanks, Colin! I've pushed this to our internal tree for review and if
everything goes fine it will land upstream following our normal
upstreaming process.
--
Cheers,
Luca.
Re: [PATCH 2/2] input: misc: Add Spreadtrum vibrator driver
Hi Xiaotong,
On Tue, Apr 17, 2018 at 11:18:24AM +0800, Baolin Wang wrote:
> From: Xiaotong Lu
[snip]
> +static int sc27xx_vibra_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct vibra_info *info;
> + int ret;
> +
> + info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + info->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!info->regmap) {
> + dev_err(&pdev->dev, "failed to get vibrator regmap.\n");
> + return -ENODEV;
> + }
> +
> + ret = of_property_read_u32(node, "reg", &info->base);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to get vibrator base address.\n");
> + return ret;
> + }
> +
> + info->input_dev = devm_input_allocate_device(&pdev->dev);
> + if (!info->input_dev) {
> + dev_err(&pdev->dev, "failed to allocate input device.\n");
> + return -ENOMEM;
> + }
> +
> + info->input_dev->name = "sc27xx:vibrator";
> + info->input_dev->id.version = 0;
> + info->input_dev->dev.parent = pdev->dev.parent;
> + info->input_dev->close = sc27xx_vibra_close;
> +
> + input_set_drvdata(info->input_dev, info);
> + input_set_capability(info->input_dev, EV_FF, FF_RUMBLE);
> + INIT_WORK(&info->play_work, sc27xx_vibra_play_work);
> + info->enabled = false;
> +
> + ret = input_ff_create_memless(info->input_dev, NULL, sc27xx_vibra_play);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register vibrator to FF.\n");
> + return ret;
> + }
> +
> + ret = input_register_device(info->input_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register input device.\n");
> + input_ff_destroy(info->input_dev);
I'm not sure how the input_ff is freed for managed devices.
Either you don't have to destroy it here, or you also need to destroy it
in a release() function.
> + return ret;
> + }
> +
> + ret = sc27xx_vibra_hw_init(info);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize the vibrator.\n");
> + input_ff_destroy(info->input_dev);
> + input_unregister_device(info->input_dev);
No need to unregister managed input devices.
> + return ret;
> + }
Cheers,
Marcus Folkesson
Re: [PATCH 1/6] cifs: smbd: Check for iov length on sending the last iov
On Mon, Apr 16, 2018 at 05:49:13PM -0700, Long Li wrote: > From: Long Li > > When sending the last iov that breaks into smaller buffers to fit the > transfer size, it's necessary to check if this is the last iov. > > If this is the latest iov, stop and proceed to send pages. > > Signed-off-by: Long Li > --- > fs/cifs/smbdirect.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c > index 90e673c..b5c6c0d 100644 > --- a/fs/cifs/smbdirect.c > +++ b/fs/cifs/smbdirect.c > @@ -2197,6 +2197,8 @@ int smbd_send(struct smbd_connection *info, struct > smb_rqst *rqst) > goto done; > } > i++; > + if (i == rqst->rq_nvec) > + break; > } > start = i; > buflen = 0; > -- > 2.7.4 This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
Re: [PATCH 3/6] cifs: smbd: Avoid allocating iov on the stack
On Mon, Apr 16, 2018 at 05:49:15PM -0700, Long Li wrote:
> From: Long Li
>
> It's not necessary to allocate another iov when going through the buffers
> in smbd_send() through RDMA send.
>
> Remove it to reduce stack size.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/smbdirect.c | 36
> 1 file changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
> index b5c6c0d..f575e9a 100644
> --- a/fs/cifs/smbdirect.c
> +++ b/fs/cifs/smbdirect.c
> @@ -2088,7 +2088,7 @@ int smbd_send(struct smbd_connection *info, struct
> smb_rqst *rqst)
> int start, i, j;
> int max_iov_size =
> info->max_send_size - sizeof(struct smbd_data_transfer);
> - struct kvec iov[SMBDIRECT_MAX_SGE];
> + struct kvec *iov;
> int rc;
>
> info->smbd_send_pending++;
> @@ -2099,32 +2099,20 @@ int smbd_send(struct smbd_connection *info, struct
> smb_rqst *rqst)
> }
>
> /*
> - * This usually means a configuration error
> - * We use RDMA read/write for packet size > rdma_readwrite_threshold
> - * as long as it's properly configured we should never get into this
> - * situation
> - */
> - if (rqst->rq_nvec + rqst->rq_npages > SMBDIRECT_MAX_SGE) {
> - log_write(ERR, "maximum send segment %x exceeding %x\n",
> - rqst->rq_nvec + rqst->rq_npages, SMBDIRECT_MAX_SGE);
> - rc = -EINVAL;
> - goto done;
> - }
> -
> - /*
> - * Remove the RFC1002 length defined in MS-SMB2 section 2.1
> - * It is used only for TCP transport
> + * Skip the RFC1002 length defined in MS-SMB2 section 2.1
> + * It is used only for TCP transport in the iov[0]
>* In future we may want to add a transport layer under protocol
>* layer so this will only be issued to TCP transport
>*/
> - iov[0].iov_base = (char *)rqst->rq_iov[0].iov_base + 4;
> - iov[0].iov_len = rqst->rq_iov[0].iov_len - 4;
> - buflen += iov[0].iov_len;
> +
> + if (rqst->rq_iov[0].iov_len != 4) {
> + log_write(ERR, "expected the pdu length in 1st iov, but got
> 0x%lu\n", rqst->rq_iov[0].iov_len);
> + return -EINVAL;
> + }
> + iov = &rqst->rq_iov[1];
>
> /* total up iov array first */
> - for (i = 1; i < rqst->rq_nvec; i++) {
> - iov[i].iov_base = rqst->rq_iov[i].iov_base;
> - iov[i].iov_len = rqst->rq_iov[i].iov_len;
> + for (i = 0; i < rqst->rq_nvec-1; i++) {
> buflen += iov[i].iov_len;
> }
>
> @@ -2197,14 +2185,14 @@ int smbd_send(struct smbd_connection *info, struct
> smb_rqst *rqst)
> goto done;
> }
> i++;
> - if (i == rqst->rq_nvec)
> + if (i == rqst->rq_nvec-1)
> break;
> }
> start = i;
> buflen = 0;
> } else {
> i++;
> - if (i == rqst->rq_nvec) {
> + if (i == rqst->rq_nvec-1) {
> /* send out all remaining vecs */
> remaining_data_length -= buflen;
> log_write(INFO,
> --
> 2.7.4
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 5/6] cifs: smbd: Enable signing with smbdirect
On Mon, Apr 16, 2018 at 05:49:17PM -0700, Long Li wrote:
> From: Long Li
>
> Now signing is supported with RDMA transport.
>
> Remove the code that disabled it.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/connect.c | 8
> fs/cifs/smb2pdu.c | 4
> 2 files changed, 12 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index e8830f0..deef270 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -1977,14 +1977,6 @@ cifs_parse_mount_options(const char *mountdata, const
> char *devname,
> goto cifs_parse_mount_err;
> }
>
> -#ifdef CONFIG_CIFS_SMB_DIRECT
> - if (vol->rdma && vol->sign) {
> - cifs_dbg(VFS, "Currently SMB direct doesn't support signing."
> - " This is being fixed\n");
> - goto cifs_parse_mount_err;
> - }
> -#endif
> -
> #ifndef CONFIG_KEYS
> /* Muliuser mounts require CONFIG_KEYS support */
> if (vol->multiuser) {
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 6759035..d71ce51 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -737,10 +737,6 @@ int smb3_validate_negotiate(const unsigned int xid,
> struct cifs_tcon *tcon)
>
> cifs_dbg(FYI, "validate negotiate\n");
>
> -#ifdef CONFIG_CIFS_SMB_DIRECT
> - if (tcon->ses->server->rdma)
> - return 0;
> -#endif
> pneg_inbuf = kmalloc(sizeof(*pneg_inbuf), GFP_KERNEL);
> if (!pneg_inbuf)
> return -ENOMEM;
> --
> 2.7.4
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 2/6] cifs: Allocate validate negoation request through kmalloc
On Mon, Apr 16, 2018 at 05:49:14PM -0700, Long Li wrote:
> From: Long Li
>
> The data buffer allocated on the stack can't be DMA'ed, and hence can't send
> through RDMA via SMB Direct.
>
> Fix this by allocating the request on the heap in smb3_validate_negotiate.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/smb2pdu.c | 38 ++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 0f044c4..abbefe2 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -730,7 +730,7 @@ SMB2_negotiate(const unsigned int xid, struct cifs_ses
> *ses)
> int smb3_validate_negotiate(const unsigned int xid, struct cifs_tcon *tcon)
> {
> int rc = 0;
> - struct validate_negotiate_info_req vneg_inbuf;
> + struct validate_negotiate_info_req *pneg_inbuf;
> struct validate_negotiate_info_rsp *pneg_rsp = NULL;
> u32 rsplen;
> u32 inbuflen; /* max of 4 dialects */
> @@ -741,6 +741,9 @@ int smb3_validate_negotiate(const unsigned int xid,
> struct cifs_tcon *tcon)
> if (tcon->ses->server->rdma)
> return 0;
> #endif
> + pneg_inbuf = kmalloc(sizeof(*pneg_inbuf), GFP_KERNEL);
> + if (!pneg_inbuf)
> + return -ENOMEM;
>
> /* In SMB3.11 preauth integrity supersedes validate negotiate */
> if (tcon->ses->server->dialect == SMB311_PROT_ID)
> @@ -764,52 +767,53 @@ int smb3_validate_negotiate(const unsigned int xid,
> struct cifs_tcon *tcon)
> if (tcon->ses->session_flags & SMB2_SESSION_FLAG_IS_NULL)
> cifs_dbg(VFS, "Unexpected null user (anonymous) auth flag sent
> by server\n");
>
> - vneg_inbuf.Capabilities =
> + pneg_inbuf->Capabilities =
> cpu_to_le32(tcon->ses->server->vals->req_capabilities);
> - memcpy(vneg_inbuf.Guid, tcon->ses->server->client_guid,
> + memcpy(pneg_inbuf->Guid, tcon->ses->server->client_guid,
> SMB2_CLIENT_GUID_SIZE);
>
> if (tcon->ses->sign)
> - vneg_inbuf.SecurityMode =
> + pneg_inbuf->SecurityMode =
> cpu_to_le16(SMB2_NEGOTIATE_SIGNING_REQUIRED);
> else if (global_secflags & CIFSSEC_MAY_SIGN)
> - vneg_inbuf.SecurityMode =
> + pneg_inbuf->SecurityMode =
> cpu_to_le16(SMB2_NEGOTIATE_SIGNING_ENABLED);
> else
> - vneg_inbuf.SecurityMode = 0;
> + pneg_inbuf->SecurityMode = 0;
>
>
> if (strcmp(tcon->ses->server->vals->version_string,
> SMB3ANY_VERSION_STRING) == 0) {
> - vneg_inbuf.Dialects[0] = cpu_to_le16(SMB30_PROT_ID);
> - vneg_inbuf.Dialects[1] = cpu_to_le16(SMB302_PROT_ID);
> - vneg_inbuf.DialectCount = cpu_to_le16(2);
> + pneg_inbuf->Dialects[0] = cpu_to_le16(SMB30_PROT_ID);
> + pneg_inbuf->Dialects[1] = cpu_to_le16(SMB302_PROT_ID);
> + pneg_inbuf->DialectCount = cpu_to_le16(2);
> /* structure is big enough for 3 dialects, sending only 2 */
> inbuflen = sizeof(struct validate_negotiate_info_req) - 2;
> } else if (strcmp(tcon->ses->server->vals->version_string,
> SMBDEFAULT_VERSION_STRING) == 0) {
> - vneg_inbuf.Dialects[0] = cpu_to_le16(SMB21_PROT_ID);
> - vneg_inbuf.Dialects[1] = cpu_to_le16(SMB30_PROT_ID);
> - vneg_inbuf.Dialects[2] = cpu_to_le16(SMB302_PROT_ID);
> - vneg_inbuf.DialectCount = cpu_to_le16(3);
> + pneg_inbuf->Dialects[0] = cpu_to_le16(SMB21_PROT_ID);
> + pneg_inbuf->Dialects[1] = cpu_to_le16(SMB30_PROT_ID);
> + pneg_inbuf->Dialects[2] = cpu_to_le16(SMB302_PROT_ID);
> + pneg_inbuf->DialectCount = cpu_to_le16(3);
> /* structure is big enough for 3 dialects */
> inbuflen = sizeof(struct validate_negotiate_info_req);
> } else {
> /* otherwise specific dialect was requested */
> - vneg_inbuf.Dialects[0] =
> + pneg_inbuf->Dialects[0] =
> cpu_to_le16(tcon->ses->server->vals->protocol_id);
> - vneg_inbuf.DialectCount = cpu_to_le16(1);
> + pneg_inbuf->DialectCount = cpu_to_le16(1);
> /* structure is big enough for 3 dialects, sending only 1 */
> inbuflen = sizeof(struct validate_negotiate_info_req) - 4;
> }
>
> rc = SMB2_ioctl(xid, tcon, NO_FILE_ID, NO_FILE_ID,
> FSCTL_VALIDATE_NEGOTIATE_INFO, true /* is_fsctl */,
> - (char *)&vneg_inbuf, sizeof(struct validate_negotiate_info_req),
> + (char *)pneg_inbuf, sizeof(struct validate_negotiate_info_req),
> (char **)&pneg_rsp, &rsplen);
>
> if (rc != 0) {
> cifs_dbg(VFS, "validate protocol negotiate failed: %d\n", rc);
> + kfree(pneg_inbuf);
> return -
Re: [PATCH 6/6] cifs: smbd: Dump SMB packet when configured
On Mon, Apr 16, 2018 at 05:49:18PM -0700, Long Li wrote:
> From: Long Li
>
> When sending through SMB Direct, also dump the packet in SMB send path.
>
> Also fixed a typo in debug message.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/smbdirect.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
> index f575e9a..6ff864a 100644
> --- a/fs/cifs/smbdirect.c
> +++ b/fs/cifs/smbdirect.c
> @@ -1029,7 +1029,7 @@ static int smbd_post_send(struct smbd_connection *info,
> for (i = 0; i < request->num_sge; i++) {
> log_rdma_send(INFO,
> "rdma_request sge[%d] addr=%llu length=%u\n",
> - i, request->sge[0].addr, request->sge[0].length);
> + i, request->sge[i].addr, request->sge[i].length);
> ib_dma_sync_single_for_device(
> info->id->device,
> request->sge[i].addr,
> @@ -2130,6 +2130,10 @@ int smbd_send(struct smbd_connection *info, struct
> smb_rqst *rqst)
> goto done;
> }
>
> + cifs_dbg(FYI, "Sending smb (RDMA): smb_len=%u\n", buflen);
> + for (i = 0; i < rqst->rq_nvec-1; i++)
> + dump_smb(iov[i].iov_base, iov[i].iov_len);
> +
> remaining_data_length = buflen;
>
> log_write(INFO, "rqst->rq_nvec=%d rqst->rq_npages=%d rq_pagesz=%d "
> --
> 2.7.4
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 4/6] cifs: smbd: Don't use RDMA read/write when signing is used
On Mon, Apr 16, 2018 at 05:49:16PM -0700, Long Li wrote:
> From: Long Li
>
> SMB server will not sign data transferred through RDMA read/write. When
> signing is used, it's a good idea to have all the data signed.
>
> In this case, use RDMA send/recv for all data transfers. This will degrade
> performance as this is not generally configured in RDMA environemnt. So
> warn the user on signing and RDMA send/recv.
>
> Signed-off-by: Long Li
> ---
> fs/cifs/cifssmb.c | 3 +++
> fs/cifs/smb2ops.c | 18 ++
> fs/cifs/smb2pdu.c | 4 ++--
> 3 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
> index 6d3e40d..1529a08 100644
> --- a/fs/cifs/cifssmb.c
> +++ b/fs/cifs/cifssmb.c
> @@ -455,6 +455,9 @@ cifs_enable_signing(struct TCP_Server_Info *server, bool
> mnt_sign_required)
> server->sign = true;
> }
>
> + if (cifs_rdma_enabled(server) && server->sign)
> + cifs_dbg(VFS, "Signing is enabled, and RDMA read/write will be
> disabled");
> +
> return 0;
> }
>
> diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
> index 38ebf3f..b76b858 100644
> --- a/fs/cifs/smb2ops.c
> +++ b/fs/cifs/smb2ops.c
> @@ -252,9 +252,14 @@ smb2_negotiate_wsize(struct cifs_tcon *tcon, struct
> smb_vol *volume_info)
> wsize = volume_info->wsize ? volume_info->wsize : CIFS_DEFAULT_IOSIZE;
> wsize = min_t(unsigned int, wsize, server->max_write);
> #ifdef CONFIG_CIFS_SMB_DIRECT
> - if (server->rdma)
> - wsize = min_t(unsigned int,
> + if (server->rdma) {
> + if (server->sign)
> + wsize = min_t(unsigned int,
> + wsize,
> server->smbd_conn->max_fragmented_send_size);
> + else
> + wsize = min_t(unsigned int,
> wsize, server->smbd_conn->max_readwrite_size);
> + }
> #endif
> if (!(server->capabilities & SMB2_GLOBAL_CAP_LARGE_MTU))
> wsize = min_t(unsigned int, wsize, SMB2_MAX_BUFFER_SIZE);
> @@ -272,9 +277,14 @@ smb2_negotiate_rsize(struct cifs_tcon *tcon, struct
> smb_vol *volume_info)
> rsize = volume_info->rsize ? volume_info->rsize : CIFS_DEFAULT_IOSIZE;
> rsize = min_t(unsigned int, rsize, server->max_read);
> #ifdef CONFIG_CIFS_SMB_DIRECT
> - if (server->rdma)
> - rsize = min_t(unsigned int,
> + if (server->rdma) {
> + if (server->sign)
> + rsize = min_t(unsigned int,
> + rsize,
> server->smbd_conn->max_fragmented_recv_size);
> + else
> + rsize = min_t(unsigned int,
> rsize, server->smbd_conn->max_readwrite_size);
> + }
> #endif
>
> if (!(server->capabilities & SMB2_GLOBAL_CAP_LARGE_MTU))
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index abbefe2..6759035 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -2596,7 +2596,7 @@ smb2_new_read_req(void **buf, unsigned int *total_len,
>* If we want to do a RDMA write, fill in and append
>* smbd_buffer_descriptor_v1 to the end of read request
>*/
> - if (server->rdma && rdata &&
> + if (server->rdma && rdata && !server->sign &&
> rdata->bytes >= server->smbd_conn->rdma_readwrite_threshold) {
>
> struct smbd_buffer_descriptor_v1 *v1;
> @@ -2974,7 +2974,7 @@ smb2_async_writev(struct cifs_writedata *wdata,
>* If we want to do a server RDMA read, fill in and append
>* smbd_buffer_descriptor_v1 to the end of write request
>*/
> - if (server->rdma && wdata->bytes >=
> + if (server->rdma && !server->sign && wdata->bytes >=
> server->smbd_conn->rdma_readwrite_threshold) {
>
> struct smbd_buffer_descriptor_v1 *v1;
> --
> 2.7.4
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
v4.17-rc1 on motorola droid d4: WARN_ON from drivers/gpu/drm/omapdrm/dss/hdmi4.c
Hi! While playing with screensaver on droid4: [ 1047.117462] omap-mcbsp 40124000.mcbsp: CLKS: could not clk_set_parent() to prcm_fck [ 1047.130432] [ cut here ] [ 1047.135559] WARNING: CPU: 1 PID: 2942 at drivers/gpu/drm/omapdrm/dss/hdmi4.c:667 hdmi_audio_stop+0x5c/0x68 [ 1047.145294] Modules linked in: [ 1047.148376] CPU: 1 PID: 2942 Comm: pulseaudio Not tainted 4.17.0-rc1-73412-g8f3e00d-dirty #623 [ 1047.157043] Hardware name: Generic OMAP4 (Flattened Device Tree) [ 1047.163085] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 1047.170898] [] (show_stack) from [] (dump_stack+0xa8/0xe0) [ 1047.178161] [] (dump_stack) from [] (__warn+0xf8/0x124) [ 1047.185180] [] (__warn) from [] (warn_slowpath_null+0x3c/0x48) [ 1047.192962] [] (warn_slowpath_null) from [] (hdmi_audio_stop+0x5c/0x68) [ 1047.192993] [] (hdmi_audio_stop) from [] (hdmi_dai_trigger+0x6c/0x88) [ 1047.193023] [] (hdmi_dai_trigger) from [] (soc_pcm_trigger+0x140/0x184) [ 1047.193023] [] (soc_pcm_trigger) from [] (snd_pcm_do_stop+0x54/0x58) [ 1047.193054] [] (snd_pcm_do_stop) from [] (snd_pcm_action_single+0x38/0x78) [ 1047.193054] [] (snd_pcm_action_single) from [] (snd_pcm_drop+0x48/0x94) [ 1047.193054] [] (snd_pcm_drop) from [] (snd_pcm_ioctl+0x8e0/0x1308) [ 1047.193084] [] (snd_pcm_ioctl) from [] (do_vfs_ioctl+0x84/0xa70) [ 1047.193084] [] (do_vfs_ioctl) from [] (ksys_ioctl+0x5c/0x80) [ 1047.193115] [] (ksys_ioctl) from [] (ret_fast_syscall+0x0/0x28) [ 1047.193115] Exception stack(0xecfc1fa8 to 0xecfc1ff0) [ 1047.193115] 1fa0: 00562308 b1986394 0015 4143 00562e20 [ 1047.193115] 1fc0: 00562308 b1986394 0053d4e0 0036 000e b6fdbce8 00507d80 bed64644 [ 1047.193145] 1fe0: b19867c4 bed644c4 b1916be7 b6c8e716 [ 1047.193145] irq event stamp: 60448 [ 1047.193145] hardirqs last enabled at (60447): [] ktime_get_ts64+0x19c/0x1dc [ 1047.193176] hardirqs last disabled at (60448): [] snd_pcm_stream_lock_irq+0x24/0x34 [ 1047.193176] softirqs last enabled at (60078): [] __do_softirq+0x2e0/0x59c [ 1047.193176] softirqs last disabled at (60031): [] irq_exit+0x144/0x194 [ 1047.193206] ---[ end trace 07b005c418b9f99b ]--- [ 1062.235626] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 1092.313934] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] xen: xenbus_dev_frontend: Really return response string
On 15/03/18 04:08, Simon Gaiser wrote:
> xenbus_command_reply() did not actually copy the response string and
> leaked stack content instead.
>
> Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response
> instead of rc")
> Signed-off-by: Simon Gaiser
Reviewed-by: Juergen Gross
Juergen
Re: [PATCH v3 03/11] iio: Add channel for Position Relative
On 15.04.2018 22:29, Jonathan Cameron wrote: On Tue, 10 Apr 2018 11:57:49 +0300 Eugen Hristev wrote: Add new channel type for relative position on a pad. These type of analog sensor offers the position of a pen on a touchpad, and is represented as a voltage, which can be converted to a position on X and Y axis on the pad. The channel will hand the relative position on the pad in both directions. The channel can then be consumed by a touchscreen driver or read as-is for a raw indication of the touchpen on a touchpad. Signed-off-by: Eugen Hristev --- Changes in v2: - modified channel name to relative position as suggested. - modified kernel version to 4.18 (presumable) Documentation/ABI/testing/sysfs-bus-iio | 12 drivers/iio/industrialio-core.c | 1 + include/uapi/linux/iio/types.h | 1 + tools/iio/iio_event_monitor.c | 2 ++ 4 files changed, 16 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6a5f34b..42a9287 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -190,6 +190,18 @@ Description: but should match other such assignments on device). Units after application of scale and offset are m/s^2. +What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw +KernelVersion: 4.18 +Contact: linux-...@vger.kernel.org +Description: + Relative position in direction x or y on a pad (may be + arbitrarily assigned but should match other such assignments on + device). + Units after application of scale and offset are milli percents + from the pad's size in both directions. Should be calibrated by + the consumer. I know the milli percent comes form the humidity equivalent, but I wonder if we are right to follow that. 10^-5 is a pretty random base unit (though I got argued into it being a standard choice for humidity sensors IIRC... What do people think? We could go with 1 for full range or just percent perhaps? I'm not that fussed about staying consistent with humidity - we are unlikely to end up with sensors doing both anytime soon so there shouldn't be any confusion... Jonathan Hello Jonathan, For my specific use case, percents are not enough, as this would mean the resolution will be pretty low. If we have a touchpanel of a higher resolution, having the position only ranged 0 to 100 is pretty bad. Having millipercents means we can have a resolution up to 100,000 points in range, which is fine for the hardware as of this moment. Of course, specific drivers reporting these channels can define a specific range if they desire (report just in the first percent if you wish (0-1000) or so, which would mean a lower resolution. Centi-percent would work fine as well I believe (0-10,000 range), but to keep consistent with your suggestion regarding relative humidity, I picked this larger scale. In my specific case, since we have a 12 bit ADC, range is 0-4096 for this value. Calibrating these values to the actual size of the touchpanel is left for the consumer to do (map 4096x4096 to the actual resolution) If you have a better idea than milli-percents I can change it, no problem. Eugen + [...]
Re: [PATCH] MAINTAINERS: Update e-mail address for Christoffer Dall
On 16/04/18 19:28, Christoffer Dall wrote: > Update my e-mail address to a working address. > > Signed-off-by: Christoffer Dall > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0a1410d5a621..3e9c99d2620b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7738,7 +7738,7 @@ F: arch/x86/include/asm/svm.h > F: arch/x86/kvm/svm.c > > KERNEL VIRTUAL MACHINE FOR ARM (KVM/arm) > -M: Christoffer Dall > +M: Christoffer Dall > M: Marc Zyngier > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > L: kvm...@lists.cs.columbia.edu > @@ -7752,7 +7752,7 @@ F: virt/kvm/arm/ > F: include/kvm/arm_* > > KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64) > -M: Christoffer Dall > +M: Christoffer Dall > M: Marc Zyngier > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > L: kvm...@lists.cs.columbia.edu > I'll queue this as a fix for the next -rc. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 17/25] staging: lustre: libcfs: rename goto label in cfs_cpt_table_print
> diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> index ae5ff58..435ee8e 100644
> --- a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> +++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
> @@ -161,20 +161,20 @@ int cfs_cpt_table_print(struct cfs_cpt_table *cptab,
> char *buf, int len)
>
> for (i = 0; i < cptab->ctb_nparts; i++) {
> if (len <= 0)
> - goto out;
> + goto err;
>
> rc = snprintf(tmp, len, "%d\t:", i);
> len -= rc;
>
> if (len <= 0)
> - goto out;
> + goto err;
Labels should say what the goto does. In this case, it's a do-nothing
goto with a "forgot to set the error code" bug.
regards,
dan carpenter
[PATCH 5/7] powerpc/lib: optimise 32 bits __clear_user()
Rewrite clear_user() on the same principle as memset(0), making use of dcbz to clear complete cache lines. This code is a copy/paste of memset(), with some modifications in order to retrieve remaining number of bytes to be cleared, as it needs to be returned in case of error. On a MPC885, throughput is almost doubled: Before: ~# dd if=/dev/zero of=/dev/null bs=1M count=1000 1048576000 bytes (1000.0MB) copied, 18.990779 seconds, 52.7MB/s After: ~# dd if=/dev/zero of=/dev/null bs=1M count=1000 1048576000 bytes (1000.0MB) copied, 9.611468 seconds, 104.0MB/s On a MPC8321, throughput is multiplied by 2.12: Before: root@vgoippro:~# dd if=/dev/zero of=/dev/null bs=1M count=1000 1048576000 bytes (1000.0MB) copied, 6.844352 seconds, 146.1MB/s After: root@vgoippro:~# dd if=/dev/zero of=/dev/null bs=1M count=1000 1048576000 bytes (1000.0MB) copied, 3.218854 seconds, 310.7MB/s Signed-off-by: Christophe Leroy --- arch/powerpc/lib/string_32.S | 85 +++- 1 file changed, 60 insertions(+), 25 deletions(-) diff --git a/arch/powerpc/lib/string_32.S b/arch/powerpc/lib/string_32.S index 5b2a73fb07be..31fc92b0aae6 100644 --- a/arch/powerpc/lib/string_32.S +++ b/arch/powerpc/lib/string_32.S @@ -11,6 +11,7 @@ #include #include #include +#include .text @@ -61,44 +62,78 @@ _GLOBAL(memcmp) #endif EXPORT_SYMBOL(memcmp) +CACHELINE_BYTES = L1_CACHE_BYTES +LG_CACHELINE_BYTES = L1_CACHE_SHIFT +CACHELINE_MASK = (L1_CACHE_BYTES-1) + _GLOBAL(__clear_user) - addir6,r3,-4 - li r3,0 - li r5,0 - cmplwi 0,r4,4 +/* + * Use dcbz on the complete cache lines in the destination + * to set them to zero. This requires that the destination + * area is cacheable. + */ + cmplwi cr0, r4, 4 + mr r10, r3 + li r3, 0 blt 7f - /* clear a single word */ -11:stwur5,4(r6) + +11:stw r3, 0(r10) beqlr - /* clear word sized chunks */ - andi. r0,r6,3 - add r4,r0,r4 - subfr6,r0,r6 - srwir0,r4,2 - andi. r4,r4,3 + andi. r0, r10, 3 + add r11, r0, r4 + subfr6, r0, r10 + + clrlwi r7, r6, 32 - LG_CACHELINE_BYTES + add r8, r7, r11 + srwir9, r8, LG_CACHELINE_BYTES + addic. r9, r9, -1 /* total number of complete cachelines */ + ble 2f + xorir0, r7, CACHELINE_MASK & ~3 + srwi. r0, r0, 2 + beq 3f + mtctr r0 +4: stwur3, 4(r6) + bdnz4b +3: mtctr r9 + li r7, 4 +10:dcbzr7, r6 + addir6, r6, CACHELINE_BYTES + bdnz10b + clrlwi r11, r8, 32 - LG_CACHELINE_BYTES + addir11, r11, 4 + +2: srwir0 ,r11 ,2 mtctr r0 - bdz 7f -1: stwur5,4(r6) + bdz 6f +1: stwur3, 4(r6) bdnz1b - /* clear byte sized chunks */ -7: cmpwi 0,r4,0 +6: andi. r11, r11, 3 beqlr - mtctr r4 - addir6,r6,3 -8: stbur5,1(r6) + mtctr r11 + addir6, r6, 3 +8: stbur3, 1(r6) bdnz8b blr -90:mr r3,r4 + +7: cmpwi cr0, r4, 0 + beqlr + mtctr r4 + addir6, r10, -1 +9: stbur3, 1(r6) + bdnz9b blr -91:mfctr r3 - slwir3,r3,2 - add r3,r3,r4 + +90:mr r3, r4 blr -92:mfctr r3 +91:add r3, r10, r4 + subfr3, r6, r3 blr EX_TABLE(11b, 90b) + EX_TABLE(4b, 91b) + EX_TABLE(10b, 91b) EX_TABLE(1b, 91b) - EX_TABLE(8b, 92b) + EX_TABLE(8b, 91b) + EX_TABLE(9b, 91b) EXPORT_SYMBOL(__clear_user) -- 2.13.3
[PATCH 7/7] powerpc/lib: Remove .balign inside string functions for PPC32
commit 87a156fb18fe1 ("Align hot loops of some string functions")
degraded the performance of string functions by adding useless
nops
A simple benchmark on an 8xx calling 10x a memchr() that
matches the first byte runs in 41668 TB ticks before this patch
and in 35986 TB ticks after this patch. So this gives an
improvement of approx 10%
Another benchmark doing the same with a memchr() matching the 128th
byte runs in 1011365 TB ticks before this patch and 1005682 TB ticks
after this patch, so regardless on the number of loops, removing
those useless nops improves the test by 5683 TB ticks.
Fixes: 87a156fb18fe1 ("Align hot loops of some string functions")
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/string.S | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S
index 89af53b08b4a..9e96f1c102c6 100644
--- a/arch/powerpc/lib/string.S
+++ b/arch/powerpc/lib/string.S
@@ -25,7 +25,9 @@ _GLOBAL(strncpy)
mtctr r5
addir6,r3,-1
addir4,r4,-1
+#ifdef CONFIG_PPC64
.balign 16
+#endif
1: lbzur0,1(r4)
cmpwi 0,r0,0
stbur0,1(r6)
@@ -47,7 +49,9 @@ _GLOBAL(strncmp)
mtctr r5
addir5,r3,-1
addir4,r4,-1
+#ifdef CONFIG_PPC64
.balign 16
+#endif
1: lbzur3,1(r5)
cmpwi 1,r3,0
lbzur0,1(r4)
@@ -68,7 +72,9 @@ _GLOBAL(memchr)
#endif
mtctr r5
addir3,r3,-1
+#ifdef CONFIG_PPC64
.balign 16
+#endif
1: lbzur0,1(r3)
cmpw0,r0,r4
bdnzf 2,1b
--
2.13.3
atmel_mxt_ts on droid4: powersave seems to break the driver
HI! v4.17-rc1 on motorola droid 4. If I disable/reenable touschreen with xinput, it fails, with this in the logs: [ 1633.749450] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 1655.938751] atmel_mxt_ts 1-004a: __mxt_read_reg: i2c transfer failed (-121) [ 1655.945800] atmel_mxt_ts 1-004a: Failed to read T44 and T5 (-121) [ 1663.829498] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host Unfortunately, xscreensaver seems to break it in a similar way. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4 2/6] mfd: stm32-timers: add support for dmas
On 04/17/2018 09:12 AM, Lee Jones wrote:
> On Mon, 16 Apr 2018, Fabrice Gasnier wrote:
>
>> 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 v4:
>> - Lee's comments: Add kerneldoc header, better format comments.
>> Changes in v3:
>> - Basically Lee's comments:
>> - rather create a struct stm32_timers_dma, and place a reference to it
>> in existing ddata (instead of adding priv struct).
>> - rather use a struct device in exported routine prototype, and use
>> standard helpers instead of ddata. Get rid of to_stm32_timers_priv().
>> - simplify error handling in probe (remove a goto)
>> - comment on devm_of_platform_*populate() usage.
>>
>> 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 | 227
>> ++-
>> include/linux/mfd/stm32-timers.h | 32 ++
>> 2 files changed, 257 insertions(+), 2 deletions(-)
>
> [...]
>
>> diff --git a/include/linux/mfd/stm32-timers.h
>> b/include/linux/mfd/stm32-timers.h
>> index 2aadab6..a04d7a1 100644
>> --- a/include/linux/mfd/stm32-timers.h
>> +++ b/include/linux/mfd/stm32-timers.h
>> @@ -8,6 +8,8 @@
>> #define _LINUX_STM32_GPTIMER_H_
>>
>> #include
>> +#include
>> +#include
>> #include
>
> [...]
>
>> +struct stm32_timers_dma;
>> +
>> struct stm32_timers {
>> struct clk *clk;
>> struct regmap *regmap;
>> u32 max_arr;
>> +struct stm32_timers_dma *dma; /* Only to be used by the parent */
>
> I'm confused. I thought the point of putting this comment in was so
> that you could place the definition of 'stm32_timers_dma' and remove
> the forward declaration?
Hi Lee,
Sorry, if I miss-understood the point then. So, do you wish I both:
- move the full struct definition in above header ?
- and keep this comment ?
+/**
+ * struct stm32_timers_dma - STM32 timer DMA handling.
+ * @completion:end of DMA transfer completion
+ * @phys_base: control registers physical base address
+ * @lock: protect DMA access
+ * @chan: DMA channel in use
+ * @chans: DMA channels available for this timer instance
+ */
+struct stm32_timers_dma {
+ struct completion completion;
+ phys_addr_t phys_base;
+ struct mutex lock;
+ struct dma_chan *chan;
+ struct dma_chan *chans[STM32_TIMERS_MAX_DMAS];
+};
This will basically expose the struct to child drivers. But I'm ok if
you think this is acceptable.
I can send a V5 if you wish...
Please advise,
Best regards,
Fabrice
>
>> };
>> +
>> +int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
>> +enum stm32_timers_dmas id, u32 reg,
>> +unsigned int num_reg, unsigned int bursts,
>> +unsigned long tmo_ms);
>> #endif
>
[PATCH 1/7] powerpc/lib: move PPC32 specific functions out of string.S
In preparation of optimisation patches, move PPC32 specific memcmp() and __clear_user() into string_32.S Signed-off-by: Christophe Leroy --- arch/powerpc/lib/Makefile| 5 +-- arch/powerpc/lib/string.S| 61 - arch/powerpc/lib/string_32.S | 72 3 files changed, 75 insertions(+), 63 deletions(-) create mode 100644 arch/powerpc/lib/string_32.S diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 653901042ad7..2c9b8c0adf22 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -26,13 +26,14 @@ obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \ memcpy_power7.o obj64-y+= copypage_64.o copyuser_64.o mem_64.o hweight_64.o \ - string_64.o memcpy_64.o memcmp_64.o pmem.o + memcpy_64.o memcmp_64.o pmem.o obj64-$(CONFIG_SMP)+= locks.o obj64-$(CONFIG_ALTIVEC)+= vmx-helper.o obj64-$(CONFIG_KPROBES_SANITY_TEST) += test_emulate_step.o -obj-y += checksum_$(BITS).o checksum_wrappers.o +obj-y += checksum_$(BITS).o checksum_wrappers.o \ + string_$(BITS).o obj-y += sstep.o ldstfp.o quad.o obj64-y+= quad.o diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S index a787776822d8..cbb90fdc672d 100644 --- a/arch/powerpc/lib/string.S +++ b/arch/powerpc/lib/string.S @@ -55,23 +55,6 @@ _GLOBAL(strncmp) blr EXPORT_SYMBOL(strncmp) -#ifdef CONFIG_PPC32 -_GLOBAL(memcmp) - PPC_LCMPI 0,r5,0 - beq-2f - mtctr r5 - addir6,r3,-1 - addir4,r4,-1 -1: lbzur3,1(r6) - lbzur0,1(r4) - subf. r3,r0,r3 - bdnzt 2,1b - blr -2: li r3,0 - blr -EXPORT_SYMBOL(memcmp) -#endif - _GLOBAL(memchr) PPC_LCMPI 0,r5,0 beq-2f @@ -85,47 +68,3 @@ _GLOBAL(memchr) 2: li r3,0 blr EXPORT_SYMBOL(memchr) - -#ifdef CONFIG_PPC32 -_GLOBAL(__clear_user) - addir6,r3,-4 - li r3,0 - li r5,0 - cmplwi 0,r4,4 - blt 7f - /* clear a single word */ -11:stwur5,4(r6) - beqlr - /* clear word sized chunks */ - andi. r0,r6,3 - add r4,r0,r4 - subfr6,r0,r6 - srwir0,r4,2 - andi. r4,r4,3 - mtctr r0 - bdz 7f -1: stwur5,4(r6) - bdnz1b - /* clear byte sized chunks */ -7: cmpwi 0,r4,0 - beqlr - mtctr r4 - addir6,r6,3 -8: stbur5,1(r6) - bdnz8b - blr -90:mr r3,r4 - blr -91:mfctr r3 - slwir3,r3,2 - add r3,r3,r4 - blr -92:mfctr r3 - blr - - EX_TABLE(11b, 90b) - EX_TABLE(1b, 91b) - EX_TABLE(8b, 92b) - -EXPORT_SYMBOL(__clear_user) -#endif diff --git a/arch/powerpc/lib/string_32.S b/arch/powerpc/lib/string_32.S new file mode 100644 index ..2519f8bd09e3 --- /dev/null +++ b/arch/powerpc/lib/string_32.S @@ -0,0 +1,72 @@ +/* + * String handling functions for PowerPC32 + * + * Copyright (C) 2018 CS Systemes d'Information + * + * Author: Christophe Leroy + * + * SPDX-License-Identifier: GPL-2.0 + */ +#include +#include +#include +#include + + .text + +_GLOBAL(memcmp) + PPC_LCMPI 0,r5,0 + beq-2f + mtctr r5 + addir6,r3,-1 + addir4,r4,-1 +1: lbzur3,1(r6) + lbzur0,1(r4) + subf. r3,r0,r3 + bdnzt 2,1b + blr +2: li r3,0 + blr +EXPORT_SYMBOL(memcmp) + +_GLOBAL(__clear_user) + addir6,r3,-4 + li r3,0 + li r5,0 + cmplwi 0,r4,4 + blt 7f + /* clear a single word */ +11:stwur5,4(r6) + beqlr + /* clear word sized chunks */ + andi. r0,r6,3 + add r4,r0,r4 + subfr6,r0,r6 + srwir0,r4,2 + andi. r4,r4,3 + mtctr r0 + bdz 7f +1: stwur5,4(r6) + bdnz1b + /* clear byte sized chunks */ +7: cmpwi 0,r4,0 + beqlr + mtctr r4 + addir6,r6,3 +8: stbur5,1(r6) + bdnz8b + blr +90:mr r3,r4 + blr +91:mfctr r3 + slwir3,r3,2 + add r3,r3,r4 + blr +92:mfctr r3 + blr + + EX_TABLE(11b, 90b) + EX_TABLE(1b, 91b) + EX_TABLE(8b, 92b) + +EXPORT_SYMBOL(__clear_user) -- 2.13.3
[PATCH 6/7] powerpc/lib: inline more NUL size verifications
strncmp(), strncpy(), memchr() are often called with constant
size.
This patch gives GCC a chance to optimise NULL size verification out
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/string.h | 24
arch/powerpc/lib/string.S | 8
2 files changed, 32 insertions(+)
diff --git a/arch/powerpc/include/asm/string.h
b/arch/powerpc/include/asm/string.h
index 196ac5d587fb..1465d5629ef2 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -30,6 +30,22 @@ extern void * memchr(const void *,int,__kernel_size_t);
extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
#ifndef CONFIG_FORTIFY_SOURCE
+static inline char *__strncpy(char *p, const char *q, __kernel_size_t size)
+{
+ if (unlikely(!size))
+ return p;
+ return strncpy(p, q, size);
+}
+#define strncpy __strncpy
+
+static inline int __strncmp(const char *p, const char *q, __kernel_size_t size)
+{
+ if (unlikely(!size))
+ return 0;
+ return strncmp(p, q, size);
+}
+#define strncmp __strncmp
+
static inline int ___memcmp(const void *p,const void *q,__kernel_size_t size,
int offset)
{
int dif;
@@ -72,6 +88,14 @@ static inline int __memcmp(const void *p,const void
*q,__kernel_size_t size)
return memcmp(p, q, size);
}
#define memcmp __memcmp
+
+static inline void *__memchr(const void *p, int c, __kernel_size_t size)
+{
+ if (unlikely(!size))
+ return NULL;
+ return memchr(p, c, size);
+}
+#define memchr __memchr
#endif
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S
index cbb90fdc672d..89af53b08b4a 100644
--- a/arch/powerpc/lib/string.S
+++ b/arch/powerpc/lib/string.S
@@ -18,8 +18,10 @@
/* This clears out any unused part of the destination buffer,
just as the libc version does. -- paulus */
_GLOBAL(strncpy)
+#ifdef CONFIG_FORTIFY_SOURCE
PPC_LCMPI 0,r5,0
beqlr
+#endif
mtctr r5
addir6,r3,-1
addir4,r4,-1
@@ -38,8 +40,10 @@ _GLOBAL(strncpy)
EXPORT_SYMBOL(strncpy)
_GLOBAL(strncmp)
+#ifdef CONFIG_FORTIFY_SOURCE
PPC_LCMPI 0,r5,0
beq-2f
+#endif
mtctr r5
addir5,r3,-1
addir4,r4,-1
@@ -51,13 +55,17 @@ _GLOBAL(strncmp)
beqlr 1
bdnzt eq,1b
blr
+#ifdef CONFIG_FORTIFY_SOURCE
2: li r3,0
blr
+#endif
EXPORT_SYMBOL(strncmp)
_GLOBAL(memchr)
+#ifdef CONFIG_FORTIFY_SOURCE
PPC_LCMPI 0,r5,0
beq-2f
+#endif
mtctr r5
addir3,r3,-1
.balign 16
--
2.13.3
Re: [PATCH 18/25] staging: lustre: libcfs: clear up failure patch in cfs_cpt_*_print
> -err: > - if (rc < 0) > - return rc; > - > return tmp - buf; > + > +err: > + return -E2BIG; We finally fixed this bug! Hooray! But it's like you guys are deliberately writing in terrible style. You can just return directly and then you would have avoided this bug altogether from square one! People think that by adding little twists and moving code to the end of the function the it will be less buggy. It's not true. It's like at a hospital if they just swept the cockroaches under the bed, just because it's at the end of the function where you can't see it or review it doesn't mean it's not buggy. regards, dan carpenter
[PATCH 4/7] powerpc/lib: inline memcmp() for small constant sizes
In my 8xx configuration, I get 208 calls to memcmp()
Within those 208 calls, about half of them have constant sizes,
46 have a size of 8, 17 have a size of 16, only a few have a
size over 16. Other fixed sizes are mostly 4, 6 and 10.
This patch inlines calls to memcmp() when size
is constant and lower than or equal to 16
In my 8xx configuration, this reduces the number of calls
to memcmp() from 208 to 123
The following table shows the number of TB timeticks to perform
a constant size memcmp() before and after the patch depending on
the size
Before After Improvement
01: 75775682 25%
02: 416685682 86%
03: 51137 13258 74%
04: 454555682 87%
05: 58713 13258 77%
06: 58712 13258 77%
07: 68183 20834 70%
08: 56819 15153 73%
09: 70077 28411 60%
10: 70077 28411 60%
11: 79546 35986 55%
12: 68182 28411 58%
13: 81440 35986 55%
14: 81440 39774 51%
15: 94697 43562 54%
16: 79546 37881 52%
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/string.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/powerpc/include/asm/string.h
b/arch/powerpc/include/asm/string.h
index cf6f495134c3..196ac5d587fb 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -4,6 +4,8 @@
#ifdef __KERNEL__
+#include
+
#define __HAVE_ARCH_STRNCPY
#define __HAVE_ARCH_STRNCMP
#define __HAVE_ARCH_MEMSET
@@ -28,10 +30,45 @@ extern void * memchr(const void *,int,__kernel_size_t);
extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
#ifndef CONFIG_FORTIFY_SOURCE
+static inline int ___memcmp(const void *p,const void *q,__kernel_size_t size,
int offset)
+{
+ int dif;
+
+ BUILD_BUG_ON(!size || size > 8);
+
+ p += offset, q += offset;
+ if (size == 1)
+ return *(u8*)p - *(u8*)q;
+ if (size == 2)
+ return be16_to_cpu(*(u16*)p) - be16_to_cpu(*(u16*)q);
+ if (size == 3) {
+ dif = be16_to_cpu(*(u16*)p) - be16_to_cpu(*(u16*)q);
+ if (dif)
+ return dif;
+ return *(u8*)(p + 2) - *(u8*)(q + 2);
+ }
+ if (size == 8) {
+ s64 tmp = be64_to_cpu(*(u64*)p) - be64_to_cpu(*(u64*)q);
+ return tmp >> 32 ? : (int)tmp;
+ }
+
+ dif = be32_to_cpu(*(u32*)p) - be32_to_cpu(*(u32*)q);
+ if (size == 4 || dif)
+ return dif;
+
+ return ___memcmp(p, q, size - 4, 4);
+}
+
static inline int __memcmp(const void *p,const void *q,__kernel_size_t size)
{
if (unlikely(!size))
return 0;
+ if (__builtin_constant_p(size) && size <= 16) {
+ int dif = ___memcmp(p, q, size < 8 ? size : 8, 0);
+ if (size <= 8 || dif)
+ return dif;
+ return ___memcmp(p, q, size - 8, 8);
+ }
return memcmp(p, q, size);
}
#define memcmp __memcmp
--
2.13.3
[PATCH 3/7] powerpc/lib: optimise PPC32 memcmp
At the time being, memcmp() compares two chunks of memory byte per byte. This patch optimised the comparison by comparing word by word. A small benchmark performed on an 8xx based on the comparison of two chuncks of 512 bytes performed 10 times gives: Before : 5852274 TB ticks After: 1488638 TB ticks This is almost 4 times faster Signed-off-by: Christophe Leroy --- arch/powerpc/lib/string_32.S | 42 +++--- 1 file changed, 35 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/lib/string_32.S b/arch/powerpc/lib/string_32.S index 94e9c9bc31c3..5b2a73fb07be 100644 --- a/arch/powerpc/lib/string_32.S +++ b/arch/powerpc/lib/string_32.S @@ -19,13 +19,41 @@ _GLOBAL(memcmp) PPC_LCMPI 0,r5,0 beq-2f #endif - mtctr r5 - addir6,r3,-1 - addir4,r4,-1 -1: lbzur3,1(r6) - lbzur0,1(r4) - subf. r3,r0,r3 - bdnzt 2,1b + srawi. r7, r5, 2 /* Divide len by 4 */ + mr r6, r3 + beq-3f + mtctr r7 + li r7, 0 +1: +#ifdef __LITTLE_ENDIAN__ + lwbrx r3, r6, r7 + lwbrx r0, r4, r7 +#else + lwzxr3, r6, r7 + lwzxr0, r4, r7 +#endif + addir7, r7, 4 + subf. r3, r0, r3 + bdnzt eq, 1b + bnelr + andi. r5, r5, 3 + beqlr +3: cmplwi cr1, r5, 2 + blt-cr1, 4f +#ifdef __LITTLE_ENDIAN__ + lhbrx r3, r6, r7 + lhbrx r0, r4, r7 +#else + lhzxr3, r6, r7 + lhzxr0, r4, r7 +#endif + addir7, r7, 2 + subf. r3, r0, r3 + beqlr cr1 + bnelr +4: lbzxr3, r6, r7 + lbzxr0, r4, r7 + subf. r3, r0, r3 blr #ifdef CONFIG_FORTIFY_SOURCE 2: li r3,0 -- 2.13.3
[PATCH] drm/xen-front: Remove CMA support
From: Oleksandr Andrushchenko
Even if xen-front allocates its buffers from contiguous memory
those are still not contiguous in PA space, e.g. the buffer is only
contiguous in IPA space.
The only use-case for this mode was if xen-front is used to allocate
dumb buffers which later be used by some other driver requiring
contiguous memory, but there is no currently such a use-case or
it can be worked around with xen-front.
Signed-off-by: Oleksandr Andrushchenko
Suggested-by: Daniel Vetter
---
Documentation/gpu/xen-front.rst | 12
drivers/gpu/drm/xen/Kconfig | 13
drivers/gpu/drm/xen/Makefile| 9 +--
drivers/gpu/drm/xen/xen_drm_front.c | 62 +++-
drivers/gpu/drm/xen/xen_drm_front.h | 42 ++-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 12 +---
drivers/gpu/drm/xen/xen_drm_front_gem.h | 3 -
drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 79 -
drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 22 --
drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 8 ---
10 files changed, 21 insertions(+), 241 deletions(-)
delete mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
index 009d942386c5..d988da7d1983 100644
--- a/Documentation/gpu/xen-front.rst
+++ b/Documentation/gpu/xen-front.rst
@@ -18,18 +18,6 @@ Buffers allocated by the frontend driver
.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h
:doc: Buffers allocated by the frontend driver
-With GEM CMA helpers
-
-
-.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h
- :doc: With GEM CMA helpers
-
-Without GEM CMA helpers
-~~~
-
-.. kernel-doc:: drivers/gpu/drm/xen/xen_drm_front.h
- :doc: Without GEM CMA helpers
-
Buffers allocated by the backend
diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
index 4f4abc91f3b6..4cca160782ab 100644
--- a/drivers/gpu/drm/xen/Kconfig
+++ b/drivers/gpu/drm/xen/Kconfig
@@ -15,16 +15,3 @@ config DRM_XEN_FRONTEND
help
Choose this option if you want to enable a para-virtualized
frontend DRM/KMS driver for Xen guest OSes.
-
-config DRM_XEN_FRONTEND_CMA
- bool "Use DRM CMA to allocate dumb buffers"
- depends on DRM_XEN_FRONTEND
- select DRM_KMS_CMA_HELPER
- select DRM_GEM_CMA_HELPER
- help
- Use DRM CMA helpers to allocate display buffers.
- This is useful for the use-cases when guest driver needs to
- share or export buffers to other drivers which only expect
- contiguous buffers.
- Note: in this mode driver cannot use buffers allocated
- by the backend.
diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
index 352730dc6c13..712afff5ffc3 100644
--- a/drivers/gpu/drm/xen/Makefile
+++ b/drivers/gpu/drm/xen/Makefile
@@ -5,12 +5,7 @@ drm_xen_front-objs := xen_drm_front.o \
xen_drm_front_conn.o \
xen_drm_front_evtchnl.o \
xen_drm_front_shbuf.o \
- xen_drm_front_cfg.o
-
-ifeq ($(CONFIG_DRM_XEN_FRONTEND_CMA),y)
- drm_xen_front-objs += xen_drm_front_gem_cma.o
-else
- drm_xen_front-objs += xen_drm_front_gem.o
-endif
+ xen_drm_front_cfg.o \
+ xen_drm_front_gem.o
obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 4a08b77f1c9e..1b0ea9ac330e 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
@@ -167,10 +166,9 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
return ret;
}
-static int be_dbuf_create_int(struct xen_drm_front_info *front_info,
+int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages,
- struct sg_table *sgt)
+ u32 bpp, u64 size, struct page **pages)
{
struct xen_drm_front_evtchnl *evtchnl;
struct xen_drm_front_shbuf *shbuf;
@@ -187,7 +185,6 @@ static int be_dbuf_create_int(struct xen_drm_front_info
*front_info,
buf_cfg.xb_dev = front_info->xb_dev;
buf_cfg.pages = pages;
buf_cfg.size = size;
- buf_cfg.sgt = sgt;
buf_cfg.be_alloc = front_info->cfg.be_alloc;
shbuf = xen_drm_front_shbuf_alloc(&buf_cfg);
@@ -237,22 +234,6 @@ static int be_dbuf_create_int(struct xen_drm_front_info
*front_info,
return ret;
}
-int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info *front_info,
- u64 dbuf_cookie, u32 width, u
[PATCH 2/7] powerpc/lib: inline memcmp() NUL size verification
Many calls to memcmp() are done with constant size.
This patch gives GCC a chance to optimise out
the NULL size verification.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/string.h | 10 ++
arch/powerpc/lib/memcmp_64.S | 4
arch/powerpc/lib/string_32.S | 4
3 files changed, 18 insertions(+)
diff --git a/arch/powerpc/include/asm/string.h
b/arch/powerpc/include/asm/string.h
index 9b8cedf618f4..cf6f495134c3 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -27,6 +27,16 @@ extern int memcmp(const void *,const void *,__kernel_size_t);
extern void * memchr(const void *,int,__kernel_size_t);
extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
+#ifndef CONFIG_FORTIFY_SOURCE
+static inline int __memcmp(const void *p,const void *q,__kernel_size_t size)
+{
+ if (unlikely(!size))
+ return 0;
+ return memcmp(p, q, size);
+}
+#define memcmp __memcmp
+#endif
+
#ifdef CONFIG_PPC64
#define __HAVE_ARCH_MEMSET32
#define __HAVE_ARCH_MEMSET64
diff --git a/arch/powerpc/lib/memcmp_64.S b/arch/powerpc/lib/memcmp_64.S
index d75d18b7bd55..f6822fabf254 100644
--- a/arch/powerpc/lib/memcmp_64.S
+++ b/arch/powerpc/lib/memcmp_64.S
@@ -30,7 +30,9 @@
#endif
_GLOBAL(memcmp)
+#ifdef CONFIG_FORTIFY_SOURCE
cmpdi cr1,r5,0
+#endif
/* Use the short loop if both strings are not 8B aligned */
or r6,r3,r4
@@ -39,7 +41,9 @@ _GLOBAL(memcmp)
/* Use the short loop if length is less than 32B */
cmpdi cr6,r5,31
+#ifdef CONFIG_FORTIFY_SOURCE
beq cr1,.Lzero
+#endif
bne .Lshort
bgt cr6,.Llong
diff --git a/arch/powerpc/lib/string_32.S b/arch/powerpc/lib/string_32.S
index 2519f8bd09e3..94e9c9bc31c3 100644
--- a/arch/powerpc/lib/string_32.S
+++ b/arch/powerpc/lib/string_32.S
@@ -15,8 +15,10 @@
.text
_GLOBAL(memcmp)
+#ifdef CONFIG_FORTIFY_SOURCE
PPC_LCMPI 0,r5,0
beq-2f
+#endif
mtctr r5
addir6,r3,-1
addir4,r4,-1
@@ -25,8 +27,10 @@ _GLOBAL(memcmp)
subf. r3,r0,r3
bdnzt 2,1b
blr
+#ifdef CONFIG_FORTIFY_SOURCE
2: li r3,0
blr
+#endif
EXPORT_SYMBOL(memcmp)
_GLOBAL(__clear_user)
--
2.13.3
Re: [PATCH v3 06/11] iio: inkern: add module put/get on iio dev module when requesting channels
On 17.04.2018 02:58, Dmitry Torokhov wrote: On Sun, Apr 15, 2018 at 08:33:21PM +0100, Jonathan Cameron wrote: On Tue, 10 Apr 2018 11:57:52 +0300 Eugen Hristev wrote: When requesting channels for a particular consumer device, besides requesting the device (incrementing the reference counter), also do it for the driver module of the iio dev. This will avoid the situation where the producer IIO device can be removed and the consumer is still present in the kernel. Signed-off-by: Eugen Hristev --- drivers/iio/inkern.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c index ec98790..68d9b87 100644 --- a/drivers/iio/inkern.c +++ b/drivers/iio/inkern.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include "iio_core.h" @@ -152,6 +153,7 @@ static int __of_iio_channel_get(struct iio_channel *channel, if (index < 0) goto err_put; channel->channel = &indio_dev->channels[index]; + try_module_get(channel->indio_dev->driver_module); And if it fails? (the module we are trying to get is going away...) We should try and handle it I think. Be it by just erroring out of here. Even more, this has nothing to do with modules. A device can go away for any number of reasons (we unbind it manually via sysfs, we pull the USB plug from the host in case it is USB-connected device, we unload I2C adapter for the bus device resides on, we kick underlying PCI device) and we should be able to handle this in some fashion. Handling errors from reads and ignoring garbage is one of methods. FWIW this is a NACK from me. Thanks. Hello, This patch is actually a "best effort attempt" for the consumer driver (touch driver) to get a reference to the producer of the data (the IIO device), when it requests the specific channels. As of this moment, there is no attempt whatsoever for the consumer to have a reference on the producer driver. Thus, the producer can be removed at any time, and the consumer will fail ungraciously. I can change the perspective from "best effort" to "mandatory" to get a reference to the producer, or you wish to stop trying to get any reference at all (remove this patch completely) ? Thanks, Eugen
[PATCH net-next v4 1/3] vmcore: add API to collect hardware dump in second kernel
The sequence of actions done by device drivers to append their device
specific hardware/firmware logs to /proc/vmcore are as follows:
1. During probe (before hardware is initialized), device drivers
register to the vmcore module (via vmcore_add_device_dump()), with
callback function, along with buffer size and log name needed for
firmware/hardware log collection.
2. vmcore module allocates the buffer with requested size. It adds
an Elf note and invokes the device driver's registered callback
function.
3. Device driver collects all hardware/firmware logs into the buffer
and returns control back to vmcore module.
Ensure that the device dump buffer size is always aligned to page size
so that it can be mmaped.
Also, rename alloc_elfnotes_buf() to vmcore_alloc_buf() to make it more
generic and reserve NT_VMCOREDD note type to indicate vmcore device
dump.
Suggested-by: Eric Biederman .
Signed-off-by: Rahul Lakkireddy
Signed-off-by: Ganesh Goudar
---
v4:
- Made __vmcore_add_device_dump() static.
- Moved compile check to define vmcore_add_device_dump() to
crash_dump.h to fix compilation when vmcore.c is not compiled in.
- Convert ---help--- to help in Kconfig as indicated by checkpatch.
- Rebased to tip.
v3:
- Dropped sysfs crashdd module.
- Added CONFIG_PROC_VMCORE_DEVICE_DUMP to allow configuring device
dump support.
- Moved logic related to adding dumps from crashdd to vmcore module.
- Rename all crashdd* to vmcoredd*.
v2:
- Added ABI Documentation for crashdd.
- Directly use octal permission instead of macro.
Changes since rfc v2:
- Moved exporting crashdd from procfs to sysfs. Suggested by
Stephen Hemminger
- Moved code from fs/proc/crashdd.c to fs/crashdd/ directory.
- Replaced all proc API with sysfs API and updated comments.
- Calling driver callback before creating the binary file under
crashdd sysfs.
- Changed binary dump file permission from S_IRUSR to S_IRUGO.
- Changed module name from CRASH_DRIVER_DUMP to CRASH_DEVICE_DUMP.
rfc v2:
- Collecting logs in 2nd kernel instead of during kernel panic.
Suggested by Eric Biederman .
- Patch added in this series.
fs/proc/Kconfig| 10 +++
fs/proc/vmcore.c | 152 ++---
include/linux/crash_core.h | 4 ++
include/linux/crash_dump.h | 17 +
include/linux/kcore.h | 6 ++
include/uapi/linux/elf.h | 1 +
6 files changed, 181 insertions(+), 9 deletions(-)
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 1ade1206bb89..504c77a444bd 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -43,6 +43,16 @@ config PROC_VMCORE
help
Exports the dump image of crashed kernel in ELF format.
+config PROC_VMCORE_DEVICE_DUMP
+ bool "Device Hardware/Firmware Log Collection"
+ depends on PROC_VMCORE
+ default y
+ help
+ Device drivers can collect the device specific snapshot of
+ their hardware or firmware before they are initialized in
+ crash recovery kernel. If you say Y here, the device dumps
+ will be added as ELF notes to /proc/vmcore
+
config PROC_SYSCTL
bool "Sysctl support (/proc/sys)" if EXPERT
depends on PROC_FS
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index a45f0af22a60..7395462d2f86 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,12 @@ static u64 vmcore_size;
static struct proc_dir_entry *proc_vmcore;
+#ifdef CONFIG_PROC_VMCORE_DEVICE_DUMP
+/* Device Dump list and mutex to synchronize access to list */
+static LIST_HEAD(vmcoredd_list);
+static DEFINE_MUTEX(vmcoredd_mutex);
+#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
+
/*
* Returns > 0 for RAM pages, 0 for non-RAM pages, < 0 on error
* The called function has to take care of module refcounting.
@@ -302,10 +309,8 @@ static const struct vm_operations_struct vmcore_mmap_ops =
{
};
/**
- * alloc_elfnotes_buf - allocate buffer for ELF note segment in
- * vmalloc memory
- *
- * @notes_sz: size of buffer
+ * vmcore_alloc_buf - allocate buffer in vmalloc memory
+ * @sizez: size of buffer
*
* If CONFIG_MMU is defined, use vmalloc_user() to allow users to mmap
* the buffer to user-space by means of remap_vmalloc_range().
@@ -313,12 +318,12 @@ static const struct vm_operations_struct vmcore_mmap_ops
= {
* If CONFIG_MMU is not defined, use vzalloc() since mmap_vmcore() is
* disabled and there's no need to allow users to mmap the buffer.
*/
-static inline char *alloc_elfnotes_buf(size_t notes_sz)
+static inline char *vmcore_alloc_buf(size_t size)
{
#ifdef CONFIG_MMU
- return vmalloc_user(notes_sz);
+ return vmalloc_user(size);
#else
- return vzalloc(notes_sz);
+ return vzalloc(size);
#endif
}
@@ -665,7 +670,7 @@ static int __init merge_note_headers_elf64(char *elfptr,
size_t *elfsz,
return rc;
*notes_sz = roundup
[PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel
On production servers running variety of workloads over time, kernel panic can happen sporadically after days or even months. It is important to collect as much debug logs as possible to root cause and fix the problem, that may not be easy to reproduce. Snapshot of underlying hardware/firmware state (like register dump, firmware logs, adapter memory, etc.), at the time of kernel panic will be very helpful while debugging the culprit device driver. This series of patches add new generic framework that enable device drivers to collect device specific snapshot of the hardware/firmware state of the underlying device in the crash recovery kernel. In crash recovery kernel, the collected logs are added as elf notes to /proc/vmcore, which is copied by user space scripts for post-analysis. The sequence of actions done by device drivers to append their device specific hardware/firmware logs to /proc/vmcore are as follows: 1. During probe (before hardware is initialized), device drivers register to the vmcore module (via vmcore_add_device_dump()), with callback function, along with buffer size and log name needed for firmware/hardware log collection. 2. vmcore module allocates the buffer with requested size. It adds an elf note and invokes the device driver's registered callback function. 3. Device driver collects all hardware/firmware logs into the buffer and returns control back to vmcore module. The device specific hardware/firmware logs can be seen as elf notes: # readelf -n /proc/vmcore Displaying notes found at file offset 0x1000 with length 0x04003288: Owner Data size Description VMCOREDD_cxgb4_:02:00.4 0x02000fd8Unknown note type: (0x0700) VMCOREDD_cxgb4_:04:00.4 0x02000fd8Unknown note type: (0x0700) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) CORE 0x0150 NT_PRSTATUS (prstatus structure) VMCOREINFO 0x074f Unknown note type: (0x) Patch 1 adds API to vmcore module to allow drivers to register callback to collect the device specific hardware/firmware logs. The logs will be added to /proc/vmcore as elf notes. Patch 2 updates read and mmap logic to append device specific hardware/ firmware logs as elf notes. Patch 3 shows a cxgb4 driver example using the API to collect hardware/firmware logs in crash recovery kernel, before hardware is initialized. Thanks, Rahul RFC v1: https://lkml.org/lkml/2018/3/2/542 RFC v2: https://lkml.org/lkml/2018/3/16/326 --- v4: - Made __vmcore_add_device_dump() static. - Moved compile check to define vmcore_add_device_dump() to crash_dump.h to fix compilation when vmcore.c is not compiled in. - Convert ---help--- to help in Kconfig as indicated by checkpatch. - Rebased to tip. v3: - Dropped sysfs crashdd module. - Exported dumps as elf notes. Suggested by Eric Biederman . Added as patch 2 in this version. - Added CONFIG_PROC_VMCORE_DEVICE_DUMP to allow configuring device dump support. - Moved logic related to adding dumps from crashdd to vmcore module. - Rename all crashdd* to vmcoredd*. - Updated comments. v2: - Added ABI Documentation for crashdd. - Directly use octal permission instead of macro. Changes since rfc v2: - Moved exporting crashdd from procfs to sysfs. Suggested by Stephen Hemminger - Moved code from fs/proc/crashdd.c to fs/crashdd/ directory. - Replaced all proc API with sysfs API and updated comments. - Calling driver callback before creating the binary file under crashdd sysfs. - Changed binary dump file permission from S_IRUSR to S_IRUGO. - Changed module name from CRASH_DRIVER_DUMP to CRASH_DEVICE_DUMP. rfc v2: - Collecting logs in 2nd kernel instead of during kernel panic. Suggested by Eric Biederman . - Added new crashdd module that exports /proc/crashdd/ containing driver's registered hardware/firmware logs in patch 1. - Replaced the API to allow drivers to register their hardware/firmware log collect routine in crash recovery kernel in patch 1. - Updated patch 2 to use the new API in patch 1. Rahul Lakkireddy (3): vmcore: add API to collect hardware dump in second kernel vmcore: append device dumps to vmcore as elf notes cxgb4: collect hardware dump in second kernel drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 25 ++ drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h | 3 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 + fs/proc/Kconfig
[PATCH net-next v4 3/3] cxgb4: collect hardware dump in second kernel
Register callback to collect hardware/firmware dumps in second kernel
before hardware/firmware is initialized. The dumps for each device
will be available as elf notes in /proc/vmcore in second kernel.
Signed-off-by: Rahul Lakkireddy
Signed-off-by: Ganesh Goudar
---
v4:
- No changes.
v3:
- Replaced all crashdd* with vmcoredd*.
- Replaced crashdd_add_dump() with vmcore_add_device_dump().
- Updated comments and commit message.
v2:
- No Changes.
Changes since rfc v2:
- Update comments and commit message for sysfs change.
rfc v2:
- Updated dump registration to the new API in patch 1.
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 25
drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h | 3 +++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 ++
4 files changed, 42 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 688f95440af2..01e7aad4ce5b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include "t4_chip_type.h"
#include "cxgb4_uld.h"
@@ -964,6 +965,9 @@ struct adapter {
struct hma_data hma;
struct srq_data *srq;
+
+ /* Dump buffer for collecting logs in kdump kernel */
+ struct vmcoredd_data vmcoredd;
};
/* Support for "sched-class" command to allow a TX Scheduling Class to be
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
index 143686c60234..76433d4fe483 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
@@ -488,3 +488,28 @@ void cxgb4_init_ethtool_dump(struct adapter *adapter)
adapter->eth_dump.version = adapter->params.fw_vers;
adapter->eth_dump.len = 0;
}
+
+static int cxgb4_cudbg_vmcoredd_collect(struct vmcoredd_data *data, void *buf)
+{
+ struct adapter *adap = container_of(data, struct adapter, vmcoredd);
+ u32 len = data->size;
+
+ return cxgb4_cudbg_collect(adap, buf, &len, CXGB4_ETH_DUMP_ALL);
+}
+
+int cxgb4_cudbg_vmcore_add_dump(struct adapter *adap)
+{
+ struct vmcoredd_data *data = &adap->vmcoredd;
+ u32 len;
+
+ len = sizeof(struct cudbg_hdr) +
+ sizeof(struct cudbg_entity_hdr) * CUDBG_MAX_ENTITY;
+ len += CUDBG_DUMP_BUFF_SIZE;
+
+ data->size = len;
+ snprintf(data->name, sizeof(data->name), "%s_%s", cxgb4_driver_name,
+adap->name);
+ data->vmcoredd_callback = cxgb4_cudbg_vmcoredd_collect;
+
+ return vmcore_add_device_dump(data);
+}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h
index ce1ac9a1c878..ef59ba1ed968 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h
@@ -41,8 +41,11 @@ enum CXGB4_ETHTOOL_DUMP_FLAGS {
CXGB4_ETH_DUMP_HW = (1 << 1), /* various FW and HW dumps */
};
+#define CXGB4_ETH_DUMP_ALL (CXGB4_ETH_DUMP_MEM | CXGB4_ETH_DUMP_HW)
+
u32 cxgb4_get_dump_length(struct adapter *adap, u32 flag);
int cxgb4_cudbg_collect(struct adapter *adap, void *buf, u32 *buf_size,
u32 flag);
void cxgb4_init_ethtool_dump(struct adapter *adapter);
+int cxgb4_cudbg_vmcore_add_dump(struct adapter *adap);
#endif /* __CXGB4_CUDBG_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 24d2865b8806..32cad0acf76c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5544,6 +5544,16 @@ static int init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (err)
goto out_free_adapter;
+ if (is_kdump_kernel()) {
+ /* Collect hardware state and append to /proc/vmcore */
+ err = cxgb4_cudbg_vmcore_add_dump(adapter);
+ if (err) {
+ dev_warn(adapter->pdev_dev,
+"Fail collecting vmcore device dump, err: %d.
Continuing\n",
+err);
+ err = 0;
+ }
+ }
if (!is_t4(adapter->params.chip)) {
s_qpp = (QUEUESPERPAGEPF0_S +
--
2.14.1
[PATCH net-next v4 2/3] vmcore: append device dumps to vmcore as elf notes
Update read and mmap logic to append device dumps as additional notes
before the other elf notes. We add device dumps before other elf notes
because the other elf notes may not fill the elf notes buffer
completely and we will end up with zero-filled data between the elf
notes and the device dumps. Tools will then try to decode this
zero-filled data as valid notes and we don't want that. Hence, adding
device dumps before the other elf notes ensure that zero-filled data
can be avoided. This also ensures that the device dumps and the
other elf notes can be properly mmaped at page aligned address.
Incorporate device dump size into the total vmcore size. Also update
offsets for other program headers after the device dumps are added.
Suggested-by: Eric Biederman .
Signed-off-by: Rahul Lakkireddy
Signed-off-by: Ganesh Goudar
---
v4:
- No changes.
v3:
- Patch added in this version.
- Exported dumps as elf notes. Suggested by Eric Biederman
.
fs/proc/vmcore.c | 247 ++-
1 file changed, 243 insertions(+), 4 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 7395462d2f86..ed1ebd85e14e 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -39,6 +39,8 @@ static size_t elfcorebuf_sz_orig;
static char *elfnotes_buf;
static size_t elfnotes_sz;
+/* Size of all notes minus the device dump notes */
+static size_t elfnotes_orig_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
@@ -51,6 +53,9 @@ static LIST_HEAD(vmcoredd_list);
static DEFINE_MUTEX(vmcoredd_mutex);
#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
+/* Device Dump Size */
+static size_t vmcoredd_orig_sz;
+
/*
* Returns > 0 for RAM pages, 0 for non-RAM pages, < 0 on error
* The called function has to take care of module refcounting.
@@ -185,6 +190,77 @@ static int copy_to(void *target, void *src, size_t size,
int userbuf)
return 0;
}
+#ifdef CONFIG_PROC_VMCORE_DEVICE_DUMP
+static int vmcoredd_copy_dumps(void *dst, u64 start, size_t size, int userbuf)
+{
+ struct vmcoredd_node *dump;
+ u64 offset = 0;
+ int ret = 0;
+ size_t tsz;
+ char *buf;
+
+ mutex_lock(&vmcoredd_mutex);
+ list_for_each_entry(dump, &vmcoredd_list, list) {
+ if (start < offset + dump->size) {
+ tsz = min(offset + (u64)dump->size - start, (u64)size);
+ buf = dump->buf + start - offset;
+ if (copy_to(dst, buf, tsz, userbuf)) {
+ ret = -EFAULT;
+ goto out_unlock;
+ }
+
+ size -= tsz;
+ start += tsz;
+ dst += tsz;
+
+ /* Leave now if buffer filled already */
+ if (!size)
+ goto out_unlock;
+ }
+ offset += dump->size;
+ }
+
+out_unlock:
+ mutex_unlock(&vmcoredd_mutex);
+ return ret;
+}
+
+static int vmcoredd_mmap_dumps(struct vm_area_struct *vma, unsigned long dst,
+ u64 start, size_t size)
+{
+ struct vmcoredd_node *dump;
+ u64 offset = 0;
+ int ret = 0;
+ size_t tsz;
+ char *buf;
+
+ mutex_lock(&vmcoredd_mutex);
+ list_for_each_entry(dump, &vmcoredd_list, list) {
+ if (start < offset + dump->size) {
+ tsz = min(offset + (u64)dump->size - start, (u64)size);
+ buf = dump->buf + start - offset;
+ if (remap_vmalloc_range_partial(vma, dst, buf, tsz)) {
+ ret = -EFAULT;
+ goto out_unlock;
+ }
+
+ size -= tsz;
+ start += tsz;
+ dst += tsz;
+
+ /* Leave now if buffer filled already */
+ if (!size)
+ goto out_unlock;
+ }
+ offset += dump->size;
+ }
+
+out_unlock:
+ mutex_unlock(&vmcoredd_mutex);
+ return ret;
+}
+#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
+
/* Read from the ELF header and then the crash dump. On error, negative value
is
* returned otherwise number of bytes read are returned.
*/
@@ -222,10 +298,41 @@ static ssize_t __read_vmcore(char *buffer, size_t buflen,
loff_t *fpos,
if (*fpos < elfcorebuf_sz + elfnotes_sz) {
void *kaddr;
+ /* We add device dumps before other elf notes because the
+* other elf notes may not fill the elf notes buffer
+* completely and we will end up with zero-filled data
+* between the elf notes and the device dumps. Tools will
+* then try to decode this zero-filled data as valid notes
+* and we don't want that. Hence, adding device dumps
Re: linux-next: manual merge of the efi-lock-down tree with the modules tree
Stephen Rothwell wrote: > Today's linux-next merge of the efi-lock-down tree got a conflict in: Can you drop my branch for the moment? Thanks, David
Re: [PATCH 2/2] input: misc: Add Spreadtrum vibrator driver
Hi Marcus,
On 17 April 2018 at 15:25, Marcus Folkesson wrote:
> Hi Xiaotong,
>
> On Tue, Apr 17, 2018 at 11:18:24AM +0800, Baolin Wang wrote:
>> From: Xiaotong Lu
>
> [snip]
>
>> +static int sc27xx_vibra_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *node = pdev->dev.of_node;
>> + struct vibra_info *info;
>> + int ret;
>> +
>> + info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
>> + if (!info)
>> + return -ENOMEM;
>> +
>> + info->regmap = dev_get_regmap(pdev->dev.parent, NULL);
>> + if (!info->regmap) {
>> + dev_err(&pdev->dev, "failed to get vibrator regmap.\n");
>> + return -ENODEV;
>> + }
>> +
>> + ret = of_property_read_u32(node, "reg", &info->base);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to get vibrator base address.\n");
>> + return ret;
>> + }
>> +
>> + info->input_dev = devm_input_allocate_device(&pdev->dev);
>> + if (!info->input_dev) {
>> + dev_err(&pdev->dev, "failed to allocate input device.\n");
>> + return -ENOMEM;
>> + }
>> +
>> + info->input_dev->name = "sc27xx:vibrator";
>> + info->input_dev->id.version = 0;
>> + info->input_dev->dev.parent = pdev->dev.parent;
>> + info->input_dev->close = sc27xx_vibra_close;
>> +
>> + input_set_drvdata(info->input_dev, info);
>> + input_set_capability(info->input_dev, EV_FF, FF_RUMBLE);
>> + INIT_WORK(&info->play_work, sc27xx_vibra_play_work);
>> + info->enabled = false;
>> +
>> + ret = input_ff_create_memless(info->input_dev, NULL,
>> sc27xx_vibra_play);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to register vibrator to FF.\n");
>> + return ret;
>> + }
>> +
>> + ret = input_register_device(info->input_dev);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to register input device.\n");
>> + input_ff_destroy(info->input_dev);
>
> I'm not sure how the input_ff is freed for managed devices.
>
> Either you don't have to destroy it here, or you also need to destroy it
> in a release() function.
I checked again, we do not need to destroy it manually. Will remove in
next version.
>
>> + return ret;
>> + }
>> +
>> + ret = sc27xx_vibra_hw_init(info);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to initialize the vibrator.\n");
>> + input_ff_destroy(info->input_dev);
>> + input_unregister_device(info->input_dev);
>
> No need to unregister managed input devices.
You are correct. Will remove these in next version. Thanks for your comments.
--
Baolin.wang
Best Regards
Re: [PATCH v6 08/11] ARM: sun9i: smp: Add is_sun8i field
Hi,
On Mon, Apr 16, 2018 at 11:50:29PM +0200, Mylène Josserand wrote:
> To prepare the support of sun8i-a83t, add a field in the smp_data
> structure to know if we are on sun9i-a80 or sun8i-a83t.
>
> Add also a global variable to retrieve which architecture we are
> having.
>
> Signed-off-by: Mylène Josserand
> ---
> arch/arm/mach-sunxi/mc_smp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> index 03f021d0c73e..9d57ea27dacc 100644
> --- a/arch/arm/mach-sunxi/mc_smp.c
> +++ b/arch/arm/mach-sunxi/mc_smp.c
> @@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
>
> extern void sunxi_mc_smp_secondary_startup(void);
> extern void sunxi_mc_smp_resume(void);
> +static int is_sun8i;
>
> static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
> {
> @@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
> struct sunxi_mc_smp_data {
> const char *enable_method;
> int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
> + int is_sun8i;
> };
>
> static void __init sunxi_mc_smp_put_nodes(struct sunxi_mc_smp_nodes *nodes)
> @@ -664,6 +666,7 @@ static const struct sunxi_mc_smp_data sunxi_mc_smp_data[]
> __initconst = {
> {
> .enable_method = "allwinner,sun9i-a80-smp",
> .get_smp_nodes = sun9i_a80_get_smp_nodes,
> + .is_sun8i = false,
I'm still not convinced about the name of that flag. sun8i doesn't
mean anything, really. What you want to discriminate against it what
you're writing in your commit log: if it is an A80 or an A83t. The
A33, H3, A23, you name it are also part of the sun8i family, yet they
are completely irrelevant to this file.
Also, false is the default value, you can leave it out.
> },
> };
>
> @@ -697,6 +700,8 @@ static int __init sunxi_mc_smp_init(void)
> break;
> }
>
> + is_sun8i = sunxi_mc_smp_data[i].is_sun8i;
> +
Do we really need to cache it? Can't we just have a pointer to the SMP
data structure and use that instead?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH v3 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
On Tuesday 17 April 2018 04:38:29 Lukas Wunner wrote: > On Mon, Apr 16, 2018 at 04:25:12PM +0200, Pali Rohár wrote: > > On Sunday 15 April 2018 21:05:23 Lukas Wunner wrote: > > > On Sun, Apr 15, 2018 at 07:17:46PM +0200, Pali Rohár wrote: > > > > On Saturday 14 April 2018 13:17:11 Lukas Wunner wrote: > > > > > On Sat, Apr 14, 2018 at 12:49:50PM +0200, Pali Rohár wrote: > > > > > > On Saturday 14 April 2018 12:45:12 Lukas Wunner wrote: > > > > > > > On Thu, Apr 12, 2018 at 10:15:41PM +0800, Kai-Heng Feng wrote: > > > > > > > > Do you have any suggestion to check if it connects to the > > > > > > > > system via > > > > > > > > Thunderbolt? > > > > > > > > > > > > > > Just use pci_is_thunderbolt_attached(), introduced by > > > > > > > 8531e283bee6, > > > > > > > like this: > > > > > > > > > > > > > > if (check_dell_switchable_gfx(pci) && > > > > > > > !pci_is_thunderbolt_attached(pci)) > > > > > > > > > > > > And what about PCI-e device attached to ExpressCard slot? > > > > > > > > > > I don't know of a bullet-proof way to recognize those. > > > > > > > > Hm... maybe another idea: Is it possible to detect which audio pci > > > > device belongs to graphics card via vga_switcheroo? Currently, looking > > > > at output it is same PCI device as graphic card, just different PCI > > > > function. > > > > > > No, the DRM drivers don't filter ExpressCard-attached GPUs when > > > registering with vga_switcheroo. > > > > > They do filter Thunderbolt-attached GPUs. > > > > So check via vga_switcheroo should at least work for Thunderbolt GPUs. > > > > I do not know if it is possible, but for me it looks like that check via > > vga_switcheroo should be better then adding another heuristic to other > > drivers. > > It is way simpler and more straightforward if hda_intel.c calls > pci_is_thunderbolt_attached() directly, as I've suggested above. > > The DRM drivers call that as well and register with vga_switcheroo > only if it returns false. So if hda_intel.c asked vga_switcheroo > and got back a negative answer, it would never know whether it's > because the DRM driver hasn't finished probing yet, or it's module > is blacklisted, or whatever. Ok, module blacklisting can be a problem. > > > And once we would have good/reliable check for EC devices we can add it > > into vga_switcheroo and all users of it could benefit. Anyway, I think > > that vga_switcheroo should filter also EC GPU cards if it already > > filters Thunderbolt. > > vga_switcheroo doesn't do the filtering, the DRM drivers themselves > decice whether to register with vga_switcheroo or not. The motivation > is to avoid middle layers and instead provide the DRM drivers with > a library of helpers that they may call at their own discretion. Understood. Driver itself can also do more work, e.g. ask ACPI or do some other check to decide whatever to register to vga_switcheroo or not. But probably, hda_intel should have same logic for disabling device like gpu drivers for detection if they are going to register into vga_switcheroo or not. Right now this seems to be really complicated and suggested solution with pci_is_thunderbolt_attached() looks to be really simple and better for now. > See this blog post and the links therein for background info: > http://blog.ffwll.ch/2016/12/midlayers-once-more-with-feeling.html > > Thanks, > > Lukas -- Pali Rohár pali.ro...@gmail.com
RE: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node
Hi Rob, On 13 April 2018 19:06, Rob Herring: > On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote: > > The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function system > > controller. This documents the node used to encapsulate it's sub > > drivers. > > > > Signed-off-by: Michel Pollet > > --- > > .../bindings/mfd/renesas,rzn1-sysctrl.txt | 23 > ++ > > 1 file changed, 23 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt > > > > diff --git > > a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt > > b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt > > new file mode 100644 > > index 000..9897f8f > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt > > @@ -0,0 +1,23 @@ > > +DT bindings for the Renesas RZ/N1 System Controller > > + > > +== System Controller Node == > > + > > +The system controller node currently only hosts a single sub-node to > > +handle the rebooting of the CPU. Eventually it will host the clock > > +driver, SMP start handler, watchdog etc. > > Please submit a complete binding for the h/w block. > > Again, if the only reason you have sub nodes is to define compatible strings > and in turn enumerate drivers, then you don't need the nodes in DT. DT is > not the only way to instantiate drivers. I can't document it before I have the code. There is 0.000% chance of my clock driver for example to be upstreamed the way I would imagine making it -- in fact pretty much any other driver will have to be reworked to fit, so documenting bindings first is impossible. So, if I understand correctly, you are telling me to make a 'sysctrl' driver and use platform_device to instantiate my sub-drivers? Isn't that what machine files used to do? And they are now banned? Geert, any guidance here? > > Rob Thanks! Michel Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
[PATCH] powerpc/misc: get rid of add_reloc_offset()
add_reloc_offset() is almost redundant with reloc_offset() Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/setup.h | 3 +-- arch/powerpc/kernel/misc.S | 16 arch/powerpc/kernel/prom_init_check.sh | 2 +- 3 files changed, 2 insertions(+), 19 deletions(-) diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h index 27fa52ed6d00..115e0896ffa7 100644 --- a/arch/powerpc/include/asm/setup.h +++ b/arch/powerpc/include/asm/setup.h @@ -17,10 +17,9 @@ extern void note_scsi_host(struct device_node *, void *); /* Used in very early kernel initialization. */ extern unsigned long reloc_offset(void); -extern unsigned long add_reloc_offset(unsigned long); extern void reloc_got2(unsigned long); -#define PTRRELOC(x)((typeof(x)) add_reloc_offset((unsigned long)(x))) +#define PTRRELOC(x)((typeof(x)) ((unsigned long)(x) + reloc_offset())) void check_for_initrd(void); void mem_topology_setup(void); diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S index 384357cb8bc0..2711b10ebdb3 100644 --- a/arch/powerpc/kernel/misc.S +++ b/arch/powerpc/kernel/misc.S @@ -39,22 +39,6 @@ _GLOBAL(reloc_offset) .align 3 2: PPC_LONG 1b -/* - * add_reloc_offset(x) returns x + reloc_offset(). - */ -_GLOBAL(add_reloc_offset) - mflrr0 - bl 1f -1: mflrr5 - PPC_LL r4,(2f-1b)(r5) - subfr5,r4,r5 - add r3,r3,r5 - mtlrr0 - blr - - .align 3 -2: PPC_LONG 1b - _GLOBAL(setjmp) mflrr0 PPC_STL r0,0(r3) diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh index acb6b9226352..ee9f63186b72 100644 --- a/arch/powerpc/kernel/prom_init_check.sh +++ b/arch/powerpc/kernel/prom_init_check.sh @@ -16,7 +16,7 @@ # If you really need to reference something from prom_init.o add # it to the list below: -WHITELIST="add_reloc_offset __bss_start __bss_stop copy_and_flush +WHITELIST="__bss_start __bss_stop copy_and_flush _end enter_prom memcpy memset reloc_offset __secondary_hold __secondary_hold_acknowledge __secondary_hold_spinloop __start strcmp strcpy strlcpy strlen strncmp strstr kstrtobool logo_linux_clut224 -- 2.13.3
Re: [PATCH v2 0/3] perf/buildid-cache: Add --list and --purge-all options
On Tue, Apr 17, 2018 at 09:43:43AM +0530, Ravi Bangoria wrote: > First patch is a trivial error message fix. Second and third > adds new options --list and --purge-all to 'buildid-cache' > subcommand. > > v2 changes: > - [PATCH v2 2/3] Display optput of 'perf buildid-cache -l' same as >'perf buildid-list'. > - [PATCH v2 2/3] Other minor changes as suggested by Jiri. Acked-by: Jiri Olsa thanks, jirka > > v1 can be found at: > https://lkml.org/lkml/2018/4/9/295 > > Ravi Bangoria (3): > tools/parse-options: Add '\n' at the end of error messages > perf/buildid-cache: Support --list option > perf/buildid-cache: Support --purge-all option > > tools/lib/subcmd/parse-options.c| 6 +- > tools/perf/Documentation/perf-buildid-cache.txt | 7 ++- > tools/perf/builtin-buildid-cache.c | 77 > - > 3 files changed, 83 insertions(+), 7 deletions(-) > > -- > 2.14.3 >
Re: [PATCH v6 08/11] ARM: sun9i: smp: Add is_sun8i field
On Tue, Apr 17, 2018 at 3:52 PM, Maxime Ripard
wrote:
> Hi,
>
> On Mon, Apr 16, 2018 at 11:50:29PM +0200, Mylène Josserand wrote:
>> To prepare the support of sun8i-a83t, add a field in the smp_data
>> structure to know if we are on sun9i-a80 or sun8i-a83t.
>>
>> Add also a global variable to retrieve which architecture we are
>> having.
>>
>> Signed-off-by: Mylène Josserand
>> ---
>> arch/arm/mach-sunxi/mc_smp.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
>> index 03f021d0c73e..9d57ea27dacc 100644
>> --- a/arch/arm/mach-sunxi/mc_smp.c
>> +++ b/arch/arm/mach-sunxi/mc_smp.c
>> @@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
>>
>> extern void sunxi_mc_smp_secondary_startup(void);
>> extern void sunxi_mc_smp_resume(void);
>> +static int is_sun8i;
>>
>> static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int
>> cluster)
>> {
>> @@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
>> struct sunxi_mc_smp_data {
>> const char *enable_method;
>> int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
>> + int is_sun8i;
>> };
>>
>> static void __init sunxi_mc_smp_put_nodes(struct sunxi_mc_smp_nodes *nodes)
>> @@ -664,6 +666,7 @@ static const struct sunxi_mc_smp_data
>> sunxi_mc_smp_data[] __initconst = {
>> {
>> .enable_method = "allwinner,sun9i-a80-smp",
>> .get_smp_nodes = sun9i_a80_get_smp_nodes,
>> + .is_sun8i = false,
>
> I'm still not convinced about the name of that flag. sun8i doesn't
> mean anything, really. What you want to discriminate against it what
> you're writing in your commit log: if it is an A80 or an A83t. The
> A33, H3, A23, you name it are also part of the sun8i family, yet they
> are completely irrelevant to this file.
>
> Also, false is the default value, you can leave it out.
>
>> },
>> };
>>
>> @@ -697,6 +700,8 @@ static int __init sunxi_mc_smp_init(void)
>> break;
>> }
>>
>> + is_sun8i = sunxi_mc_smp_data[i].is_sun8i;
>> +
>
> Do we really need to cache it? Can't we just have a pointer to the SMP
> data structure and use that instead?
I recommended that. We don't need any of the other fields in the SMP
data structure once we're past the init phase. This saves a dereference
or two.
ChenYu
Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > Yeah, I definitely agree on the idea of expanding the use case to the > general domain where dmabuf sharing is used. However, what you are > targetting with proposed changes is identical to the core design of > hyper_dmabuf. > > On top of this basic functionalities, hyper_dmabuf has driver level > inter-domain communication, that is needed for dma-buf remote tracking > (no fence forwarding though), event triggering and event handling, extra > meta data exchange and hyper_dmabuf_id that represents grefs > (grefs are shared implicitly on driver level) This really isn't a positive design aspect of hyperdmabuf imo. The core code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is very simple & clean. If there's a clear need later on we can extend that. But for now xen-zcopy seems to cover the basic use-case needs, so gets the job done. > Also it is designed with frontend (common core framework) + backend > (hyper visor specific comm and memory sharing) structure for portability. > We just can't limit this feature to Xen because we want to use the same > uapis not only for Xen but also other applicable hypervisor, like ACORN. See the discussion around udmabuf and the needs for kvm. I think trying to make an ioctl/uapi that works for multiple hypervisors is misguided - it likely won't work. On top of that the 2nd hypervisor you're aiming to support is ACRN. That's not even upstream yet, nor have I seen any patches proposing to land linux support for ACRN. Since it's not upstream, it doesn't really matter for upstream consideration. I'm doubting that ACRN will use the same grant references as xen, so the same uapi won't work on ACRN as on Xen anyway. > So I am wondering we can start with this hyper_dmabuf then modify it for > your use-case if needed and polish and fix any glitches if we want to > to use this for all general dma-buf usecases. Imo xen-zcopy is a much more reasonable starting point for upstream, which can then be extended (if really proven to be necessary). > Also, I still have one unresolved question regarding the export/import flow > in both of hyper_dmabuf and xen-zcopy. > > @danvet: Would this flow (guest1->import existing dmabuf->share underlying > pages->guest2->map shared pages->create/export dmabuf) be acceptable now? I think if you just look at the pages, and make sure you handle the sg_page == NULL case it's ok-ish. It's not great, but mostly it should work. The real trouble with hyperdmabuf was the forwarding of all these calls, instead of just passing around a list of grant references. -Daniel > > Regards, > DW > > On Mon, Apr 16, 2018 at 05:33:46PM +0300, Oleksandr Andrushchenko wrote: > > Hello, all! > > > > After discussing xen-zcopy and hyper-dmabuf [1] approaches > > > > it seems that xen-zcopy can be made not depend on DRM core any more > > > > and be dma-buf centric (which it in fact is). > > > > The DRM code was mostly there for dma-buf's FD import/export > > > > with DRM PRIME UAPI and with DRM use-cases in mind, but it comes out that if > > > > the proposed 2 IOCTLs (DRM_XEN_ZCOPY_DUMB_FROM_REFS and > > DRM_XEN_ZCOPY_DUMB_TO_REFS) > > > > are extended to also provide a file descriptor of the corresponding dma-buf, > > then > > > > PRIME stuff in the driver is not needed anymore. > > > > That being said, xen-zcopy can safely be detached from DRM and moved from > > > > drivers/gpu/drm/xen into drivers/xen/dma-buf-backend(?). > > > > This driver then becomes a universal way to turn any shared buffer between > > Dom0/DomD > > > > and DomU(s) into a dma-buf, e.g. one can create a dma-buf from any grant > > references > > > > or represent a dma-buf as grant-references for export. > > > > This way the driver can be used not only for DRM use-cases, but also for > > other > > > > use-cases which may require zero copying between domains. > > > > For example, the use-cases we are about to work in the nearest future will > > use > > > > V4L, e.g. we plan to support cameras, codecs etc. and all these will benefit > > > > from zero copying much. Potentially, even block/net devices may benefit, > > > > but this needs some evaluation. > > > > > > I would love to hear comments for authors of the hyper-dmabuf > > > > and Xen community, as well as DRI-Devel and other interested parties. > > > > > > Thank you, > > > > Oleksandr > > > > > > On 03/29/2018 04:19 PM, Oleksandr Andrushchenko wrote: > > >From: Oleksandr Andrushchenko > > > > > >Hello! > > > > > >When using Xen PV DRM frontend driver then on backend side one will need > > >to do copying of display buffers' contents (filled by the > > >frontend's user-space) into buffers allocated at the backend side. > > >Taking into account the size of display buffers and frames per seconds > > >it may result in unneeded huge data bus occupation and performance loss. > > > > > >This helper driver allows implementing zero-copying us
4.17.0-rc1 doesn't boot.
Hi, my notebook doesn't boot with 4.17.0-rc1. Booting stops right after displaying "loading initial ramdisk..". No further displays. Also nothing is wriiten to the logs. First known bad kernel is: 4.16.0-12564-g6b0a02e Last known good kernel is: 4.16.0-12548-g71b8ebb Maybe the problem came in with: 6b0a02e: "Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" Thanks, Jörg
Re: [PATCH v3] selftests/livepatch: introduce tests
On Mon, 16 Apr 2018, Petr Mladek wrote: > On Mon 2018-04-16 13:33:55, Miroslav Benes wrote: > > On Fri, 13 Apr 2018, Joe Lawrence wrote: > > > Thanks for reviewing. I'll hold off on posting v4 until Petr (and > > > others) get a chance to comment. Perhaps there are other tests that > > > would be helpful? > > > I think it would be useful to have tests for a stack checking and a > > consistency. Nicolai has written some lately for our internal testing, but > > it would take some time to transform them appropriately, I think. > > The future of the stack handling is not clear at the moment. We should > wait how the discussion goes before spending time on test cases for > the current behavior. You're talking about something different. We have to check stacks of all tasks while patching in order to achieve consistency. Tests for that would be useful. Miroslav
Re: [PATCH] doc: Add vendor prefix for Kaohsiung
Hi Rob, > On Thu, Apr 12, 2018 at 04:34:01PM +0200, Lukasz Majewski wrote: > > The 'kao' entry has been added to vendor-prefixes.txt to indicate > > products from Kaohsiung Opto-Electronics Inc. > > kao or... > > > > > Signed-off-by: Lukasz Majewski > > --- > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > > b/Documentation/devicetree/bindings/vendor-prefixes.txt index > > 8ff7eadc8bef..f995a876d2cc 100644 --- > > a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ > > b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -184,6 > > +184,7 @@ khadasKhadas kiebackpeterKieback & Peter GmbH > > kinetic Kinetic Technologies > > kingnovel Kingnovel Technology Co., Ltd. > > +koeKaohsiung Opto-Electronics Inc. > > koe? Ach... typo. This should be koe. I will fix this in v2. > > > kosagi Sutajio Ko-Usagi PTE Ltd. > > kyoKyocera Corporation > > lacie LaCie > > -- > > 2.11.0 > > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgp3kpcyjkcGJ.pgp Description: OpenPGP digital signature
Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function
On Mon, Apr 16, 2018 at 08:21:09PM +0200, Stefan Agner wrote:
> On 16.04.2018 18:08, Stephen Warren wrote:
> > On 04/16/2018 09:56 AM, Stefan Agner wrote:
> >> On 27.03.2018 14:16, Dmitry Osipenko wrote:
> >>> On 27.03.2018 14:54, Robin Murphy wrote:
> On 26/03/18 22:20, Dmitry Osipenko wrote:
> > On 25.03.2018 21:09, Stefan Agner wrote:
> >> As documented in GCC naked functions should only use Basic asm
> >> syntax. The Extended asm or mixture of Basic asm and "C" code is
> >> not guaranteed. Currently this works because it was hard coded
> >> to follow and check GCC behavior for arguments and register
> >> placement.
> >>
> >> Furthermore with clang using parameters in Extended asm in a
> >> naked function is not supported:
> >> arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
> >> references not allowed in naked functions
> >> : "r" (type), "r" (arg1), "r" (arg2)
> >> ^
> >>
> >> Use a regular function to be more portable. This aligns also with
> >> the other smc call implementations e.g. in qcom_scm-32.c and
> >> bcm_kona_smc.c.
> >>
> >> Cc: Dmitry Osipenko
> >> Cc: Stephen Warren
> >> Cc: Thierry Reding
> >> Signed-off-by: Stefan Agner
> >> ---
> >> Changes in v2:
> >> - Keep stmfd/ldmfd to avoid potential ABI issues
> >>
> >> arch/arm/firmware/trusted_foundations.c | 14 +-
> >> 1 file changed, 9 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/arm/firmware/trusted_foundations.c
> >> b/arch/arm/firmware/trusted_foundations.c
> >> index 3fb1b5a1dce9..689e6565abfc 100644
> >> --- a/arch/arm/firmware/trusted_foundations.c
> >> +++ b/arch/arm/firmware/trusted_foundations.c
> >> @@ -31,21 +31,25 @@
> >> static unsigned long cpu_boot_addr;
> >> -static void __naked tf_generic_smc(u32 type, u32 arg1, u32 arg2)
> >> +static void tf_generic_smc(u32 type, u32 arg1, u32 arg2)
> >> {
> >> + register u32 r0 asm("r0") = type;
> >> + register u32 r1 asm("r1") = arg1;
> >> + register u32 r2 asm("r2") = arg2;
> >> +
> >> asm volatile(
> >> ".arch_extension sec\n\t"
> >> - "stmfd sp!, {r4 - r11, lr}\n\t"
> >> + "stmfd sp!, {r4 - r11}\n\t"
> >> __asmeq("%0", "r0")
> >> __asmeq("%1", "r1")
> >> __asmeq("%2", "r2")
> >> "mov r3, #0\n\t"
> >> "mov r4, #0\n\t"
> >> "smc #0\n\t"
> >> - "ldmfd sp!, {r4 - r11, pc}"
> >> + "ldmfd sp!, {r4 - r11}\n\t"
> >> :
> >> - : "r" (type), "r" (arg1), "r" (arg2)
> >> - : "memory");
> >> + : "r" (r0), "r" (r1), "r" (r2)
> >> + : "memory", "r3", "r12", "lr");
> >
> > Although seems "lr" won't be affected by SMC invocation because it
> > should be
> > banked and hence could be omitted entirely from the code. Maybe
> > somebody could
> > confirm this.
> Strictly per the letter of the architecture, the SMC could be trapped to
> Hyp
> mode, and a hypervisor might clobber LR_usr in the process of forwarding
> the
> call to the firmware secure monitor (since Hyp doesn't have a banked LR
> of its
> own). Admittedly there are probably no real systems with the appropriate
> hardware/software combination to hit that, but on the other hand if this
> gets
> inlined where the compiler has already created a stack frame then an LR
> clobber
> is essentially free, so I reckon we're better off keeping it for
> reassurance.
> This isn't exactly a critical fast path anyway.
> >>>
> >>> Okay, thank you for the clarification.
> >>
> >> So it seems this change is fine?
> >>
> >> Stephen, you picked up changes for this driver before, is this patch
> >> going through your tree?
> >
> > You had best ask Thierry; he's taken over Tegra maintenance upstream.
> > But that said, don't files in arch/arm go through Russell?
>
> I think the last patches applied to that file went through your tree.
>
> Thierry, Russel, any preferences?
I don't mind picking this up into the Tegra tree. Might be a good idea
to move this into drivers/firmware, though, since that's where all the
other firmware-related drivers reside.
Firmware code, such as the BPMP driver, usually goes through ARM-SoC
these days. I think this is in the same category.
Russell, any objections to me picking this patch up and moving it into
drivers/firmware?
Thanks,
Thierry
signature.asc
Description: PGP signature
Re: 4.17.0-rc1 doesn't boot.
On Tue, Apr 17, 2018 at 10:00:25AM +0200, Jörg Otte wrote: > Maybe the problem came in with: > 6b0a02e: "Merge branch 'x86-pti-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" Fetch latest Linus master and try again - there might be a relevant fix there. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v5 2/7] clk: meson: aoclk: refactor common code into dedicated file
Hi Jerome
On 04/16/18 18:38, Jerome Brunet wrote:
>> + */
>> +for (clkid = 0; clkid < data->num_clks; clkid++) {
>> +data->clks[clkid]->map = regmap;
>> +
>> +ret = devm_clk_hw_register(dev, data->hw_data->hws[clkid]);
>> +if (ret)
>> +return ret;
>> +}
>> +
>> +return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
>> +(void *) data->hw_data);
>> +}
> Missing new line here. Please run checkpatch and pay attention to git warnings
> about whitespace errors.
>
I think we actually need to avoid this extra new line, or what's the
benefits with new line?
and besides， I didn't see any complaint from checkpatch.pl ..
./scripts/checkpatch.pl
0002-clk-meson-aoclk-refactor-common-code-into-dedicated-.patch
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#235:
new file mode 100644
total: 0 errors, 1 warnings, 302 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0002-clk-meson-aoclk-refactor-common-code-into-dedicated-.patch has
style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Yixun
Re: [PATCH v5 2/7] clk: meson: aoclk: refactor common code into dedicated file
Hi jerome
On 04/16/18 19:34, Jerome Brunet wrote:
> On Mon, 2018-04-09 at 22:37 +0800, Yixun Lan wrote:
>> We try to refactor the common code into one dedicated file,
>> while preparing to add new Meson-AXG aoclk driver, this would
>> help us to better share the code by all aoclk drivers.
>>
>> Suggested-by: Jerome Brunet
>> Signed-off-by: Yixun Lan
>> ---
>> drivers/clk/meson/Kconfig | 7
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/gxbb-aoclk.c | 91
>> ++---
>> drivers/clk/meson/gxbb-aoclk.h | 7
>> drivers/clk/meson/meson-aoclk.c | 82 +
>> drivers/clk/meson/meson-aoclk.h | 35
>> 6 files changed, 163 insertions(+), 60 deletions(-)
>> create mode 100644 drivers/clk/meson/meson-aoclk.c
>> create mode 100644 drivers/clk/meson/meson-aoclk.h
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index d5cbec522aec..fddc7ec7b820 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -3,6 +3,12 @@ config COMMON_CLK_AMLOGIC
>> depends on OF
>> depends on ARCH_MESON || COMPILE_TEST
>>
>> +config COMMON_CLK_MESON_AO
>> +bool
>> +depends on OF
>> +depends on ARCH_MESON || COMPILE_TEST
>> +select COMMON_CLK_REGMAP_MESON
>> +
>> config COMMON_CLK_REGMAP_MESON
>> bool
>> select REGMAP
>> @@ -21,6 +27,7 @@ config COMMON_CLK_GXBB
>> bool
>> depends on COMMON_CLK_AMLOGIC
>> select RESET_CONTROLLER
>> +select COMMON_CLK_MESON_AO
>> select COMMON_CLK_REGMAP_MESON
>> select MFD_SYSCON
>> help
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index ffee82e60b7a..0a8df284f4e7 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -3,6 +3,7 @@
>> #
>>
>> obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-audio-divider.o
>> +obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>> obj-$(CONFIG_COMMON_CLK_GXBB)+= gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
>> obj-$(CONFIG_COMMON_CLK_AXG) += axg.o
>> diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c
>> index eebb580b9e0f..f2e0640a7f74 100644
>> --- a/drivers/clk/meson/gxbb-aoclk.c
>> +++ b/drivers/clk/meson/gxbb-aoclk.c
>> @@ -52,39 +52,13 @@
>> * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> */
>> -#include
>> -#include
>> #include
>
>> #include
> Not required anymore
>
will remove
>> #include
>> -#include
>> #include
> Not required
>
will remove
>> -#include
>
>> -#include
>> -#include
> Please keep these 2 here
>
see comments below
>> #include "clk-regmap.h"
>> #include "gxbb-aoclk.h"
>>
>> -struct gxbb_aoclk_reset_controller {
>> -struct reset_controller_dev reset;
>> -unsigned int *data;
>> -struct regmap *regmap;
>> -};
>> -
>> -static int gxbb_aoclk_do_reset(struct reset_controller_dev *rcdev,
>> - unsigned long id)
>> -{
>> -struct gxbb_aoclk_reset_controller *reset =
>> -container_of(rcdev, struct gxbb_aoclk_reset_controller, reset);
>> -
>> -return regmap_write(reset->regmap, AO_RTI_GEN_CNTL_REG0,
>> -BIT(reset->data[id]));
>> -}
>> -
>> -static const struct reset_control_ops gxbb_aoclk_reset_ops = {
>> -.reset = gxbb_aoclk_do_reset,
>> -};
>> -
>> #define GXBB_AO_GATE(_name, _bit) \
>> static struct clk_regmap _name##_ao = {
>> \
>> .data = &(struct clk_regmap_gate_data) {\
>> @@ -117,7 +91,7 @@ static struct aoclk_cec_32k cec_32k_ao = {
>> },
>> };
>>
>> -static unsigned int gxbb_aoclk_reset[] = {
>> +static const unsigned int gxbb_aoclk_reset[] = {
>> [RESET_AO_REMOTE] = 16,
>> [RESET_AO_I2C_MASTER] = 18,
>> [RESET_AO_I2C_SLAVE] = 19,
>> @@ -135,7 +109,7 @@ static struct clk_regmap *gxbb_aoclk_gate[] = {
>> [CLKID_AO_IR_BLASTER] = &ir_blaster_ao,
>> };
>>
>> -static struct clk_hw_onecell_data gxbb_aoclk_onecell_data = {
>> +static const struct clk_hw_onecell_data gxbb_aoclk_onecell_data = {
>> .hws = {
>> [CLKID_AO_REMOTE] = &remote_ao.hw,
>> [CLKID_AO_I2C_MASTER] = &i2c_master_ao.hw,
>> @@ -145,58 +119,55 @@ static struct clk_hw_onecell_data
>> gxbb_aoclk_onecell_data = {
>> [CLKID_AO_IR_BLASTER] = &ir_blaster_ao.hw,
>> [CLKID_AO_CEC_32K] = &cec_32k_ao.hw,
>> },
>> -.num = 7,
>> +.num = NR_CLKS,
>> };
>>
>> -static int gxbb_aoclkc_probe(struct platform_device *pdev)
>> +static int gxbb_register_cec_ao_32k(struct platform_device *pdev)
>> {
>> -struct gxbb_aoclk_reset_controller *rstc;
>> struct device *dev = &pdev->dev;
>> struc
Re: [PATCH v5 5/7] clk: meson-axg: Add AO Clock and Reset controller driver
Hi Jerome:
see my comments below
On 04/16/18 19:45, Jerome Brunet wrote:
> On Mon, 2018-04-09 at 22:37 +0800, Yixun Lan wrote:
>> From: Qiufang Dai
>>
>> Adds a Clock and Reset controller driver for the Always-On part
>> of the Amlogic Meson-AXG SoC.
>>
>> Signed-off-by: Qiufang Dai
>> Signed-off-by: Yixun Lan
>> ---
>> drivers/clk/meson/Kconfig | 1 +
>> drivers/clk/meson/Makefile| 2 +-
>> drivers/clk/meson/axg-aoclk.c | 164
>> ++
>> drivers/clk/meson/axg-aoclk.h | 31
>> 4 files changed, 197 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/clk/meson/axg-aoclk.c
>> create mode 100644 drivers/clk/meson/axg-aoclk.h
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index fddc7ec7b820..815659eebea3 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -38,6 +38,7 @@ config COMMON_CLK_AXG
>> bool
>> depends on COMMON_CLK_AMLOGIC
>> select RESET_CONTROLLER
>> +select COMMON_CLK_MESON_AO
>> select COMMON_CLK_REGMAP_MESON
>> select MFD_SYSCON
>> help
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 0a8df284f4e7..d0d13aeb369a 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -6,5 +6,5 @@ obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o
>> clk-audio-divider.o
>> obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>> obj-$(CONFIG_COMMON_CLK_GXBB)+= gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
>> -obj-$(CONFIG_COMMON_CLK_AXG) += axg.o
>> +obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_REGMAP_MESON) += clk-regmap.o
>> diff --git a/drivers/clk/meson/axg-aoclk.c b/drivers/clk/meson/axg-aoclk.c
>> new file mode 100644
>> index ..cb56d809d3df
>> --- /dev/null
>> +++ b/drivers/clk/meson/axg-aoclk.c
>> @@ -0,0 +1,164 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Amlogic Meson-AXG Clock Controller Driver
>> + *
>> + * Copyright (c) 2016 Baylibre SAS.
>> + * Author: Michael Turquette
>> + *
>> + * Copyright (c) 2018 Amlogic, inc.
>> + * Author: Qiufang Dai
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
> Not required
>
will remove it
>> +#include "clkc.h"
> Why do you need this? looks like clk-regmap.h would be enough here ?
>
you right, I will adjust
>> +#include "axg-aoclk.h"
>> +
>> +#define AXG_AO_GATE(_name, _bit)\
>> +static struct clk_regmap _name##_ao = {
>> \
>> +.data = &(struct clk_regmap_gate_data) {\
>> +.offset = (AO_RTI_GEN_CNTL_REG0), \
>> +.bit_idx = (_bit), \
>> +}, \
>> +.hw.init = &(struct clk_init_data) {\
>> +.name = #_name "_ao", \
>> +.ops = &clk_regmap_gate_ops,\
>> +.parent_names = (const char *[]){ "clk81" },\
>> +.num_parents = 1, \
>> +.flags = CLK_IGNORE_UNUSED, \
>> +}, \
>> +}
>> +
>> +AXG_AO_GATE(remote, 0);
>> +AXG_AO_GATE(i2c_master, 1);
>> +AXG_AO_GATE(i2c_slave, 2);
>> +AXG_AO_GATE(uart1, 3);
>> +AXG_AO_GATE(uart2, 5);
>> +AXG_AO_GATE(ir_blaster, 6);
>> +AXG_AO_GATE(saradc, 7);
>> +
>> +static struct clk_regmap ao_clk81 = {
>> +.data = &(struct clk_regmap_mux_data) {
>> +.offset = AO_RTI_PWR_CNTL_REG0,
>> +.mask = 0x1,
>> +.shift = 8,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "ao_clk81",
>> +.ops = &clk_regmap_mux_ro_ops,
>> +.parent_names = (const char *[]){ "clk81", "ao_alt_xtal"},
>> +.num_parents = 2,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_saradc_mux = {
>> +.data = &(struct clk_regmap_mux_data) {
>> +.offset = AO_SAR_CLK,
>> +.mask = 0x3,
>> +.shift = 9,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "axg_saradc_mux",
>> +.ops = &clk_regmap_mux_ops,
>> +.parent_names = (const char *[]){ "xtal", "ao_clk81" },
>> +.num_parents = 2,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_saradc_div = {
>> +.data = &(struct clk_regmap_div_data) {
>> +.offset = AO_SAR_CLK,
>> +.shift = 0,
>> +.width = 8,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "axg_saradc_div",
>> +.ops = &clk_regmap_divider_ops,
>> +.parent_names
RE: [SIL2review] [PATCH] i2c: img-scb: fix PM device usage count
Hi, > Is it easily recognizable if the drivers check the error code because > there is a reason or if they do it "out of habit"? Probably by looking closely at the implementation of the PM callouts for the driver, but I couldn't find a pattern that would be easy to recognize. Maybe I didn't look close enough ;-) I concur that removing the check would be a better approach if it's clear that it's just done "out of habit". Actually, the real problem is to find the drivers that need to have the check in, add/fix it for them, and remove it for all others. Unfortunately, all I'm currently able to do is finding the parts that are inconsistent. Tobias
Re: [PATCH v2 2/3] Input: ti_am335x_tsc - Ack pending IRQs at probe and before suspend
On Monday 16 April 2018 11:29 PM, Dmitry Torokhov wrote:
> On Sat, Apr 14, 2018 at 03:21:52PM +0530, Vignesh R wrote:
>> From: Grygorii Strashko
>>
>> It is seen that just enabling the TSC module triggers a HW_PEN IRQ
>> without any interaction with touchscreen by user. This results in first
>> suspend/resume sequence to fail as system immediately wakes up from
>> suspend as soon as HW_PEN IRQ is enabled in suspend handler due to the
>> pending IRQ. Therefore clear all IRQs at probe and also in suspend
>
> Are the interrupts configured as edge?
>
No, its a level interrupt.
>> callback for sanity.
>>
>> Signed-off-by: Grygorii Strashko
>> Signed-off-by: Vignesh R
>> Acked-by: Lee Jones
>> ---
>>
>> v2: Add Acks from v1.
>>
>> drivers/input/touchscreen/ti_am335x_tsc.c | 2 ++
>> include/linux/mfd/ti_am335x_tscadc.h | 1 +
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
>> b/drivers/input/touchscreen/ti_am335x_tsc.c
>> index 810e05c9c4f5..dcd9db768169 100644
>> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
>> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
>> @@ -439,6 +439,7 @@ static int titsc_probe(struct platform_device *pdev)
>> dev_err(&pdev->dev, "irq wake enable failed.\n");
>> }
>>
>> + titsc_writel(ts_dev, REG_IRQSTATUS, IRQENB_MASK);
>> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
>> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS);
>
> Out of curiosity, should this be:
>
> titsc_writel(ts_dev, REG_IRQENABLE,
> IRQENB_FIFO0THRES | IRQENB_EOS);
>
> ?
>
> Because 2nd titsc_writel() overwrites the first? Or separate writes to
> the same register are distinct?
>
As per TRM, writing 0 to any bit of REG_IRQENABLE has no effect(IRQs are
cleared by writing to REG_IRQCLR). Therefore, second write does not
overwrite the first. I agree that there is nothing that prevents us from
enabling both IRQs in a single write. That can be a separate cleanup patch.
>> err = titsc_config_wires(ts_dev);
>> @@ -504,6 +505,7 @@ static int __maybe_unused titsc_suspend(struct device
>> *dev)
>>
>> tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
>> if (device_may_wakeup(tscadc_dev->dev)) {
>> + titsc_writel(ts_dev, REG_IRQSTATUS, IRQENB_MASK);
>
> The comment in titsc_irq() says that we should not be touching
> IRQENB_FIFO0THRES as it is used by another driver, but here we are
> whacking it. Can you elaborate why this is safe?
>
> You might need to rework the interrupt handling since you have several
> drivers...
>
I guess you meant IRQENB_FIFO1THRES(FIFO0 is used for TSC and FIFO1 is
ADC). Yes, this driver must not touch FIFO1 related IRQs, I will fix
that up in next version.
>> idle = titsc_readl(ts_dev, REG_IRQENABLE);
>> titsc_writel(ts_dev, REG_IRQENABLE,
>> (idle | IRQENB_HW_PEN));
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
>> b/include/linux/mfd/ti_am335x_tscadc.h
>> index b9a53e013bff..1a6a34f726cc 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -63,6 +63,7 @@
>> #define IRQENB_FIFO1OVRRUN BIT(6)
>> #define IRQENB_FIFO1UNDRFLW BIT(7)
>> #define IRQENB_PENUP BIT(9)
>> +#define IRQENB_MASK (0x7FF)
>>
>> /* Step Configuration */
>> #define STEPCONFIG_MODE_MASK (3 << 0)
>> --
>> 2.17.0
>>
>
> Thanks.
>
> --
> Dmitry
--
Regards
Vignesh
Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/17/2018 10:59 AM, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: Yeah, I definitely agree on the idea of expanding the use case to the general domain where dmabuf sharing is used. However, what you are targetting with proposed changes is identical to the core design of hyper_dmabuf. On top of this basic functionalities, hyper_dmabuf has driver level inter-domain communication, that is needed for dma-buf remote tracking (no fence forwarding though), event triggering and event handling, extra meta data exchange and hyper_dmabuf_id that represents grefs (grefs are shared implicitly on driver level) This really isn't a positive design aspect of hyperdmabuf imo. The core code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is very simple & clean. If there's a clear need later on we can extend that. But for now xen-zcopy seems to cover the basic use-case needs, so gets the job done. After we decided to remove DRM PRIME code from the zcopy driver I think we can extend the existing Xen drivers instead of introducing a new one: gntdev [1], [2] - to handle export/import of the dma-bufs to/from grefs balloon [3] - to allow allocating CMA buffers Also it is designed with frontend (common core framework) + backend (hyper visor specific comm and memory sharing) structure for portability. We just can't limit this feature to Xen because we want to use the same uapis not only for Xen but also other applicable hypervisor, like ACORN. See the discussion around udmabuf and the needs for kvm. I think trying to make an ioctl/uapi that works for multiple hypervisors is misguided - it likely won't work. On top of that the 2nd hypervisor you're aiming to support is ACRN. That's not even upstream yet, nor have I seen any patches proposing to land linux support for ACRN. Since it's not upstream, it doesn't really matter for upstream consideration. I'm doubting that ACRN will use the same grant references as xen, so the same uapi won't work on ACRN as on Xen anyway. So I am wondering we can start with this hyper_dmabuf then modify it for your use-case if needed and polish and fix any glitches if we want to to use this for all general dma-buf usecases. Imo xen-zcopy is a much more reasonable starting point for upstream, which can then be extended (if really proven to be necessary). Also, I still have one unresolved question regarding the export/import flow in both of hyper_dmabuf and xen-zcopy. @danvet: Would this flow (guest1->import existing dmabuf->share underlying pages->guest2->map shared pages->create/export dmabuf) be acceptable now? I think if you just look at the pages, and make sure you handle the sg_page == NULL case it's ok-ish. It's not great, but mostly it should work. The real trouble with hyperdmabuf was the forwarding of all these calls, instead of just passing around a list of grant references. -Daniel Regards, DW On Mon, Apr 16, 2018 at 05:33:46PM +0300, Oleksandr Andrushchenko wrote: Hello, all! After discussing xen-zcopy and hyper-dmabuf [1] approaches Even more context for the discussion [4], so Xen community can catch up it seems that xen-zcopy can be made not depend on DRM core any more and be dma-buf centric (which it in fact is). The DRM code was mostly there for dma-buf's FD import/export with DRM PRIME UAPI and with DRM use-cases in mind, but it comes out that if the proposed 2 IOCTLs (DRM_XEN_ZCOPY_DUMB_FROM_REFS and DRM_XEN_ZCOPY_DUMB_TO_REFS) are extended to also provide a file descriptor of the corresponding dma-buf, then PRIME stuff in the driver is not needed anymore. That being said, xen-zcopy can safely be detached from DRM and moved from drivers/gpu/drm/xen into drivers/xen/dma-buf-backend(?). This driver then becomes a universal way to turn any shared buffer between Dom0/DomD and DomU(s) into a dma-buf, e.g. one can create a dma-buf from any grant references or represent a dma-buf as grant-references for export. This way the driver can be used not only for DRM use-cases, but also for other use-cases which may require zero copying between domains. For example, the use-cases we are about to work in the nearest future will use V4L, e.g. we plan to support cameras, codecs etc. and all these will benefit from zero copying much. Potentially, even block/net devices may benefit, but this needs some evaluation. I would love to hear comments for authors of the hyper-dmabuf and Xen community, as well as DRI-Devel and other interested parties. Thank you, Oleksandr On 03/29/2018 04:19 PM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello! When using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per seconds it may result in unneeded huge data bus occupation and performance loss. This he
Re: [PATCH v2 3/3] Input: ti_am335x_tsc - Prevent system suspend when TSC is in use
On Monday 16 April 2018 11:31 PM, Dmitry Torokhov wrote:
> On Sat, Apr 14, 2018 at 03:21:53PM +0530, Vignesh R wrote:
>> From: Grygorii Strashko
>>
>> Prevent system suspend while user has finger on touch screen,
>> because TSC is wakeup source and suspending device while in use will
>> result in failure to disable the module.
>> This patch uses pm_stay_awake() and pm_relax() APIs to prevent and
>> resume system suspend as required.
>
> This looks like common behavior for all touchscreens and many other
> input devices, but other systems seem to cope without having to add
> pm_stay_awake() and pm_relax(). I wonder why your system requires it and
> whether we can generalize this somehow.
>
Not sure if other touch drivers with IP level wakeup, have been tested
in the same way as above scenario. But, if user has finger on
touchscreen, its better not to enter suspend until user stops
interacting with wakeup source.
I see pm_stay_awake()/pm_relax() pair as the only way to stop system
suspend when wakeup source is active. Also, one other touchscreen
driver(zforce_ts.c) and gpio_keys.c use pm_stay_awake()/pm_relax() pair.
Regards
Vignesh
>>
>> Signed-off-by: Grygorii Strashko
>> Signed-off-by: Vignesh R
>> ---
>>
>> v2: No changes.
>>
>> drivers/input/touchscreen/ti_am335x_tsc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
>> b/drivers/input/touchscreen/ti_am335x_tsc.c
>> index dcd9db768169..43b22e071842 100644
>> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
>> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
>> @@ -275,6 +275,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
>> if (status & IRQENB_HW_PEN) {
>> ts_dev->pen_down = true;
>> irqclr |= IRQENB_HW_PEN;
>> + pm_stay_awake(ts_dev->mfd_tscadc->dev);
>> }
>>
>> if (status & IRQENB_PENUP) {
>> @@ -284,6 +285,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
>> input_report_key(input_dev, BTN_TOUCH, 0);
>> input_report_abs(input_dev, ABS_PRESSURE, 0);
>> input_sync(input_dev);
>> + pm_relax(ts_dev->mfd_tscadc->dev);
>> } else {
>> ts_dev->pen_down = true;
>> }
>> @@ -524,6 +526,7 @@ static int __maybe_unused titsc_resume(struct device
>> *dev)
>> titsc_writel(ts_dev, REG_IRQWAKEUP,
>> 0x00);
>> titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
>> + pm_relax(ts_dev->mfd_tscadc->dev);
>> }
>> titsc_step_config(ts_dev);
>> titsc_writel(ts_dev, REG_FIFO0THR,
>> --
>> 2.17.0
>>
>
> Thanks.
>
> --
> Dmitry
[PATCH] regulator: lp87565: Add margin while populating ramp_delay
The slew rate might need a +/- 15% margin as per the latest data manual:
http://www.ti.com/lit/ds/snvsb22/snvsb22.pdf
Hence take a conservative approach to program 85% of the original
hardware slew rate so that the software accommodates the margin
delay while voltage switching. Hence reduce the default ramp_delay
populated in the descriptors also by 15%.
Signed-off-by: Keerthy
---
drivers/regulator/lp87565-regulator.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 04a76ec..9ee08d6 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -95,6 +95,10 @@ static int lp87565_buck_set_ramp_delay(struct regulator_dev
*rdev,
rdev->constraints->ramp_delay = lp87565_buck_ramp_delay[reg];
+ /* Conservatively give a 15% margin */
+ rdev->constraints->ramp_delay =
+ rdev->constraints->ramp_delay * 85 / 100;
+
return 0;
}
@@ -154,32 +158,32 @@ static const struct lp87565_regulator regulators[] = {
LP87565_REGULATOR("BUCK0", LP87565_BUCK_0, "buck0", lp87565_buck_ops,
256, LP87565_REG_BUCK0_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK0_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3800,
+ LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
LP87565_REGULATOR("BUCK1", LP87565_BUCK_1, "buck1", lp87565_buck_ops,
256, LP87565_REG_BUCK1_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK1_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3800,
+ LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK1_CTRL_2),
LP87565_REGULATOR("BUCK2", LP87565_BUCK_2, "buck2", lp87565_buck_ops,
256, LP87565_REG_BUCK2_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK2_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3800,
+ LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
LP87565_REGULATOR("BUCK3", LP87565_BUCK_3, "buck3", lp87565_buck_ops,
256, LP87565_REG_BUCK3_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK3_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3800,
+ LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK3_CTRL_2),
LP87565_REGULATOR("BUCK10", LP87565_BUCK_10, "buck10", lp87565_buck_ops,
256, LP87565_REG_BUCK0_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK0_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3800,
+ LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
LP87565_REGULATOR("BUCK23", LP87565_BUCK_23, "buck23", lp87565_buck_ops,
256, LP87565_REG_BUCK2_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK2_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3800,
+ LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
};
--
1.9.1
Re: [PATCH v2 1/3] Input: ti_am335x_tsc - Mark IRQ as wakeup capable
Hi,
On Monday 16 April 2018 11:15 PM, Dmitry Torokhov wrote:
> On Sat, Apr 14, 2018 at 03:21:51PM +0530, Vignesh R wrote:
>> On AM335x, ti_am335x_tsc can wake up the system from suspend, mark the
>> IRQ as wakeup capable, so that device irq is not disabled during system
>> suspend.
>>
>> Signed-off-by: Vignesh R
>> ---
>>
>> v2: No changes
>>
>> drivers/input/touchscreen/ti_am335x_tsc.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
>> b/drivers/input/touchscreen/ti_am335x_tsc.c
>> index f1043ae71dcc..810e05c9c4f5 100644
>> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
>> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
>> @@ -27,6 +27,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -432,6 +433,12 @@ static int titsc_probe(struct platform_device *pdev)
>> goto err_free_mem;
>> }
>>
>> + if (device_may_wakeup(tscadc_dev->dev)) {
>> + err = dev_pm_set_wake_irq(tscadc_dev->dev, ts_dev->irq);
>
> Hmm, most of the drivers simply use enable_irq_wake()/disable_irq_wake()
> in suspend/resume paths
dev_pm_*_wake_irq() function are alternative to above
[1]:
For most drivers, we should be able to drop the following
boilerplate code from runtime_suspend and runtime_resume
functions:
...
device_init_wakeup(dev, true);
...
if (device_may_wakeup(dev))
enable_irq_wake(irq);
...
if (device_may_wakeup(dev))
disable_irq_wake(irq);
...
device_init_wakeup(dev, false);
...
We can replace it with just the following init and exit
time code:
...
device_init_wakeup(dev, true);
dev_pm_set_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/power/wakeirq.c?id=4990d4fe327b9d9a7a3be7103a82699406fdde69
I see device_may_wakeup() check is not required. Will drop that in next version.
> and use dev_pm_set_wake_irq() only for dedicated
> and distinct wake interrupts. Why do we not follow the same pattern
> here?
Thats dev_pm_*_dedicated_wake_irq()
Thanks for the review!
--
Regards
Vignesh
Re: [PATCH v6 07/11] ARM: sun9i: smp: Rename clusters's power-off
Hello!
On 4/17/2018 12:50 AM, Mylène Josserand wrote:
To prepare the support for sun8i-a83t, rename the variable name
s/variable/macro/ maybe? Also "rename the ... name" sounds tautological...
that handles the power-off of clusters because it is different from
sun9i-a80 to sun8i-a83t.
The power off register for clusters are different from a80 and a83t.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/mc_smp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index 727968d6a3e5..03f021d0c73e 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -60,7 +60,7 @@
#define PRCM_CPU_PO_RST_CTRL_CORE(n) BIT(n)
#define PRCM_CPU_PO_RST_CTRL_CORE_ALL 0xf
#define PRCM_PWROFF_GATING_REG(c) (0x100 + 0x4 * (c))
-#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
+#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I BIT(4)
#define PRCM_PWROFF_GATING_REG_CORE(n)BIT(n)
#define PRCM_PWR_SWITCH_REG(c, cpu) (0x140 + 0x10 * (c) + 0x4 * (cpu))
#define PRCM_CPU_SOFT_ENTRY_REG 0x164
@@ -255,7 +255,7 @@ static int sunxi_cluster_powerup(unsigned int cluster)
/* clear cluster power gate */
reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
- reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER;
+ reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
@@ -452,7 +452,7 @@ static int sunxi_cluster_powerdown(unsigned int cluster)
/* gate cluster power */
pr_debug("%s: gate cluster power\n", __func__);
reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
- reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
+ reg |= PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
MBR, Sergei
[PATCH] modules: Fix display of wrong module .text address
In kernel v4.16.0 the module .text address is displayed
wrong when using /sys/module/*/sections/.text file.
Commit ef0010a30935 ("vsprintf: don't use 'restricted_pointer()' when
not restricting")
is the first bad commit.
Here is the issue, using module qeth_l2 on s390 which is the
ethernet device driver:
[root@s35lp76 ~]# lsmod
Module Size Used by
qeth_l294208 1
...
[root@s35lp76 ~]# cat /proc/modules | egrep '^qeth_l2'
qeth_l2 94208 1 - Live 0x03ff80401000
^ This is the correct address in memory
[root@s35lp76 ~]# cat /sys/module/qeth_l2/sections/.text
0x18ea8363 < This is a wrong address
[root@s35lp76 ~]#
This breaks the perf tool which uses this address on s390
to calculate start of .text section in memory.
Fix this by printing the correct (unhashed) address.
Thanks to Jessica Yu for helping on this.
Suggested-by: Linus Torvalds
Signed-off-by: Thomas Richter
Cc: Jessica Yu
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index a6e43a5806a1..77ab7211ddef 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1472,7 +1472,7 @@ static ssize_t module_sect_show(struct module_attribute
*mattr,
{
struct module_sect_attr *sattr =
container_of(mattr, struct module_sect_attr, mattr);
- return sprintf(buf, "0x%pK\n", (void *)sattr->address);
+ return sprintf(buf, "%#lx\n", kptr_restrict < 2 ? sattr->address : 0);
}
static void free_sect_attrs(struct module_sect_attrs *sect_attrs)
--
2.14.3
Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.
> > > > Second, unrelated patches must never patch the same functions. > > > > Otherwise we would not be able to define which implementation > > > > should be used. This is especially important when a patch is > > > > removed and we need to fallback either to another patch or > > > > original code. Yes, it makes perfect sense. But it needs code > > > > that will check it, refuse loading the patch, ... It is not > > > > complicated. But it is rather additional code than > > > > simplification. I might make livepatching more safe > > > > but probably not simplify the code. > > > > > > We don't need to enforce that. The func stack can stay. If somebody > > > wants to patch the same function multiple times (without using > > > 'replace'), that's inadvisable, but it's also their business. They're > > > responsible for the tooling to ensure the patch stack order is sane. > > > > > > While it might make sense to ignore the patch stack (ordering) for > > the enable operation. Do we really want to ignore it when disabling > > a patch. > > > > By other words, do we want to allow disabling a patch that is in > > the middle of the stack, only partly in use? Does not this allow > > some other crazy scenarios? Is it really the user business? > > Will it make our life easier? > > If there's no longer a patch stack, then there's no concept of a middle. > We would expect the patches to be independent of one another, and so > disabling any of them independently would be harmless. > > If any of the patches share a func, and the user disables one in the > "middle", it's not our job to support that. The vendor / patch author > should prevent such cases from occurring with tooling, packaging, > documentation, etc. Or they can just use 'replace'. > > We can already have similar unexpected situations today. For example, > what if patch B is a cumulative superset of patch A, but the user > mistakenly loads patch A (without replace) *after* loading patch B? > Then some unforeseen craziness could ensue. > > We can't control all such scenarios (and that's ok), but we shouldn't > pretend that we support them. FWIW I agree with the above. Provided we keep the func stack. [...] > > The question is what to do with the stack of patches. It will have > > no meaning for the enable operation because it will be done > > automatically. But what about the disable/unregistrer operation? > > Assuming we got rid of the patch stack, would we even need to keep a > global list of patches anymore? There are places we walk through the list of patches (klp_add_nops() in this patch set, klp_module_coming()), so probably yes. Miroslav
Re: [PATCH 0/3] Fix an Atmel USBA UDC issue introducted in 4.17-rc1
On 16/04/2018 at 11:34, Romain Izard wrote: The use of GPIO descriptors takes care of inversion flags declared in the device tree. The conversion of the Atmel USBA UDC driver introduced in 4.17-rc1 missed it, and as a result the inversion will not work. In addition, cleanup the code to remove an include left behind after the suppression of the support of platform_data to declare USBA controllers. These changes have not been tested on any hardware, as I do not have a board that needs to use inverted GPIOs. Romain Izard (3): usb: gadget: udc: atmel: GPIO inversion is handled by gpiod usb: gadget: udc: atmel: Remove obsolete include usb: gadget: udc: atmel: Fix indenting To the whole series: Acked-by: Nicolas Ferre Thank you Romain. Best regards, Nicolas drivers/usb/gadget/udc/atmel_usba_udc.c | 22 ++ drivers/usb/gadget/udc/atmel_usba_udc.h | 1 - include/linux/usb/atmel_usba_udc.h | 24 3 files changed, 10 insertions(+), 37 deletions(-) delete mode 100644 include/linux/usb/atmel_usba_udc.h -- Nicolas Ferre
Re: [PATCH v2 1/5] ALSA: xen-front: Introduce Xen para-virtualized sound frontend driver
On 04/16/2018 03:25 PM, Juergen Gross wrote:
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Introduce skeleton of the para-virtualized Xen sound
frontend driver.
Initial handling for Xen bus states: implement
Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from sound para-virtualized
protocol: xen/interface/io/sndif.h.
Signed-off-by: Oleksandr Andrushchenko
Only one minor nit (see below). With that addressed (or fixed when
committing):
will fix
Reviewed-by: Juergen Gross
Thank you
Juergen
---
sound/Kconfig | 2 +
sound/Makefile| 2 +-
sound/xen/Kconfig | 10 +++
sound/xen/Makefile| 5 ++
sound/xen/xen_snd_front.c | 196 ++
sound/xen/xen_snd_front.h | 18 +
6 files changed, 232 insertions(+), 1 deletion(-)
create mode 100644 sound/xen/Kconfig
create mode 100644 sound/xen/Makefile
create mode 100644 sound/xen/xen_snd_front.c
create mode 100644 sound/xen/xen_snd_front.h
diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
new file mode 100644
index ..f406a8f52c51
--- /dev/null
+++ b/sound/xen/xen_snd_front.c
@@ -0,0 +1,196 @@
+static void sndback_changed(struct xenbus_device *xb_dev,
+ enum xenbus_state backend_state)
+{
+ struct xen_snd_front_info *front_info = dev_get_drvdata(&xb_dev->dev);
+ int ret;
+
+ dev_dbg(&xb_dev->dev, "Backend state is %s, front is %s\n",
+ xenbus_strstate(backend_state),
+ xenbus_strstate(xb_dev->state));
+
+ switch (backend_state) {
+ case XenbusStateReconfiguring:
+ /* fall through */
+ case XenbusStateReconfigured:
+ /* fall through */
+ case XenbusStateInitialised:
+ /* fall through */
+ break;
+
+ case XenbusStateInitialising:
+ /* recovering after backend unexpected closure */
+ sndback_disconnect(front_info);
+ break;
+
+ case XenbusStateInitWait:
+ /* recovering after backend unexpected closure */
+ sndback_disconnect(front_info);
+
+ ret = sndback_initwait(front_info);
+ if (ret < 0)
+ xenbus_dev_fatal(xb_dev, ret, "initializing frontend");
+ else
+ xenbus_switch_state(xb_dev, XenbusStateInitialised);
+ break;
+
+ case XenbusStateConnected:
+ if (xb_dev->state != XenbusStateInitialised)
+ break;
+
+ ret = sndback_connect(front_info);
+ if (ret < 0)
+ xenbus_dev_fatal(xb_dev, ret, "initializing frontend");
+ else
+ xenbus_switch_state(xb_dev, XenbusStateConnected);
+ break;
+
+ case XenbusStateClosing:
+ /*
+* in this state backend starts freeing resources,
+* so let it go into closed state first, so we can also
+* remove ours
+*/
Please start the sentence with a capital letter and end it with a
full stop.
Juergen
Re: [PATCH] modules: Fix display of wrong module .text address
On 04/17/2018 10:20 AM, Thomas Richter wrote:
> In kernel v4.16.0 the module .text address is displayed
> wrong when using /sys/module/*/sections/.text file.
> Commit ef0010a30935 ("vsprintf: don't use 'restricted_pointer()' when
> not restricting")
> is the first bad commit.
>
> Here is the issue, using module qeth_l2 on s390 which is the
> ethernet device driver:
>
> [root@s35lp76 ~]# lsmod
> Module Size Used by
> qeth_l294208 1
> ...
>
> [root@s35lp76 ~]# cat /proc/modules | egrep '^qeth_l2'
> qeth_l2 94208 1 - Live 0x03ff80401000
>^ This is the correct address in memory
> [root@s35lp76 ~]# cat /sys/module/qeth_l2/sections/.text
> 0x18ea8363 < This is a wrong address
> [root@s35lp76 ~]#
>
> This breaks the perf tool which uses this address on s390
> to calculate start of .text section in memory.
>
> Fix this by printing the correct (unhashed) address.
>
> Thanks to Jessica Yu for helping on this.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Thomas Richter
> Cc: Jessica Yu
CC stable?
> ---
> kernel/module.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index a6e43a5806a1..77ab7211ddef 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1472,7 +1472,7 @@ static ssize_t module_sect_show(struct module_attribute
> *mattr,
> {
> struct module_sect_attr *sattr =
> container_of(mattr, struct module_sect_attr, mattr);
> - return sprintf(buf, "0x%pK\n", (void *)sattr->address);
> + return sprintf(buf, "%#lx\n", kptr_restrict < 2 ? sattr->address : 0);
> }
>
> static void free_sect_attrs(struct module_sect_attrs *sect_attrs)
>
Re: EXT: Re: [PATCHv1] Input: atmel_mxt_ts - fix the firmware update
On 23/03/18 21:47, Nick Dyer wrote: On Thu, Mar 22, 2018 at 05:43:30PM +0100, Sebastian Reichel wrote: The automatic update mechanism will trigger an update if the info block CRCs are different between maxtouch configuration file (maxtouch.cfg) and chip. The driver compared the CRCs without retrieving the chip CRC, resulting always in a failure and firmware flashing action triggered. The patch will fix this issue by retrieving the chip info block CRC before the check. Thanks for raising this, I agree it's definitely something we want to fix. However, I'm not convinced you're solving the problem in the best way. You've attached it to the read_t9_resolution() code path, whereas the info block is common between T9 and T100 and works in the same way. Would you mind trying the below patch? I've dusted it off from some work that I did back in 2012 and it should solve your issue. It also has the benefit that by reading the information block and the object table into a contiguous region of memory, we can verify the checksum at probe time. This means we make sure that we are indeed talking to a chip that supports object protocol correctly. Thanks Nick. This looks like a better solution. Sebastian will test this and we can see the results. Nandor
Re: [PATCH 4/4] x86/CPU/AMD: Calculate LLC ID from number of sharing threads
On Mon, Mar 26, 2018 at 01:35:16AM -0500, Suravee Suthikulpanit wrote:
> diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
> index 54d04d5..67f4790 100644
> --- a/arch/x86/kernel/cpu/cacheinfo.c
> +++ b/arch/x86/kernel/cpu/cacheinfo.c
> @@ -637,6 +637,43 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
> return i;
> }
>
> +void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id)
> +{
> + /*
> + * We may have multiple LLCs if L3 caches exist, so check if we
> + * have an L3 cache by looking at the L3 cache CPUID leaf.
> + */
> + if (!cpuid_edx(0x8006))
> + return;
> +
> + if (c->x86 < 0x17) {
> + /* LLC is at the node level. */
> + per_cpu(cpu_llc_id, cpu) = node_id;
> + } else if (c->x86 == 0x17 &&
> +c->x86_model >= 0 && c->x86_model <= 0x1F) {
> + /*
> + * LLC is at the core complex level.
> + * Core complex id is ApicId[3] for these processors.
> + */
> + per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
> + } else {
> + /* LLC ID is calculated from the number of thread sharing. */
> + u32 eax, ebx, ecx, edx, num_sharing_cache = 0;
> + u32 llc_index = find_num_cache_leaves(c) - 1;
> +
> + cpuid_count(0x801d, llc_index, &eax, &ebx, &ecx, &edx);
> + if (eax)
> + num_sharing_cache = ((eax >> 14) & 0xfff) + 1;
> +
> + if (num_sharing_cache) {
> + int bits = get_count_order(num_sharing_cache) - 1;
> +
> + per_cpu(cpu_llc_id, cpu) = c->apicid >> bits;
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(cacheinfo_amd_init_llc_id);
That function needs to be exported to modules because...?
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node
Hi Michel,
On Tue, Apr 17, 2018 at 9:56 AM, Michel Pollet
wrote:
> On 13 April 2018 19:06, Rob Herring:
>> On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function system
>> > controller. This documents the node used to encapsulate it's sub
>> > drivers.
>> >
>> > Signed-off-by: Michel Pollet
>> > ---
>> > .../bindings/mfd/renesas,rzn1-sysctrl.txt | 23
>> ++
>> > 1 file changed, 23 insertions(+)
>> > create mode 100644
>> > Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> >
>> > diff --git
>> > a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > new file mode 100644
>> > index 000..9897f8f
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > @@ -0,0 +1,23 @@
>> > +DT bindings for the Renesas RZ/N1 System Controller
>> > +
>> > +== System Controller Node ==
>> > +
>> > +The system controller node currently only hosts a single sub-node to
>> > +handle the rebooting of the CPU. Eventually it will host the clock
>> > +driver, SMP start handler, watchdog etc.
>>
>> Please submit a complete binding for the h/w block.
>>
>> Again, if the only reason you have sub nodes is to define compatible strings
>> and in turn enumerate drivers, then you don't need the nodes in DT. DT is
>> not the only way to instantiate drivers.
>
> I can't document it before I have the code. There is 0.000% chance of my clock
> driver for example to be upstreamed the way I would imagine making it -- in
> fact pretty much any other driver will have to be reworked to fit, so
> documenting
> bindings first is impossible.
>
> So, if I understand correctly, you are telling me to make a 'sysctrl' driver
> and use
> platform_device to instantiate my sub-drivers? Isn't that what machine files
> used
> to do? And they are now banned?
>
> Geert, any guidance here?
It depends on how many and which subnodes you want to add to the sysctrl
node. Without a complete binding for the block, we cannot know.
If the major part will be the clock driver, I would make that the main
driver for the sysctrl node. The clock driver can easily register
e.g. a simple reset handler.
Cfr. the renesas-cpg-mssr driver, which also handles (module) resets.
There are plenty of other examples of drivers providing multiple
functionalities (e.g. pinctrl drivers also registering GPIO controllers).
If a monolithic driver becomes too large, it can still be split using the
MFD framework.
E.g. the BD9571 PMIC driver is split in an MFD core driver, and 2 drivers
for different functionalities:
drivers/gpio/gpio-bd9571mwv.c
drivers/mfd/bd9571mwv.c
drivers/regulator/bd9571mwv-regulator.c
include/linux/mfd/bd9571mwv.h
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 v2] doc: Add vendor prefix for Kaohsiung
The 'koe' entry has been added to vendor-prefixes.txt to indicate products from Kaohsiung Opto-Electronics Inc. Signed-off-by: Lukasz Majewski --- Changes for v2: - Replace 'kao' to 'koe' in commit message --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8ff7eadc8bef..f995a876d2cc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -184,6 +184,7 @@ khadas Khadas kiebackpeterKieback & Peter GmbH kinetic Kinetic Technologies kingnovel Kingnovel Technology Co., Ltd. +koeKaohsiung Opto-Electronics Inc. kosagi Sutajio Ko-Usagi PTE Ltd. kyoKyocera Corporation lacie LaCie -- 2.11.0
Re: [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
Hello, I guess the blocking patch in this patchset is the patch "add IEC958 channel status control helper". This patch has been reviewed several times, but did not get a ack so far. If you think these helpers will not be merged, I will reintegrate the corresponding code in stm driver. Please let me know, if I need to prepare a v2 without helpers, or if we can go further in the review of iec helpers patch ? Best regards olivier On 03/13/2018 05:27 PM, Olivier Moysan wrote: > This patchset adds support of iec958 controls to STM32 SAI driver. > > The patch makes use of iec958 control status helpers previously proposed > and discussed through the following threads: > https://patchwork.kernel.org/patch/8062601/ > https://patchwork.kernel.org/patch/8091551/ (v2) > https://patchwork.kernel.org/patch/8462961/ (v3) > https://patchwork.kernel.org/patch/8533731/ (v4) > > Olivier Moysan (3): >ALSA: pcm: add IEC958 channel status control helper >ASoC: stm32: sai: add iec958 controls support >ASoC: dmaengine_pcm: document process callback > > include/sound/dmaengine_pcm.h | 2 + > include/sound/pcm_iec958.h| 19 +++ > sound/core/pcm_iec958.c | 114 > ++ > sound/soc/stm/Kconfig | 1 + > sound/soc/stm/stm32_sai_sub.c | 101 - > 5 files changed, 225 insertions(+), 12 deletions(-) >
Re: [PATCH v2 1/4] tpm: Add explicit endianness cast
On Tue, Apr 17, 2018 at 5:02 AM Jason Gunthorpe wrote:
> On Thu, Apr 12, 2018 at 12:13:47PM +0200, Thiebaud Weksteen wrote:
> > Signed-off-by: Thiebaud Weksteen
> > drivers/char/tpm/tpm_eventlog_of.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_eventlog_of.c
b/drivers/char/tpm/tpm_eventlog_of.c
> > index 96fd5646f866..d74568d58a66 100644
> > +++ b/drivers/char/tpm/tpm_eventlog_of.c
> > @@ -56,8 +56,8 @@ int tpm_read_log_of(struct tpm_chip *chip)
> >* but physical tpm needs the conversion.
> >*/
> > if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0) {
> > - size = be32_to_cpup(sizep);
> > - base = be64_to_cpup(basep);
> > + size = be32_to_cpup((__be32 *)sizep);
> > + base = be64_to_cpup((__be64 *)basep);
> Er, no.. change the definitions of sizep and basep to be __be
> Jason
Please read the comment before the condition. sizep and
basep may contain either little endian or big endian and this block is used
to adjust that. Let me know if there is a better way for handling this.
Re: [PATCH v2 0/9] Input: support for latest Lenovo thinkpads (series 80)
Hi KT, gentle ping :) Could you ACK/NACK this series? Dmitry, the first patch could go without KT's approval. Also I realized that Aaron submitted a similar patch for the X1 Carbon last October: https://patchwork.kernel.org/patch/10008513/ So I think the first one should go ASAP now that the laptops are shipping from Lenovo. Cheers, Benjamin On Mon, Apr 9, 2018 at 11:10 AM, Benjamin Tissoires wrote: > Hi Dmitry, > > Here is the v2 of the Lenovo 80 series. > Changes from v1: > - included patch to convert a function to static from build bot > - use of device property instead of platform data (thus the new device tree > binding) > > BTW, KT, if you want to add your Signed-off-by on the patches, feel free to > do so. You were of tremendous help :) > > Cheers, > Benjamin > > Benjamin Tissoires (9): > Input: synaptics - add Lenovo 80 series ids to SMBus > input: elan_i2c_smbus - fix corrupted stack > Input: elan_i2c - add trackstick report > Input: elantech - split device info into a separate structure > Input: elantech_query_info() can be static > Input: elantech - query the resolution in query_info > Input: elantech - add support for SMBus devices > Input: elantech - detect new ICs and setup Host Notify for them > input: psmouse-smbus: allow to control psmouse_deactivate > > .../devicetree/bindings/input/elan_i2c.txt | 1 + > drivers/input/mouse/Kconfig| 12 + > drivers/input/mouse/elan_i2c_core.c| 90 +++- > drivers/input/mouse/elan_i2c_smbus.c | 22 +- > drivers/input/mouse/elantech.c | 479 > +++-- > drivers/input/mouse/elantech.h | 69 ++- > drivers/input/mouse/psmouse-base.c | 21 +- > drivers/input/mouse/psmouse-smbus.c| 24 +- > drivers/input/mouse/psmouse.h | 2 + > drivers/input/mouse/synaptics.c| 5 +- > 10 files changed, 565 insertions(+), 160 deletions(-) > > -- > 2.14.3 >
[PATCH] kexec_file: do not add extra alignment to efi memmap
Chun-Yi reported a kernel warning message below: WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 early_iounmap+0x4f/0x12c() early_iounmap(ff200180, 0118) [0] size not consistent 0120 The problem is x86 kexec_file_load adds extra alignment to the efi memmap: in bzImage64_load() efi_map_sz = efi_get_runtime_map_size(); efi_map_sz = ALIGN(efi_map_sz, 16); And __efi_memmap_init maps with the size including the alignment bytes but efi_memmap_unmap use nr_maps * desc_size which does not include the extra bytes. The alignment in kexec code is only needed for the kexec buffer internal use Actually kexec should pass exact size of the efi memmap to 2nd kernel. Signed-off-by: Dave Young Reported-by: joeyli Tested-by: Randy Wright --- arch/x86/kernel/kexec-bzimage64.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- linux.orig/arch/x86/kernel/kexec-bzimage64.c +++ linux/arch/x86/kernel/kexec-bzimage64.c @@ -398,11 +398,10 @@ static void *bzImage64_load(struct kimag * little bit simple */ efi_map_sz = efi_get_runtime_map_size(); - efi_map_sz = ALIGN(efi_map_sz, 16); params_cmdline_sz = sizeof(struct boot_params) + cmdline_len + MAX_ELFCOREHDR_STR_LEN; params_cmdline_sz = ALIGN(params_cmdline_sz, 16); - kbuf.bufsz = params_cmdline_sz + efi_map_sz + + kbuf.bufsz = params_cmdline_sz + ALIGN(efi_map_sz, 16) + sizeof(struct setup_data) + sizeof(struct efi_setup_data); @@ -410,7 +409,7 @@ static void *bzImage64_load(struct kimag if (!params) return ERR_PTR(-ENOMEM); efi_map_offset = params_cmdline_sz; - efi_setup_data_offset = efi_map_offset + efi_map_sz; + efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16); /* Copy setup header onto bootparams. Documentation/x86/boot.txt */ setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;
[PATCH v3 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V
This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also written, containing perf concepts, arch porting practices and some hints. Changes in v3: - Fix typos in the document. - Change the initialization routine from statically assigning PMU to device-tree-based methods, and set default to the PMU proposed in this patch. Changes in v2: - Fix the bug reported by Alex, which was caused by not sufficient initialization. Check https://lkml.org/lkml/2018/3/31/251 for the discussion. Alan Kao (2): perf: riscv: preliminary RISC-V support perf: riscv: Add Document for Future Porting Guide Documentation/riscv/pmu.txt | 249 +++ arch/riscv/Kconfig | 13 + arch/riscv/include/asm/perf_event.h | 78 - arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/perf_event.c | 478 5 files changed, 815 insertions(+), 4 deletions(-) create mode 100644 Documentation/riscv/pmu.txt create mode 100644 arch/riscv/kernel/perf_event.c -- 2.17.0
Re: [PATCH 19/22] staging: lustre: llite: add support set_acl method in inode operations
On Mon, Apr 16, 2018 at 12:15:08AM -0400, James Simmons wrote:
> +int ll_set_acl(struct inode *inode, struct posix_acl *acl, int type)
> +{
> + struct ll_sb_info *sbi = ll_i2sbi(inode);
> + struct ptlrpc_request *req = NULL;
> + const char *name = NULL;
> + size_t value_size = 0;
> + char *value = NULL;
> + int rc;
> +
> + switch (type) {
> + case ACL_TYPE_ACCESS:
> + name = XATTR_NAME_POSIX_ACL_ACCESS;
> + if (acl) {
> + rc = posix_acl_update_mode(inode, &inode->i_mode, &acl);
> + if (rc)
> + goto out;
> + }
> +
> + break;
> +
> + case ACL_TYPE_DEFAULT:
> + name = XATTR_NAME_POSIX_ACL_DEFAULT;
> + if (!S_ISDIR(inode->i_mode)) {
> + rc = acl ? -EACCES : 0;
> + goto out;
I just hate "goto out;" labels... They're so impossible to review...
Why are we calling forget_cached_acl() when we haven't set anything? I
have no idea. Perhaps it's not even intentional.
> + }
> +
> + break;
> +
> + default:
> + rc = -EINVAL;
> + goto out;
And on this path we're calling forget_cached_acl(inode, type) with an
invalid "type" so it will trigger a BUG()... That's obviously not
intended... Who knows what's going on when all the names are vague and
hand wavy.
regards,
dan carpenter
[PATCH v3 2/2] perf: riscv: Add Document for Future Porting Guide
Reviewed-by: Alex Solomatnikov
Cc: Nick Hu
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
Documentation/riscv/pmu.txt | 249
1 file changed, 249 insertions(+)
create mode 100644 Documentation/riscv/pmu.txt
diff --git a/Documentation/riscv/pmu.txt b/Documentation/riscv/pmu.txt
new file mode 100644
index ..b29f03a6d82f
--- /dev/null
+++ b/Documentation/riscv/pmu.txt
@@ -0,0 +1,249 @@
+Supporting PMUs on RISC-V platforms
+==
+Alan Kao , Mar 2018
+
+Introduction
+
+
+As of this writing, perf_event-related features mentioned in The RISC-V ISA
+Privileged Version 1.10 are as follows:
+(please check the manual for more details)
+
+* [m|s]counteren
+* mcycle[h], cycle[h]
+* minstret[h], instret[h]
+* mhpeventx, mhpcounterx[h]
+
+With such function set only, porting perf would require a lot of work, due to
+the lack of the following general architectural performance monitoring
features:
+
+* Enabling/Disabling counters
+ Counters are just free-running all the time in our case.
+* Interrupt caused by counter overflow
+ No such feature in the spec.
+* Interrupt indicator
+ It is not possible to have many interrupt ports for all counters, so an
+ interrupt indicator is required for software to tell which counter has
+ just overflowed.
+* Writing to counters
+ There will be an SBI to support this since the kernel cannot modify the
+ counters [1]. Alternatively, some vendor considers to implement
+ hardware-extension for M-S-U model machines to write counters directly.
+
+This document aims to provide developers a quick guide on supporting their
+PMUs in the kernel. The following sections briefly explain perf' mechanism
+and todos.
+
+You may check previous discussions here [1][2]. Also, it might be helpful
+to check the appendix for related kernel structures.
+
+
+1. Initialization
+-
+
+*riscv_pmu* is a global pointer of type *struct riscv_pmu*, which contains
+various methods according to perf's internal convention and PMU-specific
+parameters. One should declare such instance to represent the PMU. By
default,
+*riscv_pmu* points to a constant structure *riscv_base_pmu*, which has very
+basic support to a baseline QEMU model.
+
+Then he/she can either assign the instance's pointer to *riscv_pmu* so that
+the minimal and already-implemented logic can be leveraged, or invent his/her
+own *riscv_init_platform_pmu* implementation.
+
+In other words, existing sources of *riscv_base_pmu* merely provide a
+reference implementation. Developers can flexibly decide how many parts they
+can leverage, and in the most extreme case, they can customize every function
+according to their needs.
+
+
+2. Event Initialization
+---
+
+When a user launches a perf command to monitor some events, it is first
+interpreted by the userspace perf tool into multiple *perf_event_open*
+system calls, and then each of them calls to the body of *event_init*
+member function that was assigned in the previous step. In *riscv_base_pmu*'s
+case, it is *riscv_event_init*.
+
+The main purpose of this function is to translate the event provided by user
+into bitmap, so that HW-related control registers or counters can directly be
+manipulated. The translation is based on the mappings and methods provided in
+*riscv_pmu*.
+
+Note that some features can be done in this stage as well:
+
+(1) interrupt setting, which is stated in the next section;
+(2) privilege level setting (user space only, kernel space only, both);
+(3) destructor setting. Normally it is sufficient to apply
*riscv_destroy_event*;
+(4) tweaks for non-sampling events, which will be utilized by functions such as
+*perf_adjust_period*, usually something like the follows:
+
+if (!is_sampling_event(event)) {
+hwc->sample_period = x86_pmu.max_period;
+hwc->last_period = hwc->sample_period;
+local64_set(&hwc->period_left, hwc->sample_period);
+}
+
+In the case of *riscv_base_pmu*, only (3) is provided for now.
+
+
+3. Interrupt
+
+
+3.1. Interrupt Initialization
+
+This often occurs at the beginning of the *event_init* method. In common
+practice, this should be a code segment like
+
+int x86_reserve_hardware(void)
+{
+int err = 0;
+
+if (!atomic_inc_not_zero(&pmc_refcount)) {
+mutex_lock(&pmc_reserve_mutex);
+if (atomic_read(&pmc_refcount) == 0) {
+if (!reserve_pmc_hardware())
+err = -EBUSY;
+else
+reserve_ds_buffers();
+}
+if (!err)
+atomic_inc(&pmc_refcount);
+mutex_unlock(&pmc_reserve_mutex);
+}
+
+return err;
+}
+
+And the magic is in *reserve_pmc_hardware*, which usually does atomic
+operations to make implemented IRQ accessible from some global functio
Re: [PATCH v3 0/2] KVM: MSR-based features
2018-02-22 3:39 GMT+08:00 Tom Lendacky : > The following series implements support within KVM for MSR-based features. > The first patch creates the MSR-based feature framework used to retrieve > the available MSR-based features. The second patch makes use of the > framework to allow a guest to determine if the LFENCE instruction is > serializing on AMD processors. Is there a qemu patch for LFENCE instruction? Regards, Wanpeng Li > > This series is based on the master branch of the KVM git tree. > > https://git.kernel.org/pub/scm/virt/kvm/kvm.git > > --- > > Changes from v2: > - Moved back to initializing the MSR-based feature list in kvm_init_msr_list() > (based on the kvm_x86_ops callback return code) > - Removed the definition of KVM_GET_MSR and switched back to using > KVM_GET_MSRS > - Consolidated the documentation to group the ioctl usage and describe the > usage > specific to the version of the ioctl used. > > Tom Lendacky (2): > KVM: x86: Add a framework for supporting MSR-based features > KVM: SVM: Add MSR-based feature support for serializing LFENCE > > > Documentation/virtual/kvm/api.txt | 29 +++ > arch/x86/include/asm/kvm_host.h |2 + > arch/x86/kvm/svm.c| 43 ++ > arch/x86/kvm/x86.c| 72 > +++-- > include/uapi/linux/kvm.h |1 + > 5 files changed, 136 insertions(+), 11 deletions(-) > > -- > Tom Lendacky
[PATCH v3 1/2] perf: riscv: preliminary RISC-V support
This patch provide a basic PMU, riscv_base_pmu, which supports two
general hardware event, instructions and cycles. Furthermore, this
PMU serves as a reference implementation to ease the portings in
the future.
riscv_base_pmu should be able to run on any RISC-V machine that
conforms to the Priv-Spec. Note that the latest qemu model hasn't
fully support a proper behavior of Priv-Spec 1.10 yet, but work
around should be easy with very small fixes. Please check
https://github.com/riscv/riscv-qemu/pull/115 for future updates.
Cc: Nick Hu
Cc: Greentime Hu
Signed-off-by: Alan Kao
---
arch/riscv/Kconfig | 13 +
arch/riscv/include/asm/perf_event.h | 78 -
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/perf_event.c | 478
4 files changed, 566 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/kernel/perf_event.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c22ebe08e902..90d9c8e50377 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -203,6 +203,19 @@ config RISCV_ISA_C
config RISCV_ISA_A
def_bool y
+menu "supported PMU type"
+ depends on PERF_EVENTS
+
+config RISCV_BASE_PMU
+ bool "Base Performance Monitoring Unit"
+ def_bool y
+ help
+ A base PMU that serves as a reference implementation and has limited
+ feature of perf. It can run on any RISC-V machines so serves as the
+ fallback, but this option can also be disable to reduce kernel size.
+
+endmenu
+
endmenu
menu "Kernel type"
diff --git a/arch/riscv/include/asm/perf_event.h
b/arch/riscv/include/asm/perf_event.h
index e13d2ff29e83..eb6bb1c46387 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -1,13 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (C) 2018 SiFive
+ * Copyright (C) 2018 Andes Technology Corporation
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public Licence
- * as published by the Free Software Foundation; either version
- * 2 of the Licence, or (at your option) any later version.
*/
#ifndef _ASM_RISCV_PERF_EVENT_H
#define _ASM_RISCV_PERF_EVENT_H
+#include
+#include
+
+#define RISCV_BASE_COUNTERS2
+
+/*
+ * The RISCV_MAX_COUNTERS parameter should be specified.
+ */
+
+#ifdef CONFIG_RISCV_BASE_PMU
+#define RISCV_MAX_COUNTERS 2
+#endif
+
+#ifndef RISCV_MAX_COUNTERS
+#error "Please provide a valid RISCV_MAX_COUNTERS for the PMU."
+#endif
+
+/*
+ * These are the indexes of bits in counteren register *minus* 1,
+ * except for cycle. It would be coherent if it can directly mapped
+ * to counteren bit definition, but there is a *time* register at
+ * counteren[1]. Per-cpu structure is scarce resource here.
+ *
+ * According to the spec, an implementation can support counter up to
+ * mhpmcounter31, but many high-end processors has at most 6 general
+ * PMCs, we give the definition to MHPMCOUNTER8 here.
+ */
+#define RISCV_PMU_CYCLE0
+#define RISCV_PMU_INSTRET 1
+#define RISCV_PMU_MHPMCOUNTER3 2
+#define RISCV_PMU_MHPMCOUNTER4 3
+#define RISCV_PMU_MHPMCOUNTER5 4
+#define RISCV_PMU_MHPMCOUNTER6 5
+#define RISCV_PMU_MHPMCOUNTER7 6
+#define RISCV_PMU_MHPMCOUNTER8 7
+
+#define RISCV_OP_UNSUPP(-EOPNOTSUPP)
+
+struct cpu_hw_events {
+ /* # currently enabled events*/
+ int n_events;
+ /* currently enabled events */
+ struct perf_event *events[RISCV_MAX_COUNTERS];
+ /* vendor-defined PMU data */
+ void*platform;
+};
+
+struct riscv_pmu {
+ struct pmu *pmu;
+
+ /* generic hw/cache events table */
+ const int *hw_events;
+ const int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX];
+ /* method used to map hw/cache events */
+ int (*map_hw_event)(u64 config);
+ int (*map_cache_event)(u64 config);
+
+ /* max generic hw events in map */
+ int max_events;
+ /* number total counters, 2(base) + x(general) */
+ int num_counters;
+ /* the width of the counter */
+ int counter_width;
+
+ /* vendor-defined PMU features */
+ void*platform;
+
+ irqreturn_t (*handle_irq)(int irq_num, void *dev);
+};
+
#endif /* _ASM_RISCV_PERF_EVENT_H */
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index ffa439d4a364..f50d19816757 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -39,5 +39,6 @@ obj-$(CONFIG_MODULE_SECTIONS) += module-sections.o
obj-$(CONFIG_FUNCTION_TRACER) += mcount.o
obj-$(CONFIG_DYNAMIC_FTRACE) += mcount-dyn.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ft
RE: [PATCH v2 0/9] Input: support for latest Lenovo thinkpads (series 80)
Hi Benjamin, I agree this series. Thanks KT -Original Message- From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] Sent: Tuesday, April 17, 2018 4:34 PM To: 廖崇榮 Cc: Oliver Haessler; Benjamin Berg; Rob Herring; devicet...@vger.kernel.org; open list:HID CORE LAYER; lkml; Dmitry Torokhov; Aaron Ma Subject: Re: [PATCH v2 0/9] Input: support for latest Lenovo thinkpads (series 80) Hi KT, gentle ping :) Could you ACK/NACK this series? Dmitry, the first patch could go without KT's approval. Also I realized that Aaron submitted a similar patch for the X1 Carbon last October: https://patchwork.kernel.org/patch/10008513/ So I think the first one should go ASAP now that the laptops are shipping from Lenovo. Cheers, Benjamin On Mon, Apr 9, 2018 at 11:10 AM, Benjamin Tissoires wrote: > Hi Dmitry, > > Here is the v2 of the Lenovo 80 series. > Changes from v1: > - included patch to convert a function to static from build bot > - use of device property instead of platform data (thus the new device tree > binding) > > BTW, KT, if you want to add your Signed-off-by on the patches, feel > free to do so. You were of tremendous help :) > > Cheers, > Benjamin > > Benjamin Tissoires (9): > Input: synaptics - add Lenovo 80 series ids to SMBus > input: elan_i2c_smbus - fix corrupted stack > Input: elan_i2c - add trackstick report > Input: elantech - split device info into a separate structure > Input: elantech_query_info() can be static > Input: elantech - query the resolution in query_info > Input: elantech - add support for SMBus devices > Input: elantech - detect new ICs and setup Host Notify for them > input: psmouse-smbus: allow to control psmouse_deactivate > > .../devicetree/bindings/input/elan_i2c.txt | 1 + > drivers/input/mouse/Kconfig| 12 + > drivers/input/mouse/elan_i2c_core.c| 90 +++- > drivers/input/mouse/elan_i2c_smbus.c | 22 +- > drivers/input/mouse/elantech.c | 479 > +++-- > drivers/input/mouse/elantech.h | 69 ++- > drivers/input/mouse/psmouse-base.c | 21 +- > drivers/input/mouse/psmouse-smbus.c| 24 +- > drivers/input/mouse/psmouse.h | 2 + > drivers/input/mouse/synaptics.c| 5 +- > 10 files changed, 565 insertions(+), 160 deletions(-) > > -- > 2.14.3 >
Re: [PATCH v2 2/2] x86/CPU/AMD: Derive CPU topology from CPUID Fn0xB when available
On Wed, Apr 04, 2018 at 01:45:14AM -0500, Suravee Suthikulpanit wrote:
> Derive topology information from Extended Topology Enumeration
> (CPUID Fn0x000B) when the information is available.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/kernel/cpu/amd.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 2c1a9f2..cdd67d1 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -327,6 +327,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>
> /* get information required for multi-node processors */
> if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
> + int err;
> u32 eax, ebx, ecx, edx;
>
> cpuid(0x801e, &eax, &ebx, &ecx, &edx);
> @@ -344,6 +345,14 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
> c->x86_max_cores /= smp_num_siblings;
> }
>
> + /*
> + * In case leaf B is avaialble, use leaf B to derive
s/avaialble/available/
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: [PATCH v2 2/5] ALSA: xen-front: Read sound driver configuration from Xen store
On 04/16/2018 03:55 PM, Juergen Gross wrote:
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Read configuration values from Xen store according
to xen/interface/io/sndif.h protocol:
- introduce configuration structures for different
components, e.g. sound card, device, stream
- read PCM HW parameters, e.g rate, format etc.
- detect stream type (capture/playback)
- read device and card parameters
Signed-off-by: Oleksandr Andrushchenko
---
sound/xen/Makefile| 3 +-
sound/xen/xen_snd_front.c | 7 +
sound/xen/xen_snd_front.h | 4 +
sound/xen/xen_snd_front_cfg.c | 517 ++
sound/xen/xen_snd_front_cfg.h | 46
5 files changed, 576 insertions(+), 1 deletion(-)
create mode 100644 sound/xen/xen_snd_front_cfg.c
create mode 100644 sound/xen/xen_snd_front_cfg.h
diff --git a/sound/xen/Makefile b/sound/xen/Makefile
index 4507ef3c27fd..06705bef61fa 100644
--- a/sound/xen/Makefile
+++ b/sound/xen/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0 OR MIT
-snd_xen_front-objs := xen_snd_front.o
+snd_xen_front-objs := xen_snd_front.o \
+ xen_snd_front_cfg.o
obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o
diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
index f406a8f52c51..65d2494a9d14 100644
--- a/sound/xen/xen_snd_front.c
+++ b/sound/xen/xen_snd_front.c
@@ -25,6 +25,13 @@ static void xen_snd_drv_fini(struct xen_snd_front_info
*front_info)
static int sndback_initwait(struct xen_snd_front_info *front_info)
{
+ int num_streams;
+ int ret;
+
+ ret = xen_snd_front_cfg_card(front_info, &num_streams);
+ if (ret < 0)
+ return ret;
+
return 0;
}
diff --git a/sound/xen/xen_snd_front.h b/sound/xen/xen_snd_front.h
index 4ae204b23d32..b52226cb30bc 100644
--- a/sound/xen/xen_snd_front.h
+++ b/sound/xen/xen_snd_front.h
@@ -11,8 +11,12 @@
#ifndef __XEN_SND_FRONT_H
#define __XEN_SND_FRONT_H
+#include "xen_snd_front_cfg.h"
+
struct xen_snd_front_info {
struct xenbus_device *xb_dev;
+
+ struct xen_front_cfg_card cfg;
};
#endif /* __XEN_SND_FRONT_H */
diff --git a/sound/xen/xen_snd_front_cfg.c b/sound/xen/xen_snd_front_cfg.c
new file mode 100644
index ..d461985afffa
--- /dev/null
+++ b/sound/xen/xen_snd_front_cfg.c
@@ -0,0 +1,517 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+/*
+ * Xen para-virtual sound device
+ *
+ * Copyright (C) 2016-2018 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko
+ */
+
+#include
+
+#include
+
+#include "xen_snd_front.h"
+#include "xen_snd_front_cfg.h"
+
+/* maximum number of supported streams */
Comment style (multiple times below, too):
Start with a capital letter and end sentences with a full stop.
will fix
+#define VSND_MAX_STREAM8
+
+struct cfg_hw_sample_rate {
+ const char *name;
+ unsigned int mask;
+ unsigned int value;
+};
+
+static const struct cfg_hw_sample_rate CFG_HW_SUPPORTED_RATES[] = {
+ { .name = "5512", .mask = SNDRV_PCM_RATE_5512, .value = 5512 },
+ { .name = "8000", .mask = SNDRV_PCM_RATE_8000, .value = 8000 },
+ { .name = "11025", .mask = SNDRV_PCM_RATE_11025, .value = 11025 },
+ { .name = "16000", .mask = SNDRV_PCM_RATE_16000, .value = 16000 },
+ { .name = "22050", .mask = SNDRV_PCM_RATE_22050, .value = 22050 },
+ { .name = "32000", .mask = SNDRV_PCM_RATE_32000, .value = 32000 },
+ { .name = "44100", .mask = SNDRV_PCM_RATE_44100, .value = 44100 },
+ { .name = "48000", .mask = SNDRV_PCM_RATE_48000, .value = 48000 },
+ { .name = "64000", .mask = SNDRV_PCM_RATE_64000, .value = 64000 },
+ { .name = "96000", .mask = SNDRV_PCM_RATE_96000, .value = 96000 },
+ { .name = "176400", .mask = SNDRV_PCM_RATE_176400, .value = 176400 },
+ { .name = "192000", .mask = SNDRV_PCM_RATE_192000, .value = 192000 },
+};
+
+struct cfg_hw_sample_format {
+ const char *name;
+ u64 mask;
+};
+
+static const struct cfg_hw_sample_format CFG_HW_SUPPORTED_FORMATS[] = {
+ {
+ .name = XENSND_PCM_FORMAT_U8_STR,
+ .mask = SNDRV_PCM_FMTBIT_U8
+ },
+ {
+ .name = XENSND_PCM_FORMAT_S8_STR,
+ .mask = SNDRV_PCM_FMTBIT_S8
+ },
+ {
+ .name = XENSND_PCM_FORMAT_U16_LE_STR,
+ .mask = SNDRV_PCM_FMTBIT_U16_LE
+ },
+ {
+ .name = XENSND_PCM_FORMAT_U16_BE_STR,
+ .mask = SNDRV_PCM_FMTBIT_U16_BE
+ },
+ {
+ .name = XENSND_PCM_FORMAT_S16_LE_STR,
+ .mask = SNDRV_PCM_FMTBIT_S16_LE
+ },
+ {
+ .name = XENSND_PCM_FORMAT_S16_BE_STR,
+ .mask = SNDRV_PCM_FMTBIT_S16_BE
+ },
+ {
+ .name = XENSND_PCM_FORMAT_U24_LE_STR,
+ .mask = SNDRV_PC
Re: [PATCH v6 08/17] media: rkisp1: add capture device driver
Hi Jacob,
On Thu, Mar 8, 2018 at 6:49 PM Jacob Chen wrote:
> From: Jacob Chen
> This is the capture device interface driver that provides the v4l2
> user interface. Frames can be received from ISP1.
Thanks for the patch. Please find my comment inline.
[snip]
> +static int
> +rkisp1_start_streaming(struct vb2_queue *queue, unsigned int count)
> +{
> + struct rkisp1_stream *stream = queue->drv_priv;
> + struct rkisp1_vdev_node *node = &stream->vnode;
> + struct rkisp1_device *dev = stream->ispdev;
> + struct v4l2_device *v4l2_dev = &dev->v4l2_dev;
> + int ret;
> +
> + if (WARN_ON(stream->state != RKISP1_STATE_READY))
> + goto return_queued_buf;
We jump out with ret unitialized here. For reference, it triggers a
compiler warning for me.
Note that rather than initializing ret at its definition, I'd recommend
adding an assignment before the goto statement. This will still let the
compiler issue warnings, without assuming that the default value is correct.
Best regards,
Tomasz
Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI bridges
> -邮件原件- > 发件人: Christoph Hellwig [mailto:h...@infradead.org] > 发送时间: 2018年4月16日 20:34 > 收件人: David Wang > 抄送: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; > gre...@linuxfoundation.org; x...@kernel.org; linux- > ker...@vger.kernel.org; brucech...@via-alliance.com; > cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com; > benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com > 主题: Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI > bridges > > On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote: > > PCI bridges integrated in new VIA chipset/SoC have no DAC issue. > > Enable DAC for the platforms with these chipset/SoC can improve DMA > > performance about 20% when DRAM size > 4GB. > > > > So we get an exception to an exception? Is there any way to figure out the > PCI IDs actually affected? Yes. Do you mean we should list the PCI IDs of the PCI bridges which have no DAC issue? There are lots of PCI bridges(PCIE root ports) in our new chipsets/SoCs. And no DMA issues found. So, we only want to recognize the chipset/SoC by reading VID/DID of Bus 0, Device 17, function 0. Thx. --- David
[PATCH] doc: dev-tools: kselftest.rst: update contributing new tests
Add a description that the kernel headers should be used as far as it is possible and then the system headers. Signed-off-by: Anders Roxell --- Documentation/dev-tools/kselftest.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index e80850eefe13..27f08d6ba91c 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -151,6 +151,9 @@ Contributing new tests (details) TEST_FILES, TEST_GEN_FILES mean it is the file which is used by test. + * First use the headers inside the kernel, and then the system headers. The + internal headers should be the primary focus to be able to find regressions. + Test Harness -- 2.11.0
Re: [PATCH 6/8] drm/amdgpu: use firmware_request_nowarn to load firmware
Well this is a rather big NAK for this patch.
Only a small fraction of the firmware files amdgpu uses are actually
optional (the ones with the *_2.bin name). All other files are mandatory
for correct driver operation.
There is a fallback when actually no firmware files at all are found, in
this case we at least try to get a picture on the screen so that the
user gets a hint on what is wrong. But this path isn't tested well and
breaks from time to time.
So when you get a message like "Direct firmware load for * failed with
error -2" even if it's one of the "*_2.bin" files that is a clear hint
that you should update your firmware package.
Regards,
Christian.
Am 17.04.2018 um 00:24 schrieb Andres Rodriguez:
Currently, during the normal boot process the amdgpu driver will produce
spew like the following in dmesg:
Direct firmware load for amdgpu/polaris10_mec_2.bin failed with error -2
This happens when amdgpu tries to load optional firmware files. So the
error does not affect the startup sequence.
This patch switches the amdgpu to use firmware_request_nowarn(), which
will not produce the warnings mentioned above. Hopefully resulting in a
cleaner bootup log.
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 2 +-
drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 2 +-
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 8
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +--
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 32 +++---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 12 +--
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 2 +-
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/si_dpm.c| 2 +-
21 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 4466f3535e2d..6c950811c0a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -811,7 +811,7 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device
*cgs_device,
return -EINVAL;
}
- err = request_firmware(&adev->pm.fw, fw_name, adev->dev);
+ err = firmware_request_nowarn(&adev->pm.fw, fw_name,
adev->dev);
if (err) {
DRM_ERROR("Failed to request firmware\n");
return err;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index af1b879a9ee9..d6225619e69f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -696,7 +696,7 @@ bool amdgpu_device_need_post(struct amdgpu_device *adev)
if (adev->asic_type == CHIP_FIJI) {
int err;
uint32_t fw_ver;
- err = request_firmware(&adev->pm.fw,
"amdgpu/fiji_smc.bin", adev->dev);
+ err = firmware_request_nowarn(&adev->pm.fw,
"amdgpu/fiji_smc.bin", adev->dev);
/* force vPost if error occured */
if (err)
return true;
@@ -1133,7 +1133,7 @@ static int amdgpu_device_parse_gpu_info_fw(struct
amdgpu_device *adev)
}
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_gpu_info.bin", chip_name);
- err = request_firmware(&adev->firmware.gpu_info_fw, fw_name, adev->dev);
+ err = firmware_request_nowarn(&adev->firmware.gpu_info_fw, fw_name,
adev->dev);
if (err) {
dev_err(adev->dev,
"Failed to load gpu_info firmware \"%s\"\n",
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
index 30b5500dc152..0acd1f3d14c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h
@@ -196,7 +196,7 @@ enum AMDGPU_UCODE_STATUS {
struct amdgpu_firmware_info {
/* ucode ID */
enum AMDGPU_UCODE_ID ucode_id;
- /* request_firmware */
+ /* firmware_request */
const struct firmware *fw;
/* starting mc address */
uint64_t mc_addr;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd
Re: [PATCH v2 2/5] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding
On Tue, Apr 10, 2018 at 02:51:38PM +0200, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > This depends on "[PATCH v2 1/5] clk: Extract OF clock helpers in > ". > > v2: > - of_clk_get_parent_count() was moved to , > - Dropped RFC, as a dummy is now available in the !CONFIG_COMMON_CLK > case. > --- Acked-by: Daniel Lezcano
Re: [PATCH v6] Fix modifier keys for Redragon Asura Keyboard
On Mon, Apr 16, 2018 at 11:38 PM, Robert Munteanu wrote:
> This adds a new driver for the Redragon Asura keyboard. The Asura
> keyboard contains an error in the HID descriptor which causes all
> modifier keys to be mapped to left shift. Additionally, we suppress
> the creation of a second, not working, keyboard device.
>
> Signed-off-by: Robert Munteanu
> ---
Looks good to me now:
Reviewed-by: Benjamin Tissoires
Thanks Robert for respinning the series!
Cheers,
Benjamin
> drivers/hid/Kconfig| 7
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-redragon.c | 86
> ++
> 4 files changed, 95 insertions(+)
> create mode 100644 drivers/hid/hid-redragon.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 19c499f5623d..1125e4813716 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -560,6 +560,13 @@ config HID_MAYFLASH
> Say Y here if you have HJZ Mayflash PS3 game controller adapters
> and want to enable force feedback support.
>
> +config HID_REDRAGON
> + tristate "Redragon keyboards"
> + depends on HID
> + default !EXPERT
> + ---help---
> +Support for Redragon keyboards that need fix-ups to work properly.
> +
> config HID_MICROSOFT
> tristate "Microsoft non-fully HID-compliant devices"
> depends on HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index eb13b9e92d85..a36f3f40ba63 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -84,6 +84,7 @@ hid-picolcd-$(CONFIG_DEBUG_FS)+=
> hid-picolcd_debugfs.o
>
> obj-$(CONFIG_HID_PLANTRONICS) += hid-plantronics.o
> obj-$(CONFIG_HID_PRIMAX) += hid-primax.o
> +obj-$(CONFIG_HID_REDRAGON) += hid-redragon.o
> obj-$(CONFIG_HID_RETRODE) += hid-retrode.o
> obj-$(CONFIG_HID_ROCCAT) += hid-roccat.o hid-roccat-common.o \
> hid-roccat-arvo.o hid-roccat-isku.o hid-roccat-kone.o \
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 9454ac134ce2..41a64d0e91f9 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -599,6 +599,7 @@
> #define USB_VENDOR_ID_JESS 0x0c45
> #define USB_DEVICE_ID_JESS_YUREX 0x1010
> #define USB_DEVICE_ID_ASUS_MD_5112 0x5112
> +#define USB_DEVICE_ID_REDRAGON_ASURA 0x760b
>
> #define USB_VENDOR_ID_JESS20x0f30
> #define USB_DEVICE_ID_JESS2_COLOR_RUMBLE_PAD 0x0111
> diff --git a/drivers/hid/hid-redragon.c b/drivers/hid/hid-redragon.c
> new file mode 100644
> index ..daf59578bf93
> --- /dev/null
> +++ b/drivers/hid/hid-redragon.c
> @@ -0,0 +1,86 @@
> +/*
> + * HID driver for Redragon keyboards
> + *
> + * Copyright (c) 2017 Robert Munteanu
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +/*
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "hid-ids.h"
> +
> +
> +/*
> + * The Redragon Asura keyboard sends an incorrect HID descriptor.
> + * At byte 100 it contains
> + *
> + * 0x81, 0x00
> + *
> + * which is Input (Data, Arr, Abs), but it should be
> + *
> + * 0x81, 0x02
> + *
> + * which is Input (Data, Var, Abs), which is consistent with the way
> + * key codes are generated.
> + */
> +
> +static __u8 *redragon_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> + unsigned int *rsize)
> +{
> + if (*rsize >= 102 && rdesc[100] == 0x81 && rdesc[101] == 0x00) {
> + dev_info(&hdev->dev, "Fixing Redragon ASURA report
> descriptor.\n");
> + rdesc[101] = 0x02;
> + }
> +
> + return rdesc;
> +}
> +
> +static int redragon_probe(struct hid_device *dev,
> + const struct hid_device_id *id)
> +{
> + int ret;
> +
> + ret = hid_parse(dev);
> + if (ret) {
> + hid_err(dev, "parse failed\n");
> + return ret;
> + }
> +
> + /* do not register unused input device */
> + if (dev->maxapplication == 1)
> + return 0;
> +
> + ret = hid_hw_start(dev, HID_CONNECT_DEFAULT);
> + if (ret) {
> + hid_err(dev, "hw start failed\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +static const struct hid_device_id redragon_devices[] = {
> + {HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_REDRAGON_ASURA)},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(hid, redragon_devices);
> +
> +static struct hid_driver redragon_driver = {
> + .name = "redragon",
> + .id_table = redragon_devices,
> + .report_fixup = redragon_report_fixup,
> + .probe = redragon_probe
> +};
> +
> +module_hid_driver(redragon_driver);
> +
> +MODULE_LICENSE("GPL");
Re: [PATCH v9 7/9] pinctrl: madera: Add DT bindings for Cirrus Logic Madera codecs
On 27/03/18 12:29, Linus Walleij wrote: On Tue, Mar 13, 2018 at 2:19 PM, Richard Fitzgerald wrote: This is the binding description of the pinctrl driver for Cirrus Logic Madera codecs. The binding uses the generic pinctrl binding so the main purpose here is to describe the device-specific names for groups and functions. Signed-off-by: Richard Fitzgerald Acked-by: Rob Herring Acked-by: Linus Walleij I can also just apply this if you want, as it has no dependencies to anything else. I just assume you want to keep it together with the rest of this complex series. Yours, Linus Walleij Linus, What is your opinion of the i.MX6 pinctrl failure after my bugfix patch for the hogs? If you would want to revert my patch I would need to change this pinctrl driver so it has its own child node as a workaround to the hog bug. Or do you think it is more likely a bug in the i.MX6 pinctrl driver?
[PATCH] regulator: lp87565: Enable LP87565_BUCK_CTRL_1_FPWM_MP_0_2
Buck10 is a multi(dual) phase regulator. So as part of enabling it
turn on the LP87565_BUCK_CTRL_1_FPWM_MP_0_2 bit which forces it to
operate always in multiphase and forced-PWM operation mode.
This helps improve the transient voltage response while switching OPP.
Signed-off-by: Keerthy
---
Boot tested on dra76-evm and read the ctrl register after probe.
Applies on top of linux-next branch with
https://patchwork.kernel.org/patch/10344529/
on top.
drivers/regulator/lp87565-regulator.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 9ee08d6..3af588e 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -178,7 +178,8 @@ static const struct lp87565_regulator regulators[] = {
LP87565_REGULATOR("BUCK10", LP87565_BUCK_10, "buck10", lp87565_buck_ops,
256, LP87565_REG_BUCK0_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK0_CTRL_1,
- LP87565_BUCK_CTRL_1_EN, 3230,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_FPWM_MP_0_2, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
LP87565_REGULATOR("BUCK23", LP87565_BUCK_23, "buck23", lp87565_buck_ops,
256, LP87565_REG_BUCK2_VOUT, LP87565_BUCK_VSET,
--
1.9.1
Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI bridges
On Tue, 17 Apr 2018, David Wang wrote: > > On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote: > > > PCI bridges integrated in new VIA chipset/SoC have no DAC issue. > > > Enable DAC for the platforms with these chipset/SoC can improve DMA > > > performance about 20% when DRAM size > 4GB. > > > > > > > So we get an exception to an exception? Is there any way to figure out > the > > PCI IDs actually affected? > Yes. > > Do you mean we should list the PCI IDs of the PCI bridges which have no DAC > issue? The question was rather to have a list of PCI IDs for those chipsets which have the problem and set the 'disable' flag only for those. That makes a lot more sense than making a list of new chips which disable the disable flag. Thanks, tglx
Re: [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On 04/16/2018 04:12 PM, Juergen Gross wrote:
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Handle Xen event channels:
- create for all configured streams and publish
corresponding ring references and event channels in Xen store,
so backend can connect
- implement event channels interrupt handlers
- create and destroy event channels with respect to Xen bus state
Signed-off-by: Oleksandr Andrushchenko
---
sound/xen/Makefile| 3 +-
sound/xen/xen_snd_front.c | 10 +-
sound/xen/xen_snd_front.h | 7 +
sound/xen/xen_snd_front_evtchnl.c | 474 ++
sound/xen/xen_snd_front_evtchnl.h | 92
5 files changed, 584 insertions(+), 2 deletions(-)
create mode 100644 sound/xen/xen_snd_front_evtchnl.c
create mode 100644 sound/xen/xen_snd_front_evtchnl.h
diff --git a/sound/xen/Makefile b/sound/xen/Makefile
index 06705bef61fa..03c669984000 100644
--- a/sound/xen/Makefile
+++ b/sound/xen/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0 OR MIT
snd_xen_front-objs := xen_snd_front.o \
- xen_snd_front_cfg.o
+ xen_snd_front_cfg.o \
+ xen_snd_front_evtchnl.o
obj-$(CONFIG_SND_XEN_FRONTEND) += snd_xen_front.o
diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
index 65d2494a9d14..eb46bf4070f9 100644
--- a/sound/xen/xen_snd_front.c
+++ b/sound/xen/xen_snd_front.c
@@ -18,9 +18,11 @@
#include
#include "xen_snd_front.h"
+#include "xen_snd_front_evtchnl.h"
Does it really make sense to have multiple driver-private headers?
I think those can be merged.
I would really like to keep it separate as it clearly
shows which stuff belongs to which modules.
At least for me it is easier to maintain it this way.
static void xen_snd_drv_fini(struct xen_snd_front_info *front_info)
{
+ xen_snd_front_evtchnl_free_all(front_info);
}
static int sndback_initwait(struct xen_snd_front_info *front_info)
@@ -32,7 +34,12 @@ static int sndback_initwait(struct xen_snd_front_info
*front_info)
if (ret < 0)
return ret;
- return 0;
+ /* create event channels for all streams and publish */
+ ret = xen_snd_front_evtchnl_create_all(front_info, num_streams);
+ if (ret < 0)
+ return ret;
+
+ return xen_snd_front_evtchnl_publish_all(front_info);
}
static int sndback_connect(struct xen_snd_front_info *front_info)
@@ -122,6 +129,7 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
return -ENOMEM;
front_info->xb_dev = xb_dev;
+ spin_lock_init(&front_info->io_lock);
dev_set_drvdata(&xb_dev->dev, front_info);
return xenbus_switch_state(xb_dev, XenbusStateInitialising);
diff --git a/sound/xen/xen_snd_front.h b/sound/xen/xen_snd_front.h
index b52226cb30bc..9c2ffbb4e4b8 100644
--- a/sound/xen/xen_snd_front.h
+++ b/sound/xen/xen_snd_front.h
@@ -13,9 +13,16 @@
#include "xen_snd_front_cfg.h"
+struct xen_snd_front_evtchnl_pair;
+
struct xen_snd_front_info {
struct xenbus_device *xb_dev;
+ /* serializer for backend IO: request/response */
+ spinlock_t io_lock;
+ int num_evt_pairs;
+ struct xen_snd_front_evtchnl_pair *evt_pairs;
+
struct xen_front_cfg_card cfg;
};
diff --git a/sound/xen/xen_snd_front_evtchnl.c b/sound/xen/xen_snd_front_evtchnl.c
new file mode 100644
index ..9ece39f938f8
--- /dev/null
+++ b/sound/xen/xen_snd_front_evtchnl.c
@@ -0,0 +1,474 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+/*
+ * Xen para-virtual sound device
+ *
+ * Copyright (C) 2016-2018 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko
+ */
+
+#include
+#include
+#include
+#include
+
+#include "xen_snd_front.h"
+#include "xen_snd_front_cfg.h"
+#include "xen_snd_front_evtchnl.h"
+
+static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id)
+{
+ struct xen_snd_front_evtchnl *channel = dev_id;
+ struct xen_snd_front_info *front_info = channel->front_info;
+ struct xensnd_resp *resp;
+ RING_IDX i, rp;
+ unsigned long flags;
+
+ if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED))
+ return IRQ_HANDLED;
+
+ spin_lock_irqsave(&front_info->io_lock, flags);
+
+again:
+ rp = channel->u.req.ring.sring->rsp_prod;
+ /* ensure we see queued responses up to rp */
+ rmb();
+
+ for (i = channel->u.req.ring.rsp_cons; i != rp; i++) {
+ resp = RING_GET_RESPONSE(&channel->u.req.ring, i);
+ if (resp->id != channel->evt_id)
+ continue;
+ switch (resp->operation) {
+ case XENSND_OP_OPEN:
+ /* fall through */
+ case XENSND_OP_CLOSE:
+ /* fall through */
+ case XENSND_OP_READ:
+ /* fall thro
Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out;
ret = fw_get_filesystem_firmware(device, fw->priv);
+#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE
+ if (ret && device &&
+ device_property_read_bool(device, "efi-embedded-firmware")) {
+ ret = fw_get_efi_embedded_fw(device, fw->priv, ret);
+ if (ret == 0)
+ ret = assign_fw(fw, device, opt_flags | FW_OPT_NOCACHE);
+ goto out;
+ }
+#endif
You mussed what I asked for in terms of adding a new flag, (please work on top
of Andre's patches as those likely will be merged first, and also have kdocs
for the flags)
Ok I will base my next version on top of Andres' series.
and then a new firmware API to wrap the above into a function
which would only do something if the driver *asked* for it on their firmware
API call.
Ie, please add a new firmware_request_efi_fw().
As I tried to explain in the changelog the problem with doing this, is that
this makes it a driver decision, where it really needs to be platform-code
driven,
not driver driven.
Take for example the drivers/input/touchscreen/silead.c code that is used on
a lot of 32 bit ARM platforms too, which don't have EFI at all, so if that
needs to call request_firmware_efi() then should I add:
#ifdef CONFIG_X86
fw = request_firmware_efi(...);
#else
fw = request_firmware(...);
#endif
? But even on x86 only some devices with a silead touchscreen have EFI
embedded firmware, so then I would need something like:
#ifdef CONFIG_X86
if (device_property_get_bool(dev, "some-prop-name"))
fw = request_firmware_efi(...);
else
#else
fw = request_firmware(...);
#endif
That is assuming I still want the normal fallback path in the
case no EFI firmware is available, which I do because then
something like packagekit may see if the firmware is packaged
in one of the configured distro repositories.
We already have (x86) platform code in place to attach
properties (like a board specific firmware filename) to the
device using device-properties so that drivers like silead.c
don't get filled / polluted with board/platform specific knowledge,
which IMHO is the place where the knowledge fallback to
an EFI embedded firmware copy belongs.
As the further patches in v3 of this series shows, this actually
works quite nicely, because this also allows bundling the
EFI-embedded firmware info (prefix, length, crc, name) together
with the other board specific properties.
TL;DR: using request_firmware_efi() vs request_firmware() is
a driver decision, but whether EFI firmware fallback should be
is board/platform specific not driver specific, therefor I
believe that using a device-property to signal this is better.
If you insist on me adding a request_firmware_efi() I can give
this a shot, but I know that Dmitry (the input maintainer) will
very much dislike the silead.c changes that implies...
Still a question for lets sat we go that route, what do we
then do with request_firmware_efi() when CONFIG_EFI is not set ?
Should it be defined then or not, and if it should be defined
when CONFIG_EFI is not set what should it do then?
Also if you see the
work I've done to remove the ifdefs over fallback mechanism you'll see it helps
split code and make it easier to read. We should strive to not add any more
ifdefery and instead make tehis code read easily.
So looking at how the CONFIG_FW_LOADER_USER_HELPER stuff deals
with this, I should:
1) Move the definition of fw_get_efi_embedded_fw() to a new
drivers/base/firmware_loader/fallback_efi.c,
which only gets build if CONFIG_EFI_EMBEDDED_FIRMWARE is set
2) Put the following in fallback.h:
#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE
int fw_get_efi_embedded_fw(struct device *dev, struct fw_priv *fw_priv, int
ret);
#else
static inline int
fw_get_efi_embedded_fw(struct device *dev, struct fw_priv *fw_priv, int ret)
{
return ret;
}
#endif
have I got that right?
Regards,
Hans
RE: [PATCH 0/3] Receive Side Coalescing for macb driver
From: David Miller [mailto:da...@davemloft.net] Sent: 16 kwietnia 2018 17:09 > From: Rafal Ozieblo > Date: Sat, 14 Apr 2018 21:53:07 +0100 > >> This patch series adds support for receive side coalescing for Cadence >> GEM driver. Receive segmentation coalescing is a mechanism to reduce >> CPU overhead. This is done by coalescing received TCP message segments >> together into a single large message. This means that when the message >> is complete the CPU only has to process the single header and act upon >> the one data payload. > > You're going to have to think more deeply about enabling this feature. > > If you can't adjust the receive buffer offset, then the various packet header > fields will be unaligned. > > On certain architectures this will result in unaligned traps all over the > networking stack as the packet is being processed. > > So enabling this by default will hurt performance on such systems a lot. > > The whole "skb_reserve(skb, NET_IP_ALIGN)" is not just for fun, it is > absolutely essential. I totally agree with you. But the issue is with IP cores which has this feature implemented in. Even when user does not want to use that feature but he bought IP with configuration supported RSC, then he has to switch off IP alignment. There is no IP alignment with RSC in the GEM: "When the gem rsc define has been set the receive buffer offset cannot be changed in the network configuration register." If IP supports RSC and skb has 2B reserved for alignment we end up with none packets receive correctly (2B missing in the each skb). We can either leave few customers without support in Linux driver or let them use the driver with decrease performance.
[PATCH] selftests/memfd: move common code into common.c
Remove code duplication, in the current code, we move common code for
memfd to common.c.
The duplicate functions got added in commit 87b2d44026e0 ("selftests:
add memfd/sealing page-pinning tests")
Signed-off-by: Anders Roxell
---
tools/testing/selftests/memfd/common.c | 37 +++
tools/testing/selftests/memfd/common.h | 4 ++
tools/testing/selftests/memfd/fuse_test.c | 43 +-
tools/testing/selftests/memfd/memfd_test.c | 37 ---
4 files changed, 43 insertions(+), 78 deletions(-)
diff --git a/tools/testing/selftests/memfd/common.c
b/tools/testing/selftests/memfd/common.c
index 8eb3d75f6e60..fee1f07828a3 100644
--- a/tools/testing/selftests/memfd/common.c
+++ b/tools/testing/selftests/memfd/common.c
@@ -44,3 +44,40 @@ int sys_memfd_create(const char *name, unsigned int flags)
return syscall(__NR_memfd_create, name, flags);
}
+
+unsigned int mfd_assert_get_seals(int fd)
+{
+ int r;
+
+ r = fcntl(fd, F_GET_SEALS);
+ if (r < 0) {
+ printf("GET_SEALS(%d) failed: %m\n", fd);
+ abort();
+ }
+
+ return (unsigned int)r;
+}
+
+void mfd_assert_add_seals(int fd, unsigned int seals)
+{
+ int r;
+ unsigned int s;
+
+ s = mfd_assert_get_seals(fd);
+ r = fcntl(fd, F_ADD_SEALS, seals);
+ if (r < 0) {
+ printf("ADD_SEALS(%d, %u -> %u) failed: %m\n", fd, s, seals);
+ abort();
+ }
+}
+
+void mfd_assert_has_seals(int fd, unsigned int seals)
+{
+ unsigned int s;
+
+ s = mfd_assert_get_seals(fd);
+ if (s != seals) {
+ printf("%u != %u = GET_SEALS(%d)\n", seals, s, fd);
+ abort();
+ }
+}
diff --git a/tools/testing/selftests/memfd/common.h
b/tools/testing/selftests/memfd/common.h
index 522d2c630bd8..5c778d15e8c7 100644
--- a/tools/testing/selftests/memfd/common.h
+++ b/tools/testing/selftests/memfd/common.h
@@ -6,4 +6,8 @@ extern int hugetlbfs_test;
unsigned long default_huge_page_size(void);
int sys_memfd_create(const char *name, unsigned int flags);
+void mfd_assert_add_seals(int fd, unsigned int seals);
+void mfd_assert_has_seals(int fd, unsigned int seals);
+unsigned int mfd_assert_get_seals(int fd);
+
#endif
diff --git a/tools/testing/selftests/memfd/fuse_test.c
b/tools/testing/selftests/memfd/fuse_test.c
index b018e835737d..231714615861 100644
--- a/tools/testing/selftests/memfd/fuse_test.c
+++ b/tools/testing/selftests/memfd/fuse_test.c
@@ -60,49 +60,10 @@ static int mfd_assert_new(const char *name, loff_t sz,
unsigned int flags)
return fd;
}
-static __u64 mfd_assert_get_seals(int fd)
+static int mfd_busy_add_seals(int fd, unsigned int seals)
{
long r;
-
- r = fcntl(fd, F_GET_SEALS);
- if (r < 0) {
- printf("GET_SEALS(%d) failed: %m\n", fd);
- abort();
- }
-
- return r;
-}
-
-static void mfd_assert_has_seals(int fd, __u64 seals)
-{
- __u64 s;
-
- s = mfd_assert_get_seals(fd);
- if (s != seals) {
- printf("%llu != %llu = GET_SEALS(%d)\n",
- (unsigned long long)seals, (unsigned long long)s, fd);
- abort();
- }
-}
-
-static void mfd_assert_add_seals(int fd, __u64 seals)
-{
- long r;
- __u64 s;
-
- s = mfd_assert_get_seals(fd);
- r = fcntl(fd, F_ADD_SEALS, seals);
- if (r < 0) {
- printf("ADD_SEALS(%d, %llu -> %llu) failed: %m\n",
- fd, (unsigned long long)s, (unsigned long long)seals);
- abort();
- }
-}
-
-static int mfd_busy_add_seals(int fd, __u64 seals)
-{
- long r;
- __u64 s;
+ unsigned int s;
r = fcntl(fd, F_GET_SEALS);
if (r < 0)
diff --git a/tools/testing/selftests/memfd/memfd_test.c
b/tools/testing/selftests/memfd/memfd_test.c
index 10baa1652fc2..527789de69b5 100644
--- a/tools/testing/selftests/memfd/memfd_test.c
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -67,43 +67,6 @@ static void mfd_fail_new(const char *name, unsigned int
flags)
}
}
-static unsigned int mfd_assert_get_seals(int fd)
-{
- int r;
-
- r = fcntl(fd, F_GET_SEALS);
- if (r < 0) {
- printf("GET_SEALS(%d) failed: %m\n", fd);
- abort();
- }
-
- return (unsigned int)r;
-}
-
-static void mfd_assert_has_seals(int fd, unsigned int seals)
-{
- unsigned int s;
-
- s = mfd_assert_get_seals(fd);
- if (s != seals) {
- printf("%u != %u = GET_SEALS(%d)\n", seals, s, fd);
- abort();
- }
-}
-
-static void mfd_assert_add_seals(int fd, unsigned int seals)
-{
- int r;
- unsigned int s;
-
- s = mfd_assert_get_seals(fd);
- r = fcntl(fd, F_ADD_SEALS, seals);
- if (r < 0) {
- printf("ADD_SEALS(%d, %u -> %u) failed: %m\n", fd, s, seals);
- abort();
- }
-}
-
static void m
RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: >>-Original Message- >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >>Sent: Wednesday, April 11, 2018 5:27 AM >>To: Ian W MORRISON >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha >>; Wajdeczko, Michal >>; Greg KH ; >>airl...@linux.ie; joonas.lahti...@linux.intel.com; >>linux-kernel@vger.kernel.org; >>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri- >>de...@lists.freedesktop.org >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for >>Geminilake >> >>On Wed, 11 Apr 2018, Ian W MORRISON wrote: >>> >>> NAK on indiscriminate Cc: stable. There are zero guarantees that older kernels will work with whatever firmware you throw at them. >>> >>> I included 'Cc: stable' so the patch would get added to the v4.16 and >>> v4.15 kernels which I have tested with the patch. I found that earlier >>> kernels didn't support the 'linux-firmware' package required to get >>> wifi working on Intel's new Gemini Lake NUC. >> >>You realize that this patch should have nothing to do with wifi? >> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate the >>specific >>versions of stable it is appropriate for. > > Hi Jani, > > The stable kernel version is 4.12 and beyond. > It is appropriate to add the CC: stable in my opinion Who tested the firmware with v4.12 and later? We only have the CI results against *current* drm-tip. We don't even know about v4.16. I'm not going to ack and take responsibility for the stable backports unless someone actually comes forward with credible Tested-bys. BR, Jani. > > Anusha >>BR, >>Jani. >> >>> PS. How is this a "RESEND"? I haven't seen this before. >>> >>> It is a 'RESEND' for that very reason. I initially sent the patch to >>> the same people as a similar patch >>> (https://patchwork.kernel.org/patch/10143637/) however after realising >>> this omitted required addresses I added them and resent the patch. >>> >>> Best regards, >>> Ian >> >>-- >>Jani Nikula, Intel Open Source Technology Center -- Jani Nikula, Intel Open Source Technology Center
Re: [PATCH v1 3/4] drm/tegra: plane: Add custom colorkey properties for older Tegra's
On Mon, Apr 16, 2018 at 03:16:27PM +0300, Dmitry Osipenko wrote:
> Colorkey'ing allows to draw on top of overlapping planes, like for example
> on top of a video plane. Older Tegra's have a limited colorkey'ing
> capability such that blending features are reduced when colorkey'ing is
> enabled. In particular dependent weighting isn't possible, meaning that
> cursors plane can't be displayed properly. In most cases it is more useful
> to display content on top of video overlay, sacrificing mouse cursor
> in the area of three planes intersection with colorkey mismatch. This
> patch adds a custom colorkey properties to primary plane and CRTC's of
> older Tegra's, allowing userspace like Opentegra Xorg driver to implement
> colorkey support for XVideo extension.
>
> Signed-off-by: Dmitry Osipenko
Since this is your own uapi, where's the userspace per
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
And why wo we need a tegra-private colorkey property here? I thought
other's have been discussing this in the context of other drivers.
-Daniel
> ---
> drivers/gpu/drm/tegra/dc.c| 166 ++
> drivers/gpu/drm/tegra/dc.h| 18 +++-
> drivers/gpu/drm/tegra/plane.c | 40
> drivers/gpu/drm/tegra/plane.h | 9 +-
> 4 files changed, 231 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index a54eefea2513..b19e954a223f 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -172,6 +172,24 @@ static void tegra_plane_setup_blending_legacy(struct
> tegra_plane *plane)
>
> state = to_tegra_plane_state(plane->base.state);
>
> + /*
> + * Assuming default zPos window order, enable color keying for cases
> + * of overlapping with topping windows, excluding overlap with
> + * window B. Due to limited HW capabilities, this allows to draw
> + * primary plane on top of video overlay in areas where key isn't
> + * matching. Though window C will be completely transparent in a
> + * region of three windows intersection + key mismatch.
> + */
> + if (state->ckey0_enabled) {
> + background[0] |= BLEND_COLOR_KEY_0;
> + background[2] |= BLEND_COLOR_KEY_0;
> + }
> +
> + if (state->ckey1_enabled) {
> + background[0] |= BLEND_COLOR_KEY_1;
> + background[2] |= BLEND_COLOR_KEY_1;
> + }
> +
> if (state->opaque) {
> /*
>* Since custom fix-weight blending isn't utilized and weight
> @@ -729,6 +747,35 @@ static unsigned long
> tegra_plane_get_possible_crtcs(struct drm_device *drm)
> return 1 << drm->mode_config.num_crtc;
> }
>
> +static void tegra_plane_create_legacy_properties(struct tegra_plane *plane,
> + struct drm_device *drm)
> +{
> + plane->props.color_key0 = drm_property_create_bool(
> + drm, 0, "color key 0");
> + plane->props.color_key1 = drm_property_create_bool(
> + drm, 0, "color key 1");
> +
> + if (!plane->props.color_key0 ||
> + !plane->props.color_key1)
> + goto err_cleanup;
> +
> + drm_object_attach_property(&plane->base.base, plane->props.color_key0,
> +false);
> + drm_object_attach_property(&plane->base.base, plane->props.color_key1,
> +false);
> +
> + return;
> +
> +err_cleanup:
> + if (plane->props.color_key0)
> + drm_property_destroy(drm, plane->props.color_key0);
> +
> + if (plane->props.color_key1)
> + drm_property_destroy(drm, plane->props.color_key1);
> +
> + dev_err(plane->dc->dev, "failed to create legacy plane properties\n");
> +}
> +
> static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,
> struct tegra_dc *dc)
> {
> @@ -764,6 +811,9 @@ static struct drm_plane
> *tegra_primary_plane_create(struct drm_device *drm,
> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
>
> + if (dc->soc->legacy_blending)
> + tegra_plane_create_legacy_properties(plane, drm);
> +
> return &plane->base;
> }
>
> @@ -1153,6 +1203,8 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> copy->pclk = state->pclk;
> copy->div = state->div;
> copy->planes = state->planes;
> + copy->ckey0 = state->ckey0;
> + copy->ckey1 = state->ckey1;
>
> return ©->base;
> }
> @@ -1537,6 +1589,50 @@ static void tegra_dc_disable_vblank(struct drm_crtc
> *crtc)
> tegra_dc_writel(dc, value, DC_CMD_INT_MASK);
> }
>
> +static int tegra_crtc_atomic_set_property(struct drm_crtc *crtc,
> +
