RE: [PATCHv2 07/10] xshm: XSHM Configuration data handling

[Sjur BRENDELAND]

Hi Arnd,

>> +static unsigned long xshm_start;
>> +module_param(xshm_start, ulong, S_IRUGO | S_IWUSR);
>> +MODULE_PARM_DESC(xshm_start, "Address for memory shared by host/modem.");
>> +
>> +static unsigned long xshm_c2c_bootaddr;
>> +module_param(xshm_c2c_bootaddr, ulong, S_IRUGO | S_IWUSR);
>> +MODULE_PARM_DESC(xshm_c2c_bootaddr, "Address given to modem (through GENI register)");
>> +
>> +static long xshm_size;
>> +module_param(xshm_size, long, S_IRUGO | S_IWUSR);
>> +MODULE_PARM_DESC(xshm_size, "Size of SHM area");

In 9540 the C2C memory configuration is known by the secure SW executing
at early boot-time. The memory layout parameters are stored in "secure world"
(ARM TrustZone), and are passed from "secure world" to boot-loader and then to
the Linux kernel.

> That looks fragile, you should never have addresses as module arguments.
> Either the kernel should be free to pick a reasonable address and tell
> it to the modem, 

This address cannot be decided by the Host alone, as the modem firmware
depends on the memory layout.

> or the modem should pick an address and then the kernel
> needs a reliable way to find out what it is.

The modem has not started at this point in the boot process.

As I see it we are left with three alternatives for getting the Shared Memory
configuration data: Device Tree, via netlink, or as module parameters.

AFIAK 9540 is not yet supporting Device Tree so this is not an option at the moment. 
Storing this in DT would also lead to duplication of configuration data.

Another option could be to get this from user-space via netlink. As mentioned
earlier the modem is started by a "Modem Init Daemon" (MID). The MID is managing the
life-cycle and provides everything the flash and ram-less modem needs. So MID has a
set of interdependent configuration elements: boot-images for several boot stages,
file-system, Shared Memory channel configuration etc. All these data elements needs
to be consistent for a given modem image. As the MID is already managing a set
of data that has to be consistent, we could add the Shared Memory Configuration
as well. (In future the MID might even get this data from "secure world" to avoid
duplication of data)

The benefit of the current solution, passing memory configuration data as Linux-kernel
boot parameters, is that the configuration is coming from the "secure world" via
the kernel boot-loader. In this way we avoid duplicating the memory configuration
data. So I'm not sure the current solution is any worse than the alternatives.

Regards,
Sjur
N‹§²æìr¸›yúèšØb²X¬¶ÇvØ^–)Þ{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü}©ž²ÆzÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ßf”ù^jÇy§m…á@A«a¶Úÿ0¶ìh®å’i