Re: [PATCH 1/1] pci: pciehp: Handle MRL interrupts to enable slot for hotplug.
Hi Ashok,
my sincere apologies for the delay.
On Fri, Sep 25, 2020 at 04:01:38PM -0700, Ashok Raj wrote:
> When Mechanical Retention Lock (MRL) is present, Linux doesn't process
> those change events.
>
> The following changes need to be enabled when MRL is present.
>
> 1. Subscribe to MRL change events in SlotControl.
> 2. When MRL is closed,
>- If there is no ATTN button, then POWER on the slot.
>- If there is ATTN button, and an MRL event pending, ignore
> Presence Detect. Since we want ATTN button to drive the
> hotplug event.
So I understand you have a hardware platform which has both MRL and
Attention Button on its hotplug slots? It may be useful to name the
hardware platform in the commit message.
If an Attention Button is present, the current behavior is to bring up
the hotplug slot as soon as presence or link is detected. We don't wait
for a button press. This is intended as a convience feature to bring up
slots as quickly as possible, but the behavior can be changed if the
button press and 5 second delay is preferred.
In any case the behavior in response to an Attention Button press should
be the same regardless whether an MRL is present or not. (The spec
doesn't seem to say otherwise.)
> + if (MRL_SENS(ctrl)) {
> + pciehp_get_latch_status(ctrl, );
> + /*
> + * If slot is closed && ATTN button exists
> + * don't continue, let the ATTN button
> + * drive the hot-plug
> + */
> + if (!getstatus && ATTN_BUTTN(ctrl))
> + return;
> + }
For the sake of readability I'd suggest adding a pciehp_latch_closed()
helper similar to pciehp_card_present_or_link_active() which returns
true if no MRL is present (i.e. !MRL_SENS(ctrl)), otherwise retrieves
and returns the status with pciehp_get_latch_status().
> +void pciehp_handle_mrl_change(struct controller *ctrl)
> +{
> + u8 getstatus = 0;
> + int present, link_active;
> +
> + pciehp_get_latch_status(ctrl, );
> +
> + present = pciehp_card_present(ctrl);
> + link_active = pciehp_check_link_active(ctrl);
> +
> + ctrl_info(ctrl, "Slot(%s): Card %spresent\n",
> + slot_name(ctrl), present ? "" : "not ");
> +
> + ctrl_info(ctrl, "Slot(%s): Link %s\n",
> + slot_name(ctrl), link_active ? "Up" : "Down");
This duplicates a lot of code from pciehp_handle_presence_or_link_change(),
which I think suggests handling MRL events in that function. After all,
an MRL event may lead to bringup or bringdown of a slot similar to
a link or presence event.
Basically pciehp_handle_presence_or_link_change() just needs to be
amended to bring down the slot if an MRL event occurred, and
afterwards only bring up the slot if MRL is closed. Like this:
- if (present <= 0 && link_active <= 0) {
+ if ((present <= 0 && link_active <= 0) || !latch_closed) {
mutex_unlock(>state_lock);
return;
}
> + /*
> + * Need to handle only MRL Open. When MRL is closed with
> + * a Card Present, either the ATTN button, or the PDC indication
> + * should power the slot and add the card in the slot
> + */
I agree with the second sentence. You may want to refer to PCIe Base Spec
r4.0, section 6.7.1.3 either in the commit message or a code comment,
which says:
"If an MRL Sensor is implemented without a corresponding MRL Sensor input
on the Hot-Plug Controller, it is recommended that the MRL Sensor be
routed to power fault input of the Hot-Plug Controller.
This allows an active adapter to be powered off when the MRL is opened."
This seems to suggest that the slot should be brought down as soon as MRL
is opened.
> + /*
> + * If MRL is triggered, if ATTN button exists, ignore the event.
> + */
> + if (ATTN_BUTTN(ctrl) && (events & PCI_EXP_SLTSTA_MRLSC))
> + events &= ~PCI_EXP_SLTSTA_PDC;
Hm, the spec doesn't seem to imply a connection between presence of
an MRL and presence of an Attention Button, so I find this confusing.
> + /*
> + * If ATTN is present and MRL is triggered
> + * ignore the Presence Change Event.
> + */
> + if (ATTN_BUTTN(ctrl) && (events & PCI_EXP_SLTSTA_MRLSC))
> + events &= ~PCI_EXP_SLTSTA_PDC;
An Attention Button press results in a synthesized PDC event after
5 seconds, which may get lost due to the above if-statement.
Thanks,
Lukas
Re: [PATCH] arm64: mm: add support for memmap kernel parameters
On Wed, Nov 18, 2020 at 11:55:33PM +, Song Bao Hua (Barry Song) wrote: > > From: Ard Biesheuvel [mailto:a...@kernel.org] > > > > On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song) > > wrote: > > > > > > Good question. Originally I wrote this patch to debug and verify the > > vmemmap > > > leak issue reported in this patch: > > > [PATCH v2] arm64: mm: free unused memmap for sparse memory model that > > define VMEMMAP > > > > > https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@ > > huawei.com/ > > > I don't have a machine which really has holes in memory_section to debug, > > but memmap > > > can help. With memmap, I could specified a machine with various holds in > > mem_sections. > > > > > > After that, I figured out this is not only useful for debugging purpose. > > > it can > > have some real user cases. > > > For example: > > > > > > 1. DAX on DRAM. > > > kernel parameter memmap=XG!YG specifies a range of RAM to emulate > > pmem. Then we are able > > > to run DAX and filesystem on top of it. Furthermore, this will probably > > > also > > benefit the case > > > this big patchset wants to "fix" via direct access to memory: > > > > > https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzh...@tencent.com/T > > /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780 > > > as the comments have clearly shown. > > > > > > 2. reserve some memory for userspace to manage via /dev/mem > > > > > > > Apologies for the bluntness, but what you are saying here is that you > > need a hack to pile those other hacks onto. > > > > Currently, we use the NOMAP attribute in memblock to describe memory > > that is omitted from the direct map. Removing memory from memblock > > entirely also strips it of this annotation, which means that > > phys_mem_access_prot() will identify it as device memory not DRAM, and > > use the wrong attributes when using /dev/mem. > > > > There are likely other places where this distinction matters, and so I > > am not buying the justification that we can make meaningful use of > > this memory in the general case, and anything that relies on it will > > be fragile, and probably only limited to very specific debug > > scenarios. > > Yep. originally I did that for debugging purpose to emulate a machine with > some holes in mem_section. I guess it should be also useful to other people > if they need the same thing for debugging. > > > > > So I don't think we should merge this. > > It should be in the same situation for other platforms like x86, mips and > xtensa > but they have enabled this kernel parameter. I didn't check mips and xtensa, but x86 carries this from nineties when they needed a way to work around broken BIOSes. I really doubt x86 maintainers would merge such feature these days. > maybe the emulated pmem by DRAM is an useful scenario other than debugging. > > Later, > https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzh...@tencent.com/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780 > might be able to use this parameter. Using kernel parameters to describe complex memory configuration does not seem scalable and maintainable. A simple mem=X should be enough for features like dmemfs to start with and if/when anything more complex will be required I doubt a kernel parameter would fit that purpose. Another thing as as soon as we expose this parameter to the user we'd have to make sure they can always get the memory layout they defined with it. Keeping the kernel parameter in sync with other means of memory detection would complicate things on both sides. Ard mentioned NOMAP property, there may be some NUMA considerations that could create a conflict between what user asked and what is possible and other things that may come up in the future. > Anyway, I don't mind keeping it local for debugging at this stage and waiting > for a > more convincing use case. > > Thanks > Barry > -- Sincerely yours, Mike.
Re: [PATCH] net: cw1200: fix missing destroy_workqueue() on error in cw1200_init_common
Qinglang Miao writes:
> Add the missing destroy_workqueue() before return from
> cw1200_init_common in the error handling case.
>
> Fixes:a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN
> chipsets")
This should be:
Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN
chipsets")
I can fix that.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] reset: sti: reset-syscfg: fix struct description warnings
Hi Alain
On 8/31/20 10:38 PM, Alain Volmat wrote:
> Fix formating of struct description to avoid warning highlighted
> by W=1 compilation.
>
> Fixes: e5d76075d930 ("drivers: reset: STi SoC system configuration reset
> controller support")
> Signed-off-by: Alain Volmat
> ---
> drivers/reset/sti/reset-syscfg.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/reset/sti/reset-syscfg.c
> b/drivers/reset/sti/reset-syscfg.c
> index 91215bb88f62..99b63035fe72 100644
> --- a/drivers/reset/sti/reset-syscfg.c
> +++ b/drivers/reset/sti/reset-syscfg.c
> @@ -17,7 +17,7 @@
> #include "reset-syscfg.h"
>
> /**
> - * Reset channel regmap configuration
> + * struct syscfg_reset_channel - Reset channel regmap configuration
> *
> * @reset: regmap field for the channel's reset bit.
> * @ack: regmap field for the channel's ack bit (optional).
> @@ -28,8 +28,9 @@ struct syscfg_reset_channel {
> };
>
> /**
> - * A reset controller which groups together a set of related reset bits,
> which
> - * may be located in different system configuration registers.
> + * struct syscfg_reset_controller - A reset controller which groups together
> + * a set of related reset bits, which may be located in different system
> + * configuration registers.
> *
> * @rst: base reset controller structure.
> * @active_low: are the resets in this controller active low, i.e. clearing
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH] phy: phy-bcm-ns-usb3: drop support for deprecated DT binding
On Thu, 19 Nov 2020 at 07:27, Vinod Koul wrote: > On 13-11-20, 12:34, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > Initially this PHY driver was implementing MDIO access on its own. It > > was caused by lack of proper hardware design understanding. > > > > It has been changed back in 2017. DT bindings were changed and driver > > was updated to use MDIO layer. > > > > It should be really safe now to drop the old deprecated code. All Linux > > stored DT files don't use it for 3,5 year. There is close to 0 chance > > there is any bootloader with its own DTB using old the binding. > > Applied, thanks > > While applying, it gave me a minor conflict, please do check the > resolution Oops, I used your master branch instead of next. Waiting for your push :) -- Rafał
[PATCH 0/2] Clean up and fix up cpu_cache_init()
Tiezhu Yang (2): MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init() MIPS: Loongson64: Fix wrong scache size when execute lscpu arch/mips/include/asm/cpu-features.h | 2 -- arch/mips/mm/c-r4k.c | 10 -- arch/mips/mm/cache.c | 10 -- 3 files changed, 4 insertions(+), 18 deletions(-) -- 2.1.0
Re: [PATCH v7 2/5] dt-bindings: leds: Add LED_COLOR_ID_MOONLIGHT definitions
Pavel Machek 於 2020年11月19日 週四 下午3:44寫道： > > Hi! > > > > > From: Gene Chen > > > > > > > > Add LED_COLOR_ID_MOONLIGHT definitions > > > > > > Why is moonlight a color? Camera flashes are usually white, no? > > > > > > At least it needs a comment... > > > > > > Best regards, > > > Pavel > > > > > > > Moonlight has more current level(150mA) from general RGB LED (24mA). > > It can be used as night-light and usually use color AMBER. > > Camera flashes are usually use two flash LED. One is YELLOW, and one > >is WHITE. > > From what I seen, night-lights are usually differetent "temperatures" > of white. Cool white + warm white. > > I believe "warm white" would be easier to understand than > "moonlight"... > ACK, I will change color "LED_COLOR_ID_WHITE" > Best regards, > Pavel > > -- > http://www.livejournal.com/~pavelmachek
Re: [PATCH v5] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.
On Wed, Nov 18, 2020 at 08:12:43PM +, Ashish Kalra wrote: > From: Ashish Kalra > > For SEV, all DMA to and from guest has to use shared > (un-encrypted) pages. SEV uses SWIOTLB to make this > happen without requiring changes to device drivers. > However, depending on workload being run, the default > 64MB of SWIOTLB might not be enough and SWIOTLB > may run out of buffers to use for DMA, resulting > in I/O errors and/or performance degradation for > high I/O workloads. FYI, you can use up 73 chars for your commit log. This looks rather compressed.
[PATCH 2/2] MIPS: Loongson64: Fix wrong scache size when execute lscpu
As the user manual and code comment said, Loongson-3 has 4-scache banks, while Loongson-2K has only 2 banks, so we should multiply the number of scache banks, this multiply operation should be done by c->scache.sets instead of scache_size, otherwise we will get the wrong scache size when execute lscpu. For example, the scache size should be 8192K instead of 2048K on the Loongson 3A3000 and 3A4000 platform, we can see the related info in the following boot message: [loongson@linux ~]$ dmesg | grep "Unified secondary cache" [0.00] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [4.061909] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [4.125629] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [4.188379] Unified secondary cache 8192kB 16-way, linesize 64 bytes. E.g. without this patch: [loongson@linux ~]$ cat /sys/devices/system/cpu/cpu*/cache/index2/size 2048K 2048K 2048K 2048K [loongson@linux ~]$ lscpu | grep "L2 cache" L2 cache: 2048K With this patch: [loongson@linux ~]$ cat /sys/devices/system/cpu/cpu*/cache/index2/size 8192K 8192K 8192K 8192K [loongson@linux ~]$ lscpu | grep "L2 cache" L2 cache: 8192K Signed-off-by: Tiezhu Yang --- arch/mips/mm/c-r4k.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index 9cede7c..9952176 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -1623,15 +1623,13 @@ static void __init loongson3_sc_init(void) c->scache.sets = 64 << ((config2 >> 8) & 15); c->scache.ways = 1 + (config2 & 15); - scache_size = c->scache.sets * - c->scache.ways * - c->scache.linesz; - /* Loongson-3 has 4-Scache banks, while Loongson-2K have only 2 banks */ if ((c->processor_id & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64R) - scache_size *= 2; + c->scache.sets *= 2; else - scache_size *= 4; + c->scache.sets *= 4; + + scache_size = c->scache.sets * c->scache.ways * c->scache.linesz; c->scache.waybit = 0; c->scache.waysize = scache_size / c->scache.ways; -- 2.1.0
[PATCH 1/2] MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init()
Since commit 02cf2119684e ("Cleanup the mess in cpu_cache_init."),
cpu_has_6k_cache and cpu_has_8k_cache have no user, r6k_cache_init()
and r8k_cache_init() are not defined for over 15 years, just remove
them.
Signed-off-by: Tiezhu Yang
---
arch/mips/include/asm/cpu-features.h | 2 --
arch/mips/mm/cache.c | 10 --
2 files changed, 12 deletions(-)
diff --git a/arch/mips/include/asm/cpu-features.h
b/arch/mips/include/asm/cpu-features.h
index f2e216e..336e02b 100644
--- a/arch/mips/include/asm/cpu-features.h
+++ b/arch/mips/include/asm/cpu-features.h
@@ -115,8 +115,6 @@
#ifndef cpu_has_3k_cache
#define cpu_has_3k_cache __isa_lt_and_opt(1, MIPS_CPU_3K_CACHE)
#endif
-#define cpu_has_6k_cache 0
-#define cpu_has_8k_cache 0
#ifndef cpu_has_4k_cache
#define cpu_has_4k_cache __isa_ge_or_opt(1, MIPS_CPU_4K_CACHE)
#endif
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 3e81ba0..ed99cde 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -203,21 +203,11 @@ void cpu_cache_init(void)
r3k_cache_init();
}
- if (cpu_has_6k_cache) {
- extern void __weak r6k_cache_init(void);
-
- r6k_cache_init();
- }
if (cpu_has_4k_cache) {
extern void __weak r4k_cache_init(void);
r4k_cache_init();
}
- if (cpu_has_8k_cache) {
- extern void __weak r8k_cache_init(void);
-
- r8k_cache_init();
- }
if (cpu_has_tx39_cache) {
extern void __weak tx39_cache_init(void);
--
2.1.0
Re: [RFC -V5] autonuma: Migrate on fault among multiple bound nodes
On Thu, Nov 19, 2020 at 02:17:21PM +0800, Huang, Ying wrote:
> >> Various page placement optimization based on the NUMA balancing can be
> >> done with these flags. As the first step, in this patch, if the
> >> memory of the application is bound to multiple nodes (MPOL_BIND), and
> >> in the hint page fault handler the accessing node are in the policy
> >> nodemask, the page will be tried to be migrated to the accessing node
> >> to reduce the cross-node accessing.
> >>
> >
> > The patch still lacks supporting data. It really should have a basic
> > benchmark of some sort serving as an example of how the policies should
> > be set and a before/after comparison showing the throughput of MPOL_BIND
> > accesses spanning 2 or more nodes is faster when numa balancing is enabled.
>
> Sure. Will add some basic benchmark data and usage example.
>
Thanks
> > A man page update should also be added clearly outlining when an
> > application should consider using it with the linux-api people cc'd
> > for review.
>
> Yes. Will Cc linux-api for review and will submit patches to
> manpages.git after the API is finalized.
>
Add the manpages patch to this series. While it is not merged through
the kernel, it's important for review purposes.
> > The main limitation is that if this requires application modification,
> > it may never be used. For example, if an application uses openmp places
> > that translates into bind then openmp needs knowledge of the flag.
> > Similar limitations apply to MPI. This feature has a risk that no one
> > uses it.
>
> My plan is to add a new option to `numactl`
> (https://github.com/numactl/numactl/), so users who want to enable NUMA
> balancing within the constrains of NUMA binding can use that. I can
> reach some Openstack and Kubernate developers to check whether it's
> possible to add the support to these software. For other applications,
> Yes, it may take long time for the new flag to be used.
>
Patch for numactl should also be included to see what it looks like in
practice. Document what happens if the flag does not exist in the
running kernel.
I know this is awkward, but it's an interface exposed to userspace and
as it is expected that applications will exist that then try run on
older kernels, it needs to be very up-front about what happens on older
kernels. It would not be a complete surprise for openmp and openmpi
packages to be updated on distributions with older kernels (either by
source or via packaging) leading to surprises.
> >> Huang Ying (2):
> >> mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON
> >> autonuma: Migrate on fault among multiple bound nodes
> >> ---
> >> include/uapi/linux/mempolicy.h | 4 +++-
> >> mm/mempolicy.c | 9 +
> >> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/uapi/linux/mempolicy.h
> >> b/include/uapi/linux/mempolicy.h
> >> index 3354774af61e..adb49f13840e 100644
> >> --- a/include/uapi/linux/mempolicy.h
> >> +++ b/include/uapi/linux/mempolicy.h
> >> @@ -28,12 +28,14 @@ enum {
> >> /* Flags for set_mempolicy */
> >> #define MPOL_F_STATIC_NODES (1 << 15)
> >> #define MPOL_F_RELATIVE_NODES (1 << 14)
> >> +#define MPOL_F_AUTONUMA (1 << 13) /* Optimize with AutoNUMA if
> >> possible */
> >>
> >
> > Order by flag usage, correct the naming.
>
> I will correct the naming. Sorry, what does "order" refer to?
>
Never mind, it was already in reverse order, it was a silly comment.
Just fix the name.
> >> /*
> >> * MPOL_MODE_FLAGS is the union of all possible optional mode flags
> >> passed to
> >> * either set_mempolicy() or mbind().
> >> */
> >> -#define MPOL_MODE_FLAGS (MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES)
> >> +#define MPOL_MODE_FLAGS
> >> \
> >> + (MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES | MPOL_F_AUTONUMA)
> >>
> >> /* Flags for get_mempolicy */
> >> #define MPOL_F_NODE (1<<0) /* return next IL mode instead of node
> >> mask */
> >
> > How does an application discover if MPOL_F_NUMAB is supported by the
> > current running kernel? It looks like they might receive -EINVAL (didn't
> > check for sure).
>
> Yes.
>
Needs to be documented so applications know they can recover. Also needs
to be determined how numactl should behave if the flag does not exist.
Likely it will simply fail in which case the error should be clear.
> > In that case, a manual page is defintely needed to
> > explain that an error can be returned if the flag is used and the kernel
> > does not support it so the application can cover by falling back to a
> > strict binding. If it fails silently, then that also needs to be documented
> > because it'll lead to different behaviour depending on the running
> > kernel.
>
> Sure. Will describe this in the manual page.
>
Thanks.
--
Mel Gorman
SUSE Labs
Re: [RFC PATCH 2/4] sched: make schedstats helpers not depend on cfs_rq
On Thu, Nov 19, 2020 at 11:52:28AM +0800, Yafang Shao wrote: > The 'cfs_rq' in these helpers is only used to get the rq_clock, so we > can pass the rq_clock directly. After that, these helpers can be used by > all sched class. > > Signed-off-by: Yafang Shao This introduces overhead in the general case even when schedstats is disabled. Previously, update_stats_wait_start was a static inline so function call overhead was avoided and schedstat_enabled() meant the overhead was negligible. As it's now a function call, the cost of the function entry/exit will be unconditionally hit regardless of intrest in schedstat. Regardless of the merit of adding schedstats for RT, the overhead of schedstats when stats are disabled should remain the same with the static branch check done in an inline function. -- Mel Gorman SUSE Labs
Re: [PATCH v7 2/5] dt-bindings: leds: Add LED_COLOR_ID_MOONLIGHT definitions
Hi! > > > From: Gene Chen > > > > > > Add LED_COLOR_ID_MOONLIGHT definitions > > > > Why is moonlight a color? Camera flashes are usually white, no? > > > > At least it needs a comment... > > > > Best regards, > > Pavel > > > > Moonlight has more current level(150mA) from general RGB LED (24mA). > It can be used as night-light and usually use color AMBER. > Camera flashes are usually use two flash LED. One is YELLOW, and one >is WHITE. From what I seen, night-lights are usually differetent "temperatures" of white. Cool white + warm white. I believe "warm white" would be easier to understand than "moonlight"... Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [PATCH] Input: adp5589-keys - use BIT()
On Wed, Nov 18, 2020 at 11:34:28PM -0800, Joe Perches wrote:
> On Wed, 2020-11-18 at 23:24 -0800, Dmitry Torokhov wrote:
> > Let's use BIT() macro instead of explicitly shifting '1'.
> []
> > diff --git a/drivers/input/keyboard/adp5589-keys.c
> > b/drivers/input/keyboard/adp5589-keys.c
>
> > @@ -651,13 +652,13 @@ static int adp5589_setup(struct adp5589_kpad *kpad)
> > unsigned short pin = pdata->gpimap[i].pin;
> >
>
> trivia:
>
> Perhaps nicer to create and use a temporary
>
> unsigned int bit = BIT(pin - kpad->var->gpi_pin_col_base);
>
> so in these places below:
>
> > if (pin <= kpad->var->gpi_pin_row_end) {
> > - evt_mode1 |= (1 << (pin - kpad->var->gpi_pin_row_base));
> > + evt_mode1 |= BIT(pin - kpad->var->gpi_pin_row_base);
>
> evt_mode1 |= bit;
>
> > } else {
> > evt_mode2 |=
> > - ((1 << (pin - kpad->var->gpi_pin_col_base)) & 0xFF);
> > + BIT(pin - kpad->var->gpi_pin_col_base) & 0xFF;
>
> evt_mode2 |= bit & 0xff;
Different "bit" tough - row vs column.
>
> > if (!kpad->is_adp5585)
> > - evt_mode3 |= ((1 << (pin -
> > - kpad->var->gpi_pin_col_base)) >> 8);
> > + evt_mode3 |=
> > + BIT(pin - kpad->var->gpi_pin_col_base) >> 8;
>
> evt_mode3 |= bit >> 8;
>
>
Thanks.
--
Dmitry
[PATCH V3 0/2] cpufreq_cooling: Get effective CPU utilization from scheduler
Hi, This patchset makes the cpufreq_cooling driver reuse the CPU utilization metric provided by the scheduler instead of depending on idle and busy times of a CPU, which aren't that accurate to measure the busyness of a CPU for the next cycle. More details can be seen in the commit log of patch 2/2. V2->V3: - Put the scheduler helpers within ifdef CONFIG_SMP. - Keep both SMP and !SMP implementations in the cpufreq_cooling driver. - Improved commit log with testing related information. -- Viresh Viresh Kumar (2): sched/core: Rename and move schedutil_cpu_util() to core.c thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms drivers/thermal/cpufreq_cooling.c | 68 ++ include/linux/sched.h | 21 ++ kernel/sched/core.c | 115 + kernel/sched/cpufreq_schedutil.c | 116 +- kernel/sched/fair.c | 6 +- kernel/sched/sched.h | 31 +--- 6 files changed, 199 insertions(+), 158 deletions(-) base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec -- 2.25.0.rc1.19.g042ed3e048af
[PATCH V3 2/2] thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms
Several parts of the kernel are already using the effective CPU
utilization (as seen by the scheduler) to get the current load on the
CPU, do the same here instead of depending on the idle time of the CPU,
which isn't that accurate comparatively.
This is also the right thing to do as it makes the cpufreq governor
(schedutil) align better with the cpufreq_cooling driver, as the power
requested by cpufreq_cooling governor will exactly match the next
frequency requested by the schedutil governor since they are both using
the same metric to calculate load.
Note that, this (and CPU frequency scaling in general) doesn't work that
well with idle injection as that is done from rt threads and is counted
as load while it tries to do quite the opposite. That should be solved
separately though.
This was tested on ARM Hikey6220 platform with hackbench, sysbench and
schbench. None of them showed any regression or significant
improvements. Schbench is the most important ones out of these as it
creates the scenario where the utilization numbers provide a better
estimate of the future.
Scenario 1: The CPUs were mostly idle in the previous polling window of
the IPA governor as the tasks were sleeping and here are the details
from traces (load is in %):
Old: thermal_power_cpu_get_power: cpus=,00ff freq=120
total_load=203 load={{0x35,0x1,0x0,0x31,0x0,0x0,0x64,0x0}} dynamic_power=1339
New: thermal_power_cpu_get_power: cpus=,00ff freq=120
total_load=600 load={{0x60,0x46,0x45,0x45,0x48,0x3b,0x61,0x44}}
dynamic_power=3960
Here, the "Old" line gives the load and requested_power (dynamic_power
here) numbers calculated using the idle time based implementation, while
"New" is based on the CPU utilization from scheduler.
As can be clearly seen, the load and requested_power numbers are simply
incorrect in the idle time based approach and the numbers collected from
CPU's utilization are much closer to the reality.
Scenario 2: The CPUs were busy in the previous polling window of the IPA
governor:
Old: thermal_power_cpu_get_power: cpus=,00ff freq=120
total_load=800 load={{0x64,0x64,0x64,0x64,0x64,0x64,0x64,0x64}}
dynamic_power=5280
New: thermal_power_cpu_get_power: cpus=,00ff freq=120
total_load=708 load={{0x4d,0x5c,0x5c,0x5b,0x5c,0x5c,0x51,0x5b}}
dynamic_power=4672
As can be seen, the idle time based load is 100% for all the CPUs as it
took only the last window into account, but in reality the CPUs aren't
that loaded as shown by the utilization numbers.
Signed-off-by: Viresh Kumar
---
drivers/thermal/cpufreq_cooling.c | 68 ---
1 file changed, 54 insertions(+), 14 deletions(-)
diff --git a/drivers/thermal/cpufreq_cooling.c
b/drivers/thermal/cpufreq_cooling.c
index cc2959f22f01..a364a2fd84b1 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -76,7 +76,9 @@ struct cpufreq_cooling_device {
struct em_perf_domain *em;
struct cpufreq_policy *policy;
struct list_head node;
+#ifndef CONFIG_SMP
struct time_in_idle *idle_time;
+#endif
struct freq_qos_request qos_req;
};
@@ -132,14 +134,35 @@ static u32 cpu_power_to_freq(struct
cpufreq_cooling_device *cpufreq_cdev,
}
/**
- * get_load() - get load for a cpu since last updated
- * @cpufreq_cdev: cpufreq_cooling_device for this cpu
- * @cpu: cpu number
- * @cpu_idx: index of the cpu in time_in_idle*
+ * get_load() - get load for a cpu
+ * @cpufreq_cdev: struct cpufreq_cooling_device for the cpu
+ * @cpu: cpu number
+ * @cpu_idx: index of the cpu in time_in_idle array
*
* Return: The average load of cpu @cpu in percentage since this
* function was last called.
*/
+#ifdef CONFIG_SMP
+static u32 get_load(struct cpufreq_cooling_device *cpufreq_cdev, int cpu,
+ int cpu_idx)
+{
+ unsigned long max = arch_scale_cpu_capacity(cpu);
+ unsigned long util;
+
+ util = sched_cpu_util(cpu, ENERGY_UTIL, max);
+ return (util * 100) / max;
+}
+
+static inline int allocate_idle_time(struct cpufreq_cooling_device
*cpufreq_cdev)
+{
+ return 0;
+}
+
+static inline void free_idle_time(struct cpufreq_cooling_device *cpufreq_cdev)
+{
+}
+
+#else /* !CONFIG_SMP */
static u32 get_load(struct cpufreq_cooling_device *cpufreq_cdev, int cpu,
int cpu_idx)
{
@@ -162,6 +185,26 @@ static u32 get_load(struct cpufreq_cooling_device
*cpufreq_cdev, int cpu,
return load;
}
+static int allocate_idle_time(struct cpufreq_cooling_device *cpufreq_cdev)
+{
+ unsigned int num_cpus =
cpumask_weight(cpufreq_cdev->policy->related_cpus);
+
+ cpufreq_cdev->idle_time = kcalloc(num_cpus,
+sizeof(*cpufreq_cdev->idle_time),
+GFP_KERNEL);
+ if (!cpufreq_cdev->idle_time)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void
[PATCH V3 1/2] sched/core: Rename and move schedutil_cpu_util() to core.c
There is nothing schedutil specific in schedutil_cpu_util(), move it to
core.c and rename it to sched_cpu_util(), so it can be used from other
parts of the kernel as well.
The cpufreq_cooling stuff will make use of this in a later commit.
Signed-off-by: Viresh Kumar
---
include/linux/sched.h| 21 ++
kernel/sched/core.c | 115 ++
kernel/sched/cpufreq_schedutil.c | 116 +--
kernel/sched/fair.c | 6 +-
kernel/sched/sched.h | 31 +
5 files changed, 145 insertions(+), 144 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 063cd120b459..926b944dae5e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1926,6 +1926,27 @@ extern long sched_getaffinity(pid_t pid, struct cpumask
*mask);
#define TASK_SIZE_OF(tsk) TASK_SIZE
#endif
+#ifdef CONFIG_SMP
+/**
+ * enum cpu_util_type - CPU utilization type
+ * @FREQUENCY_UTIL:Utilization used to select frequency
+ * @ENERGY_UTIL: Utilization used during energy calculation
+ *
+ * The utilization signals of all scheduling classes (CFS/RT/DL) and IRQ time
+ * need to be aggregated differently depending on the usage made of them. This
+ * enum is used within sched_cpu_util() to differentiate the types of
+ * utilization expected by the callers, and adjust the aggregation accordingly.
+ */
+enum cpu_util_type {
+ FREQUENCY_UTIL,
+ ENERGY_UTIL,
+};
+
+/* Returns effective CPU utilization, as seen by the scheduler */
+unsigned long sched_cpu_util(int cpu, enum cpu_util_type type,
+unsigned long max);
+#endif /* CONFIG_SMP */
+
#ifdef CONFIG_RSEQ
/*
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d2003a7d5ab5..845c976ccd53 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5117,6 +5117,121 @@ struct task_struct *idle_task(int cpu)
return cpu_rq(cpu)->idle;
}
+#ifdef CONFIG_SMP
+/*
+ * This function computes an effective utilization for the given CPU, to be
+ * used for frequency selection given the linear relation: f = u * f_max.
+ *
+ * The scheduler tracks the following metrics:
+ *
+ * cpu_util_{cfs,rt,dl,irq}()
+ * cpu_bw_dl()
+ *
+ * Where the cfs,rt and dl util numbers are tracked with the same metric and
+ * synchronized windows and are thus directly comparable.
+ *
+ * The cfs,rt,dl utilization are the running times measured with rq->clock_task
+ * which excludes things like IRQ and steal-time. These latter are then accrued
+ * in the irq utilization.
+ *
+ * The DL bandwidth number otoh is not a measured metric but a value computed
+ * based on the task model parameters and gives the minimal utilization
+ * required to meet deadlines.
+ */
+unsigned long effective_cpu_util(int cpu, unsigned long util_cfs,
+unsigned long max, enum cpu_util_type type,
+struct task_struct *p)
+{
+ unsigned long dl_util, util, irq;
+ struct rq *rq = cpu_rq(cpu);
+
+ if (!uclamp_is_used() &&
+ type == FREQUENCY_UTIL && rt_rq_is_runnable(>rt)) {
+ return max;
+ }
+
+ /*
+* Early check to see if IRQ/steal time saturates the CPU, can be
+* because of inaccuracies in how we track these -- see
+* update_irq_load_avg().
+*/
+ irq = cpu_util_irq(rq);
+ if (unlikely(irq >= max))
+ return max;
+
+ /*
+* Because the time spend on RT/DL tasks is visible as 'lost' time to
+* CFS tasks and we use the same metric to track the effective
+* utilization (PELT windows are synchronized) we can directly add them
+* to obtain the CPU's actual utilization.
+*
+* CFS and RT utilization can be boosted or capped, depending on
+* utilization clamp constraints requested by currently RUNNABLE
+* tasks.
+* When there are no CFS RUNNABLE tasks, clamps are released and
+* frequency will be gracefully reduced with the utilization decay.
+*/
+ util = util_cfs + cpu_util_rt(rq);
+ if (type == FREQUENCY_UTIL)
+ util = uclamp_rq_util_with(rq, util, p);
+
+ dl_util = cpu_util_dl(rq);
+
+ /*
+* For frequency selection we do not make cpu_util_dl() a permanent part
+* of this sum because we want to use cpu_bw_dl() later on, but we need
+* to check if the CFS+RT+DL sum is saturated (ie. no idle time) such
+* that we select f_max when there is no idle time.
+*
+* NOTE: numerical errors or stop class might cause us to not quite hit
+* saturation when we should -- something for later.
+*/
+ if (util + dl_util >= max)
+ return max;
+
+ /*
+* OTOH, for energy computation we need the estimated running time, so
+* include util_dl and ignore dl_bw.
+*/
+
[PATCH] include/net/bluetooth/mgmt.h: fix typo in struct name
Signed-off-by: n01e0
---
include/net/bluetooth/mgmt.h | 4 ++--
net/bluetooth/mgmt.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 6b55155e05e9..d8367850e8cd 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -621,7 +621,7 @@ struct mgmt_cp_set_appearance {
#define MGMT_SET_APPEARANCE_SIZE 2
#define MGMT_OP_GET_PHY_CONFIGURATION 0x0044
-struct mgmt_rp_get_phy_confguration {
+struct mgmt_rp_get_phy_configuration {
__le32 supported_phys;
__le32 configurable_phys;
__le32 selected_phys;
@@ -658,7 +658,7 @@ struct mgmt_rp_get_phy_confguration {
MGMT_PHY_LE_CODED_RX)
#define MGMT_OP_SET_PHY_CONFIGURATION 0x0045
-struct mgmt_cp_set_phy_confguration {
+struct mgmt_cp_set_phy_configuration {
__le32 selected_phys;
} __packed;
#define MGMT_SET_PHY_CONFIGURATION_SIZE4
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 12d7b368b428..3dfed4efa078 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -3387,7 +3387,7 @@ static int set_appearance(struct sock *sk, struct hci_dev
*hdev, void *data,
static int get_phy_configuration(struct sock *sk, struct hci_dev *hdev,
void *data, u16 len)
{
- struct mgmt_rp_get_phy_confguration rp;
+ struct mgmt_rp_get_phy_configuration rp;
bt_dev_dbg(hdev, "sock %p", sk);
@@ -3451,7 +3451,7 @@ static void set_default_phy_complete(struct hci_dev
*hdev, u8 status,
static int set_phy_configuration(struct sock *sk, struct hci_dev *hdev,
void *data, u16 len)
{
- struct mgmt_cp_set_phy_confguration *cp = data;
+ struct mgmt_cp_set_phy_configuration *cp = data;
struct hci_cp_le_set_default_phy cp_phy;
struct mgmt_pending_cmd *cmd;
struct hci_request req;
--
2.25.1
Re: [PATCH] Input: adp5589-keys - use BIT()
On Wed, 2020-11-18 at 23:24 -0800, Dmitry Torokhov wrote:
> Let's use BIT() macro instead of explicitly shifting '1'.
[]
> diff --git a/drivers/input/keyboard/adp5589-keys.c
> b/drivers/input/keyboard/adp5589-keys.c
> @@ -651,13 +652,13 @@ static int adp5589_setup(struct adp5589_kpad *kpad)
> unsigned short pin = pdata->gpimap[i].pin;
>
trivia:
Perhaps nicer to create and use a temporary
unsigned int bit = BIT(pin - kpad->var->gpi_pin_col_base);
so in these places below:
> if (pin <= kpad->var->gpi_pin_row_end) {
> - evt_mode1 |= (1 << (pin - kpad->var->gpi_pin_row_base));
> + evt_mode1 |= BIT(pin - kpad->var->gpi_pin_row_base);
evt_mode1 |= bit;
> } else {
> evt_mode2 |=
> - ((1 << (pin - kpad->var->gpi_pin_col_base)) & 0xFF);
> + BIT(pin - kpad->var->gpi_pin_col_base) & 0xFF;
evt_mode2 |= bit & 0xff;
> if (!kpad->is_adp5585)
> - evt_mode3 |= ((1 << (pin -
> - kpad->var->gpi_pin_col_base)) >> 8);
> + evt_mode3 |=
> + BIT(pin - kpad->var->gpi_pin_col_base) >> 8;
evt_mode3 |= bit >> 8;
RE: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use platform driver
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: 2020年11月18日 22:11
> To: Alice Guo
> Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> dl-linux-imx ; Peng Fan ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use platform
> driver
>
> Caution: EXT Email
>
> On Wed, Nov 18, 2020 at 02:07:41PM +, Alice Guo wrote:
> >
> >
> > > -Original Message-
> > > From: Krzysztof Kozlowski
> > > Sent: 2020年11月18日 18:42
> > > To: Alice Guo
> > > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > > dl-linux-imx ; Peng Fan ;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use
> > > platform driver
> > >
> > > Caution: EXT Email
> > >
> > > On Wed, Nov 18, 2020 at 10:28:47AM +, Alice Guo wrote:
> > > >
> > > > > If it is properly explained and there is no other way then yes,
> > > > > you could. Here, for old DTBs, I would prefer to use
> > > > > of_platform_device_create() and bind to "soc" node (child of root).
> > > > > This way you would always have device and exactly one entry
> > > > > point for the probe.
> > > > >
> > > >
> > > > static struct platform_driver imx8_soc_init_driver = {
> > > > .probe = imx8_soc_init_probe,
> > > > .driver = {
> > > > .name = "soc@0",
> > > > },
> > > > };
> > > > Can I use "soc@0" to match this driver? It will not use
> > > > of_platform_device_create(). It will use of_find_property() to
> > > > determine whether and nvmem-cells can be used. If there is no
> > > > nvmem-cells,
> > > it will use the old way, which supports old DTBS. There is no need
> > > to add new compatible.
> > >
> > > No, the soc@0 is not a proper name for the driver.
> >
> > I have no good idea, please give suggestion. Should I still add new
> > compatible?
> > Should I still keep device_initcall? If use
> > of_platform_device_create(), which node should I use?
>
> I mentioned my idea in the email before - of_platform_device_create() to bind
> to the soc node. This will have to be in the initcall, you don't have a
> choice to
> avoid it, since there was no compatible before.
>
node = of_find_node_by_path("/soc@0");
if (!node)
return -ENODEV;
pdev = of_platform_device_create(node, "XXX", NULL);
if (!pdev)
return -ENODEV;
Cannot use of_platform_device_create because "of_node_test_and_set_flag(np,
OF_POPULATED)" returns true.
of_platform_device_create is used to create platform device, but soc@0 is
created by common code. I don't know how
to bind to the soc node. The way I did in v3 seems not bad, it can work
correctly and support old DTBs. Can I keep this way?
Best regards,
Alice Guo
> Best regards,
> Krzysztof
Re: xfs_reclaim_inodes_ag taking several seconds
On 8/12/20 8:49 AM, Donald Buczek wrote: On 8/4/20 12:11 AM, Dave Chinner wrote: On Sat, Aug 01, 2020 at 12:25:40PM +0200, Donald Buczek wrote: On 01.08.20 00:32, Dave Chinner wrote: On Fri, Jul 31, 2020 at 01:27:31PM +0200, Donald Buczek wrote: Dear Linux people, we have a backup server with two xfs filesystems on 101.9TB md-raid6 devices (16 * 7.3 T disks) each, Current Linux version is 5.4.54. . root:done:/home/buczek/linux_problems/shrinker_semaphore/# cat /proc/meminfo MemTotal: 263572332 kB 256GB of RAM. MemFree: 2872368 kB MemAvailable: 204193824 kB 200GB "available" Buffers: 2568 kB Cached: 164931356 kB 160GB in page cache KReclaimable: 40079660 kB Slab: 49988268 kB SReclaimable: 40079660 kB 40GB in reclaimable slab objects. IOWs, you have no free memory in the machine and so allocation will frequently be dipping into memory reclaim to free up page cache and slab caches to make memory available. xfs_inode 30978282 31196832 960 4 1 : tunables 54 27 8 : slabdata 7799208 7799208 434 Yes, 30 million cached inodes. bio_integrity_payload 29644966 30203481 192 21 1 : tunables 120 60 8 : slabdata 1438261 1438261 480 Either there is a memory leak in this slab, or it is shared with something like the xfs_ili slab, which would indicate that most of the cached inodes have been dirtied in memory at some point in time. I think you are right here: crash> p $s->name $84 = 0x82259401 "bio_integrity_payload" crash> p $s->refcount $88 = 8 crash> p $s $92 = (struct kmem_cache *) 0x88bff92d2bc0 crash> p sizeof(xfs_inode_log_item_t) $93 = 192 crash> p $s->object_size $94 = 192 So if I understand you correctly, this is expected behavior with this kind of load and conceptual changes are already scheduled for kernel 5.9. I don't understand most of it, but isn't it true that with that planned changes the impact might be better limited to the filesystem, so that the performance of other areas of the system might improve? What the changes in 5.9 will do is remove the direct memory reclaim latency that comes from waiting on IO in the shrinker. Hence you will no longer see this problem from applications doing memory allocation. i.e. they'll get some other memory reclaimed without blocking (e.g. page cache or clean inodes) and so the specific symptom of having large numbers of dirty inodes in memory that you are seeing will go away. Which means that dirty inodes in memory will continue to build up until the next constraint is hit, and then it will go back to having unpredictable large latencies while waiting for inodes to be written back to free up whatever resource the filesystem has run out of. That resource will, most likely, be filesystem journal space. Every fs modification needs to reserve sufficient journal to complete before the modification starts. Hence if the journal fills, any modification to the fs will block waiting on dirty inode writeback to release space in the journal You might be lucky and the backup process is slow enough that the disk subsystem can keep up with the rate of ingest of new data and so you never hit this limitation. However, the reported state of the machine and the amount of RAM it has for caching says to me that the underlying problem is that ingest is far faster than the filesystem and disk subsystem can sink... A solution to this problem might be to spread out the backups being done over a wider timeframe, such that there isn't a sustained heavy load at 3am in the morning when every machine is scheduled to be backed up at the same time... It is already running round the clock. We have two of these servers, doing daily backups for 1374 file spaces (= directory trees below 1 TB) on 392 clients. The servers are doing daily mirrors of these file spaces, creating hard links for existing files and keeping these daily trees for 4 month. The schedule is free from fixed wall clock times. A backup is due when the last iteration is older than 24 hours, and will be done as time, threads and some locking constrains allow. Under normal circumstances the servers keep up, but are nearly continuously busy. The excess capacity is spread all over the day (sometimes there is no work to do for some minutes). I monitor, how long a local mount takes (usually 0.03-0.04 seconds) and the worst time seen so far is over 16 minutes! Because we rely on autofs mounts for logins and some other things, the system kind of appears to be dead during that time. I've limited the inode caches by running the backup jobs in memory control groups, but, as expected, this didn't really bring down the delays. I've also added a cond_resched() to mm/vmscan.c:shrink_slab_memcg(), which seems to be missing after the up_read(), but this didn't help either. From a user perspective it is hard to understand, that a
[PATCH] via/via_irq: use __func__ to replace string function name
This change also fix checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using
'via_driver_irq_postinstall', this function's name, in a string
+ DRM_DEBUG("via_driver_irq_postinstall\n");
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/via/via_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..56ce5d4ee24a 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -308,7 +308,7 @@ int via_driver_irq_postinstall(struct drm_device *dev)
drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
u32 status;
- DRM_DEBUG("via_driver_irq_postinstall\n");
+ DRM_DEBUG("fun: %s\n", __func__);
if (!dev_priv)
return -EINVAL;
--
2.29.0
[PATCH v3 3/4] dt-bindings: clock: Introduce RPMHCC bindings for SDX55
From: Vinod Koul Add compatible for SDX55 RPMHCC and DT include. Signed-off-by: Vinod Koul Signed-off-by: Manivannan Sadhasivam Reviewed-by: Bjorn Andersson Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 1 + include/dt-bindings/clock/qcom,rpmh.h| 1 + 2 files changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index a46a3a799a70..a54930f111ba 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,sc7180-rpmh-clk - qcom,sdm845-rpmh-clk + - qcom,sdx55-rpmh-clk - qcom,sm8150-rpmh-clk - qcom,sm8250-rpmh-clk diff --git a/include/dt-bindings/clock/qcom,rpmh.h b/include/dt-bindings/clock/qcom,rpmh.h index 2e6c54e65455..cd806eccb7dd 100644 --- a/include/dt-bindings/clock/qcom,rpmh.h +++ b/include/dt-bindings/clock/qcom,rpmh.h @@ -21,5 +21,6 @@ #define RPMH_IPA_CLK 12 #define RPMH_LN_BB_CLK113 #define RPMH_LN_BB_CLK1_A 14 +#define RPMH_QPIC_CLK 15 #endif -- 2.17.1
[PATCH v3 4/4] clk: qcom: Add support for SDX55 RPMh clocks
Add support for following clocks maintained by RPMh in SDX55 SoCs.
* BI TCXO
* RF_CLK1
* RF_CLK1_AO
* RF_CLK2
* RF_CLK2_AO
* QPIC (Qualcomm Technologies, Inc. Parallel Interface Controller)
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Vinod Koul
Reviewed-by: Bjorn Andersson
---
drivers/clk/qcom/clk-rpmh.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
index e2c669b08aff..fb72db957721 100644
--- a/drivers/clk/qcom/clk-rpmh.c
+++ b/drivers/clk/qcom/clk-rpmh.c
@@ -432,6 +432,25 @@ static const struct clk_rpmh_desc clk_rpmh_sm8250 = {
.num_clks = ARRAY_SIZE(sm8250_rpmh_clocks),
};
+DEFINE_CLK_RPMH_VRM(sdx55, rf_clk1, rf_clk1_ao, "rfclkd1", 1);
+DEFINE_CLK_RPMH_VRM(sdx55, rf_clk2, rf_clk2_ao, "rfclkd2", 1);
+DEFINE_CLK_RPMH_BCM(sdx55, qpic_clk, "QP0");
+
+static struct clk_hw *sdx55_rpmh_clocks[] = {
+ [RPMH_CXO_CLK] = _bi_tcxo.hw,
+ [RPMH_CXO_CLK_A]= _bi_tcxo_ao.hw,
+ [RPMH_RF_CLK1] = _rf_clk1.hw,
+ [RPMH_RF_CLK1_A]= _rf_clk1_ao.hw,
+ [RPMH_RF_CLK2] = _rf_clk2.hw,
+ [RPMH_RF_CLK2_A]= _rf_clk2_ao.hw,
+ [RPMH_QPIC_CLK] = _qpic_clk.hw,
+};
+
+static const struct clk_rpmh_desc clk_rpmh_sdx55 = {
+ .clks = sdx55_rpmh_clocks,
+ .num_clks = ARRAY_SIZE(sdx55_rpmh_clocks),
+};
+
static struct clk_hw *of_clk_rpmh_hw_get(struct of_phandle_args *clkspec,
void *data)
{
@@ -517,6 +536,7 @@ static int clk_rpmh_probe(struct platform_device *pdev)
static const struct of_device_id clk_rpmh_match_table[] = {
{ .compatible = "qcom,sc7180-rpmh-clk", .data = _rpmh_sc7180},
{ .compatible = "qcom,sdm845-rpmh-clk", .data = _rpmh_sdm845},
+ { .compatible = "qcom,sdx55-rpmh-clk", .data = _rpmh_sdx55},
{ .compatible = "qcom,sm8150-rpmh-clk", .data = _rpmh_sm8150},
{ .compatible = "qcom,sm8250-rpmh-clk", .data = _rpmh_sm8250},
{ }
--
2.17.1
[PATCH v3 1/4] dt-bindings: clock: Add SDX55 GCC clock bindings
From: Vinod Koul
Add device tree bindings for global clock controller on SDX55 SoCs.
Signed-off-by: Vinod Koul
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Rob Herring
---
.../bindings/clock/qcom,gcc-sdx55.yaml| 73
include/dt-bindings/clock/qcom,gcc-sdx55.h| 112 ++
2 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
create mode 100644 include/dt-bindings/clock/qcom,gcc-sdx55.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
new file mode 100644
index ..9d8981817ae3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx55.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller Binding for SDX55
+
+maintainers:
+ - Vinod Koul
+ - Manivannan Sadhasivam
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on SDX55
+
+ See also:
+ - dt-bindings/clock/qcom,gcc-sdx55.h
+
+properties:
+ compatible:
+const: qcom,gcc-sdx55
+
+ clocks:
+items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PLL test clock source
+
+ clock-names:
+items:
+ - const: bi_tcxo
+ - const: sleep_clk
+ - const: core_bi_pll_test_se
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+clock-controller@10 {
+ compatible = "qcom,gcc-sdx55";
+ reg = <0x0010 0x1f>;
+ clocks = < RPMH_CXO_CLK>,
+ <_clk>, <_test_clk>;
+ clock-names = "bi_tcxo", "sleep_clk", "core_bi_pll_test_se";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+};
+
+...
diff --git a/include/dt-bindings/clock/qcom,gcc-sdx55.h
b/include/dt-bindings/clock/qcom,gcc-sdx55.h
new file mode 100644
index ..c372451b3461
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gcc-sdx55.h
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020, Linaro Ltd.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GCC_SDX55_H
+#define _DT_BINDINGS_CLK_QCOM_GCC_SDX55_H
+
+#define GPLL0 3
+#define GPLL0_OUT_EVEN 4
+#define GPLL4 5
+#define GPLL4_OUT_EVEN 6
+#define GPLL5 7
+#define GCC_AHB_PCIE_LINK_CLK 8
+#define GCC_BLSP1_AHB_CLK 9
+#define GCC_BLSP1_QUP1_I2C_APPS_CLK10
+#define GCC_BLSP1_QUP1_I2C_APPS_CLK_SRC11
+#define GCC_BLSP1_QUP1_SPI_APPS_CLK12
+#define GCC_BLSP1_QUP1_SPI_APPS_CLK_SRC13
+#define GCC_BLSP1_QUP2_I2C_APPS_CLK14
+#define GCC_BLSP1_QUP2_I2C_APPS_CLK_SRC15
+#define GCC_BLSP1_QUP2_SPI_APPS_CLK16
+#define GCC_BLSP1_QUP2_SPI_APPS_CLK_SRC17
+#define GCC_BLSP1_QUP3_I2C_APPS_CLK18
+#define GCC_BLSP1_QUP3_I2C_APPS_CLK_SRC19
+#define GCC_BLSP1_QUP3_SPI_APPS_CLK20
+#define GCC_BLSP1_QUP3_SPI_APPS_CLK_SRC21
+#define GCC_BLSP1_QUP4_I2C_APPS_CLK22
+#define GCC_BLSP1_QUP4_I2C_APPS_CLK_SRC23
+#define GCC_BLSP1_QUP4_SPI_APPS_CLK24
+#define GCC_BLSP1_QUP4_SPI_APPS_CLK_SRC25
+#define GCC_BLSP1_UART1_APPS_CLK 26
+#define GCC_BLSP1_UART1_APPS_CLK_SRC 27
+#define GCC_BLSP1_UART2_APPS_CLK 28
+#define GCC_BLSP1_UART2_APPS_CLK_SRC 29
+#define GCC_BLSP1_UART3_APPS_CLK 30
+#define GCC_BLSP1_UART3_APPS_CLK_SRC 31
+#define GCC_BLSP1_UART4_APPS_CLK 32
+#define GCC_BLSP1_UART4_APPS_CLK_SRC 33
+#define GCC_BOOT_ROM_AHB_CLK 34
[PATCH v3 2/4] clk: qcom: Add SDX55 GCC support
From: Naveen Yadav
Add Global Clock Controller (GCC) support for SDX55 SoCs from Qualcomm.
Signed-off-by: Naveen Yadav
[mani: converted to parent_data, commented critical clocks, cleanups]
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Vinod Koul
---
drivers/clk/qcom/Kconfig |7 +
drivers/clk/qcom/Makefile|1 +
drivers/clk/qcom/gcc-sdx55.c | 1626 ++
3 files changed, 1634 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-sdx55.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 3a965bd326d5..7897a3947e6d 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -413,6 +413,13 @@ config SDM_LPASSCC_845
Say Y if you want to use the LPASS branch clocks of the LPASS clock
controller to reset the LPASS subsystem.
+config SDX_GCC_55
+ tristate "SDX55 Global Clock Controller"
+ help
+ Support for the global clock controller on SDX55 devices.
+ Say Y if you want to use peripheral devices such as UART,
+ SPI, I2C, USB, SD/UFS, PCIe etc.
+
config SM_DISPCC_8250
tristate "SM8150 and SM8250 Display Clock Controller"
depends on SM_GCC_8150 || SM_GCC_8250
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 11ae86febe87..886b877e70c7 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
obj-$(CONFIG_SDM_GPUCC_845) += gpucc-sdm845.o
obj-$(CONFIG_SDM_LPASSCC_845) += lpasscc-sdm845.o
obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
+obj-$(CONFIG_SDX_GCC_55) += gcc-sdx55.o
obj-$(CONFIG_SM_DISPCC_8250) += dispcc-sm8250.o
obj-$(CONFIG_SM_GCC_8150) += gcc-sm8150.o
obj-$(CONFIG_SM_GCC_8250) += gcc-sm8250.o
diff --git a/drivers/clk/qcom/gcc-sdx55.c b/drivers/clk/qcom/gcc-sdx55.c
new file mode 100644
index ..bf114165e24b
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sdx55.c
@@ -0,0 +1,1626 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "reset.h"
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_GPLL0_OUT_EVEN,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL4_OUT_EVEN,
+ P_GPLL5_OUT_MAIN,
+ P_SLEEP_CLK,
+};
+
+static const struct pll_vco lucid_vco[] = {
+ { 24960, 20, 0 },
+};
+
+static struct clk_alpha_pll gpll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .vco_table = lucid_vco,
+ .num_vco = ARRAY_SIZE(lucid_vco),
+ .clkr = {
+ .enable_reg = 0x6d000,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll0",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_lucid_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_lucid_even[] = {
+ { 0x0, 1 },
+ { 0x1, 2 },
+ { 0x3, 4 },
+ { 0x7, 8 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv gpll0_out_even = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_lucid_even,
+ .num_post_div = ARRAY_SIZE(post_div_table_lucid_even),
+ .width = 4,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpll0_out_even",
+ .parent_data = &(const struct clk_parent_data){
+ .hw = ,
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_postdiv_lucid_ops,
+ },
+};
+
+static struct clk_alpha_pll gpll4 = {
+ .offset = 0x76000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .vco_table = lucid_vco,
+ .num_vco = ARRAY_SIZE(lucid_vco),
+ .clkr = {
+ .enable_reg = 0x6d000,
+ .enable_mask = BIT(4),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll4",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_lucid_ops,
+ },
+ },
+};
+
+static struct clk_alpha_pll_postdiv gpll4_out_even = {
+ .offset = 0x76000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .post_div_shift = 8,
+ .post_div_table =
Re: [PATCH v1 0/4] PM: Add dev_wakeup_path() helper
Hi Rafael On 11/18/20 2:08 PM, Rafael J. Wysocki wrote: > On Fri, Nov 6, 2020 at 8:34 AM wrote: >> From: Patrice Chotard >> >> Add dev_wakeup_path() helper to avoid to spread >> dev->power.wakeup_path test in drivers. > OK > >> Cc: amelie.delau...@st.com, >> erwan_le...@st.com, >> fabrice.gasn...@st.com, >> alexandre.tor...@st.com, >> alain.vol...@st.com, >> pierre-yves.mord...@st.com >> >> *** BLURB HERE *** > Hmm? > >> Patrice Chotard (4): >> PM / wakeup: Add dev_wakeup_path() helper >> PM: domains: Make usage of device_wakeup_path() helper >> PM: core: Make usage of device_wakeup_path() helper >> i2c: stm32f7: Make usage of dev_wakeup_path() helper > Please fold the patches into one and add the R-by from Ulf to it. OK, the v2 is on the way. Thanks Patrice > > Thanks!
[PATCH v3 0/4] Add GCC and RPMh clock support for SDX55
Hello, This series adds Global Clock Controller (GCC) and RPMh clock support for SDX55 SoC from Qualcomm with relevant DT bindings. This series has been tested on SDX55 MTP board. The dts patches for this SoC/board will be posted later. Thanks, Mani Changes in v3: * Documented core_bi_pll_test_se clock in dt binding * Collected reviews Changes in v2: * Modified the GCC Kconfig symbol from GCC_SDX55 to SDX_GCC_55 * Added S-o-b tag to bindings patch * Incorporated review comments from Stephen on the gcc driver * Added review tag from Bjorn on RPMh patch Manivannan Sadhasivam (1): clk: qcom: Add support for SDX55 RPMh clocks Naveen Yadav (1): clk: qcom: Add SDX55 GCC support Vinod Koul (2): dt-bindings: clock: Add SDX55 GCC clock bindings dt-bindings: clock: Introduce RPMHCC bindings for SDX55 .../bindings/clock/qcom,gcc-sdx55.yaml| 73 + .../bindings/clock/qcom,rpmhcc.yaml |1 + drivers/clk/qcom/Kconfig |7 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/clk-rpmh.c | 20 + drivers/clk/qcom/gcc-sdx55.c | 1626 + include/dt-bindings/clock/qcom,gcc-sdx55.h| 112 ++ include/dt-bindings/clock/qcom,rpmh.h |1 + 8 files changed, 1841 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml create mode 100644 drivers/clk/qcom/gcc-sdx55.c create mode 100644 include/dt-bindings/clock/qcom,gcc-sdx55.h -- 2.17.1
[PATCH v2] PM: Add dev_wakeup_path() helper
From: Patrice Chotard
Add dev_wakeup_path() helper to avoid to spread
dev->power.wakeup_path test in drivers.
Signed-off-by: Patrice Chotard
Reviewed-by: Ulf Hansson
---
Changes from v1:
- Fold the 4 v1 patches into one
- Add Ulf's Reviewed-by
drivers/base/power/domain.c | 4 ++--
drivers/base/power/main.c| 4 ++--
drivers/i2c/busses/i2c-stm32f7.c | 4 ++--
include/linux/pm_wakeup.h| 10 ++
4 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 743268996336..e0894ef8457c 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1142,7 +1142,7 @@ static int genpd_finish_suspend(struct device *dev, bool
poweroff)
if (ret)
return ret;
- if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
+ if (device_wakeup_path(dev) && genpd_is_active_wakeup(genpd))
return 0;
if (genpd->dev_ops.stop && genpd->dev_ops.start &&
@@ -1196,7 +1196,7 @@ static int genpd_resume_noirq(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
+ if (device_wakeup_path(dev) && genpd_is_active_wakeup(genpd))
return pm_generic_resume_noirq(dev);
genpd_lock(genpd);
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index c7ac49042cee..921c5b2ec30a 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1359,7 +1359,7 @@ static void dpm_propagate_wakeup_to_parent(struct device
*dev)
spin_lock_irq(>power.lock);
- if (dev->power.wakeup_path && !parent->power.ignore_children)
+ if (device_wakeup_path(dev) && !parent->power.ignore_children)
parent->power.wakeup_path = true;
spin_unlock_irq(>power.lock);
@@ -1627,7 +1627,7 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
goto Complete;
/* Avoid direct_complete to let wakeup_path propagate. */
- if (device_may_wakeup(dev) || dev->power.wakeup_path)
+ if (device_may_wakeup(dev) || device_wakeup_path(dev))
dev->power.direct_complete = false;
if (dev->power.direct_complete) {
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index f41f51a176a1..9aa8e65b511e 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -2322,7 +2322,7 @@ static int stm32f7_i2c_suspend(struct device *dev)
i2c_mark_adapter_suspended(_dev->adap);
- if (!device_may_wakeup(dev) && !dev->power.wakeup_path) {
+ if (!device_may_wakeup(dev) && !device_wakeup_path(dev)) {
ret = stm32f7_i2c_regs_backup(i2c_dev);
if (ret < 0) {
i2c_mark_adapter_resumed(_dev->adap);
@@ -2341,7 +2341,7 @@ static int stm32f7_i2c_resume(struct device *dev)
struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev);
int ret;
- if (!device_may_wakeup(dev) && !dev->power.wakeup_path) {
+ if (!device_may_wakeup(dev) && !device_wakeup_path(dev)) {
ret = pm_runtime_force_resume(dev);
if (ret < 0)
return ret;
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index aa3da6611533..196a157456aa 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -84,6 +84,11 @@ static inline bool device_may_wakeup(struct device *dev)
return dev->power.can_wakeup && !!dev->power.wakeup;
}
+static inline bool device_wakeup_path(struct device *dev)
+{
+ return dev->power.wakeup_path;
+}
+
static inline void device_set_wakeup_path(struct device *dev)
{
dev->power.wakeup_path = true;
@@ -174,6 +179,11 @@ static inline bool device_may_wakeup(struct device *dev)
return dev->power.can_wakeup && dev->power.should_wakeup;
}
+static inline bool device_wakeup_path(struct device *dev)
+{
+ return false;
+}
+
static inline void device_set_wakeup_path(struct device *dev) {}
static inline void __pm_stay_awake(struct wakeup_source *ws) {}
--
2.17.1
[PATCH] Input: adp5589-keys - use BIT()
Let's use BIT() macro instead of explicitly shifting '1'.
Signed-off-by: Dmitry Torokhov
---
drivers/input/keyboard/adp5589-keys.c | 69 ++-
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/input/keyboard/adp5589-keys.c
b/drivers/input/keyboard/adp5589-keys.c
index a9b69a268c09..70c8d1c298ee 100644
--- a/drivers/input/keyboard/adp5589-keys.c
+++ b/drivers/input/keyboard/adp5589-keys.c
@@ -7,6 +7,7 @@
* Copyright (C) 2010-2011 Analog Devices Inc.
*/
+#include
#include
#include
#include
@@ -153,48 +154,48 @@
#define ADP5589_5_MAN_ID 0x02
/* GENERAL_CFG Register */
-#define OSC_EN (1 << 7)
+#define OSC_EN BIT(7)
#define CORE_CLK(x)(((x) & 0x3) << 5)
-#define LCK_TRK_LOGIC (1 << 4)/* ADP5589 only */
-#define LCK_TRK_GPI(1 << 3)/* ADP5589 only */
-#define INT_CFG(1 << 1)
-#define RST_CFG(1 << 0)
+#define LCK_TRK_LOGIC BIT(4) /* ADP5589 only */
+#define LCK_TRK_GPIBIT(3) /* ADP5589 only */
+#define INT_CFGBIT(1)
+#define RST_CFGBIT(0)
/* INT_EN Register */
-#define LOGIC2_IEN (1 << 5)/* ADP5589 only */
-#define LOGIC1_IEN (1 << 4)
-#define LOCK_IEN (1 << 3)/* ADP5589 only */
-#define OVRFLOW_IEN(1 << 2)
-#define GPI_IEN(1 << 1)
-#define EVENT_IEN (1 << 0)
+#define LOGIC2_IEN BIT(5) /* ADP5589 only */
+#define LOGIC1_IEN BIT(4)
+#define LOCK_IEN BIT(3) /* ADP5589 only */
+#define OVRFLOW_IENBIT(2)
+#define GPI_IENBIT(1)
+#define EVENT_IEN BIT(0)
/* Interrupt Status Register */
-#define LOGIC2_INT (1 << 5)/* ADP5589 only */
-#define LOGIC1_INT (1 << 4)
-#define LOCK_INT (1 << 3)/* ADP5589 only */
-#define OVRFLOW_INT(1 << 2)
-#define GPI_INT(1 << 1)
-#define EVENT_INT (1 << 0)
+#define LOGIC2_INT BIT(5) /* ADP5589 only */
+#define LOGIC1_INT BIT(4)
+#define LOCK_INT BIT(3) /* ADP5589 only */
+#define OVRFLOW_INTBIT(2)
+#define GPI_INTBIT(1)
+#define EVENT_INT BIT(0)
/* STATUS Register */
-#define LOGIC2_STAT(1 << 7)/* ADP5589 only */
-#define LOGIC1_STAT(1 << 6)
-#define LOCK_STAT (1 << 5)/* ADP5589 only */
+#define LOGIC2_STATBIT(7) /* ADP5589 only */
+#define LOGIC1_STATBIT(6)
+#define LOCK_STAT BIT(5) /* ADP5589 only */
#define KEC0x1F
/* PIN_CONFIG_D Register */
-#define C4_EXTEND_CFG (1 << 6)/* RESET2 */
-#define R4_EXTEND_CFG (1 << 5)/* RESET1 */
+#define C4_EXTEND_CFG BIT(6) /* RESET2 */
+#define R4_EXTEND_CFG BIT(5) /* RESET1 */
/* LOCK_CFG */
-#define LOCK_EN(1 << 0)
+#define LOCK_ENBIT(0)
#define PTIME_MASK 0x3
#define LTIME_MASK 0x3 /* ADP5589 only */
/* Key Event Register xy */
-#define KEY_EV_PRESSED (1 << 7)
-#define KEY_EV_MASK(0x7F)
+#define KEY_EV_PRESSED BIT(7)
+#define KEY_EV_MASK0x7F
#define KEYP_MAX_EVENT 16
#define ADP5589_MAXGPIO19
@@ -472,7 +473,7 @@ static int adp5589_build_gpiomap(struct adp5589_kpad *kpad,
memset(pin_used, false, sizeof(pin_used));
for (i = 0; i < kpad->var->maxgpio; i++)
- if (pdata->keypad_en_mask & (1 << i))
+ if (pdata->keypad_en_mask & BIT(i))
pin_used[i] = true;
for (i = 0; i < kpad->gpimapsize; i++)
@@ -651,13 +652,13 @@ static int adp5589_setup(struct adp5589_kpad *kpad)
unsigned short pin = pdata->gpimap[i].pin;
if (pin <= kpad->var->gpi_pin_row_end) {
- evt_mode1 |= (1 << (pin - kpad->var->gpi_pin_row_base));
+ evt_mode1 |= BIT(pin - kpad->var->gpi_pin_row_base);
} else {
evt_mode2 |=
- ((1 << (pin - kpad->var->gpi_pin_col_base)) & 0xFF);
+ BIT(pin - kpad->var->gpi_pin_col_base) & 0xFF;
if (!kpad->is_adp5585)
- evt_mode3 |= ((1 << (pin -
- kpad->var->gpi_pin_col_base)) >> 8);
+ evt_mode3 |=
+ BIT(pin - kpad->var->gpi_pin_col_base) >> 8;
}
}
@@ -677,7 +678,7 @@ static int adp5589_setup(struct adp5589_kpad *kpad)
dev_warn(>dev, "Conflicting pull resistor config\n");
for (i = 0; i <= kpad->var->max_row_num; i++) {
- unsigned val = 0, bit = (1 << i);
+ unsigned val = 0, bit = BIT(i);
if (pdata->pullup_en_300k & bit)
val = 0;
else if (pdata->pulldown_en_300k & bit)
@@ -697,7
Re: Collecting both remote and "local" coverage with KCOV
On Wed, Nov 18, 2020 at 3:21 AM Alexander Bulekov wrote: > > On 201116 1805, Andrey Konovalov wrote: > > On Mon, Nov 16, 2020 at 9:35 AM Dmitry Vyukov wrote: > > > > > > On Mon, Nov 16, 2020 at 3:39 AM Alexander Bulekov wrote: > > > > > > > > Hello, > > > > I'm trying to collect coverage over the syscalls issued by my process, > > > > as well as the kthreads spawned as a result of these syscalls > > > > (eg coverage over vhost ioctls and the worker kthread). Is there a way > > > > to collect coverage with both KCOV_REMOTE_ENABLE(with common_handle) and > > > > KCOV_ENABLE, simultaneously? > > > > > > > > Based on the code it seems that these two modes are mutually > > > > exclusive within a single task, but I don't think this is mentioned in > > > > the Documentation, so I want to make sure I'm not missing something. > > > > > > Hi Alex, > > > > > > Yes, it's probably not supported within a single task. The easiest way > > > to verify is to try it ;) > > > > > > It is possible to collect both coverages, but you will need 2 threads > > > (one just to set up remote KCOV). > > > > > > Unless I am missing any fundamental limitations, I would say it would > > > be reasonable to support this within a single task as well. > > > > I think the reason we did that initially, is because we don't care > > about normal coverage for USB emitting pseudo-syscalls. Filed a bug > > for this: https://bugzilla.kernel.org/show_bug.cgi?id=210225 > > I'm interested in adding support for this. Looking through the code, I > can think of ~two approaches: > > 1.) Allow the same kcov fd to be used to track coverage with both > KCOV_REMOTE_ENABLE and KCOV_ENABLE. If we try to use the same coverage > bitmap for both the remote and the local coverage, I think the local > part would have to deal with the kcov_remote_lock. If the local part > continues to write directly into the user-space coverage-area, as it > does now, it seems it would require locking for each __sanitizer_cov > call. Alternatively, the local and the remote parts could write into > different coverage-bitmaps, but I'm not sure if there is a neat way to > do this. This has 2 problems: - performance (__sanitizer_cov is by far the most performance critical part of kernel with KCOV=y) - recurions, locks are also traced, so it's not that we really can call anything there > 2.) Allow multiple kcov fds to be used by the same task. In the task, > keep a linked-list of pointers to kcov objects (remote or local). For > each __sanitizer_... call, walk the linked list and check if any of the > kcov objects match the requirements (trace_cmp/trace_pc/remote). This > would also have the side-effect of enabling simultaneous PC and CMP > tracing. Of course, it seems that this would add some overhead (in the > case of a single open fd, there would be extra pointer dereferences to > get the area[], size, etc). Walking linked list in __sanitizer_... has the same performance problems, but I think we don't really need to do it. Assuming we have at most 1 KCOV that traces the task itself we can continue keeping it cached in task_struct: https://elixir.bootlin.com/linux/v5.10-rc4/source/include/linux/sched.h#L1254 and __sanitizer_... will continue using these fields. For the kcov pointer in task struct: https://elixir.bootlin.com/linux/v5.10-rc4/source/include/linux/sched.h#L1257 we either have a linked list, or 1 pointer for local tracking and a separate list for remote kcov's: struct kcov *kcov; // local tracing struct kcov *remote_kcovs; // remote tracing, can be more than 1 Whichever is better I am not sure, it seems that some functions would benefit from a single list (KCOV_DISABLE), while others would benefit from separate fields (KCOV_ENABLE). Maybe the simplest code will be if we use both approaches -- put all kcov's into a list, but also cache the local kcov into a separate field? Then KCOV_DISABLE could just walk the list, but KCOV_ENABLE can continue checking 1 field.
[PATCH] Input: adp5589-keys - mark suspend and resume methods as __maybe_unused
This improves compile coverage of the code; unused code will be dropped by
the linker.
Signed-off-by: Dmitry Torokhov
---
drivers/input/keyboard/adp5589-keys.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/adp5589-keys.c
b/drivers/input/keyboard/adp5589-keys.c
index 31145a85c819..a9b69a268c09 100644
--- a/drivers/input/keyboard/adp5589-keys.c
+++ b/drivers/input/keyboard/adp5589-keys.c
@@ -1016,8 +1016,7 @@ static int adp5589_probe(struct i2c_client *client,
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-static int adp5589_suspend(struct device *dev)
+static int __maybe_unused adp5589_suspend(struct device *dev)
{
struct adp5589_kpad *kpad = dev_get_drvdata(dev);
struct i2c_client *client = kpad->client;
@@ -1033,7 +1032,7 @@ static int adp5589_suspend(struct device *dev)
return 0;
}
-static int adp5589_resume(struct device *dev)
+static int __maybe_unused adp5589_resume(struct device *dev)
{
struct adp5589_kpad *kpad = dev_get_drvdata(dev);
struct i2c_client *client = kpad->client;
@@ -1048,7 +1047,6 @@ static int adp5589_resume(struct device *dev)
return 0;
}
-#endif
static SIMPLE_DEV_PM_OPS(adp5589_dev_pm_ops, adp5589_suspend, adp5589_resume);
--
2.29.2.299.gdc1121823c-goog
--
Dmitry
[PATCH v3] arm64: tegra: jetson-tx1: Fix USB_VBUS_EN0 regulator
USB Host mode is broken at OTG port of Jetson-TX1 platform because
USB_VBUS_EN0 regulator (regulator@11) is being overwritten by vdd-cam-1v2
regulator. This commit rearrange USB_VBUS_EN0 to be regulator@14.
Fixes: 257c8047be44 ("arm64: tegra: jetson-tx1: Add camera supplies")
Cc: sta...@vger.kernel.org
Signed-off-by: JC Kuo
Reviewed-by: Jon Hunter
---
v3:
add 'Cc: sta...@vger.kernel.org' tag
v2:
add 'Fixes:' tag
add Reviewed-by: Jon Hunter
.../arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 20 +--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index e18e1a9a3011..a9caaf7c0d67 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@ -1663,16 +1663,6 @@ vdd_usb_vbus: regulator@9 {
vin-supply = <_5v0_sys>;
};
- vdd_usb_vbus_otg: regulator@11 {
- compatible = "regulator-fixed";
- regulator-name = "USB_VBUS_EN0";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- gpio = < TEGRA_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
- enable-active-high;
- vin-supply = <_5v0_sys>;
- };
-
vdd_hdmi: regulator@10 {
compatible = "regulator-fixed";
regulator-name = "VDD_HDMI_5V0";
@@ -1712,4 +1702,14 @@ vdd_cam_1v8: regulator@13 {
enable-active-high;
vin-supply = <_3v3_sys>;
};
+
+ vdd_usb_vbus_otg: regulator@14 {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_VBUS_EN0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < TEGRA_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <_5v0_sys>;
+ };
};
--
2.25.1
Re: [PATCH v2 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring
On Wed, Nov 18, 2020 at 05:26:53PM -0800, Guenter Roeck wrote: > On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote: > > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote: > > > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote: > > > > On Wed, Nov 18, 2020 at 03:09:27PM -0800, rentao.b...@gmail.com wrote: > > > > > From: Tao Ren > > > > > > > > > > The patch series adds hardware monitoring driver for the Maxim MAX127 > > > > > chip. > > > > > > > > Hi Tao > > > > > > > > Why are using sending a hwmon driver to the networking mailing list? > > > > > > > > Andrew > > > > > > Hi Andrew, > > > > > > I added netdev because the mailing list is included in "get_maintainer.pl > > > Documentation/hwmon/index.rst" output. Is it the right command to find > > > reviewers? Could you please suggest? Thank you. > > > > I have no idea why running get_maintainer.pl on > > Documentation/hwmon/index.rst returns such a large list of mailing > > lists and people. For some reason it includes everyone in the XDP > > maintainer list. If anyone has an idea how that happens, please > > let me know - we'll want to get this fixed to avoid the same problem > > in the future. > > > > I found it. The XDP maintainer entry has: > > K:xdp > > This matches Documentation/hwmon/index.rst. > > $ grep xdp Documentation/hwmon/index.rst >xdpe12284 > > It seems to me that a context match such as "xdp" in MAINTAINERS isn't > really appropriate. "xdp" matches a total of 348 files in the kernel. > The large majority of those is not XDP related. The maintainers > of XDP (and all the listed mailing lists) should not be surprised > to get a large number of odd review requests if they want to review > every single patch on files which include the term "xdp". > > Guenter Thanks Guenter and Andrew. Given xdp maintainers were included by mistake, I will remove them from the future discussions of this hwmon patch series. Cheers, Tao
Re: [RFC PATCH v3] tools/x86: add kcpuid tool to show raw CPU features
Hi Borislav,
Thanks for reviewing and trying.
On Wed, Nov 18, 2020 at 08:15:29PM +0100, Borislav Petkov wrote:
> On Thu, Oct 22, 2020 at 01:21:23PM +0800, Feng Tang wrote:
> > diff --git a/tools/arch/x86/kcpuid/kcpuid.c b/tools/arch/x86/kcpuid/kcpuid.c
> > new file mode 100644
> > index 000..9bd35b7
> > --- /dev/null
> > +++ b/tools/arch/x86/kcpuid/kcpuid.c
> > @@ -0,0 +1,618 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> You need here:
>
> #define _GNU_SOURCE
Thanks for the fix.
> otherwise:
>
> cc -Wextra -O2 -Wall -I../../../include -o kcpuid kcpuid.c
> kcpuid.c: In function ‘parse_line’:
> kcpuid.c:324:6: warning: implicit declaration of function ‘strcasestr’; did
> you mean ‘strcasecmp’? [-Wimplicit-function-declaration]
> 324 | if (strcasestr(buf, "EAX"))
> | ^~
> | strcasecmp
> Also, options text needs fixing:
>
> usage: kcpuid [-abdfhr] [-l leaf] [-s subleaf]
> -a|--all Show info of all CPUID leafs and
> subleafs(default on)
> -b|--bitflagsShow boolean flags only
> -d|--detail Show details of the flag/fields
> -f|--flags Show boolean flags only
>
> that f is user_csv, above in the "usage" line too.
>
> -h|--helpShow usage info
> -l|--leaf=index Specify the leaf you want to check
> -r|--raw Show raw cpuid data
> -s|--subleaf=sub Specify the subleaf you want to check
Will fix.
> > +/*
> > + * Parse text file, and construct the array of all CPUID leafs and subleafs
> > + */
> > +static void parse_text(void)
> > +{
> > + FILE *file;
> > + char *filename, *line = NULL;
>
> Do here:
>
> char *filename = def_csv;
>
> > + size_t len = 0;
> > + int ret;
> > +
> > + if (show_raw)
> > + return;
> > +
> > + filename = user_csv ? user_csv : def_csv;
>
> And now you do:
>
> if (user_csv)
> filename = user_csv;
Ok, will change.
> But something's not working still. I've added debug output and it chokes
> on the test data:
>
> $ ./kcpuid -f cpuid.csv
> This platform has 51 CPUID leafs and subleafs.
>
> parse_text: filename: cpuid.csv
> open
> parsing [# The basic row format is:
> ]parsing [# LEAF,SUBLEAF,register_name,bits,short name,long description
> ]parsing [
> ]parsing [# Leaf 00H
> ]parsing [ 0,0, EAX, 31:0, max_basic_leafs, Max input value
> for supported subleafs
> ]parsing [# Leaf 01H
> ]parsing [ 1,0, ECX, 28, avx, AVX instruction supported
> ]parsing [ 1,0, ECX, 29, f16c, 16-bit floating-point
> conversion instruction supported
> ]parsing [ 1,0, ECX, 30, rdrand, RDRAND instruction
> supported
> ]parsing [
> ]parsing [#
> ]parsing [# !!! Test data for testing different options, will be updated in
> formal version
> ]parsing [#
> ]parsing [ 4,0, ECX, 1, aaa, AAA
> Segmentation fault
I just tried the patch on one Debian 9 and 2 Ubuntus (16.04 & 20.10) with
different gcc versions, and haven't reproduced it yet. What's your distro
and gcc version? I will try to reproduce.
One thing I doubted is the getline() in parse_text() needs a accompany
free() according to its man page, but it can be added after the loop.
Anyway I attached one debug verison kcpuid.c which prints more info, thanks.
- Feng
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
// SPDX-License-Identifier: GPL-2.0
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
typedef unsigned int u32;
typedef unsigned long long u64;
char *def_csv = "/usr/share/hwdata/cpuid.csv";
char *user_csv;
struct bits_desc {
int start, end; /* start and end bits */
int value; /* 0 or 1 for 1-bit flag */
char simp[32];
char detail[256];
};
/* Descriptor info for eax/ebx/ecx/edx */
struct reg_desc {
int nr; /* number of valid entries */
struct bits_desc descs[32];
};
enum {
R_EAX = 0,
R_EBX,
R_ECX,
R_EDX,
NR_REGS
};
struct subleaf {
u32 index;
u32 sub;
u32 eax, ebx, ecx, edx;
struct reg_desc info[NR_REGS]; /* eax, ebx, ecx, edx */
};
/* cpuid_func represents one leaf (basic or extended) */
struct cpuid_func {
/*
* Array of subleafs for this func, if there is no subleafs
* then the leafs[0] is the main leaf
*/
struct subleaf *leafs;
int nr;
};
struct cpuid_range {
/* Array of leafs in this range */
struct cpuid_func *funcs;
/* Number of valid leafs */
int nr;
bool is_ext;
};
/*
* basic: basic functions started from 0
* ext:extended functions started from 0x8000
*/
struct cpuid_range *leafs_basic, *leafs_ext;
static int num_leafs;
static bool is_amd;
static bool show_details;
static bool show_all = true;
static bool show_raw;
static bool show_flags_only;
static u32 user_index = 0x;
static u32 user_sub = 0x;
static int flines;
Re: [PATCH] arm64: vmlinux.lds.S: Drop redundant *.init.rodata.*
On Thu, 19 Nov 2020 at 02:45, Youling Tang wrote:
>
> We currently try to emit *.init.rodata.* twice, once in INIT_DATA, and once
> in the line immediately following it. As the two section definitions are
> identical, the latter is redundant and can be dropped.
>
> This patch drops the redundant *.init.rodata.* section definition.
>
> Signed-off-by: Youling Tang
.init.rodata.* was added to INIT_DATA in
266ff2a8f51f02b429a987d87634697eb0d01d6a, so removing it here seems
reasonable. However, it does conflict with the for-next/lto branch in
the arm64 tree.
> ---
> arch/arm64/kernel/vmlinux.lds.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 1bda604..7dba3c4 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -201,7 +201,7 @@ SECTIONS
> INIT_CALLS
> CON_INITCALL
> INIT_RAM_FS
> - *(.init.rodata.* .init.bss) /* from the EFI stub */
> + *(.init.bss)/* from the EFI stub */
> }
> .exit.data : {
> EXIT_DATA
> --
> 2.1.0
>
Re: [PATCH 2/2] hwspinlock: add sunxi hardware spinlock support
On Wed, Nov 18, 2020 at 08:36:24PM +0100, Wilken Gottwalt wrote: > On Wed, 18 Nov 2020 16:37:33 +0100 > Maxime Ripard wrote: > > Hi Wilken, > > > > On Wed, Nov 18, 2020 at 11:02:40AM +0100, Wilken Gottwalt wrote: > > > Adds the sunxi_hwspinlock driver and updates makefiles/maintainers. > > > > > > Signed-off-by: Wilken Gottwalt > > > > A more descriptive commit log would be welcome here, for example > > containing on which SoC this driver can be used, and on which it was > > tested. > > can you help me here a bit? I still try to figure out how to do patch sets > properly. Some kernel submitting documentation says everything goes into the > coverletter and other documentation only tells how to split the patches. So > what would be the right way? A quick example based on my patch set would be > really helpful. I mean, the split between your patches and so on is good, you got that right The thing I wanted better details on is the commit log itself, so the message attached to that patch. > > This is the third attempt at that driver, and you can find the previous > > versions here: > > https://patchwork.kernel.org/project/linux-arm-kernel/cover/20200210170143.20007-1-nbori...@suse.com/ > > https://lore.kernel.org/patchwork/patch/706512/ > > > > Most of the comments on those series still apply to yours. > > Oh, I wrote my driver 2-3 years ago and just prepared it for mainline. I > wasn't aware of other attempts. I really should have checked this. Though, > I really want to get to the point where this driver is good enough for > mainline. Hmmm, it is interesting how similar these drivers are. Looks like > the other developers also got inspired by the already existing hwspinlock > drivers. :D Yeah, it looks like you all got the same inspiration :) > > Most importantly, this hwspinlock is used to synchronize the ARM cores > > and the ARISC. How did you test this driver? > > Yes, you are right, I should have mentioned this. I have a simple test kernel > module for this. But I must admit, testing the ARISC is very hard and I have > no real idea how to do it. Testing the hwspinlocks in general seems to work > with my test kernel module, but I'm not sure if this is really sufficient. I > can provide the code for it if you like. What would be the best way? Github? > Just mailing a patch? > > The test module produces these results: > > # insmod > /lib/modules/5.9.8/kernel/drivers/hwspinlock/sunxi_hwspinlock_test.ko > [ 45.395672] [init] sunxi hwspinlock test driver start > [ 45.400775] [init] start test locks > [ 45.404263] [run ] testing 32 locks > [ 45.407804] [test] testing lock 0 - > [ 45.411652] [test] taking lock attempt #0 succeded > [ 45.416438] [test] try taken lock attempt #0 > [ 45.420735] [test] unlock/take attempt #0 > [ 45.424752] [test] taking lock attempt #1 succeded > [ 45.429556] [test] try taken lock attempt #1 > [ 45.433823] [test] unlock/take attempt #1 > [ 45.437862] [test] testing lock 1 - > [ 45.441699] [test] taking lock attempt #0 succeded > [ 45.446484] [test] try taken lock attempt #0 > [ 45.450768] [test] unlock/take attempt #0 > [ 45.454774] [test] taking lock attempt #1 succeded > [ 45.459576] [test] try taken lock attempt #1 > [ 45.463843] [test] unlock/take attempt #1 > . > . > . > [ 46.309925] [test] testing lock 30 - > [ 46.313852] [test] taking lock attempt #0 succeded > [ 46.318654] [test] try taken lock attempt #0 > [ 46.322920] [test] unlock/take attempt #0 > [ 46.326944] [test] taking lock attempt #1 succeded > [ 46.331729] [test] try taken lock attempt #1 > [ 46.335994] [test] unlock/take attempt #1 > [ 46.340021] [test] testing lock 31 - > [ 46.343947] [test] taking lock attempt #0 succeded > [ 46.348749] [test] try taken lock attempt #0 > [ 46.353016] [test] unlock/take attempt #0 > [ 46.357040] [test] taking lock attempt #1 succeded > [ 46.361825] [test] try taken lock attempt #1 > [ 46.366090] [test] unlock/take attempt #1 > [ 46.370112] [init] end test locks That doesn't really test for contention though, and dealing with contention is mostly what this hardware is about. Could you make a small test with crust to see if when the arisc has taken the lock, the ARM cores can't take it? Maxime signature.asc Description: PGP signature
[tip:x86/sgx] BUILD SUCCESS 0eaa8d153a1d573e53b8283c90db44057d1376f6
allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20201118 x86_64 randconfig-a003-20201118 x86_64 randconfig-a004-20201118 x86_64 randconfig-a002-20201118 x86_64 randconfig-a006-20201118 x86_64 randconfig-a001-20201118 i386 randconfig-a006-20201119 i386 randconfig-a005-20201119 i386 randconfig-a002-20201119 i386 randconfig-a001-20201119 i386 randconfig-a003-20201119 i386 randconfig-a004-20201119 i386 randconfig-a006-20201118 i386 randconfig-a005-20201118 i386 randconfig-a002-20201118 i386 randconfig-a001-20201118 i386 randconfig-a003-20201118 i386 randconfig-a004-20201118 i386 randconfig-a012-20201119 i386 randconfig-a014-20201119 i386 randconfig-a016-20201119 i386 randconfig-a011-20201119 i386 randconfig-a013-20201119 i386 randconfig-a015-20201119 i386 randconfig-a012-20201118 i386 randconfig-a014-20201118 i386 randconfig-a016-20201118 i386 randconfig-a011-20201118 i386 randconfig-a013-20201118 i386 randconfig-a015-20201118 riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a015-20201118 x86_64 randconfig-a014-20201118 x86_64 randconfig-a011-20201118 x86_64 randconfig-a013-20201118 x86_64 randconfig-a016-20201118 x86_64 randconfig-a012-20201118 x86_64 randconfig-a005-20201119 x86_64 randconfig-a003-20201119 x86_64 randconfig-a004-20201119 x86_64 randconfig-a002-20201119 x86_64 randconfig-a006-20201119 x86_64 randconfig-a001-20201119 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:x86/cleanups] BUILD SUCCESS 31d8546033053b98de00846ede8088bdbe38651d
s3c2410_defconfig mipsbcm63xx_defconfig sh se7705_defconfig arm cm_x300_defconfig sh r7780mp_defconfig arc alldefconfig powerpc mpc83xx_defconfig powerpc tqm8540_defconfig powerpc wii_defconfig m68k sun3_defconfig powerpc kmeter1_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20201118 x86_64 randconfig-a003-20201118 x86_64 randconfig-a004-20201118 x86_64 randconfig-a002-20201118 x86_64 randconfig-a006-20201118 x86_64 randconfig-a001-20201118 i386 randconfig-a006-20201119 i386 randconfig-a005-20201119 i386 randconfig-a002-20201119 i386 randconfig-a001-20201119 i386 randconfig-a003-20201119 i386 randconfig-a004-20201119 i386 randconfig-a006-20201118 i386 randconfig-a005-20201118 i386 randconfig-a002-20201118 i386 randconfig-a001-20201118 i386 randconfig-a003-20201118 i386 randconfig-a004-20201118 x86_64 randconfig-a015-20201119 x86_64 randconfig-a014-20201119 x86_64 randconfig-a011-20201119 x86_64 randconfig-a013-20201119 x86_64 randconfig-a016-20201119 x86_64 randconfig-a012-20201119 i386 randconfig-a012-20201119 i386 randconfig-a014-20201119 i386 randconfig-a016-20201119 i386 randconfig-a011-20201119 i386 randconfig-a013-20201119 i386 randconfig-a015-20201119 i386 randconfig-a012-20201118 i386 randconfig-a014-20201118 i386 randconfig-a016-20201118 i386 randconfig-a011-20201118 i386 randconfig-a013-20201118 i386 randconfig-a015-20201118 riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a005-20201119 x86_64 randconfig-a003-20201119 x86_64 randconfig-a004-20201119 x86_64 randconfig-a002-20201119 x86_64 randconfig-a006-20201119 x86_64 randconfig-a001-20201119 x86_64 randconfig-a015-20201118 x86_64 randconfig-a014-20201118 x86_64 randconfig-a011-20201118 x86_64 randconfig-a013-20201118 x86_64 randconfig-a016-20201118 x86_64 randconfig-a012-20201118 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v1] scsi: ufs: Fix race between shutdown and runtime resume flow
On 2020-11-19 14:29, Stanley Chu wrote:
If UFS host device is in runtime-suspended state while
UFS shutdown callback is invoked, UFS device shall be
resumed for register accesses. Currently only UFS local
runtime resume function will be invoked to wake up the host.
This is not enough because if someone triggers runtime
resume from block layer, then race may happen between
shutdown and runtime resume flow, and finally lead to
unlocked register access.
To fix this kind of issues, in ufshcd_shutdown(), use
pm_runtime_get_sync() instead of resuming UFS device by
ufshcd_runtime_resume() "internally" to let runtime PM
framework manage the whole resume flow.
Fixes: 57d104c153d3 ("ufs: add UFS power management support")
Signed-off-by: Stanley Chu
Reviewed-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 80cbce414678..bb16cc04f106 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8941,11 +8941,7 @@ int ufshcd_shutdown(struct ufs_hba *hba)
if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
goto out;
- if (pm_runtime_suspended(hba->dev)) {
- ret = ufshcd_runtime_resume(hba);
- if (ret)
- goto out;
- }
+ pm_runtime_get_sync(hba->dev);
ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
out:
[PATCH v3 4/4] mtd: parsers: afs: Fix freeing the part name memory in failure
In the case of failure while parsing the partitions, the iterator should
be pre decremented by one before starting to free the memory allocated
by kstrdup(). Because in the failure case, kstrdup() will not succeed
and thus no memory will be allocated for the current iteration.
Cc: Linus Walleij
Fixes: 1fca1f6abb38 ("mtd: afs: simplify partition parsing")
Reviewed-by: Linus Walleij
Signed-off-by: Manivannan Sadhasivam
---
drivers/mtd/parsers/afs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/parsers/afs.c b/drivers/mtd/parsers/afs.c
index 980e332bdac4..26116694c821 100644
--- a/drivers/mtd/parsers/afs.c
+++ b/drivers/mtd/parsers/afs.c
@@ -370,10 +370,8 @@ static int parse_afs_partitions(struct mtd_info *mtd,
return i;
out_free_parts:
- while (i >= 0) {
+ while (--i >= 0)
kfree(parts[i].name);
- i--;
- }
kfree(parts);
*pparts = NULL;
return ret;
--
2.17.1
[PATCH v3 3/4] mtd: rawnand: qcom: Add support for Qcom SMEM parser
Add support for using Qualcomm SMEM based flash partition parser in
Qualcomm NAND controller.
Signed-off-by: Manivannan Sadhasivam
---
drivers/mtd/nand/raw/qcom_nandc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index 777fb0de0680..1b031aeac18b 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2797,6 +2797,8 @@ static int qcom_nandc_setup(struct qcom_nand_controller
*nandc)
return 0;
}
+static const char * const probes[] = { "qcomsmem", NULL };
+
static int qcom_nand_host_init_and_register(struct qcom_nand_controller *nandc,
struct qcom_nand_host *host,
struct device_node *dn)
@@ -2860,7 +2862,7 @@ static int qcom_nand_host_init_and_register(struct
qcom_nand_controller *nandc,
}
}
- ret = mtd_device_register(mtd, NULL, 0);
+ ret = mtd_device_parse_register(mtd, probes, NULL, NULL, 0);
if (ret)
nand_cleanup(chip);
--
2.17.1
[PATCH v3 1/4] dt-bindings: mtd: partitions: Add binding for Qcom SMEM parser
Add YAML binding for Qualcomm Shared Memory (SMEM) Flash partition
parser.
Signed-off-by: Manivannan Sadhasivam
---
.../mtd/partitions/qcom,smem-part.yaml| 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
diff --git
a/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
b/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
new file mode 100644
index ..cf3f8c1e035d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/qcom,smem-part.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SMEM NAND flash partition parser binding
+
+maintainers:
+ - Manivannan Sadhasivam
+
+description: |
+ The Qualcomm SoCs supporting the NAND controller interface features a Shared
+ Memory (SMEM) based partition table scheme. The maximum partitions supported
+ varies between partition table revisions. V3 supports maximum 16 partitions
+ and V4 supports 48 partitions.
+
+properties:
+ compatible:
+const: qcom,smem-part
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+flash {
+partitions {
+compatible = "qcom,smem-part";
+};
+};
--
2.17.1
[PATCH v3 2/4] mtd: parsers: Add Qcom SMEM parser
NAND based Qualcomm platforms have the partition table populated in the
Shared Memory (SMEM). Hence, add a parser for parsing the partitions
from it.
Signed-off-by: Manivannan Sadhasivam
---
drivers/mtd/parsers/Kconfig| 8 ++
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/qcomsmempart.c | 170 +
3 files changed, 179 insertions(+)
create mode 100644 drivers/mtd/parsers/qcomsmempart.c
diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
index e72354322f62..d90c30229052 100644
--- a/drivers/mtd/parsers/Kconfig
+++ b/drivers/mtd/parsers/Kconfig
@@ -160,3 +160,11 @@ config MTD_REDBOOT_PARTS_READONLY
'FIS directory' images, enable this option.
endif # MTD_REDBOOT_PARTS
+
+config MTD_QCOMSMEM_PARTS
+ tristate "Qualcomm SMEM NAND flash partition parser"
+ depends on MTD_NAND_QCOM || COMPILE_TEST
+ depends on QCOM_SMEM
+ help
+ This provides support for parsing partitions from Shared Memory (SMEM)
+ for NAND flash on Qualcomm platforms.
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index b0c5f62f9e85..50eb0b0a2210 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
obj-$(CONFIG_MTD_SHARPSL_PARTS)+= sharpslpart.o
obj-$(CONFIG_MTD_REDBOOT_PARTS)+= redboot.o
+obj-$(CONFIG_MTD_QCOMSMEM_PARTS) += qcomsmempart.o
diff --git a/drivers/mtd/parsers/qcomsmempart.c
b/drivers/mtd/parsers/qcomsmempart.c
new file mode 100644
index ..808cb33d71f8
--- /dev/null
+++ b/drivers/mtd/parsers/qcomsmempart.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm SMEM NAND flash partition parser
+ *
+ * Copyright (C) 2020, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SMEM_AARM_PARTITION_TABLE 9
+#define SMEM_APPS 0
+
+#define SMEM_FLASH_PART_MAGIC1 0x55ee73aa
+#define SMEM_FLASH_PART_MAGIC2 0xe35ebddb
+#define SMEM_FLASH_PTABLE_V3 3
+#define SMEM_FLASH_PTABLE_V4 4
+#define SMEM_FLASH_PTABLE_MAX_PARTS_V3 16
+#define SMEM_FLASH_PTABLE_MAX_PARTS_V4 48
+#define SMEM_FLASH_PTABLE_HDR_LEN (4 * sizeof(u32))
+#define SMEM_FLASH_PTABLE_NAME_SIZE16
+
+/**
+ * struct smem_flash_pentry - SMEM Flash partition entry
+ * @name: Name of the partition
+ * @offset: Offset in blocks
+ * @length: Length of the partition in blocks
+ * @attr: Flags for this partition
+ */
+struct smem_flash_pentry {
+ char name[SMEM_FLASH_PTABLE_NAME_SIZE];
+ __le32 offset;
+ __le32 length;
+ u8 attr;
+} __packed __aligned(4);
+
+/**
+ * struct smem_flash_ptable - SMEM Flash partition table
+ * @magic1: Partition table Magic 1
+ * @magic2: Partition table Magic 2
+ * @version: Partition table version
+ * @numparts: Number of partitions in this ptable
+ * @pentry: Flash partition entries belonging to this ptable
+ */
+struct smem_flash_ptable {
+ __le32 magic1;
+ __le32 magic2;
+ __le32 version;
+ __le32 numparts;
+ struct smem_flash_pentry pentry[SMEM_FLASH_PTABLE_MAX_PARTS_V4];
+} __packed __aligned(4);
+
+static int parse_qcomsmem_part(struct mtd_info *mtd,
+ const struct mtd_partition **pparts,
+ struct mtd_part_parser_data *data)
+{
+ struct smem_flash_pentry *pentry;
+ struct smem_flash_ptable *ptable;
+ size_t len = SMEM_FLASH_PTABLE_HDR_LEN;
+ struct mtd_partition *parts;
+ int ret, i, numparts;
+ char *name, *c;
+
+ pr_debug("Parsing partition table info from SMEM\n");
+ ptable = qcom_smem_get(SMEM_APPS, SMEM_AARM_PARTITION_TABLE, );
+ if (IS_ERR(ptable)) {
+ pr_err("Error reading partition table header\n");
+ return PTR_ERR(ptable);
+ }
+
+ /* Verify ptable magic */
+ if (le32_to_cpu(ptable->magic1) != SMEM_FLASH_PART_MAGIC1 ||
+ le32_to_cpu(ptable->magic2) != SMEM_FLASH_PART_MAGIC2) {
+ pr_err("Partition table magic verification failed\n");
+ return -EINVAL;
+ }
+
+ /* Ensure that # of partitions is less than the max we have allocated */
+ numparts = le32_to_cpu(ptable->numparts);
+ if (numparts > SMEM_FLASH_PTABLE_MAX_PARTS_V4) {
+ pr_err("Partition numbers exceed the max limit\n");
+ return -EINVAL;
+ }
+
+ /* Find out length of partition data based on table version */
+ if (le32_to_cpu(ptable->version) <= SMEM_FLASH_PTABLE_V3) {
+ len = SMEM_FLASH_PTABLE_HDR_LEN +
SMEM_FLASH_PTABLE_MAX_PARTS_V3 *
+ sizeof(struct smem_flash_pentry);
+ } else if (le32_to_cpu(ptable->version) == SMEM_FLASH_PTABLE_V4) {
+
[PATCH v3 0/4] Add support for Qcom SMEM based NAND parser
Hello, This series adds support for parsing the partitions defined in Shared Memory (SMEM) of the Qualcomm platforms supporting NAND interface. Current parser only supports V3 and V4 of the partition tables. This series has been tested on SDX55 MTP board which has an onboard NAND device. Thanks, Mani Changes in v3: * Handled le32 parameters in parser, collected review from Linus W. Changes in v2: * Added additionalProperties: false and removed unit address in binding Manivannan Sadhasivam (4): dt-bindings: mtd: partitions: Add binding for Qcom SMEM parser mtd: parsers: Add Qcom SMEM parser mtd: rawnand: qcom: Add support for Qcom SMEM parser mtd: parsers: afs: Fix freeing the part name memory in failure .../mtd/partitions/qcom,smem-part.yaml| 33 drivers/mtd/nand/raw/qcom_nandc.c | 4 +- drivers/mtd/parsers/Kconfig | 8 + drivers/mtd/parsers/Makefile | 1 + drivers/mtd/parsers/afs.c | 4 +- drivers/mtd/parsers/qcomsmempart.c| 170 ++ 6 files changed, 216 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml create mode 100644 drivers/mtd/parsers/qcomsmempart.c -- 2.17.1
Re: [PATCH v2 5/5] Input: adp5589: use devm_add_action_or_reset() for register clear
On Thu, Nov 12, 2020 at 09:43:08AM +0200, Alexandru Ardelean wrote: > The driver clears the general configuration register during the remove() > hook. This should also be done in case the driver exits on error. > > This change move the clear of that register to the > devm_add_action_or_reset() hook. > > Signed-off-by: Alexandru Ardelean Applied, thank you. -- Dmitry
Re: [PATCH v2 4/5] Input: adp5589: use devm_gpiochip_add_data() for gpios
On Thu, Nov 12, 2020 at 09:43:07AM +0200, Alexandru Ardelean wrote: > This change makes use of the devm_gpiochip_add_data() function. With this > the gpiochip_remove() function can be removed, and the > adp5589_gpio_remove() function as well. > > The kpad->export_gpio variable is also redundant now, and has been removed. > > Signed-off-by: Alexandru Ardelean Applied, thank you. -- Dmitry
Re: [PATCH v2 2/5] Input: adp5589: use device-managed function in adp5589_keypad_add()
Hi Alexandru,
On Thu, Nov 12, 2020 at 09:43:05AM +0200, Alexandru Ardelean wrote:
> This change makes use of the devm_input_allocate_device() function, which
> gets rid of the input_free_device() and input_unregister_device() calls.
>
> When a device is allocated via input_allocate_device(), the
> input_register_device() call will also be device-managed, so there is no
> longer need to manually call unregister.
>
> Also, the irq is allocated with the devm_request_threaded_irq(), so with
> these two changes, the adp5589_keypad_remove() function is no longer
> needed.
>
> This cleans up the error & exit paths.
> It also looks like the input_free_device() should have been called on the
> remove() hook, but doesn't look like it is.
Actually it should not be called once input_unregister_device() is
called. If you check, you will see that in probe() we set the pointer to
input device to NULL after calling unregister, which makes subsequent
call to input_free_device() a noop. We did that so that we have single
error handling flow.
I dropped this paragraph.
>
> This change may also also fix some potential leaks that were probably
> omitted earlier.
This one too.
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/input/keyboard/adp5589-keys.c | 47 +++
> 1 file changed, 11 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/input/keyboard/adp5589-keys.c
> b/drivers/input/keyboard/adp5589-keys.c
> index 922497b65ab0..e96ffd5ed69e 100644
> --- a/drivers/input/keyboard/adp5589-keys.c
> +++ b/drivers/input/keyboard/adp5589-keys.c
> @@ -909,7 +909,7 @@ static int adp5589_keypad_add(struct adp5589_kpad *kpad,
> unsigned int revid)
> return -EINVAL;
> }
>
> - input = input_allocate_device();
> + input = devm_input_allocate_device(>dev);
> if (!input)
> return -ENOMEM;
>
> @@ -953,38 +953,19 @@ static int adp5589_keypad_add(struct adp5589_kpad
> *kpad, unsigned int revid)
> __set_bit(kpad->gpimap[i].sw_evt, input->swbit);
>
> error = input_register_device(input);
> - if (error) {
> - dev_err(>dev, "unable to register input device\n");
If you want to drop error messages, please send a separate patch with
justification.
I restored error messgaes, and applied.
Thank you.
--
Dmitry
Re: [PATCH v2 3/5] Input: adp5589: remove setup/teardown hooks for gpios
On Thu, Nov 12, 2020 at 09:43:06AM +0200, Alexandru Ardelean wrote: > This is currently just dead code. It's from around a time when > platform-data was used, and a board could hook it's own special callback > for setup/teardown, and a private object (via 'context'). > > This change removes it, as there are no more users in mainline for this. > > Signed-off-by: Alexandru Ardelean Applied, thank you. -- Dmitry
WARNING: net/mptcp/protocol.c:719 mptcp_reset_timer+0x40/0x50
While running kselftest net/mptcp: mptcp_join.sh on x86_64 device running linux next 20201118 tag the following warning was noticed. # selftests: net/mptcp: mptcp_join.sh [ 1276.053194] [ cut here ] [ 1276.057857] WARNING: CPU: 2 PID: 27452 at /usr/src/kernel/net/mptcp/protocol.c:719 mptcp_reset_timer+0x40/0x50 [ 1276.067870] Modules linked in: xt_tcpudp xt_bpf act_mirred cls_u32 ip6table_mangle mpls_gso mpls_iptunnel mpls_router sch_etf ip6table_nat xt_nat iptable_nat nf_nat ip6table_filter xt_conntrack nf_conntrack nf_defrag_ipv4 libcrc32c ip6_tables nf_defrag_ipv6 bridge stp llc vrf xt_policy sch_fq 8021q iptable_filter xt_mark ip_tables x_tables cls_bpf sch_ingress veth algif_hash x86_pkg_temp_thermal fuse [last unloaded: test_blackhole_dev] [ 1276.106416] CPU: 2 PID: 27452 Comm: kworker/2:4 Tainted: GW K 5.10.0-rc4-next-20201118 #1 [ 1276.115808] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.0b 07/27/2017 [ 1276.123293] Workqueue: events mptcp_worker [ 1276.127407] RIP: 0010:mptcp_reset_timer+0x40/0x50 [ 1276.132119] Code: 45 ff 3c 07 74 22 48 8b 87 30 08 00 00 48 85 c0 74 18 48 8b 15 e1 34 d4 00 48 8d b7 50 06 00 00 48 01 c2 e8 72 3b ca ff c9 c3 <0f> 0b b8 c8 00 00 00 eb df 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 [ 1276.150863] RSP: 0018:a20b41137d28 EFLAGS: 00010246 [ 1276.156091] RAX: RBX: 95a6d444b090 RCX: [ 1276.163222] RDX: RSI: RDI: 95a6d444a800 [ 1276.170354] RBP: a20b41137d30 R08: R09: [ 1276.177487] R10: 00024200 R11: fefefefefefefeff R12: 95a6d444a800 [ 1276.184621] R13: R14: 95a6da9e44d8 R15: [ 1276.191752] FS: () GS:95a9dfd0() knlGS: [ 1276.199838] CS: 0010 DS: ES: CR0: 80050033 [ 1276.205585] CR2: 7f1770beb810 CR3: 000131026005 CR4: 003706e0 [ 1276.212718] DR0: DR1: DR2: [ 1276.219849] DR3: DR6: fffe0ff0 DR7: 0400 [ 1276.226983] Call Trace: [ 1276.229438] mptcp_push_pending+0x5bf/0x6c0 [ 1276.233633] mptcp_worker+0xf0/0x650 [ 1276.237218] ? mptcp_worker+0xf0/0x650 [ 1276.240971] ? process_one_work+0x21c/0x5e0 [ 1276.245157] process_one_work+0x289/0x5e0 [ 1276.249171] worker_thread+0x3c/0x3f0 [ 1276.252836] ? __kthread_parkme+0x6f/0xa0 [ 1276.256848] ? process_one_work+0x5e0/0x5e0 [ 1276.261034] kthread+0x142/0x160 [ 1276.264269] ? kthread_insert_work_sanity_check+0x60/0x60 [ 1276.269674] ret_from_fork+0x22/0x30 [ 1276.273254] irq event stamp: 0 [ 1276.276316] hardirqs last enabled at (0): [<>] 0x0 [ 1276.282587] hardirqs last disabled at (0): [] copy_process+0x75d/0x1d60 [ 1276.290759] softirqs last enabled at (0): [] copy_process+0x75d/0x1d60 [ 1276.298932] softirqs last disabled at (0): [<>] 0x0 [ 1276.305197] ---[ end trace fe4f318db7e06cdb ]--- Reported-by: Naresh Kamboju metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git commit: 2052923327794192c5d884623b5ee5fec1867bda git describe: next-20201118 make_kernelversion: 5.10.0-rc4 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-next/902/config Full test log link, https://lkft.validation.linaro.org/scheduler/job/1952957#L15217 -- Linaro LKFT https://lkft.linaro.org
Re: [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression
On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> Hi,
>
> Could you add intel-...@lists.freedesktop.org into reports going
> forward.
>
> Quoting kernel test robot (2020-11-11 17:58:11)
> >
> > Greeting,
> >
> > FYI, we noticed a -54.0% regression of
> > phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> > due to commit:
>
> How many runs are there on the bad version to ensure the bisect is
> repeatable?
test 4 times.
zxing@inn:/result/phoronix-test-suite/performance-true-Radial_Gradient_Paint-1024x1024-jxrendermark-1.2.4-ucode=0xd6-monitor=da39a3ee/lkp-cfl-d1/debian-x86_64-phoronix/x86_64-rhel-8.3/gcc-9/59dd13ad310793757e34afa489dd6fc8544fc3da$
grep -r "operations_per_second" */stats.json
0/stats.json:
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
4133.487932,
1/stats.json:
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
4120.421503,
2/stats.json:
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
4188.414835,
3/stats.json:
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
4068.549514,
>
> According to Chris test has various factors affecting why the result
> could fluctuate and has been known. Reverting the patch did not have
> an effect on the benchmark and was not expected to do so, either.
>
> Is there some mechanism to queue a re-run?
>
> Would it make sense to do further runs before sending out the e-mail
> to avoid false positives.
>
> It could of course be also solved by sticking to tests that have less
> fluctuation in them.
>
> Regards, Joonas
>
> >
> >
> > commit: 59dd13ad310793757e34afa489dd6fc8544fc3da ("drm/i915/gem: Flush
> > coherency domains on first set-domain-ioctl")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> >
> > in testcase: phoronix-test-suite
> > on test machine: 12 threads Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G
> > memory
> > with following parameters:
> >
> > need_x: true
> > test: jxrendermark-1.2.4
> > option_a: Radial Gradient Paint
> > option_b: 1024x1024
> > cpufreq_governor: performance
> > ucode: 0xd6
> >
> > test-description: The Phoronix Test Suite is the most comprehensive testing
> > and benchmarking platform available that provides an extensible framework
> > for which new tests can be easily added.
> > test-url: http://www.phoronix-test-suite.com/
> >
> >
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot
> >
> >
> > Details are as below:
> > -->
> >
> >
> > To reproduce:
> >
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp install job.yaml # job file is attached in this email
> > bin/lkp run job.yaml
> >
> > =
> > compiler/cpufreq_governor/kconfig/need_x/option_a/option_b/rootfs/tbox_group/test/testcase/ucode:
> > gcc-9/performance/x86_64-rhel-8.3/true/Radial Gradient
> > Paint/1024x1024/debian-x86_64-phoronix/lkp-cfl-d1/jxrendermark-1.2.4/phoronix-test-suite/0xd6
> >
> > commit:
> > 0dccdba51e ("Merge tag 'gvt-fixes-2020-10-30' of
> > https://github.com/intel/gvt-linux into drm-intel-fixes")
> > 59dd13ad31 ("drm/i915/gem: Flush coherency domains on first
> > set-domain-ioctl")
> >
> > 0dccdba51e852271 59dd13ad310793757e34afa489d
> > ---
> > %stddev %change %stddev
> > \ |\
> > 8980 ± 2% -54.0% 4127
> > phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> > 9.00 +13.9% 10.25 ± 4%
> > phoronix-test-suite.time.percent_of_cpu_this_job_got
> >
> >
> >
> >
> >
> >
> >
> >
> > 1
> > +---+
> > |
> > |
> >9000 |-+.+. .+.+.+.+.+. .+. .+. .+. .+.+. .+. .+. .+. .+.+.
> > .|
> > |.+ + +.+ + +.+ + +.+.+ + +.+ + +.+
> > |
> > |
> > |
> >8000 |-+
> > |
> > |
> > |
> >7000
Re: [PATCH v2 1/5] Input: adp5589: use devm_kzalloc() to allocate the kpad object
On Thu, Nov 12, 2020 at 09:43:04AM +0200, Alexandru Ardelean wrote: > This removes the need to manually free the kpad object and cleans up some > exit/error paths. > The error path cleanup should reduce the risk of any memory leaks with this > object. > > Signed-off-by: Alexandru Ardelean Applied, thank you. -- Dmitry
Re: [PATCH] leds: lp50xx: add missing fwnode_handle_put in error handling case
在 2020/11/11 21:27, Dan Murphy 写道:
Hello
On 11/10/20 9:21 PM, Qinglang Miao wrote:
Fix to goto child_out to do fwnode_handle_put(child)
from the error handling case rather than simply return,
as done elsewhere in this function.
Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB
LED driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/leds/leds-lp50xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
index 5fb4f24aeb2e..49a997b2c781 100644
--- a/drivers/leds/leds-lp50xx.c
+++ b/drivers/leds/leds-lp50xx.c
@@ -488,7 +488,7 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
mc_led_info = devm_kcalloc(priv->dev, LP50XX_LEDS_PER_MODULE,
sizeof(*mc_led_info), GFP_KERNEL);
if (!mc_led_info)
- return -ENOMEM;
+ goto child_out;
Thanks for the patch.
Need to set ret = -ENOMEM; then do child_out so the error is reported
properly
Dan
.
Hi Dan,
I've sent v2 on this fix, setting ret as well.
Thanks!
[PATCH] bpf: Check the return value of dev_get_by_index_rcu()
From: Kaixu Xia The return value of dev_get_by_index_rcu() can be NULL, so here it is need to check the return value and return error code if it is NULL. Signed-off-by: Kaixu Xia --- net/core/filter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/filter.c b/net/core/filter.c index 2ca5eecebacf..1263fe07170a 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -5573,6 +5573,8 @@ BPF_CALL_4(bpf_skb_fib_lookup, struct sk_buff *, skb, struct net_device *dev; dev = dev_get_by_index_rcu(net, params->ifindex); + if (unlikely(!dev)) + return -EINVAL; if (!is_skb_forwardable(dev, skb)) rc = BPF_FIB_LKUP_RET_FRAG_NEEDED; } -- 2.20.0
[PATCH] stm class: Fix a double vfree in stm_register_device()
While testing stm, stm_register_device() caused a vfree issue:
-
Trying to vfree() nonexistent vm area (ad30ebb6)
Call Trace:
__vfree+0x41/0xe0
vfree+0x5f/0xa0
stm_register_device+0x4b1/0x660 [stm_core]
dummy_stm_init+0x248/0x360 [dummy_stm]
do_one_initcall+0x149/0x7e0
do_init_module+0x1ef/0x700
load_module+0x3467/0x4140
__do_sys_finit_module+0x10d/0x1a0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x468ded
-
This is because put_device(>dev) calls stm_device_release,
which would call vfree(stm) inside, so there's no need to do
vfree again.
Fix this problem by simply return err after put_device().
Fixes: b5e2ced9bf81 ("stm class: Use vmalloc for the master map")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/hwtracing/stm/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 2712e699b..80b7c81d5 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -915,6 +915,8 @@ int stm_register_device(struct device *parent, struct
stm_data *stm_data,
/* matches device_initialize() above */
put_device(>dev);
+
+ return err;
err_free:
vfree(stm);
--
2.23.0
[PATCH] ipmi: msghandler: Suppress suspicious RCU usage warning
while running ipmi, ipmi_smi_watcher_register() caused
a suspicious RCU usage warning.
-
=
WARNING: suspicious RCU usage
5.10.0-rc3+ #1 Not tainted
-
drivers/char/ipmi/ipmi_msghandler.c:750 RCU-list traversed in non-reader
section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.0/4254:
stack backtrace:
CPU: 0 PID: 4254 Comm: syz-executor.0 Not tainted 5.10.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/
01/2014
Call Trace:
dump_stack+0x19d/0x200
ipmi_smi_watcher_register+0x2d3/0x340 [ipmi_msghandler]
acpi_ipmi_init+0xb1/0x1000 [acpi_ipmi]
do_one_initcall+0x149/0x7e0
do_init_module+0x1ef/0x700
load_module+0x3467/0x4140
__do_sys_finit_module+0x10d/0x1a0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x468ded
-
It is safe because smi_watchers_mutex is locked and srcu_read_lock
has been used, so simply pass lockdep_is_held() to the
list_for_each_entry_rcu() to suppress this warning.
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/char/ipmi/ipmi_msghandler.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
index 8774a3b8f..c44ad1846 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -747,7 +747,8 @@ int ipmi_smi_watcher_register(struct ipmi_smi_watcher
*watcher)
list_add(>link, _watchers);
index = srcu_read_lock(_interfaces_srcu);
- list_for_each_entry_rcu(intf, _interfaces, link) {
+ list_for_each_entry_rcu(intf, _interfaces, link,
+ lockdep_is_held(_watchers_mutex)) {
int intf_num = READ_ONCE(intf->intf_num);
if (intf_num == -1)
--
2.23.0
[PATCH v2] leds: lp50xx: add missing fwnode_handle_put in error handling case
Fix to set ret and goto child_out for fwnode_handle_put(child)
in the error handling case rather than simply return, as done
elsewhere in this function.
Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED
driver")
Reported-by: Hulk Robot
Suggested-by: Pavel Machek
Signed-off-by: Qinglang Miao
---
v2: forget to set ret on v1
drivers/leds/leds-lp50xx.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
index 5fb4f24ae..f13117eed 100644
--- a/drivers/leds/leds-lp50xx.c
+++ b/drivers/leds/leds-lp50xx.c
@@ -487,8 +487,10 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
*/
mc_led_info = devm_kcalloc(priv->dev, LP50XX_LEDS_PER_MODULE,
sizeof(*mc_led_info), GFP_KERNEL);
- if (!mc_led_info)
- return -ENOMEM;
+ if (!mc_led_info) {
+ ret = -ENOMEM;
+ goto child_out;
+ }
fwnode_for_each_child_node(child, led_node) {
ret = fwnode_property_read_u32(led_node, "color",
--
2.23.0
[PATCH] net: cw1200: fix missing destroy_workqueue() on error in cw1200_init_common
Add the missing destroy_workqueue() before return from
cw1200_init_common in the error handling case.
Fixes:a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN
chipsets")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/net/wireless/st/cw1200/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/st/cw1200/main.c
b/drivers/net/wireless/st/cw1200/main.c
index f7fe56aff..326b1cc1d 100644
--- a/drivers/net/wireless/st/cw1200/main.c
+++ b/drivers/net/wireless/st/cw1200/main.c
@@ -381,6 +381,7 @@ static struct ieee80211_hw *cw1200_init_common(const u8
*macaddr,
CW1200_LINK_ID_MAX,
cw1200_skb_dtor,
priv)) {
+ destroy_workqueue(priv->workqueue);
ieee80211_free_hw(hw);
return NULL;
}
@@ -392,6 +393,7 @@ static struct ieee80211_hw *cw1200_init_common(const u8
*macaddr,
for (; i > 0; i--)
cw1200_queue_deinit(>tx_queue[i - 1]);
cw1200_queue_stats_deinit(>tx_queue_stats);
+ destroy_workqueue(priv->workqueue);
ieee80211_free_hw(hw);
return NULL;
}
--
2.23.0
[PATCH] samples: vfio-mdev: fix return value of error branch in mdpy_fb_probe()
pci_release_regions() should be called in these error branches, so
I set ret and use goto err_release_regions intead of simply return
-EINVAL.
Fixes: cacade1946a4 ("sample: vfio mdev display - guest driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
samples/vfio-mdev/mdpy-fb.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
index 21dbf63d6..c944a6697 100644
--- a/samples/vfio-mdev/mdpy-fb.c
+++ b/samples/vfio-mdev/mdpy-fb.c
@@ -117,15 +117,18 @@ static int mdpy_fb_probe(struct pci_dev *pdev,
if (format != DRM_FORMAT_XRGB) {
pci_err(pdev, "format mismatch (0x%x != 0x%x)\n",
format, DRM_FORMAT_XRGB);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_release_regions;
}
if (width < 100 || width > 1) {
pci_err(pdev, "width (%d) out of range\n", width);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_release_regions;
}
if (height < 100 || height > 1) {
pci_err(pdev, "height (%d) out of range\n", height);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_release_regions;
}
pci_info(pdev, "mdpy found: %dx%d framebuffer\n",
width, height);
--
2.23.0
Re: [PATCH net-next v3 0/6] net/x25: netdev event handling
On 2020-11-18 15:47, Xie He wrote: On Wed, Nov 18, 2020 at 5:59 AM Martin Schiller wrote: --- Changes to v2: o restructure complete patch-set o keep netdev event handling in layer3 (X.25) But... Won't it be better to handle L2 connections in L2 code? For example, if we are running X.25 over XOT, we can decide in the XOT layer whether and when we reconnect in case the TCP connection is dropped. We can decide how long we wait for responses before we consider the TCP connection to be dropped. If we still want "on-demand" connections in certain L2's, we can also implement it in that L2 without the need to change L3. Every L2 has its own characteristics. It might be better to let different L2's handle their connections in their own way. This gives L2 the flexibility to handle their connections according to their actual link characteristics. Letting L3 handle L2 connections also makes L2 code too related to / coupled with L3 code, which makes the logic complex. OK, I will give it a try. But we need to keep the possibility to initiate and terminate the L2 connection from L3. In the on demand scenario i mentioned, the L2 should be connected when the first L3 logical channel goes up and needs to be disconnected, when the last L3 logical channel on an interface is cleared. o add patch to fix lapb_connect_request() for DCE o add patch to handle carrier loss correctly in lapb o drop patch for x25_neighbour param handling this may need fixes/cleanup and will be resubmitted later. Changes to v1: o fix 'subject_prefix' and 'checkpatch' warnings --- Martin Schiller (6): net/x25: handle additional netdev events net/lapb: fix lapb_connect_request() for DCE net/lapb: handle carrier loss correctly net/lapb: fix t1 timer handling for DCE net/x25: fix restart request/confirm handling net/x25: remove x25_kill_by_device()
Re: [PATCH 1/4] HID: hid-sensor-custom: Add custom sensor iio support
Hi Ye,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on iio/togreg]
[also build test WARNING on linus/master v5.10-rc4 next-20201118]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Ye-Xiang/add-custom-hinge-sensor-support/20201119-110842
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: c6x-randconfig-r003-20201119 (attached as .config)
compiler: c6x-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/1f33733d65038ade4af057df7e5c126485ecb7c6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Ye-Xiang/add-custom-hinge-sensor-support/20201119-110842
git checkout 1f33733d65038ade4af057df7e5c126485ecb7c6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/hid/hid-sensor-custom.c: In function 'store_value':
drivers/hid/hid-sensor-custom.c:401:7: warning: variable 'ret' set but not
used [-Wunused-but-set-variable]
401 | int ret;
| ^~~
In file included from include/linux/device.h:15,
from include/linux/miscdevice.h:7,
from drivers/hid/hid-sensor-custom.c:11:
drivers/hid/hid-sensor-custom.c: In function 'get_known_custom_sensor_index':
>> drivers/hid/hid-sensor-custom.c:847:24: warning: format '%ld' expects
>> argument of type 'long int', but argument 3 has type '__kernel_size_t' {aka
>> 'unsigned int'} [-Wformat=]
847 | hid_err(hsdev->hdev, " %ld != %ld\n", strlen(buf),
|^~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
19 | #define dev_fmt(fmt) fmt
| ^~~
include/linux/hid.h:1180:2: note: in expansion of macro 'dev_err'
1180 | dev_err(&(hid)->dev, fmt, ##__VA_ARGS__)
| ^~~
drivers/hid/hid-sensor-custom.c:847:3: note: in expansion of macro 'hid_err'
847 | hid_err(hsdev->hdev, " %ld != %ld\n", strlen(buf),
| ^~~
drivers/hid/hid-sensor-custom.c:847:28: note: format string is defined here
847 | hid_err(hsdev->hdev, " %ld != %ld\n", strlen(buf),
| ~~^
||
|long int
| %d
In file included from include/linux/device.h:15,
from include/linux/miscdevice.h:7,
from drivers/hid/hid-sensor-custom.c:11:
drivers/hid/hid-sensor-custom.c:847:24: warning: format '%ld' expects
argument of type 'long int', but argument 4 has type '__kernel_size_t' {aka
'unsigned int'} [-Wformat=]
847 | hid_err(hsdev->hdev, " %ld != %ld\n", strlen(buf),
|^~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
19 | #define dev_fmt(fmt) fmt
| ^~~
include/linux/hid.h:1180:2: note: in expansion of macro 'dev_err'
1180 | dev_err(&(hid)->dev, fmt, ##__VA_ARGS__)
| ^~~
drivers/hid/hid-sensor-custom.c:847:3: note: in expansion of macro 'hid_err'
847 | hid_err(hsdev->hdev, " %ld != %ld\n", strlen(buf),
| ^~~
drivers/hid/hid-sensor-custom.c:847:35: note: format string is defined here
847 | hid_err(hsdev->hdev, " %ld != %ld\n", strlen(buf),
| ~~^
| |
| long int
| %d
vim +847 drivers/hid/hid-sensor-custom.c
771
772 static int get_known_custom_sensor_index(struct hid_sensor_hub_device
*hsdev)
773 {
774 struct hid_sensor_hub_attribute_info sensor_manufacturer = { 0
};
775 struct hid_sensor_hub_attribute_info sensor_luid_info = { 0 };
776 int report_size;
777 int ret;
778 u16 *w_buf;
779 int w_buf_len;
780 char *buf;
781 int buf_len;
782 int i;
783 int index;
784
785 w_buf_len = sizeof(u16) * HID_CUSTOM_MAX_FEATURE_BYTES;
786 buf_len = sizeof(char) * HID_CUSTOM_MAX_FEATURE_BYTES;
Re: [PATCH v2] ASoC: fsl_sai: Correct the clock source for mclk0
On Thu, Nov 19, 2020 at 02:40:38PM +0800, Shengjiu Wang wrote: > On VF610, mclk0 = bus_clk; > On i.MX6SX/6UL/6ULL/7D, mclk0 = mclk1; > On i.MX7ULP, mclk0 = bus_clk; > On i.MX8QM/8QXP, mclk0 = bus_clk; > On i.MX8MQ/8MN/8MM/8MP, mclk0 = bus_clk; > > So add variable mclk0_is_mclk1 in fsl_sai_soc_data to > distinguish these platforms. > > Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen
[PATCH v2] ASoC: fsl_sai: Correct the clock source for mclk0
On VF610, mclk0 = bus_clk;
On i.MX6SX/6UL/6ULL/7D, mclk0 = mclk1;
On i.MX7ULP, mclk0 = bus_clk;
On i.MX8QM/8QXP, mclk0 = bus_clk;
On i.MX8MQ/8MN/8MM/8MP, mclk0 = bus_clk;
So add variable mclk0_is_mclk1 in fsl_sai_soc_data to
distinguish these platforms.
Signed-off-by: Shengjiu Wang
---
changes in v2:
- rename mclk0_mclk1_match to mclk0_is_mclk1
- skip MCLK0 when it is same as MCLK1 on master clock scanning
sound/soc/fsl/fsl_sai.c | 20 ++--
sound/soc/fsl/fsl_sai.h | 1 +
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 3e5c1eaccd5e..f3d3d20d35d7 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -359,7 +359,14 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool
tx, u32 freq)
if (sai->is_slave_mode)
return 0;
- for (id = 0; id < FSL_SAI_MCLK_MAX; id++) {
+ /*
+* There is no point in polling MCLK0 if it is identical to MCLK1.
+* And given that MQS use case has to use MCLK1 though two clocks
+* are the same, we simply skip MCLK0 and start to find from MCLK1.
+*/
+ id = sai->soc_data->mclk0_is_mclk1 ? 1 : 0;
+
+ for (; id < FSL_SAI_MCLK_MAX; id++) {
clk_rate = clk_get_rate(sai->mclk_clk[id]);
if (!clk_rate)
continue;
@@ -1040,7 +1047,6 @@ static int fsl_sai_probe(struct platform_device *pdev)
sai->bus_clk = NULL;
}
- sai->mclk_clk[0] = sai->bus_clk;
for (i = 1; i < FSL_SAI_MCLK_MAX; i++) {
sprintf(tmp, "mclk%d", i);
sai->mclk_clk[i] = devm_clk_get(>dev, tmp);
@@ -1051,6 +1057,11 @@ static int fsl_sai_probe(struct platform_device *pdev)
}
}
+ if (sai->soc_data->mclk0_is_mclk1)
+ sai->mclk_clk[0] = sai->mclk_clk[1];
+ else
+ sai->mclk_clk[0] = sai->bus_clk;
+
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
@@ -1165,6 +1176,7 @@ static const struct fsl_sai_soc_data fsl_sai_vf610_data =
{
.use_edma = false,
.fifo_depth = 32,
.reg_offset = 0,
+ .mclk0_is_mclk1 = false,
};
static const struct fsl_sai_soc_data fsl_sai_imx6sx_data = {
@@ -1172,6 +1184,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx6sx_data
= {
.use_edma = false,
.fifo_depth = 32,
.reg_offset = 0,
+ .mclk0_is_mclk1 = true,
};
static const struct fsl_sai_soc_data fsl_sai_imx7ulp_data = {
@@ -1179,6 +1192,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx7ulp_data
= {
.use_edma = false,
.fifo_depth = 16,
.reg_offset = 8,
+ .mclk0_is_mclk1 = false,
};
static const struct fsl_sai_soc_data fsl_sai_imx8mq_data = {
@@ -1186,6 +1200,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8mq_data
= {
.use_edma = false,
.fifo_depth = 128,
.reg_offset = 8,
+ .mclk0_is_mclk1 = false,
};
static const struct fsl_sai_soc_data fsl_sai_imx8qm_data = {
@@ -1193,6 +1208,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8qm_data
= {
.use_edma = true,
.fifo_depth = 64,
.reg_offset = 0,
+ .mclk0_is_mclk1 = false,
};
static const struct of_device_id fsl_sai_ids[] = {
diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
index 4bbcd0dbe8f1..ff2619f1b214 100644
--- a/sound/soc/fsl/fsl_sai.h
+++ b/sound/soc/fsl/fsl_sai.h
@@ -219,6 +219,7 @@
struct fsl_sai_soc_data {
bool use_imx_pcm;
bool use_edma;
+ bool mclk0_is_mclk1;
unsigned int fifo_depth;
unsigned int reg_offset;
};
--
2.27.0
[PATCH 0/2] introduce sunxi hwspinlock
From: fuyao this series add hwspinlock of sunxi. it provides hardware assistance for synchronization between the multiple processors in the system. (Or1k, Cortex-A7, Cortex-A53, Xtensa) fuyao (2): dt-bindings: hwlock: add sunxi hwlock hwspinlock: add SUNXI implementation .../bindings/hwlock/sunxi,hwspinlock.yaml | 46 MAINTAINERS | 6 + drivers/hwspinlock/Kconfig| 10 + drivers/hwspinlock/Makefile | 1 + drivers/hwspinlock/sunxi_hwspinlock.c | 205 ++ 5 files changed, 268 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwlock/sunxi,hwspinlock.yaml create mode 100644 drivers/hwspinlock/sunxi_hwspinlock.c -- 2.29.2
[PATCH 2/2] hwspinlock: add SUNXI implementation
From: fuyao
Add hwspinlock support for the SUNXI Hardware Spinlock device.
The Hardware Spinlock device on SUNXI provides hardware assistance
for synchronization between the multiple processors in the system
(Cortex-A7, or1k, Xtensa DSP, Cortex-A53)
Signed-off-by: fuyao
---
MAINTAINERS | 6 +
drivers/hwspinlock/Kconfig| 10 ++
drivers/hwspinlock/Makefile | 1 +
drivers/hwspinlock/sunxi_hwspinlock.c | 205 ++
4 files changed, 222 insertions(+)
create mode 100644 drivers/hwspinlock/sunxi_hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f0..68d25574432d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -737,6 +737,12 @@ L: linux-me...@vger.kernel.org
S: Maintained
F: drivers/staging/media/sunxi/cedrus/
+ALLWINNER HWSPINLOCK DRIVER
+M: fuyao
+S: Maintained
+F: drivers/hwspinlock/sunxi_hwspinlock.c
+F: Documentation/devicetree/bindings/hwlock/sunxi,hwspinlock.yaml
+
ALPHA PORT
M: Richard Henderson
M: Ivan Kokshaysky
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 32cd26352f381..4d0d516dcb544 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -55,6 +55,16 @@ config HWSPINLOCK_STM32
If unsure, say N.
+config HWSPINLOCK_SUNXI
+ tristate "SUNXI Hardware Spinlock device"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ help
+ Say y here to support the SUNXI Hardware Semaphore functionality,
which
+ provides a synchronisation mechanism for the various processor on the
+ SoC.
+
+ If unsure, say N.
+
config HSEM_U8500
tristate "STE Hardware Semaphore functionality"
depends on ARCH_U8500 || COMPILE_TEST
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index ed053e3f02be4..839a053205f73 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_HWSPINLOCK_SIRF) += sirf_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_SPRD) += sprd_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_STM32) += stm32_hwspinlock.o
obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
+obj-$(CONFIG_HWSPINLOCK_SUNXI) += sunxi_hwspinlock.o
diff --git a/drivers/hwspinlock/sunxi_hwspinlock.c
b/drivers/hwspinlock/sunxi_hwspinlock.c
new file mode 100644
index 0..2c3dc148c9b72
--- /dev/null
+++ b/drivers/hwspinlock/sunxi_hwspinlock.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SUNXI hardware spinlock driver
+ *
+ * Copyright (C) 2020 Allwinnertech - http://www.allwinnertech.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hwspinlock_internal.h"
+
+/* hardware spinlock register list */
+#defineLOCK_SYS_STATUS_REG (0x)
+#defineLOCK_STATUS_REG (0x0010)
+#define LOCK_BASE_OFFSET(0x0100)
+#define LOCK_BASE_ID(0)
+
+/* Possible values of SPINLOCK_LOCK_REG */
+#define SPINLOCK_NOTTAKEN (0) /* free */
+#define SPINLOCK_TAKEN (1) /* locked */
+
+struct sunxi_spinlock_config {
+ int nspin;
+};
+
+static int sunxi_hwspinlock_trylock(struct hwspinlock *lock)
+{
+ void __iomem *lock_addr = lock->priv;
+
+ /* attempt to acquire the lock by reading its value */
+ return (readl(lock_addr) == SPINLOCK_NOTTAKEN);
+}
+
+static void sunxi_hwspinlock_unlock(struct hwspinlock *lock)
+{
+ void __iomem *lock_addr = lock->priv;
+
+ /* release the lock by writing 0 to it */
+ writel(SPINLOCK_NOTTAKEN, lock_addr);
+}
+
+/*
+ * relax the SUNXI interconnect while spinning on it.
+ *
+ * The specs recommended that the retry delay time will be
+ * just over half of the time that a requester would be
+ * expected to hold the lock.
+ *
+ * in sunxi spinlock time less then 200 cycles
+ *
+ * The number below is taken from an hardware specs example,
+ * obviously it is somewhat arbitrary.
+ */
+static void sunxi_hwspinlock_relax(struct hwspinlock *lock)
+{
+ ndelay(50);
+}
+
+static const struct hwspinlock_ops sunxi_hwspinlock_ops = {
+ .trylock = sunxi_hwspinlock_trylock,
+ .unlock = sunxi_hwspinlock_unlock,
+ .relax = sunxi_hwspinlock_relax,
+};
+
+struct sunxi_hwspinlock_device {
+ struct hwspinlock_device *bank;
+
[PATCH 1/2] dt-bindings: hwlock: add sunxi hwlock
From: fuyao
SUNXI hwspinlock binding DT schema format
Signed-off-by: fuyao
---
.../bindings/hwlock/sunxi,hwspinlock.yaml | 46 +++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/hwlock/sunxi,hwspinlock.yaml
diff --git a/Documentation/devicetree/bindings/hwlock/sunxi,hwspinlock.yaml
b/Documentation/devicetree/bindings/hwlock/sunxi,hwspinlock.yaml
new file mode 100644
index 0..68ce93b6d2bcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/sunxi,hwspinlock.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/sunxi,hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SUNXI HwSpinlock for SUNXI
+
+maintainers:
+ - fuyao
+
+properties:
+ compatible:
+enum:
+ - allwinner,h3-hwspinlock, # for h3-hwspinlock
+ - allwinner,h6-hwspinlock, # for h6-hwspinlock
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+
+ - |
+hwspinlock: spinlock@1c17000 {
+compatible = "allwinner,h3-hwspinlock";
+reg = <0x0 0x01c17000 0x0 0x1000>;
+clocks = < CLK_BUS_SPINLOCK>;
+resets = < RST_BUS_SPINLOCK>;
+};
+
+ - |
+hwspinlock: spinlock@3004000 {
+compatible = "allwinner,h6-hwspinlock";
+reg = <0x0 0x03004000 0x0 0x1000>;
+clocks = < CLK_BUS_SPINLOCK>;
+resets = < RST_BUS_SPINLOCK>;
+};
+
--
2.29.2
Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies
On 02-11-20, 12:01, Nicola Mazzucato wrote: > Second proposal: > > Another option could be for each driver to store internally the performance > dependencies and let the driver directly provide the correct cpumask for > any consumer. >From the discussion that happened in this thread, looks like we are going to do it. > Whilst this works fine for energy model (see above), it is not the case Good. > (currently) for cpufreq_cooling, thus we would need to add a new interface for And this is not required for now as we discussed. -- viresh
Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies
On 18-11-20, 13:00, Rafael J. Wysocki wrote: > On Wed, Nov 18, 2020 at 5:42 AM Viresh Kumar wrote: > > > > On 17-11-20, 14:06, Rafael J. Wysocki wrote: > > > Is this really a cpufreq thing, though, or is it arch stuff? I think > > > the latter, because it is not necessary for anything in cpufreq. > > > > > > Yes, acpi-cpufreq happens to know this information, because it uses > > > processor_perflib, but the latter may as well be used by the arch > > > enumeration of CPUs and the freqdomain_cpus mask may be populated from > > > there. > > > > > > As far as cpufreq is concerned, if the interface to the hardware is > > > per-CPU, there is one CPU per policy and cpufreq has no business > > > knowing anything about the underlying hardware coordination. > > > > It won't be used by cpufreq for now at least and yes I understand your > > concern. I opted for this because we already have a cpufreq > > implementation for the same thing and it is usually better to reuse > > this kind of stuff instead of inventing it over. > > Do you mean related_cpus and real_cpus? Sorry about the confusion, I meant freqdomain_cpus only. > That's the granularity of the interface to the hardware I'm talking about. > > Strictly speaking, it means "these CPUs share a HW interface for perf > control" and it need not mean "these CPUs are in the same > clock/voltage domain". Specifically, it need not mean "these CPUs are > the only CPUs in the given clock/voltage domain". That's what it > means when the control is exercised by manipulating OPPs directly, but > not in general. > > In the ACPI case, for example, what the firmware tells you need not > reflect the HW topology in principle. It only tells you whether or > not it wants you to coordinate a given group of CPUs and in what way, > but this may not be the whole picture from the HW perspective. If you > need the latter, you need more information in general (at least you > need to assume that what the firmware tells you actually does reflect > the HW topology on the given SoC). > > So yes, in the particular case of OPP-based perf control, cpufreq > happens to have the same information that is needed by the other > subsystems, but otherwise it may not and what I'm saying is that it > generally is a mistake to expect cpufreq to have that information or > to be able to obtain it without the help of the arch/platform code. > Hence, it would be a mistake to design an interface based on that > expectation. > > Or looking at it from a different angle, today a cpufreq driver is > only required to specify the granularity of the HW interface for perf > control via related_cpus. It is not required to obtain extra > information beyond that. If a new mask to be populated by it is > added, the driver may need to do more work which is not necessary from > the perf control perspective. That doesn't look particularly clean to > me. > > Moreover, adding such a mask to cpufreq_policy would make the users of > it depend on cpufreq sort of artificially, which need not be useful > even. > > IMO, the information needed by all of the subsystems in question > should be obtained and made available at the arch/platform level and > everyone who needs it should be able to access it from there, > including the cpufreq driver for the given platform if that's what it > needs to do. > > BTW, cpuidle may need the information in question too, so why should > it be provided via cpufreq rather than via cpuidle? Right. -- viresh
Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap
On Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote: > On Wed, Nov 18, 2020 at 5:22 PM Hyesoo Yu wrote: > > > > On Tue, Nov 17, 2020 at 07:00:54PM -0800, John Stultz wrote: > > > So I suspect Rob will push back on this as he has for other dt > > > bindings related to ion/dmabuf heaps (I tried to push a similar > > > solution to exporting multiple CMA areas via dmabuf heaps). > > > > > > The proposal he seemed to like best was having an in-kernel function > > > that a driver would call to initialize the heap (associated with the > > > CMA region the driver is interested in). Similar to Kunihiko Hayashi's > > > patch here: > > > - > > > https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/ > > > > > > The one sticking point for that patch (which I think is a good one), > > > is that we don't have any in-tree users, so it couldn't be merged yet. > > > > > > A similar approach might be good here, but again we probably need to > > > have at least one in-tree user which could call such a registration > > > function. > > > > Thanks for your review. > > > > The chunk heap is not considered for device-specific reserved memory and > > specific driver. > > It is similar to system heap, but it only collects high-order pages by > > using specific cma-area for performance. > > So, yes I agree, the chunk heap isn't device specific. It's just that > the CMA regions usually are tied to devices. > > The main objection to this style of solution has been due to the fact > that the DTS is supposed to describe the physical hardware (in an OS > agnostic way), rather than define configuration info for Linux > software drivers. > > Obviously this can be quibbled about, as the normal way of tying > devices to CMA has some assumptions of what the driver will use that > region for, rather than somehow representing a physical tie between a > memory reservation and a device. Nonetheless, Rob has been hesitant to > take any sort of ION/DmaBuf Heap DT devices, and has been more > interested in some device having the memory reservation reference and > the driver for that doing the registration. > > > It is strange that there is in-tree user who registers chunk heap. > > (Wouldn't it be strange for some users to register the system heap?) > > Well, as there's no reservation/configuration needed, the system heap > can register itself. > > The CMA heap currently only registers the default CMA heap, as we > didn't want to expose all CMA regions and there's otherwise no way to > pick and choose. > > > Is there a reason to use dma-heap framework to add cma-area for specific > > device ? > > > > Even if some in-tree users register dma-heap with cma-area, the buffers > > could be allocated in user-land and these could be shared among other > > devices. > > For exclusive access, I guess, the device don't need to register dma-heap > > for cma area. > > > > It's not really about exclusive access. More just that if you want to > bind a memory reservation/region (cma or otherwise), at least for DTS, > it needs to bind with some device in DT. > > Then the device driver can register that region with a heap driver. > This avoids adding new Linux-specific software bindings to DT. It > becomes a driver implementation detail instead. The primary user of > the heap type would probably be a practical pick (ie the display or > isp driver). > > The other potential solution Rob has suggested is that we create some > tag for the memory reservation (ie: like we do with cma: "reusable"), > which can be used to register the region to a heap. But this has the > problem that each tag has to be well defined and map to a known heap. > > thanks > -john > Thanks for the detailed reply. I understood what you mean exactly. I agree with your opinion that avoids software bindings to DT. The way to register the heap by specific device driver, makes dependency between heap and some device drivers that we pick practically. If that device driver changed or removed whenever H/W changed, the chunk heap is affected regardless of our intentions. As you said, the other solution that add tags need to be well defined. I guess, that will be a long-term solution. First of all, we just want to register chunk heap to allocate high-order pages. I'm going to change to a simple solution that uses default cma like cma heap, not using DT. Thanks. Regards.
Re: [PATCH] tpm_tis: Disable interrupts on ThinkPad T490s
Matthew Garrett @ 2020-10-15 15:39 MST:
> On Thu, Oct 15, 2020 at 2:44 PM Jerry Snitselaar wrote:
>>
>> There is a misconfiguration in the bios of the gpio pin used for the
>> interrupt in the T490s. When interrupts are enabled in the tpm_tis
>> driver code this results in an interrupt storm. This was initially
>> reported when we attempted to enable the interrupt code in the tpm_tis
>> driver, which previously wasn't setting a flag to enable it. Due to
>> the reports of the interrupt storm that code was reverted and we went back
>> to polling instead of using interrupts. Now that we know the T490s problem
>> is a firmware issue, add code to check if the system is a T490s and
>> disable interrupts if that is the case. This will allow us to enable
>> interrupts for everyone else. If the user has a fixed bios they can
>> force the enabling of interrupts with tpm_tis.interrupts=1 on the
>> kernel command line.
>
> I think an implication of this is that systems haven't been
> well-tested with interrupts enabled. In general when we've found a
> firmware issue in one place it ends up happening elsewhere as well, so
> it wouldn't surprise me if there are other machines that will also be
> unhappy with interrupts enabled. Would it be possible to automatically
> detect this case (eg, if we get more than a certain number of
> interrupts in a certain timeframe immediately after enabling the
> interrupt) and automatically fall back to polling in that case? It
> would also mean that users with fixed firmware wouldn't need to pass a
> parameter.
I believe Matthew is correct here. I found another system today
with completely different vendor for both the system and the tpm chip.
In addition another Lenovo model, the L490, has the issue.
This initial attempt at a solution like Matthew suggested works on
the system I found today, but I imagine it is all sorts of wrong.
In the 2 systems where I've seen it, there are about 10 interrupts
in around 1.5 seconds, and then the irq code shuts down the interrupt
because they aren't being handled.
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 49ae09ac604f..478e9d02a3fa 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -27,6 +27,11 @@
#include "tpm.h"
#include "tpm_tis_core.h"
+static unsigned int time_start = 0;
+static bool storm_check = true;
+static bool storm_killed = false;
+static u32 irqs_fired = 0;
+
static void tpm_tis_clkrun_enable(struct tpm_chip *chip, bool value);
static void tpm_tis_enable_interrupt(struct tpm_chip *chip, u8 mask)
@@ -464,25 +469,31 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const
u8 *buf, size_t len)
return rc;
}
-static void disable_interrupts(struct tpm_chip *chip)
+static void __disable_interrupts(struct tpm_chip *chip)
{
struct tpm_tis_data *priv = dev_get_drvdata(>dev);
u32 intmask;
int rc;
- if (priv->irq == 0)
- return;
-
rc = tpm_tis_read32(priv, TPM_INT_ENABLE(priv->locality), );
if (rc < 0)
intmask = 0;
intmask &= ~TPM_GLOBAL_INT_ENABLE;
rc = tpm_tis_write32(priv, TPM_INT_ENABLE(priv->locality), intmask);
+ chip->flags &= ~TPM_CHIP_FLAG_IRQ;
+}
+
+static void disable_interrupts(struct tpm_chip *chip)
+{
+ struct tpm_tis_data *priv = dev_get_drvdata(>dev);
+ if (priv->irq == 0)
+ return;
+
+ __disable_interrupts(chip);
devm_free_irq(chip->dev.parent, priv->irq, chip);
priv->irq = 0;
- chip->flags &= ~TPM_CHIP_FLAG_IRQ;
}
/*
@@ -528,6 +539,12 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf,
size_t len)
int rc, irq;
struct tpm_tis_data *priv = dev_get_drvdata(>dev);
+ if (unlikely(storm_killed)) {
+ devm_free_irq(chip->dev.parent, priv->irq, chip);
+ priv->irq = 0;
+ storm_killed = false;
+ }
+
if (!(chip->flags & TPM_CHIP_FLAG_IRQ) || priv->irq_tested)
return tpm_tis_send_main(chip, buf, len);
@@ -748,6 +765,21 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id)
u32 interrupt;
int i, rc;
+ if (storm_check) {
+ irqs_fired++;
+
+ if (!time_start) {
+ time_start = jiffies_to_msecs(jiffies);
+ } else if ((irqs_fired > 1000) && (jiffies_to_msecs(jiffies) -
jiffies < 500)) {
+ __disable_interrupts(chip);
+ storm_check = false;
+ storm_killed = true;
+ return IRQ_HANDLED;
+ } else if ((jiffies_to_msecs(jiffies) - time_start > 500) &&
(irqs_fired < 1000)) {
+ storm_check = false;
+ }
+ }
+
rc = tpm_tis_read32(priv, TPM_INT_STATUS(priv->locality), );
if (rc < 0)
return IRQ_NONE;
[PATCH v3 1/4] usb: typec: Use Thunderbolt 3 cable discover mode VDO in Enter_USB message
When Thunderbolt 3 cable is being used to create USB4 connection, use
Thunderbolt 3 discover mode VDO to fill details such as active cable plug
link training and cable rounded support.
With USB4 cables, these VDO members need not be filled.
Suggested-by: Heikki Krogerus
Signed-off-by: Utkarsh Patel
--
Changes in v3:
- Changed the commit mesage to reflect why TBT3 VDO is being used.
- Added more details in the header file about the usage of TBT3 VDO.
Changes in v2:
- No change.
--
---
include/linux/usb/typec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 6be558045942..25731ed863fa 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -75,6 +75,10 @@ enum typec_orientation {
/*
* struct enter_usb_data - Enter_USB Message details
* @eudo: Enter_USB Data Object
+ * @tbt_cable_vdo: TBT3 Cable Discover Mode Response
+ * @tbt_cable_vdo needs to be filled with details of active cable plug link
+ * training and cable rounded support when thunderbolt 3 cable is being used to
+ * create USB4 connection. Do not fill this in case of USB4 cable.
* @active_link_training: Active Cable Plug Link Training
*
* @active_link_training is a flag that should be set with uni-directional SBRX
@@ -83,6 +87,7 @@ enum typec_orientation {
*/
struct enter_usb_data {
u32 eudo;
+ u32 tbt_cable_vdo;
unsigned char active_link_training:1;
};
--
2.17.1
[PATCH v3 3/4] usb: typec: intel_pmc_mux: Configure active cable properties for USB4
Value received as a part of Thunderbolt 3 cable discover mode VDO needs
to be configured in the USB4 mode for the cable rounded support and
active cable plug link training.
Suggested-by: Heikki Krogerus
Signed-off-by: Utkarsh Patel
--
Changes in v3:
- Moved TBT_CABLE_ROUNDED_SUPPORT assignment to the same line.
Changes in v2:
- No change.
--
---
drivers/usb/typec/mux/intel_pmc_mux.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c
b/drivers/usb/typec/mux/intel_pmc_mux.c
index aa3211f1c4c3..baf343b14682 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -295,6 +295,7 @@ pmc_usb_mux_usb4(struct pmc_usb_port *port, struct
typec_mux_state *state)
{
struct enter_usb_data *data = state->data;
struct altmode_req req = { };
+ u8 cable_rounded;
u8 cable_speed;
if (IOM_PORT_ACTIVITY_IS(port->iom_status, TBT) ||
@@ -308,9 +309,6 @@ pmc_usb_mux_usb4(struct pmc_usb_port *port, struct
typec_mux_state *state)
/* USB4 Mode */
req.mode_data = PMC_USB_ALTMODE_FORCE_LSR;
- if (data->active_link_training)
- req.mode_data |= PMC_USB_ALTMODE_ACTIVE_LINK;
-
req.mode_data |= (port->orientation - 1) << PMC_USB_ALTMODE_ORI_SHIFT;
req.mode_data |= (port->role - 1) << PMC_USB_ALTMODE_UFP_SHIFT;
@@ -322,6 +320,19 @@ pmc_usb_mux_usb4(struct pmc_usb_port *port, struct
typec_mux_state *state)
fallthrough;
default:
req.mode_data |= PMC_USB_ALTMODE_ACTIVE_CABLE;
+
+ if (data->tbt_cable_vdo) {
+ /* Active Thunderbolt 3 cable */
+ if (data->tbt_cable_vdo & TBT_CABLE_LINK_TRAINING)
+ req.mode_data |= PMC_USB_ALTMODE_ACTIVE_LINK;
+
+ cable_rounded =
TBT_CABLE_ROUNDED_SUPPORT(data->tbt_cable_vdo);
+ req.mode_data |= PMC_USB_ALTMODE_TBT_GEN(cable_rounded);
+ } else {
+ /* Active USB4 cable */
+ req.mode_data |= PMC_USB_ALTMODE_ACTIVE_LINK |
+ PMC_USB_ALTMODE_TBT_GEN(1);
+ }
break;
}
--
2.17.1
[PATCH v3 4/4] usb: typec: Remove active_link_training variable from Enter_USB message
Thunderbolt 3 cable discover mode VDO support has been added as part of
Enter_USB message to fill details of active cable plug link training.
Hence, removing unused variable active_link_training from Enter_USB
message data structure.
Signed-off-by: Utkarsh Patel
Reviewed-by: Heikki Krogerus
--
Changes in v3:
- Rebased and Added Reviewed-by tag.
Changes in v2:
- No change.
--
---
include/linux/usb/typec.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 25731ed863fa..d26824a30ff9 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -79,16 +79,10 @@ enum typec_orientation {
* @tbt_cable_vdo needs to be filled with details of active cable plug link
* training and cable rounded support when thunderbolt 3 cable is being used to
* create USB4 connection. Do not fill this in case of USB4 cable.
- * @active_link_training: Active Cable Plug Link Training
- *
- * @active_link_training is a flag that should be set with uni-directional SBRX
- * communication, and left 0 with passive cables and with bi-directional SBRX
- * communication.
*/
struct enter_usb_data {
u32 eudo;
u32 tbt_cable_vdo;
- unsigned char active_link_training:1;
};
/*
--
2.17.1
[PATCH v3 2/4] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode
Configure Thunderbolt 3 cable generation value by filling Thunderbolt 3
cable discover mode VDO to support rounded Thunderbolt 3 cables.
While we are here use Thunderbolt 3 cable discover mode VDO to fill active
cable plug link training value.
Suggested-by: Heikki Krogerus
Signed-off-by: Utkarsh Patel
--
Changes in v3:
- Added a check for cable's TBT support before filling TBT3 discover mode
VDO.
Changes in v2:
- No change.
--
---
drivers/platform/chrome/cros_ec_typec.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 8111ed1fc574..68b17ee1d1ae 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -514,8 +514,18 @@ static int cros_typec_enable_usb4(struct cros_typec_data
*typec,
else if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_CABLE)
data.eudo |= EUDO_CABLE_TYPE_RE_TIMER << EUDO_CABLE_TYPE_SHIFT;
- data.active_link_training = !!(pd_ctrl->control_flags &
- USB_PD_CTRL_ACTIVE_LINK_UNIDIR);
+ /*
+* Filling TBT3 Cable VDO when TBT3 cable is being used to establish
+* USB4 connection.
+*/
+ if (pd_ctrl->cable_gen) {
+ data.tbt_cable_vdo = TBT_MODE;
+
+ if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_LINK_UNIDIR)
+ data.tbt_cable_vdo |= TBT_CABLE_LINK_TRAINING;
+
+ data.tbt_cable_vdo |= TBT_SET_CABLE_ROUNDED(pd_ctrl->cable_gen);
+ }
port->state.alt = NULL;
port->state.data =
--
2.17.1
[PATCH v3 0/4] Thunderbolt3/USB4 cable rounded and active cable plug link training support
This patch series adds the support for Thunderbolt3/USB4 rounded and non-rounded frequencies cables and fixes the active cable plug link training support. Changes in v3: - First four patches of this series have been queued by Greg to usb-testing branch. https://www.spinics.net/lists/linux-usb/msg204880.html - Changed commit message and description in header file in patch 1/4. - Added a check for Cable's TBT support in patch 2/4 - Moved TBT_CABLE_ROUNDED_SUPPORT assignment to same line in patch 3/4. - Rebased and added Reviewed-by tag in patch 4/4. Changes in v2: - Removed the fixes tag as there is no functional implication from patches 1/8, 2/8 and 4/8. Utkarsh Patel (4): usb: typec: Use Thunderbolt 3 cable discover mode VDO in Enter_USB message platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode usb: typec: intel_pmc_mux: Configure active cable properties for USB4 usb: typec: Remove active_link_training variable from Enter_USB message drivers/platform/chrome/cros_ec_typec.c | 14 -- drivers/usb/typec/mux/intel_pmc_mux.c | 17 ++--- include/linux/usb/typec.h | 11 +-- 3 files changed, 31 insertions(+), 11 deletions(-) -- 2.17.1
Re: [PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml
On 16-11-20, 08:46, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> 1. Change syntax from txt to yaml
> 2. Drop "Driver for" from the title
> 3. Drop "reg = <0x0>;" from example (noticed by dt_binding_check)
> 4. Specify license
You missed Ccing Rob
>
> Signed-off-by: Rafał Miłecki
> ---
> I think this should go through linux-phy tree. Kishon, Vinod, can you
> take this patch?
>
> This patch generates a false positive checkpatch.pl warning [0].
> Please ignore:
> WARNING: DT binding docs and includes should be a separate patch. See:
> Documentation/devicetree/bindings/submitting-patches.rst
That is okay, it is a warning ;-)
>
> [0] https://lkml.org/lkml/2020/2/18/1084
> ---
> .../bindings/phy/bcm-ns-usb3-phy.txt | 34 --
> .../bindings/phy/bcm-ns-usb3-phy.yaml | 62 +++
> 2 files changed, 62 insertions(+), 34 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> deleted file mode 100644
> index 32f057260351..
> --- a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -Driver for Broadcom Northstar USB 3.0 PHY
> -
> -Required properties:
> -
> -- compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
> -- reg: address of MDIO bus device
> -- usb3-dmp-syscon: phandle to syscon with DMP (Device Management Plugin)
> -registers
> -- #phy-cells: must be 0
> -
> -Initialization of USB 3.0 PHY depends on Northstar version. There are
> currently
> -three known series: Ax, Bx and Cx.
> -Known A0: BCM4707 rev 0
> -Known B0: BCM4707 rev 4, BCM53573 rev 2
> -Known B1: BCM4707 rev 6
> -Known C0: BCM47094 rev 0
> -
> -Example:
> - mdio: mdio@0 {
> - reg = <0x0>;
> - #size-cells = <1>;
> - #address-cells = <0>;
> -
> - usb3-phy@10 {
> - compatible = "brcm,ns-ax-usb3-phy";
> - reg = <0x10>;
> - usb3-dmp-syscon = <_dmp>;
> - #phy-cells = <0>;
> - };
> - };
> -
> - usb3_dmp: syscon@18105000 {
> - reg = <0x18105000 0x1000>;
> - };
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
> new file mode 100644
> index ..7fd419db45d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/bcm-ns-usb3-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom Northstar USB 3.0 PHY
> +
> +description: |
> + Initialization of USB 3.0 PHY depends on Northstar version. There are
> currently
> + three known series: Ax, Bx and Cx.
> + Known A0: BCM4707 rev 0
> + Known B0: BCM4707 rev 4, BCM53573 rev 2
> + Known B1: BCM4707 rev 6
> + Known C0: BCM47094 rev 0
> +
> +maintainers:
> + - Rafał Miłecki
> +
> +properties:
> + compatible:
> +enum:
> + - brcm,ns-ax-usb3-phy
> + - brcm,ns-bx-usb3-phy
> +
> + reg:
> +description: address of MDIO bus device
> +maxItems: 1
> +
> + usb3-dmp-syscon:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + Phandle to the DMP (Device Management Plugin) syscon
> +
> + "#phy-cells":
> +const: 0
> +
> +required:
> + - compatible
> + - reg
> + - usb3-dmp-syscon
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +mdio {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +usb3-phy@10 {
> +compatible = "brcm,ns-ax-usb3-phy";
> +reg = <0x10>;
> +usb3-dmp-syscon = <_dmp>;
> +#phy-cells = <0>;
> +};
> +};
> +
> +usb3_dmp: syscon@18105000 {
> +reg = <0x18105000 0x1000>;
> +};
> --
> 2.27.0
--
~Vinod
[PATCH v1] scsi: ufs: Fix race between shutdown and runtime resume flow
If UFS host device is in runtime-suspended state while
UFS shutdown callback is invoked, UFS device shall be
resumed for register accesses. Currently only UFS local
runtime resume function will be invoked to wake up the host.
This is not enough because if someone triggers runtime
resume from block layer, then race may happen between
shutdown and runtime resume flow, and finally lead to
unlocked register access.
To fix this kind of issues, in ufshcd_shutdown(), use
pm_runtime_get_sync() instead of resuming UFS device by
ufshcd_runtime_resume() "internally" to let runtime PM
framework manage the whole resume flow.
Fixes: 57d104c153d3 ("ufs: add UFS power management support")
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 80cbce414678..bb16cc04f106 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8941,11 +8941,7 @@ int ufshcd_shutdown(struct ufs_hba *hba)
if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
goto out;
- if (pm_runtime_suspended(hba->dev)) {
- ret = ufshcd_runtime_resume(hba);
- if (ret)
- goto out;
- }
+ pm_runtime_get_sync(hba->dev);
ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
out:
--
2.18.0
Re: [PATCH] phy: phy-bcm-ns-usb3: drop support for deprecated DT binding
On 13-11-20, 12:34, Rafał Miłecki wrote: > From: Rafał Miłecki > > Initially this PHY driver was implementing MDIO access on its own. It > was caused by lack of proper hardware design understanding. > > It has been changed back in 2017. DT bindings were changed and driver > was updated to use MDIO layer. > > It should be really safe now to drop the old deprecated code. All Linux > stored DT files don't use it for 3,5 year. There is close to 0 chance > there is any bootloader with its own DTB using old the binding. Applied, thanks While applying, it gave me a minor conflict, please do check the resolution -- ~Vinod
Re: [RFC PATCH] perf session: Fixup timestamp for ordered events
Hi Adrian, On Wed, Nov 18, 2020 at 05:57:09PM +0200, Adrian Hunter wrote: [...] > >>> The follow diagram depicts the flow for how the AUX event is arriving > >>> ahead than MMAP2 event: > >>> > >>>T1: T3: T4: > >>> perf process Open PMU devicePerf is scheduled out; > >>> invoke perf_aux_output_end() > >>> and generate AUX event > >>>^^^ > >>>||| > >>> CPU0 ---> (T) > >>>\ > >>> \ Forked process is placed on another CPU > >>> V > >>> CPU1 ---> (T) > >>> || > >>> VV > >>> T2: T5: > >>> Invoke execvp() for profiled Record MMAP2 event > >>> program > >> > >> I don't understand. An MMAP at T5 cannot affect data recorded before T5 > >> (e.g. T4). > >> Are you saying the timestamps from different CPUs are not in time order? > >> Ot > >> are you saying the data is actually recorded after T5? > > > > Here refers to the later one. > > > > I observed the PMU device is opened and closed for multiple times, so > > the AUX events and MMAP2 events are interleave with each other. Below > > is the dumping with debugging option "--debug ordered-events=1" (and I > > added code for printing out event type value). > > > > When perf tool starts to decode the trace data for the first AUX event > > (its timestamp is 160.767623) and try to synthesize samples, it doesn't > > give chance for handling the sequential MMAP2 events (ts: 160.770223, > > 160.770451, 160.773111). > > > > [ 160.765623] queue_event nr_events 1 > > [ 160.765623] new event on queue: type=12 > > [ 160.765714] queue_event nr_events 2 > > [ 160.765714] new event on queue: type=3 > > [ 160.765822] queue_event nr_events 3 > > [ 160.765822] new event on queue: type=10 ==> MMAP2 event > > [ 160.766180] queue_event nr_events 4 > > [ 160.766180] new event on queue: type=14 > > [ 160.767623] queue_event nr_events 5 > > [ 160.767623] new event on queue: type=11 ==> AUX event > > [ 160.769710] queue_event nr_events 6 > > [ 160.769710] new event on queue: type=12 > > [ 160.769762] queue_event nr_events 7 > > [ 160.769762] new event on queue: type=14 > > [ 160.769810] queue_event nr_events 8 > > [ 160.769810] new event on queue: type=14 > > [ 160.769943] queue_event nr_events 9 > > [ 160.769943] new event on queue: type=11 ==> AUX event > > [ 160.770028] queue_event nr_events 10 > > [ 160.770028] new event on queue: type=12 > > [ 160.770073] queue_event nr_events 11 > > [ 160.770073] new event on queue: type=14 > > [ 160.770223] queue_event nr_events 12 > > [ 160.770223] new event on queue: type=10 ==> MMAP2 event > > [ 160.770451] queue_event nr_events 13 > > [ 160.770451] new event on queue: type=10 ==> MMAP2 event > > [ 160.770628] queue_event nr_events 14 > > [ 160.770628] new event on queue: type=14 > > [ 160.771650] queue_event nr_events 15 > > [ 160.771650] new event on queue: type=11 ==> AUX event > > [ 160.771752] queue_event nr_events 16 > > [ 160.771752] new event on queue: type=12 > > [ 160.771798] queue_event nr_events 17 > > [ 160.771798] new event on queue: type=14 > > [ 160.773111] queue_event nr_events 18 > > [ 160.773111] new event on queue: type=10 ==> MMAP2 event > > [ 160.782613] queue_event nr_events 19 > > [ 160.782613] new event on queue: type=14 > > > > Thanks for the reviewing, > > > > Leo > > > > When you say AUX event, do you mean PERF_RECORD_AUX or PERF_RECORD_AUXTRACE? The AUX event is PERF_RECORD_AUX. > The kernel creates PERF_RECORD_AUX and the data range aux_offset/aux_size > should be for things prior to the sample time. > > perf tool creates PERF_RECORD_AUXTRACE when copying data out of the aux > area. PERF_RECORD_AUXTRACE does not have a timestamp and can contain data > corresponding to several PERF_RECORD_AUX. Data is queued based on > PERF_RECORD_AUXTRACE because that is what the data is attached to i.e. one > buffer can contain data from several PERF_RECORD_AUX events. > > If you are processing data based on PERF_RECORD_AUX timestamp then you need > to pay attention to the offset. PERF_RECORD_AUX gives you > aux_offset/aux_size and auxtrace_buffer (which may contain data from several > PERF_RECORD_AUX) gives you offset/size. Yeah, as you suggested, in this case the key point is for the first PERF_RECORD_AUX
[PATCH v2] workqueue: Kick a worker based on the actual activation of delayed works
In realtime scenario, We do not want to have interference on the
isolated cpu cores. but when invoking alloc_workqueue() for percpu wq
on the housekeeping cpu, it kick a kworker on the isolated cpu.
alloc_workqueue
pwq_adjust_max_active
wake_up_worker
The comment in pwq_adjust_max_active() said:
"Need to kick a worker after thawed or an unbound wq's
max_active is bumped"
So it is unnecessary to kick a kworker for percpu's wq when invoking
alloc_workqueue(). this patch only kick a worker based on the actual
activation of delayed works.
Signed-off-by: Yunfeng Ye
---
kernel/workqueue.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c41c3c17b86a..b3c9d6ef7c69 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3725,17 +3725,25 @@ static void pwq_adjust_max_active(struct pool_workqueue
*pwq)
* is updated and visible.
*/
if (!freezable || !workqueue_freezing) {
+ bool kick = false;
+
pwq->max_active = wq->saved_max_active;
while (!list_empty(>delayed_works) &&
- pwq->nr_active < pwq->max_active)
+ pwq->nr_active < pwq->max_active) {
pwq_activate_first_delayed(pwq);
+ kick = true;
+ }
/*
* Need to kick a worker after thawed or an unbound wq's
-* max_active is bumped. It's a slow path. Do it always.
+* max_active is bumped. But in realtime scenario, kick a
+* worker always will have interference on the isolated
+* cpu cores. So do it only based on the actual activation
+* of delayed works.
*/
- wake_up_worker(pwq->pool);
+ if (kick)
+ wake_up_worker(pwq->pool);
} else {
pwq->max_active = 0;
}
--
2.18.4
kernel BUG at mm/filemap.c:LINE! (2)
Hello, syzbot found the following issue on: HEAD commit:e28c0d7c Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=145b685a50 kernel config: https://syzkaller.appspot.com/x/.config?x=86ae89f992df998f dashboard link: https://syzkaller.appspot.com/bug?extid=f0179a8115cb538470a6 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f0179a8115cb53847...@syzkaller.appspotmail.com raw: 0202 88801e33 page dumped because: VM_BUG_ON_PAGE(page_mapped(page)) page->mem_cgroup:88801e33 [ cut here ] kernel BUG at mm/filemap.c:173! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 3 PID: 10789 Comm: syz-executor.1 Not tainted 5.10.0-rc3-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:unaccount_page_cache_page+0xb1a/0x1040 mm/filemap.c:173 Code: e8 eb f3 dd ff 48 c7 c6 00 d6 53 89 48 89 ef e8 cc d6 0d 00 0f 0b e8 d5 f3 dd ff 48 c7 c6 60 da 53 89 48 89 ef e8 b6 d6 0d 00 <0f> 0b e8 bf f3 dd ff 49 8d 9f 58 4d 00 00 e9 7e fb ff ff e8 ae f3 RSP: 0018:c900023bf668 EFLAGS: 00010096 RAX: RBX: 0001 RCX: c9000cb33000 RDX: 0004 RSI: 88ae5577 RDI: f52000477e67 RBP: ea0001c68000 R08: 0021 R09: 88802cd2005b R10: R11: R12: ea0001c68008 R13: 88801e3f85c8 R14: R15: ea0001c50308 FS: 7f5a5d2ba700() GS:88802cd0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f5a5d298db8 CR3: 6f8d8000 CR4: 00350ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __delete_from_page_cache mm/filemap.c:238 [inline] delete_from_page_cache+0x150/0x240 mm/filemap.c:274 truncate_inode_page+0x85/0xd0 mm/truncate.c:228 shmem_undo_range+0x5ef/0x1b00 mm/shmem.c:949 shmem_truncate_range mm/shmem.c:1058 [inline] shmem_setattr+0x67a/0xc70 mm/shmem.c:1117 notify_change+0xb60/0x10a0 fs/attr.c:336 do_truncate+0x134/0x1f0 fs/open.c:64 handle_truncate fs/namei.c:2910 [inline] do_open fs/namei.c:3256 [inline] path_openat+0x2054/0x2730 fs/namei.c:3369 do_filp_open+0x17e/0x3c0 fs/namei.c:3396 do_sys_openat2+0x16d/0x420 fs/open.c:1168 do_sys_open fs/open.c:1184 [inline] __do_sys_creat fs/open.c:1258 [inline] __se_sys_creat fs/open.c:1252 [inline] __x64_sys_creat+0xc9/0x120 fs/open.c:1252 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45da59 Code: bd b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 8b b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f5a5d2b9c88 EFLAGS: 0246 ORIG_RAX: 0055 RAX: ffda RBX: 006f4da0 RCX: 0045da59 RDX: RSI: RDI: 2400 RBP: 004aab8b R08: R09: R10: R11: 0246 R12: 0075c050 R13: 7ffddf47bd7f R14: 7f5a5d29a000 R15: 0003 Modules linked in: ---[ end trace 0b8db26874e8aeaf ]--- RIP: 0010:unaccount_page_cache_page+0xb1a/0x1040 mm/filemap.c:173 Code: e8 eb f3 dd ff 48 c7 c6 00 d6 53 89 48 89 ef e8 cc d6 0d 00 0f 0b e8 d5 f3 dd ff 48 c7 c6 60 da 53 89 48 89 ef e8 b6 d6 0d 00 <0f> 0b e8 bf f3 dd ff 49 8d 9f 58 4d 00 00 e9 7e fb ff ff e8 ae f3 RSP: 0018:c900023bf668 EFLAGS: 00010096 RAX: RBX: 0001 RCX: c9000cb33000 RDX: 0004 RSI: 88ae5577 RDI: f52000477e67 RBP: ea0001c68000 R08: 0021 R09: 88802cd2005b R10: R11: R12: ea0001c68008 R13: 88801e3f85c8 R14: R15: ea0001c50308 FS: 7f5a5d2ba700() GS:88802cd0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f5a5d298db8 CR3: 6f8d8000 CR4: 00350ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH v2 1/6] iommu: Move iotlb_sync_map out from __iommu_map
In the end of __iommu_map, It alway call iotlb_sync_map.
This patch moves iotlb_sync_map out from __iommu_map since it is
unnecessary to call this for each sg segment especially iotlb_sync_map
is flush tlb all currently.
Signed-off-by: Yong Wu
---
drivers/iommu/iommu.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 8c470f451a32..decef851fa3a 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2407,9 +2407,6 @@ static int __iommu_map(struct iommu_domain *domain,
unsigned long iova,
size -= pgsize;
}
- if (ops->iotlb_sync_map)
- ops->iotlb_sync_map(domain);
-
/* unroll mapping in case something went wrong */
if (ret)
iommu_unmap(domain, orig_iova, orig_size - size);
@@ -2422,15 +2419,29 @@ static int __iommu_map(struct iommu_domain *domain,
unsigned long iova,
int iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot)
{
+ const struct iommu_ops *ops = domain->ops;
+ int ret;
+
might_sleep();
- return __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+ ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+ if (ret == 0 && ops->iotlb_sync_map)
+ ops->iotlb_sync_map(domain);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_map);
int iommu_map_atomic(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot)
{
- return __iommu_map(domain, iova, paddr, size, prot, GFP_ATOMIC);
+ const struct iommu_ops *ops = domain->ops;
+ int ret;
+
+ ret = __iommu_map(domain, iova, paddr, size, prot, GFP_ATOMIC);
+ if (ret == 0 && ops->iotlb_sync_map)
+ ops->iotlb_sync_map(domain);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_map_atomic);
@@ -2514,6 +2525,7 @@ static size_t __iommu_map_sg(struct iommu_domain *domain,
unsigned long iova,
struct scatterlist *sg, unsigned int nents, int
prot,
gfp_t gfp)
{
+ const struct iommu_ops *ops = domain->ops;
size_t len = 0, mapped = 0;
phys_addr_t start;
unsigned int i = 0;
@@ -2544,6 +2556,8 @@ static size_t __iommu_map_sg(struct iommu_domain *domain,
unsigned long iova,
sg = sg_next(sg);
}
+ if (ops->iotlb_sync_map)
+ ops->iotlb_sync_map(domain);
return mapped;
out_err:
--
2.18.0
Re: [RESEND PATCH 09/19] phy: allwinner: Convert to devm_platform_ioremap_* API
On 10-11-20, 14:35, Frank Lee wrote: > From: Yangtao Li > > Use the devm_platform_ioremap_resource_byname() and > devm_platform_ioremap_resource helper to simplify the code. This fails to apply for me, pls rebase -- ~Vinod
Re: [RESEND PATCH 08/19] phy: sun4i-usb: remove enable_pmu_unk1 from sun50i_h6_cfg
On 10-11-20, 14:32, Frank Lee wrote: > From: Yangtao Li > > For the current code, enable_pmu_unk1 only works in non-a83t and non-h6 > types. So let's delete it from the sun50i_h6_cfg. Applied, thanks -- ~Vinod
[PATCH v2 6/6] iommu/mediatek: Convert tlb_flush_walk to gather_add_page
MediaTek TLB flush don't care about granule. when unmap, it could gather
whole the iova range then do tlb flush once.
In current v7s, If unmap the lvl2 pagetable, the steps are:
step1: set this current pdg to 0.
step2: tlb flush for this lvl2 block iova(1M).
step3: free the lvl2 pagetable.
This patch means we delay the step2 after unmap whole the iova.
the iommu consumer HW should have stopped before it call dma_free_xx,
thus, this delay looks ok.
Since tlb_flush_walk doesn't have the "gather" parameter, so we have to
add this "gather" in ourself private data.
Meanswhile, After this patch, the gather_add_pages will always be called,
then "gather->start == ULONG_MAX" is impossible. remove this checking.
Signed-off-by: Yong Wu
---
tlb_flush_walk is designed for tlb flush range, I'm not sure whether it's ok
if adding "gather" as a parameter in tlb_flush_walk. in this version, I put
it into our private data.
---
drivers/iommu/mtk_iommu.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 94786860bd84..4c8200f4403a 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -128,6 +128,8 @@ struct mtk_iommu_domain {
struct io_pgtable_ops *iop;
struct iommu_domain domain;
+
+ struct iommu_iotlb_gather *gather;
};
static const struct iommu_ops mtk_iommu_ops;
@@ -227,6 +229,17 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long
iova, size_t size,
}
}
+static void mtk_iommu_tlb_flush_walk(unsigned long iova, size_t size,
+size_t granule, void *cookie)
+{
+ struct mtk_iommu_data *data = cookie;
+ struct mtk_iommu_domain *m4u_dom = data->m4u_dom;
+ struct iommu_domain *domain = _dom->domain;
+
+ /* Gather all the iova and tlb flush once after unmap. */
+ iommu_iotlb_gather_add_page(domain, m4u_dom->gather, iova, size);
+}
+
static void mtk_iommu_tlb_flush_page_nosync(struct iommu_iotlb_gather *gather,
unsigned long iova, size_t granule,
void *cookie)
@@ -239,8 +252,8 @@ static void mtk_iommu_tlb_flush_page_nosync(struct
iommu_iotlb_gather *gather,
static const struct iommu_flush_ops mtk_iommu_flush_ops = {
.tlb_flush_all = mtk_iommu_tlb_flush_all,
- .tlb_flush_walk = mtk_iommu_tlb_flush_range_sync,
- .tlb_flush_leaf = mtk_iommu_tlb_flush_range_sync,
+ .tlb_flush_walk = mtk_iommu_tlb_flush_walk,
+ .tlb_flush_leaf = mtk_iommu_tlb_flush_walk,
.tlb_add_page = mtk_iommu_tlb_flush_page_nosync,
};
@@ -432,6 +445,7 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ dom->gather = gather;
gather->granule_ignore = true;
return dom->iop->unmap(dom->iop, iova, size, gather);
}
@@ -447,9 +461,6 @@ static void mtk_iommu_iotlb_sync(struct iommu_domain
*domain,
struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
size_t length = gather->end - gather->start;
- if (gather->start == ULONG_MAX)
- return;
-
mtk_iommu_tlb_flush_range_sync(gather->start, length, gather->pgsize,
data);
}
--
2.18.0
[PATCH v2 5/6] iommu/mediatek: Enable granule_ignore for unmap
MediaTek IOMMU HW don't care about granule when it flush tlb.
In order to flush tlb once when unmap, Enable this flag to gather all
the iova chunk of unmap.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8c2d4a225666..94786860bd84 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -432,6 +432,7 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ gather->granule_ignore = true;
return dom->iop->unmap(dom->iop, iova, size, gather);
}
--
2.18.0
[PATCH v2 2/6] iommu: Add iova and size as parameters in iommu_iotlb_map
iotlb_sync_map allow IOMMU drivers tlb sync after completing the whole
mapping. This patch adds iova and size as the parameters in it. then the
IOMMU driver could flush tlb with the whole range once after iova mapping
to improve performance.
Signed-off-by: Yong Wu
---
drivers/iommu/iommu.c | 6 +++---
drivers/iommu/tegra-gart.c | 3 ++-
include/linux/iommu.h | 3 ++-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index decef851fa3a..df87c8e825f7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2425,7 +2425,7 @@ int iommu_map(struct iommu_domain *domain, unsigned long
iova,
might_sleep();
ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
if (ret == 0 && ops->iotlb_sync_map)
- ops->iotlb_sync_map(domain);
+ ops->iotlb_sync_map(domain, iova, size);
return ret;
}
@@ -2439,7 +2439,7 @@ int iommu_map_atomic(struct iommu_domain *domain,
unsigned long iova,
ret = __iommu_map(domain, iova, paddr, size, prot, GFP_ATOMIC);
if (ret == 0 && ops->iotlb_sync_map)
- ops->iotlb_sync_map(domain);
+ ops->iotlb_sync_map(domain, iova, size);
return ret;
}
@@ -2557,7 +2557,7 @@ static size_t __iommu_map_sg(struct iommu_domain *domain,
unsigned long iova,
}
if (ops->iotlb_sync_map)
- ops->iotlb_sync_map(domain);
+ ops->iotlb_sync_map(domain, iova, mapped);
return mapped;
out_err:
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index fac720273889..d15d13a98ed1 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -261,7 +261,8 @@ static int gart_iommu_of_xlate(struct device *dev,
return 0;
}
-static void gart_iommu_sync_map(struct iommu_domain *domain)
+static void gart_iommu_sync_map(struct iommu_domain *domain, unsigned long
iova,
+ size_t size)
{
FLUSH_GART_REGS(gart_handle);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..794d4085edd3 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -244,7 +244,8 @@ struct iommu_ops {
size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
size_t size, struct iommu_iotlb_gather *iotlb_gather);
void (*flush_iotlb_all)(struct iommu_domain *domain);
- void (*iotlb_sync_map)(struct iommu_domain *domain);
+ void (*iotlb_sync_map)(struct iommu_domain *domain, unsigned long iova,
+ size_t size);
void (*iotlb_sync)(struct iommu_domain *domain,
struct iommu_iotlb_gather *iotlb_gather);
phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t
iova);
--
2.18.0
[PATCH v2 4/6] iommu: Add granule_ignore when tlb gather
Add a granule_ignore option when tlb gather for some HW which don't care
about granule when it flush tlb.
Signed-off-by: Yong Wu
---
include/linux/iommu.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 794d4085edd3..1aad32238510 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -171,6 +171,7 @@ enum iommu_dev_features {
* @start: IOVA representing the start of the range to be flushed
* @end: IOVA representing the end of the range to be flushed (exclusive)
* @pgsize: The interval at which to perform the flush
+ * @granule_ignore: For tlb flushing that could be regardless of granule.
*
* This structure is intended to be updated by multiple calls to the
* ->unmap() function in struct iommu_ops before eventually being passed
@@ -180,6 +181,7 @@ struct iommu_iotlb_gather {
unsigned long start;
unsigned long end;
size_t pgsize;
+ boolgranule_ignore;
};
/**
@@ -544,7 +546,7 @@ static inline void iommu_iotlb_gather_add_page(struct
iommu_domain *domain,
* a different granularity, then sync the TLB so that the gather
* structure can be rewritten.
*/
- if (gather->pgsize != size ||
+ if ((!gather->granule_ignore && gather->pgsize != size) ||
end < gather->start || start > gather->end) {
if (gather->pgsize)
iommu_iotlb_sync(domain, gather);
--
2.18.0
[PATCH v2 3/6] iommu/mediatek: Add iotlb_sync_map to sync whole the iova range
Remove IO_PGTABLE_QUIRK_TLBI_ON_MAP to avoid tlb sync for each a small
chunk memory, Use the new iotlb_sync_map to tlb_sync once for whole the
iova range of iommu_map.
Signed-off-by: Yong Wu
---
After reading msm_iommu.c, It looks IO_PGTABLE_QUIRK_TLBI_ON_MAP can be
removed.
---
drivers/iommu/mtk_iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c072cee532c2..8c2d4a225666 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -323,7 +323,6 @@ static int mtk_iommu_domain_finalise(struct
mtk_iommu_domain *dom)
dom->cfg = (struct io_pgtable_cfg) {
.quirks = IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NO_PERMS |
- IO_PGTABLE_QUIRK_TLBI_ON_MAP |
IO_PGTABLE_QUIRK_ARM_MTK_EXT,
.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
.ias = 32,
@@ -454,6 +453,14 @@ static void mtk_iommu_iotlb_sync(struct iommu_domain
*domain,
data);
}
+static void mtk_iommu_sync_map(struct iommu_domain *domain, unsigned long iova,
+ size_t size)
+{
+ struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+
+ mtk_iommu_tlb_flush_range_sync(iova, size, size, dom->data);
+}
+
static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova)
{
@@ -540,6 +547,7 @@ static const struct iommu_ops mtk_iommu_ops = {
.unmap = mtk_iommu_unmap,
.flush_iotlb_all = mtk_iommu_flush_iotlb_all,
.iotlb_sync = mtk_iommu_iotlb_sync,
+ .iotlb_sync_map = mtk_iommu_sync_map,
.iova_to_phys = mtk_iommu_iova_to_phys,
.probe_device = mtk_iommu_probe_device,
.release_device = mtk_iommu_release_device,
--
2.18.0
[PATCH v2 0/6] MediaTek IOMMU improve tlb flush performance in map/unmap
This patchset is to improve tlb flushing performance in iommu_map/unmap for MediaTek IOMMU. For iommu_map, currently MediaTek IOMMU use IO_PGTABLE_QUIRK_TLBI_ON_MAP to do tlb_flush for each a memory chunk. this is so unnecessary. we could improve it by tlb flushing one time at the end of iommu_map. For iommu_unmap, currently we have already improve this performance by gather. But the current gather should take care its granule size. if the granule size is different, it will do tlb flush and gather again. Our HW don't care about granule size. thus I add a flag(granule_ignore) for this case. After this patchset, we could achieve only tlb flushing once in iommu_map and iommu_unmap. Regardless of sg, for each a segment, I did a simple test: size = 20 * SZ_1M; /* the worst case, all are 4k mapping. */ ret = iommu_map(domain, 0x5bb02000, 0x123f1000, size, IOMMU_READ); iommu_unmap(domain, 0x5bb02000, size); This is the comparing time(unit is us): original-time after-improve map-20M59943 2347 unmap-20M 264 36 This patchset also flush tlb once in the iommu_map_sg case. patch [1/6][2/6][3/6] are for map while the others are for unmap. change note: v2: Refactor all the code. base on v5.10-rc1. v1: https://lore.kernel.org/linux-iommu/20201019113100.23661-1-chao@mediatek.com/ Yong Wu (6): iommu: Move iotlb_sync_map out from __iommu_map iommu: Add iova and size as parameters in iommu_iotlb_map iommu/mediatek: Add iotlb_sync_map to sync whole the iova range iommu: Add granule_ignore when tlb gather iommu/mediatek: Enable granule_ignore for unmap iommu/mediatek: Convert tlb_flush_walk to gather_add_page drivers/iommu/iommu.c | 24 +++- drivers/iommu/mtk_iommu.c | 32 ++-- drivers/iommu/tegra-gart.c | 3 ++- include/linux/iommu.h | 7 +-- 4 files changed, 52 insertions(+), 14 deletions(-) -- 2.18.0
Re: [RFC -V5] autonuma: Migrate on fault among multiple bound nodes
Mel Gorman writes:
> On Wed, Nov 18, 2020 at 01:19:52PM +0800, Huang Ying wrote:
>> Now, AutoNUMA can only optimize the page placement among the NUMA
>
> Note that the feature is referred to as NUMA_BALANCING in the kernel
> configs as AUTONUMA as it was first presented was not merged. The sysctl
> for it is kernel.numa_balancing as you already note. So use NUMAB or
> NUMA_BALANCING but not AUTONUMA because at least a new person grepping
> for NUMA_BALANCING or variants will find it where as autonuma only creeped
> into the powerpc arch code.
Sure. Will change this.
>
> If exposing to userspace, the naming should definitely be consistent.
>
>> - sysctl knob numa_balancing can enable/disable the NUMA balancing
>> globally.
>>
>> - even if sysctl numa_balancing is enabled, the NUMA balancing will be
>> disabled for the memory areas or applications with the explicit memory
>> policy by default.
>>
>> - MPOL_F_AUTONUMA can be used to enable the NUMA balancing for the
>> applications when specifying the explicit memory policy.
>>
>
> MPOL_F_NUMAB
Sure, will change it to MPOL_F_NUMA_BALANCING.
>> Various page placement optimization based on the NUMA balancing can be
>> done with these flags. As the first step, in this patch, if the
>> memory of the application is bound to multiple nodes (MPOL_BIND), and
>> in the hint page fault handler the accessing node are in the policy
>> nodemask, the page will be tried to be migrated to the accessing node
>> to reduce the cross-node accessing.
>>
>
> The patch still lacks supporting data. It really should have a basic
> benchmark of some sort serving as an example of how the policies should
> be set and a before/after comparison showing the throughput of MPOL_BIND
> accesses spanning 2 or more nodes is faster when numa balancing is enabled.
Sure. Will add some basic benchmark data and usage example.
> A man page update should also be added clearly outlining when an
> application should consider using it with the linux-api people cc'd
> for review.
Yes. Will Cc linux-api for review and will submit patches to
manpages.git after the API is finalized.
> The main limitation is that if this requires application modification,
> it may never be used. For example, if an application uses openmp places
> that translates into bind then openmp needs knowledge of the flag.
> Similar limitations apply to MPI. This feature has a risk that no one
> uses it.
My plan is to add a new option to `numactl`
(https://github.com/numactl/numactl/), so users who want to enable NUMA
balancing within the constrains of NUMA binding can use that. I can
reach some Openstack and Kubernate developers to check whether it's
possible to add the support to these software. For other applications,
Yes, it may take long time for the new flag to be used.
>> Huang Ying (2):
>> mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON
>> autonuma: Migrate on fault among multiple bound nodes
>> ---
>> include/uapi/linux/mempolicy.h | 4 +++-
>> mm/mempolicy.c | 9 +
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/mempolicy.h b/include/uapi/linux/mempolicy.h
>> index 3354774af61e..adb49f13840e 100644
>> --- a/include/uapi/linux/mempolicy.h
>> +++ b/include/uapi/linux/mempolicy.h
>> @@ -28,12 +28,14 @@ enum {
>> /* Flags for set_mempolicy */
>> #define MPOL_F_STATIC_NODES (1 << 15)
>> #define MPOL_F_RELATIVE_NODES (1 << 14)
>> +#define MPOL_F_AUTONUMA (1 << 13) /* Optimize with AutoNUMA if
>> possible */
>>
>
> Order by flag usage, correct the naming.
I will correct the naming. Sorry, what does "order" refer to?
>> /*
>> * MPOL_MODE_FLAGS is the union of all possible optional mode flags passed
>> to
>> * either set_mempolicy() or mbind().
>> */
>> -#define MPOL_MODE_FLAGS (MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES)
>> +#define MPOL_MODE_FLAGS
>> \
>> +(MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES | MPOL_F_AUTONUMA)
>>
>> /* Flags for get_mempolicy */
>> #define MPOL_F_NODE (1<<0) /* return next IL mode instead of node mask */
>
> How does an application discover if MPOL_F_NUMAB is supported by the
> current running kernel? It looks like they might receive -EINVAL (didn't
> check for sure).
Yes.
> In that case, a manual page is defintely needed to
> explain that an error can be returned if the flag is used and the kernel
> does not support it so the application can cover by falling back to a
> strict binding. If it fails silently, then that also needs to be documented
> because it'll lead to different behaviour depending on the running
> kernel.
Sure. Will describe this in the manual page.
Best Regards,
Huang, Ying
Re: [External] Re: [PATCH v4 05/21] mm/hugetlb: Introduce pgtable allocation/freeing helpers
On Tue, Nov 17, 2020 at 11:06 PM Oscar Salvador wrote:
>
> On Fri, Nov 13, 2020 at 06:59:36PM +0800, Muchun Song wrote:
> > +#define page_huge_pte(page) ((page)->pmd_huge_pte)
>
> Seems you do not need this one anymore.
>
> > +void vmemmap_pgtable_free(struct page *page)
> > +{
> > + struct page *pte_page, *t_page;
> > +
> > + list_for_each_entry_safe(pte_page, t_page, >lru, lru) {
> > + list_del(_page->lru);
> > + pte_free_kernel(_mm, page_to_virt(pte_page));
> > + }
> > +}
> > +
> > +int vmemmap_pgtable_prealloc(struct hstate *h, struct page *page)
> > +{
> > + unsigned int nr = pgtable_pages_to_prealloc_per_hpage(h);
> > +
> > + /* Store preallocated pages on huge page lru list */
> > + INIT_LIST_HEAD(>lru);
> > +
> > + while (nr--) {
> > + pte_t *pte_p;
> > +
> > + pte_p = pte_alloc_one_kernel(_mm);
> > + if (!pte_p)
> > + goto out;
> > + list_add(_to_page(pte_p)->lru, >lru);
> > + }
>
> Definetely this looks better and easier to handle.
> Btw, did you explore Matthew's hint about instead of allocating a new page,
> using one of the ones you are going to free to store the ptes?
> I am not sure whether it is feasible at all though.
Hi Oscar and Matthew,
I have started an investigation about this. Finally, I think that it
may not be feasible. If we use a vmemmap page frame as a
page table when we split the PMD table firstly, in this stage,
we need to set 512 pte entry to the vmemmap page frame. If
someone reads the tail struct page struct of the HugeTLB,
it can get the arbitrary value (I am not sure it actually exists,
maybe the memory compaction module can do this). So on
the safe side, I think that allocating a new page is a good
choice.
Thanks.
>
>
> > --- a/mm/hugetlb_vmemmap.h
> > +++ b/mm/hugetlb_vmemmap.h
> > @@ -9,12 +9,24 @@
> > #ifndef _LINUX_HUGETLB_VMEMMAP_H
> > #define _LINUX_HUGETLB_VMEMMAP_H
> > #include
> > +#include
>
> why do we need this here?
>
> --
> Oscar Salvador
> SUSE L3
--
Yours,
Muchun
Re: [PATCH RFC 02/12] vdpa: split vdpasim to core and net modules
On 2020/11/18 下午9:14, Stefano Garzarella wrote:
Hi Jason,
I just discovered that I missed the other questions in this email,
sorry for that!
No problem :)
On Mon, Nov 16, 2020 at 12:00:11PM +0800, Jason Wang wrote:
On 2020/11/13 下午9:47, Stefano Garzarella wrote:
From: Max Gurtovoy
Introduce new vdpa_sim_net and vdpa_sim (core) drivers. This is a
preparation for adding a vdpa simulator module for block devices.
Signed-off-by: Max Gurtovoy
[sgarzare: various cleanups/fixes]
Signed-off-by: Stefano Garzarella
---
v1:
- Removed unused headers
- Removed empty module_init() module_exit()
- Moved vdpasim_is_little_endian() in vdpa_sim.h
- Moved vdpasim16_to_cpu/cpu_to_vdpasim16() in vdpa_sim.h
- Added vdpasim*_to_cpu/cpu_to_vdpasim*() also for 32 and 64
- Replaced 'select VDPA_SIM' with 'depends on VDPA_SIM' since selected
option can not depend on other [Jason]
If possible, I would suggest to split this patch further:
1) convert to use void *config, and an attribute for setting config
size during allocation
2) introduce supported_features
3) other attributes (#vqs)
4) rename config ops (more generic one)
5) introduce ops for set|get_config, set_get_features
6) real split
[...]
-static const struct vdpa_config_ops vdpasim_net_config_ops;
-static const struct vdpa_config_ops vdpasim_net_batch_config_ops;
+static const struct vdpa_config_ops vdpasim_config_ops;
+static const struct vdpa_config_ops vdpasim_batch_config_ops;
-static struct vdpasim *vdpasim_create(void)
+struct vdpasim *vdpasim_create(struct vdpasim_init_attr *attr)
{
const struct vdpa_config_ops *ops;
struct vdpasim *vdpasim;
+ u32 device_id;
struct device *dev;
- int ret = -ENOMEM;
+ int i, size, ret = -ENOMEM;
- if (batch_mapping)
- ops = _net_batch_config_ops;
+ device_id = attr->device_id;
+ /* Currently, we only accept the network and block devices. */
+ if (device_id != VIRTIO_ID_NET && device_id != VIRTIO_ID_BLOCK)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ if (attr->batch_mapping)
+ ops = _batch_config_ops;
else
- ops = _net_config_ops;
+ ops = _config_ops;
vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
VDPASIM_VQ_NUM);
if (!vdpasim)
goto err_alloc;
- INIT_WORK(>work, vdpasim_work);
+ if (device_id == VIRTIO_ID_NET)
+ size = sizeof(struct virtio_net_config);
+ else
+ size = sizeof(struct virtio_blk_config);
It's better to avoid such if/else consider we may introduce more type
of devices.
Can we have an attribute of config size instead?
Yes, I'll move the patch 7 before this.
About config size and set/get_config ops, I'm not sure if it is better
to hidden everything under the new set/get_config ops, allocating the
config structure in each device, or leave the allocation in the core
and update it like now.
I think we'd better to avoid having any type specific codes in generic
sim codes.
[...]
+config VDPA_SIM_NET
+ tristate "vDPA simulator for networking device"
+ depends on VDPA_SIM
+ default n
I remember somebody told me that if we don't enable a module it was
disabled by default.
So, should I remove "default n" from vdpa_sim* entries?
Yes, but please do that in another patch.
Thanks
Thanks,
Stefano
Re: [PATCH v2] arm64: tegra: jetson-tx1: Fix USB_VBUS_EN0 regulator
On Thu, Nov 19, 2020 at 11:07:29AM +0800, JC Kuo wrote:
> USB_VBUS_EN0 regulator (regulator@11) is being overwritten by vdd-cam-1v2
> regulator. This commit rearrange USB_VBUS_EN0 to be regulator@14.
>
> Fixes: 257c8047be44 ("arm64: tegra: jetson-tx1: Add camera supplies")
> Signed-off-by: JC Kuo
> Reviewed-by: Jon Hunter
> ---
> v2:
> add 'Fixes:' tag
> add Reviewed-by: Jon Hunter
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM
On Thu, Nov 19, 2020 at 7:29 AM Saeed Mirzamohammadi wrote: > > This adds crashkernel=auto feature to configure reserved memory for > vmcore creation to both x86 and ARM platforms based on the total memory > size. Thanks for the patch! This is very helpful for distribution makers, this allows the distro to have better control of the crashkernel size and ship it with the kernel. The crashkernel value is sensitive to kernel and driver changes, so shipping it with the kernel makes sense. And I think crashkernel=auto could be used as an indicator that user want the kernel to control the crashkernel size, so some further work could be done to adjust the crashkernel more accordingly. eg. when memory encryption is enabled, increase the crashkernel value for the auto estimation, as it's known to consume more crashkernel memory. There have been a lot of efforts trying to push this in upstream: https://lkml.org/lkml/2018/5/20/262 https://lkml.org/lkml/2009/8/12/61 Still, it's not yet accepted. it's good to see more people working on this. But why not make it arch-independent? This crashkernel=auto idea should simply work with every arch. > > Cc: sta...@vger.kernel.org > Signed-off-by: John Donnelly > Signed-off-by: Saeed Mirzamohammadi > --- > Documentation/admin-guide/kdump/kdump.rst | 5 + > arch/arm64/Kconfig| 26 ++- > arch/arm64/configs/defconfig | 1 + > arch/x86/Kconfig | 26 ++- > arch/x86/configs/x86_64_defconfig | 1 + > kernel/crash_core.c | 20 +++-- > 6 files changed, 75 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/kdump/kdump.rst > b/Documentation/admin-guide/kdump/kdump.rst > index 75a9dd98e76e..f95a2af64f59 100644 > --- a/Documentation/admin-guide/kdump/kdump.rst > +++ b/Documentation/admin-guide/kdump/kdump.rst > @@ -285,7 +285,12 @@ This would mean: > 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M > 3) if the RAM size is larger than 2G, then reserve 128M > > +Or you can use crashkernel=auto if you have enough memory. The threshold > +is 1G on x86_64 and arm64. If your system memory is less than the threshold, > +crashkernel=auto will not reserve memory. The size changes according to > +the system memory size like below: > > +x86_64/arm64: 1G-64G:128M,64G-1T:256M,1T-:512M > > Boot into System Kernel > === > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1515f6f153a0..d359dcffa80e 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1124,7 +1124,7 @@ comment "Support for PE file signature verification > disabled" > depends on KEXEC_SIG > depends on !EFI || !SIGNED_PE_FILE_VERIFICATION > > -config CRASH_DUMP > +menuconfig CRASH_DUMP > bool "Build kdump crash kernel" > help > Generate crash dump after being started by kexec. This should > @@ -1135,6 +1135,30 @@ config CRASH_DUMP > > For more details see Documentation/admin-guide/kdump/kdump.rst > > +if CRASH_DUMP > + > +config CRASH_AUTO_STR > +string "Memory reserved for crash kernel" > + depends on CRASH_DUMP > +default "1G-64G:128M,64G-1T:256M,1T-:512M" > + help > + This configures the reserved memory dependent > + on the value of System RAM. The syntax is: > + crashkernel=:[,:,...][@offset] > + range=start-[end] > + > + For example: > + crashkernel=512M-2G:64M,2G-:128M > + > + This would mean: > + > + 1) if the RAM is smaller than 512M, then don't reserve anything > +(this is the "rescue" case) > + 2) if the RAM size is between 512M and 2G (exclusive), then > reserve 64M > + 3) if the RAM size is larger than 2G, then reserve 128M > + > +endif # CRASH_DUMP > + > config XEN_DOM0 > def_bool y > depends on XEN > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 5cfe3cf6f2ac..899ef3b6a78f 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -69,6 +69,7 @@ CONFIG_SECCOMP=y > CONFIG_KEXEC=y > CONFIG_KEXEC_FILE=y > CONFIG_CRASH_DUMP=y > +# CONFIG_CRASH_AUTO_STR is not set > CONFIG_XEN=y > CONFIG_COMPAT=y > CONFIG_RANDOMIZE_BASE=y > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f6946b81f74a..bacd17312bb1 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2035,7 +2035,7 @@ config KEXEC_BZIMAGE_VERIFY_SIG > help > Enable bzImage signature verification support. > > -config CRASH_DUMP > +menuconfig CRASH_DUMP > bool "kernel crash dumps" > depends on X86_64 || (X86_32 && HIGHMEM) > help > @@ -2049,6 +2049,30 @@ config CRASH_DUMP > (CONFIG_RELOCATABLE=y). > For more details see
[PATCH v4 0/3] Add support for Encryption and Casefolding in F2FS
These patches are on top of the torvalds tree. F2FS currently supports casefolding and encryption, but not at the same time. These patches aim to rectify that. In a later follow up, this will be added for Ext4 as well. The f2fs-tools changes have already been applied. Since both fscrypt and casefolding require their own dentry operations, I've moved the responsibility of setting the dentry operations from fscrypt to the filesystems and provided helper functions that should work for most cases. These are a follow-up to the previously sent patch set "[PATCH v12 0/4] Prepare for upcoming Casefolding/Encryption patches" v2: Simplified generic dentry_op function Passed through errors in f2fs_match_ci_name v3: Split some long lines Cleaned up some code Made some comments clearer Fixed bug in v2 error passing v4: Added reviewed bys and acks from Eric Removed unneeded variable ifdef consistency Daniel Rosenberg (3): libfs: Add generic function for setting dentry_ops fscrypt: Have filesystems handle their d_ops f2fs: Handle casefolding with Encryption fs/crypto/fname.c | 4 -- fs/crypto/fscrypt_private.h | 1 - fs/crypto/hooks.c | 1 - fs/ext4/dir.c | 7 --- fs/ext4/ext4.h | 4 -- fs/ext4/namei.c | 1 + fs/ext4/super.c | 5 -- fs/f2fs/dir.c | 105 ++-- fs/f2fs/f2fs.h | 11 ++-- fs/f2fs/hash.c | 11 +++- fs/f2fs/inline.c| 4 ++ fs/f2fs/namei.c | 1 + fs/f2fs/recovery.c | 12 - fs/f2fs/super.c | 7 --- fs/libfs.c | 70 fs/ubifs/dir.c | 1 + include/linux/fs.h | 1 + include/linux/fscrypt.h | 7 ++- 18 files changed, 185 insertions(+), 68 deletions(-) base-commit: 0fa8ee0d9ab95c9350b8b84574824d9a384a9f7d -- 2.29.2.454.gaff20da3a2-goog
[PATCH v4 2/3] fscrypt: Have filesystems handle their d_ops
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
they have their own specific dentry operations as well. That operation
will set the minimal d_ops required under the circumstances.
Since the fscrypt d_ops are set later on, we must set all d_ops there,
since we cannot adjust those later on. This should not result in any
change in behavior.
Signed-off-by: Daniel Rosenberg
Acked-by: Eric Biggers
---
fs/crypto/fname.c | 4
fs/crypto/fscrypt_private.h | 1 -
fs/crypto/hooks.c | 1 -
fs/ext4/dir.c | 7 ---
fs/ext4/ext4.h | 4
fs/ext4/namei.c | 1 +
fs/ext4/super.c | 5 -
fs/f2fs/dir.c | 7 ---
fs/f2fs/f2fs.h | 3 ---
fs/f2fs/namei.c | 1 +
fs/f2fs/super.c | 1 -
fs/ubifs/dir.c | 1 +
include/linux/fscrypt.h | 7 +--
13 files changed, 8 insertions(+), 35 deletions(-)
diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
index 1fbe6c24d705..cb3cfa6329ba 100644
--- a/fs/crypto/fname.c
+++ b/fs/crypto/fname.c
@@ -570,7 +570,3 @@ int fscrypt_d_revalidate(struct dentry *dentry, unsigned
int flags)
return valid;
}
EXPORT_SYMBOL_GPL(fscrypt_d_revalidate);
-
-const struct dentry_operations fscrypt_d_ops = {
- .d_revalidate = fscrypt_d_revalidate,
-};
diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
index 4f5806a3b73d..df9c48c1fbf7 100644
--- a/fs/crypto/fscrypt_private.h
+++ b/fs/crypto/fscrypt_private.h
@@ -294,7 +294,6 @@ int fscrypt_fname_encrypt(const struct inode *inode, const
struct qstr *iname,
bool fscrypt_fname_encrypted_size(const union fscrypt_policy *policy,
u32 orig_len, u32 max_len,
u32 *encrypted_len_ret);
-extern const struct dentry_operations fscrypt_d_ops;
/* hkdf.c */
diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c
index 20b0df47fe6a..9006fa983335 100644
--- a/fs/crypto/hooks.c
+++ b/fs/crypto/hooks.c
@@ -117,7 +117,6 @@ int __fscrypt_prepare_lookup(struct inode *dir, struct
dentry *dentry,
spin_lock(>d_lock);
dentry->d_flags |= DCACHE_NOKEY_NAME;
spin_unlock(>d_lock);
- d_set_d_op(dentry, _d_ops);
}
return err;
}
diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index ca50c90adc4c..e757319a4472 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -667,10 +667,3 @@ const struct file_operations ext4_dir_operations = {
.open = ext4_dir_open,
.release= ext4_release_dir,
};
-
-#ifdef CONFIG_UNICODE
-const struct dentry_operations ext4_dentry_ops = {
- .d_hash = generic_ci_d_hash,
- .d_compare = generic_ci_d_compare,
-};
-#endif
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index bf9429484462..ad77f01d9e20 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3380,10 +3380,6 @@ static inline void ext4_unlock_group(struct super_block
*sb,
/* dir.c */
extern const struct file_operations ext4_dir_operations;
-#ifdef CONFIG_UNICODE
-extern const struct dentry_operations ext4_dentry_ops;
-#endif
-
/* file.c */
extern const struct inode_operations ext4_file_inode_operations;
extern const struct file_operations ext4_file_operations;
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 33509266f5a0..12a417ff5648 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1614,6 +1614,7 @@ static struct buffer_head *ext4_lookup_entry(struct inode
*dir,
struct buffer_head *bh;
err = ext4_fname_prepare_lookup(dir, dentry, );
+ generic_set_encrypted_ci_d_ops(dentry);
if (err == -ENOENT)
return NULL;
if (err)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6633b20224d5..0288bedf46e1 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
goto failed_mount4;
}
-#ifdef CONFIG_UNICODE
- if (sb->s_encoding)
- sb->s_d_op = _dentry_ops;
-#endif
-
sb->s_root = d_make_root(root);
if (!sb->s_root) {
ext4_msg(sb, KERN_ERR, "get root dentry failed");
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 4b9ef8bbfa4a..71fdf5076461 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -1099,10 +1099,3 @@ const struct file_operations f2fs_dir_operations = {
.compat_ioctl = f2fs_compat_ioctl,
#endif
};
-
-#ifdef CONFIG_UNICODE
-const struct dentry_operations f2fs_dentry_ops = {
- .d_hash = generic_ci_d_hash,
- .d_compare = generic_ci_d_compare,
-};
-#endif
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cb700d797296..62b4f31d30e2 100644
--- a/fs/f2fs/f2fs.h
+++
[PATCH v4 3/3] f2fs: Handle casefolding with Encryption
Expand f2fs's casefolding support to include encrypted directories. To
index casefolded+encrypted directories, we use the SipHash of the
casefolded name, keyed by a key derived from the directory's fscrypt
master key. This ensures that the dirhash doesn't leak information
about the plaintext filenames.
Encryption keys are unavailable during roll-forward recovery, so we
can't compute the dirhash when recovering a new dentry in an encrypted +
casefolded directory. To avoid having to force a checkpoint when a new
file is fsync'ed, store the dirhash on-disk appended to i_name.
This patch incorporates work by Eric Biggers
and Jaegeuk Kim .
Co-developed-by: Eric Biggers
Signed-off-by: Eric Biggers
Signed-off-by: Daniel Rosenberg
Reviewed-by: Eric Biggers
---
fs/f2fs/dir.c | 98 +++---
fs/f2fs/f2fs.h | 8 ++--
fs/f2fs/hash.c | 11 +-
fs/f2fs/inline.c | 4 ++
fs/f2fs/recovery.c | 12 +-
fs/f2fs/super.c| 6 ---
6 files changed, 106 insertions(+), 33 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 71fdf5076461..82b58d1f80eb 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -5,6 +5,7 @@
* Copyright (c) 2012 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*/
+#include
#include
#include
#include
@@ -206,30 +207,55 @@ static struct f2fs_dir_entry *find_in_block(struct inode
*dir,
/*
* Test whether a case-insensitive directory entry matches the filename
* being searched for.
+ *
+ * Returns 1 for a match, 0 for no match, and -errno on an error.
*/
-static bool f2fs_match_ci_name(const struct inode *dir, const struct qstr
*name,
+static int f2fs_match_ci_name(const struct inode *dir, const struct qstr *name,
const u8 *de_name, u32 de_name_len)
{
const struct super_block *sb = dir->i_sb;
const struct unicode_map *um = sb->s_encoding;
+ struct fscrypt_str decrypted_name = FSTR_INIT(NULL, de_name_len);
struct qstr entry = QSTR_INIT(de_name, de_name_len);
int res;
+ if (IS_ENCRYPTED(dir)) {
+ const struct fscrypt_str encrypted_name =
+ FSTR_INIT((u8 *)de_name, de_name_len);
+
+ if (WARN_ON_ONCE(!fscrypt_has_encryption_key(dir)))
+ return -EINVAL;
+
+ decrypted_name.name = kmalloc(de_name_len, GFP_KERNEL);
+ if (!decrypted_name.name)
+ return -ENOMEM;
+ res = fscrypt_fname_disk_to_usr(dir, 0, 0, _name,
+ _name);
+ if (res < 0)
+ goto out;
+ entry.name = decrypted_name.name;
+ entry.len = decrypted_name.len;
+ }
+
res = utf8_strncasecmp_folded(um, name, );
- if (res < 0) {
- /*
-* In strict mode, ignore invalid names. In non-strict mode,
-* fall back to treating them as opaque byte sequences.
-*/
- if (sb_has_strict_encoding(sb) || name->len != entry.len)
- return false;
- return !memcmp(name->name, entry.name, name->len);
+ /*
+* In strict mode, ignore invalid names. In non-strict mode,
+* fall back to treating them as opaque byte sequences.
+*/
+ if (res < 0 && !sb_has_strict_encoding(sb)) {
+ res = name->len == entry.len &&
+ memcmp(name->name, entry.name, name->len) == 0;
+ } else {
+ /* utf8_strncasecmp_folded returns 0 on match */
+ res = (res == 0);
}
- return res == 0;
+out:
+ kfree(decrypted_name.name);
+ return res;
}
#endif /* CONFIG_UNICODE */
-static inline bool f2fs_match_name(const struct inode *dir,
+static inline int f2fs_match_name(const struct inode *dir,
const struct f2fs_filename *fname,
const u8 *de_name, u32 de_name_len)
{
@@ -256,6 +282,7 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(const struct
f2fs_dentry_ptr *d,
struct f2fs_dir_entry *de;
unsigned long bit_pos = 0;
int max_len = 0;
+ int res = 0;
if (max_slots)
*max_slots = 0;
@@ -273,10 +300,15 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(const
struct f2fs_dentry_ptr *d,
continue;
}
- if (de->hash_code == fname->hash &&
- f2fs_match_name(d->inode, fname, d->filename[bit_pos],
- le16_to_cpu(de->name_len)))
- goto found;
+ if (de->hash_code == fname->hash) {
+ res = f2fs_match_name(d->inode, fname,
+ d->filename[bit_pos],
+
[PATCH v4 1/3] libfs: Add generic function for setting dentry_ops
This adds a function to set dentry operations at lookup time that will
work for both encrypted filenames and casefolded filenames.
A filesystem that supports both features simultaneously can use this
function during lookup preparations to set up its dentry operations once
fscrypt no longer does that itself.
Currently the casefolding dentry operation are always set if the
filesystem defines an encoding because the features is toggleable on
empty directories. Unlike in the encryption case, the dentry operations
used come from the parent. Since we don't know what set of functions
we'll eventually need, and cannot change them later, we enable the
casefolding operations if the filesystem supports them at all.
By splitting out the various cases, we support as few dentry operations
as we can get away with, maximizing compatibility with overlayfs, which
will not function if a filesystem supports certain dentry_operations.
Signed-off-by: Daniel Rosenberg
Reviewed-by: Eric Biggers
---
fs/libfs.c | 70 ++
include/linux/fs.h | 1 +
2 files changed, 71 insertions(+)
diff --git a/fs/libfs.c b/fs/libfs.c
index fc34361c1489..bac918699022 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -1449,4 +1449,74 @@ int generic_ci_d_hash(const struct dentry *dentry,
struct qstr *str)
return 0;
}
EXPORT_SYMBOL(generic_ci_d_hash);
+
+static const struct dentry_operations generic_ci_dentry_ops = {
+ .d_hash = generic_ci_d_hash,
+ .d_compare = generic_ci_d_compare,
+};
+#endif
+
+#ifdef CONFIG_FS_ENCRYPTION
+static const struct dentry_operations generic_encrypted_dentry_ops = {
+ .d_revalidate = fscrypt_d_revalidate,
+};
+#endif
+
+#if defined(CONFIG_FS_ENCRYPTION) && defined(CONFIG_UNICODE)
+static const struct dentry_operations generic_encrypted_ci_dentry_ops = {
+ .d_hash = generic_ci_d_hash,
+ .d_compare = generic_ci_d_compare,
+ .d_revalidate = fscrypt_d_revalidate,
+};
+#endif
+
+/**
+ * generic_set_encrypted_ci_d_ops - helper for setting d_ops for given dentry
+ * @dentry:dentry to set ops on
+ *
+ * Casefolded directories need d_hash and d_compare set, so that the dentries
+ * contained in them are handled case-insensitively. Note that these
operations
+ * are needed on the parent directory rather than on the dentries in it, and
+ * while the casefolding flag can be toggled on and off on an empty directory,
+ * dentry_operations can't be changed later. As a result, if the filesystem
has
+ * casefolding support enabled at all, we have to give all dentries the
+ * casefolding operations even if their inode doesn't have the casefolding flag
+ * currently (and thus the casefolding ops would be no-ops for now).
+ *
+ * Encryption works differently in that the only dentry operation it needs is
+ * d_revalidate, which it only needs on dentries that have the no-key name
flag.
+ * The no-key flag can't be set "later", so we don't have to worry about that.
+ *
+ * Finally, to maximize compatibility with overlayfs (which isn't compatible
+ * with certain dentry operations) and to avoid taking an unnecessary
+ * performance hit, we use custom dentry_operations for each possible
+ * combination rather than always installing all operations.
+ */
+void generic_set_encrypted_ci_d_ops(struct dentry *dentry)
+{
+#ifdef CONFIG_FS_ENCRYPTION
+ bool needs_encrypt_ops = dentry->d_flags & DCACHE_NOKEY_NAME;
+#endif
+#ifdef CONFIG_UNICODE
+ bool needs_ci_ops = dentry->d_sb->s_encoding;
+#endif
+#if defined(CONFIG_FS_ENCRYPTION) && defined(CONFIG_UNICODE)
+ if (needs_encrypt_ops && needs_ci_ops) {
+ d_set_d_op(dentry, _encrypted_ci_dentry_ops);
+ return;
+ }
#endif
+#ifdef CONFIG_FS_ENCRYPTION
+ if (needs_encrypt_ops) {
+ d_set_d_op(dentry, _encrypted_dentry_ops);
+ return;
+ }
+#endif
+#ifdef CONFIG_UNICODE
+ if (needs_ci_ops) {
+ d_set_d_op(dentry, _ci_dentry_ops);
+ return;
+ }
+#endif
+}
+EXPORT_SYMBOL(generic_set_encrypted_ci_d_ops);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8667d0cdc71e..11345e66353b 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3202,6 +3202,7 @@ extern int generic_ci_d_hash(const struct dentry *dentry,
struct qstr *str);
extern int generic_ci_d_compare(const struct dentry *dentry, unsigned int len,
const char *str, const struct qstr *name);
#endif
+extern void generic_set_encrypted_ci_d_ops(struct dentry *dentry);
#ifdef CONFIG_MIGRATION
extern int buffer_migrate_page(struct address_space *,
--
2.29.2.454.gaff20da3a2-goog
linux-next: Tree for Nov 19
Hi all, Changes since 20201118: The phy-next tree lost its a build failure. The dmaengine tree gained a conflict against the dmaengine-fixes tree. The gpio tree lost its build failure. The mhi tree lost its build failure. Non-merge commits (relative to Linus' tree): 6286 6273 files changed, 557265 insertions(+), 104469 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 327 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (c2e7554e1b85 Merge tag 'gfs2-v5.10-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super early in asm boot trampoline) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (23c216416056 arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver) Merging arm-soc-fixes/arm/fixes (cc05af8e2e91 Merge tag 'imx-fixes-5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes) Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (cd81acc600a9 powerpc/64s/exception: KVM Fix for host DSI being taken in HPT guest MMU context) Merging s390-fixes/fixes (78d732e1f326 s390/cpum_sf.c: fix file permission for cpum_sfb_size) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (a3dcb3e7e70c net: dsa: mv88e6xxx: Wait for EEPROM done after HW reset) Merging bpf/master (4363023d2668 bpf, sockmap: Avoid failures from skb_to_sgvec when skb has frag_list) Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in xfrm_user_policy()) Merging netfilter/master (e59d6e876580 netfilter: nftables_offload: build mask based from the matching bytes) Merging ipvs/master (e59d6e876580 netfilter: nftables_offload: build mask based from the matching bytes) Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in case of assert during CSA) Merging mac80211/master (849920c70339 devlink: Add missing genlmsg_cancel() in devlink_nl_sb_port_pool_fill()) Merging rdma-fixes/for-rc (dabbd6abcdbe IB/hfi1: Fix error return code in hfi1_init_dd()) Merging sound-current/for-linus (54a2a3898f46 ALSA: usb-audio: Add delay quirk for all Logitech USB devices) Merging sound-asoc-fixes/for-linus (12a309713362 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (3650b228f83a Linux 5.10-rc1) Merging regulator-fixes/for-linus (2ba546ebe0ce regulator: ti-abb: Fix array out of bound read access on the first transition) Merging spi-fixes/for-linus (ce069a5266eb Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging pci-current/for-linus (51e2e24504ad PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller) Merging driver
