Re: [PATCH v11 3/8] ata: libahci_platform: move port_map parameters into the AHCI structure

[Antoine Ténart]

On Tue, Jul 29, 2014 at 10:40:42AM -0400, Tejun Heo wrote:
> On Thu, Jul 24, 2014 at 11:17:25AM +0200, Antoine Ténart wrote:
> > @@ -321,6 +321,8 @@ struct ahci_host_priv {
> >  	u32			cap;		/* cap to use */
> >  	u32			cap2;		/* cap2 to use */
> >  	u32			port_map;	/* port map to use */
> > +	u32			force_port_map;	/* force port map */
> > +	u32			mask_port_map;	/* mask out particular bits */
> 
> Let's collect the inputs, including flags, at the top and mark them clearly.

Done.

> 
> >  int ahci_platform_init_host(struct platform_device *pdev,
> >  			    struct ahci_host_priv *hpriv,
> >  			    const struct ata_port_info *pi_template,
> > -			    unsigned long host_flags,
> > -			    unsigned int force_port_map,
> > -			    unsigned int mask_port_map)
> > +			    unsigned long host_flags)
> 
> This doesn't make much sense to me.  Near the head of the function, it
> does
> 
> 	hpriv->flags |= host_flags;
> 
> Wouldn't it make more sense to just let the caller set hpriv->flags?

I just removed the host_flags parameter and updated the drivers calling
it.


How do you want me to send the series? There is two conflicts when
applying to libata/for-3.17:
- patch 4/8: it takes into account a patch not in libata/for-3.17 but
  added before rc7. It should be better to first merge rc7, otherwise
  some modifications won't make sense.
- patch 6/8: "fsl,imx53-ahci" was removed from the documentation in
  libata/for-3.17 but not in rc7. Resolving the conflict is really
  simple.

I think it's better to apply the whole thing after merging rc7 into
libata/for-3.17, because it will only have a really simple conflict to
resolve.

Please tell me what do you prefer before I send the updated version.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/