Re: [PATCH 5/5] mm: mark stable page dirty in KSM
On Mon, Oct 26, 2015 at 07:23:12PM -0700, Hugh Dickins wrote: > On Mon, 19 Oct 2015, Minchan Kim wrote: > > > Stable page could be shared by several processes and last process > > could own the page among them after CoW or zapping for every process > > except last process happens. Then, page table entry of the page > > in last process can have no dirty bit and PG_dirty flag in page->flags. > > In this case, MADV_FREE could discard the page wrongly. > > For preventing it, we mark stable page dirty. > > I agree with the change, but found that comment (repeated in the source) > rather hard to follow. And it doesn't really do justice to the changes > you have made. > > This is not now a MADV_FREE thing, it's more general than that, even > if MADV_FREE is the only thing that takes advantage of it. I like > very much that you've made page reclaim sane, freeing non-dirty > anonymous pages instead of swapping them out, without having to > think of whether it's for MADV_FREE or not. > > Would you mind if we replace your patch by a re-commented version? > > [PATCH] mm: mark stable page dirty in KSM > > The MADV_FREE patchset changes page reclaim to simply free a clean > anonymous page with no dirty ptes, instead of swapping it out; but > KSM uses clean write-protected ptes to reference the stable ksm page. > So be sure to mark that page dirty, so it's never mistakenly discarded. > > Signed-off-by: Minchan Kim > Signed-off-by: Hugh Dickins Looks better than mine. I will include this in my patchset when I respin. 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] scsi_sysfs: Fix queue_ramp_up_period return code
On 10/26/2015 03:54 PM, Peter Oberparleiter wrote: > Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period > returns the value of that number instead of the number of bytes written. > This behavior can confuse programs expecting POSIX write() semantics. > Fix this by returning the number of bytes written instead. > > Signed-off-by: Peter Oberparleiter > --- > drivers/scsi/scsi_sysfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c > index b89..6b0f292 100644 > --- a/drivers/scsi/scsi_sysfs.c > +++ b/drivers/scsi/scsi_sysfs.c > @@ -898,7 +898,7 @@ sdev_store_queue_ramp_up_period(struct device *dev, > return -EINVAL; > > sdev->queue_ramp_up_period = msecs_to_jiffies(period); > - return period; > + return count; > } > > static DEVICE_ATTR(queue_ramp_up_period, S_IRUGO | S_IWUSR, > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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/
character driver - poll() timeout
[ Please keep me in CC as I'm not subscribed to the list] Hello, Is it possible to print the timeout value in character driver poll() API? User mode call: int poll(struct pollfd *fds, nfds_t nfds, int timeout) Kernel mode call: unsigned int driver_poll(struct file *filp, poll_table *wait) -- Thanks, Sekhar -- 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 3/7] usb: gadget: define free_ep_req as universal function
On 10/26/2015 05:55 PM, Felipe F. Tonello wrote:
> This function is shared between gadget functions, so this avoid unnecessary
> duplicated code and potentially avoid memory leaks.
>
> Signed-off-by: Felipe F. Tonello
> ---
> drivers/usb/gadget/function/f_midi.c | 6 --
> drivers/usb/gadget/function/f_sourcesink.c | 6 --
> drivers/usb/gadget/function/g_zero.h | 1 -
> drivers/usb/gadget/u_f.c | 8
> drivers/usb/gadget/u_f.h | 3 +--
> 5 files changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c
> b/drivers/usb/gadget/function/f_midi.c
> index c19f154..4c01c8a 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -202,12 +202,6 @@ static inline struct usb_request
> *midi_alloc_ep_req(struct usb_ep *ep,
> return alloc_ep_req(ep, length, length);
> }
>
> -static void free_ep_req(struct usb_ep *ep, struct usb_request *req)
> -{
> - kfree(req->buf);
> - usb_ep_free_request(ep, req);
> -}
> -
> static const uint8_t f_midi_cin_length[] = {
> 0, 0, 2, 3, 3, 1, 2, 3, 3, 3, 3, 3, 2, 2, 3, 1
> };
> diff --git a/drivers/usb/gadget/function/f_sourcesink.c
> b/drivers/usb/gadget/function/f_sourcesink.c
> index 3a5ae99..eedea7f 100644
> --- a/drivers/usb/gadget/function/f_sourcesink.c
> +++ b/drivers/usb/gadget/function/f_sourcesink.c
> @@ -307,12 +307,6 @@ static inline struct usb_request *ss_alloc_ep_req(struct
> usb_ep *ep, int len)
> return alloc_ep_req(ep, len, buflen);
> }
>
> -void free_ep_req(struct usb_ep *ep, struct usb_request *req)
> -{
> - kfree(req->buf);
> - usb_ep_free_request(ep, req);
> -}
> -
> static void disable_ep(struct usb_composite_dev *cdev, struct usb_ep *ep)
> {
> int value;
> diff --git a/drivers/usb/gadget/function/g_zero.h
> b/drivers/usb/gadget/function/g_zero.h
> index 15f1809..5ed90b4 100644
> --- a/drivers/usb/gadget/function/g_zero.h
> +++ b/drivers/usb/gadget/function/g_zero.h
> @@ -59,7 +59,6 @@ void lb_modexit(void);
> int lb_modinit(void);
>
> /* common utilities */
> -void free_ep_req(struct usb_ep *ep, struct usb_request *req);
> void disable_endpoints(struct usb_composite_dev *cdev,
> struct usb_ep *in, struct usb_ep *out,
> struct usb_ep *iso_in, struct usb_ep *iso_out);
> diff --git a/drivers/usb/gadget/u_f.c b/drivers/usb/gadget/u_f.c
> index c6276f0..f78bd1f 100644
> --- a/drivers/usb/gadget/u_f.c
> +++ b/drivers/usb/gadget/u_f.c
> @@ -14,6 +14,7 @@
> #include
> #include "u_f.h"
>
> +/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
> struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len)
> {
> struct usb_request *req;
> @@ -30,3 +31,10 @@ struct usb_request *alloc_ep_req(struct usb_ep *ep, int
> len, int default_len)
> return req;
> }
> EXPORT_SYMBOL_GPL(alloc_ep_req);
> +
> +void free_ep_req(struct usb_ep *ep, struct usb_request *req)
> +{
> + kfree(req->buf);
> + usb_ep_free_request(ep, req);
> +}
> +EXPORT_SYMBOL_GPL(free_ep_req);
> diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
> index 1d5f0eb..2a1a6fb 100644
> --- a/drivers/usb/gadget/u_f.h
> +++ b/drivers/usb/gadget/u_f.h
> @@ -46,7 +46,6 @@ struct usb_ep;
> struct usb_request;
>
> struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int
> default_len);
> +void free_ep_req(struct usb_ep *ep, struct usb_request *req);
>
> #endif /* __U_F_H__ */
> -
> -
>
Isn't it simple enough to be static inline?
Best regards,
Robert
--
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 4/5] mm: simplify reclaim path for MADV_FREE
On Mon, Oct 26, 2015 at 07:09:15PM -0700, Hugh Dickins wrote: > On Mon, 19 Oct 2015, Minchan Kim wrote: > > > I made reclaim path mess to check and free MADV_FREEed page. > > This patch simplify it with tweaking add_to_swap. > > > > So far, we mark page as PG_dirty when we add the page into > > swap cache(ie, add_to_swap) to page out to swap device but > > this patch moves PG_dirty marking under try_to_unmap_one > > when we decide to change pte from anon to swapent so if > > any process's pte has swapent for the page, the page must > > be swapped out. IOW, there should be no funcional behavior > > change. It makes relcaim path really simple for MADV_FREE > > because we just need to check PG_dirty of page to decide > > discarding the page or not. > > > > Other thing this patch does is to pass TTU_BATCH_FLUSH to > > try_to_unmap when we handle freeable page because I don't > > see any reason to prevent it. > > > > Cc: Hugh Dickins > > Cc: Mel Gorman > > Signed-off-by: Minchan Kim > > Acked-by: Hugh Dickins > > This is sooo much nicer than the code it replaces! Really good. Thanks! > Kudos also to Hannes for suggesting this approach originally, I think. I should buy beer or soju if Hannes likes. > > I hope this implementation satisfies a good proportion of the people > who have been wanting MADV_FREE: I'm not among them, and have long > lost touch with those discussions, so won't judge how usable it is. > > I assume you'll refactor the series again before it goes to Linus, > so the previous messier implementations vanish? I notice Andrew Actutally, I didn't think about that but once you mentioned it, I realized that would be better. Thanks for the suggestion. > has this "mm: simplify reclaim path for MADV_FREE" in mmotm as > mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch: > I guess it all got much too messy to divide up in a hurry. Yeb, I will rebase all series from the beginning based on recent mmtom so I will vanish the mess in git-blame. When I rebases it in mmotm, I will do it before reaching THP refcount new design if Andrew and Kirill don't mind it because it makes to fail my test as I reported. I don't know it's long time unknown bug or something THP-ref new introduces. Anyway, I want to test smoothly. > > I've noticed no problems in testing (unlike the first time you moved > to working with pte_dirty); though of course I've not been using Thanks for testing! > MADV_FREE itself at all. > > One aspect has worried me for a while, but I think I've reached the > conclusion that it doesn't matter at all. The swap that's allocated > in add_to_swap() would normally get freed again (after try_to_unmap > found it was a MADV_FREE !pte_dirty !PageDirty case) at the bottom > of shrink_page_list(), in __remove_mapping(), yes? Right. > > The bit that worried me is that on rare occasions, something unknown > might take a speculative reference to the page, and __remove_mapping() > fail to freeze refs for that reason. Much too rare to worry over not > freeing that page immediately, but it leaves us with a PageUptodate > PageSwapCache !PageDirty page, yet its contents are not the contents > of that location on swap. > > But since this can only happen when you have *not* inserted the > corresponding swapent anywhere, I cannot think of anything that would > have a legitimate interest in its contents matching that location on swap. > So I don't think it's worth looking for somewhere to add a SetPageDirty > (or a delete_from_swap_cache) just to regularize that case. Exactly. -- 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 v12 4/6] QE/CPM: move muram management functions to qe_common
On Tue, 2015-10-27 at 01:24 -0500, Zhao Qiang-B45475 wrote: > On Tue, Oct 27, 2015 at 12:48 PM, Wood Scott-B07421 wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Tuesday, October 27, 2015 12:48 PM > > To: Zhao Qiang-B45475 > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > > pau...@samba.org > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to > > qe_common > > > > On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote: > > > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote: > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Saturday, October 24, 2015 4:56 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > > > > pau...@samba.org > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management > > functions > > > > to qe_common > > > > > > > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote: > > > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421 > > > > > > > > > > wrote: > > > > > > -Original Message- > > > > > > From: Wood Scott-B07421 > > > > > > Sent: Friday, October 23, 2015 11:10 AM > > > > > > To: Zhao Qiang-B45475 > > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 > > > > > > ; pau...@samba.org > > > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management > > > > functions > > > > > > to qe_common > > > > > > > > > > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote: > > > > > > > QE and CPM have the same muram, they use the same management > > > > > > > functions. Now QE support both ARM and PowerPC, it is > > > > > > > necessary to move QE to "driver/soc", so move the muram > > > > > > > management functions from cpm_common to qe_common for > > > > > > > preparing to move QE code to > > > > "driver/soc" > > > > > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > > > --- > > > > > > > Changes for v2: > > > > > > > - no changes > > > > > > > Changes for v3: > > > > > > > - no changes > > > > > > > Changes for v4: > > > > > > > - no changes > > > > > > > Changes for v5: > > > > > > > - no changes > > > > > > > Changes for v6: > > > > > > > - using genalloc instead rheap to manage QE MURAM > > > > > > > - remove qe_reset from platform file, using > > > > > > > - subsys_initcall to call qe_init function. > > > > > > > Changes for v7: > > > > > > > - move this patch from 3/3 to 2/3 > > > > > > > - convert cpm with genalloc > > > > > > > - check for gen_pool allocation failure Changes for v8: > > > > > > > - rebase > > > > > > > - move BD_SC_* macro instead of copy Changes for v9: > > > > > > > - doesn't modify CPM, add a new patch to modify. > > > > > > > - rebase > > > > > > > Changes for v10: > > > > > > > - rebase > > > > > > > Changes for v11: > > > > > > > - remove renaming > > > > > > > - delete removing qe_reset and delete adding qe_init. > > > > > > > Changes for v12: > > > > > > > - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for > > it. > > > > > > > > > > > > Why is the SPI change part of this patch? Why is it even part > > > > > > of this patchset, rather than an independent patch sent to the > > > > > > SPI list and maintainer? If it's tied to other changes you're > > > > > > making, explain that. As is, there is zero mention of the SPI > > > > > > change in the part of the e-mail that will become the git > > > > > > changelog. > > > > > > > > > > > This SPI_FSL_CPM is cpm-spi, it is part of CPM. > > > > > > > > So then why are you selecting QUICC_ENGINE? And again, what does it > > > > have to do with this patch? > > > > > > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will > > > failed to build. > > > > Why QUICC_ENGINE and not CPM? > > QE and CPM use the same muram, and it has been moved to qe_muram from > cpm_muram. Fix the makefiles so that the muram code continues to be built for both QUICC_ENGINE and CPM. It's not acceptable to have to bring in the entire QE code just for the muram. -Scott -- 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/5] mm: clear PG_dirty to mark page freeable
On Mon, Oct 26, 2015 at 06:28:13PM -0700, Hugh Dickins wrote: > On Mon, 19 Oct 2015, Minchan Kim wrote: > > > Basically, MADV_FREE relies on dirty bit in page table entry > > to decide whether VM allows to discard the page or not. > > IOW, if page table entry includes marked dirty bit, VM shouldn't > > discard the page. > > > > However, as a example, if swap-in by read fault happens, > > page table entry doesn't have dirty bit so MADV_FREE could discard > > the page wrongly. > > > > For avoiding the problem, MADV_FREE did more checks with PageDirty > > and PageSwapCache. It worked out because swapped-in page lives on > > swap cache and since it is evicted from the swap cache, the page has > > PG_dirty flag. So both page flags check effectively prevent > > wrong discarding by MADV_FREE. > > > > However, a problem in above logic is that swapped-in page has > > PG_dirty still after they are removed from swap cache so VM cannot > > consider the page as freeable any more even if madvise_free is > > called in future. > > > > Look at below example for detail. > > > > ptr = malloc(); > > memset(ptr); > > .. > > .. > > .. heavy memory pressure so all of pages are swapped out > > .. > > .. > > var = *ptr; -> a page swapped-in and could be removed from > >swapcache. Then, page table doesn't mark > >dirty bit and page descriptor includes PG_dirty > > .. > > .. > > madvise_free(ptr); -> It doesn't clear PG_dirty of the page. > > .. > > .. > > .. > > .. heavy memory pressure again. > > .. In this time, VM cannot discard the page because the page > > .. has *PG_dirty* > > > > To solve the problem, this patch clears PG_dirty if only the page > > is owned exclusively by current process when madvise is called > > because PG_dirty represents ptes's dirtiness in several processes > > so we could clear it only if we own it exclusively. > > > > Cc: Hugh Dickins > > Signed-off-by: Minchan Kim > > Acked-by: Hugh Dickins > > (and patches 1/5 and 2/5 too if you like) > Thanks for the review, Hugh! I will rebase all series from the beginning as you suggested and will add your Acked-by because I feel you just reviewed all of MADV_FREE code line and you have no found any problem. If something happens(ie, I abuse your Acked-by) wrong, please shout me. -- 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 5/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface
On 10/26/2015 11:53 PM, Felipe Tonello wrote: > Hi Robert, > > On Mon, Oct 26, 2015 at 10:30 PM, Robert Baldyga > wrote: >> On 10/26/2015 05:55 PM, Felipe F. Tonello wrote: >>> This avoids duplication of USB requests for OUT endpoint and >>> re-enabling endpoints. >>> >>> Signed-off-by: Felipe F. Tonello >>> --- >>> drivers/usb/gadget/function/f_midi.c | 4 >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/drivers/usb/gadget/function/f_midi.c >>> b/drivers/usb/gadget/function/f_midi.c >>> index 0e9cdeb..a617df3 100644 >>> --- a/drivers/usb/gadget/function/f_midi.c >>> +++ b/drivers/usb/gadget/function/f_midi.c >>> @@ -323,6 +323,10 @@ static int f_midi_set_alt(struct usb_function *f, >>> unsigned intf, unsigned alt) >>> unsigned i; >>> int err; >>> >>> + /* We don't care if it is not MIDIStreaming interface */ >>> + if (intf != ms_interface_desc.bInterfaceNumber) >>> + return 0; >>> + >> >> These global descriptors are overwritten in bind() of each instance of >> f_midi, so you have no guarantee that your bInterfaceNumber is correct >> for your current instance. Instead you should store value obtained from >> usb_interface_id() during bind(). > > Ok. > > But then this interface descriptors shouldn't be global static, > because they will always reflect the latest bind() only. Right? They are copied for each instance of USB function, so they are actually template to fill and copy in bind(). I'm currently working on some patches changing a bit behavior of set_alt() to make it clearer, but for now the only way to distinguish between altsettings properly is to store bInterfaceNumber value for each function instance in its bind(). Best regards, Robert > >> >>> err = f_midi_start_ep(midi, f, midi->in_ep); >>> if (err) >>> return err; >>> > > Felipe -- 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 PATCH] VFIO: Add a parameter to force nonthread IRQ
On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote:
> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
> > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
> > assigning a device to a guest with low latency requirement since it
> > reduce the context switch to/from the IRQ thread.
>
> Is there any way we can do this automatically? Perhaps detecting that
> we're on a RT kernel or maybe that the user is running with RT priority?
> I find that module options are mostly misunderstood and misused.
Alex, thanks for review.
It's not easy to detect if the user is running with RT priority, since
sometimes the user start the thread and then set the scheduler priority
late.
Also should we do this only for in kernel irqchip scenario and not for user
space handler, since in kernel irqchip has lower overhead?
>
> > An experiment was conducted on a HSW platform for 1 minutes, with the
> > guest vCPU bound to isolated pCPU. The assigned device triggered the
> > interrupt every 1ms. The average EXTERNAL_INTERRUPT exit handling time
> > is dropped from 5.3us to 2.2us.
> >
> > Another choice is to change VFIO_DEVICE_SET_IRQS ioctl, to apply this
> > option only to specific devices when in kernel irq_chip is enabled. It
> > provides more flexibility but is more complex, not sure if we need go
> > through that way.
>
> Allowing the user to decide whether or not to use a threaded IRQ seems
> like a privilege violation; a chance for the user to game the system and
> give themselves better latency, maybe at the cost of others. I think
Yes, you are right. One benefit of the ioctl change is to have a
per-device-option thus is more flexible.
> we're better off trying to infer the privilege from the task priority or
I'd think system admin may make decision after some tunning, like you said
it "maybe at the cost of others" and not sure if we should make decision
based on task priority or kernel config.
Thanks
--jyh
> kernel config or, if we run out of options, make a module option as you
> have here requiring the system admin to provide the privilege. Thanks,
>
> Alex
>
>
> > Signed-off-by: Yunhong Jiang
> > ---
> > drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
> > b/drivers/vfio/pci/vfio_pci_intrs.c
> > index 1f577b4..ca1f95a 100644
> > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > @@ -22,9 +22,13 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "vfio_pci_private.h"
> >
> > +static bool nonthread_msi = 1;
> > +module_param(nonthread_msi, bool, 0444);
> > +
> > /*
> > * INTx
> > */
> > @@ -313,6 +317,7 @@ static int vfio_msi_set_vector_signal(struct
> > vfio_pci_device *vdev,
> > char *name = msix ? "vfio-msix" : "vfio-msi";
> > struct eventfd_ctx *trigger;
> > int ret;
> > + unsigned long irqflags = 0;
> >
> > if (vector >= vdev->num_ctx)
> > return -EINVAL;
> > @@ -352,7 +357,10 @@ static int vfio_msi_set_vector_signal(struct
> > vfio_pci_device *vdev,
> > pci_write_msi_msg(irq, &msg);
> > }
> >
> > - ret = request_irq(irq, vfio_msihandler, 0,
> > + if (nonthread_msi)
> > + irqflags = IRQF_NO_THREAD;
> > +
> > + ret = request_irq(irq, vfio_msihandler, irqflags,
> > vdev->ctx[vector].name, trigger);
> > if (ret) {
> > kfree(vdev->ctx[vector].name);
>
>
>
--
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 V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling
于 2015/10/23 23:12, Peter Zijlstra 写道:
> On Fri, Oct 23, 2015 at 02:52:11PM +0200, Peter Zijlstra wrote:
>> On Thu, Oct 22, 2015 at 06:28:22PM +0800, Wangnan (F) wrote:
>>> information to analysis when glitch happen. Another way we are trying to
>>> implement
>>> now is to dynamically turn events on and off, or at least enable/disable
>>> sampling dynamically because the overhead of copying those samples
>>> is a big part of perf's total overhead. After that we can trace as many
>>> event as possible, but only fetch data from them when we detect a glitch.
>>
>> So why don't you 'fix' the flight recorder mode and just leave the data
>> in memory and not bother copying it out until a glitch happens?
>>
>> Something like this:
>>
>> lkml.kernel.org/r/20130708121557.ga17...@twins.programming.kicks-ass.net
>>
>> it appears we never quite finished that.
>
> Updated to current sources, compile tested only.
>
> It obviously needs testing and performance numbers.. and some
> userspace.
>
> ---
> Subject: perf: Update event buffer tail when overwriting old events
> From: Peter Zijlstra
>
>> From: "Yan, Zheng"
>>
>> If perf event buffer is in overwrite mode, the kernel only updates
>> the data head when it overwrites old samples. The program that owns
>> the buffer need periodically check the buffer and update a variable
>> that tracks the date tail. If the program fails to do this in time,
>> the data tail can be overwritted by new samples. The program has to
>> rewind the buffer because it does not know where is the first vaild
>> sample.
>>
>> This patch makes the kernel update the date tail when it overwrites
>> old events. So the program that owns the event buffer can always
>> read the latest samples. This is convenient for programs that use
>> perf to do branch tracing. One use case is GDB branch tracing:
>> (http://sourceware.org/ml/gdb-patches/2012-06/msg00172.html)
>> It uses perf interface to read BTS, but only cares the branches
>> before the ptrace event.
>
> Original-patch-by: "Yan, Zheng"
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/kernel/cpu/perf_event_intel_ds.c |2
> include/linux/perf_event.h|6 --
> kernel/events/core.c | 56 +
> kernel/events/internal.h |2
> kernel/events/ring_buffer.c | 77
> +-
> 5 files changed, 107 insertions(+), 36 deletions(-)
>
> --- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
> @@ -1140,7 +1140,7 @@ static void __intel_pmu_pebs_event(struc
>
> while (count > 1) {
> setup_pebs_sample_data(event, iregs, at, &data, ®s);
> - perf_event_output(event, &data, ®s);
> + event->overflow_handler(event, &data, ®s);
> at += x86_pmu.pebs_record_size;
> at = get_next_pebs_record_by_bit(at, top, bit);
> count--;
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -828,10 +828,6 @@ extern int perf_event_overflow(struct pe
>struct perf_sample_data *data,
>struct pt_regs *regs);
>
> -extern void perf_event_output(struct perf_event *event,
> - struct perf_sample_data *data,
> - struct pt_regs *regs);
> -
> extern void
> perf_event_header__init_id(struct perf_event_header *header,
> struct perf_sample_data *data,
> @@ -1032,6 +1028,8 @@ static inline bool has_aux(struct perf_e
>
> extern int perf_output_begin(struct perf_output_handle *handle,
>struct perf_event *event, unsigned int size);
> +extern int perf_output_begin_overwrite(struct perf_output_handle *handle,
> + struct perf_event *event, unsigned int size);
> extern void perf_output_end(struct perf_output_handle *handle);
> extern unsigned int perf_output_copy(struct perf_output_handle *handle,
>const void *buf, unsigned int len);
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4515,6 +4515,8 @@ static int perf_mmap_fault(struct vm_are
> return ret;
> }
>
> +static void perf_event_set_overflow(struct perf_event *event, struct
> ring_buffer *rb);
> +
> static void ring_buffer_attach(struct perf_event *event,
> struct ring_buffer *rb)
> {
> @@ -4546,6 +4548,8 @@ static void ring_buffer_attach(struct pe
> spin_lock_irqsave(&rb->event_lock, flags);
> list_add_rcu(&event->rb_entry, &rb->event_list);
> spin_unlock_irqrestore(&rb->event_lock, flags);
> +
> + perf_event_set_overflow(event, rb);
> }
>
> rcu_assign_pointer(event->rb, rb);
> @@ -5579,9 +5583,12 @@ void perf_prepare_sample(struct perf_eve
> }
> }
>
> -void perf_event_output(struct perf_event *event,
> -
Re: [PATCH v4 1/7] usb: gadget: f_midi: Transmit data only when IN ep is enabled
On 10/26/2015 11:49 PM, Felipe Tonello wrote:
> Hi Robert,
>
> On Mon, Oct 26, 2015 at 10:13 PM, Robert Baldyga
> wrote:
>> Hi Felipe,
>>
>> On 10/26/2015 05:55 PM, Felipe F. Tonello wrote:
>>> This makes sure f_midi doesn't try to enqueue data when the IN endpoint is
>>> disabled, ie, USB cable is disconnected.
>>>
>>> Signed-off-by: Felipe F. Tonello
>>> ---
>>> drivers/usb/gadget/function/f_midi.c | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/function/f_midi.c
>>> b/drivers/usb/gadget/function/f_midi.c
>>> index edb84ca..e08f365 100644
>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -87,6 +87,7 @@ struct f_midi {
>>> int index;
>>> char *id;
>>> unsigned int buflen, qlen;
>>> + bool in_ep_enabled;
>>
>> It's not necessary, you can use ep->enabled flag instead.
>
> There is no such flag in usb_ep struct[1].
>
> [1] http://lxr.free-electrons.com/source/include/linux/usb/gadget.h#L170
It's already in next branch of Felipe Balbi's tree.
Look here:
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/
Best regards,
Robert
>
>>
>>> };
>>>
>>> static inline struct f_midi *func_to_midi(struct usb_function *f)
>>> @@ -332,6 +333,7 @@ static int f_midi_set_alt(struct usb_function *f,
>>> unsigned intf, unsigned alt)
>>> err = f_midi_start_ep(midi, f, midi->in_ep);
>>> if (err)
>>> return err;
>>> + midi->in_ep_enabled = true;
>>>
>>> err = f_midi_start_ep(midi, f, midi->out_ep);
>>> if (err)
>>> @@ -387,6 +389,8 @@ static void f_midi_disable(struct usb_function *f)
>>>*/
>>> usb_ep_disable(midi->in_ep);
>>> usb_ep_disable(midi->out_ep);
>>> +
>>> + midi->in_ep_enabled = false;
>>> }
>>>
>>> static int f_midi_snd_free(struct snd_device *device)
>>> @@ -543,7 +547,7 @@ static void f_midi_transmit(struct f_midi *midi, struct
>>> usb_request *req)
>>> }
>>> }
>>>
>>> - if (req->length > 0) {
>>> + if (req->length > 0 && midi->in_ep_enabled) {
>>
>> You should rather test it at the beginning of this function. Or, even
>> better, when tasklet is scheduled, because tasklet is the only way this
>> function can be called when endpoints are disabled.
>
> Not in this case, because this function needs to consume the triggered
> data from ALSA, otherwise a timeout will happen (which is worse).
> Of course this is not the best solution, but it is an incremental improvement.
>
> Patch 7 has the proper solution, which checks this flag at the
> beginning of the function as expected. Also, it is more optimal
> because it drops all substreams buffers, instead of copying it.
>
>>
>>> int err;
>>>
>>> err = usb_ep_queue(ep, req, GFP_ATOMIC);
>>> @@ -1158,6 +1162,7 @@ static struct usb_function *f_midi_alloc(struct
>>> usb_function_instance *fi)
>>> midi->index = opts->index;
>>> midi->buflen = opts->buflen;
>>> midi->qlen = opts->qlen;
>>> + midi->in_ep_enabled = false;
>>> ++opts->refcnt;
>>> mutex_unlock(&opts->lock);
>>>
>>>
>>
>
> Felipe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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] libata: add support for NCQ commands for SG interface
On Tue, Oct 27, 2015 at 11:46 AM, Tejun Heo wrote: > On Tue, Oct 27, 2015 at 11:19:15AM +0530, vinayak.k...@gmail.com wrote: >> From: Vinayak Kale >> >> This patch is needed to make NCQ commands with FPDMA protocol value >> (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface. >> >> Signed-off-by: Vinayak Kale > > Applied to libata/for-4.4. Thanks Tejun :-) > > Thanks. > > -- > tejun -- 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 v12 4/6] QE/CPM: move muram management functions to qe_common
On Tue, Oct 27, 2015 at 12:48 PM, Wood Scott-B07421 wrote: > -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, October 27, 2015 12:48 PM > To: Zhao Qiang-B45475 > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > pau...@samba.org > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to > qe_common > > On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote: > > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote: > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Saturday, October 24, 2015 4:56 AM > > > To: Zhao Qiang-B45475 > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > > > pau...@samba.org > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management > functions > > > to qe_common > > > > > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote: > > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421 > > > > > > > > wrote: > > > > > -Original Message- > > > > > From: Wood Scott-B07421 > > > > > Sent: Friday, October 23, 2015 11:10 AM > > > > > To: Zhao Qiang-B45475 > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 > > > > > ; pau...@samba.org > > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management > > > functions > > > > > to qe_common > > > > > > > > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote: > > > > > > QE and CPM have the same muram, they use the same management > > > > > > functions. Now QE support both ARM and PowerPC, it is > > > > > > necessary to move QE to "driver/soc", so move the muram > > > > > > management functions from cpm_common to qe_common for > > > > > > preparing to move QE code to > > > "driver/soc" > > > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > > --- > > > > > > Changes for v2: > > > > > > - no changes > > > > > > Changes for v3: > > > > > > - no changes > > > > > > Changes for v4: > > > > > > - no changes > > > > > > Changes for v5: > > > > > > - no changes > > > > > > Changes for v6: > > > > > > - using genalloc instead rheap to manage QE MURAM > > > > > > - remove qe_reset from platform file, using > > > > > > - subsys_initcall to call qe_init function. > > > > > > Changes for v7: > > > > > > - move this patch from 3/3 to 2/3 > > > > > > - convert cpm with genalloc > > > > > > - check for gen_pool allocation failure Changes for v8: > > > > > > - rebase > > > > > > - move BD_SC_* macro instead of copy Changes for v9: > > > > > > - doesn't modify CPM, add a new patch to modify. > > > > > > - rebase > > > > > > Changes for v10: > > > > > > - rebase > > > > > > Changes for v11: > > > > > > - remove renaming > > > > > > - delete removing qe_reset and delete adding qe_init. > > > > > > Changes for v12: > > > > > > - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for > it. > > > > > > > > > > Why is the SPI change part of this patch? Why is it even part > > > > > of this patchset, rather than an independent patch sent to the > > > > > SPI list and maintainer? If it's tied to other changes you're > > > > > making, explain that. As is, there is zero mention of the SPI > > > > > change in the part of the e-mail that will become the git changelog. > > > > > > > > > This SPI_FSL_CPM is cpm-spi, it is part of CPM. > > > > > > So then why are you selecting QUICC_ENGINE? And again, what does it > > > have to do with this patch? > > > > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will > > failed to build. > > Why QUICC_ENGINE and not CPM? QE and CPM use the same muram, and it has been moved to qe_muram from cpm_muram. > > -Scott
[PATCH v3 01/10] mmc: core: Add DT bindings for eMMC hardware reset support
Sometime only need set MMC_CAP_HW_RESET for one of MMC hosts, So set it in device tree is better. Signed-off-by: Chaotian Jing --- Documentation/devicetree/bindings/mmc/mmc.txt | 1 + drivers/mmc/core/host.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 0384fc3..f693baf 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -37,6 +37,7 @@ Optional properties: - sd-uhs-sdr104: SD UHS SDR104 speed is supported - sd-uhs-ddr50: SD UHS DDR50 speed is supported - cap-power-off-card: powering off the card is safe +- cap-mmc-hw-reset: eMMC hardware reset is supported - cap-sdio-irq: enable SDIO IRQ signalling on this interface - full-pwr-cycle: full power cycle of the card is supported - mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index abd933b..04fdc2f 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -507,6 +507,8 @@ int mmc_of_parse(struct mmc_host *host) host->caps |= MMC_CAP_UHS_DDR50; if (of_property_read_bool(np, "cap-power-off-card")) host->caps |= MMC_CAP_POWER_OFF_CARD; + if (of_property_read_bool(np, "cap-mmc-hw-reset")) + host->caps |= MMC_CAP_HW_RESET; if (of_property_read_bool(np, "cap-sdio-irq")) host->caps |= MMC_CAP_SDIO_IRQ; if (of_property_read_bool(np, "full-pwr-cycle")) -- 1.8.1.1.dirty -- 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 04/10] mmc: mediatek: change the argument "ddr" to "timing"
use the ios->timing directly is better
It can reflect current timing and do settings by timing
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 8b3e15d..c877ded 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -297,7 +297,7 @@ struct msdc_host {
u32 mclk; /* mmc subsystem clock frequency */
u32 src_clk_freq; /* source clock frequency */
u32 sclk; /* SD/MS bus clock frequency */
- bool ddr;
+ unsigned char timing;
bool vqmmc_enabled;
struct msdc_save_para save_para; /* used when gate HCLK */
};
@@ -488,7 +488,7 @@ static void msdc_ungate_clock(struct msdc_host *host)
cpu_relax();
}
-static void msdc_set_mclk(struct msdc_host *host, int ddr, u32 hz)
+static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
{
u32 mode;
u32 flags;
@@ -504,7 +504,8 @@ static void msdc_set_mclk(struct msdc_host *host, int ddr,
u32 hz)
flags = readl(host->base + MSDC_INTEN);
sdr_clr_bits(host->base + MSDC_INTEN, flags);
- if (ddr) { /* may need to modify later */
+ if (timing == MMC_TIMING_UHS_DDR50 ||
+ timing == MMC_TIMING_MMC_DDR52) {
mode = 0x2; /* ddr mode and use divisor */
if (hz >= (host->src_clk_freq >> 2)) {
div = 0; /* mean div = 1/4 */
@@ -535,12 +536,12 @@ static void msdc_set_mclk(struct msdc_host *host, int
ddr, u32 hz)
cpu_relax();
host->sclk = sclk;
host->mclk = hz;
- host->ddr = ddr;
+ host->timing = timing;
/* need because clk changed. */
msdc_set_timeout(host, host->timeout_ns, host->timeout_clks);
sdr_set_bits(host->base + MSDC_INTEN, flags);
- dev_dbg(host->dev, "sclk: %d, ddr: %d\n", host->sclk, ddr);
+ dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
}
static inline u32 msdc_cmd_find_resp(struct msdc_host *host,
@@ -1158,14 +1159,9 @@ static void msdc_ops_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
{
struct msdc_host *host = mmc_priv(mmc);
int ret;
- u32 ddr = 0;
pm_runtime_get_sync(host->dev);
- if (ios->timing == MMC_TIMING_UHS_DDR50 ||
- ios->timing == MMC_TIMING_MMC_DDR52)
- ddr = 1;
-
msdc_set_buswidth(host, ios->bus_width);
/* Suspend/Resume will do power off/on */
@@ -1202,8 +1198,8 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
break;
}
- if (host->mclk != ios->clock || host->ddr != ddr)
- msdc_set_mclk(host, ddr, ios->clock);
+ if (host->mclk != ios->clock || host->timing != ios->timing)
+ msdc_set_mclk(host, ios->timing, ios->clock);
end:
pm_runtime_mark_last_busy(host->dev);
--
1.8.1.1.dirty
--
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 05/10] mmc: mediatek: fix got GPD checksum error interrupt when data transfer
Even if we only use one gpd, we need alloc 2 gpd and make the gpd->next pointer to the second gpd, or may get gpd checksum error, this was checked by hardware Signed-off-by: Chaotian Jing --- drivers/mmc/host/mtk-sd.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index c877ded..3858163 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -1145,11 +1145,14 @@ static void msdc_init_gpd_bd(struct msdc_host *host, struct msdc_dma *dma) struct mt_bdma_desc *bd = dma->bd; int i; - memset(gpd, 0, sizeof(struct mt_gpdma_desc)); + memset(gpd, 0, sizeof(struct mt_gpdma_desc) * 2); gpd->gpd_info = GPDMA_DESC_BDP; /* hwo, cs, bd pointer */ gpd->ptr = (u32)dma->bd_addr; /* physical address */ - + /* gpd->next is must set for desc DMA +* That's why must alloc 2 gpd structure. +*/ + gpd->next = (u32)dma->gpd_addr + sizeof(struct mt_gpdma_desc); memset(bd, 0, sizeof(struct mt_bdma_desc) * MAX_BD_NUM); for (i = 0; i < (MAX_BD_NUM - 1); i++) bd[i].next = (u32)dma->bd_addr + sizeof(*bd) * (i + 1); @@ -1306,7 +1309,7 @@ static int msdc_drv_probe(struct platform_device *pdev) host->timeout_clks = 3 * 1048576; host->dma.gpd = dma_alloc_coherent(&pdev->dev, - sizeof(struct mt_gpdma_desc), + 2 * sizeof(struct mt_gpdma_desc), &host->dma.gpd_addr, GFP_KERNEL); host->dma.bd = dma_alloc_coherent(&pdev->dev, MAX_BD_NUM * sizeof(struct mt_bdma_desc), @@ -1347,7 +1350,7 @@ release: release_mem: if (host->dma.gpd) dma_free_coherent(&pdev->dev, - sizeof(struct mt_gpdma_desc), + 2 * sizeof(struct mt_gpdma_desc), host->dma.gpd, host->dma.gpd_addr); if (host->dma.bd) dma_free_coherent(&pdev->dev, -- 1.8.1.1.dirty -- 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 06/10] mmc: mediatek: add implement of ops->hw_reset()
add implement of ops->hw_reset() for eMMC
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 3858163..5627644 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -64,6 +64,7 @@
#define SDC_RESP20x48
#define SDC_RESP30x4c
#define SDC_BLK_NUM 0x50
+#define EMMC_IOCON 0x7c
#define SDC_ACMD_RESP0x80
#define MSDC_DMA_SA 0x90
#define MSDC_DMA_CTRL0x98
@@ -1209,6 +1210,15 @@ end:
pm_runtime_put_autosuspend(host->dev);
}
+static void msdc_hw_reset(struct mmc_host *mmc)
+{
+ struct msdc_host *host = mmc_priv(mmc);
+
+ sdr_set_bits(host->base + EMMC_IOCON, 1);
+ udelay(10); /* 10us is enough */
+ sdr_clr_bits(host->base + EMMC_IOCON, 1);
+}
+
static struct mmc_host_ops mt_msdc_ops = {
.post_req = msdc_post_req,
.pre_req = msdc_pre_req,
@@ -1216,6 +1226,7 @@ static struct mmc_host_ops mt_msdc_ops = {
.set_ios = msdc_ops_set_ios,
.start_signal_voltage_switch = msdc_ops_switch_volt,
.card_busy = msdc_card_busy,
+ .hw_reset = msdc_hw_reset,
};
static int msdc_drv_probe(struct platform_device *pdev)
--
1.8.1.1.dirty
--
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 09/10] mmc: mediatek: add HS400 support
add HS400 mode and tune support
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 249 +-
1 file changed, 244 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 5627644..39568cc 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -72,6 +73,8 @@
#define MSDC_PATCH_BIT 0xb0
#define MSDC_PATCH_BIT1 0xb4
#define MSDC_PAD_TUNE0xec
+#define PAD_DS_TUNE 0x188
+#define EMMC50_CFG0 0x208
/*--*/
/* Register Mask*/
@@ -88,6 +91,7 @@
#define MSDC_CFG_CKSTB (0x1 << 7) /* R */
#define MSDC_CFG_CKDIV (0xff << 8)/* RW */
#define MSDC_CFG_CKMOD (0x3 << 16)/* RW */
+#define MSDC_CFG_HS400_CK_MODE (0x1 << 18)/* RW */
/* MSDC_IOCON mask */
#define MSDC_IOCON_SDR104CKS(0x1 << 0) /* RW */
@@ -205,6 +209,17 @@
#define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29) /* RW */
#define MSDC_PATCH_BIT_DECRCTMO (0x1 << 30) /* RW */
+#define MSDC_PAD_TUNE_DATRRDLY (0x1f << 8) /* RW */
+#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16) /* RW */
+
+#define PAD_DS_TUNE_DLY1 (0x1f << 2) /* RW */
+#define PAD_DS_TUNE_DLY2 (0x1f << 7) /* RW */
+#define PAD_DS_TUNE_DLY3 (0x1f << 12) /* RW */
+
+#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0) /* RW */
+#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3) /* RW */
+#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4) /* RW */
+
#define REQ_CMD_EIO (0x1 << 0)
#define REQ_CMD_TMO (0x1 << 1)
#define REQ_DAT_ERR (0x1 << 2)
@@ -220,6 +235,7 @@
#define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
#define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */
+#define PAD_DELAY_MAX 32 /* PAD delay cells */
/*--*/
/* Descriptor Structure */
/*--*/
@@ -266,6 +282,14 @@ struct msdc_save_para {
u32 pad_tune;
u32 patch_bit0;
u32 patch_bit1;
+ u32 pad_ds_tune;
+ u32 emmc50_cfg0;
+};
+
+struct msdc_delay_phase {
+ u8 maxlen;
+ u8 start;
+ u8 final_phase;
};
struct msdc_host {
@@ -300,6 +324,7 @@ struct msdc_host {
u32 sclk; /* SD/MS bus clock frequency */
unsigned char timing;
bool vqmmc_enabled;
+ u32 hs400_ds_delay;
struct msdc_save_para save_para; /* used when gate HCLK */
};
@@ -505,9 +530,15 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned
char timing, u32 hz)
flags = readl(host->base + MSDC_INTEN);
sdr_clr_bits(host->base + MSDC_INTEN, flags);
+ sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
if (timing == MMC_TIMING_UHS_DDR50 ||
- timing == MMC_TIMING_MMC_DDR52) {
- mode = 0x2; /* ddr mode and use divisor */
+ timing == MMC_TIMING_MMC_DDR52 ||
+ timing == MMC_TIMING_MMC_HS400) {
+ if (timing == MMC_TIMING_MMC_HS400)
+ mode = 0x3;
+ else
+ mode = 0x2; /* ddr mode and use divisor */
+
if (hz >= (host->src_clk_freq >> 2)) {
div = 0; /* mean div = 1/4 */
sclk = host->src_clk_freq >> 2; /* sclk = clk / 4 */
@@ -516,6 +547,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned
char timing, u32 hz)
sclk = (host->src_clk_freq >> 2) / div;
div = (div >> 1);
}
+
+ if (timing == MMC_TIMING_MMC_HS400 &&
+ hz >= (host->src_clk_freq >> 1)) {
+ sdr_set_bits(host->base + MSDC_CFG,
+MSDC_CFG_HS400_CK_MODE);
+ sclk = host->src_clk_freq >> 1;
+ div = 0; /* div is ignore when bit18 is set */
+ }
} else if (hz >= host->src_clk_freq) {
mode = 0x1; /* no divisor */
div = 0;
@@ -894,7 +933,7 @@ static void msdc_data_xfer_next(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_data *data)
{
if (mmc_op_multi(mrq->cmd->opcode) && mrq->stop && !mrq->stop->error &&
- (!data->bytes_xfered || !mrq->sbc))
+ !mrq->sbc)
msdc_start_command(host, mrq, mrq->stop);
else
msdc_request_done(host, mrq);
@@ -940,6 +979,8 @@ static bool msdc_data_xfer_done(struct msdc_host *host, u32
events,
if (events & MSDC_INT_DATTMO)
[PATCH v3 07/10] arm64: dts: mediatek: add eMMC hw reset support
Add eMMC hardware reset support Signed-off-by: Chaotian Jing --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index 4be66ca..6d79ffc 100644 --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts @@ -72,6 +72,7 @@ bus-width = <8>; max-frequency = <5000>; cap-mmc-highspeed; + cap-mmc-hw-reset; vmmc-supply = <&mt6397_vemc_3v3_reg>; vqmmc-supply = <&mt6397_vio18_reg>; non-removable; -- 1.8.1.1.dirty -- 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 10/10] arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support
add HS200/HS400 support for eMMC
add SDR50/SDR104 support for SD
Signed-off-by: Chaotian Jing
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 6d79ffc..a061221 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -70,11 +70,16 @@
pinctrl-0 = <&mmc0_pins_default>;
pinctrl-1 = <&mmc0_pins_uhs>;
bus-width = <8>;
- max-frequency = <5000>;
+ max-frequency = <2>;
cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
cap-mmc-hw-reset;
+ hs400-ds-delay = <0x14015>;
vmmc-supply = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
+ assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
non-removable;
};
@@ -84,9 +89,10 @@
pinctrl-0 = <&mmc1_pins_default>;
pinctrl-1 = <&mmc1_pins_uhs>;
bus-width = <4>;
- max-frequency = <5000>;
+ max-frequency = <2>;
cap-sd-highspeed;
- sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
cd-gpios = <&pio 132 0>;
vmmc-supply = <&mt6397_vmch_reg>;
vqmmc-supply = <&mt6397_vmc_reg>;
@@ -155,13 +161,19 @@
,
;
input-enable;
- drive-strength = ;
+ drive-strength = ;
bias-pull-up = ;
};
pins_clk {
pinmux = ;
- drive-strength = ;
+ drive-strength = ;
+ bias-pull-down = ;
+ };
+
+ pins_ds {
+ pinmux = ;
+ drive-strength = ;
bias-pull-down = ;
};
@@ -179,13 +191,13 @@
,
;
input-enable;
- drive-strength = ;
+ drive-strength = ;
bias-pull-up = ;
};
pins_clk {
pinmux = ;
- drive-strength = ;
+ drive-strength = ;
bias-pull-down = ;
};
};
--
1.8.1.1.dirty
--
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 03/10] mmc: mediatek: make cmd_ints_mask to const
cmd_ints_mask and data_ints_mask are constant value,
so make it to const
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2e89d3..8b3e15d 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -353,7 +353,10 @@ static void msdc_reset_hw(struct msdc_host *host)
static void msdc_cmd_next(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_command *cmd);
-static u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
+static const u32 cmd_ints_mask = MSDC_INTEN_CMDRDY | MSDC_INTEN_RSPCRCERR |
+ MSDC_INTEN_CMDTMO | MSDC_INTEN_ACMDRDY |
+ MSDC_INTEN_ACMDCRCERR | MSDC_INTEN_ACMDTMO;
+static const u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
MSDC_INTEN_DATCRCERR | MSDC_INTEN_DMA_BDCSERR |
MSDC_INTEN_DMA_GPDCSERR | MSDC_INTEN_DMA_PROTECT;
@@ -725,10 +728,7 @@ static bool msdc_cmd_done(struct msdc_host *host, int
events,
if (done)
return true;
- sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_CMDRDY |
- MSDC_INTEN_RSPCRCERR | MSDC_INTEN_CMDTMO |
- MSDC_INTEN_ACMDRDY | MSDC_INTEN_ACMDCRCERR |
- MSDC_INTEN_ACMDTMO);
+ sdr_clr_bits(host->base + MSDC_INTEN, cmd_ints_mask);
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136) {
@@ -818,10 +818,7 @@ static void msdc_start_command(struct msdc_host *host,
rawcmd = msdc_cmd_prepare_raw_cmd(host, mrq, cmd);
mod_delayed_work(system_wq, &host->req_timeout, DAT_TIMEOUT);
- sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_CMDRDY |
- MSDC_INTEN_RSPCRCERR | MSDC_INTEN_CMDTMO |
- MSDC_INTEN_ACMDRDY | MSDC_INTEN_ACMDCRCERR |
- MSDC_INTEN_ACMDTMO);
+ sdr_set_bits(host->base + MSDC_INTEN, cmd_ints_mask);
writel(cmd->arg, host->base + SDC_ARG);
writel(rawcmd, host->base + SDC_CMD);
}
--
1.8.1.1.dirty
--
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 02/10] mmc: dt-bindings: update Mediatek MMC bindings
Add 400Mhz clock source for HS400 mode
Signed-off-by: Chaotian Jing
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index a1adfa4..0120c7f 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -17,6 +17,11 @@ Required properties:
- vmmc-supply: power to the Core
- vqmmc-supply: power to the IO
+Optional properties:
+- assigned-clocks: PLL of the source clock
+- assigned-clock-parents: parent of source clock, used for HS400 mode to get
400Mhz source clock
+- hs400-ds-delay: HS400 DS delay setting
+
Examples:
mmc0: mmc@1123 {
compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
@@ -24,9 +29,13 @@ mmc0: mmc@1123 {
interrupts = ;
vmmc-supply = <&mt6397_vemc_3v3_reg>;
vqmmc-supply = <&mt6397_vio18_reg>;
- clocks = <&pericfg CLK_PERI_MSDC30_0>, <&topckgen
CLK_TOP_MSDC50_0_H_SEL>;
+ clocks = <&pericfg CLK_PERI_MSDC30_0>,
+<&topckgen CLK_TOP_MSDC50_0_H_SEL>;
clock-names = "source", "hclk";
pinctrl-names = "default", "state_uhs";
pinctrl-0 = <&mmc0_pins_default>;
pinctrl-1 = <&mmc0_pins_uhs>;
+ assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
+ hs400-ds-delay = <0x14015>;
};
--
1.8.1.1.dirty
--
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 08/10] mmc: mmc: extend the mmc_send_tuning()
The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.
in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.
Signed-off-by: Chaotian Jing
---
drivers/mmc/core/mmc_ops.c | 8
drivers/mmc/host/dw_mmc-exynos.c | 4 ++--
drivers/mmc/host/dw_mmc.c | 2 +-
drivers/mmc/host/dw_mmc.h | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 6 +++---
drivers/mmc/host/sdhci-msm.c | 2 +-
drivers/mmc/host/sdhci-sirf.c | 2 +-
include/linux/mmc/core.h | 2 +-
8 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 0e9ae1c..4305f75 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -589,7 +589,7 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8
value,
}
EXPORT_SYMBOL_GPL(mmc_switch);
-int mmc_send_tuning(struct mmc_host *host)
+int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error)
{
struct mmc_request mrq = {NULL};
struct mmc_command cmd = {0};
@@ -599,16 +599,13 @@ int mmc_send_tuning(struct mmc_host *host)
const u8 *tuning_block_pattern;
int size, err = 0;
u8 *data_buf;
- u32 opcode;
if (ios->bus_width == MMC_BUS_WIDTH_8) {
tuning_block_pattern = tuning_blk_pattern_8bit;
size = sizeof(tuning_blk_pattern_8bit);
- opcode = MMC_SEND_TUNING_BLOCK_HS200;
} else if (ios->bus_width == MMC_BUS_WIDTH_4) {
tuning_block_pattern = tuning_blk_pattern_4bit;
size = sizeof(tuning_blk_pattern_4bit);
- opcode = MMC_SEND_TUNING_BLOCK;
} else
return -EINVAL;
@@ -639,6 +636,9 @@ int mmc_send_tuning(struct mmc_host *host)
mmc_wait_for_req(host, &mrq);
+ if (cmd_error)
+ *cmd_error = cmd.error;
+
if (cmd.error) {
err = cmd.error;
goto out;
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 1e75309..3a7e835 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -446,7 +446,7 @@ out:
return loc;
}
-static int dw_mci_exynos_execute_tuning(struct dw_mci_slot *slot)
+static int dw_mci_exynos_execute_tuning(struct dw_mci_slot *slot, u32 opcode)
{
struct dw_mci *host = slot->host;
struct dw_mci_exynos_priv_data *priv = host->priv;
@@ -461,7 +461,7 @@ static int dw_mci_exynos_execute_tuning(struct dw_mci_slot
*slot)
mci_writel(host, TMOUT, ~0);
smpl = dw_mci_exynos_move_next_clksmpl(host);
- if (!mmc_send_tuning(mmc))
+ if (!mmc_send_tuning(mmc, opcode, NULL))
candiates |= (1 << smpl);
} while (start_smpl != smpl);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index fcbf552..be8441d 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1427,7 +1427,7 @@ static int dw_mci_execute_tuning(struct mmc_host *mmc,
u32 opcode)
int err = -EINVAL;
if (drv_data && drv_data->execute_tuning)
- err = drv_data->execute_tuning(slot);
+ err = drv_data->execute_tuning(slot, opcode);
return err;
}
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 8ce4674..394340f 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -281,7 +281,7 @@ struct dw_mci_drv_data {
void(*prepare_command)(struct dw_mci *host, u32 *cmdr);
void(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
int (*parse_dt)(struct dw_mci *host);
- int (*execute_tuning)(struct dw_mci_slot *slot);
+ int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode);
int (*prepare_hs400_tuning)(struct dw_mci *host,
struct mmc_ios *ios);
int (*switch_voltage)(struct mmc_host *mmc,
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 886d230..1f1582f 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -759,7 +759,7 @@ static int esdhc_executing_tuning(struct sdhci_host *host,
u32 opcode)
min = ESDHC_TUNE_CTRL_MIN;
while (min < ESDHC_TUNE_CTRL_MAX) {
esdhc_prepare_tuning(host, min);
- if (!mmc_send_tuning(host->mmc))
+ if (!mmc_send_tuning(host->mmc, opcode, NULL))
break;
min += ES
[PATCH v3 00/10] Add tune support of Mediatek MMC driver
Change in v3: Fix checkpatch errors and warnings for patch 8 Split patch 9, make DT parts enabling hw reset separately Change in v2: Drop the 400mhz and use assigned-clock-parents to instead Split the original tune patch to several independent patches Re-write the mmc_send_tuning() Fix GPD checksum error Move the HS400 setting to ops->prepare_hs400_tuning() Modify SD driving settings Change in v1: Add DT bindings for eMMC hardware reset Add pinctrl of data strobe pin for HS400 mode Modify eMMC driving settings Add 400mhz source clock for HS400 mode Add eMMC HS200/HS400 mode support Add SD SDR50/SDR104 mode support Add implement of tune function with CMD19/CMD21 Chaotian Jing (10): mmc: core: Add DT bindings for eMMC hardware reset support mmc: dt-bindings: update Mediatek MMC bindings mmc: mediatek: make cmd_ints_mask to const mmc: mediatek: change the argument "ddr" to "timing" mmc: mediatek: fix got GPD checksum error interrupt when data transfer mmc: mediatek: add implement of ops->hw_reset() arm64: dts: mediatek: add eMMC hw reset support mmc: mmc: extend the mmc_send_tuning() mmc: mediatek: add HS400 support arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support Documentation/devicetree/bindings/mmc/mmc.txt| 1 + Documentation/devicetree/bindings/mmc/mtk-sd.txt | 11 +- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 27 +- drivers/mmc/core/host.c | 2 + drivers/mmc/core/mmc_ops.c | 8 +- drivers/mmc/host/dw_mmc-exynos.c | 4 +- drivers/mmc/host/dw_mmc.c| 2 +- drivers/mmc/host/dw_mmc.h| 2 +- drivers/mmc/host/mtk-sd.c| 304 --- drivers/mmc/host/sdhci-esdhc-imx.c | 6 +- drivers/mmc/host/sdhci-msm.c | 2 +- drivers/mmc/host/sdhci-sirf.c| 2 +- include/linux/mmc/core.h | 2 +- 13 files changed, 322 insertions(+), 51 deletions(-) -- 1.8.1.1.dirty -- 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] regulator, dt: add dt support for tps6502x regulator
Hello Mark,
Am 27.10.2015 um 03:12 schrieb Mark Brown:
On Mon, Oct 26, 2015 at 12:25:17PM +0100, Heiko Schocher wrote:
add DT support for the tps6502x regulators.
Please use subject lines matching the style for the subsystem.
Would be "regulator: tps6520x:" correct?
+ regulators = of_get_child_by_name(np, "regulators");
+ if (!regulators) {
+ dev_err(dev, "regulator node not found\n");
+ return NULL;
+ }
Please use the generic support for locating the DT information for
regulators using regulators_node and of_match in the regulator_desc
rather than open coding this.
Hmm.. could you point me to a correct example? Seems I overlook sth.
drivers/regulator/tps65090-regulator.c
drivers/regulator/tps65910-regulator.c
drivers/regulator/tps6507x-regulator.c
drivers/regulator/tps6586x-regulator.c
are doing it all the same way ...
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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] regulator: tps65217: remove tps65217.dtsi file
Hello Keerthy,
Am 27.10.2015 um 07:06 schrieb Keerthy:
Hi Heiko,
On Monday 26 October 2015 02:43 PM, Heiko Schocher wrote:
remove tps65217.dtsi and adapt all boards, which
used it.
I boot tested this on am335x-bone and am335x-boneblack boards and could
successfully boot and i even
checked the regulators registered am335x-bone:
cat /sys/class/regulator/regulator.*/name
regulator-dummy
vmmcsd_fixed
DCDC1
DCDC2
DCDC3
LDO1
LDO2
LDO3
LDO4
Looks good to me. For am335x-bone and am335x-boneblack you can add
Tested-by: Keerthy
Thanks for testing!
bye,
Heiko
Best Regards,
Keerthy
Signed-off-by: Heiko Schocher
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581
.../devicetree/bindings/regulator/tps65217.txt | 78 --
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++-
arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
arch/arm/boot/dts/am335x-nano.dts | 14 +++-
arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
arch/arm/boot/dts/am335x-sl50.dts | 13 +++-
arch/arm/boot/dts/tps65217.dtsi| 56
7 files changed, 58 insertions(+), 145 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
delete mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
- after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
- initialization data for defined regulators. Not all regulators for the given
- device need to be present. The definition for each of these nodes is defined
- using the standard binding for regulators found at
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
- The valid names for regulators are:
- tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-tps: tps@24 {
-compatible = "ti,tps65217";
-ti,pmic-shutdown-controller;
-
-regulators {
-dcdc1_reg: dcdc1 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <180>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc2_reg: dcdc2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc3_reg: dcc3 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <150>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo1_reg: ldo1 {
-regulator-min-microvolt = <100>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo2_reg: ldo2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo3_reg: ldo3 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo4_reg: ldo4 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-};
-};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
};
};
-
-/include/ "tps65217.dtsi"
-
&tps {
+compatible = "ti,tps65217";
/*
* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
* mode") at poweroff. Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
ti,pmic-shutdown-controller;
regulators {
+#address-cells = <1>;
+#size-cells = <0>;
+
dcdc1_reg: regulator@0 {
+reg = <0>;
regulator-name = "vdds_dp
Re: Re: [PATCH v3 0/8] ftrace with regs + live patching for ppc64 LE (ABI v2)
Hi Torsten,
[auto build test ERROR on powerpc/next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Torsten-Duwe/Re-PATCH-v3-0-8-ftrace-with-regs-live-patching-for-ppc64-LE-ABI-v2/20151027-020058
config: powerpc-ppc6xx_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
kernel/built-in.o: In function `ftrace_get_addr_curr':
>> kernel/trace/ftrace.c:2286: undefined reference to `ftrace_regs_caller'
>> kernel/trace/ftrace.c:2286: undefined reference to `ftrace_regs_caller'
kernel/built-in.o: In function `ftrace_get_addr_new':
kernel/trace/ftrace.c:2254: undefined reference to `ftrace_regs_caller'
kernel/trace/ftrace.c:2254: undefined reference to `ftrace_regs_caller'
kernel/built-in.o: In function `__ftrace_replace_code':
>> kernel/trace/ftrace.c:2316: undefined reference to `ftrace_modify_call'
kernel/built-in.o: In function `ftrace_get_addr_curr':
>> kernel/trace/ftrace.c:2286: undefined reference to `ftrace_regs_caller'
>> kernel/trace/ftrace.c:2286: undefined reference to `ftrace_regs_caller'
kernel/built-in.o: In function `ftrace_get_addr_new':
kernel/trace/ftrace.c:2254: undefined reference to `ftrace_regs_caller'
kernel/trace/ftrace.c:2254: undefined reference to `ftrace_regs_caller'
kernel/built-in.o: In function `ftrace_get_addr_curr':
>> kernel/trace/ftrace.c:2286: undefined reference to `ftrace_regs_caller'
kernel/built-in.o:kernel/trace/ftrace.c:2286: more undefined references to
`ftrace_regs_caller' follow
vim +2286 kernel/trace/ftrace.c
79922b80 Steven Rostedt (Red Hat 2014-05-06 2280) return
(unsigned long)FTRACE_ADDR;
79922b80 Steven Rostedt (Red Hat 2014-05-06 2281) }
79922b80 Steven Rostedt (Red Hat 2014-05-06 2282) return
ops->trampoline;
79922b80 Steven Rostedt (Red Hat 2014-05-06 2283) }
79922b80 Steven Rostedt (Red Hat 2014-05-06 2284)
7413af1f Steven Rostedt (Red Hat 2014-05-06 2285) if (rec->flags &
FTRACE_FL_REGS_EN)
7413af1f Steven Rostedt (Red Hat 2014-05-06 @2286) return
(unsigned long)FTRACE_REGS_ADDR;
7413af1f Steven Rostedt (Red Hat 2014-05-06 2287) else
7413af1f Steven Rostedt (Red Hat 2014-05-06 2288) return
(unsigned long)FTRACE_ADDR;
7413af1f Steven Rostedt (Red Hat 2014-05-06 2289) }
7413af1f Steven Rostedt (Red Hat 2014-05-06 2290)
c88fd863 Steven Rostedt 2011-08-16 2291 static int
c88fd863 Steven Rostedt 2011-08-16 2292
__ftrace_replace_code(struct dyn_ftrace *rec, int enable)
c88fd863 Steven Rostedt 2011-08-16 2293 {
08f6fba5 Steven Rostedt 2012-04-30 2294 unsigned long
ftrace_old_addr;
c88fd863 Steven Rostedt 2011-08-16 2295 unsigned long
ftrace_addr;
c88fd863 Steven Rostedt 2011-08-16 2296 int ret;
c88fd863 Steven Rostedt 2011-08-16 2297
7c0868e0 Steven Rostedt (Red Hat 2014-05-08 2298) ftrace_addr =
ftrace_get_addr_new(rec);
c88fd863 Steven Rostedt 2011-08-16 2299
7c0868e0 Steven Rostedt (Red Hat 2014-05-08 2300) /* This needs to be
done before we call ftrace_update_record */
7c0868e0 Steven Rostedt (Red Hat 2014-05-08 2301) ftrace_old_addr =
ftrace_get_addr_curr(rec);
7c0868e0 Steven Rostedt (Red Hat 2014-05-08 2302)
7c0868e0 Steven Rostedt (Red Hat 2014-05-08 2303) ret =
ftrace_update_record(rec, enable);
08f6fba5 Steven Rostedt 2012-04-30 2304
c88fd863 Steven Rostedt 2011-08-16 2305 switch (ret) {
c88fd863 Steven Rostedt 2011-08-16 2306 case
FTRACE_UPDATE_IGNORE:
c88fd863 Steven Rostedt 2011-08-16 2307 return 0;
c88fd863 Steven Rostedt 2011-08-16 2308
c88fd863 Steven Rostedt 2011-08-16 2309 case
FTRACE_UPDATE_MAKE_CALL:
c88fd863 Steven Rostedt 2011-08-16 2310 return
ftrace_make_call(rec, ftrace_addr);
c88fd863 Steven Rostedt 2011-08-16 2311
c88fd863 Steven Rostedt 2011-08-16 2312 case
FTRACE_UPDATE_MAKE_NOP:
39b5552c Steven Rostedt (Red Hat 2014-08-17 2313) return
ftrace_make_nop(NULL, rec, ftrace_old_addr);
08f6fba5 Steven Rostedt 2012-04-30 2314
08f6fba5 Steven Rostedt 2012-04-30 2315 case
FTRACE_UPDATE_MODIFY_CALL:
08f6fba5 Steven Rostedt 2012-04-30 @2316 return
ftrace_modify_call(rec, ftrace_old_addr, ftrace_addr);
5072c59f Steven Rostedt 2008-05-12 2317 }
5072c59f Steven Rostedt 2008-05-12 2318
c88fd863 Steven Rostedt 2011-08-16 2319 return -1; /* unkn
Re: [PATCHv12 26/37] mm: rework mapcount accounting to enable 4k mapping of THPs
On Tue, Oct 06, 2015 at 06:23:53PM +0300, Kirill A. Shutemov wrote: > We're going to allow mapping of individual 4k pages of THP compound. > It means we need to track mapcount on per small page basis. > > Straight-forward approach is to use ->_mapcount in all subpages to track > how many time this subpage is mapped with PMDs or PTEs combined. But > this is rather expensive: mapping or unmapping of a THP page with PMD > would require HPAGE_PMD_NR atomic operations instead of single we have > now. > > The idea is to store separately how many times the page was mapped as > whole -- compound_mapcount. This frees up ->_mapcount in subpages to > track PTE mapcount. > > We use the same approach as with compound page destructor and compound > order to store compound_mapcount: use space in first tail page, > ->mapping this time. > > Any time we map/unmap whole compound page (THP or hugetlb) -- we > increment/decrement compound_mapcount. When we map part of compound page > with PTE we operate on ->_mapcount of the subpage. > > page_mapcount() counts both: PTE and PMD mappings of the page. > > Basically, we have mapcount for a subpage spread over two counters. > It makes tricky to detect when last mapcount for a page goes away. > > We introduced PageDoubleMap() for this. When we split THP PMD for the > first time and there's other PMD mapping left we offset up ->_mapcount > in all subpages by one and set PG_double_map on the compound page. > These additional references go away with last compound_mapcount. > > This approach provides a way to detect when last mapcount goes away on > per small page basis without introducing new overhead for most common > cases. > > Signed-off-by: Kirill A. Shutemov > Tested-by: Aneesh Kumar K.V > Acked-by: Jerome Marchand I found that recent mmotm hit the following BUG_ON() by reading /proc/kpageflags over pfn backed by a thp. [ 268.024519] page:ea00033e count:0 mapcount:0 mapping: (null) index:0x70200 [ 268.026076] flags: 0x4000() [ 268.026778] page dumped because: VM_BUG_ON_PAGE(!PageHead(page)) [ 268.027816] page->mem_cgroup:88021588cc00 [ 268.028638] [ cut here ] [ 268.029932] kernel BUG at /src/linux-dev/include/linux/page-flags.h:552! [ 268.031092] invalid opcode: [#1] SMP DEBUG_PAGEALLOC [ 268.032125] Modules linked in: cfg80211 rfkill crc32c_intel virtio_balloon serio_raw i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi [ 268.032598] CPU: 0 PID: 1183 Comm: page-types Not tainted 4.2.0-mmotm-2015-10-21-14-41-151027-1418-00014-41+ #179 [ 268.032598] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 268.032598] task: 880214a08bc0 ti: 880213e2c000 task.ti: 880213e2c000 [ 268.032598] RIP: 0010:[] [] stable_page_flags+0x336/0x340 [ 268.032598] RSP: 0018:880213e2fda8 EFLAGS: 00010292 [ 268.032598] RAX: 0021 RBX: 8802150a39c0 RCX: [ 268.032598] RDX: 88021ec0ff38 RSI: 88021ec0d658 RDI: 88021ec0d658 [ 268.032598] RBP: 880213e2fdc8 R08: 000a R09: 132f [ 268.032598] R10: R11: 132f R12: 4000 [ 268.032598] R13: ea00033e6340 R14: 7fff8449e430 R15: ea00033e6340 [ 268.032598] FS: 7ff7f9525700() GS:88021ec0() knlGS: [ 268.032598] CS: 0010 DS: ES: CR0: 80050033 [ 268.032598] CR2: 0063b800 CR3: d9e71000 CR4: 06f0 [ 268.032598] Stack: [ 268.032598] 8800db82df80 8802150a39c0 0008 000cf98d [ 268.032598] 880213e2fe18 81243588 7fff8449e430 880213e2ff20 [ 268.032598] 0063b800 8802150a39c0 fffb 880213e2ff20 [ 268.032598] Call Trace: [ 268.032598] [] kpageflags_read+0xc8/0x130 [ 268.032598] [] proc_reg_read+0x48/0x70 [ 268.032598] [] __vfs_read+0x28/0xd0 [ 268.032598] [] ? security_file_permission+0xae/0xc0 [ 268.032598] [] ? rw_verify_area+0x53/0xf0 [ 268.032598] [] vfs_read+0x8a/0x130 [ 268.032598] [] SyS_pread64+0x77/0x90 [ 268.032598] [] entry_SYSCALL_64_fastpath+0x12/0x6a [ 268.032598] Code: ca 00 00 40 01 48 39 c1 48 0f 44 da e9 a2 fd ff ff 48 c7 c6 50 a6 a1 8 1 e8 58 ab f4 ff 0f 0b 48 c7 c6 90 a2 a1 81 e8 4a ab f4 ff <0f> 0b 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 [ 268.032598] RIP [] stable_page_flags+0x336/0x340 [ 268.032598] RSP [ 268.070504] ---[ end trace e5d18553088c026a ]--- page_mapcount() could be called for a tail page, so VM_BUG_ON_PAGE(!PageHead()) in PageDoubleMap() introduced by this patch seems too strong restriction. Could you handle this? Thanks, Naoya Horiguchi-- 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-inf
Re: [PATCH v2] libata: add support for NCQ commands for SG interface
On Tue, Oct 27, 2015 at 11:19:15AM +0530, vinayak.k...@gmail.com wrote: > From: Vinayak Kale > > This patch is needed to make NCQ commands with FPDMA protocol value > (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface. > > Signed-off-by: Vinayak Kale Applied to libata/for-4.4. Thanks. -- tejun -- 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/3] sched: Implement interface for cgroup unified hierarchy
On Tue, 2015-10-27 at 15:00 +0900, Tejun Heo wrote: > On Tue, Oct 27, 2015 at 06:56:42AM +0100, Mike Galbraith wrote: > > > Well, if you think certain things are being missed, please speak up. > > > Not in some media campaign way but with technical reasoning and > > > justifications. > > > > Inserting a middle-man is extremely unlikely to improve performance. > > I'm not following you at all. Technical reasoning and justifications > is a middle-man? No, user <-> systemd or whatever <-> kernel ^^^ > I don't think anything productive is likely to come out of this > conversation. Let's just end this sub-thread. Agreed. -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] regulator: tps65217: remove tps65217.dtsi file
Hi Heiko,
On Monday 26 October 2015 02:43 PM, Heiko Schocher wrote:
remove tps65217.dtsi and adapt all boards, which
used it.
I boot tested this on am335x-bone and am335x-boneblack boards and could
successfully boot and i even checked the regulators registered am335x-bone:
cat /sys/class/regulator/regulator.*/name
regulator-dummy
vmmcsd_fixed
DCDC1
DCDC2
DCDC3
LDO1
LDO2
LDO3
LDO4
Looks good to me. For am335x-bone and am335x-boneblack you can add
Tested-by: Keerthy
Best Regards,
Keerthy
Signed-off-by: Heiko Schocher
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581
.../devicetree/bindings/regulator/tps65217.txt | 78 --
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++-
arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
arch/arm/boot/dts/am335x-nano.dts | 14 +++-
arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
arch/arm/boot/dts/am335x-sl50.dts | 13 +++-
arch/arm/boot/dts/tps65217.dtsi| 56
7 files changed, 58 insertions(+), 145 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
delete mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
- after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
- initialization data for defined regulators. Not all regulators for the given
- device need to be present. The definition for each of these nodes is defined
- using the standard binding for regulators found at
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
- The valid names for regulators are:
- tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
- tps: tps@24 {
- compatible = "ti,tps65217";
- ti,pmic-shutdown-controller;
-
- regulators {
- dcdc1_reg: dcdc1 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <180>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- dcdc2_reg: dcdc2 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- dcdc3_reg: dcc3 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <150>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: ldo1 {
- regulator-min-microvolt = <100>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo2_reg: ldo2 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo3_reg: ldo3 {
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo4_reg: ldo4 {
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-comm
Linux 4.2.4 Random ext4 corruption (thinks active inodes are deleted)
Same as before. Strange error with fuse trying to load (I think its related in some way with the writes being made to the /proc/sysrq), then strange errors. I am running on CENTOS 6.3 with 4.2.4 kernel. fsck cleans up the problem so its not a disk error, kernel error of some sort. Jeff Ebtables v2.0 registered fuse init (API version 7.23) blk_update_request: I/O error, dev fd0, sector 0 floppy: error -5 while reading block 0 blk_update_request: I/O error, dev fd0, sector 0 floppy: error -5 while reading block 0 perf interrupt took too long (2510 > 2500), lowering kernel.perf_event_max_sample_rate to 5 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300810 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300810 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300812 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300812 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300792 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300792 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300794 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300794 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300800 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300800 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300802 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300802 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300804 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300804 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300806 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300806 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300808 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300808 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300796 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300796 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300798 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300798 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300816 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300816 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300814 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300814 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300818 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300818 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300822 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300822 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300824 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300824 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300820 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300820 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300826 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300826 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300830 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300830 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300832 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300832 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300834 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300834 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300828 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300828 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300836 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300836 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300836 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300828 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300834 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300832 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300830 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300826 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300820 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300824 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300822 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300818 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300814 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300816 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300798 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300796 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300808 EXT2-fs (sdb3): error: ext2_lookup: deleted inode referenced: 2300806 EXT2-fs (sdb3): error: ext2_lookup: delete
Re: [PATCH v3 2/2] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller
> +
> +static struct ethtool_ops nb8800_ethtool_ops = {
Ops should be const
> + .get_settings = nb8800_get_settings,
> + .set_settings = nb8800_set_settings,
> + .nway_reset = nb8800_nway_reset,
> + .get_link = ethtool_op_get_link,
> +};
> +
Since you are implementing ethtool please add a driver
info function.
--
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/7 v2] powerpc/dma-mapping: override dma_get_page_shift
On 10/24/2015 07:57 AM, Nishanth Aravamudan wrote:
On Power, the kernel's page size can differ from the IOMMU's page size,
so we need to override the generic implementation, which always returns
the kernel's page size. Lookup the IOMMU's page size from struct
iommu_table, if available. Fallback to the kernel's page size,
otherwise.
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/include/asm/dma-mapping.h | 3 +++
arch/powerpc/kernel/dma.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 7f522c0..c5638f4 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -125,6 +125,9 @@ static inline void set_dma_offset(struct device *dev,
dma_addr_t off)
#define HAVE_ARCH_DMA_SET_MASK 1
extern int dma_set_mask(struct device *dev, u64 dma_mask);
+#define HAVE_ARCH_DMA_GET_PAGE_SHIFT 1
+extern unsigned long dma_get_page_shift(struct device *dev);
+
#include
extern int __dma_set_mask(struct device *dev, u64 dma_mask);
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 59503ed..e805af2 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -335,6 +335,15 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
}
EXPORT_SYMBOL(dma_set_mask);
+unsigned long dma_get_page_shift(struct device *dev)
+{
+ struct iommu_table *tbl = get_iommu_table_base(dev);
+ if (tbl)
+ return tbl->it_page_shift;
All PCI devices have this initialized on POWER (at least, our, IBM's POWER)
so 4K will always be returned here while in the case of
(get_dma_ops(dev)==&dma_direct_ops) it could actually return PAGE_SHIFT. Is
4K still preferred value to return here?
+ return PAGE_SHIFT;
+}
+EXPORT_SYMBOL(dma_get_page_shift);
+
u64 __dma_get_required_mask(struct device *dev)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
--
Alexey
--
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/3] sched: Implement interface for cgroup unified hierarchy
On Tue, Oct 27, 2015 at 06:56:42AM +0100, Mike Galbraith wrote: > > Well, if you think certain things are being missed, please speak up. > > Not in some media campaign way but with technical reasoning and > > justifications. > > Inserting a middle-man is extremely unlikely to improve performance. I'm not following you at all. Technical reasoning and justifications is a middle-man? I don't think anything productive is likely to come out of this conversation. Let's just end this sub-thread. Thanks. -- tejun -- 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/3] sched: Implement interface for cgroup unified hierarchy
On Tue, 2015-10-27 at 14:46 +0900, Tejun Heo wrote: > Hello, > > On Tue, Oct 27, 2015 at 06:42:11AM +0100, Mike Galbraith wrote: > > Sure, sounds fine, I just fervently hope that the below is foul swamp > > gas having nothing what so ever to do with your definition of "saner". > > lol, idk, you keep taking things in weird directions. Let's just stay > technical, okay? > > > http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign > > > > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > > > I'm not into begging. I really don't want to have to ask anyone to > > pretty please do for me what I can currently do all by my little self > > without having to give a rats ass less whether what I want to do fits in > > the world view of this or that obnoxious little control freak. > > Well, if you think certain things are being missed, please speak up. > Not in some media campaign way but with technical reasoning and > justifications. Inserting a middle-man is extremely unlikely to improve performance. -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 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift
On 10/24/2015 07:59 AM, Nishanth Aravamudan wrote:
When DDW (Dynamic DMA Windows) are present for a device, we have stored
the TCE (Translation Control Entry) size in a special device tree
property. Check if we have enabled DDW for the device and return the TCE
size from that property if present. If the property isn't present,
fallback to looking the value up in struct iommu_table. If we don't find
a iommu_table, fallback to the kernel's page size.
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/platforms/pseries/iommu.c | 36 ++
1 file changed, 36 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 0946b98..1bf6471 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1292,6 +1292,40 @@ static u64 dma_get_required_mask_pSeriesLP(struct device
*dev)
return dma_iommu_ops.get_required_mask(dev);
}
+static unsigned long dma_get_page_shift_pSeriesLP(struct device *dev)
+{
+ struct iommu_table *tbl;
+
+ if (!disable_ddw && dev_is_pci(dev)) {
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct device_node *dn;
+
+ dn = pci_device_to_OF_node(pdev);
+
+ /* search upwards for ibm,dma-window */
+ for (; dn && PCI_DN(dn) && !PCI_DN(dn)->table_group;
+ dn = dn->parent)
+ if (of_get_property(dn, "ibm,dma-window", NULL))
+ break;
+ /*
+* if there is a DDW configuration, the TCE shift is stored in
+* the property
+*/
+ if (dn && PCI_DN(dn)) {
+ const struct dynamic_dma_window_prop *direct64 =
+ of_get_property(dn, DIRECT64_PROPNAME, NULL);
This DIRECT64_PROPNAME property is only present under pHyp, QEMU/KVM does
not set it as 64bit windows are dynamic there so something like
find_existing_ddw() needs to be used here.
+ if (direct64)
+ return be32_to_cpu(direct64->tce_shift);
+ }
+ }
+
+ tbl = get_iommu_table_base(dev);
+ if (tbl)
+ return tbl->it_page_shift;
+
+ return PAGE_SHIFT;
+}
+
#else /* CONFIG_PCI */
#define pci_dma_bus_setup_pSeries NULL
#define pci_dma_dev_setup_pSeries NULL
@@ -1299,6 +1333,7 @@ static u64 dma_get_required_mask_pSeriesLP(struct device
*dev)
#define pci_dma_dev_setup_pSeriesLP NULL
#define dma_set_mask_pSeriesLPNULL
#define dma_get_required_mask_pSeriesLP NULL
+#define dma_get_page_shift_pSeriesLP NULL
#endif /* !CONFIG_PCI */
static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
@@ -1395,6 +1430,7 @@ void iommu_init_early_pSeries(void)
pseries_pci_controller_ops.dma_dev_setup =
pci_dma_dev_setup_pSeriesLP;
ppc_md.dma_set_mask = dma_set_mask_pSeriesLP;
ppc_md.dma_get_required_mask = dma_get_required_mask_pSeriesLP;
+ ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
} else {
pseries_pci_controller_ops.dma_bus_setup =
pci_dma_bus_setup_pSeries;
pseries_pci_controller_ops.dma_dev_setup =
pci_dma_dev_setup_pSeries;
--
Alexey
--
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] libata: add support for NCQ commands for SG interface
From: Vinayak Kale This patch is needed to make NCQ commands with FPDMA protocol value (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface. Signed-off-by: Vinayak Kale --- Changes in v2: - Decoupled tf->flags changes in ata_scsi_pass_thru() from this patch as per Tejun's suggestion. A separate patch will be sent for that change. drivers/ata/libata-scsi.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 0d7f0da..c2af592 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -2914,12 +2914,14 @@ ata_scsi_map_proto(u8 byte1) case 5: /* PIO Data-out */ return ATA_PROT_PIO; + case 12:/* FPDMA */ + return ATA_PROT_NCQ; + case 0: /* Hard Reset */ case 1: /* SRST */ case 8: /* Device Diagnostic */ case 9: /* Device Reset */ case 7: /* DMA Queued */ - case 12:/* FPDMA */ case 15:/* Return Response Info */ default:/* Reserved */ break; @@ -2992,6 +2994,10 @@ static unsigned int ata_scsi_pass_thru(struct ata_queued_cmd *qc) tf->command = cdb[9]; } + /* For NCQ commands with FPDMA protocol, copy the tag value */ + if (tf->protocol == ATA_PROT_NCQ) + tf->nsect = qc->tag << 3; + /* enforce correct master/slave bit */ tf->device = dev->devno ? tf->device | ATA_DEV1 : tf->device & ~ATA_DEV1; -- 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] iov: restore NumVFs register to 0 before return from virtfn_max_buses()
On 10/15/2015 10:16 AM, Bjorn Helgaas wrote:
Hi Ethan,
On Wed, Sep 16, 2015 at 12:19:53PM +0900, Ethan Zhao wrote:
After commit 4449f079722c ("PCI: Calculate maximum number of buses
required for VFs"),the initial value of NumVFs register was left to
non-zero after sriov_init() and no VFs was enabled in device driver.
this changed the behaviour of kernel exported by lspci and sysfs etc.
so this patch restore the NumVFs register to zero after the
calculation of max_VF_buses was done and before return from
virtfn_max_buses().
Tested on stable 4.1 and passed building on stable 4.3-rc1
Signed-off-by: Ethan Zhao
Tested-by: Sriharsha Yadagudde
Can you test the patch below? I'm trying to avoid touching
PCI_SRIOV_NUM_VF in more than one place, and I think it's OK to set it
and test offset/stride at the end, instead of setting NUM_VF to zero,
testing offset/stride, computing max_bus, then setting NUM_VF to zero
again.
Bjorn
commit 8e20e89658f23b8d16b1e21810e9f63c8625129c
Author: Bjorn Helgaas
Date: Thu Oct 15 11:31:21 2015 -0500
PCI: Set SR-IOV NumVFs to zero after enumeration
The enumeration path should leave NumVFs set to zero. But after
4449f079722c ("PCI: Calculate maximum number of buses required for VFs"),
we call virtfn_max_buses() in the enumeration path, which changes NumVFs.
This NumVFs change is visible via lspci and sysfs until a driver enables
SR-IOV.
Set NumVFs to zero after virtfn_max_buses() computes the maximum number of
buses.
Fixes: 4449f079722c ("PCI: Calculate maximum number of buses required for VFs")
Based-on-patch-by: Ethan Zhao
Signed-off-by: Bjorn Helgaas
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..0202ab0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -384,7 +384,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
int rc;
int nres;
u32 pgsz;
- u16 ctrl, total, offset, stride;
+ u16 ctrl, total;
struct pci_sriov *iov;
struct resource *res;
struct pci_dev *pdev;
@@ -414,11 +414,6 @@ static int sriov_init(struct pci_dev *dev, int pos)
found:
pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
- pci_write_config_word(dev, pos + PCI_SRIOV_NUM_VF, 0);
- pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, &offset);
- pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, &stride);
- if (!offset || (total > 1 && !stride))
- return -EIO;
pci_read_config_dword(dev, pos + PCI_SRIOV_SUP_PGSIZE, &pgsz);
i = PAGE_SHIFT > 12 ? PAGE_SHIFT - 12 : 0;
@@ -456,8 +451,6 @@ found:
iov->nres = nres;
iov->ctrl = ctrl;
iov->total_VFs = total;
- iov->offset = offset;
- iov->stride = stride;
iov->pgsz = pgsz;
iov->self = dev;
pci_read_config_dword(dev, pos + PCI_SRIOV_CAP, &iov->cap);
@@ -475,6 +468,11 @@ found:
dev->sriov = iov;
dev->is_physfn = 1;
iov->max_VF_buses = virtfn_max_buses(dev);
+ pci_iov_set_numvfs(dev, 0);
+ if (!iov->offset || (total > 1 && !iov->stride)) {
+ rc = -EIO;
+ goto failed;
+ }
return 0;
You might want to reorder this a bit. The problem is offset and stride
can be 0 if numvfs is 0. So you should probably test offset and stride
first, and then reset numvfs to 0.
- Alex
--
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/3] sched: Implement interface for cgroup unified hierarchy
Hello, On Tue, Oct 27, 2015 at 06:42:11AM +0100, Mike Galbraith wrote: > Sure, sounds fine, I just fervently hope that the below is foul swamp > gas having nothing what so ever to do with your definition of "saner". lol, idk, you keep taking things in weird directions. Let's just stay technical, okay? > http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign > > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > I'm not into begging. I really don't want to have to ask anyone to > pretty please do for me what I can currently do all by my little self > without having to give a rats ass less whether what I want to do fits in > the world view of this or that obnoxious little control freak. Well, if you think certain things are being missed, please speak up. Not in some media campaign way but with technical reasoning and justifications. Thanks. -- tejun -- 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/3] sched: Implement interface for cgroup unified hierarchy
On Tue, 2015-10-27 at 12:16 +0900, Tejun Heo wrote: > Hello, Mike. > > On Sun, Oct 25, 2015 at 04:43:33AM +0100, Mike Galbraith wrote: > > I don't think it's weird, it's just a thought wrt where pigeon holing > > could lead: If you filter out current users who do so in a manner you > > consider to be in some way odd, when all the filtering is done, you may > > find that you've filtered out the vast majority of current deployment. > > I think you misunderstood what I wrote. It's not about excluding > existing odd use cases. It's about examining the usages and > extracting the required capabilities and building an interface which > is well defined and blends well with the rest of programming interface > provided by the kernel so that those can be achieved in a saner way. Sure, sounds fine, I just fervently hope that the below is foul swamp gas having nothing what so ever to do with your definition of "saner". http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ I'm not into begging. I really don't want to have to ask anyone to pretty please do for me what I can currently do all by my little self without having to give a rats ass less whether what I want to do fits in the world view of this or that obnoxious little control freak. -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 4/5] staging: fsl-mc: bus rescan attribute to sync kernel with MC
On Sun, Oct 25, 2015 at 05:41:22PM -0500, Lijun Pan wrote:
> Introduce the rescan attribute as a bus attribute to
> synchronize the fsl-mc bus objects and the MC firmware.
>
> To rescan the fsl-mc bus, e.g.,
> echo 1 > /sys/bus/fsl-mc/rescan
>
> Signed-off-by: Lijun Pan
> ---
> drivers/staging/fsl-mc/bus/mc-bus.c | 46
> +
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
> b/drivers/staging/fsl-mc/bus/mc-bus.c
> index 33a56ad..f1baad7 100644
> --- a/drivers/staging/fsl-mc/bus/mc-bus.c
> +++ b/drivers/staging/fsl-mc/bus/mc-bus.c
> @@ -144,11 +144,57 @@ static const struct attribute_group
> *fsl_mc_dev_groups[] = {
> NULL,
> };
>
> +static int scan_fsl_mc_bus(struct device *dev, void *data)
> +{
> + struct fsl_mc_device *root_mc_dev;
> + struct fsl_mc_bus *root_mc_bus;
> +
> + if (is_root_dprc(dev)) {
> + root_mc_dev = to_fsl_mc_device(dev);
> + root_mc_bus = to_fsl_mc_bus(root_mc_dev);
> + mutex_lock(&root_mc_bus->scan_mutex);
> + dprc_scan_objects(root_mc_dev);
> + mutex_unlock(&root_mc_bus->scan_mutex);
> + }
> +
> + return 0;
> +}
> +
> +static ssize_t bus_rescan_store(struct bus_type *bus,
> + const char *buf, size_t count)
> +{
> + unsigned long val;
> +
> + if (kstrtoul(buf, 0, &val) < 0)
> + return -EINVAL;
> +
> + if (val)
> + bus_for_each_dev(bus, NULL, NULL, scan_fsl_mc_bus);
> +
> + return count;
> +}
> +static BUS_ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, bus_rescan_store);
> +
> +static struct attribute *fsl_mc_bus_attrs[] = {
> + &bus_attr_rescan.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group fsl_mc_bus_group = {
> + .attrs = fsl_mc_bus_attrs,
> +};
> +
> +static const struct attribute_group *fsl_mc_bus_groups[] = {
> + &fsl_mc_bus_group,
> + NULL,
> +};
> +
> struct bus_type fsl_mc_bus_type = {
> .name = "fsl-mc",
> .match = fsl_mc_bus_match,
> .uevent = fsl_mc_bus_uevent,
> .dev_groups = fsl_mc_dev_groups,
> + .bus_groups = fsl_mc_bus_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
No documentation update as well?
--
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/5] mfd: sec: Add support for S2MPS15 PMIC
Hello
On 10/26/2015 07:59 PM, Lee Jones wrote:
On Mon, 26 Oct 2015, Alim Akhtar wrote:
Hi Lee,
Thanks for looking into this.
On 10/26/2015 04:36 PM, Lee Jones wrote:
On Mon, 26 Oct 2015, Alim Akhtar wrote:
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 161 +++
4 files changed, 201 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
Why don't these have compatibles?
s2mps15-pmic does have compatible below in sec_dt_match[].
Woah!! What's going on here? You're matching the MFD and Regulator
drivers with the same compatible string. And then registering the
Regulator device as an MFD. That's a bit confusing don't you think?
Sorry for the confusion, as explained in the binding documentation,
S2MPS15 is a multi-function device which has rtc, regulator and clk
provider as a sub-blocks. And each of these sub-blocks are represented
as child node of parent MFD node. Out of these only clk controller child
node needs its own compatible string to populate of_node structure of
the device so that it can access properties of this sub-node in
drivers/clk/clk-s2mps11.c.
I just followed "Documentation/devicetree/bindings/mfd/s2mps11.txt"
to implement s2mps15.
s2mps15-rtc does not need one as rtc driver does not support OF yet.
So no DT node for this as of now.
[...]
--
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 tip/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()
On Tue, Oct 27, 2015 at 02:19:39PM +0900, Tejun Heo wrote:
> Hello,
>
> On Tue, Oct 27, 2015 at 12:37:16PM +0900, Linus Torvalds wrote:
> > > I believe that the above should instead be:
> > >
> > > struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,
>
> I should have just used list_entry() here. It's just offseting the
> pointer to set up the initial iteration point.
OK, that sounds much better!
> ...
> > That said, I'm not sure why it doesn't just do the normal
> >
> > rcu_read_lock();
> > list_for_each_entry_rcu(wb, &bdi->wb_list, bdi_node) {
> >
> > }
> > rcu_read_unlock();
> >
> > like the other places do. It looks like it wants that
> > "list_for_each_entry_continue_rcu()" because it does that odd "pin
> > entry and drop rcu lock and retake it and continue where you left
> > off", but I'm not sure why the continue version would be so
> > different.. It's going to do that "follow next entry" regardless, and
> > the "goto restart" doesn't look like it actually adds anything. If
> > following the next pointer is ok even after having released the RCU
> > read lock, then I'm not seeing why the end of the loop couldn't just
> > do
> >
> > rcu_read_unlock();
> > wb_wait_for_completion(bdi, &fallback_work_done);
> > rcu_read_lock();
> >
> > and just continue the loop (and the pinning of "wb" and releasing the
> > "last_wb" thing in the *next* iteration should make it all work the
> > same).
> >
> > Adding Tejun to the cc, because this is his code and there's probably
> > something subtle I'm missing. Tejun, can you take a look? It's
> > bdi_split_work_to_wbs() in fs/fs-writeback.c.
>
> Yeah, just releasing and regrabbing should work too as the iterator
> doesn't depend on anything other than the current entry (e.g. as
> opposed to imaginary list_for_each_entry_safe_rcu()). It's slightly
> icky to meddle with locking behind the iterator's back tho. Either
> way should be fine but how about something like the following?
>
> Subject: writeback: don't use list_entry_rcu() for pointer offsetting in
> bdi_split_work_to_wbs()
>
> bdi_split_work_to_wbs() uses list_for_each_entry_rcu_continue() to
> walk @bdi->wb_list. To set up the initial iteration condition, it
> uses list_entry_rcu() to calculate the entry pointer corresponding to
> the list head; however, this isn't an actual RCU dereference and using
> list_entry_rcu() for it ended up breaking a proposed list_entry_rcu()
> change because it was feeding an non-lvalue pointer into the macro.
>
> Don't use the RCU variant for simple pointer offsetting. Use
> list_entry() instead.
>
> Signed-off-by: Tejun Heo
Acked-by: Paul E. McKenney
> ---
> fs/fs-writeback.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 29e4599..7378169 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -779,8 +779,8 @@ static void bdi_split_work_to_wbs(struct backing_dev_info
> *bdi,
> bool skip_if_busy)
> {
> struct bdi_writeback *last_wb = NULL;
> - struct bdi_writeback *wb = list_entry_rcu(&bdi->wb_list,
> - struct bdi_writeback, bdi_node);
> + struct bdi_writeback *wb = list_entry(&bdi->wb_list,
> + struct bdi_writeback, bdi_node);
>
> might_sleep();
> restart:
>
--
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 tip/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()
On Tue, Oct 27, 2015 at 12:37:16PM +0900, Linus Torvalds wrote:
> On Mon, Oct 26, 2015 at 11:55 PM, Paul E. McKenney
> wrote:
> >> struct bdi_writeback *last_wb = NULL;
> >> struct bdi_writeback *wb = list_entry_rcu(&bdi->wb_list,
> >
> > I believe that the above should instead be:
> >
> > struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,
>
> I don't think you can do that.
>
> You haven't even taken the RCU read lock yet at this point.
>
> What the code seems to try to do is to get the "head pointer" of the
> list before taking the read lock (since _that_ is stable), and then
> follow the list under the lock.
>
> You're making it actually follow the first RCU pointer too early.
Good point, color me dazed and confused. :-/
Thanx, Paul
> That said, I'm not sure why it doesn't just do the normal
>
> rcu_read_lock();
> list_for_each_entry_rcu(wb, &bdi->wb_list, bdi_node) {
>
> }
> rcu_read_unlock();
>
> like the other places do. It looks like it wants that
> "list_for_each_entry_continue_rcu()" because it does that odd "pin
> entry and drop rcu lock and retake it and continue where you left
> off", but I'm not sure why the continue version would be so
> different.. It's going to do that "follow next entry" regardless, and
> the "goto restart" doesn't look like it actually adds anything. If
> following the next pointer is ok even after having released the RCU
> read lock, then I'm not seeing why the end of the loop couldn't just
> do
>
> rcu_read_unlock();
> wb_wait_for_completion(bdi, &fallback_work_done);
> rcu_read_lock();
>
> and just continue the loop (and the pinning of "wb" and releasing the
> "last_wb" thing in the *next* iteration should make it all work the
> same).
>
> Adding Tejun to the cc, because this is his code and there's probably
> something subtle I'm missing. Tejun, can you take a look? It's
> bdi_split_work_to_wbs() in fs/fs-writeback.c.
>
> Linus
>
--
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] dt-bindings: add document of mediatek efuse driver
On Mon, 2015-10-26 at 10:55 +, Srinivas Kandagatla wrote: > > On 26/10/15 10:23, Sascha Hauer wrote: > > On Mon, Oct 26, 2015 at 09:56:14AM +, Srinivas Kandagatla wrote: > >> > >> > >> On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote: > >>> From: Andrew-CT Chen > >>> > >>> Add Mediatek MT8173 EFUSE Devicetree binding file > >>> > >>> Signed-off-by: Andrew-CT Chen > >> > >> Looks good to me, minor comment below. > >> > >> Will queue this for v4.5 once v4.4-rc1 is released. > >> > >> > >>> --- > >>> .../devicetree/bindings/nvmem/mtk-efuse.txt| 36 > >>> ++ > >>> 1 file changed, 36 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt > >>> > >>> diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt > >>> b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt > >>> new file mode 100644 > >>> index 000..92edc3d > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt > >>> @@ -0,0 +1,36 @@ > >>> += Mediatek MTK-EFUSE device tree bindings = > >>> + > >>> +This binding is intended to represent MTK-EFUSE which is found in most > >>> Mediatek SOCs. > >>> + > >>> +Required properties: > >>> +- compatible: should be "mediatek,mt8173-efuse" or > >>> "mediatek,mt8135-efuse" > >> > >> Can we make the compatible more generic for mediatek socs? Like > >> "mediatek,efuse" Or are they different in each SOC? > > > > While we can add an additional "mediatek,efuse" compatible we should > > always add the most specific compatible first. Otherwise we cannot > > differentiate between SoCs later without changing the device tree. > Yes, that’s correct. > > AFAIK, Ideally the driver should have more generic compatible string > unless there is any SOC specific thing, and DT can still use the order > of specific, generic compatible strings. If not we would end up adding > compatible strings into the driver for every new SOC. We will modify for generic compatible string like "mediatek,efuse" and rebase it to v4.4-rc1. > > --srini > > > > > Sascha > > -- 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] nvmem: mediatek: Add Mediatek EFUSE driver
On Mon, 2015-10-26 at 09:56 +, Srinivas Kandagatla wrote:
> On 16/10/15 09:39, andrew-ct.c...@mediatek.com wrote:
> > From: Andrew-CT Chen
> >
> > Add Mediatek EFUSE driver to access hardware data like
> > thermal sensor calibration or HDMI impedance.
> >
> > Signed-off-by: Andrew-CT Chen
>
> Dirver looks pretty simple, below are few minor nits.
>
> Please rebase this patch on top of v4.4-rc1 once its released in few
> weeks, so that I can queue this driver for v4.5.
We will rebase it.
>
> > ---
> > drivers/nvmem/Kconfig | 11 ++
> > drivers/nvmem/Makefile| 1 +
> > drivers/nvmem/mtk-efuse.c | 89
> > +++
> > 3 files changed, 101 insertions(+)
> > create mode 100644 drivers/nvmem/mtk-efuse.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > index 8db2978..1bd5badc 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -14,6 +14,17 @@ menuconfig NVMEM
> >
> > if NVMEM
> >
> > +config MTK_EFUSE
> > + tristate "Mediatek SoCs EFUSE support"
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> > + select REGMAP_MMIO
> > + help
> > + This is a driver to access hardware related data like sensor
> > + calibration, HDMI impedance etc.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called efuse-mtk.
> > +
> > config QCOM_QFPROM
> > tristate "QCOM QFPROM Support"
> > depends on ARCH_QCOM || COMPILE_TEST
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index 4328b93..916b727 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_NVMEM) += nvmem_core.o
> > nvmem_core-y := core.o
> >
> > # Devices
> > +obj-$(CONFIG_MTK_EFUSE)+= mtk-efuse.o
>
> For consistency reasons, could you do this similar to other drivers.
>
> > obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
> > nvmem_qfprom-y:= qfprom.o
> > obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
> > diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> > new file mode 100644
> > index 000..9021c0b
> > --- /dev/null
> > +++ b/drivers/nvmem/mtk-efuse.c
> > @@ -0,0 +1,89 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Andrew-CT Chen
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static struct regmap_config mtk_regmap_config = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > +};
> > +
> > +static int mtk_efuse_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct resource *res;
> > + struct nvmem_device *nvmem;
> > + struct nvmem_config *econfig;
> > + struct regmap *regmap;
> > + void __iomem *base;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(base))
> > + return PTR_ERR(base);
> > +
> > + econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
> > + if (!econfig)
> > + return -ENOMEM;
> Why not use static econfig variable?
>
> > +
> > + mtk_regmap_config.max_register = resource_size(res) - 1;
> > +
> > + regmap = devm_regmap_init_mmio(dev, base, &mtk_regmap_config);
> > + if (IS_ERR(regmap)) {
> > + dev_err(dev, "regmap init failed\n");
> > + return PTR_ERR(regmap);
> > + }
> > +
> > + econfig->dev = dev;
> > + econfig->owner = THIS_MODULE;
> > + nvmem = nvmem_register(econfig);
> > + if (IS_ERR(nvmem))
> > + return PTR_ERR(nvmem);
> > +
> > + platform_set_drvdata(pdev, nvmem);
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_efuse_remove(struct platform_device *pdev)
> > +{
> > + struct nvmem_device *nvmem = platform_get_drvdata(pdev);
> > +
> > + return nvmem_unregister(nvmem);
> > +}
> > +
> > +static const struct of_device_id mtk_efuse_of_match[] = {
> > + { .compatible = "mediatek,mt8135-efuse",},
> > + { .compatible = "mediatek,mt8173-efuse",},
> > + {/* sentinel */},
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_efuse_of_match);
> > +
> > +static struct platform_driver mtk_efuse_driver = {
> > + .probe = mtk_efuse_probe,
> > + .remove = mtk_efuse_remove,
> > + .driver = {
> > + .name = "mediatek,efuse",
> > + .of_match_table = mtk_efuse_of_match,
> > + },
> > +};
> > +module_platfo
Re: [PATCH] clk: qcom: msm8960: Fix dsi1/2 halt bits
On 10/27/2015 06:53 AM, Stephen Boyd wrote:
The halt bits for these clocks seem wrong. I get the following
warning while booting on an msm8960-cdp:
WARNING: CPU: 0 PID: 1 at drivers/clk/qcom/clk-branch.c:97
clk_branch_toggle+0xd0/0x138()
dsi1_clk status stuck at 'on'
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc3-00113-g5532cfb567fe #110
Hardware name: Qualcomm (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4)
[] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from []
(clk_branch_toggle+0xd0/0x138)
[] (clk_branch_toggle) from []
(clk_disable_unused_subtree+0x98/0x1b0)
[] (clk_disable_unused_subtree) from []
(clk_disable_unused_subtree+0x20/0x1b0)
[] (clk_disable_unused_subtree) from []
(clk_disable_unused+0x58/0xd8)
[] (clk_disable_unused) from [] (do_one_initcall+0xac/0x1ec)
[] (do_one_initcall) from []
(kernel_init_freeable+0x11c/0x1e8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Fix the status bits and the errors go away.
Fixes: 5532cfb567fe ("clk: qcom: mmcc-8960: Add DSI related clocks")
Cc: Archit Taneja
Signed-off-by: Stephen Boyd
---
Acked-by: Archit Taneja
--
The Qualcomm Innovation Center, Inc. is a member of the 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: [PATCH] Staging: wilc1000: Fix warning prefer eth_broadcast_addr over memset()
On Tue, Oct 27, 2015 at 01:21:46AM +0530, Punit Vara wrote: > This patch is to the host_interface.c that fixes up following > warning by checkpatch.pl: > > -Prefer eth_broadcast_addr() over memset() > > Signed-off-by: Punit Vara > --- > drivers/staging/wilc1000/host_interface.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/wilc1000/host_interface.c > b/drivers/staging/wilc1000/host_interface.c > index 09a6c98..87b4eb8 100644 > --- a/drivers/staging/wilc1000/host_interface.c > +++ b/drivers/staging/wilc1000/host_interface.c > @@ -4688,7 +4688,7 @@ s32 host_int_del_station(struct host_if_drv *hif_drv, > const u8 *pu8MacAddr) > msg.drv = hif_drv; > > if (pu8MacAddr == NULL) > - memset(pstrDelStationMsg->mac_addr, 255, ETH_ALEN); > + eth_broadcast_addr(pstrDelStationMsg->mac_addr); > else > memcpy(pstrDelStationMsg->mac_addr, pu8MacAddr, ETH_ALEN); > Doesn't apply to my staging.git tree at all :( -- 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 tip/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()
Hello,
On Tue, Oct 27, 2015 at 12:37:16PM +0900, Linus Torvalds wrote:
> > I believe that the above should instead be:
> >
> > struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,
I should have just used list_entry() here. It's just offseting the
pointer to set up the initial iteration point.
...
> That said, I'm not sure why it doesn't just do the normal
>
> rcu_read_lock();
> list_for_each_entry_rcu(wb, &bdi->wb_list, bdi_node) {
>
> }
> rcu_read_unlock();
>
> like the other places do. It looks like it wants that
> "list_for_each_entry_continue_rcu()" because it does that odd "pin
> entry and drop rcu lock and retake it and continue where you left
> off", but I'm not sure why the continue version would be so
> different.. It's going to do that "follow next entry" regardless, and
> the "goto restart" doesn't look like it actually adds anything. If
> following the next pointer is ok even after having released the RCU
> read lock, then I'm not seeing why the end of the loop couldn't just
> do
>
> rcu_read_unlock();
> wb_wait_for_completion(bdi, &fallback_work_done);
> rcu_read_lock();
>
> and just continue the loop (and the pinning of "wb" and releasing the
> "last_wb" thing in the *next* iteration should make it all work the
> same).
>
> Adding Tejun to the cc, because this is his code and there's probably
> something subtle I'm missing. Tejun, can you take a look? It's
> bdi_split_work_to_wbs() in fs/fs-writeback.c.
Yeah, just releasing and regrabbing should work too as the iterator
doesn't depend on anything other than the current entry (e.g. as
opposed to imaginary list_for_each_entry_safe_rcu()). It's slightly
icky to meddle with locking behind the iterator's back tho. Either
way should be fine but how about something like the following?
Subject: writeback: don't use list_entry_rcu() for pointer offsetting in
bdi_split_work_to_wbs()
bdi_split_work_to_wbs() uses list_for_each_entry_rcu_continue() to
walk @bdi->wb_list. To set up the initial iteration condition, it
uses list_entry_rcu() to calculate the entry pointer corresponding to
the list head; however, this isn't an actual RCU dereference and using
list_entry_rcu() for it ended up breaking a proposed list_entry_rcu()
change because it was feeding an non-lvalue pointer into the macro.
Don't use the RCU variant for simple pointer offsetting. Use
list_entry() instead.
Signed-off-by: Tejun Heo
---
fs/fs-writeback.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 29e4599..7378169 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -779,8 +779,8 @@ static void bdi_split_work_to_wbs(struct backing_dev_info
*bdi,
bool skip_if_busy)
{
struct bdi_writeback *last_wb = NULL;
- struct bdi_writeback *wb = list_entry_rcu(&bdi->wb_list,
- struct bdi_writeback, bdi_node);
+ struct bdi_writeback *wb = list_entry(&bdi->wb_list,
+ struct bdi_writeback, bdi_node);
might_sleep();
restart:
--
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 5/5] staging: fsl-mc: Management Complex restool driver
On Sun, 2015-10-25 at 17:41 -0500, Lijun Pan wrote: > The kernel support for the restool (a user space resource management > tool) is a driver for the /dev/dprc.N device file. > Its purpose is to provide an ioctl interface, > which the restool uses to interact with the MC bus driver > and with the MC firmware. > We allocate a dpmcp at driver initialization, > and keep that dpmcp until driver exit. > We use that dpmcp by default. > If that dpmcp is in use, we create another portal at run time > and destroy the newly created portal after use. > The ioctl RESTOOL_SEND_MC_COMMAND sends user space command to fsl-mc > bus and utilizes the fsl-mc bus to communicate with MC firmware. > The ioctl RESTOOL_DPRC_SYNC request the mc-bus launch > objects scan under root dprc. > In order to support multiple root dprc, we utilize the bus notify > mechanism to scan fsl_mc_bus_type for the newly added root dprc. > After discovering the root dprc, it creates a miscdevice > /dev/dprc.N to associate with this root dprc. > > Signed-off-by: Lijun Pan > --- > drivers/staging/fsl-mc/bus/Kconfig | 7 +- > drivers/staging/fsl-mc/bus/Makefile | 3 + > drivers/staging/fsl-mc/bus/mc-ioctl.h | 24 ++ > drivers/staging/fsl-mc/bus/mc-restool.c | 488 > > 4 files changed, 521 insertions(+), 1 deletion(-) > create mode 100644 drivers/staging/fsl-mc/bus/mc-ioctl.h > create mode 100644 drivers/staging/fsl-mc/bus/mc-restool.c > > diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl- > mc/bus/Kconfig > index 0d779d9..39c6ef9 100644 > --- a/drivers/staging/fsl-mc/bus/Kconfig > +++ b/drivers/staging/fsl-mc/bus/Kconfig > @@ -21,4 +21,9 @@ config FSL_MC_BUS > Only enable this option when building the kernel for > Freescale QorQIQ LS2 SoCs. > > - > +config FSL_MC_RESTOOL > +tristate "Freescale Management Complex (MC) restool driver" > +depends on FSL_MC_BUS > +help > + Driver that provides kernel support for the Freescale Management > + Complex resource manager user-space tool. > diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl- > mc/bus/Makefile > index 25433a9..28b5fc0 100644 > --- a/drivers/staging/fsl-mc/bus/Makefile > +++ b/drivers/staging/fsl-mc/bus/Makefile > @@ -15,3 +15,6 @@ mc-bus-driver-objs := mc-bus.o \ > mc-allocator.o \ > dpmcp.o \ > dpbp.o > + > +# MC restool kernel support > +obj-$(CONFIG_FSL_MC_RESTOOL) += mc-restool.o > diff --git a/drivers/staging/fsl-mc/bus/mc-ioctl.h b/drivers/staging/fsl- > mc/bus/mc-ioctl.h > new file mode 100644 > index 000..e52f907 > --- /dev/null > +++ b/drivers/staging/fsl-mc/bus/mc-ioctl.h > @@ -0,0 +1,24 @@ > +/* > + * Freescale Management Complex (MC) ioclt interface ioctl > + * > + * Copyright (C) 2014 Freescale Semiconductor, Inc. > + * Author: Lijun Pan > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > +#ifndef _FSL_MC_IOCTL_H_ > +#define _FSL_MC_IOCTL_H_ > + > +#include > + > +#define RESTOOL_IOCTL_TYPE 'R' > + > +#define RESTOOL_DPRC_SYNC \ > + _IO(RESTOOL_IOCTL_TYPE, 0x2) > + > +#define RESTOOL_SEND_MC_COMMAND \ > + _IOWR(RESTOOL_IOCTL_TYPE, 0x4, struct mc_command) Look at Documentation/ioctl/ioctl-number.txt and reserve a range within 'R' that doesn't conflict. Add thorough documentation of this API. I'm not sure how it's usually handled with staging drivers, but eventually this will need to move to an appropriate uapi header. Is this functionality even needed before the driver comes out of staging? I don't see "userspace restool support" in drivers/staging/fsl-mc/TODO. Don't reference struct mc_command without including the header that defines it. > +#endif /* _FSL_MC_IOCTL_H_ */ > diff --git a/drivers/staging/fsl-mc/bus/mc-restool.c b/drivers/staging/fsl- > mc/bus/mc-restool.c > new file mode 100644 > index 000..a219172 > --- /dev/null > +++ b/drivers/staging/fsl-mc/bus/mc-restool.c > @@ -0,0 +1,488 @@ > +/* > + * Freescale Management Complex (MC) restool driver > + * > + * Copyright (C) 2014 Freescale Semiconductor, Inc. > + * Author: Lijun Pan > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +#include "../include/mc-private.h" > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "mc-ioctl.h" > +#include "../include/mc-sys.h" > +#include "../include/mc-cmd.h" > +#include "../include/dpmng.h" > + > +/** > + * Maximum number of DPRCs that can be opened at the same time > + */ > +#define MAX_DPRC_HANDLES 64 > + > +/** > + * restool_misc - information associ
Guten Tag.
Guten Tag, Ich brauche einen ausländischen Partner für einen gemeinsamen Geschäfts Vorschlag, der auf die Übertragung von einer großen Geldsumme an einem ausländischen Konto bezieht, als Empfänger der Mittel. Alles an dieser Transaktion rechtlich ohne Brücke der Finanzbehörde sowohl in meinem Land und yours.I wil gönnen Sie höchste Diskretion in allen Fragen rund um dieses Problem zu beobachten, durchgeführt werden. Wenn Sie interessiert sind, antworten Sie bitte zurück über meine private E-Mail-Adresse unten geschrieben, gebe ich Ihnen mehr über mich selbst mit dem Finanzinstitut I dargestellt und tatsächlichen Beträge beinhaltet zum Projekt, sobald ich Ihre positive Antwort erhalten. Private E-Mail: fu.zh...@fuzhongjun.net Freundlichen Gruß, Geschäftsführer. China-Bank. -- 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] get_maintainer: Don't fallback to git by default
On 10/26/15 9:57 PM, j...@perches.com wrote: On 2015-10-26 19:47, Theodore Ts'o wrote: What if we have a git_fallback "auto" mode which only falls back to using git if there is no entry in the MAINTAINERS file? That might address the concern which Laura raised, without blocking this change until the MAINTAINERS file is fully populated. That's what happens already right now. Not with the change proposed though -- 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] get_maintainer: Don't fallback to git by default
On 2015-10-26 19:47, Theodore Ts'o wrote: What if we have a git_fallback "auto" mode which only falls back to using git if there is no entry in the MAINTAINERS file? That might address the concern which Laura raised, without blocking this change until the MAINTAINERS file is fully populated. That's what happens already right now. -- 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 0/5] crypto: add algif_akcipher user space API
Hi Stephan, > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. > > The patch set is tested with the user space library of libkcapi [1]. > Use [1] test/test.sh for a full test run. The test covers the > following scenarios: > > * sendmsg of one IOVEC > > * sendmsg of 16 IOVECs with non-linear buffer > > * vmsplice of one IOVEC > > * vmsplice of 15 IOVECs with non-linear buffer > > * invoking multiple separate cipher operations with one > open cipher handle > > * encryption with private key (using vector from testmgr.h) > > * encryption with public key (using vector from testmgr.h) > > * decryption with private key (using vector from testmgr.h) after having discussions with David Howells and David Woodhouse, I don't think we should expose akcipher via AF_ALG at all. I think the akcipher operations for sign/verify/encrypt/decrypt should operate on asymmetric keys in the first place. With akcipher you are pretty much bound to public and private keys and the key is the important part and not the akcipher itself. Especially since we want to support private keys in hardware (like TPM for example). It seems more appropriate to use keyctl to derive the symmetric session key from your asymmetric key. And then use the symmetric session key id with skcipher via AF_ALG. Especially once symmetric key type has been introduced this seems to be trivial then. I am not really in favor of having two userspace facing APIs for asymmetric cipher usage. And we need to have an API that is capable to work with hardware keys. 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 0/8] add missing of_node_put
From: Julia Lawall Date: Sun, 25 Oct 2015 14:56:59 +0100 > The various for_each device_node iterators performs an of_node_get on each > iteration, so a break out of the loop requires an of_node_put. > > The complete semantic patch that fixes this problem is > (http://coccinelle.lip6.fr): ... Series applied, thanks a lot Julia. -- 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 v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram
On Sun, 2015-10-25 at 22:15 -0500, Zhao Qiang-B45475 wrote:
> On Sat, 2015-10-24 at 04:59 AM, Wood Scott-B07421
> wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Saturday, October 24, 2015 4:59 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > pau...@samba.org
> > Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram
> >
> > Don't send HTML e-mail.
> >
> > On Fri, 2015-10-23 at 02:06 -0500, Zhao Qiang-B45475 wrote:
> > > On Fri, 2015-10-23 at 11:00 AM, Wood Scott-B07421
> > >
> > > wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, October 23, 2015 11:00 AM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > > pau...@samba.org
> > > > Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE
> > > > muram
> > > >
> > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > > -/**
> > > > > +/*
> > > > > * cpm_muram_alloc - allocate the requested size worth of
> > > > > multi-user
> > > ram
> > > > > * @size: number of bytes to allocate
> > > > > * @align: requested alignment, in bytes @@ -141,59 +151,102 @@
> > > > > out:
> > > > > */
> > > > > unsigned long cpm_muram_alloc(unsigned long size, unsigned long
> > > > > align) {
> > > > > - unsigned long start;
> > > > > unsigned long flags;
> > > > > -
> > > > > + unsigned long start;
> > > > > + static struct genpool_data_align muram_pool_data;
> > > > > spin_lock_irqsave(&cpm_muram_lock, flags);
> > > > > - cpm_muram_info.alignment = align;
> > > > > - start = rh_alloc(&cpm_muram_info, size, "commproc");
> > > > > - memset(cpm_muram_addr(start), 0, size);
> > > > > + muram_pool_data.align = align;
> > > > > + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> > > > > + &muram_pool_data);
> > > > > + start = cpm_muram_alloc_common(size, &muram_pool_data);
> > > > > spin_unlock_irqrestore(&cpm_muram_lock, flags);
> > > > > -
> > > > > return start;
> > > > > }
> > > > > EXPORT_SYMBOL(cpm_muram_alloc);
> > > >
> > > > Why is muram_pool_data static? Why is it being passed to
> > > > gen_pool_set_algo()?
> > > Cpm_muram use both align algo and fixed algo, so we need to set
> > > corresponding algo and Algo data.
> >
> > The data gets passed in via gen_pool_alloc_data(). The point was to
> > allow it to
> > be on the caller's stack, not a long-lived data structure shared by all
> > callers and
> > needing synchronization.
>
> You mean it is not necessary to point pool->data to data, just passing the
> data to gen_pool_alloc_data()?
> However, the algo it needed to be set.
>
> >
> > > > The whole reason we're adding gen_pool_alloc_data() is to avoid
> > > > that. Do we need gen_pool_alloc_algo() too?
> > >
> > > We add gen_pool_alloc_data() to pass data to algo, because align algo
> > > and fixed algo, Because align and fixed algos need specific data.
> >
> > And my point is that because of that, it seems like we need a version that
> > accepts an algorithm as well.
>
> It the user just use only one algo, it doesn’t need to set algo,
> However, qe_muram use two algos with alloc_align function
> And alloc_fixed function.
Yes. That is why gen_pool_alloc_data() does not accomplish what we want.
When we were discussing gen_pool_alloc_data(), you had not yet mentioned the
need for fixed allocations.
-Scott
--
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 v12 4/6] QE/CPM: move muram management functions to qe_common
On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote: > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Saturday, October 24, 2015 4:56 AM > > To: Zhao Qiang-B45475 > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > > pau...@samba.org > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to > > qe_common > > > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote: > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421 > > > > > > wrote: > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Friday, October 23, 2015 11:10 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ; > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ; > > > > pau...@samba.org > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management > > functions > > > > to qe_common > > > > > > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote: > > > > > QE and CPM have the same muram, they use the same management > > > > > functions. Now QE support both ARM and PowerPC, it is necessary to > > > > > move QE to "driver/soc", so move the muram management functions > > > > > from cpm_common to qe_common for preparing to move QE code to > > "driver/soc" > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > --- > > > > > Changes for v2: > > > > > - no changes > > > > > Changes for v3: > > > > > - no changes > > > > > Changes for v4: > > > > > - no changes > > > > > Changes for v5: > > > > > - no changes > > > > > Changes for v6: > > > > > - using genalloc instead rheap to manage QE MURAM > > > > > - remove qe_reset from platform file, using > > > > > - subsys_initcall to call qe_init function. > > > > > Changes for v7: > > > > > - move this patch from 3/3 to 2/3 > > > > > - convert cpm with genalloc > > > > > - check for gen_pool allocation failure Changes for v8: > > > > > - rebase > > > > > - move BD_SC_* macro instead of copy Changes for v9: > > > > > - doesn't modify CPM, add a new patch to modify. > > > > > - rebase > > > > > Changes for v10: > > > > > - rebase > > > > > Changes for v11: > > > > > - remove renaming > > > > > - delete removing qe_reset and delete adding qe_init. > > > > > Changes for v12: > > > > > - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for it. > > > > > > > > Why is the SPI change part of this patch? Why is it even part of > > > > this patchset, rather than an independent patch sent to the SPI list > > > > and maintainer? If it's tied to other changes you're making, > > > > explain that. As is, there is zero mention of the SPI change in the > > > > part of the e-mail that will become the git changelog. > > > > > > > This SPI_FSL_CPM is cpm-spi, it is part of CPM. > > > > So then why are you selecting QUICC_ENGINE? And again, what does it have > > to do with this patch? > > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will failed to > build. Why QUICC_ENGINE and not CPM? -Scott -- 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] bpf: make tracing helpers gpl only
From: Alexei Starovoitov Date: Fri, 23 Oct 2015 14:58:19 -0700 > exported perf symbols are GPL only, mark eBPF helper functions > used in tracing as GPL only as well. > > Suggested-by: Peter Zijlstra > Signed-off-by: Alexei Starovoitov Applied. -- 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 3/5] mtd: ofpart: update devicetree binding specification
On Sun, Oct 11, 2015 at 3:04 PM, Brian Norris
wrote:
> Hi DT maintainers,
>
> It's a bit hypocritical of me, since I've been a slow reviewer as well,
> but... can we get some review on this one? Usually, I'm comfortable
> taking driver DT bindings without your review, but this one is a bit
> more generic and is more far-reaching than the average driver.
Sorry, missed this one. This would be a good one to send to
devicetree-spec to BTW.
> I'm not a big fan of this change, and I don't quite understand why the
> bus driver (the SPI bus, which is a level up from the SPI device / MTD
> node) can specify its grandchildren (see spi-samsung.txt). But given the
That's just an example. I just would change it.
> constraints, I think Michal's solution is OK. And I do agree that MTD's
> ofpart should be bit more specific.
>
> Anyway, a quick look and an Ack/Nak would be appreciated.
Looks fine to me:
Acked-by: Rob Herring
>
> Thanks,
> Brian
>
> On Tue, Aug 18, 2015 at 03:34:08PM -, Michal Suchanek wrote:
>> To avoid conflict with other drivers using subnodes of the mtd device
>> create only one ofpart-specific node rather than any number of
>> arbitrary partition subnodes.
>>
>> Signed-off-by: Michal Suchanek
>> ---
>> v3:
>>
>> - rename DT node ofpart -> partitions
>> ---
>> .../devicetree/bindings/mtd/partition.txt | 68
>> +-
>> 1 file changed, 40 insertions(+), 28 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt
>> b/Documentation/devicetree/bindings/mtd/partition.txt
>> index 8e5557d..8c2aff7 100644
>> --- a/Documentation/devicetree/bindings/mtd/partition.txt
>> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
>> @@ -4,10 +4,16 @@ Partitions can be represented by sub-nodes of an mtd
>> device. This can be used
>> on platforms which have strong conventions about which portions of a flash
>> are
>> used for what purposes, but which don't use an on-flash partition table such
>> as RedBoot.
>> +
>> +The partition table should be partitions subnode of the mtd node.
>> Partitions are
>> +defined in subnodes of the partitions node.
>> +
>> +For backwards compatibility partitions as direct subnodes of the mtd device
>> are
>> +supported. This use is discouraged.
>> NOTE: if the sub-node has a compatible string, then it is not a partition.
>>
>> -#address-cells & #size-cells must both be present in the mtd device. There
>> are
>> -two valid values for both:
>> +#address-cells & #size-cells must both be present in the partitions subnode
>> of the
>> +mtd device. There are two valid values for both:
>> <1>: for partitions that require a single 32-bit cell to represent their
>> size/address (aka the value is below 4 GiB)
>> <2>: for partitions that require two 32-bit cells to represent their
>> @@ -28,44 +34,50 @@ Examples:
>>
>>
>> flash@0 {
>> - #address-cells = <1>;
>> - #size-cells = <1>;
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>>
>> - partition@0 {
>> - label = "u-boot";
>> - reg = <0x000 0x10>;
>> - read-only;
>> - };
>> + partition@0 {
>> + label = "u-boot";
>> + reg = <0x000 0x10>;
>> + read-only;
>> + };
>>
>> - uimage@10 {
>> - reg = <0x010 0x20>;
>> + uimage@10 {
>> + reg = <0x010 0x20>;
>> + };
>> };
>> };
>>
>> flash@1 {
>> - #address-cells = <1>;
>> - #size-cells = <2>;
>> + partitions {
>> + #address-cells = <1>;
>> + #size-cells = <2>;
>>
>> - /* a 4 GiB partition */
>> - partition@0 {
>> - label = "filesystem";
>> - reg = <0x 0x1 0x>;
>> + /* a 4 GiB partition */
>> + partition@0 {
>> + label = "filesystem";
>> + reg = <0x 0x1 0x>;
>> + };
>> };
>> };
>>
>> flash@2 {
>> - #address-cells = <2>;
>> - #size-cells = <2>;
>> + partitions {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>>
>> - /* an 8 GiB partition */
>> - partition@0 {
>> - label = "filesystem #1";
>> - reg = <0x0 0x 0x2 0x>;
>> - };
>> + /* an 8 GiB partition */
>> + partition@0 {
>> + label = "filesystem #1";
>> + reg = <0x0 0x 0x2 0x>;
>> + };
>>
>> - /* a 4 GiB partition */
>> - partition@2 {
>> - label = "filesystem #2";
>> - reg = <0x2 0x 0x1 0x>;
>> + /* a 4 GiB partition */
>> + partition@2 {
>> + label = "filesystem #2";
>> + reg = <0x2 0x
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > > > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > > > Furthermore, that applies only to devices that use synchronous suspend. > > > Async suspend is becoming common, and there the only restrictions are > > > parent-child relations plus whatever explicit requirements that drivers > > > impose by calling device_pm_wait_for_dev(). > > > > Hrm, this is the first I'd noticed that feature though I see the initial > > commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > > > It looks like most of the users are PCs at > > the minute but we should be using it more widely for embedded things, > > there's definitely some cases I'm aware of where it will allow us to > > remove some open coding. > > > > It does seem like we want to be feeding dependency information we > > discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. Well, good point. :-) I've been kind of struggling with finding time to work on the patches lately and some aspects of the design are still not finalized. It seems, though, that it can be beneficial to discuss the approach in general, so let me start a new thread for that. Thanks, Rafael -- 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 net-next] bpf: fix bpf_perf_event_read() helper
From: Alexei Starovoitov
Date: Thu, 22 Oct 2015 17:10:14 -0700
> Fix safety checks for bpf_perf_event_read():
> - only non-inherited events can be added to perf_event_array map
> (do this check statically at map insertion time)
> - dynamically check that event is local and !pmu->count
> Otherwise buggy bpf program can cause kernel splat.
>
> Also fix error path after perf_event_attrs()
> and remove redundant 'extern'.
>
> Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get
> the selected hardware PMU conuter")
> Signed-off-by: Alexei Starovoitov
Applied, although my tendancy is to agree with the sentiment that you must
respect the entire universe of valid 64-bit counter values. I do not buy
the arguments about values overlapping error codes being unlikely or not
worth worrying about.
Just FYI...
--
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] kernel: power: replacing printk
replacing prink(s) with appropriate pr_info and pr_err
Signed-off-by: Saurabh Sengar
---
kernel/power/suspend.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7e4cda4..2597a96 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -245,7 +245,7 @@ static int suspend_test(int level)
{
#ifdef CONFIG_PM_DEBUG
if (pm_test_level == level) {
- printk(KERN_INFO "suspend debug: Waiting for %d second(s).\n",
+ pr_info("suspend debug: Waiting for %d second(s).\n",
pm_test_delay);
mdelay(pm_test_delay * 1000);
return 1;
@@ -317,7 +317,7 @@ static int suspend_enter(suspend_state_t state, bool
*wakeup)
error = dpm_suspend_late(PMSG_SUSPEND);
if (error) {
- printk(KERN_ERR "PM: late suspend of devices failed\n");
+ pr_err("PM: late suspend of devices failed\n");
goto Platform_finish;
}
error = platform_suspend_prepare_late(state);
@@ -326,7 +326,7 @@ static int suspend_enter(suspend_state_t state, bool
*wakeup)
error = dpm_suspend_noirq(PMSG_SUSPEND);
if (error) {
- printk(KERN_ERR "PM: noirq suspend of devices failed\n");
+ pr_err("PM: noirq suspend of devices failed\n");
goto Platform_early_resume;
}
error = platform_suspend_prepare_noirq(state);
@@ -486,9 +486,9 @@ static int enter_state(suspend_state_t state)
#ifndef CONFIG_SUSPEND_SKIP_SYNC
trace_suspend_resume(TPS("sync_filesystems"), 0, true);
- printk(KERN_INFO "PM: Syncing filesystems ... ");
+ pr_info("PM: Syncing filesystems ... ");
sys_sync();
- printk("done.\n");
+ pr_info("done.\n");
trace_suspend_resume(TPS("sync_filesystems"), 0, false);
#endif
--
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 v3] dmaengine: fsl-edma: add PM suspend/resume support
Hi Vinod,
Thanks for your review.
I did the test and it seems that it should be ok when CONFIG_PM is not defined.
So I removed the protection code to make it more readable.
Do you think is it ok?
Best Regards,
Yuan Yao
> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, October 27, 2015 10:01 AM
> To: Yuan Yao-B46683
> Cc: ste...@agner.ch; a...@arndb.de; dan.j.willi...@intel.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3] dmaengine: fsl-edma: add PM suspend/resume
> support
>
> On Mon, Oct 19, 2015 at 04:31:05PM +0800, Yuan Yao wrote:
>
> The patch overall looks fine, but
> >
> > +static int fsl_edma_suspend_late(struct device *dev)
>
> This needs protection and will have build failure when CONFIG_PM is not
> defined
>
> > +{
> > + struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > + struct fsl_edma_chan *fsl_chan;
> > + unsigned long flags;
> > + int i;
> > +
> > + for (i = 0; i < fsl_edma->n_chans; i++) {
> > + fsl_chan = &fsl_edma->chans[i];
> > + spin_lock_irqsave(&fsl_chan->vchan.lock, flags);
> > + /* Make sure chan is idle or will force disable. */
> > + if (unlikely(!fsl_chan->idle)) {
> > + dev_warn(dev, "WARN: There is non-idle channel.");
> > + fsl_edma_disable_request(fsl_chan);
> > + fsl_edma_chan_mux(fsl_chan, 0, false);
> > + }
> > +
> > + fsl_chan->pm_state = SUSPENDED;
> > + spin_unlock_irqrestore(&fsl_chan->vchan.lock, flags);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int fsl_edma_resume_early(struct device *dev) {
> > + struct fsl_edma_engine *fsl_edma = dev_get_drvdata(dev);
> > + struct fsl_edma_chan *fsl_chan;
> > + int i;
> > +
> > + for (i = 0; i < fsl_edma->n_chans; i++) {
> > + fsl_chan = &fsl_edma->chans[i];
> > + fsl_chan->pm_state = RUNNING;
> > + edma_writew(fsl_edma, 0x0, fsl_edma->membase +
> EDMA_TCD_CSR(i));
> > + if (fsl_chan->slave_id != 0)
> > + fsl_edma_chan_mux(fsl_chan, fsl_chan->slave_id,
> true);
> > + }
> > +
> > + edma_writel(fsl_edma, EDMA_CR_ERGA | EDMA_CR_ERCA,
> > + fsl_edma->membase + EDMA_CR);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct dev_pm_ops fsl_edma_pm_ops = {
> > + .suspend_late = fsl_edma_suspend_late,
> > + .resume_early = fsl_edma_resume_early,
> > +};
>
> This one too, also why use late and early, pls add the note here
>
> > static const struct of_device_id fsl_edma_dt_ids[] = {
> > { .compatible = "fsl,vf610-edma", },
> > { /* sentinel */ }
> > @@ -969,6 +1042,7 @@ static struct platform_driver fsl_edma_driver = {
> > .driver = {
> > .name = "fsl-edma",
> > .of_match_table = fsl_edma_dt_ids,
> > + .pm = &fsl_edma_pm_ops,
> This will fail too if CONFIG_PM is not defined
>
> --
> ~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 4/5] mm: simplify reclaim path for MADV_FREE
> On Oct 27, 2015, at 10:09, Hugh Dickins wrote:
>
> On Mon, 19 Oct 2015, Minchan Kim wrote:
>
>> I made reclaim path mess to check and free MADV_FREEed page.
>> This patch simplify it with tweaking add_to_swap.
>>
>> So far, we mark page as PG_dirty when we add the page into
>> swap cache(ie, add_to_swap) to page out to swap device but
>> this patch moves PG_dirty marking under try_to_unmap_one
>> when we decide to change pte from anon to swapent so if
>> any process's pte has swapent for the page, the page must
>> be swapped out. IOW, there should be no funcional behavior
>> change. It makes relcaim path really simple for MADV_FREE
>> because we just need to check PG_dirty of page to decide
>> discarding the page or not.
>>
>> Other thing this patch does is to pass TTU_BATCH_FLUSH to
>> try_to_unmap when we handle freeable page because I don't
>> see any reason to prevent it.
>>
>> Cc: Hugh Dickins
>> Cc: Mel Gorman
>> Signed-off-by: Minchan Kim
>
> Acked-by: Hugh Dickins
>
> This is sooo much nicer than the code it replaces! Really good.
> Kudos also to Hannes for suggesting this approach originally, I think.
>
> I hope this implementation satisfies a good proportion of the people
> who have been wanting MADV_FREE: I'm not among them, and have long
> lost touch with those discussions, so won't judge how usable it is.
>
> I assume you'll refactor the series again before it goes to Linus,
> so the previous messier implementations vanish? I notice Andrew
> has this "mm: simplify reclaim path for MADV_FREE" in mmotm as
> mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch:
> I guess it all got much too messy to divide up in a hurry.
>
> I've noticed no problems in testing (unlike the first time you moved
> to working with pte_dirty); though of course I've not been using
> MADV_FREE itself at all.
>
> One aspect has worried me for a while, but I think I've reached the
> conclusion that it doesn't matter at all. The swap that's allocated
> in add_to_swap() would normally get freed again (after try_to_unmap
> found it was a MADV_FREE !pte_dirty !PageDirty case) at the bottom
> of shrink_page_list(), in __remove_mapping(), yes?
>
> The bit that worried me is that on rare occasions, something unknown
> might take a speculative reference to the page, and __remove_mapping()
> fail to freeze refs for that reason. Much too rare to worry over not
> freeing that page immediately, but it leaves us with a PageUptodate
> PageSwapCache !PageDirty page, yet its contents are not the contents
> of that location on swap.
>
> But since this can only happen when you have *not* inserted the
> corresponding swapent anywhere, I cannot think of anything that would
> have a legitimate interest in its contents matching that location on swap.
> So I don't think it's worth looking for somewhere to add a SetPageDirty
> (or a delete_from_swap_cache) just to regularize that case.
>
>> ---
>> include/linux/rmap.h | 6 +
>> mm/huge_memory.c | 5
>> mm/rmap.c| 42 ++
>> mm/swap_state.c | 5 ++--
>> mm/vmscan.c | 64
>>
>> 5 files changed, 30 insertions(+), 92 deletions(-)
>>
>> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
>> index 6b6233fafb53..978f65066fd5 100644
>> --- a/include/linux/rmap.h
>> +++ b/include/linux/rmap.h
>> @@ -193,8 +193,7 @@ static inline void page_dup_rmap(struct page *page, bool
>> compound)
>> * Called from mm/vmscan.c to handle paging out
>> */
>> int page_referenced(struct page *, int is_locked,
>> -struct mem_cgroup *memcg, unsigned long *vm_flags,
>> -int *is_pte_dirty);
>> +struct mem_cgroup *memcg, unsigned long *vm_flags);
>>
>> #define TTU_ACTION(x) ((x) & TTU_ACTION_MASK)
>>
>> @@ -272,11 +271,8 @@ int rmap_walk(struct page *page, struct
>> rmap_walk_control *rwc);
>> static inline int page_referenced(struct page *page, int is_locked,
>>struct mem_cgroup *memcg,
>>unsigned long *vm_flags,
>> - int *is_pte_dirty)
>> {
>> *vm_flags = 0;
>> -if (is_pte_dirty)
>> -*is_pte_dirty = 0;
>> return 0;
>> }
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 269ed99493f0..adccfb48ce57 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -1753,11 +1753,6 @@ pmd_t *page_check_address_pmd(struct page *page,
>> return NULL;
>> }
>>
>> -int pmd_freeable(pmd_t pmd)
>> -{
>> -return !pmd_dirty(pmd);
>> -}
>> -
>> #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE)
>>
>> int hugepage_madvise(struct vm_area_struct *vma,
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 94ee372e238b..fd64f79c87c4 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -797,7 +797,6 @@ int page_mapped_in_vma(struct page *page, struct
>> vm_area_struct *
Re: [net-next PATCHv2] bpf: Output error message to logbuf when loading failure
On 2015/10/27 11:26, Alexei Starovoitov wrote: On Mon, Oct 26, 2015 at 07:13:08AM +, Wang Nan wrote: Many reasons can make bpf_prog_load() return EINVAL. This patch utilizes logbuf to deliver the actual reason of the failure. Without this patch, it is very easy for user to pass an object with "version" section not match the kernel version code, and the problem is hard to determine from return code (EINVAL). Signed-off-by: Wang Nan Cc: Alexei Starovoitov Cc: Arnaldo Carvalho de Melo Cc: David S. Miller Cc: Wu Fengguang NACK for both implementation and design. OK. Let perf to report error message. Thank you. -- 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] drivers: of: removing assignment of 0 to static variable
no need to initialise static variable with 0, hence correcting it. Signed-off-by: Saurabh Sengar --- drivers/of/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 6e82bc42..63699dd 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -184,7 +184,7 @@ static void * unflatten_dt_node(const void *blob, struct property *pp, **prev_pp = NULL; const char *pathp; unsigned int l, allocl; - static int depth = 0; + static int depth; int old_depth; int offset; int has_name = 0; -- 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 07/10] hwmon: (fam15h_power) Introduce a cpu accumulated power reporting algorithm
On Fri, Oct 23, 2015 at 10:20:59PM +0800, Guenter Roeck wrote:
> On 10/19/2015 07:28 PM, Huang Rui wrote:
> > This patch introduces an algorithm that computes the average power by
> > reading a delta value of “core power accumulator” register during
> > measurement interval, and then dividing delta value by the length of
> > the time interval.
> >
> > User is able to use power1_average entry to measure the processor power
> > consumption and power1_average_interval entry to set the interval.
> >
> > A simple example:
> >
> > ray@hr-ub:~/tip$ sensors
> > fam15h_power-pci-00c4
> > Adapter: PCI adapter
> > power1: 23.73 mW (avg = 634.63 mW, interval = 0.01 s)
> > (crit = 15.00 W)
> >
> > ...
> >
> > The result is current average processor power consumption in 10
> > millisecond. The unit of the result is uWatt.
> >
> > Suggested-by: Guenter Roeck
> > Signed-off-by: Huang Rui
> > Cc: Borislav Petkov
> > Cc: Peter Zijlstra
> > Cc: Ingo Molnar
> > ---
> > drivers/hwmon/fam15h_power.c | 120
> > +++
> > 1 file changed, 120 insertions(+)
> >
> > diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > index 6321f73..a5a539e 100644
> > --- a/drivers/hwmon/fam15h_power.c
> > +++ b/drivers/hwmon/fam15h_power.c
> > @@ -26,6 +26,9 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> >
> > @@ -64,6 +67,10 @@ struct fam15h_power_data {
> > u64 cu_acc_power[MAX_CUS];
> > /* performance timestamp counter */
> > u64 cpu_sw_pwr_ptsc[MAX_CUS];
> > + /* online/offline status of current compute unit */
> > + int cu_on[MAX_CUS];
> > + unsigned long power_period;
> > + struct mutex acc_pwr_mutex;
>
> Can you elaborate a bit about what this mutex is supposed to protect ?
> To me it seems that it doesn't really protect anything.
>
My orignal intention is to avoid race condition from user space.
Actually you know, show_power_acc, acc_set_power_period will expose to
application layer.
> > };
> >
> > static ssize_t show_power(struct device *dev,
> > @@ -132,11 +139,15 @@ static void do_read_registers_on_cu(void *_data)
> > cores_per_cu = amd_get_cores_per_cu();
> > cu = cpu / cores_per_cu;
> >
> > + mutex_lock(&data->acc_pwr_mutex);
> > WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
> > &data->cu_acc_power[cu]));
> >
> > WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
> > &data->cpu_sw_pwr_ptsc[cu]));
> > +
> > + data->cu_on[cu] = 1;
> > + mutex_unlock(&data->acc_pwr_mutex);
>
> ... for example, while this protects cu_on[cu],
>
> > }
> >
> > static int read_registers(struct fam15h_power_data *data)
> > @@ -148,6 +159,10 @@ static int read_registers(struct fam15h_power_data
> > *data)
> > cores_per_cu = amd_get_cores_per_cu();
> > cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >
> > + mutex_lock(&data->acc_pwr_mutex);
> > + memset(data->cu_on, 0, sizeof(int) * MAX_CUS);
> > + mutex_unlock(&data->acc_pwr_mutex);
>
> ... this code may well overwrite that same value.
>
Yes, but I only need the compute unit status of the "sencond" time of
read_registers.
Then ignore the offline compute unit to avoid hotplug issue.
> > +
> > WARN_ON_ONCE(cu_num > MAX_CUS);
> >
> > ret = zalloc_cpumask_var(&mask, GFP_KERNEL);
> > @@ -184,18 +199,113 @@ static int read_registers(struct fam15h_power_data
> > *data)
> > return 0;
> > }
> >
> > +static ssize_t acc_show_power(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct fam15h_power_data *data = dev_get_drvdata(dev);
> > + u64 prev_cu_acc_power[MAX_CUS], prev_ptsc[MAX_CUS],
> > + jdelta[MAX_CUS];
> > + u64 tdelta, avg_acc;
> > + int cu, cu_num, cores_per_cu, ret;
> > + signed long leftover;
> > +
> > + cores_per_cu = amd_get_cores_per_cu();
> > + cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > + ret = read_registers(data);
> > + if (ret)
> > + return 0;
The first time of read_registers
> > +
> > + cu = 0;
> > + while(cu++ < cu_num) {
> > + prev_cu_acc_power[cu] = data->cu_acc_power[cu];
> > + prev_ptsc[cu] = data->cpu_sw_pwr_ptsc[cu];
> > + }
>
> ... and multiple parallel reads on the power attribute must produce
> pretty random values, unless I am really missing something.
>
> > +
> > + leftover = schedule_timeout_interruptible(
> > + msecs_to_jiffies(data->power_period)
> > + );
> > + if (leftover)
> > + return 0;
> > +
> > + ret = read_registers(data);
The second time of read_registers
> > + if (ret)
> > + return 0;
> > +
> With a 10ms period, I wonder how accurate this really is.
>
According to the HW description, the measurement interval could be on
the order of se
Re: [PATCH net-next] seccomp, ptrace: add support for dumping seccomp filters
On Tue, Oct 27, 2015 at 09:23:59AM +0900, Tycho Andersen wrote: > This patch adds support for dumping a process' (classic BPF) seccomp > filters via ptrace. > > PTRACE_SECCOMP_GET_FILTER allows the tracer to dump the user's classic BPF > seccomp filters. addr should be an integer which represents the ith seccomp > filter (0 is the most recently installed filter). data should be a struct > sock_filter * with enough room for the ith filter, or NULL, in which case > the filter is not saved. The return value for this command is the number of > BPF instructions the program represents, or negative in the case of errors. > Command specific errors are ENOENT: which indicates that there is no ith > filter in this seccomp tree, and EMEDIUMTYPE, which indicates that the ith > filter was not installed as a classic BPF filter. > > A caveat with this approach is that there is no way to get explicitly at > the heirarchy of seccomp filters, and users need to memcmp() filters to > decide which are inherited. This means that a task which installs two of > the same filter can potentially confuse users of this interface. > > v2: * make save_orig const > * check that the orig_prog exists (not necessary right now, but when >grows eBPF support it will be) > * s/n/filter_off and make it an unsigned long to match ptrace > * count "down" the tree instead of "up" when passing a filter offset > > v3: * don't take the current task's lock for inspecting its seccomp mode > * use a 0x42** constant for the ptrace command value > > v4: * don't copy to userspace while holding spinlocks > > v5: * add another condition to WARN_ON > > v6: * rebase on net-next > > Signed-off-by: Tycho Andersen > Acked-by: Kees Cook > CC: Will Drewry > Reviewed-by: Oleg Nesterov > CC: Andy Lutomirski > CC: Pavel Emelyanov > CC: Serge E. Hallyn > CC: Alexei Starovoitov > CC: Daniel Borkmann Looks fine. Acked-by: Alexei Starovoitov -- 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 PATCH] VFIO: Add a parameter to force nonthread IRQ
On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
> even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
> assigning a device to a guest with low latency requirement since it
> reduce the context switch to/from the IRQ thread.
Is there any way we can do this automatically? Perhaps detecting that
we're on a RT kernel or maybe that the user is running with RT priority?
I find that module options are mostly misunderstood and misused.
> An experiment was conducted on a HSW platform for 1 minutes, with the
> guest vCPU bound to isolated pCPU. The assigned device triggered the
> interrupt every 1ms. The average EXTERNAL_INTERRUPT exit handling time
> is dropped from 5.3us to 2.2us.
>
> Another choice is to change VFIO_DEVICE_SET_IRQS ioctl, to apply this
> option only to specific devices when in kernel irq_chip is enabled. It
> provides more flexibility but is more complex, not sure if we need go
> through that way.
Allowing the user to decide whether or not to use a threaded IRQ seems
like a privilege violation; a chance for the user to game the system and
give themselves better latency, maybe at the cost of others. I think
we're better off trying to infer the privilege from the task priority or
kernel config or, if we run out of options, make a module option as you
have here requiring the system admin to provide the privilege. Thanks,
Alex
> Signed-off-by: Yunhong Jiang
> ---
> drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
> b/drivers/vfio/pci/vfio_pci_intrs.c
> index 1f577b4..ca1f95a 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -22,9 +22,13 @@
> #include
> #include
> #include
> +#include
>
> #include "vfio_pci_private.h"
>
> +static bool nonthread_msi = 1;
> +module_param(nonthread_msi, bool, 0444);
> +
> /*
> * INTx
> */
> @@ -313,6 +317,7 @@ static int vfio_msi_set_vector_signal(struct
> vfio_pci_device *vdev,
> char *name = msix ? "vfio-msix" : "vfio-msi";
> struct eventfd_ctx *trigger;
> int ret;
> + unsigned long irqflags = 0;
>
> if (vector >= vdev->num_ctx)
> return -EINVAL;
> @@ -352,7 +357,10 @@ static int vfio_msi_set_vector_signal(struct
> vfio_pci_device *vdev,
> pci_write_msi_msg(irq, &msg);
> }
>
> - ret = request_irq(irq, vfio_msihandler, 0,
> + if (nonthread_msi)
> + irqflags = IRQF_NO_THREAD;
> +
> + ret = request_irq(irq, vfio_msihandler, irqflags,
> vdev->ctx[vector].name, trigger);
> if (ret) {
> kfree(vdev->ctx[vector].name);
--
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 tip/core/rcu 11/13] rculist: Make list_entry_rcu() use lockless_dereference()
On Mon, Oct 26, 2015 at 11:55 PM, Paul E. McKenney
wrote:
>> struct bdi_writeback *last_wb = NULL;
>> struct bdi_writeback *wb = list_entry_rcu(&bdi->wb_list,
>
> I believe that the above should instead be:
>
> struct bdi_writeback *wb = list_entry_rcu(bdi->wb_list.next,
I don't think you can do that.
You haven't even taken the RCU read lock yet at this point.
What the code seems to try to do is to get the "head pointer" of the
list before taking the read lock (since _that_ is stable), and then
follow the list under the lock.
You're making it actually follow the first RCU pointer too early.
That said, I'm not sure why it doesn't just do the normal
rcu_read_lock();
list_for_each_entry_rcu(wb, &bdi->wb_list, bdi_node) {
}
rcu_read_unlock();
like the other places do. It looks like it wants that
"list_for_each_entry_continue_rcu()" because it does that odd "pin
entry and drop rcu lock and retake it and continue where you left
off", but I'm not sure why the continue version would be so
different.. It's going to do that "follow next entry" regardless, and
the "goto restart" doesn't look like it actually adds anything. If
following the next pointer is ok even after having released the RCU
read lock, then I'm not seeing why the end of the loop couldn't just
do
rcu_read_unlock();
wb_wait_for_completion(bdi, &fallback_work_done);
rcu_read_lock();
and just continue the loop (and the pinning of "wb" and releasing the
"last_wb" thing in the *next* iteration should make it all work the
same).
Adding Tejun to the cc, because this is his code and there's probably
something subtle I'm missing. Tejun, can you take a look? It's
bdi_split_work_to_wbs() in fs/fs-writeback.c.
Linus
--
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: [net-next PATCHv2] bpf: Output error message to logbuf when loading failure
On Mon, Oct 26, 2015 at 07:13:08AM +, Wang Nan wrote:
> Many reasons can make bpf_prog_load() return EINVAL. This patch utilizes
> logbuf to deliver the actual reason of the failure.
>
> Without this patch, it is very easy for user to pass an object with
> "version" section not match the kernel version code, and the problem
> is hard to determine from return code (EINVAL).
>
> Signed-off-by: Wang Nan
> Cc: Alexei Starovoitov
> Cc: Arnaldo Carvalho de Melo
> Cc: David S. Miller
> Cc: Wu Fengguang
NACK
for both implementation and design.
> + /* Don't need care the copying result too much */
> + WARN(copy_to_user(log_ubuf, log_buf, log_size),
> + KERN_WARNING "Failed to copy BPF error note '%s' to log buffer\n",
> + log_buf);
unprivilged user will be spamming kernel logs?!
> - if (attr->insn_cnt >= BPF_MAXINSNS)
> + if (attr->insn_cnt >= BPF_MAXINSNS) {
> + bpf_prog_load_note(attr, "Too many instructions: %d > %d\n",
> +attr->insn_cnt, BPF_MAXINSNS);
> return -EINVAL;
if user space did that, it's wrong and can detect it
on its own.
> if (type == BPF_PROG_TYPE_KPROBE &&
> - attr->kern_version != LINUX_VERSION_CODE)
> + attr->kern_version != LINUX_VERSION_CODE) {
> + bpf_prog_load_note(attr,
> +"Kernel version mismatch: 0x%x != 0x%x\n",
> +attr->kern_version, LINUX_VERSION_CODE);
> return -EINVAL;
user space (perf) could have checked that on its own
without kernel changes.
> /* find program type: socket_filter vs tracing_filter */
> err = find_prog_type(type, prog);
> - if (err < 0)
> + if (err < 0) {
> + bpf_prog_load_note(attr, "Invalid program type: %d\n", type);
> goto free_prog;
same here.
In general syscalls muxing different error conditions into EINVAL
is a kernel wide problem and should be solved for all.
--
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 PATCH v2 1/2] perf tools: Set evsel->system_wide field for global system wide recording
On 2015/10/26 21:02, Adrian Hunter wrote: On 26/10/15 14:39, Wangnan (F) wrote: On 2015/10/26 20:24, Adrian Hunter wrote: On 26/10/15 13:41, Wang Nan wrote: evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837 (perf evlist: Add 'system_wide' option), which is used for mixing evsels that aren't system-wide with ones that are [1]. However, for global system wide recording (perf record -a ...), evsel->system_wide is set to false, which is confusion. This patch set evsel->system_wide to true if the target.system_wide is set, which makes evsel->system_wide a reliable way to describe whether itself is system_wide or not. [1] http://lkml.kernel.org/r/562df19b.2080...@intel.com Signed-off-by: Wang Nan Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Alexei Starovoitov Cc: Peter Zijlstra Cc: Li Zefan Cc: pi3or...@163.com Link: http://lkml.kernel.org/n/ebpf-qm3gtwidc1o5ktjd9tgje...@git.kernel.org --- tools/perf/util/evsel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 3ac4ee9c..36ecf0e 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -734,6 +734,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts) int track = evsel->tracking; bool per_cpu = opts->target.default_per_cpu && !opts->target.per_thread; +evsel->system_wide = opts->target.system_wide; Well that breaks the way evsel->system_wide is used i.e. it is a parameter to the evsel and here you just overwrote it. Currently the only user of evsel->system_wide is IPT: auxtrace_record__options -> intel_pt_recording_options and it only set it to true. So I think changing to this should make it safe: evsel->system_wide = (evsel->system_wide || opt->target.system_wide); Thought? That would work although it looks like a kludge. Have you looked at properly validating opts->no_inherit ? Also, aren't you neglecting target->cpu_list ? I need this because Alexei's bpf_perf_event_output() helper needs perf side support, and it only accept no-inherit perf event. I have already made a patch[1] to support setting inherit bit per-event, so even without this and next patch I can continue my work on bpf output. I'd like to rethink this patch after I finish perf support for bpf output. Thank you. [1] http://lkml.kernel.org/g/1445847884-143981-1-git-send-email-wangn...@huawei.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/
Re: [RFC PATCH] x86/cpu: Move sparsely used bit leafs into scattered features (was: Re: [PATCH 2/2] x86/cpufeature: Add CLZERO feature)
On Mon, Oct 26, 2015 at 07:56:06PM -0700, Andy Lutomirski wrote: > How few features in one leaf do we need before calling it scattered > makes sense? These four might make sense to keep as is... Actually, according to hpa, all those leafs will be filled out gradually as they're apparently going to be used for hw features. And it looks like the AMD leaf is of the same type. So those all will be fleshed out with time and we can keep them here, in cpufeature.h. > ...whereas this looks totally reasonable. > > FWIW, we have a ton of thses things. Would it make sense to convert > this to a text file giving features and their CPUID positions that > generates the defines and the code to enumerate them? Yeah, maybe. I'm not that really bothered by the current form too, though. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] bpf: sample: define aarch64 specific registers
On Mon, Oct 26, 2015 at 05:02:19PM -0700, Yang Shi wrote: > Define aarch64 specific registers for building bpf samples correctly. > > Signed-off-by: Yang Shi looks good to me. Acked-by: Alexei Starovoitov -- 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] ARM: dts: uniphier: add system-bus-controller nodes
The System Bus Controller block has two register regions,
but having only the second one in a separate node was not nice.
Replace it with a new node with two register regions in it.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 7 +++
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 7 +++
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 7 +++
6 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index ae13469..af49381 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 85377b2..254642f 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -232,10 +232,9 @@
clock-frequency = <40>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb2: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 96da01e..11eb762 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -241,10 +241,9 @@
clock-frequency = <40>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
pinctrl: pinctrl@5f801000 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 945b37f..691a17d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -216,10 +216,9 @@
clock-frequency = <40>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index c98428c..e88559b 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ad5fb39..259f1a9 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -251,10 +251,9 @@
clock-frequency = <40>;
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Hello, Mike. On Sun, Oct 25, 2015 at 04:43:33AM +0100, Mike Galbraith wrote: > I don't think it's weird, it's just a thought wrt where pigeon holing > could lead: If you filter out current users who do so in a manner you > consider to be in some way odd, when all the filtering is done, you may > find that you've filtered out the vast majority of current deployment. I think you misunderstood what I wrote. It's not about excluding existing odd use cases. It's about examining the usages and extracting the required capabilities and building an interface which is well defined and blends well with the rest of programming interface provided by the kernel so that those can be achieved in a saner way. If doing acrobatics with the current interface is necessary to acheive certain capabilities, we need to come up with a better interface for those. If fringe usages can be satisfied using better constructs, we should implement that and encourage transition to a better mechanism. > I'm not at all sure of this, but I suspect that SUSE's gigabuck size > cgroup power user will land in the same "fringe" pigeon hole. If so, > that would be another sizeable dent in volume. > > My point is that these power users likely _are_ your general audience. Sure, that doesn't mean we shouldn't scrutinize the interface we implement to support those users. Also, cgroup also definitely had some negative spiral effect where eccentric mechanisms and interfaces discouraged general wider usages fortifying the argument that "we're the main users" which in turn fed back to even weirder things being added. Everybody including the "heavy" users suffers from such failures in the long term. We sure want to support all the valid use cases from heavy users in a reasonable way but that doesn't mean we say yes to everything. > Sure, it was just a thought wrt "actively filter those out" and who all > "those" may end up being. I hope what I meant is clearer now. Thanks. -- tejun -- 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] blktrace: re-write setting q->blk_trace
This is really about simplifying the double xchg patterns into
a single cmpxchg, with the same logic. Other than the immediate
cleanup, there are some subtleties this change deals with:
(i) While the load of the old bt is fully ordered wrt everything,
ie:
old_bt = xchg(&q->blk_trace, bt); [barrier]
if (old_bt)
(void) xchg(&q->blk_trace, old_bt);[barrier]
blk_trace could still be changed between the xchg and the old_bt
load. Note that this description is merely theoretical and afaict
very small, but doing everything in a single context with cmpxchg
closes this potential race.
(ii) Ordering guarantees are obviously kept with cmpxchg.
Signed-off-by: Davidlohr Bueso
---
v2: sorry I sent a stale version which didn't set EBUSY when the structure is
already initialized.
kernel/trace/blktrace.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 90e72a0..e3a2618 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -437,7 +437,7 @@ int do_blk_trace_setup(struct request_queue *q, char *name,
dev_t dev,
struct block_device *bdev,
struct blk_user_trace_setup *buts)
{
- struct blk_trace *old_bt, *bt = NULL;
+ struct blk_trace *bt = NULL;
struct dentry *dir = NULL;
int ret;
@@ -519,11 +519,8 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
bt->trace_state = Blktrace_setup;
ret = -EBUSY;
- old_bt = xchg(&q->blk_trace, bt);
- if (old_bt) {
- (void) xchg(&q->blk_trace, old_bt);
+ if (cmpxchg(&q->blk_trace, NULL, bt))
goto err;
- }
if (atomic_inc_return(&blk_probes_ref) == 1)
blk_register_tracepoints();
@@ -1481,7 +1478,7 @@ static int blk_trace_remove_queue(struct request_queue *q)
static int blk_trace_setup_queue(struct request_queue *q,
struct block_device *bdev)
{
- struct blk_trace *old_bt, *bt = NULL;
+ struct blk_trace *bt = NULL;
int ret = -ENOMEM;
bt = kzalloc(sizeof(*bt), GFP_KERNEL);
@@ -1497,12 +1494,9 @@ static int blk_trace_setup_queue(struct request_queue *q,
blk_trace_setup_lba(bt, bdev);
- old_bt = xchg(&q->blk_trace, bt);
- if (old_bt != NULL) {
- (void)xchg(&q->blk_trace, old_bt);
- ret = -EBUSY;
+ ret = -EBUSY;
+ if (cmpxchg(&q->blk_trace, NULL, bt))
goto free_bt;
- }
if (atomic_inc_return(&blk_probes_ref) == 1)
blk_register_tracepoints();
--
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] perf tools: Allow BPF program attach to modules
By extending the syntax of BPF object section names, this patch allows
user to attach BPF programs to symbol in modules. For example:
SEC("module=i915\n"
"parse_cmds=i915_parse_cmds")
int parse_cmds(void *ctx)
{
return 1;
}
Implementation is very simple: like what 'perf probe' does, for module,
fill 'uprobe' field in 'struct perf_probe_event'. Other parts would be
done automatically.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo
Link: http://lkml.kernel.org/n/ebpf-x1mxko3tby054o573zd57...@git.kernel.org
---
This patch is based on commit ad14ba45236a496a7ce25f4ea947d245b1406e40
in my git tree[1], and will be appear in the next pull request of this
perf eBPF support patchset.
[1] https://git.kernel.org/cgit/linux/kernel/git/pi3orama/linux.git
---
tools/perf/util/bpf-loader.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index b14aff4..a85caae 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -120,10 +120,17 @@ do_config(const char *key, const char *value,
pev->target = strdup(value);
return 0;
}
+ if (strcmp(key, "module") == 0) {
+ pev->uprobes = false;
+ pev->target = strdup(value);
+ return 0;
+ }
pr_warning("BPF: WARNING: invalid config option in object: %s=%s\n",
key, value);
- pr_warning("\tHint: Currently only valid option is 'exec='\n");
+ pr_warning("\tHint: Currently valid options are:\n");
+ pr_warning("\t 'exec='\n");
+ pr_warning("\t 'module='\n");
return 0;
}
--
1.8.3.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: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > This patch fixes two problems to make value-returning atomics and
> > {cmp}xchg fully ordered on PPC.
>
> Hi Boqun,
>
> Can you please split this into two patches. One that does the cmpxchg change
> and one that changes PPC_ATOMIC_ENTRY_BARRIER.
>
OK, make sense ;-)
> Also given how pervasive this change is I'd like to take it via the powerpc
> next tree, so can you please send this patch (which will be two after you
> split
> it) as powerpc patches. And the rest can go via tip?
>
One problem is that patch 5 will remove __xchg_u32 and __xchg_64
entirely, which are modified in this patch(patch 1), so there will be
some conflicts if two branch get merged, I think.
Alternative way is that all this series go to powerpc next tree as most
of the dependent patches are already there. I just need to remove
inc/dec related code and resend them when appropriate. Besides, I can
pull patch 2 out and send it as a tip patch because it's general code
and no one depends on this in this series.
To summerize:
patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
powerpc patches for powerpc next, patch 2(unmodified) sent as tip patch
for locking/core.
Peter and Michael, this works for you both?
Regards,
signature.asc
Description: PGP signature
[PATCH] blktrace: re-write setting q->blk_trace
This is really about simplifying the double xchg patterns into
a single cmpxchg, with the same logic. Other than the immediate
cleanup, there are some subtleties this change deals with:
(i) While the load of the old bt is fully ordered wrt everything,
ie:
old_bt = xchg(&q->blk_trace, bt); [barrier]
if (old_bt)
(void) xchg(&q->blk_trace, old_bt);[barrier]
blk_trace could still be changed between the xchg and the old_bt
load. Note that this description is merely theoretical and afaict
very small, but doing everything in a single context with cmpxchg
closes this potential race.
(ii) Ordering guarantees are obviously kept with cmpxchg.
Signed-off-by: Davidlohr Bueso
---
kernel/trace/blktrace.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 90e72a0..4a30229 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -437,7 +437,7 @@ int do_blk_trace_setup(struct request_queue *q, char *name,
dev_t dev,
struct block_device *bdev,
struct blk_user_trace_setup *buts)
{
- struct blk_trace *old_bt, *bt = NULL;
+ struct blk_trace *bt = NULL;
struct dentry *dir = NULL;
int ret;
@@ -519,11 +519,8 @@ int do_blk_trace_setup(struct request_queue *q, char
*name, dev_t dev,
bt->trace_state = Blktrace_setup;
ret = -EBUSY;
- old_bt = xchg(&q->blk_trace, bt);
- if (old_bt) {
- (void) xchg(&q->blk_trace, old_bt);
+ if (cmpxchg(&q->blk_trace, NULL, bt))
goto err;
- }
if (atomic_inc_return(&blk_probes_ref) == 1)
blk_register_tracepoints();
@@ -1481,7 +1478,7 @@ static int blk_trace_remove_queue(struct request_queue *q)
static int blk_trace_setup_queue(struct request_queue *q,
struct block_device *bdev)
{
- struct blk_trace *old_bt, *bt = NULL;
+ struct blk_trace *bt = NULL;
int ret = -ENOMEM;
bt = kzalloc(sizeof(*bt), GFP_KERNEL);
@@ -1497,12 +1494,8 @@ static int blk_trace_setup_queue(struct request_queue *q,
blk_trace_setup_lba(bt, bdev);
- old_bt = xchg(&q->blk_trace, bt);
- if (old_bt != NULL) {
- (void)xchg(&q->blk_trace, old_bt);
- ret = -EBUSY;
+ if (cmpxchg(&q->blk_trace, NULL, bt))
goto free_bt;
- }
if (atomic_inc_return(&blk_probes_ref) == 1)
blk_register_tracepoints();
--
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 net] macvtap: unbreak receiving of gro skb with frag list
On 10/26/2015 04:30 PM, Michael S. Tsirkin wrote:
> On Mon, Oct 26, 2015 at 02:53:38PM +0800, Jason Wang wrote:
>>
>> On 10/26/2015 02:09 PM, Michael S. Tsirkin wrote:
>>> On Mon, Oct 26, 2015 at 11:15:57AM +0800, Jason Wang wrote:
On 10/23/2015 09:37 PM, Michael S. Tsirkin wrote:
> On Fri, Oct 23, 2015 at 12:57:05AM -0400, Jason Wang wrote:
>> We don't have fraglist support in TAP_FEATURES. This will lead
>> software segmentation of gro skb with frag list. Fixes by having
>> frag list support in TAP_FEATURES.
>>
>> With this patch single session of netperf receiving were restored from
>> about 5Gb/s to about 12Gb/s on mlx4.
>>
>> Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
>> Cc: Vlad Yasevich
>> Cc: Michael S. Tsirkin
>> Signed-off-by: Jason Wang
> Thanks!
> Does this mean we should look at re-adding NETIF_F_FRAGLIST
> to virtio-net as well?
Not sure I get the point, but probably not. This is for receiving and
skb_copy_datagram_iter() can deal with frag list.
>>> Point is:
>>> - bridge within guest
>>> - assigned device creating gro skbs with frag list bridged to virtio
>> I see, but this problem looks not specific to virtio. Most cards does
>> not support frag list.
> These will be slower when used with a bridge then, won't they?
For forwarding, not sure. GRO has latency and cpu overhead anyway.
Anyway I can try to add the support for this.
--
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: kernel: utilize hrtimer based broadcast
Hi, Mark, Could you comment this patch? It is based on your suggestion in https://patchwork.kernel.org/patch/6764231/ . Thanks. Best Regards, Alison Wang > -Original Message- > From: Alison Wang [mailto:b18...@freescale.com] > Sent: Friday, July 17, 2015 5:12 PM > To: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org > Cc: Wang Huan-B18965 > Subject: [PATCH] arm: kernel: utilize hrtimer based broadcast > > Hrtimer based broadcast is used on ARM platform. It can be registered as > the tick broadcast device in the absence of a real external clock device. > > Signed-off-by: Alison Wang > --- > arch/arm/kernel/time.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index > a66e37e..a9bc73c 100644 > --- a/arch/arm/kernel/time.c > +++ b/arch/arm/kernel/time.c > @@ -12,6 +12,7 @@ > * reading the RTC at bootup, etc... > */ > #include > +#include > #include > #include > #include > @@ -121,5 +122,7 @@ void __init time_init(void) > of_clk_init(NULL); > #endif > clocksource_of_init(); > + > + tick_setup_hrtimer_broadcast(); > } > } > -- > 2.1.0.27.g96db324 -- 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 PATCH] x86/cpu: Move sparsely used bit leafs into scattered features (was: Re: [PATCH 2/2] x86/cpufeature: Add CLZERO feature)
On Mon, Oct 26, 2015 at 2:01 PM, Borislav Petkov wrote: > On Mon, Oct 26, 2015 at 09:22:50PM +0100, Borislav Petkov wrote: >> And btw, those Intel QoS single bit defines and the XSAVE stuff there >> should move to that function too - that's a pure waste having them in >> the cap_flags array. I'll fix that. > > I.e., something like that (I'm jetlagged and I can't sleep, bah :-\). > > So this one builds but no further guarantees. It looks straightforward > though. > > Not-yet-signed-off-by: Borislav Petkov > > --- > diff --git a/arch/x86/include/asm/cpufeature.h > b/arch/x86/include/asm/cpufeature.h > index 9727b3b48bd1..ea109b58a864 100644 > --- a/arch/x86/include/asm/cpufeature.h > +++ b/arch/x86/include/asm/cpufeature.h > @@ -12,7 +12,7 @@ > #include > #endif > > -#define NCAPINTS 13 /* N 32-bit words worth of info */ > +#define NCAPINTS 10 /* N 32-bit words worth of info */ > #define NBUGINTS 1 /* N 32-bit bug flags */ > > /* > @@ -198,6 +198,15 @@ > #define X86_FEATURE_HWP_EPP( 7*32+13) /* Intel HWP_EPP */ > #define X86_FEATURE_HWP_PKG_REQ ( 7*32+14) /* Intel HWP_PKG_REQ */ > #define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */ > +/* Extended state features, CPUID level 0x000d:1 (eax) */ > +#define X86_FEATURE_XSAVEOPT (7*32+ 16) /* XSAVEOPT */ > +#define X86_FEATURE_XSAVEC (7*32+ 17) /* XSAVEC */ > +#define X86_FEATURE_XGETBV1(7*32+ 18) /* XGETBV with ECX = 1 */ > +#define X86_FEATURE_XSAVES (7*32+ 19) /* XSAVES/XRSTORS */ How few features in one leaf do we need before calling it scattered makes sense? These four might make sense to keep as is... > +/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:0 (edx) */ > +#define X86_FEATURE_CQM_LLC(7*32+ 20) /* LLC QoS if 1 */ > +/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:1 (edx) */ > +#define X86_FEATURE_CQM_OCCUP_LLC (7*32+ 21) /* LLC occupancy monitoring if > 1 */ > ...whereas this looks totally reasonable. FWIW, we have a ton of thses things. Would it make sense to convert this to a text file giving features and their CPUID positions that generates the defines and the code to enumerate them? --Andy -- 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 05/10] hwmon: (fam15h_power) Add compute unit accumulated power
On Fri, Oct 23, 2015 at 03:27:02PM +0200, Borislav Petkov wrote:
> On Tue, Oct 20, 2015 at 10:28:24AM +0800, Huang Rui wrote:
> > This patch adds a member in fam15h_power_data which specifies the
> > compute unit accumulated power. It adds do_read_registers_on_cu to do
> > all the read to all MSRs and run it on one of the online cores on each
> > compute unit with smp_call_function_many(). This behavior can decrease
> > IPI numbers.
> >
> > Suggested-by: Borislav Petkov
> > Signed-off-by: Huang Rui
> > Cc: Guenter Roeck
> > Cc: Peter Zijlstra
> > Cc: Ingo Molnar
> > ---
> > drivers/hwmon/fam15h_power.c | 68
> > +++-
> > 1 file changed, 67 insertions(+), 1 deletion(-)
> >
> > +
> > +static int read_registers(struct fam15h_power_data *data)
> > +{
> > + int this_cpu, ret;
> > + int cu_num, cores_per_cu, cpu, cu;
> > + cpumask_var_t mask;
> > +
> > + cores_per_cu = amd_get_cores_per_cu();
> > + cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > + WARN_ON_ONCE(cu_num > MAX_CUS);
> > +
> > + ret = zalloc_cpumask_var(&mask, GFP_KERNEL);
> > + if (!ret)
> > + return -ENOMEM;
> > +
> > + this_cpu = get_cpu();
>
> This should be get_online_cpus() and its counterpart below should be
> put_online_cpus().
>
Preemption must be disabled when calling smp_call_function_many,
get_cpu would did that. Will get_online_cpus have the same behavior
like that?
> > +
> > + /*
> > +* Choose the first online core of each compute unit, and then
> > +* read their MSR value of power and ptsc in one time of IPI,
>
> in a single IPI.
>
> > +* because the MSR value of cpu core represent the compute
>
> s/cpu/CPU/
>
> do that in *all* your text.
>
> > +* unit's. This behavior can decrease IPI numbers between the
>
> unit's ?
>
> What does that sentence even mean?
>
That means "the value(cu_acc_power) of the compute unit", which does
not represent the value of one CPU core.
> > +* cores.
> > +*/
> > + cpu = cpumask_first(cpu_online_mask);
> > + cu = cpu / cores_per_cu;
> > + while (cpu < boot_cpu_data.x86_max_cores) {
> > + if (cu <= cpu / cores_per_cu) {
> > + cu = cpu / cores_per_cu + 1;
> > + cpumask_set_cpu(cpu, mask);
> > + }
> > + cpu = cpumask_next(cu * cores_per_cu - 1, cpu_online_mask);
> > + }
>
> This is hard to parse - I *think* you're setting a bit in mask for a
> core in each CU...
>
Yes, that's right.
My codes' behavior is below:
Assumed cores_per_cu is 4 and cu_number is 6, and the online cpumask
is:
cu5 cu4 cu3 cu2 cu1 cu0
1000_1100_0110_1011__
After setting bits of the mask:
1000_0100_0010_0001__0001
on on on on off on
> If so, I think you can simplify it by generating a tmp mask which
> contains the cores of CU0, i.e. something like that:
>
> 11_00_00_...
>
> and then do cpumask_and(res, ...) to find the online cores on that CU
> and then do cpumask_set_cpu(cpumask_any(res), mask) to select one CPU on
> that CU.
>
> And then shift to the next CU:
>
> cpumask_shift_right(dst, src_mask, cores_per_cu);
>
> I think this should be cleaner and less error prone, without the
> conditionals...
>
OK, how about below codes:
---
for (i = 0; i <= cores_per_cu / BITS_PER_LONG; i++) {
offset = cores_per_cu % BITS_PER_LONG;
if (i == cores_per_cu / BITS_PER_LONG) {
cpumask_bits(src_mask)[i] = GENMASK(offset -1, 0);
break;
}
cpumask_bits(src_mask)[i] = GENMASK(BITS_PER_LONG - 1, 0);
}
for (i = 0; i < cu_num; i++) {
cpumask_shift_left(dst, src_mask, cores_per_cu * i);
cpumask_and(res, dst, cpu_online_mask);
cpumask_set_cpu(cpumask_any(res), mask);
}
---
Thanks,
Rui
--
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] perf, tools, stat: Implement --metric-only mode
Here's a v2 that fixes a problem in --per-core mode.
---
Add a new mode to only print metrics. Sometimes we don't care about
the raw values, just want the computed metrics. This allows more
compact printing, so with -I each sample is only a single line.
This also allows easier plotting and processing with other tools.
The main target is with using --topdown, but it also works with
-T and standard perf stat. A few metrics are not supported.
To avoiding having to hardcode all the metrics in the code it uses
a two pass approach: first compute dummy metrics and only
print the headers in the print_metric callback. Then use the callback
to print the actual values. There are some additional changes
in the stat printout code to handle all metrics being on a single line.
Example:
% perf stat -a -I 1000 --metric-only
1.000604977 frontend cycles idle backend cycles idle insn per
cycle stalled cycles per insn branch-misses of all branches
1.0006049770.76
2.35%
2.0009246800.72
2.34%
3.0011395920.76
2.57%
4.0013584520.73
2.44%
The output is fairly wide, but that's a trade off for the concise format.
v2: Fix --per-socket/core extra prefix printing.
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-stat.txt | 4 +
tools/perf/builtin-stat.c | 201 +++--
2 files changed, 196 insertions(+), 9 deletions(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 079b141..58296e7 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -132,6 +132,10 @@ Print count deltas every N milliseconds (minimum: 10ms)
The overhead percentage could be high in some cases, for instance with small,
sub 100ms intervals. Use with caution.
example: 'perf stat -I 1000 -e cycles -a sleep 5'
+--metric-only::
+Only print computed metrics. Print them in a single line.
+Don't show any raw values. Not supported with -A or --per-thread.
+
--per-socket::
Aggregate counts per processor socket for system-wide mode measurements. This
is a useful mode to detect imbalance between sockets. To enable this mode,
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 4042b97..6b3e89a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -117,6 +117,7 @@ static bool sync_run
= false;
static unsigned intinitial_delay = 0;
static unsigned intunit_width = 4; /*
strlen("unit") */
static boolforever = false;
+static boolmetric_only = false;
static struct timespec ref_time;
static struct cpu_map *aggr_map;
static int (*aggr_get_id)(struct cpu_map *m, int cpu);
@@ -572,6 +573,99 @@ static void print_metric_csv(void *ctx,
fprintf(out, "%s%s%s", vals, csv_sep, unit);
}
+#define METRIC_ONLY_LEN 24
+
+/* Filter out some columns that don't work well in metrics only mode */
+
+static bool valid_only_metric(const char *unit)
+{
+ if (!unit)
+ return false;
+ if (strstr(unit, "/sec") ||
+ strstr(unit, "hz") ||
+ strstr(unit, "Hz") ||
+ strstr(unit, "CPUs utilized"))
+ return false;
+ return true;
+}
+
+static const char *fixunit(char *buf, struct perf_evsel *evsel,
+ const char *unit)
+{
+ if (!strncmp(unit, "of all", 6)) {
+ snprintf(buf, 1024, "%s %s", perf_evsel__name(evsel),
+unit);
+ return buf;
+ }
+ return unit;
+}
+
+static void print_metric_only(void *ctx, const char *color, const char *fmt,
+ const char *unit, double val)
+{
+ struct outstate *os = ctx;
+ FILE *out = os->fh;
+ int n;
+ char buf[1024];
+ unsigned mlen = METRIC_ONLY_LEN;
+
+ if (!valid_only_metric(unit))
+ return;
+ unit = fixunit(buf, os->evsel, unit);
+ if (color)
+ n = color_fprintf(out, color, fmt, val);
+ else
+ n = fprintf(out, fmt, val);
+ if (n > METRIC_ONLY_LEN)
+ n = METRIC_ONLY_LEN;
+ if (mlen < strlen(unit))
+ mlen = strlen(unit) + 1;
+ fprintf(out, "%*s", mlen - n, "");
+}
+
+static void print_metric_only_csv(void *ctx, const char *color __maybe_unused,
+ con
Re: [PATCH] get_maintainer: Don't fallback to git by default
What if we have a git_fallback "auto" mode which only falls back to using git if there is no entry in the MAINTAINERS file? That might address the concern which Laura raised, without blocking this change until the MAINTAINERS file is fully populated. Cheers, - Ted -- 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] ARM: multi_v7_defconfig: enable UniPhier I2C drivers
These two drivers were merged into the I2C sub-system by
commit dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver")
and commit 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C
driver").
Enable them from arch/arm/configs/multi_v7_defconfig.
Signed-off-by: Masahiro Yamada
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index bfd74fe..90e2b68 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -308,6 +308,8 @@ CONFIG_I2C_SIRF=y
CONFIG_I2C_ST=y
CONFIG_I2C_SUN6I_P2WI=y
CONFIG_I2C_TEGRA=y
+CONFIG_I2C_UNIPHIER=y
+CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_XILINX=y
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=m
--
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 5/9] perf, tools, stat: Move noise/running printing into printout
On Mon, Oct 26, 2015 at 04:32:06PM +0100, Jiri Olsa wrote:
> On Fri, Oct 23, 2015 at 04:59:33PM -0700, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > Move the running/noise printing into printout to avoid
> > duplicated code in the callers.
> >
> > v2: Merged with other patches. Remove unnecessary hunk.
> > Readd hunk that ended in earlier patch.
> > Signed-off-by: Andi Kleen
>
> hit the same issue as in previous version described in here:
>
> http://marc.info/?l=linux-kernel&m=144308533308176&w=2
>
> on your perf/stat-metrics-9
Here's an updated patch and I pushed perf/stat-metrics-10
---
Move the running/noise printing into printout to avoid
duplicated code in the callers.
v2: Merged with other patches. Remove unnecessary hunk.
Readd hunk that ended in earlier patch.
v3: Fix noise/running output in CSV mode
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 50 ---
1 file changed, 8 insertions(+), 42 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f78af2a..f995911 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -586,7 +586,7 @@ static void abs_printout(int id, int nr, struct perf_evsel
*evsel, double avg)
}
static void printout(int id, int nr, struct perf_evsel *counter, double uval,
-char *prefix)
+char *prefix, u64 run, u64 ena, double noise)
{
struct perf_stat_output_ctx out;
struct outstate os = {
@@ -612,6 +612,9 @@ static void printout(int id, int nr, struct perf_evsel
*counter, double uval,
stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
cpu_map__id_to_cpu(id),
&out);
+
+ print_noise(counter, noise);
+ print_running(run, ena);
}
static void print_aggr(char *prefix)
@@ -667,11 +670,7 @@ static void print_aggr(char *prefix)
continue;
}
uval = val * counter->scale;
- printout(id, nr, counter, uval, prefix);
- if (!csv_output)
- print_noise(counter, 1.0);
-
- print_running(run, ena);
+ printout(id, nr, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -698,12 +697,7 @@ static void print_aggr_thread(struct perf_evsel *counter,
char *prefix)
fprintf(output, "%s", prefix);
uval = val * counter->scale;
- printout(thread, 0, counter, uval, prefix);
-
- if (!csv_output)
- print_noise(counter, 1.0);
-
- print_running(run, ena);
+ printout(thread, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
}
}
@@ -717,7 +711,6 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
FILE *output = stat_config.output;
struct perf_stat_evsel *ps = counter->priv;
double avg = avg_stats(&ps->res_stats[0]);
- int scaled = counter->counts->scaled;
double uval;
double avg_enabled, avg_running;
@@ -727,32 +720,8 @@ static void print_counter_aggr(struct perf_evsel *counter,
char *prefix)
if (prefix)
fprintf(output, "%s", prefix);
- if (scaled == -1 || !counter->supported) {
- fprintf(output, "%*s%s",
- csv_output ? 0 : 18,
- counter->supported ? CNTR_NOT_COUNTED :
CNTR_NOT_SUPPORTED,
- csv_sep);
- fprintf(output, "%-*s%s",
- csv_output ? 0 : unit_width,
- counter->unit, csv_sep);
- fprintf(output, "%*s",
- csv_output ? 0 : -25,
- perf_evsel__name(counter));
-
- if (counter->cgrp)
- fprintf(output, "%s%s", csv_sep, counter->cgrp->name);
-
- print_running(avg_running, avg_enabled);
- fputc('\n', output);
- return;
- }
-
uval = avg * counter->scale;
- printout(-1, 0, counter, uval, prefix);
-
- print_noise(counter, avg);
-
- print_running(avg_running, avg_enabled);
+ printout(-1, 0, counter, uval, prefix, avg_running, avg_enabled, avg);
fprintf(output, "\n");
}
@@ -801,10 +770,7 @@ static void print_counter(struct perf_evsel *counter, char
*prefix)
}
uval = val * counter->scale;
- printout(cpu, 0, counter, uval, prefix);
- if (!csv_output)
- print_noise(counter, 1.0);
- print_running(run, ena);
+ printout(cpu, 0, counter, uval, prefix, run, ena, 1.0);
fputc('\n', output);
[PATCH] mtd: blkdevs: fix potential deadlock + lockdep warnings
Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.
The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.
-> blktrans_open()
-> mutex_lock(&dev->lock);
-> mutex_lock(&mtd_table_mutex);
-> del_mtd_device()
-> mutex_lock(&mtd_table_mutex);
-> blktrans_notify_remove() -> del_mtd_blktrans_dev()
-> mutex_lock(&dev->lock);
This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:
if (mutex_trylock(&mtd_table_mutex)) {
mutex_unlock(&mtd_table_mutex);
BUG();
}
So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.
Snippets of the lockdep output follow:
# modprobe -r m25p80
[ 53.419251]
[ 53.420838] ==
[ 53.427300] [ INFO: possible circular locking dependency detected ]
[ 53.433865] 4.3.0-rc6 #96 Not tainted
[ 53.437686] ---
[ 53.444220] modprobe/372 is trying to acquire lock:
[ 53.449320] (&new->lock){+.+...}, at: []
del_mtd_blktrans_dev+0x80/0xdc
[ 53.457271]
[ 53.457271] but task is already holding lock:
[ 53.463372] (mtd_table_mutex){+.+.+.}, at: []
del_mtd_device+0x18/0x100
[ 53.471321]
[ 53.471321] which lock already depends on the new lock.
[ 53.471321]
[ 53.479856]
[ 53.479856] the existing dependency chain (in reverse order) is:
[ 53.487660]
-> #1 (mtd_table_mutex){+.+.+.}:
[ 53.492331][] blktrans_open+0x34/0x1a4
[ 53.497879][] __blkdev_get+0xc4/0x3b0
[ 53.503364][] blkdev_get+0x108/0x320
[ 53.508743][] do_dentry_open+0x218/0x314
[ 53.514496][] path_openat+0x4c0/0xf9c
[ 53.519959][] do_filp_open+0x5c/0xc0
[ 53.525336][] do_sys_open+0xfc/0x1cc
[ 53.530716][] ret_fast_syscall+0x0/0x1c
[ 53.536375]
-> #0 (&new->lock){+.+...}:
[ 53.540587][] mutex_lock_nested+0x38/0x3cc
[ 53.546504][] del_mtd_blktrans_dev+0x80/0xdc
[ 53.552606][] blktrans_notify_remove+0x7c/0x84
[ 53.558891][] del_mtd_device+0x74/0x100
[ 53.564544][] del_mtd_partitions+0x80/0xc8
[ 53.570451][] mtd_device_unregister+0x24/0x48
[ 53.576637][] spi_drv_remove+0x1c/0x34
[ 53.582207][] __device_release_driver+0x88/0x114
[ 53.588663][] device_release_driver+0x20/0x2c
[ 53.594843][] bus_remove_device+0xd8/0x108
[ 53.600748][] device_del+0x10c/0x210
[ 53.606127][] device_unregister+0xc/0x20
[ 53.611849][] __unregister+0x10/0x20
[ 53.617211][] device_for_each_child+0x50/0x7c
[ 53.623387][] spi_unregister_master+0x58/0x8c
[ 53.629578][] release_nodes+0x15c/0x1c8
[ 53.635223][] __device_release_driver+0x90/0x114
[ 53.641689][] driver_detach+0xb4/0xb8
[ 53.647147][] bus_remove_driver+0x4c/0xa0
[ 53.652970][] SyS_delete_module+0x11c/0x1e4
[ 53.658976][] ret_fast_syscall+0x0/0x1c
[ 53.664621]
[ 53.664621] other info that might help us debug this:
[ 53.664621]
[ 53.672979] Possible unsafe locking scenario:
[ 53.672979]
[ 53.679169]CPU0CPU1
[ 53.683900]
[ 53.688633] lock(mtd_table_mutex);
[ 53.692383]lock(&new->lock);
[ 53.698306]lock(mtd_table_mutex);
[ 53.704658] lock(&new->lock);
[ 53.707946]
[ 53.707946] *** DEADLOCK ***
Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount")
Reported-by: Felipe Balbi
Tested-by: Felipe Balbi
Signed-off-by: Brian Norris
Cc:
---
Resending as a proper patch
Note: I tried to reproduce this lockdep warning myself but couldn't. But I saw
no problem under the new patch either.
drivers/mtd/mtd_blkdevs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 44dc965a2f7c..e7a02ed9fba8 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -192,8 +192,8 @@ static int blktrans_open(struct bl
[PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node
It seems more logical to use a device node directly associated with the
MTD master device (i.e., mtd->dev.of_node field) rather than requiring
auxiliary partition parser information to be passed in by the driver in
a separate struct.
This patch supports the mtd->dev.of_node field, deprecates the parser
data 'of_node' field, and begins using the new convention for nand_base.
Other NAND driver conversions may now follow.
Additional side benefit to assigning mtd->dev.of_node rather than using
parser data: the driver core will automatically create a device -> node
symlink for us.
Signed-off-by: Brian Norris
---
drivers/mtd/nand/nand_base.c | 3 +++
drivers/mtd/ofpart.c | 18 ++
drivers/mtd/spi-nor/spi-nor.c | 1 +
include/linux/mtd/partitions.h | 4 +++-
4 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index cc74142938b0..d2e7fee2ac37 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3990,6 +3990,9 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
int ret;
if (chip->flash_node) {
+ /* MTD can automatically handle DT partitions, etc. */
+ mtd->dev.of_node = chip->flash_node;
+
ret = nand_dt_init(mtd, chip, chip->flash_node);
if (ret)
return ret;
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index aa26c32e1bc2..a5dfd73cfc7d 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -35,10 +35,11 @@ static int parse_ofpart_partitions(struct mtd_info *master,
int nr_parts, i;
- if (!data)
- return 0;
-
- node = data->of_node;
+ /*
+* of_node can be provided through auxiliary parser data or (preferred)
+* by assigning the master device
+*/
+ node = data && data->of_node ? data->of_node : master->dev.of_node;
if (!node)
return 0;
@@ -120,10 +121,11 @@ static int parse_ofoldpart_partitions(struct mtd_info
*master,
} *part;
const char *names;
- if (!data)
- return 0;
-
- dp = data->of_node;
+ /*
+* of_node can be provided through auxiliary parser data or (preferred)
+* by assigning the master device
+*/
+ dp = data && data->of_node ? data->of_node : master->dev.of_node;
if (!dp)
return 0;
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 49883905a434..8f9080c6db63 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1258,6 +1258,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
enum read_mode mode)
mtd->flags |= MTD_NO_ERASE;
mtd->dev.parent = dev;
+ mtd->dev.of_node = np;
nor->page_size = info->page_size;
mtd->writebufsize = nor->page_size;
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 6a35e6de5da1..e742f34b67eb 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -56,7 +56,9 @@ struct device_node;
/**
* struct mtd_part_parser_data - used to pass data to MTD partition parsers.
* @origin: for RedBoot, start address of MTD device
- * @of_node: for OF parsers, device node containing partitioning information
+ * @of_node: for OF parsers, device node containing partitioning information.
+ * This field is deprecated, as the device node should simply be
+ * assigned to the master struct device.
*/
struct mtd_part_parser_data {
unsigned long origin;
--
2.6.0.rc2.230.g3dd15c0
--
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] efi: Fix warning of int-to-pointer-cast on x86 32-bit builds
On 27 October 2015 at 06:02, Matt Fleming wrote: > On Fri, 23 Oct, at 10:37:46AM, Ard Biesheuvel wrote: >> >> After looking at the original (already merged) patch 11/11 again, I >> realize this is still not right: the problem is that efi_memory_map's >> phys_map member uses a void* type to hold a physical address, which >> happens to be correct in the normal case even when phys_addr_t is >> larger than void* (like on ARM with LPAE enabled) since the address it >> holds is the address of an allocation performed by the firmware, which >> only uses 1:1 addressable memory. >> >> However, overwriting memmap.phys_map with a value produced my >> memblock_alloc() is problematic, since the allocation may be above 4 >> GB on 32-bit (L)PAE platforms. So the correct way to do this would be >> to set the memblock limit to 4GB before memblock_alloc() on 32-bit >> platforms, and restore it afterwards. This is a bit of a kludge, >> though, and it would be more correct to change the type of >> efi_memory_map::phys_map to phys_addr_t, although I don't know what >> the potential fallout of that change is. Matt? > > I think that should be fine. The only potentially tricky situation we > could encounter is where 32-bit x86 firmware uses PAE but the kernel > is built without support. > > But that's not something I've ever seen enabled in the firmware and > there's a bunch of assumptions in the kernel already that would break > in that case. > Does UEFI even allow that? Even if it can describe memory over 4 GB, it uses a flat mapping so allocations done by the stub (which retrieves the memory map) should never reside at addresses over 4 GB. -- Ard. -- 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: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered
On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> This patch fixes two problems to make value-returning atomics and
> {cmp}xchg fully ordered on PPC.
Hi Boqun,
Can you please split this into two patches. One that does the cmpxchg change
and one that changes PPC_ATOMIC_ENTRY_BARRIER.
Also given how pervasive this change is I'd like to take it via the powerpc
next tree, so can you please send this patch (which will be two after you split
it) as powerpc patches. And the rest can go via tip?
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/
[PATCH 3/5] mtd: spi-nor: drop unnecessary partition parser data
Now that the SPI-NOR/MTD framework pass the 'flash_node' through to the
partition parsing code, we don't have to do it ourselves.
Also convert to mtd_device_register(), since we don't need the 2nd and
3rd parameters anymore.
Signed-off-by: Brian Norris
---
drivers/mtd/devices/m25p80.c | 8 ++--
drivers/mtd/spi-nor/fsl-quadspi.c | 4 +---
drivers/mtd/spi-nor/nxp-spifi.c | 4 +---
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 4b5d7a4655fd..d86fa1ae6d1f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -175,7 +175,6 @@ static int m25p80_erase(struct spi_nor *nor, loff_t offset)
*/
static int m25p_probe(struct spi_device *spi)
{
- struct mtd_part_parser_data ppdata;
struct flash_platform_data *data;
struct m25p *flash;
struct spi_nor *nor;
@@ -227,11 +226,8 @@ static int m25p_probe(struct spi_device *spi)
if (ret)
return ret;
- ppdata.of_node = spi->dev.of_node;
-
- return mtd_device_parse_register(&nor->mtd, NULL, &ppdata,
- data ? data->parts : NULL,
- data ? data->nr_parts : 0);
+ return mtd_device_register(&nor->mtd, data ? data->parts : NULL,
+ data ? data->nr_parts : 0);
}
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 7b10ed413983..95991a2197e8 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -927,7 +927,6 @@ static void fsl_qspi_unprep(struct spi_nor *nor, enum
spi_nor_ops ops)
static int fsl_qspi_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct mtd_part_parser_data ppdata;
struct device *dev = &pdev->dev;
struct fsl_qspi *q;
struct resource *res;
@@ -1038,8 +1037,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
if (ret)
goto mutex_failed;
- ppdata.of_node = np;
- ret = mtd_device_parse_register(mtd, NULL, &ppdata, NULL, 0);
+ ret = mtd_device_register(mtd, NULL, 0);
if (ret)
goto mutex_failed;
diff --git a/drivers/mtd/spi-nor/nxp-spifi.c b/drivers/mtd/spi-nor/nxp-spifi.c
index 9e82098ae644..9414495a73cb 100644
--- a/drivers/mtd/spi-nor/nxp-spifi.c
+++ b/drivers/mtd/spi-nor/nxp-spifi.c
@@ -271,7 +271,6 @@ static void nxp_spifi_dummy_id_read(struct spi_nor *nor)
static int nxp_spifi_setup_flash(struct nxp_spifi *spifi,
struct device_node *np)
{
- struct mtd_part_parser_data ppdata;
enum read_mode flash_read;
u32 ctrl, property;
u16 mode = 0;
@@ -361,8 +360,7 @@ static int nxp_spifi_setup_flash(struct nxp_spifi *spifi,
return ret;
}
- ppdata.of_node = np;
- ret = mtd_device_parse_register(&spifi->nor.mtd, NULL, &ppdata, NULL,
0);
+ ret = mtd_device_register(&spifi->nor.mtd, NULL, 0);
if (ret) {
dev_err(spifi->dev, "mtd device parse failed\n");
return ret;
--
2.6.0.rc2.230.g3dd15c0
--
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 5/5] mtd: drop 'of_node' partition parser data
This field is no longer used anywhere, as it is superseded by
mtd->dev.of_node.
Signed-off-by: Brian Norris
---
drivers/mtd/ofpart.c | 14 --
include/linux/mtd/partitions.h | 4
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index a5dfd73cfc7d..4368badfc653 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -35,11 +35,8 @@ static int parse_ofpart_partitions(struct mtd_info *master,
int nr_parts, i;
- /*
-* of_node can be provided through auxiliary parser data or (preferred)
-* by assigning the master device
-*/
- node = data && data->of_node ? data->of_node : master->dev.of_node;
+ /* Pull of_node from the master device */
+ node = master->dev.of_node;
if (!node)
return 0;
@@ -121,11 +118,8 @@ static int parse_ofoldpart_partitions(struct mtd_info
*master,
} *part;
const char *names;
- /*
-* of_node can be provided through auxiliary parser data or (preferred)
-* by assigning the master device
-*/
- dp = data && data->of_node ? data->of_node : master->dev.of_node;
+ /* Pull of_node from the master device */
+ dp = master->dev.of_node;
if (!dp)
return 0;
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index e742f34b67eb..773975a3c9e6 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -56,13 +56,9 @@ struct device_node;
/**
* struct mtd_part_parser_data - used to pass data to MTD partition parsers.
* @origin: for RedBoot, start address of MTD device
- * @of_node: for OF parsers, device node containing partitioning information.
- * This field is deprecated, as the device node should simply be
- * assigned to the master struct device.
*/
struct mtd_part_parser_data {
unsigned long origin;
- struct device_node *of_node;
};
--
2.6.0.rc2.230.g3dd15c0
--
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 4/5] mtd: drop unnecessary partition parser data
We should assign the MTD dev.of_node instead of the parser data field.
This gets us the equivalent partition parser behavior with fewer special
fields and parameter passing.
Also convert several of these to mtd_device_register(), since we don't
need the 2nd and 3rd parameters anymore.
Signed-off-by: Brian Norris
---
drivers/mtd/devices/mtd_dataflash.c | 5 ++---
drivers/mtd/devices/spear_smi.c | 6 ++
drivers/mtd/devices/st_spi_fsm.c| 5 ++---
drivers/mtd/maps/lantiq-flash.c | 5 ++---
drivers/mtd/maps/physmap_of.c | 5 ++---
drivers/mtd/onenand/omap2.c | 8 +++-
6 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/devices/mtd_dataflash.c
b/drivers/mtd/devices/mtd_dataflash.c
index 39666d552682..0de40f5a7509 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -624,7 +624,6 @@ static int add_dataflash_otp(struct spi_device *spi, char
*name, int nr_pages,
{
struct dataflash*priv;
struct mtd_info *device;
- struct mtd_part_parser_data ppdata;
struct flash_platform_data *pdata = dev_get_platdata(&spi->dev);
char*otp_tag = "";
int err = 0;
@@ -656,6 +655,7 @@ static int add_dataflash_otp(struct spi_device *spi, char
*name, int nr_pages,
device->priv = priv;
device->dev.parent = &spi->dev;
+ device->dev.of_node = spi->dev.of_node;
if (revision >= 'c')
otp_tag = otp_setup(device, revision);
@@ -665,8 +665,7 @@ static int add_dataflash_otp(struct spi_device *spi, char
*name, int nr_pages,
pagesize, otp_tag);
spi_set_drvdata(spi, priv);
- ppdata.of_node = spi->dev.of_node;
- err = mtd_device_parse_register(device, NULL, &ppdata,
+ err = mtd_device_register(device,
pdata ? pdata->parts : NULL,
pdata ? pdata->nr_parts : 0);
diff --git a/drivers/mtd/devices/spear_smi.c b/drivers/mtd/devices/spear_smi.c
index 64c7458344d4..8c41cc82d860 100644
--- a/drivers/mtd/devices/spear_smi.c
+++ b/drivers/mtd/devices/spear_smi.c
@@ -810,7 +810,6 @@ static int spear_smi_setup_banks(struct platform_device
*pdev,
u32 bank, struct device_node *np)
{
struct spear_smi *dev = platform_get_drvdata(pdev);
- struct mtd_part_parser_data ppdata = {};
struct spear_smi_flash_info *flash_info;
struct spear_smi_plat_data *pdata;
struct spear_snor_flash *flash;
@@ -855,6 +854,7 @@ static int spear_smi_setup_banks(struct platform_device
*pdev,
flash->mtd.name = flash_devices[flash_index].name;
flash->mtd.dev.parent = &pdev->dev;
+ flash->mtd.dev.of_node = np;
flash->mtd.type = MTD_NORFLASH;
flash->mtd.writesize = 1;
flash->mtd.flags = MTD_CAP_NORFLASH;
@@ -881,10 +881,8 @@ static int spear_smi_setup_banks(struct platform_device
*pdev,
count = flash_info->nr_partitions;
}
#endif
- ppdata.of_node = np;
- ret = mtd_device_parse_register(&flash->mtd, NULL, &ppdata, parts,
- count);
+ ret = mtd_device_register(&flash->mtd, parts, count);
if (ret) {
dev_err(&dev->pdev->dev, "Err MTD partition=%d\n", ret);
return ret;
diff --git a/drivers/mtd/devices/st_spi_fsm.c b/drivers/mtd/devices/st_spi_fsm.c
index 3060025c8af4..16cd44f728c1 100644
--- a/drivers/mtd/devices/st_spi_fsm.c
+++ b/drivers/mtd/devices/st_spi_fsm.c
@@ -2025,7 +2025,6 @@ boot_device_fail:
static int stfsm_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct mtd_part_parser_data ppdata;
struct flash_info *info;
struct resource *res;
struct stfsm *fsm;
@@ -2035,7 +2034,6 @@ static int stfsm_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "No DT found\n");
return -EINVAL;
}
- ppdata.of_node = np;
fsm = devm_kzalloc(&pdev->dev, sizeof(*fsm), GFP_KERNEL);
if (!fsm)
@@ -2106,6 +2104,7 @@ static int stfsm_probe(struct platform_device *pdev)
fsm->mtd.name = info->name;
fsm->mtd.dev.parent = &pdev->dev;
+ fsm->mtd.dev.of_node= np;
fsm->mtd.type = MTD_NORFLASH;
fsm->mtd.writesize = 4;
fsm->mtd.writebufsize = fsm->mtd.writesize;
@@ -2124,7 +2123,7 @@ static int stfsm_probe(struct platform_device *pdev)
(long long)fsm->mtd.size, (long long)(fsm->mtd.size >> 20),
fsm->mtd.erasesize, (fsm->mtd.erasesize >> 10));
- return mtd_device_parse_register(&fsm->mtd, NULL, &ppdata, NULL, 0);
+ return mtd_device_register(&fsm->mtd, NULL, 0);
}
static int stfsm_remove(struct platform_device *pd
[PATCH 0/5] mtd: migrate 'of_node' handling to core, not in mtd_part_parser_data
Hi, I noticed that, for MTD drivers that want to support DT partition parsing (essentially all recent ones), it's a bit awkward to set the tell MTD which DT node to use. I also noticed that this info is duplicated in a few places; namely, some sub-subsystems (like SPI NOR and NAND) need their own field to track the DT node, so let's have the propagate the 'MTD' DT node down for us. Besides simplifying the boilerplate throughout MTD, this series also has the side effect of producing 'of_node' symlinks in sysfs. e.g.: # ls -al /sys/class/mtd/mtd0/of_node lrwxrwxrwx 1 root root 0 Oct 26 19:17 /sys/class/mtd/mtd0/of_node -> ../../../../firmware/devicetree/base/spi@ff13/flash@0 For NAND, this potentially has some other bigger initial side effects, since nand_dt_init() handles a bit more automagically for drivers that defined their ->flash_node. But these drivers should probably convert anyway. So, please test your favorite driver! Thanks, Brian Brian Norris (5): mtd: ofpart: grab device tree node directly from master device node mtd: nand: drop unnecessary partition parser data mtd: spi-nor: drop unnecessary partition parser data mtd: drop unnecessary partition parser data mtd: drop 'of_node' partition parser data drivers/mtd/devices/m25p80.c | 8 ++-- drivers/mtd/devices/mtd_dataflash.c | 5 ++--- drivers/mtd/devices/spear_smi.c | 6 ++ drivers/mtd/devices/st_spi_fsm.c | 5 ++--- drivers/mtd/maps/lantiq-flash.c | 5 ++--- drivers/mtd/maps/physmap_of.c | 5 ++--- drivers/mtd/nand/atmel_nand.c | 7 +++ drivers/mtd/nand/brcmnand/brcmnand.c | 3 +-- drivers/mtd/nand/davinci_nand.c | 10 +++--- drivers/mtd/nand/fsl_elbc_nand.c | 5 ++--- drivers/mtd/nand/fsl_ifc_nand.c | 5 ++--- drivers/mtd/nand/fsl_upm.c| 5 ++--- drivers/mtd/nand/fsmc_nand.c | 7 +++ drivers/mtd/nand/gpio.c | 8 +++- drivers/mtd/nand/gpmi-nand/gpmi-nand.c| 5 ++--- drivers/mtd/nand/hisi504_nand.c | 5 ++--- drivers/mtd/nand/lpc32xx_mlc.c| 7 +++ drivers/mtd/nand/lpc32xx_slc.c| 7 +++ drivers/mtd/nand/mpc5121_nfc.c| 5 ++--- drivers/mtd/nand/mxc_nand.c | 5 ++--- drivers/mtd/nand/nand_base.c | 3 +++ drivers/mtd/nand/ndfc.c | 5 ++--- drivers/mtd/nand/omap2.c | 6 ++ drivers/mtd/nand/orion_nand.c | 6 ++ drivers/mtd/nand/plat_nand.c | 5 ++--- drivers/mtd/nand/pxa3xx_nand.c| 10 +- drivers/mtd/nand/sh_flctl.c | 6 ++ drivers/mtd/nand/socrates_nand.c | 5 ++--- drivers/mtd/nand/sunxi_nand.c | 4 +--- drivers/mtd/nand/vf610_nfc.c | 6 +- drivers/mtd/ofpart.c | 12 drivers/mtd/onenand/omap2.c | 8 +++- drivers/mtd/spi-nor/fsl-quadspi.c | 4 +--- drivers/mtd/spi-nor/nxp-spifi.c | 4 +--- drivers/mtd/spi-nor/spi-nor.c | 1 + drivers/staging/mt29f_spinand/mt29f_spinand.c | 5 ++--- include/linux/mtd/partitions.h| 2 -- 37 files changed, 79 insertions(+), 131 deletions(-) -- 2.6.0.rc2.230.g3dd15c0 -- 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/5] mtd: nand: drop unnecessary partition parser data
All of these drivers set up a parser data struct just to communicate DT
partition data. This field has been deprecated and is instead supported
by telling nand_scan_ident() about the 'flash_node'.
This patch:
* sets chip->flash_node for those drivers that didn't already (but used
OF partitioning)
* drops the parser data
* switches to the simpler mtd_device_register() where possible, now
that we've eliminated one of the auxiliary parameters
Now that we've assigned chip->flash_node for these drivers, we can
probably rely on nand_dt_init() to do more of the DT parsing for us, but
for now, I don't want to fiddle with each of these drivers. The parsing
is done in duplicate for now on some drivers. I don't think this should
break things. (Famous last words.)
Signed-off-by: Brian Norris
---
drivers/mtd/nand/atmel_nand.c | 7 +++
drivers/mtd/nand/brcmnand/brcmnand.c | 3 +--
drivers/mtd/nand/davinci_nand.c | 10 +++---
drivers/mtd/nand/fsl_elbc_nand.c | 5 ++---
drivers/mtd/nand/fsl_ifc_nand.c | 5 ++---
drivers/mtd/nand/fsl_upm.c| 5 ++---
drivers/mtd/nand/fsmc_nand.c | 7 +++
drivers/mtd/nand/gpio.c | 8 +++-
drivers/mtd/nand/gpmi-nand/gpmi-nand.c| 5 ++---
drivers/mtd/nand/hisi504_nand.c | 5 ++---
drivers/mtd/nand/lpc32xx_mlc.c| 7 +++
drivers/mtd/nand/lpc32xx_slc.c| 7 +++
drivers/mtd/nand/mpc5121_nfc.c| 5 ++---
drivers/mtd/nand/mxc_nand.c | 5 ++---
drivers/mtd/nand/ndfc.c | 5 ++---
drivers/mtd/nand/omap2.c | 6 ++
drivers/mtd/nand/orion_nand.c | 6 ++
drivers/mtd/nand/plat_nand.c | 5 ++---
drivers/mtd/nand/pxa3xx_nand.c| 10 +-
drivers/mtd/nand/sh_flctl.c | 6 ++
drivers/mtd/nand/socrates_nand.c | 5 ++---
drivers/mtd/nand/sunxi_nand.c | 4 +---
drivers/mtd/nand/vf610_nfc.c | 6 +-
drivers/staging/mt29f_spinand/mt29f_spinand.c | 5 ++---
24 files changed, 54 insertions(+), 88 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 583cdd9bb971..dd157b0d8041 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -2093,7 +2093,6 @@ static int atmel_nand_probe(struct platform_device *pdev)
struct mtd_info *mtd;
struct nand_chip *nand_chip;
struct resource *mem;
- struct mtd_part_parser_data ppdata = {};
int res, irq;
/* Allocate memory for the device structure (and zero it) */
@@ -2117,6 +2116,7 @@ static int atmel_nand_probe(struct platform_device *pdev)
nand_chip = &host->nand_chip;
host->dev = &pdev->dev;
if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+ mtd->dev.of_node = pdev->dev.of_node;
/* Only when CONFIG_OF is enabled of_node can be parsed */
res = atmel_of_init_port(host, pdev->dev.of_node);
if (res)
@@ -2259,9 +2259,8 @@ static int atmel_nand_probe(struct platform_device *pdev)
}
mtd->name = "atmel_nand";
- ppdata.of_node = pdev->dev.of_node;
- res = mtd_device_parse_register(mtd, NULL, &ppdata,
- host->board.parts, host->board.num_parts);
+ res = mtd_device_register(mtd, host->board.parts,
+ host->board.num_parts);
if (!res)
return res;
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 7c1c306650a4..961a9ee4369c 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1889,7 +1889,6 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
- struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
if (ret) {
@@ -1959,7 +1958,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
if (nand_scan_tail(mtd))
return -ENXIO;
- return mtd_device_parse_register(mtd, NULL, &ppdata, NULL, 0);
+ return mtd_device_register(mtd, NULL, 0);
}
static void brcmnand_save_restore_cs_config(struct brcmnand_host *host,
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index c72313d66cf6..a8448d73f56c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -684,6 +684,7 @@ static int nand_davinci_probe(struct platform_device *pdev)
info->mtd.priv = &info->chip;
info->mtd.dev.parent= &pdev->dev;
+ info->mtd.dev.of_node = pdev->dev.of_node;
info->chip.IO_ADDR_R= vaddr;
Re: [PATCH 20/31] perf tools: Allow BPF program attach to uprobe events
On 2015/10/14 20:41, Wang Nan wrote:
This patch appends new syntax to BPF object section name to support
probing at uprobe event. Now we can use BPF program like this:
SEC(
"target=/lib64/libc.so.6\n"
"libcwrite=__write"
)
int libcwrite(void *ctx)
{
return 1;
}
Where, in section name of a program, before the main config string,
we can use 'key=value' style options. Now the only option key "target"
is for uprobe probing.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Cc: Arnaldo Carvalho de Melo
Link: http://lkml.kernel.org/n/ebpf-6yw9eg0ej3l4jnqhinngk...@git.kernel.org
---
tools/perf/util/bpf-loader.c | 86
1 file changed, 80 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index af549ea..73ff9a9 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -111,6 +111,84 @@ bpf_prog_priv__clear(struct bpf_program *prog
__maybe_unused,
}
static int
+do_config(const char *key, const char *value,
+ struct perf_probe_event *pev)
+{
+ pr_debug("config bpf program: %s=%s\n", key, value);
+ if (strcmp(key, "target") == 0) {
+ pev->uprobes = true;
+ pev->target = strdup(value);
+ return 0;
+ }
+
+ pr_warning("BPF: WARNING: invalid config option in object: %s=%s\n",
+ key, value);
+ pr_warning("\tHint: Currently only valid option is 'target='\n");
+ return 0;
+}
This part is very easy to be extended to support probing at modules.
I'd like to change "target" to "exec" to make it unify with perf probe,
then add another patch to support module probing in next pull request.
Thank you.
--
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] scsi_sysfs: Fix queue_ramp_up_period return code
On 10/26/15 07:54, Peter Oberparleiter wrote: Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period returns the value of that number instead of the number of bytes written. This behavior can confuse programs expecting POSIX write() semantics. Fix this by returning the number of bytes written instead. Signed-off-by: Peter Oberparleiter --- drivers/scsi/scsi_sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index b89..6b0f292 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -898,7 +898,7 @@ sdev_store_queue_ramp_up_period(struct device *dev, return -EINVAL; sdev->queue_ramp_up_period = msecs_to_jiffies(period); - return period; + return count; } static DEVICE_ATTR(queue_ramp_up_period, S_IRUGO | S_IWUSR, Hello Peter, Good catch. But please CC the people who introduced this code and also "stable" (see also commit 4a84067dbfce436b81779e585bf712b02ceee552). Thanks, Bart. -- 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/
