Hi Dan,
On Thu, Sep 17, 2020 at 01:49:41PM +0300, Dan Carpenter wrote:
> On Thu, Sep 17, 2020 at 01:33:43PM +0300, Sakari Ailus wrote:
> > > +static int connect_supported_devices(void)
> > > +{
> > > + struct acpi_device *adev;
> > > + struct device *dev;
> > > + struct sensor_bios_data ssdb;
> >
allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20200917
i386 randconfig
From: Ivan Safonov
[ Upstream commit 628cbd971a927abe6388d44320e351c337b331e4 ]
skb clones use same data buffer,
so tail of one skb is corrupted by beginning of next skb.
Signed-off-by: Ivan Safonov
Link: https://lore.kernel.org/r/20200423191404.12028-1-insafo...@gmail.com
Signed-off-by: Greg
From: Dan Carpenter
[ Upstream commit ef0ed05dcef8a74178a8b480cce23a377b1de2b8 ]
There was supposed to be a "ret = " assignment here, otherwise the
error handling on the next line won't work.
Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface")
Signed-off-by: Dan Carpenter
From: Ivan Safonov
[ Upstream commit 628cbd971a927abe6388d44320e351c337b331e4 ]
skb clones use same data buffer,
so tail of one skb is corrupted by beginning of next skb.
Signed-off-by: Ivan Safonov
Link: https://lore.kernel.org/r/20200423191404.12028-1-insafo...@gmail.com
Signed-off-by: Greg
From: Dan Carpenter
[ Upstream commit ef0ed05dcef8a74178a8b480cce23a377b1de2b8 ]
There was supposed to be a "ret = " assignment here, otherwise the
error handling on the next line won't work.
Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface")
Signed-off-by: Dan Carpenter
From: Ivan Safonov
[ Upstream commit 628cbd971a927abe6388d44320e351c337b331e4 ]
skb clones use same data buffer,
so tail of one skb is corrupted by beginning of next skb.
Signed-off-by: Ivan Safonov
Link: https://lore.kernel.org/r/20200423191404.12028-1-insafo...@gmail.com
Signed-off-by: Greg
From: Dan Carpenter
[ Upstream commit ef0ed05dcef8a74178a8b480cce23a377b1de2b8 ]
There was supposed to be a "ret = " assignment here, otherwise the
error handling on the next line won't work.
Fixes: 64b5a49df486 ("[media] media: imx: Add Capture Device Interface")
Signed-off-by: Dan Carpenter
Le jeudi 17 septembre 2020 à 20:27 -0400, Nicolas Dufresne a écrit :
> As per spec, the CAPTURE resolution should be automatically set based on
> the OTUPUT resolution. This patch properly propagate width/height to the
> capture when the OUTPUT format is set and override the user provided
> width/h
As per spec, the CAPTURE resolution should be automatically set based on
the OTUPUT resolution. This patch properly propagate width/height to the
capture when the OUTPUT format is set and override the user provided
width/height with configured OUTPUT resolution when the CAPTURE fmt is
updated.
Thi
Buenos días
Soy Alex Pons, director de FOESCO (Formación Estatal Continua).
Llegadas estas fechas y como cada año, recordamos a todas las empresas
Españolas su derecho a consumir el Crédito de Formación del que disponen para
la formación de sus empleados, antes de su caducidad a final de año.
HELLO,
My name is Mrs. Jane from America, I read about you from a reliable web site
and i will love to employ you into humanitarian work in your country, I'm ready
to donate some money for you to carry out the work in your country. Please
reply with your private email address so that i will
On 17/09/2020 15:14, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 4:53 PM Dan Scally wrote:
>> Hi Andy, thanks for input (as always)
> You're welcome! I'm really impressed by your activity in this area.
Thanks - it's pretty fun so far
>>> Ah, I think you misinterpreted the meaning of above. Th
allnoconfig
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig
Le jeudi 17 septembre 2020 à 12:39 +0200, Hans Verkuil a écrit :
> On 14/05/2020 17:39, Nicolas Dufresne wrote:
> > As per spec, the CAPTURE resolution should be automatically set based on
> > the OTUPUT resolution. This patch properly propagate width/height to the
> > capture when the OUTPUT forma
On Thu, Sep 17, 2020 at 10:33:39AM +0200, Hans Verkuil wrote:
> Hi Maxime,
>
> On 27/08/2020 17:19, Maxime Ripard wrote:
> > On Tue, Aug 25, 2020 at 07:35:18PM +0200, Jernej Skrabec wrote:
> >> Allwinner R40 SoC contains video engine very similar to that in A33.
> >>
> >> First two patches add sys
On Thu, Sep 17, 2020 at 02:36:22PM +0100, Dan Scally wrote:
> On 17/09/2020 13:45, Andy Shevchenko wrote:
> > On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote:
> >> On 17/09/2020 11:33, Sakari Ailus wrote:
> > I will do better review for next version, assuming you will Cc reviewers and
>
On Thu, Sep 17, 2020 at 5:19 PM Kieran Bingham
wrote:
> On 17/09/2020 15:08, Andy Shevchenko wrote:
...
> Ayee, ok so we have 'half' the driver for IPU3 out of staging.
Correct. And your below analysis is correct.
> From my understanding, the IPU3 consists of two components, the CIO2
> (CSI2 c
Hi Andy,
On 17/09/2020 15:08, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 4:31 PM Kieran Bingham
> wrote:
>> On 17/09/2020 10:47, Dan Scally wrote:
>>> On 17/09/2020 08:53, Greg KH wrote:
On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>
> drivers/staging/media/ipu3
On Thu, Sep 17, 2020 at 4:53 PM Dan Scally wrote:
>
> Hi Andy, thanks for input (as always)
You're welcome! I'm really impressed by your activity in this area.
> On 17/09/2020 13:45, Andy Shevchenko wrote:
> > On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote:
> >> On 17/09/2020 11:33,
On Thu, Sep 17, 2020 at 4:31 PM Kieran Bingham
wrote:
> On 17/09/2020 10:47, Dan Scally wrote:
> > On 17/09/2020 08:53, Greg KH wrote:
> >> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
> >>> drivers/staging/media/ipu3/Kconfig | 15 +
> >>> drivers/staging/media/ipu3/Make
Hi Andy, thanks for input (as always)
On 17/09/2020 13:45, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote:
>> On 17/09/2020 11:33, Sakari Ailus wrote:
> I will do better review for next version, assuming you will Cc reviewers and
> TWIMC people. Below is like s
Hi Dan, Greg,
On 17/09/2020 10:47, Dan Scally wrote:
> Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
> I'm new to both C and kernel work)
>
> On 17/09/2020 08:53, Greg KH wrote:
>> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>>> MAINTAINERS
On Thu, Sep 17, 2020 at 03:25:29PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 01:49:41PM +0300, Dan Carpenter wrote:
> > On Thu, Sep 17, 2020 at 01:33:43PM +0300, Sakari Ailus wrote:
>
> > > > + int i, ret;
> > >
> > > unsigned int i
> > >
> >
> > Why?
> >
> > For list itera
On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote:
> On 17/09/2020 11:33, Sakari Ailus wrote:
I will do better review for next version, assuming you will Cc reviewers and
TWIMC people. Below is like small part of comments I may give to the code.
...
> > The ones I know require PMIC cont
On Thu, Sep 17, 2020 at 01:49:41PM +0300, Dan Carpenter wrote:
> On Thu, Sep 17, 2020 at 01:33:43PM +0300, Sakari Ailus wrote:
> > > + int i, ret;
> >
> > unsigned int i
> >
>
> Why?
>
> For list iterators then "int i;" is best... For sizes then unsigned is
> sometimes best. Or if it's part
Hey Sakari - thanks for the reply
On 17/09/2020 11:33, Sakari Ailus wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> Is this all that it takes to add support for some machines shipped with
> Windows?
Almost
> The ones I know require PMIC control done in software (not even
> sensors are accessi
On Thu, Sep 17, 2020 at 01:33:43PM +0300, Sakari Ailus wrote:
> > +static int connect_supported_devices(void)
> > +{
> > + struct acpi_device *adev;
> > + struct device *dev;
> > + struct sensor_bios_data ssdb;
> > + struct sensor *sensor;
> > + struct property_entry *sensor_props;
> > +
Hi Greg,
This series add the phy layer needed for the USB stack to work
on Hikey 970.
The main difference against v3 is that I'm sending this one via
staging.
In order for this phy to actually work properly, we still need to
apply one quirk patch at dwc3, which fixes some issues with
USB HID dr
Address the issues reported by checkpatch --strict,
and add a SPDX tag.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 157 ++---
1 file changed, 76 insertions(+), 81 deletions(-)
diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.c
b/d
While this driver is not used yet, use a more consistent namespace,
similar to the PHY layer for Kirin 960 (hi3660).
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/phy-hi3670-usb3.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/hikey
From: Yu Chen
There are some problems at the initialization part of this phy.
Solve them.
Signed-off-by: Yu Chen
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 70 ++
1 file changed, 32 insertions(+), 38 deletions(-)
diff --git a/dri
From: Yu Chen
Add the Hisilicon Kirin 3670 USB phy driver.
This driver was imported from Linaro's official Hikey 970
tree, from the original patch, removing the addition of
the dwg3-specific parts, and getting the missing SoB from
its original author:
https://github.com/96boards-hikey/
Add the needed bits in order to build the Kirin 970 PHY
driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/Kconfig | 11 +++
drivers/staging/hikey9xx/Makefile | 2 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/stagi
Use the new YAML for this physical layer.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/phy-hi3670-usb3.txt | 25 ---
drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 72 +++
2 files changed, 72 insertions(+), 25 deletions(-)
delete mode 100644 drivers/st
Rename hikey970 to hi3670, in order to use a namespace
similar to hi3660 driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 98 +++---
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/hikey9xx/phy-hi3670-us
Do some changes at the DT properties in order to make it
follow the phy-hi3660-usb3 example and to simplify
usb3-phy-tx-vboost-lvl name.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --gi
On 14/05/2020 17:39, Nicolas Dufresne wrote:
> As per spec, the CAPTURE resolution should be automatically set based on
> the OTUPUT resolution. This patch properly propagate width/height to the
> capture when the OUTPUT format is set and override the user provided
> width/height with configured OU
On Thu, 2020-09-17 at 12:34 +0300, Dan Carpenter wrote:
> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
> > diff --git a/drivers/staging/media/ipu3/cio2-bridge.c
> > b/drivers/staging/media/ipu3/cio2-bridge.c
[]
> > + if (!dev->driver_data) {
> > + pr_i
Hi Daniel,
Thank you for the patch.
Is this all that it takes to add support for some machines shipped with
Windows? The ones I know require PMIC control done in software (not even
sensors are accessible without that).
One possibility would be to put this to platform code. That would
effectively
On 17/09/2020 11:15, Dan Carpenter wrote:
> On Thu, Sep 17, 2020 at 10:47:50AM +0100, Dan Scally wrote:
>> Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
>> I'm new to both C and kernel work)
> It's pretty impressive work if you're new to C...
Thanks (and for your other re
On Thu, Sep 17, 2020 at 10:47:50AM +0100, Dan Scally wrote:
> Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
> I'm new to both C and kernel work)
It's pretty impressive work if you're new to C...
> >
> >> + return;
> > No error value?
> The prototype for
Hi all,
The following series add support for the Slimport ANX7625 transmitter, a
ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device.
This is the v16 version, any mistakes, please let me know, I will fix it in
the next series.
Change history:
v16: Fix compile error
-
Hi Greg - thanks for the comments, appreciate it (sorry there's so many,
I'm new to both C and kernel work)
On 17/09/2020 08:53, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
>> MAINTAINERS | 6 +
>> drivers/media/pci/intel/ipu3/ipu
On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> index 92f5eadf2c99..fd941d2c7581 100644
> --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> +++ b/drivers/media/pci/intel/ipu3/ipu3-c
On Thu, 2020-09-17 at 09:13 +0200, Michael Straube wrote:
> Use __func__ instead of hardcoded function names to clear
> checkpatch warnings.
[]
> diff --git a/drivers/staging/rtl8188eu/hal/odm.c
> b/drivers/staging/rtl8188eu/hal/odm.c
[]
> @@ -249,7 +249,7 @@ void odm_CommonInfoSelfUpdate(struct o
anx7625: MIPI to DP transmitter DT schema
Signed-off-by: Xin Ji
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/analogix,anx7625.yaml | 95 ++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.ya
Hi Maxime,
On 27/08/2020 17:19, Maxime Ripard wrote:
> On Tue, Aug 25, 2020 at 07:35:18PM +0200, Jernej Skrabec wrote:
>> Allwinner R40 SoC contains video engine very similar to that in A33.
>>
>> First two patches add system controller nodes and the rest of them
>> add support for Cedrus VPU.
>>
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/Kconfig |9 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analog
On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
> MAINTAINERS | 6 +
> drivers/media/pci/intel/ipu3/ipu3-cio2.c | 67 +++-
staging drivers should be self-contained, and not modify stuff outside
of drivers/staging/
> drivers/staging/media/ipu3/Kconfi
Use __func__ instead of hardcoded function names to clear
checkpatch warnings.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/hal_intf.c | 4 +-
drivers/staging/rtl8188eu/hal/odm.c | 60 +--
drivers/staging/rtl8188eu/hal/phy.c | 2 +-
Move constants to the right side of comparsions to follow kernel
coding style and clear checkpatch warnings. In case of comparsion
to _FAIL we can use '!' since _FAIL is defined as '0'.
WARNING: Comparisons should place the constant on the right side of the test
Signed-off-by: Michael Straube
--
52 matches
Mail list logo
