Question about mv_print_info in sata_mv.c in sata_mv.c

Question about mv_print_info in sata_mv.c in sata_mv.c

[nick]

Greetings Tejuin,Grant and Rob,
Hope you are having a good holidays. I am wondering if there is 
anything we need to add to this function as stated in a fix me above it.I am pretty certain
there isn't but as the maintainers, I am double checking first with you:). Please let me 
known if you think of something.
Regards and Have a Great Holidays :),
Nick 

Re: Question about mv_print_info in sata_mv.c in sata_mv.c

[Rob Herring]

On Mon, Dec 22, 2014 at 10:04 PM, nick <xerofoify@gmail.com> wrote:
> Greetings Tejuin,Grant and Rob,
> Hope you are having a good holidays. I am wondering if there is
> anything we need to add to this function as stated in a fix me above it.I am pretty certain
> there isn't but as the maintainers, I am double checking first with you:). Please let me
> known if you think of something.

Grant and I are not actually maintainers of this driver.
get_maintainer.pl is somewhat wrong here because it matches on regex
that is present in about every driver that is DT enabled. I've sent a
patch now to change that.

It would help also if you paste in the actually code you are referring to.

Rob

> Regards and Have a Great Holidays :),
> Nick

Re: Question about mv_print_info in sata_mv.c in sata_mv.c

[nick]

Sorry Rob,
This is the code I am referring to:
 *      mv_print_info - Dump key info to kernel log for perusal.
 *      @host: ATA host to print info about
 *
 *      FIXME: complete this.
 *
 *      LOCKING:
 *      Inherited from caller.
 */
static void mv_print_info(struct ata_host *host)
{
	struct pci_dev *pdev = to_pci_dev(host->dev);
 	struct mv_host_priv *hpriv = host->private_data;
 	u8 scc;
 	const char *scc_s, *gen;

	/* Use this to determine the HW stepping of the chip so we know
	 * what errata to workaround
 	 */
	pci_read_config_byte(pdev, PCI_CLASS_DEVICE, &scc);
	if (scc == 0)
		scc_s = "SCSI";
	else if (scc == 0x01)
		scc_s = "RAID";
	else
		scc_s = "?";

	if (IS_GEN_I(hpriv))
		gen = "I";
	else if (IS_GEN_II(hpriv))
 		gen = "II";
	else if (IS_GEN_IIE(hpriv))
 		gen = "IIE";
	else
		gen = "?";
 
	dev_info(&pdev->dev, "Gen-%s %u slots %u ports %s mode IRQ via %s\n",
		 gen, (unsigned)MV_MAX_Q_DEPTH, host->n_ports,
		 scc_s, (MV_HP_FLAG_MSI & hpriv->hp_flags) ? "MSI" : "INTx");
}
I am assuming after reading this function's code, that this function is completed and no longer
needs a fix me comment above it to be completed.
Nick

On 2014-12-26 03:55 PM, Rob Herring wrote:
> On Mon, Dec 22, 2014 at 10:04 PM, nick <xerofoify@gmail.com> wrote:
>> Greetings Tejuin,Grant and Rob,
>> Hope you are having a good holidays. I am wondering if there is
>> anything we need to add to this function as stated in a fix me above it.I am pretty certain
>> there isn't but as the maintainers, I am double checking first with you:). Please let me
>> known if you think of something.
> 
> Grant and I are not actually maintainers of this driver.
> get_maintainer.pl is somewhat wrong here because it matches on regex
> that is present in about every driver that is DT enabled. I've sent a
> patch now to change that.
> 
> It would help also if you paste in the actually code you are referring to.
> 
> Rob
> 
>> Regards and Have a Great Holidays :),
>> Nick

Re: Question about mv_print_info in sata_mv.c in sata_mv.c

[tj@kernel.org >> Tejun Heo]

Hello, Nick.

On Fri, Dec 26, 2014 at 04:06:11PM -0500, nick wrote:
> I am assuming after reading this function's code, that this function is completed and no longer
> needs a fix me comment above it to be completed.

I do appreciate that you're studying the FIXME comments but at this
point I'm not sure whether blindly chasing them and asking people
whether they're still necessary is a productive thing to do.  If
they're actively misleading, sure, let's remove them, but FIXME in a
sata_mv function which prints some controller identification
information just doesn't matter.  If you can assert that the comment
is no longer necessary and misleading, please submit a patch with
backing rationale; otherwise, obsessing with each instance of FIXME
comment doesn't seem to be a particularly productive way of
participating in kernel development.

Thanks.

-- 
tejun