Linux PCI subsystem development
 help / color / mirror / Atom feed
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.


  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