linux-kernel - Re: [PATCH 09/12] coresight tmc: Add capability information

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]

Message-ID: <CANLsYkzKaB1zcb22D3TqWPDBd-ABzu_0TygSeod30k9CcTOKfg@mail.gmail.com>
Date:   Thu, 15 Jun 2017 08:37:09 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Suzuki K Poulose <Suzuki.Poulose@....com>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/12] coresight tmc: Add capability information

On 15 June 2017 at 04:30, Suzuki K Poulose <Suzuki.Poulose@....com> wrote:
> On 14/06/17 19:22, Mathieu Poirier wrote:
>>
>> On Mon, Jun 12, 2017 at 03:36:48PM +0100, Suzuki K Poulose wrote:
>>>
>>> This patch adds description of the capabilities of a given TMC.
>>> This will help us to handle different versions of the TMC in the
>>> same driver by checking the capabilities.
>>>
>>> Cc: Mathieu Poirier <mathieu.poirier@...aro.org>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>>> ---
>>>  drivers/hwtracing/coresight/coresight-tmc.c | 10 +++++++++-
>>>  drivers/hwtracing/coresight/coresight-tmc.h | 18 ++++++++++++++++++
>>>  2 files changed, 27 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c
>>> b/drivers/hwtracing/coresight/coresight-tmc.c
>>> index 7152656..e88f2f3 100644
>>> --- a/drivers/hwtracing/coresight/coresight-tmc.c
>>> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
>>> @@ -399,16 +399,24 @@ static int tmc_probe(struct amba_device *adev,
>>> const struct amba_id *id)
>>>         ret = misc_register(&drvdata->miscdev);
>>>         if (ret)
>>>                 coresight_unregister(drvdata->csdev);
>>> +       else if (id->data)
>>> +               drvdata->caps = *(struct tmc_caps *)id->data;
>>>  out:
>>>         return ret;
>>>  }
>>>
>>> +static struct tmc_caps coresight_soc_400_tmc_caps = {
>>> +       .caps = CORESIGHT_SOC_400_TMC_CAPS,
>>> +};
>>> +
>>>  static struct amba_id tmc_ids[] = {
>>>         {
>>> +               /* Coresight SoC 400 TMC */
>>>                 .id     = 0x000bb961,
>>>                 .mask   = 0x000fffff,
>>> +               .data   = &coresight_soc_400_tmc_caps,
>>
>>
>> Do we need this?  I don't see anywhere a check for TMC_CAP_ETR_SG_UNIT.
>> And
>> I also suppose that the SoC600 suite also supports scatter-gather - is
>> there a
>> need to differenciate both that may not be implemented in this set?
>
>
> Yes, the coresight SoC-600 doesn't come with an in built Scatter Gather
> unit.
> Instead there is a dedicated component (Coresight Address Translation UNIT,
> CATU)
> to do the Scatter Gather, which needs a driver. This is to make sure that if
> somebody wants to use the SG, they should check it in the caps.
>
>
>>
>> I'm also wondering if capabilities for SoC600 could not be retrieved from
>> HW
>> registers rather than hard coded?
>
>
> Unfortunately, no. There is no hardware description for the feature. So, we
> need
> to depend on the PIDs to detect the features.

I suspected that much - thanks for the clarification.

>
>>> +#define TMC_CAP_ETR_SG_UNIT                    (1U << 0)
>>> +
>>> +/**
>>> + * struct tmc_cap - Describes the capabilities of the TMC.
>>> + * @caps:      - Bitmask of the capacities
>>> + */
>>> +struct tmc_caps {
>>> +       u32     caps;
>>> +};
>>> +
>>> +#define CORESIGHT_SOC_400_TMC_CAPS     (TMC_CAP_ETR_SG_UNIT)
>>> +
>>>  /**
>>>   * struct tmc_drvdata - specifics associated to an TMC component
>>>   * @base:      memory mapped base address for this component.
>>> @@ -110,6 +122,7 @@ struct tmc_drvdata {
>>>         void __iomem            *base;
>>>         struct device           *dev;
>>>         struct coresight_device *csdev;
>>> +       struct tmc_caps         caps;
>>
>>
>> A simple u32 is probably best here rather than introducing a new
>> structure.  If
>> capabilites can't be retrieved from HW and have to be declared statically,
>> a
>> *u32 referencing ->data is sufficient rather than copying memory.
>
>
> I think eventually the compiler may be able to do a register move to copy a
> 32bit
> data. We could potentially add more fields there (e.g, whether a CATU is
> connected
> to the device or not etc). Hence the abstraction.

Ok

>
>
> Suzuki