Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1382451 > unrolled thread
| Started by | Suzuki K Poulose <Suzuki.Poulose@arm.com> |
|---|---|
| First post | 2016-04-19 14:40 +0200 |
| Last post | 2016-04-19 17:40 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH V2 06/15] coresight: tmc: making prepare/unprepare functions generic Suzuki K Poulose <Suzuki.Poulose@arm.com> - 2016-04-19 14:40 +0200
Re: [PATCH V2 06/15] coresight: tmc: making prepare/unprepare functions generic Mathieu Poirier <mathieu.poirier@linaro.org> - 2016-04-19 17:30 +0200
Re: [PATCH V2 06/15] coresight: tmc: making prepare/unprepare functions generic Suzuki K Poulose <Suzuki.Poulose@arm.com> - 2016-04-19 17:40 +0200
| From | Suzuki K Poulose <Suzuki.Poulose@arm.com> |
|---|---|
| Date | 2016-04-19 14:40 +0200 |
| Subject | Re: [PATCH V2 06/15] coresight: tmc: making prepare/unprepare functions generic |
| Message-ID | <rpD6G-6Tc-21@gated-at.bofh.it> |
On 12/04/16 18:54, Mathieu Poirier wrote:
> Dealing with HW related matters in tmc_read_prepare/unprepare
> becomes convoluted when many cases need to be handled distinctively.
>
> As such moving processing related to HW setup to individual driver
> files and keep the core driver generic.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 62 ++++++++++++++++++++++++-
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 42 ++++++++++++++++-
> drivers/hwtracing/coresight/coresight-tmc.c | 55 +++++-----------------
> drivers/hwtracing/coresight/coresight-tmc.h | 8 ++--
> 4 files changed, 117 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 910d6f3b7d26..495540e9064d 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -70,7 +70,7 @@ static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
> drvdata->buf = drvdata->vaddr;
> }
>
> -void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> +static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> {
> CS_UNLOCK(drvdata->base);
>
> @@ -126,3 +126,43 @@ static const struct coresight_ops_sink tmc_etr_sink_ops = {
> const struct coresight_ops tmc_etr_cs_ops = {
> .sink_ops = &tmc_etr_sink_ops,
> };
> +
> +int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> +{
> + unsigned long flags;
> +
> + /* config types are set a boot time and never change */
> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> + return -EINVAL;
...
> +
> +int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
> +{
> + unsigned long flags;
> +
> + /* config types are set a boot time and never change */
> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> + return -EINVAL;
> +
For both cases above should we WARN_ON_ONCE() if we encounter such a case ?
Irrespective of that,
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[toc] | [next] | [standalone]
| From | Mathieu Poirier <mathieu.poirier@linaro.org> |
|---|---|
| Date | 2016-04-19 17:30 +0200 |
| Message-ID | <rpFLb-wa-1@gated-at.bofh.it> |
| In reply to | #1382451 |
On 19 April 2016 at 06:30, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> On 12/04/16 18:54, Mathieu Poirier wrote:
>>
>> Dealing with HW related matters in tmc_read_prepare/unprepare
>> becomes convoluted when many cases need to be handled distinctively.
>>
>> As such moving processing related to HW setup to individual driver
>> files and keep the core driver generic.
>>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> ---
>> drivers/hwtracing/coresight/coresight-tmc-etf.c | 62
>> ++++++++++++++++++++++++-
>> drivers/hwtracing/coresight/coresight-tmc-etr.c | 42 ++++++++++++++++-
>> drivers/hwtracing/coresight/coresight-tmc.c | 55
>> +++++-----------------
>> drivers/hwtracing/coresight/coresight-tmc.h | 8 ++--
>> 4 files changed, 117 insertions(+), 50 deletions(-)
>>
>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> index 910d6f3b7d26..495540e9064d 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> @@ -70,7 +70,7 @@ static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
>> drvdata->buf = drvdata->vaddr;
>> }
>>
>> -void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>> +static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> CS_UNLOCK(drvdata->base);
>>
>> @@ -126,3 +126,43 @@ static const struct coresight_ops_sink
>> tmc_etr_sink_ops = {
>> const struct coresight_ops tmc_etr_cs_ops = {
>> .sink_ops = &tmc_etr_sink_ops,
>> };
>> +
>> +int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
>> +{
>> + unsigned long flags;
>> +
>> + /* config types are set a boot time and never change */
>> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
>> + return -EINVAL;
>
>
> ...
>
>> +
>> +int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
>> +{
>> + unsigned long flags;
>> +
>> + /* config types are set a boot time and never change */
>> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
>> + return -EINVAL;
>> +
>
>
> For both cases above should we WARN_ON_ONCE() if we encounter such a case ?
WARN_ON_ONCE() would also be valid, albeit very blunt. Those
functions are user space triggered and returning -EINVAL will stop
everything - the end result is the same. I suppose that on such
condition fighting back with a backtrace will force people to pay
attention or report the problem.
>
> Irrespective of that,
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
[toc] | [prev] | [next] | [standalone]
| From | Suzuki K Poulose <Suzuki.Poulose@arm.com> |
|---|---|
| Date | 2016-04-19 17:40 +0200 |
| Message-ID | <rpFUS-Dr-23@gated-at.bofh.it> |
| In reply to | #1382607 |
On 19/04/16 16:22, Mathieu Poirier wrote:
> On 19 April 2016 at 06:30, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>> On 12/04/16 18:54, Mathieu Poirier wrote:
>>>
>>> Dealing with HW related matters in tmc_read_prepare/unprepare
>>> becomes convoluted when many cases need to be handled distinctively.
>>>
>>> As such moving processing related to HW setup to individual driver
>>> files and keep the core driver generic.
>>>
>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> ---
>>> drivers/hwtracing/coresight/coresight-tmc-etf.c | 62
>>> ++++++++++++++++++++++++-
>>> drivers/hwtracing/coresight/coresight-tmc-etr.c | 42 ++++++++++++++++-
>>> drivers/hwtracing/coresight/coresight-tmc.c | 55
>>> +++++-----------------
>>> drivers/hwtracing/coresight/coresight-tmc.h | 8 ++--
>>> 4 files changed, 117 insertions(+), 50 deletions(-)
>>>
>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>>> b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>>> index 910d6f3b7d26..495540e9064d 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>>> @@ -70,7 +70,7 @@ static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
>>> drvdata->buf = drvdata->vaddr;
>>> }
>>>
>>> -void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>>> +static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>>> {
>>> CS_UNLOCK(drvdata->base);
>>>
>>> @@ -126,3 +126,43 @@ static const struct coresight_ops_sink
>>> tmc_etr_sink_ops = {
>>> const struct coresight_ops tmc_etr_cs_ops = {
>>> .sink_ops = &tmc_etr_sink_ops,
>>> };
>>> +
>>> +int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
>>> +{
>>> + unsigned long flags;
>>> +
>>> + /* config types are set a boot time and never change */
>>> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
>>> + return -EINVAL;
>>
>>
>> ...
>>
>>> +
>>> +int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
>>> +{
>>> + unsigned long flags;
>>> +
>>> + /* config types are set a boot time and never change */
>>> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
>>> + return -EINVAL;
>>> +
>>
>>
>> For both cases above should we WARN_ON_ONCE() if we encounter such a case ?
>
> WARN_ON_ONCE() would also be valid, albeit very blunt. Those
> functions are user space triggered and returning -EINVAL will stop
> everything - the end result is the same. I suppose that on such
> condition fighting back with a backtrace will force people to pay
> attention or report the problem.
We do necessary checks to route the caller here, so we shouldn't really
hit the condition with the tmc_read_prepare(). So WARN_ON_ONCE() might be a
good check to make sure we don't hit it from say, perf driver or something
really went bad under the hood (corrupted ?). I am not too particular about it.
Suzuki
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web