* [PATCH v2 3/3] Add picosam9g45 board to Makefile
From: Nicu Pavel @ 2011-10-31 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320076396-6233-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
* [PATCH v2 2/3] Add kernel configuration option for picosam9g45 board
From: Nicu Pavel @ 2011-10-31 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320076396-6233-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 v2 1/3] Add support for mini-box.com picoSAM9G45 board
From: Nicu Pavel @ 2011-10-31 15:53 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..bd746a1
--- /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 <asm/gpio.h>
+
+#include <mach/board.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
* Re: [PATCH 5/5] distro_tracking_fields: updates for sudo, mtools, grep, and openssh
From: Saul Wold @ 2011-10-31 15:46 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <201110310908.45138.paul.eggleton@linux.intel.com>
On 10/31/2011 02:08 AM, Paul Eggleton wrote:
> On Wednesday 26 October 2011 21:37:39 Saul Wold wrote:
>>> -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-sudo = "1 month"
>>> -RECIPE_LATEST_RELEASE_DATE_pn-sudo = "2011/05/16"
>>> +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-sudo = "2 months"
>>> +RECIPE_LATEST_RELEASE_DATE_pn-sudo = "2011/10/21"
>>
>> These date formats should be MMM DD, YYYY also, for all the data listed
>> below also.
>
> I'd been meaning to ask this before - is there a good reason for not being
> consistent and using the same format for all date fields in this file?
>
Maybe I am missing your comment, is that what I not suggested in my
comment above? All date formats in the distro_tracking_fields should be
in the MMM DD, YYY format.
Sau!
> Cheers,
> Paul
>
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Stephen Warren @ 2011-10-31 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029084330.GW19187@n2100.arm.linux.org.uk>
Russell King wrote at Saturday, October 29, 2011 2:44 AM:
> On Fri, Oct 28, 2011 at 09:49:49AM -0700, Stephen Warren wrote:
> > When boards boot from DT, there is no fixup function to override the
> > bootloader's ATAGs. I also see a bunch of code to set up the memory
> > information from DT e.g. setup_machine_fdt()'s call to:
> >
> > of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> >
> > ... but I assume that happens before the ATAGs are processed, and the
> > buggy ATAGs end up overriding the information in the DT file.
>
> As far as the uncompressed kernel is concerned, there is either ATAG
> or DT information, never both. If the boot loader provides ATAGs and
> the zImage has a DT appended to it, the zImage decompressor merges the
> ATAGs into the appended DT and passes the DT to the kernel.
>
> So anyone who currently 'fixes' their broken boot loader via the fixup
> function by directly manipulating the ATAGS is going to hit the DT
> image instead.
I believe the PAZ00 fixup function runs on the kernel's internal data-
structures, not the ATAGs directly, so the issue you point out isn't
a problem here:
static void __init tegra_paz00_fixup(struct tag *tags, char **cmdline,
struct meminfo *mi)
{
mi->nr_banks = 1;
mi->bank[0].start = PHYS_OFFSET;
mi->bank[0].size = 448 * SZ_1M;
}
--
nvpublic
^ permalink raw reply
* RE: RE: [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Stephen Warren @ 2011-10-31 15:51 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Marc Dietrich,
Grant Likely (grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org),
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Olof Johansson,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Colin Cross
In-Reply-To: <20111029084330.GW19187-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
Russell King wrote at Saturday, October 29, 2011 2:44 AM:
> On Fri, Oct 28, 2011 at 09:49:49AM -0700, Stephen Warren wrote:
> > When boards boot from DT, there is no fixup function to override the
> > bootloader's ATAGs. I also see a bunch of code to set up the memory
> > information from DT e.g. setup_machine_fdt()'s call to:
> >
> > of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> >
> > ... but I assume that happens before the ATAGs are processed, and the
> > buggy ATAGs end up overriding the information in the DT file.
>
> As far as the uncompressed kernel is concerned, there is either ATAG
> or DT information, never both. If the boot loader provides ATAGs and
> the zImage has a DT appended to it, the zImage decompressor merges the
> ATAGs into the appended DT and passes the DT to the kernel.
>
> So anyone who currently 'fixes' their broken boot loader via the fixup
> function by directly manipulating the ATAGS is going to hit the DT
> image instead.
I believe the PAZ00 fixup function runs on the kernel's internal data-
structures, not the ATAGs directly, so the issue you point out isn't
a problem here:
static void __init tegra_paz00_fixup(struct tag *tags, char **cmdline,
struct meminfo *mi)
{
mi->nr_banks = 1;
mi->bank[0].start = PHYS_OFFSET;
mi->bank[0].size = 448 * SZ_1M;
}
--
nvpublic
^ permalink raw reply
* Re: [PATCH 0/2] ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch]
From: Bjorn Helgaas @ 2011-10-31 15:51 UTC (permalink / raw)
To: Thomas Renninger
Cc: Myron Stowe, Len Brown, bondd, lenb, linux-acpi, rjw, ying.huang
In-Reply-To: <201110311133.31320.trenn@suse.de>
On Mon, Oct 31, 2011 at 4:33 AM, Thomas Renninger <trenn@suse.de> wrote:
> On Friday 28 October 2011 17:14:39 Bjorn Helgaas wrote:
>> On Thu, Oct 27, 2011 at 7:49 PM, Thomas Renninger <trenn@suse.de> wrote:
>> > There is another problem. Would be great to get some opinions/feedback
>> > on it already:
>> > APEI GAR entries seem to have invalid bit_width entries on some platforms.
>> > After looking at several tables, I expect that with APEI tables access width
>> > (in bytes) should get used instead, Windows seem to ignore bit width fields,
>> > at least for APEI tables.
>>
>> I'm confused. How can you tell that the bit_width is incorrect My
>> understanding is that the bit_width is the size of the *register*,
>> while the access_width is the size of access the processor must
>> generate on the bus. The access_width may be larger, for example, if
>> the hardware only supports 32-bit or 64-bit reads.
> This also is my understanding.
>> So I don't understand how you can derive bit_width from access_width.
> The problem is that Windows seem to ignore the bit width field, at least
> for APEI tables.
> There you also have the mask value and bit width information is not
> needed to determine the bits of interest.
> While mostly bit width information is correct, I compared quite some
> tables and especially IBM is adding some interesting values.
> But I've also seen wrong bit widths on Supermicro and others.
>
>
>> In the example below, I think we're supposed to do a 64-bit read, then
>> extract 8 bits that contain the register of interest. If we keep all
>> 64 bits, I don't see how that can be correct.
> Yep. But "Get Error Address Range" is supposed to return/contain an iomem address.
> Cutting it down to 8 bits produces below error when trying to
> reserve a memory region from the retrieved value/address at 0x3f.
> Using acpidump to evaluate the register's 8 byte shows:
> acpidump --addr 0x7F8A8032 --length 8
> 0x000000007f8a803f
> which perfectly fits into an unused e820 reserved memory region.
>
> Same for "Get Error Address Length" on this machine:
> [1D0h 0464 1] Action : 0E (Get Error Address Length)
> [1D5h 0469 1] Bit Width : 08
> [1D7h 0471 1] Encoded Access Width : 03 (DWord Access:32)
> [1D8h 0472 8] Address : 000000007F8A803A
> [1E8h 0488 8] Mask : 00000000FFFFFFFF
>
> Reading 0x7F8A803A you get:
> 0x2000
> which is exactly what you expect as "error memory length", but cut
> down to 8 bits it's wrong.
> Look at the mask value from which you could derive bit width (on APEI tables
> only), it should be 0x16, but it's not needed (bit width info) and should
> get ignored because it's sometimes wrong.
>
> The question remains whether Windows (which versions?) is only ignoring bit
> width in their APEI implementation (this is what I currently expect).
> For now, as we have separate APEI GAR checking it should be fine to
> only ignore bit width there. But keeping an eye open and check
> other ACPI tables containing GAR structures out there in the field
> is certainly a good idea.
Seems like these are BIOS bugs. Do we know for sure that Windows
consumes this information that seems to be wrong? Have you had a
conversation with the vendor about whether the BIOS is at fault here?
If we make Linux ignore the bit_width, that might "fix" these boxes
with broken BIOSes, but at the cost of breaking a box that uses
bit_width correctly.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [PATCH v2] NFC: update to NCI spec 1.0 draft 18
From: Gustavo Padovan @ 2011-10-31 15:51 UTC (permalink / raw)
To: ilanelias78
Cc: aloisio.almeida, lauro.venancio, samuel, linville, linux-wireless,
Ilan Elias
In-Reply-To: <1319551485-17963-1-git-send-email-ilane@ti.com>
Hi Ilian,
* ilanelias78@gmail.com <ilanelias78@gmail.com> [2011-10-25 16:04:45 +0200]:
> From: Ilan Elias <ilane@ti.com>
>
> Update supported features according to NCI spec 1.0 draft 18.
> No new features were introduced.
> The changes are related only to the NCI protocol layer.
>
> Summary of the main changes:
> - Addition, deletion, and modification of NCI constants
> - Changes in NCI commands, responses and notifications structures
> - Check if data flow control is used in nci_tx_work
> - No need to create the static rf connection anymore
> - Set available credits to initial value when target is deactivated
>
> Signed-off-by: Ilan Elias <ilane@ti.com>
> ---
> include/net/nfc/nci.h | 208 ++++++++++++++++++++++---------------------
> include/net/nfc/nci_core.h | 13 +--
> net/nfc/nci/core.c | 17 ++--
> net/nfc/nci/data.c | 5 +-
> net/nfc/nci/lib.c | 8 +--
> net/nfc/nci/ntf.c | 152 +++++++++++++++++++-------------
> net/nfc/nci/rsp.c | 149 ++++++++++++++-----------------
> 7 files changed, 281 insertions(+), 271 deletions(-)
>
> diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
> index 39b85bc..e4a2632 100644
> --- a/include/net/nfc/nci.h
> +++ b/include/net/nfc/nci.h
> @@ -33,47 +33,49 @@
> #define NCI_MAX_NUM_RF_CONFIGS 10
> #define NCI_MAX_NUM_CONN 10
>
> -/* NCI Status Codes */
> -#define NCI_STATUS_OK 0x00
> -#define NCI_STATUS_REJECTED 0x01
> -#define NCI_STATUS_MESSAGE_CORRUPTED 0x02
> -#define NCI_STATUS_BUFFER_FULL 0x03
> -#define NCI_STATUS_FAILED 0x04
> -#define NCI_STATUS_NOT_INITIALIZED 0x05
> -#define NCI_STATUS_SYNTAX_ERROR 0x06
> -#define NCI_STATUS_SEMANTIC_ERROR 0x07
> -#define NCI_STATUS_UNKNOWN_GID 0x08
> -#define NCI_STATUS_UNKNOWN_OID 0x09
> -#define NCI_STATUS_INVALID_PARAM 0x0a
> -#define NCI_STATUS_MESSAGE_SIZE_EXCEEDED 0x0b
> -/* Discovery Specific Status Codes */
> -#define NCI_STATUS_DISCOVERY_ALREADY_STARTED 0xa0
> -#define NCI_STATUS_DISCOVERY_TARGET_ACTIVATION_FAILED 0xa1
> +/* Generic Status Codes */
> +#define NCI_STATUS_OK 0x00
> +#define NCI_STATUS_REJECTED 0x01
> +#define NCI_STATUS_RF_FRAME_CORRUPTED 0x02
> +#define NCI_STATUS_FAILED 0x03
> +#define NCI_STATUS_NOT_INITIALIZED 0x04
> +#define NCI_STATUS_SYNTAX_ERROR 0x05
> +#define NCI_STATUS_SEMANTIC_ERROR 0x06
> +#define NCI_STATUS_UNKNOWN_GID 0x07
> +#define NCI_STATUS_UNKNOWN_OID 0x08
> +#define NCI_STATUS_INVALID_PARAM 0x09
> +#define NCI_STATUS_MESSAGE_SIZE_EXCEEDED 0x0a
> +/* RF Discovery Specific Status Codes */
> +#define NCI_STATUS_DISCOVERY_ALREADY_STARTED 0xa0
> +#define NCI_STATUS_DISCOVERY_TARGET_ACTIVATION_FAILED 0xa1
> +#define NCI_STATUS_DISCOVERY_TEAR_DOWN 0xa2
> /* RF Interface Specific Status Codes */
> -#define NCI_STATUS_RF_TRANSMISSION_ERROR 0xb0
> -#define NCI_STATUS_RF_PROTOCOL_ERROR 0xb1
> -#define NCI_STATUS_RF_TIMEOUT_ERROR 0xb2
> -#define NCI_STATUS_RF_LINK_LOSS_ERROR 0xb3
> +#define NCI_STATUS_RF_TRANSMISSION_ERROR 0xb0
> +#define NCI_STATUS_RF_PROTOCOL_ERROR 0xb1
> +#define NCI_STATUS_RF_TIMEOUT_ERROR 0xb2
> /* NFCEE Interface Specific Status Codes */
> -#define NCI_STATUS_MAX_ACTIVE_NFCEE_INTERFACES_REACHED 0xc0
> -#define NCI_STATUS_NFCEE_INTERFACE_ACTIVATION_FAILED 0xc1
> -#define NCI_STATUS_NFCEE_TRANSMISSION_ERROR 0xc2
> -#define NCI_STATUS_NFCEE_PROTOCOL_ERROR 0xc3
> +#define NCI_STATUS_MAX_ACTIVE_NFCEE_INTERFACES_REACHED 0xc0
> +#define NCI_STATUS_NFCEE_INTERFACE_ACTIVATION_FAILED 0xc1
> +#define NCI_STATUS_NFCEE_TRANSMISSION_ERROR 0xc2
> +#define NCI_STATUS_NFCEE_PROTOCOL_ERROR 0xc3
> #define NCI_STATUS_NFCEE_TIMEOUT_ERROR 0xc4
>
> -/* NCI RF Technology and Mode */
> -#define NCI_NFC_A_PASSIVE_POLL_MODE 0x00
> -#define NCI_NFC_B_PASSIVE_POLL_MODE 0x01
> -#define NCI_NFC_F_PASSIVE_POLL_MODE 0x02
> -#define NCI_NFC_A_ACTIVE_POLL_MODE 0x03
> -#define NCI_NFC_F_ACTIVE_POLL_MODE 0x05
> -#define NCI_NFC_A_PASSIVE_LISTEN_MODE 0x80
> -#define NCI_NFC_B_PASSIVE_LISTEN_MODE 0x81
> -#define NCI_NFC_F_PASSIVE_LISTEN_MODE 0x82
> -#define NCI_NFC_A_ACTIVE_LISTEN_MODE 0x83
> -#define NCI_NFC_F_ACTIVE_LISTEN_MODE 0x85
> -
> -/* NCI RF Protocols */
> +/* RF Technologies */
> +#define NCI_NFC_RF_TECHNOLOGY_A 0x00
> +#define NCI_NFC_RF_TECHNOLOGY_B 0x01
> +#define NCI_NFC_RF_TECHNOLOGY_F 0x02
> +#define NCI_NFC_RF_TECHNOLOGY_15693 0x03
> +
> +/* Bit Rates */
> +#define NCI_NFC_BIT_RATE_106 0x00
> +#define NCI_NFC_BIT_RATE_212 0x01
> +#define NCI_NFC_BIT_RATE_424 0x02
> +#define NCI_NFC_BIT_RATE_848 0x03
> +#define NCI_NFC_BIT_RATE_1696 0x04
> +#define NCI_NFC_BIT_RATE_3392 0x05
> +#define NCI_NFC_BIT_RATE_6784 0x06
> +
> +/* RF Protocols */
> #define NCI_RF_PROTOCOL_UNKNOWN 0x00
> #define NCI_RF_PROTOCOL_T1T 0x01
> #define NCI_RF_PROTOCOL_T2T 0x02
> @@ -81,38 +83,54 @@
> #define NCI_RF_PROTOCOL_ISO_DEP 0x04
> #define NCI_RF_PROTOCOL_NFC_DEP 0x05
>
> -/* NCI RF Interfaces */
> -#define NCI_RF_INTERFACE_RFU 0x00
> -#define NCI_RF_INTERFACE_FRAME 0x01
> -#define NCI_RF_INTERFACE_ISO_DEP 0x02
> -#define NCI_RF_INTERFACE_NFC_DEP 0x03
> +/* RF Interfaces */
> +#define NCI_RF_INTERFACE_NFCEE_DIRECT 0x00
> +#define NCI_RF_INTERFACE_FRAME 0x01
> +#define NCI_RF_INTERFACE_ISO_DEP 0x02
> +#define NCI_RF_INTERFACE_NFC_DEP 0x03
>
> -/* NCI RF_DISCOVER_MAP_CMD modes */
> +/* Reset types */
> +#define NCI_RESET_TYPE_KEEP_CONFIG 0x00
> +#define NCI_RESET_TYPE_RESET_CONFIG 0x01
> +
> +/* Static RF connection ID */
> +#define NCI_STATIC_RF_CONN_ID 0x00
> +
> +/* RF_DISCOVER_MAP_CMD modes */
> #define NCI_DISC_MAP_MODE_POLL 0x01
> #define NCI_DISC_MAP_MODE_LISTEN 0x02
> #define NCI_DISC_MAP_MODE_BOTH 0x03
>
> -/* NCI Discovery Types */
> +/* Discovery Types */
> #define NCI_DISCOVERY_TYPE_POLL_A_PASSIVE 0x00
> -#define NCI_DISCOVERY_TYPE_POLL_B_PASSIVE 0x01
> -#define NCI_DISCOVERY_TYPE_POLL_F_PASSIVE 0x02
> -#define NCI_DISCOVERY_TYPE_POLL_A_ACTIVE 0x03
> -#define NCI_DISCOVERY_TYPE_POLL_F_ACTIVE 0x05
> -#define NCI_DISCOVERY_TYPE_WAKEUP_A_PASSIVE 0x06
> -#define NCI_DISCOVERY_TYPE_WAKEUP_B_PASSIVE 0x07
> -#define NCI_DISCOVERY_TYPE_WAKEUP_A_ACTIVE 0x09
> -#define NCI_DISCOVERY_TYPE_LISTEN_A_PASSIVE 0x80
> -#define NCI_DISCOVERY_TYPE_LISTEN_B_PASSIVE 0x81
> -#define NCI_DISCOVERY_TYPE_LISTEN_F_PASSIVE 0x82
> -#define NCI_DISCOVERY_TYPE_LISTEN_A_ACTIVE 0x83
> -#define NCI_DISCOVERY_TYPE_LISTEN_F_ACTIVE 0x85
> -
> -/* NCI Deactivation Type */
> -#define NCI_DEACTIVATE_TYPE_IDLE_MODE 0x00
> -#define NCI_DEACTIVATE_TYPE_SLEEP_MODE 0x01
> -#define NCI_DEACTIVATE_TYPE_SLEEP_AF_MODE 0x02
> -#define NCI_DEACTIVATE_TYPE_RF_LINK_LOSS 0x03
> -#define NCI_DEACTIVATE_TYPE_DISCOVERY_ERROR 0x04
> +#define NCI_DISCOVERY_TYPE_POLL_B_PASSIVE 0x01
> +#define NCI_DISCOVERY_TYPE_POLL_F_PASSIVE 0x02
> +#define NCI_DISCOVERY_TYPE_POLL_A_ACTIVE 0x03
> +#define NCI_DISCOVERY_TYPE_POLL_F_ACTIVE 0x05
> +#define NCI_DISCOVERY_TYPE_WAKEUP_A_ACTIVE 0x09
> +#define NCI_DISCOVERY_TYPE_LISTEN_A_PASSIVE 0x80
> +#define NCI_DISCOVERY_TYPE_LISTEN_B_PASSIVE 0x81
> +#define NCI_DISCOVERY_TYPE_LISTEN_F_PASSIVE 0x82
> +#define NCI_DISCOVERY_TYPE_LISTEN_A_ACTIVE 0x83
> +#define NCI_DISCOVERY_TYPE_LISTEN_F_ACTIVE 0x85
> +
> +/* RF Technology and Mode */
> +#define NCI_NFC_A_PASSIVE_POLL_MODE 0x00
> +#define NCI_NFC_B_PASSIVE_POLL_MODE 0x01
> +#define NCI_NFC_F_PASSIVE_POLL_MODE 0x02
> +#define NCI_NFC_A_ACTIVE_POLL_MODE 0x03
> +#define NCI_NFC_F_ACTIVE_POLL_MODE 0x05
> +#define NCI_NFC_A_PASSIVE_LISTEN_MODE 0x80
> +#define NCI_NFC_B_PASSIVE_LISTEN_MODE 0x81
> +#define NCI_NFC_F_PASSIVE_LISTEN_MODE 0x82
> +#define NCI_NFC_A_ACTIVE_LISTEN_MODE 0x83
> +#define NCI_NFC_F_ACTIVE_LISTEN_MODE 0x85
> +
> +/* Deactivation Type */
> +#define NCI_DEACTIVATE_TYPE_IDLE_MODE 0x00
> +#define NCI_DEACTIVATE_TYPE_SLEEP_MODE 0x01
> +#define NCI_DEACTIVATE_TYPE_SLEEP_AF_MODE 0x02
> +#define NCI_DEACTIVATE_TYPE_DISCOVERY 0x03
>
> /* Message Type (MT) */
> #define NCI_MT_DATA_PKT 0x00
> @@ -144,10 +162,10 @@
> #define nci_conn_id(hdr) (__u8)(((hdr)[0])&0x0f)
>
> /* GID values */
> -#define NCI_GID_CORE 0x0
> -#define NCI_GID_RF_MGMT 0x1
> -#define NCI_GID_NFCEE_MGMT 0x2
> -#define NCI_GID_PROPRIETARY 0xf
> +#define NCI_GID_CORE 0x0
> +#define NCI_GID_RF_MGMT 0x1
> +#define NCI_GID_NFCEE_MGMT 0x2
> +#define NCI_GID_PROPRIETARY 0xf
>
> /* ---- NCI Packet structures ---- */
> #define NCI_CTRL_HDR_SIZE 3
> @@ -169,18 +187,11 @@ struct nci_data_hdr {
> /* ----- NCI Commands ---- */
> /* ------------------------ */
> #define NCI_OP_CORE_RESET_CMD nci_opcode_pack(NCI_GID_CORE, 0x00)
> -
> -#define NCI_OP_CORE_INIT_CMD nci_opcode_pack(NCI_GID_CORE, 0x01)
> -
> -#define NCI_OP_CORE_SET_CONFIG_CMD nci_opcode_pack(NCI_GID_CORE, 0x02)
> -
> -#define NCI_OP_CORE_CONN_CREATE_CMD nci_opcode_pack(NCI_GID_CORE, 0x04)
> -struct nci_core_conn_create_cmd {
> - __u8 target_handle;
> - __u8 num_target_specific_params;
> +struct nci_core_reset_cmd {
> + __u8 reset_type;
> } __packed;
>
> -#define NCI_OP_CORE_CONN_CLOSE_CMD nci_opcode_pack(NCI_GID_CORE, 0x06)
> +#define NCI_OP_CORE_INIT_CMD nci_opcode_pack(NCI_GID_CORE, 0x01)
>
> #define NCI_OP_RF_DISCOVER_MAP_CMD nci_opcode_pack(NCI_GID_RF_MGMT, 0x00)
> struct disc_map_config {
> @@ -218,6 +229,7 @@ struct nci_rf_deactivate_cmd {
> struct nci_core_reset_rsp {
> __u8 status;
> __u8 nci_ver;
> + __u8 config_status;
> } __packed;
>
> #define NCI_OP_CORE_INIT_RSP nci_opcode_pack(NCI_GID_CORE, 0x01)
> @@ -232,24 +244,14 @@ struct nci_core_init_rsp_1 {
> struct nci_core_init_rsp_2 {
> __u8 max_logical_connections;
> __le16 max_routing_table_size;
> - __u8 max_control_packet_payload_length;
> - __le16 rf_sending_buffer_size;
> - __le16 rf_receiving_buffer_size;
> - __le16 manufacturer_id;
> -} __packed;
> -
> -#define NCI_OP_CORE_SET_CONFIG_RSP nci_opcode_pack(NCI_GID_CORE, 0x02)
> -
> -#define NCI_OP_CORE_CONN_CREATE_RSP nci_opcode_pack(NCI_GID_CORE, 0x04)
> -struct nci_core_conn_create_rsp {
> - __u8 status;
> - __u8 max_pkt_payload_size;
> + __u8 max_control_pkt_payload_len;
> + __le16 max_size_for_large_params;
> + __u8 max_data_pkt_payload_size;
> __u8 initial_num_credits;
> - __u8 conn_id;
> + __u8 manufacturer_id;
> + __le32 manufacturer_specific_info;
> } __packed;
>
> -#define NCI_OP_CORE_CONN_CLOSE_RSP nci_opcode_pack(NCI_GID_CORE, 0x06)
> -
> #define NCI_OP_RF_DISCOVER_MAP_RSP nci_opcode_pack(NCI_GID_RF_MGMT, 0x00)
>
> #define NCI_OP_RF_DISCOVER_RSP nci_opcode_pack(NCI_GID_RF_MGMT, 0x03)
> @@ -270,12 +272,7 @@ struct nci_core_conn_credit_ntf {
> struct conn_credit_entry conn_entries[NCI_MAX_NUM_CONN];
> } __packed;
>
> -#define NCI_OP_RF_FIELD_INFO_NTF nci_opcode_pack(NCI_GID_CORE, 0x08)
> -struct nci_rf_field_info_ntf {
> - __u8 rf_field_status;
> -} __packed;
> -
> -#define NCI_OP_RF_ACTIVATE_NTF nci_opcode_pack(NCI_GID_RF_MGMT, 0x05)
> +#define NCI_OP_RF_INTF_ACTIVATED_NTF nci_opcode_pack(NCI_GID_RF_MGMT, 0x05)
> struct rf_tech_specific_params_nfca_poll {
> __u16 sens_res;
> __u8 nfcid1_len; /* 0, 4, 7, or 10 Bytes */
> @@ -289,17 +286,20 @@ struct activation_params_nfca_poll_iso_dep {
> __u8 rats_res[20];
> };
>
> -struct nci_rf_activate_ntf {
> - __u8 target_handle;
> +struct nci_rf_intf_activated_ntf {
> + __u8 rf_discovery_id;
> + __u8 rf_interface_type;
> __u8 rf_protocol;
> - __u8 rf_tech_and_mode;
> + __u8 activation_rf_tech_and_mode;
> __u8 rf_tech_specific_params_len;
>
> union {
> struct rf_tech_specific_params_nfca_poll nfca_poll;
> } rf_tech_specific_params;
>
> - __u8 rf_interface_type;
> + __u8 data_exchange_rf_tech_and_mode;
> + __u8 data_exchange_tx_bit_rate;
> + __u8 data_exchange_rx_bit_rate;
> __u8 activation_params_len;
Aren't these names too big? Do you really need such a big names?
>
> union {
> @@ -309,5 +309,9 @@ struct nci_rf_activate_ntf {
> } __packed;
>
> #define NCI_OP_RF_DEACTIVATE_NTF nci_opcode_pack(NCI_GID_RF_MGMT, 0x06)
> +struct nci_rf_deactivate_ntf {
> + __u8 type;
> + __u8 reason;
> +} __packed;
What about a patch that only change the defines? Could make things easier to
review.
>
> #endif /* __NCI_H */
> diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
> index b8b4bbd..77b7c9e 100644
> --- a/include/net/nfc/nci_core.h
> +++ b/include/net/nfc/nci_core.h
> @@ -109,15 +109,12 @@ struct nci_dev {
> [NCI_MAX_SUPPORTED_RF_INTERFACES];
> __u8 max_logical_connections;
> __u16 max_routing_table_size;
> - __u8 max_control_packet_payload_length;
> - __u16 rf_sending_buffer_size;
> - __u16 rf_receiving_buffer_size;
> - __u16 manufacturer_id;
> -
> - /* received during NCI_OP_CORE_CONN_CREATE_RSP for static conn 0 */
> - __u8 max_pkt_payload_size;
> + __u8 max_control_pkt_payload_len;
> + __u16 max_size_for_large_params;
> + __u8 max_data_pkt_payload_size;
> __u8 initial_num_credits;
> - __u8 conn_id;
> + __u8 manufacturer_id;
> + __u32 manufacturer_specific_info;
>
> /* stored during nci_data_exchange */
> data_exchange_cb_t data_exchange_cb;
> diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
> index 4047e29..056cd37 100644
> --- a/net/nfc/nci/core.c
> +++ b/net/nfc/nci/core.c
> @@ -125,7 +125,10 @@ static inline int nci_request(struct nci_dev *ndev,
>
> static void nci_reset_req(struct nci_dev *ndev, unsigned long opt)
> {
> - nci_send_cmd(ndev, NCI_OP_CORE_RESET_CMD, 0, NULL);
> + struct nci_core_reset_cmd cmd;
> +
> + cmd.reset_type = NCI_RESET_TYPE_RESET_CONFIG;
> + nci_send_cmd(ndev, NCI_OP_CORE_RESET_CMD, 1, &cmd);
> }
>
> static void nci_init_req(struct nci_dev *ndev, unsigned long opt)
> @@ -135,17 +138,11 @@ static void nci_init_req(struct nci_dev *ndev, unsigned long opt)
>
> static void nci_init_complete_req(struct nci_dev *ndev, unsigned long opt)
> {
> - struct nci_core_conn_create_cmd conn_cmd;
> struct nci_rf_disc_map_cmd cmd;
> struct disc_map_config *cfg = cmd.mapping_configs;
> __u8 *num = &cmd.num_mapping_configs;
> int i;
>
> - /* create static rf connection */
> - conn_cmd.target_handle = 0;
> - conn_cmd.num_target_specific_params = 0;
> - nci_send_cmd(ndev, NCI_OP_CORE_CONN_CREATE_CMD, 2, &conn_cmd);
> -
> /* set rf mapping configurations */
> *num = 0;
>
> @@ -469,7 +466,7 @@ static int nci_data_exchange(struct nfc_dev *nfc_dev, __u32 target_idx,
> ndev->data_exchange_cb = cb;
> ndev->data_exchange_cb_context = cb_context;
>
> - rc = nci_send_data(ndev, ndev->conn_id, skb);
> + rc = nci_send_data(ndev, NCI_STATIC_RF_CONN_ID, skb);
> if (rc)
> clear_bit(NCI_DATA_EXCHANGE, &ndev->flags);
>
> @@ -725,7 +722,9 @@ static void nci_tx_work(struct work_struct *work)
> if (!skb)
> return;
>
> - atomic_dec(&ndev->credits_cnt);
> + /* Check if data flow control is used */
> + if (atomic_read(&ndev->credits_cnt) != 0xff)
> + atomic_dec(&ndev->credits_cnt);
This seems racy to me. Can't the value of credits_cnt change in between of
atomic_read and atomic_dec?
>
> nfc_dbg("NCI TX: MT=data, PBF=%d, conn_id=%d, plen=%d",
> nci_pbf(skb->data),
> diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
> index e5ed90f..511fb96 100644
> --- a/net/nfc/nci/data.c
> +++ b/net/nfc/nci/data.c
> @@ -95,7 +95,8 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
> __skb_queue_head_init(&frags_q);
>
> while (total_len) {
> - frag_len = min_t(int, total_len, ndev->max_pkt_payload_size);
> + frag_len =
> + min_t(int, total_len, ndev->max_data_pkt_payload_size);
>
> skb_frag = nci_skb_alloc(ndev,
> (NCI_DATA_HDR_SIZE + frag_len),
> @@ -151,7 +152,7 @@ int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb)
> nfc_dbg("entry, conn_id 0x%x, plen %d", conn_id, skb->len);
>
> /* check if the packet need to be fragmented */
> - if (skb->len <= ndev->max_pkt_payload_size) {
> + if (skb->len <= ndev->max_data_pkt_payload_size) {
> /* no need to fragment packet */
> nci_push_data_hdr(ndev, conn_id, skb, NCI_PBF_LAST);
>
> diff --git a/net/nfc/nci/lib.c b/net/nfc/nci/lib.c
> index b19dc2f..e99adcf 100644
> --- a/net/nfc/nci/lib.c
> +++ b/net/nfc/nci/lib.c
> @@ -42,12 +42,9 @@ int nci_to_errno(__u8 code)
> case NCI_STATUS_REJECTED:
> return -EBUSY;
>
> - case NCI_STATUS_MESSAGE_CORRUPTED:
> + case NCI_STATUS_RF_FRAME_CORRUPTED:
> return -EBADMSG;
>
> - case NCI_STATUS_BUFFER_FULL:
> - return -ENOBUFS;
> -
> case NCI_STATUS_NOT_INITIALIZED:
> return -EHOSTDOWN;
>
> @@ -80,9 +77,6 @@ int nci_to_errno(__u8 code)
> case NCI_STATUS_NFCEE_TIMEOUT_ERROR:
> return -ETIMEDOUT;
>
> - case NCI_STATUS_RF_LINK_LOSS_ERROR:
> - return -ENOLINK;
> -
> case NCI_STATUS_MAX_ACTIVE_NFCEE_INTERFACES_REACHED:
> return -EDQUOT;
>
> diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
> index 96633f5..770dfc8 100644
> --- a/net/nfc/nci/ntf.c
> +++ b/net/nfc/nci/ntf.c
> @@ -54,7 +54,7 @@ static void nci_core_conn_credits_ntf_packet(struct nci_dev *ndev,
> ntf->conn_entries[i].conn_id,
> ntf->conn_entries[i].credits);
>
> - if (ntf->conn_entries[i].conn_id == ndev->conn_id) {
> + if (ntf->conn_entries[i].conn_id == NCI_STATIC_RF_CONN_ID) {
> /* found static rf connection */
> atomic_add(ntf->conn_entries[i].credits,
> &ndev->credits_cnt);
> @@ -66,22 +66,12 @@ static void nci_core_conn_credits_ntf_packet(struct nci_dev *ndev,
> queue_work(ndev->tx_wq, &ndev->tx_work);
> }
>
> -static void nci_rf_field_info_ntf_packet(struct nci_dev *ndev,
> - struct sk_buff *skb)
> -{
> - struct nci_rf_field_info_ntf *ntf = (void *) skb->data;
> -
> - nfc_dbg("entry, rf_field_status %d", ntf->rf_field_status);
> -}
> -
> -static int nci_rf_activate_nfca_passive_poll(struct nci_dev *ndev,
> - struct nci_rf_activate_ntf *ntf, __u8 *data)
> +static __u8 *nci_extract_rf_params_nfca_passive_poll(struct nci_dev *ndev,
> + struct nci_rf_intf_activated_ntf *ntf, __u8 *data)
> {
> struct rf_tech_specific_params_nfca_poll *nfca_poll;
> - struct activation_params_nfca_poll_iso_dep *nfca_poll_iso_dep;
>
> nfca_poll = &ntf->rf_tech_specific_params.nfca_poll;
> - nfca_poll_iso_dep = &ntf->activation_params.nfca_poll_iso_dep;
>
> nfca_poll->sens_res = __le16_to_cpu(*((__u16 *)data));
> data += 2;
> @@ -100,32 +90,32 @@ static int nci_rf_activate_nfca_passive_poll(struct nci_dev *ndev,
> if (nfca_poll->sel_res_len != 0)
> nfca_poll->sel_res = *data++;
>
> - ntf->rf_interface_type = *data++;
> - ntf->activation_params_len = *data++;
> -
> - nfc_dbg("sel_res_len %d, sel_res 0x%x, rf_interface_type %d, activation_params_len %d",
> + nfc_dbg("sel_res_len %d, sel_res 0x%x",
> nfca_poll->sel_res_len,
> - nfca_poll->sel_res,
> - ntf->rf_interface_type,
> - ntf->activation_params_len);
> -
> - switch (ntf->rf_interface_type) {
> - case NCI_RF_INTERFACE_ISO_DEP:
> - nfca_poll_iso_dep->rats_res_len = *data++;
> - if (nfca_poll_iso_dep->rats_res_len > 0) {
> - memcpy(nfca_poll_iso_dep->rats_res,
> + nfca_poll->sel_res);
> +
> + return data;
> +}
> +
> +static int nci_extract_activation_params_iso_dep(struct nci_dev *ndev,
> + struct nci_rf_intf_activated_ntf *ntf, __u8 *data)
> +{
> + struct activation_params_nfca_poll_iso_dep *nfca_poll;
> +
> + switch (ntf->activation_rf_tech_and_mode) {
> + case NCI_NFC_A_PASSIVE_POLL_MODE:
> + nfca_poll = &ntf->activation_params.nfca_poll_iso_dep;
> + nfca_poll->rats_res_len = *data++;
> + if (nfca_poll->rats_res_len > 0) {
> + memcpy(nfca_poll->rats_res,
> data,
> - nfca_poll_iso_dep->rats_res_len);
> + nfca_poll->rats_res_len);
> }
> break;
>
> - case NCI_RF_INTERFACE_FRAME:
> - /* no activation params */
> - break;
> -
> default:
> - nfc_err("unsupported rf_interface_type 0x%x",
> - ntf->rf_interface_type);
> + nfc_err("unsupported activation_rf_tech_and_mode 0x%x",
> + ntf->activation_rf_tech_and_mode);
> return -EPROTO;
> }
>
> @@ -133,7 +123,7 @@ static int nci_rf_activate_nfca_passive_poll(struct nci_dev *ndev,
> }
>
> static void nci_target_found(struct nci_dev *ndev,
> - struct nci_rf_activate_ntf *ntf)
> + struct nci_rf_intf_activated_ntf *ntf)
> {
> struct nfc_target nfc_tgt;
>
> @@ -141,6 +131,8 @@ static void nci_target_found(struct nci_dev *ndev,
> nfc_tgt.supported_protocols = NFC_PROTO_MIFARE_MASK;
> else if (ntf->rf_protocol == NCI_RF_PROTOCOL_ISO_DEP) /* 4A */
> nfc_tgt.supported_protocols = NFC_PROTO_ISO14443_MASK;
> + else
> + nfc_tgt.supported_protocols = 0;
>
> nfc_tgt.sens_res = ntf->rf_tech_specific_params.nfca_poll.sens_res;
> nfc_tgt.sel_res = ntf->rf_tech_specific_params.nfca_poll.sel_res;
> @@ -158,49 +150,86 @@ static void nci_target_found(struct nci_dev *ndev,
> nfc_targets_found(ndev->nfc_dev, &nfc_tgt, 1);
> }
>
> -static void nci_rf_activate_ntf_packet(struct nci_dev *ndev,
> - struct sk_buff *skb)
> +static void nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev,
> + struct sk_buff *skb)
> {
> - struct nci_rf_activate_ntf ntf;
> + struct nci_rf_intf_activated_ntf ntf;
> __u8 *data = skb->data;
> - int rc = -1;
> + int err = 0;
>
> clear_bit(NCI_DISCOVERY, &ndev->flags);
> set_bit(NCI_POLL_ACTIVE, &ndev->flags);
>
> - ntf.target_handle = *data++;
> + ntf.rf_discovery_id = *data++;
> + ntf.rf_interface_type = *data++;
> ntf.rf_protocol = *data++;
> - ntf.rf_tech_and_mode = *data++;
> + ntf.activation_rf_tech_and_mode = *data++;
> ntf.rf_tech_specific_params_len = *data++;
>
> - nfc_dbg("target_handle %d, rf_protocol 0x%x, rf_tech_and_mode 0x%x, rf_tech_specific_params_len %d",
> - ntf.target_handle,
> - ntf.rf_protocol,
> - ntf.rf_tech_and_mode,
> + nfc_dbg("rf_discovery_id %d", ntf.rf_discovery_id);
> + nfc_dbg("rf_interface_type 0x%x", ntf.rf_interface_type);
> + nfc_dbg("rf_protocol 0x%x", ntf.rf_protocol);
> + nfc_dbg("activation_rf_tech_and_mode 0x%x",
> + ntf.activation_rf_tech_and_mode);
> + nfc_dbg("rf_tech_specific_params_len %d",
> ntf.rf_tech_specific_params_len);
>
> - switch (ntf.rf_tech_and_mode) {
> - case NCI_NFC_A_PASSIVE_POLL_MODE:
> - rc = nci_rf_activate_nfca_passive_poll(ndev, &ntf,
> - data);
> - break;
> + if (ntf.rf_tech_specific_params_len > 0) {
> + switch (ntf.activation_rf_tech_and_mode) {
> + case NCI_NFC_A_PASSIVE_POLL_MODE:
> + data = nci_extract_rf_params_nfca_passive_poll(ndev,
> + &ntf, data);
> + break;
> +
> + default:
> + nfc_err("unsupported activation_rf_tech_and_mode 0x%x",
> + ntf.activation_rf_tech_and_mode);
> + return;
> + }
> + }
>
> - default:
> - nfc_err("unsupported rf_tech_and_mode 0x%x",
> - ntf.rf_tech_and_mode);
> - return;
> + ntf.data_exchange_rf_tech_and_mode = *data++;
> + ntf.data_exchange_tx_bit_rate = *data++;
> + ntf.data_exchange_rx_bit_rate = *data++;
> + ntf.activation_params_len = *data++;
> +
> + nfc_dbg("data_exchange_rf_tech_and_mode 0x%x",
> + ntf.data_exchange_rf_tech_and_mode);
> + nfc_dbg("data_exchange_tx_bit_rate 0x%x",
> + ntf.data_exchange_tx_bit_rate);
> + nfc_dbg("data_exchange_rx_bit_rate 0x%x",
> + ntf.data_exchange_rx_bit_rate);
> + nfc_dbg("activation_params_len %d",
> + ntf.activation_params_len);
> +
> + if (ntf.activation_params_len > 0) {
Seems to me that ntf.activation_params_len > 0 can be a check in the beginning
of this function.
> + switch (ntf.rf_interface_type) {
> + case NCI_RF_INTERFACE_ISO_DEP:
> + err = nci_extract_activation_params_iso_dep(ndev,
> + &ntf, data);
> + break;
> +
> + case NCI_RF_INTERFACE_FRAME:
> + /* no activation params */
> + break;
> +
> + default:
> + nfc_err("unsupported rf_interface_type 0x%x",
> + ntf.rf_interface_type);
> + return;
> + }
> }
>
> - if (!rc)
> + if (!err)
> nci_target_found(ndev, &ntf);
> }
>
> static void nci_rf_deactivate_ntf_packet(struct nci_dev *ndev,
> struct sk_buff *skb)
> {
> - __u8 type = skb->data[0];
> + struct nci_rf_deactivate_ntf *ntf = (void *) skb->data;
>
> - nfc_dbg("entry, type 0x%x", type);
> + nfc_dbg("entry, type 0x%x, reason 0x%x", ntf->type, ntf->reason);
>
> clear_bit(NCI_POLL_ACTIVE, &ndev->flags);
> ndev->target_active_prot = 0;
> @@ -214,6 +243,9 @@ static void nci_rf_deactivate_ntf_packet(struct nci_dev *ndev,
> ndev->rx_data_reassembly = 0;
> }
>
> + /* set the available credits to initial value */
> + atomic_set(&ndev->credits_cnt, ndev->initial_num_credits);
> +
> /* complete the data exchange transaction, if exists */
> if (test_bit(NCI_DATA_EXCHANGE, &ndev->flags))
> nci_data_exchange_complete(ndev, NULL, -EIO);
> @@ -237,12 +269,8 @@ void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb)
> nci_core_conn_credits_ntf_packet(ndev, skb);
> break;
>
> - case NCI_OP_RF_FIELD_INFO_NTF:
> - nci_rf_field_info_ntf_packet(ndev, skb);
> - break;
> -
> - case NCI_OP_RF_ACTIVATE_NTF:
> - nci_rf_activate_ntf_packet(ndev, skb);
> + case NCI_OP_RF_INTF_ACTIVATED_NTF:
> + nci_rf_intf_activated_ntf_packet(ndev, skb);
> break;
>
> case NCI_OP_RF_DEACTIVATE_NTF:
> diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
> index 0403d4c..1d2a1ce 100644
> --- a/net/nfc/nci/rsp.c
> +++ b/net/nfc/nci/rsp.c
> @@ -42,10 +42,11 @@ static void nci_core_reset_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb)
>
> nfc_dbg("entry, status 0x%x", rsp->status);
>
> - if (rsp->status == NCI_STATUS_OK)
> + if (rsp->status == NCI_STATUS_OK) {
> ndev->nci_ver = rsp->nci_ver;
> -
> - nfc_dbg("nci_ver 0x%x", ndev->nci_ver);
> + nfc_dbg("nci_ver 0x%x, config_status 0x%x",
> + rsp->nci_ver, rsp->config_status);
> + }
>
> nci_req_complete(ndev, rsp->status);
> }
> @@ -57,86 +58,76 @@ static void nci_core_init_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb)
>
> nfc_dbg("entry, status 0x%x", rsp_1->status);
>
> - if (rsp_1->status != NCI_STATUS_OK)
> - return;
> -
> - ndev->nfcc_features = __le32_to_cpu(rsp_1->nfcc_features);
> - ndev->num_supported_rf_interfaces = rsp_1->num_supported_rf_interfaces;
> -
> - if (ndev->num_supported_rf_interfaces >
> - NCI_MAX_SUPPORTED_RF_INTERFACES) {
> + if (rsp_1->status == NCI_STATUS_OK) {
This works better if you invert the check and add a "goto err", then you save
one indentation level in the code.
> + ndev->nfcc_features = __le32_to_cpu(rsp_1->nfcc_features);
> ndev->num_supported_rf_interfaces =
> - NCI_MAX_SUPPORTED_RF_INTERFACES;
> + rsp_1->num_supported_rf_interfaces;
> +
> + if (ndev->num_supported_rf_interfaces >
> + NCI_MAX_SUPPORTED_RF_INTERFACES) {
Wrong indentation, one more tab here.
> + ndev->num_supported_rf_interfaces =
> + NCI_MAX_SUPPORTED_RF_INTERFACES;
> + }
> +
> + memcpy(ndev->supported_rf_interfaces,
> + rsp_1->supported_rf_interfaces,
> + ndev->num_supported_rf_interfaces);
> +
> + rsp_2 =
> + (void *) (skb->data + 6 + rsp_1->num_supported_rf_interfaces);
> +
> + ndev->max_logical_connections =
> + rsp_2->max_logical_connections;
> + ndev->max_routing_table_size =
> + __le16_to_cpu(rsp_2->max_routing_table_size);
> + ndev->max_control_pkt_payload_len =
> + rsp_2->max_control_pkt_payload_len;
> + ndev->max_size_for_large_params =
> + __le16_to_cpu(rsp_2->max_size_for_large_params);
> + ndev->max_data_pkt_payload_size =
> + rsp_2->max_data_pkt_payload_size;
> + ndev->initial_num_credits =
> + rsp_2->initial_num_credits;
> + ndev->manufacturer_id =
> + rsp_2->manufacturer_id;
> + ndev->manufacturer_specific_info =
> + __le32_to_cpu(rsp_2->manufacturer_specific_info);
> +
> + atomic_set(&ndev->credits_cnt, ndev->initial_num_credits);
> +
> + nfc_dbg("nfcc_features 0x%x",
> + ndev->nfcc_features);
> + nfc_dbg("num_supported_rf_interfaces %d",
> + ndev->num_supported_rf_interfaces);
> + nfc_dbg("supported_rf_interfaces[0] 0x%x",
> + ndev->supported_rf_interfaces[0]);
> + nfc_dbg("supported_rf_interfaces[1] 0x%x",
> + ndev->supported_rf_interfaces[1]);
> + nfc_dbg("supported_rf_interfaces[2] 0x%x",
> + ndev->supported_rf_interfaces[2]);
> + nfc_dbg("supported_rf_interfaces[3] 0x%x",
> + ndev->supported_rf_interfaces[3]);
> + nfc_dbg("max_logical_connections %d",
> + ndev->max_logical_connections);
> + nfc_dbg("max_routing_table_size %d",
> + ndev->max_routing_table_size);
> + nfc_dbg("max_control_pkt_payload_len %d",
> + ndev->max_control_pkt_payload_len);
> + nfc_dbg("max_size_for_large_params %d",
> + ndev->max_size_for_large_params);
> + nfc_dbg("max_data_pkt_payload_size %d",
> + ndev->max_data_pkt_payload_size);
> + nfc_dbg("initial_num_credits %d",
> + ndev->initial_num_credits);
> + nfc_dbg("manufacturer_id 0x%x",
> + ndev->manufacturer_id);
> + nfc_dbg("manufacturer_specific_info 0x%x",
> + ndev->manufacturer_specific_info);
> }
>
> - memcpy(ndev->supported_rf_interfaces,
> - rsp_1->supported_rf_interfaces,
> - ndev->num_supported_rf_interfaces);
> -
> - rsp_2 = (void *) (skb->data + 6 + ndev->num_supported_rf_interfaces);
> -
> - ndev->max_logical_connections =
> - rsp_2->max_logical_connections;
> - ndev->max_routing_table_size =
> - __le16_to_cpu(rsp_2->max_routing_table_size);
> - ndev->max_control_packet_payload_length =
> - rsp_2->max_control_packet_payload_length;
> - ndev->rf_sending_buffer_size =
> - __le16_to_cpu(rsp_2->rf_sending_buffer_size);
> - ndev->rf_receiving_buffer_size =
> - __le16_to_cpu(rsp_2->rf_receiving_buffer_size);
> - ndev->manufacturer_id =
> - __le16_to_cpu(rsp_2->manufacturer_id);
> -
> - nfc_dbg("nfcc_features 0x%x",
> - ndev->nfcc_features);
> - nfc_dbg("num_supported_rf_interfaces %d",
> - ndev->num_supported_rf_interfaces);
> - nfc_dbg("supported_rf_interfaces[0] 0x%x",
> - ndev->supported_rf_interfaces[0]);
> - nfc_dbg("supported_rf_interfaces[1] 0x%x",
> - ndev->supported_rf_interfaces[1]);
> - nfc_dbg("supported_rf_interfaces[2] 0x%x",
> - ndev->supported_rf_interfaces[2]);
> - nfc_dbg("supported_rf_interfaces[3] 0x%x",
> - ndev->supported_rf_interfaces[3]);
> - nfc_dbg("max_logical_connections %d",
> - ndev->max_logical_connections);
> - nfc_dbg("max_routing_table_size %d",
> - ndev->max_routing_table_size);
> - nfc_dbg("max_control_packet_payload_length %d",
> - ndev->max_control_packet_payload_length);
> - nfc_dbg("rf_sending_buffer_size %d",
> - ndev->rf_sending_buffer_size);
> - nfc_dbg("rf_receiving_buffer_size %d",
> - ndev->rf_receiving_buffer_size);
> - nfc_dbg("manufacturer_id 0x%x",
> - ndev->manufacturer_id);
> -
> nci_req_complete(ndev, rsp_1->status);
> }
>
> -static void nci_core_conn_create_rsp_packet(struct nci_dev *ndev,
> - struct sk_buff *skb)
> -{
> - struct nci_core_conn_create_rsp *rsp = (void *) skb->data;
> -
> - nfc_dbg("entry, status 0x%x", rsp->status);
> -
> - if (rsp->status != NCI_STATUS_OK)
> - return;
> -
> - ndev->max_pkt_payload_size = rsp->max_pkt_payload_size;
> - ndev->initial_num_credits = rsp->initial_num_credits;
> - ndev->conn_id = rsp->conn_id;
> -
> - atomic_set(&ndev->credits_cnt, ndev->initial_num_credits);
> -
> - nfc_dbg("max_pkt_payload_size %d", ndev->max_pkt_payload_size);
> - nfc_dbg("initial_num_credits %d", ndev->initial_num_credits);
> - nfc_dbg("conn_id %d", ndev->conn_id);
> -}
> -
> static void nci_rf_disc_map_rsp_packet(struct nci_dev *ndev,
> struct sk_buff *skb)
> {
> @@ -196,10 +187,6 @@ void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb)
> nci_core_init_rsp_packet(ndev, skb);
> break;
>
> - case NCI_OP_CORE_CONN_CREATE_RSP:
> - nci_core_conn_create_rsp_packet(ndev, skb);
> - break;
> -
This removal could also be in another patch.
Gustavo
^ permalink raw reply
* Re: [PATCH] ARM: mark empty gpio.h files empty
From: Linus Walleij @ 2011-10-31 15:50 UTC (permalink / raw)
To: Grant Likely
Cc: linux-arm-kernel, Jeff Garzik, linux-kernel, swarren, olof, ben,
arnaud.patard, w.sang, bs14
In-Reply-To: <20111029110613.GE20132@ponder.secretlab.ca>
On Sat, Oct 29, 2011 at 1:06 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Oct 28, 2011 at 10:19:02PM +0200, Linus Walleij wrote:
>> It is generally a better idea to make intentionally empty files
>> contain the human-readable /* empty */ comment, also it makes
>> the files play nice with "make distclean".
>>
>> Reported-by: Jeff Garzik <jeff@garzik.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> Applied, thanks.
Hm I put that into Russell's patch tracker since it was mainly
touching arch/arm/*
and I think he applied it too.
Well whatever, git will cope.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: mark empty gpio.h files empty
From: Linus Walleij @ 2011-10-31 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029110613.GE20132@ponder.secretlab.ca>
On Sat, Oct 29, 2011 at 1:06 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Oct 28, 2011 at 10:19:02PM +0200, Linus Walleij wrote:
>> It is generally a better idea to make intentionally empty files
>> contain the human-readable /* empty */ comment, also it makes
>> the files play nice with "make distclean".
>>
>> Reported-by: Jeff Garzik <jeff@garzik.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> Applied, thanks.
Hm I put that into Russell's patch tracker since it was mainly
touching arch/arm/*
and I think he applied it too.
Well whatever, git will cope.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [lm-sensors] Something wrong with support for NCT6776F in
From: Guenter Roeck @ 2011-10-31 15:50 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4EA9CECA.4050007@gmx.de>
T24gTW9uLCAyMDExLTEwLTMxIGF0IDAzOjQ2IC0wNDAwLCBTb2VyZW4gRC4gU2NodWx6ZSB3cm90
ZToKPiBPbiAzMS4xMC4yMDExIDA1OjU3LCBHdWVudGVyIFJvZWNrIHdyb3RlOgo+ID4+IEkgaGF2
ZSBhbiBBU1JvY2sgSDY3TS1JVFggbW90aGVyYm9hcmQuCj4gPj4KPiA+PiBUaGUgdzgzNjI2ZWhm
IGRyaXZlciBkZXRlY3RzOgo+ID4+Cj4gPj4gWyAzOTA0LjYwODY5M10gdzgzNjI3ZWhmOiBGb3Vu
ZCBOQ1Q2Nzc2RiBjaGlwIGF0IDB4MjkwCj4gPj4KPiA+PiAic2Vuc29ycyIgc2hvd3MgbWU6Cj4g
Pj4KPiA+PiBjb3JldGVtcC1pc2EtMDAwMAo+ID4+IEFkYXB0ZXI6IElTQSBhZGFwdGVyCj4gPj4g
UGh5c2ljYWwgaWQgMDogICs0Ni4wwrBDICAoaGlnaCA9ICs4MC4wwrBDLCBjcml0ID0gKzk4LjDC
sEMpCj4gPj4gQ29yZSAwOiAgICAgICAgICs0Ni4wwrBDICAoaGlnaCA9ICs4MC4wwrBDLCBjcml0
ID0gKzk4LjDCsEMpCj4gPj4gQ29yZSAxOiAgICAgICAgICs0NS4wwrBDICAoaGlnaCA9ICs4MC4w
wrBDLCBjcml0ID0gKzk4LjDCsEMpCj4gPj4gQ29yZSAyOiAgICAgICAgICs0Ni4wwrBDICAoaGln
aCA9ICs4MC4wwrBDLCBjcml0ID0gKzk4LjDCsEMpCj4gPj4gQ29yZSAzOiAgICAgICAgICs0Ni4w
wrBDICAoaGlnaCA9ICs4MC4wwrBDLCBjcml0ID0gKzk4LjDCsEMpCj4gPj4KPiA+PiBuY3Q2Nzc2
LWlzYS0wMjkwCj4gPj4gQWRhcHRlcjogSVNBIGFkYXB0ZXIKPiA+PiBWY29yZTogICAgICAgICAr
MC45NiBWICAobWluID0gICswLjAwIFYsIG1heCA9ICArMS43NCBWKQo+ID4+IGluMTogICAgICAg
ICAgICswLjE4IFYgIChtaW4gPSAgKzAuMDAgViwgbWF4ID0gICswLjAwIFYpICBBTEFSTQo+ID4+
IEFWQ0M6ICAgICAgICAgICszLjM5IFYgIChtaW4gPSAgKzAuMDAgViwgbWF4ID0gICswLjAwIFYp
ICBBTEFSTQo+ID4+ICszLjNWOiAgICAgICAgICszLjM5IFYgIChtaW4gPSAgKzAuMDAgViwgbWF4
ID0gICswLjAwIFYpICBBTEFSTQo+ID4+IGluNDogICAgICAgICAgICswLjU0IFYgIChtaW4gPSAg
KzAuMDAgViwgbWF4ID0gICswLjAwIFYpICBBTEFSTQo+ID4+IGluNTogICAgICAgICAgICsxLjY5
IFYgIChtaW4gPSAgKzAuMDAgViwgbWF4ID0gICswLjAwIFYpICBBTEFSTQo+ID4+IDNWU0I6ICAg
ICAgICAgICszLjQxIFYgIChtaW4gPSAgKzAuMDAgViwgbWF4ID0gICswLjAwIFYpICBBTEFSTQo+
ID4+IFZiYXQ6ICAgICAgICAgICszLjMxIFYgIChtaW4gPSAgKzAuMDAgViwgbWF4ID0gICswLjAw
IFYpICBBTEFSTQo+ID4+IGZhbjE6ICAgICAgICAgICAgMCBSUE0gIChtaW4gPSAgICAwIFJQTSkg
IEFMQVJNCj4gPj4gZmFuMjogICAgICAgICAyMTgwIFJQTSAgKG1pbiA9ICAgIDAgUlBNKSAgQUxB
Uk0KPiA+PiBTWVNUSU46ICAgICAgICArNDIuMMKwQyAgKGhpZ2ggPSAgKzAuMMKwQywgaHlzdCA9
ICArMC4wwrBDKSAgQUxBUk0gIHNlbnNvcgo+ID4+ID0gdGhlcm1pc3Rvcgo+ID4+IENQVVRJTjog
ICAgICAgKzEyNy41wrBDICAoaGlnaCA9ICs4MC4wwrBDLCBoeXN0ID0gKzc1LjDCsEMpICBBTEFS
TSAgc2Vuc29yCj4gPj4gPSB0aGVybWlzdG9yCj4gPj4gQVVYVElOOiAgICAgICAgLTI0LjDCsEMg
IChoaWdoID0gKzgwLjDCsEMsIGh5c3QgPSArNzUuMMKwQykgIHNlbnNvciA9Cj4gPj4gdGhlcm1p
c3Rvcgo+ID4+IFBFQ0kgQWdlbnQgMDogICs0Ni41wrBDCj4gPj4gY3B1MF92aWQ6ICAgICArMi4w
NTAgVgo+ID4+IGludHJ1c2lvbjA6ICAgQUxBUk0KPiA+PiBpbnRydXNpb24xOiAgIEFMQVJNCj4g
Pj4KPiA+Pgo+ID4+IEhlcmUsIENQVVRJTiBhbmQgQVVYVElOICh3aGF0ZXZlciBpdCBpcykgYXJl
IG9idmlvdXNseSB3cm9uZy4gIENQVVRJTgo+ID4+ICpkZWNyZWFzZXMqIHRvd2FyZHMgMTfCsEMg
d2hlbiB0aGUgQ1BVIGdldHMgaG90IChub24tbGluZWFybHksIHRob3VnaCkuCj4gPj4KPiA+IE9k
ZC4gTm8gaWRlYSB3aGF0IGlzIGdvaW5nIG9uLCB0aG91Z2guIFRoZSByZWdpc3RlcnMgYXJlIHF1
aXRlIHN0cmFpZ2h0Zm9yd2FyZCwKPiA+IGFuZCB0aGUgc2FtZSBmb3IgTkNUNjc3NUYgYW5kIE5D
VDY3NzZGLiBBbmQgaXQgd29ya3Mgb24gbXkgc3lzdGVtIHdpdGggTkNUNjc3NUYuCj4gCj4gSXMg
dGhlcmUgdGhlIG9wdGlvbiB0aGF0IGF1dG8tZGV0ZWN0aW9uIHdhcyB3cm9uZyBhbmQgSSBoYXZl
IGEgCj4gY29tcGxldGVseSBkaWZmZXJlbnQgY2hpcD8KPiAKVGhlb3JldGljYWxseSBwb3NzaWJs
ZSwgYnV0IHVubGlrZWx5LiBNb3JlIGxpa2VseSBzb21ldGhpbmcgaXMgbWlzc2luZywKb3IgdGhl
IGNoaXAgaXMgbWlzY29uZmlndXJlZCBmcm9tIHRoZSBCSU9TLgoKPiA+PiBUaGlzIHdhcyB0aGUg
Zmlyc3QgcHJvYmxlbS4gIFRoZSBzZWNvbmQgcHJvYmxlbSBvY2N1cnMgd2hlbiBJIHRyeSB0bwo+
ID4+IGNvbnRyb2wgZmFuMiBtYW51YWxseS4gIFRoZSAicHdtMiIgZmlsZSBpbiBzeXNmcyBpcyAy
NTUgZm9yIGFueXRoaW5nCj4gPj4gYWJvdmUgMjAwMCBSUE0sIGJ1dCBhcyB5b3UgY2FuIHNlZSBh
Ym92ZSwgdGhlIGZhbiBjYW4gZG8gbW9yZSAoSSd2ZSBiZWVuCj4gPj4gYXQgMjYwMCBSUE0gLS0g
bWF5YmUgaXQgY2FuIGRvIGV2ZW4gbW9yZSksIGJ1dCBwd20yIHN0YXlzIGF0IDI1NS4KPiA+Pgo+
ID4gTG9va2luZyB0aHJvdWdoIHRoZSBkYXRhc2hlZXQsIEkgZGlkIG5vdCBmaW5kIGFueXRoaW5n
IG9idmlvdXMuIEl0IG1pZ2h0Cj4gPiBiZSBwb3NzaWJsZSB0aGF0IHRoZSBQV00gb3V0cHV0IGZy
ZXF1ZW5jeSAocmVnaXN0ZXIgMiBiYW5rIDApIHNvbWVob3cgYWZmZWN0cwo+ID4gdGhlIGZhbiBz
cGVlZCBhcyB3ZWxsLiBXaGF0IGNhdXNlcyB0aGUgZmFuIHNwZWVkIHRvIGdvIGhpZ2hlciBpbiB5
b3VyIHN5c3RlbSA/Cj4gCj4gSGlnaCB0ZW1wZXJhdHVyZSBpbiBUZW1wZXJhdHVyZSBDcnVpc2Ug
bW9kZS4KPiAKPiBNeSBmaXJtd2FyZSBzZXR1cCBpbnRlcmZhY2UgYWN0dWFsbHkgcHJvdmlkZXMg
bWUgd2l0aCBib3RoIHRoZSBvcHRpb25zIAo+ICJUYXJnZXQgZmFuIHNwZWVkIiBhbmQgIlRhcmdl
dCB0ZW1wZXJhdHVyZSIsIGJ1dCBJIGhhdmUgdGhlIGltcHJlc3Npb24gCj4gdGhhdCB3aGlsZSB0
aGUgZHJpdmVyIHJlcG9ydHMgdGhhdCBJJ20gaW4gVGVtcGVyYXR1cmUgQ3J1aXNlIG1vZGUsIHRo
ZSAKPiBmYW4gc3BlZWQgZG9lcyBub3QgdmFyeSB0aGF0IG11Y2gsIGJ1dCBpdCByYXRoZXIgdHJp
ZXMgdG8ga2VlcCB0aGUgZmFuIAo+IHNwZWVkIGNvbnN0YW50IHVubGVzcyB0ZW1wZXJhdHVyZSBp
cyBjb21wbGV0ZWx5IG91dCBvZiByYW5nZS4KPiAKPiBUaGUgZmFuIHNwZWVkcyB1cCBvbmx5IHdo
ZW4gSSdtIGFib3ZlIDYwwrBDLCBhbmQgZXZlbiB0aGF0IHdpdGggYSBjZXJ0YWluIAo+IGRlbGF5
LCBzbyB1bmRlciBmdWxsIGxvYWQsIEkgZ2V0IGFib3ZlIDcwwrBDIHdoZW4gbXkgZmFucyBhcmUg
Cj4gZmlybXdhcmUtY29udHJvbGxlZC4uLiAgVGhhdCdzIGJhc2ljYWxseSB0aGUgcmVhc29uIHdo
eSBJIHdhbnQgc29mdHdhcmUgCj4gY29udHJvbC4KCk1pZ2h0IGJlIHRoZSB3YXkgaXQgaXMgY29u
ZmlndXJlZC4gQmVzdCBvcHRpb24sIGlmIHlvdSBjYW4gZG8gdGhhdCwKd291bGQgcHJvYmFibHkg
YmUgdG8gZ2V0IHRoZSBkYXRhc2hlZXQgZnJvbSBOdXZvdG9uIChhc2sgbmljZWx5IGFuZApleHBs
YWluIHdoeSB5b3UgbmVlZCBpdCkgYW5kIGNoZWNrIHRoZSB2YXJpb3VzIHJlZ2lzdGVycyBhbmQg
d2hhdCB0aGV5CmFyZSBkb2luZy4KCkd1ZW50ZXIKCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29y
c0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0
aW5mby9sbS1zZW5zb3Jz
^ permalink raw reply
* Re: [PATCH] oom: fix integer overflow of points in oom_badness
From: Frantisek Hrbata @ 2011-10-31 15:49 UTC (permalink / raw)
To: Oleg Nesterov
Cc: rientjes, linux-mm, linux-kernel, akpm, kosaki.motohiro,
minchan.kim, stable, eteo, pmatouse
In-Reply-To: <20111031152833.GA31904@redhat.com>
On Mon, Oct 31, 2011 at 04:28:33PM +0100, Oleg Nesterov wrote:
> 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.
Agreed. I will post v2 with the int => long change.
>
> 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.
You are right, it's not needed. I just wanted to make the cast more visible, but
some kind of comment would be probably better here.
>
> 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.
Sure, this looks much better than the one line expression in the patch I sent.
If David or others decide to not go with the int=>long change I think we should
use this.
>
> Oleg.
>
Many thanks Oleg.
--
Frantisek Hrbata
^ permalink raw reply
* Re: [PATCH] oom: fix integer overflow of points in oom_badness
From: Frantisek Hrbata @ 2011-10-31 15:49 UTC (permalink / raw)
To: Oleg Nesterov
Cc: rientjes, linux-mm, linux-kernel, akpm, kosaki.motohiro,
minchan.kim, stable, eteo, pmatouse
In-Reply-To: <20111031152833.GA31904@redhat.com>
On Mon, Oct 31, 2011 at 04:28:33PM +0100, Oleg Nesterov wrote:
> 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.
Agreed. I will post v2 with the int => long change.
>
> 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.
You are right, it's not needed. I just wanted to make the cast more visible, but
some kind of comment would be probably better here.
>
> 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.
Sure, this looks much better than the one line expression in the patch I sent.
If David or others decide to not go with the int=>long change I think we should
use this.
>
> Oleg.
>
Many thanks Oleg.
--
Frantisek Hrbata
--
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 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Trond Myklebust @ 2011-10-31 15:49 UTC (permalink / raw)
To: Peng Tao; +Cc: linux-nfs, bhalevy, Peng Tao
In-Reply-To: <1320074136-3087-2-git-send-email-bergwolf@gmail.com>
On Mon, 2011-10-31 at 08:15 -0700, Peng Tao wrote:
> For blocklayout, we need to issue layoutreturn to return layouts when
> handling CB_RECALL_ANY.
Why?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: [PATCH RFC 8/8] tile: implement syscall restart generically
From: Chris Metcalf @ 2011-10-31 15:48 UTC (permalink / raw)
To: Jonas Bonn; +Cc: linux-kernel, linux-arch
In-Reply-To: <e790f266cc75b291d44726cf6bf8641d1bf7af5d.1319364492.git.jonas@southpole.se>
On 10/23/2011 6:20 AM, Jonas Bonn wrote:
> Manipulating task state to effect re-execution of an interrupted syscall
> used to be purely architecture specific code. However, as most arch's
> were essentially just making minor adjustments to almost identical logic,
> this code could be moved to a common implementation.
>
> The generic variant introduces the function handle_syscall_restart() to be
> called after get_signal_to_deliver(). The architecture specific register
> manipulations required to effect the actual restart are now implemented
> in the generic syscall interface found in asm/syscall.h
>
> This patch transitions this architecture's signal handling code over to
> using the generic syscall restart code by:
>
> i) Implementing the register manipulations in asm/syscall.h
> ii) Replacing the restart logic with a call to handle_syscall_restart
>
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
I like the idea, though the patch isn't quite right:
- You need to move the definition of INT_SWINT_1_SIGRETURN from
<asm/sigframe.h> to <asm/syscall.h>. You then have to add #includes of
<asm/syscall.h> to signal.c and stack.c in arch/tile/kernel. (And probably
use syscall_clear() in signal.c.)
- In syscall_do_restartblock() you need to use regs->regs[], not regs->gprs[].
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH RFC 8/8] tile: implement syscall restart generically
From: Chris Metcalf @ 2011-10-31 15:48 UTC (permalink / raw)
To: Jonas Bonn; +Cc: linux-kernel, linux-arch
In-Reply-To: <e790f266cc75b291d44726cf6bf8641d1bf7af5d.1319364492.git.jonas@southpole.se>
On 10/23/2011 6:20 AM, Jonas Bonn wrote:
> Manipulating task state to effect re-execution of an interrupted syscall
> used to be purely architecture specific code. However, as most arch's
> were essentially just making minor adjustments to almost identical logic,
> this code could be moved to a common implementation.
>
> The generic variant introduces the function handle_syscall_restart() to be
> called after get_signal_to_deliver(). The architecture specific register
> manipulations required to effect the actual restart are now implemented
> in the generic syscall interface found in asm/syscall.h
>
> This patch transitions this architecture's signal handling code over to
> using the generic syscall restart code by:
>
> i) Implementing the register manipulations in asm/syscall.h
> ii) Replacing the restart logic with a call to handle_syscall_restart
>
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Signed-off-by: Jonas Bonn <jonas@southpole.se>
I like the idea, though the patch isn't quite right:
- You need to move the definition of INT_SWINT_1_SIGRETURN from
<asm/sigframe.h> to <asm/syscall.h>. You then have to add #includes of
<asm/syscall.h> to signal.c and stack.c in arch/tile/kernel. (And probably
use syscall_clear() in signal.c.)
- In syscall_do_restartblock() you need to use regs->regs[], not regs->gprs[].
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: couple questions about cleaning up the Quick Start Guide
From: Robert P. J. Day @ 2011-10-31 15:47 UTC (permalink / raw)
To: Rifenbark, Scott M; +Cc: Yocto discussion list
In-Reply-To: <41DEA4B02DBDEF40A0F3B6D0DDB1237916E9FEFB@ORSMSX101.amr.corp.intel.com>
On Mon, 31 Oct 2011, Rifenbark, Scott M wrote:
> Robert,
>
> Thanks for the stuff and the look here. Regarding your first point
> - I don't have a problem using the real link over the redirect.
> The only things that come to mind are if they work why change them?
> But, if the community wants the downloads.yoctoproject.org/releases
> URL in there I can certainly go in and make changes to master.
yes, that's a judgment call, someone else can make that decision.
obviously, not a critical change.
> On the second point - you are absolutely correct here. I will fix
> that in master to reflect where the tarball really is. I think as
> the project moves forward there will be more consistency. Early
> life jitters I guess :)
i suspect you've already seen the two patches i posted yesterday.
just apply what you think is useful, i've already moved on to the next
manual i'm fighting with. :-)
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()
From: Alex Deucher @ 2011-10-31 15:46 UTC (permalink / raw)
To: Thomas Reim; +Cc: Alex Deucher, dri-devel
In-Reply-To: <1320074105.4172.51.camel@Mark-Aurel.gas.de>
On Mon, Oct 31, 2011 at 11:15 AM, Thomas Reim <reimth@googlemail.com> wrote:
> Dear Alex,
>
> your reply confuses me:
>
>> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim <reimth@googlemail.com> wrote:
>> > Dear Alex,
>> >
>> > but we use DDC probing e. g. to identify connectors with improperly
>> > terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
>> > we decided some months ago to use this function during module loading to
>> > inform the user once (and only once!), which connector has a monitor
>> > connected with valid EDID and which connector has not.
>>
>> There's nothing in that function that actually prevents the printing
>> of bad EDIDs.
>
> That's true.
>
>> All it does is call drm_get_edid() and report whether
>> it found an EDID or not. radeon_dvi_detect() already takes into
>> account the requires_extended_probe flag.
>
> The extended probe flag will prevent the radeon driver from further
> useless printing of bad EDIDs every ten seconds:
Yes, the extended probe check will prevent the spewing of probe
failures, so why do we need to fetch all the edids again at load? It
just adds latency.
>
> in radeon_connectors.c:
> if (radeon_connector->ddc_bus)
> dret = radeon_ddc_probe(radeon_connector,
> radeon_connector->requires_extended_probe);
> if (dret) {
> if (radeon_connector->edid) {
> kfree(radeon_connector->edid);
> radeon_connector->edid = NULL;
> }
> radeon_connector->edid = drm_get_edid(&radeon_connector->base, &radeon_connector->ddc_bus->adapter);
>
>
>
>
> But the now to be removed function radeon_ddc_dump() took care during
> connector setup that at least one (!) dump was in the logs, accompagnied
> by the info, that no monitor is connected, or there is a wrong/buggy
> EDID.
Ok, I see what you are saying. I'm not sure how important it is that
we print that out. If we have an improperly terminated i2c line,
you'll either get an edid or garbage and we already cover that with
the extended edid probe check.
>
> in radeon_display.c:
> radeon_print_display_setup(dev);
> list_for_each_entry(drm_connector, &dev->mode_config.connector_list, head)
> radeon_ddc_dump(drm_connector);
>
>
> I cannot imagine why this should confuse users. Having retrieved and
> configured connectors plus info plus EDID dump in case of problems
> logged next to each other was perfect.
It's confusing because on systems with eDP, DP, or DP bridge chips
(VGA and LVDS bridges) users get messages saying that the connectors
are disconnected or have a bad edid and then they file bugs that the
driver can''t detect their monitor when the monitor is detected just
fine, it's just on aux rather than i2c. It also adds latency to boot
since you now have two rounds of connector probing; once for the
ddc_dump, and once for the fb code. If we only dump information for
certain connectors it is also confusing since users will not see some
of the connectors checked at boot while others will be. We could add
additional logic for the DP cases, but you'd need to drag in most of
the logic from the dp detect functions in order to determine whether
the DP port is in DP or legacy mode and then decide whether or not to
use aux or i2c; all of which just adds more boot latency considering
we already have to do this for the fb setup.
>
>> The connectors are probed by
>> the fb code for the console as well so it just adds to the module load
>> time. If we want to print what connectors are connected, it should be
>> done from the fb code so we only have to do it once.
>>
>
> I briefly checked the code, but couldn't find a promising connector
> probing function in the fb code. Did you mean function
> drm_fb_helper_probe_connector_modes?
yes, via drm_fb_helper_initial_config()
>
>
>> > Graphic solutions in general have several connectors integrated, and it's
>> > sometimes really difficult to identify, which one of the does not work as
>> > expected, based on the logs. From above log we see, that a monitor is
>> > connected to DVI connector, nothing is connected to the VGA connector, and
>> > we have a problem with the HDMI connector. Without this fuinction, nothing
>> > helpful from radeon module would be in the logs.
>>
>> We should print the connector name in the generic drm error code then
>> if we want to print this info at boot time.
>
> Is there a place that is not called every ten seconds?
You could add logic to the fb probe code.
>
>>
>> >
>> > Maybe we can keep this function, but call it only for connectors, for which
>> > it works, i. e. not for DP, eDP and DP bridge connectors.
>>
>> That's just as bad. Users won't understand why only certain
>> connectors are probed.
>>
>> >
>> > Best regards
>> >
>> > Thomas Reim
>> >
>> > Am Dienstag, den 25.10.2011, 19:24 -0400 schrieb alexdeucher@gmail.com:
>> >
>> > From: Alex Deucher <alexander.deucher@amd.com>
>> >
>> > The function didn't work with DP, eDP, or DP bridge
>> > connectors and thus confused users as it lead them to
>> > believe nothing was connected or the EDID was invalid
>> > when in fact is was, just on the aux bus rather an i2c.
>> >
>> > It should also speed up module loading as it avoids a
>> > bunch of extra DDC probing.
>> >
>> > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>> > ---
>> > drivers/gpu/drm/radeon/radeon_display.c | 33
>> > -------------------------------
>> > 1 files changed, 0 insertions(+), 33 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/radeon/radeon_display.c
>> > b/drivers/gpu/drm/radeon/radeon_display.c
>> > index 6adb3e5..4998736 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_display.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_display.c
>> > @@ -33,8 +33,6 @@
>> > #include "drm_crtc_helper.h"
>> > #include "drm_edid.h"
>> >
>> > -static int radeon_ddc_dump(struct drm_connector *connector);
>> > -
>> > static void avivo_crtc_load_lut(struct drm_crtc *crtc)
>> > {
>> > struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
>> > @@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device
>> > *dev)
>> > static bool radeon_setup_enc_conn(struct drm_device *dev)
>> > {
>> > struct radeon_device *rdev = dev->dev_private;
>> > - struct drm_connector *drm_connector;
>> > bool ret = false;
>> >
>> > if (rdev->bios) {
>> > @@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device
>> > *dev)
>> > if (ret) {
>> > radeon_setup_encoder_clones(dev);
>> > radeon_print_display_setup(dev);
>> > - list_for_each_entry(drm_connector, &dev->mode_config.connector_list,
>> > head)
>> > - radeon_ddc_dump(drm_connector);
>> > }
>> >
>> > return ret;
>> > @@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector
>> > *radeon_connector)
>> > return 0;
>> > }
>> >
>> > -static int radeon_ddc_dump(struct drm_connector *connector)
>> > -{
>> > - struct edid *edid;
>> > - struct radeon_connector *radeon_connector =
>> > to_radeon_connector(connector);
>> > - int ret = 0;
>> > -
>> > - /* on hw with routers, select right port */
>> > - if (radeon_connector->router.ddc_valid)
>> > - radeon_router_select_ddc_port(radeon_connector);
>> > -
>> > - if (!radeon_connector->ddc_bus)
>> > - return -1;
>> > - edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
>> > - /* Log EDID retrieval status here. In particular with regard to
>> > - * connectors with requires_extended_probe flag set, that will prevent
>> > - * function radeon_dvi_detect() to fetch EDID on this connector,
>> > - * as long as there is no valid EDID header found */
>> > - if (edid) {
>> > - DRM_INFO("Radeon display connector %s: Found valid EDID",
>> > - drm_get_connector_name(connector));
>> > - kfree(edid);
>> > - } else {
>> > - DRM_INFO("Radeon display connector %s: No monitor connected or invalid
>> > EDID",
>> > - drm_get_connector_name(connector));
>> > - }
>> > - return ret;
>> > -}
>> > -
>> > /* avivo */
>> > static void avivo_get_fb_div(struct radeon_pll *pll,
>> > u32 target_clock,
>> >
>> >
>
>
^ permalink raw reply
* [PATCH] btrfs: add block plug for .writepages
From: Namjae Jeon @ 2011-10-31 15:45 UTC (permalink / raw)
To: chris.mason; +Cc: linux-kernel, Namjae Jeon
Add block plug for btrfs .writepages. Block plug is helpful to reduce block lock contention.
Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
---
fs/btrfs/extent_io.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index d418164..8f2d6bd 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2388,6 +2388,7 @@ static int extent_write_cache_pages(struct extent_io_tree *tree,
pgoff_t end; /* Inclusive */
int scanned = 0;
int tag;
+ struct blk_plug plug;
pagevec_init(&pvec, 0);
if (wbc->range_cyclic) {
@@ -2405,6 +2406,8 @@ static int extent_write_cache_pages(struct extent_io_tree *tree,
retry:
if (wbc->sync_mode == WB_SYNC_ALL)
tag_pages_for_writeback(mapping, index, end);
+
+ blk_start_plug(&plug);
while (!done && !nr_to_write_done && (index <= end) &&
(nr_pages = pagevec_lookup_tag(&pvec, mapping, &index, tag,
min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1))) {
@@ -2468,6 +2471,7 @@ retry:
pagevec_release(&pvec);
cond_resched();
}
+ blk_finish_plug(&plug);
if (!scanned && !done) {
/*
* We hit the last page and there is more work to be done: wrap
--
1.7.4.4
^ permalink raw reply related
* Re: [lm-sensors] [PATCH 3/3] hwmon: (w83627ehf) Add support for the
From: Guenter Roeck @ 2011-10-31 15:45 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20111031152342.15f99729@endymion.delvare>
On Mon, 2011-10-31 at 10:23 -0400, Jean Delvare wrote:
> This is essentially a stripped down version of the W83627DHG. Noticeable
> difference is that it is still powered with +5V, as older models, even
> though the ADC resolution is 8 mV as newer models have.
>
> Thanks to Ulf Bruman (Saab Group) for doing all the testing.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
> ---
> Hmm, I'm almost certain that I had originally prepared changes to
> Kconfig and the documentation file too, but apparently they got lost
> somewhere. I'll see if I can find a backup somewhere.
>
... assuming you'll add those.
Not sure if moving NCT677[56] to a separate driver would make much of a
difference in the complexity of this one.
Thanks,
Guenter
> drivers/hwmon/w83627ehf.c | 146 +++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 121 insertions(+), 25 deletions(-)
>
> --- linux-3.2-rc0.orig/drivers/hwmon/w83627ehf.c 2011-10-31 14:31:50.000000000 +0100
> +++ linux-3.2-rc0/drivers/hwmon/w83627ehf.c 2011-10-31 14:48:18.000000000 +0100
> @@ -39,6 +39,7 @@
> 0x8860 0xa1
> w83627dhg 9 5 4 3 0xa020 0xc1 0x5ca3
> w83627dhg-p 9 5 4 3 0xb070 0xc1 0x5ca3
> + w83627uhg 8 2 2 2 0xa230 0xc1 0x5ca3
> w83667hg 9 5 3 3 0xa510 0xc1 0x5ca3
> w83667hg-b 9 5 3 4 0xb350 0xc1 0x5ca3
> nct6775f 9 4 3 9 0xb470 0xc1 0x5ca3
> @@ -61,14 +62,17 @@
> #include <linux/io.h>
> #include "lm75.h"
>
> -enum kinds { w83627ehf, w83627dhg, w83627dhg_p, w83667hg, w83667hg_b, nct6775,
> - nct6776 };
> +enum kinds {
> + w83627ehf, w83627dhg, w83627dhg_p, w83627uhg,
> + w83667hg, w83667hg_b, nct6775, nct6776,
> +};
>
> /* used to set data->name = w83627ehf_device_names[data->sio_kind] */
> static const char * const w83627ehf_device_names[] = {
> "w83627ehf",
> "w83627dhg",
> "w83627dhg",
> + "w83627uhg",
> "w83667hg",
> "w83667hg",
> "nct6775",
> @@ -104,6 +108,7 @@ MODULE_PARM_DESC(fan_debounce, "Enable d
> #define SIO_W83627EHG_ID 0x8860
> #define SIO_W83627DHG_ID 0xa020
> #define SIO_W83627DHG_P_ID 0xb070
> +#define SIO_W83627UHG_ID 0xa230
> #define SIO_W83667HG_ID 0xa510
> #define SIO_W83667HG_B_ID 0xb350
> #define SIO_NCT6775_ID 0xb470
> @@ -388,18 +393,23 @@ div_from_reg(u8 reg)
> return 1 << reg;
> }
>
> -/* Some of analog inputs have internal scaling (2x), 8mV is ADC LSB */
> -
> -static u8 scale_in[10] = { 8, 8, 16, 16, 8, 8, 8, 16, 16, 8 };
> +/* Some of the voltage inputs have internal scaling, the tables below
> + * contain 8 (the ADC LSB in mV) * scaling factor * 100 */
> +static const u16 scale_in_common[10] = {
> + 800, 800, 1600, 1600, 800, 800, 800, 1600, 1600, 800
> +};
> +static const u16 scale_in_w83627uhg[9] = {
> + 800, 800, 3328, 3424, 800, 800, 0, 3328, 3400
> +};
>
> -static inline long in_from_reg(u8 reg, u8 nr)
> +static inline long in_from_reg(u8 reg, u8 nr, const u16 *scale_in)
> {
> - return reg * scale_in[nr];
> + return DIV_ROUND_CLOSEST(reg * scale_in[nr], 100);
> }
>
> -static inline u8 in_to_reg(u32 val, u8 nr)
> +static inline u8 in_to_reg(u32 val, u8 nr, const u16 *scale_in)
> {
> - return SENSORS_LIMIT(((val + (scale_in[nr] / 2)) / scale_in[nr]), 0,
> + return SENSORS_LIMIT(DIV_ROUND_CLOSEST(val * 100, scale_in[nr]), 0,
> 255);
> }
>
> @@ -430,6 +440,7 @@ struct w83627ehf_data {
> const u16 *REG_FAN_STOP_TIME;
> const u16 *REG_FAN_MAX_OUTPUT;
> const u16 *REG_FAN_STEP_OUTPUT;
> + const u16 *scale_in;
>
> unsigned int (*fan_from_reg)(u16 reg, unsigned int divreg);
> unsigned int (*fan_from_reg_min)(u16 reg, unsigned int divreg);
> @@ -481,7 +492,8 @@ struct w83627ehf_data {
> u8 vrm;
>
> u16 have_temp;
> - u8 in6_skip;
> + u8 in6_skip:1;
> + u8 temp3_val_only:1;
> };
>
> struct w83627ehf_sio_data {
> @@ -907,7 +919,8 @@ show_##reg(struct device *dev, struct de
> struct sensor_device_attribute *sensor_attr = \
> to_sensor_dev_attr(attr); \
> int nr = sensor_attr->index; \
> - return sprintf(buf, "%ld\n", in_from_reg(data->reg[nr], nr)); \
> + return sprintf(buf, "%ld\n", in_from_reg(data->reg[nr], nr, \
> + data->scale_in)); \
> }
> show_in_reg(in)
> show_in_reg(in_min)
> @@ -928,7 +941,7 @@ store_in_##reg(struct device *dev, struc
> if (err < 0) \
> return err; \
> mutex_lock(&data->update_lock); \
> - data->in_##reg[nr] = in_to_reg(val, nr); \
> + data->in_##reg[nr] = in_to_reg(val, nr, data->scale_in); \
> w83627ehf_write_value(data, W83627EHF_REG_IN_##REG(nr), \
> data->in_##reg[nr]); \
> mutex_unlock(&data->update_lock); \
> @@ -1617,25 +1630,28 @@ static struct sensor_device_attribute sd
> store_fan_step_output, 3),
> };
>
> +static struct sensor_device_attribute sda_sf3_arrays_fan3[] = {
> + SENSOR_ATTR(pwm3_stop_time, S_IWUSR | S_IRUGO, show_fan_stop_time,
> + store_fan_stop_time, 2),
> + SENSOR_ATTR(pwm3_start_output, S_IWUSR | S_IRUGO, show_fan_start_output,
> + store_fan_start_output, 2),
> + SENSOR_ATTR(pwm3_stop_output, S_IWUSR | S_IRUGO, show_fan_stop_output,
> + store_fan_stop_output, 2),
> +};
> +
> static struct sensor_device_attribute sda_sf3_arrays[] = {
> SENSOR_ATTR(pwm1_stop_time, S_IWUSR | S_IRUGO, show_fan_stop_time,
> store_fan_stop_time, 0),
> SENSOR_ATTR(pwm2_stop_time, S_IWUSR | S_IRUGO, show_fan_stop_time,
> store_fan_stop_time, 1),
> - SENSOR_ATTR(pwm3_stop_time, S_IWUSR | S_IRUGO, show_fan_stop_time,
> - store_fan_stop_time, 2),
> SENSOR_ATTR(pwm1_start_output, S_IWUSR | S_IRUGO, show_fan_start_output,
> store_fan_start_output, 0),
> SENSOR_ATTR(pwm2_start_output, S_IWUSR | S_IRUGO, show_fan_start_output,
> store_fan_start_output, 1),
> - SENSOR_ATTR(pwm3_start_output, S_IWUSR | S_IRUGO, show_fan_start_output,
> - store_fan_start_output, 2),
> SENSOR_ATTR(pwm1_stop_output, S_IWUSR | S_IRUGO, show_fan_stop_output,
> store_fan_stop_output, 0),
> SENSOR_ATTR(pwm2_stop_output, S_IWUSR | S_IRUGO, show_fan_stop_output,
> store_fan_stop_output, 1),
> - SENSOR_ATTR(pwm3_stop_output, S_IWUSR | S_IRUGO, show_fan_stop_output,
> - store_fan_stop_output, 2),
> };
>
>
> @@ -1728,6 +1744,8 @@ static void w83627ehf_device_remove_file
> data->REG_FAN_STEP_OUTPUT[attr->index] != 0xff)
> device_remove_file(dev, &attr->dev_attr);
> }
> + for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan3); i++)
> + device_remove_file(dev, &sda_sf3_arrays_fan3[i].dev_attr);
> for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan4); i++)
> device_remove_file(dev, &sda_sf3_arrays_fan4[i].dev_attr);
> for (i = 0; i < data->in_num; i++) {
> @@ -1756,6 +1774,8 @@ static void w83627ehf_device_remove_file
> continue;
> device_remove_file(dev, &sda_temp_input[i].dev_attr);
> device_remove_file(dev, &sda_temp_label[i].dev_attr);
> + if (i = 2 && data->temp3_val_only)
> + continue;
> device_remove_file(dev, &sda_temp_max[i].dev_attr);
> device_remove_file(dev, &sda_temp_max_hyst[i].dev_attr);
> if (i > 2)
> @@ -1808,6 +1828,9 @@ static inline void __devinit w83627ehf_i
> case w83627ehf:
> diode = w83627ehf_read_value(data, W83627EHF_REG_DIODE);
> break;
> + case w83627uhg:
> + diode = 0x00;
> + break;
> default:
> diode = 0x70;
> }
> @@ -1871,6 +1894,13 @@ w83627ehf_check_fan_inputs(const struct
> {
> int fan3pin, fan4pin, fan4min, fan5pin, regval;
>
> + /* The W83627UHG is simple, only two fan inputs, no config */
> + if (sio_data->kind = w83627uhg) {
> + data->has_fan = 0x03; /* fan1 and fan2 */
> + data->has_fan_min = 0x03;
> + return;
> + }
> +
> superio_enter(sio_data->sioreg);
>
> /* fan4 and fan5 share some pins with the GPIO and serial flash */
> @@ -1962,11 +1992,21 @@ static int __devinit w83627ehf_probe(str
>
> /* 627EHG and 627EHF have 10 voltage inputs; 627DHG and 667HG have 9 */
> data->in_num = (sio_data->kind = w83627ehf) ? 10 : 9;
> - /* 667HG, NCT6775F, and NCT6776F have 3 pwms */
> - data->pwm_num = (sio_data->kind = w83667hg
> - || sio_data->kind = w83667hg_b
> - || sio_data->kind = nct6775
> - || sio_data->kind = nct6776) ? 3 : 4;
> + /* 667HG, NCT6775F, and NCT6776F have 3 pwms, and 627UHG has only 2 */
> + switch (sio_data->kind) {
> + default:
> + data->pwm_num = 4;
> + break;
> + case w83667hg:
> + case w83667hg_b:
> + case nct6775:
> + case nct6776:
> + data->pwm_num = 3;
> + break;
> + case w83627uhg:
> + data->pwm_num = 2;
> + break;
> + }
>
> /* Default to 3 temperature inputs, code below will adjust as needed */
> data->have_temp = 0x07;
> @@ -2085,6 +2125,42 @@ static int __devinit w83627ehf_probe(str
> data->in6_skip = 1;
>
> data->temp_label = w83667hg_b_temp_label;
> + } else if (sio_data->kind = w83627uhg) {
> + u8 reg;
> +
> + w83627ehf_set_temp_reg_ehf(data, 3);
> +
> + /*
> + * Temperature sources for temp1 and temp2 are selected with
> + * bank 0, registers 0x49 and 0x4a.
> + */
> + data->temp_src[0] = 0; /* SYSTIN */
> + reg = w83627ehf_read_value(data, 0x49) & 0x07;
> + /* Adjust to have the same mapping as other source registers */
> + if (reg = 0)
> + data->temp_src[1]++;
> + else if (reg >= 2 && reg <= 5)
> + data->temp_src[1] += 2;
> + else /* should never happen */
> + data->have_temp &= ~(1 << 1);
> + reg = w83627ehf_read_value(data, 0x4a);
> + data->temp_src[2] = reg >> 5;
> +
> + /*
> + * Skip temp3 if source is invalid or the same as temp1
> + * or temp2.
> + */
> + if (data->temp_src[2] = 2 || data->temp_src[2] = 3 ||
> + data->temp_src[2] = data->temp_src[0] ||
> + ((data->have_temp & (1 << 1)) &&
> + data->temp_src[2] = data->temp_src[1]))
> + data->have_temp &= ~(1 << 2);
> + else
> + data->temp3_val_only = 1; /* No limit regs */
> +
> + data->in6_skip = 1; /* No VIN3 */
> +
> + data->temp_label = w83667hg_b_temp_label;
> } else {
> w83627ehf_set_temp_reg_ehf(data, 3);
>
> @@ -2162,6 +2238,12 @@ static int __devinit w83627ehf_probe(str
> W83627EHF_REG_FAN_STEP_OUTPUT_COMMON;
> }
>
> + /* Setup input voltage scaling factors */
> + if (sio_data->kind = w83627uhg)
> + data->scale_in = scale_in_w83627uhg;
> + else
> + data->scale_in = scale_in_common;
> +
> /* Initialize the chip */
> w83627ehf_init_device(data, sio_data->kind);
>
> @@ -2178,7 +2260,7 @@ static int __devinit w83627ehf_probe(str
> err = device_create_file(dev, &dev_attr_cpu0_vid);
> if (err)
> goto exit_release;
> - } else {
> + } else if (sio_data->kind != w83627uhg) {
> superio_select(sio_data->sioreg, W83627EHF_LD_HWM);
> if (superio_inb(sio_data->sioreg, SIO_REG_VID_CTRL) & 0x80) {
> /* Set VID input sensibility if needed. In theory the
> @@ -2268,7 +2350,14 @@ static int __devinit w83627ehf_probe(str
> goto exit_remove;
> }
> }
> - /* if fan4 is enabled create the sf3 files for it */
> + /* if fan3 and fan4 are enabled create the sf3 files for them */
> + if ((data->has_fan & (1 << 2)) && data->pwm_num >= 3)
> + for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan3); i++) {
> + err = device_create_file(dev,
> + &sda_sf3_arrays_fan3[i].dev_attr);
> + if (err)
> + goto exit_remove;
> + }
> if ((data->has_fan & (1 << 3)) && data->pwm_num >= 4)
> for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan4); i++) {
> err = device_create_file(dev,
> @@ -2336,6 +2425,8 @@ static int __devinit w83627ehf_probe(str
> if (err)
> goto exit_remove;
> }
> + if (i = 2 && data->temp3_val_only)
> + continue;
> if (data->reg_temp_over[i]) {
> err = device_create_file(dev,
> &sda_temp_max[i].dev_attr);
> @@ -2419,6 +2510,7 @@ static int __init w83627ehf_find(int sio
> static const char __initdata sio_name_W83627EHG[] = "W83627EHG";
> static const char __initdata sio_name_W83627DHG[] = "W83627DHG";
> static const char __initdata sio_name_W83627DHG_P[] = "W83627DHG-P";
> + static const char __initdata sio_name_W83627UHG[] = "W83627UHG";
> static const char __initdata sio_name_W83667HG[] = "W83667HG";
> static const char __initdata sio_name_W83667HG_B[] = "W83667HG-B";
> static const char __initdata sio_name_NCT6775[] = "NCT6775F";
> @@ -2451,6 +2543,10 @@ static int __init w83627ehf_find(int sio
> sio_data->kind = w83627dhg_p;
> sio_name = sio_name_W83627DHG_P;
> break;
> + case SIO_W83627UHG_ID:
> + sio_data->kind = w83627uhg;
> + sio_name = sio_name_W83627UHG;
> + break;
> case SIO_W83667HG_ID:
> sio_data->kind = w83667hg;
> sio_name = sio_name_W83667HG;
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: linux-next 20111025: warnings in rcu_idle_exit_common()/rcu_idle_enter_common()
From: Steven Rostedt @ 2011-10-31 15:44 UTC (permalink / raw)
To: paulmck
Cc: Wu Fengguang, linux-kernel@vger.kernel.org, Ingo Molnar,
Lai Jiangshan, Frederic Weisbecker, Carsten Emde
In-Reply-To: <20111031121951.GM6160@linux.vnet.ibm.com>
On Mon, 2011-10-31 at 05:19 -0700, Paul E. McKenney wrote:
> On Mon, Oct 31, 2011 at 07:41:42PM +0800, Wu Fengguang wrote:
> > On Mon, Oct 31, 2011 at 06:43:25PM +0800, Wu Fengguang wrote:
> > > On Mon, Oct 31, 2011 at 05:51:52PM +0800, Paul E. McKenney wrote:
> > > > On Mon, Oct 31, 2011 at 04:26:34PM +0800, Wu Fengguang wrote:
> > > > > Hi Paul,
> > > > >
> > > > > I got two warnings in rcutree.c. The last working kernels are
> > > > > linux-next 20111014 and linux v3.1.
> > > >
> > > > Interesting. Could you please enable RCU event tracing at boot?
> > >
> > > Sorry I cannot...possibly due to another ftrace bug.
> > >
> > > > The RCU event tracing is at tracing/events/rcu/enable relative to
> > > > the debugfs mount point at runtime, if that helps.
> > >
> > > It's exactly that linux next 20111025 (comparing to 20111014) no
> > > longer produces all the trace events that made me looking into the
> > > dmesg and find the warning from RCU (rather than the expected warning
> > > from ftrace).
> > >
> > > The trace output is now:
> > >
> > > # tracer: nop
> > > #
> > > # WARNING: FUNCTION TRACING IS CORRUPTED
> > > # MAY BE MISSING FUNCTION EVENTS
> > > # TASK-PID CPU# TIMESTAMP FUNCTION
> > > # | | | | |
> > > (nothing more)
> >
> > I checked the other test box and got the same warnings. Below is the
> > full dmesg.
> >
> > No single trace output again..
>
> Hmmm... I wonder if it is too early during boot for tracing to work
> correctly.
>
> Gah! I have rcu/next set ahead to commits that are not supposed to go
> upstream yet. I reset it back to match the stuff that is targeted for
> the current merge window. Still need to find the bug, of course.
>
> Anyone have any idea why the kworker thread might be trying to enter
> the idle loop? The idle_cpu(smp_processor_id()) call believes that
> this is not the idle task. Or does x86 allow non-idle tasks to enter
> the idle loop? Or to be migrated off-CPU?
It's not. Carsten Emde noticed what looked like a bug in ftrace last
week at LinuxCon, and looking deeper at it, I found that the swapper
task for all but CPU0 is named kworker. That's because kworker creates
the idle task for all other CPUs besides CPU 0 and the idle task takes
on kworker name.
Carsten posted a patch last week too:
https://lkml.org/lkml/2011/10/26/313
I'm glad that this bug shows up outside of just ftrace :)
-- Steve
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Error check find_ram_offset
From: Markus Armbruster @ 2011-10-31 15:42 UTC (permalink / raw)
To: Alex Williamson; +Cc: Blue Swirl, qemu-devel
In-Reply-To: <20111031145311.13723.63607.stgit@s20.home>
Alex Williamson <alex.williamson@redhat.com> writes:
> Spotted via code review, we initialize offset to 0 to avoid a
> compiler warning, but in the unlikely case that offset is
> never set to something else, we should abort instead of return
> a value that will almost certainly cause problems.
Compiler warning pointed to the problem until commit 09d7ae90 "Fix
warning about uninitialized variable" papered over it.
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>
> exec.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 9dc4edb..70f6fb8 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2874,7 +2874,7 @@ static void *file_ram_alloc(RAMBlock *block,
> static ram_addr_t find_ram_offset(ram_addr_t size)
> {
> RAMBlock *block, *next_block;
> - ram_addr_t offset = 0, mingap = RAM_ADDR_MAX;
> + ram_addr_t offset = RAM_ADDR_MAX, mingap = RAM_ADDR_MAX;
>
> if (QLIST_EMPTY(&ram_list.blocks))
> return 0;
> @@ -2890,10 +2890,17 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
> }
> }
> if (next - end >= size && next - end < mingap) {
> - offset = end;
> + offset = end;
> mingap = next - end;
> }
> }
> +
> + if (offset == RAM_ADDR_MAX) {
> + fprintf(stderr, "Failed to find gap of requested size: %" PRIu64 "\n",
> + (uint64_t)size);
> + abort();
> + }
> +
> return offset;
> }
The loop can't yield offset RAM_ADDR_MAX, because size needs to be zero
for next - end >= size to succeed, and that's not possible.
Reviewed-by: Markus Armbruster <armbru@redhat.com>
^ permalink raw reply
* Re: [patch 07/66] btrfs: clear_extent_bit error push-up [other BUG hit]
From: David Sterba @ 2011-10-31 15:41 UTC (permalink / raw)
To: Jeff Mahoney, Chris Mason, David Sterba, Linux Btrfs
In-Reply-To: <20111031150754.GE19328@twin.jikos.cz>
[18300.906594] ------------[ cut here ]------------
[18300.910518] kernel BUG at fs/btrfs/inode.c:1592!
[18300.910518] invalid opcode: 0000 [#1] SMP
[18300.910518] CPU 1
[18300.910518] Modules linked in: btrfs loop aoe [last unloaded: btrfs]
[18300.910518]
[18300.910518] Pid: 1853, comm: btrfs-fixup-0 Tainted: G W 3.1.0-rc9-default+ #63 Intel Corporation Santa Rosa platform/Matanzas
[18300.910518] RIP: 0010:[<ffffffffa017a8f2>] [<ffffffffa017a8f2>] btrfs_writepage_fixup_worker+0x152/0x160 [btrfs]
[18300.910518] RSP: 0018:ffff880000095da0 EFLAGS: 00010246
[18300.910518] RAX: 0000000000000000 RBX: ffff88007d8894f8 RCX: ffff880075e3a928
[18300.910518] RDX: 0000000000005958 RSI: 0000000000000001 RDI: ffff8800431fbad8
[18300.910518] RBP: ffff880000095df0 R08: 0000000000000000 R09: 0000000000000000
[18300.910518] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000306000
[18300.910518] R13: ffff8800431fbbe8 R14: 0000000000000000 R15: 0000000000306fff
[18300.910518] FS: 0000000000000000(0000) GS:ffff88007e600000(0000) knlGS:0000000000000000
[18300.910518] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[18300.910518] CR2: 00007fe2024f9000 CR3: 0000000064037000 CR4: 00000000000006e0
[18300.910518] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[18300.910518] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[18300.910518] Process btrfs-fixup-0 (pid: 1853, threadinfo ffff880000094000, task ffff88000e3f4d80)
[18300.910518] Stack:
[18300.910518] ffff88007947fbc0 ffff8800431fb8b0 ffff88007940b190 ffff8800689b7c38
[18300.910518] ffff880000095dd0 ffff88007940b140 ffff88007947fbf0 ffff88007940b158
[18300.910518] ffff880000095e40 ffff88007940b190 ffff880000095ea0 ffffffffa01a1e34
[18300.910518] Call Trace:
[18300.910518] [<ffffffffa01a1e34>] worker_loop+0xb4/0x520 [btrfs]
[18300.910518] [<ffffffffa01a1d80>] ? btrfs_queue_worker+0x330/0x330 [btrfs]
[18300.910518] [<ffffffff8107cf26>] kthread+0xa6/0xb0
[18300.910518] [<ffffffff81a1e584>] kernel_thread_helper+0x4/0x10
[18300.910518] [<ffffffff81a146e0>] ? _raw_spin_unlock_irq+0x30/0x40
[18300.910518] [<ffffffff81097c7d>] ? trace_hardirqs_on+0xd/0x10
[18300.910518] [<ffffffff81a14eb4>] ? retint_restore_args+0x13/0x13
[18300.910518] [<ffffffff8107ce80>] ? __init_kthread_worker+0x70/0x70
[18300.910518] [<ffffffff81a1e580>] ? gs_change+0x13/0x13
[18300.910518] Code: 00 48 8b 7d b8 48 8d 4d c8 41 b8 50 00 00 00 4c 89 fa 4c 89 e6 e8 6f a3 01 00 eb b6 0f 0b 48 89 df e8 b3 dd f7 e0 0f 1f 00 eb 95 <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 41
[18300.910518] RIP [<ffffffffa017a8f2>] btrfs_writepage_fixup_worker+0x152/0x160 [btrfs]
[18300.910518] RSP <ffff880000095da0>
[18301.262194] ---[ end trace de089b9ceb00d1b9 ]---
1583 ordered = btrfs_lookup_ordered_extent(inode, page_start);
1584 if (ordered) {
1585 unlock_extent_cached(&BTRFS_I(inode)->io_tree, page_start,
1586 page_end, &cached_state, GFP_NOFS);
1587 unlock_page(page);
1588 btrfs_start_ordered_extent(inode, ordered, 1);
1589 goto again;
1590 }
1591
1592 BUG();
1593 ret = btrfs_set_extent_delalloc(inode, page_start, page_end,
1594 &cached_state);
1595 BUG_ON(ret < 0);
1596 ClearPageChecked(page);
1597 out:
1598 unlock_extent_cached(&BTRFS_I(inode)->io_tree, page_start, page_end,
1599 &cached_state, GFP_NOFS);
1600 out_page:
1601 unlock_page(page);
1602 page_cache_release(page);
1603 kfree(fixup);
1604 }
during xfstests/209 (and 10 seconds after I sent the previous mail of course).
david
^ 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
^ 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.