aboutsummaryrefslogtreecommitdiffstats
path: root/include/net/bluetooth/l2cap.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Bluetooth: Initial work for L2CAP split.Gustavo F. Padovan2011-02-081-0/+15
| | | | | | | | | This patch tries to do the minimal to move l2cap_sock_create() and its dependencies to l2cap_sock.c. It create a API to initialize and cleanup the L2CAP sockets from l2cap_core.c through l2cap_init_sockets() and l2cap_cleanup_sockets(). Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
* Bluetooth: Use non-flushable by default L2CAP data packetsAndrei Emeltchenko2011-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modification of Nick Pelly <npelly@google.com> patch. With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit makes ACL data packets non-flushable by default on compatible chipsets, and adds the BT_FLUSHABLE socket option to explicitly request flushable ACL data packets for a given L2CAP socket. This is useful for A2DP data which can be safely discarded if it can not be delivered within a short time (while other ACL data should not be discarded). Note that making ACL data flushable has no effect unless the automatic flush timeout for that ACL link is changed from its default of 0 (infinite). Default packet types (for compatible chipsets): Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits) Bluetooth HCI H4 Bluetooth HCI ACL Packet .... 0000 0000 0010 = Connection Handle: 0x0002 ..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0) 00.. .... .... .... = BC Flag: Point-To-Point (0) Data Total Length: 8 Bluetooth L2CAP Packet After setting BT_FLUSHABLE (sock.setsockopt(274 /*SOL_BLUETOOTH*/, 8 /* BT_FLUSHABLE */, 1 /* flush */)) Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits) Bluetooth HCI H4 Bluetooth HCI ACL Packet .... 0000 0000 0010 = Connection Handle: 0x0002 ..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2) 00.. .... .... .... = BC Flag: Point-To-Point (0) Data Total Length: 8 Bluetooth L2CAP Packet Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
* Bluetooth: clean up legal textAndrei Emeltchenko2010-12-011-6/+6
| | | | | | | | Remove extra spaces from legal text so that legal stuff looks the same for all bluetooth code. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
* Bluetooth: clean up l2cap codeAndrei Emeltchenko2010-12-011-5/+5
| | | | | | | | Do not initialize static vars to zero, macros with complex values shall be enclosed with (), remove unneeded braces. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
* net: return operator cleanupEric Dumazet2010-09-231-1/+1
| | | | | | | | | Change "return (EXPR);" to "return EXPR;" return is not a function, parentheses are not required. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Bluetooth: Use 3-DH5 payload size for default ERTM max PDU sizeMat Martineau2010-08-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on the default L2CAP MTU. That default MTU is calculated from the size of two DH5 packets, minus ACL and L2CAP b-frame header overhead. ERTM is used with newer basebands that typically support larger 3-DH5 packets, and i-frames and s-frames have more header overhead. With clean RF conditions, basebands will typically attempt to use 1021-byte 3-DH5 packets for maximum throughput. Adjusting for 2 bytes of ACL headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes of payload. This PDU size imposes less overhead for header bytes and gives the baseband the option to choose 3-DH5 packets, but is small enough for ERTM traffic to interleave well with other L2CAP or SCO data. 672-byte payloads do not allow the most efficient over-the-air packet choice, and cannot achieve maximum throughput over BR/EDR. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Change default L2CAP ERTM retransmit timeoutMat Martineau2010-08-101-1/+1
| | | | | | | | The L2CAP specification requires that the ERTM retransmit timeout be at least 2 seconds for BR/EDR connections. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use __packed annotationGustavo F. Padovan2010-07-211-13/+13
| | | | | | | | | To make net/ and include/net/ code consistent use __packed instead of __attribute__ ((packed)). Bluetooth subsystem was one of the last net subsys still using __attribute__ ((packed)). Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add Google's copyright to L2CAPGustavo F. Padovan2010-07-211-0/+1
| | | | | Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add Copyright notice to L2CAPGustavo F. Padovan2010-07-211-0/+1
| | | | | | | | Copyright for the time I worked on L2CAP during the Google Summer of Code program. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove the send_lock spinlock from ERTMGustavo F. Padovan2010-07-211-1/+0
| | | | | | | | | Using a lock to deal with the ERTM race condition - interruption with new data from the hci layer - is wrong. We should use the native skb backlog queue. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Disconnect early if mode is not supportedGustavo F. Padovan2010-07-211-0/+5
| | | | | | | | When mode is mandatory we shall not send connect request and report this to the userspace as well. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix race condition on l2cap_ertm_send()Gustavo F. Padovan2010-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | l2cap_ertm_send() can be called both from user context and bottom half context. The socket locks for that contexts are different, the user context uses a mutex(which can sleep) and the second one uses a spinlock_bh. That creates a race condition when we have interruptions on both contexts at the same time. The better way to solve this is to add a new spinlock to lock l2cap_ertm_send() and the vars it access. The other solution was to defer l2cap_ertm_send() with a workqueue, but we the sending process already has one defer on the hci layer. It's not a good idea add another one. The patch refactor the code to create l2cap_retransmit_frames(), then we encapulate the lock of l2cap_ertm_send() for some call. It also changes l2cap_retransmit_frame() to l2cap_retransmit_one_frame() to avoid confusion Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement Local Busy Condition handlingGustavo F. Padovan2010-05-101-0/+6
| | | | | | | | | | | | | Supports Local Busy condition handling through a waitqueue that wake ups each 200ms and try to push the packets to the upper layer. If it can push all the queue then it leaves the Local Busy state. The patch modifies the behaviour of l2cap_ertm_reassembly_sdu() to support retry of the push operation. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Enable option to configure Max Transmission value via sockoptGustavo F. Padovan2010-05-101-0/+2
| | | | | | | | With the sockopt extension we can set a per-channel MaxTx value. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Change acknowledgement to use the value of txWindowGustavo F. Padovan2010-05-101-2/+1
| | | | | | | | | | | Now that we can set the txWindow we need to change the acknowledgement procedure to ack after each (pi->txWindow/6 + 1). The plus 1 is to avoid the zero value. It also renames pi->num_to_ack to a better name: pi->num_acked. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add sockopt configuration for txWindow on L2CAPGustavo F. Padovan2010-05-101-0/+2
| | | | | | | | Now we can set/get Transmission Window size via sockopt. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix configuration of the MPS valueGustavo F. Padovan2010-05-101-1/+2
| | | | | | | | | We were accepting values bigger than we can accept. This was leading ERTM to drop packets because of wrong FCS checks. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add timer to Acknowledge I-framesGustavo F. Padovan2010-05-101-0/+4
| | | | | | | | | | | | We ack I-frames on each txWindow/5 I-frames received, but if the sender stop to send I-frames and it's not a txWindow multiple we can leave some frames unacked. So I added a timer to ack I-frames on this case. The timer expires in 200ms. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement 'Send IorRRorRNR' eventGustavo F. Padovan2010-05-101-9/+11
| | | | | | | | | After receive a RR with P bit set ERTM shall use this funcion to choose what type of frame to reply with F bit = 1. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement RejActioned flagGustavo F. Padovan2009-12-031-0/+1
| | | | | | | | | | | | | | RejActioned is used to prevent retransmission when a entity is on the WAIT_F state, i.e., waiting for a frame with F-bit set due local busy condition or a expired retransmission timer. (When these two events raise they send a frame with the Poll bit set and enters in the WAIT_F state to wait for a frame with the Final bit set.) The local entity doesn't send I-frames(the data frames) until the receipt of a frame with F-bit set. When that happens it also set RejActioned to false. RejActioned is a mandatory feature of ERTM spec. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix sending ReqSeq on I-framesGustavo F. Padovan2009-12-031-1/+0
| | | | | | | | | | | | | | | | | As specified by ERTM spec an ERTM channel can acknowledge received I-frames(the data frames) by sending an I-frame with the proper ReqSeq value (i.e. ReqSeq is set to BufferSeq). Until now we aren't setting the ReqSeq value on I-frame control bits. That way we can save sending S-frames(Supervise frames) only to acknowledge receipt of I-frames. It is very helpful to the full-duplex channel. ReqSeq is the packet sequence number sent in an acknowledgement frame to acknowledge receipt of frames up to (ReqSeq - 1). BufferSeq controls the receiver buffer, it is used to delay acknowledgement of new frames to not cause buffer overflow. BufferSeq value is not increased until frames are pulled by reassembly function. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Handle L2CAP case when the remote receiver is busyGustavo F. Padovan2009-08-261-0/+2
| | | | | | | Implement all issues related to RemoteBusy in the RECV state table. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Full support for receiving L2CAP SREJ framesGustavo F. Padovan2009-08-221-0/+3
| | | | | | | Support for receiving of SREJ frames as specified by the state table. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for L2CAP SREJ exceptionGustavo F. Padovan2009-08-221-1/+13
| | | | | | | | | | When L2CAP loses an I-frame we send a SREJ frame to the transmitter side requesting the lost packet. This patch implement all Recv I-frame events on SREJ_SENT state table except the ones that deal with SendRej (the REJ exception at receiver side is yet not implemented). Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for FCS option to L2CAPGustavo F. Padovan2009-08-221-0/+2
| | | | | | | | | | | | | Implement CRC16 check for L2CAP packets. FCS is used by Streaming Mode and Enhanced Retransmission Mode and is a extra check for the packet content. Using CRC16 is the default, L2CAP won't use FCS only when both side send a "No FCS" request. Initially based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for Retransmission and Monitor TimersGustavo F. Padovan2009-08-221-3/+12
| | | | | | | | | | | L2CAP uses retransmission and monitor timers to inquiry the other side about unacked I-frames. After sending each I-frame we (re)start the retransmission timer. If it expires, we start a monitor timer that send a S-frame with P bit set and wait for S-frame with F bit set. If monitor timer expires, try again, at a maximum of L2CAP_DEFAULT_MAX_TX. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Initial support for retransmission of packets with REJ framesGustavo F. Padovan2009-08-221-0/+1
| | | | | | | | | | | | When receiving an I-frame with unexpected txSeq, receiver side start the recovery procedure by sending a REJ S-frame to the transmitter side. So the transmitter can re-send the lost I-frame. This patch just adds a basic support for retransmission, it doesn't mean that ERTM now has full support for packet retransmission. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for Segmentation and Reassembly of SDUsGustavo F. Padovan2009-08-221-1/+8
| | | | | | | | | | | | | | ERTM should use Segmentation and Reassembly to break down a SDU in many PDUs on sending data to the other side. On sending packets we queue all 'segments' until end of segmentation and just the add them to the queue for sending. On receiving we create a new SKB with the SDU reassembled. Initially based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add initial support for ERTM packets transfersGustavo F. Padovan2009-08-221-1/+53
| | | | | | | | | | | | | | This patch adds support for ERTM transfers, without retransmission, with txWindow up to 63 and with acknowledgement of packets received. Now the packets are queued before call l2cap_do_send(), so packets couldn't be sent at the time we call l2cap_sock_sendmsg(). They will be sent in an asynchronous way on later calls of l2cap_ertm_send(). Besides if an error occurs on calling l2cap_do_send() we disconnect the channel. Initially based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add configuration support for ERTM and Streaming modeGustavo F. Padovan2009-08-221-7/+21
| | | | | | | | | | | Add support to config_req and config_rsp to configure ERTM and Streaming mode. If the remote device specifies ERTM or Streaming mode, then the same mode is proposed. Otherwise ERTM or Basic mode is used. And in case of a state 2 device, the remote device should propose the same mode. If not, then the channel gets disconnected. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Allow setting of L2CAP ERTM via socket optionMarcel Holtmann2009-08-221-3/+5
| | | | | | | | | To enable Enhanced Retransmission mode it needs to be set via a socket option. A different mode can be set on a socket, but on listen() and connect() the mode is checked and ERTM is only allowed if it is enabled via the module parameter. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add basic constants for L2CAP ERTM support and use themMarcel Holtmann2009-06-081-21/+42
| | | | | | | | | This adds the basic constants required to add support for L2CAP Enhanced Retransmission feature. Based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use macro for L2CAP hint mask on receiving config requestGustavo F. Padovan2009-06-081-0/+2
| | | | | | | | Using the L2CAP_CONF_HINT macro is easier to understand than using a hardcoded 0x80 value. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use macros for L2CAP channel identifiersGustavo F. Padovan2009-06-081-0/+6
| | | | | | | | Use macros instead of hardcoded numbers to make the L2CAP source code more readable. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Ask upper layers for HCI disconnect reasonMarcel Holtmann2009-02-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the qualification tests demand that in case of failures in L2CAP the HCI disconnect should indicate a reason why L2CAP fails. This is a bluntly layer violation since multiple L2CAP connections could be using the same ACL and thus forcing a disconnect reason is not a good idea. To comply with the Bluetooth test specification, the disconnect reason is now stored in the L2CAP connection structure and every time a new L2CAP channel is added it will set back to its default. So only in the case where the L2CAP channel with the disconnect reason is really the last one, it will propagated to the HCI layer. The HCI layer has been extended with a disconnect indication that allows it to ask upper layers for a disconnect reason. The upper layer must not support this callback and in that case it will nicely default to the existing behavior. If an upper layer like L2CAP can provide a disconnect reason that one will be used to disconnect the ACL or SCO link. No modification to the ACL disconnect timeout have been made. So in case of Linux to Linux connection the initiator will disconnect the ACL link before the acceptor side can signal the specific disconnect reason. That is perfectly fine since Linux doesn't make use of this value anyway. The L2CAP layer has a perfect valid error code for rejecting connection due to a security violation. It is unclear why the Bluetooth specification insists on having specific HCI disconnect reason. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add CID field to L2CAP socket address structureMarcel Holtmann2009-02-271-0/+1
| | | | | | | | | | | | | | In preparation for L2CAP fixed channel support, the CID value of a L2CAP connection needs to be accessible via the socket interface. The CID is the connection identifier and exists as source and destination value. So extend the L2CAP socket address structure with this field and change getsockname() and getpeername() to fill it in. The bind() and connect() functions have been modified to handle L2CAP socket address structures of variable sizes. This makes them future proof if additional fields need to be added. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Request L2CAP fixed channel list if availableMarcel Holtmann2009-02-271-0/+1
| | | | | | | | | | If the extended features mask indicates support for fixed channels, request the list of available fixed channels. This also enables the fixed channel features bit so remote implementations can request information about it. Currently only the signal channel will be listed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix double L2CAP connection requestMarcel Holtmann2009-02-271-0/+1
| | | | | | | | | | | If the remote L2CAP server uses authentication pending stage and encryption is enabled it can happen that a L2CAP connection request is sent twice due to a race condition in the connection state machine. When the remote side indicates any kind of connection pending, then track this state and skip sending of L2CAP commands for this period. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix race condition with L2CAP information requestMarcel Holtmann2009-02-271-1/+2
| | | | | | | | | | When two L2CAP connections are requested quickly after the ACL link has been established there exists a window for a race condition where a connection request is sent before the information response has been received. Any connection request should only be sent after an exchange of the extended features mask has been finished. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Replace L2CAP link mode with security levelMarcel Holtmann2009-02-271-2/+3
| | | | | | | Change the L2CAP internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Fall back to L2CAP in basic modeMarcel Holtmann2007-10-221-0/+13
| | | | | | | In case the remote entity tries to negogiate retransmission or flow control mode, reject it and fall back to basic mode. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Retrieve L2CAP features mask on connection setupMarcel Holtmann2007-10-221-2/+12
| | | | | | | | | | The Bluetooth 1.2 specification introduced a specific features mask value to interoperate with newer versions of the specification. So far this piece of information was never needed, but future extensions will rely on it. This patch adds a generic way to retrieve this information only once per connection setup. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Remove global conf_mtu variable from L2CAPMarcel Holtmann2007-10-221-5/+5
| | | | | | | After the change to the L2CAP configuration parameter handling the global conf_mtu variable is no longer needed and so remove it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [BLUETOOTH] l2cap: endianness annotationsAl Viro2007-07-311-25/+25
| | | | | | | | no code changes, just documenting existing types Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Fix L2CAP configuration parameter handlingMarcel Holtmann2007-05-241-2/+6
| | | | | | | | | The L2CAP configuration parameter handling was missing the support for rejecting unknown options. The capability to reject unknown options is mandatory since the Bluetooth 1.2 specification. This patch implements its and also simplifies the parameter parsing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+238
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
generated by cgit v1.1 at 2024-05-29 08:34:45 +0000