[PATCH] ALSA: firewire: fix a memory leak bug
In iso_packets_buffer_init(), 'b->packets' is allocated through
kmalloc_array(). Then, the aligned packet size is checked. If it is
larger than PAGE_SIZE, -EINVAL will be returned to indicate the error.
However, the allocated 'b->packets' is not deallocated on this path,
leading to a memory leak.
To fix the above issue, free 'b->packets' before returning the error code.
Signed-off-by: Wenwen Wang
---
sound/firewire/packets-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/firewire/packets-buffer.c b/sound/firewire/packets-buffer.c
index 0d35359..0ecafd0 100644
--- a/sound/firewire/packets-buffer.c
+++ b/sound/firewire/packets-buffer.c
@@ -37,7 +37,7 @@ int iso_packets_buffer_init(struct iso_packets_buffer *b,
struct fw_unit *unit,
packets_per_page = PAGE_SIZE / packet_size;
if (WARN_ON(!packets_per_page)) {
err = -EINVAL;
- goto error;
+ goto err_packets;
}
pages = DIV_ROUND_UP(count, packets_per_page);
--
2.7.4
Re: [PATCH] scripts/checkpatch.pl - fix *_NOTIFIER_HEAD handling
On Wed, 2019-08-07 at 21:36 -0400, Valdis Klētnieks wrote:
> commit 81398d99e9de80d9dbe65dfe7aadec9497f88242
> Author: Gilad Ben-Yossef
> Date: Wed Jul 31 14:44:23 2019 +1000
>
> checkpatch: add *_NOTIFIER_HEAD as var definition
>
> has a typo, resulting in a truly amazing error message:
Ouch, thanks.
> Unescaped left brace in regex is passed through in regex; marked by <-- HERE
> in m/(?:
[]
> Fix the typo.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3891,7 +3891,7 @@ sub process {
> ^.DEFINE_$Ident\(\Q$name\E\)|
> ^.DECLARE_$Ident\(\Q$name\E\)|
> ^.LIST_HEAD\(\Q$name\E\)|
> - ^.{$Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
> + ^.${Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
Perhaps also better to convert all the '\Q$name\E' to '\s*\Q$name\E\s*'
Re: [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
On 08/07/2019 06:03 AM, Miles Chen wrote:
> This change prints the hexadecimal EC value in mem_abort_decode(),
> which makes it easier to lookup the corresponding EC in
> the ARM Architecture Reference Manual.
>
> The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> faults") prints useful information when memory abort occurs. It would
> be easier to lookup "0x25" instead of "DABT" in the document. Then we
> can check the corresponding ISS.
>
> For example:
> Current infoDocument
> EC Exception class
> "CP15 MCR/MRC"0x3 "MCR or MRC access to CP15a..."
> "ASIMD" 0x7 "Access to SIMD or floating-point..."
> "DABT (current EL)" 0x25"Data Abort taken without..."
> ...
>
> Before:
> Unable to handle kernel paging request at virtual address c000
> Mem abort info:
> ESR = 0x9646
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0046
> CM = 0, WnR = 1
>
> After:
> Unable to handle kernel paging request at virtual address c000
> Mem abort info:
> ESR = 0x9646
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0046
> CM = 0, WnR = 1
>
> Change since v1:
> print "EC" instead of "Exception class"
> print EC in fixwidth
>
> Cc: Mark Rutland
> Cc: Anshuman Khandual
> Cc: James Morse
> Signed-off-by: Miles Chen
This version implements the suggestion, hence it should have
also contained acked-by tag from Mark from earlier version.
Reviewed-by: Anshuman Khandual
Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
On Wed, Aug 7, 2019 at 6:55 PM Alexandre Belloni wrote: > > Hi, > > On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote: > > Maybe whether XO or DCXO is used also matters if you want to do some fine > > tunning of DCXO (control register has pletny of options), but that's > > probably > > better done in u-boot. And there's still no need to read HOSC source from > > DT. > > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL > > is 1, > > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will > > be using this info to gate/disable the osciallator. > > > > It is actually useful to be able to tweak the crystal tuning at > runtime to be able to reduce clock drift and compare with a reliable > source (e.g. NTP). > I'm curious, what kind of options does this RTC have? It has options to set the current, trim cap value, band gap voltage, and also change the mode to just accept an external clock signal, instead of driving a crystal. The settings for the former parameters are not explained though. See page 364 of http://linux-sunxi.org/File:Allwinner_H6_V200_User_Manual_V1.1.pdf ChenYu
Re: [PATCH] team: Add vlan tx offload to hw_enc_features
On Wed, 7 Aug 2019 10:38:08 +0800
YueHaibing wrote:
> We should also enable bonding's vlan tx offload in hw_enc_features,
You mean team's vlan tx offload?
> pass the vlan packets to the slave devices with vlan tci, let them
s/let them to/let the slave/
> to handle vlan tunneling offload implementation.
>
> Fixes: 3268e5cb494d ("team: Advertise tunneling offload features")
> Signed-off-by: YueHaibing
[PATCH] net/netfilter/nf_nat_proto.c - make tables static
Sparse warns about two tables not being declared.
CHECK net/netfilter/nf_nat_proto.c
net/netfilter/nf_nat_proto.c:725:26: warning: symbol 'nf_nat_ipv4_ops' was not
declared. Should it be static?
net/netfilter/nf_nat_proto.c:964:26: warning: symbol 'nf_nat_ipv6_ops' was not
declared. Should it be static?
And in fact they can indeed be static.
Signed-off-by: Valdis Kletnieks
diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
index 7ac733ebd060..0a59c14b5177 100644
--- a/net/netfilter/nf_nat_proto.c
+++ b/net/netfilter/nf_nat_proto.c
@@ -722,7 +722,7 @@ nf_nat_ipv4_local_fn(void *priv, struct sk_buff *skb,
return ret;
}
-const struct nf_hook_ops nf_nat_ipv4_ops[] = {
+static const struct nf_hook_ops nf_nat_ipv4_ops[] = {
/* Before packet filtering, change destination */
{
.hook = nf_nat_ipv4_in,
@@ -961,7 +961,7 @@ nf_nat_ipv6_local_fn(void *priv, struct sk_buff *skb,
return ret;
}
-const struct nf_hook_ops nf_nat_ipv6_ops[] = {
+static const struct nf_hook_ops nf_nat_ipv6_ops[] = {
/* Before packet filtering, change destination */
{
.hook = nf_nat_ipv6_in,
Re: [PATCH] myri10ge: remove unneeded variable
On Wed, 31 Jul 2019 16:53:46 +0800 Ding Xiang wrote: > "error" is unneeded,just return 0 > > Signed-off-by: Ding Xiang Reviewed-by: Jesse Brandeburg
Re: [PATCH 2/2] net: ag71xx: Use GFP_KERNEL instead of GFP_ATOMIC in 'ag71xx_rings_init()'
On Wed, 31 Jul 2019 10:06:48 +0200 Christophe JAILLET wrote: > There is no need to use GFP_ATOMIC here, GFP_KERNEL should be enough. > The 'kcalloc()' just a few lines above, already uses GFP_KERNEL. > > Signed-off-by: Christophe JAILLET Reviewed-by: Jesse Brandeburg
Re: [PATCH 1/2] net: ag71xx: Slighly simplify code in 'ag71xx_rings_init()'
On Wed, 31 Jul 2019 10:06:38 +0200 Christophe JAILLET wrote: > A few lines above, we have: >tx_size = BIT(tx->order); > > So use 'tx_size' directly to be consistent with the way 'rx->descs_cpu' and > 'rx->descs_dma' are computed below. > > Signed-off-by: Christophe JAILLET Reviewed-by: Jesse Brandeburg
[PATCH] net/netfilter - add missing prototypes.
Sparse rightly complains about undeclared symbols.
CHECK net/netfilter/nft_set_hash.c
net/netfilter/nft_set_hash.c:647:21: warning: symbol 'nft_set_rhash_type' was
not declared. Should it be static?
net/netfilter/nft_set_hash.c:670:21: warning: symbol 'nft_set_hash_type' was
not declared. Should it be static?
net/netfilter/nft_set_hash.c:690:21: warning: symbol 'nft_set_hash_fast_type'
was not declared. Should it be static?
CHECK net/netfilter/nft_set_bitmap.c
net/netfilter/nft_set_bitmap.c:296:21: warning: symbol 'nft_set_bitmap_type'
was not declared. Should it be static?
CHECK net/netfilter/nft_set_rbtree.c
net/netfilter/nft_set_rbtree.c:470:21: warning: symbol 'nft_set_rbtree_type'
was not declared. Should it be static?
Include nf_tables_core.h rather than nf_tables.h to pick up the additional
definitions.
Signed-off-by: Valdis Kletnieks
diff --git a/net/netfilter/nft_set_bitmap.c b/net/netfilter/nft_set_bitmap.c
index b5aeccdddb22..087a056e34d1 100644
--- a/net/netfilter/nft_set_bitmap.c
+++ b/net/netfilter/nft_set_bitmap.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
struct nft_bitmap_elem {
struct list_headhead;
diff --git a/net/netfilter/nft_set_hash.c b/net/netfilter/nft_set_hash.c
index 6e8d20c03e3d..c490451fcebf 100644
--- a/net/netfilter/nft_set_hash.c
+++ b/net/netfilter/nft_set_hash.c
@@ -16,7 +16,7 @@
#include
#include
#include
-#include
+#include
/* We target a hash table size of 4, element hint is 75% of final size */
#define NFT_RHASH_ELEMENT_HINT 3
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 419d58ef802b..57123259452f 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -13,7 +13,7 @@
#include
#include
#include
-#include
+#include
struct nft_rbtree {
struct rb_root root;
Re: [PATCH] net: ethernet: et131x: Use GFP_KERNEL instead of GFP_ATOMIC when allocating tx_ring->tcb_ring
On Wed, 31 Jul 2019 09:38:42 +0200 Christophe JAILLET wrote: > There is no good reason to use GFP_ATOMIC here. Other memory allocations > are performed with GFP_KERNEL (see other 'dma_alloc_coherent()' below and > 'kzalloc()' in 'et131x_rx_dma_memory_alloc()') > > Use GFP_KERNEL which should be enough. > > Signed-off-by: Christophe JAILLET Sure, but generally I'd say GFP_ATOMIC is ok if you're in an init path and you can afford to have the allocation thread sleep while memory is being found by the kernel. Reviewed-by: Jesse Brandeburg
Re: [PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
On 08/07/2019 10:28 AM, Jia He wrote:
> Without this patch, the MAP_SYNC test case will cause a print_bad_pte
> warning on arm64 as follows:
> [ 25.542693] BUG: Bad page map in process mapdax333
> pte:2e8000448800f53 pmd:41ff5f003
> [ 25.546360] page:7e001022 refcount:1 mapcount:-1
> mapping:8003e29c7440 index:0x0
> [ 25.550281] ext4_dax_aops
> [ 25.550282] name:"__aaabbbcccddd__"
> [ 25.551553] flags: 0x3001002(referenced|reserved)
> [ 25.555802] raw: 03001002 8003dfffa908
> 8003e29c7440
> [ 25.559446] raw: 0001fffe
>
> [ 25.563075] page dumped because: bad pte
> [ 25.564938] addr:be05b000 vm_flags:208000fb
> anon_vma: mapping:8003e29c7440 index:0
> [ 25.574272] file:__aaabbbcccddd__ fault:ext4_dax_fault
> ap:ext4_file_mmap readpage:0x0
> [ 25.578799] CPU: 1 PID: 1180 Comm: mapdax333 Not tainted 5.2.0+ #21
> [ 25.581702] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
> 02/06/2015
> [ 25.585624] Call trace:
> [ 25.587008] dump_backtrace+0x0/0x178
> [ 25.588799] show_stack+0x24/0x30
> [ 25.590328] dump_stack+0xa8/0xcc
> [ 25.591901] print_bad_pte+0x18c/0x218
> [ 25.593628] unmap_page_range+0x778/0xc00
> [ 25.595506] unmap_single_vma+0x94/0xe8
> [ 25.597304] unmap_vmas+0x90/0x108
> [ 25.598901] unmap_region+0xc0/0x128
> [ 25.600566] __do_munmap+0x284/0x3f0
> [ 25.602245] __vm_munmap+0x78/0xe0
> [ 25.603820] __arm64_sys_munmap+0x34/0x48
> [ 25.605709] el0_svc_common.constprop.0+0x78/0x168
> [ 25.607956] el0_svc_handler+0x34/0x90
> [ 25.609698] el0_svc+0x8/0xc
> [ 25.611103] Disabling lock debugging due to kernel taint
> [ 25.613573] BUG: Bad page state in process mapdax333 pfn:448800
> [ 25.616359] page:7e001022 refcount:0 mapcount:-1
> mapping:8003e29c7440 index:0x1
> [ 25.620236] ext4_dax_aops
> [ 25.620237] name:"__aaabbbcccddd__"
> [ 25.621495] flags: 0x300()
> [ 25.624912] raw: 0300 dead0100 dead0200
> 8003e29c7440
> [ 25.628502] raw: 0001 fffe
>
> [ 25.632097] page dumped because: non-NULL mapping
> [...]
> [ 25.656567] CPU: 1 PID: 1180 Comm: mapdax333 Tainted: GB
> 5.2.0+ #21
> [ 25.660131] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
> 02/06/2015
> [ 25.663324] Call trace:
> [ 25.664466] dump_backtrace+0x0/0x178
> [ 25.666163] show_stack+0x24/0x30
> [ 25.667721] dump_stack+0xa8/0xcc
> [ 25.669270] bad_page+0xf0/0x150
> [ 25.670772] free_pages_check_bad+0x84/0xa0
> [ 25.672724] free_pcppages_bulk+0x45c/0x708
> [ 25.674675] free_unref_page_commit+0xcc/0x100
> [ 25.676751] free_unref_page_list+0x13c/0x200
> [ 25.678801] release_pages+0x350/0x420
> [ 25.680539] free_pages_and_swap_cache+0xf8/0x128
> [ 25.682738] tlb_flush_mmu+0x164/0x2b0
> [ 25.684485] unmap_page_range+0x648/0xc00
> [ 25.686349] unmap_single_vma+0x94/0xe8
> [ 25.688131] unmap_vmas+0x90/0x108
> [ 25.689739] unmap_region+0xc0/0x128
> [ 25.691392] __do_munmap+0x284/0x3f0
> [ 25.693079] __vm_munmap+0x78/0xe0
> [ 25.694658] __arm64_sys_munmap+0x34/0x48
> [ 25.696530] el0_svc_common.constprop.0+0x78/0x168
> [ 25.698772] el0_svc_handler+0x34/0x90
> [ 25.700512] el0_svc+0x8/0xc
>
> The root cause is in _vm_normal_page, without the PTE_SPECIAL bit,
> the return value will be incorrectly set to pfn_to_page(pfn) instead
> of NULL. Besides, this patch also rewrite the pmd_mkdevmap to avoid
> setting PTE_SPECIAL for pmd
>
> The MAP_SYNC test case is as follows(Provided by Yibo Cai)
> $#include
> $#include
> $#include
> $#include
> $#include
>
> $#ifndef MAP_SYNC
> $#define MAP_SYNC 0x8
> $#endif
>
> /* mount -o dax /dev/pmem0 /mnt */
> $#define F "/mnt/__aaabbbcccddd__"
>
> int main(void)
> {
> int fd;
> char buf[4096];
> void *addr;
>
> if ((fd = open(F, O_CREAT|O_TRUNC|O_RDWR, 0644)) < 0) {
> perror("open1");
> return 1;
> }
>
> if (write(fd, buf, 4096) != 4096) {
> perror("lseek");
> return 1;
> }
>
> addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_SYNC,
> fd, 0);
> if (addr == MAP_FAILED) {
> perror("mmap");
> printf("did you mount with '-o dax'?\n");
> return 1;
> }
>
> memset(addr, 0x55, 4096);
>
> if (munmap(addr, 4096) == -1) {
> perror("munmap");
> return 1;
> }
>
> close(fd);
>
> return 0;
> }
>
> Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
> Reported-by: Yibo Cai
> Signed-off-by: Jia He
> Acked-by: Robin Murphy
> ---
> arch/arm64/include/asm/pgtable.h | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index
Re: [PATCH 4/5] clk: Add driver for Bitmain BM1880 SoC clock controller
Quoting Manivannan Sadhasivam (2019-07-05 08:14:39)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index fc1e0cf44995..ffc61ed85ade 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -304,6 +304,12 @@ config COMMON_CLK_FIXED_MMIO
> help
> Support for Memory Mapped IO Fixed clocks
>
> +config COMMON_CLK_BM1880
> + bool "Clock driver for Bitmain BM1880 SoC"
> + depends on ARCH_BITMAIN || COMPILE_TEST
> + help
> + This driver supports the clocks on Bitmain BM1880 SoC.
Can you add this config somewhere else besides the end? Preferably
close to alphabetically in this file.
> +
> source "drivers/clk/actions/Kconfig"
> source "drivers/clk/analogbits/Kconfig"
> source "drivers/clk/bcm/Kconfig"
> diff --git a/drivers/clk/clk-bm1880.c b/drivers/clk/clk-bm1880.c
> new file mode 100644
> index ..26cdb75bb936
> --- /dev/null
> +++ b/drivers/clk/clk-bm1880.c
> @@ -0,0 +1,947 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bitmain BM1880 SoC clock driver
> + *
> + * Copyright (c) 2019 Linaro Ltd.
> + * Author: Manivannan Sadhasivam
> + */
> +
> +#include
> +#include
> +#include
Should probably add kernel.h for at least container_of()
> +
> +#include
> +
> +#define BM1880_CLK_MPLL_CTL0x00
> +#define BM1880_CLK_SPLL_CTL0x04
> +#define BM1880_CLK_FPLL_CTL0x08
> +#define BM1880_CLK_DDRPLL_CTL 0x0c
> +
> +#define BM1880_CLK_ENABLE0 0x00
> +#define BM1880_CLK_ENABLE1 0x04
> +#define BM1880_CLK_SELECT 0x20
> +#define BM1880_CLK_DIV00x40
> +#define BM1880_CLK_DIV10x44
> +#define BM1880_CLK_DIV20x48
> +#define BM1880_CLK_DIV30x4c
> +#define BM1880_CLK_DIV40x50
> +#define BM1880_CLK_DIV50x54
> +#define BM1880_CLK_DIV60x58
> +#define BM1880_CLK_DIV70x5c
> +#define BM1880_CLK_DIV80x60
> +#define BM1880_CLK_DIV90x64
> +#define BM1880_CLK_DIV10 0x68
> +#define BM1880_CLK_DIV11 0x6c
> +#define BM1880_CLK_DIV12 0x70
> +#define BM1880_CLK_DIV13 0x74
> +#define BM1880_CLK_DIV14 0x78
> +#define BM1880_CLK_DIV15 0x7c
> +#define BM1880_CLK_DIV16 0x80
> +#define BM1880_CLK_DIV17 0x84
> +#define BM1880_CLK_DIV18 0x88
> +#define BM1880_CLK_DIV19 0x8c
> +#define BM1880_CLK_DIV20 0x90
> +#define BM1880_CLK_DIV21 0x94
> +#define BM1880_CLK_DIV22 0x98
> +#define BM1880_CLK_DIV23 0x9c
> +#define BM1880_CLK_DIV24 0xa0
> +#define BM1880_CLK_DIV25 0xa4
> +#define BM1880_CLK_DIV26 0xa8
> +#define BM1880_CLK_DIV27 0xac
> +#define BM1880_CLK_DIV28 0xb0
> +
> +#define to_bm1880_pll_clk(_hw) container_of(_hw, struct bm1880_pll_hw_clock,
> hw)
> +#define to_bm1880_div_clk(_hw) container_of(_hw, struct bm1880_div_hw_clock,
> hw)
> +
> +static DEFINE_SPINLOCK(bm1880_clk_lock);
> +
> +struct bm1880_clock_data {
> + void __iomem *pll_base;
> + void __iomem *sys_base;
> + struct clk_onecell_data clk_data;
> +};
> +
> +struct bm1880_gate_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 gate_reg;
> + s8 gate_shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_mux_clock {
> + unsigned intid;
> + const char *name;
> + const char * const * parents;
> + s8 num_parents;
> + u32 reg;
> + s8 shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 reg;
> + u8 shift;
> + u8 width;
> + u32 initval;
> + struct clk_div_table *table;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_hw_clock {
> + struct bm1880_div_clock div;
> + void __iomem *base;
> + spinlock_t *lock;
> + struct clk_hw hw;
> +};
> +
> +struct bm1880_composite_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + const char * const * parents;
> + unsigned intnum_parents;
> + unsigned long flags;
> +
> + u32 gate_reg;
> + u32 mux_reg;
> + u32 div_reg;
> +
> + s8 gate_shift;
> + s8 mux_shift;
> + s8 div_shift;
> + s8 div_width;
> + s16 div_initval;
> + struct clk_div_table *table;
> +};
> +
> +struct bm1880_pll_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 reg;
> + unsigned long flags;
> +};
> +
> +struct
[PATCH] sound: fix a memory leak bug
In sound_insert_unit(), the controlling structure 's' is allocated through kmalloc(). Then it is added to the sound driver list by invoking __sound_insert_unit(). Later on, if __register_chrdev() fails, 's' is removed from the list through __sound_remove_unit(). If 'index' is not less than 0, -EBUSY is returned to indicate the error. However, 's' is not deallocated on this execution path, leading to a memory leak bug. To fix the above issue, free 's' before -EBUSY is returned. Signed-off-by: Wenwen Wang --- sound/sound_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/sound_core.c b/sound/sound_core.c index b730d97..90d118c 100644 --- a/sound/sound_core.c +++ b/sound/sound_core.c @@ -275,7 +275,8 @@ static int sound_insert_unit(struct sound_unit **list, const struct file_operati goto retry; } spin_unlock(_loader_lock); - return -EBUSY; + r = -EBUSY; + goto fail; } } -- 2.7.4
Re: [PATCH v1 2/2] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
On 07-08-19, 23:43, Taniya Das wrote:
> +static struct clk_alpha_pll gpll0;
> +static struct clk_alpha_pll gpll1;
> +static struct clk_alpha_pll gpll4;
> +static struct clk_alpha_pll gpll6;
> +static struct clk_alpha_pll gpll7;
> +static struct clk_alpha_pll_postdiv gpll0_out_even;
I am not sure we need these, reordering code and getting rid of them
should be easy enough (i did that for sm8150)
> +static const struct parent_map gcc_parent_map_0[] = {
> + { P_BI_TCXO, 0 },
> + { P_GPLL0_OUT_MAIN, 1 },
> + { P_GPLL0_OUT_EVEN, 6 },
> + { P_CORE_BI_PLL_TEST_SE, 7 },
> +};
> +
> +static const struct clk_parent_data gcc_parent_data_0[] = {
> + { .fw_name = "bi_tcxo", .name = "bi_tcxo" },
> + { .hw = },
> + { .hw = _out_even.clkr.hw },
> + { .fw_name = "core_bi_pll_test_se", .name = "core_bi_pll_test_se" },
This is legacy test, so we would want only fw_name being there
> +static struct clk_branch gcc_camera_ahb_clk = {
> + .halt_reg = 0xb008,
> + .halt_check = BRANCH_HALT,
> + .hwcg_reg = 0xb008,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0xb008,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_camera_ahb_clk",
> + .flags = CLK_IS_CRITICAL,
It would help to explain why this clk is critical
> +static struct clk_branch gcc_disp_gpll0_div_clk_src = {
> + .halt_check = BRANCH_HALT_DELAY,
And why this needs a delay
--
~Vinod
Re: linux-next: Tree for Aug 7
Stephen Rothwell writes: > Hi all, > > Changes since 20190806: > > The arm64 tree introduced a patch that stopped the powerpc ppc64_defconfig > build from completing so I reverted that commit. > > The mips tree gained a conflict against Linus' tree. > > The crypto tree still had its build failure for which I applied a patch. > > The drm-misc tree gained a conflict and a sematic conflct against the > amdgpu tree. > > The integrity tree lost its build failure. > > The akpm-current tree gained a conflict against the arm64 tree and a > build failure for which I reverted a commit. > > The akpm tree lost a patch that turned up elsewhere. > > Non-merge commits (relative to Linus' tree): 4586 > 4952 files changed, 265168 insertions(+), 120665 deletions(-) This is still popping a few implicit fallthrough warnings, from various configs: arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/include/asm/sysreg.h:808:2: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:20:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:21:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:22:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:23:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:24:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:25:19: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:26:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:27:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:28:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:29:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:30:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:31:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:32:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:33:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/debug-sr.c:34:18: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:351:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:353:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:361:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:363:24: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:384:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:386:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:394:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm64/kvm/hyp/../../../../virt/kvm/arm/hyp/vgic-v3-sr.c:396:3: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/mips/include/asm/octeon/cvmx-sli-defs.h:47:6: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/nds32/kernel/signal.c:315:7: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/nds32/kernel/signal.c:362:20: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:3: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function 'readq'; did you mean 'readl'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function 'writeq'; did you mean 'writel'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function 'writeq' [-Werror=implicit-function-declaration] drivers/gpu/drm/sun4i/sun4i_tcon.c:318:7: warning: this statement
Re: linux-next: build failure after merge of the crypto tree
Hi Herbert, On Thu, 8 Aug 2019 15:00:04 +1000 Herbert Xu wrote: > > On Thu, Aug 08, 2019 at 01:17:10PM +1000, Stephen Rothwell wrote: > > > > Excellent, thanks. Should I add the crypto mailing list as a contact > > for problems? Mostly the emails are just reporting conflicts and only > > very occasionally do I actually send a useful patch. If so, what is > > its address? > > Yes please. The address is > > linux-cry...@vger.kernel.org Done. -- Cheers, Stephen Rothwell pgpFj8AdDHrpN.pgp Description: OpenPGP digital signature
Re: [PATCH v1 1/2] clk: qcom: Add DT bindings for SC7180 gcc clock controller
On 07-08-19, 23:43, Taniya Das wrote: > Add compatible string and the include file for gcc clock > controller for SC7180. > > Signed-off-by: Taniya Das > --- > .../devicetree/bindings/clock/qcom,gcc.txt| 1 + > include/dt-bindings/clock/qcom,gcc-sc7180.h | 155 ++ > 2 files changed, 156 insertions(+) > create mode 100644 include/dt-bindings/clock/qcom,gcc-sc7180.h > > diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt > b/Documentation/devicetree/bindings/clock/qcom,gcc.txt > index 8661c3cd3ccf..18d95467cb36 100644 > --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt > +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt > @@ -23,6 +23,7 @@ Required properties : > "qcom,gcc-sdm630" > "qcom,gcc-sdm660" > "qcom,gcc-sdm845" > + "qcom,gcc-sc7180" I don't see parent clocks listed here please add them as well -- ~Vinod
Re: [PATCH 1/5] dt-bindings: clock: Add Bitmain BM1880 SoC clock controller binding
Quoting Manivannan Sadhasivam (2019-07-05 08:14:36)
> Add devicetree binding for Bitmain BM1880 SoC clock controller.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../bindings/clock/bitmain,bm1880-clk.txt | 47 +++
Can you convert this to YAML? It's all the rage right now.
> include/dt-bindings/clock/bm1880-clock.h | 82 +++
> 2 files changed, 129 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> create mode 100644 include/dt-bindings/clock/bm1880-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> new file mode 100644
> index ..9c967095d430
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> @@ -0,0 +1,47 @@
> +* Bitmain BM1880 Clock Controller
> +
> +The Bitmain BM1880 clock controler generates and supplies clock to
> +various peripherals within the SoC.
> +
> +Required Properties:
> +
> +- compatible: Should be "bitmain,bm1880-clk"
> +- reg :Register address and size of PLL and SYS control domains
> +- reg-names : Register domain names: "pll" and "sys"
> +- clocks : Phandle of the input reference clock.
> +- #clock-cells: Should be 1.
> +
> +Each clock is assigned an identifier, and client nodes can use this
> identifier
> +to specify the clock which they consume.
> +
> +All available clocks are defined as preprocessor macros in corresponding
> +dt-bindings/clock/bm1880-clock.h header and can be used in device tree
> sources.
> +
> +External clocks:
> +
> +The osc clock used as the input for the plls is generated outside the SoC.
> +It is expected that it is defined using standard clock bindings as "osc".
> +
> +Example:
> +
> +clk: clock-controller@800 {
> +compatible = "bitmain,bm1880-clk";
> +reg = <0xe8 0x0c>,<0x800 0xb0>;
It looks weird still. What hardware module is this actually part of?
Some larger power manager block?
> +reg-names = "pll", "sys";
> +clocks = <>;
> +#clock-cells = <1>;
> +};
> +
Re: linux-next: build failure after merge of the crypto tree
On Thu, Aug 08, 2019 at 01:17:10PM +1000, Stephen Rothwell wrote: > > Excellent, thanks. Should I add the crypto mailing list as a contact > for problems? Mostly the emails are just reporting conflicts and only > very occasionally do I actually send a useful patch. If so, what is > its address? Yes please. The address is linux-cry...@vger.kernel.org Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] liquidio: Use pcie_flr() instead of reimplementing it
octeon_mbox_process_cmd() directly writes the PCI_EXP_DEVCTL_BCR_FLR bit, which bypasses timing requirements imposed by the PCIe spec. This patch fixes the function to use the pcie_flr() interface instead. Signed-off-by: Denis Efremov --- drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c index 021d99cd1665..614d07be7181 100644 --- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c +++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c @@ -260,9 +260,7 @@ static int octeon_mbox_process_cmd(struct octeon_mbox *mbox, dev_info(>pci_dev->dev, "got a request for FLR from VF that owns DPI ring %u\n", mbox->q_no); - pcie_capability_set_word( - oct->sriov_info.dpiring_to_vfpcidev_lut[mbox->q_no], - PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR); + pcie_flr(oct->sriov_info.dpiring_to_vfpcidev_lut[mbox->q_no]); break; case OCTEON_PF_CHANGED_VF_MACADDR: -- 2.21.0
Re: [PATCH v2] clk: Constify struct clk_bulk_data * where possible
Quoting Andrey Smirnov (2019-07-17 07:56:51) > The following functions: > > - clk_bulk_enable() > - clk_bulk_prepare() > - clk_bulk_disable() > - clk_bulk_unprepare() > > already expect const clk_bulk_data * as a second parameter, however > their no-op version have mismatching prototypes that don't. Fix that. > > While at it, constify the second argument of clk_bulk_prepare_enable() > and clk_bulk_disable_unprepare(), since the functions they are > comprised of already accept const clk_bulk_data *. > > Signed-off-by: Andrey Smirnov > Cc: Russell King > Cc: Stephen Boyd > Cc: Chris Healy > Cc: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- Applied to clk-next
Re: [PATCH v2 0/7] Add support for Qualcomm SM8150 and SC7180 SoCs
On 07-08-19, 12:39, Sibi Sankar wrote: > This patch series adds SCM, APSS shared mailbox and QMP AOSS PD/clock > support on SM8150 and SC7180 SoCs. > > v2: > * re-arrange the compatible lists in sort order i checked these lgtm and tested on SM8150 Tested-by: Vinod Koul Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address offset
On 8/7/19 10:36 AM, Vijay Khemka wrote:
> Lgtm except one small comment below.
>
> On 8/6/19, 5:22 PM, "openbmc on behalf of Tao Ren"
> tao...@fb.com> wrote:
>
> Currently BMC's MAC address is calculated by adding 1 to NCSI NIC's base
> MAC address when CONFIG_NCSI_OEM_CMD_GET_MAC option is enabled. The logic
> doesn't work for platforms with different BMC MAC offset: for example,
> Facebook Yamp BMC's MAC address is calculated by adding 2 to NIC's base
> MAC address ("BaseMAC + 1" is reserved for Host use).
>
> This patch adds NET_NCSI_MC_MAC_OFFSET config option to customize offset
> between NIC's Base MAC address and BMC's MAC address. Its default value is
> set to 1 to avoid breaking existing users.
>
> Signed-off-by: Tao Ren
> ---
> net/ncsi/Kconfig| 8
> net/ncsi/ncsi-rsp.c | 15 +--
> 2 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/net/ncsi/Kconfig b/net/ncsi/Kconfig
> index 2f1e5756c03a..be8efe1ed99e 100644
> --- a/net/ncsi/Kconfig
> +++ b/net/ncsi/Kconfig
> @@ -17,3 +17,11 @@ config NCSI_OEM_CMD_GET_MAC
> ---help---
> This allows to get MAC address from NCSI firmware and set them back to
> controller.
> +config NET_NCSI_MC_MAC_OFFSET
> + int
> + prompt "Offset of Management Controller's MAC Address"
> + depends on NCSI_OEM_CMD_GET_MAC
> + default 1
> + help
> + This defines the offset between Network Controller's (base) MAC
> + address and Management Controller's MAC address.
> diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
> index 7581bf919885..24a791f9ebf5 100644
> --- a/net/ncsi/ncsi-rsp.c
> +++ b/net/ncsi/ncsi-rsp.c
> @@ -656,6 +656,11 @@ static int ncsi_rsp_handler_oem_bcm_gma(struct
> ncsi_request *nr)
> struct ncsi_rsp_oem_pkt *rsp;
> struct sockaddr saddr;
> int ret = 0;
> +#ifdef CONFIG_NET_NCSI_MC_MAC_OFFSET
> + int mac_offset = CONFIG_NET_NCSI_MC_MAC_OFFSET;
> +#else
> + int mac_offset = 1;
> +#endif
>
> /* Get the response header */
> rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
> @@ -663,8 +668,14 @@ static int ncsi_rsp_handler_oem_bcm_gma(struct
> ncsi_request *nr)
> saddr.sa_family = ndev->type;
> ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
> memcpy(saddr.sa_data, >data[BCM_MAC_ADDR_OFFSET], ETH_ALEN);
> - /* Increase mac address by 1 for BMC's address */
> - eth_addr_inc((u8 *)saddr.sa_data);
> +
> + /* Management Controller's MAC address is calculated by adding
> + * the offset to Network Controller's (base) MAC address.
> + * Note: negative offset is "ignored", and BMC will use the Base
> Just mention negative and zero offset is ignored. As you are ignoring 0 as
> well.
Thank you Vijay for the review.
Zero offset is not ignored: users get what they want when setting offset to 0
(BMC-MAC = Base-MAC).
Thanks,
Tao
Re: [PATCH] arm64/cache: silence -Woverride-init warnings
On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> VIVT I-caches") introduced some compiation warnings from GCC (and
> Clang) with -Winitializer-overrides),
>
> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VIPT] = "VIPT",
> ^~
> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> 'icache_policy_str[2]')
> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_PIPT] = "PIPT",
> ^~
> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> 'icache_policy_str[3]')
> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VPIPT] = "VPIPT",
> ^~~
> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> 'icache_policy_str[0]')
>
> because it initializes icache_policy_str[0 ... 3] twice. Since
> arm64 developers are keen to keep the style of initializing a static
> array with a non-zero pattern first, just disable those warnings for
> both GCC and Clang of this file.
>
> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT
> I-caches")
> Signed-off-by: Qian Cai
It's a shame we can't just use one cc-disable-warning statement but
-Woverride-init wasn't added for GCC compatibility until clang 8.0.0
and we don't have an established minimum clang version.
With that said, I applied your patch and I don't see with warning with
W=1 anymore and I see both options get added to the clang command line
with V=1.
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
Cheers!
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
kernel/locking/mutex-debug.c: In function 'debug_mutex_lock_common':
kernel/locking/mutex-debug.c:32:42: error: dereferencing pointer to incomplete
type 'struct mutex_waiter'
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
^~~
Caused by commit
5f35d5a66b3e ("locking/mutex: Make __mutex_owner static to mutex.c")
I have reverted that commit for today.
BTW, there is another reference to mutex_waiter in sched.h!
--
Cheers,
Stephen Rothwell
pgpLjQCuDkmBv.pgp
Description: OpenPGP digital signature
Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address offset
On 8/7/19 11:41 AM, Andrew Lunn wrote:
> On Wed, Aug 07, 2019 at 11:25:18AM -0700, Jakub Kicinski wrote:
>> On Tue, 6 Aug 2019 17:21:18 -0700, Tao Ren wrote:
>>> Currently BMC's MAC address is calculated by adding 1 to NCSI NIC's base
>>> MAC address when CONFIG_NCSI_OEM_CMD_GET_MAC option is enabled. The logic
>>> doesn't work for platforms with different BMC MAC offset: for example,
>>> Facebook Yamp BMC's MAC address is calculated by adding 2 to NIC's base
>>> MAC address ("BaseMAC + 1" is reserved for Host use).
>>>
>>> This patch adds NET_NCSI_MC_MAC_OFFSET config option to customize offset
>>> between NIC's Base MAC address and BMC's MAC address. Its default value is
>>> set to 1 to avoid breaking existing users.
>>>
>>> Signed-off-by: Tao Ren
>>
>> Maybe someone more knowledgeable like Andrew has an opinion here,
>> but to me it seems a bit strange to encode what seems to be platfrom
>> information in the kernel config :(
>
> Yes, this is not a good idea. It makes it impossible to have a 'BMC
> distro' kernel which you install on a number of different BMCs.
>
> A device tree property would be better. Ideally it would be the
> standard local-mac-address, or mac-address.
Thank you Andrew and Jakub for the feedback. I picked up kconfig approach
mainly because it's an OEM-only extention which is used only when
NCSI_OEM_CMD_GET_MAC is enabled.
Let me prepare patch v2 using device tree. I'm not sure if standard
"mac-address" fits this situation because all we need is an offset (integer)
and BMC MAC is calculated by adding the offset to NIC's MAC address. Anyways,
let me work out v2 patch we can discuss more then.
Thanks,
Tao
Re: [PATCH v2 1/4] clk: core: introduce clk_hw_set_parent()
Quoting Jerome Brunet (2019-08-06 01:28:19)
> On Wed 31 Jul 2019 at 10:40, Neil Armstrong wrote:
>
> > Introduce the clk_hw_set_parent() provider call to change parent of
> > a clock by using the clk_hw pointers.
> >
> > This eases the clock reparenting from clock rate notifiers and
> > implementing DVFS with simpler code avoiding the boilerplates
> > functions as __clk_lookup(clk_hw_get_name()) then clk_set_parent().
> >
> > Signed-off-by: Neil Armstrong
> > Acked-by: Martin Blumenstingl
>
> Looks ok to me but we will obviously need Stephen's ack to apply it
Acked-by: Stephen Boyd
>
> > ---
> > drivers/clk/clk.c| 6 ++
> > include/linux/clk-provider.h | 1 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index c0990703ce54..c11b1781d24a 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2487,6 +2487,12 @@ static int clk_core_set_parent_nolock(struct
> > clk_core *core,
> > return ret;
> > }
> >
> > +int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *parent)
> > +{
> > + return clk_core_set_parent_nolock(hw->core, parent->core);
I wonder if you really want to call all those things in
clk_core_set_parent_nolock(). For example, do you want notifiers to run
again and for rates to be speculated? Maybe all you want to do is
overwrite some value for the clk's parent by calling into the ops for
the clk and generically parse the value that's passed as the "parent"
here.
I ask because it may be good to avoid doing all that work and updating
bookkeeping when we're deep in a notifier. If we can clearly understand
what the driver wants to do from the notifier then it's simpler to
change in the future to use things such as the coordinated clk rate
vaporware.
Re: [RFC/RFT v3 07/14] clk: meson: g12a: add notifiers to handle cpu clock change
Quoting Martin Blumenstingl (2019-07-02 16:28:55) > Hi Stephen, Hi Neil, > > On Mon, Jul 1, 2019 at 11:13 AM Neil Armstrong > wrote: > > > > In order to implement clock switching for the CLKID_CPU_CLK and > > CLKID_CPUB_CLK, notifiers are added on specific points of the > > clock tree : > > > > cpu_clk / cpub_clk > > | \- cpu_clk_dyn > > | | \- cpu_clk_premux0 > > | ||- cpu_clk_postmux0 > > | |||- cpu_clk_dyn0_div > > | ||\- xtal/fclk_div2/fclk_div3 > > | |\- xtal/fclk_div2/fclk_div3 > > | \- cpu_clk_premux1 > > ||- cpu_clk_postmux1 > > |||- cpu_clk_dyn1_div > > ||\- xtal/fclk_div2/fclk_div3 > > |\- xtal/fclk_div2/fclk_div3 > > \ sys_pll / sys1_pll > > > > This for each cluster, a single one for G12A, two for G12B. > > > > Each cpu_clk_premux1 tree is marked as read-only and > > CLK_SET_RATE_NO_REPARENT, > > to be used as "parking" clock in a safe clock frequency. > it seems that this is one case where the "coordinated clocks" feature > would come handy: [0] > Stephen, do you know if those patches stopped in March or if there's > still some ongoing effort to get them ready? > Derek told me yesterday he wants to work on it again, but I don't know his timeline. If Derek doesn't reply here then maybe it can be picked up by someone else.
Re: [PATCH v4 2/5] clk: qcom: clk-alpha-pll: Remove post_div_table checks
Quoting Vinod Koul (2019-07-22 00:43:45) > We want users to code properly and fix the post_div_table missing and > not rely on core to check. So remove the post_div_table check. > > Signed-off-by: Vinod Koul > Reviewed-by: Bjorn Andersson > --- Applied to clk-next
Re: [PATCH v4 4/5] dt-bindings: clock: Document gcc bindings for SM8150
Quoting Vinod Koul (2019-07-22 00:43:47) > From: Deepak Katragadda > > Document the global clock controller found on SM8150. > > Signed-off-by: Deepak Katragadda > Signed-off-by: Taniya Das > [vkoul: port to upstream and add external clocks > split binding to this patch]] > Signed-off-by: Vinod Koul > --- Applied to clk-next
Re: [PATCH v4 5/5] clk: qcom: gcc: Add global clock controller driver for SM8150
Quoting Vinod Koul (2019-07-22 00:43:48) > From: Deepak Katragadda > > Add the clocks supported in global clock controller which clock the > peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks > to the clock framework for the clients to be able to request for them. > > Signed-off-by: Deepak Katragadda > Signed-off-by: Taniya Das > [vkoul: port to upstream and tidy-up > port to new parent scheme > Add comments for critical clocks]] > Signed-off-by: Vinod Koul > --- Applied to clk-next
Re: [PATCH v4 1/5] clk: qcom: clk-alpha-pll: Remove unnecessary cast
Quoting Vinod Koul (2019-07-22 00:43:44)
> Commit 8f9fab480c7a ("linux/kernel.h: fix overflow for
> DIV_ROUND_UP_ULL") fixed the overflow for DIV_ROUND_UP_ULL, so we no
> longer need the cast for DIV_ROUND_UP_ULL, so remove the unnecessary
> u64 casts.
>
> Signed-off-by: Vinod Koul
> ---
Applied to clk-next
Re: [PATCH v4 3/5] clk: qcom: clk-alpha-pll: Add support for Trion PLLs
Quoting Vinod Koul (2019-07-22 00:43:46) > From: Deepak Katragadda > > Add programming sequence support for managing the Trion > PLLs. > > Signed-off-by: Deepak Katragadda > Signed-off-by: Taniya Das > [vkoul: port to upstream and tidy-up > use upstream way of specifying PLLs] > Signed-off-by: Vinod Koul > --- Applied to clk-next
Re: [PATCH v5 03/10] powerpc: introduce kimage_vaddr to store the kernel base
On 2019/8/7 21:03, Michael Ellerman wrote: Jason Yan writes: Now the kernel base is a fixed value - KERNELBASE. To support KASLR, we need a variable to store the kernel base. Signed-off-by: Jason Yan Cc: Diana Craciun Cc: Michael Ellerman Cc: Christophe Leroy Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Nicholas Piggin Cc: Kees Cook Reviewed-by: Christophe Leroy Reviewed-by: Diana Craciun Tested-by: Diana Craciun --- arch/powerpc/include/asm/page.h | 2 ++ arch/powerpc/mm/init-common.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index 0d52f57fca04..60a68d3a54b1 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -315,6 +315,8 @@ void arch_free_page(struct page *page, int order); struct vm_area_struct; +extern unsigned long kimage_vaddr; + #include #endif /* __ASSEMBLY__ */ #include diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c index 152ae0d21435..d4801ce48dc5 100644 --- a/arch/powerpc/mm/init-common.c +++ b/arch/powerpc/mm/init-common.c @@ -25,6 +25,8 @@ phys_addr_t memstart_addr = (phys_addr_t)~0ull; EXPORT_SYMBOL_GPL(memstart_addr); phys_addr_t kernstart_addr; EXPORT_SYMBOL_GPL(kernstart_addr); +unsigned long kimage_vaddr = KERNELBASE; +EXPORT_SYMBOL_GPL(kimage_vaddr); The names of the #defines and variables we use for these values are not very consistent already, but using kimage_vaddr makes it worse I think. Isn't this going to have the same value as kernstart_addr, but the virtual rather than physical address? Yes, that's true. If so kernstart_virt_addr would seem better. OK, I will take kernstart_virt_addr if no better name appears. cheers .
Re: [PATCH net-next v4 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
Hi Heiner, On 8/7/19 12:18 PM, Heiner Kallweit wrote: > On 06.08.2019 23:42, Tao Ren wrote: >> Hi Andrew / Heiner / Vladimir, >> >> On 8/6/19 2:09 PM, Tao Ren wrote: >>> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for >>> example, on Facebook CMM BMC platform), mainly because genphy functions >>> are designed for copper links, and 1000Base-X (clause 37) auto negotiation >>> needs to be handled differently. >>> >>> This patch enables 1000Base-X support for BCM54616S by customizing 3 >>> driver callbacks: >>> >>> - probe: probe callback detects PHY's operation mode based on >>> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX >>> Control register. >>> >>> - config_aneg: bcm54616s_config_aneg_1000bx function is added for auto >>> negotiation in 1000Base-X mode. >>> >>> - read_status: BCM54616S and BCM5482 PHY share the same read_status >>> callback which manually set link speed and duplex mode in 1000Base-X >>> mode. >>> >>> Signed-off-by: Tao Ren >> >> I customized config_aneg function for BCM54616S 1000Base-X mode and >> link-down issue is also fixed: the patch is tested on Facebook CMM and >> Minipack BMC and everything looks normal. Please kindly review when you have >> bandwidth and let me know if you have further suggestions. >> >> BTW, I would be happy to help if we decide to add a set of genphy functions >> for clause 37, although that may mean I need more help/guidance from you :-) > > You want to have standard clause 37 aneg and this should be generic in phylib. > I hacked together a first version that is compile-tested only: > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_1143631_=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=iYElT7HC77pRZ3byVvW8ng=ZJArOJvHqNkqvs1x8l9HjfxjCN8e5xJpPz2YViBuKRA=EskpfBQtu9IBVeb96dv-sz76xIz4tJK5-lD4-qdIyWI= > > It supports fixed mode too. > > It doesn't support half duplex mode because phylib doesn't know 1000BaseX HD > yet. > Not sure whether half duplex mode is used at all in reality. > > You could test the new core functions in your own config_aneg and read_status > callback implementations. Thank you very much for the help! I'm planning to add these functions but I haven't started yet because I'm still going through clause 37 :-) Let me apply your patch and run some test on my platform. Will share you results tomorrow. Cheers, Tao
Re: [PATCH] clk: ingenic: Use CLK_OF_DECLARE_DRIVER macro
Quoting Paul Cercueil (2019-07-16 10:08:00) > By using CLK_OF_DECLARE_DRIVER instead of the CLK_OF_DECLARE macro, we > allow the driver to probe also as a platform driver. > > While this driver does not have code to probe as a platform driver, this > is still useful for probing children devices in the case where the > device node is compatible with "simple-mfd". > > Signed-off-by: Paul Cercueil > --- What's the baseline for this? It doesn't apply cleanly to v5.3-rc1
Re: [PATCH] clk: ingenic/jz4740: Fix "pll half" divider not read/written properly
Quoting Paul Cercueil (2019-08-07 16:28:10)
>
>
> Le mer. 7 août 2019 à 23:33, Stephen Boyd a écrit
> :
> > Quoting Paul Cercueil (2019-07-01 04:36:06)
> >> The code was setting the bit 21 of the CPCCR register to use a
> >> divider
> >> of 2 for the "pll half" clock, and clearing the bit to use a divider
> >> of 1.
> >>
> >> This is the opposite of how this register field works: a cleared bit
> >> means that the /2 divider is used, and a set bit means that the
> >> divider
> >> is 1.
> >>
> >> Restore the correct behaviour using the newly introduced .div_table
> >> field.
> >>
> >> Signed-off-by: Paul Cercueil
> >> ---
> >
> > Applied to clk-next. Does this need a fixes tag?
>
> It depends on commit a9fa2893fcc6 ("clk: ingenic: Add support for
> divider tables") which was sent without a fixes tag, so it'd be
> a bit difficult. Probably not worth the trouble.
>
Does it need to go in as a fix for this -rc series then? Or is it not
causing issues for you so it's ok to wait until next merge window?
[PATCH v3 1/1] ixgbe: sync the first fragment unconditionally
In Xen environment, if Xen-swiotlb is enabled, ixgbe driver
could possibly allocate a page, DMA memory buffer, for the first
fragment which is not suitable for Xen-swiotlb to do DMA operations.
Xen-swiotlb have to internally allocate another page for doing DMA
operations. This mechanism requires syncing the data from the internal
page to the page which ixgbe sends to upper network stack. However,
since commit f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path"), the unmap operation is performed with
DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed.
Since the sync isn't performed, the upper network stack could receive
a incomplete network packet. By incomplete, it means the linear data
on the first fragment(between skb->head and skb->end) is invalid. So
we have to copy the data from the internal xen-swiotlb page to the page
which ixgbe sends to upper network stack through the sync operation.
More details from Alexander Duyck:
Specifically since we are mapping the frame with
DMA_ATTR_SKIP_CPU_SYNC we have to unmap with that as well. As a result
a sync is not performed on an unmap and must be done manually as we
skipped it for the first frag. As such we need to always sync before
possibly performing a page unmap operation.
Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path")
Reviewed-by: Alexander Duyck
Signed-off-by: Firo Yang
---
Changes from v2:
* Added details on the problem caused by skipping the sync.
* Added more explanation from Alexander Duyck.
Changes from v1:
* Imporved the patch description.
* Added Reviewed-by: and Fixes: as suggested by Alexander Duyck.
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712d6529..200de9838096 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1825,13 +1825,7 @@ static void ixgbe_pull_tail(struct ixgbe_ring *rx_ring,
static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring,
struct sk_buff *skb)
{
- /* if the page was released unmap it, else just sync our portion */
- if (unlikely(IXGBE_CB(skb)->page_released)) {
- dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
-ixgbe_rx_pg_size(rx_ring),
-DMA_FROM_DEVICE,
-IXGBE_RX_DMA_ATTR);
- } else if (ring_uses_build_skb(rx_ring)) {
+ if (ring_uses_build_skb(rx_ring)) {
unsigned long offset = (unsigned long)(skb->data) & ~PAGE_MASK;
dma_sync_single_range_for_cpu(rx_ring->dev,
@@ -1848,6 +1842,14 @@ static void ixgbe_dma_sync_frag(struct ixgbe_ring
*rx_ring,
skb_frag_size(frag),
DMA_FROM_DEVICE);
}
+
+ /* If the page was released, just unmap it. */
+ if (unlikely(IXGBE_CB(skb)->page_released)) {
+ dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
+ixgbe_rx_pg_size(rx_ring),
+DMA_FROM_DEVICE,
+IXGBE_RX_DMA_ATTR);
+ }
}
/**
--
2.16.4
Re: [PATCH v4 02/20] RISC-V: Add bitmap reprensenting ISA features common across CPUs
On Thu, Aug 8, 2019 at 12:18 AM Atish Patra wrote:
>
> On Wed, 2019-08-07 at 12:28 +, Anup Patel wrote:
> > This patch adds riscv_isa bitmap which represents Host ISA features
> > common across all Host CPUs. The riscv_isa is not same as elf_hwcap
> > because elf_hwcap will only have ISA features relevant for user-space
> > apps whereas riscv_isa will have ISA features relevant to both kernel
> > and user-space apps.
> >
> > One of the use-case for riscv_isa bitmap is in KVM hypervisor where
> > we will use it to do following operations:
> >
> > 1. Check whether hypervisor extension is available
> > 2. Find ISA features that need to be virtualized (e.g. floating
> >point support, vector extension, etc.)
> >
> > Signed-off-by: Anup Patel
> > Signed-off-by: Atish Patra
> > ---
> > arch/riscv/include/asm/hwcap.h | 26 +++
> > arch/riscv/kernel/cpufeature.c | 79
> > --
> > 2 files changed, 102 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/hwcap.h
> > b/arch/riscv/include/asm/hwcap.h
> > index 7ecb7c6a57b1..9b657375aa51 100644
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@ -8,6 +8,7 @@
> > #ifndef __ASM_HWCAP_H
> > #define __ASM_HWCAP_H
> >
> > +#include
> > #include
> >
> > #ifndef __ASSEMBLY__
> > @@ -22,5 +23,30 @@ enum {
> > };
> >
> > extern unsigned long elf_hwcap;
> > +
> > +#define RISCV_ISA_EXT_a ('a' - 'a')
> > +#define RISCV_ISA_EXT_c ('c' - 'a')
> > +#define RISCV_ISA_EXT_d ('d' - 'a')
> > +#define RISCV_ISA_EXT_f ('f' - 'a')
> > +#define RISCV_ISA_EXT_h ('h' - 'a')
> > +#define RISCV_ISA_EXT_i ('i' - 'a')
> > +#define RISCV_ISA_EXT_m ('m' - 'a')
> > +#define RISCV_ISA_EXT_s ('s' - 'a')
> > +#define RISCV_ISA_EXT_u ('u' - 'a')
>
> As per the discussion in following threads, 'S' & 'U' are not valid ISA
> extensions. So we should drop them from here as well.
>
> http://lists.infradead.org/pipermail/linux-riscv/2019-August/005771.html
>
> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg01217.html
I disagree because we are not checking or enforcing required ISA features
here.
The asm/hwcap.h should define all possible feature and extension bits
defined by the RISC-V spec.
The 's' and 'u' bits in ISA mean that S-mode and U-mode are supported.
These bits are defined in RISC-V privileged spec as well.
Regards,
Anup
>
>
> > +#define RISCV_ISA_EXT_zicsr (('z' - 'a') + 1)
> > +#define RISCV_ISA_EXT_zifencei (('z' - 'a') + 2)
> > +#define RISCV_ISA_EXT_zam(('z' - 'a') + 3)
> > +#define RISCV_ISA_EXT_ztso (('z' - 'a') + 4)
> > +
> > +#define RISCV_ISA_EXT_MAX256
> > +
> > +unsigned long riscv_isa_extension_base(const unsigned long
> > *isa_bitmap);
> > +
> > +#define riscv_isa_extension_mask(ext) BIT_MASK(RISCV_ISA_EXT_##ext)
> > +
> > +bool __riscv_isa_extension_available(const unsigned long
> > *isa_bitmap, int bit);
> > +#define riscv_isa_extension_available(isa_bitmap, ext) \
> > + __riscv_isa_extension_available(isa_bitmap,
> > RISCV_ISA_EXT_##ext)
> > +
> > #endif
> > #endif
> > diff --git a/arch/riscv/kernel/cpufeature.c
> > b/arch/riscv/kernel/cpufeature.c
> > index b1ade9a49347..4ce71ce5e290 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -6,21 +6,64 @@
> > * Copyright (C) 2017 SiFive
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > #include
> >
> > unsigned long elf_hwcap __read_mostly;
> > +
> > +/* Host ISA bitmap */
> > +static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
> > +
> > #ifdef CONFIG_FPU
> > bool has_fpu __read_mostly;
> > #endif
> >
> > +/**
> > + * riscv_isa_extension_base - Get base extension word
> > + *
> > + * @isa_bitmap ISA bitmap to use
> > + * @returns base extension word as unsigned long value
> > + *
> > + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> > + */
> > +unsigned long riscv_isa_extension_base(const unsigned long
> > *isa_bitmap)
> > +{
> > + if (!isa_bitmap)
> > + return riscv_isa[0];
> > + return isa_bitmap[0];
> > +}
> > +EXPORT_SYMBOL_GPL(riscv_isa_extension_base);
> > +
> > +/**
> > + * __riscv_isa_extension_available - Check whether given extension
> > + * is available or not
> > + *
> > + * @isa_bitmap ISA bitmap to use
> > + * @bit bit position of the desired extension
> > + * @returns true or false
> > + *
> > + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> > + */
> > +bool __riscv_isa_extension_available(const unsigned long
> > *isa_bitmap, int bit)
> > +{
> > + const unsigned long *bmap = (isa_bitmap) ? isa_bitmap :
> > riscv_isa;
> > +
> > + if (bit >= RISCV_ISA_EXT_MAX)
> > + return false;
> > +
> > + return test_bit(bit, bmap) ? true : false;
> > +}
> >
i2c: imx: support slave mode for imx I2C driver
The patch supports slave mode for imx I2C driver
Signed-off-by: Biwen Li
---
drivers/i2c/busses/i2c-imx.c | 199 ---
1 file changed, 185 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b1b8b938d7f4..f7583a9fa56f 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -202,6 +202,9 @@ struct imx_i2c_struct {
struct pinctrl_state *pinctrl_pins_gpio;
struct imx_i2c_dma *dma;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ struct i2c_client *slave;
+#endif /* CONFIG_I2C_SLAVE */
};
static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
@@ -583,23 +586,40 @@ static void i2c_imx_stop(struct imx_i2c_struct *i2c_imx)
imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
}
-static irqreturn_t i2c_imx_isr(int irq, void *dev_id)
+/* Clear interrupt flag bit */
+static void i2c_imx_clr_if_bit(struct imx_i2c_struct *i2c_imx)
{
- struct imx_i2c_struct *i2c_imx = dev_id;
- unsigned int temp;
+ unsigned int status;
- temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
- if (temp & I2SR_IIF) {
- /* save status register */
- i2c_imx->i2csr = temp;
- temp &= ~I2SR_IIF;
- temp |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
- imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2SR);
- wake_up(_imx->queue);
- return IRQ_HANDLED;
- }
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ status &= ~I2SR_IIF;
+ status |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
+ imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
+}
+
+/* Clear arbitration lost bit */
+static void i2c_imx_clr_al_bit(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status;
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ status &= ~I2SR_IAL;
+ imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
+}
- return IRQ_NONE;
+static irqreturn_t i2c_imx_master_isr(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status;
+
+ dev_dbg(_imx->adapter.dev, "<%s>: master interrupt\n", __func__);
+
+ /* Save status register */
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ i2c_imx->i2csr = status | I2SR_IIF;
+
+ wake_up(_imx->queue);
+
+ return IRQ_HANDLED;
}
static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
@@ -1043,11 +1063,162 @@ static u32 i2c_imx_func(struct i2c_adapter *adapter)
| I2C_FUNC_SMBUS_READ_BLOCK_DATA;
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+static void i2c_imx_slave_init(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int temp;
+
+ dev_dbg(_imx->adapter.dev, "<%s>\n", __func__);
+
+ /* Set slave addr. */
+ imx_i2c_write_reg((i2c_imx->slave->addr << 1), i2c_imx, IMX_I2C_IADR);
+
+ /* Disable i2c module */
+ temp = i2c_imx->hwdata->i2cr_ien_opcode
+ ^ I2CR_IEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* Reset status register */
+ imx_i2c_write_reg(i2c_imx->hwdata->i2sr_clr_opcode, i2c_imx,
+ IMX_I2C_I2SR);
+
+ /* Enable module and enable interrupt from i2c module */
+ temp = i2c_imx->hwdata->i2cr_ien_opcode
+ | I2CR_IIEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* Wait controller to be stable */
+ usleep_range(50, 150);
+}
+
+static irqreturn_t i2c_imx_slave_isr(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status, ctl;
+ u8 value;
+
+ if (!i2c_imx->slave) {
+ dev_err(_imx->adapter.dev, "cannot deal with slave
irq,i2c_imx->slave is null");
+ return IRQ_NONE;
+ }
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ ctl = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ if (status & I2SR_IAL) { /* Arbitration lost */
+ i2c_imx_clr_al_bit(i2c_imx);
+ } else if (status & I2SR_IAAS) { /* Addressed as a slave */
+ if (status & I2SR_SRW) { /* Master wants to read from us*/
+ dev_dbg(_imx->adapter.dev, "read requested");
+ i2c_slave_event(i2c_imx->slave,
I2C_SLAVE_READ_REQUESTED, );
+
+ /* Slave transimt */
+ ctl |= I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+
+ /* Send data */
+ imx_i2c_write_reg(value, i2c_imx, IMX_I2C_I2DR);
+ } else { /* Master wants to write to us */
+ dev_dbg(_imx->adapter.dev, "write requested");
+ i2c_slave_event(i2c_imx->slave,
I2C_SLAVE_WRITE_REQUESTED, );
+
+ /* Slave receive */
+ ctl &= ~I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+
[PATCH] lib/generic-radix-tree.c - make 2 functions static inline
When building with W=1, we get some warnings:
l CC lib/generic-radix-tree.o
lib/generic-radix-tree.c:39:10: warning: no previous prototype for
'genradix_root_to_depth' [-Wmissing-prototypes]
39 | unsigned genradix_root_to_depth(struct genradix_root *r)
| ^~
lib/generic-radix-tree.c:44:23: warning: no previous prototype for
'genradix_root_to_node' [-Wmissing-prototypes]
44 | struct genradix_node *genradix_root_to_node(struct genradix_root *r)
| ^
They're not used anywhere else, so make them static inline.
Signed-off-by: Valdis Kletnieks
diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c
index a7bafc413730..ae25e2fa2187 100644
--- a/lib/generic-radix-tree.c
+++ b/lib/generic-radix-tree.c
@@ -36,12 +36,12 @@ static inline size_t genradix_depth_size(unsigned depth)
#define GENRADIX_DEPTH_MASK\
((unsigned long) (roundup_pow_of_two(GENRADIX_MAX_DEPTH + 1) - 1))
-unsigned genradix_root_to_depth(struct genradix_root *r)
+static inline unsigned genradix_root_to_depth(struct genradix_root *r)
{
return (unsigned long) r & GENRADIX_DEPTH_MASK;
}
-struct genradix_node *genradix_root_to_node(struct genradix_root *r)
+static inline struct genradix_node *genradix_root_to_node(struct genradix_root
*r)
{
return (void *) ((unsigned long) r & ~GENRADIX_DEPTH_MASK);
}
Re: [PATCH v2 1/1] ixgbe: sync the first fragment unconditionally
On Wed, Aug 7, 2019 at 6:58 PM Jacob Wen wrote: > > > On 8/7/19 4:38 PM, Firo Yang wrote: > > The 08/07/2019 15:56, Jacob Wen wrote: > >> I think the description is not correct. Consider using something like > >> below. > > Thank you for comments. > > > >> In Xen environment, due to memory fragmentation ixgbe may allocate a 'DMA' > >> buffer with pages that are not physically contiguous. > > Actually, I didn't look into the reason why ixgbe got a DMA buffer which > > was mapped to Xen-swiotlb area. > Yes. I was wrong. You don't need to tell the exact reason. > > > > But I don't think this issue relates to phsical memory contiguity because, > > in > > our case, one ixgbe_rx_buffer only associates at most one page. > > This is interesting. > > I guess the performance of the NIC in your environment is not good due > to the extra cost of bounce buffer. If I recall correctly the Rx performance for ixgbe shouldn't be too bad even with a bounce buffer. The cost for map/unmap are expensive for a bounce buffer setup but the syncs are just copies so they are pretty cheap in comparison. The driver can take advantage of that on Rx since it leaves the pages mapped and just syncs the portion of the pages that are used. Now if you are hitting the bounce buffer on the Tx side that is another matter as you have to allocate the buffer on demand and that is quite expensive.
Re: [PATCH v2 1/2] linux/bits.h: Clarify macro argument names
On Fri, Aug 2, 2019 at 8:04 AM Rikard Falkeborn wrote: > > Be a little more verbose to improve readability. > > Signed-off-by: Rikard Falkeborn BTW, I do not understand what the improvement is. I tend to regard this as a noise commit. > --- > Changes in v2: > - This patch is new in v2 > > include/linux/bits.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/include/linux/bits.h b/include/linux/bits.h > index 669d69441a62..d4466aa42a9c 100644 > --- a/include/linux/bits.h > +++ b/include/linux/bits.h > @@ -14,16 +14,16 @@ > #define BITS_PER_BYTE 8 > > /* > - * Create a contiguous bitmask starting at bit position @l and ending at > - * position @h. For example > + * Create a contiguous bitmask starting at bit position @low and ending at > + * position @high. For example > * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. > */ > -#define GENMASK(h, l) \ > - (((~UL(0)) - (UL(1) << (l)) + 1) & \ > -(~UL(0) >> (BITS_PER_LONG - 1 - (h > +#define GENMASK(high, low) \ > + (((~UL(0)) - (UL(1) << (low)) + 1) & \ > +(~UL(0) >> (BITS_PER_LONG - 1 - (high > > -#define GENMASK_ULL(h, l) \ > - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h > +#define GENMASK_ULL(high, low) \ > + (((~ULL(0)) - (ULL(1) << (low)) + 1) & \ > +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (high > > #endif /* __LINUX_BITS_H */ > -- > 2.22.0 > -- Best Regards Masahiro Yamada
[PATCH] lib/extable.c - add missing prototypes.
When building with W=1, a number of warnings are issued: CC lib/extable.o lib/extable.c:63:6: warning: no previous prototype for 'sort_extable' [-Wmissing-prototypes] 63 | void sort_extable(struct exception_table_entry *start, | ^~~~ lib/extable.c:75:6: warning: no previous prototype for 'trim_init_extable' [-Wmissing-prototypes] 75 | void trim_init_extable(struct module *m) | ^ lib/extable.c:115:1: warning: no previous prototype for 'search_extable' [-Wmissing-prototypes] 115 | search_extable(const struct exception_table_entry *base, | ^~ Add the missing #include for the prototypes. Signed-off-by: Valdis Kletnieks diff --git a/lib/extable.c b/lib/extable.c index 25da4071122a..c3e59caf7ffa 100644 --- a/lib/extable.c +++ b/lib/extable.c @@ -10,6 +10,7 @@ #include #include #include +#include #ifndef ARCH_HAS_RELATIVE_EXTABLE #define ex_to_insn(x) ((x)->insn)
[PATCH v1 2/2] i2c: iproc: Add full name of devicetree node to adapter name
From: Lori Hikichi Add the full name of the devicetree node to the adapter name. Without this change, all adapters have the same name making it difficult to distinguish between multiple instances. The most obvious way to see this is to use the utility i2c_detect. e.g. "i2c-detect -l" Before i2c-1 i2c Broadcom iProc I2C adapter I2C adapter i2c-0 i2c Broadcom iProc I2C adapter I2C adapter After i2c-1 i2c Broadcom iProc (i2c@e) I2C adapter i2c-0 i2c Broadcom iProc (i2c@b) I2C adapter Now it is easy to figure out which adapter maps to a which DT node. Signed-off-by: Lori Hikichi Signed-off-by: Rayagonda Kokatanur --- drivers/i2c/busses/i2c-bcm-iproc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c index 19ef2b0..183b220 100644 --- a/drivers/i2c/busses/i2c-bcm-iproc.c +++ b/drivers/i2c/busses/i2c-bcm-iproc.c @@ -922,7 +922,9 @@ static int bcm_iproc_i2c_probe(struct platform_device *pdev) adap = _i2c->adapter; i2c_set_adapdata(adap, iproc_i2c); - strlcpy(adap->name, "Broadcom iProc I2C adapter", sizeof(adap->name)); + snprintf(adap->name, sizeof(adap->name), + "Broadcom iProc (%s)", + of_node_full_name(iproc_i2c->device->of_node)); adap->algo = _iproc_algo; adap->quirks = _iproc_i2c_quirks; adap->dev.parent = >dev; -- 1.9.1
[PATCH v1 1/2] i2c: iproc: Stop advertising support of SMBUS quick cmd
From: Lori Hikichi
The driver does not support the SMBUS Quick command so remove the
flag that indicates that level of support.
By default the i2c_detect tool uses the quick command to try and
detect devices at some bus addresses. If the quick command is used
then we will not detect the device, even though it is present.
Fixes: e6e5dd3566e0 (i2c: iproc: Add Broadcom iProc I2C Driver)
Signed-off-by: Lori Hikichi
Signed-off-by: Rayagonda Kokatanur
---
drivers/i2c/busses/i2c-bcm-iproc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..19ef2b0 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -790,7 +790,10 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
{
- u32 val = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+ u32 val;
+
+ /* We do not support the SMBUS Quick command */
+ val = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
if (adap->algo->reg_slave)
val |= I2C_FUNC_SLAVE;
--
1.9.1
[PATCH v1 0/2] Remove smbus quick cmd and update adapter name
Hi, This patchset contains following changes: - Remove SMBUS quick command support - Update full name of dt node to adapter name Lori Hikichi (2): i2c: iproc: Stop advertising support of SMBUS quick cmd i2c: iproc: Add full name of devicetree node to adapter name drivers/i2c/busses/i2c-bcm-iproc.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) -- 1.9.1
Re: [PATCH] hugetlbfs: fix hugetlb page migration/fault race causing SIGBUS
On Wed, Aug 07, 2019 at 05:05:33PM -0700, Mike Kravetz wrote:
> Li Wang discovered that LTP/move_page12 V2 sometimes triggers SIGBUS
> in the kernel-v5.2.3 testing. This is caused by a race between hugetlb
> page migration and page fault.
>
> If a hugetlb page can not be allocated to satisfy a page fault, the task
> is sent SIGBUS. This is normal hugetlbfs behavior. A hugetlb fault
> mutex exists to prevent two tasks from trying to instantiate the same
> page. This protects against the situation where there is only one
> hugetlb page, and both tasks would try to allocate. Without the mutex,
> one would fail and SIGBUS even though the other fault would be successful.
>
> There is a similar race between hugetlb page migration and fault.
> Migration code will allocate a page for the target of the migration.
> It will then unmap the original page from all page tables. It does
> this unmap by first clearing the pte and then writing a migration
> entry. The page table lock is held for the duration of this clear and
> write operation. However, the beginnings of the hugetlb page fault
> code optimistically checks the pte without taking the page table lock.
> If clear (as it can be during the migration unmap operation), a hugetlb
> page allocation is attempted to satisfy the fault. Note that the page
> which will eventually satisfy this fault was already allocated by the
> migration code. However, the allocation within the fault path could
> fail which would result in the task incorrectly being sent SIGBUS.
>
> Ideally, we could take the hugetlb fault mutex in the migration code
> when modifying the page tables. However, locks must be taken in the
> order of hugetlb fault mutex, page lock, page table lock. This would
> require significant rework of the migration code. Instead, the issue
> is addressed in the hugetlb fault code. After failing to allocate a
> huge page, take the page table lock and check for huge_pte_none before
> returning an error. This is the same check that must be made further
> in the code even if page allocation is successful.
>
> Reported-by: Li Wang
> Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
> Signed-off-by: Mike Kravetz
> Tested-by: Li Wang
Thanks for the work and nice description.
Reviewed-by: Naoya Horiguchi
> ---
> mm/hugetlb.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ede7e7f5d1ab..6d7296dd11b8 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3856,6 +3856,25 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
>
> page = alloc_huge_page(vma, haddr, 0);
> if (IS_ERR(page)) {
> + /*
> + * Returning error will result in faulting task being
> + * sent SIGBUS. The hugetlb fault mutex prevents two
> + * tasks from racing to fault in the same page which
> + * could result in false unable to allocate errors.
> + * Page migration does not take the fault mutex, but
> + * does a clear then write of pte's under page table
> + * lock. Page fault code could race with migration,
> + * notice the clear pte and try to allocate a page
> + * here. Before returning error, get ptl and make
> + * sure there really is no pte entry.
> + */
> + ptl = huge_pte_lock(h, mm, ptep);
> + if (!huge_pte_none(huge_ptep_get(ptep))) {
> + ret = 0;
> + spin_unlock(ptl);
> + goto out;
> + }
> + spin_unlock(ptl);
> ret = vmf_error(PTR_ERR(page));
> goto out;
> }
> --
> 2.20.1
>
>
Re: [PATCH v5 02/10] powerpc: move memstart_addr and kernstart_addr to init-common.c
On 2019/8/7 21:02, Michael Ellerman wrote: Jason Yan writes: These two variables are both defined in init_32.c and init_64.c. Move them to init-common.c. Signed-off-by: Jason Yan Cc: Diana Craciun Cc: Michael Ellerman Cc: Christophe Leroy Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Nicholas Piggin Cc: Kees Cook Reviewed-by: Christophe Leroy Reviewed-by: Diana Craciun Tested-by: Diana Craciun --- arch/powerpc/mm/init-common.c | 5 + arch/powerpc/mm/init_32.c | 5 - arch/powerpc/mm/init_64.c | 5 - 3 files changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c index a84da92920f7..152ae0d21435 100644 --- a/arch/powerpc/mm/init-common.c +++ b/arch/powerpc/mm/init-common.c @@ -21,6 +21,11 @@ #include #include +phys_addr_t memstart_addr = (phys_addr_t)~0ull; +EXPORT_SYMBOL_GPL(memstart_addr); +phys_addr_t kernstart_addr; +EXPORT_SYMBOL_GPL(kernstart_addr); Would be nice if these can be __ro_after_init ? Good idea. cheers .
[PATCH] arm64/cache: silence -Woverride-init warnings
The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
VIVT I-caches") introduced some compiation warnings from GCC (and
Clang) with -Winitializer-overrides),
arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_VIPT] = "VIPT",
^~
arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
'icache_policy_str[2]')
arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_PIPT] = "PIPT",
^~
arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
'icache_policy_str[3]')
arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_VPIPT] = "VPIPT",
^~~
arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
'icache_policy_str[0]')
because it initializes icache_policy_str[0 ... 3] twice. Since
arm64 developers are keen to keep the style of initializing a static
array with a non-zero pattern first, just disable those warnings for
both GCC and Clang of this file.
Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT
I-caches")
Signed-off-by: Qian Cai
---
arch/arm64/kernel/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 478491f07b4f..397ed5f7be1e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -11,6 +11,9 @@ CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
+CFLAGS_cpuinfo.o += $(call cc-disable-warning, override-init)
+CFLAGS_cpuinfo.o += $(call cc-disable-warning, initializer-overrides)
+
# Object file lists.
obj-y := debug-monitors.o entry.o irq.o fpsimd.o
\
entry-fpsimd.o process.o ptrace.o setup.o signal.o
\
--
2.20.1 (Apple Git-117)
[PATCH] arch/x86/lib/cpu-c - missing prototypes
When building with W=1, we get warnings about missing prototypes:
CC arch/x86/lib/cpu.o
arch/x86/lib/cpu.c:5:14: warning: no previous prototype for 'x86_family'
[-Wmissing-prototypes]
5 | unsigned int x86_family(unsigned int sig)
| ^~
arch/x86/lib/cpu.c:18:14: warning: no previous prototype for 'x86_model'
[-Wmissing-prototypes]
18 | unsigned int x86_model(unsigned int sig)
| ^
arch/x86/lib/cpu.c:33:14: warning: no previous prototype for 'x86_stepping'
[-Wmissing-prototypes]
33 | unsigned int x86_stepping(unsigned int sig)
| ^~~~
Add the proper include file so the prototypes are there.
Signed-off-by: Valdis Kletnieks
diff --git a/arch/x86/lib/cpu.c b/arch/x86/lib/cpu.c
index 04967cdce5d1..7ad68917a51e 100644
--- a/arch/x86/lib/cpu.c
+++ b/arch/x86/lib/cpu.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
#include
#include
+#include
unsigned int x86_family(unsigned int sig)
{
Re: [PATCH] mm/mmap.c: refine data locality of find_vma_prev
On Wed, Aug 07, 2019 at 09:51:01AM +0200, Michal Hocko wrote:
>On Wed 07-08-19 08:31:09, Wei Yang wrote:
>> On Tue, Aug 06, 2019 at 11:29:52AM +0200, Vlastimil Babka wrote:
>> >On 8/6/19 10:11 AM, Wei Yang wrote:
>> >> When addr is out of the range of the whole rb_tree, pprev will points to
>> >> the biggest node. find_vma_prev gets is by going through the right most
>> >
>> >s/biggest/last/ ? or right-most?
>> >
>> >> node of the tree.
>> >>
>> >> Since only the last node is the one it is looking for, it is not
>> >> necessary to assign pprev to those middle stage nodes. By assigning
>> >> pprev to the last node directly, it tries to improve the function
>> >> locality a little.
>> >
>> >In the end, it will always write to the cacheline of pprev. The caller has
>> >most
>> >likely have it on stack, so it's already hot, and there's no other CPU
>> >stealing
>> >it. So I don't understand where the improved locality comes from. The
>> >compiler
>> >can also optimize the patched code so the assembly is identical to the
>> >previous
>> >code, or vice versa. Did you check for differences?
>>
>> Vlastimil
>>
>> Thanks for your comment.
>>
>> I believe you get a point. I may not use the word locality. This patch tries
>> to reduce some unnecessary assignment of pprev.
>>
>> Original code would assign the value on each node during iteration, this is
>> what I want to reduce.
>
>Is there any measurable difference (on micro benchmarks or regular
>workloads)?
I wrote a test case to compare these two methods, but not find visible
difference in run time.
While I found we may leverage rb_last to refine the code a little.
@@ -2270,12 +2270,9 @@ find_vma_prev(struct mm_struct *mm, unsigned long addr,
if (vma) {
*pprev = vma->vm_prev;
} else {
- struct rb_node *rb_node = mm->mm_rb.rb_node;
- *pprev = NULL;
- while (rb_node) {
- *pprev = rb_entry(rb_node, struct vm_area_struct,
vm_rb);
- rb_node = rb_node->rb_right;
- }
+ struct rb_node *rb_node = rb_last(>mm_rb);
+ *pprev = !rb_node ? NULL :
+rb_entry(rb_node, struct vm_area_struct, vm_rb);
}
return vma;
Not sure this style would help a little in understanding the code?
>--
>Michal Hocko
>SUSE Labs
--
Wei Yang
Help you, Help me
[PATCH -next] ASoC: tscs454: remove unused variable 'PLL_48K_RATE'
The global variable 'PLL_48K_RATE' is never used so just remove it. Signed-off-by: YueHaibing --- sound/soc/codecs/tscs454.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/codecs/tscs454.c b/sound/soc/codecs/tscs454.c index 93d84e5..c3587af 100644 --- a/sound/soc/codecs/tscs454.c +++ b/sound/soc/codecs/tscs454.c @@ -22,7 +22,6 @@ #include "tscs454.h" -static const unsigned int PLL_48K_RATE = (48000 * 256); static const unsigned int PLL_44_1K_RATE = (44100 * 256); #define COEFF_SIZE 3 -- 2.7.4
Re: [PATCH 1/2] dt-bindings: interrupt-controller: msi: Correct msi-controller@c's reg
On Thu, Aug 1, 2019 at 5:53 PM Bin Meng wrote:
>
> On Sun, Jul 28, 2019 at 5:30 PM Bin Meng wrote:
> >
> > The base address of msi-controller@c should be set to c.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > Documentation/devicetree/bindings/interrupt-controller/msi.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/msi.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
> > index c60c034..c20b51d 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/msi.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
> > @@ -98,7 +98,7 @@ Example
> > };
> >
> > msi_c: msi-controller@c {
> > - reg = <0xb 0xf00>;
> > + reg = <0xc 0xf00>;
> > compatible = "vendor-b,another-controller";
> > msi-controller;
> > /* Each device has some unique ID */
> > --
>
> Ping?
Ping?
Re: [PATCH v5 01/10] powerpc: unify definition of M_IF_NEEDED
On 2019/8/7 21:13, Michael Ellerman wrote: Jason Yan writes: M_IF_NEEDED is defined too many times. Move it to a common place. The name is not great, can you call it MAS2_M_IF_NEEDED, which at least gives a clue what it's for? OK. cheers Signed-off-by: Jason Yan Cc: Diana Craciun Cc: Michael Ellerman Cc: Christophe Leroy Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Nicholas Piggin Cc: Kees Cook Reviewed-by: Christophe Leroy Reviewed-by: Diana Craciun Tested-by: Diana Craciun --- arch/powerpc/include/asm/nohash/mmu-book3e.h | 10 ++ arch/powerpc/kernel/exceptions-64e.S | 10 -- arch/powerpc/kernel/fsl_booke_entry_mapping.S | 10 -- arch/powerpc/kernel/misc_64.S | 5 - 4 files changed, 10 insertions(+), 25 deletions(-) diff --git a/arch/powerpc/include/asm/nohash/mmu-book3e.h b/arch/powerpc/include/asm/nohash/mmu-book3e.h index 4c9777d256fb..0877362e48fa 100644 --- a/arch/powerpc/include/asm/nohash/mmu-book3e.h +++ b/arch/powerpc/include/asm/nohash/mmu-book3e.h @@ -221,6 +221,16 @@ #define TLBILX_T_CLASS2 6 #define TLBILX_T_CLASS3 7 +/* + * The mapping only needs to be cache-coherent on SMP, except on + * Freescale e500mc derivatives where it's also needed for coherent DMA. + */ +#if defined(CONFIG_SMP) || defined(CONFIG_PPC_E500MC) +#define M_IF_NEEDEDMAS2_M +#else +#define M_IF_NEEDED0 +#endif + #ifndef __ASSEMBLY__ #include diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 1cfb3da4a84a..fd49ec07ce4a 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -1342,16 +1342,6 @@ skpinv: addir6,r6,1 /* Increment */ sync isync -/* - * The mapping only needs to be cache-coherent on SMP, except on - * Freescale e500mc derivatives where it's also needed for coherent DMA. - */ -#if defined(CONFIG_SMP) || defined(CONFIG_PPC_E500MC) -#define M_IF_NEEDEDMAS2_M -#else -#define M_IF_NEEDED0 -#endif - /* 6. Setup KERNELBASE mapping in TLB[0] * * r3 = MAS0 w/TLBSEL & ESEL for the entry we started in diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S b/arch/powerpc/kernel/fsl_booke_entry_mapping.S index ea065282b303..de0980945510 100644 --- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S +++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S @@ -153,16 +153,6 @@ skpinv:addir6,r6,1 /* Increment */ tlbivax 0,r9 TLBSYNC -/* - * The mapping only needs to be cache-coherent on SMP, except on - * Freescale e500mc derivatives where it's also needed for coherent DMA. - */ -#if defined(CONFIG_SMP) || defined(CONFIG_PPC_E500MC) -#define M_IF_NEEDEDMAS2_M -#else -#define M_IF_NEEDED0 -#endif - #if defined(ENTRY_MAPPING_BOOT_SETUP) /* 6. Setup KERNELBASE mapping in TLB1[0] */ diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b55a7b4cb543..26074f92d4bc 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -432,11 +432,6 @@ kexec_create_tlb: rlwimi r9,r10,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r9) */ /* Set up a temp identity mapping v:0 to p:0 and return to it. */ -#if defined(CONFIG_SMP) || defined(CONFIG_PPC_E500MC) -#define M_IF_NEEDEDMAS2_M -#else -#define M_IF_NEEDED0 -#endif mtspr SPRN_MAS0,r9 lis r9,(MAS1_VALID|MAS1_IPROT)@h -- 2.17.2 .
Re: [PATCH 2/2] dt-bindings: pci: pci-msi: Correct the unit-address of the pci node name
On Thu, Aug 1, 2019 at 5:53 PM Bin Meng wrote:
>
> On Sun, Jul 28, 2019 at 5:30 PM Bin Meng wrote:
> >
> > The unit-address must match the first address specified in the
> > reg property of the node.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > Documentation/devicetree/bindings/pci/pci-msi.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt
> > b/Documentation/devicetree/bindings/pci/pci-msi.txt
> > index 9b3cc81..b73d839 100644
> > --- a/Documentation/devicetree/bindings/pci/pci-msi.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
> > @@ -201,7 +201,7 @@ Example (5)
> > #msi-cells = <1>;
> > };
> >
> > - pci: pci@c {
> > + pci: pci@f {
> > reg = <0xf 0x1>;
> > compatible = "vendor,pcie-root-complex";
> > device_type = "pci";
> > --
>
> Ping?
Ping?
Re: [PATCH v5 00/10] implement KASLR for powerpc/fsl_booke/32
On 2019/8/7 21:12, Michael Ellerman wrote: Hi Jason, Jason Yan writes: This series implements KASLR for powerpc/fsl_booke/32, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. Thanks for doing this work. Sorry I didn't get a chance to look at this until v5, I sent a few comments just now. Nothing major though, I think this looks almost ready to merge. Thank you. I will try my best to improve the code. cheers Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. Entropy is derived from the banner and timer base, which will change every build and boot. This not so much safe so additionally the bootloader may pass entropy via the /chosen/kaslr-seed node in device tree. We will use the first 512M of the low memory to randomize the kernel image. The memory will be split in 64M zones. We will use the lower 8 bit of the entropy to decide the index of the 64M zone. Then we chose a 16K aligned offset inside the 64M zone to put the kernel in. KERNELBASE |--> 64M <--| | | +---+++---+ | |||kernel|| | +---+++---+ | | |-> offset<-| kimage_vaddr We also check if we will overlap with some areas like the dtb area, the initrd area or the crashkernel area. If we cannot find a proper area, kaslr will be disabled and boot from the original kernel. Changes since v4: - Add Reviewed-by tag from Christophe - Remove an unnecessary cast - Remove unnecessary parenthesis - Fix checkpatch warning Changes since v3: - Add Reviewed-by and Tested-by tag from Diana - Change the comment in fsl_booke_entry_mapping.S to be consistent with the new code. Changes since v2: - Remove unnecessary #ifdef - Use SZ_64M instead of0x400 - Call early_init_dt_scan_chosen() to init boot_command_line - Rename kaslr_second_init() to kaslr_late_init() Changes since v1: - Remove some useless 'extern' keyword. - Replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL - Improve some assembly code - Use memzero_explicit instead of memset - Use boot_command_line and remove early_command_line - Do not print kaslr offset if kaslr is disabled Jason Yan (10): powerpc: unify definition of M_IF_NEEDED powerpc: move memstart_addr and kernstart_addr to init-common.c powerpc: introduce kimage_vaddr to store the kernel base powerpc/fsl_booke/32: introduce create_tlb_entry() helper powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper powerpc/fsl_booke/32: implement KASLR infrastructure powerpc/fsl_booke/32: randomize the kernel image offset powerpc/fsl_booke/kaslr: clear the original kernel if randomized powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter powerpc/fsl_booke/kaslr: dump out kernel offset information on panic arch/powerpc/Kconfig | 11 + arch/powerpc/include/asm/nohash/mmu-book3e.h | 10 + arch/powerpc/include/asm/page.h | 7 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/early_32.c| 2 +- arch/powerpc/kernel/exceptions-64e.S | 10 - arch/powerpc/kernel/fsl_booke_entry_mapping.S | 27 +- arch/powerpc/kernel/head_fsl_booke.S | 55 ++- arch/powerpc/kernel/kaslr_booke.c | 427 ++ arch/powerpc/kernel/machine_kexec.c | 1 + arch/powerpc/kernel/misc_64.S | 5 - arch/powerpc/kernel/setup-common.c| 19 + arch/powerpc/mm/init-common.c | 7 + arch/powerpc/mm/init_32.c | 5 - arch/powerpc/mm/init_64.c | 5 - arch/powerpc/mm/mmu_decl.h| 10 + arch/powerpc/mm/nohash/fsl_booke.c| 8 +- 17 files changed, 560 insertions(+), 50 deletions(-) create mode 100644 arch/powerpc/kernel/kaslr_booke.c -- 2.17.2 .
Re: linux-next: build failure after merge of the crypto tree
Hi Herbert, On Thu, 8 Aug 2019 13:01:57 +1000 Herbert Xu wrote: > > Sorry, I forgot about your patch as it wasn't cced to the crypto > mailing list. It should be out there now. Excellent, thanks. Should I add the crypto mailing list as a contact for problems? Mostly the emails are just reporting conflicts and only very occasionally do I actually send a useful patch. If so, what is its address? > I've also added a compile test for this driver so at least it should > fail for me on x86 too. Even better! ;-) -- Cheers, Stephen Rothwell pgpflEW2vRSJ5.pgp Description: OpenPGP digital signature
Re: [PATCH 2/6] dt-bindings: arm: amlogic: add bindings for G12B based S922X SoC
Rob Herring writes: > On Mon, Aug 5, 2019 at 3:46 PM Kevin Hilman wrote: >> >> Neil Armstrong writes: >> >> > Add a specific compatible for the Amlogic G12B family based S922X SoC >> > to differentiate with the A311D SoC from the same family. >> > >> > Signed-off-by: Neil Armstrong >> > --- >> > Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml >> > b/Documentation/devicetree/bindings/arm/amlogic.yaml >> > index 325c6fd3566d..3c3bc806cd23 100644 >> > --- a/Documentation/devicetree/bindings/arm/amlogic.yaml >> > +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml >> > @@ -139,6 +139,7 @@ properties: >> > items: >> >- enum: >> >- hardkernel,odroid-n2 >> > + - const: amlogic,s922x >> >- const: amlogic,g12b >> >> nit: in previous binding docs, we were trying to keep these sorted >> alphabetically. I'll reorder the new "s922x" after "g12b" when >> applying. > > No, this is not documentation ordering. It's the order compatible > strings must be in. Ah, thanks for clarifying, Kevin
[PATCH] ARM: ep93xx: Mark expected switch fall-through
Mark switch cases where we are expecting to fall through. Fix the following warnings (Building: arm-ep93xx_defconfig arm): arch/arm/mach-ep93xx/crunch.c: In function 'crunch_do': arch/arm/mach-ep93xx/crunch.c:46:3: warning: this statement may fall through [-Wimplicit-fallthrough=] memset(crunch_state, 0, sizeof(*crunch_state)); ^~ arch/arm/mach-ep93xx/crunch.c:53:2: note: here case THREAD_NOTIFY_EXIT: ^~~~ Notice that, in this particular case, the code comment is modified in accordance with what GCC is expecting to find. Reported-by: kbuild test robot Signed-off-by: Gustavo A. R. Silva --- arch/arm/mach-ep93xx/crunch.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-ep93xx/crunch.c b/arch/arm/mach-ep93xx/crunch.c index 1c9a4be8b503..1c05c5bf7e5c 100644 --- a/arch/arm/mach-ep93xx/crunch.c +++ b/arch/arm/mach-ep93xx/crunch.c @@ -49,6 +49,7 @@ static int crunch_do(struct notifier_block *self, unsigned long cmd, void *t) * FALLTHROUGH: Ensure we don't try to overwrite our newly * initialised state information on the first fault. */ + /* Fall through */ case THREAD_NOTIFY_EXIT: crunch_task_release(thread); -- 2.22.0
Re: linux-next: build failure after merge of the crypto tree
On Thu, Aug 08, 2019 at 11:52:45AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 5 Aug 2019 14:57:36 +1000 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the crypto tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/char/hw_random/n2-drv.c: In function 'n2rng_probe':
> > drivers/char/hw_random/n2-drv.c:771:29: error: 'pdev' undeclared (first use
> > in this function); did you mean 'cdev'?
> > err = devm_hwrng_register(>dev, >hwrng);
> > ^~~~
> > cdev
> > drivers/char/hw_random/n2-drv.c:771:29: note: each undeclared identifier is
> > reported only once for each function it appears in
> >
> > Caused by commit
> >
> > 3e75241be808 ("hwrng: drivers - Use device-managed registration API")
> >
> > I applied the following patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 5 Aug 2019 14:49:59 +1000
> > Subject: [PATCH] hwrng: fix typo in n2-drv.c
> >
> > Fixes: 3e75241be808 ("hwrng: drivers - Use device-managed registration API")
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/char/hw_random/n2-drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/hw_random/n2-drv.c
> > b/drivers/char/hw_random/n2-drv.c
> > index 2d256b3470db..73e408146420 100644
> > --- a/drivers/char/hw_random/n2-drv.c
> > +++ b/drivers/char/hw_random/n2-drv.c
> > @@ -768,7 +768,7 @@ static int n2rng_probe(struct platform_device *op)
> > np->hwrng.data_read = n2rng_data_read;
> > np->hwrng.priv = (unsigned long) np;
> >
> > - err = devm_hwrng_register(>dev, >hwrng);
> > + err = devm_hwrng_register(>dev, >hwrng);
> > if (err)
> > goto out_hvapi_unregister;
> >
> > --
> > 2.20.1
>
> I am still applying that patch ...
Sorry, I forgot about your patch as it wasn't cced to the crypto
mailing list. It should be out there now.
I've also added a compile test for this driver so at least it should
fail for me on x86 too.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
Martin Blumenstingl writes: > Hi Guillaume, > > On Mon, Aug 5, 2019 at 2:48 PM guillaume La Roque > wrote: >> >> Hi Martin, >> >> again thanks for your review. > you're welcome - thank you for working on the driver :-) > > [...] >> > The IP block has more functionality, which may be added to this driver >> > in the future: >> > - reading up to 16 stored temperature samples >> >> it's not working, you can verify it if you check the regmap define in the >> driver. in fact temp is only write in one register, it's confirmed by >> amlogic. > I missed that - so please skip this part > > [...] >> >> +config AMLOGIC_THERMAL >> > we typically use "MESON" in the Kconfig symbols: >> > $ grep -c AMLOGIC .config >> > 1 >> > $ grep -c MESON .config >> > 33 >> > >> > I also wonder if we should add G12 or G12A so we don't conflict with >> > upcoming thermal sensors with a different design (assuming that this >> > will be a thing). >> > for example we already have three different USB2 PHY drivers >> > >> > [...] >> >> i check with Neil and for new family it's better to use Amlogic instead of >> meson. > can you please share the considerations behind this decision? > if new drivers should use AMLOGIC_* Kconfig symbols instead of MESON_* > then we all should know about it > >> i don't add G12 because we already know it's same sensors for SM1 SoC family >> [0]. > my idea behind this was to avoid conflicts in the future > in case of the thermal driver we may be fine with using a generic name > assuming that Amlogic will not switch to a new IP block in the next > years > I'm not saying you have to change the name - I'm bringing this up so > you can decide for yourself based on examples from the past > > here are a few examples: > - when Kevin upstreamed the MMC driver for GX he decided to use > MMC_MESON_GX for the Kconfig symbol name. it turns out that this is > smart because there are at least two other MMC controller IPs on the > 32-bit SoCs. due to him including GX in the name the drivers are easy > to differentiate (MMC_MESON_MX_SDIO and MMC_MESON_MX_SDHC being the > other ones, while the latter is not upstream yet) > - when Carlo upstreamed the eFuse driver he decided to use MESON_EFUSE > for the Kconfig symbol name. I found out much later that the 32-bit > SoCs use a different IP (or at least direct register access instead of > going through Secure Monitor). the driver for the 32-bit SoCs now uses > MESON_MX_EFUSE. if you don't know which driver applies where then it's > easy to mix up MESON_EFUSE and MESON_MX_EFUSE > - when Jerome upstreamed the ALSA driver for AXG (which is also used > on G12A and G12B) he decided to use the SND_MESON_AXG_* prefix for the > Kconfig symbol names. in my opinion this was a good choice because GXM > and everything earlier (including the 32-bit SoCs) use a different > audio IP block. we won't have a Kconfig symbol name clash when a > driver for the "older" SoCs is upstreamed > - (there are more examples, Meson8b USB PHY driver, Meson8b DWMAC > glue, ... - just like there's many examples where the IP block is > mostly compatible with older generations: SAR ADC, RNG, SPI, ...) While these are all good examples, you can see it can go both ways, so there's really no way know up front what is the "right" way. We only know after the fact. Unfortunately, we simply have no visibility into future chips and where IP blocks may be shared or not (there are other examples where vendors add a new version of an IP *and* keep the old version. ;) Even having worked inside a (different) SoC vendor and having some knowledge about what IPs are shared, it's difficult to get this right. > I'm not sure what driver naming rules other mainline SoC teams use > to me it seems that the rule for Allwinner driver names is to use the > "code-name of the first SoC the IP block appeared in" That's a good rule of thumb (and one we generally follow) but I don't feel it's important enough to enforce strictly either. Kevin
[PATCH] fs/cifs - clean up 'set but not used' variables.
When building with W=1, fs/cifs throws a lot of 'set but not used' messages.
CC [M] fs/cifs/file.o
fs/cifs/file.c: In function 'cifs_lock':
fs/cifs/file.c:1698:8: warning: variable 'netfid' set but not used
[-Wunused-but-set-variable]
1698 | __u16 netfid;
|^~
fs/cifs/file.c:1696:24: warning: variable 'cinode' set but not used
[-Wunused-but-set-variable]
1696 | struct cifsInodeInfo *cinode;
|^~
fs/cifs/file.c: In function 'cifs_write':
fs/cifs/file.c:1767:23: warning: variable 'cifs_sb' set but not used
[-Wunused-but-set-variable]
1767 | struct cifs_sb_info *cifs_sb;
| ^~~
fs/cifs/file.c: In function 'collect_uncached_read_data':
fs/cifs/file.c:3580:20: warning: variable 'tcon' set but not used
[-Wunused-but-set-variable]
3580 | struct cifs_tcon *tcon;
|^~~~
CC [M] fs/cifs/netmisc.o
fs/cifs/netmisc.c:120:40: warning: 'mapping_table_ERRHRD' defined but not used
[-Wunused-const-variable=]
120 | static const struct smb_to_posix_error mapping_table_ERRHRD[] = {
|^~~~
CC [M] fs/cifs/smb2ops.o
fs/cifs/smb2ops.c: In function 'smb3_punch_hole':
fs/cifs/smb2ops.c:2942:24: warning: variable 'cifsi' set but not used
[-Wunused-but-set-variable]
2942 | struct cifsInodeInfo *cifsi;
|^
CC [M] fs/cifs/cifsacl.o
fs/cifs/cifsacl.c: In function 'sid_to_id':
fs/cifs/cifsacl.c:367:6: warning: variable 'rc' set but not used
[-Wunused-but-set-variable]
367 | int rc;
| ^~
At top level:
fs/cifs/cifsacl.c:89:30: warning: 'sid_unix_NFS_mode' defined but not used
[-Wunused-const-variable=]
89 | static const struct cifs_sid sid_unix_NFS_mode = { 1, 2, {0, 0, 0, 0,
0, 5},
| ^
fs/cifs/cifsacl.c:62:30: warning: 'sid_user' defined but not used
[-Wunused-const-variable=]
62 | static const struct cifs_sid sid_user = {1, 2 , {0, 0, 0, 0, 0, 5}, {}
};
| ^~~~
Heave the unused stuff over the side.
Signed-off-by: Valdis Kletnieks
diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
index 78eed72f3af0..bcd5eb301230 100644
--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -58,8 +58,6 @@ static const struct cifs_sid sid_everyone = {
/* security id for Authenticated Users system group */
static const struct cifs_sid sid_authusers = {
1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(11)} };
-/* group users */
-static const struct cifs_sid sid_user = {1, 2 , {0, 0, 0, 0, 0, 5}, {} };
/* S-1-22-1 Unmapped Unix users */
static const struct cifs_sid sid_unix_users = {1, 1, {0, 0, 0, 0, 0, 22},
@@ -85,11 +83,6 @@ static const struct cifs_sid sid_unix_NFS_groups = { 1, 2,
{0, 0, 0, 0, 0, 5},
{cpu_to_le32(88),
cpu_to_le32(2), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} };
-/* S-1-5-88-3 Unix mode */
-static const struct cifs_sid sid_unix_NFS_mode = { 1, 2, {0, 0, 0, 0, 0, 5},
- {cpu_to_le32(88),
-cpu_to_le32(3), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} };
-
static const struct cred *root_cred;
static int
@@ -364,7 +357,6 @@ static int
sid_to_id(struct cifs_sb_info *cifs_sb, struct cifs_sid *psid,
struct cifs_fattr *fattr, uint sidtype)
{
- int rc;
struct key *sidkey;
char *sidstr;
const struct cred *saved_cred;
@@ -426,7 +418,6 @@ sid_to_id(struct cifs_sb_info *cifs_sb, struct cifs_sid
*psid,
sidkey = request_key(_idmap_key_type, sidstr, "",
_idmap_key_acl);
if (IS_ERR(sidkey)) {
- rc = -EINVAL;
cifs_dbg(FYI, "%s: Can't map SID %s to a %cid\n",
__func__, sidstr, sidtype == SIDOWNER ? 'u' : 'g');
goto out_revert_creds;
@@ -439,7 +430,6 @@ sid_to_id(struct cifs_sb_info *cifs_sb, struct cifs_sid
*psid,
*/
BUILD_BUG_ON(sizeof(uid_t) != sizeof(gid_t));
if (sidkey->datalen != sizeof(uid_t)) {
- rc = -EIO;
cifs_dbg(FYI, "%s: Downcall contained malformed key
(datalen=%hu)\n",
__func__, sidkey->datalen);
key_invalidate(sidkey);
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 97090693d182..f16f6d2b5217 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1693,9 +1693,7 @@ int cifs_lock(struct file *file, int cmd, struct
file_lock *flock)
bool posix_lck = false;
struct cifs_sb_info *cifs_sb;
struct cifs_tcon *tcon;
- struct cifsInodeInfo *cinode;
struct cifsFileInfo *cfile;
- __u16 netfid;
__u32 type;
rc = -EACCES;
@@ -1711,8 +1709,6 @@ int cifs_lock(struct file *file, int cmd, struct
file_lock *flock)
cifs_read_flock(flock, , , , _flag,
tcon->ses->server);
cifs_sb = CIFS_FILE_SB(file);
- netfid = cfile->fid.netfid;
linux-next: manual merge of the bpf-next tree with Linus' tree
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/lib/bpf/libbpf.c
between commit:
1d4126c4e119 ("libbpf: sanitize VAR to conservative 1-byte INT")
from Linus' tree and commit:
b03bc6853c0e ("libbpf: convert libbpf code to use new btf helpers")
from the bpf-next 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 tools/lib/bpf/libbpf.c
index 2b57d7ea7836,3abf2dd1b3b5..
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@@ -1370,22 -1374,16 +1372,21 @@@ static void bpf_object__sanitize_btf(st
for (i = 1; i <= btf__get_nr_types(btf); i++) {
t = (struct btf_type *)btf__type_by_id(btf, i);
- kind = BTF_INFO_KIND(t->info);
- if (!has_datasec && kind == BTF_KIND_VAR) {
+ if (!has_datasec && btf_is_var(t)) {
/* replace VAR with INT */
t->info = BTF_INFO_ENC(BTF_KIND_INT, 0, 0);
- t->size = sizeof(int);
- *(int *)(t + 1) = BTF_INT_ENC(0, 0, 32);
+ /*
+ * using size = 1 is the safest choice, 4 will be too
+ * big and cause kernel BTF validation failure if
+ * original variable took less than 4 bytes
+ */
+ t->size = 1;
- *(int *)(t+1) = BTF_INT_ENC(0, 0, 8);
- } else if (!has_datasec && kind == BTF_KIND_DATASEC) {
++ *(int *)(t + 1) = BTF_INT_ENC(0, 0, 8);
+ } else if (!has_datasec && btf_is_datasec(t)) {
/* replace DATASEC with STRUCT */
- struct btf_var_secinfo *v = (void *)(t + 1);
- struct btf_member *m = (void *)(t + 1);
+ const struct btf_var_secinfo *v = btf_var_secinfos(t);
+ struct btf_member *m = btf_members(t);
struct btf_type *vt;
char *name;
pgpe8B4UKHkXa.pgp
Description: OpenPGP digital signature
Re: [PATCH] hugetlbfs: fix hugetlb page migration/fault race causing SIGBUS
On 8/7/19 7:24 PM, 裘稀石(稀石) wrote: > Hi Mike, > > Do you mean the similar race is like the following? > > migration clearing the pte > page fault(before we return error, and now we return 0, then try page fault > again, right?) > migration writing a migration entry Yes, something like the that. The change is to takes the page table lock to examine the pte before returning. If the pte is clear when examined while holding the lock, an error will be returned as before. If not clear, then we return zero and try again. This change adds code which is very much like this check further in the routine hugetlb_no_page(): ptl = huge_pte_lock(h, mm, ptep); size = i_size_read(mapping->host) >> huge_page_shift(h); if (idx >= size) goto backout; ret = 0; if (!huge_pte_none(huge_ptep_get(ptep))) goto backout; -- Mike Kravetz
Re: [PATCH v2 2/2] linux/bits.h: Add compile time sanity check of GENMASK inputs
Hi Rikard, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3-rc3 next-20190807] [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/Rikard-Falkeborn/linux-bits-h-Clarify-macro-argument-names/20190805-024030 config: i386-defconfig (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): In file included from include/linux/bits.h:22:0, from arch/x86/include/asm/msr-index.h:5, from arch/x86/boot/cpucheck.c:28: >> include/linux/build_bug.h:49:0: warning: "BUILD_BUG_ON" redefined #define BUILD_BUG_ON(condition) \ In file included from arch/x86/boot/cpucheck.c:22:0: arch/x86/boot/boot.h:31:0: note: this is the location of the previous definition #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) vim +/BUILD_BUG_ON +49 include/linux/build_bug.h bc6245e5efd70c Ian Abbott 2017-07-10 40 bc6245e5efd70c Ian Abbott 2017-07-10 41 /** bc6245e5efd70c Ian Abbott 2017-07-10 42 * BUILD_BUG_ON - break compile if a condition is true. bc6245e5efd70c Ian Abbott 2017-07-10 43 * @condition: the condition which the compiler should know is false. bc6245e5efd70c Ian Abbott 2017-07-10 44 * bc6245e5efd70c Ian Abbott 2017-07-10 45 * If you have some code which relies on certain constants being equal, or bc6245e5efd70c Ian Abbott 2017-07-10 46 * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to bc6245e5efd70c Ian Abbott 2017-07-10 47 * detect if someone changes it. bc6245e5efd70c Ian Abbott 2017-07-10 48 */ bc6245e5efd70c Ian Abbott 2017-07-10 @49 #define BUILD_BUG_ON(condition) \ bc6245e5efd70c Ian Abbott 2017-07-10 50BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) bc6245e5efd70c Ian Abbott 2017-07-10 51 :: The code at line 49 was first introduced by commit :: bc6245e5efd70c41eaf9334b1b5e646745cb0fb3 bug: split BUILD_BUG stuff out into :: TO: Ian Abbott :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 2/2] linux/bits.h: Add compile time sanity check of GENMASK inputs
Hi Rikard,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3-rc3 next-20190807]
[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/Rikard-Falkeborn/linux-bits-h-Clarify-macro-argument-names/20190805-024030
config: x86_64-randconfig-h003-201931 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/bits.h:22:0,
from include/linux/bitops.h:5,
from include/linux/kernel.h:12,
from include/linux/delay.h:22,
from drivers/iio/adc/max9611.c:20:
drivers/iio/adc/max9611.c: In function 'max9611_init':
include/linux/build_bug.h:16:45: error: negative width in bit-field
''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
>> include/linux/bits.h:24:18: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
^
>> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
(GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
^~~
>> drivers/iio/adc/max9611.c:86:28: note: in expansion of macro 'GENMASK'
#define MAX9611_TEMP_MASK GENMASK(7, 15)
^~~
>> drivers/iio/adc/max9611.c:483:17: note: in expansion of macro
>> 'MAX9611_TEMP_MASK'
regval = ret & MAX9611_TEMP_MASK;
^
--
In file included from include/linux/bits.h:22:0,
from include/linux/bitops.h:5,
from include/linux/kernel.h:12,
from include/linux/delay.h:22,
from drivers/iio//adc/max9611.c:20:
drivers/iio//adc/max9611.c: In function 'max9611_init':
include/linux/build_bug.h:16:45: error: negative width in bit-field
''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
>> include/linux/bits.h:24:18: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
^
>> include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
(GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
^~~
drivers/iio//adc/max9611.c:86:28: note: in expansion of macro 'GENMASK'
#define MAX9611_TEMP_MASK GENMASK(7, 15)
^~~
drivers/iio//adc/max9611.c:483:17: note: in expansion of macro
'MAX9611_TEMP_MASK'
regval = ret & MAX9611_TEMP_MASK;
^
vim +/BUILD_BUG_ON_ZERO +24 include/linux/bits.h
15
16 /*
17 * Create a contiguous bitmask starting at bit position @low and ending
at
18 * position @high. For example
19 * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
20 */
21 #ifndef __ASSEMBLY__
> 22 #include
23 #define GENMASK_INPUT_CHECK(high, low) \
> 24 ((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
25 __is_constexpr(high) && __is_constexpr(low), \
26 (low) > (high), UL(0
27 #else
28 /*
29 * BUILD_BUG_ON_ZERO and __is_constexpr() are not available in h files
30 * included from asm files, disable the input check if that is the case.
31 */
32 #define GENMASK_INPUT_CHECK(high, low) UL(0)
33 #endif
34
35 #define __GENMASK(high, low) \
36 (((~UL(0)) - (UL(1) << (low)) + 1) & \
37 (~UL(0) >> (BITS_PER_LONG - 1 - (high
38 #define GENMASK(high, low) \
> 39 (GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
40
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[rcu:dev.2019.07.31a 110/123] kernel/rcu/rcu_segcblist.c:61:6: sparse: sparse: symbol 'rcu_segcblist_set_len' was not declared. Should it be static?
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2019.07.31a head: 71cf692f482ff45802352cf85a8880035fca9e52 commit: ab2ef5c7b4d1933ee53a66d981cb67974de46815 [110/123] rcu/nocb: Atomic ->len field in rcu_segcblist structure reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty git checkout ab2ef5c7b4d1933ee53a66d981cb67974de46815 make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) kernel/rcu/rcu_segcblist.c:32:6: sparse: sparse: symbol 'rcu_cblist_enqueue' was not declared. Should it be static? >> kernel/rcu/rcu_segcblist.c:61:6: sparse: sparse: symbol >> 'rcu_segcblist_set_len' was not declared. Should it be static? >> kernel/rcu/rcu_segcblist.c:77:6: sparse: sparse: symbol >> 'rcu_segcblist_add_len' was not declared. Should it be static? kernel/rcu/rcu_segcblist.c:96:6: sparse: sparse: symbol 'rcu_segcblist_inc_len' was not declared. Should it be static? >> kernel/rcu/rcu_segcblist.c:107:6: sparse: sparse: symbol >> 'rcu_segcblist_xchg_len' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[RFC PATCH rcu] rcu/nocb: rcu_segcblist_set_len() can be static
Fixes: ab2ef5c7b4d1 ("rcu/nocb: Atomic ->len field in rcu_segcblist structure")
Signed-off-by: kbuild test robot
---
rcu_segcblist.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
index ff431cc830378..84bbffaaede83 100644
--- a/kernel/rcu/rcu_segcblist.c
+++ b/kernel/rcu/rcu_segcblist.c
@@ -58,7 +58,7 @@ struct rcu_head *rcu_cblist_dequeue(struct rcu_cblist *rclp)
}
/* Set the length of an rcu_segcblist structure. */
-void rcu_segcblist_set_len(struct rcu_segcblist *rsclp, long v)
+static void rcu_segcblist_set_len(struct rcu_segcblist *rsclp, long v)
{
#ifdef CONFIG_RCU_NOCB_CPU
atomic_long_set(>len, v);
@@ -74,7 +74,7 @@ void rcu_segcblist_set_len(struct rcu_segcblist *rsclp, long
v)
* This increase is fully ordered with respect to the callers accesses
* both before and after.
*/
-void rcu_segcblist_add_len(struct rcu_segcblist *rsclp, long v)
+static void rcu_segcblist_add_len(struct rcu_segcblist *rsclp, long v)
{
#ifdef CONFIG_RCU_NOCB_CPU
smp_mb__before_atomic(); /* Up to the caller! */
@@ -104,7 +104,7 @@ void rcu_segcblist_inc_len(struct rcu_segcblist *rsclp)
* with the actual number of callbacks on the structure. This exchange is
* fully ordered with respect to the callers accesses both before and after.
*/
-long rcu_segcblist_xchg_len(struct rcu_segcblist *rsclp, long v)
+static long rcu_segcblist_xchg_len(struct rcu_segcblist *rsclp, long v)
{
#ifdef CONFIG_RCU_NOCB_CPU
return atomic_long_xchg(>len, v);
Re: [PATCH] rtc: bd70528: fix link error
On 2019/7/9 13:25, Vaittinen, Matti wrote:
> Hello Arnd,
>
> (Added Randy who also sent a patch to fix this)
>
> On Mon, 2019-07-08 at 18:10 +0200, Arnd Bergmann wrote:
>> On Mon, Jul 8, 2019 at 3:24 PM Vaittinen, Matti
>> wrote:
>>
>>> On Mon, 2019-07-08 at 14:41 +0200, Arnd Bergmann wrote:
>>>> With CONFIG_BD70528_WATCHDOG=m, a built-in rtc driver cannot call
>>>> into the low-level functions that are part of the watchdog
>>>> module:
>>>>
>>>> drivers/rtc/rtc-bd70528.o: In function `bd70528_set_time':
>>>> rtc-bd70528.c:(.text+0x22c): undefined reference to
>>>> `bd70528_wdt_lock'
>>>> rtc-bd70528.c:(.text+0x2a8): undefined reference to
>>>> `bd70528_wdt_unlock'
>>>> drivers/rtc/rtc-bd70528.o: In function
>>>> `bd70528_set_rtc_based_timers':
>>>> rtc-bd70528.c:(.text+0x50c): undefined reference to
>>>> `bd70528_wdt_set'
>>>>
>>>> Add a Kconfig dependency on this driver, but still allow compile-
>>>> testing
>>>> without it.
>>>>
>>>> Fixes: 32a4a4ebf768 ("rtc: bd70528: Initial support for ROHM
>>>> bd70528
>>>> RTC")
>>>> Signed-off-by: Arnd Bergmann
>>>> ---
>>>> drivers/rtc/Kconfig | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>>>> index 3bfc04a86529..7b071cc74422 100644
>>>> --- a/drivers/rtc/Kconfig
>>>> +++ b/drivers/rtc/Kconfig
>>>> @@ -498,8 +498,10 @@ config RTC_DRV_M41T80_WDT
>>>> help
>>>> If you say Y here you will get support for the
>>>> watchdog timer in the ST M41T60 and M41T80 RTC chips
>>>> series.
>>>> +
>>>> config RTC_DRV_BD70528
>>>> tristate "ROHM BD70528 PMIC RTC"
>>>> + depends on BD70528_WATCHDOG || (COMPILE_TEST &&
>>>> !BD70528_WATCHDOG)
>>>
>>> I am not fan of this. There may well be use-cases where it is
>>> desirable
>>> to leave the watchdog out but still compile in the RTC. This is why
>>> we
>>> have static inline stubs in the header for cases where WDG is not
>>> compiled in. (RTC does not need to stop WDG if WDG driver is not
>>> included)
>>>
>>> Adding dependency from RTC to MFD for BD70528 should be done - this
>>> will avoid most of the issues (And there has been few patches sent
>>> for
>>> this already). But that's still not complete solution because
>>> configuring RTC and MFD to be built in-kernel and WDG as a module
>>> will
>>> cause errors again.
>>>
>>> Is there a way to force WDG in-kernel if RTC is in-kernel? (Or
>>> disallow configuring RTC in-kernel if WDG is a module - while still
>>> allow RTC to be built without WDG?
>>
>> We could make this
>>
>> depends on BD70528_WATCHDOG || !BD70528_WATCHDOG
>>
>> which would allow building with or without watchdog, even when not
>> compile-testing, but still disallow the combination of
>> .
>
> Thanks for teaching me Arnd! That is clever :) We need something like
>
> depends on MFD_ROHM_BD70528 && (BD70528_WATCHDOG || !BD70528_WATCHDOG)
>
> (I'm not sure if parenthesis are Ok and respected in Kconfig). I would
> never have thought of BD70528_WATCHDOG || !BD70528_WATCHDOG - it looks
> awkward at first sight but indeed - depends on BD70528_WATCHDOG
> disallows BD70528_WATCHDOG=m with RTC_DRV_BD70528=y while
> !BD70528_WATCHDOG allows BD70528_WATCHDOG=n. Brilliant and exactly what
> we need :) Thanks a bunch!
Hello Vaittinen,
the issue still exists in linux-next 20190807, any plan?
>
>>
>>Arnd
[PATCH 3.18.y 4.4.y 4.9.y] block: blk_init_allocated_queue() set q->fq as NULL in the fail case
From: xiao jin
commit 54648cf1ec2d7f4b6a71767799c45676a138ca24 upstream.
We find the memory use-after-free issue in __blk_drain_queue()
on the kernel 4.14. After read the latest kernel 4.18-rc6 we
think it has the same problem.
Memory is allocated for q->fq in the blk_init_allocated_queue().
If the elevator init function called with error return, it will
run into the fail case to free the q->fq.
Then the __blk_drain_queue() uses the same memory after the free
of the q->fq, it will lead to the unpredictable event.
The patch is to set q->fq as NULL in the fail case of
blk_init_allocated_queue().
Fixes: commit 7c94e1c157a2 ("block: introduce blk_flush_queue to drive flush
machinery")
Cc:
Reviewed-by: Ming Lei
Reviewed-by: Bart Van Assche
Signed-off-by: xiao jin
Signed-off-by: Jens Axboe
Signed-off-by: Alessio Balsini
---
block/blk-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index 50d77c90070d..7662f97dded6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -870,6 +870,7 @@ blk_init_allocated_queue(struct request_queue *q,
request_fn_proc *rfn,
fail:
blk_free_flush_queue(q->fq);
+ q->fq = NULL;
return NULL;
}
EXPORT_SYMBOL(blk_init_allocated_queue);
--
2.22.0.770.g0f2c4a37fd-goog
arch/arm/mach-ep93xx/crunch.c:46:3: warning: this statement may fall through
Hi Gustavo,
FYI, the error/warning still remains.
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ecb095bff5d4b8711a81968625b3b4a235d3e477
commit: a035d552a93bb9ef6048733bb9f2a0dc857ff869 Makefile: Globally enable
fall-through warning
date: 13 days ago
config: arm-ep93xx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a035d552a93bb9ef6048733bb9f2a0dc857ff869
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
arch/arm/mach-ep93xx/crunch.c: In function 'crunch_do':
>> arch/arm/mach-ep93xx/crunch.c:46:3: warning: this statement may fall through
>> [-Wimplicit-fallthrough=]
memset(crunch_state, 0, sizeof(*crunch_state));
^~
arch/arm/mach-ep93xx/crunch.c:53:2: note: here
case THREAD_NOTIFY_EXIT:
^~~~
vim +46 arch/arm/mach-ep93xx/crunch.c
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 35
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 36
static int crunch_do(struct notifier_block *self, unsigned long cmd, void *t)
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 37 {
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 38
struct thread_info *thread = (struct thread_info *)t;
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 39
struct crunch_state *crunch_state;
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 40
u32 devcfg;
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 41
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 42
crunch_state = >crunchstate;
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 43
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 44
switch (cmd) {
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 45
case THREAD_NOTIFY_FLUSH:
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 @46
memset(crunch_state, 0, sizeof(*crunch_state));
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 47
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 48
/*
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 49
* FALLTHROUGH: Ensure we don't try to overwrite our newly
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 50
* initialised state information on the first fault.
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 51
*/
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 52
797245f5da5430 arch/arm/kernel/crunch.c Russell King 2009-12-18 53
case THREAD_NOTIFY_EXIT:
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 54
crunch_task_release(thread);
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 55
break;
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 56
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 57
case THREAD_NOTIFY_SWITCH:
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 58
devcfg = __raw_readl(EP93XX_SYSCON_DEVCFG);
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 59
if (crunch_enabled(devcfg) || crunch_owner == crunch_state) {
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 60
/*
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 61
* We don't use ep93xx_syscon_swlocked_write() here
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 62
* because we are on the context switch path and
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 63
* preemption is already disabled.
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 64
*/
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 65
devcfg ^= EP93XX_SYSCON_DEVCFG_CPENA;
c17fad11f3105c arch/arm/kernel/crunch.c Lennert Buytenhek 2006-06-27 66
__raw_writel(0xaa, EP93XX_SYSCON_SWLOCK);
02239f0a426460 arch/arm/kernel/crunch.c Hartley Sweeten 2009-07-08 67
__raw_writel(devcfg, EP93XX_SYSCON_DEVCFG);
c17fad11f3105c arch/arm/kernel/crunch.c
[PATCH v2 2/3] HID: intel-ish-hid: ipc: make ish suspend paths clear
For suspend-to-idle, send suspend message and set N0_D3 flag to put
the ISH into D0i3 state.
For suspend-to-mem, disable the DMA bit before ISH entering D3, and
NO_D3 flag is cleared by default, then the ISH would enter D3.
Signed-off-by: Zhang Lixu
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 52 +++--
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 89b14d2edd0b..35081f2cf781 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -223,6 +223,8 @@ static void __maybe_unused ish_resume_handler(struct
work_struct *work)
* it means ISH isn't powered off, in this case, send a resume message.
*/
if (fwsts >= FWSTS_SENSOR_APP_LOADED) {
+ disable_irq_wake(pdev->irq);
+
ishtp_send_resume(dev);
/* Waiting to get resume response */
@@ -255,27 +257,36 @@ static int __maybe_unused ish_suspend(struct device
*device)
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
- enable_irq_wake(pdev->irq);
- /*
-* If previous suspend hasn't been asnwered then ISH is likely dead,
-* don't attempt nested notification
-*/
- if (dev->suspend_flag)
- return 0;
-
- dev->resume_flag = 0;
- dev->suspend_flag = 1;
- ishtp_send_suspend(dev);
-
- /* 25 ms should be enough for live ISH to flush all IPC buf */
- if (dev->suspend_flag)
- wait_event_interruptible_timeout(dev->suspend_wait,
-!dev->suspend_flag,
- msecs_to_jiffies(25));
-
if (ish_should_enter_d0i3(pdev)) {
- /* Set the NO_D3 flag, the ISH would enter D0i3 */
- pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
+ /*
+* If previous suspend hasn't been asnwered then ISH is likely
+* dead, don't attempt nested notification
+*/
+ if (dev->suspend_flag)
+ return 0;
+
+ dev->resume_flag = 0;
+ dev->suspend_flag = 1;
+ ishtp_send_suspend(dev);
+
+ /* 25 ms should be enough for live ISH to flush all IPC buf */
+ if (dev->suspend_flag)
+ wait_event_interruptible_timeout(dev->suspend_wait,
+ !dev->suspend_flag,
+ msecs_to_jiffies(25));
+
+ if (dev->suspend_flag) {
+ /*
+* It looks like FW halt, clear the DMA bit, and put
+* ISH into D3, and FW would reset on resume.
+*/
+ ish_disable_dma(dev);
+ } else {
+ /* Set the NO_D3 flag, the ISH would enter D0i3 */
+ pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
+
+ enable_irq_wake(pdev->irq);
+ }
} else {
/*
* Clear the DMA bit before putting ISH into D3,
@@ -304,7 +315,6 @@ static int __maybe_unused ish_resume(struct device *device)
ish_resume_device = device;
dev->resume_flag = 1;
- disable_irq_wake(pdev->irq);
schedule_work(_work);
return 0;
--
2.17.1
[PATCH v2 1/3] HID: intel-ish-hid: ipc: set NO_D3 flag only when needed
Currently, the NO_D3 flag is set in ish_probe(), and cleared in
ish_remove(). So even if the system goes into S3, ISH is still
in D0i3 state. It makes more sense that put ISH into D3 as system
goes into S3 and put ISH into D0i3 as system goes into suspend-to-idle.
I remove the NO_D3 setting in ish_probe(), so that ISH can enter
D3 state when system enters S3. Only set N0_D3 flag when system
enters the suspend-to-idle or platform specified, and clear it
when system resume.
When the ISH enters D3, the FW will check the DMA bit status.
If the DMA bit is set, the FW will reset automatically. So the
DMA bit need be clear before putting ISH into D3 state.
Signed-off-by: Zhang Lixu
---
drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +-
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 21 +++--
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
index 1065692f90e2..ddd8e8e87cfa 100644
--- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
+++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
@@ -77,5 +77,6 @@ irqreturn_t ish_irq_handler(int irq, void *dev_id);
struct ishtp_device *ish_dev_init(struct pci_dev *pdev);
int ish_hw_start(struct ishtp_device *dev);
void ish_device_disable(struct ishtp_device *dev);
+int ish_disable_dma(struct ishtp_device *dev);
#endif /* _ISHTP_HW_ISH_H_ */
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c
b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 18fe8af89aad..8f8dfdf64833 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -672,7 +672,7 @@ irqreturn_t ish_irq_handler(int irq, void *dev_id)
*
* Return: 0 for success else error code.
*/
-static int ish_disable_dma(struct ishtp_device *dev)
+int ish_disable_dma(struct ishtp_device *dev)
{
unsigned intdma_delay;
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index aa80b4d3b740..89b14d2edd0b 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#define CREATE_TRACE_POINTS
@@ -97,6 +98,11 @@ static const struct pci_device_id ish_invalid_pci_ids[] = {
{}
};
+static inline bool ish_should_enter_d0i3(struct pci_dev *pdev)
+{
+ return !pm_suspend_via_firmware() || pdev->device == CHV_DEVICE_ID;
+}
+
/**
* ish_probe() - PCI driver probe callback
* @pdev: pci device
@@ -147,7 +153,6 @@ static int ish_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* mapping IO device memory */
hw->mem_addr = pcim_iomap_table(pdev)[0];
ishtp->pdev = pdev;
- pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
/* request and enable interrupt */
ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
@@ -184,7 +189,6 @@ static void ish_remove(struct pci_dev *pdev)
struct ishtp_device *ishtp_dev = pci_get_drvdata(pdev);
ishtp_bus_remove_all_clients(ishtp_dev, false);
- pdev->dev_flags &= ~PCI_DEV_FLAGS_NO_D3;
ish_device_disable(ishtp_dev);
}
@@ -209,6 +213,8 @@ static void __maybe_unused ish_resume_handler(struct
work_struct *work)
uint32_t fwsts;
int ret;
+ pdev->dev_flags &= ~PCI_DEV_FLAGS_NO_D3;
+
/* Get ISH FW status */
fwsts = IPC_GET_ISH_FWSTS(dev->ops->get_fw_status(dev));
@@ -267,6 +273,17 @@ static int __maybe_unused ish_suspend(struct device
*device)
!dev->suspend_flag,
msecs_to_jiffies(25));
+ if (ish_should_enter_d0i3(pdev)) {
+ /* Set the NO_D3 flag, the ISH would enter D0i3 */
+ pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
+ } else {
+ /*
+* Clear the DMA bit before putting ISH into D3,
+* or ISH FW would reset automatically.
+*/
+ ish_disable_dma(dev);
+ }
+
return 0;
}
--
2.17.1
[PATCH v2 0/3] HID: intel-ish-hid: support s2idle and s3 in ish_suspend()
Currently, the NO_D3 flag is set in ish_probe(), the intel-ish-ipc driver puts the ISH into D0i3 when system enter both suspend-to-idle(S0ix) and suspend-to-mem(S3). These patches are to put the ISH into D3 when system enter S3 and put the ISH into D0i3 when system enter S0ix. I tested these patches on the following platforms: ISH 5.2: ICL ISH 5.0: CNL CFL WHL CML ISH 4.0: GLK ISH 3.0: KBL Test steps: * Run the IIO Sensor tool to read the accel_3d sensor data * Run cmd "echo mem > /sys/power/state" to suspend-to-mem * Press the keyboard to wake up OS. * Check if the tool can get the sensor data after OS resume. * Run cmd "echo freeze > /sys/power/state" to suspend-to-idle * Press the keyboard to wake up OS. * Check if the tool can get the sensor data after OS resume. Test results: The tool can get the accel_3d sensor data after resuming from both suspend-to-mem and suspend-to-idle. Changes from v1: * Fix the indentation issue * Elaborate the reason to remove the NO_D3 flag * Split the PATCH v1 to three changes, and try to minimize the lines change Zhang Lixu (3): HID: intel-ish-hid: ipc: set NO_D3 flag only when needed HID: intel-ish-hid: ipc: make ish suspend paths clear HID: intel-ish-hid: ipc: check the NO_D3 flag to distinguish resume paths drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 + drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +- drivers/hid/intel-ish-hid/ipc/pci-ish.c | 95 +++-- 3 files changed, 61 insertions(+), 37 deletions(-) -- 2.17.1
[PATCH v2 3/3] HID: intel-ish-hid: ipc: check the NO_D3 flag to distinguish resume paths
The NO_D3 flag would be set if the ISH enter D0i3 in ish_suspend(),
The resume paths can be distinguished by checking the NO_D3 flag.
It's more reasonable than checking the FW status.
Signed-off-by: Zhang Lixu
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 34 +++--
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 35081f2cf781..f269852304e5 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -210,19 +210,11 @@ static void __maybe_unused ish_resume_handler(struct
work_struct *work)
{
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
- uint32_t fwsts;
int ret;
- pdev->dev_flags &= ~PCI_DEV_FLAGS_NO_D3;
-
- /* Get ISH FW status */
- fwsts = IPC_GET_ISH_FWSTS(dev->ops->get_fw_status(dev));
-
- /*
-* If currently, in ISH FW, sensor app is loaded or beyond that,
-* it means ISH isn't powered off, in this case, send a resume message.
-*/
- if (fwsts >= FWSTS_SENSOR_APP_LOADED) {
+ /* Check the NO_D3 flag to distinguish the resume paths */
+ if (pdev->dev_flags & PCI_DEV_FLAGS_NO_D3) {
+ pdev->dev_flags &= ~PCI_DEV_FLAGS_NO_D3;
disable_irq_wake(pdev->irq);
ishtp_send_resume(dev);
@@ -232,16 +224,20 @@ static void __maybe_unused ish_resume_handler(struct
work_struct *work)
ret = wait_event_interruptible_timeout(dev->resume_wait,
!dev->resume_flag,
msecs_to_jiffies(WAIT_FOR_RESUME_ACK_MS));
- }
- /*
-* If in ISH FW, sensor app isn't loaded yet, or no resume response.
-* That means this platform is not S0ix compatible, or something is
-* wrong with ISH FW. So on resume, full reboot of ISH processor will
-* happen, so need to go through init sequence again.
-*/
- if (dev->resume_flag)
+ /*
+* If the flag is not cleared, something is wrong with ISH FW.
+* So on resume, need to go through init sequence again.
+*/
+ if (dev->resume_flag)
+ ish_init(dev);
+ } else {
+ /*
+* Resume from the D3, full reboot of ISH processor will happen,
+* so need to go through init sequence again.
+*/
ish_init(dev);
+ }
}
/**
--
2.17.1
Re: [PATCH] scsi: pm80xx: remove redundant assignments to variable rc
Colin, > There are several occasions where variable rc is being initialized > with a value that is never read and error is being re-assigned a > little later on. Clean up the code by removing rc entirely and > just returning the return value from the call to pm8001_issue_ssp_tmf Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 00/15] hisi_sas: Misc patches
John, > This patchset incldues a set of misc changes for the driver. > > Nothing particularly stands out. Here's a quick overview: > - minor optimisation in delivery path > - some debugfs fixes and new minor features > - some other very minor optimisations > - and generally the rest are tidy-up patches Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v9 0/7] Solve postboot supplier cleanup and optimize probe ordering
Hi Greg, Saravana, On 8/1/19 11:37 PM, Greg Kroah-Hartman wrote: > On Thu, Aug 01, 2019 at 12:59:25PM -0700, Frank Rowand wrote: >> On 8/1/19 12:32 PM, Greg Kroah-Hartman wrote: >>> On Thu, Aug 01, 2019 at 12:28:13PM -0700, Frank Rowand wrote: Hi Greg, On 7/31/19 11:12 PM, Greg Kroah-Hartman wrote: > On Wed, Jul 31, 2019 at 03:17:13PM -0700, Saravana Kannan wrote: >> Add device-links to track functional dependencies between devices >> after they are created (but before they are probed) by looking at >> their common DT bindings like clocks, interconnects, etc. >> >> Having functional dependencies automatically added before the devices >> are probed, provides the following benefits: >> >> - Optimizes device probe order and avoids the useless work of >> attempting probes of devices that will not probe successfully >> (because their suppliers aren't present or haven't probed yet). >> >> For example, in a commonly available mobile SoC, registering just >> one consumer device's driver at an initcall level earlier than the >> supplier device's driver causes 11 failed probe attempts before the >> consumer device probes successfully. This was with a kernel with all >> the drivers statically compiled in. This problem gets a lot worse if >> all the drivers are loaded as modules without direct symbol >> dependencies. >> >> - Supplier devices like clock providers, interconnect providers, etc >> need to keep the resources they provide active and at a particular >> state(s) during boot up even if their current set of consumers don't >> request the resource to be active. This is because the rest of the >> consumers might not have probed yet and turning off the resource >> before all the consumers have probed could lead to a hang or >> undesired user experience. >> >> Some frameworks (Eg: regulator) handle this today by turning off >> "unused" resources at late_initcall_sync and hoping all the devices >> have probed by then. This is not a valid assumption for systems with >> loadable modules. Other frameworks (Eg: clock) just don't handle >> this due to the lack of a clear signal for when they can turn off >> resources. This leads to downstream hacks to handle cases like this >> that can easily be solved in the upstream kernel. >> >> By linking devices before they are probed, we give suppliers a clear >> count of the number of dependent consumers. Once all of the >> consumers are active, the suppliers can turn off the unused >> resources without making assumptions about the number of consumers. >> >> By default we just add device-links to track "driver presence" (probe >> succeeded) of the supplier device. If any other functionality provided >> by device-links are needed, it is left to the consumer/supplier >> devices to change the link when they probe. > > All now queued up in my driver-core-testing branch, and if 0-day is > happy with this, will move it to my "real" driver-core-next branch in a > day or so to get included in linux-next. I have been slow in getting my review out. This patch series is not yet ready for sending to Linus, so if putting this in linux-next implies that it will be in your next pull request to Linus, please do not put it in linux-next. >>> >>> It means that it will be in my pull request for 5.4-rc1, many many >>> waeeks away from now. >> >> If you are willing to revert the series before the pull request _if_ I >> have significant review issues in the next couple of days, then I am happy >> to see the patches get exposure in linux-next. > > If you have significant review issues, yes, I will be glad to revert them. Just a heads up that I have sent review issues in reply to version 7 of this patch series. We'll see what the responses are to my review comments, but I am expecting the changes are big enough to result in a new version (or a couple more versions) of the patch series. No rush to revert version 9 since your 5.4-rc1 pull request is still not near, and I am glad for whatever exposure these patches are getting in linux-next. Thanks, Frank > > thanks, > > greg k-h >
Re: [PATCH v2] Fix non-kerneldoc comment in realtek/rtlwifi/usb.c
On 8/7/19 8:51 PM, Valdis Klētnieks wrote:
Fix spurious warning message when building with W=1:
CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o
drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand *
on line 243 - I thought it was a doc line
drivers/net/wireless/realtek/rtlwifi/usb.c:760: warning: Cannot understand *
on line 760 - I thought it was a doc line
drivers/net/wireless/realtek/rtlwifi/usb.c:790: warning: Cannot understand *
on line 790 - I thought it was a doc line
Clean up the comment format.
Signed-off-by: Valdis Kletnieks
---
Changes since v1: Larry Finger pointed out the patch wasn't checkpatch-clean.
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 34d68dbf4b4c..4b59f3b46b28 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -239,10 +239,7 @@ static void _rtl_usb_io_handler_release(struct
ieee80211_hw *hw)
mutex_destroy(>io.bb_mutex);
}
-/**
- *
- * Default aggregation handler. Do nothing and just return the oldest skb.
- */
+/* Default aggregation handler. Do nothing and just return the oldest skb.
*/
static struct sk_buff *_none_usb_tx_aggregate_hdl(struct ieee80211_hw *hw,
struct sk_buff_head *list)
{
@@ -756,11 +753,6 @@ static int rtl_usb_start(struct ieee80211_hw *hw)
return err;
}
-/**
- *
- *
- */
-
/*=== tx =*/
static void rtl_usb_cleanup(struct ieee80211_hw *hw)
{
@@ -786,11 +778,7 @@ static void rtl_usb_cleanup(struct ieee80211_hw *hw)
usb_kill_anchored_urbs(>tx_submitted);
}
-/**
- *
- * We may add some struct into struct rtl_usb later. Do deinit here.
- *
- */
+/* We may add some struct into struct rtl_usb later. Do deinit here. */
static void rtl_usb_deinit(struct ieee80211_hw *hw)
{
rtl_usb_cleanup(hw);
I missed that the subject line should be "rtwifi: Fix ". Otherwise it is OK.
Larry
Re: [PATCH v7 2/7] driver core: Add edit_links() callback for drivers
> Date: Tue, 23 Jul 2019 17:10:55 -0700
> Subject: [PATCH v7 2/7] driver core: Add edit_links() callback for drivers
> From: Saravana Kannan
>
> The driver core/bus adding supplier-consumer dependencies by default
> enables functional dependencies to be tracked correctly even when the
> consumer devices haven't had their drivers registered or loaded (if they
> are modules).
enables functional dependencies to be tracked correctly before the
consumer device drivers are registered or loaded (if they are modules).
>
> However, when the bus incorrectly adds dependencies that it shouldn't
^^^ driver core/bus
> have added, the devices might never probe.
Explain what causes a dependency to be incorrectly added.
Is this a bug in the dependency detection code?
Are there cases where the dependency detection code can not reliably determine
whether there truly is a dependency?
>
> For example, if device-C is a consumer of device-S and they have
> phandles to each other in DT, the following could happen:
>
> 1. Device-S get added first.
> 2. The bus add_links() callback will (incorrectly) try to link it as
> a consumer of device-C.
> 3. Since device-C isn't present, device-S will be put in
> "waiting-for-supplier" list.
> 4. Device-C gets added next.
> 5. All devices in "waiting-for-supplier" list are retried for linking.
> 6. Device-S gets linked as consumer to Device-C.
> 7. The bus add_links() callback will (correctly) try to link it as
> a consumer of device-S.
> 8. This isn't allowed because it would create a cyclic device links.
>
> Neither devices will get probed since the supplier is marked as
> dependent on the consumer. And the consumer will never probe because the
> consumer can't get resources from the supplier.
>
> Without this patch, things stay in this broken state. However, with this
> patch, the execution will continue like this:
>
> 9. Device-C's driver is loaded.
Change comment to:
For example, if device-C is a consumer of device-S and they have phandles
referencing each other in the devicetree, the following could happen:
1. Device-S is added first.
- The bus add_links() callback will (incorrectly) link device-S
as a consumer of device-C, and device-S will be put in the
"wait_for_suppliers" list.
2. Device-C is added next.
- All devices in the "wait_for_suppliers" list are retried for linking.
- Device-S remains linked as a consumer to device-C.
- The bus add_links() callback will (correctly) try to link device-C as
a consumer of device-S.
- The link attempt will fail because it would create a cyclic device
link, and device-C will be put in the "wait_for_suppliers" list.
Device-S will not be probed because it is in the "wait_for_suppliers" list.
Device-C will not be probed because it is in the "wait_for_suppliers" list.
>
> Without this patch, things stay in this broken state. However, with this
> patch, the execution will continue like this:
>
> 9. Device-C's driver is loaded.
What is "loaded"? Does that mean the device-C probe succeeds?
What causes device-C to be probed? The normal processing of -EPROBE_DEFER
devices?
> 10. Device-C's driver removes Device-S as a consumer of Device-C.
> 11. Device-C's driver adds Device-C as a consumer of Device-S.
> 12. Device-S probes.
> 14. Device-C probes.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/base/core.c| 24 ++--
> drivers/base/dd.c | 29 +
> include/linux/device.h | 18 ++
> 3 files changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 1b4eb221968f..733d8a9aec76 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -422,6 +422,19 @@ static void device_link_wait_for_supplier(struct device
> *consumer)
> mutex_unlock(_lock);
> }
>
> +/**
> + * device_link_remove_from_wfs - Unmark device as waiting for supplier
> + * @consumer: Consumer device
> + *
> + * Unmark the consumer device as waiting for suppliers to become available.
> + */
> +void device_link_remove_from_wfs(struct device *consumer)
Misleading function name.
Incorrect description.
Does not remove consumer from list wait_for_suppliers.
At best, consumer might eventually get removed from list wait_for_suppliers
if device_link_check_waiting_consumers() is called again.
> +{
> + mutex_lock(_lock);
> + list_del_init(>links.needs_suppliers);
> + mutex_unlock(_lock);
> +}
> +
> /**
> * device_link_check_waiting_consumers - Try to unmark waiting consumers
> *
> @@ -439,12 +452,19 @@ static void device_link_wait_for_supplier(struct device
> *consumer)
> static void device_link_check_waiting_consumers(void)
> {
> struct device *dev, *tmp;
> + int ret;
>
> mutex_lock(_lock);
> list_for_each_entry_safe(dev, tmp,
Re: [PATCH v7 1/7] driver core: Add support for linking devices during device addition
> Date: Tue, 23 Jul 2019 17:10:54 -0700
> Subject: [PATCH v7 1/7] driver core: Add support for linking devices during
> device addition
> From: Saravana Kannan
>
> When devices are added, the bus might want to create device links to track
> functional dependencies between supplier and consumer devices. This
> tracking of supplier-consumer relationship allows optimizing device probe
> order and tracking whether all consumers of a supplier are active. The
> add_links bus callback is added to support this.
Change above to:
When devices are added, the bus may create device links to track which
suppliers a consumer device depends upon. This
tracking of supplier-consumer relationship may be used to defer probing
the driver of a consumer device before the driver(s) for its supplier device(s)
are probed. It may also be used by a supplier driver to determine if
all of its consumers have been successfully probed.
The add_links bus callback is added to create the supplier device links
>
> However, when consumer devices are added, they might not have a supplier
> device to link to despite needing mandatory resources/functionality from
> one or more suppliers. A waiting_for_suppliers list is created to track
> such consumers and retry linking them when new devices get added.
Change above to:
If a supplier device has not yet been created when the consumer device attempts
to link it, the consumer device is added to the wait_for_suppliers list.
When supplier devices are created, the supplier device link will be added to
the relevant consumer devices on the wait_for_suppliers list.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/base/core.c| 83 ++
> include/linux/device.h | 14 +++
> 2 files changed, 97 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index da84a73f2ba6..1b4eb221968f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -44,6 +44,8 @@ early_param("sysfs.deprecated", sysfs_deprecated_setup);
> #endif
>
> /* Device links support. */
> +static LIST_HEAD(wait_for_suppliers);
> +static DEFINE_MUTEX(wfs_lock);
>
> #ifdef CONFIG_SRCU
> static DEFINE_MUTEX(device_links_lock);
> @@ -401,6 +403,51 @@ struct device_link *device_link_add(struct device
> *consumer,
> }
> EXPORT_SYMBOL_GPL(device_link_add);
>
> +/**
> + * device_link_wait_for_supplier - Mark device as waiting for supplier
* device_link_wait_for_supplier - Add device to wait_for_suppliers list
> + * @consumer: Consumer device
> + *
> + * Marks the consumer device as waiting for suppliers to become available.
> The
> + * consumer device will never be probed until it's unmarked as waiting for
> + * suppliers. The caller is responsible for adding the link to the supplier
> + * once the supplier device is present.
> + *
> + * This function is NOT meant to be called from the probe function of the
> + * consumer but rather from code that creates/adds the consumer device.
> + */
> +static void device_link_wait_for_supplier(struct device *consumer)
> +{
> + mutex_lock(_lock);
> + list_add_tail(>links.needs_suppliers, _for_suppliers);
> + mutex_unlock(_lock);
> +}
> +
> +/**
> + * device_link_check_waiting_consumers - Try to remove from supplier wait
> list
> + *
> + * Loops through all consumers waiting on suppliers and tries to add all
> their
> + * supplier links. If that succeeds, the consumer device is unmarked as
> waiting
> + * for suppliers. Otherwise, they are left marked as waiting on suppliers,
> + *
> + * The add_links bus callback is expected to return 0 if it has found and
> added
> + * all the supplier links for the consumer device. It should return an error
> if
> + * it isn't able to do so.
> + *
> + * The caller of device_link_wait_for_supplier() is expected to call this
> once
> + * it's aware of potential suppliers becoming available.
Change above comment to:
* device_link_add_supplier_links - add links from consumer devices to
* supplier devices, leaving any consumer
* with inactive suppliers on the
* wait_for_suppliers list
* Scan all consumer devices in the devicetree. For any supplier device that
* is not already linked to the consumer device, add the supplier to the
* consumer device's device links.
*
* If all of a consumer device's suppliers are available then the consumer
* is removed from the wait_for_suppliers list (if previously on the list).
* Otherwise the consumer is added to the wait_for_suppliers list (if not
* already on the list).
* The add_links bus callback must return 0 if it has found and added all
* the supplier links for the consumer device. It must return an error if
* it is not able to do so.
*
* The caller of device_link_wait_for_supplier() is expected to call this
once
* it is aware of
Re: [PATCH v7 0/7] Solve postboot supplier cleanup and optimize probe ordering
Hi Saravana, On 7/23/19 5:10 PM, Saravana Kannan wrote: > Add device-links to track functional dependencies between devices > after they are created (but before they are probed) by looking at > their common DT bindings like clocks, interconnects, etc. > < snip > I know that this series has moved on to versions 8 and 9. And some additional patches submitted. Version 8 was a rebase to handle device_link changes. The version 8 patch 0/7 description of the changes did not note any functional changes, so I am assuming that my comments on version 7 are still applicable. The version 9 changes do not impact my comments. I am sending review comments on patches 1, 2, and 3. I will continue review of patches later in the series when the fall out from these review comments result in a new series. -Frank
[PATCH] regulator: act8865: Fix build error without CONFIG_POWER_SUPPLY
Building without CONFIG_POWER_SUPPLY will fail:
drivers/regulator/act8865-regulator.o: In function `act8865_pmic_probe':
act8865-regulator.c:(.text+0x357): undefined reference to
`devm_power_supply_register'
drivers/regulator/act8865-regulator.o: In function
`act8600_charger_get_property':
act8865-regulator.c:(.text+0x3f1): undefined reference to
`power_supply_get_drvdata'
Add POWER_SUPPLY dependency to Kconfig.
Reported-by: Hulk Robot
Fixes: 2d09a79bf637 ("regulator: act8865: Add support for act8600 charger")
Signed-off-by: YueHaibing
---
drivers/regulator/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index b57093d..37e6488 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -83,6 +83,7 @@ config REGULATOR_88PM8607
config REGULATOR_ACT8865
tristate "Active-semi act8865 voltage regulator"
depends on I2C
+ depends on POWER_SUPPLY
select REGMAP_I2C
help
This driver controls a active-semi act8865 voltage output
--
2.7.4
Re: [PATCH v2 1/1] ixgbe: sync the first fragment unconditionally
On 8/7/19 4:38 PM, Firo Yang wrote:
The 08/07/2019 15:56, Jacob Wen wrote:
I think the description is not correct. Consider using something like below.
Thank you for comments.
In Xen environment, due to memory fragmentation ixgbe may allocate a 'DMA'
buffer with pages that are not physically contiguous.
Actually, I didn't look into the reason why ixgbe got a DMA buffer which
was mapped to Xen-swiotlb area.
Yes. I was wrong. You don't need to tell the exact reason.
But I don't think this issue relates to phsical memory contiguity because, in
our case, one ixgbe_rx_buffer only associates at most one page.
This is interesting.
I guess the performance of the NIC in your environment is not good due
to the extra cost of bounce buffer.
If you take a look at the related code, you will find there are several reasons
for mapping a DMA buffer to Xen-swiotlb area:
static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
*/
if (dma_capable(dev, dev_addr, size) &&
!range_straddles_page_boundary(phys, size) &&
!xen_arch_need_swiotlb(dev, phys, dev_addr) &&
swiotlb_force != SWIOTLB_FORCE)
goto done;
// Firo
A NIC doesn't support directly write such buffer. So xen-swiotlb would use
the pages, which are physically contiguous, from the swiotlb buffer for the
NIC.
The unmap operation is used to copy the swiotlb buffer to the pages that are
allocated by ixgbe.
On 8/7/19 10:49 AM, Firo Yang wrote:
In Xen environment, if Xen-swiotlb is enabled, ixgbe driver
could possibly allocate a page, DMA memory buffer, for the first
fragment which is not suitable for Xen-swiotlb to do DMA operations.
Xen-swiotlb have to internally allocate another page for doing DMA
operations. It requires syncing between those two pages. However,
since commit f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path"), the unmap operation is performed with
DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed.
To fix this problem, always sync before possibly performing a page
unmap operation.
Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA
attributes in Rx path")
Reviewed-by: Alexander Duyck
Signed-off-by: Firo Yang
---
Changes from v1:
* Imporved the patch description.
* Added Reviewed-by: and Fixes: as suggested by Alexander Duyck
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712d6529..200de9838096 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1825,13 +1825,7 @@ static void ixgbe_pull_tail(struct ixgbe_ring *rx_ring,
static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring,
struct sk_buff *skb)
{
- /* if the page was released unmap it, else just sync our portion */
- if (unlikely(IXGBE_CB(skb)->page_released)) {
- dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
-ixgbe_rx_pg_size(rx_ring),
-DMA_FROM_DEVICE,
-IXGBE_RX_DMA_ATTR);
- } else if (ring_uses_build_skb(rx_ring)) {
+ if (ring_uses_build_skb(rx_ring)) {
unsigned long offset = (unsigned long)(skb->data) & ~PAGE_MASK;
dma_sync_single_range_for_cpu(rx_ring->dev,
@@ -1848,6 +1842,14 @@ static void ixgbe_dma_sync_frag(struct ixgbe_ring
*rx_ring,
skb_frag_size(frag),
DMA_FROM_DEVICE);
}
+
+ /* If the page was released, just unmap it. */
+ if (unlikely(IXGBE_CB(skb)->page_released)) {
+ dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma,
+ixgbe_rx_pg_size(rx_ring),
+DMA_FROM_DEVICE,
+IXGBE_RX_DMA_ATTR);
+ }
}
/**
Re: [Intel-wired-lan] [PATCH v2 1/1] ixgbe: sync the first fragment unconditionally
The 08/07/2019 09:06, Alexander Duyck wrote: > On Wed, Aug 7, 2019 at 7:09 AM Maciej Fijalkowski > wrote: > > > > On Wed, 7 Aug 2019 08:38:43 + > > Firo Yang wrote: > > > > > The 08/07/2019 15:56, Jacob Wen wrote: > > > > I think the description is not correct. Consider using something like > > > > below. > > > Thank you for comments. > > > > > > > > > > > In Xen environment, due to memory fragmentation ixgbe may allocate a > > > > 'DMA' > > > > buffer with pages that are not physically contiguous. > > > Actually, I didn't look into the reason why ixgbe got a DMA buffer which > > > was mapped to Xen-swiotlb area. > > > > I think that neither of these descriptions are telling us what was truly > > broken. They lack what Alexander wrote on v1 thread of this patch. > > > > ixgbe_dma_sync_frag is called only on case when the current descriptor has > > EOP > > bit set, skb was already allocated and you'll be adding a current buffer as > > a > > frag. DMA unmapping for the first frag was intentionally skipped and we > > will be > > unmapping it here, in ixgbe_dma_sync_frag. As Alex said, we're using the > > DMA_ATTR_SKIP_CPU_SYNC attribute which obliges us to perform a sync manually > > and it was missing. > > > > So IMHO the commit description should include descriptions from both xen and > > ixgbe worlds, the v2 lacks info about ixgbe case. Thank you. Will submit v3 with what Alexander worte on v1. Thanks, Firo > > > > BTW Alex, what was the initial reason for holding off with unmapping the > > first > > buffer? Asking because IIRC the i40e and ice behave a bit different here. We > > don't look there for EOP at all when building/constructing skb and not > > delaying > > the unmap of non-eop buffers. > > > > Thanks, > > Maciej > > The reason why we have to hold off on unmapping the first buffer is > because in the case of Receive Side Coalescing (RSC), also known as Large > Receive Offload (LRO), the header of the packet is updated for each > additional frame that is added. As such you can end up with the device > writing data, header, data, header, data, header where each data write > would update a new descriptor, but the header will only ever update the > first descriptor in the chain. As such if we unmapped it earlier it would > result in an IOMMU fault because the device would be rewriting the header > after it had been unmapped. > > The devices supported by the ixgbe driver are the only ones that have > RSC/LRO support. As such this behavior is present for ixgbe, but not for > other Intel NIC drivers including igb, igbvf, ixgbevf, i40e, etc. > > - Alex >
Re: [PATCH] Fix non-kerneldoc comment in realtek/rtlwifi/usb.c
On 8/7/19 3:39 PM, Valdis Klētnieks wrote: > Fix spurious warning message when building with W=1: > > CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o > drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand * > on line 243 - I thought it was a doc line > drivers/net/wireless/realtek/rtlwifi/usb.c:760: warning: Cannot understand * > on line 760 - I thought it was a doc line > drivers/net/wireless/realtek/rtlwifi/usb.c:790: warning: Cannot understand * > on line 790 - I thought it was a doc line > > Change the comment so gcc doesn't think it's a kerneldoc comment block s:gcc:scripts/kernel-doc/ and as Larry pointed out, networking comment style is "different" from the rest of the kernel. :( > > Signed-off-by: Valdis Kletnieks > > diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c > b/drivers/net/wireless/realtek/rtlwifi/usb.c > index e24fda5e9087..9478cc0d4f8b 100644 > --- a/drivers/net/wireless/realtek/rtlwifi/usb.c > +++ b/drivers/net/wireless/realtek/rtlwifi/usb.c > @@ -239,7 +239,7 @@ static void _rtl_usb_io_handler_release(struct > ieee80211_hw *hw) > mutex_destroy(>io.bb_mutex); > } > > -/** > +/* > * > * Default aggregation handler. Do nothing and just return the oldest skb. > */ > @@ -756,7 +756,7 @@ static int rtl_usb_start(struct ieee80211_hw *hw) > return err; > } > > -/** > +/* > * > * > */ > @@ -786,7 +786,7 @@ static void rtl_usb_cleanup(struct ieee80211_hw *hw) > usb_kill_anchored_urbs(>tx_submitted); > } > > -/** > +/* > * > * We may add some struct into struct rtl_usb later. Do deinit here. > * > -- ~Randy
Re: [PATCH v2 2/2] linux/bits.h: Add compile time sanity check of GENMASK inputs
On 8/7/19 6:08 PM, Joe Perches wrote: On Wed, 2019-08-07 at 17:58 -0700, Guenter Roeck wrote: On 8/7/19 5:07 PM, Joe Perches wrote: On Wed, 2019-08-07 at 23:55 +0900, Masahiro Yamada wrote: On Wed, Aug 7, 2019 at 11:27 PM Guenter Roeck wrote: [] Who is going to fix the fallout ? For example, arm64:defconfig no longer compiles with this patch applied. It seems to me that the benefit of catching misuses of GENMASK is much less than the fallout from no longer compiling kernels, since those kernels won't get any test coverage at all anymore. We cannot apply this until we fix all errors. I do not understand why Andrew picked up this so soon. I think it makes complete sense to break -next (not mainline) and force people to fix defects. Especially these types of defects that are trivial to fix. I don't think this (from next-20190807): Build results: total: 158 pass: 137 fail: 21 Qemu test results: total: 391 pass: 318 fail: 73 is very useful. The situation is bad enough for newly introduced problems. It is all but impossible to get fixes for all problems discovered (or introduced) by adding checks like this one. In some cases, no one will care. In others, no one will pick up patches. Sometimes people won't know or realize that they are expected to fix something. Making the situation worse, the failures introduced by the new checks will hide other accumulating problems. arch/sh has failed to build in mainline since 7/27 and in -next since next-20190711, due to the added "fallthrough" warning. I don't think that is too useful either. Ok, that situation may be a sign that the architecture isn't maintained as well as it should, but I don't think that this warrants breaking it on purpose in the hope to trigger some kind of reaction. I don't mind if new checks are introduced, and I agree that it is useful and makes sense. But the checks should only be introduced after a reasonable attempt was made to fix _all_ associated problems. That doesn't mean that the entire work has to be done by the person introducing the check, but I do see that person responsible for making sure (or a reasonable definition of "make sure") that all problems are fixed before actually introducing the check. Yes, I understand, this is a lot of work, but adding checks and letting all hell break loose can not be the answer. No hell is unleashed. It's -next, an integration build, not mainline. ... and the breakages introduced in -next are making it into mainline without being fixed, as I just pointed out above. That by itself is bad. It is much worse if the breakage is introduced on purpose. The criteria for -next _used_ to be "ready for mainline". If breaking -next on purpose is the new normal, no one should be surprised if it will be tested even less than it is today. Guenter
Re: linux-next: build failure after merge of the crypto tree
Hi all,
On Mon, 5 Aug 2019 14:57:36 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the crypto tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> drivers/char/hw_random/n2-drv.c: In function 'n2rng_probe':
> drivers/char/hw_random/n2-drv.c:771:29: error: 'pdev' undeclared (first use
> in this function); did you mean 'cdev'?
> err = devm_hwrng_register(>dev, >hwrng);
> ^~~~
> cdev
> drivers/char/hw_random/n2-drv.c:771:29: note: each undeclared identifier is
> reported only once for each function it appears in
>
> Caused by commit
>
> 3e75241be808 ("hwrng: drivers - Use device-managed registration API")
>
> I applied the following patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 5 Aug 2019 14:49:59 +1000
> Subject: [PATCH] hwrng: fix typo in n2-drv.c
>
> Fixes: 3e75241be808 ("hwrng: drivers - Use device-managed registration API")
> Signed-off-by: Stephen Rothwell
> ---
> drivers/char/hw_random/n2-drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
> index 2d256b3470db..73e408146420 100644
> --- a/drivers/char/hw_random/n2-drv.c
> +++ b/drivers/char/hw_random/n2-drv.c
> @@ -768,7 +768,7 @@ static int n2rng_probe(struct platform_device *op)
> np->hwrng.data_read = n2rng_data_read;
> np->hwrng.priv = (unsigned long) np;
>
> - err = devm_hwrng_register(>dev, >hwrng);
> + err = devm_hwrng_register(>dev, >hwrng);
> if (err)
> goto out_hvapi_unregister;
>
> --
> 2.20.1
I am still applying that patch ...
--
Cheers,
Stephen Rothwell
pgpqF5Ev6bfmw.pgp
Description: OpenPGP digital signature
Re: [PATCH resend] fs/handle.c - fix up kerneldoc
On Wed, Aug 07, 2019 at 07:22:34PM -0400, Valdis Klētnieks wrote: > When building with W=1, we get some kerneldoc warnings: > > CC fs/fhandle.o > fs/fhandle.c:259: warning: Function parameter or member 'flags' not described > in 'sys_open_by_handle_at' > fs/fhandle.c:259: warning: Excess function parameter 'flag' description in > 'sys_open_by_handle_at' > > Fix the typo that caused it. > > Signed-off-by: Valdis Kletnieks Applied.
Re: [PATCH v2] scsi: ufs: Configure clock in .hce_enable_notify() in Cadence UFS
Anil, > Configure CDNS_UFS_REG_HCLKDIV in .hce_enable_notify() instead of > .setup_clock() because if UFSHCD resets the controller ip because > of phy or device related errors then CDNS_UFS_REG_HCLKDIV is > reset to default value and .setup_clock() is not called later > in the sequence whereas .hce_enable_notify will be called everytime > controller is reenabled. Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH v2] Fix non-kerneldoc comment in realtek/rtlwifi/usb.c
Fix spurious warning message when building with W=1:
CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o
drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand *
on line 243 - I thought it was a doc line
drivers/net/wireless/realtek/rtlwifi/usb.c:760: warning: Cannot understand *
on line 760 - I thought it was a doc line
drivers/net/wireless/realtek/rtlwifi/usb.c:790: warning: Cannot understand *
on line 790 - I thought it was a doc line
Clean up the comment format.
Signed-off-by: Valdis Kletnieks
---
Changes since v1: Larry Finger pointed out the patch wasn't checkpatch-clean.
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 34d68dbf4b4c..4b59f3b46b28 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -239,10 +239,7 @@ static void _rtl_usb_io_handler_release(struct
ieee80211_hw *hw)
mutex_destroy(>io.bb_mutex);
}
-/**
- *
- * Default aggregation handler. Do nothing and just return the oldest skb.
- */
+/* Default aggregation handler. Do nothing and just return the oldest skb.
*/
static struct sk_buff *_none_usb_tx_aggregate_hdl(struct ieee80211_hw *hw,
struct sk_buff_head *list)
{
@@ -756,11 +753,6 @@ static int rtl_usb_start(struct ieee80211_hw *hw)
return err;
}
-/**
- *
- *
- */
-
/*=== tx =*/
static void rtl_usb_cleanup(struct ieee80211_hw *hw)
{
@@ -786,11 +778,7 @@ static void rtl_usb_cleanup(struct ieee80211_hw *hw)
usb_kill_anchored_urbs(>tx_submitted);
}
-/**
- *
- * We may add some struct into struct rtl_usb later. Do deinit here.
- *
- */
+/* We may add some struct into struct rtl_usb later. Do deinit here. */
static void rtl_usb_deinit(struct ieee80211_hw *hw)
{
rtl_usb_cleanup(hw);
Re: [PATCH v5 0/4] add coupled regulators for Exynos5422/5800
Hi Kamil, When I applied them to testing branch, those don't have the author name only just have the email address as following: You have to edit the your git author information with your name. author k.koniec...@partner.samsung.com 2019-08-07 15:38:36 +0200 committer Chanwoo Choi 2019-08-08 10:35:16 +0900 commit 4304f4ecec93cebd255463d56b0a4f112ee9dc50 (patch) tree2859e566d6f68219f71a61e7c412717c1adba4f5 parent 57d85421038b458dd87ec268404ff608f90c36ae (diff) downloadlinux-4304f4ecec93cebd255463d56b0a4f112ee9dc50.tar.gz Regards, Chanwoo Choi On 19. 8. 7. 오후 10:38, k.koniec...@partner.samsung.com wrote: > Hi, > > The main purpose of this patch series is to add coupled regulators for > Exynos5422/5800 to keep constrain on voltage difference between vdd_arm > and vdd_int to be at most 300mV. In exynos-bus instead of using > regulator_set_voltage_tol() with default voltage tolerance it should be > used regulator_set_voltage_triplet() with volatege range, and this is > already present in opp/core.c code, so it can be reused. While at this, > move setting regulators into opp/core. > > This patchset was tested on Odroid XU3. > > The DTS coupled regulators patch depends on previous patches. > > Changes: > v5: > - squashed last patch "remove exynos_bus_passive_target()" into second > - added Acked-by to patch "correct clock enable sequence" > v4: > - removed "opp: core: add regulators enable and disable" from patchset > as it was applied by Viresh Kumar and changed cover letter > - fix patch "devfreq: exynos-bus: correct clock enable sequence" to > correct order of enable/disable > - removed unrelated changes in "devfreq: exynos-bus: convert to use > dev_pm_opp_set_rate()" > - added new patch "devfreq: exynos-bus: remove exynos_bus_passive_target()" > as suggested by Chanwoo Choi > v3: > - added new exynos-bus patch to correct clock and regulator enabling > and disabling sequence as suggested by Chanwoo Choi > - corrected error path in enable and improved commit message in opp/core > - improve comment in devfreq/exynos-bus.c before devfreq_recommended_opp() > - change cover letter as there is new patch > - added note before Signed-off-by in 4th patch > v2: > - improve regulators enable/disable code in opp/core as suggested by > Viresh Kumar > - add new patch for remove unused dt-bindings as suggested by Krzysztof > Kozlowski > > Kamil Konieczny (3): > devfreq: exynos-bus: correct clock enable sequence > devfreq: exynos-bus: convert to use dev_pm_opp_set_rate() > dt-bindings: devfreq: exynos-bus: remove unused property > > Marek Szyprowski (1): > ARM: dts: exynos: add initial data for coupled regulators for > Exynos5422/5800 > > .../bindings/devfreq/exynos-bus.txt | 2 - > arch/arm/boot/dts/exynos5420.dtsi | 34 ++-- > arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 4 + > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 + > arch/arm/boot/dts/exynos5800.dtsi | 32 ++-- > drivers/devfreq/exynos-bus.c | 153 +- > 6 files changed, 78 insertions(+), 151 deletions(-) > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH V2] scsi: ufs: revamp string descriptor reading
Tomas, > Define new a type: uc_string_id for easier string handling and less > casting. Reduce number or string copies in price of a dynamic > allocation. Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: wd33c93: Mark expected swich fall-through
Gustavo, > Mark switch cases where we are expecting to fall through. > > This patch fixes the following warning (Building: m68k): > > drivers/scsi/wd33c93.c: In function ‘round_4’: > drivers/scsi/wd33c93.c:1856:11: warning: this statement may fall through > [-Wimplicit-fallthrough=] >case 2: ++x; >^~~ Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: sun3_scsi: Mark expected switch fall-throughs
Gustavo, > Mark switch cases where we are expecting to fall through. > > This patch fixes the following warnings: > > drivers/scsi/sun3_scsi.c: warning: this statement may fall through > [-Wimplicit-fallthrough=]: => 399:9, 403:9 Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] scripts/checkpatch.pl - fix *_NOTIFIER_HEAD handling
commit 81398d99e9de80d9dbe65dfe7aadec9497f88242
Author: Gilad Ben-Yossef
Date: Wed Jul 31 14:44:23 2019 +1000
checkpatch: add *_NOTIFIER_HEAD as var definition
has a typo, resulting in a truly amazing error message:
Unescaped left brace in regex is passed through in regex; marked by <-- HERE in
m/(?:
\n.}\s*$|
^.DEFINE_(?^x:
[A-Za-z_][A-Za-z\d_]*
(?:\s*\#\#\s*[A-Za-z_][A-Za-z\d_]*)*
)\(rtl_usb_probe\)|
^.DECLARE_(?^x:
[A-Za-z_][A-Za-z\d_]*
(?:\s*\#\#\s*[A-Za-z_][A-Za-z\d_]*)*
)\(rtl_usb_probe\)|
^.LIST_HEAD\(rtl_usb_probe\)|
^.{ <-- HERE (?^x:
[A-Za-z_][A-Za-z\d_]*
(?:\s*\#\#\s*[A-Za-z_][A-Za-z\d_]*)*
)}_NOTIFIER_HEAD\(rtl_usb_probe\)|
(Rexexp dump continues for 236 lines total)
Fix the typo.
Signed-off-by: Valdis Kletnieks
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5c00151cdee8..dd095d1e5a19 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3891,7 +3891,7 @@ sub process {
^.DEFINE_$Ident\(\Q$name\E\)|
^.DECLARE_$Ident\(\Q$name\E\)|
^.LIST_HEAD\(\Q$name\E\)|
- ^.{$Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
+ ^.${Ident}_NOTIFIER_HEAD\(\Q$name\E\)|
^.(?:$Storage\s+)?$Type\s*\(\s*\*\s*\Q$name\E\s*\)\s*\(|
\b\Q$name\E(?:\s+$Attribute)*\s*(?:;|=|\[|\()
)/x) {
[PATCH] scsi: lpfc: remove redundant code
Remove the redundant initialization code. Signed-off-by: Fuqian Huang --- drivers/scsi/lpfc/lpfc_bsg.c | 1 - drivers/scsi/lpfc/lpfc_sli.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c index b7216d694bff..5f66a2da2599 100644 --- a/drivers/scsi/lpfc/lpfc_bsg.c +++ b/drivers/scsi/lpfc/lpfc_bsg.c @@ -1571,7 +1571,6 @@ lpfc_issue_ct_rsp(struct lpfc_hba *phba, struct bsg_job *job, uint32_t tag, "2722 Xmit CT response on exchange x%x Data: x%x x%x x%x\n", icmd->ulpContext, icmd->ulpIoTag, tag, phba->link_state); - ctiocb->iocb_cmpl = NULL; ctiocb->iocb_flag |= LPFC_IO_LIBDFC; ctiocb->vport = phba->pport; ctiocb->context1 = dd_data; diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index f9e6a135d656..156224c14cc7 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -17445,7 +17445,6 @@ lpfc_sli4_seq_abort_rsp(struct lpfc_vport *vport, icmd->ulpContext = phba->sli4_hba.rpi_ids[ndlp->nlp_rpi]; ctiocb->context1 = lpfc_nlp_get(ndlp); - ctiocb->iocb_cmpl = NULL; ctiocb->vport = phba->pport; ctiocb->iocb_cmpl = lpfc_sli4_seq_abort_rsp_cmpl; ctiocb->sli4_lxritag = NO_XRI; -- 2.11.0
Re: [PATCH] scsi: qlogicpti: Mark expected switch fall-throughs
Gustavo, > Mark switch cases where we are expecting to fall through. > > This patch fixes the following warnings (Building: sparc defconfig): Applied to 5.4/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
