* undefined reference to `__divdi3'
From: valdis.kletnieks at vt.edu @ 2018-07-23 17:41 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <20180722121820.GA15392@himanshu-Vostro-3559>
On Sun, 22 Jul 2018 17:48:21 +0530, Himanshu Jha said:
> I am currently working on my GSoC project and while testing through
> 0-day test service, I hit the following error:
> 424 static u32 bme680_compensate_gas(struct bme680_data *data, u16 gas_res_adc,
> 425 u8 gas_range)
> 426 {
> 427 struct bme680_calib *calib = &data->bme680;
> 428 s64 var1;
> 429 u64 var2;
> 430 s64 var3;
> 431 u32 calc_gas_res;
> 432
> 433 /* Look up table 1 for the possible gas range values */
> 434 u32 lookupTable1[16] = {2147483647u, 2147483647u, 2147483647u,
> 435 2147483647u, 2147483647u, 2126008810u,
> 436 2147483647u, 2130303777u, 2147483647u,
> 437 2147483647u, 2143188679u, 2136746228u,
> 438 2147483647u, 2126008810u, 2147483647u,
> 439 2147483647u};
As an aside, making this a 'static u32' will get rid of the mess of mov and movabs
instructions each time. 'static const u32' would be even better, as then the
compiler knows it can optimize assuming it never changes any of the values...
(In addition, with all that initialization out of the picture, figuring out
which assembler code does what should be easier...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180723/27536e06/attachment.sig>
^ permalink raw reply
* Re: [PATCH 2/9] vscode: hard-code a couple defines
From: Jonathan Nieder @ 2018-07-23 17:41 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <3770bd855c6f3e69acfe418ea7fe5b40454e4dfb.1532353966.git.gitgitgadget@gmail.com>
Hi,
Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines
> are passed to GCC *only* when compiling specific files, such as git.o.
>
> Let's just hard-code them into the script for the time being.
Could we move these to ALL_CFLAGS? Is there any downside other than
increased rebuilds when options change?
Thanks,
Jonathan
^ permalink raw reply
* Re: Incorrect name of PCM
From: Takashi Iwai @ 2018-07-23 17:40 UTC (permalink / raw)
To: Christopher Head; +Cc: alsa-devel
In-Reply-To: <56F88318-0461-4587-AE9D-A885BB121ADC@chead.ca>
On Mon, 23 Jul 2018 18:21:59 +0200,
Christopher Head wrote:
>
> On July 23, 2018 9:15:59 AM PDT, Takashi Iwai <tiwai@suse.de> wrote:
> >Just ignore this entry. alsa-lib tries to parse the all possible
> >outputs that are provided from the kernel interface. Due to
> >historical reasons, this digital output might be either SPDIF or HDMI,
> >and alsa-lib has no knowledge to distinguish easily, hence both spdif
> >and hdmi device names are provided equally for such a case.
>
> Not here, they aren’t. There is no PCM named “spdif” at all: it isn’t in the list, and if I type it, I can’t play to it for a reason that looks a lot like it doesn’t exist.
OK, then another possibility is a BIOS bug. BIOS declares the pin as
HDMI incorrectly although it's a SPDIF.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v10 3/7] Bluetooth: btqca: Redefine qca_uart_setup() to generic function.
From: Matthias Kaehlcke @ 2018-07-23 17:40 UTC (permalink / raw)
To: Balakrishna Godavarthi
Cc: marcel, johan.hedberg, linux-kernel, devicetree, linux-bluetooth,
thierry.escande, rtatiya, hemantg, linux-arm-msm
In-Reply-To: <20180720133243.6851-4-bgodavar@codeaurora.org>
On Fri, Jul 20, 2018 at 07:02:39PM +0530, Balakrishna Godavarthi wrote:
> Redefinition of qca_uart_setup will help future Qualcomm Bluetooth
> SoC, to use the same function instead of duplicating the function.
> Added new arguments soc_type and soc_ver to the functions.
>
> These arguments will help to decide type of firmware files
> to be loaded into Bluetooth chip.
> soc_type holds the Bluetooth chip connected to APPS processor.
> soc_ver holds the Bluetooth chip version.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> drivers/bluetooth/btqca.c | 20 +++++++-------------
> drivers/bluetooth/btqca.h | 13 +++++++++++--
> drivers/bluetooth/hci_qca.c | 10 +++++++++-
> 3 files changed, 27 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index c5cf9cab438a..b556710ee1bd 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -85,6 +85,9 @@ int qca_read_soc_version(struct hci_dev *hdev, u32 *soc_version)
> out:
> kfree_skb(skb);
>
> + if (err < 0 || *soc_version == 0)
> + bt_dev_err(hdev, "QCA Failed to get version (%d)", err);
You also have to set 'err' if soc_version is 0, so the caller can skip
the check for soc_version == 0
I'd suggest:
// directly after setting soc_version
if (*soc_version == 0)
err = -EILSEQ; // or should it be a different error code?
...
if (err)
bt_dev_err(hdev, "QCA Failed to get version (%d)", err);
You could also limit the error log to the 'if (*soc_version == 0)'
branch, for all other errors there will already be a more specific log
entry.
> +
> return err;
> }
Cheers
Matthias
^ permalink raw reply
* [Intel-wired-lan] [RFC 00/13] Bug fixes for ice
From: Shannon Nelson @ 2018-07-23 17:39 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <e2f9442bda931f8e813c9b4f9841ff0c404eafbe.camel@intel.com>
On 7/23/2018 10:39 AM, Jeff Kirsher wrote:
> On Mon, 2018-07-23 at 09:57 -0700, Shannon Nelson wrote:
>> On 7/20/2018 12:54 PM, Anirudh Venkataramanan wrote:
>>> This patch set fixes multiple bugs for the ice driver.
>>
>> Since the ice driver original patches are still under review and not
>> yet
>> upstream, why are these bug fixes not rolled into the original patch
>> set? Put these into the initial patch set and have a clearer
>> upstream
>> submission.
>
> Ah, the ice driver was submitted (and accepted) into 4.17 kernel. Not
> sure why you think the initial driver submission is still under review
> and not upstream. :-)
>
Hmmm... perhaps I'm confusing this with igc early this Monday morning?
My apologies. I'll go refresh my coffee.
sln
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 32/40] elf: Add nanoMIPS specific variations in ELF header fields
From: Aleksandar Markovic @ 2018-07-23 17:39 UTC (permalink / raw)
To: Richard Henderson, Stefan Markovic, qemu-devel@nongnu.org
Cc: laurent@vivier.eu, riku.voipio@iki.fi,
philippe.mathieu.daude@gmail.com, aurelien@aurel32.net,
Stefan Markovic, Petar Jovanovic, Paul Burton
In-Reply-To: <8d1a14bf-8cc5-91cb-5aed-cefeb8d97962@linaro.org>
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Monday, July 23, 2018 6:59 PM
> On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> > From: Aleksandar Markovic <amarkovic@wavecomp.com>
> >
> > Add nanoMIPS-related values in ELF header fields as specified in
> > nanoMIPS' "ELF ABI Supplement".
> >
> > Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> > Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> > ---
> > include/elf.h | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
>
> None of these values have made it upstream to binutils yet,
> so I can't double-check them. However,
>
> Acked-by: Richard Henderson <richard.henderson@linaro.org>
>
>
> r~
Hi, Richard.
True, binutils headers were not updated with these ELF-related values. However, there is a publicly-available document at https://codescape.mips.com/components/toolchain/nanomips/2018.04-02/releasenotes.html that should be the source of information for binutils headers, or any other related header in similar tools. Specifically, see Section 5.1 of that document.
Regards,
Aleksandar
^ permalink raw reply
* [Intel-wired-lan] [RFC 00/13] Bug fixes for ice
From: Jeff Kirsher @ 2018-07-23 17:39 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <b28588b5-6024-8e90-18b7-bade5264f885@oracle.com>
On Mon, 2018-07-23 at 09:57 -0700, Shannon Nelson wrote:
> On 7/20/2018 12:54 PM, Anirudh Venkataramanan wrote:
> > This patch set fixes multiple bugs for the ice driver.
>
> Since the ice driver original patches are still under review and not
> yet
> upstream, why are these bug fixes not rolled into the original patch
> set? Put these into the initial patch set and have a clearer
> upstream
> submission.
Ah, the ice driver was submitted (and accepted) into 4.17 kernel. Not
sure why you think the initial driver submission is still under review
and not upstream. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20180723/7dc02b1d/attachment.asc>
^ permalink raw reply
* Re: KASAN: use-after-free Read in rds_cong_queue_updates (2)
From: Santosh Shilimkar @ 2018-07-23 17:38 UTC (permalink / raw)
To: syzbot, davem, linux-kernel, linux-rdma, netdev, rds-devel,
syzkaller-bugs
In-Reply-To: <000000000000cdb5450571adfe40@google.com>
On 7/23/2018 10:30 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: fcf4793e278e tls: check RCV_SHUTDOWN in tls_wait_data
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1738cb2c400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c0bdc4175608181c
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=470ae97a39f16146af45
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+470ae97a39f16146af45@syzkaller.appspotmail.com
>
dup: syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com
^ permalink raw reply
* Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3
From: Paul Burton @ 2018-07-23 17:37 UTC (permalink / raw)
To: 陈华才
Cc: Ralf Baechle, James Hogan, linux-mips, Fuxin Zhang, wuzhangjin,
stable, Alan Stern, Andrea Parri, Will Deacon, Peter Zijlstra,
Boqun Feng, Nicholas Piggin, David Howells, Jade Alglave,
Luc Maranget, Paul E. McKenney, Akira Yokosawa, LKML
In-Reply-To: <tencent_49EB501232FD02AC001F9E93@qq.com>
Hi Huacai,
On Sat, Jul 21, 2018 at 09:35:59AM +0800, 陈华才 wrote:
> SFB can improve the memory bandwidth as much as 30%, and we are
> planning to enable SFB by default. So, we want to control cpu_relax()
> under CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT.
OK, applied to mips-next for 4.19 with changes to the commit message &
comment.
Thanks,
Paul
^ permalink raw reply
* Re: rte_mbuf library likely()/unlikely()
From: Stephen Hemminger @ 2018-07-23 17:37 UTC (permalink / raw)
To: Morten Brørup; +Cc: Olivier Matz, dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B421EE@smartserver.smartshare.dk>
On Mon, 23 Jul 2018 15:53:42 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:
> Hi Olivier,
>
>
>
> I noticed that __rte_pktmbuf_read() could do with an unlikely(), so I went through the entire library. Here are my suggested modifications.
>
>
>
>
>
> diff -bu rte_mbuf.c.orig rte_mbuf.c
>
> --- rte_mbuf.c.orig 2018-07-23 15:13:22.000000000 +0200
>
> +++ rte_mbuf.c 2018-07-23 15:32:53.000000000 +0200
>
> @@ -173,19 +173,19 @@
>
> {
>
> unsigned int nb_segs, pkt_len;
>
>
>
> - if (m == NULL)
>
> + if (unlikely(m == NULL))
>
> rte_panic("mbuf is NULL\n");
>
>
Adding is unlikely is not necessary since rte_panic is marked with cold attribute
which has the same effect.
^ permalink raw reply
* [Intel-wired-lan] [PATCH 13/13] ice: Change struct members from bool to u8
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Recent versions of checkpatch have a new warning based on a documented
preference of Linus to not use bool in structures due to wasted space and
the size of bool is implementation dependent. For more information, see
the email thread at https://lkml.org/lkml/2017/11/21/384.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice.h | 8 ++++----
drivers/net/ethernet/intel/ice/ice_switch.h | 6 +++---
drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +-
drivers/net/ethernet/intel/ice/ice_type.h | 16 ++++++++--------
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index ed071ea75f20..868f4a1d0f72 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -196,9 +196,9 @@ struct ice_vsi {
struct list_head tmp_sync_list; /* MAC filters to be synced */
struct list_head tmp_unsync_list; /* MAC filters to be unsynced */
- bool irqs_ready;
- bool current_isup; /* Sync 'link up' logging */
- bool stat_offsets_loaded;
+ u8 irqs_ready;
+ u8 current_isup; /* Sync 'link up' logging */
+ u8 stat_offsets_loaded;
/* queue information */
u8 tx_mapping_mode; /* ICE_MAP_MODE_[CONTIG|SCATTER] */
@@ -269,7 +269,7 @@ struct ice_pf {
struct ice_hw_port_stats stats;
struct ice_hw_port_stats stats_prev;
struct ice_hw hw;
- bool stat_prev_loaded; /* has previous stats been loaded */
+ u8 stat_prev_loaded; /* has previous stats been loaded */
char int_name[ICE_INT_NAME_STR_LEN];
};
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethernet/intel/ice/ice_switch.h
index 6f4a0d159dbf..9b8ec128ee31 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.h
+++ b/drivers/net/ethernet/intel/ice/ice_switch.h
@@ -17,7 +17,7 @@ struct ice_vsi_ctx {
u16 vsis_unallocated;
u16 flags;
struct ice_aqc_vsi_props info;
- bool alloc_from_pool;
+ u8 alloc_from_pool;
};
enum ice_sw_fwd_act_type {
@@ -94,8 +94,8 @@ struct ice_fltr_info {
u8 qgrp_size;
/* Rule creations populate these indicators basing on the switch type */
- bool lb_en; /* Indicate if packet can be looped back */
- bool lan_en; /* Indicate if packet can be forwarded to the uplink */
+ u8 lb_en; /* Indicate if packet can be looped back */
+ u8 lan_en; /* Indicate if packet can be forwarded to the uplink */
};
/* Bookkeeping structure to hold bitmap of VSIs corresponding to VSI list id */
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.h b/drivers/net/ethernet/intel/ice/ice_txrx.h
index 567067b650c4..31bc998fe200 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.h
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.h
@@ -143,7 +143,7 @@ struct ice_ring {
u16 next_to_use;
u16 next_to_clean;
- bool ring_active; /* is ring online or not */
+ u8 ring_active; /* is ring online or not */
/* stats structs */
struct ice_q_stats stats;
diff --git a/drivers/net/ethernet/intel/ice/ice_type.h b/drivers/net/ethernet/intel/ice/ice_type.h
index 99c8a9a71b5e..97c366e0ca59 100644
--- a/drivers/net/ethernet/intel/ice/ice_type.h
+++ b/drivers/net/ethernet/intel/ice/ice_type.h
@@ -83,7 +83,7 @@ struct ice_link_status {
u64 phy_type_low;
u16 max_frame_size;
u16 link_speed;
- bool lse_ena; /* Link Status Event notification */
+ u8 lse_ena; /* Link Status Event notification */
u8 link_info;
u8 an_info;
u8 ext_info;
@@ -101,7 +101,7 @@ struct ice_phy_info {
struct ice_link_status link_info_old;
u64 phy_type_low;
enum ice_media_type media_type;
- bool get_link_info;
+ u8 get_link_info;
};
/* Common HW capabilities for SW use */
@@ -167,7 +167,7 @@ struct ice_nvm_info {
u32 oem_ver; /* OEM version info */
u16 sr_words; /* Shadow RAM size in words */
u16 ver; /* NVM package version */
- bool blank_nvm_mode; /* is NVM empty (no FW present) */
+ u8 blank_nvm_mode; /* is NVM empty (no FW present) */
};
/* Max number of port to queue branches w.r.t topology */
@@ -181,7 +181,7 @@ struct ice_sched_node {
struct ice_aqc_txsched_elem_data info;
u32 agg_id; /* aggregator group id */
u16 vsi_id;
- bool in_use; /* suspended or in use */
+ u8 in_use; /* suspended or in use */
u8 tx_sched_layer; /* Logical Layer (1-9) */
u8 num_children;
u8 tc_num;
@@ -218,7 +218,7 @@ struct ice_sched_vsi_info {
struct ice_sched_tx_policy {
u16 max_num_vsis;
u8 max_num_lan_qs_per_tc[ICE_MAX_TRAFFIC_CLASS];
- bool rdma_ena;
+ u8 rdma_ena;
};
struct ice_port_info {
@@ -243,7 +243,7 @@ struct ice_port_info {
struct list_head agg_list; /* lists all aggregator */
u8 lport;
#define ICE_LPORT_MASK 0xff
- bool is_vf;
+ u8 is_vf;
};
struct ice_switch_info {
@@ -287,7 +287,7 @@ struct ice_hw {
u8 max_cgds;
u8 sw_entry_point_layer;
- bool evb_veb; /* true for VEB, false for VEPA */
+ u8 evb_veb; /* true for VEB, false for VEPA */
struct ice_bus_info bus;
struct ice_nvm_info nvm;
struct ice_hw_dev_caps dev_caps; /* device capabilities */
@@ -318,7 +318,7 @@ struct ice_hw {
u8 itr_gran_100;
u8 itr_gran_50;
u8 itr_gran_25;
- bool ucast_shared; /* true if VSIs can share unicast addr */
+ u8 ucast_shared; /* true if VSIs can share unicast addr */
};
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 12/13] ice: Fix potential return of uninitialized value
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
In ice_vsi_setup_[tx|rx]_rings, err is uninitialized which can result in
a garbage value return to the caller. Fix that.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index e5b8eb0c4581..3782569b450a 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -4887,7 +4887,7 @@ int ice_down(struct ice_vsi *vsi)
*/
static int ice_vsi_setup_tx_rings(struct ice_vsi *vsi)
{
- int i, err;
+ int i, err = 0;
if (!vsi->num_txq) {
dev_err(&vsi->back->pdev->dev, "VSI %d has 0 Tx queues\n",
@@ -4912,7 +4912,7 @@ static int ice_vsi_setup_tx_rings(struct ice_vsi *vsi)
*/
static int ice_vsi_setup_rx_rings(struct ice_vsi *vsi)
{
- int i, err;
+ int i, err = 0;
if (!vsi->num_rxq) {
dev_err(&vsi->back->pdev->dev, "VSI %d has 0 Rx queues\n",
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 11/13] ice: Fix couple of null pointer dereference issues
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
When ice_ena_msix_range() fails to reserve vectors, a devm_kfree() warning
was seen in the error flow path. So check pf->irq_tracker before use in
ice_clear_interrupt_scheme().
In ice_vsi_cfg(), check vsi->netdev before use.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index bcd39654ab4b..e5b8eb0c4581 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3259,8 +3259,10 @@ static void ice_clear_interrupt_scheme(struct ice_pf *pf)
if (test_bit(ICE_FLAG_MSIX_ENA, pf->flags))
ice_dis_msix(pf);
- devm_kfree(&pf->pdev->dev, pf->irq_tracker);
- pf->irq_tracker = NULL;
+ if (pf->irq_tracker) {
+ devm_kfree(&pf->pdev->dev, pf->irq_tracker);
+ pf->irq_tracker = NULL;
+ }
}
/**
@@ -4114,11 +4116,12 @@ static int ice_vsi_cfg(struct ice_vsi *vsi)
{
int err;
- ice_set_rx_mode(vsi->netdev);
-
- err = ice_restore_vlan(vsi);
- if (err)
- return err;
+ if (vsi->netdev) {
+ ice_set_rx_mode(vsi->netdev);
+ err = ice_restore_vlan(vsi);
+ if (err)
+ return err;
+ }
err = ice_vsi_cfg_txqs(vsi);
if (!err)
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 10/13] ice: Update to interrupts enabled in OICR
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Remove the following interrupt causes that are not applicable or not
handled:
- PFINT_OICR_HLP_RDY_M
- PFINT_OICR_CPM_RDY_M
- PFINT_OICR_GPIO_M
- PFINT_OICR_STORM_DETECT_M
Add the following interrupt cause that's actually handled in ice_misc_intr:
- PFINT_OICR_PE_CRITERR_M
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Removed defines from ice_hw_autogen.h]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 8 --------
drivers/net/ethernet/intel/ice/ice_main.c | 9 +++------
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_hw_autogen.h b/drivers/net/ethernet/intel/ice/ice_hw_autogen.h
index 499904874b3f..6076fc87df9d 100644
--- a/drivers/net/ethernet/intel/ice/ice_hw_autogen.h
+++ b/drivers/net/ethernet/intel/ice/ice_hw_autogen.h
@@ -121,10 +121,6 @@
#define PFINT_FW_CTL_CAUSE_ENA_S 30
#define PFINT_FW_CTL_CAUSE_ENA_M BIT(PFINT_FW_CTL_CAUSE_ENA_S)
#define PFINT_OICR 0x0016CA00
-#define PFINT_OICR_HLP_RDY_S 14
-#define PFINT_OICR_HLP_RDY_M BIT(PFINT_OICR_HLP_RDY_S)
-#define PFINT_OICR_CPM_RDY_S 15
-#define PFINT_OICR_CPM_RDY_M BIT(PFINT_OICR_CPM_RDY_S)
#define PFINT_OICR_ECC_ERR_S 16
#define PFINT_OICR_ECC_ERR_M BIT(PFINT_OICR_ECC_ERR_S)
#define PFINT_OICR_MAL_DETECT_S 19
@@ -133,10 +129,6 @@
#define PFINT_OICR_GRST_M BIT(PFINT_OICR_GRST_S)
#define PFINT_OICR_PCI_EXCEPTION_S 21
#define PFINT_OICR_PCI_EXCEPTION_M BIT(PFINT_OICR_PCI_EXCEPTION_S)
-#define PFINT_OICR_GPIO_S 22
-#define PFINT_OICR_GPIO_M BIT(PFINT_OICR_GPIO_S)
-#define PFINT_OICR_STORM_DETECT_S 24
-#define PFINT_OICR_STORM_DETECT_M BIT(PFINT_OICR_STORM_DETECT_S)
#define PFINT_OICR_HMC_ERR_S 26
#define PFINT_OICR_HMC_ERR_M BIT(PFINT_OICR_HMC_ERR_S)
#define PFINT_OICR_PE_CRITERR_S 28
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 71cc5b6e6237..bcd39654ab4b 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1702,15 +1702,12 @@ static void ice_ena_misc_vector(struct ice_pf *pf)
wr32(hw, PFINT_OICR_ENA, 0); /* disable all */
rd32(hw, PFINT_OICR); /* read to clear */
- val = (PFINT_OICR_HLP_RDY_M |
- PFINT_OICR_CPM_RDY_M |
- PFINT_OICR_ECC_ERR_M |
+ val = (PFINT_OICR_ECC_ERR_M |
PFINT_OICR_MAL_DETECT_M |
PFINT_OICR_GRST_M |
PFINT_OICR_PCI_EXCEPTION_M |
- PFINT_OICR_GPIO_M |
- PFINT_OICR_STORM_DETECT_M |
- PFINT_OICR_HMC_ERR_M);
+ PFINT_OICR_HMC_ERR_M |
+ PFINT_OICR_PE_CRITERR_M);
wr32(hw, PFINT_OICR_ENA, val);
--
2.14.3
^ permalink raw reply related
* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: Dave Watson @ 2018-07-23 16:35 UTC (permalink / raw)
To: David Miller; +Cc: vakul.garg, netdev, borisp, aviadye, Doron Roberts-Kedes
In-Reply-To: <20180721.192532.520509909556885779.davem@davemloft.net>
On 07/21/18 07:25 PM, David Miller wrote:
> From: Vakul Garg <vakul.garg@nxp.com>
> Date: Thu, 19 Jul 2018 21:56:13 +0530
>
> > In function decrypt_skb(), array allocation in case when sgout is NULL
> > is unnecessary. Instead, local variable sgin_arr[] can be used.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>
> Hmmm...
>
> Dave, can you take a look at this? Do you think there might have
> been a reason you felt that you needed to dynamically allocate
> the scatterlists when you COW and skb and do in-place decryption?
>
> I guess this change is ok, nsg can only get smaller when the SKB
> is COW'd.
>
> > memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
> > if (!sgout) {
> > nsg = skb_cow_data(skb, 0, &unused) + 1;
> > - sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
> > sgout = sgin;
> > }
I don't think this patch is safe as-is. sgin_arr is a stack array of
size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
it walks the whole chain of skbs from skb->next, and can return any
number of segments. Therefore we need to heap allocate. I think I
copied the IPSEC code here.
For perf though, we could use the stack array if skb_cow_data returns
<= MAX_SKB_FRAGS.
This code is slightly confusing though, since we don't heap allocate
in the zerocopy case - what happens is that skb_to_sgvec returns
-EMSGSIZE, and we fall back to the non-zerocopy case, and return again
to this function, where we then hit the skb_cow_data path and heap
allocate.
^ permalink raw reply
* [Intel-wired-lan] [PATCH 09/13] ice: Set VLAN flags correctly
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
Set the ICE_AQ_VSI_PVLAN_MODE_ALL bit to allow the driver to add a VLAN
tag to all packets it sends.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 586c6e615a98..71cc5b6e6237 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3779,6 +3779,9 @@ static int ice_vsi_manage_vlan_stripping(struct ice_vsi *vsi, bool ena)
ctxt.info.port_vlan_flags = ICE_AQ_VSI_PVLAN_EMOD_NOTHING;
}
+ /* Allow all packets untagged/tagged */
+ ctxt.info.port_vlan_flags |= ICE_AQ_VSI_PVLAN_MODE_ALL;
+
ctxt.info.valid_sections = cpu_to_le16(ICE_AQ_VSI_PROP_VLAN_VALID);
ctxt.vsi_num = vsi->vsi_num;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 08/13] ice: Don't explicitly set port_vlan_bits to 0
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
This patch fixes the following smatch warning originally reported by
Dan Carpenter:
ice_set_dflt_vsi_ctx() warn: odd binop '0x0 & 0x18'
In ice_set_dflt_vsi_ctx() we are currently doing logic that is intended
to explicitly clear bits 3 and 4 for port_vlan_flags. Clearing these
bits results in legacy behavior (showing VLAN, DEI, and UP) in the
descriptors. The issue was this was reporting the Smatch error shown
below. To fix this remove this logic because the port_vlan_flags field
is set to 0 initially by memset so by default we have the correct legacy
behavior for bits 3 and 4. A comment was added above where we set
port_vlan_flags in ice_set_dflt_vsi_ctx() to note that this is the
desired behavior.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index feeca75912ec..586c6e615a98 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1367,14 +1367,13 @@ static void ice_set_dflt_vsi_ctx(struct ice_vsi_ctx *ctxt)
ctxt->info.sw_flags = ICE_AQ_VSI_SW_FLAG_SRC_PRUNE;
/* Traffic from VSI can be sent to LAN */
ctxt->info.sw_flags2 = ICE_AQ_VSI_SW_FLAG_LAN_ENA;
- /* Allow all packets untagged/tagged */
+ /* By default bits 3 and 4 in port_vlan_flags are 0's which results in
+ * legacy behavior (show VLAN, DEI, and UP) in descriptor. Also, allow
+ * all packets untagged/tagged.
+ */
ctxt->info.port_vlan_flags = ((ICE_AQ_VSI_PVLAN_MODE_ALL &
ICE_AQ_VSI_PVLAN_MODE_M) >>
ICE_AQ_VSI_PVLAN_MODE_S);
- /* Show VLAN/UP from packets in Rx descriptors */
- ctxt->info.port_vlan_flags |= ((ICE_AQ_VSI_PVLAN_EMOD_STR_BOTH &
- ICE_AQ_VSI_PVLAN_EMOD_M) >>
- ICE_AQ_VSI_PVLAN_EMOD_S);
/* Have 1:1 UP mapping for both ingress/egress tables */
table |= ICE_UP_TABLE_TRANSLATE(0, 0);
table |= ICE_UP_TABLE_TRANSLATE(1, 1);
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 07/13] ice: Use order_base_2 to calculate higher power of 2
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Currently, we use a combination of ilog2 and is_power_of_2() to
calculate the next power of 2 for the qcount. This appears to be causing
a warning on some combinations of GCC and the Linux kernel:
MODPOST 1 modules
WARNING: "____ilog2_NaN" [ice.ko] undefined!
This appears to because because GCC realizes that qcount could be zero
in some circumstances and thus attempts to link against the
intentionally undefined ___ilog2_NaN function.
The order_base_2 function is intentionally defined to return 0 when
passed 0 as an argument, and thus will be safe to use here.
This not only fixes the warning but makes the resulting code slightly
cleaner, and is really what we should have used originally.
Also update the comment to make it more clear that we are rounding up,
not just incrementing the ilog2 of qcount unconditionally.
Without this patch, we get warnings when building against the upstream
kernel.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> minor cleanup for upstream submission]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 81b04e1d7ea2..feeca75912ec 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1313,11 +1313,8 @@ static void ice_vsi_setup_q_map(struct ice_vsi *vsi, struct ice_vsi_ctx *ctxt)
qcount = numq_tc;
}
- /* find higher power-of-2 of qcount */
- pow = ilog2(qcount);
-
- if (!is_power_of_2(qcount))
- pow++;
+ /* find the (rounded up) power-of-2 of qcount */
+ pow = order_base_2(qcount);
for (i = 0; i < ICE_MAX_TRAFFIC_CLASS; i++) {
if (!(vsi->tc_cfg.ena_tc & BIT(i))) {
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 06/13] ice: Fix bugs in control queue processing
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
This patch is a consolidation of multiple bug fixes for control queue
processing.
1) In ice_clean_adminq_subtask() remove unnecessary reads/writes to
registers. The bits PFINT_FW_CTL, PFINT_MBX_CTL and PFINT_SB_CTL
are not set when an interrupt arrives, which means that clearing them
again can be omitted.
2) Get an accurate value in "pending" by re-reading the control queue
head register from the hardware.
3) Fix a corner case involving lost control queue messages by checking
for new control messages (using ice_ctrlq_pending) before exiting the
cleanup routine.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_controlq.c | 5 ++++-
drivers/net/ethernet/intel/ice/ice_main.c | 26 ++++++++++++++++++++++----
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c b/drivers/net/ethernet/intel/ice/ice_controlq.c
index c064416080e7..62be72fdc8f3 100644
--- a/drivers/net/ethernet/intel/ice/ice_controlq.c
+++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
@@ -1065,8 +1065,11 @@ ice_clean_rq_elem(struct ice_hw *hw, struct ice_ctl_q_info *cq,
clean_rq_elem_out:
/* Set pending if needed, unlock and return */
- if (pending)
+ if (pending) {
+ /* re-read HW head to calculate actual pending messages */
+ ntu = (u16)(rd32(hw, cq->rq.head) & cq->rq.head_mask);
*pending = (u16)((ntc > ntu ? cq->rq.count : 0) + (ntu - ntc));
+ }
clean_rq_elem_err:
mutex_unlock(&cq->rq_lock);
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 450911345144..81b04e1d7ea2 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -916,6 +916,21 @@ static int __ice_clean_ctrlq(struct ice_pf *pf, enum ice_ctl_q q_type)
return pending && (i == ICE_DFLT_IRQ_WORK);
}
+/**
+ * ice_ctrlq_pending - check if there is a difference between ntc and ntu
+ * @hw: pointer to hardware info
+ * @cq: control queue information
+ *
+ * returns true if there are pending messages in a queue, false if there aren't
+ */
+static bool ice_ctrlq_pending(struct ice_hw *hw, struct ice_ctl_q_info *cq)
+{
+ u16 ntu;
+
+ ntu = (u16)(rd32(hw, cq->rq.head) & cq->rq.head_mask);
+ return cq->rq.next_to_clean != ntu;
+}
+
/**
* ice_clean_adminq_subtask - clean the AdminQ rings
* @pf: board private structure
@@ -923,7 +938,6 @@ static int __ice_clean_ctrlq(struct ice_pf *pf, enum ice_ctl_q q_type)
static void ice_clean_adminq_subtask(struct ice_pf *pf)
{
struct ice_hw *hw = &pf->hw;
- u32 val;
if (!test_bit(__ICE_ADMINQ_EVENT_PENDING, pf->state))
return;
@@ -933,9 +947,13 @@ static void ice_clean_adminq_subtask(struct ice_pf *pf)
clear_bit(__ICE_ADMINQ_EVENT_PENDING, pf->state);
- /* re-enable Admin queue interrupt causes */
- val = rd32(hw, PFINT_FW_CTL);
- wr32(hw, PFINT_FW_CTL, (val | PFINT_FW_CTL_CAUSE_ENA_M));
+ /* There might be a situation where new messages arrive to a control
+ * queue between processing the last message and clearing the
+ * EVENT_PENDING bit. So before exiting, check queue head again (using
+ * ice_ctrlq_pending) and process new messages if any.
+ */
+ if (ice_ctrlq_pending(hw, &hw->adminq))
+ __ice_clean_ctrlq(pf, ICE_CTL_Q_ADMIN);
ice_flush(hw);
}
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 05/13] ice: Clean control queues only when they are initialized
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Preethi Banala <preethi.banala@intel.com>
Clean control queues only when they are initialized. One of the ways to
validate if the basic initialization is done is by checking value of
cq->sq.head and cq->rq.head variables that specify the register address.
This patch adds a check to avoid NULL pointer dereference crash when tried
to shutdown uninitialized control queue.
Signed-off-by: Preethi Banala <preethi.banala@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_controlq.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c b/drivers/net/ethernet/intel/ice/ice_controlq.c
index 7c511f144ed6..c064416080e7 100644
--- a/drivers/net/ethernet/intel/ice/ice_controlq.c
+++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
@@ -597,10 +597,14 @@ static enum ice_status ice_init_check_adminq(struct ice_hw *hw)
return 0;
init_ctrlq_free_rq:
- ice_shutdown_rq(hw, cq);
- ice_shutdown_sq(hw, cq);
- mutex_destroy(&cq->sq_lock);
- mutex_destroy(&cq->rq_lock);
+ if (cq->rq.head) {
+ ice_shutdown_rq(hw, cq);
+ mutex_destroy(&cq->rq_lock);
+ }
+ if (cq->sq.head) {
+ ice_shutdown_sq(hw, cq);
+ mutex_destroy(&cq->sq_lock);
+ }
return status;
}
@@ -706,10 +710,14 @@ static void ice_shutdown_ctrlq(struct ice_hw *hw, enum ice_ctl_q q_type)
return;
}
- ice_shutdown_sq(hw, cq);
- ice_shutdown_rq(hw, cq);
- mutex_destroy(&cq->sq_lock);
- mutex_destroy(&cq->rq_lock);
+ if (cq->sq.head) {
+ ice_shutdown_sq(hw, cq);
+ mutex_destroy(&cq->sq_lock);
+ }
+ if (cq->rq.head) {
+ ice_shutdown_rq(hw, cq);
+ mutex_destroy(&cq->rq_lock);
+ }
}
/**
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 04/13] ice: Report stats for allocated queues via ethtool stats
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
It is not safe to have the string table for statistics change order or
size over the lifetime of a given netdevice. This is because of the
nature of the 3-step process for obtaining stats. First, userspace
performs a request for the size of the strings table. Second it performs
a separate request for the strings themselves, after allocating space
for the table. Third, it requests the stats themselves, also allocating
space for the table.
If the size decreased, there is potential to see garbage data or stats
values. In the worst case, we could potentially see stats values become
mis-aligned with their strings, so that it looks like a statistic is
being reported differently than it actually is.
Even worse, if the size increased, there is potential that the strings
table or stats table was not allocated large enough and the stats code
could access and write to memory it should not, potentially resulting in
undefined behavior and system crashes.
It isn't even safe if the size always changes under the RTNL lock. This
is because the calls take place over multiple userspace commands, so it
is not possible to hold the RTNL lock for the entire duration of
obtaining strings and stats. Further, not all consumers of the ethtool
API are the userspace ethtool program, and it is possible that one
assumes the strings will not change (valid under the current contract),
and thus only requests the stats values when requesting stats in a loop.
Finally, it's not possible in the general case to detect when the size
changes, because it is quite possible that one value which could impact
the stat size increased, while another decreased. This would result in
the same total number of stats, but reordering them so that stats no
longer line up with the strings they belong to. Since only size changes
aren't enough, we would need some sort of hash or token to determine
when the strings no longer match. This would require extending the
ethtool stats commands, but there is no more space in the relevant
structures.
The real solution to resolve this would be to add a completely new API
for stats, probably over netlink.
In the ice driver, the only thing impacting the stats that is not
constant is the number of queues. Instead of reporting stats for each
used queue, report stats for each allocated queue. We do not change the
number of queues allocated for a given netdevice, as we pass this into
the alloc_etherdev_mq() function to set the num_tx_queues and
num_rx_queues.
This resolves the potential bugs at the slight cost of displaying many
queue statistics which will not be activated.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice.h | 7 ++++
drivers/net/ethernet/intel/ice/ice_ethtool.c | 52 +++++++++++++++++++++-------
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index d8b5fff581e7..ed071ea75f20 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -89,6 +89,13 @@ extern const char ice_drv_ver[];
#define ice_for_each_rxq(vsi, i) \
for ((i) = 0; (i) < (vsi)->num_rxq; (i)++)
+/* Macros for each allocated tx/rx ring whether used or not in a VSI */
+#define ice_for_each_alloc_txq(vsi, i) \
+ for ((i) = 0; (i) < (vsi)->alloc_txq; (i)++)
+
+#define ice_for_each_alloc_rxq(vsi, i) \
+ for ((i) = 0; (i) < (vsi)->alloc_rxq; (i)++)
+
struct ice_tc_info {
u16 qoffset;
u16 qcount;
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 1db304c01d10..807b683a5707 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -26,7 +26,7 @@ static int ice_q_stats_len(struct net_device *netdev)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
- return ((np->vsi->num_txq + np->vsi->num_rxq) *
+ return ((np->vsi->alloc_txq + np->vsi->alloc_rxq) *
(sizeof(struct ice_q_stats) / sizeof(u64)));
}
@@ -218,7 +218,7 @@ static void ice_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
p += ETH_GSTRING_LEN;
}
- ice_for_each_txq(vsi, i) {
+ ice_for_each_alloc_txq(vsi, i) {
snprintf(p, ETH_GSTRING_LEN,
"tx-queue-%u.tx_packets", i);
p += ETH_GSTRING_LEN;
@@ -226,7 +226,7 @@ static void ice_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
p += ETH_GSTRING_LEN;
}
- ice_for_each_rxq(vsi, i) {
+ ice_for_each_alloc_rxq(vsi, i) {
snprintf(p, ETH_GSTRING_LEN,
"rx-queue-%u.rx_packets", i);
p += ETH_GSTRING_LEN;
@@ -253,6 +253,24 @@ static int ice_get_sset_count(struct net_device *netdev, int sset)
{
switch (sset) {
case ETH_SS_STATS:
+ /* The number (and order) of strings reported *must* remain
+ * constant for a given netdevice. This function must not
+ * report a different number based on run time parameters
+ * (such as the number of queues in use, or the setting of
+ * a private ethtool flag). This is due to the nature of the
+ * ethtool stats API.
+ *
+ * Userspace programs such as ethtool must make 3 separate
+ * ioctl requests, one for size, one for the strings, and
+ * finally one for the stats. Since these cross into
+ * userspace, changes to the number or size could result in
+ * undefined memory access or incorrect string<->value
+ * correlations for statistics.
+ *
+ * Even if it appears to be safe, changes to the size or
+ * order of strings will suffer from race conditions and are
+ * not safe.
+ */
return ICE_ALL_STATS_LEN(netdev);
default:
return -EOPNOTSUPP;
@@ -280,18 +298,26 @@ ice_get_ethtool_stats(struct net_device *netdev,
/* populate per queue stats */
rcu_read_lock();
- ice_for_each_txq(vsi, j) {
+ ice_for_each_alloc_txq(vsi, j) {
ring = READ_ONCE(vsi->tx_rings[j]);
- if (!ring)
- continue;
- data[i++] = ring->stats.pkts;
- data[i++] = ring->stats.bytes;
+ if (ring) {
+ data[i++] = ring->stats.pkts;
+ data[i++] = ring->stats.bytes;
+ } else {
+ data[i++] = 0;
+ data[i++] = 0;
+ }
}
- ice_for_each_rxq(vsi, j) {
+ ice_for_each_alloc_rxq(vsi, j) {
ring = READ_ONCE(vsi->rx_rings[j]);
- data[i++] = ring->stats.pkts;
- data[i++] = ring->stats.bytes;
+ if (ring) {
+ data[i++] = ring->stats.pkts;
+ data[i++] = ring->stats.bytes;
+ } else {
+ data[i++] = 0;
+ data[i++] = 0;
+ }
}
rcu_read_unlock();
@@ -519,7 +545,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring)
goto done;
}
- for (i = 0; i < vsi->num_txq; i++) {
+ for (i = 0; i < vsi->alloc_txq; i++) {
/* clone ring and setup updated count */
tx_rings[i] = *vsi->tx_rings[i];
tx_rings[i].count = new_tx_cnt;
@@ -551,7 +577,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring)
goto done;
}
- for (i = 0; i < vsi->num_rxq; i++) {
+ for (i = 0; i < vsi->alloc_rxq; i++) {
/* clone ring and setup updated count */
rx_rings[i] = *vsi->rx_rings[i];
rx_rings[i].count = new_rx_cnt;
--
2.14.3
^ permalink raw reply related
* ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
From: Patchwork @ 2018-07-23 17:37 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
URL : https://patchwork.freedesktop.org/series/47067/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9b348bfd231b drm/i915: Skip repeated calls to i915_gem_set_wedged()
-:58: WARNING:MEMORY_BARRIER: memory barrier without comment
#58: FILE: drivers/gpu/drm/i915/i915_gem.c:3386:
+ smp_mb__before_atomic();
total: 0 errors, 1 warnings, 0 checks, 68 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Intel-wired-lan] [PATCH 03/13] ice: Fix missing shift
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
The ITR index of the interrupt cause for OICR and FW interrupts is not
being shifted correctly so when masked with PFINT_*_CTL_ITR_INDX_M it
will always be zero. Luckily, ICE_RX_ITR is zero anyway so the end result
is the same, but the shift should be fixed in case the value of ICE_RX_ITR
ever changes or it is substituted with another value that needs to be
shifted properly.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 78756853ade1..450911345144 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -2058,15 +2058,17 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
skip_req_irq:
ice_ena_misc_vector(pf);
- val = (pf->oicr_idx & PFINT_OICR_CTL_MSIX_INDX_M) |
- (ICE_RX_ITR & PFINT_OICR_CTL_ITR_INDX_M) |
- PFINT_OICR_CTL_CAUSE_ENA_M;
+ val = ((pf->oicr_idx & PFINT_OICR_CTL_MSIX_INDX_M) |
+ ((ICE_RX_ITR << PFINT_OICR_CTL_ITR_INDX_S) &
+ PFINT_OICR_CTL_ITR_INDX_M) |
+ PFINT_OICR_CTL_CAUSE_ENA_M);
wr32(hw, PFINT_OICR_CTL, val);
/* This enables Admin queue Interrupt causes */
- val = (pf->oicr_idx & PFINT_FW_CTL_MSIX_INDX_M) |
- (ICE_RX_ITR & PFINT_FW_CTL_ITR_INDX_M) |
- PFINT_FW_CTL_CAUSE_ENA_M;
+ val = ((pf->oicr_idx & PFINT_FW_CTL_MSIX_INDX_M) |
+ ((ICE_RX_ITR << PFINT_FW_CTL_ITR_INDX_S) &
+ PFINT_FW_CTL_ITR_INDX_M) |
+ PFINT_FW_CTL_CAUSE_ENA_M);
wr32(hw, PFINT_FW_CTL, val);
itr_gran = hw->itr_gran_200;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 02/13] ice: Cleanup magic number
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
Use define for the unit size shift of the Rx LAN context descriptor base
address instead of the magic number 7.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 1 +
drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h b/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h
index d23a91665b46..068dbc740b76 100644
--- a/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h
+++ b/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h
@@ -265,6 +265,7 @@ enum ice_rx_flex_desc_status_error_0_bits {
struct ice_rlan_ctx {
u16 head;
u16 cpuid; /* bigger than needed, see above for reason */
+#define ICE_RLAN_BASE_S 7
u64 base;
u16 qlen;
#define ICE_RLAN_CTX_DBUF_S 7
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 5299caf55a7f..78756853ade1 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3986,7 +3986,7 @@ static int ice_setup_rx_ctx(struct ice_ring *ring)
/* clear the context structure first */
memset(&rlan_ctx, 0, sizeof(rlan_ctx));
- rlan_ctx.base = ring->dma >> 7;
+ rlan_ctx.base = ring->dma >> ICE_RLAN_BASE_S;
rlan_ctx.qlen = ring->count;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH 01/13] ice: Fix static analyser warning
From: Anirudh Venkataramanan @ 2018-07-23 17:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723173752.19676-1-anirudh.venkataramanan@intel.com>
This patch fixes one of the smatch (a static analysis tool) warnings
reported by Dan Carpenter. ICE_LG_ACT_GENERIC_OFFSET_M is the right mask
to use but it appears that ICE_LG_ACT_GENERIC_VALUE_M was used instead,
which resulted in the following smatch warning:
ice_add_marker_act() warn: odd binop '0x380000 & 0x7fff8'
Additionally, use a new define ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX
instead of magic number '7'.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 +
drivers/net/ethernet/intel/ice/ice_switch.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 7541ec2270b3..6d3e11659ba5 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -594,6 +594,7 @@ struct ice_sw_rule_lg_act {
#define ICE_LG_ACT_GENERIC_OFFSET_M (0x7 << ICE_LG_ACT_GENERIC_OFFSET_S)
#define ICE_LG_ACT_GENERIC_PRIORITY_S 22
#define ICE_LG_ACT_GENERIC_PRIORITY_M (0x7 << ICE_LG_ACT_GENERIC_PRIORITY_S)
+#define ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX 7
/* Action = 7 - Set Stat count */
#define ICE_LG_ACT_STAT_COUNT 0x7
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 723d15f1e90b..750d2051a976 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -645,7 +645,8 @@ ice_add_marker_act(struct ice_hw *hw, struct ice_fltr_mgmt_list_entry *m_ent,
act |= (1 << ICE_LG_ACT_GENERIC_VALUE_S) & ICE_LG_ACT_GENERIC_VALUE_M;
lg_act->pdata.lg_act.act[1] = cpu_to_le32(act);
- act = (7 << ICE_LG_ACT_GENERIC_OFFSET_S) & ICE_LG_ACT_GENERIC_VALUE_M;
+ act = (ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX <<
+ ICE_LG_ACT_GENERIC_OFFSET_S) & ICE_LG_ACT_GENERIC_OFFSET_M;
/* Third action Marker value */
act |= ICE_LG_ACT_GENERIC;
--
2.14.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.