Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.60.83 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;
Subject: Re: [PATCH] serial: core: Use cons->index for preferred console
 registration
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Michal Simek <michal.simek@xilinx.com>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        Michal Simek <monstr@monstr.eu>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jiri Slaby <jslaby@suse.com>,
        "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux-Renesas <linux-renesas-soc@vger.kernel.org>
References: <4a877f1c7189a7c45b59a6ebfc3de607e8758949.1567434470.git.michal.simek@xilinx.com>
 <CAMuHMdWY2VsY-CyAxSvpm1XYicAWqU7NORSQofQ+T195DwyLUg@mail.gmail.com>
 <7284590f-2b74-1b47-2d61-783ad8d5f46f@monstr.eu>
 <CAMuHMdWZYALZB1bP5Mtoq4Nj5iubzdWBf1vRY9Mh5QvjCDhBgA@mail.gmail.com>
 <622f4c5e-e3ed-3f91-254d-78d905de79c9@xilinx.com>
 <20191015175422.GA1072965@kroah.com>
From:   Michal Simek <michal.simek@xilinx.com>
Message-ID: <1ef25e71-d617-77ca-31f8-09fb9b3ebbb8@xilinx.com>
Date:   Wed, 16 Oct 2019 12:37:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191015175422.GA1072965@kroah.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2019 10:37:23.4048
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d9215101-4f61-4e31-e3db-08d75224d4a2
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.83];Helo=[xsj-pvapsmtpgw01]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6SPR01MB13
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 15. 10. 19 19:54, Greg Kroah-Hartman wrote:
> On Tue, Oct 15, 2019 at 04:36:56PM +0200, Michal Simek wrote:
>> On 15. 10. 19 11:51, Geert Uytterhoeven wrote:
>>> Hi Michal,
>>>
>>> On Tue, Oct 15, 2019 at 11:22 AM Michal Simek <monstr@monstr.eu> wrote:
>>>> On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
>>>>> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>> The reason for this patch is xilinx_uartps driver which create one dynamic
>>>>>> instance per IP with unique major and minor combinations. drv->nr is in
>>>>>> this case all the time setup to 1. That means that uport->line is all the
>>>>>> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
>>>>>> for example ttyPS3.
>>>>>>
>>>>>> register_console() is looping over console_cmdline array and looking for
>>>>>> proper name/index combination which is in our case ttyPS/3.
>>>>>> That's why every instance of driver needs to be registered with proper
>>>>>> combination of name/number (ttyPS/3). Using uport->line is doing
>>>>>> registration with ttyPS/0 which is wrong that's why proper console index
>>>>>> should be used which is in cons->index field.
>>>>>>
>>>>>> Also it is visible that recording console should be done based on
>>>>>> information about console not about the port but in most cases numbers are
>>>>>> the same and xilinx_uartps is only one exception now.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>>>>
>>>>> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
>>>>> for preferred console registration") in tty-next.
>>>>>
>>>>> This has been bisected to break the serial console on (at least)
>>>>> r8a7791/koelsch and r8a7795/h3-salvator-xs.
>>>>>
>>>>> The line "printk: console [ttySC0] enabled" is no longer printed.
>>>>> The system continues booting without any serial console output, and the
>>>>> login prompt never appears on the serial console.
>>>>>
>>>>> Reverting this commit fixes the issue.
>>>>
>>>> Sorry for trouble with this patch. Can you please point me to dts files
>>>> for these boards and also what's the value you have in uport->line and
>>>
>>> arch/arm/boot/dts/r8a7791-koelsch.dts
>>> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
>>>
>>>> uport->cons->index?
>>>
>>> On r8a7791/koelsch:
>>>
>>>     Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>>>     platform serial8250: uport->line = 0, uport->cons->index = -1
>>>     platform serial8250: uport->line = 1, uport->cons->index = -1
>>>     platform serial8250: uport->line = 2, uport->cons->index = -1
>>>     platform serial8250: uport->line = 3, uport->cons->index = -1
>>>     SuperH (H)SCI(F) driver initialized
>>>   * sh-sci e6e60000.serial: uport->line = 0, uport->cons->index = -1
>>>   * e6e60000.serial: ttySC0 at MMIO 0xe6e60000 (irq = 79, base_baud =
>>> 0) is a scif
>>>     printk: console [ttySC0] enabled
>>>     sh-sci e6e68000.serial: uport->line = 1, uport->cons->index = 0
>>>     e6e68000.serial: ttySC1 at MMIO 0xe6e68000 (irq = 80, base_baud =
>>> 0) is a scif
>>>
>>> On r8a7795/salvator-xs:
>>>
>>>     sh-sci e6550000.serial: uport->line = 1, uport->cons->index = -1
>>>     e6550000.serial: ttySC1 at MMIO 0xe6550000 (irq = 34, base_baud =
>>> 0) is a hscif
>>>   * sh-sci e6e88000.serial: uport->line = 0, uport->cons->index = -1
>>>   * e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 120, base_baud =
>>> 0) is a scif
>>>     printk: console [ttySC0] enabled
>>>
>>> Actual serial consoles marked with *.
>>>
>>> There are no 8250 serial ports in the system, shmobile_defconfig just includes
>>> driver support for it.
>>
>> ok. I will take a look at why it is not initialized in this case. Do you
>> have any qemu available for these boards?
>>
>> Greg: Please revert this patch I will investigate why it is failing.
> 
> Which patch exactly?  Can you provide a revert?  That makes it easiest
> for me.

Sure. Revert sent.

Thanks,
Michal