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
| ||
|
Date: Tue, 11 Oct 2022 16:10:27 +0100 From: Suzuki K Poulose <suzuki.poulose@....com> To: Mike Leach <mike.leach@...aro.org> Cc: coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, mathieu.poirier@...aro.org, peterz@...radead.org, mingo@...hat.com, acme@...nel.org, linux-perf-users@...r.kernel.org, leo.yan@...aro.org, quic_jinlmao@...cinc.com Subject: Re: [PATCH v3 03/13] coresight: stm: Update STM driver to use Trace ID API On 11/10/2022 12:10, Mike Leach wrote: > Hi suzuki, > > On Fri, 7 Oct 2022 at 18:53, Suzuki K Poulose <suzuki.poulose@....com> wrote: >> >> On 06/10/2022 14:54, Mike Leach wrote: >>> Hi Suzuki, >>> >>> On Mon, 3 Oct 2022 at 10:04, Suzuki K Poulose <suzuki.poulose@....com> wrote: >>>> >>>> On 09/08/2022 23:33, Mike Leach wrote: >>>>> Updates the STM driver to use the trace ID allocation API. >>>>> This uses the _system_id calls to allocate an ID on device poll, >>>>> and release on device remove. >>>>> >>>>> The sysfs access to the STMTRACEIDR register has been changed from RW >>>>> to RO. Having this value as writable is not appropriate for the new >>>>> Trace ID scheme - and had potential to cause errors in the previous >>>>> scheme if values clashed with other sources. >>>>> >>>>> Signed-off-by: Mike Leach <mike.leach@...aro.org> >>>>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@....com> >> >>>>> @@ -854,7 +830,7 @@ static void stm_init_generic_data(struct stm_drvdata *drvdata, >>>>> >>>>> static int stm_probe(struct amba_device *adev, const struct amba_id *id) >>>>> { >>>>> - int ret; >>>>> + int ret, trace_id; >>>>> void __iomem *base; >>>>> struct device *dev = &adev->dev; >>>>> struct coresight_platform_data *pdata = NULL; >>>>> @@ -938,12 +914,22 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id) >>>>> goto stm_unregister; >>>>> } >>>>> >>>>> + trace_id = coresight_trace_id_get_system_id(); >>>>> + if (trace_id < 0) { >>>> >>>> The above API returns "INVALID_ID" and not a negative error status. >>>> I think it is better to fix the API to return: >>>> >>>> ret < 0 - If there is any error >>>> - Otherwise a positive integer >>>> And the users should be kept unaware of which ID is valid or invalid. >>>> >>> >>> coresight_trace_id_get_system_id() returns the ID if one can be >>> allocated or -EINVAL if not. >>> >>> Not sure what you are looking at here. >> >> Sorry, indeed I was mistaken there. It is the get_cpu_id() which >> returns the INVALID_ID on failure. Please could we make that >> consistent with this scheme ? i.e, < 0 on error. >> > > That also returns -EINVAL, as both call the same underlying allocator. You're right, the check in coresight_trace_id_map_get_cpu_id(), confused me. > However happy to add on the comments for the exported functions Yes, please. Thanks Mike Suzuki
Powered by blists - more mailing lists