* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Gustavo F. Padovan @ 2010-07-23 18:05 UTC (permalink / raw)
To: Santiago Carot-Nemesio
Cc: Elvis Pfützenreuter, José Antonio Santos Cadenas,
Luiz Augusto von Dentz, Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <4C49CEB5.60600@libresoft.es>
Hi Santiago,
* Santiago Carot-Nemesio <scarot@libresoft.es> [2010-07-23 19:17:41 +0200]:
> Hi,
> On 07/23/10 13:30, Elvis Pfützenreuter wrote:
> > On 23/07/2010, at 07:44, José Antonio Santos Cadenas wrote:
> >
> >
> >> Hi,
> >>
> >> El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió:
> >>
> >>> Hi,
> >>>
> >>> On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg<johan.hedberg@gmail.com>
> >>>
> >> wrote:
> >>
> >>>> The SDP code in libbluetooth is probably the absolute worst place to
> >>>> look for good examples. In this case the second variable in the function
> >>>> is completely unnecessary. Just assign the malloc return directly to the
> >>>> mcap_md_req pointer and get rid of the uint8_t* variable.
> >>>>
> >>>> Btw, I'd like to understand why we should use different acceptance
> >>>> criteria for your patches compared to everything else that gets
> >>>> submitted to BlueZ. The convention (which I'm sure you've noticed if you
> >>>> follow the list) is that when issues are found in submitted patches the
> >>>> submitter is requested to fix the issue in the patch and resubmit a new
> >>>> version of the patch. You're essentially requesting for buggy patches to
> >>>> be accepted as such and only fix the issues through new patches on top
> >>>> of the buggy ones.
> >>>>
> >>> I completely agree with this, one of the reason for this convention is
> >>> that we don't want this changes split apart because they probably
> >>> cannot be reverted individually. Another point is the history will be
> >>> completely disorganized if we start to accept those fixes separately,
> >>> it worth mention that this can eventually happen with patches already
> >>> upstream, but then it is normally a regression fix and as such we
> >>> normally mention the original commit which has caused it. I would
> >>> understand if we were in the old days of cvs, but with git it is
> >>> pretty simple to rearrange the changes, just use git rebase -i + git
> >>> reset or whatever other form to get this fixed in place.
> >>>
> >> We agree with you two. This is the complete development history that we have
> >> now. We sent it like this because we understood that keeping the history will
> >> be better. We don't care sending a different history with all the bug
> >> corrections amended.
> >>
> >> About the use of git rebase, it is not the first time that we do this and
> >> because of this we know that rebase some commits will make some of the
> >> following commits not compile. It will be a long and hard work to fix this, so
> >> it will be better and easier to create a new "virtual" history that splits the
> >> whole implementation in smaller patches.
> >>
> > In this line, it is better to put MCAP files inside health/ as Marcel asked.
> Don't worry. I will set MCAP into health directory. I don't try to
> explain anymore that MCAP is not only a health focused specification. It
> is like I want to make program that only requires TCP to work and you
> are forcing to me to import HTTP libraries, change HTTP by HDP and TCP
> by MCAP and you will get the analogy.
> I just hope that nobody get surprised if in the coming years are new
> non-health related profiles that require use MCAP and you need import
> Health to implement it.
If that happens we can move to new 'mcap' directory. For now only HDP
uses it, so makes sense keep iut inside health/
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Gustavo F. Padovan @ 2010-07-23 18:01 UTC (permalink / raw)
To: José Antonio Santos Cadenas
Cc: Luiz Augusto von Dentz, Santiago Carot-Nemesio,
Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <201007231244.42402.santoscadenas@gmail.com>
Hi José,
* José Antonio Santos Cadenas <santoscadenas@gmail.com> [2010-07-23 12:44:42 +0200]:
> Hi,
>
> El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió:
> > Hi,
> >
> > On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg <johan.hedberg@gmail.com>
> wrote:
> > > The SDP code in libbluetooth is probably the absolute worst place to
> > > look for good examples. In this case the second variable in the function
> > > is completely unnecessary. Just assign the malloc return directly to the
> > > mcap_md_req pointer and get rid of the uint8_t* variable.
> > >
> > > Btw, I'd like to understand why we should use different acceptance
> > > criteria for your patches compared to everything else that gets
> > > submitted to BlueZ. The convention (which I'm sure you've noticed if you
> > > follow the list) is that when issues are found in submitted patches the
> > > submitter is requested to fix the issue in the patch and resubmit a new
> > > version of the patch. You're essentially requesting for buggy patches to
> > > be accepted as such and only fix the issues through new patches on top
> > > of the buggy ones.
> >
> > I completely agree with this, one of the reason for this convention is
> > that we don't want this changes split apart because they probably
> > cannot be reverted individually. Another point is the history will be
> > completely disorganized if we start to accept those fixes separately,
> > it worth mention that this can eventually happen with patches already
> > upstream, but then it is normally a regression fix and as such we
> > normally mention the original commit which has caused it. I would
> > understand if we were in the old days of cvs, but with git it is
> > pretty simple to rearrange the changes, just use git rebase -i + git
> > reset or whatever other form to get this fixed in place.
>
> We agree with you two. This is the complete development history that we have
> now. We sent it like this because we understood that keeping the history will
> be better. We don't care sending a different history with all the bug
> corrections amended.
You can keep the history and at same time do all the fixes in the
patches and amend them. That's not too hard.
>
> About the use of git rebase, it is not the first time that we do this and
> because of this we know that rebase some commits will make some of the
> following commits not compile. It will be a long and hard work to fix this, so
> it will be better and easier to create a new "virtual" history that splits the
> whole implementation in smaller patches.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* How to past connect complete event status (page timeout) to apps
From: Ed Tsang @ 2010-07-23 17:48 UTC (permalink / raw)
To: Bluettooth Linux
Hi, I tried to implement my apps to do different things depend on the failed
connection attempt.
On Hci dump I could saw the connect complete status is different depend on the
actual failure (e.g. 0x10 accept timeout, 0x06, PIN missing, 0x04 page
timeout). But the apps (base on obex-client) is not able to see those status
code.
The obex-client attempt a sdp_connect and then g_io_add_watch. On the
callback, we could see the G_IO_ERROR but I could not figure out a way to get
more detail on the failed condition. I tried look into the Bluez and could not
figure what to change to pass those connect event status up..
Anyone could offer some advise/hint...
Cheers,
Ed
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Santiago Carot-Nemesio @ 2010-07-23 17:17 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: José Antonio Santos Cadenas, Luiz Augusto von Dentz,
Gustavo F. Padovan, Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <91F64B18-B10E-4A87-879C-7EF07BC34194@signove.com>
Hi,
On 07/23/10 13:30, Elvis Pfützenreuter wrote:
> On 23/07/2010, at 07:44, José Antonio Santos Cadenas wrote:
>
>
>> Hi,
>>
>> El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió:
>>
>>> Hi,
>>>
>>> On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg<johan.hedberg@gmail.com>
>>>
>> wrote:
>>
>>>> The SDP code in libbluetooth is probably the absolute worst place to
>>>> look for good examples. In this case the second variable in the function
>>>> is completely unnecessary. Just assign the malloc return directly to the
>>>> mcap_md_req pointer and get rid of the uint8_t* variable.
>>>>
>>>> Btw, I'd like to understand why we should use different acceptance
>>>> criteria for your patches compared to everything else that gets
>>>> submitted to BlueZ. The convention (which I'm sure you've noticed if you
>>>> follow the list) is that when issues are found in submitted patches the
>>>> submitter is requested to fix the issue in the patch and resubmit a new
>>>> version of the patch. You're essentially requesting for buggy patches to
>>>> be accepted as such and only fix the issues through new patches on top
>>>> of the buggy ones.
>>>>
>>> I completely agree with this, one of the reason for this convention is
>>> that we don't want this changes split apart because they probably
>>> cannot be reverted individually. Another point is the history will be
>>> completely disorganized if we start to accept those fixes separately,
>>> it worth mention that this can eventually happen with patches already
>>> upstream, but then it is normally a regression fix and as such we
>>> normally mention the original commit which has caused it. I would
>>> understand if we were in the old days of cvs, but with git it is
>>> pretty simple to rearrange the changes, just use git rebase -i + git
>>> reset or whatever other form to get this fixed in place.
>>>
>> We agree with you two. This is the complete development history that we have
>> now. We sent it like this because we understood that keeping the history will
>> be better. We don't care sending a different history with all the bug
>> corrections amended.
>>
>> About the use of git rebase, it is not the first time that we do this and
>> because of this we know that rebase some commits will make some of the
>> following commits not compile. It will be a long and hard work to fix this, so
>> it will be better and easier to create a new "virtual" history that splits the
>> whole implementation in smaller patches.
>>
> In this line, it is better to put MCAP files inside health/ as Marcel asked.
Don't worry. I will set MCAP into health directory. I don't try to
explain anymore that MCAP is not only a health focused specification. It
is like I want to make program that only requires TCP to work and you
are forcing to me to import HTTP libraries, change HTTP by HDP and TCP
by MCAP and you will get the analogy.
I just hope that nobody get surprised if in the coming years are new
non-health related profiles that require use MCAP and you need import
Health to implement it.
Regards.
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Defer SCO setup if mode change is pending
From: Ron Shaffer @ 2010-07-23 15:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1279853339.2621.14.camel@localhost.localdomain>
Marcel:
> Hi Ron,
>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 6c57fc7..9aee8c5 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
>>
>> BT_DBG("%s status 0x%x", hdev->name, status);
>>
>> - if (!status)
>> - return;
>> -
>> cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
>> if (!cp)
>> return;
>> @@ -785,8 +782,15 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
>> hci_dev_lock(hdev);
>>
>> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
>> - if (conn)
>> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> + if (conn) {
>> + if (status) {
>> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> +
>> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
>> + &conn->pend))
>> + hci_sco_setup(conn, status);
>> + }
>> + }
>>
>> hci_dev_unlock(hdev);
>> }
>
> this change now makes it worse, please revert to initial
>
> if (!status)
> return;
>
> check at the top and the just do
>
> if (conn) {
> clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>
> if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
> hci_sco_setup(conn, status);
> }
>
> The only reason why I moved the status check down, because I was not
> thinking straight and overlooked that in case of success we don't wanna
> do a single thing here.
Makes sense. Done.
>
>> @@ -798,9 +802,6 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
>>
>> BT_DBG("%s status 0x%x", hdev->name, status);
>>
>> - if (!status)
>> - return;
>> -
>> cp = hci_sent_cmd_data(hdev, HCI_OP_EXIT_SNIFF_MODE);
>> if (!cp)
>> return;
>> @@ -808,8 +809,15 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
>> hci_dev_lock(hdev);
>>
>> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
>> - if (conn)
>> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> + if (conn) {
>> + if (status) {
>> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> +
>> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
>> + &conn->pend))
>> + hci_sco_setup(conn, status);
>> + }
>> + }
>>
>> hci_dev_unlock(hdev);
>> }
>
> Same applies here btw.
Same. Done.
>
>> @@ -915,20 +923,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
>> } else
>> conn->state = BT_CLOSED;
>>
>> - if (conn->type == ACL_LINK) {
>> - struct hci_conn *sco = conn->link;
>> - if (sco) {
>> - if (!ev->status) {
>> - if (lmp_esco_capable(hdev))
>> - hci_setup_sync(sco, conn->handle);
>> - else
>> - hci_add_sco(sco, conn->handle);
>> - } else {
>> - hci_proto_connect_cfm(sco, ev->status);
>> - hci_conn_del(sco);
>> - }
>> - }
>> - }
>> + if (conn->type == ACL_LINK)
>> + hci_sco_setup(conn, ev->status);
>>
>> if (ev->status) {
>> hci_proto_connect_cfm(conn, ev->status);
>> @@ -1478,6 +1474,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
>> conn->power_save = 1;
>> else
>> conn->power_save = 0;
>> + } else if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
>> + &conn->pend)) {
>> + hci_sco_setup(conn, ev->status);
>> }
>> }
>
> Please don't do else if here. Just add a separate check like I had in my
> initial patch. We don't wanna depend on two flags pending flags set
> here. If the SCO setup is pending, then we execute it. No matter how we
> reached that point. It is important that even if we receive a mode
> change without us triggering it, that we clear any potential SCO pending
> flag.
Hmmm. I know I found a bug here, but I can't remember how it manifested
itself. Today, I can't reproduce it, so either I was seeing things or
I'm losing it.
I'll revert it back, and if I run across the issue again, we can fix it
later.
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 6/6] pcmcia: remove cs_types.h
From: Marcel Holtmann @ 2010-07-23 15:28 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial
In-Reply-To: <1279874305-21191-6-git-send-email-linux@dominikbrodowski.net>
Hi Dominik,
> Remove cs_types.h which is no longer needed: Most definitions aren't
> used at all, a few can be made away with, and two remaining definitions
> (typedefs, unfortunatley) may be moved to more specific places.
>
> CC: netdev@vger.kernel.org
> CC: linux-wireless@vger.kernel.org
> CC: linux-ide@vger.kernel.org
> CC: linux-usb@vger.kernel.org
> CC: laforge@gnumonks.org
> CC: linux-mtd@lists.infradead.org
> CC: linux-bluetooth@vger.kernel.org
> CC: alsa-devel@alsa-project.org
> CC: linux-serial@vger.kernel.org
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
> ---
> Documentation/pcmcia/driver-changes.txt | 5 +++
> drivers/ata/pata_pcmcia.c | 1 -
> drivers/bluetooth/bluecard_cs.c | 1 -
> drivers/bluetooth/bt3c_cs.c | 1 -
> drivers/bluetooth/btuart_cs.c | 1 -
> drivers/bluetooth/dtl1_cs.c | 1 -
> drivers/char/pcmcia/cm4000_cs.c | 1 -
> drivers/char/pcmcia/cm4040_cs.c | 1 -
> drivers/char/pcmcia/ipwireless/main.h | 1 -
> drivers/char/pcmcia/ipwireless/tty.h | 1 -
> drivers/char/pcmcia/synclink_cs.c | 1 -
> drivers/ide/ide-cs.c | 1 -
> drivers/isdn/hardware/avm/avm_cs.c | 1 -
> drivers/isdn/hisax/avma1_cs.c | 1 -
> drivers/isdn/hisax/elsa_cs.c | 1 -
> drivers/isdn/hisax/sedlbauer_cs.c | 1 -
> drivers/isdn/hisax/teles_cs.c | 1 -
> drivers/mmc/host/sdricoh_cs.c | 1 -
> drivers/mtd/maps/pcmciamtd.c | 1 -
> drivers/net/pcmcia/3c574_cs.c | 1 -
> drivers/net/pcmcia/3c589_cs.c | 1 -
> drivers/net/pcmcia/axnet_cs.c | 1 -
> drivers/net/pcmcia/com20020_cs.c | 1 -
> drivers/net/pcmcia/fmvj18x_cs.c | 1 -
> drivers/net/pcmcia/ibmtr_cs.c | 1 -
> drivers/net/pcmcia/nmclan_cs.c | 1 -
> drivers/net/pcmcia/pcnet_cs.c | 5 +--
> drivers/net/pcmcia/smc91c92_cs.c | 1 -
> drivers/net/pcmcia/xirc2ps_cs.c | 1 -
> drivers/net/wireless/airo_cs.c | 1 -
> drivers/net/wireless/atmel_cs.c | 1 -
> drivers/net/wireless/b43/pcmcia.c | 1 -
> drivers/net/wireless/hostap/hostap_cs.c | 3 +-
> drivers/net/wireless/libertas/if_cs.c | 1 -
> drivers/net/wireless/orinoco/orinoco_cs.c | 1 -
> drivers/net/wireless/orinoco/spectrum_cs.c | 1 -
> drivers/net/wireless/ray_cs.c | 1 -
> drivers/net/wireless/wl3501_cs.c | 10 +-----
> drivers/parport/parport_cs.c | 1 -
> drivers/pcmcia/au1000_generic.h | 1 -
> drivers/pcmcia/au1000_pb1x00.c | 2 -
> drivers/pcmcia/cistpl.c | 1 -
> drivers/pcmcia/cs.c | 1 -
> drivers/pcmcia/db1xxx_ss.c | 1 -
> drivers/pcmcia/ds.c | 1 -
> drivers/pcmcia/i82092.c | 1 -
> drivers/pcmcia/i82365.c | 1 -
> drivers/pcmcia/m32r_cfc.c | 1 -
> drivers/pcmcia/m32r_pcc.c | 1 -
> drivers/pcmcia/m8xx_pcmcia.c | 1 -
> drivers/pcmcia/pcmcia_cis.c | 1 -
> drivers/pcmcia/pcmcia_resource.c | 1 -
> drivers/pcmcia/pd6729.c | 1 -
> drivers/pcmcia/pxa2xx_base.c | 1 -
> drivers/pcmcia/rsrc_iodyn.c | 1 -
> drivers/pcmcia/rsrc_mgr.c | 1 -
> drivers/pcmcia/rsrc_nonstatic.c | 1 -
> drivers/pcmcia/sa1100_generic.c | 1 -
> drivers/pcmcia/soc_common.h | 1 -
> drivers/pcmcia/socket_sysfs.c | 1 -
> drivers/pcmcia/tcic.c | 1 -
> drivers/pcmcia/xxs1500_ss.c | 1 -
> drivers/pcmcia/yenta_socket.c | 1 -
> drivers/scsi/pcmcia/aha152x_stub.c | 1 -
> drivers/scsi/pcmcia/fdomain_stub.c | 1 -
> drivers/scsi/pcmcia/nsp_cs.c | 1 -
> drivers/scsi/pcmcia/qlogic_stub.c | 1 -
> drivers/scsi/pcmcia/sym53c500_cs.c | 1 -
> drivers/serial/serial_cs.c | 1 -
> drivers/ssb/main.c | 1 -
> drivers/ssb/pcmcia.c | 1 -
> drivers/ssb/scan.c | 1 -
> drivers/staging/comedi/drivers/cb_das16_cs.c | 1 -
> drivers/staging/comedi/drivers/das08_cs.c | 1 -
> drivers/staging/comedi/drivers/ni_daq_700.c | 1 -
> drivers/staging/comedi/drivers/ni_daq_dio24.c | 1 -
> drivers/staging/comedi/drivers/ni_labpc_cs.c | 1 -
> drivers/staging/comedi/drivers/ni_mio_cs.c | 1 -
> drivers/staging/comedi/drivers/quatech_daqp_cs.c | 1 -
> drivers/staging/wlags49_h2/wl_cs.c | 1 -
> drivers/staging/wlags49_h2/wl_internal.h | 1 -
> drivers/telephony/ixj_pcmcia.c | 1 -
> drivers/usb/host/sl811_cs.c | 5 +--
> include/pcmcia/cistpl.h | 2 +
> include/pcmcia/cs.h | 10 +-----
> include/pcmcia/cs_types.h | 40 ----------------------
> include/pcmcia/ds.h | 3 +-
> include/pcmcia/ss.h | 1 -
> sound/pcmcia/pdaudiocf/pdaudiocf.h | 1 -
> sound/pcmcia/vx/vxpocket.h | 1 -
> 90 files changed, 14 insertions(+), 151 deletions(-)
> delete mode 100644 include/pcmcia/cs_types.h
for drivers/bluetooth/
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 6/6] pcmcia: remove cs_types.h
From: John W. Linville @ 2010-07-23 13:27 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-pcmcia, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial
In-Reply-To: <1279874305-21191-6-git-send-email-linux@dominikbrodowski.net>
On Fri, Jul 23, 2010 at 10:38:25AM +0200, Dominik Brodowski wrote:
> Remove cs_types.h which is no longer needed: Most definitions aren't
> used at all, a few can be made away with, and two remaining definitions
> (typedefs, unfortunatley) may be moved to more specific places.
>
> CC: netdev@vger.kernel.org
> CC: linux-wireless@vger.kernel.org
> CC: linux-ide@vger.kernel.org
> CC: linux-usb@vger.kernel.org
> CC: laforge@gnumonks.org
> CC: linux-mtd@lists.infradead.org
> CC: linux-bluetooth@vger.kernel.org
> CC: alsa-devel@alsa-project.org
> CC: linux-serial@vger.kernel.org
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
ACK for the drivers/net/wireless bits...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Elvis Pfützenreuter @ 2010-07-23 11:30 UTC (permalink / raw)
To: José Antonio Santos Cadenas
Cc: Luiz Augusto von Dentz, Santiago Carot-Nemesio,
Gustavo F. Padovan, Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <201007231244.42402.santoscadenas@gmail.com>
On 23/07/2010, at 07:44, José Antonio Santos Cadenas wrote:
> Hi,
>
> El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió:
>> Hi,
>>
>> On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg <johan.hedberg@gmail.com>
> wrote:
>>> The SDP code in libbluetooth is probably the absolute worst place to
>>> look for good examples. In this case the second variable in the function
>>> is completely unnecessary. Just assign the malloc return directly to the
>>> mcap_md_req pointer and get rid of the uint8_t* variable.
>>>
>>> Btw, I'd like to understand why we should use different acceptance
>>> criteria for your patches compared to everything else that gets
>>> submitted to BlueZ. The convention (which I'm sure you've noticed if you
>>> follow the list) is that when issues are found in submitted patches the
>>> submitter is requested to fix the issue in the patch and resubmit a new
>>> version of the patch. You're essentially requesting for buggy patches to
>>> be accepted as such and only fix the issues through new patches on top
>>> of the buggy ones.
>>
>> I completely agree with this, one of the reason for this convention is
>> that we don't want this changes split apart because they probably
>> cannot be reverted individually. Another point is the history will be
>> completely disorganized if we start to accept those fixes separately,
>> it worth mention that this can eventually happen with patches already
>> upstream, but then it is normally a regression fix and as such we
>> normally mention the original commit which has caused it. I would
>> understand if we were in the old days of cvs, but with git it is
>> pretty simple to rearrange the changes, just use git rebase -i + git
>> reset or whatever other form to get this fixed in place.
>
> We agree with you two. This is the complete development history that we have
> now. We sent it like this because we understood that keeping the history will
> be better. We don't care sending a different history with all the bug
> corrections amended.
>
> About the use of git rebase, it is not the first time that we do this and
> because of this we know that rebase some commits will make some of the
> following commits not compile. It will be a long and hard work to fix this, so
> it will be better and easier to create a new "virtual" history that splits the
> whole implementation in smaller patches.
In this line, it is better to put MCAP files inside health/ as Marcel asked.
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: José Antonio Santos Cadenas @ 2010-07-23 10:44 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Santiago Carot-Nemesio, Gustavo F. Padovan,
Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <AANLkTikCYPQ-e45YeUa4KCBAnfdX2Eofjq0YuVQMwpxL@mail.gmail.com>
Hi,
El Friday 23 July 2010 12:31:03 Luiz Augusto von Dentz escribió:
> Hi,
>
> On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg <johan.hedberg@gmail.com>
wrote:
> > The SDP code in libbluetooth is probably the absolute worst place to
> > look for good examples. In this case the second variable in the function
> > is completely unnecessary. Just assign the malloc return directly to the
> > mcap_md_req pointer and get rid of the uint8_t* variable.
> >
> > Btw, I'd like to understand why we should use different acceptance
> > criteria for your patches compared to everything else that gets
> > submitted to BlueZ. The convention (which I'm sure you've noticed if you
> > follow the list) is that when issues are found in submitted patches the
> > submitter is requested to fix the issue in the patch and resubmit a new
> > version of the patch. You're essentially requesting for buggy patches to
> > be accepted as such and only fix the issues through new patches on top
> > of the buggy ones.
>
> I completely agree with this, one of the reason for this convention is
> that we don't want this changes split apart because they probably
> cannot be reverted individually. Another point is the history will be
> completely disorganized if we start to accept those fixes separately,
> it worth mention that this can eventually happen with patches already
> upstream, but then it is normally a regression fix and as such we
> normally mention the original commit which has caused it. I would
> understand if we were in the old days of cvs, but with git it is
> pretty simple to rearrange the changes, just use git rebase -i + git
> reset or whatever other form to get this fixed in place.
We agree with you two. This is the complete development history that we have
now. We sent it like this because we understood that keeping the history will
be better. We don't care sending a different history with all the bug
corrections amended.
About the use of git rebase, it is not the first time that we do this and
because of this we know that rebase some commits will make some of the
following commits not compile. It will be a long and hard work to fix this, so
it will be better and easier to create a new "virtual" history that splits the
whole implementation in smaller patches.
Regards.
Jose.
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Luiz Augusto von Dentz @ 2010-07-23 10:31 UTC (permalink / raw)
To: Santiago Carot-Nemesio, Gustavo F. Padovan,
Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <20100723095813.GA17429@jh-x301>
Hi,
On Fri, Jul 23, 2010 at 12:58 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> The SDP code in libbluetooth is probably the absolute worst place to
> look for good examples. In this case the second variable in the function
> is completely unnecessary. Just assign the malloc return directly to the
> mcap_md_req pointer and get rid of the uint8_t* variable.
>
> Btw, I'd like to understand why we should use different acceptance
> criteria for your patches compared to everything else that gets
> submitted to BlueZ. The convention (which I'm sure you've noticed if you
> follow the list) is that when issues are found in submitted patches the
> submitter is requested to fix the issue in the patch and resubmit a new
> version of the patch. You're essentially requesting for buggy patches to
> be accepted as such and only fix the issues through new patches on top
> of the buggy ones.
I completely agree with this, one of the reason for this convention is
that we don't want this changes split apart because they probably
cannot be reverted individually. Another point is the history will be
completely disorganized if we start to accept those fixes separately,
it worth mention that this can eventually happen with patches already
upstream, but then it is normally a regression fix and as such we
normally mention the original commit which has caused it. I would
understand if we were in the old days of cvs, but with git it is
pretty simple to rearrange the changes, just use git rebase -i + git
reset or whatever other form to get this fixed in place.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [patch -next] bluetooth/hci_ath: kfree() => kfree_skb()
From: Dan Carpenter @ 2010-07-23 10:11 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Suraj Sumangala, linux-bluetooth, kernel-janitors
sk_buffs have to be freed with kfree_skb() instead of kfree().
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index 5ab258b..74a8f61 100755
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -163,7 +163,7 @@ static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb)
struct ath_struct *ath = hu->priv;
if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) {
- kfree(skb);
+ kfree_skb(skb);
return 0;
}
^ permalink raw reply related
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Johan Hedberg @ 2010-07-23 9:58 UTC (permalink / raw)
To: Santiago Carot-Nemesio
Cc: Gustavo F. Padovan, Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <4C49658D.4090906@libresoft.es>
Hi,
On Fri, Jul 23, 2010, Santiago Carot-Nemesio wrote:
> >>+static uint8_t *create_req(uint8_t op, uint16_t mdl_id)
> >>+{
> >>+ uint8_t *req;
> >>+ mcap_md_req *req_cmd;
> >>+
> >>+ req = g_malloc0(sizeof(mcap_md_req));
> >>+
> >>+ req_cmd = (mcap_md_req *)req;
> >>+ req_cmd->op = op;
> >>+ req_cmd->mdl = htons(mdl_id);
> >>+
> >>+ return req;
> >>+}
> >Why are you casting here? I would expect mcap_md_req * as return type
> >here. If the problem is with mcap_send_std_opcode() you can used "void *" as
> >parameter type there.
> >
> I don't see why is better doing it as you say.
> In fact I did it to make the code similar to other bluez modules
> like sdp. You can see the sdp_send_req_w4_rsp and the sdp_send_req
> functions in sdp.c to find similarities with my code.
The SDP code in libbluetooth is probably the absolute worst place to
look for good examples. In this case the second variable in the function
is completely unnecessary. Just assign the malloc return directly to the
mcap_md_req pointer and get rid of the uint8_t* variable.
Btw, I'd like to understand why we should use different acceptance
criteria for your patches compared to everything else that gets
submitted to BlueZ. The convention (which I'm sure you've noticed if you
follow the list) is that when issues are found in submitted patches the
submitter is requested to fix the issue in the patch and resubmit a new
version of the patch. You're essentially requesting for buggy patches to
be accepted as such and only fix the issues through new patches on top
of the buggy ones.
Johan
^ permalink raw reply
* [PATCH 1/1] Bluetooth: RPN negotiation fix
From: Yuri Kululin @ 2010-07-23 9:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: ext-yuri.kululin
In-Reply-To: <1279879032-27955-1-git-send-email-ext-yuri.kululin@nokia.com>
According to the ETSI 3GPP TS 07.10 the default bit rate value for RFCOMM
is 9600 bit/s. Return this bit rate in case of RPN request and accept other
sane bit rates proposed by the sender in RPM command.
Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com>
---
net/bluetooth/rfcomm/core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 7dca91b..16b79f3 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1415,8 +1415,8 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
return 0;
if (len == 1) {
- /* This is a request, return default settings */
- bit_rate = RFCOMM_RPN_BR_115200;
+ /* This is a request, return default (according to ETSI TS 07.10) settings */
+ bit_rate = RFCOMM_RPN_BR_9600;
data_bits = RFCOMM_RPN_DATA_8;
stop_bits = RFCOMM_RPN_STOP_1;
parity = RFCOMM_RPN_PARITY_NONE;
@@ -1431,9 +1431,9 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_BITRATE)) {
bit_rate = rpn->bit_rate;
- if (bit_rate != RFCOMM_RPN_BR_115200) {
+ if (bit_rate > RFCOMM_RPN_BR_230400) {
BT_DBG("RPN bit rate mismatch 0x%x", bit_rate);
- bit_rate = RFCOMM_RPN_BR_115200;
+ bit_rate = RFCOMM_RPN_BR_9600;
rpn_mask ^= RFCOMM_RPN_PM_BITRATE;
}
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH 0/1] Bluetooth: RPN negotiation fix
From: Yuri Kululin @ 2010-07-23 9:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: ext-yuri.kululin
RFCOMM port settings can be changed by using RPN command.
If the bit rate 115200 bit/s (which is not default according to
the ETSI 3GPP TS 07.10) is not supported by sender of RPN command
sender and receiver will never find an agreement. Currently RFCOMM accepts
115200 bit/s only.
This patch fixes this issue.
Please review.
Best regards,
Yuri Kululin
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Santiago Carot-Nemesio @ 2010-07-23 9:49 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <20100722234724.GE2620@vigoh>
On 07/23/10 01:47, Gustavo F. Padovan wrote:
> * Santiago Carot-Nemesio<sancane@gmail.com> [2010-07-22 10:52:11 +0200]:
>
>
>> ---
>> mcap/mcap.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 51 insertions(+), 0 deletions(-)
>>
>> diff --git a/mcap/mcap.c b/mcap/mcap.c
>> index dc55cda..a0f00af 100644
>> --- a/mcap/mcap.c
>> +++ b/mcap/mcap.c
>> @@ -261,6 +261,20 @@ static uint16_t generate_mdlid(struct mcap_mcl *mcl)
>> return mdlid;
>> }
>>
>> +static uint8_t *create_req(uint8_t op, uint16_t mdl_id)
>> +{
>> + uint8_t *req;
>> + mcap_md_req *req_cmd;
>> +
>> + req = g_malloc0(sizeof(mcap_md_req));
>> +
>> + req_cmd = (mcap_md_req *)req;
>> + req_cmd->op = op;
>> + req_cmd->mdl = htons(mdl_id);
>> +
>> + return req;
>> +}
>>
> Why are you casting here? I would expect mcap_md_req * as return type
> here. If the problem is with mcap_send_std_opcode() you can used "void *" as
> parameter type there.
>
>
I don't see why is better doing it as you say.
In fact I did it to make the code similar to other bluez modules like
sdp. You can see the sdp_send_req_w4_rsp and the sdp_send_req functions
in sdp.c to find similarities with my code.
>> +
>> static uint8_t *create_mdl_req(uint16_t mdl_id, uint8_t mdep, uint8_t conf)
>> {
>> uint8_t *req;
>> @@ -356,6 +370,43 @@ void mcap_req_mdl_creation(struct mcap_mcl *mcl,
>> mcl);
>> }
>>
>> +void mcap_req_mdl_reconnect(struct mcap_mdl *mdl,
>> + GError **err,
>> + mcap_mdl_operation_cb reconnect_cb,
>> + gpointer user_data)
>> +{
>> + struct mcap_mdl_op_cb *con;
>> + struct mcap_mcl *mcl = mdl->mcl;
>> + uint8_t *cmd;
>> +
>> + if (mdl->state != MDL_CLOSED) {
>> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_FAILED,
>> + "MDL is not closed");
>> + return;
>> + }
>> + con = g_new0(struct mcap_mdl_op_cb, 1);
>> +
>> + cmd = create_req(MCAP_MD_RECONNECT_MDL_REQ, mdl->mdlid);
>> + mcap_send_std_opcode(mcl, cmd, sizeof(mcap_md_req), err);
>> + if (*err) {
>> + g_free(con);
>> + g_free(cmd);
>> + return;
>> + }
>> +
>> + mdl->state = MDL_WAITING;
>> +
>> + con->mdl = mdl;
>> + con->cb.op = reconnect_cb;
>> + con->user_data = user_data;
>> +
>> + mcl->state = MCL_ACTIVE;
>> + mcl->priv_data = con;
>> +
>> + mcl->tid = g_timeout_add_seconds(RESPONSE_TIMER, wait_response_timer,
>> + mcl);
>> +}
>> +
>> static void update_mcl_state(struct mcap_mcl *mcl)
>> {
>> GSList *l;
>>
>
^ permalink raw reply
* Re: [PATCH 18/60] Implement function to send md_abort_mdl_req
From: Santiago Carot-Nemesio @ 2010-07-23 9:24 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <20100723000709.GI2620@vigoh>
Hi,
On 07/23/10 02:07, Gustavo F. Padovan wrote:
> Hi Santiago,
>
> * Santiago Carot-Nemesio<sancane@gmail.com> [2010-07-22 10:52:13 +0200]:
>
>
>> ---
>> mcap/mcap.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 48 insertions(+), 0 deletions(-)
>>
>> diff --git a/mcap/mcap.c b/mcap/mcap.c
>> index 5419d54..6f6e08a 100644
>> --- a/mcap/mcap.c
>> +++ b/mcap/mcap.c
>> @@ -519,6 +519,38 @@ void mcap_req_mdl_deletion(struct mcap_mdl *mdl, GError **err,
>> g_free(con);
>> }
>>
>> +void mcap_mdl_abort(struct mcap_mdl *mdl, GError **err,
>> + mcap_mdl_del_cb abort_cb, gpointer user_data)
>> +{
>> + struct mcap_mdl_op_cb *con;
>> + struct mcap_mcl *mcl = mdl->mcl;
>> + uint8_t *cmd;
>> +
>> + if (mdl->state != MDL_WAITING) {
>> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_FAILED,
>> + "Mdl in invalid state");
>> + return;
>> + }
>> +
>> + con = g_new0(struct mcap_mdl_op_cb, 1);
>> + cmd = create_req(MCAP_MD_ABORT_MDL_REQ, mdl->mdlid);
>> + mcap_send_std_opcode(mcl, cmd, sizeof(mcap_md_req), err);
>> + if (*err) {
>> + g_free(con);
>> + g_free(cmd);
>> + return;
>> + }
>> +
>> + con->mdl = mdl;
>> + con->cb.del = abort_cb;
>> + con->user_data = user_data;
>> +
>> + mcl->priv_data = con;
>> +
>> + mcl->tid = g_timeout_add_seconds(RESPONSE_TIMER, wait_response_timer,
>> + mcl);
>> +}
>> +
>> static void update_mcl_state(struct mcap_mcl *mcl)
>> {
>> GSList *l;
>> @@ -554,6 +586,22 @@ static struct mcap_mcl *find_mcl(GSList *list, const bdaddr_t *addr)
>> return NULL;
>> }
>>
>> +int mcap_mdl_get_fd(struct mcap_mdl *mdl)
>> +{
>> + if ((!mdl) || (mdl->state != MDL_CONNECTED))
>> + return -1;
>>
> A proper Unix error is better than -1 here.
>
Patch 58 fix that.
>
>> +
>> + return g_io_channel_unix_get_fd(mdl->dc);
>> +}
>> +
>> +uint16_t mcap_mdl_get_mdlid(struct mcap_mdl *mdl)
>> +{
>> + if (!mdl)
>> + return MCAP_MDLID_RESERVED;
>> +
>> + return mdl->mdlid;
>> +}
>> +
>> static void shutdown_mdl(struct mcap_mdl *mdl)
>> {
>> mdl->state = MDL_CLOSED;
>>
>
^ permalink raw reply
* Re: [PATCH 12/60] Managing connection of Data Channels
From: Santiago Carot-Nemesio @ 2010-07-23 9:23 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <20100722235452.GG2620@vigoh>
Hi Gustavo,
On 07/23/10 01:54, Gustavo F. Padovan wrote:
> Hi Santiago,
>
> * Santiago Carot-Nemesio<sancane@gmail.com> [2010-07-22 10:52:07 +0200]:
>
>
>> ---
>> mcap/mcap.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 70 insertions(+), 1 deletions(-)
>>
>> diff --git a/mcap/mcap.c b/mcap/mcap.c
>> index cf44472..1d86c51 100644
>> --- a/mcap/mcap.c
>> +++ b/mcap/mcap.c
>> @@ -754,6 +754,27 @@ static void proc_cmd(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
>> proc_req[mcl->state](mcl, cmd, len);
>> }
>>
>> +static gboolean mdl_event_cb(GIOChannel *chan, GIOCondition cond, gpointer data)
>> +{
>> +
>> + struct mcap_mdl *mdl = data;
>> + gboolean notify;
>> +
>> + DBG("Close MDL %d", mdl->mdlid);
>> +
>> + notify = (mdl->state == MDL_CONNECTED);
>>
> You actually don't need 'notify', just put the comparison in the if
> below.
>
>
That is not true, you need to do it there because you need to know if
the MDL has been closed due a delete operation initiated by upper layer
(HDP) or it has been closed by remote side. In any case, MCAP need
shutdown the channel to set the MDL in a proper state before make any
callback. See coment below:
>> + shutdown_mdl(mdl);
>>
Above function sets the MDL state to closed, due that you can not check
the MDL state after shutdown it. I suggest to look that part of the code
to understand how data channel are managed by each MCL.
Note that mdl_event_cb is called from the watcher funtion set to the
bluetooth channel. When control flow reaches this part of the code the
MDL state can be connected or deleted. How can you know the MDL state
after doing a shutdown over the data channel?, remember that MCAP does
not know what will happen into the upper layer callback, due that, it
need set the MDL in a proper state by shutting down it before make the
callback.
>> +
>> + update_mcl_state(mdl->mcl);
>> +
>> + if (notify) {
>> + /*Callback to upper layer */
>> + mdl->mcl->cb->mdl_closed(mdl, mdl->mcl->cb->user_data);
>> + }
>> +
>> + return FALSE;
>> +}
>> +
>> static gboolean mcl_control_cb(GIOChannel *chan, GIOCondition cond,
>> gpointer data)
>> {
>> @@ -779,9 +800,57 @@ fail:
>> return FALSE;
>> }
>>
>> +static void connect_dc_event_cb(GIOChannel *chan, GError *err,
>> + gpointer user_data)
>> +{
>> + struct mcap_mdl *mdl = user_data;
>> + struct mcap_mcl *mcl = mdl->mcl;
>> +
>> + mdl->state = MDL_CONNECTED;
>> + mdl->dc = g_io_channel_ref(chan);
>> + mdl->wid = g_io_add_watch(mdl->dc, G_IO_ERR | G_IO_HUP | G_IO_NVAL,
>> + (GIOFunc) mdl_event_cb, mdl);
>> +
>> + mcl->state = MCL_ACTIVE;
>> + mcl->cb->mdl_connected(mdl, mcl->cb->user_data);
>> +}
>> +
>> static void confirm_dc_event_cb(GIOChannel *chan, gpointer user_data)
>> {
>> - /* TODO */
>> + struct mcap_instance *ms = user_data;
>> + struct mcap_mcl *mcl;
>> + struct mcap_mdl *mdl;
>> + GError *err = NULL;
>> + bdaddr_t dst;
>> + GSList *l;
>> +
>> + bt_io_get(chan, BT_IO_L2CAP,&err,
>> + BT_IO_OPT_DEST_BDADDR,&dst,
>> + BT_IO_OPT_INVALID);
>> + if (err) {
>> + error("%s", err->message);
>> + g_error_free(err);
>> + goto drop;
>> + }
>> +
>> + mcl = find_mcl(ms->mcls,&dst);
>> + if (!mcl || (mcl->state != MCL_PENDING))
>>
> No need for () in the '!=' comparison.
>
>
>> + goto drop;
>> +
>> + for (l = mcl->mdls; l; l = l->next) {
>> + mdl = l->data;
>> + if (mdl->state == MDL_WAITING) {
>> + if (!bt_io_accept(chan, connect_dc_event_cb, mdl, NULL,
>> + &err)) {
>> + error("MDL accept error %s", err->message);
>> + g_error_free(err);
>> + goto drop;
>> + }
>> + return;
>> + }
>> + }
>> +drop:
>> + g_io_channel_shutdown(chan, TRUE, NULL);
>> }
>>
>> static void connect_mcl_event_cb(GIOChannel *chan, GError *err,
>>
>
^ permalink raw reply
* Re: [PATCH v4 0/5] Enhanced support for extended inquiry response
From: Johan Hedberg @ 2010-07-23 8:43 UTC (permalink / raw)
To: Inga Stotland, linux-bluetooth, rshaffer, marcel
In-Reply-To: <20100723082754.GA12563@jh-x301>
Hi,
On Fri, Jul 23, 2010, Johan Hedberg wrote:
> On Fri, Jul 23, 2010, Johan Hedberg wrote:
> > Could you explain to me why this is needed. With the current git
> > (without your patches) the local EIR data seems to be correctly updated
> > whenever the SDP database changes. Are there some scenarios when this
> > doesn't happen? I did a quick test with sdptool add/del while bluetoothd
> > was running and I could see the appropriate "Write Extended Inquiry
> > Response" commands with hcidump.
>
> It seems currently this only happens when a local record change causes
> the service class bits of the class of device to be updated too. If the
> record change doesn't affect the class of device then it seems the EIR
> data isn't modified accordingly. Is this correct? If so, could you
> please add that information to your commit message so that it's clear
> why the patch is needed.
Even with your patch it seems this still doesn't work. If I I don't have
any OBEX servers running and I do "sdptool add OPUSH" I get the
apropriate EIR update with the OPP UUID (0x1105) added to the list, but
if I do a consecutive "sdptool add FTP" 0x1106 doesn't get added even
though it should. Then when I do sdptool del for the OPP record the UUID
doesn't get removed from the EIR data. So it seems some things still
need fixing.
Also, could you somehow try to avoid the multiple "Write Extended
Inquiry Response" commands while bluetoothd is probing drivers for an
adapter that entered the UP state? With the class of device this is done
through adapter->cache_enable, so maybe some more generic system could
be used for all HCI trafic related to probing drivers.
Johan
^ permalink raw reply
* [PATCH 6/6] pcmcia: remove cs_types.h
From: Dominik Brodowski @ 2010-07-23 8:38 UTC (permalink / raw)
To: linux-pcmcia
Cc: Dominik Brodowski, netdev, linux-wireless, linux-ide, linux-usb,
laforge, linux-mtd, linux-bluetooth, alsa-devel, linux-serial
In-Reply-To: <20100723083726.GA20947@comet.dominikbrodowski.net>
Remove cs_types.h which is no longer needed: Most definitions aren't
used at all, a few can be made away with, and two remaining definitions
(typedefs, unfortunatley) may be moved to more specific places.
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: linux-bluetooth@vger.kernel.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
Documentation/pcmcia/driver-changes.txt | 5 +++
drivers/ata/pata_pcmcia.c | 1 -
drivers/bluetooth/bluecard_cs.c | 1 -
drivers/bluetooth/bt3c_cs.c | 1 -
drivers/bluetooth/btuart_cs.c | 1 -
drivers/bluetooth/dtl1_cs.c | 1 -
drivers/char/pcmcia/cm4000_cs.c | 1 -
drivers/char/pcmcia/cm4040_cs.c | 1 -
drivers/char/pcmcia/ipwireless/main.h | 1 -
drivers/char/pcmcia/ipwireless/tty.h | 1 -
drivers/char/pcmcia/synclink_cs.c | 1 -
drivers/ide/ide-cs.c | 1 -
drivers/isdn/hardware/avm/avm_cs.c | 1 -
drivers/isdn/hisax/avma1_cs.c | 1 -
drivers/isdn/hisax/elsa_cs.c | 1 -
drivers/isdn/hisax/sedlbauer_cs.c | 1 -
drivers/isdn/hisax/teles_cs.c | 1 -
drivers/mmc/host/sdricoh_cs.c | 1 -
drivers/mtd/maps/pcmciamtd.c | 1 -
drivers/net/pcmcia/3c574_cs.c | 1 -
drivers/net/pcmcia/3c589_cs.c | 1 -
drivers/net/pcmcia/axnet_cs.c | 1 -
drivers/net/pcmcia/com20020_cs.c | 1 -
drivers/net/pcmcia/fmvj18x_cs.c | 1 -
drivers/net/pcmcia/ibmtr_cs.c | 1 -
drivers/net/pcmcia/nmclan_cs.c | 1 -
drivers/net/pcmcia/pcnet_cs.c | 5 +--
drivers/net/pcmcia/smc91c92_cs.c | 1 -
drivers/net/pcmcia/xirc2ps_cs.c | 1 -
drivers/net/wireless/airo_cs.c | 1 -
drivers/net/wireless/atmel_cs.c | 1 -
drivers/net/wireless/b43/pcmcia.c | 1 -
drivers/net/wireless/hostap/hostap_cs.c | 3 +-
drivers/net/wireless/libertas/if_cs.c | 1 -
drivers/net/wireless/orinoco/orinoco_cs.c | 1 -
drivers/net/wireless/orinoco/spectrum_cs.c | 1 -
drivers/net/wireless/ray_cs.c | 1 -
drivers/net/wireless/wl3501_cs.c | 10 +-----
drivers/parport/parport_cs.c | 1 -
drivers/pcmcia/au1000_generic.h | 1 -
drivers/pcmcia/au1000_pb1x00.c | 2 -
drivers/pcmcia/cistpl.c | 1 -
drivers/pcmcia/cs.c | 1 -
drivers/pcmcia/db1xxx_ss.c | 1 -
drivers/pcmcia/ds.c | 1 -
drivers/pcmcia/i82092.c | 1 -
drivers/pcmcia/i82365.c | 1 -
drivers/pcmcia/m32r_cfc.c | 1 -
drivers/pcmcia/m32r_pcc.c | 1 -
drivers/pcmcia/m8xx_pcmcia.c | 1 -
drivers/pcmcia/pcmcia_cis.c | 1 -
drivers/pcmcia/pcmcia_resource.c | 1 -
drivers/pcmcia/pd6729.c | 1 -
drivers/pcmcia/pxa2xx_base.c | 1 -
drivers/pcmcia/rsrc_iodyn.c | 1 -
drivers/pcmcia/rsrc_mgr.c | 1 -
drivers/pcmcia/rsrc_nonstatic.c | 1 -
drivers/pcmcia/sa1100_generic.c | 1 -
drivers/pcmcia/soc_common.h | 1 -
drivers/pcmcia/socket_sysfs.c | 1 -
drivers/pcmcia/tcic.c | 1 -
drivers/pcmcia/xxs1500_ss.c | 1 -
drivers/pcmcia/yenta_socket.c | 1 -
drivers/scsi/pcmcia/aha152x_stub.c | 1 -
drivers/scsi/pcmcia/fdomain_stub.c | 1 -
drivers/scsi/pcmcia/nsp_cs.c | 1 -
drivers/scsi/pcmcia/qlogic_stub.c | 1 -
drivers/scsi/pcmcia/sym53c500_cs.c | 1 -
drivers/serial/serial_cs.c | 1 -
drivers/ssb/main.c | 1 -
drivers/ssb/pcmcia.c | 1 -
drivers/ssb/scan.c | 1 -
drivers/staging/comedi/drivers/cb_das16_cs.c | 1 -
drivers/staging/comedi/drivers/das08_cs.c | 1 -
drivers/staging/comedi/drivers/ni_daq_700.c | 1 -
drivers/staging/comedi/drivers/ni_daq_dio24.c | 1 -
drivers/staging/comedi/drivers/ni_labpc_cs.c | 1 -
drivers/staging/comedi/drivers/ni_mio_cs.c | 1 -
drivers/staging/comedi/drivers/quatech_daqp_cs.c | 1 -
drivers/staging/wlags49_h2/wl_cs.c | 1 -
drivers/staging/wlags49_h2/wl_internal.h | 1 -
drivers/telephony/ixj_pcmcia.c | 1 -
drivers/usb/host/sl811_cs.c | 5 +--
include/pcmcia/cistpl.h | 2 +
include/pcmcia/cs.h | 10 +-----
include/pcmcia/cs_types.h | 40 ----------------------
include/pcmcia/ds.h | 3 +-
include/pcmcia/ss.h | 1 -
sound/pcmcia/pdaudiocf/pdaudiocf.h | 1 -
sound/pcmcia/vx/vxpocket.h | 1 -
90 files changed, 14 insertions(+), 151 deletions(-)
delete mode 100644 include/pcmcia/cs_types.h
diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt
index 61bc4e9..ff5f0be 100644
--- a/Documentation/pcmcia/driver-changes.txt
+++ b/Documentation/pcmcia/driver-changes.txt
@@ -1,4 +1,9 @@
This file details changes in 2.6 which affect PCMCIA card driver authors:
+* No dev_info_t, no cs_types.h (as of 2.6.36)
+ dev_info_t and a few other typedefs are removed. No longer use them
+ in PCMCIA device drivers. Also, do not include pcmcia/cs_types.h, as
+ this file is gone.
+
* No dev_node_t (as of 2.6.35)
There is no more need to fill out a "dev_node_t" structure.
diff --git a/drivers/ata/pata_pcmcia.c b/drivers/ata/pata_pcmcia.c
index 118c28e..3dcb2b1 100644
--- a/drivers/ata/pata_pcmcia.c
+++ b/drivers/ata/pata_pcmcia.c
@@ -34,7 +34,6 @@
#include <linux/ata.h>
#include <linux/libata.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/bluetooth/bluecard_cs.c b/drivers/bluetooth/bluecard_cs.c
index 6d34f40..eb085de 100644
--- a/drivers/bluetooth/bluecard_cs.c
+++ b/drivers/bluetooth/bluecard_cs.c
@@ -39,7 +39,6 @@
#include <linux/skbuff.h>
#include <linux/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/bluetooth/bt3c_cs.c b/drivers/bluetooth/bt3c_cs.c
index 21e05fd..457b603 100644
--- a/drivers/bluetooth/bt3c_cs.c
+++ b/drivers/bluetooth/bt3c_cs.c
@@ -45,7 +45,6 @@
#include <linux/device.h>
#include <linux/firmware.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/bluetooth/btuart_cs.c b/drivers/bluetooth/btuart_cs.c
index 4ed7288..e7e0a17 100644
--- a/drivers/bluetooth/btuart_cs.c
+++ b/drivers/bluetooth/btuart_cs.c
@@ -41,7 +41,6 @@
#include <asm/system.h>
#include <asm/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/bluetooth/dtl1_cs.c b/drivers/bluetooth/dtl1_cs.c
index ef044d5..7c94aad 100644
--- a/drivers/bluetooth/dtl1_cs.c
+++ b/drivers/bluetooth/dtl1_cs.c
@@ -41,7 +41,6 @@
#include <asm/system.h>
#include <asm/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/char/pcmcia/cm4000_cs.c b/drivers/char/pcmcia/cm4000_cs.c
index e7956ac..a8be2a7 100644
--- a/drivers/char/pcmcia/cm4000_cs.c
+++ b/drivers/char/pcmcia/cm4000_cs.c
@@ -34,7 +34,6 @@
#include <linux/uaccess.h>
#include <linux/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c
index c0775c8..44adae9 100644
--- a/drivers/char/pcmcia/cm4040_cs.c
+++ b/drivers/char/pcmcia/cm4040_cs.c
@@ -29,7 +29,6 @@
#include <asm/uaccess.h>
#include <asm/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/char/pcmcia/ipwireless/main.h b/drivers/char/pcmcia/ipwireless/main.h
index 96d0ef3..c207be8 100644
--- a/drivers/char/pcmcia/ipwireless/main.h
+++ b/drivers/char/pcmcia/ipwireless/main.h
@@ -21,7 +21,6 @@
#include <linux/sched.h>
#include <linux/types.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/char/pcmcia/ipwireless/tty.h b/drivers/char/pcmcia/ipwireless/tty.h
index 4da6c20..3e163d4 100644
--- a/drivers/char/pcmcia/ipwireless/tty.h
+++ b/drivers/char/pcmcia/ipwireless/tty.h
@@ -21,7 +21,6 @@
#include <linux/types.h>
#include <linux/sched.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c
index 308903e..522992e 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -70,7 +70,6 @@
#include <linux/workqueue.h>
#include <linux/hdlc.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/ide/ide-cs.c b/drivers/ide/ide-cs.c
index 0b7815d..27dbab8 100644
--- a/drivers/ide/ide-cs.c
+++ b/drivers/ide/ide-cs.c
@@ -43,7 +43,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/isdn/hardware/avm/avm_cs.c b/drivers/isdn/hardware/avm/avm_cs.c
index f410d0e..e804a01 100644
--- a/drivers/isdn/hardware/avm/avm_cs.c
+++ b/drivers/isdn/hardware/avm/avm_cs.c
@@ -20,7 +20,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/isdn/hisax/avma1_cs.c b/drivers/isdn/hisax/avma1_cs.c
index a80a761..49e141e 100644
--- a/drivers/isdn/hisax/avma1_cs.c
+++ b/drivers/isdn/hisax/avma1_cs.c
@@ -20,7 +20,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/isdn/hisax/elsa_cs.c b/drivers/isdn/hisax/elsa_cs.c
index 218927e..425deea 100644
--- a/drivers/isdn/hisax/elsa_cs.c
+++ b/drivers/isdn/hisax/elsa_cs.c
@@ -46,7 +46,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/isdn/hisax/sedlbauer_cs.c b/drivers/isdn/hisax/sedlbauer_cs.c
index 1f4feaa..5dbad96 100644
--- a/drivers/isdn/hisax/sedlbauer_cs.c
+++ b/drivers/isdn/hisax/sedlbauer_cs.c
@@ -46,7 +46,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/isdn/hisax/teles_cs.c b/drivers/isdn/hisax/teles_cs.c
index 5771955..d3fb1b7 100644
--- a/drivers/isdn/hisax/teles_cs.c
+++ b/drivers/isdn/hisax/teles_cs.c
@@ -27,7 +27,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c
index e7507af..7aa65bb 100644
--- a/drivers/mmc/host/sdricoh_cs.c
+++ b/drivers/mmc/host/sdricoh_cs.c
@@ -30,7 +30,6 @@
#include <linux/ioport.h>
#include <linux/scatterlist.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/mtd/maps/pcmciamtd.c b/drivers/mtd/maps/pcmciamtd.c
index e699e6a..7948816 100644
--- a/drivers/mtd/maps/pcmciamtd.c
+++ b/drivers/mtd/maps/pcmciamtd.c
@@ -16,7 +16,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/net/pcmcia/3c574_cs.c b/drivers/net/pcmcia/3c574_cs.c
index 10ee106..e249b89 100644
--- a/drivers/net/pcmcia/3c574_cs.c
+++ b/drivers/net/pcmcia/3c574_cs.c
@@ -87,7 +87,6 @@ earlier 3Com products.
#include <linux/bitops.h>
#include <linux/mii.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/pcmcia/3c589_cs.c b/drivers/net/pcmcia/3c589_cs.c
index ce63c37..b0772df 100644
--- a/drivers/net/pcmcia/3c589_cs.c
+++ b/drivers/net/pcmcia/3c589_cs.c
@@ -41,7 +41,6 @@
#include <linux/bitops.h>
#include <linux/jiffies.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/pcmcia/axnet_cs.c b/drivers/net/pcmcia/axnet_cs.c
index 33525bf..467fd4b 100644
--- a/drivers/net/pcmcia/axnet_cs.c
+++ b/drivers/net/pcmcia/axnet_cs.c
@@ -39,7 +39,6 @@
#include <linux/mii.h>
#include "../8390.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/net/pcmcia/com20020_cs.c b/drivers/net/pcmcia/com20020_cs.c
index 5643f94..99957af 100644
--- a/drivers/net/pcmcia/com20020_cs.c
+++ b/drivers/net/pcmcia/com20020_cs.c
@@ -43,7 +43,6 @@
#include <linux/arcdevice.h>
#include <linux/com20020.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/net/pcmcia/fmvj18x_cs.c b/drivers/net/pcmcia/fmvj18x_cs.c
index 7c27c50..95a991b 100644
--- a/drivers/net/pcmcia/fmvj18x_cs.c
+++ b/drivers/net/pcmcia/fmvj18x_cs.c
@@ -49,7 +49,6 @@
#include <linux/ioport.h>
#include <linux/crc32.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/net/pcmcia/ibmtr_cs.c b/drivers/net/pcmcia/ibmtr_cs.c
index 67ee985..c36dcd1 100644
--- a/drivers/net/pcmcia/ibmtr_cs.c
+++ b/drivers/net/pcmcia/ibmtr_cs.c
@@ -57,7 +57,6 @@
#include <linux/trdevice.h>
#include <linux/ibmtr.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c
index 9b63dec..c0eacfa 100644
--- a/drivers/net/pcmcia/nmclan_cs.c
+++ b/drivers/net/pcmcia/nmclan_cs.c
@@ -146,7 +146,6 @@ Include Files
#include <linux/ioport.h>
#include <linux/bitops.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cisreg.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index bfdef72..db6dbda 100644
--- a/drivers/net/pcmcia/pcnet_cs.c
+++ b/drivers/net/pcmcia/pcnet_cs.c
@@ -42,7 +42,6 @@
#include <linux/mii.h>
#include "../8390.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
@@ -113,8 +112,6 @@ static int setup_dma_config(struct pcmcia_device *link, int start_pg,
static void pcnet_detach(struct pcmcia_device *p_dev);
-static dev_info_t dev_info = "pcnet_cs";
-
/*====================================================================*/
typedef struct hw_info_t {
@@ -956,7 +953,7 @@ static int pcnet_open(struct net_device *dev)
set_misc_reg(dev);
outb_p(0xFF, nic_base + EN0_ISR); /* Clear bogus intr. */
- ret = request_irq(dev->irq, ei_irq_wrapper, IRQF_SHARED, dev_info, dev);
+ ret = request_irq(dev->irq, ei_irq_wrapper, IRQF_SHARED, dev->name, dev);
if (ret)
return ret;
diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/pcmcia/smc91c92_cs.c
index 307cd17..88f503a 100644
--- a/drivers/net/pcmcia/smc91c92_cs.c
+++ b/drivers/net/pcmcia/smc91c92_cs.c
@@ -44,7 +44,6 @@
#include <linux/jiffies.h>
#include <linux/firmware.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/pcmcia/xirc2ps_cs.c
index b6c3644..a7662f0 100644
--- a/drivers/net/pcmcia/xirc2ps_cs.c
+++ b/drivers/net/pcmcia/xirc2ps_cs.c
@@ -82,7 +82,6 @@
#include <linux/bitops.h>
#include <linux/mii.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/wireless/airo_cs.c b/drivers/net/wireless/airo_cs.c
index 33bdc6a..9389ba0 100644
--- a/drivers/net/wireless/airo_cs.c
+++ b/drivers/net/wireless/airo_cs.c
@@ -32,7 +32,6 @@
#include <linux/timer.h>
#include <linux/netdevice.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/wireless/atmel_cs.c b/drivers/net/wireless/atmel_cs.c
index c2746fc..91ee74a 100644
--- a/drivers/net/wireless/atmel_cs.c
+++ b/drivers/net/wireless/atmel_cs.c
@@ -42,7 +42,6 @@
#include <linux/moduleparam.h>
#include <linux/device.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/wireless/b43/pcmcia.c b/drivers/net/wireless/b43/pcmcia.c
index 0e99b63..f71bc78 100644
--- a/drivers/net/wireless/b43/pcmcia.c
+++ b/drivers/net/wireless/b43/pcmcia.c
@@ -26,7 +26,6 @@
#include <linux/ssb/ssb.h>
#include <linux/slab.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
index 29b31a6..2f4b6d4 100644
--- a/drivers/net/wireless/hostap/hostap_cs.c
+++ b/drivers/net/wireless/hostap/hostap_cs.c
@@ -12,7 +12,6 @@
#include <linux/wireless.h>
#include <net/iw_handler.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
@@ -23,7 +22,7 @@
#include "hostap_wlan.h"
-static dev_info_t dev_info = "hostap_cs";
+static char *dev_info = "hostap_cs";
MODULE_AUTHOR("Jouni Malinen");
MODULE_DESCRIPTION("Support for Intersil Prism2-based 802.11 wireless LAN "
diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
index 08e4e39..1d3a7e0 100644
--- a/drivers/net/wireless/libertas/if_cs.c
+++ b/drivers/net/wireless/libertas/if_cs.c
@@ -28,7 +28,6 @@
#include <linux/firmware.h>
#include <linux/netdevice.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/net/wireless/orinoco/orinoco_cs.c b/drivers/net/wireless/orinoco/orinoco_cs.c
index b16d5db..41ca4f1 100644
--- a/drivers/net/wireless/orinoco/orinoco_cs.c
+++ b/drivers/net/wireless/orinoco/orinoco_cs.c
@@ -17,7 +17,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/delay.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/wireless/orinoco/spectrum_cs.c b/drivers/net/wireless/orinoco/spectrum_cs.c
index b51a9ad..cad30e4 100644
--- a/drivers/net/wireless/orinoco/spectrum_cs.c
+++ b/drivers/net/wireless/orinoco/spectrum_cs.c
@@ -25,7 +25,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/delay.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index abff893..165beb6 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -46,7 +46,6 @@
#include <linux/ethtool.h>
#include <linux/ieee80211.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index 376c6b9..35f431b 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -48,7 +48,6 @@
#include <net/iw_handler.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
@@ -89,13 +88,6 @@
static int wl3501_config(struct pcmcia_device *link);
static void wl3501_release(struct pcmcia_device *link);
-/*
- * The dev_info variable is the "key" that is used to match up this
- * device driver with appropriate cards, through the card configuration
- * database.
- */
-static dev_info_t wl3501_dev_info = "wl3501_cs";
-
static const struct {
int reg_domain;
int min, max, deflt;
@@ -1421,7 +1413,7 @@ static struct iw_statistics *wl3501_get_wireless_stats(struct net_device *dev)
static void wl3501_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
{
- strlcpy(info->driver, wl3501_dev_info, sizeof(info->driver));
+ strlcpy(info->driver, "wl3501_cs", sizeof(info->driver));
}
static const struct ethtool_ops ops = {
diff --git a/drivers/parport/parport_cs.c b/drivers/parport/parport_cs.c
index fd8cfe9..ee56fd6 100644
--- a/drivers/parport/parport_cs.c
+++ b/drivers/parport/parport_cs.c
@@ -48,7 +48,6 @@
#include <linux/parport.h>
#include <linux/parport_pc.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/pcmcia/au1000_generic.h b/drivers/pcmcia/au1000_generic.h
index a324d32..67530ce 100644
--- a/drivers/pcmcia/au1000_generic.h
+++ b/drivers/pcmcia/au1000_generic.h
@@ -23,7 +23,6 @@
/* include the world */
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/au1000_pb1x00.c b/drivers/pcmcia/au1000_pb1x00.c
index 5a979cb..807f2d7 100644
--- a/drivers/pcmcia/au1000_pb1x00.c
+++ b/drivers/pcmcia/au1000_pb1x00.c
@@ -31,11 +31,9 @@
#include <linux/proc_fs.h>
#include <linux/types.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
-#include <pcmcia/bus_ops.h>
#include <asm/io.h>
#include <asm/irq.h>
diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index 8844bc3..ba4a5ac 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -27,7 +27,6 @@
#include <asm/byteorder.h>
#include <asm/unaligned.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index efa30b8..2ec8ac9 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -32,7 +32,6 @@
#include <asm/system.h>
#include <asm/irq.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/db1xxx_ss.c b/drivers/pcmcia/db1xxx_ss.c
index 0f4cc3f..27575e6 100644
--- a/drivers/pcmcia/db1xxx_ss.c
+++ b/drivers/pcmcia/db1xxx_ss.c
@@ -29,7 +29,6 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <asm/mach-au1x00/au1000.h>
diff --git a/drivers/pcmcia/ds.c b/drivers/pcmcia/ds.c
index 73aeaea..56933eb 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -26,7 +26,6 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/pcmcia/i82092.c b/drivers/pcmcia/i82092.c
index 3003bb3..05d0879 100644
--- a/drivers/pcmcia/i82092.c
+++ b/drivers/pcmcia/i82092.c
@@ -15,7 +15,6 @@
#include <linux/interrupt.h>
#include <linux/device.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
diff --git a/drivers/pcmcia/i82365.c b/drivers/pcmcia/i82365.c
index 9e2a156..61746bd 100644
--- a/drivers/pcmcia/i82365.c
+++ b/drivers/pcmcia/i82365.c
@@ -50,7 +50,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
diff --git a/drivers/pcmcia/m32r_cfc.c b/drivers/pcmcia/m32r_cfc.c
index 7e16ed8..24de499 100644
--- a/drivers/pcmcia/m32r_cfc.c
+++ b/drivers/pcmcia/m32r_cfc.c
@@ -26,7 +26,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
diff --git a/drivers/pcmcia/m32r_pcc.c b/drivers/pcmcia/m32r_pcc.c
index 6c5c3f9..8e47238 100644
--- a/drivers/pcmcia/m32r_pcc.c
+++ b/drivers/pcmcia/m32r_pcc.c
@@ -27,7 +27,6 @@
#include <asm/system.h>
#include <asm/addrspace.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
diff --git a/drivers/pcmcia/m8xx_pcmcia.c b/drivers/pcmcia/m8xx_pcmcia.c
index 25e5e30..f2f90a7 100644
--- a/drivers/pcmcia/m8xx_pcmcia.c
+++ b/drivers/pcmcia/m8xx_pcmcia.c
@@ -59,7 +59,6 @@
#include <asm/irq.h>
#include <asm/fs_pd.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
diff --git a/drivers/pcmcia/pcmcia_cis.c b/drivers/pcmcia/pcmcia_cis.c
index 4a65eaf..0ac54da 100644
--- a/drivers/pcmcia/pcmcia_cis.c
+++ b/drivers/pcmcia/pcmcia_cis.c
@@ -19,7 +19,6 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cisreg.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ss.h>
diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c
index a4cd9ad..2394de4 100644
--- a/drivers/pcmcia/pcmcia_resource.c
+++ b/drivers/pcmcia/pcmcia_resource.c
@@ -25,7 +25,6 @@
#include <asm/irq.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/pd6729.c b/drivers/pcmcia/pd6729.c
index b61a136..b8a869a 100644
--- a/drivers/pcmcia/pd6729.c
+++ b/drivers/pcmcia/pd6729.c
@@ -17,7 +17,6 @@
#include <linux/device.h>
#include <linux/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
diff --git a/drivers/pcmcia/pxa2xx_base.c b/drivers/pcmcia/pxa2xx_base.c
index df4532e..66c0225 100644
--- a/drivers/pcmcia/pxa2xx_base.c
+++ b/drivers/pcmcia/pxa2xx_base.c
@@ -32,7 +32,6 @@
#include <mach/pxa2xx-regs.h>
#include <asm/mach-types.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/rsrc_iodyn.c b/drivers/pcmcia/rsrc_iodyn.c
index 6ed7bf1..3b1dce2 100644
--- a/drivers/pcmcia/rsrc_iodyn.c
+++ b/drivers/pcmcia/rsrc_iodyn.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/rsrc_mgr.c b/drivers/pcmcia/rsrc_mgr.c
index b12ecf7..b433a79 100644
--- a/drivers/pcmcia/rsrc_mgr.c
+++ b/drivers/pcmcia/rsrc_mgr.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
index 13245a2..0cca08f 100644
--- a/drivers/pcmcia/rsrc_nonstatic.c
+++ b/drivers/pcmcia/rsrc_nonstatic.c
@@ -28,7 +28,6 @@
#include <asm/irq.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/sa1100_generic.c b/drivers/pcmcia/sa1100_generic.c
index edbd8c4..e098514 100644
--- a/drivers/pcmcia/sa1100_generic.c
+++ b/drivers/pcmcia/sa1100_generic.c
@@ -35,7 +35,6 @@
#include <linux/slab.h>
#include <linux/platform_device.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
diff --git a/drivers/pcmcia/soc_common.h b/drivers/pcmcia/soc_common.h
index e40824c..3fba3a6 100644
--- a/drivers/pcmcia/soc_common.h
+++ b/drivers/pcmcia/soc_common.h
@@ -11,7 +11,6 @@
/* include the world */
#include <linux/cpufreq.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/socket_sysfs.c b/drivers/pcmcia/socket_sysfs.c
index 80e36bc..cb0d3ac 100644
--- a/drivers/pcmcia/socket_sysfs.c
+++ b/drivers/pcmcia/socket_sysfs.c
@@ -26,7 +26,6 @@
#include <asm/system.h>
#include <asm/irq.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/tcic.c b/drivers/pcmcia/tcic.c
index 56004a1..be0d841 100644
--- a/drivers/pcmcia/tcic.c
+++ b/drivers/pcmcia/tcic.c
@@ -49,7 +49,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
#include "tcic.h"
diff --git a/drivers/pcmcia/xxs1500_ss.c b/drivers/pcmcia/xxs1500_ss.c
index 201ccfa..fa88c36 100644
--- a/drivers/pcmcia/xxs1500_ss.c
+++ b/drivers/pcmcia/xxs1500_ss.c
@@ -17,7 +17,6 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index f1d4137..414d9a6 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -19,7 +19,6 @@
#include <linux/io.h>
#include <linux/slab.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/ss.h>
#include <pcmcia/cs.h>
diff --git a/drivers/scsi/pcmcia/aha152x_stub.c b/drivers/scsi/pcmcia/aha152x_stub.c
index 9d70aef..b07b53e 100644
--- a/drivers/scsi/pcmcia/aha152x_stub.c
+++ b/drivers/scsi/pcmcia/aha152x_stub.c
@@ -49,7 +49,6 @@
#include <scsi/scsi_host.h>
#include "aha152x.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/scsi/pcmcia/fdomain_stub.c b/drivers/scsi/pcmcia/fdomain_stub.c
index 21b1411..ee04897 100644
--- a/drivers/scsi/pcmcia/fdomain_stub.c
+++ b/drivers/scsi/pcmcia/fdomain_stub.c
@@ -46,7 +46,6 @@
#include <scsi/scsi_host.h>
#include "fdomain.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/scsi/pcmcia/nsp_cs.c b/drivers/scsi/pcmcia/nsp_cs.c
index 0f0e112..d414207 100644
--- a/drivers/scsi/pcmcia/nsp_cs.c
+++ b/drivers/scsi/pcmcia/nsp_cs.c
@@ -47,7 +47,6 @@
#include <scsi/scsi.h>
#include <scsi/scsi_ioctl.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/scsi/pcmcia/qlogic_stub.c b/drivers/scsi/pcmcia/qlogic_stub.c
index f0fc6ba..c1cf7f4 100644
--- a/drivers/scsi/pcmcia/qlogic_stub.c
+++ b/drivers/scsi/pcmcia/qlogic_stub.c
@@ -48,7 +48,6 @@
#include <scsi/scsi_host.h>
#include "../qlogicfas408.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/scsi/pcmcia/sym53c500_cs.c b/drivers/scsi/pcmcia/sym53c500_cs.c
index a511641..bd79e45 100644
--- a/drivers/scsi/pcmcia/sym53c500_cs.c
+++ b/drivers/scsi/pcmcia/sym53c500_cs.c
@@ -71,7 +71,6 @@
#include <scsi/scsi.h>
#include <scsi/scsi_host.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c
index ab17c08..2b99c7b 100644
--- a/drivers/serial/serial_cs.c
+++ b/drivers/serial/serial_cs.c
@@ -45,7 +45,6 @@
#include <asm/io.h>
#include <asm/system.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 51275aa..06f04b4 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -20,7 +20,6 @@
#include <linux/mmc/sdio_func.h>
#include <linux/slab.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/ssb/pcmcia.c b/drivers/ssb/pcmcia.c
index e72f404..2152030 100644
--- a/drivers/ssb/pcmcia.c
+++ b/drivers/ssb/pcmcia.c
@@ -13,7 +13,6 @@
#include <linux/io.h>
#include <linux/etherdevice.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ciscode.h>
diff --git a/drivers/ssb/scan.c b/drivers/ssb/scan.c
index 0d6c028..9738cad 100644
--- a/drivers/ssb/scan.c
+++ b/drivers/ssb/scan.c
@@ -17,7 +17,6 @@
#include <linux/pci.h>
#include <linux/io.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/staging/comedi/drivers/cb_das16_cs.c b/drivers/staging/comedi/drivers/cb_das16_cs.c
index cfeb11f..acef29c 100644
--- a/drivers/staging/comedi/drivers/cb_das16_cs.c
+++ b/drivers/staging/comedi/drivers/cb_das16_cs.c
@@ -37,7 +37,6 @@ Status: experimental
#include <linux/delay.h>
#include <linux/pci.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/staging/comedi/drivers/das08_cs.c b/drivers/staging/comedi/drivers/das08_cs.c
index 8761a6d..3eddb7c 100644
--- a/drivers/staging/comedi/drivers/das08_cs.c
+++ b/drivers/staging/comedi/drivers/das08_cs.c
@@ -48,7 +48,6 @@ Command support does not exist, but could be added for this board.
#include "das08.h"
/* pcmcia includes */
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/staging/comedi/drivers/ni_daq_700.c b/drivers/staging/comedi/drivers/ni_daq_700.c
index 6ec77bf..f3c4d2f 100644
--- a/drivers/staging/comedi/drivers/ni_daq_700.c
+++ b/drivers/staging/comedi/drivers/ni_daq_700.c
@@ -47,7 +47,6 @@ IRQ is assigned but not used.
#include <linux/ioport.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/staging/comedi/drivers/ni_daq_dio24.c b/drivers/staging/comedi/drivers/ni_daq_dio24.c
index e4865b1..f0c4367 100644
--- a/drivers/staging/comedi/drivers/ni_daq_dio24.c
+++ b/drivers/staging/comedi/drivers/ni_daq_dio24.c
@@ -48,7 +48,6 @@ the PCMCIA interface.
#include "8255.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/staging/comedi/drivers/ni_labpc_cs.c b/drivers/staging/comedi/drivers/ni_labpc_cs.c
index 163245e..1ee78f8 100644
--- a/drivers/staging/comedi/drivers/ni_labpc_cs.c
+++ b/drivers/staging/comedi/drivers/ni_labpc_cs.c
@@ -71,7 +71,6 @@ NI manuals:
#include "comedi_fc.h"
#include "ni_labpc.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/staging/comedi/drivers/ni_mio_cs.c b/drivers/staging/comedi/drivers/ni_mio_cs.c
index 3a46f0c..0bce220 100644
--- a/drivers/staging/comedi/drivers/ni_mio_cs.c
+++ b/drivers/staging/comedi/drivers/ni_mio_cs.c
@@ -48,7 +48,6 @@ See the notes in the ni_atmio.o driver.
#include "ni_stc.h"
#include "8255.h"
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index a91db6c..67c0fa6 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -50,7 +50,6 @@ Devices: [Quatech] DAQP-208 (daqp), DAQP-308
#include "../comedidev.h"
#include <linux/semaphore.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/staging/wlags49_h2/wl_cs.c b/drivers/staging/wlags49_h2/wl_cs.c
index 10abd40..afe4575 100644
--- a/drivers/staging/wlags49_h2/wl_cs.c
+++ b/drivers/staging/wlags49_h2/wl_cs.c
@@ -83,7 +83,6 @@
#include <linux/if_arp.h>
#include <linux/ioport.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/staging/wlags49_h2/wl_internal.h b/drivers/staging/wlags49_h2/wl_internal.h
index d9a0ad0..02f0a20 100644
--- a/drivers/staging/wlags49_h2/wl_internal.h
+++ b/drivers/staging/wlags49_h2/wl_internal.h
@@ -69,7 +69,6 @@
******************************************************************************/
#include <linux/version.h>
#ifdef BUS_PCMCIA
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
diff --git a/drivers/telephony/ixj_pcmcia.c b/drivers/telephony/ixj_pcmcia.c
index 99cb224..f6c7e6f 100644
--- a/drivers/telephony/ixj_pcmcia.c
+++ b/drivers/telephony/ixj_pcmcia.c
@@ -8,7 +8,6 @@
#include <linux/errno.h> /* error codes */
#include <linux/slab.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/drivers/usb/host/sl811_cs.c b/drivers/usb/host/sl811_cs.c
index 58cb73c..acb7e25 100644
--- a/drivers/usb/host/sl811_cs.c
+++ b/drivers/usb/host/sl811_cs.c
@@ -20,7 +20,6 @@
#include <linux/ioport.h>
#include <linux/platform_device.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/cisreg.h>
@@ -43,8 +42,6 @@ MODULE_LICENSE("GPL");
/* VARIABLES */
/*====================================================================*/
-static const char driver_name[DEV_NAME_LEN] = "sl811_cs";
-
typedef struct local_info_t {
struct pcmcia_device *p_dev;
} local_info_t;
@@ -246,7 +243,7 @@ MODULE_DEVICE_TABLE(pcmcia, sl811_ids);
static struct pcmcia_driver sl811_cs_driver = {
.owner = THIS_MODULE,
.drv = {
- .name = (char *)driver_name,
+ .name = "sl811_cs",
},
.probe = sl811_cs_probe,
.remove = sl811_cs_detach,
diff --git a/include/pcmcia/cistpl.h b/include/pcmcia/cistpl.h
index cfdd5af..1c5088c 100644
--- a/include/pcmcia/cistpl.h
+++ b/include/pcmcia/cistpl.h
@@ -15,6 +15,8 @@
#ifndef _LINUX_CISTPL_H
#define _LINUX_CISTPL_H
+typedef unsigned char cisdata_t;
+
#define CISTPL_NULL 0x00
#define CISTPL_DEVICE 0x01
#define CISTPL_LONGLINK_CB 0x02
diff --git a/include/pcmcia/cs.h b/include/pcmcia/cs.h
index c943c96..c78d9b1 100644
--- a/include/pcmcia/cs.h
+++ b/include/pcmcia/cs.h
@@ -43,14 +43,6 @@ typedef struct conf_reg_t {
#define CV_COPY_VALUE 0x08
#define CV_EXT_STATUS 0x10
-/* For GetFirst/NextClient */
-typedef struct client_req_t {
- socket_t Socket;
- u_int Attributes;
-} client_req_t;
-
-#define CLIENT_THIS_SOCKET 0x01
-
/* ModifyConfiguration */
typedef struct modconf_t {
u_int Attributes;
@@ -133,7 +125,7 @@ typedef struct io_req_t {
/* For GetMemPage, MapMemPage */
typedef struct memreq_t {
u_int CardOffset;
- page_t Page;
+ u_short Page;
} memreq_t;
/* For ModifyWindow */
diff --git a/include/pcmcia/cs_types.h b/include/pcmcia/cs_types.h
deleted file mode 100644
index f5e3b83..0000000
--- a/include/pcmcia/cs_types.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * cs_types.h
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * The initial developer of the original code is David A. Hinds
- * <dahinds@users.sourceforge.net>. Portions created by David A. Hinds
- * are Copyright (C) 1999 David A. Hinds. All Rights Reserved.
- *
- * (C) 1999 David A. Hinds
- */
-
-#ifndef _LINUX_CS_TYPES_H
-#define _LINUX_CS_TYPES_H
-
-#ifdef __KERNEL__
-#include <linux/types.h>
-#else
-#include <sys/types.h>
-#endif
-
-typedef u_short socket_t;
-typedef u_int event_t;
-typedef u_char cisdata_t;
-typedef u_short page_t;
-
-typedef unsigned long window_handle_t;
-
-struct region_t;
-typedef struct region_t *memory_handle_t;
-
-#ifndef DEV_NAME_LEN
-#define DEV_NAME_LEN 32
-#endif
-
-typedef char dev_info_t[DEV_NAME_LEN];
-
-#endif /* _LINUX_CS_TYPES_H */
diff --git a/include/pcmcia/ds.h b/include/pcmcia/ds.h
index 7d7721e..e614aa0 100644
--- a/include/pcmcia/ds.h
+++ b/include/pcmcia/ds.h
@@ -20,7 +20,6 @@
#include <linux/mod_devicetable.h>
#endif
-#include <pcmcia/cs_types.h>
#include <pcmcia/device_id.h>
#ifdef __KERNEL__
@@ -37,6 +36,8 @@ struct pcmcia_device;
struct config_t;
struct net_device;
+typedef unsigned long window_handle_t;
+
/* dynamic device IDs for PCMCIA device drivers. See
* Documentation/pcmcia/driver.txt for details.
*/
diff --git a/include/pcmcia/ss.h b/include/pcmcia/ss.h
index aeac271..626b63c 100644
--- a/include/pcmcia/ss.h
+++ b/include/pcmcia/ss.h
@@ -19,7 +19,6 @@
#include <linux/sched.h> /* task_struct, completion */
#include <linux/mutex.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#ifdef CONFIG_CARDBUS
#include <linux/pci.h>
diff --git a/sound/pcmcia/pdaudiocf/pdaudiocf.h b/sound/pcmcia/pdaudiocf/pdaudiocf.h
index a0a7ec6..5cc3e45 100644
--- a/sound/pcmcia/pdaudiocf/pdaudiocf.h
+++ b/sound/pcmcia/pdaudiocf/pdaudiocf.h
@@ -24,7 +24,6 @@
#include <sound/pcm.h>
#include <asm/io.h>
#include <linux/interrupt.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
diff --git a/sound/pcmcia/vx/vxpocket.h b/sound/pcmcia/vx/vxpocket.h
index ea4df16..d911066 100644
--- a/sound/pcmcia/vx/vxpocket.h
+++ b/sound/pcmcia/vx/vxpocket.h
@@ -23,7 +23,6 @@
#include <sound/vx_core.h>
-#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
#include <pcmcia/cistpl.h>
#include <pcmcia/ds.h>
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v4 0/5] Enhanced support for extended inquiry response
From: Johan Hedberg @ 2010-07-23 8:27 UTC (permalink / raw)
To: Inga Stotland, linux-bluetooth, rshaffer, marcel
In-Reply-To: <20100723082045.GA1600@jh-x301>
On Fri, Jul 23, 2010, Johan Hedberg wrote:
> Could you explain to me why this is needed. With the current git
> (without your patches) the local EIR data seems to be correctly updated
> whenever the SDP database changes. Are there some scenarios when this
> doesn't happen? I did a quick test with sdptool add/del while bluetoothd
> was running and I could see the appropriate "Write Extended Inquiry
> Response" commands with hcidump.
It seems currently this only happens when a local record change causes
the service class bits of the class of device to be updated too. If the
record change doesn't affect the class of device then it seems the EIR
data isn't modified accordingly. Is this correct? If so, could you
please add that information to your commit message so that it's clear
why the patch is needed.
Johan
^ permalink raw reply
* Re: SAP profile implementation
From: Suraj @ 2010-07-23 8:25 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTimWft8QE5ZG2sYnANOBEkV3n5kGgsdQDYOqrw1k@mail.gmail.com>
Hi Pavan,
On 7/23/2010 12:58 PM, Pavan Savoy wrote:
> i saw a bluez-sap project recently on gitorious ..
>
> On 7/23/10, Suraj<suraj@atheros.com> wrote:
>> Hi,
>>
>> Is there anyone currently working on SAP profile?
>> I know that Claudio Takahasi was working on the SAP Client implementation.
>>
>> Regards
>> Suraj
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
If I am not mistaken, it was created by Claudio Takahasi and he had
removed it sometime later.
Regards
Suraj
^ permalink raw reply
* Re: MCAP Patches
From: José Antonio Santos Cadenas @ 2010-07-23 8:25 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <20100722233606.GB2620@vigoh>
Hi,
El Friday 23 July 2010 01:36:06 Gustavo F. Padovan escribió:
> Hi Santiago,
>
> * Santiago Carot-Nemesio <sancane@gmail.com> [2010-07-22 10:51:55 +0200]:
> > Hello,
> >
> > Next you are MCAP patches that José Antonio Santos Cadenas and me have
> > generated for BlueZ. We still believe that MCAP should be an independent
> > library from HDP because other profiles non health related may want to
> > use it in the future, if we set this health dependency we will force to
> > import health features in plugins that only require MCAP. Nevertheless,
> > as we accorded last week in Brazil we are sending a last patch to set
> > MCAP into health directory with HDP. We leave in your hands upload it as
> > health plugin or not.
>
> Please provide a git tree link for theses patches too. Thanks.
You have a copy of this changes in the follow git at branch mcap.
git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git
Regards.
^ permalink raw reply
* Re: [PATCH v4 0/5] Enhanced support for extended inquiry response
From: Johan Hedberg @ 2010-07-23 8:20 UTC (permalink / raw)
To: Inga Stotland; +Cc: linux-bluetooth, rshaffer, marcel
In-Reply-To: <1279814780-29673-1-git-send-email-ingas@codeaurora.org>
Hi Inga,
On Thu, Jul 22, 2010, Inga Stotland wrote:
> EIR is updated whenever local SDP record database changes.
Could you explain to me why this is needed. With the current git
(without your patches) the local EIR data seems to be correctly updated
whenever the SDP database changes. Are there some scenarios when this
doesn't happen? I did a quick test with sdptool add/del while bluetoothd
was running and I could see the appropriate "Write Extended Inquiry
Response" commands with hcidump.
Johan
^ permalink raw reply
* Re: [PATCH 10/60] Process md_abort_mdl_req in PENDING state
From: Santiago Carot-Nemesio @ 2010-07-23 8:00 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Santiago Carot-Nemesio, linux-bluetooth
In-Reply-To: <20100722235021.GF2620@vigoh>
Hi Gustavo,
On 07/23/10 01:50, Gustavo F. Padovan wrote:
> Hi Santiago,
>
> * Santiago Carot-Nemesio<sancane@gmail.com> [2010-07-22 10:52:05 +0200]:
>
>
>> ---
>> mcap/mcap.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 49 insertions(+), 1 deletions(-)
>>
>> diff --git a/mcap/mcap.c b/mcap/mcap.c
>> index d6a9760..9f41c6b 100644
>> --- a/mcap/mcap.c
>> +++ b/mcap/mcap.c
>> @@ -551,6 +551,51 @@ static void process_md_reconnect_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
>> send4B_cmd(mcl, MCAP_MD_RECONNECT_MDL_RSP, MCAP_SUCCESS, mdl_id);
>> }
>>
>> +static void process_md_abort_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
>> + uint32_t len)
>> +{
>> + mcap_md_req *req;
>> + GSList *l;
>> + struct mcap_mdl *mdl, *del;
>> + uint16_t mdl_id;
>> +
>> + if (len != sizeof(mcap_md_req)) {
>> + send4B_cmd(mcl, MCAP_MD_ABORT_MDL_RSP,
>> + MCAP_INVALID_PARAM_VALUE, MCAP_MDLID_RESERVED);
>>
> I remenber about a Johan's comment on send4B_cmd(). It was basically,
> wouldn't be better have function to send data of a arbritrary size. I
> think I saw a send5B_cmd() in these patches as well.
>
Yes, patch 56 Fix that.
That is a big change in MCAP core to be amended in previous patches and
to expect that intermediate patches still compile.
In fact, it may be a stupid waste of time try to do that to hide MCAP
developing history. I'm not sure if that it is a good idea and as far I
remember we accorded to keep MCAP history in last meeting.
>
>> + return;
>> + }
>> +
>> + req = (mcap_md_req *)cmd;
>> + mdl_id = ntohs(req->mdl);
>> + mcl->state = MCL_CONNECTED;
>> + for (l = mcl->mdls; l; l = l->next) {
>> + mdl = l->data;
>> + if ((mdl_id == mdl->mdlid)&& (mdl->state == MDL_WAITING)) {
>> + del = mdl;
>> + if (mcl->state != MCL_CONNECTED)
>> + break;
>> + continue;
>> + }
>> + if ((mdl->state == MDL_CONNECTED)&& (mcl->state != MCL_ACTIVE))
>> + mcl->state = MCL_ACTIVE;
>> +
>> + if ((del)&& (mcl->state == MCL_ACTIVE))
>> + break;
>> + }
>> +
>> + if (!del) {
>> + send4B_cmd(mcl, MCAP_MD_ABORT_MDL_RSP, MCAP_INVALID_MDL,
>> + mdl_id);
>> + return;
>> + }
>> +
>> + mcl->cb->mdl_aborted(del, mcl->cb->user_data);
>> +
>> + mcl->mdls = g_slist_remove(mcl->mdls, del);
>> + g_free(del);
>> + send4B_cmd(mcl, MCAP_MD_ABORT_MDL_RSP, MCAP_SUCCESS, mdl_id);
>> +}
>> +
>> static void process_md_delete_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
>> uint32_t len)
>> {
>> @@ -626,7 +671,10 @@ static void proc_req_connected(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
>>
>> static void proc_req_pending(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
>> {
>> - /* TODO */
>> + if (cmd[0] == MCAP_MD_ABORT_MDL_REQ)
>> + process_md_abort_mdl_req(mcl, cmd, len);
>> + else
>> + error_cmd_rsp(mcl, cmd, len);
>> }
>>
>> static void proc_req_active(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
>>
>
^ permalink raw reply
* Re: SAP profile implementation
From: Pavan Savoy @ 2010-07-23 7:28 UTC (permalink / raw)
To: Suraj; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4C493F90.10008@Atheros.com>
i saw a bluez-sap project recently on gitorious ..
On 7/23/10, Suraj <suraj@atheros.com> wrote:
> Hi,
>
> Is there anyone currently working on SAP profile?
> I know that Claudio Takahasi was working on the SAP Client implementation.
>
> Regards
> Suraj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox