lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hr3gse7wk.wl-tiwai@suse.de>
Date:	Thu, 04 Feb 2016 17:51:07 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	"Sudip Mukherjee" <sudipm.mukherjee@...il.com>
Cc:	"Jaroslav Kysela" <perex@...ex.cz>, <alsa-devel@...a-project.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] portman2x4 - use new parport device model

On Thu, 04 Feb 2016 17:38:23 +0100,
Sudip Mukherjee wrote:
> 
> Modify portman driver to use the new parallel port device model.
> The advantage of using the device model is that the device gets binded
> to the hardware, we get the feature of hotplug, we can bind/unbind
> the driver at runtime.
> The only change is in the way the driver gets registered with the
> parallel port subsystem and so as a result there is no user visible
> change or any chance of regression.
> 
> Signed-off-by: Sudip Mukherjee <sudip@...torindia.org>
> ---
> 
> v3: changed commit message
> v2:
>  1. pardev_cb is initialized while declaring, thus removing the use of
> memset.
>  2. used pdev->id.
>  3. v1 did not have the parport probe callback, but
> we will need the probe callback for binding as the name of the driver
> and the name of the device is different.
>  4. in v1 I missed modifying snd_portman_probe_port().
> 
>  sound/drivers/portman2x4.c | 53 ++++++++++++++++++++++++++++++++++------------
>  1 file changed, 39 insertions(+), 14 deletions(-)
> 
> diff --git a/sound/drivers/portman2x4.c b/sound/drivers/portman2x4.c
> index 172685d..a22f56c 100644
> --- a/sound/drivers/portman2x4.c
> +++ b/sound/drivers/portman2x4.c
> @@ -650,10 +650,21 @@ static int snd_portman_probe_port(struct parport *p)
>  {
>  	struct pardevice *pardev;
>  	int res;
> -
> -	pardev = parport_register_device(p, DRIVER_NAME,
> -					 NULL, NULL, NULL,
> -					 0, NULL);
> +	struct pardev_cb pdev_cb = {
> +		.preempt = NULL,
> +		.wakeup = NULL,
> +		.private = NULL,
> +		.irq_func = NULL,
> +		.flags = 0,
> +	};
> +
> +	/*
> +	 * Specify the device number as SNDRV_CARDS + 1 so that the
> +	 * device id alloted to this temporary device will never clash
> +	 * with an actual device already registered.
> +	 */
> +	pardev = parport_register_dev_model(p, DRIVER_NAME, &pdev_cb,
> +					    SNDRV_CARDS + 1);

Hmm, doesn't this result in a device name like "xxx.33" ?
Also, what if multiple portman devices are registered?

I suppose rather it should be passing dev variable from
snd_portman_probe()?


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