linux-kernel - Re: [PATCH 08/11] Bluetooth: Add support for CG2900 UART

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimjDCF4V9wGszVcuDYqZ8Qq0CYhCzxnxEKcibxN@mail.gmail.com>
Date:	Fri, 17 Dec 2010 13:02:52 +0100
From:	Vitaly Wool <vitalywool@...il.com>
To:	Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@...ricsson.com>
Cc:	Pavan Savoy <pavan_savoy@...y.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
	Lukasz Rymanowski <Lukasz.Rymanowski@...to.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Par-Gunnar Hjalmdahl <pghatwork@...il.com>
Subject: Re: [PATCH 08/11] Bluetooth: Add support for CG2900 UART

Hi Par,

so on the top level: this is yet another H4 implementation plus
channel-based packet routing, right?

Could you please also elaborate

More comments on the code are inlined.

> +#define MAIN_DEV               (uart_info->dev)

What is that for?

> + * cg2900_uart_suspend() - Called by Linux PM to put the device in a low power mode.
> + * @pdev:      Pointer to platform device.
> + * @state:     New state.
> + *
> + * In UART case, CG2900 driver does nothing on suspend.
> + *
> + * Returns:
> + *   0 - Success.
> + */
> +static int cg2900_uart_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> +       struct uart_info *uart_info = dev_get_drvdata(&pdev->dev);
> +
> +       if (uart_info->sleep_state == CHIP_POWERED_DOWN)
> +               return 0;
> +
> +       if (uart_info->sleep_state != CHIP_ASLEEP)
> +               return -EBUSY;
> +
> +       dev_dbg(MAIN_DEV, "New sleep_state: CHIP_SUSPENDED\n");
> +       uart_info->sleep_state = CHIP_SUSPENDED;
> +       return 0;
> +}

I don't think this is safe wrt work queue. What if it gets scheduled
when drivers are suspended?

Thanks,
   Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/