From: Pavel Machek <pavel@ucw.cz>
To: pali.rohar@gmail.com, sre@debian.org, sre@ring0.de,
kernel list <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-omap@vger.kernel.org, tony@atomide.com, khilman@kernel.org,
aaro.koskinen@iki.fi, freemangordon@abv.bg, marcel@holtmann.org,
gustavo@padovan.org, johan.hedberg@gmail.com,
linux-bluetooth@vger.kernel.org
Subject: __hci_cmd_sync() not suitable for nokia h4p
Date: Tue, 9 Dec 2014 20:02:10 +0100 [thread overview]
Message-ID: <20141209190210.GA15641@amd> (raw)
Hi!
Major problem with Nokia H4P driver was, that it uses custom functions
instead of __hci_cmd_sync().
To recap, code was something like this: (You can see ifdefs with old
code and my new replacements).
....
len = sizeof(*neg_cmd) + sizeof(*neg_hdr) + H4_TYPE_SIZE;
#undef OLD
#ifdef OLD
skb = bt_skb_alloc(len, GFP_KERNEL);
if (!skb)
return -ENOMEM;
memset(skb->data, 0x00, len);
*skb_put(skb, 1) = H4_NEG_PKT;
neg_hdr = (struct hci_h4p_neg_hdr *)skb_put(skb, sizeof(*neg_hdr));
neg_cmd = (struct hci_h4p_neg_cmd *)skb_put(skb, sizeof(*neg_cmd));
neg_hdr->dlen = sizeof(*neg_cmd);
#else
struct {
struct hci_h4p_neg_cmd neg_cmd;
} data;
memset(&data, 0, len-1);
neg_cmd = &data.neg_cmd;
#endif
neg_cmd->ack = H4P_NEG_REQ;
neg_cmd->baud = cpu_to_le16(BT_BAUDRATE_DIVIDER/MAX_BAUD_RATE);
neg_cmd->proto = H4P_PROTO_BYTE;
neg_cmd->sys_clk = cpu_to_le16(sysclk);
hci_h4p_change_speed(info, INIT_SPEED);
printk("Setting up packet\n");
hci_h4p_set_rts(info, 1);
info->init_error = 0;
init_completion(&info->init_completion);
printk("skb_queue_tail\n");
#ifdef OLD
skb_queue_tail(&info->txq, skb);
spin_lock_irqsave(&info->lock, flags);
hci_h4p_outb(info, UART_IER, hci_h4p_inb(info, UART_IER) |
UART_IER_THRI);
spin_unlock_irqrestore(&info->lock, flags);
#else
printk("hci_cmd_sync\n");
// set_bit(HCI_RUNNING, &info->hdev->flags);
info->initing = 2;
skb = __hci_cmd_sync(info->hdev, H4_NEG_PKT << 8, sizeof(*neg_cmd), ((void *) &data), 20);
...but there's problem with __hci_cmd_sync(): the packet it produces
is one byte too long; for initialization, I can work around that with
<< 8, so the added zero is at the begining (and device will be still
initialized), but that is a) an extreme hack, b) only works for first
packet and c) means that __hci_cmd_sync() will not recognize the
reply, meaning it does not really help.
Are there different variants of the protocol I should switch to? Any
ideas? Should I forget about __hci_cmd_sync()?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: __hci_cmd_sync() not suitable for nokia h4p
Date: Tue, 9 Dec 2014 20:02:10 +0100 [thread overview]
Message-ID: <20141209190210.GA15641@amd> (raw)
Hi!
Major problem with Nokia H4P driver was, that it uses custom functions
instead of __hci_cmd_sync().
To recap, code was something like this: (You can see ifdefs with old
code and my new replacements).
....
len = sizeof(*neg_cmd) + sizeof(*neg_hdr) + H4_TYPE_SIZE;
#undef OLD
#ifdef OLD
skb = bt_skb_alloc(len, GFP_KERNEL);
if (!skb)
return -ENOMEM;
memset(skb->data, 0x00, len);
*skb_put(skb, 1) = H4_NEG_PKT;
neg_hdr = (struct hci_h4p_neg_hdr *)skb_put(skb, sizeof(*neg_hdr));
neg_cmd = (struct hci_h4p_neg_cmd *)skb_put(skb, sizeof(*neg_cmd));
neg_hdr->dlen = sizeof(*neg_cmd);
#else
struct {
struct hci_h4p_neg_cmd neg_cmd;
} data;
memset(&data, 0, len-1);
neg_cmd = &data.neg_cmd;
#endif
neg_cmd->ack = H4P_NEG_REQ;
neg_cmd->baud = cpu_to_le16(BT_BAUDRATE_DIVIDER/MAX_BAUD_RATE);
neg_cmd->proto = H4P_PROTO_BYTE;
neg_cmd->sys_clk = cpu_to_le16(sysclk);
hci_h4p_change_speed(info, INIT_SPEED);
printk("Setting up packet\n");
hci_h4p_set_rts(info, 1);
info->init_error = 0;
init_completion(&info->init_completion);
printk("skb_queue_tail\n");
#ifdef OLD
skb_queue_tail(&info->txq, skb);
spin_lock_irqsave(&info->lock, flags);
hci_h4p_outb(info, UART_IER, hci_h4p_inb(info, UART_IER) |
UART_IER_THRI);
spin_unlock_irqrestore(&info->lock, flags);
#else
printk("hci_cmd_sync\n");
// set_bit(HCI_RUNNING, &info->hdev->flags);
info->initing = 2;
skb = __hci_cmd_sync(info->hdev, H4_NEG_PKT << 8, sizeof(*neg_cmd), ((void *) &data), 20);
...but there's problem with __hci_cmd_sync(): the packet it produces
is one byte too long; for initialization, I can work around that with
<< 8, so the added zero is@the begining (and device will be still
initialized), but that is a) an extreme hack, b) only works for first
packet and c) means that __hci_cmd_sync() will not recognize the
reply, meaning it does not really help.
Are there different variants of the protocol I should switch to? Any
ideas? Should I forget about __hci_cmd_sync()?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next reply other threads:[~2014-12-09 19:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 19:02 Pavel Machek [this message]
2014-12-09 19:02 ` __hci_cmd_sync() not suitable for nokia h4p Pavel Machek
2014-12-09 19:07 ` Marcel Holtmann
2014-12-09 19:07 ` Marcel Holtmann
2014-12-09 20:13 ` Pavel Machek
2014-12-09 20:13 ` Pavel Machek
2014-12-09 21:19 ` Marcel Holtmann
2014-12-09 21:19 ` Marcel Holtmann
2014-12-10 13:15 ` Pavel Machek
2014-12-10 13:15 ` Pavel Machek
2014-12-11 12:58 ` Marcel Holtmann
2014-12-11 12:58 ` Marcel Holtmann
2014-12-11 22:13 ` Pavel Machek
2014-12-11 22:13 ` Pavel Machek
2014-12-11 22:25 ` Marcel Holtmann
2014-12-11 22:25 ` Marcel Holtmann
2014-12-12 9:51 ` Pavel Machek
2014-12-12 9:51 ` Pavel Machek
2014-12-12 12:28 ` Marcel Holtmann
2014-12-12 12:28 ` Marcel Holtmann
2014-12-12 1:15 ` Sebastian Reichel
2014-12-12 1:15 ` Sebastian Reichel
2014-12-12 12:14 ` Pavel Machek
2014-12-12 12:14 ` Pavel Machek
2014-12-13 17:35 ` Sebastian Reichel
2014-12-13 17:35 ` Sebastian Reichel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141209190210.GA15641@amd \
--to=pavel@ucw.cz \
--cc=aaro.koskinen@iki.fi \
--cc=freemangordon@abv.bg \
--cc=gustavo@padovan.org \
--cc=johan.hedberg@gmail.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=pali.rohar@gmail.com \
--cc=sre@debian.org \
--cc=sre@ring0.de \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.