linux-kernel - Re: [alsa-devel] [PATCH v6 02/11] mfd: wcd934x: add support to wcd9340/wcd9341 codec

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]

Date:   Thu, 19 Dec 2019 10:36:48 -0600
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        broonie@...nel.org, lee.jones@...aro.org, linus.walleij@...aro.org
Cc:     robh@...nel.org, alsa-devel@...a-project.org,
        bgoswami@...eaurora.org, vinod.koul@...aro.org,
        devicetree@...r.kernel.org, spapothi@...eaurora.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v6 02/11] mfd: wcd934x: add support to
 wcd9340/wcd9341 codec

> +static int wcd934x_slim_status(struct slim_device *sdev,
> +			       enum slim_device_status status)
> +{
> +	switch (status) {
> +	case SLIM_DEVICE_STATUS_UP:
> +		return wcd934x_slim_status_up(sdev);
> +	case SLIM_DEVICE_STATUS_DOWN:
> +		mfd_remove_devices(&sdev->dev);
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +

this is interesting/surprising - I just noticed what looks like a 
significant change in how probe/initialization are handled.

It was my understanding that in SLIMbus the Linux devices are created at 
probe time, and when the device reports present this 'device_status' 
callback is used to notify the codec driver of a change. The rationale 
for this was that the codec driver may control power switches/gpios that 
are necessary for the device to appear on the bus.

This argument was used to require an change in the SoundWire 
implementation, so we followed this model of creating devices at probe 
time based on information reported by ACPI/DT, and used the 
'update_status' callback when the device is present on the bus (which 
may happen after a delay or controlled by an external power switch). 
This approach can lead to 'ghost devices' described in firmware but not 
populated in hardware, and power management opens on how long a bus 
needs to remain active if no devices report present.

What I understand from the code above is that the devices are actually 
created when the SLIMbus device reports PRESENT, which seems a 180 
degree change in directions?

I actually prefer it this way, and all current discussions in MIPI 
circles point to the fact that when the bus starts all devices on that 
bus should already be powered and have the ability to report present 
immediately (if the bus starts in a 'safe' mode and then later programs 
different PHY parameters, a device can no longer join the bus)

I would however not remove the devices when the status is down but only 
on an explicit .remove.

Feedback welcome.
-Pierre