[PATCH 0/2]

[PATCH 0/2]

[Thinh Nguyen]

Fix reported issues where usb_request->no_interrupt is set for isoc
transfers.

* Make sure no interrupt is asserted if no_interrupt is set
* Make sure to stop reclaiming TRBs when the driver needs to stop

Just one of the fixes above may resolve the crash reported by Jeff and
Dan, but it's more proper to have both in place.


Thinh Nguyen (2):
  usb: dwc3: gadget: Stop processing more requests on IMI
  usb: dwc3: gadget: Don't set IMI for no_interrupt

 drivers/usb/dwc3/gadget.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)


base-commit: fb8f60dd1b67520e0e0d7978ef17d015690acfc1
-- 
2.28.0

[PATCH 1/2] usb: dwc3: gadget: Stop processing more requests on IMI

[Thinh Nguyen]

When servicing a transfer completion event, the dwc3 driver will reclaim
TRBs of started requests up to the request associated with the interrupt
event. Currently we don't check for interrupt due to missed isoc, and
the driver may attempt to reclaim TRBs beyond the associated event. This
causes invalid memory access when the hardware still owns the TRB. If
there's a missed isoc TRB with IMI (interrupt on missed isoc), make sure
to stop servicing further.

Note that only the last TRB of chained TRBs has its status updated with
missed isoc. So we only need to check for the status of TRB with CHN=0.

Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: stable@vger.kernel.org
Reported-by: Jeff Vanhoof <jdv1029@gmail.com>
Reported-by: Dan Vacura <w36195@motorola.com>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
---
 drivers/usb/dwc3/gadget.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index dd8ecbe61bec..5f321aa205be 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3248,6 +3248,11 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
 	if (event->status & DEPEVT_STATUS_SHORT && !chain)
 		return 1;
 
+	if ((trb->ctrl & DWC3_TRB_CTRL_ISP_IMI) &&
+	    !(trb->ctrl & DWC3_TRB_CTRL_CHN) &&
+	    DWC3_TRB_SIZE_TRBSTS(trb->size) == DWC3_TRBSTS_MISSED_ISOC)
+		return 1;
+
 	if ((trb->ctrl & DWC3_TRB_CTRL_IOC) ||
 	    (trb->ctrl & DWC3_TRB_CTRL_LST))
 		return 1;
-- 
2.28.0

[PATCH 2/2] usb: dwc3: gadget: Don't set IMI for no_interrupt

[Thinh Nguyen]

The gadget driver may have a certain expectation of how the request
completion flow should be from to its configuration. Make sure the
controller driver respect that. That is, don't set IMI (Interrupt on
Missed Isoc) when usb_request->no_interrupt is set.

Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
---
 drivers/usb/dwc3/gadget.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5f321aa205be..92fb2f14850b 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1292,8 +1292,8 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
 			trb->ctrl = DWC3_TRBCTL_ISOCHRONOUS;
 		}
 
-		/* always enable Interrupt on Missed ISOC */
-		trb->ctrl |= DWC3_TRB_CTRL_ISP_IMI;
+		if (!req->request.no_interrupt)
+			trb->ctrl |= DWC3_TRB_CTRL_ISP_IMI;
 		break;
 
 	case USB_ENDPOINT_XFER_BULK:
-- 
2.28.0

[PATCH 0/2]

[Sergey Shtylyov]

The nfs_client::cl_lease_time field (as well as the jiffies variable it's
used with) is declared as *unsigned long*, which is 32-bit type on 32-bit
arches and 64-bit type on 64-bit arches. When nfs4_set_lease_period() that
sets nfs_client::cl_lease_time is called, 32-bit nfs_fsinfo::lease_time
field is multiplied by HZ -- that might overflow before being implicitly
cast to *unsigned long*.  Actually, there's no need to multiply by HZ at
all the call sites of nfs4_set_lease_period() -- it makes more sense to do
that once, inside that function.  That way, we can avoid such overflow by
capping the lease period at e.g. 1 hour before multipying it by HZ...

The patches below are against the linux-next branch of Trond Myklebust's
linux-nfs.git repo.

Sergey Shtylyov (2):
  NFSv4: pass lease period in seconds to nfs4_set_lease_period()
  NFSv4: limit lease period in nfs4_set_lease_period()

 fs/nfs/nfs4_fs.h    |  3 +--
 fs/nfs/nfs4proc.c   |  2 +-
 fs/nfs/nfs4renewd.c | 15 ++++++++++++---
 fs/nfs/nfs4state.c  |  2 +-
 4 files changed, 15 insertions(+), 7 deletions(-)

