linux-kernel - Re: [PATCH V2 5/6] Thermal: Add ST-Ericsson DB8500 thermal dirver.

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, 25 Oct 2012 16:26:53 +0800
From:	Hongbo Zhang <hongbo.zhang@...aro.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, STEricsson_nomadik_linux@...t.st.com,
	kernel@...oocommunity.org, linaro-kernel@...ts.linaro.org,
	"hongbo.zhang" <hongbo.zhang@...aro.com>, patches@...aro.org
Subject: Re: [PATCH V2 5/6] Thermal: Add ST-Ericsson DB8500 thermal dirver.

[...]
>> +/* Callback to get temperature changing trend */
>> +static int db8500_sys_get_trend(struct thermal_zone_device *thermal,
>> +                       int trip, enum thermal_trend *trend)
>> +{
>> +       struct db8500_thermal_zone *pzone = thermal->devdata;
>> +
>> +       *trend = pzone->trend;
>> +
>> +       return 0;
>
> Can make it return void.
No, it is callback of thermal layer, prototype it to return int.

[...]
>> +static int __devinit db8500_thermal_probe(struct platform_device *pdev)
>> +{
>> +       struct db8500_thermal_zone *pzone = NULL;
>> +       struct db8500_thsens_platform_data *ptrips = NULL;
>> +       int low_irq, high_irq, ret = 0;
>> +       unsigned long dft_low, dft_high;
>> +
>> +       pzone = devm_kzalloc(&pdev->dev, sizeof(*pzone), GFP_KERNEL);
>> +       if (!pzone)
>> +               return -ENOMEM;
>> +
>> +       ptrips = db8500_thermal_parse_dt(pdev);
>
> This is what u have in this routine at the very first line:
>
>        if (!np) {
>                dev_err(&pdev->dev, "Missing device tree data\n");
>
> So, you will end up printing this line for every non-DT case. Not good.
> What u can do is, give preference to normal pdata here.
I moved this if(!np) into parse_dt function, no problem again.
(in fact have already done this, but it is missed in this sending)
>
>> +       if (!ptrips)
>> +               ptrips = dev_get_platdata(&pdev->dev);
>> +
>> +       if (!ptrips)
>
[...]
>> +       }
>> +
>> +       ret = devm_request_threaded_irq(&pdev->dev, low_irq, NULL,
>
> why threaded irq?
In fact PRCMU firmware is polling the thermal sensor, and if it meets
threshold, the PRCMU will write this event into share memory (shared
between PRCMU and ARM) and trigger an interrupt to ARM.
There may be other events passed via share memory, so it is better to
handle this kind of irq as fast as possible(it is always the policy),
and threaded irq satisfies this case better then the traditional one.
>
>> +               prcmu_low_irq_handler, IRQF_NO_SUSPEND | IRQF_ONESHOT,
>> +               "dbx500_temp_low", pzone);
>> +       if (ret < 0) {
>> +               dev_err(&pdev->dev, "Failed to allocate temp low irq.\n");
>> +               return ret;
>> +       }
>> +
>> +       high_irq = platform_get_irq_byname(pdev, "IRQ_HOTMON_HIGH");
>> +       if (high_irq < 0) {
>> +               dev_err(&pdev->dev, "Get IRQ_HOTMON_HIGH failed.\n");
>> +               return high_irq;
>
> don't want to free resources?
devm_* is used to allocate resources, so no need to free them manually.
>
>> +       }
>> +
>> +       ret = devm_request_threaded_irq(&pdev->dev, high_irq, NULL,
>> +               prcmu_high_irq_handler, IRQF_NO_SUSPEND | IRQF_ONESHOT,
>> +               "dbx500_temp_high", pzone);
>> +       if (ret < 0) {
>> +               dev_err(&pdev->dev, "Failed to allocate temp high irq.\n");
>> +               return ret;
>> +       }
>> +
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/