Re: GPS fun on Droid 4 and leste
Hi! > > GPS on the droid 4 does not really work out of the box. > > > > gpsd is not in default installation, maybe it should be? > > > > What is worse, there's something broken with gpsd. Try: > > > > /usr/sbin/gpsd -N -D 5 /dev/gnss0 > > gpspipe -w > > # this seems to work, but do ^C and restart > > gpspipe -w > > ...and it hangs. > > Some earlier versions of gpsd I think had issues where you could > only connect one client. Or it was a bug in the kernel drivers.. > Anyways, multiple gpspipe instances have been working for me for > a while now with gpsd-3.21. > > I also found some issues in gnss-motmdm driver for closing the > gnss device, see: > > https://github.com/tmlind/linux/commits/droid4-pending-v5.8 > > And I think the xtra2.bin data for agps is now working too :) > > https://github.com/tmlind/droid4-agps/commits/master > > At least I now get a fix in about two minutes after running the > update.sh, going outside, and starting cgps. Ok, let me play. But you should be getting fix in two minutes _without_ AGPS support, if GPS is any good... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 00/49] DRM driver for Hikey 970
Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart > wrote: > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > Based on his history, this driver seems to be originally written > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > implementation for FB dev API. > > > > > > > > As I need to preserve the original history (with has patches from > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > patch applied there. The remaining patches are incremental, > > > > and port this driver to work with upstream Kernel. > > > > > ... > > > > - Due to legal reasons, I need to preserve the authorship of > > > > each one responsbile for each patch. So, I need to start from > > > > the original patch from Kernel 4.4; > ... > > > I do acknowledge you need to preserve history and all - > > > but this patchset is not easy to review. > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > that contains the history is useful if anyone is interested, but I don't > > think it's required in mainline. > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > have on this but preserving the "absolute" history here is actively > detrimental for review and understanding of the patch set. > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > lines should be sufficient to provide both atribution credit and DCO > history. I'm not convinced that, from legal standpoint, folding things would be enough. See, there are at least 3 legal systems involved here among the different patch authors: - civil law; - common law; - customary law + common law. Merging stuff altogether from different law systems can be problematic, and trying to discuss this with experienced IP property lawyers will for sure take a lot of time and efforts. I also bet that different lawyers will have different opinions, because laws are subject to interpretation. With that matter I'm not aware of any court rules with regards to folded patches. So, it sounds to me that folding patches is something that has yet to be proofed in courts around the globe. At least for US legal system, it sounds that the Country of origin of a patch is relevant, as they have a concept of "national technology" that can be subject to export regulations. From my side, I really prefer to play safe and stay out of any such legal discussions. Thanks, Mauro
Re: [PATCH] dt-bindings: mmc: sdhci-am654: Document bindings for the host controllers on TI's J7200 devices
Hi Ulf, On 18/08/20 2:47 am, Rob Herring wrote: > On Sun, 02 Aug 2020 12:31:14 +0530, Faiz Abbas wrote: >> Add binding documentation for mmc host controllers present on >> TI's J7200 SOC >> >> Signed-off-by: Faiz Abbas >> --- >> Documentation/devicetree/bindings/mmc/sdhci-am654.txt | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > Acked-by: Rob Herring > Can you pick this up now or should I rebase to latest? Thanks, Faiz
Re: pcm|dmaengine|imx-sdma race condition on i.MX6
On Wed, Aug 19, 2020 at 01:08:29PM +0200, Lars-Peter Clausen wrote: > > For the first option, which is potentially more performant, we have to > > leave the atomic PCM context > > and we are not sure if we are allowed to. > > For the second option, we would have to divide the dma_device terminate_all > > into an atomic sync and > > an async one, which would align with the dmaengine API, giving it the > > option to ensure termination > > in an atomic context. > > Based on my understanding, most of them are synchronous anyways, for the > > currently async ones we > > would have to implement busy waits. > > However, with this approach, we reach the WARN_ON [6] inside of an atomic > > context, > > indicating we might not do the right thing. > > I don't know how feasible this is to implement in the SDMA dmaengine driver. > But I think what is should do is to have some flag to indicate if a > terminate is in progress. If a new transfer is issued while terminate is in > progress the transfer should go on a list. Once terminate finishes it should > check the list and start the transfer if there are any on the list. The list is already there in form of the vchan helpers the driver uses. I think the big mistake the driver makes is to configure fields in struct sdma_channel and also the hardware directly in sdma_prep_memcpy(), sdma_prep_slave_sg() and sdma_prep_dma_cyclic(). All information should be stored in the struct sdma_desc allocated in the prep functions and only be used when it's time to fire that specific descriptor. More specifically sdma_config_write() may not be called from sdma_prep_slave_sg() or sdma_prep_dma_cyclic(), but instead must be called from sdma_start_desc(). sdma_config_ownership() also must be called later in sdma_start_desc(). 'direction' must be a member of struct sdma_desc, not of struct sdma_channel. Overall this sounds like a fair amount of work to do, but should be feasible and IMO is a step in the right direction. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [RFC v7 00/10] DAMON: Support Physical Memory Address Space Monitoring
On Wed, 19 Aug 2020 18:21:44 -0700 Shakeel Butt wrote: > On Tue, Aug 18, 2020 at 12:25 AM SeongJae Park wrote: > > > > From: SeongJae Park > > > > Changes from Previous Version > > = > > > > - Use 42 as the fake target id for paddr instead of -1 > > - Fix a typo > > > > Introduction > > > > > > DAMON[1] programming interface users can extend DAMON for any address space > > by > > configuring the address-space specific low level primitives with appropriate > > ones including their own implementations. However, because the > > implementation > > for the virtual address space is only available now, the users should > > implement > > their own for other address spaces. Worse yet, the user space users who > > rely > > on the debugfs interface and user space tool, cannot implement their own. > > > > This patchset implements another reference implementation of the low level > > primitives for the physical memory address space. With this change, hence, > > the > > kernel space users can monitor both the virtual and the physical address > > spaces > > by simply changing the configuration in the runtime. Further, this patchset > > links the implementation to the debugfs interface and the user space tool > > for > > the user space users. > > > > Note that the implementation supports only the user memory, as same to the > > idle > > page access tracking feature. > > > > [1] > > https://lore.kernel.org/linux-mm/20200706115322.29598-1-sjp...@amazon.com/ > > > > I am still struggling to find the benefit of this feature the way it > is implemented i.e. region based physical address space monitoring. > What exactly am I supposed to do for a given hot (or cold) physical > region? In a containerized world, that region can contain pages from > any cgroup. I can not really do anything about the accesses PHY-DAMON > provides me for a region. Technically speaking, this patchset introduces an implementation of DAMON's low level primitives for physical address space of LRU-listed pages. In other words, it is not designed for cgroups case. Also, please note that this patchset is only RFC, because it aims to only show the future plan of DAMON and get opinions about the concept before being serious. It will be serious only after the DAMON patchset is merged. Maybe I didn' made this point clear in the CV, sorry. I will state this clearly in the next spin. However, owing to the flexible design of DAMON, you can still use DAMON for cgroups case, though you need to make some efforts. There could be a number of ways. First, you could figure out the physical address regions for the target cgroups by yourself, set the target regions by yourself in 'damon_ctx' object and pass it to 'damon_start()'. For dynamic page allocations, you could check if a monitored region belongs to your target cgroup or not from your action making code, which could be implemented in the '->sample_cb()' or '->aggregate_cb()' callbacks. Note that you can even update the regions inside the callbacks. That is, you can remove regions containing pages of other containers, add new pages allocated for your target containers, adjust regions having pages of both other container and your target containers to represent only your target container's. Second, you could expand DAMON for cgroups by implementing your own low level primitives. You could also reuse some of the current implementation. For example, you could implement only '->init_target_regions' and '->update_target_regions' callbacks again so that only the pages of your target cgroup belongs in the target regions. However, if you need to monitor non-LRU-listed pages, you should implement '->prepare_access_checks()' and '->check_accesses()' callbacks. > > Now if you give me per-page information that would be useful as I can > at least get per-cgroup accesses (idle or re-use data) but that would > be as costly as Page Idle Tracking. So, seems you are saying about the 'adaptive regions adjustment' disabled page granularity monitoring case. Indeed. Same information comes with same overhead. Moreover, in the page granularity monitoring case, DAMON will make more space overhead (at least 8 bytes per page), because DAMON will represent each page as a physical address region having start address and end address, while Idle Pages Tracking can use only pfn. I'm planning optimizations for this page granularity case as a future work. However, if you don't strictly need page granularity accuracy, you could reduce the overhead by using larger granularity. That is, you can set the monitoring granularity as you want while the adaptive regions adjustment is disabled. You could even use variable granularity in this case using the callbacks mentioned above. So, DAMON is a framework rather than a tool. Though it comes with basic applications using DAMON as a framework (e.g., the virtual address space low primitives implementation, DAMON debugfs inter
Re: [PATCH] crypto: drbg: check blocklen is non zero
On Sun, Aug 02, 2020 at 10:12:47AM -0700, t...@redhat.com wrote: > From: Tom Rix > > Clang static analysis reports this error > > crypto/drbg.c:441:40: warning: Division by zero > padlen = (inputlen + sizeof(L_N) + 1) % (drbg_blocklen(drbg)); > ~^~~ > > When drbg_bocklen fails it returns 0. > > if (drbg && drbg->core) > return drbg->core->blocklen_bytes; > return 0; Yes but it can only fail if the drbg is not instantiated. If you're hitting the generate path with an uninstantiated drbg you've got bigger problems than a divide by zero. So how is this even possible? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] scsi: lpfc: fix typo
Fix spelling mistake: "Cant" -> "Can't"
Signed-off-by: Kaige Li
---
drivers/scsi/lpfc/lpfc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index ae0a825..d6c07ee 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -5944,7 +5944,7 @@ lpfc_debugfs_initialize(struct lpfc_vport *vport)
phba, &lpfc_debugfs_op_lockstat);
if (!phba->debug_lockstat) {
lpfc_printf_vlog(vport, KERN_ERR, LOG_INIT,
-"4610 Cant create debugfs lockstat\n");
+"4610 Can't create debugfs
lockstat\n");
goto debug_failed;
}
#endif
--
2.1.0
Re: [PATCH] drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
Am 20.08.20 um 07:26 schrieb Furquan Shaikh:
In `amdgpu_dm_update_backlight_caps()`, there is a local
`amdgpu_dm_backlight_caps` object that is filled in by
`amdgpu_acpi_get_backlight_caps()`. However, this object is
uninitialized before the call and hence the subsequent check for
aux_support can fail since it is not initialized by
`amdgpu_acpi_get_backlight_caps()` as well. This change initializes
this local `amdgpu_dm_backlight_caps` object to 0.
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e4b33c67b634..725d8af634ee 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2853,7 +2853,7 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
static void amdgpu_dm_update_backlight_caps(struct amdgpu_display_manager *dm)
{
#if defined(CONFIG_ACPI)
- struct amdgpu_dm_backlight_caps caps;
+ struct amdgpu_dm_backlight_caps caps = { 0 };
Please use memset instead of "{ 0 }" for initialization.
Christian.
if (dm->backlight_caps.caps_valid)
return;
Re: [RFC v7 06/10] mm/damon: Implement callbacks for physical memory monitoring
On Wed, 19 Aug 2020 17:26:15 -0700 Shakeel Butt wrote:
> On Tue, Aug 18, 2020 at 12:27 AM SeongJae Park wrote:
> >
> > From: SeongJae Park
> >
> > This commit implements the four callbacks (->init_target_regions,
> > ->update_target_regions, ->prepare_access_check, and ->check_accesses)
> > for the basic access monitoring of the physical memory address space.
> > By setting the callback pointers to point those, users can easily
> > monitor the accesses to the physical memory.
> >
> > Internally, it uses the PTE Accessed bit, as similar to that of the
> > virtual memory support. Also, it supports only user memory pages, as
> > idle page tracking also does, for the same reason. If the monitoring
> > target physical memory address range contains non-user memory pages,
> > access check of the pages will do nothing but simply treat the pages as
> > not accessed.
> >
> > Users who want to use other access check primitives and/or monitor the
> > non-user memory regions could implement and use their own callbacks.
> >
> > Signed-off-by: SeongJae Park
> [snip]
> > +static void damon_phys_mkold(unsigned long paddr)
> > +{
> > + struct page *page = damon_phys_get_page(PHYS_PFN(paddr));
> > + struct rmap_walk_control rwc = {
> > + .rmap_one = damon_page_mkold,
> > + .anon_lock = page_lock_anon_vma_read,
> > + };
> > + bool need_lock;
> > +
> > + if (!page)
> > + return;
> > +
> > + if (!page_mapped(page) || !page_rmapping(page))
> > + return;
>
> I don't think you want to skip the unmapped pages. The point of
> physical address space monitoring was to include the monitoring of
> unmapped pages, so, skipping them invalidates the underlying
> motivation.
I think my answer to your other mail[1] could be an answer to this. Let me
quote some from it:
```
Technically speaking, this patchset introduces an implementation of DAMON's low
level primitives for physical address space of LRU-listed pages. In other
words, it is not designed for cgroups case. Also, please note that this
patchset is only RFC, because it aims to only show the future plan of DAMON and
get opinions about the concept before being serious. It will be serious only
after the DAMON patchset is merged. Maybe I didn' made this point clear in the
CV, sorry. I will state this clearly in the next spin.
```
```
So, DAMON is a framework rather than a tool. Though it comes with basic
applications using DAMON as a framework (e.g., the virtual address space low
primitives implementation, DAMON debugfs interface, and the DAMON user space
tool) that could be useful in simple use cases, you need to code your
application on it if your use cases are out of the simple cases. I will also
develop more of such applications for more use-cases, but it will be only after
the framework is complete enough to be merged in the mainline.
```
Of course, we could prioritize the cgroup support if strongly required, though
I still prefer focusing on the framework itself for now.
[1] https://lore.kernel.org/linux-mm/20200820071052.24271-1-sjp...@amazon.com/
Thanks,
SeongJae Park
[tip:sched/core] BUILD SUCCESS 5f4a1c4ea44728aa80be21dbf3a0469b5ca81d88
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core branch HEAD: 5f4a1c4ea44728aa80be21dbf3a0469b5ca81d88 sched/topology: Mark SD_NUMA as SDF_NEEDS_GROUPS elapsed time: 787m configs tested: 89 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig powerpc powernv_defconfig sh ap325rxa_defconfig arc nsimosci_hs_smp_defconfig microblaze mmu_defconfig arm vf610m4_defconfig arm h5000_defconfig mipsnlm_xlp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig 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 sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 i386 randconfig-a002-20200818 i386 randconfig-a002-20200820 i386 randconfig-a004-20200820 i386 randconfig-a005-20200820 i386 randconfig-a003-20200820 i386 randconfig-a006-20200820 i386 randconfig-a001-20200820 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 x86_64 randconfig-a015-20200820 x86_64 randconfig-a012-20200820 x86_64 randconfig-a016-20200820 x86_64 randconfig-a014-20200820 x86_64 randconfig-a011-20200820 x86_64 randconfig-a013-20200820 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled
On 15-08-20, 00:55, Stephen Boyd wrote:
> Quoting Viresh Kumar (2020-08-12 21:29:00)
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index e8882e7fd8a5..5f5da257f58a 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -703,12 +703,10 @@ static int _generic_set_opp_regulator(struct
> > opp_table *opp_table,
> > * Enable the regulator after setting its voltages, otherwise it
> > breaks
> > * some boot-enabled regulators.
> > */
> > - if (unlikely(!opp_table->regulator_enabled)) {
> > + if (unlikely(!opp_table->enabled)) {
> > ret = regulator_enable(reg);
> > if (ret < 0)
> > dev_warn(dev, "Failed to enable regulator: %d",
> > ret);
> > - else
> > - opp_table->regulator_enabled = true;
>
> A quick glance makes this look unsafe now because we're only checking
> 'enabled' and not actually setting it when this function is called. I
> have to go back to the previous patch to understand where enabled is now
> set to confirm that it is OK. If it was all one patch all the context
> would be here.
The only case where things can go crazy are the cases where (for
example) clk_set_rate() fails, or something like that which would be a
bug and it shouldn't bother in the normal working of this code.
--
viresh
Re: [PATCH 00/49] DRM driver for Hikey 970
On 2020-08-19 10:48 p.m., Sam Ravnborg wrote: > Hi Mauro. > > It seems my review comments failed to reach dri-devel - likely due to > the size of the mail. Right, some e-mails in this thread went through the dri-devel moderation queue due to their sizes. This mail of yours did as well, because you didn't trim the quoted text (hint, hint). -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Re: [PATCH 00/49] DRM driver for Hikey 970
Hi Sam, Em Wed, 19 Aug 2020 22:48:00 +0200 Sam Ravnborg escreveu: > Hi Mauro. > > It seems my review comments failed to reach dri-devel - likely due to > the size of the mail. Probably. It reached here properly. > Link: > https://lore.kernel.org/linux-devicetree/20200819173558.ga3...@ravnborg.org/ > > I my review feedback I refer to checkpatch a few time. > For drivers/gpu/ we have some nice tooling support. > One thing our tooling does for us is running checkpatch every time > we apply a patch. > > checkpatch -q --emacs --strict --show-types > > So we expect patches to be more or less checkpatch --strict clean. > > "more or less" - as common sense also plays a role. > And sometimes checkpatch is just wrong. > > Just in case you wondered why checkpatch --strict was requested. We also use checkpatch --strict for media as a reference, ignoring the things that would make things worse during review :-) I'll run checkpatch here and ensure that the coding style issues will be properly addressed. Thanks, Mauro
Hi
Attention: Promptly email Mr David Bailey on to lay claims to your INHERITED FUNDS. Mr David Bailey
Re: [PATCH 0/2] KVM: arm64: Fix sleeping while atomic BUG() on OOM
On 18/08/20 12:16, Will Deacon wrote: > Please note that I'm planning on rewriting most of the arm64 KVM page-table > code for 5.10, so if you can get this series in early (e.g. for -rc2), then > it would _really_ help with managing the kvm/arm64 queue for the next merge > window. Yes, I plan to send it tomorrow. Paolo
Re: [PATCH] drm/vkms: add alpha-premultiplied color blending
On Wed, 19 Aug 2020 17:53:36 -0300
Melissa Wen wrote:
> The current VKMS blend function ignores alpha channel and just overwrites
> vaddr_src with vaddr_dst. This XRGB approach triggers a warning when
> running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT
> tests, cairo_format_argb32 uses premultiplied alpha (according to
> documentation), so this patch considers premultiplied alpha colors to
> compose vaddr_src with vaddr_dst.
>
> This change removes the following cursor-alpha-transparent warning:
> Suspicious CRC: All values are 0.
>
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 43 +---
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4f3b07a32b60..6aac962d3e2e 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -32,8 +32,6 @@ static uint32_t compute_crc(void *vaddr_out, struct
> vkms_composer *composer)
> src_offset = composer->offset
>+ (i * composer->pitch)
>+ (j * composer->cpp);
> - /* XRGB format ignores Alpha channel */
> - bitmap_clear(vaddr_out + src_offset, 24, 8);
> crc = crc32_le(crc, vaddr_out + src_offset,
> sizeof(u32));
> }
> @@ -42,6 +40,32 @@ static uint32_t compute_crc(void *vaddr_out, struct
> vkms_composer *composer)
> return crc;
> }
>
> +u8 blend_channel(u8 c_src, u8 c_dst, u8 a_src)
> +{
> + u32 pre_blend;
> + u8 new_color;
> +
> + /* Premultiplied alpha blending - IGT + cairo context */
> + pre_blend = (c_src * 255 + c_dst * (255 - a_src));
> +
> + /* Faster div by 255 */
> + new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8);
> +
> + return new_color;
> +}
> +
> +void alpha_blending(u8 *argb_src, u8 *argb_dst)
> +{
> + u8 a_src;
> +
> + a_src = argb_src[3];
Hi,
DRM pixel formats are often defined as "bits in a 32-bit word", but
here you are accessing it as an array of bytes. To me that looks
suspicious wrt. big-endian architectures.
Unfortunately I have again forgot how DRM pixel formats should be
interpreted on a big-endian machine, if I ever even understood it, so I
can't say if this is right or not.
Thanks,
pq
> + argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], a_src);
> + argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], a_src);
> + argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], a_src);
> + /* Opaque primary */
> + argb_dst[3] = 0xFF;
> +}
> +
> /**
> * blend - blend value at vaddr_src with value at vaddr_dst
> * @vaddr_dst: destination address
> @@ -50,12 +74,9 @@ static uint32_t compute_crc(void *vaddr_out, struct
> vkms_composer *composer)
> * @src_composer: source framebuffer's metadata
> *
> * Blend value at vaddr_src with value at vaddr_dst.
> - * Currently, this function write value of vaddr_src on value
> - * at vaddr_dst using buffer's metadata to locate the new values
> - * from vaddr_src and their destination at vaddr_dst.
> - *
> - * TODO: Use the alpha value to blend vaddr_src with vaddr_dst
> - *instead of overwriting it.
> + * Currently, this function considers premultiplied alpha for blending, as
> used
> + * by Cairo. It uses buffer's metadata to locate the new composite values at
> + * vaddr_dst.
> */
> static void blend(void *vaddr_dst, void *vaddr_src,
> struct vkms_composer *dest_composer,
> @@ -63,6 +84,7 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> {
> int i, j, j_dst, i_dst;
> int offset_src, offset_dst;
> + u8 *p_dst, *p_src;
>
> int x_src = src_composer->src.x1 >> 16;
> int y_src = src_composer->src.y1 >> 16;
> @@ -84,8 +106,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
>+ (i * src_composer->pitch)
>+ (j * src_composer->cpp);
>
> - memcpy(vaddr_dst + offset_dst,
> -vaddr_src + offset_src, sizeof(u32));
> + p_src = (u8 *)(vaddr_src + offset_src);
> + p_dst = (u8 *)(vaddr_dst + offset_dst);
> + alpha_blending(p_src, p_dst);
> }
> i_dst++;
> }
pgpBOZ4Vmzlt4.pgp
Description: OpenPGP digital signature
Re: [PATCH v20 00/15] Introduce Data Access MONitor (DAMON)
On Mon, 17 Aug 2020 12:51:22 +0200 SeongJae Park wrote: > From: SeongJae Park > > Changes from Previous Version > = > > - Place 'CREATE_TRACE_POINTS' after '#include' statements (Steven Rostedt) > - Support large record file (Alkaid) > - Place 'put_pid()' of virtual monitoring targets in 'cleanup' callback > - Avoid conflict between concurrent DAMON users > - Update evaluation result document > > Introduction > > > DAMON is a data access monitoring framework subsystem for the Linux kernel. > The core mechanisms of DAMON called 'region based sampling' and 'adaptive > regions adjustment' (refer to 'mechanisms.rst' in the 11th patch of this > patchset for the detail) make it > > - accurate (The monitored information is useful for DRAM level memory >management. It might not appropriate for Cache-level accuracy, though.), > - light-weight (The monitoring overhead is low enough to be applied online >while making no impact on the performance of the target workloads.), and > - scalable (the upper-bound of the instrumentation overhead is controllable >regardless of the size of target workloads.). > > Using this framework, therefore, the kernel's core memory management > mechanisms > such as reclamation and THP can be optimized for better memory management. > The > experimental memory management optimization works that incurring high > instrumentation overhead will be able to have another try. In user space, > meanwhile, users who have some special workloads will be able to write > personalized tools or applications for deeper understanding and specialized > optimizations of their systems. DAMON will be presented in the next week LPC[1]. To be prepared for a screen sharing error (if I get no such error, I will do a live-demo), I recorded a simple demo video. I would like to share it here to help your easier understanding of DAMON. https://youtu.be/l63eqbVBZRY [1] https://linuxplumbersconf.org/event/7/contributions/659/ Thanks, SeongJae Park
Re: [PATCH] dt-bindings: PCI: intel,lgm-pcie: Fix matching on all snps,dw-pcie instances
On 8/20/2020 6:20 AM, Rob Herring wrote:
The intel,lgm-pcie binding is matching on all snps,dw-pcie instances
which is wrong. Add a custom 'select' entry to fix this.
Fixes: e54ea45a4955 ("dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC
controller")
Cc: Bjorn Helgaas
Cc: Dilip Kota
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring
---
I'll take this via the DT tree.
Rob
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
index 64b2c64ca806..a1e2be737eec 100644
--- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -9,6 +9,14 @@ title: PCIe RC controller on Intel Gateway SoCs
maintainers:
- Dilip Kota
+select:
+ properties:
+compatible:
+ contains:
+const: intel,lgm-pcie
+ required:
+- compatible
+
properties:
compatible:
items:
Reviewed-by: Dilip Kota
Regards,
Dilip
Re: [PATCH v2 08/14] media: uapi: h264: Drop SLICE_PARAMS 'size' field
Hi Paul,
On Wed, 2020-08-19 at 15:54 +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Fri 07 Aug 20, 11:44, Ezequiel Garcia wrote:
> > On Thu, 2020-08-06 at 17:50 +0200, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Thu 06 Aug 20, 12:13, Ezequiel Garcia wrote:
> > > > The SLICE_PARAMS control is intended for slice-based
> > > > devices. In this mode, the OUTPUT buffer contains
> > > > a single slice, and so the buffer's plane payload size
> > > > can be used to query the slice size.
> > >
> > > If we later extend the API for supporting multiple slices with dynamic
> > > array
> > > controls, I guess we'll need to know the size of each slice in each
> > > control
> > > elements. So I'd rather keep that even if it's indeed redundant with
> > > vb2_get_plane_payload in single-slice mode.
> > >
> >
> > If we later extend the API, another control (possibly
> > another decoding mode?) shall be introduced.
> >
> > This API covers single-slice-per-request as specified
> > and documented in patch 9/14 "Clarify SLICE_BASED mode".
> >
> > This is along the lines of the proposal drafted by Nicolas,
> > see my reply: https://lkml.org/lkml/2020/8/5/791.
> >
> > This applies to num_slices, slice size and slice start offset.
> >
> > There are multiple ways of doing this.
>
> If feels a bit problematic to remove these fields without a clear plan yet
> on how to support multiple slices in the future. These may need to be added
> again later, except that it will be too late and new controls will need to be
> introduced.
>
As Nicolas and I have repeatedly mentioned we do have a plan :)
Nothing prevents us from implementing this now, but since it seems
we don't have any need since the 1-slice-per-buffer is working well,
there is no motivation for it.
As you well mention, it does require new controls. This is
totally expected since new decoding semantics will need new controls.
Here's my version of the plan:
enum v4l2_mpeg_video_h264_decode_mode {
V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED,
V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_ARRAY_BASED,
V4L2_MPEG_VIDEO_H264_DECODE_MODE_FRAME_BASED,
};
#define V4L2_CID_MPEG_VIDEO_H264_SLICE_ARRAY(V4L2_CID_MPEG_BASE+1008)
struct v4l2_ctrl_h264_slice_array {
__u16 num_slices;
struct v4l2_ctrl_h264_slice slices[16];
}
struct v4l2_ctrl_h264_slice {
__u32 size;
__u32 start_byte_offset;
struct v4l2_ctrl_h264_slice_params params;
}
Now, the _specific_ way this will be done is not under
discussion at the moment.
> Also, could we consider adding more reserved fields to handle such future
> needs?
>
I have considered that (on each control), but I fail
to see the reason for it. The same may be said of all controls,
yet I don't think we bloat each one just in case.
Thanks,
Ezequiel
> Cheers,
>
> Paul
>
> > Thanks!
> > Ezequiel
> >
> > > What do you think?
> > >
> > > Paul
> > >
> > > > To reduce the API surface drop the size from the
> > > > SLICE_PARAMS control.
> > > >
> > > > A follow-up change will remove other members in SLICE_PARAMS
> > > > so we don't need to add padding fields here.
> > > >
> > > > Signed-off-by: Ezequiel Garcia
> > > > ---
> > > > Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 3 ---
> > > > drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 7 +++
> > > > include/media/h264-ctrls.h| 3 ---
> > > > 3 files changed, 3 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > > index 427fc5727ec0..fff74b7bf32a 100644
> > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > > @@ -1760,9 +1760,6 @@ enum
> > > > v4l2_mpeg_video_h264_hierarchical_coding_type -
> > > > :stub-columns: 0
> > > > :widths: 1 1 2
> > > >
> > > > -* - __u32
> > > > - - ``size``
> > > > - -
> > > > * - __u32
> > > >- ``start_byte_offset``
> > > > Offset (in bytes) from the beginning of the OUTPUT buffer to
> > > > the start
> > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > > index a9ba78b15907..8b6f05aadbe8 100644
> > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > > @@ -324,17 +324,16 @@ static void cedrus_set_params(struct cedrus_ctx
> > > > *ctx,
> > > > struct vb2_buffer *src_buf = &run->src->vb2_buf;
> > > > struct cedrus_dev *dev = ctx->dev;
> > > > dma_addr_t src_buf_addr;
> > > > - u32 len = slice->size * 8;
> > > > + size_t slice_bytes = vb2_get_plane_payload(src_buf, 0);
> > > > unsigned int pic_width_in_mbs;
> > > > bool mbaff_pic;
> > >
Re: [PATCH] sched/fair: reduce preemption with IDLE tasks runable(Internet mail)
On Thu, 20 Aug 2020 at 02:13, benbjiang(蒋彪) wrote:
>
>
>
> > On Aug 19, 2020, at 10:55 PM, Vincent Guittot
> > wrote:
> >
> > On Wed, 19 Aug 2020 at 16:27, benbjiang(蒋彪) wrote:
> >>
> >>
> >>
> >>> On Aug 19, 2020, at 7:55 PM, Dietmar Eggemann
> >>> wrote:
> >>>
> >>> On 19/08/2020 13:05, Vincent Guittot wrote:
> On Wed, 19 Aug 2020 at 12:46, Dietmar Eggemann
> wrote:
> >
> > On 17/08/2020 14:05, benbjiang(蒋彪) wrote:
> >>
> >>
> >>> On Aug 17, 2020, at 4:57 PM, Dietmar Eggemann
> >>> wrote:
> >>>
> >>> On 14/08/2020 01:55, benbjiang(蒋彪) wrote:
> Hi,
>
> > On Aug 13, 2020, at 2:39 AM, Dietmar Eggemann
> > wrote:
> >
> > On 12/08/2020 05:19, benbjiang(蒋彪) wrote:
> >> Hi,
> >>
> >>> On Aug 11, 2020, at 11:54 PM, Dietmar Eggemann
> >>> wrote:
> >>>
> >>> On 11/08/2020 02:41, benbjiang(蒋彪) wrote:
> Hi,
>
> > On Aug 10, 2020, at 9:24 PM, Dietmar Eggemann
> > wrote:
> >
> > On 06/08/2020 17:52, benbjiang(蒋彪) wrote:
> >> Hi,
> >>
> >>> On Aug 6, 2020, at 9:29 PM, Dietmar Eggemann
> >>> wrote:
> >>>
> >>> On 03/08/2020 13:26, benbjiang(蒋彪) wrote:
>
>
> > On Aug 3, 2020, at 4:16 PM, Dietmar Eggemann
> > wrote:
> >
> > On 01/08/2020 04:32, Jiang Biao wrote:
> >> From: Jiang Biao
> >
> > [...]
> >
> >>> Are you sure about this?
> >> Yes. :)
> >>>
> >>> The math is telling me for the:
> >>>
> >>> idle task: (3 / (1024 + 1024 + 3))^(-1) * 4ms = 2735ms
> >>>
> >>> normal task: (1024 / (1024 + 1024 + 3))^(-1) * 4ms =8ms
> >>>
> >>> (4ms - 250 Hz)
> >> My tick is 1ms - 1000HZ, which seems reasonable for 600ms? :)
> >
> > OK, I see.
> >
> > But here the different sched slices (check_preempt_tick()->
> > sched_slice()) between normal tasks and the idle task play a role to.
> >
> > Normal tasks get ~3ms whereas the idle task gets <0.01ms.
>
> In fact that depends on the number of CPUs on the system
> :sysctl_sched_latency = 6ms * (1 + ilog(ncpus)) . On a 8 cores system,
> normal task will run around 12ms in one shoot and the idle task still
> one tick period
> >>>
> >>> True. This is on a single CPU.
> >> Agree. :)
> >>
> >>>
> Also, you can increase even more the period between 2 runs of idle
> task by using cgroups and min shares value : 2
> >>>
> >>> Ah yes, maybe this is what Jiang wants to do then? If his runtime does
> >>> not have other requirements preventing this.
> >> That could work for increasing the period between 2 runs. But could not
> >> reduce the single runtime of idle task I guess, which means normal task
> >> could have 1-tick schedule latency because of idle task.
> >
> > Yes. An idle task will preempt an always running task during 1 tick
> > every 680ms. But also you should keep in mind that a waking normal
> > task will preempt the idle task immediately which means that it will
> > not add scheduling latency to a normal task but "steal" 0.14% of
> > normal task throughput (1/680) at most
> That’s true. But in the VM case, when VM are busy(MWAIT passthrough
> or running cpu eating works), the 1-tick scheduling latency could be
> detected by cyclictest running in the VM.
>
> OTOH, we compensate vruntime in place_entity() to boot waking
> without distinguish SCHED_IDLE task, do you think it’s necessary to
> do that? like
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4115,7 +4115,7 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity
> *se, int initial)
> vruntime += sched_vslice(cfs_rq, se);
>
> /* sleeps up to a single latency don't count. */
> - if (!initial) {
> + if (!initial && likely(!task_has_idle_policy(task_of(se {
> unsigned long thresh = sysctl_sched_latency;
Yeah, this is a good improvement.
Does it solve your problem ?
>
> >
> >> OTOH, cgroups(shares) could introduce extra complexity. :)
> >>
> >> I wonder if there’s any possibility to make SCHED_IDLEs’ priorities
> >> absolutely
> >> lower than SCHED_NORMAL(OTHER), which means no weights/shares
> >> for them, and they run only when no other task’s runnable.
> >> I guess there may be priority inversion issue if we do that. But maybe we
> >
> > Exactly, that's why we must ensure a minimum running time for sched_idle
> > task
>
> Still for VM case, different VMs have been much isolated from each other,
> priority inversion issue could be very rare, we’re trying to make offline
> tasks
> absoultly harmless to online tasks. :)
>
> Thanks a lot for your time.
> Regards,
> Jiang
>
> >
> >> could avoid it by load-balance more
Re: [PATCH 2/2] nvme: add emulation for zone-append
On Thu, Aug 20, 2020 at 3:22 AM Keith Busch wrote:
>
> On Wed, Aug 19, 2020 at 01:11:58PM -0600, David Fugate wrote:
> > Intel does not support making *optional* NVMe spec features *required*
> > by the NVMe driver.
>
> This is inaccurate. As another example, the spec optionally allows a
> zone size to be a power of 2, but linux requires a power of 2 if you
> want to use it with this driver.
>
> > Provided there's no glaring technical issues
>
> There are many. Some may be improved through a serious review process,
> but the mess it makes out of the fast path is measurably harmful to
> devices that don't subscribe to this. That issue is not so easily
> remedied.
>
> Since this patch is a copy of the scsi implementation, the reasonable
> thing is take this fight to the generic block layer for a common
> solution. We're not taking this in the nvme driver.
I sincerely want to minimize any adverse impact to the fast-path of
non-zoned devices.
My understanding of that aspect is (I feel it is good to confirm,
irrespective of the future of this patch):
1. Submission path:
There is no extra code for non-zoned device IO. For append, there is
this "ns->append_emulate = 1" check.
Snippet -
case REQ_OP_ZONE_APPEND:
- ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_zone_append);
+ if (!nvme_is_append_emulated(ns))
+ ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_zone_append);
+ else {
+ /* prepare append like write, and adjust lba
afterwards */
2. Completion:
Not as clean as submission for sure.
The extra check is "ns && ns->append_emulate == 1" for completions if
CONFIG_ZONED is enabled.
A slightly better completion-handling version (than the submitted patch) is -
- } else if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) &&
- req_op(req) == REQ_OP_ZONE_APPEND) {
- req->__sector = nvme_lba_to_sect(req->q->queuedata,
- le64_to_cpu(nvme_req(req)->result.u64));
+ } else if (IS_ENABLED(CONFIG_BLK_DEV_ZONED)) {
+ struct nvme_ns *ns = req->q->queuedata;
+ /* append-emulation requires wp update for some cmds*/
+ if (ns && nvme_is_append_emulated(ns)) {
+ if (nvme_need_zone_wp_update(req))
+ nvme_zone_wp_update(ns, req, status);
+ }
+ else if (req_op(req) == REQ_OP_ZONE_APPEND)
+ req->__sector = nvme_lba_to_sect(ns,
+ le64_to_cpu(nvme_req(req)->result.u64));
Am I missing any other fast-path pain-points?
A quick 1 minute 4K randwrite run (QD 64, 4 jobs,libaio) shows :
before: IOPS=270k, BW=1056MiB/s (1107MB/s)(61.9GiB/60002msec)
after: IOPS=270k, BW=1055MiB/s (1106MB/s)(61.8GiB/60005msec)
This maynot be the best test to see the cost, and I am happy to
conduct more and improvise.
As for the volume of the code - it is same as SCSI emulation. And I
can make efforts to reduce that by moving common code to blk-zone, and
reuse in SCSI/NVMe emulation.
In the patch I tried to isolate append-emulation by keeping everything
into "nvme_za_emul". It contains nothing nvme'ish except nvme_ns,
which can be turned into "driver_data".
+#ifdef CONFIG_BLK_DEV_ZONED
+struct nvme_za_emul {
+ unsigned int nr_zones;
+ spinlock_t zones_wp_offset_lock;
+ u32 *zones_wp_offset;
+ u32 *rev_wp_offset;
+ struct work_struct zone_wp_offset_work;
+ char *zone_wp_update_buf;
+ struct mutex rev_mutex;
+ struct nvme_ns *ns;
+};
+#endif
Will that be an acceptable line of further work/discussions?
--
Kanchan
[PATCH RESEND] lib/fonts: add font 6x8 for oled display
From: Sven Schneider
This font is derived from lib/fonts/font_6x10.c and is useful for small OLED
displays.
---
Hi All,
I am not sure any new fonts are desired in the kernel. If yes, please consider
for inclusion, otherwise some "go away, there are enough fonts in the kernel
already" would be nice as well so I can stop trying getting it in :)
Sascha
include/linux/font.h |4 +-
lib/fonts/Kconfig|7 +
lib/fonts/Makefile |1 +
lib/fonts/font_6x8.c | 2575 ++
lib/fonts/fonts.c|3 +
5 files changed, 2589 insertions(+), 1 deletion(-)
mode change 100644 => 100755 include/linux/font.h
create mode 100644 lib/fonts/font_6x8.c
diff --git a/include/linux/font.h b/include/linux/font.h
old mode 100644
new mode 100755
index 51b91c8b69d58..4a3f8741bb7e5
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -33,6 +33,7 @@ struct font_desc {
#defineMINI4x6_IDX 9
#define FONT6x10_IDX 10
#define TER16x32_IDX 11
+#define FONT6x8_IDX12
extern const struct font_desc font_vga_8x8,
font_vga_8x16,
@@ -45,7 +46,8 @@ extern const struct font_desc font_vga_8x8,
font_acorn_8x8,
font_mini_4x6,
font_6x10,
- font_ter_16x32;
+ font_ter_16x32,
+ font_6x8;
/* Find a font with a specific name */
diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 37baa79cdd71f..c035fde66aebe 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -119,6 +119,12 @@ config FONT_TER16x32
This is the high resolution, large version for use with HiDPI screens.
If the standard font is unreadable for you, say Y, otherwise say N.
+config FONT_6x8
+ bool "OLED 6x8 font" if FONTS
+ depends on FRAMEBUFFER_CONSOLE
+ help
+ This font is useful for small displays (OLED).
+
config FONT_AUTOSELECT
def_bool y
depends on !FONT_8x8
@@ -132,6 +138,7 @@ config FONT_AUTOSELECT
depends on !FONT_SUN12x22
depends on !FONT_10x18
depends on !FONT_TER16x32
+ depends on !FONT_6x8
select FONT_8x16
endif # FONT_SUPPORT
diff --git a/lib/fonts/Makefile b/lib/fonts/Makefile
index ed95070860deb..e16f68492174a 100644
--- a/lib/fonts/Makefile
+++ b/lib/fonts/Makefile
@@ -15,6 +15,7 @@ font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
font-objs-$(CONFIG_FONT_6x10) += font_6x10.o
font-objs-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
+font-objs-$(CONFIG_FONT_6x8) += font_6x8.o
font-objs += $(font-objs-y)
diff --git a/lib/fonts/font_6x8.c b/lib/fonts/font_6x8.c
new file mode 100644
index 0..d70a9e4e30be9
--- /dev/null
+++ b/lib/fonts/font_6x8.c
@@ -0,0 +1,2575 @@
+#include
+
+#define FONTDATAMAX 2048
+
+static const unsigned char fontdata_6x8[FONTDATAMAX] = {
+
+ /* 0 0x00 '^@' */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 1 0x01 '^A' */
+ 0x78, /* 00 */
+ 0x84, /* 11 */
+ 0xCC, /* 110011 */
+ 0x84, /* 11 */
+ 0xCC, /* 110011 */
+ 0xB4, /* 101101 */
+ 0x78, /* 00 */
+ 0x00, /* 00 */
+
+ /* 2 0x02 '^B' */
+ 0x78, /* 00 */
+ 0xFC, /* 11 */
+ 0xB4, /* 101101 */
+ 0xFC, /* 11 */
+ 0xB4, /* 101101 */
+ 0xCC, /* 110011 */
+ 0x78, /* 00 */
+ 0x00, /* 00 */
+
+ /* 3 0x03 '^C' */
+ 0x00, /* 00 */
+ 0x28, /* 001010 */
+ 0x7C, /* 01 */
+ 0x7C, /* 01 */
+ 0x38, /* 001110 */
+ 0x10, /* 000100 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 4 0x04 '^D' */
+ 0x00, /* 00 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x7C, /* 01 */
+ 0x38, /* 001110 */
+ 0x10, /* 000100 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 5 0x05 '^E' */
+ 0x00, /* 00 */
+ 0x38, /* 001110 */
+ 0x38, /* 001110 */
+ 0x6C, /* 011011 */
+ 0x6C, /* 011011 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x00, /* 00 */
+
+ /* 6 0x06 '^F' */
+ 0x00, /* 00 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x7C, /* 01 */
+ 0x7C, /* 01 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x00, /* 00 */
+
+ /* 7 0x07 '^G' */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x30, /* 001100 */
+ 0x78, /* 00 */
+ 0x30, /* 001100 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 8 0x08 '^H' */
+ 0xFC, /* 11 */
+
Re: Packet gets stuck in NOLOCK pfifo_fast qdisc
Hi Josh,
On Fri, Jul 3, 2020 at 2:14 AM Josh Hunt wrote:
{snip}
> Initial results with Cong's patch look promising, so far no stalls. We
> will let it run over the long weekend and report back on Tuesday.
>
> Paolo - I have concerns about possible performance regression with the
> change as well. If you can gather some data that would be great. If
> things look good with our low throughput test over the weekend we can
> also try assessing performance next week.
>
We met possibly the same problem when testing nvidia/mellanox's
GPUDirect RDMA product, we found that changing NET_SCH_DEFAULT to
DEFAULT_FQ_CODEL mitigated the problem, having no idea why. Maybe you
can also have a try?
Besides, our testing is pretty complex, do you have a quick test to
reproduce it?
--
Thanks,
Jike
RE: [RFC PATCH 1/5] printk: implement pr_cont_t
From: Joe Perches > Sent: 20 August 2020 01:34 > > On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote: > > Implement a new buffering mechanism for pr_cont messages. > > > > Old mechanism syntax: > > > > printk(KERN_INFO "text"); > > printk(KERN_CONT " continued"); > > printk(KERN_CONT "\n"); > > > > New mechanism syntax: > > > > pr_cont_t c; > > > > pr_cont_begin(&c, KERN_INFO "text"); > > bikeshed: > > I suggest: > > printk_begin(&printk_context, fmt, ...) > printk_continue(&printk_context, fmt, ...) (maybe printk_next()) > printk_end(&printk_context, fmt, ...) I see some very long source lines looming ... Blue bikeshed: You'd probably want printk_end(&ctx, NULL) to work. Although the example doesn't show where the '\n' comes from. Although I guess it is now inferred and actually deleted from 'normal' printk() call. I've no idea how you'd 'size' the number of buffers. You could use kmalloc(), perhaps falling back on a local buffer. While might lead to: pr_init(&ctx, level, GFP_KERNEL); pr_cont(&ctx, fmt, ...); pr_flush(&ctx); David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v8 4/4] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster
On 8/12/2020 2:34 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 12.08.2020 10:19, Wesley Cheng wrote:
>
>> Add the required DTS node for the USB VBUS output regulator, which is
>> available on PM8150B. This will provide the VBUS source to connected
>> peripherals.
>>
>> Signed-off-by: Wesley Cheng
>> ---
>> arch/arm64/boot/dts/qcom/pm8150b.dtsi | 6 ++
>> arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> index 053c659734a7..9e560c1ca30d 100644
>> --- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
>> @@ -53,6 +53,12 @@ power-on@800 {
>> status = "disabled";
>> };
>> + pm8150b_vbus: dcdc@1100 {
>
> s/dcdc/regulator/? What is "dcdc", anyway?
> The device nodes must have the generic names, according to the DT spec.
>
Hi Sergei,
Thanks for the comment!
DCDC is the label that we use for the DC to DC converter block, since
the VBUS booster will output 5V to the connected devices. Would it make
more sense to have "dc-dc?"
Thanks
Wesley
>> + compatible = "qcom,pm8150b-vbus-reg";
>> + status = "disabled";
>> + reg = <0x1100>;
>> + };
>> +
>> pm8150b_typec: typec@1500 {
>> compatible = "qcom,pm8150b-usb-typec";
>> status = "disabled";
> [...]
>
> MBR, Sergei
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 00/49] DRM driver for Hikey 970
Em Wed, 19 Aug 2020 20:28:44 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 7:01 PM John Stultz wrote: > > > > On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote: > > > > > > > > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab > > > wrote: > > > > So, IMO, the best is to keep it on staging for a while, until those > > > > remaining bugs gets solved. > > > > > > > > I added this series, together with the regulator driver and > > > > a few other patches (including a hack to fix a Kernel 5.8 > > > > regression at WiFi ) at: > > > > > > > > > > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > > > > > > > > > Sorry, one more small request: Could you create a branch that only has > > > the DRM driver changes in it? > > > > > > The reason I ask, is that since the HiKey960 isn't affected by the > > > majority of the problems you listed as motivation for going through > > > staging. So if we can validate that your tree works fine on HiKey960, > > > the series can be cleaned up and submitted properly upstream to enable > > > that SoC, and the outstanding 970 issues can be worked out afterwards > > > against mainline. > > > > Just as a heads up, I tried testing your tree with my HiKey960, and > > after fixing the compat string inconsistency, the drivers seem to load > > properly. However the drm_hwcomposer seems to have some trouble with > > the driver: > > 01-01 00:12:41.456 345 345 E hwc-drm-display-compositor: Commit > > test failed for display 0, FIXME > > 01-01 00:12:41.456 345 345 E hwc-drm-two: Failed to apply the > > frame composition ret=-22 > > 01-01 00:12:41.456 351 351 E HWComposer: > > presentAndGetReleaseFences: present failed for display 0: BadParameter > > (4) > > > > I'll dig in a bit further as to why, but wanted to give you a heads up. > > Ok, I've mostly gotten it sorted out: > - You're missing a few color formats. > - And I re-discovered a crash that was already fixed in my tree. > > I'll send those patches in a few here. Thank you for the patches! I'll test them with Hikey 970 in order to be sure they're compatible also with such SoC. > > That said even with the patches I've got on top of your series, I > still see a few issues: > 1) I'm seeing red-blue swap with your driver. I need to dig a bit to > see what the difference is, I know gralloc has a config option for > this, and maybe the version of the driver I'm carrying has it wrong? There are some settings at adv7535 with regards to the colormap. The 4.9 fork of it has some different settings. Maybe it could be somehow related to it. I have here a Hikey 960, but didn't test it yet. > 2) Performance is noticeably worse. Whereas with my tree, I see close > to 60fps (that clk issue we mentioned earlier is why it's not exactly > 60) in most tests, but with yours it mostly hovers around 30some fps, > occasionally speeding up to 40 and then back down. That's weird, but it could be due to some settings related to CMA, IOMMU and/or AFBC. > Obviously with some work I suspect we'll be able to sort these out, > but I also do feel that the set you're starting with for upstreaming > is pretty old. The driver I'm carrying was heavily refactored around > 5.0 to share code with the existing kirin driver, in the hopes of > making usptreaming easier, and it seems a shame to throw that out and > focus your efforts on the older tree. > > But to be fair, I've not had time to upstream the driver myself, and > it's obviously your choice on how you spend your time. I am really > excited to see your efforts here, regardless of which driver you end > up pushing. On a quick look I've done, besides not having support for Hikey 970, the code on your tree seems to have less settings than the original one for Hikey 960. Yet, it should take some time to figure out what those extra settings are doing. Once I get this driver merged, and have USB support working fine[1], my plan is to compare the version from your tree, and compare with the one I have, in order to cleanup some stuff, check performance and do some other optimizations. - [1] this is a little OOT here: USB has been a challenge. Depending on the build, I'm getting an NMI interrupt error when the USB3 stack is loaded (usually at dwc3). The error is ESR_ELx_AET_UC. Unfortunately, it doesn't point to where this error is generated, making very hard to debug it. Thanks, Mauro
Re: [PATCH RESEND] lib/fonts: add font 6x8 for oled display
On Thu, Aug 20, 2020 at 09:42:14AM +0200, Sascha Hauer wrote:
> From: Sven Schneider
>
> This font is derived from lib/fonts/font_6x10.c and is useful for small OLED
> displays.
> ---
>
No signed-off-by: line? :(
Always use scripts/checkpatch.pl on your patch to find stuff like this,
and other errors that this patch has.
> Hi All,
>
> I am not sure any new fonts are desired in the kernel. If yes, please consider
> for inclusion, otherwise some "go away, there are enough fonts in the kernel
> already" would be nice as well so I can stop trying getting it in :)
>
> Sascha
>
> include/linux/font.h |4 +-
> lib/fonts/Kconfig|7 +
> lib/fonts/Makefile |1 +
> lib/fonts/font_6x8.c | 2575 ++
> lib/fonts/fonts.c|3 +
> 5 files changed, 2589 insertions(+), 1 deletion(-)
> mode change 100644 => 100755 include/linux/font.h
You changed a .h file to be executable???
> diff --git a/lib/fonts/fonts.c b/lib/fonts/fonts.c
> index e7258d8c252b2..760f2e6893bdb 100644
> --- a/lib/fonts/fonts.c
> +++ b/lib/fonts/fonts.c
> @@ -57,6 +57,9 @@ static const struct font_desc *fonts[] = {
> #ifdef CONFIG_FONT_TER16x32
> &font_ter_16x32,
> #endif
> +#ifdef CONFIG_FONT_6x8
> +&font_6x8,
Tabs please.
As for "do we take new fonts?", sure, why not?
thanks,
greg k-h
Re: Re: Re: [PATCH] video: backlight: sky81452-backlight: Fix reference count imbalance on error
On Thu, 20 Aug 2020, dinghao@zju.edu.cn wrote:
> > On Thu, 20 Aug 2020, dinghao@zju.edu.cn wrote:
> >
> > > > On Wed, 19 Aug 2020, Markus Elfring wrote:
> > > >
> > > > > > When of_property_read_u32_array() returns an error code,
> > > > > > a pairing refcount decrement is needed to keep np's refcount
> > > > > > balanced.
> > > > >
> > > > > Can another imperative wording be helpful for the change description?
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=18445bf405cb331117bc98427b1ba6f12418ad17#n151
> > > > >
> > > > > Would an other commit message be a bit nicer?
> > > > >
> > > > >
> > > > > …
> > > > > > +++ b/drivers/video/backlight/sky81452-backlight.c
> > > > > > @@ -217,6 +217,7 @@ static struct sky81452_bl_platform_data
> > > > > > *sky81452_bl_parse_dt(
> > > > > > num_entry);
> > > > > > if (ret < 0) {
> > > > > > dev_err(dev, "led-sources node is invalid.\n");
> > > > > > + of_node_put(np);
> > > > > > return ERR_PTR(-EINVAL);
> > > > > > }
> > > > >
> > > > > I propose to add the jump target “put_node” so that a bit of common
> > > > > exception
> > > > > handling code can be better reused at the end of this function
> > > > > implementation.
> > > > >
> > > > > Regards,
> > > > > Markus
> > > >
> > > > You can safely ignore any review comments from Markus!
> > > >
> > > > However, this patch doesn't appear to be in my inbox.
> > > >
> > > > Any ideas as to why?
> > > >
> > >
> > > Thank you for your advice. My outbox shows that this patch
> > > has reached your email server successfully. Maybe this
> > > ended up in your junk mail file?
> >
> > This has happened recently, so I was sure to check.
> >
> > Not there either unfortunately.
> >
> > Would you be kind enough to bounce/resend please?
>
> Sure.
Looks like you sent it *only* to me. Please keep everyone else in Cc
when doing that, or I can't respond to everyone.
Anyway, besides the subject line (which I can fix easily), the patch
looks good to me, but Daniel T must review.
Reviewed-by: Lee Jones
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH 3/9] cpuidle: Make CPUIDLE_FLAG_TLB_FLUSHED generic
This allows moving the leave_mm() call into generic code before
rcu_idle_enter(). Gets rid of more trace_*_rcuidle() users.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/mmu.h |1 +
arch/x86/mm/tlb.c | 13 ++---
drivers/cpuidle/cpuidle.c |4
drivers/idle/intel_idle.c | 16
include/linux/cpuidle.h | 13 +++--
include/linux/mmu_context.h |5 +
6 files changed, 19 insertions(+), 33 deletions(-)
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -59,5 +59,6 @@ typedef struct {
}
void leave_mm(int cpu);
+#define leave_mm leave_mm
#endif /* _ASM_X86_MMU_H */
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -555,21 +555,12 @@ void switch_mm_irqs_off(struct mm_struct
this_cpu_write(cpu_tlbstate.ctxs[new_asid].tlb_gen,
next_tlb_gen);
load_new_mm_cr3(next->pgd, new_asid, true);
- /*
-* NB: This gets called via leave_mm() in the idle path
-* where RCU functions differently. Tracing normally
-* uses RCU, so we need to use the _rcuidle variant.
-*
-* (There is no good reason for this. The idle code should
-* be rearranged to call this before rcu_idle_enter().)
-*/
- trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH,
TLB_FLUSH_ALL);
+ trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL);
} else {
/* The new ASID is already up to date. */
load_new_mm_cr3(next->pgd, new_asid, false);
- /* See above wrt _rcuidle. */
- trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, 0);
+ trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, 0);
}
/* Make sure we write CR3 before loaded_mm. */
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "cpuidle.h"
@@ -230,6 +231,9 @@ int cpuidle_enter_state(struct cpuidle_d
broadcast = false;
}
+ if (target_state->flags & CPUIDLE_FLAG_TLB_FLUSHED)
+ leave_mm(dev->cpu);
+
/* Take note of the planned idle state. */
sched_idle_set_state(target_state);
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -90,14 +90,6 @@ static unsigned int mwait_substates __in
#define CPUIDLE_FLAG_ALWAYS_ENABLE BIT(15)
/*
- * Set this flag for states where the HW flushes the TLB for us
- * and so we don't need cross-calls to keep it consistent.
- * If this flag is set, SW flushes the TLB, so even if the
- * HW doesn't do the flushing, this flag is safe to use.
- */
-#define CPUIDLE_FLAG_TLB_FLUSHED BIT(16)
-
-/*
* MWAIT takes an 8-bit "hint" in EAX "suggesting"
* the C-state (top nibble) and sub-state (bottom nibble)
* 0x00 means "MWAIT(C1)", 0x10 means "MWAIT(C2)" etc.
@@ -131,14 +123,6 @@ static __cpuidle int intel_idle(struct c
unsigned long eax = flg2MWAIT(state->flags);
unsigned long ecx = 1; /* break on interrupt flag */
bool tick;
- int cpu = smp_processor_id();
-
- /*
-* leave_mm() to avoid costly and often unnecessary wakeups
-* for flushing the user TLB's associated with the active mm.
-*/
- if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED)
- leave_mm(cpu);
if (!static_cpu_has(X86_FEATURE_ARAT)) {
/*
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -75,12 +75,13 @@ struct cpuidle_state {
};
/* Idle State Flags */
-#define CPUIDLE_FLAG_NONE (0x00)
-#define CPUIDLE_FLAG_POLLING BIT(0) /* polling state */
-#define CPUIDLE_FLAG_COUPLED BIT(1) /* state applies to multiple cpus */
-#define CPUIDLE_FLAG_TIMER_STOP BIT(2) /* timer is stopped on this state */
-#define CPUIDLE_FLAG_UNUSABLE BIT(3) /* avoid using this state */
-#define CPUIDLE_FLAG_OFF BIT(4) /* disable this state by default */
+#define CPUIDLE_FLAG_NONE (0x00)
+#define CPUIDLE_FLAG_POLLING BIT(0) /* polling state */
+#define CPUIDLE_FLAG_COUPLED BIT(1) /* state applies to multiple
cpus */
+#define CPUIDLE_FLAG_TIMER_STOPBIT(2) /* timer is stopped on this
state */
+#define CPUIDLE_FLAG_UNUSABLE BIT(3) /* avoid using this state */
+#define CPUIDLE_FLAG_OFF BIT(4) /* disable this state by default
*/
+#define CPUIDLE_FLAG_TLB_FLUSHED BIT(5) /* idle-state flushes TLBs */
struct cpuidle_device_kobj;
struct cpuidle_state_kobj;
--- a/include/linux/mmu_context.h
+++ b/include/linux/mmu_context.h
@@ -3,10 +3,15 @@
#define _LINUX_MMU_CONTEXT_H
#include
+#include
/* Architectures that care about IRQ state in switch_mm can override this. */
#ifndef switch_mm_irqs_off
# define switch_mm_irqs_off switch_mm
#endif
+#ifndef leave_mm
+static
[PATCH 2/9] sched,idle,rcu: Push rcu_idle deeper into the idle path
Lots of things take locks, due to a wee bug, rcu_lockdep didn't notice
that the locking tracepoints were using RCU.
Push rcu_idle_{enter,exit}() as deep as possible into the idle paths,
this also resolves a lot of _rcuidle()/RCU_NONIDLE() usage.
Specifically, sched_clock_idle_wakeup_event() will use ktime which
will use seqlocks which will tickle lockdep.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle.c| 15 +++
kernel/sched/idle.c | 18 ++
kernel/time/tick-broadcast-hrtimer.c | 29 -
3 files changed, 29 insertions(+), 33 deletions(-)
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -145,22 +145,27 @@ static void enter_s2idle_proper(struct c
* executing it contains RCU usage regarded as invalid in the idle
* context, so tell RCU about that.
*/
- RCU_NONIDLE(tick_freeze());
+ tick_freeze();
/*
* The state used here cannot be a "coupled" one, because the "coupled"
* cpuidle mechanism enables interrupts and doing that with timekeeping
* suspended is generally unsafe.
*/
+ rcu_idle_enter();
stop_critical_timings();
drv->states[index].enter_s2idle(dev, drv, index);
- WARN_ON(!irqs_disabled());
+ if (WARN_ON(!irqs_disabled()))
+ local_irq_disable();
/*
* timekeeping_resume() that will be called by tick_unfreeze() for the
* first CPU executing it calls functions containing RCU read-side
* critical sections, so tell RCU about that.
+*
+* FIXME, order against rcu_idle_exit ?
*/
RCU_NONIDLE(tick_unfreeze());
start_critical_timings();
+ rcu_idle_exit();
time_end = ns_to_ktime(local_clock());
@@ -228,16 +233,18 @@ int cpuidle_enter_state(struct cpuidle_d
/* Take note of the planned idle state. */
sched_idle_set_state(target_state);
- trace_cpu_idle_rcuidle(index, dev->cpu);
+ trace_cpu_idle(index, dev->cpu);
time_start = ns_to_ktime(local_clock());
+ rcu_idle_enter();
stop_critical_timings();
entered_state = target_state->enter(dev, drv, index);
start_critical_timings();
+ rcu_idle_exit();
sched_clock_idle_wakeup_event();
time_end = ns_to_ktime(local_clock());
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
+ trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
/* The cpu is no longer idle or about to enter idle. */
sched_idle_set_state(NULL);
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -54,17 +54,18 @@ __setup("hlt", cpu_idle_nopoll_setup);
static noinline int __cpuidle cpu_idle_poll(void)
{
+ trace_cpu_idle(0, smp_processor_id());
rcu_idle_enter();
- trace_cpu_idle_rcuidle(0, smp_processor_id());
local_irq_enable();
stop_critical_timings();
while (!tif_need_resched() &&
- (cpu_idle_force_poll || tick_check_broadcast_expired()))
+ (cpu_idle_force_poll || tick_check_broadcast_expired()))
cpu_relax();
+
start_critical_timings();
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
rcu_idle_exit();
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
return 1;
}
@@ -90,9 +91,11 @@ void __cpuidle default_idle_call(void)
if (current_clr_polling_and_test()) {
local_irq_enable();
} else {
+ rcu_idle_enter();
stop_critical_timings();
arch_cpu_idle();
start_critical_timings();
+ rcu_idle_exit();
}
}
@@ -158,7 +161,6 @@ static void cpuidle_idle_call(void)
if (cpuidle_not_available(drv, dev)) {
tick_nohz_idle_stop_tick();
- rcu_idle_enter();
default_idle_call();
goto exit_idle;
@@ -178,21 +180,17 @@ static void cpuidle_idle_call(void)
u64 max_latency_ns;
if (idle_should_enter_s2idle()) {
- rcu_idle_enter();
entered_state = call_cpuidle_s2idle(drv, dev);
if (entered_state > 0)
goto exit_idle;
- rcu_idle_exit();
-
max_latency_ns = U64_MAX;
} else {
max_latency_ns = dev->forced_idle_latency_limit_ns;
}
tick_nohz_idle_stop_tick();
- rcu_idle_enter();
next_state = cpuidle_find_deepest_state(drv, dev,
max_latency_ns);
call_cpuidle(drv, dev, next_state);
@@ -209,8 +207,6 @@ static void cpuidle_idle_call(void)
else
tick_nohz_idle_retain_tick();
- rcu_idle_enter();
-
[PATCH 7/9] nds32: Implement arch_irqs_disabled()
Cc: Nick Hu
Cc: Greentime Hu
Cc: Vincent Chen
Signed-off-by: Peter Zijlstra (Intel)
---
arch/nds32/include/asm/irqflags.h |5 +
1 file changed, 5 insertions(+)
--- a/arch/nds32/include/asm/irqflags.h
+++ b/arch/nds32/include/asm/irqflags.h
@@ -34,3 +34,8 @@ static inline int arch_irqs_disabled_fla
{
return !flags;
}
+
+static inline int arch_irqs_disabled(void)
+{
+ return arch_irqs_disabled_flags(arch_local_save_flags());
+}
[PATCH 0/9] TRACE_IRQFLAGS wreckage
TRACE_IRQFLAGS local_irq_*() keeps a software state that mirrors the hardware state, used for lockdep, includes tracepoints. raw_local_irq_*() does not update the software state, no tracing. --- Problem 1: raw_local_irq_save(); // software state on local_irq_save(); // software state off ... local_irq_restore(); // software state still off, because we don't enable IRQs raw_local_irq_restore(); // software state still off, *whoopsie* existing instances: - lock_acquire() raw_local_irq_save() __lock_acquire() arch_spin_lock(&graph_lock) pv_wait() := kvm_wait() (same or worse for Xen/HyperV) local_irq_save() - trace_clock_global() raw_local_irq_save() arch_spin_lock() pv_wait() := kvm_wait() local_irq_save() - apic_retrigger_irq() raw_local_irq_save() apic->send_IPI() := default_send_IPI_single_phys() local_irq_save() Possible solutions: A) make it work by enabling the tracing inside raw_*() B) make it work by keeping tracing disabled inside raw_*() C) call it broken and clean it up now Now, given that the only reason to use the raw_* variant is because you don't want tracing. Therefore A) seems like a weird option (although it can be done). C) is tempting, but OTOH it ends up converting a _lot_ of code to raw just because there is one raw user, this strips the validation/tracing off for all the other users. So we pick B) and declare any code that ends up doing: raw_local_irq_save() local_irq_save() lockdep_assert_irqs_disabled(); broken. AFAICT this problem has existed forever, the only reason it came up is because I changed IRQ tracing vs lockdep recursion and the first instance is fairly common, the other cases hardly ever happen. --- Problem 2: raw_local_irq_save(); // software state on trace_*() ... perf_tp_event() ... perf_callchain() <#PF> trace_hardirqs_off(); // software state off ... if (regs_irqs_disabled(regs)) // false trace_hardirqs_on(); raw_local_irq_restore(); // software state stays off, *whoopsie* existing instances: - lock_acquire() / lock_release() raw_local_irq_save() trace_lock_acquire() / trace_lock_release() - function tracing Possible solutions: A) fix every architecture's entry code B) only fix kernel/entry/common.c C) fix lockdep tracepoints and pray This series does C, AFAICT this problem has existed forever. --- Problem 3: raw_local_irq_save(); // software state on <#NMI> trace_hardirqs_off(); // software state off ... if (regs_irqs_disabled(regs)) // false trace_hardirqs_on(); raw_local_irq_restore(); // software state stays off, *whoopsie* Possible solutions: This *should* not be a problem if an architecture has it's entry ordering right. In particular we rely on the architecture doing nmi_enter() before trace_hardirqs_off(). In that case, in_nmi() will be true, and lockdep_hardirqs_*() should NO-OP, except if CONFIG_TRACE_IRQFLAGS_NMI (x86). There might be a problem with using lockdep_assert_irqs_disabled() from NMI context, if so, those needs a little TLC. --- The patches in this series do (in reverse order): - 2C - 1B - fix fallout in idle due to the trace_lock_*() tracepoints suddenly being visible to rcu-lockdep. --- arch/arm/mach-omap2/pm34xx.c |4 -- arch/arm64/kernel/process.c |2 - arch/nds32/include/asm/irqflags.h |5 ++ arch/powerpc/include/asm/hw_irq.h | 11 ++--- arch/s390/kernel/idle.c |3 - arch/x86/entry/thunk_32.S |5 -- arch/x86/include/asm/mmu.h|1 arch/x86/kernel/process.c |4 -- arch/x86/mm/tlb.c | 13 +- drivers/cpuidle/cpuidle.c | 19 +++-- drivers/idle/intel_idle.c | 16 include/linux/cpuidle.h | 13 +++--- include/linux/irqflags.h | 73 -- include/linux/lockdep.h | 18 ++--- include/linux/mmu_context.h |5 ++ kernel/locking/lockdep.c | 18 + kernel/sched/idle.c | 21 -- 17 files changed, 112 insertions(+), 119 deletions(-)
[PATCH 8/9] lockdep: Only trace IRQ edges
From: Nicholas Piggin
Problem:
raw_local_irq_save();
local_irq_save();
...
local_irq_restore();
raw_local_irq_restore();
existing instances:
- lock_acquire()
raw_local_irq_save()
__lock_acquire()
arch_spin_lock(&graph_lock)
pv_wait() := kvm_wait() (same or worse for Xen/HyperV)
local_irq_save()
- trace_clock_global()
raw_local_irq_save()
arch_spin_lock()
pv_wait() := kvm_wait()
local_irq_save()
- apic_retrigger_irq()
raw_local_irq_save()
apic->send_IPI() := default_send_IPI_single_phys()
local_irq_save()
Possible solutions:
A) make it work by enabling the tracing inside raw_*()
B) make it work by keeping tracing disabled inside raw_*()
C) call it broken and clean it up now
Now, given that the only reason to use the raw_* variant is because you don't
want tracing. Therefore A) seems like a weird option (although it can be done).
C) is tempting, but OTOH it ends up converting a _lot_ of code to raw just
because there is one raw user, this strips the validation/tracing off for all
the other users.
So we pick B) and declare any code that ends up doing:
raw_local_irq_save()
local_irq_save()
lockdep_assert_irqs_disabled();
broken. AFAICT this problem has existed forever, the only reason it came
up is because I changed IRQ tracing vs lockdep recursion and the first
instance is fairly common, the other cases hardly ever happen.
Signed-off-by: Nicholas Piggin
[rewrote changelog]
Signed-off-by: Peter Zijlstra (Intel)
---
arch/powerpc/include/asm/hw_irq.h | 11 ---
include/linux/irqflags.h | 15 +++
2 files changed, 11 insertions(+), 15 deletions(-)
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -200,17 +200,14 @@ static inline bool arch_irqs_disabled(vo
#define powerpc_local_irq_pmu_save(flags) \
do { \
raw_local_irq_pmu_save(flags); \
- trace_hardirqs_off(); \
+ if (!raw_irqs_disabled_flags(flags))\
+ trace_hardirqs_off(); \
} while(0)
#define powerpc_local_irq_pmu_restore(flags) \
do {\
- if (raw_irqs_disabled_flags(flags)) { \
- raw_local_irq_pmu_restore(flags); \
- trace_hardirqs_off(); \
- } else {\
+ if (!raw_irqs_disabled_flags(flags))\
trace_hardirqs_on();\
- raw_local_irq_pmu_restore(flags); \
- } \
+ raw_local_irq_pmu_restore(flags); \
} while(0)
#else
#define powerpc_local_irq_pmu_save(flags) \
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -191,25 +191,24 @@ do { \
#define local_irq_disable()\
do {\
+ bool was_disabled = raw_irqs_disabled();\
raw_local_irq_disable();\
- trace_hardirqs_off(); \
+ if (!was_disabled) \
+ trace_hardirqs_off(); \
} while (0)
#define local_irq_save(flags) \
do {\
raw_local_irq_save(flags); \
- trace_hardirqs_off(); \
+ if (!raw_irqs_disabled_flags(flags))\
+ trace_hardirqs_off(); \
} while (0)
#define local_irq_restore(flags) \
do {\
- if (raw_irqs_disabled_flags(flags)) { \
- raw_local_irq_restore(flags); \
- trace_hardirqs_off(); \
- } else {\
+ if (!raw_irqs_disabled_flags(flags))\
trace_hardirqs_on();\
- raw_local_irq_restore(flags); \
- } \
+ raw_local_irq_restore(flags); \
} while (0)
#define safe_halt()\
[PATCH 5/9] x86/entry: Remove unused THUNKs
Unused remnants Signed-off-by: Peter Zijlstra (Intel) --- --- a/arch/x86/entry/thunk_32.S +++ b/arch/x86/entry/thunk_32.S @@ -29,11 +29,6 @@ SYM_CODE_START_NOALIGN(\name) SYM_CODE_END(\name) .endm -#ifdef CONFIG_TRACE_IRQFLAGS - THUNK trace_hardirqs_on_thunk,trace_hardirqs_on_caller,1 - THUNK trace_hardirqs_off_thunk,trace_hardirqs_off_caller,1 -#endif - #ifdef CONFIG_PREEMPTION THUNK preempt_schedule_thunk, preempt_schedule THUNK preempt_schedule_notrace_thunk, preempt_schedule_notrace
[PATCH 1/9] lockdep: Use raw_cpu_*() for per-cpu variables
Sven reported that commit a21ee6055c30 ("lockdep: Change
hardirq{s_enabled,_context} to per-cpu variables") caused trouble on
s390 because their this_cpu_*() primitives disable preemption which
then lands back tracing.
On the one hand, per-cpu ops should use preempt_*able_notrace() and
raw_local_irq_*(), on the other hand, we can trivialy use raw_cpu_*()
ops for this.
Fixes: a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu
variables")
Reported-by: Sven Schnelle
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/irqflags.h |6 +++---
include/linux/lockdep.h | 18 +-
kernel/locking/lockdep.c |4 ++--
3 files changed, 18 insertions(+), 10 deletions(-)
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -53,13 +53,13 @@ DECLARE_PER_CPU(int, hardirq_context);
extern void trace_hardirqs_off_finish(void);
extern void trace_hardirqs_on(void);
extern void trace_hardirqs_off(void);
-# define lockdep_hardirq_context() (this_cpu_read(hardirq_context))
+# define lockdep_hardirq_context() (raw_cpu_read(hardirq_context))
# define lockdep_softirq_context(p)((p)->softirq_context)
# define lockdep_hardirqs_enabled()(this_cpu_read(hardirqs_enabled))
# define lockdep_softirqs_enabled(p) ((p)->softirqs_enabled)
# define lockdep_hardirq_enter() \
do { \
- if (this_cpu_inc_return(hardirq_context) == 1) \
+ if (__this_cpu_inc_return(hardirq_context) == 1)\
current->hardirq_threaded = 0; \
} while (0)
# define lockdep_hardirq_threaded()\
@@ -68,7 +68,7 @@ do { \
} while (0)
# define lockdep_hardirq_exit()\
do { \
- this_cpu_dec(hardirq_context); \
+ __this_cpu_dec(hardirq_context);\
} while (0)
# define lockdep_softirq_enter() \
do { \
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -535,19 +535,27 @@ do {
\
DECLARE_PER_CPU(int, hardirqs_enabled);
DECLARE_PER_CPU(int, hardirq_context);
+/*
+ * The below lockdep_assert_*() macros se raw_cpu_read() to access the above
+ * per-cpu variables. This is required because this_cpu_read() will potentially
+ * call into preempt/irq-disable and that obviously isn't right. This is also
+ * correct because when IRQs are enabled, it doesn't matter if we accidentally
+ * read the value from our previous CPU.
+ */
+
#define lockdep_assert_irqs_enabled() \
do { \
- WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled)); \
+ WARN_ON_ONCE(debug_locks && !raw_cpu_read(hardirqs_enabled)); \
} while (0)
#define lockdep_assert_irqs_disabled() \
do { \
- WARN_ON_ONCE(debug_locks && this_cpu_read(hardirqs_enabled)); \
+ WARN_ON_ONCE(debug_locks && raw_cpu_read(hardirqs_enabled));\
} while (0)
#define lockdep_assert_in_irq()
\
do { \
- WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirq_context)); \
+ WARN_ON_ONCE(debug_locks && !raw_cpu_read(hardirq_context));\
} while (0)
#define lockdep_assert_preemption_enabled()\
@@ -555,7 +563,7 @@ do {
\
WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
debug_locks&& \
(preempt_count() != 0 || \
- !this_cpu_read(hardirqs_enabled))); \
+ !raw_cpu_read(hardirqs_enabled)));\
} while (0)
#define lockdep_assert_preemption_disabled() \
@@ -563,7 +571,7 @@ do {
\
WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
debug_locks&& \
(preempt_count() == 0 && \
- this_cpu_read(hardirqs_enabled)));\
+ raw_cpu_read(hardirqs_enabled))); \
} while (0)
#else
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3756,7 +3756,7 @@ void noinstr lockdep_hardirqs_on(unsigne
skip_checks:
/* we'll do an OFF -> ON transition: */
- this_cpu_write(hardirqs_enabled, 1);
+ __this_cpu_wr
[PATCH 9/9] lockdep,trace: Expose tracepoints
The lockdep tracepoints are under the lockdep recursion counter, this
has a bunch of nasty side effects:
- TRACE_IRQFLAGS doesn't work across the entire tracepoint
- RCU-lockdep doesn't see the tracepoints either, hiding numerous
"suspicious RCU usage" warnings.
Pull the trace_lock_*() tracepoints completely out from under the
lockdep recursion handling and completely rely on the trace level
recusion handling -- also, tracing *SHOULD* not be taking locks in any
case.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/locking/lockdep.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -5044,6 +5044,8 @@ void lock_acquire(struct lockdep_map *lo
{
unsigned long flags;
+ trace_lock_acquire(lock, subclass, trylock, read, check, nest_lock, ip);
+
if (unlikely(current->lockdep_recursion)) {
/* XXX allow trylock from NMI ?!? */
if (lockdep_nmi() && !trylock) {
@@ -5068,7 +5070,6 @@ void lock_acquire(struct lockdep_map *lo
check_flags(flags);
current->lockdep_recursion++;
- trace_lock_acquire(lock, subclass, trylock, read, check, nest_lock, ip);
__lock_acquire(lock, subclass, trylock, read, check,
irqs_disabled_flags(flags), nest_lock, ip, 0, 0);
lockdep_recursion_finish();
@@ -5080,13 +5081,15 @@ void lock_release(struct lockdep_map *lo
{
unsigned long flags;
+ trace_lock_release(lock, ip);
+
if (unlikely(current->lockdep_recursion))
return;
raw_local_irq_save(flags);
check_flags(flags);
+
current->lockdep_recursion++;
- trace_lock_release(lock, ip);
if (__lock_release(lock, ip))
check_chain_key(current);
lockdep_recursion_finish();
@@ -5272,8 +5275,6 @@ __lock_acquired(struct lockdep_map *lock
hlock->holdtime_stamp = now;
}
- trace_lock_acquired(lock, ip);
-
stats = get_lock_stats(hlock_class(hlock));
if (waittime) {
if (hlock->read)
@@ -5292,6 +5293,8 @@ void lock_contended(struct lockdep_map *
{
unsigned long flags;
+ trace_lock_contended(lock, ip);
+
if (unlikely(!lock_stat || !debug_locks))
return;
@@ -5301,7 +5304,6 @@ void lock_contended(struct lockdep_map *
raw_local_irq_save(flags);
check_flags(flags);
current->lockdep_recursion++;
- trace_lock_contended(lock, ip);
__lock_contended(lock, ip);
lockdep_recursion_finish();
raw_local_irq_restore(flags);
@@ -5312,6 +5314,8 @@ void lock_acquired(struct lockdep_map *l
{
unsigned long flags;
+ trace_lock_acquired(lock, ip);
+
if (unlikely(!lock_stat || !debug_locks))
return;
[PATCH 4/9] cpuidle: Move trace_cpu_idle() into generic code
Remove trace_cpu_idle() from the arch_cpu_idle() implementations and
put it in the generic code, right before disabling RCU. Gets rid of
more trace_*_rcuidle() users.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/pm34xx.c |4
arch/arm64/kernel/process.c |2 --
arch/s390/kernel/idle.c |3 +--
arch/x86/kernel/process.c|4
kernel/sched/idle.c |3 +++
5 files changed, 4 insertions(+), 12 deletions(-)
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -298,11 +298,7 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
return;
- trace_cpu_idle_rcuidle(1, smp_processor_id());
-
omap_sram_idle();
-
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
}
#ifdef CONFIG_SUSPEND
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -123,10 +123,8 @@ void arch_cpu_idle(void)
* This should do all the clock switching and wait for interrupt
* tricks
*/
- trace_cpu_idle_rcuidle(1, smp_processor_id());
cpu_do_idle();
local_irq_enable();
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
}
#ifdef CONFIG_HOTPLUG_CPU
--- a/arch/s390/kernel/idle.c
+++ b/arch/s390/kernel/idle.c
@@ -33,14 +33,13 @@ void enabled_wait(void)
PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK;
clear_cpu_flag(CIF_NOHZ_DELAY);
- trace_cpu_idle_rcuidle(1, smp_processor_id());
local_irq_save(flags);
/* Call the assembler magic in entry.S */
psw_idle(idle, psw_mask);
local_irq_restore(flags);
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
/* Account time spent with enabled wait psw loaded as idle time. */
+ /* XXX seqcount has tracepoints that require RCU */
write_seqcount_begin(&idle->seqcount);
idle_time = idle->clock_idle_exit - idle->clock_idle_enter;
idle->clock_idle_enter = idle->clock_idle_exit = 0ULL;
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -684,9 +684,7 @@ void arch_cpu_idle(void)
*/
void __cpuidle default_idle(void)
{
- trace_cpu_idle_rcuidle(1, smp_processor_id());
safe_halt();
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
}
#if defined(CONFIG_APM_MODULE) || defined(CONFIG_HALTPOLL_CPUIDLE_MODULE)
EXPORT_SYMBOL(default_idle);
@@ -792,7 +790,6 @@ static int prefer_mwait_c1_over_halt(con
static __cpuidle void mwait_idle(void)
{
if (!current_set_polling_and_test()) {
- trace_cpu_idle_rcuidle(1, smp_processor_id());
if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) {
mb(); /* quirk */
clflush((void *)¤t_thread_info()->flags);
@@ -804,7 +801,6 @@ static __cpuidle void mwait_idle(void)
__sti_mwait(0, 0);
else
local_irq_enable();
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
} else {
local_irq_enable();
}
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -91,11 +91,14 @@ void __cpuidle default_idle_call(void)
if (current_clr_polling_and_test()) {
local_irq_enable();
} else {
+
+ trace_cpu_idle(1, smp_processor_id());
rcu_idle_enter();
stop_critical_timings();
arch_cpu_idle();
start_critical_timings();
rcu_idle_exit();
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
}
[PATCH 6/9] locking/lockdep: Cleanup
Signed-off-by: Peter Zijlstra (Intel)
---
---
include/linux/irqflags.h | 54 ++-
1 file changed, 30 insertions(+), 24 deletions(-)
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -49,10 +49,11 @@ struct irqtrace_events {
DECLARE_PER_CPU(int, hardirqs_enabled);
DECLARE_PER_CPU(int, hardirq_context);
- extern void trace_hardirqs_on_prepare(void);
- extern void trace_hardirqs_off_finish(void);
- extern void trace_hardirqs_on(void);
- extern void trace_hardirqs_off(void);
+extern void trace_hardirqs_on_prepare(void);
+extern void trace_hardirqs_off_finish(void);
+extern void trace_hardirqs_on(void);
+extern void trace_hardirqs_off(void);
+
# define lockdep_hardirq_context() (raw_cpu_read(hardirq_context))
# define lockdep_softirq_context(p)((p)->softirq_context)
# define lockdep_hardirqs_enabled()(this_cpu_read(hardirqs_enabled))
@@ -120,17 +121,17 @@ do { \
#else
# define trace_hardirqs_on_prepare() do { } while (0)
# define trace_hardirqs_off_finish() do { } while (0)
-# define trace_hardirqs_on() do { } while (0)
-# define trace_hardirqs_off() do { } while (0)
-# define lockdep_hardirq_context() 0
-# define lockdep_softirq_context(p)0
-# define lockdep_hardirqs_enabled()0
-# define lockdep_softirqs_enabled(p) 0
-# define lockdep_hardirq_enter() do { } while (0)
-# define lockdep_hardirq_threaded()do { } while (0)
-# define lockdep_hardirq_exit()do { } while (0)
-# define lockdep_softirq_enter() do { } while (0)
-# define lockdep_softirq_exit()do { } while (0)
+# define trace_hardirqs_on() do { } while (0)
+# define trace_hardirqs_off() do { } while (0)
+# define lockdep_hardirq_context() 0
+# define lockdep_softirq_context(p)0
+# define lockdep_hardirqs_enabled()0
+# define lockdep_softirqs_enabled(p) 0
+# define lockdep_hardirq_enter() do { } while (0)
+# define lockdep_hardirq_threaded()do { } while (0)
+# define lockdep_hardirq_exit()do { } while (0)
+# define lockdep_softirq_enter() do { } while (0)
+# define lockdep_softirq_exit()do { } while (0)
# define lockdep_hrtimer_enter(__hrtimer) false
# define lockdep_hrtimer_exit(__context) do { } while (0)
# define lockdep_posixtimer_enter()do { } while (0)
@@ -181,17 +182,25 @@ do { \
* if !TRACE_IRQFLAGS.
*/
#ifdef CONFIG_TRACE_IRQFLAGS
-#define local_irq_enable() \
- do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0)
-#define local_irq_disable() \
- do { raw_local_irq_disable(); trace_hardirqs_off(); } while (0)
+
+#define local_irq_enable() \
+ do {\
+ trace_hardirqs_on();\
+ raw_local_irq_enable(); \
+ } while (0)
+
+#define local_irq_disable()\
+ do {\
+ raw_local_irq_disable();\
+ trace_hardirqs_off(); \
+ } while (0)
+
#define local_irq_save(flags) \
do {\
raw_local_irq_save(flags); \
trace_hardirqs_off(); \
} while (0)
-
#define local_irq_restore(flags) \
do {\
if (raw_irqs_disabled_flags(flags)) { \
@@ -214,10 +223,7 @@ do { \
#define local_irq_enable() do { raw_local_irq_enable(); } while (0)
#define local_irq_disable()do { raw_local_irq_disable(); } while (0)
-#define local_irq_save(flags) \
- do {\
- raw_local_irq_save(flags); \
- } while (0)
+#define local_irq_save(flags) do { raw_local_irq_save(flags); } while (0)
#define local_irq_restore(flags) do { raw_local_irq_restore(flags); } while (0)
#define safe_halt()do { raw_safe_halt(); } while (0)
[PATCH] binder: print warnings when detecting oneway spamming.
The most common cause of the binder transaction buffer filling up is a
client rapidly firing oneway transactions into a process, before it has
a chance to handle them. Yet the root cause of this is often hard to
debug, because either the system or the app will stop, and by that time
binder debug information we dump in bugreports is no longer relevant.
This change warns as soon as a process dips below 80% of its oneway
space (less than 100kB available in the configuration), when any one
process is responsible for either more than 50 transactions, or more
than 50% of the oneway space.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 2 +-
drivers/android/binder_alloc.c | 49 +++---
drivers/android/binder_alloc.h | 5 +++-
3 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index f936530a19b0..946332bc871a 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3136,7 +3136,7 @@ static void binder_transaction(struct binder_proc *proc,
t->buffer = binder_alloc_new_buf(&target_proc->alloc, tr->data_size,
tr->offsets_size, extra_buffers_size,
- !reply && (t->flags & TF_ONE_WAY));
+ !reply && (t->flags & TF_ONE_WAY), current->tgid);
if (IS_ERR(t->buffer)) {
/*
* -ESRCH indicates VMA cleared. The target is dying.
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 69609696a843..76e8e633dbd4 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -338,12 +338,48 @@ static inline struct vm_area_struct *binder_alloc_get_vma(
return vma;
}
+static void debug_low_async_space_locked(struct binder_alloc *alloc, int pid)
+{
+ /*
+* Find the amount and size of buffers allocated by the current caller;
+* The idea is that once we cross the threshold, whoever is responsible
+* for the low async space is likely to try to send another async txn,
+* and at some point we'll catch them in the act. This is more efficient
+* than keeping a map per pid.
+*/
+ struct rb_node *n = alloc->free_buffers.rb_node;
+ struct binder_buffer *buffer;
+ size_t buffer_size;
+ size_t total_alloc_size = 0;
+ size_t num_buffers = 0;
+
+ for (n = rb_first(&alloc->allocated_buffers); n != NULL;
+n = rb_next(n)) {
+ buffer = rb_entry(n, struct binder_buffer, rb_node);
+ if (buffer->pid != pid)
+ continue;
+ if (!buffer->async_transaction)
+ continue;
+ buffer_size = binder_alloc_buffer_size(alloc, buffer);
+ total_alloc_size += buffer_size;
+ num_buffers++;
+ }
+
+ // Warn if this pid has more than 50% of async space, or more than 50
txns
+ if (num_buffers > 50 || total_alloc_size > alloc->buffer_size / 4) {
+ binder_alloc_debug(BINDER_DEBUG_USER_ERROR,
+"%d: pid %d spamming oneway? %zd buffers allocated
for a total size of %zd\n",
+ alloc->pid, pid, num_buffers, total_alloc_size);
+ }
+}
+
static struct binder_buffer *binder_alloc_new_buf_locked(
struct binder_alloc *alloc,
size_t data_size,
size_t offsets_size,
size_t extra_buffers_size,
- int is_async)
+ int is_async,
+ int pid)
{
struct rb_node *n = alloc->free_buffers.rb_node;
struct binder_buffer *buffer;
@@ -486,11 +522,16 @@ static struct binder_buffer *binder_alloc_new_buf_locked(
buffer->offsets_size = offsets_size;
buffer->async_transaction = is_async;
buffer->extra_buffers_size = extra_buffers_size;
+ buffer->pid = pid;
if (is_async) {
alloc->free_async_space -= size + sizeof(struct binder_buffer);
binder_alloc_debug(BINDER_DEBUG_BUFFER_ALLOC_ASYNC,
"%d: binder_alloc_buf size %zd async free %zd\n",
alloc->pid, size, alloc->free_async_space);
+ if (alloc->free_async_space < alloc->buffer_size / 10) {
+ // Start detecting spammers once we reach 80% of async
space used
+ debug_low_async_space_locked(alloc, pid);
+ }
}
return buffer;
@@ -508,6 +549,7 @@ static struct binder_buffer *binder_alloc_new_buf_locked(
* @offsets_size: user specified buffer offset
* @extra_buffers_size: size of extra space for meta-data (eg, security
context)
* @is_async: buffer for async transaction
+ * @pid:
[PATCH 03/12] regulator: fan53555: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/fan53555.c:439:34: warning: ‘fan53555_dt_ids’ defined but not
used [-Wunused-const-variable=]
439 | static const struct of_device_id fan53555_dt_ids[] = {
| ^~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/fan53555.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/fan53555.c b/drivers/regulator/fan53555.c
index 00c83492f774..387c53f387ba 100644
--- a/drivers/regulator/fan53555.c
+++ b/drivers/regulator/fan53555.c
@@ -436,6 +436,7 @@ static struct fan53555_platform_data
*fan53555_parse_dt(struct device *dev,
return pdata;
}
+#ifdef CONFIG_OF
static const struct of_device_id fan53555_dt_ids[] = {
{
.compatible = "fcs,fan53526",
@@ -453,6 +454,7 @@ static const struct of_device_id fan53555_dt_ids[] = {
{ }
};
MODULE_DEVICE_TABLE(of, fan53555_dt_ids);
+#endif
static int fan53555_regulator_probe(struct i2c_client *client,
const struct i2c_device_id *id)
--
2.28.0
[PATCH 06/12] regulator: ltc3676: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3676.c:371:34: warning: ‘ltc3676_of_match’ defined but not
used [-Wunused-const-variable=]
371 | static const struct of_device_id ltc3676_of_match[] = {
| ^~~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/ltc3676.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/ltc3676.c b/drivers/regulator/ltc3676.c
index 093b3e4a6303..0778d5bb7559 100644
--- a/drivers/regulator/ltc3676.c
+++ b/drivers/regulator/ltc3676.c
@@ -368,11 +368,13 @@ static const struct i2c_device_id ltc3676_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ltc3676_i2c_id);
+#ifdef CONFIG_OF
static const struct of_device_id ltc3676_of_match[] = {
{ .compatible = "lltc,ltc3676" },
{ },
};
MODULE_DEVICE_TABLE(of, ltc3676_of_match);
+#endif
static struct i2c_driver ltc3676_driver = {
.driver = {
--
2.28.0
[PATCH 09/12] regulator: pwm: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/pwm-regulator.c:393:34: warning: ‘pwm_of_match’ defined but
not used [-Wunused-const-variable=]
393 | static const struct of_device_id pwm_of_match[] = {
| ^~~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/pwm-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index 3234b118b53e..c00829bd5d7b 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -390,11 +390,13 @@ static int pwm_regulator_probe(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
static const struct of_device_id pwm_of_match[] = {
{ .compatible = "pwm-regulator" },
{ },
};
MODULE_DEVICE_TABLE(of, pwm_of_match);
+#endif
static struct platform_driver pwm_regulator_driver = {
.driver = {
--
2.28.0
[PATCH][next] staging: spmi: hisi-spmi-controller: fix spelling mistake "controlller" -> "controller"
From: Colin Ian King
There is a spelling mistake in the MODULE_ALIAS, fix it.
Signed-off-by: Colin Ian King
---
drivers/staging/hikey9xx/hisi-spmi-controller.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c
b/drivers/staging/hikey9xx/hisi-spmi-controller.c
index 66a0b296e06f..b132b2a5d939 100644
--- a/drivers/staging/hikey9xx/hisi-spmi-controller.c
+++ b/drivers/staging/hikey9xx/hisi-spmi-controller.c
@@ -354,4 +354,4 @@ module_exit(spmi_controller_exit);
MODULE_LICENSE("GPL v2");
MODULE_VERSION("1.0");
-MODULE_ALIAS("platform:spmi_controlller");
+MODULE_ALIAS("platform:spmi_controller");
--
2.27.0
[PATCH 05/12] regulator: ltc3589: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3589.c:460:34: warning: ‘ltc3589_of_match’ defined but not
used [-Wunused-const-variable=]
460 | static const struct of_device_id ltc3589_of_match[] = {
| ^~~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/ltc3589.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/ltc3589.c b/drivers/regulator/ltc3589.c
index 9a037fdc5fc5..c73010bb3b41 100644
--- a/drivers/regulator/ltc3589.c
+++ b/drivers/regulator/ltc3589.c
@@ -457,6 +457,7 @@ static const struct i2c_device_id ltc3589_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ltc3589_i2c_id);
+#ifdef CONFIG_OF
static const struct of_device_id ltc3589_of_match[] = {
{
.compatible = "lltc,ltc3589",
@@ -473,6 +474,7 @@ static const struct of_device_id ltc3589_of_match[] = {
{ },
};
MODULE_DEVICE_TABLE(of, ltc3589_of_match);
+#endif
static struct i2c_driver ltc3589_driver = {
.driver = {
--
2.28.0
[PATCH 08/12] regulator: max77826: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/max77826-regulator.c:277:34: warning: ‘max77826_of_match’
defined but not used [-Wunused-const-variable=]
277 | static const struct of_device_id max77826_of_match[] = {
| ^
Signed-off-by: Jisheng Zhang
---
drivers/regulator/max77826-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/max77826-regulator.c
b/drivers/regulator/max77826-regulator.c
index 502ab6afc814..7fbdcd7118a8 100644
--- a/drivers/regulator/max77826-regulator.c
+++ b/drivers/regulator/max77826-regulator.c
@@ -274,11 +274,13 @@ static int max77826_i2c_probe(struct i2c_client *client)
return max77826_read_device_id(regmap, dev);
}
+#ifdef CONFIG_OF
static const struct of_device_id max77826_of_match[] = {
{ .compatible = "maxim,max77826" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, max77826_of_match);
+#endif
static const struct i2c_device_id max77826_id[] = {
{ "max77826-regulator" },
--
2.28.0
Re: [PATCH] MAINTAINERS: Add entries for CoreSight and Arm SPE
On 19/08/2020 20:26, Mathieu Poirier wrote: On Wed, 19 Aug 2020 at 11:30, Will Deacon wrote: On Wed, Aug 19, 2020 at 11:01:38AM -0600, Mathieu Poirier wrote: On Tue, 18 Aug 2020 at 11:56, John Garry wrote: On 17/08/2020 20:31, Mathieu Poirier wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 4e2698cc7e23..f9bb76baeec9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13427,8 +13427,18 @@ F: tools/perf/ PERFORMANCE EVENTS SUBSYSTEM ARM64 PMU EVENTS Maybe "PERFORMANCE EVENTS SUBSYSTEM ARM64" would be more appropriate now. R: John Garry R: Will Deacon +R: Mathieu Poirier +R: Leo Yan L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported +F: tools/build/feature/test-libopencsd.c +F: tools/perf/arch/arm/util/auxtrace.c +F: tools/perf/arch/arm/util/cs-etm.* +F: tools/perf/arch/arm/util/pmu.c +F: tools/perf/arch/arm64/util/arm-spe.c +F: tools/perf/util/arm-spe.h +F: tools/perf/util/cs-etm-decoder/* +F: tools/perf/util/cs-etm.* But from the previous discussion, I thought that we wanted an entry to cover all tools/perf/arch/arm64/ and other related folders. Or was it just put all special interest parts (like SPE support) under one entry and leave the other arm/arm64 parts to be caught by "PERFORMANCE EVENTS SUBSYSTEM" entry? I do not have the time to maintain anything outside of coresight - listing individual files as I did removes any ambiguity on that front. I'm happy to add tools/perf/arch/arm and tools/perf/arch/arm64/ if you agree to maintain them. In that case you will have to be more specific about the "other related folders" you are referring to above. As Leo mentioned, I was thinking of tools/perf/util/arm-spe-decoder/ None of us have time for this, hence why I think putting us all in one entry with all of the files listed there makes the most sense; then people do whatever they can and try to help each other out based on how much time they have. I think that's much better than fine-grained maintainership where a given file has a single point of failure. Thanks for the clarification - just wanted to make sure I don't sign you guys up for something you didn't agree to. And it's "R:" level, so none of the commitment associated with "M:". In addition - and maybe most important - the linux-arm-kernel list will (or should) be cc'ed. So I think it should include: tools/perf/arch/arm64/ tools/pmu-events/arch/arm64/ along with the SPE and Coresight files. Arnaldo would still handle the patches, so this is really about giving us a chance to review incoming patches without having to fish them out from the lists. Will . Cheers, John
[PATCH v2] drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
In `amdgpu_dm_update_backlight_caps()`, there is a local `amdgpu_dm_backlight_caps` object that is filled in by `amdgpu_acpi_get_backlight_caps()`. However, this object is uninitialized before the call and hence the subsequent check for aux_support can fail since it is not initialized by `amdgpu_acpi_get_backlight_caps()` as well. This change initializes this local `amdgpu_dm_backlight_caps` object to 0. Signed-off-by: Furquan Shaikh --- v2: Switched to using memset for initialization of object. drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e4b33c67b634..da072998ce48 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2855,6 +2855,8 @@ static void amdgpu_dm_update_backlight_caps(struct amdgpu_display_manager *dm) #if defined(CONFIG_ACPI) struct amdgpu_dm_backlight_caps caps; + memset(&caps, 0, sizeof(caps)); + if (dm->backlight_caps.caps_valid) return; -- 2.28.0.297.g1956fa8f8d-goog
[PATCH 02/12] regulator: da9210: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/da9210-regulator.c:128:34: warning: ‘da9210_dt_ids’ defined
but not used [-Wunused-const-variable=]
128 | static const struct of_device_id da9210_dt_ids[] = {
| ^
Signed-off-by: Jisheng Zhang
---
drivers/regulator/da9210-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/da9210-regulator.c
b/drivers/regulator/da9210-regulator.c
index 0cdeb6186529..219baed89ba5 100644
--- a/drivers/regulator/da9210-regulator.c
+++ b/drivers/regulator/da9210-regulator.c
@@ -125,11 +125,13 @@ static irqreturn_t da9210_irq_handler(int irq, void *data)
* I2C driver interface functions
*/
+#ifdef CONFIG_OF
static const struct of_device_id da9210_dt_ids[] = {
{ .compatible = "dlg,da9210", },
{ }
};
MODULE_DEVICE_TABLE(of, da9210_dt_ids);
+#endif
static int da9210_i2c_probe(struct i2c_client *i2c)
{
--
2.28.0
[PATCH 00/12] regulator: Fix W=1 build warning when CONFIG_OF=n
Fixing W=1 build warning when no support for device tree is there. Jisheng Zhang (12): regulator: 88pg86x: Fix W=1 build warning when CONFIG_OF=n regulator: da9210: Fix W=1 build warning when CONFIG_OF=n regulator: fan53555: Fix W=1 build warning when CONFIG_OF=n regulator: fixed: Fix W=1 build warnings when CONFIG_OF=n regulator: ltc3589: Fix W=1 build warning when CONFIG_OF=n regulator: ltc3676: Fix W=1 build warning when CONFIG_OF=n regulator: max1586: Fix W=1 build warning when CONFIG_OF=n regulator: max77826: Fix W=1 build warning when CONFIG_OF=n regulator: pwm: Fix W=1 build warning when CONFIG_OF=n regulator: stm32-pwr: Fix W=1 build warning when CONFIG_OF=n regulator: stm32-vrefbuf: Fix W=1 build warning when CONFIG_OF=n regulator: sy8106a: Fix W=1 build warning when CONFIG_OF=n drivers/regulator/88pg86x.c| 2 ++ drivers/regulator/da9210-regulator.c | 2 ++ drivers/regulator/fan53555.c | 2 ++ drivers/regulator/fixed.c | 16 drivers/regulator/ltc3589.c| 2 ++ drivers/regulator/ltc3676.c| 2 ++ drivers/regulator/max1586.c| 2 ++ drivers/regulator/max77826-regulator.c | 2 ++ drivers/regulator/pwm-regulator.c | 2 ++ drivers/regulator/stm32-pwr.c | 2 ++ drivers/regulator/stm32-vrefbuf.c | 2 ++ drivers/regulator/sy8106a-regulator.c | 2 ++ 12 files changed, 30 insertions(+), 8 deletions(-) -- 2.28.0
[PATCH v3 0/2] regulator: mt6360: Add support for MT6360 regulator
This patch series add MT6360 regulator support contains driver and binding document Gene Chen (2) regulator: mt6360: Add support for MT6360 regulator regulator: mt6360: Add DT binding documentation Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml | 109 ++ drivers/regulator/Kconfig |9 drivers/regulator/Makefile|1 drivers/regulator/mt6360-regulator.c | 458 ++ include/dt-bindings/regulator/mediatek,mt6360-regulator.h | 16 5 files changed, 593 insertions(+) changelogs between v1 & v2 - regulator: merge regmap to mfd driver for r/w with crc changelogs between v2 & v3 - Move regmap define to MFD parent driver - Add bindings document
[PATCH v3 2/2] regulator: mt6360: Add DT binding documentation
From: Gene Chen
Add a devicetree binding documentation for the mt6360 regulator driver.
Signed-off-by: Gene Chen
---
.../bindings/regulator/mt6360-regulator.yaml | 109 +
1 file changed, 109 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
new file mode 100644
index 000..bd66754
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mt6360-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT6360 Regulator from MediaTek Integrated
+
+maintainers:
+ - Gene Chen
+
+description: |
+ list of regulators provided by this controller, must be named
+ after their hardware counterparts buck1/2 or ldo1/2/3/5/6/7
+
+properties:
+ compatible:
+const: mediatek,mt6360-regulator
+
+ LDO_VIN3-supply:
+description: Input supply phandle(s) for LDO3
+
+patternProperties:
+ "^buck[12]$":
+$ref: "regulator.yaml#"
+
+ "^ldo[123567]$":
+$ref: "regulator.yaml#"
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+regulator {
+ compatible = "mediatek,mt6360-regulator";
+ LDO_VIN3-supply = <&BUCK2>;
+ buck1 {
+regulator-compatible = "BUCK1";
+regulator-name = "mt6360,buck1";
+regulator-min-microvolt = <30>;
+regulator-max-microvolt = <130>;
+regulator-allowed-modes = ;
+ };
+ BUCK2: buck2 {
+regulator-compatible = "BUCK2";
+regulator-name = "mt6360,buck2";
+regulator-min-microvolt = <30>;
+regulator-max-microvolt = <130>;
+regulator-allowed-modes = ;
+ };
+ ldo6 {
+regulator-compatible = "LDO6";
+regulator-name = "mt6360,ldo6";
+regulator-min-microvolt = <50>;
+regulator-max-microvolt = <210>;
+regulator-allowed-modes = ;
+ };
+ ldo7 {
+regulator-compatible = "LDO7";
+regulator-name = "mt6360,ldo7";
+regulator-min-microvolt = <50>;
+regulator-max-microvolt = <210>;
+regulator-allowed-modes = ;
+ };
+ ldo1 {
+regulator-compatible = "LDO1";
+regulator-name = "mt6360,ldo1";
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+ };
+ldo2 {
+regulator-compatible = "LDO2";
+regulator-name = "mt6360,ldo2";
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+ };
+ ldo3 {
+regulator-compatible = "LDO3";
+regulator-name = "mt6360,ldo3";
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+ };
+ ldo5 {
+regulator-compatible = "LDO5";
+regulator-name = "mt6360,ldo5";
+regulator-min-microvolt = <270>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+ };
+};
+...
--
2.7.4
[PATCH 01/12] regulator: 88pg86x: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/88pg86x.c:87:34: warning: ‘pg86x_dt_ids’ defined but not used
[-Wunused-const-variable=]
87 | static const struct of_device_id pg86x_dt_ids [] = {
| ^~~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/88pg86x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/88pg86x.c b/drivers/regulator/88pg86x.c
index 71cfa2c5de5e..c47c14d190f5 100644
--- a/drivers/regulator/88pg86x.c
+++ b/drivers/regulator/88pg86x.c
@@ -84,12 +84,14 @@ static int pg86x_i2c_probe(struct i2c_client *i2c)
return 0;
}
+#ifdef CONFIG_OF
static const struct of_device_id pg86x_dt_ids [] = {
{ .compatible = "marvell,88pg867" },
{ .compatible = "marvell,88pg868" },
{ }
};
MODULE_DEVICE_TABLE(of, pg86x_dt_ids);
+#endif
static const struct i2c_device_id pg86x_i2c_id[] = {
{ "88pg867", },
--
2.28.0
[PATCH v3 1/2] regulator: mt6360: Add support for MT6360 regulator
From: Gene Chen
Add MT6360 regulator driver that contains two BUCKs and six LDOs
Signed-off-by: Gene Chen
---
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6360-regulator.c | 458 +
.../regulator/mediatek,mt6360-regulator.h | 16 +
4 files changed, 484 insertions(+)
create mode 100644 drivers/regulator/mt6360-regulator.c
create mode 100644 include/dt-bindings/regulator/mediatek,mt6360-regulator.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index de17ef7..8a6c3c6 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -711,6 +711,15 @@ config REGULATOR_MT6358
This driver supports the control of different power rails of device
through regulator interface.
+config REGULATOR_MT6360
+ tristate "MT6360 SubPMIC Regulator"
+ depends on MFD_MT6360
+ help
+ Say Y here to enable MT6360 regulator support.
+ This is support MT6360 PMIC/LDO part include
+ 2-channel buck with Thermal Shutdown and Overload Protection
+ 6-channel High PSRR and Low Dropout LDO.
+
config REGULATOR_MT6380
tristate "MediaTek MT6380 PMIC"
depends on MTK_PMIC_WRAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index d8d3ecf..821a33f 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_REGULATOR_MPQ7920) += mpq7920.o
obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
+obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
diff --git a/drivers/regulator/mt6360-regulator.c
b/drivers/regulator/mt6360-regulator.c
new file mode 100644
index 000..f01d1cc
--- /dev/null
+++ b/drivers/regulator/mt6360-regulator.c
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (C) 2020 MediaTek Inc.
+//
+// Author: Gene Chen
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum {
+ MT6360_REGULATOR_BUCK1 = 0,
+ MT6360_REGULATOR_BUCK2,
+ MT6360_REGULATOR_LDO6,
+ MT6360_REGULATOR_LDO7,
+ MT6360_REGULATOR_LDO1,
+ MT6360_REGULATOR_LDO2,
+ MT6360_REGULATOR_LDO3,
+ MT6360_REGULATOR_LDO5,
+ MT6360_REGULATOR_MAX,
+};
+
+struct mt6360_irq_mapping {
+ const char *name;
+ irq_handler_t handler;
+};
+
+struct mt6360_regulator_desc {
+ const struct regulator_desc desc;
+ unsigned int mode_reg;
+ unsigned int mode_mask;
+ unsigned int state_reg;
+ unsigned int state_mask;
+ const struct mt6360_irq_mapping *irq_tables;
+ int irq_table_size;
+};
+
+struct mt6360_regulator_data {
+ struct device *dev;
+ struct regmap *regmap;
+};
+
+static irqreturn_t mt6360_pgb_event_handler(int irq, void *data)
+{
+ struct regulator_dev *rdev = data;
+
+ regulator_notifier_call_chain(rdev, REGULATOR_EVENT_FAIL, NULL);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t mt6360_oc_event_handler(int irq, void *data)
+{
+ struct regulator_dev *rdev = data;
+
+ regulator_notifier_call_chain(rdev, REGULATOR_EVENT_OVER_CURRENT, NULL);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t mt6360_ov_event_handler(int irq, void *data)
+{
+ struct regulator_dev *rdev = data;
+
+ regulator_notifier_call_chain(rdev, REGULATOR_EVENT_REGULATION_OUT,
NULL);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t mt6360_uv_event_handler(int irq, void *data)
+{
+ struct regulator_dev *rdev = data;
+
+ regulator_notifier_call_chain(rdev, REGULATOR_EVENT_UNDER_VOLTAGE,
NULL);
+ return IRQ_HANDLED;
+}
+
+static const struct mt6360_irq_mapping buck1_irq_tbls[] = {
+ { "buck1_pgb_evt", mt6360_pgb_event_handler },
+ { "buck1_oc_evt", mt6360_oc_event_handler },
+ { "buck1_ov_evt", mt6360_ov_event_handler },
+ { "buck1_uv_evt", mt6360_uv_event_handler },
+};
+
+static const struct mt6360_irq_mapping buck2_irq_tbls[] = {
+ { "buck2_pgb_evt", mt6360_pgb_event_handler },
+ { "buck2_oc_evt", mt6360_oc_event_handler },
+ { "buck2_ov_evt", mt6360_ov_event_handler },
+ { "buck2_uv_evt", mt6360_uv_event_handler },
+};
+
+static const struct mt6360_irq_mapping ldo6_irq_tbls[] = {
+ { "ldo6_pgb_evt", mt6360_pgb_event_handler },
+ { "ldo6_oc_evt", mt6360_oc_event_handler },
+};
+
+static const struct mt6360_irq_mapping ldo7_irq_tbls[] = {
+ { "ldo7_pgb_evt", mt6360_pgb_event_handler },
+ { "ldo7_oc_evt", mt6360_oc_event_handler },
+};
+
+static const struct mt6360_irq_mapping ldo1_irq_tbls[
[PATCH 04/12] regulator: fixed: Fix W=1 build warnings when CONFIG_OF=n
Fix below warnings when CONFIG_OF=n:
drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but
not used [-Wunused-const-variable=]
48 | static const struct fixed_dev_type fixed_clkenable_data = {
|^~~~
drivers/regulator/fixed.c:44:36: warning: ‘fixed_voltage_data’ defined but not
used [-Wunused-const-variable=]
44 | static const struct fixed_dev_type fixed_voltage_data = {
|^~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/fixed.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index d54830e48b8d..2d92a471ebc1 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -41,14 +41,6 @@ struct fixed_dev_type {
bool has_enable_clock;
};
-static const struct fixed_dev_type fixed_voltage_data = {
- .has_enable_clock = false,
-};
-
-static const struct fixed_dev_type fixed_clkenable_data = {
- .has_enable_clock = true,
-};
-
static int reg_clock_enable(struct regulator_dev *rdev)
{
struct fixed_voltage_data *priv = rdev_get_drvdata(rdev);
@@ -260,6 +252,14 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
}
#if defined(CONFIG_OF)
+static const struct fixed_dev_type fixed_voltage_data = {
+ .has_enable_clock = false,
+};
+
+static const struct fixed_dev_type fixed_clkenable_data = {
+ .has_enable_clock = true,
+};
+
static const struct of_device_id fixed_of_match[] = {
{
.compatible = "regulator-fixed",
--
2.28.0
arch/s390/include/asm/atomic_ops.h:56:45: error: invalid operand for inline asm constraint 'i'
Hi Vasily, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 18445bf405cb331117bc98427b1ba6f12418ad17 commit: f0cbd3b83ed47803df941865f720934c69abb803 s390/atomic: circumvent gcc 10 build regression date: 9 days ago config: s390-randconfig-r003-20200818 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 4deda57106f7c9b982a49cb907c33e3966c8de7f) 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 # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu git checkout f0cbd3b83ed47803df941865f720934c69abb803 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from drivers/tty/tty_buffer.c:8: In file included from include/linux/tty.h:5: In file included from include/linux/fs.h:6: In file included from include/linux/wait_bit.h:8: In file included from include/linux/wait.h:7: In file included from include/linux/list.h:9: In file included from include/linux/kernel.h:12: In file included from include/linux/bitops.h:29: In file included from arch/s390/include/asm/bitops.h:39: >> arch/s390/include/asm/atomic_ops.h:56:45: error: invalid operand for inline >> asm constraint 'i' __ATOMIC_CONST_OPS(__atomic_add_const, int, "asi") ^ 1 error generated. # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0cbd3b83ed47803df941865f720934c69abb803 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout f0cbd3b83ed47803df941865f720934c69abb803 vim +/i +56 arch/s390/include/asm/atomic_ops.h 126b30c3cb476c Martin Schwidefsky 2016-11-11 51 eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 52 #define __ATOMIC_CONST_OPS(op_name, op_type, op_string) \ eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 53 __ATOMIC_CONST_OP(op_name, op_type, op_string, "\n")\ eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 54 __ATOMIC_CONST_OP(op_name##_barrier, op_type, op_string, "bcr 14,0\n") eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 55 eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 @56 __ATOMIC_CONST_OPS(__atomic_add_const, int, "asi") eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 57 __ATOMIC_CONST_OPS(__atomic64_add_const, long, "agsi") eb3b7b848fb3dd Martin Schwidefsky 2017-03-24 58 :: The code at line 56 was first introduced by commit :: eb3b7b848fb3dd00f7a57d633d4ae4d194aa7865 s390/rwlock: introduce rwlock wait queueing :: TO: Martin Schwidefsky :: CC: Martin Schwidefsky --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH 11/12] regulator: stm32-vrefbuf: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/stm32-vrefbuf.c:287:34: warning: ‘stm32_vrefbuf_of_match’
defined but not used [-Wunused-const-variable=]
287 | static const struct of_device_id stm32_vrefbuf_of_match[] = {
| ^~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/stm32-vrefbuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/stm32-vrefbuf.c
b/drivers/regulator/stm32-vrefbuf.c
index 992bc18101ef..5a5c12d9ea22 100644
--- a/drivers/regulator/stm32-vrefbuf.c
+++ b/drivers/regulator/stm32-vrefbuf.c
@@ -284,11 +284,13 @@ static const struct dev_pm_ops stm32_vrefbuf_pm_ops = {
NULL)
};
+#ifdef CONFIG_OF
static const struct of_device_id stm32_vrefbuf_of_match[] = {
{ .compatible = "st,stm32-vrefbuf", },
{},
};
MODULE_DEVICE_TABLE(of, stm32_vrefbuf_of_match);
+#endif
static struct platform_driver stm32_vrefbuf_driver = {
.probe = stm32_vrefbuf_probe,
--
2.28.0
[PATCH 07/12] regulator: max1586: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/max1586.c:204:34: warning: ‘max1586_of_match’ defined but not
used [-Wunused-const-variable=]
204 | static const struct of_device_id max1586_of_match[] = {
| ^~~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/max1586.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index f8941025780b..2ddcdd2908b1 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -201,11 +201,13 @@ static int of_get_max1586_platform_data(struct device
*dev,
return 0;
}
+#ifdef CONFIG_OF
static const struct of_device_id max1586_of_match[] = {
{ .compatible = "maxim,max1586", },
{},
};
MODULE_DEVICE_TABLE(of, max1586_of_match);
+#endif
static int max1586_pmic_probe(struct i2c_client *client,
const struct i2c_device_id *i2c_id)
--
2.28.0
Re: [PATCH v4] usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA 2.3.1.2 failures
On Mon, Aug 17, 2020 at 11:46:01AM -0700, Badhri Jagan Sridharan wrote: > The patch addresses the compliance test failures while running TDA > 2.3.1.1 and TDA 2.3.1.2 of the "PD Communications Engine USB PD > Compliance MOI" test plan published in https://www.usb.org/usbc. > For a product to be Type-C compliant, it's expected that these tests > are run on usb.org certified Type-C compliance tester as mentioned in > https://www.usb.org/usbc. > > While the purpose of TDA 2.3.1.1 and TDA 2.3.1.2 is to verify that > the static and dynamic electrical capabilities of a Source meet the > requirements for each PDO offered, while doing so, the tests also > monitor that the timing of the VBUS waveform versus the messages meets > the requirements for Hard Reset defined in PROT-PROC-HR-TSTR as > mentioned in step 11 of TDA.2.3.1.1 and step 15 of TDA.2.3.1.2. > > TDB.2.2.13.1: PROT-PROC-HR-TSTR Procedure and Checks for Tester > Originated Hard Reset > Purpose: To perform the appropriate protocol checks relating to any > circumstance in which the Hard Reset signal is sent by the Tester. > > UUT is behaving as source: > The Tester sends a Hard Reset signal. > 1. Check VBUS stays within present valid voltage range for > tPSHardReset min (25ms) after last bit of Hard Reset signal. > [PROT_PROC_HR_TSTR_1] > 2. Check that VBUS starts to fall below present valid voltage range by > tPSHardReset max (35ms). [PROT_PROC_HR_TSTR_2] > 3. Check that VBUS reaches vSafe0V within tSafe0v max (650 ms). > [PROT_PROC_HR_TSTR_3] > 4. Check that VBUS starts rising to vSafe5V after a delay of > tSrcRecover (0.66s - 1s) from reaching vSafe0V. [PROT_PROC_HR_TSTR_4] > 5. Check that VBUS reaches vSafe5V within tSrcTurnOn max (275ms) of > rising above vSafe0v max (0.8V). [PROT_PROC_HR_TSTR_5] Power Delivery > Compliance Plan 139 6. Check that Source Capabilities are finished > sending within tFirstSourceCap max (250ms) of VBUS reaching vSafe5v > min. [PROT_PROC_HR_TSTR_6]. > > This is in line with 7.1.5 Response to Hard Resets of the USB Power > Delivery Specification Revision 3.0, Version 1.2, > "Hard Reset Signaling indicates a communication failure has occurred > and the Source Shall stop driving VCONN, Shall remove Rp from the > VCONN pin and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The > USB connection May reset during a Hard Reset since the VBUS voltage > will be less than vSafe5V for an extended period of time. After > establishing the vSafe0V voltage condition on VBUS, the Source Shall > wait tSrcRecover before re-applying VCONN and restoring VBUS to > vSafe5V. A Source Shall conform to the VCONN timing as specified in > [USB Type-C 1.3]." > > With the above guidelines from the spec in mind, TCPM does not turn > off VCONN while entering SRC_HARD_RESET_VBUS_OFF. The patch makes TCPM > turn off VCONN while entering SRC_HARD_RESET_VBUS_OFF and turn it back > on while entering SRC_HARD_RESET_VBUS_ON along with vbus instead of > having VCONN on through hardreset. > > Also, the spec clearly states that "After establishing the vSafe0V > voltage condition on VBUS", the Source Shall wait tSrcRecover before > re-applying VCONN and restoring VBUS to vSafe5V. > TCPM does not conform to this requirement. If the TCPC driver calls > tcpm_vbus_change with vbus off signal, TCPM right away enters > SRC_HARD_RESET_VBUS_ON without waiting for tSrcRecover. > For TCPC's which are buggy/does not call tcpm_vbus_change, TCPM > assumes that the vsafe0v is instantaneous as TCPM only waits > tSrcRecover instead of waiting for tSafe0v + tSrcRecover. > This patch also fixes this behavior by making sure that TCPM waits for > tSrcRecover before transitioning into SRC_HARD_RESET_VBUS_ON when > tcpm_vbus_change is called by TCPC. > When TCPC does not call tcpm_vbus_change, TCPM assumes the worst case > i.e. tSafe0v + tSrcRecover before transitioning into > SRC_HARD_RESET_VBUS_ON. > > Signed-off-by: Badhri Jagan Sridharan > Reviewed-by: Guenter Roeck Reviewed-by: Heikki Krogerus > --- > Changes since V1 (Guenter's suggestion): > - Bound SRC_HARD_RESET_VBUS_ON to accommodate tcpc drivers which doesn't > update the vbus status. > > Changes since V2: > - Reviewed-by: Guenter Roeck > > Changes since V3: > - Fixed compliance test numbers and updated commit description and made > in more elaborate to address Heikki's suggestion. > --- > drivers/usb/typec/tcpm/tcpm.c | 28 +--- > 1 file changed, 25 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index 3ef37202ee37..a48e3f90d196 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -3372,13 +3372,31 @@ static void run_state_machine(struct tcpm_port *port) > tcpm_set_state(port, SNK_HARD_RESET_SINK_OFF, 0); > break; > case SRC_HARD_RESET_VBUS_OFF: > - tcpm_set_vconn(port, true); > + /* > + * 7.1.5
[PATCH 12/12] regulator: sy8106a: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/sy8106a-regulator.c:126:34: warning: ‘sy8106a_i2c_of_match’
defined but not used [-Wunused-const-variable=]
126 | static const struct of_device_id sy8106a_i2c_of_match[] = {
| ^~~~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/sy8106a-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/sy8106a-regulator.c
b/drivers/regulator/sy8106a-regulator.c
index e739e62b..1878caf4dd40 100644
--- a/drivers/regulator/sy8106a-regulator.c
+++ b/drivers/regulator/sy8106a-regulator.c
@@ -123,11 +123,13 @@ static int sy8106a_i2c_probe(struct i2c_client *i2c)
return 0;
}
+#ifdef CONFIG_OF
static const struct of_device_id sy8106a_i2c_of_match[] = {
{ .compatible = "silergy,sy8106a" },
{ },
};
MODULE_DEVICE_TABLE(of, sy8106a_i2c_of_match);
+#endif
static const struct i2c_device_id sy8106a_i2c_id[] = {
{ "sy8106a", 0 },
--
2.28.0
Re: [PATCH] Revert "irqchip/mtk-sysirq: Convert to a platform driver"
On 2020-08-19 19:51, Saravana Kannan wrote: On Wed, Aug 19, 2020 at 9:52 AM Frank Wunderlich wrote: hi, does the fix you've linked to my revert [1] not work in your case? [1] https://patchwork.kernel.org/patch/11718481/ Thanks for pointing it out Frank. Also, might want to avoid top posting in the future. Enric, Can you please try that other fix and see if that solves your issue? I think Enric was clear that the driver does probe correctly (meaning that he has the fix in his tree). It is everything else that breaks, because none of the drivers on the platform are equipped to defer their own probing. I think we need to change this works right now, meaning that we can't blindly change the behaviour of *built-in* drivers. I'll see if I can come up with something quickly, but I'll otherwise take Enric patch. M. -- Jazz is not dead. It just smells funny...
[PATCH V3 3/4] opp: Split out _opp_set_rate_zero()
Create separate routine _opp_set_rate_zero() to handle !target_freq
case.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 52 ++
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0b437d483b75..4edd2c3d6d91 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -860,6 +860,34 @@ int dev_pm_opp_set_bw(struct device *dev, struct
dev_pm_opp *opp)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_set_bw);
+static int _opp_set_rate_zero(struct device *dev, struct opp_table *opp_table)
+{
+ int ret;
+
+ if (!opp_table->enabled)
+ return 0;
+
+ /*
+* Some drivers need to support cases where some platforms may
+* have OPP table for the device, while others don't and
+* opp_set_rate() just needs to behave like clk_set_rate().
+*/
+ if (!_get_opp_count(opp_table))
+ return 0;
+
+ ret = _set_opp_bw(opp_table, NULL, dev, true);
+ if (ret)
+ return ret;
+
+ if (opp_table->regulators)
+ regulator_disable(opp_table->regulators[0]);
+
+ ret = _set_required_opps(dev, opp_table, NULL);
+
+ opp_table->enabled = false;
+ return ret;
+}
+
/**
* dev_pm_opp_set_rate() - Configure new OPP based on frequency
* @dev:device for which we do this operation
@@ -886,29 +914,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
}
if (unlikely(!target_freq)) {
- ret = 0;
-
- if (!opp_table->enabled)
- goto put_opp_table;
-
- /*
-* Some drivers need to support cases where some platforms may
-* have OPP table for the device, while others don't and
-* opp_set_rate() just needs to behave like clk_set_rate().
-*/
- if (!_get_opp_count(opp_table))
- goto put_opp_table;
-
- ret = _set_opp_bw(opp_table, NULL, dev, true);
- if (ret)
- goto put_opp_table;
-
- if (opp_table->regulators)
- regulator_disable(opp_table->regulators[0]);
-
- ret = _set_required_opps(dev, opp_table, NULL);
-
- opp_table->enabled = false;
+ ret = _opp_set_rate_zero(dev, opp_table);
goto put_opp_table;
}
--
2.25.0.rc1.19.g042ed3e048af
[PATCH V3 4/4] opp: Remove _dev_pm_opp_find_and_remove_table() wrapper
Remove the unnecessary wrapper and merge
_dev_pm_opp_find_and_remove_table() with dev_pm_opp_remove_table().
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 21 -
drivers/opp/cpu.c | 2 +-
drivers/opp/of.c | 2 +-
drivers/opp/opp.h | 1 -
4 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 4edd2c3d6d91..6978b9218c6e 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -2395,7 +2395,14 @@ int dev_pm_opp_unregister_notifier(struct device *dev,
}
EXPORT_SYMBOL(dev_pm_opp_unregister_notifier);
-void _dev_pm_opp_find_and_remove_table(struct device *dev)
+/**
+ * dev_pm_opp_remove_table() - Free all OPPs associated with the device
+ * @dev: device pointer used to lookup OPP table.
+ *
+ * Free both OPPs created using static entries present in DT and the
+ * dynamically added entries.
+ */
+void dev_pm_opp_remove_table(struct device *dev)
{
struct opp_table *opp_table;
@@ -2420,16 +2427,4 @@ void _dev_pm_opp_find_and_remove_table(struct device
*dev)
/* Drop reference taken while the OPP table was added */
dev_pm_opp_put_opp_table(opp_table);
}
-
-/**
- * dev_pm_opp_remove_table() - Free all OPPs associated with the device
- * @dev: device pointer used to lookup OPP table.
- *
- * Free both OPPs created using static entries present in DT and the
- * dynamically added entries.
- */
-void dev_pm_opp_remove_table(struct device *dev)
-{
- _dev_pm_opp_find_and_remove_table(dev);
-}
EXPORT_SYMBOL_GPL(dev_pm_opp_remove_table);
diff --git a/drivers/opp/cpu.c b/drivers/opp/cpu.c
index b5055cc886ef..5004335cf0de 100644
--- a/drivers/opp/cpu.c
+++ b/drivers/opp/cpu.c
@@ -124,7 +124,7 @@ void _dev_pm_opp_cpumask_remove_table(const struct cpumask
*cpumask,
continue;
}
- _dev_pm_opp_find_and_remove_table(cpu_dev);
+ dev_pm_opp_remove_table(cpu_dev);
}
}
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 0430290670ab..7d9d4455a59e 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -616,7 +616,7 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,
struct device *dev,
*/
void dev_pm_opp_of_remove_table(struct device *dev)
{
- _dev_pm_opp_find_and_remove_table(dev);
+ dev_pm_opp_remove_table(dev);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index 0c3de3f6db5c..78e876ec803e 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -217,7 +217,6 @@ void _get_opp_table_kref(struct opp_table *opp_table);
int _get_opp_count(struct opp_table *opp_table);
struct opp_table *_find_opp_table(struct device *dev);
struct opp_device *_add_opp_dev(const struct device *dev, struct opp_table
*opp_table);
-void _dev_pm_opp_find_and_remove_table(struct device *dev);
struct dev_pm_opp *_opp_allocate(struct opp_table *opp_table);
void _opp_free(struct dev_pm_opp *opp);
int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2);
--
2.25.0.rc1.19.g042ed3e048af
[PATCH V3 0/4] opp: general cleanups
Hi, Here is another version of the cleanups I sent earlier. Rajendra: Please see if these work fine now. V3: - Dropped v2 1/4 as it is already merged. - New patch 4/4 added. - Reordered the first two patches here (Stephen) - disable regulator only if present Viresh Kumar (4): opp: Rename regulator_enabled and use it as status of all resources opp: Track device's resources configuration status opp: Split out _opp_set_rate_zero() opp: Remove _dev_pm_opp_find_and_remove_table() wrapper drivers/opp/core.c | 103 + drivers/opp/cpu.c | 2 +- drivers/opp/of.c | 2 +- drivers/opp/opp.h | 5 +-- 4 files changed, 52 insertions(+), 60 deletions(-) -- 2.25.0.rc1.19.g042ed3e048af
[PATCH V3 2/4] opp: Reuse the enabled flag in !target_freq path
The OPP core needs to track if the resources of devices are
enabled/configured or not, as it disables the resources when target_freq
is set to 0.
Handle that with the new enabled flag and remove otherwise complex
conditional statements.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 6f43ef4945b7..0b437d483b75 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -886,22 +886,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
}
if (unlikely(!target_freq)) {
+ ret = 0;
+
+ if (!opp_table->enabled)
+ goto put_opp_table;
+
/*
* Some drivers need to support cases where some platforms may
* have OPP table for the device, while others don't and
* opp_set_rate() just needs to behave like clk_set_rate().
*/
- if (!_get_opp_count(opp_table)) {
- ret = 0;
- goto put_opp_table;
- }
-
- if (!opp_table->required_opp_tables && !opp_table->regulators &&
- !opp_table->paths) {
- dev_err(dev, "target frequency can't be 0\n");
- ret = -EINVAL;
+ if (!_get_opp_count(opp_table))
goto put_opp_table;
- }
ret = _set_opp_bw(opp_table, NULL, dev, true);
if (ret)
@@ -931,14 +927,11 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
old_freq = clk_get_rate(clk);
/* Return early if nothing to do */
- if (old_freq == freq) {
- if (!opp_table->required_opp_tables && !opp_table->regulators &&
- !opp_table->paths) {
- dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are
same, nothing to do\n",
- __func__, freq);
- ret = 0;
- goto put_opp_table;
- }
+ if (opp_table->enabled && old_freq == freq) {
+ dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same,
nothing to do\n",
+ __func__, freq);
+ ret = 0;
+ goto put_opp_table;
}
/*
--
2.25.0.rc1.19.g042ed3e048af
[PATCH V3 1/4] opp: Rename regulator_enabled and use it as status of all resources
Expand the scope of the regulator_enabled flag and use it to track
status of all the resources. This will be used for other stuff in the
next patch.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 19 +--
drivers/opp/opp.h | 4 ++--
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 9668ea04cc80..6f43ef4945b7 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -703,12 +703,10 @@ static int _generic_set_opp_regulator(struct opp_table
*opp_table,
* Enable the regulator after setting its voltages, otherwise it breaks
* some boot-enabled regulators.
*/
- if (unlikely(!opp_table->regulator_enabled)) {
+ if (unlikely(!opp_table->enabled)) {
ret = regulator_enable(reg);
if (ret < 0)
dev_warn(dev, "Failed to enable regulator: %d", ret);
- else
- opp_table->regulator_enabled = true;
}
return 0;
@@ -909,12 +907,12 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
if (ret)
goto put_opp_table;
- if (opp_table->regulator_enabled) {
+ if (opp_table->regulators)
regulator_disable(opp_table->regulators[0]);
- opp_table->regulator_enabled = false;
- }
ret = _set_required_opps(dev, opp_table, NULL);
+
+ opp_table->enabled = false;
goto put_opp_table;
}
@@ -1001,8 +999,11 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
dev_err(dev, "Failed to set required opps: %d\n", ret);
}
- if (!ret)
+ if (!ret) {
ret = _set_opp_bw(opp_table, opp, dev, false);
+ if (!ret)
+ opp_table->enabled = true;
+ }
put_opp:
dev_pm_opp_put(opp);
@@ -1796,11 +1797,9 @@ void dev_pm_opp_put_regulators(struct opp_table
*opp_table)
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON(!list_empty(&opp_table->opp_list));
- if (opp_table->regulator_enabled) {
+ if (opp_table->enabled) {
for (i = opp_table->regulator_count - 1; i >= 0; i--)
regulator_disable(opp_table->regulators[i]);
-
- opp_table->regulator_enabled = false;
}
for (i = opp_table->regulator_count - 1; i >= 0; i--)
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index e51646ff279e..0c3de3f6db5c 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -147,11 +147,11 @@ enum opp_table_access {
* @clk: Device's clock handle
* @regulators: Supply regulators
* @regulator_count: Number of power supply regulators. Its value can be -1
- * @regulator_enabled: Set to true if regulators were previously enabled.
* (uninitialized), 0 (no opp-microvolt property) or > 0 (has opp-microvolt
* property).
* @paths: Interconnect path handles
* @path_count: Number of interconnect paths
+ * @enabled: Set to true if the device's resources are enabled/configured.
* @genpd_performance_state: Device's power domain support performance state.
* @is_genpd: Marks if the OPP table belongs to a genpd.
* @set_opp: Platform specific set_opp callback
@@ -195,9 +195,9 @@ struct opp_table {
struct clk *clk;
struct regulator **regulators;
int regulator_count;
- bool regulator_enabled;
struct icc_path **paths;
unsigned int path_count;
+ bool enabled;
bool genpd_performance_state;
bool is_genpd;
--
2.25.0.rc1.19.g042ed3e048af
[PATCH mmc-next v2] mmc: allow setting slot index via device tree alias
As with GPIO, UART and others, allow specifying the device index via the
aliases node in the device tree.
On embedded devices, there is often a combination of removable (e.g.
SD card) and non-removable MMC devices (e.g. eMMC).
Therefore the index might change depending on
* host of removable device
* removable card present or not
This makes it difficult to hardcode the root device, if it is on the
non-removable device. E.g. if SD card is present eMMC will be mmcblk1,
if SD card is not present at boot, eMMC will be mmcblk0.
All indices defined in the aliases node will be reserved for use by the
respective MMC device, moving the indices of devices that don't have an
alias up into the non-reserved range. If the aliases node is not found,
the driver will act as before.
This is a rebased and slightly cleaned up version of
https://www.spinics.net/lists/linux-mmc/msg26588.html .
Based-on-patch-by: Sascha Hauer
Link: https://lkml.org/lkml/2020/8/5/194
Signed-off-by: Matthias Schiffer
---
v2: fix missing symbols for modular mmcblock
drivers/mmc/core/block.c | 13 +++--
drivers/mmc/core/core.c | 40
drivers/mmc/core/core.h | 3 +++
drivers/mmc/core/host.c | 15 +--
4 files changed, 67 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 7896952de1ac..4620afaf0e50 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2260,9 +2261,17 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
int area_type)
{
struct mmc_blk_data *md;
- int devidx, ret;
+ int rsvidx, devidx = -1, ret;
+
+ rsvidx = mmc_get_reserved_index(card->host);
+ if (rsvidx >= 0)
+ devidx = ida_simple_get(&mmc_blk_ida, rsvidx, rsvidx + 1,
+ GFP_KERNEL);
+ if (devidx < 0)
+ devidx = ida_simple_get(&mmc_blk_ida,
+ mmc_first_nonreserved_index(),
+ max_devices, GFP_KERNEL);
- devidx = ida_simple_get(&mmc_blk_ida, 0, max_devices, GFP_KERNEL);
if (devidx < 0) {
/*
* We get -ENOSPC because there are no more any available
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8ccae6452b9c..5bce281a5faa 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2419,10 +2419,50 @@ void mmc_unregister_pm_notifier(struct mmc_host *host)
}
#endif
+static int mmc_max_reserved_idx = -1;
+
+/**
+ * mmc_first_nonreserved_index() - get the first index that is not reserved
+ */
+int mmc_first_nonreserved_index(void)
+{
+ return mmc_max_reserved_idx + 1;
+}
+EXPORT_SYMBOL(mmc_first_nonreserved_index);
+
+/**
+ * mmc_get_reserved_index() - get the index reserved for this MMC host
+ *
+ * Returns:
+ * The index reserved for this host on success,
+ * negative error if no index is reserved for this host
+ */
+int mmc_get_reserved_index(struct mmc_host *host)
+{
+ return of_alias_get_id(host->parent->of_node, "mmc");
+}
+EXPORT_SYMBOL(mmc_get_reserved_index);
+
+static void __init mmc_of_reserve_idx(void)
+{
+ int max;
+
+ max = of_alias_get_highest_id("mmc");
+ if (max < 0)
+ return;
+
+ mmc_max_reserved_idx = max;
+
+ pr_debug("MMC: reserving %d slots for OF aliases\n",
+mmc_max_reserved_idx + 1);
+}
+
static int __init mmc_init(void)
{
int ret;
+ mmc_of_reserve_idx();
+
ret = mmc_register_bus();
if (ret)
return ret;
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 575ac0257af2..6aef6cf4e90f 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -79,6 +79,9 @@ int mmc_attach_mmc(struct mmc_host *host);
int mmc_attach_sd(struct mmc_host *host);
int mmc_attach_sdio(struct mmc_host *host);
+int mmc_first_nonreserved_index(void);
+int mmc_get_reserved_index(struct mmc_host *host);
+
/* Module parameters */
extern bool use_spi_crc;
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index ce43f7573d80..386e15afde83 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -387,6 +387,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*dev)
{
int err;
struct mmc_host *host;
+ int alias_id, min_idx, max_idx;
host = kzalloc(sizeof(struct mmc_host) + extra, GFP_KERNEL);
if (!host)
@@ -395,7 +396,18 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*dev)
/* scanning will be enabled when we're ready */
host->rescan_disable = 1;
- err = ida_simple_get(&mmc_host_ida, 0, 0, GFP_KERNEL);
+ host->parent = dev;
+
+ alias_id = mmc_get_reserved_index(host);
+
Re: [RFC PATCH 1/5] printk: implement pr_cont_t
On Thu, 2020-08-20 at 07:44 +, David Laight wrote: > I've no idea how you'd 'size' the number of buffers. I believe they are static and assume no more than 10 simultaneous uses of printk_begin +#define CONT_LINE_MAX LOG_LINE_MAX +#define CONT_BUF_COUNT 10 +static char cont_buf[CONT_BUF_COUNT][CONT_LINE_MAX]; +static DECLARE_BITMAP(cont_buf_map, CONT_BUF_COUNT); Though I don't see much value in a separate define for CONT_LINE_MAx
[PATCH 10/12] regulator: stm32-pwr: Fix W=1 build warning when CONFIG_OF=n
Fix below warning when CONFIG_OF=n:
drivers/regulator/stm32-pwr.c:169:34: warning: ‘stm32_pwr_of_match’ defined but
not used [-Wunused-const-variable=]
169 | static const struct of_device_id stm32_pwr_of_match[] = {
| ^~
Signed-off-by: Jisheng Zhang
---
drivers/regulator/stm32-pwr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/stm32-pwr.c b/drivers/regulator/stm32-pwr.c
index e0e627b0106e..3d5cd954c391 100644
--- a/drivers/regulator/stm32-pwr.c
+++ b/drivers/regulator/stm32-pwr.c
@@ -166,11 +166,13 @@ static int stm32_pwr_regulator_probe(struct
platform_device *pdev)
return ret;
}
+#ifdef CONFIG_OF
static const struct of_device_id stm32_pwr_of_match[] = {
{ .compatible = "st,stm32mp1,pwr-reg", },
{},
};
MODULE_DEVICE_TABLE(of, stm32_pwr_of_match);
+#endif
static struct platform_driver stm32_pwr_driver = {
.probe = stm32_pwr_regulator_probe,
--
2.28.0
Re: [PATCH 2/2] nvme: add emulation for zone-append
On 20.08.2020 08:52, Christoph Hellwig wrote: On Thu, Aug 20, 2020 at 08:37:19AM +0200, Javier Gonzalez wrote: We will stop pushing for this emulation. We have a couple of SSDs where we disabled Append, we implemented support for them, and we wanted to push the changes upstream. That's it. This is no politics not a conspiracy against the current ZNS spec. We spent a lot of time working on this spec and are actually doing a fair amount of work to support Append other places in the stack. In any case, the fuzz stops here. FYI, from knowing your personally I'm pretty confident you are not part of a conspiracy and you are just doing your best given the context, and I appreciate all your work! Thanks Christoph. I'm a lot less happy about thinks that happen in other groups not involving you directly, and I'm still pretty mad at how the games were played there, and especially other actors the seem to be reading the list here, and instead of taking part in the discussion are causing fuzz in completely unrelated venues. Yes. Hopefully, we will start keeping things separated and using this list for Linux, technical conversations only.
Re: [PATCH 00/49] DRM driver for Hikey 970
Em Wed, 19 Aug 2020 14:36:52 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab > wrote: > > So, IMO, the best is to keep it on staging for a while, until those > > remaining bugs gets solved. > > > > I added this series, together with the regulator driver and > > a few other patches (including a hack to fix a Kernel 5.8 > > regression at WiFi ) at: > > > > > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > Sorry, one more small request: Could you create a branch that only has > the DRM driver changes in it? > > The reason I ask, is that since the HiKey960 isn't affected by the > majority of the problems you listed as motivation for going through > staging. So if we can validate that your tree works fine on HiKey960, > the series can be cleaned up and submitted properly upstream to enable > that SoC, and the outstanding 970 issues can be worked out afterwards > against mainline. Well, if support for HiKey 960 is OK, I guess what we can do is to not push the patch with DT bindings for hikey970. We should probably fix the color swap thing at the driver first. From my side, provided that the history is preserved, I don't mind if this is merged: - via staging tree; - at dri-devel tree; - or having a the historic patchsets merged at /staging, with a follow up patch moving it from staging/ into /gpu/drm/. Thanks, Mauro
Re: [PATCH] coresight: cti: write regsiters directly in cti_enable_hw()
Hi Tingwei
On Tue, 18 Aug 2020 at 12:11, Tingwei Zhang wrote:
>
> Deadlock as below is triggered by one CPU holds drvdata->spinlock
> and calls cti_enable_hw(). Smp_call_function_single() is called
> in cti_enable_hw() and tries to let another CPU write CTI registers.
> That CPU is trying to get drvdata->spinlock in cti_cpu_pm_notify()
> and doesn't response to IPI from smp_call_function_single().
>
> [ 988.335937] CPU: 6 PID: 10258 Comm: sh Tainted: GWL
> 5.8.0-rc6-mainline-16783-gc38daa79b26b-dirty #1
> [ 988.346364] Hardware name: Thundercomm Dragonboard 845c (DT)
> [ 988.352073] pstate: 2045 (nzCv daif +PAN -UAO BTYPE=--)
> [ 988.357689] pc : smp_call_function_single+0x158/0x1b8
> [ 988.362782] lr : smp_call_function_single+0x124/0x1b8
> ...
> [ 988.451638] Call trace:
> [ 988.454119] smp_call_function_single+0x158/0x1b8
> [ 988.458866] cti_enable+0xb4/0xf8 [coresight_cti]
> [ 988.463618] coresight_control_assoc_ectdev+0x6c/0x128 [coresight]
> [ 988.469855] coresight_enable+0x1f0/0x364 [coresight]
> [ 988.474957] enable_source_store+0x5c/0x9c [coresight]
> [ 988.480140] dev_attr_store+0x14/0x28
> [ 988.483839] sysfs_kf_write+0x38/0x4c
> [ 988.487532] kernfs_fop_write+0x1c0/0x2b0
> [ 988.491585] vfs_write+0xfc/0x300
> [ 988.494931] ksys_write+0x78/0xe0
> [ 988.498283] __arm64_sys_write+0x18/0x20
> [ 988.502240] el0_svc_common+0x98/0x160
> [ 988.506024] do_el0_svc+0x78/0x80
> [ 988.509377] el0_sync_handler+0xd4/0x270
> [ 988.513337] el0_sync+0x164/0x180
>
> This change write CTI registers directly in cti_enable_hw().
> Config->hw_powered has been checked to be true with spinlock holded.
> CTI is powered and can be programmed until spinlock is released.
>
Agreed.
Reviewed-by Mike Leach
> Fixes: 6a0953ce7de9 ("coresight: cti: Add CPU idle pm notifer to CTI devices")
> Signed-off-by: Tingwei Zhang
> ---
> drivers/hwtracing/coresight/coresight-cti.c | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-cti.c
> b/drivers/hwtracing/coresight/coresight-cti.c
> index 3ccc703dc940..869569eb8c7f 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.c
> +++ b/drivers/hwtracing/coresight/coresight-cti.c
> @@ -86,13 +86,6 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata)
> CS_LOCK(drvdata->base);
> }
>
> -static void cti_enable_hw_smp_call(void *info)
> -{
> - struct cti_drvdata *drvdata = info;
> -
> - cti_write_all_hw_regs(drvdata);
> -}
> -
> /* write regs to hardware and enable */
> static int cti_enable_hw(struct cti_drvdata *drvdata)
> {
> @@ -112,15 +105,7 @@ static int cti_enable_hw(struct cti_drvdata *drvdata)
> if (rc)
> goto cti_err_not_enabled;
>
> - if (drvdata->ctidev.cpu >= 0) {
> - rc = smp_call_function_single(drvdata->ctidev.cpu,
> - cti_enable_hw_smp_call,
> - drvdata, 1);
> - if (rc)
> - goto cti_err_not_enabled;
> - } else {
> - cti_write_all_hw_regs(drvdata);
> - }
> + cti_write_all_hw_regs(drvdata);
>
> config->hw_enabled = true;
> atomic_inc(&drvdata->config.enable_req_count);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> ___
> CoreSight mailing list
> coresi...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Re: [RFC][PATCH 5/9] mm/migrate: demote pages during reclaim
Hi, Dave,
Dave Hansen writes:
[snip]
> diff -puN mm/vmscan.c~demote-with-migrate_pages mm/vmscan.c
> --- a/mm/vmscan.c~demote-with-migrate_pages 2020-08-18 11:36:52.919583179
> -0700
> +++ b/mm/vmscan.c 2020-08-18 11:36:52.924583179 -0700
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1040,6 +1041,24 @@ static enum page_references page_check_r
> return PAGEREF_RECLAIM;
> }
>
> +bool migrate_demote_page_ok(struct page *page, struct scan_control *sc)
> +{
> + int next_nid = next_demotion_node(page_to_nid(page));
> +
> + VM_BUG_ON_PAGE(!PageLocked(page), page);
> + VM_BUG_ON_PAGE(PageHuge(page), page);
> + VM_BUG_ON_PAGE(PageLRU(page), page);
> +
> + if (next_nid == NUMA_NO_NODE)
> + return false;
> + if (PageTransHuge(page) && !thp_migration_supported())
> + return false;
> +
> + // FIXME: actually enable this later in the series
> + return false;
> +}
> +
> +
> /* Check if a page is dirty or under writeback */
> static void page_check_dirty_writeback(struct page *page,
> bool *dirty, bool *writeback)
> @@ -1070,6 +1089,66 @@ static void page_check_dirty_writeback(s
> mapping->a_ops->is_dirty_writeback(page, dirty, writeback);
> }
>
> +static struct page *alloc_demote_page(struct page *page, unsigned long node)
> +{
> + /*
> + * Try to fail quickly if memory on the target node is not
> + * available. Leaving out __GFP_IO and __GFP_FS helps with
> + * this. If the desintation node is full, we want kswapd to
> + * run there so that its pages will get reclaimed and future
> + * migration attempts may succeed.
> + */
> + gfp_t flags = (__GFP_HIGHMEM | __GFP_MOVABLE | __GFP_NORETRY |
> +__GFP_NOMEMALLOC | __GFP_NOWARN | __GFP_THISNODE |
> +__GFP_KSWAPD_RECLAIM);
> + /* HugeTLB pages should not be on the LRU */
> + WARN_ON_ONCE(PageHuge(page));
> +
> + if (PageTransHuge(page)) {
> + struct page *thp;
> +
> + flags |= __GFP_COMP;
> +
> + thp = alloc_pages_node(node, flags, HPAGE_PMD_ORDER);
> + if (!thp)
> + return NULL;
> + prep_transhuge_page(thp);
> + return thp;
> + }
> +
> + return __alloc_pages_node(node, flags, 0);
> +}
> +
> +/*
> + * Take pages on @demote_list and attempt to demote them to
> + * another node. Pages which are not demoted are added to
> + * @ret_pages.
> + */
> +static unsigned int demote_page_list(struct list_head *ret_list,
> + struct list_head *demote_pages,
> + struct pglist_data *pgdat,
> + struct scan_control *sc)
> +{
> + int target_nid = next_demotion_node(pgdat->node_id);
> + unsigned int nr_succeeded = 0;
> + int err;
> +
> + if (list_empty(demote_pages))
> + return 0;
> +
> + /* Demotion ignores all cpuset and mempolicy settings */
> + err = migrate_pages(demote_pages, alloc_demote_page, NULL,
> + target_nid, MIGRATE_ASYNC, MR_DEMOTION,
> + &nr_succeeded);
> +
> + if (err) {
> + putback_movable_pages(demote_pages);
> + list_splice(ret_list, demote_pages);
> + }
> +
> + return nr_succeeded;
> +}
> +
> /*
> * shrink_page_list() returns the number of reclaimed pages
> */
> @@ -1082,6 +1161,7 @@ static unsigned int shrink_page_list(str
> {
> LIST_HEAD(ret_pages);
> LIST_HEAD(free_pages);
> + LIST_HEAD(demote_pages);
> unsigned int nr_reclaimed = 0;
> unsigned int pgactivate = 0;
>
> @@ -1237,6 +1317,16 @@ static unsigned int shrink_page_list(str
> }
>
> /*
> + * Before reclaiming the page, try to relocate
> + * its contents to another node.
> + */
> + if (migrate_demote_page_ok(page, sc)) {
> + list_add(&page->lru, &demote_pages);
> + unlock_page(page);
> + continue;
> + }
> +
> + /*
>* Anonymous process memory has backing store?
>* Try to allocate it some swap space here.
>* Lazyfree page could be freed directly
> @@ -1484,6 +1574,9 @@ keep:
> VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page);
> }
>
> + /* Migrate pages selected for demotion */
> + nr_reclaimed += demote_page_list(&ret_pages, &demote_pages, pgdat, sc);
> +
> pgactivate = stat->nr_activate[0] + stat->nr_activate[1];
>
> mem_cgroup_uncharge_list(&free_pages);
> _
Generally, it's good to batch the page migration. But one side effect
is that, if the pages are failed to be migrated, they will be placed
back to the LRU l
Re: [PATCH] irqchip: ingenic: Leave parent IRQ unmasked on suspend
On 2020-08-19 19:06, Paul Cercueil wrote: All the wakeup sources we possibly want will go through the interrupt controller, so the parent IRQ must not be masked during suspend, or there won't be any way to wake up the system. Signed-off-by: Paul Cercueil Do you have a Fixes: tag? Does it need to be Cc: to stable? Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH] Revert "irqchip/mtk-sysirq: Convert to a platform driver"
On Thu, Aug 20, 2020 at 12:56 AM Marc Zyngier wrote: > > On 2020-08-19 19:51, Saravana Kannan wrote: > > On Wed, Aug 19, 2020 at 9:52 AM Frank Wunderlich > > wrote: > >> > >> hi, > >> > >> does the fix you've linked to my revert [1] not work in your case? > >> > >> [1] https://patchwork.kernel.org/patch/11718481/ > > > > Thanks for pointing it out Frank. Also, might want to avoid top > > posting in the future. > > > > Enric, Can you please try that other fix and see if that solves your > > issue? > > I think Enric was clear that the driver does probe correctly > (meaning that he has the fix in his tree). It is everything else > that breaks, because none of the drivers on the platform are > equipped to defer their own probing. > > I think we need to change this works right now, meaning that we can't > blindly change the behaviour of *built-in* drivers. I'll see if I can > come up with something quickly, but I'll otherwise take Enric patch. Sounds fair Marc. Btw, Enric, out of curiosity, can you try adding "fw_devlink=on" to your kernel command line to see if it helps? It basically ensures proper probe ordering without depending on the drivers. There are some corner cases where it still can't work properly (too much to explain for a late night email), but if the platforms don't have those corner cases it'll work perfectly. I'm fine with the revert if Marc isn't able to find a quick fix to the drivers, but this might also fix your problem right away. -Saravana
Re: [PATCH v2 3/3] mm: remove superfluous __ClearPageWaiters()
On Thu, Aug 20, 2020 at 08:18:27AM +0200, Michal Hocko wrote:
> On Tue 18-08-20 12:47:04, Yu Zhao wrote:
> > Presumably __ClearPageWaiters() was added to follow the previously
> > removed __ClearPageActive() pattern.
>
> I do not think so. Please have a look at 62906027091f ("mm: add
> PageWaiters indicating tasks are waiting for a page bit") and a
> discussion when the patch has been proposed. Sorry I do not have a link
> handy but I do remember that the handling was quite subtle.
>
> > Only flags that are in PAGE_FLAGS_CHECK_AT_FREE needs to be properly
> > cleared because otherwise we think there may be some kind of leak.
> > PG_waiters is not one of those flags and leaving the clearing to
> > PAGE_FLAGS_CHECK_AT_PREP is more appropriate.
>
> What is the point of this patch in the first place? Page waiters is
> quite subtle and I wouldn't touch it without having a very good reason.
I appreciate your caution. And I just studied the history [1] (I admit
this is something I should have done beforehand), and didn't find any
discussion on __ClearPageWaiters() specifically. So I would ask why it
was added originally. I was hoping Nicholas could help us.
[1] https://lore.kernel.org/lkml/20161225030030.23219-3-npig...@gmail.com/
Given its triviality, I can't argue how useful this patch is. So I'll
go with how evident it is: we are removing __ClearPageWaiters() from
paths where pages have no references left -- they can't have any
waiters or be on any wait queues.
Re: [PATCH] coresight: cti: disclaim device only when it's claimed
On Tue, 18 Aug 2020 at 12:11, Tingwei Zhang wrote:
>
> Coresight_claim_device() is called in cti_starting_cpu() only
> when CTI is enabled while coresight_disclaim_device() is called
> uncontionally in cti_dying_cpu(). This triggered below WARNING.
> Only call disclaim device when CTI device is enabled to fix it.
>
> [ 75.989643] WARNING: CPU: 1 PID: 14 at
> kernel/drivers/hwtracing/coresight/coresight.c:209
> coresight_disclaim_device_unlocked+0x10/0x24
> [ 75.989697] CPU: 1 PID: 14 Comm: migration/1 Not tainted
> 5.9.0-rc1-gff1304be0a05-dirty #21
> [ 75.989709] Hardware name: Thundercomm Dragonboard 845c (DT)
> [ 75.989737] pstate: 80c00085 (Nzcv daIf +PAN +UAO BTYPE=--)
> [ 75.989758] pc : coresight_disclaim_device_unlocked+0x10/0x24
> [ 75.989775] lr : coresight_disclaim_device+0x24/0x38
> [ 75.989783] sp : 800011cd3c90
> .
> [ 75.990018] Call trace:
> [ 75.990041] coresight_disclaim_device_unlocked+0x10/0x24
> [ 75.990066] cti_dying_cpu+0x34/0x4c
> [ 75.990101] cpuhp_invoke_callback+0x84/0x1e0
> [ 75.990121] take_cpu_down+0x90/0xe0
> [ 75.990154] multi_cpu_stop+0x134/0x160
> [ 75.990171] cpu_stopper_thread+0xb0/0x13c
> [ 75.990196] smpboot_thread_fn+0x1c4/0x270
> [ 75.990222] kthread+0x128/0x154
> [ 75.990251] ret_from_fork+0x10/0x18
>
> Fixes: e9b880581d55 ("coresight: cti: Add CPU Hotplug handling to CTI driver")
> Signed-off-by: Tingwei Zhang
> ---
> drivers/hwtracing/coresight/coresight-cti.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-cti.c
> b/drivers/hwtracing/coresight/coresight-cti.c
> index 3ccc703dc940..d6fea6efec71 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.c
> +++ b/drivers/hwtracing/coresight/coresight-cti.c
> @@ -742,7 +742,8 @@ static int cti_dying_cpu(unsigned int cpu)
>
> spin_lock(&drvdata->spinlock);
> drvdata->config.hw_powered = false;
> - coresight_disclaim_device(drvdata->base);
> + if (drvdata->config.hw_enabled)
> + coresight_disclaim_device(drvdata->base);
> spin_unlock(&drvdata->spinlock);
> return 0;
> }
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Reviewed-by: Mike Leach
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Re: [PATCH 2/2] nvme: add emulation for zone-append
On 20.08.2020 13:07, Kanchan Joshi wrote:
On Thu, Aug 20, 2020 at 3:22 AM Keith Busch wrote:
On Wed, Aug 19, 2020 at 01:11:58PM -0600, David Fugate wrote:
> Intel does not support making *optional* NVMe spec features *required*
> by the NVMe driver.
This is inaccurate. As another example, the spec optionally allows a
zone size to be a power of 2, but linux requires a power of 2 if you
want to use it with this driver.
> Provided there's no glaring technical issues
There are many. Some may be improved through a serious review process,
but the mess it makes out of the fast path is measurably harmful to
devices that don't subscribe to this. That issue is not so easily
remedied.
Since this patch is a copy of the scsi implementation, the reasonable
thing is take this fight to the generic block layer for a common
solution. We're not taking this in the nvme driver.
I sincerely want to minimize any adverse impact to the fast-path of
non-zoned devices.
My understanding of that aspect is (I feel it is good to confirm,
irrespective of the future of this patch):
1. Submission path:
There is no extra code for non-zoned device IO. For append, there is
this "ns->append_emulate = 1" check.
Snippet -
case REQ_OP_ZONE_APPEND:
- ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_zone_append);
+ if (!nvme_is_append_emulated(ns))
+ ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_zone_append);
+ else {
+ /* prepare append like write, and adjust lba
afterwards */
2. Completion:
Not as clean as submission for sure.
The extra check is "ns && ns->append_emulate == 1" for completions if
CONFIG_ZONED is enabled.
A slightly better completion-handling version (than the submitted patch) is -
- } else if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) &&
- req_op(req) == REQ_OP_ZONE_APPEND) {
- req->__sector = nvme_lba_to_sect(req->q->queuedata,
- le64_to_cpu(nvme_req(req)->result.u64));
+ } else if (IS_ENABLED(CONFIG_BLK_DEV_ZONED)) {
+ struct nvme_ns *ns = req->q->queuedata;
+ /* append-emulation requires wp update for some cmds*/
+ if (ns && nvme_is_append_emulated(ns)) {
+ if (nvme_need_zone_wp_update(req))
+ nvme_zone_wp_update(ns, req, status);
+ }
+ else if (req_op(req) == REQ_OP_ZONE_APPEND)
+ req->__sector = nvme_lba_to_sect(ns,
+ le64_to_cpu(nvme_req(req)->result.u64));
Am I missing any other fast-path pain-points?
A quick 1 minute 4K randwrite run (QD 64, 4 jobs,libaio) shows :
before: IOPS=270k, BW=1056MiB/s (1107MB/s)(61.9GiB/60002msec)
after: IOPS=270k, BW=1055MiB/s (1106MB/s)(61.8GiB/60005msec)
It is good to use the QEMU "simulation" path that we implemented to test
performance with different delays, etc., but for these numbers to make
sense we need to put them in contrast to the simulated NAND speed, etc.
This maynot be the best test to see the cost, and I am happy to
conduct more and improvise.
As for the volume of the code - it is same as SCSI emulation. And I
can make efforts to reduce that by moving common code to blk-zone, and
reuse in SCSI/NVMe emulation.
In the patch I tried to isolate append-emulation by keeping everything
into "nvme_za_emul". It contains nothing nvme'ish except nvme_ns,
which can be turned into "driver_data".
+#ifdef CONFIG_BLK_DEV_ZONED
+struct nvme_za_emul {
+ unsigned int nr_zones;
+ spinlock_t zones_wp_offset_lock;
+ u32 *zones_wp_offset;
+ u32 *rev_wp_offset;
+ struct work_struct zone_wp_offset_work;
+ char *zone_wp_update_buf;
+ struct mutex rev_mutex;
+ struct nvme_ns *ns;
+};
+#endif
Will that be an acceptable line of further work/discussions?
I know we spent time enabling this path, but I don't think that moving
the discussion to the block layer will have much more benefit.
Let's keep the support for these non-append devices in xNVMe and focus
on the support for the append-enabled ones in Linux. We have a lot of
good stuff in the backlog that we can start pushing.
Re: [PATCH 11/12] regulator: stm32-vrefbuf: Fix W=1 build warning when CONFIG_OF=n
On 8/20/20 9:46 AM, Jisheng Zhang wrote:
> Fix below warning when CONFIG_OF=n:
>
> drivers/regulator/stm32-vrefbuf.c:287:34: warning: ‘stm32_vrefbuf_of_match’
> defined but not used [-Wunused-const-variable=]
> 287 | static const struct of_device_id stm32_vrefbuf_of_match[] = {
> | ^~
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/regulator/stm32-vrefbuf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/regulator/stm32-vrefbuf.c
> b/drivers/regulator/stm32-vrefbuf.c
> index 992bc18101ef..5a5c12d9ea22 100644
> --- a/drivers/regulator/stm32-vrefbuf.c
> +++ b/drivers/regulator/stm32-vrefbuf.c
> @@ -284,11 +284,13 @@ static const struct dev_pm_ops stm32_vrefbuf_pm_ops = {
> NULL)
> };
>
> +#ifdef CONFIG_OF
Hi Jisheng,
You could probably adopt "__maybe_unused" here ? E.g. like:
static const struct of_device_id __maybe_unused stm32_vrefbuf_of_match[] = {
I can see other drivers use this already for the same.
Thanks,
Best regards,
Fabrice
> static const struct of_device_id stm32_vrefbuf_of_match[] = {
> { .compatible = "st,stm32-vrefbuf", },
> {},
> };
> MODULE_DEVICE_TABLE(of, stm32_vrefbuf_of_match);
> +#endif
>
> static struct platform_driver stm32_vrefbuf_driver = {
> .probe = stm32_vrefbuf_probe,
>
Re: [PATCH STABLE 4.9] mm: Avoid calling build_all_zonelists_init under hotplug context
On Tue, Aug 18, 2020 at 02:24:46PM +0200, Michal Hocko wrote:
> On Tue 18-08-20 13:00:46, Oscar Salvador wrote:
> > Recently a customer of ours experienced a crash when booting the
> > system while enabling memory-hotplug.
> >
> > The problem is that Normal zones on different nodes don't get their private
> > zone->pageset allocated, and keep sharing the initial boot_pageset.
> > The sharing between zones is normally safe as explained by the comment for
> > boot_pageset - it's a percpu structure, and manipulations are done with
> > disabled interrupts, and boot_pageset is set up in a way that any page
> > placed
> > on its pcplist is immediately flushed to shared zone's freelist, because
> > pcp->high == 1.
> > However, the hotplug operation updates pcp->high to a higher value as it
> > expects to be operating on a private pageset.
> >
> > The problem is in build_all_zonelists(), which is called when the first
> > range
> > of pages is onlined for the Normal zone of node X or Y:
> >
> > if (system_state == SYSTEM_BOOTING) {
> > build_all_zonelists_init();
> > } else {
> > #ifdef CONFIG_MEMORY_HOTPLUG
> > if (zone)
> > setup_zone_pageset(zone);
> > #endif
> > /* we have to stop all cpus to guarantee there is no user
> > of zonelist */
> > stop_machine(__build_all_zonelists, pgdat, NULL);
> > /* cpuset refresh routine should be here */
> > }
> >
> > When called during hotplug, it should execute the setup_zone_pageset(zone)
> > which allocates the private pageset.
> > However, with memhp_default_state=online, this happens early while
> > system_state == SYSTEM_BOOTING is still true, hence this step is skipped.
> > (and build_all_zonelists_init() is probably unsafe anyway at this point).
> >
> > Another hotplug operation on the same zone then leads to
> > zone_pcp_update(zone)
> > called from online_pages(), which updates the pcp->high for the shared
> > boot_pageset to a value higher than 1.
> > At that point, pages freed from Node X and Y Normal zones can end up on the
> > same
> > pcplist and from there they can be freed to the wrong zone's freelist,
> > leading to the corruption and crashes.
> >
> > Please, note that upstream has fixed that differently (and unintentionally)
> > by
> > adding another boot state (SYSTEM_SCHEDULING), which is set before
> > smp_init().
> > That should happen before memory hotplug events even with
> > memhp_default_state=online.
> > Backporting that would be too intrusive.
> >
> > Signed-off-by: Oscar Salvador
> > Debugged-by: Vlastimil Babka
>
> Yes, I believe this is the easiest and the least scary way to fix the
> issue for stable kernel users. Feel free to add
> Acked-by: Michal Hocko # for stable trees
>
> for that purpose.
Now queued up, thanks!
greg k-h
Re: fixing 4.14-stable's broken DM cache writethrough support [was: Re: [(resend) PATCH v3: {linux-4.14.y} ] dm cache: submit writethrough writes in parallel to origin and cache]
On Wed, Aug 05, 2020 at 03:34:09PM -0400, Mike Snitzer wrote: > On Wed, Aug 05 2020 at 10:32am -0400, > Greg KH wrote: > > > On Tue, Aug 04, 2020 at 02:20:38PM -0400, Mike Snitzer wrote: > > > On Tue, Aug 04 2020 at 8:47am -0400, > > > Greg KH wrote: > > > > > > > On Tue, Aug 04, 2020 at 07:33:05AM -0500, John Donnelly wrote: > > > > > From: Mike Snitzer > > > > > > > > > > Discontinue issuing writethrough write IO in series to the origin and > > > > > then cache. > > > > > > > > > > Use bio_clone_fast() to create a new origin clone bio that will be > > > > > mapped to the origin device and then bio_chain() it to the bio that > > > > > gets > > > > > remapped to the cache device. The origin clone bio does _not_ have a > > > > > copy of the per_bio_data -- as such check_if_tick_bio_needed() will > > > > > not > > > > > be called. > > > > > > > > > > The cache bio (parent bio) will not complete until the origin bio has > > > > > completed -- this fulfills bio_clone_fast()'s requirements as well as > > > > > the requirement to not complete the original IO until the write IO has > > > > > completed to both the origin and cache device. > > > > > > > > > > Signed-off-by: Mike Snitzer > > > > > > > > > > (cherry picked from commit 2df3bae9a6543e90042291707b8db0cbfbae9ee9) > > > > > > > > > > Fixes: 4ec34f2196d125ff781170ddc6c3058c08ec5e73 (dm bio record: > > > > > save/restore bi_end_io and bi_integrity ) > > > > > > > > > > 4ec34f21 introduced a mkfs.ext4 hang on a LVM device that has been > > > > > modified with lvconvert --cachemode=writethrough. > > > > > > > > > > CC:sta...@vger.kernel.org for 4.14.y > > > > > > > > > > Signed-off-by: John Donnelly > > > > > Reviewed-by: Somasundaram Krishnasamy > > > > > > > > > > > > > > > conflicts: > > > > > drivers/md/dm-cache-target.c. - Corrected usage of > > > > > writethrough_mode(&cache->feature) that was caught by > > > > > compiler, and removed unused static functions : > > > > > writethrough_endio(), > > > > > defer_writethrough_bio(), wake_deferred_writethrough_worker() > > > > > that generated warnings. > > > > > > > > What is this "conflicts nonsense"? You don't see that in any other > > > > kernel patch changelog, do you? > > > > > > > > > --- > > > > > drivers/md/dm-cache-target.c | 92 > > > > > ++-- > > > > > 1 file changed, 37 insertions(+), 55 deletions(-) > > > > > > > > Please fix your email client up, it's totally broken and this does not > > > > work at all and is getting frustrating from my side here. > > > > > > > > Try sending emails to yourself and see if you can apply the patches, as > > > > the one you sent here does not work, again: > > > > > > John's inability to submit a patch that can apply aside: I do not like > > > how this patch header is constructed (yet attributed "From" me). It is > > > devoid of detail as it relates to stable@. > > > > > > Greg, please don't apply the v4 of this patch either. I'll craft a > > > proper stable@ patch that explains the reason for change and why we're > > > left having to resolve conflicts in stable@. > > > > > > But first I need to focus on sending DM changes to Linus for v5.9 merge. > > > > Ok, no worries, I'll drop all of these from my review queue and wait for > > something from you sometime in the future. > > Hey Greg, > > SO I've looked this required 4.14 stable@ backport over. Because 4.14 > already has these commits (to fix a dm integrity issue): > 1b17159e52b dm bio record: save/restore bi_end_io and bi_integrity > 248aa2645aa dm integrity: use dm_bio_record and dm_bio_restore > > DM-cache's 4.14 writethrough mode got broken because its implementation > (ab)used dm_hook_bio+dm_bio_record and predates 4.15's switch to using > bio_chain() via commit 2df3bae9a654. Without commit 2df3bae9a654 the > dm_hook_bio+dm_bio_record changes from commit 1b17159e52b break > dm-cache's writethrough support. > > So 4.14-stable now needs these 3 upstream 4.15 commits: > 8e3c3827776f dm cache: pass cache structure to mode functions > 2df3bae9a654 dm cache: submit writethrough writes in parallel to origin and > cache > 9958f1d9a04e dm cache: remove all obsolete writethrough-specific code > > Applying those commits to v4.14.190 with: > git cherry-pick -x 8e3c3827776f^..9958f1d9a04e > > results in a kernel that successfully builds and should fix > 4.14-stable's broken dm-cache writethrough support. > > Are you ok with queueing up applying these 3 upstream commits to > 4.14-stable or do you need me to send a patchset? This is good enough, now all queued up, thanks! greg k-h
[PATCH v2] lib/fonts: add font 6x8 for OLED display
From: Sven Schneider
This font is derived from lib/fonts/font_6x10.c and is useful for small
OLED displays
Signed-off-by: Sven Schneider
Signed-off-by: Sascha Hauer
---
Changes since v1:
- re-added lost Signed-off-by lines
- do not mode change include/linux/font.h to 0755
- Add SPDX tag
- Whitespace cleanup
include/linux/font.h |4 +-
lib/fonts/Kconfig|7 +
lib/fonts/Makefile |1 +
lib/fonts/font_6x8.c | 2576 ++
lib/fonts/fonts.c|3 +
5 files changed, 2590 insertions(+), 1 deletion(-)
create mode 100644 lib/fonts/font_6x8.c
diff --git a/include/linux/font.h b/include/linux/font.h
index 51b91c8b69d58..4a3f8741bb7e5 100644
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -33,6 +33,7 @@ struct font_desc {
#defineMINI4x6_IDX 9
#define FONT6x10_IDX 10
#define TER16x32_IDX 11
+#define FONT6x8_IDX12
extern const struct font_desc font_vga_8x8,
font_vga_8x16,
@@ -45,7 +46,8 @@ extern const struct font_desc font_vga_8x8,
font_acorn_8x8,
font_mini_4x6,
font_6x10,
- font_ter_16x32;
+ font_ter_16x32,
+ font_6x8;
/* Find a font with a specific name */
diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 37baa79cdd71f..c035fde66aebe 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -119,6 +119,12 @@ config FONT_TER16x32
This is the high resolution, large version for use with HiDPI screens.
If the standard font is unreadable for you, say Y, otherwise say N.
+config FONT_6x8
+ bool "OLED 6x8 font" if FONTS
+ depends on FRAMEBUFFER_CONSOLE
+ help
+ This font is useful for small displays (OLED).
+
config FONT_AUTOSELECT
def_bool y
depends on !FONT_8x8
@@ -132,6 +138,7 @@ config FONT_AUTOSELECT
depends on !FONT_SUN12x22
depends on !FONT_10x18
depends on !FONT_TER16x32
+ depends on !FONT_6x8
select FONT_8x16
endif # FONT_SUPPORT
diff --git a/lib/fonts/Makefile b/lib/fonts/Makefile
index ed95070860deb..e16f68492174a 100644
--- a/lib/fonts/Makefile
+++ b/lib/fonts/Makefile
@@ -15,6 +15,7 @@ font-objs-$(CONFIG_FONT_ACORN_8x8) += font_acorn_8x8.o
font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
font-objs-$(CONFIG_FONT_6x10) += font_6x10.o
font-objs-$(CONFIG_FONT_TER16x32) += font_ter16x32.o
+font-objs-$(CONFIG_FONT_6x8) += font_6x8.o
font-objs += $(font-objs-y)
diff --git a/lib/fonts/font_6x8.c b/lib/fonts/font_6x8.c
new file mode 100644
index 0..e064477884186
--- /dev/null
+++ b/lib/fonts/font_6x8.c
@@ -0,0 +1,2576 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+
+#define FONTDATAMAX 2048
+
+static const unsigned char fontdata_6x8[FONTDATAMAX] = {
+
+ /* 0 0x00 '^@' */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 1 0x01 '^A' */
+ 0x78, /* 00 */
+ 0x84, /* 11 */
+ 0xCC, /* 110011 */
+ 0x84, /* 11 */
+ 0xCC, /* 110011 */
+ 0xB4, /* 101101 */
+ 0x78, /* 00 */
+ 0x00, /* 00 */
+
+ /* 2 0x02 '^B' */
+ 0x78, /* 00 */
+ 0xFC, /* 11 */
+ 0xB4, /* 101101 */
+ 0xFC, /* 11 */
+ 0xB4, /* 101101 */
+ 0xCC, /* 110011 */
+ 0x78, /* 00 */
+ 0x00, /* 00 */
+
+ /* 3 0x03 '^C' */
+ 0x00, /* 00 */
+ 0x28, /* 001010 */
+ 0x7C, /* 01 */
+ 0x7C, /* 01 */
+ 0x38, /* 001110 */
+ 0x10, /* 000100 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 4 0x04 '^D' */
+ 0x00, /* 00 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x7C, /* 01 */
+ 0x38, /* 001110 */
+ 0x10, /* 000100 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 5 0x05 '^E' */
+ 0x00, /* 00 */
+ 0x38, /* 001110 */
+ 0x38, /* 001110 */
+ 0x6C, /* 011011 */
+ 0x6C, /* 011011 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x00, /* 00 */
+
+ /* 6 0x06 '^F' */
+ 0x00, /* 00 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x7C, /* 01 */
+ 0x7C, /* 01 */
+ 0x10, /* 000100 */
+ 0x38, /* 001110 */
+ 0x00, /* 00 */
+
+ /* 7 0x07 '^G' */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x30, /* 001100 */
+ 0x78, /* 00 */
+ 0x30, /* 001100 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+ 0x00, /* 00 */
+
+ /* 8 0x08 '^H' */
+ 0xFC, /* 11 */
+ 0xFC, /* 11 */
+ 0xCC, /* 110011 */
+ 0x84, /* 11 */
+
Re: linux-next: Fixes tag needs some work in the tip tree
On Thu, Aug 20, 2020 at 04:12:39PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 71aefb9a89d4 ("RAS/CEC: Fix cec_init() prototype")
>
> Fixes tag
>
> Fixes: 9554bfe403nd ("x86/mce: Convert the CEC to use the MCE notifier")
Hmm, this came from the original patch submission:
https://lkml.kernel.org/r/20200805095708.83939-1-luca.stefani@gmail.com
the 'n' is already there.
> has these problem(s):
>
> - The SHA1 is not all hex
If your script which verifies that is in python, per chance, you could
give it to me so that I can add it to my patch massaging script. :-)
I have no Fixes: tags sanity checks so far and have never considered
that they could possibly be wrong but this here is a case-in-point
example.
I guess I'd need also an "is the commit ID an actual upstream commit ID"
check, while at it.
> Presumably
>
> Fixes: 9554bfe403bd ("x86/mce: Convert the CEC to use the MCE notifier")
Fixing...
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG
Nürnberg
Re: [PATCH 25/49] staging: hikey9xx/gpu: do some code cleanups
(added c/c Rob Herring)
Em Wed, 19 Aug 2020 18:53:06 -0700
John Stultz escreveu:
> On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> wrote:
> > @@ -376,7 +355,7 @@ static int kirin_drm_platform_resume(struct
> > platform_device *pdev)
> > }
> >
> > static const struct of_device_id kirin_drm_dt_ids[] = {
> > - { .compatible = "hisilicon,hi3660-dpe",
> > + { .compatible = "hisilicon,kirin960-dpe",
>
>
> One issue, elsewhere in your patch stack you still refer to the
> hisilicon,hi3660-dpe compatible string. This should probably be
> consistent one way or the other.
Agreed with regards to consistency.
It sounds to me that calling those as Kirin 9xx (and the previous one
as Kirin 620) is better than using the part number.
Here, googling for "Kirin 970" gave about 6.9 million hits, while "Hi3670"
gave only 75,5K hits.
Kirin 620 has similar results: 6.85 million hits, against 61,9 hits
for "Hi3620".
With "Kirin 960", the numbers are a lot higher: had 21,4 million hits,
against 423K hits for "Hi3660".
So, my preference is to use "Kirin 620, 960 and 970" for future changes.
-
Currently, there are already some inconsistency, as some places
use the part number where others use "Kirin xxx" designation,
when referring to Kirin 620, 960 and 970.
I would love to make this consistent among the Kernel. However,
I'm not sure if changing "compatible" would be acceptable
by DT maintainers.
If something like that would be OK, I can prepare a separate
patchset to be applied at the Kernel.
Thanks,
Mauro
Re: [net-next v4 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices
Hi Andrew, On Fri, Aug 14, 2020 at 03:18:15PM +0200, Andrew Lunn wrote: > > > > Currently > > > > > > > > compatible = "marvell,prestera" > > > > > > > > is used as default, so may be > > > > > > > > you mean to support few matching including particular silicon too, like > > > > ? > > > > > > > > > > > > compatible = "marvell,prestera" > > > > compatible = "marvell,prestera-ac3x" > > > > > > > > Would you please give an example ? > > > > > > AFAICT "Prestera" is the general name for the Marvell > > > enterprise/data-centre silicon, comparable to the "LinkStreet" > > > designation for their lower end switching. The mv88e* drivers do not > > > mention LinkStreet in their compatible strings at all, choosing instead > > > to refer to chip IDs (I see mv88e6085, mv88e6190 + mv88e6250). > > > > > > I do not have enough familiarity with the Prestera range to be able to > > > tell what commonality there is between the different versions (it > > > appears you need an NDA to get hold of the programming references), but > > > even just looking at your driver and the vendor code for the BobCat it > > > seems that AlleyCat3 uses an extended DSA header format, and requires a > > > firmware with message based access, in comparison to the BobCat which > > > uses register poking. > > > > > > Based on that I'd recommend not using the bare "marvell,prestera" > > > compatible string, but instead something more specific. > > > "marvell,prestera-ac3x" seems like a suitable choice, assuming that's > > > how these chips are named/generally referred to. > > > > > > Also I'd expand your Kconfig information to actually include "Marvell > > > Prestera 98DX326x" as that's the only supported chip range at present. > > > > > > > Yes, Prestera covers more range of devices. But it is planning to cover > > other devices too, and currently there is no device-specific DTS > > properties which are used in this version, but only the generic one - > > since only the MAC address node. > > > > I mean that if there will be other Prestera devices supported then it > > will require to extend the DTS matching string in the driver just to > > support the same generic DTS properties for new device. > > > > Anyway I will rise and discuss this question. > > Hi Vadym > > Lets start with how mv88e6xxx does this. The switches have ID > registers. Once you have read the ID registers, you know what device > you have, and you can select device specific code as needed. However, > these ID registers are in three different locations, depending on the > chip family. So the compatible string is all about where to read the > ID from, not about what specific chip is. So most device tree bindings > say "marvell,mv88e6085", but the 6390 family use "marvell,mv88e6190" > for example. > > This naming scheme is actually odd compared to others. And that > oddness causes confusion. But it avoids a few problems. If you have > per chip compatible strings, what do you do when it conflicts with the > ID registers. If from day 1 you validate the compatible string against > the ID register and fail the probe if it is incorrect, you are > O.K. But if you decide to add this validation later, you are going to > find a number of device tree blobs which have the wrong compatible > string. Do you fail the probe on boards which have worked? > > So what to do with this driver? > > Does the prestera have ID registers? Are you using them in the driver? > ASIC device specific handling is serviced by the firmware, current driver's logic does not have PP specific code and relies on the FW ABI which is PP-generic, and it looks like this how it should work for boards with other ASICs, of course these boards should follow the Marvell's Switchdev board design. > Marvell is not particularly good at backwards compatibility. Does your > compatible string give you enough wiggle room you can easily introduce > another compatible string in order to find the ID registers when they > move? > > Andrew
[PATCH] iio: Fixed IIO_VAL_FRACTIONAL calcuation for negative values
This patch fixes IIO_VAL_FRACTIONAL calculation for negative
values where the exponent is 0.
Signed-off-by: Anand Ashok Dumbre
---
drivers/iio/industrialio-core.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index f72c2dc..cd43b17 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -554,6 +554,7 @@ static ssize_t __iio_format_value(char *buf, size_t len,
unsigned int type,
{
unsigned long long tmp;
int tmp0, tmp1;
+ s64 tmp2;
bool scale_db = false;
switch (type) {
@@ -576,10 +577,13 @@ static ssize_t __iio_format_value(char *buf, size_t len,
unsigned int type,
else
return snprintf(buf, len, "%d.%09u", vals[0], vals[1]);
case IIO_VAL_FRACTIONAL:
- tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
+ tmp2 = div_s64((s64)vals[0] * 10LL, vals[1]);
tmp1 = vals[1];
- tmp0 = (int)div_s64_rem(tmp, 10, &tmp1);
- return snprintf(buf, len, "%d.%09u", tmp0, abs(tmp1));
+ tmp0 = (int)div_s64_rem(tmp2, 10, &tmp1);
+ if ((tmp2 < 0) && (tmp0 == 0))
+ return snprintf(buf, len, "-%d.%09u", tmp0, abs(tmp1));
+ else
+ return snprintf(buf, len, "%d.%09u", tmp0, abs(tmp1));
case IIO_VAL_FRACTIONAL_LOG2:
tmp = shift_right((s64)vals[0] * 10LL, vals[1]);
tmp0 = (int)div_s64_rem(tmp, 10LL, &tmp1);
--
2.7.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
Re: [PATCH 11/12] regulator: stm32-vrefbuf: Fix W=1 build warning when CONFIG_OF=n
On Thu, 20 Aug 2020 10:13:12 +0200 Fabrice Gasnier wrote:
>
>
> On 8/20/20 9:46 AM, Jisheng Zhang wrote:
> > Fix below warning when CONFIG_OF=n:
> >
> > drivers/regulator/stm32-vrefbuf.c:287:34: warning: ‘stm32_vrefbuf_of_match’
> > defined but not used [-Wunused-const-variable=]
> > 287 | static const struct of_device_id stm32_vrefbuf_of_match[] = {
> > | ^~
> >
> > Signed-off-by: Jisheng Zhang
> > ---
> > drivers/regulator/stm32-vrefbuf.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/regulator/stm32-vrefbuf.c
> > b/drivers/regulator/stm32-vrefbuf.c
> > index 992bc18101ef..5a5c12d9ea22 100644
> > --- a/drivers/regulator/stm32-vrefbuf.c
> > +++ b/drivers/regulator/stm32-vrefbuf.c
> > @@ -284,11 +284,13 @@ static const struct dev_pm_ops stm32_vrefbuf_pm_ops =
> > {
> > NULL)
> > };
> >
> > +#ifdef CONFIG_OF
>
> Hi Jisheng,
Hi,
>
> You could probably adopt "__maybe_unused" here ? E.g. like:
__maybe_unused also fixes the warning. I'm not sure the maintainers' preference.
Hi Mark,
which solution do you prefer?
Thanks in advance
>
> static const struct of_device_id __maybe_unused stm32_vrefbuf_of_match[] = {
>
> I can see other drivers use this already for the same.
>
> Thanks,
> Best regards,
> Fabrice
>
> > static const struct of_device_id stm32_vrefbuf_of_match[] = {
> > { .compatible = "st,stm32-vrefbuf", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, stm32_vrefbuf_of_match);
> > +#endif
> >
> > static struct platform_driver stm32_vrefbuf_driver = {
> > .probe = stm32_vrefbuf_probe,
> >
Re: [Cocci] coccinelle: Convert comma to semicolons (was Re: [PATCH] checkpatch: Add test for comma use that should be semicolon)
On Wed, 19 Aug 2020, Joe Perches wrote: > On Wed, 2020-08-19 at 14:22 -0700, Joe Perches wrote: > > There are commas used as statement terminations that should typically > > have used semicolons instead. Only direct assignments or use of a single > > function or value on a single line are detected by this test. > > > > e.g.: > > foo = bar(),/* typical use is semicolon not comma */ > > bar = baz(); > > > > Add an imperfect test to detect these comma uses. > > > > No false positives were found in testing, but many types of false negatives > > are possible. > > > > e.g.: > > foo = bar() + 1,/* comma use, but not direct assignment */ > > bar = baz(); > > Hi. > > I recently added a test for this condition to linux's checkpatch. > > A similar coccinelle script might be: > > $ cat comma.cocci > @@ > expression e1; > expression e2; > @@ > > e1 > - , > + ; > e2; > $ > > This works reasonably well but it has several false positives > for declarations like: > > $ spatch --sp-file comma.cocci mm/huge_memory.c > diff -u -p a/huge_memory.c b/huge_memory.c > --- a/huge_memory.c > +++ b/huge_memory.c > @@ -2778,7 +2778,7 @@ static unsigned long deferred_split_scan > struct pglist_data *pgdata = NODE_DATA(sc->nid); > struct deferred_split *ds_queue = &pgdata->deferred_split_queue; > unsigned long flags; > - LIST_HEAD(list), *pos, *next; > + LIST_HEAD(list), *pos; *next; > struct page *page; > int split = 0; > $ > > Any script improvement suggestions? I have a bunch of variations of this that are more complicated than I would have expected. One shorter variant that I have is: @@ expression e1,e2; statement S; @@ S e1 -, +; (<+... e2 ...+>); This will miss cases where the first statement is the comma thing. But I think it is possible to improve this now. I will check. thanks, julia
[tip: ras/core] x86/MCE/AMD, EDAC/mce_amd: Remove struct smca_hwid.xec_bitmap
The following commit has been merged into the ras/core branch of tip:
Commit-ID: 368d1887200d68075c064a62a9aa191168cf1eed
Gitweb:
https://git.kernel.org/tip/368d1887200d68075c064a62a9aa191168cf1eed
Author:Yazen Ghannam
AuthorDate:Mon, 20 Jul 2020 14:53:53
Committer: Borislav Petkov
CommitterDate: Thu, 20 Aug 2020 10:34:38 +02:00
x86/MCE/AMD, EDAC/mce_amd: Remove struct smca_hwid.xec_bitmap
The Extended Error Code Bitmap (xec_bitmap) for a Scalable MCA bank type
was intended to be used by the kernel to filter out invalid error codes
on a system. However, this is unnecessary after a few product releases
because the hardware will only report valid error codes. Thus, there's
no need for it with future systems.
Remove the xec_bitmap field and all references to it.
Signed-off-by: Yazen Ghannam
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20200720145353.43924-1-yazen.ghan...@amd.com
---
arch/x86/include/asm/mce.h| 1 +-
arch/x86/kernel/cpu/mce/amd.c | 44 +-
drivers/edac/mce_amd.c| 4 +---
3 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index cf50382..6adced6 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -328,7 +328,6 @@ enum smca_bank_types {
struct smca_hwid {
unsigned int bank_type; /* Use with smca_bank_types for easy indexing.
*/
u32 hwid_mcatype; /* (hwid,mcatype) tuple */
- u32 xec_bitmap; /* Bitmap of valid ExtErrorCodes; current max
is 21. */
u8 count; /* Number of instances. */
};
diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index 99be063..0c6b02d 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -132,49 +132,49 @@ static enum smca_bank_types smca_get_bank_type(unsigned
int bank)
}
static struct smca_hwid smca_hwid_mcatypes[] = {
- /* { bank_type, hwid_mcatype, xec_bitmap } */
+ /* { bank_type, hwid_mcatype } */
/* Reserved type */
- { SMCA_RESERVED, HWID_MCATYPE(0x00, 0x0), 0x0 },
+ { SMCA_RESERVED, HWID_MCATYPE(0x00, 0x0)},
/* ZN Core (HWID=0xB0) MCA types */
- { SMCA_LS, HWID_MCATYPE(0xB0, 0x0), 0x1F },
- { SMCA_LS_V2,HWID_MCATYPE(0xB0, 0x10), 0xFF },
- { SMCA_IF, HWID_MCATYPE(0xB0, 0x1), 0x3FFF },
- { SMCA_L2_CACHE, HWID_MCATYPE(0xB0, 0x2), 0xF },
- { SMCA_DE, HWID_MCATYPE(0xB0, 0x3), 0x1FF },
+ { SMCA_LS, HWID_MCATYPE(0xB0, 0x0)},
+ { SMCA_LS_V2,HWID_MCATYPE(0xB0, 0x10) },
+ { SMCA_IF, HWID_MCATYPE(0xB0, 0x1)},
+ { SMCA_L2_CACHE, HWID_MCATYPE(0xB0, 0x2)},
+ { SMCA_DE, HWID_MCATYPE(0xB0, 0x3)},
/* HWID 0xB0 MCATYPE 0x4 is Reserved */
- { SMCA_EX, HWID_MCATYPE(0xB0, 0x5), 0xFFF },
- { SMCA_FP, HWID_MCATYPE(0xB0, 0x6), 0x7F },
- { SMCA_L3_CACHE, HWID_MCATYPE(0xB0, 0x7), 0xFF },
+ { SMCA_EX, HWID_MCATYPE(0xB0, 0x5)},
+ { SMCA_FP, HWID_MCATYPE(0xB0, 0x6)},
+ { SMCA_L3_CACHE, HWID_MCATYPE(0xB0, 0x7)},
/* Data Fabric MCA types */
- { SMCA_CS, HWID_MCATYPE(0x2E, 0x0), 0x1FF },
- { SMCA_PIE, HWID_MCATYPE(0x2E, 0x1), 0x1F },
- { SMCA_CS_V2,HWID_MCATYPE(0x2E, 0x2), 0x3FFF },
+ { SMCA_CS, HWID_MCATYPE(0x2E, 0x0)},
+ { SMCA_PIE, HWID_MCATYPE(0x2E, 0x1)},
+ { SMCA_CS_V2,HWID_MCATYPE(0x2E, 0x2)},
/* Unified Memory Controller MCA type */
- { SMCA_UMC, HWID_MCATYPE(0x96, 0x0), 0xFF },
+ { SMCA_UMC, HWID_MCATYPE(0x96, 0x0)},
/* Parameter Block MCA type */
- { SMCA_PB, HWID_MCATYPE(0x05, 0x0), 0x1 },
+ { SMCA_PB, HWID_MCATYPE(0x05, 0x0)},
/* Platform Security Processor MCA type */
- { SMCA_PSP, HWID_MCATYPE(0xFF, 0x0), 0x1 },
- { SMCA_PSP_V2, HWID_MCATYPE(0xFF, 0x1), 0x3 },
+ { SMCA_PSP, HWID_MCATYPE(0xFF, 0x0)},
+ { SMCA_PSP_V2, HWID_MCATYPE(0xFF, 0x1)},
/* System Management Unit MCA type */
- { SMCA_SMU, HWID_MCATYPE(0x01, 0x0), 0x1 },
- { SMCA_SMU_V2, HWID_MCATYPE(0x01, 0x1), 0x7FF },
+ { SMCA_SMU, HWID_MCATYPE(0x01, 0x0)},
+ { SMCA_SMU_V2, HWID_MCATYPE(0x01, 0x1)},
/* Microprocessor 5 Unit MCA type */
- { SMCA_MP5, HWID_MCATYPE(0x01, 0x2), 0x3FF },
+ { SMCA_MP5, HWID_MCATYPE(0x01, 0x2)},
/* Northbridge IO Unit MCA type */
- { SMCA_NBIO, HWID_MCATYPE(0x18, 0x0), 0x1F },
+ { SMCA_NBIO, HWID_MCATYPE(0x18, 0x0)},
/* PCI Express Unit MCA type */
- { SMCA_PCIE, HWID_MCATYPE(0x46, 0x0), 0x1F },
+
[tip: ras/core] RAS/CEC: Fix cec_init() prototype
The following commit has been merged into the ras/core branch of tip:
Commit-ID: 85e6084e0b436cabe9c909e679937998ffbf9c9d
Gitweb:
https://git.kernel.org/tip/85e6084e0b436cabe9c909e679937998ffbf9c9d
Author:Luca Stefani
AuthorDate:Wed, 05 Aug 2020 11:57:08 +02:00
Committer: Borislav Petkov
CommitterDate: Thu, 20 Aug 2020 10:33:33 +02:00
RAS/CEC: Fix cec_init() prototype
late_initcall() expects a function that returns an integer. Update the
function signature to match.
[ bp: Massage commit message into proper sentences. ]
Fixes: 9554bfe403bd ("x86/mce: Convert the CEC to use the MCE notifier")
Signed-off-by: Luca Stefani
Signed-off-by: Borislav Petkov
Reviewed-by: Sami Tolvanen
Tested-by: Sami Tolvanen
Link:
https://lkml.kernel.org/r/20200805095708.83939-1-luca.stefani@gmail.com
---
drivers/ras/cec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index 569d9ad..6939aa5 100644
--- a/drivers/ras/cec.c
+++ b/drivers/ras/cec.c
@@ -553,20 +553,20 @@ static struct notifier_block cec_nb = {
.priority = MCE_PRIO_CEC,
};
-static void __init cec_init(void)
+static int __init cec_init(void)
{
if (ce_arr.disabled)
- return;
+ return -ENODEV;
ce_arr.array = (void *)get_zeroed_page(GFP_KERNEL);
if (!ce_arr.array) {
pr_err("Error allocating CE array page!\n");
- return;
+ return -ENOMEM;
}
if (create_debugfs_nodes()) {
free_page((unsigned long)ce_arr.array);
- return;
+ return -ENOMEM;
}
INIT_DELAYED_WORK(&cec_work, cec_work_fn);
@@ -575,6 +575,7 @@ static void __init cec_init(void)
mce_register_decode_chain(&cec_nb);
pr_info("Correctable Errors collector initialized.\n");
+ return 0;
}
late_initcall(cec_init);
Re: [REGRESSION 5.8] x86/entry: DR0 break-on-write not working
On Wed, Aug 19, 2020 at 10:46:36PM -0500, Josh Poimboeuf wrote: > On Wed, Aug 19, 2020 at 05:14:18PM -0700, Andy Lutomirski wrote: > > I'm pretty sure you have the buggy sequence of events right, but for > > the wrong reason. There's nothing wrong with scheduling when > > delivering SIGTRAP, but it's definitely wrong to blindly save and > > restore DR7 around scheduling and around ptrace invocations. Remember > > this is an entry from user mode, so it runs on the user stack. *groan*, yeah that's broken :/ > Wow, I had no idea user #DB's run on the task stack. The scheduling > from #DB blew my mind :-) What's the purpose of that? At the very least that vm86 junk needs to I think. Also -RT needs it to send signals.
Re: linux-next: boot failure after merge of the dma-mapping tree
Hi Stephen, On Thu, Aug 20, 2020 at 03:51:12PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the dma-mapping tree, today's linux-next build (powerpc > pseries_le_defconfig) failed like this: > > [1.829053][T1] [ cut here ] > [1.829629][T1] kernel BUG at include/linux/iommu-helper.h:21! > [1.830182][T1] Oops: Exception in kernel mode, sig: 5 [#1] > [1.830302][T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > [1.830436][T1] Modules linked in: > [1.830879][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc1 #2 > [1.831042][T1] NIP: c06f4944 LR: c06f4924 CTR: > c004aa10 > [1.831174][T1] REGS: c0007e3a31e0 TRAP: 0700 Not tainted > (5.9.0-rc1) > [1.831243][T1] MSR: 82029033 CR: > 44022422 XER: 2000 > [1.831574][T1] CFAR: c06b3084 IRQMASK: 1 > [1.831574][T1] GPR00: c06f4924 c0007e3a3470 > c1289000 0001 > [1.831574][T1] GPR04: 0003 > 0040 > [1.831574][T1] GPR08: 0001 > fffe c00c > [1.831574][T1] GPR12: 24028420 c14b > c0007e9cd000 0001 > [1.831574][T1] GPR16: > c0007e9cd100 c0007e9cd118 > [1.831574][T1] GPR20: > 0001 > [1.831574][T1] GPR24: > c0007eb2 > [1.831574][T1] GPR28: 0001 bfff > 0001 > [1.833145][T1] NIP [c06f4944] iommu_area_alloc+0xa4/0x170 > [1.833271][T1] LR [c06f4924] iommu_area_alloc+0x84/0x170 > [1.833494][T1] Call Trace: > [1.833686][T1] [c0007e3a3470] [c06f4924] > iommu_area_alloc+0x84/0x170 (unreliable) > [1.833961][T1] [c0007e3a34e0] [c004b034] > iommu_range_alloc+0x1a4/0x410 > [1.834116][T1] [c0007e3a35a0] [c004b650] > iommu_alloc+0x60/0x130 > [1.834248][T1] [c0007e3a35f0] [c004c6c8] > iommu_map_page+0xd8/0x210 > [1.834381][T1] [c0007e3a3680] [c004aa70] > dma_iommu_map_page+0x60/0x80 > [1.834502][T1] [c0007e3a36a0] [c01cce30] > dma_map_page_attrs+0x190/0x260 > [1.834628][T1] [c0007e3a3750] [c086195c] > ibmvscsi_probe+0x12c/0xa2c > [1.834768][T1] [c0007e3a3830] [c00e049c] > vio_bus_probe+0x9c/0x460 > [1.834880][T1] [c0007e3a38d0] [c07f2cbc] > really_probe+0x12c/0x4e0 > [1.834993][T1] [c0007e3a3970] [c07f3308] > driver_probe_device+0x88/0x120 > [1.835108][T1] [c0007e3a39a0] [c07f36ec] > device_driver_attach+0xcc/0xe0 > [1.835220][T1] [c0007e3a39e0] [c07f3780] > __driver_attach+0x80/0x140 > [1.835321][T1] [c0007e3a3a20] [c07ef9a8] > bus_for_each_dev+0xa8/0x130 > [1.835429][T1] [c0007e3a3a80] [c07f2394] > driver_attach+0x34/0x50 > [1.835534][T1] [c0007e3a3aa0] [c07f1878] > bus_add_driver+0x1e8/0x2b0 > [1.835647][T1] [c0007e3a3b30] [c07f47f8] > driver_register+0x98/0x1a0 > [1.835782][T1] [c0007e3a3ba0] [c00df4bc] > __vio_register_driver+0x4c/0x60 > [1.835938][T1] [c0007e3a3bc0] [c0f8d924] > ibmvscsi_module_init+0xa4/0xdc > [1.836056][T1] [c0007e3a3c00] [c0012430] > do_one_initcall+0x60/0x2b0 > [1.836175][T1] [c0007e3a3cd0] [c0f44740] > kernel_init_freeable+0x2e0/0x378 > [1.836287][T1] [c0007e3a3db0] [c0012a24] > kernel_init+0x2c/0x158 > [1.836509][T1] [c0007e3a3e20] [c000d9d0] > ret_from_kernel_thread+0x5c/0x6c > [1.836717][T1] Instruction dump: > [1.836904][T1] 2da9 f8010010 f821ff91 4bfbe669 6000 7c3d1840 > 7c7f1b78 40810074 > [1.837082][T1] 6000 6000 6000 40920010 <0fe0> > 6000 6000 408efff4 > [1.838497][T1] ---[ end trace e9dbc52052087399 ]--- > > The BUG is > > BUG_ON(!is_power_of_2(boundary_size)); > > in iommu_is_span_boundary() Took a quick look -- the boundary_size is seemingly passed from https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/powerpc/kernel/iommu.c#n240 boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, 1 << tbl->it_page_shift); Looks like an overflow happens due to (ULONG_MAX + 1). Should we fix here instead (or also)? Thanks Nic
[PATCH] dt-bindings: mfd: mediatek: Add bindings for MT6360 PMIC
From: Gene Chen
Add bindings for MT6360 PMIC
Signed-off-by: Gene Chen
---
Documentation/devicetree/bindings/mfd/mt6360.yaml | 142 ++
1 file changed, 142 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mt6360.yaml
diff --git a/Documentation/devicetree/bindings/mfd/mt6360.yaml
b/Documentation/devicetree/bindings/mfd/mt6360.yaml
new file mode 100644
index 000..5ad1afd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mt6360.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mt6360.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT6360 PMIC from MediaTek Integrated
+
+maintainers:
+ - Gene Chen
+
+description: |
+ MT6360 is a PMIC device with the following sub modules.
+ It is interfaced to host controller using I2C interface.
+
+ This document describes the binding for PMIC device and its sub module.
+
+properties:
+ compatible:
+const: mediatek,mt6360
+
+ reg:
+description:
+ I2C device address.
+maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+maxItems: 1
+
+ interrupt-names:
+ enum:
+- IRQB
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+const: 1
+description:
+ The first cell is the IRQ number.
+
+ regulator:
+$ref: ../regulator/mt6360-regulator.yaml
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mt6360@34 {
+compatible = "mediatek,mt6360";
+reg = <0x34>;
+wakeup-source;
+interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "IRQB";
+interrupt-controller;
+#interrupt-cells = <1>;
+regulator {
+compatible = "mediatek,mt6360-regulator";
+LDO_VIN3-supply = <&BUCK2>;
+buck1 {
+regulator-compatible = "BUCK1";
+regulator-name = "mt6360,buck1";
+regulator-min-microvolt = <30>;
+regulator-max-microvolt = <130>;
+regulator-allowed-modes = ;
+};
+BUCK2: buck2 {
+regulator-compatible = "BUCK2";
+regulator-name = "mt6360,buck2";
+regulator-min-microvolt = <30>;
+regulator-max-microvolt = <130>;
+regulator-allowed-modes = ;
+};
+ldo6 {
+regulator-compatible = "LDO6";
+regulator-name = "mt6360,ldo6";
+regulator-min-microvolt = <50>;
+regulator-max-microvolt = <210>;
+regulator-allowed-modes = ;
+};
+ldo7 {
+regulator-compatible = "LDO7";
+regulator-name = "mt6360,ldo7";
+regulator-min-microvolt = <50>;
+regulator-max-microvolt = <210>;
+regulator-allowed-modes = ;
+};
+ldo1 {
+regulator-compatible = "LDO1";
+regulator-name = "mt6360,ldo1";
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+};
+ldo2 {
+regulator-compatible = "LDO2";
+regulator-name = "mt6360,ldo2";
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+};
+ldo3 {
+regulator-compatible = "LDO3";
+regulator-name = "mt6360,ldo3";
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+};
+ldo5 {
+regulator-compatible = "LDO5";
+regulator-name = "mt6360,ldo5";
+regulator-min-microvolt = <270>;
+regulator-max-microvolt = <360>;
+regulator-allowed-modes = ;
+};
+};
+};
+};
--
2.7.4
Re: [PATCH v2] lib/fonts: add font 6x8 for OLED display
On Thu, Aug 20, 2020 at 10:21:37AM +0200, Sascha Hauer wrote: > From: Sven Schneider > > This font is derived from lib/fonts/font_6x10.c and is useful for small > OLED displays > > Signed-off-by: Sven Schneider > Signed-off-by: Sascha Hauer Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] x86/debug: Allow a single level of #DB recursion
On Wed, Aug 19, 2020 at 05:15:43PM -0700, Andy Lutomirski wrote:
> +static __always_inline void debug_enter(unsigned long *dr6, unsigned long
> *dr7)
> +{
> + *dr6 = debug_read_clear_dr6();
> }
>
> static __always_inline void debug_exit(unsigned long dr7)
> {
> - local_db_restore(dr7);
> }
That's all unused after this patch, might as well remove it.
Re: [patch 0/2] timekeeping: NMI safe timekeeper enhancements
On Fri 2020-08-14 12:19:33, Thomas Gleixner wrote:
> printk intends to store various timestamps (MONOTONIC, REALTIME, BOOTTIME)
> to make correlation of dmesg accross different machines easier.
>
> The NMI safe timekeeper allows to retrieve these timestamps from any
> context.
For both patches:
Tested-by: Petr Mladek
I am not familiar with the timekeeping code so that I could not
provide a valuable review. Anyway, the patches seem to work
as expected.
The interface is perfectly fine for printk() needs.
I tested them with the patch below. The first timestamps appear
as early as before:
[0.00] [0.00][1970-01-01T00:00:00][T0] kvm-clock: Using
msrs 4b564d01 and 4b564d00
[0.00] [0.00][1970-01-01T00:00:00][T0] kvm-clock: cpu 0,
msr 129c01001, primary cpu clock
[0.00] [0.00][1970-01-01T00:00:00][T0] kvm-clock: using
sched offset of 56519600356309 cycles
[0.08] [0.08][1970-01-01T00:00:00][T0] clocksource:
kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns:
881590591483 ns
[0.22] [0.22][1970-01-01T00:00:00][T0] tsc: Detected
2112.000 MHz processor
[0.000835] [0.000835][1970-01-01T00:00:00][T0] e820: update [mem
0x-0x0fff] usable ==> reserved
The realtime timestamps get ready later as expected:
[0.073075] [0.073075][1970-01-01T00:00:00][T0] rcu: Adjusting
geometry for rcu_fanout_leaf=16, nr_cpu_ids=3
[0.075847] [0.075847][1970-01-01T00:00:00][T0] NR_IRQS: 524544,
nr_irqs: 448, preallocated irqs: 16
[0.076014] [0.076014][2020-08-20T07:58:46][T0] Console: colour
dummy device 80x25
[0.076014] [0.076014][2020-08-20T07:58:46][T0] printk: console
[tty0] enabled
Also suspend resume seems to work as expected. I tested it the follwing way:
echo core > /sys/power/pm_test
echo reboot > /sys/power/disk
echo disk > /sys/power/state
and the result is:
[ 224.422540] [ 224.422540][2020-08-20T08:02:31][ T5124] Disabling non-boot
CPUs ...
[ 224.424171] [ 224.424171][2020-08-20T08:02:31][ T15] IRQ fixup: irq 21
move in progress, old vector 36
[ 224.425304] [ 224.425304][2020-08-20T08:02:31][ T5124] smpboot: CPU 1 is
now offline
[ 224.426664] [ 224.426664][2020-08-20T08:02:31][ T20] IRQ 21: no longer
affine to CPU2
[ 224.426685] [ 224.426685][2020-08-20T08:02:31][ T20] IRQ 24: no longer
affine to CPU2
[ 224.426717] [ 224.426717][2020-08-20T08:02:31][ T20] IRQ 27: no longer
affine to CPU2
[ 224.427765] [ 224.427765][2020-08-20T08:02:31][ T5124] smpboot: CPU 2 is
now offline
[ 224.428016] [ 224.428016][2020-08-20T08:02:31][ T5124] PM: hibernation:
debug: Waiting for 5 seconds.
[ 224.428218] [ 229.618141][2020-08-20T08:02:36][ T5124] Enabling non-boot
CPUs ...
^^^^^^ ^^
[ 224.428560] [ 229.618483][2020-08-20T08:02:36][ T5124] x86: Booting SMP
configuration:
[ 224.428564] [ 229.618486][2020-08-20T08:02:36][ T5124] smpboot: Booting
Node 0 Processor 1 APIC 0x1
[ 224.428766] [ 229.618688][2020-08-20T08:02:36][T0] kvm-clock: cpu 1,
msr 129c01041, secondary cpu clock
[ 224.449192] [ 229.639115][2020-08-20T08:02:36][ T14] kvm-guest:
stealtime: cpu 1, msr 17fbf2080
And here is the patch that I used for testing:
>From 39bdfebfa94fc55616fe23f2f0b80e06479b65e0 Mon Sep 17 00:00:00 2001
From: Petr Mladek
Date: Thu, 20 Aug 2020 10:18:57 +0200
Subject: [PATCH] printk: Test using all three timestamps: mono, boot, real
Test timekeeper enhancements proposed at
https://lore.kernel.org/r/20200814101933.574326...@linutronix.de
Allow to store and show all three timestamp (mono, boot, real).
It is not final solution. The prefix takes 83 characters that might
make the real text invisible or hard to read. Fragments of seconds
are lost in when printing real time timestamp. Offset is not provided
for crashdump tools.
Only syslog interface is supported. The log can be seen on consoles
or via:
dmesg -S
Signed-off-by: Petr Mladek
---
kernel/printk/printk.c | 40 ++--
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 9b75f6bfc333..329f3595b024 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -366,7 +366,7 @@ enum log_flags {
};
struct printk_log {
- u64 ts_nsec;/* timestamp in nanoseconds */
+ struct ktime_timestamps ts; /* timestamps */
u16 len;/* length of entire record */
u16 text_len; /* length of text buffer */
u16 dict_len; /* length of dictionary buffer */
@@ -443,7 +443,7 @@ static u64 clear_seq;
static u32 clear_idx;
#ifdef CONFIG_PRINTK_CALLER
-#define PREFIX_MAX 48
+#define PREFIX_MAX 48+14+21
#else
#define PREFIX_MAX 32
#endif
@@ -614,7 +614,7 @@ static u32 truncate_msg(u16 *text_len
Re: [PATCH 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary
On Wed, Aug 19, 2020 at 05:20:53PM -0700, Suren Baghdasaryan wrote:
> Currently __set_oom_adj loops through all processes in the system to
> keep oom_score_adj and oom_score_adj_min in sync between processes
> sharing their mm. This is done for any task with more that one mm_users,
> which includes processes with multiple threads (sharing mm and signals).
> However for such processes the loop is unnecessary because their signal
> structure is shared as well.
> Android updates oom_score_adj whenever a tasks changes its role
> (background/foreground/...) or binds to/unbinds from a service, making
> it more/less important. Such operation can happen frequently.
> We noticed that updates to oom_score_adj became more expensive and after
> further investigation found out that the patch mentioned in "Fixes"
> introduced a regression. Using Pixel 4 with a typical Android workload,
> write time to oom_score_adj increased from ~3.57us to ~362us. Moreover
> this regression linearly depends on the number of multi-threaded
> processes running on the system.
> Mark the mm with a new MMF_PROC_SHARED flag bit when task is created with
> CLONE_VM and !CLONE_SIGHAND. Change __set_oom_adj to use MMF_PROC_SHARED
> instead of mm_users to decide whether oom_score_adj update should be
> synchronized between multiple processes. To prevent races between clone()
> and __set_oom_adj(), when oom_score_adj of the process being cloned might
> be modified from userspace, we use oom_adj_mutex. Its scope is changed to
> global and it is renamed into oom_adj_lock for naming consistency with
> oom_lock. Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> used the additional mutex lock in that path of the clone() syscall should
> not affect its overall performance. Clearing the MMF_PROC_SHARED flag
> (when the last process sharing the mm exits) is left out of this patch to
> keep it simple and because it is believed that this threading model is
> rare. Should there ever be a need for optimizing that case as well, it
> can be done by hooking into the exit path, likely following the
> mm_update_next_owner pattern.
> With the combination of CLONE_VM and !CLONE_SIGHAND being quite rare, the
> regression is gone after the change is applied.
>
> Fixes: 44a70adec910 ("mm, oom_adj: make sure processes sharing mm have same
> view of oom_score_adj")
> Reported-by: Tim Murray
> Suggested-by: Michal Hocko
> Signed-off-by: Suren Baghdasaryan
> ---
> fs/proc/base.c | 7 +++
> include/linux/oom.h| 1 +
> include/linux/sched/coredump.h | 1 +
> kernel/fork.c | 9 +
> mm/oom_kill.c | 2 ++
> 5 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 617db4e0faa0..cff1a58a236c 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1055,7 +1055,6 @@ static ssize_t oom_adj_read(struct file *file, char
> __user *buf, size_t count,
>
> static int __set_oom_adj(struct file *file, int oom_adj, bool legacy)
> {
> - static DEFINE_MUTEX(oom_adj_mutex);
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> @@ -1064,7 +1063,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> if (!task)
> return -ESRCH;
>
> - mutex_lock(&oom_adj_mutex);
> + mutex_lock(&oom_adj_lock);
> if (legacy) {
> if (oom_adj < task->signal->oom_score_adj &&
> !capable(CAP_SYS_RESOURCE)) {
> @@ -1095,7 +1094,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct task_struct *p = find_lock_task_mm(task);
>
> if (p) {
> - if (atomic_read(&p->mm->mm_users) > 1) {
> + if (test_bit(MMF_PROC_SHARED, &p->mm->flags)) {
> mm = p->mm;
> mmgrab(mm);
> }
> @@ -1132,7 +1131,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> mmdrop(mm);
> }
> err_unlock:
> - mutex_unlock(&oom_adj_mutex);
> + mutex_unlock(&oom_adj_lock);
> put_task_struct(task);
> return err;
> }
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> index f022f581ac29..861f22bd4706 100644
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -55,6 +55,7 @@ struct oom_control {
> };
>
> extern struct mutex oom_lock;
> +extern struct mutex oom_adj_lock;
>
> static inline void set_current_oom_origin(void)
> {
> diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
> index ecdc6542070f..070629b722df 100644
> --- a/include/linux/sched/coredump.h
> +++ b/include/linux/sched/coredump.h
> @@ -72,6 +72,7 @@ static inline int get_dumpable(struct mm_struct *mm)
> #define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
> #define MMF_OOM_VICTIM
RE: [RFC PATCH 1/5] printk: implement pr_cont_t
From: Joe Perches > Sent: 20 August 2020 09:00 > > On Thu, 2020-08-20 at 07:44 +, David Laight wrote: > > I've no idea how you'd 'size' the number of buffers. > > I believe they are static and assume no more than 10 > simultaneous uses of printk_begin What I meant was how you'd work out whether 10 was in any way appropriate. ISTM it is either 'too many' or 'nowhere near enough' depending on exactly what the system is doing. And if code 'leaks' them you are in deep doo-doos. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH 1/6] staging: wfx/main.h: fix a spelling and grammar mistake
Fix spelling mistake "extention" => "extension".
And correct the statement in passive-voice by adding "be".
Signed-off-by: Suraj Upadhyay
---
drivers/staging/wfx/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/main.h b/drivers/staging/wfx/main.h
index c59d375dd3ad..2457cb595b0f 100644
--- a/drivers/staging/wfx/main.h
+++ b/drivers/staging/wfx/main.h
@@ -19,7 +19,7 @@ struct wfx_dev;
struct hwbus_ops;
struct wfx_platform_data {
- /* Keyset and ".sec" extention will appended to this string */
+ /* Keyset and ".sec" extension will be appended to this string */
const char *file_fw;
const char *file_pds;
struct gpio_desc *gpio_wakeup;
--
2.17.1
[PATCH v32 12/12] LRNG - add power-on and runtime self-tests
Parts of the LRNG are already covered by self-tests, including: * Self-test of SP800-90A DRBG provided by the Linux kernel crypto API. * Self-test of the PRNG provided by the Linux kernel crypto API. * Raw noise source data testing including SP800-90B compliant tests when enabling CONFIG_LRNG_HEALTH_TESTS This patch adds the self-tests for the remaining critical functions of the LRNG that are essential to maintain entropy and provide cryptographic strong random numbers. The following self-tests are implemented: * Self-test of the time array maintenance. This test verifies whether the time stamp array management to store multiple values in one integer implements a concatenation of the data. * Self-test of the LFSR operation. This test injects a monotonic increasing counter into the LFSR. After completion of the injection of the counter, 3 pool words are compared with known good values. The known good values are calculated with the newly-developed tool lfsr_testvector_generation provided as part of the LRNG test tool set at [1]. * Self-test of the Hash_DF operation ensures that this function operates compliant to the specification. The self-test performs a Hash_DF operation of a zeroized entropy pool state. The test vectors are generated using the newly-developed tool hash_df_testvector_generation provided as part of the LRNG test tool set at [1]. * Self-test of the ChaCha20 DRNG is based on the self-tests that are already present and implemented with the stand-alone user space ChaCha20 DRNG implementation available at [2]. The self-tests cover different use cases of the DRNG seeded with known seed data. The status of the LRNG self-tests is provided with the selftest_status SysFS file. If the file contains a zero, the self-tests passed. The value 0x means that the self-tests were not executed. Any other value indicates a self-test failure. The self-test may be compiled to panic the system if the self-test fails. All self-tests operate on private state data structures. This implies that none of the self-tests have any impact on the regular LRNG operations. This allows the self-tests to be repeated at runtime by writing anything into the selftest_status SysFS file. [1] https://www.chronox.de/lrng.html [2] https://www.chronox.de/chacha20.html CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange CC: Marcelo Henrique Cerri CC: Neil Horman Signed-off-by: Stephan Mueller --- drivers/char/lrng/Kconfig | 25 ++ drivers/char/lrng/Makefile| 1 + drivers/char/lrng/lrng_selftest.c | 504 ++ 3 files changed, 530 insertions(+) create mode 100644 drivers/char/lrng/lrng_selftest.c diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig index 5d2f44d07581..6930dddb5347 100644 --- a/drivers/char/lrng/Kconfig +++ b/drivers/char/lrng/Kconfig @@ -287,4 +287,29 @@ config LRNG_TESTING endif #LRNG_TESTING_MENU +config LRNG_SELFTEST + bool "Enable power-on and on-demand self-tests" + help + The power-on self-tests are executed during boot time + covering the ChaCha20 DRNG, the LFSR processing and the + time stamp management of the LRNG. + + The on-demand self-tests are triggered by writing any + value into the SysFS file selftest_status. At the same + time, when reading this file, the test status is + returned. A zero indicates that all tests were executed + successfully. + + If unsure, say Y. + +if LRNG_SELFTEST + +config LRNG_SELFTEST_PANIC + bool "Panic the kernel upon self-test failure" + help + If the option is enabled, the kernel is terminated if an + LRNG power-on self-test failure is detected. + +endif # LRNG_SELFTEST + endif # LRNG diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile index b2ce1979dc4b..92219c565f66 100644 --- a/drivers/char/lrng/Makefile +++ b/drivers/char/lrng/Makefile @@ -16,3 +16,4 @@ obj-$(CONFIG_LRNG_KCAPI) += lrng_kcapi.o obj-$(CONFIG_LRNG_JENT)+= lrng_jent.o obj-$(CONFIG_LRNG_HEALTH_TESTS)+= lrng_health.o obj-$(CONFIG_LRNG_TESTING) += lrng_testing.o +obj-$(CONFIG_LRNG_SELFTEST)+= lrng_selftest.o diff --git a/drivers/char/lrng/lrng_selftest.c b/drivers/char/lrng/lrng_selftest.c new file mode 100644 index ..638fd151904c --- /dev/null +++ b/drivers/char/lrng/lrng_selftest.c @@ -0,0 +1,504 @@ +// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +/* + * LRNG power-on and on-demand self-test + * + * Copyright (C) 2016 - 2020, Stephan Mueller + */ + +/* + * In addition to the self-tests below, the following LRNG components + * are covered with self-tests during reg
[PATCH v32 07/12] LRNG - add kernel crypto API PRNG extension
Add runtime-pluggable support for all PRNGs that are accessible via
the kernel crypto API, including hardware PRNGs. The PRNG is selected
with the module parameter drng_name where the name must be one that the
kernel crypto API can resolve into an RNG.
This allows using of the kernel crypto API PRNG implementations that
provide an interface to hardware PRNGs. Using this extension,
the LRNG uses the hardware PRNGs to generate random numbers. An
example is the S390 CPACF support providing such a PRNG.
The hash is provided by a kernel crypto API SHASH whose digest size
complies with the seedsize of the PRNG.
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Tarreau
CC: Matthew Garrett
CC: Vito Caputo
CC: Andreas Dilger
CC: Jan Kara
CC: Ray Strode
CC: William Jon McCann
CC: zhangjs
CC: Andy Lutomirski
CC: Florian Weimer
CC: Lennart Poettering
CC: Nicolai Stange
Reviewed-by: Marcelo Henrique Cerri
Reviewed-by: Roman Drahtmueller
Tested-by: Roman Drahtmüller
Tested-by: Marcelo Henrique Cerri
Tested-by: Neil Horman
Signed-off-by: Stephan Mueller
---
drivers/char/lrng/Kconfig | 11 ++
drivers/char/lrng/Makefile | 1 +
drivers/char/lrng/lrng_kcapi.c | 321 +
3 files changed, 333 insertions(+)
create mode 100644 drivers/char/lrng/lrng_kcapi.c
diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index 4ad26fdfbe7e..ba3d84cd0676 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -82,6 +82,17 @@ config LRNG_DRBG
Enable the SP800-90A DRBG support for the LRNG. Once the
module is loaded, output from /dev/random, /dev/urandom,
getrandom(2), or get_random_bytes is provided by a DRBG.
+
+config LRNG_KCAPI
+ tristate "Kernel Crypto API support for the LRNG"
+ depends on CRYPTO
+ select CRYPTO_RNG
+ help
+ Enable the support for generic pseudo-random number
+ generators offered by the kernel crypto API with the
+ LRNG. Once the module is loaded, output from /dev/random,
+ /dev/urandom, getrandom(2), or get_random_bytes is
+ provided by the selected kernel crypto API RNG.
endif # LRNG_DRNG_SWITCH
endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 0d320fcb7b9e..94b2dfb2dfdb 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_NUMA)+= lrng_numa.o
obj-$(CONFIG_SYSCTL) += lrng_proc.o
obj-$(CONFIG_LRNG_DRNG_SWITCH) += lrng_switch.o
obj-$(CONFIG_LRNG_DRBG)+= lrng_drbg.o
+obj-$(CONFIG_LRNG_KCAPI) += lrng_kcapi.o
diff --git a/drivers/char/lrng/lrng_kcapi.c b/drivers/char/lrng/lrng_kcapi.c
new file mode 100644
index ..482f31627422
--- /dev/null
+++ b/drivers/char/lrng/lrng_kcapi.c
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * Backend for the LRNG providing the cryptographic primitives using the
+ * kernel crypto API.
+ *
+ * Copyright (C) 2018 - 2020, Stephan Mueller
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+static char *drng_name = NULL;
+module_param(drng_name, charp, 0444);
+MODULE_PARM_DESC(drng_name, "Kernel crypto API name of DRNG");
+
+static char *pool_hash = "sha512";
+module_param(pool_hash, charp, 0444);
+MODULE_PARM_DESC(pool_hash,
+"Kernel crypto API name of hash or keyed message digest to
read the entropy pool");
+
+static char *seed_hash = NULL;
+module_param(seed_hash, charp, 0444);
+MODULE_PARM_DESC(seed_hash,
+"Kernel crypto API name of hash with output size equal to
seedsize of DRNG to bring seed string to the size required by the DRNG");
+
+struct lrng_hash_info {
+ struct shash_desc shash;
+ char ctx[];
+};
+
+struct lrng_drng_info {
+ struct crypto_rng *kcapi_rng;
+ struct lrng_hash_info *lrng_hash;
+};
+
+static struct lrng_hash_info *_lrng_kcapi_hash_alloc(const char *name)
+{
+ struct lrng_hash_info *lrng_hash;
+ struct crypto_shash *tfm;
+ int size;
+
+ if (!name) {
+ pr_err("Hash name missing\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ tfm = crypto_alloc_shash(name, 0, 0);
+ if (IS_ERR(tfm)) {
+ pr_err("could not allocate hash %s\n", name);
+ return ERR_CAST(tfm);
+ }
+
+ size = sizeof(struct lrng_hash_info) + crypto_shash_descsize(tfm);
+ lrng_hash = kmalloc(size, GFP_KERNEL);
+ if (!lrng_hash) {
+ crypto_free_shash(tfm);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ lrng_hash->shash.tfm = tfm;
+
+ return lrng_hash;
+}
+
+static inline u32 _lrng_kcapi_hash_digestsize(struct lrng_hash_info *lrng_hash)
+{
+ struct shash_desc *shash = &lrng_hash->shash;
+ struct crypto_shash *tfm = shas
