* Re: [PATCH 01/12] i2c: quirks: add zero length checks
From: Wolfram Sang @ 2018-07-23 21:05 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Wolfram Sang, linux-i2c, linux-renesas-soc, linux-kernel
In-Reply-To: <20180723204418.GG1432@bigcity.dyn.berto.se>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
> > Only build tested.
>
> Was this not tested when you also tested i2c-rcar and i2c-sh_mobile
> drivers? In any case I think this change make much sens.
>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
You are right, of course. This text was added by a script and I forgot to
remove it :( This code was tested!
Thanks for the review!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH mlx5-next v2 1/8] net/mlx5: Add forward compatible support for the FTE match data
From: Saeed Mahameed @ 2018-07-23 21:05 UTC (permalink / raw)
To: Jason Gunthorpe, leon@kernel.org, dledford@redhat.com
Cc: netdev@vger.kernel.org, Leon Romanovsky,
linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <20180723122512.20967-2-leon@kernel.org>
On Mon, 2018-07-23 at 15:25 +0300, Leon Romanovsky wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Use the PRM size including the reserved when working with the FTE
> match data.
>
> This comes to support forward compatibility for cases that current
> reserved data will be exposed by the firmware by an application that
> uses the DEVX API without changing the kernel.
>
> Also drop some driver checks around the match criteria leaving the
> work
> for firmware to enable forward compatibility for future bits there.
>
> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 77 +----------
> ------------
> 1 file changed, 1 insertion(+), 76 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index 49a75d31185e..eba113cf1117 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@ -309,89 +309,17 @@ static struct fs_prio *find_prio(struct
> mlx5_flow_namespace *ns,
> return NULL;
> }
>
> -static bool check_last_reserved(const u32 *match_criteria)
> -{
> - char *match_criteria_reserved =
> - MLX5_ADDR_OF(fte_match_param, match_criteria,
> MLX5_FTE_MATCH_PARAM_RESERVED);
> -
> - return !match_criteria_reserved[0] &&
> - !memcmp(match_criteria_reserved,
> match_criteria_reserved + 1,
> - MLX5_FLD_SZ_BYTES(fte_match_param,
> - MLX5_FTE_MATCH_PARAM_RESER
> VED) - 1);
> -}
> -
> -static bool check_valid_mask(u8 match_criteria_enable, const u32
> *match_criteria)
> -{
> - if (match_criteria_enable & ~(
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_OUTER_HEADERS) |
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS) |
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_INNER_HEADERS) |
> - (1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS_2)))
> - return false;
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_OUTER_HEADERS)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> outer_headers);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_lyr_2_4) -
> 1))
> - return false;
> - }
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> misc_parameters);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_misc) -
> 1))
> - return false;
> - }
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_INNER_HEADERS)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> inner_headers);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_lyr_2_4) -
> 1))
> - return false;
> - }
> -
> - if (!(match_criteria_enable &
> - 1 <<
> MLX5_CREATE_FLOW_GROUP_IN_MATCH_CRITERIA_ENABLE_MISC_PARAMETERS_2)) {
> - char *fg_type_mask = MLX5_ADDR_OF(fte_match_param,
> - match_criteria,
> misc_parameters_2);
> -
> - if (fg_type_mask[0] ||
> - memcmp(fg_type_mask, fg_type_mask + 1,
> - MLX5_ST_SZ_BYTES(fte_match_set_misc2) -
> 1))
> - return false;
> - }
> -
> - return check_last_reserved(match_criteria);
> -}
> -
> static bool check_valid_spec(const struct mlx5_flow_spec *spec)
> {
> int i;
>
> - if (!check_valid_mask(spec->match_criteria_enable, spec-
> >match_criteria)) {
> - pr_warn("mlx5_core: Match criteria given mismatches
> match_criteria_enable\n");
> - return false;
> - }
> -
> for (i = 0; i < MLX5_ST_SZ_DW_MATCH_PARAM; i++)
> if (spec->match_value[i] & ~spec->match_criteria[i])
> {
> pr_warn("mlx5_core: match_value differs from
> match_criteria\n");
> return false;
> }
>
> - return check_last_reserved(spec->match_value);
> + return true;
> }
>
> static struct mlx5_flow_root_namespace *find_root(struct fs_node
> *node)
> @@ -1158,9 +1086,6 @@ struct mlx5_flow_group
> *mlx5_create_flow_group(struct mlx5_flow_table *ft,
> struct mlx5_flow_group *fg;
> int err;
>
> - if (!check_valid_mask(match_criteria_enable,
> match_criteria))
> - return ERR_PTR(-EINVAL);
> -
> if (ft->autogroup.active)
> return ERR_PTR(-EPERM);
>
^ permalink raw reply
* [PATCH v2] PCI/AER: Do not clear AER bits if we don't own AER
From: Alexandru Gagniuc @ 2018-07-23 20:01 UTC (permalink / raw)
To: linux-pci, bhelgaas
Cc: keith.busch, alex_gagniuc, austin_bolen, shyam_iyer,
jeffrey.t.kirsher, ariel.elior, michael.chan, ganeshgr, tariqt,
jakub.kicinski, airlied, alexander.deucher, mike.marciniszyn,
Alexandru Gagniuc, Frederick Lawler, Oza Pawandeep,
Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20180718215359.GG128988@bhelgaas-glaptop.roam.corp.google.com>
When we don't own AER, we shouldn't touch the AER error bits. Clearing
error bits willy-nilly might cause firmware to miss some errors. In
theory, these bits get cleared by FFS, or via ACPI _HPX method. These
mechanisms are not subject to the problem.
This race is mostly of theoretical significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
drivers/pci/pcie/aer.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index a2e88386af28..85c3e173c025 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -307,6 +307,12 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
aer_set_firmware_first(dev);
return dev->__aer_firmware_first;
}
+
+static bool pcie_aer_is_kernel_first(struct pci_dev *dev)
+{
+ return !!dev->aer_cap && !pcie_aer_get_firmware_first(dev);
+}
+
#define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE | PCI_EXP_DEVCTL_NFERE | \
PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -337,10 +343,7 @@ bool aer_acpi_firmware_first(void)
int pci_enable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
- return -EIO;
-
- if (!dev->aer_cap)
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS);
@@ -349,7 +352,7 @@ EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
int pci_disable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
@@ -383,10 +386,10 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
if (!pci_is_pcie(dev))
return -ENODEV;
- pos = dev->aer_cap;
- if (!pos)
+ if (pcie_aer_is_kernel_first(dev))
return -EIO;
+ pos = dev->aer_cap;
port_type = pci_pcie_type(dev);
if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, &status);
--
2.17.1
^ permalink raw reply related
* [Intel-wired-lan] [RFC PATCH jkirsher-next-queue] i40e: len_ethhdr can be static
From: kbuild test robot @ 2018-07-23 21:04 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <201807240548.0XzJcSzH%fengguang.wu@intel.com>
Fixes: 58e0270bb7ac ("i40e: Initial support to add hw hints for xdp")
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
i40e_txrx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 09536d7e7..ab8b97f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2296,9 +2296,9 @@ static inline void i40e_xdp_ring_update_tail(struct i40e_ring *xdp_ring)
writel_relaxed(xdp_ring->next_to_use, xdp_ring->tail);
};
-const size_t len_ethhdr = sizeof(struct ethhdr);
-const size_t len_ipv4hdr = sizeof(struct iphdr);
-const size_t len_ipv6hdr = sizeof(struct ipv6hdr);
+static const size_t len_ethhdr = sizeof(struct ethhdr);
+static const size_t len_ipv4hdr = sizeof(struct iphdr);
+static const size_t len_ipv6hdr = sizeof(struct ipv6hdr);
enum XDP_META_PTYPE
{
^ permalink raw reply related
* [Intel-wired-lan] [jkirsher-next-queue:XDP-hints-EXPERIMENTAL 1/1] drivers/net/ethernet/intel/i40e/i40e_txrx.c:2299:14: sparse: symbol 'len_ethhdr' was not declared. Should it be static?
From: kbuild test robot @ 2018-07-23 21:04 UTC (permalink / raw)
To: intel-wired-lan
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git XDP-hints-EXPERIMENTAL
head: 58e0270bb7ac94a31ff0fe372385cfce4198b56c
commit: 58e0270bb7ac94a31ff0fe372385cfce4198b56c [1/1] i40e: Initial support to add hw hints for xdp
reproduce:
# apt-get install sparse
git checkout 58e0270bb7ac94a31ff0fe372385cfce4198b56c
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:1118:23: sparse: expression using sizeof(void)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:1118:23: sparse: expression using sizeof(void)
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2299:14: sparse: symbol 'len_ethhdr' was not declared. Should it be static?
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2300:14: sparse: symbol 'len_ipv4hdr' was not declared. Should it be static?
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2301:14: sparse: symbol 'len_ipv6hdr' was not declared. Should it be static?
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2346:38: sparse: missing braces around initializer
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2350:47: sparse: incorrect type in initializer (different base types) @@ expected unsigned long long [unsigned] [usertype] stserr @@ got g long [unsigned] [usertype] stserr @@
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2350:47: expected unsigned long long [unsigned] [usertype] stserr
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2350:47: got restricted __le64 [usertype] status_error_len
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c:2438:36: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [unsigned] [assigned] [usertype] hash @@ got igned] [assigned] [usertype] hash @@
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2438:36: expected unsigned int [unsigned] [assigned] [usertype] hash
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2438:36: got restricted __le32 [usertype] rss
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2761:27: sparse: expression using sizeof(void)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2809:16: sparse: expression using sizeof(void)
drivers/net/ethernet/intel/i40e/i40e_txrx.c:2809:16: sparse: expression using sizeof(void)
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v4 00/21] Add `range-diff`, a `tbdiff` lookalike
From: Stefan Beller @ 2018-07-23 21:03 UTC (permalink / raw)
To: gitgitgadget; +Cc: git, Junio C Hamano
In-Reply-To: <pull.1.v4.git.gitgitgadget@gmail.com>
On Sat, Jul 21, 2018 at 3:04 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> Side note: I work on implementing range-diff not only to make life easier for reviewers who have to suffer through v2, v3, ... of my patch series, but also to verify my changes before submitting a new iteration. And also, maybe even more importantly, I plan to use it to verify my merging-rebases of Git for
> Windows (for which I previously used to redirect the pre-rebase/post-rebase diffs vs upstream and then compare them using `git diff --no-index`). And of course any interested person can see what changes were necessary e.g. in the merging-rebase of Git for Windows onto v2.17.0 by running a command like:
Thanks for making tools that makes the life of a Git developer easier!
(Just filed https://github.com/gitgitgadget/gitgitgadget/issues/26
which asks to break lines for this cover letter)
> base-commit: b7bd9486b055c3f967a870311e704e3bb0654e4f
> Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-1%2Fdscho%2Fbranch-diff-v4
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1/dscho/branch-diff-v4
> Pull-Request: https://github.com/gitgitgadget/git/pull/1
I just realized that if I had ideal memory of the previous review,
I could contain my whole review answer to this email only.
>
> Range-diff vs v3:
>
> 1: 39272eefc ! 1: f7e70689e linear-assignment: a function to solve least-cost assignment problems
> @@ -223,9 +223,7 @@
> + BUG("negative j: %d", j);
> + i = pred[j];
> + column2row[j] = i;
> -+ k = j;
> -+ j = row2column[i];
> -+ row2column[i] = k;
> ++ SWAP(j, row2column[i]);
The dual color option (as a default) really helps here. Thanks for that!
Does it have to be renamed though? (It's more than two colors; originally
it was inverting the beginning signs)
Maybe --color=emphasize-later
assuming there will be other modes for coloring, such as "diff-only",
which would correspond with --no-dual-color, or "none" that will correspond
would be --no-color. I imagine there could be more fancy things, hence I would
propose a mode rather than a switch.
(Feel free to push back if discussing naming here feels like bike shedding)
2: 7f15b26d4ea ! 82: 88134121d2a Introduce `range-diff` to compare
iterations of a topic branch
[...]
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
The line starting with --- is red (default removed color) and the line
with +++ is green (default add color).
Ideally these two lines and the third line above starting with "diff --git"
would render in GIT_COLOR_BOLD ("METAINFO").
> 3: 076e1192d ! 3: 4e3fb47a1 range-diff: first rudimentary implementation
> @@ -4,7 +4,7 @@
>
> At this stage, `git range-diff` can determine corresponding commits
> of two related commit ranges. This makes use of the recently introduced
> - implementation of the Hungarian algorithm.
> + implementation of the linear assignment algorithm.
>
> The core of this patch is a straight port of the ideas of tbdiff, the
> apparently dormant project at https://github.com/trast/tbdiff.
> @@ -51,19 +51,17 @@
> + int res = 0;
> + struct strbuf range1 = STRBUF_INIT, range2 = STRBUF_INIT;
>
> -- argc = parse_options(argc, argv, NULL, options,
> -- builtin_range_diff_usage, 0);
> -+ argc = parse_options(argc, argv, NULL, options, builtin_range_diff_usage,
> -+ 0);
> + argc = parse_options(argc, argv, NULL, options,
> + builtin_range_diff_usage, 0);
This is really nice in colors when viewed locally.
> 16: dfa7b1e71 < -: --------- range-diff --dual-color: work around bogus white-space warning
> -: --------- > 16: f4252f2b2 range-diff --dual-color: fix bogus white-space warning
Ah; here my initial assumption of only reviewing the range-diff breaks down now.
I'll dig into patch 16 separately.
Maybe it is worth having an option to expand all "new" patches.
(Given that the range-diff pr-1/dscho/branch-diff-v3...pr-1/dscho/branch-diff-v4
told me you used a different base, this is a hard problem, as I certainly
would want to skip over all new base commits, but this one is interesting
to look at. An easy way out: Maybe an option to expand any new
commits/patches after the first expansion? Asking for opinions rather
than implementing it)
> 19: 144363006 < -: --------- range-diff: left-pad patch numbers
> -: --------- > 19: 07ec215e8 range-diff: left-pad patch numbers
> -: --------- > 21: d8498fb32 range-diff: use dim/bold cues to improve dual color mode
Those are interesting, I'll look at them separately, too.
Thanks,
Stefan
^ permalink raw reply
* Re: linux-next: Tree for Jul 23
From: Stephen Rothwell @ 2018-07-23 21:03 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <877elmhvf9.fsf@concordia.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
Hi Michael,
On Tue, 24 Jul 2018 00:35:22 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Would you mind adding my "topic/hvc" branch to linux-next.
>
> We (ppc) are notionally the maintainers for that code but it's used by
> some other folks, so I'd like it to get some wider testing before I
> commit it.
>
> You should get:
>
> 9f65b81f36e3 ("tty: hvc: introduce the hv_ops.flush operation for hvc drivers")
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5] PCI: Check for PCIe downtraining conditions
From: Jakub Kicinski @ 2018-07-23 21:01 UTC (permalink / raw)
To: Alexandru Gagniuc
Cc: linux-pci, bhelgaas, keith.busch, alex_gagniuc, austin_bolen,
shyam_iyer, jeffrey.t.kirsher, ariel.elior, michael.chan,
ganeshgr, tariqt, airlied, alexander.deucher, mike.marciniszyn,
linux-kernel
In-Reply-To: <20180723200339.23943-1-mr.nuke.me@gmail.com>
On Mon, 23 Jul 2018 15:03:38 -0500, Alexandru Gagniuc wrote:
> PCIe downtraining happens when both the device and PCIe port are
> capable of a larger bus width or higher speed than negotiated.
> Downtraining might be indicative of other problems in the system, and
> identifying this from userspace is neither intuitive, nor
> straightforward.
>
> The easiest way to detect this is with pcie_print_link_status(),
> since the bottleneck is usually the link that is downtrained. It's not
> a perfect solution, but it works extremely well in most cases.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>
> For the sake of review, I've created a __pcie_print_link_status() which
> takes a 'verbose' argument. If we agree want to go this route, and update
> the users of pcie_print_link_status(), I can split this up in two patches.
> I prefer just printing this information in the core functions, and letting
> drivers not have to worry about this. Though there seems to be strong for
> not going that route, so here it goes:
FWIW the networking drivers print PCIe BW because sometimes the network
bandwidth is simply over-provisioned on multi port cards, e.g. 80Gbps
card on a x8 link.
Sorry to bike shed, but currently the networking cards print the info
during probe. Would it make sense to move your message closer to probe
time? Rather than when device is added. If driver structure is
available, we could also consider adding a boolean to struct pci_driver
to indicate if driver wants the verbose message? This way we avoid
duplicated prints.
I have no objection to current patch, it LGTM. Just a thought.
> drivers/pci/pci.c | 22 ++++++++++++++++++----
> drivers/pci/probe.c | 21 +++++++++++++++++++++
> include/linux/pci.h | 1 +
> 3 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 316496e99da9..414ad7b3abdb 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5302,14 +5302,15 @@ u32 pcie_bandwidth_capable(struct pci_dev *dev, enum pci_bus_speed *speed,
> }
>
> /**
> - * pcie_print_link_status - Report the PCI device's link speed and width
> + * __pcie_print_link_status - Report the PCI device's link speed and width
> * @dev: PCI device to query
> + * @verbose: Be verbose -- print info even when enough bandwidth is available.
> *
> * Report the available bandwidth at the device. If this is less than the
> * device is capable of, report the device's maximum possible bandwidth and
> * the upstream link that limits its performance to less than that.
> */
> -void pcie_print_link_status(struct pci_dev *dev)
> +void __pcie_print_link_status(struct pci_dev *dev, bool verbose)
> {
> enum pcie_link_width width, width_cap;
> enum pci_bus_speed speed, speed_cap;
> @@ -5319,11 +5320,11 @@ void pcie_print_link_status(struct pci_dev *dev)
> bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap);
> bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width);
>
> - if (bw_avail >= bw_cap)
> + if (bw_avail >= bw_cap && verbose)
> pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d link)\n",
> bw_cap / 1000, bw_cap % 1000,
> PCIE_SPEED2STR(speed_cap), width_cap);
> - else
> + else if (bw_avail < bw_cap)
> pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
> bw_avail / 1000, bw_avail % 1000,
> PCIE_SPEED2STR(speed), width,
> @@ -5331,6 +5332,19 @@ void pcie_print_link_status(struct pci_dev *dev)
> bw_cap / 1000, bw_cap % 1000,
> PCIE_SPEED2STR(speed_cap), width_cap);
> }
> +
> +/**
> + * pcie_print_link_status - Report the PCI device's link speed and width
> + * @dev: PCI device to query
> + *
> + * Report the available bandwidth at the device. If this is less than the
> + * device is capable of, report the device's maximum possible bandwidth and
> + * the upstream link that limits its performance to less than that.
> + */
> +void pcie_print_link_status(struct pci_dev *dev)
> +{
> + __pcie_print_link_status(dev, true);
> +}
> EXPORT_SYMBOL(pcie_print_link_status);
>
> /**
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ac876e32de4b..1f7336377c3b 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2205,6 +2205,24 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
> return dev;
> }
>
> +static void pcie_check_upstream_link(struct pci_dev *dev)
> +{
> + if (!pci_is_pcie(dev))
> + return;
> +
> + /* Look from the device up to avoid downstream ports with no devices. */
> + if ((pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT) &&
> + (pci_pcie_type(dev) != PCI_EXP_TYPE_LEG_END) &&
> + (pci_pcie_type(dev) != PCI_EXP_TYPE_UPSTREAM))
> + return;
> +
> + /* Multi-function PCIe share the same link/status. */
> + if (PCI_FUNC(dev->devfn) != 0 || dev->is_virtfn)
> + return;
> +
> + __pcie_print_link_status(dev, false);
> +}
> +
> static void pci_init_capabilities(struct pci_dev *dev)
> {
> /* Enhanced Allocation */
> @@ -2240,6 +2258,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
> /* Advanced Error Reporting */
> pci_aer_init(dev);
>
> + /* Check link and detect downtrain errors */
> + pcie_check_upstream_link(dev);
> +
> if (pci_probe_reset_function(dev) == 0)
> dev->reset_fn = 1;
> }
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index abd5d5e17aee..15bfab8f7a1b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1088,6 +1088,7 @@ int pcie_set_mps(struct pci_dev *dev, int mps);
> u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
> enum pci_bus_speed *speed,
> enum pcie_link_width *width);
> +void __pcie_print_link_status(struct pci_dev *dev, bool verbose);
> void pcie_print_link_status(struct pci_dev *dev);
> int pcie_flr(struct pci_dev *dev);
> int __pci_reset_function_locked(struct pci_dev *dev);
^ permalink raw reply
* Re: [PATCH bpf] xdp: add NULL pointer check in __xdp_return()
From: Jakub Kicinski @ 2018-07-23 19:58 UTC (permalink / raw)
To: Björn Töpel
Cc: Daniel Borkmann, Björn Töpel, Jesper Dangaard Brouer,
kafai, ap420073, ast, Netdev, Karlsson, Magnus
In-Reply-To: <CAJ+HfNh5BLoqhJWkiDf7-mVxuPrOgAyGp6=8e5jOOOvVkb9+HA@mail.gmail.com>
On Mon, 23 Jul 2018 11:39:36 +0200, Björn Töpel wrote:
> Den fre 20 juli 2018 kl 22:08 skrev Jakub Kicinski:
> > On Fri, 20 Jul 2018 10:18:21 -0700, Martin KaFai Lau wrote:
> > > On Sat, Jul 21, 2018 at 01:04:45AM +0900, Taehee Yoo wrote:
> > > > rhashtable_lookup() can return NULL. so that NULL pointer
> > > > check routine should be added.
> > > >
> > > > Fixes: 02b55e5657c3 ("xdp: add MEM_TYPE_ZERO_COPY")
> > > > Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> > > > ---
> > > > net/core/xdp.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/core/xdp.c b/net/core/xdp.c
> > > > index 9d1f220..1c12bc7 100644
> > > > --- a/net/core/xdp.c
> > > > +++ b/net/core/xdp.c
> > > > @@ -345,7 +345,8 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> > > > rcu_read_lock();
> > > > /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> > > > xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> > > > - xa->zc_alloc->free(xa->zc_alloc, handle);
> > > > + if (xa)
> > > > + xa->zc_alloc->free(xa->zc_alloc, handle);
> > > hmm...It is not clear to me the "!xa" case don't have to be handled?
> >
> > Actually I have a more fundamental question about this interface I've
> > been meaning to ask.
> >
> > IIUC free() can happen on any CPU at any time, when whatever device,
> > socket or CPU this got redirected to completed the TX. IOW there may
> > be multiple producers. Drivers would need to create spin lock a'la the
> > a9744f7ca200 ("xsk: fix potential race in SKB TX completion code") fix?
> >
>
> Jakub, apologies for the slow response. I'm still in
> "holiday/hammock&beer mode", but will be back in a week. :-P
Ah, sorry to interrupt! :)
> The idea with the xdp_return_* functions are that an xdp_buff and
> xdp_frame can have custom allocations schemes. The difference beween
> struct xdp_buff and struct xdp_frame is lifetime. The xdp_buff
> lifetime is within the napi context, whereas xdp_frame can have a
> lifetime longer/outside the napi context. E.g. for a XDP_REDIRECT
> scenario an xdp_buff is converted to a xdp_frame. The conversion is
> done in include/net/xdp.h:convert_to_xdp_frame.
>
> Currently, the zero-copy MEM_TYPE_ZERO_COPY memtype can *only* be used
> for xdp_buff, meaning that the lifetime is constrained to a napi
> context. Further, given an xdp_buff with memtype MEM_TYPE_ZERO_COPY,
> doing XDP_REDIRECT to a target that is *not* an AF_XDP socket would
> mean converting the xdp_buff to an xdp_frame. The xdp_frame can then
> be free'd on any CPU.
>
> Note that the xsk_rcv* functions is always called from an napi
> context, and therefore is using the xdp_return_buff calls.
>
> To answer your question -- no, this fix is *not* needed, because the
> xdp_buff napi constrained, and the xdp_buff will only be free'd on one
> CPU.
Oh, thanks, I missed the check in convert_to_xdp_frame(), so the only
frames which can come back via the free path are out of the error path
in __xsk_rcv_zc()?
That path looks a little surprising too, isn't the expectation that if
xdp_do_redirect() returns an error the driver retains the ownership of
the buffer?
static int __xsk_rcv_zc(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
{
int err = xskq_produce_batch_desc(xs->rx, (u64)xdp->handle, len);
if (err) {
xdp_return_buff(xdp);
xs->rx_dropped++;
}
return err;
}
This seems to call xdp_return_buff() *and* return an error.
> > We need some form of internal kernel circulation which would be MPSC.
> > I'm currently hacking up the XSK code to tell me whether the frame was
> > consumed by the correct XSK, and always clone the frame otherwise
> > (claiming to be the "traditional" MEM_TYPE_PAGE_ORDER0).
> >
> > I feel like I'm missing something about the code. Is redirect of
> > ZC/UMEM frame outside the xsk not possible and the only returns we will
> > see are from net/xdp/xsk.c? That would work, but I don't see such a
> > check. Help would be appreciated.
> >
>
> Right now, this is the case (refer to the TODO in
> convert_to_xdp_frame), i.e. you cannot redirect an ZC/UMEM allocated
> xdp_buff to a target that is not an xsk. This must, obviously, change
> so that an xdp_buff (of MEM_TYPE_ZERO_COPY) can be converted to an
> xdp_frame. The xdp_frame must be able to be free'd from multiple CPUs,
> so here the a more sophisticated allocation scheme is required.
>
> > Also the fact that XSK bufs can't be freed, only completed, adds to the
> > pain of implementing AF_XDP, we'd certainly need some form of "give
> > back the frame, but I may need it later" SPSC mechanism, otherwise
> > driver writers will have tough time. Unless, again, I'm missing
> > something about the code :)
> >
>
> Yup, moving the recycling scheme from driver to "generic" is a good
> idea! I need to finish up those i40e zerocopy patches first though...
Interesting, FWIW I wasn't necessarily thinking about full recycling,
although that would be the holy grail. Just a generic way of giving up
buffers for example when user changes ring sizes or brings the device
down.
> (...and I'm very excited that you're doing nfp support for AF_XDP!!!)
Thanks, I'm still way out in the weeds but it's interesting work :)
^ permalink raw reply
* [PATCH] net: sort Kconfig menu items alphabetically
From: Bjorn Helgaas @ 2018-07-23 21:01 UTC (permalink / raw)
To: David S. Miller
Cc: Florian Fainelli, Rasesh Mody, Sudarsana Kalluru, Jon Mason,
Dept-GELinuxNICDev, netdev, linux-kernel
From: Bjorn Helgaas <bhelgaas@google.com>
6c541b4595a2 ("net: ethernet: Sort Kconfig sourcing alphabetically")
sorted Kconfig sourcing based on directory names, but in a couple cases,
the menu item text is quite different from the directory name and is not
sorted correctly:
drivers/net/ethernet/neterion/Kconfig => "Exar devices"
drivers/net/ethernet/brocade/Kconfig => "QLogic BR-series devices"
Move these entries so the Kconfig menu items are sorted.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index af766fd61151..b21febba458e 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -34,7 +34,6 @@ source "drivers/net/ethernet/arc/Kconfig"
source "drivers/net/ethernet/atheros/Kconfig"
source "drivers/net/ethernet/aurora/Kconfig"
source "drivers/net/ethernet/broadcom/Kconfig"
-source "drivers/net/ethernet/brocade/Kconfig"
source "drivers/net/ethernet/cadence/Kconfig"
source "drivers/net/ethernet/calxeda/Kconfig"
source "drivers/net/ethernet/cavium/Kconfig"
@@ -71,6 +70,7 @@ config DNET
source "drivers/net/ethernet/dec/Kconfig"
source "drivers/net/ethernet/dlink/Kconfig"
source "drivers/net/ethernet/emulex/Kconfig"
+source "drivers/net/ethernet/neterion/Kconfig"
source "drivers/net/ethernet/ezchip/Kconfig"
source "drivers/net/ethernet/faraday/Kconfig"
source "drivers/net/ethernet/freescale/Kconfig"
@@ -81,7 +81,6 @@ source "drivers/net/ethernet/huawei/Kconfig"
source "drivers/net/ethernet/i825xx/Kconfig"
source "drivers/net/ethernet/ibm/Kconfig"
source "drivers/net/ethernet/intel/Kconfig"
-source "drivers/net/ethernet/neterion/Kconfig"
source "drivers/net/ethernet/xscale/Kconfig"
config JME
@@ -160,6 +159,7 @@ config ETHOC
source "drivers/net/ethernet/packetengines/Kconfig"
source "drivers/net/ethernet/pasemi/Kconfig"
source "drivers/net/ethernet/qlogic/Kconfig"
+source "drivers/net/ethernet/brocade/Kconfig"
source "drivers/net/ethernet/qualcomm/Kconfig"
source "drivers/net/ethernet/rdc/Kconfig"
source "drivers/net/ethernet/realtek/Kconfig"
^ permalink raw reply related
* Re: [RFC PATCH ghak59 V1 3/6] audit: exclude user records from syscall context
From: Paul Moore @ 2018-07-23 21:00 UTC (permalink / raw)
To: rgb; +Cc: Eric Paris, linux-audit, linux-kernel
In-Reply-To: <20180723164035.wkazolpmpf3mvdxw@madcap2.tricolour.ca>
On Mon, Jul 23, 2018 at 12:43 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2018-07-12 17:46, Richard Guy Briggs wrote:
> > On 2018-06-28 18:11, Paul Moore wrote:
> > > On Thu, Jun 14, 2018 at 4:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > > Since the function audit_log_common_recv_msg() is shared by a number of
> > > > AUDIT_CONFIG_CHANGE and the entire range of AUDIT_USER_* record types,
> > > > and since the AUDIT_CONFIG_CHANGE message type has been converted to a
> > > > syscall accompanied record type, special-case the AUDIT_USER_* range of
> > > > messages so they remain standalone records.
> > > >
> > > > See: https://github.com/linux-audit/audit-kernel/issues/59
> > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > > ---
> > > > kernel/audit.c | 12 +++++++++---
> > > > 1 file changed, 9 insertions(+), 3 deletions(-)
> > >
> > > I think this is fine, but see my previous comment about combining 2/6
> > > and 3/6 as a safety measure.
> >
> > This one I left as a seperate patch for discussion. We'd previously
> > talked about connecting all possible records with syscall records if
> > they exist, but this one I'm unsure about, since we don't really care
> > what userspace process is issuing this message. It is just the message
> > content itself that is important. Or is it? Are we concerned about
> > CAP_AUDIT_WRITE holders/abusers and want as much info about them as we
> > can get in case they go rogue or pear-shaped?
>
> I'm waiting on re-spinning this patchset because of this open question.
>
> Is connecting AUDIT_USER* records desirable or a liability?
Like I said, I think special casing the AUDIT_USER* records so they
are *not* associated with other records is okay, and perhaps even the
right thing to do. The problem is that we don't have the necessary
context (har har) to match any kernel events (and there is the
possibility that there are none) to the userspace generated
AUDIT_USER* event. Further, I don't think this is something we would
ever be able to solve in a reasonable manner.
> > > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > > index e469234..c8c2efc 100644
> > > > --- a/kernel/audit.c
> > > > +++ b/kernel/audit.c
> > > > @@ -1057,7 +1057,8 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
> > > > return err;
> > > > }
> > > >
> > > > -static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > +static void __audit_log_common_recv_msg(struct audit_context *context,
> > > > + struct audit_buffer **ab, u16 msg_type)
> > > > {
> > > > uid_t uid = from_kuid(&init_user_ns, current_uid());
> > > > pid_t pid = task_tgid_nr(current);
> > > > @@ -1067,7 +1068,7 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > return;
> > > > }
> > > >
> > > > - *ab = audit_log_start(audit_context(), GFP_KERNEL, msg_type);
> > > > + *ab = audit_log_start(context, GFP_KERNEL, msg_type);
> > > > if (unlikely(!*ab))
> > > > return;
> > > > audit_log_format(*ab, "pid=%d uid=%u", pid, uid);
> > > > @@ -1075,6 +1076,11 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > audit_log_task_context(*ab);
> > > > }
> > > >
> > > > +static inline void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > +{
> > > > + __audit_log_common_recv_msg(audit_context(), ab, msg_type);
> > > > +}
> > > > +
> > > > int is_audit_feature_set(int i)
> > > > {
> > > > return af.features & AUDIT_FEATURE_TO_MASK(i);
> > > > @@ -1341,7 +1347,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> > > > if (err)
> > > > break;
> > > > }
> > > > - audit_log_common_recv_msg(&ab, msg_type);
> > > > + __audit_log_common_recv_msg(NULL, &ab, msg_type);
> > > > if (msg_type != AUDIT_USER_TTY)
> > > > audit_log_format(ab, " msg='%.*s'",
> > > > AUDIT_MESSAGE_TEXT_MAX,
> > > > --
> > > > 1.8.3.1
> > > >
> > >
> > >
> > > --
> > > paul moore
> > > www.paul-moore.com
> > >
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Sr. S/W Engineer, Kernel Security, Base Operating Systems
> > Remote, Ottawa, Red Hat Canada
> > IRC: rgb, SunRaycer
> > Voice: +1.647.777.2635, Internal: (81) 32635
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 0/4] ia64: switch to NO_BOOTMEM
From: Luck, Tony @ 2018-07-23 21:00 UTC (permalink / raw)
To: Mike Rapoport
Cc: Fenghua Yu, Michal Hocko, linux-ia64, linux-mm, linux-kernel
In-Reply-To: <1532325418-22617-1-git-send-email-rppt@linux.vnet.ibm.com>
On Mon, Jul 23, 2018 at 08:56:54AM +0300, Mike Rapoport wrote:
> Hi,
>
> These patches convert ia64 to use NO_BOOTMEM.
>
> The first two patches are cleanups, the third patches reduces usage of
> 'struct bootmem_data' for easier transition and the forth patch actually
> replaces bootmem with memblock + nobootmem.
>
> I've tested the sim_defconfig with the ski simulator and build tested other
> defconfigs.
Boots OK on my real ia64 system.
Unless somebody else sees an issue I'll push to Linus nest merge window.
-Tony
^ permalink raw reply
* Re: [PATCH 0/4] ia64: switch to NO_BOOTMEM
From: Luck, Tony @ 2018-07-23 21:00 UTC (permalink / raw)
To: Mike Rapoport
Cc: Fenghua Yu, Michal Hocko, linux-ia64, linux-mm, linux-kernel
In-Reply-To: <1532325418-22617-1-git-send-email-rppt@linux.vnet.ibm.com>
On Mon, Jul 23, 2018 at 08:56:54AM +0300, Mike Rapoport wrote:
> Hi,
>
> These patches convert ia64 to use NO_BOOTMEM.
>
> The first two patches are cleanups, the third patches reduces usage of
> 'struct bootmem_data' for easier transition and the forth patch actually
> replaces bootmem with memblock + nobootmem.
>
> I've tested the sim_defconfig with the ski simulator and build tested other
> defconfigs.
Boots OK on my real ia64 system.
Unless somebody else sees an issue I'll push to Linus nest merge window.
-Tony
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/4] lib: Don't assert all KMS drivers support edid_override
From: Patchwork @ 2018-07-23 20:59 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20180723200736.29508-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [i-g-t,1/4] lib: Don't assert all KMS drivers support edid_override
URL : https://patchwork.freedesktop.org/series/47084/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> IGTPW_1633 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47084/revisions/1/mbox/
== Known issues ==
Here are the changes found in IGTPW_1633 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_module_reload@basic-reload-inject:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725, fdo#106248) +1
igt@gem_ringfill@basic-default-fd:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-j4005: PASS -> FAIL (fdo#100368)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: NOTRUN -> INCOMPLETE (fdo#103713)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000)
==== Possible fixes ====
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
== Participating hosts (47 -> 43) ==
Additional (1): fi-bsw-kefka
Missing (5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1633
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1633: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1633/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Testlist changes ==
+igt@gem_exec_capture@many-random
+igt@gem_exec_capture@many-zero
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1633/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* request for 4.17-stable: 7ec916f82c48 ("Revert "iommu/intel-iommu: Enable CONFIG_DMA_DIRECT_OPS=y and clean up intel_{alloc,free}_coherent()"")
From: Jeremy Cline @ 2018-07-23 19:56 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Christoph Hellwig, Fabio Coatti, stable
Hi Greg,
Please consider backporting commit 7ec916f82c48, which fixes an issue
with iwlwifi module loading in some cases. Fabio initially reported the
issue and confirmed reverting fixed the problem, and it has also been
reported by at least one Fedora user[0] as fixing the problem.
Thanks!
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1607092
^ permalink raw reply
* [PATCH] net/mlx5: fix queue rollback when starting device
From: Yongseok Koh @ 2018-07-23 20:57 UTC (permalink / raw)
To: shahafs; +Cc: dev, Yongseok Koh, stable
mlx5_rxq_start() and mlx5_rxq_stop() must be strictly paired because
internal reference counter is increased or decreased inside. Also,
mlx5_rxq_get() must be paired with mlx5_rxq_release().
Fixes: 7d6bf6b866b8 ("net/mlx5: add Multi-Packet Rx support")
Fixes: a1366b1a2be3 ("net/mlx5: add reference counter on DPDK Rx queues")
Fixes: 6e78005a9b30 ("net/mlx5: add reference counter on DPDK Tx queues")
Cc: stable@dpdk.org
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
drivers/net/mlx5/mlx5_trigger.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_trigger.c b/drivers/net/mlx5/mlx5_trigger.c
index 4d2078bbd..ef499d898 100644
--- a/drivers/net/mlx5/mlx5_trigger.c
+++ b/drivers/net/mlx5/mlx5_trigger.c
@@ -46,7 +46,6 @@ mlx5_txq_start(struct rte_eth_dev *dev)
unsigned int i;
int ret;
- /* Add memory regions to Tx queues. */
for (i = 0; i != priv->txqs_n; ++i) {
struct mlx5_txq_ctrl *txq_ctrl = mlx5_txq_get(dev, i);
@@ -60,12 +59,17 @@ mlx5_txq_start(struct rte_eth_dev *dev)
}
}
ret = mlx5_tx_uar_remap(dev, priv->ctx->cmd_fd);
- if (ret)
+ if (ret) {
+ /* Adjust index for rollback. */
+ i = priv->txqs_n - 1;
goto error;
+ }
return 0;
error:
ret = rte_errno; /* Save rte_errno before cleanup. */
- mlx5_txq_stop(dev);
+ do {
+ mlx5_txq_release(dev, i);
+ } while (i-- != 0);
rte_errno = ret; /* Restore rte_errno. */
return -rte_errno;
}
@@ -103,8 +107,10 @@ mlx5_rxq_start(struct rte_eth_dev *dev)
int ret = 0;
/* Allocate/reuse/resize mempool for Multi-Packet RQ. */
- if (mlx5_mprq_alloc_mp(dev))
- goto error;
+ if (mlx5_mprq_alloc_mp(dev)) {
+ /* Should not release Rx queues but return immediately. */
+ return -rte_errno;
+ }
for (i = 0; i != priv->rxqs_n; ++i) {
struct mlx5_rxq_ctrl *rxq_ctrl = mlx5_rxq_get(dev, i);
struct rte_mempool *mp;
@@ -130,7 +136,9 @@ mlx5_rxq_start(struct rte_eth_dev *dev)
return 0;
error:
ret = rte_errno; /* Save rte_errno before cleanup. */
- mlx5_rxq_stop(dev);
+ do {
+ mlx5_rxq_release(dev, i);
+ } while (i-- != 0);
rte_errno = ret; /* Restore rte_errno. */
return -rte_errno;
}
@@ -152,21 +160,21 @@ mlx5_dev_start(struct rte_eth_dev *dev)
struct priv *priv = dev->data->dev_private;
int ret;
- dev->data->dev_started = 1;
- DRV_LOG(DEBUG, "port %u allocating and configuring hash Rx queues",
- dev->data->port_id);
+ DRV_LOG(DEBUG, "port %u starting device", dev->data->port_id);
ret = mlx5_txq_start(dev);
if (ret) {
DRV_LOG(ERR, "port %u Tx queue allocation failed: %s",
dev->data->port_id, strerror(rte_errno));
- goto error;
+ return -rte_errno;
}
ret = mlx5_rxq_start(dev);
if (ret) {
DRV_LOG(ERR, "port %u Rx queue allocation failed: %s",
dev->data->port_id, strerror(rte_errno));
- goto error;
+ mlx5_txq_stop(dev);
+ return -rte_errno;
}
+ dev->data->dev_started = 1;
ret = mlx5_rx_intr_vec_enable(dev);
if (ret) {
DRV_LOG(ERR, "port %u Rx interrupt vector creation failed",
@@ -221,8 +229,7 @@ mlx5_dev_stop(struct rte_eth_dev *dev)
dev->tx_pkt_burst = removed_tx_burst;
rte_wmb();
usleep(1000 * priv->rxqs_n);
- DRV_LOG(DEBUG, "port %u cleaning up and destroying hash Rx queues",
- dev->data->port_id);
+ DRV_LOG(DEBUG, "port %u stopping device", dev->data->port_id);
mlx5_flow_stop(dev, &priv->flows);
mlx5_traffic_disable(dev);
mlx5_rx_intr_vec_disable(dev);
--
2.11.0
^ permalink raw reply related
* Re: Linux 4.18-rc6
From: Linus Torvalds @ 2018-07-23 20:56 UTC (permalink / raw)
To: Guenter Roeck, David Miller, Martin Schwidefsky; +Cc: Linux Kernel Mailing List
In-Reply-To: <20180723204617.GA14487@roeck-us.net>
Adding davem for the sparc issue, Martin for the s390 one.
On Mon, Jul 23, 2018 at 1:46 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> The s390 gcc plugins related build error reported previously has not really
> been fixed; after feedback from the s390 maintainers, suggesting that it
> won't get fixed in 4.18, I disabled GCC_PLUGINS for s390 builds. This is
> not my preferred solution, but it beats not testing s390:allmodconfig
> builds at all.
Martin - can we just remove the
select HAVE_GCC_PLUGINS
from the s390 Kconfig file (or perhaps add "if BROKEN" or something to
disable it).
Because if it's not getting fixed, it shouldn't be exposed.
> The sparc32 build error is still:
>
> In file included from
> ...
> from drivers/staging/media/omap4iss/iss_video.c:15:
> include/linux/highmem.h: In function 'clear_user_highpage':
> include/linux/highmem.h:137:31: error:
> passing argument 1 of 'sparc_flush_page_to_ram' from incompatible pointer type
>
> due to a missing declaration of 'struct page', as previously reported.
Hmm. I assume it's
arch/sparc/include/asm/cacheflush_32.h
that wants a forward-declaration of 'struct page', and doesn't include
any header files.
The fix is presumably to move the
#include <asm/cacheflush.h>
in drivers/staging/media/omap4iss/iss_video.c down to below the
<linux/*> includes?
The old patchwork link you had for a fix no longer works, I think
because the patchwork database got re-generated during the upgrade
(and the patchwork numbering isn't stable).
Davem?
Linus
^ permalink raw reply
* Re: [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion.
From: Paul E. McKenney @ 2018-07-23 20:56 UTC (permalink / raw)
To: NeilBrown; +Cc: Herbert Xu, Thomas Graf, netdev, linux-kernel
In-Reply-To: <87h8kqrhi0.fsf@notabene.neil.brown.name>
On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
> On Sun, Jul 22 2018, Paul E. McKenney wrote:
> >
> > One issue is that the ->func pointer can legitimately be NULL while on
> > RCU's callback lists. This happens when someone invokes kfree_rcu()
> > with the rcu_head structure at the beginning of the enclosing structure.
> > I could add an offset to avoid this, or perhaps the kmalloc() folks
> > could be persuaded Rao Shoaib's patch moving kfree_rcu() handling to
> > the slab allocators, so that RCU only ever sees function pointers in
> > the ->func field.
> >
> > Either way, this should be hidden behind an API to allow adjustments
> > to be made if needed. Maybe something like is_after_call_rcu()?
> > This would (for example) allow debug-object checks to be used to catch
> > check-after-free bugs.
> >
> > Would something of that sort work for you?
>
> Yes, if you could provide an is_after_call_rcu() API, that would
> perfectly suit my use-case.
After beating my head against the object-debug code a bit, I have to ask
if it would be OK for you if the is_after_call_rcu() API also takes the
function that was passed to RCU.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v6] pidns: introduce syscall translate_pid
From: Michael Tirado @ 2018-07-23 20:55 UTC (permalink / raw)
To: Nagarathnam Muthusamy
Cc: Konstantin Khlebnikov, linux-api, LKML, Jann Horn, Serge Hallyn,
Prakash Sangappa, Oleg Nesterov, Eric W. Biederman, Andrew Morton,
Andy Lutomirski, Michael Kerrisk (man-pages)
In-Reply-To: <db8d560e-47d1-c32f-e4a2-407110f2b5b6@oracle.com>
Hey, I'm not seeing much activity on this so here's my $0.02
> Unix socket automatically translates pid attached to SCM_CREDENTIALS.
> This requires CAP_SYS_ADMIN for sending arbitrary pids and entering
> into pid namespace, this expose process and could be insecure.
Perhaps it would be a good idea to add a sysctl switch that prevents
credential spoofing over AF_UNIX \by default\ if that is the main
concern, or is there another concern and I have read this wrong? I'm
having trouble thinking of a legitimate use of SCM_CREDENTIALS
spoofing that isn't in a debugging or troubleshooting context and
would be more comfortable if it were not possible at all... Anyone
know of a program that relies on this spoofing functionality?
If you look at socket(7) under SO_PEERCRED there is a way to get
credentials at time of connect() for an AF_UNIX SOCK_STREAM, or at
time of socketpair() for a SOCK_DGRAM. I would like to think these
credentials are reliable, but will probably require some extra daemon
to proxy a dgram syslog socket.
^ permalink raw reply
* Re: [PATCH 12/12] i2c: sh_mobile: use core to detect 'no zero length read' quirk
From: Niklas Söderlund @ 2018-07-23 20:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-renesas-soc, linux-kernel
In-Reply-To: <20180723202617.15230-13-wsa+renesas@sang-engineering.com>
Hi Wolfram,
Thanks for your work.
On 2018-07-23 22:26:16 +0200, Wolfram Sang wrote:
> And don't reimplement in the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
>
> drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
> index 5fda4188a9e5..9c7f6f8ceb22 100644
> --- a/drivers/i2c/busses/i2c-sh_mobile.c
> +++ b/drivers/i2c/busses/i2c-sh_mobile.c
> @@ -613,11 +613,6 @@ static void sh_mobile_i2c_xfer_dma(struct sh_mobile_i2c_data *pd)
> static int start_ch(struct sh_mobile_i2c_data *pd, struct i2c_msg *usr_msg,
> bool do_init)
> {
> - if (usr_msg->len == 0 && (usr_msg->flags & I2C_M_RD)) {
> - dev_err(pd->dev, "Unsupported zero length i2c read\n");
> - return -EOPNOTSUPP;
> - }
> -
> if (do_init) {
> /* Initialize channel registers */
> iic_wr(pd, ICCR, ICCR_SCP);
> @@ -758,6 +753,10 @@ static const struct i2c_algorithm sh_mobile_i2c_algorithm = {
> .master_xfer = sh_mobile_i2c_xfer,
> };
>
> +static const struct i2c_adapter_quirks sh_mobile_i2c_quirks = {
> + .flags = I2C_AQ_NO_ZERO_LEN_READ,
> +};
> +
> /*
> * r8a7740 chip has lasting errata on I2C I/O pad reset.
> * this is work-around for it.
> @@ -925,6 +924,7 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
>
> adap->owner = THIS_MODULE;
> adap->algo = &sh_mobile_i2c_algorithm;
> + adap->quirks = &sh_mobile_i2c_quirks;
> adap->dev.parent = &dev->dev;
> adap->retries = 5;
> adap->nr = dev->id;
> --
> 2.11.0
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-next-queue:XDP-hints-EXPERIMENTAL 1/1] drivers/net//ethernet/intel/i40e/i40e_txrx.c:8:10: fatal error: asm/msr.h: No such file or directory
From: kbuild test robot @ 2018-07-23 20:54 UTC (permalink / raw)
To: intel-wired-lan
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git XDP-hints-EXPERIMENTAL
head: 58e0270bb7ac94a31ff0fe372385cfce4198b56c
commit: 58e0270bb7ac94a31ff0fe372385cfce4198b56c [1/1] i40e: Initial support to add hw hints for xdp
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 58e0270bb7ac94a31ff0fe372385cfce4198b56c
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> drivers/net//ethernet/intel/i40e/i40e_txrx.c:8:10: fatal error: asm/msr.h: No such file or directory
#include <asm/msr.h>
^~~~~~~~~~~
compilation terminated.
vim +8 drivers/net//ethernet/intel/i40e/i40e_txrx.c
3
4 #include <linux/prefetch.h>
5 #include <net/busy_poll.h>
6 #include <linux/bpf_trace.h>
7 #include <net/xdp.h>
> 8 #include <asm/msr.h>
9 #include "i40e.h"
10 #include "i40e_trace.h"
11 #include "i40e_prototype.h"
12
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23435 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20180724/80727c70/attachment-0001.bin>
^ permalink raw reply
* Re: [PATCH 1/1] t7406: avoid failures solely due to timing issues
From: Stefan Beller @ 2018-07-23 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitgitgadget, git, Johannes Schindelin
In-Reply-To: <xmqqmuuh69xx.fsf@gitster-ct.c.googlers.com>
On Mon, Jul 23, 2018 at 12:14 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > To prevent such false positives from unnecessarily costing time when
> > investigating test failures, let's take the exact order of the lines out
> > of the equation by sorting them before comparing them.
> > ...
> > cat <<EOF >expect2
> > +Cloning into '$pwd/recursivesuper/super/merging'...
> > +Cloning into '$pwd/recursivesuper/super/none'...
> > +Cloning into '$pwd/recursivesuper/super/rebasing'...
> > +Cloning into '$pwd/recursivesuper/super/submodule'...
> > Submodule 'merging' ($pwd/merging) registered for path '../super/merging'
> > Submodule 'none' ($pwd/none) registered for path '../super/none'
> > Submodule 'rebasing' ($pwd/rebasing) registered for path '../super/rebasing'
> > Submodule 'submodule' ($pwd/submodule) registered for path '../super/submodule'
>
> Thanks. It obviously goes in the right direction to loosen the
> ordering requirement that fundamentally cannot be met, as the log
> message cleanly analizes.
>
> Do we know that the write(2)s that show these lines are atomic, or
> are we merely lucky that we don't see them intermixed in the middle
> of lines (sbeller cc'ed). I _think_ they are but just wanted to
> double check.
Not just the lines, but the whole message per submodule (i.e.
the "Cloning... " lione and its accompanying "done") is one
atomic unit. These messages are from processes invoked via
run_processes_parallel (in run-command.h), which buffers
all output per process.
This test was last touched in c66410ed32a (submodule init:
redirect stdout to stderr, 2016-05-02), merged as f2c96ceb57a
(Merge branch 'sb/submodule-init', 2016-05-17)
The parallelizing effort was made before that
(2335b870fa7 (submodule update: expose parallelism to the
user, 2016-02-29) via bdebbeb3346 (Merge branch
'sb/submodule-parallel-update', 2016-04-06)), but did not
review existing tests for the newly introduced raciness.
Thanks for the fix!
Stefan
^ permalink raw reply
* [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 20:53 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20180723201956.GB26824@linux.intel.com>
On 07/23/2018 01:19 PM, Jarkko Sakkinen wrote:
> In this case I do not have any major evidence of any major benefit *and*
> the change breaks the ABI.
As I said before - this does not break the ABI.
As for the benefits - it help user space in how they implement the receive
path. Application does not need to provide a 4K buffer for every read even
if the response is, for instance 8 bytes long.
Thanks,
--
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] drm_audio_component support for AMD/ATI HDMI codecs
From: Alex Deucher @ 2018-07-23 20:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Maling list - DRI developers, amd-gfx list
In-Reply-To: <20180723145030.25133-1-tiwai@suse.de>
On Mon, Jul 23, 2018 at 10:50 AM, Takashi Iwai <tiwai@suse.de> wrote:
> Hi,
>
> this is a patch set to add the support of drm_audio_component for
> AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
> hotplug and ELD read-out can be achieved directly without the hardware
> access. The best point by that is that it makes the hotplug
> notification working even during runtime suspend.
>
> The support is totally optional and dynamic, hence it still works even
> if either HD-audio or DRM side isn't patched, and it'll fall back to
> the existing method.
I'm still getting my head around how the new callbacks work so bear
with me. It seems like we'd want to set the ELD and report whether
the display is attached in when we detect the displays or fetch the
EDID rather than at modeset time when we enable the audio stream.
Alex
>
> The current patch supports only radeon and a part of amdgpu; the DC
> support isn't included yet.
>
>
> Takashi
>
> ===
>
> Takashi Iwai (4):
> ALSA: hda/hdmi: Use single mutex unlock in error paths
> ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
> drm/radeon: Add audio component support
> drm/amdgpu: Add audio component support
>
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c | 97 ++++++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 +
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 +
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 +
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 +
> drivers/gpu/drm/radeon/radeon.h | 3 +
> drivers/gpu/drm/radeon/radeon_audio.c | 79 ++++++++
> sound/pci/hda/patch_hdmi.c | 209 +++++++++++++++++-----
> 12 files changed, 374 insertions(+), 49 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
>
> --
> 2.18.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 03/15] staging:rtl8192u: Remove unused QOS definitions - Style
From: John Whitmore @ 2018-07-23 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: devel, gregkh, pombredanne, kstewart, tglx, John Whitmore
In-Reply-To: <20180723205031.19816-1-johnfwhitmore@gmail.com>
Remove the unused QOS related types.
Since definitions are not used simply remove from code. This change is
a coding style change and should not impact runtime execution.
Signed-off-by: John Whitmore <johnfwhitmore@gmail.com>
---
.../staging/rtl8192u/ieee80211/rtl819x_Qos.h | 22 -------------------
1 file changed, 22 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_Qos.h b/drivers/staging/rtl8192u/ieee80211/rtl819x_Qos.h
index fb2745da5844..a83abaf3a2ea 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_Qos.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_Qos.h
@@ -4,25 +4,6 @@
#define MAX_WMMELE_LENGTH 64
-//
-// QoS mode.
-// enum 0, 1, 2, 4: since we can use the OR(|) operation.
-//
-// QOS_MODE is redefined for enum can't be ++, | under C++ compiler, 2006.05.17, by rcnjko.
-//typedef enum _QOS_MODE{
-// QOS_DISABLE = 0,
-// QOS_WMM = 1,
-// QOS_EDCA = 2,
-// QOS_HCCA = 4,
-//}QOS_MODE,*PQOS_MODE;
-//
-#define QOS_DISABLE 0
-#define QOS_WMM 1
-#define QOS_WMMSA 2
-#define QOS_EDCA 4
-#define QOS_HCCA 8
-#define QOS_WMM_UAPSD 16 //WMM Power Save, 2006-06-14 Isaiah
-
#define AC_PARAM_SIZE 4
#define WMM_PARAM_ELE_BODY_LEN 18
@@ -506,14 +487,11 @@ typedef struct _BSS_QOS {
AC_PARAM AcParameter[4];
} BSS_QOS, *PBSS_QOS;
-
//
// Ref: sQoSCtlLng and QoSCtl definition in 8185 QoS code.
//#define QoSCtl (( (Adapter->bRegQoS) && (Adapter->dot11QoS.QoSMode &(QOS_EDCA|QOS_HCCA)) ) ?sQoSCtlLng:0)
//
#define sQoSCtlLng 2
-#define QOS_CTRL_LEN(_QosMode) ((_QosMode > QOS_DISABLE) ? sQoSCtlLng : 0)
-
//Added by joseph
//UP Mapping to AC, using in MgntQuery_SequenceNumber() and maybe for DSCP
--
2.18.0
^ 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.