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] [day] [month] [year] [list]
Message-ID: <20150529135604.541eee30@gavidov-lnx.qualcomm.com>
Date:	Fri, 29 May 2015 13:56:04 -0600
From:	Gilad Avidov <gavidov@...eaurora.org>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Ankit Gupta <ankgupta@...eaurora.org>, sdharia@...eaurora.org,
	ivan.ivanov@...aro.org, svarbanov@...sol.com, rostedt@...dmis.org,
	linux-arm-msm@...r.kernel.org, gregkh@...uxfoundation.org,
	collinsd@...eaurora.org, osvaldob@...eaurora.org,
	linux-kernel@...r.kernel.org, mlocke@...eaurora.org,
	galak@...eaurora.org, agross@...eaurora.org
Subject: Re: [PATCH] spmi-pmic-arb: add irq tracepoints to the pmic-arb
 driver

On Thu, 28 May 2015 18:15:59 -0700
Stephen Boyd <sboyd@...eaurora.org> wrote:

> On 05/28/2015 04:02 PM, Gilad Avidov wrote:
> > On Wed, 27 May 2015 13:06:29 -0700
> > Stephen Boyd <sboyd@...eaurora.org> wrote:
> >
> >> On 05/27, Ankit Gupta wrote:
> >>>> How is this any better than irq tracepoints that we already have
> >>>> for generic irqs?
> >>>>
> >>> It is better than generic irq tracepoints because it provides bus
> >>> specific information (sid and address(pid) of slave write), driver
> >>> specific information (apid (pmic-peripheral) and func_num) and
> >>> statistics (apid range).
> >>> Recall that *slave* read/write cannot be traced by the spmi
> >>> framework ftrace.
> >>>
> >> Don't we already get all this information based on how we map
> >> interrupts to devices in DT? It feels to me that the same
> >> argument here could be applied to all the random gpio expanders
> >> and chained interrupt controllers that we support in the kernel.
> >>
> > We don't.
> > We could get the same information if we had the irq-domain and
> > hw-irq 32bit value. While these values are available
> > from /proc/interrupt, they are not available from the irq event
> > tracing.
> 
> Hm.. maybe we should add those trace events then into the irq domain 
> layer? Or even extend the irq tracepoints to include the hw-irq and 
> irq-domain name?
> 
I agree, adding hw-irq and irq-domain name to irq-tracing is a better
idea.

> >
> > This patch traces spmi slave-originated events. If we had one such
> > slave we could cross information from both sources to filter the
> > trace events. However, we have hundreds of transaction-capable spmi
> > slaves.
> >
> 
> Sorry I'm not following this point. If it was about tracing 
> slave-originated events wouldn't it be more than irqs then?
> 
Slave originated events are converted to irqs by the spmi controller.

Thanks,
Gilad
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