Re: PATCH: RFC: Broadcom serdev driver

[Ian Molton <ian@mnementh.co.uk>]

On 08/07/17 08:58, Marcel Holtmann wrote:
>> One oddity I've spotted is that the chip tries to go back to 115200 baud
>> after loading its firmware patch, which messes up the change to
>> oper_speed. I've worked around this by not using the set_baudrate hook,
>> just setting the operating speed after firmware loading in setup.
>
> I assume we addressed that in hci_uart. If not then we need to handle that there first.


In hci_uart_setup() in hci_serdev.c, there is the following:


        if (hu->init_speed)
                speed = hu->init_speed;
        else if (hu->proto->init_speed)
                speed = hu->proto->init_speed;
        else
                speed = 0;

        if (speed)
                serdev_device_set_baudrate(hu->serdev, speed);

        /* Operational speed if any */
        if (hu->oper_speed)
                speed = hu->oper_speed;
        else if (hu->proto->oper_speed)
                speed = hu->proto->oper_speed;
        else
                speed = 0;

        if (hu->proto->set_baudrate && speed) {
                err = hu->proto->set_baudrate(hu, speed);
                if (err)
                        BT_ERR("%s: failed to set baudrate", hdev->name);
                else
                        serdev_device_set_baudrate(hu->serdev, speed);
        }

        if (hu->proto->setup)
                return hu->proto->setup(hu);


The problem is that it attempts to set the baudrate to oper_speed
*prior* to calling the driver's setup() hook.

It *seems* simple enough that we could move the setup call to prior to
the change to oper_speed, but I am unsure how this might affect other
drivers.

I can test this on my driver (and implement the set_baudrate command
properly as a result.

I can send a patch to this effect if you want?

-Ian