[PATCH v2 0/2]

[PATCH v2 0/2]

[Liu, Jinsong]

Intel has released Memory Protection Extensions (MPX) recently.
Please refer to http://download-software.intel.com/sites/default/files/319433-015.pdf

These 2 patches are version2 to support Intel MPX at qemu side.
Version 1:
* Fix cpuid leaf 0x0d bug which incorrectly parsed eax and ebx;
* Expose cpuid leaf (0xd, 3) and (0xd, 4) to guest;

Version 2:
* Add comments to explain cpuid error parse (of current qemu) didn't generate wrong result;
* Add some MPX related definiation, and hardcode sizes and offsets of xsave features 3 and 4. It also add corresponding part to kvm_get/put_xsave.

Thanks,
Jinsong

[PATCH v2 0/2]

[Frans Klaver]

On Tue, Sep 23, 2014 at 11:58 PM, Greg Kroah-Hartman wrote:
> So both would be needed to be backported to stable kernels?  Why not
> just do the fix first, then the cleanup afterward, to make backporting
> easier?

Sure thing. I read something about cleaning up first, then actually changing
stuff, but it doesn't really make sense to move bugs around before fixing them,
unless fixing them requires moving them around.

Anyway, here's the respin.

v1..v2:
  - swapped fix and cleanup to ease backporting

Frans Klaver (2):
  tty: omap-serial: fix division by zero
  tty: omap-serial: pull out calculation from baud_is_mode16

 drivers/tty/serial/omap-serial.c | 34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

-- 
2.1.0

[PATCH v2 0/2]

[Frans Klaver]

On Tue, Sep 23, 2014 at 11:58 PM, Greg Kroah-Hartman wrote:
> So both would be needed to be backported to stable kernels?  Why not
> just do the fix first, then the cleanup afterward, to make backporting
> easier?

Sure thing. I read something about cleaning up first, then actually changing
stuff, but it doesn't really make sense to move bugs around before fixing them,
unless fixing them requires moving them around.

Anyway, here's the respin.

v1..v2:
  - swapped fix and cleanup to ease backporting

Frans Klaver (2):
  tty: omap-serial: fix division by zero
  tty: omap-serial: pull out calculation from baud_is_mode16

 drivers/tty/serial/omap-serial.c | 34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

-- 
2.1.0

[PATCH v2 0/2]

[Ouyang Changchun]

This patch enables testpmd user can config port hw_vlan with more fine granularity:
hw vlan filter, hw vlan strip, and hw vlan extend;

Update testpmd doc accordingly.

Changchun Ouyang (2):
  testpmd: HW vlan command
  doc: Update for new HW vlan command

 app/test-pmd/cmdline.c                      | 36 ++++++++++++++++++++++++++---
 app/test-pmd/parameters.c                   | 18 +++++++++++++++
 doc/guides/testpmd_app_ug/run_app.rst       | 12 ++++++++++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33 ++++++++++++++++++++++++++
 4 files changed, 96 insertions(+), 3 deletions(-)

-- 
1.8.4.2

Re: [PATCH v2 0/2]

[Ouyang, Changchun]

> -----Original Message-----
> From: Ouyang, Changchun
> Sent: Friday, March 6, 2015 4:00 PM
> To: dev-VfR2kkLFssw@public.gmane.org
> Cc: Butler, Siobhan A; De Lara Guarch, Pablo; Cao, Waterman; Ouyang,
> Changchun
> Subject: [PATCH v2 0/2]
> 
> This patch enables testpmd user can config port hw_vlan with more fine
> granularity:
> hw vlan filter, hw vlan strip, and hw vlan extend;
> 
> Update testpmd doc accordingly.
> 
> Changchun Ouyang (2):
>   testpmd: HW vlan command
>   doc: Update for new HW vlan command
> 
>  app/test-pmd/cmdline.c                      | 36 ++++++++++++++++++++++++++---
>  app/test-pmd/parameters.c                   | 18 +++++++++++++++
>  doc/guides/testpmd_app_ug/run_app.rst       | 12 ++++++++++
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33
> ++++++++++++++++++++++++++
>  4 files changed, 96 insertions(+), 3 deletions(-)
> 
> --
> 1.8.4.2

Self-nack it, due to missing subject.
Will send a v3 patch set.

[PATCH v2 0/2]

[Gary Tierney]

Have updated the patches to print error messages for failures which result in
indeterminate state and warnings for failures to load policy from userspace.
Also updated the patches to remove the function name from log messages.

Steve,

Does your work on AUDIT_MAC_STATUS_FAIL/AUDIT_MAC_LOAD_FAIL messages (I'm
assuming that's what Stephen's referencing in his previous mail) obsolete the
printk logs in the first patch?  An AUDIT_MAC_POLICY_LOAD message would still
be logged presently even if one of sel_make_{bools,classes,policycap} fails, so
I'm not sure if you would also want an
AUDIT_MAC_STATUS_FAIL/AUDIT_MAC_LOAD_FAIL message when that happens, though I
think you might want one in the first case when security_load_policy() fails
(or anything up until that point).

Gary Tierney (2):
  selinux: log errors when loading new policy
  selinux: default to security isid in sel_make_bools() if no sid is
    found

 security/selinux/selinuxfs.c | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

-- 
2.7.4

Re: [PATCH v2 0/2]

[Steve Grubb]

On Tuesday, December 20, 2016 1:28:45 AM EST Gary Tierney wrote:
> Have updated the patches to print error messages for failures which result
> in indeterminate state and warnings for failures to load policy from
> userspace. Also updated the patches to remove the function name from log
> messages.
> 
> Steve,
> 
> Does your work on AUDIT_MAC_STATUS_FAIL/AUDIT_MAC_LOAD_FAIL messages (I'm
> assuming that's what Stephen's referencing in his previous mail) obsolete
> the printk logs in the first patch?

No, audit cares only about audit events. We don't care at all about syslog 
messages. However, they ought to be singing the same song so to speak.

