Re: [PATCH v4 2/5] ALSA: ctxfi: initialized snd_card

[Takashi Iwai]

At Tue, 23 Sep 2014 16:30:21 +0530,
Sudip Mukherjee wrote:
> 
> initialized the reference of snd_card which was added to the various
> structures through the previous patch of the series.
> these references of snd_card will be used in a later patch to convert
> the pr_* macros to dev_*
> 
> Signed-off-by: Sudip Mukherjee <sudip@xxxxxxxxxxxxxxx>
> ---
>  sound/pci/ctxfi/ctamixer.c | 2 ++
>  sound/pci/ctxfi/ctatc.c    | 1 +
>  sound/pci/ctxfi/ctdaio.c   | 1 +
>  sound/pci/ctxfi/ctsrc.c    | 2 ++
>  4 files changed, 6 insertions(+)
> 
> diff --git a/sound/pci/ctxfi/ctamixer.c b/sound/pci/ctxfi/ctamixer.c
> index fed6e6a..dc89fad 100644
> --- a/sound/pci/ctxfi/ctamixer.c
> +++ b/sound/pci/ctxfi/ctamixer.c
> @@ -314,6 +314,7 @@ int amixer_mgr_create(void *hw, struct amixer_mgr **ramixer_mgr)
>  
>  	amixer_mgr->get_amixer = get_amixer_rsc;
>  	amixer_mgr->put_amixer = put_amixer_rsc;
> +	amixer_mgr->card = ((struct hw *)hw)->card;

Overall the patches became obviously better now, but unfortunately
we still see such rather stupid cast occasionally.  I guess you
considered reducing these?

Then start thinking from the scratch: why the cast is needed at all?
It's because the driver uses the void pointer for hw objects.  Why?
The driver author tried to separate the code abstraction, and thought
to pass the arbitrary hw object.

Such abstraction would be good if really different objects are
handled.  OTOH, in ctxfi case, we know that we deal with only a single
hw type.  So, using void * for hw object is rather error-prone, and
the code safety can be even improved by strict typing.

That said, replacing void * with struct hw * or such would make things
not only easier but also safer.

BTW, the patch 5 is basically independent from the rest, and it's good
enough, so I applied it now.  At the next respin, please drop that
patch from your series.


thanks,

Takashi
--
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/