Chunyan Zhang writes:
> Hi Alex,
Hi Chunyan,
> Could you take this patch please if there's no further comments?
Sorry for the delay. Yes, I'm picking this patch into my tree very
soon.
Thanks,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a mes
On 21 March 2017 at 07:57, Chunyan Zhang wrote:
> On 20 March 2017 at 19:09, Alexander Shishkin
> wrote:
>> Chunyan Zhang writes:
>>
>>> Hi Alex,
>>>
>>> On 20 March 2017 at 16:49, Alexander Shishkin
>>> wrote:
>>>> Hi Chuny
Chunyan Zhang writes:
> Hi Alex,
>
> On 20 March 2017 at 16:49, Alexander Shishkin
> wrote:
>> Hi Chunyan,
>>
>> A couple of clarifications: iirc this applies to the function tracer
>> of ftrace, right? Does it make sense to mention that? Also, are you
>
Hi Chunyan,
A couple of clarifications: iirc this applies to the function tracer
of ftrace, right? Does it make sense to mention that? Also, are you
planning to support other ftrace payloads like trace_printk()s?
Thanks,
--
Alex
On 20 March 2017 at 08:47, Chunyan Zhang wrote:
> This patch adds
Ben Hutchings writes:
> When kernel.perf_event_open is set to 3 (or greater), disallow all
> access to performance events by users without CAP_SYS_ADMIN.
> Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> makes this value the default.
So this patch does two things, can it then be
Mathieu Poirier writes:
> On 6 April 2016 at 20:51, Chunyan Zhang wrote:
>> This patchset adds support for the CoreSight STM IP block.
>
> This has been out there long enough - I'm picking this up.
>
> Alex, I'll have 1/4 go through my tree. Get back to me if you want to
> proceed differently.
Mathieu Poirier writes:
> On 21 March 2016 at 01:47, Alexander Shishkin
> wrote:
>> Chunyan Zhang writes:
>>
>>> From: Mathieu Poirier
>>>
>>> Some architecture like ARM assign masterIDs at the HW design
>>> phase. Those are therefore u
Chunyan Zhang writes:
> From: Mathieu Poirier
>
> Some architecture like ARM assign masterIDs at the HW design
> phase. Those are therefore unreachable to users, making masterID
> management in the generic STM core irrelevant.
>
> In this kind of configuration channels are shared between master
Mathieu Poirier writes:
> On 8 February 2016 at 06:26, Alexander Shishkin
> wrote:
>> This $end==$start situation itself may be ambiguous and can be
>> interpreted either as having just one *static* master ID fixed for all
>> SW writers (what I assumed from your commit
Al Grant writes:
>> Mike did write "master IDs are hardwired to individual cores and core
>> security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective. From the perspective of a u
Chunyan Zhang writes:
> +static long stm_generic_set_options(struct stm_data *stm_data,
> + unsigned int master,
> + unsigned int channel,
> + unsigned int nr_chans,
> +
Chunyan Zhang writes:
> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.
I'm not sure I unde
Mathieu Poirier writes:
> On 5 February 2016 at 05:52, Alexander Shishkin
> wrote:
>> Chunyan Zhang writes:
>>
>>> From: Mathieu Poirier
>>>
>>> Some architecture like ARM assign masterIDs statically at the HW design
>>> phase, making ma
Mike Leach writes:
> Hi,
>
> I think a quick clarification of the ARM hardware STM architecture may be of
> value here.
>
> The ARM hardware STM, when implemented as recommend in a hardware design, the
> master IDs are not under driver control, but have a hardwire association with
> source dev
Chunyan Zhang writes:
> +#ifndef CONFIG_64BIT
> +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> +{
> + asm volatile("strd %1, %0"
> + : "+Qo" (*(volatile u64 __force *)addr)
> + : "r" (val));
> +}
Is it really ok to do this for all !
Chunyan Zhang writes:
> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.
>
> Signed-off-by: C
Chunyan Zhang writes:
> From: Mathieu Poirier
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific
RR_PTR(-ENODEV);
> + kfree(devname);
In the existing code there is a clear distinction between -ENODEV, which
is to say "we didn't find the device" and -EINVAL, "directory name
breaks rules/is badly formatted". After the change, it's all -EINVAL,
which also become
Mathieu Poirier writes:
>> I'd like to understand all the potential failures here, because it's
>> really a good idea to keep those to a minimum for the sake of
>> consistency. That is, if the user succeeded in creating an event, about
>> the only good reason for the event not starting is a fille
Mathieu Poirier writes:
> Adding an ETB10 specific AUX area operations to be used
> by the perf framework when events are initialised.
>
> Part of this operation involves modeling the mmap'ed area
> based on the specific ways a sink buffer gathers information.
I don't mind being CC'd on the rest
Mathieu Poirier writes:
> +static int etm_event_init(struct perf_event *event)
> +{
> + if (event->attr.type != etm_pmu.type)
> + return -ENOENT;
> +
> + if (event->cpu >= nr_cpu_ids)
> + return -EINVAL;
perf_event_alloc() already does this. Except for this one do
21 matches
Mail list logo