-- 
2.52.0

Re: [PATCH 0/2]

[Sergey Shtylyov]

Argh, I forgot to finish the subject! :-/ I'll repost...

[PATCH 0/2]

[Rex Chen]

[PATCH 1/2]
Function mmc_sdio_alive() check if sd device alive by cmd7, but SPI mode
cmd7 unavailable, so replaced by check if can read CCCR register success.
[PATCH 2/2]
SPI multiple read operation doesn't need to read crc ack, so remove it.

Rex Chen (2):
  mmc: core: SPI mode remove cmd7
  mmc: mmc_spi: multiple block read remove read crc ack

 drivers/mmc/core/sdio.c    | 8 +++++++-
 drivers/mmc/host/mmc_spi.c | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.25.1

[PATCH 0/2]

[luyulin]

  This patch introduces a driver for the Eswin eic7700 SoC pinctrl
  controller, adding support for the pinctrl functionality in the Linux
  kernel. The driver provides basic functionality to manage and control
  the pinctrl signals for the eic7700 SoC.

  The driver integrates with the Linux pinctrl subsystem, enabling kernel
  code to trigger pinctrl operations on hardware and ensuring support for
  pin multiplexing and pin configuration.

  Features:

    Implements support for the Eswin eic7700 SoC pinctrl controller.
    Provides API to manage pinctrl for the eic7700 SoC.
    Integration with the Linux pinctrl subsystem for consistency and
    scalability.

  Supported chips:
    Eswin eic7700 SoC.

  Test:
    I tested this patch on the Sifive HiFive Premier P550 (which uses
    the EIC7700 SoC), including system boot, networking, EMMC, display,
    and other peripherals. The drivers for these modules all use the
    pinctrl module, so this verifies that this pinctrl driver
    patch is working properly.

luyulin (2):
  dt-bindings: pinctrl: eswin: Document for eic7700 SoC
  pinctrl: eswin: Add eic7700 pinctrl driver

 .../pinctrl/eswin,eic7700-pinctrl.yaml        | 156 ++++
 drivers/pinctrl/Kconfig                       |  11 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/pinctrl-eic7700.c             | 701 ++++++++++++++++++
 4 files changed, 869 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-eic7700.c

-- 
2.25.1

[PATCH 0/2]

[Patrice Chotard]

stm32mp: Restore STM32MP257F-EV1 boot

This series is restoring STM32MP257F-EV1 boot :
  _ Fix usart2 clock frequency
  _ Fix board_get_usable_ram_top()



Patrice Chotard (2):
  stm32mp: Fix board_get_usable_ram_top()
  ARM: dts: stm32: Update ck_flexgen_08 frequency.

 arch/arm/dts/stm32mp251.dtsi      | 2 +-
 arch/arm/mach-stm32mp/dram_init.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.25.1

Re: [PATCH 0/2]

[Patrice CHOTARD]

Don't take care of this series, i will resend it with correct cover letter title

Sorry
Patrice

On 1/9/25 11:18, Patrice Chotard wrote:
> stm32mp: Restore STM32MP257F-EV1 boot
> 
> This series is restoring STM32MP257F-EV1 boot :
>   _ Fix usart2 clock frequency
>   _ Fix board_get_usable_ram_top()
> 
> 
> 
> Patrice Chotard (2):
>   stm32mp: Fix board_get_usable_ram_top()
>   ARM: dts: stm32: Update ck_flexgen_08 frequency.
> 
>  arch/arm/dts/stm32mp251.dtsi      | 2 +-
>  arch/arm/mach-stm32mp/dram_init.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

[PATCH 0/2]

[Finn Thain]

This series removes some duplicate RTC driver code. rtc-m48t59 is tweaked
to bring it into equivalence with the RTC drivers in arch/m68k/mvme*.
Then the latter drivers are removed and platform devices added to make use
of the former.

The second patch depends upon the first, which will require some
coordination between the maintainers of the RTC and m68k subsystems.


Finn Thain (2):
  rtc: m48t59: Accommodate chips that lack a century bit
  m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver

 arch/m68k/configs/multi_defconfig   |   1 +
 arch/m68k/configs/mvme147_defconfig |   1 +
 arch/m68k/configs/mvme16x_defconfig |   1 +
 arch/m68k/include/asm/mvme147hw.h   |  19 +---
 arch/m68k/include/asm/mvme16xhw.h   |  18 +--
 arch/m68k/mvme147/config.c          |  54 ++++-----
 arch/m68k/mvme16x/Makefile          |   2 +-
 arch/m68k/mvme16x/config.c          |  56 ++++------
 arch/m68k/mvme16x/rtc.c             | 165 ----------------------------
 drivers/rtc/rtc-m48t59.c            |  31 +++---
 10 files changed, 67 insertions(+), 281 deletions(-)
 delete mode 100644 arch/m68k/mvme16x/rtc.c

