Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754344AbcDVPB7 (ORCPT ); Fri, 22 Apr 2016 11:01:59 -0400 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:3714 "EHLO mx0a-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752473AbcDVPB5 convert rfc822-to-8bit (ORCPT ); Fri, 22 Apr 2016 11:01:57 -0400 From: Amitkumar Karwar To: Marcel Holtmann CC: Linux Bluetooth , LKML , Ganapathi Bhat , Cathy Luo , Nishant Sarmukadam Subject: RE: [PATCH v7] Bluetooth: hci_uart: Support firmware download for Marvell Thread-Topic: [PATCH v7] Bluetooth: hci_uart: Support firmware download for Marvell Thread-Index: AQHRjxYDCrmEZxJGlEWIcvhh9vcEqJ+TY7sA//+eY0CAAvDnAIAAjuGA//+RIhA= Date: Fri, 22 Apr 2016 15:01:52 +0000 Message-ID: <3f9ff7c183624e568e60681c86bcfdfd@SC-EXCH04.marvell.com> References: <1459845266-2771-1-git-send-email-akarwar@marvell.com> <2A69CC2B-1FC2-4148-8564-38335A87CCD7@holtmann.org> <2119fc93636742459899d50f2c1fcb8d@SC-EXCH04.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-22_11:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604220189 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1971 Lines: 52 Hi Marcel, > From: Marcel Holtmann [mailto:marcel@holtmann.org] > Sent: Friday, April 22, 2016 6:19 PM > To: Amitkumar Karwar > Cc: Linux Bluetooth; LKML; Ganapathi Bhat; Cathy Luo > Subject: Re: [PATCH v7] Bluetooth: hci_uart: Support firmware download > for Marvell > > Hi Amitkumar, > > >>>> + > >>>> +static int mrvl_setup(struct hci_uart *hu) { > >>>> + struct mrvl_data *mrvl = hu->priv; > >>>> + > >>>> + mrvl_init_fw_data(hu); > >>>> + set_bit(HCI_UART_DNLD_FW, &mrvl->flags); > >>>> + > >>>> + return hci_uart_dnld_fw(hu); > >>>> +} > >>> > >>> So this is clearly the wrong spot. When ->setup is called it is > >>> expected that HCI is ready. You are misusing it here. > >>> > >> > >> Sure. We will move this to mrvl_open() where HCI is not yet > initialized. > > > > We tried moving firmware download to mrvl_open(), but it's not > feasible. "hu->proto" is not yet initialized at that time. So when the > data/ack is received during firmware download, we can't have Marvell > specific handling. Also, I can see other vendor's (broadcomm, Intel) > have done firmware download in setup handler. > > firmware download in ->setup() is fine as long as it uses HCI commands. > If it does not use HCI commands, then we need to come up with something > new. > > The problem here is that for all intense and purposes once ->setup() is > called, then assumption is that you are in an HCI capable transport and > it is ready. > We have maintained a flag(in mrvl->flags) which remains on until firmware download gets completed. We drop HCI frames in "->enqueue" if firmware download is in progress. I don't see any possible issues if firmware download is included in ->setup(). request_firmware() API expects a device pointer (hdev->dev). We won't get valid pointer until HCI is ready. Also, we are downloading firmware data chunks through normal Tx path(scheduling hu->write_work etc) where hdev comes into picture. Let me know your thoughts. Regards, Amitkumar