RTC alarm2 is connected to pmic_en line and hence can be used to control
the pmic enabling/disabling. Hence add the system-power-controller for rtc
node.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/am4372.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
RTC alarm2 is connected to pmic_en line and hence can be used to control
the pmic enabling/disabling. Hence add the system-power-controller for rtc
node.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/am4372.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
wl1271_warning() already appends a \n to the format,
so adding one to the warning string gives empty lines in the log.
Signed-off-by: H. Nikolaus Schaller
---
drivers/net/wireless/ti/wlcore/main.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
wl1271_warning() already appends a \n to the format,
so adding one to the warning string gives empty lines in the log.
Signed-off-by: H. Nikolaus Schaller
---
drivers/net/wireless/ti/wlcore/main.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Hello,
On Wed, 25 Jul 2018, Tan Hu wrote:
> We came across infinite loop in ipvs when using ipvs in docker
> env.
>
> When ipvs receives new packets and cannot find an ipvs connection,
> it will create a new connection, then if the dest is unavailable
> (i.e. IP_VS_DEST_F_AVAILABLE),
Hello,
On Wed, 25 Jul 2018, Tan Hu wrote:
> We came across infinite loop in ipvs when using ipvs in docker
> env.
>
> When ipvs receives new packets and cannot find an ipvs connection,
> it will create a new connection, then if the dest is unavailable
> (i.e. IP_VS_DEST_F_AVAILABLE),
On 07/24/2018 09:53 PM, Jeremy Cline wrote:
> Adjust tcp_client.py and tcp_server.py to work with Python 3 by using
> the print function, marking string literals as bytes, and using the
> newer exception syntax. This should be functionally equivalent and
> supports Python 3+.
>
> Signed-off-by:
On 07/24/2018 09:53 PM, Jeremy Cline wrote:
> Adjust tcp_client.py and tcp_server.py to work with Python 3 by using
> the print function, marking string literals as bytes, and using the
> newer exception syntax. This should be functionally equivalent and
> supports Python 3+.
>
> Signed-off-by:
This patch adds the dmam_async_device_register for DMA code.
Use the Devres to call the release for the DMA engine driver.
Signed-off-by: Huang Shijie
---
Documentation/driver-model/devres.txt | 1 +
drivers/dma/dmaengine.c | 35 +++
This patch adds the dmam_async_device_register for DMA code.
Use the Devres to call the release for the DMA engine driver.
Signed-off-by: Huang Shijie
---
Documentation/driver-model/devres.txt | 1 +
drivers/dma/dmaengine.c | 35 +++
Use of_device_is_system_power_controller instead of manually reading
the system-power-controller property from the device tree node.
Reviewed-by: Johan Hovold
Signed-off-by: Keerthy
---
Changes in v5:
* Added Johan's Reviewed-by
drivers/rtc/rtc-omap.c | 3 +--
1 file changed, 1
Use of_device_is_system_power_controller instead of manually reading
the system-power-controller property from the device tree node.
Reviewed-by: Johan Hovold
Signed-off-by: Keerthy
---
Changes in v5:
* Added Johan's Reviewed-by
drivers/rtc/rtc-omap.c | 3 +--
1 file changed, 1
Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
over try again.
Signed-off-by: Keerthy
---
Changes in v5:
* Added an additional check to see if ALARM2 status is not set
before retrying.
* Cleaned up comments
* Also reduced mdelay to 1S lesser as per this commit
On 07/24/2018 03:33 PM, Brian Brooks wrote:
> Signed-off-by: Brian Brooks
Please respin with proper commit message instead of empty one.
Thanks,
Daniel
Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
over try again.
Signed-off-by: Keerthy
---
Changes in v5:
* Added an additional check to see if ALARM2 status is not set
before retrying.
* Cleaned up comments
* Also reduced mdelay to 1S lesser as per this commit
On 07/24/2018 03:33 PM, Brian Brooks wrote:
> Signed-off-by: Brian Brooks
Please respin with proper commit message instead of empty one.
Thanks,
Daniel
On 07/24/2018 04:55 AM, YueHaibing wrote:
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
>
On 07/24/2018 04:55 AM, YueHaibing wrote:
> Fix inconsistent IS_ERR and PTR_ERR in get_btf,
> the proper pointer to be passed as argument is '*btf'
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
>
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add dummy buffer for RDMA memory mode
>
> When display power on, the drm frame work would modeset and
> set up the display HW.
>
> In this time, the RDMA would start wroking and read the data from memory.
> But, user
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add dummy buffer for RDMA memory mode
>
> When display power on, the drm frame work would modeset and
> set up the display HW.
>
> In this time, the RDMA would start wroking and read the data from memory.
> But, user
This patch adds the binding documentation for the HS/SS USB PHY found
inside Qualcom Dakota SoCs.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: John Crispin
---
.../bindings/phy/phy-qcom-ipq4019-usb.txt | 21 +
1 file changed, 21 insertions(+)
This patch adds the binding documentation for the HS/SS USB PHY found
inside Qualcom Dakota SoCs.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: John Crispin
---
.../bindings/phy/phy-qcom-ipq4019-usb.txt | 21 +
1 file changed, 21 insertions(+)
This patch makes USB work on the Dakota EVB.
Signed-off-by: John Crispin
---
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 20 +++
arch/arm/boot/dts/qcom-ipq4019.dtsi | 76 +++
2 files changed, 96 insertions(+)
diff --git
This patch makes USB work on the Dakota EVB.
Signed-off-by: John Crispin
---
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 20 +++
arch/arm/boot/dts/qcom-ipq4019.dtsi | 76 +++
2 files changed, 96 insertions(+)
diff --git
Add a driver to setup the USB phy on Qualcom Dakota SoCs.
The driver sets up HS and SS phys. In case of HS some magic values need to
be written to magic offsets. These were taken from the SDK driver.
Signed-off-by: John Crispin
---
drivers/phy/qualcomm/Kconfig| 7 +
Add a driver to setup the USB phy on Qualcom Dakota SoCs.
The driver sets up HS and SS phys. In case of HS some magic values need to
be written to magic offsets. These were taken from the SDK driver.
Signed-off-by: John Crispin
---
drivers/phy/qualcomm/Kconfig| 7 +
On Tue, 2018-07-24 at 11:57 -0700, Casey Schaufler wrote:
> On 7/24/2018 9:00 AM, David Howells wrote:
> > Casey Schaufler wrote:
> >
> > > > (1) Mount topology and reconfiguration change events.
> > >
> > > With the possibility of unprivileged mounting you're going to have to
> > > address
On Tue, 2018-07-24 at 11:57 -0700, Casey Schaufler wrote:
> On 7/24/2018 9:00 AM, David Howells wrote:
> > Casey Schaufler wrote:
> >
> > > > (1) Mount topology and reconfiguration change events.
> > >
> > > With the possibility of unprivileged mounting you're going to have to
> > > address
On 07/24/2018 05:10 PM, Thomas Richter wrote:
> commit a5b8bd47dcc57 ("bpf tools: Collect eBPF programs from their own
> sections")
>
> cause a compiler error when building the perf tool in the linux-next tree.
> I compile it using a FEDORA 28 installation, my gcc compiler version:
> gcc (GCC)
On 07/24/2018 05:10 PM, Thomas Richter wrote:
> commit a5b8bd47dcc57 ("bpf tools: Collect eBPF programs from their own
> sections")
>
> cause a compiler error when building the perf tool in the linux-next tree.
> I compile it using a FEDORA 28 installation, my gcc compiler version:
> gcc (GCC)
This patch adds registration of the system memory with memblock, eliminates
bootmem initialization and converts early memory reservations from bootmem
to memblock.
Signed-off-by: Mike Rapoport
---
v2: fix calculation of the reserved memory size
arch/hexagon/Kconfig | 3 +++
This patch adds registration of the system memory with memblock, eliminates
bootmem initialization and converts early memory reservations from bootmem
to memblock.
Signed-off-by: Mike Rapoport
---
v2: fix calculation of the reserved memory size
arch/hexagon/Kconfig | 3 +++
On Tue, Jul 24, 2018 at 09:12:55PM -0500, Richard Kuo wrote:
> On Tue, Jul 24, 2018 at 08:47:04AM +0300, Mike Rapoport wrote:
> > On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
> > >
> > > On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > > > This patch adds
Please do not comment out unneeded code. Remove.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/bridge/synopsys/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 5dad97d..3e1b1e3 100644
On Tue, Jul 24, 2018 at 09:12:55PM -0500, Richard Kuo wrote:
> On Tue, Jul 24, 2018 at 08:47:04AM +0300, Mike Rapoport wrote:
> > On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
> > >
> > > On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > > > This patch adds
Please do not comment out unneeded code. Remove.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/bridge/synopsys/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 5dad97d..3e1b1e3 100644
On Tue, Jul 24, 2018 at 10:23:27AM +0200, Benjamin Tissoires wrote:
> On Tue, Jul 24, 2018 at 12:34 AM Dmitry Torokhov
> wrote:
> >
> > On Fri, Jul 20, 2018 at 10:51:21PM +0100, Nick Dyer wrote:
> > > From: Nick Dyer
> > >
> > > input_mt_report_slot_state() ignores the tool when the slot is
On Tue, Jul 24, 2018 at 10:23:27AM +0200, Benjamin Tissoires wrote:
> On Tue, Jul 24, 2018 at 12:34 AM Dmitry Torokhov
> wrote:
> >
> > On Fri, Jul 20, 2018 at 10:51:21PM +0100, Nick Dyer wrote:
> > > From: Nick Dyer
> > >
> > > input_mt_report_slot_state() ignores the tool when the slot is
On Tue, 24 Jul 2018, Vignesh R wrote:
> On Monday 23 July 2018 11:07 AM, Lee Jones wrote:
> > On Wed, 18 Jul 2018, Dmitry Torokhov wrote:
> >
> >> On Wed, Jul 18, 2018 at 08:47:36AM +0100, Lee Jones wrote:
> >>> On Tue, 17 Jul 2018, Vignesh R wrote:
> >>>
> Hi Dmitry,
>
> On
On Tue, 24 Jul 2018, Vignesh R wrote:
> On Monday 23 July 2018 11:07 AM, Lee Jones wrote:
> > On Wed, 18 Jul 2018, Dmitry Torokhov wrote:
> >
> >> On Wed, Jul 18, 2018 at 08:47:36AM +0100, Lee Jones wrote:
> >>> On Tue, 17 Jul 2018, Vignesh R wrote:
> >>>
> Hi Dmitry,
>
> On
On Tue, 24 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation
On Tue, 24 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation
The filechk_offsets in arch/arm/mach-at91/Makefile is never
used because it is always overridden by the equivalent one in
scripts/Makefile.lib
Signed-off-by: Masahiro Yamada
---
I will queue this to my kbuild tree.
arch/arm/mach-at91/Makefile | 25 -
1 file changed,
The filechk_offsets in arch/arm/mach-at91/Makefile is never
used because it is always overridden by the equivalent one in
scripts/Makefile.lib
Signed-off-by: Masahiro Yamada
---
I will queue this to my kbuild tree.
arch/arm/mach-at91/Makefile | 25 -
1 file changed,
Currently, filechk unconditionally opens the first prerequisite and
redirects it as the stdin of a filechk_* rule. Hence, every target
using $(call filechk,...) must list something as the first prerequisite
even if it is unneeded.
'< $<' is actually unneeded in most cases. Each rule can
Currently, filechk unconditionally opens the first prerequisite and
redirects it as the stdin of a filechk_* rule. Hence, every target
using $(call filechk,...) must list something as the first prerequisite
even if it is unneeded.
'< $<' is actually unneeded in most cases. Each rule can
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch fixed the error value for add DSI1 in mutex
>
English is not my mother language, but should it be 'fix' rather than
'fixed'?
Regards,
CK
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch fixed the error value for add DSI1 in mutex
>
English is not my mother language, but should it be 'fix' rather than
'fixed'?
Regards,
CK
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Cannon Matthews
> Sent: Tuesday, July 24, 2018 9:37 PM
> Subject: Re: [PATCH v2] RFC: clear 1G pages with streaming stores on
> x86
>
> Reimplement clear_gigantic_page() to clear
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Cannon Matthews
> Sent: Tuesday, July 24, 2018 9:37 PM
> Subject: Re: [PATCH v2] RFC: clear 1G pages with streaming stores on
> x86
>
> Reimplement clear_gigantic_page() to clear
Hi Eric,
>
> On 07/13/2018 02:52 AM, Pankaj Gupta wrote:
> > This patch adds virtio-pmem Qemu device.
> >
> > This device presents memory address range information to guest
> > which is backed by file backend type. It acts like persistent
> > memory device for KVM guest. Guest can
Hi Eric,
>
> On 07/13/2018 02:52 AM, Pankaj Gupta wrote:
> > This patch adds virtio-pmem Qemu device.
> >
> > This device presents memory address range information to guest
> > which is backed by file backend type. It acts like persistent
> > memory device for KVM guest. Guest can
On Tue, Jul 24 2018, Paul E. McKenney wrote:
> On Tue, Jul 24, 2018 at 07:52:03AM +1000, NeilBrown wrote:
>> On Mon, Jul 23 2018, Paul E. McKenney wrote:
>>
>> > On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
>> >> On Sun, Jul 22 2018, Paul E. McKenney wrote:
>> >> >
>> >> > One
On Tue, Jul 24 2018, Paul E. McKenney wrote:
> On Tue, Jul 24, 2018 at 07:52:03AM +1000, NeilBrown wrote:
>> On Mon, Jul 23 2018, Paul E. McKenney wrote:
>>
>> > On Mon, Jul 23, 2018 at 09:13:43AM +1000, NeilBrown wrote:
>> >> On Sun, Jul 22 2018, Paul E. McKenney wrote:
>> >> >
>> >> > One
Coutts & Co Ltd
440 Strand, London, WC2R 0QS
Website: https://www.coutts.com
Telephone:+4420 3389 7785 & +4420 7753 1000
Fax:+44 872 110 3479
OUR REF: Coutts/UK/2018/LOANAPP
YOUR REF:LOANAPPT/Coutts/JULY/2018
TO WHOM IT MAY CONCERN
We give out both Local/International Loan starting from 2.75%*
Coutts & Co Ltd
440 Strand, London, WC2R 0QS
Website: https://www.coutts.com
Telephone:+4420 3389 7785 & +4420 7753 1000
Fax:+44 872 110 3479
OUR REF: Coutts/UK/2018/LOANAPP
YOUR REF:LOANAPPT/Coutts/JULY/2018
TO WHOM IT MAY CONCERN
We give out both Local/International Loan starting from 2.75%*
On Tue, Jul 24, 2018 at 10:29:48PM -0500, Richard Kuo wrote:
> Patch series looks good. Definitely appreciate the cleanup.
>
> I can take it through my tree, or if not:
>
> Acked-by: Richard Kuo
Please take it through your tree, thanks!
On Tue, Jul 24, 2018 at 10:29:48PM -0500, Richard Kuo wrote:
> Patch series looks good. Definitely appreciate the cleanup.
>
> I can take it through my tree, or if not:
>
> Acked-by: Richard Kuo
Please take it through your tree, thanks!
2018-07-25 2:56 GMT+09:00 Christoph Hellwig :
> Hi Masahiro,
>
> what do you think about the series below, which moves the includes
> of all the architecture independ Kconfig files to the top-level
> Kconfig instead of duplicating the includes in all architectures?
>
> Note that this only handles
2018-07-25 2:56 GMT+09:00 Christoph Hellwig :
> Hi Masahiro,
>
> what do you think about the series below, which moves the includes
> of all the architecture independ Kconfig files to the top-level
> Kconfig instead of duplicating the includes in all architectures?
>
> Note that this only handles
On 07/23/2018 07:46 AM, Anshuman Khandual wrote:
> On 07/20/2018 06:45 PM, Michael S. Tsirkin wrote:
>> On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote:
>>> Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for
>>> virito devices
>>
>> s/virito/virtio/
>
>
On 07/23/2018 07:46 AM, Anshuman Khandual wrote:
> On 07/20/2018 06:45 PM, Michael S. Tsirkin wrote:
>> On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote:
>>> Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for
>>> virito devices
>>
>> s/virito/virtio/
>
>
Arnd Bergmann writes:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann
> ---
Arnd Bergmann writes:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann
> ---
Hi Sebastian,
Thanks for the response.
"I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case."
This cannot happen. The only possible return values of this function
are -ENOENT or 0.
In the case where we return -ENOENT, we'll go
straight
Hi Sebastian,
Thanks for the response.
"I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case."
This cannot happen. The only possible return values of this function
are -ENOENT or 0.
In the case where we return -ENOENT, we'll go
straight
Tomas Bortoli wrote on Mon, Jul 23, 2018:
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 18c5271910dc..92240ccf476b 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -524,6 +525,12 @@ static int p9_check_errors(struct p9_client *c, struct
> p9_req_t *req)
> int ecode;
>
Tomas Bortoli wrote on Mon, Jul 23, 2018:
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 18c5271910dc..92240ccf476b 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -524,6 +525,12 @@ static int p9_check_errors(struct p9_client *c, struct
> p9_req_t *req)
> int ecode;
>
On (07/24/18 19:51), Matthew Wilcox wrote:
>
> Also note that this is in the allocation path; this flag isn't checked
> at free. But it is cleared on free, so someone's stomping on page->flags
> after they're freed. I suggest enabling more debugging code.
Would be lovely if Tino could bisect
On (07/24/18 19:51), Matthew Wilcox wrote:
>
> Also note that this is in the allocation path; this flag isn't checked
> at free. But it is cleared on free, so someone's stomping on page->flags
> after they're freed. I suggest enabling more debugging code.
Would be lovely if Tino could bisect
On 2018/7/25 1:39 AM, Eric Biggers wrote:
> On Wed, Jul 25, 2018 at 12:28:15AM +0800, Coly Li wrote:
>> On 2018/7/24 12:44 PM, Eric Biggers wrote:
>>> On Thu, Jul 19, 2018 at 12:55:45AM +0800, Coly Li wrote:
This patch adds a kernel module to test the consistency of multiple crc
On 2018/7/25 1:39 AM, Eric Biggers wrote:
> On Wed, Jul 25, 2018 at 12:28:15AM +0800, Coly Li wrote:
>> On 2018/7/24 12:44 PM, Eric Biggers wrote:
>>> On Thu, Jul 19, 2018 at 12:55:45AM +0800, Coly Li wrote:
This patch adds a kernel module to test the consistency of multiple crc
> integrator_defconfig+CONFIG_DEVTMPFS=y+CONFIG_DEVTMPFS_MOUNT=y
>
> Qemu command line is
> qemu-system-arm -M integratorcp -m 128 \
> -kernel arch/arm/boot/zImage -no-reboot \
> -initrd busybox-armv4.cpio \
> --append "rdinit=/sbin/init console=ttyAMA0,115200" \
>
> integrator_defconfig+CONFIG_DEVTMPFS=y+CONFIG_DEVTMPFS_MOUNT=y
>
> Qemu command line is
> qemu-system-arm -M integratorcp -m 128 \
> -kernel arch/arm/boot/zImage -no-reboot \
> -initrd busybox-armv4.cpio \
> --append "rdinit=/sbin/init console=ttyAMA0,115200" \
>
piaojun wrote on Wed, Jul 25, 2018:
> On 2018/7/25 11:32, Dominique Martinet wrote:
> >>p9_client_write(fid, 0, , );
> >
> > I'm not sure what to do about this but it's also possible for
> > p9_client_write to not write the full length without setting and error.
> >
> > We should
piaojun wrote on Wed, Jul 25, 2018:
> On 2018/7/25 11:32, Dominique Martinet wrote:
> >>p9_client_write(fid, 0, , );
> >
> > I'm not sure what to do about this but it's also possible for
> > p9_client_write to not write the full length without setting and error.
> >
> > We should
Enric Balletbo Serra writes:
> Hi Levin,
>
> Missatge de Heiko Stuebner del dia dt., 24 de jul.
> 2018 a les 11:29:
>>
>> Hi Levin,
>>
>> Am Samstag, 21. Juli 2018, 10:30:26 CEST schrieb d...@t-chip.com.cn:
>> > From: Levin Du
>> >
>> > ROC-RK3399-PC is the first power efficient 4GB DDR4
Enric Balletbo Serra writes:
> Hi Levin,
>
> Missatge de Heiko Stuebner del dia dt., 24 de jul.
> 2018 a les 11:29:
>>
>> Hi Levin,
>>
>> Am Samstag, 21. Juli 2018, 10:30:26 CEST schrieb d...@t-chip.com.cn:
>> > From: Levin Du
>> >
>> > ROC-RK3399-PC is the first power efficient 4GB DDR4
Hi Dominique,
On 2018/7/25 11:32, Dominique Martinet wrote:
> piaojun wrote on Wed, Jul 25, 2018:
>> In my testing, v9fs_fid_xattr_set will return successfully even if the
>> backend ext4 filesystem has no space to store xattr key-value. That will
>> cause inconsistent behavior between front end
Hi Heiko,
Heiko Stuebner writes:
> Hi Levin,
>
> Am Samstag, 21. Juli 2018, 10:30:26 CEST schrieb d...@t-chip.com.cn:
>> From: Levin Du
>>
>> ROC-RK3399-PC is the first power efficient 4GB DDR4 single board
>
> maybe "is a power efficient" instead of "the first" ;-)
>
> [...]
>
ok :)
>> diff
Hi Dominique,
On 2018/7/25 11:32, Dominique Martinet wrote:
> piaojun wrote on Wed, Jul 25, 2018:
>> In my testing, v9fs_fid_xattr_set will return successfully even if the
>> backend ext4 filesystem has no space to store xattr key-value. That will
>> cause inconsistent behavior between front end
Hi Heiko,
Heiko Stuebner writes:
> Hi Levin,
>
> Am Samstag, 21. Juli 2018, 10:30:26 CEST schrieb d...@t-chip.com.cn:
>> From: Levin Du
>>
>> ROC-RK3399-PC is the first power efficient 4GB DDR4 single board
>
> maybe "is a power efficient" instead of "the first" ;-)
>
> [...]
>
ok :)
>> diff
On 7/6/18 1:11 AM, Johannes Thumshirn wrote:
On Thu, Jul 05, 2018 at 09:09:44AM -0700, Santosh Shilimkar wrote:
OK. we will look into it if an interim fix can be made
Thanks a lot.
Intermediate fix is posted here [1]
Regards,
Santosh
[1] https://patchwork.ozlabs.org/patch/949010/
On 7/6/18 1:11 AM, Johannes Thumshirn wrote:
On Thu, Jul 05, 2018 at 09:09:44AM -0700, Santosh Shilimkar wrote:
OK. we will look into it if an interim fix can be made
Thanks a lot.
Intermediate fix is posted here [1]
Regards,
Santosh
[1] https://patchwork.ozlabs.org/patch/949010/
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before
Currently dw_hdmi_setup is only run when the dw-hdmi bridge is enabled,
with the mode set last time.
When the bridge is enabled before any mode is set (this may happen when
booting), the mode won't be set at all, some setup steps will be
skipped or fail, and the HDMI output may not work.
Re-run
Currently dw_hdmi_setup is only run when the dw-hdmi bridge is enabled,
with the mode set last time.
When the bridge is enabled before any mode is set (this may happen when
booting), the mode won't be set at all, some setup steps will be
skipped or fail, and the HDMI output may not work.
Re-run
On 24 July 2018 at 23:05, Joel Fernandes wrote:
> From: Ruchi Kandoi
>
> systrace used for tracing for Android systems has carried a patch for
> many years in the Android tree that traces when the cpufreq limits
> change. With the help of this information, systrace can know when the
> policy
On 24 July 2018 at 23:05, Joel Fernandes wrote:
> From: Ruchi Kandoi
>
> systrace used for tracing for Android systems has carried a patch for
> many years in the Android tree that traces when the cpufreq limits
> change. With the help of this information, systrace can know when the
> policy
Registration of a memory region(MR) through FRMR/fastreg(unlike FMR)
needs a connection/qp. With a proxy qp, this dependency on connection
will be removed, but that needs more infrastructure patches, which is a
work in progress.
As an intermediate fix, the get_mr returns EOPNOTSUPP when
piaojun wrote on Wed, Jul 25, 2018:
> In my testing, v9fs_fid_xattr_set will return successfully even if the
> backend ext4 filesystem has no space to store xattr key-value. That will
> cause inconsistent behavior between front end and back end. The reason is
> that lsetxattr will be triggered by
Registration of a memory region(MR) through FRMR/fastreg(unlike FMR)
needs a connection/qp. With a proxy qp, this dependency on connection
will be removed, but that needs more infrastructure patches, which is a
work in progress.
As an intermediate fix, the get_mr returns EOPNOTSUPP when
piaojun wrote on Wed, Jul 25, 2018:
> In my testing, v9fs_fid_xattr_set will return successfully even if the
> backend ext4 filesystem has no space to store xattr key-value. That will
> cause inconsistent behavior between front end and back end. The reason is
> that lsetxattr will be triggered by
On Thu, Jul 19, 2018 at 05:56:33AM -0700, Christoph Hellwig wrote:
> hexagon does all the required cache maintainance at dma map time, and none
> at unmap time. It thus has to implement sync_single_for_device to match
> the map cace for buffer reuse, but there is no point in doing another
>
On Thu, Jul 19, 2018 at 05:56:33AM -0700, Christoph Hellwig wrote:
> hexagon does all the required cache maintainance at dma map time, and none
> at unmap time. It thus has to implement sync_single_for_device to match
> the map cace for buffer reuse, but there is no point in doing another
>
On Wed, Jul 25, 2018 at 12:50:03PM +1000, Tobin C. Harding wrote:
Please drop this. I've forgotten to deal with the links from
Documentation/*.rst to Documentation/networking/netdev-FAQ.txt
Since I've already botched it can I ask for guidance here. The problem
is updating the links means
On Wed, Jul 25, 2018 at 12:50:03PM +1000, Tobin C. Harding wrote:
Please drop this. I've forgotten to deal with the links from
Documentation/*.rst to Documentation/networking/netdev-FAQ.txt
Since I've already botched it can I ask for guidance here. The problem
is updating the links means
On 24/07/2018 15:26, Wolfram Sang wrote:
Hi Phil,
So, it is not possible to read SCL status then? Hmm, currently a working
get_scl is required...
...
Well, I don't know much about this IP core and how/where it is used. I
just wonder what happens if another user comes along using an
On 24/07/2018 15:26, Wolfram Sang wrote:
Hi Phil,
So, it is not possible to read SCL status then? Hmm, currently a working
get_scl is required...
...
Well, I don't know much about this IP core and how/where it is used. I
just wonder what happens if another user comes along using an
1 - 100 of 1482 matches
Mail list logo
