* [U-Boot] [PATCH v6 4/4] usb: add USB support for Efika
From: Stefano Babic @ 2011-10-31 15:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAB+7RbGhb5tGhtxFiaVqEcBu_EJACciwKsbA2X6eo8fYPoevzw@mail.gmail.com>
On 10/31/2011 03:58 PM, Jana Rapava wrote:
>
>
> 2011/10/31 Stefano Babic <sbabic at denx.de <mailto:sbabic@denx.de>>
>
> > There are some issues with: [PATCH 3/4] EHCI: adjust for mx5
> > If you have already applied it
>
> Jana, can you answer / fix this point ?
>
>
> I really don't know what happens there. Code file looks aligned, but
> when I generate a patch with git-format-patch, aligning is messed up.
Wait: this can be due to the different positions of the TAB characters,
and to the leading + to mark an added line. It is not a problem.
> So
> I fix it in git-send-email,
Do you mean you change the patch generated by git format-patch ? You
should not do it.
Take a look at your patch. Some defines are removed, and in the patch
you see them as:
-#ifdef CONFIG_MX25
-#define MX25_USB_CTRL_IP_PUE_DOWN_BIT (1<<6)
-#define MX25_USB_CTRL_HSTD_BIT (1<<5)
-#define MX25_USB_CTRL_USBTE_BIT (1<<4)
-#define MX25_USB_CTRL_OCPOL_OTG_BIT (1<<3)
-#endif
It seems that even in the original file the defines were not aligned.
But this is not true, the disalignment is introduced by the leading "-".
However, when we see some lines later, the defines are added again and
they seem aligned.
+#ifdef CONFIG_MX25
+#define MX25_USB_CTRL_IP_PUE_DOWN_BIT (1<<6)
+#define MX25_USB_CTRL_HSTD_BIT (1<<5)
+#define MX25_USB_CTRL_USBTE_BIT (1<<4)
+#define MX25_USB_CTRL_OCPOL_OTG_BIT (1<<3)
+#endif
But when we apply the patch, they defines are disaligned again. maybe
you are worrying too much: let the tools doing their work. You have to
check that your changed file is correct (without whitespace instead of
tab), and then call git-format-patch. And do not care if the result
seems producing disaligned entries, this is not true.
There are also other comments by Igor that should be fixed,
independently from this alignment problem. Please fix them and resubmit.
> but after sending whitespace characters are
> messed up again.
> I wasn't able to find a way to fix it yet.
As I said, you want to fix the result of git-format-patch, but it is
correct. Simply do not do it.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [PATCH 1/3] Add support for mini-box.com picoSAM9G45 board
From: Nicu Pavel @ 2011-10-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for picoSAM9G45 board from mini-box.com. This board is
based on Atmel G45 SOC. More details can be found at http://arm.mini-box.com
Signed-off-by: Nicu Pavel <npavel@mini-box.com>
---
arch/arm/mach-at91/board-picosam9g45.c | 436 ++++++++++++++++++++++++++++++++
1 files changed, 436 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-at91/board-picosam9g45.c
diff --git a/arch/arm/mach-at91/board-picosam9g45.c b/arch/arm/mach-at91/board-picosam9g45.c
new file mode 100644
index 0000000..84d9dff
--- /dev/null
+++ b/arch/arm/mach-at91/board-picosam9g45.c
@@ -0,0 +1,436 @@
+/*
+ * Board-specific setup code for the picoSAM9G45 board
+ *
+ * http://www.mini-box.com/pico-SAM9G45-X
+ *
+ * Copyright (C) 2011 Nicu Pavel <npavel@mini-box.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/fb.h>
+#include <linux/gpio_keys.h>
+#include <linux/input.h>
+#include <linux/leds.h>
+#include <linux/clk.h>
+#include <linux/atmel-mci.h>
+
+#include <mach/hardware.h>
+#include <video/atmel_lcdc.h>
+
+#include <asm/setup.h>
+#include <asm/mach-types.h>
+#include <asm/irq.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/irq.h>
+
+#include <mach/board.h>
+#include <mach/gpio.h>
+#include <mach/at91sam9_smc.h>
+#include <mach/at91_shdwc.h>
+#include <mach/system_rev.h>
+
+#include "sam9_smc.h"
+#include "generic.h"
+
+
+static void __init picosam9g45_init_early(void)
+{
+ /* Initialize processor: 12.000 MHz crystal */
+ at91_initialize(12000000);
+
+ /* DGBU on ttyS0. (Rx & Tx only) */
+ at91_register_uart(0, 0, 0);
+
+ /* USART1 on ttyS1. (Rx, Tx, RTS, CTS) */
+ at91_register_uart(AT91SAM9G45_ID_US0, 1, ATMEL_UART_CTS | ATMEL_UART_RTS);
+ /* USART1 on ttyS2. (Rx, Tx, RTS, CTS) */
+ at91_register_uart(AT91SAM9G45_ID_US1, 2, ATMEL_UART_CTS | ATMEL_UART_RTS);
+
+ /* set serial console to ttyS0 (ie, DBGU) */
+ at91_set_serial_console(0);
+}
+
+/*
+ * USB HS Host port (common to OHCI & EHCI)
+ */
+static struct at91_usbh_data __initdata picosam9g45_usbh_hs_data = {
+ .ports = 2,
+ .vbus_pin = {AT91_PIN_PD1, AT91_PIN_PD3},
+};
+
+
+/*
+ * USB HS Device port
+ */
+static struct usba_platform_data __initdata picosam9g45_usba_udc_data = {
+ .vbus_pin = AT91_PIN_PB19,
+};
+
+
+/*
+ * SPI devices.
+ */
+static struct spi_board_info picosam9g45_spi_devices[] = {
+ [0] = {/* SPI0 CS0 on right side connector J7*/
+ .modalias= "spidev",
+ .max_speed_hz= 15 * 1000 * 1000,
+ .bus_num= 0,
+ .chip_select= 0,
+ },
+ [1] = {/* SPI1 CS0 on left side connector J9*/
+ .modalias= "spidev",
+ .max_speed_hz= 15 * 1000 * 1000,
+ .bus_num= 1,
+ .chip_select= 0,
+ },
+};
+
+
+/*
+ * MCI (SD/MMC)
+ */
+static struct mci_platform_data __initdata mci0_data = {
+ .slot[0] = {
+ .bus_width = 4,
+ .detect_pin = AT91_PIN_PD10,
+ },
+};
+
+static struct mci_platform_data __initdata mci1_data = {
+ .slot[0] = {
+ .bus_width = 4,
+ .detect_pin = AT91_PIN_PD11,
+ .wp_pin = AT91_PIN_PD29,
+ },
+};
+
+
+/*
+ * MACB Ethernet device
+ */
+static struct at91_eth_data __initdata picosam9g45_macb_data = {
+ .phy_irq_pin = AT91_PIN_PD5,
+ .is_rmii = 1,
+};
+
+
+/*
+ * NAND flash
+ */
+static struct mtd_partition __initdata picosam9g45_nand_partition[] = {
+ {
+ .name = "Bootstrap",
+ .offset = 0,
+ .size = SZ_4M
+ },
+ {
+ .name= "RootFS",
+ .offset= MTDPART_OFS_NXTBLK,
+ .size= 60 * SZ_1M,
+ },
+ {
+ .name= "Space",
+ .offset= MTDPART_OFS_NXTBLK,
+ .size= MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition * __init nand_partitions(int size, int *num_partitions)
+{
+ *num_partitions = ARRAY_SIZE(picosam9g45_nand_partition);
+ return picosam9g45_nand_partition;
+}
+
+/* det_pin is not connected */
+static struct atmel_nand_data __initdata picosam9g45_nand_data = {
+ .ale = 21,
+ .cle = 22,
+ .rdy_pin = AT91_PIN_PC8,
+ .enable_pin = AT91_PIN_PC14,
+ .partition_info = nand_partitions,
+};
+
+static struct sam9_smc_config __initdata picosam9g45_nand_smc_config = {
+ .ncs_read_setup = 0,
+ .nrd_setup = 2,
+ .ncs_write_setup = 0,
+ .nwe_setup = 2,
+
+ .ncs_read_pulse = 4,
+ .nrd_pulse = 4,
+ .ncs_write_pulse = 4,
+ .nwe_pulse = 4,
+
+ .read_cycle = 7,
+ .write_cycle = 7,
+
+ .mode = AT91_SMC_READMODE | AT91_SMC_WRITEMODE | AT91_SMC_EXNWMODE_DISABLE,
+ .tdf_cycles = 3,
+};
+
+static void __init picosam9g45_add_device_nand(void)
+{
+ picosam9g45_nand_data.bus_width_16 = board_have_nand_16bit();
+ /* setup bus-width (8 or 16) */
+ if (picosam9g45_nand_data.bus_width_16)
+ picosam9g45_nand_smc_config.mode |= AT91_SMC_DBW_16;
+ else
+ picosam9g45_nand_smc_config.mode |= AT91_SMC_DBW_8;
+
+ /* configure chip-select 3 (NAND) */
+ sam9_smc_configure(3, &picosam9g45_nand_smc_config);
+
+ at91_add_device_nand(&picosam9g45_nand_data);
+}
+
+
+/*
+ * LCD Controller
+ */
+#if defined(CONFIG_FB_ATMEL) || defined(CONFIG_FB_ATMEL_MODULE)
+static struct fb_videomode at91_tft_vga_modes[] = {
+ {
+ .name = "HannStar",
+ .refresh = 60,
+ .xres = 480, .yres = 272,
+ .pixclock = KHZ2PICOS(9000),
+
+ .left_margin = 2, .right_margin = 2,
+ .upper_margin = 2, .lower_margin = 2,
+ .hsync_len = 41, .vsync_len = 10,
+
+ .sync = 0,
+ .vmode = FB_VMODE_NONINTERLACED,
+ },
+};
+
+static struct fb_monspecs at91fb_default_monspecs = {
+ .manufacturer = "HNS",
+ .monitor = "HSD043I9W1",
+
+ .modedb = at91_tft_vga_modes,
+ .modedb_len = ARRAY_SIZE(at91_tft_vga_modes),
+ .hfmin = 15000,
+ .hfmax = 17640,
+ .vfmin = 57,
+ .vfmax = 67,
+};
+
+#define AT91SAM9G45_DEFAULT_LCDCON2 (ATMEL_LCDC_MEMOR_LITTLE \
+ | ATMEL_LCDC_DISTYPE_TFT \
+ | ATMEL_LCDC_CLKMOD_ALWAYSACTIVE)
+
+/* Driver datas */
+static struct atmel_lcdfb_info __initdata picosam9g45_lcdc_data = {
+ .lcdcon_is_backlight = true,
+ .default_bpp = 16,
+ .default_dmacon = ATMEL_LCDC_DMAEN,
+ .default_lcdcon2 = AT91SAM9G45_DEFAULT_LCDCON2,
+ .default_monspecs = &at91fb_default_monspecs,
+ .guard_time = 9,
+ .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB,
+};
+
+#else
+static struct atmel_lcdfb_info __initdata picosam9g45_lcdc_data;
+#endif
+
+
+/*
+ * Touchscreen
+ */
+static struct at91_tsadcc_data picosam9g45_tsadcc_data = {
+ .adc_clock = 300000,
+ .pendet_debounce = 0x0d,
+ .ts_sample_hold_time = 0x0a,
+};
+
+
+/*
+ * GPIO Buttons
+ */
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
+static struct gpio_keys_button picosam9g45_buttons[] = {
+ { /* J9 pin 5 gnd + pin 11 */
+ .code = KEY_BACK,
+ .gpio = AT91_PIN_PB6,
+ .active_low = 1,
+ .desc = "Back",
+ .wakeup = 1,
+ },
+ { /* J9 pin 5 gnd + pin 13*/
+ .code = KEY_MENU,
+ .gpio = AT91_PIN_PB7,
+ .active_low = 1,
+ .desc = "Menu",
+ .wakeup = 1,
+ },
+ { /* J9 pin 5 gnd + pin 12 */
+ .code = KEY_HOME,
+ .gpio = AT91_PIN_PB16,
+ .active_low = 1,
+ .desc = "Home",
+ },
+
+};
+
+static struct gpio_keys_platform_data picosam9g45_button_data = {
+ .buttons = picosam9g45_buttons,
+ .nbuttons = ARRAY_SIZE(picosam9g45_buttons),
+};
+
+static struct platform_device picosam9g45_button_device = {
+ .name = "gpio-keys",
+ .id = -1,
+ .num_resources = 0,
+ .dev = {
+ .platform_data = &picosam9g45_button_data,
+ }
+};
+
+static void __init picosam9g45_add_device_buttons(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(picosam9g45_buttons); i++) {
+ at91_set_GPIO_periph(picosam9g45_buttons[i].gpio, 1);
+ at91_set_deglitch(picosam9g45_buttons[i].gpio, 1);
+ }
+
+ platform_device_register(&picosam9g45_button_device);
+}
+#else
+static void __init picosam9g45_add_device_buttons(void) {}
+#endif
+
+
+/*
+ * LEDs ... these could all be PWM-driven, for variable brightness
+ */
+static struct gpio_led picosam9g45_leds[] = {
+ { /* "pwr" led */
+ .name = "pwr",
+ .gpio = AT91_PIN_PD30,
+ .default_trigger = "heartbeat",
+ },
+ { /* "u1" led */
+ .name = "u1",
+ .gpio = AT91_PIN_PD0,
+ .active_low = 1,
+ .default_trigger = "mmc0",
+ },
+#if !(defined(CONFIG_LEDS_ATMEL_PWM) || defined(CONFIG_LEDS_ATMEL_PWM_MODULE))
+ { /* "u2" led */
+ .name = "u2",
+ .gpio = AT91_PIN_PD31,
+ .active_low = 1,
+ .default_trigger = "none",
+ },
+#endif
+};
+
+
+/*
+ * PWM Leds
+ */
+static struct gpio_led picosam9g45_pwm_led[] = {
+#if defined(CONFIG_LEDS_ATMEL_PWM) || defined(CONFIG_LEDS_ATMEL_PWM_MODULE)
+ { /* "right" led, green, userled1, pwm1 */
+ .name = "d7",
+ .gpio = 1, /* is PWM channel number */
+ .active_low = 1,
+ .default_trigger = "none",
+ },
+ { /* picopc buzzer */
+ .name= "buzzer",
+ .gpio= 2, /* is PWM channel number */
+ .active_low= 1,
+ .default_trigger= "none",
+ },
+#endif
+};
+
+
+/*
+ * PWM buzzer
+ */
+static void picosam9g45_setup_device_buzzer(void)
+{
+ at91_set_A_periph(AT91_PIN_PE31, 1);
+}
+
+/*
+ * Capacitive touchscreen
+ */
+#define PICOSAM9G45_CAPTS_IRQ AT91_PIN_PA27
+static struct i2c_board_info __initdata picosam9g45_i2c1_devices[] = {
+ {
+ I2C_BOARD_INFO("ms-msg20xx", 0x60),
+ .irq = PICOSAM9G45_CAPTS_IRQ,
+ },
+};
+
+static void picosam9g45_setup_device_capts(void)
+{
+ at91_set_gpio_input(PICOSAM9G45_CAPTS_IRQ, 0);
+ at91_set_deglitch(PICOSAM9G45_CAPTS_IRQ, 1);
+}
+
+
+static void __init picosam9g45_board_init(void)
+{
+ /* Buzzer PWM pin */
+ picosam9g45_setup_device_buzzer();
+ /* Capacitive Touch Screen IRQ */
+ picosam9g45_setup_device_capts();
+ /* Serial */
+ at91_add_device_serial();
+ /* USB HS Host */
+ at91_add_device_usbh_ohci(&picosam9g45_usbh_hs_data);
+ at91_add_device_usbh_ehci(&picosam9g45_usbh_hs_data);
+ /* USB HS Device */
+ at91_add_device_usba(&picosam9g45_usba_udc_data);
+ /* SPI */
+ at91_add_device_spi(picosam9g45_spi_devices, ARRAY_SIZE(picosam9g45_spi_devices));
+ /* MMC */
+ at91_add_device_mci(0, &mci0_data);
+ at91_add_device_mci(1, &mci1_data);
+ /* Ethernet */
+ at91_add_device_eth(&picosam9g45_macb_data);
+ /* NAND */
+ picosam9g45_add_device_nand();
+ /* I2C */
+ at91_add_device_i2c(0, NULL, 0);
+ at91_add_device_i2c(1, picosam9g45_i2c1_devices, ARRAY_SIZE(picosam9g45_i2c1_devices));
+ /* LCD Controller */
+ at91_add_device_lcdc(&picosam9g45_lcdc_data);
+ /* Resistive Touch Screen */
+ at91_add_device_tsadcc(&picosam9g45_tsadcc_data);
+ /* Push Buttons */
+ picosam9g45_add_device_buttons();
+ /* LEDs */
+ at91_gpio_leds(picosam9g45_leds, ARRAY_SIZE(picosam9g45_leds));
+ at91_pwm_leds(picosam9g45_pwm_led, ARRAY_SIZE(picosam9g45_pwm_led));
+}
+
+MACHINE_START(MINIBOXPICOSAM9G45, "Mini Box picoSAM9 G45 Board")
+ /* Maintainer: Nicu Pavel */
+ .timer = &at91sam926x_timer,
+ .map_io = at91_map_io,
+ .init_early = picosam9g45_init_early,
+ .init_irq = at91_init_irq_default,
+ .init_machine = picosam9g45_board_init,
+MACHINE_END
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] Add kernel configuration option for picosam9g45 board
From: Nicu Pavel @ 2011-10-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320074614-19889-1-git-send-email-npavel@mini-box.com>
Signed-off-by: Nicu Pavel <npavel@mini-box.com>
---
arch/arm/mach-at91/Kconfig | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 2248467..419295a 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -400,6 +400,12 @@ if ARCH_AT91SAM9G45
comment "AT91SAM9G45 Board Type"
+config MACH_MINIBOXPICOSAM9G45
+ bool "Mini-Box.com picoSAM9G45 board"
+ help
+ Select this if you are using Mini-Box.com picoSAM9G45 Board
+ <http://arm.mini-box.com>
+
config MACH_AT91SAM9M10G45EK
bool "Atmel AT91SAM9M10G45-EK Evaluation Kits"
help
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] Add picosam9g45 board to Makefile
From: Nicu Pavel @ 2011-10-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320074614-19889-1-git-send-email-npavel@mini-box.com>
Signed-off-by: Nicu Pavel <npavel@mini-box.com>
---
arch/arm/mach-at91/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index bf57e8b..ad1950d 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MACH_GSIA18S) += board-gsia18s.o board-stamp9g20.o
obj-$(CONFIG_MACH_SNAPPER_9260) += board-snapper9260.o
# AT91SAM9G45 board-specific support
+obj-$(CONFIG_MACH_MINIBOXPICOSAM9G45) += board-picosam9g45.o
obj-$(CONFIG_MACH_AT91SAM9M10G45EK) += board-sam9m10g45ek.o
# AT91CAP9 board-specific support
--
1.7.1
^ permalink raw reply related
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Jiri Kosina @ 2011-10-31 15:24 UTC (permalink / raw)
To: Denilson Figueiredo de Sá
Cc: Dmitry Torokhov, Christoph Fritz, linux-kernel, linux-input,
linux-usb
In-Reply-To: <op.v32w1irmdsdv5o@localhost>
On Fri, 28 Oct 2011, Denilson Figueiredo de Sá wrote:
> > On the other hand I feel like just dropping the report on the floor should
> > be the proper thing to do.
>
> I'd say not the entire report, but just the invalid fields.
Right, which is what my patch actually does, just my fingers on keyboard
were faster than my brain while writing that.
> The HID specification (HID1_11.pdf) talks about "Null Values" at the section
> 5.10 (page 20).
>
> [quote]
> HID class devices support the ability to ignore selected fields in a
> report at run- time. This is accomplished by declaring bit field in a
> report that is capable of containing a range of values larger than those
> actually generated by the control. If the host or the device receives an
> out-of-range value then the current value for the respective control
> will not be modified.
> [/quote]
>
> (sidenote: Why didn't I mention this spec earlier? Because I knew I have
> read that information somewhere, but didn't find it again until today.)
I personally find the wording of the spec here a bit unfortunate (the
'declaring bit field in a report that is capable of containing a range of
values largen than those actually generated by the control' seems to be a
bit too foggy and vague).
> > Christoph, how about the (untested at my side yet) patch below? It'd be
> > nice if you could test with the device you are seeing the problem with and
> > let me know.
>
> I can't test it *right now*, but I can probably test it in a week or two.
Thanks. No real rush here, as I will definitely not be queuing this for
3.2 anyway, 3.3 is the first release I'd consider this for.
> > + /* Ignore absolute values that are out of bounds */
> > + if ((usage->type == EV_ABS && (value < field->logical_minimum ||
> > + value > field->logical_maximum))) {
>
> Given what the HID spec says (as I quoted above), I'd change this condition to
> just:
>
> > + if (value < field->logical_minimum ||
> > + value > field->logical_maximum) {
After thinking about it a little bit more, I think I agree.
I will still try to evaluate this against a number of devices I have (or I
have reports for), to see if we potentially really can't break something.
So please let me know the result of your testing.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Jiri Kosina @ 2011-10-31 15:24 UTC (permalink / raw)
To: Denilson Figueiredo de Sá
Cc: Dmitry Torokhov, Christoph Fritz, linux-kernel, linux-input,
linux-usb
In-Reply-To: <op.v32w1irmdsdv5o@localhost>
On Fri, 28 Oct 2011, Denilson Figueiredo de Sá wrote:
> > On the other hand I feel like just dropping the report on the floor should
> > be the proper thing to do.
>
> I'd say not the entire report, but just the invalid fields.
Right, which is what my patch actually does, just my fingers on keyboard
were faster than my brain while writing that.
> The HID specification (HID1_11.pdf) talks about "Null Values" at the section
> 5.10 (page 20).
>
> [quote]
> HID class devices support the ability to ignore selected fields in a
> report at run- time. This is accomplished by declaring bit field in a
> report that is capable of containing a range of values larger than those
> actually generated by the control. If the host or the device receives an
> out-of-range value then the current value for the respective control
> will not be modified.
> [/quote]
>
> (sidenote: Why didn't I mention this spec earlier? Because I knew I have
> read that information somewhere, but didn't find it again until today.)
I personally find the wording of the spec here a bit unfortunate (the
'declaring bit field in a report that is capable of containing a range of
values largen than those actually generated by the control' seems to be a
bit too foggy and vague).
> > Christoph, how about the (untested at my side yet) patch below? It'd be
> > nice if you could test with the device you are seeing the problem with and
> > let me know.
>
> I can't test it *right now*, but I can probably test it in a week or two.
Thanks. No real rush here, as I will definitely not be queuing this for
3.2 anyway, 3.3 is the first release I'd consider this for.
> > + /* Ignore absolute values that are out of bounds */
> > + if ((usage->type == EV_ABS && (value < field->logical_minimum ||
> > + value > field->logical_maximum))) {
>
> Given what the HID spec says (as I quoted above), I'd change this condition to
> just:
>
> > + if (value < field->logical_minimum ||
> > + value > field->logical_maximum) {
After thinking about it a little bit more, I think I agree.
I will still try to evaluate this against a number of devices I have (or I
have reports for), to see if we potentially really can't break something.
So please let me know the result of your testing.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH 1/3] Add support for mini-box.com picoSAM9G45 board
From: Russell King - ARM Linux @ 2011-10-31 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320073010-19549-1-git-send-email-npavel@mini-box.com>
On Mon, Oct 31, 2011 at 04:56:48PM +0200, Nicu Pavel wrote:
> +#include <mach/hardware.h>
> +#include <video/atmel_lcdc.h>
> +
> +#include <asm/setup.h>
> +#include <asm/mach-types.h>
> +#include <asm/irq.h>
> +
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/mach/irq.h>
> +
> +#include <mach/board.h>
> +#include <mach/gpio.h>
Noooooooo. asm/gpio.h please.
^ permalink raw reply
* Re: [lm-sensors] [PATCH 1/3] hwmon: (w83627ehf) Properly report
From: Guenter Roeck @ 2011-10-31 15:24 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20111031151923.7dd990b9@endymion.delvare>
On Mon, 2011-10-31 at 10:19 -0400, Jean Delvare wrote:
> When temperature sources are PECI or AMD-SI agents, it makes no sense
> to report their type as diode or thermistor. Instead we must report
> their digital nature.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: stable@kernel.org
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
> ---
> drivers/hwmon/w83627ehf.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> --- linux-3.2-rc0.orig/drivers/hwmon/w83627ehf.c 2011-10-31 14:21:09.000000000 +0100
> +++ linux-3.2-rc0/drivers/hwmon/w83627ehf.c 2011-10-31 14:24:39.000000000 +0100
> @@ -1812,7 +1812,14 @@ static inline void __devinit w83627ehf_i
> diode = 0x70;
> }
> for (i = 0; i < 3; i++) {
> - if ((tmp & (0x02 << i)))
> + const char *label = data->temp_label[data->temp_src[i]];
> +
> + /* Digital source overrides analog type */
> + if (strncmp(label, "PECI", 4) = 0)
> + data->temp_type[i] = 6;
> + else if (strncmp(label, "AMD", 3) = 0)
> + data->temp_type[i] = 5;
> + else if ((tmp & (0x02 << i)))
> data->temp_type[i] = (diode & (0x10 << i)) ? 1 : 3;
> else
> data->temp_type[i] = 4; /* thermistor */
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [U-Boot] [PATCH] part_efi: fix build warning
From: Anatolij Gustschin @ 2011-10-31 15:26 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320073625-7544-1-git-send-email-leiwen@marvell.com>
Hi,
On Mon, 31 Oct 2011 08:07:05 -0700
Lei Wen <leiwen@marvell.com> wrote:
> part_efi.c: In function 'print_part_efi':
> part_efi.c:133: warning: passing argument 3 of 'is_gpt_valid' from
> incompatible pointer type
> part_efi.c:95: note: expected 'struct gpt_header *' but argument is of
> type 'struct gpt_header **'
> part_efi.c: In function 'get_partition_info_efi':
> part_efi.c:172: warning: passing argument 3 of 'is_gpt_valid' from
> incompatible pointer type
> part_efi.c:95: note: expected 'struct gpt_header *' but argument is of
> type 'struct gpt_header **'
>
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> ---
> disk/part_efi.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
A patch for this bug already exists: [1].
Thanks anyway,
Anatolij
[1] http://patchwork.ozlabs.org/patch/122485/
^ permalink raw reply
* Re: [regression] CD-ROM polling blocks suspend on some machines (Re: [PATCH 1/2] cdrom: always check_disk_change() on open)
From: Tejun Heo @ 2011-10-31 15:26 UTC (permalink / raw)
To: Matthijs Kooijman, Gaudenz Steinlin, linux-kernel,
Jameson Graef Rollins, Jonathan Nieder, Jens Axboe, Amit Shah,
David Zeuthen, Martin Pitt
In-Reply-To: <20111031092812.GD14392@login.drsnuggles.stderr.nl>
Hello,
On Mon, Oct 31, 2011 at 10:28:12AM +0100, Matthijs Kooijman wrote:
> I'm running this kernel now and the problem seems to have disappeared.
> I've done a dozen or so undocks and suspends, without any problems.
> Also, the "udisks-daemon" process in ps now says "not polling any
> devices" after undocking, where it would continue to say "polling sr0"
> before.
Ah, good to hear.
> I'll continue running this kernel for a while and inform you if the
> problem resurfaces.
>
> Any other tests I should be doing?
Not at the moment, please update after testing some more.
Thank you.
--
tejun
^ permalink raw reply
* [PATCH] udf : fix metadata/mirror address print
From: Namjae Jeon @ 2011-10-31 15:25 UTC (permalink / raw)
To: jack; +Cc: linux-kernel, Namjae Jeon, Ashish Sangwan
I found some bug in Skip-mirror-metadata-FE-loading-when-metadata-FE-is-ok patch
So I try to fix metadata/mirror address print.
Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
---
fs/udf/super.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index b4921ab..dfe043a 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -860,7 +860,7 @@ static int udf_load_metadata_files(struct super_block *sb, int partition)
/* metadata address */
udf_debug("Metadata file location: block = %d part = %d\n",
- addr.logicalBlockNum, addr.partitionReferenceNum);
+ mdata->s_meta_file_loc, map->s_partition_num);
mdata->s_metadata_fe = udf_find_metadata_inode_efe(sb,
mdata->s_meta_file_loc, map->s_partition_num);
@@ -868,7 +868,7 @@ static int udf_load_metadata_files(struct super_block *sb, int partition)
if (mdata->s_metadata_fe == NULL) {
/* mirror file entry */
udf_debug("Mirror metadata file location: block = %d part = %d\n",
- addr.logicalBlockNum, addr.partitionReferenceNum);
+ mdata->s_mirror_file_loc, map->s_partition_num);
mdata->s_mirror_fe = udf_find_metadata_inode_efe(sb,
mdata->s_mirror_file_loc, map->s_partition_num);
--
1.7.4.4
^ permalink raw reply related
* Re: [Qemu-devel] Performance of USB2.0
From: Hans de Goede @ 2011-10-31 15:22 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4EAEA4A0.0@obes.name>
Hi,
On 10/31/2011 02:37 PM, Til Obes wrote:
> Hi.
>
> Am 31.10.2011 13:46, schrieb Hans de Goede:
>> If you're using libvirt to start qemu, then it will also pass
>> -usb to qemu, so you will have both a usb-1 (uhci) and a usb-2
>> (ehci) controller inside your vm, since your hostdev xml code does
>> not specify a bus the hostdev will likely get connected to the first
>> usb bus which is the one attached to the uhci controller, although
>> your lsusb output suggests otherwise (to my surprise).
> >
> > So assuming that I'm reading your lsusb output correct, the device
> > does seem to be connected to the virtual ehci controller rather then
> > to the virtual uhci controller, which more or less rules that out
> > as the cause.
>
>
> The kernel output says:
> router:~# dmesg|grep usb
> [ 0.418314] usbcore: registered new interface driver usbfs
> [ 0.418401] usbcore: registered new interface driver hub
> [ 0.419256] usbcore: registered new device driver usb
> [ 0.488137] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [ 0.488144] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [ 0.488150] usb usb1: Product: EHCI Host Controller
> [ 0.488155] usb usb1: Manufacturer: Linux 2.6.32-5-amd64 ehci_hcd
> [ 0.488160] usb usb1: SerialNumber: 0000:00:07.0
> [ 0.488437] usb usb1: configuration #1 chosen from 1 choice
> [ 1.155604] usb 1-1: new high speed USB device using ehci_hcd and address 2
> [ 1.665760] usb 1-1: New USB device found, idVendor=9710, idProduct=7830
> [ 1.665781] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 1.665784] usb 1-1: Product: USB-MAC Controller
> [ 1.665786] usb 1-1: Manufacturer: Moschip Semiconductor
> [ 1.665787] usb 1-1: SerialNumber: 3b0c00d1
> [ 1.665886] usb 1-1: configuration #1 chosen from 1 choice
> [ 1.877906] usb 1-1: applying rev.C fixup
> [ 1.890249] usb 1-1: applying rev.C fixup
> [ 1.905011] eth2: register 'MOSCHIP usb-ethernet driver' at usb-0000:00:07.0-1, MOSCHIP 7830/7730 usb-NET adapter, 00:13:3b:0c:00:d1
> [ 1.905028] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
>
> So it should work with my configuration...
>
Agreed.
>> This means that the likely cause is just that usb emulation / pass
>> through causes quite a bit of overhead, which is not unexpected since
>> both the usb protocol and the ehci controller interface are both quite
>> hard to emulate.
>
> But 6Mbit from 480MBit is quite low, at least 100MBit should be realistic or?
That depends on how the protocol between the NIC and the usb host works, it likely
is using bulk transfers, and likely only 1 at a time, which means that latency
becomes an important issue, and usb redirection of bulk transfers causes quite
a bit of latency.
>
>> It is likely better to just use the usb nic directly from the host,
>> and then pass it through the virtio-net using bridging.
>
> Well the cable modem is only talking to the first mac address it gets.
> In my setup eth1 is the bridged nic to the cable box and it isnt
> working. Any suggestions how to solve this?
If the cable box wants to use the usb-nic, then why not let the host
drive the usb-host and bridge the usb-nic rather then eth1 to the virtual machine?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 2/2] cdma-connman: Add cdma-netreg status watch to activate data call
From: Guillaume Zajac @ 2011-10-31 15:27 UTC (permalink / raw)
To: ofono
In-Reply-To: <4EACF9CC.9010101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]
Hi Denis,
On 30/10/2011 08:16, Denis Kenzior wrote:
> Hi Guillaume,
>
> On 10/20/2011 10:41 AM, Guillaume Zajac wrote:
>> ---
>> src/cdma-connman.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 72 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/cdma-connman.c b/src/cdma-connman.c
>> index db8f6c5..edd71b5 100644
>> --- a/src/cdma-connman.c
>> +++ b/src/cdma-connman.c
>> @@ -52,6 +52,11 @@ struct cdma_connman_settings {
>> struct ofono_cdma_connman {
>> ofono_bool_t powered;
>> ofono_bool_t dormant;
>> + ofono_bool_t attached;
>> + int cdma_netreg_status;
>> + struct ofono_cdma_netreg *cdma_netreg;
>> + unsigned int cdma_netreg_watch;
>> + unsigned int cdma_status_watch;
>> struct cdma_connman_settings *settings;
>> DBusMessage *pending;
>> const struct ofono_cdma_connman_driver *driver;
>> @@ -465,7 +470,9 @@ static DBusMessage *cdma_connman_set_property(DBusConnection *conn,
>>
>> cm->pending = dbus_message_ref(msg);
>>
>> - /* TODO: add logic to support CDMA Network Registration */
>> + if (value&& !cm->attached)
>> + return __ofono_error_not_attached(msg);
>> +
> There is no concept of attachment in CDMA, so I'd prefer we not do it
> this way. Can't we simply check the current netreg atom status here?
Fine for me. Then we should also create a new D-Bus error message like:
__ofono_error_not_registered().
>> if (value)
>> cm->driver->activate(cm, cm->username, cm->password,
>> activate_callback, cm);
>> @@ -531,9 +538,23 @@ static void cdma_connman_unregister(struct ofono_atom *atom)
>> DBusConnection *conn = ofono_dbus_get_connection();
>> struct ofono_modem *modem = __ofono_atom_get_modem(atom);
>> const char *path = __ofono_atom_get_path(atom);
>> + struct ofono_cdma_connman *cm = __ofono_atom_get_data(atom);
>>
>> DBG("");
>>
>> + if (cm->cdma_netreg_watch) {
>> + if (cm->cdma_status_watch) {
>> + __ofono_cdma_netreg_remove_status_watch(
>> + cm->cdma_netreg,
>> + cm->cdma_status_watch);
>> + cm->cdma_status_watch = 0;
>> + }
>> +
>> + __ofono_modem_remove_atom_watch(modem, cm->cdma_netreg_watch);
>> + cm->cdma_netreg_watch = 0;
>> + cm->cdma_netreg = NULL;
>> + }
>> +
>> g_dbus_unregister_interface(conn, path,
>> OFONO_CDMA_CONNECTION_MANAGER_INTERFACE);
>> ofono_modem_remove_interface(modem,
>> @@ -593,6 +614,53 @@ struct ofono_cdma_connman *ofono_cdma_connman_create(
>> return cm;
>> }
>>
>> +static void cdma_connman_netreg_update(struct ofono_cdma_connman *cm)
>> +{
>> + ofono_bool_t attach;
>> +
>> + attach = cm->cdma_netreg_status ==
>> + NETWORK_REGISTRATION_STATUS_REGISTERED;
>> +
>> + /* TODO: Manager roaming case */
>> +
>> + cm->attached = attach;
>> +}
>> +
>> +static void cdma_netreg_status_changed(int status, void *data)
>> +{
>> + struct ofono_cdma_connman *cm = data;
>> +
>> + DBG("%d", status);
>> +
>> + if (cm->cdma_netreg_status == status)
>> + return;
>> +
>> + cm->cdma_netreg_status = status;
>> +
>> + cdma_connman_netreg_update(cm);
>> +}
>> +
>> +static void cdma_netreg_watch(struct ofono_atom *atom,
>> + enum ofono_atom_watch_condition cond,
>> + void *data)
>> +{
>> + struct ofono_cdma_connman *cm = data;
>> +
>> + if (cond == OFONO_ATOM_WATCH_CONDITION_UNREGISTERED) {
>> + cm->cdma_netreg_status =
>> + NETWORK_REGISTRATION_STATUS_NOT_REGISTERED;
>> + return;
>> + }
>> +
>> + cm->cdma_netreg = __ofono_atom_get_data(atom);
>> + cm->cdma_netreg_status = ofono_cdma_netreg_get_status(cm->cdma_netreg);
>> + cm->cdma_status_watch =
>> + __ofono_cdma_netreg_add_status_watch(cm->cdma_netreg,
>> + cdma_netreg_status_changed, cm, NULL);
>> +
>> + cdma_connman_netreg_update(cm);
>> +}
>> +
>> void ofono_cdma_connman_register(struct ofono_cdma_connman *cm)
>> {
>> DBusConnection *conn = ofono_dbus_get_connection();
>> @@ -613,7 +681,9 @@ void ofono_cdma_connman_register(struct ofono_cdma_connman *cm)
>> ofono_modem_add_interface(modem,
>> OFONO_CDMA_CONNECTION_MANAGER_INTERFACE);
>>
>> - /* TODO: add watch to support CDMA Network Registration atom */
>> + cm->cdma_netreg_watch = __ofono_modem_add_atom_watch(modem,
>> + OFONO_ATOM_TYPE_CDMA_NETREG,
>> + cdma_netreg_watch, cm, NULL);
>>
>> __ofono_atom_register(cm->atom, cdma_connman_unregister);
>> }
> It seems to me that this is way too complicated. All you want is to
> check the netreg status before trying to set powered. If we lose netreg
> when the connection is active, then the regular cdma-connman
> notification procedures would apply.
Once we lost netreg, what are we supposed to do?
cdma-netreg atom will signal "Status" property has changed.
Is that up to ConnMan to deactivate the data call in checking the
cdma-netreg "Status" property equal to "unregistered"?
Kind regards,
Guillaume
^ permalink raw reply
* Re: [PATCH -v2 07/16] PCI: TILE: convert pcibios_set_master() to a non-inlined function
From: Chris Metcalf @ 2011-10-31 15:27 UTC (permalink / raw)
To: Myron Stowe
Cc: jbarnes, linux-pci, linux, vapier, dhowells, ysato, tony.luck,
fenghua.yu, monstr, ralf, benh, paulus, lethal, davem, gxt, tglx,
mingo, chris, linux-kernel
In-Reply-To: <20111028214817.20088.15009.stgit@amt.stowe>
On 10/28/2011 5:48 PM, Myron Stowe wrote:
> From: Myron Stowe <mstowe@redhat.com>
>
> This patch converts TILE's architecture-specific 'pcibios_set_master()'
> routine to a non-inlined function. This will allow follow on patches
> to create a generic 'pcibios_set_master()' function using the '__weak'
> attribute which can be used by all architectures as a default which,
> if necessary, can then be over-ridden by architecture-specific code.
>
> Converting 'pci_bios_set_master()' to a non-inlined function will
> allow TILE's 'pcibios_set_master()' implementation to remain
> architecture-specific after the generic version is introduced and
> thus, not change current behavior.
>
> No functional change.
>
> Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH 1/3] ext4: Use correct locking for ext4_end_io_nolock()
From: Tao Ma @ 2011-10-31 15:28 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Ext4 Developers List, Tao Ma
In-Reply-To: <1320073367-28916-1-git-send-email-tytso@mit.edu>
On 10/31/2011 11:02 PM, Theodore Ts'o wrote:
> From: Tao Ma <boyu.mt@taobao.com>
>
> We must hold i_completed_io_lock when manipulating anything on the
> i_completed_io_list linked list. This includes io->lock, which we
> were checking in ext4_end_io_nolock().
>
> So move this check to ext4_end_io_work(). This also has the bonus of
> avoiding extra work if it is already done without needing to take the
> mutex.
>
> Signed-off-by: Tao Ma <boyu.mt@taobao.com>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
I am fine with it.
Thanks
Tao
> ---
> fs/ext4/fsync.c | 3 ---
> fs/ext4/page-io.c | 14 +++++++++++---
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c
> index c942924..851ac5b 100644
> --- a/fs/ext4/fsync.c
> +++ b/fs/ext4/fsync.c
> @@ -83,9 +83,6 @@ int ext4_flush_completed_IO(struct inode *inode)
> int ret = 0;
> int ret2 = 0;
>
> - if (list_empty(&ei->i_completed_io_list))
> - return ret;
> -
> dump_completed_IO(inode);
> spin_lock_irqsave(&ei->i_completed_io_lock, flags);
> while (!list_empty(&ei->i_completed_io_list)){
> diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
> index 92f38ee..aed4096 100644
> --- a/fs/ext4/page-io.c
> +++ b/fs/ext4/page-io.c
> @@ -87,6 +87,9 @@ void ext4_free_io_end(ext4_io_end_t *io)
>
> /*
> * check a range of space and convert unwritten extents to written.
> + *
> + * Called with inode->i_mutex; we depend on this when we manipulate
> + * io->flag, since we could otherwise race with ext4_flush_completed_IO()
> */
> int ext4_end_io_nolock(ext4_io_end_t *io)
> {
> @@ -100,9 +103,6 @@ int ext4_end_io_nolock(ext4_io_end_t *io)
> "list->prev 0x%p\n",
> io, inode->i_ino, io->list.next, io->list.prev);
>
> - if (list_empty(&io->list))
> - return ret;
> -
> if (!(io->flag & EXT4_IO_END_UNWRITTEN))
> return ret;
>
> @@ -142,6 +142,13 @@ static void ext4_end_io_work(struct work_struct *work)
> unsigned long flags;
> int ret;
>
> + spin_lock_irqsave(&ei->i_completed_io_lock, flags);
> + if (list_empty(&io->list)) {
> + spin_unlock_irqrestore(&ei->i_completed_io_lock, flags);
> + goto free;
> + }
> + spin_unlock_irqrestore(&ei->i_completed_io_lock, flags);
> +
> if (!mutex_trylock(&inode->i_mutex)) {
> /*
> * Requeue the work instead of waiting so that the work
> @@ -170,6 +177,7 @@ static void ext4_end_io_work(struct work_struct *work)
> list_del_init(&io->list);
> spin_unlock_irqrestore(&ei->i_completed_io_lock, flags);
> mutex_unlock(&inode->i_mutex);
> +free:
> ext4_free_io_end(io);
> }
>
^ permalink raw reply
* [PATCH] vlan: Don't propagate flag changes on down interfaces.
From: Matthijs Kooijman @ 2011-10-31 14:53 UTC (permalink / raw)
To: netdev; +Cc: Matthijs Kooijman
In-Reply-To: <20111031134411.GG14392@login.drsnuggles.stderr.nl>
When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
flags are cleared or set on the underlying interface. So, if these flags
are changed on a vlan interface that is not up, the flags underlying
interface might be set or cleared twice.
Only propagating flag changes when a device is up makes sure this does
not happen. It also makes sure that an underlying device is not set to
promiscuous or allmulti mode for a vlan device that is down.
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
---
net/8021q/vlan_dev.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 9d40a07..0e72689 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -470,10 +470,12 @@ static void vlan_dev_change_rx_flags(struct net_device *dev, int change)
{
struct net_device *real_dev = vlan_dev_info(dev)->real_dev;
- if (change & IFF_ALLMULTI)
- dev_set_allmulti(real_dev, dev->flags & IFF_ALLMULTI ? 1 : -1);
- if (change & IFF_PROMISC)
- dev_set_promiscuity(real_dev, dev->flags & IFF_PROMISC ? 1 : -1);
+ if (dev->flags & IFF_UP) {
+ if (change & IFF_ALLMULTI)
+ dev_set_allmulti(real_dev, dev->flags & IFF_ALLMULTI ? 1 : -1);
+ if (change & IFF_PROMISC)
+ dev_set_promiscuity(real_dev, dev->flags & IFF_PROMISC ? 1 : -1);
+ }
}
static void vlan_dev_set_rx_mode(struct net_device *vlan_dev)
--
1.7.7
^ permalink raw reply related
* [U-Boot] [PATCH 0/2] add Timll DevKit3250 board initial support
From: Vladimir Zapolskiy @ 2011-10-31 15:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319560064-10018-1-git-send-email-vz@mleia.com>
Hello Albert and Wolfgang,
On 25.10.2011 19:27, Vladimir Zapolskiy wrote:
> This patchset adds generic NXP LPC32XX SoC support and basic support
> for Embest/Timll DevKit3250 board, which powered by this SoC.
>
> Vladimir Zapolskiy (2):
> arm926ejs: add NXP LPC32x0 cpu series support
> devkit3250: add Timll DevKit3250 board initial support
>
> arch/arm/cpu/arm926ejs/lpc32xx/Makefile | 45 +++++++
> arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c | 118 ++++++++++++++++++
> arch/arm/cpu/arm926ejs/lpc32xx/cpu.c | 58 +++++++++
> arch/arm/cpu/arm926ejs/lpc32xx/devices.c | 47 +++++++
> arch/arm/cpu/arm926ejs/lpc32xx/timer.c | 94 +++++++++++++++
> arch/arm/include/asm/arch-lpc32xx/clk.h | 159 +++++++++++++++++++++++++
> arch/arm/include/asm/arch-lpc32xx/config.h | 59 +++++++++
> arch/arm/include/asm/arch-lpc32xx/cpu.h | 64 ++++++++++
> arch/arm/include/asm/arch-lpc32xx/emc.h | 92 ++++++++++++++
> arch/arm/include/asm/arch-lpc32xx/sys_proto.h | 25 ++++
> arch/arm/include/asm/arch-lpc32xx/timer.h | 74 ++++++++++++
> arch/arm/include/asm/arch-lpc32xx/uart.h | 54 +++++++++
> arch/arm/include/asm/arch-lpc32xx/wdt.h | 51 ++++++++
> board/timll/devkit3250/Makefile | 50 ++++++++
> board/timll/devkit3250/devkit3250.c | 74 ++++++++++++
> boards.cfg | 3 +-
> include/configs/devkit3250.h | 121 +++++++++++++++++++
> 17 files changed, 1187 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/Makefile
> create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/clkpwr.c
> create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/cpu.c
> create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/devices.c
> create mode 100644 arch/arm/cpu/arm926ejs/lpc32xx/timer.c
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/clk.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/config.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/cpu.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/emc.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/sys_proto.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/timer.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/uart.h
> create mode 100644 arch/arm/include/asm/arch-lpc32xx/wdt.h
> create mode 100644 board/timll/devkit3250/Makefile
> create mode 100644 board/timll/devkit3250/devkit3250.c
> create mode 100644 include/configs/devkit3250.h
>
still there is no comment on this patchset, however I wonder, if I could
accomplish any other your request to accelerate inclusion of the changes
to u-boot-arm/next.
Thank you in advance.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [Qemu-devel] Patch for ui/cocoa.m
From: Juan Pineda @ 2011-10-31 15:32 UTC (permalink / raw)
To: Andreas Färber; +Cc: aliguori, qemu-devel
In-Reply-To: <4EADD380.1020100@web.de>
Hi Andreas,
Thanks for your reply. You can verify that my cocoa.m patch works 100% under 0.15.1. That's where I was testing it. The fix is completely independent of the other problems in the OSX build (uint16, GThread, etc.) that have cropped up since 0.15.1, so there should be no problem merging it.
I will us GDB on that GThread error to find the source code line where it failed and post what I find.
Thanks!
-Juan
On Oct 30, 2011, at 3:45 PM, Andreas Färber wrote:
> Am 18.10.2011 16:35, schrieb Juan Pineda:
>>>> What command line do you use? If using the right arguments you
>>>> shouldn't see a window at all. Are you maybe using -drive instead of
>>>> -hda and that is not yet handled correctly?
>>
>> The boot volume dialog appears only when a hard disk file is not supplied on the command line. I would think the failure of the dialog to close is not unique to Lion. However in prior OS releases it probably does not present a problem as the main window can be raised above the dialog.
>
> If that were the case I would see it as worth fixing there, too. :)
>
>>>> Apart from this issue, is it working correctly for you?
>
>> However building the main branch (with flags as above) does not work. The build fails with error about redefinition of uint16 in fpu/softfloat.h. If that is fixed the build completes. But trying to run qemu-system-i386 quits:
>>
>>> $ i386-softmmu/qemu-system-i386 -hda ~/Downloads/linux-0.2.img
>>>
>>> GThread-ERROR **: GThread system may only be initialized once.
>>> aborting...
>>> Abort trap: 6
>
> That's what I'm seeing, too, so I don't feel comfortable committing this
> patch now. It compiles file, but it crashes either way with a message
> similar to the above, so I don't see an improvement (yet).
>
> If you could pinpoint where this error stems from (e.g., single-stepping
> in gdb) that might help getting it fixed.
>
> Thanks,
> Andreas
^ permalink raw reply
* Re: [PATCH] oom: fix integer overflow of points in oom_badness
From: Oleg Nesterov @ 2011-10-31 15:28 UTC (permalink / raw)
To: Frantisek Hrbata
Cc: rientjes, linux-mm, linux-kernel, akpm, kosaki.motohiro,
minchan.kim, stable, eteo, pmatouse
In-Reply-To: <1320048865-13175-1-git-send-email-fhrbata@redhat.com>
On 10/31, Frantisek Hrbata wrote:
>
> My understanding is that we may just change the type of points variable from int
> to long and keep the current imho clearer(better readable) computation. There
> should not be an overflow on 32bit and there is a plenty of space for 64bit.
> If you like this solution better I will post the patch as v2.
Up to maintainer, but personally I think the simple s/int/long/ looks better.
Everything like get_mm_*/nr_ptes returns long.
Anyway good catch. Imho stable needs the fix too.
Cosmetic nit,
> - points = get_mm_rss(p->mm) + p->mm->nr_ptes;
> - points += get_mm_counter(p->mm, MM_SWAPENTS);
> + points = (int)((get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +
^^^^^
Why do we need the explicit typecast? It buys nothing and looks a bit confusing.
And, if you prefer "int", perhaps something like
- points *= 1000;
- points /= totalpages;
+ /* avoid the possible overflow */
+ points = points * 1000L / totalpages;
looks a bit more readable with the same effect. But I won't insist, this is
up to you and David.
Oleg.
--
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: [PATCH] oom: fix integer overflow of points in oom_badness
From: Oleg Nesterov @ 2011-10-31 15:28 UTC (permalink / raw)
To: Frantisek Hrbata
Cc: rientjes, linux-mm, linux-kernel, akpm, kosaki.motohiro,
minchan.kim, stable, eteo, pmatouse
In-Reply-To: <1320048865-13175-1-git-send-email-fhrbata@redhat.com>
On 10/31, Frantisek Hrbata wrote:
>
> My understanding is that we may just change the type of points variable from int
> to long and keep the current imho clearer(better readable) computation. There
> should not be an overflow on 32bit and there is a plenty of space for 64bit.
> If you like this solution better I will post the patch as v2.
Up to maintainer, but personally I think the simple s/int/long/ looks better.
Everything like get_mm_*/nr_ptes returns long.
Anyway good catch. Imho stable needs the fix too.
Cosmetic nit,
> - points = get_mm_rss(p->mm) + p->mm->nr_ptes;
> - points += get_mm_counter(p->mm, MM_SWAPENTS);
> + points = (int)((get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +
^^^^^
Why do we need the explicit typecast? It buys nothing and looks a bit confusing.
And, if you prefer "int", perhaps something like
- points *= 1000;
- points /= totalpages;
+ /* avoid the possible overflow */
+ points = points * 1000L / totalpages;
looks a bit more readable with the same effect. But I won't insist, this is
up to you and David.
Oleg.
^ permalink raw reply
* Re: Nand support for i.MX233
From: Robert Schwebel @ 2011-10-31 15:33 UTC (permalink / raw)
To: David.Kiland; +Cc: barebox
In-Reply-To: <OF23737A70.6C166A59-ONC125793A.00534C62-C125793A.0053E739@vsmgroup.com>
On Mon, Oct 31, 2011 at 04:16:25PM +0100, David.Kiland@europe.svpworldwide.com wrote:
> Is there anyone out there working on NAND support for the freescale i.MX233
> processor?
In general, yes (for MX23 and MX28). We are collecting customers to
sponsor those activities. If you are interested, please drop me a note
(offlist).
Best regards,
Robert
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] dma: Avoid reentrancy in DMA transfer handlers
From: Paolo Bonzini @ 2011-10-31 15:34 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4EAEB4A9.2000203@redhat.com>
On 10/31/2011 03:46 PM, Kevin Wolf wrote:
> > Hmm, I think you should set rearm = 1 to ensure the BH is run when
> > ultimately you leave the sync read. Sorry for not spotting this before.
>
> I was about to agree, but in fact adding a rearm = 1; line leads to
> crashes, whereas in the version I posted it just works. So it looks like
> something is wrong with doing it, even though it seemed to make perfect
> sense at the first sight.
But what will restart the DMA at the end of the synchronous I/O, then?
Paolo
^ permalink raw reply
* Re: [lm-sensors] [PATCH 2/3] hwmon: (w83627ehf) Clean up probe
From: Jean Delvare @ 2011-10-31 15:36 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20111031152004.28e9f7b8@endymion.delvare>
On Mon, 31 Oct 2011 08:22:59 -0700, Guenter Roeck wrote:
> On Mon, 2011-10-31 at 10:20 -0400, Jean Delvare wrote:
> > The probe function has grown pretty large, I think it's time for some
> > cleanups, starting with these two simple ones:
> > * Move temp3/in6 check for the W83667HG later in the function, where
> > it is done for all other chip types.
> > * Move temperature register setting to a separate function, to avoid
> > code duplication.
> >
> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
>
> Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
>
> Do you want to take this series, or should I take it ?
I'll take it, my setup to push things to Linus is operational again.
> > ---
> > Guenter, had you considered adding support for the NCT6775 and NCT6776
> > to a separate driver? The code starts being seriously bloated :(
> >
> No thoughts so far. Might be an option, but I am not sure if/when I
> would have time to work on it. And I would have to get a board with
> NCT6776 on it. If there are any with SandyBridge CPU, I might actually
> get one ;).
Would be great.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
From: Valdis.Kletnieks @ 2011-10-31 15:37 UTC (permalink / raw)
To: t-kristo
Cc: Munegowda, Keshava, Paul Walmsley, Cousson, Benoit, Basak, Partha,
Balbi, Felipe, parthab, linux-usb, linux-omap, linux-kernel,
Gadiyar, Anand, sameo, tony, Hilman, Kevin, johnstul,
Sripathy, Vishwanath
In-Reply-To: <1319803416.12919.2.camel@sokoban>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Fri, 28 Oct 2011 15:03:36 +0300, Tero Kristo said:
> Hi Again,
> I created a new version of the patch which should be better than this
> hack, I'll send it as an RFC to the l-o list in a bit.
> On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote:
> > On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo <t-kristo@ti.com> wrote:
> > > On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote:
> > >> On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava
> > >> <keshava_mgowda@ti.com> wrote:
> > >> > On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo <t-kristo@ti.com> wrote:
> > >> >> On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:
> > >> >> Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki
> > > Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki
> Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki
Moral: Just leave current street addresses out of it. :)
And can we *please* trim irrelevant stuff? You top-posted a 2 line reply,
followed by the entire note, which a bunch of kernel developers got to scroll
through and wonder if they missed an in-line comment. *Especially* after the
top part had one line that it wasn't clear if it was a top-posted sig line gone
wrong, or 3 attempts to get an address right for inclusion in a patch.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* RE: [GIT PULL] mm: frontswap (for 3.2 window)
From: Dan Magenheimer @ 2011-10-31 15:39 UTC (permalink / raw)
To: James Bottomley
Cc: John Stoffel, Johannes Weiner, Pekka Enberg, Cyclonus J,
Sasha Levin, Christoph Hellwig, David Rientjes, Linus Torvalds,
linux-mm, LKML, Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge,
Seth Jennings, ngupta, Chris Mason, JBeulich, Dave Hansen,
Jonathan Corbet
In-Reply-To: <1320048767.8283.13.camel@dabdike>
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Subject: RE: [GIT PULL] mm: frontswap (for 3.2 window)
Hi James --
Thanks for the reply. You raise some good points but
I hope you will read what I believe are reasonable though
long-winded answers.
> On Fri, 2011-10-28 at 13:19 -0700, Dan Magenheimer wrote:
> > For those who "hack on the VM", I can't imagine why the handful
> > of lines in the swap subsystem, which is probably the most stable
> > and barely touched subsystem in Linux or any OS on the planet,
> > is going to be a burden or much of a cost.
>
> Saying things like this doesn't encourage anyone to trust you. The
> whole of the MM is a complex, highly interacting system. The recent
> issues we've had with kswapd and the shrinker code gives a nice
> demonstration of this ... and that was caused by well tested code
> updates.
I do understand that. My point was that the hooks are
placed _statically_ in largely stable code so it's not
going to constantly get in the way of VM developers
adding new features and fixing bugs, particularly
any developers that don't care about whether frontswap
works or not. I do think that is a very relevant
point about maintenance... do you disagree?
Runtime interactions can only occur if the code is
config'ed and, if config'ed, only if a tmem backend (e.g.
Xen or zcache) enables it also at runtime. When
both are enabled, runtime interactions do occur
and absolutely must be fully tested. My point was
that any _users_ who don't care about whether frontswap
works or not don't need to have any concerns about
VM system runtime interactions. I think this is also
a very relevant point about maintenance... do you
disagree?
> You can't hand wave away the need for benchmarks and
> performance tests.
I'm not. Conclusive benchmarks are available for one user
(Xen) but not (yet) for other users. I've already acknowledged
the feedback desiring benchmarking for zcache, but zcache
is already merged (albeit in staging), and Xen tmem
is already merged in both Linux and the Xen hypervisor,
and cleancache (the alter ego of frontswap) is already
merged.
So the question is not whether benchmarks are waived,
but whether one accepts (1) conclusive benchmarks for Xen;
PLUS (2) insufficiently benchmarked zcache; PLUS (3) at
least two other interesting-but-not-yet-benchmarkable users;
as sufficient for adding this small set of hooks into
swap code.
I understand that some kernel developers (mostly from one
company) continue to completely discount Xen, and
thus won't even look at the Xen results. IMHO
that is mudslinging.
> You have also answered all questions about inactive cost by saying "the
> code has zero cost when it's compiled out" This also is a non starter.
> For the few use cases it has, this code has to be compiled in. I
> suspect even Oracle isn't going to ship separate frontswap and
> non-frontswap kernels in its distro. So you have to quantify what the
> performance impact is when this code is compiled in but not used.
> Please do so.
First, no, Oracle is not going to ship separate frontswap and
non-frontswap kernels. It IS going to ship a frontswap-enabled
kernel and this can be seen in Oracle's publicly-available
kernel git tree (the next release, now in Beta). Frontswap is
compiled in, but still must be enabled at runtime (e.g. for
a Xen guest, either manually by the guest's administrator
or automagically by the Oracle VM product's management layer).
I did fully quantify the performance impact elsewhere in
this thread. The performance impact with CONFIG_FRONTSWAP=n
(which is ZERO) is relevant for distros which choose to
ignore it entirely. The performance impact for CONFIG_FRONTSWAP=y
but not-enabled-at-runtume is one compare-pointer-against-NULL
per page actually swapped in or out (essentially ZERO);
this is relevant for distros which choose to configure it
enabled in case they wish to enable it at runtime in
the future.
So the remaining question is the performance impact when
compile-time AND runtime enabled; this is in the published
Xen presentation I've referenced -- the impact is much much
less than the performance gain. IMHO benchmark results can
be easily manipulated so I prefer to discuss the theoretical
underpinnings which, in short, is that just about anything
a tmem backend does (hypercall, compression, deduplication,
even moving data across a fast network) is a helluva lot
faster than swapping a page to disk.
Are there corner cases and probably even real workloads
where the cost exceeds the benefits? Probably... though
less likely for frontswap than for cleancache because ONLY
pages that would actually be swapped out/in use frontswap.
But I have never suggested that every kernel should always
unconditionally compile-time-enable and run-time-enable
frontswap... simply that it should be in-tree so those
who wish to enable it are able to enable it.
Thanks,
Dan
--
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
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.