Re: [PATCH 5/6] x86/apic/msi: Use Real PCI DMA device when configuring IRTE

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

Re: [PATCH 5/6] x86/apic/msi: Use Real PCI DMA device when configuring IRTE

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

Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI

+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

Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI

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

Re: [PATCH] PCI/ASPM: Enable ASPM for links under VMD domain

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

Re: [PATCH] PCI/ASPM: Enable ASPM for links under VMD domain

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

Re: [PATCH] PCI/ASPM: Enable ASPM for links under VMD domain

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

Re: [PATCH] PCI/ASPM: Enable ASPM for links under VMD domain

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

Re: [PATCH] PCI/ASPM: Enable ASPM for links under VMD domain

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

Re: [patch V2 23/46] irqdomain/msi: Provide DOMAIN_BUS_VMD_MSI

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

Re: [PATCH 0/6] VMD MSI Remapping Bypass

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

Re: Parallel compilation performance regression

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

Parallel compilation performance regression

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

Re: [PATCH v3 0/2] PCI/ERR: Allow Native AER/DPC using _OSC

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 >

Re: [PATCH v4 0/3] Replace private domain with per-group default domain

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.

Re: [PATCH v3 0/2] PCI/ERR: Allow Native AER/DPC using _OSC

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

Re: [PATCH v1 1/1] PCI/AER: Use _OSC negotiation to determine AER ownership

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, >

Re: [PATCH 2/2] block: sed-opal: fix sparse warning: convert __be64 data

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

Re: [PATCH 1/2] block: sed-opal: fix sparse warning: obsolete array init.

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

Re: [PATCH 2/2] PCI: vmd: Fix shadow offsets to reflect spec changes

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

Re: [PATCH 2/2] PCI: vmd: Fix shadow offsets to reflect spec changes

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: > > >

Re: [PATCH 2/2] PCI: vmd: Fix shadow offsets to reflect spec changes

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: > > > >

Re: [PATCH 2/2] PCI: vmd: Fix shadow offsets to reflect spec changes

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

Re: [PATCH V6 1/2] genirq/affinity: Improve __irq_build_affinity_masks()

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

Re: [PATCH V6 2/2] genirq/affinity: Spread vectors on node according to nr_cpu ratio

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

Re: [PATCH V5 2/2] genirq/affinity: Spread vectors on node according to nr_cpu ratio

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

Re: [PATCH V3 1/3] genirq/affinity: Enhance warning check

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. >

Re: [PATCH] genirq/affinity: report extra vectors on uneven nodes

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

Re: [PATCH 1/3] block: sed-opal: add ioctl for done-mark of shadow mbr

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

Re: [PATCH 2/2] x86/pci: Clean up usage of X86_DEV_DMA_OPS

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

Re: [PATCH v4 13/16] block: sed-opal: check size of shadow mbr

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

Re: [PATCH v4 15/16] block: sed-opal: don't repeat opal_discovery0 in each steps array

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

Re: [PATCH v4 13/16] block: sed-opal: check size of shadow mbr

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. > >

Re: [PATCH v4 16/16] block: sed-opal: rename next to execute_steps

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

Re: [PATCH v4 15/16] block: sed-opal: don't repeat opal_discovery0 in each steps array

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,

Re: [PATCH v4 12/16] block: sed-opal: unify retrieval of table columns

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

Re: [PATCH v4 01/16] block: sed-opal: fix typos and formatting

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

Re: [PATCH v4 09/16] block: sed-opal: split generation of bytestring header and content

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

Re: [PATCH v4 11/16] block: sed-opal: ioctl for writing to shadow mbr

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

Re: [PATCH v4 02/16] block: sed-opal: use correct macro for method length

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

Re: [PATCH v4 05/16] block: sed-opal: unify cmd start

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

Re: [PATCH v4 07/16] block: sed-opal: reuse response_get_token to decrease code duplication

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

Re: [PATCH v4 04/16] block: sed-opal: close parameter list in cmd_finalize

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)

Re: [PATCH v4 03/16] block: sed-opal: unify space check in add_token_*

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

Re: [PATCH v4 10/16] block: sed-opal: add ioctl for done-mark of shadow mbr

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

Re: [PATCH 14/15] vmd: use the proper dma_* APIs instead of direct methods calls

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

Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

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

Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

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

Re: [PATCH] PCI/portdrv: Enable error reporting on managed ports

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

Re: [PATCH] PCI/portdrv: Enable error reporting on managed ports

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

Re: [PATCH v2] PCI hotplug Eq v2

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

Re: [PATCH v2] PCI hotplug Eq v2

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

Re: [PATCH] PCI/AER: Fix an AER enabling/disabling race

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,

Re: [PATCH] PCI/AER: Fix an AER enabling/disabling race

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,

Re: [PATCH 1/2] PCI/DPC: Add 'nodpc' parameter

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

Re: [PATCH 1/2] PCI/DPC: Add 'nodpc' parameter

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

Re: [PATCH] PCI: Equalize hotplug memory for non/occupied slots

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

Re: [PATCH] PCI: Equalize hotplug memory for non/occupied slots

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

Re: [PATCH][RESEND] block: sed-opal: fix response string extraction

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

Re: [PATCH][RESEND] block: sed-opal: fix response string extraction

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 >

Re: [PATCH][RESEND] block: sed-opal: fix u64 short atom length

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(-) >

Re: [PATCH][RESEND] block: sed-opal: fix u64 short atom length

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