Re: [PATCH] ftrace: Remove use of control list and ops
On Tue, Dec 01, 2015 at 11:56:55AM -0500, Steven Rostedt wrote:
> On Tue, 1 Dec 2015 16:57:44 +0100
> Jiri Olsa wrote:
>
>
> > > Hmm, I thought that I forced the list function when RCU or PER_CPU
> > > was set. Oh wait. I have CONFIG_PREEMPT set, which will change the
> > > logic slightly. I'm guessing you have PREEMPT_VOLUNTARY set. I'll try
> > > that out.
> >
> > yep, but the trampoline has separate code path
> > to set the ops func
>
> Right, but that only gets called for DYNAMIC ops (which perf is) when
> CONFIG_PREEMPT is not set. What about this patch instead? (on top of my
> other one)
>
> It's a lot like yours, but instead of creating a new helper function, I
> just reuse the recurs_func instead.
>
> -- Steve
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 8b22e681baf8..05ed87d06bb0 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -5230,20 +5230,29 @@ static void ftrace_ops_no_ops(unsigned long ip,
> unsigned long parent_ip)
>
> /*
> * If there's only one function registered but it does not support
> - * recursion, this function will be called by the mcount trampoline.
> - * This function will handle recursion protection.
> + * recursion, needs RCU protection and/or requires per cpu handling, then
> + * this function will be called by the mcount trampoline.
> */
> -static void ftrace_ops_recurs_func(unsigned long ip, unsigned long parent_ip,
> +static void ftrace_ops_assist_func(unsigned long ip, unsigned long parent_ip,
> struct ftrace_ops *op, struct pt_regs *regs)
> {
> int bit;
>
> + if ((op->flags & FTRACE_OPS_FL_RCU) && !rcu_is_watching())
> + return;
> +
> bit = trace_test_and_set_recursion(TRACE_LIST_START, TRACE_LIST_MAX);
> if (bit < 0)
> return;
>
> - op->func(ip, parent_ip, op, regs);
> + preempt_disable_notrace();
I was wondering about not disabling preemption in the original
ftrace_ops_recurs_func function.. thats why I added new one ;-)
I'll test the patch
thanks,
jirka
>
> + if (!(op->flags & FTRACE_OPS_FL_PER_CPU) ||
> + ftrace_function_local_disabled(op)) {
> + op->func(ip, parent_ip, op, regs);
> + }
> +
> + preempt_enable_notrace();
> trace_clear_recursion(bit);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mach-imx: iomux-imx31: fix spelling mistake in error message
On Sat, Nov 28, 2015 at 04:27:34PM +, Colin King wrote: > From: Colin Ian King > > Minor issue, fix spelling mistake, nonexistant -> nonexistent > > Signed-off-by: Colin Ian King Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/40] staging: lustre: reflect down routes in /proc/sys/lnet/routes
On Fri, Nov 20, 2015 at 06:35:39PM -0500, James Simmons wrote:
> From: Chris Horn
>
> We consider routes "down" if the router is down or the router
> NI for the target network is down. This should be reflected
> in the output of /proc/sys/lnet/routes
>
> Signed-off-by: Chris Horn
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3679
> Reviewed-on: http://review.whamcloud.com/7857
> Reviewed-by: Cory Spitz
> Reviewed-by: Isaac Huang
> Reviewed-by: Oleg Drokin
> ---
> .../staging/lustre/include/linux/lnet/lib-lnet.h | 13
> drivers/staging/lustre/lnet/lnet/lib-move.c| 32
> ++--
> drivers/staging/lustre/lnet/lnet/router_proc.c |2 +-
> 3 files changed, 30 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
> b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
> index b61d504..09c6bfe 100644
> --- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
> +++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
> @@ -64,6 +64,19 @@ extern lnet_t the_lnet; /* THE network */
> /** exclusive lock */
> #define LNET_LOCK_EX CFS_PERCPT_LOCK_EX
>
> +static inline int lnet_is_route_alive(lnet_route_t *route)
> +{
> + /* gateway is down */
> + if (!route->lr_gateway->lp_alive)
> + return 0;
> + /* no NI status, assume it's alive */
> + if ((route->lr_gateway->lp_ping_feats &
> + LNET_PING_FEAT_NI_STATUS) == 0)
> + return 1;
> + /* has NI status, check # down NIs */
> + return route->lr_downis == 0;
> +}
> +
> static inline int lnet_is_wire_handle_none(lnet_handle_wire_t *wh)
> {
> return (wh->wh_interface_cookie == LNET_WIRE_HANDLE_COOKIE_NONE &&
> diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
> b/drivers/staging/lustre/lnet/lnet/lib-move.c
> index 7a68382..c56de44 100644
> --- a/drivers/staging/lustre/lnet/lnet/lib-move.c
> +++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
> @@ -1122,9 +1122,9 @@ static lnet_peer_t *
> lnet_find_route_locked(lnet_ni_t *ni, lnet_nid_t target, lnet_nid_t rtr_nid)
> {
> lnet_remotenet_t *rnet;
> - lnet_route_t *rtr;
> - lnet_route_t *rtr_best;
> - lnet_route_t *rtr_last;
> + lnet_route_t *route;
> + lnet_route_t *best_route;
> + lnet_route_t *last_route;
Unrelated variable renaming.
> struct lnet_peer *lp_best;
> struct lnet_peer *lp;
> int rc;
> @@ -1137,13 +1137,12 @@ lnet_find_route_locked(lnet_ni_t *ni, lnet_nid_t
> target, lnet_nid_t rtr_nid)
> return NULL;
>
> lp_best = NULL;
> - rtr_best = rtr_last = NULL;
> - list_for_each_entry(rtr, >lrn_routes, lr_list) {
> - lp = rtr->lr_gateway;
> + best_route = NULL;
> + last_route = NULL;
Unrelated checkpatch fixes.
> + list_for_each_entry(route, >lrn_routes, lr_list) {
> + lp = route->lr_gateway;
>
> - if (!lp->lp_alive || /* gateway is down */
> - ((lp->lp_ping_feats & LNET_PING_FEAT_NI_STATUS) != 0 &&
> - rtr->lr_downis != 0)) /* NI to target is down */
> + if (!lnet_is_route_alive(route))
This section is related to the patch, we moved the check out into its
own function.
> continue;
>
> if (ni != NULL && lp->lp_ni != ni)
> @@ -1153,28 +1152,29 @@ lnet_find_route_locked(lnet_ni_t *ni, lnet_nid_t
> target, lnet_nid_t rtr_nid)
> return lp;
>
> if (lp_best == NULL) {
> - rtr_best = rtr_last = rtr;
> + best_route = route;
> + last_route = route;
More unrelated checkpatch fixes.
> lp_best = lp;
> continue;
> }
>
> /* no protection on below fields, but it's harmless */
> - if (rtr_last->lr_seq - rtr->lr_seq < 0)
> - rtr_last = rtr;
> + if (last_route->lr_seq - route->lr_seq < 0)
> + last_route = route;
>
> - rc = lnet_compare_routes(rtr, rtr_best);
> + rc = lnet_compare_routes(route, best_route);
> if (rc < 0)
> continue;
>
> - rtr_best = rtr;
> + best_route = route;
> lp_best = lp;
> }
>
> /* set sequence number on the best router to the latest sequence + 1
>* so we can round-robin all routers, it's race and inaccurate but
>* harmless and functional */
> - if (rtr_best != NULL)
> - rtr_best->lr_seq = rtr_last->lr_seq + 1;
> + if (best_route)
More checkpatch fixes.
> + best_route->lr_seq = last_route->lr_seq + 1;
> return lp_best;
> }
>
> diff --git a/drivers/staging/lustre/lnet/lnet/router_proc.c
> b/drivers/staging/lustre/lnet/lnet/router_proc.c
> index 396c7c4..af7423f 100644
> ---
Re: [PATCH 03/19] bluetooth: hci_ldisc: Remove dead code
Hi Peter, > The N_HCI ldisc does not define a flush_buffer() ldisc method, so > the check when opening the ldisc is always false. > > Cc: Marcel Holtmann > Cc: Johan Hedberg > Cc: > Signed-off-by: Peter Hurley > --- > drivers/bluetooth/hci_ldisc.c | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/40] staging: lustre: fix 'NULL pointer dereference' errors for LNet
On Fri, Nov 20, 2015 at 06:35:38PM -0500, James Simmons wrote:
> From: Sebastien Buisson
>
> Fix 'NULL pointer dereference' defects found by Coverity version
> 6.5.3:
> Dereference after null check (FORWARD_NULL)
> For instance, Passing null pointer to a function which dereferences
> it.
> Dereference before null check (REVERSE_INULL)
> Null-checking variable suggests that it may be null, but it has
> already been dereferenced on all paths leading to the check.
> Dereference null return value (NULL_RETURNS)
>
> The following fixes for the LNet layer are broken out of patch
> http://review.whamcloud.com/4720.
>
> Signed-off-by: Sebastien Buisson
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2217
> Reviewed-on: http://review.whamcloud.com/4720
> Reviewed-by: Dmitry Eremin
> Reviewed-by: Oleg Drokin
> ---
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|2 +-
> drivers/staging/lustre/lnet/lnet/lib-move.c|2 +
> drivers/staging/lustre/lnet/selftest/conctl.c | 51
> ++--
> 3 files changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> index de0f85f..0f4154c 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> @@ -2829,7 +2829,7 @@ int kiblnd_startup(lnet_ni_t *ni)
> return 0;
>
> failed:
> - if (net->ibn_dev == NULL && ibdev != NULL)
> + if (net && net->ibn_dev == NULL && ibdev != NULL)
> kiblnd_destroy_dev(ibdev);
>
> net_failed:
I think the warning must be for a really really old version. This was
fixed in: 3247c4e5ef5d ('staging: lustre: lnet: klnds: o2iblnd: fix null
dereference on failed path in o2iblnd.c').
The new NULL check is superflous.
> diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
> b/drivers/staging/lustre/lnet/lnet/lib-move.c
> index 5631f60..7a68382 100644
> --- a/drivers/staging/lustre/lnet/lnet/lib-move.c
> +++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
> @@ -162,6 +162,7 @@ lnet_iov_nob(unsigned int niov, struct kvec *iov)
> {
> unsigned int nob = 0;
>
> + LASSERT(niov == 0 || iov);
> while (niov-- > 0)
> nob += (iov++)->iov_len;
>
> @@ -280,6 +281,7 @@ lnet_kiov_nob(unsigned int niov, lnet_kiov_t *kiov)
> {
> unsigned int nob = 0;
>
> + LASSERT(niov == 0 || kiov);
> while (niov-- > 0)
> nob += (kiov++)->kiov_len;
>
Fine, I suppose.
> diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c
> b/drivers/staging/lustre/lnet/selftest/conctl.c
> index 556c837..2ca7d0e 100644
> --- a/drivers/staging/lustre/lnet/selftest/conctl.c
> +++ b/drivers/staging/lustre/lnet/selftest/conctl.c
> @@ -679,45 +679,46 @@ static int
> lst_stat_query_ioctl(lstio_stat_args_t *args)
> {
> int rc;
> - char *name;
> + char *name = NULL;
>
> /* TODO: not finished */
> if (args->lstio_sta_key != console_session.ses_key)
> return -EACCES;
>
> - if (args->lstio_sta_resultp == NULL ||
> - (args->lstio_sta_namep == NULL &&
> - args->lstio_sta_idsp == NULL) ||
> - args->lstio_sta_nmlen <= 0 ||
> - args->lstio_sta_nmlen > LST_NAME_SIZE)
> - return -EINVAL;
> -
> - if (args->lstio_sta_idsp != NULL &&
> - args->lstio_sta_count <= 0)
> + if (!args->lstio_sta_resultp)
> return -EINVAL;
>
> - LIBCFS_ALLOC(name, args->lstio_sta_nmlen + 1);
> - if (name == NULL)
> - return -ENOMEM;
> -
> - if (copy_from_user(name, args->lstio_sta_namep,
> -args->lstio_sta_nmlen)) {
> - LIBCFS_FREE(name, args->lstio_sta_nmlen + 1);
> - return -EFAULT;
> - }
> + if (args->lstio_sta_idsp) {
> + if (args->lstio_sta_count <= 0)
> + return -EINVAL;
>
> - if (args->lstio_sta_idsp == NULL) {
> - rc = lstcon_group_stat(name, args->lstio_sta_timeout,
> -args->lstio_sta_resultp);
> - } else {
> rc = lstcon_nodes_stat(args->lstio_sta_count,
> args->lstio_sta_idsp,
> args->lstio_sta_timeout,
> args->lstio_sta_resultp);
> - }
> + } else if (args->lstio_sta_namep) {
> + if (args->lstio_sta_nmlen <= 0 ||
> + args->lstio_sta_nmlen > LST_NAME_SIZE)
> + return -EINVAL;
> +
> + LIBCFS_ALLOC(name, args->lstio_sta_nmlen + 1);
> + if (!name)
> + return -ENOMEM;
>
> - LIBCFS_FREE(name, args->lstio_sta_nmlen + 1);
> + rc = copy_from_user(name, args->lstio_sta_namep,
> + args->lstio_sta_nmlen);
> + if (!rc)
> +
[PATCH v2] PCI: imx6:don't sleep in atomic context
From: David Mueller
If additional PCIe switch get connected between the
host and the NIC,the kernel crashes with "BUG:
scheduling while atomic". To handle this we need to
call mdelay() instead of usleep_range().
This is currently called from atomic context through
pci_config_{read,write).
For more detail please refer bugzilla.kernel.org, Bug
100031
Signed-off-by: David Mueller
Signed-off-by: Sanjeev Sharma
Changes in v2:
-order of signoff has been change
-Author of patch has been change
-A mdelay(1000) is different timescale than
a usleep(1000).change it to correct scale i.e mdelay(1)
-updated comment
---
drivers/pci/host/pci-imx6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 233a196..c03527f 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
* Wait a little bit, then re-check if the link finished
* the training.
*/
- usleep_range(1000, 2000);
+ mdelay(1);
}
/*
* From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [char-misc-next 3/6] mei: wd: implement MEI iAMT watchdog driver
> >>
> >> Any special reason for having two data structures instead of one ?
> >> You could just move the variables from struct mei_wdt_dev into
> >> struct mei_wdt, no ?
> >
> > Yes, on newer platform mei_wdt_dev might be not present in case the the
> > device is not provisioned. This came to action in the following
> > patches.
> >
>
> It is still an implementation choice to keep the data structures separate.
> That mei_wdt_dev can be unregistered doesn't mean that the data structure
> has to be destroyed or allocated on registration.
That's correct, the issue is that if the MEI device resets or go through
suspend/resume the mei_wdt will be removed destroyed
Why watchdog daemon will still holds open handler to watchdog_device and will
releases it upon ping failure. This is where reference counter will come in.
Currently we do not support seamless reset.
> >>> +
> >>> + /* valid value is already checked by the caller */
> >>> + wdt->timeout = timeout;
> >>> + wdd->timeout = timeout;
> >>
> >> One of those seems unnecessary. Why keep the timeout twice ?
> >
> > We need two as wdd may not exists and we still need to send ping to
> > detect if the device is provisioned.
> >
>
> Ok, makes sense.
>
> >>> +
> >>> +static void mei_wdt_unregister(struct mei_wdt *wdt)
> >>> +{
> >>> + if (!wdt->mwd)
> >>> + return;
> >>> +
> >>> + watchdog_unregister_device(>mwd->wdd);
> >>> + kref_put(>mwd->refcnt, mei_wdt_release);
> >>> + wdt->mwd = NULL;
>
> If setting this to NULL was really needed, you would have a race condition
> here:
> wdt->mwd is set to NULL only after the pointer it points to was freed, leaving
> a small window where the code above could still access it.
Yes, good catch will fix that.
>
> >>> +}
> >>
> >> Seems to me that using two separate data structures instead of one
> >> adds a lot of complexity.
> >
> > It might be reduced but I'm not sure it can be significantly simpler.
> > It the reference counter will be part of watchdog_device it would be
> > simpler.
> >
>
> It would be there if struct watchdog_device was allocated by the
> watchdog core, which is not the case. I am still trying to create
> a situation where the local data structure (struct mei_wdt in this case)
> can be released while the watchdog device is still open
> (ie how to unprovision the watchdog device while in use).
This happen on device suspend/resume or device reset, this is not the case of
provisioning.
Currently the our bus layer doesn't support seamless reconnection.
> Once I figure that out, I hope I can find a way to protect it
> differently and drop the ref/unref callbacks. I suspect it may
> be necessary to separate struct watchdog_device into two parts:
> one used by drivers and one used by the watchdog core.
> The watchdog core would then manage its own data structure, and
> no longer depend on struct watchdog_device (owned by the driver)
> to actually be there. Different story, though.
I think that would somehow fit also our driver.
Thanks
Tomas
Re: [PATCH v3] arm64: dts: add all hi6220 i2c nodes
On Wed, Dec 02, 2015 at 02:29:09PM +0800, Xinwei Kong wrote:
> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
> use this I2C IP of Synopsys Designware for HiKey board.
>
> Signed-off-by: Xinwei Kong
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 31
> +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 82d2488..6eae673 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -208,5 +208,36 @@
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
> +
> + i2c0: i2c@f710 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf710 0x0 0x1000>;
> + interrupts = <0 44 4>;
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmx_func _cfg_func>;
> + status = "disabled";
You got me wrong. I was asking you to drop property 'clock-names' only,
not 'clocks' together. I do not think it works if you drop property
'clocks', because I see that dw_i2c_plat_probe() will fail if
devm_clk_get() fails. Did you test the patch before posting it out?
Shawn
> + };
> +
> + i2c1: i2c@f7101000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7101000 0x0 0x1000>;
> + interrupts = <0 45 4>;
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmx_func _cfg_func>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@f7102000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7102000 0x0 0x1000>;
> + interrupts = <0 46 4>;
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmx_func _cfg_func>;
> + status = "disabled";
> + };
> +
> };
> };
> --
> 1.9.1
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] Staging: wilc1000: Fix build break due to undeclared *wilc and implicit declaration of init_irq
On Wed, Dec 2, 2015 at 12:30 PM, Sudip Mukherjee wrote: > On Wed, Dec 02, 2015 at 08:39:10AM +0530, punit vara wrote: >> On Mon, Nov 9, 2015 at 3:53 PM, Sudip Mukherjee >> wrote: >> > On Mon, Nov 09, 2015 at 03:43:38PM +0530, punit vara wrote: >> >> On Mon, Nov 9, 2015 at 3:31 PM, glen lee wrote: >> >> > >> >> > >> >> > On 2015년 11월 09일 18:05, punit vara wrote: >> >> >> >> >> >> On Mon, Nov 9, 2015 at 2:25 PM, glen lee wrote: >> >> >>> >> >> >>> On 2015년 11월 09일 17:18, Dan Carpenter wrote: >> >> >> >> On Mon, Nov 09, 2015 at 05:02:48PM +0900, glen lee wrote: >> >> > >> >> >> >> make ./drivers/staging/wilc1000/this working fine for me >> >> >> >> but >> >> >> >> make ./drivers/staging/wilc1000/linux_wlan.o is creates error. >> > >> > I am also not getting build failure. Can you please post your .config file. >> > >> > regards >> > sudip >> I have attached .config file . and please tell me should I focus on >> this patch or not . Because build is still broken.For temporary this >> patch can be useful to fix the build .Later on as per requirement Glen >> can change the code . > > With your config file also I am not getting any build failure. Can you > please tell what are the exact compilation steps you are following? > > Here are my steps after I have copied your config file as .config. > 1) make oldconfig && make prepare > 2) make bzImage && make modules > > And I dont see any build failure. > I think you are not building bzImage and the modules before testing wilc > compilation. And that is why it is unable to find SPI or SDIO. > > regards > sudip Steps I have followed: 1. I have updated staging tree and checkout to new branch. 2. make drivers/staging/wilc1000/linux_wlan.o When I have performed second step it automatically ask me about different modules options "yes/no" I have pressed ENTER in every option .At last configuration are written to .config. and module start building and I have found error at last. I will try to perform 2 step you have suggested . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
block/scsi: WARNING: at block/blk-merge.c:435 immediately followed by BUG at drivers/scsi/scsi_lib.c:1096
Greetings, Yesterday morning and this morning, 4.4-master has exploded as below. (have crash dumps, but returning from vacation, also have backlog) [ 1576.519298] [ cut here ] [ 1576.519306] WARNING: CPU: 6 PID: 287 at block/blk-merge.c:435 blk_rq_map_sg+0x43a/0x440() [ 1576.519307] Modules linked in: tun bnep bluetooth rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc fuse af_packet bridge stp llc iscsi_ibft iscsi_boot_sysfs ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm nls_iso8859_1 nls_cp437 snd_hwdep vfat fat snd_hda_core tpm_infineon tpm_tis irqbypass crct10dif_pclmul crc32_pclmul snd_pcm tpm crc32c_intel snd_timer snd aesni_intel sr_mod r8169 [ 1576.519331] cdrom iTCO_wdt iTCO_vendor_support lpc_ich thermal battery aes_x86_64 lrw mei_me mii mei gf128mul glue_helper ablk_helper intel_smartconnect mfd_core serio_raw i2c_i801 joydev soundcore fan cryptd dm_mod efivarfs ums_realtek uas usb_storage nouveau mxm_wmi wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm video button sg autofs4 [ 1576.519347] CPU: 6 PID: 287 Comm: kworker/6:1H Not tainted 4.4.0-master #483 [ 1576.519348] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 1576.519350] Workqueue: kblockd cfq_kick_queue [ 1576.519351] 81837694 8800dc9ebb50 81299276 [ 1576.519353] 8800dc9ebb88 810552c6 [ 1576.519354] 00e0 8800db4a4a80 000f 8800dc9ebb98 [ 1576.519355] Call Trace: [ 1576.519359] [] dump_stack+0x44/0x5e [ 1576.519362] [] warn_slowpath_common+0x86/0xc0 [ 1576.519364] [] warn_slowpath_null+0x1a/0x20 [ 1576.519365] [] blk_rq_map_sg+0x43a/0x440 [ 1576.519368] [] scsi_init_sgtable+0x44/0x70 [ 1576.519369] [] scsi_init_io+0x4a/0x1c0 [ 1576.519372] [] sd_setup_read_write_cmnd+0x38/0x9d0 [ 1576.519375] [] ? scsi_host_alloc_command+0x47/0xc0 [ 1576.519376] [] sd_init_command+0x27/0xa0 [ 1576.519378] [] scsi_setup_cmnd+0xf0/0x150 [ 1576.519379] [] scsi_prep_fn+0xd1/0x170 [ 1576.519381] [] blk_peek_request+0x14f/0x260 [ 1576.519383] [] scsi_request_fn+0x3f/0x600 [ 1576.519384] [] __blk_run_queue+0x33/0x40 [ 1576.519385] [] cfq_kick_queue+0x2f/0x40 [ 1576.519388] [] process_one_work+0x143/0x3c0 [ 1576.519389] [] worker_thread+0x11a/0x450 [ 1576.519392] [] ? __schedule+0x31d/0x830 [ 1576.519393] [] ? process_one_work+0x3c0/0x3c0 [ 1576.519395] [] kthread+0xc9/0xe0 [ 1576.519396] [] ? kthread_park+0x60/0x60 [ 1576.519398] [] ret_from_fork+0x3f/0x70 [ 1576.519399] [] ? kthread_park+0x60/0x60 [ 1576.519400] ---[ end trace 0e3b884028bc69c0 ]--- [ 1576.519407] [ cut here ] [ 1576.519408] kernel BUG at drivers/scsi/scsi_lib.c:1096! [ 1576.519409] invalid opcode: [#1] SMP [ 1576.519411] Dumping ftrace buffer: [ 1576.519413](ftrace buffer empty) [ 1576.519414] Modules linked in: tun bnep bluetooth rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc fuse af_packet bridge stp llc iscsi_ibft iscsi_boot_sysfs ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm nls_iso8859_1 nls_cp437 snd_hwdep vfat fat snd_hda_core tpm_infineon tpm_tis irqbypass crct10dif_pclmul crc32_pclmul snd_pcm tpm crc32c_intel snd_timer snd aesni_intel sr_mod r8169 [ 1576.519430] cdrom iTCO_wdt iTCO_vendor_support lpc_ich thermal battery aes_x86_64 lrw mei_me mii mei gf128mul glue_helper ablk_helper intel_smartconnect mfd_core serio_raw i2c_i801 joydev soundcore fan cryptd dm_mod efivarfs ums_realtek uas usb_storage nouveau mxm_wmi wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm video button sg autofs4 [ 1576.519440] CPU: 6 PID: 287 Comm: kworker/6:1H Tainted: GW 4.4.0-master #483 [ 1576.519440] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 1576.519441] Workqueue: kblockd cfq_kick_queue [ 1576.519442] task: 8800dcde9b40 ti: 8800dc9e8000 task.ti: 8800dc9e8000 [ 1576.519443] RIP: 0010:[] [] scsi_init_sgtable+0x6a/0x70 [ 1576.519445] RSP: 0018:8800dc9ebc20 EFLAGS: 00010002 [
[PATCH v4 0/3] Exynos4210: fix power domain for MDMA1 device
This patchset fixes mysterious boot hang on Exynos 4210 SoCs, when IOMMU is enabled. There is no direct dependency between IOMMU devices and MDMA1. However enabling IOMMU changes the device probe order, what results in LCD0 power domain being turned off for some time. During that time the registration of MDMA1 device happens, what results in system hangs, because the common bus code tries to read PID/CID registers from turned-off device. Changes since v3 include some more code refactoring done to fix issues pointed by Ulf Hansson and Russel King. Best regards Marek Szyprowski Samsung R Institute Poland Changelog: v4: - fixed more issues pointed by Ulf Hansson and Russell King v3: https://lkml.org/lkml/2015/12/1/334 - fixed issues pointed by Ulf Hansson - dropped patch for exynos4210 dts, because it already got queued for merging v2: https://lkml.org/lkml/2015/11/26/229 - added 2 patches from 'On-demand device probing' thread (https://lkml.org/lkml/2015/9/29/189), which move PID/CIR reading from amba_device_add() to amba_match() - moved dev_pm_domain_attach() to amba_match(), which is allowed to return -EPROBE_DEFER v1: http://www.spinics.net/lists/arm-kernel/msg463185.html - initial version Patch summary: Marek Szyprowski (1): ARM: amba: Properly handle devices with power domains Tomeu Vizoso (2): driver core: handle -EPROBE_DEFER from bus_type.match() ARM: amba: Move reading of periphid to amba_match() Documentation/driver-model/porting.txt | 6 +- drivers/amba/bus.c | 152 ++--- drivers/base/dd.c | 24 +- include/linux/device.h | 7 +- 4 files changed, 112 insertions(+), 77 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] ARM: amba: Properly handle devices with power domains
To read pid/cid registers, the probed device need to be properly turned on.
When it is inside a power domain, the bus code should ensure that the
given power domain is enabled before trying to access device's registers.
Signed-off-by: Marek Szyprowski
Reviewed-by: Ulf Hansson
---
drivers/amba/bus.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 643127f..570033b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -60,6 +60,10 @@ static int amba_read_periphid(struct amba_device *dev)
if (!tmp)
return -ENOMEM;
+ ret = dev_pm_domain_attach(>dev, true);
+ if (ret == -EPROBE_DEFER)
+ goto err_unmap;
+
ret = amba_get_enable_pclk(dev);
if (ret == 0) {
u32 pid, cid;
@@ -84,6 +88,8 @@ static int amba_read_periphid(struct amba_device *dev)
ret = -ENODEV;
}
+ dev_pm_domain_detach(>dev, true);
+err_unmap:
iounmap(tmp);
return ret;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] driver core: handle -EPROBE_DEFER from bus_type.match()
From: Tomeu Vizoso
Allow implementations of the match() callback in struct bus_type to
return errors and if it's -EPROBE_DEFER then queue the device for
deferred probing.
This is useful to buses such as AMBA in which devices are registered
before their matching information can be retrieved from the HW
(typically because a clock driver hasn't probed yet).
Signed-off-by: Tomeu Vizoso
[changed if-else code structure, adjusted documentation to match the code,
extended comments]
Signed-off-by: Marek Szyprowski
Reviewed-by: Ulf Hansson
---
Documentation/driver-model/porting.txt | 6 --
drivers/base/dd.c | 24 ++--
include/linux/device.h | 7 +--
3 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/Documentation/driver-model/porting.txt
b/Documentation/driver-model/porting.txt
index 92d86f7..453053f 100644
--- a/Documentation/driver-model/porting.txt
+++ b/Documentation/driver-model/porting.txt
@@ -340,8 +340,10 @@ comparison:
int (*match)(struct device * dev, struct device_driver * drv);
-match should return '1' if the driver supports the device, and '0'
-otherwise.
+match should return positive value if the driver supports the device,
+and zero otherwise. It may also return error code (for example
+-EPROBE_DEFER) if determining that given driver supports the device is
+not possible.
When a device is registered, the bus's list of drivers is iterated
over. bus->match() is called for each one until a match is found.
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index a641cf3..793e915 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -490,6 +490,7 @@ static int __device_attach_driver(struct device_driver
*drv, void *_data)
struct device_attach_data *data = _data;
struct device *dev = data->dev;
bool async_allowed;
+ int ret;
/*
* Check if device has already been claimed. This may
@@ -500,8 +501,17 @@ static int __device_attach_driver(struct device_driver
*drv, void *_data)
if (dev->driver)
return -EBUSY;
- if (!driver_match_device(drv, dev))
+ ret = driver_match_device(drv, dev);
+ if (ret == 0) {
+ /* no match */
return 0;
+ } else if (ret == -EPROBE_DEFER) {
+ dev_dbg(dev, "Device match requests probe deferral\n");
+ driver_deferred_probe_add(dev);
+ } else if (ret < 0) {
+ dev_dbg(dev, "Bus failed to match device: %d", ret);
+ return ret;
+ } /* ret > 0 means positive match */
async_allowed = driver_allows_async_probing(drv);
@@ -621,6 +631,7 @@ void device_initial_probe(struct device *dev)
static int __driver_attach(struct device *dev, void *data)
{
struct device_driver *drv = data;
+ int ret;
/*
* Lock device and try to bind to it. We drop the error
@@ -632,8 +643,17 @@ static int __driver_attach(struct device *dev, void *data)
* is an error.
*/
- if (!driver_match_device(drv, dev))
+ ret = driver_match_device(drv, dev);
+ if (ret == 0) {
+ /* no match */
return 0;
+ } else if (ret == -EPROBE_DEFER) {
+ dev_dbg(dev, "Device match requests probe deferral\n");
+ driver_deferred_probe_add(dev);
+ } else if (ret < 0) {
+ dev_dbg(dev, "Bus failed to match device: %d", ret);
+ return ret;
+ } /* ret > 0 means positive match */
if (dev->parent)/* Needed for USB */
device_lock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index b8f411b..69bea82 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -70,8 +70,11 @@ extern void bus_remove_file(struct bus_type *, struct
bus_attribute *);
* @dev_groups:Default attributes of the devices on the bus.
* @drv_groups: Default attributes of the device drivers on the bus.
* @match: Called, perhaps multiple times, whenever a new device or driver
- * is added for this bus. It should return a nonzero value if the
- * given device can be handled by the given driver.
+ * is added for this bus. It should return a positive value if the
+ * given device can be handled by the given driver and zero
+ * otherwise. It may also return error code if determining that
+ * the driver supports the device is not possible. In case of
+ * -EPROBE_DEFER it will queue the device for deferred probing.
* @uevent:Called when a device is added, removed, or a few other things
* that generate uevents to add the environment variables.
* @probe: Called when a new device or driver add to this bus, and callback
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
[PATCH v4 2/3] ARM: amba: Move reading of periphid to amba_match()
From: Tomeu Vizoso
Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.
By reading the periphid in amba_match() we can return -EPROBE_DEFER if
the apb pclk isn't there yet and the device will be retried later.
Signed-off-by: Tomeu Vizoso
[minor code adjustments, removed forward declaration, added missing
comment]
Signed-off-by: Marek Szyprowski
Reviewed-by: Ulf Hansson
---
drivers/amba/bus.c | 146 +++--
1 file changed, 75 insertions(+), 71 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index f009936..643127f 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -24,6 +24,71 @@
#define to_amba_driver(d) container_of(d, struct amba_driver, drv)
+static int amba_get_enable_pclk(struct amba_device *pcdev)
+{
+ int ret;
+
+ pcdev->pclk = clk_get(>dev, "apb_pclk");
+ if (IS_ERR(pcdev->pclk))
+ return PTR_ERR(pcdev->pclk);
+
+ ret = clk_prepare_enable(pcdev->pclk);
+ if (ret)
+ clk_put(pcdev->pclk);
+
+ return ret;
+}
+
+static void amba_put_disable_pclk(struct amba_device *pcdev)
+{
+ clk_disable_unprepare(pcdev->pclk);
+ clk_put(pcdev->pclk);
+}
+
+static int amba_read_periphid(struct amba_device *dev)
+{
+ u32 size;
+ void __iomem *tmp;
+ int i, ret = 0;
+
+ /*
+* Dynamically calculate the size of the resource
+* and use this for iomap
+*/
+ size = resource_size(>res);
+ tmp = ioremap(dev->res.start, size);
+ if (!tmp)
+ return -ENOMEM;
+
+ ret = amba_get_enable_pclk(dev);
+ if (ret == 0) {
+ u32 pid, cid;
+
+ /*
+* Read pid and cid based on size of resource
+* they are located at end of region
+*/
+ for (pid = 0, i = 0; i < 4; i++)
+ pid |= (readl(tmp + size - 0x20 + 4 * i) & 255) <<
+ (i * 8);
+ for (cid = 0, i = 0; i < 4; i++)
+ cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
+ (i * 8);
+
+ amba_put_disable_pclk(dev);
+
+ if (cid == AMBA_CID || cid == CORESIGHT_CID)
+ dev->periphid = pid;
+
+ if (!dev->periphid)
+ ret = -ENODEV;
+ }
+
+ iounmap(tmp);
+
+ return ret;
+}
+
static const struct amba_id *
amba_lookup(const struct amba_id *table, struct amba_device *dev)
{
@@ -43,11 +108,19 @@ static int amba_match(struct device *dev, struct
device_driver *drv)
{
struct amba_device *pcdev = to_amba_device(dev);
struct amba_driver *pcdrv = to_amba_driver(drv);
+ int ret;
/* When driver_override is set, only bind to the matching driver */
if (pcdev->driver_override)
return !strcmp(pcdev->driver_override, drv->name);
+ /* Do plug-n-play if no hard-coded primecell ID has been provided */
+ if (!pcdev->periphid) {
+ ret = amba_read_periphid(pcdev);
+ if (ret)
+ return ret;
+ }
+
return amba_lookup(pcdrv->id_table, pcdev) != NULL;
}
@@ -204,27 +277,6 @@ static int __init amba_init(void)
postcore_initcall(amba_init);
-static int amba_get_enable_pclk(struct amba_device *pcdev)
-{
- int ret;
-
- pcdev->pclk = clk_get(>dev, "apb_pclk");
- if (IS_ERR(pcdev->pclk))
- return PTR_ERR(pcdev->pclk);
-
- ret = clk_prepare_enable(pcdev->pclk);
- if (ret)
- clk_put(pcdev->pclk);
-
- return ret;
-}
-
-static void amba_put_disable_pclk(struct amba_device *pcdev)
-{
- clk_disable_unprepare(pcdev->pclk);
- clk_put(pcdev->pclk);
-}
-
/*
* These are the device model conversion veneers; they convert the
* device model structures to our more specific structures.
@@ -341,15 +393,12 @@ static void amba_device_release(struct device *dev)
* @dev: AMBA device allocated by amba_device_alloc
* @parent: resource parent for this devices resources
*
- * Claim the resource, and read the device cell ID if not already
- * initialized. Register the AMBA device with the Linux device
+ * Claim the resource, and register the AMBA device with the Linux device
* manager.
*/
int amba_device_add(struct amba_device *dev, struct resource *parent)
{
- u32 size;
- void __iomem *tmp;
- int i, ret;
+ int ret;
WARN_ON(dev->irq[0] == (unsigned int)-1);
WARN_ON(dev->irq[1] == (unsigned int)-1);
@@ -358,51 +407,6 @@ int amba_device_add(struct amba_device *dev, struct
resource *parent)
if (ret)
goto err_out;
- /* Hard-coded primecell ID instead of plug-n-play */
- if
[PATCH V7 1/1] usb:serial: Add Fintek F81532/534 driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration by ioctl TIOCGRS485/TIOCSRS485 If the driver setting with SER_RS485_ENABLED, the RTS signal will high with not in TX and low with in TX. If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND, the RTS signal will low with not in TX and high with in TX. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). So it implements as gpiolib interface with output-only function. 5. It'll save the configuration in internal storage when uart/pins mode changed. Please reference https://bitbucket.org/hpeter/fintek-general/src/ with f81534/tools to get set_gpio.c & set_mode.c to change F81532/534 setting. Please use it carefully. Signed-off-by: Peter Hung --- Changelog: v7 1. Make all gpiolib function with #ifdef CONFIG_GPIOLIB marco block. Due to F81532/534 could run without gpiolib, we implements f81534_prepare_gpio()/f81534_release_gpio() always success without CONFIG_GPIOLIB. 2. Fix crash when receiving MSR change on driver load/unload. It's cause by f81534_process_read_urb() get read URB callback data, but port private data is not init complete or released. We solve with 2 modifications. 1. add null pointer check with f81534_process_read_urb(). We'll skip this report when port_priv = NULL. 2. when "one" port f81534_port_remove() is called, kill the port-0 read URB before kfree port_priv. v6 1. Re-implement the write()/resume() function. Due to this device cant be suitable with generic write(), we'll do the submit write URB when write()/received tx empty/set_termios()/resume() 2. Logic/Phy Port mapping rewrite in f81534_port_probe() & f81534_phy_to_logic_port(). 3. Introduced "Port Hide" function. Some customer use F81532 reference design for HW layout, but really use F81534 IC. We'll check F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do port hide with port not used. It can be avoid end-user to use not layouted port. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). So we decide to implement with gpiolib interface. 5. Add device vendor id with 0x2c42 v5 1. Change f81534_port_disable/enable() from H/W mode to S/W mode It'll skip all rx data when port is not opened. 2. Some function modifier add with static (Thanks for Paul Bolle) 3. It's will direct return when count=0 in f81534_write() to reduce spin_lock usage. v4 1. clearify f81534_process_read_urb() with f81534_process_per_serial_block(). (referenced from mxuport.c) 2. We limited f81534_write() max tx kfifo with 124Bytes. Original subsystem is designed for auto tranmiting fifo data if available. But we must wait for tx_empty for next tx data (H/W design). With this kfifo size limit, we can use generic subsystem api with f81534_write(). When usb_serial_generic_write_start() called after first write URB complete, the fifo will no data. The generic subsystem of write will go to idle state. Until we received TX_EMPTY and release write spinlock, the fifo will fill max 124Bytes by following f81534_write(). v3 1. Migrate read, write and some routine from custom code to usbserial subsystem callback function. 2. Use more defines to replece magic numbers to make it meaningful 3. Make more comments as document in source code. v2 1. v1 version submit to staging tree, but Greg KH advised me to cleanup source code & re-submit it to correct subsystem 2. Remove all custom ioctl commands drivers/usb/serial/Kconfig | 10 + drivers/usb/serial/Makefile |1 + drivers/usb/serial/f81534.c | 2945 +++ 3 files changed, 2956 insertions(+) create mode 100644 drivers/usb/serial/f81534.c diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index 56ecb8b..0642864 100644 --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -255,6 +255,16 @@ config USB_SERIAL_F81232 To compile this driver as a module, choose M here: the module will be called f81232. +config USB_SERIAL_F8153X + tristate "USB Fintek F81532/534 Multi-Ports Serial Driver" + help + Say Y here if you want to use the Fintek F81532/534 Multi-Ports + usb to serial adapter. + + To compile this driver
Re: [PATCH] mm/hugetlb resv map memory leak for placeholder entries
>
> Dmitry Vyukov reported the following memory leak
>
> unreferenced object 0x88002eaafd88 (size 32):
> comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s)
> hex dump (first 32 bytes):
> 28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff (.Nc(.Nc
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> backtrace:
> [< inline >] kmalloc include/linux/slab.h:458
> [] region_chg+0x2d4/0x6b0 mm/hugetlb.c:398
> [] __vma_reservation_common+0x2c3/0x390
> mm/hugetlb.c:1791
> [< inline >] vma_needs_reservation mm/hugetlb.c:1813
> [] alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845
> [< inline >] hugetlb_no_page mm/hugetlb.c:3543
> [] hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717
> [] follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880
> [] __get_user_pages+0x542/0xf30 mm/gup.c:497
> [] populate_vma_page_range+0xde/0x110 mm/gup.c:919
> [] __mm_populate+0x1c7/0x310 mm/gup.c:969
> [] do_mlock+0x291/0x360 mm/mlock.c:637
> [< inline >] SYSC_mlock2 mm/mlock.c:658
> [] SyS_mlock2+0x4b/0x70 mm/mlock.c:648
>
> Dmitry identified a potential memory leak in the routine region_chg,
> where a region descriptor is not free'ed on an error path.
>
> However, the root cause for the above memory leak resides in region_del.
> In this specific case, a "placeholder" entry is created in region_chg. The
> associated page allocation fails, and the placeholder entry is left in the
> reserve map. This is "by design" as the entry should be deleted when the
> map is released. The bug is in the region_del routine which is used to
> delete entries within a specific range (and when the map is released).
> region_del did not handle the case where a placeholder entry exactly matched
> the start of the range range to be deleted. In this case, the entry would
> not be deleted and leaked. The fix is to take these special placeholder
> entries into account in region_del.
>
> The region_chg error path leak is also fixed.
>
> Fixes: feba16e25a57 ("add region_del() to delete a specific range of entries")
> Cc: sta...@vger.kernel.org [4.3]
> Signed-off-by: Mike Kravetz
> Reported-by: Dmitry Vyukov
> ---
Acked-by: Hillf Danton
> mm/hugetlb.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 1101ccd94..ba07014 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -372,8 +372,10 @@ retry_locked:
> spin_unlock(>lock);
>
> trg = kmalloc(sizeof(*trg), GFP_KERNEL);
> - if (!trg)
> + if (!trg) {
> + kfree(nrg);
> return -ENOMEM;
> + }
>
> spin_lock(>lock);
> list_add(>link, >region_cache);
> @@ -483,7 +485,13 @@ static long region_del(struct resv_map *resv, long f,
> long t)
> retry:
> spin_lock(>lock);
> list_for_each_entry_safe(rg, trg, head, link) {
> - if (rg->to <= f)
> + /*
> + * file_region ranges are normally of the form [from, to).
> + * However, there may be a "placeholder" entry in the map
> + * which is of the form (from, to) with from == to. Check
> + * for placeholder entries as well.
> + */
> + if (rg->to <= f && rg->to != rg->from)
> continue;
> if (rg->from >= t)
> break;
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Update maintainer list for Intel TXT
Update maintainer list for Intel TXT Signed-off-by: Gang Wei diff --git a/MAINTAINERS b/MAINTAINERS index cba790b..84c8fe7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5621,9 +5621,7 @@ F:Documentation/trace/intel_th.txt F: drivers/hwtracing/intel_th/ INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) -M: Richard L Maliszewski -M: Gang Wei -M: Shane Wang +M: Ning Sun L: tboot-de...@lists.sourceforge.net W: http://tboot.sourceforge.net T: hg http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-graphics-maintainer] [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros
On 12/02/2015 01:04 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
>> Hi,
>>
>> On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
>>> On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh wrote:
Hi,
>>
>>
>> */
>> -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
>> -({ \
>> - unsigned long __dummy1, __dummy2; \
>> - __asm__ __volatile__ ("inl %%dx" : \
>> - "=a"(out1), \
>> - "=b"(out2), \
>> - "=c"(out3), \
>> - "=d"(out4), \
>> - "=S"(__dummy1), \
>> - "=D"(__dummy2) :\
>> - "a"(VMMOUSE_PROTO_MAGIC), \
>> - "b"(in1), \
>> - "c"(VMMOUSE_PROTO_CMD_##cmd), \
>> - "d"(VMMOUSE_PROTO_PORT) : \
>> - "memory"); \
>> +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
>> +({\
>> + unsigned long __dummy1 = 0, __dummy2 = 0; \
> Why do we need to initialize dummies?
Because for some commands those parameters to VMW_PORT() can be both
input and outout.
>>> The vmmouse commands do not use them as input though, so it seems we
>>> are simply wasting CPU cycles setting them to 0 just because we are
>>> using the new VMW_PORT here. Why do we need to switch? What is the
>>> benefit of doing this?
>> There are two reasons. One is to make the code more readable and
>> maintainable. Rather than having mostly similar inline assembly
>> code sprinkled across multiple modules, we can just use the macros
>> and document that.
> But the macro is only used here, and the variables aren't used at all,
> so it makes no sense in this file.
>
IMO, this makes a lot of sense because we now get a single definition of
VMW_PORT in the platform code that a developer can refer to to
understand things like 32-64 bit compatibilty, and usage conditions and
it also forces the developer to adopt the good practice of clearing
currently unused input variables rather than to leave them undefined. In
addition, if something needs to be changed we have one single place to
change rather than a lot of places scattered all over various kernel
modules.
Things that we (I) previously, for example, didn't get quite right in
the vmmouse module despite spending a considerable amount of time on the
subject.
Thanks,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [v8, 2/6] fsl/fman: Add FMan support
Hi David, Thank you for your feedback, I'll address it and re-submit. Regards, Igal Liberman > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, December 01, 2015 11:28 PM > To: Liberman Igal-B31950 > Cc: net...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Wood Scott-B07421 ; > Bucur Madalin-Cristian-B32716 ; > pebo...@tiscali.nl; joakim.tjernl...@transmode.se; p...@mindchasers.com; > step...@networkplumber.org > Subject: Re: [v8, 2/6] fsl/fman: Add FMan support > > From: > Date: Mon, 30 Nov 2015 14:20:58 +0200 > > > +typedef irqreturn_t (fman_exceptions_cb)(struct fman *fman, > > +enum fman_exceptions exception); > > Function and function pointer declarations and definitions should be > indented such that the second and subsequent lines begin precisely at the > first column after the openning parenthesis of the first line. > > Please audit this and fix it in your entire submission, almost ever new such > case is done incorrectly. > > > + fman->state->exceptions = (EX_DMA_BUS_ERROR | > > + EX_DMA_READ_ECC | > > + EX_DMA_SYSTEM_WRITE_ECC | > > + EX_DMA_FM_WRITE_ECC | > > + EX_FPM_STALL_ON_TASKS| > > + EX_FPM_SINGLE_ECC| > > + EX_FPM_DOUBLE_ECC| > > + > EX_QMI_DEQ_FROM_UNKNOWN_PORTID | > > + EX_BMI_LIST_RAM_ECC | > > + EX_BMI_STORAGE_PROFILE_ECC | > > + EX_BMI_STATISTICS_RAM_ECC| > > + EX_MURAM_ECC | > > + EX_BMI_DISPATCH_RAM_ECC | > > + EX_QMI_DOUBLE_ECC| > > + EX_QMI_SINGLE_ECC); > > The same applies to multi-line parenthesized expressions like this one. > Again, please audit and fix this in your entire submission. > > Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC
On 12/01/2015 09:32 PM, Heikki Krogerus wrote:
> Intel Braswell/Cherrytrail has an internal mux that shares
> one USB port between USB Device Controller and xHCI. The
> same mux is found on several SOCs from Intel, but only on
> a few Cherrytrail based platforms the OS is expected to
> configure it. Normally BIOS takes care of it.
>
> The driver for the mux is an "extcon" driver. With this we
> only register the mux if it's detected.
>
> Suggested-by: Lu Baolu
> Signed-off-by: Heikki Krogerus
> ---
> drivers/usb/host/pci-quirks.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index f940056..4e3016a 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include "pci-quirks.h"
> #include "xhci-ext-caps.h"
>
> @@ -1029,9 +1030,36 @@ static void quirk_usb_handoff_xhci(struct pci_dev
> *pdev)
> writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
>
> hc_init:
> - if (pdev->vendor == PCI_VENDOR_ID_INTEL)
> + if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> usb_enable_intel_xhci_ports(pdev);
>
> + /*
> + * Initialize the internal mux that shares a port between USB
> + * Device Controller and xHCI on platforms that have it.
> + */
> +#define XHCI_INTEL_VENDOR_CAPS 192
> +#define XHCI_INTEL_USB_MUX_OFFSET 0x80d8
> + ext_cap_offset = xhci_find_next_cap_offset(base,
> + XHCI_HCC_PARAMS_OFFSET);
> + ext_cap_offset = xhci_find_ext_cap_by_id(base, ext_cap_offset,
> + XHCI_INTEL_VENDOR_CAPS);
Hi Heikki,
This helper has been replaced with xhci_find_next_ext_cap() in
commit d5ddcdf(xhci: rework xhci extended capability list parsing functions).
Need to fix this, otherwise it will not pass compile on top of usb-next.
Thanks,
Baolu
> + if (ext_cap_offset) {
> + struct intel_usb_mux *mux;
> + struct resource r;
> +
> + r.start = pci_resource_start(pdev, 0) +
> + XHCI_INTEL_USB_MUX_OFFSET;
> + r.end = r.start + 8;
> + r.flags = IORESOURCE_MEM;
> +
> + mux = intel_usb_mux_register(>dev, );
> + if (IS_ERR(mux) && PTR_ERR(mux) == -ENOTSUPP)
> + dev_dbg(>dev, "USB mux not supported\n");
> + else if (IS_ERR(mux))
> + dev_err(>dev, "failed to register mux\n");
> + }
> + }
> +
> op_reg_base = base + XHCI_HC_LENGTH(readl(base));
>
> /* Wait for the host controller to be ready before writing any
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] Staging: wilc1000: Fix build break due to undeclared *wilc and implicit declaration of init_irq
On Wed, Dec 02, 2015 at 08:39:10AM +0530, punit vara wrote: > On Mon, Nov 9, 2015 at 3:53 PM, Sudip Mukherjee > wrote: > > On Mon, Nov 09, 2015 at 03:43:38PM +0530, punit vara wrote: > >> On Mon, Nov 9, 2015 at 3:31 PM, glen lee wrote: > >> > > >> > > >> > On 2015년 11월 09일 18:05, punit vara wrote: > >> >> > >> >> On Mon, Nov 9, 2015 at 2:25 PM, glen lee wrote: > >> >>> > >> >>> On 2015년 11월 09일 17:18, Dan Carpenter wrote: > >> > >> On Mon, Nov 09, 2015 at 05:02:48PM +0900, glen lee wrote: > >> > > >> > >> make ./drivers/staging/wilc1000/this working fine for me > >> > >> but > >> > >> make ./drivers/staging/wilc1000/linux_wlan.o is creates error. > > > > I am also not getting build failure. Can you please post your .config file. > > > > regards > > sudip > I have attached .config file . and please tell me should I focus on > this patch or not . Because build is still broken.For temporary this > patch can be useful to fix the build .Later on as per requirement Glen > can change the code . With your config file also I am not getting any build failure. Can you please tell what are the exact compilation steps you are following? Here are my steps after I have copied your config file as .config. 1) make oldconfig && make prepare 2) make bzImage && make modules And I dont see any build failure. I think you are not building bzImage and the modules before testing wilc compilation. And that is why it is unable to find SPI or SDIO. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BISECTED] rcu_sched self-detected stall since 3.17
I too have traced a similar RCU stall all the way back to 3.17. Seems to affect RCU preempt code as well. I had not been able to find a sure fail way to trigger this and it could take several days running before problem arises. Ross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nvdimm: do not show pfn_seed for non pmem regions
This simple change hides pfn_seed attribute for non pmem regions because they don't support pfn anyway. Signed-off-by: Dmitry V. Krivenok --- drivers/nvdimm/region_devs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c index 529f3f0..3d730d1 100644 --- a/drivers/nvdimm/region_devs.c +++ b/drivers/nvdimm/region_devs.c @@ -406,6 +406,9 @@ static umode_t region_visible(struct kobject *kobj, struct attribute *a, int n) struct nd_interleave_set *nd_set = nd_region->nd_set; int type = nd_region_to_nstype(nd_region); + if (!is_nd_pmem(dev) && a == _attr_pfn_seed.attr) + return 0; + if (a != _attr_set_cookie.attr && a != _attr_available_size.attr) return a->mode; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] oom kill init lead panic
From: chenjie when oom happened we can see: Out of memory: Kill process 9134 (init) score 3 or sacrifice child Killed process 9134 (init) total-vm:1868kB, anon-rss:84kB, file-rss:572kB Kill process 1 (init) sharing same memory ... Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 That's because: the busybox init will vfork a process,oom_kill_process found the init not the children,their mm is the same when vfork. Cc: Signed-off-by: Chen Jie --- mm/oom_kill.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index d13a339..a0ddebd 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -608,6 +608,8 @@ void oom_kill_process(struct oom_control *oc, struct task_struct *p, continue; if (unlikely(p->flags & PF_KTHREAD)) continue; + if (!is_global_init(p)) + continue; if (p->signal->oom_score_adj == OOM_SCORE_ADJ_MIN) continue; -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] arm64: dts: add all hi6220 i2c nodes
This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
use this I2C IP of Synopsys Designware for HiKey board.
Signed-off-by: Xinwei Kong
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 82d2488..6eae673 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -208,5 +208,36 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+ i2c0: i2c@f710 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0xf710 0x0 0x1000>;
+ interrupts = <0 44 4>;
+ i2c-sda-hold-time-ns = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pmx_func _cfg_func>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@f7101000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0xf7101000 0x0 0x1000>;
+ interrupts = <0 45 4>;
+ i2c-sda-hold-time-ns = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pmx_func _cfg_func>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@f7102000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x0 0xf7102000 0x0 0x1000>;
+ interrupts = <0 46 4>;
+ i2c-sda-hold-time-ns = <300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pmx_func _cfg_func>;
+ status = "disabled";
+ };
+
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH cgroup/for-4.4-fixes 2/3] cgroup: fix handling of multi-destination migration from subtree_control enabling
Hi Tejun, On 12/01/2015 05:44 PM, Tejun Heo wrote: > On Tue, Dec 01, 2015 at 08:02:23AM +0100, Daniel Wagner wrote: >> I was not able to verify if these two patches are fixing it. I don't see >> the call trace on mainline only when using cgroup/review-xt_cgroup2 >> review branch. >> >> So I ported it to review-xt_croup2 with only a small merge conflict for >> in netclassid_cgroup.c. No fun though, I still see it. > > It also needs the previous ref fix patch and Oleg's race fix too. Can > you please test the following branch? > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git > review-pids-fixes First I verified that I see the stack trace using v4.4-rc1. Then I forwarded to review-pids-fixes and all looks good now. You can add a Tested-by: Daniel Wagner if you like. Thanks! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cgroups: move cpuset specific checks from generic code to cpuset_can_attach (v2)
On Tue, 2015-12-01 at 11:49 -0500, Tejun Heo wrote: > On Thu, Nov 26, 2015 at 08:32:32PM -0200, Marcelo Tosatti wrote: > > > > Move PF_NO_SETAFFINITY and kthreadd_task checks to cpuset cgroups, > > where they belong. This makes it possible to attach PF_NO_SETAFFINITY > > tasks to Intel CAT cgroup. > > > > Reported-by: Luiz Capitulino > > Signed-off-by: Marcelo Tosatti > > Reviewed-by: Chao Peng > > > > v2: "PF_NO_SETAFFINITY check" -> "PF_NO_SETAFFINITY and kthreadd_task > > checks" > > This wasn't just for cpuset. It's for all controllers. Hm, indeed. Workers landing in a throttled cfs rq wouldn't be as painful as an rt worker being born in an rq with no rt_runtime, but could sting. Workers stuffed into the freezer would sting mightily. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: use common return path
On Wed, Dec 02, 2015 at 10:32:49AM +0530, Sudip Mukherjee wrote: > By "common exit path" do you mean mixing up of success and error paths? Normally it's just the error paths which are mixed together. Back in the day, this unisys driver had tons of error handling bugs so that I didn't even bother reporting them all. http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-May/068932.html http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-May/069073.html regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk
On Intel platforms, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a port hung
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.
The state could be resolved by performing a port reset to the
debug port from the host xHCI. This patch introduces this work
around.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 52
include/linux/usb/xhci-dbc.h | 2 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 254a0a8..41ce116 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -255,6 +255,8 @@ static void __iomem *xdbc_map_pci_mmio(u32 bus,
xdbcp->bar = bar;
xdbcp->xhci_base = base;
xdbcp->xhci_length = sz64;
+ xdbcp->vendor = read_pci_config_16(bus, dev, func, PCI_VENDOR_ID);
+ xdbcp->device = read_pci_config_16(bus, dev, func, PCI_DEVICE_ID);
if (length)
*length = sz64;
@@ -638,6 +640,52 @@ static int xdbc_mem_init(void)
return 0;
}
+static void xdbc_reset_debug_port_callback(int cap_offset, void *data)
+{
+ u8 major;
+ u32 val, port_offset, port_count;
+ u32 cap_length;
+ void __iomem *ops_reg;
+ void __iomem *portsc;
+ int i;
+
+ val = readl(xdbcp->xhci_base + cap_offset);
+ major = (u8) XHCI_EXT_PORT_MAJOR(val);
+
+ /* only reset super-speed port */
+ if (major != 0x3)
+ return;
+
+ val = readl(xdbcp->xhci_base + cap_offset + 8);
+ port_offset = XHCI_EXT_PORT_OFF(val);
+ port_count = XHCI_EXT_PORT_COUNT(val);
+ xdbc_trace("Extcap Port offset %d count %d\n",
+ port_offset, port_count);
+
+ cap_length = readl(xdbcp->xhci_base) & 0xff;
+ ops_reg = xdbcp->xhci_base + cap_length;
+
+ port_offset--;
+ for (i = port_offset; i < (port_offset + port_count); i++) {
+ portsc = ops_reg + 0x400 + i * 0x10;
+ val = readl(portsc);
+ /* reset the port if CCS bit is cleared */
+ if (!(val & 0x1))
+ writel(val | (1 << 4), portsc);
+ }
+}
+
+static void xdbc_reset_debug_port(void)
+{
+ xdbc_walk_excap(xdbcp->bus,
+ xdbcp->dev,
+ xdbcp->func,
+ XHCI_EXT_CAPS_PROTOCOL,
+ false,
+ xdbc_reset_debug_port_callback,
+ NULL);
+}
+
/*
* xdbc_start: start DbC
*
@@ -656,6 +704,10 @@ static int xdbc_start(void)
return -ENODEV;
}
+ /* reset port to avoid bus hang */
+ if (xdbcp->vendor == PCI_VENDOR_ID_INTEL)
+ xdbc_reset_debug_port();
+
/* wait for port connection */
if (handshake(>xdbc_reg->portsc, PORTSC_CCS,
PORTSC_CCS, 500, 100) < 0) {
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 153fb87..fc0ef9a 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -128,6 +128,8 @@ struct xdbc_state {
u32 dev;
u32 func;
u8 bar;
+ u16 vendor;
+ u16 device;
void __iomem*xhci_base;
size_t xhci_length;
#defineXDBC_PCI_MAX_BUSES 256
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1] ARM: dts: imx6: Change the clock name for spba clock
On Thu, Nov 26, 2015 at 10:39:30AM +0800, Shengjiu Wang wrote: > Audio IP need the spba clock, but original clock name "dma" is not > accurate, so change it to name "spba". The audio driver has been > using the new name "spba", the binding document has been updated. > > Signed-off-by: Shengjiu Wang Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 03/12] usb: xhci: dbc: probe and setup xhci debug capability
xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.
This patch introduces the code to probe and initialize the debug
capability hardware during early boot. With hardware initialization
done, the debug target (system under debug which has DbC enabled)
will present a debug device through the debug port. The debug device
is fully compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link between the
debug host and target.
Signed-off-by: Lu Baolu
---
MAINTAINERS | 7 +
arch/x86/Kconfig.debug | 12 +
drivers/usb/early/Makefile | 1 +
drivers/usb/early/xhci-dbc.c | 774 +++
include/linux/usb/xhci-dbc.h | 187 +++
5 files changed, 981 insertions(+)
create mode 100644 drivers/usb/early/xhci-dbc.c
create mode 100644 include/linux/usb/xhci-dbc.h
diff --git a/MAINTAINERS b/MAINTAINERS
index cba790b..9fb7c2f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11266,6 +11266,13 @@ S: Supported
F: drivers/usb/host/xhci*
F: drivers/usb/host/pci-quirks*
+USB XHCI DEBUG PORT
+M: Lu Baolu
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/usb/early/xhci-dbc.c
+F: include/linux/usb/xhci-dbc.h
+
USB ZD1201 DRIVER
L: linux-wirel...@vger.kernel.org
W: http://linux-lc100020.sourceforge.net
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 137dfa9..e450f88 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -65,6 +65,18 @@ config EARLY_PRINTK_EFI
This is useful for kernel debugging when your machine crashes very
early before the console code is initialized.
+config EARLY_PRINTK_XDBC
+ bool "Early printk via xHCI debug port"
+ depends on EARLY_PRINTK && PCI
+ ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
config X86_PTDUMP_CORE
def_bool n
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..2db5906 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..254a0a8
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,774 @@
+/**
+ * xhci-dbc.c - xHCI debug capability driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Lu Baolu
+ * Some code shared with EHCI debug port and xHCI driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../host/xhci.h"
+
+#defineXDBC_PROTOCOL 1 /* GNU Remote Debug Command Set
*/
+#defineXDBC_VENDOR_ID 0x1d6b /* Linux Foundation 0x1d6b */
+#defineXDBC_PRODUCT_ID 0x0004 /* __le16 idProduct; device
0004 */
+#defineXDBC_DEVICE_REV 0x0010 /* 0.10 */
+
+static struct xdbc_state xdbc_stat;
+static struct xdbc_state *xdbcp = _stat;
+
+#ifdef DBC_DEBUG
+/* place holder */
+#definexdbc_trace printk
+static void xdbc_dbg_dump_regs(char *str)
+{
+ if (!xdbcp->xdbc_reg) {
+ xdbc_trace("register not mapped\n");
+ return;
+ }
+
+ xdbc_trace("XDBC registers: %s\n", str);
+ xdbc_trace(" Capability: %08x\n",
+ readl(>xdbc_reg->capability));
+ xdbc_trace(" Door bell: %08x\n",
+ readl(>xdbc_reg->doorbell));
+ xdbc_trace(" Event Ring Segment Table Size: %08x\n",
+ readl(>xdbc_reg->ersts));
+ xdbc_trace(" Event Ring Segment Table Base Address: %16llx\n",
+ xdbc_read64(>xdbc_reg->erstba));
+ xdbc_trace(" Event Ring Dequeue Pointer: %16llx\n",
+ xdbc_read64(>xdbc_reg->erdp));
+ xdbc_trace(" Port status and control: %08x\n",
+ readl(>xdbc_reg->portsc));
+ xdbc_trace(" Debug Capability Context Pointer: %16llx\n",
+ xdbc_read64(>xdbc_reg->dccp));
+ xdbc_trace(" Device Descriptor Info Register 1: %08x\n",
+
[PATCH v5 05/12] usb: xhci: dbc: add debug buffer
"printk" is not suitable for dbc debugging especially when console
is in usage. This patch adds a debug buffer in dbc driver and puts
the debug messages in this local buffer. The debug buffer could be
dumped whenever the console is not in use. This part of code will
not be visible unless DBC_DEBUG is defined.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 62 ++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 41ce116..6855048 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
static struct xdbc_state *xdbcp = _stat;
#ifdef DBC_DEBUG
-/* place holder */
-#definexdbc_trace printk
+#defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
+#defineMSG_MAX_LINE128
+static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
+static void xdbc_trace(const char *fmt, ...)
+{
+ int i, size;
+ va_list args;
+ static int pos;
+ char temp_buf[MSG_MAX_LINE];
+
+ if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+ return;
+
+ memset(temp_buf, 0, MSG_MAX_LINE);
+ va_start(args, fmt);
+ vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
+ va_end(args);
+
+ i = 0;
+ size = strlen(temp_buf);
+ while (i < size) {
+ xdbc_debug_buf[pos] = temp_buf[i];
+ pos++;
+ i++;
+
+ if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+ break;
+ }
+}
+
+static void xdbc_dump_debug_buffer(void)
+{
+ int index = 0;
+ int count = 0;
+ char dump_buf[MSG_MAX_LINE];
+
+ xdbc_trace("The end of DbC trace buffer\n");
+ pr_notice("DBC debug buffer:\n");
+ memset(dump_buf, 0, MSG_MAX_LINE);
+
+ while (index < XDBC_DEBUG_BUF_SIZE) {
+ if (!xdbc_debug_buf[index])
+ break;
+
+ if (xdbc_debug_buf[index] == '\n' ||
+ count >= MSG_MAX_LINE - 1) {
+ pr_notice("DBC: @%08x %s\n", index, dump_buf);
+ memset(dump_buf, 0, MSG_MAX_LINE);
+ count = 0;
+ } else {
+ dump_buf[count] = xdbc_debug_buf[index];
+ count++;
+ }
+
+ index++;
+ }
+}
+
static void xdbc_dbg_dump_regs(char *str)
{
if (!xdbcp->xdbc_reg) {
@@ -165,6 +221,7 @@ static void xdbc_dbg_dump_data(char *str)
#else
static inline void xdbc_trace(const char *fmt, ...) { }
+static inline void xdbc_dump_debug_buffer(void) { }
static inline void xdbc_dbg_dump_regs(char *str) { }
static inline void xdbc_dbg_dump_data(char *str) { }
#endif /* DBC_DEBUG */
@@ -819,6 +876,7 @@ int __init early_xdbc_init(char *s)
pr_notice("failed to setup xHCI DbC connection\n");
xdbcp->xhci_base = NULL;
xdbcp->xdbc_reg = NULL;
+ xdbc_dump_debug_buffer();
return ret;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 10/12] usb: xhci: dbc: add handshake between debug target and host
After DbC setup, debug target needs to wait until tty driver and
application (e.g. mincom) on debug taget start. Otherwise, out
messages might be ignored.
This patch adds a ping/pong mechanism between debug target and
host. Debug target will be waiting there until user presses 'Y'
or 'y' in the tty application.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6c24ba0..37c5c87 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,6 +32,9 @@
static struct xdbc_state xdbc_stat;
static struct xdbc_state *xdbcp = _stat;
+static int early_xdbc_read(struct console *con, char *str, unsigned n);
+static void early_xdbc_write(struct console *con, const char *str, u32 n);
+
#ifdef DBC_DEBUG
#defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
#defineMSG_MAX_LINE128
@@ -860,8 +863,12 @@ int __init early_xdbc_init(char *s)
{
u32 bus = 0, dev = 0, func = 0;
unsigned long dbgp_num = 0;
+ char *ping = "Press Y to continue...\n";
+ char pong[64];
+ size_t size;
u32 offset;
int ret;
+ int retry = 20;
if (!early_pci_allowed())
return -EPERM;
@@ -904,6 +911,21 @@ int __init early_xdbc_init(char *s)
return ret;
}
+ while (retry > 0) {
+ early_xdbc_write(NULL, ping, strlen(ping));
+ size = early_xdbc_read(NULL, pong, 64);
+ if (size > 0) {
+ xdbc_trace("%s: pong message: %s\n", __func__, pong);
+ if (pong[0] == 'Y' || pong[0] == 'y')
+ break;
+ } else {
+ xdbc_trace("%s: pong message error %d\n",
+ __func__, size);
+ }
+
+ retry--;
+ }
+
return 0;
}
@@ -1325,6 +1347,11 @@ int xdbc_bulk_write(const char *bytes, int size)
* Start a bulk-in or bulk-out transfer, wait until transfer completion
* or error. Return the count of actually transferred bytes or error.
*/
+static int early_xdbc_read(struct console *con, char *str, unsigned n)
+{
+ return xdbc_bulk_read(str, n, 0);
+}
+
static void early_xdbc_write(struct console *con, const char *str, u32 n)
{
int chunk, ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 09/12] x86: early_printk: add USB3 debug port earlyprintk support
Add support for early printk by writing debug messages to the USB3
debug port. Users can use this type of early printk by specifying
kernel parameter of "earlyprintk=xdbc". This gives users a chance
of providing debug output.
Signed-off-by: Lu Baolu
---
Documentation/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
drivers/usb/early/xhci-dbc.c| 43 +
include/linux/usb/xhci-dbc.h| 5 +
4 files changed, 54 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index e6b6e056..dfce467 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1049,6 +1049,7 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+ earlyprintk=xdbc[xhciController#]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 21bf924..ba4c471 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -373,6 +374,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "dbgp", 4) && !early_dbgp_init(buf + 4))
early_console_register(_dbgp_console, keep);
#endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+ if (!strncmp(buf, "xdbc", 4) && !early_xdbc_init(buf + 4))
+ early_console_register(_xdbc_console, keep);
+#endif
#ifdef CONFIG_HVC_XEN
if (!strncmp(buf, "xen", 3))
early_console_register(_console, keep);
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 344d93e..6c24ba0 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -10,6 +10,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -1319,3 +1320,45 @@ int xdbc_bulk_write(const char *bytes, int size)
return ret;
}
+
+/*
+ * Start a bulk-in or bulk-out transfer, wait until transfer completion
+ * or error. Return the count of actually transferred bytes or error.
+ */
+static void early_xdbc_write(struct console *con, const char *str, u32 n)
+{
+ int chunk, ret;
+ static char buf[XDBC_MAX_PACKET];
+ int use_cr = 0;
+
+ if (!xdbcp->xdbc_reg)
+ return;
+ memset(buf, 0, XDBC_MAX_PACKET);
+ while (n > 0) {
+ for (chunk = 0; chunk < XDBC_MAX_PACKET && n > 0;
+str++, chunk++, n--) {
+ if (!use_cr && *str == '\n') {
+ use_cr = 1;
+ buf[chunk] = '\r';
+ str--;
+ n++;
+ continue;
+ }
+ if (use_cr)
+ use_cr = 0;
+ buf[chunk] = *str;
+ }
+ if (chunk > 0) {
+ ret = xdbc_bulk_write(buf, chunk);
+ if (ret < 0)
+ break;
+ }
+ }
+}
+
+struct console early_xdbc_console = {
+ .name = "earlyxdbc",
+ .write =early_xdbc_write,
+ .flags =CON_PRINTBUFFER,
+ .index =-1,
+};
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 289ba58..a556eb8 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -216,4 +216,9 @@ struct xdbc_state {
#definexdbc_read64(regs) xhci_read_64(NULL, (regs))
#definexdbc_write64(val, regs) xhci_write_64(NULL, (val), (regs))
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+extern int early_xdbc_init(char *s);
+extern struct console early_xdbc_console;
+#endif /* CONFIG_EARLY_PRINTK_XDBC */
+
#endif /* __LINUX_XHCI_DBC_H */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 07/12] usb: xhci: dbc: handle dbc-configured exit
DbC might exit configured state in some cases (refer to 7.6.4.4 in
xHCI spec 1.1). Software needs detect and clear this situation by
clearing DCCTRL.DCR and wait until the DbC configured before read
or write oprations.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index f59c80ef..c81df40 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1140,6 +1140,29 @@ static int xdbc_wait_until_bulk_done(struct xdbc_trb
*trb, int loops)
return -EIO;
}
+static int xdbc_wait_until_dbc_configured(void)
+{
+ int timeout = 0;
+ u32 reg;
+
+ /* Port exits configured state */
+ reg = readl(>xdbc_reg->control);
+ if (!(reg & CTRL_DRC))
+ return 0;
+
+ /* clear run change bit (RW1C) */
+ writel(reg | CTRL_DRC, >xdbc_reg->control);
+
+ do {
+ if (readl(>xdbc_reg->control) & CTRL_DCR)
+ return 0;
+
+ xdbc_udelay(10);
+ } while (timeout++ < XDBC_LOOPS);
+
+ return -ETIMEDOUT;
+}
+
static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
{
u64 addr;
@@ -1154,6 +1177,11 @@ static int xdbc_bulk_transfer(void *data, int size, int
loops, bool read)
return -EINVAL;
}
+ if (xdbc_wait_until_dbc_configured()) {
+ xdbc_trace("%s: hardware not ready\n", __func__);
+ return -EPERM;
+ }
+
ring = (read ? >in_ring : >out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 06/12] usb: xhci: dbc: add bulk out and bulk in interfaces
This patch adds interfaces for bulk out and bulk in ops. These
interfaces could be used to implement early printk bootconsole
or hook to various system debuggers.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 373 +++
include/linux/usb/xhci-dbc.h | 30
2 files changed, 403 insertions(+)
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6855048..f59c80ef 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -219,11 +219,21 @@ static void xdbc_dbg_dump_data(char *str)
xdbc_dbg_dump_string("String Descriptor:");
}
+static void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str)
+{
+ xdbc_trace("DBC trb: %s\n", str);
+ xdbc_trace("@%016llx %08x %08x %08x %08x\n", (u64)__pa(trb),
+ le32_to_cpu(trb->field[0]),
+ le32_to_cpu(trb->field[1]),
+ le32_to_cpu(trb->field[2]),
+ le32_to_cpu(trb->field[3]));
+}
#else
static inline void xdbc_trace(const char *fmt, ...) { }
static inline void xdbc_dump_debug_buffer(void) { }
static inline void xdbc_dbg_dump_regs(char *str) { }
static inline void xdbc_dbg_dump_data(char *str) { }
+static inline void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str) { }
#endif /* DBC_DEBUG */
/*
@@ -334,6 +344,7 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
static char in_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char out_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char table_page[PAGE_SIZE] __aligned(PAGE_SIZE);
+ static char bulk_buf_page[PAGE_SIZE] __aligned(PAGE_SIZE);
switch (type) {
case XDBC_PAGE_EVENT:
@@ -348,6 +359,9 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
case XDBC_PAGE_TABLE:
virt = (void *)table_page;
break;
+ case XDBC_PAGE_BUFFER:
+ virt = (void *)bulk_buf_page;
+ break;
default:
return NULL;
}
@@ -694,6 +708,12 @@ static int xdbc_mem_init(void)
dev_info = cpu_to_le32((XDBC_DEVICE_REV << 16) | XDBC_PRODUCT_ID);
writel(dev_info, >xdbc_reg->devinfo2);
+ /* get and store the transfer buffer */
+ xdbcp->out_buf = xdbc_get_page(>out_dma,
+ XDBC_PAGE_BUFFER);
+ xdbcp->in_buf = xdbcp->out_buf + XDBC_MAX_PACKET;
+ xdbcp->in_dma = xdbcp->out_dma + XDBC_MAX_PACKET;
+
return 0;
}
@@ -789,6 +809,9 @@ static int xdbc_start(void)
xdbc_trace("root hub port number %d\n", DCST_DPN(status));
+ xdbcp->in_ep_state = EP_RUNNING;
+ xdbcp->out_ep_state = EP_RUNNING;
+
xdbc_trace("DbC is running now, control 0x%08x\n",
readl(>xdbc_reg->control));
@@ -882,3 +905,353 @@ int __init early_xdbc_init(char *s)
return 0;
}
+
+static void xdbc_queue_trb(struct xdbc_ring *ring,
+ u32 field1, u32 field2, u32 field3, u32 field4)
+{
+ struct xdbc_trb *trb, *link_trb;
+
+ trb = ring->enqueue;
+ trb->field[0] = cpu_to_le32(field1);
+ trb->field[1] = cpu_to_le32(field2);
+ trb->field[2] = cpu_to_le32(field3);
+ trb->field[3] = cpu_to_le32(field4);
+
+ xdbc_dbg_dump_trb(trb, "enqueue trb");
+
+ ++(ring->enqueue);
+ if (ring->enqueue >= >segment->trbs[TRBS_PER_SEGMENT - 1]) {
+ link_trb = ring->enqueue;
+ if (ring->cycle_state)
+ link_trb->field[3] |= cpu_to_le32(TRB_CYCLE);
+ else
+ link_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
+
+ ring->enqueue = ring->segment->trbs;
+ ring->cycle_state ^= 1;
+ }
+}
+
+static void xdbc_ring_doorbell(int target)
+{
+ writel(DOOR_BELL_TARGET(target), >xdbc_reg->doorbell);
+}
+
+static void xdbc_handle_port_status(struct xdbc_trb *evt_trb)
+{
+ u32 port_reg;
+
+ port_reg = readl(>xdbc_reg->portsc);
+
+ if (port_reg & PORTSC_CSC) {
+ xdbc_trace("%s: connect status change event\n", __func__);
+ writel(port_reg | PORTSC_CSC, >xdbc_reg->portsc);
+ port_reg = readl(>xdbc_reg->portsc);
+ }
+
+ if (port_reg & PORTSC_PRC) {
+ xdbc_trace("%s: port reset change event\n", __func__);
+ writel(port_reg | PORTSC_PRC, >xdbc_reg->portsc);
+ port_reg = readl(>xdbc_reg->portsc);
+ }
+
+ if (port_reg & PORTSC_PLC) {
+ xdbc_trace("%s: port link status change event\n", __func__);
+ writel(port_reg | PORTSC_PLC, >xdbc_reg->portsc);
+ port_reg = readl(>xdbc_reg->portsc);
+ }
+
+ if (port_reg & PORTSC_CEC) {
+ xdbc_trace("%s: config error change\n", __func__);
+ writel(port_reg | PORTSC_CEC, >xdbc_reg->portsc);
+
[PATCH v5 12/12] usb: doc: add document for xHCI DbC driver
Add Documentation/usb/xhci-dbc.txt. This document includes development status and user guide for USB3 debug port. Signed-off-by: Lu Baolu --- Documentation/usb/xhci-dbc.txt | 350 + MAINTAINERS| 1 + drivers/usb/early/xhci-dbc.c | 3 + 3 files changed, 354 insertions(+) create mode 100644 Documentation/usb/xhci-dbc.txt diff --git a/Documentation/usb/xhci-dbc.txt b/Documentation/usb/xhci-dbc.txt new file mode 100644 index 000..564fd8f --- /dev/null +++ b/Documentation/usb/xhci-dbc.txt @@ -0,0 +1,350 @@ +xHCI debug capability driver + + Lu Baolu + +Last-updated: September 2015 + + + Contents: + - + * What is xHCI DbC? + * Debug topologies + * Debug stacks + * Port Multiplexing + * Hardware initialization + * External reset + * Port reset + * Interrupt/DMA/Memory during early boot + * Endpoint STALL + * Debug device information + * How to use DbC early printk? + * Limitations + + What is xHCI DbC? + - + +The xHCI Debugging Capability defined in section 7.6 of xHCI spec 1.1 +provides an optional functionality that enables low-level system debug +over USB. It provides a means of connecting two systems where one system +is a Debug Host and the other a Debug Target (System Under Test). The +Debug Capability provides an interface that is completely independent +of the xHCI interface. A Debug Target enumerates as a USB debug device +to the Debug Host, allowing a Debug Host to access a Debug Target through +the standard USB software stack. + + Debug topologies + + +Multiple Debug Targets may be attached to a single Debug Host. Debug +Targets may be connected to any downstream facing port below a Debug +Host (i.e. anywhere in the fabric, root port or external hub puts). +A Debug Target may only connect to a Debug Host through a Root Hub port +of the target. That means connection of a Debug Target to a Debug Host +through the ports of an external hub is not supported. + +Below is a typical connection between Debug Host and Debug target. Two +Debug targets are connected to a single Debug host. + + + +| Debug Host | | Debug Target | +|| || +|xHC without DbC | | xHC with DbC | +|or DbC disabled | | enabled| +|| || +|P1| |p2| |P1| |p2| +|__| |__| |__| |__| + || | + ||_| + |_ +| + ___| +| HUB | | Debug Target | +|| || +| Superspeed hub | | xHC with DbC | +|| | enabled| +|| || +|P1| |p2| |P1| |p2| +|__| |__| |__| |__| + | | + |_| + + Debug stacks + + +Below is a software stack diagram of both Debug Host and Debug Target. + + +| Debug Host | | Debug Target | +|| || +| debug App| || +|| | system debug | +| usb_debug| | hooks | +|| || +|usbcore | || +|| |debug capability| +|xhci_hcd| | driver | +|| || +|xHC without DbC | | xHC with DbC | +|or DbC disabled | | enabled| +|| || +|P1| |p2| |P1| |p2| +|__| |__| |__| |__| + | | + |_| + + + Port Multiplexing + - + +A debug port is always multiplexed with the first xHCI root hub port. +Whenever debug capability is supported and enabled, and the first root +hub port is detected to be connected to a downstream super-speed port +of a Debug Host, the root hub port is assigned to the debug capability +and operating
[PATCH v5 08/12] usb: xhci: dbc: handle endpoint stall
In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recovered before
read or write oprations.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index c81df40..344d93e 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1163,6 +1163,37 @@ static int xdbc_wait_until_dbc_configured(void)
return -ETIMEDOUT;
}
+static int xdbc_wait_until_epstall_cleared(bool read)
+{
+ int timeout = 0;
+
+ if (read) {
+ do {
+ if (!(readl(>xdbc_reg->control) & CTRL_HIT)) {
+ xdbcp->in_ep_state = EP_RUNNING;
+
+ return 0;
+ }
+
+ xdbcp->in_ep_state = EP_HALTED;
+ xdbc_udelay(10);
+ } while (timeout++ < XDBC_LOOPS);
+ } else {
+ do {
+ if (!(readl(>xdbc_reg->control) & CTRL_HOT)) {
+ xdbcp->out_ep_state = EP_RUNNING;
+
+ return 0;
+ }
+
+ xdbcp->out_ep_state = EP_HALTED;
+ xdbc_udelay(10);
+ } while (timeout++ < XDBC_LOOPS);
+ }
+
+ return -ETIMEDOUT;
+}
+
static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
{
u64 addr;
@@ -1182,6 +1213,11 @@ static int xdbc_bulk_transfer(void *data, int size, int
loops, bool read)
return -EPERM;
}
+ if (xdbc_wait_until_epstall_cleared(read)) {
+ xdbc_trace("%s: endpoint not ready\n", __func__);
+ return -EPERM;
+ }
+
ring = (read ? >in_ring : >out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 11/12] usb: serial: usb_debug: add support for dbc debug device
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
};
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+ { USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
/* This HW really does not support a serial break, so one will be
* emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
};
+static struct usb_serial_driver dbc_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = "xhci_dbc",
+ },
+ .id_table = dbc_id_table,
+ .num_ports =1,
+ .break_ctl =usb_debug_break_ctl,
+ .process_read_urb = usb_debug_process_read_urb,
+};
+
static struct usb_serial_driver * const serial_drivers[] = {
- _device, NULL
+ _device, _device, NULL
};
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_LICENSE("GPL");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 01/12] usb: xhci: add sysfs file for xHCI debug port
This patch adds a sysfs file for users to check 1) whether the debug
capability is implemented by hardware; 2) if supported, which state
does it stay at.
With a host that supports debug port, a file named "debug_port_state"
will be created under the device sysfs directory. Reading this file
will show users the state (disabled, enabled or configured) of the
debug port.
With a host that does NOT support debug port, "debug_port_state" file
won't be created.
Signed-off-by: Lu Baolu
---
.../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 23
drivers/usb/host/Makefile | 2 +-
drivers/usb/host/xhci-ext-caps.h | 5 ++
drivers/usb/host/xhci-sysfs.c | 65 ++
drivers/usb/host/xhci.c| 4 ++
drivers/usb/host/xhci.h| 4 ++
6 files changed, 102 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
create mode 100644 drivers/usb/host/xhci-sysfs.c
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
new file mode 100644
index 000..5d0a7d3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -0,0 +1,23 @@
+What: /sys/bus/pci/drivers/xhci_hcd/.../debug_port_state
+Date: November 2015
+KernelVersion: 4.4.0
+Contact: Lu Baolu
+Description:
+ This file is designed for users to check the state of a
+ USB3 debug port. On a machine which supports USB3 debug
+ port, this file will be created. Reading this file will
+ show the state (disabled, enabled or configured) of the
+ debug port. On a machine that doesn't support USB3 debug
+ port, this file doesn't exist.
+
+ The state of a debug port could be:
+ 1) disabled: The debug port is not enabled and the root
+ port has been switched to xHCI host as a normal
+ root port.
+ 2) enabled: The debug port is enabled. The debug port
+ has been assigned to debug capability. The debug
+ capability is able to handle the control requests
+ defined in USB3 spec.
+ 3) configured: The debug port has been enumerated by the
+ debug host as a debug device. The debug port is
+ in use now.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 65a06b4..aba2bf5 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -12,7 +12,7 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
xhci-hcd-y := xhci.o xhci-mem.o
xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
-xhci-hcd-y += xhci-trace.o
+xhci-hcd-y += xhci-trace.o xhci-sysfs.o
ifneq ($(CONFIG_USB_XHCI_MTK), )
xhci-hcd-y += xhci-mtk-sch.o
endif
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index 04ce6b1..c4b49c5 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -73,6 +73,11 @@
#define XHCI_HLC (1 << 19)
#define XHCI_BLC (1 << 20)
+/* Debug capability - section 7.6.8 */
+#define XHCI_DBC_DCCTRL0x20
+#define XHCI_DBC_DCCTRL_DCR(1 << 0)
+#define XHCI_DBC_DCCTRL_DCE(1 << 31)
+
/* command register values to disable interrupts and halt the HC */
/* start/stop HC execution - do not write unless HC is halted*/
#define XHCI_CMD_RUN (1 << 0)
diff --git a/drivers/usb/host/xhci-sysfs.c b/drivers/usb/host/xhci-sysfs.c
new file mode 100644
index 000..9feb727
--- /dev/null
+++ b/drivers/usb/host/xhci-sysfs.c
@@ -0,0 +1,65 @@
+/*
+ * sysfs interface for xHCI host controller driver
+ *
+ * Copyright (C) 2015 Intel Corp.
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+
+#include "xhci.h"
+
+#define GET_DBC_EXT_CAP_OFFSET(h) \
+ xhci_find_next_ext_cap(&(h)->cap_regs->hc_capbase, \
+ 0, XHCI_EXT_CAPS_DEBUG)
+
+static ssize_t debug_port_state_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int count = 0, offset;
+ char*state;
+ void __iomem*dbc_base;
+ u32 dcctrl_reg;
+ struct xhci_hcd *xhci = hcd_to_xhci(dev_get_drvdata(dev));
+
+ offset = GET_DBC_EXT_CAP_OFFSET(xhci);
+ if (!offset)
+ return 0;
+
+ dbc_base = (void __iomem *) xhci->cap_regs + offset;
+ dcctrl_reg = readl(dbc_base + XHCI_DBC_DCCTRL);
+
+ if (!(dcctrl_reg & XHCI_DBC_DCCTRL_DCE))
+ state = "disabled";
+ else
[PATCH v5 02/12] x86: fixmap: add permanent fixmap for xhci debug port
xHCI compatible USB3 host controller may provide debug capability
which enables low-level system debug over USB. In order to probing
this debug capability, Linux kernel needs to map and access the
mmio of the host controller during early boot.
This patch adds permenent fixmap pages in fixed_addresses table for
xHCI mmio access.
Signed-off-by: Lu Baolu
---
arch/x86/include/asm/fixmap.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index f80d700..fbf452f 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -82,6 +82,10 @@ enum fixed_addresses {
#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
#endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+ FIX_XDBC_BASE,
+ FIX_XDBC_END = FIX_XDBC_BASE + 15,
+#endif
#ifdef CONFIG_X86_LOCAL_APIC
FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */
#endif
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 00/12] usb: early: add support for early printk through USB3 debug port
Hi, This patch series adds support for early printk through USB3 debug port. USB3 debug port is described in xHCI specification as an optional extended capability. The first patch adds a file in sysfs, through which users can check whether the debug capability is supported by a specific host controller, and the hardware state. Patch 2 to 10 add the driver for xHCI debug capability. It interfaces with the register set and provides the required ops (read/write/control) to upper layers. Early printk is one consumer of these ops. The hooks for early printk are introduced in patch 9. This design is similar to what we have done in drivers/usb/early/ehci-dbgp.c. Patch 11 is a minor change to usb_debug module. This change is required to bind usb_debug with the USB3 debug device. Patch 12 is the design document and user guide. Change log: v1->v2: (1) Patch 1 re-implemented. "debugfs" has been replaced with sysfs. The scope reduced from all extended capabilities to debug port specific. (2) Patch 11 changed. Removed unnecessary .bulk_out_size setting. v2->v3: (1) Patch 11 got acked by Johan Hovold. v3->v4: (1) Patch 1 code refactored by using xhci_find_ext_cap_by_id() helper. (2) Patch 3 "bus hung state" changed to "port hung state" in commit message. (3) Patch 12 added verified platform information. v4->v5: (1) Patch 1 & 3 code refactored by using xhci_find_next_ext_cap() helper. (2) Patch 12 updated with more user guide information. (3) All patches rebased to the new usb-next branch which contains commit d5ddcdf(xhci: rework xhci extended capability list parsing functions). Lu Baolu (12): usb: xhci: add sysfs file for xHCI debug port x86: fixmap: add permanent fixmap for xhci debug port usb: xhci: dbc: probe and setup xhci debug capability usb: xhci: dbc: add support for Intel xHCI dbc quirk usb: xhci: dbc: add debug buffer usb: xhci: dbc: add bulk out and bulk in interfaces usb: xhci: dbc: handle dbc-configured exit usb: xhci: dbc: handle endpoint stall x86: early_printk: add USB3 debug port earlyprintk support usb: xhci: dbc: add handshake between debug target and host usb: serial: usb_debug: add support for dbc debug device usb: doc: add document for xHCI DbC driver .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 23 + Documentation/kernel-parameters.txt|1 + Documentation/usb/xhci-dbc.txt | 350 + MAINTAINERS|8 + arch/x86/Kconfig.debug | 12 + arch/x86/include/asm/fixmap.h |4 + arch/x86/kernel/early_printk.c |5 + drivers/usb/early/Makefile |1 + drivers/usb/early/xhci-dbc.c | 1394 drivers/usb/host/Makefile |2 +- drivers/usb/host/xhci-ext-caps.h |5 + drivers/usb/host/xhci-sysfs.c | 65 + drivers/usb/host/xhci.c|4 + drivers/usb/host/xhci.h|4 + drivers/usb/serial/usb_debug.c | 28 +- include/linux/usb/xhci-dbc.h | 224 16 files changed, 2126 insertions(+), 4 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd create mode 100644 Documentation/usb/xhci-dbc.txt create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/host/xhci-sysfs.c create mode 100644 include/linux/usb/xhci-dbc.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add support for monitoring Chrome OS firmware signals
Martyn,
On Tue, Dec 01, 2015 at 08:19:46PM +, Martyn Welch wrote:
> Select Chromebooks have gpio attached to signals used to cause the firmware
> to enter alternative modes of operation and/or control other device
[...]
> +
> +static int chromeos_firmware_probe(struct platform_device *pdev)
> +{
> + int err;
> + struct chromeos_firmware_data *gpios;
> +
> + gpios = devm_kmalloc(>dev, sizeof(gpios), GFP_KERNEL);
Should this be 'sizeof(*gpios)' so it allocates enough room for the
entire struct instead of just the pointer?
[...]
--
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] kexec: Set KEXEC_TYPE_CRASH before sanity_check_segment_list()
Hi Dave,
On 12/02/2015 at 01:47 PM, Dave Young wrote:
> Ccing Andrew since usually he monitors and picks up kexec patches.
>
> On 12/02/15 at 01:26pm, Xunlei Pang wrote:
>> sanity_check_segment_list() checks KEXEC_TYPE_CRASH flag to ensure
>> all the segments of the loaded crash kernel are winthin the kernel
>> crash resource limits, so set the flag beforehand.
> Looks good except a nitpick, see comments inline.
>
> Otherwise:
> Acked-by: Dave Young
>
>> Signed-off-by: Xunlei Pang
>> ---
>> kernel/kexec.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index d873b64..9624391 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -63,16 +63,19 @@ static int kimage_alloc_init(struct kimage **rimage,
>> unsigned long entry,
>> if (ret)
>> goto out_free_image;
>>
>> -ret = sanity_check_segment_list(image);
>> -if (ret)
>> -goto out_free_image;
>> -
>> - /* Enable the special crash kernel control page allocation policy. */
>> +/*
>> + * Enable the special crash kernel control page allocation policy,
>> + * and set the crash type flag.
> It is obvious it is setting the crash type flag, so no need to add extra
> comment.
>
>> + */
>> if (kexec_on_panic) {
> Like kexec_file.c, move /* Enable ... policy */ here sounds better.
Yea, this is better. Will do, thanks.
Regards,
Xunlei
>
>> image->control_page = crashk_res.start;
>> image->type = KEXEC_TYPE_CRASH;
>> }
>>
>> +ret = sanity_check_segment_list(image);
>> +if (ret)
>> +goto out_free_image;
>> +
>> /*
>> * Find a location for the control code buffer, and add it
>> * the vector of segments so that it's pages will also be
>> --
>> 2.5.0
>>
> Thanks
> Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 net 0/6] Marvell Armada XP/370/38X Neta fixes
2015-12-02 4:03 GMT+01:00 David Miller : > From: Marcin Wojtas > Date: Mon, 30 Nov 2015 13:27:40 +0100 > >> I'm sending v4 with corrected commit log of the last patch, in order >> to avoid possible conflicts between the branches as suggested by >> Gregory Clement. > > Series applied, thanks. Thanks, a lot, Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 03/17] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API
Hello,
There is a set of conversion routines ulong[]<->u32[] to address this
32/64-bit compat issue. Using a u32-based bitmap would require drivers
to handle the u32 bitmaps themselves, this might be confusing,
considering there is a standard bitmap api; and might be error-prone
as well. Plus there is %*pb[l] format that's very helpful for
debugging. That's why I preferred to handle the relative complexity of
u32 bitmaps with the CPP conditionals in the non-driver code that
handles the user/kernel interactions, and drivers can use the standard
bitmap api transparently.
I was currently moving/rewriting the u32/ulong conversion code to
bitmap.{c,h} as Ben Hutchings was suggesting, which should hopefully
make the code more digestible; and could possibly be used for other
user/kernel interfaces. How about I send an updated version with this
solution, and if it's still not right, I'll revisit with either u32[]
everywhere or fixed-size bitmap instead of variable-size as here? Or
maybe another option would be to implement a new u32[]
bitmap_u32.{c,h} api, possibly using a set of macro tricks to share
code with bitmap.{c,h}?
On Tue, Dec 1, 2015 at 7:13 PM, David Miller wrote:
> From: David Decotigny
> Date: Mon, 30 Nov 2015 14:05:41 -0800
>
>> This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by
>> the new get_ksettings/set_ksettings callbacks. This API provides
>> support for most legacy ethtool_cmd fields, adds support for larger
>> link mode masks (up to 4064 bits, variable length), and removes
>> ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt).
>
> Please do not define the mask using a non-fixed type. I know it makes
> it easier to use the various bitmap helper routines if you use 'long',
> but here it is clearly superior to use "u32" for the bitmap type and
> do the bit operations by hand if necessary.
>
> Otherwise you have to have all of this ulong size CPP conditional code
> which is incredibly ugly.
>
> Furthermore you have to use fixed sized types anyways so that we don't
> need compat code to deal with 32-bit userspace applications making
> these ethtool calls into a 64-bit kernel.
>
> THanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] power: Build power/avs when POWER_AVS is selected but POWER_SUPPLY is not
POWER_AVS can be selected from top-drivers menu and it does not depend on POWER_SUPPLY. However in such case (POWER_SUPPLY is not enabled) all objects will be skipped by make. Signed-off-by: Krzysztof Kozlowski --- drivers/Makefile | 1 + drivers/power/Makefile | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 0ebb49d0e57e..a3717decf3e7 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -106,6 +106,7 @@ obj-y += i2c/ media/ obj-$(CONFIG_PPS) += pps/ obj-$(CONFIG_PTP_1588_CLOCK) += ptp/ obj-$(CONFIG_W1) += w1/ +obj-$(CONFIG_POWER_AVS)+= power/avs/ obj-$(CONFIG_POWER_RESET) += power/reset/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON)+= hwmon/ diff --git a/drivers/power/Makefile b/drivers/power/Makefile index ac430b373f84..d6a1ddb20fec 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -65,7 +65,6 @@ obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_CHARGER_BQ24257) += bq24257_charger.o obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o -obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] power: Fix unmet dependency on POWER_SUPPLY by POWER_RESET by uncoupling them
Actually reset/power off handlers do not really depend on power supply. Move the power reset out of power supply block so it will appear in main drivers section. This fixes following build warning (encountered on ARM exynos defconfig when POWER_SUPPLY is disabled manually): warning: (ARCH_HISI && ARCH_INTEGRATOR && ARCH_EXYNOS && ARCH_VEXPRESS && REALVIEW_DT) selects POWER_RESET which has unmet direct dependencies (POWER_SUPPLY) warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON which has unmet direct dependencies (POWER_SUPPLY && POWER_RESET && OF) warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON_POWEROFF which has unmet direct dependencies (POWER_SUPPLY && POWER_RESET && OF) Reported-by: Pavel Fedin Signed-off-by: Krzysztof Kozlowski --- drivers/Makefile | 1 + drivers/power/Kconfig | 3 +-- drivers/power/Makefile | 1 - 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index 795d0ca714bf..0ebb49d0e57e 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -106,6 +106,7 @@ obj-y += i2c/ media/ obj-$(CONFIG_PPS) += pps/ obj-$(CONFIG_PTP_1588_CLOCK) += ptp/ obj-$(CONFIG_W1) += w1/ +obj-$(CONFIG_POWER_RESET) += power/reset/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON)+= hwmon/ obj-$(CONFIG_THERMAL) += thermal/ diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 2f944d742ed4..c031f901b497 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -509,8 +509,7 @@ config AXP20X_POWER This driver provides support for the power supply features of AXP20x PMIC. -source "drivers/power/reset/Kconfig" - endif # POWER_SUPPLY +source "drivers/power/reset/Kconfig" source "drivers/power/avs/Kconfig" diff --git a/drivers/power/Makefile b/drivers/power/Makefile index b656638f8b39..ac430b373f84 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -69,6 +69,5 @@ obj-$(CONFIG_POWER_AVS) += avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o -obj-$(CONFIG_POWER_RESET) += reset/ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] net: thunderx: Increase transmit queue length
>The driver should successfully recover from out of memory situations > and not stop RX/TX completely. This memory allocation is while interface bringup/initialization and not during packet I/O. >Don't put this off as not "related" to your patch, it is as this >introduces the behavior for this user, and you should fix it before >expecting me to apply this patch series. I would disagree on this, as this patch hasn't introduced any failure here, if this user has connected any device which asks for a bit large amount of coherent memory then i am sure he will see the same issue. And above i have suggested what could be done to not see this issue. But anyway for the time being I will resubmit the patch series without this patch, hope that would be okay. On Wed, Dec 2, 2015 at 1:00 AM, David Miller wrote: > From: Sunil Kovvuri > Date: Tue, 1 Dec 2015 22:00:49 +0530 > >> Increasing descriptor ring size will lead to more memory allocation. >> And what you are seeing is a memory alloc failure and doesn't seem >> to be due to this driver change. I mean it looks like the behavior >> will be same for other drivers as well. > > The driver should successfully recover from out of memory situations > and not stop RX/TX completely. > > There might be some other problem with your driver causing this. > > Don't put this off as not "related" to your patch, it is as this > introduces the behavior for this user, and you should fix it before > expecting me to apply this patch series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: dts: ls1021a: Add a TFT LCD panel.
On Wed, Nov 25, 2015 at 02:46:07PM +0800, Meng Yi wrote:
> Signed-off-by: Alison Wang
> Signed-off-by: Xiubo Li
> Signed-off-by: Jianwei Wang
> ---
> arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index fbb89d1..fad2e3b 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -105,6 +105,17 @@
> bitclock-master;
> };
> };
> +
> + panel: panel {
> + compatible = "nec,nl4827hc19-05b";
> + };
> +
This new line shouldn't be needed.
> +};
> +
> + {
> + fsl,panel = <>;
> + status = "okay";
> +
Ditto
I fixed them up and applied the both patches.
Shawn
> };
>
> {
> --
> 2.1.0.27.g96db324
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] kexec: Set KEXEC_TYPE_CRASH before sanity_check_segment_list()
Ccing Andrew since usually he monitors and picks up kexec patches.
On 12/02/15 at 01:26pm, Xunlei Pang wrote:
> sanity_check_segment_list() checks KEXEC_TYPE_CRASH flag to ensure
> all the segments of the loaded crash kernel are winthin the kernel
> crash resource limits, so set the flag beforehand.
Looks good except a nitpick, see comments inline.
Otherwise:
Acked-by: Dave Young
>
> Signed-off-by: Xunlei Pang
> ---
> kernel/kexec.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index d873b64..9624391 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -63,16 +63,19 @@ static int kimage_alloc_init(struct kimage **rimage,
> unsigned long entry,
> if (ret)
> goto out_free_image;
>
> - ret = sanity_check_segment_list(image);
> - if (ret)
> - goto out_free_image;
> -
> - /* Enable the special crash kernel control page allocation policy. */
> + /*
> + * Enable the special crash kernel control page allocation policy,
> + * and set the crash type flag.
It is obvious it is setting the crash type flag, so no need to add extra
comment.
> + */
> if (kexec_on_panic) {
Like kexec_file.c, move /* Enable ... policy */ here sounds better.
> image->control_page = crashk_res.start;
> image->type = KEXEC_TYPE_CRASH;
> }
>
> + ret = sanity_check_segment_list(image);
> + if (ret)
> + goto out_free_image;
> +
> /*
>* Find a location for the control code buffer, and add it
>* the vector of segments so that it's pages will also be
> --
> 2.5.0
>
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] clocksource: simplify ACPI code in arm_arch_timer.c
From: Fu Wei
The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
drivers/clocksource/arm_arch_timer.c | 48
1 file changed, 10 insertions(+), 38 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index e16fdad..87d6bae 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -806,60 +806,32 @@ static void __init arch_timer_mem_init(struct device_node
*np)
CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
arch_timer_mem_init);
-#ifdef CONFIG_ACPI
-static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
-{
- int trigger, polarity;
-
- if (!interrupt)
- return 0;
-
- trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
- : ACPI_LEVEL_SENSITIVE;
-
- polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
- : ACPI_ACTIVE_HIGH;
-
- return acpi_register_gsi(NULL, interrupt, trigger, polarity);
-}
-
+#ifdef CONFIG_ACPI_GTDT
/* Initialize per-processor generic timer */
static int __init arch_timer_acpi_init(struct acpi_table_header *table)
{
- struct acpi_table_gtdt *gtdt;
+ struct arch_timer_data data;
if (arch_timers_present & ARCH_CP15_TIMER) {
pr_warn("arch_timer: already initialized, skipping\n");
return -EINVAL;
}
- gtdt = container_of(table, struct acpi_table_gtdt, header);
-
arch_timers_present |= ARCH_CP15_TIMER;
- arch_timer_ppi[PHYS_SECURE_PPI] =
- map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
- gtdt->secure_el1_flags);
-
- arch_timer_ppi[PHYS_NONSECURE_PPI] =
- map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
- gtdt->non_secure_el1_flags);
-
- arch_timer_ppi[VIRT_PPI] =
- map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
- gtdt->virtual_timer_flags);
+ if (gtdt_arch_timer_data_init(table, ))
+ return -EINVAL;
- arch_timer_ppi[HYP_PPI] =
- map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
- gtdt->non_secure_el2_flags);
+ arch_timer_ppi[PHYS_SECURE_PPI] = data.phys_secure_ppi;
+ arch_timer_ppi[PHYS_NONSECURE_PPI] = data.phys_nonsecure_ppi;
+ arch_timer_ppi[VIRT_PPI] = data.virt_ppi;
+ arch_timer_ppi[HYP_PPI] = data.hyp_ppi;
+ arch_timer_c3stop = data.c3stop; /* Always-on capability */
/* Get the frequency from CNTFRQ */
arch_timer_detect_rate(NULL, NULL);
-
- /* Always-on capability */
- arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
-
arch_timer_init();
+
return 0;
}
CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] ACPI: add GTDT table parse driver into ACPI driver
From: Fu Wei
This driver adds support for parsing all kinds of timer in GTDT:
(1)arch timer: provide a kernel API to parse all the PPIs and
always-on info in GTDT and export them by arch_timer_data struct.
(2)memory-mapped timer: provide several kernel APIs to parse
GT Block Structure in GTDT, export those info by return value
and arch_timer_mem_data struct.
(3)SBSA Generic Watchdog: parse all info in SBSA Generic Watchdog
Structure in GTDT, and creating a platform device with that
information. This allows the operating system to obtain device
data from the resource of platform device.
The platform device named "sbsa-gwdt" can be used by the ARM SBSA
Generic Watchdog driver.
By this driver, we can simplify all the relevant drivers, and
separate all the ACPI GTDT knowledge from them.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
drivers/acpi/Kconfig | 9 +
drivers/acpi/Makefile| 1 +
drivers/acpi/gtdt.c | 367 +++
drivers/clocksource/arm_arch_timer.c | 2 -
include/clocksource/arm_arch_timer.h | 19 ++
include/linux/acpi.h | 17 ++
6 files changed, 413 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 25dbb76..9b23596 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -510,4 +510,13 @@ config XPOWER_PMIC_OPREGION
endif
+config ACPI_GTDT
+ bool "ACPI GTDT Support"
+ depends on ARM64
+ help
+ GTDT (Generic Timer Description Table) provides information
+ for per-processor timers and Platform (memory-mapped) timers
+ for ARM platforms. Select this option to provide information
+ needed for the timers init.
+
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..ac42e31 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -96,5 +96,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
+obj-$(CONFIG_ACPI_GTDT)+= gtdt.o
video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/gtdt.c b/drivers/acpi/gtdt.c
new file mode 100644
index 000..d15ea91
--- /dev/null
+++ b/drivers/acpi/gtdt.c
@@ -0,0 +1,367 @@
+/*
+ * ARM Specific GTDT table Support
+ *
+ * Copyright (C) 2015, Linaro Ltd.
+ * Author: Fu Wei
+ * Hanjun Guo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static u32 platform_timer_count __initdata;
+static int gtdt_timers_existence __initdata;
+
+/*
+ * Get some basic info from GTDT table, and init the global variables above
+ * for all timers initialization of Generic Timer.
+ * This function does some validation on GTDT table, and will be run only once.
+ */
+static void __init *platform_timer_info_init(struct acpi_table_header *table)
+{
+ void *gtdt_end, *platform_timer_struct, *platform_timer;
+ struct acpi_gtdt_header *header;
+ struct acpi_table_gtdt *gtdt;
+ u32 i;
+
+ gtdt = container_of(table, struct acpi_table_gtdt, header);
+ if (!gtdt) {
+ pr_err("GTDT: table pointer error, bad table.\n");
+ return NULL;
+ }
+ gtdt_end = (void *)table + table->length;
+ gtdt_timers_existence |= ARCH_CP15_TIMER;
+
+ if (table->revision < 2) {
+ pr_info("GTDT: Revision:%d doesn't support Platform Timers.\n",
+ table->revision);
+ return NULL;
+ }
+
+ platform_timer_count = gtdt->platform_timer_count;
+ if (!platform_timer_count) {
+ pr_info("GTDT: No Platform Timer structures.\n");
+ return NULL;
+ }
+
+ platform_timer_struct = (void *)gtdt + gtdt->platform_timer_offset;
+ if (platform_timer_struct < (void *)table +
+ sizeof(struct acpi_table_gtdt)) {
+ pr_err("GTDT: Platform Timer pointer error, bad table.\n");
+ return NULL;
+ }
+
+ platform_timer = platform_timer_struct;
+ for (i = 0; i < platform_timer_count; i++) {
+ if (platform_timer > gtdt_end) {
+ pr_warn("GTDT: subtable pointer overflows, bad
table\n");
+ platform_timer_count = i;
+ break;
+ }
+ header = (struct acpi_gtdt_header *)platform_timer;
+ if (header->type == ACPI_GTDT_TYPE_TIMER_BLOCK)
+ gtdt_timers_existence |= ARCH_MEM_TIMER;
+ else if (header->type ==
[PATCH v2 3/3] clocksource: add memory-mapped timer support in arm_arch_timer.c
From: Fu Wei
The patch add memory-mapped timer register support for arm_arch_timer driver
by using the information provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei
---
drivers/clocksource/arm_arch_timer.c | 136 +++
1 file changed, 136 insertions(+)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 87d6bae..3792fd6 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -666,6 +666,15 @@ arch_timer_needs_probing(int type, const struct
of_device_id *matches)
needs_probing = true;
of_node_put(dn);
+#ifdef CONFIG_ACPI_GTDT
+ /*
+* Check if we have timer in GTDT table
+*/
+ if (!acpi_disabled && gtdt_timer_is_available(type) &&
+ !(arch_timers_present & type))
+ needs_probing = true;
+#endif
+
return needs_probing;
}
@@ -835,4 +844,131 @@ static int __init arch_timer_acpi_init(struct
acpi_table_header *table)
return 0;
}
CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
+
+static u32 __init arch_timer_mem_cnttidr(struct acpi_gtdt_timer_block
*gt_block)
+{
+ phys_addr_t cntctlbase_phy;
+ void __iomem *cntctlbase;
+ u32 cnttidr;
+
+ cntctlbase_phy = (phys_addr_t)gtdt_gt_cntctlbase(gt_block);
+ if (!cntctlbase_phy) {
+ pr_err("arch_timer: Can't find CNTCTLBase.\n");
+ return 0;
+ }
+
+ /*
+* According to ARMv8 Architecture Reference Manual(ARM),
+* the size of CNTCTLBase frame of memory-mapped timer
+* is SZ_4K(Offset 0x000 – 0xFFF).
+*/
+ cntctlbase = ioremap(cntctlbase_phy, SZ_4K);
+ if (!cntctlbase) {
+ pr_err("arch_timer: Can't map CNTCTLBase\n");
+ return 0;
+ }
+ cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
+ iounmap(cntctlbase);
+
+ return cnttidr;
+}
+
+static int __init arch_timer_mem_best_frame(struct acpi_table_header *table,
+ struct arch_timer_mem_data *data)
+{
+ struct acpi_gtdt_timer_block *gt_block;
+ u32 frame_number, timer_count, cnttidr;
+ int i;
+
+ gt_block = gtdt_gt_block(table, 0);
+ if (!gt_block) {
+ pr_err("arch_timer: Can't find GT Block.\n");
+ return -EINVAL;
+ }
+
+ timer_count = gtdt_gt_timer_count(gt_block);
+ if (!timer_count) {
+ pr_err("arch_timer: Can't find GT frame number.\n");
+ return -EINVAL;
+ }
+
+ if (gtdt_gt_timer_data(gt_block, 0, false, data)) {
+ pr_err("arch_timer: Can't get first phy timer.\n");
+ return -EINVAL;
+ }
+
+ /*
+* Get Generic Timer Counter-timer Timer ID Register
+* for Virtual Timer Capability info
+*/
+ cnttidr = arch_timer_mem_cnttidr(gt_block);
+
+ /*
+* Try to find a virtual capable frame.
+* Otherwise fall back to the first physical capable frame.
+*/
+ for (i = 0; i < timer_count; i++) {
+ frame_number = gtdt_gt_frame_number(gt_block, i);
+ if (frame_number < ARCH_TIMER_MEM_MAX_FRAME &&
+ cnttidr & CNTTIDR_VIRT(frame_number)) {
+ if (!gtdt_gt_timer_data(gt_block, i, true, data)) {
+ arch_timer_mem_use_virtual = true;
+ return 0;
+ }
+ pr_warn("arch_timer: Can't get virt timer.\n");
+ }
+ }
+
+ return 0;
+}
+
+/* Initialize memory-mapped timer(wake-up timer) */
+static int __init arch_timer_mem_acpi_init(struct acpi_table_header *table)
+{
+ struct arch_timer_mem_data data;
+ void __iomem *cntbase;
+
+ if (arch_timers_present & ARCH_MEM_TIMER) {
+ pr_warn("arch_timer_mem: already initialized, skipping\n");
+ return -EINVAL;
+ }
+ arch_timers_present |= ARCH_MEM_TIMER;
+
+ if (arch_timer_mem_best_frame(table, ))
+ return -EINVAL;
+
+ /*
+* According to ARMv8 Architecture Reference Manual(ARM),
+* the size of CNTBaseN frames of memory-mapped timer
+* is SZ_4K(Offset 0x000 – 0xFFF).
+*/
+ cntbase = ioremap(data.cntbase_phy, SZ_4K);
+ if (!cntbase) {
+ pr_err("arch_timer: Can't map CntBase.\n");
+ return -EINVAL;
+ }
+ arch_counter_base = cntbase;
+
+ if (!data.irq) {
+ pr_err("arch_timer: Frame missing %s irq",
+ arch_timer_mem_use_virtual ? "virt" : "phys");
+ return -EINVAL;
+ }
+
+ /*
+* Because in a system that implements both Secure and
+* Non-secure states, CNTFRQ is only accessible in Secure state.
+* So we
[PATCH v2 0/3] ACPI, clocksource: add GTDT and ARM memory-mapped timer support
From: Fu Wei This patchset: (1)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (2)Simplify ACPI code for arch timer in arm_arch_timer.c (3)Add memory-mapped timer support in arm_arch_timer.c The SBSA Generic Watchdog info parsing support have been tested with a upstreaming SBSA Generic Watchdog driver: https://lkml.org/lkml/2015/10/27/466 on the following platforms: (1)ARM Foundation v8 model (2)AMD Seattle platform ARM memory-mapped timer support of this patchset has been tested on the following platforms: (1)ARM Foundation v8 model Changelog: v2: Rebase to latest kernel version(4.4-rc3). Fix the bug about the config problem, use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553 Fu Wei (3): ACPI: add GTDT table parse driver into ACPI driver clocksource: simplify ACPI code in arm_arch_timer.c clocksource: add memory-mapped timer support in arm_arch_timer.c drivers/acpi/Kconfig | 9 + drivers/acpi/Makefile| 1 + drivers/acpi/gtdt.c | 367 +++ drivers/clocksource/arm_arch_timer.c | 178 + include/clocksource/arm_arch_timer.h | 19 ++ include/linux/acpi.h | 17 ++ 6 files changed, 555 insertions(+), 36 deletions(-) create mode 100644 drivers/acpi/gtdt.c -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] perf tools: Introduce perf_thread for backtrace
Backtrace is a crucial info for debugging. And upcoming refcnt
tracking facility also wants to use it.
So instead of relying on glibc's backtrace_symbols[_fd] which misses
some (static) functions , use our own symbol searching mechanism. To
do that, add perf_thread global variable to keep its maps and symbols.
The backtrace output from TUI is changed like below. (I made a key
action to generate a segfault):
Before:
perf: Segmentation fault
backtrace
perf[0x544a8b]
/usr/lib/libc.so.6(+0x33680)[0x7fc46420b680]
perf[0x54041b]
perf(perf_evlist__tui_browse_hists+0x91)[0x5432e1]
perf(cmd_report+0x1d20)[0x43cb10]
perf[0x487073]
perf(main+0x62f)[0x42cb1f]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fc4641f8610]
perf(_start+0x29)[0x42cc39]
After:
perf: Segmentation fault
backtrace
perf_evsel__hists_browse(+0x43b) in perf [0x54066b]
perf_evlist__tui_browse_hists(+0x91) in perf [0x543531]
cmd_report(+0x1d20) in perf [0x43cb50]
run_builtin(+0x53) in perf [0x4870b3]
main(+0x634) in perf [0x42cb54]
__libc_start_main(+0xf0) in libc-2.22.so [0x7fea3577c610]
_start(+0x29) in perf [0x42cc79]
Cc: Frederic Weisbecker
Cc: Masami Hiramatsu
Signed-off-by: Namhyung Kim
---
v2) fallback to glibc's backtrace_symbols_fd() if failed
tools/perf/perf.c | 7 +-
tools/perf/ui/tui/setup.c | 31 ++--
tools/perf/util/util.c| 62 +++
tools/perf/util/util.h| 5
4 files changed, 102 insertions(+), 3 deletions(-)
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 4bee53c3f796..f77eb440b05c 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -604,6 +604,8 @@ int main(int argc, const char **argv)
*/
pthread__block_sigwinch();
+ create_perf_thread();
+
while (1) {
static int done_help;
int was_alias = run_argv(, );
@@ -615,7 +617,7 @@ int main(int argc, const char **argv)
fprintf(stderr, "Expansion of alias '%s' failed; "
"'%s' is not a perf-command\n",
cmd, argv[0]);
- goto out;
+ goto out_destroy;
}
if (!done_help) {
cmd = argv[0] = help_unknown_cmd(cmd);
@@ -626,6 +628,9 @@ int main(int argc, const char **argv)
fprintf(stderr, "Failed to run command '%s': %s\n",
cmd, strerror_r(errno, sbuf, sizeof(sbuf)));
+
+out_destroy:
+ destroy_perf_thread();
out:
return 1;
}
diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
index 7dfeba0a91f3..ba0ff1c4e6b7 100644
--- a/tools/perf/ui/tui/setup.c
+++ b/tools/perf/ui/tui/setup.c
@@ -13,6 +13,8 @@
#include "../libslang.h"
#include "../keysyms.h"
#include "tui.h"
+#include "../../util/symbol.h"
+#include "../../util/thread.h"
static volatile int ui__need_resize;
@@ -96,14 +98,39 @@ int ui__getch(int delay_secs)
static void ui__signal_backtrace(int sig)
{
void *stackdump[32];
- size_t size;
+ size_t size, i;
ui__exit(false);
psignal(sig, "perf");
printf(" backtrace \n");
size = backtrace(stackdump, ARRAY_SIZE(stackdump));
- backtrace_symbols_fd(stackdump, size, STDOUT_FILENO);
+ /* skip first two stack frame (for this function and signal stack) */
+ for (i = 2; i < size; i++) {
+ struct addr_location al = {
+ .sym = NULL,
+ };
+
+ /* valid callchain ends with 0 address */
+ if (stackdump[i] == NULL && i == (size - 1))
+ continue;
+
+ thread__find_addr_location(perf_thread, PERF_RECORD_MISC_USER,
+ MAP__FUNCTION, (long)stackdump[i],
);
+
+ if (!al.sym)
+ break;
+
+ printf("%s(+0x%"PRIx64") in %s [0x%lx]\n", al.sym->name,
+ map__map_ip(al.map, (u64)stackdump[i]) - al.sym->start,
+ al.map->dso->short_name, (unsigned long)stackdump[i]);
+ }
+
+ if (i != size) {
+ printf("\nperf backtrace seems broken, try again with glibc\n");
+ printf(" backtrace \n");
+ backtrace_symbols_fd(stackdump, size, STDOUT_FILENO);
+ }
exit(0);
}
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 75759aebc7b8..f1a26ea14053 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -16,6 +16,9 @@
#include
#include
#include "callchain.h"
+#include "machine.h"
+#include "thread.h"
+#include "thread_map.h"
struct callchain_param callchain_param = {
.mode = CHAIN_GRAPH_ABS,
@@ -696,3 +699,62 @@ fetch_kernel_version(unsigned int *puint, char *str,
*puint =
RE: [PATCH v2 1/3] serial: xuartps: Spliting the ISR into smaller routines.
> -Original Message-
> From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com]
> Sent: Friday, November 20, 2015 8:14 PM
> To: Nava kishore Manne
> Cc: jsl...@suse.com; Michal Simek; Anirudha Sarangi; linux-
> ser...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Nava kishore Manne
> Subject: Re: [PATCH v2 1/3] serial: xuartps: Spliting the ISR into smaller
> routines.
>
> On Fri, 2015-11-20 at 07:04PM +0530, Nava kishore Manne wrote:
> > Breaking the single big ISR that has both Rx and Tx in a single
> > function into smaller ones
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > Changes for v2:
> > --Splits up the ISR without any functional changes as suggested
> > by Peter Hurley
> >
> > drivers/tty/serial/xilinx_uartps.c | 247
> > -
> > 1 file changed, 135 insertions(+), 112 deletions(-)
> >
> > diff --git a/drivers/tty/serial/xilinx_uartps.c
> > b/drivers/tty/serial/xilinx_uartps.c
> > index 009e0db..2e1b0a8 100644
> > --- a/drivers/tty/serial/xilinx_uartps.c
> > +++ b/drivers/tty/serial/xilinx_uartps.c
> > @@ -172,6 +172,9 @@ struct cdns_uart { #define to_cdns_uart(_nb)
> > container_of(_nb, struct cdns_uart, \
> > clk_rate_change_nb);
> >
> > +static void cdns_uart_handle_tx(void *dev_id); static void
> > +cdns_uart_handle_rx(void *dev_id, unsigned int isrstatus);
>
> Can't you just move these functions here instead of adding prototypes here?
Initially I created the patch without adding prototypes but that patch was
unreadable
Due to the common lines of code b/w the functions so created the prototypes to
make the
Patch more readable as suggested by Peter.
Will add one more patch in the next series to get rid of the prototypes.
> Also, this is likely to conflict with
> https://lkml.org/lkml/2015/11/19/622
Yes I agree l see that no comments for your series of patches as of now...
Let me know whether I should wait until your patches got applied or you want me
to send the next version
Of my patches...
Regards,
Navakishore.
>
> Sören
[PATCH 1/2] kexec: Set KEXEC_TYPE_CRASH before sanity_check_segment_list()
sanity_check_segment_list() checks KEXEC_TYPE_CRASH flag to ensure
all the segments of the loaded crash kernel are winthin the kernel
crash resource limits, so set the flag beforehand.
Signed-off-by: Xunlei Pang
---
kernel/kexec.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index d873b64..9624391 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -63,16 +63,19 @@ static int kimage_alloc_init(struct kimage **rimage,
unsigned long entry,
if (ret)
goto out_free_image;
- ret = sanity_check_segment_list(image);
- if (ret)
- goto out_free_image;
-
-/* Enable the special crash kernel control page allocation policy. */
+ /*
+* Enable the special crash kernel control page allocation policy,
+* and set the crash type flag.
+*/
if (kexec_on_panic) {
image->control_page = crashk_res.start;
image->type = KEXEC_TYPE_CRASH;
}
+ ret = sanity_check_segment_list(image);
+ if (ret)
+ goto out_free_image;
+
/*
* Find a location for the control code buffer, and add it
* the vector of segments so that it's pages will also be
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: imx: clk-vf610: fix SAI clock tree
On Sat, Oct 17, 2015 at 09:05:20PM -0700, Stefan Agner wrote: > The Synchronous Audio Interface (SAI) instances are clocked by > independent clocks: The bus clock and the audio clock (as shown in > Figure 51-1 in the Vybrid Reference Manual). The clock gates in > CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access > tests to the registers with/without gating those clocks have shown. > The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1, > followed by a clock divider (SAIx_DIV). Currently, the parent of > the bus clock gates has been assigned to SAIx_DIV, which is not > involved in the bus clock path for the SAI instances (see chapter > 9.10.12, SAI clocking in the Vybrid Reference Manual). > > Fix this by define the parent clock of VF610_CLK_SAIx to be the bus > clock. > > If the driver needs the audio clock (when used in master mode), a > fixed device tree is required which assign the audio clock properly > to VF610_CLK_SAIx_DIV. > > Signed-off-by: Stefan Agner > --- > Hi all, > > Patch 1 and 2 are actual fixes and should be applied toghether. If > the clock tree changes are applied only, master mode won't work > anymore. With only the device tree changes applied, it probably > will still work but the VF610_CLK_SAIx_DIV will be enabled twice. > > Since Patch 3 also uses the fixed clock layout, it should be > applied after the clock tree fix too... Applied all 3, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address
On Thu, Nov 26, 2015 at 01:19:01PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 26, 2015 at 04:58:57PM +0100, Jiri Olsa escreveu:
> > On Thu, Nov 26, 2015 at 08:48:17AM -0700, David Ahern wrote:
> > > On 11/26/15 8:00 AM, Namhyung Kim wrote:
> > > >Hi David,
> > > >
> > > >On Thu, Nov 26, 2015 at 06:14:57AM -0700, David Ahern wrote:
> > > >>On 11/26/15 12:08 AM, Namhyung Kim wrote:
> > > >>>@@ -528,11 +529,16 @@ int main(int argc, const char **argv)
> > > >>> {
> > > >>> const char *cmd;
> > > >>> char sbuf[STRERR_BUFSIZE];
> > > >>>+ int min_addr;
> > > >>>
> > > >>> /* The page_size is placed in util object. */
> > > >>> page_size = sysconf(_SC_PAGE_SIZE);
> > > >>> cacheline_size = sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
> > > >>>
> > > >>>+ if (sysctl__read_int("vm/mmap_min_addr", _addr) < 0)
>
> Please put this in that symbol_conf kitchen sink :-)
>
> I'm unsure though if there would be a reason for having both the local
> min_addr and the one at perf record time, i.e. from perf.data :-\
Otherwise, it can use different value and can treat valid addresses as
invalid especially if the difference is huge.
Btw, I think it should be kernel to cut off these invalid callchains
in the first place, no?
>
> > > >>This assumes the record and analysis are done on the same system.
> > > >
> > > >Right. Maybe we can just use minimal size (or page size?) or save and
> > > >pass it through somewhere in the feature bit?
> > >
> > > no preference, but it should work with cross arch analysis as well (e.g.,
> > > record on arm/ppc and analysis on x86)
> >
> > I think we should store it in perf.data in features, but seems
> > like a waste to spend one bit just for this number.
> >
> > I remember commenting on new CPU related FEATURE data, that would contain
> > cpu specific data in extensible form like TAG,VALUE,TAG,VALUE..
> >
> > but I think the design changed or something, because I cannot find it in
> > now ;-)
> >
> > maybe we could add something like that
>
> Right, isn't that one part of the perf/stat patchkit?
I'll take a look. Jiri, could you give the link if you have it?
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian, On 02/12/15 08:56, Brian Norris wrote: > Hi Roger, > > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: >> On 30/11/15 21:54, Brian Norris wrote: >>> On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: On 26/10/15 23:23, Brian Norris wrote: > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >> This causes performance increase when using prefetch-irq mode. >> 30% increase in read, 17% increase in write in prefetch-irq mode. > > Have you pinpointed the exact causes for the performance increase, or > can you give an educated guess? AIUI, you're reducing the number of > interrupts needed for NAND prefetch mode, but you're also removing a bit > of abstraction and implementing hooks that look awfully like the > existing abstractions: > > + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > + u32 (*nand_irq_status)(void); > > That's not really a problem if there's a good reason for them (brcmnand > implements similar hooks because of quirks in the implementation of > interrupts across various BRCM SoCs, and it's not worth writing irqchip > drivers for those cases). I'm mainly curious for an explanation. I have both implementations with me. My guess is that the 20% performance gain is due to absence of irqchip/irqdomain translation code. I haven't investigated further though. >>> >>> I don't have much context for whether this makes sense or not. According >>> to your tests, you're getting ~800K interrupts over ~15 seconds. So >>> should you start noticing performance hits due to abstraction at 53K >>> interrupts per second? >> >> Yes, this was my understanding. > > Am I computing wrong, or is that a pretty insane rate of interrupts? I don't have the test board with me right now and so can't tell you for sure if the mtd tests took 15 seconds or more. I can try it out on a different board that I have and let you know for sure about how many interrupts we get per second. > >>> But anyway, I'm not sure that completely answered my question. My >>> question was whether you were removing the irqchip code solely for >>> performance reasons, or are there others? >> >> Yes. Only for performance reasons. > > Hmm, that's not my favorite answer. I'd prefer that more analysis was > done here before scrapping irqchip... I agree. We could retain the irqchip model till we have more satisfying analysis. > > But maybe that's not too bad. It seems like your patch set overall is a > net positive for disentangling some of arch/ and drivers/. :) > > I'll take another pass over your patch set, but if things are looking > better, how do you expect to merge this? There are significant portions > that touch at least 2 or 3 different subsystem trees, AFAICT. Tony could create an immutable branch with all the dts and memory changes. You could base the mtd changes on top of that? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 3/3] vhost_net: basic polling support
On 12/01/2015 10:43 PM, Michael S. Tsirkin wrote: > On Tue, Dec 01, 2015 at 01:17:49PM +0800, Jason Wang wrote: >> >> On 11/30/2015 06:44 PM, Michael S. Tsirkin wrote: >>> On Wed, Nov 25, 2015 at 03:11:29PM +0800, Jason Wang wrote: > This patch tries to poll for new added tx buffer or socket receive > queue for a while at the end of tx/rx processing. The maximum time > spent on polling were specified through a new kind of vring ioctl. > > Signed-off-by: Jason Wang >>> One further enhancement would be to actually poll >>> the underlying device. This should be reasonably >>> straight-forward with macvtap (especially in the >>> passthrough mode). >>> >>> >> Yes, it is. I have some patches to do this by replacing >> skb_queue_empty() with sk_busy_loop() but for tap. > We probably don't want to do this unconditionally, though. > >> Tests does not show >> any improvement but some regression. > Did you add code to call sk_mark_napi_id on tap then? > sk_busy_loop won't do anything useful without. Yes I did. Probably something wrong elsewhere. > >> Maybe it's better to test macvtap. > Same thing ... > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: use common return path
On Tue, Dec 01, 2015 at 06:57:24PM +0300, Dan Carpenter wrote: > On Tue, Dec 01, 2015 at 09:54:50AM -0500, Ben Romer wrote: > > On 12/01/2015 03:00 AM, Dan Carpenter wrote: > > >Doing One Err style error handling is often a mistake but it's ok here. > > > > Why is it okay here? I don't understand why this function would be > > any different than the other places where the code used a goto. > > What I meant was that I'm generally opposed to "common exit paths". > Mixing all the exit paths together often makes the code more complicated > and leads to errors. That makes sense from a common sense perspective By "common exit path" do you mean mixing up of success and error paths? regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: use common return path
On Tue, Dec 01, 2015 at 11:16:16AM -0500, Ben Romer wrote: > On 12/01/2015 10:57 AM, Dan Carpenter wrote: > >What I meant was that I'm generally opposed to "common exit paths". > >Mixing all the exit paths together often makes the code more complicated > >and leads to errors. That makes sense from a common sense perspective > >that doing many things is more difficult than doing one thing? Anyway > >it's easy enough to verify empirically that this style is bug prone. > > > >On the other hand there are times where all exit paths need to unlock or > >to free a variable and in those cases using a common exit path makes > >sense. Just don't standardize on "Every function should only have a > >single return". > > > > That works for me. Mainly my issue with it is that I've spent a lot > of time trying to eliminate "goto Away" code from the drivers, so > I'd rather not put any back if possible. But what is wrong with goto? Quoting from CodingStyle: "The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done. If there is no cleanup needed then just return directly." I am absolutely fine if you don't want it to be applied but just for knowing - It has multiple exits. In this case spin_unlock_irqrestore() is the common work. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/30/2015 10:17 PM, Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
>
+static int hidma_mgmt_probe(struct platform_device *pdev)
+{
+ struct hidma_mgmt_dev *mgmtdev;
+ struct resource *res;
+ void __iomem *virtaddr;
+ int irq;
+ int rc;
+ u32 val;
+
+ pm_runtime_set_autosuspend_delay(>dev, AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(>dev);
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
>>>
>>> at this time pm core will treat device as fully enabled and pm methods can
>>> be invoked, but you are not ready yet right. Typically these are done at the
>>> end of the probe unless you have a reason...
>>
>> I need it here because the clocks are declared as ACPI power resources.
>> The kernel is turning off all power resources during initialization. In
>> order for this code to touch the hardware, I need to call enable so that
>> clocks are enabled once again.
>
> The question is are you ready in your driver routines to be invoked by pm
> core?
>
I don't have any support for suspend and resume PM APIs. The only PM
interface I support is PM runtime. PM can turn on/off the clocks based
on the reference counts it maintains after get/set APIs. Since PM is
turning off the clocks during power up before my driver load, I do need
to grab this lock to re-enable it during HW initialization. Then, let PM
turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.
Is there any other interaction with the PM that I'm not aware of?
>>
>>>
+static ssize_t show_values(struct device *dev, struct device_attribute
*attr,
+ char *buf)
>>>
>>> Please fix the coding style here and other places as well.
>>
>> what's the problem here?
>>
>>> Specifically
>>> please read Chapter 2
>>>
>>
>> Why is checkpatch not complaining about any of the coding style issues?
>> I'm checking my code with checkpatch before submitting. Is there any
>> other tool that would catch this?
>
> So did you read the Chapter 2.. Quoting here
>
I did read the chapter 2. Maybe, my lack of native english speaking but
I don't get from this sentence that function parameters need to be
aligned to the opening paranthesis.
> Descendants are always substantially shorter than the parent
> and are placed substantially to the right. The same applies to function
> headers
> with a long argument list.
>
I ran Lindent and manually cleaned up the junk it introduced. The result
is this
static ssize_t show_values(struct device *dev, struct device_attribute
*attr,
char *buf)
> Your breaking lines is not placed substantially to the right..
> I do not think checkpatch is checking this..
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: use common return path
On Tue, Dec 01, 2015 at 07:05:19PM +0300, Dan Carpenter wrote: > A lot of review is judgement calls. I try very hard to be predictable > and machine like as possible. > > I have sometimes called you out for being too strict. I usually try to guess what Greg will do if he notices those multiple changes (for which you called me strict). But since staging is meant to be a learning ground for newbies, so my being strict will, most of the time, be for for them. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
On Tue, Dec 01, 2015 at 09:17:06PM +0100, Arnd Bergmann wrote: > On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote: > > On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote: > > > channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode > > > it will use a filter lookup table and retrieves the needed information > > > from > > > the dma_filter_map provided by the DMA drivers. > > > > That sounds right, for the third case would the arch, driver or someone else > > configure this? > > The typical case is for the configuration to be defined in arch or platform > code and passed down to the dmaengine driver. > > I just noticed that the text above (and probably the code too) should > be changed so we always fall back to this. There are cases where the > platform is booted with DT in principle, but the DMA engine does not > (yet) use DT and still wants to be converted. I think we can easily > handle that case by always trying this if the other methods fail. I agree that this makes sense, not just for DT cases but ACPI as well > > > > This legacy mode needs changes in platform code, in dmaengine drivers and > > > finally the dmaengine user drivers can be converted: > > > > Are you marking the current APIs as dericated in the end of this series > > I think we practically stopped marking things as deprecated in general. > Per Linus decree, whenever we want to get rid of something, we should > instead change all users in tree and then remove the API, expecting > driver maintainers to do something just because you marked it as deprecated > often doesn't work. Yes but while we do conversion we don't know if new users get added which use old API.. > > I can help out converting a few platforms, maybe one interface at a time. Great yes we all will have to chip in and start removing these, i will try doing few after new year Am sure Andy can chip in as well :) > This is what I see: > > arnd@wuerfel:~/arm-soc$ for i in dma_request_slave_channel_reason > dma_request_slave_channel dma_request_slave_channel_compat > dma_request_channel ; do echo `git grep -wl $i drivers/ | grep -v > drivers/dma | wc -l`\ $i ; done > 14 dma_request_slave_channel_reason > 27 dma_request_slave_channel > 25 dma_request_slave_channel_compat > 34 dma_request_channel > > I would probably leave the users of dma_request_channel() while converting > the others, as that is still used by all the platforms that don't use any DT > support. > > Changing dma_request_slave_channel_reason and dma_request_slave_channel is > trivial, we can probably use coccinelle for that, as it does not require > any platform changes. That brings us to the users of > dma_request_slave_channel_compat, which currently includes these files: > > $ git grep -wl dma_request_slave_channel_compat drivers/ata/pata_pxa.c > drivers/crypto/atmel-aes.c > drivers/crypto/atmel-sha.c > drivers/crypto/atmel-tdes.c > drivers/crypto/omap-aes.c > drivers/crypto/omap-des.c > drivers/crypto/omap-sham.c > drivers/media/platform/omap3isp/isphist.c > drivers/mmc/host/davinci_mmc.c > drivers/mmc/host/omap.c > drivers/mmc/host/omap_hsmmc.c > drivers/mmc/host/pxamci.c > drivers/mmc/host/s3cmci.c > drivers/mmc/host/tmio_mmc_dma.c > drivers/mtd/nand/pxa3xx_nand.c > drivers/net/ethernet/smsc/smc91x.c > drivers/net/irda/pxaficp_ir.c > drivers/spi/spi-omap2-mcspi.c > drivers/spi/spi-pxa2xx-dma.c > drivers/spi/spi-rspi.c > drivers/spi/spi-s3c64xx.c > drivers/spi/spi-sh-msiof.c > drivers/tty/serial/8250/8250_dma.c > drivers/tty/serial/samsung.c > drivers/tty/serial/sh-sci.c > include/linux/dmaengine.h > > In other words: arch/avr32 and arch/sh along with omap1, omap2, davinci, pxa, > and s3c > in terms of ARM platforms. > > Arnd -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: dts: enable GPIO-a for Broadcom NSP
This enables the GPIO-a support for Broadcom NSP SoC
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
---
arch/arm/boot/dts/bcm-nsp.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..16e3c2b 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -116,4 +116,16 @@
status = "disabled";
};
};
+
+ gpioa: gpio-a@1820 {
+ compatible = "brcm,nsp-gpio-a";
+ reg = <0x1820 0x70>,
+ <0x1803f1c4 0x1c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <32>;
+ interrupt-controller;
+ interrupts = ;
+ gpio-ranges = < 0 0 32>;
+ };
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] pinctrl: Broadcom NSP GPIO-a device tree bindings
Device tree binding documentation for Broadcom NSP GPIO-a driver
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
---
.../devicetree/bindings/pinctrl/brcm,nsp-gpio.txt | 80 ++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
new file mode 100644
index 000..bea4211
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
@@ -0,0 +1,80 @@
+Broadcom Northstar plus (NSP) GPIO/PINCONF Controller
+
+Required properties:
+- compatible:
+Must be "brcm,nsp-gpio-a"
+
+- reg:
+Should contain the register physical address and length for each of
+GPIO base, IO control registers
+
+- #gpio-cells:
+Must be two. The first cell is the GPIO pin number (within the
+controller's pin space) and the second cell is used for the following:
+bit[0]: polarity (0 for active high and 1 for active low)
+
+- gpio-controller:
+Specifies that the node is a GPIO controller
+
+- ngpios:
+Number of gpios supported (58x25 supports 32 and 58x23 supports 24)
+
+Optional properties:
+- interrupts:
+Interrupt ID
+
+- interrupt-controller:
+Specifies that the node is an interrupt controller
+
+- gpio-ranges:
+Specifies the mapping between gpio controller and pin-controllers pins.
+This requires 4 fields in cells defined as -
+1. Phandle of pin-controller.
+2. GPIO base pin offset.
+3 Pin-control base pin offset.
+4. number of gpio pins which are linearly mapped from pin base.
+
+Supported generic PINCONF properties in child nodes:
+- pins:
+The list of pins (within the controller's own pin space) that properties
+in the node apply to. Pin names are "gpio-"
+
+- bias-disable:
+Disable pin bias
+
+- bias-pull-up:
+Enable internal pull up resistor
+
+- bias-pull-down:
+Enable internal pull down resistor
+
+- drive-strength:
+Valid drive strength values include 2, 4, 6, 8, 10, 12, 14, 16 (mA)
+
+Example:
+
+ gpioa: gpio-a@1820 {
+ compatible = "brcm,nsp-gpio-a";
+ reg = <0x1820 0x100>,
+ <0x1803f1c4 0x1c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ ngpios = <32>;
+ gpio-ranges = < 0 0 31>;
+ interrupt-controller;
+ interrupts = ;
+
+ /* Hog a few default settings */
+ pinctrl-names = "default";
+ pinctrl-0 = <>;
+ led: led {
+ pins = "gpio-1";
+ bias-pull-up;
+ };
+
+ pwr: pwr {
+ gpio-hog;
+ gpios = <3 1>;
+ output-high;
+ };
+ };
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] pinctrl: nsp: add gpio-a driver support for Broadcom NSP SoC
This adds the initial support of the Broadcom NSP gpio-a driver.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy
---
drivers/pinctrl/bcm/Kconfig| 17 +
drivers/pinctrl/bcm/Makefile | 1 +
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 749 +
3 files changed, 767 insertions(+)
create mode 100644 drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index cd11d4d..1a8c837 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -54,3 +54,20 @@ config PINCTRL_CYGNUS_MUX
The Broadcom Cygnus IOMUX driver supports group based IOMUX
configuration, with the exception that certain individual pins
can be overrided to GPIO function
+
+config PINCTRL_NSP_GPIO
+ bool "Broadcom NSP GPIO (with PINCONF) driver"
+ depends on OF_GPIO && (ARCH_BCM_NSP || COMPILE_TEST)
+ select GPIOLIB_IRQCHIP
+ select PINCONF
+ select GENERIC_PINCONF
+ default ARCH_BCM_NSP
+ help
+ Say yes here to enable the Broadcom NSP GPIO driver.
+
+ The Broadcom Northstar Plus SoC ChipcommonA GPIO controller is
+ supported by this driver.
+
+ The ChipcommonA GPIO controller support basic PINCONF functions such
+ as bias pull up, pull down, and drive strength configurations, when
+ these pins are muxed to GPIO.
diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile
index 2b2f70e..2fb1ed8 100644
--- a/drivers/pinctrl/bcm/Makefile
+++ b/drivers/pinctrl/bcm/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
obj-$(CONFIG_PINCTRL_CYGNUS_GPIO) += pinctrl-cygnus-gpio.o
obj-$(CONFIG_PINCTRL_CYGNUS_MUX) += pinctrl-cygnus-mux.o
+obj-$(CONFIG_PINCTRL_NSP_GPIO) += pinctrl-nsp-gpio.o
diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
new file mode 100644
index 000..06b7aaf
--- /dev/null
+++ b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
@@ -0,0 +1,749 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This file contains the Broadcom Northstar Plus (NSP) GPIO driver that
+ * supports the chipCommonA GPIO controller. Basic PINCONF such as bias,
+ * pull up/down, slew and drive strength are also supported in this driver.
+ *
+ * Pins from the chipCommonA GPIO can be individually muxed to GPIO function,
+ * through the interaction with the NSP IOMUX controller.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../pinctrl-utils.h"
+
+#define NSP_CHIP_A_INT_STATUS 0x00
+#define NSP_CHIP_A_INT_MASK0x04
+#define NSP_GPIO_DATA_IN 0x40
+#define NSP_GPIO_DATA_OUT 0x44
+#define NSP_GPIO_OUT_EN0x48
+#define NSP_GPIO_INT_POLARITY 0x50
+#define NSP_GPIO_INT_MASK 0x54
+#define NSP_GPIO_EVENT 0x58
+#define NSP_GPIO_EVENT_INT_MASK0x5c
+#define NSP_GPIO_EVENT_INT_POLARITY0x64
+#define NSP_CHIP_A_GPIO_INT_BIT0x01
+
+/* I/O parameters offset for chipcommon A GPIO */
+#define NSP_GPIO_DRV_CTRL 0x00
+#define NSP_GPIO_HYSTERESIS_EN 0x10
+#define NSP_GPIO_SLEW_RATE_EN 0x14
+#define NSP_PULL_UP_EN 0x18
+#define NSP_PULL_DOWN_EN 0x1c
+#define GPIO_DRV_STRENGTH_BITS 0x03
+
+/*
+ * nsp GPIO core
+ *
+ * @dev: pointer to device
+ * @base: I/O register base for nsp GPIO controller
+ * @io_ctrl: I/O register base for PINCONF support outside the GPIO block
+ * @gc: GPIO chip
+ * @pctl: pointer to pinctrl_dev
+ * @pctldesc: pinctrl descriptor
+ * @irq_domain: pointer to irq domain
+ * @lock: lock to protect access to I/O registers
+ */
+struct nsp_gpio {
+ struct device *dev;
+ void __iomem *base;
+ void __iomem *io_ctrl;
+ struct gpio_chip gc;
+ struct pinctrl_dev *pctl;
+ struct pinctrl_desc pctldesc;
+ struct irq_domain *irq_domain;
+ spinlock_t lock;
+};
+
+enum base_type {
+ REG,
+ IO_CTRL
+};
+
+static inline struct nsp_gpio *to_nsp_gpio(struct gpio_chip *gc)
+{
+ return container_of(gc, struct nsp_gpio, gc);
+}
+
+/*
+ * Mapping from PINCONF pins to GPIO pins is 1-to-1
+ */
+static inline unsigned nsp_pin_to_gpio(unsigned pin)
+{
+
[PATCH 0/3] gpio support for Broadcom NSP
This patchset contains the gpio support for the Broadcom's Northstar Plus (NSP) SOC. The first patch provides the documentation details and the second patch contains driver details. The third patch contains the enable method. This patchset has been tested on NSP bcm958625HR board with pinctrl patch added. This patchset is based on v4.4.0-rc1 and is available from github repo: https://github.com/Broadcom/cygnus-linux.git branch: nsp-gpio-v1 Yendapally Reddy Dhananjaya Reddy (3): pinctrl: Broadcom NSP GPIO-a device tree bindings pinctrl: nsp: add gpio-a driver support for Broadcom NSP SoC ARM: dts: enable GPIO-a for Broadcom NSP .../devicetree/bindings/pinctrl/brcm,nsp-gpio.txt | 80 +++ arch/arm/boot/dts/bcm-nsp.dtsi | 12 + drivers/pinctrl/bcm/Kconfig| 17 + drivers/pinctrl/bcm/Makefile | 1 + drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 749 + 5 files changed, 859 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt create mode 100644 drivers/pinctrl/bcm/pinctrl-nsp-gpio.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI/AER: enable SERR# forwarding and role-based error reporting
On 12/1/2015 6:07 PM, Bjorn Helgaas wrote:
> On Tue, Dec 01, 2015 at 03:08:48PM -0500, Sinan Kaya wrote:
>> On 12/1/2015 2:21 PM, Christopher Covington wrote:
>>> On 12/01/2015 01:51 PM, Bjorn Helgaas wrote:
[+cc Taku]
>>>
>>> It looks to me like Bjorn intended to add Taku to the distribution list,
>>> but accidentally left him off, so I'm adding him to the To field in this
>>> reply.
>>>
>>> Regards,
>>> Christopher Covington
>>>
Hi Sinan,
On Mon, Oct 26, 2015 at 05:25:02PM -0400, Sinan Kaya wrote:
> A PCIe card behind a PCIe switch is unable to report its errors
> when SERR# forwarding is not enabled on the PCIe switch's
> secondary interface. This is required by the PCIe spec.
I think enabling SERR# forwarding is only "required by the spec" in
the sense that bridges do not forward errors upstream unless the
SERR# Enable bit is set, right? So I would say this is just an
ordinary enable bit in the bridge, not a special spec requirement.
>>
>> Bottom line is that AER errors won't be forwarded if this bit is not set.
>
> Right. So it's required by the spec if you want error forwarding, in
> the same way the spec requires the Hot-Plug Interrupt Enable bit to be
> set if you want interrupts for hot-plug events.
>
The Linux AER code doesn't poll for errors; it assumes errors will be
propagated upstream to the Root Port, where they will cause an
interrupt, so I agree that it doesn't really make sense to enable AER
for a device unless we also enable SERR# forwarding in all the bridges
leading to it.
I assume this patch fixes a problem, e.g., errors reported by a device
are not forwarded upstream, so AER never logs them, and with this
patch, AER does log them?
>>
>> Correct. I'm not observing the AER errors without this patch. After this
>> patch, I'm seeing the AER errors coming from the endpoints.
>
> Thanks for confirming this.
>
I suppose we didn't notice this before
because some firmware enables SERR# forwarding for us, but yours
doesn't?
>>
>> Possible..., I could have done this in the UEFI BIOS but I'm also
>> worried about hotplug case. That's why, I chose to submit a patch for
>> the kernel.
>
> Thanks for confirming that your firmware does not enable SERR#
> forwarding. That explains why this patch makes a difference for you.
> There must be firmware that does enable SERR# forwarding; otherwise
> AER would never have worked for anybody.
>
> I think it makes sense for Linux to make sure SERR# forwarding is
> enabled when enabling AER. We shouldn't rely on firmware setting it
> for us.
>
>> For instance, what happens after hotplug insertion. Will anybody set
>> these bits? We need some kernel support for some PCIe features to
>> reconfigure the hardware.
>
> ACPI systems that support hotplug may supply _HPP or _HPX methods. If
> _HPP or _HPX indicates that SERR# forwarding should be enabled, Linux
> does enable it for hot-added devices (and I think we now do it for all
> devices at boot, too). That would explain how this could work on ACPI
> systems today.
Are we sure about this? The name of the field in HPP is "Enable SERR".
Will this also enable SERR# forwarding?
I do have _HPP in ACPI with SERR enabled but I do not have HPX. I rely
on the hardware defaults for which errors to be enabled and masked etc.
So, I don't need HPX.
>
> But obviously AER should work even if we don't have ACPI, so we need
> something like this patch.
>
> This patch
> enables SERR# forwarding and also cleans out compatibility
> mode so that AER reporting is enabled.
>
> Tested with PEX8749-CA RDK.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/pci/pcie/aer/aerdrv_core.c | 56
> +-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
> b/drivers/pci/pcie/aer/aerdrv_core.c
> index 9803e3d..acd22d7 100644
> --- a/drivers/pci/pcie/aer/aerdrv_core.c
> +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> @@ -37,21 +37,75 @@ module_param(nosourceid, bool, 0);
>
> int pci_enable_pcie_error_reporting(struct pci_dev *dev)
> {
> + u8 header_type;
> + int pos;
> +
> if (pcie_aer_get_firmware_first(dev))
> return -EIO;
>
> - if (!pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR))
> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR);
> + if (!pos)
> return -EIO;
>
> + pci_read_config_byte(dev, PCI_HEADER_TYPE, _type);
> +
> + /* needs to be a bridge/switch */
> + if (header_type == PCI_HEADER_TYPE_BRIDGE) {
> + u32 status;
> + u16 control;
> +
> + /*
> + * A switch will not forward ERR_ messages coming from an
> + * endpoint if SERR# forwarding is not enabled.
> + * AER
Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices
On Tue, Dec 01, 2015 at 09:20:28PM +0100, Arnd Bergmann wrote: > On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote: > > On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote: > > > Add support for providing device to filter_fn mapping so client drivers > > > can switch to use the dma_request_chan() API. > > > > Any reason why we dont want to go with DT based only for edma here? > > I think the OMAP2 based platforms using edma are all DT-only, but mach-davinci > would need a lot of work for that. Okay sound fine then -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/61] PCI: Resource allocation cleanup for v4.4
On Tue, Dec 1, 2015 at 1:23 PM, Khalid Aziz wrote: > The device does work with this patch. Good. > Doesn't this warning mean BAR6 > resources could not be reserved which means the device driver may not be > able to get the BAR6 resource at some point if another device grabs the > unreserved resource? Current sparc pci only have checking, does not have assign unassigned bar from firmware. because firmware does not assign resource to that BAR6, the driver may not need that bar at all. > > David M had pointed out an issue with how OF driver uses the same address > range for all ROMs enabling them only one at a time. That seems to be in > play here in the issue I am seeing. Does this patch series need to address > this? That trick may have problem when we have devices under bridge. as bridge window need to be setup at first. If the driver really need to use that trick, it should borrow from BAR0 (MEM) instead. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v2] ath6kl: Use vmalloc to allocate ar->fw for api1 method
Since commit 8437754c8335 ("ath6kl: Use vmalloc instead of kmalloc for
fw") ar->fw is expected to be pointing to memory allocated by vmalloc.
If the api1 method (via ath6kl_fetch_fw_api1) is used to allocate memory
for ar->fw, then kmemdup is used. This patch checks if the firmware being
loaded is the 'fw' image, then use vmalloc, otherwise use kmalloc.
Signed-off-by: Brent Taylor
---
v2: Fix commit message and code formatting (use tab instaed of spaces)
drivers/net/wireless/ath/ath6kl/init.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c
b/drivers/net/wireless/ath/ath6kl/init.c
index 6ae0734..4f16bd8 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -673,10 +673,15 @@ static int ath6kl_get_fw(struct ath6kl *ar, const char
*filename,
return ret;
*fw_len = fw_entry->size;
- *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
+ if (>fw == fw)
+ *fw = vmalloc(fw_entry->size);
+ else
+ *fw = kmalloc(fw_entry->size, GFP_KERNEL);
if (*fw == NULL)
ret = -ENOMEM;
+ else
+ memcpy(*fw, fw_entry->data, fw_entry->size);
release_firmware(fw_entry);
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Fix mmap MAP_POPULATE for DAX pmd mapping
On Tue, Dec 1, 2015 at 6:19 PM, Toshi Kani wrote:
> On Mon, 2015-11-30 at 14:08 -0800, Dan Williams wrote:
>> On Mon, Nov 23, 2015 at 12:04 PM, Toshi Kani wrote:
>> > The following oops was observed when mmap() with MAP_POPULATE
>> > pre-faulted pmd mappings of a DAX file. follow_trans_huge_pmd()
>> > expects that a target address has a struct page.
>> >
>> > BUG: unable to handle kernel paging request at ea001222
>> > follow_trans_huge_pmd+0xba/0x390
>> > follow_page_mask+0x33d/0x420
>> > __get_user_pages+0xdc/0x800
>> > populate_vma_page_range+0xb5/0xe0
>> > __mm_populate+0xc5/0x150
>> > vm_mmap_pgoff+0xd5/0xe0
>> > SyS_mmap_pgoff+0x1c1/0x290
>> > SyS_mmap+0x1b/0x30
>> >
>> > Fix it by making the PMD pre-fault handling consistent with PTE.
>> > After pre-faulted in faultin_page(), follow_page_mask() calls
>> > follow_trans_huge_pmd(), which is changed to call follow_pfn_pmd()
>> > for VM_PFNMAP or VM_MIXEDMAP. follow_pfn_pmd() handles FOLL_TOUCH
>> > and returns with -EEXIST.
>> >
>> > Reported-by: Mauricio Porto
>> > Signed-off-by: Toshi Kani
>> > Cc: Andrew Morton
>> > Cc: Kirill A. Shutemov
>> > Cc: Matthew Wilcox
>> > Cc: Dan Williams
>> > Cc: Ross Zwisler
>> > ---
>>
>> Hey Toshi,
>>
>> I ended up fixing this differently with follow_pmd_devmap() introduced
>> in this series:
>>
>> https://lists.01.org/pipermail/linux-nvdimm/2015-November/003033.html
>>
>> Does the latest libnvdimm-pending branch [1] pass your test case?
>
> Hi Dan,
>
> I ran several test cases, and they all hit the case "pfn not in memmap" in
> __dax_pmd_fault() during mmap(MAP_POPULATE). Looking at the dax.pfn, PFN_DEV
> is
> set but PFN_MAP is not. I have not looked into why, but I thought I let you
> know first. I've also seen the test thread got hung up at the end sometime.
That PFN_MAP flag will not be set by default for NFIT-defined
persistent memory. See pmem_should_map_pages() for pmem namespaces
that will have it set by default, currently only e820 type-12 memory
ranges.
NFIT-defined persistent memory can have a memmap array dynamically
allocated by setting up a pfn device (similar to setting up a btt).
We don't map it by default because the NFIT may describe hundreds of
gigabytes of persistent and the overhead of the memmap may be too
large to locate the memmap in ram.
I have a pending patch in libnvdimm-pending that allows the capacity
for the memmap to come from pmem instead of ram:
https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/commit/?h=libnvdimm-pending=3117a24e07fe
> I also noticed that reason is not set in the case below.
>
> if (length < PMD_SIZE
> || (pfn_t_to_pfn(dax.pfn) & PG_PMD_COLOUR)) {
> dax_unmap_atomic(bdev, );
> goto fallback;
> }
Thanks, I'll fix that up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: pci_quirks: fix memory leak, by adding iounmap
On 2 December 2015 at 04:05, Greg KH wrote: > On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote: >> added iounmap inorder to free memory mapped to base before returning >> >> Signed-off-by: Saurabh Sengar >> --- >> drivers/usb/host/pci-quirks.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c >> index f940056..332f687 100644 >> --- a/drivers/usb/host/pci-quirks.c >> +++ b/drivers/usb/host/pci-quirks.c >> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev) >> /* We're reading garbage from the controller */ >> dev_warn(>dev, >>"xHCI controller failing to respond"); >> - return; >> + goto iounmap; >> } >> >> if (!ext_cap_offset) >> @@ -1061,7 +1061,7 @@ hc_init: >>"xHCI HW did not halt within %d usec status = 0x%x\n", >>XHCI_MAX_HALT_USEC, val); >> } >> - >> +iounmap: >> iounmap(base); >> } >> > > Does not apply to the tree :( This patch applies fine on top of "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". Just now only I have re-verified. Am I expected to send this patch on top of some other git tree/branch ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpuset: return -EINVAL for legacy non-subset child creation attempt
On Wed, 2015-12-02 at 09:20 +0800, Zefan Li wrote: > On 2015/12/1 23:22, Mike Galbraith wrote: > > A legacy hierarchy child set that is not a subset of its parent is not > > a permissions issue, it's an invalid configuration. Return -EINVAL. > > > > It's sometimes arguable which errno should be used. In this case I don't > see why we can't use EACCES. It's even documented in man page. > > EACCES Attempted to add, using write(2), a CPU or memory node to > a >cpuset, when that CPU or memory node was not already in its > par- >ent. > > Let's see another example. In mmap manual: > > EACCES A file descriptor refers to a non-regular file. > > We can argue fd of a non-regular file is an invalid configuration, but > here we return EACCES. Ok, works for me (official -ENOPE -> gripee), thanks. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Hi Roger, On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: > On 30/11/15 21:54, Brian Norris wrote: > > On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote: > >> On 26/10/15 23:23, Brian Norris wrote: > >>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ > with the omap2-nand driver and handle NAND IRQ events in the NAND driver. > This causes performance increase when using prefetch-irq mode. > 30% increase in read, 17% increase in write in prefetch-irq mode. > >>> > >>> Have you pinpointed the exact causes for the performance increase, or > >>> can you give an educated guess? AIUI, you're reducing the number of > >>> interrupts needed for NAND prefetch mode, but you're also removing a bit > >>> of abstraction and implementing hooks that look awfully like the > >>> existing abstractions: > >>> > >>> + int (*nand_irq_enable)(enum gpmc_nand_irq irq); > >>> + int (*nand_irq_disable)(enum gpmc_nand_irq irq); > >>> + void (*nand_irq_clear)(enum gpmc_nand_irq irq); > >>> + u32 (*nand_irq_status)(void); > >>> > >>> That's not really a problem if there's a good reason for them (brcmnand > >>> implements similar hooks because of quirks in the implementation of > >>> interrupts across various BRCM SoCs, and it's not worth writing irqchip > >>> drivers for those cases). I'm mainly curious for an explanation. > >> > >> I have both implementations with me. My guess is that the 20% performance > >> gain is due to absence of irqchip/irqdomain translation code. > >> I haven't investigated further though. > > > > I don't have much context for whether this makes sense or not. According > > to your tests, you're getting ~800K interrupts over ~15 seconds. So > > should you start noticing performance hits due to abstraction at 53K > > interrupts per second? > > Yes, this was my understanding. Am I computing wrong, or is that a pretty insane rate of interrupts? > > But anyway, I'm not sure that completely answered my question. My > > question was whether you were removing the irqchip code solely for > > performance reasons, or are there others? > > Yes. Only for performance reasons. Hmm, that's not my favorite answer. I'd prefer that more analysis was done here before scrapping irqchip... But maybe that's not too bad. It seems like your patch set overall is a net positive for disentangling some of arch/ and drivers/. I'll take another pass over your patch set, but if things are looking better, how do you expect to merge this? There are significant portions that touch at least 2 or 3 different subsystem trees, AFAICT. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [radeon r100] when ring test fails, provide users with option to test
On 01.12.2015 19:01, Pavel Machek wrote: > On Mon 2015-11-30 09:39:54, Christian König wrote: >> On 29.11.2015 23:22, Pavel Machek wrote: >>> On Sun 2015-11-29 20:48:53, Christian König wrote: On 28.11.2015 21:58, Pavel Machek wrote: > Ring test failure is often caused by too high agpmode. Tell the user > what to try. > > Signed-off-by: Pavel Machek NAK, the ring test can fail for any number of reasons and the agpmode is actually rather unlikely to be the cause. >>> Well, when I asked on the list "why this is happened" I got "umm, >>> noone knows" response that was not exactly helpful. And then someone >>> told me about agpmode. >>> >>> If you know about the reasons it can fail, could you list them near >>> the DRM_ERROR, at least as a comment? >> >> Well as I said, that could be any number of reasons. Some of them even >> completely unrelated to the driver itself. >> >> E.g. BIOS setting, faulty hardware, problems with the writeback etc... There >> is really not a list you could give here. >> >> Lowering the agpmode usually helps more to prevent random corruptions and >> problems under load. > > Take a look at > > http://www.gossamer-threads.com/lists/linux/kernel/2197183 > > . I had a problem, you did not know how to debug it, but it already > happened to pebolle at tiscali ... and yes, it was agpmode. That > problem is clearly more common then you realize... So this should go > in. I agree with Christian, but at the very least, agpmode must not be mentioned if AGP isn't being used in the first place, i.e. either the GPU isn't AGP or is being forced to PCI(e) mode. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 03/17] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API
From: David Decotigny Date: Mon, 30 Nov 2015 14:05:41 -0800 > This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by > the new get_ksettings/set_ksettings callbacks. This API provides > support for most legacy ethtool_cmd fields, adds support for larger > link mode masks (up to 4064 bits, variable length), and removes > ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt). Please do not define the mask using a non-fixed type. I know it makes it easier to use the various bitmap helper routines if you use 'long', but here it is clearly superior to use "u32" for the bitmap type and do the bit operations by hand if necessary. Otherwise you have to have all of this ulong size CPP conditional code which is incredibly ugly. Furthermore you have to use fixed sized types anyways so that we don't need compat code to deal with 32-bit userspace applications making these ethtool calls into a 64-bit kernel. THanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] Staging: wilc1000: Fix build break due to undeclared *wilc and implicit declaration of init_irq
On Mon, Nov 9, 2015 at 3:53 PM, Sudip Mukherjee wrote: > On Mon, Nov 09, 2015 at 03:43:38PM +0530, punit vara wrote: >> On Mon, Nov 9, 2015 at 3:31 PM, glen lee wrote: >> > >> > >> > On 2015년 11월 09일 18:05, punit vara wrote: >> >> >> >> On Mon, Nov 9, 2015 at 2:25 PM, glen lee wrote: >> >>> >> >>> On 2015년 11월 09일 17:18, Dan Carpenter wrote: >> >> On Mon, Nov 09, 2015 at 05:02:48PM +0900, glen lee wrote: >> > >> >> make ./drivers/staging/wilc1000/this working fine for me >> >> but >> >> make ./drivers/staging/wilc1000/linux_wlan.o is creates error. > > I am also not getting build failure. Can you please post your .config file. > > regards > sudip I have attached .config file . and please tell me should I focus on this patch or not . Because build is still broken.For temporary this patch can be useful to fix the build .Later on as per requirement Glen can change the code . config.gz Description: GNU Zip compressed data
Re: [PATCH v4 net 0/6] Marvell Armada XP/370/38X Neta fixes
From: Marcin Wojtas Date: Mon, 30 Nov 2015 13:27:40 +0100 > I'm sending v4 with corrected commit log of the last patch, in order > to avoid possible conflicts between the branches as suggested by > Gregory Clement. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V3 00/17] hv_netvsc: Eliminate the additional head room
From: "K. Y. Srinivasan" Date: Tue, 1 Dec 2015 16:42:58 -0800 > In an attempt to avoid having to allocate memory on the send path, the netvsc > driver was requesting additional head room so that both rndis header and the > netvsc packet (the state that had to persist) could be placed in the skb. > Since the amount of head room requested was exceeding the default head room > as set in LL_MAX_HEADER, we were forcing a reallocation of skb. > > With this patch-set, I have reduced the size of the netvsc packet to less > than 20 bytes and with this reduction we don't need to ask for any additional > headroom. We place the rndis header in the skb head room and we place the > netvsc packet in control buffer area in the skb. > > V2: - Addressed review comments: > - Eliminated more fields from netvsc packet structure. > > V3: - Fixed a typo in patch: hv_netvsc: Don't ask for additional head room > in the skb. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] i2c: mediatek: fix i2c multi transfer issue in high speed mode
On Sat, 2015-11-14 at 22:38 +0800, Daniel Kurtz wrote:
> On Mon, Nov 9, 2015 at 1:43 PM, Liguo Zhang wrote:
> > For platform with auto restart support, when doing i2c multi transfer
> > in high speed, for example, doing write-then-read transfer, the master
> > code will occupy the first transfer, and the second transfer will be
> > the read transfer, the write transfer will be discarded. So we should
> > first send the master code, and then start i2c multi transfer.
> >
> > Signed-off-by: Liguo Zhang
> > Reviewed-by: Eddie Huang
> > ---
> > drivers/i2c/busses/i2c-mt65xx.c | 45
> > +
> > 1 file changed, 45 insertions(+)
> >
> > diff --git a/drivers/i2c/busses/i2c-mt65xx.c
> > b/drivers/i2c/busses/i2c-mt65xx.c
> > index dc4aac6..249df86 100644
> > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > @@ -53,6 +53,8 @@
> > #define I2C_FS_TIME_INIT_VALUE 0x1303
> > #define I2C_WRRD_TRANAC_VALUE 0x0002
> > #define I2C_RD_TRANAC_VALUE0x0001
> > +#define I2C_TRAN_DEFAULT_VALUE 0x0001
> > +#define I2C_TRANAC_DEFAULT_VALUE 0x0001
>
> "TRAN" and "TRANAC" are not good names; this should be "TRANSFER_LEN"
> and "TRANSAC", based on the names of the registers to which you write
> these constants.
>
> Furthermore, these are not "default" values, they are the transfer
> length and number of transactions for sending the "master code", so:
>
> #define I2C_TRANSFER_LEN_MASTER_CODE 0x0001
> #define I2C_TRANSAC_LEN_MASTER_CODE 0x0001
>
> Similarly, I think the "TRANAC" in I2C_WRRD_TRANAC_VALUE and
> I2C_RD_TRANAC_VALUE should also be TRANSAC.
>
Yes, I will follow your advice.
> >
> > #define I2C_DMA_CON_TX 0x
> > #define I2C_DMA_CON_RX 0x0001
> > @@ -365,6 +367,43 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c,
> > unsigned int parent_clk,
> > return 0;
> > }
> >
> > +static int mtk_i2c_send_master_code(struct mtk_i2c *i2c)
> > +{
> > + int ret = 0;
> > +
> > + reinit_completion(>msg_complete);
> > +
> > + writew(I2C_CONTROL_RS | I2C_CONTROL_ACKERR_DET_EN |
> > + I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN,
> > + i2c->base + OFFSET_CONTROL);
> > +
> > + /* Clear interrupt status */
> > + writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP | I2C_HS_NACKERR |
> > I2C_ACKERR,
> > + i2c->base + OFFSET_INTR_STAT);
> > +
> > + /* Enable interrupt */
> > + writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP, i2c->base +
> > + OFFSET_INTR_MASK);
> > +
> > + writew(I2C_TRAN_DEFAULT_VALUE, i2c->base + OFFSET_TRANSFER_LEN);
> > + writew(I2C_TRANAC_DEFAULT_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
> > +
> > + writew(I2C_TRANSAC_START | I2C_RS_MUL_CNFG, i2c->base +
> > OFFSET_START);
> > +
> > + ret = wait_for_completion_timeout(>msg_complete,
> > + i2c->adap.timeout);
>
> How does the hardware know that this transaction should be a "master code"?
> Do you have to tell the hardware what value ('1XXX') to use as the
> master code?
When we set i2c speed > 400K , the hardware will send master code. We
have a register to configure master code，and usually we use the default
value "1000".
> The Master Code must be sent at <= 400 kHz, not the target clock. How
> does the hardware know what rate to use?
The i2c speed is defined in dts, and we will set the i2c speed in i2c
register, so HW will know the rate to use.
> When sending the master code, arbitration is supposed to occur, such
> that only one winning master can proceed with the following high speed
> transaction.
> Where do you check that you won this arbitration?
> If this is not implemented, adding a "TODO" would be helpful.
>
Our i2c driver now only support one master.
> > +
> > + completion_done(>msg_complete);
>
> This completion_done() is only useful if you check the return value.
> You should check it too, since we should only check for timeout if the
> message hasn't completed.
>
I will delete the completion_done() function.
> > +
> > + if (ret == 0) {
> > + dev_dbg(i2c->dev, "send master code timeout.\n");
> > + mtk_i2c_init_hw(i2c);
> > + return -ETIMEDOUT;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
> >int num, int left_num)
> > {
> > @@ -539,6 +578,12 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
> > }
> > }
> >
> > + if (i2c->auto_restart && i2c->speed_hz > 40) {
>
> Don't we need to send the master code for *every* HS transaction, not
> just "auto_restart"?
>
When we don't use auto restart, we also need to send the master code,
the master code is sent by HW automatically.
I am improving the master code
Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI
On Fri, 2015-11-27 at 12:09 +0100, Petr Mladek wrote:
> printk() takes some locks and could not be used a safe way in NMI
> context.
>
> The chance of a deadlock is real especially when printing
> stacks from all CPUs. This particular problem has been addressed
> on x86 by the commit a9edc8809328 ("x86/nmi: Perform a safe NMI stack
> trace on all CPUs").
...
> diff --git a/kernel/printk/nmi.c b/kernel/printk/nmi.c
> new file mode 100644
> index ..3989e13a0021
> --- /dev/null
> +++ b/kernel/printk/nmi.c
> @@ -0,0 +1,200 @@
...
> +
> +struct nmi_seq_buf {
> + atomic_tlen;/* length of written data */
> + struct irq_work work; /* IRQ work that flushes the buffer */
> + unsigned char buffer[PAGE_SIZE - sizeof(atomic_t) -
> +sizeof(struct irq_work)];
> +};
> +static DEFINE_PER_CPU(struct nmi_seq_buf, nmi_print_seq);
PAGE_SIZE isn't always 4K.
On typical powerpc systems this will give you 128K, and on some 512K, which is
probably not what we wanted.
The existing code just did:
#define NMI_BUF_SIZE 4096
So I think you should just go back to doing that.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] support the efuse for rk3188/rk3066a SoCs and cleanup driver on nvmem.
Hi Srinivas, What's the think of this series patches? Let me know if you have any suggestions or ideas.:-) Thanks! 在 2015年11月11日 15:34, Caesar Wang 写道: This patchset to support reading the efuse info for more SoCs. (Note: support 32 bits SoCs). Meanwhile, cleanup sunxi/rockchip drivers for more readability. You can easy to test for following: cd /sys/bus/nvmem/devices/rockchip-efuse0 localhost rockchip-efuse0 # busybox hexdump -C nvmem Caesar Wang (4): nvmem: sunxi: trivial: fix code style nvmem: rockchip: trivial: Make the driver more readability ARM: dts: rockchip: add eFuse node for rk3066a SoCs ARM: dts: rockchip: add eFuse node for rk3188 SoCs arch/arm/boot/dts/rk3066a.dtsi | 13 ++ arch/arm/boot/dts/rk3188.dtsi | 13 ++ drivers/nvmem/rockchip-efuse.c | 90 -- drivers/nvmem/sunxi_sid.c | 9 ++--- 4 files changed, 71 insertions(+), 54 deletions(-) -- caesar wang | software engineer | w...@rock-chip.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3 v9] livepatch: add old_sympos as disambiguator field to klp_func
Currently, patching objects with duplicate symbol names fail because the
creation of the sysfs function directory collides with the previous
attempt. Appending old_addr to the function name is problematic as it
reveals the address of the function being patch to a normal user. Using
the symbol's occurrence in kallsyms to postfix the function name in the
sysfs directory solves the issue of having consistent unique names and
ensuring that the address is not exposed to a normal user.
In addition, using the symbol position as the user's method to disambiguate
symbols instead of addr allows for disambiguating symbols in modules as
well for both function addresses and for relocs. This also simplifies much
of the code. Special handling for kASLR is no longer needed and can be
removed. The klp_find_verify_func_addr function can be replaced by
klp_find_object_symbol, and klp_verify_vmlinux_symbol and its callback can
be removed completely.
In cases of duplicate symbols, old_sympos will be used to disambiguate
instead of old_addr. By default old_sympos will be 0, and patching will
only succeed if the symbol is unique. Specifying a positive value will
ensure that occurrence of the symbol in kallsyms for the patched object
will be used for patching if it is valid.
In addition, make old_addr an internal structure field not to be specified
by the user. Finally, remove klp_find_verify_func_addr as it can be
replaced by klp_find_object_symbol directly.
Support for symbol position disambiguation for relocations is added in the
next patch in this series.
Signed-off-by: Chris J Arges
---
include/linux/livepatch.h | 19 +++--
kernel/livepatch/core.c | 72 ---
2 files changed, 41 insertions(+), 50 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 31db7a0..b60e8ab 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -37,8 +37,9 @@ enum klp_state {
* struct klp_func - function structure for live patching
* @old_name: name of the function to be patched
* @new_func: pointer to the patched function code
- * @old_addr: a hint conveying at what address the old function
- * can be found (optional, vmlinux patches only)
+ * @old_sympos: a hint indicating which symbol position the old function
+ * can be found (optional)
+ * @old_addr: the address of the function being patched
* @kobj: kobject for sysfs resources
* @state: tracks function-level patch application state
* @stack_node:list node for klp_ops func_stack list
@@ -48,16 +49,16 @@ struct klp_func {
const char *old_name;
void *new_func;
/*
-* The old_addr field is optional and can be used to resolve
-* duplicate symbol names in the vmlinux object. If this
-* information is not present, the symbol is located by name
-* with kallsyms. If the name is not unique and old_addr is
-* not provided, the patch application fails as there is no
-* way to resolve the ambiguity.
+* The old_sympos field is optional and can be used to resolve
+* duplicate symbol names in livepatch objects. If this field is zero,
+* it is expected the symbol is unique, otherwise patching fails. If
+* this value is greater than zero then that occurrence of the symbol
+* in kallsyms for the given object is used.
*/
- unsigned long old_addr;
+ unsigned long old_sympos;
/* internal */
+ unsigned long old_addr;
struct kobject kobj;
enum klp_state state;
struct list_head stack_node;
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index db545cb..e416f96 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -135,13 +135,8 @@ struct klp_find_arg {
const char *objname;
const char *name;
unsigned long addr;
- /*
-* If count == 0, the symbol was not found. If count == 1, a unique
-* match was found and addr is set. If count > 1, there is
-* unresolvable ambiguity among "count" number of symbols with the same
-* name in the same object.
-*/
unsigned long count;
+ unsigned long pos;
};
static int klp_find_callback(void *data, const char *name,
@@ -158,37 +153,48 @@ static int klp_find_callback(void *data, const char *name,
if (args->objname && strcmp(args->objname, mod->name))
return 0;
- /*
-* args->addr might be overwritten if another match is found
-* but klp_find_object_symbol() handles this and only returns the
-* addr if count == 1.
-*/
args->addr = addr;
args->count++;
+ /*
+* Finish the search when the symbol is found for the desired position
+* or the position is not defined for a non-unique symbol.
+*/
+ if ((args->pos && (args->count ==
[PATCH 3/3 v9] livepatch: function,sympos scheme in livepatch sysfs directory
The following directory structure will allow for cases when the same function name exists in a single object. /sys/kernel/livepatch/// The sympos number corresponds to the nth occurrence of the symbol name in kallsyms for the patched object. An example of patching multiple symbols can be found here: https://github.com/dynup/kpatch/issues/493 Signed-off-by: Chris J Arges --- Documentation/ABI/testing/sysfs-kernel-livepatch | 6 +- kernel/livepatch/core.c | 10 -- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch b/Documentation/ABI/testing/sysfs-kernel-livepatch index 5bf42a8..da87f43 100644 --- a/Documentation/ABI/testing/sysfs-kernel-livepatch +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch @@ -33,7 +33,7 @@ Description: The object directory contains subdirectories for each function that is patched within the object. -What: /sys/kernel/livepatch/// +What: /sys/kernel/livepatch/// Date: Nov 2014 KernelVersion: 3.19.0 Contact: live-patch...@vger.kernel.org @@ -41,4 +41,8 @@ Description: The function directory contains attributes regarding the properties and state of the patched function. + The directory name contains the patched function name and a + sympos number corresponding to the nth occurrence of the symbol + name in kallsyms for the patched object. + There are currently no such attributes. diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index e842534..94893e8 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -535,7 +535,7 @@ EXPORT_SYMBOL_GPL(klp_enable_patch); * /sys/kernel/livepatch/ * /sys/kernel/livepatch//enabled * /sys/kernel/livepatch// - * /sys/kernel/livepatch/// + * /sys/kernel/livepatch/// */ static ssize_t enabled_store(struct kobject *kobj, struct kobj_attribute *attr, @@ -680,8 +680,14 @@ static int klp_init_func(struct klp_object *obj, struct klp_func *func) INIT_LIST_HEAD(>stack_node); func->state = KLP_DISABLED; + /* The format for the sysfs directory is where sympos +* is the nth occurrence of this symbol in kallsyms for the patched +* object. If the user selects 0 for old_sympos, then 1 will be used +* since a unique symbol will be the first occurrence. +*/ return kobject_init_and_add(>kobj, _ktype_func, - >kobj, "%s", func->old_name); + >kobj, "%s,%lu", func->old_name, + func->old_sympos ? func->old_sympos : 1); } /* parts of the initialization that is done only when the object is loaded */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3 v9] livepatch: disambiguate symbols with the same name
Currently, patching objects with duplicate symbol names fail because the creation of the sysfs function directory collides with the previous attempt. Appending old_addr to the function name is problematic as it reveals the address of the function being patch to a normal user. Using the symbol's occurrence in kallsyms to postfix the function name in the sysfs directory solves the issue of having consistent unique names and ensuring that the address is not exposed to a normal user. In addition, using the symbol position as the user's method to disambiguate symbols instead of addr allows for disambiguating symbols in modules as well for both function addresses and for relocs. This also simplifies much of the code. Special handling for kASLR is no longer needed and can be removed. The klp_find_verify_func_addr function can be replaced by klp_find_object_symbol, and klp_verify_vmlinux_symbol and its callback can be removed completely. The following set of patches use symbol positioning instead of old addresses to disambiguate symbols that have the same name in a given object. This is necessary in order to be able to patch symbols with the same name within the same object. This requires modifications to the klp_func and klp_reloc structures to add an additional element. In addition the scheme used for the func directory in sysfs is modified to append the symbols occurrence in kallsyms. In addition, I've tested this patchset against a modified kpatch. I modified the kpatch livepatch scaffolding to set lreloc->sympos = 0, and lfunc->old_sympos to the nth occurrence of the symbol for that object in kallsyms. I was able to patch the same test patch as described here: https://github.com/dynup/kpatch/issues/493 I've also tested this with sample livepatch code to test if the various old_sympos values work for unique and duplicate functions. v9: - use mod->name instead of mod->obj->name for klp_find_object_symbol in klp_write_object_relocations - rebase on current master - tested with kpatch v8: - explain motivation and necessity in initial patch - don't support sympos for external relocations v7: - make count/pos checking in klp_find_callback more readable - fix klp_write_object_relocations sympos/external checking v6: - move sympos arg before addr in klp_find_object_symbol - make comments more accurate, remove unnecessary whitespace - improve cover letter v5: - remove val from klp_reloc struct - klp_write_object_relocations doesn't use sympos with external relocs - add Petr Mladek's patch to simplify relocated external symbol code - add optimization in klp_find_callback in unique case - remove klp_find_verify_func_addr - amend/remove commit messages/comments to be more precise Chris J Arges (3): livepatch: add old_sympos as disambiguator field to klp_func livepatch: add sympos as disambiguator field to klp_reloc livepatch: function,sympos scheme in livepatch sysfs directory Documentation/ABI/testing/sysfs-kernel-livepatch | 6 +- include/linux/livepatch.h| 24 ++-- kernel/livepatch/core.c | 164 --- 3 files changed, 74 insertions(+), 120 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3 v9] livepatch: add sympos as disambiguator field to klp_reloc
In cases of duplicate symbols, sympos will be used to disambiguate instead
of val. By default sympos will be 0, and patching will only succeed if
the symbol is unique. Specifying a positive value will ensure that
occurrence of the symbol in kallsyms for the patched object will be used
for patching if it is valid. For external relocations sympos is not
supported.
Remove klp_verify_callback, klp_verify_args and klp_verify_vmlinux_symbol
as they are no longer used.
>From the klp_reloc structure remove val, as it can be refactored as a
local variable in klp_write_object_relocations.
Signed-off-by: Chris J Arges
---
include/linux/livepatch.h | 5 ++-
kernel/livepatch/core.c | 84 +++
2 files changed, 21 insertions(+), 68 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index b60e8ab..a882865 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -67,8 +67,7 @@ struct klp_func {
/**
* struct klp_reloc - relocation structure for live patching
* @loc: address where the relocation will be written
- * @val: address of the referenced symbol (optional,
- * vmlinux patches only)
+ * @sympos:position in kallsyms to disambiguate symbols (optional)
* @type: ELF relocation type
* @name: name of the referenced symbol (for lookup/verification)
* @addend:offset from the referenced symbol
@@ -76,7 +75,7 @@ struct klp_func {
*/
struct klp_reloc {
unsigned long loc;
- unsigned long val;
+ unsigned long sympos;
unsigned long type;
const char *name;
int addend;
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index e416f96..e842534 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -203,45 +203,6 @@ static int klp_find_object_symbol(const char *objname,
const char *name,
return -EINVAL;
}
-struct klp_verify_args {
- const char *name;
- const unsigned long addr;
-};
-
-static int klp_verify_callback(void *data, const char *name,
- struct module *mod, unsigned long addr)
-{
- struct klp_verify_args *args = data;
-
- if (!mod &&
- !strcmp(args->name, name) &&
- args->addr == addr)
- return 1;
-
- return 0;
-}
-
-static int klp_verify_vmlinux_symbol(const char *name, unsigned long addr)
-{
- struct klp_verify_args args = {
- .name = name,
- .addr = addr,
- };
- int ret;
-
- mutex_lock(_mutex);
- ret = kallsyms_on_each_symbol(klp_verify_callback, );
- mutex_unlock(_mutex);
-
- if (!ret) {
- pr_err("symbol '%s' not found at specified address 0x%016lx,
kernel mismatch?\n",
- name, addr);
- return -EINVAL;
- }
-
- return 0;
-}
-
/*
* external symbols are located outside the parent object (where the parent
* object is either vmlinux or the kmod being patched).
@@ -272,6 +233,7 @@ static int klp_write_object_relocations(struct module *pmod,
struct klp_object *obj)
{
int ret;
+ unsigned long val;
struct klp_reloc *reloc;
if (WARN_ON(!klp_is_object_loaded(obj)))
@@ -281,35 +243,27 @@ static int klp_write_object_relocations(struct module
*pmod,
return -EINVAL;
for (reloc = obj->relocs; reloc->name; reloc++) {
- if (!klp_is_module(obj)) {
-
-#if defined(CONFIG_RANDOMIZE_BASE)
- /* If KASLR has been enabled, adjust old value
accordingly */
- if (kaslr_enabled())
- reloc->val += kaslr_offset();
-#endif
- ret = klp_verify_vmlinux_symbol(reloc->name,
- reloc->val);
- if (ret)
- return ret;
- } else {
- /* module, reloc->val needs to be discovered */
- if (reloc->external)
- ret = klp_find_external_symbol(pmod,
- reloc->name,
- >val);
- else
- ret = klp_find_object_symbol(obj->mod->name,
-reloc->name,
-0, >val);
- if (ret)
- return ret;
- }
+ /* discover the address of the referenced symbol */
+ if (reloc->external) {
+ if (reloc->sympos > 0) {
+ pr_err("non-zero sympos for external reloc
symbol '%s' is not supported\n",
+
Re: [PATCH v2] arm64: dts: add all hi6220 i2c nodes
hi Shawn
On 2015/12/2 10:05, Shawn Guo wrote:
> On Thu, Nov 26, 2015 at 03:57:03PM +0800, Xinwei Kong wrote:
>> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
>> use this I2C IP of Synopsys Designware for HiKey board.
>>
>> Signed-off-by: Xinwei Kong
>> ---
>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37
>> +++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> index 82d2488..85d4a8b 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> @@ -208,5 +208,42 @@
>> clock-names = "uartclk", "apb_pclk";
>> status = "disabled";
>> };
>> +
>> +i2c0: i2c@f710 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf710 0x0 0x1000>;
>> +interrupts = <0 44 4>;
>> +clocks = <_ctrl HI6220_I2C0_CLK>;
>> +clock-names = "clk_i2c0";
>
> Neither bindings doc i2c-designware.txt defines this property, nor
> kernel i2c-designware driver uses this property. So I think this
> clock-names property can just be dropped.
>
This property should been delete it. I will debug it in HiKey board then
send v3 patch.
Thank you
xinwei
> Otherwise, the patch looks good to me.
>
> Shawn
>
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pmx_func _cfg_func>;
>> +status = "disabled";
>> +};
>> +
>> +i2c1: i2c@f7101000 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf7101000 0x0 0x1000>;
>> +interrupts = <0 45 4>;
>> +clocks = <_ctrl HI6220_I2C1_CLK>;
>> +clock-names = "clk_i2c1";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pmx_func _cfg_func>;
>> +status = "disabled";
>> +};
>> +
>> +i2c2: i2c@f7102000 {
>> +compatible = "snps,designware-i2c";
>> +reg = <0x0 0xf7102000 0x0 0x1000>;
>> +interrupts = <0 46 4>;
>> +clocks = <_ctrl HI6220_I2C2_CLK>;
>> +clock-names = "clk_i2c2";
>> +i2c-sda-hold-time-ns = <300>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pmx_func _cfg_func>;
>> +status = "disabled";
>> +};
>> +
>> };
>> };
>> --
>> 1.9.1
>>
>>
>>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm64: dts: qcom: Add apq8096 dragonboard dts skeletons
On 12/02/2015 02:59 AM, Bryan Huntsman wrote: > On 12/01/2015 08:11 AM, Rajendra Nayak wrote: >> Add new dtsi and dts files for the apq8096 dragonboards with just >> a serial device used as debug console >> >> While at it, also rearrange the Makefile so we have one dtb per line >> so as to be consistent with whats done on other platforms. >> >> Signed-off-by: Rajendra Nayak >> --- >> arch/arm64/boot/dts/qcom/Makefile | 4 ++- >> arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts | 21 >> arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 >> +++ >> 3 files changed, 54 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts >> create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi > > One problem. The board you have is not called a dragonboard. Let's > check with the marketing folks on what they're calling it now. We need > to explicitly avoid using dragonboard here as that name applies to a > different class of products. Thanks. Thanks Bryan, I'll update with the new board name. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tboot: non-0 tboot_addr but it is not of type E820_RESERVED
On 12/01/15 17:26, Elliott, Robert (Persistent Memory) wrote: Per an hpa suggestion, I compared two versions of grub: upstream grub (with "linux" in grub.cfg): tboot_probe boot_params[0] = 0080 0070 tboot_probe boot_params[16] = 100400032000 00913000 tboot_probe boot_params[32] = 3fa3001000100810 080808000818 tboot_probe boot_params[48] = tboot probe boot_params[64] = tboot_probe boot_params[80] = tboot_probe boot_params[96] = tboot_probe boot_params[112] = tboot_probe boot_params[128] = tboot_probe boot_params[144] = tboot_probe boot_params[160] = tboot_probe boot_params[176] = tboot_probe boot_params[192] = ... Fedora 22 grub (with "linuxefi" in grub.cfg): tboot_probe boot_params[0] = 0070 tboot_probe boot_params[16] = 000400032000 00913000 tboot_probe boot_params[32] = 00100810 080808000818 tboot_probe boot_params[48] = 01000100 tboot_probe boot_params[64] = 557365206120626f 6f74206c6f616465 tboot_probe boot_params[80] = 722e0d0a0a52656d 6f7665206469736b tboot_probe boot_params[96] = 20616e6420707265 737320616e79206b tboot_probe boot_params[112] = 657920746f207265 626f6f742e2e2e0d tboot_probe boot_params[128] = 0a0050456486 0400 tboot_probe boot_params[144] = 0100a000 06020b020214f017 tboot_probe boot_params[160] = 5c001076 d20010460002 tboot_probe boot_params[176] = 20002000 tboot_probe boot_params[192] = ... [0.00] tboot: non-0 tboot_addr 0x6b7369642065766f but it is not of type E820_RESERVED In both cases, the kernel is compiled with CONFIG_EFI_STUB=y. tboot_addr is at offset 88. Offset 64 is an ASCII string that says: "Use a boot loader. Remove disk and press any key to reboot..." and is from arch/x86/boot/header.S, which is placing that string at offset 64 (0x3c + 4) from .bstext (which precedes .bsdata) if CONFIG_EFI_STUB is true. #ifdef CONFIG_EFI_STUB .org0x3c # # Offset to the PE header. # .long pe_header #endif /* CONFIG_EFI_STUB */ .section ".bsdata", "a" bugger_off_msg: .ascii "Use a boot loader.\r\n" .ascii "\n" .ascii "Remove disk and press any key to reboot...\r\n" .byte 0 Most likely the "linuxefi" boot method uses the EFI handover protocol, however. It looks like they don't start with a properly zeroed structure... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros
On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > Hi,
> >
> > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh wrote:
> > > > Hi,
> > > >
> >
> >
> >
> > > >> > */
> > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
> > > >> > -({ \
> > > >> > - unsigned long __dummy1, __dummy2; \
> > > >> > - __asm__ __volatile__ ("inl %%dx" : \
> > > >> > - "=a"(out1), \
> > > >> > - "=b"(out2), \
> > > >> > - "=c"(out3), \
> > > >> > - "=d"(out4), \
> > > >> > - "=S"(__dummy1), \
> > > >> > - "=D"(__dummy2) :\
> > > >> > - "a"(VMMOUSE_PROTO_MAGIC), \
> > > >> > - "b"(in1), \
> > > >> > - "c"(VMMOUSE_PROTO_CMD_##cmd), \
> > > >> > - "d"(VMMOUSE_PROTO_PORT) : \
> > > >> > - "memory"); \
> > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)
> > > >> > \
> > > >> > +({\
> > > >> > + unsigned long __dummy1 = 0, __dummy2 = 0; \
> > > >>
> > > >> Why do we need to initialize dummies?
> > > >
> > > > Because for some commands those parameters to VMW_PORT() can be both
> > > > input and outout.
> > >
> > > The vmmouse commands do not use them as input though, so it seems we
> > > are simply wasting CPU cycles setting them to 0 just because we are
> > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > benefit of doing this?
> >
> > There are two reasons. One is to make the code more readable and
> > maintainable. Rather than having mostly similar inline assembly
> > code sprinkled across multiple modules, we can just use the macros
> > and document that.
>
> But the macro is only used here, and the variables aren't used at all,
> so it makes no sense in this file.
Maybe it's because I didn't CC you on the rest of the series. I wasn't
sure what the proper distribution list is for each part.
This new macro is also used in arch/x86/kernel/cpu/vmware.c and
vmw_balloon.c
>
> > The second reason is this organization makes some on-going future
> > development easier.
>
> We don't plan for "future" development other than a single patch series,
> as we have no idea what that development is, nor if it will really
> happen. You can always change this file later if you need to, nothing
> is keeping that from happening.
So the intent of this series is to centralize similar lines of inline
assembly code that are currently used by 3 different kernel modules
to a central place. The new vmware.h [patch 0/6] becomes the one header
to include for common guest-host communication needs.
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] ASoC: cygnus: Add Cygnus audio DAI driver
On 11/22/2015 5:44 AM, Mark Brown wrote:
On Mon, Nov 09, 2015 at 04:17:43PM -0800, Simran Rai wrote:
+#ifdef CONFIG_PM_SLEEP
+static int cygnus_ssp_suspend(struct snd_soc_dai *cpu_dai)
+{
+ struct cygnus_aio_port *aio = cygnus_dai_get_portinfo(cpu_dai);
+ struct cygnus_audio *cygaud = snd_soc_dai_get_drvdata(cpu_dai);
+
+ audio_ssp_out_disable(aio);
+ audio_ssp_in_disable(aio);
+ if (cygaud->active_ports > 0)
+ cygaud->active_ports--;
+
+ return 0;
+}
+
+static int cygnus_ssp_resume(struct snd_soc_dai *cpu_dai)
+{
+ return 0;
+}
I'm a bit confused here - why do we need to disable things on suspend
but not reenable them on resume? I'd expect that the core would have
quiesced any streams that need to be suspended before we get as far as
suspending the drivers.
Please also remove empty functions.
Now I check I see that I'm repeating the questions I had on my previous
review:
| Blank line between functions and remove empty functions. Though I'm not
| clear why the result doesn't undo what the suspend did...
Please don't ignore review comments.
Let me investigate this further and debug why the core did not
quiescence the streams.
+ parent = clk_get_parent(cygaud->audio_clk[0]);
+ if (IS_ERR(parent)) {
+ error = PTR_ERR(parent);
+ goto err_get_parent;
+ }
+
+ /* Set PLL VCO Frequency (Hz) to default */
+ error = clk_set_rate(parent, DEFAULT_VCO);
+ if (error) {
+ dev_err(>dev,
+ "%s Set PLL VCO rate failed: %d\n", __func__, error);
+ goto err_get_parent;
+ }
I would expect any initialisationn of clocks beyond the ones that the
device directly interacts with to be handled within the clock API
configuration rather than in a specific driver, this avoids the driver
being dependent on a particular system integration.
I will have to figure out a way to propagate the frequency from leaf clocks to
the parent
clock. Will send out another patch with the fix.
Thanks,
Simran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] iio: ina2xx: add support for TI INA2xx Power Monitors
On Mon, Nov 30, 2015 at 12:49:14PM +0100, Marc Titinger wrote:
> in SOFTWARE buffer mode, a kthread will capture the active scan_elements
> into a kfifo, then compute the remaining time until the next capture tick
> and do an active wait (udelay).
>
> This will produce a stream of up to fours channels plus a 64bits
> timestamps (ns).
>
> Tested with ina226, on BeagleBoneBlack.
>
> Datasheet: http://www.ti.com/lit/gpn/ina226
>
> Signed-off-by: Marc Titinger
> ---
> drivers/iio/adc/Kconfig | 9 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ina2xx-iio.c | 678
> +++
> 3 files changed, 688 insertions(+)
> create mode 100644 drivers/iio/adc/ina2xx-iio.c
> +
[ ... ]
> +
> +static const struct i2c_device_id ina2xx_id[] = {
> + {"ina219", ina219},
> + {"ina220", ina219},
> + {"ina226", ina226},
> + {"ina230", ina226},
> + {"ina231", ina226},
> + {}
> +};
I wonder what is going to happen if both this driver and the hwmon
driver for the same chips are configured in a system which supports
devicetree (or any system, really). Unless I am missing something,
the result will be that both drivers will try to instantiate, and
one will fail with -EBUSY. Or the instantiated driver is more or less
random, depending on which one happens to be loaded. Not a good
situation to be in.
For the time being, it might make sense to add cross-dependencies
in Kconfig to only permit one of the two drivers to be configured.
Ultimately we may need a better solution for the iio-hwmon bridge,
one that makes the underlying driver transparent in both devicetree
properties and user space ABI. No idea how to do that, though.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm64: dts: add all hi6220 i2c nodes
On Thu, Nov 26, 2015 at 03:57:03PM +0800, Xinwei Kong wrote:
> This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
> use this I2C IP of Synopsys Designware for HiKey board.
>
> Signed-off-by: Xinwei Kong
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37
> +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 82d2488..85d4a8b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -208,5 +208,42 @@
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
> +
> + i2c0: i2c@f710 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf710 0x0 0x1000>;
> + interrupts = <0 44 4>;
> + clocks = <_ctrl HI6220_I2C0_CLK>;
> + clock-names = "clk_i2c0";
Neither bindings doc i2c-designware.txt defines this property, nor
kernel i2c-designware driver uses this property. So I think this
clock-names property can just be dropped.
Otherwise, the patch looks good to me.
Shawn
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmx_func _cfg_func>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@f7101000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7101000 0x0 0x1000>;
> + interrupts = <0 45 4>;
> + clocks = <_ctrl HI6220_I2C1_CLK>;
> + clock-names = "clk_i2c1";
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmx_func _cfg_func>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@f7102000 {
> + compatible = "snps,designware-i2c";
> + reg = <0x0 0xf7102000 0x0 0x1000>;
> + interrupts = <0 46 4>;
> + clocks = <_ctrl HI6220_I2C2_CLK>;
> + clock-names = "clk_i2c2";
> + i2c-sda-hold-time-ns = <300>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmx_func _cfg_func>;
> + status = "disabled";
> + };
> +
> };
> };
> --
> 1.9.1
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] x86: Add trace point for MSR accesses
On Tue, 1 Dec 2015 17:00:59 -0800 Andi Kleen wrote: > From: Andi Kleen > > For debugging low level code interacting with the CPU > it is often useful to trace the MSR read/writes. This gives > a concise summary of PMU and other operations. > > perf has an ad-hoc way to do this using trace_printk, > but it's somewhat limited (and also now spews ugly boot > messages when enabled) > > Instead define real trace points for all MSR accesses. > > This adds three new trace points: read_msr and write_msr > and rdpmc. > > They also report if the access faulted (if *_safe is used) > > This allows filtering and triggering on specific > MSR values, which allows various more advanced > debugging techniques. > > All the values are well defined in the CPU documentation. > > The trace can be post processed with > Documentation/trace/postprocess/decode_msr.py > to add symbolic MSR names to the trace. > > I only added it to native MSR accesses in C, not paravirtualized > or in entry*.S (which is not too interesting) > > Originally the patch kit moved the MSRs out of line. > This uses an alternative approach recommended by Steven Rostedt > of only moving the trace calls out of line, but open coding the > access to the jump label. > > v2: > Move MSR trace events to arch/x86/include/asm/msr-trace.h > Signed-off-by: Andi Kleen > For the general tracing part. Acked-by: Steven Rostedt -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] tracepoints: Move struct tracepoint to new tracepoint-defs.h header
On Tue, 1 Dec 2015 17:00:58 -0800 Andi Kleen wrote: > From: Andi Kleen > > Steven recommended open coding access to tracepoint->key to add > trace points to headers. Unfortunately this is difficult for some > headers (such as x86 asm/msr.h) because including tracepoint.h > includes so many other headers that it causes include loops. > The main problem is the include of linux/rcupdate.h, which > pulls in a lot of other headers. The rcu header is only needed > when actually defining trace points. > > Move the struct tracepoint into a separate tracepoint-defs.h > header that can be included without pulling in all of RCU. > > Signed-off-by: Andi Kleen Acked-by: Steven Rostedt -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
