Re: [PATCH] clk: rockchip: fix frac settings of GPLL clock for rk3328
Hi Elaine,
Am Montag, 24. Dezember 2018, 08:48:05 CET schrieb zhangq...@rock-chips.com:
> Hi: Heiko:
>
> This explanation and the change is OK. Thanks for Katsuhiro's correction.
thanks for your quick confirmation. Can I make this an
Acked-by: Elaine Zhang
when applying the patch?
Thanks
Heiko
> 张晴
> 福州瑞芯微电子股份有限公司
> Fuzhou Rockchip Electronics Co.,Ltd
> 地址：福建省福州市铜盘路软件大道89号软件园A区21号楼
> Add:No.21 Building, A District, No.89 Software Boulevard Fuzhou, Fujian
> 350003, P.R.China
> Tel:+86-0591-83991906-8601
> 邮编：350003
> E-mail:elaine.zh...@rock-chips.com
>
> From: Heiko Stuebner
> Date: 2018-12-24 15:34
> To: Katsuhiro Suzuki; Finley Xiao; Elaine Zhang
> CC: linux-rockchip; linux-arm-kernel; linux-kernel
> Subject: Re: [PATCH] clk: rockchip: fix frac settings of GPLL clock for rk3328
> Hi,
>
> Am Samstag, 22. Dezember 2018, 17:42:49 CET schrieb Katsuhiro Suzuki:
> > This patch fixes settings of GPLL frequency in fractional mode for
> > rk3328. In this mode, FOUTVCO is calcurated by following formula:
> > FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24)
> >
> > The problem is in FREF * FRAC >> 24 term. This result always lacks
> > one from target value is specified by rate member. For example first
> > itme of rk3328_pll_frac_rate originally has
> > - rate : 1016064000
> > - refdiv: 3
> > - fbdiv : 127
> > - frac : 134217
> > - FREF * FBDIV / REFDIV= 101600
> > - (FREF * FRAC / REFDIV) >> 24 = 63999
> > Thus calculated rate is 1016063999. It seems wrong.
> >
> > If frac has 134218 (it is increased 1 from original value), second
> > term is 64000. All other items have same situation. So this patch
> > adds 1 to frac member in all items of rk3328_pll_frac_rate.
> >
> > Signed-off-by: Katsuhiro Suzuki
>
> so while this sounds all quite right to me, I've added some Rockchip
> people that have clock experience to hopefully get an Ack on the
> change :-)
>
> @Elaine + Finley: does this explanation and the below change look right?
>
>
> Thanks
> Heiko
>
> > ---
> > drivers/clk/rockchip/clk-rk3328.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/clk/rockchip/clk-rk3328.c
> > b/drivers/clk/rockchip/clk-rk3328.c
> > index faa94adb2a37..65ab5c2f48b0 100644
> > --- a/drivers/clk/rockchip/clk-rk3328.c
> > +++ b/drivers/clk/rockchip/clk-rk3328.c
> > @@ -78,17 +78,17 @@ static struct rockchip_pll_rate_table
> > rk3328_pll_rates[] = {
> >
> > static struct rockchip_pll_rate_table rk3328_pll_frac_rates[] = {
> > /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
> > - RK3036_PLL_RATE(1016064000, 3, 127, 1, 1, 0, 134217),
> > + RK3036_PLL_RATE(1016064000, 3, 127, 1, 1, 0, 134218),
> > /* vco = 1016064000 */
> > - RK3036_PLL_RATE(98304, 24, 983, 1, 1, 0, 671088),
> > + RK3036_PLL_RATE(98304, 24, 983, 1, 1, 0, 671089),
> > /* vco = 98304 */
> > - RK3036_PLL_RATE(49152, 24, 983, 2, 1, 0, 671088),
> > + RK3036_PLL_RATE(49152, 24, 983, 2, 1, 0, 671089),
> > /* vco = 98304 */
> > - RK3036_PLL_RATE(6144, 6, 215, 7, 2, 0, 671088),
> > + RK3036_PLL_RATE(6144, 6, 215, 7, 2, 0, 671089),
> > /* vco = 860156000 */
> > - RK3036_PLL_RATE(56448000, 12, 451, 4, 4, 0, 9797894),
> > + RK3036_PLL_RATE(56448000, 12, 451, 4, 4, 0, 9797895),
> > /* vco = 903168000 */
> > - RK3036_PLL_RATE(4096, 12, 409, 4, 5, 0, 10066329),
> > + RK3036_PLL_RATE(4096, 12, 409, 4, 5, 0, 10066330),
> > /* vco = 81920 */
> > { /* sentinel */ },
> > };
> >
>
>
>
>
>
>
Hello
Hello Dear Friend I am Dr. Samson Mohamed; please I have a very important issue to discuss with you. Please I urge you to contact me via my E-mail address: samsonmoha...@aol.com. Thank You, Dr. Samson Mohamed.
Re: [PATCH net-next 3/3] vhost: access vq metadata through kernel virtual address
On 2018/12/14 下午8:36, Michael S. Tsirkin wrote:
On Fri, Dec 14, 2018 at 11:57:35AM +0800, Jason Wang wrote:
On 2018/12/13 下午11:44, Michael S. Tsirkin wrote:
On Thu, Dec 13, 2018 at 06:10:22PM +0800, Jason Wang wrote:
It was noticed that the copy_user() friends that was used to access
virtqueue metdata tends to be very expensive for dataplane
implementation like vhost since it involves lots of software check,
speculation barrier, hardware feature toggling (e.g SMAP). The
extra cost will be more obvious when transferring small packets.
This patch tries to eliminate those overhead by pin vq metadata pages
and access them through vmap(). During SET_VRING_ADDR, we will setup
those mappings and memory accessors are modified to use pointers to
access the metadata directly.
Note, this was only done when device IOTLB is not enabled. We could
use similar method to optimize it in the future.
Tests shows about ~24% improvement on TX PPS when using virtio-user +
vhost_net + xdp1 on TAP (CONFIG_HARDENED_USERCOPY is not enabled):
Before: ~5.0Mpps
After: ~6.1Mpps
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 178 ++
drivers/vhost/vhost.h | 11 +++
2 files changed, 189 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index bafe39d2e637..1bd24203afb6 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -443,6 +443,9 @@ void vhost_dev_init(struct vhost_dev *dev,
vq->indirect = NULL;
vq->heads = NULL;
vq->dev = dev;
+ memset(>avail_ring, 0, sizeof(vq->avail_ring));
+ memset(>used_ring, 0, sizeof(vq->used_ring));
+ memset(>desc_ring, 0, sizeof(vq->desc_ring));
mutex_init(>mutex);
vhost_vq_reset(dev, vq);
if (vq->handle_kick)
@@ -614,6 +617,102 @@ static void vhost_clear_msg(struct vhost_dev *dev)
spin_unlock(>iotlb_lock);
}
+static int vhost_init_vmap(struct vhost_vmap *map, unsigned long uaddr,
+ size_t size, int write)
+{
+ struct page **pages;
+ int npages = DIV_ROUND_UP(size, PAGE_SIZE);
+ int npinned;
+ void *vaddr;
+
+ pages = kmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
+ if (!pages)
+ return -ENOMEM;
+
+ npinned = get_user_pages_fast(uaddr, npages, write, pages);
+ if (npinned != npages)
+ goto err;
+
As I said I have doubts about the whole approach, but this
implementation in particular isn't a good idea
as it keeps the page around forever.
The pages wil be released during set features.
So no THP, no NUMA rebalancing,
For THP, we will probably miss 2 or 4 pages, but does this really matter
consider the gain we have? For NUMA rebalancing, I'm even not quite sure
if it can helps for the case of IPC (vhost). It looks to me the worst
case it may cause page to be thrash between nodes if vhost and userspace
are running in two nodes.
This is the price of all GUP users not only vhost itself.
Yes. GUP is just not a great interface for vhost to use.
Zerocopy codes (enabled by defualt) use them for years.
What's more
important, the goal is not to be left too much behind for other backends
like DPDK or AF_XDP (all of which are using GUP).
So these guys assume userspace knows what it's doing.
We can't assume that.
What kind of assumption do you they have?
userspace-controlled
amount of memory locked up and not accounted for.
It's pretty easy to add this since the slow path was still kept. If we
exceeds the limitation, we can switch back to slow path.
Don't get me wrong it's a great patch in an ideal world.
But then in an ideal world no barriers smap etc are necessary at all.
Again, this is only for metadata accessing not the data which has been used
for years for real use cases.
For SMAP, it makes senses for the address that kernel can not forcast. But
it's not the case for the vhost metadata since we know the address will be
accessed very frequently. For speculation barrier, it helps nothing for the
data path of vhost which is a kthread.
I don't see how a kthread makes any difference. We do have a validation
step which makes some difference.
The problem is not kthread but the address of userspace address. The
addresses of vq metadata tends to be consistent for a while, and vhost
knows they will be frequently. SMAP doesn't help too much in this case.
Thanks.
Packet or AF_XDP benefit from
accessing metadata directly, we should do it as well.
Thanks
Re: Bug with report THP eligibility for each vma
[Cc-ing mailing list and people involved in the original patch]
On Fri 21-12-18 13:42:24, Paul Oppenheimer wrote:
> Hello! I've never reported a kernel bug before, and since its on the
> "next" tree I was told to email the author of the relevant commit.
> Please redirect me to the correct place if I've made a mistake.
>
> When opening firefox or chrome, and using it for a good 7 seconds, it
> hangs in "uninterruptible sleep" and I recieve a "BUG" in dmesg. This
> doesn't occur when reverting this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=48cf516f8c.
> Ive attached the output of decode_stacktrace.sh and the relevant dmesg
> log to this email.
>
> Thanks
> BUG: unable to handle kernel NULL pointer dereference at 00e8
Thanks for the bug report! This is offset 232 and that matches
file->f_mapping as per pahole
pahole -C file ./vmlinux | grep f_mapping
struct address_space * f_mapping;/* 232 8 */
I thought that each file really has to have a mapping. But the following
should heal the issue and add an extra care.
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f64733c23067..fc9d70a9fbd1 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -66,6 +66,8 @@ bool transparent_hugepage_enabled(struct vm_area_struct *vma)
{
if (vma_is_anonymous(vma))
return __transparent_hugepage_enabled(vma);
+ if (!vma->vm_file || !vma->vm_file->f_mapping)
+ return false;
if (shmem_mapping(vma->vm_file->f_mapping) && shmem_huge_enabled(vma))
return __transparent_hugepage_enabled(vma);
Andrew, could you fold it to the original patch please?
Keeping the rest for the reference.
> #PF error: [normal kernel read fault]
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 7 PID: 2687 Comm: StreamTrans #56 Tainted: G U
> 4.20.0-rc7-next-20181221-beppy+ #15
> Hardware name: Dell Inc. XPS 13 9360/0TPN17, BIOS 2.10.0 09/27/2018
> RIP: 0010:transparent_hugepage_enabled (??:?)
> Code: 17 fd 00 e9 20 ff ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89
> fb 48 83 bf 90 00 00 00 00 74 27 48 8b 87 a0 00 00 00 <48> 8b b8 e8 00 00 00
> e8 7a cc fa ff 84 c0 75 04 31 c0 5b c3 48 89
> All code
>
>0: 17 (bad)
>1: fd std
>2: 00 e9 add%ch,%cl
>4: 20 ff and%bh,%bh
>6: ff (bad)
>7: ff 0f decl (%rdi)
>9: 1f (bad)
>a: 84 00 test %al,(%rax)
>c: 00 00 add%al,(%rax)
>e: 00 00 add%al,(%rax)
> 10: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 15: 53 push %rbx
> 16: 48 89 fbmov%rdi,%rbx
> 19: 48 83 bf 90 00 00 00cmpq $0x0,0x90(%rdi)
> 20: 00
> 21: 74 27 je 0x4a
> 23: 48 8b 87 a0 00 00 00mov0xa0(%rdi),%rax
> 2a:*48 8b b8 e8 00 00 00mov0xe8(%rax),%rdi <--
> trapping instruction
> 31: e8 7a cc fa ff callq 0xfffaccb0
> 36: 84 c0 test %al,%al
> 38: 75 04 jne0x3e
> 3a: 31 c0 xor%eax,%eax
> 3c: 5b pop%rbx
> 3d: c3 retq
> 3e: 48 rex.W
> 3f: 89 .byte 0x89
>
> Code starting with the faulting instruction
> ===
>0: 48 8b b8 e8 00 00 00mov0xe8(%rax),%rdi
>7: e8 7a cc fa ff callq 0xfffacc86
>c: 84 c0 test %al,%al
>e: 75 04 jne0x14
> 10: 31 c0 xor%eax,%eax
> 12: 5b pop%rbx
> 13: c3 retq
> 14: 48 rex.W
> 15: 89 .byte 0x89
> RSP: 0018:b79744f17d28 EFLAGS: 00010282
> RAX: RBX: 8948c17aff00 RCX:
> RDX: 0004 RSI: ab1165ba RDI: 8948c17aff00
> RBP: 8948c17aff00 R08: 0007 R09: 894927e547b2
> R10: R11: 894927e549da R12: b79744f17d38
> R13: 8948c17aff00 R14: 89489bef9400 R15: 89488b775a80
> FS: 7fa54ad43700() GS:8949363c() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 00e8 CR3: 00025c0ee003 CR4: 003606e0
> Call Trace:
> show_smap (/home/bep/.opt/kernel/linux-e/fs/proc/task_mmu.c:805)
> seq_read (/home/bep/.opt/kernel/linux-e/fs/seq_file.c:269)
> __vfs_read (/home/bep/.opt/kernel/linux-e/fs/read_write.c:421)
> vfs_read (/home/bep/.opt/kernel/linux-e/fs/read_write.c:452
> /home/bep/.opt/kernel/linux-e/fs/read_write.c:437)
> ksys_read
Re: [PATCH] mlxsw: spectrum_acl_bloom_filter: use struct_size() in kzalloc()
On 12/24/18 1:38 AM, Ido Schimmel wrote:
On Sun, Dec 23, 2018 at 11:27:41PM -0600, Gustavo A. R. Silva wrote:
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Ido Schimmel
But net-next is closed (http://vger.kernel.org/~davem/net-next.html) and
this isn't a bug fix. Can you please re-submit when net-next opens
again? Alternatively, I can apply the patch to my mlxsw queue and submit
in your stead. Let me know what you prefer.
Oh yeah. I forgot net close net-next during the merge window. I'll
re-submit it in two weeks then. I'll add your Reviewed-by.
Happy holiday.
Thanks
--
Gustavo
[PATCH] ASoC: sgtl5000: Allow SCLK pad drive strength to be changed
This patch introduces "sclk-strength" property to allow SCLK pad drive
strength to be changed via device tree.
When running playback test on LS1028ARDB, Tx Frame sync error interrupt
will occur sometimes. Some noises also exist. After changing SCLK pad
drive strength to the maximum value, the issues are gone.
Signed-off-by: Alison Wang
---
sound/soc/codecs/sgtl5000.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index add18d6..a6a4748 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -116,6 +116,13 @@ enum {
I2S_LRCLK_STRENGTH_HIGH,
};
+enum {
+ I2S_SCLK_STRENGTH_DISABLE,
+ I2S_SCLK_STRENGTH_LOW,
+ I2S_SCLK_STRENGTH_MEDIUM,
+ I2S_SCLK_STRENGTH_HIGH,
+};
+
/* sgtl5000 private structure in codec */
struct sgtl5000_priv {
int sysclk; /* sysclk rate */
@@ -129,6 +136,7 @@ struct sgtl5000_priv {
u8 micbias_resistor;
u8 micbias_voltage;
u8 lrclk_strength;
+ u8 sclk_strength;
};
/*
@@ -1302,7 +1310,9 @@ static int sgtl5000_probe(struct snd_soc_component
*component)
SGTL5000_DAC_MUTE_RIGHT |
SGTL5000_DAC_MUTE_LEFT);
- reg = ((sgtl5000->lrclk_strength) << SGTL5000_PAD_I2S_LRCLK_SHIFT |
0x5f);
+ reg = ((sgtl5000->lrclk_strength) << SGTL5000_PAD_I2S_LRCLK_SHIFT |
+ (sgtl5000->sclk_strength) << SGTL5000_PAD_I2S_SCLK_SHIFT |
+ 0x1f);
snd_soc_component_write(component, SGTL5000_CHIP_PAD_STRENGTH, reg);
snd_soc_component_write(component, SGTL5000_CHIP_ANA_CTRL,
@@ -1542,6 +1552,13 @@ static int sgtl5000_i2c_probe(struct i2c_client *client,
sgtl5000->lrclk_strength = value;
}
+ sgtl5000->sclk_strength = I2S_SCLK_STRENGTH_LOW;
+ if (!of_property_read_u32(np, "sclk-strength", )) {
+ if (value > I2S_SCLK_STRENGTH_HIGH)
+ value = I2S_SCLK_STRENGTH_LOW;
+ sgtl5000->sclk_strength = value;
+ }
+
/* Ensure sgtl5000 will start with sane register values */
sgtl5000_fill_defaults(client);
--
1.7.1
[PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
When KASLR enaled(CONFIG_RANDOMIZE_BASE=y), the top 4K virtual
address have chance to be mapped to physical address, but which
is expected to leave room for ERR_PTR.
Also, it might cause some other warparound issue when somewhere
use the last memory page but no overflow check. Such as the last
page compressed by LZO:
[ 2738.034508] Unable to handle kernel NULL pointer dereference at virtual
address 0009
[ 2738.034515] Mem abort info:
[ 2738.034518] Exception class = DABT (current EL), IL = 32 bits
[ 2738.034520] SET = 0, FnV = 0
[ 2738.034523] EA = 0, S1PTW = 0
[ 2738.034524] FSC = 5
[ 2738.034526] Data abort info:
[ 2738.034528] ISV = 0, ISS = 0x0005
[ 2738.034530] CM = 0, WnR = 0
[ 2738.034533] user pgtable: 4k pages, 39-bit VAs, pgd = 94cee000
[ 2738.034535] [0009] *pgd=, *pud=
...
[ 2738.034592] pc : lzo1x_1_do_compress+0x198/0x610
[ 2738.034595] lr : lzo1x_1_compress+0x98/0x3d8
[ 2738.034597] sp : ff801caa3470 pstate : 00c00145
[ 2738.034598] x29: ff801caa3500 x28: 1000
[ 2738.034601] x27: 1000 x26: f000
[ 2738.034604] x25: 4ebc x24:
[ 2738.034607] x23: 004c x22: f7b8
[ 2738.034610] x21: 2e2ee0b3 x20: 2e2ee0bb
[ 2738.034612] x19: 0fcc x18: f84a
[ 2738.034615] x17: 801b03d6 x16: 0782
[ 2738.034618] x15: 2e2ee0bf x14: fff0
[ 2738.034620] x13: 000f x12: 0020
[ 2738.034623] x11: 1824429d x10: ffec
[ 2738.034626] x9 : 0009 x8 :
[ 2738.034628] x7 : 0868 x6 : 0434
[ 2738.034631] x5 : 4ebc x4 :
[ 2738.034633] x3 : ff801caa3510 x2 : 2e2ee000
[ 2738.034636] x1 : x0 : f000
...
[ 2738.034717] Process kworker/u16:1 (pid: 8705, stack limit =
0xff801caa)
[ 2738.034720] Call trace:
[ 2738.034722] lzo1x_1_do_compress+0x198/0x610
[ 2738.034725] lzo_compress+0x48/0x88
[ 2738.034729] crypto_compress+0x14/0x20
[ 2738.034733] zcomp_compress+0x2c/0x38
[ 2738.034736] zram_bvec_rw+0x3d0/0x860
[ 2738.034738] zram_rw_page+0x88/0xe0
[ 2738.034742] bdev_write_page+0x70/0xc0
[ 2738.034745] __swap_writepage+0x58/0x3f8
[ 2738.034747] swap_writepage+0x40/0x50
[ 2738.034750] shrink_page_list+0x4fc/0xe58
[ 2738.034753] reclaim_pages_from_list+0xa0/0x150
[ 2738.034756] reclaim_pte_range+0x18c/0x1f8
[ 2738.034759] __walk_page_range+0xf8/0x1e0
[ 2738.034762] walk_page_range+0xf8/0x130
[ 2738.034765] reclaim_task_anon+0xcc/0x168
[ 2738.034767] swap_fn+0x438/0x668
[ 2738.034771] process_one_work+0x1fc/0x460
[ 2738.034773] worker_thread+0x2d0/0x478
[ 2738.034775] kthread+0x110/0x120
[ 2738.034778] ret_from_fork+0x10/0x18
[ 2738.034781] Code: 3800167f 54a8 d100066f 1431 (b9400131)
[ 2738.034784] ---[ end trace 9b5cca106f0e54d1 ]---
[ 2738.035473] Kernel panic - not syncing: Fatal exception
in = 0xf000
in_len = 4096
ip = x9 = 0x0009 overflowed.
Always leave room the last size of ARM64_MEMSTART_ALIGN region
in linear region.
Signed-off-by: liyueyi
---
arch/arm64/mm/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 0340e45..20fe11e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -439,7 +439,8 @@ void __init arm64_memblock_init(void)
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
extern u16 memstart_offset_seed;
u64 range = linear_region_size -
- (memblock_end_of_DRAM() - memblock_start_of_DRAM());
+ (memblock_end_of_DRAM() - memblock_start_of_DRAM()) -
+ ARM64_MEMSTART_ALIGN;
/*
* If the size of the linear region exceeds, by a sufficient
--
2.7.4
Re: [PATCH] mlxsw: spectrum_acl_bloom_filter: use struct_size() in kzalloc()
On Sun, Dec 23, 2018 at 11:27:41PM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Ido Schimmel
But net-next is closed (http://vger.kernel.org/~davem/net-next.html) and
this isn't a bug fix. Can you please re-submit when net-next opens
again? Alternatively, I can apply the patch to my mlxsw queue and submit
in your stead. Let me know what you prefer.
Thanks!
GOLD BARS FOR SALES
I am Patrick Kaba from Ghana.I am looking for buyers for my Gold Bars. I have 50kgs of Gold Bars to sell to any company and person. Is 22 Carat plus and the price is 28000 Usd/kG the broker commission is 1500 USD:KG.I can deliver this to your final destination. Europe, Dubai, Singapore, China, Hongkong, South Africa, Usa. I will take care of the shipment cost to your final destination. I will need your full address details to communicate with you to arrange the deal. NB. I will bring the Gold to meet you myself to your city or country of destination. Regard, Patrick Kaba.
Re: [PATCH] clk: rockchip: fix frac settings of GPLL clock for rk3328
Hi,
Am Samstag, 22. Dezember 2018, 17:42:49 CET schrieb Katsuhiro Suzuki:
> This patch fixes settings of GPLL frequency in fractional mode for
> rk3328. In this mode, FOUTVCO is calcurated by following formula:
> FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24)
>
> The problem is in FREF * FRAC >> 24 term. This result always lacks
> one from target value is specified by rate member. For example first
> itme of rk3328_pll_frac_rate originally has
> - rate : 1016064000
> - refdiv: 3
> - fbdiv : 127
> - frac : 134217
> - FREF * FBDIV / REFDIV= 101600
> - (FREF * FRAC / REFDIV) >> 24 = 63999
> Thus calculated rate is 1016063999. It seems wrong.
>
> If frac has 134218 (it is increased 1 from original value), second
> term is 64000. All other items have same situation. So this patch
> adds 1 to frac member in all items of rk3328_pll_frac_rate.
>
> Signed-off-by: Katsuhiro Suzuki
so while this sounds all quite right to me, I've added some Rockchip
people that have clock experience to hopefully get an Ack on the
change :-)
@Elaine + Finley: does this explanation and the below change look right?
Thanks
Heiko
> ---
> drivers/clk/rockchip/clk-rk3328.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3328.c
> b/drivers/clk/rockchip/clk-rk3328.c
> index faa94adb2a37..65ab5c2f48b0 100644
> --- a/drivers/clk/rockchip/clk-rk3328.c
> +++ b/drivers/clk/rockchip/clk-rk3328.c
> @@ -78,17 +78,17 @@ static struct rockchip_pll_rate_table rk3328_pll_rates[]
> = {
>
> static struct rockchip_pll_rate_table rk3328_pll_frac_rates[] = {
> /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
> - RK3036_PLL_RATE(1016064000, 3, 127, 1, 1, 0, 134217),
> + RK3036_PLL_RATE(1016064000, 3, 127, 1, 1, 0, 134218),
> /* vco = 1016064000 */
> - RK3036_PLL_RATE(98304, 24, 983, 1, 1, 0, 671088),
> + RK3036_PLL_RATE(98304, 24, 983, 1, 1, 0, 671089),
> /* vco = 98304 */
> - RK3036_PLL_RATE(49152, 24, 983, 2, 1, 0, 671088),
> + RK3036_PLL_RATE(49152, 24, 983, 2, 1, 0, 671089),
> /* vco = 98304 */
> - RK3036_PLL_RATE(6144, 6, 215, 7, 2, 0, 671088),
> + RK3036_PLL_RATE(6144, 6, 215, 7, 2, 0, 671089),
> /* vco = 860156000 */
> - RK3036_PLL_RATE(56448000, 12, 451, 4, 4, 0, 9797894),
> + RK3036_PLL_RATE(56448000, 12, 451, 4, 4, 0, 9797895),
> /* vco = 903168000 */
> - RK3036_PLL_RATE(4096, 12, 409, 4, 5, 0, 10066329),
> + RK3036_PLL_RATE(4096, 12, 409, 4, 5, 0, 10066330),
> /* vco = 81920 */
> { /* sentinel */ },
> };
>
Re: FYI: Userland breakage caused by udev bind commit
Am So., 23. Dez. 2018 um 19:09 Uhr schrieb Dmitry Torokhov
:
[ also added Linus to CC on that one too ]
>
> On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote:
> > On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote:
> > > Hi,
> > >
> > > I am the maintainer of libmtp and libgphoto2
> > >
> > > Some months ago I was made aware of this bug:
> > > https://bugs.kde.org/show_bug.cgi?id=387454
> > >
> > > This was fallout identified to come from this kernel commit:
> > >
> > > commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
> > > Author: Dmitry Torokhov
> > > Date: Wed Jul 19 17:24:30 2017 -0700
> >
> > Fwiw, the addition of {un}bind events has caused issues for
> > systemd-udevd as well and is tracked here:
> > https://github.com/systemd/systemd/issues/7587
> > I haven't been aware of this until yesterday and it seems that so far
> > this hasn't been brought up on lkml until you did now.
>
> The fallout was caused by premature enabling of the new events in
> systemd/udev by yours truly (even though the commit has Lennart's name
> on it due to how it was merged):
>
> https://github.com/systemd/systemd/commit/9a39e1ce314d1a6f8a754f6dab040019239666a9
>
> "Add handling for bind/unbind actions (#6720)
>
> Newer kernels will emit uevents with "bind" and "unbind" actions. These
> uevents will be issued when driver is bound to or unbound from a device.
> "Bind" events are helpful when device requires a firmware to operate
> properly, and driver is unable to create a child device before firmware
> is properly loaded.
>
> For some reason systemd validates actions and drops the ones it does not
> know, instead of passing them on through as old udev did, so we need to
> explicitly teach it about them."
>
> Similarly it is now papered over in systemd/udev until we make it
> properly handle new events:
>
> https://github.com/systemd/systemd/commit/56c886dc7ed5b2bb0882ba85136f4070545bfc1b
>
> "sd-device: ignore bind/unbind events for now
>
> Until systemd/udev are ready for the new events and do not flush entire
> device state on each new event received, we should ignore them."
>
And how about peoples still uses systemd < 235 and newer kernels ?
> > >
> > > If distributions would be using libmtp and libgphoto2 udev rules
> > > that just triggered on "add" events, and not the new "bind" events,
> > > the missing "attribute tagging" of the "bind" events would confused the
> > > KDE Solid device detection and make the devices no longer detected.
> > >
> > > This did not affect distributions that rely on the newer "hwdb"
> > > device detection method.
> > >
> > > I have released fixed libmtp and libgphoto2 versions in November, so
> > > this is under control, but wanted to bring this up as a "kernel caused
> > > userland breakage".
>
> Given that we explicitly enabled these new events in systemd/udev code
> this is actually "userspace caused userspace breakage" case.
I really do not agree with you here .. Is kernel -> userspace breakage
and while userspace is trying to workaround even much more breaks.
>
> Still it is unfortunate that we did nit notice that my patch enabling
> this functionality in systemd was premature.
>
> Thanks.
>
> --
> Dmitry
BR,
Gabriel
[PATCH] thermal: generic-adc: Fix adc to temp interpolation
First correct the edge case to return the last element if we're
outside the range, rather than at the last element, so that
interpolation is not omitted for points between the two last entries in
the table.
Then correct the formula to perform linear interpolation based the two
points surrounding the read ADC value. The indices for temp are kept as
"hi" and "lo" to pair with the adc indices, but there's no requirement
that the temperature is provided in descendent order. mult_frac() is
used to prevent issues with overflowing the int.
Cc: Laxman Dewangan
Signed-off-by: Bjorn Andersson
---
drivers/thermal/thermal-generic-adc.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal-generic-adc.c
b/drivers/thermal/thermal-generic-adc.c
index bf1c628d4a7a..e22fc60ad36d 100644
--- a/drivers/thermal/thermal-generic-adc.c
+++ b/drivers/thermal/thermal-generic-adc.c
@@ -26,7 +26,7 @@ struct gadc_thermal_info {
static int gadc_thermal_adc_to_temp(struct gadc_thermal_info *gti, int val)
{
- int temp, adc_hi, adc_lo;
+ int temp, temp_hi, temp_lo, adc_hi, adc_lo;
int i;
for (i = 0; i < gti->nlookup_table; i++) {
@@ -36,13 +36,17 @@ static int gadc_thermal_adc_to_temp(struct
gadc_thermal_info *gti, int val)
if (i == 0) {
temp = gti->lookup_table[0];
- } else if (i >= (gti->nlookup_table - 1)) {
+ } else if (i >= gti->nlookup_table) {
temp = gti->lookup_table[2 * (gti->nlookup_table - 1)];
} else {
adc_hi = gti->lookup_table[2 * i - 1];
adc_lo = gti->lookup_table[2 * i + 1];
- temp = gti->lookup_table[2 * i];
- temp -= ((val - adc_lo) * 1000) / (adc_hi - adc_lo);
+
+ temp_hi = gti->lookup_table[2 * i - 2];
+ temp_lo = gti->lookup_table[2 * i];
+
+ temp = temp_hi + mult_frac(temp_lo - temp_hi, val - adc_hi,
+ adc_lo - adc_hi);
}
return temp;
--
2.18.0
[PATCH 1/2] lib/genalloc.c: Use the vzalloc_node to allocate the bitmap.
Some devices may have over 1G memory on chip. In some cases, the nbytes may big then 4M which is the bounday of the memory buddy system. So use vzalloc_node() to allocate the bitmap. Signed-off-by: Huang Shijie --- lib/genalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/genalloc.c b/lib/genalloc.c index 5deb25c40a5a..0d0ff9f0483f 100644 --- a/lib/genalloc.c +++ b/lib/genalloc.c @@ -187,7 +187,7 @@ int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt, phys_addr_t phy int nbytes = sizeof(struct gen_pool_chunk) + BITS_TO_LONGS(nbits) * sizeof(long); - chunk = kzalloc_node(nbytes, GFP_KERNEL, nid); + chunk = vzalloc_node(nbytes, nid); if (unlikely(chunk == NULL)) return -ENOMEM; -- 2.17.1
[PATCH 2/2] lib/genalloc.c: export symbol addr_in_gen_pool
We may use the addr_in_gen_pool() in the driver module. So export the addr_in_gen_pool for the compiling. Signed-off-by: Huang Shijie --- lib/genalloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/genalloc.c b/lib/genalloc.c index 0d0ff9f0483f..9da91a16046f 100644 --- a/lib/genalloc.c +++ b/lib/genalloc.c @@ -450,6 +450,7 @@ bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start, rcu_read_unlock(); return found; } +EXPORT_SYMBOL(addr_in_gen_pool); /** * gen_pool_avail - get available free space of the pool -- 2.17.1
[PATCH] sched/cpufreq: calculate util / max firstly in get_next_freq()
From: Vincent Wang When a task that is in_iowait state is enqueued, cpufreq_update_util() will be invoked with SCHED_CPUFREQ_IOWAIT flag. In this case,the value of util and max, which are parameters used in get_next_freq(), will be cpu frequency, instead of cpu util or capactiy. For some 32bit architectures, the size of unsigned long is 32. When calculating freq, there may be an overflow error in this expression: freq = (freq + (freq >> 2)) * util / max; This patch will fix this overflow risk by calulating util / max firstly, whether they be frequency or util. Signed-off-by: Vincent Wang Signed-off-by: Chunyan Zhang --- kernel/sched/cpufreq_schedutil.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 3fffad3..7c372db1 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -166,8 +166,9 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, struct cpufreq_policy *policy = sg_policy->policy; unsigned int freq = arch_scale_freq_invariant() ? policy->cpuinfo.max_freq : policy->cur; + unsigned int ratio = util * 100 / max; - freq = (freq + (freq >> 2)) * util / max; + freq = (freq + (freq >> 2)) * ratio / 100; if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update) return sg_policy->next_freq; -- 2.7.4
Re: [PATCH] usb: dwc2: gadget: fix ISOC frame overflow handling
Hi John,
On 12/21/2018 8:05 PM, John Keeping wrote:
> Hi Minas,
>
> On Wed, 19 Dec 2018 14:09:01 +
> Minas Harutyunyan wrote:
>
>> On 12/18/2018 6:35 PM, John Keeping wrote:
>>> Hi Minas,
>>>
>>> On Fri, 14 Dec 2018 09:00:08 +
>>> Minas Harutyunyan wrote:
First of all, sorry for delayed answer.
Looks like similar issue seen by Andrzej Pietrasiewicz
: "dwc2 isochronous transfers issues". Same
feedback provided to Andrzej.
I run tests on 4.20.0-rc4 in DDMA. By default IN ISOC traffic
failed because of BNA interrupts. It's happen because UAC2
requests count set by default to 2. Our core and driver can't work
in DDMA with descriptor list length equal to 2. It's not possible
on time prepare next descriptors to avoid BNA interrupt.
By changing UAC2_DEF_REQ_NUM to 4 all audio gadget tests passed
smoothly. Could you please apply this patch and run tests in DDMA
mode:
diff --git a/drivers/usb/gadget/function/u_uac2.h
b/drivers/usb/gadget/function/u_uac2.h
index 8362ee572e1e..5e649259ab76 100644
--- a/drivers/usb/gadget/function/u_uac2.h
+++ b/drivers/usb/gadget/function/u_uac2.h
@@ -21,7 +21,7 @@
#define UAC2_DEF_CCHMASK 0x3
#define UAC2_DEF_CSRATE 64000
#define UAC2_DEF_CSSIZE 2
-#define UAC2_DEF_REQ_NUM 2
+#define UAC2_DEF_REQ_NUM 4
struct f_uac2_opts {
struct usb_function_instancefunc_inst;
If it will OK on your side also then will switch to BDMA mode and
debug.
>>>
>>> With DDMA enabled, I see the following error after the stream has
>>> been running for a while (anything from a few seconds to a few
>>> minutes):
>>> -- >8 --
>>> [ 1798.836322] dwc2 ff58.usb: dwc2_hsotg_ep_disable: called for
>>> ep0 [ 1798.836329] dwc2 ff58.usb: dwc2_hsotg_ep_disable: called
>>> for ep0 [ 1798.851092] dwc2 ff58.usb: new device is high-speed
>>> [ 1798.924461] dwc2 ff58.usb: new device is high-speed
>>> [ 1798.982887] dwc2 ff58.usb: new address 25
>>> [ 1799.002463] configfs-gadget gadget: high-speed config #1: config
>>> -- 8< --
>>>
>>> On the host side (Linux 4.18.16 Intel xHCI), I see this logged at
>>> the same time:
>>>
>>> -- >8 --
>>> [1735740.716242] retire_capture_urb: usb 1-2.2.7: frame 0 active:
>>> -71 [1735740.716990] retire_capture_urb: usb 1-2.2.7: frame 0
>>> active: -71 [1735740.717906] retire_capture_urb: usb 1-2.2.7: frame
>>> 0 active: -71 [1735740.718905] retire_capture_urb: usb 1-2.2.7:
>>> frame 0 active: -71 [1735740.719916] retire_capture_urb: usb
>>> 1-2.2.7: frame 0 active: -71 [1735740.720032] usb 1-2.2-port7:
>>> disabled by hub (EMI?), re-enabling... [1735740.720036] usb
>>> 1-2.2.7: USB disconnect, device number 28 [1735740.937500] usb
>>> 1-2.2.7: new high-speed USB device number 29 using xhci_hcd -- 8< --
>>>
>>> The device does then enumerate and works for a period of time
>>> before the same error happens again.
>>>
>> From logs not clear who initiate disconnect: host or device. More
>> probably host, after some errors in retire_capture_urb initiate
>> disconnect. Do you have any idea?
>> Can't you connect device to host on same platform?
>> If root cause of disconnect by host is device issue, i.e. not able to
>> send to host data packets in time then I need device side dmesg log
>> with debug enabled. USB trace around the disconnect will help to
>> debug.
>
> I remember running a test with a hardware USB analyzer and which showed
> an isochronous packet with an incorrect length (much larger than it
> should have been) when the failure occurred.
>
> I don't have any logs from that test and I'm out of the office at the
> moment, but I will capture logs when I'm back in January.
I think, if you enable debug prints, you will see BNA interrupts. So, my
recommendation is to increase more UAC2_DEF_REQ_NUM until BNA will
disappear. Per me value of UAC2_DEF_REQ_NUM is platform's latency dependent.
Thanks,
Minas
>
>
> Thanks,
> John
>
Re: [PATCH] arm64: dts: rockchip: enable analog audio node for rock64
Hi, Am Sonntag, 23. Dezember 2018, 11:10:26 CET schrieb Katsuhiro Suzuki: > The Rock64 boards has analog audio jack on it. RK3328 can output > analog audio signal using I2S1 and ACODEC core. > > This patch adds sound node for analog audio for Rock64. > > Signed-off-by: Katsuhiro Suzuki I've put a patch collecting the sound-dai-cells in rk3328.dtsi before this one, dropped the sound-dai-cells from here and applied the patch for 4.22. Thanks Heiko
[PATCH v4 0/2] spi: Add Renesas R-Car Gen3 RPC SPI driver
Hi Mark, This Renesas R-Car Gen3 RPC SPI driver is based on Boris's new spi-mem direct mapping read/write mode [1][2]. v4 patch is according to Sergei's comments including: 1) Drop soc_device_match() 2) Drop unused RPC registers 3) Use ilog2() instead of fls() 4) Patch read 6 bytes ID w/ one command. 5) Coding style and so on. v3 patch is according to Marek and Geert's comments including: 1) soc_device_mach() to set up RPC_PHYCNT_STRTIM. 2) get_unaligned() 3) rpc-mode for rpi-spi-flash or rpc-hyperflash. 4) coding style and so on. v2 patch including: 1) remove RPC clock enable/dis-able control, 2) patch run time PM, 3) add RPC module software reset, 4) add regmap, 5) other coding style and so on. thanks for your review. best regards, Mason [1] https://patchwork.kernel.org/patch/10670753 [2] https://patchwork.kernel.org/patch/10670747 Mason Yang (2): spi: Add Renesas R-Car Gen3 RPC SPI controller driver dt-bindings: spi: Document Renesas R-Car Gen3 RPC controller bindings .../devicetree/bindings/spi/spi-renesas-rpc.txt| 37 + drivers/spi/Kconfig| 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 788 + 4 files changed, 832 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt create mode 100644 drivers/spi/spi-renesas-rpc.c -- 1.9.1
[PATCH v4 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC controller bindings
Document the bindings used by the Renesas R-Car Gen3 RPC controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/spi/spi-renesas-rpc.txt| 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
new file mode 100644
index 000..ba863d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
@@ -0,0 +1,37 @@
+Renesas R-Car Gen3 RPC controller Device Tree Bindings
+--
+
+Required properties:
+- compatible: should be "renesas,r8a77995-rpc"
+- #address-cells: should be 1
+- #size-cells: should be 0
+- reg: should contain 2 entries, one for the registers and one for the direct
+ mapping area
+- reg-names: should contain "regs" and "dirmap"
+- clock-names: should contain "rpc"
+- clocks: should contain 1 entries for the module's clock
+- renesas,rpc-mode: should contain "spi" for rpc spi mode or
+ "hyperflash" for rpc hyerflash mode.
+
+Example:
+
+ rpc: rpc@ee20 {
+ compatible = "renesas,r8a77995-rpc";
+ reg = <0 0xee20 0 0x8100>, <0 0x0800 0 0x400>;
+ reg-names = "regs", "dirmap";
+ clocks = < CPG_MOD 917>;
+ power-domains = < R8A77995_PD_ALWAYS_ON>;
+ resets = < 917>;
+ clock-names = "rpc";
+ renesas,rpc-mode = "spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+ };
--
1.9.1
[PATCH v4 1/2] spi: Add Renesas R-Car Gen3 RPC SPI controller driver
Add a driver for Renesas R-Car Gen3 RPC SPI controller. Signed-off-by: Mason Yang --- drivers/spi/Kconfig | 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 788 ++ 3 files changed, 795 insertions(+) create mode 100644 drivers/spi/spi-renesas-rpc.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7d3a5c9..54b40f8 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -528,6 +528,12 @@ config SPI_RSPI help SPI driver for Renesas RSPI and QSPI blocks. +config SPI_RENESAS_RPC + tristate "Renesas R-Car Gen3 RPC SPI controller" + depends on ARCH_RENESAS || COMPILE_TEST + help + SPI driver for Renesas R-Car Gen3 RPC. + config SPI_QCOM_QSPI tristate "QTI QSPI controller" depends on ARCH_QCOM diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 3575205..5d5c523 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -81,6 +81,7 @@ obj-$(CONFIG_SPI_QUP) += spi-qup.o obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o obj-$(CONFIG_SPI_RB4XX)+= spi-rb4xx.o obj-$(CONFIG_SPI_RSPI) += spi-rspi.o +obj-$(CONFIG_SPI_RENESAS_RPC) += spi-renesas-rpc.o obj-$(CONFIG_SPI_S3C24XX) += spi-s3c24xx-hw.o spi-s3c24xx-hw-y := spi-s3c24xx.o spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o diff --git a/drivers/spi/spi-renesas-rpc.c b/drivers/spi/spi-renesas-rpc.c new file mode 100644 index 000..6dd739a --- /dev/null +++ b/drivers/spi/spi-renesas-rpc.c @@ -0,0 +1,788 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp. +// Copyright (C) 2018 Macronix International Co., Ltd. +// +// R-Car Gen3 RPC SPI/QSPI/Octa driver +// +// Authors: +// Mason Yang +// + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define RPC_CMNCR 0x /* R/W */ +#define RPC_CMNCR_MD BIT(31) +#define RPC_CMNCR_SFDE BIT(24) /* undocumented bit but must be set */ +#define RPC_CMNCR_MOIIO3(val) (((val) & 0x3) << 22) +#define RPC_CMNCR_MOIIO2(val) (((val) & 0x3) << 20) +#define RPC_CMNCR_MOIIO1(val) (((val) & 0x3) << 18) +#define RPC_CMNCR_MOIIO0(val) (((val) & 0x3) << 16) +#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \ +RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3)) +#define RPC_CMNCR_IO3FV(val) (((val) & 0x3) << 14) +#define RPC_CMNCR_IO2FV(val) (((val) & 0x3) << 12) +#define RPC_CMNCR_IO0FV(val) (((val) & 0x3) << 8) +#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \ +RPC_CMNCR_IO3FV(3)) +#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0) + +#define RPC_SSLDR 0x0004 /* R/W */ +#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16) +#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8) +#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0) + +#define RPC_DRCR 0x000C /* R/W */ +#define RPC_DRCR_SSLN BIT(24) +#define RPC_DRCR_RBURST(v) v) - 1) & 0x1F) << 16) +#define RPC_DRCR_RCF BIT(9) +#define RPC_DRCR_RBE BIT(8) +#define RPC_DRCR_SSLE BIT(0) + +#define RPC_DRCMR 0x0010 /* R/W */ +#define RPC_DRCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_DRCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_DREAR 0x0014 /* R/W */ +#define RPC_DREAR_EAC(c) (((c) & 0x7) << 0) + +#define RPC_DROPR 0x0018 /* R/W */ + +#define RPC_DRENR 0x001C /* R/W */ +#define RPC_DRENR_CDB(o) (u32)o) & 0x3) << 30)) +#define RPC_DRENR_OCDB(o) (((o) & 0x3) << 28) +#define RPC_DRENR_ADB(o) (((o) & 0x3) << 24) +#define RPC_DRENR_OPDB(o) (((o) & 0x3) << 20) +#define RPC_DRENR_SPIDB(o) (((o) & 0x3) << 16) +#define RPC_DRENR_DME BIT(15) +#define RPC_DRENR_CDE BIT(14) +#define RPC_DRENR_OCDE BIT(12) +#define RPC_DRENR_ADE(v) (((v) & 0xF) << 8) +#define RPC_DRENR_OPDE(v) (((v) & 0xF) << 4) + +#define RPC_SMCR 0x0020 /* R/W */ +#define RPC_SMCR_SSLKP BIT(8) +#define RPC_SMCR_SPIRE BIT(2) +#define RPC_SMCR_SPIWE BIT(1) +#define RPC_SMCR_SPIE BIT(0) + +#define RPC_SMCMR 0x0024 /* R/W */ +#define RPC_SMCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_SMCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_SMADR 0x0028 /* R/W */ +#define RPC_SMOPR 0x002C /* R/W */ +#define RPC_SMOPR_OPD3(o) (((o) & 0xFF) << 24) +#define RPC_SMOPR_OPD2(o) (((o) & 0xFF) << 16) +#define RPC_SMOPR_OPD1(o) (((o) & 0xFF) << 8) +#define RPC_SMOPR_OPD0(o) (((o) & 0xFF) << 0) + +#define RPC_SMENR 0x0030 /* R/W */
[PATCH] dmaengine: dma-jz4780: Use struct_size() in devm_kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count,
GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL);
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/dma/dma-jz4780.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c
index a8b6225faa12..9ce0a386225b 100644
--- a/drivers/dma/dma-jz4780.c
+++ b/drivers/dma/dma-jz4780.c
@@ -838,9 +838,8 @@ static int jz4780_dma_probe(struct platform_device *pdev)
if (!soc_data)
return -EINVAL;
- jzdma = devm_kzalloc(dev, sizeof(*jzdma)
- + sizeof(*jzdma->chan) * soc_data->nb_channels,
- GFP_KERNEL);
+ jzdma = devm_kzalloc(dev, struct_size(jzdma, chan,
+soc_data->nb_channels), GFP_KERNEL);
if (!jzdma)
return -ENOMEM;
--
2.20.1
Re: [PATCH v2] f2fs: rebuild nat_bits during umount
On 2018/12/13 16:50, Chao Yu wrote:
> If all free_nat_bitmap are available, we can rebuild nat_bits from
> free_nat_bitmap entirely during umount, let's make another chance
> to reenable nat_bits for image.
Jaegeuk,
Could you please have a try with this patch?
I just did xfstest on it with below method, and there is no data corruption
reported from fsck:
- let fill_super preload all NAT blocks to enable free_nid_bitmap entirely.
- don't add nat_bits during mkfs image.
Thanks,
>
> Signed-off-by: Chao Yu
> ---
> v2:
> - fix bugs in f2fs_enable_nat_bits()
> - add kmsg to record nat_bits {en,dis}abling operations
> - fix to validate {full,empty}_nat_bits in __get_nat_bitmaps()
>
> fs/f2fs/checkpoint.c | 20 +---
> fs/f2fs/f2fs.h | 21 ++---
> fs/f2fs/node.c | 72 +++-
> 3 files changed, 82 insertions(+), 31 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 623536b8e0c0..fa0eb56f1703 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -1225,12 +1225,22 @@ static void update_ckpt_flags(struct f2fs_sb_info
> *sbi, struct cp_control *cpc)
> struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
> unsigned long flags;
>
> - spin_lock_irqsave(>cp_lock, flags);
> + if (cpc->reason & CP_UMOUNT) {
> + if (le32_to_cpu(ckpt->cp_pack_total_block_count) >
> + sbi->blocks_per_seg - NM_I(sbi)->nat_bits_blocks) {
> + clear_ckpt_flags(sbi, CP_NAT_BITS_FLAG);
> + f2fs_msg(sbi->sb, KERN_NOTICE,
> + "Disable nat_bits due to no space");
> + } else if (!is_set_ckpt_flags(sbi, CP_NAT_BITS_FLAG) &&
> + f2fs_nat_bitmap_enabled(sbi)) {
> + f2fs_enable_nat_bits(sbi);
> + set_ckpt_flags(sbi, CP_NAT_BITS_FLAG);
> + f2fs_msg(sbi->sb, KERN_NOTICE,
> + "Rebuild and enable nat_bits");
> + }
> + }
>
> - if ((cpc->reason & CP_UMOUNT) &&
> - le32_to_cpu(ckpt->cp_pack_total_block_count) >
> - sbi->blocks_per_seg - NM_I(sbi)->nat_bits_blocks)
> - disable_nat_bits(sbi, false);
> + spin_lock_irqsave(>cp_lock, flags);
>
> if (cpc->reason & CP_TRIMMED)
> __set_ckpt_flags(ckpt, CP_TRIMMED_FLAG);
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 7cec897146a3..869a36b6a28f 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1618,25 +1618,6 @@ static inline void clear_ckpt_flags(struct
> f2fs_sb_info *sbi, unsigned int f)
> spin_unlock_irqrestore(>cp_lock, flags);
> }
>
> -static inline void disable_nat_bits(struct f2fs_sb_info *sbi, bool lock)
> -{
> - unsigned long flags;
> -
> - /*
> - * In order to re-enable nat_bits we need to call fsck.f2fs by
> - * set_sbi_flag(sbi, SBI_NEED_FSCK). But it may give huge cost,
> - * so let's rely on regular fsck or unclean shutdown.
> - */
> -
> - if (lock)
> - spin_lock_irqsave(>cp_lock, flags);
> - __clear_ckpt_flags(F2FS_CKPT(sbi), CP_NAT_BITS_FLAG);
> - kfree(NM_I(sbi)->nat_bits);
> - NM_I(sbi)->nat_bits = NULL;
> - if (lock)
> - spin_unlock_irqrestore(>cp_lock, flags);
> -}
> -
> static inline bool enabled_nat_bits(struct f2fs_sb_info *sbi,
> struct cp_control *cpc)
> {
> @@ -2952,6 +2933,7 @@ int f2fs_truncate_inode_blocks(struct inode *inode,
> pgoff_t from);
> int f2fs_truncate_xattr_node(struct inode *inode);
> int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info *sbi,
> unsigned int seq_id);
> +bool f2fs_nat_bitmap_enabled(struct f2fs_sb_info *sbi);
> int f2fs_remove_inode_page(struct inode *inode);
> struct page *f2fs_new_inode_page(struct inode *inode);
> struct page *f2fs_new_node_page(struct dnode_of_data *dn, unsigned int ofs);
> @@ -2975,6 +2957,7 @@ int f2fs_recover_xattr_data(struct inode *inode, struct
> page *page);
> int f2fs_recover_inode_page(struct f2fs_sb_info *sbi, struct page *page);
> int f2fs_restore_node_summary(struct f2fs_sb_info *sbi,
> unsigned int segno, struct f2fs_summary_block *sum);
> +void f2fs_enable_nat_bits(struct f2fs_sb_info *sbi);
> int f2fs_flush_nat_entries(struct f2fs_sb_info *sbi, struct cp_control *cpc);
> int f2fs_build_node_manager(struct f2fs_sb_info *sbi);
> void f2fs_destroy_node_manager(struct f2fs_sb_info *sbi);
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 30a4427aaa94..9f55f2cb0dff 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -2036,6 +2036,24 @@ static void __move_free_nid(struct f2fs_sb_info *sbi,
> struct free_nid *i,
> }
> }
>
> +bool f2fs_nat_bitmap_enabled(struct f2fs_sb_info *sbi)
> +{
> + struct f2fs_nm_info *nm_i = NM_I(sbi);
>
[PATCH] clk: imx: imx7ulp: use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/clk/imx/clk-imx7ulp.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 4e18f629f823..ce306631e844 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -48,8 +48,8 @@ static void __init imx7ulp_clk_scg1_init(struct device_node
*np)
struct clk_hw **clks;
void __iomem *base;
- clk_data = kzalloc(sizeof(*clk_data) + sizeof(*clk_data->hws) *
- IMX7ULP_CLK_SCG1_END, GFP_KERNEL);
+ clk_data = kzalloc(struct_size(clk_data, hws, IMX7ULP_CLK_SCG1_END),
+ GFP_KERNEL);
if (!clk_data)
return;
@@ -136,8 +136,8 @@ static void __init imx7ulp_clk_pcc2_init(struct device_node
*np)
struct clk_hw **clks;
void __iomem *base;
- clk_data = kzalloc(sizeof(*clk_data) + sizeof(*clk_data->hws) *
- IMX7ULP_CLK_PCC2_END, GFP_KERNEL);
+ clk_data = kzalloc(struct_size(clk_data, hws, IMX7ULP_CLK_PCC2_END),
+ GFP_KERNEL);
if (!clk_data)
return;
@@ -183,8 +183,8 @@ static void __init imx7ulp_clk_pcc3_init(struct device_node
*np)
struct clk_hw **clks;
void __iomem *base;
- clk_data = kzalloc(sizeof(*clk_data) + sizeof(*clk_data->hws) *
- IMX7ULP_CLK_PCC3_END, GFP_KERNEL);
+ clk_data = kzalloc(struct_size(clk_data, hws, IMX7ULP_CLK_PCC3_END),
+ GFP_KERNEL);
if (!clk_data)
return;
@@ -228,8 +228,8 @@ static void __init imx7ulp_clk_smc1_init(struct device_node
*np)
struct clk_hw **clks;
void __iomem *base;
- clk_data = kzalloc(sizeof(*clk_data) + sizeof(*clk_data->hws) *
- IMX7ULP_CLK_SMC1_END, GFP_KERNEL);
+ clk_data = kzalloc(struct_size(clk_data, hws, IMX7ULP_CLK_SMC1_END),
+ GFP_KERNEL);
if (!clk_data)
return;
--
2.20.1
Re: [PATCH v3] f2fs: add bio cache for IPU
Jaegeuk,
Will kernel still hang with this v3?
Thanks,
On 2018/12/19 17:29, Chao Yu wrote:
> SQLite in Wal mode may trigger sequential IPU write in db-wal file, after
> commit d1b3e72d5490 ("f2fs: submit bio of in-place-update pages"), we
> lost the chance of merging page in inner managed bio cache, result in
> submitting more small-sized IO.
>
> So let's add temporary bio in writepages() to cache mergeable write IO as
> much as possible.
>
> Test case:
> 1. xfs_io -f /mnt/f2fs/file -c "pwrite 0 65536" -c "fsync"
> 2. xfs_io -f /mnt/f2fs/file -c "pwrite 0 65536" -c "fsync"
>
> Before:
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65544, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65552, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65560, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65568, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65576, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65584, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65592, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65600, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65608, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65616, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65624, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65632, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65640, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65648, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65656, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65664, size = 4096
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), NODE, sector =
> 57352, size = 4096
>
> After:
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), DATA, sector =
> 65544, size = 65536
> f2fs_submit_write_bio: dev = (251,0)/(251,0), rw = WRITE(S), NODE, sector =
> 57368, size = 4096
>
> Signed-off-by: Chao Yu
> ---
> v3:
> - introduce f2fs_submit_ipu_bio() to check page Writeback status.
> fs/f2fs/data.c| 85 ++-
> fs/f2fs/f2fs.h| 3 ++
> fs/f2fs/segment.c | 5 ++-
> 3 files changed, 84 insertions(+), 9 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index cdfe9a7b856e..e5cd3fd9e215 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -341,20 +341,20 @@ static void __submit_merged_bio(struct f2fs_bio_info
> *io)
> io->bio = NULL;
> }
>
> -static bool __has_merged_page(struct f2fs_bio_info *io, struct inode *inode,
> +static bool __has_merged_page(struct bio *bio, struct inode *inode,
> struct page *page, nid_t ino)
> {
> struct bio_vec *bvec;
> struct page *target;
> int i;
>
> - if (!io->bio)
> + if (!bio)
> return false;
>
> if (!inode && !page && !ino)
> return true;
>
> - bio_for_each_segment_all(bvec, io->bio, i) {
> + bio_for_each_segment_all(bvec, bio, i) {
>
> if (bvec->bv_page->mapping)
> target = bvec->bv_page;
> @@ -405,7 +405,7 @@ static void __submit_merged_write_cond(struct
> f2fs_sb_info *sbi,
> struct f2fs_bio_info *io = sbi->write_io[btype] + temp;
>
> down_read(>io_rwsem);
> - ret = __has_merged_page(io, inode, page, ino);
> + ret = __has_merged_page(io->bio, inode, page, ino);
> up_read(>io_rwsem);
> }
> if (ret)
> @@ -474,6 +474,59 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
> return 0;
> }
>
> +int f2fs_merge_page_bio(struct f2fs_io_info *fio)
> +{
> + struct bio *bio = *fio->bio;
> + struct page *page = fio->encrypted_page ?
> + fio->encrypted_page : fio->page;
> +
> + if (!f2fs_is_valid_blkaddr(fio->sbi, fio->new_blkaddr,
> + __is_meta_io(fio) ? META_GENERIC : DATA_GENERIC))
> + return -EFAULT;
> +
> + trace_f2fs_submit_page_bio(page, fio);
> + f2fs_trace_ios(fio, 0);
> +
> + if (bio && (*fio->last_block + 1 != fio->new_blkaddr ||
> + !__same_bdev(fio->sbi, fio->new_blkaddr, bio))) {
> + __submit_bio(fio->sbi, bio, fio->type);
> + bio = NULL;
> + }
> +alloc_new:
> + if (!bio) {
Re: [PATCH 08/20] xfs: xfs_buf: drop useless LIST_HEAD
On Sun, 23 Dec 2018, Darrick J. Wong wrote:
> On Sun, Dec 23, 2018 at 09:57:03AM +0100, Julia Lawall wrote:
> > Drop LIST_HEAD where the variable it declares has never
> > been used.
> >
> > The semantic patch that fixes this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > //
> > @@
> > identifier x;
> > @@
> > - LIST_HEAD(x);
> > ... when != x
> > //
> >
> > Fixes: 26f1fe858f274 ("xfs: reduce lock hold times in buffer writeback")
> > Signed-off-by: Julia Lawall
>
> Looks ok; are you planning to push this whole series directly to Linus
> or do you want me to take the two xfs patches through?
Please take them. Thanks.
julia
>
> Reviewed-by: Darrick J. Wong
>
> --D
>
> >
> > ---
> > Successfully 0-day tested on 151 configurations.
> >
> > fs/xfs/xfs_buf.c |1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> > index b21ea2ba768d..eedc5e0156ff 100644
> > --- a/fs/xfs/xfs_buf.c
> > +++ b/fs/xfs/xfs_buf.c
> > @@ -1992,7 +1992,6 @@ xfs_buf_delwri_submit_buffers(
> > struct list_head*wait_list)
> > {
> > struct xfs_buf *bp, *n;
> > - LIST_HEAD (submit_list);
> > int pinned = 0;
> > struct blk_plug plug;
> >
> >
>
Re: [PATCH 2/2] mfd: tps65218.c: Add input voltage options
On Sun, 23 Dec 2018, Tony Lindgren wrote: > * Lee Jones [181221 11:01]: > > On Tue, 18 Dec 2018, Christian Hohnstaedt wrote: > > > > > These options apply to all regulators in this chip. > > > > > > strict-supply-voltage: > > > Set STRICT flag in CONFIG1 > > > under-voltage-limit: > > > Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1 > > > under-voltage-hysteresis: > > > Select 200mV or 400mV UVLOHYS in CONFIG2 > > > > > > Signed-off-by: Christian Hohnstaedt > > > --- > > > drivers/mfd/tps65218.c | 46 > > > ++ > > > 1 file changed, 46 insertions(+) > > > > This needs a close review by Tony and any of the other OMAP guys. > > Adding Keerthy to Cc, he's probably the best person to review these > changes. But you've dropped the patch, so all he has it a commit log to review? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH][trivial] fix email address quoting in MODULE_AUTHOR()
On Sun, 23 Dec 2018, Joe Perches wrote: > On Sun, 2018-12-23 at 20:27 +0100, Pavel Machek wrote: > > > > Apparently it is quite easy to forget ">" in quoting of email > > address. This fixes it. > > It's good you do this, thanks. > > Please use git diff --stat -p when you produce these > or git format-patch so there is an easy to read list > of files modified in this patch. `git format-patch` & `git send-email` is preferred. I would also suggest that you split this up into patch-per-subsystem set for easy merge, since there aren't *any* dependencies between them. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] drivers: qcom: rpmh: use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/soc/qcom/rpmh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index c7beb6841289..12c057a0b325 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -362,8 +362,7 @@ int rpmh_write_batch(const struct device *dev, enum
rpmh_state state,
if (!count)
return -EINVAL;
- req = kzalloc(sizeof(*req) + count * sizeof(req->rpm_msgs[0]),
- GFP_ATOMIC);
+ req = kzalloc(struct_size(req, rpm_msgs, count), GFP_ATOMIC);
if (!req)
return -ENOMEM;
req->count = count;
--
2.17.0
Re: [PATCH] arm64: dts: rockchip: add rk3328 ACODEC node
Am Sonntag, 23. Dezember 2018, 11:05:30 CET schrieb Katsuhiro Suzuki: > This patch adds audio codec (ACODEC) node that converts to analog > audio signal from I2S for rk3328. > > Signed-off-by: Katsuhiro Suzuki I've moved the rockchip,grf below the clocks properties and applied the result for 4.22. Thanks for improving the rk3328 Heiko
[PATCH] clk: zynqmp: Fix memory allocation in zynqmp_clk_setup
Fix memory allocation and use struct_size() in kzalloc().
Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
---
drivers/clk/zynqmp/clkc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
index f65cc0ff76ab..b0908ec62f73 100644
--- a/drivers/clk/zynqmp/clkc.c
+++ b/drivers/clk/zynqmp/clkc.c
@@ -669,8 +669,8 @@ static int zynqmp_clk_setup(struct device_node *np)
if (ret)
return ret;
- zynqmp_data = kzalloc(sizeof(*zynqmp_data) + sizeof(*zynqmp_data) *
- clock_max_idx, GFP_KERNEL);
+ zynqmp_data = kzalloc(struct_size(zynqmp_data, hws, clock_max_idx),
+ GFP_KERNEL);
if (!zynqmp_data)
return -ENOMEM;
--
2.17.0
KASAN: use-after-free Read in __xfrm_policy_bysel_ctx
Hello, syzbot found the following crash on: HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=175b8d1540 kernel config: https://syzkaller.appspot.com/x/.config?x=67a2081147a23142 dashboard link: https://syzkaller.appspot.com/bug?extid=ae4bda7fbf4ae4fb57b6 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ae4bda7fbf4ae4fb5...@syzkaller.appspotmail.com netlink: 20 bytes leftover after parsing attributes in process `syz-executor1'. netlink: 104 bytes leftover after parsing attributes in process `syz-executor0'. netlink: 20 bytes leftover after parsing attributes in process `syz-executor1'. == BUG: KASAN: use-after-free in __xfrm_policy_bysel_ctx.constprop.63+0x3d4/0x460 net/xfrm/xfrm_policy.c:1618 Read of size 1 at addr 8881b697a699 by task syz-executor0/25289 CPU: 0 PID: 25289 Comm: syz-executor0 Not tainted 4.20.0-rc7+ #358 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430 __xfrm_policy_bysel_ctx.constprop.63+0x3d4/0x460 net/xfrm/xfrm_policy.c:1618 xfrm_policy_bysel_ctx+0x883/0x1050 net/xfrm/xfrm_policy.c:1664 xfrm_get_policy+0x6a3/0x1140 net/xfrm/xfrm_user.c:1887 xfrm_user_rcv_msg+0x44c/0x8e0 net/xfrm/xfrm_user.c:2663 netlink_rcv_skb+0x16c/0x430 net/netlink/af_netlink.c:2477 xfrm_netlink_rcv+0x6f/0x90 net/xfrm/xfrm_user.c:2671 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x59f/0x750 net/netlink/af_netlink.c:1336 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116 __sys_sendmsg+0x11d/0x280 net/socket.c:2154 __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457669 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f0704710c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457669 RDX: RSI: 2014f000 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7f07047116d4 R13: 004c44d8 R14: 004d74e8 R15: Allocated by task 24751: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 __do_kmalloc_node mm/slab.c:3684 [inline] __kmalloc_node_track_caller+0x50/0x70 mm/slab.c:3698 __kmalloc_reserve.isra.40+0x41/0xe0 net/core/skbuff.c:140 __alloc_skb+0x155/0x760 net/core/skbuff.c:208 alloc_skb include/linux/skbuff.h:1011 [inline] sctp_packet_transmit+0x36b/0x3cd0 net/sctp/output.c:584 sctp_packet_transmit_chunk+0xa8/0x18b net/sctp/output.c:207 sctp_outq_flush_data net/sctp/outqueue.c:1106 [inline] sctp_outq_flush+0x1546/0x34f0 net/sctp/outqueue.c:1205 sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:772 sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline] sctp_do_sm+0x5ff/0x7190 net/sctp/sm_sideeffect.c:1191 sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1074 sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95 sctp_rcv+0x2e48/0x4150 net/sctp/input.c:271 sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1065 ip6_protocol_deliver_rcu+0x372/0x1940 net/ipv6/ip6_input.c:394 ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:434 NF_HOOK include/linux/netfilter.h:289 [inline] ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:443 dst_input include/net/dst.h:450 [inline] ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76 NF_HOOK include/linux/netfilter.h:289 [inline] ipv6_rcv+0x115/0x640 net/ipv6/ip6_input.c:272 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083 process_backlog+0x217/0x760 net/core/dev.c:5923 napi_poll net/core/dev.c:6346 [inline] net_rx_action+0x7c5/0x1950 net/core/dev.c:6412 __do_softirq+0x30c/0xb2e kernel/softirq.c:292 Freed by task 24751:
INFO: rcu detected stall in netlink_sendmsg
Hello, syzbot found the following crash on: HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=12662e6740 kernel config: https://syzkaller.appspot.com/x/.config?x=67a2081147a23142 dashboard link: https://syzkaller.appspot.com/bug?extid=a910a514846e27f15348 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a910a514846e27f15...@syzkaller.appspotmail.com netlink: 8 bytes leftover after parsing attributes in process `syz-executor5'. rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 1-...!: (10500 ticks this GP) idle=58a/1/0x4002 softirq=84145/84145 fqs=0 rcu: (t=10500 jiffies g=122913 q=1655) rcu: rcu_preempt kthread starved for 10500 jiffies! g122913 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1 rcu: RCU grace-period kthread stack dump: rcu_preempt I2256810 2 0x8000 Call Trace: context_switch kernel/sched/core.c:2831 [inline] __schedule+0x86c/0x1ed0 kernel/sched/core.c:3472 schedule+0xfe/0x460 kernel/sched/core.c:3516 schedule_timeout+0x140/0x260 kernel/time/timer.c:1804 rcu_gp_fqs_loop+0x762/0xa80 kernel/rcu/tree.c:1934 rcu_gp_kthread+0x341/0xc70 kernel/rcu/tree.c:2090 kthread+0x35a/0x440 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 NMI backtrace for cpu 1 CPU: 1 PID: 10942 Comm: syz-executor1 Not tainted 4.20.0-rc7+ #358 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 nmi_cpu_backtrace.cold.4+0x63/0xa2 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x1c2/0x22c lib/nmi_backtrace.c:62 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x16f/0x1bc kernel/rcu/tree.c:1195 print_cpu_stall.cold.65+0x1f3/0x3c6 kernel/rcu/tree.c:1334 check_cpu_stall kernel/rcu/tree.c:1408 [inline] rcu_pending kernel/rcu/tree.c:2961 [inline] rcu_check_callbacks+0xac1/0x1410 kernel/rcu/tree.c:2506 update_process_times+0x2d/0x70 kernel/time/timer.c:1636 tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164 tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274 __run_hrtimer kernel/time/hrtimer.c:1398 [inline] __hrtimer_run_queues+0x41c/0x10d0 kernel/time/hrtimer.c:1460 hrtimer_interrupt+0x313/0x780 kernel/time/hrtimer.c:1518 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1034 [inline] smp_apic_timer_interrupt+0x1a1/0x760 arch/x86/kernel/apic/apic.c:1059 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x1/0x20 kernel/kcov.c:188 Code: fe ff ff 5d c3 0f 1f 40 00 55 0f b7 d6 0f b7 f7 bf 03 00 00 00 48 89 e5 48 8b 4d 08 e8 88 fe ff ff 5d c3 66 0f 1f 44 00 00 55 <89> f2 89 fe bf 05 00 00 00 48 89 e5 48 8b 4d 08 e8 6a fe ff ff 5d RSP: 0018:8881c195ef50 EFLAGS: 0286 ORIG_RAX: ff13 RAX: 0004 RBX: 0004 RCX: c90005f36000 RDX: 0004 RSI: 0004 RDI: 000e RBP: 8881c195efc0 R08: 8881d7da2040 R09: R10: R11: 8881d7da2040 R12: dc00 R13: 8881c2e07c18 R14: 8881b8142d20 R15: 0100 xfrm_policy_bysel_ctx+0x883/0x1050 net/xfrm/xfrm_policy.c:1664 xfrm_get_policy+0x6a3/0x1140 net/xfrm/xfrm_user.c:1887 xfrm_user_rcv_msg+0x44c/0x8e0 net/xfrm/xfrm_user.c:2663 netlink_rcv_skb+0x16c/0x430 net/netlink/af_netlink.c:2477 xfrm_netlink_rcv+0x6f/0x90 net/xfrm/xfrm_user.c:2671 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x59f/0x750 net/netlink/af_netlink.c:1336 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116 __sys_sendmsg+0x11d/0x280 net/socket.c:2154 __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457669 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc47e41ac78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457669 RDX: RSI: 2014f000 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12:
[PATCH] mlxsw: spectrum_acl_bloom_filter: use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
.../net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
index 505b87846acc..f5c381dcb015 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c
@@ -234,8 +234,8 @@ mlxsw_sp_acl_bf_init(struct mlxsw_sp *mlxsw_sp, unsigned
int num_erp_banks)
* is 2^ACL_MAX_BF_LOG
*/
bf_bank_size = 1 << MLXSW_CORE_RES_GET(mlxsw_sp->core, ACL_MAX_BF_LOG);
- bf = kzalloc(sizeof(*bf) + bf_bank_size * num_erp_banks *
-sizeof(*bf->refcnt), GFP_KERNEL);
+ bf = kzalloc(struct_size(bf, refcnt, bf_bank_size * num_erp_banks),
+GFP_KERNEL);
if (!bf)
return ERR_PTR(-ENOMEM);
--
2.17.0
Re: [PATCH v5 0/7] mips: system call table generation support
On Sun, 23 Dec 2018 at 21:51, Paul Burton wrote: > > Hi Firoz, > > On Sun, Dec 23, 2018 at 08:15:48AM -0800, Paul Burton wrote: > > Hello, > > > > Firoz Khan wrote: > > > The purpose of this patch series is, we can easily > > > add/modify/delete system call table support by cha- > > > nging entry in syscall.tbl file instead of manually > > > changing many files. The other goal is to unify the > > > system call table generation support implementation > > > across all the architectures. > >% > > Series applied to mips-fixes. > > > > Thanks, > > Paul > > > > [ This message was auto-generated; if you believe anything is incorrect > > then please email paul.bur...@mips.com to report it. ] > > FYI this was actually applied to mips-next on the 14th & is part of the > pull request I'm about to send for 4.21, but running my ack-email script > is still a manual step & clearly still could be improved :) Thanks Paul! Firoz
Re: [v6,1/5] powerpc: add __NR_syscalls along with NR_syscalls
On Sun, 23 Dec 2018 at 18:58, Michael Ellerman wrote: > > On Mon, 2018-12-17 at 10:40:32 UTC, Firoz Khan wrote: > > NR_syscalls macro holds the number of system call exist > > in powerpc architecture. We have to change the value of > > NR_syscalls, if we add or delete a system call. > > > > One of the patch in this patch series has a script which > > will generate a uapi header based on syscall.tbl file. > > The syscall.tbl file contains the number of system call > > information. So we have two option to update NR_syscalls > > value. > > > > 1. Update NR_syscalls in asm/unistd.h manually by count- > >ing the no.of system calls. No need to update NR_sys- > >calls until we either add a new system call or delete > >existing system call. > > > > 2. We can keep this feature in above mentioned script, > >that will count the number of syscalls and keep it in > >a generated file. In this case we don't need to expli- > >citly update NR_syscalls in asm/unistd.h file. > > > > The 2nd option will be the recommended one. For that, I > > added the __NR_syscalls macro in uapi/asm/unistd.h along > > with NR_syscalls asm/unistd.h. The macro __NR_syscalls > > also added for making the name convention same across all > > architecture. While __NR_syscalls isn't strictly part of > > the uapi, having it as part of the generated header to > > simplifies the implementation. We also need to enclose > > this macro with #ifdef __KERNEL__ to avoid side effects. > > > > Signed-off-by: Firoz Khan > > Series applied to powerpc next, thanks. Thanks Micheal! Firoz > > https://git.kernel.org/powerpc/c/8a19eeeab66dfdd7c67bc8e3048ac0 > > cheers
linux-next: manual merge of the iommu tree with the powerpc tree
Hi all,
Today's linux-next merge of the iommu tree got a conflict in:
arch/powerpc/kernel/iommu.c
between commit:
c4e9d3c1e65a ("powerpc/powernv/pseries: Rework device adding to IOMMU groups")
from the powerpc tree and commit:
bf8763d8f837 ("powerpc/iommu: Use device_iommu_mapped()")
from the iommu tree.
I fixed it up (I just used the powerpc tree version which removed the
code modified by the latter) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your
tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp8UYrRsKjqO.pgp
Description: OpenPGP digital signature
[GIT PULL] ext4 updates for 4.21-rc1
The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436: Linux 4.20-rc4 (2018-11-25 14:19:31 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for you to fetch changes up to 18f2c4fcebf2582f96cbd5f2238f4f354a0e4847: ext4: check for shutdown and r/o file system in ext4_write_inode() (2018-12-19 14:36:58 -0500) All cleanups and bug fixes; most notably, fix some problems discovered in ext4's NFS support, and fix an ioctl (EXT4_IOC_GROUP_ADD) used by old versions of e2fsprogs which we accidentally broke a while back. Also fixed some error paths in ext4's quota and inline data support. Finally, improve tail latency in jbd2's commit code. Alexander Lochmann (1): jbd2: update locking documentation for transaction_t Chengguang Xu (2): ext4: remove redundant condition check ext4: compare old and new mode before setting update_mode flag Colin Ian King (2): ext4: clean up indentation issues, remove extraneous tabs jbd2: clean up indentation issue, replace spaces with tab Eric Sandeen (1): ext4: hard fail dax mount on unsupported devices Jan Kara (1): jbd2: avoid long hold times of j_state_lock while committing a transaction Maurizio Lombardi (1): ext4: missing unlock/put_page() in ext4_try_to_write_inline_data() Pan Bian (1): ext4: fix possible use after free in ext4_quota_enable Theodore Ts'o (5): ext4: add ext4_sb_bread() to disambiguate ENOMEM cases ext4: include terminating u32 in size of xattr entries when expanding inodes ext4: avoid declaring fs inconsistent due to invalid file handles ext4: force inode writes when nfsd calls commit_metadata() ext4: check for shutdown and r/o file system in ext4_write_inode() ruippan (潘睿) (1): ext4: fix EXT4_IOC_GROUP_ADD ioctl fs/ext4/acl.c | 3 +- fs/ext4/ext4.h | 17 - fs/ext4/ialloc.c| 2 +- fs/ext4/inline.c| 5 ++- fs/ext4/inode.c | 63 +-- fs/ext4/ioctl.c | 2 +- fs/ext4/migrate.c | 48 fs/ext4/namei.c | 4 +- fs/ext4/resize.c| 79 +++ fs/ext4/super.c | 92 -- fs/ext4/xattr.c | 83 - fs/jbd2/commit.c| 3 ++ fs/jbd2/transaction.c | 45 --- include/linux/jbd2.h| 7 ++-- include/trace/events/ext4.h | 20 ++ 15 files changed, 296 insertions(+), 177 deletions(-)
Re: [PATCH] debugfs: remove inc_nlink in debugfs_create_automount
Greg KH wrote on 2018/12/22 19:25:
On Sat, Dec 22, 2018 at 04:45:36PM +0800, yangerkun wrote:
Remove inc_nlink in debugfs_create_automount, or this inode will never
be free.
Signed-off-by: yangerkun
---
fs/debugfs/inode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 13b01351dd1c..9294238e364f 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -551,12 +551,11 @@ struct dentry *debugfs_create_automount(const char *name,
if (unlikely(!inode))
return failed_creating(dentry);
+ /* directory inodes start off with i_nlink == 2 (for "." entry) */
make_empty_dir_inode(inode);
inode->i_flags |= S_AUTOMOUNT;
inode->i_private = data;
dentry->d_fsdata = (void *)f;
- /* directory inodes start off with i_nlink == 2 (for "." entry) */
- inc_nlink(inode);
Again, have you tested this and how? How did you find this issue?
thanks,
greg k-h
.
Thanks a lot for Al Viro's explain.
I was confusing about i_nlink and i_count before, so after insert and
remove module show as below, i think the inode can still exist with
nlink will be 1.
So the only problem is that the nlink should be 2 for a empty dir, and
for debugfs,the influence is that the stat for the dir. Right?
#include
#include
#include
static char *name = "test-dir";
module_param(name, charp, 0644);
MODULE_PARM_DESC(name, "Get an string(char *) value from user...\n");
struct inode *inode;
int init_module(void)
{
struct dentry *dentry;
dentry = debugfs_create_automount(name, NULL, NULL, NULL);
inode = dentry->d_inode;
debugfs_remove(dentry);
return 0;
}
void cleanup_module(void)
{
printk("%d\n", inode->i_nlink);
}
MODULE_LICENSE("GPL");
Thanks,
Kun.
Re: [PATCH net V2 4/4] vhost: log dirty page correctly
On 2018/12/14 下午9:20, Michael S. Tsirkin wrote: On Fri, Dec 14, 2018 at 10:43:03AM +0800, Jason Wang wrote: On 2018/12/13 下午10:31, Michael S. Tsirkin wrote: Just to make sure I understand this. It looks to me we should: - allow passing GIOVA->GPA through UAPI - cache GIOVA->GPA somewhere but still use GIOVA->HVA in device IOTLB for performance Is this what you suggest? Thanks Not really. We already have GPA->HVA, so I suggested a flag to pass GIOVA->GPA in the IOTLB. This has advantages for security since a single table needs then to be validated to ensure guest does not corrupt QEMU memory. I wonder how much we can gain through this. Currently, qemu IOMMU gives GIOVA->GPA mapping, and qemu vhost code will translate GPA to HVA then pass GIOVA->HVA to vhost. It looks no difference to me. Thanks The difference is in security not in performance. Getting a bad HVA corrupts QEMU memory and it might be guest controlled. Very risky. How can this be controlled by guest? HVA was generated from qemu ram blocks which is totally under the control of qemu memory core instead of guest. Thanks If translations to HVA are done in a single place through a single table it's safer as there's a single risky place.
[PATCH] zram: idle writeback fixes and cleanup
This patch includes some fixes and cleanup for idle-page writeback. 1. writeback_limit interface Now writeback_limit interface is rather conusing. For example, once writeback limit budget is exausted, admin can see 0 from /sys/block/zramX/writeback_limit which is same semantic with disable writeback_limit at this moment. IOW, admin cannot tell that zero came from disable writeback limit or exausted writeback limit. To make the interface clear, let's sepatate enable of writeback limit to another knob - /sys/block/zram0/writeback_limit_enable * before: while true : # to re-enable writeback limit once previous one is used up echo 0 > /sys/block/zram0/writeback_limit echo $((200<<20)) > /sys/block/zram0/writeback_limit .. .. # used up the writeback limit budget * new # To enable writeback limit, from the beginning, admin should # enable it. echo $((200<<20)) > /sys/block/zram0/writeback_limit echo 1 > /sys/block/zram/0/writeback_limit_enable while true : echo $((200<<20)) > /sys/block/zram0/writeback_limit .. .. # used up the writeback limit budget It's much strightforward. 2. fix condition check idle/huge writeback mode check The mode in writeback_store is not bit opeartion any more so no need to use bit operations. Furthermore, current condition check is broken in that it does writeback every pages regardless of huge/idle. 3. clean up idle_store No need to use goto. Suggested-by: John Dias Signed-off-by: Minchan Kim --- Documentation/ABI/testing/sysfs-block-zram | 11 ++- Documentation/blockdev/zram.txt| 74 --- drivers/block/zram/zram_drv.c | 86 -- drivers/block/zram/zram_drv.h | 5 +- 4 files changed, 122 insertions(+), 54 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram index 9d2339a485c8a..14b2bf2e5105c 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -122,11 +122,18 @@ Contact: Minchan Kim statistics (bd_count, bd_reads, bd_writes) in a format similar to block layer statistics file format. +What: /sys/block/zram/writeback_limit_enable +Date: November 2018 +Contact: Minchan Kim +Description: + The writeback_limit_enable file is read-write and specifies + eanbe of writeback_limit feature. "1" means eable the feature. + No limit "0" is the initial state. + What: /sys/block/zram/writeback_limit Date: November 2018 Contact: Minchan Kim Description: The writeback_limit file is read-write and specifies the maximum amount of writeback ZRAM can do. The limit could be changed - in run time and "0" means disable the limit. - No limit is the initial state. + in run time. diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt index 436c5e98e1b60..4df0ce2710857 100644 --- a/Documentation/blockdev/zram.txt +++ b/Documentation/blockdev/zram.txt @@ -156,22 +156,23 @@ Per-device statistics are exported as various nodes under /sys/block/zram/ A brief description of exported device attributes. For more details please read Documentation/ABI/testing/sysfs-block-zram. -Nameaccessdescription ------ -disksize RWshow and set the device's disk size -initstate ROshows the initialization state of the device -reset WOtrigger device reset -mem_used_max WOreset the `mem_used_max' counter (see later) -mem_limit WOspecifies the maximum amount of memory ZRAM can use -to store the compressed data -writeback_limit WOspecifies the maximum amount of write IO zram can - write out to backing device as 4KB unit -max_comp_streams RWthe number of possible concurrent compress operations -comp_algorithmRWshow and change the compression algorithm -compact WOtrigger memory compaction -debug_statROthis file is used for zram debugging purposes -backing_dev RWset up backend storage for zram to write out -idle WOmark allocated slot as idle +Name accessdescription + ----- +disksize RW show and set the device's disk size +initstate RO shows the initialization state of the device +reset WO trigger device reset +mem_used_max WO reset the `mem_used_max' counter (see later) +mem_limit WO specifies the maximum amount of memory ZRAM can use + to store the compressed data +writeback_limitWO specifies the maximum amount of write IO
[PATCH] nvme-pci: fix the wrong setting of nr_maps
We only set the nr_maps to 3 if poll queues are supported. Signed-off-by: Jianchao Wang --- drivers/nvme/host/pci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 5a0bf6a..cc65fa8 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2294,7 +2294,6 @@ static int nvme_dev_add(struct nvme_dev *dev) dev->tagset.nr_maps = 2; /* default + read */ if (dev->io_queues[HCTX_TYPE_POLL]) dev->tagset.nr_maps++; - dev->tagset.nr_maps = HCTX_MAX_TYPES; dev->tagset.timeout = NVME_IO_TIMEOUT; dev->tagset.numa_node = dev_to_node(dev->dev); dev->tagset.queue_depth = -- 2.7.4
Re: [PATCH 1/1] x86/hyper-v: Fix 'set but not used' warnings
On Sat, Dec 22, 2018 at 12:06:58AM +, Michael Kelley wrote: In these two cases, a value returned by rdmsr() or rdmsrl() is ignored. Indicate that ignoring the value is intentional, so that with the W=1 compilation option no warning is generated. Signed-off-by: Michael Kelley Queued up, thank you. -- Thanks, Sasha
linux-next: manual merge of the rdma tree with the nfs-anna tree
Hi all,
Today's linux-next merge of the rdma tree got a conflict in:
net/sunrpc/xprtrdma/fmr_ops.c
between commit:
d31f8deac38d ("xprtrdma: Remove support for FMR memory registration")
from the nfs-anna tree and commit:
3023a1e93656 ("RDMA: Start use ib_device_ops")
from the rdma tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp5ZOzcXMhtB.pgp
Description: OpenPGP digital signature
RE: [PATCH] staging: android: ion: add buffer flag update ioctl
Hi laura:
>-Original Message-
>From: Laura Abbott [mailto:labb...@redhat.com]
>Sent: Friday, December 21, 2018 4:50 AM
>To: Zengtao (B) ; sumit.sem...@linaro.org
>Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
>; Todd Kjos ; Martijn Coenen
>; Joel Fernandes ;
>de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org;
>linaro-mm-...@lists.linaro.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH] staging: android: ion: add buffer flag update ioctl
>
>On 12/19/18 5:39 PM, Zengtao (B) wrote:
>> Hi laura:
>>
>>> -Original Message-
>>> From: Laura Abbott [mailto:labb...@redhat.com]
>>> Sent: Thursday, December 20, 2018 2:10 AM
>>> To: Zengtao (B) ;
>sumit.sem...@linaro.org
>>> Cc: Greg Kroah-Hartman ; Arve
>Hjønnevåg
>>> ; Todd Kjos ; Martijn
>Coenen
>>> ; Joel Fernandes ;
>>> de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org;
>>> linaro-mm-...@lists.linaro.org; linux-kernel@vger.kernel.org
>>> Subject: Re: [PATCH] staging: android: ion: add buffer flag update
>>> ioctl
>>>
>>> On 12/19/18 9:19 AM, Zeng Tao wrote:
In some usecases, the buffer cached attribute is not determined at
allocation time, it's determined just before the real cpu mapping.
And from the memory view of point, a buffer should not have the
>>> cached
attribute util is really mapped by the cpu. So in this patch, we
introduced the new ioctl command to target the requirement.
>>>
>>> This is racy and error prone. Can you explain more what problem you
>>> are trying to solve?
>>
>> My use case is like this:
>> 1. There are two process A and B, A takes case of ion buffer allocation,
>and
>> pass the buffer fd to B, then B maps and uses it.
>> 2. Process B need to map the buffer with different cached attribute
>> for different use case, for example, if the buffer is used for pure
>> software algorithm, then we need to map it as cached, otherwise
>> non-cached, and B needs to deal with both cases.
>> And unfortunately the mmap syscall takes no cached flags and we can't
>> decide the cache attribute when we are doing the mmap, so I introduce
>> new the ioctl even though I think the solution is not as good.
>>
>>
>
>Thanks for the explanation, this was about the use case I expected.
>I'm pretty sure I had this exact problem once upon a time and we didn't
>come up with a solution. I'd still like to get rid of uncached buffers in
>general and just use cached buffers (see
>http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-N
>ovember/128842.html)
>What's your usecase for uncached buffers?
Some buffers are only used by HW, in this case, we tend to use uncached buffers.
But sometimes the SW need to read few buffer contents for debug purpose and
no synchronization is needed.
>
>>>
Signed-off-by: Zeng Tao
---
drivers/staging/android/ion/ion-ioctl.c | 4
drivers/staging/android/ion/ion.c | 17
>+
drivers/staging/android/ion/ion.h | 1 +
drivers/staging/android/uapi/ion.h | 22
>>> ++
4 files changed, 44 insertions(+)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index a8d3cc4..60bb702 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -12,6 +12,7 @@
union ion_ioctl_arg {
struct ion_allocation_data allocation;
+ struct ion_buffer_flag_data update;
struct ion_heap_query query;
};
@@ -83,6 +84,9 @@ long ion_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
break;
}
+ case ION_IOC_BUFFER_UPDATE:
+ ret = ion_buffer_update(data.update.fd, data.update.flags);
+ break;
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps();
break;
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 9907332..f1404dc 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -436,6 +436,23 @@ int ion_alloc(size_t len, unsigned int
>>> heap_id_mask, unsigned int flags)
return fd;
}
+int ion_buffer_update(unsigned int fd, unsigned int flags) {
+ struct dma_buf *dmabuf;
+ struct ion_buffer *buffer;
+
+ dmabuf = dma_buf_get(fd);
+
+ if (!dmabuf)
+ return -EINVAL;
+
+ buffer = dmabuf->priv;
+ buffer->flags = flags;
+ dma_buf_put(dmabuf);
+
+ return 0;
+}
+
int ion_query_heaps(struct ion_heap_query *query)
{
struct ion_device *dev = internal_dev; diff --git
a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index c006fc1..99bf9ab 100644
---
[PATCH][v2] tty: fix race between flush_to_ldisc and tty_open
There still is a race window after the commit b027e2298bd588
("tty: fix data race between tty_init_dev and flush of buf"),
if receive_buf call comes before tty initialization completes
in n_tty_open and tty->driver_data may be NULL.
CPU0 CPU1
n_tty_open
tty_init_dev
tty_ldisc_unlock
schedule
flush_to_ldisc
n_tty_receive_buf
uart_flush_chars
uart_start
/*tty->driver_data is NULL*/
tty->ops->open
/*init tty->driver_data*/
Extending ldisc semaphore lock in tty_init_dev to driver_data
initialized completely after tty->ops->open().
Signed-off-by: Zhang Yu
Signed-off-by: Li RongQing
---
drivers/staging/speakup/spk_ttyio.c | 1 +
drivers/tty/pty.c | 2 ++
drivers/tty/serdev/serdev-ttyport.c | 2 ++
drivers/tty/tty_io.c| 14 +++---
drivers/tty/tty_ldisc.c | 1 +
5 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/speakup/spk_ttyio.c
b/drivers/staging/speakup/spk_ttyio.c
index 979e3ae249c1..c31f08c98383 100644
--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -155,6 +155,7 @@ static int spk_ttyio_initialise_ldisc(struct spk_synth
*synth)
else
ret = -ENODEV;
+ tty_ldisc_unlock(tty);
if (ret) {
tty_unlock(tty);
return ret;
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 00099a8439d2..1b9684d4f718 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -873,9 +873,11 @@ static int ptmx_open(struct inode *inode, struct file
*filp)
tty_debug_hangup(tty, "opening (count=%d)\n", tty->count);
+ tty_ldisc_unlock(tty);
tty_unlock(tty);
return 0;
err_release:
+ tty_ldisc_unlock(tty);
tty_unlock(tty);
// This will also put-ref the fsi
tty_release(inode, filp);
diff --git a/drivers/tty/serdev/serdev-ttyport.c
b/drivers/tty/serdev/serdev-ttyport.c
index fa1672993b4c..ce16cb303e28 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -123,6 +123,7 @@ static int ttyport_open(struct serdev_controller *ctrl)
if (ret)
goto err_close;
+ tty_ldisc_unlock(tty);
tty_unlock(serport->tty);
/* Bring the UART into a known 8 bits no parity hw fc state */
@@ -145,6 +146,7 @@ static int ttyport_open(struct serdev_controller *ctrl)
err_close:
tty->ops->close(tty, NULL);
err_unlock:
+ tty_ldisc_unlock(tty);
tty_unlock(tty);
tty_release_struct(tty, serport->tty_idx);
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 687250ec8032..199f45e2e1b1 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1351,7 +1351,6 @@ struct tty_struct *tty_init_dev(struct tty_driver
*driver, int idx)
retval = tty_ldisc_setup(tty, tty->link);
if (retval)
goto err_release_tty;
- tty_ldisc_unlock(tty);
/* Return the tty locked so that it cannot vanish under the caller */
return tty;
@@ -1926,7 +1925,7 @@ EXPORT_SYMBOL_GPL(tty_kopen);
* - concurrent tty removal from driver table
*/
static struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
-struct file *filp)
+struct file *filp, bool *unlock)
{
struct tty_struct *tty;
struct tty_driver *driver = NULL;
@@ -1970,6 +1969,7 @@ static struct tty_struct *tty_open_by_driver(dev_t
device, struct inode *inode,
}
} else { /* Returns with the tty_lock held for now */
tty = tty_init_dev(driver, index);
+ *unlock = true;
mutex_unlock(_mutex);
}
out:
@@ -2007,6 +2007,7 @@ static int tty_open(struct inode *inode, struct file
*filp)
int noctty, retval;
dev_t device = inode->i_rdev;
unsigned saved_flags = filp->f_flags;
+ bool unlock = false;
nonseekable_open(inode, filp);
@@ -2017,7 +2018,7 @@ static int tty_open(struct inode *inode, struct file
*filp)
tty = tty_open_current_tty(device, filp);
if (!tty)
- tty = tty_open_by_driver(device, inode, filp);
+ tty = tty_open_by_driver(device, inode, filp, );
if (IS_ERR(tty)) {
tty_free_file(filp);
@@ -2042,6 +2043,10 @@ static int tty_open(struct inode *inode, struct file
*filp)
if (retval) {
tty_debug_hangup(tty, "open error %d, releasing\n", retval);
+ if (unlock) {
+ unlock = false;
+ tty_ldisc_unlock(tty);
+
[PATCH] usb: gadget: function: sync f_uac1 ac header baInterfaceNr
f_uac1 audio control header descriptor default set baInterfaceNr[]={1,2}, but
usb gadget make a configuration descriptor with more interfaces combination, it
can not confirm f_uac1 function linked first. So always keep
baInterfaceNr[]={1,2} is correct, and it is necessary to sync baInterfaceNr[]
with usb_interface_id() value.
Signed-off-by: Liang Shengjun
---
drivers/usb/gadget/function/f_uac1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/function/f_uac1.c
b/drivers/usb/gadget/function/f_uac1.c
index 28c1a78..d9aeb5c 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -581,6 +581,7 @@ static int f_audio_bind(struct usb_configuration *c, struct
usb_function *f)
goto fail;
as_out_interface_alt_0_desc.bInterfaceNumber = status;
as_out_interface_alt_1_desc.bInterfaceNumber = status;
+ ac_header_desc.baInterfaceNr[0] = status;
uac1->as_out_intf = status;
uac1->as_out_alt = 0;
@@ -589,6 +590,7 @@ static int f_audio_bind(struct usb_configuration *c, struct
usb_function *f)
goto fail;
as_in_interface_alt_0_desc.bInterfaceNumber = status;
as_in_interface_alt_1_desc.bInterfaceNumber = status;
+ ac_header_desc.baInterfaceNr[1] = status;
uac1->as_in_intf = status;
uac1->as_in_alt = 0;
--
2.7.4
[PATCH] usb: gadget: function: f_uac1 add interface assoc desc
Add f_uac1 interface association descriptor, make f_uac1 link other
function(like f_uvc) is possible.
Signed-off-by: Liang Shengjun
---
drivers/usb/gadget/function/f_uac1.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/gadget/function/f_uac1.c
b/drivers/usb/gadget/function/f_uac1.c
index 2746a92..28c1a78 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -48,6 +48,16 @@ static inline struct f_uac1 *func_to_uac1(struct
usb_function *f)
/* Number of streaming interfaces */
#define F_AUDIO_NUM_INTERFACES 2
+static struct usb_interface_assoc_descriptor uac_iad = {
+ .bLength = sizeof(uac_iad),
+ .bDescriptorType = USB_DT_INTERFACE_ASSOCIATION,
+ .bFirstInterface = 0,
+ .bInterfaceCount = 3,
+ .bFunctionClass = USB_CLASS_AUDIO,
+ .bFunctionSubClass = 0,
+ .bFunctionProtocol = UAC_VERSION_1,
+};
+
/* B.3.1 Standard AC Interface Descriptor */ static struct
usb_interface_descriptor ac_interface_desc = {
.bLength = USB_DT_INTERFACE_SIZE,
@@ -247,6 +257,7 @@ static struct uac_iso_endpoint_descriptor as_iso_in_desc =
{ };
static struct usb_descriptor_header *f_audio_desc[] = {
+ (struct usb_descriptor_header *)_iad,
(struct usb_descriptor_header *)_interface_desc,
(struct usb_descriptor_header *)_header_desc,
@@ -523,6 +534,7 @@ static int f_audio_bind(struct usb_configuration *c, struct
usb_function *f)
us = usb_gstrings_attach(cdev, uac1_strings, ARRAY_SIZE(strings_uac1));
if (IS_ERR(us))
return PTR_ERR(us);
+ uac_iad.iFunction = us[STR_AC_IF].id;
ac_interface_desc.iInterface = us[STR_AC_IF].id;
usb_out_it_desc.iTerminal = us[STR_USB_OUT_IT].id;
usb_out_it_desc.iChannelNames = us[STR_USB_OUT_IT_CH_NAMES].id; @@
-559,6 +571,7 @@ static int f_audio_bind(struct usb_configuration *c, struct
usb_function *f)
status = usb_interface_id(c, f);
if (status < 0)
goto fail;
+ uac_iad.bFirstInterface = status;
ac_interface_desc.bInterfaceNumber = status;
uac1->ac_intf = status;
uac1->ac_alt = 0;
--
2.7.4
[PATCH] net/net_namespace: Check the return value of register_pernet_subsys()
In net_ns_init(), register_pernet_subsys() could fail while registering
network namespace subsystems. The fix checks the return value and
sends a panic() on failure.
Signed-off-by: Aditya Pakki
---
net/core/net_namespace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index fefe72774aeb..af8849a7a9c3 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -917,7 +917,8 @@ static int __init net_ns_init(void)
init_net_initialized = true;
up_write(_ops_rwsem);
- register_pernet_subsys(_ns_ops);
+ if (register_pernet_subsys(_ns_ops))
+ panic("Could not register network namespace subsystems");
rtnl_register(PF_UNSPEC, RTM_NEWNSID, rtnl_net_newid, NULL,
RTNL_FLAG_DOIT_UNLOCKED);
--
2.17.1
[PATCH] net/netlink_compat: Fix a missing check of nla_parse_nested
In tipc_nl_compat_sk_dump(), if nla_parse_nested() fails, it could return an error. To be consistent with other invocations of the function call, on error, the fix passes the return value upstream. Signed-off-by: Aditya Pakki --- net/tipc/netlink_compat.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c index 6376467e78f8..21f6ccc89401 100644 --- a/net/tipc/netlink_compat.c +++ b/net/tipc/netlink_compat.c @@ -951,8 +951,11 @@ static int tipc_nl_compat_sk_dump(struct tipc_nl_compat_msg *msg, u32 node; struct nlattr *con[TIPC_NLA_CON_MAX + 1]; - nla_parse_nested(con, TIPC_NLA_CON_MAX, -sock[TIPC_NLA_SOCK_CON], NULL, NULL); + err = nla_parse_nested(con, TIPC_NLA_CON_MAX, + sock[TIPC_NLA_SOCK_CON], NULL, NULL); + + if (err) + return err; node = nla_get_u32(con[TIPC_NLA_CON_NODE]); tipc_tlv_sprintf(msg->rep, " connected to <%u.%u.%u:%u>", -- 2.17.1
[GIT PULL] iomap: updates for v4.21
Hi Linus, Here's a fix for a memory overflow bug in the iomap code for 4.21-rc1. It has undergone the usual testing regimen and merges cleanly with 4.20 final. Let me know if you encounter any problems with the merge. --D The following changes since commit 7566ec393f4161572ba6f11ad5171fd5d59b0fbd: Linux 4.20-rc7 (2018-12-16 15:46:55 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-4.21-merge-2 for you to fetch changes up to 3cc31fa65d85610574c0f6a474e89f4c419923d5: iomap: don't search past page end in iomap_is_partially_uptodate (2018-12-21 08:42:50 -0800) Updates for 4.21: - Fix a memory overflow bug for blocksize < pagesize Eric Sandeen (1): iomap: don't search past page end in iomap_is_partially_uptodate fs/iomap.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-)
xiao jie ju xu liu
Ltd.
[GIT PULL] xfs: updates for v4.21
Hi Linus, Here are a number of bug fixes for 4.21-rc1. It has undergone the usual testing regimen and merges cleanly with 4.20 final. Let me know if you encounter any problems with the merge. --D The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d: Linux 4.20-rc6 (2018-12-09 15:31:00 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-4.21-merge-2 for you to fetch changes up to 65eed012d1f2d0f0bf0ffc036826d58147de77b8: xfs: reallocate realtime summary cache on growfs (2018-12-21 18:45:18 -0800) XFS changes for 4.21: - Fix CoW remapping of extremely fragmented file areas - Fix a zero-length symlink verifier error - Constify some of the rmap owner structures for per-AG metadata - Precalculate inode geometry for later use - Fix scrub counting problems - Don't crash when rtsummary inode is null - Fix x32 ioctl operation - Fix enum->string mappings for ftrace output - Cache realtime summary information in memory Colin Ian King (1): xfs: clean up indentation issues, remove an unwanted space Darrick J. Wong (16): xfs: split up the xfs_reflink_end_cow work into smaller transactions xfs: idiotproof defer op type configuration xfs: streamline defer op type handling xfs: const-ify xfs_owner_info arguments xfs: remove xfs_rmap_ag_owner and friends xfs: add a block to inode count converter xfs: precalculate inodes and blocks per inode cluster xfs: precalculate cluster alignment in inodes and blocks xfs: count inode blocks correctly in inobt scrub xfs: require both realtime inodes to mount xfs: fix function pointer type in ftrace format xfs: fix symbolic enum printing in ftrace output xfs: move XFS_AG_BTREE_CMP_FORMAT_STR mappings to libxfs xfs: move XFS_INODE_FORMAT_STR mappings to libxfs xfs: stringify btree cursor types in ftrace output xfs: stringify scrub types in ftrace output Dave Chinner (1): xfs: zero length symlinks are not valid Nick Bowler (3): xfs: Align compat attrlist_by_handle with native implementation. xfs: Fix bulkstat compat ioctls on x32 userspace. xfs: Fix x32 ioctls when cmd numbers differ from ia32. Omar Sandoval (2): xfs: cache minimum realtime summary level xfs: reallocate realtime summary cache on growfs Pan Bian (1): xfs: libxfs: move xfs_perag_put late fs/xfs/libxfs/xfs_ag.c | 9 +- fs/xfs/libxfs/xfs_alloc.c | 79 ++-- fs/xfs/libxfs/xfs_alloc.h | 4 +- fs/xfs/libxfs/xfs_bmap.c | 6 +- fs/xfs/libxfs/xfs_bmap.h | 4 +- fs/xfs/libxfs/xfs_defer.c | 67 ++- fs/xfs/libxfs/xfs_defer.h | 37 +++--- fs/xfs/libxfs/xfs_format.h | 12 ++ fs/xfs/libxfs/xfs_ialloc.c | 54 - fs/xfs/libxfs/xfs_ialloc_btree.c | 7 +- fs/xfs/libxfs/xfs_refcount_btree.c | 6 +- fs/xfs/libxfs/xfs_rmap.c | 240 + fs/xfs/libxfs/xfs_rmap.h | 54 - fs/xfs/libxfs/xfs_rtbitmap.c | 6 + fs/xfs/libxfs/xfs_symlink_remote.c | 14 ++- fs/xfs/libxfs/xfs_types.c | 9 +- fs/xfs/libxfs/xfs_types.h | 22 fs/xfs/scrub/agheader.c| 25 ++-- fs/xfs/scrub/agheader_repair.c | 5 +- fs/xfs/scrub/alloc.c | 4 +- fs/xfs/scrub/btree.c | 45 +++ fs/xfs/scrub/btree.h | 22 ++-- fs/xfs/scrub/common.c | 14 +-- fs/xfs/scrub/common.h | 2 +- fs/xfs/scrub/ialloc.c | 64 +- fs/xfs/scrub/inode.c | 4 +- fs/xfs/scrub/refcount.c| 16 +-- fs/xfs/scrub/repair.c | 54 - fs/xfs/scrub/repair.h | 7 +- fs/xfs/scrub/rmap.c| 35 +++--- fs/xfs/scrub/scrub.h | 4 +- fs/xfs/scrub/trace.h | 131 +++- fs/xfs/xfs_aops.h | 3 + fs/xfs/xfs_extfree_item.c | 5 +- fs/xfs/xfs_fsops.c | 2 +- fs/xfs/xfs_inode.c | 16 +-- fs/xfs/xfs_ioctl32.c | 58 +++-- fs/xfs/xfs_itable.c| 14 +-- fs/xfs/xfs_log_recover.c | 8 +- fs/xfs/xfs_mount.c | 4 + fs/xfs/xfs_mount.h | 11 ++ fs/xfs/xfs_reflink.c | 232 --- fs/xfs/xfs_rtalloc.c | 57 +++-- fs/xfs/xfs_super.c | 10 +- fs/xfs/xfs_symlink.c | 33 ++--- fs/xfs/xfs_trace.h | 51 +--- fs/xfs/xfs_trans.h | 7 +- fs/xfs/xfs_trans_bmap.c| 11 +- fs/xfs/xfs_trans_extfree.c | 40 +++ fs/xfs/xfs_trans_refcount.c
[PATCH] rtl8723bs/ioctl_linux: Add a security check to copy_from_user()
Currently, the return value of copy_from_user is not checked.
extra is assigned to u32wps_start irrespective of these failures.
Signed-off-by: Aditya Pakki
---
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index b8631baf128d..9992caa8c839 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -2577,14 +2577,19 @@ static int rtw_wps_start(struct net_device *dev,
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct iw_point *pdata = >data;
u32 u32wps_start = 0;
-unsigned int uintRet = 0;
if ((true == padapter->bDriverStopped) ||(true
==padapter->bSurpriseRemoved) || (NULL == pdata)) {
ret = -EINVAL;
goto exit;
}
- uintRet = copy_from_user((void*)_start, pdata->pointer, 4);
+ ret = copy_from_user((void *)_start, pdata->pointer, 4);
+
+ if (ret) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
if (u32wps_start == 0)
u32wps_start = *extra;
--
2.17.1
Linux 4.20 released..
Let's face it, last week wasn't quite as quiet as I would have hoped for, but there really doesn't seem to be any point to delay 4.20 because everybody is already taking a break. And it's not like there are any known issues, it's just that the shortlog below is a bit longer than I would have wished for. Nothing screams "oh, that's scary", though. And as part of the "everybody is already taking a break", I can happily report that I already have quite a few early pull requests in my inbox. I encouraged people to get it over and done with, so that people can just relax over the year-end holidays. In fact, I probably won't start pulling for a couple of days, but otherwise let's just try to keep to the normal merge window schedule, even if most people hopefully won't even be back until over the merge window is over. As to the details of this last week of 4.20 - most of it is networking (drivers, core networking fixes, bpf). There's a few other non-network driver updates too, and a revert series of some of the x86 inline asm changes that were obviated by upcoming compiler support. Details below. Have a Merry Christmas or other holiday of your choice. Linus --- Alaa Hleihel (1): net/mlx5e: Remove the false indication of software timestamping support Alexander Aring (1): ieee802154: hwsim: fix off-by-one in parse nested Alistair Strachan (1): x86/vdso: Pass --eh-frame-hdr to the linker Allan W. Nielsen (1): mscc: Configured MAC entries should be locked. Anssi Hannula (3): net: macb: fix random memory corruption on RX with 64-bit DMA net: macb: fix dropped RX frames due to a race net: macb: add missing barriers when reading descriptors Antoine Tenart (2): net: mvpp2: 10G modes aren't supported on all ports net: mvpp2: fix the phylink mode validation Arnd Bergmann (4): i2c: nvidia-gpu: mark resume function as __maybe_unused ubifs: replay: Fix high stack usage ubifs: auth: Add CONFIG_KEYS dependency w90p910_ether: remove incorrect __init annotation Atul Gupta (5): net/tls: Init routines in create_ctx net/tls: sleeping function from invalid context crypto/chelsio/chtls: listen fails with multiadapt crypto/chelsio/chtls: macro correction in tx path crypto/chelsio/chtls: send/recv window update Benjamin Poirier (1): xfrm: Fix bucket count reported to userspace Benjamin Tissoires (1): Input: elantech - disable elan-i2c for P52 and P72 Brian Norris (1): Revert "mwifiex: restructure rx_reorder_tbl_lock usage" Bryan Whitehead (2): lan743x: Expand phy search for LAN7431 lan743x: Remove MAC Reset from initialization Cfir Cohen (1): KVM: Fix UAF in nested posted interrupt processing Chang S. Bae (1): x86/fsgsbase/64: Fix the base write helper functions Christian Brauner (1): Revert "vfs: Allow userns root to call mknod on owned filesystems." Christoph Hellwig (1): dma-mapping: fix flags in dma_alloc_wc Christophe Leroy (1): gpio: max7301: fix driver for use with CONFIG_VMAP_STACK Claudiu Beznea (1): net: macb: restart tx after tx used bit read Colin Ian King (2): x86/mtrr: Don't copy uninitialized gentry fields back to userspace vxge: ensure data0 is initialized in when fetching firmware version information Cong Wang (6): tipc: use lock_sock() in tipc_sk_reinit() tipc: fix a double kfree_skb() tipc: compare remote and local protocols in tipc_udp_enable() tipc: check tsk->group in tipc_wait_for_cond() tipc: check group dests after tipc_wait_for_cond() ipv6: explicitly initialize udp6_addr in udp_sock_create6() Corentin Labbe (1): sparc: Set "ARCH: sunxx" information on the same line Dan Carpenter (3): scsi: bnx2fc: Fix NULL dereference in error handling qed: Fix an error code qed_ll2_start_xmit() net: stmmac: Fix an error code in probe() Dan Williams (1): x86/mm: Fix decoy address handling vs 32-bit builds Daniel Borkmann (1): bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K Daniele Palmas (1): qmi_wwan: Fix qmap header retrieval in qmimux_rx_fixup Dave Chinner (1): iomap: Revert "fs/iomap.c: get/put the page in iomap_page_create/release()" Dave Taht (1): net: Allow class-e address assignment via ifconfig ioctl David Ahern (1): neighbor: NTF_PROXY is a valid ndm_flag for a dump request David S. Miller (1): rds: Fix warning. Davide Caratti (1): net: Use __kernel_clockid_t in uapi net_stamp.h Dexuan Cui (1): Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels Dmitry V. Levin (1): uapi: linux/blkzoned.h: fix BLKGETZONESZ and BLKGETNRZONES definitions Eduardo Habkost (1): kvm: x86: Add AMD's EX_CFG to the list of ignored MSRs Emmanuel Grumbach (1): iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares Eric Biggers (1): KVM:
Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro
On Mon, 24 Dec 2018 00:52:13 +0100
Rasmus Villemoes wrote:
> On 23/12/2018 23.56, Steven Rostedt wrote:
> > On Sun, 23 Dec 2018 23:01:52 +0100
> > Rasmus Villemoes wrote:
> >
> >> On 21/12/2018 23.20, Joe Perches wrote:
> >>>
> >>> Using
> >>>
> >>> static inline bool str_has_prefix(const char *str, const char prefix[])
> >>> {
> >>> return !strncmp(str, prefix, strlen(prefix));
> >>> }
> >>>
> >>
> >> We already have exactly that function, it's called strstarts().
> >
> > It's not exact.
>
> Huh? The str_has_prefix() I quoted is exactly strstarts().
The the implemented str_has_prefix() that you replied to is:
+/*
+ * A common way to test a prefix of a string is to do:
+ * strncmp(str, prefix, sizeof(prefix) - 1)
+ *
+ * But this can lead to bugs due to typos, or if prefix is a pointer
+ * and not a constant. Instead use strncmp_prefix().
+ */
+#define strncmp_prefix(str, prefix)\
+ ({ \
+ int strcmp_prefix_ret; \
+ if (__builtin_constant_p()) {\
+ strcmp_prefix_ret = \
+ strncmp(str, prefix, sizeof(prefix) - 1); \
+ } else {\
+ typeof(prefix) strcmp_prefix = prefix; \
+ strcmp_prefix_ret = \
+ strncmp(str, strcmp_prefix, \
+ strlen(strcmp_prefix)); \
+ } \
+ strcmp_prefix_ret; \
+ })
+
Note, this has turned into a nice function:
http://lkml.kernel.org/r/20181222162856.518489...@goodmis.org
+/**
+ * str_has_prefix - Test if a string has a given prefix
+ * @str: The string to test
+ * @prefix: The string to see if @str starts with
+ *
+ * A common way to test a prefix of a string is to do:
+ * strncmp(str, prefix, sizeof(prefix) - 1)
+ *
+ * But this can lead to bugs due to typos, or if prefix is a pointer
+ * and not a constant. Instead use str_has_prefix().
+ *
+ * Returns: 0 if @str does not start with @prefix
+ strlen(@prefix) if @str does start with @prefix
+ */
+static __always_inline size_t str_has_prefix(const char *str, const char
*prefix)
+{
+ size_t len = strlen(prefix);
+ return strncmp(str, prefix, len) == 0 ? len : 0;
+}
+
>
> >
> > Well, one thing that str_has_prefix() does that strstarts() does not,
> > is to return the prefix length which gets rid of the duplication.
>
> I hadn't seen the patches containing that version of str_has_prefix().
> Anyway, I just wanted to point out that strstarts() exists, so that we
> at least do not add a copy of that.
That's because you didn't read the patch that you quoted, just the
change log.
>
> > Would it be OK to convert strstarts() to return the length of prefix?
>
> Dunno. By far, most users of the strncmp() idiom only seem to be
> interested in the boolean result. It's true that there are some that
> then want to skip the prefix and do further parsing, and I can see how
> avoiding duplicating the prefix length is useful. But the mathematician
> in me can't help consider the corner case of 'the empty string is always
> a prefix of any other string', and having str_has_prefix(str, "") be
> false seems wrong - obviously, nobody would ever use a literal "" there,
> but nothing in str_has_prefix() _requires_ the prefix to be a constant.
Which would be a useless use case. And if you define that it returns
the length of prefix on return, then it both matches and doesn't
match ;-)
>
> Maybe 'bool str_skip_prefix(const char *s, const char *p, const char
> **out)' where *out is set to s+len on success, and set to s on failure
> (just to allow passing and continue parsing in elseifs)? That would
> make your 4/5 "tracing: Have the historgram use the result of
> str_has_prefix() for len of prefix" do
>
> if (str_skip_prefix(str, "onmatch(", _str)) {
>
> hoisting the action_str declaration to the top, replacing the len variable?
>
The use cases I've used in the final patch series uses the len for
indexing and other cases.
I think I'm keeping the str_has_prefix() and change the other users to
use it in the kernel. Most of the git grep strstarts() is tools
and scripts anyway.
-- Steve
Re: [PATCH] net: core: Fix Spectre v1 vulnerability
On 12/23/18 5:58 PM, David Miller wrote: From: Alexei Starovoitov Date: Sat, 22 Dec 2018 22:00:00 -0800 On Sat, Dec 22, 2018 at 11:03:31PM -0600, Gustavo A. R. Silva wrote: I took another look at the following patches: "net: core: Fix Spectre v1 vulnerability" "nfc: af_nfc: Fix Spectre v1 vulnerability" "can: af_can: Fix Spectre v1 vulnerability" and I have to say that none of them are necessary. I'm not sure whether there were other patches that pretend to fix spectre1. ... in other words there is no bug and there is no vulnerability, but there is a 'policy' set by ... ? So hence Nack to the policy and Nack to the patches. I have to agree with Alexei after looking at all of this stuff one more time. I'm reverting all of these changes. Yeah. That's fine with me. Thanks -- Gustavo
Re: [PATCH] net: core: Fix Spectre v1 vulnerability
From: Alexei Starovoitov Date: Sat, 22 Dec 2018 22:00:00 -0800 > On Sat, Dec 22, 2018 at 11:03:31PM -0600, Gustavo A. R. Silva wrote: >> > I took another look at the following patches: >> > "net: core: Fix Spectre v1 vulnerability" >> > "nfc: af_nfc: Fix Spectre v1 vulnerability" >> > "can: af_can: Fix Spectre v1 vulnerability" >> > and I have to say that none of them are necessary. >> > I'm not sure whether there were other patches that pretend to fix spectre1. ... > in other words there is no bug and there is no vulnerability, > but there is a 'policy' set by ... ? > So hence Nack to the policy and Nack to the patches. I have to agree with Alexei after looking at all of this stuff one more time. I'm reverting all of these changes.
Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro
On 23/12/2018 23.56, Steven Rostedt wrote:
> On Sun, 23 Dec 2018 23:01:52 +0100
> Rasmus Villemoes wrote:
>
>> On 21/12/2018 23.20, Joe Perches wrote:
>>>
>>> Using
>>>
>>> static inline bool str_has_prefix(const char *str, const char prefix[])
>>> {
>>> return !strncmp(str, prefix, strlen(prefix));
>>> }
>>>
>>
>> We already have exactly that function, it's called strstarts().
>
> It's not exact.
Huh? The str_has_prefix() I quoted is exactly strstarts().
>
> Well, one thing that str_has_prefix() does that strstarts() does not,
> is to return the prefix length which gets rid of the duplication.
I hadn't seen the patches containing that version of str_has_prefix().
Anyway, I just wanted to point out that strstarts() exists, so that we
at least do not add a copy of that.
> Would it be OK to convert strstarts() to return the length of prefix?
Dunno. By far, most users of the strncmp() idiom only seem to be
interested in the boolean result. It's true that there are some that
then want to skip the prefix and do further parsing, and I can see how
avoiding duplicating the prefix length is useful. But the mathematician
in me can't help consider the corner case of 'the empty string is always
a prefix of any other string', and having str_has_prefix(str, "") be
false seems wrong - obviously, nobody would ever use a literal "" there,
but nothing in str_has_prefix() _requires_ the prefix to be a constant.
Maybe 'bool str_skip_prefix(const char *s, const char *p, const char
**out)' where *out is set to s+len on success, and set to s on failure
(just to allow passing and continue parsing in elseifs)? That would
make your 4/5 "tracing: Have the historgram use the result of
str_has_prefix() for len of prefix" do
if (str_skip_prefix(str, "onmatch(", _str)) {
hoisting the action_str declaration to the top, replacing the len variable?
Rasmus
[PATCH v3 04/11] platform/x86: intel_ips: make PCI dependency explicit
ipss driver is a PCI device driver but this has not been mentioned anywhere in Kconfig. Signed-off-by: Sinan Kaya --- drivers/platform/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index e3b62c2ee8d1..b36ea14b41ad 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -1009,7 +1009,7 @@ config INTEL_MFLD_THERMAL config INTEL_IPS tristate "Intel Intelligent Power Sharing" - depends on ACPI + depends on ACPI && PCI ---help--- Intel Calpella platforms support dynamic power sharing between the CPU and GPU, maximizing performance in a given TDP. This driver, -- 2.19.0
[PATCH v3 02/11] ata: make PCI dependency explicit for PATA_ACPI
PATA_ACPI is a PCI device driver but the PCI dependency has not been explicitly called out. Signed-off-by: Sinan Kaya --- drivers/ata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 4ca7a6b4eaae..8218db17ebdb 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -1091,7 +1091,7 @@ comment "Generic fallback / legacy drivers" config PATA_ACPI tristate "ACPI firmware driver for PATA" - depends on ATA_ACPI && ATA_BMDMA + depends on ATA_ACPI && ATA_BMDMA && PCI help This option enables an ACPI method driver which drives motherboard PATA controller interfaces through the ACPI -- 2.19.0
[PATCH v3 05/11] platform/x86: intel_pmc: Make PCI dependency explicit
Code relies on PCI for execution. Specify this in the Kconfig. Signed-off-by: Sinan Kaya --- drivers/platform/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index b36ea14b41ad..7afb96cb1cd6 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -1174,7 +1174,7 @@ config INTEL_SMARTCONNECT config INTEL_PMC_IPC tristate "Intel PMC IPC Driver" - depends on ACPI + depends on ACPI && PCI ---help--- This driver provides support for PMC control on some Intel platforms. The PMC is an ARC processor which defines IPC commands for communication -- 2.19.0
[PATCH v3 07/11] drivers: thermal: int3406_thermal: Make PCI dependency explicit
Need CONFIG_PCI to be set in order to be able to use this driver. Signed-off-by: Sinan Kaya --- drivers/thermal/intel/int340x_thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/intel/int340x_thermal/Kconfig b/drivers/thermal/intel/int340x_thermal/Kconfig index 0582bd12a239..fba1976d5f8d 100644 --- a/drivers/thermal/intel/int340x_thermal/Kconfig +++ b/drivers/thermal/intel/int340x_thermal/Kconfig @@ -31,7 +31,7 @@ if INT340X_THERMAL config INT3406_THERMAL tristate "ACPI INT3406 display thermal driver" - depends on ACPI_VIDEO + depends on ACPI_VIDEO && PCI help The display thermal device represents the LED/LCD display panel that may or may not include touch support. The main function of -- 2.19.0
[PATCH v3 10/11] x86: select IOSF_MBI only when CONFIG_PCI is set
Need CONFIG_PCI to be set in order to be able to use IOSF_MBI functionality. Signed-off-by: Sinan Kaya --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index cc4f0c6ee1ed..322a58ababb0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -617,7 +617,7 @@ config X86_INTEL_QUARK config X86_INTEL_LPSS bool "Intel Low Power Subsystem Support" - depends on X86 && ACPI + depends on X86 && ACPI && PCI select COMMON_CLK select PINCTRL select IOSF_MBI -- 2.19.0
[PATCH v3 06/11] apple-gmux: Make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not been explicitly called out. Signed-off-by: Sinan Kaya Reviewed-by: Lukas Wunner --- drivers/platform/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 7afb96cb1cd6..89f4b86244a7 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -1136,6 +1136,7 @@ config SAMSUNG_Q10 config APPLE_GMUX tristate "Apple Gmux Driver" depends on ACPI + depends on PCI depends on PNP depends on BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_APPLE=n || BACKLIGHT_APPLE -- 2.19.0
[PATCH v3 08/11] ASoC: Intel: atom: Make PCI dependency explicit
Code does unconditional select for IOSF_MBI. IOSF_MBI driver depends on CONFIG_PCI set but this is not specified anywhere. Signed-off-by: Sinan Kaya --- sound/soc/intel/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 2fd1b61e8331..b0764b2fe001 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -91,7 +91,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_PCI config SND_SST_ATOM_HIFI2_PLATFORM_ACPI tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms" default ACPI - depends on X86 && ACPI + depends on X86 && ACPI && PCI select SND_SST_IPC_ACPI select SND_SST_ATOM_HIFI2_PLATFORM select SND_SOC_ACPI_INTEL_MATCH -- 2.19.0
[PATCH v3 01/11] ACPI / LPSS: Make PCI dependency explicit
This code depends on PCI. Compile only when PCI is present.
Signed-off-by: Sinan Kaya
---
drivers/acpi/Makefile | 3 ++-
drivers/acpi/internal.h | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 7c6afc111d76..bb857421c2e8 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,7 +41,8 @@ acpi-y+= ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-$(CONFIG_PCI) += pci_root.o pci_link.o pci_irq.o
obj-$(CONFIG_ACPI_MCFG)+= pci_mcfg.o
-acpi-y += acpi_lpss.o acpi_apd.o
+acpi-$(CONFIG_PCI) += acpi_lpss.o
+acpi-y += acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 7e6952edb5b0..6a9e1fb8913a 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -81,7 +81,11 @@ void acpi_debugfs_init(void);
#else
static inline void acpi_debugfs_init(void) { return; }
#endif
+#ifdef CONFIG_PCI
void acpi_lpss_init(void);
+#else
+static inline void acpi_lpss_init(void) {}
+#endif
void acpi_apd_init(void);
--
2.19.0
[PATCH v3 09/11] mmc: add PCI dependency into IOSF_MBI
Select IOSF_MBI only when PCI is set. Signed-off-by: Sinan Kaya --- drivers/mmc/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index e26b8145efb3..4c5f037b246d 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -117,7 +117,7 @@ config MMC_RICOH_MMC config MMC_SDHCI_ACPI tristate "SDHCI support for ACPI enumerated SDHCI controllers" depends on MMC_SDHCI && ACPI - select IOSF_MBI if X86 + select IOSF_MBI if (X86 && PCI) help This selects support for ACPI enumerated SDHCI controllers, identified by ACPI Compatibility ID PNP0D40 or specific -- 2.19.0
[PATCH v3 03/11] vga-switcheroo: make PCI dependency explicit
This driver depends on the PCI infrastructure but the dependency has not been explicitly called out. Signed-off-by: Sinan Kaya Reviewed-by: Lukas Wunner --- drivers/gpu/vga/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig index b677e5d524e6..d5f1d8e1c6f8 100644 --- a/drivers/gpu/vga/Kconfig +++ b/drivers/gpu/vga/Kconfig @@ -21,6 +21,7 @@ config VGA_SWITCHEROO bool "Laptop Hybrid Graphics - GPU switching support" depends on X86 depends on ACPI + depends on PCI select VGA_ARB help Many laptops released in 2008/9/10 have two GPUs with a multiplexer -- 2.19.0
[PATCH v3 11/11] drivers: thermal: int340x_thermal: Make PCI dependency explicit
IOSF_CORE depends on PCI. This was never mentioned. Signed-off-by: Sinan Kaya --- drivers/thermal/intel/int340x_thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/intel/int340x_thermal/Kconfig b/drivers/thermal/intel/int340x_thermal/Kconfig index fba1976d5f8d..2acddf8fb314 100644 --- a/drivers/thermal/intel/int340x_thermal/Kconfig +++ b/drivers/thermal/intel/int340x_thermal/Kconfig @@ -4,7 +4,7 @@ config INT340X_THERMAL tristate "ACPI INT340X thermal drivers" - depends on X86 && ACPI + depends on X86 && ACPI && PCI select THERMAL_GOV_USER_SPACE select ACPI_THERMAL_REL select ACPI_FAN -- 2.19.0
Re: [PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
On 12/23/2018 8:15 PM, Lukas Wunner wrote:
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
This series doesn't have a cover letter so it's unclear to me through
which tree it's supposed to go in? Each patch through the individual
subsystem tree or all through the same tree? If the former I guess I
could push this to drm-misc...
Feel free to apply individual patches independently. Let me know which
one you applied so that I can drop them on the next rev.
I've realized only now that this patch fixes fallout of commit
5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
which is part of Rafael's acpi pull for v4.21.
Usually such fixes go through the same tree as the offending commit,
so I'd expect Raphael to pick up the whole series and forward it to
Linus in the second half of the merge window. I'm not sure if that's
how it'll play out though given the holidays.
I'll do follow-up with Rafael. Apologize for not giving the full story.
Trying to get pieces out in the middle of vacation as there was a breakage.
I didn't have time to polish.
Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote: > + > +4. Kernel sandbox attacking kernel > +^^ > + > +The kernel has support for running user-supplied programs within the > +kernel. Specific rules (such as bounds checking) are enforced on these > +programs by the kernel to ensure that they do not violate access controls. > + > +eBPF is a kernel sub-system that uses user-supplied program > +to execute JITed untrusted byte code inside the kernel. eBPF is used > +for manipulating and examining network packets, examining system call > +parameters for sand boxes and other uses. > + > +A malicious local process could upload and trigger an malicious > +eBPF script to the kernel, with the script attacking the kernel > +using variant 1 or 2 and reading memory. Above is not correct. The exploit for var2 does not load bpf progs into kernel. Instead the bpf interpreter is speculatively executing bpf prog that was never loaded. Hence CONFIG_BPF_JIT_ALWAYS_ON=y is necessary to make var2 harder to exploit. Same goes for other in kernel interpreters and state machines. > + > +Necessary Prerequisites: > +1. Malicious local process > +2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets > +on the same machine. This is not quite correct either. Var 1 could have been exploited with and without JIT. Also above sounds like that var1 is still exploitable through bpf which is not the case.
Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
>
>
> Den 23.12.2018 01.55, skrev Peter Wu:
> > After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
> > "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
> > have some effect). After that, drm_fb_helper_initial_config is called
> > which may call the "fb_probe" driver callback.
> >
> > This driver callback may call drm_fb_helper_defio_init (as is done by
> > drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
> > as documented. These are normally cleaned up on exit by
> > drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
> >
> > If an error occurs after "fb_probe", but before setup is complete, then
> > calling just drm_fb_helper_fini will leak resources. This was triggered
> > by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
> >
> > [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support
> > this framebuffer
> > [ 50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup]
> > *ERROR* fbdev: Failed to set configuration (ret=-38)
> > [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for
> > :00:02.0 on minor 2
> > [ 50.013604] WARNING: CPU: 1 PID: 1 at
> > drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
> > [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G
> > T 4.20.0-rc7 #1
> > [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
> > ...
> > [ 50.023155] Call Trace:
> > [ 50.023155] ? bochs_kms_fini+0x1e/0x30
> > [ 50.023155] ? bochs_unload+0x18/0x40
> >
> > This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
> >
> > Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
> > Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
> > Fixes: 8741216396b2 ("drm/fb-helper: Add
> > drm_fb_helper_fbdev_setup/teardown()")
> > Reported-by: kernel test robot
> > Cc: Noralf Trønnes
> > Signed-off-by: Peter Wu
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 9d64f874f965..432e0f3b9267 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
> > return 0;
> > err_drm_fb_helper_fini:
> > - drm_fb_helper_fini(fb_helper);
> > + drm_fb_helper_fbdev_teardown(dev);
>
> This change will break the error path for drm_fbdev_generic_setup()
> because drm_fb_helper_generic_probe() cleans up on error but doesn't
> clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
This should probably considered a bug of drm_fb_helper_generic_probe.
Ownership of fb_helper should remain with the caller. The caller can
detect an error and act accordingly.
> My assumption has been that the drm_fb_helper_funcs->fb_probe callback
> cleans up its resources on error. Clearly this is not the case for bochs, so
> my take on this is that bochsfb_create() needs to clean up on error.
That assumption still holds for bochs. The problem is this sequence:
- drm_fb_helper_fbdev_setup is called.
- fb_probe succeeds (this is crucial).
- register_framebuffer fails.
- error path of setup is triggered.
As fb_helper is fully setup by drivers, the drm_fb_helper core should
fully deallocate it again on the error path or else a leak occurs.
> Gerd has a patchset that switches bochs over to the generic fbdev
> emulation, but ofc that doesn't help with 4.20:
> https://patchwork.freedesktop.org/series/54269/
And that does not help with other users of the drm_fb_helper who use
functions like drm_fb_helper_defio_init. They will likely run in the
same problem.
I don't have a way to test tinydrm or other drivers, but if you force
register_framebuffer to fail, you should be able to reproduce the
problem with drm_fb_helper_generic_probe.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro
On Sun, 2018-12-23 at 23:01 +0100, Rasmus Villemoes wrote: > On 21/12/2018 23.20, Joe Perches wrote: [] > > static inline bool str_has_prefix(const char *str, const char prefix[]) [] > We already have exactly that function, it's called strstarts(). Heh. Thanks Rasmus. I didn't remember that one. I think the 'int str_has_prefix' naming and returning the prefix length may be a bit better use than 'bool strstarts' and perhaps a treewide conversion of the existing strstarts to str_has_prefix would be OK as there aren't that many. $ git grep -w strstarts | wc -l 91
Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro
On Sun, 23 Dec 2018 23:01:52 +0100
Rasmus Villemoes wrote:
> On 21/12/2018 23.20, Joe Perches wrote:
> > On Fri, 2018-12-21 at 16:08 -0500, Steven Rostedt wrote:
> >> On Fri, 21 Dec 2018 21:58:32 +0100
> >> Andreas Schwab wrote:
> >>
> >>
> Well, perhaps I can just remove the ending ones. I get paranoid with
> macro variables, and tend to over do it so that there's no question.
> >>>
> >>> Why not make it an inline function?
> >>
> >> Matters if that removes the strlen(const) optimization. I could try it
> >> and see what happens.
> >
> > Using
> >
> > static inline bool str_has_prefix(const char *str, const char prefix[])
> > {
> > return !strncmp(str, prefix, strlen(prefix));
> > }
> >
>
> We already have exactly that function, it's called strstarts().
It's not exact.
>
> commit 66f92cf9d415e96a5bdd6c64de8dd8418595d2fc
> Author: Rusty Russell
> Date: Tue Mar 31 13:05:36 2009 -0600
>
> strstarts: helper function for !strncmp(str, prefix, strlen(prefix))
>
> Please don't add a copy under another name.
>
> As for converting existing users, go for it. FWIW, I ran a cocci script
> a few years ago to find suspicious strncmp() cases, and there were some
> (e87c3f, ca957b6), but fewer than I expected. There are some
> confused/confusing ones that apparently deliberately do strncmp(a, b,
> sizeof(b)) instead of the equivalent to strcmp(a, b) (e.g. 'strncmp(str,
> "hwc", 4) == 0')
Well, one thing that str_has_prefix() does that strstarts() does not,
is to return the prefix length which gets rid of the duplication.
Would it be OK to convert strstarts() to return the length of prefix?
-- Steve
Re: [PATCH 08/20] xfs: xfs_buf: drop useless LIST_HEAD
On Sun, Dec 23, 2018 at 09:57:03AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares has never
> been used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: 26f1fe858f274 ("xfs: reduce lock hold times in buffer writeback")
> Signed-off-by: Julia Lawall
Looks ok; are you planning to push this whole series directly to Linus
or do you want me to take the two xfs patches through?
Reviewed-by: Darrick J. Wong
--D
>
> ---
> Successfully 0-day tested on 151 configurations.
>
> fs/xfs/xfs_buf.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index b21ea2ba768d..eedc5e0156ff 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -1992,7 +1992,6 @@ xfs_buf_delwri_submit_buffers(
> struct list_head*wait_list)
> {
> struct xfs_buf *bp, *n;
> - LIST_HEAD (submit_list);
> int pinned = 0;
> struct blk_plug plug;
>
>
Re: [PATCH 09/20] xfs: xfs_fsops: drop useless LIST_HEAD
On Sun, Dec 23, 2018 at 09:57:04AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> Commit 0410c3bb2b88 ("xfs: factor ag btree root block
> initialisation") stopped using buffer_list and started using a
> buffer list in an aghdr_init_data structure, but the declaration
> of buffer_list was not removed.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: 0410c3bb2b88 ("xfs: factor ag btree root block initialisation")
> Signed-off-by: Julia Lawall
Reviewed-by: Darrick J. Wong
--D
>
> ---
> Successfully 0-day tested on 151 configurations.
>
> fs/xfs/xfs_fsops.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> index ec2e63a7963b..f3ef70c542e1 100644
> --- a/fs/xfs/xfs_fsops.c
> +++ b/fs/xfs/xfs_fsops.c
> @@ -40,7 +40,6 @@ xfs_growfs_data_private(
> xfs_rfsblock_t new;
> xfs_agnumber_t oagcount;
> xfs_trans_t *tp;
> - LIST_HEAD (buffer_list);
> struct aghdr_init_data id = {};
>
> nb = in->newblocks;
>
linux-next: manual merge of the kbuild tree with the mips-fixes tree
Hi all,
Today's linux-next merge of the kbuild tree got a conflict in:
arch/mips/ralink/Kconfig
between commit:
0b15394475e3 ("MIPS: ralink: Select CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8")
from the mips-fixes tree and commit:
eb01d42a7778 ("PCI: consolidate PCI config entry in drivers/pci")
from the kbuild tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/mips/ralink/Kconfig
index 613d61763433,4c8006b4a5f7..
--- a/arch/mips/ralink/Kconfig
+++ b/arch/mips/ralink/Kconfig
@@@ -38,8 -38,7 +38,8 @@@ choic
config SOC_MT7620
bool "MT7620/8"
+ select CPU_MIPSR2_IRQ_VI
- select HW_HAS_PCI
+ select HAVE_PCI
config SOC_MT7621
bool "MT7621"
pgpxYLdmx_j9t.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 07/11] drivers: thermal: Hide PCI driver when CONFIG_PCI is unset
On 12/23/2018 10:48 PM, Rafael J. Wysocki wrote: Can you actually test this driver with your new #ifdef stuff and with CONFIG_PCI unset? Have you really test it in that configuration? No, I haven't. Code was compile tested only. If not, you shouldn't even post this patch. I was hoping the maintainer to chime in. By looking at the code, it was registering a platform and PCI driver. I assumed that it was generic code that can be used with and without PCI. Please make the driver depend on PCI. I can do that.
Re: [PATCH v2 01/11] ACPI / LPSS: Add guards against CONFIG_PCI
On 12/23/2018 10:45 PM, Rafael J. Wysocki wrote: No. Please make this driver depend on PCI instead. Sure.
[rtc] 461e557b97: general_protection_fault:#[##]
FYI, we noticed the following commit (built with gcc-6):
commit: 461e557b97277b693cd8008c32a9d01c7f8f453b ("rtc: nvmem: use
devm_nvmem_register()")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | b28cc6cec3 | 461e557b97 |
+--+++
| boot_successes | 38 | 6 |
| boot_failures| 0 | 11 |
| general_protection_fault:#[##] | 0 | 10 |
| RIP:kernfs_name_hash | 0 | 11 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 11 |
| BUG:unable_to_handle_kernel | 0 | 1 |
| Oops:#[##] | 0 | 1 |
+--+++
[ 109.608578] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 109.619447] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 109.772717] rtc_cmos 00:00: RTC can wake from S4
[ 109.902360] rtc_cmos 00:00: registered as rtc0
[ 109.942570] rtc_cmos 00:00: alarms up to one day, y3k, 114 bytes nvram, hpet
irqs
[ 109.954719] general protection fault: [#1] PREEMPT SMP PTI
[ 109.958901] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GT
4.20.0-rc1-9-g461e557 #1
[ 109.958901] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 109.958901] RIP: 0010:kernfs_name_hash+0x13/0x77
[ 109.958901] Code: 36 c2 81 74 04 48 8b 77 40 48 89 df e8 ea 9f 37 00 5a 5b
41 5c 5d c3 55 31 c0 48 89 e5 53 51 48 89 75 f0 48 83 c9 ff 48 89 fb ae 48
f7 d1 8d 79 ff 31 c9 48 39 cf 74 1f 48 0f be 04 0b 48 ff
[ 109.958901] RSP: :880107c6bbd0 EFLAGS: 00010286
[ 109.958901] RAX: RBX: 00306d6172766e5f RCX:
[ 109.958901] RDX: 81e48650 RSI: RDI: 00306d6172766e5f
[ 109.958901] RBP: 880107c6bbe0 R08: 0002 R09:
[ 109.958901] R10: 880107c6bc10 R11: R12: 00306d617276
[ 109.958901] R13: 00306d6172766e5f R14: R15: 880107e8c8a0
[ 109.958901] FS: () GS:88023780()
knlGS:
[ 109.958901] CS: 0010 DS: ES: CR0: 80050033
[ 109.958901] CR2: CR3: 01e12000 CR4: 000406b0
[ 109.958901] Call Trace:
[ 109.958901] kernfs_find_ns+0x8d/0xd7
[ 109.958901] kernfs_remove_by_name_ns+0x48/0x74
[ 109.958901] sysfs_remove_bin_file+0x15/0x1a
[ 109.958901] rtc_nvmem_unregister+0x1d/0x20
[ 109.958901] devm_rtc_release_device+0x10/0x2b
[ 109.958901] release_nodes+0x143/0x166
[ 109.958901] devres_release_all+0x3f/0x42
[ 109.958901] really_probe+0x184/0x43b
[ 109.958901] driver_probe_device+0xd3/0x109
[ 109.958901] __driver_attach+0xbb/0xed
[ 109.958901] ? driver_probe_device+0x109/0x109
[ 109.958901] bus_for_each_dev+0x64/0x84
[ 109.958901] driver_attach+0x1d/0x20
[ 109.958901] bus_add_driver+0x12e/0x215
[ 109.958901] ? abb5zes3_driver_init+0x3e/0x3e
[ 109.958901] driver_register+0x9e/0xd5
[ 109.958901] ? abb5zes3_driver_init+0x3e/0x3e
[ 109.958901] pnp_register_driver+0x1d/0x20
[ 109.958901] cmos_init+0x29/0x124
[ 109.958901] do_one_initcall+0x64/0x13a
[ 109.958901] kernel_init_freeable+0x1f5/0x312
[ 109.958901] ? rest_init+0xf1/0xf1
[ 109.958901] kernel_init+0x9/0xf5
[ 109.958901] ret_from_fork+0x1f/0x30
[ 109.958901] Modules linked in:
[ 110.136281] _warn_unseeded_randomness: 532 callbacks suppressed
[ 110.136448] random: get_random_bytes called from init_oops_id+0x21/0x32 with
crng_init=0
[ 110.146604] ---[ end trace efccaee9b41f1345 ]---
[ 110.168116] RIP: 0010:kernfs_name_hash+0x13/0x77
[ 110.172161] Code: 36 c2 81 74 04 48 8b 77 40 48 89 df e8 ea 9f 37 00 5a 5b
41 5c 5d c3 55 31 c0 48 89 e5 53 51 48 89 75 f0 48 83 c9 ff 48 89 fb ae 48
f7 d1 8d 79 ff 31 c9 48 39 cf 74 1f 48 0f be 04 0b 48 ff
[ 110.201209] RSP: :880107c6bbd0 EFLAGS: 00010286
[ 110.204379] RAX: RBX: 00306d6172766e5f RCX:
[ 110.222891] RDX: 81e48650 RSI: RDI: 00306d6172766e5f
[ 110.229003] RBP: 880107c6bbe0 R08: 0002 R09:
[ 110.247797] R10: 880107c6bc10 R11: R12: 00306d617276
[ 110.252327] R13: 00306d6172766e5f R14: R15: 880107e8c8a0
[ 110.270803] FS:
[GIT PULL] hwmon updates for v4.21
Hi Linus,
Please pull hwmon updates for Linux v4.21 from signed tag:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-for-v4.21
Thanks,
Guenter
--
The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
tags/hwmon-for-v4.21
for you to fetch changes up to 9aa3aa15f4c2f74f47afd6c5db4b420fadf3f315:
hwmon: (lm80) fix a missing check of bus read in lm80 probe (2018-12-21
15:37:59 -0800)
hwmon updates for v4.21
The big change in this series is for the most part automatic: Introducing
SENSOR[_DEVICE]_ATTR_{RO,RW,WO} variants and conversion of various drivers
to use it. This is similar to DEVICE_ATTR variants.
Other than that, we have
- Some conversions of S_ with octal values, also automated
- Added support for Hygon Dhyana CPUs to k10temp driver
- Added support for STLM75 to lm75 driver
- B57891S0103 to ntc_thermistor
- Added pm-runtime support to ina3221 driver
- Support for PowerPC On-Chip Controller (OCC)
- Various minor bug fices and improvements
Chris Packham (1):
hwmon: (adt7475) document mapping of sysfs entries to inputs
Colin Ian King (1):
hwmon: (ltc2978) Fix spelling mistake "comppatible" -> "compatible"
Corentin Labbe (2):
hwmon: fix typo build -> built
hwmon: Remove multiple space after dot
Eddie James (10):
dt-bindings: fsi: Add P9 OCC device documentation
fsi: Add On-Chip Controller (OCC) driver
Documentation: hwmon: Add OCC documentation
dt-bindings: i2c: Add P8 OCC hwmon device documentation
hwmon: Add On-Chip Controller (OCC) hwmon driver
hwmon (occ): Add command transport method for P8 and P9
hwmon (occ): Parse OCC poll response
hwmon (occ): Add sensor types and versions
hwmon (occ): Add sensor attributes and register hwmon device
hwmon (occ): Add sysfs attributes for additional OCC data
Guenter Roeck (43):
hwmon: Introduce SENSOR_DEVICE_ATTR_{RO, RW, WO} and variants
hwmon: (ltc2945): Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (k10temp) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (lm95234) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (nct7802) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (ltc4260) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (max6650) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (ntc_thermistor) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW,
WO}
hwmon: (pwm-fan) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (max6697) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (tmp401) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (ina2xx) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (ltc4215) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}
hwmon: (abx500) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (acpi_power_meter) Replace S_ with octal values
hwmon: (ad7314) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (ad7414) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (ad7418) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adc128d818) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adcxx) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adm1021) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (ads1015) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (ads7828) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (ads7871) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adt7462) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adt7470) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adt7475) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (adt7x10) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (amc6821) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (applesmc) Replace S_ with octal values
hwmon: (aspeed-pwm-tacho) Use permission specific SENSOR[_DEVICE]_ATTR
variants
hwmon: (asus_atk0110) Replace S_ with octal values
hwmon: (coretemp) Replace S_ with octal values
hwmon: (da9052-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR
variants
hwmon: (da9055-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR
variants
hwmon: (dell-smm-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR
variants
hwmon: (ds1621) Use permission specific SENSOR[_DEVICE]_ATTR variants
hwmon: (ds620) Use
linux-next: manual merge of the mips-fixes tree with Linus' tree
Hi all,
Today's linux-next merge of the mips-fixes tree got a conflict in:
MAINTAINERS
between commit:
6584297b78b6 ("MAINTAINERS: Update linux-mips mailing list address")
from Linus' tree and commit:
9bd2f7eeaed1 ("MAINTAINERS: Add a maintainer for MSCC MIPS SoCs")
from the mips-fixes tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index f3a5c97e3419,50223cba6ddb..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -9912,8 -9801,9 +9912,9 @@@ F: drivers/dma/at_xdmac.
MICROSEMI MIPS SOCS
M:Alexandre Belloni
+ M:Microchip Linux Driver Support
-L:linux-m...@linux-mips.org
+L:linux-m...@vger.kernel.org
- S:Maintained
+ S:Supported
F:arch/mips/generic/board-ocelot.c
F:arch/mips/configs/generic/board-ocelot.config
F:arch/mips/boot/dts/mscc/
pgpuqhaBkwvAI.pgp
Description: OpenPGP digital signature
Re: [PATCH 00/20] drop useless LIST_HEAD
On Sun, 23 Dec 2018, Tom Psyborg wrote: > Why do you CC this to so many lists? Because the different files are in different subsystems. The cover letter goes to a list for each file, or to a person if there is no list. The patches go to the people and lists associated with the affected files. julia > > On 23/12/2018, Julia Lawall wrote: > > Drop LIST_HEAD where the variable it declares is never used. > > > > --- > > > > drivers/dma/at_hdmac.c|5 - > > drivers/dma/dw/core.c |1 - > > drivers/dma/pl330.c |1 - > > drivers/dma/sa11x0-dma.c |2 -- > > drivers/dma/st_fdma.c |3 --- > > drivers/infiniband/ulp/ipoib/ipoib_ib.c |1 - > > drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |5 - > > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c |3 --- > > drivers/net/ethernet/mellanox/mlxsw/spectrum.c|1 - > > drivers/net/wireless/st/cw1200/queue.c|1 - > > drivers/scsi/lpfc/lpfc_nvme.c |2 -- > > drivers/scsi/lpfc/lpfc_scsi.c |2 -- > > drivers/scsi/lpfc/lpfc_sli.c |1 - > > drivers/scsi/qla2xxx/qla_init.c |1 - > > drivers/xen/xenbus/xenbus_dev_frontend.c |2 -- > > fs/btrfs/relocation.c |1 - > > fs/nfs/nfs4client.c |1 - > > fs/nfsd/nfs4layouts.c |1 - > > fs/xfs/xfs_buf.c |1 - > > fs/xfs/xfs_fsops.c|1 - > > 20 files changed, 36 deletions(-) > > >
Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro
On 21/12/2018 23.20, Joe Perches wrote:
> On Fri, 2018-12-21 at 16:08 -0500, Steven Rostedt wrote:
>> On Fri, 21 Dec 2018 21:58:32 +0100
>> Andreas Schwab wrote:
>>
>>
Well, perhaps I can just remove the ending ones. I get paranoid with
macro variables, and tend to over do it so that there's no question.
>>>
>>> Why not make it an inline function?
>>
>> Matters if that removes the strlen(const) optimization. I could try it
>> and see what happens.
>
> Using
>
> static inline bool str_has_prefix(const char *str, const char prefix[])
> {
> return !strncmp(str, prefix, strlen(prefix));
> }
>
We already have exactly that function, it's called strstarts().
commit 66f92cf9d415e96a5bdd6c64de8dd8418595d2fc
Author: Rusty Russell
Date: Tue Mar 31 13:05:36 2009 -0600
strstarts: helper function for !strncmp(str, prefix, strlen(prefix))
Please don't add a copy under another name.
As for converting existing users, go for it. FWIW, I ran a cocci script
a few years ago to find suspicious strncmp() cases, and there were some
(e87c3f, ca957b6), but fewer than I expected. There are some
confused/confusing ones that apparently deliberately do strncmp(a, b,
sizeof(b)) instead of the equivalent to strcmp(a, b) (e.g. 'strncmp(str,
"hwc", 4) == 0')
Rasmus
[PATCH v4 1/2] drm/amd: validate user pitch alignment
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
For GPU that does frame buffer compression, DMA writing out of bound
memory will cause memory corruption.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 686a26de50f9..af0626a2b528 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ struct amdgpu_device *adev = dev->dev_private;
+ int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
+ int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false);
+
+ if (mode_cmd->pitches[0] != pitch) {
+ DRM_DEBUG_KMS("Invalid pitch: expecting %d but got %d\n",
+ pitch, mode_cmd->pitches[0]);
+ return ERR_PTR(-EINVAL);
+ }
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (obj == NULL) {
--
2.20.1.415.g653613c723-goog
[PATCH v4 2/2] drm/amd: validate user GEM object size
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
which could not only corrupt memory but also reveal sensitive data.
This fix is not done in a common code path because individual
driver might have different requirement.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index af0626a2b528..9aa23cb20873 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,7 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ int height;
struct amdgpu_device *adev = dev->dev_private;
int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false);
@@ -550,6 +551,13 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-EINVAL);
}
+ height = ALIGN(mode_cmd->height, 8);
+ if (obj->size < pitch * height) {
+ DRM_DEBUG_KMS("Invalid GEM size: expecting >= %d but got %zu\n",
+ pitch * height, obj->size);
+ return ERR_PTR(-EINVAL);
+ }
+
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
drm_gem_object_put_unlocked(obj);
--
2.20.1.415.g653613c723-goog
Re: [PATCH 00/20] drop useless LIST_HEAD
Why do you CC this to so many lists? On 23/12/2018, Julia Lawall wrote: > Drop LIST_HEAD where the variable it declares is never used. > > --- > > drivers/dma/at_hdmac.c|5 - > drivers/dma/dw/core.c |1 - > drivers/dma/pl330.c |1 - > drivers/dma/sa11x0-dma.c |2 -- > drivers/dma/st_fdma.c |3 --- > drivers/infiniband/ulp/ipoib/ipoib_ib.c |1 - > drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |5 - > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c |3 --- > drivers/net/ethernet/mellanox/mlxsw/spectrum.c|1 - > drivers/net/wireless/st/cw1200/queue.c|1 - > drivers/scsi/lpfc/lpfc_nvme.c |2 -- > drivers/scsi/lpfc/lpfc_scsi.c |2 -- > drivers/scsi/lpfc/lpfc_sli.c |1 - > drivers/scsi/qla2xxx/qla_init.c |1 - > drivers/xen/xenbus/xenbus_dev_frontend.c |2 -- > fs/btrfs/relocation.c |1 - > fs/nfs/nfs4client.c |1 - > fs/nfsd/nfs4layouts.c |1 - > fs/xfs/xfs_buf.c |1 - > fs/xfs/xfs_fsops.c|1 - > 20 files changed, 36 deletions(-) >
Re: [PATCH v2 07/11] drivers: thermal: Hide PCI driver when CONFIG_PCI is unset
On Sat, Dec 22, 2018 at 6:49 PM Sinan Kaya wrote:
>
> This driver is both a platform and PCI driver. Hide PCI specific pieces
> when CONFIG_PCI is unset.
>
> Signed-off-by: Sinan Kaya
> ---
> .../intel/int340x_thermal/processor_thermal_device.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> index 284cf2c5a8fd..b84a475a1162 100644
> --- a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> +++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> @@ -374,6 +374,7 @@ static int int3401_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PCI
> static irqreturn_t proc_thermal_pci_msi_irq(int irq, void *devid)
> {
> struct proc_thermal_device *proc_priv;
> @@ -482,6 +483,7 @@ static struct pci_driver proc_thermal_pci_driver = {
> .remove = proc_thermal_pci_remove,
> .id_table = proc_thermal_pci_ids,
> };
> +#endif
>
> static const struct acpi_device_id int3401_device_ids[] = {
> {"INT3401", 0},
> @@ -505,16 +507,18 @@ static int __init proc_thermal_init(void)
> ret = platform_driver_register(_driver);
> if (ret)
> return ret;
> -
> +#ifdef CONFIG_PCI
> ret = pci_register_driver(_thermal_pci_driver);
> -
> +#endif
> return ret;
> }
>
> static void __exit proc_thermal_exit(void)
> {
> platform_driver_unregister(_driver);
> +#ifdef CONFIG_PCI
> pci_unregister_driver(_thermal_pci_driver);
> +#endif
> }
>
> module_init(proc_thermal_init);
Can you actually test this driver with your new #ifdef stuff and with
CONFIG_PCI unset?
Have you really test it in that configuration?
If not, you shouldn't even post this patch.
Please make the driver depend on PCI.
Re: [PATCH 2/3] drm/amd: validate user pitch alignment
On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote: > On 2018-12-21 4:10 a.m., Yu Zhao wrote: > > Userspace may request pitch alignment that is not supported by GPU. > > Some requests 32, but GPU ignores it and uses default 64 when cpp is > > 4. If GEM object is allocated based on the smaller alignment, GPU > > DMA will go out of bound. > > > > For GPU that does frame buffer compression, DMA writing out of bound > > memory will cause memory corruption. > > > > Signed-off-by: Yu Zhao > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > index e309d26170db..755daa332f8a 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > @@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct > > drm_device *dev, > > struct drm_gem_object *obj; > > struct amdgpu_framebuffer *amdgpu_fb; > > int ret; > > + struct amdgpu_device *adev = dev->dev_private; > > + int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0); > > + int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false); > > Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width, > otherwise it'll spuriously fail for larger but well-aligned pitches. Actually mode_cmd->pitches[0] is aligned mode_cmd->width multiplied by cpp. So we can't just use mode_cmd->pitches[0]. And I'm not sure if the hardware works with larger alignment (it certainly ignores smaller alignment).
Re: [PATCH v2 01/11] ACPI / LPSS: Add guards against CONFIG_PCI
On Sat, Dec 22, 2018 at 6:49 PM Sinan Kaya wrote: > > We can now compile ACPI without PCI support. If code depends on CONFIG_PCI, > it needs to explicitly guard that piece. > > Signed-off-by: Sinan Kaya > --- > drivers/acpi/acpi_lpss.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c > index 5f94c35d165f..4148abcdf9ef 100644 > --- a/drivers/acpi/acpi_lpss.c > +++ b/drivers/acpi/acpi_lpss.c > @@ -534,8 +534,11 @@ static struct device *acpi_lpss_find_device(const char > *hid, const char *uid) > dev = bus_find_device(_bus_type, NULL, , match_hid_uid); > if (dev) > return dev; > - > +#ifdef CONFIG_PCI > return bus_find_device(_bus_type, NULL, , match_hid_uid); > +#else > + return NULL; > +#endif > } No. Please make this driver depend on PCI instead. > > static bool acpi_lpss_dep(struct acpi_device *adev, acpi_handle handle)
Re: [PATCH 01/20] nfsd: drop useless LIST_HEAD
Applied, thanks.--b.
On Sun, Dec 23, 2018 at 09:56:56AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> This was introduced in c5c707f96fc9a ("nfsd: implement pNFS
> layout recalls"), but was not used even in that commit.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: c5c707f96fc9a ("nfsd: implement pNFS layout recalls")
> Signed-off-by: Julia Lawall
>
> ---
> Successfully 0-day tested on 151 configurations.
>
> fs/nfsd/nfs4layouts.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
> index 2b36aa037ce0..44517fb5c0de 100644
> --- a/fs/nfsd/nfs4layouts.c
> +++ b/fs/nfsd/nfs4layouts.c
> @@ -656,7 +656,6 @@ nfsd4_cb_layout_done(struct nfsd4_callback *cb, struct
> rpc_task *task)
> struct nfsd_net *nn;
> ktime_t now, cutoff;
> const struct nfsd4_layout_ops *ops;
> - LIST_HEAD(reaplist);
>
>
> switch (task->tk_status) {
Re: x86/sgx: uapi change proposal
On Sun, Dec 23, 2018 at 4:52 AM Jarkko Sakkinen wrote: > > On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote: > > On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote: > > > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote: > > > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote: > > > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just > > > > > opening a new instance of /dev/sgx for each encalve? > > > > > > > > I think that fits better to the SCM_RIGHTS scenario i.e. you could send > > > > the enclav to a process that does not have necessarily have rights to > > > > /dev/sgx. Gives more robust environment to configure SGX. > > > > > > Sean, is this why you wanted enclave fd and anon inode and not just use > > > the address space of /dev/sgx? Just taking notes of all observations. > > > I'm not sure what your rationale was (maybe it was somewhere). This was > > > something I made up, and this one is wrong deduction. You can easily > > > get the same benefit with /dev/sgx associated fd representing the > > > enclave. > > > > > > This all means that for v19 I'm going without enclave fd involved with > > > fd to /dev/sgx representing the enclave. No anon inodes will be > > > involved. > > > > Based on these observations I updated the uapi. > > > > As far as I'm concerned there has to be a solution to do EPC mapping > > with a sequence: > > > > 1. Ping /dev/kvm to do something. > > 2. KVM asks SGX core to do something. > > 3. SGX core does something. > > > > I don't care what the something is exactly is, but KVM is the only sane > > place for KVM uapi. I would be surprised if KVM maintainers didn't agree > > that they don't want to sprinkle KVM uapi to random places in other > > subsystems. > > The one option to consider to do would be to have a device driver for > KVM if you really want this e.g. something like /dev/vsgx. With the > current knowledge I'm not yet sure why all could not be done just > through /dev/kvm. > That seems reasonable too. I don't really care about the path to the device node, but it does seem reasonable to me to have it be a separate node entirely from the normal enclave interface.
Re: x86/sgx: uapi change proposal
> On Dec 21, 2018, at 11:24 AM, Sean Christopherson
> wrote:
>
> On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote:
>>> On Dec 21, 2018, at 9:28 AM, Sean Christopherson
>>> wrote:
>>>
>>> On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote:
> On Dec 19, 2018, at 6:45 AM, Sean Christopherson
> wrote:
>
>>> On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote:
>
> I agree with Jethro, passing the enclave_fd as a param is obnoxious.
> And it means the user needs to open /dev/sgx to do anything with an
> enclave fd, e.g. the enclave fd might be passed to a builder thread,
> it shouldn't also need the device fd.
>
> E.g.:
>
> sgx_fd = open("/dev/sgx", O_RDWR);
> BUG_ON(sgx_fd < 0);
>
> enclave_fd = ioctl(sgx_fd, SGX_ENCLAVE_CREATE, );
> BUG_ON(enclave_fd < 0);
>
> ret = ioctl(enclave_fd, SGX_ENCLAVE_ADD_PAGE, );
> BUG_ON(ret);
>
> ...
>
> ret = ioctl(enclave_fd, SGX_ENCLAVE_INIT, );
> BUG_ON(ret);
>
> ...
>
> close(enclave_fd);
> close(sgx_fd);
>
>
> Take a look at virt/kvm/kvm_main.c to see how KVM manages anon inodes
> and ioctls for VMs and vCPUs.
Can one of you explain why SGX_ENCLAVE_CREATE is better than just
opening a new instance of /dev/sgx for each encalve?
>>>
>>> Directly associating /dev/sgx with an enclave means /dev/sgx can't be
>>> used to provide ioctl()'s for other SGX-related needs, e.g. to mmap()
>>> raw EPC and expose it a VM. Proposed layout in the link below. I'll
>>> also respond to Jarkko's question about exposing EPC through /dev/sgx
>>> instead of having KVM allocate it on behalf of the VM.
>>
>> Hmm. I guess this makes some sense. My instinct would be to do it a
>> little differently and have:
>>
>> /dev/sgx/enclave: Each instance is an enclave.
>>
>> /dev/sgx/epc: Used to get raw EPC for KVM. Might have different
>> permissions, perhaps 0660 and group kvm.
>>
>> /dev/sgx/something_else: For when SGX v3 adds something else :)
>
> Mmmm, I like this approach a lot. It would allow userspace to easily
> manage permissions for each "feature", e.g. give all users access to
> /dev/sgx/epc but restrict /dev/sgx/enclave.
>
> And we could add e.g. /dev/sgx/admin if we wanted to exposed ioctls()
> that apply to all aspects of SGX.
>
> Do you know if /dev/sgx/epc could be dynamically created, e.g. by
> KVM when the kvm_intel module is loaded?
Presumably sgx would create a bus and enumerate the devices as needed.
Or I suppose these things could be platform or system devices. I’m not
really a device model expert, and the one time I tried to implement a
character device, I got so disgusted that I wrote a whole library for
it. It’s still in limbo somewhere.
> That would seal the deal for
> me as it'd keep open the option of having KVM handle oversubscription
> of guest EPC while exposing EPC through /dev/sgx instead of /dev/kvm.
Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties
On 12/12/18 7:32 PM, Pavel Machek wrote:
On Wed 2018-12-12 07:56:20, Rob Herring wrote:
On Wed, Dec 12, 2018 at 3:59 AM Pavel Machek wrote:
Hi!
We would also probably need different DT properties for different
types of devices, since e.g. for network case the network interface
name would fit better for the LED name, than the phy name,
and we would need to know what type of device name we're going
to look for.
Pavel gave following examples:
eth0:green:link
adsl0:green:link
adsl0:red:error
So we would have e.g.:
associated-vl42-device = <>;
associated-network-device = <>;
associated-block-device = <>;
Variable property names are kind of a pain to parse.
Perhaps when LEDs are associated with a device, we shouldn't care
within the context of the LED subsystem what the name is. The
association is more important and if you have that exposed, then you
don't really need to care what the name is. You still have to deal
with a device with more than 1 LED, but that becomes a problem local
to that device.
What I'm getting at is following a more standard binding pattern of
providers and consumers like we have for gpios, clocks, etc. So we'd
have something like this:
ethernet {
...
leds = <_led>, <_led>;
led-names = "link", "err";
};
We can still support defining LED names as we've done, but we don't
have to come up with some elaborate naming convention that covers
every single case.
I see that it would be more consistent with how gpios work, but I'm
afraid this does not fit LEDs properly.
With power LED, you want to be able to say "this is just on". Some
poeple like heartbeat, and have LED for that. There may be LED for
"disk activity", meaning activity on any harddrive. And there may be
activity LED for specific disk.
Only in the last case it would be suitable to have LED reference as a
child of an device...
Right. For all the other cases, why do you need any link with a
device? What we have today is sufficient and can continue to be
supported. A link to a device is only used if the led is associated
with a particular device.
Right, so the link is only needed in some cases. So unlike your
example, we would have:
led1 { led-meaning = "heartbeat"; }
led2 { led-meaning = "link"; }
led3 { led-meaning = "err"; }
led4 { led-meaning = "activity"; what-activity = "all_harddisks"; }
ethernet { leds = < , >; }
Dunno. I'd expect all the LED description in the LED node, not part of
the description there and back link from the device
Driven by the feeling that it's all going in a wrong direction
I've done a bit more analysis - please refer below to my conclusions.
We already have a means for associating LEDs connected to standalone LED
controllers with other devices - this is LED trigger mechanism.
The association can be discovered by reading "trigger" sysfs file.
Device drivers can even create their own custom triggers, comprising
device node name or phy name in their names, which are known only during
driver probing, which allows to better describe the association than the
generic ones.
When it comes to devices with built-in LEDs - let's check how network
devices handle their LEDs. I've looked into ralink wireless driver:
drivers/net/wireless/ralink/rt2x00/rt2x00leds.c
It registers its LEDs in rt2x00leds_register(),
and composes names according to the following pattern:
snprintf(name, sizeof(name), "%s-%s::assoc",
rt2x00dev->ops->name, phy_name);
snprintf(name, sizeof(name), "%s-%s::quality",
rt2x00dev->ops->name, phy_name);
snprintf(name, sizeof(name), "%s-%s::radio",
rt2x00dev->ops->name, phy_name);
which results in the following LED names for wifi dongle:
rt73usb-phy16::assoc ->
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/leds/rt73usb-phy16::assoc
rt73usb-phy16::quality ->
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/leds/rt73usb-phy16::quality
rt73usb-phy16::radio ->
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/leds/rt73usb-phy16::radio
As it is shown, each entry under /sys/class/CLASS_NAME is a symbolic
link to the class device sub-directory located in the parent device
directory. In this case, even if we hadn't phy name in the LED name,
we could retrieve it by traversing parent device directory in the
sysfs:
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/ieee80211/phy16/
We have also available additional device and driver specific info
in the uevent file:
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/uevent:DEVTYPE=usb_interface
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/uevent:DRIVER=rt73usb
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/uevent:PRODUCT=148f/2573/1
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/uevent:TYPE=0/0/0
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/uevent:INTERFACE=255/255/255
../../devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/uevent:MODALIAS=usb:v148Fp2573d0001dc00dsc00dp00icFFiscFFipFFin00
In addition to
Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver
On Sun 2018-12-23 07:51:47, Tony Lindgren wrote:
> * Pavel Machek [181223 11:11]:
> > I added some printks to motmdm_probe, and they don't appear to be
> > called. I wonder if I'm missing something else in the config? I do
> > have serial
> >
> > root@devuan:/my/ko# ls -al /dev/ttyS0
> > crw-rw 1 root dialout 4, 64 Dec 23 11:52 /dev/ttyS0
> >
> > but not gsm multiplex:
> >
> > root@devuan:/my/ko# ls -al /dev/gsm*
> > ls: cannot access '/dev/gsm*': No such file or directory
>
> Hmm with serdev you should not get /dev/ttyS0, so maybe you're missing:
>
> CONFIG_SERIAL_DEV_BUS=y
> CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
I had those enabled.
I also have
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
> Probably the Kconfig dependency should be for SERIAL_DEV_CTRL_TTYPORT
> instead of SERIAL_DEV_BUS in these patches if that helps.
>
> Or else you're missing the serdev related dts changes?
Thanks for the hints, but dts looks ok, too.
We still have
uart1: serial@0 {
compatible = "ti,omap4-uart";
in omap4-l4.dtsi, right? ...
I see that CONFIG_SERIAL_OMAP=y and 8250_omap handles same
hardware. Let me try disabling CONFIG_SERIAL_OMAP=y.
Best regards,
Pavel
Oh and you may want to apply this:
diff --git a/drivers/mfd/motorola-mdm.c b/drivers/mfd/motorola-mdm.c
index 2b7c324..2cdc9e8 100644
--- a/drivers/mfd/motorola-mdm.c
+++ b/drivers/mfd/motorola-mdm.c
@@ -1141,5 +1152,5 @@ module_serdev_device_driver(motmdm_driver);
MODULE_ALIAS("platform:motorola-mdm");
MODULE_DESCRIPTION("Motorola Modem TS 27.010 serdev driver");
-MODULE_AUTHOR("Tony Lindgren ");
MODULE_LICENSE("GPL v2");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH][trivial] fix email address quoting in MODULE_AUTHOR()
On Sun, 2018-12-23 at 20:27 +0100, Pavel Machek wrote: > > Apparently it is quite easy to forget ">" in quoting of email > address. This fixes it. It's good you do this, thanks. Please use git diff --stat -p when you produce these or git format-patch so there is an easy to read list of files modified in this patch.
[BUG] net: sungem: device driver frees DMA memory with wrong function
Hello During a boot on a qemu machine, I hit the following problem: [ 21.613659] [ cut here ] [ 21.614039] DMA-API: gem :00:0f.0: device driver frees DMA memory with wrong function [device address=0x185c5402] [size=408 bytes] [mapped as page] [unmapped as single] [ 21.615960] WARNING: CPU: 0 PID: 206 at /linux-next/kernel/dma/debug.c:1085 check_unmap+0x1b0/0xd10 [ 21.616599] Modules linked in: [ 21.617344] CPU: 0 PID: 206 Comm: dhcpcd Not tainted 4.20.0-rc6-next-20181217+ #12 [ 21.617735] NIP: c00ad4e0 LR: c00ad4e0 CTR: c058a710 [ 21.618068] REGS: dfff7cb0 TRAP: 0700 Not tainted (4.20.0-rc6-next-20181217+) [ 21.618404] MSR: 00021032 CR: 28008264 XER: [ 21.618789] [ 21.618789] GPR00: c00ad4e0 dfff7d60 d85924c0 00a8 0102 0101 00fe 5d205b6d [ 21.618789] GPR08: 0007 00fe 22008864 100581b4 dfff7f1c de019508 [ 21.618789] GPR16: de019000 0001 c0a67f00 0004 c0b44018 c0a31fc4 c0b43bdc [ 21.618789] GPR24: 9032 c0dadedc c0db c0da999c c0b43bdc c0c0b178 dfff7de0 de076ce8 [ 21.620219] NIP [c00ad4e0] check_unmap+0x1b0/0xd10 [ 21.620478] LR [c00ad4e0] check_unmap+0x1b0/0xd10 [ 21.620703] Call Trace: [ 21.620963] [dfff7d60] [c00ad4e0] check_unmap+0x1b0/0xd10 (unreliable) [ 21.621379] [dfff7dd0] [c00ae128] debug_dma_unmap_page+0xe8/0x120 [ 21.621656] [dfff7e40] [c05a865c] gem_poll+0x1000/0x18fc [ 21.621863] [dfff7f00] [c071f044] net_rx_action+0x1b8/0x41c [ 21.622242] [dfff7f80] [c08a287c] __do_softirq+0x17c/0x3b0 [ 21.622495] [dfff7ff0] [c0011378] call_do_softirq+0x24/0x3c [ 21.622697] [d86c9c20] [c000724c] do_softirq_own_stack+0x3c/0x7c [ 21.623008] [d86c9c40] [c004e800] do_softirq.part.1+0x64/0x7c [ 21.623292] [d86c9c60] [c004e8d4] __local_bh_enable_ip+0xbc/0x138 [ 21.623526] [d86c9c80] [c071c9b4] __dev_queue_xmit+0x28c/0x874 [ 21.623776] [d86c9cf0] [c083ebe8] packet_snd+0x4f8/0x988 [ 21.624057] [d86c9d80] [c06eddb8] sock_sendmsg+0x20/0x40 [ 21.624410] [d86c9d90] [c06ede94] sock_write_iter+0xbc/0x138 [ 21.624636] [d86c9df0] [c018f50c] do_iter_readv_writev+0x1dc/0x1f4 [ 21.624872] [d86c9e40] [c01925a8] do_iter_write+0xb4/0x350 [ 21.625143] [d86c9e80] [c01928f4] vfs_writev+0x88/0x140 [ 21.625446] [d86c9f00] [c0192a1c] do_writev+0x70/0x104 [ 21.625621] [d86c9f40] [c001912c] ret_from_syscall+0x0/0x38 [ 21.626001] --- interrupt: c01 at 0xfedbd08 [ 21.626001] LR = 0xffbc1f8 [ 21.626357] Instruction dump: [ 21.626719] 7eb5ba14 7e95a214 2b940014 419d0970 92c10008 7efcba14 3c60c0a1 7e649b78 [ 21.627152] 38637cac 80d7043c 90c1000c 4bf9d36d <0fe0> 8261003c 82810040 82a10044 [ 21.627665] ---[ end trace fd53714bd2a5fd06 ]--- After some pr_info, I found that the function triggering this is the pci_unmap_page() in gem_tx(). So clearly this WARNING() is strange since it says "unmapped as single". The qemu is ran with: qemu-system-ppc -machine mac99,via=pmu -nographic -net nic,model=sungem,macaddr=52:54:00:12:34:58 -net tap -m 512 -monitor none -append "console=ttyPZ0 root=/dev/ram0" -kernel vmlinux -initrd rootfs.cpio.gz -drive format=qcow2,file=lava-guest.qcow2,media=disk,id=test,if=ide Regards
Re: [GIT PULL] timer fix
On Fri, Dec 21, 2018 at 01:34:53PM +0100, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest timers-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> timers-urgent-for-linus
>
># HEAD: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 posix-timers: Fix
> division by zero bug
>
> Fix a division by zero crash in the posix-timers code.
>
> Thanks,
>
> Ingo
>
> -->
> Thomas Gleixner (1):
> posix-timers: Fix division by zero bug
>
>
> kernel/time/posix-timers.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> index bd62b5eeb5a0..31f49ae80f43 100644
> --- a/kernel/time/posix-timers.c
> +++ b/kernel/time/posix-timers.c
> @@ -289,9 +289,6 @@ static void common_hrtimer_rearm(struct k_itimer *timr)
> {
> struct hrtimer *timer = >it.real.timer;
>
> - if (!timr->it_interval)
> - return;
> -
> timr->it_overrun += hrtimer_forward(timer, timer->base->get_time(),
> timr->it_interval);
> hrtimer_restart(timer);
> @@ -317,7 +314,7 @@ void posixtimer_rearm(struct kernel_siginfo *info)
> if (!timr)
> return;
>
> - if (timr->it_requeue_pending == info->si_sys_private) {
> + if (timr->it_interval && timr->it_requeue_pending ==
> info->si_sys_private) {
> timr->kclock->timer_rearm(timr);
FWIW, with this patch the vanilla glibc 2.28 self tests
rt/tst-cputimer1, rt/tst-cputimer2, and rt/tst-cputimer3
start to fail on s390:
rt/tst-cputimer1.out:
clock_gettime returned timespec = { 0, 117181 }
clock_getres returned timespec = { 0, 1 }
Timed out: killed the child process
rt/tst-cputimer1.test-result:
FAIL: rt/tst-cputimer1
original exit status 1
rt/tst-cputimer2.out:
clock_gettime returned timespec = { 0, 9686 }
clock_getres returned timespec = { 0, 1 }
Timed out: killed the child process
rt/tst-cputimer2.test-result:
FAIL: rt/tst-cputimer2
original exit status 1
rt/tst-cputimer3.out:
clock_gettime returned timespec = { 0, 0 }
clock_getres returned timespec = { 0, 1 }
Timed out: killed the child process
rt/tst-cputimer3.test-result:
FAIL: rt/tst-cputimer3
original exit status 1
I haven't looked any further into this, just reporting.. otherwise the
test systems seem to be healthy.
[PATCH][trivial] fix email address quoting in MODULE_AUTHOR()
Apparently it is quite easy to forget ">" in quoting of email
address. This fixes it.
Signed-off-by: Pavel Machek
diff --git a/arch/mips/crypto/crc32-mips.c b/arch/mips/crypto/crc32-mips.c
index 7d1d242..a10a8e6 100644
--- a/arch/mips/crypto/crc32-mips.c
+++ b/arch/mips/crypto/crc32-mips.c
@@ -340,7 +340,7 @@ static void __exit crc32_mod_exit(void)
crypto_unregister_shash(_alg);
}
-MODULE_AUTHOR("Marcin Nowakowski ");
MODULE_DESCRIPTION("CRC32 and CRC32C using optional MIPS instructions");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/bus/tegra-gmi.c b/drivers/bus/tegra-gmi.c
index a657078..ca14f3e 100644
--- a/drivers/bus/tegra-gmi.c
+++ b/drivers/bus/tegra-gmi.c
@@ -279,6 +279,6 @@ static struct platform_driver tegra_gmi_driver = {
};
module_platform_driver(tegra_gmi_driver);
-MODULE_AUTHOR("Mirza Krak ");
MODULE_DESCRIPTION("NVIDIA Tegra GMI Bus Driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 8bdf91b..242fc18 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1666,6 +1666,6 @@ static struct i2c_driver si5351_driver = {
};
module_i2c_driver(si5351_driver);
-MODULE_AUTHOR("Sebastian Hesselbarth ");
MODULE_DESCRIPTION("Silicon Labs Si5351A/B/C clock generator driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/clk/ux500/abx500-clk.c b/drivers/clk/ux500/abx500-clk.c
index 5a86cd8..3c8594d 100644
--- a/drivers/clk/ux500/abx500-clk.c
+++ b/drivers/clk/ux500/abx500-clk.c
@@ -122,6 +122,6 @@ static int __init abx500_clk_init(void)
}
arch_initcall(abx500_clk_init);
-MODULE_AUTHOR("Ulf Hansson ");
MODULE_DESCRIPTION("ABX500 clk driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
b/drivers/cpufreq/kirkwood-cpufreq.c
index c2dd43f..26da4fc 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -202,6 +202,6 @@ static struct platform_driver
kirkwood_cpufreq_platform_driver = {
module_platform_driver(kirkwood_cpufreq_platform_driver);
MODULE_LICENSE("GPL v2");
-MODULE_AUTHOR("Andrew Lunn ");
MODULE_DESCRIPTION("cpufreq driver for Marvell's kirkwood CPU");
MODULE_ALIAS("platform:kirkwood-cpufreq");
diff --git a/drivers/crypto/hisilicon/sec/sec_drv.c
b/drivers/crypto/hisilicon/sec/sec_drv.c
index c1ee4e7..2fc0ab6 100644
--- a/drivers/crypto/hisilicon/sec/sec_drv.c
+++ b/drivers/crypto/hisilicon/sec/sec_drv.c
@@ -1319,5 +1319,5 @@ module_platform_driver(sec_driver);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Hisilicon Security Accelerators");
-MODULE_AUTHOR("Zaibo Xu ");
MODULE_AUTHOR("Jonathan Cameron ");
diff --git a/drivers/firmware/efi/efibc.c b/drivers/firmware/efi/efibc.c
index 503bbe2..11aafd7 100644
--- a/drivers/firmware/efi/efibc.c
+++ b/drivers/firmware/efi/efibc.c
@@ -108,6 +108,6 @@ static void __exit efibc_exit(void)
module_exit(efibc_exit);
MODULE_AUTHOR("Jeremy Compostella ");
-MODULE_AUTHOR("Matt Gumbel ");
MODULE_DESCRIPTION("EFI Bootloader Control");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index c4e7953..7f8f738 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -519,7 +519,7 @@ static struct platform_driver dln2_gpio_driver = {
module_platform_driver(dln2_gpio_driver);
-MODULE_AUTHOR("Daniel Baluta ");
MODULE_DESCRIPTION("Driver for the Diolan DLN2 GPIO interface");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:dln2-gpio");
diff --git a/drivers/gpio/gpio-ge.c b/drivers/gpio/gpio-ge.c
index 6369527..726b448 100644
--- a/drivers/gpio/gpio-ge.c
+++ b/drivers/gpio/gpio-ge.c
@@ -105,5 +105,5 @@ static struct platform_driver gef_gpio_driver = {
module_platform_driver_probe(gef_gpio_driver, gef_gpio_probe);
MODULE_DESCRIPTION("GE I/O FPGA GPIO driver");
-MODULE_AUTHOR("Martyn Welch ");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpio/gpio-mpc5200.c b/drivers/gpio/gpio-mpc5200.c
index fc10cf5..debe6fa 100644
--- a/drivers/gpio/gpio-mpc5200.c
+++ b/drivers/gpio/gpio-mpc5200.c
@@ -373,6 +373,6 @@ static void __exit mpc52xx_gpio_exit(void)
module_exit(mpc52xx_gpio_exit);
MODULE_DESCRIPTION("Freescale MPC52xx gpio driver");
-MODULE_AUTHOR("Sascha Hauer ");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a7c39f3..313acab 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1964,6 +1964,6 @@ static struct i2c_driver tda998x_driver = {
module_i2c_driver(tda998x_driver);
-MODULE_AUTHOR("Rob Clark ");
MODULE_DESCRIPTION("NXP Semiconductors TDA998X HDMI Encoder");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index dcff812..d90bd38 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1372,6 +1372,6 @@ static void __exit msm_drm_unregister(void)
module_init(msm_drm_register);
module_exit(msm_drm_unregister);
Re: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver
Hi Pawel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.20-rc7 next-20181221]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Pawel-Laszczak/Introduced-new-Cadence-USBSS-DRD-Driver/20181223-231813
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> drivers/usb/common/debug.c:253:25: warning: restricted __le16 degrades to
>> integer
drivers/usb/common/debug.c:254:25: warning: restricted __le16 degrades to
integer
drivers/usb/common/debug.c:255:25: warning: restricted __le16 degrades to
integer
drivers/usb/common/debug.c:256:25: warning: restricted __le16 degrades to
integer
drivers/usb/common/debug.c:257:25: warning: restricted __le16 degrades to
integer
drivers/usb/common/debug.c:258:25: warning: restricted __le16 degrades to
integer
vim +253 drivers/usb/common/debug.c
cefb8b21 Pawel Laszczak 2018-12-23 205
cefb8b21 Pawel Laszczak 2018-12-23 206 /**
cefb8b21 Pawel Laszczak 2018-12-23 207 * usb_decode_ctrl - returns a string
representation of ctrl request
cefb8b21 Pawel Laszczak 2018-12-23 208 */
cefb8b21 Pawel Laszczak 2018-12-23 209 const char *usb_decode_ctrl(char *str,
__u8 bRequestType, __u8 bRequest,
cefb8b21 Pawel Laszczak 2018-12-23 210 __u16
wValue, __u16 wIndex, __u16 wLength)
cefb8b21 Pawel Laszczak 2018-12-23 211 {
cefb8b21 Pawel Laszczak 2018-12-23 212 switch (bRequest) {
cefb8b21 Pawel Laszczak 2018-12-23 213 case USB_REQ_GET_STATUS:
cefb8b21 Pawel Laszczak 2018-12-23 214
usb_decode_get_status(bRequestType, wIndex, wLength, str);
cefb8b21 Pawel Laszczak 2018-12-23 215 break;
cefb8b21 Pawel Laszczak 2018-12-23 216 case USB_REQ_CLEAR_FEATURE:
cefb8b21 Pawel Laszczak 2018-12-23 217 case USB_REQ_SET_FEATURE:
cefb8b21 Pawel Laszczak 2018-12-23 218
usb_decode_set_clear_feature(bRequestType, bRequest, wValue,
cefb8b21 Pawel Laszczak 2018-12-23 219
wIndex, str);
cefb8b21 Pawel Laszczak 2018-12-23 220 break;
cefb8b21 Pawel Laszczak 2018-12-23 221 case USB_REQ_SET_ADDRESS:
cefb8b21 Pawel Laszczak 2018-12-23 222
usb_decode_set_address(wValue, str);
cefb8b21 Pawel Laszczak 2018-12-23 223 break;
cefb8b21 Pawel Laszczak 2018-12-23 224 case USB_REQ_GET_DESCRIPTOR:
cefb8b21 Pawel Laszczak 2018-12-23 225 case USB_REQ_SET_DESCRIPTOR:
cefb8b21 Pawel Laszczak 2018-12-23 226
usb_decode_get_set_descriptor(bRequestType, bRequest, wValue,
cefb8b21 Pawel Laszczak 2018-12-23 227
wIndex, wLength, str);
cefb8b21 Pawel Laszczak 2018-12-23 228 break;
cefb8b21 Pawel Laszczak 2018-12-23 229 case USB_REQ_GET_CONFIGURATION:
cefb8b21 Pawel Laszczak 2018-12-23 230
usb_decode_get_configuration(wLength, str);
cefb8b21 Pawel Laszczak 2018-12-23 231 break;
cefb8b21 Pawel Laszczak 2018-12-23 232 case USB_REQ_SET_CONFIGURATION:
cefb8b21 Pawel Laszczak 2018-12-23 233
usb_decode_set_configuration(wValue, str);
cefb8b21 Pawel Laszczak 2018-12-23 234 break;
cefb8b21 Pawel Laszczak 2018-12-23 235 case USB_REQ_GET_INTERFACE:
cefb8b21 Pawel Laszczak 2018-12-23 236
usb_decode_get_intf(wIndex, wLength, str);
cefb8b21 Pawel Laszczak 2018-12-23 237 break;
cefb8b21 Pawel Laszczak 2018-12-23 238 case USB_REQ_SET_INTERFACE:
cefb8b21 Pawel Laszczak 2018-12-23 239
usb_decode_set_intf(wValue, wIndex, str);
cefb8b21 Pawel Laszczak 2018-12-23 240 break;
cefb8b21 Pawel Laszczak 2018-12-23 241 case USB_REQ_SYNCH_FRAME:
cefb8b21 Pawel Laszczak 2018-12-23 242
usb_decode_synch_frame(wIndex, wLength, str);
cefb8b21 Pawel Laszczak 2018-12-23 243 break;
cefb8b21 Pawel Laszczak 2018-12-23 244 case USB_REQ_SET_SEL:
cefb8b21 Pawel Laszczak 2018-12-23 245
usb_decode_set_sel(wLength, str);
cefb8b21 Pawel Laszczak 2018-12-23 246 break;
cefb8b21 Pawel Laszczak 2018-12-23 247 case USB_REQ_SET_ISOCH_DELAY:
cefb8b21 Pawel Laszczak 2018-12-23 248
usb_decode_set_isoch_delay(wValue, str);
cefb8b21 Pawel Laszczak 2018-12-23 249 break;
cefb8b21 Pawel Laszczak 2018-12-23 250 default:
cefb8b21 Pawel Laszczak 2018-12-23 251 sprin