-- 
2.39.5

[PATCH 0/2]

[Pranav Prasad]

This patch series adds fatal error checks for pm8001 driver
functions pm8001_phy_control() and pm8001_lu_reset().

1. Added a fatal error check in pm8001_phy_control().

2. Added a fatal error check in pm8001_lu_reset().

Changyuan Lyu (1):
  scsi: pm80xx: Add fatal error check for pm8001_phy_control()

Igor Pylypiv (1):
  scsi: pm80xx: Add fatal error check for pm8001_lu_reset()

 drivers/scsi/pm8001/pm8001_sas.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

-- 
2.40.1.698.g37aff9b760-goog

[PATCH 0/2]

[Laurent Pinchart]

Hello,

This small patch series simplifies colorspace handling for drivers by
sanitizing values in the V4L2 core.

Patch 1/2 improves the colorspace validity checks in existing helper
functions, to make them more future-proof. It's not a hard dependency
for the next patch, and could be dropped if desired.

Patch 2/2 then extends the v4l_sanitize_format() function to also
sanitize colorspace fields.

Laurent Pinchart (2):
  media: v4l2: Make colorspace validity checks more future-proof
  media: v4l2: Sanitize colorspace values in the framework

 drivers/media/v4l2-core/v4l2-ioctl.c | 65 +++++++++++++++++++++++-----
 include/media/v4l2-common.h          | 10 ++---
 include/uapi/linux/videodev2.h       | 29 +++++++++++++
 3 files changed, 89 insertions(+), 15 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 0/2]

[Zhenneng Li]

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

[PATCH 0/2]

[Zhenneng Li]

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

[PATCH 0/2]

[Zhenneng Li]

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

Re: [PATCH 0/2]

[Rodrigo Siqueira Jordao]

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/2]

[Rodrigo Siqueira Jordao]

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/2]

[Rodrigo Siqueira Jordao]

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 

[PATCH 0/2]

[Antoniu Miclaus]

The ADMV1013 is a wideband, microwave upconverter optimized
for point to point microwave radio designs operating in the
24 GHz to 44 GHz radio frequency (RF) range.

Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADMV1013.pdf

NOTE:
Currently depends on 64-bit architecture since the input
clock that server as Local Oscillator should support values
in the range 5.4 GHz to 10.25 GHz.

We might need some scaling implementation in the clock
framework so that u64 types are supported when using 32-bit
architectures.

Antoniu Miclaus (2):
  iio: frequency: admv1013: add support for ADMV1013
  dt-bindings: iio: frequency: add admv1013 doc

 .../bindings/iio/frequency/adi,admv1013.yaml  | 110 ++++
 drivers/iio/frequency/Kconfig                 |  13 +
 drivers/iio/frequency/Makefile                |   1 +
 drivers/iio/frequency/admv1013.c              | 579 ++++++++++++++++++
 4 files changed, 703 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
 create mode 100644 drivers/iio/frequency/admv1013.c

-- 
2.33.1

[PATCH 0/2]

[Amanda Brindle]

The following changes since commit b73e96e7f3f5d1ba3a221d99792a7a3c7ef42c21:

  python-scons: upgrade to v3.0.1; use pypi.bbclass (2017-12-13 14:00:52 +0000)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib abrindle/rprovides
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/rprovides

Amanda Brindle (2):
  oe-pkgdata-util: Refactor functions for consistency
  oe-pkgdata-util: Add support for RPROVIDES

 scripts/oe-pkgdata-util | 173 +++++++++++++++++++++++++++---------------------
 1 file changed, 97 insertions(+), 76 deletions(-)

-- 
2.7.4

Re: [PATCH 0/2]

[Richard Purdie]

On Mon, 2017-12-18 at 14:12 -0800, Amanda Brindle wrote:
> The following changes since commit
> b73e96e7f3f5d1ba3a221d99792a7a3c7ef42c21:
> 
>   python-scons: upgrade to v3.0.1; use pypi.bbclass (2017-12-13
> 14:00:52 +0000)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib abrindle/rprovides
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/r
> provides
> 
> Amanda Brindle (2):
>   oe-pkgdata-util: Refactor functions for consistency
>   oe-pkgdata-util: Add support for RPROVIDES
> 
>  scripts/oe-pkgdata-util | 173 +++++++++++++++++++++++++++-----------
> ----------
>  1 file changed, 97 insertions(+), 76 deletions(-)

