From: Guixin Liu <kanie@linux.alibaba.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.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 19:18:19 +0800 [thread overview]
Message-ID: <e3f9f75f-d6d0-458a-81c9-ba9659b5f7c2@linux.alibaba.com> (raw)
In-Reply-To: <a0f0fead-ee26-943a-53b3-873e8652811f@linux.intel.com>
在 2025/12/11 17:33, Ilpo Järvinen 写道:
> 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.
OK, Changed in v8, thanks.
>> #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).
OK, I wil do this.
Best Regards,
Guixin Liu
next prev parent reply other threads:[~2025-12-11 11:18 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
2025-12-11 11:18 ` Guixin Liu [this message]
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=e3f9f75f-d6d0-458a-81c9-ba9659b5f7c2@linux.alibaba.com \
--to=kanie@linux.alibaba.com \
--cc=andriy.shevchenko@intel.com \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.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