-Steve

[PATCH v2 0/2]

[Tamara Diaconita]

Tamara Diaconita (2):
  staging: speakup: keyhelp: Add spaces to align
  staging: speakup: keyhelp: Fix 'if' continuation

Changes since v1:
*Deleted the patch: 'staging:speakup:keyhelp.c: Remove unnecessary else' from the set and remake the original file.
*Deleted the '.c' in the subject of the patches.
*Added a space after ':' in the subject of the patches.

 drivers/staging/speakup/keyhelp.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

-- 
2.9.3

Re: [PATCH v2 0/2]

[Greg KH]

On Mon, Mar 06, 2017 at 08:20:52PM +0200, Tamara Diaconita wrote:
> Tamara Diaconita (2):
>   staging: speakup: keyhelp: Add spaces to align
>   staging: speakup: keyhelp: Fix 'if' continuation
> 
> Changes since v1:
> *Deleted the patch: 'staging:speakup:keyhelp.c: Remove unnecessary else' from the set and remake the original file.
> *Deleted the '.c' in the subject of the patches.
> *Added a space after ':' in the subject of the patches.
> 
>  drivers/staging/speakup/keyhelp.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)

Why is there no real subject here saying what these patches are for?

thanks,

greg k-h

[patch v2 0/2]

[Oleksandr Shamray]

When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, it could be done from the external
JTAG master controller.
 
For such purpose, usually the user layer
application implements jtag protocol or using a proprietary
connection to vendor hardware.
This method is slow and not generic.
 
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's 
device via BMC without additional devices nor cost. 

This patch purpose is to add JTAG master core infrastructure by 
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.

The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
 
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.

For example, systems which equipped with host CPU, BMC SoC or/and 
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:

BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production) 
BMC JTAG master --> pin selected to voltage monitors for programming 
(field upgrade, production) 
BMC JTAG master --> pin selected to host CPU (on-site debugging 
and developers debugging)

For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
 
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);

The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.

Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
  number of clocks.

SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.

Oleksandr Shamray (2):
  drivers: jtag: Add JTAG core driver
  drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
    driver

 .../devicetree/bindings/jtag/aspeed-jtag.txt       |   27 +
 Documentation/ioctl/ioctl-number.txt               |    2 +
 MAINTAINERS                                        |    8 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    1 +
 drivers/jtag/Kconfig                               |   29 +
 drivers/jtag/Makefile                              |    2 +
 drivers/jtag/jtag-aspeed.c                         |  774 ++++++++++++++++++++
 drivers/jtag/jtag.c                                |  313 ++++++++
 include/linux/jtag.h                               |   42 ++
 include/uapi/linux/jtag.h                          |  113 +++
 11 files changed, 1313 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
 create mode 100644 drivers/jtag/Kconfig
 create mode 100644 drivers/jtag/Makefile
 create mode 100644 drivers/jtag/jtag-aspeed.c
 create mode 100644 drivers/jtag/jtag.c
 create mode 100644 include/linux/jtag.h
 create mode 100644 include/uapi/linux/jtag.h

[patch v2 0/2]

[Oleksandr Shamray]

When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, it could be done from the external
JTAG master controller.
 
For such purpose, usually the user layer
application implements jtag protocol or using a proprietary
connection to vendor hardware.
This method is slow and not generic.
 
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's 
device via BMC without additional devices nor cost. 

This patch purpose is to add JTAG master core infrastructure by 
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.

The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
 
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.

For example, systems which equipped with host CPU, BMC SoC or/and 
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:

BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production) 
BMC JTAG master --> pin selected to voltage monitors for programming 
(field upgrade, production) 
BMC JTAG master --> pin selected to host CPU (on-site debugging 
and developers debugging)

For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
 
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);

The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.

Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
  number of clocks.

SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.

Oleksandr Shamray (2):
  drivers: jtag: Add JTAG core driver
  drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
    driver

 .../devicetree/bindings/jtag/aspeed-jtag.txt       |   27 +
 Documentation/ioctl/ioctl-number.txt               |    2 +
 MAINTAINERS                                        |    8 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    1 +
 drivers/jtag/Kconfig                               |   29 +
 drivers/jtag/Makefile                              |    2 +
 drivers/jtag/jtag-aspeed.c                         |  774 ++++++++++++++++++++
 drivers/jtag/jtag.c                                |  313 ++++++++
 include/linux/jtag.h                               |   42 ++
 include/uapi/linux/jtag.h                          |  113 +++
 11 files changed, 1313 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
 create mode 100644 drivers/jtag/Kconfig
 create mode 100644 drivers/jtag/Makefile
 create mode 100644 drivers/jtag/jtag-aspeed.c
 create mode 100644 drivers/jtag/jtag.c
 create mode 100644 include/linux/jtag.h
 create mode 100644 include/uapi/linux/jtag.h

Re: [patch v2 0/2]

[Andrew Lunn]

On Mon, Aug 07, 2017 at 05:17:45PM +0300, Oleksandr Shamray wrote:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, it could be done from the external
> JTAG master controller.
>  
> For such purpose, usually the user layer
> application implements jtag protocol or using a proprietary
> connection to vendor hardware.
> This method is slow and not generic.
>  
> We propose to implement general JTAG interface and infrastructure
> to communicate with user layer application. 

Hi Oleksandr

You might find this discussion interesting:

https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-August/004721.html

You are defining a new ABI here, so linux-abi should be involved in
the discussion of these patches.

    Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch v2 0/2]

[Andrew Lunn]

On Mon, Aug 07, 2017 at 05:17:45PM +0300, Oleksandr Shamray wrote:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, it could be done from the external
> JTAG master controller.
>  
> For such purpose, usually the user layer
> application implements jtag protocol or using a proprietary
> connection to vendor hardware.
> This method is slow and not generic.
>  
> We propose to implement general JTAG interface and infrastructure
> to communicate with user layer application. 

Hi Oleksandr

You might find this discussion interesting:

https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-August/004721.html

You are defining a new ABI here, so linux-abi should be involved in
the discussion of these patches.

    Andrew

[patch v2 0/2]

[Andrew Lunn]

On Mon, Aug 07, 2017 at 05:17:45PM +0300, Oleksandr Shamray wrote:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, it could be done from the external
> JTAG master controller.
>  
> For such purpose, usually the user layer
> application implements jtag protocol or using a proprietary
> connection to vendor hardware.
> This method is slow and not generic.
>  
> We propose to implement general JTAG interface and infrastructure
> to communicate with user layer application. 

Hi Oleksandr

You might find this discussion interesting:

https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-August/004721.html

You are defining a new ABI here, so linux-abi should be involved in
the discussion of these patches.

    Andrew

Re: [patch v2 0/2]

[Greg KH]

On Mon, Aug 07, 2017 at 05:17:45PM +0300, Oleksandr Shamray wrote:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, it could be done from the external
> JTAG master controller.

Your subject line is a bit "odd" :(

[patch v2 0/2]

[Greg KH]

On Mon, Aug 07, 2017 at 05:17:45PM +0300, Oleksandr Shamray wrote:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, it could be done from the external
> JTAG master controller.

Your subject line is a bit "odd" :(

[PATCH v2 0/2]

[sean.wang]

From: Sean Wang <sean.wang@mediatek.com>

Since v2: 
- reusing 8250_of since the original driver has almost the same logic

This patchset introduces the support for MediaTek BTIF controller.

MediaTek BTIF controller is the serial interface similar to UART but it
works only as the digital device which is mainly used to communicate with
the connectivity module also called CONNSYS inside the SoC which could be
mostly found on those MediaTek SoCs with Bluetooth feature.

And the controller is made as being compatible with the 8250 register
layout so it tends to be integrated with existing 8250 core driver and
have no requirement for the modem configuration additionally such as the
baud rate calculation and assignment.

Sean Wang (2):
  dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings
  serial: 8250: of: Add new port type for MediaTek BTIF controller on
    MT7622/23 SoC

 Documentation/devicetree/bindings/serial/8250.txt | 3 +++
 drivers/tty/serial/8250/8250_of.c                 | 2 ++
 drivers/tty/serial/8250/8250_port.c               | 8 ++++++++
 include/uapi/linux/serial_core.h                  | 3 +++
 4 files changed, 16 insertions(+)

-- 
2.7.4

[PATCH v2 0/2]

[sean.wang at mediatek.com]

From: Sean Wang <sean.wang@mediatek.com>

Since v2: 
- reusing 8250_of since the original driver has almost the same logic

This patchset introduces the support for MediaTek BTIF controller.

MediaTek BTIF controller is the serial interface similar to UART but it
works only as the digital device which is mainly used to communicate with
the connectivity module also called CONNSYS inside the SoC which could be
mostly found on those MediaTek SoCs with Bluetooth feature.

And the controller is made as being compatible with the 8250 register
layout so it tends to be integrated with existing 8250 core driver and
have no requirement for the modem configuration additionally such as the
baud rate calculation and assignment.

Sean Wang (2):
  dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings
  serial: 8250: of: Add new port type for MediaTek BTIF controller on
    MT7622/23 SoC

 Documentation/devicetree/bindings/serial/8250.txt | 3 +++
 drivers/tty/serial/8250/8250_of.c                 | 2 ++
 drivers/tty/serial/8250/8250_port.c               | 8 ++++++++
 include/uapi/linux/serial_core.h                  | 3 +++
 4 files changed, 16 insertions(+)

-- 
2.7.4

[PATCH v2 0/2]

[sean.wang]

From: Sean Wang <sean.wang@mediatek.com>

Since v2: 
- reusing 8250_of since the original driver has almost the same logic

This patchset introduces the support for MediaTek BTIF controller.

MediaTek BTIF controller is the serial interface similar to UART but it
works only as the digital device which is mainly used to communicate with
the connectivity module also called CONNSYS inside the SoC which could be
mostly found on those MediaTek SoCs with Bluetooth feature.

And the controller is made as being compatible with the 8250 register
layout so it tends to be integrated with existing 8250 core driver and
have no requirement for the modem configuration additionally such as the
baud rate calculation and assignment.

Sean Wang (2):
  dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings
  serial: 8250: of: Add new port type for MediaTek BTIF controller on
    MT7622/23 SoC

 Documentation/devicetree/bindings/serial/8250.txt | 3 +++
 drivers/tty/serial/8250/8250_of.c                 | 2 ++
 drivers/tty/serial/8250/8250_port.c               | 8 ++++++++
 include/uapi/linux/serial_core.h                  | 3 +++
 4 files changed, 16 insertions(+)

-- 
2.7.4

[PATCH v2 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[sean.wang]

From: Sean Wang <sean.wang@mediatek.com>

Document the devicetree bindings in 8250.txt for MediaTek BTIF
controller which could be found on MT7622 and MT7623 SoC.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
 Documentation/devicetree/bindings/serial/8250.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index 419ff6c..7528d90 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -14,6 +14,9 @@ Required properties:
 	  tegra132, or tegra210.
 	- "nxp,lpc3220-uart"
 	- "ralink,rt2880-uart"
+	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
+	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
+	  "mediatek,mt7623-btif" where <chip> is mt7622.
 	- "altr,16550-FIFO32"
 	- "altr,16550-FIFO64"
 	- "altr,16550-FIFO128"
-- 
2.7.4

[PATCH v2 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[sean.wang at mediatek.com]

From: Sean Wang <sean.wang@mediatek.com>

Document the devicetree bindings in 8250.txt for MediaTek BTIF
controller which could be found on MT7622 and MT7623 SoC.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
 Documentation/devicetree/bindings/serial/8250.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index 419ff6c..7528d90 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -14,6 +14,9 @@ Required properties:
 	  tegra132, or tegra210.
 	- "nxp,lpc3220-uart"
 	- "ralink,rt2880-uart"
+	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
+	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
+	  "mediatek,mt7623-btif" where <chip> is mt7622.
 	- "altr,16550-FIFO32"
 	- "altr,16550-FIFO64"
 	- "altr,16550-FIFO128"
-- 
2.7.4

[PATCH v2 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[sean.wang]

From: Sean Wang <sean.wang@mediatek.com>

Document the devicetree bindings in 8250.txt for MediaTek BTIF
controller which could be found on MT7622 and MT7623 SoC.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
 Documentation/devicetree/bindings/serial/8250.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index 419ff6c..7528d90 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -14,6 +14,9 @@ Required properties:
 	  tegra132, or tegra210.
 	- "nxp,lpc3220-uart"
 	- "ralink,rt2880-uart"
+	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
+	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
+	  "mediatek,mt7623-btif" where <chip> is mt7622.
 	- "altr,16550-FIFO32"
 	- "altr,16550-FIFO64"
 	- "altr,16550-FIFO128"
-- 
2.7.4

[PATCH v2 2/2] serial: 8250: of: Add new port type for MediaTek BTIF controller on MT7622/23 SoC

[sean.wang]

From: Sean Wang <sean.wang@mediatek.com>

MediaTek BTIF controller is the serial interface similar to UART but it
works only as the digital device which is mainly used to communicate with
the connectivity module called CONNSYS inside the SoC which could be mostly
found on those MediaTek SoCs with Bluetooth feature such as MT7622 and
MT7623 SoCs.

And the controller is made as being compatible with the 8250 register
layout with extra registers such as DMA enablement so it tends to be
integrated with reusing 8250 OF driver. However, DMA mode is not being
supported yet in the current driver.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/tty/serial/8250/8250_of.c   | 2 ++
 drivers/tty/serial/8250/8250_port.c | 8 ++++++++
 include/uapi/linux/serial_core.h    | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 6c5a8ca..47d4772 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -300,6 +300,8 @@ static const struct of_device_id of_platform_serial_table[] = {
 		.data = (void *)PORT_ALTR_16550_F64, },
 	{ .compatible = "altr,16550-FIFO128",
 		.data = (void *)PORT_ALTR_16550_F128, },
+	{ .compatible = "mediatek,mt7623-btif",
+		.data = (void *)PORT_MTK_BTIF, },
 	{ .compatible = "mrvl,mmp-uart",
 		.data = (void *)PORT_XSCALE, },
 	{ .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 25aae66..053bb38 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -289,6 +289,14 @@ static const struct serial8250_config uart_config[] = {
 		.rxtrig_bytes	= {1, 4, 8, 14},
 		.flags		= UART_CAP_FIFO | UART_CAP_AFE,
 	},
+	[PORT_MTK_BTIF] = {
+		.name		= "MediaTek BTIF",
+		.fifo_size	= 16,
+		.tx_loadsz	= 16,
+		.fcr		= UART_FCR_ENABLE_FIFO |
+				  UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
+		.flags		= UART_CAP_FIFO,
+	},
 };
 
 /* Uart divisor latch read */
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 38bea32..cfc07a5 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -272,4 +272,7 @@
 /* MPS2 UART */
 #define PORT_MPS2UART	116
 
+/* MediaTek BTIF */
+#define PORT_MTK_BTIF	117
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.7.4

[PATCH v2 2/2] serial: 8250: of: Add new port type for MediaTek BTIF controller on MT7622/23 SoC

[sean.wang at mediatek.com]

From: Sean Wang <sean.wang@mediatek.com>

MediaTek BTIF controller is the serial interface similar to UART but it
works only as the digital device which is mainly used to communicate with
the connectivity module called CONNSYS inside the SoC which could be mostly
found on those MediaTek SoCs with Bluetooth feature such as MT7622 and
MT7623 SoCs.

And the controller is made as being compatible with the 8250 register
layout with extra registers such as DMA enablement so it tends to be
integrated with reusing 8250 OF driver. However, DMA mode is not being
supported yet in the current driver.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/tty/serial/8250/8250_of.c   | 2 ++
 drivers/tty/serial/8250/8250_port.c | 8 ++++++++
 include/uapi/linux/serial_core.h    | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 6c5a8ca..47d4772 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -300,6 +300,8 @@ static const struct of_device_id of_platform_serial_table[] = {
 		.data = (void *)PORT_ALTR_16550_F64, },
 	{ .compatible = "altr,16550-FIFO128",
 		.data = (void *)PORT_ALTR_16550_F128, },
+	{ .compatible = "mediatek,mt7623-btif",
+		.data = (void *)PORT_MTK_BTIF, },
 	{ .compatible = "mrvl,mmp-uart",
 		.data = (void *)PORT_XSCALE, },
 	{ .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 25aae66..053bb38 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -289,6 +289,14 @@ static const struct serial8250_config uart_config[] = {
 		.rxtrig_bytes	= {1, 4, 8, 14},
 		.flags		= UART_CAP_FIFO | UART_CAP_AFE,
 	},
+	[PORT_MTK_BTIF] = {
+		.name		= "MediaTek BTIF",
+		.fifo_size	= 16,
+		.tx_loadsz	= 16,
+		.fcr		= UART_FCR_ENABLE_FIFO |
+				  UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
+		.flags		= UART_CAP_FIFO,
+	},
 };
 
 /* Uart divisor latch read */
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 38bea32..cfc07a5 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -272,4 +272,7 @@
 /* MPS2 UART */
 #define PORT_MPS2UART	116
 
+/* MediaTek BTIF */
+#define PORT_MTK_BTIF	117
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.7.4

[PATCH v2 2/2] serial: 8250: of: Add new port type for MediaTek BTIF controller on MT7622/23 SoC

[sean.wang]

From: Sean Wang <sean.wang@mediatek.com>

MediaTek BTIF controller is the serial interface similar to UART but it
works only as the digital device which is mainly used to communicate with
the connectivity module called CONNSYS inside the SoC which could be mostly
found on those MediaTek SoCs with Bluetooth feature such as MT7622 and
MT7623 SoCs.

And the controller is made as being compatible with the 8250 register
layout with extra registers such as DMA enablement so it tends to be
integrated with reusing 8250 OF driver. However, DMA mode is not being
supported yet in the current driver.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/tty/serial/8250/8250_of.c   | 2 ++
 drivers/tty/serial/8250/8250_port.c | 8 ++++++++
 include/uapi/linux/serial_core.h    | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 6c5a8ca..47d4772 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -300,6 +300,8 @@ static const struct of_device_id of_platform_serial_table[] = {
 		.data = (void *)PORT_ALTR_16550_F64, },
 	{ .compatible = "altr,16550-FIFO128",
 		.data = (void *)PORT_ALTR_16550_F128, },
+	{ .compatible = "mediatek,mt7623-btif",
+		.data = (void *)PORT_MTK_BTIF, },
 	{ .compatible = "mrvl,mmp-uart",
 		.data = (void *)PORT_XSCALE, },
 	{ .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 25aae66..053bb38 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -289,6 +289,14 @@ static const struct serial8250_config uart_config[] = {
 		.rxtrig_bytes	= {1, 4, 8, 14},
 		.flags		= UART_CAP_FIFO | UART_CAP_AFE,
 	},
+	[PORT_MTK_BTIF] = {
+		.name		= "MediaTek BTIF",
+		.fifo_size	= 16,
+		.tx_loadsz	= 16,
+		.fcr		= UART_FCR_ENABLE_FIFO |
+				  UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
+		.flags		= UART_CAP_FIFO,
+	},
 };
 
 /* Uart divisor latch read */
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 38bea32..cfc07a5 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -272,4 +272,7 @@
 /* MPS2 UART */
 #define PORT_MPS2UART	116
 
+/* MediaTek BTIF */
+#define PORT_MTK_BTIF	117
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.7.4

Re: [PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Matthias Brugger]

On 08/19/2017 09:06 PM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> 
> Document the devicetree bindings in 8250.txt for MediaTek BTIF
> controller which could be found on MT7622 and MT7623 SoC.
> 
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
>   Documentation/devicetree/bindings/serial/8250.txt | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> index 419ff6c..7528d90 100644
> --- a/Documentation/devicetree/bindings/serial/8250.txt
> +++ b/Documentation/devicetree/bindings/serial/8250.txt
> @@ -14,6 +14,9 @@ Required properties:
>   	  tegra132, or tegra210.
>   	- "nxp,lpc3220-uart"
>   	- "ralink,rt2880-uart"
> +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
> +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
> +	  "mediatek,mt7623-btif" where <chip> is mt7622.

Hm, to me that's confusing. What about:
"mediatek,mt7623-btif": for MediaTek MT7623
"mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622

If in the future we have more SoCs that support the BTIF, we should add them 
like the mt7622 case.

Make sense?

Regards,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Matthias Brugger]

On 08/19/2017 09:06 PM, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
> 
> Document the devicetree bindings in 8250.txt for MediaTek BTIF
> controller which could be found on MT7622 and MT7623 SoC.
> 
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
>   Documentation/devicetree/bindings/serial/8250.txt | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> index 419ff6c..7528d90 100644
> --- a/Documentation/devicetree/bindings/serial/8250.txt
> +++ b/Documentation/devicetree/bindings/serial/8250.txt
> @@ -14,6 +14,9 @@ Required properties:
>   	  tegra132, or tegra210.
>   	- "nxp,lpc3220-uart"
>   	- "ralink,rt2880-uart"
> +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
> +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
> +	  "mediatek,mt7623-btif" where <chip> is mt7622.

Hm, to me that's confusing. What about:
"mediatek,mt7623-btif": for MediaTek MT7623
"mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622

If in the future we have more SoCs that support the BTIF, we should add them 
like the mt7622 case.

Make sense?

Regards,
Matthias

Re: [PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Matthias Brugger]

On 08/19/2017 09:06 PM, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
> 
> Document the devicetree bindings in 8250.txt for MediaTek BTIF
> controller which could be found on MT7622 and MT7623 SoC.
> 
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
>   Documentation/devicetree/bindings/serial/8250.txt | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> index 419ff6c..7528d90 100644
> --- a/Documentation/devicetree/bindings/serial/8250.txt
> +++ b/Documentation/devicetree/bindings/serial/8250.txt
> @@ -14,6 +14,9 @@ Required properties:
>   	  tegra132, or tegra210.
>   	- "nxp,lpc3220-uart"
>   	- "ralink,rt2880-uart"
> +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
> +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
> +	  "mediatek,mt7623-btif" where <chip> is mt7622.

Hm, to me that's confusing. What about:
"mediatek,mt7623-btif": for MediaTek MT7623
"mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622

If in the future we have more SoCs that support the BTIF, we should add them 
like the mt7622 case.

Make sense?

Regards,
Matthias

Re: [PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Sean Wang]

On Sun, 2017-08-27 at 22:00 +0300, Matthias Brugger wrote:
> 
> On 08/19/2017 09:06 PM, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> > 
> > Document the devicetree bindings in 8250.txt for MediaTek BTIF
> > controller which could be found on MT7622 and MT7623 SoC.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> >   Documentation/devicetree/bindings/serial/8250.txt | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> > index 419ff6c..7528d90 100644
> > --- a/Documentation/devicetree/bindings/serial/8250.txt
> > +++ b/Documentation/devicetree/bindings/serial/8250.txt
> > @@ -14,6 +14,9 @@ Required properties:
> >   	  tegra132, or tegra210.
> >   	- "nxp,lpc3220-uart"
> >   	- "ralink,rt2880-uart"
> > +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
> > +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
> > +	  "mediatek,mt7623-btif" where <chip> is mt7622.
> 
> Hm, to me that's confusing. What about:
> "mediatek,mt7623-btif": for MediaTek MT7623
> "mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622
> 
> If in the future we have more SoCs that support the BTIF, we should add them 
> like the mt7622 case.
> 

I had v3, but it should have similar logic and also got ack from Rob

I knew all your logic of adding binding document for all MediaTek
devices, even I alway added MediaTek device in dt-bindings as the way
you mentioned here, but I felt this way is fine for this kind of
dedicated document.

The reason i don't add it as usual is the following. 8250.txt is common
and shared among all uart like devices, so i don't want btif device
occupies too much section and bloat the document when every new MediaTek
SoC is introduced. 

So instead I refer to existing Nvidia device added in 8250.txt  which I
thought its way is simple, elegant and also using pattern I can use to
add btif devices.

	Sean

> Make sense?
> 
> Regards,
> Matthias

[PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Sean Wang]

On Sun, 2017-08-27 at 22:00 +0300, Matthias Brugger wrote:
> 
> On 08/19/2017 09:06 PM, sean.wang at mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> > 
> > Document the devicetree bindings in 8250.txt for MediaTek BTIF
> > controller which could be found on MT7622 and MT7623 SoC.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> >   Documentation/devicetree/bindings/serial/8250.txt | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> > index 419ff6c..7528d90 100644
> > --- a/Documentation/devicetree/bindings/serial/8250.txt
> > +++ b/Documentation/devicetree/bindings/serial/8250.txt
> > @@ -14,6 +14,9 @@ Required properties:
> >   	  tegra132, or tegra210.
> >   	- "nxp,lpc3220-uart"
> >   	- "ralink,rt2880-uart"
> > +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
> > +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
> > +	  "mediatek,mt7623-btif" where <chip> is mt7622.
> 
> Hm, to me that's confusing. What about:
> "mediatek,mt7623-btif": for MediaTek MT7623
> "mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622
> 
> If in the future we have more SoCs that support the BTIF, we should add them 
> like the mt7622 case.
> 

I had v3, but it should have similar logic and also got ack from Rob

I knew all your logic of adding binding document for all MediaTek
devices, even I alway added MediaTek device in dt-bindings as the way
you mentioned here, but I felt this way is fine for this kind of
dedicated document.

The reason i don't add it as usual is the following. 8250.txt is common
and shared among all uart like devices, so i don't want btif device
occupies too much section and bloat the document when every new MediaTek
SoC is introduced. 

So instead I refer to existing Nvidia device added in 8250.txt  which I
thought its way is simple, elegant and also using pattern I can use to
add btif devices.

	Sean

> Make sense?
> 
> Regards,
> Matthias

Re: [PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Sean Wang]

On Sun, 2017-08-27 at 22:00 +0300, Matthias Brugger wrote:
> 
> On 08/19/2017 09:06 PM, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> > 
> > Document the devicetree bindings in 8250.txt for MediaTek BTIF
> > controller which could be found on MT7622 and MT7623 SoC.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> >   Documentation/devicetree/bindings/serial/8250.txt | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
> > index 419ff6c..7528d90 100644
> > --- a/Documentation/devicetree/bindings/serial/8250.txt
> > +++ b/Documentation/devicetree/bindings/serial/8250.txt
> > @@ -14,6 +14,9 @@ Required properties:
> >   	  tegra132, or tegra210.
> >   	- "nxp,lpc3220-uart"
> >   	- "ralink,rt2880-uart"
> > +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
> > +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
> > +	  "mediatek,mt7623-btif" where <chip> is mt7622.
> 
> Hm, to me that's confusing. What about:
> "mediatek,mt7623-btif": for MediaTek MT7623
> "mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622
> 
> If in the future we have more SoCs that support the BTIF, we should add them 
> like the mt7622 case.
> 

I had v3, but it should have similar logic and also got ack from Rob

I knew all your logic of adding binding document for all MediaTek
devices, even I alway added MediaTek device in dt-bindings as the way
you mentioned here, but I felt this way is fine for this kind of
dedicated document.

The reason i don't add it as usual is the following. 8250.txt is common
and shared among all uart like devices, so i don't want btif device
occupies too much section and bloat the document when every new MediaTek
SoC is introduced. 

So instead I refer to existing Nvidia device added in 8250.txt  which I
thought its way is simple, elegant and also using pattern I can use to
add btif devices.

	Sean

> Make sense?
> 
> Regards,
> Matthias

Re: [PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Matthias Brugger]

On 08/27/2017 10:39 PM, Sean Wang wrote:
> On Sun, 2017-08-27 at 22:00 +0300, Matthias Brugger wrote:
>>
>> On 08/19/2017 09:06 PM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
>>> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>
>>> Document the devicetree bindings in 8250.txt for MediaTek BTIF
>>> controller which could be found on MT7622 and MT7623 SoC.
>>>
>>> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>> ---
>>>    Documentation/devicetree/bindings/serial/8250.txt | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
>>> index 419ff6c..7528d90 100644
>>> --- a/Documentation/devicetree/bindings/serial/8250.txt
>>> +++ b/Documentation/devicetree/bindings/serial/8250.txt
>>> @@ -14,6 +14,9 @@ Required properties:
>>>    	  tegra132, or tegra210.
>>>    	- "nxp,lpc3220-uart"
>>>    	- "ralink,rt2880-uart"
>>> +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
>>> +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
>>> +	  "mediatek,mt7623-btif" where <chip> is mt7622.
>>
>> Hm, to me that's confusing. What about:
>> "mediatek,mt7623-btif": for MediaTek MT7623
>> "mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622
>>
>> If in the future we have more SoCs that support the BTIF, we should add them
>> like the mt7622 case.
>>
> 
> I had v3, but it should have similar logic and also got ack from Rob
> 
> I knew all your logic of adding binding document for all MediaTek
> devices, even I alway added MediaTek device in dt-bindings as the way
> you mentioned here, but I felt this way is fine for this kind of
> dedicated document.
> 
> The reason i don't add it as usual is the following. 8250.txt is common
> and shared among all uart like devices, so i don't want btif device
> occupies too much section and bloat the document when every new MediaTek
> SoC is introduced.
> 
> So instead I refer to existing Nvidia device added in 8250.txt  which I
> thought its way is simple, elegant and also using pattern I can use to
> add btif devices.
> 

Working on my email backlog after vactions I didn't see that this was accepted 
by Rob. Sorry for the noise.

Matthias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Matthias Brugger]

On 08/27/2017 10:39 PM, Sean Wang wrote:
> On Sun, 2017-08-27 at 22:00 +0300, Matthias Brugger wrote:
>>
>> On 08/19/2017 09:06 PM, sean.wang at mediatek.com wrote:
>>> From: Sean Wang <sean.wang@mediatek.com>
>>>
>>> Document the devicetree bindings in 8250.txt for MediaTek BTIF
>>> controller which could be found on MT7622 and MT7623 SoC.
>>>
>>> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>>> ---
>>>    Documentation/devicetree/bindings/serial/8250.txt | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
>>> index 419ff6c..7528d90 100644
>>> --- a/Documentation/devicetree/bindings/serial/8250.txt
>>> +++ b/Documentation/devicetree/bindings/serial/8250.txt
>>> @@ -14,6 +14,9 @@ Required properties:
>>>    	  tegra132, or tegra210.
>>>    	- "nxp,lpc3220-uart"
>>>    	- "ralink,rt2880-uart"
>>> +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
>>> +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
>>> +	  "mediatek,mt7623-btif" where <chip> is mt7622.
>>
>> Hm, to me that's confusing. What about:
>> "mediatek,mt7623-btif": for MediaTek MT7623
>> "mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622
>>
>> If in the future we have more SoCs that support the BTIF, we should add them
>> like the mt7622 case.
>>
> 
> I had v3, but it should have similar logic and also got ack from Rob
> 
> I knew all your logic of adding binding document for all MediaTek
> devices, even I alway added MediaTek device in dt-bindings as the way
> you mentioned here, but I felt this way is fine for this kind of
> dedicated document.
> 
> The reason i don't add it as usual is the following. 8250.txt is common
> and shared among all uart like devices, so i don't want btif device
> occupies too much section and bloat the document when every new MediaTek
> SoC is introduced.
> 
> So instead I refer to existing Nvidia device added in 8250.txt  which I
> thought its way is simple, elegant and also using pattern I can use to
> add btif devices.
> 

Working on my email backlog after vactions I didn't see that this was accepted 
by Rob. Sorry for the noise.

Matthias

Re: [PATCH v2 RESEND 1/2] dt-bindings: serial: 8250: Add MediaTek BTIF controller bindings

[Matthias Brugger]

On 08/27/2017 10:39 PM, Sean Wang wrote:
> On Sun, 2017-08-27 at 22:00 +0300, Matthias Brugger wrote:
>>
>> On 08/19/2017 09:06 PM, sean.wang@mediatek.com wrote:
>>> From: Sean Wang <sean.wang@mediatek.com>
>>>
>>> Document the devicetree bindings in 8250.txt for MediaTek BTIF
>>> controller which could be found on MT7622 and MT7623 SoC.
>>>
>>> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>>> ---
>>>    Documentation/devicetree/bindings/serial/8250.txt | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
>>> index 419ff6c..7528d90 100644
>>> --- a/Documentation/devicetree/bindings/serial/8250.txt
>>> +++ b/Documentation/devicetree/bindings/serial/8250.txt
>>> @@ -14,6 +14,9 @@ Required properties:
>>>    	  tegra132, or tegra210.
>>>    	- "nxp,lpc3220-uart"
>>>    	- "ralink,rt2880-uart"
>>> +	- For MediaTek MT7623, must contain "mediatek,mt7623-btif"
>>> +	- For other MediaTek SoCs , must contain "mediatek,<chip>-btif",
>>> +	  "mediatek,mt7623-btif" where <chip> is mt7622.
>>
>> Hm, to me that's confusing. What about:
>> "mediatek,mt7623-btif": for MediaTek MT7623
>> "mediatek,mt7622-btif", "mediatek,mt7623-btif": for MediaTek MT7622
>>
>> If in the future we have more SoCs that support the BTIF, we should add them
>> like the mt7622 case.
>>
> 
> I had v3, but it should have similar logic and also got ack from Rob
> 
> I knew all your logic of adding binding document for all MediaTek
> devices, even I alway added MediaTek device in dt-bindings as the way
> you mentioned here, but I felt this way is fine for this kind of
> dedicated document.
> 
> The reason i don't add it as usual is the following. 8250.txt is common
> and shared among all uart like devices, so i don't want btif device
> occupies too much section and bloat the document when every new MediaTek
> SoC is introduced.
> 
> So instead I refer to existing Nvidia device added in 8250.txt  which I
> thought its way is simple, elegant and also using pattern I can use to
> add btif devices.
> 

Working on my email backlog after vactions I didn't see that this was accepted 
by Rob. Sorry for the noise.

Matthias

[PATCH V2 0/2]

[Amanda Brindle]

In V2, fixed an error that did not list all packages if multiple packages were specified
on the command line.

The following changes since commit cf75fd5ae07355951b1f90d13842552a99e61063:

  contrib/yocto-bsp-kernel-update.sh: remove this script (2018-01-18 13:05:56 +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

[PATCH v2 0/2]

[Jacopo Mondi]

Hello,
   this small series add R-Mobile A1 R8A7740 to the list of CEU supported
SoCs, and adds the CEU node to r8a7740.dtsi.

All the information on CEU clocks, power domains and memory regions have been
deducted from the now-deleted board file:
arch/arm/mach-shmobile/board-armadillo800eva.c

Thanks
   j

v1 -> v2:
- Enlarge the memory range as suggested by Simon
- Fix power domain, as reported by Simon
- s/Enable/[Describe|Add] in commit message

Jacopo Mondi (2):
  dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740
  ARM: dts: r8a7740: Add CEU0

 Documentation/devicetree/bindings/media/renesas,ceu.txt |  7 ++++---
 arch/arm/boot/dts/r8a7740.dtsi                          | 10 ++++++++++
 drivers/media/platform/renesas-ceu.c                    |  1 +
 3 files changed, 15 insertions(+), 3 deletions(-)

--
2.7.4

[PATCH v2 0/2]

[Damien Robert]

Here is the version 2. I incorporated Jeff's preliminary patch, and handled
all push.default cases and added tests for them.

Damien Robert (1):
  remote.c: fix handling of %(push:remoteref)

Jeff King (1):
  remote: drop "explicit" parameter from remote_ref_for_branch()

 ref-filter.c            |   6 +--
 remote.c                | 113 +++++++++++++++++++++++++++++-----------
 remote.h                |   3 +-
 t/t6300-for-each-ref.sh |  29 ++++++++++-
 4 files changed, 115 insertions(+), 36 deletions(-)

-- 
Patched on top of v2.25.1-377-g2d2118b814 (git version 2.25.1)

[PATCH v2 0/2]

[Pavel Reichl]

 xfs: remove deprecated mount and sysctl options

Hi,

by Eric and Dave's suggestion I prepared a patchset which adds warnings about
using deprecated options. I tried to justify the changes in commit
messages based on the info from Eric and Dave.

If this patchsed should be merged I need to know when the options are
actually eliminated, so documentation can be properly updated.

Thanks.

V2 update:
Added comment to mount options that are being deprecated
Added Sep 2020 to documentation as a planned date of removal

Pavel Reichl (2):
  xfs: remove deprecated mount options
  xfs: remove deprecated sysctl options

 Documentation/admin-guide/xfs.rst |  5 ++++-
 fs/xfs/xfs_super.c                | 31 +++++++++++++++-----------
 fs/xfs/xfs_sysctl.c               | 36 +++++++++++++++++++++++++++++--
 3 files changed, 56 insertions(+), 16 deletions(-)

-- 
2.26.2

[PATCH v2 0/2]

[Steven Rostedt]

From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>

When writing code with libtracefs, I found that it would be very
convenient to have an easy way to enable and disable events.

This patch set adds:

  tracefs_event_enable()
  tracefs_event_disable()

to allow users to easily enable and disable events in their code.

Changes since v1:

  - free the regex of system and event if they are created.

Steven Rostedt (VMware) (2):
  libtracefs: Add tracefs_event_enable/disable() API
  libtracefs: Update the man page for tracefs_event_enable/disable()
    APIs

 Documentation/libtracefs-events.txt |  36 +++++++
 include/tracefs.h                   |   3 +
 src/tracefs-events.c                | 149 ++++++++++++++++++++++++++++
 3 files changed, 188 insertions(+)

-- 
2.29.2

Re: [PATCH v2 0/2]

[Steven Rostedt]

That's what I get for using git send email on this. I forgot to update the
subject :-p

-- Steve

[PATCH v2 0/2]

[bence.balogh]

From: Bence Balogh <bence.balogh@arm.com>

Changelog :
===========

v2:

* Apply 0043-firmware-psci-Fix-bind_smccc_features-psci-check.patch
  only to CS1K, instead of to all platforms.


Bence Balogh (2):
  arm-bsp/u-boot: corstone1000: fix SMCCC_ARCH_FEATURES detection in the
    PSCI driver
  arm-bsp/trusted-firmware-a: corstone1000: remove SMCCC_ARCH_FEATURES
    discovery workaround

 ...tone1000-pass-spsr-value-explicitly.patch} |  0
 ...URES-discovery-through-PSCI_FEATURES.patch | 29 ---------
 ...d-remove-EL3-interrupt-registration.patch} |  0
 .../trusted-firmware-a-corstone1000.inc       |  5 +-
 .../u-boot/u-boot-corstone1000.inc            |  1 +
 ...i-Fix-bind_smccc_features-psci-check.patch | 60 +++++++++++++++++++
 6 files changed, 63 insertions(+), 32 deletions(-)
 rename meta-arm-bsp/recipes-bsp/trusted-firmware-a/files/corstone1000/{0003-fix-corstone1000-pass-spsr-value-explicitly.patch => 0002-fix-corstone1000-pass-spsr-value-explicitly.patch} (100%)
 delete mode 100644 meta-arm-bsp/recipes-bsp/trusted-firmware-a/files/corstone1000/0002-psci-SMCCC_ARCH_FEATURES-discovery-through-PSCI_FEATURES.patch
 rename meta-arm-bsp/recipes-bsp/trusted-firmware-a/files/corstone1000/{0004-fix-spmd-remove-EL3-interrupt-registration.patch => 0003-fix-spmd-remove-EL3-interrupt-registration.patch} (100%)
 create mode 100644 meta-arm-bsp/recipes-bsp/u-boot/u-boot/corstone1000/0043-firmware-psci-Fix-bind_smccc_features-psci-check.patch

--
2.25.1

Re: [PATCH v2 0/2]

[Jon Mason]

On Thu, 14 Mar 2024 12:04:55 +0100, bence.balogh@arm.com wrote:
> From: Bence Balogh <bence.balogh@arm.com>
> 
> Changelog :
> ===========
> 
> v2:
> 
> [...]

Applied, thanks!

[1/2] arm-bsp/u-boot: corstone1000: fix SMCCC_ARCH_FEATURES detection in the PSCI driver
      commit: fb1a85a43c663d9e44047fc5e93af5c02c711c98
[2/2] arm-bsp/trusted-firmware-a: corstone1000: remove SMCCC_ARCH_FEATURES discovery workaround
      commit: 0792a314f623b4143652563d6db9a840b2b8226f

Best regards,
-- 
Jon Mason <jon.mason@arm.com>

[PATCH v2 0/2]

[Rex Chen]

[patch 1/2]
Update based on reviewer comments
[patch 2/2]
No change for patch 2

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

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

-- 
2.25.1