* Re: [PATCH 01/17] KVM: PPC: Fix machine checks on 32-bit Book3S
From: Alexander Graf @ 2011-07-01 10:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20110629101642.GB25406@bloggs.ozlabs.ibm.com>
On 29.06.2011, at 12:16, Paul Mackerras wrote:
> Commit 69acc0d3ba ("KVM: PPC: Resolve real-mode handlers through
> function exports") resulted in vcpu->arch.trampoline_lowmem and
> vcpu->arch.trampoline_enter ending up with kernel virtual addresses
> rather than physical addresses. This is OK on 64-bit Book3S machines,
> which ignore the top 4 bits of the effective address in real mode,
> but on 32-bit Book3S machines, accessing these addresses in real mode
> causes machine check interrupts, as the hardware uses the whole
> effective address as the physical address in real mode.
>=20
> This fixes the problem by using __pa() to convert these addresses
> to physical addresses.
Ouch. Thanks for the catch! I really need to include book3s_32 in my =
automated testing :(.
Alex
^ permalink raw reply
* linux tqm8260
From: bourkeb idir @ 2011-07-01 8:57 UTC (permalink / raw)
To: Linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
hi everybody
i'm trying to port linux in a tqm8260 fresscale card with an mpc8260 cpu .i've already ported u-boot and it seems working but now i'm trying to cross compile a linux kernel 2.4.4 (which have a config file for tqm8260) and i always get trouble when i try to make a zImage .
can anyone help me ,please?
[-- Attachment #2: Type: text/html, Size: 517 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: ucc_geth: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 6:57 UTC (permalink / raw)
To: tklauser; +Cc: netdev, linuxppc-dev
In-Reply-To: <1309349793-1864-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 29 Jun 2011 14:16:33 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* [PATCH] 4xx: Add check_link to struct ppc4xx_pciex_hwops
From: Tony Breeds @ 2011-07-01 6:44 UTC (permalink / raw)
To: LinuxPPC-dev, Benjamin Herrenschmidt; +Cc: Ayman El-Khashab
All current pcie controllers unconditionally use SDR to check the link and
poll for reset.
Refactor the code to include device reset in the port_init_hw() op and add a new
check_link() op.
This will make room fro new controllers that do not use SDR for these
operations.
Tested on 460ex.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 156aa7d..ad330fe 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -650,12 +650,75 @@ struct ppc4xx_pciex_hwops
int (*core_init)(struct device_node *np);
int (*port_init_hw)(struct ppc4xx_pciex_port *port);
int (*setup_utl)(struct ppc4xx_pciex_port *port);
+ void (*check_link)(struct ppc4xx_pciex_port *port);
};
static struct ppc4xx_pciex_hwops *ppc4xx_pciex_hwops;
#ifdef CONFIG_44x
+static int __init ppc4xx_pciex_wait_on_sdr(struct ppc4xx_pciex_port *port,
+ unsigned int sdr_offset,
+ unsigned int mask,
+ unsigned int value,
+ int timeout_ms)
+{
+ u32 val;
+
+ while(timeout_ms--) {
+ val = mfdcri(SDR0, port->sdr_base + sdr_offset);
+ if ((val & mask) == value) {
+ pr_debug("PCIE%d: Wait on SDR %x success with tm %d (%08x)\n",
+ port->index, sdr_offset, timeout_ms, val);
+ return 0;
+ }
+ msleep(1);
+ }
+ return -1;
+}
+
+static int __init ppc4xx_pciex_port_reset_sdr(struct ppc4xx_pciex_port *port)
+{
+ printk(KERN_INFO "PCIE%d: Checking link...\n",
+ port->index);
+
+ /* Wait for reset to complete */
+ if (ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS, 1 << 20, 0, 10)) {
+ printk(KERN_WARNING "PCIE%d: PGRST failed\n",
+ port->index);
+ return -1;
+ }
+ return 0;
+}
+
+static void __init ppc4xx_pciex_check_link_sdr(struct ppc4xx_pciex_port *port)
+{
+ /* Check for card presence detect if supported, if not, just wait for
+ * link unconditionally.
+ *
+ * note that we don't fail if there is no link, we just filter out
+ * config space accesses. That way, it will be easier to implement
+ * hotplug later on.
+ */
+ if (!port->has_ibpre ||
+ !ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP,
+ 1 << 28, 1 << 28, 100)) {
+ printk(KERN_INFO
+ "PCIE%d: Device detected, waiting for link...\n",
+ port->index);
+ if (ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP,
+ 0x1000, 0x1000, 2000))
+ printk(KERN_WARNING
+ "PCIE%d: Link up failed\n", port->index);
+ else {
+ printk(KERN_INFO
+ "PCIE%d: link is up !\n", port->index);
+ port->link = 1;
+ }
+ } else
+ printk(KERN_INFO "PCIE%d: No device detected.\n", port->index);
+}
+
/* Check various reset bits of the 440SPe PCIe core */
static int __init ppc440spe_pciex_check_reset(struct device_node *np)
{
@@ -806,7 +869,7 @@ static int ppc440spe_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET,
(1 << 24) | (1 << 16), 1 << 12);
- return 0;
+ return ppc4xx_pciex_port_reset_sdr(port);
}
static int ppc440speA_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
@@ -856,6 +919,7 @@ static struct ppc4xx_pciex_hwops ppc440speA_pcie_hwops __initdata =
.core_init = ppc440spe_pciex_core_init,
.port_init_hw = ppc440speA_pciex_init_port_hw,
.setup_utl = ppc440speA_pciex_init_utl,
+ .check_link = ppc4xx_pciex_check_link_sdr,
};
static struct ppc4xx_pciex_hwops ppc440speB_pcie_hwops __initdata =
@@ -863,6 +927,7 @@ static struct ppc4xx_pciex_hwops ppc440speB_pcie_hwops __initdata =
.core_init = ppc440spe_pciex_core_init,
.port_init_hw = ppc440speB_pciex_init_port_hw,
.setup_utl = ppc440speB_pciex_init_utl,
+ .check_link = ppc4xx_pciex_check_link_sdr,
};
static int __init ppc460ex_pciex_core_init(struct device_node *np)
@@ -944,7 +1009,7 @@ static int ppc460ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
port->has_ibpre = 1;
- return 0;
+ return ppc4xx_pciex_port_reset_sdr(port);
}
static int ppc460ex_pciex_init_utl(struct ppc4xx_pciex_port *port)
@@ -972,6 +1037,7 @@ static struct ppc4xx_pciex_hwops ppc460ex_pcie_hwops __initdata =
.core_init = ppc460ex_pciex_core_init,
.port_init_hw = ppc460ex_pciex_init_port_hw,
.setup_utl = ppc460ex_pciex_init_utl,
+ .check_link = ppc4xx_pciex_check_link_sdr,
};
static int __init ppc460sx_pciex_core_init(struct device_node *np)
@@ -1075,7 +1141,7 @@ static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
port->has_ibpre = 1;
- return 0;
+ return ppc4xx_pciex_port_reset_sdr(port);
}
static int ppc460sx_pciex_init_utl(struct ppc4xx_pciex_port *port)
@@ -1089,6 +1155,7 @@ static struct ppc4xx_pciex_hwops ppc460sx_pcie_hwops __initdata = {
.core_init = ppc460sx_pciex_core_init,
.port_init_hw = ppc460sx_pciex_init_port_hw,
.setup_utl = ppc460sx_pciex_init_utl,
+ .check_link = ppc4xx_pciex_check_link_sdr,
};
#endif /* CONFIG_44x */
@@ -1154,7 +1221,7 @@ static int ppc405ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
port->has_ibpre = 1;
- return 0;
+ return ppc4xx_pciex_port_reset_sdr(port);
}
static int ppc405ex_pciex_init_utl(struct ppc4xx_pciex_port *port)
@@ -1183,11 +1250,11 @@ static struct ppc4xx_pciex_hwops ppc405ex_pcie_hwops __initdata =
.core_init = ppc405ex_pciex_core_init,
.port_init_hw = ppc405ex_pciex_init_port_hw,
.setup_utl = ppc405ex_pciex_init_utl,
+ .check_link = ppc4xx_pciex_check_link_sdr,
};
#endif /* CONFIG_40x */
-
/* Check that the core has been initied and if not, do it */
static int __init ppc4xx_pciex_check_core_init(struct device_node *np)
{
@@ -1261,26 +1328,6 @@ static void __init ppc4xx_pciex_port_init_mapping(struct ppc4xx_pciex_port *port
dcr_write(port->dcrs, DCRO_PEGPL_MSGMSK, 0);
}
-static int __init ppc4xx_pciex_wait_on_sdr(struct ppc4xx_pciex_port *port,
- unsigned int sdr_offset,
- unsigned int mask,
- unsigned int value,
- int timeout_ms)
-{
- u32 val;
-
- while(timeout_ms--) {
- val = mfdcri(SDR0, port->sdr_base + sdr_offset);
- if ((val & mask) == value) {
- pr_debug("PCIE%d: Wait on SDR %x success with tm %d (%08x)\n",
- port->index, sdr_offset, timeout_ms, val);
- return 0;
- }
- msleep(1);
- }
- return -1;
-}
-
static int __init ppc4xx_pciex_port_init(struct ppc4xx_pciex_port *port)
{
int rc = 0;
@@ -1291,40 +1338,8 @@ static int __init ppc4xx_pciex_port_init(struct ppc4xx_pciex_port *port)
if (rc != 0)
return rc;
- printk(KERN_INFO "PCIE%d: Checking link...\n",
- port->index);
-
- /* Wait for reset to complete */
- if (ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS, 1 << 20, 0, 10)) {
- printk(KERN_WARNING "PCIE%d: PGRST failed\n",
- port->index);
- return -1;
- }
-
- /* Check for card presence detect if supported, if not, just wait for
- * link unconditionally.
- *
- * note that we don't fail if there is no link, we just filter out
- * config space accesses. That way, it will be easier to implement
- * hotplug later on.
- */
- if (!port->has_ibpre ||
- !ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP,
- 1 << 28, 1 << 28, 100)) {
- printk(KERN_INFO
- "PCIE%d: Device detected, waiting for link...\n",
- port->index);
- if (ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP,
- 0x1000, 0x1000, 2000))
- printk(KERN_WARNING
- "PCIE%d: Link up failed\n", port->index);
- else {
- printk(KERN_INFO
- "PCIE%d: link is up !\n", port->index);
- port->link = 1;
- }
- } else
- printk(KERN_INFO "PCIE%d: No device detected.\n", port->index);
+ if (ppc4xx_pciex_hwops->check_link)
+ ppc4xx_pciex_hwops->check_link(port);
/*
* Initialize mapping: disable all regions and configure
@@ -1347,14 +1362,17 @@ static int __init ppc4xx_pciex_port_init(struct ppc4xx_pciex_port *port)
/*
* Check for VC0 active and assert RDY.
*/
- if (port->link &&
- ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS,
- 1 << 16, 1 << 16, 5000)) {
- printk(KERN_INFO "PCIE%d: VC0 not active\n", port->index);
- port->link = 0;
+ if (port->sdr_base) {
+ if (port->link &&
+ ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS,
+ 1 << 16, 1 << 16, 5000)) {
+ printk(KERN_INFO "PCIE%d: VC0 not active\n", port->index);
+ port->link = 0;
+ }
+
+ dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET, 0, 1 << 20);
}
- dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET, 0, 1 << 20);
msleep(100);
return 0;
Yours Tony
^ permalink raw reply related
* Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
From: Artem Bityutskiy @ 2011-07-01 5:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, b35362, dwmw2, linux-mtd
In-Reply-To: <20110630112656.3257116a@schlenkerla.am.freescale.net>
On Thu, 2011-06-30 at 11:26 -0500, Scott Wood wrote:
> If the NULL assignment is dropped, consider what happens if the
> fsl_elbc_nand module is removed then reinserted. On reinsertion, it
> will
> see a non-NULL fsl_lbc_ctrl_dev->nand, and will skip allocating a new
> one.
> Then you're referencing freed memory.
Oh, then this sounds like a separate bug. Removing the module should
kill everything, and re-inserging the module should have zero
dependencies on the previous states...
Anyway, if you think the original patch is OK, I can put it to my tree.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* [PATCH] powerpc/hvsi: Fix conflict with old HVSI driver
From: Benjamin Herrenschmidt @ 2011-07-01 3:11 UTC (permalink / raw)
To: linuxppc-dev
A mix of thinko & mismerge on my side caused a problem where both the
new hvsi_lib and the old hvsi driver gets compiled and try to define
symbols with the same name.
This fixes it by renaming the hvsi_lib exported symbols.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/hvsi.h | 24 ++++++++++++------------
drivers/tty/hvc/hvc_vio.c | 30 +++++++++++++++---------------
drivers/tty/hvc/hvsi_lib.c | 32 ++++++++++++++++----------------
3 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/include/asm/hvsi.h b/arch/powerpc/include/asm/hvsi.h
index 91e0453..d3f64f3 100644
--- a/arch/powerpc/include/asm/hvsi.h
+++ b/arch/powerpc/include/asm/hvsi.h
@@ -78,17 +78,17 @@ struct hvsi_priv {
/* hvsi lib functions */
struct hvc_struct;
-extern void hvsi_init(struct hvsi_priv *pv,
- int (*get_chars)(uint32_t termno, char *buf, int count),
- int (*put_chars)(uint32_t termno, const char *buf,
- int count),
- int termno, int is_console);
-extern int hvsi_open(struct hvsi_priv *pv, struct hvc_struct *hp);
-extern void hvsi_close(struct hvsi_priv *pv, struct hvc_struct *hp);
-extern int hvsi_read_mctrl(struct hvsi_priv *pv);
-extern int hvsi_write_mctrl(struct hvsi_priv *pv, int dtr);
-extern void hvsi_establish(struct hvsi_priv *pv);
-extern int hvsi_get_chars(struct hvsi_priv *pv, char *buf, int count);
-extern int hvsi_put_chars(struct hvsi_priv *pv, const char *buf, int count);
+extern void hvsilib_init(struct hvsi_priv *pv,
+ int (*get_chars)(uint32_t termno, char *buf, int count),
+ int (*put_chars)(uint32_t termno, const char *buf,
+ int count),
+ int termno, int is_console);
+extern int hvsilib_open(struct hvsi_priv *pv, struct hvc_struct *hp);
+extern void hvsilib_close(struct hvsi_priv *pv, struct hvc_struct *hp);
+extern int hvsilib_read_mctrl(struct hvsi_priv *pv);
+extern int hvsilib_write_mctrl(struct hvsi_priv *pv, int dtr);
+extern void hvsilib_establish(struct hvsi_priv *pv);
+extern int hvsilib_get_chars(struct hvsi_priv *pv, char *buf, int count);
+extern int hvsilib_put_chars(struct hvsi_priv *pv, const char *buf, int count);
#endif /* _HVSI_H */
diff --git a/drivers/tty/hvc/hvc_vio.c b/drivers/tty/hvc/hvc_vio.c
index ade73fa..710c06c 100644
--- a/drivers/tty/hvc/hvc_vio.c
+++ b/drivers/tty/hvc/hvc_vio.c
@@ -134,7 +134,7 @@ static int hvterm_hvsi_get_chars(uint32_t vtermno, char *buf, int count)
if (WARN_ON(!pv))
return 0;
- return hvsi_get_chars(&pv->hvsi, buf, count);
+ return hvsilib_get_chars(&pv->hvsi, buf, count);
}
static int hvterm_hvsi_put_chars(uint32_t vtermno, const char *buf, int count)
@@ -144,7 +144,7 @@ static int hvterm_hvsi_put_chars(uint32_t vtermno, const char *buf, int count)
if (WARN_ON(!pv))
return 0;
- return hvsi_put_chars(&pv->hvsi, buf, count);
+ return hvsilib_put_chars(&pv->hvsi, buf, count);
}
static int hvterm_hvsi_open(struct hvc_struct *hp, int data)
@@ -158,7 +158,7 @@ static int hvterm_hvsi_open(struct hvc_struct *hp, int data)
if (rc)
return rc;
- return hvsi_open(&pv->hvsi, hp);
+ return hvsilib_open(&pv->hvsi, hp);
}
static void hvterm_hvsi_close(struct hvc_struct *hp, int data)
@@ -167,7 +167,7 @@ static void hvterm_hvsi_close(struct hvc_struct *hp, int data)
pr_devel("HVSI@%x: do close !\n", pv->termno);
- hvsi_close(&pv->hvsi, hp);
+ hvsilib_close(&pv->hvsi, hp);
notifier_del_irq(hp, data);
}
@@ -178,7 +178,7 @@ void hvterm_hvsi_hangup(struct hvc_struct *hp, int data)
pr_devel("HVSI@%x: do hangup !\n", pv->termno);
- hvsi_close(&pv->hvsi, hp);
+ hvsilib_close(&pv->hvsi, hp);
notifier_hangup_irq(hp, data);
}
@@ -201,9 +201,9 @@ static int hvterm_hvsi_tiocmset(struct hvc_struct *hp, unsigned int set,
pv->termno, set, clear);
if (set & TIOCM_DTR)
- hvsi_write_mctrl(&pv->hvsi, 1);
+ hvsilib_write_mctrl(&pv->hvsi, 1);
else if (clear & TIOCM_DTR)
- hvsi_write_mctrl(&pv->hvsi, 0);
+ hvsilib_write_mctrl(&pv->hvsi, 0);
return 0;
}
@@ -267,8 +267,8 @@ static int __devinit hvc_vio_probe(struct vio_dev *vdev,
pv->termno = vdev->unit_address;
pv->proto = proto;
hvterm_privs[termno] = pv;
- hvsi_init(&pv->hvsi, hvc_get_chars, hvc_put_chars,
- pv->termno, 0);
+ hvsilib_init(&pv->hvsi, hvc_get_chars, hvc_put_chars,
+ pv->termno, 0);
}
hp = hvc_alloc(termno, vdev->irq, ops, MAX_VIO_PUT_CHARS);
@@ -416,10 +416,10 @@ void __init hvc_vio_init_early(void)
else if (of_device_is_compatible(stdout_node, "hvterm-protocol")) {
hvterm_priv0.proto = HV_PROTOCOL_HVSI;
ops = &hvterm_hvsi_ops;
- hvsi_init(&hvterm_priv0.hvsi, hvc_get_chars, hvc_put_chars,
- hvterm_priv0.termno, 1);
+ hvsilib_init(&hvterm_priv0.hvsi, hvc_get_chars, hvc_put_chars,
+ hvterm_priv0.termno, 1);
/* HVSI, perform the handshake now */
- hvsi_establish(&hvterm_priv0.hvsi);
+ hvsilib_establish(&hvterm_priv0.hvsi);
} else
goto out;
udbg_putc = udbg_hvc_putc;
@@ -462,8 +462,8 @@ void __init udbg_init_debug_lpar_hvsi(void)
udbg_putc = udbg_hvc_putc;
udbg_getc = udbg_hvc_getc;
udbg_getc_poll = udbg_hvc_getc_poll;
- hvsi_init(&hvterm_priv0.hvsi, hvc_get_chars, hvc_put_chars,
- hvterm_priv0.termno, 1);
- hvsi_establish(&hvterm_priv0.hvsi);
+ hvsilib_init(&hvterm_priv0.hvsi, hvc_get_chars, hvc_put_chars,
+ hvterm_priv0.termno, 1);
+ hvsilib_establish(&hvterm_priv0.hvsi);
}
#endif /* CONFIG_PPC_EARLY_DEBUG_LPAR_HVSI */
diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
index 9401fcb..bd9b098 100644
--- a/drivers/tty/hvc/hvsi_lib.c
+++ b/drivers/tty/hvc/hvsi_lib.c
@@ -178,7 +178,7 @@ static int hvsi_get_packet(struct hvsi_priv *pv)
return 0;
}
-int hvsi_get_chars(struct hvsi_priv *pv, char *buf, int count)
+int hvsilib_get_chars(struct hvsi_priv *pv, char *buf, int count)
{
unsigned int tries, read = 0;
@@ -228,7 +228,7 @@ int hvsi_get_chars(struct hvsi_priv *pv, char *buf, int count)
return read;
}
-int hvsi_put_chars(struct hvsi_priv *pv, const char *buf, int count)
+int hvsilib_put_chars(struct hvsi_priv *pv, const char *buf, int count)
{
struct hvsi_data dp;
int rc, adjcount = min(count, HVSI_MAX_OUTGOING_DATA);
@@ -254,7 +254,7 @@ static void maybe_msleep(unsigned long ms)
msleep(ms);
}
-int hvsi_read_mctrl(struct hvsi_priv *pv)
+int hvsilib_read_mctrl(struct hvsi_priv *pv)
{
struct hvsi_query q;
int rc, timeout;
@@ -285,7 +285,7 @@ int hvsi_read_mctrl(struct hvsi_priv *pv)
return -EIO;
}
-int hvsi_write_mctrl(struct hvsi_priv *pv, int dtr)
+int hvsilib_write_mctrl(struct hvsi_priv *pv, int dtr)
{
struct hvsi_control ctrl;
unsigned short mctrl;
@@ -310,7 +310,7 @@ int hvsi_write_mctrl(struct hvsi_priv *pv, int dtr)
return hvsi_send_packet(pv, &ctrl.hdr);
}
-void hvsi_establish(struct hvsi_priv *pv)
+void hvsilib_establish(struct hvsi_priv *pv)
{
int timeout;
@@ -359,32 +359,32 @@ void hvsi_establish(struct hvsi_priv *pv)
pr_devel("HVSI@%x: ... established, reading mctrl\n", pv->termno);
- hvsi_read_mctrl(pv);
+ hvsilib_read_mctrl(pv);
/* Set our own DTR */
pr_devel("HVSI@%x: ... setting mctrl\n", pv->termno);
- hvsi_write_mctrl(pv, 1);
+ hvsilib_write_mctrl(pv, 1);
/* Set the opened flag so reads are allowed */
wmb();
pv->opened = 1;
}
-int hvsi_open(struct hvsi_priv *pv, struct hvc_struct *hp)
+int hvsilib_open(struct hvsi_priv *pv, struct hvc_struct *hp)
{
pr_devel("HVSI@%x: open !\n", pv->termno);
/* Keep track of the tty data structure */
pv->tty = tty_kref_get(hp->tty);
- hvsi_establish(pv);
+ hvsilib_establish(pv);
return 0;
}
-void hvsi_close(struct hvsi_priv *pv, struct hvc_struct *hp)
+void hvsilib_close(struct hvsi_priv *pv, struct hvc_struct *hp)
{
unsigned long flags;
@@ -401,7 +401,7 @@ void hvsi_close(struct hvsi_priv *pv, struct hvc_struct *hp)
/* Clear our own DTR */
if (!pv->tty || (pv->tty->termios->c_cflag & HUPCL))
- hvsi_write_mctrl(pv, 0);
+ hvsilib_write_mctrl(pv, 0);
/* Tear down the connection */
hvsi_send_close(pv);
@@ -412,11 +412,11 @@ void hvsi_close(struct hvsi_priv *pv, struct hvc_struct *hp)
pv->tty = NULL;
}
-void hvsi_init(struct hvsi_priv *pv,
- int (*get_chars)(uint32_t termno, char *buf, int count),
- int (*put_chars)(uint32_t termno, const char *buf,
- int count),
- int termno, int is_console)
+void hvsilib_init(struct hvsi_priv *pv,
+ int (*get_chars)(uint32_t termno, char *buf, int count),
+ int (*put_chars)(uint32_t termno, const char *buf,
+ int count),
+ int termno, int is_console)
{
memset(pv, 0, sizeof(*pv));
pv->get_chars = get_chars;
^ permalink raw reply related
* Re: linux-next: build failure after merge of the powerpc tree
From: Benjamin Herrenschmidt @ 2011-07-01 3:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-next, Paul Mackerras, linux-kernel
In-Reply-To: <20110701113942.5cfed9a3.sfr@canb.auug.org.au>
On Fri, 2011-07-01 at 11:39 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/include/asm/setup.h: Assembler messages:
> arch/powerpc/include/asm/setup.h:6: Error: Unrecognized opcode: `extern'
> make[2]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> Caused by commit a9c0f41b3a64 ("powerpc: Add printk companion for
> ppc_md.progress"). Clearly not build tested for 64 but powerpc :-(
>
> I have used the version of the powerpc tree from next-20110630 for today.
Crap !
I had fixed that locally, and ... forgot to commit --amend before
pushing it.
I'll stick a fixup patch right next to it.
Cheers,
Ben.
^ permalink raw reply
* linux-next: build failure after merge of the powerpc tree
From: Stephen Rothwell @ 2011-07-01 1:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/include/asm/setup.h: Assembler messages:
arch/powerpc/include/asm/setup.h:6: Error: Unrecognized opcode: `extern'
make[2]: *** [arch/powerpc/kernel/head_64.o] Error 1
Caused by commit a9c0f41b3a64 ("powerpc: Add printk companion for
ppc_md.progress"). Clearly not build tested for 64 but powerpc :-(
I have used the version of the powerpc tree from next-20110630 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] [v6] drivers/virt: introduce Freescale hypervisor management driver
From: Tabi Timur-B04825 @ 2011-07-01 1:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
cmetcalf@tilera.com, akpm@kernel.org, dsaxena@linaro.org,
linux-console@vger.kernel.org, greg@kroah.com, Gala Kumar-B11780,
virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <201106092304.55479.arnd@arndb.de>
On Thu, Jun 9, 2011 at 4:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 09 June 2011 22:52:06 Timur Tabi wrote:
>> Add the drivers/virt directory, which houses drivers that support
>> virtualization environments, and add the Freescale hypervisor management
>> driver.
....
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
So I've made the changes that people have asked for, and Arnd has
acked this driver. Who's going to pick it up? Who will be the
maintainer for drivers/virt? I'd really like to see this driver in
3.1, and there's not much time left.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] powerpc: Use -mtraceback=no
From: Anton Blanchard @ 2011-06-30 23:55 UTC (permalink / raw)
To: benh, linuxppc-dev
gcc 4.7 will be more strict about parsing the -mtraceback option:
gcc: error: unrecognized argument in option '-mtraceback=none'
gcc: note: valid arguments to '-mtraceback=' are: full no part
gcc used to do a 2 char compare so both "no" and "none" would
match. Switch to using -mtraceback=no should work everywhere.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/Makefile
===================================================================
--- linux-powerpc.orig/arch/powerpc/Makefile 2011-07-01 09:40:57.902255472 +1000
+++ linux-powerpc/arch/powerpc/Makefile 2011-07-01 09:41:13.512533634 +1000
@@ -67,7 +67,7 @@ LDFLAGS_vmlinux-yy := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_PPC64)$(CONFIG_RELOCATABLE) := -pie
LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-yy)
-CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc
+CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=no -mcall-aixdesc
CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple
KBUILD_CPPFLAGS += -Iarch/$(ARCH)
KBUILD_AFLAGS += -Iarch/$(ARCH)
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Benjamin Herrenschmidt @ 2011-06-30 23:13 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, Alexander Graf, kvm-ppc, linuxppc-dev, Paul Mackerras,
Scott Wood
In-Reply-To: <4E0C9339.2080601@redhat.com>
> Regarding that. There's another option - the ioctl code embeds the
> structure size. So if we extend the ioctl parsing to pad up (or
> truncate down) from the user's size to our size, and similarly in the
> other direction, we can get away from this ugliness.
I don't like relying on that much ... I prefer having an explicit
version in the structure head (or use a flag).
> Some years ago I posted a generic helper that did this (and also
> kmalloc'ed and kfree'd the data itself), but it wasn't received
> favourably. Maybe I should try again (and we can possibly use it in kvm
> even if it is rejected for general use, though that's against our
> principles of pushing all generic infrastructure to the wider kernel).
Cheers,
Ben.
^ permalink raw reply
* broken g5?
From: kevin diggs @ 2011-06-30 19:11 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I would like to figure out if my G5 is broken. And if so how to fix it?
As I have previously posted it behaves strangely when using the cpufreq driver.
Anyone have suggestions to figure out what is going on?
Thanks!
kevin
^ permalink raw reply
* Re: [PATCH 2/5] hugetlb: add phys addr to struct huge_bootmem_page
From: Becky Bruce @ 2011-06-30 18:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, List linux-kernel@vger.kernel.org Mailing,
David Gibson
In-Reply-To: <1309297166.32158.461.camel@pasglop>
On Jun 28, 2011, at 4:39 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-06-28 at 14:54 -0500, Becky Bruce wrote:
>> struct page *alloc_huge_page_node(struct hstate *h, int nid);
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 6402458..2db81ea 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1105,8 +1105,14 @@ static void __init
>> gather_bootmem_prealloc(void)
>> struct huge_bootmem_page *m;
>>=20
>> list_for_each_entry(m, &huge_boot_pages, list) {
>> - struct page *page =3D virt_to_page(m);
>> struct hstate *h =3D m->hstate;
>> +#ifdef CONFIG_HIGHMEM
>> + struct page *page =3D pfn_to_page(m->phys >>
>> PAGE_SHIFT);
>> + free_bootmem_late((unsigned long)m,
>> + sizeof(struct huge_bootmem_page));
>> +#else
>> + struct page *page =3D virt_to_page(m);
>> +#endif
>> __ClearPageReserved(page);
>=20
> Why do you add free_bootmem_late() in the highmem case and not the
> normal case ?
Because there was no bootmem allocation in the normal case - the =
non-highmem version stores data structure in the huge page itself. This =
is perfectly fine as long as you have a mapping. Since this isn't true =
for HIGHMEM pages, I allocate bootmem to store the early data structure =
that stores information about the hugepage (this happens in =
arch-specific code in alloc_bootmem_huge_page).
-Becky
^ permalink raw reply
* Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
From: Dave Jones @ 2011-06-30 18:30 UTC (permalink / raw)
To: kevin diggs
Cc: Dmitry Eremin-Solenikov, Paul Mackerras, linuxppc-dev, cpufreq
In-Reply-To: <BANLkTinciPSnJHHsMo8nfvsYS1AeDov5Tw@mail.gmail.com>
On Thu, Jun 30, 2011 at 01:23:03PM -0500, kevin diggs wrote:
> Hi,
>
> On Wed, Jun 29, 2011 at 3:58 PM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
> >
> > drivers/cpufreq/powerpc. However my current version (as suggested by Ben)
> > goes directly to drivers/cpufreq
> >
> Uh ... Just curious ... why is arch specific code now being put
> outside of the arch directories? When I wrote the 750GX stuff
> (~2.6.28) I put in a location similar to what x86 was doing? When did
> this change?
last release, ARM moved their cpufreq drivers. I moved the x86 ones afterwards.
There's precedent for other arch specific drivers in drivers/ too, but the
cpufreq move is a recent thing.
Dave
^ permalink raw reply
* Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
From: kevin diggs @ 2011-06-30 18:23 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Paul Mackerras, linuxppc-dev, cpufreq, Dave Jones
In-Reply-To: <BANLkTimjBfMBXEdH7k-6sTjb1P+Fq3-Fvg@mail.gmail.com>
Hi,
On Wed, Jun 29, 2011 at 3:58 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
>
> drivers/cpufreq/powerpc. However my current version (as suggested by Ben)
> goes directly to drivers/cpufreq
>
Uh ... Just curious ... why is arch specific code now being put
outside of the arch directories? When I wrote the 750GX stuff
(~2.6.28) I put in a location similar to what x86 was doing? When did
this change?
kevin
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Alexander Graf @ 2011-06-30 16:33 UTC (permalink / raw)
To: Avi Kivity
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Paul Mackerras,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <4E0C9D98.5000904@redhat.com>
On 30.06.2011, at 18:00, Avi Kivity <avi@redhat.com> wrote:
> On 06/30/2011 06:22 PM, Alexander Graf wrote:
>>> Regarding that. There's another option - the ioctl code embeds the stru=
cture size. So if we extend the ioctl parsing to pad up (or truncate down) f=
rom the user's size to our size, and similarly in the other direction, we ca=
n get away from this ugliness.
>>>=20
>>> Some years ago I posted a generic helper that did this (and also kmalloc=
'ed and kfree'd the data itself), but it wasn't received favourably. Maybe I=
should try again (and we can possibly use it in kvm even if it is rejected f=
or general use, though that's against our principles of pushing all generic i=
nfrastructure to the wider kernel).
>>=20
>>=20
>> That does sound interesting, but requires a lot more thought to be put in=
to the actual code, as we basically need to read out the feature bitmap, the=
n provide a minimum size for the chosen features and then decide if they fit=
in.
>=20
>=20
> Why? just put the things you want in the structure.
>=20
> old userspace -> new kernel: we auto-zero the parts userspace left out, an=
d zero means old behaviour, so everthing works
> new userspace -> old kernel: truncate. Userspace shouldn't have used any n=
ew features (KVM_CAP), and we can -EINVAL if the truncated section contains a=
nonzero bit.
Yup, which requires knowledge in the code on what actually fits :). Logic we=
don't have today.
Alex
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
From: Scott Wood @ 2011-06-30 16:26 UTC (permalink / raw)
To: dedekind1; +Cc: linuxppc-dev, b35362, dwmw2, linux-mtd
In-Reply-To: <1309434797.23597.178.camel@sauron>
On Thu, 30 Jun 2011 14:53:13 +0300
Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Wed, 2011-06-29 at 11:45 -0500, Scott Wood wrote:
> > If we're freeing fsl_lbc_ctrl, we'd better get rid of references to it...
>
> Yes, on the one hand this is a good defensive programming practice, on
> the other hand it hides double-free bugs. Like this patch fixes a
> double-free bug, and why it was noticed before? I thought may be because
> of this NULL assignment?
I'm not sure how the NULL assignment was hiding anything here. It was
probably hidden only because nobody tested it with suitable debug options
enabled since the code was last reorganized.
If the NULL assignment is dropped, consider what happens if the
fsl_elbc_nand module is removed then reinserted. On reinsertion, it will
see a non-NULL fsl_lbc_ctrl_dev->nand, and will skip allocating a new one.
Then you're referencing freed memory.
Looking more closely, the MAX_BANKS loop should be removed. Since the
reorganization, the platform device represents one chip, not the
controller, so we should only be removing that one chip.
-Scott
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Avi Kivity @ 2011-06-30 16:00 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras, kvm-ppc, kvm
In-Reply-To: <4E0C94A0.3090301@suse.de>
On 06/30/2011 06:22 PM, Alexander Graf wrote:
>> Regarding that. There's another option - the ioctl code embeds the
>> structure size. So if we extend the ioctl parsing to pad up (or
>> truncate down) from the user's size to our size, and similarly in the
>> other direction, we can get away from this ugliness.
>>
>> Some years ago I posted a generic helper that did this (and also
>> kmalloc'ed and kfree'd the data itself), but it wasn't received
>> favourably. Maybe I should try again (and we can possibly use it in
>> kvm even if it is rejected for general use, though that's against our
>> principles of pushing all generic infrastructure to the wider kernel).
>
>
> That does sound interesting, but requires a lot more thought to be put
> into the actual code, as we basically need to read out the feature
> bitmap, then provide a minimum size for the chosen features and then
> decide if they fit in.
Why? just put the things you want in the structure.
old userspace -> new kernel: we auto-zero the parts userspace left out,
and zero means old behaviour, so everthing works
new userspace -> old kernel: truncate. Userspace shouldn't have used
any new features (KVM_CAP), and we can -EINVAL if the truncated section
contains a nonzero bit.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Alexander Graf @ 2011-06-30 15:22 UTC (permalink / raw)
To: Avi Kivity; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras, kvm-ppc, kvm
In-Reply-To: <4E0C9339.2080601@redhat.com>
On 06/30/2011 05:16 PM, Avi Kivity wrote:
> On 06/30/2011 06:04 PM, Alexander Graf wrote:
>>> +4.64 KVM_PPC_SET_PLATFORM
>>> +
>>> +Capability: none
>>> +Architectures: powerpc
>>> +Type: vm ioctl
>>> +Parameters: struct kvm_ppc_set_platform (in)
>>> +Returns: 0, or -1 on error
>>> +
>>> +This is used by userspace to tell KVM what sort of platform it should
>>> +emulate. The return value of the ioctl tells userspace whether the
>>> +emulation it is requesting is supported by KVM.
>>> +
>>> +struct kvm_ppc_set_platform {
>>> + __u16 platform; /* defines the OS/hypervisor ABI */
>>> + __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
>>> + __u32 flags;
>>
>>
>> Please add some padding so we can extend it later if necessary.
>
> Regarding that. There's another option - the ioctl code embeds the
> structure size. So if we extend the ioctl parsing to pad up (or
> truncate down) from the user's size to our size, and similarly in the
> other direction, we can get away from this ugliness.
>
> Some years ago I posted a generic helper that did this (and also
> kmalloc'ed and kfree'd the data itself), but it wasn't received
> favourably. Maybe I should try again (and we can possibly use it in
> kvm even if it is rejected for general use, though that's against our
> principles of pushing all generic infrastructure to the wider kernel).
That does sound interesting, but requires a lot more thought to be put
into the actual code, as we basically need to read out the feature
bitmap, then provide a minimum size for the chosen features and then
decide if they fit in.
But yes, that'd still be a lot better than shoving around useless data
all the time :)
Alex
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Avi Kivity @ 2011-06-30 15:16 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras, kvm-ppc, kvm
In-Reply-To: <4E0C9077.2060608@suse.de>
On 06/30/2011 06:04 PM, Alexander Graf wrote:
>> +4.64 KVM_PPC_SET_PLATFORM
>> +
>> +Capability: none
>> +Architectures: powerpc
>> +Type: vm ioctl
>> +Parameters: struct kvm_ppc_set_platform (in)
>> +Returns: 0, or -1 on error
>> +
>> +This is used by userspace to tell KVM what sort of platform it should
>> +emulate. The return value of the ioctl tells userspace whether the
>> +emulation it is requesting is supported by KVM.
>> +
>> +struct kvm_ppc_set_platform {
>> + __u16 platform; /* defines the OS/hypervisor ABI */
>> + __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
>> + __u32 flags;
>
>
> Please add some padding so we can extend it later if necessary.
Regarding that. There's another option - the ioctl code embeds the
structure size. So if we extend the ioctl parsing to pad up (or
truncate down) from the user's size to our size, and similarly in the
other direction, we can get away from this ugliness.
Some years ago I posted a generic helper that did this (and also
kmalloc'ed and kfree'd the data itself), but it wasn't received
favourably. Maybe I should try again (and we can possibly use it in kvm
even if it is rejected for general use, though that's against our
principles of pushing all generic infrastructure to the wider kernel).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Alexander Graf @ 2011-06-30 15:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Scott Wood, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20110629104103.GR25406@bloggs.ozlabs.ibm.com>
On 06/29/2011 12:41 PM, Paul Mackerras wrote:
> This new ioctl allows userspace to specify what paravirtualization
> interface (if any) KVM should implement, what architecture version
> the guest virtual processors should conform to, and whether the guest
> can be permitted to use a real supervisor mode.
>
> At present the only effect of the ioctl is to indicate whether the
> requested emulation is available, but in future it may be used to
> select between different emulation techniques (book3s_pr vs. book3s_hv)
> or set the CPU compatibility mode for the guest.
>
> If book3s_pr KVM is enabled in the kernel config, then this new
> ioctl accepts platform values of KVM_PPC_PV_NONE and KVM_PPC_PV_KVM,
> but not KVM_PPC_PV_SPAPR. If book3s_hv KVM is enabled, then this
> ioctl requires that the platform is KVM_PPC_PV_SPAPR and the
> guest_arch field contains one of 201 or 206 (for architecture versions
> 2.01 and 2.06) -- when running on a PPC970, it must contain 201, and
> when running on a POWER7, it must contain 206.
>
> Signed-off-by: Paul Mackerras<paulus@samba.org>
> ---
> Documentation/virtual/kvm/api.txt | 35 +++++++++++++++++++++++++++++++++++
> arch/powerpc/include/asm/kvm.h | 15 +++++++++++++++
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/kvm/powerpc.c | 28 ++++++++++++++++++++++++++++
> include/linux/kvm.h | 1 +
> 5 files changed, 80 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index b0e4b9c..3ab012c 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1430,6 +1430,41 @@ is supported; 2 if the processor requires all virtual machines to have
> an RMA, or 1 if the processor can use an RMA but doesn't require it,
> because it supports the Virtual RMA (VRMA) facility.
>
> +4.64 KVM_PPC_SET_PLATFORM
> +
> +Capability: none
> +Architectures: powerpc
> +Type: vm ioctl
> +Parameters: struct kvm_ppc_set_platform (in)
> +Returns: 0, or -1 on error
> +
> +This is used by userspace to tell KVM what sort of platform it should
> +emulate. The return value of the ioctl tells userspace whether the
> +emulation it is requesting is supported by KVM.
> +
> +struct kvm_ppc_set_platform {
> + __u16 platform; /* defines the OS/hypervisor ABI */
> + __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
> + __u32 flags;
Please add some padding so we can extend it later if necessary.
> +};
> +
> +/* Values for platform */
> +#define KVM_PPC_PV_NONE 0 /* bare-metal, non-paravirtualized */
> +#define KVM_PPC_PV_KVM 1 /* as defined in kvm_para.h */
> +#define KVM_PPC_PV_SPAPR 2 /* IBM Server PAPR (a la PowerVM) */
We also support BookE which would be useful to also include in the list.
Furthermore, KVM is more of a feature flag than a platform. We can
easily support KVM extensions on an SPAPR platform, no?
This whole interface also could deprecate the PVR setting one, so we can
simply include PVR as well and not require kernel space to jump through
hoops to figure out its capabilities.
And we need to identify 32-bit BookS processors, so we can go into
32-bit mode when necessary. That should also be a different guest_arch,
right?
> +
> +/* Values for flags */
> +#define KVM_PPC_CROSS_ARCH 1 /* guest architecture != host */
User space shouldn't have to worry about this one. It's up to the kernel
to decide that it's cross.
Alex
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
From: Artem Bityutskiy @ 2011-06-30 11:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, b35362, dwmw2, linux-mtd
In-Reply-To: <20110629114558.13975519@schlenkerla.am.freescale.net>
On Wed, 2011-06-29 at 11:45 -0500, Scott Wood wrote:
> On Wed, 29 Jun 2011 09:20:25 +0300
> Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> > On Tue, 2011-06-28 at 09:50 +0800, b35362@freescale.com wrote:
> > > From: Liu Shuo <b35362@freescale.com>
> > >
> > > The global data fsl_lbc_ctrl_dev->nand don't have to be freed in
> > > fsl_elbc_chip_remove(). The right place to do that is in fsl_elbc_nand_remove()
> > > if elbc_fcm_ctrl->counter is zero.
> > >
> > > Signed-off-by: Liu Shuo <b35362@freescale.com>
> > > ---
> > > drivers/mtd/nand/fsl_elbc_nand.c | 1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> > > index 0bb254c..a212116 100644
> > > --- a/drivers/mtd/nand/fsl_elbc_nand.c
> > > +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> > > @@ -829,7 +829,6 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
> > >
> > > elbc_fcm_ctrl->chips[priv->bank] = NULL;
> > > kfree(priv);
> > > - kfree(elbc_fcm_ctrl);
> > > return 0;
> > > }
> >
> > Do we have to assign fsl_lbc_ctrl_dev->nand to NULL in
> > fsl_elbc_nand_remove() then? I think that assignment can be killed then.
> >
> > if (!elbc_fcm_ctrl->counter) {
> > fsl_lbc_ctrl_dev->nand = NULL;
> > kfree(elbc_fcm_ctrl);
> > }
> >
>
> If we're freeing fsl_lbc_ctrl, we'd better get rid of references to it...
Yes, on the one hand this is a good defensive programming practice, on
the other hand it hides double-free bugs. Like this patch fixes a
double-free bug, and why it was noticed before? I thought may be because
of this NULL assignment?
I do not insist though, that was just a suggestion/question.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: [PATCH 2/2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-06-30 11:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, b35362, dwmw2, linux-mtd
In-Reply-To: <20110629114329.154aaef2@schlenkerla.am.freescale.net>
On Wed, 2011-06-29 at 11:43 -0500, Scott Wood wrote:
> On Wed, 29 Jun 2011 09:22:04 +0300
> Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> > On Tue, 2011-06-28 at 09:50 +0800, b35362@freescale.com wrote:
> > > + /* Hack for supporting the flash chip whose writesize is
> > > + * larger than 2K bytes.
> > > + */
> >
> > Please, use proper kernel multi-line comments. Please, make sure
> > checkpatch.pl does not generate 13 errors with this patch.
>
> Most of the checkpatch complaints are about existing style in the file --
> particularly, the use of tabs only for indentation, with spaces used for
> alignment beyond the indentation point.
OK, fair enough, but the multi-line comment is a valid complain,
although minor. And you guys could just fix the style issues as well in
a separate patch-set.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Problem with a driver in Linux-2.6.33
From: MohanReddy koppula @ 2011-06-30 9:20 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
I am writing a device driver for DSP Embedded Line and Port Interface Controller
PEB 20570 (Delic) from infineon. I am using MPC885 custom board. First we wrote
a driver without OS and tested transmission and reception, they are
working fine.
But when I port the same code to the Linux-2.6.33, the chip
initialization is done properly but
transmission and reception are not happening properly. Some times it
receives and transmits the
data but some times it doen't.
Please let me know where could the problem be and how I should
proceed. Is there any open source
driver available for this chip?.
Thanks,
Venkat.
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Avi Kivity @ 2011-06-30 8:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc, linuxppc-dev, Paul Mackerras, Alexander Graf, kvm
In-Reply-To: <20110629115857.GB17551@zod.rchland.ibm.com>
On 06/29/2011 02:58 PM, Josh Boyer wrote:
> >> This makes me wonder if a similar thing might eventually be usable for
> >> running an i686 or x32 guest on an x86_64 KVM host. I have no idea if
> >> that is even theoretically possible, but if it is it might be better to
> >> rename the ioctl to be architecture agnostic.
> >
> >On x86 this is not required unless we want to "virtualize" pre-CPUID CPUs. Everything as of Pentium has a full bitmap of feature capabilities that KVM gets from user space, including information such as "Can we do 64-bit mode?".
>
> Ah. Thank you for the explanation.
To clarify a bit further, running an i686 guest on an x86_64 host is not
only theoretically possible, but is done regularly. First, x86_64 is
backwards compatible with i686 (so you can install a 32-bit OS on 64-bit
hardware), and second, you can impersonate 32-bit guest hardware on a
64-bit host.
--
error compiling committee.c: too many arguments to function
^ 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