Hi Amanda,

I pulled these into master-next for testing but we saw:

https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/753/steps/Running%20oe-selftest/logs/stdio

You can reproduce with:

oe-selftest -r pkgdata.OePkgdataUtilTests

Cheers,

Richard

[PATCH 0/2]

[Benjamin Gaignard]

Those patches aim to complete stm32 timer features support.
The last missing part is to be able to chain to timer blocks
which mean that one of timerX's trigger could be used as clock for timerY.

Since this operating is neither event or buffer triggered mode I would
like to introduce a hardware triggered mode in IIO core.

Benjamin Gaignard (2):
  iio: add hardware triggered operating mode
  iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode

 .../ABI/testing/sysfs-bus-iio-timer-stm32          | 15 ++++++
 drivers/iio/industrialio-core.c                    |  4 +-
 drivers/iio/trigger/stm32-timer-trigger.c          | 61 ++++++++++++++++++++++
 include/linux/iio/iio.h                            |  6 +++
 4 files changed, 84 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 0/2]

[Jim Qu]

Jim Qu (2):
  drm/amd/amdgpu: fix console deadlock if late init failed
  drm/amd/amdgpu: add atomic helper to suspend/resume functions

 drivers/gpu/drm/amd/amdgpu/amdgpu.h        |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 182 +++++++++++++++++------------
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c     |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   2 +-
 4 files changed, 115 insertions(+), 77 deletions(-)

-- 
1.9.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 0/2]

[Vadim Suraev]

two timer bugs fixed

 lib/librte_timer/rte_timer.c |   21 ++++++++++-----------
 lib/librte_timer/rte_timer.h |    7 ++++++-
 2 files changed, 16 insertions(+), 12 deletions(-)

-- 
1.7.9.5

[PATCH 0/2]

[Vadim Suraev]

rte_timer: 2 bug fixes

Vadim Suraev (2):
  rte_timer bug fix: pending timers count is not  decremented when
    going running. Fix: decrement pending when going running, increment
    if reloaded, do nothing if not reloaded     Signed-off-by: Vadim
    Suraev <vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  rte_timer bug fix: when a perdiodic timer's callback manipulates
    another timer, updated flag prevents reloading the periodic timer.
    Fix: move  updated flag to rte_timer structure (one per core)    
    Signed-off-by: Vadim Suraev <vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

 lib/librte_timer/rte_timer.c |   21 ++++++++++-----------
 lib/librte_timer/rte_timer.h |    7 ++++++-
 2 files changed, 16 insertions(+), 12 deletions(-)

-- 
1.7.9.5

Re: [PATCH 0/2]

[Thomas Monjalon]

Hi Vadim,

Your new patchset trial is better but not correct:
- all is in the title.
- the title must be short and begin with "timer:" as it's done for previous 
timer patches
- you must describe the bug you are fixing

I think you'll understand the problem by looking at the archives:
http://dpdk.org/ml/archives/dev/2014-May/002466.html

Please try again
-- 
Thomas

[PATCH] ARM: i.MX6: dts: change iomuxc pinctrl config to match Rev. 0 IMX6DQRM

[Huang Shijie]

? 2013?08?26? 13:39, alison_chaiken at mentor.com ??:
> From: Alison Chaiken <alison_chaiken@mentor.com>
>
> Update imx6.dtsi iomuxc pinctrl config settings to reflect Table 4-1 of Rev. 0
> (11/2012) of IMX6DQRM, i.MX6 technical reference manual.
>
> Impact:
> USDHC: increase drive speed and impedance.
> I2C and EIM: change drive impedance and disable open-drain.
> ECSPI: change drive impedance.
> ESAI and ENET: probably pedantic changes.
Could you rebase this patch with the latest code? linux-next?


thanks
Huang Shijie

[PATCH 0/2]

[alison_chaiken at mentor.com]

From: Alison Chaiken <alison_chaiken@mentor.com>

Tested on a variety of i.MX6 reference boards with older kernels.    Newly added
pinctrl configuration settings that are not tested are not modified.

Changes since v1:
 * Now rebased on linux-next.

