[PATCH]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

I get a board with 8168e-vl(10ec:8168 with RTL_GIGA_MAC_VER_34),
everything looks well first, I can use ifconfig to set ip, netmask,
etc. And the rx/tx statistics show by ifconfig looks good when I
ping another host or ping it from another host. But it don't work,
I can't get ICMP REPLAY from both sides, although the RX/TX statistics
seem good.

After add some debug code, I found this NIC only accept ethernet
broadcast package, it can't filter out the package send to its
MAC address, but it works good for sending.So ifconfig show the
RX/TX status means it can receive ARP package.(It don't its MAC
address, so below)

I have try the driver provided by realtek's website, it have the
same problem at the first time. BUT IT WORK AFTER I REBOOT with
CRTL-ALT-DEL, the reason is that realtek's driver call rtl8168_rar_set
in the .shutdown function register with pci_register_driver. Yes,
the really reason to make it work is rtl8689_rar_set, this function
set extended GigaMAC registers, so after reboot without lost the power,
NIC keep the status before reboot.

I haven't see any code to set GigaMAC registers in kernel when boot,
so I guess BIOS or NIC's circuit make it, but of course one miss
the extended GigaMAC registers  in this problem. The probe code can
get MAC address right, so MAC{0,4} must had been setted, but some
guys forget the extended GigaMAC registers.

This patch fix it.
[ I don't known whether others' realtek's NIC with extended GigaMAC
reigisters have the same problem, I meet it in 8168e-vl with
RTL_GIGA_MAC_VER_34, so I make this patch just for it.]

Signed-off-by: Wang YanQing 
---
 drivers/net/ethernet/realtek/r8169.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 927aa33..e49c08d 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3095,7 +3095,30 @@ static void rtl8168e_1_hw_phy_config(struct 
rtl8169_private *tp)
rtl_writephy(tp, 0x0e, 0x);
rtl_writephy(tp, 0x0d, 0x);
 }
+static void rtl8168e_2_workaround(struct rtl8169_private *tp, u8 *addr)
+{
+   void __iomem *ioaddr = tp->mmio_addr;
+   u32 high;
+   u32 low;
+
+   low  = addr[0] | (addr[1] << 8) | (addr[2] << 16) | (addr[3] << 24);
+   high = addr[4] | (addr[5] << 8);
+
+
+   RTL_W8(Cfg9346, Cfg9346_Unlock);
+   if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+   const struct exgmac_reg e[] = {
+   { .addr = 0xe0, ERIAR_MASK_, .val = low },
+   { .addr = 0xe4, ERIAR_MASK_, .val = high },
+   { .addr = 0xf0, ERIAR_MASK_, .val = low << 16 },
+   { .addr = 0xf4, ERIAR_MASK_, .val = high << 16 |
+   low  >> 16 },
+   };
 
+   rtl_write_exgmac_batch(tp, e, ARRAY_SIZE(e));
+   }
+   RTL_W8(Cfg9346, Cfg9346_Lock);
+}
 static void rtl8168e_2_hw_phy_config(struct rtl8169_private *tp)
 {
static const struct phy_reg phy_reg_init[] = {
@@ -3178,6 +3201,7 @@ static void rtl8168e_2_hw_phy_config(struct 
rtl8169_private *tp)
rtl_w1w0_phy(tp, 0x19, 0x, 0x0001);
rtl_w1w0_phy(tp, 0x10, 0x, 0x0400);
rtl_writephy(tp, 0x1f, 0x);
+   rtl8168e_2_workaround(tp, tp->dev->dev_addr);
 }
 
 static void rtl8168f_hw_phy_config(struct rtl8169_private *tp)
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

On Fri, Nov 30, 2012 at 07:35:00AM +0100, Francois Romieu wrote:
> Which kernel version is it ?
I have done the test and debug  with mainline 
e23739b4ade80a3a7f87198f008f6c44a7cbc9fd, v3.7-rc7-51-ge23739b

> I'd rather see the GigaMAC registers written through a call to
> rtl_rar_set when the mac address is read in rtl_init_one instead
> of duplicating most of rtl_rar_set in a quite different place.

I have the same feeling with you, I will resend the patch follow
your opinion if everything pass test and work.

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

I get a board with 8168e-vl(10ec:8168 with RTL_GIGA_MAC_VER_34),
everything looks well first, I can use ifconfig to set ip, netmask,
etc. And the rx/tx statistics show by ifconfig looks good when I
ping another host or ping it from another host. But it don't work,
I can't get ICMP REPLAY from both sides, although the RX/TX statistics
seem good.

After add some debug code, I found this NIC only accept ethernet
broadcast package, it can't filter out the package send to its
MAC address, but it works good for sending.So ifconfig show the
RX/TX status means it can receive ARP package.(It don't know its
MAC address, so below)

I have try the driver provided by realtek's website, it have the
same problem at the first time. BUT IT WORK AFTER I REBOOT with
CRTL-ALT-DEL, the reason is that realtek's driver call rtl8168_rar_set
in the .shutdown function register with pci_register_driver. Yes,
the really reason to make it work is rtl8689_rar_set, this function
set extended GigaMAC registers, so after reboot without lost the power,
NIC keep the status before reboot.

I haven't see any code to set GigaMAC registers in kernel when boot,
so I guess BIOS or NIC's circuit make it, but of course one miss
the extended GigaMAC registers  in this problem. The probe code can
get MAC address right, so MAC{0,4} must had been setted, but some
guys forget the extended GigaMAC registers.

This patch fix it.

[ I don't known whether others' realtek's NIC with extended GigaMAC
reigisters have the same problem, I meet it in 8168e-vl with
RTL_GIGA_MAC_VER_34, so I make this patch just for it.]

Changes:
V1-V2:
I follow Francois Romieu 's below opinion to make this patch oneline:

I'd rather see the GigaMAC registers written through a call to
rtl_rar_set when the mac address is read in rtl_init_one instead of
duplicating most of rtl_rar_set in a quite different place.

Signed-off-by: Wang YanQing 
---
 drivers/net/ethernet/realtek/r8169.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 927aa33..cb1dce4 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6903,6 +6903,7 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
dev->dev_addr[i] = RTL_R8(MAC0 + i);
memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
 
+   rtl_rar_set(tp, dev->dev_addr);
SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
 
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

On Fri, Nov 30, 2012 at 05:04:29PM +0800, Wang YanQing wrote:
> On Fri, Nov 30, 2012 at 07:35:00AM +0100, Francois Romieu wrote:
> > Which kernel version is it ?
> I have done the test and debug  with mainline 
> e23739b4ade80a3a7f87198f008f6c44a7cbc9fd, v3.7-rc7-51-ge23739b
More exactly, I find the problem in 3.0 stable tree, and fix it
for 3.0 stable tree first, then re test and debug for mainline,
e23739b4ade80a3a7f87198f008f6c44a7cbc9fd, v3.7-rc7-51-ge23739b.

I found the mainline's r8169 works the same as realtek's driver,
the first time don't work, but it works after reboot, the reason
is the pci driver's shutdown don't call rtl_rar_set in 3.0 stable
tree but the mainline does.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lib80211: make lib80211 can be enabled independently

[Wang YanQing]

Current we can only enable lib80211 by enable a driver
in tree use it which will select it, but some out tree's
drivers also use it, so I think it has sense to make lib80211
can be enabled independently.

A example of the out tree's drivers use lib80211 is:
hybird driver(wl) for Broadcom Corporation BCM43225 802.11b/g/n

Signed-off-by: Wang YanQing 
---
 net/wireless/Kconfig | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 16d08b3..6e83f0a 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -140,22 +140,34 @@ config CFG80211_WEXT
  extensions with cfg80211-based drivers.
 
 config LIB80211
-   tristate
+   tristate "common routines used by IEEE802.11 wireless LAN drivers"
default n
help
  This options enables a library of common routines used
  by IEEE802.11 wireless LAN drivers.
 
- Drivers should select this themselves if needed.
+ Drivers could select this themselves if needed.
 
 config LIB80211_CRYPT_WEP
-   tristate
+   tristate "host-based WEP encryption implementation for lib80211"
+   depends on LIB80211
+   default n
+   ---help---
+  host-based WEP encryption implementation for lib80211
 
 config LIB80211_CRYPT_CCMP
-   tristate
+   tristate "host-based CCMP encryption implementation for lib80211"
+   depends on LIB80211
+   default n
+   ---help---
+  host-based CCMP encryption implementation for lib80211
 
 config LIB80211_CRYPT_TKIP
-   tristate
+   tristate "host-based TKIP encryption implementation for lib80211"
+   depends on LIB80211
+   default n
+   ---help---
+   host-based TKIP encryption implementation for lib80211
 
 config LIB80211_DEBUG
bool "lib80211 debugging messages"
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lib80211: make lib80211 can be enabled independently

[Wang YanQing]

On Fri, Apr 05, 2013 at 10:51:30AM +1100, Julian Calaby wrote:
> Just as a bit of explanation for Johannes' NACK:
> 
> 1. The only reason lib80211 still exists is because a couple of
> in-tree drivers still use it. If this weren't the case, the code would
> have been removed a long time ago as it's been completely replaced by
> mac80211 and cfg80211. All modern drivers _must_ use mac80211 or
> cfg80211 without exception.
> 2. In general, there is no official in-kernel support for
> out-of-kernel drivers, regardless of quality, status or importance.
> 3. I believe that the in-tree brcmsmac driver already supports the
> Broadcom card you reference.

Hi Julian.

Thanks for your complete explanation.
I have tried in-tree brcmsmac driver and it works well,
I use it to send out this email! This is wonderful, then
I don't need to fix compilation errors about the old, ugly
and closed wl driver for my notebook with BCM43225 802.11b/g/n
every time I upgrade kernel.

Thanks Julian and all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]smp: Fix send func call IPI to empty cpu mask

[Wang YanQing]

I get below warning every day with 3.7,
one or two times per day.

[ 2235.186027] WARNING: at 
/mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 
default_send_IPI_mask_logical+0x2f/0xb8()
[ 2235.186030] Hardware name: Aspire 4741
[ 2235.186032] empty IPI mask
[ 2235.186034] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) 
vboxdrv(O) nvidia(PO) wl(O)
[ 2235.186046] Pid: 5542, comm: pool Tainted: P   O 3.7.2+ #41
[ 2235.186049] Call Trace:
[ 2235.186059]  [] warn_slowpath_common+0x65/0x7a
[ 2235.186064]  [] ? default_send_IPI_mask_logical+0x2f/0xb8
[ 2235.186069]  [] warn_slowpath_fmt+0x26/0x2a
[ 2235.186074]  [] default_send_IPI_mask_logical+0x2f/0xb8
[ 2235.186079]  [] native_send_call_func_ipi+0x4f/0x57
[ 2235.186087]  [] smp_call_function_many+0x191/0x1a9
[ 2235.186092]  [] ? do_flush_tlb_all+0x3f/0x3f
[ 2235.186097]  [] native_flush_tlb_others+0x21/0x24
[ 2235.186101]  [] flush_tlb_page+0x63/0x89
[ 2235.186105]  [] ptep_set_access_flags+0x20/0x26
[ 2235.186111]  [] do_wp_page+0x234/0x502
[ 2235.186117]  [] ? T.2009+0x31/0x35
[ 2235.186121]  [] handle_pte_fault+0x50d/0x54c
[ 2235.186128]  [] ? irq_exit+0x5f/0x61
[ 2235.186133]  [] ? smp_call_function_interrupt+0x2c/0x2e
[ 2235.186143]  [] ? call_function_interrupt+0x2d/0x34
[ 2235.186148]  [] handle_mm_fault+0xd0/0xe2
[ 2235.186153]  [] __do_page_fault+0x411/0x42d
[ 2235.186158]  [] ? sys_futex+0xa9/0xee
[ 2235.186162]  [] ? __do_page_fault+0x42d/0x42d
[ 2235.186166]  [] do_page_fault+0x8/0xa
[ 2235.186170]  [] error_code+0x5a/0x60
[ 2235.186174]  [] ? __do_page_fault+0x42d/0x42d
[ 2235.186177] ---[ end trace 089b20858c3cb340 ]---

This patch fix it.

This patch also fix some system hang problem:
If the data->cpumask been cleared after pass

if (WARN_ONCE(!mask, "empty IPI mask"))
return;
then the problem 83d349f3 fix will happen again.

Signed-off-by: Wang YanQing 
---
 kernel/smp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index 29dd40a..7c56aba 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -33,6 +33,7 @@ struct call_function_data {
struct call_single_data csd;
atomic_trefs;
cpumask_var_t   cpumask;
+   cpumask_var_t   cpumask_ipi;
 };
 
 static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
@@ -526,6 +527,13 @@ void smp_call_function_many(const struct cpumask *mask,
return;
}
 
+   /*
+* After we put entry into list, data->cpumask
+* may be cleared when others cpu respone other
+* IPI for call function, then data->cpumask will
+* be zero.
+*/
+   cpumask_copy(data->cpumask_ipi, data->cpumask);
raw_spin_lock_irqsave(&call_function.lock, flags);
/*
 * Place entry at the _HEAD_ of the list, so that any cpu still
@@ -549,7 +557,7 @@ void smp_call_function_many(const struct cpumask *mask,
smp_mb();
 
/* Send a message to all CPUs in the map */
-   arch_send_call_function_ipi_mask(data->cpumask);
+   arch_send_call_function_ipi_mask(data->cpumask_ipi);
 
/* Optionally wait for the CPUs to complete */
if (wait)
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]video:uvesafb: Fix dereference NULL pointer code path

[Wang YanQing]

platform_device_alloc could failed and return NULL,
we should check this before call platform_device_put.

Signed-off-by: Wang YanQing 
---
 drivers/video/uvesafb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f8f82d..230bd45 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -1975,7 +1975,8 @@ static int __devinit uvesafb_init(void)
err = -ENOMEM;
 
if (err) {
-   platform_device_put(uvesafb_device);
+   if (uvesafb_device)
+   platform_device_put(uvesafb_device);
platform_driver_unregister(&uvesafb_driver);
cn_del_callback(&uvesafb_cn_id);
return err;
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] smp:Fix use un-initialized cpumask_ipi

[Wang YanQing]

c7b798525b50256c8084215a139fa40b0114bfcc
[smp: Fix SMP function call empty cpu mask race]
use the un-initialized variable cpumask_ipi when
enable CONFIG_CPUMASK_OFFSTACK.

Signed-off-by: Wang YanQing 
---
 I am sorry for miss it, I just think it when I 
 was lying on the bed last night. :)

 kernel/smp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/smp.c b/kernel/smp.c
index 7c56aba..a38aa18 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -57,6 +57,9 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long action, 
void *hcpu)
if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
cpu_to_node(cpu)))
return notifier_from_errno(-ENOMEM);
+   if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
+   cpu_to_node(cpu)))
+   return notifier_from_errno(-ENOMEM);
break;
 
 #ifdef CONFIG_HOTPLUG_CPU
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH Resend] smp:Fix use un-initialized cpumask_ipi

[Wang YanQing]

c7b798525b50256c8084215a139fa40b0114bfcc
[smp: Fix SMP function call empty cpu mask race]
use the un-initialized variable cpumask_ipi when
enable CONFIG_CPUMASK_OFFSTACK.

Signed-off-by: Wang YanQing 
---
 I am sorry for miss it first.

 kernel/smp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/smp.c b/kernel/smp.c
index 7c56aba..af86f5e 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -57,6 +57,9 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long action, 
void *hcpu)
if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
cpu_to_node(cpu)))
return notifier_from_errno(-ENOMEM);
+   if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
+   cpu_to_node(cpu)))
+   return notifier_from_errno(-ENOMEM);
break;
 
 #ifdef CONFIG_HOTPLUG_CPU
@@ -66,6 +69,7 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long action, 
void *hcpu)
case CPU_DEAD:
case CPU_DEAD_FROZEN:
free_cpumask_var(cfd->cpumask);
+   free_cpumask_var(cfd->cpumask_ini);
break;
 #endif
};
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH Resend Resend] smp:Fix use un-initialized cpumask_ipi

[Wang YanQing]

c7b798525b50256c8084215a139fa40b0114bfcc
[smp: Fix SMP function call empty cpu mask race]
use the un-initialized variable cpumask_ipi when
enable CONFIG_CPUMASK_OFFSTACK.

Signed-off-by: Wang YanQing 
---
 I am sorry for miss it first.

 kernel/smp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/smp.c b/kernel/smp.c
index 7c56aba..af86f5e 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -57,6 +57,9 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long action, 
void *hcpu)
if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
cpu_to_node(cpu)))
return notifier_from_errno(-ENOMEM);
+   if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
+   cpu_to_node(cpu)))
+   return notifier_from_errno(-ENOMEM);
break;
 
 #ifdef CONFIG_HOTPLUG_CPU
@@ -66,6 +69,7 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long action, 
void *hcpu)
case CPU_DEAD:
case CPU_DEAD_FROZEN:
free_cpumask_var(cfd->cpumask);
+   free_cpumask_var(cfd->cpumask_ipi);
break;
 #endif
};
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]smp: Fix send func call IPI to empty cpu mask

[Wang YanQing]

On Mon, Jan 28, 2013 at 09:25:55AM +, Jan Beulich wrote:
> But the patch is obviously incomplete for the CPUMASK_OFFSTACK
> case, as the newly added cpumask_ipi member never gets
> its bit array allocated.
> 
> Jan
Yes, I have found it, and the patch is in lkml some hours ago.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]iommu: Include linux/err.h

[Wang YanQing]

The linux/iommu.h header uses ERR_PTR defined
in linux/err.h but doesn't include it.

Reviewed-by: Alex Williamson 
Signed-off-by: Wang YanQing 
---
 I send this twice to joerg.roe...@amd.com more than one
 month, but it had been ignored, I don't why.

 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..f4a49a6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -20,6 +20,7 @@
 #define __LINUX_IOMMU_H
 
 #include 
+#include 
 #include 
 
 #define IOMMU_READ (1)
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]gma500: remove unused drm_psb_no_fb

[Wang YanQing]

commit f9f23a77f07506a32d9dc1d925bf85c0e7507b66(gma500: remove no_fb bits)
remove all the drm_psb_no_fb relations code in gma500 except this line code,
so remove it also.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/gma500/psb_drv.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index a7fd6c4..6053b8a 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -876,7 +876,6 @@ extern const struct psb_ops cdv_chip_ops;
 #define PSB_D_MSVDX   (1 << 9)
 #define PSB_D_TOPAZ   (1 << 10)
 
-extern int drm_psb_no_fb;
 extern int drm_idle_check_interval;
 
 /*
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]scripts:kconfig:meconf: Add Save button to save config at anytime

[Wang YanQing]

mconf make me annoying I have to make menuconfig && exit to save
the config when I am tuning .config time by time, it is even
worse I have to search down to my desire submenu time by time.
So I add "Save" button to save our time. With "Save" button,
I can use CRTL-Z after save config, and then use "%" or fg to
resume menuconfig and go on tuning.

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/lxdialog/menubox.c |  7 +--
 scripts/kconfig/mconf.c| 32 +++-
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..a469f09 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -160,6 +160,7 @@ static void print_buttons(WINDOW * win, int height, int 
width, int selected)
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,9 +373,11 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 3 : (button > 3 ? 0 : button);
 
print_buttons(dialog, height, width, button);
+   if (button == 3)
+   button = 9;
wrefresh(menu);
break;
case ' ':
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index f584a28..beb5ebf9 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -521,6 +521,7 @@ static void conf(struct menu *menu)
struct symbol *sym;
struct menu *active_menu = NULL;
int res;
+   int yesno;
int s_scroll = 0;
 
while (1) {
@@ -615,6 +616,36 @@ static void conf(struct menu *menu)
case 8:
show_all_options = !show_all_options;
break;
+   case 9:
+   if (!conf_get_changed()) {
+   show_helptext(_("Notice"),
+   _("\n\n"
+   "Your configuration have not 
been changed."
+   "\n\n"));
+   break;
+   }
+
+   yesno = dialog_yesno(NULL,
+   _("Do you wish to save your "
+   "new configuration?\n"
+   " to continue."),
+   6, 60);
+   if (yesno == 0) {
+   if (conf_write(filename)) {
+   show_helptext(_("Notice"),
+   _("\n\n"
+   "Error while writing of 
the configuration.\n"
+   "Your configuration 
changes were NOT saved."
+   "\n\n"));
+   } else {
+   show_helptext(_("Notice"),
+   _("\n\n"
+   "Your configuration 
changes were saved."
+   "\n\n"));
+
+   }
+   }
+   break;
}
}
 }
@@ -879,4 +910,3 @@ int main(int ac, char **av)
 
return res;
 }
-
-- 
1.7.11.1.116.g8228a23

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] kconfig: fix trivial typos and update mconf documentation

[Wang YanQing]

On Thu, Oct 03, 2013 at 07:24:29PM +0200, Martin Walch wrote:
> From: Martin Walch 
> Date: Thu, 3 Oct 2013 17:28:14 +0200
> Subject: [PATCH v2 2/5] kconfig: fix trivial typos and update mconf 
> documentation
> 
> This fixes lots of typos in comments and strings.
> 
> It also updates the documentation strings in mconf to reflect the changes in
> the user interface from the two commits
> 
> 6364fd0cb1e4c7f72b974613e0cf5744ae4d2cb2
>   menuconfig: Add Save/Load buttons
> 1bdbac478a858d2aa73a6784c7c2e09de0f6d06b
>   menuconfig: Get rid of the top-level entries for "Load an Alternate/Save an 
> Alternate"
> 
> And it updates the layout of the example search result, i. e. moves down the
> "Defined at" and "Depends on" lines and adds a symbol state ([=n]) to the
> symbol in the "Selected by" line.
> 
> Furthermore, the help texts now should fit in 80 columns again when viewed
> in mconf.
> 
> Signed-off-by: Martin Walch 

Reviewed-by: Wang YanQing 

Thanks, I like it. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/5] kconfig: adjust warning message for conflicting types

[Wang YanQing]

On Thu, Oct 03, 2013 at 07:24:46PM +0200, Martin Walch wrote:
> From: Martin Walch 
> Date: Thu, 3 Oct 2013 18:32:02 +0200
> Subject: [PATCH v2 3/5] kconfig: adjust warning message for conflicting types
> 
> Each symbol must have exactly one type assigned. However, if a symbol happens
> to have two different types assigned at runtime, a warning is printed and the
> first type is preserved while the second type is being ignored.
> 
> The warning message says
> 
> type of  redefined from  to 
> 
> which may be misleading as it may create the impression that the second type
> replaces the first type.
> 
> This patch clarifies this by changing the warning to
> 
> ignoring type redefinition of  from  to 
> 
> Signed-off-by: Martin Walch 

Acked-by: Wang YanQing 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/5] kconfig: fix bug in search results string: use strlen(gstr->s), not gstr->len

[Wang YanQing]

On Thu, Oct 03, 2013 at 07:25:53PM +0200, Martin Walch wrote:
> From: Martin Walch 
> Date: Thu, 3 Oct 2013 18:35:16 +0200
> Subject: [PATCH v2 5/5] kconfig: fix bug in search results string: use 
> strlen(gstr->s), not gstr->len
> 
> The struct gstr has a capacity that may differ from the actual string length.
> 
> However, a string manipulation in the function search_conf made the assumption
> that it is the same, which led to messing up some search results, especially
> when the content of the gstr in use had not yet reached at least 63 chars.
> 
> Signed-off-by: Martin Walch 
Acked-by: Wang YanQing 

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]kconfig:mconf: avoid unneeded memcpy

[Wang YanQing]

In function update_text we assign jump key label
per page (1)-(9) cycled, and use three space char
as the header after k exceed JUMP_NB.

We don't need to call memcpy with header of three
space char, because it changes nothing, it just
copy what was there.

I don't think we need to clear old jump key label in
current implementation, I can't image out any case
which a search result could change its jump key label,
unless user search new string, but then we will re-assign
jump key label, and it will be fix after that.

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/mconf.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 2c39631..ff9d737 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -379,11 +379,8 @@ static void update_text(char *buf, size_t start, size_t 
end, void *_data)
data->keys[k] = key;
data->targets[k] = pos->target;
k++;
-   } else {
-   sprintf(header, "   ");
+   memcpy(buf + pos->offset, header, 
sizeof(header) - 1);
}
-
-   memcpy(buf + pos->offset, header, sizeof(header) - 1);
}
}
data->keys[k] = 0;
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]kconfig:mconf: avoid unneeded memcpy

[Wang YanQing]

On Sun, Oct 06, 2013 at 01:57:15AM +0800, Wang YanQing wrote:
> In function update_text we assign jump key label
> per page (1)-(9) cycled, and use three space char
> as the header after k exceed JUMP_NB.
> 
> We don't need to call memcpy with header of three
> space char, because it changes nothing, it just
> copy what was there.
> 
> I don't think we need to clear old jump key label in
> current implementation, I can't image out any case
> which a search result could change its jump key label,
> unless user search new string, but then we will re-assign
> jump key label, and it will be fix after that.
> 
> Signed-off-by: Wang YanQing 
> ---
>  scripts/kconfig/mconf.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index 2c39631..ff9d737 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
> @@ -379,11 +379,8 @@ static void update_text(char *buf, size_t start, size_t 
> end, void *_data)
>   data->keys[k] = key;
>   data->targets[k] = pos->target;
>   k++;
> - } else {
> - sprintf(header, "   ");
> + memcpy(buf + pos->offset, header, 
> sizeof(header) - 1);
>   }
> -
> - memcpy(buf + pos->offset, header, sizeof(header) - 1);
>   }
>   }
>   data->keys[k] = 0;
> -- 
> 1.7.12.4.dirty

Hi all, please ignore this patch.

I image out that we need to clear old jump label when we run 
make menuconfig in a x11 terminal with high resolution that
could show more than 9 item in one page.

Sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()

[Wang YanQing]

On Mon, Jul 08, 2013 at 04:50:24PM +0800, Chen Gang wrote:
> When failure occurs in hotplug_cfd(), need release related resources,
> or will cause memory leak.
> 
> Also beautify the related code.
> 
> Signed-off-by: Chen Gang 
> ---
>  kernel/smp.c |   13 +
>  1 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 02a885d..c264623 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -45,15 +45,20 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long 
> action, void *hcpu)
>   switch (action) {
>   case CPU_UP_PREPARE:
>   case CPU_UP_PREPARE_FROZEN:
> - if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
> - cpu_to_node(cpu)))
> + if (!zalloc_cpumask_var_node(&cfd->cpumask,
> + GFP_KERNEL, cpu_to_node(cpu)))
>   return notifier_from_errno(-ENOMEM);

What did you fixed here? code style?
You can drop this part.

> - if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
> - cpu_to_node(cpu)))
> +
> + if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi,
> + GFP_KERNEL, cpu_to_node(cpu))) {
> + free_cpumask_var(cfd->cpumask);
>   return notifier_from_errno(-ENOMEM);
> + }
> +
>   cfd->csd = alloc_percpu(struct call_single_data);
>   if (!cfd->csd) {
>   free_cpumask_var(cfd->cpumask);
> + free_cpumask_var(cfd->cpumask_ipi);
>   return notifier_from_errno(-ENOMEM);
>   }
>   break;

Yes, we need this fix.

If you resend the v2, I will give acked-by :)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()

[Wang YanQing]

On Tue, Jul 09, 2013 at 08:43:05AM +0800, Chen Gang wrote:
> When failure occurs in hotplug_cfd(), need release related resources,
> or will cause memory leak.
> 
> Signed-off-by: Chen Gang 
> ---
>  kernel/smp.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 02a885d..2a3a017 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -49,10 +49,13 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long 
> action, void *hcpu)
>   cpu_to_node(cpu)))
>   return notifier_from_errno(-ENOMEM);
>   if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
> - cpu_to_node(cpu)))
> + cpu_to_node(cpu))) {
> + free_cpumask_var(cfd->cpumask);
>   return notifier_from_errno(-ENOMEM);
> + }
>   cfd->csd = alloc_percpu(struct call_single_data);
>   if (!cfd->csd) {
> + free_cpumask_var(cfd->cpumask_ipi);
>   free_cpumask_var(cfd->cpumask);
>       return notifier_from_errno(-ENOMEM);
>   }
> -- 
> 1.7.7.6
Acked-by: Wang YanQing 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 01/25] Revert smp: Fix SMP function call empty cpu mask race

[Wang YanQing]

On Thu, Sep 12, 2013 at 12:07:05AM +0800, Jiang Liu wrote:
> From: Jiang Liu 
> 
> Commit f44310b98ddb7 "smp: Fix SMP function call empty cpu mask race"
> introduced field call_function_data->cpumask_ipi to resolve a race
> condition in smp_call_function_many().
> 
> Later commit 9a46ad6d6df3 "smp: make smp_call_function_many() use logic
> similar to smp_call_function_single()" fixed the same issue in another
> way when optimizing smp_call_function_many(), which then obsoletes
> changes introduced by commit f44310b98ddb7. So revert it.
> 
> Signed-off-by: Jiang Liu 
> Acked-by: Wang YanQing 
> Cc: Jiang Liu 
> ---
>  kernel/smp.c | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)
> 
> diff --git a/kernel/smp.c b/kernel/smp.c
> index fe9f773..a034712 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -23,7 +23,6 @@ enum {
>  struct call_function_data {
>   struct call_single_data __percpu *csd;
>   cpumask_var_t   cpumask;
> - cpumask_var_t   cpumask_ipi;
>  };
>  
>  static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
> @@ -47,9 +46,6 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long 
> action, void *hcpu)
>   if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
>   cpu_to_node(cpu)))
>   return notifier_from_errno(-ENOMEM);
> - if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
> - cpu_to_node(cpu)))
> - return notifier_from_errno(-ENOMEM);
>   cfd->csd = alloc_percpu(struct call_single_data);
>   if (!cfd->csd) {
>   free_cpumask_var(cfd->cpumask);
> @@ -64,7 +60,6 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long 
> action, void *hcpu)
>   case CPU_DEAD:
>   case CPU_DEAD_FROZEN:
>   free_cpumask_var(cfd->cpumask);
> - free_cpumask_var(cfd->cpumask_ipi);
>   free_percpu(cfd->csd);
>   break;
>  #endif
> @@ -255,9 +250,9 @@ int smp_call_function_single(int cpu, smp_call_func_t 
> func, void *info,
>   csd = &__get_cpu_var(csd_data);
>  
>   csd_lock(csd);
> -
>   csd->func = func;
>   csd->info = info;
> +
>   generic_exec_single(cpu, csd, wait);
>   } else {
>   err = -ENXIO;   /* CPU not online */
> @@ -410,13 +405,6 @@ void smp_call_function_many(const struct cpumask *mask,
>   if (unlikely(!cpumask_weight(cfd->cpumask)))
>   return;
>  
> - /*
> -  * After we put an entry into the list, cfd->cpumask may be cleared
> -  * again when another CPU sends another IPI for a SMP function call, so
> -  * cfd->cpumask will be zero.
> -  */
> - cpumask_copy(cfd->cpumask_ipi, cfd->cpumask);
> -
>   for_each_cpu(cpu, cfd->cpumask) {
>   struct call_single_data *csd = per_cpu_ptr(cfd->csd, cpu);
>   struct call_single_queue *dst =
> @@ -433,7 +421,7 @@ void smp_call_function_many(const struct cpumask *mask,
>   }
>  
>   /* Send a message to all CPUs in the map */
> - arch_send_call_function_ipi_mask(cfd->cpumask_ipi);
> + arch_send_call_function_ipi_mask(cfd->cpumask);
>  
>   if (wait) {
>   for_each_cpu(cpu, cfd->cpumask) {
> -- 
> 1.8.1.2
Hi Liu and all

Commit 60c323699bb308404dcb60e8808531e02651578a 
(kernel/smp.c: free related resources when failure occurs in hotplug_cfd())
is a fix patch for commit you revert, and it had been merged into mainline.

So could you ajust your patch to revert it together? I don't think we need
a separate patch to revert 60c323699bb308404dcb60e8808531e02651578a, because
your patch haven't be merged.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 01/25] Revert smp: Fix SMP function call empty cpu mask race

[Wang YanQing]

On Sat, Sep 14, 2013 at 12:41:36PM +0800, Wang YanQing wrote:
> On Thu, Sep 12, 2013 at 12:07:05AM +0800, Jiang Liu wrote:
> > From: Jiang Liu 
> > 
> > Commit f44310b98ddb7 "smp: Fix SMP function call empty cpu mask race"
> > introduced field call_function_data->cpumask_ipi to resolve a race
> > condition in smp_call_function_many().
> > 
> > Later commit 9a46ad6d6df3 "smp: make smp_call_function_many() use logic
> > similar to smp_call_function_single()" fixed the same issue in another
> > way when optimizing smp_call_function_many(), which then obsoletes
> > changes introduced by commit f44310b98ddb7. So revert it.
> > 
> > Signed-off-by: Jiang Liu 
> > Acked-by: Wang YanQing 
> > Cc: Jiang Liu 
> > ---
> >  kernel/smp.c | 16 ++--
> >  1 file changed, 2 insertions(+), 14 deletions(-)
> > 
> > diff --git a/kernel/smp.c b/kernel/smp.c
> > index fe9f773..a034712 100644
> > --- a/kernel/smp.c
> > +++ b/kernel/smp.c
> > @@ -23,7 +23,6 @@ enum {
> >  struct call_function_data {
> > struct call_single_data __percpu *csd;
> > cpumask_var_t   cpumask;
> > -   cpumask_var_t   cpumask_ipi;
> >  };
> >  
> >  static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
> > @@ -47,9 +46,6 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long 
> > action, void *hcpu)
> > if (!zalloc_cpumask_var_node(&cfd->cpumask, GFP_KERNEL,
> > cpu_to_node(cpu)))
> > return notifier_from_errno(-ENOMEM);
> > -   if (!zalloc_cpumask_var_node(&cfd->cpumask_ipi, GFP_KERNEL,
> > -   cpu_to_node(cpu)))
> > -   return notifier_from_errno(-ENOMEM);
> > cfd->csd = alloc_percpu(struct call_single_data);
> > if (!cfd->csd) {
> > free_cpumask_var(cfd->cpumask);
> > @@ -64,7 +60,6 @@ hotplug_cfd(struct notifier_block *nfb, unsigned long 
> > action, void *hcpu)
> > case CPU_DEAD:
> > case CPU_DEAD_FROZEN:
> > free_cpumask_var(cfd->cpumask);
> > -   free_cpumask_var(cfd->cpumask_ipi);
> > free_percpu(cfd->csd);
> > break;
> >  #endif
> > @@ -255,9 +250,9 @@ int smp_call_function_single(int cpu, smp_call_func_t 
> > func, void *info,
> > csd = &__get_cpu_var(csd_data);
> >  
> > csd_lock(csd);
> > -
> > csd->func = func;
> > csd->info = info;
> > +
> > generic_exec_single(cpu, csd, wait);
> > } else {
> > err = -ENXIO;   /* CPU not online */
> > @@ -410,13 +405,6 @@ void smp_call_function_many(const struct cpumask *mask,
> > if (unlikely(!cpumask_weight(cfd->cpumask)))
> > return;
> >  
> > -   /*
> > -* After we put an entry into the list, cfd->cpumask may be cleared
> > -* again when another CPU sends another IPI for a SMP function call, so
> > -* cfd->cpumask will be zero.
> > -*/
> > -   cpumask_copy(cfd->cpumask_ipi, cfd->cpumask);
> > -
> > for_each_cpu(cpu, cfd->cpumask) {
> > struct call_single_data *csd = per_cpu_ptr(cfd->csd, cpu);
> > struct call_single_queue *dst =
> > @@ -433,7 +421,7 @@ void smp_call_function_many(const struct cpumask *mask,
> > }
> >  
> > /* Send a message to all CPUs in the map */
> > -   arch_send_call_function_ipi_mask(cfd->cpumask_ipi);
> > +   arch_send_call_function_ipi_mask(cfd->cpumask);
> >  
> > if (wait) {
> > for_each_cpu(cpu, cfd->cpumask) {
> > -- 
> > 1.8.1.2
> Hi Liu and all
> 
> Commit 60c323699bb308404dcb60e8808531e02651578a 
> (kernel/smp.c: free related resources when failure occurs in hotplug_cfd())
> is a fix patch for commit you revert, and it had been merged into mainline.
> 
> So could you ajust your patch to revert it together? I don't think we need
> a separate patch to revert 60c323699bb308404dcb60e8808531e02651578a, because
> your patch haven't be merged.
> 
> Thanks.

Add Cc:gang.c...@asianux.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] trace: show more and exactly help information about snapshot

[Wang YanQing]

Actually, they both are correct:

default:
if (tr->allocated_snapshot) {
if (iter->cpu_file == RING_BUFFER_ALL_CPUS)
tracing_reset_online_cpus(&tr->max_buffer);
else
tracing_reset(&tr->max_buffer,  iter->cpu_file);
}
break;
}

It does nothing if it isn't allocated.

Perhaps we need it to say "(but does not allocate or free)"

-- Steve

Signed-off-by: Wang YanQing 
---
 I think "Clears and frees" are reasonable, and
 "Clears and allocates are not so reasonable, so
 we don't need to say not allocate. But it is help 
 information, so make it more clearer is also acceptable. :)
 
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..d5f7c4d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2760,7 +2760,7 @@ static void show_snapshot_main_help(struct seq_file *m)
seq_printf(m, "# echo 0 > snapshot : Clears and frees snapshot 
buffer\n");
seq_printf(m, "# echo 1 > snapshot : Allocates snapshot buffer, if not 
already allocated.\n");
seq_printf(m, "#  Takes a snapshot of the main 
buffer.\n");
-   seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does 
not allocate)\n");
+   seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does 
not allocate or free)\n");
seq_printf(m, "#  (Doesn't have to be '2' works 
with any number that\n");
seq_printf(m, "#   is not a '0' or '1')\n");
 }
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 1/3] SMP: kill redundant call_function_data->cpumask_ipi field

[Wang YanQing]

On Sun, Sep 08, 2013 at 11:22:23PM +0800, Jiang Liu wrote:
> From: Jiang Liu 
> 
> Commit f44310b98ddb7 "smp: Fix SMP function call empty cpu mask race"
> introduced field call_function_data->cpumask_ipi to resolve a race
> condition in smp_call_function_many().
> 
> Later commit 9a46ad6d6df3 "smp: make smp_call_function_many() use logic
> similar to smp_call_function_single()" fixed the same issue in another
> way when optimizing smp_call_function_many(), which then obsoletes
> changes introduced by commit f44310b98ddb7. So revert it.
> 

Yes, you are right, after commit 9a46ad6d6df3, we can revert f44310b98ddb7.
Maybe use "Revert smp: Fix SMP function call empty cpu mask race" is a better
subject.

> We may also keep call_function_data->cpumask_ipi field and use it to
> optimize smp_call_function_many() as below:
> diff --git a/kernel/smp.c b/kernel/smp.c
> index fe9f773..dd852fb 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -428,6 +428,8 @@ void smp_call_function_many(const struct cpumask *mask,
> csd->info = info;
> 
> raw_spin_lock_irqsave(&dst->lock, flags);
> +   if (list_empty(&dst->list))
> +   cpumask_clear_cpu(cpu, cfd->cpumask_ipi);
> list_add_tail(&csd->list, &dst->list);
> raw_spin_unlock_irqrestore(&dst->lock, flags);
> }
> 

Your optimization don't need to keep cpumask_ipi, just clear cfd->cpumask,
and test whether cfd->cpumask is empty after "for_each_cpu(cpu, cfd->cpumask)".


Acked-by: Wang YanQing 

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]trace: fix wrong help information about snapshot

[Wang YanQing]

Cat snapshot give me:
" tracer: nop

 * Snapshot is freed *

 Snapshot commands:
 echo 0 > snapshot : Clears and frees snapshot buffer
 echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
  Takes a snapshot of the main buffer.
 echo 2 > snapshot : Clears snapshot buffer (but does not allocate)
  (Doesn't have to be '2' works with any number that
   is not a '0' or '1')"

But after read the code, I found the right information about "echo 2 > snapshot"
should looks like below:

" echo 2 > snapshot : Clears snapshot buffer (but does not free)
  (Doesn't have to be '2' works with any number that
   is not a '0' or '1')"

Signed-off-by: Wang YanQing 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..d0da660 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2760,7 +2760,7 @@ static void show_snapshot_main_help(struct seq_file *m)
seq_printf(m, "# echo 0 > snapshot : Clears and frees snapshot 
buffer\n");
seq_printf(m, "# echo 1 > snapshot : Allocates snapshot buffer, if not 
already allocated.\n");
seq_printf(m, "#  Takes a snapshot of the main 
buffer.\n");
-   seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does 
not allocate)\n");
+   seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does 
not free)\n");
seq_printf(m, "#  (Doesn't have to be '2' works 
with any number that\n");
seq_printf(m, "#   is not a '0' or '1')\n");
 }
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2]mconf: Add Save button

[Wang YanQing]

mconf make me annoying I have to make menuconfig && exit to
save the config when I am tuning .config time by time, it
is even worse I have to search down to my desire submenu
time by time. So I add "Save" button to save our time. With
"Save" button, I can use CRTL-Z after save config, and then
use "%" or fg to resume menuconfig and go on tuning.

Changes v1-v2:
* Rewrite the most code to make it more correct

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/lxdialog/menubox.c | 17 
 scripts/kconfig/mconf.c| 40 --
 2 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..f71f112 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -160,6 +160,7 @@ static void print_buttons(WINDOW * win, int height, int 
width, int selected)
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +373,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 3 : (button > 3 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +400,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
-   case 'n':
return 4;
-   case 'm':
+   case 'n':
return 5;
-   case ' ':
+   case 'm':
return 6;
-   case '/':
+   case ' ':
return 7;
-   case 'z':
+   case '/':
return 8;
+   case 'z':
+   return 9;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index f584a28..100b52a 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -521,6 +521,7 @@ static void conf(struct menu *menu)
struct symbol *sym;
struct menu *active_menu = NULL;
int res;
+   int yesno;
int s_scroll = 0;
 
while (1) {
@@ -588,6 +589,25 @@ static void conf(struct menu *menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   if (!conf_get_changed()) {
+   break;
+   }
+
+   yesno = dialog_yesno(NULL,
+   _("Do you wish to save your "
+   "new configuration?\n"
+   " to continue."),
+   6, 60);
+   if (yesno == 0) {
+   if (conf_write(filename)) {
+   show_textbox(NULL,
+   _("Error while writing of the 
configuration.\n"
+   "Your configuration 
changes were NOT saved."),
+   6,60);
+   }
+   }
+   break;
+   case 4:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -595,24 +615,24 @@ static void conf(struct menu *menu)
  

[PATCH v3]mconf: Add Save button

[Wang YanQing]

mconf make me annoying I have to make menuconfig && exit to save
the config when I am tuning .config time by time, it is even
worse I have to search down to my desire submenu time by time.
So I add "Save" button to save our time. With "Save" button,
I can use CRTL-Z after save config, and then use "%" or fg to
resume menuconfig and go on tuning.

v2: Rewrite the most code to make it more correct
v3: Fix the behavior of conf_message_callback when exit.

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/lxdialog/menubox.c | 17 +++---
 scripts/kconfig/mconf.c| 47 --
 2 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..f71f112 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -160,6 +160,7 @@ static void print_buttons(WINDOW * win, int height, int 
width, int selected)
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +373,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 3 : (button > 3 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +400,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
-   case 'n':
return 4;
-   case 'm':
+   case 'n':
return 5;
-   case ' ':
+   case 'm':
return 6;
-   case '/':
+   case ' ':
return 7;
-   case 'z':
+   case '/':
return 8;
+   case 'z':
+   return 9;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index f584a28..72c4ae6 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -274,6 +274,7 @@ static int child_count;
 static int single_menu_mode;
 static int show_all_options;
 static int saved_x, saved_y;
+static int save_and_exit;
 
 static void conf(struct menu *menu);
 static void conf_choice(struct menu *menu);
@@ -521,6 +522,7 @@ static void conf(struct menu *menu)
struct symbol *sym;
struct menu *active_menu = NULL;
int res;
+   int yesno;
int s_scroll = 0;
 
while (1) {
@@ -588,6 +590,25 @@ static void conf(struct menu *menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   if (!conf_get_changed()) {
+   break;
+   }
+
+   yesno = dialog_yesno(NULL,
+   _("Do you wish to save your "
+   "new configuration?\n"
+   " to continue."),
+   6, 60);
+   if (yesno == 0) {
+   if (conf_write(filename)) {
+   show_textbox(NULL,
+   _("Error while writing of the 
configuration.\n"
+   "Your configuration 
changes were NOT saved."),
+   6,60);
+   }
+   }

Re: [PATCH v3]mconf: Add Save button

[Wang YanQing]

On Mon, Oct 08, 2012 at 08:03:40AM +0200, Borislav Petkov wrote:
> Well, there are a bunch of patches from Benjamin Poirier adding the
> possibility to jump to search results and you could use them to go to
> your desired submenu.
First there are two ways to save the .config in menuconfig
1:Exit menuconfig with choice the "Yes" to save .config
2:go to top menu and use the "Save an alternate Configuration File" to save 
.config

No matter which way you choice, it is slow and annoying to find the origin
submenu where you have interest.The bunch of patches from Benjamin make it
a little annoying, but not ignore it.Just image the situation that you have 
to exit menuconfig then "make menuconfig" and search down the submenu time 
by time, it is really annoying.

> > So I add "Save" button to save our time. With "Save" button, I can use
> > CRTL-Z after save config, and then use "%" or fg to resume menuconfig
> > and go on tuning.
> 
> Ok, IIUC, when you put menuconfig in the background, edit .config by
> hand in the shell and then do 'fg', you need to reload the edited
> .config back otherwise you lose your changes you just did by hand.
> 
> And generally speaking, why exactly do you need to edit .config by hand,
> and, at same time, do it over menuconfig? IMO, with Benjamin's patches,
> you don't need to do that anymore, right?
> 
> Thanks.
It is not the first time to make me trouble with representation by my poor 
English,
sorry for that.I hope the below words show the really meaning that I want to 
give you.

With one terminal, I can do:
1: make menuconfig
2: ajust and use "Save" button to save .config
3: use CRTL-Z(konsole) to "menuconfig" run in background
3: make && test kernel
4: fg or "%1" to resume the menuconfig

With two terminal, I can do:
in first terminal
1: make menuconfig 
2: ajust and use "Save" button to save .config

in second terminal
3: make && test kernel

go back the first terminal and go on tuning.

Now, you can see what the "Save" button can do,
it make there is no "exit menuconfig" or go to
the top menu when you want to save .config in 
menuconfig

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3]mconf: Add Save button

[Wang YanQing]

On Mon, Oct 08, 2012 at 10:28:32AM +0200, Borislav Petkov wrote:
> On Mon, Oct 08, 2012 at 03:22:49PM +0800, Wang YanQing wrote:
> > With one terminal, I can do:
> > 1: make menuconfig
> > 2: ajust and use "Save" button to save .config
> > 3: use CRTL-Z(konsole) to "menuconfig" run in background
> > 3: make && test kernel
> > 4: fg or "%1" to resume the menuconfig
> 
> I understand all that, but why do you think your usecase should be
> in the kernel? I still fail to see its relevance for the majority of
> people.
No, I don't think it is only my usecase. Use fg,CRTL-Z is very normal
in terminal or in vt(console), without save button you have to exit 
menuconfig every time you want to save .config.

By the way,just a quick test, qconfig, xconfig, nconfig all have the
Save button, why do them exist if we follow your opinion?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

I get a board with 8168e-vl(10ec:8168 with RTL_GIGA_MAC_VER_34),
everything looks well first, I can use ifconfig to set ip, netmask,
etc. And the rx/tx statistics show by ifconfig looks good when I
ping another host or ping it from another host. But it don't work,
I can't get ICMP REPLAY from both sides, although the RX/TX statistics
seem good.

After add some debug code, I found this NIC only accept ethernet
broadcast package, it can't filter out the package send to its
MAC address, but it works good for sending.So ifconfig show the
RX/TX status means it can receive ARP package.(It don't know its
MAC address, so below)

I have try the driver provided by realtek's website, it have the
same problem at the first time. BUT IT WORK AFTER I REBOOT with
CRTL-ALT-DEL, the reason is that realtek's driver call rtl8168_rar_set
in the .shutdown function register with pci_register_driver. Yes,
the really reason to make it work is rtl8689_rar_set, this function
set extended GigaMAC registers, so after reboot without lost the power,
NIC keep the status before reboot.

I haven't see any code to set GigaMAC registers in kernel when boot,
so I guess BIOS or NIC's circuit make it, but of course one miss
the extended GigaMAC registers  in this problem. The probe code can
get MAC address right, so MAC{0,4} must had been setted, but some
guys forget the extended GigaMAC registers.

This patch fix it.

[ I don't known whether others' realtek's NIC with extended GigaMAC
reigisters have the same problem, I meet it in 8168e-vl with
RTL_GIGA_MAC_VER_34, so I make this patch just for it.]

Changes:
V1-V2:
I follow Francois Romieu 's below opinion to make this patch oneline:

I'd rather see the GigaMAC registers written through a call to
rtl_rar_set when the mac address is read in rtl_init_one instead of
duplicating most of rtl_rar_set in a quite different place.

V2-V3:
1:Add conditon code to around this fix, because it make no sense for
most NIC
2:Add comment in code

Signed-off-by: Wang YanQing 
---
 drivers/net/ethernet/realtek/r8169.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 927aa33..5d98296 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6903,6 +6903,14 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
dev->dev_addr[i] = RTL_R8(MAC0 + i);
memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
 
+   /*
+*This is a fix for BIOS forget to set
+*extend GigaMAC registers
+*Wang YanQing 12/1/2012
+*/
+   if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+   rtl_rar_set(tp, dev->dev_addr);
+   }
SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
 
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

On Fri, Nov 30, 2012 at 06:00:02PM +0800, Wang YanQing wrote:
> I found the mainline's r8169 works the same as realtek's driver,
> the first time don't work, but it works after reboot, the reason
> is the pci driver's shutdown don't call rtl_rar_set in 3.0 stable
> tree but the mainline does.
Sorry, I make a mistake here, the boths pci driver's shutdown call 
rtl_rar_set, but 3.0 stable tree don't include commit 
c28aa38567101bad4e020f4392df41d0bf6c165c(r8169 : MAC address change fix for the 
8168e-vl)

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4]menuconfig: Add Save button

[Wang YanQing]

If menuconfig have a Save button like alternative
.config editors, xconfig, nconfig, etc.We will have
a obvious benefit when use menuconfig just like
when we use others, we can save our .config quickly
and conveniently.

This patch add the Save button for menuconfig.

V1-V2: Rewrite the most code to make it more correct
V2-V3: Fix the behavior of conf_message_callback when exit.
V3-V4:
1: Move Buttons a little left to make them look like symmetrical.
2: Exchange the position between Save button and Exit button.
3: Use conf_save instead of conf_write to make we can save
an alternate configuration file with Save button.

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/lxdialog/menubox.c | 21 +-
 scripts/kconfig/mconf.c| 45 ++
 2 files changed, 47 insertions(+), 19 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..b445bda 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -154,12 +154,13 @@ static void print_arrows(WINDOW * win, int item_no, int 
scroll, int y, int x,
  */
 static void print_buttons(WINDOW * win, int height, int width, int selected)
 {
-   int x = width / 2 - 16;
+   int x = width / 2 - 20;
int y = height - 2;
 
print_button(win, gettext("Select"), y, x, selected == 0);
-   print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
+   print_button(win, gettext(" Save "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Exit "), y, x + 36, selected == 3);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +373,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 3 : (button > 3 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +400,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
-   case 'n':
return 4;
-   case 'm':
+   case 'n':
return 5;
-   case ' ':
+   case 'm':
return 6;
-   case '/':
+   case ' ':
return 7;
-   case 'z':
+   case '/':
return 8;
+   case 'z':
+   return 9;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 53975cf..a8a1947 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -280,6 +280,7 @@ static struct menu *current_menu;
 static int child_count;
 static int single_menu_mode;
 static int show_all_options;
+static int save_and_exit;
 
 static void conf(struct menu *menu, struct menu *active_menu);
 static void conf_choice(struct menu *menu);
@@ -584,6 +585,7 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
const char *prompt = menu_get_prompt(menu);
struct symbol *sym;
int res;
+   int yesno;
int s_scroll = 0;
 
while (1) {
@@ -604,7 +606,7 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
res = dialog_menu(prompt ? _(prompt) : _("Main Menu"),
  _(menu_instructions),
  active_menu, &s_scroll);
-   if (res == 1 || res == KEY_ESC || res == -ERRDISPLAYTOOSMALL)
+   if (res == 3 || res == KEY_ESC || res == -ERRDISPLAYTOOSMALL)
break;
if (!item_activate_selected())
continue;
@@ -644,13 +646,27 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
 

Re: [PATCH v3]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

[Wang YanQing]

On Sat, Dec 01, 2012 at 12:44:01PM +0100, Francois Romieu wrote:
> Wang YanQing  :
> > +   /*
> > +*This is a fix for BIOS forget to set
> > +*extend GigaMAC registers
> > +*Wang YanQing 12/1/2012
> > +*/
> 
> This part will go into the changelog.
I think brevity comment in code is good for
code's readableness. We read out the MAC{0,4},
and write them back in next line to call rtl_rar_set,
it don't have obvious sense for new readers, so I think 
the brevity comment is good. Could you consider remaining
the comment except the no sense line "Wang YanQing 12/1/2012"?

> 
> > +   if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
> > +   rtl_rar_set(tp, dev->dev_addr);
> > +   }
> 
> rtl_rar_set already includes a RTL_GIGA_MAC_VER_34 test and non-8168evl
> devices are already able to stand an extra MAC{0, 4} write. I'll check
> it does not hurt on different 81xx devices and submit an update.
I add the test code to ignore the an extra MAC{0,4} write for non-8168evl
devices, and if you think it is not a issue, then I agree with you to remove 
the test code.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lxdialog:inputbox: Fix can't change selected button with Left/Right when input box selected

[Wang YanQing]

inputbox code don't support use Left/Right to change input
position in the input box, so it use continue to skip them
when input key is Left/Right, but use break for Up/Down, so
we can change selected button with Up/Down but we can't do it
with Left/Right key when input box selected.

This patch fix it.

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/lxdialog/inputbox.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/kconfig/lxdialog/inputbox.c 
b/scripts/kconfig/lxdialog/inputbox.c
index dd8e587..7841f46 100644
--- a/scripts/kconfig/lxdialog/inputbox.c
+++ b/scripts/kconfig/lxdialog/inputbox.c
@@ -120,11 +120,9 @@ do_resize:
case TAB:
case KEY_UP:
case KEY_DOWN:
-   break;
case KEY_LEFT:
-   continue;
case KEY_RIGHT:
-   continue;
+   break;
case KEY_BACKSPACE:
case 127:
if (input_x || scroll) {
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lxdialog:inputbox: Fix can't change selected button with Left/Right when input box selected

[Wang YanQing]

On Sun, Dec 02, 2012 at 06:32:43PM +0100, Yann E. MORIN wrote:
> Wang, All,
> 
> On Sunday 02 December 2012 Wang YanQing wrote:
> > inputbox code don't support use Left/Right to change input
> > position in the input box, so it use continue to skip them
> > when input key is Left/Right, but use break for Up/Down, so
> > we can change selected button with Up/Down but we can't do it
> > with Left/Right key when input box selected.
> > This patch fix it.
> 
> Although I do understand the motivation behind your change, may I suggest
> that left/right are used to navigate *inside* the input field, so it is
> possible to modify the text in place?
Hi Yann,All,
I understand what you say, and I also want inputbox support
changing input position with Left/Right. But this patch is accepted 
before somebody make it come true, right?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4]menuconfig: Add Save button

[Wang YanQing]

Hi Yann, All,

On Sun, Dec 02, 2012 at 06:52:50PM +0100, Yann E. MORIN wrote:
> To make the behavior consistent, may I suggest that you push the
> concept even a bit further:
>   - add a "Load" *and* a "Save" buttons
>   - get rid of the top-level "Load an Alternate Configuration File"
> and "Save an Alternate Configuration File" entries
> 
> For the "Save" and "Load" buttons, please mimick how the nconf frontend
> behaves: prompt for the file to save to/load from, and prefill it with
> the last filename that was entered (".config" per default).
> 
> Of course, two patches for that: one for the "Save/Load" buttons, one
> to get rid of the top-level entries afterward.
Thanks, very good suggestion, I will jump in.

> Note: I do not state that your use-case is valid or not. That's your
> call how you configure and test your kernel. However, I think that
> having a consistent behavior across the frontends is a very nice goal
> to pursue.
I understand, I make a mistake in the comment in previous Email.

> See other comments in-lined, below.
> 
> > V1-V2: Rewrite the most code to make it more correct
> > V2-V3: Fix the behavior of conf_message_callback when exit.
> > V3-V4:
> > 1: Move Buttons a little left to make them look like symmetrical.
> > 2: Exchange the position between Save button and Exit button.
> > 3: Use conf_save instead of conf_write to make we can save
> > an alternate configuration file with Save button.
> > 
> > Signed-off-by: Wang YanQing 
> > ---
> >  scripts/kconfig/lxdialog/menubox.c | 21 +-
> >  scripts/kconfig/mconf.c| 45 
> > ++
> >  2 files changed, 47 insertions(+), 19 deletions(-)
> > 
> > diff --git a/scripts/kconfig/lxdialog/menubox.c 
> > b/scripts/kconfig/lxdialog/menubox.c
> > index 1d60473..b445bda 100644
> > --- a/scripts/kconfig/lxdialog/menubox.c
> > +++ b/scripts/kconfig/lxdialog/menubox.c
> > @@ -26,7 +26,7 @@
> >   *
> >   **)  A bugfix for the Page-Down problem
> >   *
> > - **)  Formerly when I used Page Down and Page Up, the cursor would be 
> > set 
> > + **)  Formerly when I used Page Down and Page Up, the cursor would be 
> > set
> 
> Space-damage. Don't send trailing-space fixes, or at least add a quick
> note for it at the end of the commit log (eg.: "remove trailing space
> while at it").
Ok, it is right.

Thanks Yann E. MORIN, and All

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2 v2] menuconfig: Add Save/Load buttons

[Wang YanQing]

If menuconfig have Save/Load button like alternative
.config editors, xconfig, nconfig, etc.We will have
a obvious benefit when use menuconfig just like
when we use others, we can Save/Load our .config quickly
and conveniently.

This patch add the Save/Load button for menuconfig.

[remove trailing space while at it for below line:
"*)  Formerly when I used Page Down and Page Up, the cursor would be set"
]

Changes:
V1-V2:
1:use PATH_MAX instead of hard code suggested by Yann E. MORIN
2:drop the spurious empty-line removal suggested by Yann E. MORIN

Signed-off-by: Wang YanQing 
---
 scripts/kconfig/lxdialog/menubox.c | 20 +++-
 scripts/kconfig/mconf.c| 30 +-
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..8b534d5 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -154,12 +154,14 @@ static void print_arrows(WINDOW * win, int item_no, int 
scroll, int y, int x,
  */
 static void print_buttons(WINDOW * win, int height, int width, int selected)
 {
-   int x = width / 2 - 16;
+   int x = width / 2 - 26;
int y = height - 2;
 
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
+   print_button(win, gettext(" Load "), y, x + 48, selected == 4);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +374,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 4 : (button > 4 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +401,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
+   return 5;
case 'n':
-   return 4;
+   return 6;
case 'm':
-   return 5;
+   return 7;
case ' ':
-   return 6;
+   return 8;
case '/':
-   return 7;
+   return 9;
case 'z':
-   return 8;
+   return 10;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 53975cf..9fb90f0 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -280,6 +280,7 @@ static struct menu *current_menu;
 static int child_count;
 static int single_menu_mode;
 static int show_all_options;
+static int save_and_exit;
 
 static void conf(struct menu *menu, struct menu *active_menu);
 static void conf_choice(struct menu *menu);
@@ -651,6 +652,12 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   conf_save();
+   break;
+   case 4:
+   conf_load();
+   break;
+   case 5:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -658,24 +665,24 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_textbox(NULL, setmod_text, 6, 74);
}
break;
-   case 4:
+   case 6:
if (item_is_tag('t'))
sym_set_tristate_value(sym, no);
 

[PATCH 1/2 v3] menuconfig: Add Save/Load buttons

[Wang YanQing]

If menuconfig have Save/Load button like alternative
.config editors, xconfig, nconfig, etc.We will have
a obvious benefit when use menuconfig just like
when we use others, we can Save/Load our .config quickly
and conveniently.

This patch add the Save/Load button for menuconfig.

[remove trailing space while at it for below line:
"*)  Formerly when I used Page Down and Page Up, the cursor would be set"
]

Changes:
V1-V2:
1:use PATH_MAX instead of hard code suggested by Yann E. MORIN
2:drop the spurious empty-line removal suggested by Yann E. MORIN
V2-V3:
1:ajust buttons position well centered reported by Yann E. MORIN

Signed-off-by: Wang YanQing 
---
 Hi Yann E. MORIN, can you give your Rev'ed-by and Tested-by to his patch,
 Thanks very much for your help, I just don't know how to computer out the
 right position :)

 The Changes appear in commit log is ok, I found I am not the first guy
 do it, it maybe useful in some case :)

 scripts/kconfig/lxdialog/menubox.c | 20 +++-
 scripts/kconfig/mconf.c| 30 +-
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..8b534d5 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -154,12 +154,14 @@ static void print_arrows(WINDOW * win, int item_no, int 
scroll, int y, int x,
  */
 static void print_buttons(WINDOW * win, int height, int width, int selected)
 {
-   int x = width / 2 - 16;
+   int x = width / 2 - 26;
int y = height - 2;
 
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
+   print_button(win, gettext(" Load "), y, x + 48, selected == 4);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +374,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 4 : (button > 4 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +401,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
+   return 5;
case 'n':
-   return 4;
+   return 6;
case 'm':
-   return 5;
+   return 7;
case ' ':
-   return 6;
+   return 8;
case '/':
-   return 7;
+   return 9;
case 'z':
-   return 8;
+   return 10;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 53975cf..9fb90f0 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -280,6 +280,7 @@ static struct menu *current_menu;
 static int child_count;
 static int single_menu_mode;
 static int show_all_options;
+static int save_and_exit;
 
 static void conf(struct menu *menu, struct menu *active_menu);
 static void conf_choice(struct menu *menu);
@@ -651,6 +652,12 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   conf_save();
+   break;
+   case 4:
+   conf_load();
+   break;
+   case 5:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -658,24 +665,24 @@ static void conf(st

[PATCH RESEND 1/2 v3] menuconfig: Add Save/Load buttons

[Wang YanQing]

If menuconfig have Save/Load button like alternative
.config editors, xconfig, nconfig, etc.We will have
a obvious benefit when use menuconfig just like
when we use others, we can Save/Load our .config quickly
and conveniently.

This patch add the Save/Load button for menuconfig.

[remove trailing space while at it for below line:
"*)  Formerly when I used Page Down and Page Up, the cursor would be set"
]

Changes:
V1-V2:
1:use PATH_MAX instead of hard code suggested by Yann E. MORIN
2:drop the spurious empty-line removal suggested by Yann E. MORIN
V2-V3:
1:ajust buttons position well centered reported by Yann E. MORIN

Signed-off-by: Wang YanQing 
---
 Hi Yann E. MORIN, can you give your Rev'ed-by and Tested-by to this patch,
 Thanks very much for your help, I just don't know how to computer out the
 right position :)

 The Changes appear in commit log is ok, I found I am not the first guy
 do it, it maybe useful in some case :)

 scripts/kconfig/lxdialog/menubox.c | 20 +++-
 scripts/kconfig/mconf.c| 30 +-
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..8b534d5 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -154,12 +154,14 @@ static void print_arrows(WINDOW * win, int item_no, int 
scroll, int y, int x,
  */
 static void print_buttons(WINDOW * win, int height, int width, int selected)
 {
-   int x = width / 2 - 16;
+   int x = width / 2 - 28;
int y = height - 2;
 
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
+   print_button(win, gettext(" Load "), y, x + 48, selected == 4);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +374,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 4 : (button > 4 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +401,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
+   return 5;
case 'n':
-   return 4;
+   return 6;
case 'm':
-   return 5;
+   return 7;
case ' ':
-   return 6;
+   return 8;
case '/':
-   return 7;
+   return 9;
case 'z':
-   return 8;
+   return 10;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 53975cf..9fb90f0 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -280,6 +280,7 @@ static struct menu *current_menu;
 static int child_count;
 static int single_menu_mode;
 static int show_all_options;
+static int save_and_exit;
 
 static void conf(struct menu *menu, struct menu *active_menu);
 static void conf_choice(struct menu *menu);
@@ -651,6 +652,12 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   conf_save();
+   break;
+   case 4:
+   conf_load();
+   break;
+   case 5:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -658,24 +665,24 @@ static void conf(st

Re: [PATCH] kconfig:lxdialog: remove duplicate code

[Wang YanQing]

On Mon, Dec 17, 2012 at 07:19:07PM +0100, Yann E. MORIN wrote:
> Wang, All,
> 
> On Monday 17 December 2012 Wang YanQing wrote:
> > dialog.h has two line the same below:
> > extern char dialog_input_result[];
> > This patch remove one of them.
> > 
> > Signed-off-by: Wang YanQing 
> 
> Reviewed-by: "Yann E. MORIN" 
> Tested-by: "Yann E. MORIN" 
Michal, All.

Hi Michal, could you consider pick up this obvious right
patch, and consider others' three patch I sented one week
ago? I just don't want delay them to 2013, and they can get
more test when they appear in next tree.
https://patchwork.kernel.org/patch/1887361/
https://patchwork.kernel.org/patch/1894341/
https://patchwork.kernel.org/patch/1887441/

Happy christmas!

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] iommu: Include linux/err.h

[Wang YanQing]

The linux/iommu.h header uses ERR_PTR defined
in linux/err.h but doesn't include it.

Cc:j...@8bytes.org
Reviewed-by: Alex Williamson 
Signed-off-by: Wang YanQing 
---
 This patch has been in LKML for more than 2 months,
 I even forget it, but the compile error when I compile
 a kernel module for 3.8.8 failed due without CONFIG_IOMMU_API
 in my .config remind me.
 
 I really hope someone accept it.

 Thanks. 
 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..f4a49a6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -20,6 +20,7 @@
 #define __LINUX_IOMMU_H
 
 #include 
+#include 
 #include 
 
 #define IOMMU_READ (1)
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]drivers:acpi: Fix wrong parameter passed to memblock_reserve

[Wang YanQing]

On Mon, Apr 15, 2013 at 07:47:38PM -0700, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 6:44 PM, Wang YanQing  wrote:
> >
> > The parameter of memblock_reserve is start address,
> > and size, not address range.
> >
> > Signed-off-by: Wang YanQing 
> > ---
> >  drivers/acpi/osl.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> > index 586e7e9..bcb7a3b 100644
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -641,7 +641,7 @@ void __init acpi_initrd_override(void *data, size_t 
> > size)
> >  * Both memblock_reserve and e820_add_region (via 
> > arch_reserve_mem_area)
> >  * works fine.
> >  */
> > -   memblock_reserve(acpi_tables_addr, acpi_tables_addr + 
> > all_tables_size);
> > +   memblock_reserve(acpi_tables_addr, all_tables_size);
> > arch_reserve_mem_area(acpi_tables_addr, all_tables_size);
> 
> Acked-by: Yinghai Lu 
> 
> And it should go to stable for v3.8

Hi all, I think this fix should be merged before 3.9 is out,
it make no much sense to backport it for 3.9 later, but we don't have 
much time before 3.9 is out, so...

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]memblock: Fix potential section mismatch problem

[Wang YanQing]

This patch convert __init to __init_memblock
for functions which make reference to memblock variable
with attribute __meminitdata.

Signed-off-by: Wang YanQing 
---
 mm/memblock.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index c5fad93..ee74c69 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -766,7 +766,7 @@ int __init_memblock memblock_set_node(phys_addr_t base, 
phys_addr_t size,
 }
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
-static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
+static phys_addr_t __init_memblock memblock_alloc_base_nid(phys_addr_t size,
phys_addr_t align, phys_addr_t max_addr,
int nid)
 {
@@ -785,17 +785,17 @@ static phys_addr_t __init 
memblock_alloc_base_nid(phys_addr_t size,
return 0;
 }
 
-phys_addr_t __init memblock_alloc_nid(phys_addr_t size, phys_addr_t align, int 
nid)
+phys_addr_t __init_memblock memblock_alloc_nid(phys_addr_t size, phys_addr_t 
align, int nid)
 {
return memblock_alloc_base_nid(size, align, MEMBLOCK_ALLOC_ACCESSIBLE, 
nid);
 }
 
-phys_addr_t __init __memblock_alloc_base(phys_addr_t size, phys_addr_t align, 
phys_addr_t max_addr)
+phys_addr_t __init_memblock __memblock_alloc_base(phys_addr_t size, 
phys_addr_t align, phys_addr_t max_addr)
 {
return memblock_alloc_base_nid(size, align, max_addr, MAX_NUMNODES);
 }
 
-phys_addr_t __init memblock_alloc_base(phys_addr_t size, phys_addr_t align, 
phys_addr_t max_addr)
+phys_addr_t __init_memblock memblock_alloc_base(phys_addr_t size, phys_addr_t 
align, phys_addr_t max_addr)
 {
phys_addr_t alloc;
 
@@ -808,12 +808,12 @@ phys_addr_t __init memblock_alloc_base(phys_addr_t size, 
phys_addr_t align, phys
return alloc;
 }
 
-phys_addr_t __init memblock_alloc(phys_addr_t size, phys_addr_t align)
+phys_addr_t __init_memblock memblock_alloc(phys_addr_t size, phys_addr_t align)
 {
return memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
 }
 
-phys_addr_t __init memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, 
int nid)
+phys_addr_t __init_memblock memblock_alloc_try_nid(phys_addr_t size, 
phys_addr_t align, int nid)
 {
phys_addr_t res = memblock_alloc_nid(size, align, nid);
 
@@ -827,12 +827,12 @@ phys_addr_t __init memblock_alloc_try_nid(phys_addr_t 
size, phys_addr_t align, i
  * Remaining API functions
  */
 
-phys_addr_t __init memblock_phys_mem_size(void)
+phys_addr_t __init_memblock memblock_phys_mem_size(void)
 {
return memblock.memory.total_size;
 }
 
-phys_addr_t __init memblock_mem_size(unsigned long limit_pfn)
+phys_addr_t __init_memblock memblock_mem_size(unsigned long limit_pfn)
 {
unsigned long pages = 0;
struct memblock_region *r;
@@ -862,7 +862,7 @@ phys_addr_t __init_memblock memblock_end_of_DRAM(void)
return (memblock.memory.regions[idx].base + 
memblock.memory.regions[idx].size);
 }
 
-void __init memblock_enforce_memory_limit(phys_addr_t limit)
+void __init_memblock memblock_enforce_memory_limit(phys_addr_t limit)
 {
unsigned long i;
phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX;
@@ -904,7 +904,7 @@ static int __init_memblock memblock_search(struct 
memblock_type *type, phys_addr
return -1;
 }
 
-int __init memblock_is_reserved(phys_addr_t addr)
+int __init_memblock memblock_is_reserved(phys_addr_t addr)
 {
return memblock_search(&memblock.reserved, addr) != -1;
 }
@@ -1016,12 +1016,12 @@ void __init_memblock __memblock_dump_all(void)
memblock_dump(&memblock.reserved, "reserved");
 }
 
-void __init memblock_allow_resize(void)
+void __init_memblock memblock_allow_resize(void)
 {
memblock_can_resize = 1;
 }
 
-static int __init early_memblock(char *p)
+static int __init_memblock early_memblock(char *p)
 {
if (p && strstr(p, "debug"))
memblock_debug = 1;
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]memblock: Fix potential section mismatch problem

[Wang YanQing]

On Wed, Jun 12, 2013 at 10:29:17AM -0700, Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 9:08 AM, Wang YanQing  wrote:
> >
> > This patch convert __init to __init_memblock
> > for functions which make reference to memblock variable
> > with attribute __meminitdata.
> 
> for which arch?

I just think different arch could have different
meaning about __init and __init_memblock, but
if a function call another function with __init_memblock
annotation or has reference to variable with  __initdata_memblock,
then we have better to give it __init_memblock annotation.


> for x86: __init_memblock is __init, so that is not problem.

Thanks for point out this, then I know why I haven't get
compile warning.

> for other arches like powerpc and sparc etc, __init_memblock is " "
> 
> so you need cc  powerpc, and sparc ...

My first motivation to propose this patch was I found below 
two functions have different annotation which I think they 
should have the same annotation:

"
int __init memblock_is_reserved(phys_addr_t addr)
{
return memblock_search(&memblock.reserved, addr) != -1;
}

int __init_memblock memblock_is_memory(phys_addr_t addr)
{
return memblock_search(&memblock.memory, addr) != -1;
}
"


Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH kbuild-next] kconfig/lxdialog: Add definitions for mininimum (re)size values

[Wang YanQing]

On Sat, Jun 15, 2013 at 11:07:35AM +0200, Sedat Dilek wrote:
> Commit c8dc68ad0fbd ("kconfig/lxdialog: support resize") added support
> for resizing, but forgot to collect all hardcoded values at one single
> place.
> 
> Also add a definition for the check for a minimum screen/window size
> of 80x19.
> 
> [ ChangeLog v3:
>   * Rename MENU_{HEIGTH,WIDTH}_MIN -> MENUBOX_{HEIGTH,WIDTH}_MIN
>   ChangeLog v2:
>   * Rename WIN_{HEIGTH,WIDTH}_MIN -> WINDOW_{HEIGTH,WIDTH}_MIN
>   * Mention the check for a minimum screen/window size in the changelog
>   * Add a comment above the block of new definitions ]
> 
> Signed-off-by: Sedat Dilek 
Acked-by: Wang YanQing 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] TTY:vt: convert remain take_over_console's users to do_take_over_console

[Wang YanQing]

On Tue, Jun 04, 2013 at 10:13:18PM +0200, Pavel Machek wrote:
> On Tue 2013-05-21 13:15:12, Wang YanQing wrote:
> > Impact:
> > 1:convert all remain take_over_console to do_take_over_console
> 
> This is step backwards.

What is step backwards? do_take_over_console appear MUCH MUCH later in kernel
than take_over_console, do_take_over_console is the new API, I can't understand
what is step backwards.

> > --- a/arch/alpha/kernel/console.c
> > +++ b/arch/alpha/kernel/console.c
> > @@ -61,7 +61,9 @@ locate_and_init_vga(void *(*sel_func)(void *, void *))
> >  
> > /* Set the VGA hose and init the new console. */
> > pci_vga_hose = hose;
> > -   take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1);
> > +   console_lock();
> > +   do_take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1);
> > +   console_unlock();
> >  }
> 
> Original was better.

Except reduce some console_lock/unlock scatter scattered in kernel, I 
can't see the "BETTER", and it is not a BIG problem for the benefit to
unify the API.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] TTY:vt: convert remain take_over_console's users to do_take_over_console

[Wang YanQing]

On Thu, Jun 06, 2013 at 01:47:46PM +0200, Pavel Machek wrote:
> On Thu 2013-06-06 09:23:13, Wang YanQing wrote:
> > On Tue, Jun 04, 2013 at 10:13:18PM +0200, Pavel Machek wrote:
> > > On Tue 2013-05-21 13:15:12, Wang YanQing wrote:
> > > > Impact:
> > > > 1:convert all remain take_over_console to do_take_over_console
> > > 
> > > This is step backwards.
> > 
> > What is step backwards? do_take_over_console appear MUCH MUCH later in 
> > kernel
> > than take_over_console, do_take_over_console is the new API, I can't 
> > understand
> > what is step backwards.
> 
> "do_*" is internal api, "*" is external api. You sprinkle internal api
> all over the place.
> 

internal vs external? No, they only have one difference, callee vs caller hold
the console lock.

> > > > --- a/arch/alpha/kernel/console.c
> > > > +++ b/arch/alpha/kernel/console.c
> > > > @@ -61,7 +61,9 @@ locate_and_init_vga(void *(*sel_func)(void *, void *))
> > > >  
> > > > /* Set the VGA hose and init the new console. */
> > > > pci_vga_hose = hose;
> > > > -   take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1);
> > > > +   console_lock();
> > > > +   do_take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1);
> > > > +   console_unlock();
> > > >  }
> > > 
> > > Original was better.
> > 
> > Except reduce some console_lock/unlock scatter scattered in kernel, I 
> > can't see the "BETTER", and it is not a BIG problem for the benefit to
> > unify the API.
> 
> You replaced "calling exported function" with "calling
> internal-sounding function and adding locking too".

do_take_over_console is also exported by:

EXPORT_SYMBOL_GPL(do_take_over_console)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[Wang YanQing]

On Thu, May 30, 2013 at 09:18:43AM +0800, Chen Gang wrote:
> 
> 'boot_args' is an input args, and 'boot_command_line' has a fix length.
> 
> So need use strlcpy() instead of strcpy() to avoid memory overflow.
> 
> 
> Signed-off-by: Chen Gang 
> ---
>  arch/parisc/kernel/setup.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
> index 60c1ae6..7349a3f 100644
> --- a/arch/parisc/kernel/setup.c
> +++ b/arch/parisc/kernel/setup.c
> @@ -69,7 +69,8 @@ void __init setup_cmdline(char **cmdline_p)
>   /* called from hpux boot loader */
>   boot_command_line[0] = '\0';
>   } else {
> - strcpy(boot_command_line, (char *)__va(boot_args[1]));
> + strlcpy(boot_command_line, (char *)__va(boot_args[1]),
> + COMMAND_LINE_SIZE);

What about add 
boot_command_line[COMMAND_LINE_SIZE - 1] = '\0';
to protect the following another strcpy?

"
strcpy(command_line, boot_command_line);
"
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
>   if (boot_args[2] != 0) /* did palo pass us a ramdisk? */
> -- 
> 1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]memblock: do double array and add merge directly path in memblock_insert_region

[Wang YanQing]

We current do double array, region insertion separately, and
have to count how many regions before do the really insertion.
This is the reasion we have the strage repeat, twice execution codes
in memblock_add_region.

If we do double array in region insertion,
we can throw away this strange and inconvenient behavior,
this patch move double array code to memblock_insert_region.

At the same time, we do region insertion and region mergence separately,
and have to iterator all regions after insert a new region every time,
it is not efficient.

If we allow do merge directly when insertion, we can get better performance,
this patch add support to do merge directly in memblock_insert_region.

Signed-off-by: Wang YanQing 
---
 mm/memblock.c | 87 +--
 1 file changed, 42 insertions(+), 45 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index c5fad93..6fc94af 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -330,20 +330,36 @@ static void __init_memblock memblock_merge_regions(struct 
memblock_type *type)
  *
  * Insert new memblock region [@base,@base+@size) into @type at @idx.
  * @type must already have extra room to accomodate the new region.
+ *
+ * RETURNS:
+ * 0 on sucess, non-zero on failure.
  */
-static void __init_memblock memblock_insert_region(struct memblock_type *type,
+static int __init_memblock memblock_insert_region(struct memblock_type *type,
   int idx, phys_addr_t base,
-  phys_addr_t size, int nid)
+  phys_addr_t size, int nid, 
int merge)
 {
struct memblock_region *rgn = &type->regions[idx];
 
-   BUG_ON(type->cnt >= type->max);
+   if (merge && (base + size) == rgn->base &&
+   nid == memblock_get_region_node(rgn)) {
+   rgn->base = base;
+   rgn->size += size;
+   type->total_size += size;
+   return 0;
+   }
+
+   if (type->cnt + 1 > type->max) {
+   if (memblock_double_array(type, base, size) < 0)
+   return -ENOMEM;
+   }
+
memmove(rgn + 1, rgn, (type->cnt - idx) * sizeof(*rgn));
rgn->base = base;
rgn->size = size;
memblock_set_region_node(rgn, nid);
type->cnt++;
type->total_size += size;
+   return 0;
 }
 
 /**
@@ -364,10 +380,8 @@ static void __init_memblock memblock_insert_region(struct 
memblock_type *type,
 static int __init_memblock memblock_add_region(struct memblock_type *type,
phys_addr_t base, phys_addr_t size, int nid)
 {
-   bool insert = false;
-   phys_addr_t obase = base;
phys_addr_t end = base + memblock_cap_size(base, &size);
-   int i, nr_new;
+   int i, ret;
 
if (!size)
return 0;
@@ -381,14 +395,6 @@ static int __init_memblock memblock_add_region(struct 
memblock_type *type,
type->total_size = size;
return 0;
}
-repeat:
-   /*
-* The following is executed twice.  Once with %false @insert and
-* then with %true.  The first counts the number of regions needed
-* to accomodate the new area.  The second actually inserts them.
-*/
-   base = obase;
-   nr_new = 0;
 
for (i = 0; i < type->cnt; i++) {
struct memblock_region *rgn = &type->regions[i];
@@ -404,10 +410,11 @@ repeat:
 * area, insert that portion.
 */
if (rbase > base) {
-   nr_new++;
-   if (insert)
-   memblock_insert_region(type, i++, base,
-  rbase - base, nid);
+   ret = memblock_insert_region(type, i++, base,
+   rbase - base, nid, 1);
+   if (ret) {
+   return ret;
+   }
}
/* area below @rend is dealt with, forget about it */
base = min(rend, end);
@@ -415,25 +422,13 @@ repeat:
 
/* insert the remaining portion */
if (base < end) {
-   nr_new++;
-   if (insert)
-   memblock_insert_region(type, i, base, end - base, nid);
+   ret = memblock_insert_region(type, i, base, end - base, nid, 1);
+   if (ret) {
+   return ret;
+   }
}
 
-   /*
-* If this was the first round, resize array and repeat for actual
-* insertions; otherwise, merge and return.
-*/
-   if (!insert) {
-   while (type->cnt + nr_new > type->max)
-   if (memblock_d

Re: [v3.9] [v3.10] [Regression] serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller

[Wang YanQing]

On Mon, Jul 01, 2013 at 12:14:45PM -0400, Joseph Salisbury wrote:
> Hi Wang,
> 
> A bug was opened against the Ubuntu kernel[0].  After a kernel bisect,
> it was found that reverting the following commit resolved this bug:
> 
> commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366
> Author: Wang YanQing 
> Date:   Fri Mar 1 11:47:20 2013 +0800
> 
> serial: 8250_pci: add support for another kind of NetMos Technology
> PCI 9835 Multi-I/O Controller
> 
> 
> The regression was introduced as of v3.9-rc3 and still exists in the
> current Mainline tree.  It was also propagated to the stable trees.
> 
> The patch causes the device to use the serial module instead of
> parport_serial.  Maybe the the quirk in ~drivers/pci/quirks.c
> quirk_netmos() needs to be modified?
> 
> I see that you are the author of this patch, so I wanted to run this by
> you.  I was thinking of requesting a revert, but I wanted to get your
> feedback first.
> 
> 
> Thanks,
> 
> Joe
Hi all,
I am sorry for it and later reply.

But I am sure I have included the parport_serial in the
kernel for my consumers at the time they report their
PCI 9835 Multi-I/O Controller didn't work which cause
this "culprit" patch.

I don't have the card in hand right now, so I can't
dig into it. After stare into parport_serial.c, yes,
it seems like it will handle this pci serial card.

Maybe I forget or miss something, I hope.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] smp/ipi: Remove redundant cfd->cpumask_ipi mask

[Wang YanQing]

On Fri, Jul 05, 2013 at 09:57:01PM +0530, Preeti U Murthy wrote:
> cfd->cpumask_ipi is used only in smp_call_function_many().The existing
> comment around it says that this additional mask is used because
> cfd->cpumask can get overwritten.
> 
> There is no reason why the cfd->cpumask can be overwritten, since this
> is a per_cpu mask; nobody can change it but us and we are
> called with preemption disabled.

The ChangeLog for f44310b98ddb7f0d06550d73ed67df5865e3eda5
which import cfd->cpumask_ipi saied the reason why we need
it:

"As explained by Linus as well:

 |
 | Once we've done the "list_add_rcu()" to add it to the
 | queue, we can have (another) IPI to the target CPU that can
 | now see it and clear the mask.
 |
 | So by the time we get to actually send the IPI, the mask might
 | have been cleared by another IPI.
 |

This patch also fixes a system hang problem, if the data->cpumask
gets cleared after passing this point:

if (WARN_ONCE(!mask, "empty IPI mask"))
return;

then the problem in commit 83d349f35e1a ("x86: don't send an IPI to
the empty set of CPU's") will happen again.
"
So this patch is wrong.

And you should cc linus and Jan Beulich who give acked-by tag to
the commit.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] smp/ipi:Remove check around csd lock in handler for smp_call_function variants

[Wang YanQing]

On Fri, Jul 05, 2013 at 09:57:21PM +0530, Preeti U Murthy wrote:
> call_single_data is always locked by all callers of
> arch_send_call_function_single_ipi() or
> arch_send_call_function_ipi_mask() which results in execution of
> generic_call_function_interrupt() handler.
> 
> Hence remove the check for lock on csd in generic_call_function_interrupt()
> handler, before unlocking it.

I can't find where is the generic_call_function_interrupt :)

> Signed-off-by: Preeti U Murthy 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Xiao Guangrong 
> Cc: srivatsa.b...@linux.vnet.ibm.com
> Cc: Paul E. McKenney 
> Cc: Steven Rostedt 
> Cc: Rusty Russell  ---
> 
>  kernel/smp.c |   14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/kernel/smp.c b/kernel/smp.c
> index b6981ae..d37581a 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -181,25 +181,13 @@ void generic_smp_call_function_single_interrupt(void)
>  
>   while (!list_empty(&list)) {
>   struct call_single_data *csd;
> - unsigned int csd_flags;
>  
>   csd = list_entry(list.next, struct call_single_data, list);
>   list_del(&csd->list);
>  
> - /*
> -  * 'csd' can be invalid after this call if flags == 0
> -  * (when called through generic_exec_single()),
> -  * so save them away before making the call:
> -  */
> - csd_flags = csd->flags;
> -

You haven't mention this change in the ChangeLog, don't do it.
I can't see any harm to remove csd_flags, but I hope others
check it again.

>   csd->func(csd->info);
>  
> - /*
> -  * Unlocked CSDs are valid through generic_exec_single():
> -  */
> - if (csd_flags & CSD_FLAG_LOCK)
> - csd_unlock(csd);
> + csd_unlock(csd);

I don't like this change, I think check CSD_FLAG_LOCK 
to make sure we really need csd_unlock is good.

Just like you can't know who and how people will use the
API, so some robust check code is good.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] smp/ipi: Remove redundant cfd->cpumask_ipi mask

[Wang YanQing]

On Sat, Jul 06, 2013 at 10:59:39AM +0530, Preeti U Murthy wrote:
> Hi Wang,
> 
> On 07/06/2013 08:43 AM, Wang YanQing wrote:
> > On Fri, Jul 05, 2013 at 09:57:01PM +0530, Preeti U Murthy wrote:
> >> cfd->cpumask_ipi is used only in smp_call_function_many().The existing
> >> comment around it says that this additional mask is used because
> >> cfd->cpumask can get overwritten.
> >>
> >> There is no reason why the cfd->cpumask can be overwritten, since this
> >> is a per_cpu mask; nobody can change it but us and we are
> >> called with preemption disabled.
> > 
> > The ChangeLog for f44310b98ddb7f0d06550d73ed67df5865e3eda5
> > which import cfd->cpumask_ipi saied the reason why we need
> > it:
> > 
> > "As explained by Linus as well:
> > 
> >  |
> >  | Once we've done the "list_add_rcu()" to add it to the
> >  | queue, we can have (another) IPI to the target CPU that can
> >  | now see it and clear the mask.
> >  |
> >  | So by the time we get to actually send the IPI, the mask might
> >  | have been cleared by another IPI.
> 
> I am unable to understand where the cfd->cpumask of the source cpu is
> getting cleared. Surely not by itself, since it is preempt disabled.
> Also why should it get cleared?

Assume we have three CPUs: A,B,C

A call smp_call_function_many to notify C do something,
and current it execute on finished below codes:

"for_each_cpu(cpu, cfd->cpumask) {
struct call_single_data *csd = per_cpu_ptr(cfd->csd, cpu);
struct call_single_queue *dst =
&per_cpu(call_single_queue, cpu);
unsigned long flags;

csd_lock(csd);
csd->func = func;
csd->info = info;

raw_spin_lock_irqsave(&dst->lock, flags);
list_add_tail(&csd->list, &dst->list);
raw_spin_unlock_irqrestore(&dst->lock, flags);
}
"
You see "list_add_tail(&csd->list, &dst->list);", it pass the address of csd,
and A stop before call arch_send_call_function_ipi_mask due interrupt.

At this time B send ipi to C also, then C will see the csd passed by A,
then C will clear itself in the cfd->cpumask.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] smp/ipi:Clarify ambiguous comments around deadlock scenarios in smp_call_function variants.

[Wang YanQing]

On Fri, Jul 05, 2013 at 09:57:11PM +0530, Preeti U Murthy wrote:
> Elaborate on when deadlocks can occur when a call is made to
> smp_call_function_single() and its friends. This avoids ambiguity about
> when to use these calls.
> 
> Signed-off-by: Preeti U Murthy 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Xiao Guangrong 
> Cc: srivatsa.b...@linux.vnet.ibm.com
> Cc: Paul E. McKenney 
> Cc: Steven Rostedt 
> Cc: Rusty Russell  ---
> 
>  kernel/smp.c |   46 --
>  1 file changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 89be6e6..b6981ae 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -230,7 +230,23 @@ int smp_call_function_single(int cpu, smp_call_func_t 
> func, void *info,
>   this_cpu = get_cpu();
>  
>   /*
> -  * Can deadlock when called with interrupts disabled.
> +  * Can deadlock when called with interrupts disabled under two
> +  * different circumstances depending on the wait parameter.
> +  *
> +  * 1. wait = 1: Two CPUs execute smp_call_function_single(), send an
> +  * IPI to each other, and wait for func to finish on each other.
> +  * Since they are interrupt disabled, neither receives this IPI,
> +  * nor do they proceed forward,as they wait for each other to complete
> +  * execution of func.
> +  *

Yes, we should avoid this situation, but I am not sure whether this is 
the meaning of "deadlock" in the original comment.

> +  * 2. wait = 0: This function could be called from an interrupt
> +  * context, and can get blocked on the csd_lock(csd) below in
> +  * "non wait cases".
> +  * This is because the percpu copy of csd of this_cpu is used
> +  * in non wait cases. Under such circumstances, if the previous caller
> +  * of this function who got preempted by this interrupt has already 
> taken
> +  * the lock under non wait condition, it will result in deadlock.
> +  *

No, it will not cause deadlock, it is not mutex lock,  it is busy wait, so
when the CSD_FLAG_LOCK be cleared, the code will go on running.

After stare into the kernel/smp.c, I can't catch what the exactly meaning
of the "DeadLock" in the original comment also.

I hope someone can clarify it.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] smp/ipi:Remove check around csd lock in handler for smp_call_function variants

[Wang YanQing]

On Sat, Jul 06, 2013 at 01:36:27PM +0530, Preeti U Murthy wrote:
> Ideally it should be under a WARN_ON(). csd_unlock() has that WARN_ON().
> Unlocking a parameter which is not locked should be seen as a bug, which
> the above code is not doing. In fact it avoids it being reported as a bug.

Although I know what's your meaning, but just like the comment in code:

"
 /* 
  
  * Unlocked CSDs are valid through generic_exec_single():  
  
  */
"

If the csd don't come from generic_exec_single, then
Unlocked CSDs maybe are not valid. So we check CSD_FLAG_LOCK
to avoid trigger the WARN_ON in csd_unlock.

Genric_exec_single's name imply it is a generic version,
you know, maybe we will have "special" version.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] smp: Give WARN()ing when calling smp_call_function_many()/single() in serving irq

[Wang YanQing]

On Fri, Jul 05, 2013 at 03:50:57PM +0200, Thomas Gleixner wrote:
> On Sat, 16 Feb 2013, Chuansheng Liu wrote:
> > There is a real case for softirq DEADLOCK case:
> > 
> > CPUACPUB
> > spin_lock(&spinlock)
> > Any irq coming, call the irq handler
> > irq_exit()
> > spin_lock_irq(&spinlock)
> > <== Blocking here due to
> > CPUB hold it
> >   __do_softirq()
> > run_timer_softirq()
> >   timer_cb()
> > call smp_call_function_many()
> >   send IPI interrupt to CPUA
> > wait_csd()
> > 
> > Then both CPUA and CPUB will be deadlocked here.
> 

Why can't we just use spin_lock_irq instead of spin_lock in CPUB to
prevent this to happen ?

And the according senario for kernel/smp.c is to use raw_spin_lock_irqsave
instead of raw_spin_lock in generic_smp_call_function_single_interrupt
to protect the follow one line codes:

raw_spin_lock(&q->lock);
list_replace_init(&q->list, &list);
raw_spin_unlock(&q->lock);

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] smp: Give WARN()ing when calling smp_call_function_many()/single() in serving irq

[Wang YanQing]

On Fri, Jul 05, 2013 at 04:37:14PM +0200, Thomas Gleixner wrote:
> Hmm, even there it matters, because of the following scenario:
> 
> CPU 0
> smp_call_function_single(CPU 1)
> csd_lock(CPU 1)

No, smpl_call_function_single(CPU 1)
will csd_lock(CPU 0), not csd_lock(CPU 1)

> irq_enter()
> irq_exit()
> __do_softirq()
> smp_call_function_many()
>   setup csd (CPU 1)
> csd_lock(CPU 1) ==> CPU 0 deadlocked itself.
> 

maybe below is the scenario:
 irq_enter()
 irq_exit()
 __do_softirq()
 smp_call_function_single()
   setup csd (CPU 1)
 csd_lock(CPU 0) ==> CPU 0 deadlocked itself.
 

> And this is even more likely to happen than the lock issue.
> 
> Thanks,
> 
>   tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] smp/ipi:Remove check around csd lock in handler for smp_call_function variants

[Wang YanQing]

On Sun, Jul 07, 2013 at 09:53:48PM +0530, Preeti U Murthy wrote:
> > "
> >  /* 
> >   
> >   * Unlocked CSDs are valid through generic_exec_single():  
> >   
> >   */
> 
> I don't understand this comment. All callers of generic_exec_single()
> take the csd lock. So where is the scenario of csds being unlocked in
> generic_exec_single() before the call to
> arch_send_call_function_single_ipi() is made?
>   Rather what is the above comment trying to say?

I have given the answer to this question in last reply.

I don't know whether it is right to make a assumption through
this way that what you do currently:

Find all the current api users, and drop all the robust codes,
despite the unpredictable future users.

Ok, I know the balance between "robust" vs "performance",
robust check codes will bring performance penalty in fastest
code path, but the "penalty" is neglectable sometimes for
modern CPU.

I decide to respect the MAINTAINER's decision to accept this 
change or not.

Thanks.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: Fix override new_cpu_data.x86 with 486

[Wang YanQing]

We should set X86 to 486 before use cpuid
to detect the cpu type, if we set X86 to 486
after cpuid, then we will get 486 for ever.

Yes, we will correct this in early_cpu_init,
but it is still a wrong behavior, right? So
just fix it.

I also find maybe we can delete the new_cpu_data,
because we will over write all the information
in early_cpu_init, and before early_cpu_init,
there is no user of new_cpu_data, but this is
another patch in the future.

Signed-off-by: Wang YanQing 
---
 arch/x86/kernel/head_32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 73afd11..733a8ef 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -410,6 +410,7 @@ enable_paging:
 /*
  * Check if it is 486
  */
+   movb $4,X86 # at least 486
cmpl $-1,X86_CPUID
je is486
 
@@ -437,7 +438,6 @@ enable_paging:
movl %edx,X86_CAPABILITY
 
 is486:
-   movb $4,X86
movl $0x50022,%ecx  # set AM, WP, NE and MP
movl %cr0,%eax
andl $0x8011,%eax   # Save PG,PE,ET
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Fix override new_cpu_data.x86 with 486

[Wang YanQing]

On Thu, Jun 27, 2013 at 12:54:35PM +0200, Borislav Petkov wrote:
> On Thu, Jun 27, 2013 at 12:26:40AM +0800, Wang YanQing wrote:
> > 
> > We should set X86 to 486 before use cpuid
> > to detect the cpu type, if we set X86 to 486
> > after cpuid, then we will get 486 for ever.
> 
> So not "for ever" but until cpu_detect runs.
> 
> > 
> > Yes, we will correct this in early_cpu_init,
> > but it is still a wrong behavior, right? So
> > just fix it.
> 
> Right, so this patch is correct and it fixes the small window where we
> run with family == 4 before cpu_detect but the commit message needs a
> bit massaging before it gets applied.

I think it fixes the window where we run with family > 4 before cpu_detect :)

> 
> > 
> > I also find maybe we can delete the new_cpu_data,
> > because we will over write all the information
> > in early_cpu_init, and before early_cpu_init,
> > there is no user of new_cpu_data, but this is
> > another patch in the future.
> 
> You can drop that part.

I can't catch the exactly meaning:

We can drop the new_cpu_data or 
I need to drop this part commit
message.


Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2]x86: Fix override new_cpu_data.x86 with 486

[Wang YanQing]

We should set X86 to 486 before use cpuid
to detect the cpu type, if we set X86 to 486
after cpuid, then we will get 486 until
cpu_detect runs.

Signed-off-by: Wang YanQing 
---
ChangeLog
v1-v2:
1:Use more accurate and short commit log

 arch/x86/kernel/head_32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 73afd11..24c6675 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -410,6 +410,7 @@ enable_paging:
 /*
  * Check if it is 486
  */
+   movb $4,X86 # at least 486
cmpl $-1,X86_CPUID
je is486
 
@@ -437,7 +438,6 @@ enable_paging:
movl %edx,X86_CAPABILITY
 
 is486:
-   movb $4,X86
movl $0x50022,%ecx  # set AM, WP, NE and MP
movl %cr0,%eax
andl $0x8011,%eax   # Save PG,PE,ET
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller

[Wang YanQing]

01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O 
Controller (rev 01)
Subsystem: Device [1000:0012]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
---
 drivers/tty/serial/8250/8250_pci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 791c5a7..ebcc362 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4791,6 +4791,10 @@ static struct pci_device_id serial_pci_tbl[] = {
PCI_VENDOR_ID_IBM, 0x0299,
0, 0, pbn_b0_bt_2_115200 },
 
+   {   PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835,
+   0x1000, 0x0012,
+   0, 0, pbn_b0_bt_2_115200 },
+
{   PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9901,
0xA000, 0x1000,
0, 0, pbn_b0_1_115200 },
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]serial: 8250: Fix detect XScale port wrong

[Wang YanQing]

Some UARTs add enhanced functions with unused bit in
16550 standard, like UART_IER_UUE bit, it cause XScale
detect wrong. Now detect UART_IER_UUE and UART_IER_RTOIE
to reduce the annoying wrong result which cause UARTs don't
work.

Serial controller: Device 4348:3253(CH352 PCI based Multi-I/O Controller)
is a example. It use UART_IER_UUE as the LOWPOWER function,
you can get the datasheet from below urls:

http://wch-ic.com/download/list.asp?id=116
CH352DS1.PDF

http://wch-ic.com/download/list.asp?id=117
CH352DS2.PDF.

I choice UART_IER_RTOIE as another test bit, because
choice it is harmless for current code, we will set
UART_CAP_RTOIE if it is XScale port.

Signed-off-by: Wang YanQing 
---
 drivers/tty/serial/8250/8250.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 0efc815..2c1f9c9 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -841,6 +841,7 @@ static void autoconfig_16550a(struct uart_8250_port *up)
 {
unsigned char status1, status2;
unsigned int iersave;
+   unsigned int iertest;
 
up->port.type = PORT_16550A;
up->capabilities |= UART_CAP_FIFO;
@@ -966,16 +967,25 @@ static void autoconfig_16550a(struct uart_8250_port *up)
 * We're going to explicitly set the UUE bit to 0 before
 * trying to write and read a 1 just to make sure it's not
 * already a 1 and maybe locked there before we even start start.
+*
+* 01/03/2013
+* Some UARTs add enhanced functions with unused bit in
+* 16550 standard, like UART_IER_UUE bit, it cause XScale
+* detect wrong. Now detect UART_IER_UUE and UART_IER_RTOIE
+* to reduce the annoying wrong result which cause UART don't
+* work.
 */
iersave = serial_in(up, UART_IER);
-   serial_out(up, UART_IER, iersave & ~UART_IER_UUE);
-   if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
+   iertest = UART_IER_UUE | UART_IER_RTOIE;
+
+   serial_out(up, UART_IER, iersave & ~iertest);
+   if (!(serial_in(up, UART_IER) & iertest)) {
/*
 * OK it's in a known zero state, try writing and reading
 * without disturbing the current state of the other bits.
 */
-   serial_out(up, UART_IER, iersave | UART_IER_UUE);
-   if (serial_in(up, UART_IER) & UART_IER_UUE) {
+   serial_out(up, UART_IER, iersave | iertest);
+   if ((serial_in(up, UART_IER) & iertest) == iertest) {
/*
 * It's an Xscale.
 * We'll leave the UART_IER_UUE bit set to 1 (enabled).
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]serial: 8250: Fix detect XScale port wrong

[Wang YanQing]

On Fri, Mar 01, 2013 at 02:17:16PM -0500, Paul Gortmaker wrote:
> On 13-03-01 12:56 AM, Wang YanQing wrote:
> > Some UARTs add enhanced functions with unused bit in
> > 16550 standard, like UART_IER_UUE bit, it cause XScale
> 
> Which xscale platform?  It would be nice to know the specifics.
The "XScale" mean the XScale port detect code in autoconfig_16550a,
I meet the problem in a normal pc motherboard, I should rephrase
the subject use "Fix detect 16550A ports as XScale ports wrong"
> 
> > detect wrong. Now detect UART_IER_UUE and UART_IER_RTOIE
> > to reduce the annoying wrong result which cause UARTs don't
> > work.
> 
> You should ideally identify the original commit which caused
> the regression.  Assuming you have fully understood the problem
> you should be able to do this with "git blame" and not need to
> do the full bisect.
>
No it is not a regression, it is caused just like you say
there are many 8250/16550 variations, and I meet one, that is it.

> 
> > 
> > Serial controller: Device 4348:3253(CH352 PCI based Multi-I/O Controller)
> > is a example. It use UART_IER_UUE as the LOWPOWER function,
> > you can get the datasheet from below urls:
> > 
> > http://wch-ic.com/download/list.asp?id=116
> > CH352DS1.PDF
> > 
> > http://wch-ic.com/download/list.asp?id=117
> > CH352DS2.PDF.
> 
> Rather than quote links that will expire and no longer be
> valid in six months, it would be better if you described
> exactly how and why these ports are different directly in
> your commit long log.

Device 4348:3253 use the UART_IER_UUE
as the LOWPOWER function , so it is readable and writable,
quote out the origin words in datasheet.

"
LOWPOWER:When the bit is 1, close the internal benchmark clock
of serial port to set into low-power status.
"

That is  the convict cause our XScale detect code work wrong.

> What does your change do to Xscale that do not do UART_IER_RTOIE?
Yes, you are right, I don't have experience with Xscale, so I will
fix the problem in another way, set it fix type in 8250_pci code 
maybe is good.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]8250_pci: Add additional WCH CH352 device

[Wang YanQing]

This patch fix a problem XScale port
detect code in autoconfig_16550a treat
16550A port as XScale port, caused by
CH352 device use the 6th bit(UART_IER_UUE)
in IER as a enhance function make this bit
w/r.

for the below device:
"
01:08.0 Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:3253
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
---
 drivers/tty/serial/8250/8250_pci.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index ebcc362..be45d39 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1557,6 +1557,7 @@ pci_wch_ch353_setup(struct serial_private *priv,
 #define PCI_DEVICE_ID_WCH_CH353_4S 0x3453
 #define PCI_DEVICE_ID_WCH_CH353_2S1PF  0x5046
 #define PCI_DEVICE_ID_WCH_CH353_2S1P   0x7053
+#define PCI_DEVICE_ID_WCH_CH352_2S 0x3253
 #define PCI_VENDOR_ID_AGESTAR  0x5372
 #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
 #define PCI_VENDOR_ID_ASIX 0x9710
@@ -2180,6 +2181,14 @@ static struct pci_serial_quirk pci_serial_quirks[] 
__refdata = {
.subdevice  = PCI_ANY_ID,
.setup  = pci_wch_ch353_setup,
},
+   /* WCH CH352 2S card (16550 clone) */
+   {
+   .vendor = PCI_VENDOR_ID_WCH,
+   .device = PCI_DEVICE_ID_WCH_CH352_2S,
+   .subvendor  = PCI_ANY_ID,
+   .subdevice  = PCI_ANY_ID,
+   .setup  = pci_wch_ch353_setup,
+   },
/*
 * ASIX devices with FIFO bug
 */
@@ -4873,6 +4882,10 @@ static struct pci_device_id serial_pci_tbl[] = {
PCI_ANY_ID, PCI_ANY_ID,
0, 0, pbn_b0_bt_2_115200 },
 
+   {   PCI_VENDOR_ID_WCH, PCI_DEVICE_ID_WCH_CH352_2S,
+   PCI_ANY_ID, PCI_ANY_ID,
+   0, 0, pbn_b0_bt_2_115200 },
+
/*
 * Commtech, Inc. Fastcom adapters
 */
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]8250_pci: Add additional WCH CH352 device

[Wang YanQing]

On Sat, Mar 02, 2013 at 05:45:55PM +0800, Wang YanQing wrote:
> This patch fix a problem XScale port
> detect code in autoconfig_16550a treat
> 16550A port as XScale port, caused by
> CH352 device use the 6th bit(UART_IER_UUE)
> in IER as a enhance function make this bit
> w/r.
> 
> for the below device:
> "
> 01:08.0 Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
>   Subsystem: Device 4348:3253
>   Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-Interrupt: pin A routed to IRQ 20
>   Region 0: I/O ports at e010 [size=8]
>   Region 1: I/O ports at e000 [size=8]
>   Kernel driver in use: serial
> "
> [Note: I haven't test this patch, because I can't
> access the hardware now, but it should be right]
> 
I have tested it this morning, it works.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2]8250_pci: Add WCH CH352 quirk to avoid Xscale detection

[Wang YanQing]

The code in 8250.c for detecting ARM/XScale UARTs says:

  * Try writing and reading the UART_IER_UUE bit (b6).
  * If it works, this is probably one of the Xscale platform's
  * internal UARTs.

If the above passes, it then goes on to:

 * It's an Xscale.
 * We'll leave the UART_IER_UUE bit set to 1 (enabled).

However, the CH352 uses the UART_IER_UUE as the LOWPOWER function,
so it is readable and writable.  According to the datasheet:

"LOWPOWER:When the bit is 1, close the internal benchmark
 clock of serial port to set into low-power status.

So it essentially gets mis-detected as Xscale, and gets
powered down in the process.  The device in question where
this was seen is listed by lspci as:

 Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])

Re-using the 353 quirk which just sets flags to fixed and type
to 16550 is suitable for fixing the 352 as well.

Signed-off-by: Wang YanQing 
Signed-off-by: Paul Gortmaker 
---
 Changes
 V1-V2:
 1: Use a better descriptive subject by Paul Gortmaker 
 2: Add more detail log by Paul Gortmaker 

 I resend this version, because it will make merge job easy, and I 
 will not owe gregkh juice :)

 Thanks, Paul Gortmaker and all
 drivers/tty/serial/8250/8250_pci.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 791c5a7..5805f89 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1554,6 +1554,7 @@ pci_wch_ch353_setup(struct serial_private *priv,
 #define PCI_DEVICE_ID_PLX_CRONYX_OMEGA 0xc001
 #define PCI_DEVICE_ID_INTEL_PATSBURG_KT 0x1d3d
 #define PCI_VENDOR_ID_WCH  0x4348
+#define PCI_DEVICE_ID_WCH_CH352_2S 0x3253
 #define PCI_DEVICE_ID_WCH_CH353_4S 0x3453
 #define PCI_DEVICE_ID_WCH_CH353_2S1PF  0x5046
 #define PCI_DEVICE_ID_WCH_CH353_2S1P   0x7053
@@ -2180,6 +2181,14 @@ static struct pci_serial_quirk pci_serial_quirks[] 
__refdata = {
.subdevice  = PCI_ANY_ID,
.setup  = pci_wch_ch353_setup,
},
+   /* WCH CH352 2S card (16550 clone) */
+   {
+   .vendor = PCI_VENDOR_ID_WCH,
+   .device = PCI_DEVICE_ID_WCH_CH352_2S,
+   .subvendor  = PCI_ANY_ID,
+   .subdevice  = PCI_ANY_ID,
+   .setup  = pci_wch_ch353_setup,
+   },
/*
 * ASIX devices with FIFO bug
 */
@@ -4869,6 +4878,10 @@ static struct pci_device_id serial_pci_tbl[] = {
PCI_ANY_ID, PCI_ANY_ID,
0, 0, pbn_b0_bt_2_115200 },
 
+   {   PCI_VENDOR_ID_WCH, PCI_DEVICE_ID_WCH_CH352_2S,
+   PCI_ANY_ID, PCI_ANY_ID,
+   0, 0, pbn_b0_bt_2_115200 },
+
/*
 * Commtech, Inc. Fastcom adapters
 */
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2]serial: 8250_pci: add device id for a kind of Multi-I/O Controller based on NetMos Technology PCI 9835

[Wang YanQing]

I get a Multi-I/O Controller below:
01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O 
Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic 1P2S
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
---
Changes:
V1-V2:
1: use a better descriptive subject
2: add more detail log

Thanks
 drivers/tty/serial/8250/8250_pci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 5805f89..2120840 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4800,6 +4800,10 @@ static struct pci_device_id serial_pci_tbl[] = {
PCI_VENDOR_ID_IBM, 0x0299,
0, 0, pbn_b0_bt_2_115200 },
 
+   {   PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835,
+   0x1000, 0x0012,
+   0, 0, pbn_b0_bt_2_115200 },
+
{   PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9901,
0xA000, 0x1000,
0, 0, pbn_b0_1_115200 },
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2]x86:boot: Remove unneccessary headers

[Wang YanQing]

asm/segment.h come from setup.S:
we used to need GDT_ENTRY_BOOT_CS
to setup gdt, but now we don't need it,
boot_gdt had been moved to kernel/head_32.S

generated/utsrelease.h come from setup.S:
we used to define kernel_version in setup.S,
but we don't need it now, because the
definition of kernel_version had been move
to boot/version.c

asm/e820.h come from setup.S:
we used to do the memory detect in setup.S,
but we don't need it now, because
we do memory detect in boot/memory.c

I can't finger out the commits import the changes
above, because all the changes happened before git
epoch :)

asm/page_types.h come from setup.S:
we used to need the __PAGE_OFFSET define
in page_types.h to compute ramdisk_max,
but now we don't need it in header.S anymore,
cf8fa920c(i386: handle an initrd in highmem (version 2))
remove it.

This patch remove the unneeded head files included
in header.S.

Signed-off-by: Wang YanQing 
---
Changes:
V1-V2:
1:add more detail and long long log

 arch/x86/boot/header.S | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9ec06a1..43a3502 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -15,11 +15,7 @@
  *
  */
 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include "boot.h"
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][TRIVIAL] iommu: Include linux/err.h

[Wang YanQing]

The linux/iommu.h header uses ERR_PTR defined
in linux/err.h but doesn't include it.

Reviewed-by: Alex Williamson 
Signed-off-by: Wang YanQing 
---
 I send this twice to joerg.roe...@amd.com more than one
 month, but it had been ignored, I don't why.

 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..f4a49a6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -20,6 +20,7 @@
 #define __LINUX_IOMMU_H
 
 #include 
+#include 
 #include 
 
 #define IOMMU_READ (1)
-- 
1.7.11.1.116.g8228a23
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][TRIVIAL] tg3: Fix compilation warning

[Wang YanQing]

This patch fix the below compilation warning:
linux/drivers/net/ethernet/broadcom/tg3.c: In function 
'tg3_hwclock_to_timestamp':
linux/drivers/net/ethernet/broadcom/tg3.c:5686: warning: integer constant is 
too large for 'long' type

Signed-off-by: Wang YanQing 
---
 drivers/net/ethernet/broadcom/tg3.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.h 
b/drivers/net/ethernet/broadcom/tg3.h
index d330e81..6ec480a 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -774,7 +774,7 @@
 #define  SG_DIG_AUTONEG_ERROR   0x0001
 #define TG3_TX_TSTAMP_LSB  0x05c0
 #define TG3_TX_TSTAMP_MSB  0x05c4
-#define  TG3_TSTAMP_MASK0x7fff
+#define  TG3_TSTAMP_MASK0x7fffULL
 /* 0x5c8 --> 0x600 unused */
 #define MAC_TX_MAC_STATE_BASE  0x0600 /* 16 bytes */
 #define MAC_RX_MAC_STATE_BASE  0x0610 /* 20 bytes */
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][TRIVIAL] ata:pata_pdc2027x: Fix compiler warnings

[Wang YanQing]

Fix the follwing warnings:
linux/drivers/ata/pata_pdc2027x.c:66: warning: 'pdc2027x_reinit_one' declared 
'static' but never defined

pdc2027x_reinit_one are defined only when CONFIG_PM is defined,
thus making it conditional.

Signed-off-by: Wang YanQing 
---
 drivers/ata/pata_pdc2027x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
index 3f94a88..c76e659 100644
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -63,7 +63,9 @@ enum {
 };
 
 static int pdc2027x_init_one(struct pci_dev *pdev, const struct pci_device_id 
*ent);
+#ifdef CONFIG_PM
 static int pdc2027x_reinit_one(struct pci_dev *pdev);
