| Message ID | df3e58c6-f70d-a5d3-102e-4fab2f7df126@users.sourceforge.net (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
On Wed, May 17, 2017 at 05:47:29PM +0200, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Wed, 17 May 2017 17:30:28 +0200 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit Please fix however you're sending things out to avoid this noise. > The script “checkpatch.pl” pointed information out like the following. > > Comparison to NULL could be written !… > > Thus fix the affected source code places. This changelog does not describe any purpose in making this change, we could equally well say the exact opposite. Why should we do this?
>> MIME-Version: 1.0 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 8bit > > Please fix however you're sending things out to avoid this noise. The Git software generated such extra information because my commit message contained a few special characters. >> The script “checkpatch.pl” pointed information out like the following. >> >> Comparison to NULL could be written !… >> >> Thus fix the affected source code places. > > This changelog does not describe any purpose in making this change, > we could equally well say the exact opposite. Why should we do this? How do you think about to reduce the usage of the preprocessor symbol “NULL”? Can it help if the source code is a little bit shorter after the proposed adjustment? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 18, 2017 at 04:34:45PM +0200, SF Markus Elfring wrote: > >> The script “checkpatch.pl” pointed information out like the following. > >> Comparison to NULL could be written !… > >> Thus fix the affected source code places. > > This changelog does not describe any purpose in making this change, > > we could equally well say the exact opposite. Why should we do this? > How do you think about to reduce the usage of the preprocessor symbol “NULL”? Why would that matter? > Can it help if the source code is a little bit shorter after the > proposed adjustment? Not really - clarity is important but the size of code isn't too meaningful in and of itself. Please if you don't really understand what you're sending try to understand it first, don't throw things out without that. I know a number of other maintainers have already raised concerns about the quality of what's being sent and the effort required to review them in relation to their value. There's nothing wrong with doing small cleanups but if that's all you're sending and there's often problems then it becomes more trouble than it's worth to review your changes.
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c index e6dc37fbea4e..846c54129744 100644 --- a/drivers/spi/spidev.c +++ b/drivers/spi/spidev.c @@ -106,8 +106,7 @@ spidev_sync(struct spidev_data *spidev, struct spi_message *message) spin_lock_irq(&spidev->spi_lock); spi = spidev->spi; spin_unlock_irq(&spidev->spi_lock); - - if (spi == NULL) + if (!spi) status = -ESHUTDOWN; else status = spi_sync(spi, message); @@ -218,7 +217,7 @@ static int spidev_message(struct spidev_data *spidev, spi_message_init(&msg); k_xfers = kcalloc(n_xfers, sizeof(*k_tmp), GFP_KERNEL); - if (k_xfers == NULL) + if (!k_xfers) return -ENOMEM; /* Construct spi_message, copying any tx data to bounce buffer. @@ -387,8 +386,7 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) spin_lock_irq(&spidev->spi_lock); spi = spi_dev_get(spidev->spi); spin_unlock_irq(&spidev->spi_lock); - - if (spi == NULL) + if (!spi) return -ESHUTDOWN; /* use the buffer lock here for triple duty: @@ -535,8 +533,7 @@ spidev_compat_ioc_message(struct file *filp, unsigned int cmd, spin_lock_irq(&spidev->spi_lock); spi = spi_dev_get(spidev->spi); spin_unlock_irq(&spidev->spi_lock); - - if (spi == NULL) + if (!spi) return -ESHUTDOWN; /* SPI_IOC_MESSAGE needs the buffer locked "normally" */ @@ -655,7 +652,7 @@ static int spidev_release(struct inode *inode, struct file *filp) spidev->speed_hz = spidev->spi->max_speed_hz; /* ... after we unbound from the underlying device? */ - dofree = (spidev->spi == NULL); + dofree = !spidev->spi; spin_unlock_irq(&spidev->spi_lock); if (dofree)