* [RFC PATCHv2 1/2] Export SoC info through sysfs
From: Nicolas Pitre @ 2011-04-07 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D9E30AE.9080105@bluewatersys.com>
On Fri, 8 Apr 2011, Ryan Mallon wrote:
> On 04/08/2011 09:29 AM, Arnd Bergmann wrote:
> > I'll try to capture the opinions from the other people as well,
> > hopefully this represents a consensus. Please correct me otherwise.
> >
> > I believe the uncontroversial parts are:
> >
> > * Make it not an entry but a device with certain properties.
> > * Make the naming so that you can have more than one of them.
> > * Put all devices on an SoC that uses this scheme underneath that
> > device by setting their parents to the SoC device.
> >
> > For the location of the device, I have not seen a clear consensus yet,
> > but I'm fine with eihter of these:
> >
> > /sys/devices/soc/${NAME}/
> > /sys/devices/platform/soc${NUMBER}/
>
> I prefer the second format here since the path is always the same which
> makes it easier to write parsing tools. The name should be an entry in
> the directory rather than the name of the directory itself.
>
> Probably SoC number should match CPU number for SMP machines right?
Not really. SOC means System On Chip. you usually have only one SOC on
a board, and within that SOC you may have one or more CPUs. SMP
machines are still likely to have only one SOC.
Nicolas
^ permalink raw reply
* Re: [RFC PATCHv2 1/2] Export SoC info through sysfs
From: Nicolas Pitre @ 2011-04-07 22:01 UTC (permalink / raw)
To: Ryan Mallon
Cc: ext Nishanth Menon, ext Tony Lindgren, Greg KH, Linus Walleij,
Ambresh, Saravana Kannan, Andrei Warkentin, Lee Jones,
Rabin VINCENT, Russell King, Jonas ABERG, ext Kevin Hilman,
Peter De-Schrijver, David Brown, Maxime Coquelin, Arnd Bergmann,
linux-arm-msm@vger.kernel.org, Loic PALLARDY, Eduardo Valentin,
maxime_coquelin, Linux-OMAP, linux-arm-kernel
In-Reply-To: <4D9E30AE.9080105@bluewatersys.com>
On Fri, 8 Apr 2011, Ryan Mallon wrote:
> On 04/08/2011 09:29 AM, Arnd Bergmann wrote:
> > I'll try to capture the opinions from the other people as well,
> > hopefully this represents a consensus. Please correct me otherwise.
> >
> > I believe the uncontroversial parts are:
> >
> > * Make it not an entry but a device with certain properties.
> > * Make the naming so that you can have more than one of them.
> > * Put all devices on an SoC that uses this scheme underneath that
> > device by setting their parents to the SoC device.
> >
> > For the location of the device, I have not seen a clear consensus yet,
> > but I'm fine with eihter of these:
> >
> > /sys/devices/soc/${NAME}/
> > /sys/devices/platform/soc${NUMBER}/
>
> I prefer the second format here since the path is always the same which
> makes it easier to write parsing tools. The name should be an entry in
> the directory rather than the name of the directory itself.
>
> Probably SoC number should match CPU number for SMP machines right?
Not really. SOC means System On Chip. you usually have only one SOC on
a board, and within that SOC you may have one or more CPUs. SMP
machines are still likely to have only one SOC.
Nicolas
^ permalink raw reply
* Endless print of uhci_result_common: failed with status 440000
From: Zdenek Kabelac @ 2011-04-07 22:01 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Alan Stern
Hi
While debugging resume problem with Intel HW I've been hitting problem
with endless print of usb 1.1 error message on my T61.
(See my other similar post
http://marc.info/?l=linux-kernel&m=130221292724436&w=2)
This time the problem is generated by Bluetooth device.
Often just only several messages are printed - and then machine
suspend - so the log usually contains only several such message - if
at all - however today with debugging and serial console logging -
I've seen several times - that suspend resulted in endless unbreakable
loop.
As a workaround - one could just disable BT device:
"echo disable >/proc/acpi/ibm/bluetooth"
Here is the log:
[ 0.000000] Linux version 2.6.39-rc2-00005-gf04d4dc (kabi@linux)
(gcc version 4.6.0 20110331 (Red Hat 4.6.0-2) (GCC) ) #119 SMP PREEMPT
Wed Apr 6 15:27:55 CEST 2011
[ 0.000000] Command line: ro root=/dev/sda2 selinux=0 kmemleak=off
lockdep.prove_locking=0 lockdep.lock_stat=0 SYSFONT=latarcyrheb-sun16
LANG=cs_CZ.UTF-8 KEYTABLE=us systemd.log_level=info
systemd.log_target=kmsg systemd.sysv_console=true
console=ttyS0,115200n8 console=tty drm.debug=0xe
..
[ 63.850237] usb 2-1: new full speed USB device number 5 using uhci_hcd
[ 64.003946] usb 2-1: skipped 1 descriptor after interface
[ 64.015946] usb 2-1: default language 0x0409
[ 64.032516] usb 2-1: udev 5, busnum 2, minor = 132
[ 64.039699] usb 2-1: New USB device found, idVendor=0a5c, idProduct=2110
[ 64.048507] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 64.057788] usb 2-1: Product: BCM2045B
[ 64.063791] usb 2-1: Manufacturer: Broadcom Corp
[ 64.071394] usb 2-1: usb_probe_device
[ 64.077084] usb 2-1: configuration #1 chosen from 1 choice
[ 64.087013] usb 2-1: adding 2-1:1.0 (config #1, interface 0)
[ 64.094665] btusb 2-1:1.0: usb_probe_interface
[ 64.100942] btusb 2-1:1.0: usb_probe_interface - got id
[ 64.109662] uhci_hcd 0000:00:1a.0: reserve dev 5 ep81-INT, period
1, phase 0, 23 us
[ 64.119576] usb 2-1: adding 2-1:1.1 (config #1, interface 1)
[ 64.127950] usb 2-1: adding 2-1:1.2 (config #1, interface 2)
[ 64.136924] btusb 2-1:1.2: usb_probe_interface
[ 64.144332] btusb 2-1:1.2: usb_probe_interface - got id
[ 64.152571] usb 2-1: adding 2-1:1.3 (config #1, interface 3)
[ 64.160897] btusb 2-1:1.3: usb_probe_interface
[ 64.167823] btusb 2-1:1.3: usb_probe_interface - got id
...
[ 100.534903] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
(SDVO_CMD_GET_ATTACHED_DISPLAYS)
[ 100.548392] [drm:intel_sdvo_read_response], SDVOB: R: (Success) 00 00
[ 100.560152] [drm:intel_sdvo_detect], SDVO response 0 0 [1]
[ 100.565826] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:15:DVI-D-1] disconnected
[ 100.574551] [drm:drm_mode_getconnector], [CONNECTOR:15:?]
[ 100.580044] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:15:DVI-D-1]
[ 100.587672] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
(SDVO_CMD_GET_ATTACHED_DISPLAYS)
[ 100.601411] [drm:intel_sdvo_read_response], SDVOB: R: (Success) 00 00
[ 100.613202] [drm:intel_sdvo_detect], SDVO response 0 0 [1]
[ 100.618808] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:15:DVI-D-1] disconnected
[ 101.802287] [drm:drm_mode_addfb], [FB:18]
[ 102.142272] [drm:intel_crtc_cursor_set],
[ 102.146471] [drm:intel_crtc_cursor_set], cursor off
[ 103.346753] hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0002
[ 103.352278] usb 2-1: uhci_result_common: failed with status 440000
[ 103.357592] usb 2-1: uhci_result_common: failed with status 440000
[ 103.364864] usb 2-1: uhci_result_common: failed with status 440000
[ 103.368183] usb 2-1: uhci_result_common: failed with status 440000
[ 103.377457] usb 2-1: uhci_result_common: failed with status 440000
[ 103.380772] usb 2-1: uhci_result_common: failed with status 440000
[ 103.390052] usb 2-1: uhci_result_common: failed with status 440000
[ 103.393370] usb 2-1: uhci_result_common: failed with status 440000
[ 103.402631] usb 2-1: uhci_result_common: failed with status 440000
[ 103.405948] usb 2-1: uhci_result_common: failed with status 440000
[ 103.415211] usb 2-1: uhci_result_common: failed with status 440000
[ 103.418532] usb 2-1: uhci_result_common: failed with status 440000
[ 103.427791] usb 2-1: uhci_result_common: failed with status 440000
[ 103.431111] usb 2-1: uhci_result_common: failed with status 440000
[ 103.440365] usb 2-1: uhci_result_common: failed with status 440000
[ 103.443686] usb 2-1: uhci_result_common: failed with status 440000
[ 103.452932] usb 2-1: uhci_result_common: failed with status 440000
[ 103.456247] usb 2-1: uhci_result_common: failed with status 440000
[ 103.465501] usb 2-1: uhci_result_common: failed with status 440000
[ 103.468821] usb 2-1: uhci_result_common: failed with status 440000
[ 103.478074] usb 2-1: uhci_result_common: failed with status 440000
[ 103.481394] usb 2-1: uhci_result_common: failed with status 440000
[ 103.490630] usb 2-1: uhci_result_common: failed with status 440000
[ 103.493950] usb 2-1: uhci_result_common: failed with status 440000
[ 103.503202] usb 2-1: uhci_result_common: failed with status 440000
[ 103.506521] usb 2-1: uhci_result_common: failed with status 440000
[ 103.515763] usb 2-1: uhci_result_common: failed with status 440000
[ 103.519084] usb 2-1: uhci_result_common: failed with status 440000
[ 103.528341] usb 2-1: uhci_result_common: failed with status 440000
[ 103.531661] usb 2-1: uhci_result_common: failed with status 440000
[ 103.540907] usb 2-1: uhci_result_common: failed with status 440000
---repeating ---
[ 141.696075] usb 2-1: uhci_result_common: failed with status 440000
[ 141.699335] usb 2-1: uhci_result_common: failed with status 440000
[ 141.708504] usb 2-1: uhci_result_common: failed with status 440000
[ 141.711826] usb 2-1: uhci_result_common: failed with status 440000
[ 141.720950] usb 2-1: uhci_result_common: failed with status 440000
--- decided to turn off laptop ---
Googling it - seems it's common issue of this BT chipset - but I think
is should not cause suspend deadlock ??
Zdenek
^ permalink raw reply
* Re: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
From: Alexander Holler @ 2011-04-07 21:59 UTC (permalink / raw)
To: Alexander Clouter; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20110407214457.GH26616@chipmunk>
Am 07.04.2011 23:44, schrieb Alexander Clouter:
> * Alexander Holler<holler@ahsoftware.de> [2011-04-07 23:31:08+0200]:
>>
>> Requiring a machine ID and the needed stuff to handle that for a
>> board which just is using two GPIOs different than another board is
>> why the ARM tree exploded. And requiring a machine ID just to follow
>> the rule that a machine ID is much better than some pretty unique hw
>> feature is in my humble opinion senseless and that the resulting code
>> is more readable and better to maintain is a myth.
>>
> It's something that most people agree with you on too. However, I am
> guessing it's around as no one else *at the time* of it's conception
> could think of a better way.
>
> Now this is why there is a lot of work being done on device-tree.
>
>> Sorry that I wanted to help there. Will not try it again.
>>
> Yeah, as obviously no tries to help anyone improve around here:
That is future, I've tried to help with the existing stuff. Maybe I
should have suggested just to remove all boards now which never will get
support for DT. Linux might get happy.
And than I get called that I'm writing an abomination, which would have
been nice with just the change of one line.
Sorry guys, this isn't what motivates people, at least not without the
needed compensations to tolerate such manners.
Regards,
Alexander
^ permalink raw reply
* [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
From: Alexander Holler @ 2011-04-07 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110407214457.GH26616@chipmunk>
Am 07.04.2011 23:44, schrieb Alexander Clouter:
> * Alexander Holler<holler@ahsoftware.de> [2011-04-07 23:31:08+0200]:
>>
>> Requiring a machine ID and the needed stuff to handle that for a
>> board which just is using two GPIOs different than another board is
>> why the ARM tree exploded. And requiring a machine ID just to follow
>> the rule that a machine ID is much better than some pretty unique hw
>> feature is in my humble opinion senseless and that the resulting code
>> is more readable and better to maintain is a myth.
>>
> It's something that most people agree with you on too. However, I am
> guessing it's around as no one else *at the time* of it's conception
> could think of a better way.
>
> Now this is why there is a lot of work being done on device-tree.
>
>> Sorry that I wanted to help there. Will not try it again.
>>
> Yeah, as obviously no tries to help anyone improve around here:
That is future, I've tried to help with the existing stuff. Maybe I
should have suggested just to remove all boards now which never will get
support for DT. Linux might get happy.
And than I get called that I'm writing an abomination, which would have
been nice with just the change of one line.
Sorry guys, this isn't what motivates people, at least not without the
needed compensations to tolerate such manners.
Regards,
Alexander
^ permalink raw reply
* Re: [PATCH] leds: New PCEngines Alix LED driver using gpio interface
From: Andrew Morton @ 2011-04-07 21:58 UTC (permalink / raw)
To: kernel; +Cc: rpurdie, const, daniel, a.zummo, linux-kernel
In-Reply-To: <1299430285-13189-1-git-send-email-kernel@wildgooses.com>
On Sun, 6 Mar 2011 16:51:25 +0000
kernel@wildgooses.com wrote:
> From: Ed Wildgoose <kernel@wildgooses.com>
>
> This new driver replaces the old PCEngines Alix 2/3 LED driver with
> a new driver that controls the LEDs through the leds-gpio driver.
> The old driver accessed GPIOs directly, which created a conflict
> and prevented also loading the cs5535-gio driver to read other
> GPIOs on the Alix board. With this new driver, both are loaded
> and therefore it's possible to access both the LEDs and onboard GPIOs
>
> This driver is based on leds-net5501.c
> by: Alessandro Zummo <a.zummo@towertech.it>
> Additionally it relies on parts of the patch: 7f131cf3ed
> by: Daniel Mack <daniel@caiaq.de> to perform detection of the Alix board
As far as I can tell from looking at it, this driver maintains all the
same interfaces and behaviour as the old version. Am I right?
^ permalink raw reply
* + leds-new-pcengines-alix-led-driver-using-gpio-interface.patch added to -mm tree
From: akpm @ 2011-04-07 21:58 UTC (permalink / raw)
To: mm-commits; +Cc: kernel, a.zummo, daniel, rpurdie
The patch titled
leds: new PCEngines Alix LED driver using gpio interface
has been added to the -mm tree. Its filename is
leds-new-pcengines-alix-led-driver-using-gpio-interface.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: leds: new PCEngines Alix LED driver using gpio interface
From: Ed Wildgoose <kernel@wildgooses.com>
This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
driver that controls the LEDs through the leds-gpio driver. The old
driver accessed GPIOs directly, which created a conflict and prevented
also loading the cs5535-gio driver to read other GPIOs on the Alix board.
With this new driver, both are loaded and therefore it's possible to
access both the LEDs and onboard GPIOs
This driver is based on leds-net5501.c by Alessandro Zummo.
Additionally it relies on parts of the patch: 7f131cf3ed ("leds:
leds-alix2c - take port address from MSR") by Daniel Mack to perform
detection of the Alix board.
Signed-off-by: Ed Wildgoose <kernel@wildgooses.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Daniel Mack <daniel@caiaq.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/leds/Kconfig | 2
drivers/leds/leds-alix2.c | 196 ++++++++----------------------------
2 files changed, 46 insertions(+), 152 deletions(-)
diff -puN drivers/leds/Kconfig~leds-new-pcengines-alix-led-driver-using-gpio-interface drivers/leds/Kconfig
--- a/drivers/leds/Kconfig~leds-new-pcengines-alix-led-driver-using-gpio-interface
+++ a/drivers/leds/Kconfig
@@ -110,7 +110,7 @@ config LEDS_WRAP
config LEDS_ALIX2
tristate "LED Support for ALIX.2 and ALIX.3 series"
depends on LEDS_CLASS
- depends on X86 && !GPIO_CS5535 && !CS5535_GPIO
+ depends on X86 && LEDS_GPIO_PLATFORM && GPIO_CS5535
help
This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
You have to set leds-alix2.force=1 for boards with Award BIOS.
diff -puN drivers/leds/leds-alix2.c~leds-new-pcengines-alix-led-driver-using-gpio-interface drivers/leds/leds-alix2.c
--- a/drivers/leds/leds-alix2.c~leds-new-pcengines-alix-led-driver-using-gpio-interface
+++ a/drivers/leds/leds-alix2.c
@@ -1,119 +1,66 @@
/*
* LEDs driver for PCEngines ALIX.2 and ALIX.3
*
- * Copyright (C) 2008 Constantin Baranov <const@mimas.ru>
+ * Copyright (C) 2011 Nippy Networks Ltd
+ * Written by Ed Wildgoose <kernel@wildgooses.com>
+ * Based on leds-net5501.c by Alessandro Zummo <a.zummo@towertech.it>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
*/
-#include <linux/err.h>
-#include <linux/io.h>
#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/string.h>
#include <linux/leds.h>
-#include <linux/module.h>
#include <linux/platform_device.h>
-#include <linux/string.h>
-#include <linux/pci.h>
+#include <linux/gpio.h>
+
+#include <asm/geode.h>
static int force = 0;
module_param(force, bool, 0444);
MODULE_PARM_DESC(force, "Assume system has ALIX.2/ALIX.3 style LEDs");
-#define MSR_LBAR_GPIO 0x5140000C
-#define CS5535_GPIO_SIZE 256
-
-static u32 gpio_base;
-
-static struct pci_device_id divil_pci[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_CS5535_ISA) },
- { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA) },
- { } /* NULL entry */
-};
-MODULE_DEVICE_TABLE(pci, divil_pci);
-
-struct alix_led {
- struct led_classdev cdev;
- unsigned short port;
- unsigned int on_value;
- unsigned int off_value;
-};
-
-static void alix_led_set(struct led_classdev *led_cdev,
- enum led_brightness brightness)
-{
- struct alix_led *led_dev =
- container_of(led_cdev, struct alix_led, cdev);
-
- if (brightness)
- outl(led_dev->on_value, gpio_base + led_dev->port);
- else
- outl(led_dev->off_value, gpio_base + led_dev->port);
-}
-
-static struct alix_led alix_leds[] = {
+static struct gpio_led alix_leds[] = {
{
- .cdev = {
- .name = "alix:1",
- .brightness_set = alix_led_set,
- },
- .port = 0x00,
- .on_value = 1 << 22,
- .off_value = 1 << 6,
+ .name = "alix:1",
+ .gpio = 6,
+ .default_trigger = "default-on",
+ .active_low = 1,
},
{
- .cdev = {
- .name = "alix:2",
- .brightness_set = alix_led_set,
- },
- .port = 0x80,
- .on_value = 1 << 25,
- .off_value = 1 << 9,
+ .name = "alix:2",
+ .gpio = 25,
+ .default_trigger = "default-off",
+ .active_low = 1,
},
{
- .cdev = {
- .name = "alix:3",
- .brightness_set = alix_led_set,
- },
- .port = 0x80,
- .on_value = 1 << 27,
- .off_value = 1 << 11,
+ .name = "alix:3",
+ .gpio = 27,
+ .default_trigger = "default-off",
+ .active_low = 1,
},
};
-static int __init alix_led_probe(struct platform_device *pdev)
-{
- int i;
- int ret;
-
- for (i = 0; i < ARRAY_SIZE(alix_leds); i++) {
- alix_leds[i].cdev.flags |= LED_CORE_SUSPENDRESUME;
- ret = led_classdev_register(&pdev->dev, &alix_leds[i].cdev);
- if (ret < 0)
- goto fail;
- }
- return 0;
+static struct gpio_led_platform_data alix_leds_data = {
+ .num_leds = ARRAY_SIZE(alix_leds),
+ .leds = alix_leds,
+};
-fail:
- while (--i >= 0)
- led_classdev_unregister(&alix_leds[i].cdev);
- return ret;
-}
+static struct platform_device alix_leds_dev = {
+ .name = "leds-gpio",
+ .id = -1,
+ .dev.platform_data = &alix_leds_data,
+};
-static int alix_led_remove(struct platform_device *pdev)
+static void __init register_alix(void)
{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(alix_leds); i++)
- led_classdev_unregister(&alix_leds[i].cdev);
- return 0;
+ platform_device_register(&alix_leds_dev);
}
-static struct platform_driver alix_led_driver = {
- .remove = alix_led_remove,
- .driver = {
- .name = KBUILD_MODNAME,
- .owner = THIS_MODULE,
- },
-};
-
static int __init alix_present(unsigned long bios_phys,
const char *alix_sig,
size_t alix_sig_len)
@@ -164,76 +111,23 @@ static int __init alix_present(unsigned
return 0;
}
-static struct platform_device *pdev;
-
-static int __init alix_pci_led_init(void)
+static int __init alix_init(void)
{
- u32 low, hi;
-
- if (pci_dev_present(divil_pci) == 0) {
- printk(KERN_WARNING KBUILD_MODNAME": DIVIL not found\n");
- return -ENODEV;
- }
-
- /* Grab the GPIO I/O range */
- rdmsr(MSR_LBAR_GPIO, low, hi);
-
- /* Check the mask and whether GPIO is enabled (sanity check) */
- if (hi != 0x0000f001) {
- printk(KERN_WARNING KBUILD_MODNAME": GPIO not enabled\n");
- return -ENODEV;
- }
-
- /* Mask off the IO base address */
- gpio_base = low & 0x0000ff00;
-
- if (!request_region(gpio_base, CS5535_GPIO_SIZE, KBUILD_MODNAME)) {
- printk(KERN_ERR KBUILD_MODNAME": can't allocate I/O for GPIO\n");
- return -ENODEV;
- }
-
- /* Set GPIO function to output */
- outl(1 << 6, gpio_base + 0x04);
- outl(1 << 9, gpio_base + 0x84);
- outl(1 << 11, gpio_base + 0x84);
-
- return 0;
-}
-
-static int __init alix_led_init(void)
-{
- int ret = -ENODEV;
const char tinybios_sig[] = "PC Engines ALIX.";
const char coreboot_sig[] = "PC Engines\0ALIX.";
+ if (!is_geode())
+ return 0;
+
if (alix_present(0xf0000, tinybios_sig, sizeof(tinybios_sig) - 1) ||
alix_present(0x500, coreboot_sig, sizeof(coreboot_sig) - 1))
- ret = alix_pci_led_init();
+ register_alix();
- if (ret < 0)
- return ret;
-
- pdev = platform_device_register_simple(KBUILD_MODNAME, -1, NULL, 0);
- if (!IS_ERR(pdev)) {
- ret = platform_driver_probe(&alix_led_driver, alix_led_probe);
- if (ret)
- platform_device_unregister(pdev);
- } else
- ret = PTR_ERR(pdev);
-
- return ret;
-}
^ permalink raw reply
* Re: [PATCH 1/2] rename alloc_pages_exact()
From: Dave Hansen @ 2011-04-07 21:58 UTC (permalink / raw)
To: David Rientjes
Cc: linux-mm, linux-kernel, Timur Tabi, Andi Kleen, Mel Gorman,
Andrew Morton
In-Reply-To: <alpine.DEB.2.00.1104071437130.14967@chino.kir.corp.google.com>
On Thu, 2011-04-07 at 14:40 -0700, David Rientjes wrote:
> > alloc_pages_exact() returns a virtual address. But, alloc_pages() returns
> > a 'struct page *'. That makes for very confused kernel hackers.
> >
> > __get_free_pages(), on the other hand, returns virtual addresses. That
> > makes alloc_pages_exact() a much closer match to __get_free_pages(), so
> > rename it to get_free_pages_exact().
> >
>
> The patch also reverses the arguments of the function in
> include/linux/gfp.h, undoubtedly to resemble the (mask, order) appearance
> of __get_free_pages():
>
> -void *alloc_pages_exact(size_t size, gfp_t gfp_mask);
> +void *get_free_pages_exact(gfp_t gfp_mask, size_t size);
Thanks. I dumped the fixes for that in the second patch. Whoops. Will
repost.
-- Dave
^ permalink raw reply
* Re: [PATCH 1/2] rename alloc_pages_exact()
From: Dave Hansen @ 2011-04-07 21:58 UTC (permalink / raw)
To: David Rientjes
Cc: linux-mm, linux-kernel, Timur Tabi, Andi Kleen, Mel Gorman,
Andrew Morton
In-Reply-To: <alpine.DEB.2.00.1104071437130.14967@chino.kir.corp.google.com>
On Thu, 2011-04-07 at 14:40 -0700, David Rientjes wrote:
> > alloc_pages_exact() returns a virtual address. But, alloc_pages() returns
> > a 'struct page *'. That makes for very confused kernel hackers.
> >
> > __get_free_pages(), on the other hand, returns virtual addresses. That
> > makes alloc_pages_exact() a much closer match to __get_free_pages(), so
> > rename it to get_free_pages_exact().
> >
>
> The patch also reverses the arguments of the function in
> include/linux/gfp.h, undoubtedly to resemble the (mask, order) appearance
> of __get_free_pages():
>
> -void *alloc_pages_exact(size_t size, gfp_t gfp_mask);
> +void *get_free_pages_exact(gfp_t gfp_mask, size_t size);
Thanks. I dumped the fixes for that in the second patch. Whoops. Will
repost.
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive
From: Gavin Flower @ 2011-04-07 21:58 UTC (permalink / raw)
To: neilb; +Cc: linux-raid
Hi Neil,
After further checking, I found there was no problem with the swap partition.
Cheers,
Gavin
--
All Adults share the Responsibility
to help Raise Today's Children,
for they are Tomorrow's Society!
--- On Thu, 7/4/11, Gavin Flower <gavinflower@yahoo.com> wrote:
> From: Gavin Flower <gavinflower@yahoo.com>
> Subject: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive
> To: neilb@suse.de
> Cc: linux-raid@vger.kernel.org
> Date: Thursday, 7 April, 2011, 18:07
[...]
> Somewhere along the way, I seemed to have lost my swap
> partition!
[...]
^ permalink raw reply
* Re: [RFC PATCHv2 4/5] hwmon: lis3: Remove the referencies to the global variable in core driver
From: Thadeu Lima de Souza Cascardo @ 2011-04-07 21:58 UTC (permalink / raw)
To: Ilkka Koskinen
Cc: Ilkka Koskinen, eric.piel, mjg, linux-kernel, platform-driver-x86,
samu.p.onkalo, linux-input
In-Reply-To: <alpine.DEB.2.00.1104071448290.9511@tumpelo.nmp.nokia.com>
[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]
On Thu, Apr 07, 2011 at 02:59:48PM +0300, Ilkka Koskinen wrote:
>
> Hi,
>
> Thanks for the comments!
>
> On Tue, 5 Apr 2011, ext Thadeu Lima de Souza Cascardo wrote:
> >On Tue, Apr 05, 2011 at 05:45:13PM +0300, Ilkka Koskinen wrote:
> >>Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
> >>---
> >> drivers/misc/lis3lv02d/lis3lv02d.c | 237 ++++++++++++++++++++----------------
> >> drivers/misc/lis3lv02d/lis3lv02d.h | 3 +
> >> 2 files changed, 135 insertions(+), 105 deletions(-)
>
> >>@@ -980,14 +1003,18 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
> >> thread_fn,
> >> IRQF_TRIGGER_RISING | IRQF_ONESHOT |
> >> irq_flags,
> >>- DRIVER_NAME, &lis3_dev);
> >>+ DRIVER_NAME, lis3);
> >>
> >> if (err < 0) {
> >> pr_err("Cannot get IRQ\n");
> >> goto out;
> >> }
> >>
> >>- if (misc_register(&lis3lv02d_misc_device))
> >>+ lis3->miscdev.minor = MISC_DYNAMIC_MINOR;
> >>+ lis3->miscdev.name = "freefall";
> >>+ lis3->miscdev.fops = &lis3lv02d_misc_fops;
> >>+
> >>+ if (misc_register(&lis3->miscdev))
> >> pr_err("misc_register failed\n");
> >
> >You should not use miscdevice in case there will be multiple devices.
> >First, it will fail. There cannot be more than one device with the same
> >name. Second, current dynamic minor devices is restricted to 64 devices.
> >Since this is reserved to one-shot devices, freefall was OK as a misc
> >device until you fixed it to allow multiple freefall devices. :-)
>
> Ah, true :)
>
> >So, I'd recommend switching to a new device class, and have freefall0,
> >freefall1, etc.
>
> I wonder if introducing a new class makes sense. I mean, I can
> figure out use cases for several accelerometers but for several free
> fall sensors? :/
>
> Would it be better to add a mechanism to tell to the core module if
> the particular device is used for free fall detection or not?
>
> Cheers, Ilkka
>
I would suggest an input handler or just letting userspace handle that
using input events. Then, I checked out the code and realized that this
is done by the hardware, using an interrupt. Should we handle said
interrupt as a particular kind of event (perhaps a new misc event)?
I've written classmate-laptop driver, which has an accelerometer too
(using ACPI). Should we start documenting how accelerometer drivers
should be written? Input event devices are the best class, but I've seen
cases where drivers use sysfs files. In fact, I've just checked and seen
that lis3lv02d does that too, in the file position. But I've seen
drivers out there that use one file per axis. I guess that's the way
hwmon drivers usually do things, creating sysfs files.
Should we start standardizing these drivers? I think input devices are
good enough to report the data, including for 2-axis devices (I have one
SPI "inclinometer" here - how those should be distinguished?). sysfs
files would be nice for setting parameters. classmate-laptop, for
example, has a sensitivity parameter. Besides freefall, lis3 seems to
have a selftest function and a rate setting.
One last email in linux-input and pdx lists has requested a new MISC
event to report a change in direction for some devices. Although I think
freefall and change in direction could be computed using the
accelerometer values in userspace, these devices do it directly. How
should we handle them in a standard way?
I would like to gather some opinions before writing a draft of
recommendations for writing such drivers. Is linux-input the best forum
for this?
Regards,
Cascardo.
> >Anyway, good job on this.
> >
> >Regards,
> >Cascardo.
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH perf 0/2] perf: trace-event-parse: support more operators and print formats
From: Frederic Weisbecker @ 2011-04-07 21:57 UTC (permalink / raw)
To: David Sharp
Cc: linux-kernel, mrubin, Arnaldo Carvalho de Melo, Steven Rostedt,
Ingo Molnar, Stephane Eranian
In-Reply-To: <BANLkTin43CY46KTb2WOTK0hgm2bN1VbP4w@mail.gmail.com>
On Thu, Apr 07, 2011 at 01:25:04PM -0700, David Sharp wrote:
> On Thu, Apr 7, 2011 at 7:26 AM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Wed, Apr 06, 2011 at 07:01:40PM -0700, David Sharp wrote:
> >> Hi, any feedback on these patches? I think it's important that perf
> >> and trace-cmd don't drift in the syntax they accept.
> >>
> >> d#
> >
> > Sorry, I forgot these.
> >
> >> On Mon, Mar 21, 2011 at 3:34 PM, David Sharp <dhsharp@google.com> wrote:
> >> > These patches correspond to similar patches recently applied to trace-cmd
> >> >
> >> > [ Re-sending with more Cc's ]
> >> >
> >> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> >> > Cc: Frederic Weisbecker <fweisbec@gmail.com>
> >> > Cc: Steven Rostedt <rostedt@goodmis.org>
> >> > Cc: Ingo Molnar <mingo@elte.hu>
> >> > Cc: Stephane Eranian <eranian@google.com>
> >> >
> >> >
> >> > David Sharp (2):
> >> > perf: trace-event-parse: support additional operators: '!', '~', and
> >> > '!='
> >> > perf: trace-event-parse: support printing short fields
> >
> > So we now have trace events that use these new operations? Which ones?
> > A quick grep on "TP_printk" and "!" doesn't give me any result, probably
> > because TP_printk is often multiline.
> >
>
> We (google) have some events that use '~' and '!', and I threw in '!='
> mostly because it needed to be differentiated from '!' during
> tokenizing.
>
> We set the MSB of the syscall number in raw_syscalls events to
> indicate a compat syscall, and use '~' and '!' (and '&' and '>>') to
> extract the bit. eg, for sys_exit:
> print fmt: "NR %ld = %ld isCompat: %d", REC->id & (~0UL>>1), REC->ret,
> !!(REC->id & ~(~0UL>>1))
> Patches for this will be forthcoming, but, you know: time.
Please consider the compat syscall tracing patches from Jason Baron
and Ian Munsie:
http://lkml.org/lkml/2010/6/23/69
They were pretty clean IIRC. Someone just need to rebase them, clean
up some last things and repost.
>
> If our internally-added events are not sufficient reason, I think it
> still makes sense to support as much of the C expression syntax as
> reasonable. Leaving holes in the syntax mostly just causes frustration
> when these operators would be useful. And since they do work with the
> in-kernel output (which has the whole compiler to leverage), use of
> unsupported operators can go unnoticed for quite a while.
Hmm, ok.
^ permalink raw reply
* Re: [ath9k-devel] Override Minstrel HT RC to set an MCS bitrate (mask)
From: M. A. @ 2011-04-07 21:56 UTC (permalink / raw)
To: ath9k-devel, linux-wireless
In-Reply-To: <AANLkTinRhmByJFoMLsN82ZVfvRa=WOsKVhAcbk8hX2Pv@mail.gmail.com>
Dear all,
Can anyone help in fixing/ overriding MCS rates as described above,
Thank you all!
On Tue, Mar 15, 2011 at 5:02 AM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Tue, Mar 8, 2011 at 11:10 PM, M. A. <jdiq123@googlemail.com> wrote:
>> Hi all,
>>
>> My question is how can I modify Minstrel HT rate control to be able to
>> override it (by a boolean or otherwise) to select an MCS or specific
>> rate index from user space (such that once set it driver will only try
>> sending at that rate until unset then driver will resort back to
>> Minstrel RC).
>
> I don't think we can fix the MCS rate index from user space, may be we
> need a hack.
> iw dev <devname> set bitrates [legacy-<2.4|5> <legacy rate in Mbps>*]
> and this is only for legacy rates.
>
>
>>
>> I have been able to change other kernel parameters at runtime(echo
>> /sys/kernel/debug/ieee80211/...) by passing them through (fops) to
>> DebugFs. however I am unsure of what parameters to pass through in the
>> case of MCS rate fixing and what modifications to the code are
>> required to achieve this.
>
> don't know and I am not sure whether this can be easily done.
>
>>
>>
>> Also I have been told that these sections of code facilitate the
>> masking of rates;
>>
>> =========================================================================
>> include/net/cfg80211.h: cfg80211_bitrate_mask
>> -------------------------------------------------------------------------------------------------------
>> /*
>> * cfg80211_bitrate_mask - masks for bitrate control
>> */
>> struct cfg80211_bitrate_mask {
>> struct {
>> u32 legacy;
>> /* TODO: add support for masking MCS rates; e.g.: */
>> /* u8 mcs[IEEE80211_HT_MCS_MASK_LEN]; */
>> } control[IEEE80211_NUM_BANDS];
>> };
>> -------------------------------------------------------------------------------------------------------
>> net/mac80211/cfg.c ieee80211_set_bitrate_mask
>> -------------------------------------------------------------------------------------------------------
>> static int ieee80211_set_bitrate_mask(struct wiphy *wiphy,
>> struct net_device *dev,
>> const u8 *addr,
>> const struct cfg80211_bitrate_mask *mask)
>> {
>> struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>> struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
>> int i;
>>
>> /*
>> * This _could_ be supported by providing a hook for
>> * drivers for this function, but at this point it
>> * doesn't seem worth bothering.
>> */
>> if (local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL)
>> return -EOPNOTSUPP;
>>
>>
>> for (i = 0; i < IEEE80211_NUM_BANDS; i++)
>> sdata->rc_rateidx_mask[i] = mask->control[i].legacy;
>>
>> return 0;
>> }
>> -------------------------------------------------------------------------------------------------------
>> net/wireless/nl80211.c: nl80211_set_tx_bitrate_mask
>> -------------------------------------------------------------------------------------------------------
>> static int nl80211_set_tx_bitrate_mask(struct sk_buff *skb,
>> struct genl_info *info)
>> {
>> struct nlattr *tb[NL80211_TXRATE_MAX + 1];
>> struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> struct cfg80211_bitrate_mask mask;
>> int rem, i;
>> struct net_device *dev = info->user_ptr[1];
>> struct nlattr *tx_rates;
>> struct ieee80211_supported_band *sband;
>>
>> if (info->attrs[NL80211_ATTR_TX_RATES] == NULL)
>> return -EINVAL;
>>
>> if (!rdev->ops->set_bitrate_mask)
>> return -EOPNOTSUPP;
>>
>> memset(&mask, 0, sizeof(mask));
>> /* Default to all rates enabled */
>> for (i = 0; i < IEEE80211_NUM_BANDS; i++) {
>> sband = rdev->wiphy.bands[i];
>> mask.control[i].legacy =
>> sband ? (1 << sband->n_bitrates) - 1 : 0;
>> }
>>
>> /*
>> * The nested attribute uses enum nl80211_band as the index. This maps
>> * directly to the enum ieee80211_band values used in cfg80211.
>> */
>> nla_for_each_nested(tx_rates, info->attrs[NL80211_ATTR_TX_RATES], rem)
>> {
>> enum ieee80211_band band = nla_type(tx_rates);
>> if (band < 0 || band >= IEEE80211_NUM_BANDS)
>> return -EINVAL;
>> sband = rdev->wiphy.bands[band];
>> if (sband == NULL)
>> return -EINVAL;
>> nla_parse(tb, NL80211_TXRATE_MAX, nla_data(tx_rates),
>> nla_len(tx_rates), nl80211_txattr_policy);
>> if (tb[NL80211_TXRATE_LEGACY]) {
>> mask.control[band].legacy = rateset_to_mask(
>> sband,
>> nla_data(tb[NL80211_TXRATE_LEGACY]),
>> nla_len(tb[NL80211_TXRATE_LEGACY]));
>> if (mask.control[band].legacy == 0)
>> return -EINVAL;
>> }
>> }
>>
>> return rdev->ops->set_bitrate_mask(&rdev->wiphy, dev, NULL, &mask);
>> }
>
> As you see everything is for legacy thing and for MCS it's a TODO section.
>
>> ====================================================================================================================
>>
>>
>> Any help is much appreciated!
>>
>> Thank you all very much
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
^ permalink raw reply
* [ath9k-devel] Override Minstrel HT RC to set an MCS bitrate (mask)
From: M. A. @ 2011-04-07 21:56 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <AANLkTinRhmByJFoMLsN82ZVfvRa=WOsKVhAcbk8hX2Pv@mail.gmail.com>
Dear all,
Can anyone help in fixing/ overriding MCS rates as described above,
Thank you all!
On Tue, Mar 15, 2011 at 5:02 AM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Tue, Mar 8, 2011 at 11:10 PM, M. A. <jdiq123@googlemail.com> wrote:
>> Hi all,
>>
>> My question is how can I modify Minstrel HT rate control to be able to
>> override it (by a boolean or otherwise) to select an MCS or specific
>> rate index from user space (such that once set it driver will only try
>> sending at that rate until unset then driver will resort back to
>> Minstrel RC).
>
> I don't think we can fix the MCS rate index from user space, may be we
> need a hack.
> iw ?dev <devname> set bitrates [legacy-<2.4|5> <legacy rate in Mbps>*]
> and this is only for legacy rates.
>
>
>>
>> I have been able to change other kernel parameters at runtime(echo
>> /sys/kernel/debug/ieee80211/...) by passing them through (fops) to
>> DebugFs. however I am unsure of what parameters to pass through in the
>> case of MCS rate fixing and what modifications to the code are
>> required to achieve this.
>
> don't know and I am not sure whether this can be easily done.
>
>>
>>
>> Also I have been told that these sections of code facilitate the
>> masking of rates;
>>
>> =========================================================================
>> include/net/cfg80211.h: cfg80211_bitrate_mask
>> -------------------------------------------------------------------------------------------------------
>> /*
>> ?* cfg80211_bitrate_mask - masks for bitrate control
>> ?*/
>> struct cfg80211_bitrate_mask {
>> ? ? ? ?struct {
>> ? ? ? ? ? ? ? ?u32 legacy;
>> ? ? ? ? ? ? ? ?/* TODO: add support for masking MCS rates; e.g.: */
>> ? ? ? ? ? ? ? ?/* u8 mcs[IEEE80211_HT_MCS_MASK_LEN]; */
>> ? ? ? ?} control[IEEE80211_NUM_BANDS];
>> };
>> -------------------------------------------------------------------------------------------------------
>> net/mac80211/cfg.c ieee80211_set_bitrate_mask
>> -------------------------------------------------------------------------------------------------------
>> static int ieee80211_set_bitrate_mask(struct wiphy *wiphy,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct net_device *dev,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const u8 *addr,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const struct cfg80211_bitrate_mask *mask)
>> {
>> ? ? ? ?struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>> ? ? ? ?struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
>> ? ? ? ?int i;
>>
>> ? ? ? ?/*
>> ? ? ? ? * This _could_ be supported by providing a hook for
>> ? ? ? ? * drivers for this function, but at this point it
>> ? ? ? ? * doesn't seem worth bothering.
>> ? ? ? ? */
>> ? ? ? ?if (local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL)
>> ? ? ? ? ? ? ? ?return -EOPNOTSUPP;
>>
>>
>> ? ? ? ?for (i = 0; i < IEEE80211_NUM_BANDS; i++)
>> ? ? ? ? ? ? ? ?sdata->rc_rateidx_mask[i] = mask->control[i].legacy;
>>
>> ? ? ? ?return 0;
>> }
>> -------------------------------------------------------------------------------------------------------
>> net/wireless/nl80211.c: nl80211_set_tx_bitrate_mask
>> -------------------------------------------------------------------------------------------------------
>> static int nl80211_set_tx_bitrate_mask(struct sk_buff *skb,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct genl_info *info)
>> {
>> ? ? ? ?struct nlattr *tb[NL80211_TXRATE_MAX + 1];
>> ? ? ? ?struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> ? ? ? ?struct cfg80211_bitrate_mask mask;
>> ? ? ? ?int rem, i;
>> ? ? ? ?struct net_device *dev = info->user_ptr[1];
>> ? ? ? ?struct nlattr *tx_rates;
>> ? ? ? ?struct ieee80211_supported_band *sband;
>>
>> ? ? ? ?if (info->attrs[NL80211_ATTR_TX_RATES] == NULL)
>> ? ? ? ? ? ? ? ?return -EINVAL;
>>
>> ? ? ? ?if (!rdev->ops->set_bitrate_mask)
>> ? ? ? ? ? ? ? ?return -EOPNOTSUPP;
>>
>> ? ? ? ?memset(&mask, 0, sizeof(mask));
>> ? ? ? ?/* Default to all rates enabled */
>> ? ? ? ?for (i = 0; i < IEEE80211_NUM_BANDS; i++) {
>> ? ? ? ? ? ? ? ?sband = rdev->wiphy.bands[i];
>> ? ? ? ? ? ? ? ?mask.control[i].legacy =
>> ? ? ? ? ? ? ? ? ? ? ? ?sband ? (1 << sband->n_bitrates) - 1 : 0;
>> ? ? ? ?}
>>
>> ? ? ? ?/*
>> ? ? ? ? * The nested attribute uses enum nl80211_band as the index. This maps
>> ? ? ? ? * directly to the enum ieee80211_band values used in cfg80211.
>> ? ? ? ? */
>> ? ? ? ?nla_for_each_nested(tx_rates, info->attrs[NL80211_ATTR_TX_RATES], rem)
>> ? ? ? ?{
>> ? ? ? ? ? ? ? ?enum ieee80211_band band = nla_type(tx_rates);
>> ? ? ? ? ? ? ? ?if (band < 0 || band >= IEEE80211_NUM_BANDS)
>> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
>> ? ? ? ? ? ? ? ?sband = rdev->wiphy.bands[band];
>> ? ? ? ? ? ? ? ?if (sband == NULL)
>> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
>> ? ? ? ? ? ? ? ?nla_parse(tb, NL80211_TXRATE_MAX, nla_data(tx_rates),
>> ? ? ? ? ? ? ? ? ? ? ? ? ?nla_len(tx_rates), nl80211_txattr_policy);
>> ? ? ? ? ? ? ? ?if (tb[NL80211_TXRATE_LEGACY]) {
>> ? ? ? ? ? ? ? ? ? ? ? ?mask.control[band].legacy = rateset_to_mask(
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sband,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?nla_data(tb[NL80211_TXRATE_LEGACY]),
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?nla_len(tb[NL80211_TXRATE_LEGACY]));
>> ? ? ? ? ? ? ? ? ? ? ? ?if (mask.control[band].legacy == 0)
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
>> ? ? ? ? ? ? ? ?}
>> ? ? ? ?}
>>
>> ? ? ? ?return rdev->ops->set_bitrate_mask(&rdev->wiphy, dev, NULL, &mask);
>> }
>
> As you see everything is for legacy thing and for MCS it's a TODO section.
>
>> ====================================================================================================================
>>
>>
>> Any help is much appreciated!
>>
>> Thank you all very much
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
^ permalink raw reply
* Re: [PATCH] net: enic: convert to hw_features
From: roprabhu @ 2011-04-07 21:55 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev, Christian Benvenuti, Vasanthy Kolluri, David Wang
In-Reply-To: <20110407204506.GA18509@rere.qmqm.pl>
On 4/7/11 1:45 PM, "Michał Mirosław" <mirq-linux@rere.qmqm.pl> wrote:
> On Thu, Apr 07, 2011 at 12:52:45PM -0700, roprabhu wrote:
>> Thanks michal.
>>
>> One small comment below,
>>
>> On 4/7/11 5:43 AM, "Michał Mirosław" <mirq-linux@rere.qmqm.pl> wrote:
>>> As the driver uses GRO and not LRO, LRO settings are ignored anyway
>>> and are removed here to avoid confusion.
> [...]
>>> diff --git a/drivers/net/enic/enic_res.c b/drivers/net/enic/enic_res.c
>>> index f111a37..6e5c635 100644
>>> --- a/drivers/net/enic/enic_res.c
>>> +++ b/drivers/net/enic/enic_res.c
>>> @@ -98,9 +98,9 @@ int enic_get_vnic_config(struct enic *enic)
>>> "vNIC MAC addr %pM wq/rq %d/%d mtu %d\n",
>>> enic->mac_addr, c->wq_desc_count, c->rq_desc_count, c->mtu);
>>> dev_info(enic_get_dev(enic), "vNIC csum tx/rx %d/%d "
>>> - "tso/lro %d/%d intr timer %d usec rss %d\n",
>>> + "tso %d intr timer %d usec rss %d\n",
>>> ENIC_SETTING(enic, TXCSUM), ENIC_SETTING(enic, RXCSUM),
>>> - ENIC_SETTING(enic, TSO), ENIC_SETTING(enic, LRO),
>>> + ENIC_SETTING(enic, TSO),
>>> c->intr_timer_usec, ENIC_SETTING(enic, RSS));
>>>
>> You are right about the driver using GRO and not LRO by default. But the
>> config entry from where enic gets this setting is still called LRO for
>> reasons out of the scope of the driver. Yes, I see that it can lead to
>> confusion. So, we will need to retain the ENIC_SETTING(enic, LRO) but fix
>> the name of that setting. Thanks for pointing this out. We will fix this
>> and any other changes if required and resubmit.
>
> I removed this part because now network core is always turning on GRO
> by default regardless of what driver sets in features at init time.
> That's on purpose, since GRO is purely a software feature.
>
> OTOH, if you want to forcibly disable GRO when LRO is not set in enic's
> config, then you can do so in ndo_fix_features callback.
>
Ok thanks michal.
^ permalink raw reply
* Re: [PATCHES] Generalize PCI <-> OF node matching
From: Benjamin Herrenschmidt @ 2011-04-07 21:50 UTC (permalink / raw)
To: monstr; +Cc: linux-pci, linux-arch, linux-kernel, davem, bheglaas, tglx,
bigeasy
In-Reply-To: <4D9DA5DF.8020303@monstr.eu>
On Thu, 2011-04-07 at 13:54 +0200, Michal Simek wrote:
> There are several coding style issues.
> Please look at it through checkpatch.pl.
I tend to generally ignore checkpatch :-) I have my reasons... I'll have
a quick look see if there's anything really worthwhile in there but in
general I dislike "absolute" rules such as what checkpatch imposes.
> Compilation is fine for Microblaze as you surely saw.
> I am not able to test it on real hw right now but I will ask for
> remote connection to the board.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* [U-Boot] DM9000 on 2011.03
From: Wolfgang Denk @ 2011-04-07 21:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BANLkTim4FBa-fvd9i=XpmjKPBZcio-K-vg@mail.gmail.com>
Dear haifeng zhang,
In message <BANLkTim4FBa-fvd9i=XpmjKPBZcio-K-vg@mail.gmail.com> you wrote:
>
> I am trying to run u-boot-2011.03 on Mini2440 (samsung S3c2440), now uboot
> is running,
>
> I have some trouble with network chip dm9000 ,
> Uboot can detect the chip
> "net: dm9000"
>
> when doing ping, it keeps showing
> "raise:signal # 8 caught"
Which tool chain are you using? Try another one.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy arrangement for
the people. - Eleanor Roosevelt
^ permalink raw reply
* Re: [PATCH 2/3] drm/i915: split irq handling into per-chipset functions
From: Chris Wilson @ 2011-04-07 21:50 UTC (permalink / raw)
To: Jesse Barnes, intel-gfx
In-Reply-To: <1302211980-10089-3-git-send-email-jbarnes@virtuousgeek.org>
On Thu, 7 Apr 2011 14:32:59 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Set the IRQ handling functions in driver load so they'll just be used
> directly, rather than branching over most of the code in the chipset
> functions.
This is the direction we definitely need to go in. However, it is still a
tangled mess of which functions are called for which chipset.
Is it any clearer to have a display vfunc table for each chipset? It would
still be a mess, but at least there will be an overview of how each chipset
works in a single spot. Invaluable for tracing through the function
pointers later.
One thing we need to be careful is to move the common code into small
helper routines to avoid unnecessarily duplicating it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [U-Boot] [PATCH v3 4/4] ARMV7: OMAP3: Add support for Comelit DIG297 board
From: Wolfgang Denk @ 2011-04-07 21:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D9E12B7.2040809@comelit.it>
Dear Luca Ceresoli,
In message <4D9E12B7.2040809@comelit.it> you wrote:
>
> I'm going to define the bit values for the GPMC_CONFIGn registers.
> Is arch/arm/include/asm/arch-omap3/omap_gpmc.h the correct place?
I think so, but I'm not an OMAP expert.
Sandeep?
> > Is this the correct machine ID? "OMAP3_CPS" does not really relate to
> > the board name, "DIG297" ?
> As per our previous discussion (see the bottom of
> http://lists.denx.de/pipermail/u-boot/2011-March/088964.html), I renamed the
> board everywhere except for the Machine ID in the ARM registry, and
> consequently mach-types.h.
> As you suggested, I plan to ask for a rename in the registry just after this
> patch series is integrated in U-Boot, to avoid confusion. The rename in
> mach-types.h and in my code would follow.
Ah, now I remember. OK.
> > Incorrect multiline comment style, please fix globally.
> Do you mean like this?
>
> - /* GPIO list
> + /*
> + * GPIO list
Yes.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The more complex the mind, the greater the need for the simplicity of
play.
-- Kirk, "Shore Leave", stardate 3025.8
^ permalink raw reply
* Re: Prioritizing readdirplus/getattr/lookup
From: Andrew Klaassen @ 2011-04-07 21:49 UTC (permalink / raw)
To: Chuck Lever; +Cc: Benny Halevy, Jim Rees, Garth Gibson, linux-nfs
In-Reply-To: <514401.95922.qm@web65408.mail.ac4.yahoo.com>
--- On Thu, 4/7/11, Andrew Klaassen <clawsoon@yahoo.com> wrote:
> I do notice that ksoftirqd is eating up 100% of a core when
> I'm loading the server heavily. I assume that's
> because I'm not using jumbo frames and the ethernet cards
> are spitting out interrupts as fast as they're able.
I just got myself edjumicated on smp_affinity, and now I'm able to achieve 99% CPU usage by 8 nfsd processes on 8 cores on a read-only, fully-cached workload, with ksoftirqd processes only using 1% CPU per core.
Unfortunately, this doesn't help the "ls -l" speed.
Andrew
^ permalink raw reply
* Questions about rt2800usb
From: Larry Finger @ 2011-04-07 21:49 UTC (permalink / raw)
To: Jett Chen; +Cc: wireless
I know from experience that the staging driver rt82860sta has been replaced by
rt2800pci and I plan to push a patch deleting the driver from staging.
It appears that rt2870sta has been replaced by rt2800usb. Is that correct? If
so, I will also include the deletion of that driver from staging in the patch.
I noticed that rt2870sta includes a few USB IDs not found in rt2800usb, namely:
0x2001:0x3c09, 0x2001:0x3c0a, and 0x2019:0xed14.
Any reasons why these should not be included in rt2800usb?
Please let me know of any objections to removing those two staging drivers.
Thanks,
Larry
^ permalink raw reply
* LVM2 ./WHATS_NEW lib/metadata/lv_manip.c
From: jbrassow @ 2011-04-07 21:49 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: jbrassow at sourceware.org 2011-04-07 21:49:30
Modified files:
. : WHATS_NEW
lib/metadata : lv_manip.c
Log message:
Thanks to Zdenek Kabelac (kabi) for pointing out that I was using
dm_pool_free incorrectly. This check-in fixes that incorrect usage.
I've also added a WHATS_NEW line to reflect the changes I made to allow
lv_extend to operate on 0 length intrinsically layered LVs (i.e mirrors
and RAID). I forgot that in the last commit.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.1967&r2=1.1968
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/lv_manip.c.diff?cvsroot=lvm2&r1=1.255&r2=1.256
--- LVM2/WHATS_NEW 2011/03/30 13:14:34 1.1967
+++ LVM2/WHATS_NEW 2011/04/07 21:49:29 1.1968
@@ -1,5 +1,6 @@
Version 2.02.85 -
===================================
+ Allow lv_extend() to work on zero length intrinsically layered LVs.
Keep the cache content when the exported vg buffer is matching.
Extend the set of memory regions, that are not locked to memory.
Enhance usability with the valgrind memcheck tool.
--- LVM2/lib/metadata/lv_manip.c 2011/04/06 21:32:20 1.255
+++ LVM2/lib/metadata/lv_manip.c 2011/04/07 21:49:29 1.256
@@ -2114,8 +2114,8 @@
struct logical_volume *sub_lv;
uint32_t i;
uint64_t status = 0;
- char *img_name;
- size_t len;
+ size_t len = strlen(lv->name) + 32;
+ char img_name[len];
struct lv_segment *mapseg;
if (lv->le_count || first_seg(lv)) {
@@ -2141,9 +2141,6 @@
/*
* Next, create all of our sub_lv's and link them in.
*/
- len = strlen(lv->name) + 32;
- if (!(img_name = dm_pool_alloc(lv->vg->cmd->mem, len)))
- return_0;
if (dm_snprintf(img_name, len, "%s%s", lv->name, "_mimage_%d") < 0)
return_0;
@@ -2157,7 +2154,6 @@
}
dm_list_add(&lv->segments, &mapseg->list);
- dm_pool_free(lv->vg->cmd->mem, img_name);
return 1;
}
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_uart: check the return value of recv()
From: Gustavo F. Padovan @ 2011-04-07 21:48 UTC (permalink / raw)
To: Jiejing Zhang; +Cc: Marcel Holtmann, linux-bluetooth, Jiejing Zhang
In-Reply-To: <1302179826-15745-1-git-send-email-kzjeef@gmail.com>
Hi Jiejing,
* Jiejing Zhang <kzjeef@gmail.com> [2011-04-07 20:37:06 +0800]:
> Check the return value of hu->proto->recv() in hci_uart_tty_receive()
> the recv() may return error, check it, not add this to statistics.
>
> Signed-off-by: Jiejing Zhang <jiejing.zhang@freescale.com>
> ---
> drivers/bluetooth/hci_ath.c | 6 +++++-
> drivers/bluetooth/hci_ldisc.c | 6 ++++--
> 2 files changed, 9 insertions(+), 3 deletions(-)
Patch has been applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Endless loop with "detected XactErr"
From: Zdenek Kabelac @ 2011-04-07 21:48 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Alan Stern
Hi
I've been trying to track some resume error with Intel GPU - and
notice a couple problems related to resume of my Lenovo T61.
Laptop has been docked - and suspend/resume has been performed without
'undocking' laptop.
After several iterations of suspend/resume - I've got this endless
printing loop with this line on console display:
ehci_hcd 0000:00:1a.7: detected XactErr len 0/4 retry 1
Just with changing last number - I've got only one such line on serial console.
By looking into "drivers/usb/host/ehci-q.c" - there seems to be
endless goto loop.
>From the log it looks like my USB mouse connected to docking station
was the source of problem.
(Maybe a movement ??)
Here is the trace from last resume:
[ 0.000000] Linux version 2.6.39-rc2-00005-gf04d4dc (kabi@linux)
(gcc version 4.6.0 20110331 (Red Hat 4.6.0-2) (GCC) ) #119 SMP PREEMPT
Wed Apr 6 15:27:55 CEST 2011
[ 0.000000] Command line: ro root=/dev/sda2 selinux=0 kmemleak=off
lockdep.prove_locking=0 lockdep.lock_stat=0 SYSFONT=latarcyrheb-sun16
LANG=cs_CZ.UTF-8 KEYTABLE=us systemd.log_level=info
systemd.log_target=kmsg systemd.sysv_console=true
console=ttyS0,115200n8 console=tty drm.debug=0xe
...
[ 3.605707] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 3.612698] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 3.620138] usb usb2: Product: EHCI Host Controller
[ 3.625187] usb usb2: Manufacturer: Linux 2.6.39-rc2-00005-gf04d4dc ehci_hcd
[ 3.632406] usb usb2: SerialNumber: 0000:00:1a.7
...
[ 7.017440] input: Logitech Optical USB Mouse as
/devices/pci0000:00/0000:00:1a.7/usb2/2-4/2-4.4/2-4.4:1.0/input/input5
[ 7.017666] generic-usb 0003:046D:C016.0001: input: USB HID v1.10
Mouse [Logitech Optical USB Mouse] on usb-0000:00:1a.7-4.4/input0
...
[ 466.138551] PM: resume of devices complete after 3797.616 msecs
[ 467.809750] PM: Finishing wakeup.
[ 467.813162] Restarting tasks ...
[ 467.816673] hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ 467.822422] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 467.827956] hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 467.833510] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 467.839041] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 467.844571] hub 1-0:1.0: state 7 ports 2 chg 0004 evt 0004
[ 467.850164] hub 1-0:1.0: port 2, status 0103, change 0000, 12 Mb/s
[ 467.852203] done.
[ 467.858332] hub 2-0:1.0: state 7 ports 4 chg 0010 evt 0000
[ 467.862691] video LNXVIDEO:00: Restoring backlight state
[ 467.869497] [drm:intel_panel_get_max_backlight], max backlight PWM = 12056655
[ 467.869500] [drm:intel_panel_set_backlight], set backlight PWM = 12056655
[ 467.869504] [drm:intel_panel_get_max_backlight], max backlight PWM = 12056655
[ 467.869511] [drm:intel_opregion_asle_intr], non asle set request??
[ 467.869515] [drm:intel_opregion_asle_intr], non asle set request??
[ 467.869572] hub 2-0:1.0: port 4, status 0501, change 0000, 480 Mb/s
[ 467.920355] ehci_hcd 0000:00:1a.7: port 4 high speed
[ 467.923301] ehci_hcd 0000:00:1a.7: GetStatus port:4 status 001005 0
ACK POWER sig=se0 PE CONNECT
[ 467.975320] [drm:drm_crtc_helper_set_config],
[ 467.975323] [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:9]
#connectors=1 (x y) (0 0)
[ 467.975338] [drm:drm_crtc_helper_set_config], [CONNECTOR:5:LVDS-1]
to [CRTC:4]
[ 468.005138] usb 2-4: new high speed USB device number 12 using ehci_hcd
[ 468.067008] ehci_hcd 0000:00:1a.7: port 4 high speed
[ 468.069960] ehci_hcd 0000:00:1a.7: GetStatus port:4 status 001005 0
ACK POWER sig=se0 PE CONNECT
[ 468.154142] usb 2-4: udev 12, busnum 2, minor = 139
[ 468.161303] usb 2-4: New USB device found, idVendor=04b3, idProduct=4485
[ 468.170269] usb 2-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 468.179654] usb 2-4: usb_probe_device
[ 468.185068] usb 2-4: configuration #1 chosen from 1 choice
[ 468.193537] usb 2-4: adding 2-4:1.0 (config #1, interface 0)
[ 468.201128] hub 2-4:1.0: usb_probe_interface
[ 468.207421] hub 2-4:1.0: usb_probe_interface - got id
[ 468.214292] hub 2-4:1.0: USB hub found
[ 468.220402] hub 2-4:1.0: 4 ports detected
[ 468.228538] hub 2-4:1.0: standalone hub
[ 468.234184] hub 2-4:1.0: individual port power switching
[ 468.241381] hub 2-4:1.0: individual port over-current protection
[ 468.249652] hub 2-4:1.0: TT per port
[ 468.254985] hub 2-4:1.0: TT requires at most 8 FS bit times (666 ns)
[ 468.263575] hub 2-4:1.0: power on to power good time: 100ms
[ 468.271550] hub 2-4:1.0: local power source is good
[ 468.278823] hub 2-4:1.0: enabling power on all ports
[ 468.289997] drivers/usb/core/inode.c: creating file '012'
[ 468.387705] hub 2-4:1.0: port 4: status 0301 change 0001
[ 468.496728] usb 2-4: link qh256-0001/ffff880120b9ac00 start 9 [1/0 us]
[ 468.507602] hub 2-4:1.0: state 7 ports 4 chg 0010 evt 0000
[ 468.517597] hub 2-4:1.0: port 4, status 0301, change 0000, 1.5 Mb/s
[ 468.537004] hub 2-4:1.0: port 4 not reset yet, waiting 10ms
[ 468.610244] usb 2-4.4: new low speed USB device number 13 using ehci_hcd
[ 468.630223] hub 2-4:1.0: port 4 not reset yet, waiting 10ms
[ 468.723696] usb 2-4.4: skipped 1 descriptor after interface
[ 468.734517] usb 2-4.4: default language 0x0409
[ 468.745646] usb 2-4.4: udev 13, busnum 2, minor = 140
[ 468.754995] usb 2-4.4: New USB device found, idVendor=046d, idProduct=c016
[ 468.766392] usb 2-4.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 468.775979] usb 2-4.4: Product: Optical USB Mouse
[ 468.782487] usb 2-4.4: Manufacturer: Logitech
[ 468.789890] usb 2-4.4: usb_probe_device
[ 468.795515] usb 2-4.4: configuration #1 chosen from 1 choice
[ 468.803441] usb 2-4.4: adding 2-4.4:1.0 (config #1, interface 0)
[ 468.811385] usbhid 2-4.4:1.0: usb_probe_interface
[ 468.817759] usbhid 2-4.4:1.0: usb_probe_interface - got id
[ 468.827419] input: Logitech Optical USB Mouse as
/devices/pci0000:00/0000:00:1a.7/usb2/2-4/2-4.4/2-4.4:1.0/input/input14
[ 468.840451] usb 2-4.4: link qh8-0e01/ffff8801177d5900 start 2 [1/2 us]
[ 468.849214] generic-usb 0003:046D:C016.0005: input: USB HID v1.10
Mouse [Logitech Optical USB Mouse] on usb-0000:00:1a.7-4.4/input0
[ 468.863600] drivers/usb/core/inode.c: creating file '013'
[ 470.340197] hub 4-0:1.0: hub_suspend
[ 470.348199] usb usb4: bus auto-suspend
[ 470.356097] ehci_hcd 0000:00:1d.7: suspend root hub
[ 470.365083] hub 3-0:1.0: hub_suspend
[ 470.372770] usb usb3: bus auto-suspend
[ 470.380585] usb usb3: suspend_rh
[ 470.387916] hub 7-0:1.0: hub_suspend
[ 470.395551] usb usb7: bus auto-suspend
[ 470.403356] usb usb7: suspend_rh
[ 470.410592] hub 5-0:1.0: hub_suspend
[ 470.418098] usb usb5: bus auto-suspend
[ 470.425732] usb usb5: suspend_rh
[ 470.432783] hub 6-0:1.0: hub_suspend
[ 470.440145] usb usb6: bus auto-suspend
[ 470.447700] usb usb6: suspend_rh
[ 473.873802] ACPI: \_SB_.GDCK - undocking
[ 473.897678] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0010
[ 473.904809] ehci_hcd 0000:00:1a.7: detected XactErr len 0/4 retry 1
^ permalink raw reply
* Re: halt/reset on assert?
From: Benjamin Herrenschmidt @ 2011-04-07 21:48 UTC (permalink / raw)
To: kevin diggs; +Cc: Andreas Schwab, linuxppc-dev, Evan Lavelle
In-Reply-To: <BANLkTimX==Ei2Sn=86svSajHNX+0G1WM9w@mail.gmail.com>
On Thu, 2011-04-07 at 12:04 -0500, kevin diggs wrote:
> On Thu, Apr 7, 2011 at 2:55 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Wed, 2011-04-06 at 14:01 +0100, Evan Lavelle wrote:
> >> #define MY_ASSERT(expr) if(!(expr)) BUG()
> >
> > Make it
> >
> > #define MY_ASSERT(expr) do { if .... } while(0)
> >
> > To ensure it has proper single statement semantics in C.
> >
> So THAT'S why they do this!!!!!! Now I just have to figure out what
> 'proper single statement semantics' means!
Thing what happens without the do { ... } while(0) if you have code
that looks like:
if (enable_debug)
MY_ASSERT(foo);
else
something_else;
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.