linux-kernel - linux-next: manual merge of the pm tree with the tty.current tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170811120047.17d5db54@canb.auug.org.au>
Date:   Fri, 11 Aug 2017 12:00:47 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>, Greg KH <greg@...ah.com>
Cc:     Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Timur Tabi <timur@...eaurora.org>,
        Graeme Gregory <graeme.gregory@...aro.org>
Subject: linux-next: manual merge of the pm tree with the tty.current tree

Hi Rafael,

Today's linux-next merge of the pm tree got a conflict in:

  drivers/acpi/spcr.c

between commit:

  37ef38f3f838 ("tty: pl011: fix initialization order of QDF2400 E44")

from the tty.current tree and commit:

  01c5210cad90 ("ACPI: SPCR: work around clock issue on xgene UART")

from the pm tree.

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 drivers/acpi/spcr.c
index 98aa8c808a33,48a7efc28ebb..000000000000
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@@ -157,35 -155,21 +165,43 @@@ int __init parse_spcr(bool earlycon
  		goto done;
  	}
  
 -	if (qdf2400_erratum_44_present(&table->header))
 -		uart = "qdf2400_e44";
 +	/*
 +	 * If the E44 erratum is required, then we need to tell the pl011
 +	 * driver to implement the work-around.
 +	 *
 +	 * The global variable is used by the probe function when it
 +	 * creates the UARTs, whether or not they're used as a console.
 +	 *
 +	 * If the user specifies "traditional" earlycon, the qdf2400_e44
 +	 * console name matches the EARLYCON_DECLARE() statement, and
 +	 * SPCR is not used.  Parameter "earlycon" is false.
 +	 *
 +	 * If the user specifies "SPCR" earlycon, then we need to update
 +	 * the console name so that it also says "qdf2400_e44".  Parameter
 +	 * "earlycon" is true.
 +	 *
 +	 * For consistency, if we change the console name, then we do it
 +	 * for everyone, not just earlycon.
 +	 */
 +	if (qdf2400_erratum_44_present(&table->header)) {
 +		qdf2400_e44_present = true;
 +		if (earlycon)
 +			uart = "qdf2400_e44";
 +	}
 +
- 	if (xgene_8250_erratum_present(table))
+ 	if (xgene_8250_erratum_present(table)) {
  		iotype = "mmio32";
  
- 	snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
- 		 table->serial_port.address, baud_rate);
+ 		/* for xgene v1 and v2 we don't know the clock rate of the
+ 		 * UART so don't attempt to change to the baud rate state
+ 		 * in the table because driver cannot calculate the dividers
+ 		 */
+ 		snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
+ 			 table->serial_port.address);
+ 	} else {
+ 		snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
+ 			 table->serial_port.address, baud_rate);
+ 	}
  
  	pr_info("console: %s\n", opts);