+#endif
 static int pdc2027x_prereset(struct ata_link *link, unsigned long deadline);
 static void pdc2027x_set_piomode(struct ata_port *ap, struct ata_device *adev);
 static void pdc2027x_set_dmamode(struct ata_port *ap, struct ata_device *adev);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][TRIVIAL]drivers: Fix a class of compiler warnings

[Wang YanQing]

Fix the warnings look like below:
/linux/drivers/dma/timb_dma.c:801: warning: 'td_remove' defined but not used

I get the warning above when I compile 3.8.6 kernel,
then I fix it and others' same issue in kernel with
the help of perl, then I review and check the changes
one by one.

Signed-off-by: Wang YanQing 
---
 drivers/dma/timb_dma.c | 2 +-
 drivers/mfd/omap-usb-host.c| 2 +-
 drivers/mfd/twl4030-madc.c | 2 +-
 drivers/mmc/host/wmt-sdmmc.c   | 2 +-
 drivers/spi/spi-atmel.c| 2 +-
 drivers/tty/serial/xilinx_uartps.c | 2 +-
 drivers/usb/gadget/mv_u3d_core.c   | 2 +-
 drivers/usb/gadget/mv_udc_core.c   | 2 +-
 drivers/usb/musb/blackfin.c| 2 +-
 drivers/usb/otg/mv_otg.c   | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index 952f823..f709279 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -798,7 +798,7 @@ err_release_region:
 
 }
 
-static int td_remove(struct platform_device *pdev)
+static int __exit td_remove(struct platform_device *pdev)
 {
struct timb_dma *td = platform_get_drvdata(pdev);
struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 05164d7..8bf0eb5 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -654,7 +654,7 @@ end_probe:
  *
  * Reverses the effect of usbhs_omap_probe().
  */
-static int usbhs_omap_remove(struct platform_device *pdev)
+static int __exit usbhs_omap_remove(struct platform_device *pdev)
 {
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
 
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 88ff9dc..86ba920 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -785,7 +785,7 @@ err_power:
return ret;
 }
 
-static int twl4030_madc_remove(struct platform_device *pdev)
+static int __exit twl4030_madc_remove(struct platform_device *pdev)
 {
struct twl4030_madc_data *madc = platform_get_drvdata(pdev);
 
diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c
index 154f0e8..3e98508 100644
--- a/drivers/mmc/host/wmt-sdmmc.c
+++ b/drivers/mmc/host/wmt-sdmmc.c
@@ -892,7 +892,7 @@ fail1:
return ret;
 }
 
-static int wmt_mci_remove(struct platform_device *pdev)
+static int __exit wmt_mci_remove(struct platform_device *pdev)
 {
struct mmc_host *mmc;
struct wmt_mci_priv *priv;
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..1ab72fd 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1009,7 +1009,7 @@ out_free:
return ret;
 }
 
-static int atmel_spi_remove(struct platform_device *pdev)
+static int __exit atmel_spi_remove(struct platform_device *pdev)
 {
struct spi_master   *master = platform_get_drvdata(pdev);
struct atmel_spi*as = spi_master_get_devdata(master);
diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 9ab9103..98cfbfb 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -997,7 +997,7 @@ static int xuartps_probe(struct platform_device *pdev)
  *
  * Returns 0 on success, negative error otherwise
  **/
-static int xuartps_remove(struct platform_device *pdev)
+static int __exit xuartps_remove(struct platform_device *pdev)
 {
struct uart_port *port = dev_get_drvdata(&pdev->dev);
int rc = 0;
diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index b5cea27..a4e1a19 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -1763,7 +1763,7 @@ static void mv_u3d_gadget_release(struct device *dev)
dev_dbg(dev, "%s\n", __func__);
 }
 
-static int mv_u3d_remove(struct platform_device *dev)
+static int __exit mv_u3d_remove(struct platform_device *dev)
 {
struct mv_u3d *u3d = platform_get_drvdata(dev);
 
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index 6e8b127..c2517ae 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -2128,7 +2128,7 @@ static void gadget_release(struct device *_dev)
complete(udc->done);
 }
 
-static int mv_udc_remove(struct platform_device *dev)
+static int __exit mv_udc_remove(struct platform_device *dev)
 {
struct mv_udc *udc = the_controller;
int clk_i;
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index dbb31b3..72c8c7c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -510,7 +510,7 @@ err0:
return ret;
 }
 
-static int bfin_remove(struct platform_device *pdev)
+static int __exit bfin_remove(struct platform_device *pdev)
 {
struct bfin_glue*glue = platform_get_drvdata(pdev);
 
diff --git a/drivers

[PATCH]drm: Re-add DMT modes for monitors back

[Wang YanQing]

Commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
"drm: don't add inferred modes for monitors that don't support them"

It remove the call add_inferred_modes when DRM_EDID_FEATURE_DEFAULT_GTF
in feature support field is zero, this remove all inferred modes
come from GTF or CVT range information, and also remove DMT modes,
this make me lost some avaiable modes for my TV.
Without this patch I get:
Screen 0: minimum 320 x 200, current 2720 x 1024, maximum 32767 x 32767
VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 414mm x 
257mm
   1440x900   75.0*+   59.9
   1400x1050  60.3
   1280x1024  75.0
   1280x800   59.8
   1152x864   75.0
   1280x720   60.0
   1024x768   75.1 70.1 60.0
   832x62474.6
   800x60072.2 75.0 60.3
   640x48072.8 75.0 66.7 60.0
   720x40070.1
HDMI1 connected 1280x1024+1440+0 (normal left inverted right x axis y axis) 
1600mm x 900mm
   1920x1080  60.0 +   50.0
   1920x1080i 30.0 25.0
   1280x1024  60.0*
   1280x720   60.0 50.0
   1440x576i  25.0
   1024x768   60.0
   1440x480i  30.0
   800x60060.3
   720x57650.0
   720x48059.9
   640x48060.0 59.9
DP1 disconnected (normal left inverted right x axis y axis)

With this patch I get below:
Screen 0: minimum 320 x 200, current 2880 x 900, maximum 32767 x 32767
VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 414mm x 
257mm
   1440x900   75.0*+   59.9
   1400x1050  60.3
   1280x1024  75.0
   1280x800   59.8
   1152x864   75.0
   1280x720   60.0
   1024x768   75.1 70.1 60.0
   832x62474.6
   800x60072.2 75.0 60.3
   640x48072.8 75.0 66.7 60.0
   720x40070.1
HDMI1 connected 1440x900+1440+0 (normal left inverted right x axis y axis) 
1600mm x 900mm
   1440x900   59.9*+
   1920x1080  60.0 +   50.0
   1920x1080i 30.0 25.0
   1680x1050  59.9
   1400x1050  59.9
   1280x1024  60.0
   1280x960   60.0
   1360x768   60.0
   1280x800   59.9
   1280x768   60.0
   1280x720   60.0 50.0
   1440x576i  25.0
   1024x768   60.0
   1440x480i  30.0
   800x60060.3 56.2
   720x57650.0
   848x48060.0
   720x48059.9
   640x48060.0 59.9
DP1 disconnected (normal left inverted right x axis y axis)

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_edid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfd9ed3..10c2147 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1182,7 +1182,8 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
  closure->edid,
  timing);

-   if (!version_greater(closure->edid, 1, 1))
+   if (!version_greater(closure->edid, 1, 1) ||
+   !(closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF))
return; /* GTF not defined yet */
 
switch (range->flags) {
@@ -2022,8 +2023,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
num_modes += add_cvt_modes(connector, edid);
num_modes += add_standard_modes(connector, edid);
num_modes += add_established_modes(connector, edid);
-   if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
-   num_modes += add_inferred_modes(connector, edid);
+   num_modes += add_inferred_modes(connector, edid);
num_modes += add_cea_modes(connector, edid);
 
if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kconfig: sort found symbols by relevance

[Wang YanQing]

On Mon, May 06, 2013 at 05:28:32PM +0200, Jean Delvare wrote:
> Le Monday 06 May 2013 à 15:02 +0200, Yann E. MORIN a écrit :
> > From: "Yann E. MORIN" 
> > 
> > When searching for symbols, return the symbols sorted by relevance.
> > 
> > Relevance is the ratio of the length of the matched string and the
> > length of the symbol name. Symbols of equal relevance are sorted
> > alphabetically.
> I did not look at the code, only tested it, and it does what I asked for
> originally: exact match is listed first. So thank you :)
> 
> However I am not sure if your implementation is what we want. Your
> definition of "relevance" is somewhat arbitrary and may not be
> immediately to others. For example, my own definition of "relevance" was
> that symbols which start with the subject string are more relevant than
> the symbols which have the string in the middle. Others would possibly
> have other definitions.

But no matter what the definition of relevance in text search, 
in the middle or start or end, the searcher always want the "results" 
look like what they input literal.

I think Yann's definition make sense. It is just a pattern matching ratio 
question.

If you want in start, just use ^PCI(reguar search), then with the help of 
this patch, will make people life easier.

This patch is not to replace the regular search, you can just use them together.

BTW, I haven't read the code right now, maybe I will read it tonight.
I test it, it works well, and I find it is useful to use it with regular search.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]ALSA: HDA: Fix Oops caused by dereference NULL pointer

[Wang YanQing]

The interrupt handler azx_interrupt will call azx_update_rirb,
which may call snd_hda_queue_unsol_event, snd_hda_queue_unsol_event
will dereference chip->bus pointer.

The problem is we alloc chip->bus in azx_codec_create
which will be called after we enable IRQ and enable unsolicited
event in azx_probe.

This will cause Oops due dereference NULL pointer. I meet it, good luck:)

Signed-off-by: Wang YanQing 
---
 sound/pci/hda/hda_codec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 622f726..9c76752 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -618,6 +618,9 @@ int snd_hda_queue_unsol_event(struct hda_bus *bus, u32 res, 
u32 res_ex)
unsigned int wp;
 
trace_hda_unsol_event(bus, res, res_ex);
+   if (!bus)
+   return 0;
+
unsol = bus->unsol;
if (!unsol)
return 0;
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH]TTY: Fix tty can't be restarted by TCXONC ioctl request

[Wang YanQing]

I meet emacs hang in start if I do the operation below:
  1: echo 3 > /proc/sys/vm/drop_caches
  2: emacs BigFile
  3: Press CTRL-S follow 2 immediately

Then emacs hang on, CTRL-Q can't resume, the terminal
hang on, you can do nothing with this terminal except
close it.

The reason is before emacs takeover control the tty,
we use CTRL-S to XOFF it. Then when emacs takeover the
control, it may don't use the flow-control, so emacs hang.
But after search the emacs's startup codes, I find they use TCXONC
to workaround this situation:

  /* This code added to insure that, if flow-control is not to be used,
 we have an unlocked terminal at the start. */
  if (!tty_out->flow_control) ioctl (fileno (tty_out->input), TCXONC, 1);
  ioctl (fileno (tty_out->input), TCXONC, 1);

But this workaround never work due the kernel's current code.
This patch fix it.

Below is the ChangeLog introduce the tty->flow_stopped flag:

Thu Nov 21 10:05:22 1996  Theodre Ts'o  

   * tty_ioctl.c (tty_wait_until_sent): Always check the driver
   wait_until_ready routine, even if there are no characters
   in the xmit buffer.  (There may be charactes in the device
   FIFO.)
   (n_tty_ioctl): Add new flag tty->flow_stopped which
   indicates whether the tty is stopped due to a request by
   the TCXONC ioctl (used by tcflow).  If so, don't let an
   incoming XOFF character restart the tty.  The tty can only
   be restarted by another TCXONC request.

So I think this patch make TCXONC can restart tty which stopped by
STOP_CHAR don't break the original meaning.

This patch will fix some strange tty relation hang problem,
I believe I meet it with vim in ssh, and also see below bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823

Signed-off-by: Wang YanQing 
---
 drivers/tty/tty_ioctl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index e4455e0..42e08e5 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1129,11 +1129,12 @@ int n_tty_ioctl_helper(struct tty_struct *tty, struct 
file *file,
case TCOOFF:
if (!tty->flow_stopped) {
tty->flow_stopped = 1;
-   stop_tty(tty);
+   if (!tty->stopped)
+   stop_tty(tty);
}
break;
case TCOON:
-   if (tty->flow_stopped) {
+   if (tty->flow_stopped || tty->stopped) {
tty->flow_stopped = 0;
start_tty(tty);
}
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]TTY: Fix tty can't be restarted by TCXONC ioctl request

[Wang YanQing]

On Tue, May 07, 2013 at 11:58:00AM -0700, Greg KH wrote:
> On Wed, May 08, 2013 at 02:47:34AM +0800, Wang YanQing wrote:
> > The reason is before emacs takeover control the tty,
> > we use CTRL-S to XOFF it. Then when emacs takeover the
> > control, it may don't use the flow-control, so emacs hang.
> > But after search the emacs's startup codes, I find they use TCXONC
> > to workaround this situation:
> > 
> >   /* This code added to insure that, if flow-control is not to be used,
> >  we have an unlocked terminal at the start. */
> >   if (!tty_out->flow_control) ioctl (fileno (tty_out->input), TCXONC, 1);
> >   ioctl (fileno (tty_out->input), TCXONC, 1);

The second line of ioctl:
"ioctl (fileno (tty_out->input), TCXONC, 1);"

It is not there in emacs' code, I add it for debuging, and forget to
delete it.
Greg KH, could you delete it from ChangeLog if you accept this patch?


> > But this workaround never work due the kernel's current code.
> > This patch fix it.
> > 
> > Below is the ChangeLog introduce the tty->flow_stopped flag:
> > 
> > Thu Nov 21 10:05:22 1996  Theodre Ts'o  
> > 
> >* tty_ioctl.c (tty_wait_until_sent): Always check the driver
> >wait_until_ready routine, even if there are no characters
> >in the xmit buffer.  (There may be charactes in the device
> >FIFO.)
> >(n_tty_ioctl): Add new flag tty->flow_stopped which
> >indicates whether the tty is stopped due to a request by
> >the TCXONC ioctl (used by tcflow).  If so, don't let an
> >incoming XOFF character restart the tty.  The tty can only
> >be restarted by another TCXONC request.
> > 
> > So I think this patch make TCXONC can restart tty which stopped by
> > STOP_CHAR don't break the original meaning.
> > 
> > This patch will fix some strange tty relation hang problem,
> > I believe I meet it with vim in ssh, and also see below bug report:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823
> 
> So this has been a problem since 1996?  Or is it newly introduced due to
> some changes in this area in a newer kernel?

I have tested the v2.6.32.45, and have the same issue, my current environment
can't compile and test v2.6.24/v2.6.25, due make version maybe.

But after explore history codes, I want to say,
yes, this issue since 1996 that we can't use TCXONC 
to restart tty which be stopped by STOP_CHAR.

Kernel process the STOP_CHAR/START_CHAR to implement 
flow control, but userspace should have methold to 
START/STOP it by ioctl or others' similar positive method
which don't depend on another side, that's TCXONC.

According http://en.wikibooks.org/wiki/Serial_Programming/termio

"
TCXONC
Start or stop the output. 
"

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]TTY: Fix tty can't be restarted by TCXONC ioctl request

[Wang YanQing]

On Tue, May 07, 2013 at 04:50:05PM -0400, Peter Hurley wrote:
> This should be fixed in n_tty_set_termios() instead of fixing userspace
> workarounds.

Sorry, I misuse the word "workaround", emacs just do the right thing I think.
But your suggestion maybe import policy.

> The problem occurs when the tty has been stopped with STOP_CHAR(tty) and then
> termios is changed so that START_CHAR(tty) is subsequently ignored
> (in the reported case, I_IXON(tty) is cleared).
> 
That's right.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]TTY: Fix tty can't be restarted by TCXONC ioctl request

[Wang YanQing]

On Tue, May 07, 2013 at 07:02:00PM -0700, Greg KH wrote:
> What about Peter's comments on this patch?
> 
Peter's comments will import policy,

I means we should let userspace to decide whether
and when to restart tty with the mechanism of TCXONC
instead of restart tty accidental when make n_tty_set_termios
call.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]TTY: Fix tty can't be restarted by TCXONC ioctl request

[Wang YanQing]

On Wed, May 08, 2013 at 11:18:07AM -0400, Peter Hurley wrote:
> On 05/08/2013 09:16 AM, Wang YanQing wrote:
> > On Tue, May 07, 2013 at 07:02:00PM -0700, Greg KH wrote:
> >> What about Peter's comments on this patch?
> >>
> > Peter's comments will import policy,
> >
> > I means we should let userspace to decide whether
> > and when to restart tty with the mechanism of TCXONC
> > instead of restart tty accidental when make n_tty_set_termios
> > call.
> 
> There would be no accidental restart. Userspace is specifically
> disabling user-controlled output flow control by clearing
> IXON in termios. Userspace is _expecting_ a 'started' tty.
> 
> If you insist that this must be controllable from userspace,
> then that is already possible:
> 
>   tcflow(fd, TCOOFF);
>   tcflow(fd, TCOON);

Indeed you can't do what you said with TCOOFF and TCOON
if you read the codes, that's what this patch fix.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/9] Convert all to the caller hold lock version

[Wang YanQing]

After commit 50e244cc793d511b86adea24972f3a7264cae114 
 (fb: rework locking to fix lock ordering on takeover)
and 
 commit e93a9a868792ad71cdd09d75e5a02d8067473c4e
 (fb: Yet another band-aid for fixing lockdep mess)

We have two version functions implement almost the same function,
except the caller/callee hold lock.

fbcon_takeover vs do_fbcon_takeover
register_con_driver vs do_register_con_driver
take_over_console vs do_take_over_console
unbind_con_driver vs do_unbind_con_driver
bind_con_driver vs do_bind_con_driver
unregister_con_driver vs do_unregister_con_driver

This issue bring us much code duplication,
like do_fbcon_takeover and fbcon_takeover,
they have almost the same.

Although some of them had been re-written 
as a wrapper for another, but the wrapper
is so trivial, we can just throw them away.

Also those two versions of almost the same
functions will confuse API's user.

After all, I think this issue is not good
for long time maintain.

This series patch convert all to the
new version which caller hold the lock,
and then delete the old version away.

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/9] fbcon: convert last fbcon_takeover call to do_fbcon_takeover

[Wang YanQing]

After commit 054430e773c9a1e26f38e30156eff02dedfffc17 (fbcon: fix locking 
harder),
there is only one place use do_fbcon_takeover now, this patch
convert it to do_fbcon_takeover too, then we can delete
fbcon_takeover whos function can be achieved with do_fbcon_takeover
easily to reduce code size and duplication.

Signed-off-by: Wang YanQing 
---
 drivers/video/console/fbcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 3cd6759..1660644 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3541,8 +3541,9 @@ static void fbcon_start(void)
}
}
 
+   do_fbcon_takeover(0);
console_unlock();
-   fbcon_takeover(0);
+
}
 }
 
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/9] fbcon: delete unneeded function fbcon_takeover

[Wang YanQing]

Now there is no place use fbcon_takeover, and
fbcon_takeover has huge duplication code with
do_fbcon_takeover, we can achieve fbcon_takeover's
function with do_fbcon_takeover easily, so we
can just delete it.

Signed-off-by: Wang YanQing 
---
 drivers/video/console/fbcon.c | 28 
 1 file changed, 28 deletions(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 1660644..47b9353 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -556,34 +556,6 @@ static int do_fbcon_takeover(int show_logo)
return err;
 }
 
-static int fbcon_takeover(int show_logo)
-{
-   int err, i;
-
-   if (!num_registered_fb)
-   return -ENODEV;
-
-   if (!show_logo)
-   logo_shown = FBCON_LOGO_DONTSHOW;
-
-   for (i = first_fb_vc; i <= last_fb_vc; i++)
-   con2fb_map[i] = info_idx;
-
-   err = take_over_console(&fb_con, first_fb_vc, last_fb_vc,
-   fbcon_is_default);
-
-   if (err) {
-   for (i = first_fb_vc; i <= last_fb_vc; i++) {
-   con2fb_map[i] = -1;
-   }
-   info_idx = -1;
-   } else {
-   fbcon_has_console_bind = 1;
-   }
-
-   return err;
-}
-
 #ifdef MODULE
 static void fbcon_prepare_logo(struct vc_data *vc, struct fb_info *info,
   int cols, int rows, int new_cols, int new_rows)
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/9] vt: delete unneeded functions register_con_driver|take_over_console

[Wang YanQing]

Now there is no place use register_con_driver|take_over_console,
and we can achieve their function with do_register_con_driver|
do_take_over_console easily, so just delete them to reduce code duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c | 45 -
 include/linux/console.h |  2 --
 2 files changed, 47 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index fbd447b..852d470 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3576,26 +3576,6 @@ err:
return retval;
 }
 
