* Re: [PATCH] mt76: mt7615: remove rx_mask in mt7615_eeprom_parse_hw_cap
From: kbuild test robot @ 2020-02-14 20:38 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <496a58e997ab842d912c5b5352fa6593dc7cc00f.1581455625.git.lorenzo@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4710 bytes --]
Hi Lorenzo,
I love your patch! Yet something to improve:
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on wireless-drivers/master v5.6-rc1 next-20200214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Lorenzo-Bianconi/mt76-mt7615-remove-rx_mask-in-mt7615_eeprom_parse_hw_cap/20200215-021915
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.5.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.5.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c: In function 'mt7615_eeprom_parse_hw_cap':
>> drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c:123:39: error: 'rx_mask' undeclared (first use in this function); did you mean 'tx_mask'?
dev->mt76.chainmask = tx_mask << 8 | rx_mask;
^~~~~~~
tx_mask
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c:123:39: note: each undeclared identifier is reported only once for each function it appears in
vim +123 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
f9461a687928df2 Lorenzo Bianconi 2019-05-17 92
c988a77f1de523e Lorenzo Bianconi 2019-05-17 93 static void mt7615_eeprom_parse_hw_cap(struct mt7615_dev *dev)
c988a77f1de523e Lorenzo Bianconi 2019-05-17 94 {
d08f3010f4a32ee Lorenzo Bianconi 2020-02-07 95 u8 *eeprom = dev->mt76.eeprom.data;
30ec8d836cb0539 Lorenzo Bianconi 2020-02-11 96 u8 tx_mask, max_nss;
d08f3010f4a32ee Lorenzo Bianconi 2020-02-07 97 u32 val;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 98
c988a77f1de523e Lorenzo Bianconi 2019-05-17 99 val = FIELD_GET(MT_EE_NIC_WIFI_CONF_BAND_SEL,
c988a77f1de523e Lorenzo Bianconi 2019-05-17 100 eeprom[MT_EE_WIFI_CONF]);
c988a77f1de523e Lorenzo Bianconi 2019-05-17 101 switch (val) {
c988a77f1de523e Lorenzo Bianconi 2019-05-17 102 case MT_EE_5GHZ:
c988a77f1de523e Lorenzo Bianconi 2019-05-17 103 dev->mt76.cap.has_5ghz = true;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 104 break;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 105 case MT_EE_2GHZ:
c988a77f1de523e Lorenzo Bianconi 2019-05-17 106 dev->mt76.cap.has_2ghz = true;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 107 break;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 108 default:
c988a77f1de523e Lorenzo Bianconi 2019-05-17 109 dev->mt76.cap.has_2ghz = true;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 110 dev->mt76.cap.has_5ghz = true;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 111 break;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 112 }
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 113
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 114 /* read tx-rx mask from eeprom */
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 115 val = mt76_rr(dev, MT_TOP_STRAP_STA);
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 116 max_nss = val & MT_TOP_3NSS ? 3 : 4;
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 117
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 118 tx_mask = FIELD_GET(MT_EE_NIC_CONF_TX_MASK,
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 119 eeprom[MT_EE_NIC_CONF_0]);
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 120 if (!tx_mask || tx_mask > max_nss)
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 121 tx_mask = max_nss;
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 122
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 @123 dev->mt76.chainmask = tx_mask << 8 | rx_mask;
acf5457fd99db6c Lorenzo Bianconi 2019-11-14 124 dev->mt76.antenna_mask = BIT(tx_mask) - 1;
c988a77f1de523e Lorenzo Bianconi 2019-05-17 125 }
c988a77f1de523e Lorenzo Bianconi 2019-05-17 126
:::::: The code at line 123 was first introduced by commit
:::::: acf5457fd99db6c9a42ef280494dfee949ee1e09 mt76: mt7615: read {tx,rx} mask from eeprom
:::::: TO: Lorenzo Bianconi <lorenzo@kernel.org>
:::::: CC: Felix Fietkau <nbd@nbd.name>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 56548 bytes --]
^ permalink raw reply
* Re: [PATCH v2 9/9] perf,tracing: Allow function tracing when !RCU
From: Kim Phillips @ 2020-02-14 20:38 UTC (permalink / raw)
To: Peter Zijlstra, linux-kernel, linux-arch, rostedt
Cc: mingo, joel, gregkh, gustavo, tglx, paulmck, josh,
mathieu.desnoyers, jiangshanlai
In-Reply-To: <20200212210750.312024711@infradead.org>
On 2/12/20 3:01 PM, Peter Zijlstra wrote:
> Since perf is now able to deal with !rcu_is_watching() contexts,
> remove the restraint.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> kernel/trace/trace_event_perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/kernel/trace/trace_event_perf.c
> +++ b/kernel/trace/trace_event_perf.c
> @@ -477,7 +477,7 @@ static int perf_ftrace_function_register
> {
> struct ftrace_ops *ops = &event->ftrace_ops;
>
> - ops->flags = FTRACE_OPS_FL_RCU;
> + ops->flags = 0;
> ops->func = perf_ftrace_function_call;
> ops->private = (void *)(unsigned long)nr_cpu_ids;
If this is the last user of the flag, should all remaining
FTRACE_OPS_FL_RCU references be removed, too?
Thanks,
Kim
^ permalink raw reply
* Re: [PATCH] pinctrl: ingenic: Make unreachable path more robust
From: Josh Poimboeuf @ 2020-02-14 20:37 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, linux-gpio, linux-kernel, Peter Zijlstra,
Randy Dunlap
In-Reply-To: <1581706938.3.5@crapouillou.net>
On Fri, Feb 14, 2020 at 04:02:18PM -0300, Paul Cercueil wrote:
> Hi Josh,
>
>
> Le ven., févr. 14, 2020 at 10:37, Josh Poimboeuf <jpoimboe@redhat.com> a
> écrit :
> > In the second loop of ingenic_pinconf_set(), it annotates the switch
> > default case as unreachable(). The annotation is technically correct,
> > because that same case would have resulted in an early return in the
> > previous loop.
> >
> > However, if a bug were to get introduced later, for example if an
> > additional case were added to the first loop without adjusting the
> > second loop, it would result in nasty undefined behavior: most likely
> > the function's generated code would fall through to the next function.
> >
> > Another issue is that, while objtool normally understands unreachable()
> > annotations, there's one special case where it doesn't: when the
> > annotation occurs immediately after a 'ret' instruction. That happens
> > to be the case here because unreachable() is immediately before the
> > return.
> >
> > So change the unreachable() to BUG() so that the unreachable code, if
> > ever executed, would panic instead of introducing undefined behavior.
> > This also makes objtool happy.
>
> I don't like the idea that you change this driver's code just to work around
> a bug in objtool, and I don't like the idea of working around a future bug
> that shouldn't be introduced in the first place.
It's not an objtool bug. It's a byproduct of the fact that GCC's
undefined behavior is inscrutable, and there's no way to determine that
it actually *wants* to jump to a random function.
And anyway, regardless of objtool, the patch is meant to make the code
more robust.
Do you not agree that BUG (defined behavior) is more robust than
unreachable (undefined behavior)?
--
Josh
^ permalink raw reply
* Re: [Virtio-fs] [PATCH v2 0/2] virtiofsd: Fix xattr and ACL
From: Vivek Goyal @ 2020-02-14 20:37 UTC (permalink / raw)
To: misono.tomohiro@fujitsu.com; +Cc: virtio-fs@redhat.com
In-Reply-To: <OSBPR01MB458283800922F1C74C094ABDE5070@OSBPR01MB4582.jpnprd01.prod.outlook.com>
On Fri, Jan 31, 2020 at 02:06:51AM +0000, misono.tomohiro@fujitsu.com wrote:
> > On Tue, Jan 28, 2020 at 07:18:17PM +0900, Misono Tomohiro wrote:
> > > Hi,
> > >
> > > This is a second version of xattr fix for virtiofsd.
> > > I included ACL fix (which introduces new option posix_acl) in this
> > > version too as ACL mostly depends on xattr.
> > >
> > > I run xfstests with XFS backend using "-o xattr -o posix_acl" option
> > > and only new failure is generic/375 which checks if sgid bit is
> > > cleared after setfacl. I'll try to investigate it.
> > >
> > > change in v1 -> v2
> > > - rebased to current dev branch
> > >
> > > - Always chdir for xattr (1st patch)
> > > In v1, I keep current implementation for regular file/dir since it
> > > show better performance in my environment. But I notice opening file
> > > for xattr causes seek sanity test fails (xfstest generic/285, 436).
> > >
> > > I'm not sure what is the fundamental problem here but I believe
> > > performance can be improved by introducing some caching mechanism
> > > in general.
> >
> > Hi Misono,
> >
> > How much is performance degradation due to fchdir(). If it is significant, then I will be inclined to keep original code for dir/file
> > till some other mechanism is introduced to offset the perofrmance loss.
>
> Please refer this replay: https://www.redhat.com/archives/virtio-fs/2020-January/msg00063.html
As per your email, regression due to fchdir() seems to be in the range of
5% to 10%. It is not trivial, IMO. May be its a good idea to keep original
logic and use fchdir() only when need be.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH] net: phy: restore mdio regs in the iproc mdio driver
From: Florian Fainelli @ 2020-02-14 20:37 UTC (permalink / raw)
To: Andrew Lunn, Scott Branden
Cc: Ray Jui, Arun Parameswaran, Russell King, linux-kernel,
bcm-kernel-feedback-list, netdev, David S . Miller,
linux-arm-kernel, Heiner Kallweit
In-Reply-To: <20200214203310.GQ31084@lunn.ch>
On 2/14/20 12:33 PM, Andrew Lunn wrote:
> On Fri, Feb 14, 2020 at 11:48:58AM -0800, Scott Branden wrote:
>> From: Arun Parameswaran <arun.parameswaran@broadcom.com>
>>
>> The mii management register in iproc mdio block
>> does not have a reention register so it is lost on suspend.
>
> reention?
Retention presumably.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] net: phy: restore mdio regs in the iproc mdio driver
From: Florian Fainelli @ 2020-02-14 20:37 UTC (permalink / raw)
To: Andrew Lunn, Scott Branden
Cc: Heiner Kallweit, Ray Jui, Arun Parameswaran, Russell King,
linux-kernel, bcm-kernel-feedback-list, netdev, David S . Miller,
linux-arm-kernel
In-Reply-To: <20200214203310.GQ31084@lunn.ch>
On 2/14/20 12:33 PM, Andrew Lunn wrote:
> On Fri, Feb 14, 2020 at 11:48:58AM -0800, Scott Branden wrote:
>> From: Arun Parameswaran <arun.parameswaran@broadcom.com>
>>
>> The mii management register in iproc mdio block
>> does not have a reention register so it is lost on suspend.
>
> reention?
Retention presumably.
--
Florian
^ permalink raw reply
* Re: [PATCH 10/12] mm: x86: Invoke hypercall when page encryption status is changed
From: Ashish Kalra @ 2020-02-14 20:36 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Radim Krcmar, Joerg Roedel, Borislav Petkov, Tom Lendacky,
David Rientjes, X86 ML, kvm list, LKML, brijesh.singh
In-Reply-To: <CALCETrX=ycjSuf_N_ff-VQtqq2_RoawuAqdkM+bCPn_2_swkjg@mail.gmail.com>
On Fri, Feb 14, 2020 at 10:56:53AM -0800, Andy Lutomirski wrote:
> On Thu, Feb 13, 2020 at 2:28 PM Ashish Kalra <ashish.kalra@amd.com> wrote:
> >
> > On Wed, Feb 12, 2020 at 09:42:02PM -0800, Andy Lutomirski wrote:
> > >> On Wed, Feb 12, 2020 at 5:18 PM Ashish Kalra <Ashish.Kalra@amd.com> wrote:
> > >> >
> > >> > From: Brijesh Singh <brijesh.singh@amd.com>
> > > >
> > > > Invoke a hypercall when a memory region is changed from encrypted ->
> > > > decrypted and vice versa. Hypervisor need to know the page encryption
> > > > status during the guest migration.
> > >>
> > >> What happens if the guest memory status doesn't match what the
> > >> hypervisor thinks it is? What happens if the guest gets migrated
> > >> between the hypercall and the associated flushes?
> >
> > This is basically same as the dirty page tracking and logging being done
> > during Live Migration. As with dirty page tracking and logging we
> > maintain a page encryption bitmap in the kernel which keeps tracks of
> > guest's page encrypted/decrypted state changes and this bitmap is
> > sync'ed regularly from kernel to qemu and also during the live migration
> > process, therefore any dirty pages whose encryption status will change
> > during migration, should also have their page status updated when the
> > page encryption bitmap is sync'ed.
> >
> > Also i think that when the amount of dirty pages reach a low threshold,
> > QEMU stops the source VM and then transfers all the remaining dirty
> > pages, so at that point, there will also be a final sync of the page
> > encryption bitmap, there won't be any hypercalls after this as the
> > source VM has been stopped and the remaining VM state gets transferred.
>
> And have you ensured that, in the inevitable race when a guest gets
> migrated part way through an encryption state change, that no data
> corruption occurs?
We ensure that we send the page encryption state bitmap to the
destination VM at migration completion and when the remaining amount of
RAM/dirty pages are flushed. Also as the source VM is stopped before
this flush of remaining blocks occur, so any encryption state change
hypercalls would have been completed before that.
Thanks,
Ashish
^ permalink raw reply
* Re: [PATCH] x86/mce/amd: Fix kobject lifetime
From: Borislav Petkov @ 2020-02-14 20:36 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Greg KH, stable, X86 ML, Yazen Ghannam, LKML
In-Reply-To: <87a75kud8o.fsf@nanos.tec.linutronix.de>
On Fri, Feb 14, 2020 at 09:26:31PM +0100, Thomas Gleixner wrote:
> This once Cc'ed stable but lacked a Cc: stable tag in the changelog.
So that's the difference. Ok, I'm fine with that.
/me removes "suppresscc = bodycc" from his .gitconfig again.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: s390 depending on cc-options makes it difficult to configure
From: Jeremy Cline @ 2020-02-14 20:35 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Philipp Rudo, Michal Kubecek, Linux Kernel Mailing List,
Heiko Carstens, Vasily Gorbik, linux-s390
In-Reply-To: <CAK7LNATL3Oyn=FLKm0TcB9SkJLuCOWV06a_t-FRtFiFp9Vda1g@mail.gmail.com>
On Fri, Feb 14, 2020 at 12:31:05PM +0900, Masahiro Yamada wrote:
> Hi.
>
> On Tue, Feb 11, 2020 at 3:49 AM Philipp Rudo <prudo@linux.ibm.com> wrote:
> >
> > Hey Jeremy,
> > Hey Michal,
> >
> > sorry for the late response. The mail got lost in the pre-xmas rush...
> >
> > In my opinion the problem goes beyond s390 and the commit you mentioned. So I'm
> > also adding Masahiro as Kconfig maintainer and author of cc-option.
>
>
> I did not notice the former discussion.
> Thanks for CC'ing me.
>
>
>
>
> > On Wed, 11 Dec 2019 12:18:22 -0500
> > Jeremy Cline <jcline@redhat.com> wrote:
> >
> > > On Tue, Dec 10, 2019 at 10:01:08AM +0100, Michal Kubecek wrote:
> > > > On Mon, Dec 09, 2019 at 11:41:55AM -0500, Jeremy Cline wrote:
> > > > > Hi folks,
> > > > >
> > > > > Commit 5474080a3a0a ("s390/Kconfig: make use of 'depends on cc-option'")
> > > > > makes it difficult to produce an s390 configuration for Fedora and Red
> > > > > Hat kernels.
> > > > >
> > > > > The issue is I have the following configurations:
> > > > >
> > > > > CONFIG_MARCH_Z13=y
> > > > > CONFIG_TUNE_Z14=y
> > > > > # CONFIG_TUNE_DEFAULT is not set
> > > > >
> > > > > When the configuration is prepared on a non-s390x host without a
> > > > > compiler with -march=z* it changes CONFIG_TUNE_DEFAULT to y which, as
> > > > > far as I can tell, leads to a kernel tuned for z13 instead of z14.
> > > > > Fedora and Red Hat build processes produce complete configurations from
> > > > > snippets on any available host in the build infrastructure which very
> > > > > frequently is *not* s390.
> > > >
> > > > We have exactly the same problem. Our developers need to update config
> > > > files for different architectures and different kernel versions on their
> > > > machines which are usually x86_64 but that often produces different
> > > > configs than the real build environment.
> > > >
> > > > This is not an issue for upstream development as one usually updates
> > > > configs on the same system where the build takes place but it's a big
> > > > problem for distribution maintainers.
> >
> > If I recall correct the goal was to avoid trouble with clang, as it does not
> > support all processor types with -march. But yeah, in the original
> > consideration we only thought about upstream development and forgot the
> > distros.
> > > > > I did a quick search and couldn't find any other examples of Kconfigs
> > > > > depending on march or mtune compiler flags and it seems like it'd
> > > > > generally problematic for people preparing configurations.
> >
> > True, but not the whole story. Power and Arm64 use cc-option to check for
> > -mstack-protector*, which do not exist on s390. So you have the same problem
> > when you prepare a config for any of them on s390. Thus simply reverting the
> > commit you mentioned above does not solve the problem but merely hides one
> > symptom. Which also means that the original problem will return over and over
> > again in the future.
> >
> > An other reason why I don't think it makes sens to revert the commit is that it
> > would make cc-option as a whole useless. What's the benefit in having cc-option
> > when you are not allowed to use it? Or less provocative, in which use cases is
> > allowed to use cc-option?
>
>
> You are right.
> Reverting the particular s390 commit is not the solution.
>
>
> > > > There are more issues like this. In general, since 4.17 or 4.18, the
> > > > resulting config depends on both architecture and compiler version.
> > > > Earlier, you could simply run "ARCH=... make oldconfig" (or menuconfig)
> > > > to update configs for all architectures and distribution versions.
> > > > Today, you need to use the right compiler version (results with e.g.
> > > > 4.8, 7.4 and 9.2 differ) and architecture.
> > > >
> > >
> > > Yeah, that's also troublesome. This is by no means the first problem
> > > related to the environment at configuration time, but it the most
> > > bothersome to work around (at least for Fedora kernel configuration).
> > >
> > > > At the moment, I'm working around the issue by using chroot environments
> > > > with target distributions (e.g. openSUSE Tumbleweed) and set of cross
> > > > compilers for supported architectures but it's far from perfect and even
> > > > this way, there are problemantic points, e.g. BPFILTER_UMH which depends
> > > > on gcc being able to not only compile but also link.
> > > >
> > > > IMHO the key problem is that .config mixes configuration with
> > > > description of build environment. I have an idea of a solution which
> > > > would consist of
> > > >
> > > > - an option to extract "config" options which describe build
> > > > environment (i.e. their values are determined by running some
> > > > command, rather than reading from a file or asking user) into
> > > > a cache file
> > > > - an option telling "make *config" to use such cache file for these
> > > > environment "config" options instead of running the test scripts
> > > > (and probably issue an error if an environment option is missing)
> > > >
> > >
> > > I agree that the issue is mixing kernel configuration with build
> > > environment. I suppose a cache file would work, but it still sounds like
> > > a difficult process that is working around that fact that folks are
> > > coupling the configuration step with the build step.
> >
> > An other solution would be a "I know better" switch which simply disables
> > cc-option for that run. That would allow the use of cc-option for upstream
> > development and provide a simple way for distros to turn it off.
> >
> > > I would advocate that this patch be reverted and an effort made to not
> > > mix build environment checks into the configuration. I'm much happier
> > > for the build to fail because the configuration can't be satisfied by
> > > the environment than I am for the configuration to quietly change or for
> > > the tools to not allow me to make the configuration in the first place.
> > > Ideally the tools would warn the user if their environment won't build
> > > the configuration, but that's a nice-to-have.
> >
> > I too would prefer to have a warning instead of the config being silently
> > changed. But again, the problem goes beyond what was reported.
> >
> > @Masahiro: What do you think about it?
> >
> > Thanks
> > Philipp
> >
>
>
> The problem for Jeremy and Michal is,
> it is difficult to get a full-feature cross-compiler
> for every arch.
>
Indeed.
> One idea to workaround this is
> to use a fake script that accepts any flag,
> and use it as $(CC) in Kconfig.
>
> RFC patch is attached.
>
> This is not a perfect solution, of course.
>
The attached patch doesn't looks like it'd work for what we need,
although I wonder if it's easier to just check when cc-options is
defined for an environment variable or something and always return y
instead of calling out to $(CC) at all. Comes to the same thing, I
suppose.
>
> Evaluating the compiler in the Kconfig stage
> conceptually has a conflict with the workflow
> of distro maintainers.
>
> I think the only way to solve it completely is,
> ultimately, go back to pre 4.18 situation.
> But, I am not sure if upstream people want to do it.
> At least, Linus was happy to do compiler-tests
> in Kconfig.
>
> I already got several criticism about the
> new feature in Kconfig because it broke the
> workflow of distro maintainers. Sorry about that.
>
No worries, it's a tough balancing act between upstream users and
distros. It's not caused me *that* much bother.
>
> The idea from Michal, separation of the build environment
> description, would work too.
> IIRC, the crosstool-ng project generates some
> Kconfig files based on the environment.
> In hindsight, Kconfig did not need to have cc-option
> but it was how I implemented. I just thought it would be cleaner to
> put cc-option and the CONFIG option depending on it very close.
>
> Anyway, comments to the attachment are appreciated.
>
I believe it would solve our problem so from that perspective, it looks
good to me.
Thanks,
Jeremy
^ permalink raw reply
* Re: [PATCH 02/13] fixup! KVM: selftests: Add support for vcpu_args_set to aarch64 and s390x
From: Christian Borntraeger @ 2020-02-14 20:35 UTC (permalink / raw)
To: Andrew Jones, kvm; +Cc: pbonzini, bgardon, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-3-drjones@redhat.com>
On 14.02.20 15:59, Andrew Jones wrote:
> [Fixed array index (num => i) and made some style changes.]
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> .../selftests/kvm/lib/aarch64/processor.c | 24 ++++---------------
subject says s390, the patch not.
^ permalink raw reply
* Re: [PATCH 0/7] Split fsverity-utils into a shared library
From: Eric Biggers @ 2020-02-14 20:35 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-fscrypt, kernel-team, Jes Sorensen
In-Reply-To: <c39f57d5-c9a4-5fbb-3ce3-cd21e90ef921@gmail.com>
Hi Jes,
On Tue, Feb 11, 2020 at 06:35:45PM -0500, Jes Sorensen wrote:
> On 2/11/20 6:14 PM, Eric Biggers wrote:
> > On Tue, Feb 11, 2020 at 05:09:22PM -0500, Jes Sorensen wrote:
> >> On 2/11/20 2:22 PM, Eric Biggers wrote:
> >>> Hi Jes,
> >> So I basically want to be able to carry verity signatures in RPM as RPM
> >> internal data, similar to how it supports IMA signatures. I want to be
> >> able to install those without relying on post-install scripts and
> >> signature files being distributed as actual files that gets installed,
> >> just to have to remove them. This is how IMA support is integrated into
> >> RPM as well.
> >>
> >> Right now the RPM approach for signatures involves two steps, a build
> >> digest phase, and a sign the digest phase.
> >>
> >> The reason I included enable and measure was for completeness. I don't
> >> care wildly about those.
> >
> > So the signing happens when the RPM is built, not when it's installed? Are you
> > sure you actually need a library and not just 'fsverity sign' called from a
> > build script?
>
> So the way RPM is handling these is to calculate the digest in one
> place, and sign it in another. Basically the signing is a second step,
> post build, using the rpmsign command. Shelling out is not a good fit
> for this model.
>
> >>> Separately, before you start building something around fs-verity's builtin
> >>> signature verification support, have you also considered adding support for
> >>> fs-verity to IMA? I.e., using the fs-verity hashing mechanism with the IMA
> >>> signature mechanism. The IMA maintainer has been expressed interested in that.
> >>> If rpm already supports IMA signatures, maybe that way would be a better fit?
> >>
> >> I looked at IMA and it is overly complex. It is not obvious to me how
> >> you would get around that without the full complexity of IMA? The beauty
> >> of fsverity's approach is the simplicity of relying on just the kernel
> >> keyring for validation of the signature. If you have explicit
> >> suggestions, I am certainly happy to look at it.
> >
> > fs-verity's builtin signature verification feature is simple, but does it
> > actually do what you need? Note that unlike IMA, it doesn't provide an
> > in-kernel policy about which files have to have signatures and which don't.
> > I.e., to get any authenticity guarantee, before using any files that are
> > supposed to be protected by fs-verity, userspace has to manually check whether
> > the fs-verity bit is actually set. Is that part of your design?
>
> Totally aware of this, and it fits the model I am looking at.
>
Well, this might be a legitimate use case then. We need to define the library
interface as simply as possible, though, so that we can maintain this code in
the future without breaking users. I suggest starting with something along the
lines of:
#ifndef _LIBFSVERITY_H
#define _LIBFSVERITY_H
#include <stddef.h>
#include <stdint.h>
#define FS_VERITY_HASH_ALG_SHA256 1
#define FS_VERITY_HASH_ALG_SHA512 2
struct libfsverity_merkle_tree_params {
uint32_t version;
uint32_t hash_algorithm;
uint32_t block_size;
uint32_t salt_size;
const uint8_t *salt;
size_t reserved[11];
};
struct libfsverity_digest {
uint16_t digest_algorithm;
uint16_t digest_size;
uint8_t digest[];
};
struct libfsverity_signature_params {
const char *keyfile;
const char *certfile;
size_t reserved[11];
};
int libfsverity_compute_digest(int fd,
const struct libfsverity_merkle_tree_params *params,
struct libfsverity_digest **digest_ret);
int libfsverity_sign_digest(const struct libfsverity_digest *digest,
const struct libfsverity_signature_params *sig_params,
void **sig_ret, size_t *sig_size_ret);
#endif /* _LIBFSVERITY_H */
I.e.:
- The stuff in util.h and hash_algs.h isn't exposed to library users.
- Then names of all library functions and structs are appropriately prefixed
and avoid collisions with the kernel header.
- Only signing functionality is included.
- There are reserved fields, so we can add more parameters later.
Before committing to any stable API, it would also be helpful to see the RPM
patches to see what it actually does.
We'd also need to follow shared library best practices like compiling with
-fvisibility=hidden and marking the API functions explicitly with
__attribute__((visibility("default"))), and setting the 'soname' like
-Wl,-soname=libfsverity.so.0.
Also, is the GPLv2+ license okay for the use case?
- Eric
^ permalink raw reply
* Re: get-lore-mbox: quickly grab full threads from lore
From: Kevin Hilman @ 2020-02-14 20:35 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: workflows
In-Reply-To: <20200214195318.ghvcroucki4pcz4r@chatter.i7.local>
Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
> On Fri, Feb 14, 2020 at 11:30:42AM -0800, Kevin Hilman wrote:
>> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
>>
>> > I'd like your opinion on this quick helper script I wrote that uses any
>> > message-id to grab a full thread from lore.kernel.org and save it as a
>> > mbox file.
>>
>> This is very useful, thank you!
>>
>> One question/request: Is there a way for it to only grab a subset of a
>> series? e.g. Some series contain patches that might end up going
>> through a couple different trees (e.g. DT patches typically take a
>> separate path than drivers) so as a maintainer for one of the
>> subsystems, I might want to only get a subset of the series into an
>> mbox, not the whole thing.
>>
>> IOW, Right now even if I pass a msgid from the middle of the series, it
>> finds the whole series (which is cool!), but what if I want to apply
>> just that single patch? Or even better, I might want to only apply
>> patches 3-5 and 9 from a 10-patch series.
>>
>> Is this something do-able?
>
> I think for such cases it's easy enough to just edit the .mbx file to
> remove the patches you're not interested in.
Yes, that was my first "solution", but it's not very easy to
automate. :)
If there needs to be a manual step, I prefer 'git am --interactive'.
Anyways, this tool is really great and it's already replacing some of my
homebrew scripts.
Thanks,
Kevin
^ permalink raw reply
* Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
From: Jason Gunthorpe @ 2020-02-14 20:34 UTC (permalink / raw)
To: Greg KH
Cc: Jeff Kirsher, davem, Dave Ertman, netdev, linux-rdma, nhorman,
sassmann, parav, galpress, selvin.xavier, sriharsha.basavapatna,
benve, bharat, xavier.huwei, yishaih, leonro, mkalderon, aditr,
Kiran Patil, Andrew Bowers
In-Reply-To: <20200214170240.GA4034785@kroah.com>
On Fri, Feb 14, 2020 at 09:02:40AM -0800, Greg KH wrote:
> > +/**
> > + * virtbus_dev_register - add a virtual bus device
> > + * @vdev: virtual bus device to add
> > + */
> > +int virtbus_dev_register(struct virtbus_device *vdev)
> > +{
> > + int ret;
> > +
> > + if (!vdev->release) {
> > + dev_err(&vdev->dev, "virtbus_device .release callback NULL\n");
>
> "virtbus_device MUST have a .release callback that does something!\n"
>
> > + return -EINVAL;
> > + }
> > +
> > + device_initialize(&vdev->dev);
> > +
> > + vdev->dev.bus = &virtual_bus_type;
> > + vdev->dev.release = virtbus_dev_release;
> > + /* All device IDs are automatically allocated */
> > + ret = ida_simple_get(&virtbus_dev_ida, 0, 0, GFP_KERNEL);
> > + if (ret < 0) {
> > + dev_err(&vdev->dev, "get IDA idx for virtbus device failed!\n");
> > + put_device(&vdev->dev);
>
> If you allocate the number before device_initialize(), no need to call
> put_device(). Just a minor thing, no big deal.
If *_regster does put_device on error then it must always do
put_device on any error, for instance the above return -EINVAL with
no put_device leaks memory.
Generally I find the design and audit of drivers simpler if the
register doesn't do device_initialize or put_device - have them
distinct and require the caller to manage this.
For instance look at ice_init_peer_devices() and ask who frees
the alloc_ordered_workqueue() if virtbus_dev_register() fails..
It is not all easy to tell if this is right or not..
> > + put_device(&vdev->dev);
> > + ida_simple_remove(&virtbus_dev_ida, vdev->id);
>
> You need to do this before put_device().
Shouldn't it be in the release function? The ida index should not be
re-used until the kref goes to zero..
> > +struct virtbus_device {
> > + struct device dev;
> > + const char *name;
> > + void (*release)(struct virtbus_device *);
> > + int id;
> > + const struct virtbus_dev_id *matched_element;
> > +};
>
> Any reason you need to make "struct virtbus_device" a public structure
> at all?
The general point of this scheme is to do this in a public header:
+struct iidc_virtbus_object {
+ struct virtbus_device vdev;
+ struct iidc_peer_dev *peer_dev;
+};
And then this when the driver binds:
+int irdma_probe(struct virtbus_device *vdev)
+{
+ struct iidc_virtbus_object *vo =
+ container_of(vdev, struct iidc_virtbus_object, vdev);
+ struct iidc_peer_dev *ldev = vo->peer_dev;
So the virtbus_device is in a public header to enable the container_of
construction.
Jason
^ permalink raw reply
* [PATCH] xfstests: add a CGROUP configuration option
From: Josef Bacik @ 2020-02-14 20:34 UTC (permalink / raw)
To: fstests, linux-btrfs
I want to add some extended statistic gathering for xfstests, but it's
tricky to isolate xfstests from the rest of the host applications. The
most straightforward way to do this is to run every test inside of it's
own cgroup. From there we can monitor the activity of tasks in the
specific cgroup using BPF.
The support for this is pretty simple, allow users to specify
CGROUP=/path/to/cgroup. We will create the path if it doesn't already
exist, and validate we can add things to cgroup.procs. If we cannot
it'll be disabled, otherwise we will use this when we do _run_seq by
echo'ing the bash pid into cgroup.procs, which will cause any children
to run under that cgroup.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
README | 3 +++
check | 17 ++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/README b/README
index 593c1052..722dc170 100644
--- a/README
+++ b/README
@@ -102,6 +102,9 @@ Preparing system for tests:
- set USE_KMEMLEAK=yes to scan for memory leaks in the kernel
after every test, if the kernel supports kmemleak.
- set KEEP_DMESG=yes to keep dmesg log after test
+ - set CGROUP=/path/to/cgroup to create a cgroup to run tests inside
+ of. The main check will run outside of the cgroup, only the test
+ itself and any child processes will run under the cgroup.
- or add a case to the switch in common/config assigning
these variables based on the hostname of your test
diff --git a/check b/check
index 2e148e57..07a0e251 100755
--- a/check
+++ b/check
@@ -509,11 +509,23 @@ _expunge_test()
OOM_SCORE_ADJ="/proc/self/oom_score_adj"
test -w ${OOM_SCORE_ADJ} && echo -1000 > ${OOM_SCORE_ADJ}
+# Initialize the cgroup path if it doesn't already exist
+if [ ! -z "$CGROUP" ]; then
+ mkdir -p ${CGROUP}
+
+ # If we can't write to cgroup.procs then unset cgroup
+ test -w ${CGROUP}/cgroup.procs || unset CGROUP
+fi
+
# ...and make the tests themselves somewhat more attractive to it, so that if
# the system runs out of memory it'll be the test that gets killed and not the
# test framework.
_run_seq() {
- bash -c "test -w ${OOM_SCORE_ADJ} && echo 250 > ${OOM_SCORE_ADJ}; exec ./$seq"
+ _extra="test -w ${OOM_SCORE_ADJ} && echo 250 > ${OOM_SCORE_ADJ};"
+ if [ ! -z "$CGROUP" ]; then
+ _extra+="echo $$ > ${CGROUP}/cgroup.procs;"
+ fi
+ bash -c "${_extra} exec ./$seq"
}
_detect_kmemleak
@@ -615,6 +627,9 @@ for section in $HOST_OPTIONS_SECTIONS; do
echo "MKFS_OPTIONS -- `_scratch_mkfs_options`"
echo "MOUNT_OPTIONS -- `_scratch_mount_options`"
fi
+ if [ ! -z "$CGROUP" ]; then
+ echo "CGROUP -- ${CGROUP}"
+ fi
echo
needwrap=true
--
2.24.1
^ permalink raw reply related
* [PATCH -next] fork: annotate a data race in vm_area_dup()
From: Qian Cai @ 2020-02-14 20:33 UTC (permalink / raw)
To: akpm; +Cc: elver, linux-mm, linux-kernel, Qian Cai
struct vm_area_struct could be accessed concurrently as noticed by
KCSAN,
write to 0xffff9cf8bba08ad8 of 8 bytes by task 14263 on cpu 35:
vma_interval_tree_insert+0x101/0x150:
rb_insert_augmented_cached at include/linux/rbtree_augmented.h:58
(inlined by) vma_interval_tree_insert at mm/interval_tree.c:23
__vma_link_file+0x6e/0xe0
__vma_link_file at mm/mmap.c:629
vma_link+0xa2/0x120
mmap_region+0x753/0xb90
do_mmap+0x45c/0x710
vm_mmap_pgoff+0xc0/0x130
ksys_mmap_pgoff+0x1d1/0x300
__x64_sys_mmap+0x33/0x40
do_syscall_64+0x91/0xc44
entry_SYSCALL_64_after_hwframe+0x49/0xbe
read to 0xffff9cf8bba08a80 of 200 bytes by task 14262 on cpu 122:
vm_area_dup+0x6a/0xe0
vm_area_dup at kernel/fork.c:362
__split_vma+0x72/0x2a0
__split_vma at mm/mmap.c:2661
split_vma+0x5a/0x80
mprotect_fixup+0x368/0x3f0
do_mprotect_pkey+0x263/0x420
__x64_sys_mprotect+0x51/0x70
do_syscall_64+0x91/0xc44
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The write is holding mmap_sem while changing vm_area_struct.shared.rb.
Even though the read is lockless while making a copy, the clone will
have its own shared.rb reinitialized. Thus, mark it as an intentional
data race using the data_race() macro.
Signed-off-by: Qian Cai <cai@lca.pw>
---
kernel/fork.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 41f784b6203a..81bdc6e8a6cf 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -359,7 +359,11 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig)
struct vm_area_struct *new = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (new) {
- *new = *orig;
+ /*
+ * @orig may be modified concurrently, but the clone will be
+ * reinitialized.
+ */
+ *new = data_race(*orig);
INIT_LIST_HEAD(&new->anon_vma_chain);
}
return new;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: phy: restore mdio regs in the iproc mdio driver
From: Andrew Lunn @ 2020-02-14 20:33 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Ray Jui, Arun Parameswaran, Russell King,
linux-kernel, bcm-kernel-feedback-list, netdev, David S . Miller,
linux-arm-kernel, Heiner Kallweit
In-Reply-To: <20200214194858.8528-1-scott.branden@broadcom.com>
On Fri, Feb 14, 2020 at 11:48:58AM -0800, Scott Branden wrote:
> From: Arun Parameswaran <arun.parameswaran@broadcom.com>
>
> The mii management register in iproc mdio block
> does not have a reention register so it is lost on suspend.
reention?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] net: phy: restore mdio regs in the iproc mdio driver
From: Andrew Lunn @ 2020-02-14 20:33 UTC (permalink / raw)
To: Scott Branden
Cc: Florian Fainelli, Heiner Kallweit, Ray Jui, Arun Parameswaran,
Russell King, linux-kernel, bcm-kernel-feedback-list, netdev,
David S . Miller, linux-arm-kernel
In-Reply-To: <20200214194858.8528-1-scott.branden@broadcom.com>
On Fri, Feb 14, 2020 at 11:48:58AM -0800, Scott Branden wrote:
> From: Arun Parameswaran <arun.parameswaran@broadcom.com>
>
> The mii management register in iproc mdio block
> does not have a reention register so it is lost on suspend.
reention?
Andrew
^ permalink raw reply
* [cip-dev] [ANNOUNCE] Release v4.19.103-cip20 and v4.4.213-cip42
From: nobuhiro1.iwamatsu at toshiba.co.jp @ 2020-02-14 20:32 UTC (permalink / raw)
To: cip-dev
Hi,
CIP kernel team has released Linux kernel v4.19.103-cip20 and v4.4.213-cip42.
The linux-4.19.y-cip tree has been updated base version from v4.19.98 to v4.19.103,
and many features of r8a774b1 have been added.
Then the linux-4.4.y-cip tree has been updated base version from v4.4.208 to v4.4.213,
and QSPI, TPU, PWM, VSP, USB and MSIOF support for r8a7744 has been added.
We can get this release via the git tree at:
v4.19.103-cip20:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
d8d2f780968e403b42ecf61d498032ade45546d0
added commits:
CIP: Bump version suffix to -cip20 after merge from stable
arm64: dts: renesas: r8a774b1: Add USB3.0 device nodes
arm64: dts: renesas: r8a774b1: Add USB-DMAC and HSUSB device nodes
arm64: dts: renesas: r8a774b1: Add USB2.0 phy and host (EHCI/OHCI) device nodes
dt-bindings: usb: renesas_usb3: Document r8a774b1 support
dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
dt-bindings: usb-xhci: Add r8a774b1 support
dt-bindings: rcar-gen3-phy-usb3: Add r8a774b1 support
dt-bindings: usb: renesas_usbhs: Add r8a774b1 support
dt-bindings: usb: renesas_usbhs: Rename bindings documentation file
dt-bindings: dmaengine: usb-dmac: Add binding for r8a774b1
dt-bindings: rcar-gen3-phy-usb2: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add Sound and Audio DMAC device nodes
ASoC: rsnd: Document r8a774b1 bindings
arm64: dts: renesas: r8a774a1: Remove audio port node
arm64: dts: renesas: Add support for Advantech idk-1110wr LVDS panel
arm64: dts: renesas: hihope-rzg2-ex: Add LVDS support
drm: rcar-du: lvds: Add r8a774b1 support
arm64: dts: renesas: hihope-rzg2-ex: Enable backlight
arm64: dts: renesas: r8a774b1: Add PWM device nodes
arm64: dts: renesas: r8a774b1: Add FDP1 device nodes
arm64: dts: renesas: r8a774b1-hihope-rzg2n: Add display clock properties
arm64: dts: renesas: r8a774b1: Add HDMI encoder instance
arm64: dts: renesas: r8a774b1: Add DU device to DT
drm: rcar-du: Add R8A774B1 support
arm64: dts: renesas: hihope-common: Move du clk properties out of common dtsi
arm64: dts: renesas: r8a774b1: Connect Ethernet-AVB to IPMMU-DS0
arm64: dts: renesas: r8a774b1: Tie SYS-DMAC to IPMMU-DS0/1
arm64: dts: renesas: r8a774b1: Add VSP instances
arm64: dts: renesas: r8a774b1: Add FCPF and FCPV instances
arm64: dts: renesas: r8a774b1: Add IPMMU device nodes
iommu/ipmmu-vmsa: Hook up r8a774b1 DT matching code
dt-bindings: iommu: ipmmu-vmsa: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add CAN and CAN FD support
dt-bindings: can: rcar_canfd: document r8a774b1 support
dt-bindings: can: rcar_can: document r8a774b1 support
arm64: dts: renesas: r8a774b1: Add TMU device nodes
clk: renesas: r8a774b1: Add TMU clock
dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings
arm64: dts: renesas: r8a774b1: Add CMT device nodes
dt-bindings: timer: renesas, cmt: Document r8a774b1 CMT support
arm64: dts: renesas: r8a774b1: Add RZ/G2N thermal support
thermal: rcar_gen3_thermal: Add r8a774b1 support
dt-bindings: thermal: rcar-gen3-thermal: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add OPPs table for cpu devices
arm64: dts: renesas: r8a774b1: Add I2C and IIC-DVFS support
dt-bindings: i2c: sh_mobile: Add r8a774b1 support
dt-bindings: i2c: sh_mobile: Rename bindings documentation file
dt-bindings: i2c: rcar: Add r8a774b1 support
dt-bindings: i2c: rcar: Rename bindings documentation file
arm64: dts: renesas: r8a774b1-hihope-rzg2n: Enable HS400 mode
arm64: dts: renesas: r8a774b1: Add SDHI support
mmc: renesas_sdhi_internal_dmac: Add r8a774b1 support
dt-bindings: mmc: renesas_sdhi: Add r8a774b1 support
arm64: dts: renesas: r8a774b1: Add INTC-EX device node
arm64: dts: renesas: hihope-rzg2-ex: Let the board specific DT decide about pciec1
arm64: dts: renesas: r8a774b1: Add PCIe device nodes
arm64: dts: renesas: r8a774b1: Add all MSIOF nodes
arm64: dts: renesas: r8a774b1: Add RWDT node
dt-bindings: watchdog: renesas-wdt: Document r8a774b1 support
dt-bindings: watchdog: Rename bindings documentation file
dt-bindings: spi: sh-msiof: Add r8a774b1 support
arm64: dts: renesas: Add HiHope RZ/G2N sub board support
arm64: dts: renesas: r8a774b1: Add Ethernet AVB node
dt-bindings: net: ravb: Add support for r8a774b1 SoC
arm64: dts: renesas: r8a774b1: Add GPIO device nodes
dt-bindings: gpio: rcar: Add DT binding for r8a774b1
arm64: dts: renesas: r8a774b1: Add SCIF and HSCIF nodes
arm64: dts: renesas: r8a774b1: Add SYS-DMAC device nodes
dt-bindings: dmaengine: rcar-dmac: Document R8A774B1 bindings
v4.4.213-cip42:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.4.y-cip
commit hash:
2507dd95fec1b330c3c62881e43d3d10d44a1a04
added commits:
CIP: Bump version suffix to -cip42 after merge from stable
ARM: dts: r8a7744: Add PCIe Controller device node
ARM: dts: r8a7744: Add xhci support
dt-bindings: usb-xhci: Document r8a7744 support
usb: host: xhci-plat: Add r8a7744 support
ARM: dts: r8a7744-iwg20m: Add SPI NOR support
ARM: dts: r8a7744: Add MSIOF[012] support
ARM: dts: r8a7744: Add QSPI support
ARM: dts: r8a7744: Add TPU support
ARM: dts: r8a7744: Add PWM SoC support
ARM: dts: r8a7744: Add VSP support
Best regards,
Nobuhiro
^ permalink raw reply
* Re: [PATCH v2 20/21] target/arm: Use FIELD_EX32 for testing 32-bit fields
From: Richard Henderson @ 2020-02-14 20:32 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-21-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> Cut-and-paste errors mean we're using FIELD_EX64() to extract fields from
> some 32-bit ID register fields. Use FIELD_EX32() instead. (This makes
> no difference in behaviour, it's just more consistent.)
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH v2 19/21] target/arm: Use isar_feature function for testing AA32HPD feature
From: Richard Henderson @ 2020-02-14 20:32 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-20-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> Now we have moved ID_MMFR4 into the ARMISARegisters struct, we
> can define and use an isar_feature for the presence of the
> ARMv8.2-AA32HPD feature, rather than open-coding the test.
>
> While we're here, correct a comment typo which missed an 'A'
> from the feature name.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 5 +++++
> target/arm/helper.c | 4 ++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [PATCH v2 18/21] target/arm: Test correct register in aa32_pan and aa32_ats1e1 checks
From: Richard Henderson @ 2020-02-14 20:30 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: Eric Auger, Aaron Lindsay, Philippe Mathieu-Daudé
In-Reply-To: <20200214175116.9164-19-peter.maydell@linaro.org>
On 2/14/20 9:51 AM, Peter Maydell wrote:
> The isar_feature_aa32_pan and isar_feature_aa32_ats1e1 functions
> are supposed to be testing fields in ID_MMFR3; but a cut-and-paste
> error meant we were looking at MVFR0 instead.
>
> Fix the functions to look at the right register; this requires
> us to move at least id_mmfr3 to the ARMISARegisters struct; we
> choose to move all the ID_MMFRn registers for consistency.
>
> Fixes: 3d6ad6bb466f
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 14 +++---
> hw/intc/armv7m_nvic.c | 8 ++--
> target/arm/cpu.c | 104 +++++++++++++++++++++---------------------
> target/arm/cpu64.c | 28 ++++++------
> target/arm/helper.c | 12 ++---
> target/arm/kvm32.c | 17 +++++++
> target/arm/kvm64.c | 10 ++++
> 7 files changed, 110 insertions(+), 83 deletions(-)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~
^ permalink raw reply
* Re: [Virtio-fs] fedora packages for virtiofsd
From: Dr. David Alan Gilbert @ 2020-02-14 20:31 UTC (permalink / raw)
To: Daniel Walsh; +Cc: virtio-fs-list, Mrunal Patel, Vivek Goyal, crobinso
In-Reply-To: <b703d3ec-b48a-776a-a525-4acb16a27ac4@redhat.com>
* Daniel Walsh (dwalsh@redhat.com) wrote:
> On 2/14/20 2:44 PM, Dr. David Alan Gilbert wrote:
> > * Vivek Goyal (vgoyal@redhat.com) wrote:
> >> Hi David,
> >>
> >> Are fedora packages for latest qemu with virtiofsd now available. Can one
> >> try it?
> >>
> >> Dan Walsh and Mrunal are looking for it (CCed in email).
> >>
> >> Keeping this thread on virtio-fs list as others might be interested as
> >> well.
> > Cole has got it into the virt-preview copr:
> >
> > https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview
> >
> > Dave
> >
> >> Thanks
> >> Vivek
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
> How soon can we get this into Fedora. I really do not want to have to
> deal with special packages, that users can not easily get a hold of. I
> am real apprehensive on giving the go-ahead on a project as being
> Enterprise ready until it gets some soak time in Fedora. I would love
> to see this available in Fedora 32, so people can start experimenting
> with it.
Understood.
It's upstream in the current QEMU tree, but it's due for release end of
April which is I assume too late for F32.
(libvirt is still a work in progress).
I'll leave Cole to comment on Fedora backporting.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [PATCH 00/28] PM: QoS: Get rid of unuseful code and rework CPU latency QoS interface
From: Francisco Jerez @ 2020-02-14 20:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Rafael J. Wysocki, Linux PM, LKML,
Amit Kucheria, Pandruvada, Srinivas, Rodrigo Vivi, Peter Zijlstra
In-Reply-To: <CAJZ5v0hm2vVbM5dXGitvvUrWoZXZXXaJ+P3x38BjHRukZKgB3Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6046 bytes --]
"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Fri, Feb 14, 2020 at 1:14 AM Francisco Jerez <currojerez@riseup.net> wrote:
>>
>> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>>
>> > On Thu, Feb 13, 2020 at 12:34 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> [cut]
>
>> >
>> > I think that your use case is almost equivalent to the thermal
>> > pressure one, so you'd want to limit the max and so that would be
>> > something similar to store_max_perf_pct() with its input side hooked
>> > up to a QoS list.
>> >
>> > But it looks like that QoS list would rather be of a "reservation"
>> > type, so a request added to it would mean something like "leave this
>> > fraction of power that appears to be available to the CPU subsystem
>> > unused, because I need it for a different purpose". And in principle
>> > there might be multiple requests in there at the same time and those
>> > "reservations" would add up. So that would be a kind of "limited sum"
>> > QoS type which wasn't even there before my changes.
>> >
>> > A user of that QoS list might then do something like
>> >
>> > ret = cpu_power_reserve_add(1, 4);
>> >
>> > meaning that it wants 25% of the "potential" CPU power to be not
>> > utilized by CPU performance scaling and that could affect the
>> > scheduler through load modifications (kind of along the thermal
>> > pressure patchset discussed some time ago) and HWP (as well as the
>> > non-HWP intel_pstate by preventing turbo frequencies from being used
>> > etc).
>>
>> The problems with this are the same as with the per-CPU frequency QoS
>> approach: How does the device driver know what the appropriate fraction
>> of CPU power is?
>
> Of course it doesn't know and it may never know exactly, but it may guess.
>
> Also, it may set up a feedback loop: request an aggressive
> reservation, run for a while, measure something and refine if there's
> headroom. Then repeat.
>
Yeah, of course, but that's obviously more computationally intensive and
less accurate than computing an approximately optimal constraint in a
single iteration (based on knowledge from performance counters and a
notion of the latency requirements of the application), since such a
feedback loop relies on repeatedly overshooting and undershooting the
optimal value (the latter causes an artificial CPU bottleneck, possibly
slowing down other applications too) in order to converge to and remain
in a neighborhood of the optimal value.
Incidentally people tested a power balancing solution with a feedback
loop very similar to the one you're describing side by side to the RFC
patch series I provided a link to earlier (which targeted Gen9 LP
parts), and the energy efficiency improvements they observed were
roughly half of the improvement obtained with my series unsurprisingly.
Not to speak about generalizing such a feedback loop to bottlenecks on
multiple I/O devices.
>> Depending on the instantaneous behavior of the
>> workload it might take 1% or 95% of the CPU power in order to keep the
>> IO device busy. Each user of this would need to monitor the performance
>> of every CPU in the system and update the constraints on each of them
>> periodically (whether or not they're talking to that IO device, which
>> would possibly negatively impact the latency of unrelated applications
>> running on other CPUs, unless we're willing to race with the task
>> scheduler).
>
> No, it just needs to measure a signal representing how much power *it*
> gets and decide whether or not it can let the CPU subsystem use more
> power.
>
Well yes it's technically possible to set frequency constraints based on
trial-and-error without sampling utilization information from the CPU
cores, but don't we agree that this kind of information can be highly
valuable?
>> A solution based on utilization clamps (with some
>> extensions) sounds more future-proof to me honestly.
>
> Except that it would be rather hard to connect it to something like
> RAPL, which should be quite straightforward with the approach I'm
> talking about.
>
I think using RAPL as additional control variable would be useful, but
fully orthogonal to the cap being set by some global mechanism or being
derived from the aggregation of a number of per-process power caps based
on the scheduler behavior. The latter sounds like the more reasonable
fit for a multi-tasking, possibly virtualized environment honestly.
Either way RAPL is neither necessary nor sufficient in order to achieve
the energy efficiency improvement I'm working on.
> The problem with all scheduler-based ways, again, is that there is no
> direct connection between the scheduler and HWP,
I was planning to introduce such a connection in RFC part 2. I have a
prototype for that based on a not particularly pretty custom interface,
I wouldn't mind trying to get it to use utilization clamps if you think
that's the way forward.
> or even with whatever the processor does with the P-states in the
> turbo range. If any P-state in the turbo range is requested, the
> processor has a license to use whatever P-state it wants, so this
> pretty much means allowing it to use as much power as it can.
>
> So in the first place, if you want to limit the use of power in the
> CPU subsystem through frequency control alone, you need to prevent it
> from using turbo P-states at all. However, with RAPL you can just
> limit power which may still allow some (but not all) turbo P-states to
> be used.
My goal is not to limit the use of power of the CPU (if it has enough
load to utilize 100% of the cycles at turbo frequency so be it), but to
get it to use it more efficiently. If you are constrained by a given
power budget (e.g. the TDP or the one you want set via RAPL) you can do
more with it if you set a stable frequency rather than if you let the
CPU bounce back and forth between turbo and idle. This can only be
achieved effectively if the frequency governor has a rough idea of the
latency requirements of the workload, since it involves a
latency/energy-efficiency trade-off.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: Buffered IO async context overhead
From: Andres Freund @ 2020-02-14 20:31 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring
In-Reply-To: <c91551b2-9694-78cb-2aa6-bc8cccc474c3@kernel.dk>
Hi,
On 2020-02-14 13:13:35 -0700, Jens Axboe wrote:
> On 2/14/20 12:50 PM, Andres Freund wrote:
> > which I think is pretty clear evidence we're hitting fairly significant
> > contention on the queue lock.
> >
> >
> > I am hitting this in postgres originally, not fio, but I thought it's
> > easier to reproduce this way. There's obviously benefit to doing things
> > in the background - but it requires odd logic around deciding when to
> > use io_uring, and when not.
> >
> > To be clear, none of this happens with DIO, but I don't forsee switching
> > to DIO for all IO by default ever (too high demands on accurate
> > configuration).
>
> Can you try with this added?
>
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 76cbf474c184..207daf83f209 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -620,6 +620,7 @@ static const struct io_op_def io_op_defs[] = {
> .async_ctx = 1,
> .needs_mm = 1,
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_WRITEV] = {
> @@ -634,6 +635,7 @@ static const struct io_op_def io_op_defs[] = {
> },
> [IORING_OP_READ_FIXED] = {
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_WRITE_FIXED] = {
> @@ -711,11 +713,13 @@ static const struct io_op_def io_op_defs[] = {
> [IORING_OP_READ] = {
> .needs_mm = 1,
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_WRITE] = {
> .needs_mm = 1,
> .needs_file = 1,
> + .hash_reg_file = 1,
> .unbound_nonreg_file = 1,
> },
> [IORING_OP_FADVISE] = {
> @@ -955,7 +959,7 @@ static inline bool io_prep_async_work(struct io_kiocb *req,
> bool do_hashed = false;
>
> if (req->flags & REQ_F_ISREG) {
> - if (def->hash_reg_file)
> + if (!(req->kiocb->ki_flags & IOCB_DIRECT) && def->hash_reg_file)
> do_hashed = true;
> } else {
> if (def->unbound_nonreg_file)
I can (will do Sunday, on the road till then). But I'm a bit doubtful
it'll help. This is using WRITEV after all, and I only see a single
worker?
Greetings,
Andres Freund
^ permalink raw reply
* Re: [PATCH 06/10] riscv: Add Kendryte K210 SoC support
From: Sean Anderson @ 2020-02-14 20:31 UTC (permalink / raw)
To: linux-riscv
In-Reply-To: <20200212103432.660256-7-damien.lemoal@wdc.com>
Hi Damien/Chistopher,
I'm working on adding k210 support to U-Boot [1], so I'm interested in
how you've tackled these problems. Hopefully, we can keep the
implementations broadly similar, to make it easier to correct bugs in
the future. In part
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=157821
On 2/12/20 5:34 AM, Damien Le Moal wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> Add support for the Kendryte K210 RISC-V SoC. For now, this support
> only provides a simple sysctl driver allowing to setup the CPU and
> uart clock. This support is enabled through the new Kconfig option
> SOC_KENDRYTE and defines the config option CONFIG_K210_SYSCTL
> to enable the K210 SoC sysctl driver compilation.
>
> The sysctl driver also registers an early SoC initialization function
> allowing enabling the general purpose use of the 2MB of SRAM normally
> reserved for the SoC AI engine. This initialization function is
> automatically called before the dt early initialization using the flat
> dt root node compatible property matching the value "kendryte,k210".
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
> arch/riscv/Kconfig.socs | 6 +
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/kendryte/Kconfig | 14 ++
> drivers/soc/kendryte/Makefile | 3 +
> drivers/soc/kendryte/k210-sysctl.c | 245 +++++++++++++++++++++++++++++
> 6 files changed, 270 insertions(+)
> create mode 100644 drivers/soc/kendryte/Kconfig
> create mode 100644 drivers/soc/kendryte/Makefile
> create mode 100644 drivers/soc/kendryte/k210-sysctl.c
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index d325b67d00df..4d5d4a65b2a2 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -10,4 +10,10 @@ config SOC_SIFIVE
> help
> This enables support for SiFive SoC platform hardware.
>
> +config SOC_KENDRYTE
> + bool "Kendryte K210 SoC"
> + depends on !MMU
> + help
> + This enables support for Kendryte K210 SoC hardware.
> +
> endmenu
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 1778f8c62861..425ab6f7e375 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -22,5 +22,6 @@ source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> source "drivers/soc/xilinx/Kconfig"
> source "drivers/soc/zte/Kconfig"
> +source "drivers/soc/kendryte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 8b49d782a1ab..af58063bb989 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> obj-y += xilinx/
> obj-$(CONFIG_ARCH_ZX) += zte/
> +obj-$(CONFIG_SOC_KENDRYTE) += kendryte/
> diff --git a/drivers/soc/kendryte/Kconfig b/drivers/soc/kendryte/Kconfig
> new file mode 100644
> index 000000000000..49785b1b0217
> --- /dev/null
> +++ b/drivers/soc/kendryte/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_KENDRYTE
> +
> +config K210_SYSCTL
> + bool "Kendryte K210 system controller"
> + default y
> + depends on RISCV
> + help
> + Enables controlling the K210 various clocks and to enable
> + general purpose use of the extra 2MB of SRAM normally
> + reserved for the AI engine.
> +
> +endif
> diff --git a/drivers/soc/kendryte/Makefile b/drivers/soc/kendryte/Makefile
> new file mode 100644
> index 000000000000..002d9ce95c0d
> --- /dev/null
> +++ b/drivers/soc/kendryte/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_K210_SYSCTL) += k210-sysctl.o
> diff --git a/drivers/soc/kendryte/k210-sysctl.c b/drivers/soc/kendryte/k210-sysctl.c
> new file mode 100644
> index 000000000000..7d4ecd954af0
> --- /dev/null
> +++ b/drivers/soc/kendryte/k210-sysctl.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2019 Christoph Hellwig.
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +#include <linux/types.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <asm/soc.h>
> +
> +#define K210_SYSCTL_CLK0_FREQ 26000000UL
> +
> +/* Registers base address */
> +#define K210_SYSCTL_SYSCTL_BASE_ADDR 0x50440000ULL
> +
> +/* Registers */
> +#define K210_SYSCTL_PLL0 0x08
> +#define K210_SYSCTL_PLL1 0x0c
> +/* clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
> +#define PLL_RESET (1 << 20)
> +#define PLL_PWR (1 << 21)
> +#define PLL_INTFB (1 << 22)
> +#define PLL_BYPASS (1 << 23)
> +#define PLL_TEST (1 << 24)
> +#define PLL_OUT_EN (1 << 25)
> +#define PLL_TEST_EN (1 << 26)
> +#define K210_SYSCTL_PLL_LOCK 0x18
> +#define PLL0_LOCK1 (1 << 0)
> +#define PLL0_LOCK2 (1 << 1)
> +#define PLL0_SLIP_CLEAR (1 << 2)
> +#define PLL0_TEST_CLK_OUT (1 << 3)
> +#define PLL1_LOCK1 (1 << 8)
> +#define PLL1_LOCK2 (1 << 9)
> +#define PLL1_SLIP_CLEAR (1 << 10)
> +#define PLL1_TEST_CLK_OUT (1 << 11)
> +#define PLL2_LOCK1 (1 << 16)
> +#define PLL2_LOCK2 (1 << 16)
> +#define PLL2_SLIP_CLEAR (1 << 18)
> +#define PLL2_TEST_CLK_OUT (1 << 19)
> +#define K210_SYSCTL_CLKSEL0 0x20
> +#define CLKSEL_ACLK (1 << 0)
> +#define K210_SYSCTL_CLKEN_CENT 0x28
> +#define CLKEN_CPU (1 << 0)
> +#define CLKEN_SRAM0 (1 << 1)
> +#define CLKEN_SRAM1 (1 << 2)
> +#define CLKEN_APB0 (1 << 3)
> +#define CLKEN_APB1 (1 << 4)
> +#define CLKEN_APB2 (1 << 5)
> +#define K210_SYSCTL_CLKEN_PERI 0x2c
> +#define CLKEN_ROM (1 << 0)
> +#define CLKEN_DMA (1 << 1)
> +#define CLKEN_AI (1 << 2)
> +#define CLKEN_DVP (1 << 3)
> +#define CLKEN_FFT (1 << 4)
> +#define CLKEN_GPIO (1 << 5)
> +#define CLKEN_SPI0 (1 << 6)
> +#define CLKEN_SPI1 (1 << 7)
> +#define CLKEN_SPI2 (1 << 8)
> +#define CLKEN_SPI3 (1 << 9)
> +#define CLKEN_I2S0 (1 << 10)
> +#define CLKEN_I2S1 (1 << 11)
> +#define CLKEN_I2S2 (1 << 12)
> +#define CLKEN_I2C0 (1 << 13)
> +#define CLKEN_I2C1 (1 << 14)
> +#define CLKEN_I2C2 (1 << 15)
> +#define CLKEN_UART1 (1 << 16)
> +#define CLKEN_UART2 (1 << 17)
> +#define CLKEN_UART3 (1 << 18)
> +#define CLKEN_AES (1 << 19)
> +#define CLKEN_FPIO (1 << 20)
> +#define CLKEN_TIMER0 (1 << 21)
> +#define CLKEN_TIMER1 (1 << 22)
> +#define CLKEN_TIMER2 (1 << 23)
> +#define CLKEN_WDT0 (1 << 24)
> +#define CLKEN_WDT1 (1 << 25)
> +#define CLKEN_SHA (1 << 26)
> +#define CLKEN_OTP (1 << 27)
> +#define CLKEN_RTC (1 << 29)
> +
> +struct k210_sysctl {
> + void __iomem *regs;
> + struct clk_hw hw;
> +};
> +
> +static void k210_set_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) | val, reg);
> +}
> +
> +static void k210_clear_bits(u32 val, void __iomem *reg)
> +{
> + writel(readl(reg) & ~val, reg);
> +}
> +
> +static void k210_pll1_enable(void __iomem *regs)
> +{
> + u32 val;
> +
> + val = readl(regs + K210_SYSCTL_PLL1);
> + val &= ~0xfffff;
> + val |= (59 << 4) | (3 << 10) | (59 << 15);
Can this be done with symbolic constants? Additionally, I believe bwadj
needs to be set to the value you use for f (at least when using internal
feedback). There is a datasheet floating around under the name
"TCITSMCN40GGPMPLLA1_guide" which has more information about the PLL's
internals.
> + writel(val, regs + K210_SYSCTL_PLL1);
> +
> + k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
> +
> + /*
> + * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
> + */
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> + nop();
> + nop();
> + k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
> +
> + for (;;) {
> + val = readl(regs + K210_SYSCTL_PLL_LOCK);
> + if (val & PLL1_LOCK2)
> + break;
> + writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
> + }
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
> +}
> +
> +static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
> + u32 clksel0, pll0;
> + u64 pll0_freq, clkr0, clkf0, clkod0;
> +
> + /*
> + * If the clock selector is not set, use the base frequency.
> + * Otherwise, use PLL0 frequency with a frequency divisor.
> + */
> + clksel0 = readl(s->regs + K210_SYSCTL_CLKSEL0);
> + if (!(clksel0 & CLKSEL_ACLK))
> + return K210_SYSCTL_CLK0_FREQ;
> +
> + /*
> + * Get PLL0 frequency:
> + * freq = base frequency * clkf0 / (clkr0 * clkod0)
> + */
> + pll0 = readl(s->regs + K210_SYSCTL_PLL0);
> + clkr0 = 1 + (pll0 & 0x0000000f);
> + clkf0 = 1 + ((pll0 & 0x000003f0) >> 4);
> + clkod0 = 1 + ((pll0 & 0x00003c00) >> 10);
Can you do this with FIELD_GET and GENMASK instead?
> + pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
> +
> + /* Get the frequency divisor from the clock selector */
> + return pll0_freq / (2ULL << ((clksel0 & 0x00000006) >> 1));
Same thing here.
> +}
> +
> +static const struct clk_ops k210_sysctl_clk_ops = {
> + .recalc_rate = k210_sysctl_clk_recalc_rate,
> +};
> +
> +static const struct clk_init_data k210_clk_init_data = {
> + .name = "k210-sysctl-pll1",
> + .ops = &k210_sysctl_clk_ops,
> +};
> +
> +static int k210_sysctl_probe(struct platform_device *pdev)
> +{
> + struct k210_sysctl *s;
> + int error;
> +
> + pr_info("Kendryte K210 SoC sysctl\n");
> +
> + s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
> + if (!s)
> + return -ENOMEM;
> +
> + s->regs = devm_ioremap_resource(&pdev->dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> + if (IS_ERR(s->regs))
> + return PTR_ERR(s->regs);
> +
> + s->hw.init = &k210_clk_init_data;
> + error = devm_clk_hw_register(&pdev->dev, &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "failed to register clk");
> + return error;
> + }
> +
> + error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
> + &s->hw);
> + if (error) {
> + dev_err(&pdev->dev, "adding clk provider failed\n");
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id k210_sysctl_of_match[] = {
> + { .compatible = "kendryte,k210-sysctl", },
> + {}
> +};
> +
> +static struct platform_driver k210_sysctl_driver = {
> + .driver = {
> + .name = "k210-sysctl",
> + .of_match_table = k210_sysctl_of_match,
> + },
> + .probe = k210_sysctl_probe,
> +};
> +
> +static int __init k210_sysctl_init(void)
> +{
> + return platform_driver_register(&k210_sysctl_driver);
> +}
> +core_initcall(k210_sysctl_init);
> +
> +/*
> + * This needs to be called very early during initialization, given that
> + * PLL1 needs to be enabled to be able to use all SRAM.
> + */
> +static void __init k210_soc_early_init(const void *fdt)
> +{
> + void __iomem *regs;
> +
> + regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
> + if (!regs)
> + panic("K210 sysctl ioremap");
> +
> + /* Enable PLL1 to make the KPU SRAM useable */
> + k210_pll1_enable(regs);
> +
> + k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
> +
> + k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
> + regs + K210_SYSCTL_CLKEN_CENT);
> + k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
> + regs + K210_SYSCTL_CLKEN_PERI);
> +
> + k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_CLKSEL0);
> +
> + iounmap(regs);
> +}
> +SOC_EARLY_INIT_DECLARE("kendryte,k210", k210_soc_early_init);
--Sean
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.