Few more patches.
Patches 4 and 5 are significant:
- relaxed check for BACK start sequence
it fixes connectivity problem caused by firmware's funny
implementation of block ack
- Use larger Tx rings
boosts throughput
Vladimir Kondratiev (5):
wil6210: Convert to Kbuild
wil6210: fix printouts for better readability
wil6210: sync with the latest FW API
wil6210: relaxed check for BACK start sequence
wil6210: Use larger Tx rings
drivers/net/wireless/ath/wil6210/Kbuild | 18 ++++++++++
drivers/net/wireless/ath/wil6210/Makefile | 18 ----------
drivers/net/wireless/ath/wil6210/interrupt.c | 2 +-
drivers/net/wireless/ath/wil6210/main.c | 4 +--
drivers/net/wireless/ath/wil6210/pcie_bus.c | 2 --
drivers/net/wireless/ath/wil6210/rx_reorder.c | 17 +++++++++
drivers/net/wireless/ath/wil6210/wil6210.h | 3 +-
drivers/net/wireless/ath/wil6210/wmi.c | 11 +++---
drivers/net/wireless/ath/wil6210/wmi.h | 50 +++++++++++++++++----------
9 files changed, 77 insertions(+), 48 deletions(-)
create mode 100644 drivers/net/wireless/ath/wil6210/Kbuild
delete mode 100644 drivers/net/wireless/ath/wil6210/Makefile
--
1.8.3.2
On 2014-04-10 12:23, Vladimir Kondratiev wrote:
> On Thursday, April 10, 2014 10:22:47 AM Michal Marek wrote:
>> Kbuild is a slightly better choice because it better describes the
>> content, but I don't think its needed to rename existing Makefiles just
>> because of that. Kbuild is needed in the toplevel directory or in
>> arch/*/, where Makefile has a different special meaning. The out of tree
>> build use case can be solved by a GNUmakefile.
>>
>
> Originally, I followed the code found at
> drivers/scsi/osd/
> They have Kbuild for in-kernel use and Makefile for out-of-tree
>
> But now I found, Documentation/kbuild/makefiles.txt says:
> ---cut---
> The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can
> be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild'
> file will be used.
> ---cut---
>
> Accordingly to this, would you say I should drop this patch and go with
> GNUmakefile + Makefile for internal development? I am pretty neutral with
> this, just need to know what is the proper way.
It's up to you, since it's your driver :). But the trick with
GNUmakefile works with the driver as-is as well as any other driver, so
it might be easier just to use that.
Michal
On Thursday, April 10, 2014 01:06:11 PM Michal Marek wrote:
> It's up to you, since it's your driver :).
Then, I like Kbuild + Makefile better. This makes it clear
kbuild file is not 'real' top-level makefile.
So, let's keep this patch as it is.
Thanks, Vladimir
(adding Michal Marek)
On Wed, 2014-04-09 at 17:08 +0300, Vladimir Kondratiev wrote:
> On Tuesday, April 08, 2014 09:14:51 AM Joe Perches wrote:
> > On Tue, 2014-04-08 at 11:36 +0300, Vladimir Kondratiev wrote:
> > > Convert Makefile -> Kbuild,
> > > to make off-kernel development easier and less intrusive.
> > No drivers/net directory uses Kbuild.
> > Why should this?
>
> because it makes it easier to do off-kernel development, and then
> move things to the proper location within the kernel without
> conflicting changes in the Makefile.
> As I understand, Kbuild is better choice because it is really not
> standalone "Makefile", it is intended to be included by the real
> Makefile. Thus, distinct name is better.
> Are there any reasons why not using Kbuild? I did not found
> guidelines when use Kbuild and when not.
Michal? Any opinion?
On Thu, 2014-04-10 at 13:23 +0300, Vladimir Kondratiev wrote:
> Accordingly to this, would you say I should drop this patch and go with
> GNUmakefile + Makefile for internal development? I am pretty neutral with
> this, just need to know what is the proper way.
Or you could just use the backports project for that :)
johannes
On Tue, 2014-04-08 at 11:36 +0300, Vladimir Kondratiev wrote:
> Convert Makefile -> Kbuild,
> to make off-kernel development easier and less intrusive.
No drivers/net directory uses Kbuild.
Why should this?
> Signed-off-by: Vladimir Kondratiev <[email protected]>
> ---
> drivers/net/wireless/ath/wil6210/Kbuild | 18 ++++++++++++++++++
> drivers/net/wireless/ath/wil6210/Makefile | 18 ------------------
If you send renaming patches, please use
git format-patch -M
On Tuesday, April 08, 2014 09:14:51 AM Joe Perches wrote:
> On Tue, 2014-04-08 at 11:36 +0300, Vladimir Kondratiev wrote:
> > Convert Makefile -> Kbuild,
> > to make off-kernel development easier and less intrusive.
>
> No drivers/net directory uses Kbuild.
>
> Why should this?
because it makes it easier to do off-kernel development, and then
move things to the proper location within the kernel without
conflicting changes in the Makefile.
As I understand, Kbuild is better choice because it is really not
standalone "Makefile", it is intended to be included by the real
Makefile. Thus, distinct name is better.
Are there any reasons why not using Kbuild? I did not found
guidelines when use Kbuild and when not.
>
> > Signed-off-by: Vladimir Kondratiev <[email protected]>
> > ---
> > drivers/net/wireless/ath/wil6210/Kbuild | 18 ++++++++++++++++++
> > drivers/net/wireless/ath/wil6210/Makefile | 18 ------------------
>
> If you send renaming patches, please use
> git format-patch -M
Sure I will. Thanks for mentioning this.
Thanks, Vladimir
On 2014-04-09 18:06, Joe Perches wrote:
> (adding Michal Marek)
>
> On Wed, 2014-04-09 at 17:08 +0300, Vladimir Kondratiev wrote:
>> On Tuesday, April 08, 2014 09:14:51 AM Joe Perches wrote:
>>> On Tue, 2014-04-08 at 11:36 +0300, Vladimir Kondratiev wrote:
>>>> Convert Makefile -> Kbuild,
>>>> to make off-kernel development easier and less intrusive.
>>> No drivers/net directory uses Kbuild.
>>> Why should this?
>>
>> because it makes it easier to do off-kernel development, and then
>> move things to the proper location within the kernel without
>> conflicting changes in the Makefile.
You can create a GNUmakefile for this purpose, it takes precedence over
Makefile.
>> As I understand, Kbuild is better choice because it is really not
>> standalone "Makefile", it is intended to be included by the real
>> Makefile. Thus, distinct name is better.
>> Are there any reasons why not using Kbuild? I did not found
>> guidelines when use Kbuild and when not.
Kbuild is a slightly better choice because it better describes the
content, but I don't think its needed to rename existing Makefiles just
because of that. Kbuild is needed in the toplevel directory or in
arch/*/, where Makefile has a different special meaning. The out of tree
build use case can be solved by a GNUmakefile.
Michal
- add pcp_max_assoc_sta to the struct wmi_pcp_start_cmd
- enum for the scan ststus
Signed-off-by: Vladimir Kondratiev <[email protected]>
---
drivers/net/wireless/ath/wil6210/wmi.c | 3 +-
drivers/net/wireless/ath/wil6210/wmi.h | 50 +++++++++++++++++++++-------------
2 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index b7764f3..e9a11cb 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -348,7 +348,7 @@ static void wmi_evt_scan_complete(struct wil6210_priv *wil, int id,
{
if (wil->scan_request) {
struct wmi_scan_complete_event *data = d;
- bool aborted = (data->status != 0);
+ bool aborted = (data->status != WMI_SCAN_SUCCESS);
wil_dbg_wmi(wil, "SCAN_COMPLETE(0x%08x)\n", data->status);
cfg80211_scan_done(wil->scan_request, aborted);
@@ -802,6 +802,7 @@ int wmi_pcp_start(struct wil6210_priv *wil, int bi, u8 wmi_nettype, u8 chan)
.network_type = wmi_nettype,
.disable_sec_offload = 1,
.channel = chan - 1,
+ .pcp_max_assoc_sta = WIL6210_MAX_CID,
};
struct {
struct wil6210_mbox_hdr_wmi wmi;
diff --git a/drivers/net/wireless/ath/wil6210/wmi.h b/drivers/net/wireless/ath/wil6210/wmi.h
index 50b8528..17334c8 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.h
+++ b/drivers/net/wireless/ath/wil6210/wmi.h
@@ -28,7 +28,7 @@
#define __WILOCITY_WMI_H__
/* General */
-
+#define WILOCITY_MAX_ASSOC_STA (8)
#define WMI_MAC_LEN (6)
#define WMI_PROX_RANGE_NUM (3)
@@ -219,15 +219,6 @@ struct wmi_disconnect_sta_cmd {
__le16 disconnect_reason;
} __packed;
-/*
- * WMI_RECONNECT_CMDID
- */
-struct wmi_reconnect_cmd {
- u8 channel; /* hint */
- u8 reserved;
- u8 bssid[WMI_MAC_LEN]; /* mandatory if set */
-} __packed;
-
/*
* WMI_SET_PMK_CMDID
@@ -296,11 +287,13 @@ enum wmi_scan_type {
WMI_LONG_SCAN = 0,
WMI_SHORT_SCAN = 1,
WMI_PBC_SCAN = 2,
+ WMI_ACTIVE_SCAN = 3,
+ WMI_DIRECT_SCAN = 4,
};
struct wmi_start_scan_cmd {
- u8 reserved[8];
-
+ u8 direct_scan_mac_addr[6];
+ u8 reserved[2];
__le32 home_dwell_time; /* Max duration in the home channel(ms) */
__le32 force_scan_interval; /* Time interval between scans (ms)*/
u8 scan_type; /* wmi_scan_type */
@@ -332,6 +325,7 @@ struct wmi_probed_ssid_cmd {
u8 ssid[WMI_MAX_SSID_LEN];
} __packed;
+
/*
* WMI_SET_APPIE_CMDID
* Add Application specified IE to a management frame
@@ -427,7 +421,7 @@ struct wmi_bcon_ctrl_cmd {
__le16 frag_num;
__le64 ss_mask;
u8 network_type;
- u8 reserved;
+ u8 pcp_max_assoc_sta;
u8 disable_sec_offload;
u8 disable_sec;
} __packed;
@@ -450,7 +444,7 @@ enum wmi_port_role {
struct wmi_port_allocate_cmd {
u8 mac[WMI_MAC_LEN];
u8 port_role;
- u8 midid;
+ u8 mid;
} __packed;
/*
@@ -467,6 +461,7 @@ struct wmi_delete_port_cmd {
enum wmi_discovery_mode {
WMI_DISCOVERY_MODE_NON_OFFLOAD = 0,
WMI_DISCOVERY_MODE_OFFLOAD = 1,
+ WMI_DISCOVERY_MODE_PEER2PEER = 2,
};
struct wmi_p2p_cfg_cmd {
@@ -493,7 +488,8 @@ struct wmi_power_mgmt_cfg_cmd {
*/
struct wmi_pcp_start_cmd {
__le16 bcon_interval;
- u8 reserved0[10];
+ u8 pcp_max_assoc_sta;
+ u8 reserved0[9];
u8 network_type;
u8 channel;
u8 disable_sec_offload;
@@ -857,6 +853,7 @@ enum wmi_event_id {
WMI_RF_MGMT_STATUS_EVENTID = 0x1853,
WMI_BF_SM_MGMT_DONE_EVENTID = 0x1838,
WMI_RX_MGMT_PACKET_EVENTID = 0x1840,
+ WMI_TX_MGMT_PACKET_EVENTID = 0x1841,
/* Performance monitoring events */
WMI_DATA_PORT_OPEN_EVENTID = 0x1860,
@@ -1040,16 +1037,23 @@ enum wmi_disconnect_reason {
struct wmi_disconnect_event {
__le16 protocol_reason_status; /* reason code, see 802.11 spec. */
u8 bssid[WMI_MAC_LEN]; /* set if known */
- u8 disconnect_reason; /* see wmi_disconnect_reason_e */
- u8 assoc_resp_len;
- u8 assoc_info[0];
+ u8 disconnect_reason; /* see wmi_disconnect_reason */
+ u8 assoc_resp_len; /* not in use */
+ u8 assoc_info[0]; /* not in use */
} __packed;
/*
* WMI_SCAN_COMPLETE_EVENTID
*/
+enum scan_status {
+ WMI_SCAN_SUCCESS = 0,
+ WMI_SCAN_FAILED = 1,
+ WMI_SCAN_ABORTED = 2,
+ WMI_SCAN_REJECTED = 3,
+};
+
struct wmi_scan_complete_event {
- __le32 status;
+ __le32 status; /* scan_status */
} __packed;
/*
@@ -1256,6 +1260,14 @@ struct wmi_rx_mgmt_info {
u8 channel; /* From Radio MNGR */
} __packed;
+
+/*
+ * WMI_TX_MGMT_PACKET_EVENTID
+ */
+struct wmi_tx_mgmt_packet_event {
+ u8 payload[0];
+} __packed;
+
struct wmi_rx_mgmt_packet_event {
struct wmi_rx_mgmt_info info;
u8 payload[0];
--
1.8.3.2
Sometimes, due to the race between Rx path and WMI_BA_STATUS_EVENTID WMI event,
few frames may be passed to the stack before reorder buffer allocated.
Then, after BACK establishment, it start getting frames with sequence number ahead of
SSN, and it get interpreted as missing frames. Then, BACK mechanism will wait
for missing frames; data traffic will be stopped. In case of interface configured
for DHCP, this data delay causes DHCP failure.
Relax checking for sequence number; use sequence of 1-st frame handled by the buffer
as SSN for this buffer.
This is work-around, real fix should be done when proper BACK mechanism implemented.
Signed-off-by: Vladimir Kondratiev <[email protected]>
---
drivers/net/wireless/ath/wil6210/rx_reorder.c | 17 +++++++++++++++++
drivers/net/wireless/ath/wil6210/wil6210.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/net/wireless/ath/wil6210/rx_reorder.c b/drivers/net/wireless/ath/wil6210/rx_reorder.c
index d04629f..ec29954 100644
--- a/drivers/net/wireless/ath/wil6210/rx_reorder.c
+++ b/drivers/net/wireless/ath/wil6210/rx_reorder.c
@@ -91,6 +91,22 @@ void wil_rx_reorder(struct wil6210_priv *wil, struct sk_buff *skb)
spin_lock(&r->reorder_lock);
+ /** Due to the race between WMI events, where BACK establishment
+ * reported, and data Rx, few packets may be pass up before reorder
+ * buffer get allocated. Catch up by pretending SSN is what we
+ * see in the 1-st Rx packet
+ */
+ if (r->first_time) {
+ r->first_time = false;
+ if (seq != r->head_seq_num) {
+ wil_err(wil, "Error: 1-st frame with wrong sequence"
+ " %d, should be %d. Fixing...\n", seq,
+ r->head_seq_num);
+ r->head_seq_num = seq;
+ r->ssn = seq;
+ }
+ }
+
/* frame with out of date sequence number */
if (seq_less(seq, r->head_seq_num)) {
dev_kfree_skb(skb);
@@ -162,6 +178,7 @@ struct wil_tid_ampdu_rx *wil_tid_ampdu_rx_alloc(struct wil6210_priv *wil,
r->head_seq_num = ssn;
r->buf_size = size;
r->stored_mpdu_num = 0;
+ r->first_time = true;
return r;
}
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index 2a2dec7..f881aee 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -301,6 +301,7 @@ struct wil_tid_ampdu_rx {
u16 buf_size;
u16 timeout;
u8 dialog_token;
+ bool first_time; /* is it 1-st time this buffer used? */
};
struct wil6210_stats {
--
1.8.3.2
Convert Makefile -> Kbuild,
to make off-kernel development easier and less intrusive.
Signed-off-by: Vladimir Kondratiev <[email protected]>
---
drivers/net/wireless/ath/wil6210/Kbuild | 18 ++++++++++++++++++
drivers/net/wireless/ath/wil6210/Makefile | 18 ------------------
2 files changed, 18 insertions(+), 18 deletions(-)
create mode 100644 drivers/net/wireless/ath/wil6210/Kbuild
delete mode 100644 drivers/net/wireless/ath/wil6210/Makefile
diff --git a/drivers/net/wireless/ath/wil6210/Kbuild b/drivers/net/wireless/ath/wil6210/Kbuild
new file mode 100644
index 0000000..c7a3465
--- /dev/null
+++ b/drivers/net/wireless/ath/wil6210/Kbuild
@@ -0,0 +1,18 @@
+obj-$(CONFIG_WIL6210) += wil6210.o
+
+wil6210-y := main.o
+wil6210-y += netdev.o
+wil6210-y += cfg80211.o
+wil6210-y += pcie_bus.o
+wil6210-y += debugfs.o
+wil6210-y += wmi.o
+wil6210-y += interrupt.o
+wil6210-y += txrx.o
+wil6210-y += debug.o
+wil6210-y += rx_reorder.o
+wil6210-$(CONFIG_WIL6210_TRACING) += trace.o
+
+# for tracing framework to find trace.h
+CFLAGS_trace.o := -I$(src)
+
+subdir-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/wireless/ath/wil6210/Makefile b/drivers/net/wireless/ath/wil6210/Makefile
deleted file mode 100644
index c7a3465..0000000
--- a/drivers/net/wireless/ath/wil6210/Makefile
+++ /dev/null
@@ -1,18 +0,0 @@
-obj-$(CONFIG_WIL6210) += wil6210.o
-
-wil6210-y := main.o
-wil6210-y += netdev.o
-wil6210-y += cfg80211.o
-wil6210-y += pcie_bus.o
-wil6210-y += debugfs.o
-wil6210-y += wmi.o
-wil6210-y += interrupt.o
-wil6210-y += txrx.o
-wil6210-y += debug.o
-wil6210-y += rx_reorder.o
-wil6210-$(CONFIG_WIL6210_TRACING) += trace.o
-
-# for tracing framework to find trace.h
-CFLAGS_trace.o := -I$(src)
-
-subdir-ccflags-y += -D__CHECK_ENDIAN__
--
1.8.3.2
Reshuffle prints to consolidate firmware/hardware information
report upon card init
Convert print for unhandled MISC ISR bits to "debug" - it is
normal situation and not an "error"
Signed-off-by: Vladimir Kondratiev <[email protected]>
---
drivers/net/wireless/ath/wil6210/interrupt.c | 2 +-
drivers/net/wireless/ath/wil6210/main.c | 4 ++--
drivers/net/wireless/ath/wil6210/pcie_bus.c | 2 --
drivers/net/wireless/ath/wil6210/wmi.c | 8 ++++----
4 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c b/drivers/net/wireless/ath/wil6210/interrupt.c
index 5824cd4..73593aa 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -338,7 +338,7 @@ static irqreturn_t wil6210_irq_misc_thread(int irq, void *cookie)
}
if (isr)
- wil_err(wil, "un-handled MISC ISR bits 0x%08x\n", isr);
+ wil_dbg_irq(wil, "un-handled MISC ISR bits 0x%08x\n", isr);
wil->isr_misc = 0;
diff --git a/drivers/net/wireless/ath/wil6210/main.c b/drivers/net/wireless/ath/wil6210/main.c
index 95f4efe..1b265fd 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -363,8 +363,8 @@ static int wil_wait_for_fw_ready(struct wil6210_priv *wil)
wil_err(wil, "Firmware not ready\n");
return -ETIME;
} else {
- wil_dbg_misc(wil, "FW ready after %d ms\n",
- jiffies_to_msecs(to-left));
+ wil_info(wil, "FW ready after %d ms. HW version 0x%08x\n",
+ jiffies_to_msecs(to-left), wil->hw_version);
}
return 0;
}
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 58fc096..27746e8 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -76,8 +76,6 @@ static int wil_if_pcie_enable(struct wil6210_priv *wil)
if (rc)
goto release_irq;
- wil_info(wil, "HW version: 0x%08x\n", wil->hw_version);
-
return 0;
release_irq:
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index 2ba56ee..b7764f3 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -192,7 +192,7 @@ static int __wmi_send(struct wil6210_priv *wil, u16 cmdid, void *buf, u16 len)
might_sleep();
if (!test_bit(wil_status_fwready, &wil->status)) {
- wil_err(wil, "FW not ready\n");
+ wil_err(wil, "WMI: cannot send command while FW not ready\n");
return -EAGAIN;
}
@@ -276,8 +276,8 @@ static void wmi_evt_ready(struct wil6210_priv *wil, int id, void *d, int len)
wil->fw_version = le32_to_cpu(evt->sw_version);
wil->n_mids = evt->numof_additional_mids;
- wil_dbg_wmi(wil, "FW ver. %d; MAC %pM; %d MID's\n", wil->fw_version,
- evt->mac, wil->n_mids);
+ wil_info(wil, "FW ver. %d; MAC %pM; %d MID's\n", wil->fw_version,
+ evt->mac, wil->n_mids);
if (!is_valid_ether_addr(ndev->dev_addr)) {
memcpy(ndev->dev_addr, evt->mac, ETH_ALEN);
@@ -290,7 +290,7 @@ static void wmi_evt_ready(struct wil6210_priv *wil, int id, void *d, int len)
static void wmi_evt_fw_ready(struct wil6210_priv *wil, int id, void *d,
int len)
{
- wil_dbg_wmi(wil, "WMI: FW ready\n");
+ wil_dbg_wmi(wil, "WMI: got FW ready event\n");
set_bit(wil_status_fwready, &wil->status);
/* reuse wmi_ready for the firmware ready indication */
--
1.8.3.2
When using scatter-gather, more descriptor entries get used.
Signed-off-by: Vladimir Kondratiev <[email protected]>
---
drivers/net/wireless/ath/wil6210/wil6210.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index f881aee..d3b8659 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -35,7 +35,7 @@ static inline u32 WIL_GET_BITS(u32 x, int b0, int b1)
#define WIL6210_MEM_SIZE (2*1024*1024UL)
#define WIL6210_RX_RING_SIZE (128)
-#define WIL6210_TX_RING_SIZE (128)
+#define WIL6210_TX_RING_SIZE (512)
#define WIL6210_MAX_TX_RINGS (24) /* HW limit */
#define WIL6210_MAX_CID (8) /* HW limit */
#define WIL6210_NAPI_BUDGET (16) /* arbitrary */
--
1.8.3.2
On Thursday, April 10, 2014 10:22:47 AM Michal Marek wrote:
> On 2014-04-09 18:06, Joe Perches wrote:
> > (adding Michal Marek)
> >
> > On Wed, 2014-04-09 at 17:08 +0300, Vladimir Kondratiev wrote:
> >> On Tuesday, April 08, 2014 09:14:51 AM Joe Perches wrote:
> >>> On Tue, 2014-04-08 at 11:36 +0300, Vladimir Kondratiev wrote:
> >>>> Convert Makefile -> Kbuild,
> >>>> to make off-kernel development easier and less intrusive.
> >>> No drivers/net directory uses Kbuild.
> >>> Why should this?
> >>
> >> because it makes it easier to do off-kernel development, and then
> >> move things to the proper location within the kernel without
> >> conflicting changes in the Makefile.
>
> You can create a GNUmakefile for this purpose, it takes precedence over
> Makefile.
>
>
> >> As I understand, Kbuild is better choice because it is really not
> >> standalone "Makefile", it is intended to be included by the real
> >> Makefile. Thus, distinct name is better.
> >> Are there any reasons why not using Kbuild? I did not found
> >> guidelines when use Kbuild and when not.
>
> Kbuild is a slightly better choice because it better describes the
> content, but I don't think its needed to rename existing Makefiles just
> because of that. Kbuild is needed in the toplevel directory or in
> arch/*/, where Makefile has a different special meaning. The out of tree
> build use case can be solved by a GNUmakefile.
>
Originally, I followed the code found at
drivers/scsi/osd/
They have Kbuild for in-kernel use and Makefile for out-of-tree
But now I found, Documentation/kbuild/makefiles.txt says:
---cut---
The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can
be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild'
file will be used.
---cut---
Accordingly to this, would you say I should drop this patch and go with
GNUmakefile + Makefile for internal development? I am pretty neutral with
this, just need to know what is the proper way.
Thanks, Vladimir