From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Guixin Liu <kanie@linux.alibaba.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Andy Shevchenko <andriy.shevchenko@intel.com>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 1/2] PCI: Introduce named defines for pci rom
Date: Thu, 11 Dec 2025 11:33:07 +0200 (EET) [thread overview]
Message-ID: <a0f0fead-ee26-943a-53b3-873e8652811f@linux.intel.com> (raw)
In-Reply-To: <20251211033741.53072-2-kanie@linux.alibaba.com>
On Thu, 11 Dec 2025, Guixin Liu wrote:
> This is a preparation patch for the next fix patch.
> Convert some magic numbers to named defines.
>
> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
> ---
> drivers/pci/rom.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
> index e18d3a4383ba..3e00611fa76b 100644
> --- a/drivers/pci/rom.c
> +++ b/drivers/pci/rom.c
> @@ -9,9 +9,20 @@
> #include <linux/export.h>
> #include <linux/pci.h>
> #include <linux/slab.h>
> +#include <linux/bits.h>
Includes should always be ordered alphabetically when they already are so.
Even in to other cases it's better try to place them close to the
right place wrt. other headers when it comes to alphabetical order, even
if some pre-existing headers would violate it still.
> #include "pci.h"
>
> +#define PCI_ROM_HEADER_SIZE 0x1A
> +#define PCI_ROM_POINTER_TO_DATA_STRUCT 0x18
> +#define PCI_ROM_LAST_IMAGE_INDICATOR 0x15
> +#define PCI_ROM_LAST_IMAGE_INDICATOR_BIT BIT(7)
> +#define PCI_ROM_IMAGE_LEN 0x10
> +#define PCI_ROM_IMAGE_LEN_UNIT_SZ_512 512
> +#define PCI_ROM_IMAGE_SIGNATURE 0xAA55
> +#define PCI_ROM_DATA_STRUCT_SIGNATURE 0x52494350
> +#define PCI_ROM_DATA_STRUCT_LEN 0x0A
> +
> /**
> * pci_enable_rom - enable ROM decoding for a PCI device
> * @pdev: PCI device to enable
You should convert the literals in the code too in this patch already.
I know it's a bit work to rebase the second patch on top of this, but you
actually don't need to do it that way (you can just make changes to this
patch and then use git diff to produce the very same end result so you
don't need to resolve any rebase conflicts).
--
i.
next prev parent reply other threads:[~2025-12-11 9:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 3:37 [PATCH v7 0/2] PCI: Fix crash when access broken rom Guixin Liu
2025-12-11 3:37 ` [PATCH v7 1/2] PCI: Introduce named defines for pci rom Guixin Liu
2025-12-11 9:33 ` Ilpo Järvinen [this message]
2025-12-11 11:18 ` Guixin Liu
2025-12-11 13:53 ` Andy Shevchenko
2025-12-11 3:37 ` [PATCH v7 2/2] PCI: Check rom header and data structure addr before accessing Guixin Liu
2025-12-11 9:59 ` Ilpo Järvinen
2025-12-11 11:19 ` Guixin Liu
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=a0f0fead-ee26-943a-53b3-873e8652811f@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=andriy.shevchenko@intel.com \
--cc=bhelgaas@google.com \
--cc=kanie@linux.alibaba.com \
--cc=linux-pci@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox