On Fri, 24 Mar 2017, Luck, Tony wrote:
> +Reading/writing the schemata file
> +-
> +Reading the schemata file will show the state of all resources
> +on all domains. When writing you only need to specify those values
> +which you wish to change. E.g.
> +
> +# cat sc
On Thu, Mar 30, 2017 at 9:49 PM, Dmitry Monakhov wrote:
> If some one try to attempt advance bvec beyond it's size we simply
> dump WARN_ONCE and continue to iterate beyond bvec array boundaries.
> This simply means that we endup dereferencing/corrupting random memory
> region.
>
> Code was added
On Fri, Mar 31, 2017 at 06:22:31AM +0300, Michael S. Tsirkin wrote:
> I'm not sure why does it fail after 32 on 64 bit, but as
> virtio devices aren't limited to 32 vqs it looks like we
> should go back to requesting the irq only once for all vqs.
Meh.
>
> Christoph, should I just revert for now
On 31/03/17 09:01, Thomas Gleixner wrote:
> On Thu, 30 Mar 2017, Aniruddha Banerjee wrote:
>
>> add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are
>> not configured as edge-triggered, which may be wrong for certain GIC
>> implementations such as the GIC-400
>
> The above is just useless
Commit-ID: 29f72ce3e4d18066ec75c79c857bee0618a3504b
Gitweb: http://git.kernel.org/tip/29f72ce3e4d18066ec75c79c857bee0618a3504b
Author: Yazen Ghannam
AuthorDate: Thu, 30 Mar 2017 13:17:14 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 31 Mar 2017 10:09:44 +0200
x86/mce/AMD: Give a na
On Tue, Mar 28, 2017 at 05:29:38PM +0200, Enric Balletbo i Serra wrote:
> From: Bryan Freed
>
> When the I2C Infineon part is attached to an I2C adapter that imposes
> a size limitation, large requests will fail with -EOPNOTSUPP. Retry
> them with a sane minimum size without re-issuing the 0x05 c
On 31/03/17 09:01, Thomas Gleixner wrote:
> On Thu, 30 Mar 2017, Aniruddha Banerjee wrote:
>
>> add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are
>> not configured as edge-triggered, which may be wrong for certain GIC
>> implementations such as the GIC-400
>
> The above is just useles
GPIO bits clearing on pins assigned to STMPE1600
had no effects due to missing "clear registers"
settings within stmpe1600_regs[].
STMPE1600 does not have dedicated "clear registers",
but single "set/clear registers", hence stmpe1600_regs[]
"clear registers" (STMPE_IDX_GPCR_XXX) must be set to
same
Hi Lorenzo,
On 28 March 2017 at 23:41, Lorenzo Pieralisi wrote:
> On Wed, Mar 22, 2017 at 12:31:22AM +0800, fu@linaro.org wrote:
>> From: Fu Wei
>>
>> This driver adds support for parsing SBSA Generic Watchdog timer
>> in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT,
>> an
Eric Biggers wrote:
> Ultimately this needs to be addressed in ext4 more fully, but how about for
> ->getattr() just skipping the call to ext4_get_inode_flags() and instead
> populating the generic attributes like STATX_ATTR_APPEND and
> STATX_ATTR_IMMUTABLE from the generic inode flags, rather t
On Thu, 30 Mar 2017, Andrey Ryabinin wrote:
> vfree() can be used in any atomic context now, thus there is no point
> in vfree_atomic().
> This reverts commit 8d5341a6260a ("x86/ldt: use vfree_atomic()
> to free ldt entries")
>
> Signed-off-by: Andrey Ryabinin
Reviewed-by: Thomas Gleixner
On 30/03/17 16:51, Boris Ostrovsky wrote:
> On 03/30/2017 10:18 AM, Juergen Gross wrote:
>> For kdump to work correctly it needs the physical address of
>> vmcoreinfo_note. When running as dom0 this means the virtual address
>> has to be translated to the related machine address.
>>
>> paddr_vmcore
On 30/03/17 17:05, Jan Beulich wrote:
On 30.03.17 at 16:18, wrote:
>> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct
>> *vma,
>> return -EINVAL;
>> }
>> EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>> +
>> +#ifdef CONFIG_KEXEC_CORE
>> +phys_addr_t paddr_
Linus,
please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
to get HID fixes:
- Wacom regression fixes, from Aaron Armstrong Skomra
- new device ID addition by Peter Stein
Thanks.
Aaron Armstr
On Thu, 30 Mar 2017, Aniruddha Banerjee wrote:
> add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are
> not configured as edge-triggered, which may be wrong for certain GIC
> implementations such as the GIC-400
The above is just useless blurb.
I can't figure out at all WHY a generic inte
On Thu 30-03-17 23:49:52, Joel Fernandes wrote:
> Hi Michal,
>
> On Wed, Mar 29, 2017 at 3:43 AM, Michal Hocko wrote:
> > On Wed 29-03-17 09:23:32, Vaneet Narang wrote:
> >> Hi,
> >>
> >> >> Hmm, how can you track _all_ vmalloc allocations done on behalf of the
> >> >> module? It is quite some ti
> The code is untested, I have hardware in the mail.
Cool!
> If any one is interested and has any comments I would really like to
> hear them. I am open to all suggestions (even down to trivial coding
> style issues).
I'll just repeat that the key move to get this driver out of staging is
to ge
Hi Stephen,
We've switched from my personal git tree for the Allwinner sunxi
development to a shared tree:
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
The branch to be included in linux-next will still be called
sunxi/for-next as it used to be, and it will still go through the
a
On Fri, Mar 31, 2017 at 08:09:09AM +0200, Greg KH wrote:
> On Thu, Mar 30, 2017 at 08:08:02PM +0800, Wu Hao wrote:
> > During FPGA device (e.g PCI-based) discovery, platform devices are
> > registered for different FPGA function units. But the device node path
> > isn't quite friendly to applicatio
Hi Joe + Himanshu,
Thanks for backporting this patch to apply to v4.10.y.
I haven't seen it queued to v4.9.y yet though, would you be so kind to
send out a v4.9.y backport as well to Greg-KH + stable team so it can be
picked up for earlier stable versions too..?
Thank you,
On Thu, 2017-03-30 at
On Thu, Mar 30, 2017 at 12:54:54PM -0600, Shuah Khan wrote:
> On 03/30/2017 04:00 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.8 release.
> > There are 17 patches in this series, all will be posted as a response
> > to this one. If anyone has any issu
On Thu, Mar 30, 2017 at 08:46:15PM -0700, Guenter Roeck wrote:
> On 03/30/2017 03:00 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.8 release.
> > There are 17 patches in this series, all will be posted as a response
> > to this one. If anyone has any i
rebase on top of previous changes
---
>From dfb7cab2783d2175ad8355ce65943a28e43d8700 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 29 Mar 2017 18:08:51 +0200
Subject: [PATCH] mm, memory_hotplug: remove unused cruft after memory hotplug
rework
arch_add_memory doesn't need for_device para
Hi,
Roger Quadros writes:
Roger Quadros writes:
> dra7 OTG core limits the host controller to USB2.0 (high-speed) mode
> when we're operating in dual-role.
yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no
USB3 when OTGv2 was written.
D
Hi,
On 29/03/17 13:32, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros writes:
>>> Roger Quadros writes:
dra7 OTG core limits the host controller to USB2.0 (high-speed) mode
when we're operating in dual-role.
>>>
>>> yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was n
Fixed screw ups during the initial patch split up as per Hillf
---
>From a53c465b8f8046c6e6886dc3c17945238e63ee7c Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 29 Mar 2017 15:17:48 +0200
Subject: [PATCH] mm: remove return value from init_currently_empty_zone
init_currently_empty_zone doe
Recently most nodes got labels to make them referenceable. The USB 3.0
nodes as well as the nodes for the SATA controllers were left out,
rectify the omission.
Signed-off-by: Ralph Sennhauser
---
Hi everybody
In preparation to add support for the Linksys WRT3200ACM (Rango) some
rework of the "d
Fixed screw ups during the initial patch split up as per Hillf
---
>From 8be6c5e47de66210e47710c80e72e8abd899017b Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 29 Mar 2017 15:11:30 +0200
Subject: [PATCH] mm: get rid of zone_is_initialized
There shouldn't be any reason to add initialized
Hi Arnd
On 03/30/2017 05:36 PM, Arnd Bergmann wrote:
On Thu, Mar 23, 2017 at 11:09 AM, Alexandre TORGUE
wrote:
stm32_defconfig is used for several STM32 MCU: STM32F429, STM32F469,
STM32F746 and now STM32H743. Each of MCU listed have different interrupts
number mapped on NVIC. STM32F429: 81, ST
The default value of RX detection stable time is 10us, and this
margin is too big for some critical cases which cause U3 link fail
and link to U2(probability is about 1%). So change it to 5us.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 18 ++
1 file changed
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 93 +---
1 file changed, 80 insertions(+), 13 deletions(-)
diff --git a/Documenta
Increase LFPS filter threshold to avoid some fake remote wakeup
signal which cause U3 link fail and link to U2 only at about
0.01% probability.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/phy/phy-mt65xx-usb
Seems to be quietening down, which means someone will make a liar of me for rc6.
Just one vc4, one etnvaiv, one radeon, and a few i915 GVT fixes, and
one i915 normal fixes.
Dave.
The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:
Linux 4.11-rc4 (2017-03-26 14:15:16 -
There are some variations from mt2701 to mt2712:
1. banks shared by multiple ports are put back into each port,
such as SPLLC and U2FREQ;
2. add a new bank MISC for u2port, and CHIP for u3port;
3. bank's offset in each port are also rearranged;
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy
There will be a problem if SS port is diasbled and HS port extracts
100uA from SS port, so disable extract 100uA from SS port in the case,
when disable it, PA0_RG_USB20_INTR_EN should be set, otherwise HS port
only works on LS.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 24
there is a reference clock for each port, HighSpeed port is 48M,
and SuperSpeed port is usually 26M. it is flexible to move it
into port node, then unused clock can be disabled.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |8 ++--
1 file changed, 6 insertions
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/a
each port has its own reference clock, the HighSpeed port is 48M,
and the SuperSpeed port is usually 26M, put them into port node for
flexibility, this can close clock if the port is not used.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 27 +--
1 fil
Allright, I finally found some time for reviewing some of this
after splitting the ftgmac100 patch into 54 smaller ones :)
On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote:
.../...
> +struct aspeed_i2c_bus {
> + struct i2c_adapter adap;
> + struct device
On 30/03/17 22:13, Rafael J. Wysocki wrote:
> On Thu, Mar 30, 2017 at 10:58 AM, Juri Lelli wrote:
> > Hi,
>
> Hi,
>
> > On 30/03/17 00:41, Rafael J. Wysocki wrote:
> >> On Friday, March 24, 2017 02:08:59 PM Juri Lelli wrote:
> >> > No assumption can be made upon the rate at which frequency updat
On 30/03/17 22:22, Rafael J. Wysocki wrote:
> On Thursday, March 30, 2017 08:50:11 AM Vikram Mulukutla wrote:
> >
> > > OK
> > >
> > > So there are two pieces here.
> > >
> > > One is that if we want *all* drivers to work with schedutil, we need to
> > > keep
> > > the kthread for the ones that
On Thu, 30 Mar 2017, Dmitry Safonov wrote:
> > vim +/__NR_ia32_execve +541 arch/x86/kernel/process_64.c
> >
> >535 set_thread_flag(TIF_IA32);
> >536 clear_thread_flag(TIF_X32);
> >537 if (current->mm)
> >538 current->mm->c
On Sat, Mar 18, 2017 at 2:13 AM, Sergio Prado
wrote:
>
> +static const struct of_device_id s3cmci_dt_match[] = {
> + {
> + .compatible = "samsung,s3c2410-sdi",
> + .data = (void *)0,
> + },
> + {
> + .compatible = "samsung,s3c2412-sdi",
On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
> Handlers are currently the only blocker to compile the kernel with gcc 7
> and KASAN+use-after-scope enabled:
> drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760
> bytes is larger than 2048 bytes [-Werror=frame-larger-than=
The option indicates the kernel to save branch type during sampling.
One example:
perf record -g --branch-filter any,save_type
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-record.txt | 1 +
tools/perf/util/parse-branch-options.c | 1 +
2 files changed, 2 insertions(+)
diff --git
Show branch type in callchain entry. The branch type is printed
with other LBR information (such as cycles/abort/...).
The branch types are:
JCC forward: Conditional forward jump
JCC backward: Conditional backward jump
JMP: Jump imm
IND_JMP: Jump reg/mem
CALL: Call imm
Perf already has support for disassembling the branch instruction
and using the branch type for filtering. The patch just records
the branch type in perf_branch_entry.
Before recording, the patch converts the x86 branch classification
to common branch classification.
Signed-off-by: Jin Yao
---
Show the branch type statistics at the end of perf report --stdio.
For example:
perf report --stdio
JCC forward: 34.0%
JCC backward: 3.6%
JMP: 0.0%
IND_JMP: 6.5%
CALL: 26.6%
IND_CALL: 0.0%
RET: 29.3%
FAR_BRANCH: 0.0%
Signed-off-by: Jin Yao
---
It is often useful to know the branch types while analyzing branch
data. For example, a call is very different from a conditional branch.
Currently we have to look it up in binary while the binary may later
not be available and even the binary is available but user has to take
some time. It is ver
It is often useful to know the branch types while analyzing branch
data. For example, a call is very different from a conditional branch.
Currently we have to look it up in binary while the binary may later
not be available and even the binary is available but user has to take
some time. It is ver
Dear Wolfram,
Thank you for the reply, which we talked about briefly at the
Chemnitzer LinuxTage.
Am Freitag, den 03.03.2017, 11:17 +0100 schrieb Wolfram Sang:
> > Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for
> > multiplexed main adapter in SB800) [1] caused a regression. Tim
>
On Fri 31-03-17 15:06:41, Hillf Danton wrote:
> On March 31, 2017 2:49 PM Michal Hocko wrote:
> > On Fri 31-03-17 11:49:49, Hillf Danton wrote:
> > [...]
> > > > -/* Can fail with -ENOMEM from allocating a wait table with vmalloc() or
> > > > - * alloc_bootmem_node_nopanic()/memblock_virt_alloc_no
On Fri, Mar 31, 2017 at 03:41:18AM +0800, Yuyang Du wrote:
> > >
> > > p
> > > c2 = 1024 \Sum y^n
> > > n=1
> > >
> > > infinf
> > > = 1024 ( \Sum y^n - \Sum y^n - y^0 )
> > > n=0n=p
> >
> > It looks surprisingly kinda w
On 03/31/2017 12:40 AM, Andrew Morton wrote:
>> > BUG: kernel hang in boot stage
>>
>> Thanks, I was able to reproduce and debug this.
>> Andrew, please apply the following -fix. There will be conflicts on later
>> patches, but with trivial resolution (pages -> free_pages). Thanks!
>>
>> ...
>>
>
Hi Andrew,
On Thu, Mar 30, 2017 at 3:22 PM, Andrew Morton
wrote:
> On Thu, 30 Mar 2017 13:27:16 +0300 Andrey Ryabinin
> wrote:
>
>> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem
>> as potentially sleeping") added might_sleep() to remove_vm_area() from
>> vfree(), and commi
You're calling memcpy_{to,from}_iomem on non-__iomem pointers. This
is a fundamental no-go as we keep I/O memory separate from kernel
pointers.
On March 31, 2017 2:49 PM Michal Hocko wrote:
> On Fri 31-03-17 11:49:49, Hillf Danton wrote:
> [...]
> > > -/* Can fail with -ENOMEM from allocating a wait table with vmalloc() or
> > > - * alloc_bootmem_node_nopanic()/memblock_virt_alloc_node_nopanic() */
> > > -static int __ref ensure_zone_is_i
hello
Since linux-next-20170329, my qemu virtual machine crash with:
[1.409213] Freeing unused kernel memory: 688K
[1.414790] Freeing unused kernel memory: 1920K
[1.415581] BUG: unable to handle kernel paging request at c753f000f000
[1.416808] IP: ptdump_walk_pgd_level_core+0x2
On Thu, Mar 30, 2017 at 03:02:47PM -0700, Paul Turner wrote:
> On Thu, Mar 30, 2017 at 7:14 AM, Peter Zijlstra wrote:
> > On Thu, Mar 30, 2017 at 02:16:58PM +0200, Peter Zijlstra wrote:
> >> On Thu, Mar 30, 2017 at 04:21:08AM -0700, Paul Turner wrote:
> >
> >> > > +
> >> > > + if (unlikely(p
On 31.03.2017 08:40, Tommi Rantala wrote:
The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely. Tommi, can you put strace of x86info
-mp somewhere?
That will confirm/deny whether we're at least asking the kernel to do
sane things.
Indeed the bug ha
701 - 761 of 761 matches
Mail list logo
