* [PATCH 1/2] leds: make the default trigger name const
From: Trent Piepho @ 2008-07-25 21:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Stephen Rothwell, linuxppc-dev, Richard Purdie, Trent Piepho
In-Reply-To: <Pine.LNX.4.64.0807181339500.10116@t2.domain.actdsltmp>
The default_trigger fields of struct gpio_led and thus struct led_classdev
are pretty much always assigned from a string literal, which means the
string can't be modified. Which is fine, since there is no reason to
modify the string and in fact it never is.
But they should be marked const to prevent such code from being added, to
prevent warnings if -Wwrite-strings is used and when assigned from a
constant string other than a string literal (which produces a warning under
current kernel compiler flags), and for general good coding practices.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
---
include/linux/leds.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 519df72..defe693 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -48,7 +48,7 @@ struct led_classdev {
struct device *dev;
struct list_head node; /* LED Device list */
- char *default_trigger; /* Trigger to use */
+ const char *default_trigger; /* Trigger to use */
#ifdef CONFIG_LEDS_TRIGGERS
/* Protects the trigger data below */
@@ -121,7 +121,7 @@ extern void ledtrig_ide_activity(void);
/* For the leds-gpio driver */
struct gpio_led {
const char *name;
- char *default_trigger;
+ const char *default_trigger;
unsigned gpio;
u8 active_low;
};
--
1.5.4.3
^ permalink raw reply related
* [PATCH 2/2] leds: Support OpenFirmware led bindings
From: Trent Piepho @ 2008-07-25 21:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Stephen Rothwell, linuxppc-dev, Richard Purdie, Trent Piepho
In-Reply-To: <Pine.LNX.4.64.0807181339500.10116@t2.domain.actdsltmp>
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on. The of_platform code is of course only
available on archs that have OF support.
The existing probe and remove methods are refactored to use new functions
create_gpio_led(), to create and register one led, and delete_gpio_led(),
to unregister and free one led. The new probe and remove methods for the
of_platform driver can then share most of the common probe and remove code
with the platform driver.
The suspend and resume methods aren't shared, but they are very short. The
actual led driving code is the same for LEDs created by either binding.
The OF bindings are based on patch by Anton Vorontsov
<avorontsov@ru.mvista.com>. They have been extended to allow multiple LEDs
per device.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 44 ++++-
drivers/leds/Kconfig | 21 ++-
drivers/leds/leds-gpio.c | 225 ++++++++++++++++++-----
3 files changed, 236 insertions(+), 54 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt
index ff51f4c..ed01297 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -1,15 +1,39 @@
-LED connected to GPIO
+LEDs connected to GPIO lines
Required properties:
-- compatible : should be "gpio-led".
-- label : (optional) the label for this LED. If omitted, the label is
- taken from the node name (excluding the unit address).
-- gpios : should specify LED GPIO.
+- compatible : should be "gpio-leds".
-Example:
+Each LED is represented as a sub-node of the gpio-leds device. Each
+node's name represents the name of the corresponding LED.
-led@0 {
- compatible = "gpio-led";
- label = "hdd";
- gpios = <&mcu_pio 0 1>;
+LED node properties:
+- gpios : Should specify the LED GPIO.
+- label : (optional) The label for this LED. If omitted, the label
+ is taken from the node name (excluding the unit address).
+- function : (optional) This parameter, if present, is a string
+ defining the function of the LED. It can be used to put the LED
+ under software control, e.g. Linux LED triggers like "heartbeat",
+ "ide-disk", and "timer". Or it could be used to attach a hardware
+ signal to the LED, e.g. a SoC that can configured to put a SATA
+ activity signal on a GPIO line.
+
+Examples:
+
+leds {
+ compatible = "gpio-leds";
+ hdd {
+ label = "IDE activity";
+ gpios = <&mcu_pio 0 0>;
+ function = "ide-disk";
+ };
};
+
+run-control {
+ compatible = "gpio-leds";
+ red {
+ gpios = <&mpc8572 6 0>;
+ };
+ green {
+ gpios = <&mpc8572 7 0>;
+ };
+}
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 86a369b..8344256 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -109,7 +109,26 @@ config LEDS_GPIO
help
This option enables support for the LEDs connected to GPIO
outputs. To be useful the particular board must have LEDs
- and they must be connected to the GPIO lines.
+ and they must be connected to the GPIO lines. The LEDs must be
+ defined as platform devices and/or OpenFirmware platform devices.
+ The code to use these bindings can be selected below.
+
+config LEDS_GPIO_PLATFORM
+ bool "Platform device bindings for GPIO LEDs"
+ depends on LEDS_GPIO
+ default y
+ help
+ Let the leds-gpio driver drive LEDs which have been defined as
+ platform devices. If you don't know what this means, say yes.
+
+config LEDS_GPIO_OF
+ bool "OpenFirmware platform device bindings for GPIO LEDs"
+ depends on LEDS_GPIO && OF_DEVICE
+ default y
+ help
+ Let the leds-gpio driver drive LEDs which have been defined as
+ of_platform devices. For instance, LEDs which are listed in a "dts"
+ file.
config LEDS_CM_X270
tristate "LED Support for the CM-X270 LEDs"
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index b13bd29..f10f123 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -71,11 +71,52 @@ static int gpio_blink_set(struct led_classdev *led_cdev,
return led_dat->platform_gpio_blink_set(led_dat->gpio, delay_on, delay_off);
}
-static int gpio_led_probe(struct platform_device *pdev)
+static int __devinit create_gpio_led(const struct gpio_led *template,
+ struct gpio_led_data *led_dat, struct device *parent,
+ int (*blink_set)(unsigned, unsigned long *, unsigned long *))
+{
+ int ret;
+
+ ret = gpio_request(template->gpio, template->name);
+ if (ret < 0)
+ return ret;
+
+ led_dat->cdev.name = template->name;
+ led_dat->cdev.default_trigger = template->default_trigger;
+ led_dat->gpio = template->gpio;
+ led_dat->can_sleep = gpio_cansleep(template->gpio);
+ led_dat->active_low = template->active_low;
+ if (blink_set) {
+ led_dat->platform_gpio_blink_set = blink_set;
+ led_dat->cdev.blink_set = gpio_blink_set;
+ }
+ led_dat->cdev.brightness_set = gpio_led_set;
+ led_dat->cdev.brightness = LED_OFF;
+
+ gpio_direction_output(led_dat->gpio, led_dat->active_low);
+
+ INIT_WORK(&led_dat->work, gpio_led_work);
+
+ ret = led_classdev_register(parent, &led_dat->cdev);
+ if (ret < 0)
+ gpio_free(led_dat->gpio);
+
+ return ret;
+}
+
+static void delete_gpio_led(struct gpio_led_data *led)
+{
+ led_classdev_unregister(&led->cdev);
+ cancel_work_sync(&led->work);
+ gpio_free(led->gpio);
+}
+
+/* Code to creates LEDs from platform devices */
+#ifdef CONFIG_LEDS_GPIO_PLATFORM
+static int __devinit gpio_led_probe(struct platform_device *pdev)
{
struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
- struct gpio_led *cur_led;
- struct gpio_led_data *leds_data, *led_dat;
+ struct gpio_led_data *leds_data;
int i, ret = 0;
if (!pdata)
@@ -87,34 +128,10 @@ static int gpio_led_probe(struct platform_device *pdev)
return -ENOMEM;
for (i = 0; i < pdata->num_leds; i++) {
- cur_led = &pdata->leds[i];
- led_dat = &leds_data[i];
-
- ret = gpio_request(cur_led->gpio, cur_led->name);
+ ret = create_gpio_led(&pdata->leds[i], &leds_data[i],
+ &pdev->dev, pdata->gpio_blink_set);
if (ret < 0)
goto err;
-
- led_dat->cdev.name = cur_led->name;
- led_dat->cdev.default_trigger = cur_led->default_trigger;
- led_dat->gpio = cur_led->gpio;
- led_dat->can_sleep = gpio_cansleep(cur_led->gpio);
- led_dat->active_low = cur_led->active_low;
- if (pdata->gpio_blink_set) {
- led_dat->platform_gpio_blink_set = pdata->gpio_blink_set;
- led_dat->cdev.blink_set = gpio_blink_set;
- }
- led_dat->cdev.brightness_set = gpio_led_set;
- led_dat->cdev.brightness = LED_OFF;
-
- gpio_direction_output(led_dat->gpio, led_dat->active_low);
-
- INIT_WORK(&led_dat->work, gpio_led_work);
-
- ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
- if (ret < 0) {
- gpio_free(led_dat->gpio);
- goto err;
- }
}
platform_set_drvdata(pdev, leds_data);
@@ -122,13 +139,8 @@ static int gpio_led_probe(struct platform_device *pdev)
return 0;
err:
- if (i > 0) {
- for (i = i - 1; i >= 0; i--) {
- led_classdev_unregister(&leds_data[i].cdev);
- cancel_work_sync(&leds_data[i].work);
- gpio_free(leds_data[i].gpio);
- }
- }
+ for (i = i - 1; i >= 0; i--)
+ delete_gpio_led(&leds_data[i]);
kfree(leds_data);
@@ -143,11 +155,8 @@ static int __devexit gpio_led_remove(struct platform_device *pdev)
leds_data = platform_get_drvdata(pdev);
- for (i = 0; i < pdata->num_leds; i++) {
- led_classdev_unregister(&leds_data[i].cdev);
- cancel_work_sync(&leds_data[i].work);
- gpio_free(leds_data[i].gpio);
- }
+ for (i = 0; i < pdata->num_leds; i++)
+ delete_gpio_led(&leds_data[i]);
kfree(leds_data);
@@ -211,7 +220,137 @@ static void __exit gpio_led_exit(void)
module_init(gpio_led_init);
module_exit(gpio_led_exit);
-MODULE_AUTHOR("Raphael Assenat <raph@8d.com>");
+MODULE_ALIAS("platform:leds-gpio");
+#endif /* CONFIG_LEDS_GPIO_PLATFORM */
+
+/* Code to create from OpenFirmware platform devices */
+#ifdef CONFIG_LEDS_GPIO_OF
+#include <linux/of_platform.h>
+#include <linux/of_gpio.h>
+
+struct gpio_led_of_platform_data {
+ int num_leds;
+ struct gpio_led_data led_data[];
+};
+
+static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node, *child;
+ struct gpio_led led;
+ struct gpio_led_of_platform_data *led_pdata;
+ int count = 0, ret;
+
+ /* count LEDs defined by this device, so we now how much to allocate */
+ for_each_child_of_node(np, child)
+ count++;
+ if (!count)
+ return 0; /* or ENODEV? */
+
+ led_pdata = kzalloc(sizeof(*led_pdata) +
+ sizeof(struct gpio_led_data) * count, GFP_KERNEL);
+ if (!led_pdata)
+ return -ENOMEM;
+
+ memset(&led, 0, sizeof(led));
+ for_each_child_of_node(np, child) {
+ led.gpio = of_get_gpio(child, 0);
+ led.name = of_get_property(child, "label", NULL) ? : child->name;
+ led.default_trigger =
+ of_get_property(child, "linux,default-trigger", NULL);
+
+ ret = create_gpio_led(&led,
+ &led_pdata->led_data[led_pdata->num_leds++],
+ &ofdev->dev, NULL);
+ if (ret < 0)
+ goto err;
+ }
+
+ dev_set_drvdata(&ofdev->dev, led_pdata);
+
+ return 0;
+
+err:
+ for (count = led_pdata->num_leds - 1; count >= 0; count--)
+ delete_gpio_led(&led_pdata->led_data[count]);
+
+ kfree(led_pdata);
+
+ return ret;
+}
+
+static int __devexit of_gpio_leds_remove(struct of_device *ofdev)
+{
+ struct gpio_led_of_platform_data *pdata = dev_get_drvdata(&ofdev->dev);
+ int i;
+
+ for (i = 0; i < pdata->num_leds; i++)
+ delete_gpio_led(&pdata->led_data[i]);
+
+ kfree(pdata);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int of_gpio_led_suspend(struct of_device *ofdev, pm_message_t state)
+{
+ struct gpio_led_of_platform_data *pdata = dev_get_drvdata(&ofdev->dev);
+ int i;
+
+ for (i = 0; i < pdata->num_leds; i++)
+ led_classdev_suspend(&pdata->leds_data[i].cdev);
+
+ return 0;
+}
+
+static int of_gpio_led_resume(struct of_device *ofdev)
+{
+ struct gpio_led_of_platform_data *pdata = dev_get_drvdata(&ofdev->dev);
+ int i;
+
+ for (i = 0; i < pdata->num_leds; i++)
+ led_classdev_resume(&pdata->leds_data[i].cdev);
+
+ return 0;
+}
+#else
+#define of_gpio_led_suspend NULL
+#define of_gpio_led_resume NULL
+#endif /* CONFIG_PM */
+
+static const struct of_device_id of_gpio_leds_match[] = {
+ { .compatible = "gpio-led", },
+ {},
+};
+
+static struct of_platform_driver of_gpio_leds_driver = {
+ .driver = {
+ .name = "of_gpio_leds",
+ .owner = THIS_MODULE,
+ },
+ .match_table = of_gpio_leds_match,
+ .probe = of_gpio_leds_probe,
+ .remove = __devexit_p(of_gpio_leds_remove),
+ .suspend = of_gpio_led_suspend,
+ .resume = of_gpio_led_resume,
+};
+
+static int __init of_gpio_leds_init(void)
+{
+ return of_register_platform_driver(&of_gpio_leds_driver);
+}
+module_init(of_gpio_leds_init);
+
+static void __exit of_gpio_leds_exit(void)
+{
+ of_unregister_platform_driver(&of_gpio_leds_driver);
+}
+module_exit(of_gpio_leds_exit);
+#endif
+
+MODULE_AUTHOR("Raphael Assenat <raph@8d.com>, Trent Piepho <tpiepho@freescale.com>");
MODULE_DESCRIPTION("GPIO LED driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:leds-gpio");
--
1.5.4.3
^ permalink raw reply related
* DTC v1.2.0 Released
From: Jon Loeliger @ 2008-07-25 21:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
Folks,
I have tagged and released DTC version 1.2.0 on jdl.com.
git://git.jdl.com/software/dtc.git
Problems with it to me, please!
Enjoy,
jdl
^ permalink raw reply
* [PATCH] Memset the kernel copy of rtas args before using
From: Nathan Fontenot @ 2008-07-25 21:25 UTC (permalink / raw)
To: linuxppc-dev
The kernel copy of the rtas args struct that is read in from
user space is a stack variable. This structure should be
zero'ed out before we do any reads/writes to/from the user
when handling a rtas call request. This patch adds a memset
to do this.
I am seeing an issue in testing partition mobility, where the
parts of the rtas args struct that return status top the user
contain stale data.
Signed-off-by: Nathan Fontenot <nfont@ausitn,ibm.com>
---
Index: linux-2.6.git/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/rtas.c 2008-07-22 09:34:03.000000000 -0500
+++ linux-2.6.git/arch/powerpc/kernel/rtas.c 2008-07-25 16:06:00.000000000 -0500
@@ -775,6 +775,8 @@
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
+ memset(&args, 0, sizeof(args));
+
if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
return -EFAULT;
^ permalink raw reply
* PowerPC source tree
From: Bizhan Gholikhamseh (bgholikh) @ 2008-07-25 21:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
Hi,
Where can I download the latest (stable) PowerPC source tree? Is it
kernel.org?
Thanks,
Bizhan
[-- Attachment #2: Type: text/html, Size: 664 bytes --]
^ permalink raw reply
* Re: [RFC] 4xx hardware watchpoint support
From: Benjamin Herrenschmidt @ 2008-07-25 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <83A1F423-1C8B-405D-9118-D9BB51A8AA94@kernel.crashing.org>
> Josh pointed out that you went ahead and merged this. Curse you :)
>
> I've got a patch in my tree to address my initial concerns.
Well, I asked Josh on IRC and he was fine, I got your email too late.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC] 4xx hardware watchpoint support
From: Benjamin Herrenschmidt @ 2008-07-25 21:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <C786174A-78C1-40B6-ABC9-24E7419FA182@kernel.crashing.org>
On Fri, 2008-07-25 at 10:23 -0500, Kumar Gala wrote:
>
> Ben, I want to make sure this works on FSL Book-E before it gets into
> tree and I need to think about what SMP issues it might have.
Hrm.. too late. I merged it.
> I talked to Josh about this at OLS and if you are ok I can deal with
> acceptance of this patch via my tree.
I don't see the patch causing issues as-is, unless I missed something.
Currently none of the platform it affects supports SMP in the tree
either. Can you verify about FSL and if there's a problem we can fixup
the #ifdefs.
Ben.
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-25 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <BAF7B55C-75C2-4BCA-8686-34A843865C91@kernel.crashing.org>
On Fri, 2008-07-25 at 10:07 -0500, Kumar Gala wrote:
> On Jul 25, 2008, at 3:13 AM, Benjamin Herrenschmidt wrote:
>
> >
> > Benjamin Herrenschmidt (1):
> > Move update_mmu_cache() declaration from tlbflush.h to pgtable.h
>
> I'm guessing this was pretty trivial, but please post patches to the
> list even if you've committed them to your tree.
This was a last minute build fix I stuck in to ... fix the build :-)
Some new stuff from Christoph Lameter broke ppc32 build without that
fix.
Next time I'll also send it to the list as well.
Ben.
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
From: Benjamin Herrenschmidt @ 2008-07-25 21:46 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linuxppc-dev, Ingo Molnar, the arch/x86 maintainers, linux-kernel,
Mike Travis
In-Reply-To: <Pine.LNX.4.64.0807251839190.20617@blonde.site>
On Fri, 2008-07-25 at 19:45 +0100, Hugh Dickins wrote:
>
> I've Cc'ed Ben and linuxppc-dev because I wonder if they're aware
> that several options (I got it from LATENCYTOP, but I think LOCKDEP
> and FTRACE and some others) are doing a "select FRAME_POINTER",
> which forces CONFIG_FRAME_POINTER=y on PowerPC, even though
> FRAME_POINTER is not an option offered on PowerPC. The
> resulting kernels appear to run okay, but I was surprised.
Because the option just does nothing for us ? :-) We always have frame
pointers on powerpc except in some case for leaf functions. I don't know
if the option has any actual effect on the later, but I don't think we
have a case where doing either way would break things.
Cheers,
Ben.
^ permalink raw reply
* can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Jon Smirl @ 2008-07-25 21:51 UTC (permalink / raw)
To: ppc-dev
I've lost my ability to boot on the mpc5200. Reverting this patch fixes it.
powerpc: Enable AT_BASE_PLATFORM aux vector
9115d13453dee22473a1e8cacc90a8d64a9c4bc9
commit 9115d13453dee22473a1e8cacc90a8d64a9c4bc9
Author: Nathan Lynch <ntl@pobox.com>
Date: Wed Jul 16 09:58:51 2008 +1000
powerpc: Enable AT_BASE_PLATFORM aux vector
Stash the first platform string matched by identify_cpu() in
powerpc_base_platform, and supply that to the ELF loader for the value
of AT_BASE_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b936a1d..25a052c 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -23,6 +23,9 @@
struct cpu_spec* cur_cpu_spec = NULL;
EXPORT_SYMBOL(cur_cpu_spec);
+/* The platform string corresponding to the real PVR */
+const char *powerpc_base_platform;
+
/* NOTE:
* Unlike ppc32, ppc64 will only call this once for the boot CPU, it's
* the responsibility of the appropriate CPU save/restore functions to
@@ -1652,6 +1655,14 @@ struct cpu_spec * __init identify_cpu(unsigned
long offset, unsigned int pvr)
} else
*t = *s;
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
+
+ /*
+ * Set the base platform string once; assumes
+ * we're called with real pvr first.
+ */
+ if (powerpc_base_platform == NULL)
+ powerpc_base_platform = t->platform;
+
#if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
/* ppc64 and booke expect identify_cpu to also call
* setup_cpu for that processor. I will consolidate
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 2a3e907..ef8a248 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -127,6 +127,8 @@ extern struct cpu_spec *identify_cpu(unsigned long
offset, unsigned int pvr);
extern void do_feature_fixups(unsigned long value, void *fixup_start,
void *fixup_end);
+extern const char *powerpc_base_platform;
+
#endif /* __ASSEMBLY__ */
/* CPU kernel features */
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index 8966467..80d1f39 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -217,6 +217,14 @@ typedef elf_vrregset_t elf_fpxregset_t;
#define ELF_PLATFORM (cur_cpu_spec->platform)
+/* While ELF_PLATFORM indicates the ISA supported by the platform, it
+ * may not accurately reflect the underlying behavior of the hardware
+ * (as in the case of running in Power5+ compatibility mode on a
+ * Power6 machine). ELF_BASE_PLATFORM allows ld.so to load libraries
+ * that are tuned for the real hardware.
+ */
+#define ELF_BASE_PLATFORM (powerpc_base_platform)
+
#ifdef __powerpc64__
# define ELF_PLAT_INIT(_r, load_addr) do { \
_r->gpr[2] = load_addr; \
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* RE: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
From: John Linn @ 2008-07-25 21:54 UTC (permalink / raw)
To: Mirek23, linuxppc-embedded
In-Reply-To: <18649823.post@talk.nabble.com>
{resend as I forgot to send to the mailing list)
Hi Mirek,
Since this is a u-boot issue, we can move this conversation off this
list.
The u-boot that is in the git repository has not been tested on the
Virtex4 platform.
I have only tested on the ML507, Virtex 5 platform.
There's not a ML403/ML405 board supported in our git tree, so I'm
curious what you did to try to build it for V4.
There are differences between V4 and V5 with the DMA as it's hard in V5
and hangs off the DCR bus of the processor.
The kernel itself is running on both the ML405 and the ML507, but not
yet with u-boot.
Thanks,
John
> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Mirek23
> Sent: Friday, July 25, 2008 5:22 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx Linux 2.6 for XPS LL_TEMAC and LL_FIFO problem
> =
> =
> Hi John and Mike,
> =
> Thank you for your reply. We have modified out FPGA design and now we
have
> LL_TEMAC with LL_DMA component connected instead of the LL_FIFO.
Before
> building linux kernel we have tried to build the u-boot (downloaded
from the
> xilinx-git tree).
> =
> It was relatively easy to build u-boot which has the ll_temac with
ll_dma
> support.
> =
> next we have tried to run u-boot on our ppc (virtex-4 FX12). All went
fine
> till the moment to establish the communication with the network.
> =
> I put some debug messages to the xilinx ll_dma and ll_temac drivers
and we
> have found that u-boot hangs
> during dma initialisation:
> =
> more specifically in the function calls :
> XLlDma_Initialize(XLlDma * InstancePtr, u32 BaseAddress)
> XLlDma_Reset(XLlDma * InstancePtr)
> XLlDma_mBdRingSnapShotCurrBd(TxRingPtr);
> =
> Do you have any idea what could be wrong with dma initialization?
> =
> Best Regards
> =
> Mirek
> =
> =
> =
> --
> View this message in context:
http://www.nabble.com/Compile-time-error%2C-compiling-Xilinx-Linux-2.6-
> for-XPS-LLTEMAC-tp16065692p18649823.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> =
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Nathan Lynch @ 2008-07-25 22:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: ppc-dev
In-Reply-To: <9e4733910807251451s623b87cetcf7ed5ff6a12f012@mail.gmail.com>
Jon Smirl wrote:
> I've lost my ability to boot on the mpc5200. Reverting this patch fixes it.
How does it fail?
> @@ -1652,6 +1655,14 @@ struct cpu_spec * __init identify_cpu(unsigned
> long offset, unsigned int pvr)
> } else
> *t = *s;
> *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
> +
> + /*
> + * Set the base platform string once; assumes
> + * we're called with real pvr first.
> + */
> + if (powerpc_base_platform == NULL)
> + powerpc_base_platform = t->platform;
> +
Hmm, maybe this needs RELOC/PTRRELOC tricks?
^ permalink raw reply
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Benjamin Herrenschmidt @ 2008-07-25 22:15 UTC (permalink / raw)
To: Nathan Lynch; +Cc: ppc-dev
In-Reply-To: <20080725220038.GI9594@localdomain>
On Fri, 2008-07-25 at 17:00 -0500, Nathan Lynch wrote:
> Jon Smirl wrote:
> > I've lost my ability to boot on the mpc5200. Reverting this patch fixes it.
>
> How does it fail?
>
>
> > @@ -1652,6 +1655,14 @@ struct cpu_spec * __init identify_cpu(unsigned
> > long offset, unsigned int pvr)
> > } else
> > *t = *s;
> > *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
> > +
> > + /*
> > + * Set the base platform string once; assumes
> > + * we're called with real pvr first.
> > + */
> > + if (powerpc_base_platform == NULL)
> > + powerpc_base_platform = t->platform;
> > +
>
> Hmm, maybe this needs RELOC/PTRRELOC tricks?
Hrm... indeed.
if (RELOC(powerpc_base_platform))
RELOC(powerpc_base_platform) = t->platform;
try that.
Ben.
^ permalink raw reply
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Jon Smirl @ 2008-07-25 22:46 UTC (permalink / raw)
To: benh; +Cc: ppc-dev, Nathan Lynch
In-Reply-To: <1217024108.11188.117.camel@pasglop>
On 7/25/08, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2008-07-25 at 17:00 -0500, Nathan Lynch wrote:
> > Jon Smirl wrote:
> > > I've lost my ability to boot on the mpc5200. Reverting this patch fixes it.
> >
> > How does it fail?
> >
> >
> > > @@ -1652,6 +1655,14 @@ struct cpu_spec * __init identify_cpu(unsigned
> > > long offset, unsigned int pvr)
> > > } else
> > > *t = *s;
> > > *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
> > > +
> > > + /*
> > > + * Set the base platform string once; assumes
> > > + * we're called with real pvr first.
> > > + */
> > > + if (powerpc_base_platform == NULL)
> > > + powerpc_base_platform = t->platform;
> > > +
> >
> > Hmm, maybe this needs RELOC/PTRRELOC tricks?
>
>
> Hrm... indeed.
>
> if (RELOC(powerpc_base_platform))
> RELOC(powerpc_base_platform) = t->platform;
It completely fails booting, no console or anything.
Where is RELOC defined, prom_init.c?
#ifdef CONFIG_PPC64
#define RELOC(x) (*PTRRELOC(&(x)))
#define ADDR(x) (u32) add_reloc_offset((unsigned long)(x))
#define OF_WORKAROUNDS 0
#else
#define RELOC(x) (x)
#define ADDR(x) (u32) (x)
#define OF_WORKAROUNDS of_workarounds
int of_workarounds;
#endif
>
> try that.
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Nathan Lynch @ 2008-07-25 22:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
In-Reply-To: <1217024108.11188.117.camel@pasglop>
Commit 9115d13453dee22473a1e8cacc90a8d64a9c4bc9 ("powerpc: Enable
AT_BASE_PLATFORM aux vector") broke boot on 32-bit powerpc systems; we
have to use PTRRELOC to initialize powerpc_base_platform this early in
boot.
Bug reported by Jon Smirl.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
Benjamin Herrenschmidt wrote:
> if (RELOC(powerpc_base_platform))
> RELOC(powerpc_base_platform) = t->platform;
>
> try that.
Maybe this? (RELOC isn't defined in any header AFAICT).
arch/powerpc/kernel/cputable.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 25a052c..25c273c 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1660,8 +1660,8 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
* Set the base platform string once; assumes
* we're called with real pvr first.
*/
- if (powerpc_base_platform == NULL)
- powerpc_base_platform = t->platform;
+ if (*PTRRELOC(&powerpc_base_platform) == NULL)
+ *PTRRELOC(&powerpc_base_platform) = t->platform;
#if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
/* ppc64 and booke expect identify_cpu to also call
--
1.5.6.2
^ permalink raw reply related
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Jon Smirl @ 2008-07-25 22:51 UTC (permalink / raw)
To: benh; +Cc: ppc-dev, Nathan Lynch
In-Reply-To: <9e4733910807251546k2388b1afgba52081c20332dc4@mail.gmail.com>
On 7/25/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 7/25/08, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > On Fri, 2008-07-25 at 17:00 -0500, Nathan Lynch wrote:
> > > Jon Smirl wrote:
> > > > I've lost my ability to boot on the mpc5200. Reverting this patch fixes it.
> > >
> > > How does it fail?
> > >
> > >
> > > > @@ -1652,6 +1655,14 @@ struct cpu_spec * __init identify_cpu(unsigned
> > > > long offset, unsigned int pvr)
> > > > } else
> > > > *t = *s;
> > > > *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
> > > > +
> > > > + /*
> > > > + * Set the base platform string once; assumes
> > > > + * we're called with real pvr first.
> > > > + */
> > > > + if (powerpc_base_platform == NULL)
> > > > + powerpc_base_platform = t->platform;
> > > > +
> > >
> > > Hmm, maybe this needs RELOC/PTRRELOC tricks?
> >
> >
> > Hrm... indeed.
> >
> > if (RELOC(powerpc_base_platform))
> > RELOC(powerpc_base_platform) = t->platform;
This boots:
#define RELOC(x) (*PTRRELOC(&(x)))
if (RELOC(powerpc_base_platform))
RELOC(powerpc_base_platform) = t->platform;
>
>
> It completely fails booting, no console or anything.
>
> Where is RELOC defined, prom_init.c?
>
> #ifdef CONFIG_PPC64
> #define RELOC(x) (*PTRRELOC(&(x)))
> #define ADDR(x) (u32) add_reloc_offset((unsigned long)(x))
> #define OF_WORKAROUNDS 0
> #else
> #define RELOC(x) (x)
> #define ADDR(x) (u32) (x)
> #define OF_WORKAROUNDS of_workarounds
> int of_workarounds;
> #endif
>
>
>
> >
> > try that.
> >
> > Ben.
>
> >
> >
> >
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Jon Smirl @ 2008-07-25 22:52 UTC (permalink / raw)
To: Nathan Lynch; +Cc: ppc-dev
In-Reply-To: <20080725225030.GJ9594@localdomain>
On 7/25/08, Nathan Lynch <ntl@pobox.com> wrote:
> Commit 9115d13453dee22473a1e8cacc90a8d64a9c4bc9 ("powerpc: Enable
> AT_BASE_PLATFORM aux vector") broke boot on 32-bit powerpc systems; we
> have to use PTRRELOC to initialize powerpc_base_platform this early in
> boot.
>
> Bug reported by Jon Smirl.
>
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
>
> ---
>
> Benjamin Herrenschmidt wrote:
> > if (RELOC(powerpc_base_platform))
> > RELOC(powerpc_base_platform) = t->platform;
> >
> > try that.
>
>
> Maybe this? (RELOC isn't defined in any header AFAICT).
>
> arch/powerpc/kernel/cputable.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
>
> index 25a052c..25c273c 100644
>
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
>
> @@ -1660,8 +1660,8 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
>
> * Set the base platform string once; assumes
> * we're called with real pvr first.
> */
> - if (powerpc_base_platform == NULL)
> - powerpc_base_platform = t->platform;
>
> + if (*PTRRELOC(&powerpc_base_platform) == NULL)
> + *PTRRELOC(&powerpc_base_platform) = t->platform;
This works too.
>
>
> #if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
> /* ppc64 and booke expect identify_cpu to also call
>
> --
> 1.5.6.2
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: can't boot mpc5200, powerpc: Enable AT_BASE_PLATFORM aux vector
From: Nathan Lynch @ 2008-07-25 22:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: ppc-dev
In-Reply-To: <9e4733910807251552i37ae832fpa84cc0c105774795@mail.gmail.com>
> This works too.
Thanks Jon, sorry about that.
^ permalink raw reply
* [PATCH] Fix vio build warnings
From: Nathan Lynch @ 2008-07-25 23:06 UTC (permalink / raw)
To: linuxppc-dev
arch/powerpc/kernel/vio.c:1034: warning: function declaration isn’t a prototype
arch/powerpc/kernel/vio.c:1035: warning: function declaration isn’t a prototype
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/vio.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index ade8aea..6952384 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1031,8 +1031,8 @@ void vio_cmo_set_dev_desired(struct vio_dev *viodev, size_t desired) {}
static int vio_cmo_bus_probe(struct vio_dev *viodev) { return 0; }
static void vio_cmo_bus_remove(struct vio_dev *viodev) {}
static void vio_cmo_set_dma_ops(struct vio_dev *viodev) {}
-static void vio_cmo_bus_init() {}
-static void vio_cmo_sysfs_init() { }
+static void vio_cmo_bus_init(void) {}
+static void vio_cmo_sysfs_init(void) { }
#endif /* CONFIG_PPC_SMLPAR */
EXPORT_SYMBOL(vio_cmo_entitlement_update);
EXPORT_SYMBOL(vio_cmo_set_dev_desired);
--
1.5.6.2
^ permalink raw reply related
* [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-25 23:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, akpm, Linux Kernel list
Hi Linus !
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
To get one patch that fixes a boot problem introduced by yesterday's
serie.
Thanks !
Ben.
arch/powerpc/kernel/cputable.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Nathan Lynch (1):
powerpc: Fix boot problem due to AT_BASE_PLATFORM change
^ permalink raw reply
* Re: [RFC] 4xx hardware watchpoint support
From: Josh Boyer @ 2008-07-25 23:08 UTC (permalink / raw)
To: benh; +Cc: ppc-dev, Hellwig, Paul Mackerras, Christoph
In-Reply-To: <1217021937.11188.110.camel@pasglop>
On Sat, 26 Jul 2008 07:38:57 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Josh pointed out that you went ahead and merged this. Curse you :)
> >
> > I've got a patch in my tree to address my initial concerns.
>
> Well, I asked Josh on IRC and he was fine, I got your email too late.
I was (and still am) OK with it. Kumar's comments are valid but not
major for 44x. Some cleanup could be done, but I was more focused on
getting it in during this merge window.
I think we just had a small case of bad timing. I blame conferences
and late nights of beer^H^H^H^Hcoding.
josh
^ permalink raw reply
* Re: [RFC] 4xx hardware watchpoint support
From: Benjamin Herrenschmidt @ 2008-07-25 23:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: ppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <20080725190838.27c227bc@zod.rchland.ibm.com>
On Fri, 2008-07-25 at 19:08 -0400, Josh Boyer wrote:
> On Sat, 26 Jul 2008 07:38:57 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > > Josh pointed out that you went ahead and merged this. Curse you :)
> > >
> > > I've got a patch in my tree to address my initial concerns.
> >
> > Well, I asked Josh on IRC and he was fine, I got your email too late.
>
> I was (and still am) OK with it. Kumar's comments are valid but not
> major for 44x. Some cleanup could be done, but I was more focused on
> getting it in during this merge window.
>
> I think we just had a small case of bad timing. I blame conferences
> and late nights of beer^H^H^H^Hcoding.
Yeah, as I said, the patch is fine (ie shouldn't break anything) and has
had plenty of review so I felt it was good to go, we can do cleanups
later. I wanted that feature in the merge window, next week would have
been too late :-)
Cheers,
Ben.
^ permalink raw reply
* 82xx/83xx MCC Super Channels - GUN Error
From: Russell McGuire @ 2008-07-25 23:50 UTC (permalink / raw)
To: linuxppc-embedded
Guys,
Attempting to polish up an existing MCC HDLC driver, adding super channels
for an 8360E, though I imagine the specifics an answer, might work for any
82xx or 83xx architecture.
Background:
I have taken my existing working MCC HDLC driver <non-superchanneled>
interfaced to a T1 in clear channel mode, and found that I was using less
than optimized MCC configuration, i.e. using the TX SiRAM entries to
transmit 8 bytes chunks. Though his works, I get GUN errors probably every
10 minutes. So after careful reading, I decided to optimize and create super
channels using the 83xx version <16 bit entries only for 83xx> for the
SiRAM.
Problem:
After the super channel conversion, I now get GUN interrupts continuously
the instant I enable the TDM's / SI.
Detail:
I have written the extra code to program up the SiRAM entries, RX side to
use super channel 6 <for compatibility with later SATM code, SC must be
divisible by 4 after subtracting 2>, and the TX side uses channels 0-11 <12
channels of 2 bytes = 192 byes of a standard T1 B8ZS-ESF Frame>, my SCT
table of course routes slots 0-11 into SC 6. I am guessing this is correct,
and more likely I probably have a setup problem with configuring all the MCC
parameters, or init sequence.
After reading much Freescale documentation and their FAQ's online, I see
there are a couple of undocumented things that may or may not need to be
done, like stopping a super channel before issues the QE_INIT_TX_RX
commands.
So my question is this:
In order to not have GUN always occurring, how does one initialize a super
channel and its related sub-channels? This what I am doing now.
1) Program SI entries
2) Program MCC global PRAM?
3) Program SuperChannel ChanPRAM
4) Program SuperChannel XtraPRAM
5) Program SuperChannel Table <SCT>
6) Set rstate and tstate once for SuperChannel i.e. channel 6
7) Call QE_INIT_TX_RX once for channel block 0 <i.e. channels 0-31>.
8) Enable TDM's
9) GUN recovery code goes nuts until I reset.
Anybody have experience with this and super channels? I have seen hints that
perhaps I need to maybe set rstate and tstate for every channel in the super
channel, what about the 'first byte' in the SiRAM TX entry? Does that need
to be set for clear channels? I have seen one email for 82xx MCC that say
the super channel needs to be QE_STOP_TX before calling the MCC INIT code,
but not sure if that is really needed, or only for 82xx CPU's. What about
using the QE_INIT_TX_RX_16? I have tried this, and it causes silence in the
driver, i.e. can't even get interrupts if I use this command.
Ideas anyone?
Russell McGuire
Senior Systems Engineer
rmcguire@videopresence.com
503.888.0968
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Linus Torvalds @ 2008-07-26 0:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, akpm, Linux Kernel list
In-Reply-To: <1217027473.11188.120.camel@pasglop>
On Sat, 26 Jul 2008, Benjamin Herrenschmidt wrote:
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
What odd character do you have there before the 'git://' and why?
It cuts-and-pastes into some whitespace that isn't space, and that the
shell thus makes part of that word when parsing. It seems to be U+FEFF,
which is "zero-width non-break space", but what the heck is the point of
that kind of garbage in email?
Is this some new way for Evolution to screw up?
Linus
^ permalink raw reply
* Cleanup for i2c driver changes.
From: Sean MacLennan @ 2008-07-26 1:45 UTC (permalink / raw)
To: linuxppc-dev
This patch removes the i2c code which is now obsolete due to the new
ibm iic driver walking the device tree for child nodes.
There are two other small cleanups that came indirectly from the ad7414
code review. Make sure Tlow is correct and handle the case where
i2c_smbus_read_word_data fails.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 9565995..960edf8 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -30,18 +30,6 @@ static __initdata struct of_device_id warp_of_bus[] = {
{},
};
-static __initdata struct i2c_board_info warp_i2c_info[] = {
- { I2C_BOARD_INFO("ad7414", 0x4a) }
-};
-
-static int __init warp_arch_init(void)
-{
- /* This should go away once support is moved to the dts. */
- i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
- return 0;
-}
-machine_arch_initcall(warp, warp_arch_init);
-
static int __init warp_device_probe(void)
{
of_platform_bus_probe(NULL, warp_of_bus, NULL);
@@ -223,7 +211,7 @@ static void pika_setup_critical_temp(struct i2c_client *client)
/* These registers are in 1 degree increments. */
i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
- i2c_smbus_write_byte_data(client, 3, 55); /* Tlow */
+ i2c_smbus_write_byte_data(client, 3, 0); /* Tlow */
np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
if (np == NULL) {
@@ -289,8 +277,15 @@ found_it:
printk(KERN_INFO "PIKA DTM thread running.\n");
while (!kthread_should_stop()) {
- u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
- out_be32(fpga + 0x20, temp);
+ int val;
+
+ val = i2c_smbus_read_word_data(client, 0);
+ if (val < 0)
+ dev_dbg(&client->dev, "DTM read temp failed.\n");
+ else {
+ s16 temp = swab16(val);
+ out_be32(fpga + 0x20, temp);
+ }
pika_dtm_check_fan(fpga);
^ permalink raw reply related
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