RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver

[Ong, Boon Leong]

>-----Original Message-----
>From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-
>owner@xxxxxxxxxxxxxxx] On Behalf Of Ong, Boon Leong
>Sent: Monday, February 23, 2015 9:39 AM
>To: Kweh, Hock Leong; Zhang, Rui; edubezval@xxxxxxxxx
>Cc: linux-pm@xxxxxxxxxxxxxxx; LKML; Bryan O'Donoghue
>Subject: RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver
>

>>> +static struct soc_sensor_entry *alloc_soc_dts(void)
>>> +{
>>> +	struct soc_sensor_entry *aux_entry;
>>> +	int err;
>>> +	u32 out;
>>> +	int wr_mask;
>>> +
>>> +	aux_entry = kzalloc(sizeof(*aux_entry), GFP_KERNEL);
>>
>>Wondering is it possible to use the resource-managed functions (for e.g.
>>devm_kzalloc())? This could help the driver looks more neat and clean
>>where the resource-managed framework will help you take care all the
>>kfree().
>>
>>Understand that the flow here is to call the thermal_zone_device_register()
>>function after this aux_entry allocation.
>>
>>But thinking would it also working if change the flow to call
>>thermal_zone_device_register() function 1st to obtain the
>>thermal_zone_device
>>then later on perform devm_kzalloc() and assign it back to devdata.
>>
>Ok, it is worth exploring on this devm_kzalloc() for neatness.

I give it a thought again and I think that devm_kzalloc() is only useful
if the thermal driver is platform driver. So, for Quark thermal driver, 
this will not be useful. So, the existing kzalloc() method is sufficient.


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