* [PATCH v2 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Rajendra Nayak @ 2011-11-22 13:44 UTC (permalink / raw)
To: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: khilman-l0cyMroinI0, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
patches-QSEj5FYQhm4dnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
Rajendra Nayak, govindraj.raja-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1321969456-24266-1-git-send-email-rnayak-l0cyMroinI0@public.gmane.org>
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
Signed-off-by: Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/omap3.dtsi | 31 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 28 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 1 -
3 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..216c331 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ serial3 = &uart4;
+ };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +66,29 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ uart1: serial@0x4806a000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ clock-frequency = <48000000>;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ clock-frequency = <48000000>;
+ };
+
+ uart3: serial@0x49020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ clock-frequency = <48000000>;
+ };
+
+ uart4: serial@0x49042000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..e8fe75f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ serial3 = &uart4;
};
cpus {
@@ -99,5 +103,29 @@
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
+
+ uart1: serial@0x4806a000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart1";
+ clock-frequency = <48000000>;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart2";
+ clock-frequency = <48000000>;
+ };
+
+ uart3: serial@0x48020000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart3";
+ clock-frequency = <48000000>;
+ };
+
+ uart4: serial@0x4806e000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
};
};
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index fb55fa3..bb72809 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -70,7 +70,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
- omap_serial_init();
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
--
1.7.1
^ permalink raw reply related
* [PATCH v2 2/4] omap-serial: Use default clock speed (48Mhz) if not specified
From: Rajendra Nayak @ 2011-11-22 13:44 UTC (permalink / raw)
To: linux-serial, linux-omap, devicetree-discuss
Cc: tony, khilman, govindraj.raja, b-cousson, linux-arm-kernel,
linaro-dev, patches, robherring2, Rajendra Nayak
In-Reply-To: <1321969456-24266-1-git-send-email-rnayak@ti.com>
Use a default clock speed of 48Mhz, instead of ending up with 0,
if platforms fail to specify a valid clock speed.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/tty/serial/omap-serial.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a02cc9f..f14b9c5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,8 @@
#include <plat/dmtimer.h>
#include <plat/omap-serial.h>
+#define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1386,6 +1388,11 @@ static int serial_omap_probe(struct platform_device *pdev)
up->port.flags = omap_up_info->flags;
up->port.uartclk = omap_up_info->uartclk;
+ if (!up->port.uartclk) {
+ up->port.uartclk = DEFAULT_CLK_SPEED;
+ dev_warn(&pdev->dev, "No clock speed specified: using default:"
+ "%d\n", DEFAULT_CLK_SPEED);
+ }
up->uart_dma.uart_base = mem->start;
up->errata = omap_up_info->errata;
--
1.7.1
^ permalink raw reply related
* Re: [GIT PULL] ARM: amba: Enable module alias autogeneration for AMBA drivers
From: Alessandro Rubini @ 2011-11-22 15:19 UTC (permalink / raw)
To: dave.martin-QSEj5FYQhm4dnm+yROfE0A
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Pawel.Moll-5wv7dgnIgG8,
tiwai-l3A5Bk7waGM, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, perex-/Fr2/VpizcU,
wim-IQzOog9fTRqzQB+pC5nmwQ, julia-dAYI7NvHqcQ,
linux-lFZ/pmaqli7XmaaqVzeoHQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, cjb-2X9k7bc8m7Mdnm+yROfE0A,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw, patches-QSEj5FYQhm4dnm+yROfE0A,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alan-VuQAYsv1563Yd54FQh9/CA, a.zummo-BfzFCNDTiLLj+vYz1yj4TQ,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
lethal-M7jkjyW5wf5g9hUCZPvPmw,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111122120756.GF2066-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
>> lkml.org/lkml/2011/11/4/125 (0/2: description of the work)
>> lkml.org/lkml/2011/11/4/126 (1/2: turn the if plethora to table lookup)
>> lkml.org/lkml/2011/11/4/127 (2/2: partial split to type-specific files).
>
> Splitting this up doesn't look like a silly idea -- I thought it was
> unfortunate to have to patch a core file just to add a bus type.
>
> I guess the question is how many new buses we get over time.
Well, CERN will have 2 in a short time. And I'm sure the bus concept
is so good that a number of them exists as external patches. Being
forced to patch a core file is not good, with conflicts that accumulate
over time.
I'd better be able to drop in my own file and add a kconfig-aware line
in Makefile. I think the implementation is straightforward. Who should
I send it to?
thanks
/alessandro
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
^ permalink raw reply
* Re: [GIT PULL] ARM: amba: Enable module alias autogeneration for AMBA drivers
From: Greg KH @ 2011-11-22 19:20 UTC (permalink / raw)
To: Alessandro Rubini
Cc: dave.martin, Pawel.Moll, tiwai, linus.walleij, alsa-devel,
grant.likely, wim, julia, linux, vinod.koul, jassisinghbrar,
linux-serial, linux-input, cjb, linux-watchdog, rtc-linux,
patches, linux-fbdev, dan.j.williams, linux-arm-kernel, alan,
a.zummo, dmitry.torokhov, linux-mmc, linux-kernel, lethal,
spi-devel-general
In-Reply-To: <20111122115632.GA5165@mail.gnudd.com>
On Tue, Nov 22, 2011 at 12:56:32PM +0100, Alessandro Rubini wrote:
> > I have Acks on some of the driver patches and no comments on the
> > rest. I've been circulating these for some time, so if you're
> > happy to pull those driver patches via your tree, please go ahead.
>
> Sure I have no problem with the nomadik-rng.c, (so please have my
> Acked-by: -- sorry for not noting it earlier) but I think this
> file2alias thing needs a serious rework to split each bus in a
> different file, using ELF sections like we do elsewhere.
>
> I posted a patch last week but I got no comment at all. Maybe this
> is the time to ask for comments? I can rebase and repost if needed.
>
> lkml.org/lkml/2011/11/4/125 (0/2: description of the work)
> lkml.org/lkml/2011/11/4/126 (1/2: turn the if plethora to table lookup)
> lkml.org/lkml/2011/11/4/127 (2/2: partial split to type-specific files).
Ah, I missed that, yes, this would be a good thing to have, we've been
wanting it for _years_.
greg k-h
^ permalink raw reply
* [PATCH v3 0/2] KT serial controller IIR workaround
From: Dan Williams @ 2011-11-22 21:41 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, linux-serial, alan
Changes since v2 [1]:
* reflowed on tty-next (commit: 161e773c "UART: add CSR SiRFprimaII..."
* add a quirk to turn on msi to try to prevent shared interrupts
[1]: https://lkml.org/lkml/2011/11/15/264
---
Dan Williams (2):
serial/8250_pci: setup-quirk workaround for the kt serial controller
serial/8250_pci: init-quirk msi support for kt serial controller
drivers/tty/serial/8250.c | 4 +++-
drivers/tty/serial/8250_pci.c | 31 ++++++++++++++++++++++++++++++-
include/linux/serial_core.h | 1 +
3 files changed, 34 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v3 1/2] serial/8250_pci: setup-quirk workaround for the kt serial controller
From: Dan Williams @ 2011-11-22 21:41 UTC (permalink / raw)
To: gregkh; +Cc: Nhan H Mai, linux-kernel, linux-serial, alan
In-Reply-To: <20111122213859.13786.7738.stgit@localhost6.localdomain6>
Workaround dropped notifications in the iir register. Prevent reads
coincident with new interrupt notifications by reading the iir at most
once per interrupt.
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/tty/serial/8250.c | 4 +++-
drivers/tty/serial/8250_pci.c | 17 ++++++++++++++++-
include/linux/serial_core.h | 1 +
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250.c b/drivers/tty/serial/8250.c
index eeadf1b..3a8e5bf 100644
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -1619,11 +1619,13 @@ static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
do {
struct uart_8250_port *up;
struct uart_port *port;
+ bool skip;
up = list_entry(l, struct uart_8250_port, list);
port = &up->port;
+ skip = pass_counter && up->port.flags & UPF_IIR_ONCE;
- if (port->handle_irq(port)) {
+ if (!skip && port->handle_irq(port)) {
handled = 1;
end = NULL;
} else if (end == NULL)
diff --git a/drivers/tty/serial/8250_pci.c b/drivers/tty/serial/8250_pci.c
index 825937a..8742ef5 100644
--- a/drivers/tty/serial/8250_pci.c
+++ b/drivers/tty/serial/8250_pci.c
@@ -1092,6 +1092,14 @@ static int skip_tx_en_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
+static int kt_serial_setup(struct serial_private *priv,
+ const struct pciserial_board *board,
+ struct uart_port *port, int idx)
+{
+ port->flags |= UPF_IIR_ONCE;
+ return skip_tx_en_setup(priv, board, port, idx);
+}
+
static int pci_eg20t_init(struct pci_dev *dev)
{
#if defined(CONFIG_SERIAL_PCH_UART) || defined(CONFIG_SERIAL_PCH_UART_MODULE)
@@ -1110,7 +1118,6 @@ pci_xr17c154_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
-/* This should be in linux/pci_ids.h */
#define PCI_VENDOR_ID_SBSMODULARIO 0x124B
#define PCI_SUBVENDOR_ID_SBSMODULARIO 0x124B
#define PCI_DEVICE_ID_OCTPRO 0x0001
@@ -1136,6 +1143,7 @@ pci_xr17c154_setup(struct serial_private *priv,
#define PCI_DEVICE_ID_OXSEMI_16PCI958 0x9538
#define PCIE_DEVICE_ID_NEO_2_OX_IBM 0x00F6
#define PCI_DEVICE_ID_PLX_CRONYX_OMEGA 0xc001
+#define PCI_DEVICE_ID_INTEL_PATSBURG_KT 0x1d3d
/* Unknown vendors/cards - this should not be in linux/pci_ids.h */
#define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584
@@ -1220,6 +1228,13 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.subdevice = PCI_ANY_ID,
.setup = ce4100_serial_setup,
},
+ {
+ .vendor = PCI_VENDOR_ID_INTEL,
+ .device = PCI_DEVICE_ID_INTEL_PATSBURG_KT,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = kt_serial_setup,
+ },
/*
* ITE
*/
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 945e02c..b67305e 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -351,6 +351,7 @@ struct uart_port {
#define UPF_CONS_FLOW ((__force upf_t) (1 << 23))
#define UPF_SHARE_IRQ ((__force upf_t) (1 << 24))
#define UPF_EXAR_EFR ((__force upf_t) (1 << 25))
+#define UPF_IIR_ONCE ((__force upf_t) (1 << 26))
/* The exact UART type is known and should not be probed. */
#define UPF_FIXED_TYPE ((__force upf_t) (1 << 27))
#define UPF_BOOT_AUTOCONF ((__force upf_t) (1 << 28))
^ permalink raw reply related
* [PATCH v3 2/2] serial/8250_pci: init-quirk msi support for kt serial controller
From: Dan Williams @ 2011-11-22 21:41 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, linux-serial, alan
In-Reply-To: <20111122213859.13786.7738.stgit@localhost6.localdomain6>
The semantics of UPF_IIR_ONCE (once per serial irq) are only guaranteed
if the kt irq is not shared (once per serial isr in the shared case ==
potentially unwanted reads of the IIR).
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/tty/serial/8250_pci.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/8250_pci.c b/drivers/tty/serial/8250_pci.c
index 8742ef5..2cbf78f 100644
--- a/drivers/tty/serial/8250_pci.c
+++ b/drivers/tty/serial/8250_pci.c
@@ -1118,6 +1118,18 @@ pci_xr17c154_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
+static int try_enable_msi(struct pci_dev *dev)
+{
+ /* use msi if available, but fallback to legacy otherwise */
+ pci_enable_msi(dev);
+ return 0;
+}
+
+static void disable_msi(struct pci_dev *dev)
+{
+ pci_disable_msi(dev);
+}
+
#define PCI_VENDOR_ID_SBSMODULARIO 0x124B
#define PCI_SUBVENDOR_ID_SBSMODULARIO 0x124B
#define PCI_DEVICE_ID_OCTPRO 0x0001
@@ -1233,7 +1245,9 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_INTEL_PATSBURG_KT,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
+ .init = try_enable_msi,
.setup = kt_serial_setup,
+ .exit = disable_msi,
},
/*
* ITE
^ permalink raw reply related
* Re: [PATCH v3 0/2] KT serial controller IIR workaround
From: Alan Cox @ 2011-11-22 23:08 UTC (permalink / raw)
To: Dan Williams; +Cc: gregkh, linux-kernel, linux-serial
In-Reply-To: <20111122213859.13786.7738.stgit@localhost6.localdomain6>
On Tue, 22 Nov 2011 13:41:19 -0800
Dan Williams <dan.j.williams@intel.com> wrote:
> Changes since v2 [1]:
> * reflowed on tty-next (commit: 161e773c "UART: add CSR
> SiRFprimaII..."
> * add a quirk to turn on msi to try to prevent shared interrupts
>
> [1]: https://lkml.org/lkml/2011/11/15/264
>
> ---
>
> Dan Williams (2):
> serial/8250_pci: setup-quirk workaround for the kt serial
> controller serial/8250_pci: init-quirk msi support for kt serial
> controller
Series
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [PATCH 2/2] serial/mxs-auart: only wake up tty layer once
From: Alan Cox @ 2011-11-23 11:40 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: kernel, linux-serial
In-Reply-To: <1321968177-16039-2-git-send-email-u.kleine-koenig@pengutronix.de>
On Tue, 22 Nov 2011 14:22:56 +0100
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> There is no need to call uart_write_wakeup after each character send.
> Once at the end of the write sequence is enough.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Both parts
Acked-by: Alan Cox <alan@linux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] serial/mxs-auart: only wake up tty layer once
From: Uwe Kleine-König @ 2011-11-23 11:41 UTC (permalink / raw)
To: Alan Cox; +Cc: kernel, linux-serial
In-Reply-To: <20111123114033.62639253@bob.linux.org.uk>
On Wed, Nov 23, 2011 at 11:40:33AM +0000, Alan Cox wrote:
> On Tue, 22 Nov 2011 14:22:56 +0100
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>
> > There is no need to call uart_write_wakeup after each character send.
> > Once at the end of the write sequence is enough.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> Both parts
>
> Acked-by: Alan Cox <alan@linux.intel.com>
That means they should go via Sascha and/or Shawn?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] serial/mxs-auart: only wake up tty layer once
From: Alan Cox @ 2011-11-23 14:56 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: kernel, linux-serial
In-Reply-To: <20111123114133.GM19986@pengutronix.de>
> > Both parts
> >
> > Acked-by: Alan Cox <alan@linux.intel.com>
> That means they should go via Sascha and/or Shawn?
Probably simplest yes
^ permalink raw reply
* Re: [PATCH 0/8] serial: 8250: support hw-based RS485 direction control (finally!)
From: Wolfram Sang @ 2011-11-23 15:03 UTC (permalink / raw)
To: linux-serial
Cc: linux-kernel, Alan Cox, Claudio Scordino, Juergen Beisert,
Matthias Fuchs
In-Reply-To: <1321460685-15753-1-git-send-email-w.sang@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Wed, Nov 16, 2011 at 05:24:37PM +0100, Wolfram Sang wrote:
> Some 8250-variants control the direction pin for RS485 in hardware. Linux has
> RS485 support these days, so update the 8250-driver to adhere to that. There
> have been attempts for mainlining this before. So, I started with the version
> from Matthias which got no further comments, a proof-of-concept for the 16V2750
> from Jürgen, and reworked it to match the current state of RS485 in Linux. Some
> minor cleanup patches came along the way. Really looking forward to
> comments/tags, because I think it is really time to get this functionality into
> mainline once and for all ;)
Ping. Claudio? What do you think? Matthias, are you still there?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Kumar Gala @ 2011-11-24 8:14 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <1267212301-26851-1-git-send-email-paul.gortmaker@windriver.com>
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
> chips seems to cause a short lived IRQ storm (/proc/interrupts
> typically shows somewhere between 300 and 1500 events). Unfortunately
> this renders SysRQ over the serial console completely inoperable.
> Testing with obvious things like ACKing the event doesn't seem to
> change anything vs. a completely dumb approach of just ignoring
> it and waiting for it to stop, so that is what is implemented here.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> This is a refresh of a patch I'd done earlier -- I've tried to make
> the bug support as generic as possible to minimize having board
> specific ifdef crap in 8250.c -- any suggestions on how to further
> improve it are welcome.
>
> drivers/serial/8250.c | 6 ++++++
> drivers/serial/8250.h | 20 ++++++++++++++++++++
> drivers/serial/Kconfig | 14 ++++++++++++++
> include/linux/serial_reg.h | 2 ++
> 4 files changed, 42 insertions(+), 0 deletions(-)
Did we ever decide what to do with this or trying to get it accepted upstream?
- k
^ permalink raw reply
* [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-11-24 14:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-serial, linux-m68k, linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20111023141115.208699274@telegraphics.com.au>
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC interrupts at the chip but doesn't
ack them. Then when a pmac_zilog port is opened and SCC chip interrupts
become enabled, the machine locks up with "unexpected interrupt" because
request_irq() hasn't happened yet.
Fix this by setting the SCC master interrupt enable bit only after the
handler is installed. This is achieved by extracting that operation out of
__pmz_startup() and placing it into a seperate routine.
A similar problem arises when the irq is freed. Fix this by resetting the
chip first (on m68k mac).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This patch has been tested on a variety of m68k Macs but no PowerMacs.
I am re-sending this patch Cc linux-serial. It still needs a suitable ack
so that Geert can push it through his tree.
Index: linux-m68k/drivers/tty/serial/pmac_zilog.c
===================================================================
--- linux-m68k.orig/drivers/tty/serial/pmac_zilog.c 2011-10-22 23:02:22.000000000 +1100
+++ linux-m68k/drivers/tty/serial/pmac_zilog.c 2011-10-22 23:02:38.000000000 +1100
@@ -910,8 +910,8 @@ static int __pmz_startup(struct uart_pma
/* Clear handshaking, enable BREAK interrupts */
uap->curregs[R15] = BRKIE;
- /* Master interrupt enable */
- uap->curregs[R9] |= NV | MIE;
+ /* No vector */
+ uap->curregs[R9] |= NV;
pmz_load_zsregs(uap, uap->curregs);
@@ -925,6 +925,17 @@ static int __pmz_startup(struct uart_pma
return pwr_delay;
}
+static void pmz_master_int_control(struct uart_pmac_port *uap, int enable)
+{
+ if (enable) {
+ uap->curregs[R9] |= MIE; /* Master interrupt enable */
+ write_zsreg(uap, R9, uap->curregs[R9]);
+ } else {
+ uap->curregs[R9] &= ~MIE;
+ write_zsreg(uap, 9, FHWRES);
+ }
+}
+
static void pmz_irda_reset(struct uart_pmac_port *uap)
{
uap->curregs[R5] |= DTR;
@@ -976,6 +987,19 @@ static int pmz_startup(struct uart_port
return -ENXIO;
}
+ /*
+ * Most 68k Mac models cannot mask the SCC IRQ so they must enable
+ * interrupts after the handler is installed and not before.
+ */
+#ifndef CONFIG_MAC
+ if (!ZS_IS_CONS(uap))
+#endif
+ {
+ spin_lock_irqsave(&port->lock, flags);
+ pmz_master_int_control(uap, 1);
+ spin_unlock_irqrestore(&port->lock, flags);
+ }
+
mutex_unlock(&pmz_irq_mutex);
/* Right now, we deal with delay by blocking here, I'll be
@@ -1015,6 +1039,11 @@ static void pmz_shutdown(struct uart_por
mutex_lock(&pmz_irq_mutex);
+#ifdef CONFIG_MAC
+ if (!ZS_IS_OPEN(uap->mate))
+ pmz_master_int_control(uap, 0);
+#endif
+
/* Release interrupt handler */
free_irq(uap->port.irq, uap);
@@ -1734,6 +1763,7 @@ static int pmz_resume(struct macio_dev *
goto bail;
}
pwr_delay = __pmz_startup(uap);
+ pmz_master_int_control(uap, 1);
/* Take care of config that may have changed while asleep */
__pmz_set_termios(&uap->port, &uap->termios_cache, NULL);
@@ -2178,6 +2208,9 @@ static int __init pmz_console_setup(stru
* Enable the hardware
*/
pwr_delay = __pmz_startup(uap);
+#ifndef CONFIG_MAC
+ pmz_master_int_control(uap, 1);
+#endif
if (pwr_delay)
mdelay(pwr_delay);
^ permalink raw reply
* Re: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Alan Cox @ 2011-11-24 14:56 UTC (permalink / raw)
To: Finn Thain
Cc: Benjamin Herrenschmidt, linux-serial, linux-m68k, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <alpine.LNX.2.00.1111250133321.6314@nippy.intranet>
On Fri, 25 Nov 2011 01:34:58 +1100 (EST)
Finn Thain <fthain@telegraphics.com.au> wrote:
>
> On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> masked. This can be a problem when pmac_zilog starts up.
>
> For example, the serial debugging code in arch/m68k/kernel/head.S may be
> used beforehand. It disables the SCC interrupts at the chip but doesn't
> ack them. Then when a pmac_zilog port is opened and SCC chip interrupts
> become enabled, the machine locks up with "unexpected interrupt" because
> request_irq() hasn't happened yet.
>
> Fix this by setting the SCC master interrupt enable bit only after the
> handler is installed. This is achieved by extracting that operation out of
> __pmz_startup() and placing it into a seperate routine.
>
> A similar problem arises when the irq is freed. Fix this by resetting the
> chip first (on m68k mac).
>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> ---
>
> This patch has been tested on a variety of m68k Macs but no PowerMacs.
>
> I am re-sending this patch Cc linux-serial. It still needs a suitable ack
> so that Geert can push it through his tree.
Given the change should work for all hardware do we really need the
ifdefs. Far better I would have thought to just change it so we don't
have to maintain what is effectively two versions of the code between now
and 2038.
So no ack from me yet - I'd like to understand the ifdef decision first.
Otherwise it looks sensible.
Alan
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Paul Gortmaker @ 2011-11-24 15:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <82B7F47D-C7BF-4BD1-9982-7E7AEDC23530@kernel.crashing.org>
On 11-11-24 03:14 AM, Kumar Gala wrote:
>
> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>
>> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
>> chips seems to cause a short lived IRQ storm (/proc/interrupts
>> typically shows somewhere between 300 and 1500 events). Unfortunately
>> this renders SysRQ over the serial console completely inoperable.
>> Testing with obvious things like ACKing the event doesn't seem to
>> change anything vs. a completely dumb approach of just ignoring
>> it and waiting for it to stop, so that is what is implemented here.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>>
>> This is a refresh of a patch I'd done earlier -- I've tried to make
>> the bug support as generic as possible to minimize having board
>> specific ifdef crap in 8250.c -- any suggestions on how to further
>> improve it are welcome.
>>
>> drivers/serial/8250.c | 6 ++++++
>> drivers/serial/8250.h | 20 ++++++++++++++++++++
>> drivers/serial/Kconfig | 14 ++++++++++++++
>> include/linux/serial_reg.h | 2 ++
>> 4 files changed, 42 insertions(+), 0 deletions(-)
>
> Did we ever decide what to do with this or trying to get it accepted upstream?
That is an old version. ScottW gave me the errata information
which allowed me to fix the problem in a cleaner way.
http://patchwork.ozlabs.org/patch/46609/
I think the above version is OK as-is; the only thing I
think we could do to improve it is to go and automatically
select the thing based on known impacted CPU types (which
could be a separate commit or commits, as various CPUs are
confirmed to have the issue.)
Paul.
>
> - k
^ permalink raw reply
* RE: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: David Laight @ 2011-11-24 15:28 UTC (permalink / raw)
To: Finn Thain, Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <alpine.LNX.2.00.1111250133321.6314@nippy.intranet>
> On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> masked. This can be a problem when pmac_zilog starts up.
Wouldn't this also happen if the interrupt were shared?
Hopefully nothing vaguely modern uses the borked Zilog 8530 SCC
(which I presume is the part in question - brings back
too many nightmares....)
David
^ permalink raw reply
* [PATCH 02/11] TTY: Remove redundant spi driver bus initialization
From: Lars-Peter Clausen @ 2011-11-24 15:29 UTC (permalink / raw)
To: linux-kernel; +Cc: Lars-Peter Clausen, open list:SERIAL DRIVERS
In-Reply-To: <1322148561-25138-1-git-send-email-lars@metafoo.de>
In ancient times it was necessary to manually initialize the bus field of an
spi_driver to spi_bus_type. These days this is done in spi_driver_register(),
so we can drop the manual assignment.
The patch was generated using the following coccinelle semantic patch:
// <smpl>
@@
identifier _driver;
@@
struct spi_driver _driver = {
.driver = {
- .bus = &spi_bus_type,
},
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Alan Cox <alan@linux.intel.com> (maintainer:SERIAL DRIVERS)
Cc: linux-serial@vger.kernel.org (open list:SERIAL DRIVERS)
---
drivers/tty/serial/ifx6x60.c | 1 -
drivers/tty/serial/max3100.c | 1 -
drivers/tty/serial/max3107-aava.c | 1 -
drivers/tty/serial/max3107.c | 1 -
drivers/tty/serial/mrst_max3110.c | 1 -
5 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 426434e..7e925e2 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -1334,7 +1334,6 @@ MODULE_DEVICE_TABLE(spi, ifx_id_table);
static const struct spi_driver ifx_spi_driver = {
.driver = {
.name = DRVNAME,
- .bus = &spi_bus_type,
.pm = &ifx_spi_pm,
.owner = THIS_MODULE},
.probe = ifx_spi_spi_probe,
diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c
index 8a6cc8c..b4902b9 100644
--- a/drivers/tty/serial/max3100.c
+++ b/drivers/tty/serial/max3100.c
@@ -901,7 +901,6 @@ static int max3100_resume(struct spi_device *spi)
static struct spi_driver max3100_driver = {
.driver = {
.name = "max3100",
- .bus = &spi_bus_type,
.owner = THIS_MODULE,
},
diff --git a/drivers/tty/serial/max3107-aava.c b/drivers/tty/serial/max3107-aava.c
index 90c40f2..aae772a 100644
--- a/drivers/tty/serial/max3107-aava.c
+++ b/drivers/tty/serial/max3107-aava.c
@@ -315,7 +315,6 @@ static int __devinit max3107_probe_aava(struct spi_device *spi)
static struct spi_driver max3107_driver = {
.driver = {
.name = "aava-max3107",
- .bus = &spi_bus_type,
.owner = THIS_MODULE,
},
.probe = max3107_probe_aava,
diff --git a/drivers/tty/serial/max3107.c b/drivers/tty/serial/max3107.c
index 7827000..17c7ba8 100644
--- a/drivers/tty/serial/max3107.c
+++ b/drivers/tty/serial/max3107.c
@@ -1181,7 +1181,6 @@ static int max3107_probe_generic(struct spi_device *spi)
static struct spi_driver max3107_driver = {
.driver = {
.name = "max3107",
- .bus = &spi_bus_type,
.owner = THIS_MODULE,
},
.probe = max3107_probe_generic,
diff --git a/drivers/tty/serial/mrst_max3110.c b/drivers/tty/serial/mrst_max3110.c
index 4c309e8..df2a224 100644
--- a/drivers/tty/serial/mrst_max3110.c
+++ b/drivers/tty/serial/mrst_max3110.c
@@ -876,7 +876,6 @@ static int __devexit serial_m3110_remove(struct spi_device *dev)
static struct spi_driver uart_max3110_driver = {
.driver = {
.name = "spi_max3111",
- .bus = &spi_bus_type,
.owner = THIS_MODULE,
},
.probe = serial_m3110_probe,
--
1.7.7.1
^ permalink raw reply related
* Re: [PATCH 0/8] serial: 8250: support hw-based RS485 direction control (finally!)
From: Claudio Scordino @ 2011-11-24 16:05 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-serial, linux-kernel, Alan Cox, Juergen Beisert,
Matthias Fuchs
In-Reply-To: <20111123150312.GH4063@pengutronix.de>
Il 23/11/2011 16:03, Wolfram Sang ha scritto:
> On Wed, Nov 16, 2011 at 05:24:37PM +0100, Wolfram Sang wrote:
>> Some 8250-variants control the direction pin for RS485 in hardware. Linux has
>> RS485 support these days, so update the 8250-driver to adhere to that. There
>> have been attempts for mainlining this before. So, I started with the version
>> from Matthias which got no further comments, a proof-of-concept for the 16V2750
>> from Jürgen, and reworked it to match the current state of RS485 in Linux. Some
>> minor cleanup patches came along the way. Really looking forward to
>> comments/tags, because I think it is really time to get this functionality into
>> mainline once and for all ;)
>
> Ping. Claudio? What do you think?
Hi Wolfram,
sorry for the delay, but I'm very busy these days.
I noticed that some of your patches revert the changes made by the previous patches in the
same series. So I would have preferred having only one patch with the whole changes wrt to
the mainline.
However, I've understood that some of those patches come from a previous submission that you
preferred to not touch. And I can apply the whole series to check what are the actual changes,
so its' fine.
The RS485 part looks right.
I had a superficial look also at the rest of the code, and its seems OK too. But, honestly, I couldn't
find the time to read it carefully.
Best regards,
Claudio
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Kumar Gala @ 2011-11-24 19:07 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <4ECE6243.3020604@windriver.com>
On Nov 24, 2011, at 9:26 AM, Paul Gortmaker wrote:
> On 11-11-24 03:14 AM, Kumar Gala wrote:
>>
>> On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
>>
>>> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
>>> chips seems to cause a short lived IRQ storm (/proc/interrupts
>>> typically shows somewhere between 300 and 1500 events). Unfortunately
>>> this renders SysRQ over the serial console completely inoperable.
>>> Testing with obvious things like ACKing the event doesn't seem to
>>> change anything vs. a completely dumb approach of just ignoring
>>> it and waiting for it to stop, so that is what is implemented here.
>>>
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>> ---
>>>
>>> This is a refresh of a patch I'd done earlier -- I've tried to make
>>> the bug support as generic as possible to minimize having board
>>> specific ifdef crap in 8250.c -- any suggestions on how to further
>>> improve it are welcome.
>>>
>>> drivers/serial/8250.c | 6 ++++++
>>> drivers/serial/8250.h | 20 ++++++++++++++++++++
>>> drivers/serial/Kconfig | 14 ++++++++++++++
>>> include/linux/serial_reg.h | 2 ++
>>> 4 files changed, 42 insertions(+), 0 deletions(-)
>>
>> Did we ever decide what to do with this or trying to get it accepted upstream?
>
> That is an old version. ScottW gave me the errata information
> which allowed me to fix the problem in a cleaner way.
>
> http://patchwork.ozlabs.org/patch/46609/
>
> I think the above version is OK as-is; the only thing I
> think we could do to improve it is to go and automatically
> select the thing based on known impacted CPU types (which
> could be a separate commit or commits, as various CPUs are
> confirmed to have the issue.)
Seems as if we could have ->bugs passed in via plat_serial8250_port and than we can get the info from the device tree.
- k
^ permalink raw reply
* Re: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Benjamin Herrenschmidt @ 2011-11-24 20:41 UTC (permalink / raw)
To: Alan Cox
Cc: Finn Thain, linux-serial, linux-m68k, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <20111124145624.24438832@lxorguk.ukuu.org.uk>
On Thu, 2011-11-24 at 14:56 +0000, Alan Cox wrote:
> > This patch has been tested on a variety of m68k Macs but no
> PowerMacs.
> >
> > I am re-sending this patch Cc linux-serial. It still needs a
> suitable ack
> > so that Geert can push it through his tree.
>
> Given the change should work for all hardware do we really need the
> ifdefs. Far better I would have thought to just change it so we don't
> have to maintain what is effectively two versions of the code between
> now
> and 2038.
>
> So no ack from me yet - I'd like to understand the ifdef decision
> first.
> Otherwise it looks sensible.
Yes, agreed. Sorry, that one was one my to-do list for a while, I meant
to look into more details and test on a ppc or two here see if it breaks
anything, and never got to do it.
I'll try to give it a go before hell freezes over.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Benjamin Herrenschmidt @ 2011-11-24 20:43 UTC (permalink / raw)
To: David Laight
Cc: Finn Thain, Geert Uytterhoeven, linux-m68k, linuxppc-dev,
linux-serial
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEE1@saturn3.aculab.com>
On Thu, 2011-11-24 at 15:28 +0000, David Laight wrote:
> > On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
> > masked. This can be a problem when pmac_zilog starts up.
>
> Wouldn't this also happen if the interrupt were shared?
> Hopefully nothing vaguely modern uses the borked Zilog 8530 SCC
> (which I presume is the part in question - brings back
> too many nightmares....)
Yup. Afaik, the most recent you can find with that are PowerMacs which
used it for their internal modem (even my G5 has one wired to the
internal slot afaik), tho none of those had shared interrupts.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-11-25 3:15 UTC (permalink / raw)
To: Alan Cox
Cc: Benjamin Herrenschmidt, linux-serial, linux-m68k, linuxppc-dev,
Geert Uytterhoeven
In-Reply-To: <20111124145624.24438832@lxorguk.ukuu.org.uk>
On Thu, 24 Nov 2011, Alan Cox wrote:
> Given the change should work for all hardware do we really need the
> ifdefs. Far better I would have thought to just change it so we don't
> have to maintain what is effectively two versions of the code between
> now and 2038.
I agree.
>
> So no ack from me yet - I'd like to understand the ifdef decision first.
Removing ifdefs makes the changes more invasive and the suspend/resume
code then has to be addressed, which I've avoided.
The suspend/resume code path can't be tested on m68k macs and the common
code paths I can't easily test on a powermac.
This patch should not be needed because the chip reset shouldn't leave the
tx and rx interrupts enabled. Those interrupts are explicitly enabled only
after request_irq(), so patching the master interrupt enable behaviour
should be redundant. But that's not the case in practice.
The chip reset code is already messy. I was inclined towards ifdefs and
reluctant to share more code after practical experience suggested possible
differences in the SCC/ESCC devices.
I guess I was hoping that the powermac maintainers might prefer ifdefs to
increased risk of destabilising the driver on powermacs...
But a more invasive patch would make for better code. I will see if I can
borrow a suitable PCI PowerMac.
Finn
> Otherwise it looks sensible.
>
> Alan
^ permalink raw reply
* 2011秋季广交会买家，群发软件+买家搜索机、海关数据,B2B询盘买家500万。
From: 保证有买家回复 @ 2011-11-25 15:54 UTC (permalink / raw)
To: annina, qunwei598, minmingg, skyportsales5, redacted,
linux-serial, phjirodomb, scdjyc, sales, master, xiaocry_yy91
群发软件+买家搜索机+110届广交会买家、展会买家、海关数据,B2B询盘买家500万。
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季+秋季广交会买家数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，最新全球买家库,共451660条数据。
3，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
4，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
5，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
6，60.8万条最新国外B2B买家询盘。
7，2009年海关提单数据piers版数据 1千万。
8，群发软件，群发软件的部署与安装。
共 500万个买家，每个均有Email.
要的抓紧联系QQ: 467643975
要的抓紧联系QQ: 467643975
要的抓紧联系QQ: 467643975
诚信为本，如果不信任本人,可以走淘宝交易,收货验证后再付款,这是对您最好的保障了。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
^ permalink raw reply
* 2011秋季广交会买家，群发软件+买家搜索机、海关数据,B2B询盘买家500万。
From: 保证有买家回复 @ 2011-11-25 16:38 UTC (permalink / raw)
To: peter_wu, onlyrope, danielle-babycakes.x, linux-serial,
phjirodomb, scdjyc, sales, changliangyan, firebirdcreations2010,
ane.wiersma, jw253765158
群发软件+买家搜索机+110届广交会买家、展会买家、海关数据,B2B询盘买家500万。
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季+秋季广交会买家数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，最新全球买家库,共451660条数据。
3，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
4，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
5，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
6，60.8万条最新国外B2B买家询盘。
7，2009年海关提单数据piers版数据 1千万。
8，群发软件，群发软件的部署与安装。
共 500万个买家，每个均有Email.
要的抓紧联系QQ: 467643975
要的抓紧联系QQ: 467643975
要的抓紧联系QQ: 467643975
诚信为本，如果不信任本人,可以走淘宝交易,收货验证后再付款,这是对您最好的保障了。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox