* Re: linux-next: Tree for May 14 (objtool 2/2)
From: Kees Cook @ 2020-05-29 19:30 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, Peter Zijlstra
In-Reply-To: <20200529175456.tbedus7okjrlkao7@treble>
On Fri, May 29, 2020 at 12:54:56PM -0500, Josh Poimboeuf wrote:
> On Thu, May 28, 2020 at 11:06:32PM -0700, Kees Cook wrote:
> > diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> > index 929211039bac..27bcc2568c95 100644
> > --- a/lib/Kconfig.ubsan
> > +++ b/lib/Kconfig.ubsan
> > @@ -63,7 +63,7 @@ config UBSAN_SANITIZE_ALL
> > config UBSAN_ALIGNMENT
> > bool "Enable checks for pointers alignment"
> > default !HAVE_EFFICIENT_UNALIGNED_ACCESS
> > - depends on !X86 || !COMPILE_TEST
> > + depends on !UBSAN_TRAP
> > help
> > This option enables the check of unaligned memory accesses.
> > Enabling this option on architectures that support unaligned
> >
> > How about that?
>
> But I thought you said the alignment traps might be useful on other
> arches? Should it be
>
> depends on !X86 || !UBSAN_TRAP
>
> ?
I was just trying to avoid objtool there, but really, UBSAN_TRAP is
likely insane for unaligned access checks entirely. If anyone ever needs
it, they can adjust. :)
--
Kees Cook
^ permalink raw reply
* [PATCH] lan743x: Added fixed link and RGMII support
From: Roelof Berg @ 2020-05-29 19:30 UTC (permalink / raw)
To: rberg
Cc: andrew, Bryan Whitehead, Microchip Linux Driver Support,
David S. Miller, netdev, linux-kernel
Microchip lan7431 is frequently connected to a phy. However, it
can also be directly connected to a MII remote peer without
any phy in between. For supporting such a phyless hardware setup
in Linux we utilized phylib, which supports a fixed-link
configuration via the device tree. And we added support for
defining the connection type R/GMII in the device tree.
New behavior:
-------------
. The automatic speed and duplex detection of the lan743x silicon
between mac and phy is disabled. Instead phylib is used like in
other typical Linux drivers. The usage of phylib allows to
specify fixed-link parameters in the device tree.
. The device tree entry phy-connection-type is supported now with
the modes RGMII or (G)MII (default).
Development state:
------------------
. Tested with fixed-phy configurations. Not yet tested in normal
configurations with phy. Microchip kindly offered testing
as soon as the Corona measures allow this.
. All review findings of Andrew Lunn are included
Example:
--------
&pcie {
status = "okay";
host@0 {
reg = <0 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
ethernet@0 {
compatible = "weyland-yutani,noscom1", "microchip,lan743x";
status = "okay";
reg = <0 0 0 0 0>;
phy-connection-type = "rgmii";
fixed-link {
speed = <100>;
full-duplex;
};
};
};
};
Signed-off-by: Roelof Berg <rberg@berg-solutions.de>
---
.../net/ethernet/microchip/lan743x_ethtool.c | 4 +-
drivers/net/ethernet/microchip/lan743x_main.c | 81 ++++++++++++++++---
drivers/net/ethernet/microchip/lan743x_main.h | 6 ++
drivers/net/ethernet/microchip/lan743x_ptp.c | 2 +-
4 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_ethtool.c b/drivers/net/ethernet/microchip/lan743x_ethtool.c
index 3a0b289d9771..c533d06fbe3a 100644
--- a/drivers/net/ethernet/microchip/lan743x_ethtool.c
+++ b/drivers/net/ethernet/microchip/lan743x_ethtool.c
@@ -2,11 +2,11 @@
/* Copyright (C) 2018 Microchip Technology Inc. */
#include <linux/netdevice.h>
-#include "lan743x_main.h"
-#include "lan743x_ethtool.h"
#include <linux/net_tstamp.h>
#include <linux/pci.h>
#include <linux/phy.h>
+#include "lan743x_main.h"
+#include "lan743x_ethtool.h"
/* eeprom */
#define LAN743X_EEPROM_MAGIC (0x74A5)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index a43140f7b5eb..36624e3c633b 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -8,7 +8,10 @@
#include <linux/crc32.h>
#include <linux/microchipphy.h>
#include <linux/net_tstamp.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include <linux/rtnetlink.h>
#include <linux/iopoll.h>
#include <linux/crc16.h>
@@ -798,9 +801,9 @@ static int lan743x_mac_init(struct lan743x_adapter *adapter)
netdev = adapter->netdev;
- /* setup auto duplex, and speed detection */
+ /* disable auto duplex, and speed detection. Phylib does that */
data = lan743x_csr_read(adapter, MAC_CR);
- data |= MAC_CR_ADD_ | MAC_CR_ASD_;
+ data &= ~(MAC_CR_ADD_ | MAC_CR_ASD_);
data |= MAC_CR_CNTR_RST_;
lan743x_csr_write(adapter, MAC_CR, data);
@@ -946,6 +949,7 @@ static void lan743x_phy_link_status_change(struct net_device *netdev)
{
struct lan743x_adapter *adapter = netdev_priv(netdev);
struct phy_device *phydev = netdev->phydev;
+ u32 data;
phy_print_status(phydev);
if (phydev->state == PHY_RUNNING) {
@@ -953,6 +957,39 @@ static void lan743x_phy_link_status_change(struct net_device *netdev)
int remote_advertisement = 0;
int local_advertisement = 0;
+ data = lan743x_csr_read(adapter, MAC_CR);
+
+ /* set interface mode */
+ if (phy_interface_mode_is_rgmii(adapter->phy_mode))
+ /* RGMII */
+ data &= ~MAC_CR_MII_EN_;
+ else
+ /* GMII */
+ data |= MAC_CR_MII_EN_;
+
+ /* set duplex mode */
+ if (phydev->duplex)
+ data |= MAC_CR_DPX_;
+ else
+ data &= ~MAC_CR_DPX_;
+
+ /* set bus speed */
+ switch (phydev->speed) {
+ case SPEED_10:
+ data &= ~MAC_CR_CFG_H_;
+ data &= ~MAC_CR_CFG_L_;
+ break;
+ case SPEED_100:
+ data &= ~MAC_CR_CFG_H_;
+ data |= MAC_CR_CFG_L_;
+ break;
+ case SPEED_1000:
+ data |= MAC_CR_CFG_H_;
+ data |= MAC_CR_CFG_L_;
+ break;
+ }
+ lan743x_csr_write(adapter, MAC_CR, data);
+
memset(&ksettings, 0, sizeof(ksettings));
phy_ethtool_get_link_ksettings(netdev, &ksettings);
local_advertisement =
@@ -980,20 +1017,44 @@ static void lan743x_phy_close(struct lan743x_adapter *adapter)
static int lan743x_phy_open(struct lan743x_adapter *adapter)
{
struct lan743x_phy *phy = &adapter->phy;
+ struct device_node *phynode;
struct phy_device *phydev;
struct net_device *netdev;
int ret = -EIO;
netdev = adapter->netdev;
- phydev = phy_find_first(adapter->mdiobus);
- if (!phydev)
- goto return_error;
+ phynode = of_node_get(adapter->pdev->dev.of_node);
+ adapter->phy_mode = PHY_INTERFACE_MODE_GMII;
+
+ if (phynode) {
+ of_get_phy_mode(phynode, &adapter->phy_mode);
+
+ if (of_phy_is_fixed_link(phynode)) {
+ ret = of_phy_register_fixed_link(phynode);
+ if (ret) {
+ netdev_err(netdev,
+ "cannot register fixed PHY\n");
+ of_node_put(phynode);
+ goto return_error;
+ }
+ }
+ phydev = of_phy_connect(netdev, phynode,
+ lan743x_phy_link_status_change, 0,
+ adapter->phy_mode);
+ of_node_put(phynode);
+ if (!phydev)
+ goto return_error;
+ } else {
+ phydev = phy_find_first(adapter->mdiobus);
+ if (!phydev)
+ goto return_error;
- ret = phy_connect_direct(netdev, phydev,
- lan743x_phy_link_status_change,
- PHY_INTERFACE_MODE_GMII);
- if (ret)
- goto return_error;
+ ret = phy_connect_direct(netdev, phydev,
+ lan743x_phy_link_status_change,
+ adapter->phy_mode);
+ if (ret)
+ goto return_error;
+ }
/* MAC doesn't support 1000T Half */
phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
diff --git a/drivers/net/ethernet/microchip/lan743x_main.h b/drivers/net/ethernet/microchip/lan743x_main.h
index 3b02eeae5f45..c61a40411317 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.h
+++ b/drivers/net/ethernet/microchip/lan743x_main.h
@@ -4,6 +4,7 @@
#ifndef _LAN743X_H
#define _LAN743X_H
+#include <linux/phy.h>
#include "lan743x_ptp.h"
#define DRIVER_AUTHOR "Bryan Whitehead <Bryan.Whitehead@microchip.com>"
@@ -104,10 +105,14 @@
((value << 0) & FCT_FLOW_CTL_ON_THRESHOLD_)
#define MAC_CR (0x100)
+#define MAC_CR_MII_EN_ BIT(19)
#define MAC_CR_EEE_EN_ BIT(17)
#define MAC_CR_ADD_ BIT(12)
#define MAC_CR_ASD_ BIT(11)
#define MAC_CR_CNTR_RST_ BIT(5)
+#define MAC_CR_DPX_ BIT(3)
+#define MAC_CR_CFG_H_ BIT(2)
+#define MAC_CR_CFG_L_ BIT(1)
#define MAC_CR_RST_ BIT(0)
#define MAC_RX (0x104)
@@ -698,6 +703,7 @@ struct lan743x_rx {
struct lan743x_adapter {
struct net_device *netdev;
struct mii_bus *mdiobus;
+ phy_interface_t phy_mode;
int msg_enable;
#ifdef CONFIG_PM
u32 wolopts;
diff --git a/drivers/net/ethernet/microchip/lan743x_ptp.c b/drivers/net/ethernet/microchip/lan743x_ptp.c
index 9399f6a98748..ab6d719d40f0 100644
--- a/drivers/net/ethernet/microchip/lan743x_ptp.c
+++ b/drivers/net/ethernet/microchip/lan743x_ptp.c
@@ -2,12 +2,12 @@
/* Copyright (C) 2018 Microchip Technology Inc. */
#include <linux/netdevice.h>
-#include "lan743x_main.h"
#include <linux/ptp_clock_kernel.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/net_tstamp.h>
+#include "lan743x_main.h"
#include "lan743x_ptp.h"
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v7 2/5] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer
From: Rob Herring @ 2020-05-29 19:30 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20200528145851.11791-1-jonathan.albrieux@gmail.com>
On Thu, May 28, 2020 at 04:58:47PM +0200, Jonathan Albrieux wrote:
> Converts documentation from txt format to yaml.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> .../bindings/iio/magnetometer/ak8975.txt | 37 ---------
> .../iio/magnetometer/asahi-kasei,ak8975.yaml | 77 +++++++++++++++++++
> 2 files changed, 77 insertions(+), 37 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> deleted file mode 100644
> index 0576b9df0bf2..000000000000
> --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -* AsahiKASEI AK8975 magnetometer sensor
> -
> -Required properties:
> -
> - - compatible : should be "asahi-kasei,ak8975".
> - - reg : the I2C address of the magnetometer.
> -
> -Optional properties:
> -
> - - gpios : AK8975 has a "Data ready" pin (DRDY) which informs that data
> - is ready to be read and is possible to listen on it. If used,
> - this should be active high. Prefer interrupt over this.
> -
> - - interrupts : interrupt for DRDY pin. Triggered on rising edge.
> -
> - - vdd-supply: an optional regulator that needs to be on to provide VDD.
> -
> - - mount-matrix: an optional 3x3 mounting rotation matrix.
> -
> -Example:
> -
> -ak8975@c {
> - compatible = "asahi-kasei,ak8975";
> - reg = <0x0c>;
> - interrupt-parent = <&gpio6>;
> - interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> - vdd-supply = <&ldo_3v3_gnss>;
> - mount-matrix = "-0.984807753012208", /* x0 */
> - "0", /* y0 */
> - "-0.173648177666930", /* z0 */
> - "0", /* x1 */
> - "-1", /* y1 */
> - "0", /* z1 */
> - "-0.173648177666930", /* x2 */
> - "0", /* y2 */
> - "0.984807753012208"; /* z2 */
> -};
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> new file mode 100644
> index 000000000000..55b18784e503
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/magnetometer/asahi-kasei,ak8975.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AsahiKASEI AK8975 magnetometer sensor
> +
> +maintainers:
> + - Jonathan Albrieux <jonathan.albrieux@gmail.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - asahi-kasei,ak8975
> + - asahi-kasei,ak8963
> + - asahi-kasei,ak09911
> + - asahi-kasei,ak09912
> + - enum:
> + - ak8975
> + - ak8963
> + - ak09911
> + - ak09912
> + deprecated: true
> +
> + reg:
> + maxItems: 1
> +
> + gpios:
> + maxItems: 1
> + description: |
> + AK8975 has a "Data ready" pin (DRDY) which informs that data
> + is ready to be read and is possible to listen on it. If used,
> + this should be active high. Prefer interrupt over this.
> +
> + interrupts:
> + maxItems: 1
> + description: interrupt for DRDY pin. Triggered on rising edge.
> +
> + vdd-supply:
> + maxItems: 1
Drop this. -supply is always 1.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] acpi: tpm: Do not build TCPA table for TPM 2
From: Stefan Berger @ 2020-05-29 19:28 UTC (permalink / raw)
To: qemu-devel, mst; +Cc: eric.auger, marcandre.lureau, Stefan Berger
From: Stefan Berger <stefanb@linux.ibm.com>
Do not build a TCPA table for TPM 2 anymore but create the log area when
building the TPM2 table. The TCPA table is only needed for TPM 1.2.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
hw/i386/acpi-build.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 2e15f6848e..b5669d6c65 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2317,6 +2317,10 @@ build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog)
tpm2_ptr->log_area_minimum_length =
cpu_to_le32(TPM_LOG_AREA_MINIMUM_SIZE);
+ acpi_data_push(tcpalog, le32_to_cpu(tpm2_ptr->log_area_minimum_length));
+ bios_linker_loader_alloc(linker, ACPI_BUILD_TPMLOG_FILE, tcpalog, 1,
+ false);
+
/* log area start address to be filled by Guest linker */
bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
log_addr_offset, log_addr_size,
@@ -2848,10 +2852,10 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
build_hpet(tables_blob, tables->linker);
}
if (misc.tpm_version != TPM_VERSION_UNSPEC) {
- acpi_add_table(table_offsets, tables_blob);
- build_tpm_tcpa(tables_blob, tables->linker, tables->tcpalog);
-
- if (misc.tpm_version == TPM_VERSION_2_0) {
+ if (misc.tpm_version == TPM_VERSION_1_2) {
+ acpi_add_table(table_offsets, tables_blob);
+ build_tpm_tcpa(tables_blob, tables->linker, tables->tcpalog);
+ } else { /* TPM_VERSION_2_0 */
acpi_add_table(table_offsets, tables_blob);
build_tpm2(tables_blob, tables->linker, tables->tcpalog);
}
--
2.24.1
^ permalink raw reply related
* [PATCH] drivers: GHES_ASSIST feature cause kernel to have a 5ms scheduling latency on AMD ROME's platform
From: dianruihui @ 2020-05-29 19:13 UTC (permalink / raw)
To: ruihui.dian, rjw, lenb, linux-acpi; +Cc: Ruihui Dian
From: Ruihui Dian <dianruihui@163.com>
AMD ROME's BIOS implement a feature(GHES_ASSIST)which is
declared in ACPI 6.3,and can't be disabled by BIOS setting.
This feature make kerenl register more than 10K poll timer.
There are more than 10K GHESdevices under
"/sys/bus/platform/drivers/GHES". These 10K timers will
preempt the CPU resources and affect kernel's schedule.
How to reproduce:
running cyclictest benchmark on AMD ROME platform
GHES_ASSIST still don't be supported by upsteam, and the
ACPI 6.2 still isn't published, So we should disable it
in drivers.
Signed-off-by: Ruihui Dian <dianruihui@163.com>
---
drivers/acpi/apei/hest.c | 10 ++++++----
include/acpi/actbl1.h | 3 ++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 8224024..f929bab 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -141,8 +141,9 @@ static int __init hest_parse_ghes_count(struct acpi_hest_header *hest_hdr, void
{
int *count = data;
- if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR ||
- hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2)
+ if ((hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR &&
+ !(hest_hdr->source_id&ACPI_HEST_GHES_ASSIST_MSK)) ||
+ hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2)
(*count)++;
return 0;
}
@@ -153,8 +154,9 @@ static int __init hest_parse_ghes(struct acpi_hest_header *hest_hdr, void *data)
struct ghes_arr *ghes_arr = data;
int rc, i;
- if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR &&
- hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2)
+ if ((hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR &&
+ hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2) ||
+ hest_hdr->source_id&CPI_HEST_GHES_ASSIST_MSK)
return 0;
if (!((struct acpi_hest_generic *)hest_hdr)->enabled)
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 4354954..5dbbab4 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -1155,7 +1155,8 @@ struct acpi_hest_aer_common {
#define ACPI_HEST_FIRMWARE_FIRST (1)
#define ACPI_HEST_GLOBAL (1<<1)
#define ACPI_HEST_GHES_ASSIST (1<<2)
-
+/* If type==9 and Source ID bit [15:12] =!0, It is GHES_ASSIT structure*/
+#define ACPI_HEST_GHES_ASSIST_MSK (0xF000)
/*
* Macros to access the bus/segment numbers in Bus field above:
* Bus number is encoded in bits 7:0
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: chrome: Add cros-ec-typec mux props
From: Prashant Malani @ 2020-05-29 19:28 UTC (permalink / raw)
To: Linux Kernel Mailing List, Rob Herring
Cc: Heikki Krogerus, Benson Leung,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Enric Balletbo i Serra, Guenter Roeck
In-Reply-To: <20200519214604.180036-1-pmalani@chromium.org>
Hi Rob,
Would you prefer these switches to be defined in the
usb-connector.yaml bindings file?
If there are no other concerns, I can push a fresh version of the
patch with the properties defined in usb-connector.yaml.
Thanks,
On Tue, May 19, 2020 at 2:46 PM Prashant Malani <pmalani@chromium.org> wrote:
>
> Add properties for mode, orientation and USB data role switches for
> Type C connectors. When available, these will allow the Type C connector
> class port driver to configure the various switches according to USB PD
> information (like orientation, alt mode etc.) provided by the Chrome OS
> EC controller.
>
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
> Acked-by: Benson Leung <bleung@chromium.org>
> ---
>
> Changes in v3:
> - Fixed Acked-by tag typo.
>
> Changes in v2:
> - Added more text to the switch descriptions, explaining their purpose,
> and relation to the Type C connector class framework.
>
> .../bindings/chrome/google,cros-ec-typec.yaml | 40 ++++++++++++++++++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> index 6d7396ab8bee..800c005a0e44 100644
> --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> @@ -21,7 +21,34 @@ properties:
> const: google,cros-ec-typec
>
> connector:
> - $ref: /schemas/connector/usb-connector.yaml#
> + allOf:
> + - $ref: /schemas/connector/usb-connector.yaml#
> + - type: object
> + properties:
> + mode-switch:
> + description: Reference to a DT node for the USB Type C Multiplexer
> + for this connector. This switch controls the data lines routing
> + for this connector for various operation modes, including
> + Alternate Modes. This switch is assumed registered with the Type C
> + connector class framework by its driver. The Type C connector
> + class framework assumes that the mode switch property uses this
> + name.
> +
> + orientation-switch:
> + description: Reference to a DT node for the USB Type C orientation
> + switch for this connector. This switch controls routing the
> + correct data pairs depending on the cable plug orientation from
> + this connector to the USB / Alternate Mode controllers. This
> + switch is assumed registered with the Type C connector class
> + framework by its driver. The Type C connector class framework
> + assumes that the orientation switch property uses this name.
> +
> + usb-role-switch:
> + description: Reference to a DT node for the USB Data role switch
> + for this connector. This switch is assumed registered with the
> + Type C connector class framework by its driver. The Type C
> + connector class framework assumes that the USB role switch
> + property uses this name.
>
> required:
> - compatible
> @@ -49,6 +76,17 @@ examples:
> data-role = "dual";
> try-power-role = "source";
> };
> +
> + connector@1 {
> + compatible = "usb-c-connector";
> + reg = <1>;
> + power-role = "dual";
> + data-role = "host";
> + try-power-role = "source";
> + mode-switch = <&typec_mux>;
> + orientation-switch = <&typec_orientation_switch>;
> + usb-role-switch = <&typec_mux>;
> + };
> };
> };
> };
> --
> 2.26.2.761.g0e0b3e54be-goog
>
^ permalink raw reply
* [Linux-kernel-mentees] [PATCH] kunit: Fix TabError, remove defconfig code and handle when there is no kunitconfig
From: Vitor Massaru Iha @ 2020-05-29 19:28 UTC (permalink / raw)
To: kunit-dev, skhan
Cc: linux-kernel-mentees, brendanhiggins, linux-kernel,
linux-kselftest
The identation before this code (`if not os.path.exists(cli_args.build_dir):``)
was with spaces instead of tabs after fixed up merge conflits,
this commit revert spaces to tabs:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
File "tools/testing/kunit/kunit.py", line 247
if not linux:
^
TabError: inconsistent use of tabs and spaces in indentation
Remove defconfig related code to fix these two errors,
the commit 9bdf64b35 was created before 45ba7a893ad,
and the commit 9bdf64b35 removes defconfig related code:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 338, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 215, in main
add_config_opts(config_parser)
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 337, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 255, in main
result = run_tests(linux, request)
File "tools/testing/kunit/kunit.py", line 133, in run_tests
request.defconfig,
AttributeError: 'KunitRequest' object has no attribute 'defconfig'
Handles when there is no .kunitconfig, the error occurs because
commit 9bdf64b35 was created before 45ba7a893ad.
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 335, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 246, in main
linux = kunit_kernel.LinuxSourceTree()
File "/home/iha/sdb/opensource/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 109, in __init__
self._kconfig.read_from_file(kunitconfig_path)
File "/home/iha/sdb/opensource/lkmp/linux/tools/testing/kunit/kunit_config.py", line 88, in read_from_file
with open(path, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: '.kunit/.kunitconfig'
Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>
---
Fix the fixup on this commits: 9bdf64b, ddbd60c.
Some errors occurs because these commits were created before
this commit 45ba7a8, as explained in the commit message.
---
tools/testing/kunit/kunit.py | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index ec73b07d1265..787b6d4ad716 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -23,7 +23,7 @@ import kunit_parser
KunitResult = namedtuple('KunitResult', ['status','result','elapsed_time'])
KunitConfigRequest = namedtuple('KunitConfigRequest',
- ['build_dir', 'defconfig', 'make_options'])
+ ['build_dir', 'make_options'])
KunitBuildRequest = namedtuple('KunitBuildRequest',
['jobs', 'build_dir', 'alltests',
'make_options'])
@@ -130,7 +130,6 @@ def run_tests(linux: kunit_kernel.LinuxSourceTree,
run_start = time.time()
config_request = KunitConfigRequest(request.build_dir,
- request.defconfig,
request.make_options)
config_result = config_tests(linux, config_request)
if config_result.status != KunitStatus.SUCCESS:
@@ -212,7 +211,6 @@ def main(argv, linux=None):
help='Ensures that .config contains all of '
'the options in .kunitconfig')
add_common_opts(config_parser)
- add_config_opts(config_parser)
build_parser = subparser.add_parser('build', help='Builds a kernel with KUnit tests')
add_common_opts(build_parser)
@@ -238,11 +236,14 @@ def main(argv, linux=None):
cli_args = parser.parse_args(argv)
if cli_args.subcommand == 'run':
- if not os.path.exists(cli_args.build_dir):
- os.mkdir(cli_args.build_dir)
- kunit_kernel.kunitconfig_path = os.path.join(
- cli_args.build_dir,
- kunit_kernel.kunitconfig_path)
+ if not os.path.exists(cli_args.build_dir):
+ os.mkdir(cli_args.build_dir)
+ kunit_kernel.kunitconfig_path = os.path.join(
+ cli_args.build_dir,
+ kunit_kernel.kunitconfig_path)
+
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
if not linux:
linux = kunit_kernel.LinuxSourceTree()
@@ -264,11 +265,13 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
request = KunitConfigRequest(cli_args.build_dir,
- cli_args.defconfig,
cli_args.make_options)
result = config_tests(linux, request)
kunit_parser.print_with_timestamp((
@@ -284,6 +287,9 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
@@ -305,6 +311,9 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
--
2.26.2
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related
* [PATCH] kunit: Fix TabError, remove defconfig code and handle when there is no kunitconfig
From: Vitor Massaru Iha @ 2020-05-29 19:28 UTC (permalink / raw)
To: kunit-dev, skhan
Cc: linux-kselftest, linux-kernel, brendanhiggins,
linux-kernel-mentees
The identation before this code (`if not os.path.exists(cli_args.build_dir):``)
was with spaces instead of tabs after fixed up merge conflits,
this commit revert spaces to tabs:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
File "tools/testing/kunit/kunit.py", line 247
if not linux:
^
TabError: inconsistent use of tabs and spaces in indentation
Remove defconfig related code to fix these two errors,
the commit 9bdf64b35 was created before 45ba7a893ad,
and the commit 9bdf64b35 removes defconfig related code:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 338, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 215, in main
add_config_opts(config_parser)
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 337, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 255, in main
result = run_tests(linux, request)
File "tools/testing/kunit/kunit.py", line 133, in run_tests
request.defconfig,
AttributeError: 'KunitRequest' object has no attribute 'defconfig'
Handles when there is no .kunitconfig, the error occurs because
commit 9bdf64b35 was created before 45ba7a893ad.
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 335, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 246, in main
linux = kunit_kernel.LinuxSourceTree()
File "/home/iha/sdb/opensource/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 109, in __init__
self._kconfig.read_from_file(kunitconfig_path)
File "/home/iha/sdb/opensource/lkmp/linux/tools/testing/kunit/kunit_config.py", line 88, in read_from_file
with open(path, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: '.kunit/.kunitconfig'
Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>
---
Fix the fixup on this commits: 9bdf64b, ddbd60c.
Some errors occurs because these commits were created before
this commit 45ba7a8, as explained in the commit message.
---
tools/testing/kunit/kunit.py | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index ec73b07d1265..787b6d4ad716 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -23,7 +23,7 @@ import kunit_parser
KunitResult = namedtuple('KunitResult', ['status','result','elapsed_time'])
KunitConfigRequest = namedtuple('KunitConfigRequest',
- ['build_dir', 'defconfig', 'make_options'])
+ ['build_dir', 'make_options'])
KunitBuildRequest = namedtuple('KunitBuildRequest',
['jobs', 'build_dir', 'alltests',
'make_options'])
@@ -130,7 +130,6 @@ def run_tests(linux: kunit_kernel.LinuxSourceTree,
run_start = time.time()
config_request = KunitConfigRequest(request.build_dir,
- request.defconfig,
request.make_options)
config_result = config_tests(linux, config_request)
if config_result.status != KunitStatus.SUCCESS:
@@ -212,7 +211,6 @@ def main(argv, linux=None):
help='Ensures that .config contains all of '
'the options in .kunitconfig')
add_common_opts(config_parser)
- add_config_opts(config_parser)
build_parser = subparser.add_parser('build', help='Builds a kernel with KUnit tests')
add_common_opts(build_parser)
@@ -238,11 +236,14 @@ def main(argv, linux=None):
cli_args = parser.parse_args(argv)
if cli_args.subcommand == 'run':
- if not os.path.exists(cli_args.build_dir):
- os.mkdir(cli_args.build_dir)
- kunit_kernel.kunitconfig_path = os.path.join(
- cli_args.build_dir,
- kunit_kernel.kunitconfig_path)
+ if not os.path.exists(cli_args.build_dir):
+ os.mkdir(cli_args.build_dir)
+ kunit_kernel.kunitconfig_path = os.path.join(
+ cli_args.build_dir,
+ kunit_kernel.kunitconfig_path)
+
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
if not linux:
linux = kunit_kernel.LinuxSourceTree()
@@ -264,11 +265,13 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
request = KunitConfigRequest(cli_args.build_dir,
- cli_args.defconfig,
cli_args.make_options)
result = config_tests(linux, request)
kunit_parser.print_with_timestamp((
@@ -284,6 +287,9 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
@@ -305,6 +311,9 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3 2/8] cmake: generate the shell/perl/python scripts and templates, translations
From: Junio C Hamano @ 2020-05-29 19:27 UTC (permalink / raw)
To: Sibi Siddharthan via GitGitGadget; +Cc: git, Sibi Siddharthan
In-Reply-To: <f19794fdbc09cc3c57392dc522920f7b01691d88.1590759624.git.gitgitgadget@gmail.com>
"Sibi Siddharthan via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
>
> Implement the placeholder substitution to generate scripted
> Porcelain commands, e.g. git-request-pull out of
> git-request-pull.sh
>
> Generate shell/perl/python scripts and template using CMake instead of
> using sed like the build procedure in the Makefile does.
>
> The text translations are only build if `msgfmt` is found in your path.
>
> NOTE: The scripts and templates are generated during configuration.
OK.
> Changes
> The CMake script parses the Makefile for:
> SCRIPT_SH
> SCRIPT_PERL
Below the three-dash line.
> +#shell scripts
> +parse_makefile_for_scripts(git_sh_scripts "SCRIPT_SH" ".sh")
OK.
> +set(git_shell_scripts
> + ${git_sh_scripts}
> + git-mergetool--lib git-parse-remote git-rebase--preserve-merges
> + git-sh-setup git-sh-i18n git-instaweb)
Do we need to have enumeration here, which can drift out of sync
with the reality? Wouldn't we want to avoid it with something like
parse_makefile_for_scripts(git_sh_lib "SCRIPT_LIB" "")
too?
> +#perl modules
> +file(GLOB_RECURSE perl_modules "${CMAKE_SOURCE_DIR}/perl/*.pm")
> +
> +foreach(pm ${perl_modules})
> + string(REPLACE "${CMAKE_SOURCE_DIR}/perl/" "" file_path ${pm})
> + file(STRINGS ${pm} content NEWLINE_CONSUME)
> + string(REPLACE "@@LOCALEDIR@@" "${LOCALEDIR}" content "${content}")
> + string(REPLACE "@@NO_PERL_CPAN_FALLBACKS@@" "" content "${content}")
> + file(WRITE ${CMAKE_BINARY_DIR}/perl/build/lib/${file_path} ${content})
> +#test-lib.sh requires perl/build/lib to be the build directory of perl modules
> +endforeach()
> +
> +
> +#templates
> +file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/templates/blt/branches) #create branches
> +set(hooks_templates
> + applypatch-msg.sample pre-applypatch.sample pre-push.sample
> + commit-msg.sample pre-commit.sample pre-rebase.sample
> + fsmonitor-watchman.sample pre-merge-commit.sample pre-receive.sample
> + post-update.sample prepare-commit-msg.sample update.sample)
Do we need to have enumeration here, which can drift out of sync
with the reality? Wouldn't we want to avoid it with file(GLOB) or
something?
> +#templates have @.*@ replacement so use configure_file instead
> +#hooks
> +foreach(tm ${hooks_templates})
> + configure_file(${CMAKE_SOURCE_DIR}/templates/hooks--${tm} ${CMAKE_BINARY_DIR}/templates/blt/hooks/${tm} @ONLY)
> +endforeach()
> +
> +#info
> +configure_file(${CMAKE_SOURCE_DIR}/templates/info--exclude ${CMAKE_BINARY_DIR}/templates/blt/info/exclude @ONLY)
> +
> +#this
> +configure_file(${CMAKE_SOURCE_DIR}/templates/this--description ${CMAKE_BINARY_DIR}/templates/blt/description @ONLY)
I was hoping that we could drive any build system without having to
have separate rules like the above. The idea behind all files with
funny double-dash in its name under templates/ directory is:
- double-dash denotes directory boundary
- when a template input ends with double-dash, it tells us to
create a directory
- leading "this--" denotes "not in a subdirectory but at the top
level of the generated template directory"
so that each of them knows what the name of the file and directory
hierarchy of the final destination is, and the result of transforming
can be created and deposited at the final place mechanically with a
single rule.
> +#translations
> +if(MSGFMT_EXE)
> + set(po_files bg ca de el es fr is it ko pt_PT ru sv tr vi zh_CN zh_TW)
Do we need to have enumeration here, which can drift out of sync
with the reality? Wouldn't globbing for *.po be sufficient?
> + foreach(po ${po_files})
> + file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES)
> + add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo
> + COMMAND ${MSGFMT_EXE} --check --statistics -o ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo ${CMAKE_SOURCE_DIR}/po/${po}.po)
> + list(APPEND po_gen ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo)
> + endforeach()
> + add_custom_target(po-gen ALL DEPENDS ${po_gen})
> +endif()
Thanks.
^ permalink raw reply
* Re: [PATCH v3 1/8] Introduce CMake support for configuring Git
From: Junio C Hamano @ 2020-05-29 19:27 UTC (permalink / raw)
To: Sibi Siddharthan via GitGitGadget; +Cc: git, Sibi Siddharthan
In-Reply-To: <09c972de52b35b14a4c6f44b10c3dfc1732b2c7a.1590759624.git.gitgitgadget@gmail.com>
"Sibi Siddharthan via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
>
> At the moment, the recommended way to configure Git's builds is to
> ...
> Note: this patch asks for the minimum version v3.14 of CMake (which is
> not all that old as of time of writing) because that is the first
> version to offer a platform-independent way to generate hardlinks as
> part of the build. This is needed to generate all those hardlinks for
> the built-in commands of Git.
All of the above reads reasonable.
> Changes
> The CMake script parses the Makefile for:
> LIB_OBJS
> BUILTIN_OBJS
> XDIFF_OBJS
> VCSSVN_OBJS
> TEST_BUILTINS_OBJS
>
> By doing this we avoid duplication of text between the Makefile and
> the CMake script.
>
> The CMake script has been relocated to contrib/buildsystems.
>
> The CMake script uses GIT-VERSION-GEN to determine the version of Git
> being built.
Everything after the "Changes" line does not belong to the commit
log, as it is no use for those who read "git log" output and
encounter the "first" attempt to add CMake support there. There is
no need to tell them that you did things differently from this
version in the past, as they simply do not know what you did in the
previous iterations, nor particularly care about them.
These *do* help reviewers who saw previous iterations, and the space
after the three-dash line below is the right/recommended place for
them.
The above applies to other patches in this series.
> Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
> ---
> contrib/buildsystems/CMakeLists.txt | 575 ++++++++++++++++++++++++++++
> 1 file changed, 575 insertions(+)
> create mode 100644 contrib/buildsystems/CMakeLists.txt
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> new file mode 100644
> index 00000000000..8e2b27f44a6
> --- /dev/null
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -0,0 +1,575 @@
> +#
> +# Copyright (c) 2020 Sibi Siddharthan
> +#
> +
> +#[[
> +
> +Instructions to run CMake:
> +
> +cmake `relative-path-to-CMakeLists.txt` -DCMAKE_BUILD_TYPE=Release
The readers can infer from `relative-path-to-CMakeLists` that they
can run this command from anywhere, e.g.
$ cd $HOME
$ tar xf /var/tmp/git-2.7.0.tar
$ cd /tmp
$ cmake $HOME/git/contrib/buildsystems/CMakeLists.txt
but when given the freedom/flexibility to use it from "anywhere",
they are faced by an extra choice to make. It may be helpful to
readers to elaborate a bit more to help them decide where in the
directory hierarchy they would want to run this command. In the
above example sequence, I chose /tmp, but if I used /var/tmp as the
starting place instead, what becomes different? The answer might
be "resulting 'git' binary is stored in the directory you run the
'cmake' command in", and by spelling it out, it helps readers to
make an informed decision.
> +Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
> +compiler flags
> +Debug : -g
> +Release: -O3
> +RelWithDebInfo : -O2 -g
> +MinSizeRel : -Os
> +empty(default) :
> +
> +NOTE: -DCMAKE_BUILD_TYPE is optional. For multi-config generators like Visual Studio
> +this option is ignored
Quite helpful.
> +This process generates a Makefile(Linux) , Visual Studio solution(Windows) by default.
> +Run `make` to build Git on Linux.
> +Open git.sln on Windows and build Git.
> +
> +NOTE: By default CMake uses Makefile as the build tool on Linux and Visual Studio in Windows,
The above makes it sound as if Linux and VS are the only two systems
we care about, but is it really Linux, or UNIX-flavoured systems in
general? In other words, are we excluding friends on BSD and macOS
with the above?
The above is not a complaint about "exclusion", but is a complaint
about unclarity.
> +to use another tool say `ninja` add this to the command line when configuring.
> +`-G Ninja`
> +
> +]]
> +cmake_minimum_required(VERSION 3.14)
> ...
> +check_c_source_compiles("
The "source" given to check_c_source_{compiles,runs} may be allowed
to be anything, but I'd prefer to see it follow some consistent
style, preferrably our CodingGuidelines (except for git specific
bits like "do not include standard system file but instead just use
git-compat-util.h", which of course should not apply). This is a
comment not only about the two instances below I use as examples,
but all C-source snippets in this patch.
> +#include <alloca.h>
> +int
> +main ()
> +{
int main(void)
{
is how we start this function.
> +char *p = (char *) alloca (2 * sizeof (int));
And the decl of function local variable here would be indented by a
HT like the remainder of the function. No SP between function name
and the parentheses around its arguments. NP SP after sizeof,
either.
> + if (p) return 0;
> + return 0;
> +}"
> +HAVE_ALLOCA_H)
> ...
> +check_c_source_runs("
> +#include<stdio.h>
> +#include<stdarg.h>
> +#include<string.h>
> +#include<stdlib.h>
> +int test_vsnprintf(char *str, size_t maxsize, const char *format, ...)
> +{
> + int ret;
> + va_list ap;
> +
> + va_start(ap, format);
> + ret = vsnprintf(str, maxsize, format, ap);
> + va_end(ap);
> + return ret;
> +}
> +
> +int
> +main ()
> +{
Likewise.
> + char buf[6];
> + if (test_vsnprintf(buf, 3, \"%s\", \"12345\") != 5
> + || strcmp(buf, \"12\")) return 1;
> + if (snprintf(buf, 3, \"%s\", \"12345\") != 5
> + || strcmp(buf, \"12\")) return 1;
> +
> + return 0;
> +}"
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] dt-bindings: net: rename the bindings document for MediaTek STAR EMAC
From: Rob Herring @ 2020-05-29 19:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: devicetree, Stephane Le Provost, Fabien Parent, Pedro Tsai,
linux-kernel, Bartosz Golaszewski, Rob Herring, linux-mediatek,
Andrew Perepech, netdev, Matthias Brugger, Jakub Kicinski,
David S . Miller, linux-arm-kernel
In-Reply-To: <20200528135902.14041-1-brgl@bgdev.pl>
On Thu, 28 May 2020 15:59:02 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The driver itself was renamed before getting merged into mainline, but
> the binding document kept the old name. This makes both names consistent.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - update the id field as well
>
> .../net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} (96%)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH net-next v2] dt-bindings: net: rename the bindings document for MediaTek STAR EMAC
From: Rob Herring @ 2020-05-29 19:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: devicetree, Stephane Le Provost, Fabien Parent, Pedro Tsai,
linux-kernel, Bartosz Golaszewski, Rob Herring, linux-mediatek,
Andrew Perepech, netdev, Matthias Brugger, Jakub Kicinski,
David S . Miller, linux-arm-kernel
In-Reply-To: <20200528135902.14041-1-brgl@bgdev.pl>
On Thu, 28 May 2020 15:59:02 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The driver itself was renamed before getting merged into mainline, but
> the binding document kept the old name. This makes both names consistent.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - update the id field as well
>
> .../net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} (96%)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: linux-next: manual merge of the nfsd tree with the nfs-anna tree
From: Chuck Lever @ 2020-05-29 19:27 UTC (permalink / raw)
To: Stephen Rothwell, Bruce Fields
Cc: Anna Schumaker, Trond Myklebust, Linux NFS Mailing List,
Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20200529105917.50dfc40f@canb.auug.org.au>
> On May 28, 2020, at 8:59 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the nfsd tree got a conflict in:
>
> include/trace/events/sunrpc.h
>
> between commit:
>
> 2baebf955125 ("SUNRPC: Split the xdr_buf event class")
>
> from the nfs-anna tree and commit:
>
> 998024dee197 ("SUNRPC: Add more svcsock tracepoints")
>
> from the nfsd tree.
Alternately, I can provide a v4 nfsd-5.8 series for Bruce that
includes 2baebf955125 ("SUNRPC: Split the xdr_buf event class")
so that these merge conflicts are avoided.
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc include/trace/events/sunrpc.h
> index 73193c79fcaa,852413cbb7d9..000000000000
> --- a/include/trace/events/sunrpc.h
> +++ b/include/trace/events/sunrpc.h
> @@@ -14,9 -14,41 +14,42 @@@
> #include <linux/net.h>
> #include <linux/tracepoint.h>
>
> + TRACE_DEFINE_ENUM(SOCK_STREAM);
> + TRACE_DEFINE_ENUM(SOCK_DGRAM);
> + TRACE_DEFINE_ENUM(SOCK_RAW);
> + TRACE_DEFINE_ENUM(SOCK_RDM);
> + TRACE_DEFINE_ENUM(SOCK_SEQPACKET);
> + TRACE_DEFINE_ENUM(SOCK_DCCP);
> + TRACE_DEFINE_ENUM(SOCK_PACKET);
> +
> + #define show_socket_type(type) \
> + __print_symbolic(type, \
> + { SOCK_STREAM, "STREAM" }, \
> + { SOCK_DGRAM, "DGRAM" }, \
> + { SOCK_RAW, "RAW" }, \
> + { SOCK_RDM, "RDM" }, \
> + { SOCK_SEQPACKET, "SEQPACKET" }, \
> + { SOCK_DCCP, "DCCP" }, \
> + { SOCK_PACKET, "PACKET" })
> +
> + /* This list is known to be incomplete, add new enums as needed. */
> + TRACE_DEFINE_ENUM(AF_UNSPEC);
> + TRACE_DEFINE_ENUM(AF_UNIX);
> + TRACE_DEFINE_ENUM(AF_LOCAL);
> + TRACE_DEFINE_ENUM(AF_INET);
> + TRACE_DEFINE_ENUM(AF_INET6);
> +
> + #define rpc_show_address_family(family) \
> + __print_symbolic(family, \
> + { AF_UNSPEC, "AF_UNSPEC" }, \
> + { AF_UNIX, "AF_UNIX" }, \
> + { AF_LOCAL, "AF_LOCAL" }, \
> + { AF_INET, "AF_INET" }, \
> + { AF_INET6, "AF_INET6" })
> +
> -DECLARE_EVENT_CLASS(xdr_buf_class,
> +DECLARE_EVENT_CLASS(rpc_xdr_buf_class,
> TP_PROTO(
> + const struct rpc_task *task,
> const struct xdr_buf *xdr
> ),
>
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH net-next v2] dt-bindings: net: rename the bindings document for MediaTek STAR EMAC
From: Rob Herring @ 2020-05-29 19:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Pedro Tsai, Matthias Brugger, linux-arm-kernel,
Bartosz Golaszewski, linux-kernel, linux-mediatek, Fabien Parent,
David S . Miller, netdev, Stephane Le Provost, Jakub Kicinski,
Andrew Perepech, Rob Herring, devicetree
In-Reply-To: <20200528135902.14041-1-brgl@bgdev.pl>
On Thu, 28 May 2020 15:59:02 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The driver itself was renamed before getting merged into mainline, but
> the binding document kept the old name. This makes both names consistent.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - update the id field as well
>
> .../net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} (96%)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* drivers/gpu/drm/mgag200/mgag200_drv.c:70:5: warning: no previous prototype for function 'mgag200_driver_dumb_create'
From: kbuild test robot @ 2020-05-29 19:27 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 75caf310d16cc5e2f851c048cd597f5437013368
commit: 1591fadf857cdbaf2baa55e421af99a61354713c drm/mgag200: Add workaround for HW that does not support 'startadd'
date: 6 months ago
config: arm-randconfig-r036-20200529 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 2d068e534f1671459e1b135852c1b3c10502e929)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
git checkout 1591fadf857cdbaf2baa55e421af99a61354713c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/gpu/drm/mgag200/mgag200_drv.c:70:5: warning: no previous prototype for function 'mgag200_driver_dumb_create' [-Wmissing-prototypes]
int mgag200_driver_dumb_create(struct drm_file *file,
^
drivers/gpu/drm/mgag200/mgag200_drv.c:70:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int mgag200_driver_dumb_create(struct drm_file *file,
^
static
1 warning generated.
vim +/mgag200_driver_dumb_create +70 drivers/gpu/drm/mgag200/mgag200_drv.c
69
> 70 int mgag200_driver_dumb_create(struct drm_file *file,
71 struct drm_device *dev,
72 struct drm_mode_create_dumb *args)
73 {
74 struct mga_device *mdev = dev->dev_private;
75 unsigned long pg_align;
76
77 if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
78 return -EINVAL;
79
80 pg_align = 0ul;
81
82 /*
83 * Aligning scanout buffers to the size of the video ram forces
84 * placement at offset 0. Works around a bug where HW does not
85 * respect 'startadd' field.
86 */
87 if (mgag200_pin_bo_at_0(mdev))
88 pg_align = PFN_UP(mdev->mc.vram_size);
89
90 return drm_gem_vram_fill_create_dumb(file, dev, &dev->vram_mm->bdev,
91 pg_align, false, args);
92 }
93
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 33154 bytes --]
^ permalink raw reply
* Re: new seccomp mode aims to improve performance
From: Kees Cook @ 2020-05-29 19:27 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: zhujianwei (C), bpf@vger.kernel.org,
linux-security-module@vger.kernel.org, Hehuazhen,
Lennart Poettering, Christian Ehrhardt,
Zbigniew Jędrzejewski-Szmek
In-Reply-To: <202005290903.11E67AB0FD@keescook>
On Fri, May 29, 2020 at 09:09:28AM -0700, Kees Cook wrote:
> On Fri, May 29, 2020 at 08:43:56AM -0700, Alexei Starovoitov wrote:
> > I don't think your hunch at where cpu is spending cycles is correct.
> > Could you please do two experiments:
> > 1. try trivial seccomp bpf prog that simply returns 'allow'
> > 2. replace bpf_prog_run_pin_on_cpu() in seccomp.c with C code
> > that returns 'allow' and make sure it's noinline or in a different C file,
> > so that compiler doesn't optimize the whole seccomp_run_filters() into a nop.
> >
> > Then measure performance of both.
> > I bet you'll see exactly the same numbers.
>
> Android has already done this, it appeared to not be the same. Calling
> into a SECCOMP_RET_ALLOW filter had a surprisingly high cost. I'll see
> if I can get you the numbers. I was frankly quite surprised -- I
> understood the bulk of the seccomp overhead to be in taking the TIF_WORK
> path, copying arguments, etc, but something else is going on there.
So while it's not the Android measurements, here's what I'm seeing on
x86_64 (this is hardly a perfect noiseless benchmark, but sampling error
appears to close to 1%):
net.core.bpf_jit_enable=0:
Benchmarking 16777216 samples...
10.633756139 - 0.004359714 = 10629396425
getpid native: 633 ns
23.008737499 - 10.633967641 = 12374769858
getpid RET_ALLOW 1 filter: 737 ns
36.723141843 - 23.008975696 = 13714166147
getpid RET_ALLOW 2 filters: 817 ns
47.751422021 - 36.723345630 = 11028076391
getpid BPF-less allow: 657 ns
Estimated total seccomp overhead for 1 filter: 104 ns
Estimated total seccomp overhead for 2 filters: 184 ns
Estimated seccomp per-filter overhead: 80 ns
Estimated seccomp entry overhead: 24 ns
Estimated BPF overhead per filter: 80 ns
net.core.bpf_jit_enable=1:
net.core.bpf_jit_harden=1:
Benchmarking 16777216 samples...
31.939978606 - 21.275190689 = 10664787917
getpid native: 635 ns
43.324592380 - 31.940794751 = 11383797629
getpid RET_ALLOW 1 filter: 678 ns
55.001650599 - 43.326293248 = 11675357351
getpid RET_ALLOW 2 filters: 695 ns
65.986452855 - 55.002249904 = 10984202951
getpid BPF-less allow: 654 ns
Estimated total seccomp overhead for 1 filter: 43 ns
Estimated total seccomp overhead for 2 filters: 60 ns
Estimated seccomp per-filter overhead: 17 ns
Estimated seccomp entry overhead: 26 ns
Estimated BPF overhead per filter: 24 ns
net.core.bpf_jit_enable=1:
net.core.bpf_jit_harden=0:
Benchmarking 16777216 samples...
10.684681435 - 0.004198682 = 10680482753
getpid native: 636 ns
22.050823167 - 10.685571417 = 11365251750
getpid RET_ALLOW 1 filter: 677 ns
33.714134291 - 22.051100183 = 11663034108
getpid RET_ALLOW 2 filters: 695 ns
44.793312551 - 33.714383001 = 11078929550
getpid BPF-less allow: 660 ns
Estimated total seccomp overhead for 1 filter: 41 ns
Estimated total seccomp overhead for 2 filters: 59 ns
Estimated seccomp per-filter overhead: 18 ns
Estimated seccomp entry overhead: 23 ns
Estimated BPF overhead per filter: 17 ns
The above is from my (very dangerous!) benchmarking patch[1].
So, with the layered nature of seccomp filters there's a reasonable gain
to be seen for a O(1) bitmap lookup to skip running even a single filter,
even for the fastest BPF mode.
Not that we need to optimize for the pathological case, but this would
be especially useful for cases like systemd, which appears to be
constructing seccomp filters very inefficiently maybe on a per-syscall[3]
basis? For example, systemd-resolved has 32 (!) seccomp filters
attached[2]:
# grep ^Seccomp_filters /proc/$(pidof systemd-resolved)/status
Seccomp_filters: 32
# grep SystemCall /lib/systemd/system/systemd-resolved.service
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service
I'd like to better understand what they're doing, but haven't had time
to dig in. (The systemd devel mailing list requires subscription, so
I've directly CCed some systemd folks that have touched seccomp there
recently. Hi! The starts of this thread is here[4].)
-Kees
[1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=seccomp/benchmark-bpf&id=20cc7d8f4238ea3bc1798f204bb865f4994cca27
[2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp&id=9d06f16f463cef5c445af9738efed2bfe4c64730
[3] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=
[4] https://lore.kernel.org/bpf/c22a6c3cefc2412cad00ae14c1371711@huawei.com/
--
Kees Cook
^ permalink raw reply
* Re: [musl] ppc64le and 32-bit LE userland compatibility
From: Rich Felker @ 2020-05-29 19:24 UTC (permalink / raw)
To: Will Springer
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev, linuxppc-dev
In-Reply-To: <2047231.C4sosBPzcN@sheen>
On Fri, May 29, 2020 at 07:03:48PM +0000, Will Springer wrote:
> The next problem concerns the ABI more directly. The failure mode was `file`
> surfacing EINVAL from pread64 when invoked on an ELF; pread64 was passed a
> garbage value for `pos`, which didn't appear to be caused by anything in
> `file`. Initially it seemed as though the 32-bit components of the arg were
> getting swapped, and we made hacky fixes to glibc and musl to put them in the
> "right order"; however, we weren't sure if that was the correct approach, or
> if there were knock-on effects we didn't know about. So we found the relevant
> compat code path in the kernel, at arch/powerpc/kernel/sys_ppc32.c, where
> there exists this comment:
>
> > /*
> > * long long munging:
> > * The 32 bit ABI passes long longs in an odd even register pair.
> > */
>
> It seems that the opposite is true in LE mode, and something is expecting long
> longs to start on an even register. I realized this after I tried swapping hi/
> lo `u32`s here and didn't see an improvement. I whipped up a patch [6] that
> switches which syscalls use padding arguments depending on endianness, while
> hopefully remaining tidy enough to be unobtrusive. (I took some liberties with
> variable names/types so that the macro could be consistent.)
The argument passing for pread/pwrite is historically a mess and
differs between archs. musl has a dedicated macro that archs can
define to override it. But it looks like it should match regardless of
BE vs LE, and musl already defines it for powerpc with the default
definition, adding a zero arg to start on an even arg-slot index,
which is an odd register (since ppc32 args start with an odd one, r3).
> [6]: https://gist.github.com/Skirmisher/02891c1a8cafa0ff18b2460933ef4f3c
I don't think this is correct, but I'm confused about where it's
getting messed up because it looks like it should already be right.
> This was enough to fix up the `file` bug. I'm no seasoned kernel hacker,
> though, and there is still concern over the right way to approach this,
> whether it should live in the kernel or libc, etc. Frankly, I don't know the
> ABI structure enough to understand why the register padding has to be
> different in this case, or what lower-level component is responsible for it..
> For comparison, I had a look at the mips tree, since it's bi-endian and has a
> similar 32/64 situation. There is a macro conditional upon endianness that is
> responsible for munging long longs; it uses __MIPSEB__ and __MIPSEL__ instead
> of an if/else on the generic __LITTLE_ENDIAN__. Not sure what to make of that.
> (It also simply swaps registers for LE, unlike what I did for ppc.)
Indeed the problem is probably that you need to swap registers for LE,
not remove the padding slot. Did you check what happens if you pass a
value larger than 32 bits?
If so, the right way to fix this on the kernel side would be to
construct the value as a union rather than by bitwise ops so it's
endian-agnostic:
(union { u32 parts[2]; u64 val; }){{ arg1, arg2 }}.val
But the kernel folks might prefer endian ifdefs for some odd reason...
> Also worth noting is the one other outstanding bug, where the time-related
> syscalls in the 32-bit vDSO seem to return garbage. It doesn't look like an
> endian bug to me, and it doesn't affect standard syscalls (which is why if you
> run `date` on musl it prints the correct time, unlike on glibc). The vDSO time
> functions are implemented in ppc asm (arch/powerpc/kernel/vdso32/
> gettimeofday.S), and I've never touched the stuff, so if anyone has a clue I'm
> all ears.
Not sure about this. Worst-case, just leave it disabled until someone
finds a fix.
Rich
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: power: Add BQ28z610 compatible
From: Rob Herring @ 2020-05-29 19:26 UTC (permalink / raw)
To: Dan Murphy; +Cc: linux-kernel, sre, devicetree, afd, linux-pm, pali
In-Reply-To: <20200528122147.6171-3-dmurphy@ti.com>
On Thu, 28 May 2020 07:21:46 -0500, Dan Murphy wrote:
> Add the Texas Instruments bq28z610 battery monitor to the bq27xxx
> binding.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/5] rebase -i: support --committer-date-is-author-date
From: Johannes Schindelin @ 2020-05-29 2:52 UTC (permalink / raw)
To: Phillip Wood
Cc: Junio C Hamano, Elijah Newren, Rohit Ashiwal,
Đoàn Trần Công Danh, Alban Gruin,
Git Mailing List
In-Reply-To: <20200527173356.47364-3-phillip.wood123@gmail.com>
Hi Phillip,
On Wed, 27 May 2020, Phillip Wood wrote:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> As part of the on-going effort to retire the apply rebase backend teach
> the merge backend how to handle --committer-date-is-author-date.
I forgot to mention this in my reply to the first patch in this series: it
strikes me as a mis-characterization that the `apply` backend is about to
be retired. What _is_ true is that the `merge` backend is the default
backend, and what is even more true is that it is cumbersome if certain
`rebase` options cannot be combined because they are only implemented by
one of both rebase backends.
>
> Original-patch-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---
> Documentation/git-rebase.txt | 10 +++--
> builtin/rebase.c | 16 ++++---
> sequencer.c | 59 +++++++++++++++++++++++++-
> sequencer.h | 1 +
> t/t3422-rebase-incompatible-options.sh | 1 -
> t/t3436-rebase-more-options.sh | 56 ++++++++++++++++++++++++
> 6 files changed, 133 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index b003784f01..dfa70263e6 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -445,9 +445,13 @@ if the other side had no changes that conflicted.
> See also INCOMPATIBLE OPTIONS below.
>
> --committer-date-is-author-date::
> + Instead of using the current time as the committer date, use
> + the author date of the commit being rebased as the committer
> + date. This option implies --force-rebase.
> +
> --ignore-date::
> - These flags are passed to 'git am' to easily change the dates
> - of the rebased commits (see linkgit:git-am[1]).
> + This flag is passed to 'git am' to change the author date
> + of each rebased commit (see linkgit:git-am[1]).
> +
> See also INCOMPATIBLE OPTIONS below.
>
> @@ -585,7 +589,6 @@ INCOMPATIBLE OPTIONS
> The following options:
>
> * --apply
> - * --committer-date-is-author-date
> * --ignore-date
> * --whitespace
> * -C
> @@ -613,6 +616,7 @@ In addition, the following pairs of options are incompatible:
> * --preserve-merges and --rebase-merges
> * --preserve-merges and --empty=
> * --preserve-merges and --ignore-whitespace
> + * --preserve-merges and --committer-date-is-author-date
> * --keep-base and --onto
> * --keep-base and --root
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 5d8e117276..357cd6acf3 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -89,6 +89,7 @@ struct rebase_options {
> int ignore_whitespace;
> char *gpg_sign_opt;
> int autostash;
> + int committer_date_is_author_date;
> char *cmd;
> int allow_empty_message;
> int rebase_merges, rebase_cousins;
> @@ -126,6 +127,8 @@ static struct replay_opts get_replay_opts(const struct rebase_options *opts)
> replay.quiet = !(opts->flags & REBASE_NO_QUIET);
> replay.verbose = opts->flags & REBASE_VERBOSE;
> replay.reschedule_failed_exec = opts->reschedule_failed_exec;
> + replay.committer_date_is_author_date =
> + opts->committer_date_is_author_date;
> replay.gpg_sign = xstrdup_or_null(opts->gpg_sign_opt);
> replay.strategy = opts->strategy;
>
> @@ -1003,6 +1006,8 @@ static int run_am(struct rebase_options *opts)
>
> if (opts->ignore_whitespace)
> argv_array_push(&am.args, "--ignore-whitespace");
> + if (opts->committer_date_is_author_date)
> + argv_array_push(&opts->git_am_opts, "--committer-date-is-author-date");
As before, I would rather see this in `cmd__rebase()` rahn in `run_am()`.
> if (opts->action && !strcmp("continue", opts->action)) {
> argv_array_push(&am.args, "--resolved");
> argv_array_pushf(&am.args, "--resolvemsg=%s", resolvemsg);
> @@ -1507,9 +1512,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> PARSE_OPT_NOARG, NULL, REBASE_DIFFSTAT },
> OPT_BOOL(0, "signoff", &options.signoff,
> N_("add a Signed-off-by: line to each commit")),
> - OPT_PASSTHRU_ARGV(0, "committer-date-is-author-date",
> - &options.git_am_opts, NULL,
> - N_("passed to 'git am'"), PARSE_OPT_NOARG),
> + OPT_BOOL(0, "committer-date-is-author-date",
> + &options.committer_date_is_author_date,
> + N_("make committer date match author date")),
> OPT_PASSTHRU_ARGV(0, "ignore-date", &options.git_am_opts, NULL,
> N_("passed to 'git am'"), PARSE_OPT_NOARG),
> OPT_PASSTHRU_ARGV('C', NULL, &options.git_am_opts, N_("n"),
> @@ -1804,11 +1809,12 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> options.autosquash) {
> allow_preemptive_ff = 0;
> }
> + if (options.committer_date_is_author_date)
> + options.flags |= REBASE_FORCE;
>
> for (i = 0; i < options.git_am_opts.argc; i++) {
> const char *option = options.git_am_opts.argv[i], *p;
> - if (!strcmp(option, "--committer-date-is-author-date") ||
> - !strcmp(option, "--ignore-date") ||
> + if (!strcmp(option, "--ignore-date") ||
> !strcmp(option, "--whitespace=fix") ||
> !strcmp(option, "--whitespace=strip"))
> allow_preemptive_ff = 0;
> diff --git a/sequencer.c b/sequencer.c
> index 6fd2674632..8826c6325b 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -149,6 +149,7 @@ static GIT_PATH_FUNC(rebase_path_refs_to_delete, "rebase-merge/refs-to-delete")
> * command-line.
> */
> static GIT_PATH_FUNC(rebase_path_gpg_sign_opt, "rebase-merge/gpg_sign_opt")
> +static GIT_PATH_FUNC(rebase_path_cdate_is_adate, "rebase-merge/cdate_is_adate")
> static GIT_PATH_FUNC(rebase_path_orig_head, "rebase-merge/orig-head")
> static GIT_PATH_FUNC(rebase_path_verbose, "rebase-merge/verbose")
> static GIT_PATH_FUNC(rebase_path_quiet, "rebase-merge/quiet")
> @@ -872,6 +873,22 @@ static char *get_author(const char *message)
> return NULL;
> }
>
> +static const char *author_date_from_env_array(const struct argv_array *env)
> +{
> + int i;
> + const char *date;
> +
> + for (i = 0; i < env->argc; i++)
> + if (skip_prefix(env->argv[i],
> + "GIT_AUTHOR_DATE=", &date))
> + return date;
> + /*
> + * If GIT_AUTHOR_DATE is missing we should have already errored out when
> + * reading the script
> + */
> + BUG("GIT_AUTHOR_DATE missing from author script");
> +}
> +
> static const char staged_changes_advice[] =
> N_("you have staged changes in your working tree\n"
> "If these changes are meant to be squashed into the previous commit, run:\n"
> @@ -938,6 +955,10 @@ static int run_git_commit(struct repository *r,
> gpg_opt, gpg_opt);
> }
>
> + if (opts->committer_date_is_author_date)
> + argv_array_pushf(&cmd.env_array, "GIT_COMMITTER_DATE=%s",
> + author_date_from_env_array(&cmd.env_array));
> +
> argv_array_push(&cmd.args, "commit");
>
> if (!(flags & VERIFY_MSG))
> @@ -1349,6 +1370,30 @@ static int try_to_commit(struct repository *r,
> commit_list_insert(current_head, &parents);
> }
>
> + if (opts->committer_date_is_author_date) {
> + int len = strlen(author);
Given that `len` is used only once, is this local variable really
necessary? You could just as well pass `(int)strlen(author)` in the
`split_ident_line()` call below.
> + struct ident_split ident;
> + struct strbuf date = STRBUF_INIT;
> +
> + if (split_ident_line(&ident, author, len) < 0) {
> + res = error(_("malformed ident line '%s'"), author);
> + goto out;
> + }
> + if (!ident.date_begin) {
> + res = error(_("corrupted author without date information"));
> + goto out;
> + }
> +
> + strbuf_addf(&date, "@%.*s %.*s",
> + (int)(ident.date_end - ident.date_begin), ident.date_begin,
> + (int)(ident.tz_end - ident.tz_begin), ident.tz_begin);
> + res = setenv("GIT_COMMITTER_DATE", date.buf, 1);
> + strbuf_release(&date);
It might be easier to read if it was written this way:
if (split_ident_line(...) < 0)
res = ...
else if (!ident.date_begin)
res = ...
else {
strbuf_addf(...)
res = ...
strbuf_release(&date);
}
if (res)
goto out;
> +
> + if (res)
> + goto out;
> + }
> +
> if (write_index_as_tree(&tree, r->index, r->index_file, 0, NULL)) {
> res = error(_("git write-tree failed to write a tree"));
> goto out;
> @@ -2532,6 +2577,11 @@ static int read_populate_opts(struct replay_opts *opts)
> opts->signoff = 1;
> }
>
> + if (file_exists(rebase_path_cdate_is_adate())) {
> + opts->allow_ff = 0;
> + opts->committer_date_is_author_date = 1;
> + }
> +
> if (file_exists(rebase_path_reschedule_failed_exec()))
> opts->reschedule_failed_exec = 1;
>
> @@ -2622,6 +2672,8 @@ int write_basic_state(struct replay_opts *opts, const char *head_name,
> write_file(rebase_path_drop_redundant_commits(), "%s", "");
> if (opts->keep_redundant_commits)
> write_file(rebase_path_keep_redundant_commits(), "%s", "");
> + if (opts->committer_date_is_author_date)
> + write_file(rebase_path_cdate_is_adate(), "%s", "");
> if (opts->reschedule_failed_exec)
> write_file(rebase_path_reschedule_failed_exec(), "%s", "");
>
> @@ -3542,6 +3594,10 @@ static int do_merge(struct repository *r,
> goto leave_merge;
> }
>
> + if (opts->committer_date_is_author_date)
> + argv_array_pushf(&cmd.env_array, "GIT_COMMITTER_DATE=%s",
> + author_date_from_env_array(&cmd.env_array));
> +
> cmd.git_cmd = 1;
> argv_array_push(&cmd.args, "merge");
> argv_array_push(&cmd.args, "-s");
> @@ -3819,7 +3875,8 @@ static int pick_commits(struct repository *r,
> setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
> if (opts->allow_ff)
> assert(!(opts->signoff || opts->no_commit ||
> - opts->record_origin || opts->edit));
> + opts->record_origin || opts->edit ||
> + opts->committer_date_is_author_date));
> if (read_and_refresh_cache(r, opts))
> return -1;
>
> diff --git a/sequencer.h b/sequencer.h
> index 0bee85093e..4ab94119ae 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -45,6 +45,7 @@ struct replay_opts {
> int verbose;
> int quiet;
> int reschedule_failed_exec;
> + int committer_date_is_author_date;
>
> int mainline;
>
> diff --git a/t/t3422-rebase-incompatible-options.sh b/t/t3422-rebase-incompatible-options.sh
> index 55ca46786d..c8234062c6 100755
> --- a/t/t3422-rebase-incompatible-options.sh
> +++ b/t/t3422-rebase-incompatible-options.sh
> @@ -61,7 +61,6 @@ test_rebase_am_only () {
> }
>
> test_rebase_am_only --whitespace=fix
> -test_rebase_am_only --committer-date-is-author-date
> test_rebase_am_only -C4
>
> test_expect_success REBASE_P '--preserve-merges incompatible with --signoff' '
> diff --git a/t/t3436-rebase-more-options.sh b/t/t3436-rebase-more-options.sh
> index fb5e747e86..7e68fb9753 100755
> --- a/t/t3436-rebase-more-options.sh
> +++ b/t/t3436-rebase-more-options.sh
> @@ -9,6 +9,9 @@ test_description='tests to ensure compatibility between am and interactive backe
>
> . "$TEST_DIRECTORY"/lib-rebase.sh
>
> +GIT_AUTHOR_DATE="1999-04-02T08:03:20+05:30"
> +export GIT_AUTHOR_DATE
> +
> # This is a special case in which both am and interactive backends
> # provide the same output. It was done intentionally because
> # both the backends fall short of optimal behaviour.
> @@ -28,8 +31,13 @@ test_expect_success 'setup' '
> EOF
> git commit -am "update file" &&
> git tag side &&
> + test_commit commit1 foo foo1 &&
> + test_commit commit2 foo foo2 &&
> + test_commit commit3 foo foo3 &&
>
> git checkout --orphan master &&
> + git rm --cached foo &&
> + rm foo &&
> sed -e "s/^|//" >file <<-\EOF &&
> |line 1
> | line 2
> @@ -78,6 +86,54 @@ test_expect_success '--ignore-whitespace is remembered when continuing' '
> test_cmp expect file
> '
>
> +test_expect_success '--committer-date-is-author-date works with apply backend' '
> + GIT_AUTHOR_DATE="@1234 +0300" git commit --amend --reset-author &&
> + git rebase --apply --committer-date-is-author-date HEAD^ &&
> + git log -1 --pretty=%ai >authortime &&
> + git log -1 --pretty=%ci >committertime &&
> + test_cmp authortime committertime
This seems to be a repeated pattern. To dry it up, it would make sense to
do this:
test_ctime_is_atime () {
git log -1 --pretty=%ai >authortime &&
git log -1 --pretty=%ci >committertime &&
test_cmp authortime committertime
}
Ciao,
Dscho
> +'
> +
> +test_expect_success '--committer-date-is-author-date works with merge backend' '
> + GIT_AUTHOR_DATE="@1234 +0300" git commit --amend --reset-author &&
> + git rebase -m --committer-date-is-author-date HEAD^ &&
> + git log -1 --pretty=%ai >authortime &&
> + git log -1 --pretty=%ci >committertime &&
> + test_cmp authortime committertime
> +'
> +
> +test_expect_success '--committer-date-is-author-date works with rebase -r' '
> + git checkout side &&
> + GIT_AUTHOR_DATE="@1234 +0300" git merge --no-ff commit3 &&
> + git rebase -r --root --committer-date-is-author-date &&
> + git log --pretty=%ai >authortime &&
> + git log --pretty=%ci >committertime &&
> + test_cmp authortime committertime
> +'
> +
> +test_expect_success '--committer-date-is-author-date works when forking merge' '
> + git checkout side &&
> + GIT_AUTHOR_DATE="@1234 +0300" git merge --no-ff commit3 &&
> + git rebase -r --root --strategy=resolve --committer-date-is-author-date &&
> + git log --pretty=%ai >authortime &&
> + git log --pretty=%ci >committertime &&
> + test_cmp authortime committertime
> +
> +'
> +
> +test_expect_success '--committer-date-is-author-date works when committing conflict resolution' '
> + git checkout commit2 &&
> + GIT_AUTHOR_DATE="@1980 +0000" git commit --amend --only --reset-author &&
> + git log -1 --format=%at HEAD >expect &&
> + test_must_fail git rebase -m --committer-date-is-author-date \
> + --onto HEAD^^ HEAD^ &&
> + echo resolved > foo &&
> + git add foo &&
> + git rebase --continue &&
> + git log -1 --format=%ct HEAD >actual &&
> + test_cmp expect actual
> +'
> +
> # This must be the last test in this file
> test_expect_success '$EDITOR and friends are unchanged' '
> test_editor_unchanged
> --
> 2.26.2
>
>
^ permalink raw reply
* [PATCH v3] regmap: fix alignment issue
From: Jens Thoms Toerring @ 2020-05-29 19:25 UTC (permalink / raw)
To: Mark Brown, linux-kernel
The assembly and disassembly of data to be sent to or received from a
device invoke functions (regmap_format_XXX() and regmap_parse_XXX())
that extract or insert data items from or into a buffer, using
assignments. In some cases those functions are called with buffer
pointers with odd addresses. On architectures with strict alignment
requirements this results in a kernel crash for u16 and u32 values.
The assignments have been replaced by methods that take alignment
into consideration.
Signed-off-by: Jens Thoms Toerring <jt@toerring.de>
---
drivers/base/regmap/regmap.c | 38 ++++++++++++++++++--------------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 58cfb32..70f470e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -193,15 +193,15 @@ static void regmap_format_8(void *buf, unsigned int val, unsigned int shift)
static void regmap_format_16_be(void *buf, unsigned int val, unsigned int shift)
{
- __be16 *b = buf;
-
- b[0] = cpu_to_be16(val << shift);
+ put_unaligned_be16(val << shift, buf);
}
static void regmap_format_16_native(void *buf, unsigned int val,
unsigned int shift)
{
- *(u16 *)buf = val << shift;
+ u16 v = val << shift;
+
+ memcpy(buf, &v, sizeof(v));
}
static void regmap_format_24(void *buf, unsigned int val, unsigned int shift)
@@ -217,15 +217,15 @@ static void regmap_format_24(void *buf, unsigned int val, unsigned int shift)
static void regmap_format_32_be(void *buf, unsigned int val, unsigned int shift)
{
- __be32 *b = buf;
-
- b[0] = cpu_to_be32(val << shift);
+ put_unaligned_be32(val << shift, buf);
}
static void regmap_format_32_native(void *buf, unsigned int val,
unsigned int shift)
{
- *(u32 *)buf = val << shift;
+ u32 = val << shift;
+
+ memcpy(buf, &v, sizeof(v));
}
static unsigned int regmap_parse_8(void *buf)
@@ -237,16 +237,15 @@ static unsigned int regmap_parse_8(void *buf)
static unsigned int regmap_parse_16_be(void *buf)
{
- __be16 *b = buf;
-
- b[0] = be16_to_cpu(b[0]);
-
- return b[0];
+ return get_unaligned_be16(buf);
}
static unsigned int regmap_parse_16_native(void *buf)
{
- return *(u16 *)buf;
+ u16 v;
+
+ memcpy(&v, buf, sizeof(v));
+ return v;
}
static unsigned int regmap_parse_24(void *buf)
@@ -261,17 +260,15 @@ static unsigned int regmap_parse_24(void *buf)
static unsigned int regmap_parse_32_be(void *buf)
{
- __be32 *b = buf;
-
- b[0] = be32_to_cpu(b[0]);
-
- return b[0];
+ return get_unaligned_be32(buf);
}
static unsigned int regmap_parse_32_native(void *buf)
{
- return *(u32 *)buf;
+ u32 v;
+
+ memcpy(&v, buf, sizeof(v));
+ return v;
}
static void regmap_lock_mutex(void *__map)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: power: Add BQ27561 compatible
From: Rob Herring @ 2020-05-29 19:25 UTC (permalink / raw)
To: Dan Murphy; +Cc: afd, linux-pm, sre, linux-kernel, pali, devicetree
In-Reply-To: <20200528122147.6171-1-dmurphy@ti.com>
On Thu, 28 May 2020 07:21:44 -0500, Dan Murphy wrote:
> Add the Texas Instruments bq27561 battery monitor to the bq27xxx
> binding.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
From: Rob Herring @ 2020-05-29 19:24 UTC (permalink / raw)
To: EastL
Cc: mark.rutland, devicetree, wsd_upstream, Sean Wang, linux-kernel,
dmaengine, vkoul, linux-mediatek, matthias.bgg, linux-arm-kernel
In-Reply-To: <1590659832-31476-2-git-send-email-EastL.Lee@mediatek.com>
On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> Document the devicetree bindings for MediaTek Command-Queue DMA controller
> which could be found on MT6779 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: EastL <EastL.Lee@mediatek.com>
Need a full name.
> ---
> .../devicetree/bindings/dma/mtk-cqdma.yaml | 100 +++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> new file mode 100644
> index 0000000..045aa0c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Command-Queue DMA controller Device Tree Binding
> +
> +maintainers:
> + - EastL <EastL.Lee@mediatek.com>
> +
> +description:
> + MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> + is dedicated to memory-to-memory transfer through queue based
> + descriptor management.
> +
Need a $ref to dma-controller.yaml
> +properties:
> + "#dma-cells":
> + minimum: 1
> + # Should be enough
> + maximum: 255
> + description:
> + Used to provide DMA controller specific information.
> +
> + compatible:
> + const: mediatek,cqdma
Needs SoC specific compatible string(s).
> +
> + reg:
> + minItems: 1
> + maxItems: 255
You can have 255 register regions?
You need to define what each region is if more than 1.
> +
> + interrupts:
> + minItems: 1
> + maxItems: 255
255 interrupts?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: cqdma
> +
> + dma-channel-mask:
> + description:
> + Bitmask of available DMA channels in ascending order that are
> + not reserved by firmware and are available to the
> + kernel. i.e. first channel corresponds to LSB.
> + The first item in the array is for channels 0-31, the second is for
> + channels 32-63, etc.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + items:
> + minItems: 1
> + # Should be enough
> + maxItems: 255
This already has a definition in dma-common.yaml. Don't copy-n-paste
it. Just add any constraints you have. Like what is the max number of
channels?
> +
> + dma-channels:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA channels supported by the controller.
> +
> + dma-requests:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA request signals supported by the controller.
Same comment on these 2.
> +
> +required:
> + - "#dma-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - dma-channel-mask
> + - dma-channels
> + - dma-requests
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/mt6779-clk.h>
> + cqdma: dma-controller@10212000 {
> + compatible = "mediatek,cqdma";
> + reg = <0 0x10212000 0 0x80>,
> + <0 0x10212080 0 0x80>,
> + <0 0x10212100 0 0x80>;
Examples default to 1 cell each for address and size.
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg_ao CLK_INFRA_CQ_DMA>;
> + clock-names = "cqdma";
> + dma-channel-mask = <63>;
> + dma-channels = <3>;
> + dma-requests = <32>;
> + #dma-cells = <1>;
> + };
> +
> +...
> --
> 1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH net-next v4 1/4] dt-bindings: net: Add tx and rx internal delays
From: Dan Murphy @ 2020-05-29 19:24 UTC (permalink / raw)
To: Rob Herring
Cc: andrew, f.fainelli, hkallweit1, davem, netdev, linux-kernel,
devicetree
In-Reply-To: <20200529182544.GA2691697@bogus>
Rob
On 5/29/20 1:25 PM, Rob Herring wrote:
> On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
>> tx-internal-delays and rx-internal-delays are a common setting for RGMII
>> capable devices.
>>
>> These properties are used when the phy-mode or phy-controller is set to
>> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
>> controller that the PHY will add the internal delay for the connection.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> .../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
>> index ac471b60ed6a..70702a4ef5e8 100644
>> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
>> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
>> @@ -143,6 +143,20 @@ properties:
>> Specifies the PHY management type. If auto is set and fixed-link
>> is not specified, it uses MDIO for management.
>>
>> + rx-internal-delay-ps:
>> + $ref: /schemas/types.yaml#definitions/uint32
>> + description: |
>> + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
>> + PHY's that have configurable RX internal delays. This property is only
>> + used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
> Isn't this a property of the phy (this is the controller schema)? Looks
> like we have similar properties already and they go in phy nodes. Would
> be good to have a standard property, but let's be clear where it goes.
>
> We need to add '-ps' as a standard unit suffix (in dt-schema) and then a
> type is not needed here.
This is a PHY specific property.
I will move them.
Dumb question but you can just point me to the manual about how and
where to add the '-ps' to the dt-schema
Dan
> Rob
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
From: Rob Herring @ 2020-05-29 19:24 UTC (permalink / raw)
To: EastL
Cc: mark.rutland, devicetree, wsd_upstream, Sean Wang, linux-kernel,
dmaengine, vkoul, linux-mediatek, matthias.bgg, linux-arm-kernel
In-Reply-To: <1590659832-31476-2-git-send-email-EastL.Lee@mediatek.com>
On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> Document the devicetree bindings for MediaTek Command-Queue DMA controller
> which could be found on MT6779 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: EastL <EastL.Lee@mediatek.com>
Need a full name.
> ---
> .../devicetree/bindings/dma/mtk-cqdma.yaml | 100 +++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> new file mode 100644
> index 0000000..045aa0c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Command-Queue DMA controller Device Tree Binding
> +
> +maintainers:
> + - EastL <EastL.Lee@mediatek.com>
> +
> +description:
> + MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> + is dedicated to memory-to-memory transfer through queue based
> + descriptor management.
> +
Need a $ref to dma-controller.yaml
> +properties:
> + "#dma-cells":
> + minimum: 1
> + # Should be enough
> + maximum: 255
> + description:
> + Used to provide DMA controller specific information.
> +
> + compatible:
> + const: mediatek,cqdma
Needs SoC specific compatible string(s).
> +
> + reg:
> + minItems: 1
> + maxItems: 255
You can have 255 register regions?
You need to define what each region is if more than 1.
> +
> + interrupts:
> + minItems: 1
> + maxItems: 255
255 interrupts?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: cqdma
> +
> + dma-channel-mask:
> + description:
> + Bitmask of available DMA channels in ascending order that are
> + not reserved by firmware and are available to the
> + kernel. i.e. first channel corresponds to LSB.
> + The first item in the array is for channels 0-31, the second is for
> + channels 32-63, etc.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + items:
> + minItems: 1
> + # Should be enough
> + maxItems: 255
This already has a definition in dma-common.yaml. Don't copy-n-paste
it. Just add any constraints you have. Like what is the max number of
channels?
> +
> + dma-channels:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA channels supported by the controller.
> +
> + dma-requests:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA request signals supported by the controller.
Same comment on these 2.
> +
> +required:
> + - "#dma-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - dma-channel-mask
> + - dma-channels
> + - dma-requests
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/mt6779-clk.h>
> + cqdma: dma-controller@10212000 {
> + compatible = "mediatek,cqdma";
> + reg = <0 0x10212000 0 0x80>,
> + <0 0x10212080 0 0x80>,
> + <0 0x10212100 0 0x80>;
Examples default to 1 cell each for address and size.
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg_ao CLK_INFRA_CQ_DMA>;
> + clock-names = "cqdma";
> + dma-channel-mask = <63>;
> + dma-channels = <3>;
> + dma-requests = <32>;
> + #dma-cells = <1>;
> + };
> +
> +...
> --
> 1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.
From: Dan Williams @ 2020-05-29 19:22 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jan Kara, linux-nvdimm, jack, Jeff Moyer, Oliver O'Halloran,
Michal Suchánek, linuxppc-dev
In-Reply-To: <7e8ee9e3-4d4d-e4b9-913b-1c2448adc62a@linux.ibm.com>
On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> On 5/29/20 3:22 PM, Jan Kara wrote:
> > Hi!
> >
> > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> >> Thanks Michal. I also missed Jeff in this email thread.
> >
> > And I think you'll also need some of the sched maintainers for the prctl
> > bits...
> >
> >> On 5/29/20 3:03 PM, Michal Suchánek wrote:
> >>> Adding Jan
> >>>
> >>> On Fri, May 29, 2020 at 11:11:39AM +0530, Aneesh Kumar K.V wrote:
> >>>> With POWER10, architecture is adding new pmem flush and sync instructions.
> >>>> The kernel should prevent the usage of MAP_SYNC if applications are not using
> >>>> the new instructions on newer hardware.
> >>>>
> >>>> This patch adds a prctl option MAP_SYNC_ENABLE that can be used to enable
> >>>> the usage of MAP_SYNC. The kernel config option is added to allow the user
> >>>> to control whether MAP_SYNC should be enabled by default or not.
> >>>>
> >>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> > ...
> >>>> diff --git a/kernel/fork.c b/kernel/fork.c
> >>>> index 8c700f881d92..d5a9a363e81e 100644
> >>>> --- a/kernel/fork.c
> >>>> +++ b/kernel/fork.c
> >>>> @@ -963,6 +963,12 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(mmlist_lock);
> >>>> static unsigned long default_dump_filter = MMF_DUMP_FILTER_DEFAULT;
> >>>> +#ifdef CONFIG_ARCH_MAP_SYNC_DISABLE
> >>>> +unsigned long default_map_sync_mask = MMF_DISABLE_MAP_SYNC_MASK;
> >>>> +#else
> >>>> +unsigned long default_map_sync_mask = 0;
> >>>> +#endif
> >>>> +
> >
> > I'm not sure CONFIG is really the right approach here. For a distro that would
> > basically mean to disable MAP_SYNC for all PPC kernels unless application
> > explicitly uses the right prctl. Shouldn't we rather initialize
> > default_map_sync_mask on boot based on whether the CPU we run on requires
> > new flush instructions or not? Otherwise the patch looks sensible.
> >
>
> yes that is correct. We ideally want to deny MAP_SYNC only w.r.t
> POWER10. But on a virtualized platform there is no easy way to detect
> that. We could ideally hook this into the nvdimm driver where we look at
> the new compat string ibm,persistent-memory-v2 and then disable MAP_SYNC
> if we find a device with the specific value.
>
> BTW with the recent changes I posted for the nvdimm driver, older kernel
> won't initialize persistent memory device on newer hardware. Newer
> hardware will present the device to OS with a different device tree
> compat string.
>
> My expectation w.r.t this patch was, Distro would want to mark
> CONFIG_ARCH_MAP_SYNC_DISABLE=n based on the different application
> certification. Otherwise application will have to end up calling the
> prctl(MMF_DISABLE_MAP_SYNC, 0) any way. If that is the case, should this
> be dependent on P10?
>
> With that I am wondering should we even have this patch? Can we expect
> userspace get updated to use new instruction?.
>
> With ppc64 we never had a real persistent memory device available for
> end user to try. The available persistent memory stack was using vPMEM
> which was presented as a volatile memory region for which there is no
> need to use any of the flush instructions. We could safely assume that
> as we get applications certified/verified for working with pmem device
> on ppc64, they would all be using the new instructions?
I think prctl is the wrong interface for this. I was thinking a sysfs
interface along the same lines as /sys/block/pmemX/dax/write_cache.
That attribute is toggling DAXDEV_WRITE_CACHE for the determination of
whether the platform or the kernel needs to handle cache flushing
relative to power loss. A similar attribute can be established for
DAXDEV_SYNC, it would simply default to off based on a configuration
time policy, but be dynamically changeable at runtime via sysfs.
These flags are device properties that affect the kernel and
userspace's handling of persistence.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.