From: Xinhui Yang <cyan@cyano.uk>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-scsi@vger.kernel.org
Cc: stable@vger.kernel.org, Mingcong Bai <jeffbai@aosc.io>,
Kexy Biscuit <kexybiscuit@aosc.io>,
Oliver Neukum <oliver@neukum.org>, Ali Akcaagac <aliakc@web.de>,
Jamie Lenehan <lenehan@twibble.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] scsi: dc395x: improve code formatting for the macros
Date: Tue, 23 Sep 2025 21:31:14 +0800 [thread overview]
Message-ID: <c6a39939-b0cd-43a3-8b63-114909ba001e@cyano.uk> (raw)
In-Reply-To: <1ae97d061da14b0d85c0938c3000ed57ccd39382.camel@HansenPartnership.com>
Hi James,
在 2025/9/23 21:09, James Bottomley 写道:
> On Tue, 2025-09-23 at 20:52 +0800, Xinhui Yang wrote:
>> These DC395x_* macros does not have white spaces around their
>> arguments,
>> thus checkpatch.pl throws an error for each change in the macros.
>>
>> Also, there are no surrounding parentheses in the expressions for the
>> read and write macros, which checkpatch.pl also complained about.
>>
>> This patch does only formatting improvements to make the macro
>> definitions align with the previous patch.
>>
>> Signed-off-by: Xinhui Yang <cyan@cyano.uk>
>> ---
>> drivers/scsi/dc395x.c | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
>> index aed4f21e8143..cff6fa20e53c 100644
>> --- a/drivers/scsi/dc395x.c
>> +++ b/drivers/scsi/dc395x.c
>> @@ -91,8 +91,8 @@
>> #endif
>>
>>
>> -#define
>> DC395x_LOCK_IO(dev,flags) spin_lock_irqsave(((struct Scsi_Host *)dev)->host_lock,flags)
>> -#define
>> DC395x_UNLOCK_IO(dev,flags) spin_unlock_irqrestore(((struct Scsi_Host*)dev)->host_lock,flags)
>> +#define DC395x_LOCK_IO(dev,
>> flags) spin_lock_irqsave(((struct Scsi_Host *)dev)->host_lock, flags)
>> +#define DC395x_UNLOCK_IO(dev,
>> flags) spin_unlock_irqrestore(((struct Scsi_Host *)dev)->host_lock, flags)
>>
>> /*
>> * read operations that may trigger side effects in the hardware,
>> @@ -100,12 +100,12 @@
>> */
>> #define DC395x_peek8(acb, address) ((void)(inb(acb-
>>> io_port_base + (address))))
>> /* normal read write operations goes here. */
>> -#define DC395x_read8(acb,address) (u8)(inb(acb-
>>> io_port_base + (address)))
>> -#define DC395x_read16(acb,address) (u16)(inw(acb-
>>> io_port_base + (address)))
>> -#define DC395x_read32(acb,address) (u32)(inl(acb-
>>> io_port_base + (address)))
>> -#define DC395x_write8(acb,address,value) outb((value), acb-
>>> io_port_base + (address))
>> -#define DC395x_write16(acb,address,value) outw((value), acb-
>>> io_port_base + (address))
>> -#define DC395x_write32(acb,address,value) outl((value), acb-
>>> io_port_base + (address))
>> +#define DC395x_read8(acb, address) ((u8) (inb(acb-
>>> io_port_base + (address))))
>> +#define DC395x_read16(acb, address) ((u16) (inw(acb-
>>> io_port_base + (address))))
>> +#define DC395x_read32(acb, address) ((u32) (inl(acb-
>>> io_port_base + (address))))
>
> This doesn't look right. The problem checkpatch is complaining about
> is surely that the cast makes it a compound statement. However, since
> inb inw and inl all return the types they're being cast to the correct
> solution is surely to remove the cast making these single statements
> that don't need parentheses.
Thanks, I checked the definitions and you are right - these read macros
should have their casts removed, as they now return u8, u16 and u32
respectively.
>> +#define DC395x_write8(acb, address, value) (outb((value), acb-
>>> io_port_base + (address)))
>> +#define DC395x_write16(acb, address, value) (outw((value), acb-
>>> io_port_base + (address)))
>> +#define DC395x_write32(acb, address, value) (outl((value), acb-
>>> io_port_base + (address)))
>
> And these are single statements which shouldn't need parentheses. Are
> you sure checkpatch is complaining about this, because if it is then
> checkpatch needs fixing.
Thanks for pointing this out, they don't need additional parentheses.
> Regards,
>
> James
>
Thanks,
Xinhui
prev parent reply other threads:[~2025-09-23 13:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 12:52 [PATCH v3 0/2] dc395x: fix compiler warnings and improve formatting of " Xinhui Yang
2025-09-23 12:52 ` [PATCH v3 1/2] scsi: dc395x: correctly discard the return value in certain reads Xinhui Yang
2025-09-23 12:52 ` [PATCH v3 2/2] scsi: dc395x: improve code formatting for the macros Xinhui Yang
2025-09-23 13:09 ` James Bottomley
2025-09-23 13:31 ` Xinhui Yang [this message]
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=c6a39939-b0cd-43a3-8b63-114909ba001e@cyano.uk \
--to=cyan@cyano.uk \
--cc=James.Bottomley@HansenPartnership.com \
--cc=aliakc@web.de \
--cc=jeffbai@aosc.io \
--cc=kexybiscuit@aosc.io \
--cc=lenehan@twibble.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=oliver@neukum.org \
--cc=stable@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
all inboxes | Powered by JetHome®