Alison Chaiken (2):
  ARM: i.MX6: dts: change iomuxc pinctrl config to match Rev. 1 IMX6DQRM
  i.MX6: Documentation: Change fsl,imx-pinctrl.txt to match i.MX6 TRM

 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |  25 +-
 arch/arm/boot/dts/imx6qdl.dtsi                     | 354 ++++++++++-----------
 arch/arm/boot/dts/imx6sl.dtsi                      |  48 +--
 3 files changed, 214 insertions(+), 213 deletions(-)

-- 
1.8.4

[PATCH 0/2]

[alison_chaiken]

From: Alison Chaiken <alison_chaiken@mentor.com>

Tested on a variety of i.MX6 reference boards with older kernels.    Newly added
pinctrl configuration settings that are not tested are not modified.

Changes since v1:
 * Now rebased on linux-next.

Alison Chaiken (2):
  ARM: i.MX6: dts: change iomuxc pinctrl config to match Rev. 1 IMX6DQRM
  i.MX6: Documentation: Change fsl,imx-pinctrl.txt to match i.MX6 TRM

 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |  25 +-
 arch/arm/boot/dts/imx6qdl.dtsi                     | 354 ++++++++++-----------
 arch/arm/boot/dts/imx6sl.dtsi                      |  48 +--
 3 files changed, 214 insertions(+), 213 deletions(-)

-- 
1.8.4

[PATCH 0/2]

[Dolev Raviv]

Those patches replace the previous Query Request and NOP patches:
[PATCH 1/8] scsi: ufs: add support for query
[PATCH 7/8] scsi: ufs: Set fDeviceInit flag to initiate device initialization
[PATCH 8/8] scsi: ufs: Fix the response UPIU length setting

And depends on:
[PATCH 2/8] scsi: ufs: wrap the i/o access operations
[PATCH 3/8] scsi: ufs: amend interrupt configuration
[PATCH 4/8] scsi: ufs: remove version check before IS reg clear
[PATCH 5/8] scsi: ufs: rework link start-up process

Sending the query request via the SCSI vendor specific command can cause a deadlock
in case the SCSI command queue is blocked and we would like to send a query request 
(for example fDeviceInit in case of re-initialization).
In addition, usage of a vendor specific SCSI command for UFS can cause future conflicts
if this vendor specific command will be allocated for a different usage.

The below patches allocate an internal tag for NOP and query requests and do not
involve the SCSI layer in UFS specific requests transfers. 
This design also resolves the possible deadlock mentioned above.


Dolev Raviv (1):
  scsi: ufs: Set fDeviceInit flag to initiate device initialization

Sujit Reddy Thumma (1):
  scsi: ufs: Add support for sending NOP OUT UPIU

 drivers/scsi/ufs/ufs.h    |  127 +++++++-
 drivers/scsi/ufs/ufshcd.c |  802 ++++++++++++++++++++++++++++++++++++++------
 drivers/scsi/ufs/ufshcd.h |   40 +++-
 drivers/scsi/ufs/ufshci.h |    2 +-
 4 files changed, 849 insertions(+), 122 deletions(-)

-- 
1.7.6
-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 0/2]

[dmitry pervushin]

Hello all,

These patches update idletimer extension to reflect changes in the kernel

[PATCH 1/2] netfilter: idletimers, synchronize headers
[PATCH 2/2] netfilter: idletimers, add v1 structures

[PATCH 0/2]

[Pablo Neira Ayuso]

Hi Patrick,

The first patch here re-works the conntrack event cache to use the
extension infrastructure so there is an event cache per-conntrack.
This is used by the second patch, which aims to improve ctnetlink
reliability.

Please, have a look at the patch descriptions for more details.
If you like them, you can pull them from:

git://1984.lsi.us.es/nf-next-2.6 master

Wait for your comments!

---

Pablo Neira Ayuso (2):
      netfilter: conntrack: optional reliable conntrack event delivery
      netfilter: conntrack: move event cache to conntrack extension infrastructure


 include/net/netfilter/nf_conntrack.h        |    2 
 include/net/netfilter/nf_conntrack_ecache.h |  133 +++++++++--------
 include/net/netfilter/nf_conntrack_extend.h |    2 
 include/net/netfilter/nf_conntrack_helper.h |    2 
 include/net/netns/conntrack.h               |    7 +
 net/netfilter/nf_conntrack_core.c           |  106 ++++++++++---
 net/netfilter/nf_conntrack_ecache.c         |  216 ++++++++++++++++++---------
 net/netfilter/nf_conntrack_helper.c         |   15 ++
 net/netfilter/nf_conntrack_netlink.c        |   94 +++++++-----
 9 files changed, 379 insertions(+), 198 deletions(-)