Re: [RFC PATCH 1/9] drivers: regulator: qcom_spmi: enable linear range info
On 4/4/19 07:55, Mark Brown wrote:
> On Thu, Apr 04, 2019 at 07:09:22AM +0200, Niklas Cassel wrote:
>> From: Jorge Ramirez-Ortiz
>>
>> Signed-off-by: Jorge Ramirez-Ortiz
>> ---
>> drivers/regulator/qcom_spmi-regulator.c | 7 +++
>> 1 file changed, 7 insertions(+)
>
> This doesn't build:
>
> CC drivers/regulator/qcom_spmi-regulator.o
> drivers/regulator/qcom_spmi-regulator.c: In function
> ‘qcom_spmi_regulator_probe’:
> drivers/regulator/qcom_spmi-regulator.c:1837:29: error:
> ‘SPMI_REGULATOR_LOGICAL_TYPE_HFS430’ undeclared (first use in this function);
> did you mean ‘SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS’?
>if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_HFS430) {
> ^~
> SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS
> drivers/regulator/qcom_spmi-regulator.c:1837:29: note: each undeclared
> identifier is reported only once for each function it appears in
>
yeah, the SPMI regulator changes are still pending
Re: [PATCH v1] mfd: Add support for Merrifield Basin Cove PMIC
On Tue, 02 Apr 2019, Andy Shevchenko wrote:
> On Tue, Apr 02, 2019 at 06:12:11AM +0100, Lee Jones wrote:
> > On Mon, 18 Mar 2019, Andy Shevchenko wrote:
> >
> > > Add an mfd driver for Intel Merrifield Basin Cove PMIC.
> >
> > Nit: s/mfd/MFD/
>
> Noted. And changed for v2.
>
> > > +static const struct mfd_cell bcove_dev[] = {
> > > + {
> > > + .name = "mrfld_bcove_pwrbtn",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[0],
> > > + }, {
> > > + .name = "mrfld_bcove_tmu",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[1],
> > > + }, {
> > > + .name = "mrfld_bcove_thermal",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[2],
> > > + }, {
> > > + .name = "mrfld_bcove_bcu",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[3],
> > > + }, {
> > > + .name = "mrfld_bcove_adc",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[4],
> > > + }, {
> > > + .name = "mrfld_bcove_charger",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[5],
> > > + }, {
> > > + .name = "mrfld_bcove_extcon",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[5],
> > > + }, {
> > > + .name = "mrfld_bcove_gpio",
> > > + .num_resources = 1,
> > > + .resources = &irq_level2_resources[6],
> > > + },
> > > + { .name = "mrfld_bcove_region", },
> > > +};
>
> > > +static int regmap_ipc_byte_reg_read(void *context, unsigned int reg,
> >
> > Prefixing these with regmap is pretty confusing, since this it not
> > part of the Regmap API. Better to provide them with local names
> > instead.
> >
> > bcove_ipc_byte_reg_read()
>
> Good point. And changed for v2.
>
> > > + for (i = 0; i < ARRAY_SIZE(irq_level2_resources); i++) {
> > > + ret = platform_get_irq(pdev, i);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + irq_level2_resources[i].start = ret;
> > > + irq_level2_resources[i].end = ret;
> > > + }
> >
> > Although succinct, dragging values from one platform device into
> > another doesn't sound that neat.
>
> So, how to split resources given in one _physical_ multi-functional device to
> several of them? Isn't it what MFD framework for?
>
> Any other approach here? I'm all ears!
>From the child:
platform_get_irq(dev->parent, CLIENT_ID);
> > Also, since the ordering of the
> > devices is critical in this implementation, it also comes across as
> > fragile.
>
> How fragile? In ACPI we don't have IRQ labeling scheme. Index is used for
> that.
>
> > Any reason why ACPI can't register all of the child devices, or for
> > the child devices to obtain their IRQ directly from the tables?
>
> And how are we supposed to enumerated them taking into consideration single
> ACPI ID given?
This question was a little whimsical, since I have no idea how the
ACPI tables you're working with are laid out.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: Add support for Merrifield Basin Cove PMIC
On Thu, 04 Apr 2019, Lee Jones wrote:
> On Tue, 02 Apr 2019, Andy Shevchenko wrote:
>
> > On Tue, Apr 02, 2019 at 06:12:11AM +0100, Lee Jones wrote:
> > > On Mon, 18 Mar 2019, Andy Shevchenko wrote:
> > >
> > > > Add an mfd driver for Intel Merrifield Basin Cove PMIC.
> > >
> > > Nit: s/mfd/MFD/
> >
> > Noted. And changed for v2.
> >
> > > > +static const struct mfd_cell bcove_dev[] = {
> > > > + {
> > > > + .name = "mrfld_bcove_pwrbtn",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[0],
> > > > + }, {
> > > > + .name = "mrfld_bcove_tmu",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[1],
> > > > + }, {
> > > > + .name = "mrfld_bcove_thermal",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[2],
> > > > + }, {
> > > > + .name = "mrfld_bcove_bcu",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[3],
> > > > + }, {
> > > > + .name = "mrfld_bcove_adc",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[4],
> > > > + }, {
> > > > + .name = "mrfld_bcove_charger",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[5],
> > > > + }, {
> > > > + .name = "mrfld_bcove_extcon",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[5],
> > > > + }, {
> > > > + .name = "mrfld_bcove_gpio",
> > > > + .num_resources = 1,
> > > > + .resources = &irq_level2_resources[6],
> > > > + },
> > > > + { .name = "mrfld_bcove_region", },
> > > > +};
> >
> > > > +static int regmap_ipc_byte_reg_read(void *context, unsigned int reg,
> > >
> > > Prefixing these with regmap is pretty confusing, since this it not
> > > part of the Regmap API. Better to provide them with local names
> > > instead.
> > >
> > > bcove_ipc_byte_reg_read()
> >
> > Good point. And changed for v2.
> >
> > > > + for (i = 0; i < ARRAY_SIZE(irq_level2_resources); i++) {
> > > > + ret = platform_get_irq(pdev, i);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + irq_level2_resources[i].start = ret;
> > > > + irq_level2_resources[i].end = ret;
> > > > + }
> > >
> > > Although succinct, dragging values from one platform device into
> > > another doesn't sound that neat.
> >
> > So, how to split resources given in one _physical_ multi-functional device
> > to
> > several of them? Isn't it what MFD framework for?
> >
> > Any other approach here? I'm all ears!
>
> From the child:
>
> platform_get_irq(dev->parent, CLIENT_ID);
If you set the .id of the cell properly you could do:
platform_get_irq(dev->parent, dev->id);
> > > Also, since the ordering of the
> > > devices is critical in this implementation, it also comes across as
> > > fragile.
> >
> > How fragile? In ACPI we don't have IRQ labeling scheme. Index is used for
> > that.
> >
> > > Any reason why ACPI can't register all of the child devices, or for
> > > the child devices to obtain their IRQ directly from the tables?
> >
> > And how are we supposed to enumerated them taking into consideration single
> > ACPI ID given?
>
> This question was a little whimsical, since I have no idea how the
> ACPI tables you're working with are laid out.
>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v8 05/11] mfd: core: document mfd_add_devices()
On Wed, 03 Apr 2019, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add a kernel doc for mfd_add_devices(). > > Signed-off-by: Bartosz Golaszewski > Acked-by: Pavel Machek > --- > drivers/mfd/mfd-core.c | 13 + > 1 file changed, 13 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] tty: add SPDX identifiers to Kconfig and Makefiles
On 4/2/2019 7:37 PM, Greg Kroah-Hartman wrote: There were a few Kconfig and Makefiles under drivers/tty/ that were missing a SPDX identifier. Fix that up so that automated tools can properly classify all kernel source files. Cc: Jiri Slaby Cc: Jiri Kosina Cc: David Sterba Cc: Rob Herring Signed-off-by: Greg Kroah-Hartman Reviewed-by: Mukesh Ojha Cheers, -Mukesh --- drivers/tty/Kconfig | 1 + drivers/tty/hvc/Kconfig | 1 + drivers/tty/ipwireless/Makefile | 1 + drivers/tty/serdev/Kconfig | 1 + drivers/tty/serdev/Makefile | 1 + drivers/tty/serial/8250/Kconfig | 1 + drivers/tty/serial/Kconfig | 1 + drivers/tty/serial/cpm_uart/Makefile | 1 + drivers/tty/serial/jsm/Makefile | 1 + 9 files changed, 9 insertions(+) diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig index e0a04bfc873e..8034473c54ca 100644 --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 config TTY bool "Enable TTY" if EXPERT default y diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig index 4293c172e120..1a910ec9f643 100644 --- a/drivers/tty/hvc/Kconfig +++ b/drivers/tty/hvc/Kconfig @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 if TTY config HVC_DRIVER diff --git a/drivers/tty/ipwireless/Makefile b/drivers/tty/ipwireless/Makefile index fe2e1730986b..a665d021e24d 100644 --- a/drivers/tty/ipwireless/Makefile +++ b/drivers/tty/ipwireless/Makefile @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 # # Makefile for the IPWireless driver # diff --git a/drivers/tty/serdev/Kconfig b/drivers/tty/serdev/Kconfig index 1dbc8352e027..46ae732bfc68 100644 --- a/drivers/tty/serdev/Kconfig +++ b/drivers/tty/serdev/Kconfig @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 # # Serial bus device driver configuration # diff --git a/drivers/tty/serdev/Makefile b/drivers/tty/serdev/Makefile index 0cbdb9444d9d..078417e5b068 100644 --- a/drivers/tty/serdev/Makefile +++ b/drivers/tty/serdev/Makefile @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 serdev-objs := core.o obj-$(CONFIG_SERIAL_DEV_BUS) += serdev.o diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig index 15c2c5463835..296115f6a4d8 100644 --- a/drivers/tty/serial/8250/Kconfig +++ b/drivers/tty/serial/8250/Kconfig @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 # # The 8250/16550 serial drivers. You shouldn't be in this list unless # you somehow have an implicit or explicit dependency on SERIAL_8250. diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 72966bc0ac76..a5032e58c737 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 # # Serial device configuration # diff --git a/drivers/tty/serial/cpm_uart/Makefile b/drivers/tty/serial/cpm_uart/Makefile index 896a5d57881c..3f3a6ed02ed4 100644 --- a/drivers/tty/serial/cpm_uart/Makefile +++ b/drivers/tty/serial/cpm_uart/Makefile @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 # # Makefile for the Motorola 8xx FEC ethernet controller # diff --git a/drivers/tty/serial/jsm/Makefile b/drivers/tty/serial/jsm/Makefile index 705d1ff6fdeb..4f2dbada7741 100644 --- a/drivers/tty/serial/jsm/Makefile +++ b/drivers/tty/serial/jsm/Makefile @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 # # Makefile for Jasmine adapter #
Re: [PATCH] staging: greybus: power_supply: fix prop-descriptor request size
Hi Johan,
Thanks for the patch.
On Thu 04 Apr 2019 at 07:53, Johan Hovold wrote:
Since moving the message buffers off the stack, the dynamically
allocated get-prop-descriptor request buffer is incorrectly
sized due to
using the pointer rather than request-struct size when creating
the
operation.
Fortunately, the pointer size is always larger than this
one-byte
request, but this could still cause trouble on the remote end
due to the
unexpected message size.
Fixes: 9d15134d067e ("greybus: power_supply: rework get
descriptors")
Cc: stable # 4.9
Cc: Rui Miguel Silva
Signed-off-by: Johan Hovold
Nice catch. LGTM.
Reviewed-by: Rui Miguel Silva
---
Cheers,
Rui
---
drivers/staging/greybus/power_supply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/power_supply.c
b/drivers/staging/greybus/power_supply.c
index 0529e5628c24..ae5c0285a942 100644
--- a/drivers/staging/greybus/power_supply.c
+++ b/drivers/staging/greybus/power_supply.c
@@ -520,7 +520,7 @@ static int
gb_power_supply_prop_descriptors_get(struct gb_power_supply
*gbpsy)
op = gb_operation_create(connection,
GB_POWER_SUPPLY_TYPE_GET_PROP_DESCRIPTORS,
- sizeof(req), sizeof(*resp) +
props_count *
+ sizeof(*req), sizeof(*resp) +
props_count *
sizeof(struct
gb_power_supply_props_desc),
GFP_KERNEL);
if (!op)
Re: [PATCH 2/6] arm64/mm: Enable memory hot remove
On 04/03/2019 11:02 PM, Logan Gunthorpe wrote: > > > On 2019-04-02 10:30 p.m., Anshuman Khandual wrote: >> Memory removal from an arch perspective involves tearing down two different >> kernel based mappings i.e vmemmap and linear while releasing related page >> table pages allocated for the physical memory range to be removed. >> >> Define a common kernel page table tear down helper remove_pagetable() which >> can be used to unmap given kernel virtual address range. In effect it can >> tear down both vmemap or kernel linear mappings. This new helper is called >> from both vmemamp_free() and ___remove_pgd_mapping() during memory removal. >> The argument 'direct' here identifies kernel linear mappings. >> >> Vmemmap mappings page table pages are allocated through sparse mem helper >> functions like vmemmap_alloc_block() which does not cycle the pages through >> pgtable_page_ctor() constructs. Hence while removing it skips corresponding >> destructor construct pgtable_page_dtor(). >> >> While here update arch_add_mempory() to handle __add_pages() failures by >> just unmapping recently added kernel linear mapping. Now enable memory hot >> remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE. >> >> This implementation is overall inspired from kernel page table tear down >> procedure on X86 architecture. > > I've been working on very similar things for RISC-V. In fact, I'm > currently in progress on a very similar stripped down version of > remove_pagetable(). (Though I'm fairly certain I've done a bunch of > stuff wrong.) > > Would it be possible to move this work into common code that can be used > by all arches? Seems like, to start, we should be able to support both > arm64 and RISC-V... and maybe even x86 too. > > I'd be happy to help integrate and test such functions in RISC-V. Sure that will be great. The only impediment is pgtable_page_ctor() for kernel linear mapping. This series is based on current arm64 where linear mapping pgtable pages go through pgtable_page_ctor() init sequence but that might be changing soon. If RISC-V does not have pgtable_page_ctor() init for linear mapping and no other arch specific stuff later on we can try to consolidate remove_pagetable() atleast for both the architectures. Then I wondering whether I can transition pud|pmd_large() to pud|pmd_sect().
Re: [PATCH] staging: greybus: power_supply: Use struct_size() helper
Hi Gustavo, Thanks a lot for the patch. On Wed 03 Apr 2019 at 21:58, Gustavo A. R. Silva wrote: Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace code of the following form: sizeof(*resp) + props_count * sizeof(struct gb_power_supply_props_desc) with: struct_size(resp, props, props_count) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva What are the odds of 2 people changing same code in greybus in the same day :). But it happened, so as Johan asked please rebase on top of his patch. that would be great. --- Cheers, Rui --- drivers/staging/greybus/power_supply.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/power_supply.c b/drivers/staging/greybus/power_supply.c index 0529e5628c24..40cc2d462ba0 100644 --- a/drivers/staging/greybus/power_supply.c +++ b/drivers/staging/greybus/power_supply.c @@ -520,8 +520,8 @@ static int gb_power_supply_prop_descriptors_get(struct gb_power_supply *gbpsy) op = gb_operation_create(connection, GB_POWER_SUPPLY_TYPE_GET_PROP_DESCRIPTORS, - sizeof(req), sizeof(*resp) + props_count * - sizeof(struct gb_power_supply_props_desc), +sizeof(req), + struct_size(resp, props, props_count), GFP_KERNEL); if (!op) return -ENOMEM;
Re: [RFC PATCH 00/25] Accelerate page migration and use memcg for PMEM management
On Wed 03-04-19 19:00:21, Zi Yan wrote: > From: Zi Yan > > Thanks to Dave Hansen's patches, which make PMEM as part of memory as NUMA > nodes. > How to use PMEM along with normal DRAM remains an open problem. There are > several patchsets posted on the mailing list, proposing to use page migration > to > move pages between PMEM and DRAM using Linux page replacement policy [1,2,3]. > There are some important problems not addressed in these patches: > 1. The page migration in Linux does not provide high enough throughput for us > to > fully exploit PMEM or other use cases. > 2. Linux page replacement is running too infrequent to distinguish hot and > cold > pages. [...] > 33 files changed, 4261 insertions(+), 162 deletions(-) For a patch _this_ large you should really start with a real world usecasing hitting bottlenecks with the current implementation. Should microbenchmarks can trigger bottlenecks much easier but do real application do the same? Please give us some numbers. -- Michal Hocko SUSE Labs
Re: [PATCH] mm:workingset use real time to judge activity of the file page
[Fixup email for Pavel and add Johannes]
On Thu 04-04-19 11:30:17, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> In previous implementation, the number of refault pages is used
> for judging the refault period of each page, which is not precised as
> eviction of other files will be affect a lot on current cache.
> We introduce the timestamp into the workingset's entry and refault ratio
> to measure the file page's activity. It helps to decrease the affection
> of other files(average refault ratio can reflect the view of whole system
> 's memory).
> The patch is tested on an Android system, which can be described as
> comparing the launch time of an application between a huge memory
> consumption. The result is launch time decrease 50% and the page fault
> during the test decrease 80%.
>
> Signed-off-by: Zhaoyang Huang
> ---
> include/linux/mmzone.h | 2 ++
> mm/workingset.c| 24 +---
> 2 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 32699b2..c38ba0a 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -240,6 +240,8 @@ struct lruvec {
> atomic_long_t inactive_age;
> /* Refaults at the time of last reclaim cycle */
> unsigned long refaults;
> + atomic_long_t refaults_ratio;
> + atomic_long_t prev_fault;
> #ifdef CONFIG_MEMCG
> struct pglist_data *pgdat;
> #endif
> diff --git a/mm/workingset.c b/mm/workingset.c
> index 40ee02c..6361853 100644
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@ -159,7 +159,7 @@
>NODES_SHIFT + \
>MEM_CGROUP_ID_SHIFT)
> #define EVICTION_MASK(~0UL >> EVICTION_SHIFT)
> -
> +#define EVICTION_JIFFIES (BITS_PER_LONG >> 3)
> /*
> * Eviction timestamps need to be able to cover the full range of
> * actionable refaults. However, bits are tight in the radix tree
> @@ -175,18 +175,22 @@ static void *pack_shadow(int memcgid, pg_data_t *pgdat,
> unsigned long eviction)
> eviction >>= bucket_order;
> eviction = (eviction << MEM_CGROUP_ID_SHIFT) | memcgid;
> eviction = (eviction << NODES_SHIFT) | pgdat->node_id;
> + eviction = (eviction << EVICTION_JIFFIES) | (jiffies >>
> EVICTION_JIFFIES);
> eviction = (eviction << RADIX_TREE_EXCEPTIONAL_SHIFT);
>
> return (void *)(eviction | RADIX_TREE_EXCEPTIONAL_ENTRY);
> }
>
> static void unpack_shadow(void *shadow, int *memcgidp, pg_data_t **pgdat,
> - unsigned long *evictionp)
> + unsigned long *evictionp, unsigned long *prev_jiffp)
> {
> unsigned long entry = (unsigned long)shadow;
> int memcgid, nid;
> + unsigned long prev_jiff;
>
> entry >>= RADIX_TREE_EXCEPTIONAL_SHIFT;
> + entry >>= EVICTION_JIFFIES;
> + prev_jiff = (entry & ((1UL << EVICTION_JIFFIES) - 1)) <<
> EVICTION_JIFFIES;
> nid = entry & ((1UL << NODES_SHIFT) - 1);
> entry >>= NODES_SHIFT;
> memcgid = entry & ((1UL << MEM_CGROUP_ID_SHIFT) - 1);
> @@ -195,6 +199,7 @@ static void unpack_shadow(void *shadow, int *memcgidp,
> pg_data_t **pgdat,
> *memcgidp = memcgid;
> *pgdat = NODE_DATA(nid);
> *evictionp = entry << bucket_order;
> + *prev_jiffp = prev_jiff;
> }
>
> /**
> @@ -242,8 +247,12 @@ bool workingset_refault(void *shadow)
> unsigned long refault;
> struct pglist_data *pgdat;
> int memcgid;
> + unsigned long refault_ratio;
> + unsigned long prev_jiff;
> + unsigned long avg_refault_time;
> + unsigned long refault_time;
>
> - unpack_shadow(shadow, &memcgid, &pgdat, &eviction);
> + unpack_shadow(shadow, &memcgid, &pgdat, &eviction, &prev_jiff);
>
> rcu_read_lock();
> /*
> @@ -288,10 +297,11 @@ bool workingset_refault(void *shadow)
>* list is not a problem.
>*/
> refault_distance = (refault - eviction) & EVICTION_MASK;
> -
> inc_lruvec_state(lruvec, WORKINGSET_REFAULT);
> -
> - if (refault_distance <= active_file) {
> + lruvec->refaults_ratio = atomic_long_read(&lruvec->inactive_age) /
> jiffies;
> + refault_time = jiffies - prev_jiff;
> + avg_refault_time = refault_distance / lruvec->refaults_ratio;
> + if (refault_time <= avg_refault_time) {
> inc_lruvec_state(lruvec, WORKINGSET_ACTIVATE);
> rcu_read_unlock();
> return true;
> @@ -521,7 +531,7 @@ static int __init workingset_init(void)
>* some more pages at runtime, so keep working with up to
>* double the initial memory by using totalram_pages as-is.
>*/
> - timestamp_bits = BITS_PER_LONG - EVICTION_SHIFT;
> + timestamp_bits = BITS_PER_LONG - EVICTION_SHIFT - EVICTION_JIFFIES;
> max_order = fls_long(totalram_pages - 1);
> if (max_order > timestamp_bits)
> bucket_order = m
Re: [PATCH v8 06/11] mfd: max77650: new core mfd driver
On Wed, 03 Apr 2019, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add the core mfd driver for max77650 PMIC. We define five sub-devices
> for which the drivers will be added in subsequent patches.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/mfd/Kconfig | 14 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/max77650.c | 234 +++
> include/linux/mfd/max77650.h | 59 +
> 4 files changed, 308 insertions(+)
> create mode 100644 drivers/mfd/max77650.c
> create mode 100644 include/linux/mfd/max77650.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0ce2d8dfc5f1..ade04e124aa0 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -733,6 +733,20 @@ config MFD_MAX77620
> provides common support for accessing the device; additional drivers
> must be enabled in order to use the functionality of the device.
>
> +config MFD_MAX77650
> + tristate "Maxim MAX77650/77651 PMIC Support"
> + depends on I2C
> + depends on OF || COMPILE_TEST
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> + Say Y here to add support for Maxim Semiconductor MAX77650 and
> + MAX77651 Power Management ICs. This is the core multifunction
> + driver for interacting with the device. The module name is
> + 'max77650'. Additional drivers can be enabled in order to use
> + the following functionalities of the device: GPIO, regulator,
> + charger, LED, onkey.
> +
> config MFD_MAX77686
> tristate "Maxim Semiconductor MAX77686/802 PMIC Support"
> depends on I2C
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b4569ed7f3f3..5727d099c16f 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -155,6 +155,7 @@ obj-$(CONFIG_MFD_DA9150) += da9150-core.o
>
> obj-$(CONFIG_MFD_MAX14577) += max14577.o
> obj-$(CONFIG_MFD_MAX77620) += max77620.o
> +obj-$(CONFIG_MFD_MAX77650) += max77650.o
> obj-$(CONFIG_MFD_MAX77686) += max77686.o
> obj-$(CONFIG_MFD_MAX77693) += max77693.o
> obj-$(CONFIG_MFD_MAX77843) += max77843.o
> diff --git a/drivers/mfd/max77650.c b/drivers/mfd/max77650.c
> new file mode 100644
> index ..7a6c0a5cf602
> --- /dev/null
> +++ b/drivers/mfd/max77650.c
> @@ -0,0 +1,234 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2018 BayLibre SAS
> +// Author: Bartosz Golaszewski
> +//
> +// Core MFD driver for MAXIM 77650/77651 charger/power-supply.
> +// Programming manual: https://pdfserv.maximintegrated.com/en/an/AN6428.pdf
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX77650_INT_GPI_F_MSK BIT(0)
> +#define MAX77650_INT_GPI_R_MSK BIT(1)
> +#define MAX77650_INT_GPI_MSK \
> + (MAX77650_INT_GPI_F_MSK | MAX77650_INT_GPI_R_MSK)
> +#define MAX77650_INT_nEN_F_MSK BIT(2)
> +#define MAX77650_INT_nEN_R_MSK BIT(3)
> +#define MAX77650_INT_TJAL1_R_MSK BIT(4)
> +#define MAX77650_INT_TJAL2_R_MSK BIT(5)
> +#define MAX77650_INT_DOD_R_MSK BIT(6)
> +
> +#define MAX77650_INT_THM_MSK BIT(0)
> +#define MAX77650_INT_CHG_MSK BIT(1)
> +#define MAX77650_INT_CHGIN_MSK BIT(2)
> +#define MAX77650_INT_TJ_REG_MSK BIT(3)
> +#define MAX77650_INT_CHGIN_CTRL_MSK BIT(4)
> +#define MAX77650_INT_SYS_CTRL_MSKBIT(5)
> +#define MAX77650_INT_SYS_CNFG_MSKBIT(6)
> +
> +#define MAX77650_INT_GLBL_OFFSET 0
> +#define MAX77650_INT_CHG_OFFSET 1
> +
> +#define MAX77650_SBIA_LPM_MASK BIT(5)
> +#define MAX77650_SBIA_LPM_DISABLED 0x00
> +
> +enum {
> + MAX77650_INT_GPI,
> + MAX77650_INT_nEN_F,
> + MAX77650_INT_nEN_R,
> + MAX77650_INT_TJAL1_R,
> + MAX77650_INT_TJAL2_R,
> + MAX77650_INT_DOD_R,
> + MAX77650_INT_THM,
> + MAX77650_INT_CHG,
> + MAX77650_INT_CHGIN,
> + MAX77650_INT_TJ_REG,
> + MAX77650_INT_CHGIN_CTRL,
> + MAX77650_INT_SYS_CTRL,
> + MAX77650_INT_SYS_CNFG,
> +};
> +
> +static const struct resource max77650_charger_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MAX77650_INT_CHG, "CHG"),
> + DEFINE_RES_IRQ_NAMED(MAX77650_INT_CHGIN, "CHGIN"),
> +};
> +
> +static const struct resource max77650_gpio_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MAX77650_INT_GPI, "GPI"),
> +};
> +
> +static const struct resource max77650_onkey_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MAX77650_INT_nEN_F, "nEN_F"),
> + DEFINE_RES_IRQ_NAMED(MAX77650_INT_nEN_R, "nEN_R"),
> +};
> +
> +static const struct mfd_cell max77650_cells[] = {
> + {
> + .name = "max77650-regulator",
> + .of_compatible = "maxim,max77650-regulator",
> + },
> + {
Nit: Place these all on the same line, like:
}, {
> + .name = "max77650-charger",
> +
[PATCH 0/5] Input: Use devm_platform_ioremap_resource()
Hi All, This is just a minor change to promote using of this api devm_platform_ioremap_resource() and nothing else functional change it does. Also, there are patches where only ioremap is used without requesting the mem region so this devm_platform_ioremap_resource() take cares all of that in single call. Mukesh Ojha (5): Input: fsl-imx25-tcq: Use devm_platform_ioremap_resource() Input: mxs-lradc-ts.c: Use devm_platform_ioremap_resource() Input: s3c2410_ts: Use devm_platform_ioremap_resource() Input: sun4i-ts: Use devm_platform_ioremap_resource() Input: ts4800-ts: Use devm_platform_ioremap_resource() drivers/input/touchscreen/fsl-imx25-tcq.c | 4 +--- drivers/input/touchscreen/mxs-lradc-ts.c | 6 +- drivers/input/touchscreen/s3c2410_ts.c| 10 +- drivers/input/touchscreen/sun4i-ts.c | 3 +-- drivers/input/touchscreen/ts4800-ts.c | 4 +--- 5 files changed, 5 insertions(+), 22 deletions(-) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 4/5] Input: sun4i-ts: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource() and devm_ioremap_resource() in it. So instead of calling them separately use devm_platform_ioremap_resource() directly. Signed-off-by: Mukesh Ojha --- drivers/input/touchscreen/sun4i-ts.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c index d2e14d9..bbb0104 100644 --- a/drivers/input/touchscreen/sun4i-ts.c +++ b/drivers/input/touchscreen/sun4i-ts.c @@ -309,8 +309,7 @@ static int sun4i_ts_probe(struct platform_device *pdev) input_set_drvdata(ts->input, ts); } - ts->base = devm_ioremap_resource(dev, - platform_get_resource(pdev, IORESOURCE_MEM, 0)); + ts->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(ts->base)) return PTR_ERR(ts->base); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/5] Input: mxs-lradc-ts.c: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource() and devm_ioremap_resource() in it. So instead of calling them separately use devm_platform_ioremap_resource() directly. Signed-off-by: Mukesh Ojha --- drivers/input/touchscreen/mxs-lradc-ts.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/input/touchscreen/mxs-lradc-ts.c b/drivers/input/touchscreen/mxs-lradc-ts.c index c850b51..af047fa 100644 --- a/drivers/input/touchscreen/mxs-lradc-ts.c +++ b/drivers/input/touchscreen/mxs-lradc-ts.c @@ -615,7 +615,6 @@ static int mxs_lradc_ts_probe(struct platform_device *pdev) struct device_node *node = dev->parent->of_node; struct mxs_lradc *lradc = dev_get_drvdata(dev->parent); struct mxs_lradc_ts *ts; - struct resource *iores; int ret, irq, virq, i; u32 ts_wires = 0, adapt; @@ -629,10 +628,7 @@ static int mxs_lradc_ts_probe(struct platform_device *pdev) ts->dev = dev; spin_lock_init(&ts->lock); - iores = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!iores) - return -EINVAL; - ts->base = devm_ioremap(dev, iores->start, resource_size(iores)); + ts->base = devm_platform_ioremap_resource(pdev, 0); if (!ts->base) return -ENOMEM; -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 5/5] Input: ts4800-ts: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
Signed-off-by: Mukesh Ojha
---
drivers/input/touchscreen/ts4800-ts.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ts4800-ts.c
b/drivers/input/touchscreen/ts4800-ts.c
index fed73ee..5b4f536 100644
--- a/drivers/input/touchscreen/ts4800-ts.c
+++ b/drivers/input/touchscreen/ts4800-ts.c
@@ -148,7 +148,6 @@ static int ts4800_ts_probe(struct platform_device *pdev)
{
struct input_polled_dev *poll_dev;
struct ts4800_ts *ts;
- struct resource *res;
int error;
ts = devm_kzalloc(&pdev->dev, sizeof(*ts), GFP_KERNEL);
@@ -159,8 +158,7 @@ static int ts4800_ts_probe(struct platform_device *pdev)
if (error)
return error;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- ts->base = devm_ioremap_resource(&pdev->dev, res);
+ ts->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(ts->base))
return PTR_ERR(ts->base);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
[PATCH 1/5] Input: fsl-imx25-tcq: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource() and devm_ioremap_resource() in it. So instead of calling them separately use devm_platform_ioremap_resource() directly. Signed-off-by: Mukesh Ojha --- drivers/input/touchscreen/fsl-imx25-tcq.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c b/drivers/input/touchscreen/fsl-imx25-tcq.c index 1d6c8f4..b66df8a 100644 --- a/drivers/input/touchscreen/fsl-imx25-tcq.c +++ b/drivers/input/touchscreen/fsl-imx25-tcq.c @@ -503,7 +503,6 @@ static int mx25_tcq_probe(struct platform_device *pdev) struct input_dev *idev; struct mx25_tcq_priv *priv; struct mx25_tsadc *tsadc = dev_get_drvdata(dev->parent); - struct resource *res; void __iomem *mem; int error; @@ -512,8 +511,7 @@ static int mx25_tcq_probe(struct platform_device *pdev) return -ENOMEM; priv->dev = dev; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - mem = devm_ioremap_resource(dev, res); + mem = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(mem)) return PTR_ERR(mem); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 3/5] Input: s3c2410_ts: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
Signed-off-by: Mukesh Ojha
---
drivers/input/touchscreen/s3c2410_ts.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/input/touchscreen/s3c2410_ts.c
b/drivers/input/touchscreen/s3c2410_ts.c
index 1173890..e11cdae 100644
--- a/drivers/input/touchscreen/s3c2410_ts.c
+++ b/drivers/input/touchscreen/s3c2410_ts.c
@@ -242,7 +242,6 @@ static int s3c2410ts_probe(struct platform_device *pdev)
struct s3c2410_ts_mach_info *info;
struct device *dev = &pdev->dev;
struct input_dev *input_dev;
- struct resource *res;
int ret = -EINVAL;
/* Initialise input stuff */
@@ -277,14 +276,7 @@ static int s3c2410ts_probe(struct platform_device *pdev)
goto err_clk;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "no resource for registers\n");
- ret = -ENOENT;
- goto err_clk;
- }
-
- ts.io = ioremap(res->start, resource_size(res));
+ ts.io = devm_platform_ioremap_resource(pdev, 0);
if (ts.io == NULL) {
dev_err(dev, "cannot map registers\n");
ret = -ENOMEM;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
Re: [PATCH 1/2] mfd: cs47l35: Make DAC_AEC_CONTROL_2 readable
On Wed, 03 Apr 2019, Charles Keepax wrote: > From: Richard Fitzgerald > > There is a second AEC loopback on cs47l35 so the registers for it should > be readable. > > Signed-off-by: Richard Fitzgerald > Signed-off-by: Charles Keepax > --- > drivers/mfd/cs47l35-tables.c | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 0/7] irqchip: Use devm_platform_ioremap_resource()
Hi All, This is just a minor change to promote using of this api devm_platform_ioremap_resource() and nothing else functional change it does. Also, there are patches where only ioremap is used without requesting the mem region so this devm_platform_ioremap_resource() take cares all of that in single call. Mukesh Ojha (7): irqchip/irq-uniphier-aidet: Use devm_platform_ioremap_resource() irqchip/irq-imgpdc.c: Use devm_platform_ioremap_resource() irqchip/irq-ts4800.c: Use devm_platform_ioremap_resource() irqchip/irq-mbigen.c: Use devm_platform_ioremap_resource() irqchip/irq-mvebu-icu: Use devm_platform_ioremap_resource() irqchip/irq-mvebu-pic: Use devm_platform_ioremap_resource() irqchip/irq-mvebu-sei: Use devm_platform_ioremap_resource() drivers/irqchip/irq-imgpdc.c | 10 +- drivers/irqchip/irq-ls-scfg-msi.c| 4 +--- drivers/irqchip/irq-mbigen.c | 9 + drivers/irqchip/irq-mvebu-icu.c | 4 +--- drivers/irqchip/irq-mvebu-pic.c | 4 +--- drivers/irqchip/irq-mvebu-sei.c | 3 +-- drivers/irqchip/irq-ts4800.c | 4 +--- drivers/irqchip/irq-uniphier-aidet.c | 4 +--- 8 files changed, 8 insertions(+), 34 deletions(-) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/7] irqchip/irq-uniphier-aidet: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource() and devm_ioremap_resource() in it. So instead of calling them separately use devm_platform_ioremap_resource() directly. Signed-off-by: Mukesh Ojha --- drivers/irqchip/irq-uniphier-aidet.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-uniphier-aidet.c b/drivers/irqchip/irq-uniphier-aidet.c index 7ba7f25..1a77268 100644 --- a/drivers/irqchip/irq-uniphier-aidet.c +++ b/drivers/irqchip/irq-uniphier-aidet.c @@ -174,7 +174,6 @@ static int uniphier_aidet_probe(struct platform_device *pdev) struct device_node *parent_np; struct irq_domain *parent_domain; struct uniphier_aidet_priv *priv; - struct resource *res; parent_np = of_irq_find_parent(dev->of_node); if (!parent_np) @@ -189,8 +188,7 @@ static int uniphier_aidet_probe(struct platform_device *pdev) if (!priv) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - priv->reg_base = devm_ioremap_resource(dev, res); + priv->reg_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(priv->reg_base)) return PTR_ERR(priv->reg_base); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 5/7] irqchip/irq-mvebu-icu: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
Signed-off-by: Mukesh Ojha
---
drivers/irqchip/irq-mvebu-icu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-mvebu-icu.c b/drivers/irqchip/irq-mvebu-icu.c
index 547045d..a54e4cd 100644
--- a/drivers/irqchip/irq-mvebu-icu.c
+++ b/drivers/irqchip/irq-mvebu-icu.c
@@ -347,7 +347,6 @@ static int mvebu_icu_subset_probe(struct platform_device
*pdev)
static int mvebu_icu_probe(struct platform_device *pdev)
{
struct mvebu_icu *icu;
- struct resource *res;
int i;
icu = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_icu),
@@ -357,8 +356,7 @@ static int mvebu_icu_probe(struct platform_device *pdev)
icu->dev = &pdev->dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- icu->base = devm_ioremap_resource(&pdev->dev, res);
+ icu->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(icu->base)) {
dev_err(&pdev->dev, "Failed to map icu base address.\n");
return PTR_ERR(icu->base);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
[PATCH 7/7] irqchip/irq-mvebu-sei: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
Signed-off-by: Mukesh Ojha
---
drivers/irqchip/irq-mvebu-sei.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-mvebu-sei.c b/drivers/irqchip/irq-mvebu-sei.c
index 18832cc..0a09dcc 100644
--- a/drivers/irqchip/irq-mvebu-sei.c
+++ b/drivers/irqchip/irq-mvebu-sei.c
@@ -382,8 +382,7 @@ static int mvebu_sei_probe(struct platform_device *pdev)
mutex_init(&sei->cp_msi_lock);
raw_spin_lock_init(&sei->mask_lock);
- sei->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sei->base = devm_ioremap_resource(sei->dev, sei->res);
+ sei->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(sei->base)) {
dev_err(sei->dev, "Failed to remap SEI resource\n");
return PTR_ERR(sei->base);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
[PATCH 6/7] irqchip/irq-mvebu-pic: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource() and devm_ioremap_resource() in it. So instead of calling them separately use devm_platform_ioremap_resource() directly. Signed-off-by: Mukesh Ojha --- drivers/irqchip/irq-mvebu-pic.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-mvebu-pic.c b/drivers/irqchip/irq-mvebu-pic.c index eec6395..d6ade62 100644 --- a/drivers/irqchip/irq-mvebu-pic.c +++ b/drivers/irqchip/irq-mvebu-pic.c @@ -124,14 +124,12 @@ static int mvebu_pic_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; struct mvebu_pic *pic; struct irq_chip *irq_chip; - struct resource *res; pic = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_pic), GFP_KERNEL); if (!pic) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - pic->base = devm_ioremap_resource(&pdev->dev, res); + pic->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(pic->base)) return PTR_ERR(pic->base); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/7] irqchip/irq-imgpdc.c: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
Signed-off-by: Mukesh Ojha
---
drivers/irqchip/irq-imgpdc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/irqchip/irq-imgpdc.c b/drivers/irqchip/irq-imgpdc.c
index d00489a..8904a5f 100644
--- a/drivers/irqchip/irq-imgpdc.c
+++ b/drivers/irqchip/irq-imgpdc.c
@@ -307,13 +307,6 @@ static int pdc_intc_probe(struct platform_device *pdev)
if (!node)
return -ENOENT;
- /* Get registers */
- res_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res_regs == NULL) {
- dev_err(&pdev->dev, "cannot find registers resource\n");
- return -ENOENT;
- }
-
/* Allocate driver data */
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
@@ -324,8 +317,7 @@ static int pdc_intc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
/* Ioremap the registers */
- priv->pdc_base = devm_ioremap(&pdev->dev, res_regs->start,
- resource_size(res_regs));
+ priv->pdc_base = devm_platform_ioremap_resource(pdev, 0);
if (!priv->pdc_base)
return -EIO;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
[PATCH 4/7] irqchip/irq-mbigen.c: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
Signed-off-by: Mukesh Ojha
---
drivers/irqchip/irq-ls-scfg-msi.c | 4 +---
drivers/irqchip/irq-mbigen.c | 9 +
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/irqchip/irq-ls-scfg-msi.c
b/drivers/irqchip/irq-ls-scfg-msi.c
index c671b32..aec5a2f 100644
--- a/drivers/irqchip/irq-ls-scfg-msi.c
+++ b/drivers/irqchip/irq-ls-scfg-msi.c
@@ -336,7 +336,6 @@ static int ls_scfg_msi_probe(struct platform_device *pdev)
{
const struct of_device_id *match;
struct ls_scfg_msi *msi_data;
- struct resource *res;
int i, ret;
match = of_match_device(ls_scfg_msi_id, &pdev->dev);
@@ -349,8 +348,7 @@ static int ls_scfg_msi_probe(struct platform_device *pdev)
msi_data->cfg = (struct ls_scfg_msi_cfg *) match->data;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
+ msi_data->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(msi_data->regs)) {
dev_err(&pdev->dev, "failed to initialize 'regs'\n");
return PTR_ERR(msi_data->regs);
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 98b6e1d..c9aedfb 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -327,7 +327,6 @@ static inline int mbigen_acpi_create_domain(struct
platform_device *pdev,
static int mbigen_device_probe(struct platform_device *pdev)
{
struct mbigen_device *mgn_chip;
- struct resource *res;
int err;
mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
@@ -335,13 +334,7 @@ static int mbigen_device_probe(struct platform_device
*pdev)
return -ENOMEM;
mgn_chip->pdev = pdev;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -EINVAL;
-
- mgn_chip->base = devm_ioremap(&pdev->dev, res->start,
- resource_size(res));
+ mgn_chip->base = devm_platform_ioremap_resource(pdev, 0);
if (!mgn_chip->base) {
dev_err(&pdev->dev, "failed to ioremap %pR\n", res);
return -ENOMEM;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
[PATCH 3/7] irqchip/irq-ts4800.c: Use devm_platform_ioremap_resource()
devm_platform_ioremap_resource() internally have platform_get_resource() and devm_ioremap_resource() in it. So instead of calling them separately use devm_platform_ioremap_resource() directly. Signed-off-by: Mukesh Ojha --- drivers/irqchip/irq-ts4800.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-ts4800.c b/drivers/irqchip/irq-ts4800.c index 2325fb3..589a8a1 100644 --- a/drivers/irqchip/irq-ts4800.c +++ b/drivers/irqchip/irq-ts4800.c @@ -94,15 +94,13 @@ static int ts4800_ic_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; struct ts4800_irq_data *data; struct irq_chip *irq_chip; - struct resource *res; int parent_irq; data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - data->base = devm_ioremap_resource(&pdev->dev, res); + data->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(data->base)) return PTR_ERR(data->base); -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] staging: greybus: power_supply: Use struct_size() helper
On Thu, Apr 04, 2019 at 08:09:51AM +0100, Rui Miguel Silva wrote: > Hi Gustavo, > Thanks a lot for the patch. > > On Wed 03 Apr 2019 at 21:58, Gustavo A. R. Silva wrote: > > Make use of the struct_size() helper instead of an open-coded > > version > > in order to avoid any potential type mistakes, in particular in > > the > > context in which this code is being used. > > > > So, replace code of the following form: > > > > sizeof(*resp) + props_count * sizeof(struct > > gb_power_supply_props_desc) > > > > with: > > > > struct_size(resp, props, props_count) > > > > This code was detected with the help of Coccinelle. > > > > Signed-off-by: Gustavo A. R. Silva > > What are the odds of 2 people changing same code in greybus in > the same day :). Well, I only noticed the bug in the current code, when reviewing Gustavo's diff. ;) Johan
[PATCH] mm/gup.c: fix the wrong comments
When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own get_user_pages_fast(). In the following scenario, we will may meet the bug in the DMA case: . get_user_pages_fast(start,,, pages); .. sg_alloc_table_from_pages(, pages, ...); . The root cause is that sg_alloc_table_from_pages() requires the page order to keep the same as it used in the user space, but get_user_pages_fast() will mess it up. So change the comments, and make it more clear for the driver users. Signed-off-by: Huang Shijie --- mm/gup.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index 22acdd0f79ff..b810d15d4db9 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1129,10 +1129,6 @@ EXPORT_SYMBOL(get_user_pages_locked); * with: * * get_user_pages_unlocked(tsk, mm, ..., pages); - * - * It is functionally equivalent to get_user_pages_fast so - * get_user_pages_fast should be used instead if specific gup_flags - * (e.g. FOLL_FORCE) are not required. */ long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages, struct page **pages, unsigned int gup_flags) @@ -2147,6 +2143,10 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write, * If not successful, it will fall back to taking the lock and * calling get_user_pages(). * + * This function is different from the get_user_pages_unlocked(): + * The @pages may has different page order with the result + * got by get_user_pages_unlocked(). + * * Returns number of pages pinned. This may be fewer than the number * requested. If nr_pages is 0 or negative, returns 0. If no pages * were pinned, returns -errno. -- 2.17.1
Re: [PATCH v11 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
On Thu, Apr 04, 2019 at 07:54:52AM +0100, Lee Jones wrote: > On Thu, 04 Apr 2019, Vaittinen, Matti wrote: > > > Actually, now that I thik of it the right way to do this would have > > been the function pointer in parent data as was done in original patch > > set. HW-colleagues tend to re-use HW blocks, and we like to re-use our > > drivers. If the next PMIC from ROHM uses same RTC block but does not > > provide watchdog - then it is cleanest solution to fall back to > > function pointer and leave it to NULL when there is no WDT or when WDT > > is unused. Another option is to export dummy function - which is not so > > nice. > > I think the converse is true. > > Pointers to functions outside of a subsystem API context are generally > horrible. It's much nicer to call a function which can be easily > stubbed out in a header file based on a Kconfig option. It's how most > kernel APIs work. I hate to admit but I see your point. This nicely solves any issues in syncronizing the startup for driver providing function pointer and for driver using it. > > Additional benefit from function pointer would have been that the > > function pointer can be only used by drivers which have acces to it. > > This exported function is globally visible. The WDT disable/enable is > > very specific procedure and it actually would be nicer design to not > > have it visible globally. It is not intended to be used by anything > > else besides the WDT and RTC here. > > Why would anything else try to use it? > > There are 1000's of exported functions in the kernel. If it's > properly namespaced a consumer would have to purposely call it, which > if they really wanted to, they could do anyway. I don't really see > your point. I could still argue on this. It _is_ less obvous that an exported function is not meant to be publicly used than it is for function pointers. But as you say, this is not a strong enough point to see the trouble in synchronizing the WDT/RTC startup. > > But I can't say there will be PMIC with same RTC and no WDT coming from > > ROHM. Also, I am not terribly excited about the option of changing this > > back to function-pointer as I already removed the pointer from parent > > data and this changed parent data is already adapted to all sub drivers > > - so this is all just babbling. Maybe it is just my huge ego shouting > > there - 'I was right, I must have the final say'. > > No, a call-back function would be a back-step. You are probably right. > Ego or no ego, you're wrong. =:-D I'd rephrase that as "It's not that I am wrong, but you are right." =) > > As a side note, I already did submit v12 with other styling fixes but > > which left the WDT function in MFD. If you still see the WDT functions > > should be exported from WDT - then please ignore the v12. I'll do v13 > > at the afternoon (my time, which is only a bit after noon your time I > > guess) which will export these functions from WDT. (Well, I had to try > > once more :D) > > Please keep the WDT code in the WDT driver. Create a little stub for > the cases where the WDT driver is not enabled - job done. Yes Sir. Br, Matti Vaittinen -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Re: [PATCH v2 4/4] ARM: dts: at91-vinco: use SPDX-License-Identifier
Hi Alexandre, On mer., avril 03 2019, Alexandre Belloni wrote: > The X11 license text [1] is explicitly for the X Consortium and has a > couple of extra clauses. The MIT license text [2] is actually what the > current DT files claim. > > [1] https://spdx.org/licenses/X11.html > [2] https://spdx.org/licenses/MIT.html > > Signed-off-by: Alexandre Belloni Acked-by: Gregory CLEMENT Thanks, Gregory > --- > arch/arm/boot/dts/at91-vinco.dts | 39 +--- > 1 file changed, 1 insertion(+), 38 deletions(-) > > diff --git a/arch/arm/boot/dts/at91-vinco.dts > b/arch/arm/boot/dts/at91-vinco.dts > index 430277291e02..15050fdd479d 100644 > --- a/arch/arm/boot/dts/at91-vinco.dts > +++ b/arch/arm/boot/dts/at91-vinco.dts > @@ -1,47 +1,10 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > /* > * Device Tree file for VInCo platform > * > * Copyright (C) 2014 Atmel, > *2014 Nicolas Ferre > * 2015 Gregory CLEMENT > - * > - * This file is dual-licensed: you can use it either under the terms > - * of the GPL or the X11 license, at your option. Note that this dual > - * licensing only applies to this file, and not this project as a > - * whole. > - * > - * a) This file 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. > - * > - * This file 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. > - * > - * Or, alternatively, > - * > - * b) Permission is hereby granted, free of charge, to any person > - * obtaining a copy of this software and associated documentation > - * files (the "Software"), to deal in the Software without > - * restriction, including without limitation the rights to use, > - * copy, modify, merge, publish, distribute, sublicense, and/or > - * sell copies of the Software, and to permit persons to whom the > - * Software is furnished to do so, subject to the following > - * conditions: > - * > - * The above copyright notice and this permission notice shall be > - * included in all copies or substantial portions of the Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > - * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > - * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > */ > /dts-v1/; > #include "sama5d4.dtsi" > -- > 2.20.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com
Re: [PATCH] mm: __pagevec_lru_add_fn: typo fix
On 4/2/2019 3:13 PM, Peng Fan wrote: There is no function named munlock_vma_pages, correct it to munlock_vma_page. Signed-off-by: Peng Fan Reviewed-by: Mukesh Ojha Cheers, -Mukesh --- mm/swap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/swap.c b/mm/swap.c index 301ed4e04320..3a75722e68a9 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -867,7 +867,7 @@ static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec, SetPageLRU(page); /* * Page becomes evictable in two ways: -* 1) Within LRU lock [munlock_vma_pages() and __munlock_pagevec()]. +* 1) Within LRU lock [munlock_vma_page() and __munlock_pagevec()]. * 2) Before acquiring LRU lock to put the page to correct LRU and then * a) do PageLRU check with lock [check_move_unevictable_pages] * b) do PageLRU check before lock [clear_page_mlock]
[RFC PATCH] media: cec: DRM connector to CEC dev mapping
This patch proposes to introduce explicit mapping between DRM connectors
and /dev/cecX adapters.
This is achieved here by adding a new structure with connector info
(DRM card number and connector id) to cec_adapter. That connector info
is expected to be set either by a code creating an adapter or trough
a CEC notifier (which is extended for that purpose).
A new ioctl, exposing connector info to userland, is added to /dev/cec.
New CEC event type is also added. That event is to notify an application
that the info about mapping between an adapter and a DRM connector was
just set.
Signed-off-by: Dariusz Marcinkiewicz
---
Notes:
Sending the patch in its current form the get feedback if that is
considered a right approach or if some other way of learning
the mapping in userland is preferred.
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_cec.c | 20
drivers/gpu/drm/i915/intel_dp.c | 4 +-
drivers/gpu/drm/i915/intel_hdmi.c | 7 ++-
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +-
drivers/media/cec/cec-adap.c | 21 -
drivers/media/cec/cec-api.c | 17 +++
drivers/media/cec/cec-core.c | 12 -
drivers/media/cec/cec-notifier.c | 47 ---
include/drm/drm_dp_helper.h | 14 +++---
include/media/cec-notifier.h | 31 ++--
include/media/cec.h | 13 -
include/uapi/linux/cec.h | 18 +++
13 files changed, 172 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index c4ea3a91f17aa..41678df654cdc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -379,7 +379,7 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_aux_register(&aconnector->dm_dp_aux.aux);
drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
- aconnector->base.name, dm->adev->dev);
+ &aconnector->base);
aconnector->mst_mgr.cbs = &dm_mst_cbs;
drm_dp_mst_topology_mgr_init(
&aconnector->mst_mgr,
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index b15cee85b702b..cb09bb2197a85 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -8,7 +8,9 @@
#include
#include
#include
+#include
#include
+#include
#include
/*
@@ -295,6 +297,7 @@ static void drm_dp_cec_unregister_work(struct work_struct
*work)
*/
void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
{
+ struct drm_connector *connector = aux->cec.connector;
u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
unsigned int num_las = 1;
u8 cap;
@@ -344,16 +347,19 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
/* Create a new adapter */
aux->cec.adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
-aux, aux->cec.name, cec_caps,
+aux, connector->name, cec_caps,
num_las);
if (IS_ERR(aux->cec.adap)) {
aux->cec.adap = NULL;
goto unlock;
}
- if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
+ if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
cec_delete_adapter(aux->cec.adap);
aux->cec.adap = NULL;
} else {
+ cec_s_connector_info(aux->cec.adap,
+connector->dev->primary->index,
+connector->base.id);
/*
* Update the phys addr for the new CEC adapter. When called
* from drm_dp_cec_register_connector() edid == NULL, so in
@@ -406,22 +412,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
/**
* drm_dp_cec_register_connector() - register a new connector
* @aux: DisplayPort AUX channel
- * @name: name of the CEC device
- * @parent: parent device
+ * @connector: drm connector
*
* A new connector was registered with associated CEC adapter name and
* CEC adapter parent device. After registering the name and parent
* drm_dp_cec_set_edid() is called to check if the connector supports
* CEC and to register a CEC adapter if that is the case.
*/
-void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
- struct device *parent)
+void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
{
WARN_ON(aux-
Re: [PATCH v8 06/11] mfd: max77650: new core mfd driver
czw., 4 kwi 2019 o 09:15 Lee Jones napisał(a):
>
> On Wed, 03 Apr 2019, Bartosz Golaszewski wrote:
>
> > From: Bartosz Golaszewski
> >
> > Add the core mfd driver for max77650 PMIC. We define five sub-devices
> > for which the drivers will be added in subsequent patches.
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > drivers/mfd/Kconfig | 14 +++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/max77650.c | 234 +++
> > include/linux/mfd/max77650.h | 59 +
> > 4 files changed, 308 insertions(+)
> > create mode 100644 drivers/mfd/max77650.c
> > create mode 100644 include/linux/mfd/max77650.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 0ce2d8dfc5f1..ade04e124aa0 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -733,6 +733,20 @@ config MFD_MAX77620
> > provides common support for accessing the device; additional drivers
> > must be enabled in order to use the functionality of the device.
> >
> > +config MFD_MAX77650
> > + tristate "Maxim MAX77650/77651 PMIC Support"
> > + depends on I2C
> > + depends on OF || COMPILE_TEST
> > + select MFD_CORE
> > + select REGMAP_I2C
> > + help
> > + Say Y here to add support for Maxim Semiconductor MAX77650 and
> > + MAX77651 Power Management ICs. This is the core multifunction
> > + driver for interacting with the device. The module name is
> > + 'max77650'. Additional drivers can be enabled in order to use
> > + the following functionalities of the device: GPIO, regulator,
> > + charger, LED, onkey.
> > +
> > config MFD_MAX77686
> > tristate "Maxim Semiconductor MAX77686/802 PMIC Support"
> > depends on I2C
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index b4569ed7f3f3..5727d099c16f 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -155,6 +155,7 @@ obj-$(CONFIG_MFD_DA9150) += da9150-core.o
> >
> > obj-$(CONFIG_MFD_MAX14577) += max14577.o
> > obj-$(CONFIG_MFD_MAX77620) += max77620.o
> > +obj-$(CONFIG_MFD_MAX77650) += max77650.o
> > obj-$(CONFIG_MFD_MAX77686) += max77686.o
> > obj-$(CONFIG_MFD_MAX77693) += max77693.o
> > obj-$(CONFIG_MFD_MAX77843) += max77843.o
> > diff --git a/drivers/mfd/max77650.c b/drivers/mfd/max77650.c
> > new file mode 100644
> > index ..7a6c0a5cf602
> > --- /dev/null
> > +++ b/drivers/mfd/max77650.c
> > @@ -0,0 +1,234 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Copyright (C) 2018 BayLibre SAS
> > +// Author: Bartosz Golaszewski
> > +//
> > +// Core MFD driver for MAXIM 77650/77651 charger/power-supply.
> > +// Programming manual: https://pdfserv.maximintegrated.com/en/an/AN6428.pdf
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MAX77650_INT_GPI_F_MSK BIT(0)
> > +#define MAX77650_INT_GPI_R_MSK BIT(1)
> > +#define MAX77650_INT_GPI_MSK \
> > + (MAX77650_INT_GPI_F_MSK | MAX77650_INT_GPI_R_MSK)
> > +#define MAX77650_INT_nEN_F_MSK BIT(2)
> > +#define MAX77650_INT_nEN_R_MSK BIT(3)
> > +#define MAX77650_INT_TJAL1_R_MSK BIT(4)
> > +#define MAX77650_INT_TJAL2_R_MSK BIT(5)
> > +#define MAX77650_INT_DOD_R_MSK BIT(6)
> > +
> > +#define MAX77650_INT_THM_MSK BIT(0)
> > +#define MAX77650_INT_CHG_MSK BIT(1)
> > +#define MAX77650_INT_CHGIN_MSK BIT(2)
> > +#define MAX77650_INT_TJ_REG_MSK BIT(3)
> > +#define MAX77650_INT_CHGIN_CTRL_MSK BIT(4)
> > +#define MAX77650_INT_SYS_CTRL_MSKBIT(5)
> > +#define MAX77650_INT_SYS_CNFG_MSKBIT(6)
> > +
> > +#define MAX77650_INT_GLBL_OFFSET 0
> > +#define MAX77650_INT_CHG_OFFSET 1
> > +
> > +#define MAX77650_SBIA_LPM_MASK BIT(5)
> > +#define MAX77650_SBIA_LPM_DISABLED 0x00
> > +
> > +enum {
> > + MAX77650_INT_GPI,
> > + MAX77650_INT_nEN_F,
> > + MAX77650_INT_nEN_R,
> > + MAX77650_INT_TJAL1_R,
> > + MAX77650_INT_TJAL2_R,
> > + MAX77650_INT_DOD_R,
> > + MAX77650_INT_THM,
> > + MAX77650_INT_CHG,
> > + MAX77650_INT_CHGIN,
> > + MAX77650_INT_TJ_REG,
> > + MAX77650_INT_CHGIN_CTRL,
> > + MAX77650_INT_SYS_CTRL,
> > + MAX77650_INT_SYS_CNFG,
> > +};
> > +
> > +static const struct resource max77650_charger_resources[] = {
> > + DEFINE_RES_IRQ_NAMED(MAX77650_INT_CHG, "CHG"),
> > + DEFINE_RES_IRQ_NAMED(MAX77650_INT_CHGIN, "CHGIN"),
> > +};
> > +
> > +static const struct resource max77650_gpio_resources[] = {
> > + DEFINE_RES_IRQ_NAMED(MAX77650_INT_GPI, "GPI"),
> > +};
> > +
> > +static const struct resource max77650_onkey_resources[] = {
> > + DEFINE_RES_IRQ_NAMED(MAX77650_INT_nEN_F, "nEN_F"),
> > + DEFINE_RES_IRQ_NAMED(MAX77650_INT_nEN_R, "nEN_R"),
> > +};
> > +
> > +static const struct mfd_
Re: [PATCH v2 0/2] clk: sunxi-ng: H6 related clock fixes
On Wed, Apr 03, 2019 at 05:14:02PM +0200, Jernej Skrabec wrote: > During linux-next testing on Allwinner H6, I found several issues with > clock driver. This patch series fixes them. > > Patch 1 allows video and vpu related clocks to set parent rate. > Patch 2 adds a comment with short explanation why zero width check is > needed. Applied both, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH] genirq: Fix uninitialized request_mutex
When !CONFIG_SPARSE_IRQ, request_mutex of struct irq_desc won't
be initialiezed, it leads to system hung, fix it.
Fixes: 9114014cf4e6 ("genirq: Add mutex to irq desc to serialize
request/free_irq()")
Signed-off-by: Kefeng Wang
---
kernel/irq/irqdesc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 13539e12cd80..9f8a709337cf 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -558,6 +558,7 @@ int __init early_irq_init(void)
alloc_masks(&desc[i], node);
raw_spin_lock_init(&desc[i].lock);
lockdep_set_class(&desc[i].lock, &irq_desc_lock_class);
+ mutex_init(&desc[i].request_mutex);
desc_set_defaults(i, &desc[i], node, NULL, NULL);
}
return arch_early_irq_init();
--
2.20.1
Re: [PATCH net] trival: net: skbuff: fix comment in skbuff.h
On 4/3/2019 2:45 PM, linmiaohe wrote: From: Miaohe Lin It should be IPv6|UDP instead of IPv4|UDP for NETIF_F_IPV6_CSUM Signed-off-by: linmiaohe Reviewed-by: Mukesh Ojha Cheers, -Mukesh --- include/linux/skbuff.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 69b5538adcea..9683e00a5a79 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -71,7 +71,7 @@ * NETIF_F_IPV6_CSUM - Driver (device) is only able to checksum plain * TCP or UDP packets over IPv6. These are specifically * unencapsulated packets of the form IPv6|TCP or - * IPv4|UDP where the Next Header field in the IPv6 + * IPv6|UDP where the Next Header field in the IPv6 * header is either TCP or UDP. IPv6 extension headers * are not supported with this feature. This feature * cannot be set in features for a device with
Re: [PATCH v5 8/8] PCI: dwc: Do not write to MSI control registers if the platform doesn't use it
Hi Lorenzo, On 03/04/19 10:49 PM, Lorenzo Pieralisi wrote: > On Thu, Mar 21, 2019 at 03:29:27PM +0530, Kishon Vijay Abraham I wrote: >> Platforms which populate msi_host_init, has it's own MSI controller >> logic. Writing to MSI control registers on platforms which doesn't use >> Designware's MSI controller logic might have side effects. To >> be safe, do not write to MSI control registers if the platform uses >> it's own MSI controller logic instead of Designware's MSI controller >> logic. >> >> Signed-off-by: Kishon Vijay Abraham I >> --- >> .../pci/controller/dwc/pcie-designware-host.c | 24 ++- >> 1 file changed, 13 insertions(+), 11 deletions(-) > > This patch is needed regardless of the rest of the series, correct ? > A.k.a. it is fixing an issue already in the mainline. That's correct. Thanks Kishon
Re: [PATCH] sched: Document that RT task priorities are 1…99
On 2019-04-03, John Ogness wrote: > IMHO it is a bit crazy that userspace RT prio 99 maps to kernel prio > 0. This leaves a hole at kernel prio 99. Wouldn't it be better just to > map userspace RT prio 1-99 to kernel prio 99-1? FWIW, the current mapping: userspace kernel - -- rt 1...99 98...0 nice -20...+19100...139 has been in place since the introduction of Ingo's scalable scheduler: Author: linus1 Date: Sun Dec 16 12:00:00 2001 -0800 v2.5.1.9 -> v2.5.1.10 - Kai Germaschewski: ISDN updates - Al Viro: start moving buffer cache indexing to "struct - block_device *" - Greg KH: USB update - Russell King: fix up some ARM merge issues - Ingo Molnar: scalable scheduler With that commit, the then separate nice and rt_priority task_struct fields were combined to the new prio field, and thus the mapping was born. John Ogness
Re: [PATCH net-next] MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig
Hi Paul, The 04/03/2019 23:23, Paul Burton wrote: > External E-Mail > > > Hi Horatiu, > > On Wed, Apr 03, 2019 at 05:27:36PM +0200, Horatiu Vultur wrote: > > diff --git a/arch/mips/configs/generic/board-ocelot.config > > b/arch/mips/configs/generic/board-ocelot.config > > index f607888..3215741 100644 > > --- a/arch/mips/configs/generic/board-ocelot.config > > +++ b/arch/mips/configs/generic/board-ocelot.config > >% > > +# CONFIG_HID is not set > > +# CONFIG_USB_SUPPORT is not set > > +# CONFIG_VIRTIO_MENU is not set > > +# CONFIG_SCSI is not set > > Unfortunately this part won't work so well. If board-ocelot.config > disables these things, then what should happen if another board that's > also included in a generic kernel enables them? > > eg. if you run 'make ARCH=mips 32r2el_defconfig' then we merge all of > the following: > > board-boston.config enables USB > board-sead-3.config enables USB > board-ocelot.config disables USB I didn't think about this scenario, because I didn't expect that building a generic configuration will bring together all the board configurations. Anyway, I will send a new patch in which I will remove these configurations. > > These are mutually exclusive, and it seems that on my system we > currently end up disabling USB due to board-ocelot.config. That will of > course break USB support for Boston or SEAD-3 which are also supported > by the same kernel binary. In practice which one 'wins' will depend on > the order the files are listed by make's wildcard function - so far as > I'm aware that doesn't guarantee any particular order so if it ends up > depending on the order the filesystem lists the files or something like > that then configurations might even differ when used on different > machines. > > So to avoid that the best we can do is leave these enabled and the > general rule is that board-*.config files can only enable extra things, > not disable them. > > You might be tempted to disable the options in generic_defconfig & > update any board configs that actually need them to enable them, but > that doesn't work too well for things which are 'default y' because > kconfig then warns about the conflict between generic_defconfig & the > board config being merged with it. That applies to the first 3 of the > entries you disable, leaving only CONFIG_SCSI that could potentially be > dealt with that way... > > Thanks, > Paul > -- /Horatiu
Re: [PATCH V32 19/27] x86/mmiotrace: Lock down the testmmiotrace module
On Wed, 3 Apr 2019, Matthew Garrett wrote: > From: David Howells > > The testmmiotrace module shouldn't be permitted when the kernel is locked > down as it can be used to arbitrarily read and write MMIO space. This is > a runtime check rather than buildtime in order to allow configurations > where the same kernel may be run in both locked down or permissive modes > depending on local policy. > > Suggested-by: Thomas Gleixner > Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Thomas Gleixner
Re: [PATCH V32 11/27] x86: Lock down IO port access when the kernel is locked down
On Wed, 3 Apr 2019, Matthew Garrett wrote: > From: Matthew Garrett > > IO port access would permit users to gain access to PCI configuration > registers, which in turn (on a lot of hardware) give access to MMIO > register space. This would potentially permit root to trigger arbitrary > DMA, so lock it down by default. > > This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and > KDDISABIO console ioctls. > > Signed-off-by: Matthew Garrett > Signed-off-by: David Howells Reviewed-by: Thomas Gleixner
Re: [RFC PATCH 1/9] drivers: regulator: qcom_spmi: enable linear range info
On Thu, Apr 04, 2019 at 08:59:10AM +0200, Jorge Ramirez wrote: > > This doesn't build: > yeah, the SPMI regulator changes are still pending If you're sending patches that have dependencies on other series that are reviewed please call that out so people are aware. signature.asc Description: PGP signature
Re: [PATCH v1 02/12] ASoC: rockchip: pdm: using left justified store mode
On Wed, Apr 03, 2019 at 09:40:46PM +0800, Sugar Zhang wrote: > This patch set left justified store mode default. The changelog should really explain why you're doing this. signature.asc Description: PGP signature
Re: [PATCH 1/6 v3] ptrace: Remove maxargs from task_current_syscall()
On Mon, 1 Apr 2019, Steven Rostedt wrote: > From: "Steven Rostedt (Red Hat)" > > task_current_syscall() has a single user that passes in 6 for maxargs, which > is the maximum arguments that can be used to get system calls from > syscall_get_arguments(). Instead of passing in a number of arguments to > grab, just get 6 arguments. The args argument even specifies that it's an > array of 6 items. > > This will also allow changing syscall_get_arguments() to not get a variable > number of arguments, but always grab 6. > > Linus also suggested not passing in a bunch of arguments to > task_current_syscall() but to instead pass in a pointer to a structure, and > just fill the structure. struct seccomp_data has almost all the parameters > that is needed except for the stack pointer (sp). As seccomp_data is part of > uapi, and I'm afraid to change it, a new structure was created > "syscall_info", which includes seccomp_data and adds the "sp" field. > > Link: http://lkml.kernel.org/r/20161107213233.466776...@goodmis.org > > Cc: Thomas Gleixner > Cc: Andy Lutomirski > Cc: Alexey Dobriyan > Cc: Oleg Nesterov > Cc: Kees Cook > Cc: Al Viro > Cc: linux-fsde...@vger.kernel.org > Signed-off-by: Steven Rostedt (VMware) Reviewed-by: Thomas Gleixner
[PATCH][next] ASoC: sprd: Fix spelling mistake "faied" -> "failed"
From: Colin Ian King
There are two identical spelling mistakes in dev_err messages. Fix them.
Signed-off-by: Colin Ian King
---
sound/soc/sprd/sprd-pcm-compress.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sprd/sprd-pcm-compress.c
b/sound/soc/sprd/sprd-pcm-compress.c
index dc84257cffc2..e008525a6cb3 100644
--- a/sound/soc/sprd/sprd-pcm-compress.c
+++ b/sound/soc/sprd/sprd-pcm-compress.c
@@ -282,13 +282,13 @@ static int sprd_platform_compr_set_params(struct
snd_compr_stream *cstream,
*/
ret = sprd_platform_compr_dma_config(cstream, params, 1);
if (ret) {
- dev_err(dev, "faied to config stage 1 DMA: %d\n", ret);
+ dev_err(dev, "failed to config stage 1 DMA: %d\n", ret);
return ret;
}
ret = sprd_platform_compr_dma_config(cstream, params, 0);
if (ret) {
- dev_err(dev, "faied to config stage 0 DMA: %d\n", ret);
+ dev_err(dev, "failed to config stage 0 DMA: %d\n", ret);
goto config_err;
}
--
2.20.1
Re: [PATCH v11 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
On 04/04/2019 10:24:49+0300, Matti Vaittinen wrote: > On Thu, Apr 04, 2019 at 07:54:52AM +0100, Lee Jones wrote: > > On Thu, 04 Apr 2019, Vaittinen, Matti wrote: > > > > > Actually, now that I thik of it the right way to do this would have > > > been the function pointer in parent data as was done in original patch > > > set. HW-colleagues tend to re-use HW blocks, and we like to re-use our > > > drivers. If the next PMIC from ROHM uses same RTC block but does not > > > provide watchdog - then it is cleanest solution to fall back to > > > function pointer and leave it to NULL when there is no WDT or when WDT > > > is unused. Another option is to export dummy function - which is not so > > > nice. > > > > I think the converse is true. > > > > Pointers to functions outside of a subsystem API context are generally > > horrible. It's much nicer to call a function which can be easily > > stubbed out in a header file based on a Kconfig option. It's how most > > kernel APIs work. > > I hate to admit but I see your point. This nicely solves any issues in > syncronizing the startup for driver providing function pointer and for > driver using it. > Wouldn't it be easier to register the watchdog driver as part of the RTC driver? As I see it, the wdt is just a glorified RTC alarm. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3 05/13] thermal: qoriq: Embed per-sensor data into struct qoriq_tmu_data
On 01/04/2019 06:14, Andrey Smirnov wrote:
> Embed per-sensor data into struct qoriq_tmu_data so we can drop the
> code allocating it. This also allows us to get rid of per-sensor back
> reference to struct qoriq_tmu_data since now its address can be
> caluclated using container_of().
This seems to be a repeating pattern, drivers are forced to put a back
pointer in the thermal sensor structure to regain access to the
container structure in the get_temp callback.
It would make sense to pass the sensor id to the get_temp callback as we
register with the sensor id.
One comment below.
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Daniel Lezcano
> Cc: Angus Ainslie (Purism)
> Cc: linux-...@nxp.com
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/thermal/qoriq_thermal.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
> index e281bdcfa11f..deb5cb6a0baf 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -59,22 +59,24 @@ struct qoriq_tmu_regs {
> u32 ttr3cr; /* Temperature Range 3 Control Register */
> };
>
> -struct qoriq_tmu_data;
> -
> /*
> * Thermal zone data
> */
> struct qoriq_sensor {
> - struct qoriq_tmu_data *qdata;
> int id;
> };>
> struct qoriq_tmu_data {
> struct qoriq_tmu_regs __iomem *regs;
> bool little_endian;
Why not replace the little_endian boolean by a couple of callback
read/write and assign them to ioread32|ioread32be at init time.
That will kill the tmu_read and tmu_write functions and from there you
can figure out how to remove the qdata backpointer. In addition, it will
save a few instructions to test the boolean.
> - struct qoriq_sensor *sensor[SITES_MAX];
> + struct qoriq_sensor sensor[SITES_MAX];
>
> };
>
> +static struct qoriq_tmu_data *qoriq_sensor_to_data(struct qoriq_sensor *s)
> +{
> + return container_of(s, struct qoriq_tmu_data, sensor[s->id]);
> +}
> +
> static void tmu_write(struct qoriq_tmu_data *p, u32 val, void __iomem *addr)
> {
> if (p->little_endian)
> @@ -94,7 +96,7 @@ static u32 tmu_read(struct qoriq_tmu_data *p, void __iomem
> *addr)
> static int tmu_get_temp(void *p, int *temp)
> {
> struct qoriq_sensor *qsensor = p;
> - struct qoriq_tmu_data *qdata = qsensor->qdata;
> + struct qoriq_tmu_data *qdata = qoriq_sensor_to_data(qsensor);
> u32 val;
>
> val = tmu_read(qdata, &qdata->regs->site[qsensor->id].tritsr);
> @@ -114,15 +116,9 @@ static int qoriq_tmu_register_tmu_zone(struct
> platform_device *pdev)
>
> for (id = 0; id < SITES_MAX; id++) {
> struct thermal_zone_device *tzd;
> - struct qoriq_sensor *s;
> -
> - s = qdata->sensor[id] = devm_kzalloc(&pdev->dev,
> - sizeof(struct qoriq_sensor), GFP_KERNEL);
> - if (!qdata->sensor[id])
> - return -ENOMEM;
> + struct qoriq_sensor *s = &qdata->sensor[id];
>
> s->id = id;
> - s->qdata = qdata;
>
> tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, id,
> s, &tmu_tz_ops);
>
--
Facebook |
Twitter |
[PATCH][next] HID: intel-ish-hid: fix spelling mistake "multipe" -> "multiple"
From: Colin Ian King
There is a spelling mistake in a dev_err message, fix it.
Signed-off-by: Colin Ian King
---
drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp-fw-loader.c
b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c
index e770e220bd73..22ba21457035 100644
--- a/drivers/hid/intel-ish-hid/ishtp-fw-loader.c
+++ b/drivers/hid/intel-ish-hid/ishtp-fw-loader.c
@@ -525,7 +525,7 @@ static int ish_query_loader_prop(struct ishtp_cl_data
*client_data,
if ((fw_info->ldr_capability.xfer_mode & LOADER_XFER_MODE_DIRECT_DMA) &&
(fw_info->ldr_capability.max_dma_buf_size % L1_CACHE_BYTES)) {
dev_err(cl_data_to_dev(client_data),
- "Shim firmware loader buffer size %d should be multipe
of cacheline\n",
+ "Shim firmware loader buffer size %d should be multiple
of cacheline\n",
fw_info->ldr_capability.max_dma_buf_size);
return -EINVAL;
}
--
2.20.1
Re: [PATCH] genirq: Fix uninitialized request_mutex
On 4/4/2019 1:15 PM, Kefeng Wang wrote:
When !CONFIG_SPARSE_IRQ, request_mutex of struct irq_desc won't
be initialiezed, it leads to system hung, fix it.
Fixes: 9114014cf4e6 ("genirq: Add mutex to irq desc to serialize
request/free_irq()")
Signed-off-by: Kefeng Wang
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
kernel/irq/irqdesc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 13539e12cd80..9f8a709337cf 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -558,6 +558,7 @@ int __init early_irq_init(void)
alloc_masks(&desc[i], node);
raw_spin_lock_init(&desc[i].lock);
lockdep_set_class(&desc[i].lock, &irq_desc_lock_class);
+ mutex_init(&desc[i].request_mutex);
desc_set_defaults(i, &desc[i], node, NULL, NULL);
}
return arch_early_irq_init();
Re: [PATCH][next] ASoC: sprd: Fix spelling mistake "faied" -> "failed"
On 4/4/2019 1:26 PM, Colin King wrote:
From: Colin Ian King
There are two identical spelling mistakes in dev_err messages. Fix them.
Signed-off-by: Colin Ian King
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
sound/soc/sprd/sprd-pcm-compress.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sprd/sprd-pcm-compress.c
b/sound/soc/sprd/sprd-pcm-compress.c
index dc84257cffc2..e008525a6cb3 100644
--- a/sound/soc/sprd/sprd-pcm-compress.c
+++ b/sound/soc/sprd/sprd-pcm-compress.c
@@ -282,13 +282,13 @@ static int sprd_platform_compr_set_params(struct
snd_compr_stream *cstream,
*/
ret = sprd_platform_compr_dma_config(cstream, params, 1);
if (ret) {
- dev_err(dev, "faied to config stage 1 DMA: %d\n", ret);
+ dev_err(dev, "failed to config stage 1 DMA: %d\n", ret);
return ret;
}
ret = sprd_platform_compr_dma_config(cstream, params, 0);
if (ret) {
- dev_err(dev, "faied to config stage 0 DMA: %d\n", ret);
+ dev_err(dev, "failed to config stage 0 DMA: %d\n", ret);
goto config_err;
}
Re: [RFC PATCH v2 14/14] dcache: Implement object migration
On Wed, Apr 3, 2019 at 9:05 PM Al Viro wrote:
>
> On Wed, Apr 03, 2019 at 07:24:54PM +0100, Al Viro wrote:
>
> > If by "how to do it right" you mean "expedit kicking out something with
> > non-zero refcount" - there's no way to do that. Nothing even remotely
> > sane.
> >
> > If you mean "kick out everything in this page with zero refcount" - that
> > can be done (see further in the thread).
> >
> > Look, dentries and inodes are really, really not relocatable. If they
> > can be evicted by memory pressure - sure, we can do that for a given
> > set (e.g. "everything in that page"). But that's it - if memory
> > pressure would _not_ get rid of that one, there's nothing to be done.
> > Again, all VM can do is to simulate shrinker hitting hard on given
> > bunch (rather than buggering the entire cache). If filesystem (or
> > something in VFS) says "it's busy", it bloody well _is_ busy and
> > won't be going away until it ceases to be such.
>
> FWIW, some theory: the only kind of long-term reference that can
> be killed off by memory pressure is that from child to parent.
> Anything else (e.g. an opened file, current directory, mountpoint,
> etc.) is out of limits - it either won't be going away until
> the thing is not pinned anymore (close, chdir, etc.) *or*
> it really shouldn't be ("VM wants this mountpoint dentry freed,
> so just dissolve the mount" is a bloody bad idea for obvious
> reasons).
Well, theoretically we could do two levels of references, where the
long term reference is stable and contains an rcu protected unstable
reference to the real object. In the likely case when only read-only
access to the object is needed (d_lookup) then the cost is an extra
dereference and the associated additional cache usage. If read-write
access is needed to object, then extra locking is needed to protect
against concurrent migration. So there's non-trivial cost in addition
to the added complexity, and I don't see it actually making sense in
practice. But maybe someone can expand this idea to something
practicable...
Thanks,
Miklos
[PATCH] iio: accell: mma8452: free iio trigger pointer when cleanup
When mma8452 is built as module, once it is insmod and rmmod, below
kernel dump will show out, the root cause is module being put twice
if iio trigger pointer is NOT NULL, this patch frees iio trigger
pointer after iio trigger is unregistered to avoid below kernel
dump:
[ cut here ]
WARNING: CPU: 3 PID: 270 at kernel/module.c:1145 module_put+0xd0/0x188
Modules linked in: mma8452(-)
CPU: 3 PID: 270 Comm: rmmod Not tainted
5.1.0-rc3-next-20190403-00022-g5ede0c9-dirty #1596
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xd8/0x10c)
[] (dump_stack) from [] (__warn+0xf8/0x124)
[] (__warn) from [] (warn_slowpath_null+0x3c/0x48)
[] (warn_slowpath_null) from [] (module_put+0xd0/0x188)
[] (module_put) from []
(iio_device_unregister_trigger_consumer+0x18/0x24)
[] (iio_device_unregister_trigger_consumer) from []
(iio_dev_release+0x20/0)
[] (iio_dev_release) from [] (device_release+0x24/0x8c)
[] (device_release) from [] (kobject_put+0x74/0xd4)
[] (kobject_put) from [] (release_nodes+0x16c/0x1f0)
[] (release_nodes) from []
(device_release_driver_internal+0xec/0x1a0)
[] (device_release_driver_internal) from []
(driver_detach+0x44/0x80)
[] (driver_detach) from [] (bus_remove_driver+0x4c/0xa0)
[] (bus_remove_driver) from []
(sys_delete_module+0x130/0x1dc)
[] (sys_delete_module) from [] (ret_fast_syscall+0x0/0x28)
Exception stack(0xe8d87fa8 to 0xe8d87ff0)
7fa0: 0001ffc0 38616d6d be87bbf0 0880 be87be98
7fc0: 0001ffc0 38616d6d 00323534 0081 000a9744 be87bf81 000a9790
7fe0: be87bbe8 be87bbd8 0001fe18 b6e381a0
irq event stamp: 4017
hardirqs last enabled at (4035): [] console_unlock+0x400/0x630
hardirqs last disabled at (4052): [] console_unlock+0x80/0x630
softirqs last enabled at (4050): [] __do_softirq+0x458/0x554
softirqs last disabled at (4069): [] irq_exit+0x130/0x180
---[ end trace a7ba8f1823b1e073 ]---
Signed-off-by: Anson Huang
---
drivers/iio/accel/mma8452.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 3027811..6b18177 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1475,8 +1475,10 @@ static int mma8452_trigger_setup(struct iio_dev
*indio_dev)
static void mma8452_trigger_cleanup(struct iio_dev *indio_dev)
{
- if (indio_dev->trig)
+ if (indio_dev->trig) {
iio_trigger_unregister(indio_dev->trig);
+ indio_dev->trig = NULL;
+ }
}
static int mma8452_reset(struct i2c_client *client)
--
2.7.4
Re: [PATCH][next] ASoC: sprd: Fix spelling mistake "faied" -> "failed"
On Thu, 4 Apr 2019 at 15:56, Colin King wrote: > > From: Colin Ian King > > There are two identical spelling mistakes in dev_err messages. Fix them. > > Signed-off-by: Colin Ian King Thanks for fixing my mistakes. Reviewed-by: Baolin Wang -- Baolin Wang Best Regards
Re: [PATCH v11 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
> > > ROHM. Also, I am not terribly excited about the option of changing this > > > back to function-pointer as I already removed the pointer from parent > > > data and this changed parent data is already adapted to all sub drivers > > > - so this is all just babbling. Maybe it is just my huge ego shouting > > > there - 'I was right, I must have the final say'. > > > > No, a call-back function would be a back-step. > > You are probably right. > > > Ego or no ego, you're wrong. =:-D > > I'd rephrase that as "It's not that I am wrong, but you are right." =) Works for me. > > > As a side note, I already did submit v12 with other styling fixes but > > > which left the WDT function in MFD. If you still see the WDT functions > > > should be exported from WDT - then please ignore the v12. I'll do v13 > > > at the afternoon (my time, which is only a bit after noon your time I > > > guess) which will export these functions from WDT. (Well, I had to try > > > once more :D) > > > > Please keep the WDT code in the WDT driver. Create a little stub for > > the cases where the WDT driver is not enabled - job done. > > Yes Sir. =;-) -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH RFC 2/2] thermal/drivers/qoriq: Use the get_temp_id()
Currently the code is adding extra back pointer to find out the general
structure for the driver from the sensor data.
Use the get_temp_id() which pass the sensor id when registering the callback.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/qoriq_thermal.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 3b5f5b3fb1bc..405d1fbdd0cb 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -92,20 +92,20 @@ static u32 tmu_read(struct qoriq_tmu_data *p, void __iomem
*addr)
return ioread32be(addr);
}
-static int tmu_get_temp(void *p, int *temp)
+static int tmu_get_temp(int id, void *p, int *temp)
{
struct qoriq_sensor *qsensor = p;
struct qoriq_tmu_data *qdata = qsensor->qdata;
u32 val;
- val = tmu_read(qdata, &qdata->regs->site[qsensor->id].tritsr);
+ val = tmu_read(qdata, &qdata->regs->site[id].tritsr);
*temp = (val & 0xff) * 1000;
return 0;
}
static const struct thermal_zone_of_device_ops tmu_tz_ops = {
- .get_temp = tmu_get_temp,
+ .get_temp_id = tmu_get_temp,
};
static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
--
2.17.1
[PATCH RFC 1/2] thermal/drivers/of: Add a get_temp_id callback function
Currently when we register a sensor, we specify the sensor id and a data
pointer to be passed when the get_temp function is called. However the
sensor_id is not passed to the get_temp callback forcing the driver to
do extra allocation and adding back pointer to find out from the sensor
information the driver data and then back to the sensor id.
Add a new callback get_temp_id() which will be called if set. It will
call the get_temp_id() with the sensor id.
That will be more consistent with the registering function.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/of-thermal.c | 19 +--
include/linux/thermal.h | 1 +
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 2df059cc07e2..787d1cbe13f3 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -78,6 +78,8 @@ struct __thermal_zone {
/* sensor interface */
void *sensor_data;
+ int sensor_id;
+
const struct thermal_zone_of_device_ops *ops;
};
@@ -88,10 +90,14 @@ static int of_thermal_get_temp(struct thermal_zone_device
*tz,
{
struct __thermal_zone *data = tz->devdata;
- if (!data->ops->get_temp)
- return -EINVAL;
+ if (data->ops->get_temp)
+ return data->ops->get_temp(data->sensor_data, temp);
- return data->ops->get_temp(data->sensor_data, temp);
+ if (data->ops->get_temp_id)
+ return data->ops->get_temp_id(data->sensor_id,
+ data->sensor_data, temp);
+
+ return -EINVAL;
}
static int of_thermal_set_trips(struct thermal_zone_device *tz,
@@ -407,8 +413,8 @@ static struct thermal_zone_device_ops of_thermal_ops = {
/*** sensor API ***/
static struct thermal_zone_device *
-thermal_zone_of_add_sensor(struct device_node *zone,
- struct device_node *sensor, void *data,
+thermal_zone_of_add_sensor(struct device_node *zone, struct device_node
*sensor,
+ int sensor_id, void *data,
const struct thermal_zone_of_device_ops *ops)
{
struct thermal_zone_device *tzd;
@@ -426,6 +432,7 @@ thermal_zone_of_add_sensor(struct device_node *zone,
mutex_lock(&tzd->lock);
tz->ops = ops;
tz->sensor_data = data;
+ tz->sensor_id = sensor_id;
tzd->ops->get_temp = of_thermal_get_temp;
tzd->ops->get_trend = of_thermal_get_trend;
@@ -516,7 +523,7 @@ thermal_zone_of_sensor_register(struct device *dev, int
sensor_id, void *data,
}
if (sensor_specs.np == sensor_np && id == sensor_id) {
- tzd = thermal_zone_of_add_sensor(child, sensor_np,
+ tzd = thermal_zone_of_add_sensor(child, sensor_np,
sensor_id,
data, ops);
if (!IS_ERR(tzd))
tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 5f4705f46c2f..2762d7e6dd86 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -351,6 +351,7 @@ struct thermal_genl_event {
*hardware.
*/
struct thermal_zone_of_device_ops {
+ int (*get_temp_id)(int, void *, int *);
int (*get_temp)(void *, int *);
int (*get_trend)(void *, int, enum thermal_trend *);
int (*set_trips)(void *, int, int);
--
2.17.1
Re: [PATCH 2/2] mfd: cs47l90: Make DAC_AEC_CONTROL_2 readable
On Wed, 03 Apr 2019, Charles Keepax wrote: > From: Ajit Pandey > > There is a second AEC loopback on cs47l90 so the registers for it should > be readable. > > Signed-off-by: Ajit Pandey > Signed-off-by: Charles Keepax > --- > drivers/mfd/cs47l90-tables.c | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 06/13] thermal: qoriq: Pass data to qoriq_tmu_register_tmu_zone() directly
On 01/04/2019 06:14, Andrey Smirnov wrote:
> Pass all necessary data to qoriq_tmu_register_tmu_zone() directly
> instead of passing a paltform device and then deriving it. This is
> done as a first step to simplify resource deallocation code.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Daniel Lezcano
> Cc: Angus Ainslie (Purism)
> Cc: linux-...@nxp.com
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Acked-by: Daniel Lezcano
> ---
> drivers/thermal/qoriq_thermal.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
> index deb5cb6a0baf..24a2a57f61c9 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -109,9 +109,9 @@ static const struct thermal_zone_of_device_ops tmu_tz_ops
> = {
> .get_temp = tmu_get_temp,
> };
>
> -static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
> +static int qoriq_tmu_register_tmu_zone(struct device *dev,
> +struct qoriq_tmu_data *qdata)
> {
> - struct qoriq_tmu_data *qdata = platform_get_drvdata(pdev);
> int id, sites = 0;
>
> for (id = 0; id < SITES_MAX; id++) {
> @@ -120,7 +120,7 @@ static int qoriq_tmu_register_tmu_zone(struct
> platform_device *pdev)
>
> s->id = id;
>
> - tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, id,
> + tzd = devm_thermal_zone_of_sensor_register(dev, id,
> s, &tmu_tz_ops);
> if (IS_ERR(tzd)) {
> if (PTR_ERR(tzd) == -ENODEV)
> @@ -215,7 +215,7 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err_tmu;
>
> - ret = qoriq_tmu_register_tmu_zone(pdev);
> + ret = qoriq_tmu_register_tmu_zone(dev, data);
> if (ret < 0) {
> dev_err(dev, "Failed to register sensors\n");
> ret = -ENODEV;
>
--
Facebook |
Twitter |
Re: [PATCH v11 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Hello Alexandre, On Thu, 2019-04-04 at 09:56 +0200, Alexandre Belloni wrote: > On 04/04/2019 10:24:49+0300, Matti Vaittinen wrote: > > On Thu, Apr 04, 2019 at 07:54:52AM +0100, Lee Jones wrote: > > > On Thu, 04 Apr 2019, Vaittinen, Matti wrote: > > > > > > > Actually, now that I thik of it the right way to do this would > > > > have > > > > been the function pointer in parent data as was done in > > > > original patch > > > > set. HW-colleagues tend to re-use HW blocks, and we like to re- > > > > use our > > > > drivers. If the next PMIC from ROHM uses same RTC block but > > > > does not > > > > provide watchdog - then it is cleanest solution to fall back to > > > > function pointer and leave it to NULL when there is no WDT or > > > > when WDT > > > > is unused. Another option is to export dummy function - which > > > > is not so > > > > nice. > > > > > > I think the converse is true. > > > > > > Pointers to functions outside of a subsystem API context are > > > generally > > > horrible. It's much nicer to call a function which can be easily > > > stubbed out in a header file based on a Kconfig option. It's how > > > most > > > kernel APIs work. > > > > I hate to admit but I see your point. This nicely solves any issues > > in > > syncronizing the startup for driver providing function pointer and > > for > > driver using it. > > > > Wouldn't it be easier to register the watchdog driver as part of the > RTC > driver? > > As I see it, the wdt is just a glorified RTC alarm. Do you suggest me to put all the stuff now placed in drivers/watchdog/bd70528_wdt.c into rtc driver? It would be doable - but I'd rather kept the WDT independent module so that it can be left out of config if WDT needs not to be used. And same with RTC. Also, re- use of RTC driver in HW which does not include WDT is easier when WDT is a separate module. To me it looks much cleaner to have the WDT as own module than polluting the RTC driver with config ifdefs. But from HW perspective you are correct. The WDT in BD70528 seems to be kind of RTC alarm which shuts of the PMIC if triggered. Br, Matti Vaittinen
Re: [PATCH v3 07/13] thermal: qoriq: Pass data to qoriq_tmu_calibration() directly
On 01/04/2019 06:14, Andrey Smirnov wrote:
> We can simplify error cleanup code if instead of passing a "struct
> platform_device *" to qoriq_tmu_calibration() and deriving a bunch of
> pointers from it, we pass those pointers directly. This way we won't
> be force to call platform_set_drvdata() as early in qoriq_tmu_probe()
> and consequently would be able to drop the "err_iomap" error path.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Daniel Lezcano
> Cc: Angus Ainslie (Purism)
> Cc: linux-...@nxp.com
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/thermal/qoriq_thermal.c | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
> index 24a2a57f61c9..a3ddb55740e4 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -139,16 +139,16 @@ static int qoriq_tmu_register_tmu_zone(struct device
> *dev,
> return 0;
> }
>
> -static int qoriq_tmu_calibration(struct platform_device *pdev)
> +static int qoriq_tmu_calibration(struct device *dev,
> + struct qoriq_tmu_data *data)
> {
> int i, val, len;
> u32 range[4];
> const u32 *calibration;
> - struct device_node *np = pdev->dev.of_node;
> - struct qoriq_tmu_data *data = platform_get_drvdata(pdev);
> + struct device_node *np = dev->of_node;
>
> if (of_property_read_u32_array(np, "fsl,tmu-range", range, 4)) {
> - dev_err(&pdev->dev, "missing calibration range.\n");
> + dev_err(dev, "missing calibration range.\n");
> return -ENODEV;
> }
>
> @@ -160,7 +160,7 @@ static int qoriq_tmu_calibration(struct platform_device
> *pdev)
>
> calibration = of_get_property(np, "fsl,tmu-calibration", &len);
> if (calibration == NULL || len % 8) {
> - dev_err(&pdev->dev, "invalid calibration data.\n");
> + dev_err(dev, "invalid calibration data.\n");
> return -ENODEV;
> }
>
> @@ -198,20 +198,17 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
> if (!data)
> return -ENOMEM;
>
> - platform_set_drvdata(pdev, data);
> -
> data->little_endian = of_property_read_bool(np, "little-endian");
>
> data->regs = of_iomap(np, 0);
> if (!data->regs) {
> dev_err(dev, "Failed to get memory region\n");
> - ret = -ENODEV;
> - goto err_iomap;
> + return -ENODEV;
> }
>
> qoriq_tmu_init_device(data);/* TMU initialization */
>
> - ret = qoriq_tmu_calibration(pdev); /* TMU calibration */
> + ret = qoriq_tmu_calibration(dev, data); /* TMU calibration */
> if (ret < 0)
> goto err_tmu;
>
> @@ -222,14 +219,13 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
> goto err_iomap;
s/goto err_iomap/goto err_tmu/ ?
> }
>
> + platform_set_drvdata(pdev, data);
> +
> return 0;
>
> err_tmu:
> iounmap(data->regs);
>
> -err_iomap:
> - platform_set_drvdata(pdev, NULL);
> -
> return ret;
> }
>
>
--
Facebook |
Twitter |
[PATCH v2] driver core: platform: Propagate error from insert_resource()
Since insert_resource() might return an error we don't need
to shadow its error code and would safely propagate to the user.
Signed-off-by: Andy Shevchenko
---
- move an assignment to the separate line inside first branch (Rafael)
drivers/base/platform.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index dab0a5abc391..9cf9e2af9efd 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -438,10 +438,12 @@ int platform_device_add(struct platform_device *pdev)
p = &ioport_resource;
}
- if (p && insert_resource(p, r)) {
- dev_err(&pdev->dev, "failed to claim resource %d:
%pR\n", i, r);
- ret = -EBUSY;
- goto failed;
+ if (p) {
+ ret = insert_resource(p, r);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to claim resource
%d: %pR\n", i, r);
+ goto failed;
+ }
}
}
--
2.20.1
[PATCH] soundwire: cdns: Fix compilation error on arm64
On arm64 the cadence_master.c file doesn't compile. readl and writel are undefined. This patch fixes that by including io.h. Signed-off-by: Jan Kotas --- drivers/soundwire/cadence_master.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index cb6a331f4..0b5bcc209 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include -- 2.15.0
Re: [PATCH v2 2/2] mfd: cros_ec: Instantiate the CrOS USB PD logger driver
On Wed, 03 Apr 2019, Enric Balletbo i Serra wrote: > Add the cros-usbpd-logger driver for logging event data for the USB PD > charger available in the Embedded Controller on ChromeOS systems. The > logging feature is logically separate functionality from charge manager, > hence is instantiated as a different driver. > > Signed-off-by: Enric Balletbo i Serra > --- > Lee, this is send as separate patch because touches the MFD subsystem, > apart from that the driver won't be instantiated if [1/2] is not > merged, which I think is not a problem, it is safe for both go through > their subsystem separately. > > Thanks, > Enric > > Changes in v2: None > > drivers/mfd/cros_ec_dev.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] Documentation: bus: ti-sysc: fix spelling mistake "multipe" -> "multiple"
From: Colin Ian King There is a spelling mistake in the Documentation. Fix it. Signed-off-by: Colin Ian King --- Documentation/devicetree/bindings/bus/ti-sysc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt index 85a23f551f02..8eec4c384000 100644 --- a/Documentation/devicetree/bindings/bus/ti-sysc.txt +++ b/Documentation/devicetree/bindings/bus/ti-sysc.txt @@ -131,6 +131,6 @@ using offsets from l4_cfg second segment (0x4a00 + 0x8 = 0x4a0ab000): }; }; -Note that other SoCs, such as am335x can have multipe child devices. On am335x +Note that other SoCs, such as am335x can have multiple child devices. On am335x there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA instance as children of a single interconnet target module. -- 2.20.1
[RESEND][PATCH 0/3] DMA dts changes for hi3660
Here are a few dts changes which didn't get picked up for the last merge window to enable support for code changes that did land in v5.1. Let me know if you have any objecitons or feedback! thanks -john Cc: Tanglei Han Cc: Zhuangluan Su Cc: Ryan Grachek Cc: Manivannan Sadhasivam Cc: Wei Xu Cc: Rob Herring Cc: Mark Rutland Cc: linux-arm-ker...@lists.infradead.org Cc: devicet...@vger.kernel.org John Stultz (2): arm64: dts: hi3660: Add dma to uart nodes arm64: dts: hi3660: Fixup unofficial dma-min-chan to dma-channel-mask Youlin Wang (1): arm64: dts: hi3660: Add hisi asp dma device arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH] bpf:sample: fix field 'lock' has incomplete type in hbm.h
When compiling sample/bpf:
samples/bpf/hbm.h:12:23: error: field ‘lock’ has incomplete type
struct bpf_spin_lock lock;
Fixes: 187d0738ff35(bpf: Sample HBM BPF program to limit egress bw)
Signed-off-by: Bo YU
---
samples/bpf/hbm.h | 2 +-
samples/bpf/hbm_out_kern.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/samples/bpf/hbm.h b/samples/bpf/hbm.h
index 518e8147d084..7ce18cb9e365 100644
--- a/samples/bpf/hbm.h
+++ b/samples/bpf/hbm.h
@@ -9,7 +9,7 @@
* Include file for Host Bandwidth Management (HBM) programs
*/
struct hbm_vqueue {
- struct bpf_spin_lock lock;
+ struct bpf_spin_lock *lock;
/* 4 byte hole */
unsigned long long lasttime;/* In ns */
int credit; /* In bytes */
diff --git a/samples/bpf/hbm_out_kern.c b/samples/bpf/hbm_out_kern.c
index f806863d0b79..04c4f3d6ab9a 100644
--- a/samples/bpf/hbm_out_kern.c
+++ b/samples/bpf/hbm_out_kern.c
@@ -90,7 +90,7 @@ int _hbm_out_cg(struct __sk_buff *skb)
curtime = bpf_ktime_get_ns();
// Begin critical section
- bpf_spin_lock(&qdp->lock);
+ bpf_spin_lock(qdp->lock);
credit = qdp->credit;
delta = curtime - qdp->lasttime;
/* delta < 0 implies that another process with a curtime greater
@@ -105,7 +105,7 @@ int _hbm_out_cg(struct __sk_buff *skb)
}
credit -= len;
qdp->credit = credit;
- bpf_spin_unlock(&qdp->lock);
+ bpf_spin_unlock(qdp->lock);
// End critical section
// Check if we should update rate
--
2.11.0
Applied "ASoC: rockchip: pdm: Mark RXFIFO_DATA as volatile and precious" to the asoc tree
The patch
ASoC: rockchip: pdm: Mark RXFIFO_DATA as volatile and precious
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From b126fc07328749269021ac53173f9afdd6947248 Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Thu, 4 Apr 2019 11:57:08 +0800
Subject: [PATCH] ASoC: rockchip: pdm: Mark RXFIFO_DATA as volatile and
precious
This patch marks RXFIFO_DATA as precious to avoid being read
outside a call from the driver, such as regmap debugfs
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index 068453596470..6c0f242db5ef 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -417,6 +417,7 @@ static bool rockchip_pdm_rd_reg(struct device *dev,
unsigned int reg)
case PDM_INT_CLR:
case PDM_INT_ST:
case PDM_DATA_VALID:
+ case PDM_RXFIFO_DATA:
case PDM_VERSION:
return true;
default:
@@ -431,6 +432,17 @@ static bool rockchip_pdm_volatile_reg(struct device *dev,
unsigned int reg)
case PDM_FIFO_CTRL:
case PDM_INT_CLR:
case PDM_INT_ST:
+ case PDM_RXFIFO_DATA:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool rockchip_pdm_precious_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case PDM_RXFIFO_DATA:
return true;
default:
return false;
@@ -453,6 +465,7 @@ static const struct regmap_config
rockchip_pdm_regmap_config = {
.writeable_reg = rockchip_pdm_wr_reg,
.readable_reg = rockchip_pdm_rd_reg,
.volatile_reg = rockchip_pdm_volatile_reg,
+ .precious_reg = rockchip_pdm_precious_reg,
.cache_type = REGCACHE_FLAT,
};
--
2.20.1
Applied "ASoC: rockchip: pdm: add default regs" to the asoc tree
The patch
ASoC: rockchip: pdm: add default regs
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a7980cd212cef9002fe9683f440d27609d1aae37 Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Wed, 3 Apr 2019 21:40:47 +0800
Subject: [PATCH] ASoC: rockchip: pdm: add default regs
This patch add default regs value for controller.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index ba61a4b27d39..984d99889a65 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -361,11 +361,19 @@ static bool rockchip_pdm_volatile_reg(struct device *dev,
unsigned int reg)
}
}
+static const struct reg_default rockchip_pdm_reg_defaults[] = {
+ {0x04, 0x7817},
+ {0x08, 0x0bb8ea60},
+ {0x18, 0x001f},
+};
+
static const struct regmap_config rockchip_pdm_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.max_register = PDM_VERSION,
+ .reg_defaults = rockchip_pdm_reg_defaults,
+ .num_reg_defaults = ARRAY_SIZE(rockchip_pdm_reg_defaults),
.writeable_reg = rockchip_pdm_wr_reg,
.readable_reg = rockchip_pdm_rd_reg,
.volatile_reg = rockchip_pdm_volatile_reg,
--
2.20.1
Applied "ASoC: sprd: Fix spelling mistake "faied" -> "failed"" to the asoc tree
The patch
ASoC: sprd: Fix spelling mistake "faied" -> "failed"
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 47fa5773f11c7cc9117d74ea5a18a22502d8f0f3 Mon Sep 17 00:00:00 2001
From: Colin Ian King
Date: Thu, 4 Apr 2019 08:56:03 +0100
Subject: [PATCH] ASoC: sprd: Fix spelling mistake "faied" -> "failed"
There are two identical spelling mistakes in dev_err messages. Fix them.
Signed-off-by: Colin Ian King
Reviewed-by: Mukesh Ojha
Reviewed-by: Baolin Wang
Signed-off-by: Mark Brown
---
sound/soc/sprd/sprd-pcm-compress.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sprd/sprd-pcm-compress.c
b/sound/soc/sprd/sprd-pcm-compress.c
index 424e9834d093..6cddf551bc11 100644
--- a/sound/soc/sprd/sprd-pcm-compress.c
+++ b/sound/soc/sprd/sprd-pcm-compress.c
@@ -281,13 +281,13 @@ static int sprd_platform_compr_set_params(struct
snd_compr_stream *cstream,
*/
ret = sprd_platform_compr_dma_config(cstream, params, 1);
if (ret) {
- dev_err(dev, "faied to config stage 1 DMA: %d\n", ret);
+ dev_err(dev, "failed to config stage 1 DMA: %d\n", ret);
return ret;
}
ret = sprd_platform_compr_dma_config(cstream, params, 0);
if (ret) {
- dev_err(dev, "faied to config stage 0 DMA: %d\n", ret);
+ dev_err(dev, "failed to config stage 0 DMA: %d\n", ret);
goto config_err;
}
--
2.20.1
Applied "ASoC: rockchip: pdm: optimize clear logic" to the asoc tree
The patch
ASoC: rockchip: pdm: optimize clear logic
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 252163a66a06859f468ef1e00fa5a1f377b16eed Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Wed, 3 Apr 2019 21:40:48 +0800
Subject: [PATCH] ASoC: rockchip: pdm: optimize clear logic
There is no need to reset controller every time, do this
once in pdm_probe.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index 984d99889a65..eb5216dd7dbc 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -183,9 +183,6 @@ static int rockchip_pdm_hw_params(struct snd_pcm_substream
*substream,
val);
regmap_update_bits(pdm->regmap, PDM_DMA_CTRL, PDM_DMA_RDL_MSK,
PDM_DMA_RDL(16));
- regmap_update_bits(pdm->regmap, PDM_SYSCONFIG,
- PDM_RX_MASK | PDM_RX_CLR_MASK,
- PDM_RX_STOP | PDM_RX_CLR_WR);
}
return 0;
@@ -353,6 +350,7 @@ static bool rockchip_pdm_volatile_reg(struct device *dev,
unsigned int reg)
{
switch (reg) {
case PDM_SYSCONFIG:
+ case PDM_FIFO_CTRL:
case PDM_INT_CLR:
case PDM_INT_ST:
return true;
@@ -436,6 +434,7 @@ static int rockchip_pdm_probe(struct platform_device *pdev)
goto err_suspend;
}
+ rockchip_pdm_rxctrl(pdm, 0);
ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
if (ret) {
dev_err(&pdev->dev, "could not register pcm: %d\n", ret);
--
2.20.1
Applied "ASoC: rockchip: pdm: fix regmap_ops hang issue" to the asoc tree
The patch ASoC: rockchip: pdm: fix regmap_ops hang issue has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From c85064435fe7a216ec0f0238ef2b8f7cd850a450 Mon Sep 17 00:00:00 2001 From: Sugar Zhang Date: Wed, 3 Apr 2019 21:40:45 +0800 Subject: [PATCH] ASoC: rockchip: pdm: fix regmap_ops hang issue This is because set_fmt ops maybe called when PD is off, and in such case, regmap_ops will lead system hang. enale PD before doing regmap_ops. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown --- sound/soc/rockchip/rockchip_pdm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/rockchip/rockchip_pdm.c b/sound/soc/rockchip/rockchip_pdm.c index 400e29edb1c9..8a2e3bbce3a1 100644 --- a/sound/soc/rockchip/rockchip_pdm.c +++ b/sound/soc/rockchip/rockchip_pdm.c @@ -208,7 +208,9 @@ static int rockchip_pdm_set_fmt(struct snd_soc_dai *cpu_dai, return -EINVAL; } + pm_runtime_get_sync(cpu_dai->dev); regmap_update_bits(pdm->regmap, PDM_CLK_CTRL, mask, val); + pm_runtime_put(cpu_dai->dev); return 0; } -- 2.20.1
Applied "dt-bindings: sound: add compatible for rk1808" to the asoc tree
The patch dt-bindings: sound: add compatible for rk1808 has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 2a050b7a746e2c59a733a3641eb1c01cf2e573b4 Mon Sep 17 00:00:00 2001 From: Sugar Zhang Date: Thu, 4 Apr 2019 11:55:45 +0800 Subject: [PATCH] dt-bindings: sound: add compatible for rk1808 This patch adds bindings for rk1808 soc. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rockchip,pdm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/rockchip,pdm.txt b/Documentation/devicetree/bindings/sound/rockchip,pdm.txt index 3e0eb7354ba6..98572a25122f 100644 --- a/Documentation/devicetree/bindings/sound/rockchip,pdm.txt +++ b/Documentation/devicetree/bindings/sound/rockchip,pdm.txt @@ -4,6 +4,7 @@ Required properties: - compatible: "rockchip,pdm" - "rockchip,px30-pdm" + - "rockchip,rk1808-pdm" - "rockchip,rk3308-pdm" - reg: physical base address of the controller and length of memory mapped region. -- 2.20.1
Applied "ASoC: rockchip: pdm: change dma burst to 8" to the asoc tree
The patch
ASoC: rockchip: pdm: change dma burst to 8
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 86a7b6ffd90095d81d9fa0d8b48955b7c83b2e2f Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Thu, 4 Apr 2019 11:48:11 +0800
Subject: [PATCH] ASoC: rockchip: pdm: change dma burst to 8
This patch decreases the transfer bursts to avoid the fifo overrun.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index 8a2e3bbce3a1..d0b403a0e27b 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -24,7 +24,7 @@
#include "rockchip_pdm.h"
-#define PDM_DMA_BURST_SIZE (16) /* size * width: 16*4 = 64 bytes */
+#define PDM_DMA_BURST_SIZE (8) /* size * width: 8*4 = 32 bytes */
struct rk_pdm_dev {
struct device *dev;
--
2.20.1
Applied "ASoC: rockchip: pdm: adjust waterlevel in frame unit" to the asoc tree
The patch ASoC: rockchip: pdm: adjust waterlevel in frame unit has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 430f5da69b9323d5e7faca95bc30e61be4fcbbbf Mon Sep 17 00:00:00 2001 From: Sugar Zhang Date: Thu, 4 Apr 2019 11:56:29 +0800 Subject: [PATCH] ASoC: rockchip: pdm: adjust waterlevel in frame unit This patch make the waterlevel more reasonable, because the pdm controller share the single FIFO(128 entries) with each channel. adjust waterlevel in frame to meet the vad or dma frames request. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown --- sound/soc/rockchip/rockchip_pdm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/rockchip/rockchip_pdm.c b/sound/soc/rockchip/rockchip_pdm.c index 3e1c5fd5b32b..955cdc2b8fc5 100644 --- a/sound/soc/rockchip/rockchip_pdm.c +++ b/sound/soc/rockchip/rockchip_pdm.c @@ -255,8 +255,9 @@ static int rockchip_pdm_hw_params(struct snd_pcm_substream *substream, regmap_update_bits(pdm->regmap, PDM_CTRL0, PDM_PATH_MSK | PDM_VDW_MSK, val); + /* all channels share the single FIFO */ regmap_update_bits(pdm->regmap, PDM_DMA_CTRL, PDM_DMA_RDL_MSK, - PDM_DMA_RDL(16)); + PDM_DMA_RDL(8 * params_channels(params))); return 0; } -- 2.20.1
Applied "ASoC: rockchip: pdm: fixup pdm fractional div" to the asoc tree
The patch
ASoC: rockchip: pdm: fixup pdm fractional div
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 624e8e00acafe3d31a7c31e67fa95ce06e324bf8 Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Thu, 4 Apr 2019 11:51:09 +0800
Subject: [PATCH] ASoC: rockchip: pdm: fixup pdm fractional div
This patch adds support fractional div for rk3308.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 172 ++
sound/soc/rockchip/rockchip_pdm.h | 9 ++
2 files changed, 139 insertions(+), 42 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index c50494b0ed0d..4f93a7454e85 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -17,14 +17,23 @@
#include
#include
#include
+#include
#include
+#include
#include
+#include
#include
#include
#include "rockchip_pdm.h"
#define PDM_DMA_BURST_SIZE (8) /* size * width: 8*4 = 32 bytes */
+#define PDM_SIGNOFF_CLK_RATE (1)
+
+enum rk_pdm_version {
+ RK_PDM_RK3229,
+ RK_PDM_RK3308,
+};
struct rk_pdm_dev {
struct device *dev;
@@ -32,22 +41,51 @@ struct rk_pdm_dev {
struct clk *hclk;
struct regmap *regmap;
struct snd_dmaengine_dai_dma_data capture_dma_data;
+ struct reset_control *reset;
+ enum rk_pdm_version version;
};
struct rk_pdm_clkref {
unsigned int sr;
unsigned int clk;
+ unsigned int clk_out;
+};
+
+struct rk_pdm_ds_ratio {
+ unsigned int ratio;
+ unsigned int sr;
};
static struct rk_pdm_clkref clkref[] = {
- { 8000, 4096 },
- { 11025, 56448000 },
- { 12000, 6144 },
+ { 8000, 4096, 2048000 },
+ { 11025, 56448000, 2822400 },
+ { 12000, 6144, 3072000 },
+ { 8000, 98304000, 2048000 },
+ { 12000, 98304000, 3072000 },
+};
+
+static struct rk_pdm_ds_ratio ds_ratio[] = {
+ { 0, 192000 },
+ { 0, 176400 },
+ { 0, 128000 },
+ { 1, 96000 },
+ { 1, 88200 },
+ { 1, 64000 },
+ { 2, 48000 },
+ { 2, 44100 },
+ { 2, 32000 },
+ { 3, 24000 },
+ { 3, 22050 },
+ { 3, 16000 },
+ { 4, 12000 },
+ { 4, 11025 },
+ { 4, 8000 },
};
-static unsigned int get_pdm_clk(unsigned int sr)
+static unsigned int get_pdm_clk(struct rk_pdm_dev *pdm, unsigned int sr,
+ unsigned int *clk_src, unsigned int *clk_out)
{
- unsigned int i, count, clk, div;
+ unsigned int i, count, clk, div, rate;
clk = 0;
if (!sr)
@@ -59,14 +97,39 @@ static unsigned int get_pdm_clk(unsigned int sr)
continue;
div = sr / clkref[i].sr;
if ((div & (div - 1)) == 0) {
+ *clk_out = clkref[i].clk_out;
+ rate = clk_round_rate(pdm->clk, clkref[i].clk);
+ if (rate != clkref[i].clk)
+ continue;
clk = clkref[i].clk;
+ *clk_src = clkref[i].clk;
break;
}
}
+ if (!clk) {
+ clk = clk_round_rate(pdm->clk, PDM_SIGNOFF_CLK_RATE);
+ *clk_src = clk;
+ }
return clk;
}
+static unsigned int get_pdm_ds_ratio(unsigned int sr)
+{
+ unsigned int i, count, ratio;
+
+ ratio = 0;
+ if (!sr)
+ return ratio;
+
+ count = ARRAY_SIZE(ds_ratio);
+ for (i = 0; i < count; i++) {
+ if (sr == ds_ratio[i].sr)
+ ratio = ds_ratio[i].ratio;
+ }
+ return ratio;
+}
+
static inline struct rk_pdm_dev *to_info(struct snd_soc_dai *dai)
{
return snd_soc_dai_get_drvdata(dai);
@@ -95,40 +158,52 @@ static int rockchip_pdm_hw_params(struct snd_pcm_substream
*substream,
struct rk_pdm_dev *pdm = to_info(dai);
unsigned int val = 0;
unsigned int clk_rate, clk_div, samplerate;
+ unsigned int clk_src, clk_out;
+ unsigned long m, n;
+ bool chang
[RESEND][PATCH 1/3] arm64: dts: hi3660: Add dma to uart nodes
Try to add DMA support to the uart nodes following the assignments made in the dts from the victoria vendor kernel here: https://consumer.huawei.com/en/opensource/detail/?siteCode=worldwide&keywords=p10&fileType=openSourceSoftware&pageSize=10&curPage=1 Cc: Tanglei Han Cc: Zhuangluan Su Cc: Ryan Grachek Cc: Manivannan Sadhasivam Cc: Wei Xu Cc: Rob Herring Cc: Mark Rutland Cc: linux-arm-ker...@lists.infradead.org Cc: devicet...@vger.kernel.org Acked-by: Manivannan Sadhasivam Signed-off-by: John Stultz --- v3: * Remove dma enablment on uart0 which would use reserved channel 0 --- arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi index 1734675..37a997a 100644 --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi @@ -484,6 +484,8 @@ compatible = "arm,pl011", "arm,primecell"; reg = <0x0 0xfdf0 0x0 0x1000>; interrupts = ; + dma-names = "rx", "tx"; + dmas = <&dma0 2 &dma0 3>; clocks = <&crg_ctrl HI3660_CLK_GATE_UART1>, <&crg_ctrl HI3660_CLK_GATE_UART1>; clock-names = "uartclk", "apb_pclk"; @@ -496,6 +498,8 @@ compatible = "arm,pl011", "arm,primecell"; reg = <0x0 0xfdf03000 0x0 0x1000>; interrupts = ; + dma-names = "rx", "tx"; + dmas = <&dma0 4 &dma0 5>; clocks = <&crg_ctrl HI3660_CLK_GATE_UART2>, <&crg_ctrl HI3660_PCLK>; clock-names = "uartclk", "apb_pclk"; @@ -520,6 +524,8 @@ compatible = "arm,pl011", "arm,primecell"; reg = <0x0 0xfdf01000 0x0 0x1000>; interrupts = ; + dma-names = "rx", "tx"; + dmas = <&dma0 6 &dma0 7>; clocks = <&crg_ctrl HI3660_CLK_GATE_UART4>, <&crg_ctrl HI3660_CLK_GATE_UART4>; clock-names = "uartclk", "apb_pclk"; @@ -532,6 +538,8 @@ compatible = "arm,pl011", "arm,primecell"; reg = <0x0 0xfdf05000 0x0 0x1000>; interrupts = ; + dma-names = "rx", "tx"; + dmas = <&dma0 8 &dma0 9>; clocks = <&crg_ctrl HI3660_CLK_GATE_UART5>, <&crg_ctrl HI3660_CLK_GATE_UART5>; clock-names = "uartclk", "apb_pclk"; -- 2.7.4
Applied "ASoC: rockchip: pdm: add compatible for rk1808" to the asoc tree
The patch
ASoC: rockchip: pdm: add compatible for rk1808
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 717d97879b346d56fc47a6e3fe0ad44fea9949b2 Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Thu, 4 Apr 2019 11:54:30 +0800
Subject: [PATCH] ASoC: rockchip: pdm: add compatible for rk1808
This patch adds support for rk1808, the pdm controller
is the same as rk3308.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index 4f93a7454e85..3e1c5fd5b32b 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -457,6 +457,8 @@ static const struct of_device_id rockchip_pdm_match[] = {
{ .compatible = "rockchip,pdm", },
{ .compatible = "rockchip,px30-pdm",
.data = (void *)RK_PDM_RK3308 },
+ { .compatible = "rockchip,rk1808-pdm",
+ .data = (void *)RK_PDM_RK3308 },
{ .compatible = "rockchip,rk3308-pdm",
.data = (void *)RK_PDM_RK3308 },
{},
--
2.20.1
Applied "ASoC: rockchip: pdm: using left justified store mode" to the asoc tree
The patch
ASoC: rockchip: pdm: using left justified store mode
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From fb20de606316a446efdfb0f775a892f782165783 Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Wed, 3 Apr 2019 21:40:46 +0800
Subject: [PATCH] ASoC: rockchip: pdm: using left justified store mode
This patch set left justified store mode default.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 1 +
sound/soc/rockchip/rockchip_pdm.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index 400e29edb1c9..ba61a4b27d39 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -135,6 +135,7 @@ static int rockchip_pdm_hw_params(struct snd_pcm_substream
*substream,
regmap_update_bits(pdm->regmap, PDM_HPF_CTRL,
PDM_HPF_LE | PDM_HPF_RE, PDM_HPF_LE | PDM_HPF_RE);
regmap_update_bits(pdm->regmap, PDM_CLK_CTRL, PDM_CLK_EN, PDM_CLK_EN);
+ regmap_update_bits(pdm->regmap, PDM_CTRL0, PDM_MODE_MSK, PDM_MODE_LJ);
val = 0;
switch (params_format(params)) {
diff --git a/sound/soc/rockchip/rockchip_pdm.h
b/sound/soc/rockchip/rockchip_pdm.h
index 886b48d128fd..00a8fa187d22 100644
--- a/sound/soc/rockchip/rockchip_pdm.h
+++ b/sound/soc/rockchip/rockchip_pdm.h
@@ -42,6 +42,9 @@
/* PDM CTRL0 */
#define PDM_PATH_MSK (0xf << 27)
+#define PDM_MODE_MSK BIT(31)
+#define PDM_MODE_RJ0
+#define PDM_MODE_LJBIT(31)
#define PDM_PATH3_EN BIT(30)
#define PDM_PATH2_EN BIT(29)
#define PDM_PATH1_EN BIT(28)
--
2.20.1
Re: [PATCH 4/5] mfd: ti-lmu: Remove support for LM3697
On Mon, 25 Mar 2019, Dan Murphy wrote: > Remove support for the LM3697 from the ti-lmu Bit of an odd place to insert a line feed. > driver in favor of a dedicated LED driver. > > Signed-off-by: Dan Murphy > --- > drivers/leds/Kconfig| 2 +- > drivers/mfd/Kconfig | 2 +- > drivers/mfd/ti-lmu.c| 17 --- > include/linux/mfd/ti-lmu-register.h | 44 - > include/linux/mfd/ti-lmu.h | 1 - > 5 files changed, 2 insertions(+), 64 deletions(-) I'm fine with the patch. Can you edit drivers/leds/Kconfig as part of a separate patch please? Keeping this in sync with this change is not critical and would add a whole bunch of process which we can really do without. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 4/5] mfd: ti-lmu: Remove support for LM3697
On Thu, 04 Apr 2019, Lee Jones wrote: > On Mon, 25 Mar 2019, Dan Murphy wrote: > > > Remove support for the LM3697 from the ti-lmu > > Bit of an odd place to insert a line feed. > > > driver in favor of a dedicated LED driver. > > > > Signed-off-by: Dan Murphy > > --- > > drivers/leds/Kconfig| 2 +- > > drivers/mfd/Kconfig | 2 +- > > drivers/mfd/ti-lmu.c| 17 --- > > include/linux/mfd/ti-lmu-register.h | 44 - > > include/linux/mfd/ti-lmu.h | 1 - > > 5 files changed, 2 insertions(+), 64 deletions(-) > > I'm fine with the patch. > > Can you edit drivers/leds/Kconfig as part of a separate patch please? > Keeping this in sync with this change is not critical and would add a > whole bunch of process which we can really do without. BTW, please add my: For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Applied "dt-bindings: sound: rockchip: add compatible for rk3308/px30" to the asoc tree
The patch dt-bindings: sound: rockchip: add compatible for rk3308/px30 has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 6bfff707985fff14fa79c851e53f9630e76a4860 Mon Sep 17 00:00:00 2001 From: Sugar Zhang Date: Thu, 4 Apr 2019 11:53:15 +0800 Subject: [PATCH] dt-bindings: sound: rockchip: add compatible for rk3308/px30 This patch adds bindings for rk3308/px30. Signed-off-by: Sugar Zhang Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rockchip,pdm.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/rockchip,pdm.txt b/Documentation/devicetree/bindings/sound/rockchip,pdm.txt index 47f164fbd1d7..3e0eb7354ba6 100644 --- a/Documentation/devicetree/bindings/sound/rockchip,pdm.txt +++ b/Documentation/devicetree/bindings/sound/rockchip,pdm.txt @@ -3,6 +3,8 @@ Required properties: - compatible: "rockchip,pdm" + - "rockchip,px30-pdm" + - "rockchip,rk3308-pdm" - reg: physical base address of the controller and length of memory mapped region. - dmas: DMA specifiers for rx dma. See the DMA client binding, @@ -12,6 +14,8 @@ Required properties: - clock-names: should contain following: - "pdm_hclk": clock for PDM BUS - "pdm_clk" : clock for PDM controller +- resets: a list of phandle + reset-specifer paris, one for each entry in reset-names. +- reset-names: reset names, should include "pdm-m". - pinctrl-names: Must contain a "default" entry. - pinctrl-N: One property must exist for each entry in pinctrl-names. See ../pinctrl/pinctrl-bindings.txt -- 2.20.1
Applied "ASoC: rockchip: pdm: Correct PDM_CTRL0 reg value" to the asoc tree
The patch
ASoC: rockchip: pdm: Correct PDM_CTRL0 reg value
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 54cd97cfe02e9bb93db53e7cbfa9b672bf4a5ac8 Mon Sep 17 00:00:00 2001
From: Sugar Zhang
Date: Thu, 4 Apr 2019 11:57:57 +0800
Subject: [PATCH] ASoC: rockchip: pdm: Correct PDM_CTRL0 reg value
This patch fix the wrong reg value for rk322x/rk322xh,
cuz there is no STORE JUSTIFIED MODE on it.
on rk322x/rk322xh, the same bit means PDM_MODE/RESERVED,
if the bit is set to RESERVED, the controller will not work.
Signed-off-by: Sugar Zhang
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_pdm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_pdm.c
b/sound/soc/rockchip/rockchip_pdm.c
index 955cdc2b8fc5..068453596470 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -210,7 +210,9 @@ static int rockchip_pdm_hw_params(struct snd_pcm_substream
*substream,
regmap_update_bits(pdm->regmap, PDM_HPF_CTRL,
PDM_HPF_LE | PDM_HPF_RE, PDM_HPF_LE | PDM_HPF_RE);
regmap_update_bits(pdm->regmap, PDM_CLK_CTRL, PDM_CLK_EN, PDM_CLK_EN);
- regmap_update_bits(pdm->regmap, PDM_CTRL0, PDM_MODE_MSK, PDM_MODE_LJ);
+ if (pdm->version != RK_PDM_RK3229)
+ regmap_update_bits(pdm->regmap, PDM_CTRL0,
+ PDM_MODE_MSK, PDM_MODE_LJ);
val = 0;
switch (params_format(params)) {
@@ -455,7 +457,8 @@ static const struct regmap_config
rockchip_pdm_regmap_config = {
};
static const struct of_device_id rockchip_pdm_match[] = {
- { .compatible = "rockchip,pdm", },
+ { .compatible = "rockchip,pdm",
+ .data = (void *)RK_PDM_RK3229 },
{ .compatible = "rockchip,px30-pdm",
.data = (void *)RK_PDM_RK3308 },
{ .compatible = "rockchip,rk1808-pdm",
--
2.20.1
[RESEND][PATCH 2/3] arm64: dts: hi3660: Add hisi asp dma device
From: Youlin Wang
Add asp-dma device to hi3660 dts
Cc: Tanglei Han
Cc: Zhuangluan Su
Cc: Ryan Grachek
Cc: Manivannan Sadhasivam
Cc: Wei Xu
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Acked-by: Manivannan Sadhasivam
Signed-off-by: Youlin Wang
Signed-off-by: Tanglei Han
Signed-off-by: John Stultz
---
v2: Removed undocumented bindings
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 37a997a..7f92049 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -573,6 +573,16 @@
dma-type = "hi3660_dma";
};
+ asp_dmac: dma-controller@e804b000 {
+ compatible = "hisilicon,hisi-pcm-asp-dma-1.0";
+ reg = <0x0 0xe804b000 0x0 0x1000>;
+ #dma-cells = <1>;
+ dma-channels = <16>;
+ dma-requests = <32>;
+ interrupts = ;
+ interrupt-names = "asp_dma_irq";
+ };
+
rtc0: rtc@fff04000 {
compatible = "arm,pl031", "arm,primecell";
reg = <0x0 0Xfff04000 0x0 0x1000>;
--
2.7.4
[RESEND][PATCH 3/3] arm64: dts: hi3660: Fixup unofficial dma-min-chan to dma-channel-mask
A undocumented and unimplemented binding got into the hi3660 dtsi, and this switches that binding to the now documented one. Cc: Tanglei Han Cc: Zhuangluan Su Cc: Ryan Grachek Cc: Manivannan Sadhasivam Cc: Wei Xu Cc: Rob Herring Cc: Mark Rutland Cc: linux-arm-ker...@lists.infradead.org Cc: devicet...@vger.kernel.org Signed-off-by: John Stultz --- v3: Renamed to hisi-dma-avail-chan v4: Renamed to dma-channel-mask --- arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi index 7f92049..7a49aa9 100644 --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi @@ -566,7 +566,7 @@ #dma-cells = <1>; dma-channels = <16>; dma-requests = <32>; - dma-min-chan = <1>; + dma-channel-mask = <0xfffe>; interrupts = ; clocks = <&crg_ctrl HI3660_CLK_GATE_DMAC>; dma-no-cci; -- 2.7.4
Re: [PATCH 1/5] dt-bindings: mfd: Update the ramp up/down property
On Mon, 25 Mar 2019, Dan Murphy wrote:
> Modify the ramp-up/down property and add the property description
> to the binding.
This is the 'what', but where is the 'why'?
> Signed-off-by: Dan Murphy
> ---
> .../devicetree/bindings/mfd/ti-lmu.txt| 20 ---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> index 980394d701a7..d9d529de6dc1 100644
> --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> @@ -25,6 +25,12 @@ Required properties:
>
> Optional property:
>- enable-gpios: A GPIO specifier for hardware enable pin.
> + - ramp-up-ms: Current ramping from one brightness level to
> + the a higher brightness level.
> + Range from 2048 us - 117.44 s
> + - ramp-down-ms: Current ramping from one brightness level to
> + the a lower brightness level.
> + Range from 2048 us - 117.44 s
>
> Required node:
>- backlight: All LMU devices have backlight child nodes.
> @@ -90,7 +96,7 @@ lm3631@29 {
>
> lcd_bl {
> led-sources = <0 1>;
> - ramp-up-msec = <300>;
> + ramp-up-ms = <300>;
> };
> };
> };
> @@ -152,15 +158,15 @@ lm3633@36 {
> main {
> label = "main_lcd";
> led-sources = <1 2>;
> - ramp-up-msec = <500>;
> - ramp-down-msec = <500>;
> + ramp-up-ms = <500>;
> + ramp-down-ms = <500>;
> };
>
> front {
> label = "front_lcd";
> led-sources = <0>;
> - ramp-up-msec = <1000>;
> - ramp-down-msec = <0>;
> + ramp-up-ms = <1000>;
> + ramp-down-ms = <0>;
> };
> };
>
> @@ -212,8 +218,8 @@ lm3697@36 {
>
> lcd {
> led-sources = <0 1 2>;
> - ramp-up-msec = <200>;
> - ramp-down-msec = <200>;
> + ramp-up-ms = <200>;
> + ramp-down-ms = <200>;
> };
> };
>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH V2 net-next 04/12] net: hns3: return 0 and print warning when hit duplicate MAC
From: Peng Li
When set 2 same MAC to different function of one port, IMP
will return error as the later one may modify the origin one.
This will cause bond fail for 2 VFs of one port.
Driver just print warning and return 0 with this patch, so
if set same MAC address, it will return 0 but do not really
configure HW.
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
V2: fixes comments from Sergei Shtylyov
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index e742a05..f51e4c0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5962,8 +5962,11 @@ int hclge_add_uc_addr_common(struct hclge_vport *vport,
}
/* check if we just hit the duplicate */
- if (!ret)
- ret = -EINVAL;
+ if (!ret) {
+ dev_warn(&hdev->pdev->dev, "VF %d mac(%pM) exists\n",
+vport->vport_id, addr);
+ return 0;
+ }
dev_err(&hdev->pdev->dev,
"PF failed to add unicast entry(%pM) in the MAC table\n",
--
2.7.4
Re: [PATCH v11 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
On Thu, 04 Apr 2019, Vaittinen, Matti wrote: > Hello Alexandre, > > On Thu, 2019-04-04 at 09:56 +0200, Alexandre Belloni wrote: > > On 04/04/2019 10:24:49+0300, Matti Vaittinen wrote: > > > On Thu, Apr 04, 2019 at 07:54:52AM +0100, Lee Jones wrote: > > > > On Thu, 04 Apr 2019, Vaittinen, Matti wrote: > > > > > > > > > Actually, now that I thik of it the right way to do this would > > > > > have > > > > > been the function pointer in parent data as was done in > > > > > original patch > > > > > set. HW-colleagues tend to re-use HW blocks, and we like to re- > > > > > use our > > > > > drivers. If the next PMIC from ROHM uses same RTC block but > > > > > does not > > > > > provide watchdog - then it is cleanest solution to fall back to > > > > > function pointer and leave it to NULL when there is no WDT or > > > > > when WDT > > > > > is unused. Another option is to export dummy function - which > > > > > is not so > > > > > nice. > > > > > > > > I think the converse is true. > > > > > > > > Pointers to functions outside of a subsystem API context are > > > > generally > > > > horrible. It's much nicer to call a function which can be easily > > > > stubbed out in a header file based on a Kconfig option. It's how > > > > most > > > > kernel APIs work. > > > > > > I hate to admit but I see your point. This nicely solves any issues > > > in > > > syncronizing the startup for driver providing function pointer and > > > for > > > driver using it. > > > > > > > Wouldn't it be easier to register the watchdog driver as part of the > > RTC > > driver? > > > > As I see it, the wdt is just a glorified RTC alarm. > > Do you suggest me to put all the stuff now placed in > drivers/watchdog/bd70528_wdt.c into rtc driver? It would be doable - > but I'd rather kept the WDT independent module so that it can be left > out of config if WDT needs not to be used. And same with RTC. Also, re- > use of RTC driver in HW which does not include WDT is easier when WDT > is a separate module. To me it looks much cleaner to have the WDT as > own module than polluting the RTC driver with config ifdefs. I haven't looked at the code, but I agree with this in principle. I'm a firm believer of having functionality in the most appropriate subsystem. IMHO, if a device can be neatly split 9/10 it should be. > But from HW perspective you are correct. The WDT in BD70528 seems to be > kind of RTC alarm which shuts of the PMIC if triggered. > > Br, > Matti Vaittinen -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: Add support for Merrifield Basin Cove PMIC
On Thu, Apr 04, 2019 at 08:03:57AM +0100, Lee Jones wrote:
> On Thu, 04 Apr 2019, Lee Jones wrote:
> > On Tue, 02 Apr 2019, Andy Shevchenko wrote:
> > > On Tue, Apr 02, 2019 at 06:12:11AM +0100, Lee Jones wrote:
> > > > On Mon, 18 Mar 2019, Andy Shevchenko wrote:
> > > > > +static const struct mfd_cell bcove_dev[] = {
> > > > > + {
> > > > > + .name = "mrfld_bcove_pwrbtn",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[0],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_tmu",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[1],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_thermal",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[2],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_bcu",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[3],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_adc",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[4],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_charger",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[5],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_extcon",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[5],
> > > > > + }, {
> > > > > + .name = "mrfld_bcove_gpio",
> > > > > + .num_resources = 1,
> > > > > + .resources = &irq_level2_resources[6],
> > > > > + },
> > > > > + { .name = "mrfld_bcove_region", },
> > > > > +};
> > > > > + for (i = 0; i < ARRAY_SIZE(irq_level2_resources); i++) {
> > > > > + ret = platform_get_irq(pdev, i);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + irq_level2_resources[i].start = ret;
> > > > > + irq_level2_resources[i].end = ret;
> > > > > + }
> > > >
> > > > Although succinct, dragging values from one platform device into
> > > > another doesn't sound that neat.
> > >
> > > So, how to split resources given in one _physical_ multi-functional
> > > device to
> > > several of them? Isn't it what MFD framework for?
> > >
> > > Any other approach here? I'm all ears!
> >
> > From the child:
> >
> > platform_get_irq(dev->parent, CLIENT_ID);
So, instead of keeping a fragile approach in one driver, we will spread this
to all of them.
> If you set the .id of the cell properly you could do:
>
> platform_get_irq(dev->parent, dev->id);
This will bring a confuse, ID is used to form an instance name, for now
we don't have several instances of any of the devices from PMIC.
On top of above, some of the resources (one already, others might be a case in
the future) is split between two drivers, which would bring even more confusion
to the entire picture.
> > > > Also, since the ordering of the
> > > > devices is critical in this implementation, it also comes across as
> > > > fragile.
> > >
> > > How fragile? In ACPI we don't have IRQ labeling scheme. Index is used for
> > > that.
> > >
> > > > Any reason why ACPI can't register all of the child devices, or for
> > > > the child devices to obtain their IRQ directly from the tables?
> > >
> > > And how are we supposed to enumerated them taking into consideration
> > > single
> > > ACPI ID given?
> >
> > This question was a little whimsical, since I have no idea how the
> > ACPI tables you're working with are laid out.
There is one device node with several IRQ and other resources.
In pseudo code:
device node {
device ID,
IRQ 0,
IRQ 1,
...
MMIO 0,
...
}
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v3 08/13] thermal: qoriq: Convert driver to use devm_ioremap()
On 01/04/2019 06:14, Andrey Smirnov wrote:
> Convert driver to use devm_ioremap() to simplify memory deallocation
> and error handling code. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Daniel Lezcano
> Cc: Angus Ainslie (Purism)
> Cc: linux-...@nxp.com
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/thermal/qoriq_thermal.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
> index a3ddb55740e4..4f9a2543f9c3 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -192,6 +192,7 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
> struct qoriq_tmu_data *data;
> struct device_node *np = pdev->dev.of_node;
> struct device *dev = &pdev->dev;
> + struct resource *io;
>
> data = devm_kzalloc(dev, sizeof(struct qoriq_tmu_data),
> GFP_KERNEL);
> @@ -200,7 +201,13 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
>
> data->little_endian = of_property_read_bool(np, "little-endian");
>
> - data->regs = of_iomap(np, 0);
> + io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!io) {
> + dev_err(dev, "Failed to get memory region\n");
> + return -ENODEV;
> + }
> +
> + data->regs = devm_ioremap(dev, io->start, resource_size(io));
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
?
> if (!data->regs) {
> dev_err(dev, "Failed to get memory region\n");
> return -ENODEV;
> @@ -210,23 +217,17 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
>
> ret = qoriq_tmu_calibration(dev, data); /* TMU calibration */
> if (ret < 0)
> - goto err_tmu;
> + return ret;
>
> ret = qoriq_tmu_register_tmu_zone(dev, data);
> if (ret < 0) {
> dev_err(dev, "Failed to register sensors\n");
> - ret = -ENODEV;
> - goto err_iomap;
> + return -ENODEV;
> }
>
> platform_set_drvdata(pdev, data);
>
> return 0;
> -
> -err_tmu:
> - iounmap(data->regs);
> -
> - return ret;
> }
>
> static int qoriq_tmu_remove(struct platform_device *pdev)
> @@ -236,7 +237,6 @@ static int qoriq_tmu_remove(struct platform_device *pdev)
> /* Disable monitoring */
> tmu_write(data, TMR_DISABLE, &data->regs->tmr);
>
> - iounmap(data->regs);
> platform_set_drvdata(pdev, NULL);
>
> return 0;
>
--
Facebook |
Twitter |
Re: [PATCH v3 1/2] mfd: cros_ec: Add host_sleep_event_v1 command
On Wed, 03 Apr 2019, Evan Green wrote: > Introduce the command and response structures for the second revision > of the host sleep event. These structures are part of a new EC change > that enables detection of failure to enter S0ix. The EC waits a > kernel-specified timeout (or a default amount of time) for the S0_SLP > pin to change, and wakes the system if that change does not occur in > time. > > Signed-off-by: Evan Green > > --- > > Changes in v3: None > Changes in v2: > - Made unions anonymous > - Replaced reserved union members with a comment > > include/linux/mfd/cros_ec_commands.h | 57 > 1 file changed, 57 insertions(+) Always good to have some additional Chromium reviewers on patches touching this file. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/6] arm64/mm: Enable memory hot remove
On 04/03/2019 11:27 PM, Robin Murphy wrote: > On 03/04/2019 18:32, Logan Gunthorpe wrote: >> >> >> On 2019-04-02 10:30 p.m., Anshuman Khandual wrote: >>> Memory removal from an arch perspective involves tearing down two different >>> kernel based mappings i.e vmemmap and linear while releasing related page >>> table pages allocated for the physical memory range to be removed. >>> >>> Define a common kernel page table tear down helper remove_pagetable() which >>> can be used to unmap given kernel virtual address range. In effect it can >>> tear down both vmemap or kernel linear mappings. This new helper is called >>> from both vmemamp_free() and ___remove_pgd_mapping() during memory removal. >>> The argument 'direct' here identifies kernel linear mappings. >>> >>> Vmemmap mappings page table pages are allocated through sparse mem helper >>> functions like vmemmap_alloc_block() which does not cycle the pages through >>> pgtable_page_ctor() constructs. Hence while removing it skips corresponding >>> destructor construct pgtable_page_dtor(). >>> >>> While here update arch_add_mempory() to handle __add_pages() failures by >>> just unmapping recently added kernel linear mapping. Now enable memory hot >>> remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE. >>> >>> This implementation is overall inspired from kernel page table tear down >>> procedure on X86 architecture. >> >> I've been working on very similar things for RISC-V. In fact, I'm >> currently in progress on a very similar stripped down version of >> remove_pagetable(). (Though I'm fairly certain I've done a bunch of >> stuff wrong.) >> >> Would it be possible to move this work into common code that can be used >> by all arches? Seems like, to start, we should be able to support both >> arm64 and RISC-V... and maybe even x86 too. >> >> I'd be happy to help integrate and test such functions in RISC-V. I am more inclined towards consolidating remove_pagetable() across platforms like arm64 and RISC-V (probably others). But there are clear distinctions between user page table and kernel page table tear down process. > > Indeed, I had hoped we might be able to piggyback off generic code for this > anyway, > given that we have generic pagetable code which knows how to free process > pagetables, > and kernel pagetables are also pagetables. But there are differences. To list some * Freeing mapped and pagetable pages - Memory hot remove deals with both vmemmap and linear mappings - Selectively call pgtable_page_dtor() for linear mappings (arch specific) - Not actually freeing PTE|PMD|PUD mapped pages for linear mappings - Freeing mapped pages for vmemap mappings * TLB shootdown - User page table process uses mmu_gather mechanism for TLB flush - Kernel page table tear down can do with less TLB flush invocations - Dont have to care about flush deferral etc * THP and HugeTLB - Kernel page table tear down procedure does not have to understand THP or HugeTLB - Though it has to understand possible arch specific special block mappings - Specific kernel linear mappings on arm64 - PUD|PMD|CONT_PMD|CONT_PTE large page mappings - Specific vmemmap mappings on arm64 - PMD large or PTE mappings -User page table tear down procedure needs to understand THP and HugeTLB * Page table locking - Kernel procedure locks init_mm.page_table_lock while clearing an individual entry - Kernel procedure does not have to worry about mmap_sem * ZONE_DEVICE struct vmem_altmap - Kernel page table tear down procedure needs to accommodate 'struct vmem_altmap' when vmemmap mappings are created with pages allocated from 'struct vmem_altmap' (ZONE_DEVICE) rather than buddy allocator or memblock.
[PATCH] perf script: fix spelling mistake "multipe" -> "multiple"
From: Colin Ian King There is a spelling mistake in the Documentation. Fix it. Signed-off-by: Colin Ian King --- tools/perf/Documentation/perf-script.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Documentation/perf-script.txt b/tools/perf/Documentation/perf-script.txt index 9b0d04dd2a61..e84aba03fc25 100644 --- a/tools/perf/Documentation/perf-script.txt +++ b/tools/perf/Documentation/perf-script.txt @@ -360,7 +360,7 @@ include::itrace.txt[] stop time is not given (i.e, time string is 'x.y,') then analysis goes to end of file. - Also support time percent with multipe time range. Time string is + Also support time percent with multiple time range. Time string is 'a%/n,b%/m,...' or 'a%-b%,c%-%d,...'. For example: -- 2.20.1
Re: [PATCH v2] driver core: platform: Propagate error from insert_resource()
On Thu, Apr 4, 2019 at 10:12 AM Andy Shevchenko
wrote:
>
> Since insert_resource() might return an error we don't need
> to shadow its error code and would safely propagate to the user.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Rafael J. Wysocki
> ---
> - move an assignment to the separate line inside first branch (Rafael)
>
> drivers/base/platform.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index dab0a5abc391..9cf9e2af9efd 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -438,10 +438,12 @@ int platform_device_add(struct platform_device *pdev)
> p = &ioport_resource;
> }
>
> - if (p && insert_resource(p, r)) {
> - dev_err(&pdev->dev, "failed to claim resource %d:
> %pR\n", i, r);
> - ret = -EBUSY;
> - goto failed;
> + if (p) {
> + ret = insert_resource(p, r);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to claim resource
> %d: %pR\n", i, r);
> + goto failed;
> + }
> }
> }
>
> --
> 2.20.1
>
[PATCH v2] MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig
Some of the configuration were not selected by default anymore, therefore enable them again. Also remove some configs which are used for MSCC Ocelot. Signed-off-by: Horatiu Vultur --- arch/mips/configs/generic/board-ocelot.config | 8 1 file changed, 8 insertions(+) diff --git a/arch/mips/configs/generic/board-ocelot.config b/arch/mips/configs/generic/board-ocelot.config index f607888..184eb65 100644 --- a/arch/mips/configs/generic/board-ocelot.config +++ b/arch/mips/configs/generic/board-ocelot.config @@ -1,6 +1,10 @@ # require CONFIG_CPU_MIPS32_R2=y CONFIG_LEGACY_BOARD_OCELOT=y +CONFIG_FIT_IMAGE_FDT_OCELOT=y + +CONFIG_BRIDGE=y +CONFIG_GENERIC_PHY=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y @@ -19,6 +23,8 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_NETDEVICES=y +CONFIG_NET_SWITCHDEV=y +CONFIG_NET_DSA=y CONFIG_MSCC_OCELOT_SWITCH=y CONFIG_MSCC_OCELOT_SWITCH_OCELOT=y CONFIG_MDIO_MSCC_MIIM=y @@ -35,6 +41,8 @@ CONFIG_SPI_DESIGNWARE=y CONFIG_SPI_DW_MMIO=y CONFIG_SPI_SPIDEV=y +CONFIG_PINCTRL_OCELOT=y + CONFIG_GPIO_SYSFS=y CONFIG_POWER_RESET=y -- 2.7.4
[PATCH net-next] tcp: Ensure DCTCP reacts to losses
RFC8257 §3.5 explicitly states that DCTCP should "react to loss
episode in the same way that a conventional TCP".
This is also the behavior on MS Windows.
Currently, Linux DCTCP performs no ssthresh reduction when losses
are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
alpha to its maximal value if a RTO happens. This behavior
is sub-optimal for at least two reasons: i) it ignores losses
triggering fast retransmissions; and ii) it causes unnecessary large
cwnd reduction in the future if the loss was isolated as it resets
the historical term of DCTCP's alpha EWMA to its maximal value (i.e.,
denoting a total congestion). The second reason has an especially
noticeable effect when using DCTCP in high BDP environments, where
alpha normally stays at low values.
This patch replace the clamping of alpha by setting ssthresh to
half of cwnd for both fast retransmissions and RTOs, at most once
per RTT. To reflect the change, the dctcp_clamp_alpha_on_loss option
has been renamed to dctcp_halve_cwnd_on_loss.
The table below shows experimental results where we measured the
drop probability of a PIE AQM (not applying ECN marks) at a
bottleneck in the presence of a single TCP flow with either the
alpha-clamping option enabled or the cwnd halving proposed by this
patch. Results using reno or cubic are given for comparison.
| Link | RTT|Drop
TCP CC | speed | base+AQM | probability
==|=|==|
CUBIC | 40Mbps | 7+20ms |0.21%
RENO | | |0.19%
DCTCP-CLAMP-ALPHA | | | 25.80%
DCTCP-HALVE-CWND | | |0.22%
--|-|--|
CUBIC | 100Mbps | 7+20ms |0.03%
RENO | | |0.02%
DCTCP-CLAMP-ALPHA | | | 23.30%
DCTCP-HALVE-CWND | | |0.04%
--|-|--|
CUBIC | 800Mbps | 1+1ms |0.04%
RENO | | |0.05%
DCTCP-CLAMP-ALPHA | | | 18.70%
DCTCP-HALVE-CWND | | |0.06%
We see that, without halving its cwnd for all source of losses,
DCTCP drives the AQM to large drop probabilities in order to keep
the queue length under control (i.e., it repeatedly faces RTOs).
Instead, if DCTCP reacts to all source of losses, it can then be
controlled by the AQM using similar drop levels than cubic or reno.
Signed-off-by: Koen De Schepper
Signed-off-by: Olivier Tilmans
Cc: Bob Briscoe
Cc: Lawrence Brakmo
Cc: Florian Westphal
Cc: Daniel Borkmann
Cc: Yuchung Cheng
Cc: Neal Cardwell
Cc: Eric Dumazet
Cc: Andrew Shewmaker
Cc: Glenn Judd
---
net/ipv4/tcp_dctcp.c | 39 ++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/net/ipv4/tcp_dctcp.c b/net/ipv4/tcp_dctcp.c
index cd4814f7e962..60417243e7d7 100644
--- a/net/ipv4/tcp_dctcp.c
+++ b/net/ipv4/tcp_dctcp.c
@@ -67,10 +67,9 @@ static unsigned int dctcp_alpha_on_init __read_mostly =
DCTCP_MAX_ALPHA;
module_param(dctcp_alpha_on_init, uint, 0644);
MODULE_PARM_DESC(dctcp_alpha_on_init, "parameter for initial alpha value");
-static unsigned int dctcp_clamp_alpha_on_loss __read_mostly;
-module_param(dctcp_clamp_alpha_on_loss, uint, 0644);
-MODULE_PARM_DESC(dctcp_clamp_alpha_on_loss,
-"parameter for clamping alpha on loss");
+static unsigned int dctcp_halve_cwnd_on_loss __read_mostly;
+module_param(dctcp_halve_cwnd_on_loss, uint, 0644);
+MODULE_PARM_DESC(dctcp_halve_cwnd_on_loss, "halve cwnd in case of losses");
static struct tcp_congestion_ops dctcp_reno;
@@ -164,21 +163,23 @@ static void dctcp_update_alpha(struct sock *sk, u32 flags)
}
}
-static void dctcp_state(struct sock *sk, u8 new_state)
+static void dctcp_react_to_loss(struct sock *sk)
{
- if (dctcp_clamp_alpha_on_loss && new_state == TCP_CA_Loss) {
- struct dctcp *ca = inet_csk_ca(sk);
+ struct dctcp *ca = inet_csk_ca(sk);
+ struct tcp_sock *tp = tcp_sk(sk);
- /* If this extension is enabled, we clamp dctcp_alpha to
-* max on packet loss; the motivation is that dctcp_alpha
-* is an indicator to the extend of congestion and packet
-* loss is an indicator of extreme congestion; setting
-* this in practice turned out to be beneficial, and
-* effectively assumes total congestion which reduces the
-* window by half.
-*/
- ca->dctcp_alpha = DCTCP_MAX_ALPHA;
- }
+ ca->loss_cwnd = tp->snd_cwnd;
+ tp->snd_ssthresh = max(tp->snd_cwnd >> 1U, 2U);
+}
+
+static void dctcp_state(struct sock *sk, u8 new_state)
+{
+
Re: [PATCH v3 2/2] platform/chrome: Add support for v1 of host sleep event
On Wed, 03 Apr 2019, Evan Green wrote: > Add support in code for the new forms of the host sleep event. > Detects the presence of this version of the command at runtime, > and use whichever form the EC supports. At this time, always > request the default timeout, and only report the failing response > via a WARN_ONCE(). Future versions could accept the sleep parameter > from outside the driver, and return the response information to > usermode or elsewhere. > > Signed-off-by: Evan Green > > --- > > Changes in v3: > - Consolidated boolean logic for host_sleep_v1 (Guenter) > > Changes in v2: > - Removed unnecessary version assignment (Guenter) > - Changed WARN to WARN_ONCE (Guenter) > - Fixed C code to use anonymous unions > - insize is only bigger for resume events. > > drivers/mfd/cros_ec.c | 39 + > drivers/platform/chrome/cros_ec_proto.c | 6 > include/linux/mfd/cros_ec.h | 2 ++ > 3 files changed, 42 insertions(+), 5 deletions(-) Looks okay in principle. For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RFC][PATCH 15/16] sched: Trivial forced-newidle balancer
On Fri, Feb 22, 2019 at 12:42 AM Peter Zijlstra wrote:
>
> On Thu, Feb 21, 2019 at 04:19:46PM +, Valentin Schneider wrote:
> > Hi,
> >
> > On 18/02/2019 16:56, Peter Zijlstra wrote:
> > [...]
> > > +static bool try_steal_cookie(int this, int that)
> > > +{
> > > + struct rq *dst = cpu_rq(this), *src = cpu_rq(that);
> > > + struct task_struct *p;
> > > + unsigned long cookie;
> > > + bool success = false;
> > > +
> > > + local_irq_disable();
> > > + double_rq_lock(dst, src);
Here, should we check dst and src's rq status before lock their rq?
if src is idle, it could be in the progress of load balance already?
Thanks,
-Aubrey
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3e3162f..a1e0a6f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3861,6 +3861,13 @@ static bool try_steal_cookie(int this, int that)
unsigned long cookie;
bool success = false;
+ /*
+* Don't steal if src is idle or has only one runnable task,
+* or dst has more than one runnable task
+*/
+ if (src->nr_running <= 1 || unlikely(dst->nr_running >= 1))
+ return false;
+
local_irq_disable();
double_rq_lock(dst, src);
Re: [PATCH 4/6] mm/hotplug: Reorder arch_remove_memory() call in __remove_memory()
On 04/03/2019 02:47 PM, Michal Hocko wrote: > On Wed 03-04-19 10:00:04, Anshuman Khandual wrote: >> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs >> entries between memory block and node. It first checks pfn validity with >> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config >> (arm64 has this enabled) pfn_valid_within() calls pfn_valid(). >> >> pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID) >> which scans all mapped memblock regions with memblock_is_map_memory(). This >> creates a problem in memory hot remove path which has already removed given >> memory range from memory block with memblock_[remove|free] before arriving >> at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1 >> skipping subsequent sysfs_remove_link() calls leaving node <-> memory block >> sysfs entries as is. Subsequent memory add operation hits BUG_ON() because >> of existing sysfs entries. >> >> [ 62.007176] NUMA: Unknown node for memory at 0x68000, assuming node 0 >> [ 62.052517] [ cut here ] >> [ 62.053211] kernel BUG at mm/memory_hotplug.c:1143! >> [ 62.053868] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP >> [ 62.054589] Modules linked in: >> [ 62.054999] CPU: 19 PID: 3275 Comm: bash Not tainted >> 5.1.0-rc2-4-g28cea40b2683 #41 >> [ 62.056274] Hardware name: linux,dummy-virt (DT) >> [ 62.057166] pstate: 4045 (nZcv daif +PAN -UAO) >> [ 62.058083] pc : add_memory_resource+0x1cc/0x1d8 >> [ 62.058961] lr : add_memory_resource+0x10c/0x1d8 >> [ 62.059842] sp : 168b3ce0 >> [ 62.060477] x29: 168b3ce0 x28: 8005db546c00 >> [ 62.061501] x27: x26: >> [ 62.062509] x25: 111ef000 x24: 111ef5d0 >> [ 62.063520] x23: x22: 0006bfff >> [ 62.064540] x21: ffef x20: 006c >> [ 62.065558] x19: 0068 x18: 0024 >> [ 62.066566] x17: x16: >> [ 62.067579] x15: x14: 8005e412e890 >> [ 62.068588] x13: 8005d6b105d8 x12: >> [ 62.069610] x11: 8005d6b10490 x10: 0040 >> [ 62.070615] x9 : 8005e412e898 x8 : 8005e412e890 >> [ 62.071631] x7 : 8005d6b105d8 x6 : 8005db546c00 >> [ 62.072640] x5 : 0001 x4 : 0002 >> [ 62.073654] x3 : 8005d7049480 x2 : 0002 >> [ 62.074666] x1 : 0003 x0 : ffef >> [ 62.075685] Process bash (pid: 3275, stack limit = 0xd754280f) >> [ 62.076930] Call trace: >> [ 62.077411] add_memory_resource+0x1cc/0x1d8 >> [ 62.078227] __add_memory+0x70/0xa8 >> [ 62.078901] probe_store+0xa4/0xc8 >> [ 62.079561] dev_attr_store+0x18/0x28 >> [ 62.080270] sysfs_kf_write+0x40/0x58 >> [ 62.080992] kernfs_fop_write+0xcc/0x1d8 >> [ 62.081744] __vfs_write+0x18/0x40 >> [ 62.082400] vfs_write+0xa4/0x1b0 >> [ 62.083037] ksys_write+0x5c/0xc0 >> [ 62.083681] __arm64_sys_write+0x18/0x20 >> [ 62.084432] el0_svc_handler+0x88/0x100 >> [ 62.085177] el0_svc+0x8/0xc >> >> Re-ordering arch_remove_memory() with memblock_[free|remove] solves the >> problem on arm64 as pfn_valid() behaves correctly and returns positive >> as memblock for the address range still exists. arch_remove_memory() >> removes applicable memory sections from zone with __remove_pages() and >> tears down kernel linear mapping. Removing memblock regions afterwards >> is consistent. > > consistent with what? Anyway, I believe you wanted to mention that this > is safe because there is no other memblock (bootmem) allocator user that Yes I did intend but did not express that very well here. > late. So nobody is going to allocate from the removed range just to blow > up later. Also nobody should be using the bootmem allocated range else > we wouldn't allow to remove it. So reordering is indeed safe. Looks better. > >> Signed-off-by: Anshuman Khandual > > With a changelog updated to explain why this is safe Sure will change it. Thanks for the commit message suggestion.
[PATCH] remoteproc: silence an uninitialized variable warning
Smatch complains that "ret" might be uninitialized. I can see why it generates the warning, but I don't know if it's actually possible. Anyway initializing "ret" here is harmless. Signed-off-by: Dan Carpenter --- drivers/soc/qcom/mdt_loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c index 1c488024c698..fc58d660692f 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -188,7 +188,7 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw, if (reloc_base) *reloc_base = mem_reloc; - + ret = 0; out: kfree(fw_name); -- 2.17.1
Re: [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs
On Wed, Apr 03, 2019 at 11:08:09PM +0300, Alexey Dobriyan wrote: > Currently there is no easy way to get the number of CPUs on the system. And this patch doesn't change that :-) Still, it does the right thing and I like it. The point is that nr_cpu_ids is the length of the bitmap, but does not contain information on how many CPUs are in the system. Consider the case where the bitmap is sparse. > Applications are divided into 2 groups: > One group allocates buffer and call sched_getaffinity(2) once. It works > but either underallocate or overallocates and in the future such application > will become buggy as Linux will start working on even more SMP-ier systems. > > Glibc in particular shipped with 1024 CPUs support maximum at some point > which is quite surprising as glibc maitainers should know better. > > Another group dynamically grow buffer until cpumask fits. This is > inefficient as multiple system calls are done. > > Nobody seems to parse "/sys/devices/system/cpu/possible". > Even if someone does, parsing sysfs is much slower than necessary. True; but I suppose glibc already does lots of that anyway, right? It does contain the right information. > Patch overloads sched_getaffinity(len=0) to simply return "nr_cpu_ids". > This will make gettting CPU mask require at most 2 system calls > and will eliminate unnecessary code. > > len=0 is chosen so that > * passing zeroes is the simplest thing > > syscall(__NR_sched_getaffinity, 0, 0, NULL) > > will simply do the right thing, > > * old kernels returned -EINVAL unconditionally. > > Note: glibc segfaults upon exiting from system call because it tries to > clear the rest of the buffer if return value is positive, so > applications will have to use syscall(3). > Good news is that it proves noone uses sched_getaffinity(pid, 0, NULL). This also needs a manpage update. And I'm missing the libc people on Cc. > Signed-off-by: Alexey Dobriyan > --- > > kernel/sched/core.c |3 +++ > 1 file changed, 3 insertions(+) > > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -4942,6 +4942,9 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned > int, len, > int ret; > cpumask_var_t mask; > > + if (len == 0) > + return nr_cpu_ids; > + > if ((len * BITS_PER_BYTE) < nr_cpu_ids) > return -EINVAL; > if (len & (sizeof(unsigned long)-1))
