Re: [PATCH] staging: mt7621-eth: Refactor RX ring resource allocation and cleanup
On Wed, May 30, 2018 at 11:16:10AM +1000, NeilBrown wrote:
> "obviously" we would first fix mtk_rx_free_frags() to do the right thing
> if ring->rx_data were NULL. This is a crucial part of robust error
> handling.
> The very best error handling style is devm_*. When that is not
> practical, kfree() style, which quietly accepts NULL, is a good second
> best.
> Could it be that the various bugs you have seen could be blamed on
> resource-release function which do not handle NULL well? When these
> bugs were fixed, were they fixed by fixing the resource-release
> function (which would benefit many) or were they fixed by making the
> code more robust against a poor interface by adding more checking?
It's way way more complicated to review that sort of code.
With multi label style error handling, I can just track the most
recently allocated resource and tell from the goto if it frees what I
expected.
With one label error handling, I have to scroll down to the bottom of
the function. Then jump to mtk_rx_free_frags(). Then carefully read
through it to see if can handle a partially allocated array. Then I
have to jump back to the original code and scroll up to see if
ring->rx_data is zeroed memory and where ring->rx_buf_size gets set.
>
> >
> > Multi label error handling is self documenting so you don't need to jump
> > to the bottom of the function. You only need to track the most recently
> > allocated resource.
> >
> > foo = allocate_foo();
> > if (!foo)
> > return -ENOMEM;
> >
> > bar = allocate_bar();
> > if (!bar) {
> > ret = -ENOMEM;
> > goto err_free_foo;
> > }
>
> I despise this structure because I cannot simply add
>
> baz = allocate_baz();
> if (!baz) {
> ret = -ENOMEM;
> goto err_???;
> }
>
> in the between these two. I would need to also change the err_free_foo
> to err_free_baz.
In the common case, you only need to update one goto.
foo = allocate_foo();
if (!foo)
return -ENOMEM;
ret = allocate_new();
if (ret)
goto free_foo;
ret = -ENOMEM;
bar = allocate_bar();
if (!bar)
goto free_new; <-- changed
Which ever way you write error handling, it always needs to be updated
so this isn't worse than other styles.
> Possibly if the convention was "goto err_baz_failed" it might be
> workable. Then the failure code would get
>
>free_baz(baz);
> err_baz_failed:
>
> added to it. That would be less despicable, but not as good have
> ensuring that every free_XXX() correctly handled NULL.
When code uses "come from" style label names, the gotos look like this:
foo = kmalloc();
if (!foo)
goto foo_failed;
That's useless, because it doesn't tell what the goto does. Imagine if
functions were named after the call site. It's the same concept. I
have to scroll to the bottom to see what the goto does.
>
> >
> > This style of error handling is the most maintainable. For example, I
> > see bugs where people change a function from returning NULL to returning
> > an error pointer but the error handling was relying on that kfree(NULL)
> > is a no-op. If you only free resources which have been allocated then
> > you avoid that.
>
> You've just made an excellent case for changing kfree() to something like
>
> if (unlikely(ZERO_OR_NULL_PTR(objp) || IS_ERR(objp)))
> return;
>
> I look forward do seeing your patch :-)
>
I mentioned earlier that in the past few days I had seen four bugs
from one label style error handling.
2 were freeing uninitialized pointers (GCC didn't catch it).
2 were doing kfree(foo->bar); where foo was NULL.
1 was missing a free.
Changing kfree() wouldn't have fixed any of those problems. One of the
kfree(foo->bar) bugs was actually slightly involved and we're still
figuring out what the right fix is.
The multi label bug was that was a missing free. It was straight
forward to add a new free to right place.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/25] staging: lustre: libcfs: restore UMP handling
On Tue, May 29, 2018 at 10:21:41AM -0400, James Simmons wrote:
> @@ -208,20 +222,52 @@ void cfs_cpt_unset_nodemask(struct cfs_cpt_table *cptab,
> void cfs_cpu_fini(void);
>
> #else /* !CONFIG_SMP */
> -struct cfs_cpt_table;
> -#define cfs_cpt_tab ((struct cfs_cpt_table *)NULL)
>
> -static inline cpumask_var_t *
> -cfs_cpt_cpumask(struct cfs_cpt_table *cptab, int cpt)
> +static inline void cfs_cpt_table_free(struct cfs_cpt_table *cptab)
> {
> - return NULL;
> + kfree(cptab);
> }
This should free cptab->ctb_cpumask?
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings
On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert wrote:
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index e248702ee519..745bf5ca2622 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8 *buff,
> u32 size)
>
> freq = ieee80211_channel_to_frequency(curr_channel, NL80211_BAND_2GHZ);
>
> - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
"buff" comes from the network, it's going to be little endian, not cpu
endian. The rest of the function treats it as CPU endian but I'm pretty
sure it's wrong...
> cfg80211_rx_mgmt(priv->wdev, freq, 0, buff, size, 0);
> return;
> }
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c
> b/drivers/staging/wilc1000/wilc_wlan.c
> index 28c93f3f846e..a5ac1d26590b 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -560,7 +560,8 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
> *txq_count)
> int ret = 0;
> int counter;
> int timeout;
> - u32 vmm_table[WILC_VMM_TBL_SIZE];
> + __le32 vmm_table[WILC_VMM_TBL_SIZE];
> + u32 table_entry;
> struct wilc_vif *vif;
> struct wilc *wilc;
> const struct wilc_hif_func *func;
> @@ -598,10 +599,10 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
> *txq_count)
> if ((sum + vmm_sz) > LINUX_TX_SIZE)
> break;
>
> - vmm_table[i] = vmm_sz / 4;
> + table_entry = vmm_sz / 4;
> if (tqe->type == WILC_CFG_PKT)
> - vmm_table[i] |= BIT(10);
> - vmm_table[i] = cpu_to_le32(vmm_table[i]);
> + table_entry |= BIT(10);
> + vmm_table[i] = cpu_to_le32(table_entry);
>
> i++;
> sum += vmm_sz;
> @@ -704,8 +705,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
> *txq_count)
> if (vmm_table[i] == 0)
> break;
>
> - vmm_table[i] = cpu_to_le32(vmm_table[i]);
> - vmm_sz = (vmm_table[i] & 0x3ff);
> + vmm_sz = (le32_to_cpu(vmm_table[i]) & 0x3ff);
> vmm_sz *= 4;
> header = (tqe->type << 31) |
>(tqe->buffer_size << 15) |
> @@ -715,8 +715,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
> *txq_count)
> else
> header &= ~BIT(30);
>
> - header = cpu_to_le32(header);
> - memcpy(&txb[offset], &header, 4);
> + *((__le32 *)&txb[offset]) = cpu_to_le32(header);
I worry about alignment issues here. That might be the reason for the
memcpy(). (I'm reading as fast as I can and don't the code so I may
be wrong).
> if (tqe->type == WILC_CFG_PKT) {
> buffer_offset = ETH_CONFIG_PKT_HDR_OFFSET;
> } else if (tqe->type == WILC_NET_PKT) {
> @@ -770,8 +769,7 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc,
> u8 *buffer, int size)
>
> do {
> buff_ptr = buffer + offset;
> - memcpy(&header, buff_ptr, 4);
> - header = cpu_to_le32(header);
> + header = le32_to_cpup((__le32 *)buff_ptr);
Maybe the same, whenever you see a memcpy().
>
> is_cfg_packet = (header >> 31) & 0x1;
> pkt_offset = (header >> 22) & 0x1ff;
> @@ -942,6 +940,7 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const
> u8 *buffer,
> u32 offset;
> u32 addr, size, size2, blksz;
> u8 *dma_buffer;
> + const __le32 *header;
> int ret = 0;
>
> blksz = BIT(12);
> @@ -952,10 +951,9 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const
> u8 *buffer,
>
> offset = 0;
> do {
> - memcpy(&addr, &buffer[offset], 4);
> - memcpy(&size, &buffer[offset + 4], 4);
> - addr = cpu_to_le32(addr);
> - size = cpu_to_le32(size);
> + header = (__le32 *)buffer + offset;
> + addr = le32_to_cpu(header[0]);
> + size = le32_to_cpu(header[1]);
> acquire_bus(wilc, ACQUIRE_ONLY);
> offset += 8;
> while (((int)size) && (offset < buffer_size)) {
> diff --git a/drivers/staging/wilc1000/wilc_wlan_cfg.c
> b/drivers/staging/wilc1000/wilc_wlan_cfg.c
> index c0b9b700f4d7..4a914d8572aa 100644
> --- a/drivers/staging/wilc1000/wilc_wlan_cfg.c
> +++ b/drivers/staging/wilc1000/wilc_wlan_cfg.c
> @@ -275,14 +275,14 @@ static int wilc_wlan_cfg_set_bin(u8 *frame, u32 offset,
> u16 id, u8 *b, u32 size)
>
> static void wilc_wlan_
Re: [PATCH 1/1] staging: wilc1000: Use common structs to parse ip packets
On Tue, May 29, 2018 at 09:08:39PM +0200, Thibaut Robert wrote:
> static inline void tcp_process(struct net_device *dev, struct txq_entry_t
> *tqe)
> {
> - u8 *eth_hdr_ptr;
> + const struct ethhdr *eth_hdr_ptr = (const struct ethhdr *)tqe->buffer;
> +
> u8 *buffer = tqe->buffer;
No blank line, please.
> - unsigned short h_proto;
> int i;
> unsigned long flags;
> struct wilc_vif *vif;
> @@ -197,37 +199,25 @@ static inline void tcp_process(struct net_device *dev,
> struct txq_entry_t *tqe)
>
> spin_lock_irqsave(&wilc->txq_spinlock, flags);
>
> - eth_hdr_ptr = &buffer[0];
> - h_proto = ntohs(*((unsigned short *)ð_hdr_ptr[12]));
> - if (h_proto == ETH_P_IP) {
> - u8 *ip_hdr_ptr;
> - u8 protocol;
> -
> - ip_hdr_ptr = &buffer[ETHERNET_HDR_LEN];
> - protocol = ip_hdr_ptr[9];
> + if (eth_hdr_ptr->h_proto == htons(ETH_P_IP)) {
> + const struct iphdr *ip_hdr_ptr = (const struct iphdr *)
> + (buffer + ETH_HLEN);
If you declared buffer as a void pointer you could remove this cast.
const struct iphdr *ip_hdr_ptr = buf + ETH_HLEN;
>
> - if (protocol == 0x06) {
> - u8 *tcp_hdr_ptr;
> + if (ip_hdr_ptr->protocol == IPPROTO_TCP) {
> + const struct tcphdr *tcp_hdr_ptr;
> u32 IHL, total_length, data_offset;
>
> - tcp_hdr_ptr = &ip_hdr_ptr[IP_HDR_LEN];
> - IHL = (ip_hdr_ptr[0] & 0xf) << 2;
> - total_length = ((u32)ip_hdr_ptr[2] << 8) +
> - (u32)ip_hdr_ptr[3];
> - data_offset = ((u32)tcp_hdr_ptr[12] & 0xf0) >> 2;
> + IHL = ip_hdr_ptr->ihl << 2;
> + tcp_hdr_ptr = (const struct tcphdr *)
> + ((u8 *)ip_hdr_ptr + IHL);
This alignment is a bit unfortunate... Perhaps?
tcp_hdr_ptr = buf + ETH_HLEN + IHL;
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic
It's weird, I only get Greg's side of this thread. Sunil's emails are going to the list: https://marc.info/?l=linux-driver-devel&m=152762471013289&w=2 But they're not getting to my gmail account. I've checked the spam folder as well and they're not there. Anyone else having this issue? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic
Gmail really seems to hate @microsoft.com addresses... I never get Dexuan's emails either. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: libcfs: add parens around macros args
On Tue, May 22, 2018 at 04:34:39PM +0300, Ivan Bornyakov wrote: > One may call 'CFS_FAIL_TIMEOUT(id, secs + 5);' and get unexpected result > after macro substitution, viz., 'secs + 5' will turn into > 'secs + 5 * 1000' > We actually do that in ptl_send_rpc() as well so this is a real bug. It's sort of an interesting coincidence that the code in ptl_send_rpc() looks almost exactly like your theoretical code: OBD_FAIL_TIMEOUT(OBD_FAIL_PTLRPC_DELAY_SEND, request->rq_timeout + 5); regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings
On Tue, 29 May 2018 21:11:43 +0200
Thibaut Robert wrote:
> This commit fix a few sparse warnings. It mostly consists of fixing
> the type declarations and avoiding the use of variables with mixed
> endianness values.
>
> Signed-off-by: Thibaut Robert
> ---
> drivers/staging/wilc1000/wilc_spi.c | 15 ++-
> .../staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
> drivers/staging/wilc1000/wilc_wlan.c | 26
> +-- drivers/staging/wilc1000/wilc_wlan_cfg.c |
> 8 +++--- drivers/staging/wilc1000/wilc_wlan_cfg.h | 4 +--
> 5 files changed, 27 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_spi.c
> b/drivers/staging/wilc1000/wilc_spi.c index
> 647526387784..e51f0d91a376 100644 ---
> a/drivers/staging/wilc1000/wilc_spi.c +++
> b/drivers/staging/wilc1000/wilc_spi.c @@ -666,11 +666,11 @@ static
> int spi_data_write(struct wilc *wilc, u8 *b, u32 sz) static int
> spi_internal_write(struct wilc *wilc, u32 adr, u32 dat) {
> struct spi_device *spi = to_spi_device(wilc->dev);
> + __le32 le32dat = cpu_to_le32(dat);
> int result;
>
> - dat = cpu_to_le32(dat);
> - result = spi_cmd_complete(wilc, CMD_INTERNAL_WRITE, adr, (u8
> *)&dat, 4,
> - 0);
> + result = spi_cmd_complete(wilc, CMD_INTERNAL_WRITE, adr, (u8
> *)&le32dat,
> + 4, 0);
> if (result != N_OK)
> dev_err(&spi->dev, "Failed internal write cmd...\n");
>
> @@ -689,7 +689,7 @@ static int spi_internal_read(struct wilc *wilc,
> u32 adr, u32 *data) return 0;
> }
>
> - *data = cpu_to_le32(*data);
> + le32_to_cpus(data);
>
> return 1;
> }
> @@ -706,15 +706,16 @@ static int wilc_spi_write_reg(struct wilc
> *wilc, u32 addr, u32 data) int result = N_OK;
> u8 cmd = CMD_SINGLE_WRITE;
> u8 clockless = 0;
> + __le32 le32data = cpu_to_le32(data);
>
> - data = cpu_to_le32(data);
> if (addr < 0x30) {
> /* Clockless register */
> cmd = CMD_INTERNAL_WRITE;
> clockless = 1;
> }
>
> - result = spi_cmd_complete(wilc, cmd, addr, (u8 *)&data, 4,
> clockless);
> + result = spi_cmd_complete(wilc, cmd, addr, (u8 *)&le32data,
> 4,
> + clockless);
> if (result != N_OK)
> dev_err(&spi->dev, "Failed cmd, write reg
> (%08x)...\n", addr);
> @@ -769,7 +770,7 @@ static int wilc_spi_read_reg(struct wilc *wilc,
> u32 addr, u32 *data) return 0;
> }
>
> - *data = cpu_to_le32(*data);
> + le32_to_cpus(data);
>
> return 1;
> }
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> e248702ee519..745bf5ca2622 100644 ---
> a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -1431,7
> +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8 *buff, u32
> size) freq = ieee80211_channel_to_frequency(curr_channel,
> NL80211_BAND_2GHZ);
> - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> cfg80211_rx_mgmt(priv->wdev, freq, 0, buff, size, 0);
> return;
> }
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c
> b/drivers/staging/wilc1000/wilc_wlan.c index
> 28c93f3f846e..a5ac1d26590b 100644 ---
> a/drivers/staging/wilc1000/wilc_wlan.c +++
> b/drivers/staging/wilc1000/wilc_wlan.c @@ -560,7 +560,8 @@ int
> wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count) int ret
> = 0; int counter;
> int timeout;
> - u32 vmm_table[WILC_VMM_TBL_SIZE];
> + __le32 vmm_table[WILC_VMM_TBL_SIZE];
> + u32 table_entry;
> struct wilc_vif *vif;
> struct wilc *wilc;
> const struct wilc_hif_func *func;
> @@ -598,10 +599,10 @@ int wilc_wlan_handle_txq(struct net_device
> *dev, u32 *txq_count) if ((sum + vmm_sz) > LINUX_TX_SIZE)
> break;
>
> - vmm_table[i] = vmm_sz / 4;
> + table_entry = vmm_sz / 4;
> if (tqe->type == WILC_CFG_PKT)
> - vmm_table[i] |= BIT(10);
> - vmm_table[i] = cpu_to_le32(vmm_table[i]);
> + table_entry |= BIT(10);
> + vmm_table[i] = cpu_to_le32(table_entry);
>
> i++;
> sum += vmm_sz;
> @@ -704,8 +705,7 @@ int wilc_wlan_handle_txq(struct net_device *dev,
> u32 *txq_count) if (vmm_table[i] == 0)
> break;
>
> - vmm_table[i] = cpu_to_le32(vmm_table[i]);
> - vmm_sz = (vmm_table[i] & 0x3ff);
> + vmm_sz = (le32_to_cpu(vmm_table[i]) & 0x3ff);
> vmm_sz *= 4;
> header = (tqe->type << 31) |
>(tqe->buffer_size << 15) |
> @@ -715,8 +715,7 @
[staging:debugfs_cleanup 814/814] arch/x86//kernel/kdebugfs.c:153:17: error: 'version' undeclared; did you mean 'err_version'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
debugfs_cleanup
head: 4c08a9f6835cff642bc71face6ab47ebfdeda70c
commit: 4c08a9f6835cff642bc71face6ab47ebfdeda70c [814/814] arch/*: no need to
check return value of debugfs_create functions
config: i386-randconfig-x008-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 4c08a9f6835cff642bc71face6ab47ebfdeda70c
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
arch/x86//kernel/kdebugfs.c: In function 'boot_params_kdebugfs_init':
>> arch/x86//kernel/kdebugfs.c:151:17: error: 'data' undeclared (first use in
>> this function); did you mean 'path'?
debugfs_remove(data);
^~~~
path
arch/x86//kernel/kdebugfs.c:151:17: note: each undeclared identifier is
reported only once for each function it appears in
>> arch/x86//kernel/kdebugfs.c:153:17: error: 'version' undeclared (first use
>> in this function); did you mean 'err_version'?
debugfs_remove(version);
^~~
err_version
arch/x86//kernel/kdebugfs.c:154:1: warning: label 'err_dir' defined but not
used [-Wunused-label]
err_dir:
^~~
arch/x86//kernel/kdebugfs.c:152:1: warning: label 'err_version' defined but
not used [-Wunused-label]
err_version:
^~~
vim +153 arch/x86//kernel/kdebugfs.c
6d7d74337 Huang, Ying2008-01-30 133
6d7d74337 Huang, Ying2008-01-30 134 static int __init
boot_params_kdebugfs_init(void)
6d7d74337 Huang, Ying2008-01-30 135 {
4c08a9f68 Greg Kroah-Hartman 2018-05-30 136struct dentry *dbp;
390cd85c8 Jaswinder Singh Rajput 2009-03-21 137int error = -ENOMEM;
6d7d74337 Huang, Ying2008-01-30 138
10bce8410 Borislav Petkov2017-02-27 139dbp =
debugfs_create_dir("boot_params", arch_debugfs_dir);
390cd85c8 Jaswinder Singh Rajput 2009-03-21 140
4c08a9f68 Greg Kroah-Hartman 2018-05-30 141
debugfs_create_x16("version", S_IRUGO, dbp, &boot_params.hdr.version);
4c08a9f68 Greg Kroah-Hartman 2018-05-30 142
debugfs_create_blob("data", S_IRUGO, dbp, &boot_params_blob);
390cd85c8 Jaswinder Singh Rajput 2009-03-21 143
c14b2adf1 Huang, Ying2008-03-28 144error =
create_setup_data_nodes(dbp);
c14b2adf1 Huang, Ying2008-03-28 145if (error)
c14b2adf1 Huang, Ying2008-03-28 146goto err_data;
390cd85c8 Jaswinder Singh Rajput 2009-03-21 147
6d7d74337 Huang, Ying2008-01-30 148return 0;
c14b2adf1 Huang, Ying2008-03-28 149
c14b2adf1 Huang, Ying2008-03-28 150 err_data:
c14b2adf1 Huang, Ying2008-03-28 @151debugfs_remove(data);
6d7d74337 Huang, Ying2008-01-30 152 err_version:
6d7d74337 Huang, Ying2008-01-30 @153debugfs_remove(version);
6d7d74337 Huang, Ying2008-01-30 154 err_dir:
6d7d74337 Huang, Ying2008-01-30 155debugfs_remove(dbp);
6d7d74337 Huang, Ying2008-01-30 156return error;
6d7d74337 Huang, Ying2008-01-30 157 }
390cd85c8 Jaswinder Singh Rajput 2009-03-21 158 #endif /*
CONFIG_DEBUG_BOOT_PARAMS */
6d7d74337 Huang, Ying2008-01-30 159
:: The code at line 153 was first introduced by commit
:: 6d7d7433750c7c6eec93d7b3206019e329228686 x86 boot : export boot_params
via debugfs for debugging
:: TO: Huang, Ying
:: CC: Ingo Molnar
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v4 1/8] net: bridge: Extract boilerplate around switchdev_port_obj_*()
On 30/05/18 03:56, Petr Machata wrote: > A call to switchdev_port_obj_add() or switchdev_port_obj_del() involves > initializing a struct switchdev_obj_port_vlan, a piece of code that > repeats on each call site almost verbatim. While in the current codebase > there is just one duplicated add call, the follow-up patches add more of > both add and del calls. > > Thus to remove the duplication, extract the repetition into named > functions and reuse. > > Signed-off-by: Petr Machata > Reviewed-by: Vivien Didelot > --- > net/bridge/br_private.h | 13 + > net/bridge/br_switchdev.c | 25 + > net/bridge/br_vlan.c | 26 +++--- > 3 files changed, 41 insertions(+), 23 deletions(-) > Reviewed-by: Nikolay Aleksandrov ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v4 2/8] net: bridge: Extract br_vlan_add_existing()
On 30/05/18 03:56, Petr Machata wrote: > Extract the code that deals with adding a preexisting VLAN to bridge CPU > port to a separate function. A follow-up patch introduces a need to roll > back operations in this block due to an error, and this split will make > the error-handling code clearer. > > Signed-off-by: Petr Machata > --- > net/bridge/br_vlan.c | 55 > +++- > 1 file changed, 33 insertions(+), 22 deletions(-) > Reviewed-by: Nikolay Aleksandrov ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:debugfs_cleanup 814/814] arch/x86/kernel/kdebugfs.c:151:17: error: 'data' undeclared
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
debugfs_cleanup
head: 4c08a9f6835cff642bc71face6ab47ebfdeda70c
commit: 4c08a9f6835cff642bc71face6ab47ebfdeda70c [814/814] arch/*: no need to
check return value of debugfs_create functions
config: i386-randconfig-s1-201821 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 4c08a9f6835cff642bc71face6ab47ebfdeda70c
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
arch/x86/kernel/kdebugfs.c: In function 'boot_params_kdebugfs_init':
>> arch/x86/kernel/kdebugfs.c:151:17: error: 'data' undeclared (first use in
>> this function)
debugfs_remove(data);
^~~~
arch/x86/kernel/kdebugfs.c:151:17: note: each undeclared identifier is
reported only once for each function it appears in
>> arch/x86/kernel/kdebugfs.c:153:17: error: 'version' undeclared (first use in
>> this function)
debugfs_remove(version);
^~~
arch/x86/kernel/kdebugfs.c:154:1: warning: label 'err_dir' defined but not
used [-Wunused-label]
err_dir:
^~~
arch/x86/kernel/kdebugfs.c:152:1: warning: label 'err_version' defined but
not used [-Wunused-label]
err_version:
^~~
vim +/data +151 arch/x86/kernel/kdebugfs.c
6d7d74337 Huang, Ying2008-01-30 133
6d7d74337 Huang, Ying2008-01-30 134 static int __init
boot_params_kdebugfs_init(void)
6d7d74337 Huang, Ying2008-01-30 135 {
4c08a9f68 Greg Kroah-Hartman 2018-05-30 136struct dentry *dbp;
390cd85c8 Jaswinder Singh Rajput 2009-03-21 137int error = -ENOMEM;
6d7d74337 Huang, Ying2008-01-30 138
10bce8410 Borislav Petkov2017-02-27 139dbp =
debugfs_create_dir("boot_params", arch_debugfs_dir);
390cd85c8 Jaswinder Singh Rajput 2009-03-21 140
4c08a9f68 Greg Kroah-Hartman 2018-05-30 141
debugfs_create_x16("version", S_IRUGO, dbp, &boot_params.hdr.version);
4c08a9f68 Greg Kroah-Hartman 2018-05-30 142
debugfs_create_blob("data", S_IRUGO, dbp, &boot_params_blob);
390cd85c8 Jaswinder Singh Rajput 2009-03-21 143
c14b2adf1 Huang, Ying2008-03-28 144error =
create_setup_data_nodes(dbp);
c14b2adf1 Huang, Ying2008-03-28 145if (error)
c14b2adf1 Huang, Ying2008-03-28 146goto err_data;
390cd85c8 Jaswinder Singh Rajput 2009-03-21 147
6d7d74337 Huang, Ying2008-01-30 148return 0;
c14b2adf1 Huang, Ying2008-03-28 149
c14b2adf1 Huang, Ying2008-03-28 150 err_data:
c14b2adf1 Huang, Ying2008-03-28 @151debugfs_remove(data);
6d7d74337 Huang, Ying2008-01-30 152 err_version:
6d7d74337 Huang, Ying2008-01-30 @153debugfs_remove(version);
6d7d74337 Huang, Ying2008-01-30 154 err_dir:
6d7d74337 Huang, Ying2008-01-30 155debugfs_remove(dbp);
6d7d74337 Huang, Ying2008-01-30 156return error;
6d7d74337 Huang, Ying2008-01-30 157 }
390cd85c8 Jaswinder Singh Rajput 2009-03-21 158 #endif /*
CONFIG_DEBUG_BOOT_PARAMS */
6d7d74337 Huang, Ying2008-01-30 159
:: The code at line 151 was first introduced by commit
:: c14b2adf19b5d35aff91280b1a73c41a4dcabfe3 x86, boot: export linked list
of struct setup_data via debugfs
:: TO: Huang, Ying
:: CC: Ingo Molnar
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v4 7/8] net: bridge: Notify about bridge VLANs
On 30/05/18 04:00, Petr Machata wrote: > A driver might need to react to changes in settings of brentry VLANs. > Therefore send switchdev port notifications for these as well. Reuse > SWITCHDEV_OBJ_ID_PORT_VLAN for this purpose. Listeners should use > netif_is_bridge_master() on orig_dev to determine whether the > notification is about a bridge port or a bridge. > > Signed-off-by: Petr Machata > --- > net/bridge/br_vlan.c | 28 +--- > 1 file changed, 25 insertions(+), 3 deletions(-) > LGTM, Reviewed-by: Nikolay Aleksandrov ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:debugfs_cleanup 814/814] arch/x86//kernel/kdebugfs.c:146:3: error: label 'err_data' used but not defined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
debugfs_cleanup
head: 05f6bcf9002239baec3686f19f6b279cb67dccbd
commit: 05f6bcf9002239baec3686f19f6b279cb67dccbd [814/814] arch/*: no need to
check return value of debugfs_create functions
config: x86_64-randconfig-x007-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 05f6bcf9002239baec3686f19f6b279cb67dccbd
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86//kernel/kdebugfs.c: In function 'boot_params_kdebugfs_init':
arch/x86//kernel/kdebugfs.c:150:1: warning: label 'err_dir' defined but not
used [-Wunused-label]
err_dir:
^~~
>> arch/x86//kernel/kdebugfs.c:146:3: error: label 'err_data' used but not
>> defined
goto err_data;
^~~~
vim +/err_data +146 arch/x86//kernel/kdebugfs.c
6d7d74337 Huang, Ying2008-01-30 133
6d7d74337 Huang, Ying2008-01-30 134 static int __init
boot_params_kdebugfs_init(void)
6d7d74337 Huang, Ying2008-01-30 135 {
05f6bcf90 Greg Kroah-Hartman 2018-05-30 136struct dentry *dbp;
390cd85c8 Jaswinder Singh Rajput 2009-03-21 137int error = -ENOMEM;
6d7d74337 Huang, Ying2008-01-30 138
10bce8410 Borislav Petkov2017-02-27 139dbp =
debugfs_create_dir("boot_params", arch_debugfs_dir);
390cd85c8 Jaswinder Singh Rajput 2009-03-21 140
05f6bcf90 Greg Kroah-Hartman 2018-05-30 141
debugfs_create_x16("version", S_IRUGO, dbp, &boot_params.hdr.version);
05f6bcf90 Greg Kroah-Hartman 2018-05-30 142
debugfs_create_blob("data", S_IRUGO, dbp, &boot_params_blob);
390cd85c8 Jaswinder Singh Rajput 2009-03-21 143
c14b2adf1 Huang, Ying2008-03-28 144error =
create_setup_data_nodes(dbp);
c14b2adf1 Huang, Ying2008-03-28 145if (error)
c14b2adf1 Huang, Ying2008-03-28 @146goto err_data;
390cd85c8 Jaswinder Singh Rajput 2009-03-21 147
6d7d74337 Huang, Ying2008-01-30 148return 0;
c14b2adf1 Huang, Ying2008-03-28 149
6d7d74337 Huang, Ying2008-01-30 @150 err_dir:
05f6bcf90 Greg Kroah-Hartman 2018-05-30 151
debugfs_remove_recursive(dbp);
6d7d74337 Huang, Ying2008-01-30 152return error;
6d7d74337 Huang, Ying2008-01-30 153 }
390cd85c8 Jaswinder Singh Rajput 2009-03-21 154 #endif /*
CONFIG_DEBUG_BOOT_PARAMS */
6d7d74337 Huang, Ying2008-01-30 155
:: The code at line 146 was first introduced by commit
:: c14b2adf19b5d35aff91280b1a73c41a4dcabfe3 x86, boot: export linked list
of struct setup_data via debugfs
:: TO: Huang, Ying
:: CC: Ingo Molnar
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: mt7621-mmc: Fix line size exceeding 80 columns
This patch fixes checkpatch.pl warning and check:
WARNING: line over 80 characters
CHECK: Alignment should match open parenthesis
Signed-off-by: Sankalp Negi
---
Changes in v2:
- Made alignments to match open parenthesis.
---
drivers/staging/mt7621-mmc/dbg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-mmc/dbg.c b/drivers/staging/mt7621-mmc/dbg.c
index d897b1216348..6e4e223cddfb 100644
--- a/drivers/staging/mt7621-mmc/dbg.c
+++ b/drivers/staging/mt7621-mmc/dbg.c
@@ -229,7 +229,8 @@ static int msdc_debug_proc_read(struct seq_file *s, void *p)
}
static ssize_t msdc_debug_proc_write(struct file *file,
- const char __user *buf, size_t count, loff_t
*data)
+const char __user *buf,
+size_t count, loff_t *data)
{
int ret;
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic
The maintainers of Hyper-V; Haiyang Zhang and Stephen Hemminger have always been included since the beginning in all mail & patches. I missed K. Y. Srinivasan, whom I have added now. @KY Srinivasan, @Stephen Hemminger, @Haiyang Zhang - Can we get some reviews/sign-offs? Thanks, Sunil > -Original Message- > From: Greg KH > Sent: Tuesday, May 29, 2018 9:43 PM > To: Sunil Muthuswamy > Cc: de...@linuxdriverproject.org; Haiyang Zhang > ; Stephen Hemminger > > Subject: Re: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump > over Hyper-V during panic > > On Wed, May 30, 2018 at 06:42:14AM +0200, Greg KH wrote: > > On Tue, May 29, 2018 at 08:11:40PM +, Sunil Muthuswamy wrote: > > > The V3 patch should address the concerns/comments below. Happy to > > > address any additional comments, if there are any. > > > > Why not respond to the v3 patch so I don't have to go dig it up? :) > > > > And really, it's up to the maintainer of this subsystem to provide the > > final review, and that's not me. Why did you not cc: them on the patch > > in the beginning? > > And as proof of that, I don't even have this patch in my "to-review" > local queue as I assumed the hyperv maintainers would take care of it. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic
> -Original Message- > From: Sunil Muthuswamy > Sent: Wednesday, May 30, 2018 12:40 PM > To: Greg KH ; Haiyang Zhang > ; Stephen Hemminger > ; KY Srinivasan > Cc: de...@linuxdriverproject.org > Subject: RE: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump > over Hyper-V during panic > > The maintainers of Hyper-V; Haiyang Zhang and Stephen Hemminger have > always been included since the beginning in all mail & patches. I missed K. Y. > Srinivasan, whom I have added now. I will take this patch through my tree. K. Y > > @KY Srinivasan, @Stephen Hemminger, @Haiyang Zhang - Can we get some > reviews/sign-offs? > > Thanks, > Sunil > > > -Original Message- > > From: Greg KH > > Sent: Tuesday, May 29, 2018 9:43 PM > > To: Sunil Muthuswamy > > Cc: de...@linuxdriverproject.org; Haiyang Zhang > > ; Stephen Hemminger > > > > Subject: Re: [PATCH v1] Drivers: HV: Send one page worth of kmsg dump > > over Hyper-V during panic > > > > On Wed, May 30, 2018 at 06:42:14AM +0200, Greg KH wrote: > > > On Tue, May 29, 2018 at 08:11:40PM +, Sunil Muthuswamy wrote: > > > > The V3 patch should address the concerns/comments below. Happy to > > > > address any additional comments, if there are any. > > > > > > Why not respond to the v3 patch so I don't have to go dig it up? :) > > > > > > And really, it's up to the maintainer of this subsystem to provide the > > > final review, and that's not me. Why did you not cc: them on the patch > > > in the beginning? > > > > And as proof of that, I don't even have this patch in my "to-review" > > local queue as I assumed the hyperv maintainers would take care of it. > > > > thanks, > > > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 04/13] staging: vc04_services: no need to check debugfs return values
Greg Kroah-Hartman writes:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Clean up the vchiq_arm code by not caring about the value of debugfs
> calls. This ends up removing a number of lines of code that are not
> needed.
>
> Cc: Eric Anholt
> Cc: Stefan Wahren
> Cc: Kees Cook
> Cc: Dan Carpenter
> Cc: Arnd Bergmann
> Cc: Keerthi Reddy
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> .../interface/vchiq_arm/vchiq_arm.c | 13 +---
> .../interface/vchiq_arm/vchiq_debugfs.c | 72 +++
> .../interface/vchiq_arm/vchiq_debugfs.h | 4 +-
> 3 files changed, 15 insertions(+), 74 deletions(-)
>
> diff --git
> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> index 766b4fe5f32c..103fec955e2c 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> @@ -314,31 +284,13 @@ void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T
> instance)
> debugfs_remove_recursive(node->dentry);
> }
>
> -int vchiq_debugfs_init(void)
> +void vchiq_debugfs_init(void)
> {
> - BUG_ON(debugfs_info.vchiq_cfg_dir != NULL);
> -
> debugfs_info.vchiq_cfg_dir = debugfs_create_dir("vchiq", NULL);
> - if (debugfs_info.vchiq_cfg_dir == NULL)
> - goto fail;
> -
I think now that we allow successful probe with this value NULL, module
remove could vchiq_debugfs_deinit() -> vchiq_debugfs_top() -> BUG_ON().
I think the right solution would be to just drop that BUG_ON(). With
that change (and probably just garbage-collecting that function), this
will be enthusiastically:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: include linux/highmem.h when needed
Something in recent linux-next kernels caused linux/highmem.h to
no longer be included implicitly from o2iblnd_cb.c, causing a build
failure:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function
'kiblnd_kvaddr_to_page':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:549:15: error:
'PKMAP_BASE' undeclared (first use in this function); did you mean 'RTM_BASE'?
if (vaddr >= PKMAP_BASE &&
^~
RTM_BASE
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:549:15: note: each
undeclared identifier is reported only once for each function it appears in
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:550:28: error:
'LAST_PKMAP' undeclared (first use in this function); did you mean 'AT_HWCAP'?
vaddr < (PKMAP_BASE + LAST_PKMAP * PAGE_SIZE)) {
^~
AT_HWCAP
This adds back an explicit include for the header.
Signed-off-by: Arnd Bergmann
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 47eb8b4c28db..65b7a62943ad 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -35,6 +35,7 @@
* Author: Eric Barton
*/
+#include
#include "o2iblnd.h"
#define MAX_CONN_RACES_BEFORE_ABORT 20
--
2.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: mt7621-mmc: Fix line size exceeding 80 columns
On Thu, May 31 2018, Sankalp Negi wrote:
> This patch fixes checkpatch.pl warning and check:
> WARNING: line over 80 characters
> CHECK: Alignment should match open parenthesis
>
> Signed-off-by: Sankalp Negi
Reviewed-by: NeilBrown
Thanks,
NeilBrown
> ---
> Changes in v2:
> - Made alignments to match open parenthesis.
> ---
> drivers/staging/mt7621-mmc/dbg.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/mt7621-mmc/dbg.c
> b/drivers/staging/mt7621-mmc/dbg.c
> index d897b1216348..6e4e223cddfb 100644
> --- a/drivers/staging/mt7621-mmc/dbg.c
> +++ b/drivers/staging/mt7621-mmc/dbg.c
> @@ -229,7 +229,8 @@ static int msdc_debug_proc_read(struct seq_file *s, void
> *p)
> }
>
> static ssize_t msdc_debug_proc_write(struct file *file,
> - const char __user *buf, size_t count, loff_t
> *data)
> + const char __user *buf,
> + size_t count, loff_t *data)
> {
> int ret;
>
> --
> 2.11.0
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next] hv_netvsc: fix error return code in netvsc_probe()
Fix to return a negative error code from the failover register fail
error handling case instead of 0, as done elsewhere in this function.
Fixes: 1ff78076d8dd ("netvsc: refactor notifier/event handling code to use the
failover framework")
Signed-off-by: Wei Yongjun
---
drivers/net/hyperv/netvsc_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index ebe9642..bef4d55 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2031,8 +2031,10 @@ static int netvsc_probe(struct hv_device *dev,
}
net_device_ctx->failover = failover_register(net, &netvsc_failover_ops);
- if (IS_ERR(net_device_ctx->failover))
+ if (IS_ERR(net_device_ctx->failover)) {
+ ret = PTR_ERR(net_device_ctx->failover);
goto err_failover;
+ }
return ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] ANDROID: binder: rename parameter to resolve name collision.
> Why is this needed? These don't collide in the namespace:
Sorry, I check it again, you’re right. my bad.
PS:
I need to change the binder API between 32bit & 64bit dynamically.
So I was trying to compile binder as a “.ko”. I compiled the 2
files into the same kernel module, which causes problem.
Best Regards,
> 在 2018年5月30日，下午11:54，Todd Kjos 写道：
>
> Why is this needed? These don't collide in the namespace:
>
> /sys/module/binder/parameters/debug_mask
>
> and
>
> /sys/module/binder_alloc/parameters/debug_mask.
>
> On Tue, May 29, 2018 at 9:58 PM wrote:
> From: Kuang Rufan
>
> both bind.c & binder_alloc.c define the same kernel parameter 'debug_mask',
> rename the one in binder_alloc.c to 'alloc_debug_mask'.
>
> Signed-off-by: Kuang Rufan
> ---
> drivers/android/binder_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> index 5a426c877dfb..3850dab493d4 100644
> --- a/drivers/android/binder_alloc.c
> +++ b/drivers/android/binder_alloc.c
> @@ -42,7 +42,7 @@ enum {
> };
> static uint32_t binder_alloc_debug_mask;
>
> -module_param_named(debug_mask, binder_alloc_debug_mask,
> +module_param_named(alloc_debug_mask, binder_alloc_debug_mask,
>uint, 0644);
>
> #define binder_alloc_debug(mask, x...) \
> --
> 2.15.1 (Apple Git-101)
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: include linux/highmem.h when needed
On Wed, May 30 2018, Arnd Bergmann wrote:
> Something in recent linux-next kernels caused linux/highmem.h to
> no longer be included implicitly from o2iblnd_cb.c, causing a build
> failure:
>
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function
> 'kiblnd_kvaddr_to_page':
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:549:15: error:
> 'PKMAP_BASE' undeclared (first use in this function); did you mean 'RTM_BASE'?
> if (vaddr >= PKMAP_BASE &&
>^~
>RTM_BASE
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:549:15: note: each
> undeclared identifier is reported only once for each function it appears in
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:550:28: error:
> 'LAST_PKMAP' undeclared (first use in this function); did you mean 'AT_HWCAP'?
> vaddr < (PKMAP_BASE + LAST_PKMAP * PAGE_SIZE)) {
> ^~
> AT_HWCAP
>
> This adds back an explicit include for the header.
>
> Signed-off-by: Arnd Bergmann
Thanks for finding and fixing this. I did recently reduce the number
of include files that were automatically included everywhere. Clearly
some config combinations didn't get tested properly.
Reviewed-by: NeilBrown
Thanks,
NeilBrown
> ---
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> index 47eb8b4c28db..65b7a62943ad 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> @@ -35,6 +35,7 @@
> * Author: Eric Barton
> */
>
> +#include
> #include "o2iblnd.h"
>
> #define MAX_CONN_RACES_BEFORE_ABORT 20
> --
> 2.9.0
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:debugfs_cleanup 814/814] arch/powerpc/platforms/powernv/opal-lpc.c:379:37: error: 'root' undeclared; did you mean 'ror8'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
debugfs_cleanup
head: cfe0305886b14a4f65cba2014f1963db2a534113
commit: cfe0305886b14a4f65cba2014f1963db2a534113 [814/814] arch/*: no need to
check return value of debugfs_create functions
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.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 cfe0305886b14a4f65cba2014f1963db2a534113
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/platforms/powernv/opal-lpc.c: In function
'opal_lpc_init_debugfs':
>> arch/powerpc/platforms/powernv/opal-lpc.c:379:37: error: 'root' undeclared
>> (first use in this function); did you mean 'ror8'?
rc |= opal_lpc_debugfs_create_type(root, "io", OPAL_LPC_IO);
^~~~
ror8
arch/powerpc/platforms/powernv/opal-lpc.c:379:37: note: each undeclared
identifier is reported only once for each function it appears in
--
arch/powerpc/platforms/powernv/vas-debug.c: In function
'vas_window_init_dbgdir':
>> arch/powerpc/platforms/powernv/vas-debug.c:142:17: error: unused variable
>> 'f' [-Werror=unused-variable]
struct dentry *f, *d;
^
cc1: all warnings being treated as errors
vim +379 arch/powerpc/platforms/powernv/opal-lpc.c
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 369
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 370 static int
opal_lpc_init_debugfs(void)
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 371 {
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 372 int rc = 0;
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 373
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 374 if (opal_lpc_chip_id <
0)
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 375 return -ENODEV;
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 376
cfe03058 Greg Kroah-Hartman 2018-05-30 377
debugfs_create_dir("lpc", powerpc_debugfs_root);
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 378
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 @379 rc |=
opal_lpc_debugfs_create_type(root, "io", OPAL_LPC_IO);
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 380 rc |=
opal_lpc_debugfs_create_type(root, "mem", OPAL_LPC_MEM);
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 381 rc |=
opal_lpc_debugfs_create_type(root, "fw", OPAL_LPC_FW);
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 382 return rc;
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 383 }
b14726c5 Michael Ellerman 2014-07-15 384
machine_device_initcall(powernv, opal_lpc_init_debugfs);
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 385 #endif /* CONFIG_DEBUG_FS */
fa2dbe2e Benjamin Herrenschmidt 2014-06-03 386
:: The code at line 379 was first introduced by commit
:: fa2dbe2e0fcf2cda8fc56845e475b617385b1ec6 powerpc/powernv: Provide
debugfs access to the LPC bus via OPAL
:: TO: Benjamin Herrenschmidt
:: CC: Benjamin Herrenschmidt
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: mt7621-gpio: update #interrupt-cells for the gpio node
On Wed, May 30 2018, Sergio Paracuellos wrote:
> Most gpio chips have two cells for interrupts and this should be also.
> Set this property in the device tree accordly fixing this up. In order
> to make this working properly the xlate function for the irq_domain must
> be updated to use the 'irq_domain_xlate_twocell' one in the driver.
> One more minimal change is needed two refer gpio's interrupt-parent from
> other nodes which is to add new 'gpio' label in the device tree.
>
> Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
Thanks,
NeilBrown
> ---
> Changes in v2:
> - commit message has been changed with more proper one
> - new label to refer gpio from other nodes added to the DT
> - use 'irq_domain_xlate_twocell'
>
> drivers/staging/mt7621-dts/mt7621.dtsi| 4 ++--
> drivers/staging/mt7621-gpio/gpio-mt7621.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index d7e4981..eb3966b 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -60,7 +60,7 @@
> reg = <0x100 0x100>;
> };
>
> - gpio@600 {
> + gpio: gpio@600 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> @@ -70,7 +70,7 @@
> interrupt-parent = <&gic>;
> interrupts = ;
> interrupt-controller;
> - #interrupt-cells = <1>;
> + #interrupt-cells = <2>;
>
> gpio0: bank@0 {
> reg = <0>;
> diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
> b/drivers/staging/mt7621-gpio/gpio-mt7621.c
> index c96ae67..79b8c58 100644
> --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
> +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
> @@ -317,7 +317,7 @@ mediatek_gpio_gpio_map(struct irq_domain *d, unsigned int
> irq,
> }
>
> static const struct irq_domain_ops irq_domain_ops = {
> - .xlate = irq_domain_xlate_onecell,
> + .xlate = irq_domain_xlate_twocell,
> .map = mediatek_gpio_gpio_map,
> };
>
> --
> 2.7.4
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 754/791] drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: 'ENXIO' undeclared here (not in a function)
On Sat, May 26 2018, Greg Kroah-Hartman wrote: > On Fri, May 25, 2018 at 09:40:09PM +0200, Greg Kroah-Hartman wrote: >> On Sat, May 26, 2018 at 02:04:59AM +0800, kbuild test robot wrote: >> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git >> > staging-testing >> > head: 0badacd779df08fbbc895cf6c488e100b86c1f39 >> > commit: 0922c0084b91799193059a47bfbd215ffd3a4b50 [754/791] staging: >> > lustre: remove libcfs_all from ptlrpc >> > config: ia64-allmodconfig (attached as .config) >> > compiler: ia64-linux-gcc (GCC) 8.1.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 0922c0084b91799193059a47bfbd215ffd3a4b50 >> > # save the attached .config to linux build tree >> > make.cross ARCH=ia64 >> > >> > All error/warnings (new ones prefixed by >>): >> > >> >drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: 'EPERM' >> > undeclared here (not in a function) >> > [EPERM] = LUSTRE_EPERM, >> > ^ >> >> >> >> Neil, looks like some .h files still need to be included. Care to fix >> these up? > > I've now done this, let's see if it catches all of the odd arch > issues... Thanks for this Greg (I was away all weekend so didn't get a chance to send patches before you got it done). Thanks, NeilBrown signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
