* [PATCH] USB_DR device support for FSL MPC831x
From: Vitaly Bordug @ 2007-07-17 0:58 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev
This adds support for USB device mode on mpc831x series.
Devicetree node modification is required to make it work -
dr_mode ="peripheral";
which should be commented out if host mode is desired onboot.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_soc.c | 1 +
include/linux/fsl_devices.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index c0ddc80..27a1510 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -514,6 +514,7 @@ static int __init fsl_usb_of_init(void)
}
} else if (prop && !strcmp(prop, "peripheral")) {
usb_data.operating_mode = FSL_USB2_DR_DEVICE;
+ usb_data.max_ep_nr = *(unsigned int*)of_get_property(np, "max_ep_nr",NULL);
usb_dev_dr_client = platform_device_register_simple(
"fsl-usb2-udc", i, r, 2);
if (IS_ERR(usb_dev_dr_client)) {
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 12e631f..a3feb34 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -103,6 +103,7 @@ struct fsl_usb2_platform_data {
enum fsl_usb2_operating_modes operating_mode;
enum fsl_usb2_phy_modes phy_mode;
unsigned int port_enables;
+ unsigned int max_ep_nr;
};
/* Flags in fsl_usb2_mph_platform_data */
^ permalink raw reply related
* [PATCH] USB_DR host support for FSL MPC831x
From: Vitaly Bordug @ 2007-07-17 0:58 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev
Modifies fsl_ehci code so that to get USB host working on
mpc831x platform. Verified with MPC8313RDB reference board.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8313erdb.dts | 1 +
drivers/usb/host/ehci-fsl.c | 4 +++-
drivers/usb/host/ehci-hcd.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 1b351dc..c330e79 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -90,6 +90,7 @@
interrupt-parent = < &ipic >;
interrupts = <26 8>;
phy_type = "utmi_wide";
+ control_init = <00000280>; // UTMI ext 48 MHz clk
};
mdio@24520 {
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c7a7c59..3e3187b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -185,12 +185,14 @@ static void mpc83xx_usb_setup(struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct fsl_usb2_platform_data *pdata;
void __iomem *non_ehci = hcd->regs;
+ u32 temp;
pdata =
(struct fsl_usb2_platform_data *)hcd->self.controller->
platform_data;
/* Enable PHY interface in the control reg. */
- out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x00000004);
+ temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
+ out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 099aff6..994a127 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -925,7 +925,7 @@ MODULE_LICENSE ("GPL");
#define PCI_DRIVER ehci_pci_driver
#endif
-#ifdef CONFIG_MPC834x
+#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
#include "ehci-fsl.c"
#define PLATFORM_DRIVER ehci_fsl_driver
#endif
^ permalink raw reply related
* [PATCH] POWERPC: add support of the GiGE switch for mpc8313RDB via fixed PHY
From: Vitaly Bordug @ 2007-07-17 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This utilises pretend phy, making access to it via device tree. GiGE switch
is connected to TSEC1 with fixed gigE link, so we need to emulate it
via artificial PHY to make it work.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8313erdb.dts | 1 +
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 43 +++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index a1533cc..1b351dc 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -100,6 +100,7 @@
#size-cells = <0>;
phy1: ethernet-phy@1 {
interrupt-parent = < &ipic >;
+ compatible = "fixed";
interrupts = <13 8>;
reg = <1>;
device_type = "ethernet-phy";
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index b410e67..5ee08fc 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -115,6 +115,49 @@ static int __init rtc_hookup(void)
late_initcall(rtc_hookup);
#endif
+#if defined(CONFIG_FIXED_MII_1000_FDX)
+
+static int fixed_set_link (void)
+{
+ struct fixed_info *phyinfo = fixed_mdio_get_phydev(0); /* only one fixed phy on this platform */
+ struct phy_device *phydev;
+ struct device_node *np;
+ struct device_node *child;
+ unsigned int i;
+ struct resource res;
+ int ret;
+ u32 *id = NULL;
+
+ if (!phyinfo)
+ return -ENXIO;
+ phydev = phyinfo->phydev;
+ if (!phydev)
+ return -ENXIO;
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL;
+ i++) {
+
+ memset(&res, 0, sizeof(res));
+
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret)
+ return ret;
+ child = of_find_compatible_node(np, "ethernet-phy","fixed");
+ if (!child)
+ return -ENXIO;
+ id = (u32*)of_get_property(child, "reg", NULL);
+ if (!id)
+ return -ENXIO;
+ break;
+ }
+ snprintf(phydev->dev.bus_id, BUS_ID_SIZE, PHY_ID_FMT, res.start, *id);
+ memset(phyinfo->regs,0xff,sizeof(phyinfo->regs[0])*phyinfo->regs_num);
+
+ return 0;
+}
+late_initcall(fixed_set_link);
+#endif
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
^ permalink raw reply related
* [PATCH] POWERPC: Added RTC support for mpc8313RDB and utilize "clock-frequency"
From: Vitaly Bordug @ 2007-07-17 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This enables DS1337 embedded RTC and uses "clock-frequency"
property to configure loops_per_jiffy. Fixed spaces vs tabs issue
in couple of places.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 52 ++++++++++++++++++++++++++++-
1 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 3edfe17..b410e67 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -14,6 +14,8 @@
*/
#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/rtc.h>
#include <asm/time.h>
#include <asm/ipic.h>
@@ -42,6 +44,17 @@ static void __init mpc8313_rdb_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc8313_rdb_setup_arch()", 0);
+ np = of_find_node_by_type(NULL, "cpu");
+ if (np != 0) {
+ const unsigned int *fp =
+ get_property(np, "clock-frequency", NULL);
+ if (fp != 0)
+ loops_per_jiffy = *fp / HZ;
+ else
+ loops_per_jiffy = 50000000 / HZ;
+ of_node_put(np);
+ }
+
#ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
mpc83xx_add_bridge(np);
@@ -67,14 +80,49 @@ void __init mpc8313_rdb_init_IRQ(void)
ipic_set_default_priority();
}
+#if defined (CONFIG_SENSORS_DS1337) && defined (CONFIG_I2C)
+
+extern int ds1337_do_command(int id, int cmd, void *arg);
+extern spinlock_t rtc_lock;
+#define DS1337_GET_DATE 0
+#define DS1337_SET_DATE 1
+
+static void mpc8313rdb_get_rtc_time(struct rtc_time *tm)
+{
+ int result;
+
+ result = ds1337_do_command(0, DS1337_GET_DATE, tm);
+
+ if (result == 0)
+ result = mktime(tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
+}
+
+static int mpc8313rdb_set_rtc_time(struct rtc_time *tm)
+{
+ int result;
+
+ result = ds1337_do_command(0, DS1337_SET_DATE, tm);
+
+ return result;
+}
+
+static int __init rtc_hookup(void)
+{
+ ppc_md.get_rtc_time = mpc8313rdb_get_rtc_time;
+ ppc_md.set_rtc_time = mpc8313rdb_set_rtc_time;
+ return 0;
+}
+late_initcall(rtc_hookup);
+#endif
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
static int __init mpc8313_rdb_probe(void)
{
- unsigned long root = of_get_flat_dt_root();
+ unsigned long root = of_get_flat_dt_root();
- return of_flat_dt_is_compatible(root, "MPC8313ERDB");
+ return of_flat_dt_is_compatible(root, "MPC8313ERDB");
}
define_machine(mpc8313_rdb) {
^ permalink raw reply related
* Re: [PATCH 0/3] 82xx: Add the support for Wind River SBC PowerQUICCII
From: Vitaly Bordug @ 2007-07-17 0:44 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev, paulus
In-Reply-To: <469B33E8.8010105@windriver.com>
On Mon, 16 Jul 2007 17:01:28 +0800
Mark Zhan wrote:
> These 3 patches add the powerpc support of Wind River SBC
> PowerQUICCII.
>
I am sorry, but this would intercept with big 8xx/82xx series from
Scott Wood I am reviewing now. it makes the initial merged code
more maintainable and powerpc-friendly, but would have some rework
required in upcoming patches for new BSPs.
OTOH, it would make all the changes below very short and apparent.
Of course, if something would block those series this one can be considered to merge.
> 1) Currently, some mpc82xx platform hooks in mpc82xx_ads.c are
> actually not specific to ads board. So the 1st patch makes them be
> shared by different 82xx boards.
>
> 2) The 2nd patch make 'cpm_uart_of_init' be able to parse SMC uart in
> DTS
>
> 3) The 3rd patch is the platform codes, defconfig and dts for Wind
> River SBC PowerQUICCII 82xx board.
>
> Any comment is welcome.
>
> Thanks
> Mark Zhan
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* [PATCH] PHY fixed driver: rework release path and update phy_id notation
From: Vitaly Bordug @ 2007-07-17 0:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
device_bind_driver() error code returning has been fixed.
release() function has been written, so that to free resources
in correct way; the release path is now clean.
Before the rework, it used to cause
Device 'fixed@100:1' does not have a release() function, it is broken
and must be fixed.
BUG: at drivers/base/core.c:104 device_release()
Call Trace:
[<ffffffff802ec380>] kobject_cleanup+0x53/0x7e
[<ffffffff802ec3ab>] kobject_release+0x0/0x9
[<ffffffff802ecf3f>] kref_put+0x74/0x81
[<ffffffff8035493b>] fixed_mdio_register_device+0x230/0x265
[<ffffffff80564d31>] fixed_init+0x1f/0x35
[<ffffffff802071a4>] init+0x147/0x2fb
[<ffffffff80223b6e>] schedule_tail+0x36/0x92
[<ffffffff8020a678>] child_rip+0xa/0x12
[<ffffffff80311714>] acpi_ds_init_one_object+0x0/0x83
[<ffffffff8020705d>] init+0x0/0x2fb
[<ffffffff8020a66e>] child_rip+0x0/0x12
Also changed the notation of the fixed phy definition on
mdio bus to the form of <speed>+<duplex> to make it able to be used by
gianfar and ucc_geth that define phy_id strictly as "%d:%d" and cleaned up
the whitespace issues.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/net/phy/Kconfig | 14 ++
drivers/net/phy/fixed.c | 310 ++++++++++++++++++++++++-----------------------
2 files changed, 169 insertions(+), 155 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index dd09011..432c210 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -76,4 +76,18 @@ config FIXED_MII_100_FDX
bool "Emulation for 100M Fdx fixed PHY behavior"
depends on FIXED_PHY
+config FIXED_MII_1000_FDX
+ bool "Emulation for 1000M Fdx fixed PHY behavior"
+ depends on FIXED_PHY
+
+config FIXED_MII_AMNT
+ int "Number of emulated PHYs to allocate "
+ depends on FIXED_PHY
+ default "1"
+ ---help---
+ Sometimes it is required to have several independent emulated
+ PHYs on the bus (in case of multi-eth but phy-less HW for instance).
+ This control will have specified number allocated for each fixed
+ PHY type enabled.
+
endif # PHYLIB
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index bb96691..5619182 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -30,53 +30,31 @@
#include <linux/mii.h>
#include <linux/ethtool.h>
#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include <asm/io.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
-#define MII_REGS_NUM 7
-
-/*
- The idea is to emulate normal phy behavior by responding with
- pre-defined values to mii BMCR read, so that read_status hook could
- take all the needed info.
-*/
-
-struct fixed_phy_status {
- u8 link;
- u16 speed;
- u8 duplex;
-};
-
-/*-----------------------------------------------------------------------------
- * Private information hoder for mii_bus
- *-----------------------------------------------------------------------------*/
-struct fixed_info {
- u16 *regs;
- u8 regs_num;
- struct fixed_phy_status phy_status;
- struct phy_device *phydev; /* pointer to the container */
- /* link & speed cb */
- int(*link_update)(struct net_device*, struct fixed_phy_status*);
-
-};
+/* we need to track the allocated pointers in order to free them on exit */
+static struct fixed_info *fixed_phy_ptrs[CONFIG_FIXED_MII_AMNT*MAX_PHY_AMNT];
/*-----------------------------------------------------------------------------
* If something weird is required to be done with link/speed,
* network driver is able to assign a function to implement this.
* May be useful for PHY's that need to be software-driven.
*-----------------------------------------------------------------------------*/
-int fixed_mdio_set_link_update(struct phy_device* phydev,
- int(*link_update)(struct net_device*, struct fixed_phy_status*))
+int fixed_mdio_set_link_update(struct phy_device *phydev,
+ int (*link_update) (struct net_device *,
+ struct fixed_phy_status *))
{
struct fixed_info *fixed;
- if(link_update == NULL)
+ if (link_update == NULL)
return -EINVAL;
- if(phydev) {
- if(phydev->bus) {
+ if (phydev) {
+ if (phydev->bus) {
fixed = phydev->bus->priv;
fixed->link_update = link_update;
return 0;
@@ -84,54 +62,64 @@ int fixed_mdio_set_link_update(struct phy_device* phydev,
}
return -EINVAL;
}
+
EXPORT_SYMBOL(fixed_mdio_set_link_update);
+struct fixed_info *fixed_mdio_get_phydev (int phydev_ind)
+{
+ if (phydev_ind >= MAX_PHY_AMNT)
+ return NULL;
+ return fixed_phy_ptrs[phydev_ind];
+}
+
+EXPORT_SYMBOL(fixed_mdio_get_phydev);
+
/*-----------------------------------------------------------------------------
* This is used for updating internal mii regs from the status
*-----------------------------------------------------------------------------*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX)
+#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX) || defined(CONFIG_FIXED_MII_1000_FDX)
static int fixed_mdio_update_regs(struct fixed_info *fixed)
{
u16 *regs = fixed->regs;
u16 bmsr = 0;
u16 bmcr = 0;
- if(!regs) {
+ if (!regs) {
printk(KERN_ERR "%s: regs not set up", __FUNCTION__);
return -EINVAL;
}
- if(fixed->phy_status.link)
+ if (fixed->phy_status.link)
bmsr |= BMSR_LSTATUS;
- if(fixed->phy_status.duplex) {
+ if (fixed->phy_status.duplex) {
bmcr |= BMCR_FULLDPLX;
- switch ( fixed->phy_status.speed ) {
+ switch (fixed->phy_status.speed) {
case 100:
bmsr |= BMSR_100FULL;
bmcr |= BMCR_SPEED100;
- break;
+ break;
case 10:
bmsr |= BMSR_10FULL;
- break;
+ break;
}
} else {
- switch ( fixed->phy_status.speed ) {
+ switch (fixed->phy_status.speed) {
case 100:
bmsr |= BMSR_100HALF;
bmcr |= BMCR_SPEED100;
- break;
+ break;
case 10:
bmsr |= BMSR_100HALF;
- break;
+ break;
}
}
- regs[MII_BMCR] = bmcr;
- regs[MII_BMSR] = bmsr | 0x800; /*we are always capable of 10 hdx*/
+ regs[MII_BMCR] = bmcr;
+ regs[MII_BMSR] = bmsr | 0x800; /*we are always capable of 10 hdx */
return 0;
}
@@ -141,29 +129,30 @@ static int fixed_mii_read(struct mii_bus *bus, int phy_id, int location)
struct fixed_info *fixed = bus->priv;
/* if user has registered link update callback, use it */
- if(fixed->phydev)
- if(fixed->phydev->attached_dev) {
- if(fixed->link_update) {
+ if (fixed->phydev)
+ if (fixed->phydev->attached_dev) {
+ if (fixed->link_update) {
fixed->link_update(fixed->phydev->attached_dev,
- &fixed->phy_status);
+ &fixed->phy_status);
fixed_mdio_update_regs(fixed);
}
- }
+ }
if ((unsigned int)location >= fixed->regs_num)
return -1;
return fixed->regs[location];
}
-static int fixed_mii_write(struct mii_bus *bus, int phy_id, int location, u16 val)
+static int fixed_mii_write(struct mii_bus *bus, int phy_id, int location,
+ u16 val)
{
- /* do nothing for now*/
+ /* do nothing for now */
return 0;
}
static int fixed_mii_reset(struct mii_bus *bus)
{
- /*nothing here - no way/need to reset it*/
+ /*nothing here - no way/need to reset it */
return 0;
}
#endif
@@ -171,8 +160,8 @@ static int fixed_mii_reset(struct mii_bus *bus)
static int fixed_config_aneg(struct phy_device *phydev)
{
/* :TODO:03/13/2006 09:45:37 PM::
- The full autoneg funcionality can be emulated,
- but no need to have anything here for now
+ The full autoneg funcionality can be emulated,
+ but no need to have anything here for now
*/
return 0;
}
@@ -182,59 +171,79 @@ static int fixed_config_aneg(struct phy_device *phydev)
* match will never return true...
*-----------------------------------------------------------------------------*/
static struct phy_driver fixed_mdio_driver = {
- .name = "Fixed PHY",
- .features = PHY_BASIC_FEATURES,
- .config_aneg = fixed_config_aneg,
- .read_status = genphy_read_status,
- .driver = { .owner = THIS_MODULE,},
+ .name = "Fixed PHY",
+#ifdef CONFIG_FIXED_MII_1000_FDX
+ .features = PHY_GBIT_FEATURES,
+#else
+ .features = PHY_BASIC_FEATURES,
+#endif
+ .config_aneg = fixed_config_aneg,
+ .read_status = genphy_read_status,
+ .driver = { .owner = THIS_MODULE, },
};
+static void fixed_mdio_release(struct device *dev)
+{
+ struct phy_device *phydev = container_of(dev, struct phy_device, dev);
+ struct mii_bus *bus = phydev->bus;
+ struct fixed_info *fixed = bus->priv;
+
+ kfree(phydev);
+ kfree(bus->dev);
+ kfree(bus);
+ kfree(fixed->regs);
+ kfree(fixed);
+}
+
/*-----------------------------------------------------------------------------
* This func is used to create all the necessary stuff, bind
* the fixed phy driver and register all it on the mdio_bus_type.
- * speed is either 10 or 100, duplex is boolean.
+ * speed is either 10 or 100 or 1000, duplex is boolean.
* number is used to create multiple fixed PHYs, so that several devices can
* utilize them simultaneously.
+ *
+ * The device on mdio bus will look like [bus_id]:[phy_id],
+ * bus_id = number
+ * phy_id = speed+duplex.
*-----------------------------------------------------------------------------*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX)
-static int fixed_mdio_register_device(int number, int speed, int duplex)
+#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX) || defined(CONFIG_FIXED_MII_1000_FDX)
+struct fixed_info *fixed_mdio_register_device(
+ int bus_id, int speed, int duplex, u8 phy_id)
{
struct mii_bus *new_bus;
struct fixed_info *fixed;
struct phy_device *phydev;
- int err = 0;
+ int err;
- struct device* dev = kzalloc(sizeof(struct device), GFP_KERNEL);
+ struct device *dev = kzalloc(sizeof(struct device), GFP_KERNEL);
- if (NULL == dev)
- return -ENOMEM;
+ if (dev == NULL)
+ goto err_dev_alloc;
new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
- if (NULL == new_bus) {
- kfree(dev);
- return -ENOMEM;
- }
+ if (new_bus == NULL)
+ goto err_bus_alloc;
+
fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
- if (NULL == fixed) {
- kfree(dev);
- kfree(new_bus);
- return -ENOMEM;
- }
+ if (fixed == NULL)
+ goto err_fixed_alloc;
+
+ fixed->regs = kzalloc(MII_REGS_NUM * sizeof(int), GFP_KERNEL);
+ if (NULL == fixed->regs)
+ goto err_fixed_regs_alloc;
- fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
fixed->regs_num = MII_REGS_NUM;
fixed->phy_status.speed = speed;
fixed->phy_status.duplex = duplex;
fixed->phy_status.link = 1;
- new_bus->name = "Fixed MII Bus",
- new_bus->read = &fixed_mii_read,
- new_bus->write = &fixed_mii_write,
- new_bus->reset = &fixed_mii_reset,
-
- /*set up workspace*/
+ new_bus->name = "Fixed MII Bus";
+ new_bus->read = &fixed_mii_read;
+ new_bus->write = &fixed_mii_write;
+ new_bus->reset = &fixed_mii_reset;
+ /*set up workspace */
fixed_mdio_update_regs(fixed);
new_bus->priv = fixed;
@@ -243,119 +252,110 @@ static int fixed_mdio_register_device(int number, int speed, int duplex)
/* create phy_device and register it on the mdio bus */
phydev = phy_device_create(new_bus, 0, 0);
+ if (phydev == NULL)
+ goto err_phy_dev_create;
/*
- Put the phydev pointer into the fixed pack so that bus read/write code could
- be able to access for instance attached netdev. Well it doesn't have to do
- so, only in case of utilizing user-specified link-update...
+ * Put the phydev pointer into the fixed pack so that bus read/write
+ * code could be able to access for instance attached netdev. Well it
+ * doesn't have to do so, only in case of utilizing user-specified
+ * link-update...
*/
- fixed->phydev = phydev;
- if(NULL == phydev) {
- err = -ENOMEM;
- goto device_create_fail;
- }
+ fixed->phydev = phydev;
+ phydev->speed = speed;
+ phydev->duplex = duplex;
phydev->irq = PHY_IGNORE_INTERRUPT;
phydev->dev.bus = &mdio_bus_type;
- if(number)
- snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
- "fixed_%d@%d:%d", number, speed, duplex);
- else
- snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
- "fixed@%d:%d", speed, duplex);
- phydev->bus = new_bus;
+ snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
+ PHY_ID_FMT, bus_id, phy_id);
- err = device_register(&phydev->dev);
- if(err) {
- printk(KERN_ERR "Phy %s failed to register\n",
- phydev->dev.bus_id);
- goto bus_register_fail;
- }
+ phydev->bus = new_bus;
- /*
- the mdio bus has phy_id match... In order not to do it
- artificially, we are binding the driver here by hand;
- it will be the same for all the fixed phys anyway.
- */
phydev->dev.driver = &fixed_mdio_driver.driver;
-
+ phydev->dev.release = fixed_mdio_release;
err = phydev->dev.driver->probe(&phydev->dev);
- if(err < 0) {
- printk(KERN_ERR "Phy %s: problems with fixed driver\n",phydev->dev.bus_id);
- goto probe_fail;
+ if (err < 0) {
+ printk(KERN_ERR "Phy %s: problems with fixed driver\n",
+ phydev->dev.bus_id);
+ goto err_out;
}
+ err = device_register(&phydev->dev);
+ if (err) {
+ printk(KERN_ERR "Phy %s failed to register\n",
+ phydev->dev.bus_id);
+ goto err_out;
+ }
+ //phydev->state = PHY_RUNNING; /* make phy go up quick, but in 10Mbit/HDX
+ return fixed;
- err = device_bind_driver(&phydev->dev);
- if (err)
- goto probe_fail;
-
- return 0;
-
-probe_fail:
- device_unregister(&phydev->dev);
-bus_register_fail:
+err_out:
kfree(phydev);
-device_create_fail:
- kfree(dev);
- kfree(new_bus);
+err_phy_dev_create:
+ kfree(fixed->regs);
+err_fixed_regs_alloc:
kfree(fixed);
+err_fixed_alloc:
+ kfree(new_bus);
+err_bus_alloc:
+ kfree(dev);
+err_dev_alloc:
+
+ return NULL;
- return err;
}
#endif
-
MODULE_DESCRIPTION("Fixed PHY device & driver for PAL");
MODULE_AUTHOR("Vitaly Bordug");
MODULE_LICENSE("GPL");
static int __init fixed_init(void)
{
-#if 0
- int ret;
- int duplex = 0;
-#endif
-
- /* register on the bus... Not expected to be matched with anything there... */
+ int cnt = 0;
+ int i;
+/* register on the bus... Not expected to be matched
+ * with anything there...
+ *
+ */
phy_driver_register(&fixed_mdio_driver);
- /* So let the fun begin...
- We will create several mdio devices here, and will bound the upper
- driver to them.
-
- Then the external software can lookup the phy bus by searching
- fixed@speed:duplex, e.g. fixed@100:1, to be connected to the
- virtual 100M Fdx phy.
-
- In case several virtual PHYs required, the bus_id will be in form
- fixed_<num>@<speed>:<duplex>, which make it able even to define
- driver-specific link control callback, if for instance PHY is completely
- SW-driven.
-
- */
-
-#ifdef CONFIG_FIXED_MII_DUPLEX
-#if 0
- duplex = 1;
-#endif
+/* We will create several mdio devices here, and will bound the upper
+ * driver to them.
+ *
+ * Then the external software can lookup the phy bus by searching
+ * for 0:101, to be connected to the virtual 100M Fdx phy.
+ *
+ * In case several virtual PHYs required, the bus_id will be in form
+ * [num]:[duplex]+[speed], which make it able even to define
+ * driver-specific link control callback, if for instance PHY is
+ * completely SW-driven.
+ */
+ for (i=1; i <= CONFIG_FIXED_MII_AMNT; i++) {
+#ifdef CONFIG_FIXED_MII_1000_FDX
+ fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(0, 1000, 1, i);
#endif
-
#ifdef CONFIG_FIXED_MII_100_FDX
- fixed_mdio_register_device(0, 100, 1);
+ fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(1, 100, 1, i);
#endif
-
#ifdef CONFIG_FIXED_MII_10_FDX
- fixed_mdio_register_device(0, 10, 1);
+ fixed_phy_ptrs[cnt++] = fixed_mdio_register_device(2, 10, 1, i);
#endif
+ }
+
return 0;
}
static void __exit fixed_exit(void)
{
+ int i;
+
phy_driver_unregister(&fixed_mdio_driver);
- /* :WARNING:02/18/2006 04:32:40 AM:: Cleanup all the created stuff */
+ for (i=0; i < MAX_PHY_AMNT; i++)
+ if ( fixed_phy_ptrs[i] )
+ device_unregister(&fixed_phy_ptrs[i]->phydev->dev);
}
module_init(fixed_init);
^ permalink raw reply related
* Re: [PATCH 1/2] adb: create class devices for each adb device
From: Benjamin Herrenschmidt @ 2007-07-16 23:22 UTC (permalink / raw)
To: Aristeu Rozanski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070716205319.GC30232@cathedrallabs.org>
On Mon, 2007-07-16 at 16:53 -0400, Aristeu Rozanski wrote:
> This patch adds a class device for each adb device that has a handler.
> The class device contents will be accessible by /sys/class/adb/<handler>N
> directory. This patch is needed in order to add an class device
> attribute to all keyboards that will determine the sysrq key for each
> keyboard.
I don't think class device is the right approach. Classes are supposed
to be a functional binding, ie, in this case, input devices. ADB is a
bus, and as such, you should create an adb bus type and and adb_device
that is an extension of struct device, not struct class device.
There's also the question of what to do on ADB resets (such as when
doing a sleep/wakeup cycle). Should we wipe out all devices and
re-created them, thus loosing any settings ? Or should we have some way
to attempt at re-matching existing ones ?
Cheers,
Ben.
> Signed-of-by: Aristeu Rozanski <aris@ruivo.org>
>
> --- linus-2.6.orig/drivers/macintosh/adb.c 2007-05-11 10:09:13.000000000 -0400
> +++ linus-2.6/drivers/macintosh/adb.c 2007-05-11 10:09:36.000000000 -0400
> @@ -102,11 +102,21 @@
> static void adbdev_init(void);
> static int try_handler_change(int, int);
>
> +static char *adb_device_id_string[] = {
> + [ADB_DONGLE] = "dongle",
> + [ADB_KEYBOARD] = "keyboard",
> + [ADB_MOUSE] = "mouse",
> + [ADB_TABLET] = "tablet",
> + [ADB_MODEM] = "modem",
> + [ADB_MISC] = "misc",
> +};
> +
> static struct adb_handler {
> void (*handler)(unsigned char *, int, int);
> int original_address;
> int handler_id;
> int busy;
> + char name[16];
> } adb_handler[16];
>
> /*
> @@ -508,6 +518,9 @@
> if ((adb_handler[i].original_address == default_id) &&
> (!handler_id || (handler_id == adb_handler[i].handler_id) ||
> try_handler_change(i, handler_id))) {
> + int rc;
> + struct class_device *cdev;
> +
> if (adb_handler[i].handler != 0) {
> printk(KERN_ERR
> "Two handlers for ADB device %d\n",
> @@ -517,7 +530,26 @@
> write_lock_irq(&adb_handler_lock);
> adb_handler[i].handler = handler;
> write_unlock_irq(&adb_handler_lock);
> - ids->id[ids->nids++] = i;
> +
> + snprintf(adb_handler[i].name,
> + sizeof(adb_handler[i].name), "%s%i",
> + adb_device_id_string[default_id], ids->nids);
> +
> + cdev = &ids->id[ids->nids].cdev;
> + cdev->class = adb_dev_class;
> + class_device_initialize(cdev);
> + snprintf(cdev->class_id, sizeof(cdev->class_id), "%s",
> + adb_handler[i].name);
> + rc = class_device_add(cdev);
> + if (rc) {
> + printk(KERN_WARNING "adb: unable to add class "
> + "device\n");
> + for (i = ids->nids - 1; i >= 0; i--)
> + class_device_del(&ids->id[i].cdev);
> + ids->nids = 0;
> + return 0;
> + }
> + ids->id[ids->nids++].id = i;
> }
> }
> up(&adb_handler_sem);
> @@ -525,9 +557,9 @@
> }
>
> int
> -adb_unregister(int index)
> +adb_unregister(int index, struct adb_ids *ids)
> {
> - int ret = -ENODEV;
> + int i, ret = -ENODEV;
>
> down(&adb_handler_sem);
> write_lock_irq(&adb_handler_lock);
> @@ -539,6 +571,8 @@
> }
> ret = 0;
> adb_handler[index].handler = NULL;
> + for (i = 0; i < ids->nids; i++)
> + class_device_del(&ids->id[i].cdev);
> }
> write_unlock_irq(&adb_handler_lock);
> up(&adb_handler_sem);
> --- linus-2.6.orig/include/linux/adb.h 2007-05-11 10:09:13.000000000 -0400
> +++ linus-2.6/include/linux/adb.h 2007-05-11 10:09:36.000000000 -0400
> @@ -3,6 +3,7 @@
> */
> #ifndef __ADB_H
> #define __ADB_H
> +#include <linux/device.h>
>
> /* ADB commands */
> #define ADB_BUSRESET 0
> @@ -57,7 +58,11 @@
>
> struct adb_ids {
> int nids;
> - unsigned char id[16];
> + struct adb_id {
> + unsigned char id;
> + struct class_device cdev;
> + void *priv;
> + } id[16];
> };
>
> /* Structure which encapsulates a low-level ADB driver */
> @@ -91,7 +96,7 @@
> int flags, int nbytes, ...);
> int adb_register(int default_id,int handler_id,struct adb_ids *ids,
> void (*handler)(unsigned char *, int, int));
> -int adb_unregister(int index);
> +int adb_unregister(int index, struct adb_ids *ids);
> void adb_poll(void);
> void adb_input(unsigned char *, int, int);
> int adb_reset_bus(void);
> --- linus-2.6.orig/drivers/macintosh/adbhid.c 2007-05-11 10:09:19.000000000 -0400
> +++ linus-2.6/drivers/macintosh/adbhid.c 2007-05-11 10:10:15.000000000 -0400
> @@ -875,7 +875,7 @@
> adb_register(ADB_MISC, 0, &buttons_ids, adbhid_buttons_input);
>
> for (i = 0; i < keyboard_ids.nids; i++) {
> - int id = keyboard_ids.id[i];
> + int id = keyboard_ids.id[i].id;
>
> adb_get_infos(id, &default_id, &org_handler_id);
>
> @@ -902,7 +902,7 @@
> }
>
> for (i = 0; i < buttons_ids.nids; i++) {
> - int id = buttons_ids.id[i];
> + int id = buttons_ids.id[i].id;
>
> adb_get_infos(id, &default_id, &org_handler_id);
> reg |= adbhid_input_reregister(id, default_id, org_handler_id,
> @@ -912,7 +912,7 @@
> /* Try to switch all mice to handler 4, or 2 for three-button
> mode and full resolution. */
> for (i = 0; i < mouse_ids.nids; i++) {
> - int id = mouse_ids.id[i];
> + int id = mouse_ids.id[i].id;
> int mouse_kind;
>
> adb_get_infos(id, &default_id, &org_handler_id);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] adbhid: enable KEY_FN key reporting
From: Benjamin Herrenschmidt @ 2007-07-16 23:20 UTC (permalink / raw)
To: Aristeu Rozanski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070716205309.GA30232@cathedrallabs.org>
On Mon, 2007-07-16 at 16:53 -0400, Aristeu Rozanski wrote:
> When a Fn key is used in combination with another key in ADB keyboards
> it will generate a Fn event and then a second event that can be a
> different key than pressed (Fn + F1 for instance can generate Fn +
> brightness down if it's configured like that). This patch enables the
> reporting of the Fn key to the input system.
>
> As Fn is a dead key for most purposes, it's useful to report it so
> applications can make use of it. One example is apple_mouse
> (https://jake.ruivo.org/uinputd/trunk/apple_mouse/) that emulates the
> second and third keys using a combination of keyboard keys and the mouse
> button. Other applications may use the KEY_FN as a modifier aswell.
> I've been updating and using this patch for months without problems.
>
> Signed-off-by: Aristeu Rozanski <aris@ruivo.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> --- linus-2.6.orig/drivers/macintosh/adbhid.c 2007-05-11 10:09:13.000000000 -0400
> +++ linus-2.6/drivers/macintosh/adbhid.c 2007-05-11 10:09:19.000000000 -0400
> @@ -70,7 +70,7 @@
> #define ADB_KEY_POWER_OLD 0x7e
> #define ADB_KEY_POWER 0x7f
>
> -u8 adb_to_linux_keycodes[128] = {
> +u16 adb_to_linux_keycodes[128] = {
> /* 0x00 */ KEY_A, /* 30 */
> /* 0x01 */ KEY_S, /* 31 */
> /* 0x02 */ KEY_D, /* 32 */
> @@ -134,7 +134,7 @@
> /* 0x3c */ KEY_RIGHT, /* 106 */
> /* 0x3d */ KEY_DOWN, /* 108 */
> /* 0x3e */ KEY_UP, /* 103 */
> - /* 0x3f */ 0,
> + /* 0x3f */ KEY_FN, /* 0x1d0 */
> /* 0x40 */ 0,
> /* 0x41 */ KEY_KPDOT, /* 83 */
> /* 0x42 */ 0,
> @@ -208,7 +208,7 @@
> int original_handler_id;
> int current_handler_id;
> int mouse_kind;
> - unsigned char *keycode;
> + u16 *keycode;
> char name[64];
> char phys[32];
> int flags;
> @@ -275,7 +275,7 @@
> adbhid_input_keycode(int id, int keycode, int repeat)
> {
> struct adbhid *ahid = adbhid[id];
> - int up_flag;
> + int up_flag, key;
>
> up_flag = (keycode & 0x80);
> keycode &= 0x7f;
> @@ -321,8 +321,7 @@
> }
> } else
> ahid->flags |= FLAG_FN_KEY_PRESSED;
> - /* Swallow the key press */
> - return;
> + break;
> case ADB_KEY_DEL:
> /* Emulate Fn+delete = forward delete */
> if (ahid->flags & FLAG_FN_KEY_PRESSED) {
> @@ -336,9 +335,9 @@
> #endif /* CONFIG_PPC_PMAC */
> }
>
> - if (adbhid[id]->keycode[keycode]) {
> - input_report_key(adbhid[id]->input,
> - adbhid[id]->keycode[keycode], !up_flag);
> + key = adbhid[id]->keycode[keycode];
> + if (key) {
> + input_report_key(adbhid[id]->input, key, !up_flag);
> input_sync(adbhid[id]->input);
> } else
> printk(KERN_INFO "Unhandled ADB key (scancode %#02x) %s.\n", keycode,
> @@ -757,8 +756,8 @@
> input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_LED) | BIT(EV_REP);
> input_dev->ledbit[0] = BIT(LED_SCROLLL) | BIT(LED_CAPSL) | BIT(LED_NUML);
> input_dev->event = adbhid_kbd_event;
> - input_dev->keycodemax = 127;
> - input_dev->keycodesize = 1;
> + input_dev->keycodemax = KEY_FN;
> + input_dev->keycodesize = sizeof(hid->keycode[0]);
> break;
>
> case ADB_MOUSE:
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-16 22:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <469BEECC.6070404@freescale.com>
On Mon, 2007-07-16 at 17:18 -0500, Scott Wood wrote:
>
> OK... but if you're doing a pure IRQ number conversion, the only useful
> #address-cells would be zero, which makes it a reasonable default IMHO
> (unlike the arbitrary 2 for regular traversal).
It does make a reasonable default. The thing, as I exlained, is I
dislike the whole idea of "default" values in the first place.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Fix Tsi108 ethernet driver performance
From: Jeff Garzik @ 2007-07-16 22:27 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: netdev, linuxppc-dev
In-Reply-To: <1B5F013528140F45B5C671039279CA5701F834BB@NANUK.pc.tundra.com>
Alexandre Bounine wrote:
> From: Alexandre Bounine <alexandreb@tundra.com>
>
> This patch improves performance of the Tsi108 Ethernet driver by
> changing interrupt handling for frame receive path. It reduces number of
> interrupts generated for received frames and therefore lowers CPU
> utilization by the device driver.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
Look into NAPI...
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Scott Wood @ 2007-07-16 22:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <1184623898.25235.96.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> No, interrupt maps are useful in devices with no children in some corner
> cases. Remember that a map doesnt need to use the address part of the
> source specifier, thus it can be used to do a pure domain->domain
> conversion of the irq numbers, what sort of thing. The map has the added
> advantage that today, it's the only mechanism that allows you to specify
> different interrupt-parents through the same nexus, which is useful for
> 4xx.
OK... but if you're doing a pure IRQ number conversion, the only useful
#address-cells would be zero, which makes it a reasonable default IMHO
(unlike the arbitrary 2 for regular traversal).
-Scott
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-07-16 22:12 UTC (permalink / raw)
To: James Bottomley
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras,
Jens Axboe, Geert Uytterhoeven
In-Reply-To: <1184623415.3447.48.camel@localhost.localdomain>
On Mon, 2007-07-16 at 17:03 -0500, James Bottomley wrote:
> On Tue, 2007-07-17 at 07:49 +1000, Benjamin Herrenschmidt wrote:
> > > No ... that was the point of flush_kernel_dcache_page(). The page in
> > > question is page cache backed and contains user mappings. However, the
> > > block layer has already done a flush_dcache_page() in get_user_pages()
> > > and the user shouldn't be touching memory under I/O (unless they want
> > > self induced aliasing problems) so we're free to assume all the user
> > > cachelines are purged, hence all we have to do is flush the kernel alias
> > > to bring the page up to date and make the users see it correctly.
> >
> > The block layer will have done that even in the swap-out path ? (Just
> > asking... I'm not very familiar with the block layer)
>
> Er ... not really, this is the I/O path for user initiated I/O. The
> page out path, by definition, can't have any extant user mappings. For
> page out, the relevant page is flushed before its mapping is detached,
> and then it can be paged to the backing store (or for anonymous pages to
> the swap device) when no mappings remain.
Ok, thanks.
Ben.
^ permalink raw reply
* RE: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-16 22:12 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA303067256@az33exm25.fsl.freescale.net>
> > I would personally be inclined to define that whatever spec we come up
> > with always require #address-cells/#size-cells for any node that can
> > have either device children or interrupt children, and ban default
> > values alltogether.
>
> Did you really mean #size-cells here? Shouldn't it be #interrupt-cells?
Yup, as I said, my fingers got a bit too fast on the keyboard. I means
#interrupt-cells.
Ben.
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-16 22:11 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <469BE93E.1070702@freescale.com>
On Mon, 2007-07-16 at 16:55 -0500, Scott Wood wrote:
> Benjamin Herrenschmidt wrote:
> > I would personally be inclined to define that whatever spec we come up
> > with always require #address-cells/#size-cells for any node that can
> > have either device children or interrupt children, and ban default
> > values alltogether.
>
> When is #size-cells used in the interrupt tree at all?
It's not, sorry, my fingers typed a bit too fast :-)
> And given the odd behavior of using an interrupt map in an interrupt
> parent that is not the device parent (you're potentially using keys from
> different domains that could clash, be a different sizes, etc), if we
> make any changes in that regard, I'd forbid interrupt maps in interrupt
> controllers with no device children, and thus #address-cells has no
> meaning there.
No, interrupt maps are useful in devices with no children in some corner
cases. Remember that a map doesnt need to use the address part of the
source specifier, thus it can be used to do a pure domain->domain
conversion of the irq numbers, what sort of thing. The map has the added
advantage that today, it's the only mechanism that allows you to specify
different interrupt-parents through the same nexus, which is useful for
4xx.
Ben.
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: James Bottomley @ 2007-07-16 22:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras,
Jens Axboe, Geert Uytterhoeven
In-Reply-To: <1184622555.25235.91.camel@localhost.localdomain>
On Tue, 2007-07-17 at 07:49 +1000, Benjamin Herrenschmidt wrote:
> > No ... that was the point of flush_kernel_dcache_page(). The page in
> > question is page cache backed and contains user mappings. However, the
> > block layer has already done a flush_dcache_page() in get_user_pages()
> > and the user shouldn't be touching memory under I/O (unless they want
> > self induced aliasing problems) so we're free to assume all the user
> > cachelines are purged, hence all we have to do is flush the kernel alias
> > to bring the page up to date and make the users see it correctly.
>
> The block layer will have done that even in the swap-out path ? (Just
> asking... I'm not very familiar with the block layer)
Er ... not really, this is the I/O path for user initiated I/O. The
page out path, by definition, can't have any extant user mappings. For
page out, the relevant page is flushed before its mapping is detached,
and then it can be paged to the backing store (or for anonymous pages to
the swap device) when no mappings remain.
James
^ permalink raw reply
* Re: [PATCH 1/1] eHEA: Introducing support vor DLPAR memory add
From: Jeff Garzik @ 2007-07-16 21:59 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Jan-Bernd Themann,
Marcus Eder
In-Reply-To: <200707111632.00235.osstklei@de.ibm.com>
Thomas Klein wrote:
> This patch adds support for DLPAR memory add to the eHEA driver. To detect
> whether memory was added the driver uses its own memory mapping table and
> checks for kernel addresses whether they're located in already known memory
> sections. If not the function ehea_rereg_mrs() is triggered which performs
> a rebuild of the mapping table and a re-registration of the global memory
> region.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
> ---
>
> drivers/net/ehea/ehea.h | 23 +++++--
> drivers/net/ehea/ehea_main.c | 144 +++++++++++++++++++++++++++++++++++----
> drivers/net/ehea/ehea_phyp.h | 3 +
> drivers/net/ehea/ehea_qmr.c | 156 ++++++++++++++++++++++++++++++------------
> drivers/net/ehea/ehea_qmr.h | 14 +++-
> 5 files changed, 275 insertions(+), 65 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: David Miller @ 2007-07-16 21:55 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev, netdev, ebiederm, linux-kernel
In-Reply-To: <20070716172535.GB5771@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Mon, 16 Jul 2007 12:25:35 -0500
> On Fri, Jul 13, 2007 at 03:47:02PM -0700, David Miller wrote:
> > From: linas@austin.ibm.com (Linas Vepstas)
> > Date: Fri, 13 Jul 2007 15:05:15 -0500
> >
> > >
> > > This is a patch (& bug report) for a crash in sysctl_set_parent()
> > > in 2.6.22-git2.
> > >
> > > Problem: 2.6.22-git2 crashes with a stack trace
> > >
> > > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> >
> > Thanks for tracking this down, I'll apply your patch.
>
> NAK. As I just explained in another email, this bug
> was introduced by the "send-to-self" patch I habitually
> apply -- so habitually, that I forgot I was not working
> with a "clean" tree. So it goes ...
I saw all of this, thanks.
^ permalink raw reply
* RE: [RFC][PATCH 6/8] Walnut DTS
From: Yoder Stuart-B08248 @ 2007-07-16 21:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <1184622446.25235.89.camel@localhost.localdomain>
[snip]
> There is no child device node, but there are child interrupt=20
> nodes, and
> since the interrupt-tree uses #address/size-cells, it does make some
> sense to specify them.
>=20
> Yes, there is a default value when absent, but the simple=20
> fact that the
> default is different depending if you are doing a device walk or an
> interrupt tree walk is very confusing. As I said above, the default
> values are a source of more problem than anything else and I tend to
> think they should be banned.
>=20
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children or interrupt children, and ban default
> values alltogether.
Did you really mean #size-cells here? Shouldn't it be #interrupt-cells?
Stuart
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Scott Wood @ 2007-07-16 21:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <1184622446.25235.89.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children or interrupt children, and ban default
> values alltogether.
When is #size-cells used in the interrupt tree at all?
And given the odd behavior of using an interrupt map in an interrupt
parent that is not the device parent (you're potentially using keys from
different domains that could clash, be a different sizes, etc), if we
make any changes in that regard, I'd forbid interrupt maps in interrupt
controllers with no device children, and thus #address-cells has no
meaning there.
-Scott
^ permalink raw reply
* Re: [PATCH] cell: CONFIG_SPE_BASE is a typo (was: Re: possible dead CONFIG-related content under arch/powerpc)
From: Benjamin Herrenschmidt @ 2007-07-16 21:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux PPC Mailing List, Robert P. J. Day, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.62.0707161831090.1072@pademelon.sonytel.be>
On Mon, 2007-07-16 at 18:35 +0200, Geert Uytterhoeven wrote:
> The config symbol for SPE support is called CONFIG_SPU_BASE, not
> CONFIG_SPE_BASE.
Oops... Arnd, we need to check the distro kernels here.
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 4f2f453..0b25d42 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -609,7 +609,7 @@ static void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
> mm->context.sllp = SLB_VSID_USER | mmu_psize_defs[MMU_PAGE_4K].sllp;
> #endif /* CONFIG_PPC_MM_SLICES */
>
> -#ifdef CONFIG_SPE_BASE
> +#ifdef CONFIG_SPU_BASE
> spu_flush_all_slbs(mm);
> #endif
> }
> @@ -744,7 +744,7 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> "to 4kB pages because of "
> "non-cacheable mapping\n");
> psize = mmu_vmalloc_psize = MMU_PAGE_4K;
> -#ifdef CONFIG_SPE_BASE
> +#ifdef CONFIG_SPU_BASE
> spu_flush_all_slbs(mm);
> #endif
> }
>
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
>
> Sony Network and Software Technology Center Europe
> The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
>
> Phone: +32 (0)2 700 8453
> Fax: +32 (0)2 700 8622
> E-mail: Geert.Uytterhoeven@sonycom.com
> Internet: http://www.sony-europe.com/
>
> Sony Network and Software Technology Center Europe
> A division of Sony Service Centre (Europe) N.V.
> Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
> VAT BE 0413.825.160 · RPR Brussels
> Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
> _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-07-16 21:49 UTC (permalink / raw)
To: James Bottomley
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras,
Jens Axboe, Geert Uytterhoeven
In-Reply-To: <1184593643.3447.9.camel@localhost.localdomain>
> No ... that was the point of flush_kernel_dcache_page(). The page in
> question is page cache backed and contains user mappings. However, the
> block layer has already done a flush_dcache_page() in get_user_pages()
> and the user shouldn't be touching memory under I/O (unless they want
> self induced aliasing problems) so we're free to assume all the user
> cachelines are purged, hence all we have to do is flush the kernel alias
> to bring the page up to date and make the users see it correctly.
The block layer will have done that even in the swap-out path ? (Just
asking... I'm not very familiar with the block layer)
Ben.
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-16 21:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <28A3F6B9-512B-4D86-8E0D-A7680CCE2354@kernel.crashing.org>
On Mon, 2007-07-16 at 16:34 +0200, Segher Boessenkool wrote:
> >>> + #address-cells = <0>;
> >>> + #size-cells = <0>;
> >>
> >> No need for these.
> >
> > Isn't a good practice to put #address-cells in interrupt controller
> > nodes?
>
> It is not.
Well, that's debatable... but yes, a strict reading of the spec would
say that you should put neither #address-cells nor #size-cells in a leaf
interrupt controller.
> > If the device tree has an interrupt map defined the interrupt
> > parent 'unit interrupt specifier' has to be interpreted according
> > to the #address-cells of the interrupt parent.
>
> And "#address-cells" is defaulted to 0 if it is absent,
> for the purpose of interrupt mapping (but not for its
> other purposes).
This is a bit confusing though, which is why I tend to prefer having it
explicitely in the interrupt controller node :-) I tend to dislike
"magic" defaults, we've had problems with them in the past and will have
in the future, I much prefer having things explicit whenever possible.
> Typically, such interrupt controllers
> don't have device tree children so it doesn't make sense
> to give them an "#address-cells" anyway.
Somewhat...
> > It seems like
> > typical practice in the current DTS files to explicitly define this
> > in the interrupt controller.
>
> That "typical practice" is inspired by the need to explicitly
> put #address-cells and #size-cells into the device tree if you
> want Linux to properly parse the device tree, even if the default
> values would work perfectly (if Linux would work correctly,
> that is).
Linux does handle default values in some areas. The problem with default
values is that they are badly defined and the spec contains gray areas
and contradictions as to what the default values should be in some
circumstances. As a general matter, I dislike default values because
they somewhat require background knowledge of what default values should
be in different contexts to "read" a device-tree. To be simple, I
believe default values are a bad idea.
> There are no child nodes, and no binding that says there can
> be any; neither #address-cells not #size-cells should be there.
You are being way too pedantic here. The interrupt-tree uses those two
properties, thus "there is no child node" is open to interpretation.
There is no child device node, but there are child interrupt nodes, and
since the interrupt-tree uses #address/size-cells, it does make some
sense to specify them.
Yes, there is a default value when absent, but the simple fact that the
default is different depending if you are doing a device walk or an
interrupt tree walk is very confusing. As I said above, the default
values are a source of more problem than anything else and I tend to
think they should be banned.
I would personally be inclined to define that whatever spec we come up
with always require #address-cells/#size-cells for any node that can
have either device children or interrupt children, and ban default
values alltogether.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-07-16 21:40 UTC (permalink / raw)
To: James Bottomley
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras,
Jens Axboe, Geert Uytterhoeven
In-Reply-To: <1184593643.3447.9.camel@localhost.localdomain>
On Mon, 2007-07-16 at 08:47 -0500, James Bottomley wrote:
>
> No ... that was the point of flush_kernel_dcache_page(). The page in
> question is page cache backed and contains user mappings. However,
> the
> block layer has already done a flush_dcache_page() in get_user_pages()
> and the user shouldn't be touching memory under I/O (unless they want
> self induced aliasing problems) so we're free to assume all the user
> cachelines are purged, hence all we have to do is flush the kernel
> alias
> to bring the page up to date and make the users see it correctly.
Ok. In our case the problem is not aliases though, it's the coherency
between instruction and data caches for pages that may be executed from
(such as swapped out text pages).
Ben.
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-07-16 21:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras, Jens Axboe
In-Reply-To: <Pine.LNX.4.62.0707161515460.1072@pademelon.sonytel.be>
> Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64,
> flush_dcache_page() isn't. So I'd prefer to not call it if not really needed.
>
> And according to James, flush_kernel_dcache_page() should be sufficient...
>
> So I'm getting puzzled again...
flush_dcache_page() handles icache vs. dcache coherency by clearing the
PG_arch_1 bit in the struct page that indicates that the page is cache
clean.
You -must- call it if you're going to use any form of CPU access to
write to the page (basically dirtying the data cache) and that page can
be ever mapped into user space and executed from.
I don't know what flush_kernel_dcache_page() does and if it needs a
similar treatement, it's a new interface, so maybe Jens and or James can
tell me more about it..
Cheers,
Ben.
^ permalink raw reply
* Re: Legacy ISA registers/interrupts in PCI device tree node
From: Benjamin Herrenschmidt @ 2007-07-16 21:35 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <469B336A.5060303@genesi-usa.com>
On Mon, 2007-07-16 at 09:59 +0100, Matt Sealey wrote:
> You could do a LOT worse than check the Pegasos.
Yes, mimmicing the pegasos will probably work
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Gerhard Pircher wrote:
> > Hi,
> >
> > I wonder, if there is a recommended way to specify ISA register
> addresses
> > and interrupts for a PCI device (unlike for a PCI2ISA bridge)?
> > The device in question is the integrated IDE controller of the
> VIA686B
> > southbridge, which works in compatible/legacy mode and thus uses
> interrupts
> > 14 and 15 of the i8259 PIC. Should the fdt contain this information
> or
> > should I hardcode the values in the platform setup code?
You may need a fixup like pegasos does because that chip seems to use
14/15 even when in native mode, which is somewhat out of spec.
Cheers,
Ben.
^ 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