Re: [PATCH 0/3]nds32: Correct the cache operation for catch aliasing case
2018-05-15 16:46 GMT+08:00 Vincent Chen : > The following 3 issues are fixed in this patchset > > 1. In function flush_dacache_page and copy_user_highpage, the local irq is > enabled when the cache of the page at address page_address(page) is written > back to memory. It possibly causes data corruption. To fix this problem, > the local irq is disabled before executing d-cache write-back and > invalidate in this patchset. > > 2. According to Documentation/cachetlb.txt, the cache of the page at vmaddr > shall be flushed in flush_anon_page instead of the cache of the page at > page_address(page). We correct it and add the modification to this > patchset. > > 3. Removing unneeded cache invalidation in copy_user_highpage function. > > > Vincent Chen (3): > nds32: Correct flush_dcache_page function > nds32: Flush the cache of the page at vmaddr instead of kaddr in > flush_anon_page > nds32: Disable local irq before calling cpu_dcache_wb_page in > copy_user_highpage > > arch/nds32/mm/cacheflush.c | 34 -- > 1 files changed, 20 insertions(+), 14 deletions(-) > Thank you, Vincent. Reviewed-by: Greentime Hu
Re: [PATCH v4 19/31] Documentation: kconfig: document a new Kconfig macro language
2018-05-17 15:38 GMT+09:00 Kees Cook :
> On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada
> wrote:
>> Add a document for the macro language introduced to Kconfig.
>>
>> The motivation of this work is to move the compiler option tests to
>> Kconfig from Makefile. A number of kernel features require the
>> compiler support. Enabling such features blindly in Kconfig ends up
>> with a lot of nasty build-time testing in Makefiles. If a chosen
>> feature turns out unsupported by the compiler, what the build system
>> can do is either to disable it (silently!) or to forcibly break the
>> build, despite Kconfig has let the user to enable it. By moving the
>> compiler capability tests to Kconfig, features unsupported by the
>> compiler will be hidden automatically.
>>
>> This change was strongly prompted by Linus Torvalds. You can find
>> his suggestions [1] [2] in ML. The original idea was to add a new
>> attribute with 'option shell=...', but I found more generalized text
>> expansion would make Kconfig more powerful and lovely. The basic
>> ideas are from Make, but there are some differences.
>>
>> [1]: https://lkml.org/lkml/2016/12/9/577
>> [2]: https://lkml.org/lkml/2018/2/7/527
>>
>> Signed-off-by: Masahiro Yamada
>
> (Added Randy, Jon, and linux-doc to CC for more review)
>
> This should likely be written in .rst and linked to from the developer
> index...
>
> https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#writing-documentation
>
> As for the content, though:
>
> Reviewed-by: Kees Cook
>
> -Kees
At least, nothing in Documentation/kbuild/ has not been
converted to ReST yet.
>> ---
>>
>> Changes in v4:
>> - Update according to the syntax change
>>
>> Changes in v3:
>> - Newly added
>>
>> Changes in v2: None
>>
>> Documentation/kbuild/kconfig-macro-language.txt | 252
>>
>> MAINTAINERS | 2 +-
>> 2 files changed, 253 insertions(+), 1 deletion(-)
>> create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>>
>> diff --git a/Documentation/kbuild/kconfig-macro-language.txt
>> b/Documentation/kbuild/kconfig-macro-language.txt
>> new file mode 100644
>> index 000..a8dc792
>> --- /dev/null
>> +++ b/Documentation/kbuild/kconfig-macro-language.txt
>> @@ -0,0 +1,252 @@
>> +Concept
>> +---
>> +
>> +The basic idea was inspired by Make. When we look at Make, we notice sort of
>> +two languages in one. One language describes dependency graphs consisting of
>> +targets and prerequisites. The other is a macro language for performing
>> textual
>> +substitution.
>> +
>> +There is clear distinction between the two language stages. For example, you
>> +can write a makefile like follows:
>> +
>> +APP := foo
>> +SRC := foo.c
>> +CC := gcc
>> +
>> +$(APP): $(SRC)
>> +$(CC) -o $(APP) $(SRC)
>> +
>> +The macro language replaces the variable references with their expanded
>> form,
>> +and handles as if the source file were input like follows:
>> +
>> +foo: foo.c
>> +gcc -o foo foo.c
>> +
>> +Then, Make analyzes the dependency graph and determines the targets to be
>> +updated.
>> +
>> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
>> +file like this:
>> +
>> +CC := gcc
>> +
>> +config CC_HAS_FOO
>> +def_bool $(shell, $(srctree)/scripts/gcc-check-foo.sh $(CC))
>> +
>> +The macro language in Kconfig processes the source file into the following
>> +intermediate:
>> +
>> +config CC_HAS_FOO
>> +def_bool y
>> +
>> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
>> +dependency as explained in kconfig-language.txt.
>> +
>> +
>> +Variables
>> +-
>> +
>> +Like in Make, a variable in Kconfig works as a macro variable. A macro
>> +variable is expanded "in place" to yield a text string that may then be
>> +expanded further. To get the value of a variable, enclose the variable name
>> in
>> +$( ). The parentheses are required even for single-letter variable names;
>> $X is
>> +a syntax error. The curly brace form as in ${CC} is not supported either.
>> +
>> +There are two types of variables: simply expanded variables and recursively
>> +expanded variables.
>> +
>> +A simply expanded variable is defined using the := assignment operator. Its
>> +righthand side is expanded immediately upon reading the line from the
>> Kconfig
>> +file.
>> +
>> +A recursively expanded variable is defined using the = assignment operator.
>> +Its righthand side is simply stored as the value of the variable without
>> +expanding it in any way. Instead, the expansion is performed when the
>> variable
>> +is used.
>> +
>> +There is another type of assignment operator; += is used to append text to a
>> +variable. The righthand side of += is expanded immediately if the lefthand
>> +side was originally defined as a simple variable. Otherwise, its evaluation
>> is
>> +deferred.
>> +
>> +The variable reference can t
Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote: > Hi Greg, > > Have you had a chance to look at the cachinfo parts of this patch? Nope :) I didn't write that, and while it is dumped in the driver core section of the kernel, I know nothing about it. If you get an ack from Sundeep for this, which you did, that's fine with me, merge away! thanks, greg k-h
Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1
On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote: > pdev_nr and rhport can be controlled by user-space, hence leading to > a potential exploitation of the Spectre variant 1 vulnerability. > > This issue was detected with the help of Smatch: > drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential > spectre issue 'vhcis' > drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential > spectre issue 'vhcis' > drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential > spectre issue 'vhci->vhci_hcd_ss->vdev' > drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential > spectre issue 'vhci->vhci_hcd_hs->vdev' Nit, no need to line-wrap long error messages from tools :) > Fix this by sanitizing pdev_nr and rhport before using them to index > vhcis and vhci->vhci_hcd_ss->vdev respectively. > > Notice that given that speculation windows are large, the policy is > to kill the speculation on the first load and not worry if it can be > completed with a dependent load/store [1]. > > [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 > > Cc: sta...@vger.kernel.org > Signed-off-by: Gustavo A. R. Silva > --- > drivers/usb/usbip/vhci_sysfs.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c > index 4880838..9045888 100644 > --- a/drivers/usb/usbip/vhci_sysfs.c > +++ b/drivers/usb/usbip/vhci_sysfs.c > @@ -10,6 +10,8 @@ > #include > #include > > +#include > + > #include "usbip_common.h" > #include "vhci.h" > > @@ -235,6 +237,8 @@ static ssize_t detach_store(struct device *dev, struct > device_attribute *attr, > if (!valid_port(pdev_nr, rhport)) > return -EINVAL; > > + pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers); > + rhport = array_index_nospec(rhport, VHCI_HC_PORTS); Shouldn't we just do this in one place, in the valid_port() function? That way it keeps the range checking logic in one place (now it is in 3 places in the function), which should make maintenance much simpler. thanks, greg k-h
linux-next: build warning after merge of the integrity tree
Hi all,
After merging the integrity tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
security/integrity/ima/ima_kexec.c:18:0: warning: "pr_fmt" redefined
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
In file included from include/linux/kernel.h:14:0,
from include/asm-generic/bug.h:18,
from arch/powerpc/include/asm/bug.h:128,
from include/linux/bug.h:5,
from include/linux/seq_file.h:7,
from security/integrity/ima/ima_kexec.c:13:
include/linux/printk.h:288:0: note: this is the location of the previous
definition
#define pr_fmt(fmt) fmt
Introduced by commit
3dea0d93d257 ("ima: Unify logging")
--
Cheers,
Stephen Rothwell
pgpL8es8g4xrv.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block
On 2018 Mai 17, Borislav Petkov wrote:
> On Tue, May 15, 2018 at 11:39:54AM +0200, Johannes Hirte wrote:
> > The out-of-bound access happens in get_block_address:
> >
> > if (bankp && bankp->blocks) {
> > struct threshold_block *blockp blockp = &bankp->blocks[block];
> >
> > with block=1. This doesn't exists. I don't even find any array here.
> > There is a linked list, created in allocate_threshold_blocks. On my
> > system I get 17 lists with one element each.
>
> Yes, what a mess this is. ;-\
>
> There's no such thing as ->blocks[block] array. We assign simply the
> threshold_block to it in allocate_threshold_blocks:
>
> per_cpu(threshold_banks, cpu)[bank]->blocks = b;
>
> And I can't say the design of this thing is really friendly but it is
> still no excuse that I missed that during review. Grrr.
>
> So, Yazen, what really needs to happen here is to iterate the
> bank->blocks->miscj list to find the block you're looking for and return
> its address, the opposite to this here:
>
> if (per_cpu(threshold_banks, cpu)[bank]->blocks) {
> list_add(&b->miscj,
> &per_cpu(threshold_banks, cpu)[bank]->blocks->miscj);
> } else {
> per_cpu(threshold_banks, cpu)[bank]->blocks = b;
> }
>
> and don't forget to look at ->blocks itself.
>
> And then you need to make sure that searching for block addresses still
> works when resuming from suspend so that you can avoid the RDMSR IPIs.
>
Maybe I'm missing something, but those RDMSR IPSs don't happen on
pre-SMCA systems, right? So the caching should be avoided here, cause
the whole lookup looks more expensive to me than the simple switch-block
in get_block_address.
--
Regards,
Johannes
Re: [PATCH v4 20/31] kconfig: test: add Kconfig macro language tests
2018-05-17 15:41 GMT+09:00 Kees Cook : > On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada > wrote: >> Here are the test cases I used for developing the text expansion >> feature. >> >> Signed-off-by: Masahiro Yamada > > Should these be tied to the global Makefile or selftests in any way? > > -Kees > It is already. "make testconfig" will run Kconfig unit tests. You need python3 and pytest for that. -- Best Regards Masahiro Yamada
Re: [PATCH v3 2/3] ioremap: Update pgtable free interfaces with addr
On Wed 16-05-18 17:32:06, Kani Toshimitsu wrote:
> From: Chintan Pandya
>
> This patch ("mm/vmalloc: Add interfaces to free unmapped
> page table") adds following 2 interfaces to free the page
> table in case we implement huge mapping.
>
> pud_free_pmd_page() and pmd_free_pte_page()
>
> Some architectures (like arm64) needs to do proper TLB
> maintanance after updating pagetable entry even in map.
> Why ? Read this,
> https://patchwork.kernel.org/patch/10134581/
Please add that information to the changelog.
--
Michal Hocko
SUSE Labs
Re: [PATCH] xen-netfront: fix xennet_start_xmit()'s return type
On 24/04/18 15:18, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > > Signed-off-by: Luc Van Oostenryck Pushed to xen/tip.git for-linus-4.18 Juergen
Re: linux-next: manual merge of the net-next tree with the vfs tree
> + /* Create a new file under /proc/net/ipconfig */
> + static int ipconfig_proc_net_create(const char *name,
> + const struct file_operations *fops)
> + {
> + char *pname;
> + struct proc_dir_entry *p;
> +
> + if (!ipconfig_dir)
> + return -ENOMEM;
> +
> + pname = kasprintf(GFP_KERNEL, "%s%s", "ipconfig/", name);
> + if (!pname)
> + return -ENOMEM;
> +
> + p = proc_create(pname, 0444, init_net.proc_net, fops);
> + kfree(pname);
> + if (!p)
> + return -ENOMEM;
> +
> + return 0;
This code doesn't exist in the above mentioned commit. But event
without knowing the details of the /proc/net code this looks somewhat
bogus. For one I thought all the /proc/net files should be per-net
namespace. Second the ntp file really should be using proc_create_net,
to handle all that under the hood - with the merge of the VFS
tree it will take a seq_ops, which is what this code really wants
anyway.
Re: [PATCH v2 2/3] xen/store: do not store local values in xen_start_info
On 09/05/18 12:21, Roger Pau Monne wrote: > There's no need to store the xenstore page or event channel in > xen_start_info if they are locally initialized. > > This also fixes PVH local xenstore initialization due to the lack of > xen_start_info in that case. > > Signed-off-by: Boris Ostrovsky > Signed-off-by: Roger Pau Monné Pushed to xen/tip.git for-linus-4.18 Juergen
Re: [PATCH v5] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
On 09/05/18 15:16, Paul Durrant wrote: > My recent Xen patch series introduces a new HYPERVISOR_memory_op to > support direct priv-mapping of certain guest resources (such as ioreq > pages, used by emulators) by a tools domain, rather than having to access > such resources via the guest P2M. > > This patch adds the necessary infrastructure to the privcmd driver and > Xen MMU code to support direct resource mapping. > > NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now > allow a PV tools domain to map guest pages either by GFN or MFN, thus > the term 'mfn' has been swapped for 'pfn' in the lower layers of the > remap code. > > Signed-off-by: Paul Durrant > Reviewed-by: Boris Ostrovsky Pushed to xen/tip.git for-linus-4.18 Juergen
Re: [PATCH v4 20/31] kconfig: test: add Kconfig macro language tests
On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada wrote: > Here are the test cases I used for developing the text expansion > feature. > > Signed-off-by: Masahiro Yamada Should these be tied to the global Makefile or selftests in any way? -Kees -- Kees Cook Pixel Security
Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations
Dave Martin writes: > There are constraints on defining AT_* auxvec tags that are not > obvious to the casual maintainer of either the global > or the arch-specific headers. This is likely > to lead to mistakes. (I certainly fell foul of it...) Thanks for cleaning this up. It looks like us (powerpc) / me is the main offender here. My excuse is it was glibc folk who asked us to add all those new AT_ entries in the first place. > For the benefit of future maintainers, this patch collects the > relevant information in one place, documenting how the namespace > needs to be managed, and noting all the values currently in use. > > Maintaining a global list may result in some merge conflicts, but > AT_* values are not added frequently. I'm open to suggestions on > the best approach. Yeah I agree with Rich that having a global list would be best. That is the most reliable to make people think twice about adding new entries. > I also assume that values 38 and 39 may have been used for > historical purposes, such as an architecture that is no longer > supported. If they have definitely never been used for anything, > they could be removed from the "reserved" list. I don't know why we added the new entries starting at 40, maybe Ben remembers. Quite likely it was just an accident. I don't see any sign of 38 or 39 in glibc history. cheers
Re: [PATCH v2] mm: save two stranding bit in gfp_mask
On 05/16/2018 11:14 PM, Shakeel Butt wrote: > ___GFP_COLD and ___GFP_OTHER_NODE were removed but their bits were > stranded. Fill the gaps by moving the existing gfp masks around. > > Signed-off-by: Shakeel Butt > Suggested-by: Vlastimil Babka > Acked-by: Michal Hocko Yeah that's much smaller, thanks. Acked-by: Vlastimil Babka > --- > Changelog since v1: > - Moved couple of gfp masks instead of sliding all. > > include/linux/gfp.h | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 1a4582b44d32..036846fc00a6 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -24,6 +24,7 @@ struct vm_area_struct; > #define ___GFP_HIGH 0x20u > #define ___GFP_IO0x40u > #define ___GFP_FS0x80u > +#define ___GFP_WRITE 0x100u > #define ___GFP_NOWARN0x200u > #define ___GFP_RETRY_MAYFAIL 0x400u > #define ___GFP_NOFAIL0x800u > @@ -36,11 +37,10 @@ struct vm_area_struct; > #define ___GFP_THISNODE 0x4u > #define ___GFP_ATOMIC0x8u > #define ___GFP_ACCOUNT 0x10u > -#define ___GFP_DIRECT_RECLAIM0x40u > -#define ___GFP_WRITE 0x80u > -#define ___GFP_KSWAPD_RECLAIM0x100u > +#define ___GFP_DIRECT_RECLAIM0x20u > +#define ___GFP_KSWAPD_RECLAIM0x40u > #ifdef CONFIG_LOCKDEP > -#define ___GFP_NOLOCKDEP 0x200u > +#define ___GFP_NOLOCKDEP 0x80u > #else > #define ___GFP_NOLOCKDEP 0 > #endif > @@ -205,7 +205,7 @@ struct vm_area_struct; > #define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP) > > /* Room for N __GFP_FOO bits */ > -#define __GFP_BITS_SHIFT (25 + IS_ENABLED(CONFIG_LOCKDEP)) > +#define __GFP_BITS_SHIFT (23 + IS_ENABLED(CONFIG_LOCKDEP)) > #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1)) > > /* >
Re: [PATCH v4 17/31] kconfig: add 'filename' and 'lineno' built-in variables
On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada
wrote:
> The special variables, $(filename) and $(lineno), are expanded to a
> file name and its line number being parsed, respectively.
>
> Suggested-by: Randy Dunlap
> Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
-Kees
> ---
>
> Changes in v4:
> - Newly added
>
> Changes in v3: None
> Changes in v2: None
>
> scripts/kconfig/preprocess.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
> index 88844a7..c39e30e 100644
> --- a/scripts/kconfig/preprocess.c
> +++ b/scripts/kconfig/preprocess.c
> @@ -111,6 +111,11 @@ static char *do_error(int argc, char *argv[], int
> old_argc, char *old_argv[])
> return NULL;
> }
>
> +static char *do_filename(int argc, char *argv[], int old_argc, char
> *old_argv[])
> +{
> + return xstrdup(current_file->name);
> +}
> +
> static char *do_if(int argc, char *argv[], int old_argc, char *old_argv[])
> {
> char *cond, *p, *res;
> @@ -144,6 +149,15 @@ static char *do_info(int argc, char *argv[], int
> old_argc, char *old_argv[])
> return xstrdup("");
> }
>
> +static char *do_lineno(int argc, char *argv[], int old_argc, char
> *old_argv[])
> +{
> + char buf[16];
> +
> + sprintf(buf, "%d", yylineno);
> +
> + return xstrdup(buf);
> +}
> +
> static char *do_shell(int argc, char *argv[], int old_argc, char *old_argv[])
> {
> FILE *p;
> @@ -194,8 +208,10 @@ static char *do_warning(int argc, char *argv[], int
> old_argc, char *old_argv[])
> static const struct function function_table[] = {
> /* Name MIN MAX EXP?Function */
> { "error", 1, 1, true, do_error },
> + { "filename", 0, 0, false, do_filename },
> { "if", 2, 3, false, do_if },
> { "info", 1, 1, true, do_info },
> + { "lineno", 0, 0, false, do_lineno },
> { "shell", 1, 1, true, do_shell },
> { "warning",1, 1, true, do_warning },
> };
> --
> 2.7.4
>
--
Kees Cook
Pixel Security
RE: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
Hi, > -Original Message- > From: Peter Ujfalusi [mailto:peter.ujfal...@ti.com] > Sent: Tuesday, April 24, 2018 3:21 PM > To: Vinod Koul > Cc: Lars-Peter Clausen ; Radhey Shyam Pandey > ; michal.si...@xilinx.com; linux- > ker...@vger.kernel.org; dmaeng...@vger.kernel.org; > dan.j.willi...@intel.com; Appana Durga Kedareswara Rao > ; linux-arm-ker...@lists.infradead.org > Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words > to netdev dma client > > On 2018-04-24 06:55, Vinod Koul wrote: > > On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote: > >> > >> On 2018-04-18 16:06, Lars-Peter Clausen wrote: > Hrm, true, but it is hardly the metadata use case. It is more like > different DMA transfer type. > >>> > >>> When I look at this with my astronaut architect view from high high up > above > >>> I do not see a difference between metadata and multi-planar data. > >> > >> I tend to disagree. > > > > and we will love to hear more :) > > It is getting pretty off topic from the subject ;) and I'm sorry about that. > > Multi-planar data is _data_, the metadata is > parameters/commands/information on _how_ to use the data. > It is more like a replacement or extension of: > configure peripheral > send data > > to > > send data with configuration > > In both cases the same data is sent, but the configuration, > parametrization is 'simplified' to allow per packet changes. > > >>> Both split the data that is sent to the peripheral into multiple > >>> sub-streams, each carrying part of the data. I'm sure there are > >>> peripherals > >>> that interleave data and metadata on the same data stream. Similar to > how we > >>> have left and right channel interleaved in a audio stream. > >> > >> Slimbus, S/PDIF? > >> > >>> What about metadata that is not contiguous and split into multiple > segments. > >>> How do you handle passing a sgl to the metadata interface? And then it > >>> suddenly looks quite similar to the normal DMA descriptor interface. > >> > >> Well, the metadata is for the descriptor. The descriptor describe the > >> data transfer _and_ can convey additional information. Nothing is > >> interleaved, the data and the descriptor are different things. It is > >> more like TCP headers detached from the data (but pointing to it). > >> > >>> But maybe that's just one abstraction level to high. > >> > >> I understand your point, but at the end the metadata needs to end up in > >> the descriptor which is describing the data that is going to be moved. > >> > >> The descriptor is not sent as a separate DMA trasnfer, it is part of the > >> DMA transfer, it is handled internally by the DMA. > > > > That is bit confusing to me. I thought DMA was transparent to meta data and > > would blindly collect and transfer along with the descriptor. So at high > > level we are talking about two transfers (probably co-joined at hip and you > > want to call one transfer) > > At the end yes, both the descriptor and the data is going to be sent to > the other end. > > As a reference see [1] > > The metadata is not a separate entity, it is part of the descriptor > (Host Packet Descriptor - HPD). > Each transfer (packet) is described with a HPD. The HPD have optional > fields, like EPIB (Extended Packet Info Block), PSdata (Protocol > Specific data). > > When the DMA reads the HPD, is going to move the data described by the > HPD to the entry point (or from the entry point to memory), copies the > EPIB/PSdata from the HPD to a destination HPD. The other end will use > the destination HPD to know the size of the data and to get the metadata > from the descriptor. > > In essence every entity within the Multicore Navigator system have > pktdma, they all work in a similar way, but their capabilities might > differ. Our entry to this mesh is via the DMA. > > > but why can't we visualize this as just a DMA > > transfers. maybe you want to signal/attach to transfer, cant we do that with > > additional flag DMA_METADATA etc..? > > For the data we need to call dmaengine_prep_slave_* to create the > descriptor (HPD). The metadata needs to be present in the HPD, hence I > was thinking of the attach_metadata as per descriptor API. > > If separate dmaengine_prep_slave_* is used for allocating the HPD and > place the metadata in it then the consequent dmaengine_prep_slave_* call > must be for the data of the transfer and it is still unclear how the > prepare call would have any idea where to look for the HPD it needs to > update with the parameters for the data transfer. > > I guess the driver could store the HPD pointer in the channel data if > the prepare is called with DMA_METADATA and it would be mandatory that > the next prepare is for the data portion. The driver would pick the > pointer to the HPD we stored away and update the descriptor belonging to > different tx_desc. > > But if we are here, we could have a flag like DMA_DESCRIPTOR and let > client drivers to allocate the who
Re: [PATCH v4 15/31] kconfig: add 'info', 'warning', and 'error' built-in functions
On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada
wrote:
> Add 'info', 'warning', and 'error' functions as in Make.
>
> They print messages during parsing Kconfig files. 'error' will be
> useful to terminate the parsing immediately in fatal cases.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
-Kees
> ---
>
> Changes in v4:
> - Add 'error' function
>
> Changes in v3: None
> Changes in v2: None
>
> scripts/kconfig/preprocess.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
> index 47b32dc..591bcf7 100644
> --- a/scripts/kconfig/preprocess.c
> +++ b/scripts/kconfig/preprocess.c
> @@ -104,6 +104,20 @@ struct function {
> char *(*func)(int argc, char *argv[], int old_argc, char *old_argv[]);
> };
>
> +static char *do_error(int argc, char *argv[], int old_argc, char *old_argv[])
> +{
> + pperror("%s", argv[0]);
> +
> + return NULL;
> +}
> +
> +static char *do_info(int argc, char *argv[], int old_argc, char *old_argv[])
> +{
> + printf("%s\n", argv[0]);
> +
> + return xstrdup("");
> +}
> +
> static char *do_shell(int argc, char *argv[], int old_argc, char *old_argv[])
> {
> FILE *p;
> @@ -144,9 +158,19 @@ static char *do_shell(int argc, char *argv[], int
> old_argc, char *old_argv[])
> return xstrdup(buf);
> }
>
> +static char *do_warning(int argc, char *argv[], int old_argc, char
> *old_argv[])
> +{
> + fprintf(stderr, "%s:%d: %s\n", current_file->name, yylineno, argv[0]);
> +
> + return xstrdup("");
> +}
> +
> static const struct function function_table[] = {
> /* Name MIN MAX EXP?Function */
> + { "error", 1, 1, true, do_error },
> + { "info", 1, 1, true, do_info },
> { "shell", 1, 1, true, do_shell },
> + { "warning",1, 1, true, do_warning },
> };
>
> #define FUNCTION_MAX_ARGS 16
> --
> 2.7.4
>
--
Kees Cook
Pixel Security
Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup
On Thu, May 17, 2018 at 12:28:01AM -0500, Eric W. Biederman wrote:
> > struct pid_namespace *proc_pid_namespace(struct inode *inode)
> > {
> > // maybe warn on for s_magic not on procfs??
> > return inode->i_sb->s_fs_info;
> > }
>
> That should work. Ideally out of line for the proc_fs.h version.
> Basically it should be a cousin of PDE_DATA.
The version in Al's tree is inline and without the warning as
I didn't want to drag in the magic.h include. Please look at it for
additional comments, I can send incremental fixups if needed.
Re: [PATCH v4 19/31] Documentation: kconfig: document a new Kconfig macro language
On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada
wrote:
> Add a document for the macro language introduced to Kconfig.
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile. A number of kernel features require the
> compiler support. Enabling such features blindly in Kconfig ends up
> with a lot of nasty build-time testing in Makefiles. If a chosen
> feature turns out unsupported by the compiler, what the build system
> can do is either to disable it (silently!) or to forcibly break the
> build, despite Kconfig has let the user to enable it. By moving the
> compiler capability tests to Kconfig, features unsupported by the
> compiler will be hidden automatically.
>
> This change was strongly prompted by Linus Torvalds. You can find
> his suggestions [1] [2] in ML. The original idea was to add a new
> attribute with 'option shell=...', but I found more generalized text
> expansion would make Kconfig more powerful and lovely. The basic
> ideas are from Make, but there are some differences.
>
> [1]: https://lkml.org/lkml/2016/12/9/577
> [2]: https://lkml.org/lkml/2018/2/7/527
>
> Signed-off-by: Masahiro Yamada
(Added Randy, Jon, and linux-doc to CC for more review)
This should likely be written in .rst and linked to from the developer index...
https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#writing-documentation
As for the content, though:
Reviewed-by: Kees Cook
-Kees
> ---
>
> Changes in v4:
> - Update according to the syntax change
>
> Changes in v3:
> - Newly added
>
> Changes in v2: None
>
> Documentation/kbuild/kconfig-macro-language.txt | 252
>
> MAINTAINERS | 2 +-
> 2 files changed, 253 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..a8dc792
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,252 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell, $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency as explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable. A macro
> +variable is expanded "in place" to yield a text string that may then be
> +expanded further. To get the value of a variable, enclose the variable name
> in
> +$( ). The parentheses are required even for single-letter variable names; $X
> is
> +a syntax error. The curly brace form as in ${CC} is not supported either.
> +
> +There are two types of variables: simply expanded variables and recursively
> +expanded variables.
> +
> +A simply expanded variable is defined using the := assignment operator. Its
> +righthand side is expanded immediately upon reading the line from the Kconfig
> +file.
> +
> +A recursively expanded variable is defined using the = assignment operator.
> +Its righthand side is simply stored as the value of the variable without
> +expanding it in any way. Instead, the expansion is performed when the
> variable
> +is used.
> +
> +There is another type of assignment operator; += is used to append text to a
> +variable. The righthand side of += is expanded immediately if the lefthand
> +side was originally defined as a simple variable. Otherwise, its evaluation
> is
> +deferred.
> +
> +The variable reference can take parameters, in the following form:
> +
> + $(name,arg1,arg2,arg3)
> +
> +You can consider the parameterized reference as a function. (more precisely,
> +"user-defined function" in the contrast to "built-in function" listed below).
> +
> +Useful functions must be expanded w
Re: linux-next: build warning after merge of the vfs tree
On Thu, May 17, 2018 at 10:39:32AM +1000, Stephen Rothwell wrote: > Hi Al, > > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig) > produced this warning: > > drivers/isdn/gigaset/capi.c:2344:14: warning: 'gigaset_procinfo' defined but > not used [-Wunused-function] > static char *gigaset_procinfo(struct capi_ctr *ctr) The assignment for it was incorrectly removed. I'll send a set of fixes to Al.
Re: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
On Wed, 16 May 2018, Amelie DELAUNAY wrote: > > > On 05/16/2018 04:20 PM, Linus Walleij wrote: > > On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY > > wrote: > > > >> Indeed, stmfx has other functions than GPIO. But, after comments done > >> here: [1] and there: [2], it has been decided to move MFD parent/GPIO > >> child drivers into a single PINCTRL/GPIO driver because of the following > >> reasons: > >> - Other stmfx functions (IDD measurement and TouchScreen controller) are > >> not used on any of the boards using an stmfx and supported by Linux, so > >> no way to test these functions, and no need to maintain them while they > >> are not being used. > >> - But, in the case a new board will use more than GPIO function on > >> stmfx, the actual implementation allow to easily extract common init > >> part of stmfx and put it in an MFD driver. > >> > >> So I could remove gpio sub-node and put its contents in stmfx node and > >> keep single PINCTRL/GPIO driver for the time being. > >> Please advise, > > > > I would normally advice to use the right modeling from the start, create > > the MFD driver and spawn the devices from there. It is confusing > > if the layout of the driver(s) doesn't really match the layout of the > > hardware. > > > > I understand that it is a pain to write new MFD drivers to get your > > things going and it would be "nice to get this working really quick > > now" but in my experience it is better to do it right from the start. > > > > Hi Linus, > > Thanks for your advice. I understand the point. > So, the right modeling would be to: > - create an MFD driver with the common init part of stmfx > - remove all common init part of stmfx-pinctrl driver and keep only all > gpio/pinctrl functions. > > I will not develop the other stmfx functions (IDD measurement driver and > TouchScreen controller driver) because, as explained ealier, they are > not used on any of the boards using an stmfx and supported by Linux, so > no way to test these functions, and no need to maintain them while they > are not being used. > > Lee, are you OK with that ? I missed a lot of this conversation I think, but from what I've read, it sounds fine. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
linux-next: manual merge of the akpm tree with the vfs tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/vmalloc.c
between commits:
fddda2b7b521 ("proc: introduce proc_create_seq{,_data}")
44414d82cfe0 ("proc: introduce proc_create_seq_private")
from the vfs tree and patch:
"mm: use octal not symbolic permissions"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc mm/vmalloc.c
index 89efac3a020e,abf54a3e71e6..
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@@ -2738,14 -2738,25 +2738,14 @@@ static const struct seq_operations vmal
.show = s_show,
};
-static int vmalloc_open(struct inode *inode, struct file *file)
+static int __init proc_vmalloc_init(void)
{
if (IS_ENABLED(CONFIG_NUMA))
- proc_create_seq_private("vmallocinfo", S_IRUSR, NULL,
- return seq_open_private(file, &vmalloc_op,
- nr_node_ids * sizeof(unsigned int));
++ proc_create_seq_private("vmallocinfo", 0400, NULL,
+ &vmalloc_op,
+ nr_node_ids * sizeof(unsigned int), NULL);
else
- proc_create_seq("vmallocinfo", S_IRUSR, NULL, &vmalloc_op);
- return seq_open(file, &vmalloc_op);
-}
-
-static const struct file_operations proc_vmalloc_operations = {
- .open = vmalloc_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= seq_release_private,
-};
-
-static int __init proc_vmalloc_init(void)
-{
- proc_create("vmallocinfo", 0400, NULL, &proc_vmalloc_operations);
++ proc_create_seq("vmallocinfo", 0400, NULL, &vmalloc_op);
return 0;
}
module_init(proc_vmalloc_init);
pgpea3Lagh660.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers
On 05/17/2018 09:26 AM, Takashi Iwai wrote: On Tue, 15 May 2018 08:02:08 +0200, Oleksandr Andrushchenko wrote: On 05/15/2018 09:01 AM, Takashi Iwai wrote: On Tue, 15 May 2018 07:46:38 +0200, Oleksandr Andrushchenko wrote: On 05/14/2018 11:28 PM, Takashi Iwai wrote: On Mon, 14 May 2018 08:27:40 +0200, Oleksandr Andrushchenko wrote: --- /dev/null +++ b/sound/xen/xen_snd_front_shbuf.c @@ -0,0 +1,193 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT + +/* + * Xen para-virtual sound device + * + * Copyright (C) 2016-2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#include +#include + +#include "xen_snd_front_shbuf.h" Hm, with the local build test, I get the following error: CC [M] sound/xen/xen_snd_front_shbuf.o In file included from sound/xen/xen_snd_front_shbuf.c:11:0: ./include/xen/xen.h:18:8: error: unknown type name ‘bool’ extern bool xen_pvh; ^~~~ In file included from ./include/xen/interface/xen.h:30:0, from ./include/xen/xen.h:29, from sound/xen/xen_snd_front_shbuf.c:11: ./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type name ‘uint64_t’ DEFINE_GUEST_HANDLE(uint64_t); ^ Adding #include fixed the issue. Did you really test your patches with the latest Linus tree? My bad, it does build for ARM (which is my target), but also does need "#include " for x86 which I didn't build this time. Sorry about that. Do you want me to resend this single patch or you can make the change while applying? Yes, it's fine. Thank you FWIW, the patches are in topic/xen branch in sound.git tree, and I'll keep boiling for a while to see if any issues are caught by 0day bot. Thank you, hope everything goes well Takashi Thank you, Oleksandr
Re: [PATCH v4 27/31] kcov: test compiler capability in Kconfig and correct dependency
On Wed, May 16, 2018 at 11:17 PM, Masahiro Yamada wrote: > As Documentation/kbuild/kconfig-language.txt notes, 'select' should be > be used with care - it forces a lower limit of another symbol, ignoring > the dependency. Currently, KCOV can select GCC_PLUGINS even if arch > does not select HAVE_GCC_PLUGINS. This could cause the unmet direct > dependency. > > Now that Kconfig can test compiler capability, let's handle this in a > more sophisticated way. > > There are two ways to enable KCOV; use the compiler that natively > supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if > the compiler has ability to build GCC plugins. Hence, the correct > dependency for KCOV is: > > depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS > > You do not need to build the SANCOV plugin if the compiler already > supports -fsanitize-coverage=trace-pc. Hence, the select should be: > > select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC > > With this, GCC_PLUGIN_SANCOV is selected only when necessary, so > scripts/Makefile.gcc-plugins can be cleaner. > > I also cleaned up Kconfig and scripts/Makefile.kcov as well. > > Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook -Kees -- Kees Cook Pixel Security
[PATCH 2/2] perf script: Show symbol offsets by default
Since the ip shown for a symbol is now always a virtual address,
it becomes difficult to correlate this with objdump output and
determine the exact instruction address. So, we always show the
offset from the start of the symbol.
This can be verified on a powerpc64le system running Fedora 27
as follows:
# perf probe -a sys_write
# perf record -e probe:sys_write -g ~/test
Before applying this patch:
# perf script
test 9710 [013] 95614.332431: probe:sys_write: (c04025b0)
c04025b0 sys_write (/lib/modules/4.17.0-rc4+/build/vmlinux)
c000b9e0 system_call (/lib/modules/4.17.0-rc4+/build/vmlinux)
7fffb70d8234 __GI___libc_write (/usr/lib64/libc-2.26.so)
7fffb7052c74 _IO_file_write@@GLIBC_2.17 (/usr/lib64/libc-2.26.so)
5afc1818 [unknown] ([unknown])
7fffb7051a60 new_do_write (/usr/lib64/libc-2.26.so)
7fffb7054638 _IO_do_write@@GLIBC_2.17 (/usr/lib64/libc-2.26.so)
7fffb7054bbc _IO_file_overflow@@GLIBC_2.17
(/usr/lib64/libc-2.26.so)
7fffb7055a24 __overflow (/usr/lib64/libc-2.26.so)
7fffb7044548 _IO_puts (/usr/lib64/libc-2.26.so)
1440 main (/home/sandipan/test)
7fffb6fe36a0 generic_start_main.isra.0 (/usr/lib64/libc-2.26.so)
7fffb6fe3898 __libc_start_main (/usr/lib64/libc-2.26.so)
0 [unknown] ([unknown])
...
After applying this patch:
# perf script
test 9710 [013] 95614.332431: probe:sys_write: (c04025b0)
c04025b0 sys_write+0x10
(/lib/modules/4.17.0-rc4+/build/vmlinux)
c000b9e0 system_call+0x58
(/lib/modules/4.17.0-rc4+/build/vmlinux)
7fffb70d8234 __GI___libc_write+0x24 (/usr/lib64/libc-2.26.so)
7fffb7052c74 _IO_file_write@@GLIBC_2.17+0x44
(/usr/lib64/libc-2.26.so)
5afc1818 [unknown] ([unknown])
7fffb7051a60 new_do_write+0x90 (/usr/lib64/libc-2.26.so)
7fffb7054638 _IO_do_write@@GLIBC_2.17+0x38
(/usr/lib64/libc-2.26.so)
7fffb7054bbc _IO_file_overflow@@GLIBC_2.17+0x14c
(/usr/lib64/libc-2.26.so)
7fffb7055a24 __overflow+0x64 (/usr/lib64/libc-2.26.so)
7fffb7044548 _IO_puts+0x218 (/usr/lib64/libc-2.26.so)
1440 main+0x20 (/home/sandipan/test)
7fffb6fe36a0 generic_start_main.isra.0+0x140
(/usr/lib64/libc-2.26.so)
7fffb6fe3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
0 [unknown] ([unknown])
...
Signed-off-by: Sandipan Das
---
tools/perf/builtin-script.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index fa2c7a288750..cefc8813e91e 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -153,8 +153,8 @@ static struct {
.fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
- PERF_OUTPUT_SYM | PERF_OUTPUT_DSO |
- PERF_OUTPUT_PERIOD,
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD,
.invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
},
@@ -165,8 +165,9 @@ static struct {
.fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
- PERF_OUTPUT_SYM | PERF_OUTPUT_DSO |
- PERF_OUTPUT_PERIOD | PERF_OUTPUT_BPF_OUTPUT,
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD |
+ PERF_OUTPUT_BPF_OUTPUT,
.invalid_fields = PERF_OUTPUT_TRACE,
},
@@ -185,10 +186,10 @@ static struct {
.fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
- PERF_OUTPUT_SYM | PERF_OUTPUT_DSO |
- PERF_OUTPUT_PERIOD | PERF_OUTPUT_ADDR |
- PERF_OUTPUT_DATA_SRC | PERF_OUTPUT_WEIGHT |
- PERF_OUTPUT_PHYS_ADDR,
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD |
+ PERF_OUTPUT_ADDR | PERF_OUTPUT_DATA_SRC |
+ PERF_OUTPUT_WEIGHT | PERF_OUTPUT_PHYS_ADDR,
.invalid_fields = PERF_OUTPUT_T
[PATCH 1/2] perf script: Show virtual addresses instead of offsets
When perf data is recorded with the call-graph option enabled, the callchain shown by perf script shows the binary offsets of the symbols as the ip. This is incorrect for kernel symbols as the ip values are always off by a fixed offset depending on the architecture. If the offsets from the start of the symbols are printed, they are also incorrect for both kernel and userspace symbols. Without the call-graph option, the callchain shows the virtual addresses of the symbols rather than their binary offsets. The offsets printed in this case are also correct. This fixes the inconsistency in perf script's output. This can be verified on a powerpc64le system running Fedora 27 as follows: # cat /proc/kallsyms | grep sys_write ... c04025a0 T sys_write c04025a0 T __se_sys_write ... # perf probe -a sys_write Before applying this patch: # perf record -e probe:sys_write -g ~/test # perf script -F ip,sym,symoff 4125b0 sys_write+0x80008010 1b9e0 system_call+0x80008058 118234 __GI___libc_write+0xf52c0024 92c74 _IO_file_write@@GLIBC_2.17+0xf52c0044 5afbfd8a [unknown] 91a60 new_do_write+0xf52c0090 94638 _IO_do_write@@GLIBC_2.17+0xf52c0038 94bbc _IO_file_overflow@@GLIBC_2.17+0xf52c014c 95a24 __overflow+0xf52c0064 84548 _IO_puts+0xf52c0218 440 main+0xe020 236a0 generic_start_main.isra.0+0xf52c0140 23898 __libc_start_main+0xf52c00b8 0 [unknown] ... # perf record -e probe:sys_write ~/test # perf script -F ip,sym,symoff c04025b0 sys_write+0x10 ... After applying this patch: # perf record -e probe:sys_write -g ~/test # perf script -F ip,sym,symoff c04025b0 sys_write+0x10 c000b9e0 system_call+0x58 7fffb70d8234 __GI___libc_write+0x24 7fffb7052c74 _IO_file_write@@GLIBC_2.17+0x44 5afc1818 [unknown] 7fffb7051a60 new_do_write+0x90 7fffb7054638 _IO_do_write@@GLIBC_2.17+0x38 7fffb7054bbc _IO_file_overflow@@GLIBC_2.17+0x14c 7fffb7055a24 __overflow+0x64 7fffb7044548 _IO_puts+0x218 1440 main+0x20 7fffb6fe36a0 generic_start_main.isra.0+0x140 7fffb6fe3898 __libc_start_main+0xb8 0 [unknown] ... # perf record -e probe:sys_write ~/test # perf script -F ip,sym,symoff c04025b0 sys_write+0x10 ... Signed-off-by: Sandipan Das --- tools/perf/util/machine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c index 72a351613d85..7c777cb32806 100644 --- a/tools/perf/util/machine.c +++ b/tools/perf/util/machine.c @@ -1764,7 +1764,7 @@ static int add_callchain_ip(struct thread *thread, } srcline = callchain_srcline(al.map, al.sym, al.addr); - return callchain_cursor_append(cursor, al.addr, al.map, al.sym, + return callchain_cursor_append(cursor, ip, al.map, al.sym, branch, flags, nr_loop_iter, iter_cycles, branch_from, srcline); } -- 2.14.3
Re: [PATCH v4 29/31] gcc-plugins: test plugin support in Kconfig and clean up Makefile
On Wed, May 16, 2018 at 11:17 PM, Masahiro Yamada wrote: > Run scripts/gcc-plugin.sh from Kconfig so that users can enable > GCC_PLUGINS only when the compiler supports building plugins. > > Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain > the compiler (g++ or gcc) used for building plugins, or empty > if the plugin can not be supported at all. > > This allows us to remove all ugly testing in Makefile.gcc-plugins. > > Signed-off-by: Masahiro Yamada Acked-by: Kees Cook -Kees -- Kees Cook Pixel Security
Re: [PATCH v4 28/31] gcc-plugins: move GCC version check for PowerPC to Kconfig
On Wed, May 16, 2018 at 11:17 PM, Masahiro Yamada wrote: > For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the > version check to Kconfig so that the GCC plugin menus will be hidden > if an older compiler is in use. > > Signed-off-by: Masahiro Yamada > Acked-by: Andrew Donnellan Reviewed-by: Kees Cook -Kees -- Kees Cook Pixel Security
[PATCH v4 08/31] kconfig: add 'shell' built-in function
This accepts a single command to execute. It returns the standard
output from it.
[Example code]
config HELLO
string
default "$(shell,echo hello world)"
config Y
def_bool $(shell,echo y)
[Result]
$ make -s alldefconfig && tail -n 2 .config
CONFIG_HELLO="hello world"
CONFIG_Y=y
Caveat:
Like environments, functions are expanded in the lexer. You cannot
pass symbols to function arguments. This is a limitation to simplify
the implementation. I want to avoid the dynamic function evaluation,
which would introduce much more complexity.
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Accept only one argument to simplify the implementation
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 5be28ec..d8c5f60 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -104,8 +104,49 @@ struct function {
char *(*func)(int argc, char *argv[], int old_argc, char *old_argv[]);
};
+static char *do_shell(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ FILE *p;
+ char buf[256];
+ char *cmd;
+ size_t nread;
+ int i;
+
+ cmd = argv[0];
+
+ p = popen(cmd, "r");
+ if (!p) {
+ perror(cmd);
+ exit(1);
+ }
+
+ nread = fread(buf, 1, sizeof(buf), p);
+ if (nread == sizeof(buf))
+ nread--;
+
+ /* remove trailing new lines */
+ while (buf[nread - 1] == '\n')
+ nread--;
+
+ buf[nread] = 0;
+
+ /* replace a new line with a space */
+ for (i = 0; i < nread; i++) {
+ if (buf[i] == '\n')
+ buf[i] = ' ';
+ }
+
+ if (pclose(p) == -1) {
+ perror(cmd);
+ exit(1);
+ }
+
+ return xstrdup(buf);
+}
+
static const struct function function_table[] = {
/* Name MIN MAX EXP?Function */
+ { "shell", 1, 1, true, do_shell },
};
#define FUNCTION_MAX_ARGS 16
--
2.7.4
Re: [PATCH v4 06/31] kconfig: remove sym_expand_string_value()
On Wed, May 16, 2018 at 11:16 PM, Masahiro Yamada wrote: > There is no more caller of sym_expand_string_value(). > > Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Easy to review! :) -Kees -- Kees Cook Pixel Security
Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration
On 17 May 2018 at 14:11, Vinod wrote:
> On 17-05-18, 14:02, Baolin Wang wrote:
>> Hi Vinod,
>>
>> On 17 May 2018 at 13:14, Vinod wrote:
>> > On 11-05-18, 21:06, Baolin Wang wrote:
>> >> +struct sprd_dma_config {
>> >> + struct dma_slave_config cfg;
>> >> + u32 block_len;
>> >> + u32 transcation_len;
>> >
>> > /s/transcation/transaction
>>
>> OK.
>>
>> >
>> > now in code I see block_len and this filled by len which is sg_dma_len()?
>> > So why two varibales when you are using only one.
>>
>> Like I explained before, we have transaction transfer, block transfer
>> and fragment transfer, and we should set the length for each transfer.
>> In future, we we will use these two variables in cyclic mode, but for
>> prep_sg, we just make them equal to
>
> Please add them when you have use for it. Sorry linux kernel is not a place
> for
> dumping future use work
We now use them, since we have registers to configure, and we just set
the same values for them now.
>>
>> >
>> > Second, you are storing parameters programmed thru _prep call into
>> > _dma_config. That is not correct.
>> >
>> > We use these to store channel parameters and NOT transaction parameters
>> > which
>> > would differ with each txn. No wonder you can only support only 1 txn :)
>>
>> Fine, we can remove block_len/transcation_len from 'struct
>> sprd_dma_config'. Any other issues for the 'struct sprd_dma_config'?
>
> Yes see the comments on prep_
OK.
>>
>> >
>> > Lastly, if these are same values why not use src/dstn_max_burst?
>>
>> The fragment length will be filled by src/dstn_max_burst,so we can not
>> use it again.
>>
>> >
>> >> +static enum sprd_dma_datawidth
>> >> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth)
>> >> +{
>> >> + switch (buswidth) {
>> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> >> + return ffs(buswidth) - 1;
>> >> + default:
>> >> + return SPRD_DMA_DATAWIDTH_4_BYTES;
>> >
>> > Does default make sense, should we error out?
>>
>> Not one error, maybe we can give some warning information.
>
> well client programmed a wrong value, so I expect this to error out.
OK.
>
>>
>> >
>> >> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth)
>> >> +{
>> >> + switch (buswidth) {
>> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> >> + return buswidth;
>> >> +
>> >> + default:
>> >> + return SPRD_DMA_DWORD_STEP;
>> >
>> > Does default make sense, should we error out?
>>
>> Ditto.
>>
>> >
>> >> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc
>> >> *sdesc,
>> >> +dma_addr_t src, dma_addr_t dst,
>> >> +struct sprd_dma_config *slave_cfg)
>> >> +{
>> >> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
>> >> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
>> >> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
>> >> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0;
>> >> + u32 src_datawidth, dst_datawidth, temp;
>> >> +
>> >> + if (slave_cfg->cfg.slave_id)
>> >> + schan->dev_id = slave_cfg->cfg.slave_id;
>> >> +
>> >> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET;
>> >> +
>> >> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK;
>> >> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) &
>> >> SPRD_DMA_HIGH_ADDR_MASK;
>> >> + hw->wrap_ptr = temp;
>> >> +
>> >> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK;
>> >> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) &
>> >> SPRD_DMA_HIGH_ADDR_MASK;
>> >> + hw->wrap_to = temp;
>> >> +
>> >> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK;
>> >> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK;
>> >> +
>> >> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0)
>> >> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) {
>> >
>> > this check doesnt seem right to me, what are you trying here?
>>
>> This is SPRD DMA internal feature: address-fix transfer. If the src
>> step and dst step both are 0 or both are not 0, that means we can not
>> enable the fix mode.
>> If one is 0 and another one is not, we can enable the fix mode.
>
> A comment here would help explain this :)
Sure.
>>
>> >
>> >> + fix_en = 0;
>> >> + } else {
>> >> + fix_en = 1;
>> >> + if (slave_cfg->src_step)
>> >> + fix_mode = 1;
>> >> + else
>> >> + fix_mode = 0;
>> >> + }
>> >> +
>> >> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) {
>> >> + wrap_en = 1;
>> >> + if (slave_cfg->wrap_to == src) {
>> >> + wrap_mode = 0;
>> >> +
[PATCH v4 06/31] kconfig: remove sym_expand_string_value()
There is no more caller of sym_expand_string_value().
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 1 -
scripts/kconfig/symbol.c| 53 -
2 files changed, 54 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 9f465fe..c46929f 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -31,7 +31,6 @@ extern struct symbol * symbol_hash[SYMBOL_HASHSIZE];
struct symbol * sym_lookup(const char *name, int flags);
struct symbol * sym_find(const char *name);
-char *sym_expand_string_value(const char *in);
const char * sym_escape_string_value(const char *in);
struct symbol ** sym_re_search(const char *pattern);
const char * sym_type_name(enum symbol_type type);
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 2460648..7c9a88e 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -879,59 +879,6 @@ struct symbol *sym_find(const char *name)
return symbol;
}
-/*
- * Expand symbol's names embedded in the string given in argument. Symbols'
- * name to be expanded shall be prefixed by a '$'. Unknown symbol expands to
- * the empty string.
- */
-char *sym_expand_string_value(const char *in)
-{
- const char *src;
- char *res;
- size_t reslen;
-
- /*
-* Note: 'in' might come from a token that's about to be
-* freed, so make sure to always allocate a new string
-*/
- reslen = strlen(in) + 1;
- res = xmalloc(reslen);
- res[0] = '\0';
-
- while ((src = strchr(in, '$'))) {
- char *p, name[SYMBOL_MAXLENGTH];
- const char *symval = "";
- struct symbol *sym;
- size_t newlen;
-
- strncat(res, in, src - in);
- src++;
-
- p = name;
- while (isalnum(*src) || *src == '_')
- *p++ = *src++;
- *p = '\0';
-
- sym = sym_find(name);
- if (sym != NULL) {
- sym_calc_value(sym);
- symval = sym_get_string_value(sym);
- }
-
- newlen = strlen(res) + strlen(symval) + strlen(src) + 1;
- if (newlen > reslen) {
- reslen = newlen;
- res = xrealloc(res, reslen);
- }
-
- strcat(res, symval);
- in = src;
- }
- strcat(res, in);
-
- return res;
-}
-
const char *sym_escape_string_value(const char *in)
{
const char *p;
--
2.7.4
[PATCH v4 04/31] kconfig: remove string expansion in file_lookup()
There are two callers of file_lookup(), but there is no more reason
to expand the given path.
[1] zconf_initscan()
This is used to open the first Kconfig. sym_expand_string_value()
has never been used in a useful way here; before opening the first
Kconfig file, obviously there is no symbol to expand. If you use
expand_string_value() instead, environments in KBUILD_KCONFIG would
be expanded, but I do not see practical benefits for that.
[2] zconf_nextfile()
This is used to open the next file from 'source' statement.
Symbols in the path like "arch/$SRCARCH/Kconfig" needed expanding,
but it was replaced with the direct environment expansion. The
environment has already been expanded before the token is passed
to the parser.
By the way, file_lookup() was already buggy; it expanded a given path,
but it used the path before expansion for look-up:
if (!strcmp(name, file->name)) {
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Simplify the patch. Just remove text expansion.
scripts/kconfig/util.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/scripts/kconfig/util.c b/scripts/kconfig/util.c
index 807147e..790967df 100644
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -14,18 +14,16 @@
struct file *file_lookup(const char *name)
{
struct file *file;
- char *file_name = sym_expand_string_value(name);
for (file = file_list; file; file = file->next) {
if (!strcmp(name, file->name)) {
- free(file_name);
return file;
}
}
file = xmalloc(sizeof(*file));
memset(file, 0, sizeof(*file));
- file->name = file_name;
+ file->name = xstrdup(name);
file->next = file_list;
file_list = file;
return file;
--
2.7.4
Re: [PATCH v4 30/31] gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
On Wed, May 16, 2018 at 11:17 PM, Masahiro Yamada
wrote:
> Now that the compiler's plugin support is checked in Kconfig,
> all{yes,mod}config will not be bothered.
>
> Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.
>
> 'depends on !COMPILE_TEST' for the following three are still kept:
> GCC_PLUGIN_CYC_COMPLEXITY
> GCC_PLUGIN_STRUCTLEAK_VERBOSE
> GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
>
> Kees said to do so because the first two are too noisy, and the last
> one would reduce the compile test coverage. I commented the reasons
> in arch/Kconfig.
>
> Signed-off-by: Masahiro Yamada
I'm really looking forward to these being enabled for COMPILE_TEST. :)
Acked-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
[PATCH v4 10/31] kconfig: begin PARAM state only when seeing a command keyword
Currently, any statement line starts with a keyword with TF_COMMAND
flag. So, the following three lines are dead code.
alloc_string(yytext, yyleng);
zconflval.string = text;
return T_WORD;
If a T_WORD token is returned in this context, it will cause syntax
error in the parser anyway.
The next commit will support the assignment statement where a line
starts with an arbitrary identifier. So, I want the lexer to switch
to the PARAM state only when it sees a command keyword.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- Newly added
Changes in v2: None
scripts/kconfig/zconf.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 9dc5fe3..5e53348 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -102,10 +102,10 @@ n [A-Za-z0-9_-]
{
{n}+{
const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
- BEGIN(PARAM);
current_pos.file = current_file;
current_pos.lineno = yylineno;
if (id && id->flags & TF_COMMAND) {
+ BEGIN(PARAM);
yylval.id = id;
return id->token;
}
--
2.7.4
[PATCH v3 0/4] Add basic support for Mediatek MT8183 SoC
MT8183 is a SoC based on 64bit ARMv8 architecture. It contains 4 CA53 and 4 CA73 cores. MT8183 share many HW IP with MT65xx series. This patchset was tested on MT8183 evaluation board, and boot to shell ok. This series contains document bindings, device tree including interrupt, uart. Change in v3: 1. Fill out GICC, GICH, GICV regions 2. Update Copyright to 2018 Change in v2: 1. Split dt-bindings into different patches 2. Correct bindings for supported SoCs (mtk-uart.txt) Ben Ho (1): arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile Erin Lo (3): dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183 dt-bindings: serial: Add compatible for Mediatek MT8183 Documentation/devicetree/bindings/arm/mediatek.txt | 4 + .../interrupt-controller/mediatek,sysirq.txt | 1 + .../devicetree/bindings/serial/mtk-uart.txt| 1 + arch/arm64/boot/dts/mediatek/Makefile | 1 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts| 31 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 182 + 6 files changed, 220 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi -- 1.9.1
[PATCH v4 07/31] kconfig: add built-in function support
This commit adds a new concept 'function' to do more text processing
in Kconfig.
A function call looks like this:
$(function,arg1,arg2,arg3,...)
This commit adds the basic infrastructure to expand functions.
Change the text expansion helpers to take arguments.
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Error out if arguments more than FUNCTION_MAX_ARGS are passed
- Use a comma as a delimiter between the function name and the
first argument
- Check the number of arguments accepted by each function
- Support delayed expansion of arguments.
This will be needed to implement 'if' function
Changes in v3:
- Split base infrastructure and 'shell' function
into separate patches.
Changes in v2:
- Use 'shell' for getting stdout from the comment.
It was 'shell-stdout' in the previous version.
- Simplify the implementation since the expansion has been moved to
lexer.
scripts/kconfig/preprocess.c | 168 ---
1 file changed, 159 insertions(+), 9 deletions(-)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 1bf506c..5be28ec 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -3,12 +3,17 @@
// Copyright (C) 2018 Masahiro Yamada
#include
+#include
#include
#include
#include
#include "list.h"
+#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
+
+static char *expand_string_with_args(const char *in, int argc, char *argv[]);
+
static void __attribute__((noreturn)) pperror(const char *format, ...)
{
va_list ap;
@@ -88,9 +93,85 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
}
}
-static char *eval_clause(const char *in)
+/*
+ * Built-in functions
+ */
+struct function {
+ const char *name;
+ unsigned int min_args;
+ unsigned int max_args;
+ bool expand_args;
+ char *(*func)(int argc, char *argv[], int old_argc, char *old_argv[]);
+};
+
+static const struct function function_table[] = {
+ /* Name MIN MAX EXP?Function */
+};
+
+#define FUNCTION_MAX_ARGS 16
+
+static char *function_expand_arg_and_call(char *(*func)(int argc, char *argv[],
+ int old_argc,
+ char *old_argv[]),
+ int argc, char *argv[],
+ int old_argc, char *old_argv[])
+{
+ char *expanded_argv[FUNCTION_MAX_ARGS], *res;
+ int i;
+
+ for (i = 0; i < argc; i++)
+ expanded_argv[i] = expand_string_with_args(argv[i],
+ old_argc, old_argv);
+
+ res = func(argc, expanded_argv, 0, NULL);
+
+ for (i = 0; i < argc; i++)
+ free(expanded_argv[i]);
+
+ return res;
+}
+
+static char *function_call(const char *name, int argc, char *argv[],
+ int old_argc, char *old_argv[])
+{
+ const struct function *f;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(function_table); i++) {
+ f = &function_table[i];
+ if (strcmp(f->name, name))
+ continue;
+
+ if (argc < f->min_args)
+ pperror("too few function arguments passed to '%s'",
+ name);
+
+ if (argc > f->max_args)
+ pperror("too many function arguments passed to '%s'",
+ name);
+
+ if (f->expand_args)
+ return function_expand_arg_and_call(f->func, argc, argv,
+ old_argc, old_argv);
+ return f->func(argc, argv, old_argc, old_argv);
+ }
+
+ return NULL;
+}
+
+/*
+ * Evaluate a clause with arguments. argc/argv are arguments from the upper
+ * function call.
+ *
+ * Returned string must be freed when done
+ */
+static char *eval_clause(const char *in, int argc, char *argv[])
{
- char *res, *name;
+ char *tmp, *prev, *p, *res, *name;
+ int new_argc = 0;
+ char *new_argv[FUNCTION_MAX_ARGS];
+ int nest = 0;
+ int i;
/*
* Returns an empty string because '$()' should be evaluated
@@ -99,10 +180,69 @@ static char *eval_clause(const char *in)
if (!*in)
return xstrdup("");
- name = expand_string(in);
+ tmp = xstrdup(in);
+
+ prev = p = tmp;
+
+ /*
+* Split into tokens
+* The function name and arguments are separated by a comma.
+* For example, if the function call is like this:
+* $(foo,abc,$(x),$(y))
+*
+* The input string for this helper should be:
+* foo,abc,$(x),$(y)
+*
+* and split into:
+* new_argv[0] = 'foo'
+* new_argv[1] =
[PATCH v4 02/31] kbuild: remove CONFIG_CROSS_COMPILE support
Kbuild provides a couple of ways to specify CROSS_COMPILE: [1] Command line [2] Environment [3] arch/*/Makefile (only some architectures) [4] CONFIG_CROSS_COMPILE [4] is problematic for the compiler capability tests in Kconfig. CONFIG_CROSS_COMPILE allows users to change the compiler prefix from 'make menuconfig', etc. It means, the compiler options would have to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed. To avoid complexity and performance issues, I'd like to evaluate the shell commands statically, i.e. only parsing Kconfig files. I guess the majority is [1] or [2]. Currently, there are only 5 defconfig files that specify CONFIG_CROSS_COMPILE. arch/arm/configs/lpc18xx_defconfig arch/hexagon/configs/comet_defconfig arch/nds32/configs/defconfig arch/openrisc/configs/or1ksim_defconfig arch/openrisc/configs/simple_smp_defconfig Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v4: None Changes in v3: None Changes in v2: None Makefile | 3 --- init/Kconfig | 9 - 2 files changed, 12 deletions(-) diff --git a/Makefile b/Makefile index e78f73f..01b2211 100644 --- a/Makefile +++ b/Makefile @@ -316,12 +316,9 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ # CROSS_COMPILE can be set on the command line # make CROSS_COMPILE=ia64-linux- # Alternatively CROSS_COMPILE can be set in the environment. -# A third alternative is to store a setting in .config so that plain -# "make" in the configured kernel build directory always uses that. # Default value for CROSS_COMPILE is not to prefix executables # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile ARCH ?= $(SUBARCH) -CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%) # Architecture as present in compile.h UTS_MACHINE:= $(ARCH) diff --git a/init/Kconfig b/init/Kconfig index f013afc..4537962 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -54,15 +54,6 @@ config INIT_ENV_ARG_LIMIT Maximum of each of the number of arguments and environment variables passed to init from the kernel command line. - -config CROSS_COMPILE - string "Cross-compiler tool prefix" - help - Same as running 'make CROSS_COMPILE=prefix-' but stored for - default make runs in this kernel build directory. You don't - need to set this unless you want the configured kernel build - directory to select the cross-compiler automatically. - config COMPILE_TEST bool "Compile also drivers which will not load" depends on !UML -- 2.7.4
[PATCH v4 03/31] kconfig: reference environment variables directly and remove 'option env='
To get access to environment variables, Kconfig needs to define a symbol using "option env=" syntax. It is tedious to add a symbol entry for each environment variable given that we need to define much more such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability in Kconfig. Adding '$' for symbol references is grammatically inconsistent. Looking at the code, the symbols prefixed with 'S' are expanded by: - conf_expand_value() This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list' - sym_expand_string_value() This is used to expand strings in 'source' and 'mainmenu' All of them are fixed values independent of user configuration. So, they can be changed into the direct expansion instead of symbols. This change makes the code much cleaner. The bounce symbols 'SRCARCH', 'ARCH', 'SUBARCH', 'KERNELVERSION' are gone. sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE' should be replaced with an environment variable. ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced without '$' prefix. The new syntax is addicted by Make. The variable reference needs parentheses, like $(FOO), but you can omit them for single-letter variables, like $F. Yet, in Makefiles, people tend to use the parenthetical form for consistency / clarification. At this moment, only the environment variable is supported, but I will extend the concept of 'variable' later on. The variables are expanded in the lexer so we can simplify the token handling on the parser side. For example, the following code works. [Example code] config MY_TOOLCHAIN_LIST string default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)" [Result] $ make -s alldefconfig && tail -n 1 .config CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E" Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v4: - Enclose ARCH in conf_defname - Drop single-letter support Changes in v3: - Reimplement - Variable reference need parentheses except single-letter variable Changes in v2: - Move the string expansion to the lexer phase. - Split environment helpers to env.c Documentation/kbuild/kconfig-language.txt | 8 - Kconfig | 8 +- Makefile | 3 +- arch/sh/Kconfig | 4 +- arch/sparc/Kconfig| 4 +- arch/um/Kconfig.common| 4 - arch/x86/Kconfig | 4 +- arch/x86/um/Kconfig | 6 +- init/Kconfig | 16 +- scripts/kconfig/confdata.c| 33 +--- scripts/kconfig/kconf_id.c| 1 - scripts/kconfig/lkc.h | 4 - scripts/kconfig/lkc_proto.h | 6 + scripts/kconfig/menu.c| 3 - scripts/kconfig/preprocess.c | 247 ++ scripts/kconfig/symbol.c | 56 --- scripts/kconfig/util.c| 18 +-- scripts/kconfig/zconf.l | 67 +++- scripts/kconfig/zconf.y | 2 +- 19 files changed, 340 insertions(+), 154 deletions(-) create mode 100644 scripts/kconfig/preprocess.c diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index f5b9493..0e966e8 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -198,14 +198,6 @@ applicable everywhere (see syntax). enables the third modular state for all config symbols. At most one symbol may have the "modules" option set. - - "env"= -This imports the environment variable into Kconfig. It behaves like -a default, except that the value comes from the environment, this -also means that the behaviour when mixing it with normal defaults is -undefined at this point. The symbol is currently not exported back -to the build environment (if this is desired, it can be done via -another symbol). - - "allnoconfig_y" This declares the symbol as one that should have the value y when using "allnoconfig". Used for symbols that hide other symbols. diff --git a/Kconfig b/Kconfig index 8c4c1cb..4af1b42 100644 --- a/Kconfig +++ b/Kconfig @@ -3,10 +3,6 @@ # For a description of the syntax of this configuration file, # see Documentation/kbuild/kconfig-language.txt. # -mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration" +mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration" -config SRCARCH - string - option env="SRCARCH" - -source "arch/$SRCARCH/Kconfig" +source "arch/$(SRCARCH)/Kconfig" diff --git a/Makefile b/Makefile index 01b2211..c6278e6 100644 --- a/Makefile +++ b/Makefile @@ -284,7 +284,8 @@ include scripts/Kbuild.include # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.r
Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers
On Tue, 15 May 2018 08:02:08 +0200, Oleksandr Andrushchenko wrote: > > On 05/15/2018 09:01 AM, Takashi Iwai wrote: > > On Tue, 15 May 2018 07:46:38 +0200, > > Oleksandr Andrushchenko wrote: > >> On 05/14/2018 11:28 PM, Takashi Iwai wrote: > >>> On Mon, 14 May 2018 08:27:40 +0200, > >>> Oleksandr Andrushchenko wrote: > --- /dev/null > +++ b/sound/xen/xen_snd_front_shbuf.c > @@ -0,0 +1,193 @@ > +// SPDX-License-Identifier: GPL-2.0 OR MIT > + > +/* > + * Xen para-virtual sound device > + * > + * Copyright (C) 2016-2018 EPAM Systems Inc. > + * > + * Author: Oleksandr Andrushchenko > + */ > + > +#include > +#include > + > +#include "xen_snd_front_shbuf.h" > >>> Hm, with the local build test, I get the following error: > >>> > >>> CC [M] sound/xen/xen_snd_front_shbuf.o > >>> In file included from sound/xen/xen_snd_front_shbuf.c:11:0: > >>> ./include/xen/xen.h:18:8: error: unknown type name ‘bool’ > >>> extern bool xen_pvh; > >>> ^~~~ > >>> In file included from ./include/xen/interface/xen.h:30:0, > >>> from ./include/xen/xen.h:29, > >>> from sound/xen/xen_snd_front_shbuf.c:11: > >>> ./arch/x86/include/asm/xen/interface.h:92:21: error: unknown type > >>> name ‘uint64_t’ > >>> DEFINE_GUEST_HANDLE(uint64_t); > >>> ^ > >>> > >>> Adding #include fixed the issue. > >>> > >>> Did you really test your patches with the latest Linus tree? > >> My bad, it does build for ARM (which is my target), but also does > >> need "#include " for x86 which I didn't build this time. > >> Sorry about that. > >> > >> Do you want me to resend this single patch or you can make the change > >> while applying? > > Yes, it's fine. > Thank you FWIW, the patches are in topic/xen branch in sound.git tree, and I'll keep boiling for a while to see if any issues are caught by 0day bot. Takashi
Re: [PATCH v4 23/31] stack-protector: test compiler capability in Kconfig and drop AUTO mode
On Wed, May 16, 2018 at 11:17 PM, Masahiro Yamada
wrote:
> Move the test for -fstack-protector(-strong) option to Kconfig.
>
> If the compiler does not support the option, the corresponding menu
> is automatically hidden. If STRONG is not supported, it will fall
> back to REGULAR. If REGULAR is not supported, it will be disabled.
> This means, AUTO is implicitly handled by the dependency solver of
> Kconfig, hence removed.
>
> I also turned the 'choice' into only two boolean symbols. The use of
> 'choice' is not a good idea here, because all of all{yes,mod,no}config
> would choose the first visible value, while we want allnoconfig to
> disable as many features as possible.
>
> X86 has additional shell scripts in case the compiler supports those
> options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
> to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
> to make it work correctly.
>
> Signed-off-by: Masahiro Yamada
Thanks!
Acked-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
[PATCH v4 01/31] kbuild: remove kbuild cache
The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).
However, this turned out not so clever as I had first expected.
Actually, it is problematic. For example, "$(CC) -print-file-name"
is cached. If the compiler is updated, the stale search path causes
build error, which is difficult to figure out. Another problem
scenario is cache files could be touched while install targets are
running under the root permission. We can patch them if desired,
but the build infrastructure is getting uglier and uglier.
Now, we are going to move compiler flag tests to the configuration
phase. If this is completed, the result of compiler tests will be
naturally cached in the .config file. We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.
To start this work with a cleaner code base, remove the kbuild
cache first.
Revert the following commits:
Commit 9a234a2e3843 ("kbuild: create directory for make cache only when
necessary")
Commit e17c400ae194 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130ed ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b21c ("kbuild: Add a cache for generated variables")
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Makefile | 5 +--
scripts/Kbuild.include | 101 +++--
2 files changed, 16 insertions(+), 90 deletions(-)
diff --git a/Makefile b/Makefile
index ba3106b..e78f73f 100644
--- a/Makefile
+++ b/Makefile
@@ -501,7 +501,7 @@ RETPOLINE_CFLAGS := $(call
cc-option,$(RETPOLINE_CFLAGS_GCC),$(call cc-option,$(
export RETPOLINE_CFLAGS
# check for 'asm goto'
-ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)
$(KBUILD_CFLAGS)), y)
+ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)
$(KBUILD_CFLAGS)), y)
CC_HAVE_ASM_GOTO := 1
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
@@ -804,7 +804,7 @@ KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
# arch Makefile may override CC so keep this after arch Makefile is included
-NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
-print-file-name=include)
+NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
CHECKFLAGS += $(NOSTDINC_FLAGS)
# warn about C99 declaration after statement
@@ -1622,7 +1622,6 @@ clean: $(clean-dirs)
-o -name '*.asn1.[ch]' \
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
- -o -name .cache.mk \
-o -name '*.c.[012]*.*' \
-o -name '*.ll' \
-o -name '*.gcno' \) -type f -print | xargs rm -f
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 50cee53..925a851 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -8,8 +8,6 @@ squote := '
empty :=
space := $(empty) $(empty)
space_escape := _-_SPACE_-_
-right_paren := )
-left_paren := (
pound := \#
###
@@ -83,71 +81,6 @@ cc-cross-prefix = \
echo $(c);\
fi)))
-# Tools for caching Makefile variables that are "expensive" to compute.
-#
-# Here we want to help deal with variables that take a long time to compute
-# by making it easy to store these variables in a cache.
-#
-# The canonical example here is testing for compiler flags. On a simple system
-# each call to the compiler takes 10 ms, but on a system with a compiler that's
-# called through various wrappers it can take upwards of 100 ms. If we have
-# 100 calls to the compiler this can take 1 second (on a simple system) or 10
-# seconds (on a complicated system).
-#
-# The "cache" will be in Makefile syntax and can be directly included.
-# Any time we try to reference a variable that's not in the cache we'll
-# calculate it and store it in the cache for next time.
-
-# Include values from last time
-make-cache := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/,$(if
$(obj),$(obj)/)).cache.mk
-$(make-cache): ;
--include $(make-cache)
-
-cached-data := $(filter __cached_%, $(.VARIABLES))
-
-# If cache exceeds 1000 lines, shrink it down to 500.
-ifneq ($(word 1000,$(cached-data)),)
-$(shell tail -n 500 $(make-cache) > $(make-cache).tmp; \
- mv $(make-cache).tmp $(make-cache))
-endif
-
-create-cache-dir := $(if $(KBUILD_SRC),$(if $(cache-data),,1))
-
-# Usage: $(call __sanitize-opt,Hello=Hola$(comma)Goodbye Adios)
-#
-# Convert all '$', ')', '(', '\', '=', ' ', ',', ':' to '_'
-__sanitize-opt = $(subst $$,_,$(subst $(right_paren),_,$(subst
$(left_paren),_,$(subst \,_,$(subst =,_,$(subst $(space),_,$(subst
$(comma),_,$(subst :,_,$(1)
-
-# Usage: $(call shell-cached,shell_command)
-# Exam
[PATCH v4 09/31] kconfig: replace $(UNAME_RELEASE) with function call
Now that 'shell' function is supported, this can be self-contained in Kconfig. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Reviewed-by: Ulf Magnusson --- Changes in v4: None Changes in v3: None Changes in v2: None Makefile | 3 +-- init/Kconfig | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index c6278e6..01b2211 100644 --- a/Makefile +++ b/Makefile @@ -284,8 +284,7 @@ include scripts/Kbuild.include # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION) -UNAME_RELEASE := $(shell uname --release) -export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION UNAME_RELEASE +export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION # SUBARCH tells the usermode build what the underlying arch is. That is set # first, and if a usermode build is happening, the "ARCH=um" on the command diff --git a/init/Kconfig b/init/Kconfig index 752816b..66f0463 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -2,9 +2,9 @@ config DEFCONFIG_LIST string depends on !UML option defconfig_list - default "/lib/modules/$(UNAME_RELEASE)/.config" + default "/lib/modules/$(shell, uname --release)/.config" default "/etc/kernel-config" - default "/boot/config-$(UNAME_RELEASE)" + default "/boot/config-$(shell, uname --release)" default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" -- 2.7.4
[PATCH v4 26/31] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c according to your GCC version. We can achieve the equivalent behavior by setting reasonable dependency with the knowledge of the compiler version. If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users are still allowed to select GCOV_FORMAT_4_7 in case the newer format is back-ported. On the other hand, If GCC 4.7 or newer is used, there is no reason to use GCOV_FORMAT_3_4, so it should be hidden. If you downgrade the compiler to GCC 4.7 or older, oldconfig/syncconfig will display a prompt for the choice because GCOV_FORMAT_3_4 becomes visible as a new symbol. Signed-off-by: Masahiro Yamada Acked-by: Peter Oberparleiter Reviewed-by: Kees Cook --- Changes in v4: None Changes in v3: None Changes in v2: None kernel/gcov/Kconfig | 17 + kernel/gcov/Makefile | 2 -- 2 files changed, 5 insertions(+), 14 deletions(-) diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig index 1276aab..1e3823f 100644 --- a/kernel/gcov/Kconfig +++ b/kernel/gcov/Kconfig @@ -53,23 +53,16 @@ config GCOV_PROFILE_ALL choice prompt "Specify GCOV format" depends on GCOV_KERNEL - default GCOV_FORMAT_AUTODETECT ---help--- - The gcov format is usually determined by the GCC version, but there are + The gcov format is usually determined by the GCC version, and the + default is chosen according to your GCC version. However, there are exceptions where format changes are integrated in lower-version GCCs. - In such a case use this option to adjust the format used in the kernel - accordingly. - - If unsure, choose "Autodetect". - -config GCOV_FORMAT_AUTODETECT - bool "Autodetect" - ---help--- - Select this option to use the format that corresponds to your GCC - version. + In such a case, change this option to adjust the format used in the + kernel accordingly. config GCOV_FORMAT_3_4 bool "GCC 3.4 format" + depends on CC_IS_GCC && GCC_VERSION < 40700 ---help--- Select this option to use the format defined by GCC 3.4. diff --git a/kernel/gcov/Makefile b/kernel/gcov/Makefile index c6c50e5..ff06d64 100644 --- a/kernel/gcov/Makefile +++ b/kernel/gcov/Makefile @@ -4,5 +4,3 @@ ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"' obj-y := base.o fs.o obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o -obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion, -lt, 0407, \ - gcc_3_4.o, gcc_4_7.o) -- 2.7.4
[PATCH v4 15/31] kconfig: add 'info', 'warning', and 'error' built-in functions
Add 'info', 'warning', and 'error' functions as in Make.
They print messages during parsing Kconfig files. 'error' will be
useful to terminate the parsing immediately in fatal cases.
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Add 'error' function
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 24
1 file changed, 24 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 47b32dc..591bcf7 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -104,6 +104,20 @@ struct function {
char *(*func)(int argc, char *argv[], int old_argc, char *old_argv[]);
};
+static char *do_error(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ pperror("%s", argv[0]);
+
+ return NULL;
+}
+
+static char *do_info(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ printf("%s\n", argv[0]);
+
+ return xstrdup("");
+}
+
static char *do_shell(int argc, char *argv[], int old_argc, char *old_argv[])
{
FILE *p;
@@ -144,9 +158,19 @@ static char *do_shell(int argc, char *argv[], int
old_argc, char *old_argv[])
return xstrdup(buf);
}
+static char *do_warning(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ fprintf(stderr, "%s:%d: %s\n", current_file->name, yylineno, argv[0]);
+
+ return xstrdup("");
+}
+
static const struct function function_table[] = {
/* Name MIN MAX EXP?Function */
+ { "error", 1, 1, true, do_error },
+ { "info", 1, 1, true, do_info },
{ "shell", 1, 1, true, do_shell },
+ { "warning",1, 1, true, do_warning },
};
#define FUNCTION_MAX_ARGS 16
--
2.7.4
[PATCH v4 19/31] Documentation: kconfig: document a new Kconfig macro language
Add a document for the macro language introduced to Kconfig.
The motivation of this work is to move the compiler option tests to
Kconfig from Makefile. A number of kernel features require the
compiler support. Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles. If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it. By moving the
compiler capability tests to Kconfig, features unsupported by the
compiler will be hidden automatically.
This change was strongly prompted by Linus Torvalds. You can find
his suggestions [1] [2] in ML. The original idea was to add a new
attribute with 'option shell=...', but I found more generalized text
expansion would make Kconfig more powerful and lovely. The basic
ideas are from Make, but there are some differences.
[1]: https://lkml.org/lkml/2016/12/9/577
[2]: https://lkml.org/lkml/2018/2/7/527
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Update according to the syntax change
Changes in v3:
- Newly added
Changes in v2: None
Documentation/kbuild/kconfig-macro-language.txt | 252
MAINTAINERS | 2 +-
2 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
diff --git a/Documentation/kbuild/kconfig-macro-language.txt
b/Documentation/kbuild/kconfig-macro-language.txt
new file mode 100644
index 000..a8dc792
--- /dev/null
+++ b/Documentation/kbuild/kconfig-macro-language.txt
@@ -0,0 +1,252 @@
+Concept
+---
+
+The basic idea was inspired by Make. When we look at Make, we notice sort of
+two languages in one. One language describes dependency graphs consisting of
+targets and prerequisites. The other is a macro language for performing textual
+substitution.
+
+There is clear distinction between the two language stages. For example, you
+can write a makefile like follows:
+
+APP := foo
+SRC := foo.c
+CC := gcc
+
+$(APP): $(SRC)
+$(CC) -o $(APP) $(SRC)
+
+The macro language replaces the variable references with their expanded form,
+and handles as if the source file were input like follows:
+
+foo: foo.c
+gcc -o foo foo.c
+
+Then, Make analyzes the dependency graph and determines the targets to be
+updated.
+
+The idea is quite similar in Kconfig - it is possible to describe a Kconfig
+file like this:
+
+CC := gcc
+
+config CC_HAS_FOO
+def_bool $(shell, $(srctree)/scripts/gcc-check-foo.sh $(CC))
+
+The macro language in Kconfig processes the source file into the following
+intermediate:
+
+config CC_HAS_FOO
+def_bool y
+
+Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
+dependency as explained in kconfig-language.txt.
+
+
+Variables
+-
+
+Like in Make, a variable in Kconfig works as a macro variable. A macro
+variable is expanded "in place" to yield a text string that may then be
+expanded further. To get the value of a variable, enclose the variable name in
+$( ). The parentheses are required even for single-letter variable names; $X is
+a syntax error. The curly brace form as in ${CC} is not supported either.
+
+There are two types of variables: simply expanded variables and recursively
+expanded variables.
+
+A simply expanded variable is defined using the := assignment operator. Its
+righthand side is expanded immediately upon reading the line from the Kconfig
+file.
+
+A recursively expanded variable is defined using the = assignment operator.
+Its righthand side is simply stored as the value of the variable without
+expanding it in any way. Instead, the expansion is performed when the variable
+is used.
+
+There is another type of assignment operator; += is used to append text to a
+variable. The righthand side of += is expanded immediately if the lefthand
+side was originally defined as a simple variable. Otherwise, its evaluation is
+deferred.
+
+The variable reference can take parameters, in the following form:
+
+ $(name,arg1,arg2,arg3)
+
+You can consider the parameterized reference as a function. (more precisely,
+"user-defined function" in the contrast to "built-in function" listed below).
+
+Useful functions must be expanded when they are used since the same function is
+expanded differently if different parameters are passed. Hence, a user-defined
+function is defined using the = assignment operator. The parameters are
+referenced within the body definition with $(1), $(2), etc.
+
+In fact, recursively expanded variables and user-defined functions are the same
+internally. (In other words, "variable" is "function with zero argument".)
+When we say "variable" in a broad sense, it includes "user-defined function".
+
+
+Built-in functions
+--
+
+Like Make, Kconfig provides several built-in function
Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO
On Wed, 16 May 2018, Hoan Tran wrote: > Hi Phil, > > On 5/11/18, 1:31 AM, "Phil Edworthy" wrote: > > The DesignWare GPIO IP can be configured for either 1 interrupt or 1 > per GPIO in port A, but the driver currently only supports 1 interrupt. > See the DesignWare DW_apb_gpio Databook description of the > 'GPIO_INTR_IO' parameter. > > This change allows the driver to work with up to 32 interrupts, it will > get as many interrupts as specified in the DT 'interrupts' property. > It doesn't do anything clever with the different interrupts, it just calls > the same handler used for single interrupt hardware. > > Signed-off-by: Phil Edworthy > Reviewed-by: Rob Herring > Acked-by: Lee Jones > --- > One point to mention is that I have made it possible for users to have > unconnected interrupts by specifying holes in the list of interrupts. > This is > done by supporting the interrupts-extended DT prop. > However, I have no use for this and had to hack some test case for this. > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts? > > v6: > - Treat DT and ACPI the same as much as possible. Note that we can't use >platform_get_irq() to get the DT interrupts as they are in the port >sub-node and hence do not have an associated platform device. > v5: > - Rolled ACPI companion code provided by Hoan Tran into this patch. > v4: > - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping() > v3: > - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect > problems > v2: > - Replaced interrupt-mask DT prop with support for the > interrupts-extended >prop. This means replacing the call to irq_of_parse_and_map() with > calls >to of_irq_parse_one() and irq_create_of_mapping(). > --- > .../devicetree/bindings/gpio/snps-dwapb-gpio.txt | 9 +++- > drivers/gpio/gpio-dwapb.c | 49 > +++--- > drivers/mfd/intel_quark_i2c_gpio.c | 3 +- > include/linux/platform_data/gpio-dwapb.h | 3 +- > 4 files changed, 45 insertions(+), 19 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt > b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt > index 4a75da7..3c1118b 100644 > --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt > +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt > @@ -26,8 +26,13 @@ controller. >the second encodes the triger flags encoded as described in >Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > - interrupt-parent : The parent interrupt controller. > -- interrupts : The interrupt to the parent controller raised when GPIOs > - generate the interrupts. > +- interrupts : The interrupts to the parent controller raised when GPIOs > + generate the interrupts. If the controller provides one combined > interrupt > + for all GPIOs, specify a single interrupt. If the controller provides > one > + interrupt for each GPIO, provide a list of interrupts that correspond > to each > + of the GPIO pins. When specifying multiple interrupts, if any are > unconnected, > + use the interrupts-extended property to specify the interrupts and set > the > + interrupt controller handle for unused interrupts to 0. > - snps,nr-gpios : The number of pins in the port, a single cell. > - resets : Reset line for the controller. > > Acked-by: Hoan Tran Well that's new. I've never seen a mailer reply like that before. Which mailer are you using? Might be worth sorting that out. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v4 17/31] kconfig: add 'filename' and 'lineno' built-in variables
The special variables, $(filename) and $(lineno), are expanded to a
file name and its line number being parsed, respectively.
Suggested-by: Randy Dunlap
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Newly added
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 16
1 file changed, 16 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 88844a7..c39e30e 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -111,6 +111,11 @@ static char *do_error(int argc, char *argv[], int
old_argc, char *old_argv[])
return NULL;
}
+static char *do_filename(int argc, char *argv[], int old_argc, char
*old_argv[])
+{
+ return xstrdup(current_file->name);
+}
+
static char *do_if(int argc, char *argv[], int old_argc, char *old_argv[])
{
char *cond, *p, *res;
@@ -144,6 +149,15 @@ static char *do_info(int argc, char *argv[], int old_argc,
char *old_argv[])
return xstrdup("");
}
+static char *do_lineno(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ char buf[16];
+
+ sprintf(buf, "%d", yylineno);
+
+ return xstrdup(buf);
+}
+
static char *do_shell(int argc, char *argv[], int old_argc, char *old_argv[])
{
FILE *p;
@@ -194,8 +208,10 @@ static char *do_warning(int argc, char *argv[], int
old_argc, char *old_argv[])
static const struct function function_table[] = {
/* Name MIN MAX EXP?Function */
{ "error", 1, 1, true, do_error },
+ { "filename", 0, 0, false, do_filename },
{ "if", 2, 3, false, do_if },
{ "info", 1, 1, true, do_info },
+ { "lineno", 0, 0, false, do_lineno },
{ "shell", 1, 1, true, do_shell },
{ "warning",1, 1, true, do_warning },
};
--
2.7.4
[PATCH v4 11/31] kconfig: support user-defined function and recursively expanded variable
Now, we got a basic ability to test compiler capability in Kconfig.
config CC_HAS_STACKPROTECTOR
def_bool $(shell, ($(CC) -Werror -fstack-protector -E -x c /dev/null -o
/dev/null 2>/dev/null) && echo y || echo n)
This works, but it is ugly to repeat this long boilerplate.
We want to describe like this:
config CC_HAS_STACKPROTECTOR
bool
default $(cc-option, -fstack-protector)
It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like that. Hence, here is another
feature, user-defined function. This works as a textual shorthand
with parameterization.
A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions. A user-defined
function in Make is referenced like $(call my-func,arg1,arg2), but I
omitted the 'call' to make the syntax shorter.
The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters. It is grammatically valid
to pass more or fewer arguments when calling it. We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.
By the way, a variable is supported as a subset of this feature since
a variable is "a user-defined function with zero argument". In this
context, I mean "variable" as recursively expanded variable. I will
add a different flavored variable in the next commit.
The code above can be written as follows:
[Example Code]
success = $(shell, ($(1)) >/dev/null 2>&1 && echo y || echo n)
cc-option = $(success, $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
config CC_HAS_STACKPROTECTOR
def_bool $(cc-option, -fstack-protector)
[Result]
$ make -s alldefconfig && tail -n 1 .config
CONFIG_CC_HAS_STACKPROTECTOR=y
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- Re-implement the parse logic
- Use = operator to define a user-defined function
Changes in v2:
- Use 'macro' directly instead of inside the string type symbol.
scripts/kconfig/lkc_proto.h | 2 +
scripts/kconfig/preprocess.c | 108 ++-
scripts/kconfig/zconf.l | 17 ++-
scripts/kconfig/zconf.y | 19 +++-
4 files changed, 142 insertions(+), 4 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index c46929f..2b16d6e 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -50,6 +50,8 @@ const char * prop_get_type_name(enum prop_type type);
/* preprocess.c */
void env_write_dep(FILE *f, const char *auto_conf_name);
+void variable_add(const char *name, const char *value);
+void variable_all_del(void);
char *expand_string(const char *in);
char *expand_dollar(const char **str);
char *expand_one_token(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index d8c5f60..88580c4 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -201,18 +201,110 @@ static char *function_call(const char *name, int argc,
char *argv[],
}
/*
+ * Variables (and user-defined functions)
+ */
+static LIST_HEAD(variable_list);
+
+struct variable {
+ char *name;
+ char *value;
+ struct list_head node;
+};
+
+static struct variable *variable_lookup(const char *name)
+{
+ struct variable *v;
+
+ list_for_each_entry(v, &variable_list, node) {
+ if (!strcmp(name, v->name))
+ return v;
+ }
+
+ return NULL;
+}
+
+static char *variable_expand(const char *name, int argc, char *argv[],
+int old_argc, char *old_argv[])
+{
+ struct variable *v;
+ char *expanded_argv[FUNCTION_MAX_ARGS], *res;
+ int i;
+
+ v = variable_lookup(name);
+ if (!v)
+ return NULL;
+
+ for (i = 0; i < argc; i++)
+ expanded_argv[i] = expand_string_with_args(argv[i],
+ old_argc, old_argv);
+
+ res = expand_string_with_args(v->value, argc, expanded_argv);
+
+ for (i = 0; i < argc; i++)
+ free(expanded_argv[i]);
+
+ return res;
+}
+
+void variable_add(const char *name, const char *value)
+{
+ struct variable *v;
+
+ v = variable_lookup(name);
+ if (v) {
+ free(v->value);
+ } else {
+ v = xmalloc(sizeof(*v));
+ v->name = xstrdup(name);
+ list_add_tail(&v->node, &variable_list);
+ }
+
+ v->value = xstrdup(value);
+}
+
+static void variable_del(struct variable *v)
+{
+ list_del(&v->node);
+ free(v->name);
+ free(v->value);
+ free(v);
+}
+
+void variable_all_del(void)
+{
+ struct variable *v, *tmp;
+
+ list_for_each_entry_safe(v, tmp, &variable_list, node)
+ variable_del(v)
[PATCH v4 29/31] gcc-plugins: test plugin support in Kconfig and clean up Makefile
Run scripts/gcc-plugin.sh from Kconfig so that users can enable GCC_PLUGINS only when the compiler supports building plugins. Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain the compiler (g++ or gcc) used for building plugins, or empty if the plugin can not be supported at all. This allows us to remove all ugly testing in Makefile.gcc-plugins. Signed-off-by: Masahiro Yamada --- Changes in v4: - Use if-success macro for clean-up Changes in v3: - Respin to keep scripts/gcc-plugin.sh as-is. Changes in v2: None arch/Kconfig | 10 ++ scripts/Kconfig.include | 3 ++ scripts/Makefile.gcc-plugins | 79 scripts/gcc-plugins/Makefile | 1 + 4 files changed, 36 insertions(+), 57 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index ca32950..70f585f 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -401,6 +401,15 @@ config SECCOMP_FILTER See Documentation/prctl/seccomp_filter.txt for details. +preferred-plugin-hostcc := $(if-success, [ $(gcc-version) -ge 40800 ],$(HOSTCXX),$(HOSTCC)) + +config PLUGIN_HOSTCC + string + default "$(shell, $(srctree)/scripts/gcc-plugin.sh $(preferred-plugin-hostcc) $(HOSTCXX) $(CC))" + help + Host compiler used to build GCC plugins. This can be $(HOSTCXX), + $(HOSTCC), or a null string if GCC plugin is unsupported. + config HAVE_GCC_PLUGINS bool help @@ -410,6 +419,7 @@ config HAVE_GCC_PLUGINS menuconfig GCC_PLUGINS bool "GCC plugins" depends on HAVE_GCC_PLUGINS + depends on PLUGIN_HOSTCC != "" depends on !COMPILE_TEST help GCC plugins are loadable modules that provide extra features to the diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include index b1502f4..bfecf61 100644 --- a/scripts/Kconfig.include +++ b/scripts/Kconfig.include @@ -22,3 +22,6 @@ cc-option = $(success, $(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) # $(ld-option,) # y if the linker supports , n otherwise ld-option = $(success, $(LD) -v $(1)) + +# gcc version including patch level +gcc-version := $(shell, $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 's/^0*//') diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 1e92353..da5d38d 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -1,72 +1,37 @@ # SPDX-License-Identifier: GPL-2.0 -ifdef CONFIG_GCC_PLUGINS - __PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC)) - PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh "$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)") - - SANCOV_PLUGIN := -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so - - gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) += cyc_complexity_plugin.so +gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) += cyc_complexity_plugin.so - gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += latent_entropy_plugin.so - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)+= -DLATENT_ENTROPY_PLUGIN - ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY +gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += latent_entropy_plugin.so +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += -DLATENT_ENTROPY_PLUGIN +ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY DISABLE_LATENT_ENTROPY_PLUGIN += -fplugin-arg-latent_entropy_plugin-disable - endif - - ifdef CONFIG_GCC_PLUGIN_SANCOV - # It is needed because of the gcc-plugin.sh and gcc version checks. - gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so - - ifeq ($(PLUGINCC),) -$(warning warning: cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler) - endif - endif - - gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE)+= -fplugin-arg-structleak_plugin-verbose - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) += -fplugin-arg-structleak_plugin-byref-all - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)+= -DSTRUCTLEAK_PLUGIN +endif - gcc-plugin-$(CONFIG_GCC_PLUGIN_RANDSTRUCT) += randomize_layout_plugin.so - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT)+= -DRANDSTRUCT_PLUGIN - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE)+= -fplugin-arg-randomize_layout_plugin-performance-mode +gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so +gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE) += -fplugin-arg-structleak_plugin-verbose +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)+= -fplugin-arg-structleak_plugin-byref-all +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += -DSTRUCTLEAK_PLUGIN - GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc
Re: [PATCH] mmc: block: propagate correct returned value in mmc_rpmb_ioctl
On 2018/5/17 14:16, Mathieu Malaterre wrote:
On Thu, May 17, 2018 at 4:45 AM, Shawn Lin wrote:
On 2018/5/17 3:20, Mathieu Malaterre wrote:
In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device")
a
new function `mmc_rpmb_ioctl` was added. The final return is simply
returning a value of `0` instead of propagating the correct return code.
Discovered during a compilation with W=1, silence the following gcc
warning
drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Good catch! But hey, which gcc are you using now? Mine, gcc-linaro-
6.3.1-2017.05-x86_64_aarch64-linux-gnu, with W=1 doesn't warn about
this.
$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks for sharing.
This is the default powerpc cross compiler on Debian stable (no
change). Config is simply a ppc32 (with some minor customization).
And it's worth backporting to stable.
I am not familiar with the process, do I need to submit a v2 to add the line:
Cc: # v4.15+
In general Ulf could kindly help with it when applied. :)
?
Reviewed-by: Shawn Lin
Signed-off-by: Mathieu Malaterre
---
drivers/mmc/core/block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 9e923cd1d80e..38a7586b00cc 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2485,7 +2485,7 @@ static long mmc_rpmb_ioctl(struct file *filp,
unsigned int cmd,
break;
}
- return 0;
+ return ret;
}
#ifdef CONFIG_COMPAT
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 18/31] kconfig: error out if a recursive variable references itself
When using a recursively expanded variable, it is a common mistake
to make circular reference.
For example, Make terminates the following code:
X = $(X)
Y := $(X)
Let's detect the circular expansion in Kconfig, too.
On the other hand, a function that recurses itself is a commonly-used
programming technique. So, Make does not check recursion in the
reference with 'call'. For example, the following code continues
running eternally:
X = $(call X)
Y := $(X)
Kconfig allows circular expansion if one or more arguments are given,
but terminates when the same function is recursively invoked 1000 times,
assuming it is a programming mistake.
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Newly added
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index c39e30e..246f879 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -276,6 +276,7 @@ struct variable {
char *name;
char *value;
enum variable_flavor flavor;
+ int exp_count;
struct list_head node;
};
@@ -306,8 +307,19 @@ static char *variable_expand(const char *name, int argc,
char *argv[],
expanded_argv[i] = expand_string_with_args(argv[i],
old_argc, old_argv);
+ if (argc == 0 && v->exp_count)
+ pperror("Recursive variable '%s' references itself
(eventually)",
+ name);
+
+ if (v->exp_count > 1000)
+ pperror("Too deep recursive expansion");
+
+ v->exp_count++;
+
res = expand_string_with_args(v->value, argc, expanded_argv);
+ v->exp_count--;
+
for (i = 0; i < argc; i++)
free(expanded_argv[i]);
@@ -337,6 +349,7 @@ void variable_add(const char *name, const char *value,
v = xmalloc(sizeof(*v));
v->name = xstrdup(name);
+ v->exp_count = 0;
list_add_tail(&v->node, &variable_list);
}
--
2.7.4
[PATCH v4 13/31] kconfig: support append assignment operator
Support += operator. This appends a space and the text on the
righthand side to a variable.
The timing of the evaluation of the righthand side depends on the
flavor of the variable. If the lefthand side was originally defined
as a simple variable, the righthand side is expanded immediately.
Otherwise, the expansion is deferred. Appending something to an
undefined variable results in a recursive variable.
To implement this, we need to remember the flavor of variables.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 1 +
scripts/kconfig/preprocess.c | 29 +++--
scripts/kconfig/zconf.l | 1 +
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 6303193..a8b7a33 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -52,6 +52,7 @@ const char * prop_get_type_name(enum prop_type type);
enum variable_flavor {
VAR_SIMPLE,
VAR_RECURSIVE,
+ VAR_APPEND,
};
void env_write_dep(FILE *f, const char *auto_conf_name);
void variable_add(const char *name, const char *value,
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 5d7bd9d..47b32dc 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -208,6 +208,7 @@ static LIST_HEAD(variable_list);
struct variable {
char *name;
char *value;
+ enum variable_flavor flavor;
struct list_head node;
};
@@ -250,18 +251,42 @@ void variable_add(const char *name, const char *value,
enum variable_flavor flavor)
{
struct variable *v;
+ char *new_value;
+ bool append = false;
v = variable_lookup(name);
if (v) {
- free(v->value);
+ /* For defined variables, += inherits the existing flavor */
+ if (flavor == VAR_APPEND) {
+ flavor = v->flavor;
+ append = true;
+ } else {
+ free(v->value);
+ }
} else {
+ /* For undefined variables, += assumes the recursive flavor */
+ if (flavor == VAR_APPEND)
+ flavor = VAR_RECURSIVE;
+
v = xmalloc(sizeof(*v));
v->name = xstrdup(name);
list_add_tail(&v->node, &variable_list);
}
- v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+ v->flavor = flavor;
+
+ new_value = (flavor == VAR_SIMPLE) ? expand_string(value) :
xstrdup(value);
+
+ if (append) {
+ v->value = xrealloc(v->value,
+ strlen(v->value) + strlen(new_value) + 2);
+ strcat(v->value, " ");
+ strcat(v->value, new_value);
+ free(new_value);
+ } else {
+ v->value = new_value;
+ }
}
static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index aa76942..c68ca56b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -116,6 +116,7 @@ n [A-Za-z0-9_-]
}
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
+ "+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return
T_ASSIGN; }
[[:blank:]]+
. warn_ignored_character(*yytext);
\n {
--
2.7.4
[PATCH v3 1/4] dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform
This adds dt-binding documentation of cpu for Mediatek MT8183. Signed-off-by: Erin Lo --- Documentation/devicetree/bindings/arm/mediatek.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index 7d21ab3..2754535 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -19,6 +19,7 @@ compatible: Must contain one of "mediatek,mt8127" "mediatek,mt8135" "mediatek,mt8173" + "mediatek,mt8183" Supported boards: @@ -73,3 +74,6 @@ Supported boards: - MTK mt8173 tablet EVB: Required root node properties: - compatible = "mediatek,mt8173-evb", "mediatek,mt8173"; +- Evaluation board for MT8183: +Required root node properties: + - compatible = "mediatek,mt8183-evb", "mediatek,mt8183"; -- 1.9.1
Re: [PATCH] PCI: Clean up resource allocation in devm_of_pci_get_host_bridge_resources()
On 05/16/2018 03:31 PM, Jan Kiszka wrote:
> Instead of first allocating and then freeing memory for struct resource
> in case we cannot parse a PCI resource from the device tree, work
> against a local struct and kmemdup it when we decide to go with it.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Jan Kiszka
> ---
> drivers/pci/of.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index b06585a1da75..fc0f906c5c25 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -266,7 +266,7 @@ int devm_of_pci_get_host_bridge_resources(struct device
> *dev,
> struct list_head *resources, resource_size_t *io_base)
> {
> struct device_node *dev_node = dev->of_node;
> - struct resource *res;
> + struct resource *res, tmp_res;
> struct resource *bus_range;
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> @@ -320,18 +320,16 @@ int devm_of_pci_get_host_bridge_resources(struct device
> *dev,
> if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> continue;
>
> - res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
> + err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
> + if (err)
> + continue;
> +
> + res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
The change looks okay, apparently probable garbage in tmp_res.desc has no
impact.
Reviewed-by: Vladimir Zapolskiy
--
With best wishes,
Vladimir
[PATCH v3 2/4] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo --- .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index 07bf0b9..5ff48a8 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -5,6 +5,7 @@ interrupt. Required properties: - compatible: should be + "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183 "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173 "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135 "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 -- 1.9.1
[PATCH v4 21/31] kconfig: show compiler version text in the top comment
The kernel configuration phase is now tightly coupled with the compiler in use. It will be nice to show the compiler information in Kconfig. The compiler information will be displayed like this: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config scripts/kconfig/conf --oldaskconfig Kconfig * * Linux/arm64 4.16.0-rc1 Kernel Configuration * * * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 * * * General setup * Compile also drivers which will not load (COMPILE_TEST) [N/y/?] If you use GUI methods such as menuconfig, it will be displayed in the top menu. This is simply implemented by using the 'comment' statement. So, it will be saved into the .config file as well. This commit has a very important meaning. If the compiler is upgraded, Kconfig must be re-run since different compilers have different sets of supported options. All referenced environments are written to include/config/auto.conf.cmd so that any environment change triggers syncconfig, and prompt the user to input new values if needed. With this commit, something like follows will be added to include/config/auto.conf.cmd ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011" include/config/auto.conf: FORCE endif Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v4: - Add comment to arch/x86/um/Kconfig as well Changes in v3: None Changes in v2: None Kconfig | 2 ++ Makefile| 2 ++ arch/x86/um/Kconfig | 2 ++ 3 files changed, 6 insertions(+) diff --git a/Kconfig b/Kconfig index 4af1b42..5b55d87 100644 --- a/Kconfig +++ b/Kconfig @@ -5,4 +5,6 @@ # mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration" +comment "Compiler: $(CC_VERSION_TEXT)" + source "arch/$(SRCARCH)/Kconfig" diff --git a/Makefile b/Makefile index 01b2211..7529825 100644 --- a/Makefile +++ b/Makefile @@ -442,6 +442,8 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL export KBUILD_ARFLAGS +export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1) + # When compiling out-of-tree modules, put MODVERDIR in the module # tree rather than in the kernel tree. The kernel tree might # even be read-only. diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig index 6a15c4d..a992f8e 100644 --- a/arch/x86/um/Kconfig +++ b/arch/x86/um/Kconfig @@ -1,6 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 mainmenu "User Mode Linux/$(SUBARCH) $(KERNELVERSION) Kernel Configuration" +comment "Compiler: $(CC_VERSION_TEXT)" + source "arch/um/Kconfig.common" menu "UML-specific options" -- 2.7.4
[PATCH v3 3/4] dt-bindings: serial: Add compatible for Mediatek MT8183
This adds dt-binding documentation of uart for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index f73abff..4783336 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -15,6 +15,7 @@ Required properties: * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS + * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS * "mediatek,mt6577-uart" for MT6577 and all of the above - reg: The base address of the UART register bank. -- 1.9.1
[PATCH v3 4/4] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Ben Ho
Add basic chip support for Mediatek 8183
Signed-off-by: Ben Ho
Signed-off-by: Erin Lo
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 182
3 files changed, 214 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60..2836261 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -5,3 +5,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 000..9b52559
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+ model = "MediaTek MT8183 evaluation board";
+ compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
new file mode 100644
index 000..03edf9c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8183";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x100>;
+ enable-method = "psci";
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x101>;
+ enable-method = "ps
[GIT PULL] s390 patches for 4.17-rc6
Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: A few more additional changes for 4.17: * A fix for the vfio ccw translation code * Update an incorrect email address in the MAINTAINERS file * Fix a division by zero oops in the cpum_sf code found by trinity * Two fixes for the error handling of the qdio code * Several spectre related patches to convert all left-over indirect branches in the kernel to expoline branches * Update defconfigs to avoid warnings due to the netfilter Kconfig changes * Avoid several compiler warnings in the kexec_file code for s390 Halil Pasic (1): vfio: ccw: fix cleanup if cp_prefetch fails Harald Freudenberger (1): MAINTAINERS: update s390 zcrypt maintainers email address Hendrik Brueckner (1): s390/cpum_sf: ensure sample frequency of perf event attributes is non-zero Julian Wiedmann (2): s390/qdio: fix access to uninitialized qdio_q fields s390/qdio: don't release memory in qdio_setup_irq() Martin Schwidefsky (9): s390: move expoline assembler macros to a header s390/crc32-vx: use expoline for indirect branches s390/lib: use expoline for indirect branches s390/ftrace: use expoline for indirect branches s390/kernel: use expoline for indirect branches s390: move spectre sysfs attribute code s390: remove indirect branch from do_softirq_own_stack s390: extend expoline to BC instructions s390: use expoline thunks in the BPF JIT Sebastian Ott (2): s390: update defconfigs s390/kexec_file: add declaration of purgatory related globals MAINTAINERS | 2 +- arch/s390/configs/debug_defconfig | 9 +- arch/s390/configs/performance_defconfig | 8 +- arch/s390/crypto/crc32be-vx.S | 5 +- arch/s390/crypto/crc32le-vx.S | 4 +- arch/s390/include/asm/nospec-insn.h | 196 arch/s390/include/asm/purgatory.h | 6 + arch/s390/kernel/Makefile | 1 + arch/s390/kernel/asm-offsets.c | 1 + arch/s390/kernel/base.S | 24 ++-- arch/s390/kernel/entry.S| 105 - arch/s390/kernel/irq.c | 5 +- arch/s390/kernel/mcount.S | 14 ++- arch/s390/kernel/nospec-branch.c| 44 --- arch/s390/kernel/nospec-sysfs.c | 21 arch/s390/kernel/perf_cpum_sf.c | 4 + arch/s390/kernel/reipl.S| 7 +- arch/s390/kernel/swsusp.S | 10 +- arch/s390/lib/mem.S | 19 ++-- arch/s390/net/bpf_jit.S | 16 ++- arch/s390/net/bpf_jit_comp.c| 63 +- drivers/s390/cio/qdio_setup.c | 12 +- drivers/s390/cio/vfio_ccw_cp.c | 13 ++- 23 files changed, 422 insertions(+), 167 deletions(-) create mode 100644 arch/s390/include/asm/nospec-insn.h create mode 100644 arch/s390/kernel/nospec-sysfs.c diff --git a/MAINTAINERS b/MAINTAINERS index dd66ae9..2ad3306 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12239,7 +12239,7 @@ F: Documentation/s390/vfio-ccw.txt F: include/uapi/linux/vfio_ccw.h S390 ZCRYPT DRIVER -M: Harald Freudenberger +M: Harald Freudenberger L: linux-s...@vger.kernel.org W: http://www.ibm.com/developerworks/linux/linux390/ S: Supported diff --git a/arch/s390/configs/debug_defconfig b/arch/s390/configs/debug_defconfig index 6176fe9..941d8cc 100644 --- a/arch/s390/configs/debug_defconfig +++ b/arch/s390/configs/debug_defconfig @@ -261,9 +261,9 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IP_VS_PE_SIP=m CONFIG_NF_CONNTRACK_IPV4=m -CONFIG_NF_TABLES_IPV4=m +CONFIG_NF_TABLES_IPV4=y CONFIG_NFT_CHAIN_ROUTE_IPV4=m -CONFIG_NF_TABLES_ARP=m +CONFIG_NF_TABLES_ARP=y CONFIG_NFT_CHAIN_NAT_IPV4=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_AH=m @@ -284,7 +284,7 @@ CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_NF_CONNTRACK_IPV6=m -CONFIG_NF_TABLES_IPV6=m +CONFIG_NF_TABLES_IPV6=y CONFIG_NFT_CHAIN_ROUTE_IPV6=m CONFIG_NFT_CHAIN_NAT_IPV6=m CONFIG_IP6_NF_IPTABLES=m @@ -305,7 +305,7 @@ CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_SECURITY=m CONFIG_IP6_NF_NAT=m CONFIG_IP6_NF_TARGET_MASQUERADE=m -CONFIG_NF_TABLES_BRIDGE=m +CONFIG_NF_TABLES_BRIDGE=y CONFIG_RDS=m CONFIG_RDS_RDMA=m CONFIG_RDS_TCP=m @@ -604,7 +604,6 @@ CONFIG_DETECT_HUNG_TASK=y CONFIG_WQ_WATCHDOG=y CONFIG_PANIC_ON_OOPS=y CONFIG_DEBUG_TIMEKEEPING=y -CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y CONFIG_PROVE_LOCKING=y CONFIG_LOCK_STAT=y CONFIG_DEBUG_LOCKDEP=y diff --git a/arch/s390/configs/performance_defconfig b/arch/s390/configs/performance_defconfig index c105bcc..eb6f75f 100644 --- a/arch/s390/configs/performance_defconfig +++ b/arch/s390/configs/performance_defconfig @@ -259,9 +259,9 @@ CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONF
[PATCH v4 25/31] kconfig: add CC_IS_CLANG and CLANG_VERSION
This will be useful to describe the clang version dependency.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
init/Kconfig | 7 +++
scripts/clang-version.sh | 18 --
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index c6ac856..3aeb37a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -16,6 +16,13 @@ config GCC_VERSION
default $(shell, $(srctree)/scripts/gcc-version.sh -p $(CC) | sed
's/^0*//') if CC_IS_GCC
default 0
+config CC_IS_CLANG
+ def_bool $(success, $(CC) --version | grep -q clang)
+
+config CLANG_VERSION
+ int
+ default $(shell, $(srctree)/scripts/clang-version.sh $(CC))
+
config CONSTRUCTORS
bool
depends on !UML
diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
index 9780efa..dbf0a31 100755
--- a/scripts/clang-version.sh
+++ b/scripts/clang-version.sh
@@ -10,24 +10,14 @@
# clang-5.0.1 etc.
#
-if [ "$1" = "-p" ] ; then
- with_patchlevel=1;
- shift;
-fi
-
compiler="$*"
-if [ ${#compiler} -eq 0 ]; then
- echo "Error: No compiler specified."
- printf "Usage:\n\t$0 \n"
+if !( $compiler --version | grep -q clang) ; then
+ echo 0
exit 1
fi
MAJOR=$(echo __clang_major__ | $compiler -E -x c - | tail -n 1)
MINOR=$(echo __clang_minor__ | $compiler -E -x c - | tail -n 1)
-if [ "x$with_patchlevel" != "x" ] ; then
- PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n
1)
- printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-else
- printf "%02d%02d\\n" $MAJOR $MINOR
-fi
+PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 1)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.7.4
[PATCH v4 23/31] stack-protector: test compiler capability in Kconfig and drop AUTO mode
Move the test for -fstack-protector(-strong) option to Kconfig.
If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.
I also turned the 'choice' into only two boolean symbols. The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.
X86 has additional shell scripts in case the compiler supports those
options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Makefile | 93 ++-
arch/Kconfig | 32 ---
arch/x86/Kconfig | 11 +++-
scripts/gcc-x86_32-has-stack-protector.sh | 7 +--
scripts/gcc-x86_64-has-stack-protector.sh | 5 --
5 files changed, 28 insertions(+), 120 deletions(-)
diff --git a/Makefile b/Makefile
index 7529825..12c222d 100644
--- a/Makefile
+++ b/Makefile
@@ -672,55 +672,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
endif
-# This selects the stack protector compiler flag. Testing it is delayed
-# until after .config has been reprocessed, in the prepare-compiler-check
-# target.
-ifdef CONFIG_CC_STACKPROTECTOR_AUTO
- stackp-flag := $(call cc-option,-fstack-protector-strong,$(call
cc-option,-fstack-protector))
- stackp-name := AUTO
-else
-ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
- stackp-flag := -fstack-protector
- stackp-name := REGULAR
-else
-ifdef CONFIG_CC_STACKPROTECTOR_STRONG
- stackp-flag := -fstack-protector-strong
- stackp-name := STRONG
-else
- # If either there is no stack protector for this architecture or
- # CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
- # is empty, skipping all remaining stack protector tests.
- #
- # Force off for distro compilers that enable stack protector by default.
- KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-endif
-endif
-endif
-# Find arch-specific stack protector compiler sanity-checking script.
-ifdef stackp-name
-ifneq ($(stackp-flag),)
- stackp-path :=
$(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
- stackp-check := $(wildcard $(stackp-path))
- # If the wildcard test matches a test script, run it to check functionality.
- ifdef stackp-check
-ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS)
$(biarch)),y)
- stackp-broken := y
-endif
- endif
- ifndef stackp-broken
-# If the stack protector is functional, enable code that depends on it.
-KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
-# Either we've already detected the flag (for AUTO) or we'll fail the
-# build in the prepare-compiler-check rule (for specific flag).
-KBUILD_CFLAGS += $(stackp-flag)
- else
-# We have to make sure stack protector is unconditionally disabled if
-# the compiler is broken (in case we're going to continue the build in
-# AUTO mode).
-KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
- endif
-endif
-endif
+stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR) := -fstack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG) := -fstack-protector-strong
+
+KBUILD_CFLAGS += $(stackp-flags-y)
ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
@@ -1099,7 +1055,7 @@ endif
# prepare2 creates a makefile if using a separate output directory.
# From this point forward, .config has been reprocessed, so any rules
# that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic
+prepare2: prepare3 outputmakefile asm-generic
prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
include/config/auto.conf
@@ -1125,43 +1081,6 @@ uapi-asm-generic:
PHONY += prepare-objtool
prepare-objtool: $(objtool_target)
-# Check for CONFIG flags that require compiler support. Abort the build
-# after .config has been processed, but before the kernel build starts.
-#
-# For security-sensitive CONFIG options, we don't want to fallback and/or
-# silently change which compiler flags will be used, since that leads to
-# producing kernels with different security feature characteristics
-# depending on the compiler used. (For example, "But I selected
-# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!")
-PHONY += prepare-compiler-check
-prepare-co
[PATCH v4 30/31] gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.
Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.
'depends on !COMPILE_TEST' for the following three are still kept:
GCC_PLUGIN_CYC_COMPLEXITY
GCC_PLUGIN_STRUCTLEAK_VERBOSE
GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
Kees said to do so because the first two are too noisy, and the last
one would reduce the compile test coverage. I commented the reasons
in arch/Kconfig.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- Add comment about reason
Changes in v2: None
arch/Kconfig | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 70f585f..6e8f0cf 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -420,7 +420,6 @@ menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on PLUGIN_HOSTCC != ""
- depends on !COMPILE_TEST
help
GCC plugins are loadable modules that provide extra features to the
compiler. They are useful for runtime instrumentation and static
analysis.
@@ -430,7 +429,7 @@ menuconfig GCC_PLUGINS
config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function" if EXPERT
depends on GCC_PLUGINS
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# too noisy
help
The complexity M of a function's control flow graph is defined as:
M = E - N + 2P
@@ -497,7 +496,7 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# too noisy
help
This option will cause a warning to be printed each time the
structleak plugin finds a variable it thinks needs to be
@@ -537,7 +536,7 @@ config GCC_PLUGIN_RANDSTRUCT
config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
bool "Use cacheline-aware structure randomization"
depends on GCC_PLUGIN_RANDSTRUCT
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# do not reduce test coverage
help
If you say Y here, the RANDSTRUCT randomization will make a
best effort at restricting randomization to cacheline-sized
--
2.7.4
[PATCH v4 22/31] kconfig: add basic helper macros to scripts/Kconfig.include
Kconfig got text processing tools like we see in Make. Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v4:
- source scripts/Kconfig.include
from arch/x86/um/Kconfig since UML is special
- Use { $(1); } for 'success' macro for better performance
- Use -E instead of -c for 'cc-option' macro for better performance
- Add 'if-success' macro
Changes in v3:
- Move helpers to scripts/Kconfig.include
Changes in v2: None
Kconfig | 2 ++
MAINTAINERS | 1 +
arch/x86/um/Kconfig | 2 ++
scripts/Kconfig.include | 24
4 files changed, 29 insertions(+)
create mode 100644 scripts/Kconfig.include
diff --git a/Kconfig b/Kconfig
index 5b55d87..a90d9f9 100644
--- a/Kconfig
+++ b/Kconfig
@@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
comment "Compiler: $(CC_VERSION_TEXT)"
+source "scripts/Kconfig.include"
+
source "arch/$(SRCARCH)/Kconfig"
diff --git a/MAINTAINERS b/MAINTAINERS
index b7d7ae61..1667cee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7634,6 +7634,7 @@ L:linux-kbu...@vger.kernel.org
S: Maintained
F: Documentation/kbuild/kconfig*
F: scripts/kconfig/
+F: scripts/Kconfig.include
KDUMP
M: Dave Young
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index a992f8e..9d529f2 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -3,6 +3,8 @@ mainmenu "User Mode Linux/$(SUBARCH) $(KERNELVERSION) Kernel
Configuration"
comment "Compiler: $(CC_VERSION_TEXT)"
+source "scripts/Kconfig.include"
+
source "arch/um/Kconfig.common"
menu "UML-specific options"
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
new file mode 100644
index 000..b1502f4
--- /dev/null
+++ b/scripts/Kconfig.include
@@ -0,0 +1,24 @@
+# Kconfig helper macros
+
+# Convenient variables
+comma := ,
+quote := "
+squote := '
+empty :=
+space := $(empty) $(empty)
+
+# $(if-success,,,)
+# if exits with 0, otherwise.
+if-success = $(shell, { $(1); } >/dev/null 2>&1 && echo "$(2)" || echo "$(3)")
+
+# $(success,)
+# y if exits with 0, n otherwise
+success = $(if-success, $(1),y,n)
+
+# $(cc-option,)
+# y if the compiler supports , n otherwise
+cc-option = $(success, $(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)
+
+# $(ld-option,)
+# y if the linker supports , n otherwise
+ld-option = $(success, $(LD) -v $(1))
--
2.7.4
[PATCH v4 28/31] gcc-plugins: move GCC version check for PowerPC to Kconfig
For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the version check to Kconfig so that the GCC plugin menus will be hidden if an older compiler is in use. Signed-off-by: Masahiro Yamada Acked-by: Andrew Donnellan --- Changes in v4: None Changes in v3: - Move comment to Kconfig as well Changes in v2: None arch/powerpc/Kconfig | 2 +- scripts/Makefile.gcc-plugins | 8 2 files changed, 1 insertion(+), 9 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index c32a181..17e53e6 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -195,7 +195,7 @@ config PPC select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER - select HAVE_GCC_PLUGINS + select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC select HAVE_GENERIC_GUP select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx) select HAVE_IDE diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 0ce3802..1e92353 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -53,14 +53,6 @@ gcc-plugins-check: FORCE ifdef CONFIG_GCC_PLUGINS ifeq ($(PLUGINCC),) ifneq ($(GCC_PLUGINS_CFLAGS),) - # Various gccs between 4.5 and 5.1 have bugs on powerpc due to missing - # header files. gcc <= 4.6 doesn't work at all, gccs from 4.8 to 5.1 have - # issues with 64-bit targets. - ifeq ($(ARCH),powerpc) -ifeq ($(call cc-ifversion, -le, 0501, y), y) - @echo "Cannot use CONFIG_GCC_PLUGINS: plugin support on gcc <= 5.1 is buggy on powerpc, please upgrade to gcc 5.2 or newer" >&2 && exit 1 -endif - endif ifeq ($(call cc-ifversion, -ge, 0405, y), y) $(Q)$(srctree)/scripts/gcc-plugin.sh --show-error "$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)" || true @echo "Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?" >&2 && exit 1 -- 2.7.4
[PATCH v4 31/31] arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
This becomes much neater in Kconfig. Signed-off-by: Masahiro Yamada Acked-by: Will Deacon Reviewed-by: Kees Cook --- Changes in v4: - Rebase Changes in v3: - Newly added Changes in v2: None arch/arm64/Kconfig | 1 + arch/arm64/Makefile | 6 -- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index eb2cf49..119b18e 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -43,6 +43,7 @@ config ARM64 select ARCH_USE_QUEUED_RWLOCKS select ARCH_SUPPORTS_MEMORY_FAILURE select ARCH_SUPPORTS_ATOMIC_RMW + select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5 || CC_IS_CLANG select ARCH_SUPPORTS_NUMA_BALANCING select ARCH_WANT_COMPAT_IPC_PARSE_VERSION select ARCH_WANT_FRAME_POINTERS diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 87f7d2f..cefd1e9 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -56,12 +56,6 @@ KBUILD_AFLAGS+= $(lseinstr) $(brokengasinst) KBUILD_CFLAGS += $(call cc-option,-mabi=lp64) KBUILD_AFLAGS += $(call cc-option,-mabi=lp64) -ifeq ($(cc-name),clang) -KBUILD_CFLAGS += -DCONFIG_ARCH_SUPPORTS_INT128 -else -KBUILD_CFLAGS += $(call cc-ifversion, -ge, 0500, -DCONFIG_ARCH_SUPPORTS_INT128) -endif - ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS+= -mbig-endian CHECKFLAGS += -D__AARCH64EB__ -- 2.7.4
[PATCH v4 24/31] kconfig: add CC_IS_GCC and GCC_VERSION
This will be useful to specify the required compiler version, like this: config FOO bool "Use Foo" depends on GCC_VERSION >= 40800 help This feature requires GCC 4.8 or newer. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v4: None Changes in v3: None Changes in v2: None init/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/init/Kconfig b/init/Kconfig index 66f0463..c6ac856 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -8,6 +8,14 @@ config DEFCONFIG_LIST default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" +config CC_IS_GCC + def_bool $(success, $(CC) --version | grep -q gcc) + +config GCC_VERSION + int + default $(shell, $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 's/^0*//') if CC_IS_GCC + default 0 + config CONSTRUCTORS bool depends on !UML -- 2.7.4
[PATCH v4 20/31] kconfig: test: add Kconfig macro language tests
Here are the test cases I used for developing the text expansion
feature.
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Adjust for the change in function call syntax.
- Remove unnecessarily tricky tests.
Changes in v3:
- newly added
Changes in v2: None
.../kconfig/tests/preprocess/builtin_func/Kconfig | 29 +
.../tests/preprocess/builtin_func/__init__.py | 8
.../tests/preprocess/builtin_func/expected_stderr | 7
.../tests/preprocess/builtin_func/expected_stdout | 1 +
.../tests/preprocess/circular_expansion/Kconfig| 3 ++
.../preprocess/circular_expansion/__init__.py | 10 +
.../preprocess/circular_expansion/expected_stderr | 1 +
scripts/kconfig/tests/preprocess/escape/Kconfig| 21 ++
.../kconfig/tests/preprocess/escape/__init__.py| 7
.../tests/preprocess/escape/expected_stderr| 5 +++
scripts/kconfig/tests/preprocess/variable/Kconfig | 48 ++
.../kconfig/tests/preprocess/variable/__init__.py | 7
.../tests/preprocess/variable/expected_stderr | 9
13 files changed, 156 insertions(+)
create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/Kconfig
create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/__init__.py
create mode 100644
scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
create mode 100644
scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
create mode 100644 scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
create mode 100644
scripts/kconfig/tests/preprocess/circular_expansion/__init__.py
create mode 100644
scripts/kconfig/tests/preprocess/circular_expansion/expected_stderr
create mode 100644 scripts/kconfig/tests/preprocess/escape/Kconfig
create mode 100644 scripts/kconfig/tests/preprocess/escape/__init__.py
create mode 100644 scripts/kconfig/tests/preprocess/escape/expected_stderr
create mode 100644 scripts/kconfig/tests/preprocess/variable/Kconfig
create mode 100644 scripts/kconfig/tests/preprocess/variable/__init__.py
create mode 100644 scripts/kconfig/tests/preprocess/variable/expected_stderr
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
new file mode 100644
index 000..5f51135
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
@@ -0,0 +1,29 @@
+# 'info' prints the argument to stdout.
+$(info,hello world 0)
+
+# 'warning' is similar, but it sends its argument to stderr,
+# and the message is prefixed with the current file name and line number.
+$(warning,hello world 1)
+
+# 'shell' executes a command, and returns its stdout.
+$(warning,$(shell,echo hello world 3))
+
+# Every newline in the output is replaced with a space,
+# but any trailing newlines are deleted.
+$(warning,$(shell,printf 'hello\nworld\n\n4\n\n\n'))
+
+# 'filename' is expanded to the currently parsed file name,
+# 'lineno' to the line number.
+$(warning,filename=$(filename))
+$(warning,lineno=$(lineno))
+
+# 'if' selects which argument to expand
+# depending on the condition part.
+cond := 1
+$(warning,$(if,$(cond),y,n))
+cond :=
+$(warning,$(if,$(cond),y,n))
+
+# 'if' delays the expansion of arguments.
+# In the following, the 'error' function should not be evaluated.
+$(if,,$(error,this should not be expanded))
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/__init__.py
b/scripts/kconfig/tests/preprocess/builtin_func/__init__.py
new file mode 100644
index 000..ec7c3e2
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/__init__.py
@@ -0,0 +1,8 @@
+"""
+Built-in function tests.
+"""
+
+def test(conf):
+assert conf.oldaskconfig() == 0
+assert conf.stdout_contains('expected_stdout')
+assert conf.stderr_matches('expected_stderr')
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
b/scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
new file mode 100644
index 000..a4f27a6
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
@@ -0,0 +1,7 @@
+Kconfig:6: hello world 1
+Kconfig:9: hello world 3
+Kconfig:13: hello world 4
+Kconfig:17: filename=Kconfig
+Kconfig:18: lineno=18
+Kconfig:23: y
+Kconfig:25: n
diff --git a/scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
b/scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
new file mode 100644
index 000..82de3a7
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
@@ -0,0 +1 @@
+hello world 0
diff --git a/scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
b/scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
new file mode 100644
index 000..54debf1
--- /dev/null
+++ b/scripts/kconfig/tests/preprocess/circular_expansion/Kconfig
@@ -0,0 +1,3 @@
+X = $(Y)
+Y = $(X)
+$(info $(X))
diff --git a/scripts/kconfig/tests/preprocess/circular_expansion/__init__.py
b/scripts/kconfig/tests/preprocess/circular
[PATCH v4 12/31] kconfig: support simply expanded variable
The previous commit added variable and user-defined function. They
work similarly in the sense that the evaluation is deferred until
they are used.
This commit adds another type of variable, simply expanded variable,
as we see in Make.
The := operator defines a simply expanded variable, expanding the
righthand side immediately. This works like traditional programming
language variables.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 7 ++-
scripts/kconfig/preprocess.c | 6 --
scripts/kconfig/zconf.l | 3 ++-
scripts/kconfig/zconf.y | 5 +++--
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 2b16d6e..6303193 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -49,8 +49,13 @@ const char * sym_get_string_value(struct symbol *sym);
const char * prop_get_type_name(enum prop_type type);
/* preprocess.c */
+enum variable_flavor {
+ VAR_SIMPLE,
+ VAR_RECURSIVE,
+};
void env_write_dep(FILE *f, const char *auto_conf_name);
-void variable_add(const char *name, const char *value);
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor);
void variable_all_del(void);
char *expand_string(const char *in);
char *expand_dollar(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 88580c4..5d7bd9d 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -246,7 +246,8 @@ static char *variable_expand(const char *name, int argc,
char *argv[],
return res;
}
-void variable_add(const char *name, const char *value)
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor)
{
struct variable *v;
@@ -259,7 +260,8 @@ void variable_add(const char *name, const char *value)
list_add_tail(&v->node, &variable_list);
}
- v->value = xstrdup(value);
+ v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+ xstrdup(value);
}
static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 19e5ebf..aa76942 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,7 +114,8 @@ n [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
- "=" { BEGIN(ASSIGN_VAL); return T_ASSIGN; }
+ "=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
+ ":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
[[:blank:]]+
. warn_ignored_character(*yytext);
\n {
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 6201119..16432d0 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -41,6 +41,7 @@ static struct menu *current_menu, *current_entry;
struct expr *expr;
struct menu *menu;
const struct kconf_id *id;
+ enum variable_flavor flavor;
}
%token T_MAINMENU
@@ -78,7 +79,7 @@ static struct menu *current_menu, *current_entry;
%token T_OPEN_PAREN
%token T_EOL
%token T_VARIABLE
-%token T_ASSIGN
+%token T_ASSIGN
%token T_ASSIGN_VAL
%left T_OR
@@ -517,7 +518,7 @@ word_opt: /* empty */ { $$ = NULL; }
/* assignment statement */
-assignment_stmt: T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3);
free($1); free($3); }
+assignment_stmt: T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3,
$2); free($1); free($3); }
assign_val:
/* empty */ { $$ = xstrdup(""); };
--
2.7.4
[PATCH v4 14/31] kconfig: expand lefthand side of assignment statement
Make expands the lefthand side of assignment statements. In fact,
Kbuild relies on it since kernel makefiles mostly look like follows:
obj-$(CONFIG_FOO) += foo.o
Do likewise in Kconfig.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
scripts/kconfig/zconf.l | 7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index c68ca56b..ae33e9b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,6 +114,13 @@ n [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
+ ({n}|$)+{
+ /* this token includes at least one '$' */
+ yylval.string = expand_token(yytext, yyleng);
+ if (strlen(yylval.string))
+ return T_VARIABLE;
+ free(yylval.string);
+ }
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
"+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return
T_ASSIGN; }
--
2.7.4
[PATCH v4 27/31] kcov: test compiler capability in Kconfig and correct dependency
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
dependency.
Now that Kconfig can test compiler capability, let's handle this in a
more sophisticated way.
There are two ways to enable KCOV; use the compiler that natively
supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
the compiler has ability to build GCC plugins. Hence, the correct
dependency for KCOV is:
depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
You do not need to build the SANCOV plugin if the compiler already
supports -fsanitize-coverage=trace-pc. Hence, the select should be:
select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
scripts/Makefile.gcc-plugins can be cleaner.
I also cleaned up Kconfig and scripts/Makefile.kcov as well.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3:
- Replace the previous 'select -> imply' patch with
a new approach
Changes in v2:
- Drop depends on GCC_VERSION
Makefile | 2 +-
lib/Kconfig.debug| 11 +++
scripts/Makefile.gcc-plugins | 6 +-
scripts/Makefile.kcov| 10 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 12c222d..b5c1301 100644
--- a/Makefile
+++ b/Makefile
@@ -623,7 +623,7 @@ all: vmlinux
KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call
cc-disable-warning,maybe-uninitialized,)
-export CFLAGS_GCOV CFLAGS_KCOV
+export CFLAGS_GCOV
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..bba2298 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -736,12 +736,15 @@ config ARCH_HAS_KCOV
only for x86_64. KCOV requires testing on other archs, and most likely
disabling of instrumentation for some early boot code.
+config CC_HAS_SANCOV_TRACE_PC
+ def_bool $(cc-option, -fsanitize-coverage=trace-pc)
+
config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
+ depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
select DEBUG_FS
- select GCC_PLUGINS if !COMPILE_TEST
- select GCC_PLUGIN_SANCOV if !COMPILE_TEST
+ select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
help
KCOV exposes kernel code coverage information in a form suitable
for coverage-guided fuzzing (randomized testing).
@@ -755,7 +758,7 @@ config KCOV
config KCOV_ENABLE_COMPARISONS
bool "Enable comparison operands collection by KCOV"
depends on KCOV
- default n
+ depends on $(cc-option, -fsanitize-coverage=trace-cmp)
help
KCOV also exposes operands of every comparison in the instrumented
code along with operand sizes and PCs of the comparison instructions.
@@ -765,7 +768,7 @@ config KCOV_ENABLE_COMPARISONS
config KCOV_INSTRUMENT_ALL
bool "Instrument all code by default"
depends on KCOV
- default y if KCOV
+ default y
help
If you are doing generic system call fuzzing (like e.g. syzkaller),
then you will want to instrument the whole kernel and you should
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 7f5c862..0ce3802 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,16 +14,12 @@ ifdef CONFIG_GCC_PLUGINS
endif
ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(strip $(CFLAGS_KCOV)),)
# It is needed because of the gcc-plugin.sh and gcc version checks.
gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
- ifneq ($(PLUGINCC),)
-CFLAGS_KCOV := $(SANCOV_PLUGIN)
- else
+ ifeq ($(PLUGINCC),)
$(warning warning: cannot use CONFIG_KCOV:
-fsanitize-coverage=trace-pc is not supported by compiler)
endif
-endif
endif
gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov
index 5cc7203..d71ba73 100644
--- a/scripts/Makefile.kcov
+++ b/scripts/Makefile.kcov
@@ -1,7 +1,9 @@
ifdef CONFIG_KCOV
-CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
-ifeq ($(CONFIG_KCOV_ENABLE_COMPARISONS),y)
-CFLAGS_KCOV += $(call cc-option,-fsanitize-coverage=trace-cmp,)
-endif
+
+kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc
+kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS) += -fsanitize-coverage=trace-cmp
+kcov-flags-$(CONFIG_GCC_PLUGIN_SANKOV) +=
-fplugin=$(objtree)/scripts/gcc-plugi
[PATCH v4 16/31] kconfig: add 'if' built-in function
The 'if' function is invoked in the form:
$(if,condition,then-part,else-part)
The behavior is slightly different from that of Make.
In Make, the condition is true if the expansion contains any characters
(even space). That is why we sometimes need $(strip ...) in the
condition part.
I thought it was a nasty part in Make, so I changed it for Kconfig;
the condition is true if the expansion contains any characters except
whitespaces.
Unlike the other functions, the parameters passed to 'if' are lazily
expanded. The then-part is expanded only when the condition true,
and the else-part when false. If the parameters were evaluated
before passed to the 'if' function, $(if,$(cond),$(error,...))
would terminate the parsing regardless of $(cond).
Signed-off-by: Masahiro Yamada
---
Changes in v4:
- Newly added
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 591bcf7..88844a7 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -111,6 +111,32 @@ static char *do_error(int argc, char *argv[], int
old_argc, char *old_argv[])
return NULL;
}
+static char *do_if(int argc, char *argv[], int old_argc, char *old_argv[])
+{
+ char *cond, *p, *res;
+ const char *sel;
+
+ cond = expand_string_with_args(argv[0], old_argc, old_argv);
+ p = cond;
+
+ /* condition is true if any character except whitespaces is contained */
+ while (*p == ' ' || *p == '\t')
+ p++;
+
+ if (*p)
+ sel = argv[1];
+ else if (argc >= 3)
+ sel = argv[2];
+ else
+ sel = "";
+
+ res = expand_string_with_args(sel, old_argc, old_argv);
+
+ free(cond);
+
+ return res;
+}
+
static char *do_info(int argc, char *argv[], int old_argc, char *old_argv[])
{
printf("%s\n", argv[0]);
@@ -168,6 +194,7 @@ static char *do_warning(int argc, char *argv[], int
old_argc, char *old_argv[])
static const struct function function_table[] = {
/* Name MIN MAX EXP?Function */
{ "error", 1, 1, true, do_error },
+ { "if", 2, 3, false, do_if },
{ "info", 1, 1, true, do_info },
{ "shell", 1, 1, true, do_shell },
{ "warning",1, 1, true, do_warning },
--
2.7.4
[PATCH v4 05/31] kconfig: remove string expansion for mainmenu after yyparse()
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.
The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Simplify the patch. Just remove the text expansion.
scripts/kconfig/zconf.y | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 3a4a0fa..22e318c 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -109,7 +109,7 @@ static struct menu *current_menu, *current_entry;
%%
input: nl start | start;
-start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+start: mainmenu_stmt stmt_list | stmt_list;
/* mainmenu entry */
@@ -118,19 +118,6 @@ mainmenu_stmt: T_MAINMENU prompt nl
menu_add_prompt(P_MENU, $2, NULL);
};
-/* Default main menu, if there's no mainmenu entry */
-
-no_mainmenu_stmt: /* empty */
-{
- /*
-* Hack: Keep the main menu title on the heap so we can safely free it
-* later regardless of whether it comes from the 'prompt' in
-* mainmenu_stmt or here
-*/
- menu_add_prompt(P_MENU, xstrdup("Linux Kernel Configuration"), NULL);
-};
-
-
stmt_list:
/* empty */
| stmt_list common_stmt
@@ -528,7 +515,6 @@ word_opt: /* empty */ { $$ = NULL; }
void conf_parse(const char *name)
{
- const char *tmp;
struct symbol *sym;
int i;
@@ -544,10 +530,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );
- tmp = rootmenu.prompt->text;
- rootmenu.prompt->text = _(rootmenu.prompt->text);
- rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
- free((char*)tmp);
+ if (!menu_has_prompt(&rootmenu)) {
+ current_entry = &rootmenu;
+ menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+ }
menu_finalize(&rootmenu);
for_all_symbols(i, sym) {
--
2.7.4
[PATCH v4 00/31] kconfig: move compiler capability tests to Kconfig
[Introduction] The motivation of this work is to move the compiler option tests to Kconfig from Makefile. A number of kernel features require the compiler support. Enabling such features blindly in Kconfig ends up with a lot of nasty build-time testing in Makefiles. If a chosen feature turns out unsupported by the compiler, what the build system can do is either to disable it (silently!) or to forcibly break the build, despite Kconfig has let the user to enable it. By moving the compiler capability tests to Kconfig, Kconfig entries will be visible only when they are available. [Major Changes in V4] - In V4, I slightly change the syntax of a function call. I chose grammatical consistency and simplicity. Anyway, Kconfig is deviating from Make behavior already. In v3, a function call looked like this: $(func-name arg1,arg2,arg3) In v4, a function is invoked like follows: $(func-name,arg1,arg2,arg3) The difference is that the function name and the first argument are separated by a comma. - V3 supported single-letter variable like $X. V4 dropped it because we do not need multiple ways to do the same thing. You must always enclose a variable name like $(X). - Support lazy argument expansion. This is necessary for implementing 'if', 'and', 'or' functions as in Make. - Add more built-in functions: 'if', 'error', 'filename', 'lineno' - Error out if a recursive variable references itself eventually. For example, X = $(X) ends up with a circular expansion. It must be terminated since the expansion would continue eternally. - Update Documentation and unit-tests, accordingly. [Major Changes in V3] This version looks more like Make. - Use = operator instead of 'macro' keyword to define a user-defined function. - 'Recursively expanded variable' is implemented as a side-effect. A variable is a function with zero argument. - Support simply expanded variable which is defined by := operator - Support += operator. Probably, this feature will be useful to accumulate compiler flags. At least, Clang needs some prerequisite flags such as triplet to test other compiler flags. - Support $(info ...) and $(warning ...) built-in functions, which were useful while I was debugging this. - Add documentation - Add unit tests - Collect helpers to scripts/Kconfig.include [Old Versions] V3: https://lkml.org/lkml/2018/4/13/37 V2: https://lkml.org/lkml/2018/2/16/610 V1: https://lkml.org/lkml/2018/2/16/610 RFC: https://lkml.org/lkml/2018/2/8/429 Masahiro Yamada (31): kbuild: remove kbuild cache kbuild: remove CONFIG_CROSS_COMPILE support kconfig: reference environment variables directly and remove 'option env=' kconfig: remove string expansion in file_lookup() kconfig: remove string expansion for mainmenu after yyparse() kconfig: remove sym_expand_string_value() kconfig: add built-in function support kconfig: add 'shell' built-in function kconfig: replace $(UNAME_RELEASE) with function call kconfig: begin PARAM state only when seeing a command keyword kconfig: support user-defined function and recursively expanded variable kconfig: support simply expanded variable kconfig: support append assignment operator kconfig: expand lefthand side of assignment statement kconfig: add 'info', 'warning', and 'error' built-in functions kconfig: add 'if' built-in function kconfig: add 'filename' and 'lineno' built-in variables kconfig: error out if a recursive variable references itself Documentation: kconfig: document a new Kconfig macro language kconfig: test: add Kconfig macro language tests kconfig: show compiler version text in the top comment kconfig: add basic helper macros to scripts/Kconfig.include stack-protector: test compiler capability in Kconfig and drop AUTO mode kconfig: add CC_IS_GCC and GCC_VERSION kconfig: add CC_IS_CLANG and CLANG_VERSION gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT kcov: test compiler capability in Kconfig and correct dependency gcc-plugins: move GCC version check for PowerPC to Kconfig gcc-plugins: test plugin support in Kconfig and clean up Makefile gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig Documentation/kbuild/kconfig-language.txt | 8 - Documentation/kbuild/kconfig-macro-language.txt| 252 Kconfig| 10 +- MAINTAINERS| 3 +- Makefile | 105 +--- arch/Kconfig | 49 +- arch/arm64/Kconfig | 1 + arch/arm64/Makefile| 6 - arch/powerpc/Kconfig | 2 +- arch/sh/Kconfig| 4 +- arch/sparc/Kconfig
Re: [PATCH] mmc: block: propagate correct returned value in mmc_rpmb_ioctl
On Thu, May 17, 2018 at 4:45 AM, Shawn Lin wrote:
>
> On 2018/5/17 3:20, Mathieu Malaterre wrote:
>>
>> In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device")
>> a
>> new function `mmc_rpmb_ioctl` was added. The final return is simply
>> returning a value of `0` instead of propagating the correct return code.
>>
>> Discovered during a compilation with W=1, silence the following gcc
>> warning
>>
>>drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not
>> used [-Wunused-but-set-variable]
>>
>
> Good catch! But hey, which gcc are you using now? Mine, gcc-linaro-
> 6.3.1-2017.05-x86_64_aarch64-linux-gnu, with W=1 doesn't warn about
> this.
$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is the default powerpc cross compiler on Debian stable (no
change). Config is simply a ppc32 (with some minor customization).
> And it's worth backporting to stable.
I am not familiar with the process, do I need to submit a v2 to add the line:
Cc: # v4.15+
?
> Reviewed-by: Shawn Lin
>
>
>> Signed-off-by: Mathieu Malaterre
>> ---
>> drivers/mmc/core/block.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
>> index 9e923cd1d80e..38a7586b00cc 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -2485,7 +2485,7 @@ static long mmc_rpmb_ioctl(struct file *filp,
>> unsigned int cmd,
>> break;
>> }
>> - return 0;
>> + return ret;
>> }
>> #ifdef CONFIG_COMPAT
>>
>
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On 05/17/18 at 01:53pm, Chao Fan wrote:
> On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote:
> >Hi Chao,
> >
> >On 05/17/18 at 11:27am, Chao Fan wrote:
> >> >+/* Store the number of 1GB huge pages which user specified.*/
> >> >+static unsigned long max_gb_huge_pages;
> >> >+
> >> >+static int parse_gb_huge_pages(char *param, char* val)
> >> >+{
> >> >+ char *p;
> >> >+ u64 mem_size;
> >> >+ static bool gbpage_sz = false;
> >> >+
> >> >+ if (!strcmp(param, "hugepagesz")) {
> >> >+ p = val;
> >> >+ mem_size = memparse(p, &p);
> >> >+ if (mem_size == PUD_SIZE) {
> >> >+ if (gbpage_sz)
> >> >+ warn("Repeadly set hugeTLB page size of 1G!\n");
> >> >+ gbpage_sz = true;
> >> >+ } else
> >> >+ gbpage_sz = false;
> >> >+ } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> >> >+ p = val;
> >> >+ max_gb_huge_pages = simple_strtoull(p, &p, 0);
> >> >+ debug_putaddr(max_gb_huge_pages);
> >> >+ }
> >> >+}
> >> >+
> >> >+
> >> > static int handle_mem_memmap(void)
> >> > {
> >> > char *args = (char *)get_cmd_line_ptr();
> >> >@@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector
> >> >*region, unsigned long image_size)
> >> > }
> >> > }
> >> >
> >> >+/* Skip as many 1GB huge pages as possible in the passed region. */
> >> >+static void process_gb_huge_page(struct mem_vector *region, unsigned
> >> >long image_size)
> >> >+{
> >> >+ int i = 0;
> >> >+ unsigned long addr, size;
> >> >+ struct mem_vector tmp;
> >> >+
> >> >+ if (!max_gb_huge_pages) {
> >> >+ store_slot_info(region, image_size);
> >> >+ return;
> >> >+ }
> >> >+
> >> >+ addr = ALIGN(region->start, PUD_SIZE);
> >> >+ /* If Did we raise the address above the passed in memory entry? */
> >> >+ if (addr < region->start + region->size)
> >> >+ size = region->size - (addr - region->start);
> >> >+
> >> >+ /* Check how many 1GB huge pages can be filtered out*/
> >> >+ while (size > PUD_SIZE && max_gb_huge_pages) {
> >> >+ size -= PUD_SIZE;
> >> >+ max_gb_huge_pages--;
> >>
> >> The global variable 'max_gb_huge_pages' means how many huge pages
> >> user specified when you get it from command line.
> >> But here, everytime we find a position which is good for huge page
> >> allocation, the 'max_gdb_huge_page' decreased. So in my understanding,
> >> it is used to store how many huge pages that we still need to search memory
> >> for good slots to filter out, right?
> >> If it's right, maybe the name 'max_gb_huge_pages' is not very suitable.
> >> If my understanding is wrong, please tell me.
> >
> >No, you have understood it very right. I finished the draft patch last
> >week, but changed this variable name and the function names several
> >time, still I feel they are not good. However I can't get a better name.
> >
> >Yes, 'max_gb_huge_pages' stores how many 1GB huge pages are expected
> >from kernel command-line. And in this function it will be decreased. But
> >we can't define another global variable only for decreasing in this
> >place.
> >
> >And you can see that in this patchset I only take cares of 1GB huge
> >pages. While on x86 we have two kinds of huge pages, 2MB and 1GB, why
> >1GB only? Because 2MB is not impacted by KASLR, please check the code in
> >hugetlb_nrpages_setup() of mm/hugetlb.c . Only 1GB huge pages need be
> >pre-allocated in hugetlb_nrpages_setup(), and if you look into
> >hugetlb_nrpages_setup(), you will find that it will call
> >alloc_bootmem_huge_page() to allocate huge pages one by one, but not at
> >one time. That is why I always add 'gb' in the middle of the global
> >variable and the newly added functions.
> >
> >And it will answer your below questions. When walk over all memory
> >regions, 'max_gb_huge_pages' is still not 0, what should we do? It's
> >normal and done as expected. Here hugetlb only try its best to allocate
> >as many as possible according to 'max_gb_huge_pages'. If can't fully
> >satisfied, it's fine. E.g on bare-metal machine with 16GB RAM, you add
> >below to command-line:
> >
> >default_hugepagesz=1G hugepagesz=1G hugepages=20
> >
> >Then it will get 14 good 1GB huge pages with kaslr disabled since [0,1G)
> >and [3G,4G) are touched by bios reservation and pci/firmware reservation.
> >Then this 14 huge pages are maximal value which is expected. It's not a
> >bug in huge page. But with kaslr enabled, it sometime only get 13 1GB
> >huge pages because KASLR put kernel into one of those good 1GB huge
> >pages. This is a bug.
>
> Thanks for your explaination, I got it.
>
> >
> >I am not very familiar with huge page handling, just read code recently
> >because of this kaslr bug. Hope Luiz and people from his team can help
> >correct and clarify if anything is not right. Especially the function
> >names, I feel it's not good, if anyone have a better idea, I will really
> >appreciate that.
> >>
> >> >+ i++;
> >> >+ }
[PATCH] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
I ever met a panic under memory pressure tests(start 20 guests and run memhog in the host). -begin [35380.800950] BUG: Bad page state in process qemu-kvm pfn:dd0b6 [35380.805825] page:7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc000() [35380.818845] raw: 1fffc000 ecf98147 [35380.826569] raw: dead0100 dead0200 8017c001c000 [35380.805825] page:7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc000() [35380.818845] raw: 1fffc000 ecf98147 [35380.826569] raw: dead0100 dead0200 8017c001c000 [35380.834294] page dumped because: nonzero _refcount [35380.839069] Modules linked in: vhost_net vhost tap ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter fcoe libfcoe libfc 8021q garp mrp stp llc scsi_transport_fc openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack vfat fat rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm mlx5_ib ib_core crc32_ce ipmi_ssif tpm_tis tpm_tis_core sg nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath ip_tables xfs libcrc32c mlx5_core mlxfw devlink ahci_platform libahci_platform libahci qcom_emac sdhci_acpi sdhci hdma mmc_core hdma_mgmt i2c_qup dm_mirror dm_region_hash dm_log dm_mod [35380.908341] CPU: 29 PID: 18323 Comm: qemu-kvm Tainted: G W 4.14.15-5.hxt.aarch64 #1 [35380.917107] Hardware name: [35380.930909] Call trace: [35380.933345] [] dump_backtrace+0x0/0x22c [35380.938723] [] show_stack+0x24/0x2c [35380.943759] [] dump_stack+0x8c/0xb0 [35380.948794] [] bad_page+0xf4/0x154 [35380.953740] [] free_pages_check_bad+0x90/0x9c [35380.959642] [] free_pcppages_bulk+0x464/0x518 [35380.965545] [] free_hot_cold_page+0x22c/0x300 [35380.971448] [] __put_page+0x54/0x60 [35380.976484] [] unmap_stage2_range+0x170/0x2b4 [35380.982385] [] kvm_unmap_hva_handler+0x30/0x40 [35380.988375] [] handle_hva_to_gpa+0xb0/0xec [35380.994016] [] kvm_unmap_hva_range+0x5c/0xd0 [35380.999833] [] kvm_mmu_notifier_invalidate_range_start+0x60/0xb0 [35381.007387] [] __mmu_notifier_invalidate_range_start+0x64/0x8c [35381.014765] [] try_to_unmap_one+0x78c/0x7a4 [35381.020493] [] rmap_walk_ksm+0x124/0x1a0 [35381.025961] [] rmap_walk+0x94/0x98 [35381.030909] [] try_to_unmap+0x100/0x124 [35381.036293] [] unmap_and_move+0x480/0x6fc [35381.041847] [] migrate_pages+0x10c/0x288 [35381.047318] [] compact_zone+0x238/0x954 [35381.052697] [] compact_zone_order+0xc4/0xe8 [35381.058427] [] try_to_compact_pages+0x160/0x294 [35381.064503] [] __alloc_pages_direct_compact+0x68/0x194 [35381.071187] [] __alloc_pages_nodemask+0xc20/0xf7c [35381.077437] [] alloc_pages_vma+0x1a4/0x1c0 [35381.083080] [] do_huge_pmd_anonymous_page+0x128/0x324 [35381.089677] [] __handle_mm_fault+0x71c/0x7e8 [35381.095492] [] handle_mm_fault+0xf8/0x194 [35381.101049] [] __get_user_pages+0x124/0x34c [35381.106777] [] populate_vma_page_range+0x90/0x9c [35381.112941] [] __mm_populate+0xc4/0x15c [35381.118322] [] SyS_mlockall+0x100/0x164 [35381.123705] Exception stack(0x800dce5f3ec0 to 0x800dce5f4000) [35381.130128] 3ec0: 0003 d6e6024cc9b87e00 be94f000 [35381.137940] 3ee0: 0002 cf6fc3c0 [35381.145753] 3f00: 00e6 cf6fc490 eeeab0f0 d6e6024cc9b87e00 [35381.153565] 3f20: be81b3c0 0020 9e53eff806b5 [35381.161379] 3f40: be94de48 a7c269b0 0011 eeeabf68 [35381.169190] 3f60: ceacfe60 be94f000 be9ba358 be7ffb80 [35381.177003] 3f80: be9ba000 be959f64 be94f000 [35381.184815] 3fa0: eeeabdb0 be5f3bf8 eeeabdb0 [35381.192628] 3fc0: a7c269b8 6000 0003 00e6 [35381.200440] 3fe0: [35381.208254] [] __sys_trace_return+0x0/0x4 [35381.213809] Disabling lock debugging due to kernel taint end-- The root cause might be what I fixed at [1]. But from arm kvm points of view, it would be better we caught the exception earlier and clearer. If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the wrong(more or less) page range. Hence it caused the "BUG: Bad page state" [1] https://lkml.org/lkml/2018/5/3/1042 Signed-off-by: jia...@hxt-semitech.com --- virt/kvm/arm/mmu.c | 2 ++ 1 file changed
[RFC] hexagon: Drop the unused variable zero_page_mask
Hexagon arch does not seem to have subscribed to _HAVE_COLOR_ZERO_PAGE framework. Hence zero_page_mask variable is not needed. Signed-off-by: Anshuman Khandual --- I will have to request some one with hexagon system to compile and test this patch. Dont have access to hardware. arch/hexagon/include/asm/pgtable.h | 1 - arch/hexagon/mm/init.c | 3 --- 2 files changed, 4 deletions(-) diff --git a/arch/hexagon/include/asm/pgtable.h b/arch/hexagon/include/asm/pgtable.h index aef02f7ca8aa..65125d0b02dd 100644 --- a/arch/hexagon/include/asm/pgtable.h +++ b/arch/hexagon/include/asm/pgtable.h @@ -30,7 +30,6 @@ /* A handy thing to have if one has the RAM. Declared in head.S */ extern unsigned long empty_zero_page; -extern unsigned long zero_page_mask; /* * The PTE model described here is that of the Hexagon Virtual Machine, diff --git a/arch/hexagon/mm/init.c b/arch/hexagon/mm/init.c index 192584d5ac2f..1495d45e472d 100644 --- a/arch/hexagon/mm/init.c +++ b/arch/hexagon/mm/init.c @@ -39,9 +39,6 @@ unsigned long __phys_offset; /* physical kernel offset >> 12 */ /* Set as variable to limit PMD copies */ int max_kernel_seg = 0x303; -/* think this should be (page_size-1) the way it's used...*/ -unsigned long zero_page_mask; - /* indicate pfn's of high memory */ unsigned long highstart_pfn, highend_pfn; -- 2.11.0
Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration
On 17-05-18, 14:02, Baolin Wang wrote:
> Hi Vinod,
>
> On 17 May 2018 at 13:14, Vinod wrote:
> > On 11-05-18, 21:06, Baolin Wang wrote:
> >> +struct sprd_dma_config {
> >> + struct dma_slave_config cfg;
> >> + u32 block_len;
> >> + u32 transcation_len;
> >
> > /s/transcation/transaction
>
> OK.
>
> >
> > now in code I see block_len and this filled by len which is sg_dma_len()?
> > So why two varibales when you are using only one.
>
> Like I explained before, we have transaction transfer, block transfer
> and fragment transfer, and we should set the length for each transfer.
> In future, we we will use these two variables in cyclic mode, but for
> prep_sg, we just make them equal to
Please add them when you have use for it. Sorry linux kernel is not a place for
dumping future use work
>
> >
> > Second, you are storing parameters programmed thru _prep call into
> > _dma_config. That is not correct.
> >
> > We use these to store channel parameters and NOT transaction parameters
> > which
> > would differ with each txn. No wonder you can only support only 1 txn :)
>
> Fine, we can remove block_len/transcation_len from 'struct
> sprd_dma_config'. Any other issues for the 'struct sprd_dma_config'?
Yes see the comments on prep_
>
> >
> > Lastly, if these are same values why not use src/dstn_max_burst?
>
> The fragment length will be filled by src/dstn_max_burst,so we can not
> use it again.
>
> >
> >> +static enum sprd_dma_datawidth
> >> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth)
> >> +{
> >> + switch (buswidth) {
> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> >> + return ffs(buswidth) - 1;
> >> + default:
> >> + return SPRD_DMA_DATAWIDTH_4_BYTES;
> >
> > Does default make sense, should we error out?
>
> Not one error, maybe we can give some warning information.
well client programmed a wrong value, so I expect this to error out.
>
> >
> >> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth)
> >> +{
> >> + switch (buswidth) {
> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> >> + return buswidth;
> >> +
> >> + default:
> >> + return SPRD_DMA_DWORD_STEP;
> >
> > Does default make sense, should we error out?
>
> Ditto.
>
> >
> >> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc
> >> *sdesc,
> >> +dma_addr_t src, dma_addr_t dst,
> >> +struct sprd_dma_config *slave_cfg)
> >> +{
> >> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
> >> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> >> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
> >> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0;
> >> + u32 src_datawidth, dst_datawidth, temp;
> >> +
> >> + if (slave_cfg->cfg.slave_id)
> >> + schan->dev_id = slave_cfg->cfg.slave_id;
> >> +
> >> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET;
> >> +
> >> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK;
> >> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
> >> + hw->wrap_ptr = temp;
> >> +
> >> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK;
> >> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
> >> + hw->wrap_to = temp;
> >> +
> >> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK;
> >> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK;
> >> +
> >> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0)
> >> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) {
> >
> > this check doesnt seem right to me, what are you trying here?
>
> This is SPRD DMA internal feature: address-fix transfer. If the src
> step and dst step both are 0 or both are not 0, that means we can not
> enable the fix mode.
> If one is 0 and another one is not, we can enable the fix mode.
A comment here would help explain this :)
>
> >
> >> + fix_en = 0;
> >> + } else {
> >> + fix_en = 1;
> >> + if (slave_cfg->src_step)
> >> + fix_mode = 1;
> >> + else
> >> + fix_mode = 0;
> >> + }
> >> +
> >> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) {
> >> + wrap_en = 1;
> >> + if (slave_cfg->wrap_to == src) {
> >> + wrap_mode = 0;
> >> + } else if (slave_cfg->wrap_to == dst) {
> >> + wrap_mode = 1;
> >> + } else {
> >> + dev_err(sdev->dma_dev.dev, "invalid wrap mode\n");
> >> + return -EINVAL;
> >> + }
> >> + }
> >> +
> >> + hw->intc = slave_
Re: [PATCH 0/3] Add support to disable sensor groups in P9
On 05/15/2018 08:32 PM, Guenter Roeck wrote: > On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote: >> This patch series adds support to enable/disable OCC based >> inband-sensor groups at runtime. The environmental sensor groups are >> managed in HWMON and the remaining platform specific sensor groups are >> managed in /sys/firmware/opal. >> >> The firmware changes required for this patch is posted below: >> https://lists.ozlabs.org/pipermail/skiboot/2018-March/010812.html >> > > Sorry for not getting back earlier. This is a tough one. > Thanks for the reply. I have tried to answer your questions according to my understanding below: > Key problem is that you are changing the ABI with those new attributes. > On top of that, the attributes _do_ make some sense (many chips support > enabling/disabling of individual sensors), suggesting that those or > similar attributes may or even should at some point be added to the ABI. > > At the same time, returning "0" as measurement values when sensors are > disabled does not seem like a good idea, since "0" is a perfectly valid > measurement, at least for most sensors. I agree. > > Given that, we need to have a discussion about adding _enable attributes to > the ABI > what is the scope, IIUC the scope should be RW and the attribute is defined for each supported sensor group > when should the attributes exist and when not, We control this currently via device-tree > do we want/need power_enable or powerX_enable or both, and so on), and We need power_enable right now > what to return if a sensor is disabled (such as -ENODATA). -ENODATA sounds good. Thanks and Regards, Shilpa Once we have an > agreement, we can continue with an implementation. > > Guenter > >> Shilpasri G Bhat (3): >> powernv:opal-sensor-groups: Add support to enable sensor groups >> hwmon: ibmpowernv: Add attributes to enable/disable sensor groups >> powernv: opal-sensor-groups: Add attributes to disable/enable sensors >> >> .../ABI/testing/sysfs-firmware-opal-sensor-groups | 34 ++ >> Documentation/hwmon/ibmpowernv | 31 - >> arch/powerpc/include/asm/opal-api.h| 4 +- >> arch/powerpc/include/asm/opal.h| 2 + >> .../powerpc/platforms/powernv/opal-sensor-groups.c | 104 - >> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + >> drivers/hwmon/ibmpowernv.c | 127 >> +++-- >> 7 files changed, 265 insertions(+), 38 deletions(-) >> create mode 100644 >> Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups >> >> -- >> 1.8.3.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] PM / devfreq: Add support for QCOM devfreq FW
The firmware present in some QCOM chipsets offloads the steps necessary for
changing the frequency of some devices (Eg: L3). This driver implements the
devfreq interface for this firmware so that various governors could be used
to scale the frequency of these devices.
Signed-off-by: Saravana Kannan
---
.../bindings/devfreq/devfreq-qcom-fw.txt | 31 ++
drivers/devfreq/Kconfig| 14 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq_qcom_fw.c | 326 +
4 files changed, 372 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
new file mode 100644
index 000..5e1aecf
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
@@ -0,0 +1,31 @@
+QCOM Devfreq FW device
+
+Some Qualcomm Technologies, Inc. (QTI) chipsets have a FW that offloads the
+steps for frequency switching. The qcom,devfreq-fw represents this FW as a
+device. Sometimes, multiple entities want to vote on the frequency request
+that is sent to the FW. The qcom,devfreq-fw-voter represents these voters as
+child devices of the corresponding qcom,devfreq-fw device.
+
+Required properties:
+- compatible: Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"
+Only for qcom,devfreq-fw:
+- reg: Pairs of physical base addresses and region sizes of
+ memory mapped registers.
+- reg-names: Names of the bases for the above registers. Expected
+ bases are: "en-base", "lut-base" and "perf-base".
+
+Example:
+
+ qcom,devfreq-l3 {
+ compatible = "qcom,devfreq-fw";
+ reg-names = "en-base", "lut-base", "perf-base";
+ reg = <0x18321000 0x4>, <0x18321110 0x600>, <0x18321920 0x4>;
+
+ qcom,cpu0-l3 {
+ compatible = "qcom,devfreq-fw-voter";
+ };
+
+ qcom,cpu4-l3 {
+ compatible = "qcom,devfreq-fw-voter";
+ };
+ };
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 6a172d3..8503018 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -113,6 +113,20 @@ config ARM_RK3399_DMC_DEVFREQ
It sets the frequency for the memory controller and reads the usage
counts
from hardware.
+config ARM_QCOM_DEVFREQ_FW
+ bool "Qualcomm Technologies Inc. DEVFREQ FW driver"
+ depends on ARCH_QCOM
+ select DEVFREQ_GOV_PERFORMANCE
+ select DEVFREQ_GOV_POWERSAVE
+ select DEVFREQ_GOV_USERSPACE
+ default n
+ help
+ The firmware present in some QCOM chipsets offloads the steps
+ necessary for changing the frequency of some devices (Eg: L3). This
+ driver implements the devfreq interface for this firmware so that
+ various governors could be used to scale the frequency of these
+ devices.
+
source "drivers/devfreq/event/Kconfig"
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 32b8d4d..f1cc8990 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARM_QCOM_DEVFREQ_FW) += devfreq_qcom_fw.o
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/devfreq_qcom_fw.c
b/drivers/devfreq/devfreq_qcom_fw.c
new file mode 100644
index 000..3e85f76
--- /dev/null
+++ b/drivers/devfreq/devfreq_qcom_fw.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INIT_RATE 3UL
+#define XO_RATE1920UL
+#define LUT_MAX_ENTRIES40U
+#define LUT_ROW_SIZE 32
+
+struct devfreq_qcom_fw {
+ void __iomem *perf_base;
+ struct devfreq_dev_profile dp;
+ struct list_head voters;
+ struct list_head voter;
+ unsigned int index;
+};
+
+static DEFINE_SPINLOCK(voter_lock);
+
+static int devfreq_qcom_fw_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct devfreq_qcom_fw *d = dev_get_drvdata(dev), *pd, *v;
+ struct devfreq_dev_profile *p = &d->dp;
+ unsigned int index;
+ un
Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration
Hi Vinod,
On 17 May 2018 at 13:14, Vinod wrote:
> On 11-05-18, 21:06, Baolin Wang wrote:
>> +struct sprd_dma_config {
>> + struct dma_slave_config cfg;
>> + u32 block_len;
>> + u32 transcation_len;
>
> /s/transcation/transaction
OK.
>
> now in code I see block_len and this filled by len which is sg_dma_len()?
> So why two varibales when you are using only one.
Like I explained before, we have transaction transfer, block transfer
and fragment transfer, and we should set the length for each transfer.
In future, we we will use these two variables in cyclic mode, but for
prep_sg, we just make them equal to
>
> Second, you are storing parameters programmed thru _prep call into
> _dma_config. That is not correct.
>
> We use these to store channel parameters and NOT transaction parameters which
> would differ with each txn. No wonder you can only support only 1 txn :)
Fine, we can remove block_len/transcation_len from 'struct
sprd_dma_config'. Any other issues for the 'struct sprd_dma_config'?
>
> Lastly, if these are same values why not use src/dstn_max_burst?
The fragment length will be filled by src/dstn_max_burst,so we can not
use it again.
>
>> +static enum sprd_dma_datawidth
>> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth)
>> +{
>> + switch (buswidth) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return ffs(buswidth) - 1;
>> + default:
>> + return SPRD_DMA_DATAWIDTH_4_BYTES;
>
> Does default make sense, should we error out?
Not one error, maybe we can give some warning information.
>
>> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth)
>> +{
>> + switch (buswidth) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return buswidth;
>> +
>> + default:
>> + return SPRD_DMA_DWORD_STEP;
>
> Does default make sense, should we error out?
Ditto.
>
>> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc
>> *sdesc,
>> +dma_addr_t src, dma_addr_t dst,
>> +struct sprd_dma_config *slave_cfg)
>> +{
>> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan);
>> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
>> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw;
>> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0;
>> + u32 src_datawidth, dst_datawidth, temp;
>> +
>> + if (slave_cfg->cfg.slave_id)
>> + schan->dev_id = slave_cfg->cfg.slave_id;
>> +
>> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET;
>> +
>> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK;
>> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
>> + hw->wrap_ptr = temp;
>> +
>> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK;
>> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK;
>> + hw->wrap_to = temp;
>> +
>> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK;
>> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK;
>> +
>> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0)
>> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) {
>
> this check doesnt seem right to me, what are you trying here?
This is SPRD DMA internal feature: address-fix transfer. If the src
step and dst step both are 0 or both are not 0, that means we can not
enable the fix mode.
If one is 0 and another one is not, we can enable the fix mode.
>
>> + fix_en = 0;
>> + } else {
>> + fix_en = 1;
>> + if (slave_cfg->src_step)
>> + fix_mode = 1;
>> + else
>> + fix_mode = 0;
>> + }
>> +
>> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) {
>> + wrap_en = 1;
>> + if (slave_cfg->wrap_to == src) {
>> + wrap_mode = 0;
>> + } else if (slave_cfg->wrap_to == dst) {
>> + wrap_mode = 1;
>> + } else {
>> + dev_err(sdev->dma_dev.dev, "invalid wrap mode\n");
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + hw->intc = slave_cfg->int_mode | SPRD_DMA_CFG_ERR_INT_EN;
>> +
>> + src_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.src_addr_width);
>> + dst_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.dst_addr_width);
>> +
>> + temp = src_datawidth << SPRD_DMA_SRC_DATAWIDTH_OFFSET;
>> + temp |= dst_datawidth << SPRD_DMA_DES_DATAWIDTH_OFFSET;
>> + temp |= slave_cfg->req_mode << SPRD_DMA_REQ_MODE_OFFSET;
>> + temp |= wrap_mode << SPRD_DMA_WRAP_SEL_OFFSET;
>> + temp |= wrap_en << SPRD_DMA_WRAP_EN_OFFSET;
>> + temp |= fix_mode << SPRD_DMA_FIX_SEL_OF
Re: [PATCH 1/5] random: fix crng_ready() test
Le 13/04/2018 à 19:00, Theodore Y. Ts'o a écrit :
On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote:
What I would like to point out that more and more folks change to
getrandom(2). As this call will now unblock much later in the boot cycle,
these systems see a significant departure from the current system behavior.
E.g. an sshd using getrandom(2) would be ready shortly after the boot finishes
as of now. Now it can be a matter minutes before it responds. Thus, is such
change in the kernel behavior something for stable?
It will have some change on the kernel behavior, but not as much as
you might think. That's because in older kernels, we were *already*
blocking until crng_init > 2 --- if the getrandom(2) call happened
while crng_init was in state 0.
Even before this patch series, we didn't wake up a process blocked on
crng_init_wait until crng_init state 2 is reached:
static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
{
...
if (crng == &primary_crng && crng_init < 2) {
invalidate_batched_entropy();
crng_init = 2;
process_random_ready_list();
wake_up_interruptible(&crng_init_wait);
pr_notice("random: crng init done\n");
}
}
This is the reason why there are reports like this: "Boot delayed for
about 90 seconds until 'random: crng init done'"[1]
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1685794
So we have the problem already. There will be more cases of this
after this patch series is applied, true. But what we have already is
an inconsistent state where if you call getrandom(2) while the kernel
is in crng_init state 0, you will block until crng_init state 2, but
if you are in crng_init state 1, you will assume the CRNG is fully
initialized.
Given the documentation of how getrandom(2) works what its documented
guarantees are, I think it does justify making its behavior both more
consistent with itself, and more consistent what the security
guarantees we have promised people.
I was a little worried that on VM's this could end up causing things
to block for a long time, but an experiment on a GCE VM shows that
isn't a problem:
[0.00] Linux version 4.16.0-rc3-ext4-9-gf6b302ebca85 (tytso@cwcc)
(gcc version 7.3.0 (Debian 7.3.0-15)) #16 SMP Thu Apr 12 16:57:17 EDT 2018
[1.282220] random: fast init done
[3.987092] random: crng init done
[4.376787] EXT4-fs (sda1): re-mounted. Opts: (null)
There are some desktops where the "crng_init done" report doesn't
happen until 45-90 seconds into the boot. I don't think I've seen
reports where it takes _minutes_ however. Can you give me some
examples of such cases?
On a powerpc embedded board which has an mpc8xx processor running at
133Mhz, I now get the startup done in more than 7 minutes instead of 30
seconds. This is due to the webserver blocking on read on /dev/random
until we get 'random: crng init done':
[0.00] Linux version 4.17.0-rc4-00415-gd2f75d40072d
(root@localhost) (gcc version 5.4.0 (GCC)) #203 PREEMPT Wed May 16
16:32:02 CEST 2018
[0.295453] random: get_random_u32 called from
bucket_table_alloc+0x84/0x1bc with crng_init=0
[1.030472] device: 'random': device_add
[1.031279] device: 'urandom': device_add
[1.420069] device: 'hw_random': device_add
[2.156853] random: fast init done
[ 462.007776] random: crng init done
This has become really critical, is there anything that can be done ?
Christophe
- Ted
P.S. Of course, in a VM environment, if the host supports virtio-rng,
the boot delay problem is completely not an issue. You just have to
enable virtio-rng in the guest kernel, which I believe is already the
case for most distro kernels.
BTW, for KVM, it's fairly simple to set it the host-side support for
virtio-rng. Just add to the kvm command-line options:
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0
Re: [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input
Hi Jacopo, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [cannot apply to renesas/next v4.17-rc5] [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/Jacopo-Mondi/arm64-dts-Draak-Enable-video-inputs-and-VIN4/20180517-102013 base: git://linuxtv.org/media_tree.git master config: arm64-defconfig (attached as .config) compiler: aarch64-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 make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/renesas/r8a77995-draak.dts:266.1-6 Label or path >> vin4 not found >> FATAL ERROR: Syntax error parsing input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] cpuidle/powernv : init all present cpus for deep states
Yes this needs to be sent to stable.
Fixes: d405a98c ("powerpc/powernv: Move cpuidle related code from setup.c
to new file")
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote:
>Hi Chao,
>
>On 05/17/18 at 11:27am, Chao Fan wrote:
>> >+/* Store the number of 1GB huge pages which user specified.*/
>> >+static unsigned long max_gb_huge_pages;
>> >+
>> >+static int parse_gb_huge_pages(char *param, char* val)
>> >+{
>> >+ char *p;
>> >+ u64 mem_size;
>> >+ static bool gbpage_sz = false;
>> >+
>> >+ if (!strcmp(param, "hugepagesz")) {
>> >+ p = val;
>> >+ mem_size = memparse(p, &p);
>> >+ if (mem_size == PUD_SIZE) {
>> >+ if (gbpage_sz)
>> >+ warn("Repeadly set hugeTLB page size of 1G!\n");
>> >+ gbpage_sz = true;
>> >+ } else
>> >+ gbpage_sz = false;
>> >+ } else if (!strcmp(param, "hugepages") && gbpage_sz) {
>> >+ p = val;
>> >+ max_gb_huge_pages = simple_strtoull(p, &p, 0);
>> >+ debug_putaddr(max_gb_huge_pages);
>> >+ }
>> >+}
>> >+
>> >+
>> > static int handle_mem_memmap(void)
>> > {
>> >char *args = (char *)get_cmd_line_ptr();
>> >@@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
>> >unsigned long image_size)
>> >}
>> > }
>> >
>> >+/* Skip as many 1GB huge pages as possible in the passed region. */
>> >+static void process_gb_huge_page(struct mem_vector *region, unsigned long
>> >image_size)
>> >+{
>> >+ int i = 0;
>> >+ unsigned long addr, size;
>> >+ struct mem_vector tmp;
>> >+
>> >+ if (!max_gb_huge_pages) {
>> >+ store_slot_info(region, image_size);
>> >+ return;
>> >+ }
>> >+
>> >+ addr = ALIGN(region->start, PUD_SIZE);
>> >+ /* If Did we raise the address above the passed in memory entry? */
>> >+ if (addr < region->start + region->size)
>> >+ size = region->size - (addr - region->start);
>> >+
>> >+ /* Check how many 1GB huge pages can be filtered out*/
>> >+ while (size > PUD_SIZE && max_gb_huge_pages) {
>> >+ size -= PUD_SIZE;
>> >+ max_gb_huge_pages--;
>>
>> The global variable 'max_gb_huge_pages' means how many huge pages
>> user specified when you get it from command line.
>> But here, everytime we find a position which is good for huge page
>> allocation, the 'max_gdb_huge_page' decreased. So in my understanding,
>> it is used to store how many huge pages that we still need to search memory
>> for good slots to filter out, right?
>> If it's right, maybe the name 'max_gb_huge_pages' is not very suitable.
>> If my understanding is wrong, please tell me.
>
>No, you have understood it very right. I finished the draft patch last
>week, but changed this variable name and the function names several
>time, still I feel they are not good. However I can't get a better name.
>
>Yes, 'max_gb_huge_pages' stores how many 1GB huge pages are expected
>from kernel command-line. And in this function it will be decreased. But
>we can't define another global variable only for decreasing in this
>place.
>
>And you can see that in this patchset I only take cares of 1GB huge
>pages. While on x86 we have two kinds of huge pages, 2MB and 1GB, why
>1GB only? Because 2MB is not impacted by KASLR, please check the code in
>hugetlb_nrpages_setup() of mm/hugetlb.c . Only 1GB huge pages need be
>pre-allocated in hugetlb_nrpages_setup(), and if you look into
>hugetlb_nrpages_setup(), you will find that it will call
>alloc_bootmem_huge_page() to allocate huge pages one by one, but not at
>one time. That is why I always add 'gb' in the middle of the global
>variable and the newly added functions.
>
>And it will answer your below questions. When walk over all memory
>regions, 'max_gb_huge_pages' is still not 0, what should we do? It's
>normal and done as expected. Here hugetlb only try its best to allocate
>as many as possible according to 'max_gb_huge_pages'. If can't fully
>satisfied, it's fine. E.g on bare-metal machine with 16GB RAM, you add
>below to command-line:
>
>default_hugepagesz=1G hugepagesz=1G hugepages=20
>
>Then it will get 14 good 1GB huge pages with kaslr disabled since [0,1G)
>and [3G,4G) are touched by bios reservation and pci/firmware reservation.
>Then this 14 huge pages are maximal value which is expected. It's not a
>bug in huge page. But with kaslr enabled, it sometime only get 13 1GB
>huge pages because KASLR put kernel into one of those good 1GB huge
>pages. This is a bug.
Thanks for your explaination, I got it.
>
>I am not very familiar with huge page handling, just read code recently
>because of this kaslr bug. Hope Luiz and people from his team can help
>correct and clarify if anything is not right. Especially the function
>names, I feel it's not good, if anyone have a better idea, I will really
>appreciate that.
>>
>> >+ i++;
>> >+ }
>> >+
>> >+ if (!i) {
>> >+ store_slot_info(region, image_size);
>> >+ return;
>> >+ }
>> >+
>> >+ /* Process the remaining regions after filtering out. */
>> >+
>> This lin
[PATCH v7 0/6] provide power off support for iMX6 with external PMIC
2018.05.17: update patches to version v7 This patch series is providing power off support for Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). As a first step the PMIC is configured to turn off the system if the standby pin is asserted. On second step we assert the standby pin. For this reason we need to use pm_power_off_prepare. Usage of stnadby pin for power off is described in official iMX6 documentation. 2018.03.05: As this patch set touches multiple subsystems I think it would make sense for Shawn Guo to take the all patch set. The only part which didn't receive an ACK is regulator stuff. So I would hope that Mark Brown can ACK it. Kind regards, Oleksij Rempel 2017.12.06: Adding Linus. Probably there is no maintainer for this patch set. No changes are made, tested on v4.15-rc1. 2017.10.27: Last version of this patch set was send at 20 Jun 2017, this is a rebase against kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments, please point me. changes: v7: - use EXPORT_SYMBOL_GPL(pm_power_off_prepare) instead of EXPORT_SYMBOL - call imx6q_suspend_finish() directly without cpu_suspend() v6: - rename imx6_pm_poweroff to imx6_pm_stby_poweroff - fix "MPIC_STBY_REQ" typo in the comment. v5: - remove useless includes from pm-imx6.c patch - add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property" patch v4: - update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..." patch - add Acked-by to "ARM: imx6q: provide documentation for new ..." patch v3: - set pm_power_off_prepare = NULL on .remove. - documentation and spelling fixes. - use %pf instead of lookup_symbol_name. Oleksij Rempel (6): ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set kernel/reboot.c: export pm_power_off_prepare regulator: pfuze100: add fsl,pmic-stby-poweroff property regulator: pfuze100-regulator: provide pm_power_off_prepare handler ARM: dts: imx6: RIoTboard provide standby on power off option .../devicetree/bindings/clock/imx6q-clock.txt | 8 ++ .../bindings/regulator/pfuze100.txt | 7 ++ arch/arm/boot/dts/imx6dl-riotboard.dts| 5 + arch/arm/mach-imx/pm-imx6.c | 25 + drivers/regulator/pfuze100-regulator.c| 92 +++ kernel/reboot.c | 1 + 6 files changed, 138 insertions(+) -- 2.17.0
[PATCH v7 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set
One of the Freescale recommended sequences for power off with external
PMIC is the following:
...
3. SoC is programming PMIC for power off when standby is asserted.
4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
See:
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
page 5083
This patch implements step 4. of this sequence.
Signed-off-by: Oleksij Rempel
---
arch/arm/mach-imx/pm-imx6.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 017539dd712b..2f5c643f62fb 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -601,6 +601,28 @@ static void __init imx6_pm_common_init(const struct
imx6_pm_socdata
IMX6Q_GPR1_GINT);
}
+static void imx6_pm_stby_poweroff(void)
+{
+ imx6_set_lpm(STOP_POWER_OFF);
+ imx6q_suspend_finish(0);
+
+ mdelay(1000);
+
+ pr_emerg("Unable to poweroff system\n");
+}
+
+static int imx6_pm_stby_poweroff_probe(void)
+{
+ if (pm_power_off) {
+ pr_warn("%s: pm_power_off already claimed %p %pf!\n",
+ __func__, pm_power_off, pm_power_off);
+ return -EBUSY;
+ }
+
+ pm_power_off = imx6_pm_stby_poweroff;
+ return 0;
+}
+
void __init imx6_pm_ccm_init(const char *ccm_compat)
{
struct device_node *np;
@@ -617,6 +639,9 @@ void __init imx6_pm_ccm_init(const char *ccm_compat)
val = readl_relaxed(ccm_base + CLPCR);
val &= ~BM_CLPCR_LPM;
writel_relaxed(val, ccm_base + CLPCR);
+
+ if (of_property_read_bool(np, "fsl,pmic-stby-poweroff"))
+ imx6_pm_stby_poweroff_probe();
}
void __init imx6q_pm_init(void)
--
2.17.0
[PATCH v7 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option
This board, as well as some other boards with i.MX6 and a PMIC, uses a
"PMIC_STBY_REQ" line to notify the PMIC about a state change.
The PMIC is programmed for a specific state change before triggering the
line.
In this case, PMIC_STBY_REQ can be used for stand by, sleep
and power off modes.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-riotboard.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts
b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 2e98c92adff7..a0e9753ee767 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -90,6 +90,10 @@
status = "okay";
};
+&clks {
+ fsl,pmic-stby-poweroff;
+};
+
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
@@ -170,6 +174,7 @@
reg = <0x08>;
interrupt-parent = <&gpio5>;
interrupts = <16 8>;
+ fsl,pmic-stby-poweroff;
regulators {
reg_vddcore: sw1ab {/*
VDDARM_IN */
--
2.17.0
[PATCH v7 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property
Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index a45ca67a9d5f..e1308346e00d 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -6,6 +6,14 @@ Required properties: - interrupts: Should contain CCM interrupt - #clock-cells: Should be <1> +Optional properties: +- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal + on power off. + Use this property if the SoC should be powered off by external power + management IC (PMIC) triggered via PMIC_STBY_REQ signal. + Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should + be using "syscon-poweroff" driver instead. + The clock consumer should specify the desired clock by having the clock ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h for the full list of i.MX6 Quad and DualLite clock IDs. -- 2.17.0
[PATCH v7 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler
On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC
about state changes. In this case internal state of PMIC must be
preconfigured for upcomming state change.
It works fine with the current regulator framework, except with the
power-off case.
This patch is providing an optional pm_power_off_prepare handler
which will configure standby state of the PMIC to disable all power lines.
In my power consumption test on RIoTBoard, I got the following results:
power off without this patch: 320 mA
power off with this patch: 2 mA
suspend to ram: 40 mA
Signed-off-by: Oleksij Rempel
---
drivers/regulator/pfuze100-regulator.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index 63922a2167e5..f6c276ed91d8 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#define PFUZE_NUMREGS 128
@@ -42,11 +43,17 @@
#define PFUZE100_COINVOL 0x1a
#define PFUZE100_SW1ABVOL 0x20
+#define PFUZE100_SW1ABMODE 0x23
#define PFUZE100_SW1CVOL 0x2e
+#define PFUZE100_SW1CMODE 0x31
#define PFUZE100_SW2VOL0x35
+#define PFUZE100_SW2MODE 0x38
#define PFUZE100_SW3AVOL 0x3c
+#define PFUZE100_SW3AMODE 0x3f
#define PFUZE100_SW3BVOL 0x43
+#define PFUZE100_SW3BMODE 0x46
#define PFUZE100_SW4VOL0x4a
+#define PFUZE100_SW4MODE 0x4d
#define PFUZE100_SWBSTCON1 0x66
#define PFUZE100_VREFDDRCON0x6a
#define PFUZE100_VSNVSVOL 0x6b
@@ -57,6 +64,13 @@
#define PFUZE100_VGEN5VOL 0x70
#define PFUZE100_VGEN6VOL 0x71
+#define PFUZE100_SWxMODE_MASK 0xf
+#define PFUZE100_SWxMODE_APS_APS 0x8
+#define PFUZE100_SWxMODE_APS_OFF 0x4
+
+#define PFUZE100_VGENxLPWR BIT(6)
+#define PFUZE100_VGENxSTBY BIT(5)
+
enum chips { PFUZE100, PFUZE200, PFUZE3000 = 3 };
struct pfuze_regulator {
@@ -489,6 +503,69 @@ static inline struct device_node *match_of_node(int index)
}
#endif
+static struct pfuze_chip *syspm_pfuze_chip;
+
+static void pfuze_power_off_prepare(void)
+{
+ dev_info(syspm_pfuze_chip->dev, "Configure standy mode for power off");
+
+ /* Switch from default mode: APS/APS to APS/Off */
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW1ABMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW1CMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW2MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW3AMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW3BMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW4MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN1VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN2VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN3VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN4VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN5VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN6VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+}
+
+static int pfuze_power_off_prepare_init(struct pfuze_chip *pfuze_chip)
+{
+ if (pfuze_chip->chip_id != PFUZE100) {
+ dev_warn(pfuze_chip->dev, "Requested pm_power_off_prepare
handler for not supported chip\n");
+ return -ENODEV;
+ }
+
+ if (pm_power_off_prepare) {
+ dev_warn(pfuze_chip->dev, "pm_power_off_prepare is already
registered.\n");
+ return -EBUSY;
+ }
+
+ if (syspm_pfuze_chip) {
+ dev_warn(pfuze_chip->dev, "syspm_pfuze_chip is already set.\n");
[PATCH v7 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property
Document the new optional "fsl,pmic-stby-poweroff" property. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt index c6dd3f5e485b..91fec1a0785d 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.txt +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt @@ -4,6 +4,13 @@ Required properties: - compatible: "fsl,pfuze100", "fsl,pfuze200", "fsl,pfuze3000" - reg: I2C slave address +Optional properties: +- fsl,pmic-stby-poweroff: if present, configure the PMIC to shutdown all + power rails when PMIC_STBY_REQ line is asserted during the power off sequence. + Use this option if the SoC should be powered off by external power + management IC (PMIC) on PMIC_STBY_REQ signal. + As opposite to PMIC_STBY_REQ boards can implement PMIC_ON_REQ signal. + Required child node: - regulators: This is the list of child nodes that specify the regulator initialization data for defined regulators. Please refer to below doc -- 2.17.0
[PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare
Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/reboot.c b/kernel/reboot.c index e4ced883d8de..83810d726f3e 100644 --- a/kernel/reboot.c +++ b/kernel/reboot.c @@ -49,6 +49,7 @@ int reboot_force; */ void (*pm_power_off_prepare)(void); +EXPORT_SYMBOL_GPL(pm_power_off_prepare); /** * emergency_restart - reboot the system -- 2.17.0
Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
Russell King - ARM Linux writes: > On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: >> Hi Russell, >> >> On 10 May 2018 at 02:40, Russell King - ARM Linux >> wrote: >> > This does not leak information from other namespaces because of the >> > uniqueness of the global PID. However, what it does leak is the value >> > of the global PID which is meaningless in the namespace. So, before >> > the event stream is delivered to userspace, this value needs to be >> > re-written to the namespace's PID value. >> >> Unfortunately that can't be done. The trace stream is compressed and >> needs to be decompressed using an external library. I think the only >> option is to return an error if a user is trying to use this feature >> from a namespace. > > That sounds like a sensible approach, and that should get rid of the > vpid stuff too. > > Eric, would this solve all your concerns? It does, and I have given my ack to the respin. I am moderately concerned about using the global pid with hardware. But pids are a core abstraction that aren't going anywhere. As long as hardware does not impose constraints on pids that software already does not we should be fine. Eric
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On 05/17/18 at 07:12am, damian wrote:
> On Wed, 16. May 18:05, Baoquan He wrote:
> > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to
> > handle conflict between KASLR and huge pages, will be used in the next
> > patch.
> >
> > Function parse_gb_huge_pages() is used to parse kernel command-line to get
> > how many 1GB huge pages have been specified. A static global variable
> > 'max_gb_huge_pages' is added to store the number.
> >
> > And process_gb_huge_page() is used to skip as many 1GB huge pages as
> > possible
> > from the passed in memory region according to the specified number.
> >
> > Signed-off-by: Baoquan He
> > ---
> > arch/x86/boot/compressed/kaslr.c | 71
> >
> > 1 file changed, 71 insertions(+)
> >
> > diff --git a/arch/x86/boot/compressed/kaslr.c
> > b/arch/x86/boot/compressed/kaslr.c
> > index a0a50b91ecef..13bd879cdc5d 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -215,6 +215,32 @@ static void mem_avoid_memmap(char *str)
> > memmap_too_large = true;
> > }
> >
> > +/* Store the number of 1GB huge pages which user specified.*/
> > +static unsigned long max_gb_huge_pages;
> > +
> > +static int parse_gb_huge_pages(char *param, char* val)
> > +{
> > + char *p;
> > + u64 mem_size;
> > + static bool gbpage_sz = false;
> > +
> > + if (!strcmp(param, "hugepagesz")) {
> > + p = val;
> > + mem_size = memparse(p, &p);
> > + if (mem_size == PUD_SIZE) {
> > + if (gbpage_sz)
> > + warn("Repeadly set hugeTLB page size of 1G!\n");
> > + gbpage_sz = true;
> > + } else
> > + gbpage_sz = false;
> > + } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> > + p = val;
> > + max_gb_huge_pages = simple_strtoull(p, &p, 0);
> > + debug_putaddr(max_gb_huge_pages);
> > + }
> > +}
> Hello,
>
> the return value is missing for the function or not ?
Thanks, very good catch. It should be 'static void ', no return value
since we didn't check it. Will update when repost.
>
> > +
> > +
> > static int handle_mem_memmap(void)
> > {
> > char *args = (char *)get_cmd_line_ptr();
> > @@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
> > unsigned long image_size)
> > }
> > }
> >
> > +/* Skip as many 1GB huge pages as possible in the passed region. */
> > +static void process_gb_huge_page(struct mem_vector *region, unsigned long
> > image_size)
> > +{
> > + int i = 0;
> > + unsigned long addr, size;
> > + struct mem_vector tmp;
> > +
> > + if (!max_gb_huge_pages) {
> > + store_slot_info(region, image_size);
> > + return;
> > + }
> > +
> > + addr = ALIGN(region->start, PUD_SIZE);
> > + /* If Did we raise the address above the passed in memory entry? */
> > + if (addr < region->start + region->size)
> > + size = region->size - (addr - region->start);
> > +
> > + /* Check how many 1GB huge pages can be filtered out*/
> > + while (size > PUD_SIZE && max_gb_huge_pages) {
> > + size -= PUD_SIZE;
> > + max_gb_huge_pages--;
> > + i++;
> > + }
> > +
> > + if (!i) {
> > + store_slot_info(region, image_size);
> > + return;
> > + }
> > +
> > + /* Process the remaining regions after filtering out. */
> > +
> > + if (addr >= region->start + image_size) {
> > + tmp.start = region->start;
> > + tmp.size = addr - region->start;
> > + store_slot_info(&tmp, image_size);
> > + }
> > +
> > + size = region->size - (addr - region->start) - i * PUD_SIZE;
> > +if (size >= image_size) {
> > + tmp.start = addr + i*PUD_SIZE;
> > + tmp.size = size;
> > + store_slot_info(&tmp, image_size);
> > +}
> > +}
> > +
> > static unsigned long slots_fetch_random(void)
> > {
> > unsigned long slot;
> > --
> > 2.13.6
> >
Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
On 05/17/2018 12:08 AM, Dmitry Torokhov wrote:
On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote:
On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
@@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
- /* Set input abs params to match backend screen res */
- abs = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_FEAT_ABS_POINTER, 0);
- ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_WIDTH,
- ptr_size[KPARAM_X]);
- ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_HEIGHT,
- ptr_size[KPARAM_Y]);
- if (abs) {
- ret = xenbus_write(XBT_NIL, dev->nodename,
- XENKBD_FIELD_REQ_ABS_POINTER, "1");
- if (ret) {
- pr_warn("xenkbd: can't request abs-pointer\n");
- abs = 0;
- }
- }
+ /*
+* The below are reverse logic, e.g. if the feature is set, then
+* do not expose the corresponding virtual device.
+*/
+ with_kbd = !xenbus_read_unsigned(dev->nodename,
+XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
- touch = xenbus_read_unsigned(dev->nodename,
-XENKBD_FIELD_FEAT_MTOUCH, 0);
- if (touch) {
+ with_ptr = !xenbus_read_unsigned(dev->nodename,
+XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
+
+ /* Direct logic: if set, then create multi-touch device. */
+ with_mtouch = xenbus_read_unsigned(dev->nodename,
+ XENKBD_FIELD_FEAT_MTOUCH, 0);
+ if (with_mtouch) {
ret = xenbus_write(XBT_NIL, dev->nodename,
XENKBD_FIELD_REQ_MTOUCH, "1");
if (ret) {
pr_warn("xenkbd: can't request multi-touch");
- touch = 0;
+ with_mtouch = 0;
}
}
Does it make sense to still end up calling xenkbd_connect_backend() when
all interfaces (keyboard, pointer, and multitouch) are disabled? Should
we do:
if (!(with_kbd || || with_ptr || with_mtouch))
return -ENXIO;
?
It does make sense. Then we probably need to move all xenbus_read_unsigned
calls to the very beginning of the .probe, so no memory allocations are made
which will be useless if we return -ENXIO, e.g. something like
static int xenkbd_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
int ret, i;
bool with_mtouch, with_kbd, with_ptr;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
if (!(with_kbd | with_ptr | with_mtouch))
return -ENXIO;
Does the above looks ok?
Yes. Another option is to keep the check where I suggested and do
if (...) {
ret = -ENXIO;
goto error;
}
Whichever you prefer is fine with me.
I will go with the change you suggested and
I'll send v4 tomorrow then.
Thanks.
Thank you,
Oleksandr
Re: [PATCH 11/40] ipv6/flowlabel: simplify pid namespace lookup
Christoph Hellwig writes:
> On Sat, May 05, 2018 at 07:37:33AM -0500, Eric W. Biederman wrote:
>> Christoph Hellwig writes:
>>
>> > The shole seq_file sequence already operates under a single RCU lock pair,
>> > so move the pid namespace lookup into it, and stop grabbing a reference
>> > and remove all kinds of boilerplate code.
>>
>> This is wrong.
>>
>> Move task_active_pid_ns(current) from open to seq_start actually means
>> that the results if you pass this proc file between callers the results
>> will change. So this breaks file descriptor passing.
>>
>> Open is a bad place to access current. In the middle of read/write is
>> broken.
>>
>>
>> In this particular instance looking up the pid namespace with
>> task_active_pid_ns was a personal brain fart. What the code should be
>> doing (with an appropriate helper) is:
>>
>> struct pid_namespace *pid_ns = inode->i_sb->s_fs_info;
>>
>> Because each mount of proc is bound to a pid namespace. Looking up the
>> pid namespace from the super_block is a much better way to go.
>
> What do you have in mind for the helper? For now I've thrown it in
> opencoded into my working tree, but I'd be glad to add a helper.
>
> struct pid_namespace *proc_pid_namespace(struct inode *inode)
> {
> // maybe warn on for s_magic not on procfs??
> return inode->i_sb->s_fs_info;
> }
That should work. Ideally out of line for the proc_fs.h version.
Basically it should be a cousin of PDE_DATA.
Eric
Re: [linux-firmware] Version in WHENCE file
On Mon, 2018-05-07 at 09:47 +0200, Sedat Dilek wrote: > On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho com> wrote: > > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: > > > Hi Luca, > > > > > > I hope I catched the correct MLs (not sure if linux-firmware has > > > a > > > ML, > > > I did not found any in the MAINTAINERS file). > > > > > > I have seen that in the WHENCE file there is "Version" with and > > > without ":", mostly iwlwifi ucodes. > > > > > > As an example: > > > > > > File: iwlwifi-8265-36.ucode > > > -Version 36.e91976c0.0 > > > +Version: 36.e91976c0.0 > > > > > > I don't know the workflow: Do you want to fix it in your tree or > > > directly in linux-firmware.git upstream? > > > My attached patch is against upstream. > > > > Thanks, Sedat! > > > > I'm going to send a new pull-request this week, so I can include > > your > > patch in my tree and as part of the pull-request. > > > > -- > > Cheers, > > Luca. > > OK, Thanks. > Attached Patch v2 is against your tree [1]. > It differs from v1 against upstream. You need to write a proper commit message and sign it off so I can apply it. -- Luca.
Re: [PATCH] dmaengine: qcom: bam_dma: check if the runtime pm enabled
On 14-05-18, 17:18, Srinivas Kandagatla wrote:
> Disabling pm runtime at probe is not sufficient to get BAM working
> on remotely controller instances. pm_runtime_get_sync() would return
> -EACCES in such cases.
> So check if runtime pm is enabled before returning error from bam functions.
>
> Fixes: 5b4a68952a89 ("dmaengine: qcom: bam_dma: disable runtime pm on remote
> controlled")
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/dma/qcom/bam_dma.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index d29275b97e84..5f4babebc508 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -540,7 +540,7 @@ static void bam_free_chan(struct dma_chan *chan)
> int ret;
>
> ret = pm_runtime_get_sync(bdev->dev);
> - if (ret < 0)
> + if (pm_runtime_enabled(bdev->dev) && ret < 0)
would it make sense to first check enabled and do _get_sync()
if (pm_runtime_enabled()) {
ret = pm_runtime_get_sync() {
...
}
}
thus making clear in code that we do calls only when it is enabled. Also you can
add a local macro for this code and use that rather than copy pasting :)
--
~Vinod
