Re: [PATCH v4 0/4] Multiplex sdmmc low jitter clock path
Series Acked-By: Peter De Schrijver Peter. On Mon, Jul 09, 2018 at 07:38:54PM +0300, Aapo Vienamo wrote: > The SDMMC clocks have a Low Jitter (LJ) clock path which bypasses a > divider to achieve better jitter performance with high speed signaling > modes. The clock path with the divider is needed by some of the slower > signaling modes. This series automatically multiplexes the LJ and > non-LJ clock paths based on the requested frequency. > > Changelog: > v4: > - Add a changelog > > v3: > - Use include instead of for > do_div() > - Use SPDX tags for new files > - Make mux_lj_idx[] and mux_non_lj_idx[] const > - Make tegra_clk_sdmmc_mux_ops static > - Fix the includes for fence_udelay() in a separate patch > > v2: > - Fix the type compatibility error on do_div > > Aapo Vienamo (1): > clk: tegra: Fix includes required by fence_udelay() > > Peter De Schrijver (1): > clk: tegra: refactor 7.1 div calculation > > Peter De-Schrijver (2): > clk: tegra: Add sdmmc mux divider clock > clk: tegra: make sdmmc2 and sdmmc4 as sdmmc clocks > > drivers/clk/tegra/Makefile | 2 + > drivers/clk/tegra/clk-divider.c | 30 + > drivers/clk/tegra/clk-id.h | 2 - > drivers/clk/tegra/clk-sdmmc-mux.c| 250 > +++ > drivers/clk/tegra/clk-tegra-periph.c | 11 -- > drivers/clk/tegra/clk-tegra210.c | 14 +- > drivers/clk/tegra/clk.h | 30 + > drivers/clk/tegra/div71.c| 43 ++ > 8 files changed, 342 insertions(+), 40 deletions(-) > create mode 100644 drivers/clk/tegra/clk-sdmmc-mux.c > create mode 100644 drivers/clk/tegra/div71.c > > -- > 2.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-clk" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 08/21] s390: vfio-ap: register matrix device with VFIO mdev framework
On 09.07.2018 16:17, Pierre Morel wrote:
> On 29/06/2018 23:11, Tony Krowiak wrote:
>> Registers the matrix device created by the VFIO AP device
>> driver with the VFIO mediated device framework.
>> Registering the matrix device will create the sysfs
>> structures needed to create mediated matrix devices
>> each of which will be used to configure the AP matrix
>> for a guest and connect it to the VFIO AP device driver.
>>
>> Registering the matrix device with the VFIO mediated device
>> framework will create the following sysfs structures:
>>
>> /sys/devices/vfio_ap
>> ... [matrix]
>> .. [mdev_supported_types]
>> . [vfio_ap-passthrough]
>> create
>>
>> To create a mediated device for the AP matrix device, write a UUID
>> to the create file:
>>
>> uuidgen > create
>>
>> A symbolic link to the mediated device's directory will be created in the
>> devices subdirectory named after the generated $uuid:
>>
>> /sys/devices/vfio_ap
>> ... [matrix]
>> .. [mdev_supported_types]
>> . [vfio_ap-passthrough]
>> [devices]
>> ... [$uuid]
>>
>> Signed-off-by: Tony Krowiak
>> ---
>> MAINTAINERS | 1 +
>> drivers/s390/crypto/Makefile | 2 +-
>> drivers/s390/crypto/vfio_ap_drv.c | 9 ++
>> drivers/s390/crypto/vfio_ap_ops.c | 131
>> +
>> drivers/s390/crypto/vfio_ap_private.h | 22 +-
>> 5 files changed, 161 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/s390/crypto/vfio_ap_ops.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0515dae..3217803 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -12410,6 +12410,7 @@ W:
>> http://www.ibm.com/developerworks/linux/linux390/
>> S: Supported
>> F: drivers/s390/crypto/vfio_ap_drv.c
>> F: drivers/s390/crypto/vfio_ap_private.h
>> +F: drivers/s390/crypto/vfio_ap_ops.c
>>
>> S390 ZFCP DRIVER
>> M: Steffen Maier
>> diff --git a/drivers/s390/crypto/Makefile b/drivers/s390/crypto/Makefile
>> index 48e466e..8d36b05 100644
>> --- a/drivers/s390/crypto/Makefile
>> +++ b/drivers/s390/crypto/Makefile
>> @@ -17,5 +17,5 @@ pkey-objs := pkey_api.o
>> obj-$(CONFIG_PKEY) += pkey.o
>>
>> # adjunct processor matrix
>> -vfio_ap-objs := vfio_ap_drv.o
>> +vfio_ap-objs := vfio_ap_drv.o vfio_ap_ops.o
>> obj-$(CONFIG_VFIO_AP) += vfio_ap.o
>> diff --git a/drivers/s390/crypto/vfio_ap_drv.c
>> b/drivers/s390/crypto/vfio_ap_drv.c
>> index 93db312..b6ff7a4 100644
>> --- a/drivers/s390/crypto/vfio_ap_drv.c
>> +++ b/drivers/s390/crypto/vfio_ap_drv.c
>> @@ -127,11 +127,20 @@ int __init vfio_ap_init(void)
>> return ret;
>> }
>>
>> + ret = vfio_ap_mdev_register(matrix_dev);
>> + if (ret) {
>> + ap_driver_unregister(&vfio_ap_drv);
>> + vfio_ap_matrix_dev_destroy(matrix_dev);
>> +
>> + return ret;
>> + }
>> +
>> return 0;
>> }
>>
>> void __exit vfio_ap_exit(void)
>> {
>> + vfio_ap_mdev_unregister(matrix_dev);
>> ap_driver_unregister(&vfio_ap_drv);
>> vfio_ap_matrix_dev_destroy(matrix_dev);
>> }
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
>> b/drivers/s390/crypto/vfio_ap_ops.c
>> new file mode 100644
>> index 000..4e61e33
>> --- /dev/null
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -0,0 +1,131 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Adjunct processor matrix VFIO device driver callbacks.
>> + *
>> + * Copyright IBM Corp. 2018
>> + * Author(s): Tony Krowiak
>> + *
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "vfio_ap_private.h"
>> +
>> +#define VFOP_AP_MDEV_TYPE_HWVIRT "passthrough"
>> +#define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
>> +
>> +DEFINE_SPINLOCK(mdev_list_lock);
>> +LIST_HEAD(mdev_list);
>> +
>> +static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device
>> *mdev)
>> +{
>> + struct ap_matrix_dev *matrix_dev =
>> + to_ap_matrix_dev(mdev_parent_dev(mdev));
>> + struct ap_matrix_mdev *matrix_mdev;
>> +
>> + matrix_mdev = kzalloc(sizeof(*matrix_mdev), GFP_KERNEL);
>> + if (!matrix_mdev)
>> + return -ENOMEM;
>> +
>> + matrix_mdev->name = dev_name(mdev_dev(mdev));
>> + mdev_set_drvdata(mdev, matrix_mdev);
>> +
>> + if (atomic_dec_if_positive(&matrix_dev->available_instances) < 0) {
>> + kfree(matrix_mdev);
>> + return -EPERM;
>> + }
>> +
>> + spin_lock_bh(&mdev_list_lock);
>> + list_add(&matrix_mdev->list, &mdev_list);
>> + spin_unlock_bh(&mdev_list_lock);
>> +
>> + return 0;
>> +}
>> +
>> +static int vfio_ap_mdev_remove(struct mdev_device *mdev)
>> +{
>> + struct ap_matrix_dev *matrix_dev =
>> + to_ap_matrix_dev(mdev_parent_dev(mdev));
>> + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
>> +
>> + spin_lock_bh(&mdev_list_lock);
>> + list_del(&matrix_mdev->list);
>> + spin_unlock_bh(&mdev_list_lock);
>> + kf
Re: linux-next: Signed-off-by missing for commit in the pinctrl tree
Hi Shimoda-san, Linus,
On Tue, Jul 10, 2018 at 3:18 AM Yoshihiro Shimoda
wrote:
> > -Original Message-
> > From: Linus Walleij, Sent: Tuesday, July 10, 2018 7:46 AM
> >
> > Hm must have come from Geert's pull request?
> >
> > (I'm regularly wrong about this so not so certain...)
> >
> > Geert can I fix it the usual way by simply rebasing and
> > adding the right SoB?
>
> I'm very sorry for this trouble.
> When I ported this patch, I dropped the author's Signed-of-by wrongly..
>
> Signed-off-by: Takeshi Kihara
Thank you!
Since this was the top commit from my last pull request, I've just ammended it,
retagged, and pushed.
Sorry for the trouble.
/me looks into improving checkpatch.pl...
> > On Mon, Jul 9, 2018 at 11:54 PM Stephen Rothwell
> > wrote:
> > > Commit
> > >
> > > a742fcf72902 ("pinctrl: sh-pfc: r8a77990: Add USB3.0 pins, groups and
> > > functions")
> > >
> > > is missing a Signed-off-by from its author.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH -mm -v4 05/21] mm, THP, swap: Support PMD swap mapping in free_swap_and_cache()/swap_free()
Dave Hansen writes:
> I'm seeing a pattern here.
>
> old code:
>
> foo()
> {
> do_swap_something()
> }
>
> new code:
>
> foo(bool cluster)
> {
> if (cluster)
> do_swap_cluster_something();
> else
> do_swap_something();
> }
>
> That make me fear that we have:
> 1. Created a new, wholly untested code path
> 2. Created two places to patch bugs
> 3. Are not reusing code when possible
>
> The code non-resuse was, and continues to be, IMNHO, one of the largest
> sources of bugs with the original THP implementation. It might be
> infeasible to do here, but let's at least give it as much of a go as we can.
I totally agree that we should unify the code path for huge and normal
page/swap if possible. One concern is code size for !CONFIG_THP_SWAP.
The original method is good for that. The new method may introduce some
huge swap related code that is hard to be eliminated for
!CONFIG_THP_SWAP. Andrew Morton pointed this out for the patchset of
the first step of the THP swap optimization.
This may be mitigated at least partly via,
`
#ifdef CONFIG_THP_SWAP
#define nr_swap_entries(nr) (nr)
#else
#define nr_swap_entries(nr) 1
#endif
void do_something(swp_entry_t entry, int __nr_entries)
{
int i, nr_entries = nr_swap_entries(__nr_entries);
if (nr_entries = SWAPFILE_CLUSTER)
; /* huge swap specific */
else
; /* normal swap specific */
for (i = 0; i < nr_entries; i++) {
; /* do something for each entry */
}
/* ... */
}
`
and rely on compiler to do the dirty work for us if possible.
Hi, Andrew,
What do you think about this?
> Can I ask that you take another round through this set and:
>
> 1. Consolidate code refactoring into separate patches
Sure.
> 2. Add comments to code, and avoid doing it solely in changelogs
Sure.
> 3. Make an effort to share more code between the old code and new
>code. Where code can not be shared, call that out in the changelog.
Will do that if we resolve the code size concern.
> This is a *really* hard-to-review set at the moment. Doing those things
> will make it much easier to review and hopefully give us more
> maintainable code going forward.
>
> My apologies for not having done this review sooner.
Thanks a lot for your comments!
Best Regards,
Huang, Ying
Re: [PATCH 2/2] mips: mm: Discard ioremap_uncached_accelerated() method
'
On Mon, Jul 9, 2018 at 3:57 PM Serge Semin wrote:
>
> Adaptive ioremap_wc() method is now available (see "mips: mm:
> Create UCA-based ioremap_wc() method" commit). We can use it for
> UCA-featured MMIO transactions in the kernel, so we don't need
> it platform clone ioremap_uncached_accelerated() being declard.
> Seeing it is also unused anywhere in the kernel code, lets remove
> it from io.h arch-specific header then.
>
> Signed-off-by: Serge Semin
> Singed-off-by: Paul Burton
nit: 'Signed' (on both patches)
> Cc: James Hogan
> Cc: Ralf Baechle
> Cc: linux-m...@linux-mips.org
> Cc: sta...@vger.kernel.org
> ---
> arch/mips/include/asm/io.h | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
> index babe5155a..360b7ddeb 100644
> --- a/arch/mips/include/asm/io.h
> +++ b/arch/mips/include/asm/io.h
> @@ -301,15 +301,11 @@ static inline void __iomem * __ioremap_mode(phys_addr_t
> offset, unsigned long si
> __ioremap_mode((offset), (size), boot_cpu_data.writecombine)
>
> /*
> - * These two are MIPS specific ioremap variant. ioremap_cacheable_cow
> - * requests a cachable mapping, ioremap_uncached_accelerated requests a
> - * mapping using the uncached accelerated mode which isn't supported on
> - * all processors.
> + * This is a MIPS specific ioremap variant. ioremap_cacheable_cow
> + * requests a cachable mapping with CWB attribute enabled.
> */
> #define ioremap_cacheable_cow(offset, size)\
> __ioremap_mode((offset), (size), _CACHE_CACHABLE_COW)
> -#define ioremap_uncached_accelerated(offset, size) \
> - __ioremap_mode((offset), (size), _CACHE_UNCACHED_ACCELERATED)
>
> static inline void iounmap(const volatile void __iomem *addr)
> {
> --
> 2.12.0
>
>
RE: linux-next: build warning after merge of the printk tree
Hi Petr,
> Hi all,
> After merging the printk tree, today's linux-next build (x86_64
> allnoconfig) produced this warning:
> kernel/printk/printk.c:2033:13: warning: 'suppress_message_printing' defined
> but not used [-Wunused-function]
> static bool suppress_message_printing(int level) { return false; }
^
seems there is no user for suppress_message_printing when CONFIG_PRINTK is
disabled,
because earlier it was getting used in console_unlock and now we shifted this
into vprintk_emit
which will be disabled on disabling CONFIG_PRINTk.
should we remove this defination when CONFIG_PRINTK is disabled ?
> Introduced by commit
> 375899cddcbb ("printk: make sure to print log on console.")
No File Name 0
Description: Binary data
Re: [PATCH] net/9p/client.c: add missing '\n' at the end of p9_debug()
On 2018/7/10 14:56, piaojun wrote: > In p9_client_getattr_dotl(), we should add '\n' at the end of printing > log. > > Signed-off-by: Jun Piao Reviewed-by: Yiwen Jiang > --- > net/9p/client.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/9p/client.c b/net/9p/client.c > index 5c13431..8bc8b3e 100644 > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -1790,7 +1790,7 @@ struct p9_stat_dotl *p9_client_getattr_dotl(struct > p9_fid *fid, > "<<< st_mtime_sec=%lld st_mtime_nsec=%lld\n" > "<<< st_ctime_sec=%lld st_ctime_nsec=%lld\n" > "<<< st_btime_sec=%lld st_btime_nsec=%lld\n" > - "<<< st_gen=%lld st_data_version=%lld", > + "<<< st_gen=%lld st_data_version=%lld\n", > ret->st_result_mask, ret->qid.type, ret->qid.path, > ret->qid.version, ret->st_mode, ret->st_nlink, > from_kuid(&init_user_ns, ret->st_uid), >
Re: [PATCH] ARM: ftrace: Only set kernel memory back to read-only after boot
On 04.07.2018 13:30, Stefan Agner wrote:
> On 21.06.2018 18:47, Steven Rostedt wrote:
>> From: Steven Rostedt (VMware)
>>
>> Dynamic ftrace requires modifying the code segments that are usually
>> set to read-only. To do this, a per arch function is called both before
>> and after the ftrace modifications are performed. The "before" function
>> will set kernel code text to read-write to allow for ftrace to make the
>> modifications, and the "after" function will set the kernel code text
>> back to "read-only" to keep the kernel code text protected.
>>
>> The issue happens when dynamic ftrace is tested at boot up. The test is
>> done before the kernel code text has been set to read-only. But the
>> "before" and "after" calls are still performed. The "after" call will
>> change the kernel code text to read-only prematurely, and other boot
>> code that expects this code to be read-write will fail.
>>
>> The solution is to add a variable that is set when the kernel code text
>> is expected to be converted to read-only, and make the ftrace "before"
>> and "after" calls do nothing if that variable is not yet set. This is
>> similar to the x86 solution from commit 162396309745 ("ftrace, x86:
>> make kernel text writable only for conversions").
>>
>> Reported-by: Stefan Agner
>> Tested-by: Stefan Agner
>> Link: http://lkml.kernel.org/r/20180620212906.24b7b...@vmware.local.home
>> Signed-off-by: Steven Rostedt (VMware)
>> ---
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index c186474422f3..0cc8e04295a4 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>
> I guess this can be seen as reviewed?
>
> Patches touching core ARM port usually go through Russels patch tracker.
>
> You have to submit the patch here:
> http://www.armlinux.org.uk/developer/patches/
>
FWIW, I added this patch to the patch tracker, its patch ID is 8780/1.
--
Stefan
>
>
>> @@ -736,20 +736,29 @@ static int __mark_rodata_ro(void *unused)
>> return 0;
>> }
>>
>> +static int kernel_set_to_readonly __read_mostly;
>> +
>> void mark_rodata_ro(void)
>> {
>> +kernel_set_to_readonly = 1;
>> stop_machine(__mark_rodata_ro, NULL, NULL);
>> debug_checkwx();
>> }
>>
>> void set_kernel_text_rw(void)
>> {
>> +if (!kernel_set_to_readonly)
>> +return;
>> +
>> set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), false,
>> current->active_mm);
>> }
>>
>> void set_kernel_text_ro(void)
>> {
>> +if (!kernel_set_to_readonly)
>> +return;
>> +
>> set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
>> current->active_mm);
>> }
Re: linux-next: build warning after merge of the random tree
Hi all,
On Mon, 18 Jun 2018 15:29:00 +1000 "Tobin C. Harding" wrote:
>
> On Mon, Jun 18, 2018 at 01:35:23PM +1000, Stephen Rothwell wrote:
> >
> > On Fri, 8 Jun 2018 13:37:48 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the random tree, today's linux-next build (arm
> > > multi_v7_defconfig) produced this warning:
> > >
> > > lib/vsprintf.c:1668:13: warning: 'have_filled_random_ptr_key' defined but
> > > not used [-Wunused-variable]
> > > static bool have_filled_random_ptr_key __read_mostly;
> > > ^~
> > >
> > > Introduced by commit
> > >
> > > bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")
> > >
> >
> > I am still getting this ...
>
> This is fixed in:
>
> [PATCH v7 0/4] enable early printing of hashed pointers
>
>
> FYI v8 to come with unrelated change removing EXPORT_SYMBOL() (as suggested
> on LKML in response to v7)
Still getting this warning ...
--
Cheers,
Stephen Rothwell
pgpQMb0KbPMfV.pgp
Description: OpenPGP digital signature
Re: linux-next: build warning after merge of the scsi tree
Hi all,
On Wed, 20 Jun 2018 13:29:10 +1000 Stephen Rothwell
wrote:
>
> After merging the scsi tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
>
> In file included from include/target/target_core_base.h:7:0,
> from drivers/target/target_core_tmr.c:31:
> include/linux/sbitmap.h:331:46: warning: 'struct seq_file' declared inside
> parameter list will not be visible outside of this definition or declaration
> void sbitmap_show(struct sbitmap *sb, struct seq_file *m);
> ^~~~
> include/linux/sbitmap.h:342:53: warning: 'struct seq_file' declared inside
> parameter list will not be visible outside of this definition or declaration
> void sbitmap_bitmap_show(struct sbitmap *sb, struct seq_file *m);
> ^~~~
> include/linux/sbitmap.h:530:59: warning: 'struct seq_file' declared inside
> parameter list will not be visible outside of this definition or declaration
> void sbitmap_queue_show(struct sbitmap_queue *sbq, struct seq_file *m);
>^~~~
> In file included from include/target/target_core_base.h:7:0,
> from drivers/target/target_core_ua.c:30:
> include/linux/sbitmap.h:331:46: warning: 'struct seq_file' declared inside
> parameter list will not be visible outside of this definition or declaration
> void sbitmap_show(struct sbitmap *sb, struct seq_file *m);
> ^~~~
> include/linux/sbitmap.h:342:53: warning: 'struct seq_file' declared inside
> parameter list will not be visible outside of this definition or declaration
> void sbitmap_bitmap_show(struct sbitmap *sb, struct seq_file *m);
> ^~~~
> include/linux/sbitmap.h:530:59: warning: 'struct seq_file' declared inside
> parameter list will not be visible outside of this definition or declaration
> void sbitmap_queue_show(struct sbitmap_queue *sbq, struct seq_file *m);
>^~~~
>
> Introduced by commit
>
> 24af1ccfe12a ("sbitmap: add helpers for dumping to a seq_file")
>
> in v4.11.rc1, but exposed by commit
>
> eca7ee1f33e8 ("scsi: target: Convert target drivers to use sbitmap")
I am still seeing these warnings ...
--
Cheers,
Stephen Rothwell
pgpDvQDJcS764.pgp
Description: OpenPGP digital signature
Re: [PATCHv2 1/7] tools: build: Fixup host c flags
On Mon, Jul 09, 2018 at 05:45:56PM -0700, Laura Abbott wrote:
> Commit 0c3b7e42616f ("tools build: Add support for host programs format")
> introduced host_c_flags which referenced CHOSTFLAGS. The actual name of the
> variable is HOSTCFLAGS. Fix this up.
>
> Fixes: 0c3b7e42616f ("tools build: Add support for host programs format")
> Signed-off-by: Laura Abbott
> ---
> v2: Also fixed another instance in perf pmu-events.
Acked-by: Jiri Olsa
cc-ing more folks, that were in initial patch for heads up
thanks,
jirka
> ---
> tools/build/Build.include | 2 +-
> tools/perf/pmu-events/Build | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/build/Build.include b/tools/build/Build.include
> index a4bbb984941d..b5c679cd441c 100644
> --- a/tools/build/Build.include
> +++ b/tools/build/Build.include
> @@ -98,4 +98,4 @@ cxx_flags = -Wp,-MD,$(depfile) -Wp,-MT,$@ $(CXXFLAGS)
> -D"BUILD_STR(s)=\#s" $(CXX
> ###
> ## HOSTCC C flags
>
> -host_c_flags = -Wp,-MD,$(depfile) -Wp,-MT,$@ $(CHOSTFLAGS)
> -D"BUILD_STR(s)=\#s" $(CHOSTFLAGS_$(basetarget).o) $(CHOSTFLAGS_$(obj))
> +host_c_flags = -Wp,-MD,$(depfile) -Wp,-MT,$@ $(HOSTCFLAGS)
> -D"BUILD_STR(s)=\#s" $(HOSTCFLAGS_$(basetarget).o) $(HOSTCFLAGS_$(obj))
> diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build
> index 17783913d330..215ba30b8534 100644
> --- a/tools/perf/pmu-events/Build
> +++ b/tools/perf/pmu-events/Build
> @@ -1,7 +1,7 @@
> hostprogs := jevents
>
> jevents-y+= json.o jsmn.o jevents.o
> -CHOSTFLAGS_jevents.o = -I$(srctree)/tools/include
> +HOSTCFLAGS_jevents.o = -I$(srctree)/tools/include
> pmu-events-y += pmu-events.o
> JDIR = pmu-events/arch/$(SRCARCH)
> JSON = $(shell [ -d $(JDIR) ] &&\
> --
> 2.17.1
>
Re: [PATCHv2 2/7] tools: build: Use HOSTLDFLAGS with fixdep
On Mon, Jul 09, 2018 at 05:45:57PM -0700, Laura Abbott wrote: > The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS. > Fix this. > > Signed-off-by: Laura Abbott Acked-by: Jiri Olsa thanks, jirka > --- > v2: Switch to just using HOSTLDFLAGS instead of both LDFLAGS and > HOSTLDFLAGS. > --- > tools/build/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/build/Makefile b/tools/build/Makefile > index 5eb4b5ad79cb..5edf65e684ab 100644 > --- a/tools/build/Makefile > +++ b/tools/build/Makefile > @@ -43,7 +43,7 @@ $(OUTPUT)fixdep-in.o: FORCE > $(Q)$(MAKE) $(build)=fixdep > > $(OUTPUT)fixdep: $(OUTPUT)fixdep-in.o > - $(QUIET_LINK)$(HOSTCC) $(LDFLAGS) -o $@ $< > + $(QUIET_LINK)$(HOSTCC) $(HOSTLDFLAGS) -o $@ $< > > FORCE: > > -- > 2.17.1 >
linux-next: Tree for Jul 10
Hi all, Changes since 20180709: The vfs tree gained conflicts against the overlayfs tree. The rdma tree gained a conflict against the rdma-fixes tree. The akpm-current tree gained a conflict against the pci tree. Non-merge commits (relative to Linus' tree): 5017 5138 files changed, 186644 insertions(+), 107709 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 283 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (1e4b044d2251 Linux 4.18-rc4) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (47a18a2dabba scripts: teach extract-vmlinux about LZ4 and ZSTD) Merging arc-current/for-curr (6e3761145a9b ARC: Fix CONFIG_SWAP) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (1a381d4a0a9a arm64: remove no-op -p linker flag) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (22db552b50fa powerpc/powermac: Fix rtc read/write functions) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (6508b6781be0 tcp: cleanup copied_seq and urg_data in tcp_disconnect) Merging bpf/master (f292b87d3ac0 bpf: include errno.h from bpf-cgroup.h) Merging ipsec/master (7284fdf39a91 esp6: fix memleak on error path in esp6_input) Merging netfilter/master (84379c9afe01 netfilter: ipv6: nf_defrag: drop skb dst before queueing) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (248c690a2dc8 Merge tag 'wireless-drivers-for-davem-2018-07-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers) Merging mac80211/master (5cf3006cc81d nl80211: Add a missing break in parse_station_flags) Merging rdma-fixes/for-rc (fe48aecb4df8 RDMA/uverbs: Don't fail in creation of multiple flows) Merging sound-current/for-linus (c6b17f1020d9 ALSA: hda/realtek - two more lenovo models need fixup of MIC_LOCATION) Merging sound-asoc-fixes/for-linus (b2a0d94959c9 Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (7daf201d7fe8 Linux 4.18-rc2) Merging regulator-fixes/for-linus (83b9348e987d Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (d28cbf8dcb01 Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (a83a21734416 PCI: endpoint: Fix NULL pointer dereference error when CONFIGFS is disabled) Merging driver-core.current/driver-core-linus (7daf201d7fe8 Linux 4.18-rc2) Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3) Merging usb.current/usb-linus (f1e255d60ae6 USB: yurex: fix out-of-bounds uaccess in read handler) Merging usb-gadget-fixes/fixes (1d8e5c002758 dwc2: gadget: Fix ISOC IN DDMA PID bitfield value calculation) Merging usb-serial-fixes/usb-linus (794744abfffe USB: serial: mos7840: fix status-register error handling) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600:
Re: [PATCH 2/2] mips: mm: Discard ioremap_uncached_accelerated() method
On Tue, Jul 10, 2018 at 09:15:17AM +0200, Mathieu Malaterre
wrote:
> '
> On Mon, Jul 9, 2018 at 3:57 PM Serge Semin wrote:
> >
> > Adaptive ioremap_wc() method is now available (see "mips: mm:
> > Create UCA-based ioremap_wc() method" commit). We can use it for
> > UCA-featured MMIO transactions in the kernel, so we don't need
> > it platform clone ioremap_uncached_accelerated() being declard.
> > Seeing it is also unused anywhere in the kernel code, lets remove
> > it from io.h arch-specific header then.
> >
> > Signed-off-by: Serge Semin
> > Singed-off-by: Paul Burton
>
> nit: 'Signed' (on both patches)
>
Good catch! Thanks. Didn't notice the typo. Should have copy-pasted
both the signature and the e-mail from another letter.
I'll fix it if there will be a second version of the patchset. Otherwise
I suppose it would be easier for the integrator to do this.
Regards,
-Sergey
> > Cc: James Hogan
> > Cc: Ralf Baechle
> > Cc: linux-m...@linux-mips.org
> > Cc: sta...@vger.kernel.org
> > ---
> > arch/mips/include/asm/io.h | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
> > index babe5155a..360b7ddeb 100644
> > --- a/arch/mips/include/asm/io.h
> > +++ b/arch/mips/include/asm/io.h
> > @@ -301,15 +301,11 @@ static inline void __iomem *
> > __ioremap_mode(phys_addr_t offset, unsigned long si
> > __ioremap_mode((offset), (size), boot_cpu_data.writecombine)
> >
> > /*
> > - * These two are MIPS specific ioremap variant.
> > ioremap_cacheable_cow
> > - * requests a cachable mapping, ioremap_uncached_accelerated requests a
> > - * mapping using the uncached accelerated mode which isn't supported on
> > - * all processors.
> > + * This is a MIPS specific ioremap variant. ioremap_cacheable_cow
> > + * requests a cachable mapping with CWB attribute enabled.
> > */
> > #define ioremap_cacheable_cow(offset, size)\
> > __ioremap_mode((offset), (size), _CACHE_CACHABLE_COW)
> > -#define ioremap_uncached_accelerated(offset, size) \
> > - __ioremap_mode((offset), (size), _CACHE_UNCACHED_ACCELERATED)
> >
> > static inline void iounmap(const volatile void __iomem *addr)
> > {
> > --
> > 2.12.0
> >
> >
Re: [PATCH -mm -v4 14/21] mm, cgroup, THP, swap: Support to move swap account for PMD swap mapping
Daniel Jordan writes: > On Fri, Jun 22, 2018 at 11:51:44AM +0800, Huang, Ying wrote: >> Because there is no way to prevent a huge swap cluster from being >> split except when it has SWAP_HAS_CACHE flag set. > > What about making get_mctgt_type_thp take the cluster lock? That function > would be the first lock_cluster user outside of swapfile.c, but it would > serialize with split_swap_cluster. > >> It is possible for >> the huge swap cluster to be split and the charge for the swap slots >> inside to be changed, after we check the PMD swap mapping and the huge >> swap cluster before we commit the charge moving. But the race window >> is so small, that we will just ignore the race. > > Moving the charges is a slow path, so can't we just be correct here and not > leak? Check the code and thought about this again, found the race may not exist. Because the PMD is locked when get_mctgt_type_thp() is called until charge is completed for the PMD. So the charge of the huge swap cluster cannot be changed at the same time even if the huge swap cluster is split by other processes. Right? Will update the comments for this. Best Regards, Huang, Ying
Re: [PATCH 0/2] mm/fs: put_user_page() proposal
On Mon 09-07-18 13:56:57, Jason Gunthorpe wrote: > On Mon, Jul 09, 2018 at 09:47:40PM +0200, Jan Kara wrote: > > On Mon 09-07-18 10:16:51, Matthew Wilcox wrote: > > > On Mon, Jul 09, 2018 at 06:08:06PM +0200, Jan Kara wrote: > > > > On Mon 09-07-18 18:49:37, Nicholas Piggin wrote: > > > > > The problem with blocking in clear_page_dirty_for_io is that the fs is > > > > > holding the page lock (or locks) and possibly others too. If you > > > > > expect to have a bunch of long term references hanging around on the > > > > > page, then there will be hangs and deadlocks everywhere. And if you do > > > > > not have such log term references, then page lock (or some similar > > > > > lock > > > > > bit) for the duration of the DMA should be about enough? > > > > > > > > There are two separate questions: > > > > > > > > 1) How to identify pages pinned for DMA? We have no bit in struct page > > > > to > > > > use and we cannot reuse page lock as that immediately creates lock > > > > inversions e.g. in direct IO code (which could be fixed but then good > > > > luck > > > > with auditing all the other GUP users). Matthew had an idea and John > > > > implemented it based on removing page from LRU and using that space in > > > > struct page. So we at least have a way to identify pages that are pinned > > > > and can track their pin count. > > > > > > > > 2) What to do when some page is pinned but we need to do e.g. > > > > clear_page_dirty_for_io(). After some more thinking I agree with you > > > > that > > > > just blocking waiting for page to unpin will create deadlocks like: > > > > > > Why are we trying to writeback a page that is pinned? It's presumed to > > > be continuously redirtied by its pinner. We can't evict it. > > > > So what should be a result of fsync(file), where some 'file' pages are > > pinned e.g. by running direct IO? If we just skip those pages, we'll lie to > > userspace that data was committed while it was not (and it's not only about > > data that has landed in those pages via DMA, you can have first 1k of a page > > modified by normal IO in parallel to DMA modifying second 1k chunk). If > > fsync(2) returns error, it would be really unexpected by userspace and most > > apps will just not handle that correctly. So what else can you do than > > block? > > I think as a userspace I would expect the 'current content' to be > flushed without waiting.. Yes but the problem is we cannot generally write out a page whose contents is possibly changing (e.g. RAID5 checksums would then be wrong). But maybe using bounce pages (and keeping original page still dirty) in such case would be worth it - originally I thought using bounce pages would not bring us much but now seeing problems with blocking in more detail maybe they are worth the trouble after all... > If you block fsync() then anyone using a RDMA MR with it will just > dead lock. What happens if two processes open the same file and > one makes a MR and the other calls fsync()? Sounds bad. Yes, that's one of the reasons why we were discussing revoke mechanisms for long term pins. But with bounce pages we could possibly avoid that (except for cases like DAX + truncate where it's really unavoidable but there it's a new functionality so mandating revoke and returning error otherwise is fine I guess). Honza -- Jan Kara SUSE Labs, CR
[PATCH] gpio: mxc: add power management support
GPIO registers could lose context on some i.MX SoCs,
like on i.MX7D, when enter LPSR mode, the whole SoC
will be powered off except LPSR domain, GPIO banks
will lose context in this case, need to restore
the context after resume from LPSR mode.
This patch adds GPIO save/restore for those necessary
registers, and put the save/restore operations in noirq
suspend/resume phase, since GPIO is fundamental module
which could be used by other peripherals' resume phase.
Signed-off-by: Anson Huang
---
drivers/gpio/gpio-mxc.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 2f28299..0fc52d8 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -45,6 +45,15 @@ struct mxc_gpio_hwdata {
unsigned fall_edge;
};
+struct mxc_gpio_reg_saved {
+ u32 icr1;
+ u32 icr2;
+ u32 imr;
+ u32 gdir;
+ u32 edge_sel;
+ u32 dr;
+};
+
struct mxc_gpio_port {
struct list_head node;
void __iomem *base;
@@ -55,6 +64,7 @@ struct mxc_gpio_port {
struct gpio_chip gc;
struct device *dev;
u32 both_edges;
+ struct mxc_gpio_reg_saved gpio_saved_reg;
};
static struct mxc_gpio_hwdata imx1_imx21_gpio_hwdata = {
@@ -497,6 +507,8 @@ static int mxc_gpio_probe(struct platform_device *pdev)
list_add_tail(&port->node, &mxc_gpio_ports);
+ platform_set_drvdata(pdev, port);
+
return 0;
out_irqdomain_remove:
@@ -507,11 +519,67 @@ static int mxc_gpio_probe(struct platform_device *pdev)
return err;
}
+static void mxc_gpio_save_regs(struct mxc_gpio_port *port)
+{
+ if (mxc_gpio_hwtype == IMX21_GPIO)
+ return;
+
+ port->gpio_saved_reg.icr1 = readl(port->base + GPIO_ICR1);
+ port->gpio_saved_reg.icr2 = readl(port->base + GPIO_ICR2);
+ port->gpio_saved_reg.imr = readl(port->base + GPIO_IMR);
+ port->gpio_saved_reg.gdir = readl(port->base + GPIO_GDIR);
+ port->gpio_saved_reg.edge_sel = readl(port->base + GPIO_EDGE_SEL);
+ port->gpio_saved_reg.dr = readl(port->base + GPIO_DR);
+}
+
+static void mxc_gpio_restore_regs(struct mxc_gpio_port *port)
+{
+ if (mxc_gpio_hwtype == IMX21_GPIO)
+ return;
+
+ writel(port->gpio_saved_reg.icr1, port->base + GPIO_ICR1);
+ writel(port->gpio_saved_reg.icr2, port->base + GPIO_ICR2);
+ writel(port->gpio_saved_reg.imr, port->base + GPIO_IMR);
+ writel(port->gpio_saved_reg.gdir, port->base + GPIO_GDIR);
+ writel(port->gpio_saved_reg.edge_sel, port->base + GPIO_EDGE_SEL);
+ writel(port->gpio_saved_reg.dr, port->base + GPIO_DR);
+}
+
+static int __maybe_unused mxc_gpio_noirq_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct mxc_gpio_port *port = platform_get_drvdata(pdev);
+
+ mxc_gpio_save_regs(port);
+ clk_disable_unprepare(port->clk);
+
+ return 0;
+}
+
+static int __maybe_unused mxc_gpio_noirq_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct mxc_gpio_port *port = platform_get_drvdata(pdev);
+ int ret;
+
+ ret = clk_prepare_enable(port->clk);
+ if (ret)
+ return ret;
+ mxc_gpio_restore_regs(port);
+
+ return 0;
+}
+
+static const struct dev_pm_ops mxc_gpio_dev_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mxc_gpio_noirq_suspend,
mxc_gpio_noirq_resume)
+};
+
static struct platform_driver mxc_gpio_driver = {
.driver = {
.name = "gpio-mxc",
.of_match_table = mxc_gpio_dt_ids,
.suppress_bind_attrs = true,
+ .pm = &mxc_gpio_dev_pm_ops,
},
.probe = mxc_gpio_probe,
.id_table = mxc_gpio_devtype,
--
2.7.4
Re: [PATCH] kernel.h: Add for_each_if()
On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
> wrote:
>
> > To avoid compilers complainig about ambigious else blocks when putting
> > an if condition into a for_each macro one needs to invert the
> > condition and add a dummy else. We have a nice little convenience
> > macro for that in drm headers, let's move it out. Subsequent patches
> > will roll it out to other places.
> >
> > The issue the compilers complain about are nested if with an else
> > block and no {} to disambiguate which if the else belongs to. The C
> > standard is clear, but in practice people forget:
> >
> > if (foo)
> > if (bar)
> > /* something */
> > else
> > /* something else
>
> um, yeah, don't do that. Kernel coding style is very much to do
>
> if (foo) {
> if (bar)
> /* something */
> else
> /* something else
> }
>
> And if not doing that generates a warning then, well, do that.
>
> > The same can happen in a for_each macro when it also contains an if
> > condition at the end, except the compiler message is now really
> > confusing since there's only 1 if:
> >
> > for_each_something()
> > if (bar)
> > /* something */
> > else
> > /* something else
> >
> > The for_each_if() macro, by inverting the condition and adding an
> > else, avoids the compiler warning.
>
> Ditto.
>
> > Motivated by a discussion with Andy and Yisheng, who want to add
> > another for_each_macro which would benefit from for_each_if() instead
> > of hand-rolling it.
>
> Ditto.
>
> > v2: Explain a bit better what this is good for, after the discussion
> > with Peter Z.
>
> Presumably the above was discussed in whatever-thread-that-was.
So there's a bunch of open coded versions of this already in kernel
headers (at least the ones I've found). Not counting the big pile of
existing users in drm. They are all wrong and should be reverted to a
plain if? That why there's a bunch more patches in this series.
And yes I made it clear in the discussion that if you sprinkle enough {}
there's no warning, should have probably captured this here.
Aka a formal Nack-pls-keep-your-stuff-in-drm: would be appreciated so I
can stop bothering with this.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/2] arm64: dts: mt7622: update a clock property for UART0
The input clock of UART0 should be CLK_PERI_UART0_PD. Signed-off-by: Ryder Lee --- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi index 8cdec52..4caa9b4 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi @@ -367,7 +367,7 @@ reg = <0 0x11002000 0 0x400>; interrupts = ; clocks = <&topckgen CLK_TOP_UART_SEL>, -<&pericfg CLK_PERI_UART1_PD>; +<&pericfg CLK_PERI_UART0_PD>; clock-names = "baud", "bus"; status = "disabled"; }; -- 1.9.1
[PATCH 1/2] arm64: dts: mt7622: add some misc device nodes
Add some misc nodes support - timer and ARM CCI-400.
Signed-off-by: Ryder Lee
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 9213c96..8cdec52 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -217,6 +217,16 @@
#reset-cells = <1>;
};
+ timer: timer@10004000 {
+ compatible = "mediatek,mt7622-timer",
+"mediatek,mt6577-timer";
+ reg = <0 0x10004000 0 0x80>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_APXGPT_PD>,
+<&topckgen CLK_TOP_RTC>;
+ clock-names = "system-clk", "rtc-clk";
+ };
+
scpsys: scpsys@10006000 {
compatible = "mediatek,mt7622-scpsys",
"syscon";
@@ -317,6 +327,32 @@
<0 0x1036 0 0x2000>;
};
+ cci: cci@1039 {
+ compatible = "arm,cci-400";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0x1039 0 0x1000>;
+ ranges = <0 0 0x1039 0x1>;
+
+ cci_control0: slave-if@1000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace-lite";
+ reg = <0x1000 0x1000>;
+ };
+
+ cci_control1: slave-if@4000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x4000 0x1000>;
+ };
+
+ cci_control2: slave-if@5000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x5000 0x1000>;
+ };
+ };
+
auxadc: adc@11001000 {
compatible = "mediatek,mt7622-auxadc";
reg = <0 0x11001000 0 0x1000>;
--
1.9.1
Re: [RFC PATCH v2] watchdog: sp805: Add clock-frequency property
Hi Guenter,
Thank you for your feedback. Please find my answers in lined.
On Mon, Jul 9, 2018 at 7:15 PM, Guenter Roeck wrote:
> On 07/09/2018 03:19 AM, Srinath Mannam wrote:
>>
>> When using ACPI node, binding clock devices are
>> not available as device tree, So clock-frequency
>> property given in _DSD object of ACPI device is
>> used to calculate Watchdog rate.
>>
>> Signed-off-by: Srinath Mannam
>> ---
>> drivers/watchdog/sp805_wdt.c | 34 ++
>> 1 file changed, 26 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
>> index 9849db0..ad5ed64 100644
>> --- a/drivers/watchdog/sp805_wdt.c
>> +++ b/drivers/watchdog/sp805_wdt.c
>> @@ -11,6 +11,7 @@
>>* warranty of any kind, whether express or implied.
>>*/
>> +#include
>> #include
>> #include
>> #include
>> @@ -22,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -65,6 +67,7 @@ struct sp805_wdt {
>> spinlock_t lock;
>> void __iomem*base;
>> struct clk *clk;
>> + u64 rate;
>> struct amba_device *adev;
>> unsigned intload_val;
>> };
>> @@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd,
>> unsigned int timeout)
>> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>> u64 load, rate;
>> - rate = clk_get_rate(wdt->clk);
>> + rate = wdt->rate;
>> /*
>> * sp805 runs counter with given value twice, after the end of
>> first
>> @@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
>> unsigned int timeout)
>> static unsigned int wdt_timeleft(struct watchdog_device *wdd)
>> {
>> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>> - u64 load, rate;
>> -
>> - rate = clk_get_rate(wdt->clk);
>> + u64 load;
>> spin_lock(&wdt->lock);
>> load = readl_relaxed(wdt->base + WDTVALUE);
>> @@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct
>> watchdog_device *wdd)
>> load += wdt->load_val + 1;
>> spin_unlock(&wdt->lock);
>> - return div_u64(load, rate);
>> + return div_u64(load, wdt->rate);
>> }
>> static int
>> @@ -228,10 +229,27 @@ sp805_wdt_probe(struct amba_device *adev, const
>> struct amba_id *id)
>> if (IS_ERR(wdt->base))
>> return PTR_ERR(wdt->base);
>> - wdt->clk = devm_clk_get(&adev->dev, NULL);
>> - if (IS_ERR(wdt->clk)) {
>> + if (adev->dev.of_node) {
>> + wdt->clk = devm_clk_get(&adev->dev, NULL);
>> + if (IS_ERR(wdt->clk)) {
>> + ret = PTR_ERR(wdt->clk);
>> + wdt->clk = NULL;
>
>
> Clearing wdt->clk is useless.
If not, clk_prepare_enable and clk_disable_unprepare functions calls
made in this driver will crash.
>
>> + } else
>> + wdt->rate = clk_get_rate(wdt->clk);
>
>
> The else branch should be in { } as well per coding style.
I will add the change.
>
>> + } else if (has_acpi_companion(&adev->dev)) {
>> + /*
>> +* When Driver probe with ACPI device, clock devices
>> +* are not available, so watchdog rate get from
>> +* clock-frequency property given in _DSD object.
>> +*/
>> + device_property_read_u64(&adev->dev, "clock-frequency",
>> + &wdt->rate);
>
>
> Continuation line alignment is off.
I missed it, Thank you, I will make the change.
>
> Still not documented. Maybe that is common for ACPI devices nowadays.
> If so, I'll need at least a pointer to a document or something declaring
> that ACPI devices do not use well documented properties, and a confirmation
> that using such properties is acceptable in the Linux kernel.
>
patches listed below has same approach to add ACPI support.
ex:
1. commit 515da746983bc6382e380ba8b1ce9345a9550ffe
Author: Naveen Kaje
Date: Tue Oct 11 10:27:56 2016 -0600
i2c: qup: add ACPI support
2. commit 82a19035d000c8b4fd7d6f61b614f63dec75d389
Author: Lendacky, Thomas
Date: Fri Jan 16 12:47:16 2015 -0600
amd-xgbe: Add ACPI support
>> + if (!wdt->rate)
>> + ret = -ENODEV;
>> + }
>> +
>> + if (ret) {
>> dev_warn(&adev->dev, "Clock not found\n");
>> - ret = PTR_ERR(wdt->clk);
>> goto err;
>> }
>
>
> Please move the error handling to where the error occurs. While doing that,
> please change the message to dev_err() - this is an error, not a warning -
> and change the second error message to match the error (it did not find
> the property).
>
> Also, return directly - the goto just generates another error message
> which is
Re: [RFC PATCH v2] watchdog: sp805: Add clock-frequency property
Hi Guenter,
I missed your comment about "Clearing wdt->clk is useless." I will
remove that line.
Regards,
Srinath.
On Tue, Jul 10, 2018 at 1:27 PM, Srinath Mannam
wrote:
> Hi Guenter,
>
> Thank you for your feedback. Please find my answers in lined.
>
> On Mon, Jul 9, 2018 at 7:15 PM, Guenter Roeck wrote:
>> On 07/09/2018 03:19 AM, Srinath Mannam wrote:
>>>
>>> When using ACPI node, binding clock devices are
>>> not available as device tree, So clock-frequency
>>> property given in _DSD object of ACPI device is
>>> used to calculate Watchdog rate.
>>>
>>> Signed-off-by: Srinath Mannam
>>> ---
>>> drivers/watchdog/sp805_wdt.c | 34 ++
>>> 1 file changed, 26 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
>>> index 9849db0..ad5ed64 100644
>>> --- a/drivers/watchdog/sp805_wdt.c
>>> +++ b/drivers/watchdog/sp805_wdt.c
>>> @@ -11,6 +11,7 @@
>>>* warranty of any kind, whether express or implied.
>>>*/
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -22,6 +23,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -65,6 +67,7 @@ struct sp805_wdt {
>>> spinlock_t lock;
>>> void __iomem*base;
>>> struct clk *clk;
>>> + u64 rate;
>>> struct amba_device *adev;
>>> unsigned intload_val;
>>> };
>>> @@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd,
>>> unsigned int timeout)
>>> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>> u64 load, rate;
>>> - rate = clk_get_rate(wdt->clk);
>>> + rate = wdt->rate;
>>> /*
>>> * sp805 runs counter with given value twice, after the end of
>>> first
>>> @@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
>>> unsigned int timeout)
>>> static unsigned int wdt_timeleft(struct watchdog_device *wdd)
>>> {
>>> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>> - u64 load, rate;
>>> -
>>> - rate = clk_get_rate(wdt->clk);
>>> + u64 load;
>>> spin_lock(&wdt->lock);
>>> load = readl_relaxed(wdt->base + WDTVALUE);
>>> @@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct
>>> watchdog_device *wdd)
>>> load += wdt->load_val + 1;
>>> spin_unlock(&wdt->lock);
>>> - return div_u64(load, rate);
>>> + return div_u64(load, wdt->rate);
>>> }
>>> static int
>>> @@ -228,10 +229,27 @@ sp805_wdt_probe(struct amba_device *adev, const
>>> struct amba_id *id)
>>> if (IS_ERR(wdt->base))
>>> return PTR_ERR(wdt->base);
>>> - wdt->clk = devm_clk_get(&adev->dev, NULL);
>>> - if (IS_ERR(wdt->clk)) {
>>> + if (adev->dev.of_node) {
>>> + wdt->clk = devm_clk_get(&adev->dev, NULL);
>>> + if (IS_ERR(wdt->clk)) {
>>> + ret = PTR_ERR(wdt->clk);
>>> + wdt->clk = NULL;
>>
>>
>> Clearing wdt->clk is useless.
>
> If not, clk_prepare_enable and clk_disable_unprepare functions calls
> made in this driver will crash.
Sorry I missed your point. I will remove that.
>
>>
>>> + } else
>>> + wdt->rate = clk_get_rate(wdt->clk);
>>
>>
>> The else branch should be in { } as well per coding style.
> I will add the change.
>>
>>> + } else if (has_acpi_companion(&adev->dev)) {
>>> + /*
>>> +* When Driver probe with ACPI device, clock devices
>>> +* are not available, so watchdog rate get from
>>> +* clock-frequency property given in _DSD object.
>>> +*/
>>> + device_property_read_u64(&adev->dev, "clock-frequency",
>>> + &wdt->rate);
>>
>>
>> Continuation line alignment is off.
> I missed it, Thank you, I will make the change.
>>
>> Still not documented. Maybe that is common for ACPI devices nowadays.
>> If so, I'll need at least a pointer to a document or something declaring
>> that ACPI devices do not use well documented properties, and a confirmation
>> that using such properties is acceptable in the Linux kernel.
>>
> patches listed below has same approach to add ACPI support.
> ex:
> 1. commit 515da746983bc6382e380ba8b1ce9345a9550ffe
> Author: Naveen Kaje
> Date: Tue Oct 11 10:27:56 2016 -0600
>
> i2c: qup: add ACPI support
>
> 2. commit 82a19035d000c8b4fd7d6f61b614f63dec75d389
> Author: Lendacky, Thomas
> Date: Fri Jan 16 12:47:16 2015 -0600
>
> amd-xgbe: Add ACPI support
>
>>> + if (!wdt->rate)
>>> + ret = -ENODEV;
>>> + }
>>> +
>>> + if (ret) {
>>> dev_warn(&adev->dev, "Clock not found\n");
>>> - ret = PTR_ERR(wdt->clk);
>
Re: [PATCH 07/18] fs_context: fix double free of legacy_fs_context data
Eric Biggers wrote:
> Why isn't this done in the same place that ->init_fs_context() would otherwise
> be called? It logically does the same thing, right?
Fair point. How about the attached incremental change? It breaks the legacy
context initialisation out into its own init function and just sets that as
the default if the fs doesn't supply its own.
It also makes the freeing conditional.
David
---
diff --git a/fs/fs_context.c b/fs/fs_context.c
index 8af0542ab8b6..f388ab29d37d 100644
--- a/fs/fs_context.c
+++ b/fs/fs_context.c
@@ -42,6 +42,7 @@ struct legacy_fs_context {
enum legacy_fs_paramparam_type;
};
+static int legacy_init_fs_context(struct fs_context *fc, struct dentry
*dentry);
static const struct fs_context_operations legacy_fs_context_ops;
static const match_table_t common_set_sb_flag = {
@@ -239,6 +240,7 @@ struct fs_context *vfs_new_fs_context(struct
file_system_type *fs_type,
unsigned int sb_flags,
enum fs_context_purpose purpose)
{
+ int (*init_fs_context)(struct fs_context *, struct dentry *);
struct fs_context *fc;
int ret = -ENOMEM;
@@ -246,15 +248,6 @@ struct fs_context *vfs_new_fs_context(struct
file_system_type *fs_type,
if (!fc)
return ERR_PTR(-ENOMEM);
- if (!fs_type->init_fs_context) {
- fc->fs_private = kzalloc(sizeof(struct legacy_fs_context),
-GFP_KERNEL);
- if (!fc->fs_private)
- goto err_fc;
-
- fc->ops = &legacy_fs_context_ops;
- }
-
fc->purpose = purpose;
fc->sb_flags= sb_flags;
fc->fs_type = get_filesystem(fs_type);
@@ -285,11 +278,13 @@ struct fs_context *vfs_new_fs_context(struct
file_system_type *fs_type,
/* TODO: Make all filesystems support this unconditionally */
- if (fc->fs_type->init_fs_context) {
- ret = fc->fs_type->init_fs_context(fc, reference);
- if (ret < 0)
- goto err_fc;
- }
+ init_fs_context = fc->fs_type->init_fs_context;
+ if (!init_fs_context)
+ init_fs_context = legacy_init_fs_context;
+
+ ret = (*init_fs_context)(fc, reference);
+ if (ret < 0)
+ goto err_fc;
/* Do the security check last because ->init_fs_context may change the
* namespace subscriptions.
@@ -499,19 +494,21 @@ static void legacy_fs_context_free(struct fs_context *fc)
{
struct legacy_fs_context *ctx = fc->fs_private;
- free_secdata(ctx->secdata);
- switch (ctx->param_type) {
- case LEGACY_FS_UNSET_PARAMS:
- case LEGACY_FS_NO_PARAMS:
- break;
- case LEGACY_FS_MAGIC_PARAMS:
- break; /* ctx->data is a weird pointer */
- default:
- kfree(ctx->legacy_data);
- break;
- }
+ if (ctx) {
+ free_secdata(ctx->secdata);
+ switch (ctx->param_type) {
+ case LEGACY_FS_UNSET_PARAMS:
+ case LEGACY_FS_NO_PARAMS:
+ break;
+ case LEGACY_FS_MAGIC_PARAMS:
+ break; /* ctx->data is a weird pointer */
+ default:
+ kfree(ctx->legacy_data);
+ break;
+ }
- kfree(ctx);
+ kfree(ctx);
+ }
}
/*
@@ -707,3 +704,18 @@ static const struct fs_context_operations
legacy_fs_context_ops = {
.validate = legacy_validate,
.get_tree = legacy_get_tree,
};
+
+/*
+ * Initialise a legacy context for a filesystem that doesn't support
+ * fs_context.
+ */
+static int legacy_init_fs_context(struct fs_context *fc, struct dentry *dentry)
+{
+
+ fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL);
+ if (!fc->fs_private)
+ return -ENOMEM;
+
+ fc->ops = &legacy_fs_context_ops;
+ return 0;
+}
Re: [PATCH v3] soc: imx: gpc: Turn PU domain on/off in sleep on 6qp
Am Dienstag, den 10.07.2018, 00:27 +0200 schrieb Ulf Hansson: > > On 6 July 2018 at 18:46, Leonard Crestez wrote: > > On imx6qp power gating on the PU domain is disabled because of errata > > ERR009619. However power gating during suspend/resume can still be > > performed. > > Sounds a bit hand wavy. Exactly why can it be done during system > suspend/resume? Power gating this domain in normal operation may introduce a glitch in unrelated modules, potentially disturbing a running display scanout. This is not a concern when the whole system enters suspend state, so it's safe to do in this case. Regards, Lucas > > > > Enable this by implementing SLEEP_PM_OPS in imx_pgc_power_domain_driver. > > > > In order to ensure correct ordering add device links from devices inside > > the PU domain to the pgc platform_device. > > In genpd, the PM domain gets powered off after all device's > corresponding ->suspend_noirq() callback has been invoked - and it > also considers if there are some wakeup settings enabled, possibly > avoiding to do the power off. > > It sound like the imx's power domain driver ->power_off|on() callback > should deal with this, to make get a consistent behavior. I understand > that you currently can't tell under what circumstances the > ->power_off|on() callbacks are being invoked, that may need some > changes in genpd. > > Currently we have a flag, GENPD_FLAG_ALWAYS_ON which makes genpd to > always prevent power off. Perhaps we should add a new flag > "GENPD_FLAG_RUNTIME_ON", which makes genpd to call the > ->power_on|off() callbacks, but only during system wide PM. > > Thoughts? Yes, this might work for this case. Regards, Lucas
Re: [PATCH] netfilter: NFT_SOCKET don't use NF_SOCKET_IPV6 without NF_TABLES_IPV6
On Tue, Jul 10, 2018 at 10:02:27AM +0200, Máté Eckl wrote:
> On Mon, Jul 09, 2018 at 11:35:09PM +0200, Arnd Bergmann wrote:
> > It is now possible to build the nft_socket module as built-in when
> > NF_TABLES_IPV6 is disabled, and have NF_SOCKET_IPV6=m set manually.
> >
> > In this case, the NF_SOCKET_IPV6 functionality will be useless according
> > to the explanation in commit 35bf1ccecaaa ("netfilter: Kconfig: Change
> > IPv6 select dependencies"), but on top of that it also causes a link
> > error:
> >
> > net/netfilter/nft_socket.o: In function `nft_socket_eval':
> > nft_socket.c:(.text+0x162): undefined reference to `nf_sk_lookup_slow_v6'
> >
> > This changes the compile-time check so we don't attempt to use
> > the NF_SOCKET_IPV6 code when it cannot be used, and make it all
> > compile again. That may lead to unexpected behavior when a user
> > enables NF_SOCKET_IPV6 but cannot use it, but seems to be the
> > logical conclusion of the 35bf1ccecaaa change.
> >
> > Fixes: 35bf1ccecaaa ("netfilter: Kconfig: Change IPv6 select dependencies")
> > Signed-off-by: Arnd Bergmann
>
> I think this should be fixed in the Kconfig rather than inside the module(s).
>
> I did some investigation and it turns out that you missed a circumstance. This
> link error occures only if NFT_SOCKET=y && NF_SOCKET_IPV6=m &&
> NF_TABLES_IPV6=y
> (cannot be m here if NFT_SOCKET is y). And probably the same with
> iptables-related modules. Probably this possibility should be eliminated.
NF_TPROXY_IPV6 might be in the same situation.
Re: [PATCH v12 05/13] x86/sgx: architectural structures
On Fri, Jul 6, 2018 at 12:50 AM, wrote:
> On July 5, 2018 1:09:12 PM PDT, Jarkko Sakkinen
> wrote:
>>On Thu, Jul 05, 2018 at 08:31:42AM -0700, Dave Hansen wrote:
>>> On 07/03/2018 11:19 AM, Jarkko Sakkinen wrote:
>>> > +struct sgx_secs {
>>> > + uint64_t size;
>>> > + uint64_t base;
>>> > + uint32_t ssaframesize;
>>> > + uint32_t miscselect;
>>> > + uint8_t reserved1[SGX_SECS_RESERVED1_SIZE];
>>> > + uint64_t attributes;
>>> > + uint64_t xfrm;
>>> > + uint32_t mrenclave[8];
>>> > + uint8_t reserved2[SGX_SECS_RESERVED2_SIZE];
>>> > + uint32_t mrsigner[8];
>>> > + uint8_t reserved3[SGX_SECS_RESERVED3_SIZE];
>>> > + uint16_t isvvprodid;
>>> > + uint16_t isvsvn;
>>> > + uint8_t reserved4[SGX_SECS_RESERVED4_SIZE];
>>> > +} __packed __aligned(4096);
>>>
>>> Why are the uint* versions in use here? Those are for userspace ABI,
>>> but this is entirely for in-kernel-use, right?
>>>
>>> We've used u8/16/32/64 in arch code in a bunch of places. They're at
>>> least a bit more compact and easier to read. It's this:
>>>
>>> u8 foo;
>>> u64 bar;
>>>
>>> vs. this:
>>>
>>> uint8_t foo;
>>> uint64_t bar;
>>
>>The reason was that with in-kernel LE these were in fact used by
>>user space code. Now they can be changed to those that you
>>suggested.
> For things exported to user space use __u* and __s* types... the _t types
> would actually violate the C standard with respect to namespace pollution.
Hmm... Coding style 5(d) allows to use uintNN_t in new code (as a
variation of uNN choice).
--
With Best Regards,
Andy Shevchenko
INFO: task hung in utimes_common
Hello, syzbot found the following crash on: HEAD commit:d00d6d9a339d Add linux-next specific files for 20180709 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=17fdd90c40 kernel config: https://syzkaller.appspot.com/x/.config?x=94fe2b586beccacd dashboard link: https://syzkaller.appspot.com/bug?extid=3a0570f93c0d6ca388f5 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+3a0570f93c0d6ca38...@syzkaller.appspotmail.com 9pnet_virtio: no channels available for device (null) Unknown ioctl 44801 9pnet_virtio: no channels available for device (null) 9pnet: Insufficient options for proto=fd 9pnet: Insufficient options for proto=fd INFO: task syz-executor0:12044 blocked for more than 140 seconds. Not tainted 4.18.0-rc3-next-20180709+ #2 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor0 D25408 12044 4539 0x0004 Call Trace: context_switch kernel/sched/core.c:2853 [inline] __schedule+0x87c/0x1ed0 kernel/sched/core.c:3501 schedule+0xfb/0x450 kernel/sched/core.c:3545 __rwsem_down_write_failed_common+0x95d/0x1630 kernel/locking/rwsem-xadd.c:566 rwsem_down_write_failed+0xe/0x10 kernel/locking/rwsem-xadd.c:595 call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117 __down_write arch/x86/include/asm/rwsem.h:142 [inline] down_write+0xaa/0x130 kernel/locking/rwsem.c:72 inode_lock include/linux/fs.h:748 [inline] utimes_common.isra.1+0x45c/0x8e0 fs/utimes.c:90 do_utimes+0x1f7/0x380 fs/utimes.c:156 do_futimesat+0x249/0x350 fs/utimes.c:212 __do_sys_utimes fs/utimes.c:225 [inline] __se_sys_utimes fs/utimes.c:222 [inline] __x64_sys_utimes+0x59/0x80 fs/utimes.c:222 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x455e29 Code: cc 64 48 8b 0c 25 f8 ff ff ff 48 3b 61 10 0f 86 ab 04 00 00 48 83 ec 58 48 89 6c 24 50 48 8d 6c 24 50 48 8b 44 24 60 c6 00 00 <48> 8b 4c 24 68 48 89 ca 48 89 50 08 48 8b 59 20 48 01 da 31 db 31 RSP: 002b:7fac7c8b4c68 EFLAGS: 0246 ORIG_RAX: 00eb RAX: ffda RBX: 7fac7c8b56d4 RCX: 00455e29 RDX: RSI: 2380 RDI: 2180 RBP: 0072bff0 R08: R09: R10: R11: 0246 R12: R13: 004c2af0 R14: 004d4600 R15: 0002 INFO: lockdep is turned off. NMI backtrace for cpu 1 CPU: 1 PID: 898 Comm: khungtaskd Not tainted 4.18.0-rc3-next-20180709+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 nmi_cpu_backtrace.cold.5+0x19/0xce lib/nmi_backtrace.c:103 nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 trigger_all_cpu_backtrace include/linux/nmi.h:143 [inline] check_hung_uninterruptible_tasks kernel/hung_task.c:204 [inline] watchdog+0xb39/0x10b0 kernel/hung_task.c:265 kthread+0x345/0x410 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
[PATCH v5 17/22] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver
This adds a device-tree binding document that specifies the properties
used by the Sunxi-Cedurs VPU driver, as well as examples.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Rob Herring
---
.../bindings/media/sunxi-cedrus.txt | 54 +++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
new file mode 100644
index ..a089a0c1ff05
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
@@ -0,0 +1,54 @@
+Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
+Video Engine (VE) in Allwinner literature.
+
+The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
+from the DRAM base. This requires specific memory allocation and handling.
+
+Required properties:
+- compatible : must be one of the following compatibles:
+ - "allwinner,sun4i-a10-video-engine"
+ - "allwinner,sun5i-a13-video-engine"
+ - "allwinner,sun7i-a20-video-engine"
+ - "allwinner,sun8i-a33-video-engine"
+ - "allwinner,sun8i-h3-video-engine"
+- reg : register base and length of VE;
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names : should contain "ahb", "mod" and "ram" entries;
+- resets : phandle for reset;
+- interrupts : VE interrupt number;
+- allwinner,sram : SRAM region to use with the VE.
+
+Optional properties:
+- memory-region: CMA pool to use for buffers allocation
instead of the
+ default CMA pool.
+
+Example:
+
+reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+ cma_pool: cma@4a00 {
+ compatible = "shared-dma-pool";
+ size = <0x600>;
+ alloc-ranges = <0x4a00 0x600>;
+ reusable;
+ linux,cma-default;
+ };
+};
+
+video-codec@1c0e000 {
+ compatible = "allwinner,sun7i-a20-video-engine";
+ reg = <0x01c0e000 0x1000>;
+
+ clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>,
+<&ccu CLK_DRAM_VE>;
+ clock-names = "ahb", "mod", "ram";
+
+ resets = <&ccu RST_VE>;
+ interrupts = ;
+ allwinner,sram = <&ve_sram 1>;
+};
--
2.17.1
Re: INFO: task hung in utimes_common
On Tue, Jul 10, 2018 at 10:08 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:d00d6d9a339d Add linux-next specific files for 20180709
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17fdd90c40
> kernel config: https://syzkaller.appspot.com/x/.config?x=94fe2b586beccacd
> dashboard link: https://syzkaller.appspot.com/bug?extid=3a0570f93c0d6ca388f5
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3a0570f93c0d6ca38...@syzkaller.appspotmail.com
Look similar to the other hangs in 9p, this time caused by the
following program:
21:30:55 executing program 0:
pipe2$9p(&(0x7f000100)={0x,
0x}, 0x0)
write$P9_RUNLINKAT(r1, &(0x7f40)={0xffca, 0x4d}, 0x7)
mkdir(&(0x7f000300)='./file0\x00', 0x0)
mount$9p_fd(0x0, &(0x7fc0)='./file0\x00',
&(0x7f000340)='9p\x00', 0x0, &(0x7f0001c0)={'trans=fd,',
{'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c})
write$P9_RREADDIR(r1, &(0x7f000480)={0x2a, 0x29, 0x1, {0x0, [{{},
0x0, 0x0, 0x7, './file0'}]}}, 0x2a)
write$P9_RGETATTR(r1, &(0x7f000200)={0xa0, 0x19, 0x1}, 0xa0)
write$P9_RWALK(r1, &(0x7f000500)=ANY=[@ANYBLOB="09016f0100"], 0x9)
mount$9p_fd(0x0, &(0x7f80)='./file0\x00',
&(0x7f000900)='9p\x00', 0x0, &(0x7f000840)={'trans=fd,',
{'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c,
{[{@access_uid={'access', 0x3d}, 0x2c}]}})
r2 = socket$inet6(0xa, 0x10002, 0x0)
ioctl(r2, 0x8912, &(0x7f000280)="025cc83d6d345f8f762070")
utimes(&(0x7f000180)='./file0\x00', &(0x7f000380))
> 9pnet_virtio: no channels available for device (null)
> Unknown ioctl 44801
> 9pnet_virtio: no channels available for device (null)
> 9pnet: Insufficient options for proto=fd
> 9pnet: Insufficient options for proto=fd
> INFO: task syz-executor0:12044 blocked for more than 140 seconds.
> Not tainted 4.18.0-rc3-next-20180709+ #2
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> syz-executor0 D25408 12044 4539 0x0004
> Call Trace:
> context_switch kernel/sched/core.c:2853 [inline]
> __schedule+0x87c/0x1ed0 kernel/sched/core.c:3501
> schedule+0xfb/0x450 kernel/sched/core.c:3545
> __rwsem_down_write_failed_common+0x95d/0x1630
> kernel/locking/rwsem-xadd.c:566
> rwsem_down_write_failed+0xe/0x10 kernel/locking/rwsem-xadd.c:595
> call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117
> __down_write arch/x86/include/asm/rwsem.h:142 [inline]
> down_write+0xaa/0x130 kernel/locking/rwsem.c:72
> inode_lock include/linux/fs.h:748 [inline]
> utimes_common.isra.1+0x45c/0x8e0 fs/utimes.c:90
> do_utimes+0x1f7/0x380 fs/utimes.c:156
> do_futimesat+0x249/0x350 fs/utimes.c:212
> __do_sys_utimes fs/utimes.c:225 [inline]
> __se_sys_utimes fs/utimes.c:222 [inline]
> __x64_sys_utimes+0x59/0x80 fs/utimes.c:222
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x455e29
> Code: cc 64 48 8b 0c 25 f8 ff ff ff 48 3b 61 10 0f 86 ab 04 00 00 48 83 ec
> 58 48 89 6c 24 50 48 8d 6c 24 50 48 8b 44 24 60 c6 00 00 <48> 8b 4c 24 68 48
> 89 ca 48 89 50 08 48 8b 59 20 48 01 da 31 db 31
> RSP: 002b:7fac7c8b4c68 EFLAGS: 0246 ORIG_RAX: 00eb
> RAX: ffda RBX: 7fac7c8b56d4 RCX: 00455e29
> RDX: RSI: 2380 RDI: 2180
> RBP: 0072bff0 R08: R09:
> R10: R11: 0246 R12:
> R13: 004c2af0 R14: 004d4600 R15: 0002
> INFO: lockdep is turned off.
> NMI backtrace for cpu 1
> CPU: 1 PID: 898 Comm: khungtaskd Not tainted 4.18.0-rc3-next-20180709+ #2
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> nmi_cpu_backtrace.cold.5+0x19/0xce lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_all_cpu_backtrace include/linux/nmi.h:143 [inline]
> check_hung_uninterruptible_tasks kernel/hung_task.c:204 [inline]
> watchdog+0xb39/0x10b0 kernel/hung_task.c:265
> kthread+0x345/0x410 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
> Sending NMI from CPU 1 to CPUs 0:
> NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0x6/0x10
> arch/x86/include/asm/irqflags.h:54
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot wil
Re: [PATCH] mmc: core: improve rationality of bus width setting for HS400es
On 10 July 2018 at 07:04, Fang Hongjie(方洪杰) wrote:
>> On 9 July 2018 at 08:47, Hongjie Fang wrote:
>> > mmc_select_hs400es() calls mmc_select_bus_width() which will try to
>> > set 4bit transfer mode if fail to set 8bit mode. The problem is that
>> > the bus width should not be set to 4bit in HS400es mode.
>>
>> I guess it fails because there is something wrong. Can you please
>> elaborate under what circumstance the problem occurs?
>>
> This problem very occasionally occurred when system resume from
> suspend state. The card stuck in the programming state after setting
> 8bit mode. After that, mmc_select_bus_width() will continue to set
> 4bit mode and return without errors. Of course, the following R/W
> requests will be all failing.
I see. So it's the mmc_switch() operation that fails, when trying 8-bit. Hmm.
>
> The problem scene is hard to reproduce. Maybe it happened
> because there is something wrong about bus clock or core voltage
> stability when system do resume.
Yeah, that needs further debugging.
Don't know what host driver you are using, but potentially you could
play with a couple host specific mechanism. The ->host->card_busy()
callback, host->max_busy_timeout and MMC_CAP_WAIT_WHILE_BUSY.
Depending on these, __mmc_switch() changes its policy when polling for
busy. Have a look at __mmc_switch() and mmc_poll_for_busy(), to see
what goes on.
>
>> >
>> > Signed-off-by: Hongjie Fang
>> > ---
>> > drivers/mmc/core/mmc.c | 23 +--
>> > 1 file changed, 21 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> > index 4466f5d..94c3cc5 100644
>> > --- a/drivers/mmc/core/mmc.c
>> > +++ b/drivers/mmc/core/mmc.c
>> > @@ -1337,9 +1337,28 @@ static int mmc_select_hs400es(struct mmc_card *card)
>> > if (err)
>> > goto out_err;
>> >
>> > - err = mmc_select_bus_width(card);
>> > - if (err < 0)
>> > + /* Switch card to 8 bit mode */
>> > + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> > +EXT_CSD_BUS_WIDTH,
>> > +EXT_CSD_BUS_WIDTH_8,
>> > +card->ext_csd.generic_cmd6_time);
>> > + if (err) {
>> > + pr_err("%s: switch to 8 bit mode for hs400es failed,
>> > err:%d\n",
>> > + mmc_hostname(host), err);
>> > + goto out_err;
>> > + }
>> > +
>> > + mmc_set_bus_width(host, MMC_BUS_WIDTH_8);
>> > +
>> > + if (!(host->caps & MMC_CAP_BUS_WIDTH_TEST))
>> > + err = mmc_compare_ext_csds(card, MMC_BUS_WIDTH_8);
>> > + else
>> > + err = mmc_bus_test(card, MMC_BUS_WIDTH_8);
>> > + if (err) {
>> > + pr_err("%s: test 8 bit mode for hs400es failed, err:%d\n",
>> > + mmc_hostname(host), err);
>> > goto out_err;
>>
>> Lot's open coding, no I don't like it.
>>
>> Wouldn't it instead be possible to check the return value from
>> mmc_select_bus_width(), as it should tell what width it manage to
>> select. Then if it isn't 8-bit, then we should bail out. Does that
>> work?
>>
> After setting 4bit mode, it can't work because it cannot back to
> HS200 mode like the HS400 mode.
> For HS400es, if fail to set 8bit mode, maybe it is more reasonable
> that return error directly.
Yeah. Care to send a patch for that?
[...]
Kind regards
Uffe
Re: 回复：Re：[RFC] a question about reuse hwpoison page in soft_offline_page()
Hi Xishi,
On Mon, Jul 09, 2018 at 09:13:07PM +0800, 裘稀石(稀石) wrote:
> Hi Naoya,
>
> - does the same issue happens on soft offlining of normal pages?
>
> I thinks yes. We can do anything during get_any_page and set hwpoison flag.
> soft_offline_page
> get_any_page
> soft_offline_free_page
> SetPageHWPoison
>
> I search the key word of PageHWPoison, and these two paths maybe have issue.
> do_swap_page
> if (PageHWPoison(page)) - ret = VM_FAULT_HWPOISON;
> __do_fault
> if (unlikely(PageHWPoison(vmf->page))) - return VM_FAULT_HWPOISON;
>
> It may cause mce kill later.
I agree.
I checked git history and found some related to this race.
IIRC, the race windows seems to open at commit c6c919eb90e0 ("mm: use put_page()
to free page instead of putback_lru_page()") which makes migration source pages
freed by put_page().
Before that commit, we kept migration source pages pinned to avoid reusing,
introduced by commit add05cecef80 ("mm: soft-offline: don't free target page
in successful page migration".)
And before this commit, migration source pages were freed via putback_lru_page()
with changing migration type to MIGRATE_ISOLATE.
The oldest behavior was buggy because of freeing with putback_lru_page(),
but "changing migration type" part was still correct if there's a time window
between freeing a page and setting the PageHWPoison flag.
At c6c919eb90e0 we returned back to the behavior of releasing source pages
(then we have such time window again,) so we should have restored to change
the migration type.
So I feel that this solves the above issues in the normal page's case.
Does it make sense?
This part of code has changed repeatedly and it's painful to track the whole
story in git-log, so I'll clarify the latest (hopefully saner) behavior
in inline comment.
>
> As you said allocation failure, I think we will get oom first.
We get OOM if alloc_huge_page() returns ENOMEM, and that happens when
- vma_needs_reservation() returns negative value,
- hugetlb_cgroup_charge_cgroup() fails to charge.
It seems to me that hwposion doesn't affect both of these.
I presumed that dequeue_huge_page_vma() failed with NULL return due to
dequeue_huge_page_node_exact()'s failure.
And the result should be ENOSPC or allocation success by overcommitting.
So the allocation failure might cause sigbus?
>
> - does hard offling of free (huge) page have the similar issue?
> We can kill process in anytime, right?
Yes, so as-is might be fine.
Thanks,
Naoya Horiguchi
>
> Thanks,
> Xishi Qiu
> On Mon, Jul 09, 2018 at 01:43:35PM +0800, 裘稀石(稀石) wrote:
> > Hi Naoya,
> >
> > Shall we fix this path too? It also will set hwpoison before
> > dissolve_free_huge_page().
> >
> > soft_offline_huge_page
> > migrate_pages
> > unmap_and_move_huge_page
> > if (reason == MR_MEMORY_FAILURE && !test_set_page_hwpoison
> (hpage))
> > dissolve_free_huge_page
>
> Thank you Xishi, I added it to the current (still draft) version below.
>
> I start feeling that current code is broken about behavior of PageHWPoison
> (at least) in soft offline. And this patch might not cover all of the issues.
> My current questions/concerns are:
>
> - does the same issue happens on soft offlining of normal pages?
> - does hard offling of free (huge) page have the similar issue?
>
> I'll try to clarify these next and will update the patch if necessary.
> I'm happy if I get some comment around these.
>
> Thanks,
> Naoya Horiguchi
> ---
> From 9ce4df899f4c859001571958be6a281cdaf5a58f Mon Sep 17 00:00:00 2001
> From: Naoya Horiguchi
> Date: Mon, 9 Jul 2018 13:07:46 +0900
> Subject: [PATCH] mm: fix race on soft-offlining free huge pages
>
> There's a race condition between soft offline and hugetlb_fault which
> causes unexpected process killing and/or hugetlb allocation failure.
>
> The process killing is caused by the following flow:
>
> CPU 0 CPU 1 CPU 2
>
> soft offline
> get_any_page
> // find the hugetlb is free
> mmap a hugetlb file
> page fault
> ...
> hugetlb_fault
> hugetlb_no_page
> alloc_huge_page
> // succeed
> soft_offline_free_page
> // set hwpoison flag
> mmap the hugetlb file
> page fault
>...
> hugetlb_fault
>hugetlb_no_page
> find_lock_page
>return VM_FAULT_HWPOISON
>mm_fault_error
> do_sigbus
> // kill the process
Re: [PATCH 0/2] mm/fs: put_user_page() proposal
On Mon 09-07-18 13:00:49, Matthew Wilcox wrote: > On Mon, Jul 09, 2018 at 09:47:40PM +0200, Jan Kara wrote: > > On Mon 09-07-18 10:16:51, Matthew Wilcox wrote: > > > > 2) What to do when some page is pinned but we need to do e.g. > > > > clear_page_dirty_for_io(). After some more thinking I agree with you > > > > that > > > > just blocking waiting for page to unpin will create deadlocks like: > > > > > > Why are we trying to writeback a page that is pinned? It's presumed to > > > be continuously redirtied by its pinner. We can't evict it. > > > > So what should be a result of fsync(file), where some 'file' pages are > > pinned e.g. by running direct IO? If we just skip those pages, we'll lie to > > userspace that data was committed while it was not (and it's not only about > > data that has landed in those pages via DMA, you can have first 1k of a page > > modified by normal IO in parallel to DMA modifying second 1k chunk). If > > fsync(2) returns error, it would be really unexpected by userspace and most > > apps will just not handle that correctly. So what else can you do than > > block? > > I was thinking about writeback, and neglected the fsync case. For memory cleaning writeback skipping is certainly the right thing to do and that's what we plan to do. > For fsync, we could copy the "current" contents of the page to a > freshly-allocated page and write _that_ to disc? As long as we redirty > the real page after the pin is dropped, I think we're fine. So for record, this technique is called "bouncing" in block layer terminology and we do have a support for it there (see block/bounce.c). It would need some tweaking (e.g. a bio flag to indicate that some page in a bio needs bouncing if underlying storage requires stable pages) but that is easy to do - we even had support for something similar some years back as ext3 needed it to provide guarantee metadata buffer cannot be modified while IO is running on it. I was actually already considering using this some time ago but then disregarded it as it seemed it won't buy us much compared to blocking / skipping. But now seeing the troubles with blocking, using page bouncing for situations where we cannot just skip page writeout looks indeed appealing. Thanks for suggesting that! As a side note I'm not 100% decided whether it is better to keep the original page dirty all the time while it is pinned or not. I'm more inclined to keeping it dirty all the time as it gives mm more accurate information about the amount of really dirty pages, prevents reclaim of filesystem's dirtiness / allocation tracking information (buffers or whatever it has attached to the page), and generally avoids "surprising" set_page_dirty() once page is unpinned (one less dirtying path for filesystems to care about). OTOH it would make flusher threads always try to writeback these pages only to skip them, fsync(2) would always write them, etc... Honza -- Jan Kara SUSE Labs, CR
[PATCH v1 0/4] add memcpy support for sdma
This patchset is to add memcpy interface for imx-sdma, besides,to support dmatest and enable config related, so that easily test dma without any other device support such as uart/audio/spi... Robin Gong (4): dmaengine: imx-sdma: add memcpy interface dmaengine: imx-sdma: add check_bd_buswidth() to kill the dulicated code dmaengine: imx-sdma: support dmatest ARM: configs: imx_v6_v7_defconfig: add DMATEST support arch/arm/configs/imx_v6_v7_defconfig | 3 +- drivers/dma/imx-sdma.c | 172 --- 2 files changed, 139 insertions(+), 36 deletions(-) -- 2.7.4
[PATCH V2 0/4] Fix kvm misconceives NVDIMM pages as reserved mmio
For device specific memory space, when we move these area of pfn to memory zone, we will set the page reserved flag at that time, some of these reserved for device mmio, and some of these are not, such as NVDIMM pmem. Now, we map these dev_dax or fs_dax pages to kvm for DIMM/NVDIMM backend, since these pages are reserved. the check of kvm_is_reserved_pfn() misconceives those pages as MMIO. Therefor, we introduce 2 page map types, MEMORY_DEVICE_FS_DAX/MEMORY_DEVICE_DEV_DAX, to indentify these pages are from NVDIMM pmem. and let kvm treat these as normal pages. Without this patch, Many operations will be missed due to this mistreatment to pmem pages. For example, a page may not have chance to be unpinned for KVM guest(in kvm_release_pfn_clean); not able to be marked as dirty/accessed(in kvm_set_pfn_dirty/accessed) etc. V1: https://lkml.org/lkml/2018/7/4/91 V2: *Add documentation for MEMORY_DEVICE_DEV_DAX memory type in comment block *Add is_dax_page() in mm.h to differentiate the pages is from DAX device. *Remove the function kvm_is_nd_pfn(). Zhang Yi (4): kvm: remove redundant reserved page check mm: introduce memory type MEMORY_DEVICE_DEV_DAX mm: add a function to differentiate the pages is from DAX device memory kvm: add a check if pfn is from NVDIMM pmem. drivers/dax/pmem.c | 1 + include/linux/memremap.h | 9 + include/linux/mm.h | 12 virt/kvm/kvm_main.c | 16 4 files changed, 30 insertions(+), 8 deletions(-) -- 2.7.4
[PATCH v1 0/4] add memcpy support for sdma
This patchset is to add memcpy interface for imx-sdma, besides,to support dmatest and enable config related, so that easily test dma without any other device support such as uart/audio/spi... Robin Gong (4): dmaengine: imx-sdma: add memcpy interface dmaengine: imx-sdma: add check_bd_buswidth() to kill the dulicated code dmaengine: imx-sdma: support dmatest ARM: configs: imx_v6_v7_defconfig: add DMATEST support arch/arm/configs/imx_v6_v7_defconfig | 3 +- drivers/dma/imx-sdma.c | 172 --- 2 files changed, 139 insertions(+), 36 deletions(-) -- 2.7.4
[PATCH V2 3/4] mm: add a function to differentiate the pages is from DAX device memory
DAX driver hotplug the device memory and move it to memory zone, these
pages will be marked reserved flag, however, some other kernel componet
will misconceive these pages are reserved mmio (ex: we map these dev_dax
or fs_dax pages to kvm for DIMM/NVDIMM backend). Together with the type
MEMORY_DEVICE_FS_DAX, we can use is_dax_page() to differentiate the pages
is DAX device memory or not.
Signed-off-by: Zhang Yi
Signed-off-by: Zhang Yu
---
include/linux/mm.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6e19265..9f0f690 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -856,6 +856,13 @@ static inline bool is_device_public_page(const struct page
*page)
page->pgmap->type == MEMORY_DEVICE_PUBLIC;
}
+static inline bool is_dax_page(const struct page *page)
+{
+ return is_zone_device_page(page) &&
+ (page->pgmap->type == MEMORY_DEVICE_FS_DAX ||
+ page->pgmap->type == MEMORY_DEVICE_DEV_DAX);
+}
+
#else /* CONFIG_DEV_PAGEMAP_OPS */
static inline void dev_pagemap_get_ops(void)
{
@@ -879,6 +886,11 @@ static inline bool is_device_public_page(const struct page
*page)
{
return false;
}
+
+static inline bool is_dax_page(const struct page *page)
+{
+ return false;
+}
#endif /* CONFIG_DEV_PAGEMAP_OPS */
static inline void get_page(struct page *page)
--
2.7.4
[PATCH v1 1/4] dmaengine: imx-sdma: add memcpy interface
Add MEMCPY support, meanwhile, add SDMA_BD_MAX_CNT instead
of '0x'.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 104 ++---
1 file changed, 98 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 3b622d6..27ccabf 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -341,6 +341,7 @@ struct sdma_desc {
* @pc_from_device:script address for those device_2_memory
* @pc_to_device: script address for those memory_2_device
* @device_to_device: script address for those device_2_device
+ * @pc_to_pc: script address for those memory_2_memory
* @flags: loop mode or not
* @per_address: peripheral source or destination address in common case
* destination address in p_2_p case
@@ -366,6 +367,7 @@ struct sdma_channel {
enum dma_slave_buswidth word_size;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
+ unsigned intpc_to_pc;
unsigned long flags;
dma_addr_t per_address, per_address2;
unsigned long event_mask[2];
@@ -385,6 +387,8 @@ struct sdma_channel {
#define SDMA_FIRMWARE_MAGIC 0x414d4453
+#define SDMA_BD_MAX_CNT0x
+
/**
* struct sdma_firmware_header - Layout of the firmware image
*
@@ -868,14 +872,16 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
* These are needed once we start to support transfers between
* two peripherals or memory-to-memory transfers
*/
- int per_2_per = 0;
+ int per_2_per = 0, emi_2_emi = 0;
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
sdmac->device_to_device = 0;
+ sdmac->pc_to_pc = 0;
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
+ emi_2_emi = sdma->script_addrs->ap_2_ap_addr;
break;
case IMX_DMATYPE_DSP:
emi_2_per = sdma->script_addrs->bp_2_ap_addr;
@@ -948,6 +954,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
sdmac->device_to_device = per_2_per;
+ sdmac->pc_to_pc = emi_2_emi;
}
static int sdma_load_context(struct sdma_channel *sdmac)
@@ -964,6 +971,8 @@ static int sdma_load_context(struct sdma_channel *sdmac)
load_address = sdmac->pc_from_device;
else if (sdmac->direction == DMA_DEV_TO_DEV)
load_address = sdmac->device_to_device;
+ else if (sdmac->direction == DMA_MEM_TO_MEM)
+ load_address = sdmac->pc_to_pc;
else
load_address = sdmac->pc_to_device;
@@ -1317,6 +1326,84 @@ static struct sdma_desc *sdma_transfer_init(struct
sdma_channel *sdmac,
return NULL;
}
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+ struct dma_chan *chan, dma_addr_t dma_dst,
+ dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+ struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+ size_t count;
+ int i = 0, param;
+ struct sdma_buffer_descriptor *bd;
+ struct sdma_desc *desc;
+
+ if (!chan || !len)
+ return NULL;
+
+ dev_dbg(sdma->dev, "memcpy: %pad->%pad, len=%zu, channel=%d.\n",
+ &dma_src, &dma_dst, len, channel);
+
+ desc = sdma_transfer_init(sdmac, DMA_MEM_TO_MEM, len / SDMA_BD_MAX_CNT
+ + 1);
+ if (!desc)
+ goto err_out;
+
+ do {
+ count = min_t(size_t, len, SDMA_BD_MAX_CNT);
+ bd = &desc->bd[i];
+ bd->buffer_addr = dma_src;
+ bd->ext_buffer_addr = dma_dst;
+ bd->mode.count = count;
+ desc->chn_count += count;
+
+ switch (sdmac->word_size) {
+ case DMA_SLAVE_BUSWIDTH_4_BYTES:
+ bd->mode.command = 0;
+ if ((count | dma_src | dma_dst) & 3)
+ goto err_bd_out;
+ break;
+ case DMA_SLAVE_BUSWIDTH_2_BYTES:
+ bd->mode.command = 2;
+ if ((count | dma_src | dma_dst) & 1)
+ goto err_bd_out;
+ break;
+ case DMA_SLAVE_BUSWIDTH_1_BYTE:
+ bd->mode.command = 1;
+ break;
+ default:
+ goto err_bd_out;
+ }
+
+ dma_src += count;
+ dma_dst += count;
+ len -= count;
+ i++;
+
+ param = BD_DONE | BD_EXTD | BD_CONT;
[PATCH v1 4/4] ARM: configs: imx_v6_v7_defconfig: add DMATEST support
Add DMATEST support and remove invalid options, such as CONFIG_BT_HCIUART_H4 is default enabled and CONFIG_SND_SOC_IMX_WM8962 is out of date and not appear in any config file. Signed-off-by: Robin Gong --- arch/arm/configs/imx_v6_v7_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index e381d05..f28d4d9 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -81,7 +81,6 @@ CONFIG_CAN=y CONFIG_CAN_FLEXCAN=y CONFIG_BT=y CONFIG_BT_HCIUART=y -CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_LL=y CONFIG_CFG80211=y CONFIG_CFG80211_WEXT=y @@ -282,7 +281,6 @@ CONFIG_SND_SOC_FSL_ASRC=y CONFIG_SND_IMX_SOC=y CONFIG_SND_SOC_PHYCORE_AC97=y CONFIG_SND_SOC_EUKREA_TLV320=y -CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_IMX_ES8328=y CONFIG_SND_SOC_IMX_SGTL5000=y CONFIG_SND_SOC_IMX_SPDIF=y @@ -371,6 +369,7 @@ CONFIG_DMADEVICES=y CONFIG_FSL_EDMA=y CONFIG_IMX_SDMA=y CONFIG_MXS_DMA=y +CONFIG_DMATEST=m CONFIG_STAGING=y CONFIG_STAGING_MEDIA=y CONFIG_VIDEO_IMX_MEDIA=y -- 2.7.4
[PATCH v1 3/4] dmaengine: imx-sdma: support dmatest
dmatest(memcpy) will never call dmaengine_slave_config before prep,
so jobs in dmaengine_slave_config need to be moved into somewhere
before device_prep_dma_memcpy. Besides, dmatest never setup chan
->private as other common case like uart/audio/spi will always setup
chan->private. Here check it to judge if it's dmatest case and do
jobs in slave_config.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ed2267d..48f3749 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1222,10 +1222,36 @@ static int sdma_alloc_chan_resources(struct dma_chan
*chan)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct imx_dma_data *data = chan->private;
+ struct imx_dma_data default_data;
int prio, ret;
- if (!data)
- return -EINVAL;
+ ret = clk_enable(sdmac->sdma->clk_ipg);
+ if (ret)
+ return ret;
+ ret = clk_enable(sdmac->sdma->clk_ahb);
+ if (ret)
+ goto disable_clk_ipg;
+ /*
+* dmatest(memcpy) will never call dmaengine_slave_config before prep,
+* so jobs in dmaengine_slave_config need to be moved into somewhere
+* before device_prep_dma_memcpy. Besides, dmatest never setup chan
+* ->private as other common cases like uart/audio/spi will setup
+* chan->private always. Here check it to judge if it's dmatest case
+* and do jobs in slave_config.
+*/
+ if (!data) {
+ dev_warn(sdmac->sdma->dev, "dmatest is running?\n");
+ sdmac->word_size = sdmac->sdma->dma_device.copy_align;
+ default_data.priority = 2;
+ default_data.peripheral_type = IMX_DMATYPE_MEMORY;
+ default_data.dma_request = 0;
+ default_data.dma_request2 = 0;
+ data = &default_data;
+
+ sdma_config_ownership(sdmac, false, true, false);
+ sdma_get_pc(sdmac, IMX_DMATYPE_MEMORY);
+ sdma_load_context(sdmac);
+ }
switch (data->priority) {
case DMA_PRIO_HIGH:
@@ -1244,13 +1270,6 @@ static int sdma_alloc_chan_resources(struct dma_chan
*chan)
sdmac->event_id0 = data->dma_request;
sdmac->event_id1 = data->dma_request2;
- ret = clk_enable(sdmac->sdma->clk_ipg);
- if (ret)
- return ret;
- ret = clk_enable(sdmac->sdma->clk_ahb);
- if (ret)
- goto disable_clk_ipg;
-
ret = sdma_set_channel_priority(sdmac, prio);
if (ret)
goto disable_clk_ahb;
--
2.7.4
[PATCH v1 2/4] dmaengine: imx-sdma: add check_bd_buswidth() to kill the dulicated code
Add check_bd_buswidth() to minimize the code size.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 64 +++---
1 file changed, 29 insertions(+), 35 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 27ccabf..ed2267d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1326,6 +1326,33 @@ static struct sdma_desc *sdma_transfer_init(struct
sdma_channel *sdmac,
return NULL;
}
+static int check_bd_buswidth(struct sdma_buffer_descriptor *bd,
+struct sdma_channel *sdmac, int count,
+dma_addr_t dma_dst, dma_addr_t dma_src)
+{
+ int ret = 0;
+
+ switch (sdmac->word_size) {
+ case DMA_SLAVE_BUSWIDTH_4_BYTES:
+ bd->mode.command = 0;
+ if ((count | dma_dst | dma_src) & 3)
+ ret = -EINVAL;
+ break;
+ case DMA_SLAVE_BUSWIDTH_2_BYTES:
+ bd->mode.command = 2;
+ if ((count | dma_dst | dma_src) & 1)
+ ret = -EINVAL;
+ break;
+ case DMA_SLAVE_BUSWIDTH_1_BYTE:
+bd->mode.command = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dma_dst,
dma_addr_t dma_src, size_t len, unsigned long flags)
@@ -1357,23 +1384,8 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
bd->mode.count = count;
desc->chn_count += count;
- switch (sdmac->word_size) {
- case DMA_SLAVE_BUSWIDTH_4_BYTES:
- bd->mode.command = 0;
- if ((count | dma_src | dma_dst) & 3)
- goto err_bd_out;
- break;
- case DMA_SLAVE_BUSWIDTH_2_BYTES:
- bd->mode.command = 2;
- if ((count | dma_src | dma_dst) & 1)
- goto err_bd_out;
- break;
- case DMA_SLAVE_BUSWIDTH_1_BYTE:
- bd->mode.command = 1;
- break;
- default:
+ if (check_bd_buswidth(bd, sdmac, count, dma_dst, dma_src))
goto err_bd_out;
- }
dma_src += count;
dma_dst += count;
@@ -1440,27 +1452,9 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
bd->mode.count = count;
desc->chn_count += count;
- if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES)
+ if (check_bd_buswidth(bd, sdmac, count, 0, sg->dma_address))
goto err_bd_out;
- switch (sdmac->word_size) {
- case DMA_SLAVE_BUSWIDTH_4_BYTES:
- bd->mode.command = 0;
- if (count & 3 || sg->dma_address & 3)
- goto err_bd_out;
- break;
- case DMA_SLAVE_BUSWIDTH_2_BYTES:
- bd->mode.command = 2;
- if (count & 1 || sg->dma_address & 1)
- goto err_bd_out;
- break;
- case DMA_SLAVE_BUSWIDTH_1_BYTE:
- bd->mode.command = 1;
- break;
- default:
- goto err_bd_out;
- }
-
param = BD_DONE | BD_EXTD | BD_CONT;
if (i + 1 == sg_len) {
--
2.7.4
[PATCH V2 4/4] kvm: add a check if pfn is from NVDIMM pmem.
For device specific memory space, when we move these area of pfn to
memory zone, we will set the page reserved flag at that time, some of
these reserved for device mmio, and some of these are not, such as
NVDIMM pmem.
Now, we map these dev_dax or fs_dax pages to kvm for DIMM/NVDIMM
backend, since these pages are reserved. the check of
kvm_is_reserved_pfn() misconceives those pages as MMIO. Therefor, we
introduce 2 page map types, MEMORY_DEVICE_FS_DAX/MEMORY_DEVICE_DEV_DAX,
to indentify these pages are from NVDIMM pmem. and let kvm treat these
as normal pages.
Without this patch, Many operations will be missed due to this
mistreatment to pmem pages. For example, a page may not have chance to
be unpinned for KVM guest(in kvm_release_pfn_clean); not able to be
marked as dirty/accessed(in kvm_set_pfn_dirty/accessed) etc
Signed-off-by: Zhang Yi
---
virt/kvm/kvm_main.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index afb2e6e..77e6ba8 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -142,8 +142,12 @@ __weak void kvm_arch_mmu_notifier_invalidate_range(struct
kvm *kvm,
bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
{
- if (pfn_valid(pfn))
- return PageReserved(pfn_to_page(pfn));
+ struct page *page;
+
+ if (pfn_valid(pfn)) {
+ page = pfn_to_page(pfn);
+ return PageReserved(page) && !is_dax_page(page);
+ }
return true;
}
--
2.7.4
Re: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
On 7 June 2018 at 14:11, Manish Narani wrote:
> This patch adds support for reading Tap Delay values from Device Tree
> and write them via eemi calls. The macros containing these tap delay
> values are removed from the driver.
>
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 131
> +
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c
> b/drivers/mmc/host/sdhci-of-arasan.c
> index e3332a5..fc0fd01 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -36,6 +36,8 @@
>
> #define PHY_CLK_TOO_SLOW_HZ40
>
> +#define MMC_BANK2 0x2
> +
> /*
> * On some SoCs the syscon area has a feature where the upper 16-bits of
> * each 32-bit register act as a write mask for the lower 16-bits. This
> allows
> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
> struct sdhci_host *host;
> struct clk *clk_ahb;
> struct phy *phy;
> + u32 mio_bank;
> + u32 device_id;
> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
> boolis_phy_on;
>
> boolhas_cqe;
> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct sdhci_host
> *host,
> return ret;
> }
>
> +/**
> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
> + * @deviceid: Unique Id of device
> + * @itap_delay:Input Tap Delay
> + * @oitap_delay: Output Tap Delay
> + */
> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
> otap_delay)
> +{
> + const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
No thanks!
Isn't there a more generic framework we can use to change the tap
values, rather than calling SoC specific functions from the driver?
BTW, what is a tap value, more exactly?
What does changing a tap value mean and where does the property belong, really?
Of course this doesn't even compile, as you have a dependency to
another series. Next time, please clarify that in a cover-letter
(maybe you did, but I can't find it).
> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
> +
> + if (!eemi_ops || !eemi_ops->ioctl)
> + return;
> +
> + if (itap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_INPUT, itap_delay, NULL);
> +
> + if (otap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
> +}
Another overall comment for the series.
I would recommend to change the order of the patches in the series.
Let the DT doc change come first, next the driver change and finally
the change to the DTS file(s). This makes it easier to follow and
review.
[...]
Kind regards
Uffe
Re: [RFC PATCH v4 03/12] PM: Introduce an Energy Model management framework
On Monday 09 Jul 2018 at 20:07:31 (+0200), Dietmar Eggemann wrote: > On 06/28/2018 01:40 PM, Quentin Perret wrote: > This em_rescale_cpu_capacity() function is still very much specific to > systems with asymmetric cpu capacity (Arm big.Little/DynamIQ). Only after > cpufreq is up we can determine the capacity of a CPU, hence we need this one > to set the CPU capacity values for the individual performance states. The abstraction is that this function is needed by all systems where the capacities of CPUs are discovered late, or can be changed at run-time. But yeah, AFAICT this applies mainly to Arm big.LITTLE and/or DynamIQ systems, at least for now. > > Can you not calculate capacity 'on the fly' just using freq and max freq as > well as arch_scale_cpu_capacity() which gives you max capacity? > > capacity = arch_scale_cpu_capacity() * freq / max_freq > > In this case we could get rid of the 'ugly' EM rescaling infrastructure. Indeed, having 'capacity' values in the EM framework is just an optimization for the scheduler, so that it doesn't need to compute them in the wake-up path. I could get rid of the whole em_rescale_cpu_capacity() mess (and by the same occasion the RCU protection of the tables ...) if I removed the 'capacity' values from the EM. But that means a slightly higher complexity on the scheduler side. As you said, the capacity of a CPU at a specific OPP is: cap(opp) = freq(opp) * scale_cpu / max_freq Now, we estimate the energy consumed by this CPU as: nrg = power(opp) * util / cap(opp) because 'util / cap(opp)' represents its percentage of busy time. If I inject the first equation in the second, I get: nrg = power(opp) * util * max_freq / (scale_cpu * freq(opp)) and this can be re-arranged as: nrg = (power(opp) * max_freq / freq(opp)) * (util / scale_cpu) In the above equation, the first term between () is static so I could pre-compute it as a 'cost' for that OPP and store it in the EM table: cost(opp) = power(opp) * max_freq / freq(opp) And then the energy calculation would be something like: nrg = cost(opp) * util / scale_cpu If 'scale_cpu' was static, I could fold it into 'cost' and avoid the cost of the division. But it's not really, so I can either re-do the division all the time on the scheduler side, or play with RCU to cache the result of the division in the EM framework. (I now realize that the current implementation of em_fd_energy() does 'cs->power * sum_util / cs->capacity' but the power / capacity ratio is constant so, if we decide to keep the capacity values in the EM, I should still cache 'power / capacity' in the EM tables and actually save the division ...) This is really a performance vs. code complexity trade-off. I made the choice of performance since we're talking about the scheduler here, but I'm not sure how much we really save by saving this division TBH. Thoughts ? Thanks, Quentin
Re: [PATCH 0/3] fix selftests compiling errors and warnings
ping On 07/02/2018 11:53 AM, Li Zhijian wrote: Li Zhijian (3): selftests/android: fix compiling error selftests/android: initialize heap_type to avoid compiling warning selftests/gpio: unset OUTPUT for build tools/gpio tools/testing/selftests/android/ion/Makefile| 5 - tools/testing/selftests/android/ion/ionapp_export.c | 7 +++ tools/testing/selftests/gpio/Makefile | 2 +- 3 files changed, 12 insertions(+), 2 deletions(-)
Re: [V9fs-developer] [PATCH] p9_check_errors() validate PDU length
Tomas Bortoli wrote on Tue, Jul 10, 2018: > > This however gets more complicated once you start factoring in that > > change I suggested about p9_parse_header not setting size (and checking > > size) because trans_fd relies on it; so I'm not sure how we should > > proceed. > > Mmh, me neither. I don't see where the *actual* PDU length is stored. That's precisely the problem, none of the transports actually write in the pdu how much has been read. Instead, we blindly trust how much the client says it has written and p9_parse_header will write pdu->size which is then used as the 'actual' PDU length. With the three lines I added in each file all transports will store the PDU length in pdu->size so my following suggestion would be to just check that in p9_parse_header the length read from the packet match that of the received data and flag any packet where this is wrong as invalid. The only problem with that is that TCP will use p9_parse_header with a partial packet to know how much it needs to read, so that modification needs actual testing (hence my question below) as it is more intrusive than a simple boundary check. I'd suggest implementing some logic like already here with the if (pdu->size == 0) -- only check if pdu->size was previously set, and set it if it wasn't... But feel free to try something else. With that done I don't expect more problems but if I do it there's little point in making you do it as well ;) > > Do you have a working 9p tcp server to test changes are valid, or are > > you only working off the syzbot reproducer? > > No, I was just using the reproducer to test. > > > In the first place, are you willing to take the time to do that bigger > > fix? > > Yes. Ok, let's get you a working setup for TCP then. You need to install a 9p server, the two I'm aware of are diod and nfs-ganesha (I'm using ganesha); once you have a working config you can mount with something like this: mount -t 9p -o aname=path,trans=fd Once you have that you should be able to fiddle with things until it works as expected. (for virtio I use qemu, that's probably easy to test as well; for RDMA you can use rxe to setup a virtual interface (with rxe_cfg) and then use either diod or ganesha again but the setup is more complicated so it's OK to leave that aside for now) > For me both ways are good. Signed-off-by will be good. > You know for sure more than me about 9p as I started delving it for the > first time yesterday. I can also make and test a patch but I'll need to > understand more about it. Let me know if you find out more. There's a saying about giving a fish or teaching how to fish, so let's have you try if you're motivated :) I don't think much is left if you can sew the pieces together, the most difficult part will probably to set the test environment up if you want to do this properly. Please ask if you run into any trouble, -- Dominique Martinet | Asmadeus
[PATCH v2 1/3] clk: meson: add DT documentation for emmc clock controller
Document the MMC sub clock controller driver, the potential consumer
of this driver is MMC or NAND.
Signed-off-by: Yixun Lan
---
.../bindings/clock/amlogic,mmc-clkc.txt | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
diff --git a/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
new file mode 100644
index ..ff6b4bf3ecf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
@@ -0,0 +1,31 @@
+* Amlogic MMC Sub Clock Controller Driver
+
+The Amlogic MMC clock controller generates and supplies clock to support
+MMC and NAND controller
+
+Required Properties:
+
+- compatible: should be:
+ "amlogic,meson-gx-mmc-clkc"
+ "amlogic,meson-axg-mmc-clkc"
+
+- #clock-cells: should be 1.
+- clocks: phandles to clocks corresponding to the clock-names property
+- clock-names: list of parent clock names
+ - "clkin0", "clkin1"
+
+Parent node should have the following properties :
+- compatible: "syscon", "simple-mfd, and "amlogic,meson-axg-mmc-clkc"
+- reg: base address and size of the MMC control register space.
+
+Example: Clock controller node:
+
+sd_mmc_c_clkc: clock-controller@7000 {
+ compatible = "amlogic,mmc-clkc", "syscon", "simple-mfd";
+ reg = <0x0 0x7000 0x0 0x4>;
+ #clock-cells = <1>;
+
+ clock-names = "clkin0", "clkin1";
+ clocks = <&clkc CLKID_SD_MMC_C_CLK0>,
+ <&clkc CLKID_FCLK_DIV2>;
+};
--
2.18.0
[PATCH v2 3/3] clk: meson: add sub MMC clock controller driver
The patch will add a MMC clock controller driver which used by MMC or NAND,
It provide a mux and divider clock, and three phase clocks - core, tx, tx.
Two clocks are provided as the parent of MMC clock controller from
upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
To specify which clock the MMC or NAND driver may consume,
the preprocessor macros in the dt-bindings/clock/emmc-clkc.h header
can be used in the device tree sources.
Signed-off-by: Yixun Lan
---
drivers/clk/meson/Kconfig| 9 +
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/mmc-clkc.c | 419 +++
3 files changed, 429 insertions(+)
create mode 100644 drivers/clk/meson/mmc-clkc.c
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index efaa70f682b4..edc18e65c89b 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -15,6 +15,15 @@ config COMMON_CLK_MESON_AO
select COMMON_CLK_REGMAP_MESON
select RESET_CONTROLLER
+config COMMON_CLK_MMC_MESON
+ tristate "Meson MMC Sub Clock Controller Driver"
+ depends on COMMON_CLK_AMLOGIC
+ select MFD_SYSCON
+ select REGMAP
+ help
+ Support for the MMC sub clock controller on Amlogic Meson Platform,
+ Say Y if you want this clock enabled.
+
config COMMON_CLK_REGMAP_MESON
bool
select REGMAP
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 72ec8c40d848..4b3817f80ba1 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
obj-$(CONFIG_COMMON_CLK_AXG)+= axg.o axg-aoclk.o
obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
+obj-$(CONFIG_COMMON_CLK_MMC_MESON) += mmc-clkc.o
obj-$(CONFIG_COMMON_CLK_REGMAP_MESON) += clk-regmap.o
diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
new file mode 100644
index ..43b7a376746d
--- /dev/null
+++ b/drivers/clk/meson/mmc-clkc.c
@@ -0,0 +1,419 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clkc.h"
+
+/* clock ID used by internal driver */
+#define CLKID_MMC_MUX 0
+#define CLKID_MMC_PHASE_CORE 2
+
+#define SD_EMMC_CLOCK 0
+#define CLK_DIV_MASK GENMASK(5, 0)
+#define CLK_SRC_MASK GENMASK(7, 6)
+#define CLK_CORE_PHASE_MASK GENMASK(9, 8)
+#define CLK_TX_PHASE_MASK GENMASK(11, 10)
+#define CLK_RX_PHASE_MASK GENMASK(13, 12)
+#define CLK_V2_TX_DELAY_MASK GENMASK(19, 16)
+#define CLK_V2_RX_DELAY_MASK GENMASK(23, 20)
+#define CLK_V2_ALWAYS_ON BIT(24)
+
+#define CLK_V3_TX_DELAY_MASK GENMASK(21, 16)
+#define CLK_V3_RX_DELAY_MASK GENMASK(27, 22)
+#define CLK_V3_ALWAYS_ON BIT(28)
+
+#define CLK_DELAY_STEP_PS 200
+#define CLK_PHASE_STEP 30
+#define CLK_PHASE_POINT_NUM (360 / CLK_PHASE_STEP)
+
+#define MUX_CLK_NUM_PARENTS2
+#define MMC_MAX_CLKS 5
+
+struct clk_regmap_phase_data {
+ unsigned long phase_mask;
+ unsigned long delay_mask;
+ unsigned intdelay_step_ps;
+};
+
+struct mmc_clkc_data {
+ struct clk_regmap_phase_datatx;
+ struct clk_regmap_phase_datarx;
+};
+
+struct mmc_clkc_info {
+ struct device *dev;
+ struct regmap *map;
+ struct mmc_clkc_data*data;
+};
+
+static inline struct clk_regmap_phase_data *
+clk_get_regmap_phase_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_phase_data *)clk->data;
+}
+
+static struct clk_regmap_mux_data mmc_clkc_mux_data = {
+ .offset = SD_EMMC_CLOCK,
+ .mask = 0x3,
+ .shift = 6,
+ .flags = CLK_DIVIDER_ROUND_CLOSEST,
+};
+
+static struct clk_regmap_div_data mmc_clkc_div_data = {
+ .offset = SD_EMMC_CLOCK,
+ .shift = 0,
+ .width = 6,
+ .flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
+};
+
+static struct clk_regmap_phase_data mmc_clkc_core_phase = {
+ .phase_mask = CLK_CORE_PHASE_MASK,
+};
+
+static const struct mmc_clkc_data mmc_clkc_gx_data = {
+ {
+ .phase_mask = CLK_TX_PHASE_MASK,
+ .delay_mask = CLK_V2_TX_DELAY_MASK,
+ .delay_step_ps = CLK_DELAY_STEP_PS,
+ },
+ {
+ .phase_mask = CLK_RX_PHASE_MASK,
+ .delay_mask = CLK_V2_RX_DELAY_MASK,
+ .delay_step_ps = CLK_DELAY_STEP_PS,
+ },
+};
+
+static const struct mmc_clkc_data mmc_clkc_axg_data = {
+ {
+ .phase_mask = CLK_TX_PHASE_MASK,
+ .delay_mask = CLK_V3_TX_DELAY_MAS
[PATCH v2 0/3] clk: meson: add a sub EMMC clock controller support
This driver will add a MMC clock controller driver support. The original idea about adding a clock controller is during the discussion in the NAND driver mainline effort[1]. I've tested this in the S400 board (AXG platform) by using NAND driver. Changes since v1 [2]: - implement phase clock - update compatible name - adjust file name - divider probe() into small functions, and re-use them [1] https://lkml.kernel.org/r/20180628090034.0637a062@xps13 [2] https://lkml.kernel.org/r/20180703145716.31860-1-yixun@amlogic.com Yixun Lan (3): clk: meson: add DT documentation for emmc clock controller clk: meson: add sub MMC clock dt-bindings IDs clk: meson: add sub MMC clock controller driver .../bindings/clock/amlogic,mmc-clkc.txt | 31 ++ drivers/clk/meson/Kconfig | 9 + drivers/clk/meson/Makefile| 1 + drivers/clk/meson/mmc-clkc.c | 419 ++ .../clock/amlogic,meson-mmc-clkc.h| 16 + 5 files changed, 476 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt create mode 100644 drivers/clk/meson/mmc-clkc.c create mode 100644 include/dt-bindings/clock/amlogic,meson-mmc-clkc.h -- 2.18.0
[PATCH v2 2/3] clk: meson: add sub MMC clock dt-bindings IDs
Add two clock bindings IDs which provided by the MMC clock controller, These two clocks will be used by MMC or NAND driver. Signed-off-by: Yixun Lan --- .../dt-bindings/clock/amlogic,meson-mmc-clkc.h | 16 1 file changed, 16 insertions(+) create mode 100644 include/dt-bindings/clock/amlogic,meson-mmc-clkc.h diff --git a/include/dt-bindings/clock/amlogic,meson-mmc-clkc.h b/include/dt-bindings/clock/amlogic,meson-mmc-clkc.h new file mode 100644 index ..2ae988ebc3ae --- /dev/null +++ b/include/dt-bindings/clock/amlogic,meson-mmc-clkc.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ +/* + * Meson MMC sub clock tree IDs + * + * Copyright (c) 2018 Amlogic, Inc. All rights reserved. + * Author: Yixun Lan + */ + +#ifndef __MMC_CLKC_H +#define __MMC_CLKC_H + +#define CLKID_MMC_DIV 1 +#define CLKID_MMC_PHASE_TX 3 +#define CLKID_MMC_PHASE_RX 4 + +#endif -- 2.18.0
Re: [v2,3/3] i2c: at91: added slave mode support
On Mon, Jul 09, 2018 at 05:51:36PM +0200, Wolfram Sang wrote: > > > Sorry for having not catched it. If I remember well, it was the only > > issue I had while testing the slave support. > > > > > > > > BTW maybe I asked already and forgot: is this IP core capable of being > > > master and slave on the same bus? > > > > > > > No the master and slave modes are exclusive. > > Pity. > > But thanks for the heads up, any tag you want to give? Ack or Rev? > Yes sure, you can add my Ack. I would be pleased to see the slave support taken. Regards Ludovic
[PATCH 1/2] clk: imx: add ocram_s clock for i.mx6sx
i.MX6SX has a 16KB always-on ocram bank called
ocram_s, and its clock gate in CCM CCGR1 CG14
needs to be enabled before access, add it to
clock tree.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx6sx.c | 1 +
include/dt-bindings/clock/imx6sx-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index 10c771b..691db26 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -411,6 +411,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_GPT_BUS] = imx_clk_gate2("gpt_bus",
"perclk",base + 0x6c, 20);
clks[IMX6SX_CLK_GPT_SERIAL] = imx_clk_gate2("gpt_serial",
"perclk",base + 0x6c, 22);
clks[IMX6SX_CLK_GPU] = imx_clk_gate2("gpu",
"gpu_core_podf", base + 0x6c, 26);
+ clks[IMX6SX_CLK_OCRAM_S] = imx_clk_gate2("ocram_s", "ahb",
base + 0x6c, 28);
clks[IMX6SX_CLK_CANFD]= imx_clk_gate2("canfd",
"can_podf", base + 0x6c, 30);
/* CCGR2 */
diff --git a/include/dt-bindings/clock/imx6sx-clock.h
b/include/dt-bindings/clock/imx6sx-clock.h
index cd2d6c5..c1ccff8 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -279,6 +279,7 @@
#define IMX6SX_CLK_LVDS2_OUT 266
#define IMX6SX_CLK_LVDS2_IN267
#define IMX6SX_CLK_ANACLK2 268
-#define IMX6SX_CLK_CLK_END 269
+#define IMX6SX_CLK_OCRAM_S 269
+#define IMX6SX_CLK_CLK_END 270
#endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
--
2.7.4
[PATCH 2/2] ARM: dts: imx6sx: add ocram_s support
i.MX6SX has a 16KB always-on ocram bank called
ocram_s, enable it as another mmio sram.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 596763c..9923739 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -172,6 +172,12 @@
clocks = <&clks IMX6SX_CLK_OCRAM>;
};
+ ocram_s: sram@8f8000 {
+ compatible = "mmio-sram";
+ reg = <0x008f8000 0x4000>;
+ clocks = <&clks IMX6SX_CLK_OCRAM_S>;
+ };
+
L2: l2-cache@a02000 {
compatible = "arm,pl310-cache";
reg = <0x00a02000 0x1000>;
--
2.7.4
[RFC PATCH v3] watchdog: sp805: Add clock-frequency property
When using ACPI node, binding clock devices are
not available as device tree, So clock-frequency
property given in _DSD object of ACPI device is
used to calculate Watchdog rate.
Signed-off-by: Srinath Mannam
---
drivers/watchdog/sp805_wdt.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 9849db0..a896b1c 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -11,6 +11,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -65,6 +67,7 @@ struct sp805_wdt {
spinlock_t lock;
void __iomem*base;
struct clk *clk;
+ u64 rate;
struct amba_device *adev;
unsigned intload_val;
};
@@ -80,7 +83,7 @@ static int wdt_setload(struct watchdog_device *wdd, unsigned
int timeout)
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
u64 load, rate;
- rate = clk_get_rate(wdt->clk);
+ rate = wdt->rate;
/*
* sp805 runs counter with given value twice, after the end of first
@@ -106,9 +109,7 @@ static int wdt_setload(struct watchdog_device *wdd,
unsigned int timeout)
static unsigned int wdt_timeleft(struct watchdog_device *wdd)
{
struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
- u64 load, rate;
-
- rate = clk_get_rate(wdt->clk);
+ u64 load;
spin_lock(&wdt->lock);
load = readl_relaxed(wdt->base + WDTVALUE);
@@ -118,7 +119,7 @@ static unsigned int wdt_timeleft(struct watchdog_device
*wdd)
load += wdt->load_val + 1;
spin_unlock(&wdt->lock);
- return div_u64(load, rate);
+ return div_u64(load, wdt->rate);
}
static int
@@ -228,11 +229,25 @@ sp805_wdt_probe(struct amba_device *adev, const struct
amba_id *id)
if (IS_ERR(wdt->base))
return PTR_ERR(wdt->base);
- wdt->clk = devm_clk_get(&adev->dev, NULL);
- if (IS_ERR(wdt->clk)) {
- dev_warn(&adev->dev, "Clock not found\n");
- ret = PTR_ERR(wdt->clk);
- goto err;
+ if (adev->dev.of_node) {
+ wdt->clk = devm_clk_get(&adev->dev, NULL);
+ if (IS_ERR(wdt->clk)) {
+ dev_err(&adev->dev, "Clock not found\n");
+ return PTR_ERR(wdt->clk);
+ }
+ wdt->rate = clk_get_rate(wdt->clk);
+ } else if (has_acpi_companion(&adev->dev)) {
+ /*
+* When Driver probe with ACPI device, clock devices
+* are not available, so watchdog rate get from
+* clock-frequency property given in _DSD object.
+*/
+ device_property_read_u64(&adev->dev, "clock-frequency",
+&wdt->rate);
+ if (!wdt->rate) {
+ dev_err(&adev->dev, "no clock-frequency property\n");
+ return -ENODEV;
+ }
}
wdt->adev = adev;
--
2.7.4
Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization
On 09/07/2018 17:50, Halil Pasic wrote: On 07/09/2018 05:21 AM, Pierre Morel wrote: On 03/07/2018 01:10, Halil Pasic wrote: On 06/29/2018 11:11 PM, Tony Krowiak wrote: This patch provides documentation describing the AP architecture and design concepts behind the virtualization of AP devices. It also includes an example of how to configure AP devices for exclusive use of KVM guests. Signed-off-by: Tony Krowiak I don't like the design of external interfaces except for: * cpu model features, and * reset handling. In particular: ...snip... 4) If I were to act out the role of the administrator, I would prefer to think of specifying or changing the access controls of a guest in respect to AP (that is setting the AP matrix) as a single atomic operation -- which either succeeds or fails. The operation should succeed for any valid configuration, and fail for any invalid on. The current piecemeal approach seems even less fitting if we consider changing the access controls of a running guest. AFAIK changing access controls for a running guest is possible, and I don't see a reason why should we artificially prohibit this. I think the current sysfs interface for manipulating the matrix is good for manual playing around, but I would prefer having an interface that is better suited for programs (e.g. ioctl). I disagree with using ioctl. Why? What speaks against ioctl? Using a sysfs interface is easy and can be done using any interpreted language. It has become the standard way to configure drivers. Even the existing interface must be consolidated, it exist and is functional. For what I understood, the problem is to have an atomic update of the matrix to avoid possible dead-lock when two admin tasks try to configure a matrix for a guest. The problematic is a userland problem it is not a kernel problem. We have several possibilities to avoid this problem but still keep a sysfs interface: - the admin tasks may use a lock - the admin task may use a policy like freeing owned resources if they can not get all resources. Using a step by step configuration allows to easily know the missing resource in case of failure. Regards, Pierre I agree that the current implementation is not right. The configuration of APM and AQM should always be guarantied as coherent within the host but it can be done doing the right checks when using the sysfs. I'm glad we agree on this one at least. Regards, Halil -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany
[PATCH 3/3] KVM: x86: expose MOVDIR64B CPU feature into VM.
MOVDIR64B moves 64-bytes as direct-store with 64-bytes write atomicity. Direct store is implemented by using write combining (WC) for writing data directly into memory without caching the data. Availability of the MOVDIR64B instruction is indicated by the presence of the CPUID feature flag MOVDIR64B (CPUID.0x07.0x0:ECX[bit 28]). This patch exposes the movdir64b feature to the guest. The release document ref below link: https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf This patch has a dependency on https://lkml.org/lkml/2018/6/15/655. Signed-off-by: Jingqi Liu --- arch/x86/kvm/cpuid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 456caf7..deaad68 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -406,7 +406,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) | - F(CLDEMOTE) | F(WAITPKG) | F(MOVDIRI); + F(CLDEMOTE) | F(WAITPKG) | F(MOVDIRI) | F(MOVDIR64B); /* cpuid 7.0.edx*/ const u32 kvm_cpuid_7_0_edx_x86_features = -- 1.8.3.1
[PATCH 1/3] KVM: x86: expose UMWAIT/UMONITOR/TPAUSE CPU features into VM.
UMONITOR, UMWAIT, and TPAUSE are a set of user wait instructions. UMONITOR arms address monitoring hardware using an address. A store to an address within the specified address range triggers the monitoring hardware to wake up the processor waiting in umwait. UMWAIT instructs the processor to enter an implementation-dependent optimized state while monitoring a range of addresses. The optimized state may be either a light-weight power/performance optimized state (c0.1 state) or an improved power/performance optimized state (c0.2 state). TPAUSE instructs the processor to enter an implementation-dependent optimized state c0.1 or c0.2 state and wake up when time-stamp counter reaches specified timeout. Availability of the user wait instructions is indicated by the presence of the CPUID feature flag WAITPKG CPUID.0x07.0x0:ECX[5]. This patch exposes the umonitor,umwait, and tpause features to the guest. The release document ref below link: https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf This patch has a dependency on https://lkml.org/lkml/2018/6/15/657. Signed-off-by: Jingqi Liu --- arch/x86/kvm/cpuid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 7e042e3..e16c05e 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -406,7 +406,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) | - F(CLDEMOTE); + F(CLDEMOTE) | F(WAITPKG); /* cpuid 7.0.edx*/ const u32 kvm_cpuid_7_0_edx_x86_features = -- 1.8.3.1
[PATCH 0/3] KVM: x86: expose a few new features into VM.
A few new features including user wait (umwait, umonitor, tpause) and direct stores (movdiri and movdir64b) will be available in Intel Snow Ridge, and need to be exposed to guest VM. The release document ref below link: https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf This series expose umonitor,umwait, tpause, movdiri and movdir64b features to guest VM. Jingqi Liu (3): KVM: x86: expose UMWAIT/UMONITOR/TPAUSE CPU features into VM. KVM: x86: expose MOVDIRI CPU feature into VM. KVM: x86: expose MOVDIR64B CPU feature into VM. arch/x86/kvm/cpuid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.3.1
[PATCH 2/3] KVM: x86: expose MOVDIRI CPU feature into VM.
MOVDIRI moves doubleword or quadword from register to memory through direct store which is implemented by using write combining (WC) for writing data directly into memory without caching the data. Availability of the MOVDIRI instruction is indicated by the presence of the CPUID feature flag MOVDIRI(CPUID.0x07.0x0:ECX[bit 27]). This patch exposes the movdiri feature to the guest. The release document ref below link: https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf This patch has a dependency on https://lkml.org/lkml/2018/6/15/654. Signed-off-by: Jingqi Liu --- arch/x86/kvm/cpuid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index e16c05e..456caf7 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -406,7 +406,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) | - F(CLDEMOTE) | F(WAITPKG); + F(CLDEMOTE) | F(WAITPKG) | F(MOVDIRI); /* cpuid 7.0.edx*/ const u32 kvm_cpuid_7_0_edx_x86_features = -- 1.8.3.1
[PATCH v5 1/7] arm_pmu: Clean up maximum period handling
Each PMU defines their max_period of the counter as the maximum
value that can be counted. Since all the PMU backends support
32bit counters by default, let us remove the redundant field.
No functional changes.
Cc: Will Deacon
Acked-by: Mark Rutland
Reviewed-by: Julien Thierry
Signed-off-by: Suzuki K Poulose
---
No changes since v2
---
arch/arm/kernel/perf_event_v6.c | 2 --
arch/arm/kernel/perf_event_v7.c | 1 -
arch/arm/kernel/perf_event_xscale.c | 2 --
arch/arm64/kernel/perf_event.c | 1 -
drivers/perf/arm_pmu.c | 16
include/linux/perf/arm_pmu.h| 1 -
6 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index be42c4f..f64a6bf 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -495,7 +495,6 @@ static void armv6pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->stop = armv6pmu_stop;
cpu_pmu->map_event = armv6_map_event;
cpu_pmu->num_events = 3;
- cpu_pmu->max_period = (1LLU << 32) - 1;
}
static int armv6_1136_pmu_init(struct arm_pmu *cpu_pmu)
@@ -546,7 +545,6 @@ static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->stop = armv6pmu_stop;
cpu_pmu->map_event = armv6mpcore_map_event;
cpu_pmu->num_events = 3;
- cpu_pmu->max_period = (1LLU << 32) - 1;
return 0;
}
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 57f01e0..ecca4cd 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1170,7 +1170,6 @@ static void armv7pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->start = armv7pmu_start;
cpu_pmu->stop = armv7pmu_stop;
cpu_pmu->reset = armv7pmu_reset;
- cpu_pmu->max_period = (1LLU << 32) - 1;
};
static void armv7_read_num_pmnc_events(void *info)
diff --git a/arch/arm/kernel/perf_event_xscale.c
b/arch/arm/kernel/perf_event_xscale.c
index 88d1a76..c4f0294 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -374,7 +374,6 @@ static int xscale1pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->stop = xscale1pmu_stop;
cpu_pmu->map_event = xscale_map_event;
cpu_pmu->num_events = 3;
- cpu_pmu->max_period = (1LLU << 32) - 1;
return 0;
}
@@ -743,7 +742,6 @@ static int xscale2pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->stop = xscale2pmu_stop;
cpu_pmu->map_event = xscale_map_event;
cpu_pmu->num_events = 5;
- cpu_pmu->max_period = (1LLU << 32) - 1;
return 0;
}
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 33147aa..678ecff 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -960,7 +960,6 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->start = armv8pmu_start,
cpu_pmu->stop = armv8pmu_stop,
cpu_pmu->reset = armv8pmu_reset,
- cpu_pmu->max_period = (1LLU << 32) - 1,
cpu_pmu->set_event_filter = armv8pmu_set_event_filter;
return 0;
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index a6347d4..6ddc00d 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -28,6 +28,11 @@
static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
static DEFINE_PER_CPU(int, cpu_irq);
+static inline u64 arm_pmu_max_period(void)
+{
+ return (1ULL << 32) - 1;
+}
+
static int
armpmu_map_cache_event(const unsigned (*cache_map)
[PERF_COUNT_HW_CACHE_MAX]
@@ -114,8 +119,10 @@ int armpmu_event_set_period(struct perf_event *event)
struct hw_perf_event *hwc = &event->hw;
s64 left = local64_read(&hwc->period_left);
s64 period = hwc->sample_period;
+ u64 max_period;
int ret = 0;
+ max_period = arm_pmu_max_period();
if (unlikely(left <= -period)) {
left = period;
local64_set(&hwc->period_left, left);
@@ -136,8 +143,8 @@ int armpmu_event_set_period(struct perf_event *event)
* effect we are reducing max_period to account for
* interrupt latency (and we are being very conservative).
*/
- if (left > (armpmu->max_period >> 1))
- left = armpmu->max_period >> 1;
+ if (left > (max_period >> 1))
+ left = (max_period >> 1);
local64_set(&hwc->prev_count, (u64)-left);
@@ -153,6 +160,7 @@ u64 armpmu_event_update(struct perf_event *event)
struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
u64 delta, prev_raw_count, new_raw_count;
+ u64 max_period = arm_pmu_max_period();
again:
prev_raw_coun
[PATCH v5 3/7] arm_pmu: Add support for 64bit event counters
Each PMU has a set of 32bit event counters. But in some
special cases, the events could be counted using counters
which are effectively 64bit wide.
e.g, Arm V8 PMUv3 has a 64 bit cycle counter which can count
only the CPU cycles. Also, the PMU can chain the event counters
to effectively count as a 64bit counter.
Add support for tracking the events that uses 64bit counters.
This only affects the periods set for each counter in the core
driver.
Cc: Will Deacon
Reviewed-by: Julien Thierry
Acked-by: Mark Rutland
Signed-off-by: Suzuki K Poulose
---
Changes since v3:
- Replace ternary operator with if..else for max_period
- Added Acked-by from Mark R
---
drivers/perf/arm_pmu.c | 16 ++--
include/linux/perf/arm_pmu.h | 6 ++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 6ddc00d..8cad6b5 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -28,9 +28,12 @@
static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
static DEFINE_PER_CPU(int, cpu_irq);
-static inline u64 arm_pmu_max_period(void)
+static inline u64 arm_pmu_event_max_period(struct perf_event *event)
{
- return (1ULL << 32) - 1;
+ if (event->hw.flags & ARMPMU_EVT_64BIT)
+ return GENMASK_ULL(63, 0);
+ else
+ return GENMASK_ULL(31, 0);
}
static int
@@ -122,7 +125,7 @@ int armpmu_event_set_period(struct perf_event *event)
u64 max_period;
int ret = 0;
- max_period = arm_pmu_max_period();
+ max_period = arm_pmu_event_max_period(event);
if (unlikely(left <= -period)) {
left = period;
local64_set(&hwc->period_left, left);
@@ -148,7 +151,7 @@ int armpmu_event_set_period(struct perf_event *event)
local64_set(&hwc->prev_count, (u64)-left);
- armpmu->write_counter(event, (u64)(-left) & 0x);
+ armpmu->write_counter(event, (u64)(-left) & max_period);
perf_event_update_userpage(event);
@@ -160,7 +163,7 @@ u64 armpmu_event_update(struct perf_event *event)
struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
u64 delta, prev_raw_count, new_raw_count;
- u64 max_period = arm_pmu_max_period();
+ u64 max_period = arm_pmu_event_max_period(event);
again:
prev_raw_count = local64_read(&hwc->prev_count);
@@ -368,6 +371,7 @@ __hw_perf_event_init(struct perf_event *event)
struct hw_perf_event *hwc = &event->hw;
int mapping;
+ hwc->flags = 0;
mapping = armpmu->map_event(event);
if (mapping < 0) {
@@ -410,7 +414,7 @@ __hw_perf_event_init(struct perf_event *event)
* is far less likely to overtake the previous one unless
* you have some serious IRQ latency issues.
*/
- hwc->sample_period = arm_pmu_max_period() >> 1;
+ hwc->sample_period = arm_pmu_event_max_period(event) >> 1;
hwc->last_period= hwc->sample_period;
local64_set(&hwc->period_left, hwc->sample_period);
}
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index f7126a2..10f92e1 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -25,6 +25,12 @@
*/
#define ARMPMU_MAX_HWEVENTS32
+/*
+ * ARM PMU hw_event flags
+ */
+/* Event uses a 64bit counter */
+#define ARMPMU_EVT_64BIT 1
+
#define HW_OP_UNSUPPORTED 0x
#define C(_x) PERF_COUNT_HW_CACHE_##_x
#define CACHE_OP_UNSUPPORTED 0x
--
2.7.4
[PATCH v5 4/7] arm_pmu: Tidy up clear_event_idx call backs
The armpmu uses get_event_idx callback to allocate an event
counter for a given event, which marks the selected counter
as "used". Now, when we delete the counter, the arm_pmu goes
ahead and clears the "used" bit and then invokes the "clear_event_idx"
call back, which kind of splits the job between the core code
and the backend. To keep things tidy, mandate the implementation
of clear_event_idx() and add it for exisiting backends.
This will be useful for adding the chained event support, where
we leave the event idx maintenance to the backend.
Also, when an event is removed from the PMU, reset the hw.idx
to indicate that a counter is not allocated for this event,
to help the backends do better checks. This will be also used
for the chain counter support.
Cc: Will Deacon
Cc: Mark Rutland
Reviewed-by: Julien Thierry
Signed-off-by: Suzuki K Poulose
---
Changes since v4:
- Add missing clear_event_idx call back for xscale PMU
---
arch/arm/kernel/perf_event_v6.c | 8
arch/arm/kernel/perf_event_v7.c | 9 +
arch/arm/kernel/perf_event_xscale.c | 8
arch/arm64/kernel/perf_event.c | 7 +++
drivers/perf/arm_pmu.c | 7 +++
5 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 0729f98..1ae99de 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -411,6 +411,12 @@ armv6pmu_get_event_idx(struct pmu_hw_events *cpuc,
}
}
+static void armv6pmu_clear_event_idx(struct pmu_hw_events *cpuc,
+struct perf_event *event)
+{
+ clear_bit(event->hw.idx, cpuc->used_mask);
+}
+
static void armv6pmu_disable_event(struct perf_event *event)
{
unsigned long val, mask, evt, flags;
@@ -491,6 +497,7 @@ static void armv6pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->read_counter = armv6pmu_read_counter;
cpu_pmu->write_counter = armv6pmu_write_counter;
cpu_pmu->get_event_idx = armv6pmu_get_event_idx;
+ cpu_pmu->clear_event_idx = armv6pmu_clear_event_idx;
cpu_pmu->start = armv6pmu_start;
cpu_pmu->stop = armv6pmu_stop;
cpu_pmu->map_event = armv6_map_event;
@@ -541,6 +548,7 @@ static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->read_counter = armv6pmu_read_counter;
cpu_pmu->write_counter = armv6pmu_write_counter;
cpu_pmu->get_event_idx = armv6pmu_get_event_idx;
+ cpu_pmu->clear_event_idx = armv6pmu_clear_event_idx;
cpu_pmu->start = armv6pmu_start;
cpu_pmu->stop = armv6pmu_stop;
cpu_pmu->map_event = armv6mpcore_map_event;
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index fd7ce01..acb49a9 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1058,6 +1058,12 @@ static int armv7pmu_get_event_idx(struct pmu_hw_events
*cpuc,
return -EAGAIN;
}
+static void armv7pmu_clear_event_idx(struct pmu_hw_events *cpuc,
+struct perf_event *event)
+{
+ clear_bit(event->hw.idx, cpuc->used_mask);
+}
+
/*
* Add an event filter to a given event. This will only work for PMUv2 PMUs.
*/
@@ -1167,6 +1173,7 @@ static void armv7pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->read_counter = armv7pmu_read_counter;
cpu_pmu->write_counter = armv7pmu_write_counter;
cpu_pmu->get_event_idx = armv7pmu_get_event_idx;
+ cpu_pmu->clear_event_idx = armv7pmu_clear_event_idx;
cpu_pmu->start = armv7pmu_start;
cpu_pmu->stop = armv7pmu_stop;
cpu_pmu->reset = armv7pmu_reset;
@@ -1637,6 +1644,7 @@ static void krait_pmu_clear_event_idx(struct
pmu_hw_events *cpuc,
bool venum_event = EVENT_VENUM(hwc->config_base);
bool krait_event = EVENT_CPU(hwc->config_base);
+ armv7pmu_clear_event_idx(cpuc, event);
if (venum_event || krait_event) {
bit = krait_event_to_bit(event, region, group);
clear_bit(bit, cpuc->used_mask);
@@ -1966,6 +1974,7 @@ static void scorpion_pmu_clear_event_idx(struct
pmu_hw_events *cpuc,
bool venum_event = EVENT_VENUM(hwc->config_base);
bool scorpion_event = EVENT_CPU(hwc->config_base);
+ armv7pmu_clear_event_idx(cpuc, event);
if (venum_event || scorpion_event) {
bit = scorpion_event_to_bit(event, region, group);
clear_bit(bit, cpuc->used_mask);
diff --git a/arch/arm/kernel/perf_event_xscale.c
b/arch/arm/kernel/perf_event_xscale.c
index 942230f..f6cdcac 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -292,6 +292,12 @@ xscale1pmu_get_event_idx(struct pmu_hw_events *cpuc,
}
}
+static void xscalepmu_clear_event_idx(struct pmu_hw_events *cpuc,
+struct p
[PATCH v5 5/7] arm64: perf: Clean up armv8pmu_select_counter
armv8pmu_select_counter always returns the passed idx. So
let us make that void and get rid of the pointless checks.
Suggested-by: Mark Rutland
Cc: Will Deacon
Acked-by: Mark Rutland
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/perf_event.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index ac66851..bc014af 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -503,13 +503,17 @@ static inline int armv8pmu_counter_has_overflowed(u32
pmnc, int idx)
return pmnc & BIT(ARMV8_IDX_TO_COUNTER(idx));
}
-static inline int armv8pmu_select_counter(int idx)
+static inline void armv8pmu_select_counter(int idx)
{
u32 counter = ARMV8_IDX_TO_COUNTER(idx);
write_sysreg(counter, pmselr_el0);
isb();
+}
- return idx;
+static inline u32 armv8pmu_read_evcntr(int idx)
+{
+ armv8pmu_select_counter(idx);
+ return read_sysreg(pmxevcntr_el0);
}
static inline u64 armv8pmu_read_counter(struct perf_event *event)
@@ -524,12 +528,18 @@ static inline u64 armv8pmu_read_counter(struct perf_event
*event)
smp_processor_id(), idx);
else if (idx == ARMV8_IDX_CYCLE_COUNTER)
value = read_sysreg(pmccntr_el0);
- else if (armv8pmu_select_counter(idx) == idx)
- value = read_sysreg(pmxevcntr_el0);
+ else
+ value = armv8pmu_read_evcntr(idx);
return value;
}
+static inline void armv8pmu_write_evcntr(int idx, u32 value)
+{
+ armv8pmu_select_counter(idx);
+ write_sysreg(value, pmxevcntr_el0);
+}
+
static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
@@ -547,16 +557,15 @@ static inline void armv8pmu_write_counter(struct
perf_event *event, u64 value)
*/
value |= 0xULL;
write_sysreg(value, pmccntr_el0);
- } else if (armv8pmu_select_counter(idx) == idx)
- write_sysreg(value, pmxevcntr_el0);
+ } else
+ armv8pmu_write_evcntr(idx, value);
}
static inline void armv8pmu_write_evtype(int idx, u32 val)
{
- if (armv8pmu_select_counter(idx) == idx) {
- val &= ARMV8_PMU_EVTYPE_MASK;
- write_sysreg(val, pmxevtyper_el0);
- }
+ armv8pmu_select_counter(idx);
+ val &= ARMV8_PMU_EVTYPE_MASK;
+ write_sysreg(val, pmxevtyper_el0);
}
static inline int armv8pmu_enable_counter(int idx)
--
2.7.4
[PATCH v5 2/7] arm_pmu: Change API to support 64bit counter values
Convert the {read/write}_counter APIs to handle 64bit values
to enable supporting chained event counters. The backends still
use 32bit values and we pass them 32bit values only. So in effect
there are no functional changes.
Cc: Will Deacon
Acked-by: Mark Rutland
Reviewed-by: Julien Thierry
Signed-off-by: Suzuki K Poulose
---
- No changes since v2
---
arch/arm/kernel/perf_event_v6.c | 4 ++--
arch/arm/kernel/perf_event_v7.c | 4 ++--
arch/arm/kernel/perf_event_xscale.c | 8
arch/arm64/kernel/perf_event.c | 9 -
include/linux/perf/arm_pmu.h| 4 ++--
5 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index f64a6bf..0729f98 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -233,7 +233,7 @@ armv6_pmcr_counter_has_overflowed(unsigned long pmcr,
return ret;
}
-static inline u32 armv6pmu_read_counter(struct perf_event *event)
+static inline u64 armv6pmu_read_counter(struct perf_event *event)
{
struct hw_perf_event *hwc = &event->hw;
int counter = hwc->idx;
@@ -251,7 +251,7 @@ static inline u32 armv6pmu_read_counter(struct perf_event
*event)
return value;
}
-static inline void armv6pmu_write_counter(struct perf_event *event, u32 value)
+static inline void armv6pmu_write_counter(struct perf_event *event, u64 value)
{
struct hw_perf_event *hwc = &event->hw;
int counter = hwc->idx;
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index ecca4cd..fd7ce01 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -743,7 +743,7 @@ static inline void armv7_pmnc_select_counter(int idx)
isb();
}
-static inline u32 armv7pmu_read_counter(struct perf_event *event)
+static inline u64 armv7pmu_read_counter(struct perf_event *event)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
@@ -763,7 +763,7 @@ static inline u32 armv7pmu_read_counter(struct perf_event
*event)
return value;
}
-static inline void armv7pmu_write_counter(struct perf_event *event, u32 value)
+static inline void armv7pmu_write_counter(struct perf_event *event, u64 value)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
diff --git a/arch/arm/kernel/perf_event_xscale.c
b/arch/arm/kernel/perf_event_xscale.c
index c4f0294..942230f 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -316,7 +316,7 @@ static void xscale1pmu_stop(struct arm_pmu *cpu_pmu)
raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
}
-static inline u32 xscale1pmu_read_counter(struct perf_event *event)
+static inline u64 xscale1pmu_read_counter(struct perf_event *event)
{
struct hw_perf_event *hwc = &event->hw;
int counter = hwc->idx;
@@ -337,7 +337,7 @@ static inline u32 xscale1pmu_read_counter(struct perf_event
*event)
return val;
}
-static inline void xscale1pmu_write_counter(struct perf_event *event, u32 val)
+static inline void xscale1pmu_write_counter(struct perf_event *event, u64 val)
{
struct hw_perf_event *hwc = &event->hw;
int counter = hwc->idx;
@@ -678,7 +678,7 @@ static void xscale2pmu_stop(struct arm_pmu *cpu_pmu)
raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
}
-static inline u32 xscale2pmu_read_counter(struct perf_event *event)
+static inline u64 xscale2pmu_read_counter(struct perf_event *event)
{
struct hw_perf_event *hwc = &event->hw;
int counter = hwc->idx;
@@ -705,7 +705,7 @@ static inline u32 xscale2pmu_read_counter(struct perf_event
*event)
return val;
}
-static inline void xscale2pmu_write_counter(struct perf_event *event, u32 val)
+static inline void xscale2pmu_write_counter(struct perf_event *event, u64 val)
{
struct hw_perf_event *hwc = &event->hw;
int counter = hwc->idx;
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 678ecff..66a2ffd 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -512,7 +512,7 @@ static inline int armv8pmu_select_counter(int idx)
return idx;
}
-static inline u32 armv8pmu_read_counter(struct perf_event *event)
+static inline u64 armv8pmu_read_counter(struct perf_event *event)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
@@ -530,7 +530,7 @@ static inline u32 armv8pmu_read_counter(struct perf_event
*event)
return value;
}
-static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
+static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
@@ -545,9 +545,8 @@ static inline void armv8
[PATCH v5 7/7] arm64: perf: Add support for chaining event counters
Add support for 64bit event by using chained event counters
and 64bit cycle counters.
PMUv3 allows chaining a pair of adjacent 32-bit counters, effectively
forming a 64-bit counter. The low/even counter is programmed to count
the event of interest, and the high/odd counter is programmed to count
the CHAIN event, taken when the low/even counter overflows.
For CPU cycles, when 64bit mode is requested, the cycle counter
is used in 64bit mode. If the cycle counter is not available,
falls back to chaining.
Cc: Mark Rutland
Cc: Will Deacon
Signed-off-by: Suzuki K Poulose
---
Changes since v4:
- Drop comment in cpu_pm_pmu_setup
Changes since v3:
- Rename format name from "bits64 => long"
- Address other comments on style.
---
arch/arm64/kernel/perf_event.c | 185 +++--
drivers/perf/arm_pmu.c | 9 +-
2 files changed, 160 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index b414d81..dfff5ed 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -446,9 +446,16 @@ static struct attribute_group
armv8_pmuv3_events_attr_group = {
};
PMU_FORMAT_ATTR(event, "config:0-15");
+PMU_FORMAT_ATTR(long, "config1:0");
+
+static inline bool armv8pmu_event_is_64bit(struct perf_event *event)
+{
+ return event->attr.config1 & 0x1;
+}
static struct attribute *armv8_pmuv3_format_attrs[] = {
&format_attr_event.attr,
+ &format_attr_long.attr,
NULL,
};
@@ -466,6 +473,21 @@ static struct attribute_group
armv8_pmuv3_format_attr_group = {
(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
/*
+ * We must chain two programmable counters for 64 bit events,
+ * except when we have allocated the 64bit cycle counter (for CPU
+ * cycles event). This must be called only when the event has
+ * a counter allocated.
+ */
+static inline bool armv8pmu_event_is_chained(struct perf_event *event)
+{
+ int idx = event->hw.idx;
+
+ return !WARN_ON(idx < 0) &&
+ armv8pmu_event_is_64bit(event) &&
+ (idx != ARMV8_IDX_CYCLE_COUNTER);
+}
+
+/*
* ARMv8 low level PMU access
*/
@@ -516,12 +538,23 @@ static inline u32 armv8pmu_read_evcntr(int idx)
return read_sysreg(pmxevcntr_el0);
}
+static inline u64 armv8pmu_read_hw_counter(struct perf_event *event)
+{
+ int idx = event->hw.idx;
+ u64 val = 0;
+
+ val = armv8pmu_read_evcntr(idx);
+ if (armv8pmu_event_is_chained(event))
+ val = (val << 32) | armv8pmu_read_evcntr(idx - 1);
+ return val;
+}
+
static inline u64 armv8pmu_read_counter(struct perf_event *event)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
int idx = hwc->idx;
- u32 value = 0;
+ u64 value = 0;
if (!armv8pmu_counter_valid(cpu_pmu, idx))
pr_err("CPU%u reading wrong counter %d\n",
@@ -529,7 +562,7 @@ static inline u64 armv8pmu_read_counter(struct perf_event
*event)
else if (idx == ARMV8_IDX_CYCLE_COUNTER)
value = read_sysreg(pmccntr_el0);
else
- value = armv8pmu_read_evcntr(idx);
+ value = armv8pmu_read_hw_counter(event);
return value;
}
@@ -540,6 +573,19 @@ static inline void armv8pmu_write_evcntr(int idx, u32
value)
write_sysreg(value, pmxevcntr_el0);
}
+static inline void armv8pmu_write_hw_counter(struct perf_event *event,
+u64 value)
+{
+ int idx = event->hw.idx;
+
+ if (armv8pmu_event_is_chained(event)) {
+ armv8pmu_write_evcntr(idx, upper_32_bits(value));
+ armv8pmu_write_evcntr(idx - 1, lower_32_bits(value));
+ } else {
+ armv8pmu_write_evcntr(idx, value);
+ }
+}
+
static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
{
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
@@ -551,14 +597,16 @@ static inline void armv8pmu_write_counter(struct
perf_event *event, u64 value)
smp_processor_id(), idx);
else if (idx == ARMV8_IDX_CYCLE_COUNTER) {
/*
-* Set the upper 32bits as this is a 64bit counter but we only
-* count using the lower 32bits and we want an interrupt when
-* it overflows.
+* The cycles counter is really a 64-bit counter.
+* When treating it as a 32-bit counter, we only count
+* the lower 32 bits, and set the upper 32-bits so that
+* we get an interrupt upon 32-bit overflow.
*/
- value |= 0xULL;
+ if (!armv8pmu_event_is_64bit(event))
+ value |= 0xULL;
write_sysreg(value, pmccntr_el0);
} else
- armv8pmu_write_evcntr(idx, value);
+
[PATCH v5 6/7] arm64: perf: Disable PMU while processing counter overflows
The arm64 PMU updates the event counters and reprograms the
counters in the overflow IRQ handler without disabling the
PMU. This could potentially cause skews in for group counters,
where the overflowed counters may potentially loose some event
counts, while they are reprogrammed. To prevent this, disable
the PMU while we process the counter overflows and enable it
right back when we are done.
This patch also moves the PMU stop/start routines to avoid a
forward declaration.
Suggested-by: Mark Rutland
Cc: Will Deacon
Acked-by: Mark Rutland
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/perf_event.c | 50 +++---
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index bc014af..b414d81 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -678,6 +678,28 @@ static void armv8pmu_disable_event(struct perf_event
*event)
raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
}
+static void armv8pmu_start(struct arm_pmu *cpu_pmu)
+{
+ unsigned long flags;
+ struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
+
+ raw_spin_lock_irqsave(&events->pmu_lock, flags);
+ /* Enable all counters */
+ armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
+ raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
+}
+
+static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
+{
+ unsigned long flags;
+ struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
+
+ raw_spin_lock_irqsave(&events->pmu_lock, flags);
+ /* Disable all counters */
+ armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
+ raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
+}
+
static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
{
u32 pmovsr;
@@ -702,6 +724,11 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu
*cpu_pmu)
*/
regs = get_irq_regs();
+ /*
+* Stop the PMU while processing the counter overflows
+* to prevent skews in group events.
+*/
+ armv8pmu_stop(cpu_pmu);
for (idx = 0; idx < cpu_pmu->num_events; ++idx) {
struct perf_event *event = cpuc->events[idx];
struct hw_perf_event *hwc;
@@ -726,6 +753,7 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu
*cpu_pmu)
if (perf_event_overflow(event, &data, regs))
cpu_pmu->disable(event);
}
+ armv8pmu_start(cpu_pmu);
/*
* Handle the pending perf events.
@@ -739,28 +767,6 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu
*cpu_pmu)
return IRQ_HANDLED;
}
-static void armv8pmu_start(struct arm_pmu *cpu_pmu)
-{
- unsigned long flags;
- struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
-
- raw_spin_lock_irqsave(&events->pmu_lock, flags);
- /* Enable all counters */
- armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
- raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
-}
-
-static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
-{
- unsigned long flags;
- struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
-
- raw_spin_lock_irqsave(&events->pmu_lock, flags);
- /* Disable all counters */
- armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
- raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
-}
-
static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
struct perf_event *event)
{
--
2.7.4
[PATCH v5 0/7] arm64: perf: Support for chained counters
This series adds support for counting PMU events using 64bit counters for arm64 PMU. The Arm v8 PMUv3 supports combining two adjacent 32bit counters (low even and hig odd counters) to count a given "event" in 64bit mode. This series adds the support for 64bit events in the core arm_pmu driver infrastructure and adds the support for armv8 64bit kernel PMU to use chained counters to count in 64bit mode. For CPU cycles, we use the cycle counter in 64bit mode, only when requested. If the cycle counter is not available, we fall back to chaining the counters. Tested on Juno, Fast models. Applies on 4.18-rc4 Change since v4: - Add missing clear_event_idx call back for xscale PMU - Drop comment in cpu_pm_pmu_setup() Changes since v3: - Rename format string "bits64" => "long" - Add clear_event_idx call back for all PMU backends - Address style comments - Add Acked-by's Changes since v2: - Clean up select counter routine. (Mark Rutland) - Stop PMU while processing overflows (Mark Rutland) - Drop special allocation algorithm for chain indices - Since we access the counters when the PMU is stopped, get rid of the unncessary barriers. - Ensure a counter is allocated when checking for chained event Change since v1: - Remove unnecessary isb()s in chain counter reads/writes - Fix event programming order for counters - Tighten chain counter event read sequence - Set chain event to count in all ELs - Cleanup helpers to be consistent - Fix build break on xcale PMU (reported by kbuild-robot) - Remove the explicit counter width field from pmu backends and default to 32bit. - Rename flag ARMPMU_EVT_LONG => ARMPMU_EVT_64BIT and the format string "chain" => "bits64". (Unfortunately we can't use "64bit" and I am open for suggestion on a better name) - Rename armpmu_get_event_max_period() => armpmu_event_max_period() - For 64bit CPU cycles events, allow chaining if cycle counter is not available. Suzuki K Poulose (7): arm_pmu: Clean up maximum period handling arm_pmu: Change API to support 64bit counter values arm_pmu: Add support for 64bit event counters arm_pmu: Tidy up clear_event_idx call backs arm64: perf: Clean up armv8pmu_select_counter arm64: perf: Disable PMU while processing counter overflows arm64: perf: Add support for chaining event counters arch/arm/kernel/perf_event_v6.c | 14 +- arch/arm/kernel/perf_event_v7.c | 14 +- arch/arm/kernel/perf_event_xscale.c | 18 ++- arch/arm64/kernel/perf_event.c | 251 +--- drivers/perf/arm_pmu.c | 38 +++--- include/linux/perf/arm_pmu.h| 11 +- 6 files changed, 264 insertions(+), 82 deletions(-) -- 2.7.4
Re: [PATCH] Revert "arm64: Use aarch64elf and aarch64elfb emulation mode variants"
Thanks, Laura.
I'll take this as a fix, and add a comment to the Makefile to justify
why we need the linux target.
Will
On Mon, Jul 09, 2018 at 01:09:56PM -0700, Laura Abbott wrote:
> This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
>
> This breaks compilation with Fedora gcc-8 tool chains:
>
> CHK include/generated/compile.h
> LD [M] arch/arm64/crypto/sha512-ce.o
> aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr:
> No such file or directory
> make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o]
> Error 1
> make: *** [Makefile:1029: arch/arm64/crypto] Error 2
>
> Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode
> variants")
> Signed-off-by: Laura Abbott
> ---
> A bit rushed and I'm still debugging but I wanted to send this out
> before anyone else gets hit since it is -rc4. Seeing this on both native
> and cross compiles.
> ---
> arch/arm64/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 7976d2d242fa..f476d52ad8d6 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> AS += -EB
> -LDFLAGS += -EB -maarch64elfb
> +LDFLAGS += -EB -maarch64linuxb
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> AS += -EL
> -LDFLAGS += -EL -maarch64elf
> +LDFLAGS += -EL -maarch64linux
> UTS_MACHINE := aarch64
> endif
>
> --
> 2.17.1
>
Re: linux-next: build warning after merge of the printk tree
On Tue 2018-07-10 12:46:14, Maninder Singh wrote:
> Hi Petr,
>
> > Hi all,
>
> > After merging the printk tree, today's linux-next build (x86_64
> > allnoconfig) produced this warning:
>
> > kernel/printk/printk.c:2033:13: warning: 'suppress_message_printing'
> > defined but not used [-Wunused-function]
> > static bool suppress_message_printing(int level) { return false; }
> ^
>
> seems there is no user for suppress_message_printing when CONFIG_PRINTK is
> disabled,
> because earlier it was getting used in console_unlock and now we shifted this
> into vprintk_emit
> which will be disabled on disabling CONFIG_PRINTk.
>
> should we remove this defination when CONFIG_PRINTK is disabled ?
>
> > Introduced by commit
> > 375899cddcbb ("printk: make sure to print log on console.")
Grr, I wonder how I missed it. I usually try build with CONFIG_PRINTK
disabled.
Anyway, I have just pushed the following patch into printk.git,
branch for-4.19:
>From 7b83946e61a1e4a080d48c24396aeb18b6366203 Mon Sep 17 00:00:00 2001
From: Petr Mladek
Date: Tue, 10 Jul 2018 10:44:53 +0200
Subject: [PATCH] printk: Fix warning about unused suppress_message_printing
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
suppress_message_printing() is not longer called in console_unlock().
Therefore it is not longer needed with disabled CONFIG_PRINTK.
This fixes the warning:
kernel/printk/printk.c:2033:13: warning: ‘suppress_message_printing’ defined
but not used [-Wunused-function]
static bool suppress_message_printing(int level) { return false; }
Reported-by: Stephen Rothwell
Suggested-by: Maninder Singh
Signed-off-by: Petr Mladek
---
kernel/printk/printk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fcc1992c040a..e2cb0fc18e2d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2021,7 +2021,6 @@ static void call_console_drivers(const char *ext_text,
size_t ext_len,
const char *text, size_t len) {}
static size_t msg_print_text(const struct printk_log *msg,
bool syslog, char *buf, size_t size) { return 0; }
-static bool suppress_message_printing(int level) { return false; }
#endif /* CONFIG_PRINTK */
--
2.13.7
Re: [PATCH] locking/lockdep: Dump state of percpu_rwsem upon hung up.
On Tue, Jul 10, 2018 at 03:10:51PM +0900, Tetsuo Handa wrote:
> From 2642b4a1904259384f2018ea8df03ac49509c57a Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 10 Jul 2018 15:01:20 +0900
> Subject: [PATCH] locking/rwsem: Convert the other sem->count to
> 'atomic_long_t'
>
> Since "locking/rwsem: Convert sem->count to 'atomic_long_t'" forgot to
> convert "struct rw_semaphore"->count in linux/rwsem-spinlock.h which is
> used when CONFIG_RWSEM_GENERIC_SPINLOCK=y, trying to access it in MIPS
> architecture causes build error due to type mismatch.
>
> error: passing argument 1 of 'atomic_long_read' from incompatible pointer
> type [-Werror=incompatible-pointer-types]
> note: expected 'const atomic_long_t * {aka const struct *}' but
> argument is of type '__s32 * {aka int *}'
>
> Signed-off-by: Tetsuo Handa
> Reported-by: kbuild test robot
> Fixes: 8ee62b1870be8e63 ("locking/rwsem: Convert sem->count to
> 'atomic_long_t'")
> Cc: stable # v4.8+
> Cc: Jason Low
> Cc: Peter Zijlstra
> ---
> include/linux/rwsem-spinlock.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hmm, how come you don't have to update kernel/locking/rwsem-spinlock.c
as well? I see stuff such as:
sem->count += woken;
in there.
Will
Re: [PATCH 0/3] pinctrl: meson-g12a: add pinctrl driver support
HI Martin On 07/10/18 06:07, Martin Blumenstingl wrote: > Hi Linus, > > On Mon, Jul 9, 2018 at 3:35 PM Linus Walleij wrote: >> >> On Wed, Jul 4, 2018 at 4:48 PM Yixun Lan wrote: >>> >>> This patch series try to add pinctrl driver support for >>> the Meson-G12A SoC. >>> >>> >>> Yixun Lan (3): >>> documentation: Add compatibles for Amlogic Meson G12A pin controllers >>> dt-bindings: pinctrl: meson-g12a: document pin name >>> pinctrl: meson-g12a: add pinctrl driver support >> >> Overall this looks good to me, could we get some review or ACKs >> from Beniamino, Martin and/or Carlo as an indication that everything >> seems all right before I apply the series? > I do not have any documentation for this hardware (I'm not even sure > if this is the successor to AXG/"the Audio SoCs" or rather a successor > of GXL or GXM/"the OTT/STB SoCs" - I assume it's their new OTT/STB > SoCs since G12A is mentioned here and it seems to have a GPU: [0]) > yes, it's more like a new generation of OTT/STB SoCs.. > I will try to have a look in the next few days and see if I can spot > anything obvious generally the pinctrl IP hasn't changed, so only pinctrl data need to be updated (the pin mux IP is same as AXG SoC which already explain in another thread). > not sure if Neil or Kevin have access to the documentation, so it'd be > great if they could give feedback as well > we are preparing documention to baylibre guys.. I think there is not many boards available in the public? > > Regards > Martin > > > [0] > http://openlinux.amlogic.com:8000/download/doc/Linux_BSP_Kernel4.9_Buildroot_OpenLinux_Release_Notes_V20180330.pdf > > . >
Re: [RFC] Make need_resched() return true when rcu_urgent_qs requested
On Mon, Jul 09, 2018 at 01:42:48PM -0700, Paul E. McKenney wrote: > On Mon, Jul 09, 2018 at 09:35:38PM +0100, David Woodhouse wrote: > > > > > > On Mon, 2018-07-09 at 13:34 -0700, Paul E. McKenney wrote: > > > > > > So here are the possible code paths when .rcu_urgent_qs is set to true: > > > > > > 1. A context switch will record the quiescent state and clear > > > .rcu_urgent_qs. (The failure to do the clearing in current -rcu > > > for PREEMPT builds is a performance bug that I need to fix.) > > > > What if there's nothing else runnable and there is no actual context > > switch? > > The scheduler invokes rcu_note_context_switch() before looking to see > if there really will or won't be a context switch. Correct. Just getting to __schedule() means we can schedule and thus is a valid point for RCU to progress. Even if we then end up selecting the very same task and not switching at all.
Re: [PATCH 2/3] dt-bindings: clk: meson-g12a: Add G12A EE Clock Bindings
On Tue, 2018-07-10 at 00:13 +0200, Martin Blumenstingl wrote: > On Mon, Jul 9, 2018 at 1:13 PM Jian Hu wrote: > > > > Add dt-bindings headers for the Meson-G12A's Everything-Else > > part clock controller. > > I wonder if this should be folded into patch #1 along with an update > to Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt so > it's clear which header has to be used for G12A > Yes, please squash patch 1 and 2. > > > > Signed-off-by: Jian Hu > > --- > > include/dt-bindings/clock/g12a-clkc.h | 93 > > +++ > > 1 file changed, 93 insertions(+) > > create mode 100644 include/dt-bindings/clock/g12a-clkc.h > > > > diff --git a/include/dt-bindings/clock/g12a-clkc.h > > b/include/dt-bindings/clock/g12a-clkc.h > > new file mode 100644 > > index 000..1473225 > > --- /dev/null > > +++ b/include/dt-bindings/clock/g12a-clkc.h > > @@ -0,0 +1,93 @@ > > +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ > > +/* > > + * Meson-G12A clock tree IDs > > + * > > + * Copyright (c) 2018 Amlogic, Inc. All rights reserved. > > + */ > > + > > +#ifndef __G12A_CLKC_H > > +#define __G12A_CLKC_H > > + > > +#define CLKID_SYS_PLL 0 > > +#define CLKID_FIXED_PLL1 > > +#define CLKID_FCLK_DIV22 > > +#define CLKID_FCLK_DIV33 > > +#define CLKID_FCLK_DIV44 > > +#define CLKID_FCLK_DIV55 > > +#define CLKID_FCLK_DIV76 > > +#define CLKID_GP0_PLL 7 Please fix the alignement. > > +#define CLKID_CLK8110 > > +#define CLKID_MPLL011 > > +#define CLKID_MPLL112 > > +#define CLKID_MPLL213 > > +#define CLKID_MPLL314 > > +#define CLKID_DDR 15 > > +#define CLKID_DOS 16 > > +#define CLKID_AUDIO_LOCKER 17 > > +#define CLKID_MIPI_DSI_HOST18 > > +#define CLKID_ETH_PHY 19 > > +#define CLKID_ISA 20 > > +#define CLKID_PL30121 > > +#define CLKID_PERIPHS 22 > > +#define CLKID_SPICC0 23 > > +#define CLKID_I2C 24 > > +#define CLKID_SANA 25 > > +#define CLKID_SD 26 > > +#define CLKID_RNG0 27 > > +#define CLKID_UART028 > > +#define CLKID_SPICC1 29 > > +#define CLKID_HIU_IFACE30 > > +#define CLKID_MIPI_DSI_PHY 31 > > +#define CLKID_ASSIST_MISC 32 > > +#define CLKID_SD_EMMC_A33 > > +#define CLKID_SD_EMMC_B34 > > +#define CLKID_SD_EMMC_C35 > > +#define CLKID_AUDIO_CODEC 36 > > +#define CLKID_AUDIO37 > > +#define CLKID_ETH 38 > > +#define CLKID_DEMUX39 > > +#define CLKID_AUDIO_IFIFO 40 > > +#define CLKID_ADC 41 > > +#define CLKID_UART142 > > +#define CLKID_G2D 43 > > +#define CLKID_RESET44 > > +#define CLKID_PCIE_COMB45 > > +#define CLKID_PARSER 46 > > +#define CLKID_USB 47 > > +#define CLKID_PCIE_PHY 48 > > +#define CLKID_AHB_ARB0 49 > > +#define CLKID_AHB_DATA_BUS 50 > > +#define CLKID_AHB_CTRL_BUS 51 > > +#define CLKID_HTX_HDCP22 52 > > +#define CLKID_HTX_PCLK 53 > > +#define CLKID_BT65654 > > +#define CLKID_USB1_DDR_BRIDGE 55 > > +#define CLKID_MMC_PCLK 56 > > +#define CLKID_UART257 > > +#define CLKID_VPU_INTR 58 > > +#define CLKID_GIC 59 > > +#define CLKID_SD_EMMC_B_CLK0 60 > > +#define CLKID_SD_EMMC_C_CLK0 61 > > +#define CLKID_HIFI_PLL 71 > > + > > is this empty line here on purpose? a comment would be great if > there's a reason behind it (there's already a gap in the numbering > between CLKID_GP0_PLL and CLKID_CLK81, but there's no emp
Re: cgroup trace events acquire sleeping locks
On Mon, Jul 09, 2018 at 04:30:10PM -0400, Steven Rostedt wrote: > On Mon, 9 Jul 2018 22:22:15 +0200 > Sebastian Andrzej Siewior wrote: > > > On 2018-07-09 15:01:54 [-0400], Steven Rostedt wrote: > > > > which is the trace_cgroup_rmdir() trace event in cgroup_rmdir(). The > > > > trace event invokes cgroup_path() which acquires a spin_lock_t and this > > > > is invoked within a preempt_disable()ed section. > > > > > > Correct. And I wish no trace event took spin locks. > > > > is there an easy way to detect this? I mean instead hitting the trace > > event with debug enabled and doing a review of each of them. > > Hmm, good question. I could possibly make all the tracepoint code into > its own section. And then look to see if any spin locks exist in them. > That wouldn't be too trivial to implement though. pick a bit from the preempt_count (say right above NMI_MASK) and set it inside a trace-event and add in_trace(). Then make lockdep explode when in_trace(). Or something along those lines.
[PATCH v5 1/2] KVM: Switch 'requests' to be 64-bit (explicitly)
Switch 'requests' to be explicitly 64-bit and update BUILD_BUG_ON check to
use the size of "requests" instead of the hard-coded '32'.
That gives us a bit more room again for arch-specific requests as we
already ran out of space for x86 due to the hard-coded check.
The only exception here is ARM32 as it is still 32-bits.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Jim Mattson
Signed-off-by: KarimAllah Ahmed
---
v1 -> v2:
- Use FIELD_SIZEOF
---
include/linux/kvm_host.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 4ee7bc5..64518a1 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -130,7 +130,7 @@ static inline bool is_error_page(struct page *page)
#define KVM_REQUEST_ARCH_BASE 8
#define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
- BUILD_BUG_ON((unsigned)(nr) >= 32 - KVM_REQUEST_ARCH_BASE); \
+ BUILD_BUG_ON((unsigned)(nr) >= (FIELD_SIZEOF(struct kvm_vcpu, requests)
* 8) - KVM_REQUEST_ARCH_BASE); \
(unsigned)(((nr) + KVM_REQUEST_ARCH_BASE) | (flags)); \
})
#define KVM_ARCH_REQ(nr) KVM_ARCH_REQ_FLAGS(nr, 0)
@@ -224,7 +224,7 @@ struct kvm_vcpu {
int vcpu_id;
int srcu_idx;
int mode;
- unsigned long requests;
+ u64 requests;
unsigned long guest_debug;
int pre_pcpu;
@@ -1124,7 +1124,7 @@ static inline void kvm_make_request(int req, struct
kvm_vcpu *vcpu)
* caller. Paired with the smp_mb__after_atomic in kvm_check_request.
*/
smp_wmb();
- set_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
+ set_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
}
static inline bool kvm_request_pending(struct kvm_vcpu *vcpu)
@@ -1134,12 +1134,12 @@ static inline bool kvm_request_pending(struct kvm_vcpu
*vcpu)
static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
{
- return test_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
+ return test_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
}
static inline void kvm_clear_request(int req, struct kvm_vcpu *vcpu)
{
- clear_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
+ clear_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
}
static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
--
2.7.4
[PATCH v5 2/2] kvm: nVMX: Introduce KVM_CAP_NESTED_STATE
From: Jim Mattson
For nested virtualization L0 KVM is managing a bit of state for L2 guests,
this state can not be captured through the currently available IOCTLs. In
fact the state captured through all of these IOCTLs is usually a mix of L1
and L2 state. It is also dependent on whether the L2 guest was running at
the moment when the process was interrupted to save its state.
With this capability, there are two new vcpu ioctls: KVM_GET_NESTED_STATE
and KVM_SET_NESTED_STATE. These can be used for saving and restoring a VM
that is in VMX operation.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jim Mattson
[karahmed@ - rename structs and functions and make them ready for AMD and
address previous comments.
- handle nested.smm state.
- rebase & a bit of refactoring.
- Merge 7/8 and 8/8 into one patch. ]
Signed-off-by: KarimAllah Ahmed
---
v4 -> v5:
- Drop the update to KVM_REQUEST_ARCH_BASE in favor of a patch to switch to
u64 instead.
- Fix commit message.
- Handle nested.smm state as well.
- rebase
v3 -> v4:
- Rename function to have _nested
v2 -> v3:
- Remove the forced VMExit from L2 after reading the kvm_state. The actual
problem is solved.
- Rebase again!
- Set nested_run_pending during restore (not sure if it makes sense yet or
not).
- Reduce KVM_REQUEST_ARCH_BASE to 7 instead of 8 (the other alternative is
to switch everything to u64)
v1 -> v2:
- Rename structs and functions and make them ready for AMD and address
previous comments.
- Rebase & a bit of refactoring.
- Merge 7/8 and 8/8 into one patch.
- Force a VMExit from L2 after reading the kvm_state to avoid mixed state
between L1 and L2 on resurrecting the instance.
---
Documentation/virtual/kvm/api.txt | 46 +
arch/x86/include/asm/kvm_host.h | 7 ++
arch/x86/include/uapi/asm/kvm.h | 45 +
arch/x86/kvm/vmx.c| 202 +-
arch/x86/kvm/x86.c| 21
include/uapi/linux/kvm.h | 4 +
6 files changed, 322 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index d10944e..925c509 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3561,6 +3561,52 @@ Returns: 0 on success,
-ENOENT on deassign if the conn_id isn't registered
-EEXIST on assign if the conn_id is already registered
+4.114 KVM_GET_NESTED_STATE
+
+Capability: KVM_CAP_NESTED_STATE
+Architectures: x86
+Type: vcpu ioctl
+Parameters: struct kvm_nested_state (in/out)
+Returns: 0 on success, -1 on error
+Errors:
+ E2BIG: the data size exceeds the value of 'size' specified by
+ the user (the size required will be written into size).
+
+struct kvm_nested_state {
+ __u16 flags;
+ __u16 format;
+ __u32 size;
+ union {
+ struct kvm_vmx_nested_state vmx;
+ struct kvm_svm_nested_state svm;
+ __u8 pad[120];
+ };
+ __u8 data[0];
+};
+
+This ioctl copies the vcpu's kvm_nested_state struct from the kernel to
userspace.
+
+4.115 KVM_SET_NESTED_STATE
+
+Capability: KVM_CAP_NESTED_STATE
+Architectures: x86
+Type: vcpu ioctl
+Parameters: struct kvm_nested_state (in)
+Returns: 0 on success, -1 on error
+
+struct kvm_nested_state {
+ __u16 flags;
+ __u16 format;
+ __u32 size;
+ union {
+ struct kvm_vmx_nested_state vmx;
+ struct kvm_svm_nested_state svm;
+ __u8 pad[120];
+ };
+ __u8 data[0];
+};
+
+This copies the vcpu's kvm_nested_state struct from userspace to the kernel.
5. The kvm_run structure
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0dab702..2e8eb08 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -75,6 +75,7 @@
#define KVM_REQ_HV_EXITKVM_ARCH_REQ(21)
#define KVM_REQ_HV_STIMER KVM_ARCH_REQ(22)
#define KVM_REQ_LOAD_EOI_EXITMAP KVM_ARCH_REQ(23)
+#define KVM_REQ_GET_VMCS12_PAGES KVM_ARCH_REQ(24)
#define CR0_RESERVED_BITS \
(~(unsigned long)(X86_CR0_PE | X86_CR0_MP | X86_CR0_EM | X86_CR0_TS \
@@ -1087,6 +1088,12 @@ struct kvm_x86_ops {
void (*setup_mce)(struct kvm_vcpu *vcpu);
+ int (*get_nested_state)(struct kvm_vcpu *vcpu,
+ struct kvm_nested_state __user
*user_kvm_nested_state);
+ int (*set_nested_state)(struct kvm_vcpu *vcpu,
+ struct kvm_nested_state __user
*user_kvm_nested_state);
+ void (*get_vmcs12_pages)(struct kvm_vcpu *vcpu);
+
int (*smi_allowed)(struct kvm_vcpu *vcpu);
int (*pre_enter_smm)(
Re: [PATCH v11 2/2] dt: qcom: Add qcom-cpufreq-kryo driver configuration
On Wed, May 23, 2018 at 04:11:31PM +0300, Ilia Lin wrote: > 1. Add NVMEM node for the speedbin > 2. Add definitions for all possible MSM8996 CPU OPPs. > The qcom-cpufreq-kryo driver will select the appropriate subset. > > Signed-off-by: Ilia Lin > Acked-by: Viresh Kumar > --- > arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 2 +- > arch/arm64/boot/dts/qcom/msm8996.dtsi | 281 > ++-- > 2 files changed, 270 insertions(+), 13 deletions(-) > Hello Ilia, Viresh I tried this patch series (together with you cpu clock driver). The first problem is that the driver fails to create debugfs entries. The second problem appears to be that it runs on unlisted frequency. Is this simply because of missing entries in the opp table? [4.538513] cpu cpu1: opp_list_debug_create_link: Failed to create link [4.538567] cpu cpu1: _add_opp_dev: Failed to register opp debugfs (-12) [4.544514] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 614400 KHz [4.551441] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 652800 KHz [4.563219] cpu cpu3: opp_list_debug_create_link: Failed to create link [4.566937] cpu cpu3: _add_opp_dev: Failed to register opp debugfs (-12) [4.573489] cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 19200 KHz [4.580368] cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to: 307200 KHz Kind regards, Niklas
Re: [PATCH 1/3] dt-bindings: clk: g12a: New binding for Meson-G12A SoC
On Mon, 2018-07-09 at 19:12 +0800, Jian Hu wrote: > Add new binding for Meson-G12A SoC Everything-Else part nitpick: I would prefer if the words 'clock' and 'controller' was somewhere in the description. Maybe "add new clock controller compatible for the EE domain of the g12a SoC" ? > > Signed-off-by: Jian Hu > --- > Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt > b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt > index e950599..0833006 100644 > --- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt > +++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt > @@ -9,6 +9,7 @@ Required Properties: > "amlogic,gxbb-clkc" for GXBB SoC, > "amlogic,gxl-clkc" for GXL and GXM SoC, > "amlogic,axg-clkc" for AXG SoC. > + "amlogic,g12a-clkc" for G12A SoC. > > - #clock-cells: should be 1. >
Re: 4.18-rc* regression: x86-32 troubles (with timers?)
On Wed 2018-07-04 14:41:08, Meelis Roos wrote: > I tried 4.18.0-rc1-00023-g9ffc59d57228 and now > 4.18.0-rc3-00113-gfc36def997cf on a 32-bit server and then some other > 32-bit machines, and got half-failed bootup - kernel and userspace come > up but some services fail to start, including network and > systemd-journald: > > systemd-journald[85]: Assertion 'clock_gettime(map_clock_id(clock_id), &ts) > == 0' failed at ../src/basic/time-util.c:53, function now(). Aborting. > > I then tried multiple other machines. All x86-64 machines seem > unaffected, some x86-32 machines are affected (Athlon with AMD750 > chipset, Fujitsu RX100-S2 with P4-3.4, and P4 with Intel 865 chipset), > some very similar x86-32 machines are unaffected. I have different > customized kernel configuration on them, so far I have not pinpointed > any configuration option to be at fault. > > All machines run Debian unstable. > > 4.17.0 was working fine. > > Will continue with bisecting between 4.17.0 and > 4.18.0-rc1-00023-g9ffc59d57228. I don't think if it helps you, but 4.18-rc4 seems to work okay for me (and previous versions did, too) on thinkpad X60. But I'm using older debian version. 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] locking/lockdep: Dump state of percpu_rwsem upon hung up.
On Tue, Jul 10, 2018 at 03:10:51PM +0900, Tetsuo Handa wrote:
> From 2642b4a1904259384f2018ea8df03ac49509c57a Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 10 Jul 2018 15:01:20 +0900
> Subject: [PATCH] locking/rwsem: Convert the other sem->count to
> 'atomic_long_t'
>
> Since "locking/rwsem: Convert sem->count to 'atomic_long_t'" forgot to
> convert "struct rw_semaphore"->count in linux/rwsem-spinlock.h which is
> used when CONFIG_RWSEM_GENERIC_SPINLOCK=y, trying to access it in MIPS
> architecture causes build error due to type mismatch.
>
> error: passing argument 1 of 'atomic_long_read' from incompatible pointer
> type [-Werror=incompatible-pointer-types]
> note: expected 'const atomic_long_t * {aka const struct *}' but
> argument is of type '__s32 * {aka int *}'
>
> Signed-off-by: Tetsuo Handa
> Reported-by: kbuild test robot
> Fixes: 8ee62b1870be8e63 ("locking/rwsem: Convert sem->count to
> 'atomic_long_t'")
> Cc: stable # v4.8+
> Cc: Jason Low
> Cc: Peter Zijlstra
> ---
> include/linux/rwsem-spinlock.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/rwsem-spinlock.h b/include/linux/rwsem-spinlock.h
> index e475683..1164965 100644
> --- a/include/linux/rwsem-spinlock.h
> +++ b/include/linux/rwsem-spinlock.h
> @@ -22,7 +22,7 @@
> * - if wait_list is not empty, then there are processes waiting for the
> semaphore
> */
> struct rw_semaphore {
> - __s32 count;
> + atomic_long_t count;
Uhhh... how does this even build? rwsem-spinlock.c doesn't use
atomic_long primitives to change count.
And the atomic_long count usage is completely private to rwsem-xadd.c,
nothing outside of that should use that field, ever.
Re: [PATCH] Revert "arm64: Use aarch64elf and aarch64elfb emulation mode variants"
Hi,
On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote:
> Thanks, Laura.
>
> I'll take this as a fix, and add a comment to the Makefile to justify
> why we need the linux target.
So this comes down to either breaking fedora/debian toolchains (that
don't support elf emulation mode) or breaking bare-metal toolchains
(that don't support linux emulation mode).
Since Linux is a bare-metal project that does not technically require
the linux target (who said using "Linux" for all things is confusing?),
I think it should aim for the elf target in the long term.
But well, breaking Linux build in common distros isn't good either, so I
guess it makes sense to revert this while distros toolchains are being
fixed. Hopefully, it won't take too long.
What do you think?
Cheers,
Paul
> Will
>
> On Mon, Jul 09, 2018 at 01:09:56PM -0700, Laura Abbott wrote:
> > This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9.
> >
> > This breaks compilation with Fedora gcc-8 tool chains:
> >
> > CHK include/generated/compile.h
> > LD [M] arch/arm64/crypto/sha512-ce.o
> > aarch64-linux-gnu-ld: cannot open linker script file
> > ldscripts/aarch64elf.xr: No such file or directory
> > make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o]
> > Error 1
> > make: *** [Makefile:1029: arch/arm64/crypto] Error 2
> >
> > Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode
> > variants")
> > Signed-off-by: Laura Abbott
> > ---
> > A bit rushed and I'm still debugging but I wanted to send this out
> > before anyone else gets hit since it is -rc4. Seeing this on both native
> > and cross compiles.
> > ---
> > arch/arm64/Makefile | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 7976d2d242fa..f476d52ad8d6 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -60,13 +60,13 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> > KBUILD_CPPFLAGS+= -mbig-endian
> > CHECKFLAGS += -D__AARCH64EB__
> > AS += -EB
> > -LDFLAGS+= -EB -maarch64elfb
> > +LDFLAGS+= -EB -maarch64linuxb
> > UTS_MACHINE:= aarch64_be
> > else
> > KBUILD_CPPFLAGS+= -mlittle-endian
> > CHECKFLAGS += -D__AARCH64EL__
> > AS += -EL
> > -LDFLAGS+= -EL -maarch64elf
> > +LDFLAGS+= -EL -maarch64linux
> > UTS_MACHINE:= aarch64
> > endif
> >
> > --
> > 2.17.1
> >
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Re: 4.18-rc* regression: x86-32 troubles (with timers?)
On Wed 2018-07-04 14:41:08, Meelis Roos wrote: > I tried 4.18.0-rc1-00023-g9ffc59d57228 and now > 4.18.0-rc3-00113-gfc36def997cf on a 32-bit server and then some other > 32-bit machines, and got half-failed bootup - kernel and userspace come > up but some services fail to start, including network and > systemd-journald: > > systemd-journald[85]: Assertion 'clock_gettime(map_clock_id(clock_id), &ts) > == 0' failed at ../src/basic/time-util.c:53, function now(). Aborting. > > I then tried multiple other machines. All x86-64 machines seem > unaffected, some x86-32 machines are affected (Athlon with AMD750 > chipset, Fujitsu RX100-S2 with P4-3.4, and P4 with Intel 865 chipset), > some very similar x86-32 machines are unaffected. I have different > customized kernel configuration on them, so far I have not pinpointed > any configuration option to be at fault. > > All machines run Debian unstable. > > 4.17.0 was working fine. > > Will continue with bisecting between 4.17.0 and > 4.18.0-rc1-00023-g9ffc59d57228. Details of my tests (.config, dmesg, versions) can be found in https://github.com/pavelmachek/missy/tree/master/db/notebook/lenovo/thinkpad/x60/pavel/2018.3648830947643 (and nearby directories). 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 v3] soc: imx: gpc: Turn PU domain on/off in sleep on 6qp
On 10 July 2018 at 10:05, Lucas Stach wrote: > Am Dienstag, den 10.07.2018, 00:27 +0200 schrieb Ulf Hansson: >> > On 6 July 2018 at 18:46, Leonard Crestez wrote: >> > On imx6qp power gating on the PU domain is disabled because of errata >> > ERR009619. However power gating during suspend/resume can still be >> > performed. >> >> Sounds a bit hand wavy. Exactly why can it be done during system >> suspend/resume? > > Power gating this domain in normal operation may introduce a glitch in > unrelated modules, potentially disturbing a running display scanout. > This is not a concern when the whole system enters suspend state, so > it's safe to do in this case. Makes sense. Could we please fold this information into the commit message to make this clear!? > > Regards, > Lucas > >> > >> > Enable this by implementing SLEEP_PM_OPS in imx_pgc_power_domain_driver. >> > >> > In order to ensure correct ordering add device links from devices inside >> > the PU domain to the pgc platform_device. >> >> In genpd, the PM domain gets powered off after all device's >> corresponding ->suspend_noirq() callback has been invoked - and it >> also considers if there are some wakeup settings enabled, possibly >> avoiding to do the power off. >> >> It sound like the imx's power domain driver ->power_off|on() callback >> should deal with this, to make get a consistent behavior. I understand >> that you currently can't tell under what circumstances the >> ->power_off|on() callbacks are being invoked, that may need some >> changes in genpd. >> >> Currently we have a flag, GENPD_FLAG_ALWAYS_ON which makes genpd to >> always prevent power off. Perhaps we should add a new flag >> "GENPD_FLAG_RUNTIME_ON", which makes genpd to call the >> ->power_on|off() callbacks, but only during system wide PM. >> >> Thoughts? > > Yes, this might work for this case. Alright. I can help to implement, if you want. Just tell. Kind regards Uffe
Re: [PATCH] Revert "arm64: Use aarch64elf and aarch64elfb emulation mode variants"
On Tue, Jul 10, 2018 at 11:30:39AM +0200, Paul Kocialkowski wrote: > On Tue, 2018-07-10 at 10:01 +0100, Will Deacon wrote: > > Thanks, Laura. > > > > I'll take this as a fix, and add a comment to the Makefile to justify > > why we need the linux target. > > So this comes down to either breaking fedora/debian toolchains (that > don't support elf emulation mode) or breaking bare-metal toolchains > (that don't support linux emulation mode). > > Since Linux is a bare-metal project that does not technically require > the linux target (who said using "Linux" for all things is confusing?), > I think it should aim for the elf target in the long term. > > But well, breaking Linux build in common distros isn't good either, so I > guess it makes sense to revert this while distros toolchains are being > fixed. Hopefully, it won't take too long. > > What do you think? Yes, we need to revert the change since it's a regression otherwise. I think the best course of action here would be to find a way that we can either tell the linker that it doesn't need the missing linker scripts because we're providing our own, or find a way to pass different LD flags depending on whether or not we have a linux toolchain. For now, I've pushed the revert to for-next/fixes. Will
Re: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3
On Tue, Jul 10, 2018 at 12:26:34PM +0800, Huacai Chen wrote:
> Hi, Paul and Peter,
>
> I think we find the real root cause, READ_ONCE() doesn't need any
> barriers, the problematic code is queued_spin_lock_slowpath() in
> kernel/locking/qspinlock.c:
>
> if (old & _Q_TAIL_MASK) {
> prev = decode_tail(old);
>
> /* Link @node into the waitqueue. */
> WRITE_ONCE(prev->next, node);
>
> pv_wait_node(node, prev);
> arch_mcs_spin_lock_contended(&node->locked);
>
> /*
> * While waiting for the MCS lock, the next pointer may have
> * been set by another lock waiter. We optimistically load
> * the next pointer & prefetch the cacheline for writing
> * to reduce latency in the upcoming MCS unlock operation.
> */
> next = READ_ONCE(node->next);
> if (next)
> prefetchw(next);
> }
>
> After WRITE_ONCE(prev->next, node); arch_mcs_spin_lock_contended()
> enter a READ_ONCE() loop, so the effect of WRITE_ONCE() is invisible
> by other cores because of the write buffer.
And _that_ is a hardware bug. Also please explain how that is different
from the ARM bug mentioned elsewhere.
> As a result,
> arch_mcs_spin_lock_contended() will wait for ever because the waiters
> of prev->next will wait for ever. I think the right way to fix this is
> flush SFB after this WRITE_ONCE(), but I don't have a good solution:
> 1, MIPS has wbflush() which can be used to flush SFB, but other archs
> don't have;
Sane archs don't need this.
> 2, Every arch has mb(), and add mb() after WRITE_ONCE() can actually
> solve Loongson's problem, but in syntax, mb() is different from
> wbflush();
Still wrong, because any non-broken arch doesn't need that flush to
begin with.
> 3, Maybe we can define a Loongson-specific WRITE_ONCE(), but not every
> WRITE_ONCE() need wbflush(), we only need wbflush() between
> WRITE_ONCE() and a READ_ONCE() loop.
No no no no ...
So now explain why the cpu_relax() hack that arm did doesn't work for
you?
Re: [PATCH] KVM: Switch 'requests' to be 64-bit (explicitly)
On Thu, 2018-07-05 at 14:51 +0100, Mark Rutland wrote:
> On Sun, Apr 15, 2018 at 12:26:44AM +0200, KarimAllah Ahmed wrote:
> >
> > Switch 'requests' to be explicitly 64-bit and update BUILD_BUG_ON check to
> > use the size of "requests" instead of the hard-coded '32'.
> >
> > That gives us a bit more room again for arch-specific requests as we
> > already ran out of space for x86 due to the hard-coded check.
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Cc: k...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: KarimAllah Ahmed
> > ---
> > include/linux/kvm_host.h | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 6930c63..fe4f46b 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -129,7 +129,7 @@ static inline bool is_error_page(struct page *page)
> > #define KVM_REQUEST_ARCH_BASE 8
> >
> > #define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
> > - BUILD_BUG_ON((unsigned)(nr) >= 32 - KVM_REQUEST_ARCH_BASE); \
> > + BUILD_BUG_ON((unsigned)(nr) >= (sizeof(((struct kvm_vcpu
> > *)0)->requests) * 8) - KVM_REQUEST_ARCH_BASE); \
> > (unsigned)(((nr) + KVM_REQUEST_ARCH_BASE) | (flags)); \
> > })
> > #define KVM_ARCH_REQ(nr) KVM_ARCH_REQ_FLAGS(nr, 0)
> > @@ -223,7 +223,7 @@ struct kvm_vcpu {
> > int vcpu_id;
> > int srcu_idx;
> > int mode;
> > - unsigned long requests;
> > + u64 requests;
>
> The usual thing to do for bitmaps is something like:
>
> #define KVM_REQUEST_NR(KVM_REQUEST_ARCH_BASE +
> KVM_REQUEST_ARCH_NR)
>
> unsigned long requests[BITS_TO_LONGS(NR_KVM_REQUESTS)];
>
> >
> > unsigned long guest_debug;
> >
> > int pre_pcpu;
> > @@ -1122,7 +1122,7 @@ static inline void kvm_make_request(int req, struct
> > kvm_vcpu *vcpu)
> > * caller. Paired with the smp_mb__after_atomic in kvm_check_request.
> > */
> > smp_wmb();
> > - set_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
> > + set_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
>
> ... which wouldn't require a void cast to make the bit API functions
> happy (as these expect a pointer to the first unsigned long in the
> bitmap).
Ah, right! Good point.
Paolo,
Would you prefer to switch "requests" to a bitmap and
update kvm_request_pending to handle this?
>
> Thanks,
> Mark.
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote: > More than one kernel developer has expressed the opinion that the LKMM > should enforce ordering of writes by locking. In other words, given I'd like to step back on this point: I still don't have a strong opinion on this, but all this debating made me curious about others' opinion ;-) I'd like to see the above argument expanded: what's the rationale behind that opinion? can we maybe add references to actual code relying on that ordering? other that I've been missing? I'd extend these same questions to the "ordering of reads" snippet below (and discussed since so long...). > the following code: > > WRITE_ONCE(x, 1); > spin_unlock(&s): > spin_lock(&s); > WRITE_ONCE(y, 1); > > the stores to x and y should be propagated in order to all other CPUs, > even though those other CPUs might not access the lock s. In terms of > the memory model, this means expanding the cumul-fence relation. > > Locks should also provide read-read (and read-write) ordering in a > similar way. Given: > > READ_ONCE(x); > spin_unlock(&s); > spin_lock(&s); > READ_ONCE(y); // or WRITE_ONCE(y, 1); > > the load of x should be executed before the load of (or store to) y. > The LKMM already provides this ordering, but it provides it even in > the case where the two accesses are separated by a release/acquire > pair of fences rather than unlock/lock. This would prevent > architectures from using weakly ordered implementations of release and > acquire, which seems like an unnecessary restriction. The patch > therefore removes the ordering requirement from the LKMM for that > case. IIUC, the same argument could be used to support the removal of the new unlock-rf-lock-po (we already discussed riscv .aq/.rl, it doesn't seem hard to imagine an arm64 LDAPR-exclusive, or the adoption of ctrl+isync on powerpc). Why are we effectively preventing their adoption? Again, I'd like to see more details about the underlying motivations... > > All the architectures supported by the Linux kernel (including RISC-V) > do provide this ordering for locks, albeit for varying reasons. > Therefore this patch changes the model in accordance with the > developers' wishes. > > Signed-off-by: Alan Stern > > --- > > v.2: Restrict the ordering to lock operations, not general release > and acquire fences. This is another controversial point, and one that makes me shivering ... I have the impression that we're dismissing the suggestion "RMW-acquire at par with LKR" with a bit of rush. So, this patch is implying that: while (cmpxchg_acquire(&s, 0, 1) != 0) cpu_relax(); is _not_ a valid implementation of spin_lock()! or, at least, it is not when paired with an smp_store_release(). Will was anticipating inserting arch hooks into the (generic) qspinlock code, when we know that similar patterns are spread all over in (q)rwlocks, mutexes, rwsem, ... (please also notice that the informal documentation is currently treating these synchronization mechanisms equally as far as "ordering" is concerned...). This distinction between locking operations and "other acquires" appears to me not only unmotivated but also extremely _fragile (difficult to use /maintain) when considering the analysis of synchronization mechanisms such as those mentioned above or their porting for new arch. Please see below for a couple of minor comments. > > [as1871b] > > > tools/memory-model/Documentation/explanation.txt | > 186 +++--- > tools/memory-model/linux-kernel.cat| >8 > tools/memory-model/litmus-tests/ISA2+pooncelock+pooncelock+pombonce.litmus | >5 > 3 files changed, 149 insertions(+), 50 deletions(-) > > Index: usb-4.x/tools/memory-model/linux-kernel.cat > === > --- usb-4.x.orig/tools/memory-model/linux-kernel.cat > +++ usb-4.x/tools/memory-model/linux-kernel.cat > @@ -38,7 +38,7 @@ let strong-fence = mb | gp > (* Release Acquire *) > let acq-po = [Acquire] ; po ; [M] > let po-rel = [M] ; po ; [Release] > -let rfi-rel-acq = [Release] ; rfi ; [Acquire] > +let unlock-rf-lock-po = [UL] ; rf ; [LKR] ; po > > (**) > (* Fundamental coherence ordering *) > @@ -60,13 +60,13 @@ let dep = addr | data > let rwdep = (dep | ctrl) ; [W] > let overwrite = co | fr > let to-w = rwdep | (overwrite & int) > -let to-r = addr | (dep ; rfi) | rfi-rel-acq > +let to-r = addr | (dep ; rfi) > let fence = strong-fence | wmb | po-rel | rmb | acq-po > -let ppo = to-r | to-w | fence > +let ppo = to-r | to-w | fence | (unlock-rf-lock-po & int) > > (* Propagation: Ordering from release operations and strong fences. *) > let A-cumul(r) = rfe? ; r > -let cumul-fence = A-cumul(strong-fence | po-rel) | wmb > +let cumul-fence = A-cumul(strong-fence | po-rel) | wmb |
Re: [PATCH] locking/rwsem: Convert the other sem->count to 'atomic_long_t'
Hi Tetsuo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/locking/core]
[also build test WARNING on v4.18-rc4 next-20180709]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tetsuo-Handa/locking-rwsem-Convert-the-other-sem-count-to-atomic_long_t/20180710-141553
config: parisc-c3000_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=parisc
All warnings (new ones prefixed by >>):
In file included from include/linux/notifier.h:15:0,
from include/linux/memory_hotplug.h:7,
from include/linux/mmzone.h:777,
from include/linux/gfp.h:6,
from include/linux/umh.h:4,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/usb/core/hcd-pci.c:7:
include/linux/rwsem.h:87:2: warning: missing braces around initializer
[-Wmissing-braces]
{ __RWSEM_INIT_COUNT(name),\
^
include/linux/rwsem.h:94:29: note: in expansion of macro
'__RWSEM_INITIALIZER'
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
^~~
>> drivers/usb/core/hcd-pci.c:31:8: note: in expansion of macro 'DECLARE_RWSEM'
static DECLARE_RWSEM(companions_rwsem);
^
vim +/DECLARE_RWSEM +31 drivers/usb/core/hcd-pci.c
^1da177e4 Linus Torvalds 2005-04-16 @7 #include
^1da177e4 Linus Torvalds 2005-04-16 8 #include
21b1861fb David Brownell 2005-11-23 9 #include
27729aadd Eric Lescouet 2010-04-24 10 #include
21b1861fb David Brownell 2005-11-23 11
^1da177e4 Linus Torvalds 2005-04-16 12 #include
^1da177e4 Linus Torvalds 2005-04-16 13 #include
21b1861fb David Brownell 2005-11-23 14
21b1861fb David Brownell 2005-11-23 15 #ifdef CONFIG_PPC_PMAC
21b1861fb David Brownell 2005-11-23 16 #include
21b1861fb David Brownell 2005-11-23 17 #include
21b1861fb David Brownell 2005-11-23 18 #include
21b1861fb David Brownell 2005-11-23 19 #endif
5f827ea3c David Brownell 2005-09-22 20
5f827ea3c David Brownell 2005-09-22 21 #include "usb.h"
^1da177e4 Linus Torvalds 2005-04-16 22
^1da177e4 Linus Torvalds 2005-04-16 23
c6053ecff David Brownell 2005-04-18 24 /* PCI-based HCs are common, but
plenty of non-PCI HCs are used too */
^1da177e4 Linus Torvalds 2005-04-16 25
05768918b Alan Stern 2013-03-28 26 /*
05768918b Alan Stern 2013-03-28 27 * Coordinate handoffs between EHCI
and companion controllers
05768918b Alan Stern 2013-03-28 28 * during EHCI probing and system
resume.
6d19c009c Alan Stern 2010-02-12 29 */
6d19c009c Alan Stern 2010-02-12 30
05768918b Alan Stern 2013-03-28 @31 static DECLARE_RWSEM(companions_rwsem);
6d19c009c Alan Stern 2010-02-12 32
:: The code at line 31 was first introduced by commit
:: 05768918b9a122ce21bd55950df5054ff6c57f28 USB: improve port transitions
when EHCI starts up
:: TO: Alan Stern
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] locking/rwsem: Convert the other sem->count to 'atomic_long_t'
Hi Tetsuo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/locking/core]
[also build test WARNING on v4.18-rc4 next-20180709]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tetsuo-Handa/locking-rwsem-Convert-the-other-sem-count-to-atomic_long_t/20180710-141553
config: m68k-m5475evb_defconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=m68k
All warnings (new ones prefixed by >>):
In file included from include/linux/notifier.h:15:0,
from include/linux/memory_hotplug.h:7,
from include/linux/mmzone.h:777,
from include/linux/gfp.h:6,
from include/linux/idr.h:16,
from include/linux/kernfs.h:14,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/pci.h:29,
from drivers//pci/search.c:11:
include/linux/rwsem.h:87:2: warning: missing braces around initializer
[-Wmissing-braces]
{ __RWSEM_INIT_COUNT(name),\
^
include/linux/rwsem.h:94:29: note: in expansion of macro
'__RWSEM_INITIALIZER'
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
^~~
>> drivers//pci/search.c:17:1: note: in expansion of macro 'DECLARE_RWSEM'
DECLARE_RWSEM(pci_bus_sem);
^
vim +/DECLARE_RWSEM +17 drivers//pci/search.c
^1da177e Linus Torvalds 2005-04-16 @11 #include
5a0e3ad6 Tejun Heo 2010-03-24 12 #include
^1da177e Linus Torvalds 2005-04-16 13 #include
^1da177e Linus Torvalds 2005-04-16 14 #include
^1da177e Linus Torvalds 2005-04-16 15 #include "pci.h"
^1da177e Linus Torvalds 2005-04-16 16
d71374da Zhang Yanmin 2006-06-02 @17 DECLARE_RWSEM(pci_bus_sem);
ce29ca3e Amos Kong 2012-05-23 18 EXPORT_SYMBOL_GPL(pci_bus_sem);
ce29ca3e Amos Kong 2012-05-23 19
:: The code at line 17 was first introduced by commit
:: d71374dafbba7ec3f67371d3b7e9f6310a588808 [PATCH] PCI: fix race with
pci_walk_bus and pci_destroy_dev
:: TO: Zhang Yanmin
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] mm, oom: remove sleep from under oom_lock
On Mon 09-07-18 15:49:53, David Rientjes wrote:
> On Mon, 9 Jul 2018, Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent
> > munlock and oom reaper unmap, v3") we have a strong synchronization
> > between the oom_killer and victim's exiting because both have to take
> > the oom_lock. Therefore the original heuristic to sleep for a short time
> > in out_of_memory doesn't serve the original purpose.
> >
> > Moreover Tetsuo has noticed that the short sleep can be more harmful
> > than actually useful. Hammering the system with many processes can lead
> > to a starvation when the task holding the oom_lock can block for a
> > long time (minutes) and block any further progress because the
> > oom_reaper depends on the oom_lock as well.
> >
> > Drop the short sleep from out_of_memory when we hold the lock. Keep the
> > sleep when the trylock fails to throttle the concurrent OOM paths a bit.
> > This should be solved in a more reasonable way (e.g. sleep proportional
> > to the time spent in the active reclaiming etc.) but this is much more
> > complex thing to achieve. This is a quick fixup to remove a stale code.
> >
> > Reported-by: Tetsuo Handa
> > Signed-off-by: Michal Hocko
>
> This reminds me:
>
> mm/oom_kill.c
>
> 54) int sysctl_oom_dump_tasks = 1;
> 55)
> 56) DEFINE_MUTEX(oom_lock);
> 57)
> 58) #ifdef CONFIG_NUMA
>
> Would you mind documenting oom_lock to specify what it's protecting?
What do you think about the following?
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index ed9d473c571e..32e6f7becb40 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -53,6 +53,14 @@ int sysctl_panic_on_oom;
int sysctl_oom_kill_allocating_task;
int sysctl_oom_dump_tasks = 1;
+/*
+ * Serializes oom killer invocations (out_of_memory()) from all contexts to
+ * prevent from over eager oom killing (e.g. when the oom killer is invoked
+ * from different domains).
+ *
+ * oom_killer_disable() relies on this lock to stabilize oom_killer_disabled
+ * and mark_oom_victim
+ */
DEFINE_MUTEX(oom_lock);
#ifdef CONFIG_NUMA
--
Michal Hocko
SUSE Labs
Re: kconfig usage in automatic kernel test
On 07/08/2018 10:15 AM, Masahiro Yamada wrote: > 2018-07-06 17:49 GMT+09:00 Cao jin : >> Masahiro-san, >> >> I am writing some utility for internal kdump test with latest kernel, >> my purpose is to test the new introduced kernel feature. For automatical >> test, I see several config target could help, like olddefconfig, all*config. >> >> But for my purpose, I don't find a good way. For example, olddefconfig >> will let the now config item has default value, while some feature may >> default to "N"; allyesconfig will slow the compilation notably. >> But "all*config" has KCONFIG_ALLCONFIG help to customizing some config >> item, that is a good utility, but seems it can't be used in olddefconfig. >> >> All these things let me have 2 questions: >> >> 1. What would you suggest for my purpose? > > > scripts/kconfig/merge_config.sh > can be used with any *config target. > I took a quick glance at the script, it seems a good method to me. Thanks very much, Masahiro-san. > If you want to tweak some symbols based on olddefconfig, > this could be the one you want. > > >> 2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild, >> but what's the purpose of allnoconfig, alldefconfig? In others words, >> when people would need allnoconfig, alldefconfig? > > I sometimes use allnoconfig for build testing. > > When I want to test the whole build process quickly, > I disable as many drivers as possible to save time. > > > I do not use alldefconfig. > Anyway, it would not hurt to have it for completeness. > Thanks for clarifying. -- Sincerely, Cao jin
[PATCH v4 4/5] rtc: isl1208: set ev-evienb bit from device tree
From: Denis Osterland
Add support to disable event in pull-up.
Signed-off-by: Denis Osterland
---
drivers/rtc/rtc-isl1208.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index bbe08c1ab9f3..2f18ee3c615a 100644
--- a/drivers/rtc/rtc-isl1208.c
+++ b/drivers/rtc/rtc-isl1208.c
@@ -44,6 +44,7 @@
#define ISL1208_REG_INT_IM (1<<7) /* interrupt/alarm mode */
#define ISL1219_REG_EV 0x09
#define ISL1219_REG_EV_EVEN(1<<4) /* event detection enable */
+#define ISL1219_REG_EV_EVIENB (1<<7) /* event in pull-up disable */
#define ISL1208_REG_ATR 0x0a
#define ISL1208_REG_DTR 0x0b
@@ -777,7 +778,10 @@ isl1208_probe(struct i2c_client *client, const struct
i2c_device_id *id)
"please set clock.\n");
if (id->driver_data == TYPE_ISL1219) {
+ struct device_node *np = client->dev.of_node;
rc = ISL1219_REG_EV_EVEN;
+ if (of_get_property(np, "isil,ev-evienb", NULL))
+ rc |= ISL1219_REG_EV_EVIENB;
rc = i2c_smbus_write_byte_data(client, ISL1219_REG_EV, rc);
if (rc < 0) {
dev_err(&client->dev, "could not enable tamper
detection\n");
@@ -786,7 +790,7 @@ isl1208_probe(struct i2c_client *client, const struct
i2c_device_id *id)
rc = rtc_add_group(rtc, &isl1219_rtc_sysfs_files);
if (rc)
return rc;
- evdet_irq = of_irq_get_byname(client->dev.of_node, "evdet");
+ evdet_irq = of_irq_get_byname(np, "evdet");
}
rc = sysfs_create_group(&client->dev.kobj, &isl1208_rtc_sysfs_files);
--
2.18.0
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315
___
Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung
und/oder Publikation dieser E-Mail ist strengstens untersagt.
The contents of the above mentioned e-mail is not legally binding. This e-mail
contains confidential and/or legally protected information. Please inform us if
you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction,
disclosure, alteration, distribution and/or publication of this e-mail is
strictly prohibited.
[PATCH v4 0/5] rtc: isl1208: fixes, documentation and isl1219 support
changes since v3: Add function to rtc-sysfs to add a group to device groups field, between alloc and register calls. Remove isl1208 struct to reduce patch footprint. Change prefix of defines and functions only available on isl1219. Use DEVICE_ATTR_RW macro for timestamp0 attribute. Call validate tm before convert and use unsigned long long cased value. Add device-tree flag to disable event in pull-up to maximize battery life time. Michael Grzeschik (1): rtc: isl1208: add support for isl1219 with tamper detection Denis Osterland (4): rtc: sysfs: facilitate attribute add to rtc device rtc: isl1208: Add "evdet" interrupt source for isl1219. rtc: isl1208: set ev-evienb bit from device tree rtc: isl1219: add device tree docu .../devicetree/bindings/rtc/isil,isl1219.txt | 29 drivers/rtc/rtc-core.h | 6 + drivers/rtc/rtc-isl1208.c | 181 ++--- drivers/rtc/rtc-sysfs.c| 39 + 4 files changed, 232 insertions(+), 23 deletions(-) Message-Id: 1520246373-19023-1-git-send-email-denis.osterl...@diehl.com Diehl Connectivity Solutions GmbH Geschäftsführung: Horst Leonberger Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht Nürnberg: HRB 32315 ___ Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten haben. Bitte loeschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited.
[PATCH v4 2/5] rtc: isl1208: add support for isl1219 with tamper detection
From: Michael Grzeschik
We add support for the ISL1219 chip that got an integrated tamper
detection function. This patch implements the feature by adding
an additional timestamp0 file to sysfs device path.
This file contains seconds since epoch, if an event occurred,
or is empty, if none occurred.
Signed-off-by: Michael Grzeschik
Signed-off-by: Denis Osterland
---
drivers/rtc/rtc-isl1208.c | 131 --
1 file changed, 124 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index 1a2c38cc0178..bb189fe6744a 100644
--- a/drivers/rtc/rtc-isl1208.c
+++ b/drivers/rtc/rtc-isl1208.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include "rtc-core.h"
/* Register map */
/* rtc section */
@@ -33,13 +34,15 @@
#define ISL1208_REG_SR_ARST(1<<7) /* auto reset */
#define ISL1208_REG_SR_XTOSCB (1<<6) /* crystal oscillator */
#define ISL1208_REG_SR_WRTC(1<<4) /* write rtc */
+#define ISL1208_REG_SR_EVT (1<<3) /* event */
#define ISL1208_REG_SR_ALM (1<<2) /* alarm */
#define ISL1208_REG_SR_BAT (1<<1) /* battery */
#define ISL1208_REG_SR_RTCF(1<<0) /* rtc fail */
#define ISL1208_REG_INT 0x08
#define ISL1208_REG_INT_ALME (1<<6) /* alarm enable */
#define ISL1208_REG_INT_IM (1<<7) /* interrupt/alarm mode */
-#define ISL1208_REG_09 0x09 /* reserved */
+#define ISL1219_REG_EV 0x09
+#define ISL1219_REG_EV_EVEN(1<<4) /* event detection enable */
#define ISL1208_REG_ATR 0x0a
#define ISL1208_REG_DTR 0x0b
@@ -57,8 +60,24 @@
#define ISL1208_REG_USR2 0x13
#define ISL1208_USR_SECTION_LEN 2
+/* event section */
+#define ISL1219_REG_SCT 0x14
+#define ISL1219_REG_MNT 0x15
+#define ISL1219_REG_HRT 0x16
+#define ISL1219_REG_DTT 0x17
+#define ISL1219_REG_MOT 0x18
+#define ISL1219_REG_YRT 0x19
+#define ISL1219_EVT_SECTION_LEN 6
+
static struct i2c_driver isl1208_driver;
+/* ISL1208 various variants */
+enum {
+ TYPE_ISL1208 = 0,
+ TYPE_ISL1218,
+ TYPE_ISL1219,
+};
+
/* block read */
static int
isl1208_i2c_read_regs(struct i2c_client *client, u8 reg, u8 buf[],
@@ -80,8 +99,8 @@ isl1208_i2c_read_regs(struct i2c_client *client, u8 reg, u8
buf[],
};
int ret;
- BUG_ON(reg > ISL1208_REG_USR2);
- BUG_ON(reg + len > ISL1208_REG_USR2 + 1);
+ WARN_ON(reg > ISL1219_REG_YRT);
+ WARN_ON(reg + len > ISL1219_REG_YRT + 1);
ret = i2c_transfer(client->adapter, msgs, 2);
if (ret > 0)
@@ -104,8 +123,8 @@ isl1208_i2c_set_regs(struct i2c_client *client, u8 reg, u8
const buf[],
};
int ret;
- BUG_ON(reg > ISL1208_REG_USR2);
- BUG_ON(reg + len > ISL1208_REG_USR2 + 1);
+ WARN_ON(reg > ISL1219_REG_YRT);
+ WARN_ON(reg + len > ISL1219_REG_YRT + 1);
i2c_buf[0] = reg;
memcpy(&i2c_buf[1], &buf[0], len);
@@ -493,6 +512,73 @@ isl1208_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alarm)
return isl1208_i2c_set_alarm(to_i2c_client(dev), alarm);
}
+static ssize_t timestamp0_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = dev_get_drvdata(dev);
+ int sr;
+
+ sr = isl1208_i2c_get_sr(client);
+ if (sr < 0) {
+ dev_err(dev, "%s: reading SR failed\n", __func__);
+ return sr;
+ }
+
+ sr &= ~ISL1208_REG_SR_EVT;
+
+ sr = i2c_smbus_write_byte_data(client, ISL1208_REG_SR, sr);
+ if (sr < 0)
+ dev_err(dev, "%s: writing SR failed\n",
+ __func__);
+
+ return count;
+};
+
+static ssize_t timestamp0_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct i2c_client *client = dev_get_drvdata(dev);
+ u8 regs[ISL1219_EVT_SECTION_LEN] = { 0, };
+ struct rtc_time tm;
+ int sr;
+
+ sr = isl1208_i2c_get_sr(client);
+ if (sr < 0) {
+ dev_err(dev, "%s: reading SR failed\n", __func__);
+ return sr;
+ }
+
+ if (!(sr & ISL1208_REG_SR_EVT))
+ return 0;
+
+ sr = isl1208_i2c_read_regs(client, ISL1219_REG_SCT, regs,
+ ISL1219_EVT_SECTION_LEN);
+ if (sr < 0) {
+ dev_err(dev, "%s: reading event section failed\n",
+ __func__);
+ return 0;
+ }
+
+ /* MSB of each alarm register is an enable bit */
+ tm.tm_sec = bcd2bin(regs[ISL1219_REG_SCT - ISL1219_REG_SCT] & 0x7f);
+ tm.tm_min = bcd2bin(regs[ISL1219_REG_MNT - ISL1219_REG_SCT] & 0x7f);
+ tm.tm_hour = bcd2bin(regs[ISL1219_REG_HRT - ISL1219_REG_SCT] & 0x3f);
+ tm.tm_mday = bcd2bin(regs[ISL1219_REG_DTT - ISL1219_REG_SCT] & 0x3f);
+ tm.tm_mon =
+ bcd2bin(regs[ISL1219_REG_MOT - ISL1219_REG_SCT] & 0x1f) - 1;
+ tm.tm_year = bcd2bin(regs
[PATCH v4 3/5] rtc: isl1208: Add "evdet" interrupt source for isl1219.
From: Denis Osterland
Add support for "evdet" named interrupt source.
The check if i2c client irq matches evdet irq is needed
for the case that there is only one interrupt named "evdet".
In this case i2c client code handles this like an unnamed
interrupt souce and assigns the value.
Signed-off-by: Denis Osterland
Reviewed-by: Michael Grzeschik
---
drivers/rtc/rtc-isl1208.c | 46 +--
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index bb189fe6744a..bbe08c1ab9f3 100644
--- a/drivers/rtc/rtc-isl1208.c
+++ b/drivers/rtc/rtc-isl1208.c
@@ -15,6 +15,7 @@
#include
#include
#include "rtc-core.h"
+#include
/* Register map */
/* rtc section */
@@ -725,11 +726,30 @@ static const struct attribute_group
isl1219_rtc_sysfs_files = {
.attrs = isl1219_rtc_attrs,
};
+static int isl1208_setup_irq(struct i2c_client *client, int irq)
+{
+ int rc = devm_request_threaded_irq(&client->dev, irq, NULL,
+ isl1208_rtc_interrupt,
+ IRQF_SHARED | IRQF_ONESHOT,
+ isl1208_driver.driver.name,
+ client);
+ if (!rc) {
+ device_init_wakeup(&client->dev, 1);
+ enable_irq_wake(irq);
+ } else {
+ dev_err(&client->dev,
+ "Unable to request irq %d, no alarm support\n",
+ irq);
+ }
+ return rc;
+}
+
static int
isl1208_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
int rc = 0;
struct rtc_device *rtc;
+ int evdet_irq = -1;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
@@ -766,28 +786,22 @@ isl1208_probe(struct i2c_client *client, const struct
i2c_device_id *id)
rc = rtc_add_group(rtc, &isl1219_rtc_sysfs_files);
if (rc)
return rc;
+ evdet_irq = of_irq_get_byname(client->dev.of_node, "evdet");
}
rc = sysfs_create_group(&client->dev.kobj, &isl1208_rtc_sysfs_files);
if (rc)
return rc;
- if (client->irq > 0) {
- rc = devm_request_threaded_irq(&client->dev, client->irq, NULL,
- isl1208_rtc_interrupt,
- IRQF_SHARED | IRQF_ONESHOT,
- isl1208_driver.driver.name,
- client);
- if (!rc) {
- device_init_wakeup(&client->dev, 1);
- enable_irq_wake(client->irq);
- } else {
- dev_err(&client->dev,
- "Unable to request irq %d, no alarm support\n",
- client->irq);
- client->irq = 0;
- }
- }
+ if (client->irq > 0)
+ rc = isl1208_setup_irq(client, client->irq);
+ if (rc)
+ return rc;
+
+ if (evdet_irq > 0 && evdet_irq != client->irq)
+ rc = isl1208_setup_irq(client, evdet_irq);
+ if (rc)
+ return rc;
return rtc_register_device(rtc);
}
--
2.18.0
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315
___
Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung
und/oder Publikation dieser E-Mail ist strengstens untersagt.
The contents of the above mentioned e-mail is not legally binding. This e-mail
contains confidential and/or legally protected information. Please inform us if
you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction,
disclosure, alteration, distribution and/or publication of this e-mail is
strictly prohibited.
Re: [PATCH 3/3] clk: meson-g12a: Add EE Clock controller driver
On Tue, 2018-07-10 at 09:21 +0800, Yixun Lan wrote:
> HI Martin
>
>
> On 07/10/18 05:53, Martin Blumenstingl wrote:
> > On Mon, Jul 9, 2018 at 1:14 PM Jian Hu wrote:
> > >
> > > Add a Clock driver for the Everyting-Else part
> > > of the Amlogic Meson-G12A SoC.
> > >
> > > Signed-off-by: Jian Hu
This patch does not apply against g...@github.com:BayLibre/clk-meson.git
Please rebase on top of the "next/drivers" branch.
Also please review the Kconfig part as changes have happened there.
> > > ---
> > > drivers/clk/meson/Kconfig | 10 +
> > > drivers/clk/meson/Makefile | 1 +
> > > drivers/clk/meson/g12a.c | 992
> > > +
> > > drivers/clk/meson/g12a.h | 123 ++
> > > 4 files changed, 1126 insertions(+)
> > > create mode 100644 drivers/clk/meson/g12a.c
> > > create mode 100644 drivers/clk/meson/g12a.h
> > >
> > > diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> > > index d5cbec5..94a82f73 100644
> > > --- a/drivers/clk/meson/Kconfig
> > > +++ b/drivers/clk/meson/Kconfig
> > > @@ -36,3 +36,13 @@ config COMMON_CLK_AXG
> > > help
> > > Support for the clock controller on AmLogic A113D devices, aka
> > > axg.
> > > Say Y if you want peripherals and CPU frequency scaling to work.
> > > +
> > > +config COMMON_CLK_G12A
> > > + bool
> > > + depends on COMMON_CLK_AMLOGIC
> > > + select RESET_CONTROLLER
> > > + select COMMON_CLK_REGMAP_MESON
> > > + select MFD_SYSCON
> > > + help
> > > + Support for the clock controller on AmLogic U400 devices, aka
> > > g12a.
I suppose U400 is the designation of the ref design board, not the SoC, right ?
If this is case, please provide the SoC reference instead.
> > > + Say Y if you want peripherals and CPU frequency scaling to work.
> > > diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> > > index fa6d1e3..45d107c 100644
> > > --- a/drivers/clk/meson/Makefile
> > > +++ b/drivers/clk/meson/Makefile
> > > @@ -6,4 +6,5 @@ obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o
> > > clk-audio-divider.o
> > > obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
> > > obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o meson-aoclk.o gxbb-aoclk.o
> > > gxbb-aoclk-32k.o
> > > obj-$(CONFIG_COMMON_CLK_AXG)+= axg.o meson-aoclk.o axg-aoclk.o
> > > +obj-$(CONFIG_COMMON_CLK_G12A) += g12a.o
> > > obj-$(CONFIG_COMMON_CLK_REGMAP_MESON) += clk-regmap.o
> > > diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
> > > new file mode 100644
> > > index 000..3675697
> > > --- /dev/null
> > > +++ b/drivers/clk/meson/g12a.c
> > > @@ -0,0 +1,992 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * AmLogic Meson-G12A Clock Controller Driver
I thought you guys stopped writing amlogic with this camel case.
Please be consistent about it
> > > + *
> > > + * Copyright (c) 2016 Baylibre SAS.
> > > + * Author: Michael Turquette
> > > + *
> > > + * Copyright (c) 2018 Amlogic, inc.
> > > + * Author: Jian Hu
> > > + * Author: Qiufang Dai
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "clkc.h"
> > > +#include "g12a.h"
> > > +
> > > +static DEFINE_SPINLOCK(meson_clk_lock);
> > > +
> > > +static struct clk_regmap g12a_fixed_pll = {
> > > + .data = &(struct meson_clk_pll_data){
> > > + .m = {
> > > + .reg_off = HHI_FIX_PLL_CNTL0,
> > > + .shift = 0,
> > > + .width = 8,
> > > + },
> > > + .n = {
> > > + .reg_off = HHI_FIX_PLL_CNTL0,
> > > + .shift = 10,
> > > + .width = 5,
> > > + },
> > > + .od = {
> > > + .reg_off = HHI_FIX_PLL_CNTL0,
> > > + .shift = 16,
> > > + .width = 2,
> > > + },
> > > + .frac = {
> > > + .reg_off = HHI_FIX_PLL_CNTL1,
> > > + .shift = 0,
> > > + .width = 19,
> > > + },
> > > + .l = {
> > > + .reg_off = HHI_FIX_PLL_CNTL0,
> > > + .shift = 31,
> > > + .width = 1,
> > > + },
> > > + .rst = {
> > > + .reg_off = HHI_FIX_PLL_CNTL0,
> > > + .shift = 29,
> > > + .width = 1,
> > > + },
> > > + },
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "fixed_pll",
> > > + .ops = &meson_clk_pll_ro_ops,
> > > + .parent_names = (const char *[]){ "xtal" },
> > > + .num_parents = 1,
> > > + },
> > > +};
> > > +
> > > +st
[PATCH] KVM: Add coalesced PIO support
Windows I/O, such as the real-time clock. The address register (port
0x70 in the RTC case) can use coalesced I/O, cutting the number of
userspace exits by half when reading or writing the RTC.
Guest access rtc like this: write register index to 0x70, then write or
read data from 0x71. writing 0x70 port is just as index and do nothing
else. So we can use coalesced mmio to handle this scene to reduce VM-EXIT
time.
In our environment, 12 windows guests running on a Skylake server:
Before patch:
IO Port Access Samples Samples% Time%Avg time
0x70:POUT2067546.04%92.72% 67.15us ( +- 7.93% )
After patch:
IO Port Access Samples Samples% Time%Avg time
0x70:POUT1750945.42%42.08% 6.37us ( +- 20.37% )
Thanks to Peng Hao's initial patch.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Eduardo Habkost
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/00-INDEX | 2 ++
Documentation/virtual/kvm/api.txt | 7 +++
Documentation/virtual/kvm/coalesced-io.txt | 17 +
include/uapi/linux/kvm.h | 4 ++--
virt/kvm/coalesced_mmio.c | 16 +---
virt/kvm/kvm_main.c| 2 ++
6 files changed, 43 insertions(+), 5 deletions(-)
create mode 100644 Documentation/virtual/kvm/coalesced-io.txt
diff --git a/Documentation/virtual/kvm/00-INDEX
b/Documentation/virtual/kvm/00-INDEX
index 3492458..a4a09a0 100644
--- a/Documentation/virtual/kvm/00-INDEX
+++ b/Documentation/virtual/kvm/00-INDEX
@@ -9,6 +9,8 @@ arm
- internal ABI between the kernel and HYP (for arm/arm64)
cpuid.txt
- KVM-specific cpuid leaves (x86).
+coalesced-io.txt
+ - Coalesced MMIO and coalesced PIO.
devices/
- KVM_CAP_DEVICE_CTRL userspace API.
halt-polling.txt
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index d10944e..4190796 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4618,3 +4618,10 @@ This capability indicates that KVM supports
paravirtualized Hyper-V TLB Flush
hypercalls:
HvFlushVirtualAddressSpace, HvFlushVirtualAddressSpaceEx,
HvFlushVirtualAddressList, HvFlushVirtualAddressListEx.
+
+8.19 KVM_CAP_COALESCED_PIO
+
+Architectures: x86, s390, ppc, arm64
+
+This Capability indicates that kvm supports writing to a coalesced-pio region
+is not reported to userspace until the next non-coalesced pio is issued.
diff --git a/Documentation/virtual/kvm/coalesced-io.txt
b/Documentation/virtual/kvm/coalesced-io.txt
new file mode 100644
index 000..5233559
--- /dev/null
+++ b/Documentation/virtual/kvm/coalesced-io.txt
@@ -0,0 +1,17 @@
+
+Coalesced MMIO and coalesced PIO can be used to optimize writes to
+simple device registers. Writes to a coalesced-I/O region are not
+reported to userspace until the next non-coalesced I/O is issued,
+in a similar fashion to write combining hardware. In KVM, coalesced
+writes are handled in the kernel without exits to userspace, and
+are thus several times faster.
+
+Examples of devices that can benefit from coalesced I/O include:
+
+- devices whose memory is accessed with many consecutive writes, for
+ example the EGA/VGA video RAM.
+
+- windows I/O, such as the real-time clock. The address register (port
+ 0x70 in the RTC case) can use coalesced I/O, cutting the number of
+ userspace exits by half when reading or writing the RTC.
+
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b6270a3..53370fc 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -420,13 +420,13 @@ struct kvm_run {
struct kvm_coalesced_mmio_zone {
__u64 addr;
__u32 size;
- __u32 pad;
+ __u32 pio;
};
struct kvm_coalesced_mmio {
__u64 phys_addr;
__u32 len;
- __u32 pad;
+ __u32 pio;
__u8 data[8];
};
diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
index 9e65feb..fc66a834 100644
--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -83,6 +83,7 @@ static int coalesced_mmio_write(struct kvm_vcpu *vcpu,
ring->coalesced_mmio[ring->last].phys_addr = addr;
ring->coalesced_mmio[ring->last].len = len;
memcpy(ring->coalesced_mmio[ring->last].data, val, len);
+ ring->coalesced_mmio[ring->last].pio = dev->zone.pio;
smp_wmb();
ring->last = (ring->last + 1) % KVM_COALESCED_MMIO_MAX;
spin_unlock(&dev->kvm->ring_lock);
@@ -149,8 +150,12 @@ int kvm_vm_ioctl_register_coalesced_mmio(struct kvm *kvm,
dev->zone = *zone;
mutex_lock(&kvm->slots_lock);
- ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, zone->addr,
- zone->size, &dev->dev);
+ if (zone->pio)
+ ret = kvm_io_bus_register_dev(kvm, KVM_PIO_BUS, zone->addr,
+ zone->size, &dev->dev);
+ else
+ ret =
[PATCH v4 1/5] rtc: sysfs: facilitate attribute add to rtc device
From: Denis Osterland
This patches addresses following problem:
rtc_allocate_device
devm_device_add_group <-- kernel oops / null pointer, because
sysfs entry does not yet exist
rtc_register_device
rc = devm_device_add_group
if (rc)
return rc; <-- forbidden to return error code
after device register
In case groups were not yet registered (kobj.state_in_sysfs == 0)
rtc_add_group just addes given group to dev.groups,
otherwise it uses devm_device_add_group.
Signed-off-by: Denis Osterland
---
drivers/rtc/rtc-core.h | 6 ++
drivers/rtc/rtc-sysfs.c | 39 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/rtc/rtc-core.h b/drivers/rtc/rtc-core.h
index 0abf98983e13..81d1c3ce7a96 100644
--- a/drivers/rtc/rtc-core.h
+++ b/drivers/rtc/rtc-core.h
@@ -40,9 +40,15 @@ static inline void rtc_proc_del_device(struct rtc_device
*rtc)
#ifdef CONFIG_RTC_INTF_SYSFS
const struct attribute_group **rtc_get_dev_attribute_groups(void);
+int rtc_add_group(struct rtc_device *rtc, const struct attribute_group *grp);
#else
static inline const struct attribute_group **rtc_get_dev_attribute_groups(void)
{
return NULL;
}
+static inline
+int rtc_add_group(struct rtc_device *rtc, const struct attribute_group *grp)
+{
+ return 0;
+}
#endif
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index 454da38c6012..9a177b8f761b 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -317,3 +317,42 @@ const struct attribute_group
**rtc_get_dev_attribute_groups(void)
{
return rtc_attr_groups;
}
+
+static size_t rtc_group_count(struct rtc_device *rtc)
+{
+ const struct attribute_group **groups = rtc->dev.groups;
+ size_t cnt = 0;
+
+ if (groups)
+ for (; *groups; groups++)
+ cnt++;
+
+ return cnt;
+}
+
+static inline int
+__rtc_add_group(struct rtc_device *rtc, const struct attribute_group *grp)
+{
+ size_t cnt = rtc_group_count(rtc);
+ const struct attribute_group **groups, **old;
+
+ groups = devm_kzalloc(&rtc->dev, (cnt+2)*sizeof(*groups), GFP_KERNEL);
+ if (IS_ERR_OR_NULL(groups))
+ return PTR_ERR(groups);
+ memcpy(groups, rtc->dev.groups, cnt*sizeof(*groups));
+ groups[cnt] = grp;
+
+ old = rtc->dev.groups;
+ rtc->dev.groups = groups;
+ if (old != rtc_attr_groups)
+ devm_kfree(&rtc->dev, old);
+
+ return 0;
+}
+
+int rtc_add_group(struct rtc_device *rtc, const struct attribute_group *grp)
+{
+ return rtc->dev.kobj.state_in_sysfs ?
+ devm_device_add_group(&rtc->dev, grp) :
+ __rtc_add_group(rtc, grp);
+}
--
2.18.0
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315
___
Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung
und/oder Publikation dieser E-Mail ist strengstens untersagt.
The contents of the above mentioned e-mail is not legally binding. This e-mail
contains confidential and/or legally protected information. Please inform us if
you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction,
disclosure, alteration, distribution and/or publication of this e-mail is
strictly prohibited.
[PATCH v4 5/5] rtc: isl1219: add device tree docu
From: Denis Osterland
The devicetree documentation for the ISL1219 device tree
binding is added with an short example. It is not a trivial
device, because it supports two interrupt souces.
Signed-off-by: Denis Osterland
---
.../devicetree/bindings/rtc/isil,isl1219.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl1219.txt
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1219.txt
b/Documentation/devicetree/bindings/rtc/isil,isl1219.txt
new file mode 100644
index ..f26f1e9d4bde
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl1219.txt
@@ -0,0 +1,29 @@
+Intersil ISL1219 I2C RTC/Alarm chip with event in
+
+ISL1219 has additional pins EVIN and #EVDET for tamper detection.
+
+Required properties supported by the device:
+
+ - "compatible": must be "isil,isl1219"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+ - "interrupt-names": list which may contains "irq" and "evdet"
+ - "interrupt-parent", "interrupts", "interrupts-extended":
+ for passing the interrupt line of the SoC connected to #IRQ pin
+ and #EVDET pin of the RTC chip.
+ - "isil,ev-evienb": if present bit can be set to disable event input pull-up
+
+
+Example isl1219 node with #IRQ pin connected to SoC gpio1 pin12
+ and #EVDET pin connected to SoC gpio2 pin 24:
+
+ isl1219: rtc@68 {
+ compatible = "isil,isl1219";
+ reg = <0x68>;
+ interrupt-names = "irq", "evdet";
+ interrupts-extended = <&gpio1 12 IRQ_TYPE_EDGE_FALLING>,
+ <&gpio2 24 IRQ_TYPE_EDGE_FALLING>;
+ };
+
--
2.18.0
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315
___
Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung
und/oder Publikation dieser E-Mail ist strengstens untersagt.
The contents of the above mentioned e-mail is not legally binding. This e-mail
contains confidential and/or legally protected information. Please inform us if
you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction,
disclosure, alteration, distribution and/or publication of this e-mail is
strictly prohibited.
Re: [PATCH v4] driver core: add a debugfs entry to show deferred devices
Hi,
On Sun, Jul 08, 2018 at 03:34:59PM +0200, Javier Martinez Canillas wrote:
> With Device Trees (DT), the dependencies of the devices are defined in the
> DT, then the drivers parse that information to lookup the needed resources
> that have as dependencies.
>
> Since drivers and devices are registered in a non-deterministic way, it is
> possible that a device that is a dependency has not been registered yet by
> the time that is looked up.
>
> In this case the driver that requires this dependency cannot probe and has
> to defer it. So the driver core adds it to a list of deferred devices that
> is iterated again every time that a new driver is probed successfully.
>
> For debugging purposes it may be useful to know what are the devices whose
> probe function was deferred. Add a debugfs entry showing that information.
>
> $ cat /sys/kernel/debug/devices_deferred
> 4807.i2c:twl@48:bci
> musb-hdrc.0.auto
> omapdrm.0
>
> This information could be obtained partially by enabling debugging, but it
> means that the kernel log has to be parsed and the probe deferral balanced
> with the successes. This can be error probe and has to be done in a ad-hoc
> manner by everyone who needs to debug these kind of issues.
>
> Since the information is already known by the kernel, just show it to make
> it easier to debug.
>
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Andy Shevchenko
> Reviewed-by: Mark Brown
Reviewed-by: Sebastian Reichel
-- Sebastian
> ---
>
> Changes since RFC v1:
> - Remove unneeded ret variable from deferred_devs_show()
>
> Changes since RFC v2:
> - Use DEFINE_SHOW_ATTRIBUTE() macro.
> - Don't propagate debugfs_create_file() error.
> - Remove IS_ENABLED(CONFIG_DEBUG_FS) guards.
> - Drop RFC prefix.
>
> Changes since v1:
> - Better explain in the commit message why this patch is useful.
> - Rename deferred_devices entry to devices_deferred.
> - Add an exit function and remove the debugfs entry.
>
> Changes since v2:
> - Add Andy Shevchenko and Mark Brown Reviewed-by tag.
> - Rebase on top of Greg's driver-core-next branch.
>
> Changes since v3:
> - Fixed a build warning caused by a wrong conflict resolution on v3.
>
>
> drivers/base/dd.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 6ea9c5cece7..e85705e8440 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -16,6 +16,7 @@
> * Copyright (c) 2007-2009 Novell Inc.
> */
>
> +#include
> #include
> #include
> #include
> @@ -53,6 +54,7 @@ static DEFINE_MUTEX(deferred_probe_mutex);
> static LIST_HEAD(deferred_probe_pending_list);
> static LIST_HEAD(deferred_probe_active_list);
> static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
> +static struct dentry *deferred_devices;
>
> /*
> * In some cases, like suspend to RAM or hibernation, It might be reasonable
> @@ -199,6 +201,24 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +/*
> + * deferred_devs_show() - Show the devices in the deferred probe pending
> list.
> + */
> +static int deferred_devs_show(struct seq_file *s, void *data)
> +{
> + struct device_private *curr;
> +
> + mutex_lock(&deferred_probe_mutex);
> +
> + list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
> + seq_printf(s, "%s\n", dev_name(curr->device));
> +
> + mutex_unlock(&deferred_probe_mutex);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(deferred_devs);
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> @@ -208,6 +228,9 @@ void device_unblock_probing(void)
> */
> static int deferred_probe_initcall(void)
> {
> + deferred_devices = debugfs_create_file("devices_deferred", 0444, NULL,
> +NULL, &deferred_devs_fops);
> +
> driver_deferred_probe_enable = true;
> driver_deferred_probe_trigger();
> /* Sort as many dependencies as possible before exiting initcalls */
> @@ -216,6 +239,12 @@ static int deferred_probe_initcall(void)
> }
> late_initcall(deferred_probe_initcall);
>
> +static void __exit deferred_probe_exit(void)
> +{
> + debugfs_remove_recursive(deferred_devices);
> +}
> +__exitcall(deferred_probe_exit);
> +
> /**
> * device_is_bound() - Check if device is bound to a driver
> * @dev: device to check
> --
> 2.17.1
>
signature.asc
Description: PGP signature
[PATCH] doc: Replace smp_cond_acquire() with smp_cond_load_acquire()
Amend commit 1f03e8d2919270 ("locking/barriers: Replace smp_cond_acquire()
with smp_cond_load_acquire()") by updating the documentation accordingly.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Akira Yokosawa
Cc: Daniel Lustig
Cc: Jonathan Corbet
---
Documentation/memory-barriers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 0d8d7ef131e9a..987a4e6cc0cd8 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -471,8 +471,8 @@ And a couple of implicit varieties:
operations after the ACQUIRE operation will appear to happen after the
ACQUIRE operation with respect to the other components of the system.
ACQUIRE operations include LOCK operations and both smp_load_acquire()
- and smp_cond_acquire() operations. The later builds the necessary ACQUIRE
- semantics from relying on a control dependency and smp_rmb().
+ and smp_cond_load_acquire() operations. The later builds the necessary
+ ACQUIRE semantics from relying on a control dependency and smp_rmb().
Memory operations that occur before an ACQUIRE operation may appear to
happen after it completes.
--
2.7.4
