Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1709169 > unrolled thread

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

Started byStephen Rothwell <sfr@canb.auug.org.au>
First post2017-08-11 04:10 +0200
Last post2017-08-11 17:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  linux-next: manual merge of the pm tree with the tty.current tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-08-11 04:10 +0200
    Re: linux-next: manual merge of the pm tree with the tty.current tree Greg KH <greg@kroah.com> - 2017-08-11 17:50 +0200

#1709169 — linux-next: manual merge of the pm tree with the tty.current tree

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2017-08-11 04:10 +0200
Subjectlinux-next: manual merge of the pm tree with the tty.current tree
Message-ID<ud7yG-5Q4-5@gated-at.bofh.it>
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);
  

[toc] | [next] | [standalone]


#1709764

FromGreg KH <greg@kroah.com>
Date2017-08-11 17:50 +0200
Message-ID<udkmf-5jx-35@gated-at.bofh.it>
In reply to#1709169
On Fri, Aug 11, 2017 at 12:00:47PM +1000, Stephen Rothwell wrote:
> 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);
>   

Fix looks good to me, thanks!

greg k-h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web