On Wed, Oct 17, 2018 at 07:07:05AM +0200, Greg KH wrote:
> On Wed, Oct 17, 2018 at 03:14:04AM +, k...@linuxonhyperv.com wrote:
> > From: Dexuan Cui
> >
> > In kvp_send_key(), we do need call process_ib_ipinfo() if
> > message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
> >
> -Original Message-
> From: Greg KH
> Sent: Tuesday, October 16, 2018 10:07 PM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuznets ;
>
> -Original Message-
> From: Greg KH
> Sent: Tuesday, October 16, 2018 10:04 PM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuznets ;
>
> -Original Message-
> From: Greg KH
> Sent: Tuesday, October 16, 2018 10:05 PM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; Stephen
> Hemminger ; Michael Kelley (EOSG)
> ; vkuznets
> S
On 10/17/18 7:07 AM, Greg KH wrote:
> On Wed, Oct 17, 2018 at 03:14:04AM +, k...@linuxonhyperv.com wrote:
>> From: Dexuan Cui
>>
>> In kvp_send_key(), we do need call process_ib_ipinfo() if
>> message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
>> the userland hv_kvp_daem
On Wed, Oct 17, 2018 at 03:14:04AM +, k...@linuxonhyperv.com wrote:
> From: Dexuan Cui
>
> In kvp_send_key(), we do need call process_ib_ipinfo() if
> message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
> the userland hv_kvp_daemon needs the info of operation, adapter_id an
On Wed, Oct 17, 2018 at 03:14:06AM +, k...@linuxonhyperv.com wrote:
> From: Dexuan Cui
>
> The patch fixes:
>
> hv_kvp_daemon.c: In function 'kvp_set_ip_info':
> hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
> into a destination of size 4096
>
> Signed-off-by: De
On Wed, Oct 17, 2018 at 03:14:02AM +, k...@linuxonhyperv.com wrote:
> From: "K. Y. Srinivasan"
>
> Currently we are replicating state in struct hv_context that is unnecessary -
> this state can be retrieved from the hypervisor. Furthermore, this is a
> per-cpu
> state that is being maintaine
On Wed, Oct 17, 2018 at 03:14:05AM +, k...@linuxonhyperv.com wrote:
> From: Dexuan Cui
>
> I didn't find a real issue. Let's just make it consistent with the
> next "case REG_U64:" where %llu is used.
>
> Signed-off-by: Dexuan Cui
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Cc: Stephen H
From: "K. Y. Srinivasan"
Currently we are replicating state in struct hv_context that is unnecessary -
this state can be retrieved from the hypervisor. Furthermore, this is a per-cpu
state that is being maintained as a global state in struct hv_context.
Get rid of this state in struct hv_context.
From: Dexuan Cui
I didn't find a real issue. Let's just make it consistent with the
next "case REG_U64:" where %llu is used.
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc:
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_kvp.c | 2 +-
1 file ch
From: Dexuan Cui
The patch fixes:
hv_kvp_daemon.c: In function 'kvp_set_ip_info':
hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
into a destination of size 4096
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc:
Signed-off-
From: Dexuan Cui
In kvp_send_key(), we do need call process_ib_ipinfo() if
message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
the userland hv_kvp_daemon needs the info of operation, adapter_id and
addr_family. With the incorrect fc62c3b1977d, the host can't get the
VM's IP via
From: Haiyang Zhang
The correct module name is hv_utils. This patch corrects
the name in struct hv_driver util_drv.
Signed-off-by: Haiyang Zhang
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv_util.c b/
From: "K. Y. Srinivasan"
Miscellaneous fixes.
Dexuan Cui (3):
Drivers: hv: kvp: Fix the recent regression caused by incorrect
clean-up
Drivers: hv: kvp: Use %u to print U32
Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1
Haiyang Zhang (1):
hv_utils: update name in st
On Tue, 2018-10-16 at 20:29 -0300, Giuliano Augusto Faulin Belinassi
wrote:
> > (There is a linux-...@googlegroups.com mailing list
> > that bounces when I reply, so I removed it from the
> > cc list)
>
> Sorry. I think this may be because my HTML mode in gmail was enabled.
No, it is because that
If caller passes un-initialized field type V4L2_FIELD_ANY to CSI
sink pad, the reset CSI crop window would not be correct, because
the crop window depends on a valid input field type. To fix move
the reset of crop and compose windows to after the call to
imx_media_fill_default_mbus_fields().
Signe
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and th
IDMAC interlaced scan, a.k.a. interweave, should be enabled in the
IDMAC output channels only if the IDMAC output pad field type is
'seq-bt' or 'seq-tb', and field type at the capture interface is
'interlaced*'.
V4L2_FIELD_HAS_BOTH() macro should not be used on the input to determine
enabling inte
If the incoming sink field type is alternate, the reset crop height
and crop height bounds must be set to twice the incoming height,
because in alternate field mode, upstream will report only the
lines for a single field, and the CSI captures the whole frame.
Signed-off-by: Steve Longerbeam
Revie
Allow sequential->interlaced interweaving but with top/bottom
lines swapped to the output buffer.
This can be accomplished by adding one line length to IDMAC output
channel address, with a negative line length for the interlace offset.
This is to allow the seq-bt -> interlaced-bt transformation,
Skip writing U/V components to odd rows for YVU420 in addition to
YUV420 and NV12.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
drivers/staging/media/imx/imx-media-csi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/st
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
So fix prepare_vdi_i
If IDMAC interweaving is enabled in a write channel, the channel must
write the odd chroma rows for 4:2:0 formats. Skipping writing the odd
chroma rows produces corrupted captured 4:2:0 images when interweave
is enabled.
Reported-by: Krzysztof Hałasa
Signed-off-by: Steve Longerbeam
Reviewed-by:
Some imx platforms do not have fwnode connections to all CSI input
ports, and should not be treated as an error. This includes the
imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode
endpoint parsing will not treat a
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be double
>(There is a linux-...@googlegroups.com mailing list
>that bounces when I reply, so I removed it from the
>cc list)
Sorry. I think this may be because my HTML mode in gmail was enabled.
> I wrote that to encourage you to do more than
> what checkpatch says.
> I just moved code around and reduced
(There is a linux-...@googlegroups.com mailing list
that bounces when I reply, so I removed it from the
cc list)
On Tue, 2018-10-16 at 19:48 -0300, Giuliano Belinassi wrote:
> Hello,
> Thank you for your review :-).
> Sorry, but I am a newbie on this, and now I am confused about my next
>
On Tue, 2018-10-16 at 18:09 -0300, Giuliano Belinassi wrote:
> A number of macro calls cause a checkpatch issue:
>
> "Lines should not end with a '('"
>
> This was fixed by moving the first '(' token to the line of the first
> argument.
Please try to make the code more readable instead of
fo
A number of macro calls cause a checkpatch issue:
"Lines should not end with a '('"
This was fixed by moving the first '(' token to the line of the first
argument.
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7280a.c | 8
1 file changed, 4 insertions(+), 4 delet
On Tue, 2018-10-16 at 20:06 +0200, Slawomir Stepien wrote:
> On paź 15, 2018 18:25, Gabriel Capella wrote:
> > This patch adds 3 comments in 2 different files.
> > These comments warn to don't correct the checks of type:
> > "CHECK: spaces preferred around that '-'"
> >
> > Signed-off-by: Gabriel
On paź 15, 2018 18:25, Gabriel Capella wrote:
> This patch adds 3 comments in 2 different files.
> These comments warn to don't correct the checks of type:
> "CHECK: spaces preferred around that '-'"
>
> Signed-off-by: Gabriel Capella
> ---
> drivers/staging/iio/adc/ad7192.c | 1 +
> drivers/st
Fixes close parenthesis alignment to match open parenthesis at
iio/drivers/staging/iio/adc/ad7606.c line 379.
Signed-of-by: Marcelo Schmitt
---
drivers/staging/iio/adc/ad7606.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/
On 10/16/2018 04:46 PM, Nishad Kamdar wrote:
> Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
> instead of the deprecated old non-descriptor interface.
>
> Signed-off-by: Nishad Kamdar
Hi,
Thanks for the patch, this looks good.
One thing about the error messages though.
> +
Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
instead of the deprecated old non-descriptor interface.
Signed-off-by: Nishad Kamdar
---
drivers/staging/iio/adc/ad7816.c | 72 +---
1 file changed, 30 insertions(+), 42 deletions(-)
diff --git a/drivers/
On Tue, Oct 16, 2018 at 02:41:50PM +0300, Dan Carpenter wrote:
> When we add drivers, can we use the new subsystem prefix for the driver?
> In other words:
>
> [PATCH] staging: nrf24: Add new driver for 2.4Ghz radio transceiver
>
Sure.
> This driver seems basically OK to me. I don't think you ne
On Mon, Oct 15, 2018 at 06:25:21PM -0300, Gabriel Capella wrote:
> This patch adds 3 comments in 2 different files.
> These comments warn to don't correct the checks of type:
> "CHECK: spaces preferred around that '-'"
>
> Signed-off-by: Gabriel Capella
> ---
> drivers/staging/iio/adc/ad7192.c
From: Todd Poynor
Remove very noisy debug logs that also contain typos and incorrect
output formats.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 24 --
1 file changed, 24 deletions(-)
diff --git a/drivers/staging/gasket/gasket_page_table.c
From: Nick Ewalt
This allows for more precise dma_direction in the dma_map_page requests.
Also leaves room for adding more flags later.
Signed-off-by: Nick Ewalt
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket.h| 33
drivers/staging/gasket/gasket_ioctl.c
From: Todd Poynor
Add flags to page mapping ioctls that specify DMA directions other than
bi-directional, avoiding unnecessary cache maintenance for read-only or
write-only buffers.
Remove some spammy / unhelpful / inaccurately formatted debug logs.
Nick Ewalt (1):
staging: gasket: page_table
From: Todd Poynor
Debug logs for device-specific callback invocation aren't very useful,
remove.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging
Please make the subject be:
[PATCH] Staging: riffa: Add new RIFFA PCIe driver
On Tue, Oct 16, 2018 at 10:54:28AM +, Cheng Fei Phung wrote:
> This patch adds RIFFA PCIe linux driver for
> https://github.com/promach/riffa/tree/full_duplex/driver/linux
Line wrap the commit message at 75 charac
On Tue, 2018-10-16 at 01:17 +0200, Marcin Ciupak wrote:
> This patch adds driver for Nordic Semiconductor nRF24L01+ radio module.
[]
> diff --git a/drivers/staging/nrf24/nrf24_hal.c
> b/drivers/staging/nrf24/nrf24_hal.c
[]
> +static ssize_t nrf24_read_reg(struct spi_device *spi, u8 addr)
> +{
>
When we add drivers, can we use the new subsystem prefix for the driver?
In other words:
[PATCH] staging: nrf24: Add new driver for 2.4Ghz radio transceiver
This driver seems basically OK to me. I don't think you necessarily
need to go through staging? Have you tried sending it directly to
netd
On 2018/10/9 21:43, Gao Xiang wrote:
> Append __init to `erofs_init_inode_cache',
> `z_erofs_init_zip_subsystem' and move these
> declarations to internal.h.
>
> Signed-off-by: Gao Xiang
Reviewed-by: Chao Yu
Thanks,
___
devel mailing list
de...@linu
On Tue, Oct 16, 2018 at 10:54:28AM +, Cheng Fei Phung wrote:
> This patch adds RIFFA PCIe linux driver for
> https://github.com/promach/riffa/tree/full_duplex/driver/linux
>
> TODO:
>
> 1) this driver needs further speed optimization although it can now achieve
> defined PCIe speed grade
>
On Tue, Oct 16, 2018 at 07:41:45AM +, Cheng Fei Phung wrote:
> Patch changelog content:
>
> Add a PCIe linux driver called RIFFA to the linux staging tree. It has full
> duplex capability compared to the original RIFFA linux driver that you can
> easily find from https://github.com/KastnerRG
This patch adds driver for Nordic Semiconductor nRF24L01+ radio module.
Signed-off-by: Marcin Ciupak
---
Changes in v2:
- add terminating newlines to all logging formats
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/stagin
Patch changelog content:
Add a PCIe linux driver called RIFFA to the linux staging tree. It has full
duplex capability compared to the original RIFFA linux driver that you can
easily find from https://github.com/KastnerRG/riffa/tree/master/driver/linux
For more context, please refer to
https:/
49 matches
Mail list logo
