Em Wed, 8 Apr 2020 17:16:29 +0100 Mark Brown <broonie@xxxxxxxxxx> escreveu: > On Wed, Apr 08, 2020 at 06:11:54PM +0200, Mauro Carvalho Chehab wrote: > > Mark Brown <broonie@xxxxxxxxxx> escreveu: > > > > Are you sure this is a sensible fix? The following lines should be part > > > of the documentation for transfer_one, will that be the case after your > > > change? > > > Without that, Sphinx will warn and may produce something unexpected. > > Right, but if the warning is telling us something useful we want to > handle it rather than just shutting it up. True. Without adding the blank line, kernel-doc would output this as: ``transfer_one`` transfer a single spi_transfer. - return 0 if the transfer is finished, - return 1 if the transfer is still in progress. When the driver is finished with this transfer it must call spi_finalize_current_transfer() so the subsystem can issue the next transfer. Note: transfer_one and transfer_one_message are mutually exclusive; when both are set, the generic subsystem does not call your transfer_one callback. This would be parsed by Sphinx (newer versions) as if the second line: transfer a single spi_transfer. would be a sort of subtitle that should be highlighted with a vertical line before that. E. g. something equivalent to: ============ |transfer_one| ------------------------------- |transfer a single spi_transfer.| - return 0 if the transfer is finished, - return 1 if the transfer is still in progress. When the driver is finished with this transfer it must call spi_finalize_current_transfer() so the subsystem can issue the next transfer. Note: transfer_one and transfer_one_message are mutually exclusive; when both are set, the generic subsystem does not call your transfer_one callback. Which is not the desired result. Adding a blank line after it fixes the issue, making it produce the expected output. > > > If this patch is applied after 20/25, the output should produce the > > correct result: > > > https://www.infradead.org/~mchehab/kernel_docs/driver-api/spi.html#spi-master-methods > > OK. > > Acked-by: Mark Brown <broonie@xxxxxxxxxx> Thanks, Mauro