From: NeilBrown <neilb@suse.de>
To: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Cc: linux-raid@vger.kernel.org, pawel.baldysiak@intel.com
Subject: Re: [PATCH 1/5] imsm: support for OROMs shared by multiple HBAs
Date: Tue, 25 Nov 2014 11:51:54 +1100 [thread overview]
Message-ID: <20141125115154.4cb8a415@notabene.brown> (raw)
In-Reply-To: <546E29CB.1010408@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]
On Thu, 20 Nov 2014 18:50:03 +0100 Artur Paszkiewicz
<artur.paszkiewicz@intel.com> wrote:
> On 11/20/2014 04:07 AM, NeilBrown wrote:
> > On Wed, 19 Nov 2014 13:53:26 +0100 Artur Paszkiewicz
> > <artur.paszkiewicz@intel.com> wrote:
> >
> >> HBAs can share OROMs (e.g. SATA/sSATA). They are matched by PCI device
> >> id. Removed populated_orom/efi and imsm_orom/efi arrays - they are
> >> replaced by oroms array and functions get_orom_by_device_id(),
> >> add_orom(), add_orom_device_id().
> >>
> >> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> >
> > Hi,
> > this patch seems to make a lot more changes that the above brief description
> > seems to suggest.
> > Is there any chance of breaking it up into two or three parts, or at least
> > describing everything that is being changed.
> >
> > I'm half tempted to just accept it as it is, as it is just "your" code that
> > that is being changed, but I'd like to understand it if I can.
> >
> > Thanks,
> > NeilBrown
> >
>
> Hi Neil,
>
> Splitting this up reasonably turned out to be more difficult than I
> thought, so I'll try to provide a more detailed description of the
> changes.
>
> The IMSM platform code was based on an assumption that the OROM or UEFI
> capability structure (represented by struct imsm_orom) always belongs to
> only one HBA. This assumption is no longer valid, because of newer
> platforms with dual AHCI HBAs. Each HBA can have a separate OROM, but
> some versions have a combined OROM for both HBAs.
>
> This patch implements this HBA-OROM relationship in struct orom_entry,
> which matches an OROM with a list of HBA PCI ids. All the detected
> orom_entries are stored and retrieved using a global array and the
> functions add_orom(), add_orom_device_id() and get_orom_by_device_id().
> This replaces the arrays: imsm_orom, populated_orom, imsm_efi,
> populated_efi.
>
> The scan() function is extended to find all HBAs for an OROM. The list
> of their device ids is retrieved from the PCI Expansion ROM Data
> Structure, hence the additional field devListOffset in struct
> pciExpDataStructFormat.
>
> In UEFI mode we can't read the PCI Expansion ROM Data Structure and the
> imsm_orom structures are stored in UEFI variables. They do not provide a
> similar device id list, so we also check the HBA PCI class to make sure
> that the HBA has RAID mode enabled.
>
> In super-intel.c there are changes which allow spanning of IMSM
> containers over HBAs of the same type, but only if the HBAs share the
> same OROM. This is done by comparing imsm_orom pointers, which (outside
> of platform-intel.c) always point to the global array containing all the
> detected oroms. Additional warnings are added to
> validate_container_imsm() to warn about potentially dangerous operations
> in all the possible cases, e.g. when an array is assembled using disks
> attached to HBAs with separate OROMs.
>
> I hope you find this description helpful and that it will make the
> changes easier to understand.
>
Much better - thanks!
I've applied all 5 patches - using v2 of patch 4, and this comment for patch
1.
Thanks,
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
next prev parent reply other threads:[~2014-11-25 0:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 12:53 [PATCH 0/5] imsm: support for NVMe devices and AHCI spanning Artur Paszkiewicz
2014-11-19 12:53 ` [PATCH 1/5] imsm: support for OROMs shared by multiple HBAs Artur Paszkiewicz
2014-11-20 3:07 ` NeilBrown
2014-11-20 17:50 ` Artur Paszkiewicz
2014-11-25 0:51 ` NeilBrown [this message]
2014-11-19 12:53 ` [PATCH 2/5] imsm: support for second and combined AHCI controllers in UEFI mode Artur Paszkiewicz
2014-11-19 12:53 ` [PATCH 3/5] imsm: add support for NVMe devices Artur Paszkiewicz
2014-11-19 12:53 ` [PATCH 4/5] imsm: detail-platform improvements Artur Paszkiewicz
2014-11-19 12:53 ` [PATCH 5/5] imsm: use efivarfs interface for reading UEFI variables Artur Paszkiewicz
2014-11-20 3:11 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141125115154.4cb8a415@notabene.brown \
--to=neilb@suse.de \
--cc=artur.paszkiewicz@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=pawel.baldysiak@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.