* [PATCH v7 02/12] Documentation: ioctl: Add ioctl numbers for PECI subsystem
From: Jae Hyun Yoo @ 2018-07-23 21:47 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland, Lee Jones,
Joel Stanley, Andrew Jeffery, Jonathan Corbet, Greg Kroah-Hartman,
Gustavo Pimentel, Kishon Vijay Abraham I, Lorenzo Pieralisi,
Darrick J . Wong, Eric Sandeen, Arnd Bergmann, Wu Hao,
Tomohiro Kusumi, Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Randy Dunlap,
Philippe Ombredanne, Vinod Koul, Stephen Boyd, David Kershner,
Uwe Kleine-Konig, Sagar Dharia, Johan Hovold, Thomas Gleixner,
Juergen Gross, Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, Jae Hyun Yoo, James Feist,
Jason M Biils, Vernon Mauery
In-Reply-To: <20180723214751.1733-1-jae.hyun.yoo@linux.intel.com>
This commit updates ioctl-number.txt to reflect ioctl numbers used
by the PECI subsystem.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: James Feist <james.feist@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
---
Documentation/ioctl/ioctl-number.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 7a471381a0c8..9e47d223f15c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -324,6 +324,8 @@ Code Seq#(hex) Include File Comments
0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org>
0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org>
0xB6 all linux/fpga-dfl.h
+0xB7 00-0F uapi/linux/peci-ioctl.h PECI subsystem
+ <mailto:jae.hyun.yoo@linux.intel.com>
0xC0 00-0F linux/usb/iowarrior.h
0xCA 00-0F uapi/misc/cxl.h
0xCA 10-2F uapi/misc/ocxl.h
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v2] hexagon: modify ffs() and fls() to return int
From: Richard Kuo @ 2018-07-23 22:50 UTC (permalink / raw)
To: Randy Dunlap; +Cc: LKML, linux-hexagon, Geert Uytterhoeven
In-Reply-To: <f96af3cd-3316-11a8-d563-dd269f1378a2@infradead.org>
On Sun, Jul 22, 2018 at 04:03:58PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
> printk format build warning. This is due to hexagon's ffs() being
> coded as returning long instead of int.
>
> Fix the printk format warning by changing all of hexagon's ffs() and
> fls() functions to return int instead of long. The variables that
> they return are already int instead of long. This return type
> matches the return type in <asm-generic/bitops/>.
>
> ../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
> ../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
>
> There are no ffs() or fls() allmodconfig build errors after making this
> change.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Richard Kuo <rkuo@codeaurora.org>
> Cc: linux-hexagon@vger.kernel.org
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> v2:
> add hexagon contacts, drop erroneous sh contacts; [thanks, Geert]
> only change return type for ffs() and fls() [thanks, Geert]
> [drop the changes for ffz(), __ffs(), and __fls()]
>
> arch/hexagon/include/asm/bitops.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Richard Kuo <rkuo@codeaurora.org>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* linux-next: manual merge of the arm64 tree with Linus' tree
From: Stephen Rothwell @ 2018-07-23 22:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Olof Johansson, Paul Kocialkowski, Laura Abbott, Greg Hackmann,
Masahiro Yamada
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
Hi all,
Today's linux-next merge of the arm64 tree got a conflict in:
arch/arm64/Makefile
between commits:
38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants")
2893af07e507 ("arm64: add endianness option to LDFLAGS instead of LD")
96f95a17c1cf ("Revert "arm64: Use aarch64elf and aarch64elfb emulation mode variants"")
from Linus' tree and commit:
c931d34ea085 ("arm64: build with baremetal linker target instead of Linux when available")
from the arm64 tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 14/21] diff: add an internal option to dual-color diffs of diffs
From: Stefan Beller @ 2018-07-23 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitgitgadget, git, Johannes Schindelin
In-Reply-To: <xmqqy3e137wd.fsf@gitster-ct.c.googlers.com>
> > - fputs(diff_line_prefix(o), file);
> > + if (first)
> > + fputs(diff_line_prefix(o), file);
> > + else if (!len)
> > + return;
>
> Can you explain this hunk in the log message? I am not sure how the
> description in the log message relates to this change. Is the idea
> of this change essentially "all the existing callers that aren't
> doing the diff-of-diffs send a non-NUL first character, and for them
> this change is a no-op. New callers share most of the remainder of
> emit_line_0() logic but do not want to show the prefix, so the
> support for it is piggy-backing by a special case where first could
> be NUL"?
All but two caller have 'reverse' set to 0, using the arguments as before.
The other two callers are using the function twice to get the prefix
and set sign going, and then the second call to get the rest of the
line going (which needs to omit the prefix as that was done in the
first call) :
+ /* Emit just the prefix, then the rest. */
+ emit_line_0(o, set_sign ? set_sign : set, !!set_sign, reset,
+ sign, "", 0);
+ emit_line_0(o, set, 0, reset, 0, line, len);
I attempted to clean it up on top, but likely got it wrong as we have
no tests for colored range diffs, yet.
https://public-inbox.org/git/20180710174552.30123-3-sbeller@google.com/
My suggestion would be to first clarify emit_line_0 and have its arguments
and its execution map better to each other, (and as a result only needing to
have one call of emit_line_0 instead of two)
That is my understanding of the situation.
Thanks,
Stefan
^ permalink raw reply
* [PATCH 2/2] goldfish: Use dedicated macros instead of manual bit shifting
From: rkir @ 2018-07-23 22:47 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, tkjos, Roman Kiryanov
In-Reply-To: <20180723224727.120952-1-rkir@google.com>
From: Roman Kiryanov <rkir@google.com>
There are dedicated macros (lower_32_bits and upper_32_bits)
available to extract the lower and upper 32 bits. They provide
better readability and could prevent some compilation warnings.
Signed-off-by: Roman Kiryanov <rkir@google.com>
---
include/linux/goldfish.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/linux/goldfish.h b/include/linux/goldfish.h
index 159b4191f15d..265a099cd3b8 100644
--- a/include/linux/goldfish.h
+++ b/include/linux/goldfish.h
@@ -2,6 +2,7 @@
#ifndef __LINUX_GOLDFISH_H
#define __LINUX_GOLDFISH_H
+#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/io.h>
@@ -10,9 +11,11 @@
static inline void gf_write_ptr(const void *ptr, void __iomem *portl,
void __iomem *porth)
{
- writel((u32)(unsigned long)ptr, portl);
+ const unsigned long addr = (unsigned long)ptr;
+
+ writel(lower_32_bits(addr), portl);
#ifdef CONFIG_64BIT
- writel((unsigned long)ptr >> 32, porth);
+ writel(upper_32_bits(addr), porth);
#endif
}
@@ -20,9 +23,9 @@ static inline void gf_write_dma_addr(const dma_addr_t addr,
void __iomem *portl,
void __iomem *porth)
{
- writel((u32)addr, portl);
+ writel(lower_32_bits(addr), portl);
#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
- writel(addr >> 32, porth);
+ writel(upper_32_bits(addr), porth);
#endif
}
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH 1/2] goldfish: Add missing includes to goldfish.h
From: rkir @ 2018-07-23 22:47 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, tkjos, Roman Kiryanov
From: Roman Kiryanov <rkir@google.com>
goldfish.h refers to external symbols such as
dma_addr_t and writel. This causes compilation errors
if this file is included before other header files.
The mentioned symbols are defined in types.h (dma_addr_t)
and io.h (writel).
Signed-off-by: Roman Kiryanov <rkir@google.com>
---
include/linux/goldfish.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/goldfish.h b/include/linux/goldfish.h
index 2835c150c3ff..159b4191f15d 100644
--- a/include/linux/goldfish.h
+++ b/include/linux/goldfish.h
@@ -2,6 +2,9 @@
#ifndef __LINUX_GOLDFISH_H
#define __LINUX_GOLDFISH_H
+#include <linux/types.h>
+#include <linux/io.h>
+
/* Helpers for Goldfish virtual platform */
static inline void gf_write_ptr(const void *ptr, void __iomem *portl,
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting
From: NeilBrown @ 2018-07-23 22:46 UTC (permalink / raw)
To: Brian Norris, Boris Brezillon
Cc: Zhiqiang Hou, linux-mtd, Linux Kernel, David Woodhouse,
Boris BREZILLON, Marek Vasut, Richard Weinberger, Cyrille Pitchen
In-Reply-To: <CAN8TOE904WXMScHo1b2jhusz-L8eGBK=gzUUX079ZVfiFk+HoQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7369 bytes --]
On Mon, Jul 23 2018, Brian Norris wrote:
> Hi Boris,
>
> On Mon, Jul 23, 2018 at 1:10 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
>> On Mon, 23 Jul 2018 11:13:50 -0700
>> Brian Norris <computersforpeace@gmail.com> wrote:
>>> I noticed this got merged, but I wanted to put my 2 cents in here:
>>
>> I wish you had replied to this thread when it was posted (more than
>> 6 months ago). Reverting the patch now implies making some people
>> unhappy because they'll have to resort to their old out-of-tree
>> hacks :-(.
>
> I'd say I'm sorry for not following things closely these days, but I'm
> not really that sorry. There are plenty of other capable hands. And if
> y'all shoot yourselves in the foot, so be it. This patch isn't going
> to blow things up, but now that I did finally notice it (because it
> happened to show up in a list of backports I was looking at), I
> thought better late than never to remind you.
>
> For way of notification: Marek already noticed that we've started down
> a slippery slope months ago:
>
> https://lkml.org/lkml/2018/4/8/141
> Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to
> 3-byte addressing.
>
> I'm not quite sure why that wasn't taken to its logical conclusion --
> that the hack should be reverted.
>
> This problem has been noted many times already, and we've always
> stayed on the side of *avoiding* this hack. A few references from a
> search of my email:
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html
> [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands
>
> http://lists.infradead.org/pipermail/barebox/2014-September/020682.html
> [RFC] MTD m25p80 3-byte addressing and boot problem
>
> http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html
> [PATCH 2/2] m25p80: if supported put chip to deep power down if not used
>
>>> On Wed, Dec 06, 2017 at 10:53:42AM +0800, Zhiqiang Hou wrote:
>>> > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>>> >
>>> > Restore the status to be compatible with legacy devices.
>>> > Take Freescale eSPI boot for example, it copies (in 3 Byte
>>> > addressing mode) the RCW and bootloader images from SPI flash
>>> > without firing a reset signal previously, so the reboot command
>>> > will fail without reseting the addressing mode of SPI flash.
>>> > This patch implement .shutdown function to restore the status
>>> > in reboot process, and add the same operation to the .remove
>>> > function.
>>>
>>> We have previously rejected this patch multiple times, because the above
>>> comment demonstrates a broken product.
>>
>> If we were to only support working HW parts, I fear Linux would not
>> support a lot of HW (that's even more true when it comes to flashes :P).
>
> You stopped allowing UBI to attach to MLC NAND recently, no? That
> sounds like almost the same boat -- you've probably killed quite a few
> shitty products, if they were to use mainline directly.
>
> Anyway, that's derailing the issue. Supporting broken hardware isn't
> something you try to do by applying the same hack to all systems. You
> normally try to apply your hack as narrowly as possible. You seem to
> imply that below. So maybe that's a solution to move forward with. But
> I'd personally be just as happy to see the patch reverted.
>
>>> You cannot guarantee that all
>>> reboots will invoke the .shutdown() method -- what about crashes? What
>>> about watchdog resets? IIUC, those will hit the same broken behavior,
>>> and have unexepcted behavior in your bootloader.
>>
>> Yes, there are corner cases that are not addressed with this approach,
>
> Is a system crash really a corner case? :D
>
>> but it still seems to improve things. Of course, that means the
>> user should try to re-route all HW reset sources to SW ones (RESET input
>> pin muxed to the GPIO controller, watchdog generating an interrupt
>> instead of directly asserting the RESET output pin), which is not always
>> possible, but even when it's not, isn't it better to have a setup that
>> works fine 99% of the time instead of 50% of the time?
>
> Perhaps, but not at the expense of future development. And
> realistically, no one is doing that if they have this hack. Most
> people won't even know that this hack is protecting them at all (so
> again, they won't try to mitigate the problem any further).
>
>>> I suppose one could argue for doing this in remove(), but AIUI you're
>>> just papering over system bugs by introducing the shutdown() function
>>> here. Thus, I'd prefer we drop the shutdown() method to avoid misleading
>>> other users of this driver.
>>
>> I understand your point. But if the problem is about making sure people
>> designing new boards get that right, why not complaining at probe time
>> when things are wrong?
>>
>> I mean, spi_nor_restore() seems to only do something on very specific
>> NORs (those on which a SW RESET does not resets the addressing
>> mode).
>
> The point isn't that SW RESET doesn't reset the addressing mode -- it
> does on any flash I've seen. The point is that most systems are built
> around a stateless assumption in these flash. IIRC, there wasn't even
> a SW RESET command at all until these "huge" flash came around and
> stateful addressing modes came about. So boot ROMs and bootloaders
> would have to be updated to start figuring out when/how to do this SW
> RESET. And once two vendors start doing it differently (I'm not sure:
> have they done this already? I think so) it's no longer something a
> boot ROM will get right.
>
> The only way to get this stuff right is to have a hardware reset, or
> else to avoid all of the stateful modes in software.
>
>> So, how about adding a flag that says "my board has the NOR HW
>> RESET pin wired" (there would be a DT props to set that flag). Then you
>> add a WARN_ON() when this flag is not set and a NOR chip impacted by
>> this bug is detected.
>
> I'd kinda prefer the reverse. There really isn't a need to document
> anything for a working system (software usually can't control this
> RESET pin). The burden should be on the b0rked system to document
> where it needs unsound hacks to survive.
>
>> This way you make sure people are informed that
>> they're doing something wrong, and for those who can't change their HW
>> (because it's already widely deployed), you have a fix that improve
>> things.
>
> Or even better: put this hack behind a DT flag, so that one has to
> admit that their board design is broken before it will even do
> anything. Proposal: "linux,badly-designed-flash-reset".
>
> But, I'd prefer just (partially?) reverting this, and let the authors
> submit something that works. We're not obligated to keep bad hacks in
> the kernel.
>
> Brian
One possibility that occurred to me when I was exploring this issue is
to revert to 3-byte mode whenever 4-byte was not actively in use.
So any access beyond 16Meg is:
switch-to-4-byte ; perform IO ; switch to 3-byte
or similar. On my hardware it would be more efficient to
use the 4-byte opcode to perform the IO, then reset the cached
4th address byte that the NOR chip transparently remembered.
This adds a little overhead, but should be fairly robust.
It doesn't help if something goes terribly wrong while IO is happening,
but I don't think any other software solution does either.
How would you see that approach?
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Bjorn Helgaas @ 2018-07-23 22:45 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723222431.4371.25962.stgit@gimli.home>
On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> Take advantage of NVMe devices using a standard interface to quiesce
> the controller prior to reset, including device specific delays before
> and after that reset. This resolves several NVMe device assignment
> scenarios with two different vendors. The Intel DC P3700 controller
> has been shown to only work as a VM boot device on the initial VM
> startup, failing after reset or reboot, and also fails to initialize
> after hot-plug into a VM. Adding a delay after FLR resolves these
> cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> from FLR with the PCI config space reading back as -1. A reproducible
> instance of this behavior is resolved by clearing the enable bit in
> the configuration register and waiting for the ready status to clear
> (disabling the NVMe controller) prior to FLR.
>
> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.
Do you have any pointers to problem reports or bugzilla entries that
we could include here?
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> drivers/pci/quirks.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index e72c8742aafa..83853562f220 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -28,6 +28,7 @@
> #include <linux/platform_data/x86/apple.h>
> #include <linux/pm_runtime.h>
> #include <linux/switchtec.h>
> +#include <linux/nvme.h>
> #include <asm/dma.h> /* isa_dma_bridge_buggy */
> #include "pci.h"
>
> @@ -3669,6 +3670,116 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, int probe)
> #define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
> #define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
>
> +/* NVMe controller needs delay before testing ready status */
> +#define NVME_QUIRK_CHK_RDY_DELAY (1 << 0)
> +/* NVMe controller needs post-FLR delay */
> +#define NVME_QUIRK_POST_FLR_DELAY (1 << 1)
> +
> +static const struct pci_device_id nvme_reset_tbl[] = {
> + { PCI_DEVICE(0x1bb1, 0x0100), /* Seagate Nytro Flash Storage */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x144d, 0xa821), /* Samsung PM1725 */
We do have PCI_VENDOR_ID_SAMSUNG if you want to use it here. I
don't see Seagate, HGST, etc.
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x144d, 0xa822), /* Samsung PM1725a */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0953), /* Intel DC P3700 */
> + .driver_data = NVME_QUIRK_POST_FLR_DELAY, },
> + { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) },
> + { 0 }
> +};
> +
> +/*
> + * The NVMe specification requires that controllers support PCIe FLR, but
> + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> + * config space) unless the device is quiesced prior to FLR. Do this for
> + * all NVMe devices by disabling the controller before reset. Some Intel
> + * controllers also require an additional post-FLR delay or else attempts
> + * to re-enable will timeout, do that here as well with heuristically
> + * determined delay value. Also maintain the delay between disabling and
> + * checking ready status as used by the native NVMe driver.
> + */
> +static int reset_nvme(struct pci_dev *dev, int probe)
> +{
> + const struct pci_device_id *id;
> + void __iomem *bar;
> + u16 cmd;
> + u32 cfg;
> +
> + id = pci_match_id(nvme_reset_tbl, dev);
> + if (!id || !pcie_has_flr(dev) || !pci_resource_start(dev, 0))
> + return -ENOTTY;
> +
> + if (probe)
> + return 0;
> +
> + bar = pci_iomap(dev, 0, NVME_REG_CC + sizeof(cfg));
> + if (!bar)
> + return -ENOTTY;
> +
> + pci_read_config_word(dev, PCI_COMMAND, &cmd);
> + pci_write_config_word(dev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
> +
> + cfg = readl(bar + NVME_REG_CC);
Apparently this is part of some NVMe spec and all controllers support
this? Is there a public reference you could cite for the details?
> +
> + /* Disable controller if enabled */
> + if (cfg & NVME_CC_ENABLE) {
> + u64 cap = readq(bar + NVME_REG_CAP);
> + unsigned long timeout;
> +
> + /*
> + * Per nvme_disable_ctrl() skip shutdown notification as it
> + * could complete commands to the admin queue. We only intend
> + * to quiesce the device before reset.
> + */
> + cfg &= ~(NVME_CC_SHN_MASK | NVME_CC_ENABLE);
> +
> + writel(cfg, bar + NVME_REG_CC);
> +
> + /* A heuristic value, matches NVME_QUIRK_DELAY_AMOUNT */
> + if (id->driver_data & NVME_QUIRK_CHK_RDY_DELAY)
> + msleep(2300);
> +
> + /* Cap register provides max timeout in 500ms increments */
> + timeout = ((NVME_CAP_TIMEOUT(cap) + 1) * HZ / 2) + jiffies;
> +
> + for (;;) {
> + u32 status = readl(bar + NVME_REG_CSTS);
> +
> + /* Ready status becomes zero on disable complete */
> + if (!(status & NVME_CSTS_RDY))
> + break;
> +
> + msleep(100);
> +
> + if (time_after(jiffies, timeout)) {
> + pci_warn(dev, "Timeout waiting for NVMe ready status to clear after disable\n");
> + break;
> + }
> + }
> + }
> +
> + pci_iounmap(dev, bar);
> +
> + /*
> + * We could use the optional NVM Subsystem Reset here, hardware
> + * supporting this is simply unavailable at the time of this code
> + * to validate in comparison to PCIe FLR. NVMe spec dictates that
> + * NVMe devices shall implement PCIe FLR.
> + */
> + pcie_flr(dev);
> +
> + if (id->driver_data & NVME_QUIRK_POST_FLR_DELAY)
> + msleep(250); /* Heuristic based on Intel DC P3700 */
> +
> + return 0;
> +}
> +
> static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
> reset_intel_82599_sfp_virtfn },
> @@ -3678,6 +3789,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> reset_ivb_igd },
> { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> reset_chelsio_generic_dev },
> + { PCI_ANY_ID, PCI_ANY_ID, reset_nvme },
> { 0 }
> };
>
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Bjorn Helgaas @ 2018-07-23 22:45 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723222431.4371.25962.stgit@gimli.home>
On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> Take advantage of NVMe devices using a standard interface to quiesce
> the controller prior to reset, including device specific delays before
> and after that reset. This resolves several NVMe device assignment
> scenarios with two different vendors. The Intel DC P3700 controller
> has been shown to only work as a VM boot device on the initial VM
> startup, failing after reset or reboot, and also fails to initialize
> after hot-plug into a VM. Adding a delay after FLR resolves these
> cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> from FLR with the PCI config space reading back as -1. A reproducible
> instance of this behavior is resolved by clearing the enable bit in
> the configuration register and waiting for the ready status to clear
> (disabling the NVMe controller) prior to FLR.
>
> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.
Do you have any pointers to problem reports or bugzilla entries that
we could include here?
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> drivers/pci/quirks.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index e72c8742aafa..83853562f220 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -28,6 +28,7 @@
> #include <linux/platform_data/x86/apple.h>
> #include <linux/pm_runtime.h>
> #include <linux/switchtec.h>
> +#include <linux/nvme.h>
> #include <asm/dma.h> /* isa_dma_bridge_buggy */
> #include "pci.h"
>
> @@ -3669,6 +3670,116 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, int probe)
> #define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
> #define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
>
> +/* NVMe controller needs delay before testing ready status */
> +#define NVME_QUIRK_CHK_RDY_DELAY (1 << 0)
> +/* NVMe controller needs post-FLR delay */
> +#define NVME_QUIRK_POST_FLR_DELAY (1 << 1)
> +
> +static const struct pci_device_id nvme_reset_tbl[] = {
> + { PCI_DEVICE(0x1bb1, 0x0100), /* Seagate Nytro Flash Storage */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x144d, 0xa821), /* Samsung PM1725 */
We do have PCI_VENDOR_ID_SAMSUNG if you want to use it here. I
don't see Seagate, HGST, etc.
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x144d, 0xa822), /* Samsung PM1725a */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0953), /* Intel DC P3700 */
> + .driver_data = NVME_QUIRK_POST_FLR_DELAY, },
> + { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) },
> + { 0 }
> +};
> +
> +/*
> + * The NVMe specification requires that controllers support PCIe FLR, but
> + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> + * config space) unless the device is quiesced prior to FLR. Do this for
> + * all NVMe devices by disabling the controller before reset. Some Intel
> + * controllers also require an additional post-FLR delay or else attempts
> + * to re-enable will timeout, do that here as well with heuristically
> + * determined delay value. Also maintain the delay between disabling and
> + * checking ready status as used by the native NVMe driver.
> + */
> +static int reset_nvme(struct pci_dev *dev, int probe)
> +{
> + const struct pci_device_id *id;
> + void __iomem *bar;
> + u16 cmd;
> + u32 cfg;
> +
> + id = pci_match_id(nvme_reset_tbl, dev);
> + if (!id || !pcie_has_flr(dev) || !pci_resource_start(dev, 0))
> + return -ENOTTY;
> +
> + if (probe)
> + return 0;
> +
> + bar = pci_iomap(dev, 0, NVME_REG_CC + sizeof(cfg));
> + if (!bar)
> + return -ENOTTY;
> +
> + pci_read_config_word(dev, PCI_COMMAND, &cmd);
> + pci_write_config_word(dev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
> +
> + cfg = readl(bar + NVME_REG_CC);
Apparently this is part of some NVMe spec and all controllers support
this? Is there a public reference you could cite for the details?
> +
> + /* Disable controller if enabled */
> + if (cfg & NVME_CC_ENABLE) {
> + u64 cap = readq(bar + NVME_REG_CAP);
> + unsigned long timeout;
> +
> + /*
> + * Per nvme_disable_ctrl() skip shutdown notification as it
> + * could complete commands to the admin queue. We only intend
> + * to quiesce the device before reset.
> + */
> + cfg &= ~(NVME_CC_SHN_MASK | NVME_CC_ENABLE);
> +
> + writel(cfg, bar + NVME_REG_CC);
> +
> + /* A heuristic value, matches NVME_QUIRK_DELAY_AMOUNT */
> + if (id->driver_data & NVME_QUIRK_CHK_RDY_DELAY)
> + msleep(2300);
> +
> + /* Cap register provides max timeout in 500ms increments */
> + timeout = ((NVME_CAP_TIMEOUT(cap) + 1) * HZ / 2) + jiffies;
> +
> + for (;;) {
> + u32 status = readl(bar + NVME_REG_CSTS);
> +
> + /* Ready status becomes zero on disable complete */
> + if (!(status & NVME_CSTS_RDY))
> + break;
> +
> + msleep(100);
> +
> + if (time_after(jiffies, timeout)) {
> + pci_warn(dev, "Timeout waiting for NVMe ready status to clear after disable\n");
> + break;
> + }
> + }
> + }
> +
> + pci_iounmap(dev, bar);
> +
> + /*
> + * We could use the optional NVM Subsystem Reset here, hardware
> + * supporting this is simply unavailable at the time of this code
> + * to validate in comparison to PCIe FLR. NVMe spec dictates that
> + * NVMe devices shall implement PCIe FLR.
> + */
> + pcie_flr(dev);
> +
> + if (id->driver_data & NVME_QUIRK_POST_FLR_DELAY)
> + msleep(250); /* Heuristic based on Intel DC P3700 */
> +
> + return 0;
> +}
> +
> static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
> reset_intel_82599_sfp_virtfn },
> @@ -3678,6 +3789,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> reset_ivb_igd },
> { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> reset_chelsio_generic_dev },
> + { PCI_ANY_ID, PCI_ANY_ID, reset_nvme },
> { 0 }
> };
>
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Bjorn Helgaas @ 2018-07-23 22:45 UTC (permalink / raw)
In-Reply-To: <20180723222431.4371.25962.stgit@gimli.home>
On Mon, Jul 23, 2018@04:24:31PM -0600, Alex Williamson wrote:
> Take advantage of NVMe devices using a standard interface to quiesce
> the controller prior to reset, including device specific delays before
> and after that reset. This resolves several NVMe device assignment
> scenarios with two different vendors. The Intel DC P3700 controller
> has been shown to only work as a VM boot device on the initial VM
> startup, failing after reset or reboot, and also fails to initialize
> after hot-plug into a VM. Adding a delay after FLR resolves these
> cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> from FLR with the PCI config space reading back as -1. A reproducible
> instance of this behavior is resolved by clearing the enable bit in
> the configuration register and waiting for the ready status to clear
> (disabling the NVMe controller) prior to FLR.
>
> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.
Do you have any pointers to problem reports or bugzilla entries that
we could include here?
> Signed-off-by: Alex Williamson <alex.williamson at redhat.com>
> ---
> drivers/pci/quirks.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index e72c8742aafa..83853562f220 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -28,6 +28,7 @@
> #include <linux/platform_data/x86/apple.h>
> #include <linux/pm_runtime.h>
> #include <linux/switchtec.h>
> +#include <linux/nvme.h>
> #include <asm/dma.h> /* isa_dma_bridge_buggy */
> #include "pci.h"
>
> @@ -3669,6 +3670,116 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, int probe)
> #define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
> #define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
>
> +/* NVMe controller needs delay before testing ready status */
> +#define NVME_QUIRK_CHK_RDY_DELAY (1 << 0)
> +/* NVMe controller needs post-FLR delay */
> +#define NVME_QUIRK_POST_FLR_DELAY (1 << 1)
> +
> +static const struct pci_device_id nvme_reset_tbl[] = {
> + { PCI_DEVICE(0x1bb1, 0x0100), /* Seagate Nytro Flash Storage */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x144d, 0xa821), /* Samsung PM1725 */
We do have PCI_VENDOR_ID_SAMSUNG if you want to use it here. I
don't see Seagate, HGST, etc.
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(0x144d, 0xa822), /* Samsung PM1725a */
> + .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0953), /* Intel DC P3700 */
> + .driver_data = NVME_QUIRK_POST_FLR_DELAY, },
> + { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) },
> + { 0 }
> +};
> +
> +/*
> + * The NVMe specification requires that controllers support PCIe FLR, but
> + * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
> + * config space) unless the device is quiesced prior to FLR. Do this for
> + * all NVMe devices by disabling the controller before reset. Some Intel
> + * controllers also require an additional post-FLR delay or else attempts
> + * to re-enable will timeout, do that here as well with heuristically
> + * determined delay value. Also maintain the delay between disabling and
> + * checking ready status as used by the native NVMe driver.
> + */
> +static int reset_nvme(struct pci_dev *dev, int probe)
> +{
> + const struct pci_device_id *id;
> + void __iomem *bar;
> + u16 cmd;
> + u32 cfg;
> +
> + id = pci_match_id(nvme_reset_tbl, dev);
> + if (!id || !pcie_has_flr(dev) || !pci_resource_start(dev, 0))
> + return -ENOTTY;
> +
> + if (probe)
> + return 0;
> +
> + bar = pci_iomap(dev, 0, NVME_REG_CC + sizeof(cfg));
> + if (!bar)
> + return -ENOTTY;
> +
> + pci_read_config_word(dev, PCI_COMMAND, &cmd);
> + pci_write_config_word(dev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
> +
> + cfg = readl(bar + NVME_REG_CC);
Apparently this is part of some NVMe spec and all controllers support
this? Is there a public reference you could cite for the details?
> +
> + /* Disable controller if enabled */
> + if (cfg & NVME_CC_ENABLE) {
> + u64 cap = readq(bar + NVME_REG_CAP);
> + unsigned long timeout;
> +
> + /*
> + * Per nvme_disable_ctrl() skip shutdown notification as it
> + * could complete commands to the admin queue. We only intend
> + * to quiesce the device before reset.
> + */
> + cfg &= ~(NVME_CC_SHN_MASK | NVME_CC_ENABLE);
> +
> + writel(cfg, bar + NVME_REG_CC);
> +
> + /* A heuristic value, matches NVME_QUIRK_DELAY_AMOUNT */
> + if (id->driver_data & NVME_QUIRK_CHK_RDY_DELAY)
> + msleep(2300);
> +
> + /* Cap register provides max timeout in 500ms increments */
> + timeout = ((NVME_CAP_TIMEOUT(cap) + 1) * HZ / 2) + jiffies;
> +
> + for (;;) {
> + u32 status = readl(bar + NVME_REG_CSTS);
> +
> + /* Ready status becomes zero on disable complete */
> + if (!(status & NVME_CSTS_RDY))
> + break;
> +
> + msleep(100);
> +
> + if (time_after(jiffies, timeout)) {
> + pci_warn(dev, "Timeout waiting for NVMe ready status to clear after disable\n");
> + break;
> + }
> + }
> + }
> +
> + pci_iounmap(dev, bar);
> +
> + /*
> + * We could use the optional NVM Subsystem Reset here, hardware
> + * supporting this is simply unavailable at the time of this code
> + * to validate in comparison to PCIe FLR. NVMe spec dictates that
> + * NVMe devices shall implement PCIe FLR.
> + */
> + pcie_flr(dev);
> +
> + if (id->driver_data & NVME_QUIRK_POST_FLR_DELAY)
> + msleep(250); /* Heuristic based on Intel DC P3700 */
> +
> + return 0;
> +}
> +
> static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
> reset_intel_82599_sfp_virtfn },
> @@ -3678,6 +3789,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> reset_ivb_igd },
> { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> reset_chelsio_generic_dev },
> + { PCI_ANY_ID, PCI_ANY_ID, reset_nvme },
> { 0 }
> };
>
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Keith Busch @ 2018-07-23 22:45 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723222431.4371.25962.stgit@gimli.home>
On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> Take advantage of NVMe devices using a standard interface to quiesce
> the controller prior to reset, including device specific delays before
> and after that reset. This resolves several NVMe device assignment
> scenarios with two different vendors. The Intel DC P3700 controller
> has been shown to only work as a VM boot device on the initial VM
> startup, failing after reset or reboot, and also fails to initialize
> after hot-plug into a VM. Adding a delay after FLR resolves these
> cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> from FLR with the PCI config space reading back as -1. A reproducible
> instance of this behavior is resolved by clearing the enable bit in
> the configuration register and waiting for the ready status to clear
> (disabling the NVMe controller) prior to FLR.
>
> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.
Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
^ permalink raw reply
* Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Keith Busch @ 2018-07-23 22:45 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723222431.4371.25962.stgit@gimli.home>
On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> Take advantage of NVMe devices using a standard interface to quiesce
> the controller prior to reset, including device specific delays before
> and after that reset. This resolves several NVMe device assignment
> scenarios with two different vendors. The Intel DC P3700 controller
> has been shown to only work as a VM boot device on the initial VM
> startup, failing after reset or reboot, and also fails to initialize
> after hot-plug into a VM. Adding a delay after FLR resolves these
> cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> from FLR with the PCI config space reading back as -1. A reproducible
> instance of this behavior is resolved by clearing the enable bit in
> the configuration register and waiting for the ready status to clear
> (disabling the NVMe controller) prior to FLR.
>
> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.
Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Keith Busch @ 2018-07-23 22:45 UTC (permalink / raw)
In-Reply-To: <20180723222431.4371.25962.stgit@gimli.home>
On Mon, Jul 23, 2018@04:24:31PM -0600, Alex Williamson wrote:
> Take advantage of NVMe devices using a standard interface to quiesce
> the controller prior to reset, including device specific delays before
> and after that reset. This resolves several NVMe device assignment
> scenarios with two different vendors. The Intel DC P3700 controller
> has been shown to only work as a VM boot device on the initial VM
> startup, failing after reset or reboot, and also fails to initialize
> after hot-plug into a VM. Adding a delay after FLR resolves these
> cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> from FLR with the PCI config space reading back as -1. A reproducible
> instance of this behavior is resolved by clearing the enable bit in
> the configuration register and waiting for the ready status to clear
> (disabling the NVMe controller) prior to FLR.
>
> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.
Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
^ permalink raw reply
* Re: [PATCH] doc: fix mlx5 dependencies
From: Yongseok Koh @ 2018-07-23 22:43 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Shahaf Shuler, dev@dpdk.org
In-Reply-To: <20180723114930.22543-1-adrien.mazarguil@6wind.com>
> On Jul 23, 2018, at 4:50 AM, Adrien Mazarguil <adrien.mazarguil@6wind.com> wrote:
>
> The new dependency of mlx5 to libmnl must be reflected in documentation.
>
> Fixes: 4d5cce06231a ("net/mlx5: lay groundwork for switch offloads")
>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> ---
Acked-by: Yongseok Koh <yskoh@mellanox.com>
Thanks
^ permalink raw reply
* [PATCH] media: staging: omap4iss: Include asm/cacheflush.h after generic includes
From: Guenter Roeck @ 2018-07-23 21:39 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-media, devel,
linux-kernel, Linus Torvalds, Guenter Roeck, David Miller,
Randy Dunlap
Including asm/cacheflush.h first results in the following build error when
trying to build sparc32:allmodconfig.
In file included from arch/sparc/include/asm/page.h:10:0,
from arch/sparc/include/asm/string_32.h:13,
from arch/sparc/include/asm/string.h:7,
from include/linux/string.h:20,
from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from arch/sparc/include/asm/smp_32.h:15,
from arch/sparc/include/asm/smp.h:7,
from arch/sparc/include/asm/switch_to_32.h:5,
from arch/sparc/include/asm/switch_to.h:7,
from arch/sparc/include/asm/ptrace.h:120,
from arch/sparc/include/asm/thread_info_32.h:19,
from arch/sparc/include/asm/thread_info.h:7,
from include/linux/thread_info.h:38,
from arch/sparc/include/asm/current.h:15,
from include/linux/mutex.h:14,
from include/linux/notifier.h:14,
from include/linux/clk.h:17,
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
Include generic includes files first to fix the problem.
Fixes: fc96d58c10162 ("[media] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices")
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Miller <davem@davemloft.net>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/staging/media/omap4iss/iss_video.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/omap4iss/iss_video.c b/drivers/staging/media/omap4iss/iss_video.c
index a3a83424a926..16478fe9e3f8 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -11,7 +11,6 @@
* (at your option) any later version.
*/
-#include <asm/cacheflush.h>
#include <linux/clk.h>
#include <linux/mm.h>
#include <linux/pagemap.h>
@@ -24,6 +23,8 @@
#include <media/v4l2-ioctl.h>
#include <media/v4l2-mc.h>
+#include <asm/cacheflush.h>
+
#include "iss_video.h"
#include "iss.h"
--
2.7.4
^ permalink raw reply related
* Re: kernel BUG at mm/shmem.c:LINE!
From: Hugh Dickins @ 2018-07-23 22:42 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Hugh Dickins, syzbot, Kirill A. Shutemov, Andrew Morton,
linux-kernel, linux-mm, syzkaller-bugs
In-Reply-To: <20180723203628.GA18236@bombadil.infradead.org>
On Mon, 23 Jul 2018, Matthew Wilcox wrote:
> On Mon, Jul 23, 2018 at 12:14:41PM -0700, Hugh Dickins wrote:
> > On Mon, 23 Jul 2018, Matthew Wilcox wrote:
> > > On Sun, Jul 22, 2018 at 07:28:01PM -0700, Hugh Dickins wrote:
> > > > Whether or not that fixed syzbot's kernel BUG at mm/shmem.c:815!
> > > > I don't know, but I'm afraid it has not fixed linux-next breakage of
> > > > huge tmpfs: I get a similar page_to_pgoff BUG at mm/filemap.c:1466!
> > > >
> > > > Please try something like
> > > > mount -o remount,huge=always /dev/shm
> > > > cp /dev/zero /dev/shm
> > > >
> > > > Writing soon crashes in find_lock_entry(), looking up offset 0x201
> > > > but getting the page for offset 0x3c1 instead.
> > >
> > > Hmm. I don't see a crash while running that command,
> >
> > Thanks for looking.
> >
> > It is the VM_BUG_ON_PAGE(page_to_pgoff(page) != offset, page)
> > in find_lock_entry(). Perhaps you didn't have CONFIG_DEBUG_VM=y
> > on this occasion? Or you don't think of an oops as a kernel crash,
> > and didn't notice it in dmesg? I see now that I've arranged for oops
> > to crash, since I don't like to miss them myself; but it is a very
> > clean oops, no locks held, so can just kill the process and continue.
>
> Usually I run with that turned on, but somehow in my recent messing
> with my test system, that got turned off. Once I turned it back on,
> it spots the bug instantly.
>
> > Or is there something more mysterious stopping it from showing up for
> > you? It's repeatable for me. When not crashing, that "cp" should fill
> > up about half of RAM before it hits the implicit tmpfs volume limit;
> > but I am assuming a not entirely fragmented machine - it does need
> > to allocate two 2MB pages before hitting the VM_BUG_ON_PAGE().
>
> I tried that too, before noticing that DEBUG_VM was off; raised my test
> VM's memory from 2GB to 8GB.
>
> > Are you sure that those pages are free, rather than most of them tails
> > of one of the two compound pages involved? I think it's the same in your
> > rewrite of struct page, the compound_head field (lru.next), with its low
> > bit set, were how to recognize a tail page.
>
> Yes, PageTail was set, and so was TAIL_MAPPING (0xdead0000000000400).
> What was going on was the first 2MB page was being stored at indices
> 0-511, then the second 2MB page was being stored at indices 64-575
> instead of 512-1023.
>
> I figured out a fix and pushed it to the 'ida' branch in
> git://git.infradead.org/users/willy/linux-dax.git
Great, thanks a lot for sorting that out so quickly. But I've cloned
the tree and don't see today's patch, so assume you've folded the fix
into an existing commit? If possible, please append the diff of today's
fix to this thread so that we can try it out. Or if that's difficult,
please at least tell which files were modified, then I can probably
work it out from the diff of those files against mmotm.
Thanks,
Hugh
>
> It won't be in linux-next tomorrow because the nvdimm people have
> just dumped a pile of patches into their tree that conflict with
> the XArray-DAX rewrite, so Stephen has pulled the XArray tree out
> of linux-next temporarily. I didn't have time to sort out the merge
> conflict today because I judged your bug report more important.
^ permalink raw reply
* Re: [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 21:38 UTC (permalink / raw)
To: James Bottomley, Jarkko Sakkinen
Cc: jgg, linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <1532380412.4112.22.camel@HansenPartnership.com>
On 07/23/2018 02:13 PM, James Bottomley wrote:
> The current patch does, you even provided a use case in your last email
> (it's do command to get sizing followed by do command with correctly
> sized buffer).
The example I provided was: #1 send a command, #2 read the response header
(10 bytes), get the actual response size from the header and then #3 read
the full response (response size - size of the header bytes).
>
> However, if you tie it to O_NONBLOCK, it won't because no-one currently
> opens the TPM device non blocking so it's an ABI conformant
> discriminator of the uses. Tying to O_NONBLOCK should be simple
> because it's in file->f_flags.
I think that it might be an option. Especially that I have this on top of
the async patch. Let's discuss this when Jarkko is back.
Thanks,
--
Tadeusz
^ permalink raw reply
* Re: [PATCH v3 4/6] compress/octeontx: add ops enq deq apis
From: De Lara Guarch, Pablo @ 2018-07-23 22:40 UTC (permalink / raw)
To: Ashish Gupta
Cc: dev@dpdk.org, narayanaprasad.athreya@cavium.com,
mahipal.challa@cavium.com, Shally Verma, Sunila Sahu
In-Reply-To: <20180720190447.7979-5-Ashish.Gupta@caviumnetworks.com>
Hi Ashish,
> -----Original Message-----
> From: Ashish Gupta [mailto:Ashish.Gupta@caviumnetworks.com]
> Sent: Friday, July 20, 2018 8:05 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; narayanaprasad.athreya@cavium.com;
> mahipal.challa@cavium.com; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>; Shally Verma
> <shally.verma@caviumnetworks.com>; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>
> Subject: [PATCH v3 4/6] compress/octeontx: add ops enq deq apis
>
> Add enqueue/dequeue APIs to perform compression/decompression operations
>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> ---
> drivers/compress/octeontx/otx_zip.c | 49 +++++++++
> drivers/compress/octeontx/otx_zip.h | 169
> ++++++++++++++++++++++++++++++++
> drivers/compress/octeontx/otx_zip_pmd.c | 119 ++++++++++++++++++++++
> 3 files changed, 337 insertions(+)
>
...
> int
> zipvf_create(struct rte_compressdev *compressdev) { diff --git
> a/drivers/compress/octeontx/otx_zip.h b/drivers/compress/octeontx/otx_zip.h
> index 3fcd86a86..73a99e624 100644
> --- a/drivers/compress/octeontx/otx_zip.h
> +++ b/drivers/compress/octeontx/otx_zip.h
...
> +
> +static inline int
> +zipvf_prepare_in_buf(struct zip_stream *zstrm, struct rte_comp_op *op)
> +{
> + uint32_t offset, inlen;
> + union zip_zptr_s *sg_list = NULL;
> + struct rte_mbuf *m_src;
> + union zip_inst_s *inst = zstrm->inst;
> + rte_iova_t iova;
> +
> + inlen = op->src.length;
> + offset = op->src.offset;
> + m_src = op->m_src;
> +
> + if (m_src->nb_segs == 1) {
> + /* Prepare direct input data pointer */
> + inst->s.dg = 0;
> + inst->s.inp_ptr_addr.s.addr =
> + rte_pktmbuf_iova_offset(m_src, offset);
> + inst->s.inp_ptr_ctl.s.length = inlen;
> + return 0;
> + }
> +
> + ZIP_PMD_INFO("Input packet is segmented\n");
> +
> + /* Packet is segmented, create gather buffer */
Looks like you actually support SGL, even though you are not setting that in the capabilities.
Now that the SGL tests are available, you should check if the PMD passes the tests
and update the capabilities accordingly.
Also, you should take into account if offset is big enough to cross boundaries
between segments (so first segment to be compressed/decompressed is not the first segment of the SGL).
Look at the comments that I made in the ZLIB PMD (partly based on comments left in the ISAL PMD),
since they should apply to this case too.
> + inst->s.dg = 1;
> + iova = rte_mempool_virt2iova(zstrm->bufs[IN_DATA_BUF]);
> + if (iova & 0xF) {
> + /* Align it to 16 Byte address */
> + iova = ZIP_ALIGN_ROUNDUP(iova, ZIP_SGPTR_ALIGN);
> + }
> +
>
^ permalink raw reply
* Re: rte_mbuf library likely()/unlikely()
From: Wiles, Keith @ 2018-07-23 22:40 UTC (permalink / raw)
To: Morten Brørup; +Cc: Honnappa Nagarahalli, Olivier Matz, dev@dpdk.org
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B421F1@smartserver.smartshare.dk>
> On Jul 23, 2018, at 2:09 PM, Morten Brørup <mb@smartsharesystems.com> wrote:
>
> I haven't performance tested, but they are compiler branch prediction hints pointing out the most likely execution path, so I expect them to have a positive effect.
We really need to make sure this provides any performance improvement and that means it needs to be tested on a number of systems. Can you please do some performance testing or see if we can get the guys doing DPDK performance testing to first give this a try? This area is very sensitive to tweaking.
>
> E.g. the first comparison in __rte_pktmbuf_read() is very unlikely to be true - it would mean that the application is trying to read data beyond the packet.
>
> Please also refer to:
> https://cellperformance.beyond3d.com/articles/2006/04/branch-patterns-using-gcc.html
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Honnappa Nagarahalli
>> Sent: Monday, July 23, 2018 7:52 PM
>> To: Morten Brørup; Olivier Matz
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] rte_mbuf library likely()/unlikely()
>>
>> Do you see any performance improvements with these changes?
>>
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Brørup
>> Sent: Monday, July 23, 2018 8:54 AM
>> To: Olivier Matz <olivier.matz@6wind.com>
>> Cc: dev@dpdk.org
>> Subject: [dpdk-dev] rte_mbuf library likely()/unlikely()
>>
>> 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.
>>
Regards,
Keith
^ permalink raw reply
* Re: [PATCH v4 16/21] range-diff --dual-color: fix bogus white-space warning
From: Junio C Hamano @ 2018-07-23 22:39 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
In-Reply-To: <f4252f2b2198cf13d5b0a21c54098e2a1d8158dd.1532210683.git.gitgitgadget@gmail.com>
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> @@ -177,8 +178,16 @@ static unsigned ws_check_emit_1(const char *line, int len, unsigned ws_rule,
> if (trailing_whitespace == -1)
> trailing_whitespace = len;
>
> + if ((ws_rule & WS_IGNORE_FIRST_SPACE) && len && line[0] == ' ') {
> + if (stream)
> + fwrite(line, 1, 1, stream);
> + written++;
> + if (!trailing_whitespace)
> + trailing_whitespace++;
> + }
> +
> /* Check indentation */
> - for (i = 0; i < trailing_whitespace; i++) {
> + for (i = written; i < trailing_whitespace; i++) {
It is pleasing to see that with a surprisingly clean and small
change like this we can exempt the initial space byte from
SP-before-HT check and from Indent-with-non-tab at the same time.
Very nice.
One reason why a surprisingly small special case is required is
perhaps because we are blessed with the original code being clean
[*1*], and the fact that a line[0] that is not ' ' will not trigger
any indentation related whitespace errors without this special case,
I guess.
> if (line[i] == ' ')
> continue;
> if (line[i] != '\t')
[Footnote]
*1* ws.c used to be almost all my code long time ago, but most of
the shape of the current whitespace_error checking code comes from
c1795bb08aa which is not mine, and I can say good things about it
without feeling embarrassingly boasty ;-)
^ permalink raw reply
* [PATCH v3 1/3] Input: edt-ft5x06 - Add support for regulator
From: Dmitry Torokhov @ 2018-07-23 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180718224645.ns7nvqxvqc6huxcz@core>
On Thu, Jul 19, 2018 at 12:46:45AM +0200, Ond?ej Jirman wrote:
> Hello Myl?ne,
>
> On Wed, Jul 18, 2018 at 08:27:17PM +0200, Myl?ne Josserand wrote:
> > Add the support of regulator to use it as VCC source.
> >
> > Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
> > ---
> > .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> > drivers/input/touchscreen/edt-ft5x06.c | 29 ++++++++++++++++++++++
> > 2 files changed, 30 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > index 025cf8c9324a..48e975b9c1aa 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > @@ -30,6 +30,7 @@ Required properties:
> > Optional properties:
> > - reset-gpios: GPIO specification for the RESET input
> > - wake-gpios: GPIO specification for the WAKE input
> > + - vcc-supply: Regulator that supplies the touchscreen
> >
> > - pinctrl-names: should be "default"
> > - pinctrl-0: a phandle pointing to the pin settings for the
> > diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> > index 1e18ca0d1b4e..aa94494b06b5 100644
> > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > @@ -39,6 +39,7 @@
> > #include <linux/input/mt.h>
> > #include <linux/input/touchscreen.h>
> > #include <linux/of_device.h>
> > +#include <linux/regulator/consumer.h>
> >
> > #define WORK_REGISTER_THRESHOLD 0x00
> > #define WORK_REGISTER_REPORT_RATE 0x08
> > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > struct touchscreen_properties prop;
> > u16 num_x;
> > u16 num_y;
> > + struct regulator *vcc;
> >
> > struct gpio_desc *reset_gpio;
> > struct gpio_desc *wake_gpio;
> > @@ -991,6 +993,22 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
> >
> > tsdata->max_support_points = chip_data->max_support_points;
> >
> > + tsdata->vcc = devm_regulator_get(&client->dev, "vcc");
> > + if (IS_ERR(tsdata->vcc)) {
> > + error = PTR_ERR(tsdata->vcc);
> > + if (error != -EPROBE_DEFER)
> > + dev_err(&client->dev, "failed to request regulator: %d\n",
> > + error);
> > + return error;
> > + }
> > +
> > + error = regulator_enable(tsdata->vcc);
> > + if (error < 0) {
> > + dev_err(&client->dev, "failed to enable vcc: %d\n",
> > + error);
> > + return error;
> > + }
> > +
> > tsdata->reset_gpio = devm_gpiod_get_optional(&client->dev,
> > "reset", GPIOD_OUT_HIGH);
> > if (IS_ERR(tsdata->reset_gpio)) {
You need to disable regulator here. We do not have
devm_regulator_enable() (and Mark had some concerns about mixing managed
and unmanaged APIs for regulators so we can't simply introduce it),
so I'd recommend using devm_add_action_or_reset() and iunstall custom
action to turn off regulator.
> > @@ -1120,20 +1138,31 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
> > static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> > {
> > struct i2c_client *client = to_i2c_client(dev);
> > + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> >
> > if (device_may_wakeup(dev))
> > enable_irq_wake(client->irq);
> >
> > + regulator_disable(tsdata->vcc);
> > +
>
> How will the touchscreen wakeup the system with interrupt if you power it off
> on suspend? Perhaps guard this with device_may_wakeup() too?
Exactly, it should be in an "else" branch.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/3] Input: edt-ft5x06 - Add support for regulator
From: Dmitry Torokhov @ 2018-07-23 22:39 UTC (permalink / raw)
To: Mylène Josserand, robh+dt, mark.rutland, maxime.ripard, wens,
devicetree, linux-kernel, thomas.petazzoni, linux-input,
linux-arm-kernel
In-Reply-To: <20180718224645.ns7nvqxvqc6huxcz@core>
On Thu, Jul 19, 2018 at 12:46:45AM +0200, Ondřej Jirman wrote:
> Hello Mylène,
>
> On Wed, Jul 18, 2018 at 08:27:17PM +0200, Mylène Josserand wrote:
> > Add the support of regulator to use it as VCC source.
> >
> > Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
> > ---
> > .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> > drivers/input/touchscreen/edt-ft5x06.c | 29 ++++++++++++++++++++++
> > 2 files changed, 30 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > index 025cf8c9324a..48e975b9c1aa 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > @@ -30,6 +30,7 @@ Required properties:
> > Optional properties:
> > - reset-gpios: GPIO specification for the RESET input
> > - wake-gpios: GPIO specification for the WAKE input
> > + - vcc-supply: Regulator that supplies the touchscreen
> >
> > - pinctrl-names: should be "default"
> > - pinctrl-0: a phandle pointing to the pin settings for the
> > diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> > index 1e18ca0d1b4e..aa94494b06b5 100644
> > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > @@ -39,6 +39,7 @@
> > #include <linux/input/mt.h>
> > #include <linux/input/touchscreen.h>
> > #include <linux/of_device.h>
> > +#include <linux/regulator/consumer.h>
> >
> > #define WORK_REGISTER_THRESHOLD 0x00
> > #define WORK_REGISTER_REPORT_RATE 0x08
> > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > struct touchscreen_properties prop;
> > u16 num_x;
> > u16 num_y;
> > + struct regulator *vcc;
> >
> > struct gpio_desc *reset_gpio;
> > struct gpio_desc *wake_gpio;
> > @@ -991,6 +993,22 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
> >
> > tsdata->max_support_points = chip_data->max_support_points;
> >
> > + tsdata->vcc = devm_regulator_get(&client->dev, "vcc");
> > + if (IS_ERR(tsdata->vcc)) {
> > + error = PTR_ERR(tsdata->vcc);
> > + if (error != -EPROBE_DEFER)
> > + dev_err(&client->dev, "failed to request regulator: %d\n",
> > + error);
> > + return error;
> > + }
> > +
> > + error = regulator_enable(tsdata->vcc);
> > + if (error < 0) {
> > + dev_err(&client->dev, "failed to enable vcc: %d\n",
> > + error);
> > + return error;
> > + }
> > +
> > tsdata->reset_gpio = devm_gpiod_get_optional(&client->dev,
> > "reset", GPIOD_OUT_HIGH);
> > if (IS_ERR(tsdata->reset_gpio)) {
You need to disable regulator here. We do not have
devm_regulator_enable() (and Mark had some concerns about mixing managed
and unmanaged APIs for regulators so we can't simply introduce it),
so I'd recommend using devm_add_action_or_reset() and iunstall custom
action to turn off regulator.
> > @@ -1120,20 +1138,31 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
> > static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> > {
> > struct i2c_client *client = to_i2c_client(dev);
> > + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> >
> > if (device_may_wakeup(dev))
> > enable_irq_wake(client->irq);
> >
> > + regulator_disable(tsdata->vcc);
> > +
>
> How will the touchscreen wakeup the system with interrupt if you power it off
> on suspend? Perhaps guard this with device_may_wakeup() too?
Exactly, it should be in an "else" branch.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] PCI: Check for PCIe downtraining conditions
From: Tal Gilboa @ 2018-07-23 21:35 UTC (permalink / raw)
To: Alex G., Bjorn Helgaas
Cc: bhelgaas, alex_gagniuc, austin_bolen, shyam_iyer, keith.busch,
linux-pci, linux-kernel, Jeff Kirsher, Ariel Elior, Michael Chan,
Ganesh Goudar, Tariq Toukan, Jakub Kicinski, Dave Airlie,
Alex Deucher
In-Reply-To: <757729fb-1eb5-e1fa-899b-5cef0cc3106c@gmail.com>
On 7/23/2018 8:01 PM, Alex G. wrote:
> On 07/23/2018 12:21 AM, Tal Gilboa wrote:
>> On 7/19/2018 6:49 PM, Alex G. wrote:
>>>
>>>
>>> On 07/18/2018 08:38 AM, Tal Gilboa wrote:
>>>> On 7/16/2018 5:17 PM, Bjorn Helgaas wrote:
>>>>> [+cc maintainers of drivers that already use pcie_print_link_status()
>>>>> and GPU folks]
>>> [snip]
>>>>>
>>>>>> + /* Multi-function PCIe share the same link/status. */
>>>>>> + if ((PCI_FUNC(dev->devfn) != 0) || dev->is_virtfn)
>>>>>> + return;
>>>>>> +
>>>>>> + pcie_print_link_status(dev);
>>>>>> +}
>>>>
>>>> Is this function called by default for every PCIe device? What about
>>>> VFs? We make an exception for them on our driver since a VF doesn't
>>>> have access to the needed information in order to provide a
>>>> meaningful message.
>>>
>>> I'm assuming VF means virtual function. pcie_print_link_status()
>>> doesn't care if it's passed a virtual function. It will try to do its
>>> job. That's why I bail out three lines above, with 'dev->is_virtfn'
>>> check.
>>>
>>> Alex
>>
>> That's the point - we don't want to call pcie_print_link_status() for
>> virtual functions. We make the distinction in our driver. If you want
>> to change the code to call this function by default it shouldn't
>> affect the current usage.
>
> I'm not understanding very well what you're asking. I understand you
> want to avoid printing this message on virtual functions, and that's
> already taken care of. I'm also not changing current behavior. Let's
> get v2 out and start the discussion again based on that.
>
> Alex
Oh ok I see. In this case, please remove the explicit call in mlx4/5
drivers so it won't be duplicated.
^ permalink raw reply
* Re: [pull request][net-next 00/16] Mellanox, mlx5e updates 2018-07-18
From: Saeed Mahameed @ 2018-07-23 21:35 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180719010107.22363-1-saeedm@mellanox.com>
On Wed, 2018-07-18 at 18:00 -0700, Saeed Mahameed wrote:
> Hi dave,
>
> This series includes updates for mlx5e net device driver, with a
> couple
> of major features and some misc updates.
>
> Please notice the mlx5-next merge patch at the beginning:
> "Merge branch 'mlx5-next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux"
>
> For more information please see tag log below.
>
> Please pull and let me know if there's any problem.
>
I will re-post v2 without the "Support PCIe buffer congestion handling
via Devlink" patches until Eran sorts out the review comments.
Thanks,
Saeed.
> Thanks,
> Saeed.
>
> ---
>
> The following changes since commit
> 681d5d071c8bd5533a14244c0d55d1c0e30aa989:
>
> Merge branch 'mlx5-next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux (2018-
> 07-18 15:53:31 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git
> tags/mlx5e-updates-2018-07-18
>
> for you to fetch changes up to
> a0ba57c09676689eb35f13d48990c9674c9baad4:
>
> net/mlx5e: Use PARTIAL_GSO for UDP segmentation (2018-07-18
> 17:26:28 -0700)
>
> ----------------------------------------------------------------
> mlx5e-updates-2018-07-18
>
> This series includes update for mlx5e net device driver.
>
> 1) From Feras Daoud, Added the support for firmware log tracing,
> first by introducing the firmware API needed for the task and then
> For each PF do the following:
> 1- Allocate memory for the tracer strings database and read it
> from the FW to the SW.
> 2- Allocate and dma map tracer buffers.
>
> Traces that will be written into the buffer will be parsed as a
> group
> of one or more traces, referred to as trace message. The trace
> message
> represents a C-like printf string.
> Once a new trace is available FW will generate an event indicates
> new trace/s are
> available and the driver will parse them and dump them using
> tracepoints
> event tracing
>
> Enable mlx5 fw tracing by:
> echo 1 > /sys/kernel/debug/tracing/events/mlx5/mlx5_fw/enable
>
> Read traces by:
> cat /sys/kernel/debug/tracing/trace
>
> 2) From Eran Ben Elisha, Support PCIe buffer congestion handling
> via Devlink, using the new devlink device parameters API, added the
> new
> parameters:
> - Congestion action
> HW mechanism in the PCIe buffer which monitors the amount
> of
> consumed PCIe buffer per host. This mechanism supports
> the
> following actions in case of threshold overflow:
> - Disabled - NOP (Default)
> - Drop
> - Mark - Mark CE bit in the CQE of received packet
> - Congestion mode
> - Aggressive - Aggressive static trigger threshold
> (Default)
> - Dynamic - Dynamically change the trigger threshold
>
> 3) From Natali, Set ECN for received packets using CQE indication.
> Using Eran's congestion settings a user can enable ECN marking, on
> such case
> driver must update ECN CE IP fields when requested by firmware
> (congestion is sensed).
>
> 4) From Roi Dayan, Remove redundant WARN when we cannot find neigh
> entry
>
> 5) From Jianbo Liu, TC double vlan support
> - Support offloading tc double vlan headers match
> - Support offloading double vlan push/pop tc actions
>
> 6) From Boris, re-visit UDP GSO, remove the splitting of UDP_GSO_L4
> packets
> in the driver, and exposes UDP_GSO_L4 as a PARTIAL_GSO feature.
>
> ----------------------------------------------------------------
> Boris Pismenny (1):
> net/mlx5e: Use PARTIAL_GSO for UDP segmentation
>
> Eran Ben Elisha (3):
> net/mlx5: Move all devlink related functions calls to devlink.c
> net/mlx5: Add MPEGC register configuration functionality
> net/mlx5: Support PCIe buffer congestion handling via Devlink
>
> Feras Daoud (5):
> net/mlx5: FW tracer, implement tracer logic
> net/mlx5: FW tracer, create trace buffer and copy strings
> database
> net/mlx5: FW tracer, events handling
> net/mlx5: FW tracer, parse traces and kernel tracing support
> net/mlx5: FW tracer, Enable tracing
>
> Jianbo Liu (3):
> net/mlx5e: Support offloading tc double vlan headers match
> net/mlx5e: Refactor tc vlan push/pop actions offloading
> net/mlx5e: Support offloading double vlan push/pop tc actions
>
> Natali Shechtman (1):
> net/mlx5e: Set ECN for received packets using CQE indication
>
> Roi Dayan (1):
> net/mlx5e: Remove redundant WARN when we cannot find neigh
> entry
>
> Saeed Mahameed (2):
> net/mlx5: FW tracer, register log buffer memory key
> net/mlx5: FW tracer, Add debug prints
>
> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 6 +-
> drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 267 ++++++
> drivers/net/ethernet/mellanox/mlx5/core/devlink.h | 41 +
> .../ethernet/mellanox/mlx5/core/diag/fw_tracer.c | 947
> +++++++++++++++++++++
> .../ethernet/mellanox/mlx5/core/diag/fw_tracer.h | 175 ++++
> .../mellanox/mlx5/core/diag/fw_tracer_tracepoint.h | 78 ++
> .../mellanox/mlx5/core/en_accel/en_accel.h | 27 +-
> .../ethernet/mellanox/mlx5/core/en_accel/rxtx.c | 109 ---
> .../ethernet/mellanox/mlx5/core/en_accel/rxtx.h | 14 -
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 9 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 35 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 3 +
> drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 2 +
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 134 ++-
> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 11 +
> drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 21 +-
> .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 23 +-
> drivers/net/ethernet/mellanox/mlx5/core/main.c | 23 +-
> include/linux/mlx5/device.h | 7 +
> include/linux/mlx5/driver.h | 3 +
> 20 files changed, 1745 insertions(+), 190 deletions(-)
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/devlink.h
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h
> create mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer_tracepoint.h
> delete mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/rxtx.c
> delete mode 100644
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/rxtx.h
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix tci mask filter
From: Yongseok Koh @ 2018-07-23 22:38 UTC (permalink / raw)
To: Nélio Laranjeiro; +Cc: dev@dpdk.org, Shahaf Shuler, stable@dpdk.org
In-Reply-To: <ea99ac4effbb0ab7ec01de2e068be910936fc1bf.1532330280.git.nelio.laranjeiro@6wind.com>
> On Jul 23, 2018, at 12:18 AM, Nelio Laranjeiro <nelio.laranjeiro@6wind.com> wrote:
>
> In mlx5_traffic_enable() the TCI mask for the VLAN is wrong causing the
> sub flow engine to reject the rule.
>
> Fixes: 272733b5ebfd ("net/mlx5: use flow to enable unicast traffic")
> Cc: stable@dpdk.org
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> ---
Acked-by: Yongseok Koh <yskoh@mellanox.com>
Thanks
^ permalink raw reply
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.