Re: [PATCH] perf script: Add option to display guest samples in host
Hi all,
For sched_switch tracepoint, I guess maybe it would be more reasonable
to show guest samples together with host samples by default, instead of
setting an option to display guest samples when we meet with this
confused situation.
To take care of this issue, the code should be changed as below:
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 0c977b6..dcfab00 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1557,7 +1557,7 @@ static int process_sample_event(struct perf_tool
*tool,
return -1;
}
-if (al.filtered)
+if (al.filtered && !(strcmp(evsel->name, "sched:sched_switch")== 0
&& perf_host &&(al.filtered & (1 << HIST_FILTER__GUEST
goto out_put;
if (cpu_list && !test_bit(sample->cpu, cpu_bitmap))
Right?
Thanks,
Mengting Zhang
On 2017/10/18 22:37, David Ahern wrote:
On 10/18/17 1:09 AM, Mengting Zhang wrote:
@@ -2771,6 +2772,8 @@ int cmd_script(int argc, const char **argv)
"Show context switch events (if recorded)"),
OPT_BOOLEAN('\0', "show-namespace-events",
&script.show_namespace_events,
"Show namespace events (if recorded)"),
+ OPT_BOOLEAN('\0', "show-guest-samples", &script.show_guest_samples,
+ "Show guest samples (if recorded)"),
OPT_BOOLEAN('f', "force", &symbol_conf.force, "don't complain, do it"),
OPT_INTEGER(0, "max-blocks", &max_blocks,
"Maximum number of code blocks to dump with brstackinsn"),
At this point we need a 'show-all' option.
.
Re: [PATCH] net: wireless: mark expected switch fall-throughs
On Fri, 2017-10-20 at 12:21 -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > This code was tested by compilation only (GCC 7.2.0 was used). > Please, verify if the actual intention of the code is to fall through. Please, if you're proposing patches, do that yourself. johannes
Re: [PATCH 1/2 v4] user namespace: use union in {g,u}idmap struct
On 23.10.2017 09:39, Nikolay Borisov wrote:
>
>
> On 19.10.2017 22:11, Christian Brauner wrote:
>> - Add a struct containing two pointer to extents and wrap both the static
>> extent
>> array and the struct into a union. This is done in preparation for bumping
>> the
>> {g,u}idmap limits for user namespaces.
>> - Add brackets around anonymous union when using designated initializers to
>> initialize members in order to please gcc <= 4.4.
>>
>> Signed-off-by: Christian Brauner
>> ---
>> Changelog 2017-10-19:
>> * kernel/user.c: Use brackets around anonymous union when using designated
>> initializers to initialize members. This is done to please gcc <= 4.4.
>> ---
>> include/linux/user_namespace.h | 18 +-
>> kernel/user.c | 30 ++
>> 2 files changed, 31 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
>> index c18e01252346..7c83d7f6289b 100644
>> --- a/include/linux/user_namespace.h
>> +++ b/include/linux/user_namespace.h
>> @@ -12,13 +12,21 @@
>>
>> #define UID_GID_MAP_MAX_EXTENTS 5
>>
>> +struct uid_gid_extent {
>> +u32 first;
>> +u32 lower_first;
>> +u32 count;
>> +};
>> +
>> struct uid_gid_map {/* 64 bytes -- 1 cache line */
>> u32 nr_extents;
>> -struct uid_gid_extent {
>> -u32 first;
>> -u32 lower_first;
>> -u32 count;
>> -} extent[UID_GID_MAP_MAX_EXTENTS];
>> +union {
>> +struct uid_gid_extent extent[UID_GID_MAP_MAX_EXTENTS];
>> +struct {
>> +struct uid_gid_extent *forward;
>> +struct uid_gid_extent *reverse;
>> +};
>> +};
>> };
>>
>> #define USERNS_SETGROUPS_ALLOWED 1UL
>> diff --git a/kernel/user.c b/kernel/user.c
>> index 00281add65b2..9a20acce460d 100644
>> --- a/kernel/user.c
>> +++ b/kernel/user.c
>> @@ -26,26 +26,32 @@
>> struct user_namespace init_user_ns = {
>> .uid_map = {
>> .nr_extents = 1,
>> -.extent[0] = {
>> -.first = 0,
>> -.lower_first = 0,
>> -.count = 4294967295U,
>> +{
>> +.extent[0] = {
>> +.first = 0,
>> +.lower_first = 0,
>> +.count = 4294967295U,
>
> nit: ULONG_MAX ?
Well, actually UINT_MAX
RE: [PATCH 1/4] bcache: convert cached_dev.count from atomic_t to refcount_t
> On 10/20/2017 12:37 AM, Elena Reshetova wrote: > > atomic_t variables are currently used to implement reference > > counters with the following properties: > > - counter is initialized to 1 using atomic_set() > > - a resource is freed upon counter reaching zero > > - once counter reaches zero, its further > >increments aren't allowed > > - counter schema uses basic atomic operations > >(set, inc, inc_not_zero, dec_and_test, etc.) > > > > Such atomic variables should be converted to a newly provided > > refcount_t type and API that prevents accidental counter overflows > > and underflows. This is important since overflows and underflows > > can lead to use-after-free situation and be exploitable. > > > > The variable cached_dev.count is used as pure reference counter. > > Convert it to refcount_t and fix up the operations. > > > > Suggested-by: Kees Cook > > Reviewed-by: David Windsor > > Reviewed-by: Hans Liljestrand > > Signed-off-by: Elena Reshetova > > Reviewed-by: Michael Lyle > > Thanks for this-- I'm including it in my tree for possible inclusion in > 4.15 (I've already sent my main chunk of changes upwards). Thank you Mike! I am dropping then this patch from my list of maintained conversions. Best Regards, Elena. > > Mike
Re: [PATCH v4 2/2] dma: sprd: Add Spreadtrum DMA driver
On Tue, Oct 10, 2017 at 01:23:01PM +0800, Baolin Wang wrote:
> +++ b/drivers/dma/sprd-dma.c
> @@ -0,0 +1,988 @@
> +/*
> + * Copyright (C) 2017 Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
MIT? See comment for MODULE_LICENSE
> +/* SPRD_DMA_CHN_CFG register definition */
> +#define SPRD_DMA_CHN_EN BIT(0)
> +#define SPRD_DMA_WAIT_BDONE 24
24 decimal? Why not BIT or GENMASK?
> +#define SPRD_DMA_DONOT_WAIT_BDONE1
BIT()
> +static void sprd_dma_chn_update(struct sprd_dma_chn *schan, u32 reg,
> + u32 mask, u32 val)
> +{
> + u32 orig = readl(schan->chn_base + reg);
> + u32 tmp;
> +
> + tmp = orig & ~mask;
> + tmp |= val & mask;
how about:
tmp = (orig & ~mask) | val;
> +
> + writel(tmp, schan->chn_base + reg);
> +}
...
> +static enum sprd_dma_int_type sprd_dma_get_int_type(struct sprd_dma_chn
> *schan)
> +{
> + u32 intc_sts = readl(schan->chn_base + SPRD_DMA_CHN_INTC) &
> +SPRD_DMA_CHN_INT_STS;
> +
> + switch (intc_sts) {
> + case SPRD_DMA_CFGERR_INT_STS:
> + return SPRD_DMA_CFGERR_INT;
> +
> + case SPRD_DMA_LIST_INT_STS:
> + return SPRD_DMA_LIST_INT;
> +
> + case SPRD_DMA_TRSC_INT_STS:
> + return SPRD_DMA_TRANS_INT;
> +
> + case SPRD_DMA_BLK_INT_STS:
> + return SPRD_DMA_BLK_INT;
> +
> + case SPRD_DMA_FRAG_INT_STS:
> + return SPRD_DMA_FRAG_INT;
> +
> + default:
> + return SPRD_DMA_NO_INT;
should we not log this as error and say we are falling back?
> +static void sprd_dma_free_chan_resources(struct dma_chan *chan)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&schan->vc.lock, flags);
> + sprd_dma_stop(schan);
shouldn't the channel be stopped already?
> +static enum dma_status sprd_dma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie,
> + struct dma_tx_state *txstate)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + struct virt_dma_desc *vd;
> + unsigned long flags;
> + enum dma_status ret;
> + u32 pos;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> +
> + spin_lock_irqsave(&schan->vc.lock, flags);
> + vd = vchan_find_desc(&schan->vc, cookie);
> + if (vd) {
pls check txstate being valid. No point continuing if that is not valid
> +struct dma_async_tx_descriptor *sprd_dma_prep_dma_memcpy(struct dma_chan
> *chan,
> + dma_addr_t dest,
> + dma_addr_t src,
> + size_t len,
> + unsigned long flags)
the argument can be moved to two line, it will help readablity.
> +static int sprd_dma_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct sprd_dma_dev *sdev;
> + struct sprd_dma_chn *dma_chn;
> + struct resource *res;
> + u32 chn_count;
> + int ret, i;
> +
> + ret = of_property_read_u32(np, "#dma-channels", &chn_count);
why not device_property_read_u32()?
> + if (ret) {
> + dev_err(&pdev->dev, "get dma channels count failed\n");
> + return ret;
> + }
> +
> + sdev = devm_kzalloc(&pdev->dev, sizeof(*sdev) +
> + sizeof(*dma_chn) * chn_count,
> + GFP_KERNEL);
> + if (!sdev)
> + return -ENOMEM;
> +
> + sdev->clk = devm_clk_get(&pdev->dev, "enable");
> + if (IS_ERR(sdev->clk)) {
> + dev_err(&pdev->dev, "get enable clock failed\n");
> + return PTR_ERR(sdev->clk);
> + }
> +
> + /* ashb clock is optional for AGCP DMA */
> + sdev->ashb_clk = devm_clk_get(&pdev->dev, "ashb_eb");
> + if (IS_ERR(sdev->ashb_clk))
> + dev_warn(&pdev->dev, "no optional ashb eb clock\n");
> +
> + /*
> + * We have three DMA controllers: AP DMA, AON DMA and AGCP DMA. For AGCP
> + * DMA controller, it can do not request the irq to save system power
it can or do not, either would make sense but not both
> + * without resuming system by DMA interrupts. Thus the DMA interrupts
> + * property should be optional.
> + */
> + sdev->irq = platform_get_irq(pdev, 0);
> + if (sdev->irq > 0) {
> + ret = devm_request_irq(&pdev->dev, sdev->irq, dma_irq_handle,
> +0, "sprd_dma", (void *)sdev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "request dma irq failed\n");
> + return ret;
> + }
> + } else {
> + dev_warn(&pdev->dev, "no interrupts for the dma controller\n");
> + }
> +
Re: [PATCH 1/2 v4] user namespace: use union in {g,u}idmap struct
On 19.10.2017 22:11, Christian Brauner wrote:
> - Add a struct containing two pointer to extents and wrap both the static
> extent
> array and the struct into a union. This is done in preparation for bumping
> the
> {g,u}idmap limits for user namespaces.
> - Add brackets around anonymous union when using designated initializers to
> initialize members in order to please gcc <= 4.4.
>
> Signed-off-by: Christian Brauner
> ---
> Changelog 2017-10-19:
> * kernel/user.c: Use brackets around anonymous union when using designated
> initializers to initialize members. This is done to please gcc <= 4.4.
> ---
> include/linux/user_namespace.h | 18 +-
> kernel/user.c | 30 ++
> 2 files changed, 31 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index c18e01252346..7c83d7f6289b 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -12,13 +12,21 @@
>
> #define UID_GID_MAP_MAX_EXTENTS 5
>
> +struct uid_gid_extent {
> + u32 first;
> + u32 lower_first;
> + u32 count;
> +};
> +
> struct uid_gid_map { /* 64 bytes -- 1 cache line */
> u32 nr_extents;
> - struct uid_gid_extent {
> - u32 first;
> - u32 lower_first;
> - u32 count;
> - } extent[UID_GID_MAP_MAX_EXTENTS];
> + union {
> + struct uid_gid_extent extent[UID_GID_MAP_MAX_EXTENTS];
> + struct {
> + struct uid_gid_extent *forward;
> + struct uid_gid_extent *reverse;
> + };
> + };
> };
>
> #define USERNS_SETGROUPS_ALLOWED 1UL
> diff --git a/kernel/user.c b/kernel/user.c
> index 00281add65b2..9a20acce460d 100644
> --- a/kernel/user.c
> +++ b/kernel/user.c
> @@ -26,26 +26,32 @@
> struct user_namespace init_user_ns = {
> .uid_map = {
> .nr_extents = 1,
> - .extent[0] = {
> - .first = 0,
> - .lower_first = 0,
> - .count = 4294967295U,
> + {
> + .extent[0] = {
> + .first = 0,
> + .lower_first = 0,
> + .count = 4294967295U,
nit: ULONG_MAX ?
> + },
> },
> },
> .gid_map = {
> .nr_extents = 1,
> - .extent[0] = {
> - .first = 0,
> - .lower_first = 0,
> - .count = 4294967295U,
> + {
> + .extent[0] = {
> + .first = 0,
> + .lower_first = 0,
> + .count = 4294967295U,
> + },
> },
> },
> .projid_map = {
> .nr_extents = 1,
> - .extent[0] = {
> - .first = 0,
> - .lower_first = 0,
> - .count = 4294967295U,
> + {
> + .extent[0] = {
> + .first = 0,
> + .lower_first = 0,
> + .count = 4294967295U,
> + },
> },
> },
> .count = ATOMIC_INIT(3),
>
Re: [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion()
On Mon, Oct 23, 2017 at 08:53:35AM +0900, Byungchul Park wrote:
> On Fri, Oct 20, 2017 at 07:44:51AM -0700, Christoph Hellwig wrote:
> > The Subject prefix for this should be "block:".
> >
> > > @@ -945,7 +945,7 @@ int submit_bio_wait(struct bio *bio)
> > > {
> > > struct submit_bio_ret ret;
> > >
> > > - init_completion(&ret.event);
> > > + init_completion_with_map(&ret.event, &bio->bi_disk->lockdep_map);
> >
> > FYI, I have an outstanding patch to simplify this a lot, which
> > switches this to DECLARE_COMPLETION_ONSTACK. I can delay this or let
> > you pick it up with your series, but we'll need a variant of
> > DECLARE_COMPLETION_ONSTACK with the lockdep annotations.
>
> Hello,
>
> I'm sorry for late.
>
> I think your patch makes block code simpler and better. I like it.
>
> But, I just wonder if it's related to my series.
Because it shows that we also need a version of DECLARE_COMPLETION_ONSTACK
the gets passed an explicit lockdep map. And because if it was merged
through a different tree it would create a conflict.
> Is it proper to add
> your patch into my series?
Sure.
RE: [PATCH 02/15] drivers, net, ethernet: convert mtk_eth.dma_refcnt from atomic_t to refcount_t
> On Fri, 2017-10-20 at 10:37 +, Reshetova, Elena wrote:
> > > On Fri, 2017-10-20 at 10:23 +0300, Elena Reshetova wrote:
> > > > atomic_t variables are currently used to implement reference
> > > > counters with the following properties:
> > > > - counter is initialized to 1 using atomic_set()
> > > > - a resource is freed upon counter reaching zero
> > > > - once counter reaches zero, its further
> > > >increments aren't allowed
> > > > - counter schema uses basic atomic operations
> > > >(set, inc, inc_not_zero, dec_and_test, etc.)
> > > >
> > > > Such atomic variables should be converted to a newly provided
> > > > refcount_t type and API that prevents accidental counter overflows
> > > > and underflows. This is important since overflows and underflows
> > > > can lead to use-after-free situation and be exploitable.
> > > >
> > > > The variable mtk_eth.dma_refcnt is used as pure reference counter.
> > > > Convert it to refcount_t and fix up the operations.
> > > >
> > > > Suggested-by: Kees Cook
> > > > Reviewed-by: David Windsor
> > > > Reviewed-by: Hans Liljestrand
> > > > Signed-off-by: Elena Reshetova
> > > > ---
> > > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 +---
> > > > drivers/net/ethernet/mediatek/mtk_eth_soc.h | 4 +++-
> > > > 2 files changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > > index 5e81a72..54adfd9 100644
> > > > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > > @@ -1817,7 +1817,7 @@ static int mtk_open(struct net_device *dev)
> > > > struct mtk_eth *eth = mac->hw;
> > > >
> > > > /* we run 2 netdevs on the same dma ring so we only bring it up
> > > > once
> > > */
> > > > - if (!atomic_read(ð->dma_refcnt)) {
> > > > + if (!refcount_read(ð->dma_refcnt)) {
> > > > int err = mtk_start_dma(eth);
> > > >
> > > > if (err)
> > > > @@ -1827,8 +1827,10 @@ static int mtk_open(struct net_device *dev)
> > > > napi_enable(ð->rx_napi);
> > > > mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
> > > > mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
> > > > + refcount_set(ð->dma_refcnt, 1);
> > >
> > > the existing driver seems to have a missing initial atomic_set for the
> > > eth->dma_refcnt.
> > >
> > > > }
> > > > - atomic_inc(ð->dma_refcnt);
> > > > + else
> > > > + refcount_inc(ð->dma_refcnt);
> > > >
> > >
> > > how about add the initial refcount_set into probe handler, and keep
> > > logic else unchanged ?
> >
> > Sure, I guess you mean mtk_probe() function? I can move the refcount_set to
> > be
> there
> > and remove this change.
> >
> > Should I resend the modified patch to you (maybe then two of the ethernet
> patches)?
> >
> > Best Regards,
> > Elena.
>
> The entire series has been applies to net-next, I think I can make the
> follow-ups patches relative to your work.
>
> Sean
Yes, I just noticed that David took them all.
Sure, if you want to send the follow up yourself, I certainly would not mind,
I still have many of these recount patches for different parts of kernel :)
Thank you!
Best Regards,
Elena.
>
> > >
> > > > phy_start(dev->phydev);
> > > > netif_start_queue(dev);
> > > > @@ -1868,7 +1870,7 @@ static int mtk_stop(struct net_device *dev)
> > > > phy_stop(dev->phydev);
> > > >
> > > > /* only shutdown DMA if this is the last user */
> > > > - if (!atomic_dec_and_test(ð->dma_refcnt))
> > > > + if (!refcount_dec_and_test(ð->dma_refcnt))
> > > > return 0;
> > > >
> > > > mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
> > > > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > > index 3d3c24a..a3af466 100644
> > > > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > > @@ -15,6 +15,8 @@
> > > > #ifndef MTK_ETH_H
> > > > #define MTK_ETH_H
> > > >
> > > > +#include
> > > > +
> > > > #define MTK_QDMA_PAGE_SIZE 2048
> > > > #defineMTK_MAX_RX_LENGTH 1536
> > > > #define MTK_TX_DMA_BUF_LEN 0x3fff
> > > > @@ -632,7 +634,7 @@ struct mtk_eth {
> > > > struct regmap *pctl;
> > > > u32 chip_id;
> > > > boolhwlro;
> > > > - atomic_tdma_refcnt;
> > > > + refcount_t dma_refcnt;
> > > > struct mtk_tx_ring tx_ring;
> > > > struct mtk_rx_ring
> > > rx_ring[MTK_MAX_RX_RING_NUM];
> > > > struct mtk_rx_ring rx_ring_qdma;
> > >
> >
>
RE: [PATCH 00/15] networking drivers refcount_t conversions
> From: Elena Reshetova > Date: Fri, 20 Oct 2017 10:23:34 +0300 > > > Note: these are the last patches related to networking that perform > > conversion of refcounters from atomic_t to refcount_t. > > In contrast to the core network refcounter conversions that > > were merged earlier, these are much more straightforward ones. > > > > This series, for various networking drivers, replaces atomic_t reference > > counters with the new refcount_t type and API (see > > include/linux/refcount.h). > > By doing this we prevent intentional or accidental > > underflows or overflows that can led to use-after-free vulnerabilities. > > > > The patches are fully independent and can be cherry-picked separately. > > Patches are based on top of net-next. > > If there are no objections to the patches, please merge them via respective > > trees > > I've applied this entire series to net-next. If there are any fixups or > follow-ups please send them as relative patches. > > Thank you. Thank you very much David! Will send fixups separately. Best Regards, Elena.
Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration
On Mon, Oct 23, 2017 at 11:13:23AM +0530, Kishon Vijay Abraham I wrote: > EPF devices use EPC devices which in turn use the actual platform device for > configuring the hardware. IMO the devices in one layer shouldn't have to > explicitly use devices in another layer other than using clearly defined > API's. > Here platform_device is the bottom later, above which is epc_device and on top > is epf_device. > > The idea is just by doing the initial setup in the framework, the epf driver > be > able to use APIs like dma_alloc_coherent using it's own *device* rather than > the EPC's "device". That's a little strange - normally we only call dma_map* routines on the actual physical bus devices.
Re: [Question] null pointer risk of kernel workqueue
Hi Bin,
Yes, that's it. thanks.
--
tanxiaofei
On 2017/10/23 9:34, Li Bin wrote:
>
>
> on 2017/10/21 23:35, Tejun Heo wrote:
>> On Fri, Oct 20, 2017 at 02:57:18PM +0800, tanxiaofei wrote:
>>> Hi Tejun,
>>>
>>> Any comments about this?
>>
>> I think you're confused, or at least can't understand what you're
>> trying to say. Can you create a rero?
>>
>
> Hi Tejun,
> The case is as following:
>
> worker_thread()
> |-spin_lock_irq()
> |-process_one_work()
> |-worker->current_pwq = pwq
> |-spin_unlock_irq()
> |-worker->current_func(work)
> |-spin_lock_irq()
> |-worker->current_pwq = NULL
> |-spin_unlock_irq()
>
> //interrupt here
>
> |-irq_handler
>
> |-__queue_work()
>
> //assuming that the wq is draining
>
> |-if (unlikely(wq->flags & __WQ_DRAINING)
> &&WARN_ON_ONCE(!is_chained_work(wq)))
>
> |-is_chained_work(wq)
>
> |-current_wq_worker() // Here, 'current' is the interrupted worker!
>
> |-current->current_pwq is NULL here!
> |-schedule()
>
> And I think the following patch can solve the bug, right?
>
> diff --git a/kernel/workqueue_internal.h b/kernel/workqueue_internal.h
> index 8635417..650680c 100644
> --- a/kernel/workqueue_internal.h
> +++ b/kernel/workqueue_internal.h
> @@ -59,7 +59,7 @@ struct worker {
> */
> static inline struct worker *current_wq_worker(void)
> {
> - if (current->flags & PF_WQ_WORKER)
> + if (!in_irq() && (current->flags & PF_WQ_WORKER))
> return kthread_data(current);
> return NULL;
> }
>
>
> Thanks,
> Li Bin
>
>> Thanks.
>>
>
>
> .
>
Re: [PATCH v5 07/11] dmaengine: sun6i: Retrieve channel count/max request from devicetree
On Tue, Oct 17, 2017 at 01:06:34AM +0200, Stefan Brüns wrote:
> To avoid introduction of a new compatible for each small SoC/DMA controller
> variation, move the definition of the channel count to the devicetree.
>
> The number of vchans is no longer explicit, but limited by the highest
> port/DMA request number. The result is a slight overallocation for SoCs
> with a sparse port mapping.
Applied, thanks. But ...
> static int sun6i_dma_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> struct sun6i_dma_dev *sdc;
> struct resource *res;
> int ret, i;
> @@ -1228,6 +1233,26 @@ static int sun6i_dma_probe(struct platform_device
> *pdev)
> sdc->num_vchans = sdc->cfg->nr_max_vchans;
> sdc->max_request = sdc->cfg->nr_max_requests;
>
> + ret = of_property_read_u32(np, "dma-channels", &sdc->num_pchans);
> + if (ret && !sdc->num_pchans) {
> + dev_err(&pdev->dev, "Can't get dma-channels.\n");
> + return ret;
> + }
... we should probably use device_read_xxx calls instead of of_xxx
--
~Vinod
[ANNOUNCE] Git v2.14.3
The latest maintenance release Git v2.14.3 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.14.3' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git Git v2.14.3 Release Notes = Fixes since v2.14.2 --- * A helper function to read a single whole line into strbuf mistakenly triggered OOM error at EOF under certain conditions, which has been fixed. * In addition to "cc: # cruft", "cc: a...@dd.re.ss # cruft" was taught to "git send-email" as a valid way to tell it that it needs to also send a carbon copy to in the trailer section. * Fix regression to "gitk --bisect" by a recent update. * Unlike "git commit-tree < file", "git commit-tree -F file" did not pass the contents of the file verbatim and instead completed an incomplete line at the end, if exists. The latter has been updated to match the behaviour of the former. * "git archive", especially when used with pathspec, stored an empty directory in its output, even though Git itself never does so. This has been fixed. * API error-proofing which happens to also squelch warnings from GCC. * "git gc" tries to avoid running two instances at the same time by reading and writing pid/host from and to a lock file; it used to use an incorrect fscanf() format when reading, which has been corrected. * The test linter has been taught that we do not like "echo -e". * Code cmp.std.c nitpick. * "git describe --match" learned to take multiple patterns in v2.13 series, but the feature ignored the patterns after the first one and did not work at all. This has been fixed. * "git cat-file --textconv" started segfaulting recently, which has been corrected. * The built-in pattern to detect the "function header" for HTML did not match .. elements without any attributes, which has been fixed. * "git mailinfo" was loose in decoding quoted printable and produced garbage when the two letters after the equal sign are not hexadecimal. This has been fixed. * The documentation for '-X' for merges was misleadingly written to suggest that "-s theirs" exists, which is not the case. * Spell the name of our system as "Git" in the output from request-pull script. * Fixes for a handful memory access issues identified by valgrind. * Backports a moral equivalent of 2015 fix to the poll emulation from the upstream gnulib to fix occasional breakages on HPE NonStop. * In the "--format=..." option of the "git for-each-ref" command (and its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)" (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat them as if the colon and an empty string that follows it were not there. * Users with "color.ui = always" in their configuration were broken by a recent change that made plumbing commands to pay attention to them as the patch created internally by "git add -p" were colored (heh) and made unusable. This has been fixed. * "git branch -M a b" while on a branch that is completely unrelated to either branch a or branch b misbehaved when multiple worktree was in use. This has been fixed. * "git fast-export" with -M/-C option issued "copy" instruction on a path that is simultaneously modified, which was incorrect. * The checkpoint command "git fast-import" did not flush updates to refs and marks unless at least one object was created since the last checkpoint, which has been corrected, as these things can happen without any new object getting created. * The scripts to drive TravisCI has been reorganized and then an optimization to avoid spending cycles on a branch whose tip is tagged has been implemented. * "git fetch :" allows an object name on the side when the other side accepts such a request since Git v2.5, but the documentation was left stale. * A regression in 2.11 that made the code to read the list of alternate object stores overrun the end of the string has been fixed. Also contains various documentation updates and code clean-ups.
Re: extcon: max14577: Use common error handling code in max14577_muic_set_path()
>>> I think that there is any benefit of this patch. >>> Also, as I commented, it make the code more complicated. >> >> We have got different software development opinions about > > I agree absolutely. So, anyone can suggest the opinion and send patches. > But, all patches have to get the review from maintainer, reviewer > or the mailing-list developer. Can an other change acceptance evolve over time? > (Please don't remove the part of my comment when you reply.) > >> the shown change possibilities then. Do you find similar updates more useful for any other software modules? Regards, Markus
Re: extcon: max14577: Use common error handling code in max14577_muic_set_path()
On 2017년 10월 23일 14:57, SF Markus Elfring wrote: >> I think that there is any benefit of this patch. >> Also, as I commented, it make the code more complicated. > > We have got different software development opinions about I agree absolutely. So, anyone can suggest the opinion and send patches. But, all patches have to get the review from maintainer, reviewer or the mailing-list developer. (Please don't remove the part of my comment when you reply.) > the shown change possibilities then. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 0/4] Few more SBA RAID driver improvements
On Tue, Oct 03, 2017 at 10:52:56AM +0530, Anup Patel wrote: > This patchset does few more improvements to Broadcom SBA RAID > driver. > > The patches are based on Linux-4.14-rc3 and can also be found > at sba-raid-imp2-v1 branch of: > https://github.com/Broadcom/arm64-linux.git Applied, thanks -- ~Vinod
Re: extcon: max14577: Use common error handling code in max14577_muic_set_path()
> I think that there is any benefit of this patch. > Also, as I commented, it make the code more complicated. We have got different software development opinions about the shown change possibilities then. Regards, Markus
Re: [PATCH 1/2] extcon: max14577: Use common error handling code in max14577_muic_set_path()
On 2017년 10월 23일 14:45, SF Markus Elfring wrote: >> As you commented, this patch might remove the redundant error message. >> But, it makes the code more complicated in side of readability. > > Do you try to avoid duplicated code any more in other circumstances? I usually used the goto statement on following cases: - Return the value (error number if fail or 0 if success) - Do free or unregister or remove operations when error happen. I think that there is any benefit of this patch. Also, as I commented, it make the code more complicated. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: devfreq/exynos-bus: Use common error handling code in exynos_bus_target()
> As I already commented on your other patch related to extcon-max14577, > this patch might remove the redundant error message. I hope that more software improvements can be achieved in this design direction. > But, it makes the code more complicated in side of readability. I prefer > existing code. I prefer to avoid duplicated code a bit more. Regards, Markus
Re: [PATCH 1/2] extcon: max14577: Use common error handling code in max14577_muic_set_path()
> As you commented, this patch might remove the redundant error message. > But, it makes the code more complicated in side of readability. Do you try to avoid duplicated code any more in other circumstances? Regards, Markus
Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration
Hi,
On Wednesday 11 October 2017 10:15 PM, Robin Murphy wrote:
> On 11/10/17 09:00, Kishon Vijay Abraham I wrote:
>> pci-epc-core.c invokes of_dma_configure in order to configure
>> the coherent_dma_mask/dma_mask of endpoint function device. This is
>> required for dma_alloc_coherent to succeed in pci function driver
>> (pci-epf-test.c). However after
>> commit 723288836628bc1c08 ("of: restrict DMA configuration"),
>> of_dma_configure doesn't configure the coherent_dma_mask/dma_mask
>> of endpoint function device (since it doesn't have dma-ranges
>> property), resulting in dma_alloc_coherent in pci endpoint function
>> driver to to fail. Fix it by making sure of_dma_configure configures
>> coherent_dma_mask/dma_mask irrespective of whether the node has
>> dma-ranges property or not.
>
> Frankly, what the endpoint stuff is doing looks wrong anyway. As I
> understand it, the endpoint functions aren't real devices, just a
> partitioning of resources - the only piece of hardware actually doing
> DMA is the EPC itself, which should already have been configured
> appropriately as a platform device.
EPF devices use EPC devices which in turn use the actual platform device for
configuring the hardware. IMO the devices in one layer shouldn't have to
explicitly use devices in another layer other than using clearly defined API's.
Here platform_device is the bottom later, above which is epc_device and on top
is epf_device.
The idea is just by doing the initial setup in the framework, the epf driver be
able to use APIs like dma_alloc_coherent using it's own *device* rather than
the EPC's "device".
>
> It seems to me that the EPF BAR allocations should just be using the EPC
> device directly, rather than trying to pretend the EPFs are distinct DMA
> masters.
>
> Furthermore, now that I've looked:
>
>> dma_addr_t phys_addr;
>
> please no :(
>
> (I can easily think of more than one system with an EP-capable DWC PCIe
> block integrated behind an IOMMU)
hmm.. haven't used IOMMU but won't setting up parent-child relationship between
EPC and EPF help in the case of IOMMU?
Thanks
Kishon
Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device
Dear all,
I got the reviews from all maintainers related to this patch.
So, I make the immutable branch on extcon.git and then send
the pull request in order to prevent the possible merge conflict.
Best Regards,
Chanwoo Choi
Samsung Electronics
The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
ib-extcon-v4.15
for you to fetch changes up to 176aa36012135d172394a928a03fb03dfecd83f9:
extcon: Split out extcon header file for consumer and provider device
(2017-10-23 14:07:58 +0900)
Chanwoo Choi (1):
extcon: Split out extcon header file for consumer and provider device
drivers/extcon/extcon-adc-jack.c | 2 +-
drivers/extcon/extcon-arizona.c | 2 +-
drivers/extcon/extcon-axp288.c| 2 +-
drivers/extcon/extcon-gpio.c | 2 +-
drivers/extcon/extcon-intel-cht-wc.c | 2 +-
drivers/extcon/extcon-intel-int3496.c | 2 +-
drivers/extcon/extcon-max14577.c | 2 +-
drivers/extcon/extcon-max3355.c | 2 +-
drivers/extcon/extcon-max77693.c | 2 +-
drivers/extcon/extcon-max77843.c | 2 +-
drivers/extcon/extcon-max8997.c | 2 +-
drivers/extcon/extcon-qcom-spmi-misc.c| 2 +-
drivers/extcon/extcon-rt8973a.c | 2 +-
drivers/extcon/extcon-sm5502.c| 2 +-
drivers/extcon/extcon-usb-gpio.c | 2 +-
drivers/extcon/extcon-usbc-cros-ec.c | 2 +-
drivers/extcon/extcon.h | 2 +-
drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c | 2 +-
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +-
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 2 +-
drivers/power/supply/qcom_smbb.c | 2 +-
drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
drivers/usb/phy/phy-tahvo.c | 2 +-
include/linux/extcon-provider.h | 142 ++
include/linux/extcon.h| 109 +---
include/linux/mfd/palmas.h| 2 +-
27 files changed, 172 insertions(+), 129 deletions(-)
create mode 100644 include/linux/extcon-provider.h
On 2017년 10월 23일 14:05, Kishon Vijay Abraham I wrote:
>
>
> On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
>> Gently Ping.
>>
>> Dear Kishon,
>>
>> Could you please review this patch for 'drivers/phy/*'?
>
> sorry for the delay.. here it is
>
> Acked-by: Kishon Vijay Abraham I
>>
>> Regards,
>> Chanwoo Choi
>>
>> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>>> Dear Kishon,
>>>
>>> Could you please review this patch?
>>> After that, I'll make the immutable brand and then send the pull request
>>> for power_supply, mfd, phy, usb and extcon framework.
>>>
>>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect the
state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API for
both provider and consumer device driver. To clarify the meaning of
header file and to remove the wrong use-case on consumer device,
this patch separates into extcon.h and extcon-provider.h.
[Description for include/linux/{extcon.h|extcon-provider.h}]
- extcon.h includes the extcon API and data structure for extcon consumer
device driver. This header file contains the following APIs:
: Register/unregister the notifier to catch the change of extcon device
: Get the extcon device instance
: Get the extcon device name
: Get the state of each external connector
: Get the property value of each external connector
: Get the property capability of each external connector
- extcon-provider.h includes the extcon API and data structure for extcon
provider device driver. This header file contains the following APIs:
: Include 'include/linux/extcon.h'
: Allocate the memory for extcon device instance
: Register/unregister extcon device
: Set the state of each external connector
: Set the property value of each external connector
: Set the property capability of each external connector
Cc: Felipe Balbi
Cc: Kishon Vijay Abraham I
Cc: Greg Kroah-Hartman
Acked-by: Sebastian Reichel
Acked-by: Chen-Yu Tsai
Acked-by: Charles Keepax
Acked-by: Lee Jones
Sig
Re: [PATCH v4 1/1] pwm: mediatek: add MT2712/MT7622 support
Hi Thierry,
Just have a ping on this issue.
Regards,
Zhi
On Wed, 2017-09-20 at 16:48 +0800, Zhi Mao wrote:
> Hi Thierry,
>
> Just a gentle ping on this issue.
> Would you please have a review to this patch?
>
> Regards,
> Zhi
>
>
> On Tue, 2017-08-22 at 10:09 +0800, Zhi Mao wrote:
> > Add support to MT2712 and MT7622.
> > Due to register offset address of pwm7 for MT2712 is not fixed 0x40,
> > add mtk_pwm_reg_offset array for pwm register offset.
> >
> > Signed-off-by: Zhi Mao
> > ---
> > drivers/pwm/pwm-mediatek.c | 51
> >
> > 1 file changed, 42 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> > index 1d78ab1..ccd86e7 100644
> > --- a/drivers/pwm/pwm-mediatek.c
> > +++ b/drivers/pwm/pwm-mediatek.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -40,11 +41,19 @@ enum {
> > MTK_CLK_PWM3,
> > MTK_CLK_PWM4,
> > MTK_CLK_PWM5,
> > + MTK_CLK_PWM6,
> > + MTK_CLK_PWM7,
> > + MTK_CLK_PWM8,
> > MTK_CLK_MAX,
> > };
> >
> > -static const char * const mtk_pwm_clk_name[] = {
> > - "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"
> > +static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
> > + "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6", "pwm7",
> > + "pwm8"
> > +};
> > +
> > +struct mtk_pwm_platform_data {
> > + unsigned int num_pwms;
> > };
> >
> > /**
> > @@ -57,6 +66,11 @@ struct mtk_pwm_chip {
> > struct pwm_chip chip;
> > void __iomem *regs;
> > struct clk *clks[MTK_CLK_MAX];
> > + const struct mtk_pwm_platform_data *data;
> > +};
> > +
> > +static const unsigned int mtk_pwm_reg_offset[] = {
> > + 0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
> > };
> >
> > static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
> > @@ -103,14 +117,14 @@ static void mtk_pwm_clk_disable(struct pwm_chip
> > *chip, struct pwm_device *pwm)
> > static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int
> > num,
> > unsigned int offset)
> > {
> > - return readl(chip->regs + 0x10 + (num * 0x40) + offset);
> > + return readl(chip->regs + mtk_pwm_reg_offset[num] + offset);
> > }
> >
> > static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
> > unsigned int num, unsigned int offset,
> > u32 value)
> > {
> > - writel(value, chip->regs + 0x10 + (num * 0x40) + offset);
> > + writel(value, chip->regs + mtk_pwm_reg_offset[num] + offset);
> > }
> >
> > static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > @@ -194,15 +208,20 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > if (!pc)
> > return -ENOMEM;
> >
> > + pc->data = of_device_get_match_data(&pdev->dev);
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pc->regs = devm_ioremap_resource(&pdev->dev, res);
> > if (IS_ERR(pc->regs))
> > return PTR_ERR(pc->regs);
> >
> > - for (i = 0; i < MTK_CLK_MAX; i++) {
> > + for (i = 0; i < pc->data->num_pwms + 2; i++) {
> > pc->clks[i] = devm_clk_get(&pdev->dev, mtk_pwm_clk_name[i]);
> > - if (IS_ERR(pc->clks[i]))
> > + if (IS_ERR(pc->clks[i])) {
> > + dev_err(&pdev->dev, "clock: %s fail: %ld\n",
> > + mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
> > return PTR_ERR(pc->clks[i]);
> > + }
> > }
> >
> > platform_set_drvdata(pdev, pc);
> > @@ -210,7 +229,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> > pc->chip.dev = &pdev->dev;
> > pc->chip.ops = &mtk_pwm_ops;
> > pc->chip.base = -1;
> > - pc->chip.npwm = 5;
> > + pc->chip.npwm = pc->data->num_pwms;
> >
> > ret = pwmchip_add(&pc->chip);
> > if (ret < 0) {
> > @@ -228,9 +247,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
> > return pwmchip_remove(&pc->chip);
> > }
> >
> > +static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> > + .num_pwms = 8,
> > +};
> > +
> > +static const struct mtk_pwm_platform_data mt7622_pwm_data = {
> > + .num_pwms = 6,
> > +};
> > +
> > +static const struct mtk_pwm_platform_data mt7623_pwm_data = {
> > + .num_pwms = 5,
> > +};
> > +
> > static const struct of_device_id mtk_pwm_of_match[] = {
> > - { .compatible = "mediatek,mt7623-pwm" },
> > - { }
> > + { .compatible = "mediatek,mt2712-pwm", .data = &mt2712_pwm_data },
> > + { .compatible = "mediatek,mt7622-pwm", .data = &mt7622_pwm_data },
> > + { .compatible = "mediatek,mt7623-pwm", .data = &mt7623_pwm_data },
> > + { },
> > };
> > MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
> >
>
Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS
On Sun, Oct 22, 2017 at 8:10 PM, Minchan Kim wrote: > On Fri, Oct 20, 2017 at 10:59:31PM +0300, Kirill A. Shutemov wrote: >> With boot-time switching between paging mode we will have variable >> MAX_PHYSMEM_BITS. >> >> Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y >> configuration to define zsmalloc data structures. >> >> The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case. >> It also suits well to handle PAE special case. >> >> Signed-off-by: Kirill A. Shutemov >> Cc: Minchan Kim >> Cc: Nitin Gupta >> Cc: Sergey Senozhatsky > Acked-by: Minchan Kim > > Nitin: > > I think this patch works and it would be best for Kirill to be able to do. > So if you have better idea to clean it up, let's make it as another patch > regardless of this patch series. > I was looking into dynamically allocating size_class array to avoid that compile error, but yes, that can be done in a future patch. So, for this patch: Reviewed-by: Nitin Gupta
Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages
On Fri, Oct 20, 2017 at 10:17:00AM +0200, Michal Hocko wrote: > On Fri 20-10-17 15:22:14, Xishi Qiu wrote: > > On 2017/10/20 10:13, Joonsoo Kim wrote: > > > > > On Thu, Oct 19, 2017 at 02:21:18PM +0200, Michal Hocko wrote: > [...] > > >> >From 8cbd811d741f5dd93d1b21bb3ef94482a4d0bd32 Mon Sep 17 00:00:00 2001 > > >> From: Michal Hocko > > >> Date: Thu, 19 Oct 2017 14:14:02 +0200 > > >> Subject: [PATCH] mm: distinguish CMA and MOVABLE isolation in > > >> has_unmovable_pages > > >> > > >> Joonsoo has noticed that "mm: drop migrate type checks from > > >> has_unmovable_pages" would break CMA allocator because it relies on > > >> has_unmovable_pages returning false even for CMA pageblocks which in > > >> fact don't have to be movable: > > >> alloc_contig_range > > >> start_isolate_page_range > > >> set_migratetype_isolate > > >> has_unmovable_pages > > >> > > >> This is a result of the code sharing between CMA and memory hotplug > > >> while each one has a different idea of what has_unmovable_pages should > > >> return. This is unfortunate but fixing it properly would require a lot > > >> of code duplication. > > >> > > >> Fix the issue by introducing the requested migrate type argument > > >> and special case MIGRATE_CMA case where CMA page blocks are handled > > >> properly. This will work for memory hotplug because it requires > > >> MIGRATE_MOVABLE. > > > > > > Unfortunately, alloc_contig_range() can be called with > > > MIGRATE_MOVABLE so this patch cannot perfectly fix the problem. > > > > > > I did a more thinking and found that it's strange to check if there is > > > unmovable page in the pageblock during the set_migratetype_isolate(). > > > set_migratetype_isolate() should be just for setting the migratetype > > > of the pageblock. Checking other things should be done by another > > > place, for example, before calling the start_isolate_page_range() in > > > __offline_pages(). > > > > > > Thanks. > > > > > > > Hi Joonsoo, > > > > How about add a flag to skip or not has_unmovable_pages() in > > set_migratetype_isolate()? > > Something like the skip_hwpoisoned_pages. > > I believe this is what Joonsoo was proposing actually. I cannot say I Yes, I initially suggested this idea but change my mind. Now, I think that problem is not in has_unmovable_pages() but in set_migratetype_isolate(). So different solution is needed. See my other reply to Michal. Thanks.
Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages
On Fri, Oct 20, 2017 at 09:02:20AM +0200, Michal Hocko wrote: > On Fri 20-10-17 15:50:14, Joonsoo Kim wrote: > > On Fri, Oct 20, 2017 at 07:59:22AM +0200, Michal Hocko wrote: > > > On Fri 20-10-17 11:13:29, Joonsoo Kim wrote: > > > > On Thu, Oct 19, 2017 at 02:21:18PM +0200, Michal Hocko wrote: > > > > > On Thu 19-10-17 10:20:41, Michal Hocko wrote: > > > > > > On Thu 19-10-17 16:33:56, Joonsoo Kim wrote: > > > > > > > On Thu, Oct 19, 2017 at 09:15:03AM +0200, Michal Hocko wrote: > > > > > > > > On Thu 19-10-17 11:51:11, Joonsoo Kim wrote: > > > > > > [...] > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > This patch will break the CMA user. As you mentioned, CMA > > > > > > > > > allocation > > > > > > > > > itself isn't migrateable. So, after a single page is > > > > > > > > > allocated through > > > > > > > > > CMA allocation, has_unmovable_pages() will return true for > > > > > > > > > this > > > > > > > > > pageblock. Then, futher CMA allocation request to this > > > > > > > > > pageblock will > > > > > > > > > fail because it requires isolating the pageblock. > > > > > > > > > > > > > > > > Hmm, does this mean that the CMA allocation path depends on > > > > > > > > has_unmovable_pages to return false here even though the memory > > > > > > > > is not > > > > > > > > movable? This sounds really strange to me and kind of abuse of > > > > > > > > this > > > > > > > > > > > > > > Your understanding is correct. Perhaps, abuse or wrong function > > > > > > > name. > > > > > > > > > > > > > > > function. Which path is that? Can we do the migrate type test > > > > > > > > theres? > > > > > > > > > > > > > > alloc_contig_range() -> start_isolate_page_range() -> > > > > > > > set_migratetype_isolate() -> has_unmovable_pages() > > > > > > > > > > > > I see. It seems that the CMA and memory hotplug have a very > > > > > > different > > > > > > view on what should happen during isolation. > > > > > > > > > > > > > We can add one argument, 'XXX' to set_migratetype_isolate() and > > > > > > > change > > > > > > > it to check migrate type rather than has_unmovable_pages() if > > > > > > > 'XXX' is > > > > > > > specified. > > > > > > > > > > > > Can we use the migratetype argument and do the special thing for > > > > > > MIGRATE_CMA? Like the following diff? > > > > > > > > > > And with the full changelog. > > > > > --- > > > > > >From 8cbd811d741f5dd93d1b21bb3ef94482a4d0bd32 Mon Sep 17 00:00:00 > > > > > >2001 > > > > > From: Michal Hocko > > > > > Date: Thu, 19 Oct 2017 14:14:02 +0200 > > > > > Subject: [PATCH] mm: distinguish CMA and MOVABLE isolation in > > > > > has_unmovable_pages > > > > > > > > > > Joonsoo has noticed that "mm: drop migrate type checks from > > > > > has_unmovable_pages" would break CMA allocator because it relies on > > > > > has_unmovable_pages returning false even for CMA pageblocks which in > > > > > fact don't have to be movable: > > > > > alloc_contig_range > > > > > start_isolate_page_range > > > > > set_migratetype_isolate > > > > > has_unmovable_pages > > > > > > > > > > This is a result of the code sharing between CMA and memory hotplug > > > > > while each one has a different idea of what has_unmovable_pages should > > > > > return. This is unfortunate but fixing it properly would require a lot > > > > > of code duplication. > > > > > > > > > > Fix the issue by introducing the requested migrate type argument > > > > > and special case MIGRATE_CMA case where CMA page blocks are handled > > > > > properly. This will work for memory hotplug because it requires > > > > > MIGRATE_MOVABLE. > > > > > > > > Unfortunately, alloc_contig_range() can be called with > > > > MIGRATE_MOVABLE so this patch cannot perfectly fix the problem. > > > > > > Yes, alloc_contig_range can be called with MIGRATE_MOVABLE but my > > > understanding is that only CMA allocator really depends on this weird > > > semantic and that does MIGRATE_CMA unconditionally. > > > > alloc_contig_range() could be called for partial pages in the > > pageblock. With your patch, this case also fails unnecessarilly if the > > other pages in the pageblock is pinned. > > Is this really the case for GB pages? Do we really want to mess those No, but, as I mentioned already, this API can be called with less pages. I know that there is no user with less pages at this moment but I cannot see any point to reduce this API's capability. > with CMA blocks and make those blocks basically unusable because GB > pages are rarely (if at all migrateable)? > > > Until now, there is no user calling alloc_contig_range() with partial > > pages except CMA allocator but API could support it. > > I disagree. If this is a CMA thing it should stay that way. The semantic > is quite confusing already, please let's not make it even worse. It is already used by other component. I'm not sure what is the confusing semantic you mentioned. I think that set_migratetype_isolate() has confusing semantic and
Re: [PATCH v6 1/6] perf report: properly handle branch count in match_chain
Hi Arnaldo and Milian,
On Fri, Oct 20, 2017 at 10:39:35AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 20, 2017 at 01:38:23PM +0200, Milian Wolff escreveu:
> > On Freitag, 20. Oktober 2017 12:21:35 CEST Milian Wolff wrote:
> > > On Donnerstag, 19. Oktober 2017 17:01:08 CEST Namhyung Kim wrote:
> > > > Hi Andi,
> > > >
> > > > On Thu, Oct 19, 2017 at 06:55:19AM -0700, Andi Kleen wrote:
> > > > > On Thu, Oct 19, 2017 at 12:59:14PM +0200, Milian Wolff wrote:
> > > > > > On Donnerstag, 19. Oktober 2017 00:41:04 CEST Andi Kleen wrote:
> > > > > > > Milian Wolff writes:
> > > > > > > > +static enum match_result match_address_dso(struct dso
> > > > > > > > *left_dso,
> > > > > > > > u64
> > > > > > > > left_ip, + struct dso
> > > > > > > > *right_dso, u64 right_ip)
> > > > > > > > +{
> > > > > > > > + if (left_dso == right_dso && left_ip == right_ip)
> > > > > > > > + return MATCH_EQ;
> > > > > > > > + else if (left_ip < right_ip)
> > > > > > > > + return MATCH_LT;
> > > > > > > > + else
> > > > > > > > + return MATCH_GT;
> > > > > > > > +}
> > > > > > >
> > > > > > > So why does only the first case check the dso? Does it not matter
> > > > > > > for the others?
> > > > > > >
> > > > > > > Either should be checked by none or by all.
> > > > > >
> > > > > > I don't see why it should be checked. It is only required to prevent
> > > > > > two
> > > > > > addresses to be considered equal while they are not. So only the one
> > > > > > check is required, otherwise we return either LT or GT.
> > > > >
> > > > > When the comparison is always in the same process (which I think
> > > > > is not the case) just checking the addresses is sufficient. If they
> > > > > are
> > > > > not then you always need to check the DSO and only compare inside the
> > > > > same DSO.
> > > >
> > > > As far as I know, the node->ip is a relative address (inside a DSO).
> > > > So it should compare the dso as well even in the same process.
> > >
> > > Sorry guys, I seem to be slow at understanding your review comments.
> > >
> > > match_address_dso should impose a sort order on two relative addresses.
> > > The
> > > order should ensure that relative addresses in a different DSO are not
> > > considered equal. But if the DSOs are different, it doesn't matter whether
> > > we return LT or GT - or?
> > >
> > > Put differently, how would you write this function to take care of the DSO
> > > in the other two branches? I.e. what to return if the DSOs are different -
> > > a MATCH_ERROR?
> >
> > Thinking a bit more about this. Are you guys maybe hinting at my
> > implementation breaking the strict ordering rules (is that the right
> > word?).
> > I.e. a < b && b > a iff a == b ? Potentially my implementation would break
> > this assumption when the relative IPs are the same, but the DSO is
> > different.
> >
> > So is this what you want:
> >
> > +static enum match_result match_address_dso(struct dso *left_dso, u64
> > left_ip, + struct dso *right_dso,
> > u64
> > right_ip)
> > +{
> > + if (left_dso == right_dso && left_ip == right_ip)
> > + return MATCH_EQ;
> > + else if (left_dso < right_dso || left_ip < right_ip)
> > + return MATCH_LT;
> > + else
> > + return MATCH_GT;
> > +}
How about
if (left_dso != right_dso)
return left_dso < right_dso ? MATCH_LT : MATCH_GT;
else if (left_ip != right_ip)
return left_ip < right_ip ? MATCH_LT : MATCH_GT;
else
return MATCH_EQ;
?
>
> Why not do all in terms of absolute addresses? Comparing relative
> addresses seems nonsensical anyway.
???
It needs to compare symbols of callchains from different address
spaces (i.e. tasks) too. We do the same when comparing symbols of
samples - please see sort__sym_cmp().
> Perhaps something like the patch
> below, and note that cnode->ip and node->ip already already are absolute
> addresses.
Only if it couldn't find a map?
Thanks,
Namhyung
>
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 35a920f09503..1ac3f4a5afab 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -671,8 +671,6 @@ static enum match_result match_chain(struct
> callchain_cursor_node *node,
> {
> struct symbol *sym = node->sym;
> u64 left, right;
> - struct dso *left_dso = NULL;
> - struct dso *right_dso = NULL;
>
> if (callchain_param.key == CCKEY_SRCLINE) {
> enum match_result match = match_chain_strings(cnode->srcline,
> @@ -698,16 +696,14 @@ static enum match_result match_chain(struct
> callchain_cursor_node *node,
> return match_chain_strings(cnode->ms.sym->name,
> node->sym->name);
>
> - left
Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax
On Fri, 20 Oct 2017 18:29:33 +0200 Christoph Hellwig wrote: > On Fri, Oct 20, 2017 at 08:23:02AM -0700, Dan Williams wrote: > > Yes, however it seems these drivers / platforms have been living with > > the lack of struct page for a long time. So they either don't use DAX, > > or they have a constrained use case that never triggers > > get_user_pages(). If it is the latter then they could introduce a new > > configuration option that bypasses the pfn_t_devmap() check in > > bdev_dax_supported() and fix up the get_user_pages() paths to fail. > > So, I'd like to understand how these drivers have been using DAX > > support without struct page to see if we need a workaround or we can > > go ahead delete this support. If the usage is limited to > > execute-in-place perhaps we can do a constrained ->direct_access() for > > just that case. > > For axonram I doubt anyone is using it any more - it was a very for > the IBM Cell blades, which were produceѕ in a rather limited number. > And Cell basically seems to be dead as far as I can tell. > > For S/390 Martin might be able to help out what the status of xpram > in general and DAX support in particular is. The goes back to the time where DAX was called XIP. The initial design point has been *not* to have struct pages for a large read-only memory area. There is a block device driver for z/VM that maps a DCSS segment somewhere in memore (no struct page!) with e.g. the complete /usr filesystem. The xpram driver is a different beast and has nothing to do with XIP/DAX. Now, if any there are very few users of the dcssblk driver out there. The idea to save a few megabyte for /usr never really took of. We have to look at our get_user_pages() implementation to see how hard it would be to make it fail if the target address is for an area without struct pages. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH v5] of: dynamic: fix memory leak related to properties of __of_node_dup
On 10/22/17 20:19, Lixin Wang wrote:
> If a node with no properties is dynamically added, then a property is
> dynamically added to the node, then the property is dynamically removed,
> the result will be node->properties == NULL and node->deadprops != NULL.
>
> Add a separate function to release the properties in both lists.
>
> Signed-off-by: Lixin Wang
> ---
> v4 -> v5:
> * fix the bug in v4, that the prop->next should be saved before release
>the prop.
>
> drivers/of/dynamic.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index 301b6db..39d69d3 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -315,6 +315,18 @@ int of_detach_node(struct device_node *np)
> }
> EXPORT_SYMBOL_GPL(of_detach_node);
>
> +static void property_list_free(struct property *prop_list)
> +{
> + struct property *prop, *next;
> +
> + for (prop = prop_list; prop != NULL; prop = next) {
> + next = prop->next;
> + kfree(prop->name);
> + kfree(prop->value);
> + kfree(prop);
> + }
> +}
> +
> /**
> * of_node_release() - release a dynamically allocated node
> * @kref: kref element of the node to be released
> @@ -324,7 +336,6 @@ EXPORT_SYMBOL_GPL(of_detach_node);
> void of_node_release(struct kobject *kobj)
> {
> struct device_node *node = kobj_to_device_node(kobj);
> - struct property *prop = node->properties;
>
> /* We should never be releasing nodes that haven't been detached. */
> if (!of_node_check_flag(node, OF_DETACHED)) {
> @@ -335,18 +346,9 @@ void of_node_release(struct kobject *kobj)
> if (!of_node_check_flag(node, OF_DYNAMIC))
> return;
>
> - while (prop) {
> - struct property *next = prop->next;
> - kfree(prop->name);
> - kfree(prop->value);
> - kfree(prop);
> - prop = next;
> + property_list_free(node->properties);
> + property_list_free(node->deadprops);
>
> - if (!prop) {
> - prop = node->deadprops;
> - node->deadprops = NULL;
> - }
> - }
> kfree(node->full_name);
> kfree(node->data);
> kfree(node);
>
Hi Lixin,
My bad... Thanks for the fix.
Reviewed-by: Frank Rowand
Re: [PATCH] PM / QoS: Fix device resume latency PM QoS
On 10/20/2017 07:27 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The special value of 0 for device resume latency PM QoS means > "no restriction", but there are two problems with that. > > First, device resume latency PM QoS requests with 0 as the > value are always put in front of requests with positive > values in the priority lists used internally by the PM QoS > framework, causing 0 to be chosen as an effective constraint > value. However, that 0 is then interpreted as "no restriction" > effectively overriding the other requests with specific > restrictions which is incorrect. > > Second, the users of device resume latency PM QoS have no > way to specify that *any* resume latency at all should be > avoided, which is an artificial limitation in general. > > To address these issues, modify device resume latency PM QoS to > use S32_MAX as the "no constraint" value and 0 as the "no > latency at all" one and rework its users (the cpuidle menu > governor, the genpd QoS governor and the runtime PM framework) > to follow these changes. > > Also add a special "n/a" value to the corresponding user space I/F > to allow user space to indicate that it cannot accept any resume > latencies at all for the given device. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323 > Signed-off-by: Rafael J. Wysocki > Reported-by: Reinette Chatre Acked-by: Alex Shi
RE: [PATCH v5 3/7] PM / devfreq: Use the available min/max frequency
> The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able
> to disable OPP as a cooling device. In result, both update_devfreq()
> and {min|max}_freq_show() have to consider the 'opp->available'
> status of each OPP.
>
> So, this patch adds the 'scaling_{min|max}_freq' to struct devfreq
> in order to indicate the available mininum and maximum frequency
> by adjusting OPP interface such as dev_pm_opp_{disable|enable}().
> The 'scaling_{min|max}_freq' are used for on both update_devfreq()
> and {min|max}_freq_show().
>
> Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
(along with the 2/7, revert commit)
> ---
> drivers/devfreq/devfreq.c | 40
> include/linux/devfreq.h | 4
> 2 files changed, 36 insertions(+), 8 deletions(-)
Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()
On 10/22/2017 07:55 PM, Jarkko Sakkinen wrote: > On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote: >> I've always been curious, and the changelog and thread are curiously >> oblique on this topic: what the heck does this driver use pipes *for*? > For communication with the process hosting the launch enclave. But, why pipes? Why does the kernel have to be the one setting these up? Why is this communication necessary in the first place?
Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device
On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
> Gently Ping.
>
> Dear Kishon,
>
> Could you please review this patch for 'drivers/phy/*'?
sorry for the delay.. here it is
Acked-by: Kishon Vijay Abraham I
>
> Regards,
> Chanwoo Choi
>
> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>> Dear Kishon,
>>
>> Could you please review this patch?
>> After that, I'll make the immutable brand and then send the pull request
>> for power_supply, mfd, phy, usb and extcon framework.
>>
>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
>>> The extcon has two type of extcon devices as following.
>>> - 'extcon provider deivce' adds new extcon device and detect the
>>>state/properties of external connector. Also, it notifies the
>>>state/properties to the extcon consumer device.
>>> - 'extcon consumer device' gets the change state/properties
>>>from extcon provider device.
>>> Prior to that, include/linux/extcon.h contains all exported API for
>>> both provider and consumer device driver. To clarify the meaning of
>>> header file and to remove the wrong use-case on consumer device,
>>> this patch separates into extcon.h and extcon-provider.h.
>>>
>>> [Description for include/linux/{extcon.h|extcon-provider.h}]
>>> - extcon.h includes the extcon API and data structure for extcon consumer
>>> device driver. This header file contains the following APIs:
>>> : Register/unregister the notifier to catch the change of extcon device
>>> : Get the extcon device instance
>>> : Get the extcon device name
>>> : Get the state of each external connector
>>> : Get the property value of each external connector
>>> : Get the property capability of each external connector
>>>
>>> - extcon-provider.h includes the extcon API and data structure for extcon
>>> provider device driver. This header file contains the following APIs:
>>> : Include 'include/linux/extcon.h'
>>> : Allocate the memory for extcon device instance
>>> : Register/unregister extcon device
>>> : Set the state of each external connector
>>> : Set the property value of each external connector
>>> : Set the property capability of each external connector
>>>
>>> Cc: Felipe Balbi
>>> Cc: Kishon Vijay Abraham I
>>> Cc: Greg Kroah-Hartman
>>> Acked-by: Sebastian Reichel
>>> Acked-by: Chen-Yu Tsai
>>> Acked-by: Charles Keepax
>>> Acked-by: Lee Jones
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> Changes from v1:
>>> - Don't touch drivers/usb/renesas_usbhs/common.h.
>>> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
>>> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
>>> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
>>> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
>>>
>>> drivers/extcon/extcon-adc-jack.c | 2 +-
>>> drivers/extcon/extcon-arizona.c | 2 +-
>>> drivers/extcon/extcon-axp288.c| 2 +-
>>> drivers/extcon/extcon-gpio.c | 2 +-
>>> drivers/extcon/extcon-intel-cht-wc.c | 2 +-
>>> drivers/extcon/extcon-intel-int3496.c | 2 +-
>>> drivers/extcon/extcon-max14577.c | 2 +-
>>> drivers/extcon/extcon-max3355.c | 2 +-
>>> drivers/extcon/extcon-max77693.c | 2 +-
>>> drivers/extcon/extcon-max77843.c | 2 +-
>>> drivers/extcon/extcon-max8997.c | 2 +-
>>> drivers/extcon/extcon-qcom-spmi-misc.c| 2 +-
>>> drivers/extcon/extcon-rt8973a.c | 2 +-
>>> drivers/extcon/extcon-sm5502.c| 2 +-
>>> drivers/extcon/extcon-usb-gpio.c | 2 +-
>>> drivers/extcon/extcon-usbc-cros-ec.c | 2 +-
>>> drivers/extcon/extcon.h | 2 +-
>>> drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
>>> drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c | 2 +-
>>> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +-
>>> drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 2 +-
>>> drivers/power/supply/qcom_smbb.c | 2 +-
>>> drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
>>> drivers/usb/phy/phy-tahvo.c | 2 +-
>>> include/linux/extcon-provider.h | 142
>>> ++
>>> include/linux/extcon.h| 109 +---
>>> include/linux/mfd/palmas.h| 2 +-
>>> 27 files changed, 172 insertions(+), 129 deletions(-)
>>> create mode 100644 include/linux/extcon-provider.h
>>>
>>> diff --git a/drivers/extcon/extcon-adc-jack.c
>>> b/drivers/extcon/extcon-adc-jack.c
>>> index 6f6537ab0a79..3877d86c746a 100644
>>> --- a/drivers/extcon/extcon-adc-jack.c
>>> +++ b/drivers/extcon/extcon-adc-jack.c
>>> @@ -26,7 +26,7 @@
>>> #include
>>> #include
>>> #include
>>> -#include
>>> +#include
>>>
>>> /**
>>> * struct adc_jack_data - internal data for adc_jack device driver
>>> diff --git a/drivers
[PATCH] objtool: Refactor insn search in add_dead_ends()
Move the search for instruction dead_end into helper function
__add_dead_ends(), instead of duplicating the search for unreachable
and reachable sections in add_dead_ends().
Cc: Ingo Molnar
Signed-off-by: Kamalesh Babulal
---
tools/objtool/check.c | 108 +++---
1 file changed, 50 insertions(+), 58 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index c0e26ad1fa7e..c82966b3ad96 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -303,36 +303,23 @@ static int decode_instructions(struct objtool_file *file)
return ret;
}
-/*
- * Mark "ud2" instructions and manually annotated dead ends.
- */
-static int add_dead_ends(struct objtool_file *file)
+static int __add_dead_ends(struct objtool_file *file, struct section *sec,
+ bool unreachable_sec)
{
- struct section *sec;
- struct rela *rela;
+ char warn_str[12] = "unreachable";
struct instruction *insn;
+ struct rela *rela;
bool found;
- /*
-* By default, "ud2" is a dead end unless otherwise annotated, because
-* GCC 7 inserts it for certain divide-by-zero cases.
-*/
- for_each_insn(file, insn)
- if (insn->type == INSN_BUG)
- insn->dead_end = true;
-
- /*
-* Check for manually annotated dead ends.
-*/
- sec = find_section_by_name(file->elf, ".rela.discard.unreachable");
- if (!sec)
- goto reachable;
+ if (!unreachable_sec)
+ strcpy(warn_str, "reachable");
list_for_each_entry(rela, &sec->rela_list, list) {
if (rela->sym->type != STT_SECTION) {
- WARN("unexpected relocation symbol type in %s",
sec->name);
+ WARN("Unexpected relocation symbol type in %s",
sec->name);
return -1;
}
+
insn = find_insn(file, rela->sym->sec, rela->addend);
if (insn)
insn = list_prev_entry(insn, list);
@@ -346,19 +333,54 @@ static int add_dead_ends(struct objtool_file *file)
}
if (!found) {
- WARN("can't find unreachable insn at %s+0x%x",
-rela->sym->sec->name, rela->addend);
+ WARN("can't find %s insn at %s+0x%x",
+ warn_str, rela->sym->sec->name,
+ rela->addend);
return -1;
}
} else {
- WARN("can't find unreachable insn at %s+0x%x",
-rela->sym->sec->name, rela->addend);
+ WARN("can't find %s insn at %s+0x%x",
+ warn_str, rela->sym->sec->name, rela->addend);
return -1;
}
- insn->dead_end = true;
+ /*
+* reachable section's insn->dead_end are false.
+*/
+ insn->dead_end = unreachable_sec;
}
+ return 0;
+}
+
+/*
+ * Mark "ud2" instructions and manually annotated dead ends.
+ */
+static int add_dead_ends(struct objtool_file *file)
+{
+ struct section *sec;
+ struct instruction *insn;
+ int ret;
+
+ /*
+* By default, "ud2" is a dead end unless otherwise annotated, because
+* GCC 7 inserts it for certain divide-by-zero cases.
+*/
+ for_each_insn(file, insn)
+ if (insn->type == INSN_BUG)
+ insn->dead_end = true;
+
+ /*
+* Check for manually annotated dead ends.
+*/
+ sec = find_section_by_name(file->elf, ".rela.discard.unreachable");
+ if (!sec)
+ goto reachable;
+
+ ret = __add_dead_ends(file, sec, true);
+ if (ret == -1)
+ return ret;
+
reachable:
/*
* These manually annotated reachable checks are needed for GCC 4.4,
@@ -370,38 +392,8 @@ static int add_dead_ends(struct objtool_file *file)
if (!sec)
return 0;
- list_for_each_entry(rela, &sec->rela_list, list) {
- if (rela->sym->type != STT_SECTION) {
- WARN("unexpected relocation symbol type in %s",
sec->name);
- return -1;
- }
- insn = find_insn(file, rela->sym->sec, rela->addend);
- if (insn)
- insn = list_prev_entry(insn, list);
- else if (rela->addend == rela->sym->sec->len) {
- found = false;
- list_for_each_entry_reverse(insn, &file->insn_list,
list) {
- if (insn->sec == rela->sym->sec) {
- fou
Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds
On Thu, Oct 19, 2017 at 8:54 PM, Timur Tabi wrote: > On 10/18/17 3:57 PM, Amit Kucheria wrote: >> >> Enable panic and disk activity triggers to tie to LED activity > > > Could you provide some explanation as to why we want this enabled for ARM64? > I don't have a problem with the change itself, but I think patch > descriptions for defconfig changes should include justifications. Indeed. The blurb should be modified as follows: "Most development boards and devices have one or more LEDs. It is useful during debugging if they can be wired to show different behaviours such as disk or cpu activity or a load-average dependent heartbeat. Enable panic and disk activity triggers so they can be tied to LED activity during debugging as well." If this blurb works, I'll send out another version.
Re: PCIe legacy interrupts blocked on Intel Apollo Lake platforms
Hi, On Wed, Oct 18, 2017 at 7:54 PM, Andy Shevchenko wrote: > While Rafael is looking for a solution, can you in meantime gather the > following on the affected hardware and share it via some resource on > Internet? > > 1. % acpidump -o tables.dat # tables.dat is point of interest https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/acpi%2520tables > 2. % lspci -vv -nk # output of the command https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/pci > 3. % dmidecode # output of the command https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/dmidecode > 4. % grep -H 15 /sys/bus/acpi/devices/*/status # output of the command https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/grep%2520-H%252015%2520acpi%2520status > 5. % dmesg # when kernel command line has the 'ignore_loglevel > initcall_debug' added https://gist.githubusercontent.com/dsd/ef9b9da4c634f57de89f917c43703272/raw/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8/dmesg All above files in a zip: https://gist.github.com/dsd/ef9b9da4c634f57de89f917c43703272/archive/391db13df07ceab78ccc2ca1d5f4e5ccd3fb10d8.zip Please let me know how we can help further! Daniel
Re: n900 in next-20170901
On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim [171019 18:53]:
> > Oops... I made a mistak. Could you test with reverting commit
> > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call
> > save_secure_ram_context() for test") in that branch?
> > Without reverting it, it doesn't call 'smc' so it always cause a
> > hang.
>
> Oops I should have noticed that one. Here you go with commit
> c977ee280378 reverted. Still not booting.
Still very thanks to you. :)
Okay. Could you test my updated branch? In there, I also disable
atomic_pool initialization and disable to remap the CMA area in order
to completely make any operation on CMA area as no-op.
And, it enables memblock_debug to check how memblock region is
allocated.
https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901
Thanks.
Re: [PATCH 4/4] arm64: dts: hisilicon: hi3660-hikey960: Allow USR4 LED to notify kernel panic
On Thu, Oct 19, 2017 at 5:30 PM, Guodong Xu wrote: > > > On Thu, Oct 19, 2017 at 4:57 AM, Amit Kucheria > wrote: >> >> Blink the LED on a kernel panic. >> >> Signed-off-by: Amit Kucheria >> --- >> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts >> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts >> index fd4705c..febbcb5 100644 >> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts >> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts >> @@ -108,6 +108,7 @@ >> label = "user_led4"; >> /* gpio_190_user_led4 */ >> gpios = <&gpio23 6 0>; >> + panic-indicator; > > > Looks good to me. Can I take that as an Ack? How about the Hikey960 patch? > > >> >> linux,default-trigger = "cpu0"; >> }; >> >> -- >> 2.7.4 >> >
Re: [PATCH] net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG
From: "Gustavo A. R. Silva" Date: Fri, 20 Oct 2017 19:43:11 -0500 > Use BUG_ON instead of if condition followed by BUG in do_setlink. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Applied.
[PATCH v6 4/9] arm: dts: mt2712: Add clock controller device nodes
Add clock controller nodes for MT2712, include topckgen, infracfg,
pericfg, mcucfg and apmixedsys. This patch also add six oscillators that
provide clocks for MT2712.
Signed-off-by: Weiyi Lu
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 115 ++
1 file changed, 115 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 57d0396..d2ee3cd 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -5,6 +5,7 @@
* SPDX-License-Identifier: (GPL-2.0 OR MIT)
*/
+#include
#include
#include
@@ -73,6 +74,48 @@
#clock-cells = <0>;
};
+ clk26m: oscillator@0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "clk26m";
+ };
+
+ clk32k: oscillator@1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "clk32k";
+ };
+
+ clkfpc: oscillator@2 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ clock-output-names = "clkfpc";
+ };
+
+ clkaud_ext_i_0: oscillator@3 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <650>;
+ clock-output-names = "clkaud_ext_i_0";
+ };
+
+ clkaud_ext_i_1: oscillator@4 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <196608000>;
+ clock-output-names = "clkaud_ext_i_1";
+ };
+
+ clkaud_ext_i_2: oscillator@5 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <180633600>;
+ clock-output-names = "clkaud_ext_i_2";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
@@ -86,6 +129,24 @@
(GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_LOW)>;
};
+ topckgen: syscon@1000 {
+ compatible = "mediatek,mt2712-topckgen", "syscon";
+ reg = <0 0x1000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ infracfg: syscon@10001000 {
+ compatible = "mediatek,mt2712-infracfg", "syscon";
+ reg = <0 0x10001000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ pericfg: syscon@10003000 {
+ compatible = "mediatek,mt2712-pericfg", "syscon";
+ reg = <0 0x10003000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
uart5: serial@1000f000 {
compatible = "mediatek,mt2712-uart",
"mediatek,mt6577-uart";
@@ -96,6 +157,18 @@
status = "disabled";
};
+ apmixedsys: syscon@10209000 {
+ compatible = "mediatek,mt2712-apmixedsys", "syscon";
+ reg = <0 0x10209000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ mcucfg: syscon@1022 {
+ compatible = "mediatek,mt2712-mcucfg", "syscon";
+ reg = <0 0x1022 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysirq: interrupt-controller@10220a80 {
compatible = "mediatek,mt2712-sysirq",
"mediatek,mt6577-sysirq";
@@ -167,5 +240,47 @@
clock-names = "baud", "bus";
status = "disabled";
};
+
+ mfgcfg: syscon@1300 {
+ compatible = "mediatek,mt2712-mfgcfg", "syscon";
+ reg = <0 0x1300 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ mmsys: syscon@1400 {
+ compatible = "mediatek,mt2712-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: syscon@1500 {
+ compatible = "mediatek,mt2712-imgsys", "syscon";
+ reg = <0 0x1500 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ bdpsys: syscon@1501 {
+ compatible = "mediatek,mt2712-bdpsys", "syscon";
+ reg = <0 0x1501 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: syscon@1600 {
+ compatible = "mediatek,mt2712-vdecsys", "syscon";
+ reg = <0 0x1600 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vencsys: syscon@1800 {
+ compatible = "mediatek,mt2712-vencsys", "syscon";
+ reg = <0 0x1800 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ jpgdecsys: syscon@1900 {
+ compatible = "mediate
[PATCH v6 7/9] soc: mediatek: add dependent clock jpgdec/audio for scpsys
There are dependent clock jpgdec/audio in scpsys on MT2712,
and will exist three dependent clocks on MT2712 VDEC.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index ba552de..7e7e4ec 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -84,6 +84,8 @@ enum clk_id {
CLK_ETHIF,
CLK_VDEC,
CLK_HIFSEL,
+ CLK_JPGDEC,
+ CLK_AUDIO,
CLK_MAX,
};
@@ -96,10 +98,12 @@ enum clk_id {
"ethif",
"vdec",
"hif_sel",
+ "jpgdec",
+ "audio",
NULL,
};
-#define MAX_CLKS 2
+#define MAX_CLKS 3
struct scp_domain_data {
const char *name;
--
1.9.1
[PATCH v6 6/9] soc: mediatek: extend bus protection API
MT2712 add "set/clear" bus control register to each control register set
instead of providing only one "enable" control register, we could avoid
the read-modify-write racing by declaring "bus_prot_reg_update" as "false"
in scp_soc_data or declaring as "true" to use the legacy update method.
By improving the mtk-infracfg bus protection implementation to
support set/clear bus protection control method by IC configuration.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-infracfg.c | 26 ++
drivers/soc/mediatek/mtk-scpsys.c | 28
include/linux/soc/mediatek/infracfg.h | 7 ---
3 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-infracfg.c
b/drivers/soc/mediatek/mtk-infracfg.c
index dba3055..8c310de 100644
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ b/drivers/soc/mediatek/mtk-infracfg.c
@@ -19,23 +19,33 @@
#define INFRA_TOPAXI_PROTECTEN 0x0220
#define INFRA_TOPAXI_PROTECTSTA1 0x0228
+#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
+#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
/**
* mtk_infracfg_set_bus_protection - enable bus protection
* @regmap: The infracfg regmap
* @mask: The mask containing the protection bits to be enabled.
+ * @reg_update: The boolean flag determines to set the protection bits
+ * by regmap_update_bits with enable register(PROTECTEN) or
+ * by regmap_write with set register(PROTECTEN_SET).
*
* This function enables the bus protection bits for disabled power
* domains so that the system does not hang when some unit accesses the
* bus while in power down.
*/
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask)
+int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
+ bool reg_update)
{
unsigned long expired;
u32 val;
int ret;
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, mask);
+ if (reg_update)
+ regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
+ mask);
+ else
+ regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
expired = jiffies + HZ;
@@ -59,16 +69,24 @@ int mtk_infracfg_set_bus_protection(struct regmap
*infracfg, u32 mask)
* mtk_infracfg_clear_bus_protection - disable bus protection
* @regmap: The infracfg regmap
* @mask: The mask containing the protection bits to be disabled.
+ * @reg_update: The boolean flag determines to clear the protection bits
+ * by regmap_update_bits with enable register(PROTECTEN) or
+ * by regmap_write with clear register(PROTECTEN_CLR).
*
* This function disables the bus protection bits previously enabled with
* mtk_infracfg_set_bus_protection.
*/
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask)
+
+int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
+ bool reg_update)
{
unsigned long expired;
int ret;
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+ if (reg_update)
+ regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
+ else
+ regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
expired = jiffies + HZ;
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index e1ce8b1..ba552de 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -134,6 +134,7 @@ struct scp {
void __iomem *base;
struct regmap *infracfg;
struct scp_ctrl_reg ctrl_reg;
+ bool bus_prot_reg_update;
};
struct scp_subdomain {
@@ -147,6 +148,7 @@ struct scp_soc_data {
const struct scp_subdomain *subdomains;
int num_subdomains;
const struct scp_ctrl_reg regs;
+ bool bus_prot_reg_update;
};
static int scpsys_domain_is_on(struct scp_domain *scpd)
@@ -254,7 +256,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
- scpd->data->bus_prot_mask);
+ scpd->data->bus_prot_mask,
+ scp->bus_prot_reg_update);
if (ret)
goto err_pwr_ack;
}
@@ -289,7 +292,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
if (scpd->data->bus_prot_mask) {
ret = mtk_infracfg_set_bus_protection(scp->infracfg,
- scpd->data->bus_prot_mask);
+ scpd->data->bus_prot_mask,
+ scp->bus_prot_reg_update);
if (ret)
goto out;
}
@@ -382,7 +386,8 @@ static void init_clks(struct platform_device *pdev, struct
clk
[PATCH v6 8/9] soc: mediatek: add MT2712 scpsys support
add scpsys driver for MT2712
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 106 +++---
1 file changed, 100 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 7e7e4ec..2a0c3a7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
@@ -32,7 +33,7 @@
#define SPM_DIS_PWR_CON0x023c
#define SPM_CONN_PWR_CON 0x0280
#define SPM_VEN2_PWR_CON 0x0298
-#define SPM_AUDIO_PWR_CON 0x029c /* MT8173 */
+#define SPM_AUDIO_PWR_CON 0x029c /* MT8173, MT2712 */
#define SPM_BDP_PWR_CON0x029c /* MT2701 */
#define SPM_ETH_PWR_CON0x02a0
#define SPM_HIF_PWR_CON0x02a4
@@ -40,12 +41,12 @@
#define SPM_MFG_2D_PWR_CON 0x02c0
#define SPM_MFG_ASYNC_PWR_CON 0x02c4
#define SPM_USB_PWR_CON0x02cc
+#define SPM_USB2_PWR_CON 0x02d4 /* MT2712 */
#define SPM_ETHSYS_PWR_CON 0x02e0 /* MT7622 */
#define SPM_HIF0_PWR_CON 0x02e4 /* MT7622 */
#define SPM_HIF1_PWR_CON 0x02e8 /* MT7622 */
#define SPM_WB_PWR_CON 0x02ec /* MT7622 */
-
#define SPM_PWR_STATUS 0x060c
#define SPM_PWR_STATUS_2ND 0x0610
@@ -64,12 +65,13 @@
#define PWR_STATUS_ETH BIT(15)
#define PWR_STATUS_HIF BIT(16)
#define PWR_STATUS_IFR_MSC BIT(17)
+#define PWR_STATUS_USB2BIT(19) /* MT2712 */
#define PWR_STATUS_VENC_LT BIT(20)
#define PWR_STATUS_VENCBIT(21)
-#define PWR_STATUS_MFG_2D BIT(22)
-#define PWR_STATUS_MFG_ASYNC BIT(23)
-#define PWR_STATUS_AUDIO BIT(24)
-#define PWR_STATUS_USB BIT(25)
+#define PWR_STATUS_MFG_2D BIT(22) /* MT8173 */
+#define PWR_STATUS_MFG_ASYNC BIT(23) /* MT8173 */
+#define PWR_STATUS_AUDIO BIT(24) /* MT8173, MT2712 */
+#define PWR_STATUS_USB BIT(25) /* MT8173, MT2712 */
#define PWR_STATUS_ETHSYS BIT(24) /* MT7622 */
#define PWR_STATUS_HIF0BIT(25) /* MT7622 */
#define PWR_STATUS_HIF1BIT(26) /* MT7622 */
@@ -602,6 +604,85 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
};
/*
+ * MT2712 power domain support
+ */
+static const struct scp_domain_data scp_domain_data_mt2712[] = {
+ [MT2712_POWER_DOMAIN_MM] = {
+ .name = "mm",
+ .sta_mask = PWR_STATUS_DISP,
+ .ctl_offs = SPM_DIS_PWR_CON,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_MM},
+ .active_wakeup = true,
+ },
+ [MT2712_POWER_DOMAIN_VDEC] = {
+ .name = "vdec",
+ .sta_mask = PWR_STATUS_VDEC,
+ .ctl_offs = SPM_VDE_PWR_CON,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_MM, CLK_VDEC},
+ .active_wakeup = true,
+ },
+ [MT2712_POWER_DOMAIN_VENC] = {
+ .name = "venc",
+ .sta_mask = PWR_STATUS_VENC,
+ .ctl_offs = SPM_VEN_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .clk_id = {CLK_MM, CLK_VENC, CLK_JPGDEC},
+ .active_wakeup = true,
+ },
+ [MT2712_POWER_DOMAIN_ISP] = {
+ .name = "isp",
+ .sta_mask = PWR_STATUS_ISP,
+ .ctl_offs = SPM_ISP_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .clk_id = {CLK_MM},
+ .active_wakeup = true,
+ },
+ [MT2712_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = PWR_STATUS_AUDIO,
+ .ctl_offs = SPM_AUDIO_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .clk_id = {CLK_AUDIO},
+ .active_wakeup = true,
+ },
+ [MT2712_POWER_DOMAIN_USB] = {
+ .name = "usb",
+ .sta_mask = PWR_STATUS_USB,
+ .ctl_offs = SPM_USB_PWR_CON,
+ .sram_pdn_bits = GENMASK(10, 8),
+ .sram_pdn_ack_bits = GENMASK(14, 12),
+ .clk_id = {CLK_NONE},
+ .active_wakeup = true,
+ },
+ [MT2712_POWER_DOMAIN_USB2] = {
+ .name = "usb2",
+ .sta_mask = PWR_STATUS_USB2,
+ .ctl_offs = SPM_USB2_PWR
[PATCH v6 3/9] clk: mediatek: Add MT2712 clock support
Add MT2712 clock support, include topckgen, apmixedsys, infracfg, pericfg, mcucfg and subsystem clocks. Signed-off-by: Weiyi Lu --- drivers/clk/mediatek/Kconfig | 50 ++ drivers/clk/mediatek/Makefile|8 + drivers/clk/mediatek/clk-mt2712-bdp.c| 102 +++ drivers/clk/mediatek/clk-mt2712-img.c| 80 ++ drivers/clk/mediatek/clk-mt2712-jpgdec.c | 76 ++ drivers/clk/mediatek/clk-mt2712-mfg.c| 75 ++ drivers/clk/mediatek/clk-mt2712-mm.c | 170 drivers/clk/mediatek/clk-mt2712-vdec.c | 94 ++ drivers/clk/mediatek/clk-mt2712-venc.c | 77 ++ drivers/clk/mediatek/clk-mt2712.c| 1435 ++ drivers/clk/mediatek/clk-mtk.h |2 + drivers/clk/mediatek/clk-pll.c | 13 +- 12 files changed, 2180 insertions(+), 2 deletions(-) create mode 100644 drivers/clk/mediatek/clk-mt2712-bdp.c create mode 100644 drivers/clk/mediatek/clk-mt2712-img.c create mode 100644 drivers/clk/mediatek/clk-mt2712-jpgdec.c create mode 100644 drivers/clk/mediatek/clk-mt2712-mfg.c create mode 100644 drivers/clk/mediatek/clk-mt2712-mm.c create mode 100644 drivers/clk/mediatek/clk-mt2712-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt2712-venc.c create mode 100644 drivers/clk/mediatek/clk-mt2712.c diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig index 28739a9..300dbb5 100644 --- a/drivers/clk/mediatek/Kconfig +++ b/drivers/clk/mediatek/Kconfig @@ -50,6 +50,56 @@ config COMMON_CLK_MT2701_BDPSYS ---help--- This driver supports Mediatek MT2701 bdpsys clocks. +config COMMON_CLK_MT2712 + bool "Clock driver for Mediatek MT2712" + depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST + select COMMON_CLK_MEDIATEK + default ARCH_MEDIATEK && ARM64 + ---help--- + This driver supports Mediatek MT2712 basic clocks. + +config COMMON_CLK_MT2712_BDPSYS + bool "Clock driver for Mediatek MT2712 bdpsys" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 bdpsys clocks. + +config COMMON_CLK_MT2712_IMGSYS + bool "Clock driver for Mediatek MT2712 imgsys" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 imgsys clocks. + +config COMMON_CLK_MT2712_JPGDECSYS + bool "Clock driver for Mediatek MT2712 jpgdecsys" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 jpgdecsys clocks. + +config COMMON_CLK_MT2712_MFGCFG + bool "Clock driver for Mediatek MT2712 mfgcfg" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 mfgcfg clocks. + +config COMMON_CLK_MT2712_MMSYS + bool "Clock driver for Mediatek MT2712 mmsys" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 mmsys clocks. + +config COMMON_CLK_MT2712_VDECSYS + bool "Clock driver for Mediatek MT2712 vdecsys" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 vdecsys clocks. + +config COMMON_CLK_MT2712_VENCSYS + bool "Clock driver for Mediatek MT2712 vencsys" + depends on COMMON_CLK_MT2712 + ---help--- + This driver supports Mediatek MT2712 vencsys clocks. + config COMMON_CLK_MT6797 bool "Clock driver for Mediatek MT6797" depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile index 2a755b5..a4e5c47 100644 --- a/drivers/clk/mediatek/Makefile +++ b/drivers/clk/mediatek/Makefile @@ -12,5 +12,13 @@ obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o obj-$(CONFIG_COMMON_CLK_MT2701_VDECSYS) += clk-mt2701-vdec.o +obj-$(CONFIG_COMMON_CLK_MT2712) += clk-mt2712.o +obj-$(CONFIG_COMMON_CLK_MT2712_BDPSYS) += clk-mt2712-bdp.o +obj-$(CONFIG_COMMON_CLK_MT2712_IMGSYS) += clk-mt2712-img.o +obj-$(CONFIG_COMMON_CLK_MT2712_JPGDECSYS) += clk-mt2712-jpgdec.o +obj-$(CONFIG_COMMON_CLK_MT2712_MFGCFG) += clk-mt2712-mfg.o +obj-$(CONFIG_COMMON_CLK_MT2712_MMSYS) += clk-mt2712-mm.o +obj-$(CONFIG_COMMON_CLK_MT2712_VDECSYS) += clk-mt2712-vdec.o +obj-$(CONFIG_COMMON_CLK_MT2712_VENCSYS) += clk-mt2712-venc.o obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o diff --git a/drivers/clk/mediatek/clk-mt2712-bdp.c b/drivers/clk/mediatek/clk-mt2712-bdp.c new file mode 100644 index 000..5fe4728 --- /dev/null +++ b/drivers/clk/mediatek/clk-mt2712-bdp.c @@ -0,0 +1,102 @@ +/* + * Copyright (c) 2017 MediaTek Inc. + * Author: Weiyi Lu + * + * 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 pr
[PATCH v6 2/9] clk: mediatek: Add dt-bindings for MT2712 clocks
Add MT2712 clock dt-bindings, include topckgen, apmixedsys, infracfg, pericfg, mcucfg and subsystem clocks. Signed-off-by: Weiyi Lu --- include/dt-bindings/clock/mt2712-clk.h | 427 + 1 file changed, 427 insertions(+) create mode 100644 include/dt-bindings/clock/mt2712-clk.h diff --git a/include/dt-bindings/clock/mt2712-clk.h b/include/dt-bindings/clock/mt2712-clk.h new file mode 100644 index 000..48a8e79 --- /dev/null +++ b/include/dt-bindings/clock/mt2712-clk.h @@ -0,0 +1,427 @@ +/* + * Copyright (c) 2017 MediaTek Inc. + * Author: Weiyi Lu + * + * 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. + */ + +#ifndef _DT_BINDINGS_CLK_MT2712_H +#define _DT_BINDINGS_CLK_MT2712_H + +/* APMIXEDSYS */ + +#define CLK_APMIXED_MAINPLL0 +#define CLK_APMIXED_UNIVPLL1 +#define CLK_APMIXED_VCODECPLL 2 +#define CLK_APMIXED_VENCPLL3 +#define CLK_APMIXED_APLL1 4 +#define CLK_APMIXED_APLL2 5 +#define CLK_APMIXED_LVDSPLL6 +#define CLK_APMIXED_LVDSPLL2 7 +#define CLK_APMIXED_MSDCPLL8 +#define CLK_APMIXED_MSDCPLL2 9 +#define CLK_APMIXED_TVDPLL 10 +#define CLK_APMIXED_MMPLL 11 +#define CLK_APMIXED_ARMCA35PLL 12 +#define CLK_APMIXED_ARMCA72PLL 13 +#define CLK_APMIXED_ETHERPLL 14 +#define CLK_APMIXED_NR_CLK 15 + +/* TOPCKGEN */ + +#define CLK_TOP_ARMCA35PLL 0 +#define CLK_TOP_ARMCA35PLL_600M1 +#define CLK_TOP_ARMCA35PLL_400M2 +#define CLK_TOP_ARMCA72PLL 3 +#define CLK_TOP_SYSPLL 4 +#define CLK_TOP_SYSPLL_D2 5 +#define CLK_TOP_SYSPLL1_D2 6 +#define CLK_TOP_SYSPLL1_D4 7 +#define CLK_TOP_SYSPLL1_D8 8 +#define CLK_TOP_SYSPLL1_D169 +#define CLK_TOP_SYSPLL_D3 10 +#define CLK_TOP_SYSPLL2_D2 11 +#define CLK_TOP_SYSPLL2_D4 12 +#define CLK_TOP_SYSPLL_D5 13 +#define CLK_TOP_SYSPLL3_D2 14 +#define CLK_TOP_SYSPLL3_D4 15 +#define CLK_TOP_SYSPLL_D7 16 +#define CLK_TOP_SYSPLL4_D2 17 +#define CLK_TOP_SYSPLL4_D4 18 +#define CLK_TOP_UNIVPLL19 +#define CLK_TOP_UNIVPLL_D7 20 +#define CLK_TOP_UNIVPLL_D2621 +#define CLK_TOP_UNIVPLL_D5222 +#define CLK_TOP_UNIVPLL_D104 23 +#define CLK_TOP_UNIVPLL_D208 24 +#define CLK_TOP_UNIVPLL_D2 25 +#define CLK_TOP_UNIVPLL1_D226 +#define CLK_TOP_UNIVPLL1_D427 +#define CLK_TOP_UNIVPLL1_D828 +#define CLK_TOP_UNIVPLL_D3 29 +#define CLK_TOP_UNIVPLL2_D230 +#define CLK_TOP_UNIVPLL2_D431 +#define CLK_TOP_UNIVPLL2_D832 +#define CLK_TOP_UNIVPLL_D5 33 +#define CLK_TOP_UNIVPLL3_D234 +#define CLK_TOP_UNIVPLL3_D435 +#define CLK_TOP_UNIVPLL3_D836 +#define CLK_TOP_F_MP0_PLL1 37 +#define CLK_TOP_F_MP0_PLL2 38 +#define CLK_TOP_F_BIG_PLL1 39 +#define CLK_TOP_F_BIG_PLL2 40 +#define CLK_TOP_F_BUS_PLL1 41 +#define CLK_TOP_F_BUS_PLL2 42 +#define CLK_TOP_APLL1 43 +#define CLK_TOP_APLL1_D2 44 +#define CLK_TOP_APLL1_D4 45 +#define CLK_TOP_APLL1_D8 46 +#define CLK_TOP_APLL1_D16 47 +#define CLK_TOP_APLL2 48 +#define CLK_TOP_APLL2_D2 49 +#define CLK_TOP_APLL2_D4 50 +#define CLK_TOP_APLL2_D8 51 +#define CLK_TOP_APLL2_D16 52 +#define CLK_TOP_LVDSPLL53 +#define CLK_TOP_LVDSPLL_D2 54 +#define CLK_TOP_LVDSPLL_D4 55 +#define CLK_TOP_LVDSPLL_D8 56 +#define CLK_TOP_LVDSPLL2 57 +#define CLK_TOP_LVDSPLL2_D258 +#define CLK_TOP_LVDSPLL2_D459 +#define CLK_TOP_LVDSPLL2_D860 +#define CLK_TOP_ETHERPLL_125M 61 +#define CLK_TOP_ETHERPLL_50M 62 +#define CLK_TOP_CVBS 63 +#define CLK_TOP_CVBS_D264 +#define CLK_TOP_SYS_26M65 +#define CLK_TOP_MMPLL 66 +#define CLK_TOP_MMPLL_D2 67 +#define CLK_TOP_VENCPLL68 +#define CLK_TOP_VENCPLL_D2 69 +#define CLK_TOP_VCODECPLL 70 +#define CLK_TOP_VCODECPLL_D2 71 +#define CLK_TOP_TVDP
[PATCH v6 5/9] dt-bindings: soc: add MT2712 power dt-bindings
Add power dt-bindings for MT2712. Acked-by: Rob Herring Signed-off-by: Weiyi Lu --- .../devicetree/bindings/soc/mediatek/scpsys.txt| 3 +++ include/dt-bindings/power/mt2712-power.h | 26 ++ 2 files changed, 29 insertions(+) create mode 100644 include/dt-bindings/power/mt2712-power.h diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index 40056f7..76bf45b 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -12,11 +12,13 @@ power/power_domain.txt. It provides the power domains defined in - include/dt-bindings/power/mt8173-power.h - include/dt-bindings/power/mt6797-power.h - include/dt-bindings/power/mt2701-power.h +- include/dt-bindings/power/mt2712-power.h - include/dt-bindings/power/mt7622-power.h Required properties: - compatible: Should be one of: - "mediatek,mt2701-scpsys" + - "mediatek,mt2712-scpsys" - "mediatek,mt6797-scpsys" - "mediatek,mt7622-scpsys" - "mediatek,mt8173-scpsys" @@ -27,6 +29,7 @@ Required properties: These are clocks which hardware needs to be enabled before enabling certain power domains. Required clocks for MT2701: "mm", "mfg", "ethif" + Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec" Required clocks for MT6797: "mm", "mfg", "vdec" Required clocks for MT7622: "hif_sel" Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" diff --git a/include/dt-bindings/power/mt2712-power.h b/include/dt-bindings/power/mt2712-power.h new file mode 100644 index 000..92b46d7 --- /dev/null +++ b/include/dt-bindings/power/mt2712-power.h @@ -0,0 +1,26 @@ +/* + * Copyright (C) 2017 MediaTek Inc. + * + * 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 http://www.gnu.org/licenses/gpl-2.0.html for more details. + */ + +#ifndef _DT_BINDINGS_POWER_MT2712_POWER_H +#define _DT_BINDINGS_POWER_MT2712_POWER_H + +#define MT2712_POWER_DOMAIN_MM 0 +#define MT2712_POWER_DOMAIN_VDEC 1 +#define MT2712_POWER_DOMAIN_VENC 2 +#define MT2712_POWER_DOMAIN_ISP3 +#define MT2712_POWER_DOMAIN_AUDIO 4 +#define MT2712_POWER_DOMAIN_USB5 +#define MT2712_POWER_DOMAIN_USB2 6 +#define MT2712_POWER_DOMAIN_MFG7 + +#endif /* _DT_BINDINGS_POWER_MT2712_POWER_H */ -- 1.9.1
[PATCH v6 9/9] arm: dts: Add power controller device node of MT2712
add power controller node for MT2712
Signed-off-by: Weiyi Lu
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index d2ee3cd..fa87f92 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt2712";
@@ -147,6 +148,21 @@
#clock-cells = <1>;
};
+ scpsys: scpsys@10006000 {
+ compatible = "mediatek,mt2712-scpsys", "syscon";
+ #power-domain-cells = <1>;
+ reg = <0 0x10006000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>,
+<&topckgen CLK_TOP_MFG_SEL>,
+<&topckgen CLK_TOP_VENC_SEL>,
+<&topckgen CLK_TOP_JPGDEC_SEL>,
+<&topckgen CLK_TOP_A1SYS_HP_SEL>,
+<&topckgen CLK_TOP_VDEC_SEL>;
+ clock-names = "mm", "mfg", "venc",
+ "jpgdec", "audio", "vdec";
+ infracfg = <&infracfg>;
+ };
+
uart5: serial@1000f000 {
compatible = "mediatek,mt2712-uart",
"mediatek,mt6577-uart";
--
1.9.1
[PATCH v6 1/9] dt-bindings: ARM: Mediatek: Document bindings for MT2712
This patch adds the binding documentation for apmixedsys, bdpsys,
imgsys, imgsys, infracfg, mcucfg, mfgcfg, mmsys, pericfg, topckgen,
vdecsys and vencsys for Mediatek MT2712.
Acked-by: Rob Herring
Signed-off-by: Weiyi Lu
---
.../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,bdpsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,imgsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,infracfg.txt| 1 +
.../bindings/arm/mediatek/mediatek,jpgdecsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,mcucfg.txt | 22 ++
.../bindings/arm/mediatek/mediatek,mfgcfg.txt | 22 ++
.../bindings/arm/mediatek/mediatek,mmsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,pericfg.txt | 1 +
.../bindings/arm/mediatek/mediatek,topckgen.txt| 1 +
.../bindings/arm/mediatek/mediatek,vdecsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,vencsys.txt | 1 +
12 files changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index cd977db..19fc116 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
+ - "mediatek,mt2712-apmixedsys", "syscon"
- "mediatek,mt6797-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8173-apmixedsys"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
index 4137196..4010e37 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
@@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be:
- "mediatek,mt2701-bdpsys", "syscon"
+ - "mediatek,mt2712-bdpsys", "syscon"
- #clock-cells: Must be 1
The bdpsys controller uses the common clk binding from
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index 047b11a..868bd51 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
+ - "mediatek,mt2712-imgsys", "syscon"
- "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
- #clock-cells: Must be 1
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index 58d58e2..a3430cd 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
+ - "mediatek,mt2712-infracfg", "syscon"
- "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
new file mode 100644
index 000..2df799c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek jpgdecsys controller
+
+
+The Mediatek jpgdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt2712-jpgdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The jpgdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+jpgdecsys: syscon@1900 {
+ compatible = "mediatek,mt2712-jpgdecsys", "syscon";
+ reg = <0 0x1900 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
new file mode 100644
index 000..b8fb03f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
@@ -0,0 +1,22 @@
+Mediatek mcucfg controller
+==
[PATCH v6 0/9] Mediatek MT2712 clock and scpsys support
This series is based on v4.14-rc1 and composed of clock control (PATCH 1-4) and scpsys control (PATCH 5-9) changes since v5: - Refine bus protection with proper variable name and better implementation for the if statement. changes since v4: - Refine scpsys and infracfg for bus protection by passing a boolean flag to determine the register update method changes since v3: - Rebase to v4.14-rc1. changes since v2: - ensure the clocks used by clocksource driver are registered before clocksource init() by using CLK_OF_DECLARE() - correct the frequency of clk32k/clkrtc_ext/clkrtc_int changes since v1: - Rebase to v4.13-next-soc. - Refine scpsys and infracfg for bus protection. Weiyi Lu (9): dt-bindings: ARM: Mediatek: Document bindings for MT2712 clk: mediatek: Add dt-bindings for MT2712 clocks clk: mediatek: Add MT2712 clock support arm: dts: mt2712: Add clock controller device nodes dt-bindings: soc: add MT2712 power dt-bindings soc: mediatek: extend bus protection API soc: mediatek: add dependent clock jpgdec/audio for scpsys soc: mediatek: add MT2712 scpsys support arm: dts: Add power controller device node of MT2712 .../bindings/arm/mediatek/mediatek,apmixedsys.txt |1 + .../bindings/arm/mediatek/mediatek,bdpsys.txt |1 + .../bindings/arm/mediatek/mediatek,imgsys.txt |1 + .../bindings/arm/mediatek/mediatek,infracfg.txt|1 + .../bindings/arm/mediatek/mediatek,jpgdecsys.txt | 22 + .../bindings/arm/mediatek/mediatek,mcucfg.txt | 22 + .../bindings/arm/mediatek/mediatek,mfgcfg.txt | 22 + .../bindings/arm/mediatek/mediatek,mmsys.txt |1 + .../bindings/arm/mediatek/mediatek,pericfg.txt |1 + .../bindings/arm/mediatek/mediatek,topckgen.txt|1 + .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 + .../bindings/arm/mediatek/mediatek,vencsys.txt |1 + .../devicetree/bindings/soc/mediatek/scpsys.txt|3 + arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 131 ++ drivers/clk/mediatek/Kconfig | 50 + drivers/clk/mediatek/Makefile |8 + drivers/clk/mediatek/clk-mt2712-bdp.c | 102 ++ drivers/clk/mediatek/clk-mt2712-img.c | 80 ++ drivers/clk/mediatek/clk-mt2712-jpgdec.c | 76 ++ drivers/clk/mediatek/clk-mt2712-mfg.c | 75 + drivers/clk/mediatek/clk-mt2712-mm.c | 170 +++ drivers/clk/mediatek/clk-mt2712-vdec.c | 94 ++ drivers/clk/mediatek/clk-mt2712-venc.c | 77 ++ drivers/clk/mediatek/clk-mt2712.c | 1435 drivers/clk/mediatek/clk-mtk.h |2 + drivers/clk/mediatek/clk-pll.c | 13 +- drivers/soc/mediatek/mtk-infracfg.c| 26 +- drivers/soc/mediatek/mtk-scpsys.c | 140 +- include/dt-bindings/clock/mt2712-clk.h | 427 ++ include/dt-bindings/power/mt2712-power.h | 26 + include/linux/soc/mediatek/infracfg.h |7 +- 31 files changed, 2993 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt create mode 100644 drivers/clk/mediatek/clk-mt2712-bdp.c create mode 100644 drivers/clk/mediatek/clk-mt2712-img.c create mode 100644 drivers/clk/mediatek/clk-mt2712-jpgdec.c create mode 100644 drivers/clk/mediatek/clk-mt2712-mfg.c create mode 100644 drivers/clk/mediatek/clk-mt2712-mm.c create mode 100644 drivers/clk/mediatek/clk-mt2712-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt2712-venc.c create mode 100644 drivers/clk/mediatek/clk-mt2712.c create mode 100644 include/dt-bindings/clock/mt2712-clk.h create mode 100644 include/dt-bindings/power/mt2712-power.h
Re: [PATCH] printk: fix typo in printk_safe.c
On (10/22/17 22:30), Baoquan He wrote: > Signed-off-by: Baoquan He Reviewed-by: Sergey Senozhatsky -ss > --- > kernel/printk/printk_safe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c > index 3cdaeaef9ce1..89558b85f45c 100644 > --- a/kernel/printk/printk_safe.c > +++ b/kernel/printk/printk_safe.c > @@ -75,7 +75,7 @@ static void queue_flush_work(struct printk_safe_seq_buf *s) > * have dedicated buffers, because otherwise printk-safe preempted by > * NMI-printk would have overwritten the NMI messages. > * > - * The messages are fushed from irq work (or from panic()), possibly, > + * The messages are flushed from irq work (or from panic()), possibly, > * from other CPU, concurrently with printk_safe_log_store(). Should this > * happen, printk_safe_log_store() will notice the buffer->len mismatch > * and repeat the write. > -- > 2.5.5 >
PROBLEM: Kernel 4.13.8 hangs on boot (no output, log entries) on Surface Book
Hi lkml, Linux 4.13.8 hangs on boot very early, so no output or log entries and just a blank screen after bootloader, on Surface Book. https://bugzilla.kernel.org/show_bug.cgi?id=197359 A parallel bug report on Ubuntu suggests the problem starts at 4.13.0 and persists to 4.14.0. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1724657 Thanks, -Ben
[PATCH v2] ARM: Remove .pad section when CONFIG_EFI_STUB enabled
Currently we are using the .pad section to ensure the zImage file size
aligned to 8 bytes.
But that is not needed when CONFIG_EFI_STUB enabled, as it would
followed by a 512 bytes aligned .data section.
Signed-off-by: Jeffy Chen
---
Changes in v2:
Remove .pad section when CONFIG_EFI_STUB enabled as Russell King
suggested.
arch/arm/boot/compressed/vmlinux.lds.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..394b2bf5d28a 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
.got : { *(.got) }
_got_end = .;
- /* ensure the zImage file size is always a multiple of 64 bits */
- /* (without a dummy byte, ld just ignores the empty section) */
- .pad : { BYTE(0); . = ALIGN(8); }
-
#ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
__pecoff_data_start = .;
@@ -91,6 +87,10 @@ SECTIONS
. = ALIGN(512);
}
__pecoff_data_rawsize = . - ADDR(.data);
+#else
+ /* ensure the zImage file size is always a multiple of 64 bits */
+ /* (without a dummy byte, ld just ignores the empty section) */
+ .pad : { BYTE(0); . = ALIGN(8); }
#endif
_edata = .;
--
2.11.0
Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled
Hi Ard,
On 10/22/2017 09:01 PM, Ard Biesheuvel wrote:
On 22 October 2017 at 13:47, Russell King - ARM Linux
wrote:
On Sun, Oct 22, 2017 at 12:01:13PM +0100, Ard Biesheuvel wrote:
On 18 October 2017 at 06:01, Jeffy Chen wrote:
The zImage file size should be aligned.
Fixes: e4bae4d0b5f3 ("arm/efi: Split zImage code and data into separate PE/COFF
sections")
Signed-off-by: Jeffy Chen
---
arch/arm/boot/compressed/vmlinux.lds.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..1636fa259577 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
.got : { *(.got) }
_got_end = .;
- /* ensure the zImage file size is always a multiple of 64 bits */
- /* (without a dummy byte, ld just ignores the empty section) */
- .pad : { BYTE(0); . = ALIGN(8); }
-
#ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
__pecoff_data_start = .;
@@ -93,6 +89,10 @@ SECTIONS
__pecoff_data_rawsize = . - ADDR(.data);
#endif
+ /* ensure the zImage file size is always a multiple of 64 bits */
+ /* (without a dummy byte, ld just ignores the empty section) */
+ .pad : { BYTE(0); . = ALIGN(8); }
+
_edata = .;
_magic_sig = ZIMAGE_MAGIC(0x016f2818);
--
2.11.0
This is not the right fix. If CONFIG_EFI_STUB is enabled, the zImage
filesize should be rounded up to 512 bytes not 8 bytes. The '. =
ALIGN(512);' in the .data section appears to ensure that, but for some
reason, that appears not to be working.
Actually, the existing .pad section is totally and utterly bogus when
EFI is enabled:
. = ALIGN(4);
_etext = .;
.got.plt : { *(.got.plt) }
_got_start = .;
.got : { *(.got) }
_got_end = .;
The .got.plt and .got are always word-based. This is then followed by
.pad, which does nothing but pad out to a multiple of 64 bit:
/* ensure the zImage file size is always a multiple of 64 bits */
/* (without a dummy byte, ld just ignores the empty section) */
.pad : { BYTE(0); . = ALIGN(8); }
So this may add zero or 4 bytes of padding.
This is then followed by the EFI data:
.data : ALIGN(4096) {
...
. = ALIGN(512);
}
which is aligned to 4K but aligns the end of itself to 512.
So, we have the end of .got aligned to 4, followed by .pad that tries to
align to 8, followed by an optional .data section. This is pointless.
A sane patch would be to choose between the EFI .data section and the
.pad section. So, it should be:
#ifdef CONFIG_EFI_STUB
.data : ALIGN(4096) {
...
. = ALIGN(512);
}
#else
.pad : { BYTE(0); . = ALIGN(8); }
#endif
Agreed, the .pad section has no point for EFI_STUB=y. However, it
seems this symptom is caused by the same issues I am trying to address
here
https://marc.info/?l=linux-arm-kernel&m=150488477807353
which is that we have __ksymtab_xxx sections that we should discard,
because the linker will otherwise emit them /after/ .data or .pad.
This is caused by the use of lib/sort.c in the EFI stub, which
contains an EXPORT_SYMBOL().
hmm, right, didn't notice the data is already aligned...
so it's indeed caused by the ksym:
[ 9] .data PROGBITS006ce000 6d6000 000200 00 WA
0 0 4096
[10] ___ksymtab+sort PROGBITS006ce200 6d6200 08 00 WA
0 0 4
[11] .bss NOBITS 006ce208 6d6208 1c 00 WA
0 0 4
and both of your old([PATCH] ARM: compressed: discard ksym/kcrctab input
section) and new([PATCH] efi/libstub: arm: omit sorting of the UEFI
memory map) patches fix the issue i meet, thanks:)
Would you perhaps prefer that I clone sort.c into its own .c file
specifically for the EFI stub? (under drivers/firmware/efi/libstub)
That should get rid of these spurious sections and thus the
misalignments and/or movements that are causing all of these issues.
Re: linux-next: build failure after merge of the keystone tree
On 10/10/17 12:19 AM, Mark Brown wrote:
Hi Santosh,
After merging the keystone tree, today's linux-next build
(multi_v7_defconfig) failed like this:
DTC arch/arm/boot/dts/keystone-k2g-evm.dtb
Error: /home/broonie/tmpfs/next/arch/arm/boot/dts/keystone-k2g-evm.dts:150.1-15
syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:316: recipe for target
'arch/arm/boot/dts/keystone-k2g-evm.dtb' failed
make[2]: *** [arch/arm/boot/dts/keystone-k2g-evm.dtb] Error 1
Caused by commit
a6f244505915f ("ARM: dts: keystone-k2g-evm: Add I2C EEPROM DT entry")
I've used the keystone tree from yesterday.
I fixed this next day but forgot to reply to you Mark.
Regards,
Santosh
Re: [PATCH] mm/swap: Use page flags to determine LRU list in __activate_page()
On 10/19/2017 09:03 PM, Michal Hocko wrote: > On Thu 19-10-17 20:26:57, Anshuman Khandual wrote: >> Its already assumed that the PageActive flag is clear on the input >> page, hence page_lru(page) will pick the base LRU for the page. In >> the same way page_lru(page) will pick active base LRU, once the >> flag PageActive is set on the page. This change of LRU list should >> happen implicitly through the page flags instead of being hard >> coded. > > The patch description tells what but it doesn't explain _why_? Does the > resulting code is better, more optimized or is this a pure readability > thing? Not really. Not only it removes couple of lines of code but it also makes it look more logical from function flow point of view as well. > > All I can see is that page_lru is more complex and a large part of it > can be optimized away which has been done manually here. I suspect the > compiler can deduce the same thing. Why not ? I mean, that is the essence of the function page_lru() which should get us the exact LRU list the page should be on and hence we should not hand craft these manually.
[PATCH v5] of: dynamic: fix memory leak related to properties of __of_node_dup
If a node with no properties is dynamically added, then a property is
dynamically added to the node, then the property is dynamically removed,
the result will be node->properties == NULL and node->deadprops != NULL.
Add a separate function to release the properties in both lists.
Signed-off-by: Lixin Wang
---
v4 -> v5:
* fix the bug in v4, that the prop->next should be saved before release
the prop.
drivers/of/dynamic.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..39d69d3 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -315,6 +315,18 @@ int of_detach_node(struct device_node *np)
}
EXPORT_SYMBOL_GPL(of_detach_node);
+static void property_list_free(struct property *prop_list)
+{
+ struct property *prop, *next;
+
+ for (prop = prop_list; prop != NULL; prop = next) {
+ next = prop->next;
+ kfree(prop->name);
+ kfree(prop->value);
+ kfree(prop);
+ }
+}
+
/**
* of_node_release() - release a dynamically allocated node
* @kref: kref element of the node to be released
@@ -324,7 +336,6 @@ EXPORT_SYMBOL_GPL(of_detach_node);
void of_node_release(struct kobject *kobj)
{
struct device_node *node = kobj_to_device_node(kobj);
- struct property *prop = node->properties;
/* We should never be releasing nodes that haven't been detached. */
if (!of_node_check_flag(node, OF_DETACHED)) {
@@ -335,18 +346,9 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
- while (prop) {
- struct property *next = prop->next;
- kfree(prop->name);
- kfree(prop->value);
- kfree(prop);
- prop = next;
+ property_list_free(node->properties);
+ property_list_free(node->deadprops);
- if (!prop) {
- prop = node->deadprops;
- node->deadprops = NULL;
- }
- }
kfree(node->full_name);
kfree(node->data);
kfree(node);
--
2.6.2
Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS
On Fri, Oct 20, 2017 at 10:59:31PM +0300, Kirill A. Shutemov wrote: > With boot-time switching between paging mode we will have variable > MAX_PHYSMEM_BITS. > > Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y > configuration to define zsmalloc data structures. > > The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case. > It also suits well to handle PAE special case. > > Signed-off-by: Kirill A. Shutemov > Cc: Minchan Kim > Cc: Nitin Gupta > Cc: Sergey Senozhatsky Acked-by: Minchan Kim Nitin: I think this patch works and it would be best for Kirill to be able to do. So if you have better idea to clean it up, let's make it as another patch regardless of this patch series. Thanks.
Re: [RFC] mm/swap: Rename pagevec_lru_move_fn() as pagevec_lruvec_move_fn()
On 10/19/2017 08:59 PM, Michal Hocko wrote: > On Thu 19-10-17 14:03:14, Anshuman Khandual wrote: >> The function pagevec_lru_move_fn() actually moves pages from various >> per cpu pagevecs into per node lruvecs with a custom function which >> knows how to handle individual pages present in any given pagevec. >> Because it does movement between pagevecs and lruvecs as whole not >> to an individual list element, the name should reflect it. > I find the original name quite understandable (and shorter). I do not > think this is worth changing. It is just a code churn without a good > reason. > Sure, I understand.
Re: [PATCH V3] selftests/vm: Add tests validating mremap mirror functionality
On 10/20/2017 04:54 AM, Mike Kravetz wrote:
> On 10/17/2017 10:55 PM, Anshuman Khandual wrote:
>> This adds two tests to validate mirror functionality with mremap()
>> system call on shared and private anon mappings. After the commit
>> dba58d3b8c5 ("mm/mremap: fail map duplication attempts for private
>> mappings"), any attempt to mirror private anon mapping will fail.
>>
>> Suggested-by: Mike Kravetz
>> Signed-off-by: Anshuman Khandual
> The tests themselves look fine. However, they are pretty simple and
> could very easily be combined into one 'mremap_mirror.c' file. I
> would prefer that they be combined, but it is not a deal breaker.
>
> Reviewed-by: Mike Kravetz
>
Hello Andrew/Shuah,
Is this okay or should I resend this patch with both tests folded
into one test case file ?
- Anshuman
Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API
Hi all, On Fri, Oct 20, 2017 at 3:34 PM, Bjorn Andersson wrote: > On Fri 20 Oct 07:43 PDT 2017, Georgi Djakov wrote: > >> Hi, >> >> On 09/08/2017 08:18 PM, Georgi Djakov wrote: >> > This patch introduce a new API to get requirements and configure the >> > interconnect buses across the entire chipset to fit with the current >> > demand. >> > >> > The API is using a consumer/provider-based model, where the providers are >> > the interconnect buses and the consumers could be various drivers. >> > The consumers request interconnect resources (path) between endpoints and >> > set the desired constraints on this data flow path. The providers receive >> > requests from consumers and aggregate these requests for all master-slave >> > pairs on that path. Then the providers configure each participating in the >> > topology node according to the requested data flow path, physical links and >> > constraints. The topology could be complicated and multi-tiered and is SoC >> > specific. >> > >> > Signed-off-by: Georgi Djakov >> > --- >> > Documentation/interconnect/interconnect.rst | 93 +++ >> > drivers/Kconfig | 2 + >> > drivers/Makefile| 1 + >> > drivers/interconnect/Kconfig| 10 + >> > drivers/interconnect/Makefile | 1 + >> > drivers/interconnect/interconnect.c | 382 >> > >> > include/linux/interconnect-consumer.h | 73 ++ >> > include/linux/interconnect-provider.h | 119 + >> > 8 files changed, 681 insertions(+) >> > create mode 100644 Documentation/interconnect/interconnect.rst >> > create mode 100644 drivers/interconnect/Kconfig >> > create mode 100644 drivers/interconnect/Makefile >> > create mode 100644 drivers/interconnect/interconnect.c >> > create mode 100644 include/linux/interconnect-consumer.h >> > create mode 100644 include/linux/interconnect-provider.h >> >> Any comments on this patch? >> > > Sorry, I still haven't found the time to do a proper review of this yet. Same. > >> I am planning to change the prefix that is used for naming for example >> the functions from "interconnect_" to something shorter like icbus_. >> > > This isn't implementing a bus; if you feel that just ic_ is too short I > would suggest naming things inter_. (But keep the full name in the file > names) Not trying to bikeshed too much, but how about icc_ for "interconnect controller"? No idea if that is a hash collision with other in-kernel apis. Just "ic_" looks to me like "integrated circuit". Regards, Mike > > Regards, > Bjorn
Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance
On Fri, Oct 20, 2017 at 02:42:54PM +, alexander.stef...@infineon.com wrote:
> > The TPM burstcount status indicates the number of bytes that can
> > be sent to the TPM without causing bus wait states. Effectively,
> > it is the number of empty bytes in the command FIFO.
> >
> > This patch optimizes the tpm_tis_send_data() function by checking
> > the burstcount only once. And if the burstcount is valid, it writes
> > all the bytes at once, permitting wait state.
> >
> > After this change, performance on a TPM 1.2 with an 8 byte
> > burstcount for 1000 extends improved from ~41sec to ~14sec.
> >
> > Suggested-by: Ken Goldman in
> > conjunction with the TPM Device Driver work group.
> > Signed-off-by: Nayna Jain
> > Acked-by: Mimi Zohar
> > ---
> > drivers/char/tpm/tpm_tis_core.c | 42 +++--
> >
> > 1 file changed, 15 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > b/drivers/char/tpm/tpm_tis_core.c
> > index b33126a35694..993328ae988c 100644
> > --- a/drivers/char/tpm/tpm_tis_core.c
> > +++ b/drivers/char/tpm/tpm_tis_core.c
> > @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> > {
> > struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
> > int rc, status, burstcnt;
> > - size_t count = 0;
> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
> >
> > status = tpm_tis_status(chip);
> > @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> > }
> > }
> >
> > - while (count < len - 1) {
> > - burstcnt = get_burstcount(chip);
> > - if (burstcnt < 0) {
> > - dev_err(&chip->dev, "Unable to read burstcount\n");
> > - rc = burstcnt;
> > - goto out_err;
> > - }
> > - burstcnt = min_t(int, burstcnt, len - count - 1);
> > - rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv-
> > >locality),
> > -burstcnt, buf + count);
> > - if (rc < 0)
> > - goto out_err;
> > -
> > - count += burstcnt;
> > -
> > - if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip-
> > >timeout_c,
> > - &priv->int_queue, false) < 0) {
> > - rc = -ETIME;
> > - goto out_err;
> > - }
> > - status = tpm_tis_status(chip);
> > - if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
> > - rc = -EIO;
> > - goto out_err;
> > - }
> > + /*
> > +* Get the initial burstcount to ensure TPM is ready to
> > +* accept data.
> > +*/
> > + burstcnt = get_burstcount(chip);
> > + if (burstcnt < 0) {
> > + dev_err(&chip->dev, "Unable to read burstcount\n");
> > + rc = burstcnt;
> > + goto out_err;
> > }
> >
> > + rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality),
> > + len - 1, buf);
> > + if (rc < 0)
> > + goto out_err;
> > +
> > /* write last byte */
> > - rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality),
> > buf[count]);
> > + rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len-
> > 1]);
> > if (rc < 0)
> > goto out_err;
> >
> > --
> > 2.13.3
>
> This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying
> to send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests seem to take an unusual amount of time. More analysis probably
> has to wait until November, since I am going to be in Prague next
> week.
>
> Alexander
For the time being I'll drop this patch from the next branch and keep it
in the master branch.
/Jarkko
Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()
On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote: > I've always been curious, and the changelog and thread are curiously > oblique on this topic: what the heck does this driver use pipes *for*? For communication with the process hosting the launch enclave. /Jarkko
[tip:WIP.timers 28/37] htmldocs: include/linux/hrtimer.h:118: warning: No description found for parameter 'is_soft'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers head: 0f0f9ec319ea27dba44d16c643805821005f4955 commit: 7f6f735b72fb372668f6526167a7f6ae4b39ab87 [28/37] hrtimer: Implement support for softirq based hrtimers reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) kernel/trace/blktrace.c:824: warning: No description found for parameter 'cgid' >> include/linux/hrtimer.h:118: warning: No description found for parameter >> 'is_soft' include/linux/sync_file.h:51: warning: No description found for parameter 'flags' drivers/gpio/gpiolib.c:593: warning: No description found for parameter '16' drivers/gpio/gpiolib.c:593: warning: Excess struct/union/enum/typedef member 'events' description in 'lineevent_state' include/linux/usb/gadget.h:232: warning: No description found for parameter 'claimed' include/linux/usb/gadget.h:232: warning: No description found for parameter 'enabled' include/linux/usb/gadget.h:414: warning: No description found for parameter 'quirk_altset_not_supp' include/linux/usb/gadget.h:414: warning: No description found for parameter 'quirk_stall_not_supp' include/linux/usb/gadget.h:414: warning: No description found for parameter 'quirk_zlp_not_supp' fs/inode.c:1680: warning: No description found for parameter 'rcu' include/linux/jbd2.h:443: warning: No description found for parameter 'i_transaction' include/linux/jbd2.h:443: warning: No description found for parameter 'i_next_transaction' include/linux/jbd2.h:443: warning: No description found for parameter 'i_list' include/linux/jbd2.h:443: warning: No description found for parameter 'i_vfs_inode' include/linux/jbd2.h:443: warning: No description found for parameter 'i_flags' include/linux/jbd2.h:497: warning: No description found for parameter 'h_rsv_handle' include/linux/jbd2.h:497: warning: No description found for parameter 'h_reserved' include/linux/jbd2.h:497: warning: No description found for parameter 'h_type' include/linux/jbd2.h:497: warning: No description found for parameter 'h_line_no' include/linux/jbd2.h:497: warning: No description found for parameter 'h_start_jiffies' include/linux/jbd2.h:497: warning: No description found for parameter 'h_requested_credits' include/linux/jbd2.h:497: warning: No description found for parameter 'saved_alloc_context' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chkpt_bhs' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_devname' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_average_commit_time' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_min_batch_time' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_max_batch_time' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_commit_callback' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_failed_commit' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chksum_driver' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_csum_seed' fs/jbd2/transaction.c:511: warning: No description found for parameter 'type' fs/jbd2/transaction.c:511: warning: No description found for parameter 'line_no' fs/jbd2/transaction.c:641: warning: No description found for parameter 'gfp_mask' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_mode_config.h:771: warning: No description found for parameter 'modifiers_property' include/drm/drm_mode_config.h:771: warning: Excess struct/union/enum/typedef member 'modifiers' description in 'drm_mode_config' include/drm/drm_plane.h:544: warning: No description found for parameter 'modifiers' include/drm/drm_plane.h:544: warning: No description found for parameter 'modifier_count' drivers/gpu/host1x/bus.c:50: warning: No description found for parameter 'driver' include/linux/rcupdate.h:571: ERROR: Unexpected indentation. include/linux/rcupdate.h:575: ERROR: Unexpected indentation. include/l
Only for Business Expertise
My sincere apology if this email will cause any inconvenience. I have a proposal which I think might be of interest to you, I have a client who is searching for Good Business Owners that have got lucrative projects/business ideas he can invest his funds on. My client has great interest to invest in worthy creative start ups that has good potentials. He is not concerned about the type of project or the location of the investment rather his interest is that the Project should be one that will be able to yield a high return on investment. The investment range should be within the range of US$ One million-US$ Two Hundred million. His plan is to invest in a long term (maybe a period of 10 - 15 years) and after that, will withdraw his original capital and at the end of every financial year both of you will be sharing the interest generated on any percentage you both agree on. send me your Tel. Number or send mailto: i...@ibreach.org Regards Mr Eugen Hagler
Re: [PATCH v6 01/12] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings
Hi Rob & Ulf,
Gentle ping...
Any other comments about this series of patch ?
On Mon, 2017-10-16 at 09:46 +0800, Chaotian Jing wrote:
> Change the comptiable for support of multi-platform
> Make compatible explicit, as MMC host of mt8173 has difference with
> mt8135(mt8173 supports hs400 and hs400_tune),so that need separate
> mt8173/mt8135 compatible name.
> Add description for reg
> Add description for source_cg
> Add description for mediatek,latch-ck
> Note that source_cg and mediatek,latch-ck are optional for some projects,
> eg, MT2701 do not have source_cg, and MT2712 do not need
> mediatek,latch-ck
>
> Signed-off-by: Chaotian Jing
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 4182ea3..72d2a73 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -7,10 +7,18 @@ This file documents differences between the core properties
> in mmc.txt
> and the properties used by the msdc driver.
>
> Required properties:
> -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> +- compatible: value should be either of the following.
> + "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> + "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> + "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> + "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> +- reg: physical base address of the controller and length
> - interrupts: Should contain MSDC interrupt number
> -- clocks: MSDC source clock, HCLK
> -- clock-names: "source", "hclk"
> +- clocks: Should contain phandle for the clock feeding the MMC controller
> +- clock-names: Should contain the following:
> + "source" - source clock (required)
> + "hclk" - HCLK which used for host (required)
> + "source_cg" - independent source clock gate (required for MT2712)
> - pinctrl-names: should be "default", "state_uhs"
> - pinctrl-0: should contain default/high speed pin ctrl
> - pinctrl-1: should contain uhs mode pin ctrl
> @@ -30,6 +38,10 @@ Optional properties:
> - mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample
> selection
> If present,HS400 command responses are
> sampled on rising edges.
> If not present,HS400 command responses
> are sampled on falling edges.
> +- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct
> latch-ck to avoid data crc
> + error caused by stop clock(fifo full)
> + Valid range = [0:0x7]. if not present, default value is 0.
> + applied to compatible "mediatek,mt2701-mmc".
>
> Examples:
> mmc0: mmc@1123 {
Re: [15/23] drm/sun4i: Add LVDS support
Hi Maxime,
On 17 October 2017 at 20:06, Maxime Ripard
wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/Makefile | 1 +-
> drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
> drivers/gpu/drm/sun4i/sun4i_lvds.h | 18 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 25 -
> 5 files changed, 419 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index cfba2c07519c..6fee15d016ef 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -10,6 +10,7 @@ sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
>
> sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
> +sun4i-tcon-y += sun4i_lvds.o
> sun4i-tcon-y += sun4i_dotclock.o
> sun4i-tcon-y += sun4i_crtc.o
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> new file mode 100644
> index ..635a3f505ecb
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sun4i_crtc.h"
> +#include "sun4i_tcon.h"
> +#include "sun4i_lvds.h"
> +
> +struct sun4i_lvds {
> + struct drm_connectorconnector;
> + struct drm_encoder encoder;
> +
> + struct sun4i_tcon *tcon;
> +};
> +
> +static inline struct sun4i_lvds *
> +drm_connector_to_sun4i_lvds(struct drm_connector *connector)
> +{
> + return container_of(connector, struct sun4i_lvds,
> + connector);
> +}
> +
> +static inline struct sun4i_lvds *
> +drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
> +{
> + return container_of(encoder, struct sun4i_lvds,
> + encoder);
> +}
> +
> +static int sun4i_lvds_get_modes(struct drm_connector *connector)
> +{
> + struct sun4i_lvds *lvds =
> + drm_connector_to_sun4i_lvds(connector);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + return drm_panel_get_modes(tcon->panel);
> +}
> +
> +static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> + .get_modes = sun4i_lvds_get_modes,
> +};
> +
> +static void
> +sun4i_lvds_connector_destroy(struct drm_connector *connector)
> +{
> + struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + drm_panel_detach(tcon->panel);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy= sun4i_lvds_connector_destroy,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + DRM_DEBUG_DRIVER("Enabling LVDS output\n");
> +
> + if (!IS_ERR(tcon->panel)) {
> + drm_panel_prepare(tcon->panel);
> + drm_panel_enable(tcon->panel);
> + }
> +}
> +
> +static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + DRM_DEBUG_DRIVER("Disabling LVDS output\n");
> +
> + if (!IS_ERR(tcon->panel)) {
> + drm_panel_disable(tcon->panel);
> + drm_panel_unprepare(tcon->panel);
> + }
> +}
> +
> +static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
> + .disable= sun4i_lvds_encoder_disable,
> + .enable = sun4i_lvds_encoder_enable,
> +};
> +
> +static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
> + .destroy= drm_encoder_cleanup,
> +};
> +
> +int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
> +{
> +
RE: [of] c810c0a17e BUG: unable to handle kernel paging request at 6b6b6b6b
Hi Fengguang, Sorry for that bug. I had find the cause reason and I will send out new patch for this today. Thanks. Lixin -Original Message- From: Fengguang Wu [mailto:fengguang...@intel.com] Sent: Monday, October 23, 2017 2:29 AM To: Wang, Alan 1. (NSB - CN/Hangzhou) Cc: w...@linux.intel.com; Rob Herring ; Frank Rowand ; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; LKP Subject: [of] c810c0a17e BUG: unable to handle kernel paging request at 6b6b6b6b Hi Lixin, FYI, here is another bug triggered by https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next commit c810c0a17e019d1e4345bcbc49b6eddcf5dd001d Author: Lixin Wang AuthorDate: Fri Oct 20 09:59:09 2017 +0800 Commit: Rob Herring CommitDate: Fri Oct 20 10:27:33 2017 -0500 of: dynamic: fix memory leak related to properties of __of_node_dup If a node with no properties is dynamically added, then a property is dynamically added to the node, then the property is dynamically removed, the result will be node->properties == NULL and node->deadprops != NULL. Add a separate function to release the properties in both lists. Signed-off-by: Lixin Wang Reviewed-by: Frank Rowand Signed-off-by: Rob Herring 4ee7c0d964 of: overlay: make pr_err() string unique c810c0a17e of: dynamic: fix memory leak related to properties of __of_node_dup c810c0a17e of: dynamic: fix memory leak related to properties of __of_node_dup +-++++ | | | 4ee7c0d964 | c810c0a17e | c810c0a17e | +-++++ | boot_successes | 1 | 0 | 0 | | boot_failures | 47 | 15 | 15 | | es#_lib.c:#ess_reset_at#:failed | 37 | 15 | 15 | | WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 2 | 2 | 2 | | EIP:initialize_tlbstate_and_flush | 2 | 2 | 2 | | BUG:workqueue_lockup-pool | 10 | || | WARNING:kernel_stack| 1 | || | BUG:unable_to_handle_kernel | 0 | 15 | 15 | | Oops:#[##] | 0 | 15 | 15 | | EIP:property_list_free | 0 | 15 | 15 | | Kernel_panic-not_syncing:Fatal_exception| 0 | 15 | 15 | +-++++ [ 100.467439] OF: overlay: node_overlaps_later_cs: #6 overlaps with #7 @/testcase-data/overlay-node/test-bus/test-unittest8 [ 100.469350] OF: overlay: overlay #6 is not topmost [ 100.483290] BUG: unable to handle kernel paging request at 6b6b6b6b [ 100.484270] IP: property_list_free+0x8/0x6e [ 100.484895] *pde = [ 100.485329] Oops: [#1] SMP [ 100.485817] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc1-00047-gc810c0a #1 [ 100.486932] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 100.488085] task: 8f43c040 task.stack: 8f43e000 [ 100.488712] EIP: property_list_free+0x8/0x6e [ 100.489324] EFLAGS: 00210202 CPU: 0 [ 100.489847] EAX: 00200246 EBX: 6b6b6b6b ECX: 0004 EDX: 0007 [ 100.492481] ESI: 8dced700 EDI: 828ea738 EBP: 8f43fe08 ESP: 8f43fe04 [ 100.493433] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 100.494219] CR0: 80050033 CR2: 6b6b6b6b CR3: 02c1e000 CR4: 0690 [ 100.495122] Call Trace: [ 100.495498] of_node_release+0x7d/0xe9 [ 100.496066] kobject_put+0x132/0x19b [ 100.496586] of_node_put+0x2b/0x3b [ 100.497106] of_changeset_destroy+0x34/0x9a [ 100.497748] free_overlay_changeset+0x36/0xf1 [ 100.498360] of_overlay_remove+0x3d9/0x452 [ 100.498960] ? platform_device_put+0x2b/0x3b [ 100.499610] of_unittest_apply_revert_overlay_check+0x17b/0x297 [ 100.500665] of_unittest_overlay+0xc8a/0x1179 [ 100.501258] of_unittest+0xf74/0x1009 [ 100.501778] ? kobject_add+0x89/0x9d [ 100.502285] ? add_sysfs_fw_map_entry+0xa8/0xef [ 100.502986] ? of_unittest_overlay+0x1179/0x1179 [ 100.503672] do_one_initcall+0x10e/0x263 [ 100.504263] ? parse_args+0x23f/0x3bd [ 100.504883] ? kernel_init_freeable+0x222/0x3c6 [ 100.505613] kernel_init_freeable+0x24c/0x3c6 [ 100.506251] ? rest_init+0x43a/0x43a [ 100.506713] kernel_init+0x16/0x248 [ 100.507130] ret_from_fork+0x19/0x30 [ 100.507566] Code:
Re: [PATCH] isdn/gigaset: Provide cardstate context for bas timer callbacks
From: Kees Cook
Date: Fri, 20 Oct 2017 13:47:08 -0700
> While the work callback uses the urb to find cardstate from bas_cardstate,
> this may not be valid for timer callbacks. Instead, introduce a direct
> pointer back to the cardstate from bas_cardstate for use in timer
> callbacks.
>
> Reported-by: Paul Bolle
> Fixes: 4cfea08e6251 ("isdn/gigaset: Convert timers to use timer_setup()")
> Cc: Paul Bolle
> Cc: Karsten Keil
> Cc: "David S. Miller"
> Cc: Johan Hovold
> Cc: gigaset307x-com...@lists.sourceforge.net
> Cc: net...@vger.kernel.org
> Signed-off-by: Kees Cook
Applied to net-next.
Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map
On Sun, Oct 22, 2017 at 02:34:56PM +, Bart Van Assche wrote: > On Sat, 2017-10-21 at 11:23 +0900, Byungchul Park wrote: > > On Sat, Oct 21, 2017 at 4:58 AM, Bart Van Assche > > wrote: > > > As explained in another e-mail thread, unlike the lock inversion checking > > > performed by the <= v4.13 lockdep code, cross-release checking is a > > > heuristic > > > that does not have a sound theoretical basis. The lock validator is an > > > > It's not heuristic but based on the same theoretical basis as <=4.13 > > lockdep. I mean, the key basis is: > > > >1) What causes deadlock > >2) What is a dependency > >3) Build a dependency when identified > > Sorry but I doubt that that statement is correct. The publication [1] contains IMHO, the paper is talking about totally different things wrt deadlocks by wait_for_event/event, that is, lost events. Furthermore, it doesn't rely on dependencies itself, but just lock ordering 'case by case', which is a subset of the more general concept. > a proof that an algorithm that is closely related to the traditional lockdep > lock inversion detector is able to detect all deadlocks and does not report I can admit this. > false positives for programs that only use mutexes as synchronization objects. I want to ask you. What makes false positives avoidable in the paper? > The comment of the authors of that paper for programs that use mutexes, > condition variables and semaphores is as follows: "It is unclear how to extend > the lock-graph-based algorithm in Section 3 to efficiently consider the > effects > of condition variables and semaphores. Therefore, when considering all three > synchronization mechanisms, we currently use a naive algorithm that checks > each Right. The paper seems to use a naive algorigm for that cases, not replying on dependencies, which they should. > feasible permutation of the trace for deadlock." In other words, if you have > found an approach for detecting potential deadlocks for programs that use > these > three kinds of synchronization objects and that does not report false > positives > then that's a breakthrough that's worth publishing in a journal or in the > proceedings of a scientific conference. Please, point out logical problems of cross-release than saying it's impossbile according to the paper. I think you'd better understand how cross-release works *first*. I'll do my best to help you do. > Bart. > > [1] Agarwal, Rahul, and Scott D. Stoller. "Run-time detection of potential > deadlocks for programs with locks, semaphores, and condition variables." In > Proceedings of the 2006 workshop on Parallel and distributed systems: testing > and debugging, pp. 51-60. ACM, 2006. > (https://pdfs.semanticscholar.org/9324/fc0b5d5cd5e05d551a3e98757122039946a2.pdf).
Re: x86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
On 10/21/17 at 12:20am, Yinghai Lu wrote: > On Thu, Oct 19, 2017 at 10:52 PM, Dave Young wrote: > > Now crashkernel=X will fail if there's not enough memory at low region > > (below 896M) when trying to reserve large memory size. One can use > > crashkernel=xM,high to reserve it at high region (>4G) but it is more > > convinient to improve crashkernel=X to: > > > > - First try to reserve X below 896M (for being compatible with old > >kexec-tools). > > - If fails, try to reserve X below 4G (swiotlb need to stay below 4G). > > - If fails, try to reserve X from MAXMEM top down. > > > > It's more transparent and user-friendly. > > ok with me. Thank you! > > But looks like last time Vivek did not like this idea. >From the old discussion I remember Vivek was fine with this patch: https://lkml.org/lkml/2013/10/15/601 Thanks Dave
Re: [PATCH v4 2/2] dma: sprd: Add Spreadtrum DMA driver
Hi Vinod, On 10 October 2017 at 13:23, Baolin Wang wrote: > This patch adds the DMA controller driver for Spreadtrum SC9860 platform. > > Signed-off-by: Baolin Wang > --- > Changes since v3: > - Remove redundant local 'mask' and 'val' variables. > - Simplify sprd_dma_get_req_type() function. > - Change pm_runtime_put_sync() to pm_runtime_put() in probe function. > - Simplify sizeof function. > - Other coding style fixes. > > Changes since v2: > - Add COMPILE_TEST as dependency. > - Renamed DMA macro definition properly. > - Add sprd_dma_chn_update() helpers to save lots of code. > - Change pm_runtime_put_sync() to pm_runtime_put() when free resources. > - Re-implement the sprd_dma_tx_status() function. > - Free irq and kill tasklet when remove driver. > - Add some documentaion. > - Change to module_init() level and add MODULE_ALIAS(). > - Other coding style fixes. > > Changes since v1: > - Use virt-dma to manage dma descriptors. > - Remove link-list and channel-start-channel Spreadtrum special features. > - Remove device_config implementation. > - Other optimization. > > Note: This patch just implemented the basic DMA_MEMCPY function, and in > future we will send new patches to introduce some Speadtrum special features, > that will be talk about how to handle these features easily instead of in one > big patch which is hard to review. > --- Do you have any comments for this version patchset? If not, could you apply this patchset into your branch? Thanks. -- Baolin.wang Best Regards
Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem
Hi, On Thu, 2017-10-19 at 16:54 +0200, Philipp Zabel wrote: > Hi Laurent, > > On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote: > > Hi Philipp, > > > > On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote: > > > On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > > > > In theory the MMSYS device tree identifier is matches twice, by the clk > > > > driver and the DRM subsystem. But the kernel only matches the first > > > > driver for a device (clk) and discards the second one. This breaks > > > > graphics on mt8173 and most probably on mt2701 as well. > > > > > > > > MMSYS in Mediatek SoCs has some registers to control clock gates (which > > > > is > > > > used in the clk driver) and some registers to enable the differnet > > > > blocks > > > > of the display subsystem. The kernel uses the binding to load the > > > > central > > > > comoponent of the distplay subsystem, which in place probes all the > > > > other > > > > components and enables the present ones in the MMSYS. > > > > > > > > We found us with the problem, that we need to change and therefor break > > > > one > > > > of the two bindings, or the DRM one or the clock driver one. > > > > > > > > Apart from that the DRM subysystem does access the MMSYS registers via > > > > relaxed reads/writes. But the it should to so via regmap, as the > > > > registers are shared. > > > > > > > > Possible solutions: > > > > 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a > > > > simple-mfd under the actual mmsys node. We change the clock driver to > > > > probe on this binding. This would make sense as the clock gate register > > > > live completly in the MMSYS configuration registers. > > > > > > The reason why the drm driver matches against the mmsys node in the > > > first place is that we wanted to avoid 2). > > > > Why did you want to avoid 2) ? > > Because the "display-subsystem" node does not represent a real device, > it's just there to probe the driver that stitches all the DISP > components together. > > > > Also, mmsys is not a pure clock controller, as it also contains the > > > display path configuration in its register space. > > > > Which makes the mmsys related to display, but more in a syscon (combining > > clocks and routing, and I assume other miscellaneous features that wouldn't > > fit nicely in the other display-related IP cores) way than actually being > > part > > of the display subsystem. Or does mmsys only provide display-related > > features > > ? > > All devices in the 0x1400 - 0x14ff memory range are part of the > MMSYS system. That includes the MMSYS control or system configuration > block at 0x1400 - 0x14000fff as well as all the related MDP (media > data path) and DISP (display data path) blocks that follow. The DISP > blocks are purely display related, while the MDP blocks implement > implement mem2mem functions like scaling and conversion. > > > > > 2) As the nodes of the DRM subsystem just need some of the registers of > > > > MMSYS we add a new binding mediatek,mt8173-dispsys which probes the > > > > central component of the DRM system. It has only a handle to > > > > mt8173-mmsys > > > > to access the registerspace via regmap functions. > > > > > > > > In this patchset I implemented 2). Please take into account, that this > > > > is > > > > a RFC. I had no time to actually test the verison on real HW. Some of > > > > the > > > > register accesses should be done using regmap_update instead of > > > > regmap_read + regmap_write. > > > > > > > > This RFC shall only show how solution 2) would look like. We can use it > > > > as > > > > discussion to see how we circumvent the actual situation. > > > > > > Or we could leave the bindings untouched and create one platform device > > > from the other or even set up the clocks from the drm driver? > > > > Does mmsys provide features (such as clocks) to non-display IP cores ? > > The MMSYS control block provides clocks for the DISP (display data path) > and MDP (multimedia data path) blocks, as well as the routing between > them, but not to anything outside of the MMSYS system. According to register table of mediatek x20 mmsys [1] and Philipp's statement, I think mmsys is neither clock-controller nor display controller. It's a combination of multiple function. The four major function is display's clock-control, mdp's clock-control, display's routing, and mdp's routing. So we have two choice: 1) Centralize these multiple function control inside mmsys device: This means there is only a mmsys device which contains function of clock-control, display, and mdp. 2) Separate these multiple function to different device: mmsys is the major device which owns the register resource but does nothing. The function is controlled by three virtual device: mmsys-clock-controller, display-controller, and mdp-controller. I prefer 2) because these function seems independent. Regards, CK [1] https://www.96boards.o
Re: [RFC] HID: input: do not increment usages when a duplicate is found
A bit late, but this has bitten us again recently. below are two
typos/nitpicks comments
On Mon, Jun 19, 2017 at 11:55:13AM +0200, Benjamin Tissoires wrote:
> This is something that bothered us from a long time. When hid-input
'for a long time'
> doesn't know how to map a usage, it uses *_MISC. But there is something
> else which increments the usage if the evdev code is already used.
this sentence is a bit confusing, needs to be reworded.
Acked-by: Peter Hutterer
Cheers,
Peter
> This leads to few issues:
> - some devices may have their ABS_X mapped to ABS_Y if they export a bad
> set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
> HID driver)
> - *_MISC + N might (will) conflict with other defined axes (my Logitech
> H800 exports some multitouch axes because of that)
> - this prevents to freely add some new evdev usages, because "hey, my
> headset will now report ABS_COFFEE, and it's not coffee capable".
>
> So let's try to kill this nonsense, and hope we won't break too many
> devices.
>
> I my headset case, the ABS_MISC axes are created because of some
> proprietary usages, so we might not break that many devices.
>
> For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
> is created and can be applied to any device that needs this behavior.
>
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi,
>
> well, given I'd like to have a formal "go" before spending too much time
> in this, I am sending this a an RFC.
> This won't solve all the user space problems (especially the detection of
> non-mt devices based on ABS_MT_SLOT - 1 being set), but it should help us
> extending the other event types.
>
> Jiri, this patch applies on top of for-next + my series that creates
> HID_QUIRK_HAVE_SPECIAL_DRIVER, so do not expect it to apply cleanly on your
> tree :)
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-input.c | 33 +++--
> include/linux/hid.h | 2 ++
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index ccdff1e..9a9be89 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1025,8 +1025,31 @@ static void hidinput_configure_usage(struct hid_input
> *hidinput, struct hid_fiel
>
> set_bit(usage->type, input->evbit);
>
> - while (usage->code <= max && test_and_set_bit(usage->code, bit))
> - usage->code = find_next_zero_bit(bit, max + 1, usage->code);
> + /*
> + * This part is *really* controversial:
> + * - HID aims at being generic so we should do our best to export
> + * all incoming events
> + * - HID describes what events are, so there is no reason for ABS_X
> + * to be mapped to ABS_Y
> + * - HID is using *_MISC+N as a default value, but nothing prevents
> + * *_MISC+N to overwrite a legitimate even, which confuses userspace
> + * (for instance ABS_MISC + 7 is ABS_MT_SLOT, which has a different
> + * processing)
> + *
> + * If devices still want to use this (at their own risk), they will
> + * have to use the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE, but
> + * the default should be a reliable mapping.
> + */
> + while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
> + if (device->quirks & HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE) {
> + usage->code = find_next_zero_bit(bit,
> + max + 1,
> + usage->code);
> + } else {
> + device->status |= HID_STAT_DUP_DETECTED;
> + goto ignore;
> + }
> + }
>
> if (usage->code > max)
> goto ignore;
> @@ -1527,6 +1550,8 @@ int hidinput_connect(struct hid_device *hid, unsigned
> int force)
> INIT_LIST_HEAD(&hid->inputs);
> INIT_WORK(&hid->led_work, hidinput_led_worker);
>
> + hid->status &= ~HID_STAT_DUP_DETECTED;
> +
> if (!force) {
> for (i = 0; i < hid->maxcollection; i++) {
> struct hid_collection *col = &hid->collection[i];
> @@ -1593,6 +1618,10 @@ int hidinput_connect(struct hid_device *hid, unsigned
> int force)
> goto out_unwind;
> }
>
> + if (hid->status & HID_STAT_DUP_DETECTED)
> + hid_info(hid,
> + "Some usages could not be mapped, please use
> HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE if this is legitimate.\n");
> +
> return 0;
>
> out_unwind:
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 7a473bf..245d1ac 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -340,6 +340,7 @@ struct hid_item {
> #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x0002
> #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x0004
> #define HID_QUIRK_HAVE_SPECIAL_DRIVER
Re: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
Quoting David Miller : From: "Gustavo A. R. Silva" Date: Sun, 22 Oct 2017 20:08:40 -0500 Code refactoring in order to make it easier to read and maintain. Signed-off-by: Gustavo A. R. Silva Gustavo, always when reposting a new version of a patch that is part of a series you must _always_ repost the entire patch series. OK. I got it. Also, a proper patch series must begine with a "[PATCH 0/2] ..." header posting explaining at a high level what the patch series is doing, how it is doing it, and why it is doing it that way. Yeah, in this case I thought there was no need for this as both patches are not actually related in terms of functionality. But now that I'm writing this, maybe that is precisely the reason why I should have posted such header...? Thanks -- Gustavo A. R. Silva
[PATCH v5 0/7] PM / devfreq: Use OPP interface to handle the frequency
These patches makes the devfreq to use the OPP interface and clean-up codes.
[Detaild Descripion]
The commit a76caf55e5b3 ("thermal: Add devfreq cooling") provides
the devfreq cooling device by using the OPP interface such as
dev_pm_opp_disable() and dev_pm_opp_enable(). It means that
the OPP interface is able to change the available status of the frequency.
Firstly, the existing devfreq doesn't reflect the result of OPP behavior
when showing the min/max frequency through the following sysfs nodes:
It shows the wrong frequency value because min_freq/max_freq don't
consider the frequency status by handling OPP interface (opp_dev_pm_opp_
{disable|add}()). So, these patches fix this issue.
- /sys/class/devfreq/devfreqX/min_freq
- /sys/class/devfreq/devfreqX/max_freq
Second, the 'available_frequencies' should show the all supported frequencies
even if the specific frequency is not available. It doesn't matter whether
frequneyc is available or not. Because the role of 'available_frequencies'
shows the all frequencies. Also, these patches fix this issue.
- /sys/class/devfreq/devfreqX/available_frequencies
Third, update_devfreq() get the available next frequency by using
new 'scaling_min/max_frewq' variables in order to consider the disabled OPP.
For example,
- devfreq's min_freq is 100Mhz and max_freq is 700Mhz.
- OPP disabled 500/600/700Mhz due to devfreq-cooling.c.
- simple_ondemand govenor decided the next target_freq (600Mhz)
|--|-|
|Freq(MHz) |100 |200|300|400 |500 |600 |70 0|
|Devfreq |min_freq| | ||| |max_freq|
|OPP avail |enabled |enabled|enabled|enabled |Disabled| Disabled|Disabled|
|Ondmenad || | |||next_freq||
||
In result,
- Before this patch, target_freq is 600Mhz
and TRANSITION_NOTIFIER sends the next_freq is 600Mhz to the notifiee.
- After this patch, target_freq is 400Mhz because 500/600 were disabled by OPP.
and TRANSITION_NOTIFIER sends the next_freq is 400Mhz to the notifiee.
Lastly,
- patch6/7 fix the minor issue and cleanup codes.
Changes from v4:
(https://lkml.org/lkml/2017/10/13/78)
- Add acked-by tag from Myungjoo Ham on patch4/5/6/7.
- Fix the typo and bug of min/max_freq_show() on patch3.
- Drop the exynos-bus.c patch for using it as a cooling device.
Changes from v3:
- Add the new 'scaling_min/max_freq' to 'struct devfreq'
in order to reflect the OPP behavior such as dev_pm_opp_disable/enable().
- Drop the call of devfreq_recommended_opp() in the update_devfreq().
- Show the available frequencies in an ascending order.
- Check '#cooling-cells' property before registering cooling device on
exynos-bus.c.
- Change the return type of devfreq_set_freq_table() and remvoe 'devfreq'
prefix from function name.
- Add acked-by tag from Myungjoo Ham on patch1.
Changes from v2:
(https://lkml.org/lkml/2017/9/20/886)
- Fix the exynos-bus.c for the cooling device on patch8
Changes from v1:
(https://lkml.org/lkml/2017/8/23/785)
- Show the available frequencies as an ascending order
- Change the author info from cwcho...@gmail.com to cw00.c...@samsung.com
- Drop the patches related to opp_notifier
- Add new patch5/6/7/8
Chanwoo Choi (7):
PM / devfreq: Set min/max_freq when adding the devfreq device
Revert "PM / devfreq: Add show_one macro to delete the duplicate code"
PM / devfreq: Use the available min/max frequency
PM / devfreq: Change return type of devfreq_set_freq_table()
PM / devfreq: Show the all available frequencies
PM / devfreq: Remove unneeded conditional statement
PM / devfreq: Define the constant governor name
drivers/devfreq/devfreq.c | 139 +-
drivers/devfreq/exynos-bus.c | 5 +-
drivers/devfreq/governor_passive.c| 2 +-
drivers/devfreq/governor_performance.c| 2 +-
drivers/devfreq/governor_powersave.c | 2 +-
drivers/devfreq/governor_simpleondemand.c | 2 +-
drivers/devfreq/governor_userspace.c | 2 +-
drivers/devfreq/rk3399_dmc.c | 2 +-
include/linux/devfreq.h | 16 +++-
9 files changed, 123 insertions(+), 49 deletions(-)
--
1.9.1
[PATCH v5 3/7] PM / devfreq: Use the available min/max frequency
The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able
to disable OPP as a cooling device. In result, both update_devfreq()
and {min|max}_freq_show() have to consider the 'opp->available'
status of each OPP.
So, this patch adds the 'scaling_{min|max}_freq' to struct devfreq
in order to indicate the available mininum and maximum frequency
by adjusting OPP interface such as dev_pm_opp_{disable|enable}().
The 'scaling_{min|max}_freq' are used for on both update_devfreq()
and {min|max}_freq_show().
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/devfreq.c | 40
include/linux/devfreq.h | 4
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index b6ba24e5db0d..ee3e7cee30b6 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -28,6 +28,9 @@
#include
#include "governor.h"
+#define MAX(a,b) ((a > b) ? a : b)
+#define MIN(a,b) ((a < b) ? a : b)
+
static struct class *devfreq_class;
/*
@@ -255,7 +258,7 @@ static int devfreq_notify_transition(struct devfreq
*devfreq,
int update_devfreq(struct devfreq *devfreq)
{
struct devfreq_freqs freqs;
- unsigned long freq, cur_freq;
+ unsigned long freq, cur_freq, min_freq, max_freq;
int err = 0;
u32 flags = 0;
@@ -273,19 +276,21 @@ int update_devfreq(struct devfreq *devfreq)
return err;
/*
-* Adjust the frequency with user freq and QoS.
+* Adjust the frequency with user freq, QoS and available freq.
*
* List from the highest priority
* max_freq
* min_freq
*/
+ max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
+ min_freq = MAX(devfreq->scaling_min_freq, devfreq->min_freq);
- if (devfreq->min_freq && freq < devfreq->min_freq) {
- freq = devfreq->min_freq;
+ if (min_freq && freq < min_freq) {
+ freq = min_freq;
flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
}
- if (devfreq->max_freq && freq > devfreq->max_freq) {
- freq = devfreq->max_freq;
+ if (max_freq && freq > max_freq) {
+ freq = max_freq;
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
@@ -494,6 +499,19 @@ static int devfreq_notifier_call(struct notifier_block
*nb, unsigned long type,
int ret;
mutex_lock(&devfreq->lock);
+
+ devfreq->scaling_min_freq = find_available_min_freq(devfreq);
+ if (!devfreq->scaling_min_freq) {
+ mutex_unlock(&devfreq->lock);
+ return -EINVAL;
+ }
+
+ devfreq->scaling_max_freq = find_available_max_freq(devfreq);
+ if (!devfreq->scaling_max_freq) {
+ mutex_unlock(&devfreq->lock);
+ return -EINVAL;
+ }
+
ret = update_devfreq(devfreq);
mutex_unlock(&devfreq->lock);
@@ -593,6 +611,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = -EINVAL;
goto err_dev;
}
+ devfreq->scaling_min_freq = devfreq->min_freq;
devfreq->max_freq = find_available_max_freq(devfreq);
if (!devfreq->max_freq) {
@@ -600,6 +619,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = -EINVAL;
goto err_dev;
}
+ devfreq->scaling_max_freq = devfreq->max_freq;
dev_set_name(&devfreq->dev, "devfreq%d",
atomic_inc_return(&devfreq_no));
@@ -1127,7 +1147,9 @@ static ssize_t min_freq_store(struct device *dev, struct
device_attribute *attr,
static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
- return sprintf(buf, "%lu\n", to_devfreq(dev)->min_freq);
+ struct devfreq *df = to_devfreq(dev);
+
+ return sprintf(buf, "%lu\n", MAX(df->scaling_min_freq, df->min_freq));
}
static ssize_t max_freq_store(struct device *dev, struct device_attribute
*attr,
@@ -1161,7 +1183,9 @@ static ssize_t max_freq_store(struct device *dev, struct
device_attribute *attr,
static ssize_t max_freq_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
- return sprintf(buf, "%lu\n", to_devfreq(dev)->max_freq);
+ struct devfreq *df = to_devfreq(dev);
+
+ return sprintf(buf, "%lu\n", MIN(df->scaling_max_freq, df->max_freq));
}
static DEVICE_ATTR_RW(max_freq);
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 597294e0cc40..997a9eb34191 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -120,6 +120,8 @@ struct devfreq_dev_profile {
* touch this.
* @min_freq: Limit minimum frequency requested by user (0: none)
* @max_freq: Limit maximum frequency requested by user (0: none)
+ * @scaling_min_freq:
[PATCH v5 1/7] PM / devfreq: Set min/max_freq when adding the devfreq device
Prior to that, the min/max_freq of the devfreq device are always zero
before the user changes the min/max_freq through sysfs entries.
It might make the confusion for the min/max_freq.
This patch initializes the available min/max_freq by using the OPP
during adding the devfreq device.
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
drivers/devfreq/devfreq.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index a1c4ee818614..6a6f88bccdee 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -69,6 +69,34 @@ static struct devfreq *find_device_devfreq(struct device
*dev)
return ERR_PTR(-ENODEV);
}
+static unsigned long find_available_min_freq(struct devfreq *devfreq)
+{
+ struct dev_pm_opp *opp;
+ unsigned long min_freq = 0;
+
+ opp = dev_pm_opp_find_freq_ceil(devfreq->dev.parent, &min_freq);
+ if (IS_ERR(opp))
+ min_freq = 0;
+ else
+ dev_pm_opp_put(opp);
+
+ return min_freq;
+}
+
+static unsigned long find_available_max_freq(struct devfreq *devfreq)
+{
+ struct dev_pm_opp *opp;
+ unsigned long max_freq = ULONG_MAX;
+
+ opp = dev_pm_opp_find_freq_floor(devfreq->dev.parent, &max_freq);
+ if (IS_ERR(opp))
+ max_freq = 0;
+ else
+ dev_pm_opp_put(opp);
+
+ return max_freq;
+}
+
/**
* devfreq_get_freq_level() - Lookup freq_table for the frequency
* @devfreq: the devfreq instance
@@ -559,6 +587,20 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_lock(&devfreq->lock);
}
+ devfreq->min_freq = find_available_min_freq(devfreq);
+ if (!devfreq->min_freq) {
+ mutex_unlock(&devfreq->lock);
+ err = -EINVAL;
+ goto err_dev;
+ }
+
+ devfreq->max_freq = find_available_max_freq(devfreq);
+ if (!devfreq->max_freq) {
+ mutex_unlock(&devfreq->lock);
+ err = -EINVAL;
+ goto err_dev;
+ }
+
dev_set_name(&devfreq->dev, "devfreq%d",
atomic_inc_return(&devfreq_no));
err = device_register(&devfreq->dev);
--
1.9.1
[PATCH v5 2/7] Revert "PM / devfreq: Add show_one macro to delete the duplicate code"
This reverts commit 3104fa3081126c9bda35793af5f335d0ee0d5818.
The {min|max}_freq_show() show the stored value of the struct devfreq.
But, if the drivers/thermal/devfreq_cooling.c disables the specific
frequency value, {min|max}_freq_show() have to check this situation
before showing the stored value. So, this patch revert the macro
in order to add the additional codes.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/devfreq.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 6a6f88bccdee..b6ba24e5db0d 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1124,6 +1124,12 @@ static ssize_t min_freq_store(struct device *dev, struct
device_attribute *attr,
return ret;
}
+static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ return sprintf(buf, "%lu\n", to_devfreq(dev)->min_freq);
+}
+
static ssize_t max_freq_store(struct device *dev, struct device_attribute
*attr,
const char *buf, size_t count)
{
@@ -1150,17 +1156,13 @@ static ssize_t max_freq_store(struct device *dev,
struct device_attribute *attr,
mutex_unlock(&df->lock);
return ret;
}
+static DEVICE_ATTR_RW(min_freq);
-#define show_one(name) \
-static ssize_t name##_show \
-(struct device *dev, struct device_attribute *attr, char *buf) \
-{ \
- return sprintf(buf, "%lu\n", to_devfreq(dev)->name);\
+static ssize_t max_freq_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ return sprintf(buf, "%lu\n", to_devfreq(dev)->max_freq);
}
-show_one(min_freq);
-show_one(max_freq);
-
-static DEVICE_ATTR_RW(min_freq);
static DEVICE_ATTR_RW(max_freq);
static ssize_t available_frequencies_show(struct device *d,
--
1.9.1
Re: [Question] null pointer risk of kernel workqueue
on 2017/10/21 23:35, Tejun Heo wrote:
> On Fri, Oct 20, 2017 at 02:57:18PM +0800, tanxiaofei wrote:
>> Hi Tejun,
>>
>> Any comments about this?
>
> I think you're confused, or at least can't understand what you're
> trying to say. Can you create a rero?
>
Hi Tejun,
The case is as following:
worker_thread()
|-spin_lock_irq()
|-process_one_work()
|-worker->current_pwq = pwq
|-spin_unlock_irq()
|-worker->current_func(work)
|-spin_lock_irq()
|-worker->current_pwq = NULL
|-spin_unlock_irq()
//interrupt
here
|-irq_handler
|-__queue_work()
//assuming that the wq is draining
|-if (unlikely(wq->flags & __WQ_DRAINING) &&WARN_ON_ONCE(!is_chained_work(wq)))
|-is_chained_work(wq)
|-current_wq_worker() // Here, 'current' is the interrupted worker!
|-current->current_pwq is NULL here!
|-schedule()
And I think the following patch can solve the bug, right?
diff --git a/kernel/workqueue_internal.h b/kernel/workqueue_internal.h
index 8635417..650680c 100644
--- a/kernel/workqueue_internal.h
+++ b/kernel/workqueue_internal.h
@@ -59,7 +59,7 @@ struct worker {
*/
static inline struct worker *current_wq_worker(void)
{
- if (current->flags & PF_WQ_WORKER)
+ if (!in_irq() && (current->flags & PF_WQ_WORKER))
return kthread_data(current);
return NULL;
}
Thanks,
Li Bin
> Thanks.
>
[PATCH v5 5/7] PM / devfreq: Show the all available frequencies
The commit a76caf55e5b35 ("thermal: Add devfreq cooling") allows
the devfreq device to use the cooling device. When the cooling down
are required, the devfreq_cooling.c disables the OPP entry with
the dev_pm_opp_disable(). In result, 'available_frequencies'[1]
sysfs node never came to show the all available frequencies.
[1] /sys/class/devfreq/.../available_frequencies
So, this patch uses the 'freq_table' in the 'struct devfreq_dev_profile'
in order to show the all available frequencies.
- If 'freq_table' is NULL, devfreq core initializes them by using OPP values.
- If 'freq_table' is initialized, devfreq core just uses the 'freq_table'.
And this patch adds some comment about the sort way of 'freq_table'.
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
drivers/devfreq/devfreq.c | 16 +---
include/linux/devfreq.h | 5 +++--
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index b2920cd2b78e..381f92e5e794 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1194,22 +1194,16 @@ static ssize_t available_frequencies_show(struct device
*d,
char *buf)
{
struct devfreq *df = to_devfreq(d);
- struct device *dev = df->dev.parent;
- struct dev_pm_opp *opp;
ssize_t count = 0;
- unsigned long freq = 0;
+ int i;
- do {
- opp = dev_pm_opp_find_freq_ceil(dev, &freq);
- if (IS_ERR(opp))
- break;
+ mutex_lock(&df->lock);
- dev_pm_opp_put(opp);
+ for (i = 0; i < df->profile->max_state; i++)
count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
- "%lu ", freq);
- freq++;
- } while (1);
+ "%lu ", df->profile->freq_table[i]);
+ mutex_unlock(&df->lock);
/* Truncate the trailing space */
if (count)
count--;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 997a9eb34191..19520625ea94 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -84,8 +84,9 @@ struct devfreq_dev_status {
* from devfreq_remove_device() call. If the user
* has registered devfreq->nb at a notifier-head,
* this is the time to unregister it.
- * @freq_table:Optional list of frequencies to support statistics.
- * @max_state: The size of freq_table.
+ * @freq_table:Optional list of frequencies to support
statistics
+ * and freq_table must be generated in ascending order.
+ * @max_state: The size of freq_table.
*/
struct devfreq_dev_profile {
unsigned long initial_freq;
--
1.9.1
[PATCH v5 7/7] PM / devfreq: Define the constant governor name
Prior to that, the devfreq device uses the governor name when adding
the itself. In order to prevent the mistake used the wrong governor name,
this patch defines the governor name as a constant and then uses them
instead of using the string directly.
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/devfreq/exynos-bus.c | 5 +++--
drivers/devfreq/governor_passive.c| 2 +-
drivers/devfreq/governor_performance.c| 2 +-
drivers/devfreq/governor_powersave.c | 2 +-
drivers/devfreq/governor_simpleondemand.c | 2 +-
drivers/devfreq/governor_userspace.c | 2 +-
drivers/devfreq/rk3399_dmc.c | 2 +-
include/linux/devfreq.h | 7 +++
8 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 49f68929e024..c25658b26598 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -436,7 +436,8 @@ static int exynos_bus_probe(struct platform_device *pdev)
ondemand_data->downdifferential = 5;
/* Add devfreq device to monitor and handle the exynos bus */
- bus->devfreq = devm_devfreq_add_device(dev, profile, "simple_ondemand",
+ bus->devfreq = devm_devfreq_add_device(dev, profile,
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
ondemand_data);
if (IS_ERR(bus->devfreq)) {
dev_err(dev, "failed to add devfreq device\n");
@@ -488,7 +489,7 @@ static int exynos_bus_probe(struct platform_device *pdev)
passive_data->parent = parent_devfreq;
/* Add devfreq device for exynos bus with passive governor */
- bus->devfreq = devm_devfreq_add_device(dev, profile, "passive",
+ bus->devfreq = devm_devfreq_add_device(dev, profile,
DEVFREQ_GOV_PASSIVE,
passive_data);
if (IS_ERR(bus->devfreq)) {
dev_err(dev,
diff --git a/drivers/devfreq/governor_passive.c
b/drivers/devfreq/governor_passive.c
index 673ad8cc9a1d..3bc29acbd54e 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -183,7 +183,7 @@ static int devfreq_passive_event_handler(struct devfreq
*devfreq,
}
static struct devfreq_governor devfreq_passive = {
- .name = "passive",
+ .name = DEVFREQ_GOV_PASSIVE,
.immutable = 1,
.get_target_freq = devfreq_passive_get_target_freq,
.event_handler = devfreq_passive_event_handler,
diff --git a/drivers/devfreq/governor_performance.c
b/drivers/devfreq/governor_performance.c
index c72f942f30a8..4d23ecfbd948 100644
--- a/drivers/devfreq/governor_performance.c
+++ b/drivers/devfreq/governor_performance.c
@@ -42,7 +42,7 @@ static int devfreq_performance_handler(struct devfreq
*devfreq,
}
static struct devfreq_governor devfreq_performance = {
- .name = "performance",
+ .name = DEVFREQ_GOV_PERFORMANCE,
.get_target_freq = devfreq_performance_func,
.event_handler = devfreq_performance_handler,
};
diff --git a/drivers/devfreq/governor_powersave.c
b/drivers/devfreq/governor_powersave.c
index 0c6bed567e6d..0c42f23249ef 100644
--- a/drivers/devfreq/governor_powersave.c
+++ b/drivers/devfreq/governor_powersave.c
@@ -39,7 +39,7 @@ static int devfreq_powersave_handler(struct devfreq *devfreq,
}
static struct devfreq_governor devfreq_powersave = {
- .name = "powersave",
+ .name = DEVFREQ_GOV_POWERSAVE,
.get_target_freq = devfreq_powersave_func,
.event_handler = devfreq_powersave_handler,
};
diff --git a/drivers/devfreq/governor_simpleondemand.c
b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5e78df..28e0f2de7100 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -125,7 +125,7 @@ static int devfreq_simple_ondemand_handler(struct devfreq
*devfreq,
}
static struct devfreq_governor devfreq_simple_ondemand = {
- .name = "simple_ondemand",
+ .name = DEVFREQ_GOV_SIMPLE_ONDEMAND,
.get_target_freq = devfreq_simple_ondemand_func,
.event_handler = devfreq_simple_ondemand_handler,
};
diff --git a/drivers/devfreq/governor_userspace.c
b/drivers/devfreq/governor_userspace.c
index 77028c27593c..080607c3f34d 100644
--- a/drivers/devfreq/governor_userspace.c
+++ b/drivers/devfreq/governor_userspace.c
@@ -87,7 +87,7 @@ static ssize_t show_freq(struct device *dev, struct
device_attribute *attr,
NULL,
};
static const struct attribute_group dev_attr_group = {
- .name = "userspace",
+ .name = DEVFREQ_GOV_USERSPACE,
.attrs = dev_entries,
};
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 1b89ebbad02c..5dfbfa3cc878 100644
---
[PATCH v5 4/7] PM / devfreq: Change return type of devfreq_set_freq_table()
This patch changes the return type of devfreq_set_freq_table()
from 'void' to 'int' in order to check whether it fails or not.
And This patch just removes the 'devfreq' prefix and the description
of function. Because the helper functions are only used by the devfreq.
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
drivers/devfreq/devfreq.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index ee3e7cee30b6..b2920cd2b78e 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -116,11 +116,7 @@ static int devfreq_get_freq_level(struct devfreq *devfreq,
unsigned long freq)
return -EINVAL;
}
-/**
- * devfreq_set_freq_table() - Initialize freq_table for the frequency
- * @devfreq: the devfreq instance
- */
-static void devfreq_set_freq_table(struct devfreq *devfreq)
+static int set_freq_table(struct devfreq *devfreq)
{
struct devfreq_dev_profile *profile = devfreq->profile;
struct dev_pm_opp *opp;
@@ -130,7 +126,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
/* Initialize the freq_table from OPP table */
count = dev_pm_opp_get_opp_count(devfreq->dev.parent);
if (count <= 0)
- return;
+ return -EINVAL;
profile->max_state = count;
profile->freq_table = devm_kcalloc(devfreq->dev.parent,
@@ -139,7 +135,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
GFP_KERNEL);
if (!profile->freq_table) {
profile->max_state = 0;
- return;
+ return -ENOMEM;
}
for (i = 0, freq = 0; i < profile->max_state; i++, freq++) {
@@ -147,11 +143,13 @@ static void devfreq_set_freq_table(struct devfreq
*devfreq)
if (IS_ERR(opp)) {
devm_kfree(devfreq->dev.parent, profile->freq_table);
profile->max_state = 0;
- return;
+ return PTR_ERR(opp);
}
dev_pm_opp_put(opp);
profile->freq_table[i] = freq;
}
+
+ return 0;
}
/**
@@ -601,7 +599,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
- devfreq_set_freq_table(devfreq);
+ err = set_freq_table(devfreq);
+ if (err < 0)
+ goto err_out;
mutex_lock(&devfreq->lock);
}
--
1.9.1
[PATCH v5 6/7] PM / devfreq: Remove unneeded conditional statement
The freq_table array of each devfreq device is always not NULL. In result, it is unneeded to check whether profile->freq_table is NULL or not. Signed-off-by: Chanwoo Choi Acked-by: MyungJoo Ham --- drivers/devfreq/devfreq.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 381f92e5e794..78fb496ecb4e 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -311,10 +311,9 @@ int update_devfreq(struct devfreq *devfreq) freqs.new = freq; devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE); - if (devfreq->profile->freq_table) - if (devfreq_update_status(devfreq, freq)) - dev_err(&devfreq->dev, - "Couldn't update frequency transition information.\n"); + if (devfreq_update_status(devfreq, freq)) + dev_err(&devfreq->dev, + "Couldn't update frequency transition information.\n"); devfreq->previous_freq = freq; return err; -- 1.9.1
Re: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
From: "Gustavo A. R. Silva" Date: Sun, 22 Oct 2017 20:08:40 -0500 > Code refactoring in order to make it easier to read and maintain. > > Signed-off-by: Gustavo A. R. Silva Gustavo, always when reposting a new version of a patch that is part of a series you must _always_ repost the entire patch series. Also, a proper patch series must begine with a "[PATCH 0/2] ..." header posting explaining at a high level what the patch series is doing, how it is doing it, and why it is doing it that way. Thank you.
Re: [PATCH] devfreq/exynos-bus: Use common error handling code in exynos_bus_target()
Hi Markus,
As I already commented on your other patch related to extcon-max14577,
this patch might remove the redundant error message. But, it makes
the code more complicated in side of readability. I prefer existing code.
On 2017년 10월 22일 22:40, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 22 Oct 2017 15:33:06 +0200
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/devfreq/exynos-bus.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 49f68929e024..e38d456b2d7d 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -124,34 +124,33 @@ static int exynos_bus_target(struct device *dev,
> unsigned long *freq, u32 flags)
>
> if (old_freq < new_freq) {
> ret = regulator_set_voltage_tol(bus->regulator, new_volt, tol);
> - if (ret < 0) {
> - dev_err(bus->dev, "failed to set voltage\n");
> - goto out;
> - }
> + if (ret < 0)
> + goto report_failure;
> }
>
> ret = clk_set_rate(bus->clk, new_freq);
> if (ret < 0) {
> dev_err(dev, "failed to change clock of bus\n");
> clk_set_rate(bus->clk, old_freq);
> - goto out;
> + goto unlock;
> }
>
> if (old_freq > new_freq) {
> ret = regulator_set_voltage_tol(bus->regulator, new_volt, tol);
> - if (ret < 0) {
> - dev_err(bus->dev, "failed to set voltage\n");
> - goto out;
> - }
> + if (ret < 0)
> + goto report_failure;
> }
> bus->curr_freq = new_freq;
>
> dev_dbg(dev, "Set the frequency of bus (%luHz -> %luHz, %luHz)\n",
> old_freq, new_freq, clk_get_rate(bus->clk));
> -out:
> +unlock:
> mutex_unlock(&bus->lock);
> -
> return ret;
> +
> +report_failure:
> + dev_err(bus->dev, "failed to set voltage\n");
> + goto unlock;
> }
>
> static int exynos_bus_get_dev_status(struct device *dev,
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH v2 2/2] net: netrom: refactor code in nr_add_node
Code refactoring in order to make it easier to read and maintain.
Signed-off-by: Gustavo A. R. Silva
---
This code was tested by compilation only.
Changes in v2:
Make use of the swap macro and remove inline keyword.
net/netrom/nr_route.c | 59 ++-
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index fc9cadc..505e142 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -80,6 +80,19 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address
*callsign,
static void nr_remove_neigh(struct nr_neigh *);
+/* re-sort the routes in quality order.*/
+static void re_sort_routes(struct nr_node *nr_node, int x, int y)
+{
+ if (nr_node->routes[y].quality > nr_node->routes[x].quality) {
+ if (nr_node->which == x)
+ nr_node->which = y;
+ else if (nr_node->which == y)
+ nr_node->which = x;
+
+ swap(nr_node->routes[x], nr_node->routes[y]);
+ }
+}
+
/*
* Add a new route to a node, and in the process add the node and the
* neighbour if it is new.
@@ -90,7 +103,6 @@ static int __must_check nr_add_node(ax25_address *nr, const
char *mnemonic,
{
struct nr_node *nr_node;
struct nr_neigh *nr_neigh;
- struct nr_route nr_route;
int i, found;
struct net_device *odev;
@@ -251,50 +263,11 @@ static int __must_check nr_add_node(ax25_address *nr,
const char *mnemonic,
/* Now re-sort the routes in quality order */
switch (nr_node->count) {
case 3:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0:
- nr_node->which = 1;
- break;
- case 1:
- nr_node->which = 0;
- break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
- if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
- switch (nr_node->which) {
- case 1: nr_node->which = 2;
- break;
-
- case 2: nr_node->which = 1;
- break;
-
- default:
- break;
- }
- nr_route = nr_node->routes[1];
- nr_node->routes[1] = nr_node->routes[2];
- nr_node->routes[2] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
+ re_sort_routes(nr_node, 1, 2);
/* fall through */
case 2:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0: nr_node->which = 1;
- break;
-
- case 1: nr_node->which = 0;
- break;
-
- default: break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
case 1:
break;
}
--
2.7.4
Re: [PATCH v4] ARM: dts: display5: Device tree description of LWN's DISPLAY5 board
On Sun, Oct 22, 2017 at 12:05:55AM +0200, Lukasz Majewski wrote: > This commit adds device tree description of Liebherr's Display5 board. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Fabio Estevam Applied, thanks.
[PATCH 4/9] staging: lustre: ldlm: remove 'flags' arg from ldlm_process_flock_lock()
This is only ever set to LDLM_FL_WAIT_NOREPROC, so we can remove the arg
and discard any code that is only run when it doesn't have that value.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 110 ---
1 file changed, 21 insertions(+), 89 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 05e6b67b0e72..2d1fa2b33129 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -122,7 +122,7 @@ ldlm_flock_destroy(struct ldlm_lock *lock, enum ldlm_mode
mode, __u64 flags)
* is released.
*
*/
-static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags)
+static int ldlm_process_flock_lock(struct ldlm_lock *req)
{
struct ldlm_resource *res = req->l_resource;
struct ldlm_namespace *ns = ldlm_res_to_ns(res);
@@ -138,8 +138,8 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req,
__u64 *flags)
const struct ldlm_callback_suite null_cbs = { };
CDEBUG(D_DLMTRACE,
- "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n",
- *flags, new->l_policy_data.l_flock.owner,
+ "owner %llu pid %u mode %u start %llu end %llu\n",
+ new->l_policy_data.l_flock.owner,
new->l_policy_data.l_flock.pid, mode,
req->l_policy_data.l_flock.start,
req->l_policy_data.l_flock.end);
@@ -150,74 +150,16 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req,
__u64 *flags)
req->l_blocking_ast = NULL;
reprocess:
- if ((*flags == LDLM_FL_WAIT_NOREPROC) || (mode == LCK_NL)) {
- /* This loop determines where this processes locks start
-* in the resource lr_granted list.
-*/
- list_for_each(tmp, &res->lr_granted) {
- lock = list_entry(tmp, struct ldlm_lock,
- l_res_link);
- if (ldlm_same_flock_owner(lock, req)) {
- ownlocks = tmp;
- break;
- }
- }
- } else {
- int reprocess_failed = 0;
-
- lockmode_verify(mode);
-
- /* This loop determines if there are existing locks
-* that conflict with the new lock request.
-*/
- list_for_each(tmp, &res->lr_granted) {
- lock = list_entry(tmp, struct ldlm_lock,
- l_res_link);
-
- if (ldlm_same_flock_owner(lock, req)) {
- if (!ownlocks)
- ownlocks = tmp;
- continue;
- }
-
- /* locks are compatible, overlap doesn't matter */
- if (lockmode_compat(lock->l_granted_mode, mode))
- continue;
-
- if (!ldlm_flocks_overlap(lock, req))
- continue;
-
- if (*flags & LDLM_FL_BLOCK_NOWAIT) {
- ldlm_flock_destroy(req, mode, *flags);
- return LDLM_ITER_STOP;
- }
-
- if (*flags & LDLM_FL_TEST_LOCK) {
- ldlm_flock_destroy(req, mode, *flags);
- req->l_req_mode = lock->l_granted_mode;
- req->l_policy_data.l_flock.pid =
- lock->l_policy_data.l_flock.pid;
- req->l_policy_data.l_flock.start =
- lock->l_policy_data.l_flock.start;
- req->l_policy_data.l_flock.end =
- lock->l_policy_data.l_flock.end;
- *flags |= LDLM_FL_LOCK_CHANGED;
- return LDLM_ITER_STOP;
- }
-
- ldlm_resource_add_lock(res, &res->lr_waiting, req);
- *flags |= LDLM_FL_BLOCK_GRANTED;
- return LDLM_ITER_STOP;
+ /* This loop determines where this processes locks start
+* in the resource lr_granted list.
+*/
+ list_for_each(tmp, &res->lr_granted) {
+ lock = list_entry(tmp, struct ldlm_lock,
+ l_res_link);
+ if (ldlm_same_flock_owner(lock, req)) {
+ ownlocks = tmp;
+ break;
}
- if (reprocess_failed)
- return LDLM_ITER_CONTINUE;
- }
-
- if (*flags & LDLM_FL_TEST_LOCK) {
- ldlm_flock_destroy(req, mode, *flags);
- re
[PATCH 9/9] staging: lustre: ldlm: remove unused field 'fwd_generation'
With this field gone, we don't need local variables 'imp' or 'obd'
any more.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 774d8667769a..9c0e9cd0 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -311,7 +311,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
struct ldlm_flock_wait_data {
struct ldlm_lock *fwd_lock;
- intfwd_generation;
};
static void
@@ -342,11 +341,9 @@ int
ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64 flags, void *data)
{
struct file_lock*getlk = lock->l_ast_data;
- struct obd_device *obd;
- struct obd_import *imp = NULL;
- struct ldlm_flock_wait_data fwd;
- struct l_wait_infolwi;
- int rc = 0;
+ struct ldlm_flock_wait_data fwd;
+ struct l_wait_info lwi;
+ int rc = 0;
OBD_FAIL_TIMEOUT(OBD_FAIL_LDLM_CP_CB_WAIT2, 4);
if (OBD_FAIL_PRECHECK(OBD_FAIL_LDLM_CP_CB_WAIT3)) {
@@ -374,18 +371,6 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
LDLM_DEBUG(lock, "client-side enqueue returned a blocked lock,
sleeping");
fwd.fwd_lock = lock;
- obd = class_exp2obd(lock->l_conn_export);
-
- /* if this is a local lock, there is no import */
- if (obd)
- imp = obd->u.cli.cl_import;
-
- if (imp) {
- spin_lock(&imp->imp_lock);
- fwd.fwd_generation = imp->imp_generation;
- spin_unlock(&imp->imp_lock);
- }
-
lwi = LWI_TIMEOUT_INTR(0, NULL, ldlm_flock_interrupted_wait, &fwd);
/* Go to sleep until the lock is granted. */
[PATCH 7/9] staging: lustre: ldlm: tidy list walking in ldlm_flock()
Use list_for_each_entry variants to
avoid the explicit list_entry() calls.
This allows us to use list_for_each_entry_safe_from()
instread of adding a local list-walking macro.
Also improve some comments so that it is more obvious
that the locks are sorted per-owner and that we need
to find the insertion point.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 45 ++-
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 1bf56892fcf5..0bf6dce1c5b1 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -59,17 +59,6 @@
#include
#include "ldlm_internal.h"
-/**
- * list_for_remaining_safe - iterate over the remaining entries in a list
- * and safeguard against removal of a list entry.
- * \param pos the &struct list_head to use as a loop counter. pos MUST
- * have been initialized prior to using it in this macro.
- * \param n another &struct list_head to use as temporary storage
- * \param head the head for your list.
- */
-#define list_for_remaining_safe(pos, n, head) \
- for (n = pos->next; pos != (head); pos = n, n = pos->next)
-
static inline int
ldlm_same_flock_owner(struct ldlm_lock *lock, struct ldlm_lock *new)
{
@@ -125,8 +114,8 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
{
struct ldlm_resource *res = req->l_resource;
struct ldlm_namespace *ns = ldlm_res_to_ns(res);
- struct list_head *tmp;
- struct list_head *ownlocks = NULL;
+ struct ldlm_lock *tmp;
+ struct ldlm_lock *ownlocks = NULL;
struct ldlm_lock *lock = NULL;
struct ldlm_lock *new = req;
struct ldlm_lock *new2 = NULL;
@@ -151,23 +140,23 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
/* This loop determines where this processes locks start
* in the resource lr_granted list.
*/
- list_for_each(tmp, &res->lr_granted) {
- lock = list_entry(tmp, struct ldlm_lock,
- l_res_link);
+ list_for_each_entry(lock, &res->lr_granted, l_res_link) {
if (ldlm_same_flock_owner(lock, req)) {
- ownlocks = tmp;
+ ownlocks = lock;
break;
}
}
- /* Scan the locks owned by this process that overlap this request.
+ /* Scan the locks owned by this process to find the insertion point
+* (as locks are ordered), and to handle overlaps.
* We may have to merge or split existing locks.
*/
- if (!ownlocks)
- ownlocks = &res->lr_granted;
-
- list_for_remaining_safe(ownlocks, tmp, &res->lr_granted) {
- lock = list_entry(ownlocks, struct ldlm_lock, l_res_link);
+ if (ownlocks)
+ lock = ownlocks;
+ else
+ lock = list_entry(&res->lr_granted,
+ struct ldlm_lock, l_res_link);
+ list_for_each_entry_safe_from(lock, tmp, &res->lr_granted, l_res_link) {
if (!ldlm_same_flock_owner(lock, new))
break;
@@ -295,7 +284,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
lock->l_granted_mode);
/* insert new2 at lock */
- ldlm_resource_add_lock(res, ownlocks, new2);
+ ldlm_resource_add_lock(res, &lock->l_res_link, new2);
LDLM_LOCK_RELEASE(new2);
break;
}
@@ -309,8 +298,12 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
if (!added) {
list_del_init(&req->l_res_link);
- /* insert new lock before ownlocks in list. */
- ldlm_resource_add_lock(res, ownlocks, req);
+ /* insert new lock before "lock", which might be the
+* next lock for this owner, or might be the first
+* lock for the next owner, or might not be a lock at
+* all, but instead points at the head of the list
+*/
+ ldlm_resource_add_lock(res, &lock->l_res_link, req);
}
/* In case we're reprocessing the requested lock we can't destroy
[PATCH 6/9] staging: lustre: ldlm: remove 'flags' arg from ldlm_flock_destroy()
The only value ever passed in LDLM_FL_WAIT_NOREPROC, so assume that
instead of passing it.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 36 ++-
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index d5a5742a1171..1bf56892fcf5 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -88,24 +88,23 @@ ldlm_flocks_overlap(struct ldlm_lock *lock, struct
ldlm_lock *new)
}
static inline void
-ldlm_flock_destroy(struct ldlm_lock *lock, enum ldlm_mode mode, __u64 flags)
+ldlm_flock_destroy(struct ldlm_lock *lock, enum ldlm_mode mode)
{
- LDLM_DEBUG(lock, "%s(mode: %d, flags: 0x%llx)",
- __func__, mode, flags);
+ LDLM_DEBUG(lock, "%s(mode: %d)",
+ __func__, mode);
/* Safe to not lock here, since it should be empty anyway */
LASSERT(hlist_unhashed(&lock->l_exp_flock_hash));
list_del_init(&lock->l_res_link);
- if (flags == LDLM_FL_WAIT_NOREPROC) {
- /* client side - set a flag to prevent sending a CANCEL */
- lock->l_flags |= LDLM_FL_LOCAL_ONLY | LDLM_FL_CBPENDING;
- /* when reaching here, it is under lock_res_and_lock(). Thus,
-* need call the nolock version of ldlm_lock_decref_internal
-*/
- ldlm_lock_decref_internal_nolock(lock, mode);
- }
+ /* client side - set a flag to prevent sending a CANCEL */
+ lock->l_flags |= LDLM_FL_LOCAL_ONLY | LDLM_FL_CBPENDING;
+
+ /* when reaching here, it is under lock_res_and_lock(). Thus,
+* need call the nolock version of ldlm_lock_decref_internal
+*/
+ ldlm_lock_decref_internal_nolock(lock, mode);
ldlm_lock_destroy_nolock(lock);
}
@@ -208,8 +207,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
}
if (added) {
- ldlm_flock_destroy(lock, mode,
- LDLM_FL_WAIT_NOREPROC);
+ ldlm_flock_destroy(lock, mode);
} else {
new = lock;
added = 1;
@@ -233,8 +231,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
new->l_policy_data.l_flock.end + 1;
break;
}
- ldlm_flock_destroy(lock, lock->l_req_mode,
- LDLM_FL_WAIT_NOREPROC);
+ ldlm_flock_destroy(lock, lock->l_req_mode);
continue;
}
if (new->l_policy_data.l_flock.end >=
@@ -265,8 +262,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
NULL, 0, LVB_T_NONE);
lock_res_and_lock(req);
if (IS_ERR(new2)) {
- ldlm_flock_destroy(req, lock->l_granted_mode,
- LDLM_FL_WAIT_NOREPROC);
+ ldlm_flock_destroy(req, lock->l_granted_mode);
return LDLM_ITER_STOP;
}
goto reprocess;
@@ -323,7 +319,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
* could be freed before the completion AST can be sent.
*/
if (added)
- ldlm_flock_destroy(req, mode, LDLM_FL_WAIT_NOREPROC);
+ ldlm_flock_destroy(req, mode);
ldlm_resource_dump(D_INFO, res);
return LDLM_ITER_CONTINUE;
@@ -477,7 +473,7 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
LDLM_DEBUG(lock, "client-side enqueue deadlock
received");
rc = -EDEADLK;
}
- ldlm_flock_destroy(lock, mode, LDLM_FL_WAIT_NOREPROC);
+ ldlm_flock_destroy(lock, mode);
unlock_res_and_lock(lock);
/* Need to wake up the waiter if we were evicted */
@@ -498,7 +494,7 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
* in the lock changes we can decref the appropriate refcount.
*/
LASSERT(ldlm_is_test_lock(lock));
- ldlm_flock_destroy(lock, getlk->fl_type, LDLM_FL_WAIT_NOREPROC);
+ ldlm_flock_destroy(lock, getlk->fl_type);
switch (lock->l_granted_mode) {
case LCK_PR:
getlk->fl_type = F_RDLCK;
[PATCH 8/9] staging: lustre: ldlm: remove unnecessary 'ownlocks' variable.
Now that the code has been simplified, 'ownlocks' is not
necessary.
The loop which sets it exits with 'lock' having the same value as
'ownlocks', or pointing to the head of the list if ownlocks is NULL.
The current code then tests ownlocks and sets 'lock' to exactly the
value that it currently has.
So discard 'ownlocks'.
Also remove unnecessary initialization of 'lock'.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 0bf6dce1c5b1..774d8667769a 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -115,8 +115,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
struct ldlm_resource *res = req->l_resource;
struct ldlm_namespace *ns = ldlm_res_to_ns(res);
struct ldlm_lock *tmp;
- struct ldlm_lock *ownlocks = NULL;
- struct ldlm_lock *lock = NULL;
+ struct ldlm_lock *lock;
struct ldlm_lock *new = req;
struct ldlm_lock *new2 = NULL;
enum ldlm_mode mode = req->l_req_mode;
@@ -140,22 +139,14 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
/* This loop determines where this processes locks start
* in the resource lr_granted list.
*/
- list_for_each_entry(lock, &res->lr_granted, l_res_link) {
- if (ldlm_same_flock_owner(lock, req)) {
- ownlocks = lock;
+ list_for_each_entry(lock, &res->lr_granted, l_res_link)
+ if (ldlm_same_flock_owner(lock, req))
break;
- }
- }
/* Scan the locks owned by this process to find the insertion point
* (as locks are ordered), and to handle overlaps.
* We may have to merge or split existing locks.
*/
- if (ownlocks)
- lock = ownlocks;
- else
- lock = list_entry(&res->lr_granted,
- struct ldlm_lock, l_res_link);
list_for_each_entry_safe_from(lock, tmp, &res->lr_granted, l_res_link) {
if (!ldlm_same_flock_owner(lock, new))
Re: [PATCH v8 0/2] gpio: uniphier: UniPhier GPIO driver
Hi Linus, 2017-10-16 17:24 GMT+09:00 Linus Walleij : > On Thu, Oct 12, 2017 at 1:36 PM, Masahiro Yamada > wrote: > >> Changes in v8: >> - Move dt-binding header to binding commit >> - Add MAINTAINERS entry for the binding doc >> - Add a consumer example to the binding doc > > This v8 looks OK to me. > > The stuff is still hard to understand, but that is because the HW is > very complex and strangely designed, not because of the driver > author. I really think you did your best, thanks! > > I'll wait some days and see if the DT people have something to say > before applying it, but I'm as happy as I can be I guess. > Still waiting for DT people? As you know, it is almost deadline of DT pull requests to arm-soc maintainers. If the driver (and binding) is not applied, I cannot add GPIO nodes to my DT, i.e. I would have to wait for one more development cycle to use GPIO. -- Best Regards Masahiro Yamada
[PATCH 0/9] Assorted cleanups for staging/.../lustre/ldlm/ldlm_flock.c
This file contains quite a bit of dead code and unused variables. This patch series cleans it up in various ways. It should change behaviour at all, just code readability/maintainabilty. I sent the back in July but got not response, possibly because there were included with other patches which caused a distraction. So here they are by themselves. Thanks, NeilBrown --- NeilBrown (9): staging: lustre: ldlm: remove 'first_enq' arg from ldlm_process_flock_lock() staging: lustre: ldlm: remove unused 'work_list' arg from ldlm_process_flock_lock() staging: lustre: ldlm: remove unneeded 'err' arg to ldlm_process_flock_lock() staging: lustre: ldlm: remove 'flags' arg from ldlm_process_flock_lock() staging: lustre: ldlm: remove unused 'overlaps' variable staging: lustre: ldlm: remove 'flags' arg from ldlm_flock_destroy() staging: lustre: ldlm: tidy list walking in ldlm_flock() staging: lustre: ldlm: remove unnecessary 'ownlocks' variable. staging: lustre: ldlm: remove unused field 'fwd_generation' drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 208 +-- 1 file changed, 42 insertions(+), 166 deletions(-) -- Signature
[PATCH 5/9] staging: lustre: ldlm: remove unused 'overlaps' variable
'overlaps' is never used, only incremented.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 2d1fa2b33129..d5a5742a1171 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -133,7 +133,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
struct ldlm_lock *new2 = NULL;
enum ldlm_mode mode = req->l_req_mode;
int added = (mode == LCK_NL);
- int overlaps = 0;
int splitted = 0;
const struct ldlm_callback_suite null_cbs = { };
@@ -226,8 +225,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
lock->l_policy_data.l_flock.start)
break;
- ++overlaps;
-
if (new->l_policy_data.l_flock.start <=
lock->l_policy_data.l_flock.start) {
if (new->l_policy_data.l_flock.end <
[PATCH 2/9] staging: lustre: ldlm: remove unused 'work_list' arg from ldlm_process_flock_lock()
'work_list' is only set to NULL, and is never used.
So discard it.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index f719dc05e1ea..766653b4d8a5 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -123,8 +123,7 @@ ldlm_flock_destroy(struct ldlm_lock *lock, enum ldlm_mode
mode, __u64 flags)
*
*/
static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags,
- enum ldlm_error *err,
- struct list_head *work_list)
+ enum ldlm_error *err)
{
struct ldlm_resource *res = req->l_resource;
struct ldlm_namespace *ns = ldlm_res_to_ns(res);
@@ -594,7 +593,7 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
/* We need to reprocess the lock to do merges or splits
* with existing locks owned by this process.
*/
- ldlm_process_flock_lock(lock, &noreproc, &err, NULL);
+ ldlm_process_flock_lock(lock, &noreproc, &err);
}
unlock_res_and_lock(lock);
return rc;
[PATCH 3/9] staging: lustre: ldlm: remove unneeded 'err' arg to ldlm_process_flock_lock()
This arg is used to return an error code, but the returned code is never
looked at. So there is no point returning it.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 766653b4d8a5..05e6b67b0e72 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -122,8 +122,7 @@ ldlm_flock_destroy(struct ldlm_lock *lock, enum ldlm_mode
mode, __u64 flags)
* is released.
*
*/
-static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags,
- enum ldlm_error *err)
+static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags)
{
struct ldlm_resource *res = req->l_resource;
struct ldlm_namespace *ns = ldlm_res_to_ns(res);
@@ -145,8 +144,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req,
__u64 *flags,
req->l_policy_data.l_flock.start,
req->l_policy_data.l_flock.end);
- *err = ELDLM_OK;
-
/* No blocking ASTs are sent to the clients for
* Posix file & record locks
*/
@@ -192,7 +189,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req,
__u64 *flags,
if (*flags & LDLM_FL_BLOCK_NOWAIT) {
ldlm_flock_destroy(req, mode, *flags);
- *err = -EAGAIN;
return LDLM_ITER_STOP;
}
@@ -330,7 +326,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req,
__u64 *flags,
if (IS_ERR(new2)) {
ldlm_flock_destroy(req, lock->l_granted_mode,
*flags);
- *err = PTR_ERR(new2);
return LDLM_ITER_STOP;
}
goto reprocess;
@@ -440,7 +435,6 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
struct obd_import *imp = NULL;
struct ldlm_flock_wait_data fwd;
struct l_wait_infolwi;
- enum ldlm_error err;
int rc = 0;
OBD_FAIL_TIMEOUT(OBD_FAIL_LDLM_CP_CB_WAIT2, 4);
@@ -593,7 +587,7 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
/* We need to reprocess the lock to do merges or splits
* with existing locks owned by this process.
*/
- ldlm_process_flock_lock(lock, &noreproc, &err);
+ ldlm_process_flock_lock(lock, &noreproc);
}
unlock_res_and_lock(lock);
return rc;
[PATCH 1/9] staging: lustre: ldlm: remove 'first_enq' arg from ldlm_process_flock_lock()
it is only ever set to '1', so we can just assume that and remove the code.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index cb826e9e840e..f719dc05e1ea 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -121,15 +121,9 @@ ldlm_flock_destroy(struct ldlm_lock *lock, enum ldlm_mode
mode, __u64 flags)
* It is also responsible for splitting a lock if a portion of the lock
* is released.
*
- * If \a first_enq is 0 (ie, called from ldlm_reprocess_queue):
- * - blocking ASTs have already been sent
- *
- * If \a first_enq is 1 (ie, called from ldlm_lock_enqueue):
- * - blocking ASTs have not been sent yet, so list of conflicting locks
- * would be collected and ASTs sent.
*/
static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags,
- int first_enq, enum ldlm_error *err,
+ enum ldlm_error *err,
struct list_head *work_list)
{
struct ldlm_resource *res = req->l_resource;
@@ -197,11 +191,6 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req,
__u64 *flags,
if (!ldlm_flocks_overlap(lock, req))
continue;
- if (!first_enq) {
- reprocess_failed = 1;
- continue;
- }
-
if (*flags & LDLM_FL_BLOCK_NOWAIT) {
ldlm_flock_destroy(req, mode, *flags);
*err = -EAGAIN;
@@ -605,7 +594,7 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
/* We need to reprocess the lock to do merges or splits
* with existing locks owned by this process.
*/
- ldlm_process_flock_lock(lock, &noreproc, 1, &err, NULL);
+ ldlm_process_flock_lock(lock, &noreproc, &err, NULL);
}
unlock_res_and_lock(lock);
return rc;
Re: [RESEND v12 0/6] cgroup-aware OOM killer
On Thu, 19 Oct 2017, Johannes Weiner wrote: > David would have really liked for this patchset to include knobs to > influence how the algorithm picks cgroup victims. The rest of us > agreed that this is beyond the scope of these patches, that the > patches don't need it to be useful, and that there is nothing > preventing anyone from adding configurability later on. David > subsequently nacked the series as he considers it incomplete. Neither > Michal nor I see technical merit in David's nack. > The nack is for three reasons: (1) unfair comparison of root mem cgroup usage to bias against that mem cgroup from oom kill in system oom conditions, (2) the ability of users to completely evade the oom killer by attaching all processes to child cgroups either purposefully or unpurposefully, and (3) the inability of userspace to effectively control oom victim selection. For (1), the difference in v12 is adding the rss of all processes attached to the root mem cgroup as the evaluation. This is not the same criteria that child cgroups are evaluated on, and they are compared using that bias. It is very trivial to provide a fair comparison as was suggested in v11. For (2), users who do for i in $(cat cgroup.procs); do mkdir $i; echo $i > $i/cgroup.procs; done can completely evade the oom killer and this may be part of their standard operating procedure for restricting resources with other cgroups other than the mem cgroup. Again, it's an unfair comparison to all other cgroups on the system. For (3), users need the ability to protect important cgroups, such as protecting a cgroup that is limited to 50% of system memory. They need the ability to kill processes from other cgroups to protect these important processes. This is nothing new: the oom killer has always provided the ability to bias against important processes. There was follow-up email on all of these points where very trivial changes were suggested to address all three of these issues, and which Roman has implemented in one form or another in previous iterations with the bonus that no accounting to the root mem cgroup needs to be done. > Michal acked the implementation, but on the condition that the new > behavior be opt-in, to not surprise existing users. I *think* we agree > that respecting the cgroup topography during global OOM is what we > should have been doing when cgroups were initially introduced; where > we disagree is that I think users shouldn't have to opt in to > improvements. We have done much more invasive changes to the victim > selection without actual regressions in the past. Further, this change > only applies to mounts of the new cgroup2. Tejun also wasn't convinced > of the risk for regression, and too would prefer cgroup-awareness to > be the default in cgroup2. I would ask for patch 5/6 to be dropped. > I agree with Michal that the new victim selection should be opt-in with CGRP_GROUP_OOM.
Re: [PATCH 3/4] ARM: dts: imx28-tx28: fix interrupt flags and use interrupts-extended property
On Wed, Oct 18, 2017 at 08:40:59AM +0200, Lothar Waßmann wrote: > > So should I drop all interrupts-extended patches from you? > > > Yes, please. Since this patch, and the corresponding patch for tx53 > also fixed the interrupt flags, I will send new patches to only fix > the interrupt flags. Okay, the following two got dropped from imx/dt branch. ARM: dts: imx28-tx28: fix interrupt flags and use interrupts-extended property ARM: dts: imx53-tx53: fix interrupt flags and use interrupts-extended property Shawn
