Re: [PATCH] tile: revert pr_info to printk in <asm/io.h>

[Chris Metcalf]

On 2/1/2013 5:33 PM, Joe Perches wrote:
> On Fri, 2013-02-01 at 12:34 -0500, Chris Metcalf wrote:
>> Using pr_info in a header exposes us to potential trouble from
>> subsystems that define pr_fmt.  This change fixes:
>>
>>   In file included from include/linux/scatterlist.h:10,
>>                    from include/scsi/scsi.h:12,
>>                    from drivers/infiniband/ulp/srp/ib_srp.c:46:
>>   arch/tile/include/asm/io.h: In function âioport_mapâ:
>>   arch/tile/include/asm/io.h:296: error: expected â)â before âPFXâ
> Interesting.
>
>> diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
> []
>> @@ -292,7 +292,7 @@ static inline long ioport_panic(void)
>>  
>>  static inline void __iomem *ioport_map(unsigned long port, unsigned int len)
>>  {
>> -	pr_info("ioport_map: mapping IO resources is unsupported on tile.\n");
>> +	printk("ioport_map: mapping IO resources is unsupported on tile.\n");
> It'd be nicer to add an appropriate KERN_<LEVEL> here.
>
> My preference would be to change ib_srp.c (and ib_srpt) like:
> ---
>  drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> index d5088ce..59bf409 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -30,7 +30,7 @@
>   * SOFTWARE.
>   */
>  
> -#define pr_fmt(fmt) PFX fmt
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
>  #include <linux/module.h>
>  #include <linux/init.h>
>

Makes sense to me, and it does fix the compile failure.  I've pulled my original change from my tree and instead, for the change above (assuming Joe is implicitly providing a Signed-off-by on this patch):

Acked-by: Chris Metcalf <cmetcalf@xxxxxxxxxx>

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/