Re: [PATCH v2 BUGFIX] ARM: dts: imx6ull: fix the imx6ull-14x14-evk configuration
On Fri, Jan 26, 2018 at 09:52:18AM +0100, Lothar Waßmann wrote: > imx6ull-14x14-evk.dts currently includes the imx6ul.dtsi file for an > i.MX6ULL SoC which is plain wrong. > > Rename the current imx6ul-14x14-evk.dts to .dtsi and include it from > imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts, so that both can > include the appropriate SoC specific (imx6ul.dtsi/imx6ull.dtsi) file. > > Signed-off-by: Lothar Waßmann Which base is the patch generated against? I cannot apply it to any branch in my tree. Shawn
Re: [PATCH 02/20] KVM: PPC: Book3S PR: Fix broken select due to misspelling
On Mon, Feb 05, 2018 at 05:58:59AM +0100, Ulf Magnusson wrote:
> On Mon, Feb 5, 2018 at 5:48 AM, Paul Mackerras wrote:
> > On Mon, Feb 05, 2018 at 02:21:14AM +0100, Ulf Magnusson wrote:
> >> Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
> >> on non-pseries platforms") added a reference to the globally undefined
> >> symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
> >> probably intended.
> >>
> >> Change PPC_SERIES to PPC_PSERIES.
> >>
> >> Discovered with the
> >> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> >> script.
> >>
> >> Signed-off-by: Ulf Magnusson
> >
> > Acked-by: Paul Mackerras
> >
> > Which tree is this series going into?
> >
> > Paul.
>
> I didn't have a particular one in mind. I imagined people would pick
> up individual patches into the trees that make the most sense. It was
> easiest to do the undefined symbol removal as a kernel-wide batch job.
OK, I'll take this one then.
Paul.
Re: [PATCH] ARM: dts: use 'atmel' as at24 manufacturer for imx6qdl-rex
On Wed, Jan 24, 2018 at 10:31:16PM +0100, Bartosz Golaszewski wrote: > Using 'at' as the part of the compatible string is now > deprecated. Use a correct string: 'atmel,'. > > Signed-off-by: Bartosz Golaszewski Applied, thanks.
Re: [PATCH] ARM: dts: use 'atmel' as at24 manufacturer for imx6qdl-zii-rdu2
On Wed, Jan 24, 2018 at 10:28:23PM +0100, Bartosz Golaszewski wrote: > Using 'at' as the part of the compatible string is now > deprecated. Use a correct string: 'atmel,'. > > Signed-off-by: Bartosz Golaszewski Applied, thanks.
Re: [PATCH] ARM: dts: fix the at24 compatible string in imx6q-h100
On Wed, Jan 24, 2018 at 10:31:48PM +0100, Bartosz Golaszewski wrote: > Using 'at24' as fallback is now deprecated - use the full > 'atmel,' string. > > Signed-off-by: Bartosz Golaszewski Applied, thanks.
Re: [PATCH v3 1/3] ARM: dts: imx: Pass empty memory size on board dts
On Wed, Jan 24, 2018 at 11:22:12AM -0200, Marco Franchi wrote: > In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass > 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory > size. > > Signed-off-by: Marco Franchi Applied all, thanks.
Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit
On 2018/2/5 14:40, Yunlong Song wrote:
> Is it necessary to make atomic commit fail? What's the problem of this
> patch (no lock at all and does not make atomic fail)? These two patches
> aims to provide ability to gc old blocks of opened atomic file, with no
> affection to original atomic commit and no mix with inmem pages.
>
> On 2018/2/5 14:29, Chao Yu wrote:
>> On 2018/2/5 10:53, Yunlong Song wrote:
>>> Is it necessary to add a lock here? What's the problem of this patch (no
>>> lock at all)? Anyway, the problem is expected to be fixed asap, since
>>> attackers can easily write an app with only atomic start and no atomic
>>> commit, which will cause f2fs run into loop gc if the disk layout is
>>> much fragmented, since f2fs_gc will select the same target victim all
>>> the time (e.g. one block of target victim belongs to the opened atomic
>>> file, and it will not be moved and do_garbage_collect will finally
>>> return 0, and that victim is selected again next time) and goto gc_more
>>> time and time again, which will block all the fs ops (all the fs ops
>>> will hang up in f2fs_balance_fs).
>>
>> Hmm.. w/ original commit log and implementation, I supposed that the patch
>> intended to fix to make atomic write be isolated from other IOs like GC
>> triggered writes...
>>
>> Alright, we have discuss the problem before in below link:
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html
>>
>> I meant, for example:
>>
>> f2fs_ioc_start_atomic_write()
>> inode->atomic_open_time = get_mtime();
>>
>> f2fs_ioc_commit_atomic_write()
>> inode->atomic_open_time = 0;
>>
>> f2fs_balance_fs_bg()
>> for_each_atomic_open_file()
>> if (inode->atomic_open_time &&
>> inode->atomic_open_time > threshold) {
>> drop_inmem_pages();
>> f2fs_msg();
>> }
>>
>> threshold = 30s
>>
>> Any thoughts?
>>
>> Thanks,
>>
>>>
>>> On 2018/2/4 22:56, Chao Yu wrote:
On 2018/2/3 10:47, Yunlong Song wrote:
> If inode has already started to atomic commit, then set_page_dirty will
> not mix the gc pages with the inmem atomic pages, so the page can be
> gced safely.
Let's avoid Ccing fs mailing list if the patch didn't change vfs common
codes.
As you know, the problem here is mixed dnode block flushing w/o
writebacking
gced data block, result in making transaction unintegrated.
OK, details as I explained before:
atomic_commit GC
- file_write_and_wait_range
- move_data_block
- f2fs_submit_page_write
- f2fs_update_data_blkaddr
- set_page_dirty
- fsync_node_pages
1. atomic writes data page #1 & update node #1
2. GC data page #2 & update node #2
3. page #1 & node #1 & #2 can be committed into nand flash before page #2 be
committed.
After a sudden pow-cut, database transaction will be inconsistent. So I think
there will be better to exclude gc/atomic_write to each other, with a lock
instead of flag checking.
Thanks,
So how about just using dio_rwsem[WRITE] during atomic committing to
exclude
GCing data block of atomic opened file?
Thanks,
>
> Signed-off-by: Yunlong Song
> ---
>fs/f2fs/data.c | 5 ++---
>fs/f2fs/gc.c | 6 --
>2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 7435830..edafcb6 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode,
> struct f2fs_io_info *fio)
> return true;
> if (S_ISDIR(inode->i_mode))
> return true;
> - if (f2fs_is_atomic_file(inode))
> - return true;
> if (fio) {
> if (is_cold_data(fio->page))
> return true;
> if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
> return true;
> - }
> + } else if (f2fs_is_atomic_file(inode))
> + return true;
> return false;
>}
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index b9d93fd..84ab3ff 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode,
> block_t bidx,
> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
> goto out;
>
> - if (f2fs_is_atomic_file(inode))
> + if (f2fs_is_atomic_file(inode) &&
> + !f2fs_is_commit_atomic_write(inode))
> goto out;
>
> if (f2fs_is_pinned_file(inode)) {
> @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode,
> block_t bidx, int gc_type,
>
Re: [PATCH 1/5] backlight: lp8788: document sysfs attributes
On Thu, Feb 01, 2018 at 11:36:04AM +, Daniel Thompson wrote:
> On Wed, Jan 31, 2018 at 01:51:21PM +0200, Jani Nikula wrote:
> > On Wed, 31 Jan 2018, Daniel Thompson wrote:
> > > On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote:
> > >> Add documentation for sysfs interfaces of lp8788 backlight driver by
> > >> looking through the code and the git commit history.
> > >>
> > >> Signed-off-by: Aishwarya Pant
> > >> ---
> > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++
> > >> 1 file changed, 10 insertions(+)
> > >> create mode 100644
> > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >>
> > >> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> new file mode 100644
> > >> index ..c0e565c8d63d
> > >> --- /dev/null
> > >> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > >> @@ -0,0 +1,10 @@
> > >> +sysfs interface for Texas Instruments lp8788 mfd backlight driver
> > >> +-
> > >> +
> > >> +What: /sys/class/backlight//bl_ctl_mode
> > >> +Date: Feb, 2013
> > >> +KernelVersion: v3.10
> > >> +Contact:Milo Kim
> > >> +Description:
> > >> +(RO) Displays whether the brightness is controlled by
> > >> the PWM
> > >> +input("PWM based") or the I2C register("Register
> > >> based").
> > >
> > > I rather dislike drivers with this type of "bonus" sysfs controls. I'm
> > > struggling to come up with any reason why the userspace would want to
> > > read this control (and I think bl_ctl_mode gets the fewest hits after
> > > searching with google hits of any search I've tried) . It looks to me
> > > like this is debug information that should never have gone into sysfs
> > > at all.
> >
> > Agreed. I think the same holds for the other extra sysfs attributes. At
> > worst, having these prevents the backlight class from adding the names
> > later on, which is just backwards.
>
> The problem is that they do exist...
>
> For controls which appear to be misplaced debug attributes I think I am
> happy to nuke the values entirely. It is extremely improbable that any
> userspace will notice.
>
> Unfortunately some of the controls look like they could be poked by an
> custom userspace so I'm quite so confident about nuking these ones...and if we
> don't nuke we should document (so thanks Aishwarya!).
>
Hi
Thanks for reviewing. Should I take it to assume that we would like to keep the
debug-like attributes in documentation for now?
Aishwarya
>
> Daniel.
Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
On Mon, 2018-02-05 at 16:03 +0900, Masahiro Yamada wrote: > 2018-02-05 15:41 GMT+09:00 Knut Omang : > > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote: > >> Add scripts/runchecks which has generic support for running > >> checker tools in a convenient and user friendly way that > >> the author hopes can contribute to rein in issues detected > >> by these tools in a manageable and convenient way. > >> > >> scripts/runchecks provides the following basic functionality: > >> > >> * Makes it possible to selectively suppress output from individual > >> checks on a per file or per subsystem basis. > >> * Unifies output and suppression input from different tools > >> by providing a single unified syntax and presentation for the > >> underlying tools in the style of "scripts/checkpatch.pl --show-types". > >> * Allows selective run of one, or more (or all) configured tools > >> for each file. > >> > >> In the Makefile system, the sparse specific setup has been replaced > >> by setup for runchecks. > > > > Hi all, > > > > - Anything more I can/need to do to bring this forward? > > - Any quiet concerns? > > > > I realize it is a subsystem crossing change, > > Is it? Only Kbuild this is related to. Ok, I see! > > and a lot going on elsewhere, > > nevertheless I believe this is a time saver in the slightly longer run, > > as it allows automation of checking, even without a "perfect" > > code base to begin with. > > > > Sorry for the delay. I understand, no problem - just was afraid it was about to get lost in between subsystems, > I have not been able to find time to dive into the detail yet. > (Actually, I tried to do that for v2 or v3, where Python code was so dirty, > then consumed my time to figure out what the code was trying to do) Hopefully v4 is cleaner from a Python code style point of view at least, but let me know if you have any particular part of the code in mind wrt readability. Also hopefully the docs should be of help. > I find my concern here: > https://lkml.org/lkml/2018/1/5/497 I believe I have addressed the issues there in v4. > Anyway, I will take a look again when I find some time. > You do not need to take care of the detail until I request to do so. Ok, thanks a lot for your time and the quick response now! Best regards, Knut
Re: [PATCH 2/2] KVM: X86: Add per-VM no-HLT-exiting capability
2018-02-03 3:02 GMT+08:00 Radim Krčmář : > 2018-02-01 23:11-0800, Wanpeng Li: >> From: Wanpeng Li >> >> If host CPUs are dedicated to a VM, we can avoid VM exits on HLT. >> This patch adds the per-VM non-HLT-exiting capability. >> >> Cc: Paolo Bonzini >> Cc: Radim Krčmář >> Signed-off-by: Wanpeng Li >> --- > > SMM handling needs more work: I think we should vmx_clear_hlt() upon SMI > and RSM needs to implement auto halt restart (AMD might differ). Do it in v2. > > And also look if we don't need vmx_clear_hlt() around INIT handling, You are right, the guest stuck after utilizing system_reset command in qemu monitor w/o vmx_clear_hlt() around INIT handling, fix it in v2. Regards, Wanpeng Li
Re: [PATCH] Documentation/ABI: update infiniband sysfs interfaces
On Thu, Feb 01, 2018 at 12:48:18PM -0500, Hal Rosenstock wrote: > On 2/1/2018 8:32 AM, Aishwarya Pant wrote: > > Add documentation for core and hardware specific infiniband interfaces. > > The descriptions have been collected from git commit logs, reading > > through code and data sheets. Some drivers have incomplete doc and are > > annotated with the comment '[to be documented]'. > > > > Signed-off-by: Aishwarya Pant > > --- > > Documentation/ABI/testing/sysfs-class-infiniband | 755 > > +++ > > 1 file changed, 755 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-class-infiniband > > b/Documentation/ABI/testing/sysfs-class-infiniband > > index a86abe66a316..2e150169633b 100644 > > --- a/Documentation/ABI/testing/sysfs-class-infiniband > > +++ b/Documentation/ABI/testing/sysfs-class-infiniband > > @@ -1,3 +1,194 @@ > > +sysfs interface common for all infiniband devices > > +- > > + > > +What: /sys/class/infiniband//node_type > > +What: /sys/class/infiniband//node_guid > > +What: /sys/class/infiniband//sys_image_guid > > +Date: Apr, 2005 > > +KernelVersion: v2.6.12 > > +Contact: linux-r...@vger.kernel.org > > +Description: > > + node_type: (RO) Node type (CA, RNIC, usNIC, usNIC UDP, > > + switch or router) > > + > > + node_guid: (RO) Node GUID > > + > > + sys_image_guid: (RO) System image GUID > > + > > + > > +What: /sys/class/infiniband//node_desc > > +Date: Feb, 2006 > > +KernelVersion: v2.6.17 > > +Contact: linux-r...@vger.kernel.org > > +Description: > > + (RW) Update the node description with information such as the > > + node's hostname, so that IB network management software can tie > > + its view to the real world. > > + > > + > > +What: /sys/class/infiniband//fw_ver > > +Date: Jun, 2016 > > +KernelVersion: v4.10 > > +Contact: linux-r...@vger.kernel.org > > +Description: > > + (RO) Display firmware version > > + > > + > > +What: /sys/class/infiniband//ports//lid > > +What: /sys/class/infiniband//ports//rate > > +What: > > /sys/class/infiniband//ports//lid_mask_count > > +What: /sys/class/infiniband//ports//sm_sl > > +What: /sys/class/infiniband//ports//sm_lid > > +What: /sys/class/infiniband//ports//state > > +What: > > /sys/class/infiniband//ports//phys_state > > +What: /sys/class/infiniband//ports//cap_mask > > +Date: Apr, 2005 > > +KernelVersion: v2.6.12 > > +Contact: linux-r...@vger.kernel.org > > +Description: > > + > > + lid:(RO) Port LID > > + > > + rate: (RO) Port data rate (active width * active > > + speed) > > + > > + lid_mask_count: (RO) Port LID mask count > > + > > + sm_slL (RO) Subnet manager SL for port's subnet > > Typo sm_sl: > > > + > > + sm_lid: (RO) Subnet manager LID for port's subnet > > + > > + state: (RO) Port state (DOWN, INIT, ARMED, ACTIVE or > > + ACTIVE_DEFER> + > > + phys_state: (RO) Port physical state (Sleep, Polling, > > + LinkUp, etc) > > + > > + cap_mask: (RO) Port capability mask > > 2 bits here are settable: IsCommunicationManagementSupported and IsSM. Hi Sorry, I don't quite understand this. cap_mask is a read only value which indicates the supported functions. So the two bits- IsCommunicationManagementSupported and IsSM, should not be setttable? Aishwarya
Re: [GIT PULL tools] Linux kernel memory model
On Sun, Feb 04, 2018 at 11:37:59AM -0500, Alan Stern wrote: > On Sun, 4 Feb 2018, Paul E. McKenney wrote: > > > --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > > +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > > @@ -1,5 +1,11 @@ > > C CoRW+poonceonce+Once > > > > +(* > > + * Test of read-write coherence, that is, whether or not a read from a > > + * given variable followed by a write to that same variable are ordered. > > The syntax of this sentence is a little tortured. Suggestion: > > ... whether or not a read from a given variable and a later > write to that same variable are ordered. > > > + * This should be ordered, that is, this test should be forbidden. > > s/This/They/ Good catches, both changed as suggested. > > --- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus > > +++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus > > @@ -1,5 +1,11 @@ > > C CoWR+poonceonce+Once > > > > +(* > > + * Test of write-read coherence, that is, whether or not a write to a > > + * given variable followed by a read from that same variable are ordered. > > Same syntax issue as above. Analogous fixed applied! > > --- a/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus > > +++ b/tools/memory-model/litmus-tests/ISA2+poonceonces.litmus > > @@ -1,5 +1,13 @@ > > C ISA2+poonceonces > > > > +(* > > + * Given a release-acquire chain ordering the first process's store > > + * against the last process's load, is ordering preserved if all of the > > + * smp_store_release() invocations be replaced by WRITE_ONCE() and all > > s/be/are/ > > > + * of the smp_load_acquire() invocations be replaced by READ_ONCE()? > > s/be/are/ Good eyes, fixed! > > --- a/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus > > +++ b/tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus > > @@ -1,5 +1,14 @@ > > C LB+ctrlonceonce+mbonceonce > > > > +(* > > + * This litmus test demonstrates that lightweight ordering suffices for > > + * the load-buffering pattern, in other words, preventing all processes > > + * reading from the preceding process's write. In this example, the > > + * combination of a control dependency and a full memory barrier are to do > > s/are to/are enough to/ Ditto! > > --- a/tools/memory-model/litmus-tests/MP+polocks.litmus > > +++ b/tools/memory-model/litmus-tests/MP+polocks.litmus > > @@ -1,5 +1,14 @@ > > C MP+polocks > > > > +(* > > + * This litmus test demonstrates how lock acquisitions and releases can > > + * stand in for smp_load_acquire() and smp_store_release(), respectively. > > + * In other words, when holding a given lock (or indeed after relaasing a > > s/relaasing/releasing/ > > > + * given lock), a CPU is not only guaranteed to see the accesses that other > > + * CPOs made while previously holding that lock, it are also guaranteed > > s/CPO/CPU/ > s/are/is/ Andrea beat you to the first two of these three, but fixed. ;-) > > + * to see all prior accesses by those other CPUs. > > Doesn't say whether the test should be allowed. This is true of several > other litmus tests too. Added the "Forbidden". You know, I should use the machine-generated syntax that my scripts recognize, shouldn't I? Doing that as well. > > --- a/tools/memory-model/litmus-tests/MP+porevlocks.litmus > > +++ b/tools/memory-model/litmus-tests/MP+porevlocks.litmus > > @@ -1,5 +1,14 @@ > > C MP+porevlocks > > > > +(* > > + * This litmus test demonstrates how lock acquisitions and releases can > > + * stand in for smp_load_acquire() and smp_store_release(), respectively. > > + * In other words, when holding a given lock (or indeed after relaasing a > > s/relaasing/releasing > > > + * given lock), a CPU is not only guaranteed to see the accesses that other > > + * CPOs made while previously holding that lock, it are also guaranteed > > s/CPO/CPU/ > s/are/is/ Fixed! > > --- a/tools/memory-model/litmus-tests/R+poonceonces.litmus > > +++ b/tools/memory-model/litmus-tests/R+poonceonces.litmus > > @@ -1,5 +1,11 @@ > > C R+poonceonces > > > > +(* > > + * This is the unordered (via smp_mb()) version of one of the classic > > Does "unordered (via smp_mb())" mean that the test uses smp_mb() to > "unorder" the accesses, or does it mean that the test doesn't use smp_mb() > to order the accesses? That is a bit ambiguous... Though I would be interested in seeing a litmus test that really did use smp_mb() to unorder the accesses! How about the following? * Result: Sometimes * * This is the unordered (thus lacking smp_mb()) version of one of the * classic counterintuitive litmus tests that illustrates the effects of * store propagation delays. > > --- a/tools/memory-model/litmus-tests/S+poonceonces.litmus > > +++ b/tools/memory-model/litmus-tests/S+poonceonces.litmus > > @@ -1,5 +1,13 @@ > > C S+poonceonces > > > > +(* > > + * Starting with a two-process re
Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings
On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez
>>
>> The RCC block is responsible of the management of the clock and reset
>> generation for the complete circuit.
>>
>> Signed-off-by: Gabriel Fernandez
>> ---
>> .../devicetree/bindings/mfd/st,stm32-rcc.txt | 85
>> ++
>> 1 file changed, 85 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> new file mode 100644
>> index 000..28017a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>> +==
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Please also refer to clock-bindings.txt for common clock controller
>> +binding usage.
>> +
>> +
>> +Required properties:
>> +- compatible: "simple-mfd", "syscon"
>
>> +- reg: should be register base and length as documented in the datasheet
>> +
>> +- Sub-nodes:
>> + - compatible: "st,stm32mp1-rcc-clk"
>> +- #clock-cells: 1, device nodes should specify the clock in their
>> + "clocks" property, containing a phandle to the clock device node,
>> + an index specifying the clock to use.
>> +
>> + - compatible: "st,stm32mp1-rcc-rst"
>> +- #reset-cells: Shall be 1
>> +
>> +Example:
>> +rcc: rcc@5000 {
>> +compatible = "syscon", "simple-mfd";
>> +reg = <0x5000 0x1000>;
>> +
>> +rcc_clk: rcc-clk@5000 {
>> +#clock-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-clk";
>> +};
>> +
>> +rcc_rst: rcc-reset@5000 {
> You should not have the same unit-address twice.
i can change if you want into:
rcc: rcc@5000 {
compatible = "syscon", "simple-mfd";
reg = <0x5000 0x1000>;
rcc_clk: rcc-clk {
#clock-cells = <1>;
compatible = "st,stm32mp1-rcc-clk";
};
rcc_rst: rcc-reset {
#reset-cells = <1>;
compatible = "st,stm32mp1-rcc-rst";
};
BR
Gabriel
> IMO, this should just be:
>
> rcc: rcc@5000 {
> compatible = "st-stm32mp1-rcc";
> reg = <0x5000 0x1000>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> };
>
> There's no reason a node can't provide more than 1 function.
>
>
>> +#reset-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-rst";
>> +};
>> +};
>> +
>> +Specifying clocks
>> +=
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
>> +tree sources.
>> +
>> +Example:
>> +
>> +/* Accessing DMA1 clock */
>> +... {
>> +clocks = <&rcc_clk DMA1>
>> +};
>> +
>> +/* Accessing SPI6 kernel clock */
>> +... {
>> +clocks = <&rcc_clk SPI6_K>
>> +};
> Other than the path to header, the clock binding explains all this. No
> need to duplicate here.
>
>> +
>> +Specifying softreset control of devices
>> +===
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index
>> specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example on STM32MP1, for LTDC reset:
>> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
>> + = 0x180 / 4 * 32 + 0 = 3072
>> +
>> +The list of valid indices for STM32MP1 is available in:
>> +include/dt-bindings/reset-controller/stm32mp1-resets.h
>> +
>> +This file implements defines like:
>> +#define LTDC_R 3072
>> +
>> +example:
>> +
>> +ltdc {
>> +resets = <&rcc_rst LTDC_R>;
>> +};
>> --
>> 1.9.1
>>
Re: [PATCHv2 0/8] hw_breakpoint: Breakpoint modification fixes and new modify ioctl
PING thanks, jirka On Wed, Nov 29, 2017 at 09:38:45AM +0100, Jiri Olsa wrote: > hi, > Milind Chabbi introduced new ioctl interface to change > live breakpoint [1]. It allows to change its bp_addr, > bp_len and bp_type throught new ioctl for perf breakpoint > event. > > We already have a kernel interface for this via > modify_user_hw_breakpoint function. This function however > does not update the breakpoint slot counts. > > So when the same functionality was exposed to user space > (Milind's change), with simple test program I could put wrong > slots count on arm server [2] and ended up with no breakpoints > available on the system. Note it's not an issue on x86, because > it shares slot single counter for both data and inst types > (CONFIG_HAVE_MIXED_BREAKPOINTS_REGS). > > This patchset contains my fixes for keeping breakpoint slots > count updated. On top of it there's Milind's change for new > _IOC_MODIFY_ATTRIBUTES ioctl interface to change a breakpoint. > > As I mentioned above there're kernel users of > modify_user_hw_breakpoint function, all ptrace related > AFAICS, which could got broken.. so cc-ing Oleg ;-) > > I ran gdb and strace tests suites and got same amount of > skip/fail tests as when I run them on unpatched machine, > so I assume nothing new got broken. > > It's also available in here: > https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/bp > > v2 changes: > - added check for the rest of the perf_event_attr fields > to be the same as for kernel event > > thanks, > jirka > > > [1] https://marc.info/?l=linux-kernel&m=151012255331565&w=2 > [2] https://marc.info/?l=linux-man&m=151172469807302&w=2 > --- > Jiri Olsa (7): > hw_breakpoint: Pass bp_type directly as find_slot_idx argument > hw_breakpoint: Pass bp_type argument to > __reserve_bp_slot|__release_bp_slot > hw_breakpoint: Add modify_bp_slot function > hw_breakpoint: Factor out __modify_user_hw_breakpoint function > hw_breakpoint: Add perf_event_attr fields check in > __modify_user_hw_breakpoint > perf/core: Move perf_event_attr::sample_max_stack into perf_copy_attr > perf tests: Add breakpoint accounting/modify test > > Milind Chabbi (1): > perf/core: fast breakpoint modification via _IOC_MODIFY_ATTRIBUTES. > > include/linux/hw_breakpoint.h | 7 + > include/uapi/linux/perf_event.h | 2 ++ > kernel/events/core.c | 53 +-- > kernel/events/hw_breakpoint.c | 115 > --- > tools/include/uapi/linux/perf_event.h | 2 ++ > tools/perf/tests/Build| 1 + > tools/perf/tests/bp_account.c | 195 > + > tools/perf/tests/builtin-test.c | 4 +++ > tools/perf/tests/tests.h | 1 + > 9 files changed, 344 insertions(+), 36 deletions(-) > create mode 100644 tools/perf/tests/bp_account.c
Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
2018-02-05 15:41 GMT+09:00 Knut Omang : > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote: >> Add scripts/runchecks which has generic support for running >> checker tools in a convenient and user friendly way that >> the author hopes can contribute to rein in issues detected >> by these tools in a manageable and convenient way. >> >> scripts/runchecks provides the following basic functionality: >> >> * Makes it possible to selectively suppress output from individual >> checks on a per file or per subsystem basis. >> * Unifies output and suppression input from different tools >> by providing a single unified syntax and presentation for the >> underlying tools in the style of "scripts/checkpatch.pl --show-types". >> * Allows selective run of one, or more (or all) configured tools >> for each file. >> >> In the Makefile system, the sparse specific setup has been replaced >> by setup for runchecks. > > Hi all, > > - Anything more I can/need to do to bring this forward? > - Any quiet concerns? > > I realize it is a subsystem crossing change, Is it? Only Kbuild this is related to. > and a lot going on elsewhere, > nevertheless I believe this is a time saver in the slightly longer run, > as it allows automation of checking, even without a "perfect" > code base to begin with. > Sorry for the delay. I have not been able to find time to dive into the detail yet. (Actually, I tried to do that for v2 or v3, where Python code was so dirty, then consumed my time to figure out what the code was trying to do) I find my concern here: https://lkml.org/lkml/2018/1/5/497 Anyway, I will take a look again when I find some time. You do not need to take care of the detail until I request to do so. -- Best Regards Masahiro Yamada
Re: [PATCH 02/14] dt-bindings: clock: add STM32MP1 clocks
On 02/05/2018 07:09 AM, Rob Herring wrote: > On Fri, Feb 02, 2018 at 03:03:30PM +0100, gabriel.fernan...@st.com wrote: >> From: Gabriel Fernandez >> >> This patch adds the clock binding entry for STM32MP1 >> >> Signed-off-by: Gabriel Fernandez >> --- >> include/dt-bindings/clock/stm32mp1-clks.h | 248 >> ++ >> 1 file changed, 248 insertions(+) >> create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h > You can squash this into the previous patch. Ok Thanks! BR Gabriel
Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings
Hi Rob,
Thanks for reviewing.
On 02/05/2018 07:09 AM, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
>> From: Gabriel Fernandez
>>
>> The RCC block is responsible of the management of the clock and reset
>> generation for the complete circuit.
>>
>> Signed-off-by: Gabriel Fernandez
>> ---
>> .../devicetree/bindings/mfd/st,stm32-rcc.txt | 85
>> ++
>> 1 file changed, 85 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> new file mode 100644
>> index 000..28017a1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Peripheral Reset Clock Controller
>> +==
>> +
>> +The RCC IP is both a reset and a clock controller.
>> +
>> +Please also refer to reset.txt for common reset controller binding usage.
>> +
>> +Please also refer to clock-bindings.txt for common clock controller
>> +binding usage.
>> +
>> +
>> +Required properties:
>> +- compatible: "simple-mfd", "syscon"
>
>> +- reg: should be register base and length as documented in the datasheet
>> +
>> +- Sub-nodes:
>> + - compatible: "st,stm32mp1-rcc-clk"
>> +- #clock-cells: 1, device nodes should specify the clock in their
>> + "clocks" property, containing a phandle to the clock device node,
>> + an index specifying the clock to use.
>> +
>> + - compatible: "st,stm32mp1-rcc-rst"
>> +- #reset-cells: Shall be 1
>> +
>> +Example:
>> +rcc: rcc@5000 {
>> +compatible = "syscon", "simple-mfd";
>> +reg = <0x5000 0x1000>;
>> +
>> +rcc_clk: rcc-clk@5000 {
>> +#clock-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-clk";
>> +};
>> +
>> +rcc_rst: rcc-reset@5000 {
> You should not have the same unit-address twice.
>
> IMO, this should just be:
>
> rcc: rcc@5000 {
> compatible = "st-stm32mp1-rcc";
> reg = <0x5000 0x1000>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> };
>
> There's no reason a node can't provide more than 1 function.
RCC is an dedicated IP for clocks and resets, but also for power
management (patches will be sent later)
Then i need to probe 3 drivers with same IP.
It's also a way to avoid use of 'CLK_OF_DECLARE_DRIVER' and i need it to
probe the 3th driver.
BR
Gabriel
>
>
>> +#reset-cells = <1>;
>> +compatible = "st,stm32mp1-rcc-rst";
>> +};
>> +};
>> +
>> +Specifying clocks
>> +=
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
>> +tree sources.
>> +
>> +Example:
>> +
>> +/* Accessing DMA1 clock */
>> +... {
>> +clocks = <&rcc_clk DMA1>
>> +};
>> +
>> +/* Accessing SPI6 kernel clock */
>> +... {
>> +clocks = <&rcc_clk SPI6_K>
>> +};
> Other than the path to header, the clock binding explains all this. No
> need to duplicate here.
ok
>> +
>> +Specifying softreset control of devices
>> +===
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index
>> specifying
>> +which channel to use.
>> +The index is the bit number within the RCC registers bank, starting from RCC
>> +base address.
>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>> +Where bit_offset is the bit offset within the register.
>> +
>> +For example on STM32MP1, for LTDC reset:
>> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
>> + = 0x180 / 4 * 32 + 0 = 3072
>> +
>> +The list of valid indices for STM32MP1 is available in:
>> +include/dt-bindings/reset-controller/stm32mp1-resets.h
>> +
>> +This file implements defines like:
>> +#define LTDC_R 3072
>> +
>> +example:
>> +
>> +ltdc {
>> +resets = <&rcc_rst LTDC_R>;
>> +};
>> --
>> 1.9.1
>>
[PATCH v2 1/2] KVM: X86: Add per-VM no-HLT-exiting capability
From: Wanpeng Li
If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* vmx_clear_hlt() around INIT handling
* vmx_clear_hlt() upon SMI and implement auto halt restart
Documentation/virtual/kvm/api.txt | 11 +++
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/include/asm/kvm_host.h| 7 +++
arch/x86/kvm/emulate.c | 2 ++
arch/x86/kvm/vmx.c | 38 ++
arch/x86/kvm/x86.c | 27 +++
arch/x86/kvm/x86.h | 5 +
include/uapi/linux/kvm.h | 1 +
8 files changed, 88 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 023da07..865b029 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4302,6 +4302,17 @@ enables QEMU to build error log and branch to guest
kernel registered
machine check handling routine. Without this capability KVM will
branch to guests' 0x200 interrupt vector.
+7.13 KVM_CAP_X86_GUEST_HLT
+
+Architectures: x86
+Parameters: none
+Returns: 0 on success
+
+This capability indicates that a guest using HLT to stop a virtual CPU
+will not cause a VM exit. As such, time spent while a virtual CPU is
+halted in this way will then be accounted for as guest running time on
+the host, KVM_FEATURE_PV_UNHALT should be disabled.
+
8. Other capabilities.
--
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index b24b1c8..78cfe8ca 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -225,6 +225,7 @@ struct x86_emulate_ops {
unsigned (*get_hflags)(struct x86_emulate_ctxt *ctxt);
void (*set_hflags)(struct x86_emulate_ctxt *ctxt, unsigned hflags);
int (*pre_leave_smm)(struct x86_emulate_ctxt *ctxt, u64 smbase);
+ void (*smm_auto_halt_restart)(struct x86_emulate_ctxt *ctxt);
};
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8f0f09a..95b2c44 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -623,6 +623,11 @@ struct kvm_vcpu_arch {
unsigned nmi_pending; /* NMI queued after currently running handler */
bool nmi_injected;/* Trying to inject an NMI this entry */
bool smi_pending;/* SMI queued after currently running handler */
+ /*
+* bit 0 is set if Value of Auto HALT Restart after Entry to SMM is true
+* bit 1 is set if Value of Auto HALT Restart When Exiting SMM is true
+*/
+ int smm_auto_halt_restart;
struct kvm_mtrr mtrr_state;
u64 pat;
@@ -806,6 +811,8 @@ struct kvm_arch {
gpa_t wall_clock;
+ bool hlt_in_guest;
+
bool ept_identity_pagetable_done;
gpa_t ept_identity_map_addr;
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d91eaeb..ee5bc65 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2597,6 +2597,8 @@ static int em_rsm(struct x86_emulate_ctxt *ctxt)
smbase = ctxt->ops->get_smbase(ctxt);
+ if (GET_SMSTATE(u16, smbase, 0x7f02) & 0x1)
+ ctxt->ops->smm_auto_halt_restart(ctxt);
/*
* Give pre_leave_smm() a chance to make ISA-specific changes to the
* vCPU state (e.g. enter guest mode) before loading state from the SMM
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3e71086..23789c9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2474,6 +2474,24 @@ static int nested_vmx_check_exception(struct kvm_vcpu
*vcpu, unsigned long *exit
return 0;
}
+static bool vmx_need_clear_hlt(struct kvm_vcpu *vcpu)
+{
+ return kvm_hlt_in_guest(vcpu->kvm) &&
+ vmcs_read32(GUEST_ACTIVITY_STATE) == GUEST_ACTIVITY_HLT;
+}
+
+static void vmx_clear_hlt(struct kvm_vcpu *vcpu)
+{
+ /*
+* Ensure that we clear the HLT state in the VMCS. We don't need to
+* explicitly skip the instruction because if the HLT state is set,
+* then the instruction is already executing and RIP has already been
+* advanced.
+*/
+ if (vmx_need_clear_hlt(vcpu))
+ vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE);
+}
+
static void vmx_queue_exception(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -2504,6 +2522,8 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu)
intr_info |= INTR_TYPE_HARD_EXCEPTION;
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
+
+ vmx_clear_hlt(vcpu);
}
static bool vmx_rdtscp_supported(void)
@@ -5359,6 +5379,8 @@ static u32 vmx_exec_control(struct vcpu_vmx *vmx)
exec_control |= CPU_BASED_CR3_STORE_EXITING |
[PATCH v2 2/2] KVM: X86: Avoid traversing all the cpus for pv tlb flush when steal time is disabled
From: Wanpeng Li
Avoid traversing all the cpus for pv tlb flush when steal time
is disabled since pv tlb flush depends on the field in steal time
for shared data.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kernel/kvm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index f2a09cf..4f3c997 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -546,7 +546,8 @@ static void __init kvm_guest_init(void)
}
if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
- !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED))
+ !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED) &&
+ kvm_para_has_feature(KVM_FEATURE_STEAL_TIME))
pv_mmu_ops.flush_tlb_others = kvm_flush_tlb_others;
if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
@@ -635,7 +636,8 @@ static __init int kvm_setup_pv_tlb_flush(void)
int cpu;
if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) &&
- !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED)) {
+ !kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED) &&
+ kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
for_each_possible_cpu(cpu) {
zalloc_cpumask_var_node(per_cpu_ptr(&__pv_tlb_mask,
cpu),
GFP_KERNEL, cpu_to_node(cpu));
--
2.7.4
Re: [PATCH 08/20] s390/kconfig: Remove ARCH_WANTS_PROT_NUMA_PROT_NONE select
On Mon, Feb 05, 2018 at 02:21:20AM +0100, Ulf Magnusson wrote:
> The ARCH_WANTS_PROT_NUMA_PROT_NONE symbol was removed by
> commit 6a33979d5bd7 ("mm: remove misleading ARCH_USES_NUMA_PROT_NONE"),
> but S390 still selects it.
>
> Remove the ARCH_WANTS_PROT_NUMA_PROT_NONE select from the S390 symbol.
>
> Discovered with the
> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> script.
>
> Signed-off-by: Ulf Magnusson
> ---
> arch/s390/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks!
Re: linux-next: Signed-off-by missing for commits in the s390 tree
Hi Stephen,
On Sat, 3 Feb 2018 13:03:48 +1100
Stephen Rothwell wrote:
> Commits
>
> a39892ed47bf ("s390/runtime_instrumentation: re-add signum system call
> parameter")
> 279d2cea3aad ("s390/cio: fix kernel-doc usage")
>
> are missing a Signed-off-by from their committer.
Thanks for the heads up, fixed it.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit
Is it necessary to make atomic commit fail? What's the problem of this
patch (no lock at all and does not make atomic fail)? These two patches
aims to provide ability to gc old blocks of opened atomic file, with no
affection to original atomic commit and no mix with inmem pages.
On 2018/2/5 14:29, Chao Yu wrote:
On 2018/2/5 10:53, Yunlong Song wrote:
Is it necessary to add a lock here? What's the problem of this patch (no
lock at all)? Anyway, the problem is expected to be fixed asap, since
attackers can easily write an app with only atomic start and no atomic
commit, which will cause f2fs run into loop gc if the disk layout is
much fragmented, since f2fs_gc will select the same target victim all
the time (e.g. one block of target victim belongs to the opened atomic
file, and it will not be moved and do_garbage_collect will finally
return 0, and that victim is selected again next time) and goto gc_more
time and time again, which will block all the fs ops (all the fs ops
will hang up in f2fs_balance_fs).
Hmm.. w/ original commit log and implementation, I supposed that the patch
intended to fix to make atomic write be isolated from other IOs like GC
triggered writes...
Alright, we have discuss the problem before in below link:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html
I meant, for example:
f2fs_ioc_start_atomic_write()
inode->atomic_open_time = get_mtime();
f2fs_ioc_commit_atomic_write()
inode->atomic_open_time = 0;
f2fs_balance_fs_bg()
for_each_atomic_open_file()
if (inode->atomic_open_time &&
inode->atomic_open_time > threshold) {
drop_inmem_pages();
f2fs_msg();
}
threshold = 30s
Any thoughts?
Thanks,
On 2018/2/4 22:56, Chao Yu wrote:
On 2018/2/3 10:47, Yunlong Song wrote:
If inode has already started to atomic commit, then set_page_dirty will
not mix the gc pages with the inmem atomic pages, so the page can be
gced safely.
Let's avoid Ccing fs mailing list if the patch didn't change vfs common
codes.
As you know, the problem here is mixed dnode block flushing w/o writebacking
gced data block, result in making transaction unintegrated.
So how about just using dio_rwsem[WRITE] during atomic committing to exclude
GCing data block of atomic opened file?
Thanks,
Signed-off-by: Yunlong Song
---
fs/f2fs/data.c | 5 ++---
fs/f2fs/gc.c | 6 --
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct
f2fs_io_info *fio)
return true;
if (S_ISDIR(inode->i_mode))
return true;
- if (f2fs_is_atomic_file(inode))
- return true;
if (fio) {
if (is_cold_data(fio->page))
return true;
if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
return true;
- }
+ } else if (f2fs_is_atomic_file(inode))
+ return true;
return false;
}
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b9d93fd..84ab3ff 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
- if (f2fs_is_atomic_file(inode))
+ if (f2fs_is_atomic_file(inode) &&
+ !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
@@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
- if (f2fs_is_atomic_file(inode))
+ if (f2fs_is_atomic_file(inode) &&
+ !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)
.
.
--
Thanks,
Yunlong Song
Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote: > Add scripts/runchecks which has generic support for running > checker tools in a convenient and user friendly way that > the author hopes can contribute to rein in issues detected > by these tools in a manageable and convenient way. > > scripts/runchecks provides the following basic functionality: > > * Makes it possible to selectively suppress output from individual > checks on a per file or per subsystem basis. > * Unifies output and suppression input from different tools > by providing a single unified syntax and presentation for the > underlying tools in the style of "scripts/checkpatch.pl --show-types". > * Allows selective run of one, or more (or all) configured tools > for each file. > > In the Makefile system, the sparse specific setup has been replaced > by setup for runchecks. Hi all, - Anything more I can/need to do to bring this forward? - Any quiet concerns? I realize it is a subsystem crossing change, and a lot going on elsewhere, nevertheless I believe this is a time saver in the slightly longer run, as it allows automation of checking, even without a "perfect" code base to begin with. Thanks, Knut
Re: [PATCH 1/2] soc: imx: gpc: ARM power domain should be always-on
On Wed, Jan 24, 2018 at 12:42:13AM +0800, Anson Huang wrote: > ARM power domain does NOT support runtime off, always-on > flag should be set to avoid incorrect power state in > pm_genpd_summary: > > Before: > > root@imx6qpdlsolox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary > domain status slaves > /device runtime status > -- > ARM off-0 > > After: > > root@imx6qpdlsolox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary > domain status slaves > /device runtime status > -- > ARM on > > Signed-off-by: Anson Huang Applied both, thanks.
Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit
On 2018/2/5 10:53, Yunlong Song wrote:
> Is it necessary to add a lock here? What's the problem of this patch (no
> lock at all)? Anyway, the problem is expected to be fixed asap, since
> attackers can easily write an app with only atomic start and no atomic
> commit, which will cause f2fs run into loop gc if the disk layout is
> much fragmented, since f2fs_gc will select the same target victim all
> the time (e.g. one block of target victim belongs to the opened atomic
> file, and it will not be moved and do_garbage_collect will finally
> return 0, and that victim is selected again next time) and goto gc_more
> time and time again, which will block all the fs ops (all the fs ops
> will hang up in f2fs_balance_fs).
Hmm.. w/ original commit log and implementation, I supposed that the patch
intended to fix to make atomic write be isolated from other IOs like GC
triggered writes...
Alright, we have discuss the problem before in below link:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1571951.html
I meant, for example:
f2fs_ioc_start_atomic_write()
inode->atomic_open_time = get_mtime();
f2fs_ioc_commit_atomic_write()
inode->atomic_open_time = 0;
f2fs_balance_fs_bg()
for_each_atomic_open_file()
if (inode->atomic_open_time &&
inode->atomic_open_time > threshold) {
drop_inmem_pages();
f2fs_msg();
}
threshold = 30s
Any thoughts?
Thanks,
>
> On 2018/2/4 22:56, Chao Yu wrote:
>> On 2018/2/3 10:47, Yunlong Song wrote:
>>> If inode has already started to atomic commit, then set_page_dirty will
>>> not mix the gc pages with the inmem atomic pages, so the page can be
>>> gced safely.
>>
>> Let's avoid Ccing fs mailing list if the patch didn't change vfs common
>> codes.
>>
>> As you know, the problem here is mixed dnode block flushing w/o writebacking
>> gced data block, result in making transaction unintegrated.
>>
>> So how about just using dio_rwsem[WRITE] during atomic committing to exclude
>> GCing data block of atomic opened file?
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Yunlong Song
>>> ---
>>> fs/f2fs/data.c | 5 ++---
>>> fs/f2fs/gc.c | 6 --
>>> 2 files changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 7435830..edafcb6 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode,
>>> struct f2fs_io_info *fio)
>>> return true;
>>> if (S_ISDIR(inode->i_mode))
>>> return true;
>>> - if (f2fs_is_atomic_file(inode))
>>> - return true;
>>> if (fio) {
>>> if (is_cold_data(fio->page))
>>> return true;
>>> if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
>>> return true;
>>> - }
>>> + } else if (f2fs_is_atomic_file(inode))
>>> + return true;
>>> return false;
>>> }
>>>
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index b9d93fd..84ab3ff 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode,
>>> block_t bidx,
>>> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>>> goto out;
>>>
>>> - if (f2fs_is_atomic_file(inode))
>>> + if (f2fs_is_atomic_file(inode) &&
>>> + !f2fs_is_commit_atomic_write(inode))
>>> goto out;
>>>
>>> if (f2fs_is_pinned_file(inode)) {
>>> @@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t
>>> bidx, int gc_type,
>>> if (!check_valid_map(F2FS_I_SB(inode), segno, off))
>>> goto out;
>>>
>>> - if (f2fs_is_atomic_file(inode))
>>> + if (f2fs_is_atomic_file(inode) &&
>>> + !f2fs_is_commit_atomic_write(inode))
>>> goto out;
>>> if (f2fs_is_pinned_file(inode)) {
>>> if (gc_type == FG_GC)
>>>
>>
>> .
>>
>
Re: [PATCH] ARM: dts: imx6sx: add pu power domain support
On Tue, Jan 23, 2018 at 11:12:23PM +0800, Anson Huang wrote: > Add PU power domain support, GPU is the only > module inside PU power domain, and PU power > is supplied by LDO_SOC. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl
James,
Thank you for your time to reply me.
On 2018/1/31 3:21, James Morse wrote:
> Hi gengdongjiu,
>
> On 24/01/18 20:06, gengdongjiu wrote:
>>> On 06/01/18 16:02, Dongjiu Geng wrote:
The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
guest and user space needs a way to tell KVM this value. So we add a
new ioctl. Before user space specifies the Exception Syndrome Register
ESR(ESR), it firstly checks that whether KVM has the capability to set
the guest ESR, If has, will set it. Otherwise, nothing to do.
For this ESR specifying, Only support for AArch64, not support AArch32.
>>>
>>> After this patch user-space can trigger an SError in the guest. If it wants
>>> to migrate the guest, how does the pending SError get migrated?
>>>
>>> I think we need to fix migration first. Andrew Jones suggested using
>>> KVM_GET/SET_VCPU_EVENTS:
>>> https://www.spinics.net/lists/arm-kernel/msg616846.html
>>>
>>> Given KVM uses kvm_inject_vabt() on v8.0 hardware too, we should cover
>>> systems without the v8.2 RAS Extensions with the same API. I
>>> think this means a bit to read/write whether SError is pending, and another
>>> to indicate the ESR should be set/read.
>>> CPUs without the v8.2 RAS Extensions can reject pending-SError that had an
>>> ESR.
>>
>> For the CPUs without the v8.2 RAS Extensions, its ESR is always 0,
>> we only can inject a SError with ESR 0 to guest, cannot set its ESR.
>
> 0? It's always implementation-defined. On Juno it seems to be always-0, but
> other systems may behave differently. (Juno may generate another ESR value
> when
> I'm not watching it...)
For the armv8.0 cpu without RAS Extensions, it does not have vsesr_el2, so when
guest take a virtual SError,
its ESR is 0, can not control the virtual SError's syndrom value, it does not
have such registers to control that.
Does Juno not have RAS Extension? if yes, I think we can only inject an SError,
but can not change its ESR value, because it does not have vsesr_el2.
>
> Just because we can't control the ESR doesn't mean injecting an SError isn't
> something user-space may want to do.
yes, we may need to support user-space injects an SError even through CPU does
not have RAS Extension.
> If we tackle migration of pending-SError first, I think that will give us the
> API to create a new pending SError with/without an ESR as appropriate.
sure, we should. Last week, I checked the KVM_GET/SET_VCPU_EVENTS IOCTL, it
should meet our migration requirements
>
>
>> About how about to use the KVM_GET/SET_VCPU_EVENTS, I will check the code,
>> and
>> consider your suggestion at the same time.
>
> (Not my suggestion, It was Andrew Jones idea.)
Got it.
>
>> The IOCTL KVM_GET/SET_VCPU_EVENTS has been used by X86.
>
> We would be re-using the struct to have values with slightly different
> meanings.
> But for migration the upshot is the same, call KVM_GET_VCPU_EVENTS on one
> system, and pass the struct to KVM_SET_VCPU_EVENTS on the new system. If we're
> lucky Qemu may be able to do this in shared x86/arm64 code.
>
Thanks for the reminder, I know your meaning.
In the x86, the kvm_vcpu_events includes exception/interrupt/nmi/smi. For the
RAS, we
only involves the exception, so Qemu handling logic is different. Anyway, I
will try to
share code for the two platform in Qemu.
/* for KVM_GET/SET_VCPU_EVENTS */
struct kvm_vcpu_events {
struct {
__u8 injected;
__u8 nr;
__u8 has_error_code;
__u8 pad;
__u32 error_code;
} exception;
struct {
__u8 injected;
__u8 nr;
__u8 soft;
__u8 shadow;
} interrupt;
struct {
__u8 injected;
__u8 pending;
__u8 masked;
__u8 pad;
} nmi;
__u32 sipi_vector;
__u32 flags;
struct {
__u8 smm;
__u8 pending;
__u8 smm_inside_nmi;
__u8 latched_init;
} smi;
__u32 reserved[9];
};
>
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index
5c7f657..738ae90 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -277,6 +277,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu
*vcpu,
return -EINVAL;
}
+int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome) {
+ return -EINVAL;
+}
>>>
>>> Does nothing in the patch that adds the support? This is a bit odd.
>>> (oh, its hiding in patch 6...)
>>
>> To make this patch simple and small, I add it in patch 6.
>
> But that made the functionality of this patch: A new API to return -EINVAL
> from
> the kernel.
>
> Swapping the patches round would have avoided this.
> Regardless, I think this will fold out in a rebase.
yes, I will, thanks for your kind suggestion.
>
>
>
Re: [PATCH] ASoC: codecs: Add support for AK4458 DAC driver
On Wed, Jan 31, 2018 at 03:20:09PM +0200, Cosmin-Gabriel Samoila wrote:
> The AK4458 is a 32-bit 8ch Premium DAC that corresponds
> to a 768kHz PCM input and an 11.2MHz DSD input at maximum.
> It supports I2S, DSD and TDM modes with 24 or 32 bit MSB
> or 16, 24, 32 LSB formats. Its datasheet is available here:
> https://www.akm.com/akm/en/file/datasheet/AK4458VN.pdf
>
> Signed-off-by: Junichi Wakasugi
> Signed-off-by: Mihai Serban
> Signed-off-by: Shengjiu Wang
> Signed-off-by: Cosmin-Gabriel Samoila
> ---
> Documentation/devicetree/bindings/sound/ak4458.txt | 23 +
Separate patch please.
> sound/soc/codecs/Kconfig | 18 +
> sound/soc/codecs/Makefile |6 +
> sound/soc/codecs/ak4458-i2c.c | 79 ++
> sound/soc/codecs/ak4458-spi.c | 61 ++
> sound/soc/codecs/ak4458.c | 1132
>
> sound/soc/codecs/ak4458.h | 127 +++
> 7 files changed, 1446 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/ak4458.txt
> create mode 100644 sound/soc/codecs/ak4458-i2c.c
> create mode 100644 sound/soc/codecs/ak4458-spi.c
> create mode 100644 sound/soc/codecs/ak4458.c
> create mode 100644 sound/soc/codecs/ak4458.h
>
> diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt
> b/Documentation/devicetree/bindings/sound/ak4458.txt
> new file mode 100644
> index 000..b9e6eb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ak4458.txt
> @@ -0,0 +1,23 @@
> +AK4458 audio DAC
> +
> +This device supports both I2C and SPI modes.
> +
> +Required properties:
> +
> +- compatible : "asahi-kasei,ak4458"
> +- reg : The I2C address of the device for I2C, the chip select number for
> SPI.
> +- asahi-kasei,pdn-gpios: A GPIO specifier for the GPIO controlling
> + the power down & reset pin.
reset-gpios like the Asahi Kasei ADC under review.
> +- asahi-kasei,mute-gpios: A GPIO specifier for the GPIO controlling
> + the soft mute pin.
State the active state.
> +
> +Example:
> +
> +&i2c {
> + ak4458: ak4458@10 {
dac@10
> + compatible = "asahi-kasei,ak4458";
> + reg = <0x10>;
> + asahi-kasei,pdn-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>
> + asahi-kasei,mute-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>
> + };
> +};
Re: [PATCHv2] tlv320dac33: Add device tree bindings
On Wed, Jan 31, 2018 at 08:01:12PM +0100, Pavel Machek wrote:
>
> This adds device tree bindings for tlv320dac33.c.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> new file mode 100644
> index 000..7fdda95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments - tlv320dac33 Codec module
> +
> +The tlv320dac33 serial control bus communicates through I2C protocols.
> +
> +Required properties:
> +
> +- compatible - "ti,tlv320dac33"
> +- reg - I2C slave address
> +
> +Optional properties:
> +
> +- reset-gpios - gpio pin to power the device, active low
> +
> +- interrupts - The interrupt output from the device.
> +- interrupt-parent - The parent interrupt controller.
> +
> +- ti,keep-bclk - Keep the BCLK running in FIFO modes
space before tab ^
> +- ti,burst-bclkdiv - BCLK divider value in burst mode
What are valid values? What's the default?
> +
> +Example:
> +
> +tlv320dac33: audio-codec@19 {
> + compatible = "ti,tlv320dac33";
> + reg = <0x19>;
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
> + reset-gpios = <&gpio2 28 0>; /* gpio_60 */
> +
> + ti,keep-bclk;
> + ti,burst-bclkdiv = <3>;
> +};
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector
On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> These bindings allow to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.
>
> Signed-off-by: Andrzej Hajda
> ---
> v2:
> - moved connector type(A,B,C) to compatible string (Rob),
> - renamed size property to type (Rob),
> - changed type description to be less confusing (Laurent),
> - removed vendor specific compatibles (implied by graph port number),
How so? More below...
> - added requirement of connector being a child of IC (Rob),
> - removed max-mode (subtly suggested by Rob, it should be detected anyway
> by USB Controller in runtime, downside is that device is not able to
> report its real capabilities, maybe better would be to make it optional(?)),
> - assigned port numbers to data buses (Rob).
>
> Regards
> Andrzej
>
> Signed-off-by: Andrzej Hajda
> ---
> .../bindings/connector/usb-connector.txt | 48
> ++
> 1 file changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/connector/usb-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..02020f5d760a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,48 @@
> +USB Connector
> +=
> +
> +USB connector node represents physical USB connector. It should be
> +a child of USB interface controller.
> +
> +Required properties:
> +- compatible: describes type of the connector, must be one of:
> +"usb-a-connector", "usb-b-connector", "usb-c-connector",
Nit: one per line.
> +
> +Optional properties:
> +- label: symbolic name for the connector
> +- type: size of the connector, should be specified in case of USB-A, USB-B
> + non-standard (large) connector sizes: "mini", "micro"
> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the OF graph bindings
> + specified in bindings/graph.txt, unless the bus is between parent node and
> + the connector. Since single connector can have multpile data buses every
> bus
> + has assigned OF graph port number as follows:
> +0: High Speed (HS), present in all connectors,
> +1: Super Speed (SS), present in SS capable connectors,
> +2: Sideband use (SBU), present in USB-C,
> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB
This is un-muxed unlike Type-C where the signals are muxed with USB SS.
That makes me think the Samsung connector should have its own compatible
string.
Can we go ahead and define the video modes of Type-C? Normally, if 2
data streams are mutually exclusive, then they are a single port with 2
endpoints. So we'd either have 2 endpoints on port 1 or we stick with
port 3 is always video. We can still know what is mutually exclusive
based on the compatible.
> +
> +Example
> +---
> +
> +muic_max77843@66 {
> + ...
> + musb_con: connector {
> + compatible = "usb-b-connector";
> + label = "micro-USB";
> + type = "micro";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@3 {
> + reg = <3>;
> + musb_con_mhl_in: endpoint {
> + remote-endpoint = <&mhl_out>;
> + };
> + };
> + };
> + };
> +};
> --
> 2.15.1
>
Re: [PATCH v2 1/3] Documentation: dt-bindings: arm: Document kryo385 cpu
On Wed, Jan 31, 2018 at 09:49:39PM +0530, Rajendra Nayak wrote: > Document the compatible string for the Kryo385 cpus found in qualcomm > SoCs. > > Signed-off-by: Rajendra Nayak > --- > Documentation/devicetree/bindings/arm/cpus.txt | 1 + > 1 file changed, 1 insertion(+) "dt-bindings: arm: " for the subject prefix. Otherwise, Reviewed-by: Rob Herring
Re: [PATCH V2 1/2] ARM: dts: imx7s: add temperature monitor support
On Fri, Jan 26, 2018 at 04:09:39PM +0800, Anson Huang wrote: > Add i.MX7 temperature monitor support. > > Signed-off-by: Anson Huang > Acked-by: Dong Aisheng > --- > no changes since V1. > .../devicetree/bindings/thermal/imx-thermal.txt | 5 +++-- The bindings doc should be a separate patch or part of related imx-thermal driver patch ... > arch/arm/boot/dts/imx7s.dtsi | 20 > ..., and shouldn't be mixed with dts changes. Shawn
Re: [PATCH v3 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC
On Wed, Jan 31, 2018 at 10:35:43PM +0100, Benoît Thébaudeau wrote: > This file had several naming inconsistencies for eSDHC: > - the instances were named sometimes SDn, sometimes SDHCn, whereas they >are named ESDHCn in the reference manual, e.g.: > MX25_PAD_SD1_CMD__SD1_CMD > MX25_PAD_D15__SDHC1_DAT7 > - the data ports were named sometimes DATAn, sometimes DATn like in the >reference manual, e.g.: > MX25_PAD_SD1_DATA0__SD1_DATA0 > MX25_PAD_D15__SDHC1_DAT7 > - in one case, the clock port was named DAT_CLK instead of CLK: > MX25_PAD_CSI_D7__SDHC2_DAT_CLK > > This change: > - introduces new definitions using the naming from the reference >manual, > - keeps definitions using the legacy naming in order not to break >compatibility for out-of-tree users (they can be removed later), > - updates the in-tree files that were using the legacy naming. > > Cc: Uwe Kleine-König > Signed-off-by: Benoît Thébaudeau > Acked-by: Uwe Kleine-König > --- > Changes v2 -> v3: > - None. > Changes v1 -> v2: > - New patch (suggested by Uwe). > --- > .../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts | 12 ++-- > arch/arm/boot/dts/imx25-pdk.dts| 12 ++-- > arch/arm/boot/dts/imx25-pinfunc.h | 72 > ++ > 3 files changed, 60 insertions(+), 36 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH] fbdev: simplefb: add support for 'memory-region' property on DT node
On Thu, Feb 01, 2018 at 04:56:08PM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Tuesday, January 23, 2018 08:34:56 PM Kunihiko Hayashi wrote: > > Enables 'memory-region' property referring to the memory description on > > the reserved-memory node in case of devicetree use. > > If there is no 'reg' property that specifies the address and size of > > the framebuffer, the address and size written in the memory description > > on the reserved-memory node can be used for the framebuffer. > > > > Furthermore, the reserved-memory node needs to have "no-map" attributes > > because simplefb driver maps the region by ioremap_wc(). > > > > Signed-off-by: Kunihiko Hayashi > > This needs an ACK from Rob or Mark (DT bindings Maintainers). > > > --- > > .../bindings/display/simple-framebuffer.txt| 3 ++ > > drivers/video/fbdev/simplefb.c | 32 > > ++ > > 2 files changed, 35 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/simple-framebuffer.txt > > b/Documentation/devicetree/bindings/display/simple-framebuffer.txt > > index 5a9ce51..be5139f 100644 > > --- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt > > +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt > > @@ -56,6 +56,9 @@ Optional properties: > >framebuffer remains active. > > > > - display : phandle pointing to the primary display hardware node > > +- memory-region: phandle to a node describing memory region as framebuffer > > +memory instead of reg property. The node should include > > +'no-map'. This should also state when it's appropriate to use this instead of reg. The memory would only be reclaimed if reg is used. Though I'm wondering what keeps the simple fb memory from getting used by the OS if reserved memory is not always used. Rob
Re: [PATCH 2/2] soc: mediatek: add SCPSYS power domain driver for MediaTek MT7623A SoC
On Thu, Feb 01, 2018 at 06:12:48PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add SCPSYS power domain driver for MT7623A SoC. The MT7623A's power > domains are the subset of MT7623 SoC's ones. As MT7623 SoC has full > features whereas MT7623A is being designed just for router applications. > Thus, MT7623A doesn't include those power domains multimedia function > belongs to. In order to avoid certain errors undoubtedly happening at > registering those power domains on MT7623A SoC using the existing MT7623 > SCPSYS driver, it's required to define another setup specifically for > MT7623A SoC. Also, use a meaningful definition for bus_prot_mask instead > of just hardcoded for it. > > Signed-off-by: Sean Wang > --- > drivers/soc/mediatek/mtk-scpsys.c | 60 > +-- > include/dt-bindings/power/mt7623a-power.h | 10 ++ This belongs in the binding patch. > include/linux/soc/mediatek/infracfg.h | 4 +++ > 3 files changed, 72 insertions(+), 2 deletions(-) > create mode 100644 include/dt-bindings/power/mt7623a-power.h >
Re: [PATCH 1/3] dt-bindings: pwm-stm32-lp: add #pwm-cells
On Thu, Feb 01, 2018 at 02:44:36PM +0100, Fabrice Gasnier wrote: > From: Gerald Baeza > > STM32 Low-Power Timer supports generic 3 cells pwm to encode > PWM number, period and polarity. > > Signed-off-by: Gerald Baeza > Signed-off-by: Fabrice Gasnier > --- > Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Rob Herring
Re: [PATCH v2 2/2] ASoC: ak5558: Add bindings for AK5558 ADC
On Fri, Feb 02, 2018 at 06:20:06PM +0200, Daniel Baluta wrote:
> Signed-off-by: Daniel Baluta
> ---
> Documentation/devicetree/bindings/sound/ak5558.txt | 23
> ++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/ak5558.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt
> b/Documentation/devicetree/bindings/sound/ak5558.txt
> new file mode 100644
> index 000..61c85568
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ak5558.txt
> @@ -0,0 +1,23 @@
> +AK5558 8 channel differential 32-bit delta-sigma ADC
> +
> +This device supports I2C mode only.
> +
> +Required properties:
> +
> +- compatible : "asahi-kasei,ak5558"
> +- reg : The I2C address of the device for I2C.
> +
> +Optional properties:
> +
> +- reset-gpios: A GPIO specifier for the GPIO controlling
> + the power down & reset pin.
> +
> +Example:
> +
> +&i2c {
> + ak5558: ak5558@10 {
adc@10
> + compatible = "asahi-kasei,ak5558";
> + reg = <0x10>;
> + reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> + };
> +};
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/14] dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings
On Fri, Feb 02, 2018 at 03:03:29PM +0100, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez
>
> The RCC block is responsible of the management of the clock and reset
> generation for the complete circuit.
>
> Signed-off-by: Gabriel Fernandez
> ---
> .../devicetree/bindings/mfd/st,stm32-rcc.txt | 85
> ++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> new file mode 100644
> index 000..28017a1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-rcc.txt
> @@ -0,0 +1,85 @@
> +STMicroelectronics STM32 Peripheral Reset Clock Controller
> +==
> +
> +The RCC IP is both a reset and a clock controller.
> +
> +Please also refer to reset.txt for common reset controller binding usage.
> +
> +Please also refer to clock-bindings.txt for common clock controller
> +binding usage.
> +
> +
> +Required properties:
> +- compatible: "simple-mfd", "syscon"
> +- reg: should be register base and length as documented in the datasheet
> +
> +- Sub-nodes:
> + - compatible: "st,stm32mp1-rcc-clk"
> + - #clock-cells: 1, device nodes should specify the clock in their
> + "clocks" property, containing a phandle to the clock device node,
> + an index specifying the clock to use.
> +
> + - compatible: "st,stm32mp1-rcc-rst"
> + - #reset-cells: Shall be 1
> +
> +Example:
> + rcc: rcc@5000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x5000 0x1000>;
> +
> + rcc_clk: rcc-clk@5000 {
> + #clock-cells = <1>;
> + compatible = "st,stm32mp1-rcc-clk";
> + };
> +
> + rcc_rst: rcc-reset@5000 {
You should not have the same unit-address twice.
IMO, this should just be:
rcc: rcc@5000 {
compatible = "st-stm32mp1-rcc";
reg = <0x5000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
There's no reason a node can't provide more than 1 function.
> + #reset-cells = <1>;
> + compatible = "st,stm32mp1-rcc-rst";
> + };
> + };
> +
> +Specifying clocks
> +=
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/stm32mp1-clks.h header and can be used in device
> +tree sources.
> +
> +Example:
> +
> + /* Accessing DMA1 clock */
> + ... {
> + clocks = <&rcc_clk DMA1>
> + };
> +
> + /* Accessing SPI6 kernel clock */
> + ... {
> + clocks = <&rcc_clk SPI6_K>
> + };
Other than the path to header, the clock binding explains all this. No
need to duplicate here.
> +
> +Specifying softreset control of devices
> +===
> +
> +Device nodes should specify the reset channel required in their "resets"
> +property, containing a phandle to the reset device node and an index
> specifying
> +which channel to use.
> +The index is the bit number within the RCC registers bank, starting from RCC
> +base address.
> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
> +Where bit_offset is the bit offset within the register.
> +
> +For example on STM32MP1, for LTDC reset:
> + ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
> + = 0x180 / 4 * 32 + 0 = 3072
> +
> +The list of valid indices for STM32MP1 is available in:
> +include/dt-bindings/reset-controller/stm32mp1-resets.h
> +
> +This file implements defines like:
> +#define LTDC_R 3072
> +
> +example:
> +
> + ltdc {
> + resets = <&rcc_rst LTDC_R>;
> + };
> --
> 1.9.1
>
Re: [PATCH v3 1/3] dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings
On Thu, Feb 01, 2018 at 11:45:23AM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> Document the devicetree bindings for MediaTek High-Speed DMA controller
> which could be found on MT7623 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: Sean Wang
> ---
> .../devicetree/bindings/dma/mtk-hsdma.txt | 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> new file mode 100644
> index 000..c07c03e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
> @@ -0,0 +1,33 @@
> +MediaTek High-Speed DMA Controller
> +==
> +
> +This driver follows the generic DMA bindings defined in dma/dma.txt.
Bindings describe h/w, not drivers.
> +
> +Required properties:
> +
> +- compatible:Must be one of
> + "mediatek,mt7622-hsdma": for MT7622 SoC
> + "mediatek,mt7623-hsdma": for MT7623 SoC
> +- reg: Should contain the register's base address and length.
> +- interrupts:Should contain a reference to the interrupt used by this
> + device.
> +- clocks:Should be the clock specifiers corresponding to the entry in
> + clock-names property.
> +- clock-names: Should contain "hsdma" entries.
> +- power-domains: Phandle to the power domain that the device is part of
> +- #dma-cells:The length of the DMA specifier, must be <1>. This one
> cell
> + in dmas property of a client device represents the channel
> + number.
> +Example:
> +
> +hsdma: hsdma@1b007000 {
dma-controller@...
> + compatible = "mediatek,mt7623-hsdma";
> + reg = <0 0x1b007000 0 0x1000>;
> + interrupts = ;
> + clocks = <ðsys CLK_ETHSYS_HSDMA>;
> + clock-names = "hsdma";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
> + #dma-cells = <1>;
> + };
> +
> +DMA clients must use the format described in dma/dma.txt file.
> --
> 2.7.4
>
Re: [PATCH 1/2] dt-bindings: fsi: Add optional property no-scan-on-init
On Mon, Feb 5, 2018 at 4:37 PM, Rob Herring wrote: > On Tue, Jan 30, 2018 at 04:21:15PM +1030, Joel Stanley wrote: >> From: Christopher Bostic >> >> Add an optional FSI master property 'no-scan-on-init. This >> can be specified to indicate that a master should not be >> automatically scanned at init time. This is required in cases >> where a scan could interfere with another FSI master on the same >> bus. >> >> Signed-off-by: Christopher Bostic >> Acked-by: Jeremy Kerr >> Signed-off-by: Joel Stanley >> --- >> Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt >> b/Documentation/devicetree/bindings/fsi/fsi.txt >> index 4eaf488d4015..ab516c673a4b 100644 >> --- a/Documentation/devicetree/bindings/fsi/fsi.txt >> +++ b/Documentation/devicetree/bindings/fsi/fsi.txt >> @@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size: >> #address-cells = <2>; >> #size-cells = <0>; >> >> +An optional boolean property can be added to indicate that a particular >> master >> +should not scan for connected devices at initialization time. This is >> +necessary in cases where a scan could cause arbitration issues with other >> +masters that may be present on the bus. >> + >> +no-scan-on-init; >> + > > The formatting here is a bit strange compared to most bindings, but no > point in reformatting the document to add one property. I'll keep that in mind next time we're working in this area. Thanks Rob. > > Reviewed-by: Rob Herring > > Rob
Re: [PATCH 02/14] dt-bindings: clock: add STM32MP1 clocks
On Fri, Feb 02, 2018 at 03:03:30PM +0100, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > This patch adds the clock binding entry for STM32MP1 > > Signed-off-by: Gabriel Fernandez > --- > include/dt-bindings/clock/stm32mp1-clks.h | 248 > ++ > 1 file changed, 248 insertions(+) > create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h You can squash this into the previous patch.
Re: [PATCH 1/2] dt-bindings: soc: add SCPSYS binding for MT7623 and MT7623A SoC
On Thu, Feb 01, 2018 at 06:12:47PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > document the binding for enabling SCPSYS on MediaTek MT7623 and MT7623A > SoC. Where MT7623 SoC has the same definition about power domains with > MT2701, so it's fine to using MT2701 ones as MT7623's fallback. > > Signed-off-by: Sean Wang > --- > Documentation/devicetree/bindings/soc/mediatek/scpsys.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Rob Herring
Re: [PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties
On Wed, Jan 31, 2018 at 03:41:50PM +0800, Ryder Lee wrote: > Move the interrupt-map properties from the child nodes to the root node > and update each entry accordingly. > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/pci/mediatek-pcie.txt | 28 > -- > 1 file changed, 15 insertions(+), 13 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH 5/6] scsi: qedi: fix building with LTO
On 02/02/18 6:42 PM, "Arnd Bergmann" wrote:
>When link-time optimizations are enabled, qedi fails to build because
>of mismatched prototypes:
>
>drivers/scsi/qedi/qedi_gbl.h:27:37: error: type of 'qedi_dbg_fops' does
>not match original declaration [-Werror=lto-type-mismatch]
> extern const struct file_operations qedi_dbg_fops;
> ^
>drivers/scsi/qedi/qedi_debugfs.c:239:30: note: 'qedi_dbg_fops' was
>previously declared here
> const struct file_operations qedi_dbg_fops[] = {
> ^
>drivers/scsi/qedi/qedi_gbl.h:26:32: error: type of 'qedi_debugfs_ops'
>does not match original declaration [-Werror=lto-type-mismatch]
> extern struct qedi_debugfs_ops qedi_debugfs_ops;
>^
>drivers/scsi/qedi/qedi_debugfs.c:102:25: note: 'qedi_debugfs_ops' was
>previously declared here
> struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>
>This changes the declaration to match the definition, and adapts the
>users as necessary. Since both array can be constant here, I'm adding
>the 'const' everywhere for consistency.
>
>Signed-off-by: Arnd Bergmann
>---
> drivers/scsi/qedi/qedi_dbg.h | 2 +-
> drivers/scsi/qedi/qedi_debugfs.c | 4 ++--
> drivers/scsi/qedi/qedi_gbl.h | 4 ++--
> drivers/scsi/qedi/qedi_main.c| 4 ++--
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/qedi/qedi_dbg.h b/drivers/scsi/qedi/qedi_dbg.h
>index c55572badfb0..358f40567849 100644
>--- a/drivers/scsi/qedi/qedi_dbg.h
>+++ b/drivers/scsi/qedi/qedi_dbg.h
>@@ -134,7 +134,7 @@ struct qedi_debugfs_ops {
> }
>
> void qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>- struct qedi_debugfs_ops *dops,
>+ const struct qedi_debugfs_ops *dops,
> const struct file_operations *fops);
> void qedi_dbg_host_exit(struct qedi_dbg_ctx *qedi);
> void qedi_dbg_init(char *drv_name);
>diff --git a/drivers/scsi/qedi/qedi_debugfs.c
>b/drivers/scsi/qedi/qedi_debugfs.c
>index fd8a1eea3163..fd914ca4149a 100644
>--- a/drivers/scsi/qedi/qedi_debugfs.c
>+++ b/drivers/scsi/qedi/qedi_debugfs.c
>@@ -19,7 +19,7 @@ static struct dentry *qedi_dbg_root;
>
> void
> qedi_dbg_host_init(struct qedi_dbg_ctx *qedi,
>- struct qedi_debugfs_ops *dops,
>+ const struct qedi_debugfs_ops *dops,
> const struct file_operations *fops)
> {
> char host_dirname[32];
>@@ -99,7 +99,7 @@ static struct qedi_list_of_funcs
>qedi_dbg_do_not_recover_ops[] = {
> { NULL, NULL }
> };
>
>-struct qedi_debugfs_ops qedi_debugfs_ops[] = {
>+const struct qedi_debugfs_ops qedi_debugfs_ops[] = {
> { "gbl_ctx", NULL },
> { "do_not_recover", qedi_dbg_do_not_recover_ops},
> { "io_trace", NULL },
>diff --git a/drivers/scsi/qedi/qedi_gbl.h b/drivers/scsi/qedi/qedi_gbl.h
>index f5b5a31999aa..a2aa06ed1620 100644
>--- a/drivers/scsi/qedi/qedi_gbl.h
>+++ b/drivers/scsi/qedi/qedi_gbl.h
>@@ -23,8 +23,8 @@ extern uint qedi_io_tracing;
> extern struct scsi_host_template qedi_host_template;
> extern struct iscsi_transport qedi_iscsi_transport;
> extern const struct qed_iscsi_ops *qedi_ops;
>-extern struct qedi_debugfs_ops qedi_debugfs_ops;
>-extern const struct file_operations qedi_dbg_fops;
>+extern const struct qedi_debugfs_ops qedi_debugfs_ops[];
>+extern const struct file_operations qedi_dbg_fops[];
> extern struct device_attribute *qedi_shost_attrs[];
>
> int qedi_alloc_sq(struct qedi_ctx *qedi, struct qedi_endpoint *ep);
>diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
>index 029e2e69b29f..e992f9d3ef00 100644
>--- a/drivers/scsi/qedi/qedi_main.c
>+++ b/drivers/scsi/qedi/qedi_main.c
>@@ -2303,8 +2303,8 @@ static int __qedi_probe(struct pci_dev *pdev, int
>mode)
> }
>
> #ifdef CONFIG_DEBUG_FS
>- qedi_dbg_host_init(&qedi->dbg_ctx, &qedi_debugfs_ops,
>- &qedi_dbg_fops);
>+ qedi_dbg_host_init(&qedi->dbg_ctx, qedi_debugfs_ops,
>+ qedi_dbg_fops);
> #endif
> QEDI_INFO(&qedi->dbg_ctx, QEDI_LOG_INFO,
> "QLogic FastLinQ iSCSI Module qedi %s, FW %d.%d.%d.%d\n",
>--
>2.9.0
Thanks
Acked-by: Manish Rangankar
>
Re: [PATCH v2 1/2] dt-bindings: gpio: Add Spreadtrum GPIO controller documentation
On Thu, Feb 01, 2018 at 11:04:31AM +0800, Baolin Wang wrote: > This patch adds the device tree bindings for the Spreadtrum > GPIO controller. The gpios will be supported by the GPIO > generic library. > > Signed-off-by: Baolin Wang > --- > Changes since v1: > - No updates. > --- > .../devicetree/bindings/gpio/gpio-sprd.txt | 28 > > 1 file changed, 28 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-sprd.txt Reviewed-by: Rob Herring
Re: [PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device
On Wed, Jan 31, 2018 at 03:42:44PM +0800, Ryder Lee wrote:
> As the MediaTek audio hardware block that expose functionalities that are
> handled by separate subsystems in the kernel, and there are registers that
> are shared between related drivers.
>
> Switch the current device to an MFD device, add more descriptions about the
> subsystem and modify example accordingly.
>
> Signed-off-by: Ryder Lee
> ---
> .../bindings/arm/mediatek/mediatek,audsys.txt | 37
> ++
> 1 file changed, 30 insertions(+), 7 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> index 9b8f578..677af40 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> @@ -1,22 +1,45 @@
> -MediaTek AUDSYS controller
> +MediaTek Audio Subsystem
>
> +The audio subsystem is one of the multi-function blocks of MediaTek SoCs.
> +It contains a system controller, which provides a number registers giving
> +access to two features: AUDSYS clocks and Audio Front End (AFE) components.
>
> +For the top level node:
> +- compatible: must be: "syscon", "simple-mfd";
This should have some SoC specific compatible.
> +- reg: register area of the Audio Subsystem
> +
> +Required sub-nodes:
> +
> +AUDSYS clocks:
> +---
> The MediaTek AUDSYS controller provides various clocks to the system.
>
> Required Properties:
>
> - compatible: Should be one of:
> - - "mediatek,mt7622-audsys", "syscon"
> + - "mediatek,mt2701-audsys";
> + - "mediatek,mt7622-audsys";
> - #clock-cells: Must be 1
>
> The AUDSYS controller uses the common clk binding from
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> The available clocks are defined in dt-bindings/clock/mt*-clk.h.
There's no register range associated with the clocks? If there is, add a
reg property.
>
> +AFE components:
> +---
> +For common binding part and usage, refer to
> +../sonud/mt2701-afe-pcm.txt.
> +
> Example:
>
> -audsys: audsys@1122 {
> - compatible = "mediatek,mt7622-audsys", "syscon";
> - reg = <0 0x1122 0 0x1000>;
> - #clock-cells = <1>;
> -};
> + audio-subsystem@1122 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0 0x1122 0 0x2000>;
> +
> + audsys: clock {
> + compatible = "mediatek,mt2701-audsys";
> + #clock-cells = <1>;
> + };
> +
> + ...
> + };
> --
> 1.9.1
>
Re: [PATCH v3 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD
On Wed, Jan 31, 2018 at 10:35:44PM +0100, Benoît Thébaudeau wrote: > The eSDHC does not work properly if the SION bit is not set for the > bidirectional CMD signal, whatever the eSDHC instance and the selected > pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do > this for MX25_PAD_*__ESDHCn_CMD in imx25-pinfunc.h in order to enforce > this behavior for all boards. > > This had already been done for eSDHC1, but not for eSDHC2. Also, define > MX25_PAD_FEC_MDC__ESDHC2_CMD so that all the possible cases are covered > from now on. > > Cc: Uwe Kleine-König > Signed-off-by: Benoît Thébaudeau > Reviewed-by: Fabio Estevam > --- > Changes v2 -> v3: > - Quickly mention SION in each comment, besides the reference to the >verbose comment (suggested by Uwe). > Changes v1 -> v2: > - Update eSDHC instance and port naming following the addition of "ARM: >dts: imx25-pinfunc: Use consistent naming for eSDHC". > - Reference the more verbose comment for MX25_PAD_SD1_CMD__ESDHC1_CMD >instead of copying the same less detailed comment everywhere >(suggested by Uwe). > --- > arch/arm/boot/dts/imx25-pinfunc.h | 18 +++--- > 1 file changed, 11 insertions(+), 7 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys
On Wed, Jan 31, 2018 at 03:42:41PM +0800, Ryder Lee wrote: > Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys. > > Signed-off-by: Ryder Lee > --- > drivers/clk/mediatek/clk-mt7622-aud.c | 1 + > include/dt-bindings/clock/mt7622-clk.h | 3 ++- > 2 files changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Rob Herring
Re: [PATCH 1/2] of: change overlay apply input data from EDT to FDT
On Mon, Jan 29, 2018 at 04:01:38PM -0800, Frank Rowand wrote: > On 01/29/18 06:42, Rob Herring wrote: > > On Sun, Jan 28, 2018 at 8:53 PM, wrote: > >> From: Frank Rowand > >> > >> Move duplicating and unflattening of an overlay flattened devicetree > >> (FDT) into the overlay application code. To accomplish this, > >> of_overlay_apply() is replaced by of_overlay_fdt_apply(). > >> > >> The copy of the FDT (aka "duplicate FDT") now belongs to devicetree > >> code, which is thus responsible for freeing the duplicate FDT. The > >> caller of of_overlay_fdt_apply() remains responsible for freeing the > >> original FDT. > >> > >> The unflattened device tree (aka expanded device tree, EDT) now > > > > Not really a fan of a new acronym. > > > >> belongs to devicetree code, which is thus responsible for freeing > >> the EDT. > >> > >> These ownership changes prevent early freeing of the duplicated FDT > >> or the EDT, which could result in use after free errors. > >> > >> of_overlay_fdt_apply() is a private function for the anticipated > >> overlay loader. > >> > >> Update unittest.c to use of_overlay_fdt_apply() instead of > >> of_overlay_apply(). > >> > >> Move overlay fragments from artificial locations in > >> drivers/of/unittest-data/tests-overlay.dtsi into one devicetree > >> source file per overlay. This led to changes in > >> drivers/of/unitest-data/Makefile and drivers/of/unitest.c. > > I should have reversed the cause and effect in that sentence to > instead be: > > The changes to drivers/of/unittest.c require the test overlays > to be in FDT form instead of unflattened devicetree form. Move > overlay fragments from artificial locations in > drivers/of/unittest-data/tests-overlay.dtsi into one > devicetree source file per overlay and thus create > one FDT per overlay. > > > > Why the rearranging? That should be a separate patch. > Bisectability. > > I can make the changes to the devicetree files in a second patch. > After the first patch, there will be 29 self test fails. > > I will make the change unless you respond back to this saying not to. One patch is fine for me. Unit test is special. Rob
Re: [PATCH v2 1/4] soc: samsung: pmu: Populate children syscon nodes
On Tue, Jan 30, 2018 at 10:18:16PM +0100, Krzysztof Kozlowski wrote: > The syscon poweroff and restart nodes logically belong to the Power > Management Unit so populate possible children. > > This also requires providing compatibles for Exynos5410 and Exynos7 so > the PMU device and its children will be instantiated for them as well. > Just like Exynos5433, these chipsets are not yet supported by the PMU > driver. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/arm/samsung/pmu.txt | 6 ++ > drivers/soc/samsung/exynos-pmu.c | 7 +++ > 2 files changed, 13 insertions(+) Reviewed-by: Rob Herring
Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform
On Tue, Jan 30, 2018 at 11:44:33PM +0530, Manish Narani wrote: > This patch adds support of SD auto tuning for ZynqMP platform. Auto > tuning sequence sends tuning block to card when operating in UHS-1 > modes. This resets the DLL and sends CMD19/CMD21 as a part of the auto > tuning process. Once the auto tuning process gets completed, reset the > DLL to load the newly obtained SDHC tuned tap value. > > Signed-off-by: Manish Narani > --- > .../devicetree/bindings/mmc/arasan,sdhci.txt | 1 + > drivers/mmc/host/sdhci-of-arasan.c | 219 > - > 2 files changed, 219 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > index 60481bf..7d29751 100644 > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > @@ -14,6 +14,7 @@ Required Properties: > - "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY > - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY > - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY > +- "xlnx,zynqmp-8.9a": Xilinx ZynqMP 8.9a PHY This should be a separate patch. >For this device it is strongly suggested to include > arasan,soc-ctl-syscon. >- reg: From mmc bindings: Register location and length. >- clocks: From clock bindings: Handles to clock inputs.
Re: [PATCH 1/2] dt-bindings: fsi: Add optional property no-scan-on-init
On Tue, Jan 30, 2018 at 04:21:15PM +1030, Joel Stanley wrote: > From: Christopher Bostic > > Add an optional FSI master property 'no-scan-on-init. This > can be specified to indicate that a master should not be > automatically scanned at init time. This is required in cases > where a scan could interfere with another FSI master on the same > bus. > > Signed-off-by: Christopher Bostic > Acked-by: Jeremy Kerr > Signed-off-by: Joel Stanley > --- > Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt > b/Documentation/devicetree/bindings/fsi/fsi.txt > index 4eaf488d4015..ab516c673a4b 100644 > --- a/Documentation/devicetree/bindings/fsi/fsi.txt > +++ b/Documentation/devicetree/bindings/fsi/fsi.txt > @@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size: > #address-cells = <2>; > #size-cells = <0>; > > +An optional boolean property can be added to indicate that a particular > master > +should not scan for connected devices at initialization time. This is > +necessary in cases where a scan could cause arbitration issues with other > +masters that may be present on the bus. > + > +no-scan-on-init; > + The formatting here is a bit strange compared to most bindings, but no point in reformatting the document to add one property. Reviewed-by: Rob Herring Rob
Re: [PATCH 01/15] firmware: qcom: scm: Add ipq4019 soc compatible
On Mon, Jan 29, 2018 at 10:41:15AM +0530, Sricharan R wrote: > Add the compatible for ipq4019. > This does not need clocks to do scm calls. > > Signed-off-by: Sricharan R > --- > Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3 ++- > drivers/firmware/qcom_scm.c | 3 +++ > 2 files changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Rob Herring
Re: [PATCH v4 2/2] dt/bindings: Add bindings for Layerscape external irqs
On Thu, Jan 25, 2018 at 04:02:30PM +0100, Rasmus Villemoes wrote:
> This adds Device Tree binding documentation for the external interrupt
> lines with configurable polarity present on some Layerscape SOCs.
>
> Signed-off-by: Rasmus Villemoes
> ---
> Changes since v3: Add non-empty commit log.
>
> .../interrupt-controller/fsl,ls-extirq.txt | 44 ++
> 1 file changed, 44 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> new file mode 100644
> index ..a71ce2c3eeae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> @@ -0,0 +1,44 @@
> +* Freescale Layerscape external IRQs
> +
> +Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
> +the polarity of certain external interrupt lines.
> +
> +The device node must be a child of the node representing the
> +Supplemental Configuration Unit (SCFG).
> +
> +Required properties:
> +- compatible: should be "fsl,-extirq", e.g. "fsl,ls1021a-extirq".
> +- interrupt-controller: Identifies the node as an interrupt controller
> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of GIC.
> +- offset: offset to the Interrupt Polarity Control Register (INTPCR)
> + register in the SCFG.
> +- interrupts: Specifies the mapping to interrupt numbers in the parent
> + interrupt controller. Interrupts are mapped one-to-one to parent
> + interrupts.
> +
> +Optional properties:
> +- fsl,bit-reverse: This boolean property should be set on the LS1021A
> + if the SCFGREVCR register has been set to all-ones (which is usually
> + the case), meaning that all reads and writes of SCFG registers are
> + implicitly bit-reversed. Other compatible platforms do not have such
> + a register.
> +
> +Example:
> + scfg: scfg@157 {
> + compatible = "fsl,ls1021a-scfg", "syscon";
> + ...
> + extirq: interrupt-controller {
> + compatible = "fsl,ls1021a-extirq";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + interrupt-parent = <&gic>;
> + offset = <0x1ac>;
Use reg here instead (with a length).
> + interrupts = <163 164 165 167 168 169>;
These don't look like GIC interrupt cells. Building this with current
dtc will have errors.
> + fsl,bit-reverse;
> + };
> + };
> +
> +
> + interrupts-extended = <&gic GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
> + <&extirq GIC_SPI 1 IRQ_TYPE_LEVEL_LOW>;
> --
> 2.15.1
>
Re: [PATCH V2 1/2] ARM: dts: imx7s: add temperature monitor support
On Fri, Jan 26, 2018 at 04:09:39PM +0800, Anson Huang wrote:
> Add i.MX7 temperature monitor support.
>
> Signed-off-by: Anson Huang
> Acked-by: Dong Aisheng
> ---
> no changes since V1.
> .../devicetree/bindings/thermal/imx-thermal.txt | 5 +++--
> arch/arm/boot/dts/imx7s.dtsi | 20
>
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> index 28be51a..9575d45 100644
> --- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> @@ -1,8 +1,9 @@
> * Temperature Monitor (TEMPMON) on Freescale i.MX SoCs
>
> Required properties:
> -- compatible : "fsl,imx6q-tempmon" for i.MX6Q, "fsl,imx6sx-tempmon" for
> i.MX6SX.
> - i.MX6SX has two more IRQs than i.MX6Q, one is IRQ_LOW and the other is
> IRQ_PANIC,
> +- compatible : "fsl,imx6q-tempmon" for i.MX6Q, "fsl,imx6sx-tempmon" for
> i.MX6SX,
> + "fsl,imx7-tempmon" for i.MX7S/D.
Please format as one valid compatible combination per line.
> + i.MX6SX and i.MX7S/D have two more IRQs than i.MX6Q, one is IRQ_LOW and
> the other is IRQ_PANIC,
This belongs with the interrupt property.
>when temperature is below than low threshold, IRQ_LOW will be triggered,
> when temperature
>is higher than panic threshold, system will auto reboot by SRC module.
> - fsl,tempmon : phandle pointer to system controller that contains TEMPMON
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 82ad26e..2e2eda53 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -497,9 +497,29 @@
> };
>
> ocotp: ocotp-ctrl@3035 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> compatible = "fsl,imx7d-ocotp", "syscon";
> reg = <0x3035 0x1>;
> clocks = <&clks IMX7D_OCOTP_CLK>;
> +
> + tempmon_calib: calib@3c {
> + reg = <0x3c 0x4>;
> + };
> +
> + tempmon_temp_grade: temp-grade@10 {
> + reg = <0x10 0x4>;
> + };
> + };
> +
> + tempmon: tempmon {
> + compatible = "fsl,imx7-tempmon";
> + interrupts = ;
> + fsl,tempmon =<&anatop>;
> + nvmem-cells = <&tempmon_calib>,
> + <&tempmon_temp_grade>;
> + nvmem-cell-names = "calib", "temp_grade";
> + clocks = <&clks IMX7D_PLL_SYS_MAIN_CLK>;
> };
>
> anatop: anatop@3036 {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/8] dt-bindings: mfd: stm32-timers: add support for dmas
On Fri, Jan 26, 2018 at 04:11:34PM +0100, Fabrice Gasnier wrote: > Add support for DMAs to STM32 timers. STM32 Timers can support up to 7 > dma requests: up to 4 channels, update, compare and trigger. > DMAs may be used to transfer data from pwm capture for instance. > DMA support is made optional, PWM capture support is also an option. > This is much more wise system-wide to avoid shortage on DMA request > lines as there's significant amount of timer instances that can > request up to 7 channels. > > Signed-off-by: Fabrice Gasnier > --- > .../devicetree/bindings/mfd/stm32-timers.txt | 20 > > 1 file changed, 20 insertions(+) Reviewed-by: Rob Herring
Re: [PATCH 2/3] ARM: dts: imx6ull: add support for the esai interface
On Fri, Jan 26, 2018 at 09:23:51AM +0100, Lothar Waßmann wrote:
> The address space taken by the UART8 on the i.MX6UL is used for the
> ESAI interface on i.MX6ULL.
>
> Since the ESAI unit on i.MX6ULL has two more bits in the TFCR register
> (TFIN, TAENB) it deserves to get its own compatible string, though the
> bits are currently not used by the driver.
>
> Signed-off-by: Lothar Waßmann
> ---
> Documentation/devicetree/bindings/sound/fsl,esai.txt | 4 ++--
> arch/arm/boot/dts/imx6ull.dtsi | 17 +
> sound/soc/fsl/fsl_esai.c | 1 +
> 3 files changed, 20 insertions(+), 2 deletions(-)
As mentioned, this really should be 3 patches. At least split out the
dts file.
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt
> b/Documentation/devicetree/bindings/sound/fsl,esai.txt
> index cacd18b..4103f46 100644
> --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
> @@ -7,8 +7,8 @@ other DSPs. It has up to six transmitters and four receivers.
>
> Required properties:
>
> - - compatible : Compatible list, must contain
> "fsl,imx35-esai" or
> - "fsl,vf610-esai"
> + - compatible : Compatible list, must contain
> "fsl,imx35-esai",
> + "fsl,vf610-esai" or "fsl,imx6ull-esai"
Please reformat as on compatible per line.
>
>- reg : Offset and length of the register set for the
> device.
>
> diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
> index abc815f..8724fdb2 100644
> --- a/arch/arm/boot/dts/imx6ull.dtsi
> +++ b/arch/arm/boot/dts/imx6ull.dtsi
> @@ -47,6 +47,23 @@
> aips-bus@200 {
> spba-bus@200 {
> /delete-node/ serial@2024000;
> +
> + esai: esai@2024000 {
> + compatible = "fsl,imx6ull-esai",
> "fsl,imx35-esai";
> + reg = <0x02024000 0x4000>;
> + interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6ULL_CLK_ESAI_IPG>,
> + <&clks IMX6ULL_CLK_ESAI_MEM>,
> + <&clks IMX6ULL_CLK_ESAI_EXTAL>,
> + <&clks IMX6ULL_CLK_ESAI_IPG>,
> + <&clks IMX6UL_CLK_SPBA>;
> + clock-names = "core", "mem", "extal",
> + "fsys", "spba";
> + dmas = <&sdma 0 21 0>,
> +<&sdma 47 21 0>;
> + dma-names = "rx", "tx";
> + status = "disabled";
Don't show status in examples.
> + };
> };
> };
>
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index cef79a1..5b6a53f 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -910,6 +910,7 @@ static int fsl_esai_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id fsl_esai_dt_ids[] = {
> + { .compatible = "fsl,imx6ull-esai", },
> { .compatible = "fsl,imx35-esai", },
> { .compatible = "fsl,vf610-esai", },
> {}
> --
> 2.1.4
>
Re: [PATCH 1/2] dt-bindings: nvmem: imx-ocotp: update the binding to reflect data cells
On Thu, Jan 25, 2018 at 03:37:28PM +0800, Dong Aisheng wrote: > imx-ocotp is implemented based on nvmem which can have data cells > as child node. Update the binding doc to reflect it to be more easily > understood by users. > > Cc: Srinivas Kandagatla > Cc: Rob Herring > Cc: Mark Rutland > Cc: Shawn Guo > Signed-off-by: Dong Aisheng > --- > .../devicetree/bindings/nvmem/imx-ocotp.txt| 23 > ++ > 1 file changed, 19 insertions(+), 4 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH] ARM: dts: imx6ull: add Toradex Colibri iMX6ULL support
On Fri, Jan 19, 2018 at 01:11:25AM +0100, Stefan Agner wrote:
> Add support for the Computer on Module Colibri iMX6ULL and its
> Bluetooth/Wifi variant along with the development/evaluation carrier
> board device trees. Follow the usual hierarchic include model,
> maintaining shared configuration in imx6ull-colibri.dtsi and
> imx6ull-colibri-eval-v3.dtsi respectively.
>
> Signed-off-by: Stefan Agner
> ---
> This depends on the following patchsets work:
> - https://lkml.org/lkml/2018/1/6/129 (applied)
> - https://lkml.org/lkml/2018/1/10/998 (pending, required)
> - https://lkml.org/lkml/2018/1/18/850 (only for highest CPU frequency)
>
> --
> Stefan
>
> arch/arm/boot/dts/Makefile | 4 +-
> arch/arm/boot/dts/imx6ull-colibri-eval-v3.dts | 14 +
> arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi | 158 ++
> arch/arm/boot/dts/imx6ull-colibri-nonwifi.dtsi | 24 +
> arch/arm/boot/dts/imx6ull-colibri-wifi-eval-v3.dts | 14 +
> arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi| 70 +++
> arch/arm/boot/dts/imx6ull-colibri.dtsi | 554
> +
> 7 files changed, 837 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx6ull-colibri-eval-v3.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-colibri-nonwifi.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-colibri-wifi-eval-v3.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-colibri.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7fc7bcefc3a0..6411b3069e8d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -525,7 +525,9 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> imx6ul-tx6ul-0010.dtb \
> imx6ul-tx6ul-0011.dtb \
> imx6ul-tx6ul-mainboard.dtb \
> - imx6ull-14x14-evk.dtb
> + imx6ull-14x14-evk.dtb \
> + imx6ull-colibri-eval-v3.dtb \
> + imx6ull-colibri-wifi-eval-v3.dtb
> dtb-$(CONFIG_SOC_IMX7D) += \
> imx7d-cl-som-imx7.dtb \
> imx7d-colibri-emmc-eval-v3.dtb \
> diff --git a/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dts
> b/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dts
> new file mode 100644
> index ..08669a18349e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2018 Toradex AG
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6ull-colibri-nonwifi.dtsi"
> +#include "imx6ull-colibri-eval-v3.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6ULL 256MB on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri-imx6ull-eval", "fsl,imx6ull";
> +};
> diff --git a/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
> b/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
> new file mode 100644
> index ..01acc0238e5e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2017 Toradex AG
> + */
> +
> +/ {
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + /* fixed crystal dedicated to mcp2515 */
> + clk16m: clk16m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + };
> +
> + panel: panel {
> + compatible = "edt,et057090dhu";
> + backlight = <&bl>;
> + power-supply = <®_3v3>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdif_out>;
> + };
> + };
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_5v0: regulator-5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "5V";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + reg_usbh_vbus: regulator-usbh-vbus {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh_reg>;
> + regulator-name = "VCC_USB[1-4]";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpio1 2 GPIO_ACTIVE_LOW>;
> + vin-supply = <®_5v0>;
> + };
> +};
> +
> +&bl {
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + power-supply = <®_3v3>;
> + pwms = <&pwm4 0 500 1>;
> +
Drop the newline.
> + status = "okay";
> +};
> +
> +&adc1 {
'adc1' should go befor
Re: [PATCH v6 24/41] ARM: dm644x: add new clock init using common clock framework
On Friday 02 February 2018 11:36 PM, David Lechner wrote: > On 02/02/2018 08:39 AM, Sekhar Nori wrote: >> On Saturday 20 January 2018 10:44 PM, David Lechner wrote: >>> This adds the new board-specific clock init in mach-davinci/dm644x.c >>> using the new common clock framework drivers. >>> >>> The #ifdefs are needed to prevent compile errors until the entire >>> ARCH_DAVINCI is converted. >>> >>> Also clean up the #includes since we are adding some here. >>> >>> Signed-off-by: David Lechner >> >> I did not notice this before, but the subject line for this and other >> patches needs to be "ARM: davinci: " > > so "davinci" == "dm644x" and not any other SoC? No, I meant "ARM: davinci: dm644x: " instead of just "ARM: dm644x". Thanks, Sekhar
Re: [PATCH v3] dmaengine: dmatest: add norandom option
On Fri, Feb 02, 2018 at 05:51:09PM +0800, Yang Shunyong wrote: > Existing option noverify disables both random src/dst address offset > setup and data verification. Sometimes, we need to control random > src/dst address setup and verification separately, such as disabling > random to make sure that test covers addresses in all interleaving > banks, but data verification is still performed. > > This patch adds option norandom to disable random offset setup. Option > noverify has been changed to disable data verification only. Applied, thanks -- ~Vinod
Re: [PATCH] dmaengine: avoid map_cnt overflow with CONFIG_DMA_ENGINE_RAID
On Mon, Jan 08, 2018 at 10:50:50AM -0500, Zi Yan wrote: > From: Zi Yan > > When CONFIG_DMA_ENGINE_RAID is enabled, unmap pool size can reach to > 256. But in struct dmaengine_unmap_data, map_cnt is only u8, wrapping > to 0, if the unmap pool is maximally used. This triggers BUG() when > struct dmaengine_unmap_data is freed. Use u16 to fix the problem. Applied, thanks -- ~Vinod
[RFC PATCH 2/2] rmqueue_bulk: avoid touching page structures under zone->lock
Profile on Intel Skylake server shows the most time consuming part
under zone->lock on allocation path is accessing those to-be-returned
page's struct page in rmqueue_bulk() and its child functions.
We do not really need to touch all those to-be-returned pages under
zone->lock, just need to move them out of the order 0's free_list and
adjust area->nr_free under zone->lock, other operations on page structure
like rmv_page_order(page) etc. could be done outside zone->lock.
So if it's possible to know the 1st and the last page structure of the
pcp->batch number pages in the free_list, we can achieve the above
without needing to touch all those page structures in between. The
problem is, the free page is linked in a doubly list so we only know
where the head and tail is, but not the Nth element in the list.
Assume order0 mt=Movable free_list has 7 pages available:
head <-> p7 <-> p6 <-> p5 <-> p4 <-> p3 <-> p2 <-> p1
One experiment I have done here is to add a new list for it: say
cluster list, where it will link pages of every pcp->batch(th) element
in the free_list.
Take pcp->batch=3 as an example, we have:
free_list: head <-> p7 <-> p6 <-> p5 <-> p4 <-> p3 <-> p2 <-> p1
cluster_list: head <> p6 <---> p3
Let's call p6-p4 a cluster, similarly, p3-p1 is another cluster.
Then every time rmqueue_bulk() is called to get 3 pages, we will iterate
the cluster_list first. If cluster list is not empty, we can quickly locate
the first and last page, p6 and p4 in this case(p4 is retrieved by checking
p6's next on cluster_list and then check p3's prev on free_list). This way,
we can reduce the need to touch all those page structures in between under
zone->lock.
Note: a common pcp->batch should be 31 since it is the default PCP batch number.
With this change, on 2 sockets Skylake server, with will-it-scale/page_fault1
full load test, zone lock has gone, lru_lock contention rose to 70% and
performance increased by 16.7% compared to vanilla.
There are some fundemental problems with this patch though:
1 When compaction occurs, the number of pages in a cluster could be less than
predefined; this will make "1 cluster can satify the request" not true any
more.
Due to this reason, the patch currently requires no compaction to happen;
2 When new pages are freed to order 0 free_list, it could merge with its buddy
and that would also cause fewer pages left in a cluster. Thus, no merge
for order-0 is required for this patch to work;
3 Similarly, when fallback allocation happens, the same problem could happen
again.
Considering the above listed problems, this patch can only serve as a POC that
cache miss is the most time consuming operation in big server. Your comments
on a possible way to overcome them are greatly appreciated.
Suggested-by: Ying Huang
Signed-off-by: Aaron Lu
---
include/linux/mm_types.h | 43 ++
include/linux/mmzone.h | 7 +++
mm/page_alloc.c | 114 ---
3 files changed, 141 insertions(+), 23 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index cfd0ac4e5e0e..e7aee48a224a 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -43,26 +43,33 @@ struct page {
/* First double word block */
unsigned long flags;/* Atomic flags, some possibly
* updated asynchronously */
- union {
- struct address_space *mapping; /* If low bit clear, points to
-* inode address_space, or NULL.
-* If page mapped as anonymous
-* memory, low bit is set, and
-* it points to anon_vma object
-* or KSM private structure. See
-* PAGE_MAPPING_ANON and
-* PAGE_MAPPING_KSM.
-*/
- void *s_mem;/* slab first object */
- atomic_t compound_mapcount; /* first tail page */
- /* page_deferred_list().next -- second tail page */
- };
- /* Second double word */
union {
- pgoff_t index; /* Our offset within mapping. */
- void *freelist; /* sl[aou]b first free object */
- /* page_deferred_list().prev-- second tail page */
+ struct {
+ union {
+ struct address_space *mapping; /* If low bit
clear, points to
+* inode
address_space, or NULL.
+* If page
mapped as anonymous
+
[RFC PATCH 1/2] __free_one_page: skip merge for order-0 page unless compaction is in progress
Running will-it-scale/page_fault1 process mode workload on a 2 sockets
Intel Skylake server showed severe lock contention of zone->lock, as
high as about 80%(43% on allocation path and 38% on free path) CPU
cycles are burnt spinning. With perf, the most time consuming part inside
that lock on free path is cache missing on page structures, mostly on
the to-be-freed page's buddy due to merging.
One way to avoid this overhead is not do any merging at all for order-0
pages and leave the need for high order pages to compaction. With this
approach, the lock contention for zone->lock on free path dropped to 4%
but allocation side still has as high as 43% lock contention. In the
meantime, the dropped lock contention on free side doesn't translate to
performance increase, instead, it's consumed by increased lock contention
of the per node lru_lock(rose from 2% to 33%).
One concern of this approach is, how much impact does it have on high order
page allocation, like for order-9 pages? I have run the stress-highalloc
workload on a Haswell Desktop(8 CPU/4G memory) sometime ago and it showed
similar success rate for vanilla kernel and the patched kernel, both at 74%.
Note that it indeed took longer to finish the test: 244s vs 218s.
1 vanilla
Attempted allocations: 1917
Failed allocs: 494
Success allocs: 1423
% Success:74
Duration alloctest pass:218s
2 no_merge_in_buddy
Attempted allocations: 1917
Failed allocs: 497
Success allocs:1420
% Success: 74
Duration alloctest pass: 244s
The above test was done with the default --ms-delay=100, which means there
is a delay of 100ms between page allocations. If I set the delay to 1ms,
the success rate of this patch will drop to 36% while vanilla could maintain
at about 70%. Though 1ms delay may not be practical, it indeed shows the
possible impact of this patch on high order page allocation.
The next patch deals with allocation path zone->lock contention.
Suggested-by: Dave Hansen
Signed-off-by: Aaron Lu
---
mm/compaction.c | 28 ++
mm/internal.h | 15 +++-
mm/page_alloc.c | 116
3 files changed, 117 insertions(+), 42 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 10cd757f1006..b53c4d420533 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -669,6 +669,28 @@ static bool too_many_isolated(struct zone *zone)
return isolated > (inactive + active) / 2;
}
+static int merge_page(struct zone *zone, struct page *page, unsigned long pfn)
+{
+ int order = 0;
+ unsigned long buddy_pfn = __find_buddy_pfn(pfn, order);
+ struct page *buddy = page + (buddy_pfn - pfn);
+
+ /* Only do merging if the merge skipped page's buddy is also free */
+ if (PageBuddy(buddy)) {
+ int mt = get_pageblock_migratetype(page);
+ unsigned long flags;
+
+ spin_lock_irqsave(&zone->lock, flags);
+ if (likely(page_merge_skipped(page))) {
+ do_merge(zone, page, mt);
+ order = page_order(page);
+ }
+ spin_unlock_irqrestore(&zone->lock, flags);
+ }
+
+ return order;
+}
+
/**
* isolate_migratepages_block() - isolate all migrate-able pages within
* a single pageblock
@@ -777,6 +799,12 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
*/
if (PageBuddy(page)) {
unsigned long freepage_order = page_order_unsafe(page);
+ /*
+* If the page didn't do merging on free time, now do
+* it since we are doing compaction.
+*/
+ if (page_merge_skipped(page))
+ freepage_order = merge_page(zone, page,
low_pfn);
/*
* Without lock, we cannot be sure that what we got is
diff --git a/mm/internal.h b/mm/internal.h
index e6bd35182dae..d2b0ac02d459 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -228,9 +228,22 @@ int find_suitable_fallback(struct free_area *area,
unsigned int order,
static inline unsigned int page_order(struct page *page)
{
/* PageBuddy() must be checked by the caller */
- return page_private(page);
+ return page_private(page) & ~(1 << 16);
}
+/*
+ * This function returns if the page is in buddy but didn't do any merging
+ * for performance reason. This function only makes sense if PageBuddy(page)
+ * is also true. The caller should hold zone->lock for this function to return
+ * correct value, or it can handle invalid values gracefully.
+ */
+static inline bool page_merge_skipped(struct page *page)
+{
+ return PageBuddy(page) && (page
RFC: eliminate zone->lock contention for will-it-scale/page_fault1 on big server
In addition the the two patches, there are two more patches that I would like to get some feedback. The two patches are more radical: the 3rd deals with free path zone->lock contention by avoiding doing any merge for order0 pages while the 4th deals with allocation path zone->lock contention by taking pcp->batch pages off the free_area order0 list without the need to iterate the list. Both patches are developed based on "the most time consuming part of operations under zone->lock is cache misses on struct page". The 3rd patch may be controversial but doesn't have correctness problem; the 4th is in an early stage and serves only as a proof-of-concept. Your comments are appreciated, thanks.
Re: [PATCH] ARM: dts: imx6q-bx50v3: Enable secure-reg-access
On Fri, Feb 02, 2018 at 12:10:04PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Fri, Feb 02, 2018 at 03:18:20PM +0800, Shawn Guo wrote:
> > + Frank
> >
> > On Mon, Jan 15, 2018 at 05:07:22PM +0100, Sebastian Reichel wrote:
> > > From: Peter Senna Tschudin
> > >
> > > Add secure-reg-access on device tree include file for Bx50 devices
> > > to enable PMU and hardware counters for perf.
> > >
> > > Signed-off-by: Peter Senna Tschudin
> > > Signed-off-by: Sebastian Reichel
> > > ---
> > > arch/arm/boot/dts/imx6q-bx50v3.dtsi | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > > b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > > index 86cfd4481e72..ccaaee83e2fa 100644
> > > --- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > > +++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > > @@ -43,6 +43,13 @@
> > > #include "imx6q-ba16.dtsi"
> > >
> > > / {
> > > + soc {
> > > + pmu {
> > > + compatible = "arm,cortex-a9-pmu";
> > > + secure-reg-access;
> >
> > I'm not sure this could be a board level configuration. Shouldn't this
> > property just be added into pmu node in imx6qdl.dtsi?
>
> This cannot become part of imx6qdl.dtsi for two reasons:
>
> 1. It's not safe to be enabled on imx6qdl in secure state, see
>excerpt from DT binding documentation below
> 2. We cannot enable it by default, since DTS format does not provide
>a method to unset it in board files using a imx6qdl in secure
>mode.
>
> Here is an extract from the DT documentation for the PMU node:
>
> - secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
> (SDER) is accessible. This will cause the driver to do
> any setup required that is only possible in ARMv7 secure
> state. If not present the ARMv7 SDER will not be touched,
> which means the PMU may fail to operate unless external
> code (bootloader or security monitor) has performed the
> appropriate initialisation. Note that this property is
> not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
> in Non-secure state.
>
> For B450v3, B650v3 and B850v3 it's safe to enable the bit and it
> improves debugging capabilities a lot.
Okay. Then please label the pmu node in imx6qdl.dtsi and referencing
the node in board dts without duplicating soc node and compatible.
Shawn
Вітаю, ви виграли € 650,000.00
Вітаю, ви виграли € 650,000.00 в "Євро Мільйони" / Google Рекламні щомісячні акції проводяться 1-го февраля 2018 року. Зверніться до нашого претензійного агента за вказаною нижче інформацією електронною поштою: janosiklubos...@gmail.com 1. Повне ім'я: 2. Адреса: 3. Стать: 4. Вік: 5. Рід занять: 6. Телефон: Роберт Автанділтайн Інтернет-координатор
[PATCH v4] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530
The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
of box.
The touchpad relies on its _INI method to update its _HID value from
to SYNA2393.
Also, the _STA relies on value of I2CN to report correct status.
Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
correctly set up, and _INI can get run. The ACPI table in this machine
is designed to get parsed this way.
Also, change the quirk table to a more generic name.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198515
Cc: Mario Limonciello
Signed-off-by: Kai-Heng Feng
---
v4: Remove unnecessary message for user.
v3: Put the function under right #ifdef, comment adjustment
v2: Andy's suggestion, merge to a single quirk table.
drivers/acpi/bus.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index f87ed3be779a..11c6dda233d6 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -66,10 +66,37 @@ static int set_copy_dsdt(const struct dmi_system_id *id)
return 0;
}
#endif
+static int set_gbl_term_list(const struct dmi_system_id *id)
+{
+ acpi_gbl_parse_table_as_term_list = 1;
+ return 0;
+}
-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
+static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = {
+ /*
+* Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C
+* mode.
+* https://bugzilla.kernel.org/show_bug.cgi?id=198515
+*/
+ {
+ .callback = set_gbl_term_list,
+ .ident = "Dell Precision M5530",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"),
+ },
+ },
+ {
+ .callback = set_gbl_term_list,
+ .ident = "Dell XPS 15 9570",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
+ },
+ },
/*
* Invoke DSDT corruption work-around on all Toshiba Satellite.
+* DSDT will be copied to memory.
* https://bugzilla.kernel.org/show_bug.cgi?id=14679
*/
{
@@ -83,7 +110,7 @@ static const struct dmi_system_id dsdt_dmi_table[]
__initconst = {
{}
};
#else
-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
+static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = {
{}
};
#endif
@@ -1019,11 +1046,8 @@ void __init acpi_early_init(void)
acpi_permanent_mmap = true;
- /*
-* If the machine falls into the DMI check table,
-* DSDT will be copied to memory
-*/
- dmi_check_system(dsdt_dmi_table);
+ /* Check machine-specific quirks */
+ dmi_check_system(acpi_quirks_dmi_table);
status = acpi_reallocate_root_table();
if (ACPI_FAILURE(status)) {
--
2.15.1
Re: [PATCH v3] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530
> On Feb 4, 2018, at 4:26 PM, Rafael J. Wysocki wrote:
>
> On Wed, Jan 31, 2018 at 5:56 AM, Kai-Heng Feng
> wrote:
>> The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
>> of box.
>>
>> The touchpad relies on its _INI method to update its _HID value from
>> to SYNA2393.
>> Also, the _STA relies on value of I2CN to report correct status.
>>
>> Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
>> correctly set up, and _INI can get run. The ACPI table in this machine
>> is designed to get parsed this way.
>>
>> Also, change the quirk table to a more generic name.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198515
>> Cc: Mario Limonciello
>> Signed-off-by: Kai-Heng Feng
>> ---
>> v3: Put the function under right #ifdef, comment adjustment
>>
>> v2: Andy's suggestion, merge to a single quirk table.
>>
>> drivers/acpi/bus.c | 40 +---
>> 1 file changed, 33 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> index 4d0979e02a28..7cb18bc2b59a 100644
>> --- a/drivers/acpi/bus.c
>> +++ b/drivers/acpi/bus.c
>> @@ -66,10 +66,39 @@ static int set_copy_dsdt(const struct dmi_system_id *id)
>>return 0;
>> }
>> #endif
>> +static int set_gbl_term_list(const struct dmi_system_id *id)
>> +{
>> + pr_notice("%s detected - parse the entire table as a term_list\n",
>> + id->ident);
>
> This is not a useful message for a user (who may not know what
> trem_list is). Care to change it to something more useful, or even
> drop it?
Yes, I think it should be dropped. The information is already in the
commit log and comment section, if the user really wants to know
more.
Kai-Heng
Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection
On 18-01-13 00:33:09, Matthew Thode wrote: > On 18-01-12 15:07:12, David Herrmann wrote: > > Hi Andy > > > > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko > > wrote: > > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann > > > wrote: > > >> Cc: Matthew Thode > > > > > > Shouldn't be Suggested-by or even Signed-off-by? > > > > The patch is different (Matthew originally suppressed the ACPI event), > > so I did not copy the sign-off. Please add Suggested-by, if that is an > > acceptable tag. > > > > >> Signed-off-by: David Herrmann > > > > > > > > >> + case TP_HKEY_EV_PALM_DETECTED: > > >> + case TP_HKEY_EV_PALM_UNDETECTED: > > > > > >> + /* palm detected hovering the keyboard, forward to > > >> user-space > > >> +* via netlink for consumption */ > > > > > > Comment style is > > > /* > > > * Multi line comment. > > > * This is an example. > > > */ > > > > All other 6 comments in this function follow the style I used here, so > > I tried to be consistent. But feel free to amend this change. > > > > I'm fine with a signed-off-by or tested-by or suggested-by. There is a > spelling mistake though, 'hoveres' should be hovers. > Is there anything else I can do here? I'm not sure any of us have the ability to find out what lenovo actualy wants this for. Sorry for the double reply, dmarc can be hell. -- Matthew Thode signature.asc Description: PGP signature
Re: [GIT PULL tools] Linux kernel memory model
On Sun, Feb 04, 2018 at 05:29:00PM +0100, Andrea Parri wrote:
> On Sun, Feb 04, 2018 at 02:17:00AM -0800, Paul E. McKenney wrote:
>
> [...]
>
> > And here is the updated commit adding comments to the litmus test,
> > which adds comments for the three litmus tests added above. I have also
> > marked this commit with "EXP" indicating that it has not yet had time
> > for review. This marking appears only on my commits -- others' commits
> > don't get pulled until there has been time for review. (I have to put
> > my commits somewhere, and maintaining two different branches would be
> > a real mess given the likelihood of depeendencies among comits.)
> >
> > Thanx, Paul
> >
> >
> >
> > commit 49af6e403afab890a54518980d345431d74234a4
> > Author: Paul E. McKenney
> > Date: Sat Feb 3 00:04:49 2018 -0800
> >
> > EXP litmus_tests: Add comments explaining tests' purposes
> >
> > This commit adds comments to the litmus tests summarizing what these
> > tests are intended to demonstrate.
> >
> > Suggested-by: Ingo Molnar
> > Signed-off-by: Paul E. McKenney
> >
> > diff --git a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> > b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> > index 5b83d57f6ac5..8e8ae8989085 100644
> > --- a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> > C CoRR+poonceonce+Once
> >
> > +(*
> > + * Test of read-read coherence, that is, whether or not two successive
> > + * reads from the same variable are ordered. They should be ordered,
> > + * that is, this test should be forbidden.
> > + *)
> > +
> > {}
> >
> > P0(int *x)
> > diff --git a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > index fab91c13d52c..0078ecd76f5e 100644
> > --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> > C CoRW+poonceonce+Once
> >
> > +(*
> > + * Test of read-write coherence, that is, whether or not a read from a
> > + * given variable followed by a write to that same variable are ordered.
> > + * This should be ordered, that is, this test should be forbidden.
> > + *)
> > +
> > {}
> >
> > P0(int *x)
> > diff --git a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > index 6a35ec2042ea..c9d342c8fbec 100644
> > --- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > +++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> > @@ -1,5 +1,11 @@
> > C CoWR+poonceonce+Once
> >
> > +(*
> > + * Test of write-read coherence, that is, whether or not a write to a
> > + * given variable followed by a read from that same variable are ordered.
> > + * They should be ordered, that is, this test should be forbidden.
> > + *)
> > +
> > {}
> >
> > P0(int *x)
> > diff --git a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> > b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> > index 32a96b832021..ad51c7b17f7b 100644
> > --- a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> > +++ b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> > @@ -1,5 +1,11 @@
> > C CoWW+poonceonce
> >
> > +(*
> > + * Test of write-write coherence, that is, whether or not two successive
> > + * writes to the same variable are ordered. They should be ordered, that
> > + * is, this test should be forbidden.
> > + *)
> > +
> > {}
> >
> > P0(int *x)
> > diff --git
> > a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> > b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> > index 7eba2c68992b..8a58abce69fe 100644
> > --- a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> > +++ b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> > @@ -1,5 +1,14 @@
> > C IRIW+mbonceonces+OnceOnce
> >
> > +(*
> > + * Test of independent reads from independent writes with smp_mb()
> > + * between each pairs of reads. In other words, is smp_mb() sufficient to
> > + * cause two different reading processes to agree on the order of a pair
> > + * of writes, where each write is to a different variable by a different
> > + * process? The smp_mb()s should be sufficient, that is, this test should
> > + * be forbidden.
> > + *)
> > +
> > {}
> >
> > P0(int *x)
> > diff --git
> > a/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
> > b/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
> > index b0556c6c75d4..c736cd372207 100644
> > --- a/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
> > +++ b/tools/memory-model/litmus-test
Re: [PATCH 02/20] KVM: PPC: Book3S PR: Fix broken select due to misspelling
On Mon, Feb 5, 2018 at 5:48 AM, Paul Mackerras wrote:
> On Mon, Feb 05, 2018 at 02:21:14AM +0100, Ulf Magnusson wrote:
>> Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
>> on non-pseries platforms") added a reference to the globally undefined
>> symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
>> probably intended.
>>
>> Change PPC_SERIES to PPC_PSERIES.
>>
>> Discovered with the
>> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
>> script.
>>
>> Signed-off-by: Ulf Magnusson
>
> Acked-by: Paul Mackerras
>
> Which tree is this series going into?
>
> Paul.
I didn't have a particular one in mind. I imagined people would pick
up individual patches into the trees that make the most sense. It was
easiest to do the undefined symbol removal as a kernel-wide batch job.
All patches are against linux-next.
Cheers,
Ulf
Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed
On 2/2/2018 8:53 AM, Asutosh Das (asd) wrote:
On 1/31/2018 1:09 PM, Avri Altman wrote:
Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?
Thanks,
Avri
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
; Asutosh Das ; open
list
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed
From: Venkat Gopalakrishnan
As multiple requests are submitted to the ufs host controller in
parallel there
could be instances where the command completion interrupt arrives
later for a
request that is already processed earlier as the corresponding
doorbell was
cleared when handling the previous interrupt. Read the interrupt
status in a
loop after processing the received interrupt to catch such interrupts
and handle
it.
Signed-off-by: Venkat Gopalakrishnan
Signed-off-by: Asutosh Das
---
drivers/scsi/ufs/ufshcd.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void
*__hba)
u32 intr_status, enabled_intr_status;
irqreturn_t retval = IRQ_NONE;
struct ufs_hba *hba = __hba;
+ int retries = hba->nutrs;
spin_lock(hba->host->host_lock);
intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
- enabled_intr_status =
- intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);
- if (intr_status)
- ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+ /*
+ * There could be max of hba->nutrs reqs in flight and in worst
case
+ * if the reqs get finished 1 by 1 after the interrupt status is
+ * read, make sure we handle them by checking the interrupt status
+ * again in a loop until we process all of the reqs before
returning.
+ */
+ do {
+ enabled_intr_status =
+ intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+ if (intr_status)
+ ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+ if (enabled_intr_status) {
+ ufshcd_sl_intr(hba, enabled_intr_status);
+ retval = IRQ_HANDLED;
+ }
+
+ intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+ } while (intr_status && --retries);
- if (enabled_intr_status) {
- ufshcd_sl_intr(hba, enabled_intr_status);
- retval = IRQ_HANDLED;
- }
spin_unlock(hba->host->host_lock);
return retval;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux
Foundation Collaborative Project.
Hi
yes - interrupt aggregation makes sense here. But there were some
performance concerns with it; well, I don't have the data to back that
up now though.
However, I can code it up and check it.
Will post it in some time.
-asd
Hi Avri,
I went through the UFS HCI - v2.1 spec. Specifically, in sec 7.2.3 it
explicitly mentions that the software should determine if new TRs were
completed since the interrupt status was last read/cleared. This step is
independent of aggregation.
So I think the above implementation makes sense. Please let me know if I
understood your concern correctly.
-asd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection
On 18-01-13 00:33:09, Matthew Thode wrote: > On 18-01-12 15:07:12, David Herrmann wrote: > > Hi Andy > > > > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko > > wrote: > > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann > > > wrote: > > >> Cc: Matthew Thode > > > > > > Shouldn't be Suggested-by or even Signed-off-by? > > > > The patch is different (Matthew originally suppressed the ACPI event), > > so I did not copy the sign-off. Please add Suggested-by, if that is an > > acceptable tag. > > > > >> Signed-off-by: David Herrmann > > > > > > > > >> + case TP_HKEY_EV_PALM_DETECTED: > > >> + case TP_HKEY_EV_PALM_UNDETECTED: > > > > > >> + /* palm detected hovering the keyboard, forward to > > >> user-space > > >> +* via netlink for consumption */ > > > > > > Comment style is > > > /* > > > * Multi line comment. > > > * This is an example. > > > */ > > > > All other 6 comments in this function follow the style I used here, so > > I tried to be consistent. But feel free to amend this change. > > > > I'm fine with a signed-off-by or tested-by or suggested-by. There is a > spelling mistake though, 'hoveres' should be hovers. > Is there anything else I can do here? I'm not sure any of us have the ability to find out what lenovo actually wants this for. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [PATCH] [BUGFIX] media: vb2: Fix videobuf2 to map correct area
On Mon, 5 Feb 2018 11:30:41 +0900
Masami Hiramatsu wrote:
> Fixes vb2_vmalloc_get_userptr() to ioremap correct area.
> Since the current code does ioremap the page address, if the offset > 0,
> it does not do ioremap the last page and results in kernel panic.
>
> This fixes to pass the page address + offset to ioremap so that ioremap
> can map correct area. Also, this uses __pfn_to_phys() to get the physical
> address of given PFN.
>
> Signed-off-by: Masami Hiramatsu
> Reported-by: Takao Orito
Oops, I've missed the original reporter.
Reported-by: Fumihiro ATSUMI
Thank you,
> ---
> drivers/media/v4l2-core/videobuf2-vmalloc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
> b/drivers/media/v4l2-core/videobuf2-vmalloc.c
> index 3a7c80cd1a17..896f2f378b40 100644
> --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
> +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
> @@ -106,7 +106,7 @@ static void *vb2_vmalloc_get_userptr(struct device *dev,
> unsigned long vaddr,
> if (nums[i-1] + 1 != nums[i])
> goto fail_map;
> buf->vaddr = (__force void *)
> - ioremap_nocache(nums[0] << PAGE_SHIFT, size);
> + ioremap_nocache(__pfn_to_phys(nums[0]) + offset, size);
> } else {
> buf->vaddr = vm_map_ram(frame_vector_pages(vec), n_pages, -1,
> PAGE_KERNEL);
>
--
Masami Hiramatsu
Re: [PATCH 02/20] KVM: PPC: Book3S PR: Fix broken select due to misspelling
On Mon, Feb 05, 2018 at 02:21:14AM +0100, Ulf Magnusson wrote:
> Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
> on non-pseries platforms") added a reference to the globally undefined
> symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
> probably intended.
>
> Change PPC_SERIES to PPC_PSERIES.
>
> Discovered with the
> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> script.
>
> Signed-off-by: Ulf Magnusson
Acked-by: Paul Mackerras
Which tree is this series going into?
Paul.
[PATCH v2 03/20] kconfig: Remove leftover references to AVR32 symbol
The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture"). Remove the remaining references to it
from the Kconfig files.
Signed-off-by: Ulf Magnusson
---
Changes in v2:
Removal of AVR32_AT32AP_CPUFREQ is already pending in
https://marc.info/?i=20180118200202.11883-1-clabbe.montjoie%40gmail.com (which
also does it properly -- I forgot to search for related files here). Just
remove the other references.
drivers/pwm/Kconfig | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/video/console/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50ea57d..f16aad3bf5d6 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -43,7 +43,7 @@ config PWM_AB8500
config PWM_ATMEL
tristate "Atmel PWM support"
- depends on ARCH_AT91 || AVR32
+ depends on ARCH_AT91
help
Generic PWM framework driver for Atmel SoC.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b81..c1e455d46c7f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -72,7 +72,7 @@ config SPI_ARMADA_3700
config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on HAS_DMA
- depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
+ depends on (ARCH_AT91 || COMPILE_TEST)
help
This selects a driver for the Atmel SPI Controller, present on
many AT32 (AVR32) and AT91 (ARM) chips.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..be63759b6027 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -7,7 +7,7 @@ menu "Console display driver support"
config VGA_CONSOLE
bool "VGA text console" if EXPERT || !X86
depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
- !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
+ !SUPERH && !BLACKFIN && !MN10300 && !CRIS && \
(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
&& \
!ARM64 && !ARC && !MICROBLAZE && !OPENRISC
default y
--
2.14.1
Re: [PATCH] ARM: dts: imx: Add support for Advantech DMS-BA16
Hi Andrew,
Will provide the v2 for all the fixes.
Thank you for the comments.
On Sun, Feb 4, 2018 at 11:22 AM, Andrew Lunn wrote:
> On Mon, Feb 05, 2018 at 02:45:14AM +0800, Ken Lin wrote:
>> Add support for Advantech DMS-BA16 board, which use
>> the Advantech BA-16 module.
>>
>> Signed-off-by: Ken Lin
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/imx6q-dms-ba16.dts | 154
>> +++
>> 2 files changed, 155 insertions(+)
>> create mode 100644 arch/arm/boot/dts/imx6q-dms-ba16.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index ade7a38543dc..d97511273f30 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -428,6 +428,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>> imx6q-b450v3.dtb \
>> imx6q-b650v3.dtb \
>> imx6q-b850v3.dtb \
>> + imx6q-dms-ba16.dtb \
>> imx6q-cm-fx6.dtb \
>> imx6q-cubox-i.dtb \
>> imx6q-cubox-i-emmc-som-v15.dtb \
>
> Hi Ken
>
> I think the intention is to keep this list sorted. So dms puts it
> later, after cubox.
>
Thanks. will fix the order issue in the v2.
>> @@ -0,0 +1,154 @@
>> +/*
>> + * Copyright 2018 Advantech Corporation
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include
>> +#include "imx6q-ba16.dtsi"
>> +
>> +/ {
>> + model = "Advantech DMS-BA16";
>> + compatible = "fsl,imx6q-dms-ba16", "fsl,imx6q";
>
> This looks wrong. I would expect "advantech,imx6q-dms-ba16".
>
> Andrew
Thanks. will fix the board comptability issue in the v2.
Re: [PATCH 8/8] thermal/drivers/cpu_cooling: Add the combo cpu cooling device
On 02-02-18, 15:30, Daniel Lezcano wrote: > On 02/02/2018 11:42, Viresh Kumar wrote: > > Here is how I see the whole thing now: > > > > - Yes we need individual support for both cpufreq and cpuidle cooling > > devices, > > and no one disagrees on that I believe. > > > > - There is nothing in the thermal framework that disallows both cpufreq and > > cpuidle cooling devices to co-exist. Both would be part of the same > > thermal > > zone and so will get throttled with the same thermal sensor event. And so > > we > > will end up trying to cool down the SoC using both cpufreq and cpuidle > > technique. > > No. It does not work because we will need different state for each > cooling device and we need some logic behind. Right, but I thought the cooling-maps can help us specify different cooling states for different cooling devices for the same trip point. Maybe my understanding of that is incorrect. > > - Now I am just wondering if we really need the "combo" functionality or > > not. > > Can we fine tune the DT cpu-cooling properties (existing ones) for a > > platform, > > so that it automatically acts as a combo cooling device? I am not 100% > > sure > > its gonna fly, but just wanted to make sure its not possible to work > > around > > with and then only try the combo device thing. > > > > For example, suppose that with just cpufreq-cooling device we need to take > > the > > CPU down to 1 GHz from 2 GHz if we cross temperature 'X'. What if we can > > change > > this policy from DT and say the cpufreq-cooling device goes to 1.5 GHz and > > cpuidle-cooling device takes us to idle for 'y' us, and the effect of > > combination of these two is >= the effect of the 1 GHz for just the > > cpufreq-cooling device. > > > > Is there any possibility of this to work ? > > It does not make sense. The combo does that automatically by computing > the power equivalence more precisely. Sure, but that works by creating a virtual combo-cooling device instead of two separate cooling devices and then there are several limitation (at least right now) where it doesn't sense the real situation automagically. For example I would expect the combo to just work with cpuidle if cpufreq isn't present and as soon as cpufreq comes in, covert itself to cpufreq+cpuidle. I was just trying to present another view at solving the problem at hand, not that one is better than the other. -- viresh
Re: [PATCH 00/20] Remove references to undefined symbols and fix two potential bugs
On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote:
> Hello,
>
> This patchset fixes most references to globally undefined symbols in Kconfig
> files, as reported by the
> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> script. I will send emails in reply to the patchset for some cases where I'm
> not sure what the proper fix is.
>
> All of the fixes are independent. I just created a patchset to track them more
> easily.
>
> Summary of changes:
>
> - Commits 1 and 2 fix what looks like potential bugs: A broken (intended)
>select of PL310_ERRATA_753970 for ARM/mvebu, and a misspelled dependency on
>PPC_PSERIES in KVM/PPC.
>
> - Commits 3-5 remove leftover AVR32 stuff.
>
> - Commits 6 and 7 remove some selects of removed symbols from riscv.
>
> - Commits 8-17 remove various references to removed symbols.
>
> - Commits 18-20 fix some (harmless) malformed defaults.
>
> Ulf Magnusson (20):
> ARM: mvebu: Fix broken PL310_ERRATA_753970 selects
> KVM: PPC: Book3S PR: Fix broken select due to misspelling
> kconfig: Remove leftover references to AVR32 symbol
> misc: atmel: Remove CPU_AT32AP700X (AVR32) reference
> rtc: at32ap700x: Remove PLATFORM_AT32AP dependency
> riscv: Remove ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select
> riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select
> s390/kconfig: Remove ARCH_WANTS_PROT_NUMA_PROT_NONE select
> clk: sunxi-ng: Remove SUNXI_CCU_* selects
> lib/Kconfig: Remove leftover select of GENERIC_IO
> usb: gadget: udc: Remove USB_GADGET_DUALSPEED select
> ARM: debug: Remove ARCH_MSM dep. from UNCOMPRESS_INCLUDE
> ore: Remove PNFS_OBJLAYOUT dependency
> iio: gyro: mpu3050: Remove INPUT_MPU3050 dep. from I2C
> phy: Remove SOC_EXYNOS4212 dep. from PHY_EXYNOS4X12_USB
> auxdisplay: img-ascii-lcd: Remove MIPS_SEAD3 dep.
> media: sec: Remove PLAT_S5P dependency
> iwlwifi: fix malformed CONFIG_IWLWIFI_PCIE_RTPM default
> ARC: Fix malformed ARC_EMUL_UNALIGNED default
> x86/PCI: VMD: Fix malformed default
>
> arch/arc/Kconfig | 1 -
> arch/arm/Kconfig.debug | 2 +-
> arch/arm/mach-mvebu/Kconfig| 4 ++--
> arch/powerpc/kvm/Kconfig | 2 +-
> arch/riscv/Kconfig | 2 --
> arch/s390/Kconfig | 1 -
> drivers/auxdisplay/Kconfig | 2 +-
> drivers/clk/sunxi-ng/Kconfig | 7 ---
> drivers/cpufreq/Kconfig| 10 --
> drivers/iio/gyro/Kconfig | 1 -
> drivers/media/platform/Kconfig | 2 +-
> drivers/misc/Kconfig | 1 -
> drivers/net/wireless/intel/iwlwifi/Kconfig | 1 -
> drivers/pci/host/Kconfig | 1 -
> drivers/phy/samsung/Kconfig| 2 +-
> drivers/pwm/Kconfig| 2 +-
> drivers/rtc/Kconfig| 2 +-
> drivers/spi/Kconfig| 2 +-
> drivers/usb/gadget/udc/Kconfig | 1 -
> drivers/video/console/Kconfig | 2 +-
> fs/exofs/Kconfig.ore | 2 +-
> lib/Kconfig| 1 -
> 22 files changed, 12 insertions(+), 39 deletions(-)
>
> --
> 2.14.1
>
Another one that looks like a potential bug:
b49efd762482 ("dma-mapping: move dma_mark_clean to dma-direct.h")
selects ARCH_HAS_DMA_MARK_CLEAN for ia64 but never defines it. It's
used in include/linux/dma-direct.h:
#ifdef CONFIG_ARCH_HAS_DMA_MARK_CLEAN
void dma_mark_clean(void *addr, size_t size);
#else
static inline void dma_mark_clean(void *addr, size_t size)
{
}
#endif /* CONFIG_ARCH_HAS_DMA_MARK_CLEAN */
Cheers,
Ulf
Re: r8169 take too long to complete driver initialization
On Fri, Feb 2, 2018 at 7:49 PM, Hau wrote:
>
>> -Original Message-
>> From: Chris Chiu [mailto:c...@endlessm.com]
>> Sent: Friday, February 2, 2018 10:03 AM
>> To: Hau
>> Cc: nic_swsd ; net...@vger.kernel.org; Linux
>> Kernel ; Linux Upstreaming Team
>>
>> Subject: Re: r8169 take too long to complete driver initialization
>>
>> On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu wrote:
>> > On Mon, Jan 29, 2018 at 11:24 PM, Hau wrote:
>> >> Hi Chris,
>> >>
>> >> Could you test following patch?
>> >>
>> >> DECLARE_RTL_COND(rtl_ocp_tx_cond)
>> >> {
>> >> void __iomem *ioaddr = tp->mmio_addr;
>> >>
>> >> - return RTL_R8(IBISR0) & 0x02;
>> >> + return RTL_R8(IBISR0) & 0x20;
>> >> }
>> >>
>> >> static void rtl8168ep_stop_cmac(struct rtl8169_private *tp) {
>> >> void __iomem *ioaddr = tp->mmio_addr;
>> >>
>> >> RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
>> >> - rtl_msleep_loop_wait_low(tp, &rtl_ocp_tx_cond, 50, 2000);
>> >> + rtl_msleep_loop_wait_high(tp, &rtl_ocp_tx_cond, 50, 2000);
>> >> RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
>> >> RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01); }
>> >>
>> >> Thanks.
>> >>
>> >
>> > Yes. It completes the initialization in 70 ms. So it means the
>> > rtl_ocp_tx_cond are waiting for incorrect register bit? Can you help work
>> out a patch for this?
>> >
>> > Chris
>> >
>> >
>>
>> Gentle ping,
>> cheers.
>>
>> Chris
>>
>
> I have submitted the patch to kernel team.
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=086ca23d03c0d2f4088f472386778d293e15c5f6
>
>
Cool. Thanks for this.
Chris
> --Please consider the environment before printing this e-mail.
>
>> >>> -Original Message-
>> >>> From: Chris Chiu [mailto:c...@endlessm.com]
>> >>> Sent: Monday, January 29, 2018 6:12 PM
>> >>> To: nic_swsd ; net...@vger.kernel.org; Linux
>> >>> Kernel ; Linux Upstreaming Team
>> >>>
>> >>> Subject: Re: r8169 take too long to complete driver initialization
>> >>>
>> >>> On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu wrote:
>> >>> > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu
>> wrote:
>> >>> >> Hi,
>> >>> >> We've hit a suspend/resume issue on a Acer desktop caused by
>> >>> >> r8169 driver. The dmseg
>> >>> >>
>> https://gist.github.com/mschiu77/b741849b5070281daaead8dfee312d1a
>> >>> >> shows it's still in msleep() within a mutex lock.
>> >>> >> After looking into the code, it's caused by the
>> >>> >> rtl8168ep_stop_cmac() which is waiting 100 seconds for
>> >>> >> rtl_ocp_tx_cond. The following dmesg states that the r8169 driver
>> >>> >> is loaded.
>> >>> >>
>> >>> >> [ 20.270526] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>> >>> >>
>> >>> >> But it takes > 100 seconds to get the following messages
>> >>> >>
>> >>> >> [ 140.400223] r8169 :02:00.0 (unnamed net_device)
>> >>> >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50).
>> >>> >> [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at
>> >>> >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [
>> >>> >> 140.413297] r8169 :02:00.0 eth0: jumbo features [frames: 9200
>> >>> >> bytes, tx checksumming: ko]
>> >>> >>
>> >>> >> So any trial to suspend the machine during this period would
>> >>> >> always get device/resource busy message then abort. Is this
>> >>> >> rtl_ocp_tx_cond necessary? Because the ethernet is still working
>> >>> >> and I don't see any problem. I don't know it should be considered
>> >>> >> normal or not. Please let me know if any more information
>> >>> >> required. Thanks
>> >>> >>
>> >>> >> Chris
>> >>> >
>> >>> > gentle ping,
>> >>> >
>> >>> > cheers.
>> >>>
>> >>> Hi,
>> >>> Just found a r8168 driver which seems to be authrized by realtek
>> >>> for cross comparison. I tried applying the patch to latest 4.15
>> >>> kernel and the driver done it's initialization in faily short time. The
>> >>> patch
>> file is here
>> >>> https://gist.github.com/mschiu77/fcf406e64a1a437f46cf2be643f1057d.
>> >>>
>> >>> In mainline r8169.c, the IBISR0 register need to be polled in
>> >>> the rtl8168ep_stop_cmac().
>> >>> In the patch file, there's also the same IBISR0 polling code in
>> >>> Dash2DisableTx(), but it's been bypassed since the chipset maches
>> >>> HW_DASH_SUPPORT_TYPE_2.
>> >>> Per the rtl_chip_info[] in r8168_n.c, CFG_METHOD_23/27/28 are
>> >>> HW_DASH_SUPPORT_TYPE_2, and they happens to be the only 3 named
>> >>> RTL8168EP/8111EP in the rtl_chip_info[].
>> >>>
>> >>> To find the same matches in r8169.c, RTL_GIGA_MAC_VER_49/50/51
>> >>> seems share the same config. Can anyone clarify if the
>> >>> rtl_ocp_tx_cond() really necessary for 8168EP/8111EP?
>> >>> Or we can just ignore the condition check for
>> RTL_GIGA_MAC_VER_49/50/51?
>> >>>
>> >>> Chris
>> >>>
>> >>> --Please consider the environment before printing this e-mail.
Re: [PATCH v2 2/5] clk: mediatek: modify MT7622 audsys to adapt MFD device
On Sat, 2018-02-03 at 15:26 +0100, Matthias Brugger wrote:
>
> On 01/31/2018 08:42 AM, Ryder Lee wrote:
> > As the new MFD parent is in place, switch probing method to adapt it.
> >
> > Signed-off-by: Ryder Lee
> > ---
> > drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c
> > b/drivers/clk/mediatek/clk-mt7622-aud.c
> > index 13f752d..8c18536 100644
> > --- a/drivers/clk/mediatek/clk-mt7622-aud.c
> > +++ b/drivers/clk/mediatek/clk-mt7622-aud.c
> > @@ -142,11 +142,12 @@ static int clk_mt7622_audiosys_init(struct
> > platform_device *pdev)
> > {
> > struct clk_onecell_data *clk_data;
> > struct device_node *node = pdev->dev.of_node;
> > + struct device_node *pnode = pdev->dev.parent->of_node;
> > int r;
> >
> > clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
> >
> > - mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
> > + mtk_clk_register_gates(pnode, audio_clks, ARRAY_SIZE(audio_clks),
>
> We will need a fallback here for older device tree bindings.
>
> Regards,
> Matthias
Up to now, I didn't see both driver and bindings are used anywhere.
Should I still care about that?
Thanks.
Re: [PATCH 03/20] kconfig: Remove leftover references to AVR32 symbol
On 05-02-18, 02:21, Ulf Magnusson wrote:
> The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
> support for AVR32 architecture"). Remove the remaining references to it
> from the Kconfig files.
>
> No references remain to the removed AVR32_AT32AP_CPUFREQ symbol either,
> so remove that one too.
>
> Discovered with the
> https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
> script.
>
> Signed-off-by: Ulf Magnusson
> ---
> drivers/cpufreq/Kconfig | 10 --
> drivers/pwm/Kconfig | 2 +-
> drivers/spi/Kconfig | 2 +-
> drivers/video/console/Kconfig | 2 +-
> 4 files changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index d8addbce40bc..608af20a3494 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -239,16 +239,6 @@ if PPC32 || PPC64
> source "drivers/cpufreq/Kconfig.powerpc"
> endif
>
> -if AVR32
> -config AVR32_AT32AP_CPUFREQ
> - bool "CPU frequency driver for AT32AP"
> - depends on PLATFORM_AT32AP
> - default n
> - help
> - This enables the CPU frequency driver for AT32AP processors.
> - If in doubt, say N.
> -endif
> -
https://lkml.kernel.org/r/20180118200202.11883-1-clabbe.montj...@gmail.com
--
viresh
Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended
On 02-02-18, 13:28, Bo Yan wrote: > On 02/02/2018 11:34 AM, Saravana Kannan wrote: > >I rather have this fixed in the dpm_suspend/resume() code. This is just > >masking the first issue that's being caused by unbalanced error handling. > >If that means adding flags in dpm_suspend/resume() then that's what we > >should do right now and clean it up later if it can be improved. Making > >cpufreq more messy doesn't seem like the right answer. +1 > dpm_suspend and dpm_resume by themselves are not balanced in this particular > case. As it's currently structured, dpm_resume can't be omitted even if > dpm_suspend is skipped due to earlier failure. I think checking > cpufreq_suspended flag is a reasonable compromise. If we can find a way to > make dpm_suspend/dpm_resume also balanced, that will be best. I think cpufreq is just one of the users which broke. Others didn't break because: - They don't have a complicated resume part. - Or we just don't know that they broke. Resuming something that never suspended is just broken by design. Yeah, its much simpler in this particular case to fix cpufreq core but the suspend/resume/hibernation part is really core kernel and should be fixed to avoid such band-aids. -- viresh
Re: [PATCH 3/3] vfio: disable filesystem-dax page pinning
On Sun, Feb 4, 2018 at 7:46 PM, Haozhong Zhang wrote:
> On 02/04/18 15:05 -0800, Dan Williams wrote:
>> Filesystem-DAX is incompatible with 'longterm' page pinning. Without
>> page cache indirection a DAX mapping maps filesystem blocks directly.
>> This means that the filesystem must not modify a file's block map while
>> any page in a mapping is pinned. In order to prevent the situation of
>> userspace holding of filesystem operations indefinitely, disallow
>> 'longterm' Filesystem-DAX mappings.
>>
>> RDMA has the same conflict and the plan there is to add a 'with lease'
>> mechanism to allow the kernel to notify userspace that the mapping is
>> being torn down for block-map maintenance. Perhaps something similar can
>> be put in place for vfio.
>>
>> Note that xfs and ext4 still report:
>>
>>"DAX enabled. Warning: EXPERIMENTAL, use at your own risk"
>>
>> ...at mount time, and resolving the dax-dma-vs-truncate problem is one
>> of the last hurdles to remove that designation.
>>
>> Cc: Alex Williamson
>> Cc: Michal Hocko
>> Cc: Christoph Hellwig
>> Cc: k...@vger.kernel.org
>> Cc:
>> Reported-by: Haozhong Zhang
>> Fixes: d475c6346a38 ("dax,ext2: replace XIP read and write with DAX I/O")
>> Signed-off-by: Dan Williams
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index e30e29ae4819..45657e2b1ff7 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -338,11 +338,12 @@ static int vaddr_get_pfn(struct mm_struct *mm,
>> unsigned long vaddr,
>> {
>> struct page *page[1];
>> struct vm_area_struct *vma;
>> + struct vm_area_struct *vmas[1];
>> int ret;
>>
>> if (mm == current->mm) {
>> - ret = get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE),
>> - page);
>> + ret = get_user_pages_longterm(vaddr, 1, !!(prot & IOMMU_WRITE),
>> + page, vmas);
>
> vmas is not used subsequently if this branch is taken, so can we use
> NULL here?
I'd rather go the other way and refactor this a bit further to skip
the find_vma_intersection() below since get_user_pages() already does
that work.
linux-next: Tree for Feb 5
Hi all, Please do not add any v4.17 material to your linux-next included branches until after v4.16-rc1 has been released. Changes since 20180202: Linus' tree gained a build failure for which I applied a fix. The kvm tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 1733 2311 files changed, 63630 insertions(+), 30340 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 256 trees (counting Linus' and 44 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (35277995e179 Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Applying: pinctrl: files should directly include apis they use Merging kbuild-current/fixes (36c1681678b5 genksyms: drop *.hash.c from .gitignore) Merging arc-current/for-curr (a46f24acf8bc ARC: boot log: Fix trailing semicolon) Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index) Merging m68k-current/for-linus (2334b1ac1235 MAINTAINERS: Add NuBus subsystem entry) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (1b689a95ce74 powerpc/pseries: include linux/types.h in asm/hvcall.h) Merging sparc/master (aebb48f5e465 sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (a6b88814ab54 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging bpf/master (09c0656dfabd Merge branch 'libbpf-xdp-support') Merging ipsec/master (545d8ae7afff xfrm: fix boolean assignment in xfrm_get_type_offload) Merging netfilter/master (743efac1 net: pxa168_eth: add netconsole support) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (a9e6d44ddecc ssb: Do not disable PCI host on non-Mips) Merging mac80211/master (c4de37ee2b55 mac80211: mesh: fix wrong mesh TTL offset calculation) Merging rdma-fixes/for-rc (ae59c3f0b6cf RDMA/mlx5: Fix out-of-bound access while querying AH) Merging sound-current/for-linus (1c9609e3a8cf ALSA: hda - Reduce the suspend time consumption for ALC256) Merging pci-current/for-linus (838cda369707 x86/PCI: Enable AMD 64-bit window on resume) Merging driver-core.current/driver-core-linus (4bf772b14675 Merge tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linux) Merging tty.current/tty-linus (4bf772b14675 Merge tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linux) Merging usb.current/usb-linus (4bf772b14675 Merge tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linux) Merging usb-gadget-fixes/fixes (b2cd1df66037 Linux 4.15-rc7) Merging usb-serial-fixes/usb-linus (d14ac576d10f USB: serial: cp210x: add new device ID ELV ALC 8xxx) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node lookup) Merging phy/fixes (2b88212c4cc6 phy: rcar-gen3-usb2: select USB_COMMON) Merging staging.current/staging-linus (4bf772b14675 Merge tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linux) Merging char-misc.current/char-misc-linus (4bf772b1
Re: [PATCH 3/3] vfio: disable filesystem-dax page pinning
On 02/04/18 15:05 -0800, Dan Williams wrote:
> Filesystem-DAX is incompatible with 'longterm' page pinning. Without
> page cache indirection a DAX mapping maps filesystem blocks directly.
> This means that the filesystem must not modify a file's block map while
> any page in a mapping is pinned. In order to prevent the situation of
> userspace holding of filesystem operations indefinitely, disallow
> 'longterm' Filesystem-DAX mappings.
>
> RDMA has the same conflict and the plan there is to add a 'with lease'
> mechanism to allow the kernel to notify userspace that the mapping is
> being torn down for block-map maintenance. Perhaps something similar can
> be put in place for vfio.
>
> Note that xfs and ext4 still report:
>
>"DAX enabled. Warning: EXPERIMENTAL, use at your own risk"
>
> ...at mount time, and resolving the dax-dma-vs-truncate problem is one
> of the last hurdles to remove that designation.
>
> Cc: Alex Williamson
> Cc: Michal Hocko
> Cc: Christoph Hellwig
> Cc: k...@vger.kernel.org
> Cc:
> Reported-by: Haozhong Zhang
> Fixes: d475c6346a38 ("dax,ext2: replace XIP read and write with DAX I/O")
> Signed-off-by: Dan Williams
> ---
> drivers/vfio/vfio_iommu_type1.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index e30e29ae4819..45657e2b1ff7 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -338,11 +338,12 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
> {
> struct page *page[1];
> struct vm_area_struct *vma;
> + struct vm_area_struct *vmas[1];
> int ret;
>
> if (mm == current->mm) {
> - ret = get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE),
> - page);
> + ret = get_user_pages_longterm(vaddr, 1, !!(prot & IOMMU_WRITE),
> + page, vmas);
vmas is not used subsequently if this branch is taken, so can we use
NULL here?
Thanks,
Haozhong
> } else {
> unsigned int flags = 0;
>
> @@ -351,7 +352,18 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
>
> down_read(&mm->mmap_sem);
> ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
> - NULL, NULL);
> + vmas, NULL);
> + /*
> + * The lifetime of a vaddr_get_pfn() page pin is
> + * userspace-controlled. In the fs-dax case this could
> + * lead to indefinite stalls in filesystem operations.
> + * Disallow attempts to pin fs-dax pages via this
> + * interface.
> + */
> + if (ret > 0 && vma_is_fsdax(vmas[0])) {
> + ret = -EOPNOTSUPP;
> + put_page(page[0]);
> + }
> up_read(&mm->mmap_sem);
> }
>
>
Re: [PATCH 1/6] genalloc: track beginning of allocations
On Sun, Feb 04, 2018 at 02:34:08PM -0800, Randy Dunlap wrote: > > +/** > > + * cleart_bits_ll - according to the mask, clears the bits specified by > > clear_bits_ll 'make W=1' should catch this ... yes? (hint: building with 'make C=1 W=1' finds all kinds of interesting issues in your code. W=12 or W=123 finds too many false positives for my tastes)
[PATCH 2/2] staging: android: ion: Return void instead of int
Now, nobody care about the return value of ion_page_pool_add, therefore
we can just make it return void.
Signed-off-by: Yisheng Xie
---
drivers/staging/android/ion/ion_page_pool.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_page_pool.c
b/drivers/staging/android/ion/ion_page_pool.c
index 150626f..e3a6e32 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -26,7 +26,7 @@ static void ion_page_pool_free_pages(struct ion_page_pool
*pool,
__free_pages(page, pool->order);
}
-static int ion_page_pool_add(struct ion_page_pool *pool, struct page *page)
+static void ion_page_pool_add(struct ion_page_pool *pool, struct page *page)
{
mutex_lock(&pool->mutex);
if (PageHighMem(page)) {
@@ -37,7 +37,6 @@ static int ion_page_pool_add(struct ion_page_pool *pool,
struct page *page)
pool->low_count++;
}
mutex_unlock(&pool->mutex);
- return 0;
}
static struct page *ion_page_pool_remove(struct ion_page_pool *pool, bool high)
--
1.7.12.4
[PATCH 1/2] staging: android: ion: Remove dead code in ion_page_pool_free
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Signed-off-by: Yisheng Xie
---
drivers/staging/android/ion/ion_page_pool.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion/ion_page_pool.c
b/drivers/staging/android/ion/ion_page_pool.c
index 4452e28..150626f 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -79,13 +79,9 @@ struct page *ion_page_pool_alloc(struct ion_page_pool *pool)
void ion_page_pool_free(struct ion_page_pool *pool, struct page *page)
{
- int ret;
-
BUG_ON(pool->order != compound_order(page));
- ret = ion_page_pool_add(pool, page);
- if (ret)
- ion_page_pool_free_pages(pool, page);
+ ion_page_pool_add(pool, page);
}
static int ion_page_pool_total(struct ion_page_pool *pool, bool high)
--
1.7.12.4
[PATCH] sched/rt: Make update_curr_rt() more accurate
rq->clock_task may be updated between the two calls of
rq_clock_task() in update_curr_rt(). Calling rq_clock_task() only
once makes it more accurate and efficient, taking update_curr() as
reference.
Signed-off-by: Wen Yang
Reviewed-by: Jiang Biao
---
kernel/sched/rt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 4056c19..d6d2a65 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -950,12 +950,13 @@ static void update_curr_rt(struct rq *rq)
{
struct task_struct *curr = rq->curr;
struct sched_rt_entity *rt_se = &curr->rt;
+ u64 now = rq_clock_task(rq);
u64 delta_exec;
if (curr->sched_class != &rt_sched_class)
return;
- delta_exec = rq_clock_task(rq) - curr->se.exec_start;
+ delta_exec = now - curr->se.exec_start;
if (unlikely((s64)delta_exec <= 0))
return;
@@ -968,7 +969,7 @@ static void update_curr_rt(struct rq *rq)
curr->se.sum_exec_runtime += delta_exec;
account_group_exec_runtime(curr, delta_exec);
- curr->se.exec_start = rq_clock_task(rq);
+ curr->se.exec_start = now;
cgroup_account_cputime(curr, delta_exec);
sched_rt_avg_update(rq, delta_exec);
--
1.9.1
Re: [PATCH 6/6] scsi: qedf: use correct strncpy() size
Hi Arnd,
I love your patch! Perhaps something to improve:
[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.15]
[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/Arnd-Bergmann/scsi-fixes-for-building-with-LTO/20180205-083607
base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 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=xtensa
All warnings (new ones prefixed by >>):
drivers/scsi//qedf/qedf_dbg.c: In function 'qedf_uevent_emit':
>> drivers/scsi//qedf/qedf_dbg.c:163:4: warning: ignoring return value of
>> 'strscpy', declared with attribute warn_unused_result [-Wunused-result]
strscpy(event_string, msg, sizeof(event_string));
^~~~
vim +/strscpy +163 drivers/scsi//qedf/qedf_dbg.c
152
153 void
154 qedf_uevent_emit(struct Scsi_Host *shost, u32 code, char *msg)
155 {
156 char event_string[40];
157 char *envp[] = {event_string, NULL};
158
159 memset(event_string, 0, sizeof(event_string));
160 switch (code) {
161 case QEDF_UEVENT_CODE_GRCDUMP:
162 if (msg)
> 163 strscpy(event_string, msg,
> sizeof(event_string));
164 else
165 sprintf(event_string, "GRCDUMP=%u",
shost->host_no);
166 break;
167 default:
168 /* do nothing */
169 break;
170 }
171
172 kobject_uevent_env(&shost->shost_gendev.kobj, KOBJ_CHANGE,
envp);
173 }
174
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/2] f2fs: enable to gc page whose inode already atomic commit
Is it necessary to add a lock here? What's the problem of this patch (no
lock at all)? Anyway, the problem is expected to be fixed asap, since
attackers can easily write an app with only atomic start and no atomic
commit, which will cause f2fs run into loop gc if the disk layout is
much fragmented, since f2fs_gc will select the same target victim all
the time (e.g. one block of target victim belongs to the opened atomic
file, and it will not be moved and do_garbage_collect will finally
return 0, and that victim is selected again next time) and goto gc_more
time and time again, which will block all the fs ops (all the fs ops
will hang up in f2fs_balance_fs).
On 2018/2/4 22:56, Chao Yu wrote:
On 2018/2/3 10:47, Yunlong Song wrote:
If inode has already started to atomic commit, then set_page_dirty will
not mix the gc pages with the inmem atomic pages, so the page can be
gced safely.
Let's avoid Ccing fs mailing list if the patch didn't change vfs common
codes.
As you know, the problem here is mixed dnode block flushing w/o writebacking
gced data block, result in making transaction unintegrated.
So how about just using dio_rwsem[WRITE] during atomic committing to exclude
GCing data block of atomic opened file?
Thanks,
Signed-off-by: Yunlong Song
---
fs/f2fs/data.c | 5 ++---
fs/f2fs/gc.c | 6 --
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7435830..edafcb6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1580,14 +1580,13 @@ bool should_update_outplace(struct inode *inode, struct
f2fs_io_info *fio)
return true;
if (S_ISDIR(inode->i_mode))
return true;
- if (f2fs_is_atomic_file(inode))
- return true;
if (fio) {
if (is_cold_data(fio->page))
return true;
if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
return true;
- }
+ } else if (f2fs_is_atomic_file(inode))
+ return true;
return false;
}
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index b9d93fd..84ab3ff 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -622,7 +622,8 @@ static void move_data_block(struct inode *inode, block_t
bidx,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
- if (f2fs_is_atomic_file(inode))
+ if (f2fs_is_atomic_file(inode) &&
+ !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
@@ -729,7 +730,8 @@ static void move_data_page(struct inode *inode, block_t
bidx, int gc_type,
if (!check_valid_map(F2FS_I_SB(inode), segno, off))
goto out;
- if (f2fs_is_atomic_file(inode))
+ if (f2fs_is_atomic_file(inode) &&
+ !f2fs_is_commit_atomic_write(inode))
goto out;
if (f2fs_is_pinned_file(inode)) {
if (gc_type == FG_GC)
.
--
Thanks,
Yunlong Song
[PATCH] media: v4l2_fh.h: add missing kconfig.h include
v4l2_fh.h uses the IS_ENABLED() macro and thus should include kconfig.h. Signed-off-by: Alexandre Courbot --- include/media/v4l2-fh.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index 62633e7d2630..ea73fef8bdc0 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -22,6 +22,7 @@ #define V4L2_FH_H #include +#include #include #include -- 2.16.0.rc1.238.g530d649a79-goog
[PATCH] [BUGFIX] media: vb2: Fix videobuf2 to map correct area
Fixes vb2_vmalloc_get_userptr() to ioremap correct area.
Since the current code does ioremap the page address, if the offset > 0,
it does not do ioremap the last page and results in kernel panic.
This fixes to pass the page address + offset to ioremap so that ioremap
can map correct area. Also, this uses __pfn_to_phys() to get the physical
address of given PFN.
Signed-off-by: Masami Hiramatsu
Reported-by: Takao Orito
---
drivers/media/v4l2-core/videobuf2-vmalloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 3a7c80cd1a17..896f2f378b40 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -106,7 +106,7 @@ static void *vb2_vmalloc_get_userptr(struct device *dev,
unsigned long vaddr,
if (nums[i-1] + 1 != nums[i])
goto fail_map;
buf->vaddr = (__force void *)
- ioremap_nocache(nums[0] << PAGE_SHIFT, size);
+ ioremap_nocache(__pfn_to_phys(nums[0]) + offset, size);
} else {
buf->vaddr = vm_map_ram(frame_vector_pages(vec), n_pages, -1,
PAGE_KERNEL);
Re: [PATCH 1/6] nvme-pci: move clearing host mem behind stopping queues
Hi Keith Thanks for your kindly response and directive. On 02/03/2018 02:46 AM, Keith Busch wrote: > This one makes sense, though I would alter the change log to something > like: > > This patch quiecses new IO prior to disabling device HMB access. > A controller using HMB may be relying on it to efficiently complete > IO commands Yes, I will change it next version. Sincerely Jianchao
Re: [PATCH 2/6] nvme-pci: fix the freeze and quiesce for shutdown and reset case
Hi Keith
Thanks for your kindly response.
On 02/03/2018 02:24 AM, Keith Busch wrote:
> On Fri, Feb 02, 2018 at 03:00:45PM +0800, Jianchao Wang wrote:
>> Currently, request queue will be frozen and quiesced for both reset
>> and shutdown case. This will trigger ioq requests in RECONNECTING
>> state which should be avoided to prepare for following patch.
>> Just freeze request queue for shutdown case and drain all the resudual
>> entered requests after controller has been shutdown.
> Freezing is not just for shutdown. It's also used so
> blk_mq_update_nr_hw_queues will work if the queue count changes across
> resets.
blk_mq_update_nr_hw_queues will freeze the queue itself. Please refer to.
static void __blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set,
int nr_hw_queues)
{
struct request_queue *q;
lockdep_assert_held(&set->tag_list_lock);
if (nr_hw_queues > nr_cpu_ids)
nr_hw_queues = nr_cpu_ids;
if (nr_hw_queues < 1 || nr_hw_queues == set->nr_hw_queues)
return;
list_for_each_entry(q, &set->tag_list, tag_set_list)
blk_mq_freeze_queue(q);
set->nr_hw_queues = nr_hw_queues;
blk_mq_update_queue_map(set);
list_for_each_entry(q, &set->tag_list, tag_set_list) {
blk_mq_realloc_hw_ctxs(set, q);
blk_mq_queue_reinit(q);
}
list_for_each_entry(q, &set->tag_list, tag_set_list)
blk_mq_unfreeze_queue(q);
}
Thanks
Jianchao
[PATCH] v4l: vidioc-prepare-buf.rst: fix link to VIDIOC_QBUF
The description for VIDIOC_PREPARE_BUF results in the following sentence: "...before actually enqueuing it, using the ioctl VIDIOC_QBUF, VIDIOC_DQBUF ioctl...". The intent is to only refer to VIDIOC_QBUF though, so fix this. Signed-off-by: Alexandre Courbot --- Documentation/media/uapi/v4l/vidioc-prepare-buf.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst index 70687a86ae38..49f9f4c181de 100644 --- a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst +++ b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst @@ -34,7 +34,7 @@ Description Applications can optionally call the :ref:`VIDIOC_PREPARE_BUF` ioctl to pass ownership of the buffer to the driver before actually enqueuing it, -using the :ref:`VIDIOC_QBUF` ioctl, and to prepare it for future I/O. Such +using the :ref:`VIDIOC_QBUF ` ioctl, and to prepare it for future I/O. Such preparations may include cache invalidation or cleaning. Performing them in advance saves time during the actual I/O. In case such cache operations are not required, the application can use one of -- 2.16.0.rc1.238.g530d649a79-goog
[PATCH] media: media-types.rst: fix typo
with -> which Signed-off-by: Alexandre Courbot --- Documentation/media/uapi/mediactl/media-types.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/media/uapi/mediactl/media-types.rst b/Documentation/media/uapi/mediactl/media-types.rst index 8d64b0c06ebc..932823e3cca8 100644 --- a/Documentation/media/uapi/mediactl/media-types.rst +++ b/Documentation/media/uapi/mediactl/media-types.rst @@ -26,7 +26,7 @@ Types and flags used to represent the media graph elements ``MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN`` - Unknown entity. That generally indicates that a driver didn't - initialize properly the entity, with is a Kernel bug + initialize properly the entity, which is a Kernel bug - .. row 2 -- 2.16.0.rc1.238.g530d649a79-goog
Re: [PATCH 4/6] nvme-pci: break up nvme_timeout and nvme_dev_disable
Hi Keith Thanks for you kindly response and comment. That's really appreciated. On 02/03/2018 02:31 AM, Keith Busch wrote: > On Fri, Feb 02, 2018 at 03:00:47PM +0800, Jianchao Wang wrote: >> Currently, the complicated relationship between nvme_dev_disable >> and nvme_timeout has become a devil that will introduce many >> circular pattern which may trigger deadlock or IO hang. Let's >> enumerate the tangles between them: >> - nvme_timeout has to invoke nvme_dev_disable to stop the >>controller doing DMA access before free the request. >> - nvme_dev_disable has to depend on nvme_timeout to complete >>adminq requests to set HMB or delete sq/cq when the controller >>has no response. >> - nvme_dev_disable will race with nvme_timeout when cancels the >>outstanding requests. > > Your patch is releasing a command back to the OS with the > PCI controller bus master still enabled. This could lead to data or > memory corruption. > There are two cases nvme_timeout will return. BLK_EH_HANDLED BLK_EH_NOT_HANDLED For the 1st case, the patch will disable the controller. Then the controller will stop processing any outstanding command and delete the sq/cq queues as the protocol. Looks like it is still not enough, I will to disable the _pci_in nvme_pci_disable_dev_directly next version. Really thanks for your directive here. For the 2nd case, it will return BLK_EH_NOT_HANDLED. blk_mq_rq_timed_out will do nothing for this case. All the command will be handled after all the things are disabled. > In any case, it's not as complicated as you're making it out to > be. It'd be easier to just enforce the exisiting rule that commands > issued in the disabling path not depend on completions or timeout > handling. All of commands issued in this path already do this except > for HMB disabling. Let'sjust fix that command, right? > We will still met nvme_timeout will invoke nvme_dev_disable and cannot synchronize on the outstanding requests. This is really a devil and will be a block to do other improvements. This patch just do two things: 1. grab all the previous outstanding requests with blk_abort_request. Then release them after the controller is totally disabled/shutdown. consequently, during the disable/shutdown and initializing procedure, nvme_timeout path only need to serve them. And this also could ensure there will be _no_ any outstanding requests after nvme_dev_disable. 2. fail the adminq command issued during disable/shutdown and initializing procedure when the controller no response. we need to do two steps for this, disable the controller/pci and complete the command. Then nvme_timeout will not need to invoke nvme_dev_disable and nvme_dev_disable will be independent. Please consider this. Many thanks Jianchao
