Applied "ASoC: rsnd: fix semicolon.cocci warnings" to the asoc tree
The patch ASoC: rsnd: fix semicolon.cocci warnings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 75f9e4adb56fbb8ffaab7d316f0c02df00e4b755 Mon Sep 17 00:00:00 2001 From: kbuild test robot Date: Fri, 21 Apr 2017 13:02:57 +0800 Subject: [PATCH] ASoC: rsnd: fix semicolon.cocci warnings sound/soc/sh/rcar/adg.c:462:54-55: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Fengguang Wu Acked-by: Kuninori Morimoto Signed-off-by: Mark Brown --- sound/soc/sh/rcar/adg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c index 96fef91b480c..faa1a4f09766 100644 --- a/sound/soc/sh/rcar/adg.c +++ b/sound/soc/sh/rcar/adg.c @@ -459,7 +459,7 @@ static void rsnd_adg_get_clkout(struct rsnd_priv *priv, * ADG supports BRRA/BRRB output only * this means all clkout0/1/2/3 will be same rate */ - prop = of_find_property(np, "clock-frequency", NULL);; + prop = of_find_property(np, "clock-frequency", NULL); req_size = prop->length / sizeof(u32); of_property_read_u32_array(np, "clock-frequency", req_rate, req_size); -- 2.11.0
Re: [PATCH v2 2/2] spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble
On Tue, Apr 11, 2017 at 05:22:25PM +0530, Vignesh R wrote: > Flash filesystems like JFFS2, UBIFS and MTD block layer can provide > vmalloc'd or kmap'd buffers that cannot be mapped using dma_map_sg() and > can potentially be in memory region above 32bit addressable region(ie > buffers belonging to memory region backed by LPAE) of DMA, implement > spi_flash_can_dma() interface to inform SPI core not to map such > buffers. I'll apply this since it fixes bugs for your systems but it feels like something that we should be moving further into the core since LPAE isn't specific to your devices. We should ideally have something (possibly in the DMA mapping code even) which does the remapping without the driver needing to know about it. signature.asc Description: PGP signature
[PATCH v2 05/17] IB/mlx4: Delete four unnecessary return statements
From: Markus Elfring Date: Fri, 21 Apr 2017 13:10:14 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions. Signed-off-by: Markus Elfring --- v2: Changes were rebased on source files from Linux next-20170421. These were recombined as requested by Doug Ledford. drivers/infiniband/hw/mlx4/mad.c | 3 --- drivers/infiniband/hw/mlx4/main.c | 1 - 2 files changed, 4 deletions(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c index d8c27e3ed69a..cf33efce69d2 100644 --- a/drivers/infiniband/hw/mlx4/mad.c +++ b/drivers/infiniband/hw/mlx4/mad.c @@ -1173,7 +1173,6 @@ static void handle_slaves_guid_change(struct mlx4_ib_dev *dev, u8 port_num, out: kfree(in_mad); kfree(out_mad); - return; } void handle_port_mgmt_change_event(struct work_struct *work) @@ -2140,7 +2139,6 @@ void mlx4_ib_tunnels_update_work(struct work_struct *work) mlx4_ib_tunnels_update(dmxw->dev, dmxw->slave, (int) dmxw->port, dmxw->do_init); kfree(dmxw); - return; } static int mlx4_ib_alloc_demux_ctx(struct mlx4_ib_dev *dev, @@ -2268,7 +2266,6 @@ static void mlx4_ib_master_tunnels(struct mlx4_ib_dev *dev, int do_init) /* initialize or tear down tunnel QPs for the master */ for (i = 0; i < dev->dev->caps.num_ports; i++) mlx4_ib_tunnels_update(dev, mlx4_master_func_num(dev->dev), i + 1, do_init); - return; } int mlx4_ib_init_sriov(struct mlx4_ib_dev *dev) diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c index 0ac670765466..232f556b1121 100644 --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -3109,7 +3109,6 @@ static void do_slave_init(struct mlx4_ib_dev *ibdev, int slave, int do_init) } out: kfree(dm); - return; } static void mlx4_ib_handle_catas_error(struct mlx4_ib_dev *ibdev) -- 2.12.2
Re: [PATCH 2/5] KEYS: user_defined: sanitize key payloads
On Fri, Apr 21, 2017 at 02:57:17PM +0100, David Howells wrote: > Eric Biggers wrote: > > > - kfree_rcu(zap, rcu); > > + call_rcu(&zap->rcu, user_free_payload_rcu); > > Add kzfree_rcu()? > > David We could, but it's not trivial because the way kfree_rcu() works is to store the offset of the rcu_head as the callback function, then have a special case in RCU reclaim that recognizes "function pointers" with value < 4096 and call kfree() rather than the function. To support kzfree_rcu() we'd need to reserve another 4096 bytes of the address space (maybe at the end?), then check for the special kzfree value on every RCU reclaim. Or equivalently it could be a flag. It's possible, but it may be best to just use a custom callback for now. Then if it can be shown later that there are a lot of users who would like a "kzfree_rcu()", it can be added. - Eric
Re: [PATCH] video: console: Remove reference to CONFIG_8xx
On Friday, April 14, 2017 03:50:04 PM Christophe Leroy wrote: > CONFIG_8xx is deprecated and should soon be removed in favor > of CONFIG_PPC_8xx. > > Signed-off-by: Christophe Leroy Patch queued for 4.12, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Re: [PATCH net] ip6mr: fix notification device destruction
On 21/04/17 20:42, Nikolay Aleksandrov wrote:
> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
> because we call unregister_netdevice_many for a device that is already
> being destroyed. In IPv4's ipmr that has been resolved by two commits
> long time ago by introducing the "notify" parameter to the delete
> function and avoiding the unregister when called from a notifier, so
> let's do the same for ip6mr.
>
> The trace from Andrey:
> [ cut here ]
> kernel BUG at net/core/dev.c:6813!
> invalid opcode: [#1] SMP KASAN
> Modules linked in:
> CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
> 01/01/2011
> Workqueue: netns cleanup_net
> task: 880069208000 task.stack: 8800692d8000
> RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813
> RSP: 0018:8800692de7f0 EFLAGS: 00010297
> RAX: 880069208000 RBX: 0002 RCX: 0001
> RDX: RSI: RDI: 88006af90569
> RBP: 8800692de9f0 R08: 8800692dec60 R09:
> R10: 0006 R11: R12: 88006af90070
> R13: 8800692debf0 R14: dc00 R15: 88006af9
> FS: () GS:88006cb0()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7fe7e897d870 CR3: 657e7000 CR4: 06e0
> Call Trace:
> unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
> unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880
> ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346
> notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
> __raw_notifier_call_chain kernel/notifier.c:394
> raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
> call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
> call_netdevice_notifiers net/core/dev.c:1663
> rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841
> unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
> unregister_netdevice_many net/core/dev.c:7880
> default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333
> ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144
> cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463
> process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097
> worker_thread+0x223/0x19c0 kernel/workqueue.c:2231
> kthread+0x35e/0x430 kernel/kthread.c:231
> ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
> Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89
> 47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f>
> 0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00
> RIP: rollback_registered_many+0x348/0xeb0 RSP: 8800692de7f0
> ---[ end trace e0b29c57e9b3292c ]---
>
> Reported-by: Andrey Konovalov
> Signed-off-by: Nikolay Aleksandrov
> ---
+CC LKML and Linus
> Andrey could you please test with this patch applied ?
> I have run the reproducer locally and can no longer trigger the bug.
> I've made "notify" an int instead of a bool only to be closer to the ipmr
> code for easier future patches.
>
> net/ipv6/ip6mr.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
> index fb4546e80c82..374997d26488 100644
> --- a/net/ipv6/ip6mr.c
> +++ b/net/ipv6/ip6mr.c
> @@ -774,7 +774,8 @@ static struct net_device *ip6mr_reg_vif(struct net *net,
> struct mr6_table *mrt)
> * Delete a VIF entry
> */
>
> -static int mif6_delete(struct mr6_table *mrt, int vifi, struct list_head
> *head)
> +static int mif6_delete(struct mr6_table *mrt, int vifi, int notify,
> +struct list_head *head)
> {
> struct mif_device *v;
> struct net_device *dev;
> @@ -820,7 +821,7 @@ static int mif6_delete(struct mr6_table *mrt, int vifi,
> struct list_head *head)
>dev->ifindex, &in6_dev->cnf);
> }
>
> - if (v->flags & MIFF_REGISTER)
> + if ((v->flags & MIFF_REGISTER) && !notify)
> unregister_netdevice_queue(dev, head);
>
> dev_put(dev);
> @@ -1331,7 +1332,6 @@ static int ip6mr_device_event(struct notifier_block
> *this,
> struct mr6_table *mrt;
> struct mif_device *v;
> int ct;
> - LIST_HEAD(list);
>
> if (event != NETDEV_UNREGISTER)
> return NOTIFY_DONE;
> @@ -1340,10 +1340,9 @@ static int ip6mr_device_event(struct notifier_block
> *this,
> v = &mrt->vif6_table[0];
> for (ct = 0; ct < mrt->maxvif; ct++, v++) {
> if (v->dev == dev)
> - mif6_delete(mrt, ct, &list);
> + mif6_delete(mrt, ct, 1, NULL);
> }
> }
> - unregister_netdevice_many(&list);
>
> return NOTIFY_DONE;
> }
> @@ -1552,7 +1551,7 @@ static void mroute_clean_tables(struct mr6
Re: [PATCH] scripts/spelling.txt: add several more common spelling mistakes
On Fri, 2017-04-21 at 13:25 +0100, Colin King wrote: > From: Colin Ian King > > Here are some of the more common spelling mistakes that I've found while > fixing up spelling mistakes in kernel error message text. They probably > should be added to this list so we don't keep on seeing them appearing again. thanks.
[PATCH v2 06/17] IB/mlx4: Delete an unnecessary check before kfree() in free_pv_object()
From: Markus Elfring
Date: Fri, 21 Apr 2017 13:50:38 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: kfree(NULL) is safe and this check is probably not required
Thus fix the affected source code place.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx4/mad.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index cf33efce69d2..3caf468ca133 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -1962,10 +1962,8 @@ static int alloc_pv_object(struct mlx4_ib_dev *dev, int
slave, int port,
static void free_pv_object(struct mlx4_ib_dev *dev, int slave, int port)
{
- if (dev->sriov.demux[port - 1].tun[slave]) {
- kfree(dev->sriov.demux[port - 1].tun[slave]);
- dev->sriov.demux[port - 1].tun[slave] = NULL;
- }
+ kfree(dev->sriov.demux[port - 1].tun[slave]);
+ dev->sriov.demux[port - 1].tun[slave] = NULL;
}
static int create_pv_resources(struct ib_device *ibdev, int slave, int port,
--
2.12.2
Re: [PATCH] lightnvm: propagate pblk_init return to userspace
On 04/21/2017 05:07 PM, Javier González wrote:
On 20 Apr 2017, at 20.23, Rakesh Pandit wrote:
From userspace calling ioctl(NVM_DEV_CREATE) was returning ENOMEM for
invalid arguments even though pblk (pblk_init) was returning correctly
-EINVAL to nvm_create_tgt inside core. This patch propagates the
correct return value to userspace.
Because pblk was introduced recently this only needs to go in 4.12.
Fixes: a4bd217b4326 ("lightnvm: physical block device (pblk) target")
Signed-off-by: Rakesh Pandit
Looks good.
Reviewed-by: Javier González
Javier
Jens, would you pick this up as well? :)
Re: [PATCH] scripts/spelling.txt: add several more common spelling mistakes
On Fri, Apr 21, 2017 at 5:25 AM, Colin King wrote: > From: Colin Ian King > > Here are some of the more common spelling mistakes that I've found while > fixing up spelling mistakes in kernel error message text. They probably > should be added to this list so we don't keep on seeing them appearing again. > > Signed-off-by: Colin Ian King Thanks! Acked-by: Kees Cook -Kees -- Kees Cook Pixel Security
[PATCH v2 07/17] IB/mlx4: Move an assignment out of a check in forward_trap()
From: Markus Elfring Date: Fri, 21 Apr 2017 14:00:08 +0200 The script "checkpatch.pl" pointed information out like the following. ERROR: do not use assignment in if condition Thus fix the affected source code place. Signed-off-by: Markus Elfring Reviewed-by: Majd Dibbiny --- drivers/infiniband/hw/mlx4/mad.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c index 3caf468ca133..0a5b46791335 100644 --- a/drivers/infiniband/hw/mlx4/mad.c +++ b/drivers/infiniband/hw/mlx4/mad.c @@ -401,7 +401,8 @@ static void forward_trap(struct mlx4_ib_dev *dev, u8 port_num, const struct ib_m */ spin_lock_irqsave(&dev->sm_lock, flags); memcpy(send_buf->mad, mad, sizeof *mad); - if ((send_buf->ah = dev->sm_ah[port_num - 1])) + send_buf->ah = dev->sm_ah[port_num - 1]; + if (send_buf->ah) ret = ib_post_send_mad(send_buf, NULL); else ret = -EINVAL; -- 2.12.2
[PATCH v2 1/3] x86/mm: Remove flush_tlb() and flush_tlb_current_task()
I was trying to figure out what how flush_tlb_current_task() would
possibly work correctly if current->mm != current->active_mm, but I
realized I could spare myself the effort: it has no callers except
the unused flush_tlb() macro. In fact, it doesn't even exist on
!SMP builds.
Cc: Rik van Riel
Cc: Dave Hansen
Cc: Nadav Amit
Cc: Michal Hocko
Cc: Sasha Levin
Cc: Andrew Morton
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/tlbflush.h | 3 ---
arch/x86/mm/tlb.c | 17 -
2 files changed, 20 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index fc5abff9b7fd..cc7ea9a7d0c1 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -303,14 +303,11 @@ static inline void flush_tlb_kernel_range(unsigned long
start,
flush_tlb_mm_range(vma->vm_mm, start, end, vma->vm_flags)
extern void flush_tlb_all(void);
-extern void flush_tlb_current_task(void);
extern void flush_tlb_page(struct vm_area_struct *, unsigned long);
extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
unsigned long end, unsigned long vmflag);
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
-#define flush_tlb()flush_tlb_current_task()
-
void native_flush_tlb_others(const struct cpumask *cpumask,
struct mm_struct *mm,
unsigned long start, unsigned long end);
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index a7655f6caf7d..92ec37f517ab 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -289,23 +289,6 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
smp_call_function_many(cpumask, flush_tlb_func, &info, 1);
}
-void flush_tlb_current_task(void)
-{
- struct mm_struct *mm = current->mm;
-
- preempt_disable();
-
- count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
-
- /* This is an implicit full barrier that synchronizes with switch_mm. */
- local_flush_tlb();
-
- trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
- if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
- flush_tlb_others(mm_cpumask(mm), mm, 0UL, TLB_FLUSH_ALL);
- preempt_enable();
-}
-
/*
* See Documentation/x86/tlb.txt for details. We choose 33
* because it is large enough to cover the vast majority (at
--
2.9.3
[PATCH v2 08/17] IB/mlx4: Enclose 46 expressions for sizeof by parentheses
From: Markus Elfring
Date: Fri, 21 Apr 2017 15:27:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script "checkpatch.pl" pointed information out like the following.
WARNING: sizeof … should be sizeof(…)
Thus fix the affected source code places.
Signed-off-by: Markus Elfring
---
v2:
Changes were rebased on source files from Linux next-20170421.
These were recombined as requested by Doug Ledford.
drivers/infiniband/hw/mlx4/mad.c | 30 +++---
drivers/infiniband/hw/mlx4/main.c | 35 +--
drivers/infiniband/hw/mlx4/qp.c | 31 ---
3 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index 0a5b46791335..41461aeb7c5e 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -195,7 +195,7 @@ static void update_sm_ah(struct mlx4_ib_dev *dev, u8
port_num, u16 lid, u8 sl)
if (!dev->send_agent[port_num - 1][0])
return;
- memset(&ah_attr, 0, sizeof ah_attr);
+ memset(&ah_attr, 0, sizeof(ah_attr));
ah_attr.dlid = lid;
ah_attr.sl = sl;
ah_attr.port_num = port_num;
@@ -400,7 +400,7 @@ static void forward_trap(struct mlx4_ib_dev *dev, u8
port_num, const struct ib_m
* it's OK for our devices).
*/
spin_lock_irqsave(&dev->sm_lock, flags);
- memcpy(send_buf->mad, mad, sizeof *mad);
+ memcpy(send_buf->mad, mad, sizeof(*mad));
send_buf->ah = dev->sm_ah[port_num - 1];
if (send_buf->ah)
ret = ib_post_send_mad(send_buf, NULL);
@@ -555,7 +555,7 @@ int mlx4_ib_send_to_slave(struct mlx4_ib_dev *dev, int
slave, u8 port,
/* create ah. Just need an empty one with the port num for the post
send.
* The driver will set the force loopback bit in post_send */
- memset(&attr, 0, sizeof attr);
+ memset(&attr, 0, sizeof(attr));
attr.port_num = port;
if (is_eth) {
union ib_gid sgid;
@@ -590,8 +590,8 @@ int mlx4_ib_send_to_slave(struct mlx4_ib_dev *dev, int
slave, u8 port,
/* copy over to tunnel buffer */
if (grh)
- memcpy(&tun_mad->grh, grh, sizeof *grh);
- memcpy(&tun_mad->mad, mad, sizeof *mad);
+ memcpy(&tun_mad->grh, grh, sizeof(*grh));
+ memcpy(&tun_mad->mad, mad, sizeof(*mad));
/* adjust tunnel data */
tun_mad->hdr.pkey_index = cpu_to_be16(tun_pkey_ix);
@@ -961,7 +961,7 @@ static int iboe_process_mad(struct ib_device *ibdev, int
mad_flags, u8 port_num,
}
mutex_unlock(&dev->counters_table[port_num - 1].mutex);
if (stats_avail) {
- memset(out_mad->data, 0, sizeof out_mad->data);
+ memset(out_mad->data, 0, sizeof(out_mad->data));
switch (counter_stats.counter_mode & 0xf) {
case 0:
edit_counter(&counter_stats,
@@ -1136,8 +1136,8 @@ static void handle_slaves_guid_change(struct mlx4_ib_dev
*dev, u8 port_num,
if (!mlx4_is_mfunc(dev->dev) || !mlx4_is_master(dev->dev))
return;
- in_mad = kmalloc(sizeof *in_mad, GFP_KERNEL);
- out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL);
+ in_mad = kmalloc(sizeof(*in_mad), GFP_KERNEL);
+ out_mad = kmalloc(sizeof(*out_mad), GFP_KERNEL);
if (!in_mad || !out_mad)
goto out;
@@ -1146,8 +1146,8 @@ static void handle_slaves_guid_change(struct mlx4_ib_dev
*dev, u8 port_num,
for (i = 0; i < 4; i++) {
if (change_bitmap && (!((change_bitmap >> (8 * i)) & 0xff)))
continue;
- memset(in_mad, 0, sizeof *in_mad);
- memset(out_mad, 0, sizeof *out_mad);
+ memset(in_mad, 0, sizeof(*in_mad));
+ memset(out_mad, 0, sizeof(*out_mad));
in_mad->base_version = 1;
in_mad->mgmt_class= IB_MGMT_CLASS_SUBN_LID_ROUTED;
@@ -1417,7 +1417,7 @@ int mlx4_ib_send_to_wire(struct mlx4_ib_dev *dev, int
slave, u8 port,
sizeof (struct mlx4_mad_snd_buf),
DMA_TO_DEVICE);
- memcpy(&sqp_mad->payload, mad, sizeof *mad);
+ memcpy(&sqp_mad->payload, mad, sizeof(*mad));
ib_dma_sync_single_for_device(&dev->ib_dev,
sqp->tx_ring[wire_tx_ix].buf.map,
@@ -1800,7 +1800,7 @@ static int create_pv_sqp(struct mlx4_ib_demux_pv_ctx *ctx,
tun_qp = &ctx->qp[qp_type];
- memset(&qp_init_att
Re: [PATCH v1] pwm: pca9685: clarify pca9685_set_sleep_mode() interface.
On Fri, Apr 21, 2017 at 4:19 PM, Sven Van Asbroeck wrote:
> The function
> static void pca9685_set_sleep_mode(struct pca9685 *pca, int sleep)
> takes the chip in and out of sleep mode, depending on the value of
> sleep, which is interpreted as a boolean.
>
> To clarify that 'int sleep' is a boolean and not a sleep delay,
> change the function interface to:
> static void pca9685_set_sleep_mode(struct pca9685 *pca, bool enable)
>
Yes, that's indeed more understandable, thanks.
Reviewed-by: Andy Shevchenko
> Suggested-by: Andy Shevchenko
> Signed-off-by: Sven Van Asbroeck
> ---
> drivers/pwm/pwm-pca9685.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 5f55cfa..a7eaf962 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -241,11 +241,11 @@ static inline int pca9685_pwm_gpio_probe(struct pca9685
> *pca)
> }
> #endif
>
> -static void pca9685_set_sleep_mode(struct pca9685 *pca, int sleep)
> +static void pca9685_set_sleep_mode(struct pca9685 *pca, bool enable)
> {
> regmap_update_bits(pca->regmap, PCA9685_MODE1,
> - MODE1_SLEEP, sleep ? MODE1_SLEEP : 0);
> - if (!sleep) {
> + MODE1_SLEEP, enable ? MODE1_SLEEP : 0);
> + if (!enable) {
> /* Wait 500us for the oscillator to be back up */
> udelay(500);
> }
> @@ -272,13 +272,13 @@ static int pca9685_pwm_config(struct pwm_chip *chip,
> struct pwm_device *pwm,
> * state is guaranteed active here.
> */
> /* Put chip into sleep mode */
> - pca9685_set_sleep_mode(pca, 1);
> + pca9685_set_sleep_mode(pca, true);
>
> /* Change the chip-wide output frequency */
> regmap_write(pca->regmap, PCA9685_PRESCALE, prescale);
>
> /* Wake the chip up */
> - pca9685_set_sleep_mode(pca, 0);
> + pca9685_set_sleep_mode(pca, false);
>
> pca->period_ns = period_ns;
> } else {
> @@ -534,7 +534,7 @@ static int pca9685_pwm_runtime_suspend(struct device *dev)
> struct i2c_client *client = to_i2c_client(dev);
> struct pca9685 *pca = i2c_get_clientdata(client);
>
> - pca9685_set_sleep_mode(pca, 1);
> + pca9685_set_sleep_mode(pca, true);
> return 0;
> }
>
> @@ -543,7 +543,7 @@ static int pca9685_pwm_runtime_resume(struct device *dev)
> struct i2c_client *client = to_i2c_client(dev);
> struct pca9685 *pca = i2c_get_clientdata(client);
>
> - pca9685_set_sleep_mode(pca, 0);
> + pca9685_set_sleep_mode(pca, false);
> return 0;
> }
> #endif
> --
> 1.9.1
>
--
With Best Regards,
Andy Shevchenko
[PATCH v2 09/17] IB/mlx4: Split a condition check in six functions
From: Markus Elfring
Date: Fri, 21 Apr 2017 18:13:16 +0200
The kfree() function was called in up to two cases during error handling
even if the passed variable contained a null pointer.
* Split a condition check for memory allocation failures.
* Adjust jump targets according to the Linux coding style convention.
* Delete initialisations for variables at the beginning
which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
---
v2:
Changes were rebased on source files from Linux next-20170421.
These were recombined as requested by Doug Ledford.
drivers/infiniband/hw/mlx4/mad.c | 14 +++---
drivers/infiniband/hw/mlx4/main.c | 90 +--
2 files changed, 68 insertions(+), 36 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index 41461aeb7c5e..b26817f0669f 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -1129,17 +1129,20 @@ static void propagate_pkey_ev(struct mlx4_ib_dev *dev,
int port_num,
static void handle_slaves_guid_change(struct mlx4_ib_dev *dev, u8 port_num,
u32 guid_tbl_blk_num, u32 change_bitmap)
{
- struct ib_smp *in_mad = NULL;
- struct ib_smp *out_mad = NULL;
+ struct ib_smp *in_mad;
+ struct ib_smp *out_mad;
u16 i;
if (!mlx4_is_mfunc(dev->dev) || !mlx4_is_master(dev->dev))
return;
in_mad = kmalloc(sizeof(*in_mad), GFP_KERNEL);
+ if (!in_mad)
+ return;
+
out_mad = kmalloc(sizeof(*out_mad), GFP_KERNEL);
- if (!in_mad || !out_mad)
- goto out;
+ if (!out_mad)
+ goto free_in_mad;
guid_tbl_blk_num *= 4;
@@ -1172,8 +1175,9 @@ static void handle_slaves_guid_change(struct mlx4_ib_dev
*dev, u8 port_num,
}
out:
- kfree(in_mad);
kfree(out_mad);
+free_in_mad:
+ kfree(in_mad);
}
void handle_port_mgmt_change_event(struct work_struct *work)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 8f0e37c4f381..e18e46a68809 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -435,8 +435,8 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
struct ib_udata *uhw)
{
struct mlx4_ib_dev *dev = to_mdev(ibdev);
- struct ib_smp *in_mad = NULL;
- struct ib_smp *out_mad = NULL;
+ struct ib_smp *in_mad;
+ struct ib_smp *out_mad;
int err;
int have_ib_ports;
struct mlx4_uverbs_ex_query_device cmd;
@@ -461,10 +461,14 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
resp.response_length = offsetof(typeof(resp), response_length) +
sizeof(resp.response_length);
in_mad = kzalloc(sizeof(*in_mad), GFP_KERNEL);
+ if (!in_mad)
+ return -ENOMEM;
+
out_mad = kmalloc(sizeof(*out_mad), GFP_KERNEL);
- err = -ENOMEM;
- if (!in_mad || !out_mad)
- goto out;
+ if (!out_mad) {
+ err = -ENOMEM;
+ goto free_in_mad;
+ }
init_query_mad(in_mad);
in_mad->attr_id = IB_SMP_ATTR_NODE_INFO;
@@ -573,9 +577,9 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
goto out;
}
out:
- kfree(in_mad);
kfree(out_mad);
-
+free_in_mad:
+ kfree(in_mad);
return err;
}
@@ -591,16 +595,21 @@ mlx4_ib_port_link_layer(struct ib_device *device, u8
port_num)
static int ib_link_query_port(struct ib_device *ibdev, u8 port,
struct ib_port_attr *props, int netw_view)
{
- struct ib_smp *in_mad = NULL;
- struct ib_smp *out_mad = NULL;
+ struct ib_smp *in_mad;
+ struct ib_smp *out_mad;
int ext_active_speed;
int mad_ifc_flags = MLX4_MAD_IFC_IGNORE_KEYS;
- int err = -ENOMEM;
+ int err;
in_mad = kzalloc(sizeof(*in_mad), GFP_KERNEL);
+ if (!in_mad)
+ return -ENOMEM;
+
out_mad = kmalloc(sizeof(*out_mad), GFP_KERNEL);
- if (!in_mad || !out_mad)
- goto out;
+ if (!out_mad) {
+ err = -ENOMEM;
+ goto free_in_mad;
+ }
init_query_mad(in_mad);
in_mad->attr_id = IB_SMP_ATTR_PORT_INFO;
@@ -673,8 +682,9 @@ static int ib_link_query_port(struct ib_device *ibdev, u8
port,
props->active_speed = IB_SPEED_SDR;
out:
- kfree(in_mad);
kfree(out_mad);
+free_in_mad:
+ kfree(in_mad);
return err;
}
@@ -766,17 +776,22 @@ static int mlx4_ib_query_port(struct ib_device *ibdev, u8
port,
int __mlx4_ib_query_gid(struct ib_device *ibdev, u8 port, int index,
union ib_gid *gid, int netw_view)
{
- struct ib_smp *in_mad = NULL;
- struct ib_smp
Re: [PATCH] lightnvm: propagate pblk_init return to userspace
On 04/21/2017 12:11 PM, Matias Bjørling wrote:
> On 04/21/2017 05:07 PM, Javier González wrote:
>>> On 20 Apr 2017, at 20.23, Rakesh Pandit wrote:
>>>
>>> From userspace calling ioctl(NVM_DEV_CREATE) was returning ENOMEM for
>>> invalid arguments even though pblk (pblk_init) was returning correctly
>>> -EINVAL to nvm_create_tgt inside core. This patch propagates the
>>> correct return value to userspace.
>>>
>>> Because pblk was introduced recently this only needs to go in 4.12.
>>>
>>> Fixes: a4bd217b4326 ("lightnvm: physical block device (pblk) target")
>>> Signed-off-by: Rakesh Pandit
>>>
>>
>> Looks good.
>>
>> Reviewed-by: Javier González
>>
>> Javier
>>
>
>
> Jens, would you pick this up as well? :)
Done, thanks Rakesh.
--
Jens Axboe
Re: [PATCH V15 03/11] cper: add timestamp print to CPER status printing
On 4/21/2017 6:21 AM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 05:05:15PM -0600, Tyler Baicar wrote:
The ACPI 6.1 spec added a timestamp to the HEST generic data
HEST?
I see the timestamp in
Table 18-343 Generic Error Data Entry
where those things are "One or more Generic Error Data Entry structures
may be recorded in the Generic Error Data Entries field of the Generic
Error Status Block structure."
And those are part of the "18.3.2.7 Generic Hardware Error Source",
i.e., GHES. So why do you say "HEST" above?
Ah yes, this should be GHES no HEST. There are too many acronyms
involved here :)
structure. Print the timestamp out when printing out the error
status information.
Signed-off-by: Tyler Baicar
CC: Jonathan (Zhixiong) Zhang
Reviewed-by: James Morse
Reviewed-by: Ard Biesheuvel
Remove those Reviewed-by:s
---
drivers/firmware/efi/cper.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 8328a6f..46585f9 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
#include
#define INDENT_SP " "
@@ -387,6 +389,29 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
}
+static void cper_estatus_timestamp(const char *pfx,
cper_print_tstamp()
+ struct acpi_hest_generic_data_v300 *gdata)
+{
+ __u8 hour, min, sec, day, mon, year, century, *timestamp;
+
+ if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
+ timestamp = (__u8 *)&(gdata->time_stamp);
+ sec = bcd2bin(timestamp[0]);
+ min = bcd2bin(timestamp[1]);
+ hour = bcd2bin(timestamp[2]);
+ day = bcd2bin(timestamp[4]);
+ mon = bcd2bin(timestamp[5]);
+ year = bcd2bin(timestamp[6]);
+ century = bcd2bin(timestamp[7]);
+
+ if (*(timestamp + 3) & 0x1)
+ printk("%stimestamp is precise\n", pfx);
+
+ printk("%stime: %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
+ century, year, mon, day, hour, min, sec);
Yeah, about the precise tstamp, you can do something like this:
---
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 46585f92b741..a649884e2264 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -404,10 +404,8 @@ static void cper_estatus_timestamp(const char *pfx,
year = bcd2bin(timestamp[6]);
century = bcd2bin(timestamp[7]);
- if (*(timestamp + 3) & 0x1)
- printk("%stimestamp is precise\n", pfx);
-
- printk("%stime: %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
+ printk("%s%ststamp: %02d%02d-%02d-%02d %02d:%02d:%02d\n", pfx,
+ (timestamp[3] & 0x1 ? "precise " : ""),
century, year, mon, day, hour, min, sec);
}
}
This is basically what I already had in v14...you asked to move it into
a different if-statement? https://lkml.org/lkml/2017/4/12/397
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH] libiscsi: Add an internal error code
This is a prep patch to add a new error code to libiscsi. We want to
rework some kmap calls to be able to fail. When we do, we'd like to
use this error code.
This patch simply introduces ISCSI_TCP_INTERNAL_ERR and prints
"Internal Error." when it gets hit.
Signed-off-by: Logan Gunthorpe
---
Please see these links for additional context.
https://patchwork.kernel.org/patch/9680329/
https://patchwork.kernel.org/patch/9680091/
Thanks,
Logan
drivers/scsi/cxgbi/libcxgbi.c | 5 +
include/scsi/libiscsi_tcp.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index bd7d39e..e38d0c1 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -1556,6 +1556,11 @@ static inline int read_pdu_skb(struct iscsi_conn *conn,
*/
iscsi_conn_printk(KERN_ERR, conn, "Invalid pdu or skb.");
return -EFAULT;
+ case ISCSI_TCP_INTERNAL_ERR:
+ pr_info("skb 0x%p, off %u, %d, TCP_INTERNAL_ERR.\n",
+ skb, offset, offloaded);
+ iscsi_conn_printk(KERN_ERR, conn, "Internal error.");
+ return -EFAULT;
case ISCSI_TCP_SEGMENT_DONE:
log_debug(1 << CXGBI_DBG_PDU_RX,
"skb 0x%p, off %u, %d, TCP_SEG_DONE, rc %d.\n",
diff --git a/include/scsi/libiscsi_tcp.h b/include/scsi/libiscsi_tcp.h
index 30520d5..90691ad 100644
--- a/include/scsi/libiscsi_tcp.h
+++ b/include/scsi/libiscsi_tcp.h
@@ -92,6 +92,7 @@ enum {
ISCSI_TCP_SKB_DONE, /* skb is out of data */
ISCSI_TCP_CONN_ERR, /* iscsi layer has fired a conn err */
ISCSI_TCP_SUSPENDED,/* conn is suspended */
+ ISCSI_TCP_INTERNAL_ERR, /* an internal error occurred */
};
extern void iscsi_tcp_hdr_recv_prep(struct iscsi_tcp_conn *tcp_conn);
--
2.1.4
[PATCH v2 10/17] IB/mlx4: Delete an unnecessary variable in __mlx4_ib_query_gid()
From: Markus Elfring
Date: Fri, 21 Apr 2017 18:22:42 +0200
* Call the function "memset" directly in an if branch without using
an intermediate variable.
* Delete the local variable "clear" which became unnecessary with
this refactoring.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx4/main.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index e18e46a68809..a54e2f04929b 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -780,7 +780,6 @@ int __mlx4_ib_query_gid(struct ib_device *ibdev, u8 port,
int index,
struct ib_smp *out_mad;
int err;
struct mlx4_ib_dev *dev = to_mdev(ibdev);
- int clear = 0;
int mad_ifc_flags = MLX4_MAD_IFC_IGNORE_KEYS;
in_mad = kzalloc(sizeof(*in_mad), GFP_KERNEL);
@@ -809,8 +808,8 @@ int __mlx4_ib_query_gid(struct ib_device *ibdev, u8 port,
int index,
if (mlx4_is_mfunc(dev->dev) && !netw_view) {
if (index) {
/* For any index > 0, return the null guid */
+ memset(gid->raw + 8, 0, 8);
err = 0;
- clear = 1;
goto out;
}
}
@@ -827,8 +826,6 @@ int __mlx4_ib_query_gid(struct ib_device *ibdev, u8 port,
int index,
memcpy(gid->raw + 8, out_mad->data + (index % 8) * 8, 8);
out:
- if (clear)
- memset(gid->raw + 8, 0, 8);
kfree(out_mad);
free_in_mad:
kfree(in_mad);
--
2.12.2
[PATCH v2 11/17] IB/mlx4: Delete an unnecessary variable initialisation in mlx4_ib_add()
From: Markus Elfring
Date: Fri, 21 Apr 2017 18:44:15 +0200
The local variable "new_counter_index" will be set to an appropriate pointer
a bit later. Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx4/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index a54e2f04929b..d08b9b154c97 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2615,7 +2615,7 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
int num_req_counters;
int allocated;
u32 counter_index;
- struct counter_index *new_counter_index = NULL;
+ struct counter_index *new_counter_index;
pr_info_once("%s", mlx4_ib_version);
--
2.12.2
Re: [PATCH 04/11] block: Improvements to bounce-buffer handling
On Thu, Apr 20, 2017 at 1:38 PM, NeilBrown wrote:
> Since commit 23688bf4f830 ("block: ensure to split after potentially
> bouncing a bio") blk_queue_bounce() is called *before*
> blk_queue_split().
> This means that:
> 1/ the comments blk_queue_split() about bounce buffers are
> irrelevant, and
> 2/ a very large bio (more than BIO_MAX_PAGES) will no longer be
> split before it arrives at blk_queue_bounce(), leading to the
> possibility that bio_clone_bioset() will fail and a NULL
> will be dereferenced.
>
> Separately, blk_queue_bounce() shouldn't use fs_bio_set as the bio
> being copied could be from the same set, and this could lead to a
> deadlock.
>
> So:
> - allocate 2 private biosets for blk_queue_bounce, one for
>splitting enormous bios and one for cloning bios.
> - add code to split a bio that exceeds BIO_MAX_PAGES.
> - Fix up the comments in blk_queue_split()
>
> Signed-off-by: NeilBrown
> ---
> block/blk-merge.c | 14 --
> block/bounce.c| 27 ++-
> 2 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index d59074556703..51c84540d3bb 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -117,17 +117,11 @@ static struct bio *blk_bio_segment_split(struct
> request_queue *q,
> * each holds at most BIO_MAX_PAGES bvecs because
> * bio_clone() can fail to allocate big bvecs.
> *
> -* It should have been better to apply the limit per
> -* request queue in which bio_clone() is involved,
> -* instead of globally. The biggest blocker is the
> -* bio_clone() in bio bounce.
> +* Those drivers which will need to use bio_clone()
> +* should tell us in some way. For now, impose the
> +* BIO_MAX_PAGES limit on all queues.
> *
> -* If bio is splitted by this reason, we should have
> -* allowed to continue bios merging, but don't do
> -* that now for making the change simple.
> -*
> -* TODO: deal with bio bounce's bio_clone() gracefully
> -* and convert the global limit into per-queue limit.
> +* TODO: handle users of bio_clone() differently.
> */
> if (bvecs++ >= BIO_MAX_PAGES)
> goto split;
> diff --git a/block/bounce.c b/block/bounce.c
> index 1cb5dd3a5da1..51fb538b504d 100644
> --- a/block/bounce.c
> +++ b/block/bounce.c
> @@ -26,6 +26,7 @@
> #define POOL_SIZE 64
> #define ISA_POOL_SIZE 16
>
> +struct bio_set *bounce_bio_set, *bounce_bio_split;
> static mempool_t *page_pool, *isa_page_pool;
>
> #if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
> @@ -40,6 +41,14 @@ static __init int init_emergency_pool(void)
> BUG_ON(!page_pool);
> pr_info("pool size: %d pages\n", POOL_SIZE);
>
> + bounce_bio_set = bioset_create(BIO_POOL_SIZE, 0);
> + BUG_ON(!bounce_bio_set);
> + if (bioset_integrity_create(bounce_bio_set, BIO_POOL_SIZE))
> + BUG_ON(1);
> +
> + bounce_bio_split = bioset_create_nobvec(BIO_POOL_SIZE, 0);
> + BUG_ON(!bounce_bio_split);
> +
> return 0;
> }
>
> @@ -194,7 +203,23 @@ static void __blk_queue_bounce(struct request_queue *q,
> struct bio **bio_orig,
>
> return;
> bounce:
> - bio = bio_clone_bioset(*bio_orig, GFP_NOIO, fs_bio_set);
> + if (bio_segments(*bio_orig) > BIO_MAX_PAGES) {
> + int cnt = 0;
> + int sectors = 0;
> + struct bio_vec bv;
> + struct bvec_iter iter;
> + bio_for_each_segment(bv, *bio_orig, iter) {
The two bio_for_each_segment()(one is in bio_segments()) can be merged to
one.
> + if (cnt++ < BIO_MAX_PAGES)
> + sectors += bv.bv_len >> 9;
> + else
> + break;
> + }
> + bio = bio_split(*bio_orig, sectors, GFP_NOIO,
> bounce_bio_split);
> + bio_chain(bio, *bio_orig);
> + generic_make_request(*bio_orig);
> + *bio_orig = bio;
> + }
> + bio = bio_clone_bioset(*bio_orig, GFP_NOIO, bounce_bio_set);
>
> bio_for_each_segment_all(to, bio, i) {
> struct page *page = to->bv_page;
>
>
Thanks,
Ming Lei
Re: [musl] Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
On Fri, Apr 21, 2017 at 03:14:21PM +0200, Hauke Mehrtens wrote: > > > On 04/20/2017 10:36 PM, David Miller wrote: > > From: David Woodhouse > > Date: Thu, 20 Apr 2017 21:14:37 +0100 > > > >> I agree, except I don't think you're going far enough. Those "standard > >> names" you mention... some of this stuff actually depends on __GLIBC__, > >> and *that* isn't right either. > > > > Yep, that's something that needs correcting. > > > Should all libc implementations define __GLIBC__ Absolutely not. Rich
[PATCH v2 12/17] IB/mlx4: Delete an unnecessary variable assignment in mlx4_ib_add()
From: Markus Elfring
Date: Fri, 21 Apr 2017 18:52:03 +0200
Delete an assignment for the local variable "num_ports" at the beginning
because it was initialised with the same value.
Signed-off-by: Markus Elfring
Reviewed-by: Majd Dibbiny
---
drivers/infiniband/hw/mlx4/main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index d08b9b154c97..4eb2466530dc 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2618,8 +2618,6 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
struct counter_index *new_counter_index;
pr_info_once("%s", mlx4_ib_version);
-
- num_ports = 0;
mlx4_foreach_ib_transport_port(i, dev)
num_ports++;
--
2.12.2
Re: [PATCH 2/2] ASoC: codec: wm8960: Relax bit clock computation when using PLL
On Fri, Apr 21, 2017 at 3:07 PM, Daniel Baluta wrote:
> Bitclk is derived from sysclk using bclk_divs.
> Sysclk can be derived in two ways:
> (1) directly from MLCK
> (2) MCLK via PLL
>
> Commit 3c01b9ee2ab9d0d ("ASoC: codec: wm8960: Relax bit clock
> computation")
> relaxed bitclk computation when sysclk is directly derived from MCLK.
>
> Lets do the same thing when sysclk is derived via PLL.
>
> Signed-off-by: Daniel Baluta
> ---
> Here, I forced the following harmless initialization:
>
> *sysclk_idx = *dac_idx = *bclk_idx = -1;
>
> otherwise I would trigger a gcc false positive warning:
>
> sound/soc/codecs/wm8960.c: In function 'wm8960_configure_clocking':
> sound/soc/codecs/wm8960.c:810:46: warning: 'j' may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> snd_soc_update_bits(codec, WM8960_CLOCK1, 0x7 << 6, j << 6);
> ~~^~~~
> sound/soc/codecs/wm8960.c:806:44: warning: 'i' may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> snd_soc_update_bits(codec, WM8960_CLOCK1, 3 << 1, i << 1);
> ~~^~~~
I saw the same warning earlier, but it was gone after the rework
I posted the other day. Please try if that works for you as well, I think
that would be better than a bogus initialization.
Arnd
Re: Unchecked flags in statx(2) [Should be fixed before 4.11-final?]
On Apr 21, 2017, at 7:13 AM, Michael Kerrisk (man-pages) wrote: > > On 04/21/2017 03:01 PM, David Howells wrote: >> Michael Kerrisk (man-pages) wrote: > >> (3) There's no problem with asking for extra bits, even if the running >> kerneldoes not support them, because the kernel tells you in its >> response what fields it actually gave you. > > It's this piece that I overlooked. Makes sense, of course. > Sorry for the noise! I agree with David that we don't want to return an error if the application asks for more bits than the kernel supports, otherwise the interface would be useless. Maybe this implies that this needs to be explained more clearly in the statx man page? Cheers, Andreas signature.asc Description: Message signed with OpenPGP
Re: [PATCH 11/11] block: don't check for BIO_MAX_PAGES in blk_bio_segment_split()
On Fri, Apr 21, 2017 at 7:34 PM, Christoph Hellwig wrote: > On Thu, Apr 20, 2017 at 03:38:50PM +1000, NeilBrown wrote: >> blk_bio_segment_split() makes sure bios have no more than >> BIO_MAX_PAGES entries in the bi_io_vec. >> This was done because bio_clone_bioset() (when given a >> mempool bioset) could not handle larger io_vecs. >> >> No driver uses bio_clone_bioset() any more, they all >> use bio_clone_fast() if anything, and bio_clone_fast() >> doesn't clone the bi_io_vec. > > Hmm. From Jens tree: > > drivers/lightnvm/pblk-read.c: int_bio = bio_clone_bioset(bio, > GFP_KERNEL, fs_bio_set); > drivers/md/raid1.c: mbio = > bio_clone_bioset_partial(bio, GFP_NOIO, > drivers/md/raid1.c: mbio = > bio_clone_bioset_partial(bio, GFP_NOIO, Btrfs use bio_clone_bioset() too: fs/btrfs/extent_io.c:2703: new = bio_clone_bioset(bio, gfp_mask, btrfs_bioset); Thanks, Ming Lei
[PATCH 1/1] staging: fbtft: Fix Sparse warning in fb_watterott.c
Sparse reports the following in fb_watterott.c:
warning: incorrect type in assignment (different base types)
expected unsigned short [unsigned] [short] [usertype]
got restricted __be16 [usertype]
Use __be16 types for endian correctness
Signed-off-by: Cezary Gapinski
---
drivers/staging/fbtft/fb_watterott.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fb_watterott.c
b/drivers/staging/fbtft/fb_watterott.c
index 4293045..180e5be 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -69,8 +69,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset,
size_t len)
{
unsigned int start_line, end_line;
u16 *vmem16 = (u16 *)(par->info->screen_buffer + offset);
- u16 *pos = par->txbuf.buf + 1;
- u16 *buf16 = par->txbuf.buf + 10;
+ __be16 *pos = par->txbuf.buf + 1;
+ __be16 *buf16 = par->txbuf.buf + 10;
int i, j;
int ret = 0;
@@ -106,7 +106,7 @@ static int write_vmem_8bit(struct fbtft_par *par, size_t
offset, size_t len)
{
unsigned int start_line, end_line;
u16 *vmem16 = (u16 *)(par->info->screen_buffer + offset);
- u16 *pos = par->txbuf.buf + 1;
+ __be16 *pos = par->txbuf.buf + 1;
u8 *buf8 = par->txbuf.buf + 10;
int i, j;
int ret = 0;
--
2.7.4
Re: [PATCH v2 3/3] x86/mm: Fix flush_tlb_page() on Xen
On 04/21/2017 02:15 PM, Andy Lutomirski wrote:
> flush_tlb_page() passes a bogus range to flush_tlb_others() and
> expects the latter to fix it up. native_flush_tlb_others() has the
> fixup but Xen's version doesn't. Move the fixup to
> flush_tlb_others().
>
> AFAICS the only real effect is that, without this fix, Xen would
> flush everything instead of just the one page on remote vCPUs in
> when flush_tlb_page() was called.
>
> Cc: Rik van Riel
> Cc: Dave Hansen
> Cc: Nadav Amit
> Cc: Michal Hocko
> Cc: Sasha Levin
> Cc: Andrew Morton
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Konrad Rzeszutek Wilk
> Fixes: e7b52ffd45a6 ("x86/flush_tlb: try flush_tlb_single one by one in
> flush_tlb_range")
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/mm/tlb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Thanks, Andy.
Reviewed-by: Boris Ostrovsky
[PATCH v2 13/17] IB/mlx4: Delete an error message for a failed memory allocation in mlx4_ib_add()
From: Markus Elfring
Date: Fri, 21 Apr 2017 18:55:35 +0200
Omit an extra message for a memory allocation failure in this function.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx4/main.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 4eb2466530dc..67368dea9b6a 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2626,11 +2626,8 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
return NULL;
ibdev = (struct mlx4_ib_dev *) ib_alloc_device(sizeof(*ibdev));
- if (!ibdev) {
- dev_err(&dev->persist->pdev->dev,
- "Device struct alloc failed\n");
+ if (!ibdev)
return NULL;
- }
iboe = &ibdev->iboe;
--
2.12.2
Re: [PATCH net] ip6mr: fix notification device destruction
On Fri, Apr 21, 2017 at 8:30 PM, Nikolay Aleksandrov
wrote:
> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>> because we call unregister_netdevice_many for a device that is already
>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>> long time ago by introducing the "notify" parameter to the delete
>> function and avoiding the unregister when called from a notifier, so
>> let's do the same for ip6mr.
Hi Nikolay,
Your patch fixes BUG_ON() being triggered for me.
Tested-by: Andrey Konovalov
Thanks!
>>
>> The trace from Andrey:
>> [ cut here ]
>> kernel BUG at net/core/dev.c:6813!
>> invalid opcode: [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>> 01/01/2011
>> Workqueue: netns cleanup_net
>> task: 880069208000 task.stack: 8800692d8000
>> RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813
>> RSP: 0018:8800692de7f0 EFLAGS: 00010297
>> RAX: 880069208000 RBX: 0002 RCX: 0001
>> RDX: RSI: RDI: 88006af90569
>> RBP: 8800692de9f0 R08: 8800692dec60 R09:
>> R10: 0006 R11: R12: 88006af90070
>> R13: 8800692debf0 R14: dc00 R15: 88006af9
>> FS: () GS:88006cb0()
>> knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 7fe7e897d870 CR3: 657e7000 CR4: 06e0
>> Call Trace:
>> unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
>> unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880
>> ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346
>> notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
>> __raw_notifier_call_chain kernel/notifier.c:394
>> raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>> call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
>> call_netdevice_notifiers net/core/dev.c:1663
>> rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841
>> unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
>> unregister_netdevice_many net/core/dev.c:7880
>> default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333
>> ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144
>> cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463
>> process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097
>> worker_thread+0x223/0x19c0 kernel/workqueue.c:2231
>> kthread+0x35e/0x430 kernel/kthread.c:231
>> ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
>> Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89
>> 47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f>
>> 0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00
>> RIP: rollback_registered_many+0x348/0xeb0 RSP: 8800692de7f0
>> ---[ end trace e0b29c57e9b3292c ]---
>>
>> Reported-by: Andrey Konovalov
>> Signed-off-by: Nikolay Aleksandrov
>> ---
>
> +CC LKML and Linus
>
>> Andrey could you please test with this patch applied ?
>> I have run the reproducer locally and can no longer trigger the bug.
>> I've made "notify" an int instead of a bool only to be closer to the ipmr
>> code for easier future patches.
>>
>> net/ipv6/ip6mr.c | 13 ++---
>> 1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
>> index fb4546e80c82..374997d26488 100644
>> --- a/net/ipv6/ip6mr.c
>> +++ b/net/ipv6/ip6mr.c
>> @@ -774,7 +774,8 @@ static struct net_device *ip6mr_reg_vif(struct net *net,
>> struct mr6_table *mrt)
>> * Delete a VIF entry
>> */
>>
>> -static int mif6_delete(struct mr6_table *mrt, int vifi, struct list_head
>> *head)
>> +static int mif6_delete(struct mr6_table *mrt, int vifi, int notify,
>> +struct list_head *head)
>> {
>> struct mif_device *v;
>> struct net_device *dev;
>> @@ -820,7 +821,7 @@ static int mif6_delete(struct mr6_table *mrt, int vifi,
>> struct list_head *head)
>>dev->ifindex, &in6_dev->cnf);
>> }
>>
>> - if (v->flags & MIFF_REGISTER)
>> + if ((v->flags & MIFF_REGISTER) && !notify)
>> unregister_netdevice_queue(dev, head);
>>
>> dev_put(dev);
>> @@ -1331,7 +1332,6 @@ static int ip6mr_device_event(struct notifier_block
>> *this,
>> struct mr6_table *mrt;
>> struct mif_device *v;
>> int ct;
>> - LIST_HEAD(list);
>>
>> if (event != NETDEV_UNREGISTER)
>> return NOTIFY_DONE;
>> @@ -1340,10 +1340,9 @@ static int ip6mr_device_event(struct notifier_block
>> *this,
>> v = &mrt->vif6_table[0];
>> for (ct = 0; ct < mrt->maxvif; ct++, v++) {
>> if (v->dev == dev)
>> - m
Re: [PATCH v1 1/1] srcu-cbmc: Use /usr/bin/awk instead of /bin/awk
On Sat, Apr 22, 2017 at 10:17:11AM -0700, priyalee.kushw...@intel.com wrote: > From: Priyalee Kushwaha > > Most OS distribution have awk in /usr/bin not in /bin > Without this patch, kernel-devsrc fails to build as > runtime dependency for srcu-cbmc script /bin/awk is > not found. > > Signed-off-by: Kushwaha, Priyalee For anyone that has it in /bin/awk, does it have a compatibility symlink from /usr/bin/awk (or vice versa), or not? If not, then this would break the build for those folks. We could just drop the shebang and the executable bit, and run "awk -f modify_srcu.awk" from whatever script invokes this. > tools/testing/selftests/rcutorture/formal/srcu-cbmc/modify_srcu.awk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/tools/testing/selftests/rcutorture/formal/srcu-cbmc/modify_srcu.awk > b/tools/testing/selftests/rcutorture/formal/srcu-cbmc/modify_srcu.awk > index 8ff8904..c9e8bc5 100755 > --- a/tools/testing/selftests/rcutorture/formal/srcu-cbmc/modify_srcu.awk > +++ b/tools/testing/selftests/rcutorture/formal/srcu-cbmc/modify_srcu.awk > @@ -1,4 +1,4 @@ > -#!/bin/awk -f > +#!/usr/bin/awk -f > > # Modify SRCU for formal verification. The first argument should be srcu.h > and > # the second should be srcu.c. Outputs modified srcu.h and srcu.c into the > -- > 2.10.0 >
Re: [PATCH 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
On 2017-04-21 06:08, Marek Vasut wrote:
> On 04/21/2017 05:15 AM, Stefan Agner wrote:
>> On 2017-04-20 19:03, Marek Vasut wrote:
>>> On 04/21/2017 03:07 AM, Stefan Agner wrote:
Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
clock architecture requiring only two clocks to be referenced.
The IP is slightly different compared to i.MX 6SoloX, but currently
none of this differences are in use so there is no detection needed
and the driver can reuse IS_MX6SX.
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index c8bbf5da2ab8..4a45d37ddc80 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx
= {
.clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
};
+static const char * const gpmi_clks_for_mx7d[] = {
+ "gpmi_io", "gpmi_bch_apb",
+};
+
+static const struct gpmi_devdata gpmi_devdata_imx7d = {
+ .type = IS_MX6SX,
>>>
>>> Would it make sense to use IS_MX7 here already to prevent future surprises ?
>>>
>>
>> Yeah I was thinking we can do it once we have an actual reason to
>> distinguish.
>
> So what are the differences anyway ?
>
I did not check the details, but Han's patchset (link in cover letter)
mentions:
"add the HW bitflip detection and correction for i.MX6QP and i.MX7D."...
>> But then, adding the type would only require 2-3 lines of change if I
>> add it to the GPMI_IS_MX6 macro...
>
> Then at least add a comment because using type = IMX6SX right under
> gpmi_data_mx7d can trigger some head-scratching. And put my R-B on V2.
FWIW, I mentioned it in the commit message.
I think rather then adding a comment it is cleaner to just add IS_IMX7D
and add it to the GPMI_IS_MX6 macro. That does not need a comment since
it implicitly says we have a i.MX 7 but treat it like i.MX 6 and it is a
rather small change. Does that sound acceptable?
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -132,7 +132,7 @@ static const char * const gpmi_clks_for_mx7d[] = {
};
static const struct gpmi_devdata gpmi_devdata_imx7d = {
- .type = IS_MX6SX,
+ .type = IS_MX7D,
.bch_max_ecc_strength = 62,
.max_chain_delay = 12,
.clks = gpmi_clks_for_mx7d,
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 2e584e18d980..f2cc13abc896 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -123,7 +123,8 @@ enum gpmi_type {
IS_MX23,
IS_MX28,
IS_MX6Q,
- IS_MX6SX
+ IS_MX6SX,
+ IS_MX7D,
};
struct gpmi_devdata {
@@ -307,6 +308,8 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
#define GPMI_IS_MX28(x)((x)->devdata->type == IS_MX28)
#define GPMI_IS_MX6Q(x)((x)->devdata->type == IS_MX6Q)
#define GPMI_IS_MX6SX(x) ((x)->devdata->type == IS_MX6SX)
+#define GPMI_IS_MX7D(x)((x)->devdata->type == IS_MX7D)
-#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x))
+#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x) ||
\
+GPMI_IS_MX7D(x))
#endif
--
Stefan
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On Fri, 2017-04-21 at 08:27 -0600, David Ahern wrote: > On 4/20/17 10:09 AM, Andrey Konovalov wrote: > > On Thu, Apr 20, 2017 at 5:39 PM, Andrey Konovalov > > wrote: > >> On Thu, Apr 20, 2017 at 5:35 PM, David Ahern > >> wrote: > >>> On 4/20/17 9:28 AM, Andrey Konovalov wrote: > This one seems to be much closer to what Dmitry reported intially. > >>> does not repro here; I ran in a loop and nothing. > > Here's strace log, maybe it'll help figuring out why it doesn't reproduce: > > reproduced. working on it. Thanks guys for working on this ;)
[PATCH v1 6/8] mei: Use recently introduced uuid_le_cmp_p{p}() helpers
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Tomas Winkler
Signed-off-by: Andy Shevchenko
---
drivers/misc/mei/bus-fixup.c | 2 +-
drivers/misc/mei/bus.c | 2 +-
drivers/misc/mei/client.c| 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 0208c4b027c5..de0fcd98d162 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -416,7 +416,7 @@ void mei_cl_bus_dev_fixup(struct mei_cl_device *cldev)
f = &mei_fixups[i];
if (uuid_le_cmp(f->uuid, MEI_UUID_ANY) == 0 ||
- uuid_le_cmp(f->uuid, *uuid) == 0)
+ uuid_le_cmp_p(uuid, f->uuid) == 0)
f->hook(cldev);
}
}
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index d1928fdd0f43..e15549f71891 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -615,7 +615,7 @@ struct mei_cl_device_id *mei_cl_device_find(struct
mei_cl_device *cldev,
id = cldrv->id_table;
while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
- if (!uuid_le_cmp(*uuid, id->uuid)) {
+ if (!uuid_le_cmp_p(uuid, id->uuid)) {
match = true;
if (cldev->name[0])
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index be64969d986a..590accb369bd 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -148,7 +148,7 @@ static struct mei_me_client *__mei_me_cl_by_uuid(struct
mei_device *dev,
list_for_each_entry(me_cl, &dev->me_clients, list) {
pn = &me_cl->props.protocol_name;
- if (uuid_le_cmp(*uuid, *pn) == 0)
+ if (uuid_le_cmp_pp(uuid, pn) == 0)
return mei_me_cl_get(me_cl);
}
@@ -228,7 +228,7 @@ static struct mei_me_client *__mei_me_cl_by_uuid_id(struct
mei_device *dev,
list_for_each_entry(me_cl, &dev->me_clients, list) {
pn = &me_cl->props.protocol_name;
- if (uuid_le_cmp(*uuid, *pn) == 0 &&
+ if (uuid_le_cmp_pp(uuid, pn) == 0 &&
me_cl->client_id == client_id)
return mei_me_cl_get(me_cl);
}
--
2.11.0
[PATCH v2 14/17] IB/mlx4: Delete unnecessary braces in mlx4_ib_add()
From: Markus Elfring
Date: Fri, 21 Apr 2017 18:58:43 +0200
Do not use curly brackets at one source code place
where a single statement should be sufficient.
Signed-off-by: Markus Elfring
Reviewed-by: Majd Dibbiny
---
drivers/infiniband/hw/mlx4/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 67368dea9b6a..7dd5468cd4b8 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2901,9 +2901,8 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
}
if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_ROCE_V1_V2) {
err = mlx4_config_roce_v2_port(dev, ROCE_V2_UDP_DPORT);
- if (err) {
+ if (err)
goto err_notif;
- }
}
}
--
2.12.2
Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design
On 21 April 2017 at 08:12, Alex Shi wrote:
> The rt-mutex-design documents didn't gotten meaningful update from its
> first version. Even after owner's pending bit was removed in commit
> 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'plist' changed to rbtree. So the documents are far
> late of real code.
>
> Update it to latest code and make it meaningful.
>
> Signed-off-by: Alex Shi
> Cc: Steven Rostedt
> Cc: Sebastian Siewior
> To: linux-...@vger.kernel.org
> To: linux-kernel@vger.kernel.org
> To: Jonathan Corbet
> To: Ingo Molnar
> To: Peter Zijlstra
> Cc: Thomas Gleixner
> ---
> Documentation/locking/rt-mutex-design.txt | 390
> +++---
> 1 file changed, 88 insertions(+), 302 deletions(-)
>
> diff --git a/Documentation/locking/rt-mutex-design.txt
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter - A waiter is a struct that is stored on the stack
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable). This
> structure holds a pointer to the task, as well as the mutex that
> - the task is blocked on. It also has the plist node structures to
> - place the task in the waiter_list of a mutex as well as the
> - pi_list of a mutex owner task (described below).
> + the task is blocked on. It also has a rbtree node structures to
Here I assume we are talking about struct rt_mutex_waiter[1]. If so I
suggest to replace rbtree with rb_node.
> + place the task in waiters rbtree of a mutex as well as the
> + pi_waiters rbtree of a mutex owner task (described below).
Also following the comment for @pi_tree_entry, s/"a mutex owner
task"/"a mutex owner waiters tree" .
[1]. http://lxr.free-electrons.com/source/kernel/locking/rtmutex_common.h#L25
>
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
> |
> F->L5-+
>
> -
> -Plist
> --
> -
> -Before I go further and talk about how the PI chain is stored through lists
> -on both mutexes and processes, I'll explain the plist. This is similar to
> -the struct list_head functionality that is already in the kernel.
> -The implementation of plist is out of scope for this document, but it is
> -very important to understand what it does.
> -
> -There are a few differences between plist and list, the most important one
> -being that plist is a priority sorted linked list. This means that the
> -priorities of the plist are sorted, such that it takes O(1) to retrieve the
> -highest priority item in the list. Obviously this is useful to store
> processes
> -based on their priorities.
> -
> -Another difference, which is important for implementation, is that, unlike
> -list, the head of the list is a different element than the nodes of a list.
> -So the head of the list is declared as struct plist_head and nodes that will
> -be added to the list are declared as struct plist_node.
> -
> +If the G process has highest priority in the chain, then all the tasks up
If process G has the highest priority in the chain, ...
> +the chain (A and B in this example), must have their priorities increased
> +to that of G.
>
> Mutex Waiter List
> -
>
> Every mutex keeps track of all the waiters that are blocked on itself. The
> mutex
> -has a plist to store these waiters by priority. This list is protected by
> +has a rbtree to store these waiters by priority. This tree is protected by
> a spin lock that is located in the struct of the mutex. This lock is called
> -wait_lock. Since the modification of the waiter list is never done in
> +wait_lock. Since the modification of the waiter tree is never done in
> interrupt context, the wait_lock can be taken without disabling interrupts.
>
>
> -Task PI List
> +Task PI Tree
>
>
> -To keep track of the PI chains, each process has its own PI list. This is
> -a list of all top waiters of the mutexes that are owned by the process.
> -Note that this list only holds the top waiters and not all waiters that are
> +To keep track of the PI chains, each process has its own PI rbtree. This is
> +a tree of all top waiters of the mutexes that are owned by the process.
> +Note that this tree only holds the top waiters and not all waiters that are
> blocked on mutexes owned by the process.
>
> -The top of the task's PI list is always the highest priority task that
> +The top of the task's PI tree is always the highest priority task that
> is waiting on a mutex that is owned by the task. So if the task has
> inherited a priority, it wil
[PATCH v2 15/17] IB/mlx4: Delete unwanted spaces behind usages of the sizeof operator
From: Markus Elfring
Date: Fri, 21 Apr 2017 19:11:59 +0200
* Replace the source code "sizeof (" by "sizeof("
according to the Linux coding style convention.
* Adjust indentation at a few places.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx4/qp.c | 128
1 file changed, 63 insertions(+), 65 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index c2a0f75d7d07..068abfdc9d01 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -342,39 +342,39 @@ static int send_wqe_overhead(enum mlx4_ib_qp_type type,
u32 flags)
*/
switch (type) {
case MLX4_IB_QPT_UD:
- return sizeof (struct mlx4_wqe_ctrl_seg) +
- sizeof (struct mlx4_wqe_datagram_seg) +
+ return sizeof(struct mlx4_wqe_ctrl_seg) +
+ sizeof(struct mlx4_wqe_datagram_seg) +
((flags & MLX4_IB_QP_LSO) ? MLX4_IB_LSO_HEADER_SPARE :
0);
case MLX4_IB_QPT_PROXY_SMI_OWNER:
case MLX4_IB_QPT_PROXY_SMI:
case MLX4_IB_QPT_PROXY_GSI:
- return sizeof (struct mlx4_wqe_ctrl_seg) +
- sizeof (struct mlx4_wqe_datagram_seg) + 64;
+ return sizeof(struct mlx4_wqe_ctrl_seg) +
+ sizeof(struct mlx4_wqe_datagram_seg) + 64;
case MLX4_IB_QPT_TUN_SMI_OWNER:
case MLX4_IB_QPT_TUN_GSI:
- return sizeof (struct mlx4_wqe_ctrl_seg) +
- sizeof (struct mlx4_wqe_datagram_seg);
+ return sizeof(struct mlx4_wqe_ctrl_seg) +
+ sizeof(struct mlx4_wqe_datagram_seg);
case MLX4_IB_QPT_UC:
- return sizeof (struct mlx4_wqe_ctrl_seg) +
- sizeof (struct mlx4_wqe_raddr_seg);
+ return sizeof(struct mlx4_wqe_ctrl_seg) +
+ sizeof(struct mlx4_wqe_raddr_seg);
case MLX4_IB_QPT_RC:
- return sizeof (struct mlx4_wqe_ctrl_seg) +
- sizeof (struct mlx4_wqe_masked_atomic_seg) +
- sizeof (struct mlx4_wqe_raddr_seg);
+ return sizeof(struct mlx4_wqe_ctrl_seg) +
+ sizeof(struct mlx4_wqe_masked_atomic_seg) +
+ sizeof(struct mlx4_wqe_raddr_seg);
case MLX4_IB_QPT_SMI:
case MLX4_IB_QPT_GSI:
- return sizeof (struct mlx4_wqe_ctrl_seg) +
+ return sizeof(struct mlx4_wqe_ctrl_seg) +
ALIGN(MLX4_IB_UD_HEADER_SIZE +
DIV_ROUND_UP(MLX4_IB_UD_HEADER_SIZE,
MLX4_INLINE_ALIGN) *
- sizeof (struct mlx4_wqe_inline_seg),
- sizeof (struct mlx4_wqe_data_seg)) +
+ sizeof(struct mlx4_wqe_inline_seg),
+ sizeof(struct mlx4_wqe_data_seg)) +
ALIGN(4 +
- sizeof (struct mlx4_wqe_inline_seg),
- sizeof (struct mlx4_wqe_data_seg));
+ sizeof(struct mlx4_wqe_inline_seg),
+ sizeof(struct mlx4_wqe_data_seg));
default:
- return sizeof (struct mlx4_wqe_ctrl_seg);
+ return sizeof(struct mlx4_wqe_ctrl_seg);
}
}
@@ -398,7 +398,8 @@ static int set_rq_size(struct mlx4_ib_dev *dev, struct
ib_qp_cap *cap,
qp->rq.wqe_cnt = roundup_pow_of_two(max(1U,
cap->max_recv_wr));
qp->rq.max_gs= roundup_pow_of_two(max(1U,
cap->max_recv_sge));
- qp->rq.wqe_shift = ilog2(qp->rq.max_gs * sizeof (struct
mlx4_wqe_data_seg));
+ qp->rq.wqe_shift = ilog2(qp->rq.max_gs
+* sizeof(struct mlx4_wqe_data_seg));
}
/* leave userspace return values as they were, so as not to break ABI */
@@ -426,7 +427,7 @@ static int set_kernel_sq_size(struct mlx4_ib_dev *dev,
struct ib_qp_cap *cap,
if (cap->max_send_wr > (dev->dev->caps.max_wqes -
MLX4_IB_SQ_MAX_SPARE) ||
cap->max_send_sge > min(dev->dev->caps.max_sq_sg,
dev->dev->caps.max_rq_sg) ||
cap->max_inline_data + send_wqe_overhead(type, qp->flags) +
- sizeof (struct mlx4_wqe_inline_seg) > dev->dev->caps.max_sq_desc_sz)
+ sizeof(struct mlx4_wqe_inline_seg) > dev->dev->caps.max_sq_desc_sz)
return -EINVAL;
/*
@@ -438,8 +439,8 @@ static int set_kernel_sq_size(struct mlx4_ib_dev *dev,
struct ib_qp_cap *cap,
cap->max_send_sge + 2 > dev->dev->caps.max_sq_sg)
return -EINVAL;
- s = max(cap->max_send_sge * sizeof (struct mlx4_wqe_data_seg),
- cap->max_inline_data + sizeof (struct mlx4_wqe_inline_seg)) +
+ s = max(cap->max_send_sge * sizeof(struct
Re: [RE][PATCH] drivers: input: joystick: Add PSX(Play Staion 1/2) pad with SPI driver Add PSX(Play Staion 1/2) pad with SPI driver. Pads can be connected directry SPI bus.
2017-04-21 1:15 GMT+02:00 AZO : > To Linux kernel input driver mainteners > > I mailed to mainteners a week ago. > Please can anyone answer? You should send the email directly to the maintainers in addition to the mailing list. You can use the get_maintainer.pl script to know who that is. > > Regard. > > = > AZO
Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support
+Cc: Heikki. He might comment on this. On Fri, Apr 21, 2017 at 4:01 PM, Hans de Goede wrote: > Add support for USB TYPE-C cable detection on systems using a > FUSB302 USB TYPE-C controller. > > Signed-off-by: Hans de Goede > --- > drivers/extcon/Kconfig | 8 + > drivers/extcon/Makefile | 1 + > drivers/extcon/extcon-fusb302.c | 782 > > 3 files changed, 791 insertions(+) > create mode 100644 drivers/extcon/extcon-fusb302.c > > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig > index 32f2dc8..562db5b 100644 > --- a/drivers/extcon/Kconfig > +++ b/drivers/extcon/Kconfig > @@ -35,6 +35,14 @@ config EXTCON_AXP288 > Say Y here to enable support for USB peripheral detection > and USB MUX switching by X-Power AXP288 PMIC. > > +config EXTCON_FUSB302 > + tristate "FUSB302 USB TYPE-C controller support" > + depends on I2C > + select REGMAP_I2C > + help > + Say Y here to enable support for USB TYPE-C cable detection using > + a FUSB302 USB TYPE-C controller. > + > config EXTCON_GPIO > tristate "GPIO extcon support" > depends on GPIOLIB || COMPILE_TEST > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile > index ecfa958..e5eb493 100644 > --- a/drivers/extcon/Makefile > +++ b/drivers/extcon/Makefile > @@ -7,6 +7,7 @@ extcon-core-objs+= extcon.o devres.o > obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o > obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o > obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o > +obj-$(CONFIG_EXTCON_FUSB302) += extcon-fusb302.o > obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o > obj-$(CONFIG_EXTCON_INTEL_INT3496) += extcon-intel-int3496.o > obj-$(CONFIG_EXTCON_INTEL_CHT_WC) += extcon-intel-cht-wc.o > diff --git a/drivers/extcon/extcon-fusb302.c b/drivers/extcon/extcon-fusb302.c > new file mode 100644 > index 000..577adb9 > --- /dev/null > +++ b/drivers/extcon/extcon-fusb302.c > @@ -0,0 +1,782 @@ > +/* > + * Extcon USB-C cable detection driver for FUSB302 USB TYPE-C controller > + * > + * Copyright (C) 2017 Hans de Goede > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "extcon.h" > + > +#define REG_DEVICE_ID 0x01 > +#define DEVICE_ID_VER_MASK GENMASK(7, 4) > +#define DEVICE_ID_FUSB302_VER 0x80 > + > +#define REG_SWITCHES0 0x02 > +#define SWITCHES0_PDWN1BIT(0) > +#define SWITCHES0_PDWN2BIT(1) > +#define SWITCHES0_PDWN GENMASK(1, 0) > +#define SWITCHES0_MEAS_CC1 BIT(2) > +#define SWITCHES0_MEAS_CC2 BIT(3) > +#define SWITCHES0_VCONN_CC1BIT(4) > +#define SWITCHES0_VCONN_CC2BIT(5) > +#define SWITCHES0_PU_EN1 BIT(6) > +#define SWITCHES0_PU_EN2 BIT(7) > + > +#define REG_MEASURE0x04 > +#define MEASURE_MDAC_MASK GENMASK(5, 0) > +/* Datasheet says MDAC must be set to 0x34 / 2226mV for vRd-3.0 detection */ > +#define MEASURE_MDAC_SNK_VRD30 0x34 > +/* MDAC must be set to 0x25 / 1600mV for disconnect det. with 80uA host-cur > */ > +#define MEASURE_MDAC_SRC_80UA_HOST_CUR 0x25 > + > +#define REG_CONTROL0 0x06 > +#define CONTROL0_HOST_CUR_MASK GENMASK(3, 2) > +#define CONTROL0_HOST_CUR_DISABLED (0 << 2) > +#define CONTROL0_HOST_CUR_80UA (1 << 2) > +#define CONTROL0_HOST_CUR_180UA(2 << 2) > +#define CONTROL0_HOST_CUR_330UA(3 << 2) > +#define CONTROL0_INT_MASK BIT(5) > + > +#define REG_CONTROL2 0x08 > +#define CONTROL2_TOGGLEBIT(0) > +#define CONTROL2_MODE_MASK GENMASK(2, 1) > +#define CONTROL2_MODE_DRP (1 << 1) > +#define CONTROL2_MODE_SNK (2 << 1) > +#define CONTROL2_MODE_SRC (3 << 1) > +#define CONTROL2_SAVE_PWR_MASK GENMASK(7, 6) > +#define CONTROL2_SAVE_PWR_DISABLED (0 << 6) > +#define CONTROL2_SAVE_PWR_40MS (1 << 6) > +#define CONTROL2_SAVE_PWR_80MS (2 << 6) > +#define CONTROL2_SAVE_PWR_160MS(3 << 6) > + > +#define REG_MASK1 0x0a > +/* REG_MASK1 value for low-power / disabled state from datasheet */ > +#define MASK1_DISABLED 0xfe > +#define MASK1_COMP_CHNG
Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
> 21 апр. 2017 г., в 17:18, Roger Quadros написал(а):
>
> I think the following commit broke functionality with interrupt driven PHYs
> 3c293f4e08b5 ("net: phy: Trigger state machine on state change and not
> polling.")
Probably this one[1] broke, according to Alexandre’s commit[2].
And it was since Nov 16 2015. But it was hidden by some other commits.
For Roger problem became visible after 3c293f4e08b5 ("net: phy:
Trigger state machine on state change and not polling.»),
For my problem became visible after 529ed1275263 ("net: phy: phy drivers
should not set SUPPORTED_[Asym_]Pause»). As commit 529ed1275263
removed SUPPORTED_Pause flag from PHY advertising property and
genphy_config_aneg() began to skip PHY auto-negotiation.
Alexander.
[1] Fixes: 321beec5047a (net: phy: Use interrupts when available in NOLINK
state)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=321beec5047af83db90c88114b7e664b156f49fe
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99f81afc139c6edd14d77a91ee91685a414a1c66
Re: [PATCH 4/5] extcon: intel-cht-wc: Add new cht_wc_extcon_set_state helper
+Cc: Heikki.
It looks like you better Cc him with entire series.
On Fri, Apr 21, 2017 at 4:01 PM, Hans de Goede wrote:
> This allows a nice cleanup of cht_wc_extcon_pwrsrc_event, getting rid
> of all the gotos in there.
>
> This also is a preparation patch for adding USB Type-C controller
> monitoring.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/extcon/extcon-intel-cht-wc.c | 54
> ++--
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/extcon/extcon-intel-cht-wc.c
> b/drivers/extcon/extcon-intel-cht-wc.c
> index 8806427e..684f6b2 100644
> --- a/drivers/extcon/extcon-intel-cht-wc.c
> +++ b/drivers/extcon/extcon-intel-cht-wc.c
> @@ -196,20 +196,40 @@ static void cht_wc_extcon_set_5v_boost(struct
> cht_wc_extcon_data *ext,
> }
>
> /* Small helper to sync EXTCON_CHG_USB_SDP and EXTCON_USB state */
> -static void cht_wc_extcon_set_state(struct cht_wc_extcon_data *ext,
> - unsigned int cable, bool state)
> +static void cht_wc_extcon_set_cable_state(struct cht_wc_extcon_data *ext,
> + unsigned int cable, bool state)
> {
> extcon_set_state_sync(ext->edev, cable, state);
> if (cable == EXTCON_CHG_USB_SDP)
> extcon_set_state_sync(ext->edev, EXTCON_USB, state);
> }
>
> +static void cht_wc_extcon_set_state(struct cht_wc_extcon_data *ext,
> + unsigned int new_cable)
> +{
> + if (new_cable == EXTCON_NONE && !ext->usb_host) {
> + /* Route D+ and D- to PMIC for future charger detection */
> + cht_wc_extcon_set_phymux(ext, MUX_SEL_PMIC);
> + } else {
> + /* Route D+ and D- to SoC for the host or gadget controller */
> + cht_wc_extcon_set_phymux(ext, MUX_SEL_SOC);
> + }
> +
> + if (new_cable != ext->previous_cable) {
> + cht_wc_extcon_set_cable_state(ext, new_cable, true);
> + cht_wc_extcon_set_cable_state(ext, ext->previous_cable,
> false);
> + ext->previous_cable = new_cable;
> + }
> +
> + extcon_set_state_sync(ext->edev, EXTCON_USB_HOST, ext->usb_host);
> +}
> +
> static void cht_wc_extcon_pwrsrc_event(struct cht_wc_extcon_data *ext)
> {
> int ret, pwrsrc_sts, id;
> unsigned int cable = EXTCON_NONE;
> /* Ignore errors in host mode, as the 5v boost converter is on then */
> - bool ignore_get_charger_errors = ext->usb_host;
> + bool ignore_get_charger_err = ext->usb_host;
>
> ret = regmap_read(ext->regmap, CHT_WC_PWRSRC_STS, &pwrsrc_sts);
> if (ret) {
> @@ -218,33 +238,13 @@ static void cht_wc_extcon_pwrsrc_event(struct
> cht_wc_extcon_data *ext)
> }
>
> id = cht_wc_extcon_get_id(ext, pwrsrc_sts);
> - if (id == USB_ID_GND) {
> - /* The 5v boost causes a false VBUS / SDP detect, skip */
> - goto charger_det_done;
> - }
> -
> - /* Plugged into a host/charger or not connected? */
> - if (!(pwrsrc_sts & CHT_WC_PWRSRC_VBUS)) {
> - /* Route D+ and D- to PMIC for future charger detection */
> - cht_wc_extcon_set_phymux(ext, MUX_SEL_PMIC);
> - goto set_state;
> - }
> -
> - cable = cht_wc_extcon_get_charger(ext, ignore_get_charger_errors);
>
> -charger_det_done:
> - /* Route D+ and D- to SoC for the host or gadget controller */
> - cht_wc_extcon_set_phymux(ext, MUX_SEL_SOC);
> -
> -set_state:
> - if (cable != ext->previous_cable) {
> - cht_wc_extcon_set_state(ext, cable, true);
> - cht_wc_extcon_set_state(ext, ext->previous_cable, false);
> - ext->previous_cable = cable;
> - }
> + /* When id == gnd the 5v boost causes a false VBUS detect */
> + if (id != USB_ID_GND && (pwrsrc_sts & CHT_WC_PWRSRC_VBUS))
> + cable = cht_wc_extcon_get_charger(ext,
> ignore_get_charger_err);
>
> ext->usb_host = ((id == USB_ID_GND) || (id == USB_RID_A));
> - extcon_set_state_sync(ext->edev, EXTCON_USB_HOST, ext->usb_host);
> + cht_wc_extcon_set_state(ext, cable);
> }
>
> static irqreturn_t cht_wc_extcon_isr(int irq, void *data)
> --
> 2.9.3
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 2/3] x86/mm: Make flush_tlb_mm_range() more predictable
On 04/21/2017 11:15 AM, Andy Lutomirski wrote: > I'm about to rewrite the function almost completely, but first I > want to get a functional change out of the way. Currently, if > flush_tlb_mm_range() does not flush the local TLB at all, it will > never do individual page flushes on remote CPUs. This seems to be > an accident, and preserving it will be awkward. Let's change it > first so that any regressions in the rewrite will be easier to > bisect and so that the rewrite can attempt to change no visible > behavior at all. > > The fix is simple: we can simply avoid short-circuiting the > calculation of base_pages_to_flush. This looks sane to me. I think it makes things more straightforward. Acked-by: Dave Hansen
[PATCH v2 16/17] IB/mlx4: Add spaces for better code readability
From: Markus Elfring
Date: Fri, 21 Apr 2017 19:14:11 +0200
Use space characters at some source code places according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx4/qp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 068abfdc9d01..15240163c399 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1065,7 +1065,7 @@ static void destroy_qp_common(struct mlx4_ib_dev *dev,
struct mlx4_ib_qp *qp,
list_del(&qp->cq_recv_list);
if (!is_user) {
__mlx4_ib_cq_clean(recv_cq, qp->mqp.qpn,
-qp->ibqp.srq ? to_msrq(qp->ibqp.srq): NULL);
+ qp->ibqp.srq ? to_msrq(qp->ibqp.srq) : NULL);
if (send_cq != recv_cq)
__mlx4_ib_cq_clean(send_cq, qp->mqp.qpn, NULL);
}
@@ -2599,7 +2599,7 @@ static int build_mlx_header(struct mlx4_ib_sqp *sqp,
struct ib_ud_wr *wr,
u16 ether_type;
u16 pcp = (be32_to_cpu(ah->av.ib.sl_tclass_flowlabel) >> 29) <<
13;
- ether_type = (!is_udp) ? ETH_P_IBOE:
+ ether_type = (!is_udp) ? ETH_P_IBOE :
(ip_version == 4 ? ETH_P_IP : ETH_P_IPV6);
mlx->sched_prio = cpu_to_be16(pcp);
--
2.12.2
Re: [PATCH 5/5] extcon: intel-cht-wc: Add support for monitoring external USB Type-C controller
+Cc: Heikki,
On Fri, Apr 21, 2017 at 4:01 PM, Hans de Goede wrote:
> On some boards the Whiskey Cove PMIC is combined with an external USB
> Type-C controller, in this case extcon consumers should use the Type-C
> extcon state, except when the USB Type-C controller detects a current
> limit of 500 mA which may indicate USB-C to USB-A cable at which point
> the extcon consumer should use the Whiskey Cove's BC-1.2 detection's
> state.
>
> Since the Type-C controller info is incomplete and needs to be
> supplemented with the BC1.2 detection result in some cases, this
> commit makes the intel-cht-wc extcon driver monitor the extcon device
> registered by the Type-C controller and report that as our extcon state
> except when BC-1.2 detection should be used. This allows extcon
> consumers on these boards to keep monitoring only the intel-cht-wc extcon
> and then get complete extcon info from that, which combines the Type-C
> and BC-1.2 info.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/extcon/extcon-intel-cht-wc.c | 96
> ++--
> 1 file changed, 80 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/extcon/extcon-intel-cht-wc.c
> b/drivers/extcon/extcon-intel-cht-wc.c
> index 684f6b2..e510188 100644
> --- a/drivers/extcon/extcon-intel-cht-wc.c
> +++ b/drivers/extcon/extcon-intel-cht-wc.c
> @@ -15,6 +15,7 @@
> * more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -88,6 +89,7 @@ static const unsigned int cht_wc_extcon_cables[] = {
> EXTCON_CHG_USB_CDP,
> EXTCON_CHG_USB_DCP,
> EXTCON_CHG_USB_ACA,
> + EXTCON_CHG_USB_FAST,
> EXTCON_NONE,
> };
>
> @@ -95,6 +97,9 @@ struct cht_wc_extcon_data {
> struct device *dev;
> struct regmap *regmap;
> struct extcon_dev *edev;
> + struct extcon_dev *usbc;
> + struct notifier_block usbc_nb;
> + struct work_struct work;
> unsigned int previous_cable;
> bool usb_host;
> };
> @@ -224,8 +229,32 @@ static void cht_wc_extcon_set_state(struct
> cht_wc_extcon_data *ext,
> extcon_set_state_sync(ext->edev, EXTCON_USB_HOST, ext->usb_host);
> }
>
> -static void cht_wc_extcon_pwrsrc_event(struct cht_wc_extcon_data *ext)
> +static void cht_wc_extcon_usb_c_event(struct work_struct *work)
> {
> + struct cht_wc_extcon_data *ext =
> + container_of(work, struct cht_wc_extcon_data, work);
> + unsigned int cable = EXTCON_NONE;
> +
> + if (extcon_get_state(ext->usbc, EXTCON_CHG_USB_SDP) > 0) {
> + /*
> +* USB-C to USB-A cable ? Try BC1.2 charger detection from
> +* WC PMIC, ignore charger detection errors.
> +*/
> + cable = cht_wc_extcon_get_charger(ext, true);
> + } else if (extcon_get_state(ext->usbc, EXTCON_CHG_USB_CDP) > 0) {
> + cable = EXTCON_CHG_USB_CDP;
> + } else if (extcon_get_state(ext->usbc, EXTCON_CHG_USB_FAST) > 0) {
> + cable = EXTCON_CHG_USB_FAST;
> + }
> +
> + ext->usb_host = (extcon_get_state(ext->usbc, EXTCON_USB_HOST) > 0);
> + cht_wc_extcon_set_state(ext, cable);
> +}
> +
> +static void cht_wc_extcon_pwrsrc_event(struct work_struct *work)
> +{
> + struct cht_wc_extcon_data *ext =
> + container_of(work, struct cht_wc_extcon_data, work);
> int ret, pwrsrc_sts, id;
> unsigned int cable = EXTCON_NONE;
> /* Ignore errors in host mode, as the 5v boost converter is on then */
> @@ -258,7 +287,7 @@ static irqreturn_t cht_wc_extcon_isr(int irq, void *data)
> return IRQ_NONE;
> }
>
> - cht_wc_extcon_pwrsrc_event(ext);
> + schedule_work(&ext->work);
>
> ret = regmap_write(ext->regmap, CHT_WC_PWRSRC_IRQ, irqs);
> if (ret) {
> @@ -269,6 +298,17 @@ static irqreturn_t cht_wc_extcon_isr(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +static int cht_wc_extcon_usbc_evt(struct notifier_block *nb,
> + unsigned long event, void *param)
> +{
> + struct cht_wc_extcon_data *ext =
> + container_of(nb, struct cht_wc_extcon_data, usbc_nb);
> +
> + schedule_work(&ext->work);
> +
> + return NOTIFY_OK;
> +}
> +
> static int cht_wc_extcon_sw_control(struct cht_wc_extcon_data *ext, bool
> enable)
> {
> int ret, mask, val;
> @@ -300,6 +340,15 @@ static int cht_wc_extcon_probe(struct platform_device
> *pdev)
> ext->regmap = pmic->regmap;
> ext->previous_cable = EXTCON_NONE;
>
> + if (acpi_dev_present("INT33FE", NULL, -1)) {
> + ext->usbc = extcon_get_extcon_dev("fusb302");
> + if (!ext->usbc)
> + return -EPROBE_DEFER;
> +
> + dev_info(&pdev->dev,
> +"Using FUSB302 extcon for USB Type-C cable info\n");
> + }
> +
> /* Initialize extcon device */
> ext->edev = de
Re: net/core: BUG in unregister_netdevice_many
On Fri, Apr 21, 2017 at 10:25 AM, Linus Torvalds wrote: > On Fri, Apr 21, 2017 at 5:48 AM, Andrey Konovalov > wrote: >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> [ cut here ] >> kernel BUG at net/core/dev.c:6813! > > Another useless BUG_ON() that I think we are double-unregister'ing the pim6reg device, we probably need something like: commit 7dc00c82cbb0119cf4663f65bbaa2cc55f961db2 Author: Wang Chen Date: Mon Jul 14 20:56:34 2008 -0700 ipv4: Fix ipmr unregister device oops An oops happens during device unregister.
[PATCH v2 17/17] IB/mlx5: Less function calls in create_kernel_qp() after error detection
From: Markus Elfring
Date: Fri, 21 Apr 2017 19:19:20 +0200
The kfree() function was called in up to five cases
by the create_kernel_qp() function during error handling
even if the passed data structure member contained a null pointer.
* Adjust jump targets according to the Linux coding style convention.
* Split a condition check for memory allocation failures so that
each pointer from these function calls will be checked immediately.
See also background information:
Topic "CWE-754: Improper check for unusual or exceptional conditions"
Link: https://cwe.mitre.org/data/definitions/754.html
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/mlx5/qp.c | 43 ++---
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 1e98a8c9fab8..c7bfa8ffaf0d 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -934,7 +934,7 @@ static int create_kernel_qp(struct mlx5_ib_dev *dev,
*in = mlx5_vzalloc(*inlen);
if (!*in) {
err = -ENOMEM;
- goto err_buf;
+ goto free_buffer;
}
qpc = MLX5_ADDR_OF(create_qp_in, *in, qpc);
@@ -956,45 +956,56 @@ static int create_kernel_qp(struct mlx5_ib_dev *dev,
err = mlx5_db_alloc(dev->mdev, &qp->db);
if (err) {
mlx5_ib_dbg(dev, "err %d\n", err);
- goto err_free;
+ goto vfree_in;
}
qp->sq.wrid = kmalloc_array(qp->sq.wqe_cnt,
sizeof(*qp->sq.wrid),
GFP_KERNEL);
+ if (!qp->sq.wrid)
+ goto free_db;
+
qp->sq.wr_data = kmalloc_array(qp->sq.wqe_cnt,
sizeof(*qp->sq.wr_data),
GFP_KERNEL);
+ if (!qp->sq.wr_data)
+ goto free_sq_wrid;
+
qp->rq.wrid = kmalloc_array(qp->rq.wqe_cnt,
sizeof(*qp->rq.wrid),
GFP_KERNEL);
+ if (!qp->rq.wrid)
+ goto free_sq_wr_data;
+
qp->sq.w_list = kmalloc_array(qp->sq.wqe_cnt,
sizeof(*qp->sq.w_list),
GFP_KERNEL);
+ if (!qp->sq.w_list)
+ goto free_rq_wrid;
+
qp->sq.wqe_head = kmalloc_array(qp->sq.wqe_cnt,
sizeof(*qp->sq.wqe_head),
GFP_KERNEL);
- if (!qp->sq.wrid || !qp->sq.wr_data || !qp->rq.wrid ||
- !qp->sq.w_list || !qp->sq.wqe_head) {
- err = -ENOMEM;
- goto err_wrid;
- }
+ if (!qp->sq.wqe_head)
+ goto free_sq_w_list;
+
qp->create_type = MLX5_QP_KERNEL;
return 0;
-
-err_wrid:
- kfree(qp->sq.wqe_head);
+free_sq_w_list:
kfree(qp->sq.w_list);
- kfree(qp->sq.wrid);
- kfree(qp->sq.wr_data);
+free_rq_wrid:
kfree(qp->rq.wrid);
+free_sq_wr_data:
+ kfree(qp->sq.wr_data);
+free_sq_wrid:
+ kfree(qp->sq.wrid);
+free_db:
mlx5_db_free(dev->mdev, &qp->db);
-
-err_free:
+ err = -ENOMEM;
+vfree_in:
kvfree(*in);
-
-err_buf:
+free_buffer:
mlx5_buf_free(dev->mdev, &qp->buf);
return err;
}
--
2.12.2
[PATCH v2] power: tps65217_charger: Add properties like voltage and current charge
Allow the possibility to configure the charge and the current voltage of
the charger and also the NTC type for battery temperature measurement.
Signed-off-by: Enric Balletbo i Serra
---
Changes since v1:
- Requested by Rob Herring
- Rename ti,charge-* to charge-* to be standard properties.
- Use unit suffixes as per bindings/property-units.txt
---
.../bindings/power/supply/tps65217_charger.txt | 15 ++
drivers/power/supply/tps65217_charger.c| 187 +++--
include/linux/mfd/tps65217.h | 2 +
3 files changed, 192 insertions(+), 12 deletions(-)
diff --git
a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
index a11072c..4415618 100644
--- a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
+++ b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
@@ -6,6 +6,18 @@ Required Properties:
Should be <0> for the USB charger and <1> for the AC adapter.
-interrupt-names: Should be "USB" and "AC"
+Optional properties:
+-charge-voltage-microvolt: set the charge voltage. The value can be: 410,
+ 415, 420, 425; default: 410
+
+-charge-current-microamp: set the charging current. The value can be: 30,
+ 40, 50, 70; default: 50
+
+-ti,ntc-type: set the NTC type for battery temperature measurement. The value
+ must be 0 or 1, where:
+ 0 – 100k (curve 1, B = 3960)
+ 1 – 10k (curve 2, B = 3480) (default)
+
This node is a subnode of the tps65217 PMIC.
Example:
@@ -14,4 +26,7 @@ Example:
compatible = "ti,tps65217-charger";
interrupts = <0>, <1>;
interrupt-names = "USB", "AC";
+ charge-voltage-microvolt = <410>;
+ charge-current-microamp = <50>;
+ ti,ntc-type = <1>;
};
diff --git a/drivers/power/supply/tps65217_charger.c
b/drivers/power/supply/tps65217_charger.c
index 1f52340..087f29c 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -39,6 +39,12 @@
#define NUM_CHARGER_IRQS 2
#define POLL_INTERVAL (HZ * 2)
+struct tps65217_charger_platform_data {
+ u32 charge_current_uamp;
+ u32 charge_voltage_uvolt;
+ int ntc_type;
+};
+
struct tps65217_charger {
struct tps65217 *tps;
struct device *dev;
@@ -48,16 +54,82 @@ struct tps65217_charger {
int prev_online;
struct task_struct *poll_task;
+ struct tps65217_charger_platform_data *pdata;
};
static enum power_supply_property tps65217_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
};
-static int tps65217_config_charger(struct tps65217_charger *charger)
+static int tps65217_set_charge_current(struct tps65217_charger *charger,
+ unsigned int uamp)
+{
+ int ret, val;
+
+ dev_dbg(charger->dev, "setting charge current to %d uA\n", uamp);
+
+ if (uamp == 30)
+ val = 0x00;
+ else if (uamp == 40)
+ val = 0x01;
+ else if (uamp == 50)
+ val = 0x02;
+ else if (uamp == 70)
+ val = 0x03;
+ else
+ return -EINVAL;
+
+ ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG3,
+ TPS65217_CHGCONFIG3_ICHRG_MASK,
+ val << TPS65217_CHGCONFIG3_ICHRG_SHIFT,
+ TPS65217_PROTECT_NONE);
+ if (ret) {
+ dev_err(charger->dev,
+ "failed to set ICHRG setting to 0x%02x (err: %d)\n",
+ val, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int tps65217_set_charge_voltage(struct tps65217_charger *charger,
+ unsigned int uvolt)
+{
+ int ret, val;
+
+ dev_dbg(charger->dev, "setting charge voltage to %d uV\n", uvolt);
+
+ if (uvolt != 410 && uvolt != 415 &&
+ uvolt != 420 && uvolt != 425)
+ return -EINVAL;
+
+ val = (uvolt - 410) / 5;
+
+ ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG2,
+ TPS65217_CHGCONFIG2_VOREG_MASK,
+ val << TPS65217_CHGCONFIG2_VOREG_SHIFT,
+ TPS65217_PROTECT_NONE);
+ if (ret) {
+ dev_err(charger->dev,
+ "failed to set VOCHG setting to 0x%02x (err: %d)\n",
+ val, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int tps65217_set_ntc_type(struct tps65217_charger *charger,
+unsigned int ntc)
{
int ret;
+ dev_dbg(charger->dev, "setting NTC type to %d\n", ntc);
+
Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption
On 4/18/2017 4:22 PM, Tom Lendacky wrote:
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
configuration of the default state). If memory encryption is to be
activated, then the encryption mask is set and the kernel is encrypted
"in place."
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/head_64.S |1 +
arch/x86/mm/mem_encrypt.c | 83 +++--
2 files changed, 80 insertions(+), 4 deletions(-)
...
-unsigned long __init sme_enable(void)
+unsigned long __init sme_enable(struct boot_params *bp)
{
+ const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
+ unsigned int eax, ebx, ecx, edx;
+ unsigned long me_mask;
+ bool active_by_default;
+ char buffer[16];
So it turns out that when KASLR is enabled (CONFIG_RAMDOMIZE_BASE=y)
the stack-protector support causes issues with this function because
it is called so early. I can get past it by adding:
CFLAGS_mem_encrypt.o := $(nostackp)
in the arch/x86/mm/Makefile, but that obviously eliminates the support
for the whole file. Would it be better to split out the sme_enable()
and other boot routines into a separate file or just apply the
$(nostackp) to the whole file?
Thanks,
Tom
+ u64 msr;
+
+ /* Check for the SME support leaf */
+ eax = 0x8000;
+ ecx = 0;
+ native_cpuid(&eax, &ebx, &ecx, &edx);
+ if (eax < 0x801f)
+ goto out;
+
+ /*
+* Check for the SME feature:
+* CPUID Fn8000_001F[EAX] - Bit 0
+* Secure Memory Encryption support
+* CPUID Fn8000_001F[EBX] - Bits 5:0
+* Pagetable bit position used to indicate encryption
+*/
+ eax = 0x801f;
+ ecx = 0;
+ native_cpuid(&eax, &ebx, &ecx, &edx);
+ if (!(eax & 1))
+ goto out;
+ me_mask = 1UL << (ebx & 0x3f);
+
+ /* Check if SME is enabled */
+ msr = __rdmsr(MSR_K8_SYSCFG);
+ if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
+ goto out;
+
+ /*
+* Fixups have not been applied to phys_base yet, so we must obtain
+* the address to the SME command line option data in the following
+* way.
+*/
+ asm ("lea sme_cmdline_arg(%%rip), %0"
+: "=r" (cmdline_arg)
+: "p" (sme_cmdline_arg));
+ asm ("lea sme_cmdline_on(%%rip), %0"
+: "=r" (cmdline_on)
+: "p" (sme_cmdline_on));
+ asm ("lea sme_cmdline_off(%%rip), %0"
+: "=r" (cmdline_off)
+: "p" (sme_cmdline_off));
+
+ if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT))
+ active_by_default = true;
+ else
+ active_by_default = false;
+
+ cmdline_ptr = (const char *)((u64)bp->hdr.cmd_line_ptr |
+((u64)bp->ext_cmd_line_ptr << 32));
+
+ cmdline_find_option(cmdline_ptr, cmdline_arg, buffer, sizeof(buffer));
+
+ if (strncmp(buffer, cmdline_on, sizeof(buffer)) == 0)
+ sme_me_mask = me_mask;
+ else if (strncmp(buffer, cmdline_off, sizeof(buffer)) == 0)
+ sme_me_mask = 0;
+ else
+ sme_me_mask = active_by_default ? me_mask : 0;
+
+out:
return sme_me_mask;
}
@@ -543,9 +618,9 @@ unsigned long sme_get_me_mask(void)
#else /* !CONFIG_AMD_MEM_ENCRYPT */
-void __init sme_encrypt_kernel(void) { }
-unsigned long __init sme_enable(void) { return 0; }
+void __init sme_encrypt_kernel(void) { }
+unsigned long __init sme_enable(struct boot_params *bp){ return 0; }
-unsigned long sme_get_me_mask(void){ return 0; }
+unsigned long sme_get_me_mask(void){ return 0; }
#endif /* CONFIG_AMD_MEM_ENCRYPT */
[PATCH v5 2/6] mtd: dataflash: Improve coding style in jedec_probe()
Change the following:
- Replace indentation between type and name of local variable from
tabs to spaces
- Replace magic number 0x1F with CFI_MFR_ATMEL macro
- Replace variable 'tmp' with 'ret' and 'i' where appropriate
- Reformat multi-line comments and add newlines where appropriate
No functional change intended.
Cc: cphe...@gmail.com
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Richard Weinberger
Cc: Cyrille Pitchen
Cc: Marek Vasut
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Vasut
Signed-off-by: Andrey Smirnov
---
No changes since [v3], [v4]
Changes since [v2]:
- Re-worded commit message
- Collected Acked-by from Marek
Not present in v1
[v2] http://lkml.kernel.org/r/20170418142127.23301-2-andrew.smir...@gmail.com
[v3] http://lkml.kernel.org/r/20170419152305.17226-2-andrew.smir...@gmail.com
[v4] http://lkml.kernel.org/r/20170420162952.5181-2-andrew.smir...@gmail.com
drivers/mtd/devices/mtd_dataflash.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/devices/mtd_dataflash.c
b/drivers/mtd/devices/mtd_dataflash.c
index a566231..5b7a8c3 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -82,6 +82,7 @@
#define OP_WRITE_SECURITY_REVC 0x9A
#define OP_WRITE_SECURITY 0x9B/* revision D */
+#define CFI_MFR_ATMEL 0x1F
struct dataflash {
u8 command[4];
@@ -738,14 +739,15 @@ static struct flash_info dataflash_data[] = {
static struct flash_info *jedec_probe(struct spi_device *spi)
{
- int tmp;
- u8 code = OP_READ_ID;
- u8 id[3];
- u32 jedec;
- struct flash_info *info;
+ int ret, i;
+ u8 code = OP_READ_ID;
+ u8 id[3];
+ u32 jedec;
+ struct flash_info *info;
int status;
- /* JEDEC also defines an optional "extended device information"
+ /*
+* JEDEC also defines an optional "extended device information"
* string for after vendor-specific data, after the three bytes
* we use here. Supporting some chips might require using it.
*
@@ -753,13 +755,14 @@ static struct flash_info *jedec_probe(struct spi_device
*spi)
* That's not an error; only rev C and newer chips handle it, and
* only Atmel sells these chips.
*/
- tmp = spi_write_then_read(spi, &code, 1, id, 3);
- if (tmp < 0) {
+ ret = spi_write_then_read(spi, &code, 1, id, 3);
+ if (ret < 0) {
pr_debug("%s: error %d reading JEDEC ID\n",
- dev_name(&spi->dev), tmp);
- return ERR_PTR(tmp);
+ dev_name(&spi->dev), ret);
+ return ERR_PTR(ret);
}
- if (id[0] != 0x1f)
+
+ if (id[0] != CFI_MFR_ATMEL)
return NULL;
jedec = id[0];
@@ -768,9 +771,9 @@ static struct flash_info *jedec_probe(struct spi_device
*spi)
jedec = jedec << 8;
jedec |= id[2];
- for (tmp = 0, info = dataflash_data;
- tmp < ARRAY_SIZE(dataflash_data);
- tmp++, info++) {
+ for (i = 0, info = dataflash_data;
+ i < ARRAY_SIZE(dataflash_data);
+ i++, info++) {
if (info->jedec_id == jedec) {
pr_debug("%s: OTP, sector protect%s\n",
dev_name(&spi->dev),
--
2.9.3
Re: [PATCH] hwmon: (ibmpowernv) Add min/max attributes and current sensors
Hello Shilpasri,
On 04/21/2017 06:31 AM, Shilpasri G Bhat wrote:
> Add support for adding min/max values for the inband sensors copied by
> OCC to main memory. And also add current(mA) sensors to the list.
>
> Signed-off-by: Shilpasri G Bhat
> ---
> drivers/hwmon/ibmpowernv.c | 55
> --
> 1 file changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 6d2e660..1f329fa8 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -50,6 +50,7 @@ enum sensors {
> TEMP,
> POWER_SUPPLY,
> POWER_INPUT,
> + CURRENT,
> MAX_SENSOR_TYPE,
> };
>
> @@ -65,7 +66,8 @@ enum sensors {
> {"fan", "ibm,opal-sensor-cooling-fan"},
> {"temp", "ibm,opal-sensor-amb-temp"},
> {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + {"power", "ibm,opal-sensor-power"},
> + {"curr"}, /* Follows newer device tree compatible ibm,opal-sensor */
why isn't there a compatible string ?
> };
>
> struct sensor_data {
> @@ -287,6 +289,7 @@ static int populate_attr_groups(struct platform_device
> *pdev)
> opal = of_find_node_by_path("/ibm,opal/sensors");
> for_each_child_of_node(opal, np) {
> const char *label;
> + int len;
>
> if (np->name == NULL)
> continue;
> @@ -298,10 +301,14 @@ static int populate_attr_groups(struct platform_device
> *pdev)
> sensor_groups[type].attr_count++;
>
> /*
> - * add a new attribute for labels
> + * add attributes for labels, min and max
>*/
> if (!of_property_read_string(np, "label", &label))
> sensor_groups[type].attr_count++;
We are negating of_property_read_string() above, but not below.
I wonder why ?
> + if (of_find_property(np, "sensor-data-min", &len))
> + sensor_groups[type].attr_count++;
> + if (of_find_property(np, "sensor-data-max", &len))
> + sensor_groups[type].attr_count++;
> }
>
> of_node_put(opal);
> @@ -428,6 +435,50 @@ static int create_device_attrs(struct platform_device
> *pdev)
> pgroups[type]->attrs[sensor_groups[type].attr_count++] =
> &sdata[count++].dev_attr.attr;
> }
> +
> + if (!of_property_read_u32(np, "sensor-data-max", &sensor_id)) {
> + switch (type) {
> + case POWER_INPUT:
> + attr_name = "input_highest";
> + break;
> + case TEMP:
> + attr_name = "max";
> + break;
> + default:
> + attr_name = "highest";
> + break;
> + }
May be we could use a converting routine here ? create_device_attrs()
is getting big.
> + sdata[count].id = sensor_id;
> + sdata[count].type = type;
> + sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
> + create_hwmon_attr(&sdata[count], attr_name,
> + show_sensor);
> + pgroups[type]->attrs[sensor_groups[type].attr_count++] =
> + &sdata[count++].dev_attr.attr;
> + }
> +
> + if (!of_property_read_u32(np, "sensor-data-min", &sensor_id)) {
> + switch (type) {
> + case POWER_INPUT:
> + attr_name = "input_lowest";
> + break;
> + case TEMP:
> + attr_name = "min";
> + break;
> + default:
> + attr_name = "lowest";
> + break;
> + }
same here.
Thanks,
C.
> + sdata[count].id = sensor_id;
> + sdata[count].type = type;
> + sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
> + create_hwmon_attr(&sdata[count], attr_name,
> + show_sensor);
> + pgroups[type]->attrs[sensor_groups[type].attr_count++] =
> + &sdata[count++].dev_attr.attr;
> + }
> }
>
> exit_put_node:
>
Re: Heads-up: two regressions in v4.11-rc series
On Thu, Apr 20, 2017 at 7:30 AM, Mel Gorman wrote: >> The end result was a revert, and this is waiting in AKPMs quilt queue: >> >> http://ozlabs.org/~akpm/mmots/broken-out/revert-mm-page_alloc-only-use-per-cpu-allocator-for-irq-safe-requests.patch >> > > This was flagged to Andrew that it should go in for either 4.11 or if > there were concerns about how close to the release we are then put it in > for 4.11-stable. At worst, I can do a resubmit to -stable myself after > it gets merged in the next window if it falls between the cracks. This got merged (commit d34b0733b452: "Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests""). The other issue (caused by commit a499a5a14dbd: "sched/cputime: Increment kcpustat directly on irqtime account") is still open. Frederic? Revert? But I guess it's something we can delay for backporting, it's presumably not possible to hit maliciously except on some fast local network attacker just causing an effective DoS. Linus
Re: iov_iter_pipe warning.
On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
> Well it's been running an hour without incident, which looks promising.
> I'll leave it run, but I'd say you're on the right track given how quick
> it reproduced so far.
Could you try this and see if it works? What happens is that unlike
e.g. generic_file_read_iter/generic_file_write_iter, NFS O_DIRECT handling
does not make sure that iov_iter had been advanced by the amount
actually transferred - it is left advanced by the amount *requested*.
mm/filemap.c code gets around that by taking a copy of iov_iter, feeding
it to ->direct_IO() and then advancing the original by the amount actually
done. That's what the previous patch had duplicated for NFS, but we have
a cleaner way to do that now - both for NFS and in mm/filemap.c. Namely,
use iov_iter_revert(). For NFS it means making nfs_direct_..._schedule_iovec()
return how much it has actually requested from server and having their
callers do iov_iter_revert() after nfs_direct_wait() has reported how much
has actually come through. I've similar patches for mm/filemap.c avoiding
the games with copy of iov_iter there, but those are not fixes per se,
so they are separate. This one just deals with NFS.
fix nfs O_DIRECT advancing iov_iter too much
It leaves the iterator advanced by the amount of IO it has requested
instead of the amount actually transferred. Among other things,
that confuses the hell out of generic_file_splice_read().
Signed-off-by: Al Viro
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index aab32fc3d6a8..c1b5fed7c863 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -537,7 +537,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct
nfs_direct_req *dreq,
if (put_dreq(dreq))
nfs_direct_complete(dreq);
- return 0;
+ return requested_bytes;
}
/**
@@ -566,7 +566,7 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct
iov_iter *iter)
struct inode *inode = mapping->host;
struct nfs_direct_req *dreq;
struct nfs_lock_context *l_ctx;
- ssize_t result = -EINVAL;
+ ssize_t result = -EINVAL, requested;
size_t count = iov_iter_count(iter);
nfs_add_stats(mapping->host, NFSIOS_DIRECTREADBYTES, count);
@@ -600,14 +600,19 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct
iov_iter *iter)
nfs_start_io_direct(inode);
NFS_I(inode)->read_io += count;
- result = nfs_direct_read_schedule_iovec(dreq, iter, iocb->ki_pos);
+ requested = nfs_direct_read_schedule_iovec(dreq, iter, iocb->ki_pos);
nfs_end_io_direct(inode);
- if (!result) {
+ if (requested > 0) {
result = nfs_direct_wait(dreq);
- if (result > 0)
+ if (result > 0) {
+ requested -= result;
iocb->ki_pos += result;
+ }
+ iov_iter_revert(iter, requested);
+ } else {
+ result = requested;
}
out_release:
@@ -954,7 +959,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct
nfs_direct_req *dreq,
if (put_dreq(dreq))
nfs_direct_write_complete(dreq);
- return 0;
+ return requested_bytes;
}
/**
@@ -979,7 +984,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct
nfs_direct_req *dreq,
*/
ssize_t nfs_file_direct_write(struct kiocb *iocb, struct iov_iter *iter)
{
- ssize_t result = -EINVAL;
+ ssize_t result = -EINVAL, requested;
size_t count;
struct file *file = iocb->ki_filp;
struct address_space *mapping = file->f_mapping;
@@ -1022,7 +1027,7 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct
iov_iter *iter)
nfs_start_io_direct(inode);
- result = nfs_direct_write_schedule_iovec(dreq, iter, pos);
+ requested = nfs_direct_write_schedule_iovec(dreq, iter, pos);
if (mapping->nrpages) {
invalidate_inode_pages2_range(mapping,
@@ -1031,13 +1036,17 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb,
struct iov_iter *iter)
nfs_end_io_direct(inode);
- if (!result) {
+ if (requested > 0) {
result = nfs_direct_wait(dreq);
if (result > 0) {
+ requested -= result;
iocb->ki_pos = pos + result;
/* XXX: should check the generic_write_sync retval */
generic_write_sync(iocb, result);
}
+ iov_iter_revert(iter, requested);
+ } else {
+ result = requested;
}
out_release:
nfs_direct_req_release(dreq);
Re: [PATCH V2] scsi: mpt3sas: remove redundant wmb
On 04/21/2017 02:56 AM, Sreekanth Reddy wrote: > On Thu, Apr 20, 2017 at 7:58 AM, Martin K. Petersen > wrote: >> Sinan Kaya writes: >> >>> Due to relaxed ordering requirements on multiple architectures, >>> drivers are required to use wmb/rmb/mb combinations when they need to >>> guarantee observability between the memory and the HW. >>> >>> The mpt3sas driver is already using wmb() for this purpose. However, >>> it issues a writel following wmb(). writel() function on arm/arm64 >>> arhictectures have an embedded wmb() call inside. > > [Sreekanth] Whether same thing applicable for SPARC & POWER > architectures. If yes then we are fine with this patch changes. This is also true for Power. Reviewed-by: Brian King -Brian -- Brian King Power Linux I/O IBM Linux Technology Center
Re: [PATCH v2 1/5] PCI: rockchip: fix sign issues for current limits
On Thu, Mar 23, 2017 at 05:27:17PM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 09, 2017 at 06:46:13PM -0800, Brian Norris wrote:
> > The regulator framework can return negative error codes via
> > regulator_get_current_limit() for regulators that don't provide current
> > information. The subsequent check for postive values isn't very useful,
> > if the variable is unsigned.
> >
> > Let's just match the signedness of the return value.
> >
> > Prevents error messages like this, seen on Samsung Chromebook Plus:
> >
> > [1.069372] rockchip-pcie f800.pcie: invalid power supply
> >
> > Fixes: 4816c4c7b82b ("PCI: rockchip: Provide captured slot power limit and
> > scale")
> > Signed-off-by: Brian Norris
> > Acked-by: Shawn Lin
>
> I applied the first two patches (this already has Shawn's ack and the
> second is trivially obvious) to pci/host-rockchip. I'm not sure what the
> current state of the others is.
I applied patches 3-5 with Shawn's ack to pci/host-rockchip for v4.12,
thanks!
> > ---
> > v2: add Shawn's ack
> > ---
> > drivers/pci/host/pcie-rockchip.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pcie-rockchip.c
> > b/drivers/pci/host/pcie-rockchip.c
> > index 26ddd3535272..d785f64ec03b 100644
> > --- a/drivers/pci/host/pcie-rockchip.c
> > +++ b/drivers/pci/host/pcie-rockchip.c
> > @@ -425,7 +425,8 @@ static struct pci_ops rockchip_pcie_ops = {
> >
> > static void rockchip_pcie_set_power_limit(struct rockchip_pcie *rockchip)
> > {
> > - u32 status, curr, scale, power;
> > + int curr;
> > + u32 status, scale, power;
> >
> > if (IS_ERR(rockchip->vpcie3v3))
> > return;
> > --
> > 2.12.0.246.ga2ecc84866-goog
> >
>
> commit 73edd2b180a18024605c599074596a9e22d745d6
> Author: Bjorn Helgaas
> Date: Thu Mar 23 17:21:26 2017 -0500
>
> PCI: rockchip: Unindent rockchip_pcie_set_power_limit()
>
> If regulator_get_current_limit() returns 0 or error, return early so the
> body of the function doesn't have to be indented as the body of an "if"
> statement. No functional change intended.
>
> Signed-off-by: Bjorn Helgaas
>
> diff --git a/drivers/pci/host/pcie-rockchip.c
> b/drivers/pci/host/pcie-rockchip.c
> index d785f64ec03b..7f76ff6af0ba 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -438,24 +438,25 @@ static void rockchip_pcie_set_power_limit(struct
> rockchip_pcie *rockchip)
>* to the actual power supply.
>*/
> curr = regulator_get_current_limit(rockchip->vpcie3v3);
> - if (curr > 0) {
> - scale = 3; /* 0.001x */
> - curr = curr / 1000; /* convert to mA */
> - power = (curr * 3300) / 1000; /* milliwatt */
> - while (power > PCIE_RC_CONFIG_DCR_CSPL_LIMIT) {
> - if (!scale) {
> - dev_warn(rockchip->dev, "invalid power
> supply\n");
> - return;
> - }
> - scale--;
> - power = power / 10;
> - }
> + if (curr <= 0)
> + return;
>
> - status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_DCR);
> - status |= (power << PCIE_RC_CONFIG_DCR_CSPL_SHIFT) |
> - (scale << PCIE_RC_CONFIG_DCR_CPLS_SHIFT);
> - rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_DCR);
> + scale = 3; /* 0.001x */
> + curr = curr / 1000; /* convert to mA */
> + power = (curr * 3300) / 1000; /* milliwatt */
> + while (power > PCIE_RC_CONFIG_DCR_CSPL_LIMIT) {
> + if (!scale) {
> + dev_warn(rockchip->dev, "invalid power supply\n");
> + return;
> + }
> + scale--;
> + power = power / 10;
> }
> +
> + status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_DCR);
> + status |= (power << PCIE_RC_CONFIG_DCR_CSPL_SHIFT) |
> + (scale << PCIE_RC_CONFIG_DCR_CPLS_SHIFT);
> + rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_DCR);
> }
>
> /**
Re: time: hang due to timer_create/timer_settime
On Fri, 21 Apr 2017, Thomas Gleixner wrote: > On Fri, 21 Apr 2017, Andrey Konovalov wrote: > > Hi, > > > > I've got the following error report while fuzzing the kernel with syzkaller. > > > > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > > > A reproducer and .config are attached. > > > > The program hangs the kernel. > > lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3762 > > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > > _raw_spin_lock_irqsave+0xc4/0x110 kernel/locking/spinlock.c:159 > > alarmtimer_fired+0x169/0x7a0 kernel/time/alarmtimer.c:189 > > __run_hrtimer kernel/time/hrtimer.c:1212 [inline] > > __hrtimer_run_queues+0x350/0xe50 kernel/time/hrtimer.c:1276 > > hrtimer_interrupt+0x1ab/0x5c0 kernel/time/hrtimer.c:1310 > > local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:937 > > smp_apic_timer_interrupt+0x71/0xa0 arch/x86/kernel/apic/apic.c:961 > > apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487 > > Right. That lacks the protection which we have in the other posix > timers. I'll have a look. But what's even more alarming is: (*(uint64_t*)0x20aedfe0 = (uint64_t)0x0); (*(uint64_t*)0x20aedfe8 = (uint64_t)0x989680); (*(uint64_t*)0x20aedff0 = (uint64_t)0x80077359400); (*(uint64_t*)0x20aedff8 = (uint64_t)0x0); r[11] = execute_syscall(__NR_timer_settime, r[6], 0x0ul, 0x20aedfe0ul, 0x20715fe0ul, 0, 0, 0, 0, 0); 0x20aedfe0 is the itimerspec handed to timer_create(). So its->it_interval.tv_sec = 0; its->it_interval.tv_nsec = 0x989680; its->it_value.tv_sec = 0x80077359400; its->it_value.tv_nsec = 0; it_value.tv_sec is 1.82795e+10 YEARS into the future. How does that timer fire in the first place? Thanks, tglx
Re: time: hang due to timer_create/timer_settime
On Fri, 21 Apr 2017, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > A reproducer and .config are attached. > > The program hangs the kernel. > lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3762 > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > _raw_spin_lock_irqsave+0xc4/0x110 kernel/locking/spinlock.c:159 > alarmtimer_fired+0x169/0x7a0 kernel/time/alarmtimer.c:189 > __run_hrtimer kernel/time/hrtimer.c:1212 [inline] > __hrtimer_run_queues+0x350/0xe50 kernel/time/hrtimer.c:1276 > hrtimer_interrupt+0x1ab/0x5c0 kernel/time/hrtimer.c:1310 > local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:937 > smp_apic_timer_interrupt+0x71/0xa0 arch/x86/kernel/apic/apic.c:961 > apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487 Right. That lacks the protection which we have in the other posix timers. I'll have a look. Thanks, tglx
Re: [PATCH] PCI: don't allow unbinding host controllers that aren't prepared
On Thu, Mar 30, 2017 at 06:12:03PM -0700, Brian Norris wrote:
> Many PCI host controller drivers aren't prepared to have their devices
> unbound from them forcefully (e.g., through /sys/...//unbind),
> as they don't provide any driver .remove callback, where they'd detach
> the root bus, release resources, etc. Keeping the driver built in (i.e.,
> not a loadable module) is not enough; and providing no .remove callback
> just means we don't do any teardown.
>
> To rule out the possibility of unbinding a device via sysfs, we need to
> set the ".suppress_bind_attrs" field.
>
> I found the suspect drivers via the following search:
>
> git grep -l platform_driver $(git grep -L -e '\.remove' -e
> suppress_bind_attrs drivers/pci/)
>
> Then I inspected them to ensure that
> (a) they set up a PCI bus in their probe() and
> (b) they don't have a remove() callback for undoing the setup
>
> I excluded drivers/pci/host/pcie-rockchip.c, because I've implemented
> remove() support elsewhere [1].
>
> [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1349576.html
> [PATCH v2 3/5] PCI: rockchip: add remove() support
>
> Suggested-by: Bjorn Helgaas
> Signed-off-by: Brian Norris
Applied to pci/remove for v4.12, thanks, Brian!
> ---
> Not tested, other than to compile a few of these.
>
> drivers/pci/dwc/pci-imx6.c | 1 +
> drivers/pci/dwc/pci-layerscape.c | 1 +
> drivers/pci/dwc/pcie-armada8k.c| 1 +
> drivers/pci/dwc/pcie-artpec6.c | 1 +
> drivers/pci/dwc/pcie-designware-plat.c | 1 +
> drivers/pci/dwc/pcie-hisi.c| 2 ++
> drivers/pci/dwc/pcie-spear13xx.c | 1 +
> drivers/pci/host/pci-ftpci100.c| 1 +
> drivers/pci/host/pci-host-generic.c| 1 +
> drivers/pci/host/pci-thunder-ecam.c| 1 +
> drivers/pci/host/pci-thunder-pem.c | 1 +
> drivers/pci/host/pci-versatile.c | 1 +
> drivers/pci/host/pci-xgene.c | 1 +
> 13 files changed, 14 insertions(+)
>
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index 801e46cd266d..f85a063e9964 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -725,6 +725,7 @@ static struct platform_driver imx6_pcie_driver = {
> .driver = {
> .name = "imx6q-pcie",
> .of_match_table = imx6_pcie_of_match,
> + .suppress_bind_attrs = true,
> },
> .shutdown = imx6_pcie_shutdown,
> };
> diff --git a/drivers/pci/dwc/pci-layerscape.c
> b/drivers/pci/dwc/pci-layerscape.c
> index c32e392a0ae6..880f345bff43 100644
> --- a/drivers/pci/dwc/pci-layerscape.c
> +++ b/drivers/pci/dwc/pci-layerscape.c
> @@ -305,6 +305,7 @@ static struct platform_driver ls_pcie_driver = {
> .driver = {
> .name = "layerscape-pcie",
> .of_match_table = ls_pcie_of_match,
> + .suppress_bind_attrs = true,
> },
> };
> builtin_platform_driver_probe(ls_pcie_driver, ls_pcie_probe);
> diff --git a/drivers/pci/dwc/pcie-armada8k.c b/drivers/pci/dwc/pcie-armada8k.c
> index f110e3b24a26..9d8f7e4db5df 100644
> --- a/drivers/pci/dwc/pcie-armada8k.c
> +++ b/drivers/pci/dwc/pcie-armada8k.c
> @@ -262,6 +262,7 @@ static struct platform_driver armada8k_pcie_driver = {
> .driver = {
> .name = "armada8k-pcie",
> .of_match_table = of_match_ptr(armada8k_pcie_of_match),
> + .suppress_bind_attrs = true,
> },
> };
> builtin_platform_driver(armada8k_pcie_driver);
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index fcd3ef845883..7a86d4b4dcc1 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -290,6 +290,7 @@ static struct platform_driver artpec6_pcie_driver = {
> .driver = {
> .name = "artpec6-pcie",
> .of_match_table = artpec6_pcie_of_match,
> + .suppress_bind_attrs = true,
> },
> };
> builtin_platform_driver(artpec6_pcie_driver);
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c
> b/drivers/pci/dwc/pcie-designware-plat.c
> index b6c832ba39dd..bdb75a5758ae 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -129,6 +129,7 @@ static struct platform_driver dw_plat_pcie_driver = {
> .driver = {
> .name = "dw-pcie",
> .of_match_table = dw_plat_pcie_of_match,
> + .suppress_bind_attrs = true,
> },
> .probe = dw_plat_pcie_probe,
> };
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index fd66a3199db7..088ed5e4e46b 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -334,6 +334,7 @@ static struct platform_driver hisi_pcie_driver = {
> .driver = {
> .name = "hisi-pcie",
> .of_match_table = hisi_pcie_of_match,
> +.suppress_bind_attrs = true,
> },
> };
> builtin_platform_d
[RFC PATCH 2/2] bug.h: replace __FILE__ with KBUILD_FILE for shorter names in log
__FILE__ can be a long absolute path for out-of-tree build.
The output of WARN_ON() and friends depends on the location of
the object tree, like this:
WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:...
KBUILD_FILE is a relative from srctree, so we will always see the
same path with/without O= option.
WARNING: CPU: 1 PID: 1 at arch/arm64/kernel/foo.c:...
Note:
"git grep __FILE__" has more than 1000 hits. Perhaps, we may want
to do 's/__FILE__/KBUILD_FILE/' tree-wide.
Signed-off-by: Masahiro Yamada
---
arch/alpha/include/asm/bug.h | 2 +-
arch/arc/include/asm/bug.h| 2 +-
arch/arm/include/asm/bug.h| 4 ++--
arch/arm64/include/asm/bug.h | 2 +-
arch/avr32/include/asm/bug.h | 2 +-
arch/blackfin/include/asm/bug.h | 2 +-
arch/cris/include/arch-v10/arch/bug.h | 6 +++---
arch/cris/include/arch-v32/arch/bug.h | 2 +-
arch/frv/include/asm/bug.h| 2 +-
arch/ia64/include/asm/bug.h | 2 +-
arch/m68k/include/asm/bug.h | 4 ++--
arch/mn10300/include/asm/bug.h| 2 +-
arch/parisc/include/asm/bug.h | 4 ++--
arch/powerpc/include/asm/bug.h| 8
arch/s390/include/asm/bug.h | 2 +-
arch/score/include/asm/bug.h | 4 ++--
arch/sh/include/asm/bug.h | 8
arch/sparc/include/asm/bug.h | 2 +-
arch/x86/include/asm/bug.h| 2 +-
include/asm-generic/bug.h | 8
20 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/arch/alpha/include/asm/bug.h b/arch/alpha/include/asm/bug.h
index f091682..8dd0661 100644
--- a/arch/alpha/include/asm/bug.h
+++ b/arch/alpha/include/asm/bug.h
@@ -12,7 +12,7 @@
__asm__ __volatile__( \
"call_pal %0 # bugchk\n\t" \
".long %1\n\t.8byte %2" \
- : : "i"(PAL_bugchk), "i"(__LINE__), "i"(__FILE__)); \
+ : : "i"(PAL_bugchk), "i"(__LINE__), "i"(KBUILD_FILE)); \
unreachable(); \
} while (0)
diff --git a/arch/arc/include/asm/bug.h b/arch/arc/include/asm/bug.h
index ea022d4..620f03e 100644
--- a/arch/arc/include/asm/bug.h
+++ b/arch/arc/include/asm/bug.h
@@ -22,7 +22,7 @@ void show_kernel_fault_diag(const char *str, struct pt_regs
*regs,
void die(const char *str, struct pt_regs *regs, unsigned long address);
#define BUG() do {
\
- pr_warn("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__);
\
+ pr_warn("BUG: failure at %s:%d/%s()!\n", KBUILD_FILE, __LINE__,
__func__); \
dump_stack();
\
} while (0)
diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 4e6e88a..8644f7d 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -19,13 +19,13 @@
#endif
-#define BUG() _BUG(__FILE__, __LINE__, BUG_INSTR_VALUE)
+#define BUG() _BUG(KBUILD_FILE, __LINE__, BUG_INSTR_VALUE)
#define _BUG(file, line, value) __BUG(file, line, value)
#ifdef CONFIG_DEBUG_BUGVERBOSE
/*
- * The extra indirection is to ensure that the __FILE__ string comes through
+ * The extra indirection is to ensure that the KBUILD_FILE string comes through
* OK. Many version of gcc do not support the asm %c parameter which would be
* preferable to this unpleasantness. We use mergeable string sections to
* avoid multiple copies of the string appearing in the kernel image.
diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 561190d..3d8826e 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -42,7 +42,7 @@
".pushsection __bug_table,\"a\"\n\t"\
".align 2\n\t" \
"0: .long 1f - 0b\n\t" \
-_BUGVERBOSE_LOCATION(__FILE__, __LINE__) \
+_BUGVERBOSE_LOCATION(KBUILD_FILE, __LINE__)\
".short " #flags "\n\t" \
".popsection\n" \
\
diff --git a/arch/avr32/include/asm/bug.h b/arch/avr32/include/asm/bug.h
index 85a92d0..b9b610c 100644
--- a/arch/avr32/include/asm/bug.h
+++ b/arch/avr32/include/asm/bug.h
@@ -29,7 +29,7 @@
" .org2b + %4\n" \
" .previous" \
: \
- : "i"(AVR32_BUG_OPCODE), "i"(__FILE__), \
+ : "i"(AVR32_BUG_OPCODE), "i"(KBUILD_FILE),
\
"i"(__LINE__), "i"(flags),\
"i"(sizeof(s
[RFC PATCH 1/2] kbuild: add KBUILD_FILE to point relative file path from $(srctree)
Since Kbuild runs in the objtree, __FILE__ can be a very long path
depending of $(srctree).
Commit 9da0763bdd82 ("kbuild: Use relative path when building in a
subdir of the source tree") made the situation better for cases
where objtree is a child of srctree. ($(srctree) is "..")
For other cases of out-of-tree build, filenames in WARN_ON() etc.
are still an absolute path. It also means the kernel image depends
on where it was built.
Here, the idea is to define a new macro, KBUILD_FILE, to point the
relative file path from $(srctree).
If we replace __FILE__ with KBUILD_FILE, we can rip off the path
to the build directory.
I am adding stringify helper because '"..."' wrapping is the same
pattern for KBUILD_BASENAME, KBUILD_MODNAME, and KBUILD_FILE.
Please note KBUILD_FILE is still an absolute path for external
modules. We can strip KBUILD_EXTMOD from the path if we want,
but I am not doing that. It would make it difficult to figure out
the module in question in case of WARN_ON().
Signed-off-by: Masahiro Yamada
---
scripts/Kbuild.include | 4
scripts/Makefile.lib | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 61f87a9..7fc3841 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -31,6 +31,10 @@ baseprereq = $(basename $(notdir $<))
escsq = $(subst $(squote),'\$(squote)',$1)
###
+# Quote a string to pass it to C files. foo => '"foo"'
+stringify = $(squote)$(quote)$1$(quote)$(squote)
+
+###
# Easy method for doing a status message
kecho := :
quiet_kecho := echo
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9e70196..f8dce56 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -96,10 +96,11 @@ obj-dirs:= $(addprefix $(obj)/,$(obj-dirs))
# Note: Files that end up in two or more modules are compiled without the
# KBUILD_MODNAME definition. The reason is that any made-up name would
# differ in different configs.
-name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst
-,_,$1))$(quote)$(squote)
+name-fix = $(call stringify,$(subst $(comma),_,$(subst -,_,$1)))
basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget))
modname_flags = $(if $(filter 1,$(words $(modname))),\
-DKBUILD_MODNAME=$(call name-fix,$(modname)))
+filepath_flags = -DKBUILD_FILE=$(call stringify,$(src)/$(notdir $<))
orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \
$(ccflags-y) $(CFLAGS_$(basetarget).o)
@@ -163,7 +164,7 @@ endif
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
$(__c_flags) $(modkern_cflags) \
-$(basename_flags) $(modname_flags)
+$(basename_flags) $(modname_flags) $(filepath_flags)
a_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
$(__a_flags) $(modkern_aflags)
--
2.7.4
[RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__
Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed with $(srctree)/ for out-of-tree build. It would be nice to see the same log regardless in-tree, or out-of-tree build. 1/2 adds a new macro KBUILD_FILE. This points the relative path of the file we are building. This is intended to replace __FILE__. 2/2 replaces __FILE__ in bug.h as an example. This will improve the output of WARN_ON() etc. Masahiro Yamada (2): kbuild: add KBUILD_FILE to point relative file path from $(srctree) bug.h: replace __FILE__ with KBUILD_FILE for shorter names in log arch/alpha/include/asm/bug.h | 2 +- arch/arc/include/asm/bug.h| 2 +- arch/arm/include/asm/bug.h| 4 ++-- arch/arm64/include/asm/bug.h | 2 +- arch/avr32/include/asm/bug.h | 2 +- arch/blackfin/include/asm/bug.h | 2 +- arch/cris/include/arch-v10/arch/bug.h | 6 +++--- arch/cris/include/arch-v32/arch/bug.h | 2 +- arch/frv/include/asm/bug.h| 2 +- arch/ia64/include/asm/bug.h | 2 +- arch/m68k/include/asm/bug.h | 4 ++-- arch/mn10300/include/asm/bug.h| 2 +- arch/parisc/include/asm/bug.h | 4 ++-- arch/powerpc/include/asm/bug.h| 8 arch/s390/include/asm/bug.h | 2 +- arch/score/include/asm/bug.h | 4 ++-- arch/sh/include/asm/bug.h | 8 arch/sparc/include/asm/bug.h | 2 +- arch/x86/include/asm/bug.h| 2 +- include/asm-generic/bug.h | 8 scripts/Kbuild.include| 4 scripts/Makefile.lib | 5 +++-- 22 files changed, 42 insertions(+), 37 deletions(-) -- 2.7.4
Re: [PATCH] sched/deadline: fix switching to -deadline
On Fri, 21 Apr 2017 11:26:59 +0100
Juri Lelli wrote:
> On 21/04/17 11:59, Luca Abeni wrote:
> > On Fri, 21 Apr 2017 10:47:29 +0100
> > Juri Lelli wrote:
> > [...]
> > > > > > *dl_se, update_dl_entity(dl_se, pi_se);
> > > > > > else if (flags & ENQUEUE_REPLENISH)
> > > > > > replenish_dl_entity(dl_se, pi_se);
> > > > > > + else if ((flags & ENQUEUE_RESTORE) &&
> > > > >
> > > > > Not sure I understand how this works. AFAICT we are doing
> > > > > __sched_setscheduler() when we want to catch the case of a new
> > > > > dl_entity (SCHED_{OTHER,FIFO} -> SCHED_DEADLINE}, but
> > > > > queue_flags (which are passed to enqueue_task()) don't seem
> > > > > to have ENQUEUE_RESTORE set?
> > > >
> > > > I was under the impression sched_setscheduler() sets
> > > > ENQUEUE_RESTORE...
> > >
> > > Oh, I think it works "by coincidence", as ENQUEUE_RESTORE ==
> > > DEQUEUE_SAVE == 0x02 ? :)
> >
> > Not sure if this is a conincidence... By looking at the comments in
> > sched/sched.h I got the impression the two values match by design
> > (and __sched_setscheduler() is using this property to simplify the
> > code :)
>
> Yep, right.
>
> Do you think we might get into trouble with do_set_cpus_allowed()?
> Can it happen that we change a task affinity while its deadline is in
> the past?
Well, double thinking about it, this is an interesting problem... What
do we want to do with do_set_cpus_allowed()? (I mean: what is the
expected behaviour?)
With this patch, if a task is moved to a different runqueue when its
deadline is in the past (because we are doing gEDF, or because of timer
granularity issues) its scheduling deadline is reinitialized to current
time + relative deadline... I think this makes perfect sense, doesn't
it?
Luca
[PATCH] hwmon: (adt7475) set start bit in probe
The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any
monitoring activities the STRT bit needs to be set. Logically this needs
to happen before any of the sensors are read so the probe() function
seems the best place for it.
[1] - https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF
Signed-off-by: Chris Packham
---
drivers/hwmon/adt7475.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index fcfa48222145..c803e3c5fcd4 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -59,6 +59,8 @@
#define REG_VENDID 0x3E
#define REG_DEVID2 0x3F
+#define REG_CONFIG10x40
+
#define REG_STATUS10x41
#define REG_STATUS20x42
@@ -1371,6 +1373,17 @@ static int adt7475_probe(struct i2c_client *client,
for (i = 0; i < ADT7475_PWM_COUNT; i++)
adt7475_read_pwm(client, i);
+ /* Start monitoring */
+ switch (chip) {
+ case adt7475:
+ case adt7476:
+ i2c_smbus_write_byte_data(client, REG_CONFIG1,
+ adt7475_read(REG_CONFIG1) | 0x01);
+ break;
+ default:
+ break;
+ }
+
ret = sysfs_create_group(&client->dev.kobj, &adt7475_attr_group);
if (ret)
return ret;
--
2.11.0.24.ge6920cf
[PATCH v5 3/6] mtd: dataflash: Replace pr_debug, printk with dev_* functions
Lion's share of calls to pr_debug in this driver follow the pattern of
pr_debug("%s ", dev_name(), ), which should
be semantically identical to dev_dbg(, "", ),
so replace such occurencies to simplify the code.
Convert the small minority of pr_debug that do not follow pattern from
above to use dev_dbg as well, for the sake of consistency.
Convert similar patter of printk(KERN_ERR, "%s: ...", dev_name(...),
...) to use dev_err instead.
No functional change intended.
Cc: cphe...@gmail.com
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: Cyrille Pitchen
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Marek Vasut
Signed-off-by: Andrey Smirnov
---
No changes since [v4]
Changes between since [v3]:
- Collected Reviewd-by from Marek
Not present in v2, v1
[v3] https://patchwork.ozlabs.org/patch/752332/
[v4] http://lkml.kernel.org/r/20170420162952.5181-3-andrew.smir...@gmail.com
drivers/mtd/devices/mtd_dataflash.c | 74 +
1 file changed, 33 insertions(+), 41 deletions(-)
diff --git a/drivers/mtd/devices/mtd_dataflash.c
b/drivers/mtd/devices/mtd_dataflash.c
index 5b7a8c3..ccd1e02 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -130,8 +130,7 @@ static int dataflash_waitready(struct spi_device *spi)
for (;;) {
status = dataflash_status(spi);
if (status < 0) {
- pr_debug("%s: status %d?\n",
- dev_name(&spi->dev), status);
+ dev_dbg(&spi->dev, "status %d?\n", status);
status = 0;
}
@@ -157,9 +156,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct
erase_info *instr)
u8 *command;
u32 rem;
- pr_debug("%s: erase addr=0x%llx len 0x%llx\n",
- dev_name(&spi->dev), (long long)instr->addr,
- (long long)instr->len);
+ dev_dbg(&spi->dev, "erase addr=0x%llx len 0x%llx\n",
+ (long long)instr->addr, (long long)instr->len);
div_u64_rem(instr->len, priv->page_size, &rem);
if (rem)
@@ -192,7 +190,7 @@ static int dataflash_erase(struct mtd_info *mtd, struct
erase_info *instr)
command[2] = (u8)(pageaddr >> 8);
command[3] = 0;
- pr_debug("ERASE %s: (%x) %x %x %x [%i]\n",
+ dev_dbg(&spi->dev, "ERASE %s: (%x) %x %x %x [%i]\n",
do_block ? "block" : "page",
command[0], command[1], command[2], command[3],
pageaddr);
@@ -201,8 +199,8 @@ static int dataflash_erase(struct mtd_info *mtd, struct
erase_info *instr)
(void) dataflash_waitready(spi);
if (status < 0) {
- printk(KERN_ERR "%s: erase %x, err %d\n",
- dev_name(&spi->dev), pageaddr, status);
+ dev_err(&spi->dev, "erase %x, err %d\n",
+ pageaddr, status);
/* REVISIT: can retry instr->retries times; or
* giveup and instr->fail_addr = instr->addr;
*/
@@ -243,8 +241,8 @@ static int dataflash_read(struct mtd_info *mtd, loff_t
from, size_t len,
u8 *command;
int status;
- pr_debug("%s: read 0x%x..0x%x\n", dev_name(&priv->spi->dev),
- (unsigned)from, (unsigned)(from + len));
+ dev_dbg(&priv->spi->dev, "read 0x%x..0x%x\n",
+ (unsigned int)from, (unsigned int)(from + len));
/* Calculate flash page/byte address */
addr = (((unsigned)from / priv->page_size) << priv->page_offset)
@@ -252,7 +250,7 @@ static int dataflash_read(struct mtd_info *mtd, loff_t
from, size_t len,
command = priv->command;
- pr_debug("READ: (%x) %x %x %x\n",
+ dev_dbg(&priv->spi->dev, "READ: (%x) %x %x %x\n",
command[0], command[1], command[2], command[3]);
spi_message_init(&msg);
@@ -284,8 +282,7 @@ static int dataflash_read(struct mtd_info *mtd, loff_t
from, size_t len,
*retlen = msg.actual_length - 8;
status = 0;
} else
- pr_debug("%s: read %x..%x --> %d\n",
- dev_name(&priv->spi->dev),
+ dev_dbg(&priv->spi->dev, "read %x..%x --> %d\n",
(unsigned)from, (unsigned)(from + len),
status);
return status;
@@ -311,8 +308,8 @@ static int dataflash_write(struct mtd_info *mtd, loff_t to,
size_t len,
int status = -EINVAL;
u8 *command;
- pr_debug("%s: write 0x%x..0x%x\n",
- dev_name(&spi->dev), (unsigned)to, (unsigned)(to + len));
+ dev_dbg(&
Re: [v6 PATCH 11/21] insn/eval: Incorporate segment base in address computation
On Tue, Mar 07, 2017 at 04:32:44PM -0800, Ricardo Neri wrote: > insn_get_addr_ref returns the effective address as defined by the Please end function names with parentheses. > section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software > Developer's Manual. In order to compute the linear address, we must add > to the effective address the segment base address as set in the segment > descriptor. Furthermore, the segment descriptor to use depends on the > register that is used as the base of the effective address. The effective > base address varies depending on whether the operand is a register or a > memory address and on whether a SiB byte is used. > > In most cases, the segment base address will be 0 if the USER_DS/USER32_DS > segment is used or if segmentation is not used. However, the base address > is not necessarily zero if a user programs defines its own segments. This > is possible by using a local descriptor table. > > Since the effective address is a signed quantity, the unsigned segment > base address saved in a separate variable and added to the final effective ".. is saved..." > address. > -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
[PATCH v5 6/6] mtd: dataflash: Add flash_info for AT45DB641E
Cc: cphe...@gmail.com
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: Cyrille Pitchen
Cc: linux-kernel@vger.kernel.org
Acked-by: Marek Vasut
Signed-off-by: Andrey Smirnov
---
Changes since [v4]:
- Collected Acked-by from Marek
Changes since [v3]:
- Update the patch ot use SUP_EXTID
No changes between v3 to v1.
[v3] http://lkml.kernel.org/r/20170419152305.17226-6-andrew.smir...@gmail.com
[v4] http://lkml.kernel.org/r/20170420162952.5181-6-andrew.smir...@gmail.com
drivers/mtd/devices/mtd_dataflash.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/devices/mtd_dataflash.c
b/drivers/mtd/devices/mtd_dataflash.c
index 3f1a0fb..5dc8bd0 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -736,6 +736,9 @@ static struct flash_info dataflash_data[] = {
{ "AT45DB642x", 0x1f2800, 8192, 1056, 11, SUP_POW2PS},
{ "at45db642d", 0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
+
+ { "AT45DB641E", 0x1f28000100, 32768, 264, 9, SUP_EXTID | SUP_POW2PS},
+ { "at45db641e", 0x1f28000100, 32768, 256, 8, SUP_EXTID | SUP_POW2PS |
IS_POW2PS},
};
static struct flash_info *jedec_lookup(struct spi_device *spi,
--
2.9.3
[PATCH v1 3/8] HID: intel_ish-hid: Use recently introduced uuid_le_cmp_p{p}()
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Srinivas Pandruvada
Cc: Benjamin Tissoires
Signed-off-by: Andy Shevchenko
---
drivers/hid/intel-ish-hid/ishtp/bus.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 5f382fedc2ab..165e21b7ee9f 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -138,8 +138,7 @@ int ishtp_fw_cl_by_uuid(struct ishtp_device *dev, const
uuid_le *uuid)
int i, res = -ENOENT;
for (i = 0; i < dev->fw_clients_num; ++i) {
- if (uuid_le_cmp(*uuid, dev->fw_clients[i].props.protocol_name)
- == 0) {
+ if (!uuid_le_cmp_p(uuid,
dev->fw_clients[i].props.protocol_name)) {
res = i;
break;
}
--
2.11.0
Re: [PATCH -mm] mm, swap: Fix swap space leak in error path of swap_free_entries()
On Fri, 2017-04-21 at 20:47 +0800, Huang, Ying wrote: > From: Huang Ying > > In swapcache_free_entries(), if swap_info_get_cont() return NULL, > something wrong occurs for the swap entry. But we should still > continue to free the following swap entries in the array instead of > skip them to avoid swap space leak. This is just problem in error > path, where system may be in an inconsistent state, but it is still > good to fix it. > Acked-by: Tim Chen > Signed-off-by: "Huang, Ying" > Cc: Tim Chen > Cc: Rik van Riel > Cc: Hugh Dickins > Cc: Shaohua Li > Cc: Minchan Kim > ---
Re: mtip32xx: add a status field to struct mtip_cmd
On 04/21/2017 08:37 AM, Christoph Hellwig wrote:
> On Fri, Apr 21, 2017 at 08:14:03AM -0600, Jens Axboe wrote:
>> From: Jens Axboe
>> Subject: [PATCH] mtip32xx: fix dereference of stack garbage
>>
>> We need to get the command payload from the request before
>> we attempt to dereference it.
>>
>> Fixes: 4dda4735c581 ("mtip32xx: add a status field to struct mtip_cmd")
>> Signed-off-by: Jens Axboe
>
> Looks fine:
>
> Reviewed-by: Christoph Hellwig
Pushed, thanks.
--
Jens Axboe
Re: Unchecked flags in statx(2) [Should be fixed before 4.11-final?]
Hello Andreas, On 04/21/2017 08:16 PM, Andreas Dilger wrote: > On Apr 21, 2017, at 7:13 AM, Michael Kerrisk (man-pages) > wrote: >> >> On 04/21/2017 03:01 PM, David Howells wrote: >>> Michael Kerrisk (man-pages) wrote: >> >>> (3) There's no problem with asking for extra bits, even if the running >>> kerneldoes not support them, because the kernel tells you in its >>> response what fields it actually gave you. >> >> It's this piece that I overlooked. Makes sense, of course. >> Sorry for the noise! > > I agree with David that we don't want to return an error if the application > asks for more bits than the kernel supports, otherwise the interface would > be useless. Yes, it's clear to me now. > Maybe this implies that this needs to be explained more clearly in the > statx man page? Precisely; my thought also. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: IB/mlx: Fine-tuning for several function implementations
> Patches should either be useful to users of the Linux kernel, e.g. by adding > new functionality or by fixing a bug, or to kernel developers, e.g. by making > their workflow easier. Such an expectation is generally fine. > I don't think this patch series falls in either category I find that my update suggestion touches some aspects for the desired source code quality, doesn't it? > so please drop these patches. I hope that corresponding software improvements will be clarified further. Regards, Markus
[PATCH] streamline TLV320AIC23 drivers
The iMX-TLV320AIC23 driver isn't from Freescale, but from a company named
Eukrea Electromatique, originally for their own boards. From the code I get
the impression it is a bit older, its DT options use a differing naming
scheme. Patch it up a bit:
- Remove Eukrea naming, i.MX is from Freescale, TLV320AIC23 is from TI,
driver was written by Eukrea, but it's DT capable, so it's not exclusive:
- Kconfig option title
- 'model' option
- driver 'compatible' string
- Other options just have changed over time, this driver remaining (one of)
the last with the old semantics:
- 'audio-codec' option (also moved from ssi node)
- 'mux-int/ext-port' options
- All options stay backwards compatible, the DT binding documents new and
old names.
CONFIG variable and files have not been renamed, though, so no need to
change old defconfigs.
Signed-off-by: Jens Rottmann
---
--- a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
+++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
@@ -1,16 +1,23 @@
-Audio complex for Eukrea boards with tlv320aic23 codec.
+Audio complex for Freescale i.MX boards with TI TLV320AIC23 I2S codecs,
+like those from Eukrea Electromatique.
Required properties:
- - compatible : "eukrea,asoc-tlv320"
+ - compatible : "fsl,imx-audio-tlv320aic23" or
+ "eukrea,asoc-tlv320" (deprecated)
- - eukrea,model : The user-visible name of this sound complex.
+ - model : The user-visible name of this sound complex.
+ - eukrea,model : Dito, deprecated.
- ssi-controller : The phandle of the SSI controller.
- - fsl,mux-int-port : The internal port of the i.MX audio muxer (AUDMUX).
+ - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX).
+ - fsl,mux-int-port : Dito, deprecated.
- - fsl,mux-ext-port : The external port of the i.MX audio muxer.
+ - mux-ext-port : The external port of the i.MX audio muxer.
+ - fsl,mux-ext-port : Dito, deprecated.
+
+ - audio-codec: The phandle of the audio codec.
Note: The AUDMUX port numbering should start at 1, which is consistent with
hardware manual.
@@ -18,9 +25,10 @@ hardware manual.
Example:
sound {
- compatible = "eukrea,asoc-tlv320";
- eukrea,model = "imx51-eukrea-tlv320aic23";
+ compatible = "fsl,imx-audio-tlv320aic23";
+ model = "imx51-eukrea-tlv320aic23";
ssi-controller = <&ssi2>;
- fsl,mux-int-port = <2>;
- fsl,mux-ext-port = <3>;
+ mux-int-port = <2>;
+ mux-ext-port = <3>;
+ audio-codec = <&codec>;
};
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -220,7 +220,7 @@ config SND_SOC_PHYCORE_AC97
and phyCARD boards in AC97 mode
config SND_SOC_EUKREA_TLV320
- tristate "Eukrea TLV320"
+ tristate "SoC Audio support for i.MX boards with TLV320AIC23"
depends on ARCH_MXC && I2C
select SND_SOC_TLV320AIC23_I2C
select SND_SOC_IMX_AUDMUX
--- a/sound/soc/fsl/eukrea-tlv320.c
+++ b/sound/soc/fsl/eukrea-tlv320.c
@@ -92,11 +92,13 @@ static int eukrea_tlv320_probe(struct platform_device *pdev)
eukrea_tlv320.dev = &pdev->dev;
if (np) {
- ret = snd_soc_of_parse_card_name(&eukrea_tlv320,
-"eukrea,model");
+ ret = snd_soc_of_parse_card_name(&eukrea_tlv320, "model");
+ if (ret) /* backwards compatible */
+ ret = snd_soc_of_parse_card_name(&eukrea_tlv320,
+"eukrea,model");
if (ret) {
dev_err(&pdev->dev,
- "eukrea,model node missing or invalid.\n");
+ "model node missing or invalid.\n");
goto err;
}
@@ -109,22 +111,28 @@ static int eukrea_tlv320_probe(struct platform_device
*pdev)
goto err;
}
- codec_np = of_parse_phandle(ssi_np, "codec-handle", 0);
+ codec_np = of_parse_phandle(pdev->dev.of_node, "audio-codec",
0);
+ if (!codec_np) /* backwards compatible */
+ codec_np = of_parse_phandle(ssi_np, "codec-handle", 0);
if (codec_np)
eukrea_tlv320_dai.codec_of_node = codec_np;
else
- dev_err(&pdev->dev, "codec-handle node missing or
invalid.\n");
+ dev_err(&pdev->dev, "audio-codec node missing or
invalid.\n");
- ret = of_property_read_u32(np, "fsl,mux-int-port", &int_port);
+ ret = of_property_read_u32(np, "mux-int-port", &int_port);
+ if (ret) /* backwards compatible */
+ ret = of_property_read_u32(np, "fsl,mux-i
Re: [PATCH] pinctrl-armada-xp: Use devm_kmalloc_array() in armada_xp_pinctrl_probe()
Hi Markus, On 15/04/17 05:04, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 14 Apr 2017 18:48:15 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding function "devm_kmalloc_array". > > This issue was detected by using the Coccinelle software. > > * Replace the specification of a data type by a pointer dereference > to make the corresponding size determination a bit safer according to > the Linux coding style convention. > > * Delete the local variable "nregs" which became unnecessary with > this refactoring. > > Signed-off-by: Markus Elfring > --- > drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c > b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c > index b854f1ee5de5..457c54c8fed3 100644 > --- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c > +++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c > @@ -574,7 +574,6 @@ static int armada_xp_pinctrl_probe(struct platform_device > *pdev) > struct mvebu_pinctrl_soc_info *soc = &armada_xp_pinctrl_info; > const struct of_device_id *match = > of_match_device(armada_xp_pinctrl_of_match, &pdev->dev); > - int nregs; > > if (!match) > return -ENODEV; > @@ -628,10 +627,11 @@ static int armada_xp_pinctrl_probe(struct > platform_device *pdev) > break; > } > > - nregs = DIV_ROUND_UP(soc->nmodes, MVEBU_MPPS_PER_REG); > - > - mpp_saved_regs = devm_kmalloc(&pdev->dev, nregs * sizeof(u32), > - GFP_KERNEL); > + mpp_saved_regs = devm_kmalloc_array(&pdev->dev, > + DIV_ROUND_UP(soc->nmodes, > + MVEBU_MPPS_PER_REG), > + sizeof(*mpp_saved_regs), > + GFP_KERNEL); I personally think having nregs makes the code a bit more readable but that's just me. With or without a change Reviewed-by: Chris Packham > if (!mpp_saved_regs) > return -ENOMEM; > >
Re: [PATCH 0/5] v2: block subsystem refcounter conversions
On Fri, Apr 21, 2017 at 3:55 AM, Reshetova, Elena wrote: > On Thu, Apr 20, 2017 at 11:33 AM, Eric Biggers wrote: >> Of course, having extra checks behind a debug option is fine. But they >> should >> not be part of the base feature; the base feature should just be mitigation >> of >> reference count *overflows*. It would be nice to do more, of course; but >> when >> the extra stuff prevents people from using refcount_t for performance >> reasons, >> it defeats the point of the feature in the first place. > > Sure, but as I said above, I think the smaller tricks and fixes won't be > convincing enough, > so their value is questionable. > >> I strongly encourage anyone who has been involved in refcount_t to experiment >> with removing a reference count decrement somewhere in their kernel, then >> trying >> to exploit it to gain code execution. If you don't know what you're trying >> to >> protect against, you will not know which defences work and which don't. > > Well, we had successful CVEs and even exploits on this in the past. > @Kees, do you store a list of them in the project? Here are two from last year: http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ http://cyseclabs.com/page?n=02012016 I don't disagree with Eric on the threat model: the primary concern for reference count protection is the overflow condition. Detecting a prior use-after-free is certainly nice to have, but the more important case is the initial overflow. How about we introduce something like CONFIG_HAVE_ARCH_FAST_REFCOUNT_T for per-arch implementations and CONFIG_FAST_REFCOUNT_T that trades coverage for speed, and checks only the overflow condition. This gets us the critical coverage without the changes in performance. This is basically what PaX/grsecurity already did: there is a tiny change to the atomic inc functions to detect the wrap. -Kees -- Kees Cook Pixel Security
Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging
Hi Laura, Thanks much for this series! On 18 April 2017 at 23:57, Laura Abbott wrote: > Hi, > > This is v4 of the series to cleanup to Ion. Greg took some of the patches > that weren't CMA related already. There was a minor bisectability problem > with the CMA APIs so this is a new version to address that. I also > addressed some minor comments on the patch to collapse header files. For the series, please feel free to apply my Acked-by: Sumit Semwal > > Thanks, > Laura > > Laura Abbott (12): > cma: Store a name in the cma structure > cma: Introduce cma_for_each_area > staging: android: ion: Use CMA APIs directly > staging: android: ion: Stop butchering the DMA address > staging: android: ion: Break the ABI in the name of forward progress > staging: android: ion: Get rid of ion_phys_addr_t > staging: android: ion: Collapse internal header files > staging: android: ion: Rework heap registration/enumeration > staging: android: ion: Drop ion_map_kernel interface > staging: android: ion: Remove ion_handle and ion_client > staging: android: ion: Set query return value > staging/android: Update Ion TODO list > > arch/powerpc/kvm/book3s_hv_builtin.c| 3 +- > drivers/base/dma-contiguous.c | 5 +- > drivers/staging/android/TODO| 21 +- > drivers/staging/android/ion/Kconfig | 32 + > drivers/staging/android/ion/Makefile| 11 +- > drivers/staging/android/ion/compat_ion.c| 152 - > drivers/staging/android/ion/compat_ion.h| 29 - > drivers/staging/android/ion/ion-ioctl.c | 55 +- > drivers/staging/android/ion/ion.c | 812 > ++-- > drivers/staging/android/ion/ion.h | 386 --- > drivers/staging/android/ion/ion_carveout_heap.c | 21 +- > drivers/staging/android/ion/ion_chunk_heap.c| 16 +- > drivers/staging/android/ion/ion_cma_heap.c | 120 ++-- > drivers/staging/android/ion/ion_heap.c | 68 -- > drivers/staging/android/ion/ion_page_pool.c | 3 +- > drivers/staging/android/ion/ion_priv.h | 453 - > drivers/staging/android/ion/ion_system_heap.c | 39 +- > drivers/staging/android/uapi/ion.h | 36 +- > include/linux/cma.h | 6 +- > mm/cma.c| 31 +- > mm/cma.h| 1 + > mm/cma_debug.c | 2 +- > 22 files changed, 524 insertions(+), 1778 deletions(-) > delete mode 100644 drivers/staging/android/ion/compat_ion.c > delete mode 100644 drivers/staging/android/ion/compat_ion.h > delete mode 100644 drivers/staging/android/ion/ion_priv.h > > -- > 2.7.4 > -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2] net: arc_emac: switch to phy_start()/phy_stop()
From: Alexander Kochetkov Date: Thu, 20 Apr 2017 16:29:34 +0300 > Currently driver use phy_start_aneg() in arc_emac_open() to bring > up PHY. But phy_start() function is more appropriate for this purposes. > Besides that it call phy_start_aneg() as part of PHY startup sequence > it also can correctly bring up PHY from error and suspended states. > So the patch replace phy_start_aneg() to phy_start(). > > Also the patch add call to phy_stop() to arc_emac_stop() to allow > the PHY device to be fully suspended when the interface is unused. > > Signed-off-by: Alexander Kochetkov Applied to net-next, thanks.
Re: [PATCH] gpio: export add/remove lookup table functions
On Fri, Apr 21, 2017 at 12:23 AM, Anatolij Gustschin wrote:
> For hot-pluggable devices adding GPIOs dynamically we need to
> assemble and add the gpio lookup tables at probe time in modules,
> so that requesting these GPIOs in attached drivers can work.
> Export lookup table functions for modules.
>
> Signed-off-by: Anatolij Gustschin
...and still a question "Do we go with stubs for them in case of !GPIOLIB?"
Patch below looks good to me:
Reviewed-by: Andy Shevchenko
> ---
> drivers/gpio/gpiolib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 4aa1e78..9196b1e 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -3008,6 +3008,7 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table
> *table)
>
> mutex_unlock(&gpio_lookup_lock);
> }
> +EXPORT_SYMBOL_GPL(gpiod_add_lookup_table);
>
> /**
> * gpiod_remove_lookup_table() - unregister GPIO device consumers
> @@ -3021,6 +3022,7 @@ void gpiod_remove_lookup_table(struct
> gpiod_lookup_table *table)
>
> mutex_unlock(&gpio_lookup_lock);
> }
> +EXPORT_SYMBOL_GPL(gpiod_remove_lookup_table);
>
> static struct gpiod_lookup_table *gpiod_find_lookup_table(struct device *dev)
> {
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
[PATCH] usb: dwc2: Remove unnecessary uphy and clk checkings
hsotg->uphy and hsotg->clk will be set or NULL, but not ERRPTR.
So IS_ERR_OR_NULL() is not required at all.
NULL pointer argument is OK for "usb_phy_set_suspend", "otg_set_host",
"otg_set_peripheral", "clk_prepare_enable" and "clk_disable_unprepare"
functions. So remove unnecessary checkings.
Signed-off-by: Sevak Arakelyan
---
drivers/usb/dwc2/core_intr.c | 3 +--
drivers/usb/dwc2/gadget.c| 8 +++-
drivers/usb/dwc2/hcd.c | 22 --
drivers/usb/dwc2/platform.c | 11 ---
4 files changed, 16 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index b8bcb007c92a..b59bc58a5bfb 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -451,8 +451,7 @@ static void dwc2_handle_usb_suspend_intr(struct dwc2_hsotg
*hsotg)
udelay(100);
/* Ask phy to be suspended */
- if (!IS_ERR_OR_NULL(hsotg->uphy))
- usb_phy_set_suspend(hsotg->uphy, true);
+ usb_phy_set_suspend(hsotg->uphy, true);
skip_power_saving:
/*
* Change to L2 (suspend) state before releasing
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 98a4a79e7f6e..634f9613bb56 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -4259,8 +4259,7 @@ static int dwc2_hsotg_udc_start(struct usb_gadget *gadget,
goto err;
}
- if (!IS_ERR_OR_NULL(hsotg->uphy))
- otg_set_peripheral(hsotg->uphy->otg, &hsotg->gadget);
+ otg_set_peripheral(hsotg->uphy->otg, &hsotg->gadget);
spin_lock_irqsave(&hsotg->lock, flags);
if (dwc2_hw_is_device(hsotg)) {
@@ -4312,8 +4311,7 @@ static int dwc2_hsotg_udc_stop(struct usb_gadget *gadget)
spin_unlock_irqrestore(&hsotg->lock, flags);
- if (!IS_ERR_OR_NULL(hsotg->uphy))
- otg_set_peripheral(hsotg->uphy->otg, NULL);
+ otg_set_peripheral(hsotg->uphy->otg, NULL);
if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL)
dwc2_lowlevel_hw_disable(hsotg);
@@ -4411,7 +4409,7 @@ static int dwc2_hsotg_vbus_draw(struct usb_gadget
*gadget, unsigned int mA)
{
struct dwc2_hsotg *hsotg = to_hsotg(gadget);
- if (IS_ERR_OR_NULL(hsotg->uphy))
+ if (hsotg->uphy)
return -ENOTSUPP;
return usb_phy_set_power(hsotg->uphy, mA);
}
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index f4ef159b538e..940d18dfde3e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4421,11 +4421,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
}
/* Ask phy to be suspended */
- if (!IS_ERR_OR_NULL(hsotg->uphy)) {
- spin_unlock_irqrestore(&hsotg->lock, flags);
- usb_phy_set_suspend(hsotg->uphy, true);
- spin_lock_irqsave(&hsotg->lock, flags);
- }
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+ usb_phy_set_suspend(hsotg->uphy, true);
+ spin_lock_irqsave(&hsotg->lock, flags);
/* After entering hibernation, hardware is no more accessible */
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
@@ -4465,11 +4463,9 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
* This must not be spinlocked since duration
* of this call is unknown.
*/
- if (!IS_ERR_OR_NULL(hsotg->uphy)) {
- spin_unlock_irqrestore(&hsotg->lock, flags);
- usb_phy_set_suspend(hsotg->uphy, false);
- spin_lock_irqsave(&hsotg->lock, flags);
- }
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+ usb_phy_set_suspend(hsotg->uphy, false);
+ spin_lock_irqsave(&hsotg->lock, flags);
/* Exit hibernation */
ret = dwc2_exit_hibernation(hsotg, true);
@@ -5249,8 +5245,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
/* Don't support SG list at this point */
hcd->self.sg_tablesize = 0;
- if (!IS_ERR_OR_NULL(hsotg->uphy))
- otg_set_host(hsotg->uphy->otg, &hcd->self);
+ otg_set_host(hsotg->uphy->otg, &hcd->self);
/*
* Finish generic HCD initialization and start the HCD. This function
@@ -5306,8 +5301,7 @@ void dwc2_hcd_remove(struct dwc2_hsotg *hsotg)
return;
}
- if (!IS_ERR_OR_NULL(hsotg->uphy))
- otg_set_host(hsotg->uphy->otg, NULL);
+ otg_set_host(hsotg->uphy->otg, NULL);
usb_remove_hcd(hcd);
hsotg->priv = NULL;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index db9846396244..7e6fb116bcb2 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -130,11 +130,9 @@ static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg
*hsotg)
if (ret)
return ret;
- if (hsotg->clk) {
-
Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave
On 04/21/2017 10:45 AM, Andrew Cooper wrote:
> On 21/04/17 15:38, Juergen Gross wrote:
>> On 21/04/17 16:24, Boris Ostrovsky wrote:
+static bool __init xen_check_xsave(void)
{
- unsigned int ax, bx, cx, dx;
- unsigned int xsave_mask;
+ unsigned int err, eax, edx;
- ax = 1;
- cx = 0;
- cpuid(1, &ax, &bx, &cx, &dx);
+ /* Test OSXSAVE capability via xgetbv instruction. */
+ asm volatile("1: .byte 0x0f,0x01,0xd0\n\t" /* xgetbv */
+ "xor %[err], %[err]\n"
+ "2:\n\t"
+ ".pushsection .fixup,\"ax\"\n\t"
+ "3: movl $1,%[err]\n\t"
+ "jmp 2b\n\t"
+ ".popsection\n\t"
+ _ASM_EXTABLE(1b, 3b)
+ : [err] "=r" (err), "=a" (eax), "=d" (edx)
+ : "c" (0));
>>> Have you tested this on processors where we actually trap on xgetbv?
>>>
>>> I have an AMD box without XSAVE support and this is a fatal error. I
>>> suspect it's too early to use exception fixup framework here.
>> Uuh, too bad.
>>
>> Then I fear we must use the other solution Andrew didn't like. :-(
>> Andrew, would you be okay with that?
> Hmm fine. The status quo is probably best then to unblock this series.
>
> As an independent question, why are exceptions set up so late? They
> really should be the very first thing done
It's exception fixup that is not set up yet --- we are executing here
before "main" kernel's entry point.
This is somewhat similar to what
arch/x86/kernel/head_64.S:early_idt_handler_common() does --- it has
special handling for early fixup --- early_fixup_exception().
I wonder though --- can this feature masking be deferred until a bit later?
-boris
[PATCHv1 2/2] fpga-mgr: add streaming support
From: Yi Li
Add fpga_mgr_firmware_stream API to enable streaming/programing
FPGA bitstream file from file system to FPGA manager. This code is
on top of Luis R. Rodriguez's new driver_data_request_sync API.
Signed-off-by: Yi Li
---
drivers/fpga/fpga-mgr.c | 96 +++
include/linux/fpga/fpga-mgr.h | 4 ++
2 files changed, 100 insertions(+)
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 188ffef..975194c 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
static DEFINE_IDA(fpga_mgr_ida);
static struct class *fpga_mgr_class;
@@ -196,6 +198,100 @@ static int fpga_mgr_buf_load_mapped(struct fpga_manager
*mgr,
return fpga_mgr_write_complete(mgr, info);
}
+static int fpga_mgr_streaming_fw_cb(void *context, const struct firmware *fw)
+{
+ int ret = -EINVAL;
+ struct driver_data_req_params *params =
+ (struct driver_data_req_params *)context;
+ struct fpga_image_info *info = (struct fpga_image_info *)
+ params->streaming_reqs.opt_ctx1;
+ struct fpga_manager *mgr = (struct fpga_manager *)
+ params->streaming_reqs.opt_ctx2;
+ struct device *dev = &mgr->dev;
+
+ /*
+* init.
+*/
+ if (params->streaming_reqs.offset == 0) {
+ ret = fpga_mgr_write_init_buf(mgr, info, fw->data, fw->size);
+ if (ret)
+ return ret;
+ }
+
+ /*
+* Write the FPGA image to the FPGA.
+*/
+ mgr->state = FPGA_MGR_STATE_WRITE;
+ ret = mgr->mops->write(mgr, fw->data, fw->size);
+ if (ret) {
+ dev_err(dev, "Error while writing image data to FPGA\n");
+ mgr->state = FPGA_MGR_STATE_WRITE_ERR;
+ return ret;
+ }
+
+ params->streaming_reqs.offset += fw->size;
+ if (fw->size < SZ_4K)
+ ret = fpga_mgr_write_complete(mgr, info);
+
+ return ret;
+}
+
+/**
+ * fpga_mgr_firmware_stream - streaming firmware and load to fpga
+ * @mgr: fpga manager
+ * @info: fpga image specific information
+ * @image_name:name of image file on the firmware search path
+ *
+ * Streaming an FPGA image using the firmware class, then write out to the
FPGA.
+ * Update the state before each step to provide info on what step failed if
+ * there is a failure. This code assumes the caller got the mgr pointer
+ * from of_fpga_mgr_get() or fpga_mgr_get() and checked that it is not an error
+ * code.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int fpga_mgr_firmware_stream(struct fpga_manager *mgr,
+struct fpga_image_info *info,
+const char *image_name)
+{
+ int ret;
+ const struct firmware *fw = NULL;
+ char *path = NULL;
+ size_t length = INT_MAX;
+ struct device *dev = &mgr->dev;
+ const struct driver_data_req_params req_params = {
+ .streaming_reqs.streaming = true,
+ .streaming_reqs.offset = 0,
+ .streaming_reqs.driver_data = &fw,
+ .streaming_reqs.path = &path,
+ .streaming_reqs.buf_size = SZ_4K,
+ .streaming_reqs.opt_ctx1 = info,
+ .streaming_reqs.opt_ctx2 = mgr,
+ DRIVER_DATA_KEEP_SYNC(fpga_mgr_streaming_fw_cb,
+ &req_params),
+ };
+
+ mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ;
+ while (length > 0) {
+ ret = driver_data_request_sync(image_name, &req_params, dev);
+ if (ret) {
+ dev_err(dev, "Error reading firmware %d\n", ret);
+ mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ_ERR;
+ return ret;
+ }
+
+ length -= fw->size;
+ if (fw->size < SZ_4K)
+ break;
+ }
+
+ __putname(*req_params.streaming_reqs.path);
+ release_firmware(fw);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(fpga_mgr_firmware_stream);
+
/**
* fpga_mgr_buf_load - load fpga from image in buffer
* @mgr: fpga manager
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index e2ef94fd..97907f5 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -140,6 +140,10 @@ int fpga_mgr_firmware_load(struct fpga_manager *mgr,
struct fpga_image_info *info,
const char *image_name);
+int fpga_mgr_firmware_stream(struct fpga_manager *mgr,
+struct fpga_image_info *info,
+const char *image_name);
+
struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
struct fpga_manager *fpga_mgr_get(struct device *dev);
--
2.7.4
[PATCHv1 0/2] Add streaming support for base firmware and fpga-mgr
From: Yi Li As the FPGA hardware advances, the bitstream image size grows. It could be an issue for kernel to allocate big buffers to load the whole firmware file. Here is an attempt to load the bitstream file into 4KB buffer and program the FPGA in a streaming mode. The streaming support is added in the driver_data_request_sync API on Luis R. Rodriguez's v6 branch. https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170329-driver-data-v2-try3, which is sent to this list for review on March/29 [PATCH v6 0/5] firmware: add driver data API. It should not be a performance hit for FPGA programing since the majority of time spend is with the FPGA CvP/PR-IP interface. Yi Li (2): firmware: Add streaming support fpga-mgr: add streaming support drivers/base/firmware_class.c | 119 +- drivers/fpga/fpga-mgr.c | 96 ++ include/linux/driver_data.h | 13 + include/linux/fpga/fpga-mgr.h | 4 ++ 4 files changed, 231 insertions(+), 1 deletion(-) -- 2.7.4
[PATCHv1 1/2] firmware: Add streaming support
From: Yi Li
Load firmware in multiple chucks(4KB) instead of the whole big firmware file
at once. The streaming support is added in the driver_data_request_sync API
based on Luis R. Rodriguez's 20170329-driver-data-v2-try3 branch.
Signed-off-by: Yi Li
---
drivers/base/firmware_class.c | 119 +-
include/linux/driver_data.h | 13 +
2 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index cc3c224..beecbf5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -569,6 +569,73 @@ fw_get_filesystem_firmware(struct device *device, struct
firmware_buf *buf)
return rc;
}
+static int
+fw_stream_filesystem_firmware(struct device *device, struct firmware_buf *buf,
+ size_t offset, size_t length, char **path)
+{
+ int i, len;
+ int rc = 0;
+ struct file *file;
+
+ buf->size = 0;
+ if (!buf->data) {
+ buf->data = vmalloc(length);
+ if (!buf->data) {
+ rc = -ENOMEM;
+ return rc;
+ }
+ }
+
+ /* skip the repeating folder searching */
+ if (*path) {
+ file = filp_open(*path, O_RDONLY, 0);
+ if (IS_ERR(file)) {
+ rc = -ENOENT;
+ return rc;
+ }
+
+ buf->size = kernel_read(file, offset, (char *)buf->data,
+ length);
+ fput(file);
+ return rc;
+ }
+
+ dev_info(device, "search %s in the folder\n", buf->fw_id);
+ *path = __getname();
+ if (!*path)
+ return -ENOMEM;
+
+ for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+ /* skip the unset customized path */
+ if (!fw_path[i][0])
+ continue;
+
+ len = snprintf(*path, PATH_MAX, "%s/%s",
+ fw_path[i], buf->fw_id);
+ if (len >= PATH_MAX) {
+ rc = -ENAMETOOLONG;
+ break;
+ }
+
+ file = filp_open(*path, O_RDONLY, 0);
+ if (IS_ERR(file)) {
+ rc = -ENOENT;
+ continue;
+ }
+
+ buf->size = kernel_read(file, offset, (char *)buf->data,
+ length);
+ rc = 0;
+ fput(file);
+ break;
+ }
+
+ if (rc)
+ dev_err(device, "loading %s failed with error %d\n",
+ *path, rc);
+ return rc;
+}
+
/* firmware holds the ownership of pages */
static void firmware_free_data(const struct firmware *fw)
{
@@ -1310,6 +1377,46 @@ _request_firmware_prepare(struct firmware **firmware_p,
const char *name,
return 1; /* need to load */
}
+static int
+_stream_firmware(const struct firmware **firmware_p, const char *name,
+struct driver_data_params *data_params,
+struct device *device)
+{
+ int ret;
+ struct firmware *fw = NULL;
+ size_t offset = data_params->req_params.streaming_reqs.offset;
+ size_t buf_size = data_params->req_params.streaming_reqs.buf_size;
+
+ if ((!firmware_p) || (!name || name[0] == '\0')) {
+ dev_err(device, "invalid firmware pointer or file name\n");
+ return -EINVAL;
+ }
+
+ if (!*firmware_p) {
+ ret = _request_firmware_prepare(&fw, name, device, data_params);
+ if (ret <= 0) {
+ dev_err(device, "%s: failed %d\n",
+ __func__, ret);
+ }
+ } else {
+ fw = (struct firmware *)*firmware_p;
+ }
+
+ ret = fw_stream_filesystem_firmware(device, fw->priv, offset, buf_size,
+ data_params->req_params.streaming_reqs.path);
+ if (ret) {
+ if (!driver_data_param_optional(&data_params->req_params))
+ dev_warn(device,
+"streaming %s failed with error %d\n",
+name, ret);
+ } else {
+ ret = assign_firmware_buf(fw, device, data_params);
+ }
+ *firmware_p = fw;
+
+ return ret;
+}
+
/* called from request_firmware() and request_firmware_work_func() */
static int
_request_firmware(const struct firmware **firmware_p, const char *name,
@@ -1577,7 +1684,17 @@ int driver_data_request_sync(const char *name,
__module_get(sync_reqs->module);
get_device(device);
- ret = _request_firmware(&driver_data, name, ¶ms, device);
+ if (req_params->streaming_reqs.streaming) {
+ /* For streaming, driver_data is recycled and kept */
+ if (!req_params->keep)
+
Re: [patch V2 00/10] timer: Move from a push remote at enqueue to a pull at expiry model
On Tue, Apr 18, 2017 at 01:11:02PM +0200, Thomas Gleixner wrote:
> Placing timers at enqueue time on a target CPU based on dubious heuristics
> does not make any sense:
>
> 1) Most timer wheel timers are canceled or rearmed before they expire.
>
> 2) The heuristics to predict which CPU will be busy when the timer expires
> are wrong by definition.
>
> So we waste precious cycles to place timers at enqueue time.
>
> The proper solution to this problem is to always queue the timers on the
> local CPU and allow the non pinned timers to be pulled onto a busy CPU at
> expiry time.
>
> To achieve this the timer storage has been split into local pinned and
> global timers. Local pinned timers are always expired on the CPU on which
> they have been queued. Global timers can be expired on any CPU.
>
> As long as a CPU is busy it expires both local and global timers. When a
> CPU goes idle it arms for the first expiring local timer. If the first
> expiring pinned (local) timer is before the first expiring movable timer,
> then no action is required because the CPU will wake up before the first
> movable timer expires. If the first expiring movable timer is before the
> first expiring pinned (local) timer, then this timer is queued into a idle
> timerqueue and eventually expired by some other active CPU.
>
> To avoid global locking the timerqueues are implemented as a hierarchy. The
> lowest level of the hierarchy holds the CPUs. The CPUs are associated to
> groups of 8, which are seperated per node. If more than one CPU group
> exist, then a second level in the hierarchy collects the groups. Depending
> on the size of the system more than 2 levels are required. Each group has a
> "migrator" which checks the timerqueue during the tick for remote expirable
> timers.
>
> If the last CPU in a group goes idle it reports the first expiring event in
> the group up to the next group(s) in the hierarchy. If the last CPU goes
> idle it arms its timer for the first system wide expiring timer to ensure
> that no timer event is missed.
OK, after several attempts this week, I formally state that I officially
suck at reviewing, though I must confess that I am quite partial to use
of hierarchies to avoid scalability bottlenecks. I therefore applied
these patches and ran rcutorture on them. Two of 19 scenarios resulted
in failures, namely TREE04 and TREE07. I have posted their .config and
console.log files here:
http://www2.rdrop.com/users/paulmck/submission/TREE04.2017.04.21a.config
http://www2.rdrop.com/users/paulmck/submission/TREE04.2017.04.21a.console.log
http://www2.rdrop.com/users/paulmck/submission/TREE07.2017.04.21a.config
http://www2.rdrop.com/users/paulmck/submission/TREE07.2017.04.21a.console.log
The first splat from TREE04 is:
[3.513964] WARNING: CPU: 1 PID: 755 at
/home/paulmck/public_git/linux-rcu/kernel/time/timer_migration.c:387
tmigr_set_cpu_active+0xd7/0xf0
[3.517320] Modules linked in:
[3.518173] CPU: 1 PID: 755 Comm: rcu_torture_rea Not tainted 4.11.0-rc2+ #1
[3.520134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[3.522692] Call Trace:
[3.523354]
[3.523953] dump_stack+0x4d/0x65
[3.524846] __warn+0xc6/0xe0
[3.525680] warn_slowpath_null+0x18/0x20
[3.526787] tmigr_set_cpu_active+0xd7/0xf0
[3.527866] tmigr_cpu_activate+0x36/0x40
[3.528872] tick_nohz_stop_sched_tick+0x248/0x330
[3.530103] tick_nohz_irq_exit+0x109/0x140
[3.531214] irq_exit+0x74/0xf0
[3.532068] smp_apic_timer_interrupt+0x38/0x50
[3.533239] apic_timer_interrupt+0x90/0xa0
[3.534363] RIP: 0010:__local_bh_enable_ip+0x3e/0x80
[3.535722] RSP: :c900014ffe60 EFLAGS: 0286 ORIG_RAX:
ff10
[3.537640] RAX: RBX: 8319c0e0 RCX: 000a
[3.539461] RDX: 81e46b40 RSI: 0200 RDI: 810b0630
[3.541307] RBP: c900014ffe60 R08: 0001 R09: 0101
[3.543497] R10: R11: R12: fee5
[3.545556] R13: R14: dfa1ef74 R15: fee6
[3.547186]
[3.547689] ? rcu_bh_torture_deferred_free+0x20/0x20
[3.548837] rcu_bh_torture_read_unlock+0x15/0x20
[3.549861] rcu_torture_reader+0xe4/0x2b0
[3.550801] ? rcu_torture_reader+0x2b0/0x2b0
[3.551768] kthread+0xfc/0x130
[3.552465] ? rcu_torture_fqs+0xe0/0xe0
[3.553387] ? kthread_create_on_node+0x40/0x40
[3.554460] ret_from_fork+0x29/0x40
Line 387 is this line in tmigr_set_cpu_active():
if (WARN_ON(group->active == group->num_childs)) {
The splat from TREE07 looks quite similar, although it has three splats
rather than only two.
Thanx, Paul
> The series is also available from git:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers
>
> Changes vs. V1:
> - Add
[PATCH] ARM: add DTS, defconfig for ADLINK LEC-iMX6
These are SMARC form factor modules with NXP/Freescale i.MX6 Q/D/DL/S,
1-2 GB RAM, optional eMMC, optional PCIe switch. The DTS files support
the modules on ADLINK's LEC-Base R1 and LEC-Base Mini eval carriers.
Signed-off-by: Jens Rottmann
---
--- /dev/null
+++ b/arch/arm/boot/dts/lec-imx6.dtsi
@@ -0,0 +1,1244 @@
+/*
+ * Copyright 2014-2016 LiPPERT ADLINK Technology GmbH
+ * Copyright 2012-2015 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/* On-module multiplexer: 0 enables SMARC SPI0, !=0 enables I2S0 instead:
+ * 1=TI TLV320AIC23 on LEC-Base R1 carrier, 2=Freescale SGTL5000 on LEC-Base
R2/Mini */
+#define CONFIG_I2S_AUDIO 0
+/* The LEC-Base carrier doesn't include cameras, but allows connecting some. */
+//#define CONFIG_SER_CAMERA3c /* I2C addr of serial camera, hex without
"0x" */
+//#define CONFIG_PAR_CAMERA3c /* I2C addr of parallel camera */
+
+/* The on-module Freescale PF0100 PMIC provides VDD_ARM_IN, VDD_SOC_IN to the
+ * on-SoC Anatop LDOs, which then generate VDD_ARM (CPU cores), VDD_PU
+ * (GPU/VPU), VDD_SOC (the rest). To save power clock and voltage need to vary
+ * according to the workload.
+ * Normal: PMIC provides fixed voltage, internal LDO lowers voltage further to
+ * required value, depending on clock frequency.
+ * LDO bypass: PMIC (switched!) provides variable voltage directly, controlled
+ * via I2C; internal LDOs bridged (FETs permanently on).
+ * Bypassing saves power, but requires steady communication on i2c2 to work. */
+#define LDO_BYPASS 1
+
+/* Freescale defines 2 alternative DT nodes for the VPU: The one normally
active
+ * loads a driver called 'mxc_vpu'. The other, disabled one, would invoke a
+ * different driver named 'coda'. I don't know what state it is in; none of
+ * Freescale's sample dts files enable it, but the code is there, appearently
+ * dormant, in imx6qdl.dtsi. 'Coda' requires a v4l-coda960-imx6*.bin firmware.
*/
+#define VPU_CODA 0
+
+#include
+#include
+#define __0x(X) 0x##X /* prefix hex digits with "0x" */
+#define _0x(X) __0x(X)
+
+/ {
+ aliases {
+ mxcfb0 = &mxcfb1;
+ mxcfb1 = &mxcfb2;
+ mxcfb2 = &mxcfb3;
+ };
+
+ chosen {
+ /* U-Boot provides this via "console=..." in the 'params'
variable. */
+ //stdout-path = &uart1;
+ };
+
+ /* The LEC-Base carriers don't have any LEDs, just show how it's done.
*/
+ //leds {
+ // compatible = "gpio-leds";
+ //
+ // example-led {
+ // gpios = <&smarc_gpio 5 GPIO_ACTIVE_LOW>; /* SMARC
GPIO5/PWM_OUT */
+ // linux,default-trigger = "mmc1"; /* more triggers in
menuconfig */
+ // };
+ //};
+
+ memory: memory {
+ reg = <0x1000 0x4000>; /* dummy size, overwritten by
U-Boot */
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_regulators>;
+
+ reg_smarc_lcd_vdd: regulator@130 {
+ compatible = "regulator-fixed";
+ reg = <130>;
+ regulator-name = "smarc_lcd_vdd";
+ gpio = <&gpio1 30 GPIO_ACTIVE_HIGH>; /* SMARC
LCD_VDD_EN */
+ enable-active-high;
+ regulator-always-on; /* Freescale's fb/lcd/ldb drivers
can't control a regulator yet :-( */
+ regulator-state-mem { regulator-off-in-suspend; }; /*
no effect? */
+ };
+
+ reg_smarc_usb0: regulator@127 {
+ compatible = "regulator-fixed";
+ reg = <127>;
+ regulator-name = "smarc_usb0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio1 27 GPIO_ACTIVE_HIGH>; /* SMARC
USB0_EN_OC# */
+ enable-active-high;
+ };
+
+ reg_smarc_usb1: regulator@329 {
+ compatible = "regulator-fixed";
+ reg = <329>;
+ regulator-name = "smarc_usb1";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio3 29 GPIO_ACTIVE_HIGH>; /* SMARC
USB1_EN_OC# */
+ enable-active-high;
+ /* Before enabling Vbus on the carrier power
Re: net: cleanup_net is slow
Eric Dumazet wrote: > On Fri, Apr 21, 2017 at 10:50 AM, Andrey Konovalov > wrote: > > Hi! > > > > We're investigating some approaches to improve isolation of syzkaller > > programs. One of the ideas is run each program in it's own user/net > > namespace. However, while I was experimenting with this, I stumbled > > upon a problem. > > > > It seems that cleanup_net() might take a very long time to execute. > > > > I've attached the reproducer and kernel .config that I used. Run as > > "./a.out 1". The reproducer just forks and does unshare(CLONE_NEWNET) > > in a loop. Note, that I have a lot of network-related configs enabled, > > which causes a few interfaces to be set up by default. > > > > What I see with this reproducer is that at first a huge number > > (~200-300) net namespaces are created without any contention. But then > > (probably when one of these namespaces gets destroyed) the program > > hangs for a considerable amount of time (~100 seconds in my vm). > > Nothing locks up inside the kernel and the CPU is mostly idle. > > > > Adding debug printfs showed that the part that takes almost all of > > that time is the lines between synchronize_rcu() and > > mutex_unlock(&net_mutex) in cleanup_net. Running perf showed that the > > cause of this might be a lot of calls to synchronize_net that happen > > while executing those lines. > > > > Is there any change that can be done to speed up the > > creation/destruction of a huge number of net namespaces? > > > > We have batches, but fundamentally this is a hard problem to solve. > > Every time we try, we add bugs :/ > > RTNL is the new BKL (Big Kernel Lock of early linux) of today. > > Even the synchronize_rcu_expedited() done from synchronize_net() is a > serious issue on some platforms. Indeed. Setting net.netfilter.nf_conntrack_default_on=0 cuts time cleanup time by 2/3 ... nf unregister is way too happy to issue synchronize_net(), I'll work on a fix.
Re: [PATCH v2 16/17] IB/mlx4: Add spaces for better code readability
On Fri, 2017-04-21 at 20:54 +0200, SF Markus Elfring wrote: > Use space characters at some source code places according to > the Linux coding style convention. [] > diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c [] > @@ -2599,7 +2599,7 @@ static int build_mlx_header(struct mlx4_ib_sqp *sqp, > struct ib_ud_wr *wr, > u16 ether_type; > u16 pcp = (be32_to_cpu(ah->av.ib.sl_tclass_flowlabel) >> 29) << > 13; > > - ether_type = (!is_udp) ? ETH_P_IBOE: > + ether_type = (!is_udp) ? ETH_P_IBOE : > (ip_version == 4 ? ETH_P_IP : ETH_P_IPV6); Please refrain from tool generated mechanical changes. Do try to make the code human readable and correct when you are also making actual object code differences. If this is to be modified at all then also please use consistent ?: condition testing parentheses or perhaps don't use parentheses at all. Maybe even align the ETH_P_ uses like: ether_type = !is_udp? ETH_P_IBOE : ip_version == 4? ETH_P_IP : ETH_P_IPV6;
Re: [PATCH] lightnvm: propagate pblk_init return to userspace
> On 20 Apr 2017, at 20.23, Rakesh Pandit wrote:
>
> From userspace calling ioctl(NVM_DEV_CREATE) was returning ENOMEM for
> invalid arguments even though pblk (pblk_init) was returning correctly
> -EINVAL to nvm_create_tgt inside core. This patch propagates the
> correct return value to userspace.
>
> Because pblk was introduced recently this only needs to go in 4.12.
>
> Fixes: a4bd217b4326 ("lightnvm: physical block device (pblk) target")
> Signed-off-by: Rakesh Pandit
>
Looks good.
Reviewed-by: Javier González
Javier
signature.asc
Description: Message signed with OpenPGP
Re: [tip:x86/mm] x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation
On Fri, Apr 21, 2017 at 7:16 AM, Kirill A. Shutemov wrote: > On Thu, Apr 20, 2017 at 02:46:51PM -0700, Dan Williams wrote: >> On Sat, Mar 18, 2017 at 2:52 AM, tip-bot for Kirill A. Shutemov >> wrote: >> > Commit-ID: 2947ba054a4dabbd82848728d765346886050029 >> > Gitweb: >> > http://git.kernel.org/tip/2947ba054a4dabbd82848728d765346886050029 >> > Author: Kirill A. Shutemov >> > AuthorDate: Fri, 17 Mar 2017 00:39:06 +0300 >> > Committer: Ingo Molnar >> > CommitDate: Sat, 18 Mar 2017 09:48:03 +0100 >> > >> > x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation >> > >> > This patch provides all required callbacks required by the generic >> > get_user_pages_fast() code and switches x86 over - and removes >> > the platform specific implementation. >> > >> > Signed-off-by: Kirill A. Shutemov >> > Cc: Andrew Morton >> > Cc: Aneesh Kumar K . V >> > Cc: Borislav Petkov >> > Cc: Catalin Marinas >> > Cc: Dann Frazier >> > Cc: Dave Hansen >> > Cc: H. Peter Anvin >> > Cc: Linus Torvalds >> > Cc: Peter Zijlstra >> > Cc: Rik van Riel >> > Cc: Steve Capper >> > Cc: Thomas Gleixner >> > Cc: linux-a...@vger.kernel.org >> > Cc: linux...@kvack.org >> > Link: >> > http://lkml.kernel.org/r/20170316213906.89528-1-kirill.shute...@linux.intel.com >> > [ Minor readability edits. ] >> > Signed-off-by: Ingo Molnar >> >> I'm still trying to spot the bug, but bisect points to this patch as >> the point at which my unit tests start failing with the following >> signature: > > I can't find the issue either. > > Is it something reproducible without hardware? In KVM? You can do it in KVM, just boot with the memmap=ss!nn parameter to simulate pmem. In this case I'm booting with memmap=4G!8G, you should also specify "nokaslr". > If yes, could you share the test-case? Yes, run: ./autogen.sh ./configure CFLAGS='-g -O0' --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib64 make TESTS=device-dax check ...from a checkout of the ndctl project: https://github.com/pmem/ndctl Let me know if you run into any problems getting the test to build or run. > >> [ 35.423841] WARNING: CPU: 8 PID: 245 at lib/percpu-refcount.c:155 >> percpu_ref_switch_to_atomic_rcu+0x1f5/0x200 >> [ 35.425328] percpu ref (dax_pmem_percpu_release [dax_pmem]) <= 0 >> (0) after switching to atomic >> [ 35.425329] Modules linked in: ip6t_rpfilter ip6t_REJECT >> nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc >> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip >> 6table_mangle ip6table_raw ip6table_security iptable_nat >> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack >> iptable_mangle iptable_raw iptable_security ebtable_filter ebtables >> ip6table_filter ip6_tables crct10dif_pclmul crc32_pclmul crc32c_intel >> ghash_clmulni_intel nd_pmem(O) dax_pmem(O) nd_btt(O) dax(O) serio_raw >> nfit(O) nd_e820(O) libnvdimm(O) tpm_tis tpm_tis_co >> re tpm nfit_test_iomap(O) nfsd nfs_acl >> [ 35.433683] CPU: 8 PID: 245 Comm: rcuos/29 Tainted: G O >> 4.11.0-rc2+ #55 >> [ 35.435538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), >> BIOS 1.9.3-1.fc25 04/01/2014 >> [ 35.437500] Call Trace: >> [ 35.438270] dump_stack+0x86/0xc3 >> [ 35.439156] __warn+0xcb/0xf0 >> [ 35.439995] warn_slowpath_fmt+0x5f/0x80 >> [ 35.440962] ? rcu_nocb_kthread+0x27a/0x500 >> [ 35.441957] ? dax_pmem_percpu_exit+0x50/0x50 [dax_pmem] >> [ 35.443107] percpu_ref_switch_to_atomic_rcu+0x1f5/0x200 >> [ 35.444251] ? percpu_ref_exit+0x60/0x60 >> [ 35.445206] rcu_nocb_kthread+0x327/0x500 >> [ 35.446186] ? rcu_nocb_kthread+0x27a/0x500 >> [ 35.447188] kthread+0x10c/0x140 >> [ 35.448058] ? rcu_eqs_enter+0x50/0x50 >> [ 35.448990] ? kthread_create_on_node+0x60/0x60 >> [ 35.450038] ret_from_fork+0x31/0x40 >> [ 35.450976] ---[ end trace eaa40898a09519b5 ]--- >> >> This is similar to the backtrace when we were not properly handling >> pud faults and was fixed with this commit: 220ced1676c4 "mm: fix >> get_user_pages() vs device-dax pud mappings" >> >> I've found some missing _devmap checks in the generic >> get_user_pages_fast() path, but this does not fix the regression: > > I don't see these in x86 GUP. Was the bug there too? No it wasn't, the test runs fine with v4.11-rc7, so perhaps I'm looking in the wrong place...
Re: [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC
On Fri, Apr 21, 2017 at 04:12:43PM +0200, Jiri Slaby wrote: > Do not use a custom macro FUNC for starts of the global functions, use > ENTRY instead. > > And while at it, annotate also ends of the functions by ENDPROC. > > Signed-off-by: Jiri Slaby > Cc: "David S. Miller" > Cc: Alexey Kuznetsov > Cc: James Morris > Cc: Hideaki YOSHIFUJI > Cc: Patrick McHardy > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x...@kernel.org > Cc: net...@vger.kernel.org > --- > arch/x86/net/bpf_jit.S | 32 ++-- > 1 file changed, 18 insertions(+), 14 deletions(-) > > diff --git a/arch/x86/net/bpf_jit.S b/arch/x86/net/bpf_jit.S > index f2a7faf4706e..762c29fb8832 100644 > --- a/arch/x86/net/bpf_jit.S > +++ b/arch/x86/net/bpf_jit.S > @@ -23,16 +23,12 @@ > 32 /* space for rbx,r13,r14,r15 */ + \ > 8 /* space for skb_copy_bits */) > > -#define FUNC(name) \ > - .globl name; \ > - .type name, @function; \ > - name: > - > -FUNC(sk_load_word) > +ENTRY(sk_load_word) > test%esi,%esi > js bpf_slow_path_word_neg > +ENDPROC(sk_load_word) this doens't look right. It will add alignment nops in critical paths of these pseudo functions. I'm also not sure whether it will still work afterwards. Was it tested? I'd prefer if this code kept as-is. > -FUNC(sk_load_word_positive_offset) > +ENTRY(sk_load_word_positive_offset) > mov %r9d,%eax # hlen > sub %esi,%eax # hlen - offset > cmp $3,%eax > @@ -40,12 +36,14 @@ FUNC(sk_load_word_positive_offset) > mov (SKBDATA,%rsi),%eax > bswap %eax/* ntohl() */ > ret > +ENDPROC(sk_load_word_positive_offset) > > -FUNC(sk_load_half) > +ENTRY(sk_load_half) > test%esi,%esi > js bpf_slow_path_half_neg > +ENDPROC(sk_load_half) > > -FUNC(sk_load_half_positive_offset) > +ENTRY(sk_load_half_positive_offset) > mov %r9d,%eax > sub %esi,%eax # hlen - offset > cmp $1,%eax > @@ -53,16 +51,19 @@ FUNC(sk_load_half_positive_offset) > movzwl (SKBDATA,%rsi),%eax > rol $8,%ax # ntohs() > ret > +ENDPROC(sk_load_half_positive_offset) > > -FUNC(sk_load_byte) > +ENTRY(sk_load_byte) > test%esi,%esi > js bpf_slow_path_byte_neg > +ENDPROC(sk_load_byte) > > -FUNC(sk_load_byte_positive_offset) > +ENTRY(sk_load_byte_positive_offset) > cmp %esi,%r9d /* if (offset >= hlen) goto bpf_slow_path_byte */ > jle bpf_slow_path_byte > movzbl (SKBDATA,%rsi),%eax > ret > +ENDPROC(sk_load_byte_positive_offset) > > /* rsi contains offset and can be scratched */ > #define bpf_slow_path_common(LEN)\ > @@ -119,31 +120,34 @@ bpf_slow_path_word_neg: > cmp SKF_MAX_NEG_OFF, %esi /* test range */ > jl bpf_error /* offset lower -> error */ > > -FUNC(sk_load_word_negative_offset) > +ENTRY(sk_load_word_negative_offset) > sk_negative_common(4) > mov (%rax), %eax > bswap %eax > ret > +ENDPROC(sk_load_word_negative_offset) > > bpf_slow_path_half_neg: > cmp SKF_MAX_NEG_OFF, %esi > jl bpf_error > > -FUNC(sk_load_half_negative_offset) > +ENTRY(sk_load_half_negative_offset) > sk_negative_common(2) > mov (%rax),%ax > rol $8,%ax > movzwl %ax,%eax > ret > +ENDPROC(sk_load_half_negative_offset) > > bpf_slow_path_byte_neg: > cmp SKF_MAX_NEG_OFF, %esi > jl bpf_error > > -FUNC(sk_load_byte_negative_offset) > +ENTRY(sk_load_byte_negative_offset) > sk_negative_common(1) > movzbl (%rax), %eax > ret > +ENDPROC(sk_load_byte_negative_offset) > > bpf_error: > # force a return 0 from jit handler > -- > 2.12.2 >
Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support
Hi, On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI > controller. > > That HDMI controller is able to do audio and CEC, but those have been left > out for now. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/sun4i/Makefile | 5 +- > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++- > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +- > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++- > 5 files changed, 942 insertions(+), 0 deletions(-) > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c Applying patch #9608371 using 'git am' Description: [13/15] drm/sun4i: Add HDMI support Applying: drm/sun4i: Add HDMI support .git/rebase-apply/patch:116: trailing whitespace. .git/rebase-apply/patch:531: trailing whitespace. .git/rebase-apply/patch:701: trailing whitespace. warning: 3 lines add whitespace errors. > diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile > index 59b757350a1f..68a0f6244a59 100644 > --- a/drivers/gpu/drm/sun4i/Makefile > +++ b/drivers/gpu/drm/sun4i/Makefile > @@ -7,7 +7,12 @@ sun4i-tcon-y += sun4i_dotclock.o > sun4i-tcon-y += sun4i_crtc.o > sun4i-tcon-y += sun4i_layer.o > > +sun4i-drm-hdmi-y += sun4i_hdmi_enc.o > +sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o > +sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o > + > obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o > obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o > obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o > +obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm-hdmi.o > obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o > diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h > b/drivers/gpu/drm/sun4i/sun4i_hdmi.h > new file mode 100644 > index ..2ad25b8fd3cd > --- /dev/null > +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h > @@ -0,0 +1,124 @@ > +/* > + * Copyright (C) 2016 Maxime Ripard > + * > + * Maxime Ripard > + * > + * 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. > + */ > + > +#ifndef _SUN4I_HDMI_H_ > +#define _SUN4I_HDMI_H_ > + > +#include > +#include > + > +#define SUN4I_HDMI_CTRL_REG0x004 > +#define SUN4I_HDMI_CTRL_ENABLE BIT(31) > + > +#define SUN4I_HDMI_IRQ_REG 0x008 > +#define SUN4I_HDMI_IRQ_STA_MASK0x73 > +#define SUN4I_HDMI_IRQ_STA_FIFO_OF BIT(1) > +#define SUN4I_HDMI_IRQ_STA_FIFO_UF BIT(0) > + > +#define SUN4I_HDMI_HPD_REG 0x00c > +#define SUN4I_HDMI_HPD_HIGHBIT(0) > + > +#define SUN4I_HDMI_VID_CTRL_REG0x010 > +#define SUN4I_HDMI_VID_CTRL_ENABLE BIT(31) > +#define SUN4I_HDMI_VID_CTRL_HDMI_MODE BIT(30) > + > +#define SUN4I_HDMI_VID_TIMING_ACT_REG 0x014 > +#define SUN4I_HDMI_VID_TIMING_BP_REG 0x018 > +#define SUN4I_HDMI_VID_TIMING_FP_REG 0x01c > +#define SUN4I_HDMI_VID_TIMING_SPW_REG 0x020 > + > +#define SUN4I_HDMI_VID_TIMING_X(x) x) - 1) & GENMASK(11, 0))) > +#define SUN4I_HDMI_VID_TIMING_Y(y) y) - 1) & GENMASK(11, 0)) > << 16) > + > +#define SUN4I_HDMI_VID_TIMING_POL_REG 0x024 > +#define SUN4I_HDMI_VID_TIMING_POL_TX_CLK(0x3e0 << 16) > +#define SUN4I_HDMI_VID_TIMING_POL_VSYNCBIT(1) > +#define SUN4I_HDMI_VID_TIMING_POL_HSYNCBIT(0) > + > +#define SUN4I_HDMI_AVI_INFOFRAME_REG(n)(0x080 + (n)) > + > +#define SUN4I_HDMI_PAD_CTRL0_REG 0x200 > + > +#define SUN4I_HDMI_PAD_CTRL1_REG 0x204 > +#define SUN4I_HDMI_PAD_CTRL1_HALVE_CLK BIT(6) > + > +#define SUN4I_HDMI_PLL_CTRL_REG0x208 > +#define SUN4I_HDMI_PLL_CTRL_DIV(n) ((n) << 4) > +#define SUN4I_HDMI_PLL_CTRL_DIV_MASK GENMASK(7, 4) > + > +#define SUN4I_HDMI_PLL_DBG0_REG0x20c > +#define SUN4I_HDMI_PLL_DBG0_TMDS_PARENT(n) (((n) & 1) << 21) > +#define SUN4I_HDMI_PLL_DBG0_TMDS_PARENT_MASK BIT(21) > +#define SUN4I_HDMI_PLL_DBG0_TMDS_PARENT_SHIFT 21 > + > +#define SUN4I_HDMI_PKT_CTRL_REG(n) (0x2f0 + (4 * (n))) > +#define SUN4I_HDMI_PKT_CTRL_TYPE(n, t) ((t) << (((n) % 4) * 4)) > + > +#define SUN4I_HDMI_UNKNOWN_REG 0x300 > +#define SUN4I_HDMI_UNKNOWN_INPUT_SYNC BIT(27) > + > +#define SUN4I_HDMI_DDC_CTRL_REG0x500 > +#define SUN4I_HDMI_DDC_CTRL_ENABLE BIT(31) > +#define SUN4I_HDMI_DDC_CTRL_START_CMD BIT(30) > +#define SUN4I_HDMI_DDC_CTRL_RES
Re: [PATCH net-next] net: dsa: LAN9303: add I2C dependency
From: Arnd Bergmann
Date: Fri, 21 Apr 2017 18:22:40 +0200
> With CONFIG_I2C=m and NET_DSA_SMSC_LAN9303=y, we run into a link error:
>
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_read':
> regmap-i2c.c:(.text.regmap_smbus_byte_reg_read+0x18): undefined reference to
> `i2c_smbus_read_byte_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_write':
> regmap-i2c.c:(.text.regmap_smbus_byte_reg_write+0x18): undefined reference to
> `i2c_smbus_write_byte_data'
> drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_word_reg_read':
> regmap-i2c.c:(.text.regmap_smbus_word_reg_read+0x18): undefined reference to
> `i2c_smbus_read_word_data'
> drivers/base/regmap/regmap-i2c.o: In function
> `regmap_smbus_word_read_swapped':
> regmap-i2c.c:(.text.regmap_smbus_word_read_swapped+0x18): undefined reference
> to `i2c_smbus_read_word_data'
> drivers/base/regmap/regmap-i2c.o: In function
> `regmap_smbus_word_write_swapped':
>
> This adds a Kconfig dependency to avoid the broken configuration.
>
> Fixes: be4e119f9914 ("net: dsa: LAN9303: add I2C managed mode support")
> Signed-off-by: Arnd Bergmann
Applied, thanks.
Re: hwmon: (adt7475) set start bit in probe
On Sat, Apr 22, 2017 at 07:08:09AM +1200, Chris Packham wrote:
> The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any
> monitoring activities the STRT bit needs to be set. Logically this needs
> to happen before any of the sensors are read so the probe() function
> seems the best place for it.
>
> [1] - https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF
>
> Signed-off-by: Chris Packham
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/adt7475.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index fcfa48222145..c803e3c5fcd4 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -59,6 +59,8 @@
> #define REG_VENDID 0x3E
> #define REG_DEVID2 0x3F
>
> +#define REG_CONFIG1 0x40
> +
> #define REG_STATUS1 0x41
> #define REG_STATUS2 0x42
>
> @@ -1371,6 +1373,17 @@ static int adt7475_probe(struct i2c_client *client,
> for (i = 0; i < ADT7475_PWM_COUNT; i++)
> adt7475_read_pwm(client, i);
>
> + /* Start monitoring */
> + switch (chip) {
> + case adt7475:
> + case adt7476:
> + i2c_smbus_write_byte_data(client, REG_CONFIG1,
> + adt7475_read(REG_CONFIG1) | 0x01);
> + break;
> + default:
> + break;
> + }
> +
> ret = sysfs_create_group(&client->dev.kobj, &adt7475_attr_group);
> if (ret)
> return ret;
Re: [PATCH net] ip6mr: fix notification device destruction
From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 21:30:42 +0300 > On 21/04/17 20:42, Nikolay Aleksandrov wrote: >> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused >> because we call unregister_netdevice_many for a device that is already >> being destroyed. In IPv4's ipmr that has been resolved by two commits >> long time ago by introducing the "notify" parameter to the delete >> function and avoiding the unregister when called from a notifier, so >> let's do the same for ip6mr. ... > +CC LKML and Linus Applied, thanks Nikolay and thanks Andrey for the report and testing. Nikolay, how far does this bug go back?
Re: net/core: BUG in unregister_netdevice_many
From: Linus Torvalds Date: Fri, 21 Apr 2017 10:42:48 -0700 > Over to Eric and networking people. This oops is user-triggerable, and > leaves the machine in a bad state (the original BUG_ON() and the new > GP fault both happen while holding the RTNL, so networking is not > healthy afterwards. I have the fix in my tree and will push it to shortly.
Re: net/core: BUG in unregister_netdevice_many
From: Cong Wang Date: Fri, 21 Apr 2017 11:55:04 -0700 > On Fri, Apr 21, 2017 at 10:25 AM, Linus Torvalds > wrote: >> On Fri, Apr 21, 2017 at 5:48 AM, Andrey Konovalov >> wrote: >>> >>> I've got the following error report while fuzzing the kernel with syzkaller. >>> >>> [ cut here ] >>> kernel BUG at net/core/dev.c:6813! >> >> Another useless BUG_ON() that > > I think we are double-unregister'ing the pim6reg device, > we probably need something like: This particular bug is fixed by Nikolay's fix. I'm not saying you haven't spotted another bug.
[RFC-b PATCH] kbuild: redefine __FILE__ as relative path from $(srctree) if possible
Since Kbuild runs in the objtree, __FILE__ can be a very long path
depending of $(srctree).
Commit 9da0763bdd82 ("kbuild: Use relative path when building in a
subdir of the source tree") made the situation better for cases
where objtree is a child of srctree. ($(srctree) is "..")
For other cases of out-of-tree build, filenames in WARN_ON() etc.
are still an absolute path. It also means the kernel image depends
on where it was built.
Here, the idea is to redefine __FILE__ as the relative path from
$(srctree), but doing so causes a compiler warning:
warning: "__FILE__" redefined [-Wbuiltin-macro-redefined]
We can suppress it with -Wno-builtin-macro-redefined. However,
this option is not recognized by old compilers. So, __FILE__
is re-defined only when the option is supported.
I am adding stringify helper because '"..."' wrapping is the same
pattern as in KBUILD_BASENAME, KBUILD_MODNAME.
Please note __FILE__ is always an absolute path for external
modules. We can strip KBUILD_EXTMOD from the path if we want,
but I am not doing that. It would make it difficult to figure out
the module in question in case of WARN_ON().
Signed-off-by: Masahiro Yamada
---
This is another possible approach.
Please see these as well:
https://patchwork.kernel.org/patch/9693559/
https://patchwork.kernel.org/patch/9693563/
Pro:
this is only touching 3 makefiles.
Con:
this does not work for old compilers.
Makefile | 3 +++
scripts/Kbuild.include | 4
scripts/Makefile.lib | 6 --
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 8804aae..293ef6d 100644
--- a/Makefile
+++ b/Makefile
@@ -798,6 +798,9 @@ KBUILD_CFLAGS += $(call
cc-option,-Werror=strict-prototypes)
# Prohibit date/time macros, which would make the build non-deterministic
KBUILD_CFLAGS += $(call cc-option,-Werror=date-time)
+# Is is possible to redefine __FILE__?
+KBUILD_CFLAGS += $(call cc-disable-warning, builtin-macro-redefined)
+
# enforce correct pointer usage
KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 61f87a9..7fc3841 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -31,6 +31,10 @@ baseprereq = $(basename $(notdir $<))
escsq = $(subst $(squote),'\$(squote)',$1)
###
+# Quote a string to pass it to C files. foo => '"foo"'
+stringify = $(squote)$(quote)$1$(quote)$(squote)
+
+###
# Easy method for doing a status message
kecho := :
quiet_kecho := echo
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9e70196..1d789df 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -96,10 +96,12 @@ obj-dirs:= $(addprefix $(obj)/,$(obj-dirs))
# Note: Files that end up in two or more modules are compiled without the
# KBUILD_MODNAME definition. The reason is that any made-up name would
# differ in different configs.
-name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst
-,_,$1))$(quote)$(squote)
+name-fix = $(call stringify,$(subst $(comma),_,$(subst -,_,$1)))
basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget))
modname_flags = $(if $(filter 1,$(words $(modname))),\
-DKBUILD_MODNAME=$(call name-fix,$(modname)))
+filepath_flags = $(if $(filter -Wno-builtin-macro-redefined,
$(KBUILD_CFLAGS)), \
+ -D__FILE__=$(call stringify,$(src)/$(notdir $<)))
orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \
$(ccflags-y) $(CFLAGS_$(basetarget).o)
@@ -163,7 +165,7 @@ endif
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
$(__c_flags) $(modkern_cflags) \
-$(basename_flags) $(modname_flags)
+$(basename_flags) $(modname_flags) $(filepath_flags)
a_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
$(__a_flags) $(modkern_aflags)
--
2.7.4
[PATCH] mtip32xx: Uninitialized variable in mtip_no_dev_cleanup()
We set "cmd->state = -ENODEV;" but "cmd" hasn't been initialized yet.
It's weird that GCC doesn't catch this.
Fixes: 4dda4735c581 ("mtip32xx: add a status field to struct mtip_cmd")
Signed-off-by: Dan Carpenter
---
Not tested, please review carefully.
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 66a6bd83faae..bd4bf70a5bcd 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -4105,14 +4105,12 @@ static int mtip_block_initialize(struct driver_data *dd)
static void mtip_no_dev_cleanup(struct request *rq, void *data, bool reserv)
{
struct driver_data *dd = (struct driver_data *)data;
- struct mtip_cmd *cmd;
+ struct mtip_cmd *cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
if (likely(!reserv)) {
cmd->status = -ENODEV;
blk_mq_complete_request(rq);
} else if (test_bit(MTIP_PF_IC_ACTIVE_BIT, &dd->port->flags)) {
-
- cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
if (cmd->comp_func)
cmd->comp_func(dd->port, MTIP_TAG_INTERNAL,
cmd, -ENODEV);
Re: [RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__
Hi Yamada-san,
On Fri, Apr 21, 2017 at 9:03 PM, Masahiro Yamada
wrote:
> Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed
> with $(srctree)/ for out-of-tree build.
>
> It would be nice to see the same log regardless
> in-tree, or out-of-tree build.
>
> 1/2 adds a new macro KBUILD_FILE. This points the relative path
> of the file we are building. This is intended to replace __FILE__.
>
> 2/2 replaces __FILE__ in bug.h as an example. This will improve
> the output of WARN_ON() etc.
I haven't tried your series, but I love the idea behind it!
I never liked exposing full file paths in kernel images.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type
On Wed, Apr 19, 2017 at 11:38 PM, Jérémy Lefaure wrote: > When building object-list.o, gcc 6 raises a warning on the sprintf call > in fscache_objlist_show: > > CC fs/fscache/object-list.o > fs/fscache/object-list.c: In function ‘fscache_objlist_show’: > fs/fscache/object-list.c:265:19: warning: ‘sprintf’ may write a > terminating nul past the end of the destination [-Wformat-overflow=] > sprintf(_type, "%02u", cookie->def->type); >^~ > fs/fscache/object-list.c:265:4: note: ‘sprintf’ output between 3 and 4 > bytes into a destination of size 3 > sprintf(_type, "%02u", cookie->def->type); > ^ > > Moreover, the documentation says that we should have an hex value for > special cookies (see Documentation/filesystems/caching/fscache.txt). > > Printing hexadecimal value for special cookies fixes the overflow > warning and complies with the documentation. If this is used by some user space tool the safest fix is to print in BCD and fix documentation. > Signed-off-by: Jérémy Lefaure > --- > fs/fscache/object-list.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/fscache/object-list.c b/fs/fscache/object-list.c > index 67f940892ef8..d51303124889 100644 > --- a/fs/fscache/object-list.c > +++ b/fs/fscache/object-list.c > @@ -262,7 +262,7 @@ static int fscache_objlist_show(struct seq_file *m, void > *v) > type = "DT"; > break; > default: > - sprintf(_type, "%02u", cookie->def->type); > + sprintf(_type, "%02x", cookie->def->type); > type = _type; > break; > } > -- > 2.12.2 > -- With Best Regards, Andy Shevchenko
Re: [PATCH] mtip32xx: Uninitialized variable in mtip_no_dev_cleanup()
On 04/21/2017 01:37 PM, Dan Carpenter wrote:
> We set "cmd->state = -ENODEV;" but "cmd" hasn't been initialized yet.
> It's weird that GCC doesn't catch this.
That is weird...
> diff --git a/drivers/block/mtip32xx/mtip32xx.c
> b/drivers/block/mtip32xx/mtip32xx.c
> index 66a6bd83faae..bd4bf70a5bcd 100644
> --- a/drivers/block/mtip32xx/mtip32xx.c
> +++ b/drivers/block/mtip32xx/mtip32xx.c
> @@ -4105,14 +4105,12 @@ static int mtip_block_initialize(struct driver_data
> *dd)
> static void mtip_no_dev_cleanup(struct request *rq, void *data, bool reserv)
> {
> struct driver_data *dd = (struct driver_data *)data;
> - struct mtip_cmd *cmd;
> + struct mtip_cmd *cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
>
> if (likely(!reserv)) {
> cmd->status = -ENODEV;
> blk_mq_complete_request(rq);
> } else if (test_bit(MTIP_PF_IC_ACTIVE_BIT, &dd->port->flags)) {
> -
> - cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
> if (cmd->comp_func)
> cmd->comp_func(dd->port, MTIP_TAG_INTERNAL,
> cmd, -ENODEV);
This is wrong, you can't use the internal tag bit for both cases. A proper
fix was already merged earlier today:
http://git.kernel.dk/cgit/linux-block/commit/?h=for-4.12/block&id=95c55ff425faa190fd8ba55090fbdf33d8b2f0ae
--
Jens Axboe
Re: net: cleanup_net is slow
On Fri, Apr 21, 2017 at 7:57 PM, Eric Dumazet wrote: > On Fri, Apr 21, 2017 at 10:50 AM, Andrey Konovalov > wrote: >> Hi! >> >> We're investigating some approaches to improve isolation of syzkaller >> programs. One of the ideas is run each program in it's own user/net >> namespace. However, while I was experimenting with this, I stumbled >> upon a problem. >> >> It seems that cleanup_net() might take a very long time to execute. >> >> I've attached the reproducer and kernel .config that I used. Run as >> "./a.out 1". The reproducer just forks and does unshare(CLONE_NEWNET) >> in a loop. Note, that I have a lot of network-related configs enabled, >> which causes a few interfaces to be set up by default. >> >> What I see with this reproducer is that at first a huge number >> (~200-300) net namespaces are created without any contention. But then >> (probably when one of these namespaces gets destroyed) the program >> hangs for a considerable amount of time (~100 seconds in my vm). >> Nothing locks up inside the kernel and the CPU is mostly idle. >> >> Adding debug printfs showed that the part that takes almost all of >> that time is the lines between synchronize_rcu() and >> mutex_unlock(&net_mutex) in cleanup_net. Running perf showed that the >> cause of this might be a lot of calls to synchronize_net that happen >> while executing those lines. >> >> Is there any change that can be done to speed up the >> creation/destruction of a huge number of net namespaces? >> > > We have batches, but fundamentally this is a hard problem to solve. > > Every time we try, we add bugs :/ > > RTNL is the new BKL (Big Kernel Lock of early linux) of today. > > Even the synchronize_rcu_expedited() done from synchronize_net() is a > serious issue on some platforms. Not sure how hard it is (I suppose hard) but if whole cleanup_net is structured as series of call_rcu callbacks, it should give perfect batching across all possible dimensions (e.g. across different ops_exit_list calls and even across cleanup of different namespaces).