-/**
- * register_con_driver - register console driver to console layer
- * @csw: console driver
- * @first: the first console to take over, minimum value is 0
- * @last: the last console to take over, maximum value is MAX_NR_CONSOLES -1
- *
- * DESCRIPTION: This function registers a console driver which can later
- * bind to a range of consoles specified by @first and @last. It will
- * also initialize the console driver by calling con_startup().
- */
-int register_con_driver(const struct consw *csw, int first, int last)
-{
-   int retval;
-
-   console_lock();
-   retval = do_register_con_driver(csw, first, last);
-   console_unlock();
-   return retval;
-}
-EXPORT_SYMBOL(register_con_driver);
 
 /**
  * unregister_con_driver - unregister console driver from console layer
@@ -3677,30 +3657,6 @@ int do_take_over_console(const struct consw *csw, int 
first, int last, int deflt
 }
 EXPORT_SYMBOL_GPL(do_take_over_console);
 
-/*
- * If we support more console drivers, this function is used
- * when a driver wants to take over some existing consoles
- * and become default driver for newly opened ones.
- *
- * take_over_console is basically a register followed by unbind
- */
-int take_over_console(const struct consw *csw, int first, int last, int deflt)
-{
-   int err;
-
-   err = register_con_driver(csw, first, last);
-   /*
-* If we get an busy error we still want to bind the console driver
-* and return success, as we may have unbound the console driver
-* but not unregistered it.
-*/
-   if (err == -EBUSY)
-   err = 0;
-   if (!err)
-   bind_con_driver(csw, first, last, deflt);
-
-   return err;
-}
 
 /*
  * give_up_console is a wrapper to unregister_con_driver. It will only
@@ -4264,6 +4220,5 @@ EXPORT_SYMBOL(console_blanked);
 EXPORT_SYMBOL(vc_cons);
 EXPORT_SYMBOL(global_cursor_default);
 #ifndef VT_SINGLE_DRIVER
-EXPORT_SYMBOL(take_over_console);
 EXPORT_SYMBOL(give_up_console);
 #endif
diff --git a/include/linux/console.h b/include/linux/console.h
index 29680a8..c2b2d45 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -75,10 +75,8 @@ extern const struct consw newport_con;   /* SGI Newport 
console  */
 extern const struct consw prom_con;/* SPARC PROM console */
 
 int con_is_bound(const struct consw *csw);
-int register_con_driver(const struct consw *csw, int first, int last);
 int unregister_con_driver(const struct consw *csw);
 int do_unregister_con_driver(const struct consw *csw);
-int take_over_console(const struct consw *sw, int first, int last, int deflt);
 int do_take_over_console(const struct consw *sw, int first, int last, int 
deflt);
 void give_up_console(const struct consw *sw);
 #ifdef CONFIG_HW_CONSOLE
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/9] vt: convert last unbind_con_driver call to do_unbind_con_driver

[Wang YanQing]

There is only one place use unbind_con_driver, this patch
convert it to do_unbind_con_driver too, then we can delete
unbind_con_driver to reduce code size and duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 852d470..a422322 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3303,8 +3303,11 @@ static int vt_unbind(struct con_driver *con)
if (first == 0 && last == MAX_NR_CONSOLES -1)
deflt = 1;
 
-   if (first != -1)
-   unbind_con_driver(csw, first, last, deflt);
+   if (first != -1) {
+   console_lock();
+   do_unbind_con_driver(csw, first, last, deflt);
+   console_unlock();
+   }
 
first = -1;
last = -1;
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/9] vt: convert last bind_con_driver call to do_bind_con_driver

[Wang YanQing]

There is only one place use bind_con_driver now, this patch
convert it to do_bind_con_driver too, then we can delete
bind_con_driver whos function can be replaced by do_bind_con_driver
easily to reduce code size and duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 164cbef..7e0953c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3236,8 +3236,11 @@ static int vt_bind(struct con_driver *con)
if (first == 0 && last == MAX_NR_CONSOLES -1)
deflt = 1;
 
-   if (first != -1)
-   bind_con_driver(csw, first, last, deflt);
+   if (first != -1) {
+   console_lock();
+   do_bind_con_driver(csw, first, last, deflt);
+   console_unlock();
+   }
 
first = -1;
last = -1;
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/9] vt: delete unneeded function bind_con_driver

[Wang YanQing]

Now there is no place use bind_con_driver,
and do_bind_con_driver can achieve bind_con_driver's
function easily, so just delete it to reduce code size and
duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 7e0953c..d5bfa86 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3088,17 +3088,6 @@ err:
 };
 
 
-static int bind_con_driver(const struct consw *csw, int first, int last,
-  int deflt)
-{
-   int ret;
-
-   console_lock();
-   ret = do_bind_con_driver(csw, first, last, deflt);
-   console_unlock();
-   return ret;
-}
-
 #ifdef CONFIG_VT_HW_CONSOLE_BINDING
 static int con_is_graphics(const struct consw *csw, int first, int last)
 {
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/9] fbcon: convert last two unregister_con_driver call to do_unregister_con_driver

[Wang YanQing]

There are only two place use unregister_con_driver now, this patch
convert them to do_unregister_con_driver too, then we can delete
unregister_con_driver whos function can be achieved with 
do_unregister_con_driver
easily to reduce code size and duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c   | 4 +++-
 drivers/video/console/fbcon.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d5bfa86..8f4a71a 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3631,7 +3631,9 @@ EXPORT_SYMBOL_GPL(do_take_over_console);
  */
 void give_up_console(const struct consw *csw)
 {
-   unregister_con_driver(csw);
+   console_lock();
+   do_unregister_con_driver(csw);
+   console_unlock();
 }
 
 static int __init vtconsole_class_init(void)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 47b9353..e0dd275 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3619,8 +3619,8 @@ static void __exit fb_console_exit(void)
fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
fbcon_exit();
+   do_unregister_con_driver(&fb_con);
console_unlock();
-   unregister_con_driver(&fb_con);
 }  
 
 module_exit(fb_console_exit);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 9/9] vt: delete unneeded function unregister_con_driver

[Wang YanQing]

Now there is no place use unregister_con_driver,
and we can achieve unregister_con_driver's function
with unregister_con_driver easily, so just delete it
to reduce code size and duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c | 13 +
 include/linux/console.h |  1 -
 2 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8f4a71a..405e1c9 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3545,7 +3545,7 @@ err:
 
 
 /**
- * unregister_con_driver - unregister console driver from console layer
+ * do_unregister_con_driver - unregister console driver from console layer
  * @csw: console driver
  *
  * DESCRIPTION: All drivers that registers to the console layer must
@@ -3555,17 +3555,6 @@ err:
  *
  * The driver must unbind first prior to unregistration.
  */
-int unregister_con_driver(const struct consw *csw)
-{
-   int retval;
-
-   console_lock();
-   retval = do_unregister_con_driver(csw);
-   console_unlock();
-   return retval;
-}
-EXPORT_SYMBOL(unregister_con_driver);
-
 int do_unregister_con_driver(const struct consw *csw)
 {
int i, retval = -ENODEV;
diff --git a/include/linux/console.h b/include/linux/console.h
index c2b2d45..cbe59c3 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -75,7 +75,6 @@ extern const struct consw newport_con;/* SGI Newport 
console  */
 extern const struct consw prom_con;/* SPARC PROM console */
 
 int con_is_bound(const struct consw *csw);
-int unregister_con_driver(const struct consw *csw);
 int do_unregister_con_driver(const struct consw *csw);
 int do_take_over_console(const struct consw *sw, int first, int last, int 
deflt);
 void give_up_console(const struct consw *sw);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/9] vt: delete unneeded function unbind_con_driver

[Wang YanQing]

Now there is no place use unbind_con_driver,
and we can achieve unbind_con_driver's function
with do_unbind_con_driver easily, so just delete
it to reduce code size and duplication.

Signed-off-by: Wang YanQing 
---
 drivers/tty/vt/vt.c | 28 
 include/linux/vt_kern.h |  2 --
 2 files changed, 30 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index a422322..164cbef 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3116,34 +3116,6 @@ static int con_is_graphics(const struct consw *csw, int 
first, int last)
return retval;
 }
 
-/**
- * unbind_con_driver - unbind a console driver
- * @csw: pointer to console driver to unregister
- * @first: first in range of consoles that @csw should be unbound from
- * @last: last in range of consoles that @csw should be unbound from
- * @deflt: should next bound console driver be default after @csw is unbound?
- *
- * To unbind a driver from all possible consoles, pass 0 as @first and
- * %MAX_NR_CONSOLES as @last.
- *
- * @deflt controls whether the console that ends up replacing @csw should be
- * the default console.
- *
- * RETURNS:
- * -ENODEV if @csw isn't a registered console driver or can't be unregistered
- * or 0 on success.
- */
-int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
-{
-   int retval;
-
-   console_lock();
-   retval = do_unbind_con_driver(csw, first, last, deflt);
-   console_unlock();
-   return retval;
-}
-EXPORT_SYMBOL(unbind_con_driver);
-
 /* unlocked version of unbind_con_driver() */
 int do_unbind_con_driver(const struct consw *csw, int first, int last, int 
deflt)
 {
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index e8d6571..adc7ff5 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -133,8 +133,6 @@ void change_console(struct vc_data *new_vc);
 void reset_vc(struct vc_data *vc);
 extern int do_unbind_con_driver(const struct consw *csw, int first, int last,
 int deflt);
-extern int unbind_con_driver(const struct consw *csw, int first, int last,
-int deflt);
 int vty_init(const struct file_operations *console_fops);
 
 static inline bool vt_force_oops_output(struct vc_data *vc)
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]TTY: Fix tty can't be restarted by TCXONC ioctl request

[Wang YanQing]

On Wed, May 08, 2013 at 02:32:23PM -0400, Peter Hurley wrote:
> Perhaps you misunderstood. The snippet above does indeed restart
> a tty which has been stopped via STOP_CHAR(tty) and the termios
> IXON flag cleared.

Thanks Peter, I get your meaning, and I think your suggestion
is right, not only because your reason, but also I find
this patch change the user interface behavior silently,
it will cause data lost or others' undesired behavior if
TCXONC restart tty but another side is not ready, it is bad.

I will send the V2.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] TTY: Fix tty miss restart after we turn off flow-control

[Wang YanQing]

I meet emacs hang in start if I do the operation below:
  1: echo 3 > /proc/sys/vm/drop_caches
  2: emacs BigFile
  3: Press CTRL-S follow 2 immediately

Then emacs hang on, CTRL-Q can't resume, the terminal
hang on, you can do nothing with this terminal except
close it.

The reason is before emacs takeover control the tty,
we use CTRL-S to XOFF it. Then when emacs takeover the
control, it may don't use the flow-control, so emacs hang.
This patch fix it.

This patch will fix a kind of strange tty relation hang problem,
I believe I meet it with vim in ssh, and also see below bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823

Signed-off-by: Wang YanQing 
---
 Changes v1-v2:
 1: move the fix into n_tty_set_termios instead of change TCXONC's behavior 
suggested by Peter Hurley
 2: rewrite some ChangeLog and use more reasonable subject.

 drivers/tty/n_tty.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 05e72be..5510b32 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1588,6 +1588,14 @@ static void n_tty_set_termios(struct tty_struct *tty, 
struct ktermios *old)
ldata->real_raw = 0;
}
n_tty_set_room(tty);
+   /*
+* Fix tty hang when I_IXON(tty) is cleared, but the tty
+* been stopped by STOP_CHAR(tty) before it.
+*/
+   if (!I_IXON(tty) && (old->c_iflag & IXON) && !tty->flow_stopped) {
+   start_tty(tty);
+   }
+
/* The termios change make the tty ready for I/O */
wake_up_interruptible(&tty->write_wait);
wake_up_interruptible(&tty->read_wait);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] TTY: Fix tty miss restart after we turn off flow-control

[Wang YanQing]

I meet emacs hang in start if I do the operation below:
  1: echo 3 > /proc/sys/vm/drop_caches
  2: emacs BigFile
  3: Press CTRL-S follow 2 immediately

Then emacs hang on, CTRL-Q can't resume, the terminal
hang on, you can do nothing with this terminal except
close it.

The reason is before emacs takeover control the tty,
we use CTRL-S to XOFF it. Then when emacs takeover the
control, it may don't use the flow-control, so emacs hang.
This patch fix it.

This patch will fix a kind of strange tty relation hang problem,
I believe I meet it with vim in ssh, and also see below bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465823

Signed-off-by: Wang YanQing 
---
 Changes v1-v2:
 1: move the fix into n_tty_set_termios instead of change TCXONC's behavior 
suggested by Peter Hurley
 2: rewrite some ChangeLog and use more reasonable subject.
 Changes v2-v3:
 1: Fix potential NULL pointer dereference.

 drivers/tty/n_tty.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 19083ef..9365978 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1587,6 +1587,14 @@ static void n_tty_set_termios(struct tty_struct *tty, 
struct ktermios *old)
ldata->real_raw = 0;
}
n_tty_set_room(tty);
+   /*
+* Fix tty hang when I_IXON(tty) is cleared, but the tty
+* been stopped by STOP_CHAR(tty) before it.
+*/
+   if (!I_IXON(tty) && old && (old->c_iflag & IXON) && !tty->flow_stopped) 
{
+   start_tty(tty);
+   }
+
/* The termios change make the tty ready for I/O */
wake_up_interruptible(&tty->write_wait);
wake_up_interruptible(&tty->read_wait);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] kconfig: sort found symbols by relevance

[Wang YanQing]

On Mon, May 06, 2013 at 11:15:31PM +0200, Yann E. MORIN wrote:
> From: "Yann E. MORIN" 
> 
> When searching for symbols, return the symbols sorted by relevance.
> 
> Sorting is done as thus:
>   - first, symbols with a prompt,   [1]
>   - then, smallest offset,  [2]
>   - then, shortest match,   [3]
>   - then, highest relative match,   [4]
>   - finally, alphabetical sort  [5]
> 
> So, searching (eg.) for 'P.*CI' :
> 
> [1] Symbols of interest are probably those with a prompt, as they can be
> changed, while symbols with no prompt are only for info. Thus:
> PCIEASPM comes before PCI_ATS

Search the value of symbols with no prompt are useful too

> [2] Symbols that match earlier in the name are to be preferred over
> symbols which match later. Thus:
> PCI_MSI comes before WDTPCI

We can achieve this with ^PCI regular search

> [3] The shortest match is (IMHO) more interesting than a longer one.
> Thus:
> PCI comes before PCMCIA

We can achieve this with ^PCI regular search plus your previous heuristic

> [4] The relative match is the ratio of the length of the match against
> the length of the symbol. The more of a symbol name we match, the
> more instersting that symbol is. Thus:
> PCIEAER comes before PCIEASPM

This is what your first heuristic

> [5] As fallback, sort symbols alphabetically
This is in your first heuristic too.

> This heuristic tries hard to get interesting symbols first in the list.
I don't mean your this heuristic is bad, but
maybe provide mechanism to user will make guesser life easier.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] kconfig: sort found symbols by relevance

[Wang YanQing]

On Thu, May 09, 2013 at 06:12:17PM +0200, Yann E. MORIN wrote:
> Wang, All,
> 
> On Thu, May 09, 2013 at 11:27:31PM +0800, Wang YanQing wrote:
> > On Mon, May 06, 2013 at 11:15:31PM +0200, Yann E. MORIN wrote:
> > > From: "Yann E. MORIN" 
> > > 
> > > When searching for symbols, return the symbols sorted by relevance.
> > > 
> > > Sorting is done as thus:
> > >   - first, symbols with a prompt,   [1]
> > >   - then, smallest offset,  [2]
> > >   - then, shortest match,   [3]
> > >   - then, highest relative match,   [4]
> > >   - finally, alphabetical sort  [5]
> > > 
> > > So, searching (eg.) for 'P.*CI' :
> > > 
> > > [1] Symbols of interest are probably those with a prompt, as they can be
> > > changed, while symbols with no prompt are only for info. Thus:
> > > PCIEASPM comes before PCI_ATS
> > 
> > Search the value of symbols with no prompt are useful too
> 
> My reasonning here is that often I need to toggle a symbol, but am not
> sure what menu it's in, so I search for it.
> 
> Sometime, I also need to search for prompt-less symbols, too, to see why
> a symbol I want is not visible. But that's not the most common use-case.
> 
> Also, the examples provided were with a very verbose search: 'P.*CI'
> which is expected to return a hell of a lot of symbols. More precise
> searches will yield substancially fewer symbols, so the search results
> will probably fit in 1 or 2 pages, not 10+ like 'P.*CI'
> 
> > > [2] Symbols that match earlier in the name are to be preferred over
> > > symbols which match later. Thus:
> > > PCI_MSI comes before WDTPCI
> > 
> > We can achieve this with ^PCI regular search
> 
> Yes, but I expect users do enter the begining of symbols, not a string
> in the middle or at the end.
> 
> Also, as Jean and Thomas have proven, not many people know that searches
> can be regular expressions.

Ok, indeed, I don't know regular expression in menuconfig before you
point it out :)

> > > [3] The shortest match is (IMHO) more interesting than a longer one.
> > > Thus:
> > > PCI comes before PCMCIA
> > 
> > We can achieve this with ^PCI regular search plus your previous heuristic
> 
> This one is not about location of the match, it's about the length of
> the match: the shortest the match, the more interesting it is (IMHO). So
> we'd prefer FOO_PCI_BAR_BUZ over A_PACI_B  (when searching for 'P.*CI').

Ok, I get your meaning.

> > > [4] The relative match is the ratio of the length of the match against
> > > the length of the symbol. The more of a symbol name we match, the
> > > more instersting that symbol is. Thus:
> > > PCIEAER comes before PCIEASPM
> > 
> > This is what your first heuristic
> > 
> > > [5] As fallback, sort symbols alphabetically
> > This is in your first heuristic too.
> > 
> > > This heuristic tries hard to get interesting symbols first in the list.
> > I don't mean your this heuristic is bad, but
> 
> This heuristic is just that: a heuristic. It kicks in only if the user
> dit not provide an anchored regexp (ie with start- or end-of-line).
> 
> For the ten-or-so tests I did, the sorting was rather appropriate,
> though that's only ten-or-so tests and is not exhaustive (and probably
> subject to testing bias, too).

I hope more people will find the sorting is appropriate if Michal Marek accept 
it :)

> What I'm trying to achieve here is come up with a way to sort symbols
> for searches of *non-anchored* regexps. Anchored regexps will always
> provide the results they used to provide so far.
> 
> Maybe we can emphasize in the UI the fact that regexps, and especially
> anchored regexps, can be used.
> 
> > maybe provide mechanism to user will make guesser life easier.
> 
> Sorry, I can't make sense of this sentence. :-( Can you elaborate a bit
> what you meant, please?

The mechanism means first heuristic in previous Email patch.

I though we could get this heuristic's result by composite your first heuristic
in previous Email patch with regular expression, it seams like I lost something,
see above.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] x86: reserve_crashkernel: use memblock_is_region_reserved to simplify code

[Wang YanQing]

Use memblock_is_region_reserved instead of memblock_find_in_range
to simplify the check codes, and gain a little speed benefit.

Signed-off-by: Wang YanQing 
---
 arch/x86/kernel/setup.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90d8cc9..9d60c85 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -577,11 +577,7 @@ static void __init reserve_crashkernel(void)
}
 
} else {
-   unsigned long long start;
-
-   start = memblock_find_in_range(crash_base,
-crash_base + crash_size, crash_size, 1<<20);
-   if (start != crash_base) {
+   if (memblock_is_region_reserved(crash_base, crash_size)) {
pr_info("crashkernel reservation failed - memory is in 
use.\n");
return;
}
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] x86:aperture_64: code pattern clean

[Wang YanQing]

This patch don't change code function,
it just do prepare for import the
memblock_alloc_in_range to do the code pattern
which looks like below in one function:

memblock_find_in_range()
follow by
memblock_reserve()

Signed-off-by: Wang YanQing 
---
 arch/x86/kernel/aperture_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index d5fd66f..1523e75 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -85,9 +85,9 @@ static u32 __init allocate_aperture(void)
 * memory. Unfortunately we cannot move it up because that would
 * make the IOMMU useless.
 */
-   addr = memblock_find_in_range(GART_MIN_ADDR, GART_MAX_ADDR,
+   addr = memblock_find_in_range(GART_MIN_ADDR, GART_MAX_ADDR - aper_size,
  aper_size, aper_size);
-   if (!addr || addr + aper_size > GART_MAX_ADDR) {
+   if (!addr) {
printk(KERN_ERR
"Cannot allocate aperture memory hole (%lx,%uK)\n",
addr, aper_size>>10);
-- 
1.7.12.4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/