It's been a few weeks. Thoughts on this one?
On Wed, 2018-07-25 at 17:02 -0600, Jon Derrick wrote:
> Currently, a hotplug bridge will be given hpmemsize additional memory
> if
> available, in order to satisfy any future hotplug allocation
> requirements.
>
> These calculations don't consider the
On Thu, 2018-08-16 at 08:49 -0700, Matthew Wilcox wrote:
> On Wed, Aug 15, 2018 at 03:26:39PM -0600, Jon Derrick wrote:
> > Some users may want to disable downstream port containment (DPC),
> > so
> > give them this option
>
> Is it possible they might only want to disable DPC on a subset of the
Hi Jonas,
On Thu, 2018-03-01 at 14:27 +0100, Jonas Rabenstein wrote:
> The length must be given as bytes and not as 4 bit tuples.
>
> Signed-off-by: Jonas Rabenstein n.de>
> ---
> block/sed-opal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
This looks correct.
Adding my Ack unless Scott has objections
Acked-by: Jonathan Derrick
On Thu, 2018-03-01 at 14:26 +0100, Jonas Rabenstein wrote:
> Tokens are prefixed by a variable length of bytes. If a bytestring is
> not stored in an tiny or short atom, we have
I found the same issue:
https://patchwork.ozlabs.org/patch/989272/
Tested-by: Jon Derrick
On Mon, 2018-11-05 at 18:32 -0600, Alex G. wrote:
> ping
>
> On 09/18/2018 05:15 PM, Alexandru Gagniuc wrote:
> > When a PCI device is gone, we don't want to send IO to it if we can
> > avoid it. We
Hi Bjorn,
On Tue, 2018-10-09 at 12:56 -0500, Bjorn Helgaas wrote:
> On Tue, Sep 04, 2018 at 12:33:09PM -0600, Jon Derrick wrote:
> > During probe, the port driver will disable error reporting and
> > assumes
> > it will be enabled later by the AER driver's pci_walk_bus()
> > sequence.
> > This
Hi,
After giving this a few days thought, I think the right way is to call
pci_enable_pcie_error_reporting after portdrv probe, and prevent AER's
pci_walk_bus from enabling err reporting if the port hasn't been
probed.
I'm going to Self-NAK this and follow-up
Sorry for the noise
On Sat,
On Mon, 2018-09-17 at 15:53 -0500, Bjorn Helgaas wrote:
> On Thu, Aug 30, 2018 at 04:11:59PM -0600, Jon Derrick wrote:
> > Hi Bjorn,
> >
> > Sorry for the delay on this one and pushing it after RC1.
> > Feel free to queue it up for 4.20 if it looks fine.
> >
> > I've added comments to the git
Hi Jonas,
On Thu, 2018-03-01 at 14:27 +0100, Jonas Rabenstein wrote:
> The length must be given as bytes and not as 4 bit tuples.
>
> Signed-off-by: Jonas Rabenstein n.de>
> ---
> block/sed-opal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/sed-opal.c
This looks correct.
Adding my Ack unless Scott has objections
Acked-by: Jonathan Derrick
On Thu, 2018-03-01 at 14:26 +0100, Jonas Rabenstein wrote:
> Tokens are prefixed by a variable length of bytes. If a bytestring is
> not stored in an tiny or short atom, we have to skip more than one
>
Hi Jason
On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > Devices on the VMD bus use their own MSI irq domain, but it is not
> > distinguishable from regular PCI/MSI irq domains. This
+Megha
On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 12:45:30PM +0000, Derrick, Jonathan wrote:
> > Hi Jason
> >
> > On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thoma
On Wed, 2020-08-26 at 21:42 +0100, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:16:51 +0100,
> Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > PCI devices behind a VMD bus are not subject to interrupt remapping, but
> > the irq domain for VMD MSI cannot be distinguished from a regular
On Tue, 2020-08-25 at 06:23 +, Christoph Hellwig wrote:
> On Fri, Aug 21, 2020 at 08:32:20PM +0800, Kai-Heng Feng wrote:
> > New Intel laptops with VMD cannot reach deeper power saving state,
> > renders very short battery time.
>
> So what about just disabling VMD given how bloody pointless
On Thu, 2020-08-27 at 06:34 +, h...@infradead.org wrote:
> On Wed, Aug 26, 2020 at 09:43:27PM +0000, Derrick, Jonathan wrote:
> > Feel free to review my set to disable the MSI remapping which will
> > make
> > it perform as well as direct-attached:
> >
> > htt
On Thu, 2020-08-27 at 17:23 +0100, h...@infradead.org wrote:
> On Thu, Aug 27, 2020 at 04:13:44PM +0000, Derrick, Jonathan wrote:
> > On Thu, 2020-08-27 at 06:34 +, h...@infradead.org wrote:
> > > On Wed, Aug 26, 2020 at 09:43:27PM +, Derrick, Jonathan wrote:
> > &g
Hi Bjorn
On Wed, 2020-09-09 at 20:55 -0500, Bjorn Helgaas wrote:
> [+cc Saheed]
>
> On Fri, Aug 21, 2020 at 08:32:20PM +0800, Kai-Heng Feng wrote:
> > New Intel laptops with VMD cannot reach deeper power saving state,
> > renders very short battery time.
> >
> > As BIOS may not be able to
On Thu, 2020-09-10 at 14:17 -0500, Bjorn Helgaas wrote:
> On Thu, Sep 10, 2020 at 06:52:48PM +0000, Derrick, Jonathan wrote:
> > On Thu, 2020-09-10 at 12:38 -0500, Bjorn Helgaas wrote:
> > > On Thu, Sep 10, 2020 at 04:33:39PM +, Derrick, Jonathan wrote:
> > > &g
On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> > In order to support direct interrupt remapping of VMD child devices,
> > ensure that the IRTE is
On Tue, 2020-10-20 at 21:21 -0500, Bjorn Helgaas wrote:
> On Wed, Oct 21, 2020 at 01:20:24AM +0000, Derrick, Jonathan wrote:
> > On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > > > VMD
On Thu, 2019-08-08 at 10:32 -0600, Keith Busch wrote:
> On Thu, Aug 08, 2019 at 09:04:28AM +0200, Thomas Gleixner wrote:
> > On Wed, 7 Aug 2019, Jon Derrick wrote:
> > > The current irq spreading algorithm spreads vectors amongst cpus evenly
> > > per node. If a node has more cpus than another
On Fri, 2019-08-16 at 09:53 -0600, Keith Busch wrote:
> On Thu, Aug 15, 2019 at 07:28:49PM -0700, Ming Lei wrote:
> > Now __irq_build_affinity_masks() spreads vectors evenly per node, and
> > all vectors may not be spread in case that each numa node has different
> > CPU number, then the warning
Hi Lorenzo,
On Tue, 2020-07-28 at 13:49 -0600, Jon Derrick wrote:
> The Intel Volume Management Device acts similar to a PCI-to-PCI bridge in that
> it changes downstream devices' requester-ids to its own. As VMD supports PCIe
> devices, it has its own MSI/X table and transmits child device MSI/X
On Tue, 2019-09-17 at 11:41 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 16, 2019 at 07:54:35AM -0600, Jon Derrick wrote:
> > The shadow offset scratchpad was moved to 0x2000-0x2010. Update the
> > location to get the correct shadow offset.
>
> Hi Jon,
>
> what does "was moved" mean ? Would
On Tue, 2019-09-17 at 15:05 +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 17, 2019 at 01:55:59PM +0000, Derrick, Jonathan wrote:
> > On Tue, 2019-09-17 at 11:41 +0100, Lorenzo Pieralisi wrote:
> > > On Mon, Sep 16, 2019 at 07:54:35AM -0600, Jon Derrick wrote:
> > > >
On Tue, 2019-09-17 at 16:15 +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 17, 2019 at 02:45:03PM +0000, Derrick, Jonathan wrote:
> > On Tue, 2019-09-17 at 15:05 +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Sep 17, 2019 at 01:55:59PM +, Derrick, Jonathan wrote:
> > >
On Tue, 2019-09-17 at 17:37 +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 17, 2019 at 03:51:39PM +0000, Derrick, Jonathan wrote:
>
> [...]
>
> > Sorry for the confusion.
> >
> > These changes only affect systems with VMD devices with 8086:28C0
> > devic
On Fri, 2020-05-01 at 11:35 -0600, Jonathan Derrick wrote:
> On Fri, 2020-05-01 at 12:16 -0500, Bjorn Helgaas wrote:
> > On Thu, Apr 30, 2020 at 12:46:07PM -0600, Jon Derrick wrote:
> > > Hi Bjorn & Kuppuswamy,
> > >
> > > I see a problem in the DPC ECN [1] to _OSC in that it doesn't give us a
>
Hi Ming,
On Tue, 2019-08-13 at 16:14 +0800, Ming Lei wrote:
> The two-stage spread is done on same irq vectors, and we just need that
> either one stage covers all vector, not two stage work together to cover
> all vectors.
>
> So enhance the warning check to make sure all vectors are spread.
>
On Wed, 2019-10-02 at 19:23 -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix sparse warning: (missing '=')
> ../block/sed-opal.c:133:17: warning: obsolete array initializer, use C99
> syntax
>
> Fixes: ff91064ea37c ("block: sed-opal: check size of shadow mbr")
> Signed-off-by: Randy
On Thu, 2019-10-03 at 11:40 -0400, Scott Bauer wrote:
> On Wed, Oct 02, 2019 at 07:23:15PM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap
> >
> > sparse warns about incorrect type when using __be64 data.
> > It is not being converted to CPU-endian but it should be.
> >
> > Fixes these sparse
lgtm. Don't know how often we'll see these configurations but it looks
like it'll be handled gracefully
Thanks for the effort
Reviewed-by: Jon Derrick
On Mon, 2019-08-19 at 20:49 +0800, Ming Lei wrote:
> Now __irq_build_affinity_masks() spreads vectors evenly per node, and
> all vectors may not
lgtm
Reviewed-by: Jon Derrick
On Mon, 2019-08-19 at 20:49 +0800, Ming Lei wrote:
> One invariant of __irq_build_affinity_masks() is that all CPUs in the
> specified masks( cpu_mask AND node_to_cpumask for each node) should be
> covered during the spread. Even though all requested vectors have
On Fri, 2020-05-01 at 12:16 -0500, Bjorn Helgaas wrote:
> On Thu, Apr 30, 2020 at 12:46:07PM -0600, Jon Derrick wrote:
> > Hi Bjorn & Kuppuswamy,
> >
> > I see a problem in the DPC ECN [1] to _OSC in that it doesn't give us a way
> > to
> > determine if firmware supports _OSC DPC negotation, and
Sorry I didn't see this before my comments yesterday
For either individual or split set,
Reviewed-by: Jon Derrick
Thanks Kuppuswamy
On Mon, 2020-04-27 at 19:02 -0500, Bjorn Helgaas wrote:
> [+cc Jon, Alexandru]
>
> On Sun, Apr 26, 2020 at 11:30:06AM -0700,
>
On Wed, 2020-05-06 at 10:09 +0800, Daniel Drake wrote:
> On Wed, May 6, 2020 at 10:03 AM Lu Baolu wrote:
> > https://lkml.org/lkml/2020/4/14/616
> > [This has been applied in iommu/next.]
> >
> > Hence, there is no need to keep the private domain implementation
> > in the Intel IOMMU driver.
Hi David,
I've been experiencing a performance regression when running a parallel
compilation (eg, make -j72) on recent kernels.
I bisected it to this commit:
commit b667b867344301e24f21d4a4c844675ff61d89e1
Author: David Howells
Date: Tue Sep 24 16:09:04 2019 +0100
pipe: Advance tail
On Thu, 2020-06-18 at 18:05 -0700, Matthew Wilcox wrote:
> On Thu, Jun 18, 2020 at 11:52:55PM +0000, Derrick, Jonathan wrote:
> > Hi David,
> >
> > I've been experiencing a performance regression when running a parallel
> > compilation (eg, make -j72) on recent kerne
On Mon, 2019-02-04 at 22:07 +0100, David Kozub wrote:
> On Mon, 4 Feb 2019, Christoph Hellwig wrote:
>
> > On Fri, Feb 01, 2019 at 09:50:10PM +0100, David Kozub wrote:
> > > From: Jonas Rabenstein
> > >
> > > All add_token_* functions have a common set of conditions that have to
> > > be
Looks good
Reviewed-by: Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> response_get_token had already been in place, its functionality had
> been duplicated within response_get_{u64,bytestring} with the same error
> handling. Unify the handling by reusing response_get_token
Normally I wouldn't like decreasing the readability (having a STARTLIST
without an ENDLIST in the same function), but this makes a lot of sense
with 5/16
Acked-by: Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> Every step ends by calling cmd_finalize (via finalize_and_send)
Looks fine with 4/16
Acked-by: Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> Every step starts with resetting the cmd buffer as well as the comid and
> constructs the appropriate OPAL_CALL command. Consequently, those
> actions may be combined into one generic function. On
Looks good
Reviewed-by: Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> From: Jonas Rabenstein
>
> Also the values of OPAL_UID_LENGTH and OPAL_METHOD_LENGTH are the same,
> it is weird to use OPAL_UID_LENGTH for the definition of the methods.
>
> Signed-off-by: Jonas
Looks good
Reviewed-by Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> From: Jonas Rabenstein
>
> Split the header generation from the (normal) memcpy part if a
> bytestring is copied into the command buffer. This allows in-place
> generation of the bytestring content. For
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> From: Jonas Rabenstein
>
> Allow modification of the shadow mbr. If the shadow mbr is not marked as
> done, this data will be presented read only as the device content. Only
> after marking the shadow mbr as done and unlocking a locking
Looks good otherwise
Reviewed-by: Jon Derrick
On Mon, 2019-02-04 at 21:28 +0100, David Kozub wrote:
> On Mon, 4 Feb 2019, Christoph Hellwig wrote:
>
> > On Fri, Feb 01, 2019 at 09:50:08PM +0100, David Kozub wrote:
> > > This should make no change in functionality.
> > > The formatting changes
On Mon, 2019-02-04 at 23:44 +0100, David Kozub wrote:
> On Mon, 4 Feb 2019, Christoph Hellwig wrote:
>
> > > + /* first do a discovery0 */
> > > + error = opal_discovery0_step(dev);
> > >
> > > + for (state = 0; !error && state < n_steps; state++)
> > > + error = execute_step(dev,
Looks good
Reviewed-by: Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> From: Jonas Rabenstein
>
> Instead of having multiple places defining the same argument list to get
> a specific column of a sed-opal table, provide a generic version and
> call it from those
Looks good
Reviewed-by: Jon Derrick
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> As the function is responsible for executing the individual steps supplied
> in the steps argument, execute_steps is a more descriptive name than the
> rather generic next.
>
> Signed-off-by: David
On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> From: Jonas Rabenstein
>
> Check whether the shadow mbr does fit in the provided space on the
> target. Also a proper firmware should handle this case and return an
> error we may prevent problems or even damage with crappy firmwares.
>
>
On Thu, 2019-02-07 at 23:56 +0100, David Kozub wrote:
> On Mon, 4 Feb 2019, Christoph Hellwig wrote:
>
> > On Fri, Feb 01, 2019 at 09:50:17PM +0100, David Kozub wrote:
> > > From: Jonas Rabenstein
> > >
> > > Enable users to mark the shadow mbr as done without completely
> > > deactivating the
Looks good to me
Thanks Christoph
Acked-by: Jon Derrick
On Fri, 2018-12-14 at 15:17 -0600, Bjorn Helgaas wrote:
> Conventional spelling in subject is
>
> PCI: vmd: Use dma_* APIs instead of direct method calls
>
> On Fri, Dec 07, 2018 at 11:07:19AM -0800, Christoph Hellwig wrote:
> > With
On Thu, 2018-08-16 at 08:49 -0700, Matthew Wilcox wrote:
> On Wed, Aug 15, 2018 at 03:26:39PM -0600, Jon Derrick wrote:
> > Some users may want to disable downstream port containment (DPC),
> > so
> > give them this option
>
> Is it possible they might only want to disable DPC on a subset of the
It's been a few weeks. Thoughts on this one?
On Wed, 2018-07-25 at 17:02 -0600, Jon Derrick wrote:
> Currently, a hotplug bridge will be given hpmemsize additional memory
> if
> available, in order to satisfy any future hotplug allocation
> requirements.
>
> These calculations don't consider the
LGTM
Reviewed-by: Jon Derrick
On Wed, 2019-05-01 at 01:20 +0200, David Kozub wrote:
> From: Jonas Rabenstein
>
> Enable users to mark the shadow mbr as done without completely
> deactivating the shadow mbr feature. This may be useful on reboots,
> when the power to the disk is not
On Wed, 2019-04-10 at 16:45 -0500, Bjorn Helgaas wrote:
> [+cc Keith, Jonathan (VMD guys)]
>
> I'm OK with this from a PCI perspective. It would be nice if
>
> dma_domain_list
> dma_domain_list_lock
> add_dma_domain()
> del_dma_domain()
> set_dma_domain_ops()
>
> could all be moved
Hi David,
On Sun, 2019-02-10 at 18:46 +0100, David Kozub wrote:
> On Fri, 8 Feb 2019, Derrick, Jonathan wrote:
>
> > On Mon, 2019-02-04 at 23:44 +0100, David Kozub wrote:
> > > On Mon, 4 Feb 2019, Christoph Hellwig wrote:
> > >
> > > > > + /* f
On Sun, 2019-02-10 at 21:05 +0100, David Kozub wrote:
> On Fri, 8 Feb 2019, Derrick, Jonathan wrote:
>
> > On Fri, 2019-02-01 at 21:50 +0100, David Kozub wrote:
> > > From: Jonas Rabenstein
> > >
> > > Check whether the shadow mbr does fit in the provide
Hi,
After giving this a few days thought, I think the right way is to call
pci_enable_pcie_error_reporting after portdrv probe, and prevent AER's
pci_walk_bus from enabling err reporting if the port hasn't been
probed.
I'm going to Self-NAK this and follow-up
Sorry for the noise
On Sat,
I found the same issue:
https://patchwork.ozlabs.org/patch/989272/
Tested-by: Jon Derrick
On Mon, 2018-11-05 at 18:32 -0600, Alex G. wrote:
> ping
>
> On 09/18/2018 05:15 PM, Alexandru Gagniuc wrote:
> > When a PCI device is gone, we don't want to send IO to it if we can
> > avoid it. We
On Mon, 2018-09-17 at 15:53 -0500, Bjorn Helgaas wrote:
> On Thu, Aug 30, 2018 at 04:11:59PM -0600, Jon Derrick wrote:
> > Hi Bjorn,
> >
> > Sorry for the delay on this one and pushing it after RC1.
> > Feel free to queue it up for 4.20 if it looks fine.
> >
> > I've added comments to the git
Hi Bjorn,
On Tue, 2018-10-09 at 12:56 -0500, Bjorn Helgaas wrote:
> On Tue, Sep 04, 2018 at 12:33:09PM -0600, Jon Derrick wrote:
> > During probe, the port driver will disable error reporting and
> > assumes
> > it will be enabled later by the AER driver's pci_walk_bus()
> > sequence.
> > This
62 matches
Mail list logo