On 03/01/2018 05:56 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) produced these warning:
>
> In file included from drivers/misc/cardreader/rts5209.c:24:0:
> include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined
>
On 03/01/2018 05:56 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) produced these warning:
>
> In file included from drivers/misc/cardreader/rts5209.c:24:0:
> include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined
>
On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote:
> Hi Everyone,
So Oliver (CC) was having issues getting any of that to work for us.
The problem is that acccording to him (I didn't double check the latest
patches) you effectively hotplug the PCIe memory into the system when
creating
On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote:
> Hi Everyone,
So Oliver (CC) was having issues getting any of that to work for us.
The problem is that acccording to him (I didn't double check the latest
patches) you effectively hotplug the PCIe memory into the system when
creating
On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote:
> > Hi Everyone,
>
>
> So Oliver (CC) was having issues getting any of that to work for us.
>
> The problem is that acccording to him (I didn't double check the latest
>
On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote:
> > Hi Everyone,
>
>
> So Oliver (CC) was having issues getting any of that to work for us.
>
> The problem is that acccording to him (I didn't double check the latest
>
From: ShuFan Lee
Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export
tcpci_irq.
More operations can be extended in tcpci_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the
From: ShuFan Lee
Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export
tcpci_irq.
More operations can be extended in tcpci_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the TCPM
writes to the
Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.
The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the
Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.
The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the
* Kevin Hilman [180301 03:08]:
> Tony Lindgren writes:
> > We are currently probing smartreflex with omap_device while we are
> > already probing smartreflex related interconnect target module with
> > ti-sysc driver and dts data.
...
> Acked-by: Kevin
* Kevin Hilman [180301 03:08]:
> Tony Lindgren writes:
> > We are currently probing smartreflex with omap_device while we are
> > already probing smartreflex related interconnect target module with
> > ti-sysc driver and dts data.
...
> Acked-by: Kevin Hilman
>
> I don't have anything else
On Wed, 2018-02-28 at 15:49 +0800, Zhiyong Tao wrote:
> On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote:
> > On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> > > For generic pins, parameter "arg" is 0 or 1.
> > > For special pins, bias-disable is set by R0R1,
> > > so we need transmited
On Wed, 2018-02-28 at 15:49 +0800, Zhiyong Tao wrote:
> On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote:
> > On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> > > For generic pins, parameter "arg" is 0 or 1.
> > > For special pins, bias-disable is set by R0R1,
> > > so we need transmited
From: ShuFanLee
Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export
tcpci_irq.
More operations can be extended in tcpci_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the
From: ShuFanLee
Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export
tcpci_irq.
More operations can be extended in tcpci_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the TCPM
writes to the
* kbuild test robot [180219 07:47]:
> > 354if (reset_gpio >= 0)
>355gpiod_set_value_cansleep(reset_gpio, 1);
Thanks this test can be just dropped. Will send out an updated
version shortly.
Regards,
Tony
* kbuild test robot [180219 07:47]:
> > 354if (reset_gpio >= 0)
>355gpiod_set_value_cansleep(reset_gpio, 1);
Thanks this test can be just dropped. Will send out an updated
version shortly.
Regards,
Tony
* Rob Herring [180219 20:41]:
> On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote:
> > The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
>
> MDM660 a typo?
Thanks fixing.
> > +Required properties:
> > +- compatible Must be
* Rob Herring [180219 20:41]:
> On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote:
> > The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
>
> MDM660 a typo?
Thanks fixing.
> > +Required properties:
> > +- compatible Must be "motorola,mapphone-mdm6600"
> >
Hi all,
Changes since 20180228:
The net-next tree gained a conflict against the net tree and also a build
failure due to an interaction with the net tree for which I applied a
merge fix patch.
Non-merge commits (relative to Linus' tree): 4348
4891 files changed, 184087 insertions(+), 124487
Hi all,
Changes since 20180228:
The net-next tree gained a conflict against the net tree and also a build
failure due to an interaction with the net tree for which I applied a
merge fix patch.
Non-merge commits (relative to Linus' tree): 4348
4891 files changed, 184087 insertions(+), 124487
Hi guys,
if i'm reading the code right, the PM clk means:
1/ the clocks which would be enabled while power on
2/ these clocks are optional, it's ok if anything wrong with them
3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier)
and currently we're adding all clocks of
Hi guys,
if i'm reading the code right, the PM clk means:
1/ the clocks which would be enabled while power on
2/ these clocks are optional, it's ok if anything wrong with them
3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier)
and currently we're adding all clocks of
From: Bjorn Helgaas
Date: Wed, 28 Feb 2018 17:08:29 -0600
> On Mon, Feb 19, 2018 at 10:30:25AM -0500, David Miller wrote:
>> From: David Woodhouse
>> Date: Mon, 19 Feb 2018 15:24:18 +
>>
>> >> For one, the sparc specific code allows mmap'ing any
From: Bjorn Helgaas
Date: Wed, 28 Feb 2018 17:08:29 -0600
> On Mon, Feb 19, 2018 at 10:30:25AM -0500, David Miller wrote:
>> From: David Woodhouse
>> Date: Mon, 19 Feb 2018 15:24:18 +
>>
>> >> For one, the sparc specific code allows mmap'ing any address range
>> >> within a PCI bus device.
If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This
will put the CPU in the correct state to resume from the failure.
Signed-off-by: Derek Basehore
---
kernel/cpu_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/cpu_pm.c
If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This
will put the CPU in the correct state to resume from the failure.
Signed-off-by: Derek Basehore
---
kernel/cpu_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c
index
From: Sean Wang
Just add binding for a fixed-factor clock axisel_d4, which would be
referenced by PWM devices on MT7623 or MT2701 SoC.
Cc: sta...@vger.kernel.org
Fixes: 1de9b21633d6 ("clk: mediatek: Add dt-bindings for MT2701 clocks")
Signed-off-by: Sean Wang
From: Sean Wang
The clock for which all PWM devices on MT7623 or MT2701 actually depending
on has to be divided by four from its parent clock axi_sel in the clock
path prior to PWM devices.
Consequently, adding a fixed-factor clock axisel_d4 as one-fourth of
clock
From: Sean Wang
Just add binding for a fixed-factor clock axisel_d4, which would be
referenced by PWM devices on MT7623 or MT2701 SoC.
Cc: sta...@vger.kernel.org
Fixes: 1de9b21633d6 ("clk: mediatek: Add dt-bindings for MT2701 clocks")
Signed-off-by: Sean Wang
Cc: Rob Herring
Cc: Mark Rutland
From: Sean Wang
The clock for which all PWM devices on MT7623 or MT2701 actually depending
on has to be divided by four from its parent clock axi_sel in the clock
path prior to PWM devices.
Consequently, adding a fixed-factor clock axisel_d4 as one-fourth of
clock axi_sel allows that PWM
XDP_REDIRECT support for mergeable buffer was removed since commit
7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable()
case"). This is because we don't reserve enough tailroom for struct
skb_shared_info which breaks XDP assumption. Other complaints are, the
complex linearize
XDP_REDIRECT support for mergeable buffer was removed since commit
7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable()
case"). This is because we don't reserve enough tailroom for struct
skb_shared_info which breaks XDP assumption. Other complaints are, the
complex linearize
Hi:
This series tries to re-enable XDP_REDIRECT for mergeable buffer which
was removed since commit 7324f5399b06 ("virtio_net: disable
XDP_REDIRECT in receive_mergeable() case"). Main concerns are:
- not enough tailroom was reserved which breaks cpumap
- complex logic like EWMA and linearizing
We used to do data copy through xdp_linearize_page() for the buffer
without sufficient headroom, it brings extra complexity without
helping for the performance. So this patch remove it and switch to use
generic XDP routine to handle this case.
Signed-off-by: Jason Wang
---
Hi:
This series tries to re-enable XDP_REDIRECT for mergeable buffer which
was removed since commit 7324f5399b06 ("virtio_net: disable
XDP_REDIRECT in receive_mergeable() case"). Main concerns are:
- not enough tailroom was reserved which breaks cpumap
- complex logic like EWMA and linearizing
We used to do data copy through xdp_linearize_page() for the buffer
without sufficient headroom, it brings extra complexity without
helping for the performance. So this patch remove it and switch to use
generic XDP routine to handle this case.
Signed-off-by: Jason Wang
---
Hi Robin,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 97ace515f01439d4cf6e898b4094040dc12d36e7
commit: e1a50de37860b3a93a9d643b09638db5aff47650 arm64: cputype: Silence Sparse
warnings
date: 12 days ago
Hi Robin,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 97ace515f01439d4cf6e898b4094040dc12d36e7
commit: e1a50de37860b3a93a9d643b09638db5aff47650 arm64: cputype: Silence Sparse
warnings
date: 12 days ago
On Wed, Feb 28, 2018 at 08:38:00PM +0800, Dave Young wrote:
> On 02/26/18 at 07:01pm, AKASHI Takahiro wrote:
> > On Fri, Feb 23, 2018 at 05:24:59PM +0800, Dave Young wrote:
> > > Hi AKASHI,
> > >
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > As arch_kexec_kernel_*_{probe,load}(),
On Wed, Feb 28, 2018 at 08:38:00PM +0800, Dave Young wrote:
> On 02/26/18 at 07:01pm, AKASHI Takahiro wrote:
> > On Fri, Feb 23, 2018 at 05:24:59PM +0800, Dave Young wrote:
> > > Hi AKASHI,
> > >
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > As arch_kexec_kernel_*_{probe,load}(),
On 02/28/2018 02:55 PM, Bjorn Helgaas wrote:
On Tue, Feb 27, 2018 at 05:19:52PM -0600, Gustavo A. R. Silva wrote:
It seems that the expression threshold_us * 1000 will never exceed the
32-bit limits [1]. So changing the type of threshold_ns from u64 to u32
seems sensible [2].
[1]
On 02/28/2018 02:55 PM, Bjorn Helgaas wrote:
On Tue, Feb 27, 2018 at 05:19:52PM -0600, Gustavo A. R. Silva wrote:
It seems that the expression threshold_us * 1000 will never exceed the
32-bit limits [1]. So changing the type of threshold_ns from u64 to u32
seems sensible [2].
[1]
From: Andi Kleen
Newer glibc did some include namespace "cleanups" and removed
struct ucontext and friends. This already broke a lot of software,
and UML seems to be the latest victim.
Use the typedefs which are still available. They also work on
older glibcs.
From: Andi Kleen
Newer glibc did some include namespace "cleanups" and removed
struct ucontext and friends. This already broke a lot of software,
and UML seems to be the latest victim.
Use the typedefs which are still available. They also work on
older glibcs.
Signed-off-by: Andi Kleen
---
Tony Lindgren writes:
> We are currently probing smartreflex with omap_device while we are
> already probing smartreflex related interconnect target module with
> ti-sysc driver and dts data.
>
> Before we can flip things on for ti-sysc, we need to prepare the
> smartreflex
Tony Lindgren writes:
> We are currently probing smartreflex with omap_device while we are
> already probing smartreflex related interconnect target module with
> ti-sysc driver and dts data.
>
> Before we can flip things on for ti-sysc, we need to prepare the
> smartreflex driver a bit:
>
> 1.
On Wed, Feb 28, 2018 at 08:33:59PM +0800, Dave Young wrote:
> On 02/26/18 at 07:24pm, AKASHI Takahiro wrote:
> > On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote:
> > > Hi AKASHI,
> > >
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > On arm64, no trampline code between old
On Wed, Feb 28, 2018 at 08:33:59PM +0800, Dave Young wrote:
> On 02/26/18 at 07:24pm, AKASHI Takahiro wrote:
> > On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote:
> > > Hi AKASHI,
> > >
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > On arm64, no trampline code between old
On 2018/3/1 10:50, Jaegeuk Kim wrote:
> On 02/28, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2018/2/28 13:48, Jaegeuk Kim wrote:
>>> Hi Yunlong,
>>>
>>> As Eric pointed out, how do you think using nohighmem for directory likewise
>>
>> I'd like to ask, at the beginning, why we choose to use highmem
On 2018/3/1 10:50, Jaegeuk Kim wrote:
> On 02/28, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2018/2/28 13:48, Jaegeuk Kim wrote:
>>> Hi Yunlong,
>>>
>>> As Eric pointed out, how do you think using nohighmem for directory likewise
>>
>> I'd like to ask, at the beginning, why we choose to use highmem
Mathieu Malaterre writes:
> When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the
> array feature_properties is defined as an empty array, which in turn
> triggers the following warning (treated as error on W=1):
>
> CC arch/powerpc/kernel/prom.o
>
Mathieu Malaterre writes:
> When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the
> array feature_properties is defined as an empty array, which in turn
> triggers the following warning (treated as error on W=1):
>
> CC arch/powerpc/kernel/prom.o
>
On 02/28, Chao Yu wrote:
> On 2018/2/28 13:09, Jaegeuk Kim wrote:
> > Change log from v1:
> > - add doc :)
> >
> > This patch adds an mount option, "alloc_mode=%s" having two options,
> > "default"
> > and "reuse".
> >
> > In "alloc_mode=reuse" case, f2fs starts to allocate segments from 0'th
On 02/28, Chao Yu wrote:
> On 2018/2/28 13:09, Jaegeuk Kim wrote:
> > Change log from v1:
> > - add doc :)
> >
> > This patch adds an mount option, "alloc_mode=%s" having two options,
> > "default"
> > and "reuse".
> >
> > In "alloc_mode=reuse" case, f2fs starts to allocate segments from 0'th
IRQ parameters for SoC devices connected directly to I/O APIC lines
(without PCI IRQ routing) may be specified in the Device Tree.
Called from DT IRQ parser, irq_create_fwspec_mapping() calls
irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.
But x86-specific DT IRQ allocation
IRQ parameters for SoC devices connected directly to I/O APIC lines
(without PCI IRQ routing) may be specified in the Device Tree.
Called from DT IRQ parser, irq_create_fwspec_mapping() calls
irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.
But x86-specific DT IRQ allocation
Fixing x86-specific DT implementation in the kernel allows reusing most of
firmware code for SoC that have ARM core replaced with x86, e.g. SC9853i.
Changes since first version:
* Splitting a single patch into three parts
Ivan Gorinov (3):
x86: devicetree: call early_init_dt_verify()
x86:
Fixing x86-specific DT implementation in the kernel allows reusing most of
firmware code for SoC that have ARM core replaced with x86, e.g. SC9853i.
Changes since first version:
* Splitting a single patch into three parts
Ivan Gorinov (3):
x86: devicetree: call early_init_dt_verify()
x86:
Call to early_init_dt_verify() is required to prepare DTB data.
It was called from arch/arm and arch/powerpc, but not arch/x86.
Signed-off-by: Ivan Gorinov
---
arch/x86/kernel/devicetree.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/devicetree.c
Adding code to register processors described in Device Tree.
APIC ID is specified in 'intel-apic_id' propery as used in U-Boot.
First address specified in 'reg' is used as default APIC ID.
Signed-off-by: Ivan Gorinov
---
arch/x86/kernel/devicetree.c | 26
Call to early_init_dt_verify() is required to prepare DTB data.
It was called from arch/arm and arch/powerpc, but not arch/x86.
Signed-off-by: Ivan Gorinov
---
arch/x86/kernel/devicetree.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/devicetree.c
Adding code to register processors described in Device Tree.
APIC ID is specified in 'intel-apic_id' propery as used in U-Boot.
First address specified in 'reg' is used as default APIC ID.
Signed-off-by: Ivan Gorinov
---
arch/x86/kernel/devicetree.c | 26 --
1 file
On 02/28, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2018/2/28 13:48, Jaegeuk Kim wrote:
> > Hi Yunlong,
> >
> > As Eric pointed out, how do you think using nohighmem for directory likewise
>
> I'd like to ask, at the beginning, why we choose to use highmem for dentry
> page?
> any history reason
Hi Jaegeuk,
On 2018/3/1 10:45, Jaegeuk Kim wrote:
> On 02/28, Chao Yu wrote:
>> From: Chao Yu
>>
>> If we fail in ->remount_fs, it needs to restore old whint_mode as other
>> mount options.
>>
>> Fixes: e25afe01822f ("f2fs: support passing down write hints given by users
>>
On 02/28, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2018/2/28 13:48, Jaegeuk Kim wrote:
> > Hi Yunlong,
> >
> > As Eric pointed out, how do you think using nohighmem for directory likewise
>
> I'd like to ask, at the beginning, why we choose to use highmem for dentry
> page?
> any history reason
Hi Jaegeuk,
On 2018/3/1 10:45, Jaegeuk Kim wrote:
> On 02/28, Chao Yu wrote:
>> From: Chao Yu
>>
>> If we fail in ->remount_fs, it needs to restore old whint_mode as other
>> mount options.
>>
>> Fixes: e25afe01822f ("f2fs: support passing down write hints given by users
>> to block layer")
>
Simplify code and use devm_add_action() to handle cleanup.
Signed-off-by: Peng Hao
---
drivers/hwmon/g762.c | 43 +--
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
index
Simplify code and use devm_add_action() to handle cleanup.
Signed-off-by: Peng Hao
---
drivers/hwmon/g762.c | 43 +--
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
index 6d1208b..49046b4 100644
Hi,
On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote:
> On 2/27/2018 11:19 PM, AKASHI Takahiro wrote:
> >Tyler,
> >
> ># I missed catching your patch as its subject doesn't contain arm64.
> >
> >On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote:
> >>Currently on arm64 ESRT
Hi,
On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote:
> On 2/27/2018 11:19 PM, AKASHI Takahiro wrote:
> >Tyler,
> >
> ># I missed catching your patch as its subject doesn't contain arm64.
> >
> >On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote:
> >>Currently on arm64 ESRT
This patch adds new option '-E' to accept user configured hot file
extension, in order to let kernel module handle hot/cold file's datas
separately better.
Signed-off-by: Chao Yu
---
v3:
- remove debug log.
include/f2fs_fs.h | 5 ++--
mkfs/f2fs_format.c | 74
This patch adds new option '-E' to accept user configured hot file
extension, in order to let kernel module handle hot/cold file's datas
separately better.
Signed-off-by: Chao Yu
---
v3:
- remove debug log.
include/f2fs_fs.h | 5 ++--
mkfs/f2fs_format.c | 74
Thomas Gleixner wrote:
Woody,
On Wed, 28 Feb 2018, Woody Suwalski wrote:
Certainly. I understand you want dmesg output for kernels build with and
without PAE, not just PAE=n on the cmdline :-)
Here it is...
Thanks for providing the data. It did not pinpoint the issue but at least
it gave me
Thomas Gleixner wrote:
Woody,
On Wed, 28 Feb 2018, Woody Suwalski wrote:
Certainly. I understand you want dmesg output for kernels build with and
without PAE, not just PAE=n on the cmdline :-)
Here it is...
Thanks for providing the data. It did not pinpoint the issue but at least
it gave me
On 02/28, Chao Yu wrote:
> From: Chao Yu
>
> If we fail in ->remount_fs, it needs to restore old whint_mode as other
> mount options.
>
> Fixes: e25afe01822f ("f2fs: support passing down write hints given by users
> to block layer")
Hi Chao,
It was not merged, so please
On 02/28, Chao Yu wrote:
> From: Chao Yu
>
> If we fail in ->remount_fs, it needs to restore old whint_mode as other
> mount options.
>
> Fixes: e25afe01822f ("f2fs: support passing down write hints given by users
> to block layer")
Hi Chao,
It was not merged, so please allow me to integrate
Change log from v1:
- relax more to issue discard commands
This patch avoids to skip discard commands when user sets gc_urgent mode.
Reviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.c | 11 +--
1 file changed, 5 insertions(+),
Change log from v1:
- relax more to issue discard commands
This patch avoids to skip discard commands when user sets gc_urgent mode.
Reviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
lay/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20180228.orig/drivers/auxdisplay/Kconfig
+++ linux-next-20180228/drivers/auxdisplay/Kconfig
@@ -166,7 +166,7 @@ config ARM_CHARLCD
endif # AUXDISPLAY
-config PANEL
+menuconfig PANEL
tristate
nko <andriy.shevche...@linux.intel.com>
Cc: Miguel Ojeda Sandonis <miguel.ojeda.sando...@gmail.com>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
drivers/auxdisplay/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-next-20180228.ori
Signed-off-by: Randy Dunlap
Cc: Miguel Ojeda Sandonis
Acked-by: Geert Uytterhoeven
Reviewed-by: Andy Shevchenko
---
drivers/auxdisplay/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20180228.orig/drivers/auxdisplay/Kconfig
+++ linux-next-20180228/drivers/auxdispl
unlap
---
drivers/auxdisplay/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-next-20180228.orig/drivers/auxdisplay/Kconfig
+++ linux-next-20180228/drivers/auxdisplay/Kconfig
@@ -14,9 +14,6 @@ menuconfig AUXDISPLAY
If you say N, all options i
On Thu, Mar 01, 2018 at 12:38:16AM +, Luis R. Rodriguez wrote:
> On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote:
> > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be forced to gain
> > > an
> > >
On Thu, Mar 01, 2018 at 12:38:16AM +, Luis R. Rodriguez wrote:
> On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote:
> > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be forced to gain
> > > an
> > >
On Wed, Feb 28, 2018 at 11:02 PM, Enric Balletbo i Serra
wrote:
> Enables typec phyter and extcon driver for cable detection that is used by
> USB 3.0 controller for Rockchip rk3399 SoCs.
>
> Signed-off-by: Enric Balletbo i Serra
On Wed, Feb 28, 2018 at 11:02 PM, Enric Balletbo i Serra
wrote:
> Enables typec phyter and extcon driver for cable detection that is used by
> USB 3.0 controller for Rockchip rk3399 SoCs.
>
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Alexandre Courbot
Thanks! This fixes a USB
On 02/28/2018 09:05 PM, Stefano Stabellini wrote:
We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.
Make status and flags explicitly
On 02/28/2018 09:05 PM, Stefano Stabellini wrote:
We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.
Make status and flags explicitly
On Wed, Feb 28, 2018 at 05:12:52AM +0800, Steven Rostedt wrote:
> On Tue, 27 Feb 2018 18:04:26 +0800
> Alan Kao wrote:
>
> > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2]
>
> Note, doing it at that stage takes the longest time. It makes small
On Wed, Feb 28, 2018 at 05:12:52AM +0800, Steven Rostedt wrote:
> On Tue, 27 Feb 2018 18:04:26 +0800
> Alan Kao wrote:
>
> > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2]
>
> Note, doing it at that stage takes the longest time. It makes small
> changes much longer
We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.
Make status and flags explicitly 64-bit aligned.
Signed-off-by: Stefano Stabellini
We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.
Make status and flags explicitly 64-bit aligned.
Signed-off-by: Stefano Stabellini
---
Hi Bart
Thanks for your precious time to review this and kindly detailed response.
On 03/01/2018 01:52 AM, Bart Van Assche wrote:
> On Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index a86df9c..6fa7b0c 100644
>> ---
Hi Bart
Thanks for your precious time to review this and kindly detailed response.
On 03/01/2018 01:52 AM, Bart Van Assche wrote:
> On Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index a86df9c..6fa7b0c 100644
>> ---
On 2018/2/12 2:45, Marc Zyngier wrote:
Hi, Marc
Sorry for replying so late.
On Sun, 11 Feb 2018 03:42:01 +,
Yang Yingliang wrote:
Hi Yang,
In direct case, rd_idx will wrap if other cpus post commands
that make rd_idx increase. When rd_idx wrapped, the driver prints
timeout messages but
On 2018/2/12 2:45, Marc Zyngier wrote:
Hi, Marc
Sorry for replying so late.
On Sun, 11 Feb 2018 03:42:01 +,
Yang Yingliang wrote:
Hi Yang,
In direct case, rd_idx will wrap if other cpus post commands
that make rd_idx increase. When rd_idx wrapped, the driver prints
timeout messages but
On Wed, Feb 28, 2018 at 03:13:54PM -0500, Alan Stern wrote:
> This patch reorganizes the definition of rb in the Linux Kernel Memory
> Consistency Model. The relation is now expressed in terms of
> rcu-fence, which consists of a sequence of gp and rscs links separated
> by rcu-link links, in
On Wed, Feb 28, 2018 at 03:13:54PM -0500, Alan Stern wrote:
> This patch reorganizes the definition of rb in the Linux Kernel Memory
> Consistency Model. The relation is now expressed in terms of
> rcu-fence, which consists of a sequence of gp and rscs links separated
> by rcu-link links, in
201 - 300 of 2974 matches
Mail list logo