[PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
Add clock, data and clear signal GPIO lines to control seven segment display on zaius platform. Signed-off-by: Jaghathiswari Rankappagounder Natarajan --- arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts index 8ef4ece..ccb8147 100644 --- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts +++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts @@ -43,6 +43,14 @@ gpios = <&gpio ASPEED_GPIO(H, 7) GPIO_ACTIVE_LOW>; }; }; + + seven-seg-disp { + compatible = "seven-seg-gpio-dev"; + refresh-interval-ms = "1000"; + clock-gpios = <&gpio ASPEED_GPIO(J, 0) GPIO_ACTIVE_HIGH>; + data-gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_HIGH>; + clear-gpios = <&gpio ASPEED_GPIO(J, 1) GPIO_ACTIVE_HIGH>; + }; }; &fmc { -- 2.8.0.rc3.226.g39d4020
[PATCH] vhost: introduce O(1) vq metadata cache
When device IOTLB is enabled, all address translations were stored in interval tree. O(lgN) searching time could be slow for virtqueue metadata (avail, used and descriptors) since they were accessed much often than other addresses. So this patch introduces an O(1) array which points to the interval tree nodes that store the translations of vq metadata. Those array were update during vq IOTLB prefetching and were reset during each invalidation and tlb update. Each time we want to access vq metadata, this small array were queried before interval tree. This would be sufficient for static mappings but not dynamic mappings, we could do optimizations on top. Test were done with l2fwd in guest (2M hugepage): noiommu | before| after tx 1.32Mpps | 1.06Mpps(82%) | 1.30Mpps(98%) rx 2.33Mpps | 1.46Mpps(63%) | 2.29Mpps(98%) We can almost reach the same performance as noiommu mode. Signed-off-by: Jason Wang --- drivers/vhost/vhost.c | 136 -- drivers/vhost/vhost.h | 8 +++ 2 files changed, 118 insertions(+), 26 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c6f2d89..89e40b6 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -282,6 +282,22 @@ void vhost_poll_queue(struct vhost_poll *poll) } EXPORT_SYMBOL_GPL(vhost_poll_queue); +static void __vhost_vq_meta_reset(struct vhost_virtqueue *vq) +{ + int j; + + for (j = 0; j < VHOST_NUM_ADDRS; j++) + vq->meta_iotlb[j] = NULL; +} + +static void vhost_vq_meta_reset(struct vhost_dev *d) +{ + int i; + + for (i = 0; i < d->nvqs; ++i) + __vhost_vq_meta_reset(d->vqs[i]); +} + static void vhost_vq_reset(struct vhost_dev *dev, struct vhost_virtqueue *vq) { @@ -311,6 +327,7 @@ static void vhost_vq_reset(struct vhost_dev *dev, vq->busyloop_timeout = 0; vq->umem = NULL; vq->iotlb = NULL; + __vhost_vq_meta_reset(vq); } static int vhost_worker(void *data) @@ -690,6 +707,18 @@ static int vq_memory_access_ok(void __user *log_base, struct vhost_umem *umem, return 1; } +static inline void __user *vhost_vq_meta_fetch(struct vhost_virtqueue *vq, + u64 addr, unsigned int size, + int type) +{ + const struct vhost_umem_node *node = vq->meta_iotlb[type]; + + if (!node) + return NULL; + + return (void *)(node->userspace_addr + (u64)addr - node->start); +} + /* Can we switch to this memory table? */ /* Caller should have device mutex but not vq mutex */ static int memory_access_ok(struct vhost_dev *d, struct vhost_umem *umem, @@ -732,8 +761,14 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void *to, * could be access through iotlb. So -EAGAIN should * not happen in this case. */ - /* TODO: more fast path */ struct iov_iter t; + void __user *uaddr = vhost_vq_meta_fetch(vq, +(u64)(uintptr_t)to, size, +VHOST_ADDR_DESC); + + if (uaddr) + return __copy_to_user(uaddr, from, size); + ret = translate_desc(vq, (u64)(uintptr_t)to, size, vq->iotlb_iov, ARRAY_SIZE(vq->iotlb_iov), VHOST_ACCESS_WO); @@ -761,8 +796,14 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to, * could be access through iotlb. So -EAGAIN should * not happen in this case. */ - /* TODO: more fast path */ + void __user *uaddr = vhost_vq_meta_fetch(vq, +(u64)(uintptr_t)from, size, +VHOST_ADDR_DESC); struct iov_iter f; + + if (uaddr) + return __copy_from_user(to, uaddr, size); + ret = translate_desc(vq, (u64)(uintptr_t)from, size, vq->iotlb_iov, ARRAY_SIZE(vq->iotlb_iov), VHOST_ACCESS_RO); @@ -782,17 +823,12 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to, return ret; } -static void __user *__vhost_get_user(struct vhost_virtqueue *vq, -void *addr, unsigned size) +static void __user *__vhost_get_user_slow(struct vhost_virtqueue *vq, + void *addr, unsigned int size, + int type) { int ret; - /* This function should be called after iotlb -* prefetch, which means we're sure that vq -* could be access through iotlb. So -EAGAIN should -* not happen in this case. -*/ - /* TODO
[PATCH linux v1 2/4] drivers: misc: Character device driver for seven segment display
Character device driver which implements the user-space API for letting a user write to two 7-segment displays including any conversion methods necessary to map the user input to two 7-segment displays. Signed-off-by: Jaghathiswari Rankappagounder Natarajan --- drivers/misc/Kconfig | 8 ++ drivers/misc/Makefile | 1 + drivers/misc/seven_seg_disp.c | 197 ++ drivers/misc/seven_seg_disp.h | 34 4 files changed, 240 insertions(+) create mode 100644 drivers/misc/seven_seg_disp.c create mode 100644 drivers/misc/seven_seg_disp.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index a216b46..a21aec1 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -791,6 +791,14 @@ config PANEL_CHANGE_MESSAGE If you say 'Y' here, you'll be able to choose a message yourself. Otherwise, say 'N' and keep the default message with the version. +config SEVEN_SEGMENT_DISPLAY + tristate "Character driver for seven segment display support" + help + Character device driver which implements the user-space + API for letting a user write to two 7-segment displays including + any conversion methods necessary to map the user input + to two 7-segment displays. + config PANEL_BOOT_MESSAGE depends on PANEL && PANEL_CHANGE_MESSAGE="y" string "New initialization message" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index b2fb6dbf..c2defbd 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -56,4 +56,5 @@ obj-$(CONFIG_GENWQE) += genwqe/ obj-$(CONFIG_ECHO) += echo/ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o obj-$(CONFIG_CXL_BASE) += cxl/ +obj-$(CONFIG_SEVEN_SEGMENT_DISPLAY)+= seven_seg_disp.o obj-$(CONFIG_PANEL) += panel.o diff --git a/drivers/misc/seven_seg_disp.c b/drivers/misc/seven_seg_disp.c new file mode 100644 index 000..4daeac5 --- /dev/null +++ b/drivers/misc/seven_seg_disp.c @@ -0,0 +1,197 @@ +/* + * Copyright (c) 2016 Google, Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 or later as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "seven_seg_disp.h" + +#define LED_DOT 0x01 + +/* + * 0 1 2 3 4 5 6 7 8 9 A B C D E F + * _ _ _ _ _ _ _ _ _ _ _ _ + * | | | _| _| |_| |_ |_| |_| |_| |_| |_ |_| |_ |_ + * |_| | |_ _| | _| |_| | |_| | | | |_| |_ |_| |_ | + * + * data[7:1] = led[a:g] + */ +const u8 seven_seg_bits[] = { + 0xFC, 0x60, 0xDA, 0xF2, 0x66, 0xB6, 0xBE, 0xE0, + 0xFE, 0xF6, 0xEE, 0x3E, 0x9C, 0x7A, 0x9E, 0x8E + }; + +/* + * 0 1 2 3 4 5 6 7 8 9 A B C D E F + * _ _ _ __ + * | |_ |_| |_ _ _ _ _ _ _ _ |__| _| | | + * |_ |_ | | _| |_| |_| | | + * + * data[7:1] = led[a:g] + */ +const u8 special_seven_seg_bits[] = { + 0x00, 0x9C, 0x1E, 0xCE, 0x8E, 0x02, 0x02, 0x02, + 0x02, 0x02, 0x02, 0x02, 0xB6, 0x7A, 0x7A, 0xEC + }; + +static dev_t seven_seg_devno; +static struct class *seven_seg_disp_class; + +static int seven_seg_disp_open(struct inode *inode, struct file *filp) +{ + struct seven_seg_disp_dev *disp_dev; + + disp_dev = container_of(inode->i_cdev, +struct seven_seg_disp_dev, cdev); + filp->private_data = disp_dev; + return 0; +} + +static int seven_seg_disp_close(struct inode *inode, struct file *filp) +{ + filp->private_data = NULL; + return 0; +} + +static ssize_t seven_seg_disp_read(struct file *filp, char __user *buf, size_t + len, loff_t *off) +{ + struct seven_seg_disp_dev *disp_dev = filp->private_data; + + if (disp_dev->disp_data_valid) + return -EINVAL; + + if (copy_to_user(buf, disp_dev->seven_seg_disp_data_array, + MAX_DISP_CHAR_SIZE) != 0) { + return -EFAULT; + } + + return 0; +} + +static u16 convert_to_disp_data(char *buf) +{ + u8 low_display; + u8 high_display; + u16 led_value; + + low_display = seven_seg_bits[hex_to_bin(buf[2])]; + + high_display = (buf[0] == '1') ? + special_seven_seg_bits[hex_to_bin(buf[1])] : + seven_seg_bits[hex_to_bin(buf[1])]; + + led_value = low_display | (high_display << 8); + if (buf[0] == '1') + led_value |= LED_DOT | (LED_DOT << 8); + + return led_value; +} + +static ssize_t seven_seg_disp_write(struct file *filp, const char __user *buf, +
[PATCH linux v1 3/4] drivers: misc: Platform driver for seven segment display support
Platform device driver which provides an API for displaying on two 7-segment displays, and implements the required bit-banging. The hardware assumed is 74HC164 wired to two 7-segment displays. Signed-off-by: Jaghathiswari Rankappagounder Natarajan --- drivers/misc/Kconfig | 8 ++ drivers/misc/Makefile | 1 + drivers/misc/seven_seg_gpio.c | 206 ++ 3 files changed, 215 insertions(+) create mode 100644 drivers/misc/seven_seg_gpio.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index a21aec1..6508108 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -812,6 +812,14 @@ config PANEL_BOOT_MESSAGE An empty message will only clear the display at driver init time. Any other printf()-formatted message is valid with newline and escape codes. +config SEVEN_SEGMENT_GPIO + tristate "Platform driver to update seven segment display" + depends on SEVEN_SEGMENT_DISPLAY + help + Platform device driver which provides an API for displaying on two + 7-segment displays, and implements the required bit-banging. + The hardware assumed is 74HC164 wired to two 7-segment displays. + source "drivers/misc/c2port/Kconfig" source "drivers/misc/eeprom/Kconfig" source "drivers/misc/cb710/Kconfig" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index c2defbd..d9c0d20 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -58,3 +58,4 @@ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o obj-$(CONFIG_CXL_BASE) += cxl/ obj-$(CONFIG_SEVEN_SEGMENT_DISPLAY)+= seven_seg_disp.o obj-$(CONFIG_PANEL) += panel.o +obj-$(CONFIG_SEVEN_SEGMENT_GPIO) += seven_seg_gpio.o diff --git a/drivers/misc/seven_seg_gpio.c b/drivers/misc/seven_seg_gpio.c new file mode 100644 index 000..3dcb903 --- /dev/null +++ b/drivers/misc/seven_seg_gpio.c @@ -0,0 +1,206 @@ +/* + * Copyright (C) 2016 Google, Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 or later as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "seven_seg_disp.h" + +#define DELAY_INTVL_US 1 + +#define CLOCK_GPIO_NAME "clock" +#define DATA_GPIO_NAME "data" +#define CLEAR_GPIO_NAME "clear" + +struct seven_seg_gpio_info { + u16 curr_disp_value; + u16 refresh_interval; + struct timer_list update_timer; + struct gpio_desc *clock_gpio; + struct gpio_desc *data_gpio; + struct gpio_desc *clear_gpio; +}; + +static void update_seven_seg_gpio_data(struct device *dev, u16 data) +{ + struct platform_device *pdev; + struct seven_seg_gpio_info *gpio_info; + + pdev = container_of(dev, struct platform_device, dev); + if (pdev == NULL) { + pr_err("invalid NULL platform_device\n"); + return; + } + + gpio_info = platform_get_drvdata(pdev); + if (gpio_info == NULL) { + pr_err("invalid NULL gpio_info\n"); + return; + } + + gpio_info->curr_disp_value = data; +} + +static void clear_seven_seg_gpio_data(struct device *dev, u16 data) +{ + struct platform_device *pdev; + struct seven_seg_gpio_info *gpio_info; + + pdev = container_of(dev, struct platform_device, dev); + if (pdev == NULL) { + pr_err("invalid NULL platform_device\n"); + return; + } + + gpio_info = platform_get_drvdata(pdev); + if (gpio_info == NULL) { + pr_err("invalid NULL gpio_info\n"); + return; + } + + gpio_info->curr_disp_value = 0; +} + +static void send_seven_seg_gpio_data(u16 disp_data, + struct seven_seg_gpio_info *gpio_info) +{ + int i; + + gpiod_set_value(gpio_info->clear_gpio, 0); + udelay(DELAY_INTVL_US); + gpiod_set_value(gpio_info->clear_gpio, 1); + udelay(DELAY_INTVL_US); + + for (i = 0; i < 16; i++) { + if (disp_data & 0x01) + gpiod_set_value(gpio_info->data_gpio, 1); + else + gpiod_set_value(gpio_info->data_gpio, 0); + + udelay(DELAY_INTVL_US); + + gpiod_set_value(gpio_info->clock_gpio, 0); + udelay(DELAY_INTVL_US); + gpiod_set_value(gpio_info->clock_gpio, 1); + udelay(DELAY_INTVL_US); + + disp_data >>= 1; + } +} + +static void disp_refresh_timer_handler(unsigned long data) +{ + u16 disp_data; + struct seven_seg_gpio_info *gpio_info = + (struct seven_seg_gpio_info *)data; + disp_data = gpio_info->curr_disp_value; + + send_seven_seg_gpio_data(disp_data, gpio_info); + mod_timer(&gpio_info->update_timer, +
[PATCH linux v1 1/4] Documentation: dt-bindings: Document bindings for seven segment display support
This binding provides interface for adding clock, data and clear signal GPIO lines to control seven segment display. Signed-off-by: Jaghathiswari Rankappagounder Natarajan --- .../devicetree/bindings/misc/seven-seg-gpio.txt| 27 ++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/seven-seg-gpio.txt diff --git a/Documentation/devicetree/bindings/misc/seven-seg-gpio.txt b/Documentation/devicetree/bindings/misc/seven-seg-gpio.txt new file mode 100644 index 000..9a4e255 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/seven-seg-gpio.txt @@ -0,0 +1,27 @@ +This binding defines interface to add clock, data and clear GPIO lines required +for seven segment display support. + +Required properties: +- compatible : should be "seven-seg-gpio-dev". +- clock-gpios : Should specify the GPIO pin connected to the Clock line on the + hardware. +- data-gpios : Should specify the GPIO pin connected to Data line on the + hardware. +- clear-gpios : Should specify the GPIO pin connected to Clear line on the + hardware. + +Optional properties: +- refresh-interval-ms : The interval at which to refresh the display. + If this property is not present, the default value is 1000. + +Examples: + +#include + +seven-seg-disp { + compatible = "seven-seg-gpio-dev"; + refresh-interval-ms = "1000"; + clock-gpios = <&gpio 0 GPIO_ACTIVE_LOW>; + data-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + clear-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; +}; -- 2.8.0.rc3.226.g39d4020
[PATCH linux v1 0/4] Seven segment display support
This patchset includes: Documentation for the binding which provides an interface for adding clock, data and clear signal GPIO lines to control seven segment display. The platform device driver provides an API for displaying on two 7-segment displays, and implements the required bit-banging. The hardware assumed is 74HC164 wired to two 7-segment displays. The character device driver implements the user-space API for letting a user write to two 7-segment displays including any conversion methods necessary to map the user input to two 7-segment displays. Adding clock, data and clear signal GPIO lines in the devicetree to control seven segment display on zaius platform. The platform driver matches on the device tree node; the platform driver also initializes the character device. Tested that the seven segment display works properly by writing to the character device file on a EVB AST2500 board which also has 74HC164 wired to two 7-segment displays. Jaghathiswari Rankappagounder Natarajan (4): Documentation: dt-bindings: Document bindings for seven segment display support drivers: misc: Character device driver for seven segment display drivers: misc: Platform driver for seven segment display support arm: dts: Add dt-binding to support seven segment display on zaius .../devicetree/bindings/misc/seven-seg-gpio.txt| 27 +++ arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 8 + drivers/misc/Kconfig | 16 ++ drivers/misc/Makefile | 2 + drivers/misc/seven_seg_disp.c | 197 drivers/misc/seven_seg_disp.h | 34 drivers/misc/seven_seg_gpio.c | 206 + 7 files changed, 490 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/seven-seg-gpio.txt create mode 100644 drivers/misc/seven_seg_disp.c create mode 100644 drivers/misc/seven_seg_disp.h create mode 100644 drivers/misc/seven_seg_gpio.c -- 2.8.0.rc3.226.g39d4020
RE: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string
On Thu, Dec 14, 2016 at 05:23:02PM +0800, Rob Herring wrote: > On Mon, Dec 12, 2016 at 8:47 PM, Yao Yuan wrote: > > On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote: > >> On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote: > >> > From: Yuan Yao > >> > >> Same problem in this subject too. > >> > >> > > >> > new compatible string: "fsl,ls1012a-qspi". > >> > > >> > Signed-off-by: Yuan Yao > >> > --- > >> > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 + > >> > 1 file changed, 1 insertion(+) > >> > >> Acked-by: Rob Herring > > > > Thanks for your review. > > And do you have any suggestion for this subject? > > The problem is you have a space in the compatible string: "fsl, ls1012a-qspi" > rather than "fsl,ls1012a-qspi" > > Also, I prefer "dt/bindings: " as the beginning of binding patch subjects. > Ok, Get it. Thanks for your comments. I will send v2 soon.
Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string
* Alexis Berlemont wrote: > Hi Masami, > > Many thanks for your mail. > > Here is another patch set which tries to fix the points you mentioned: > > * Skip the arguments containing a constant ($123); > * Review the code in charge of the register renaming (search for '%' > and parse it); > * Minor changes (print the argument in case of error, skipping, check > the sdt arg type index); > > Many thanks, > > Alexis. > > Alexis Berlemont (2): > perf sdt: add scanning of sdt probles arguments > perf probe: add sdt probes arguments into the uprobe cmd string I'd like to hijack this thread to report an SDT oddity - one of my boxen reports lots of SDT tracepoints in 'perf list': mem:[/len][:access] [Hardware breakpoint] sdt_libc:lll_lock_wait_private [SDT event] sdt_libc:longjmp [SDT event] sdt_libc:longjmp_target[SDT event] sdt_libc:memory_arena_new [SDT event] sdt_libc:memory_arena_retry[SDT event] sdt_libc:memory_arena_reuse[SDT event] sdt_libc:memory_arena_reuse_free_list [SDT event] sdt_libc:memory_arena_reuse_wait [SDT event] sdt_libc:memory_calloc_retry [SDT event] sdt_libc:memory_heap_free [SDT event] ... But none of them work: Error: No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing' ... Error: File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found. Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?. What kind of patches are required for SDT probes to work? Thanks, Ingo
Re: [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
Hi Rick, Can you upload patchset v9 to address the issue? Thanks! On Mon, Dec 12, 2016 at 5:07 PM, Rick Chang wrote: > Hi Ricky, > > Thanks for your feedback. We will fix the problem in another patch. > > On Mon, 2016-12-12 at 12:34 +0800, Ricky Liang wrote: >> Hi Rick, >> >> On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang wrote: >> > Add v4l2 driver for Mediatek JPEG Decoder >> > >> > Signed-off-by: Rick Chang >> > Signed-off-by: Minghsiu Tsai >> >> >> >> > +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx, >> > +struct mtk_jpeg_dec_param >> > *param) >> > +{ >> > + struct mtk_jpeg_dev *jpeg = ctx->jpeg; >> > + struct mtk_jpeg_q_data *q_data; >> > + >> > + q_data = &ctx->out_q; >> > + if (q_data->w != param->pic_w || q_data->h != param->pic_h) { >> > + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size >> > change\n"); >> > + return true; >> > + } >> > + >> > + q_data = &ctx->cap_q; >> > + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc, >> > + >> > MTK_JPEG_FMT_TYPE_CAPTURE)) { >> > + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n"); >> > + return true; >> > + } >> > + return false; >> >> >> >> > +static void mtk_jpeg_device_run(void *priv) >> > +{ >> > + struct mtk_jpeg_ctx *ctx = priv; >> > + struct mtk_jpeg_dev *jpeg = ctx->jpeg; >> > + struct vb2_buffer *src_buf, *dst_buf; >> > + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR; >> > + unsigned long flags; >> > + struct mtk_jpeg_src_buf *jpeg_src_buf; >> > + struct mtk_jpeg_bs bs; >> > + struct mtk_jpeg_fb fb; >> > + int i; >> > + >> > + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx); >> > + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx); >> > + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf); >> > + >> > + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) { >> > + for (i = 0; i < dst_buf->num_planes; i++) >> > + vb2_set_plane_payload(dst_buf, i, 0); >> > + buf_state = VB2_BUF_STATE_DONE; >> > + goto dec_end; >> > + } >> > + >> > + if (mtk_jpeg_check_resolution_change(ctx, >> > &jpeg_src_buf->dec_param)) { >> > + mtk_jpeg_queue_src_chg_event(ctx); >> > + ctx->state = MTK_JPEG_SOURCE_CHANGE; >> > + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx); >> > + return; >> > + } >> >> This only detects source change if multiple OUPUT buffers are queued. >> It does not catch the source change in the following scenario: >> >> - OUPUT buffers for jpeg1 enqueued >> - OUTPUT queue STREAMON >> - userspace creates CAPTURE buffers >> - CAPTURE buffers enqueued >> - CAPTURE queue STREAMON >> - decode >> - OUTPUT queue STREAMOFF >> - userspace recreates OUTPUT buffers for jpeg2 >> - OUTPUT buffers for jpeg2 enqueued >> - OUTPUT queue STREAMON >> >> In the above sequence if jpeg2's decoded size is larger than jpeg1 the >> function fails to detect that the existing CAPTURE buffers are not big >> enough to hold the decoded data. >> >> A possible fix is to pass *dst_buf to >> mtk_jpeg_check_resolution_change(), and check in the function that all >> the dst_buf planes are large enough to hold the decoded data. >> >> > + >> > + mtk_jpeg_set_dec_src(ctx, src_buf, &bs); >> > + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, >> > &fb)) >> > + goto dec_end; >> > + >> > + spin_lock_irqsave(&jpeg->hw_lock, flags); >> > + mtk_jpeg_dec_reset(jpeg->dec_reg_base); >> > + mtk_jpeg_dec_set_config(jpeg->dec_reg_base, >> > + &jpeg_src_buf->dec_param, &bs, &fb); >> > + >> > + mtk_jpeg_dec_start(jpeg->dec_reg_base); >> > + spin_unlock_irqrestore(&jpeg->hw_lock, flags); >> > + return; >> > + >> > +dec_end: >> > + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx); >> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); >> > + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state); >> > + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state); >> > + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx); >> > +} >> >> > >
Re: Revised keyrings(7) man page for review
On 12/13/2016 03:20 PM, David Howells wrote: > Michael Kerrisk (man-pages) wrote: > >> The payload data may be stored in a tmpfs filesystem, >> rather than in kernel memory, if the data size exceeds the >> overhead of storing the data in the filesystem. (Storing >> the data in a filesystem requires filesystem structures to >> be allocated in the kernel. The size of these structures >> determines the size threshold above which the tmpfs storage >> method is used.) Since Linux 4.8, the payload data is >> encrypted when stored in tmpfs, to prevent it being written >> unencrypted into swap space. > > "... thereby preventing it from being written unencrypted into the swapspace"? Fixed. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
RE: [PATCH v3 9/9] NTB: Add ntb.h comments
From: Serge Semin > Signed-off-by: Serge Semin Acked-by: Allen Hubbe > --- > include/linux/ntb.h | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/include/linux/ntb.h b/include/linux/ntb.h > index 6d46179..dab0a1b 100644 > --- a/include/linux/ntb.h > +++ b/include/linux/ntb.h > @@ -326,12 +326,17 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops > *ops) > { > /* commented callbacks are not required: */ > return > + /* Port operations are required for multiport devices */ > !ops->peer_port_count == !ops->port_number && > !ops->peer_port_number == !ops->port_number && > !ops->peer_port_idx == !ops->port_number&& > + > + /* Link operations are required */ > ops->link_is_up && > ops->link_enable&& > ops->link_disable && > + > + /* One or both MW interfaces should be developed */ > ops->mw_count && > ops->mw_get_align && > (ops->mw_set_trans || > @@ -341,12 +346,11 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops > *ops) > ops->peer_mw_get_addr && > /* ops->peer_mw_clear_trans && */ > > + /* Doorbell operations are mostly required */ > /* ops->db_is_unsafe&& */ > ops->db_valid_mask && > - > /* both set, or both unset */ > - (!ops->db_vector_count == !ops->db_vector_mask) && > - > + (!ops->db_vector_count == !ops->db_vector_mask) && > ops->db_read&& > /* ops->db_set && */ > ops->db_clear && > @@ -360,6 +364,8 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops *ops) > /* ops->peer_db_read_mask && */ > /* ops->peer_db_set_mask&& */ > /* ops->peer_db_clear_mask && */ > + > + /* Scrachpads interface is optional */ > /* !ops->spad_is_unsafe == !ops->spad_count && */ > !ops->spad_read == !ops->spad_count && > !ops->spad_write == !ops->spad_count&& > @@ -367,6 +373,7 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops *ops) > /* !ops->peer_spad_read == !ops->spad_count && */ > !ops->peer_spad_write == !ops->spad_count && > > + /* Messaging interface is optional */ > !ops->msg_inbits == !ops->msg_count && > !ops->msg_outbits == !ops->msg_count&& > !ops->msg_read_sts == !ops->msg_count && > @@ -387,13 +394,12 @@ struct ntb_client { > struct device_driverdrv; > const struct ntb_client_ops ops; > }; > - > #define drv_ntb_client(__drv) container_of((__drv), struct ntb_client, drv) > > /** > * struct ntb_device - ntb device > * @dev: Linux device object. > - * @pdev:Pci device entry of the ntb. > + * @pdev:PCI device entry of the ntb. > * @topo:Detected topology of the ntb. > * @ops: See &ntb_dev_ops. > * @ctx: See &ntb_ctx_ops. > @@ -414,7 +420,6 @@ struct ntb_dev { > /* block unregister until device is fully released */ > struct completion released; > }; > - > #define dev_ntb(__dev) container_of((__dev), struct ntb_dev, dev) > > /** > @@ -511,7 +516,7 @@ void ntb_link_event(struct ntb_dev *ntb); > * multiple interrupt vectors for doorbells, the vector number indicates > which > * vector received the interrupt. The vector number is relative to the first > * vector used for doorbells, starting at zero, and must be less than > - ** ntb_db_vector_count(). The driver may call ntb_db_read() to check which > + * ntb_db_vector_count(). The driver may call ntb_db_read() to check which > * doorbell bits need service, and ntb_db_vector_mask() to determine which of > * those bits are associated with the vector number. > */ > -- > 2.6.6
[PATCH V1] i2c: xgene: Fix missing code of DTB support
In DTB case, i2c-core doesn't create slave device which is installed on i2c-xgene bus because of missing code in this driver. This patch fixes this issue. Signed-off-by: Tin Huynh --- drivers/i2c/busses/i2c-xgene-slimpro.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c b/drivers/i2c/busses/i2c-xgene-slimpro.c index 263685c..00d1632 100644 --- a/drivers/i2c/busses/i2c-xgene-slimpro.c +++ b/drivers/i2c/busses/i2c-xgene-slimpro.c @@ -415,6 +415,7 @@ static int xgene_slimpro_i2c_probe(struct platform_device *pdev) adapter->algo = &xgene_slimpro_i2c_algorithm; adapter->class = I2C_CLASS_HWMON; adapter->dev.parent = &pdev->dev; + adapter->dev.of_node = pdev->dev.of_node; i2c_set_adapdata(adapter, ctx); rc = i2c_add_adapter(adapter); if (rc) { -- 1.7.1
[PATCH v3 9/9] NTB: Add ntb.h comments
Signed-off-by: Serge Semin --- include/linux/ntb.h | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/include/linux/ntb.h b/include/linux/ntb.h index 6d46179..dab0a1b 100644 --- a/include/linux/ntb.h +++ b/include/linux/ntb.h @@ -326,12 +326,17 @@ static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops) { /* commented callbacks are not required: */ return + /* Port operations are required for multiport devices */ !ops->peer_port_count == !ops->port_number && !ops->peer_port_number == !ops->port_number && !ops->peer_port_idx == !ops->port_number&& + + /* Link operations are required */ ops->link_is_up && ops->link_enable&& ops->link_disable && + + /* One or both MW interfaces should be developed */ ops->mw_count && ops->mw_get_align && (ops->mw_set_trans || @@ -341,12 +346,11 @@ static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops) ops->peer_mw_get_addr && /* ops->peer_mw_clear_trans && */ + /* Doorbell operations are mostly required */ /* ops->db_is_unsafe&& */ ops->db_valid_mask && - /* both set, or both unset */ - (!ops->db_vector_count == !ops->db_vector_mask) && - + (!ops->db_vector_count == !ops->db_vector_mask) && ops->db_read&& /* ops->db_set && */ ops->db_clear && @@ -360,6 +364,8 @@ static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops) /* ops->peer_db_read_mask && */ /* ops->peer_db_set_mask&& */ /* ops->peer_db_clear_mask && */ + + /* Scrachpads interface is optional */ /* !ops->spad_is_unsafe == !ops->spad_count && */ !ops->spad_read == !ops->spad_count && !ops->spad_write == !ops->spad_count&& @@ -367,6 +373,7 @@ static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops) /* !ops->peer_spad_read == !ops->spad_count && */ !ops->peer_spad_write == !ops->spad_count && + /* Messaging interface is optional */ !ops->msg_inbits == !ops->msg_count && !ops->msg_outbits == !ops->msg_count&& !ops->msg_read_sts == !ops->msg_count && @@ -387,13 +394,12 @@ struct ntb_client { struct device_driverdrv; const struct ntb_client_ops ops; }; - #define drv_ntb_client(__drv) container_of((__drv), struct ntb_client, drv) /** * struct ntb_device - ntb device * @dev: Linux device object. - * @pdev: Pci device entry of the ntb. + * @pdev: PCI device entry of the ntb. * @topo: Detected topology of the ntb. * @ops: See &ntb_dev_ops. * @ctx: See &ntb_ctx_ops. @@ -414,7 +420,6 @@ struct ntb_dev { /* block unregister until device is fully released */ struct completion released; }; - #define dev_ntb(__dev) container_of((__dev), struct ntb_dev, dev) /** @@ -511,7 +516,7 @@ void ntb_link_event(struct ntb_dev *ntb); * multiple interrupt vectors for doorbells, the vector number indicates which * vector received the interrupt. The vector number is relative to the first * vector used for doorbells, starting at zero, and must be less than - ** ntb_db_vector_count(). The driver may call ntb_db_read() to check which + * ntb_db_vector_count(). The driver may call ntb_db_read() to check which * doorbell bits need service, and ntb_db_vector_mask() to determine which of * those bits are associated with the vector number. */ -- 2.6.6
[PATCH v3] net: macb: Added PCI wrapper for Platform Driver.
There are hardware PCI implementations of Cadence GEM network controller. This patch will allow to use such hardware with reuse of existing Platform Driver. Signed-off-by: Bartosz Folta --- Changed in v3: Fixed dependencies in Kconfig. --- Changed in v2: Respin to net-next. Changed patch formatting. --- drivers/net/ethernet/cadence/Kconfig| 9 ++ drivers/net/ethernet/cadence/Makefile | 1 + drivers/net/ethernet/cadence/macb.c | 31 +-- drivers/net/ethernet/cadence/macb_pci.c | 153 include/linux/platform_data/macb.h | 6 ++ 5 files changed, 195 insertions(+), 5 deletions(-) create mode 100644 drivers/net/ethernet/cadence/macb_pci.c diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig index f0bcb15..608bea1 100644 --- a/drivers/net/ethernet/cadence/Kconfig +++ b/drivers/net/ethernet/cadence/Kconfig @@ -31,4 +31,13 @@ config MACB To compile this driver as a module, choose M here: the module will be called macb. +config MACB_PCI + tristate "Cadence PCI MACB/GEM support" + depends on MACB && PCI && COMMON_CLK + ---help--- + This is PCI wrapper for MACB driver. + + To compile this driver as a module, choose M here: the module + will be called macb_pci. + endif # NET_CADENCE diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile index 91f79b1..4ba7559 100644 --- a/drivers/net/ethernet/cadence/Makefile +++ b/drivers/net/ethernet/cadence/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_MACB) += macb.o +obj-$(CONFIG_MACB_PCI) += macb_pci.o diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 538544a..c0fb80a 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -404,6 +404,8 @@ static int macb_mii_probe(struct net_device *dev) phy_irq = gpio_to_irq(pdata->phy_irq_pin); phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq; } + } else { + phydev->irq = PHY_POLL; } /* attach the mac to the phy */ @@ -482,6 +484,9 @@ static int macb_mii_init(struct macb *bp) goto err_out_unregister_bus; } } else { + for (i = 0; i < PHY_MAX_ADDR; i++) + bp->mii_bus->irq[i] = PHY_POLL; + if (pdata) bp->mii_bus->phy_mask = pdata->phy_mask; @@ -2523,16 +2528,24 @@ static int macb_clk_init(struct platform_device *pdev, struct clk **pclk, struct clk **hclk, struct clk **tx_clk, struct clk **rx_clk) { + struct macb_platform_data *pdata; int err; - *pclk = devm_clk_get(&pdev->dev, "pclk"); + pdata = dev_get_platdata(&pdev->dev); + if (pdata) { + *pclk = pdata->pclk; + *hclk = pdata->hclk; + } else { + *pclk = devm_clk_get(&pdev->dev, "pclk"); + *hclk = devm_clk_get(&pdev->dev, "hclk"); + } + if (IS_ERR(*pclk)) { err = PTR_ERR(*pclk); dev_err(&pdev->dev, "failed to get macb_clk (%u)\n", err); return err; } - *hclk = devm_clk_get(&pdev->dev, "hclk"); if (IS_ERR(*hclk)) { err = PTR_ERR(*hclk); dev_err(&pdev->dev, "failed to get hclk (%u)\n", err); @@ -3107,15 +3120,23 @@ static int at91ether_init(struct platform_device *pdev) MODULE_DEVICE_TABLE(of, macb_dt_ids); #endif /* CONFIG_OF */ +static const struct macb_config default_gem_config = { + .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO, + .dma_burst_length = 16, + .clk_init = macb_clk_init, + .init = macb_init, + .jumbo_max_len = 10240, +}; + static int macb_probe(struct platform_device *pdev) { + const struct macb_config *macb_config = &default_gem_config; int (*clk_init)(struct platform_device *, struct clk **, struct clk **, struct clk **, struct clk **) - = macb_clk_init; - int (*init)(struct platform_device *) = macb_init; + = macb_config->clk_init; + int (*init)(struct platform_device *) = macb_config->init; struct device_node *np = pdev->dev.of_node; struct device_node *phy_node; - const struct macb_config *macb_config = NULL; struct clk *pclk, *hclk = NULL, *tx_clk = NULL, *rx_clk = NULL; unsigned int queue_mask, num_queues; struct macb_platform_data *pdata; diff --git a/drivers/net/ethernet/cadence/macb_pci.c b/drivers/net/ethernet/cadence/macb_pci.c new file mode 100644 index 000..92be2cd --- /dev/null +++ b/drivers/net/ethernet/cadence/macb_pci.c @@ -0,0 +1,153 @@ +/** + * macb_pci.c - C
RE: [PATCH v3 9/9] NTB: Add ntb.h comments
From: Serge Semin > Signed-off-by: Serge Semin > --- > include/linux/ntb.h | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/include/linux/ntb.h b/include/linux/ntb.h > index 6d46179..dab0a1b 100644 > --- a/include/linux/ntb.h > +++ b/include/linux/ntb.h > @@ -326,12 +326,17 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops > *ops) > { > /* commented callbacks are not required: */ > return > + /* Port operations are required */ ... for multiport devices. > !ops->peer_port_count == !ops->port_number && > !ops->peer_port_number == !ops->port_number && > !ops->peer_port_idx == !ops->port_number&& > + > + /* Link operations are requiered */ > ops->link_is_up && > ops->link_enable&& > ops->link_disable && > + > + /* One or both MW interfaces should be developed */ > ops->mw_count && > ops->mw_get_align && > (ops->mw_set_trans || > @@ -341,12 +346,11 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops > *ops) > ops->peer_mw_get_addr && > /* ops->peer_mw_clear_trans && */ > > + /* Doorbell operations are mostly required */ > /* ops->db_is_unsafe&& */ > ops->db_valid_mask && > - > /* both set, or both unset */ > - (!ops->db_vector_count == !ops->db_vector_mask) && > - > + (!ops->db_vector_count == !ops->db_vector_mask) && > ops->db_read&& > /* ops->db_set && */ > ops->db_clear && > @@ -360,6 +364,8 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops *ops) > /* ops->peer_db_read_mask && */ > /* ops->peer_db_set_mask&& */ > /* ops->peer_db_clear_mask && */ > + > + /* Scrachpads interface is optional */ > /* !ops->spad_is_unsafe == !ops->spad_count && */ > !ops->spad_read == !ops->spad_count && > !ops->spad_write == !ops->spad_count&& > @@ -367,6 +373,7 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops *ops) > /* !ops->peer_spad_read == !ops->spad_count && */ > !ops->peer_spad_write == !ops->spad_count && > > + /* Messaging interface is optional */ > !ops->msg_inbits == !ops->msg_count && > !ops->msg_outbits == !ops->msg_count&& > !ops->msg_read_sts == !ops->msg_count && > @@ -387,13 +394,12 @@ struct ntb_client { > struct device_driverdrv; > const struct ntb_client_ops ops; > }; > - > #define drv_ntb_client(__drv) container_of((__drv), struct ntb_client, drv) > > /** > * struct ntb_device - ntb device > * @dev: Linux device object. > - * @pdev:Pci device entry of the ntb. > + * @pdev:PCI device entry of the ntb. > * @topo:Detected topology of the ntb. > * @ops: See &ntb_dev_ops. > * @ctx: See &ntb_ctx_ops. > @@ -414,7 +420,6 @@ struct ntb_dev { > /* block unregister until device is fully released */ > struct completion released; > }; > - > #define dev_ntb(__dev) container_of((__dev), struct ntb_dev, dev) > > /** > @@ -511,7 +516,7 @@ void ntb_link_event(struct ntb_dev *ntb); > * multiple interrupt vectors for doorbells, the vector number indicates > which > * vector received the interrupt. The vector number is relative to the first > * vector used for doorbells, starting at zero, and must be less than > - ** ntb_db_vector_count(). The driver may call ntb_db_read() to check which > + * ntb_db_vector_count(). The driver may call ntb_db_read() to check which > * doorbell bits need service, and ntb_db_vector_mask() to determine which of > * those bits are associated with the vector number. > */ > -- > 2.6.6
Re: [PATCH v3 1/4] mtd: lart: Rename partition defines to be prefixed with PART_
On Fri, 9 Dec 2016 15:36:25 -0800 Florian Fainelli wrote: > In preparation for defining KERNEL_START on ARM, rename KERNEL_START to > PART_KERNEL_START, and to be consistent, do this for all > partition-related constants. > > Signed-off-by: Florian Fainelli Acked-by: Boris Brezillon > --- > drivers/mtd/devices/lart.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/drivers/mtd/devices/lart.c b/drivers/mtd/devices/lart.c > index 82bd00af5cc3..268aae45b514 100644 > --- a/drivers/mtd/devices/lart.c > +++ b/drivers/mtd/devices/lart.c > @@ -75,18 +75,18 @@ static char module_name[] = "lart"; > > /* blob */ > #define NUM_BLOB_BLOCKS FLASH_NUMBLOCKS_16m_PARAM > -#define BLOB_START 0x > -#define BLOB_LEN (NUM_BLOB_BLOCKS * > FLASH_BLOCKSIZE_PARAM) > +#define PART_BLOB_START 0x > +#define PART_BLOB_LEN(NUM_BLOB_BLOCKS * > FLASH_BLOCKSIZE_PARAM) > > /* kernel */ > #define NUM_KERNEL_BLOCKS7 > -#define KERNEL_START (BLOB_START + BLOB_LEN) > -#define KERNEL_LEN (NUM_KERNEL_BLOCKS * > FLASH_BLOCKSIZE_MAIN) > +#define PART_KERNEL_START(PART_BLOB_START + PART_BLOB_LEN) > +#define PART_KERNEL_LEN (NUM_KERNEL_BLOCKS * > FLASH_BLOCKSIZE_MAIN) > > /* initial ramdisk */ > #define NUM_INITRD_BLOCKS24 > -#define INITRD_START (KERNEL_START + KERNEL_LEN) > -#define INITRD_LEN (NUM_INITRD_BLOCKS * > FLASH_BLOCKSIZE_MAIN) > +#define PART_INITRD_START(PART_KERNEL_START + PART_KERNEL_LEN) > +#define PART_INITRD_LEN (NUM_INITRD_BLOCKS * > FLASH_BLOCKSIZE_MAIN) > > /* > * See section 4.0 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet > @@ -587,20 +587,20 @@ static struct mtd_partition lart_partitions[] = { > /* blob */ > { > .name = "blob", > - .offset = BLOB_START, > - .size = BLOB_LEN, > + .offset = PART_BLOB_START, > + .size = PART_BLOB_LEN, > }, > /* kernel */ > { > .name = "kernel", > - .offset = KERNEL_START, /* MTDPART_OFS_APPEND */ > - .size = KERNEL_LEN, > + .offset = PART_KERNEL_START,/* MTDPART_OFS_APPEND */ > + .size = PART_KERNEL_LEN, > }, > /* initial ramdisk / file system */ > { > .name = "file system", > - .offset = INITRD_START, /* MTDPART_OFS_APPEND */ > - .size = INITRD_LEN, /* MTDPART_SIZ_FULL */ > + .offset = PART_INITRD_START,/* MTDPART_OFS_APPEND */ > + .size = PART_INITRD_LEN, /* MTDPART_SIZ_FULL */ > } > }; > #define NUM_PARTITIONS ARRAY_SIZE(lart_partitions)
RE: [PATCH v3 5/9] NTB: Alter Scratchpads API to support multi-ports devices
From: Serge Semin > Even though there is no any real NTB hardware, which would have both more > than two ports and Scratchpad registers, it is logically correct to have > Scratchpad API accepting a peer port index as well. Intel/AMD drivers utilize > Primary and Secondary topology to split Scratchpad between connected root > devices. Since port-index API introduced, Intel/AMD NTB hardware drivers can > use device port to determine which Scratchpad registers actually belong to > local and peer devices. The same approach can be used if some potential > hardware in future will be multi-port and have some set of Scratchpads. > Here are the brief of changes in the API: > ntb_spad_count() - return number of Scratchpads per each port > ntb_peer_spad_addr(pidx, sidx) - address of Scratchpad register of the > peer device with pidx-index > ntb_peer_spad_read(pidx, sidx) - read specified Scratchpad register of the > peer with pidx-index > ntb_peer_spad_write(pidx, sidx) - write data to Scratchpad register of the > peer with pidx-index > > Since there is hardware which doesn't support Scratchpad registers, the > corresponding API methods are now made optional. > > Signed-off-by: Serge Semin Acked-by: Allen Hubbe > --- > drivers/ntb/hw/amd/ntb_hw_amd.c | 14 +++ > drivers/ntb/hw/intel/ntb_hw_intel.c | 14 +++ > drivers/ntb/ntb_transport.c | 17 - > drivers/ntb/test/ntb_perf.c | 6 +-- > drivers/ntb/test/ntb_pingpong.c | 8 +++- > drivers/ntb/test/ntb_tool.c | 21 -- > include/linux/ntb.h | 76 > +++-- > 7 files changed, 98 insertions(+), 58 deletions(-) > > diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c > index 6a41c38..bc537aa 100644 > --- a/drivers/ntb/hw/amd/ntb_hw_amd.c > +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c > @@ -433,30 +433,30 @@ static int amd_ntb_spad_write(struct ntb_dev *ntb, > return 0; > } > > -static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int idx) > +static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx) > { > struct amd_ntb_dev *ndev = ntb_ndev(ntb); > void __iomem *mmio = ndev->self_mmio; > u32 offset; > > - if (idx < 0 || idx >= ndev->spad_count) > + if (sidx < 0 || sidx >= ndev->spad_count) > return -EINVAL; > > - offset = ndev->peer_spad + (idx << 2); > + offset = ndev->peer_spad + (sidx << 2); > return readl(mmio + AMD_SPAD_OFFSET + offset); > } > > -static int amd_ntb_peer_spad_write(struct ntb_dev *ntb, > -int idx, u32 val) > +static int amd_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx, > +int sidx, u32 val) > { > struct amd_ntb_dev *ndev = ntb_ndev(ntb); > void __iomem *mmio = ndev->self_mmio; > u32 offset; > > - if (idx < 0 || idx >= ndev->spad_count) > + if (sidx < 0 || sidx >= ndev->spad_count) > return -EINVAL; > > - offset = ndev->peer_spad + (idx << 2); > + offset = ndev->peer_spad + (sidx << 2); > writel(val, mmio + AMD_SPAD_OFFSET + offset); > > return 0; > diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c > b/drivers/ntb/hw/intel/ntb_hw_intel.c > index 4b84012..7bb14cb 100644 > --- a/drivers/ntb/hw/intel/ntb_hw_intel.c > +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c > @@ -1409,30 +1409,30 @@ static int intel_ntb_spad_write(struct ntb_dev *ntb, > ndev->self_reg->spad); > } > > -static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int idx, > +static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int pidx, int sidx, > phys_addr_t *spad_addr) > { > struct intel_ntb_dev *ndev = ntb_ndev(ntb); > > - return ndev_spad_addr(ndev, idx, spad_addr, ndev->peer_addr, > + return ndev_spad_addr(ndev, sidx, spad_addr, ndev->peer_addr, > ndev->peer_reg->spad); > } > > -static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int idx) > +static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx) > { > struct intel_ntb_dev *ndev = ntb_ndev(ntb); > > - return ndev_spad_read(ndev, idx, > + return ndev_spad_read(ndev, sidx, > ndev->peer_mmio + > ndev->peer_reg->spad); > } > > -static int intel_ntb_peer_spad_write(struct ntb_dev *ntb, > - int idx, u32 val) > +static int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx, > + int sidx, u32 val) > { > struct intel_ntb_dev *ndev = ntb_ndev(ntb); > > - return ndev_spad_write(ndev, idx, val, > + return ndev_spad_write(ndev, sidx, val, > ndev->peer_mmio + > ndev->peer_reg->spad); > } > diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_trans
RE: [PATCH v3 4/9] NTB: Alter MW API to support multi-ports devices
From: Serge Semin > Multi-port NTB devices permit to share a memory between all accessible peers. > Memory Windows API is altered to correspondingly initialize and map memory > windows for such devices: > ntb_mw_count(pidx); - number of inbound memory windows, which can be > allocated > for shared buffer with specified peer device. > ntb_mw_get_align(pidx, widx); - get alignment and size restriction parameters > to properly allocate inbound memory region. > ntb_peer_mw_count(); - get number of outbound memory windows. > ntb_peer_mw_get_addr(widx); - get mapping address of an outbound memory > window > > If hardware supports inbound translation configured on the local ntb port: > ntb_mw_set_trans(pidx, widx); - set translation address of allocated inbound > memory window so a peer device could access it. > ntb_mw_clear_trans(pidx, widx); - clear the translation address of an inbound > memory window. > > If hardware supports outbound translation configured on the peer ntb port: > ntb_peer_mw_set_trans(pidx, widx); - set translation address of a memory > window retrieved from a peer device > ntb_peer_mw_clear_trans(pidx, widx); - clear the translation address of an > outbound memory window > > Signed-off-by: Serge Semin Acked-by: Allen Hubbe > --- > drivers/ntb/hw/amd/ntb_hw_amd.c | 68 +--- > drivers/ntb/hw/intel/ntb_hw_intel.c | 90 > drivers/ntb/ntb.c | 2 + > drivers/ntb/ntb_transport.c | 21 +++- > drivers/ntb/test/ntb_perf.c | 17 ++- > drivers/ntb/test/ntb_tool.c | 43 +--- > include/linux/ntb.h | 208 > > 7 files changed, 342 insertions(+), 107 deletions(-) > > diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c > index 4d8d0bd..6a41c38 100644 > --- a/drivers/ntb/hw/amd/ntb_hw_amd.c > +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c > @@ -5,6 +5,7 @@ > * GPL LICENSE SUMMARY > * > * Copyright (C) 2016 Advanced Micro Devices, Inc. All Rights Reserved. > + * Copyright (C) 2016 T-Platforms. All Rights Reserved. > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of version 2 of the GNU General Public License as > @@ -13,6 +14,7 @@ > * BSD LICENSE > * > * Copyright (C) 2016 Advanced Micro Devices, Inc. All Rights Reserved. > + * Copyright (C) 2016 T-Platforms. All Rights Reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > @@ -79,40 +81,42 @@ static int ndev_mw_to_bar(struct amd_ntb_dev *ndev, int > idx) > return 1 << idx; > } > > -static int amd_ntb_mw_count(struct ntb_dev *ntb) > +static int amd_ntb_mw_count(struct ntb_dev *ntb, int pidx) > { > + if (pidx != NTB_DEF_PEER_IDX) > + return -EINVAL; > + > return ntb_ndev(ntb)->mw_count; > } > > -static int amd_ntb_mw_get_range(struct ntb_dev *ntb, int idx, > - phys_addr_t *base, > - resource_size_t *size, > - resource_size_t *align, > - resource_size_t *align_size) > +static int amd_ntb_mw_get_align(struct ntb_dev *ntb, int pidx, int idx, > + resource_size_t *addr_align, > + resource_size_t *size_align, > + resource_size_t *size_max) > { > struct amd_ntb_dev *ndev = ntb_ndev(ntb); > int bar; > > + if (pidx != NTB_DEF_PEER_IDX) > + return -EINVAL; > + > bar = ndev_mw_to_bar(ndev, idx); > if (bar < 0) > return bar; > > - if (base) > - *base = pci_resource_start(ndev->ntb.pdev, bar); > - > - if (size) > - *size = pci_resource_len(ndev->ntb.pdev, bar); > + if (addr_align) > + *addr_align = SZ_4K; > > - if (align) > - *align = SZ_4K; > + if (size_align) > + *size_align = 1; > > - if (align_size) > - *align_size = 1; > + if (size_max) > + *size_max = pci_resource_len(ndev->ntb.pdev, bar); > > return 0; > } > > -static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int idx, > +static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int pidx, int idx, > dma_addr_t addr, resource_size_t size) > { > struct amd_ntb_dev *ndev = ntb_ndev(ntb); > @@ -122,6 +126,9 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int > idx, > u64 base_addr, limit, reg_val; > int bar; > > + if (pidx != NTB_DEF_PEER_IDX) > + return -EINVAL; > + > bar = ndev_mw_to_bar(ndev, idx); > if (bar < 0) > return bar; > @@ -285,6 +292,31 @@ static int amd_ntb_link_disable(struct ntb_dev *ntb) > return 0; > } > > +static int amd_ntb_peer_m
RE: [PATCH v3 1/9] NTB: Make link-state API being declared first
From: Serge Semin > Since link operations are usually performed before memory window access > operations, it's logically better to declare link-related API before any > of MW/Doorbell/Scratchpad methods. > > Signed-off-by: Serge Semin Acked-by: Allen Hubbe > --- > include/linux/ntb.h | 137 > ++-- > 1 file changed, 69 insertions(+), 68 deletions(-) > > diff --git a/include/linux/ntb.h b/include/linux/ntb.h > index 6f47562..5d1f260 100644 > --- a/include/linux/ntb.h > +++ b/include/linux/ntb.h > @@ -179,13 +179,13 @@ static inline int ntb_ctx_ops_is_valid(const struct > ntb_ctx_ops > *ops) > > /** > * struct ntb_ctx_ops - ntb device operations > + * @link_is_up: See ntb_link_is_up(). > + * @link_enable: See ntb_link_enable(). > + * @link_disable:See ntb_link_disable(). > * @mw_count:See ntb_mw_count(). > * @mw_get_range:See ntb_mw_get_range(). > * @mw_set_trans:See ntb_mw_set_trans(). > * @mw_clear_trans: See ntb_mw_clear_trans(). > - * @link_is_up: See ntb_link_is_up(). > - * @link_enable: See ntb_link_enable(). > - * @link_disable:See ntb_link_disable(). > * @db_is_unsafe:See ntb_db_is_unsafe(). > * @db_valid_mask: See ntb_db_valid_mask(). > * @db_vector_count: See ntb_db_vector_count(). > @@ -212,6 +212,12 @@ static inline int ntb_ctx_ops_is_valid(const struct > ntb_ctx_ops *ops) > * @peer_spad_write: See ntb_peer_spad_write(). > */ > struct ntb_dev_ops { > + int (*link_is_up)(struct ntb_dev *ntb, > + enum ntb_speed *speed, enum ntb_width *width); > + int (*link_enable)(struct ntb_dev *ntb, > +enum ntb_speed max_speed, enum ntb_width max_width); > + int (*link_disable)(struct ntb_dev *ntb); > + > int (*mw_count)(struct ntb_dev *ntb); > int (*mw_get_range)(struct ntb_dev *ntb, int idx, > phys_addr_t *base, resource_size_t *size, > @@ -220,12 +226,6 @@ struct ntb_dev_ops { > dma_addr_t addr, resource_size_t size); > int (*mw_clear_trans)(struct ntb_dev *ntb, int idx); > > - int (*link_is_up)(struct ntb_dev *ntb, > - enum ntb_speed *speed, enum ntb_width *width); > - int (*link_enable)(struct ntb_dev *ntb, > -enum ntb_speed max_speed, enum ntb_width max_width); > - int (*link_disable)(struct ntb_dev *ntb); > - > int (*db_is_unsafe)(struct ntb_dev *ntb); > u64 (*db_valid_mask)(struct ntb_dev *ntb); > int (*db_vector_count)(struct ntb_dev *ntb); > @@ -265,13 +265,14 @@ static inline int ntb_dev_ops_is_valid(const struct > ntb_dev_ops > *ops) > { > /* commented callbacks are not required: */ > return > + ops->link_is_up && > + ops->link_enable&& > + ops->link_disable && > ops->mw_count && > ops->mw_get_range && > ops->mw_set_trans && > /* ops->mw_clear_trans && */ > - ops->link_is_up && > - ops->link_enable&& > - ops->link_disable && > + > /* ops->db_is_unsafe&& */ > ops->db_valid_mask && > > @@ -441,6 +442,62 @@ void ntb_link_event(struct ntb_dev *ntb); > void ntb_db_event(struct ntb_dev *ntb, int vector); > > /** > + * ntb_link_is_up() - get the current ntb link state > + * @ntb: NTB device context. > + * @speed: OUT - The link speed expressed as PCIe generation number. > + * @width: OUT - The link width expressed as the number of PCIe lanes. > + * > + * Get the current state of the ntb link. It is recommended to query the > link > + * state once after every link event. It is safe to query the link state in > + * the context of the link event callback. > + * > + * Return: One if the link is up, zero if the link is down, otherwise a > + * negative value indicating the error number. > + */ > +static inline int ntb_link_is_up(struct ntb_dev *ntb, > + enum ntb_speed *speed, enum ntb_width *width) > +{ > + return ntb->ops->link_is_up(ntb, speed, width); > +} > + > +/** > + * ntb_link_enable() - enable the link on the secondary side of the ntb > + * @ntb: NTB device context. > + * @max_speed: The maximum link speed expressed as PCIe generation > number. > + * @max_width: The maximum link width expressed as the number of PCIe > lanes. > + * > + * Enable the link on the secondary side of the ntb. This can only be done > + * from the primary side of the ntb in primary or b2b topology. The ntb > device > + * should train the link to its maximum speed and wid
RE: [PATCH v3 2/9] NTB: Add indexed ports NTB API
From: Serge Semin > There is some NTB hardware, which can combine more than just two domains > over NTB. For instance, some IDT PCIe-switches can have NTB-functions > activated on more than two-ports. The different domains are distinguished > by ports they are connected to. So the new port-related methods are added to > the NTB API: > ntb_port_number() - return local port > ntb_peer_port_count() - return number of peers local port can connect to > ntb_peer_port_number(pdix) - return port number by it index > ntb_peer_port_idx(port) - return port index by it number > > Current test-drivers aren't changed much. They still support two-ports devices > for the time being while multi-ports hardware drivers aren't added. > > By default port-related API is declared for two-ports hardware. > So corresponding hardware drivers won't need to implement it. > > Signed-off-by: Serge Semin Acked-by: Allen Hubbe > --- > drivers/ntb/ntb.c | 54 ++ > drivers/ntb/ntb_transport.c | 6 ++ > drivers/ntb/test/ntb_perf.c | 4 ++ > drivers/ntb/test/ntb_pingpong.c | 6 ++ > drivers/ntb/test/ntb_tool.c | 5 ++ > include/linux/ntb.h | 156 > > 6 files changed, 231 insertions(+) > > diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c > index 2e25307..1e92e52 100644 > --- a/drivers/ntb/ntb.c > +++ b/drivers/ntb/ntb.c > @@ -191,6 +191,60 @@ void ntb_db_event(struct ntb_dev *ntb, int vector) > } > EXPORT_SYMBOL(ntb_db_event); > > +int ntb_default_port_number(struct ntb_dev *ntb) > +{ > + switch (ntb->topo) { > + case NTB_TOPO_PRI: > + case NTB_TOPO_B2B_USD: > + return NTB_PORT_PRI_USD; > + case NTB_TOPO_SEC: > + case NTB_TOPO_B2B_DSD: > + return NTB_PORT_SEC_DSD; > + default: > + break; > + } > + > + return -EINVAL; > +} > +EXPORT_SYMBOL(ntb_default_port_number); > + > +int ntb_default_peer_port_count(struct ntb_dev *ntb) > +{ > + return NTB_DEF_PEER_CNT; > +} > +EXPORT_SYMBOL(ntb_default_peer_port_count); > + > +int ntb_default_peer_port_number(struct ntb_dev *ntb, int pidx) > +{ > + if (pidx != NTB_DEF_PEER_IDX) > + return -EINVAL; > + > + switch (ntb->topo) { > + case NTB_TOPO_PRI: > + case NTB_TOPO_B2B_USD: > + return NTB_PORT_SEC_DSD; > + case NTB_TOPO_SEC: > + case NTB_TOPO_B2B_DSD: > + return NTB_PORT_PRI_USD; > + default: > + break; > + } > + > + return -EINVAL; > +} > +EXPORT_SYMBOL(ntb_default_peer_port_number); > + > +int ntb_default_peer_port_idx(struct ntb_dev *ntb, int port) > +{ > + int peer_port = ntb_default_peer_port_number(ntb, NTB_DEF_PEER_IDX); > + > + if (peer_port == -EINVAL || port != peer_port) > + return -EINVAL; > + > + return 0; > +} > +EXPORT_SYMBOL(ntb_default_peer_port_idx); > + > static int ntb_probe(struct device *dev) > { > struct ntb_dev *ntb; > diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c > index 4eb8adb..10518b7 100644 > --- a/drivers/ntb/ntb_transport.c > +++ b/drivers/ntb/ntb_transport.c > @@ -94,6 +94,9 @@ MODULE_PARM_DESC(use_dma, "Use DMA engine to perform large > data copy"); > > static struct dentry *nt_debugfs_dir; > > +/* Only two-ports NTB devices are supported */ > +#define PIDX NTB_DEF_PEER_IDX > + > struct ntb_queue_entry { > /* ntb_queue list reference */ > struct list_head entry; > @@ -1083,6 +1086,9 @@ static int ntb_transport_probe(struct ntb_client *self, > struct > ntb_dev *ndev) > dev_dbg(&ndev->dev, > "scratchpad is unsafe, proceed anyway...\n"); > > + if (ntb_peer_port_count(ndev) != NTB_DEF_PEER_CNT) > + dev_warn(&ndev->dev, "Multi-port NTB devices unsupported\n"); > + > node = dev_to_node(&ndev->dev); > > nt = kzalloc_node(sizeof(*nt), GFP_KERNEL, node); > diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c > index e75d4fd..c908b3a 100644 > --- a/drivers/ntb/test/ntb_perf.c > +++ b/drivers/ntb/test/ntb_perf.c > @@ -76,6 +76,7 @@ > #define DMA_RETRIES 20 > #define SZ_4G(1ULL << 32) > #define MAX_SEG_ORDER20 /* no larger than 1M for kmalloc > buffer */ > +#define PIDX NTB_DEF_PEER_IDX > > MODULE_LICENSE(DRIVER_LICENSE); > MODULE_VERSION(DRIVER_VERSION); > @@ -764,6 +765,9 @@ static int perf_probe(struct ntb_client *client, struct > ntb_dev *ntb) > return -EIO; > } > > + if (ntb_peer_port_count(ntb) != NTB_DEF_PEER_CNT) > + dev_warn(&ntb->dev, "Multi-port NTB devices unsupported\n"); > + > node = dev_to_node(&pdev->dev); > > perf = kzalloc_node(sizeof(*perf), GFP_KERNEL, node); > diff --git a/drivers/ntb/test/ntb_pingpong.c b/drivers/ntb/test/ntb_pingpong.c > index 4358611..12f8b40 100644 > --- a/drivers/ntb/test/ntb_pingpong.c
Re: [PATCH] mtd: fix typos in ooblayout comment blocks
On Wed, 14 Dec 2016 09:31:01 +0900 Masahiro Yamada wrote: > - "This functions return ..." -> "This function returns ..." > - "I you want ..." -> "If you want ..." > > Signed-off-by: Masahiro Yamada Acked-by: Boris Brezillon > --- > > drivers/mtd/mtdcore.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c > index ca661ce..d64e61b 100644 > --- a/drivers/mtd/mtdcore.c > +++ b/drivers/mtd/mtdcore.c > @@ -1129,7 +1129,7 @@ EXPORT_SYMBOL_GPL(mtd_write_oob); > * @oobecc: OOB region struct filled with the appropriate ECC position > * information > * > - * This functions return ECC section information in the OOB area. I you want > + * This function returns ECC section information in the OOB area. If you want > * to get all the ECC bytes information, then you should call > * mtd_ooblayout_ecc(mtd, section++, oobecc) until it returns -ERANGE. > * > @@ -1161,7 +1161,7 @@ EXPORT_SYMBOL_GPL(mtd_ooblayout_ecc); > * @oobfree: OOB region struct filled with the appropriate free position > *information > * > - * This functions return free bytes position in the OOB area. I you want > + * This function returns free bytes position in the OOB area. If you want > * to get all the free bytes information, then you should call > * mtd_ooblayout_free(mtd, section++, oobfree) until it returns -ERANGE. > * > @@ -1191,7 +1191,7 @@ EXPORT_SYMBOL_GPL(mtd_ooblayout_free); > * @iter: iterator function. Should be either mtd_ooblayout_free or > * mtd_ooblayout_ecc depending on the region type you're searching for > * > - * This functions returns the section id and oobregion information of a > + * This function returns the section id and oobregion information of a > * specific byte. For example, say you want to know where the 4th ECC byte is > * stored, you'll use: > *
Re: [PATCH v7 1/2] usb: xhci: plat: Enable runtime PM
Hey Baolin, On 2016-12-12 12:21 AM, Baolin Wang wrote: Hi Robert, On 2 December 2016 at 05:46, Robert Foss wrote: Enable runtime PM for the xhci-plat device so that the parent device may implement runtime PM. Signed-off-by: Robert Foss Tested-by: Robert Foss --- drivers/usb/host/xhci-plat.c | 29 +++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index ed56bf9ed885..ba4efe74f537 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -246,6 +246,9 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto dealloc_usb2_hcd; + pm_runtime_set_active(&pdev->dev); + pm_runtime_enable(&pdev->dev); You did not implement the runtime callbacks of xHCI device, then how can the parent device control the resume/suspend of xHCI device by runtime PM mechanism? Could you see my previous patch which implement the runtime callbacks for xHCI device? https://lkml.org/lkml/2016/11/28/25 Pardon my ignorance, but which exact functions need to be implemented? Also, does the lkml link you provided contain an example implementation of those functions? + return 0; @@ -274,6 +277,8 @@ static int xhci_plat_remove(struct platform_device *dev) struct xhci_hcd *xhci = hcd_to_xhci(hcd); struct clk *clk = xhci->clk; + pm_runtime_disable(&dev->dev); + usb_remove_hcd(xhci->shared_hcd); usb_phy_shutdown(hcd->usb_phy); @@ -292,6 +297,13 @@ static int xhci_plat_suspend(struct device *dev) { struct usb_hcd *hcd = dev_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + int ret; + + ret = pm_runtime_get_sync(dev); + if (ret < 0) { + pm_runtime_put(dev); + return ret; + } /* * xhci_suspend() needs `do_wakeup` to know whether host is allowed @@ -301,15 +313,28 @@ static int xhci_plat_suspend(struct device *dev) * reconsider this when xhci_plat_suspend enlarges its scope, e.g., * also applies to runtime suspend. */ - return xhci_suspend(xhci, device_may_wakeup(dev)); + ret = xhci_suspend(xhci, device_may_wakeup(dev)); + pm_runtime_put(dev); + + return ret; } static int xhci_plat_resume(struct device *dev) { struct usb_hcd *hcd = dev_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + int ret; - return xhci_resume(xhci, 0); + ret = pm_runtime_get_sync(dev); + if (ret < 0) { + pm_runtime_put(dev); + return ret; + } + + ret = xhci_resume(xhci, 0); + pm_runtime_put(dev); + + return ret; } static const struct dev_pm_ops xhci_plat_pm_ops = { -- 2.11.0
Re: [RFC PATCH v3] audit: use proper refcount locking on audit_sock
On Tue, Dec 13, 2016 at 8:00 PM, Richard Guy Briggs wrote: > On 2016-12-13 16:19, Cong Wang wrote: >> On Tue, Dec 13, 2016 at 7:03 AM, Richard Guy Briggs wrote: >> > @@ -1283,8 +1299,10 @@ static void __net_exit audit_net_exit(struct net >> > *net) >> > { >> > struct audit_net *aunet = net_generic(net, audit_net_id); >> > struct sock *sock = aunet->nlsk; >> > + mutex_lock(&audit_cmd_mutex); >> > if (sock == audit_sock) >> > auditd_reset(); >> > + mutex_unlock(&audit_cmd_mutex); >> >> This still doesn't look correct to me, b/c here we release the audit_sock >> refcnt twice: >> >> 1) inside audit_reset() > > The audit_reset() refcount decrement corresponds to a setting of > audit_sock only if audit_sock is still non-NULL. > Hmm, thinking about it again, looks like the sock == audit_sock and audit_sock != NULL checks can guarantee we are safe. So, Reviewed-by: Cong Wang
Re: [PATCH v4 1/4] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
Hi Balbir, On Tue, Dec 13, 2016 at 09:13:26PM +1100, Balbir Singh wrote: > > > On 10/12/16 00:32, Gautham R. Shenoy wrote: > > From: "Gautham R. Shenoy" > > diff --git a/arch/powerpc/include/asm/cpuidle.h > > b/arch/powerpc/include/asm/cpuidle.h > > index 3919332..0a3255b 100644 > > --- a/arch/powerpc/include/asm/cpuidle.h > > +++ b/arch/powerpc/include/asm/cpuidle.h > > @@ -21,7 +21,7 @@ > > > > /* Idle state entry routines */ > > #ifdef CONFIG_PPC_P7_NAP > > -#defineIDLE_STATE_ENTER_SEQ(IDLE_INST) \ > > +#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \ > > /* Magic NAP/SLEEP/WINKLE mode enter sequence */\ > > std r0,0(r1); \ > > ptesync;\ > > @@ -29,6 +29,9 @@ > > 1: cmpdcr0,r0,r0; \ > > bne 1b; \ > > IDLE_INST; \ > > + > > Is the power saving magic sequence the same as before for power 9 > as well? Yes, this is the same magic sequence for POWER9. -- Thanks and Regards gautham.
[GIT PULL] MD update for 4.10
Hi Linus, Please pull MD changes for 4.10. This update includes: - A raid5 writeback cache feature. The goal is to aggregate writes to make full stripe write and reduce read-modify-write. It's helpful for workload which does sequential write and follows fsync for example. This feature is experimental and off by default right now. - FAILFAST support. This fails IOs to broken raid disks quickly, so can improve latency. It's mainly for DASD storage, but some patches help normal raid array too. - Support bad block for raid array with external metadata - AVX2 instruction support for raid6 parity calculation - Normalize MD info output - Add missing blktrace - Other bug fixes Thanks, Shaohua The following changes since commit b78b499a67c3f77aeb6cd0b54724bc38b141255d: Merge tag 'char-misc-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc (2016-12-13 12:11:01 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git for-linus for you to fetch changes up to 20737738d397dfadbca1ea50dcc00d7259f500cf: Merge branch 'md-next' into md-linus (2016-12-13 12:40:15 -0800) Dan Carpenter (1): md/r5cache: enable IRQs on error path Gayatri Kammela (1): lib/raid6: Add AVX2 optimized xor_syndrome functions Guoqing Jiang (1): md/bitmap: call bitmap_file_unmap once bitmap_storage_alloc returns -ENOMEM JackieLiu (8): raid5-cache: restrict the use area of the log_offset variable md/raid5-cache: remove unnecessary function parameters md/raid5-cache: use ring add to prevent overflow md/raid5-cache: release the stripe_head at the appropriate location md/raid5-cache: remove the unnecessary next_cp_seq field from the r5l_log md/raid5-cache: do not need to set STRIPE_PREREAD_ACTIVE repeatedly md/raid5-cache: adjust the write position of the empty block if no data blocks md/raid5-cache: no recovery is required when create super-block Konstantin Khlebnikov (1): md/raid5: limit request size according to implementation limits NeilBrown (26): md: fix some issues with alloc_disk_sb() md: change all printk() to pr_err() or pr_warn() etc. md/bitmap: change all printk() to pr_*() md/linear: replace printk() with pr_*() md/multipath: replace printk() with pr_*() md/raid0: replace printk() with pr_*() md/raid1: change printk() to pr_*() md/raid10: change printk() to pr_*() md/raid5: change printk() to pr_*() md: perform async updates for metadata where possible. md/raid1: abort delayed writes when device fails. md/raid10: abort delayed writes when device fails. md/bitmap: Don't write bitmap while earlier writes might be in-flight md/raid1: fix: IO can block resync indefinitely md: define mddev flags, recovery flags and r1bio state bits using enums md: remove md_super_wait() call after bitmap_flush() md: add block tracing for bio_remapping md/bitmap: add blktrace event for writes to the bitmap md/raid1, raid10: add blktrace records when IO is delayed md/failfast: add failfast flag for md to be used by some personalities. md: Use REQ_FAILFAST_* on metadata writes where appropriate md/raid1: add failfast handling for reads. md/raid1: add failfast handling for writes. md/raid10: add failfast handling for reads. md/raid10: add failfast handling for writes. md: fix refcount problem on mddev when stopping array. Shaohua Li (8): raid5-cache: fix lockdep warning md: add blktrace event for writes to superblock raid5-cache: suspend reclaim thread instead of shutdown md: stop write should stop journal reclaim md: takeover should clear unrelated bits md: MD_RECOVERY_NEEDED is set for mddev->recovery md: separate flags for superblock changes Merge branch 'md-next' into md-linus Song Liu (14): md/r5cache: Check array size in r5l_init_log md/r5cache: move some code to raid5.h md/r5cache: State machine for raid5-cache write back mode md/r5cache: caching phase of r5cache md/r5cache: write-out phase and reclaim support md/r5cache: sysfs entry journal_mode md/r5cache: refactoring journal recovery code md/r5cache: r5cache recovery: part 1 md/r5cache: r5cache recovery: part 2 md/r5cache: handle FLUSH and FUA md/r5cache: handle alloc_page failure md/r5cache: run_no_space_stripes() when R5C_LOG_CRITICAL == 0 md/raid5-cache: fix crc in rewrite_data_only_stripes() md/r5cache: after recovery, increase journal seq by 1 Tomasz Majchrzak (4): md: add bad block support for external metadata md: don't fail an array if there are unacknowledged bad blocks md: wake up personality thread after array state update raid5: revert commit 11
Re: [RFC PATCH v2] crypto: Add IV generation algorithms
Hi Milan, Thank you for the reply. On 13 December 2016 at 15:31, Milan Broz wrote: > I really do not think the disk encryption key management should be moved > outside of dm-crypt. We cannot then change key structure later easily. Yes, I agree. but the key selection based on sector number restricts the option of having a larger block size used for encryption. >> + unsigned int key_size; >> + unsigned int key_extra_size; >> + unsigned int key_parts; /* independent parts in key buffer */ > > ^^^ these key sizes you probably mean by key management. Yes, I mean splitting the keys into subkeys based on the keycount parameter (as mentioned below) to the dm-crypt. cipher[:keycount]-mode-iv:ivopts aes:2-cbc-essiv:sha256 > It is based on way how the key is currently sent into kernel > (one hexa string in ioctl that needs to be split) and have to be changed in > future. -Binoy
Re: [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
Hi Florian, On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli wrote: > Register the TS-7300 FPGA manager device drivers which allows us to load > bitstreams into the on-board Altera Cyclone II FPGA. > > Signed-off-by: Florian Fainelli > --- > arch/arm/mach-ep93xx/ts72xx.c | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c > index 3b39ea353d30..acf72ea670ef 100644 > --- a/arch/arm/mach-ep93xx/ts72xx.c > +++ b/arch/arm/mach-ep93xx/ts72xx.c > @@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data > = { > .phy_id = 1, > }; > > +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX) > + > +/* Relative to EP93XX_CS1_PHYS_BASE */ > +#define TS73XX_FPGA_LOADER_BASE0x03c0 > + > +static struct resource ts73xx_fpga_resources[] = { > + { > + .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE, > + .end= EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1, > + .flags = IORESOURCE_MEM, > + }, > +}; > + > +static struct platform_device ts73xx_fpga_device = { > + .name = "ts73xx-fpga-mgr", > + .id = -1, > + .resource = ts73xx_fpga_resources, > + .num_resources = ARRAY_SIZE(ts73xx_fpga_resources), > +}; > + > +#endif > + > static void __init ts72xx_init_machine(void) > { > ep93xx_init_devices(); > @@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void) > platform_device_register(&ts72xx_wdt_device); > > ep93xx_register_eth(&ts72xx_eth_data, 1); > +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX) > + if (board_is_ts7300()) > + platform_device_register(&ts73xx_fpga_device); > +#endif > } > > MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC") > -- > 2.9.3 > I think this is backwards, shouldn't this be your [PATCH 2/2]? Otherwise you're using the driver before you added it. Thanks, Moritz
Re: [RESEND PATCH v4 1/2] sysctl: introduce new proc handler proc_dobool
Hi Jia, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jia-He/sysctl-introduce-new-proc-handler-proc_dobool/20161214-112656 config: x86_64-randconfig-n0-12141159 (attached as .config) compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> kernel/built-in.o:(___ksymtab+proc_dobool+0x0): undefined reference to >> `proc_dobool' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] doc: add note on usleep_range range
On Wed, 2016-12-14 at 00:37 +, Nicholas Mc Guire wrote: > On Tue, Dec 13, 2016 at 04:27:32PM -0800, Joe Perches wrote: > > a, On Tue, 2016-12-13 at 09:19 +, Nicholas Mc Guire wrote: > > > On Tue, Dec 13, 2016 at 11:10:50AM +0200, Jani Nikula wrote: > > > > On Tue, 13 Dec 2016, Nicholas Mc Guire wrote: > > > > > useleep_range() with a delta of 0 makes no sense and only prevents the > > > > > timer subsystem from optimizing interrupts. As any user of > > > > > usleep_range() > > > > > is in non-atomic context the timer jitter is in the range of 10s of > > > > > microseconds anyway. > > > > > > > > > > This adds a note making it clear that a range of 0 is a bad idea. > > > > > > > > So I don't really have anything to do with the timer subsystem, I'm just > > > > their "consumer", so take this with a grain of salt. > > > > > > > > Documentation is good, but I don't think this will be enough. > > > > > > > > I think the only thing that will work is to detect and complain about > > > > things like this automatically. Some ideas: > > > > > > > > * WARN_ON(min == max) or WARN_ON_ONCE(min == max) in usleep_range() > > > > might be drastic, but it would get the job done eventually. > > > > > > > > * If you want to avoid the runtime overhead (and complaints about the > > > > backtraces), you could wrap usleep_range() in a macro that does > > > > BUILD_BUG_ON(min == max) if the parameters are build time constants > > > > (they usually are). But you'd have to fix all the problem cases first. > > > > > > > > * You could try (to persuade Julia or Dan) to come up with a > > > > cocci/smatch check for usleep_range() calls where min == max, so we > > > > could get bug reports for this. This probably works on expressions, so > > > > this would catch also cases where the parameters aren't built timea, > > > > constants. > > > > You could also add a macro for usleep_range like > > > > #define usleep_range(a, b) \ > > ({ \ > > if (__builtin_constant_p(a) && __builtin_constant_p(b)) { \ > > if (a == b) \ > > __compiletime_warning("Better to use usleep_range with > > different values"); \ > > else if (a > b) \ > > __compiletime_error("usleep_range uses smaller value > > first"); \ > > } \ > > usleep_range(a, b); \ > > }) > > > > thanks for that "template" > > > and add parentheses around the actual function > > definition for usleep_range in kernel/time/timer.c > > so the macro works and these messages get emitted > > at compile-time. > > > > while compiletime warnings are a way to go I think that an > external tool is more effective than anoying eveyone during > build I don't. Annoying people at build-time is probably _the single most_ effective way to get source code defects fixed.
Re: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
Hi Florian, On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli wrote: > Add support for loading bitstreams on the Altera Cyclone II FPGA > populated on the TS-7300 board. This is done through the configuration > and data registers offered through a memory interface between the EP93xx > SoC and the FPGA via an intermediate CPLD device. > > The EP93xx SoC on the TS-7300 does not have direct means of configuring > the on-board FPGA other than by using the special memory mapped > interface to the CPLD. No other entity on the system can control the > FPGA bitstream. > > Signed-off-by: Florian Fainelli > --- > drivers/fpga/Kconfig | 7 ++ > drivers/fpga/Makefile | 1 + > drivers/fpga/ts73xx-fpga.c | 163 > + > 3 files changed, 171 insertions(+) > create mode 100644 drivers/fpga/ts73xx-fpga.c > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index ce861a2853a4..d9cbef60db80 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -33,6 +33,13 @@ config FPGA_MGR_SOCFPGA_A10 > help > FPGA manager driver support for Altera Arria10 SoCFPGA. > > +config FPGA_MGR_TS73XX > + tristate "Technologic Systems TS-73xx SBC FPGA Manager" > + depends on ARCH_EP93XX && MACH_TS72XX > + help > + FPGA manager driver support for the Altera Cyclone II FPGA > + present on the TS-73xx SBC boards. > + > config FPGA_MGR_ZYNQ_FPGA > tristate "Xilinx Zynq FPGA" > depends on ARCH_ZYNQ || COMPILE_TEST > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > index 8df07bcf42a6..a1160169e6d9 100644 > --- a/drivers/fpga/Makefile > +++ b/drivers/fpga/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o > # FPGA Manager Drivers > obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o > obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o > +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o > obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o > > # FPGA Bridge Drivers > diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c > new file mode 100644 > index ..38d78d8c6b1e > --- /dev/null > +++ b/drivers/fpga/ts73xx-fpga.c > @@ -0,0 +1,163 @@ > +/* > + * Technologic Systems TS-73xx SBC FPGA loader > + * > + * Copyright (C) 2016 Florian Fainelli > + * > + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on > + * TS-7300, heavily based on load_fpga.c in their vendor tree. > + * > + * 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; version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define TS73XX_FPGA_DATA_REG 0 > +#define TS73XX_FPGA_CONFIG_REG 1 > + > +#define TS73XX_FPGA_WRITE_DONE 0x1 > +#define TS73XX_FPGA_WRITE_DONE_TIMEOUT 1000/* us */ > +#define TS73XX_FPGA_RESET 0x2 > +#define TS73XX_FPGA_RESET_LOW_DELAY30 /* us */ > +#define TS73XX_FPGA_RESET_HIGH_DELAY 80 /* us */ > +#define TS73XX_FPGA_LOAD_OK0x4 > +#define TS73XX_FPGA_CONFIG_LOAD0x8 > + > +struct ts73xx_fpga_priv { > + void __iomem*io_base; > + struct device *dev; > +}; > + > +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr) > +{ > + return FPGA_MGR_STATE_UNKNOWN; > +} > + > +static int ts73xx_fpga_write_init(struct fpga_manager *mgr, > + struct fpga_image_info *info, > + const char *buf, size_t count) > +{ > + struct ts73xx_fpga_priv *priv = mgr->priv; > + > + /* Reset the FPGA */ > + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG); > + udelay(TS73XX_FPGA_RESET_LOW_DELAY); > + writeb(TS73XX_FPGA_RESET, priv->io_base + TS73XX_FPGA_CONFIG_REG); > + udelay(TS73XX_FPGA_RESET_HIGH_DELAY); > + > + return 0; > +} > + > +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf, > +size_t count) > +{ > + struct ts73xx_fpga_priv *priv = mgr->priv; > + size_t i = 0; > + int ret; > + u8 reg; > + > + while (count--) { > + ret = readb_poll_timeout(priv->io_base + > TS73XX_FPGA_CONFIG_REG, > +reg, !(reg & TS73XX_FPGA_WRITE_DONE), > +1, TS73XX_FPGA_WRITE_DONE_TIMEOUT); > + if (ret < 0) > + return ret; > + > + writeb(buf[i], priv->io_base +
[PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel driver. This panel has 1440x2560 resolution in 5.7-inch physical panel in the TM2 device. Signed-off-by: Donghwa Lee Signed-off-by: Hyungwon Hwang Signed-off-by: Hoegeun Kwon --- .../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++ drivers/gpu/drm/panel/Kconfig | 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756 + 4 files changed, 815 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt new file mode 100644 index 000..1f41f24 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt @@ -0,0 +1,52 @@ +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel + +Required properties: + - compatible: "samsung,s6e3ha2" + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - enable-gpios: a GPIO spec for the panel enable pin + - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio pin + +Optional properties: + - display-timings: timings for the connected panel as described by [1] + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [2]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + panel@0 { + compatible = "samsung,s6e3ha2"; + reg = <0>; + vdd3-supply = <&ldo27_reg>; + vci-supply = <&ldo28_reg>; + reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>; + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>; + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>; + + display-timings { + timing-0 { + clock-frequency = <0>; + hactive = <1440>; + vactive = <2560>; + hfront-porch = <1>; + hback-porch = <1>; + hsync-len = <1>; + vfront-porch = <1>; + vback-porch = <15>; + vsync-len = <1>; + }; + }; + + port { + dsi_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + }; diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 62aba97..e1a2fcd 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -58,6 +58,12 @@ config DRM_PANEL_SAMSUNG_S6E8AA0 select DRM_MIPI_DSI select VIDEOMODE_HELPERS +config DRM_PANEL_SAMSUNG_S6E3HA2 + tristate "Samsung S6E3HA2 DSI video mode panel" + depends on OF + select DRM_MIPI_DSI + select VIDEOMODE_HELPERS + config DRM_PANEL_SHARP_LQ101R1SX01 tristate "Sharp LQ101R1SX01 panel" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index a5c7ec0..993699b 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -4,5 +4,6 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += panel-panasonic-vvx10f034n00.o obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c new file mode 100644 index 000..a6ad63b --- /dev/null +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c @@ -0,0 +1,756 @@ +/* + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver. + * + * Copyright (c) 2016 Samsung Electronics Co., Ltd. + * Donghwa Lee + * Hyungwon Hwang + * Hoegeun Kwon + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define S6E3HA2_MIN_BRIGHTNESS 0 +#define S6E3HA
[PATCH 2/2] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hyungwon Hwang This patch add the panel device tree node for S6E3HA2 display controller to TM2 dts. Signed-off-by: Hyungwon Hwang Signed-off-by: Andrzej Hajda Signed-off-by: Chanwoo Choi Signed-off-by: Hoegeun Kwon --- arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 +++ 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts index db879f4..4ad2332 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts @@ -252,11 +252,44 @@ reg = <1>; dsi_out: endpoint { + remote-endpoint = <&dsi_in>; samsung,burst-clock-frequency = <51200>; samsung,esc-clock-frequency = <1600>; }; }; }; + + panel@0 { + compatible = "samsung,s6e3ha2"; + reg = <0>; + vdd3-supply = <&ldo27_reg>; + vci-supply = <&ldo28_reg>; + reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>; + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>; + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>; + power-on-delay = <120>; + reset-delay = <5>; + + display-timings { + timing-0 { + clock-frequency = <1487>; + hactive = <1440>; + vactive = <2560>; + hfront-porch = <1>; + hback-porch = <1>; + hsync-len = <1>; + vfront-porch = <1>; + vback-porch = <15>; + vsync-len = <1>; + }; + }; + + port { + dsi_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + }; }; &hsi2c_0 { -- 1.9.1
[PATCH 0/2] Add support for the S6E3HA2 panel on TM2 board
Purpose of this patch is add support for S6E3HA2 AMOLED panel on the TM2 board. The first patch adds support for S6E3HA2 panel device tree document and driver, the second patch add support for S6E3HA2 panel device tree. Hoegeun Kwon (1): drm/panel: Add support for S6E3HA2 panel driver on TM2 board Hyungwon Hwang (1): arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board .../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++ arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 + drivers/gpu/drm/panel/Kconfig | 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756 + 5 files changed, 848 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c -- 1.9.1
Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
On Wed, Dec 14, 2016 at 01:05:51PM +0800, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote: > > > > I have found two solutions: > > No we already have algif_rng so let's not confuse things even > further by making hwrng take PRNGs. > But algif_rng is not accessible from user space without any coding. So no easy "random" data with some cat /dev/. Clearly users of the 3 already intree hw_random PRNG will see that like a regresion. Regards Corentin Labbe
Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access
On Wed, 2016-12-14 at 11:59 +1030, Joel Stanley wrote: > > On Tue, Dec 6, 2016 at 1:27 PM, Andrew Jeffery wrote: > > The registers for the bt-bmc device live under the Aspeed LPC > > controller. Devicetree bindings have recently been introduced for the > > LPC controller where the "host" portion of the LPC register space is > > described as a syscon device. Future devicetrees describing the bt-bmc > > device should nest its node under the appropriate "simple-mfd", "syscon" > > compatible node. > > > > This change allows the bt-bmc driver to function with both syscon and > > non-syscon- based devicetree descriptions by always using a regmap for > > register access, either retrieved from the parent syscon device or > > instantiated if none exists. > > > > The patch has been tested on an OpenPOWER Palmetto machine, successfully > > booting, rebooting and powering down the host. > > > > > > Signed-off-by: Andrew Jeffery > > --- > > drivers/char/ipmi/Kconfig | 1 + > > drivers/char/ipmi/bt-bmc.c | 82 > > ++ > > 2 files changed, 62 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig > > index 7f816655cbbf..b5d48d9af124 100644 > > --- a/drivers/char/ipmi/Kconfig > > +++ b/drivers/char/ipmi/Kconfig > > @@ -79,6 +79,7 @@ endif # IPMI_HANDLER > > > > config ASPEED_BT_IPMI_BMC > > depends on ARCH_ASPEED > > If you do a v2 of this series it would be great to add || COMPILE_TEST here. > > > +depends on REGMAP && REGMAP_MMIO && MFD_SYSCON > > tristate "BT IPMI bmc driver" > > help > > Provides a driver for the BT (Block Transfer) IPMI interface > > diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c > > index fc9e8891eae3..ca1e20f6c6c5 100644 > > --- a/drivers/char/ipmi/bt-bmc.c > > +++ b/drivers/char/ipmi/bt-bmc.c > > @@ -12,10 +12,13 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > +#include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -60,7 +63,8 @@ > > struct bt_bmc { > > struct device dev; > > struct miscdevice miscdev; > > - void __iomem*base; > > + struct regmap *map; > > + int offset; > > int irq; > > wait_queue_head_t queue; > > struct timer_list poll_timer; > > @@ -69,14 +73,31 @@ struct bt_bmc { > > > > static atomic_t open_count = ATOMIC_INIT(0); > > > > +static struct regmap_config bt_regmap_cfg = { > > const? Good point. Is it worth a v2? > > > + .reg_bits = 32, > > + .val_bits = 32, > > + .reg_stride = 4, > > +}; > > + > > static u8 bt_inb(struct bt_bmc *bt_bmc, int reg) > > { > > - return ioread8(bt_bmc->base + reg); > > + uint32_t val = 0; > > + int rc; > > + > > + rc = regmap_read(bt_bmc->map, bt_bmc->offset + reg, &val); > > + WARN(rc != 0, "%s:%d: regmap_read() failed: %d\n", > > + __FILE__, __LINE__, rc); > > Under what circumstances do we expect the read to fail? By the regmap_read() implementation for MMIO it should never fail. If it does, then we should tell someone about it. > > This isn't much cleaner, but I prefer it slightly: > > rc = regmap_read(bt_bmc->map, bt_bmc->offset + reg, &val); > if (rc) { > dev_warn(bt_bmc->dev, "read failed %d\n", rc); > return rc; > } > > return val; bt_inb() currently returns a u8 type, and as such no caller performs error checking. While your suggestion might seem slightly preferable, it feels likely "slightly preferable" might fail to take into account the cascading effect of changing the return type and testing for errors at each of the (transitive) call-sites. I think the additional code required makes your suggestion less attractive given that the call should never fail. If you decide you feel strongly about it I can make the change. > > > + > > + return rc == 0 ? (u8) val : 0; > > } > > > > static void bt_outb(struct bt_bmc *bt_bmc, u8 data, int reg) > > { > > - iowrite8(data, bt_bmc->base + reg); > > + int rc; > > + > > + rc = regmap_write(bt_bmc->map, bt_bmc->offset + reg, data); > > + WARN(rc != 0, "%s:%d: regmap_write() failed: %d\n", > > + __FILE__, __LINE__, rc); > > } > > > > static void clr_rd_ptr(struct bt_bmc *bt_bmc) > > @@ -367,14 +388,18 @@ static irqreturn_t bt_bmc_irq(int irq, void *arg) > > { > > struct bt_bmc *bt_bmc = arg; > > u32 reg; > > + int rc; > > + > > + rc = regmap_read(bt_bmc->map, bt_bmc->offset + BT_CR2, ®); > > + if (rc) > > + return IRQ_NONE; > > > > - reg = ioread32(bt_bmc->base + BT_CR2); > > reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY; > > if (!reg) > > return IRQ_NONE; > > > >
RE: ATH9 driver issues on ARM64
> On Sat, Dec 10, 2016 at 02:40:48PM +, Bharat Kumar Gogada wrote: > > Hi, > > > > After taking some more lecroy traces, we see that after 2nd ASSERT from EP > on ARM64 we see continuous data movement of 32 dwords or 12 dwords and > never sign of DEASSERT. > > Comparatively on working traces (x86) after 2nd assert there are only BAR > register reads and writes and then DEASSERT, for almost most of the interrupts > and we haven't seen 12 or 32 dwords data movement on this trace. > > > > I did not work on EP wifi/network drivers, any help why EP needs those many > number of data at scan time ? > > The device doesn't know whether it's in an x86 or an arm64 system. If it > works > differently, it must be because the PCI core or the driver is programming the > device differently. > > You should be able to match up Memory transactions from the host in the trace > with things the driver does. For example, if you see an Assert_INTx message > from the device, you should eventually see a Memory Read from the host to get > the ISR, i.e., some read done in the bowels of ath9k_hw_getisr(). > > I don't know how the ath9k device works, but there must be some Memory Read > or Write done by the driver that tells the device "we've handled this > interrupt". > The device should then send a Deassert_INTx; of course, if the device still > requires service, e.g., because it has received more packets, it might leave > the > INTx asserted. > > I doubt you'd see exactly the same traces on x86 and arm64 because they aren't > seeing the same network packets and the driver is executing at different > rates. > But you should at least be able to identify interrupt assertion and the > actions of > the driver's interrupt service routine. Thanks Bjorn. As you mentioned we did try to debug in that path. After we start scan after 2nd ASSERT we see lots of 32 and 12 dword data, and in function void ath9k_hw_enable_interrupts(struct ath_hw *ah) { ... .. REG_WRITE(ah, AR_IER, AR_IER_ENABLE); // EP driver hangs at this position after 2nd ASSERT // The following writes are not happening if (!AR_SREV_9100(ah)) { REG_WRITE(ah, AR_INTR_ASYNC_ENABLE, async_mask); REG_WRITE(ah, AR_INTR_ASYNC_MASK, async_mask); REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default); REG_WRITE(ah, AR_INTR_SYNC_MASK, sync_default); } ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n", REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER)); } The above funtion is invoked from tasklet. I tried several boots every it stops here. The condition (!AR_SREV_9100(ah)) is true as per before 1st ASSERT handling. Regards, Bharat > > > > Hello there, > > > > > > as this is a thread about ath9k and ARM64, i'm not sure if i should > > > answer here or not, but i have similar "stalls" with ath9k on x86_64 > > > (starting with 4.9rc), stack trace is posted down below where the original > ARM64 stall traces are. > > > > > > Greetings, > > > > > > Tobias > > > > > > > > > On 08.12.2016 18:36, Kalle Valo wrote: > > > > Bharat Kumar Gogada writes: > > > > > > > >> > [+cc Kalle, ath9k list] > > > > Thanks, but please also CC linux-wireless. Full thread below for > > > > the folks there. > > > > > > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada > wrote: > > > Hi, > > > > > > Did anyone test Atheros ATH9 > > > driver(drivers/net/wireless/ath/ath9k/) > > > on ARM64. The end point is TP link wifi card with which > > > supports only legacy interrupts. > > > >>> If it works on other arches and the arm64 PCI enumeration works, > > > >>> my first guess would be an INTx issue, e.g., maybe the driver is > > > >>> waiting for an interrupt that never arrives. > > > >> We are not sure for now. > > > We are trying to test it on ARM64 with > > > (drivers/pci/host/pcie-xilinx-nwl.c) as root port. > > > > > > EP is getting enumerated and able to link up. > > > > > > But when we start scan system gets hanged. > > > >>> When you say the system hangs when you start a scan, I assume > > > >>> you mean a wifi scan, not the PCI enumeration. A problem with a > > > >>> wifi scan might cause a *process* to hang, but it shouldn't hang > > > >>> the entire system. > > > >>> > > > >> Yes wifi scan. > > > When we took trace we see that after we start scan assert > > > message is sent but there is no de assert from end point. > > > >>> Are you talking about a trace from a PCIe analyzer? Do you see > > > >>> an Assert_INTx PCIe message on the link? > > > >>> > > > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx > > > >> happening > > > when we do interface link up. > > > >> When we have less debug prints in Atheros driver, and do wifi > > > >> scan we s
Re: [PATCH] include/linux/kernel.h: fixed coding style issues
On Wed, 2016-12-14 at 00:52 +, Piotr Gregor wrote: > Apply coding style suggested by Documentation/CodingStyle > and checkpatch.pl script. Fix 59 warnings and 24 errors > reported by checkpatch.pl Hello Piotr. Please make the first patch you submit against something in drivers/staging and not a core kernel file like kernel.h Welcome in any case. Joe
Re: Scheduler patches: 6x performance increase when system is under heavy load
> Which of the 4 patches does this? I used all the 4 patches at the same time. Each patch fixes a different bug. Would you like me to try each of them individually? Were you already aware of each of these bugs? > Also, what hypervisor are you using and what does the output of booting > with "sched_debug" look like? I was running the distro in VirualBox on Fedora. Here's the info from /proc/sched_debug: https://justpaste.it/11dhb dmesg: https://justpaste.it/11dhr > Lastly, can you reproduce on real hardware? No. On real hardware, I tested in Ubuntu on an i7-4790 3.60GHz CPU without disabling HT and I saw no difference between CFS, the patched kernel and MuQSS. If I get to know a reason why one would be better than the other, I'd take the time to test it on more hardware. I'm curious how I got such a performance improvement in my VM. On Tue, Dec 13, 2016 at 8:40 AM, Peter Zijlstra wrote: > On Sun, Dec 11, 2016 at 04:41:51PM -0500, Alexandre-Xavier Labonté-Lamoureux > wrote: >> >> Here are my results (using "time make -j32" on my VM that has 4 cores): >> >> Kernel 4.8.14 >> real 26m56.151s >> user 79m52.472s >> sys 7m42.964s >> >> Same kernel, but patched: >> real 4m25.238s >> user 13m52.932s >> sys 1m25.820s >> >> I hope you guys will look into this. > > Which of the 4 patches does this? > > Also, what hypervisor are you using and what does the output of booting > with "sched_debug" look like? > > Lastly, can you reproduce on real hardware?
[PATCH] drm/mediatek: Support UYVY and YUYV format for overlay
MT8173 overlay can support UYVY and YUYV format, we add the format in DRM driver. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c index 019b7ca..0a340f3 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c @@ -44,6 +44,8 @@ #define OVL_CON_CLRFMT_RGB888 (1 << 12) #define OVL_CON_CLRFMT_RGBA(2 << 12) #define OVL_CON_CLRFMT_ARGB(3 << 12) +#define OVL_CON_CLRFMT_UYVY(4 << 12) +#define OVL_CON_CLRFMT_YUYV(5 << 12) #defineOVL_CON_AEN BIT(8) #defineOVL_CON_ALPHA 0xff @@ -161,6 +163,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt) case DRM_FORMAT_XBGR: case DRM_FORMAT_ABGR: return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP; + case DRM_FORMAT_YUYV: + return OVL_CON_CLRFMT_YUYV; + case DRM_FORMAT_UYVY: + return OVL_CON_CLRFMT_UYVY; } } diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index c461a23..b94c6ee 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -28,6 +28,8 @@ DRM_FORMAT_XRGB, DRM_FORMAT_ARGB, DRM_FORMAT_RGB565, + DRM_FORMAT_YUYV, + DRM_FORMAT_UYVY, }; static void mtk_plane_reset(struct drm_plane *plane) -- 1.9.1
Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote: > > I have found two solutions: No we already have algif_rng so let's not confuse things even further by making hwrng take PRNGs. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] drm/bridge: analogix_dp: set the DPCD600 during disabling the psr
Hi, On 12/12/2016 08:28 PM, Sean Paul wrote: On Fri, Dec 9, 2016 at 9:49 PM, Caesar Wang wrote: Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host device, that will cause the panel hang on the startup display. The root cause we use the fast link mode during enter and exit the psr, this issue is gone if switching the fast link to main link mode. Cc: Archit Taneja Do we want this as a fix in 4.10? Or is it okay to get it in 4.11? In other words, should this go to drm-misc-next or drm-misc-fixes? Thanks, Archit Signed-off-by: Caesar Wang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 6e0447f..6a5347b 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -133,6 +133,7 @@ int analogix_dp_disable_psr(struct device *dev) { struct analogix_dp_device *dp = dev_get_drvdata(dev); struct edp_vsc_psr psr_vsc; + int ret; if (!dp->psr_support) return -EINVAL; @@ -147,6 +148,10 @@ int analogix_dp_disable_psr(struct device *dev) psr_vsc.DB0 = 0; psr_vsc.DB1 = 0; + ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0); + if (ret != 1) + dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret); + analogix_dp_send_psr_spd(dp, &psr_vsc); return 0; } -- 2.7.4 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote: THS8135 is a configurable video DAC, but no configuration is actually necessary to make it work. For now use the dumb-vga-dac driver to support it. Queued to drm-misc-next Archit Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index e570698..86e9f9c 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -237,6 +237,7 @@ static int dumb_vga_remove(struct platform_device *pdev) static const struct of_device_id dumb_vga_match[] = { { .compatible = "dumb-vga-dac" }, + { .compatible = "ti,ths8135" }, {}, }; MODULE_DEVICE_TABLE(of, dumb_vga_match); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v7 2/5] drm: bridge: add DT bindings for TI ths8135
Hi, On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote: THS8135 is a configurable video DAC. Add DT bindings for this chip. Queued to drm-misc-next Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart Acked-by: Rob Herring --- .../bindings/display/bridge/ti,ths8135.txt | 46 ++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new file mode 100644 index 000..6ec1a88 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt @@ -0,0 +1,46 @@ +THS8135 Video DAC +- + +This is the binding for Texas Instruments THS8135 Video DAC bridge. + +Required properties: + +- compatible: Must be "ti,ths8135" + +Required nodes: + +This device has two video ports. Their connections are modelled using the OF +graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for RGB input +- Video port 1 for VGA output + +Example +--- + +vga-bridge { + compatible = "ti,ths8135"; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + vga_bridge_in: endpoint { + remote-endpoint = <&lcdc_out_vga>; + }; + }; + + port@1 { + reg = <1>; + + vga_bridge_out: endpoint { + remote-endpoint = <&vga_con_in>; + }; + }; + }; +}; -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs
On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote: > On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote: > > The driver put a constant buffer of all zeros on the stack and > > pointed a scatterlist entry at it in two places. This doesn't work > > with virtual stacks. Use ZERO_PAGE instead. > > Wait a second... > > > - sg_set_buf(&sg_out[1], pad, sizeof pad); > > + sg_set_buf(&sg_out[1], empty_zero_page, 16); > > My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what > exactly is the code trying to do? The old code makes no sense. It's > setting the *output* buffer to zeroed padding. It's decrypting so I presume it just needs to the extra space for the padding and the result will be thrown away. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Remaining crypto API regressions with CONFIG_VMAP_STACK
On Tue, Dec 13, 2016 at 09:06:31AM -0800, Andy Lutomirski wrote: > > > Having 0 as type and CRYPTO_ALG_ASYNC as mask in general means > > that we're requesting a sync algorithm (i.e., ASYNC bit off). > > > > However, it is completely unnecessary for shash as they can never > > be async. So this could be changed to just ("michael_mic", 0, 0). > > I'm confused by a bunch of this. > > 1. Is it really the case that crypto_alloc_xyz(..., CRYPTO_ALG_ASYNC) > means to allocate a *synchronous* transform? That's not what I > expected. crypto_alloc_xyz(name, 0, CRYPTO_ALG_ASYNC) allocates a sync tfm and crypto_alloc_xyz(name, CRYPTO_ALG_ASYNC, CRYPTO_ALG_ASYNC) allocates an async tfm while crypto_alloc_xyz(name, 0, 0) does not care whether the allocated tfm is sync or asnc. > 2. What guarantees that an async request is never allocated on the > stack? If it's just convention, could an assertion be added > somewhere? Sure we can add an assertion. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] remoteproc: Remove firmware_loading_complete
Hi Sarangdhar, [auto build test ERROR on next-20161213] [also build test ERROR on v4.9] [cannot apply to remoteproc/for-next v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Sarangdhar-Joshi/remoteproc-Remove-firmware_loading_complete/20161214-075027 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/soc/ti/wkup_m3_ipc.c: In function 'wkup_m3_rproc_boot_thread': >> drivers/soc/ti/wkup_m3_ipc.c:373:36: error: 'struct rproc' has no member >> named 'firmware_loading_complete' wait_for_completion(&m3_ipc->rproc->firmware_loading_complete); ^~ vim +373 drivers/soc/ti/wkup_m3_ipc.c cdd5de50 Dave Gerlach 2015-09-22 367 cdd5de50 Dave Gerlach 2015-09-22 368 static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc) cdd5de50 Dave Gerlach 2015-09-22 369 { cdd5de50 Dave Gerlach 2015-09-22 370 struct device *dev = m3_ipc->dev; cdd5de50 Dave Gerlach 2015-09-22 371 int ret; cdd5de50 Dave Gerlach 2015-09-22 372 cdd5de50 Dave Gerlach 2015-09-22 @373 wait_for_completion(&m3_ipc->rproc->firmware_loading_complete); cdd5de50 Dave Gerlach 2015-09-22 374 cdd5de50 Dave Gerlach 2015-09-22 375 init_completion(&m3_ipc->sync_complete); cdd5de50 Dave Gerlach 2015-09-22 376 :: The code at line 373 was first introduced by commit :: cdd5de500b2c90d5181ebc963826019a0a4234ba soc: ti: Add wkup_m3_ipc driver :: TO: Dave Gerlach :: CC: Tony Lindgren --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[GIT PULL] Thermal management updates for v4.10-rc1
Hi, Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next to receive the latest Thermal Management updates for v4.10-rc1 with top-most commit 0faf7dd5a947006978b549dfe29a01b710becf4a: MAINTAINERS: Samsung: Update maintainer for PWM FAN and SAMSUNG THERMAL (2016-12-13 11:20:23 +0800) on top of commit 23400ac997062647f2b63c82030d189671b1effe: Merge branch 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-11-22 13:53:01 -0800) Specifics: - Thermal core code reorganization and cleanup. Two new files are created for thermal sysfs I/F code and thermal helper functions. From: Eduardo Valentin. - Sanitize hotplug and locking for x86_pkg_temp driver. From: Thomas Gleixner. - Update MAINTAINER file for pwm-fan driver and Samsung thermal driver. From: Lukasz Majewski. - Fix module auto-load for max77620, tango and db8500 thermal driver. From: Javier Martinez Canillas. - Fix a bug that thermal hwmon sysfs I/F returns wrong critical trip point temperature value. From: Krzysztof Kozlowski. - Add Skylake PCH 100 series support for intel_pch_thermal driver. From: OGAWA Hirofumi. - Small fixes and cleanups for platform thermal drivers. From Julia Lawall, Luis Henriques, Leo Yan, Stephen Boyd, Shawn Lin, Javi Merino and Lukasz Luba. thanks, rui Eduardo Valentin (49): thermal: core: prevent zones with no types to be registered thermal: core: group thermal_zone DEVICE_ATTR's declarations thermal: core: group device_create_file() calls that are always created thermal: core: use dev.groups to manage always present tz attributes thermal: core: move emul_temp creation to tz->device.groups thermal: core: move mode attribute to tz->device.groups thermal: core: move passive attr to tz->device.groups thermal: core: improve power actor documentation thermal: core: move power actor code out of sysfs I/F section thermal: core: remove useless empty line thermal: core: fix style on remove_trip_attrs() thermal: core: move the trip attrs to the tz sysfs I/F section thermal: core: create tz->device.groups dynamically thermal: core: move trips attributes to tz->device.groups thermal: core: remove unnecessary device_remove() calls thermal: core: split passive_store thermal: core: split policy_store thermal: core: split available_policies_show() thermal: core: move to_thermal_zone() macro to header file thermal: core: treat correctly the return value of *scanf calls thermal: core: match parenthesis on code alignment thermal: core: move thermal_zone sysfs to thermal_sysfs.c thermal: core: move to_cooling_device macro to header file thermal: core: move cooling device sysfs to thermal_sysfs.c thermal: core: remove a couple of style issues on helpers thermal: core: introduce thermal_helpers.c thermal: core: group functions related to governor handling thermal: core: move idr handling to device management section thermal: core: small style fix on __unbind() helper thermal: core: move __unbind() helper to where it is used thermal: core: move bind_cdev() to where it is used thermal: core: move bind_tz() to where it is used thermal: core: fix couple of style issues on __bind() helper thermal: core: move __bind() to where it is used thermal: core: add inline to print_bind_err_msg() thermal: core: move notify to the zone update section thermal: core: add a comment describing the main update loop thermal: core: add a comment describing the power actor section thermal: core: add a comment describing the device management section thermal: sysfs: remove symbols of emul_temp when config is disabled thermal: core: remove FSF address in the GPL notice thermal: core: small style fix when checking for __find_governor() thermal: core: standardize line breaking alignment thermal: core: remove void function return statements thermal: core: remove style warnings and checks thermal: core: improve kerneldoc entry of thermal_cooling_device_unregister thermal: core: use kzalloc(sizeof(*ptr),...) thermal: sysfs: use kcalloc() instead of kzalloc() thermal: core: move slop and offset helpers to thermal_helpers.c Javi Merino (1): devfreq_cooling: pass a pointer to devfreq in the power model callbacks Javier Martinez Canillas (3): thermal: max77620: Fix module autoload thermal: tango: Fix module autoload thermal: db8500: Fix module autoload Julia Lawall (2): thermal: hwmon: use permission-specific DEVICE_ATTR variants thermal: int340x_thermal: use permission-specific DEVICE_ATTR variants Krzysztof Kozlowski (1): thermal: hwmon: Properly report critical temperature in sysfs Le
linux-next: Tree for Dec 14
Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161213: The vfs-miklos tree gained a conflict against the ubifs tree. The akpm-current tree gained a conflict against the jc_docs tree. Non-merge commits (relative to Linus' tree): 4498 4320 files changed, 189429 insertions(+), 94239 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 245 trees (counting Linus' and 35 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (b92e09bb5bf4 Merge branch 'for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to arm64 producing host-arch debs) Merging arc-current/for-curr (7badf6fefca8 ARC: axs10x: really enable ARC PGU) Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to definitions") Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (dadc4a1bb9f0 powerpc/64: Fix placement of .text to be immediately following .head.text) Merging sparc/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris) Merging net/master (3e1ed981b7a9 netlink: revert broken, broken "2-clause nla_ok()") Merging ipsec/master (bc3913a5378c Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging netfilter/master (a220871be66f virtio-net: correctly enable multiqueue) Merging ipvs/master (045169816b31 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 32-byte SSIDs) Merging mac80211/master (d8da0b5d64d5 mac80211: Ensure enough headroom when forwarding mesh pkt) Merging sound-current/for-linus (995c6a7fd9b9 ALSA: hiface: Fix M2Tech hiFace driver sampling rate change) Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)) Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5) Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3) Merging usb.current/usb-linus (e5517c2a5a49 Linux 4.9-rc7) Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong parenthesis in ffs_func_req_match()) Merging usb-serial-fixes/usb-linus (46490c347df4 USB: serial: option: add dlink dwm-158) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu) Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5) Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5) Merging input-current/for-linus (2425f1808123 Input: change KEY_DATA from 0x275 to 0x277) Merging crypto-current/master (04b46fbdea5e crypto: testmgr - fix overlap in chunked tests again) Merging ide/master (797cee982eef Merge br
Re: netlink: GPF in sock_sndtimeo
On 2016-12-13 16:17, Cong Wang wrote: > On Tue, Dec 13, 2016 at 2:52 AM, Richard Guy Briggs wrote: > > It is actually the audit_pid and audit_nlk_portid that I care about > > more. The audit daemon could vanish or close the socket while the > > kernel sock to which it was attached is still quite valid. Accessing > > the set of three atomically is the urge. I wonder if it makes more > > sense to test for the presence of auditd using audit_sock rather than > > audit_pid, but still keep audit_pid for our reporting and replacement > > strategy. Another idea would be to put the three in one struct. > > Note, the process has audit_pid should hold a refcnt to the netns too, > so the netns can't be gone until that process is gone. I noted that. I did wonder if there might be a problem if all the processes were moved to another netns with the struct sock stuck in the now process-void netns. This is alluded-to in 6f285b19d09f ("audit: Send replies in the proper network namespace."). > > Can someone explain how they think the original test was able to trigger > > this GPF? Network namespace shutdown while something pretended to set > > up a new auditd? That's impressive for a fuzzer if that's the case... > > Is there an strace? I guess it is all in test(). > > I am surprised you still don't get the race condition even when you > are now working on v2... > > The race happens in this scenarios : > > 1) Create a new netns > > 2) In the new netns, communicate with kauditd to set audit_sock > > 3) Generate some audit messages, so kauditd will keep sending them > via audit_sock > > 4) exit the netns > > 5) the previous audit_sock is now going away, but kaudit_sock could still > access it in this small window. Ah ok that fits... - RGB -- Richard Guy Briggs Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635
Re: [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error
On Wed, Dec 14, 2016 at 09:40:02AM +0800, Boqun Feng wrote: > On Wed, Dec 14, 2016 at 08:47:55AM +0800, Boqun Feng wrote: > > On Tue, Dec 13, 2016 at 10:36:47AM -0800, Paul E. McKenney wrote: > > > On Wed, Dec 14, 2016 at 02:09:27AM +0800, Boqun Feng wrote: > > > > 2016年12月14日 上午1:17,"Mark Rutland" 写道: > > > > > > > > > > Hi, > > > > > > > > > > On Tue, Dec 13, 2016 at 10:56:46AM +, Colin King wrote: > > > > > > From: Colin Ian King > > > > > > > > > > > > mask and bit are unsigned longs, so if bit is 31 we end up sign > > > > > > extending the 1 and mask ends up as 0x8000. Fix this > > > > > > by explicitly adding integer suffix UL ensure 1 is a unsigned long > > > > > > rather than an signed int. > > > > > > > > > > > > Issue found with static analysis with CoverityScan, CID 1388564 > > > > > > > > > > > > Fixes: 8965c3ce4718754db ("rcu: Use > > > > leaf_node_for_each_mask_possible_cpu() in force_qs_rnp()") > > > > > > Signed-off-by: Colin Ian King > > > > > > --- > > > > > > kernel/rcu/tree.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > > > > index 10162ac..6ecedd8 100644 > > > > > > --- a/kernel/rcu/tree.c > > > > > > +++ b/kernel/rcu/tree.c > > > > > > @@ -3051,7 +3051,7 @@ static void force_qs_rnp(struct rcu_state > > > > > > *rsp, > > > > > > > > > > > > leaf_node_for_each_mask_possible_cpu(rnp, rnp->qsmask, > > > > bit, cpu) > > > > > > if (f(per_cpu_ptr(rsp->rda, cpu), isidle, > > > > > > maxj)) > > > > > > - mask |= 1 << bit; > > > > > > + mask |= 1UL << bit; > > > > > > > > > > So as to match the rest of the code altered in commit bc75e99983df1efd > > > > > ("rcu: Correctly handle sparse possible cpus"), and regardless of > > > > > naming, I think it'd be nicer to use leaf_node_cpu_bit(), e.g. > > > > > > > > > > leaf_node_for_each_mask_possible_cpu(rnp, rnp->qsmask, bit, > > > > > cpu) > > > > > if (f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj)) > > > > > mask |= leaf_node_cpu_bit(rnp, cpu); > > > > > > > > > > IMO, it would be nice to hide the iterator bit somehow, to match > > > > > for_each_leaf_node_possible_cpu(), which this largely looks similar to > > > > > otherwise. > > > > > > > > Good point. ;-) > > > > > > > > We can > > > > > > > > #define for_each_leaf_node_cpu(rnp, mask, cpu) \ > > > > for((cpu) = (rnp)->grplo + find _first_bit(mask, > > > > MASK_BITS(mask)); \ > > > > (cpu) >= (rnp)->grplo && (cpu) <= (rnp)->grphi; \ > > > > (cpu) = (rnp)->grplo + find _next_bit(mask, ..., > > > > leaf_node_cpu_bit(rnp, cpu) + 1))) \ > > > > if (!cpu_possible(cpu)) \ > > > > continue; \ > > > > else > > > > > > What is the purpose of the cpu_possible() check? > > > > > > > To filter out CPUs in range [grplo, grphi] but not in cpu_possible_mask. > > > > Hmm.. if rcu_cpu_starting(cpu) is never called with "impossible" cpu, > IOW, ->qsmask and ->expmask never mask "impossible" cpus, then this is > just an over-care check. > > I think I probably will remove this check eventually, let me audit the > code a little more for safety ;-) Much better! ;-) Thanx, Paul > Regards, > Boqun > > > Regards, > > Boqun > > > > > Thanx, Paul > > > > > > > Typing from my cellphone, plz ignore the bad formatting ;-) > > > > > > > > Regards, > > > > Boqun > > > > > > > > > Thanks, > > > > > Mark. > > > > >
Re: [PATCH 4.8 00/33] 4.8.15-stable review
On 12/13/2016 09:16 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.8.15 release. There are 33 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Dec 15 17:15:24 UTC 2016. Anything received after that time might be too late. Build results: total: 149 pass: 149 fail: 0 Qemu test results: total: 122 pass: 122 fail: 0 Details are available at http://kerneltests.org/builders. Guenter
Re: [PATCH 4.4 00/16] 4.4.39-stable review
On 12/13/2016 09:15 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.39 release. There are 16 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Dec 15 17:15:06 UTC 2016. Anything received after that time might be too late. Build results: total: 149 pass: 149 fail: 0 Qemu test results: total: 115 pass: 115 fail: 0 Details are available at http://kerneltests.org/builders. Guenter
Re: [PATCH] block_dev: don't update file access position for sync direct IO
On 12/13/2016 08:07 PM, Shaohua Li wrote: > For sync direct IO, generic_file_direct_write/generic_file_read_iter > will update file access position. Don't duplicate the update in > .direct_IO. This cause my raid array can't assemble. That's not great... Thanks, added. -- Jens Axboe
Re: [PATCH 3.12 00/38] 3.12.69-stable review
On 12/13/2016 11:52 AM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.69 release. There are 38 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Dec 15 20:52:26 CET 2016. Anything received after that time might be too late. Build results: total: 128 pass: 128 fail: 0 Qemu test results: total: 93 pass: 93 fail: 0 Details are available at http://kerneltests.org/builders. Guenter
Re: [RFC PATCH v3] audit: use proper refcount locking on audit_sock
On 2016-12-13 16:19, Cong Wang wrote: > On Tue, Dec 13, 2016 at 7:03 AM, Richard Guy Briggs wrote: > > @@ -1283,8 +1299,10 @@ static void __net_exit audit_net_exit(struct net > > *net) > > { > > struct audit_net *aunet = net_generic(net, audit_net_id); > > struct sock *sock = aunet->nlsk; > > + mutex_lock(&audit_cmd_mutex); > > if (sock == audit_sock) > > auditd_reset(); > > + mutex_unlock(&audit_cmd_mutex); > > This still doesn't look correct to me, b/c here we release the audit_sock > refcnt twice: > > 1) inside audit_reset() The audit_reset() refcount decrement corresponds to a setting of audit_sock only if audit_sock is still non-NULL. > 2) netlink_kernel_release() This refcount decrement corresponds to netlink_kernel_create(). - RGB -- Richard Guy Briggs Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635
Re: [kbuild-all] arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'
On Tue, Dec 13, 2016 at 05:02:40AM +0100, Ralf Baechle wrote: On Sun, Dec 11, 2016 at 09:04:48AM +0800, kbuild test robot wrote: FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 045169816b31b10faed984b01c390db1b32ee4c1 commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 1 year, 1 month ago config: mips-jmr3927_defconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc # save the attached .config to linux build tree make.cross ARCH=mips Which binutils are you using with this compiler? It's binutils debian version 2.27-8. Does this jmr3927_defconfig require a special mips compiler? I see there are 4 available gcc packages in debian: gcc-mips64el-linux-gnuabi64 gcc-mips64-linux-gnuabi64 gcc-mipsel-linux-gnu gcc-mips-linux-gnu The last one is used here. Thanks, Fengguang
[PATCH v2 4/4] random: use siphash24 instead of md5 for get_random_int/long
This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase diffusion. The previous md5 algorithm used a per-cpu md5 state, which caused successive calls to the function to chain upon each other. While it's not entirely clear that this kind of chaining is absolutely necessary when using a secure PRF like siphash24, it can't hurt, and the timing of the call chain does add a degree of natural entropy. So, in keeping with this design, instead of the massive per-cpu 64-byte md5 state, there is instead a per-cpu previously returned value for chaining. Signed-off-by: Jason A. Donenfeld Cc: Jean-Philippe Aumasson Cc: Ted Tso --- Changes from v1->v2: - Uses u64 instead of uint64_t - Uses get_cpu_ptr instead of get_cpu_var drivers/char/random.c | 50 +++--- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d6876d506220..61c4b45427dc 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -262,6 +262,7 @@ #include #include #include +#include #include #include @@ -2042,7 +2043,7 @@ struct ctl_table random_table[] = { }; #endif /* CONFIG_SYSCTL */ -static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] cacheline_aligned; +static u8 random_int_secret[SIPHASH24_KEY_LEN]; int random_int_secret_init(void) { @@ -2050,8 +2051,7 @@ int random_int_secret_init(void) return 0; } -static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) - __aligned(sizeof(unsigned long)); +static DEFINE_PER_CPU(u64, get_random_int_chaining); /* * Get a random word for internal kernel use only. Similar to urandom but @@ -2061,19 +2061,25 @@ static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) */ unsigned int get_random_int(void) { - __u32 *hash; unsigned int ret; + struct { + u64 chaining; + unsigned long ts; + unsigned long entropy; + pid_t pid; + } __packed combined; + u64 *chaining; if (arch_get_random_int(&ret)) return ret; - hash = get_cpu_var(get_random_int_hash); - - hash[0] += current->pid + jiffies + random_get_entropy(); - md5_transform(hash, random_int_secret); - ret = hash[0]; - put_cpu_var(get_random_int_hash); - + chaining = get_cpu_ptr(&get_random_int_chaining); + combined.chaining = *chaining; + combined.ts = jiffies; + combined.entropy = random_get_entropy(); + combined.pid = current->pid; + ret = *chaining = siphash24((u8 *)&combined, sizeof(combined), random_int_secret); + put_cpu_ptr(chaining); return ret; } EXPORT_SYMBOL(get_random_int); @@ -2083,19 +2089,25 @@ EXPORT_SYMBOL(get_random_int); */ unsigned long get_random_long(void) { - __u32 *hash; unsigned long ret; + struct { + u64 chaining; + unsigned long ts; + unsigned long entropy; + pid_t pid; + } __packed combined; + u64 *chaining; if (arch_get_random_long(&ret)) return ret; - hash = get_cpu_var(get_random_int_hash); - - hash[0] += current->pid + jiffies + random_get_entropy(); - md5_transform(hash, random_int_secret); - ret = *(unsigned long *)hash; - put_cpu_var(get_random_int_hash); - + chaining = get_cpu_ptr(&get_random_int_chaining); + combined.chaining = *chaining; + combined.ts = jiffies; + combined.entropy = random_get_entropy(); + combined.pid = current->pid; + ret = *chaining = siphash24((u8 *)&combined, sizeof(combined), random_int_secret); + put_cpu_ptr(chaining); return ret; } EXPORT_SYMBOL(get_random_long); -- 2.11.0
[PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform
This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. Signed-off-by: Jason A. Donenfeld Cc: Andi Kleen --- Changes from v1->v2: - Rebased on the latest 4.10, and now uses top 32-bits of siphash for the optional ts value. net/core/secure_seq.c | 160 +- 1 file changed, 79 insertions(+), 81 deletions(-) diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c index 88a8e429fc3e..abadc79cd5d3 100644 --- a/net/core/secure_seq.c +++ b/net/core/secure_seq.c @@ -1,3 +1,5 @@ +/* Copyright (C) 2016 Jason A. Donenfeld . All Rights Reserved. */ + #include #include #include @@ -8,14 +10,14 @@ #include #include #include - +#include #include #if IS_ENABLED(CONFIG_IPV6) || IS_ENABLED(CONFIG_INET) +#include #include -#define NET_SECRET_SIZE (MD5_MESSAGE_BYTES / 4) -static u32 net_secret[NET_SECRET_SIZE] cacheline_aligned; +static u8 net_secret[SIPHASH24_KEY_LEN]; static __always_inline void net_secret_init(void) { @@ -44,44 +46,39 @@ static u32 seq_scale(u32 seq) u32 secure_tcpv6_sequence_number(const __be32 *saddr, const __be32 *daddr, __be16 sport, __be16 dport, u32 *tsoff) { - u32 secret[MD5_MESSAGE_BYTES / 4]; - u32 hash[MD5_DIGEST_WORDS]; - u32 i; - + const struct { + struct in6_addr saddr; + struct in6_addr daddr; + __be16 sport; + __be16 dport; + } __packed combined = { + .saddr = *(struct in6_addr *)saddr, + .daddr = *(struct in6_addr *)daddr, + .sport = sport, + .dport = dport + }; + u64 hash; net_secret_init(); - memcpy(hash, saddr, 16); - for (i = 0; i < 4; i++) - secret[i] = net_secret[i] + (__force u32)daddr[i]; - secret[4] = net_secret[4] + - (((__force u16)sport << 16) + (__force u16)dport); - for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++) - secret[i] = net_secret[i]; - - md5_transform(hash, secret); - - *tsoff = sysctl_tcp_timestamps == 1 ? hash[1] : 0; - return seq_scale(hash[0]); + hash = siphash24((const u8 *)&combined, sizeof(combined), net_secret); + *tsoff = sysctl_tcp_timestamps == 1 ? (hash >> 32) : 0; + return seq_scale(hash); } EXPORT_SYMBOL(secure_tcpv6_sequence_number); u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr, __be16 dport) { - u32 secret[MD5_MESSAGE_BYTES / 4]; - u32 hash[MD5_DIGEST_WORDS]; - u32 i; - + const struct { + struct in6_addr saddr; + struct in6_addr daddr; + __be16 dport; + } __packed combined = { + .saddr = *(struct in6_addr *)saddr, + .daddr = *(struct in6_addr *)daddr, + .dport = dport + }; net_secret_init(); - memcpy(hash, saddr, 16); - for (i = 0; i < 4; i++) - secret[i] = net_secret[i] + (__force u32) daddr[i]; - secret[4] = net_secret[4] + (__force u32)dport; - for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++) - secret[i] = net_secret[i]; - - md5_transform(hash, secret); - - return hash[0]; + return siphash24((const u8 *)&combined, sizeof(combined), net_secret); } EXPORT_SYMBOL(secure_ipv6_port_ephemeral); #endif @@ -91,33 +88,37 @@ EXPORT_SYMBOL(secure_ipv6_port_ephemeral); u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport, u32 *tsoff) { - u32 hash[MD5_DIGEST_WORDS]; - + const struct { + __be32 saddr; + __be32 daddr; + __be16 sport; + __be16 dport; + } __packed combined = { + .saddr = saddr, + .daddr = daddr, + .sport = sport, + .dport = dport + }; + u64 hash; net_secret_init(); - hash[0] = (__force u32)saddr; - hash[1] = (__force u32)daddr; - hash[2] = ((__force u16)sport << 16) + (__force u16)dport; - hash[3] = net_secret[15]; - - md5_transform(hash, net_secret); - - *tsoff = sysctl_tcp_timestamps == 1 ? hash[1] : 0; - return seq_scale(hash[0]); + hash = siphash24((const u8 *)&combined, sizeof(combined), net_secret); + *tsoff = sysctl_tcp_timestamps == 1 ? (hash >> 32) : 0; + return seq_scale(hash); } u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport) { - u32 hash[MD5_DIGEST_WORDS]; - + const struct { + __be32 saddr; + __be32 daddr; + __be16 dport; + } __packed com
[PATCH v2 1/4] siphash: add cryptographically secure hashtable function
SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't anything that comes remotely close to being useful in the way SipHash is. With that said, why do we need this? There are a variety of attacks known as "hashtable poisoning" in which an attacker forms some data such that the hash of that data will be the same, and then preceeds to fill up all entries of a hashbucket. This is a realistic and well-known denial-of-service vector. Linux developers already seem to be aware that this is an issue, and various places that use hash tables in, say, a network context, use a non-cryptographically secure function (usually jhash) and then try to twiddle with the key on a time basis (or in many cases just do nothing and hope that nobody notices). While this is an admirable attempt at solving the problem, it doesn't actually fix it. SipHash fixes it. (It fixes it in such a sound way that you could even build a stream cipher out of SipHash that would resist the modern cryptanalysis.) There are a modicum of places in the kernel that are vulnerable to hashtable poisoning attacks, either via userspace vectors or network vectors, and there's not a reliable mechanism inside the kernel at the moment to fix it. The first step toward fixing these issues is actually getting a secure primitive into the kernel for developers to use. Then we can, bit by bit, port things over to it as deemed appropriate. Dozens of languages are already using this internally for their hash tables. Some of the BSDs already use this in their kernels. SipHash is a widely known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld Cc: Jean-Philippe Aumasson Cc: Daniel J. Bernstein Cc: Linus Torvalds Cc: Eric Biggers --- Changes from v1->v2: - None in this patch, but see elsewhere in series. include/linux/siphash.h | 20 + lib/Kconfig.debug | 6 ++-- lib/Makefile| 5 ++-- lib/siphash.c | 76 + lib/test_siphash.c | 74 +++ 5 files changed, 176 insertions(+), 5 deletions(-) create mode 100644 include/linux/siphash.h create mode 100644 lib/siphash.c create mode 100644 lib/test_siphash.c diff --git a/include/linux/siphash.h b/include/linux/siphash.h new file mode 100644 index ..6623b3090645 --- /dev/null +++ b/include/linux/siphash.h @@ -0,0 +1,20 @@ +/* Copyright (C) 2016 Jason A. Donenfeld + * + * This file is provided under a dual BSD/GPLv2 license. + * + * SipHash: a fast short-input PRF + * https://131002.net/siphash/ + */ + +#ifndef _LINUX_SIPHASH_H +#define _LINUX_SIPHASH_H + +#include + +enum siphash_lengths { + SIPHASH24_KEY_LEN = 16 +}; + +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]); + +#endif /* _LINUX_SIPHASH_H */ diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index e6327d102184..32bbf689fc46 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1843,9 +1843,9 @@ config TEST_HASH tristate "Perform selftest on hash functions" default n help - Enable this option to test the kernel's integer () - and string () hash functions on boot - (or module load). + Enable this option to test the kernel's integer (), + string (), and siphash () + hash functions on boot (or module load). This is intended to help people writing architecture-specific optimized versions. If unsure, say N. diff --git a/lib/Makefile b/lib/Makefile index 50144a3aeebd..71d398b04a74 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ sha1.o chacha20.o md5.o irq_regs.o argv_split.o \ flex_proportions.o ratelimit.o show_mem.o \ is_single_threaded.o plist.o decompress.o kobject_uevent.o \ -earlycpio.o seq_buf.o nmi_backtrace.o nodemask.o win_minmax.o +earlycpio.o seq_buf.o siphash.o \ +nmi_backtrace.o nodemask.o win_minmax.o lib-$(CONFIG_MMU) += ioremap.o lib-$(CONFIG_SMP) += cpumask.o @@ -44,7 +45,7 @@ obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o obj-y += kstrtox.o obj-$(CONFIG_TEST_BPF) += test_bpf.o obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o -obj-$(CONFIG_TEST_HASH) += test_hash.o +obj-$(CONFIG_TEST_HASH) += test_hash.o test_siphash.o obj-$(CONFIG_TEST_KASAN) += test_kasan.o obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o obj-$(CONFIG_TEST_LKM) += test_module.o diff --git a/lib/siphash.c b/lib/siphash.c new file mode 100644 index ..7b55ad3a7fe9 --- /dev/null +++ b/lib/siphash.c @@ -0,0 +1,76 @@ +/* Copyright (C) 2015-2016 Jason A. Donenfeld + * Copyright (C
[PATCH v2 2/4] siphash: add convenience functions for jhash converts
Many jhash users currently rely on the Nwords functions. In order to make transitions to siphash fit something people already know about, we provide analog functions here. This also winds up being nice for the networking stack, where hashing 32-bit fields is common. Signed-off-by: Jason A. Donenfeld --- Changes from v1->v2: - None in this patch, but see elsewhere in series. include/linux/siphash.h | 33 + 1 file changed, 33 insertions(+) diff --git a/include/linux/siphash.h b/include/linux/siphash.h index 6623b3090645..1391054c4c29 100644 --- a/include/linux/siphash.h +++ b/include/linux/siphash.h @@ -17,4 +17,37 @@ enum siphash_lengths { u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]); +static inline u64 siphash24_1word(const u32 a, const u8 key[SIPHASH24_KEY_LEN]) +{ + return siphash24((u8 *)&a, sizeof(a), key); +} + +static inline u64 siphash24_2words(const u32 a, const u32 b, const u8 key[SIPHASH24_KEY_LEN]) +{ + const struct { + u32 a; + u32 b; + } __packed combined = { + .a = a, + .b = b + }; + + return siphash24((const u8 *)&combined, sizeof(combined), key); +} + +static inline u64 siphash24_3words(const u32 a, const u32 b, const u32 c, const u8 key[SIPHASH24_KEY_LEN]) +{ + const struct { + u32 a; + u32 b; + u32 c; + } __packed combined = { + .a = a, + .b = b, + .c = c + }; + + return siphash24((const u8 *)&combined, sizeof(combined), key); +} + #endif /* _LINUX_SIPHASH_H */ -- 2.11.0
[PATCH] media: platform: exynos4-is: constify v4l2_subdev_ops strcutures
Check for v4l2_subdev_ops structures that are only passed as an argument to the function v4l2_subdev_init. This argument is of type const, so v4l2_subdev_ops structures having this property can also be declared const. Done using Coccinelle: @r1 disable optional_qualifier @ identifier i; position p; @@ static struct v4l2_subdev_ops i@p = {...}; @ok1@ identifier r1.i; position p; @@ v4l2_subdev_init(...,&i@p) @bad@ position p!={r1.p,ok1.p}; identifier r1.i; @@ i@p @depends on !bad disable optional_qualifier@ identifier r1.i; @@ +const struct v4l2_subdev_ops i; Before and after size details: textdata bss dec hex filename 6743 152 2069151b03 platform/exynos4-is/fimc-isp.o 6807 88 2069151b03 platform/exynos4-is/fimc-isp.o 15653 392 36 160813ed1 platform/exynos4-is/fimc-lite.o 15717 308 36 160613ebd platform/exynos4-is/fimc-lite.o Signed-off-by: Bhumika Goyal --- drivers/media/platform/exynos4-is/fimc-isp.c | 2 +- drivers/media/platform/exynos4-is/fimc-lite.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c index 8efe916..fd793d3 100644 --- a/drivers/media/platform/exynos4-is/fimc-isp.c +++ b/drivers/media/platform/exynos4-is/fimc-isp.c @@ -433,7 +433,7 @@ static void fimc_isp_subdev_unregistered(struct v4l2_subdev *sd) .s_power = fimc_isp_subdev_s_power, }; -static struct v4l2_subdev_ops fimc_is_subdev_ops = { +static const struct v4l2_subdev_ops fimc_is_subdev_ops = { .core = &fimc_is_core_ops, .video = &fimc_is_subdev_video_ops, .pad = &fimc_is_subdev_pad_ops, diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c index b91abf1..18b6aaa 100644 --- a/drivers/media/platform/exynos4-is/fimc-lite.c +++ b/drivers/media/platform/exynos4-is/fimc-lite.c @@ -1361,7 +1361,7 @@ static void fimc_lite_subdev_unregistered(struct v4l2_subdev *sd) .log_status = fimc_lite_log_status, }; -static struct v4l2_subdev_ops fimc_lite_subdev_ops = { +static const struct v4l2_subdev_ops fimc_lite_subdev_ops = { .core = &fimc_lite_core_ops, .video = &fimc_lite_subdev_video_ops, .pad = &fimc_lite_subdev_pad_ops, -- 1.9.1
linux-next: manual merge of the akpm-current tree with the jc_docs tree
Hi Andrew, Today's linux-next merge of the akpm-current tree got a conflict in: lib/Kconfig.debug between commit: 63d0977c0e85 ("lib/Kconfig.debug: correct documentation paths") from the jc_docs tree and commit: 2c81218d9f29 ("Kconfig: lib/Kconfig.debug: fix references to Documenation") from the akpm-current tree. I fixed it up (I just used the version from the jc_docs tree) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
Re: [PATCH 04/12] mfd: flexcard: add interrupt support
Hi Holger, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9] [cannot apply to ljones-mfd/for-mfd-next next-20161213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Holger-Dengler/Eberspaecher-Flexcard-PMC-II-base-support/20161214-082350 config: tile-allyesconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/mfd/flexcard_irq.c: In function 'flexcard_demux': drivers/mfd/flexcard_irq.c:111:3: error: implicit declaration of function 'generic_handle_irq' drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_ack': drivers/mfd/flexcard_irq.c:119:9: error: implicit declaration of function 'irq_data_get_irq_chip_data' drivers/mfd/flexcard_irq.c:119:33: warning: initialization makes pointer from integer without a cast [enabled by default] >> drivers/mfd/flexcard_irq.c:120:51: error: dereferencing pointer to >> incomplete type drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_mask': drivers/mfd/flexcard_irq.c:128:33: warning: initialization makes pointer from integer without a cast [enabled by default] drivers/mfd/flexcard_irq.c:129:51: error: dereferencing pointer to incomplete type drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_unmask': drivers/mfd/flexcard_irq.c:141:33: warning: initialization makes pointer from integer without a cast [enabled by default] drivers/mfd/flexcard_irq.c:142:51: error: dereferencing pointer to incomplete type drivers/mfd/flexcard_irq.c: At top level: drivers/mfd/flexcard_irq.c:175:15: error: variable 'flexcard_irq_chip' has initializer but incomplete type drivers/mfd/flexcard_irq.c:176:2: error: unknown field 'name' specified in initializer drivers/mfd/flexcard_irq.c:176:2: warning: excess elements in struct initializer [enabled by default] drivers/mfd/flexcard_irq.c:176:2: warning: (near initialization for 'flexcard_irq_chip') [enabled by default] drivers/mfd/flexcard_irq.c:177:2: error: unknown field 'irq_ack' specified in initializer drivers/mfd/flexcard_irq.c:177:2: warning: excess elements in struct initializer [enabled by default] drivers/mfd/flexcard_irq.c:177:2: warning: (near initialization for 'flexcard_irq_chip') [enabled by default] drivers/mfd/flexcard_irq.c:178:2: error: unknown field 'irq_mask' specified in initializer drivers/mfd/flexcard_irq.c:178:2: warning: excess elements in struct initializer [enabled by default] drivers/mfd/flexcard_irq.c:178:2: warning: (near initialization for 'flexcard_irq_chip') [enabled by default] drivers/mfd/flexcard_irq.c:179:2: error: unknown field 'irq_unmask' specified in initializer drivers/mfd/flexcard_irq.c:179:2: warning: excess elements in struct initializer [enabled by default] drivers/mfd/flexcard_irq.c:179:2: warning: (near initialization for 'flexcard_irq_chip') [enabled by default] drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_domain_map': drivers/mfd/flexcard_irq.c:187:2: error: implicit declaration of function 'irq_set_chip_and_handler_name' drivers/mfd/flexcard_irq.c:188:11: error: 'handle_level_irq' undeclared (first use in this function) drivers/mfd/flexcard_irq.c:188:11: note: each undeclared identifier is reported only once for each function it appears in drivers/mfd/flexcard_irq.c:189:2: error: implicit declaration of function 'irq_set_chip_data' drivers/mfd/flexcard_irq.c:190:2: error: implicit declaration of function 'irq_modify_status' drivers/mfd/flexcard_irq.c:190:25: error: 'IRQ_NOREQUEST' undeclared (first use in this function) drivers/mfd/flexcard_irq.c:190:41: error: 'IRQ_NOAUTOEN' undeclared (first use in this function) drivers/mfd/flexcard_irq.c:190:55: error: 'IRQ_NOPROBE' undeclared (first use in this function) cc1: some warnings being treated as errors vim +120 drivers/mfd/flexcard_irq.c 105 106 stat = readl(&priv->bar0->conf.irs) & VALID_DEVIRQ_MSK; 107 while (stat) { 108 slot = __ffs(stat); 109 stat &= (1 << slot); 110 cur = irq_linear_revmap(priv->irq_domain, slot); > 111 generic_handle_irq(cur); 112 ret = IRQ_HANDLED; 113 } 114 return ret; 115 } 116 117 static v
[PATCH v2 1/3] power: supply: bq24735-charger: simplify register update to stop charging
Providing value bits outside of the mask is pointless. Signed-off-by: Peter Rosin --- drivers/power/supply/bq24735-charger.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c index eb7783b42e0a..1d5c9206e0ed 100644 --- a/drivers/power/supply/bq24735-charger.c +++ b/drivers/power/supply/bq24735-charger.c @@ -111,8 +111,7 @@ static inline int bq24735_enable_charging(struct bq24735 *charger) return 0; return bq24735_update_word(charger->client, BQ24735_CHG_OPT, - BQ24735_CHG_OPT_CHARGE_DISABLE, - ~BQ24735_CHG_OPT_CHARGE_DISABLE); + BQ24735_CHG_OPT_CHARGE_DISABLE, 0); } static inline int bq24735_disable_charging(struct bq24735 *charger) -- 2.1.4
Re: [PATCH 10/12] misc: Flexcard basic timestamp counter support
Hi Holger, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9] [cannot apply to ljones-mfd/for-mfd-next next-20161213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Holger-Dengler/Eberspaecher-Flexcard-PMC-II-base-support/20161214-082350 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All error/warnings (new ones prefixed by >>): drivers/misc/flexcard_posixclock.c: In function 'flexcard_clk_gettime': >> drivers/misc/flexcard_posixclock.c:55:10: error: implicit declaration of >> function 'readl' [-Werror=implicit-function-declaration] upper = readl(clk->ts64); ^ drivers/misc/flexcard_posixclock.c: In function 'flexcard_clk_settime': >> drivers/misc/flexcard_posixclock.c:75:2: error: implicit declaration of >> function 'writel' [-Werror=implicit-function-declaration] writel(FLEXCARD_RST_TS, clk->reset); ^~ drivers/misc/flexcard_posixclock.c: In function 'flexcard_clk_iomap': >> drivers/misc/flexcard_posixclock.c:96:14: error: implicit declaration of >> function 'devm_ioremap' [-Werror=implicit-function-declaration] clk->ts64 = devm_ioremap(&pdev->dev, res->start, resource_size(res)); ^~~~ >> drivers/misc/flexcard_posixclock.c:96:12: warning: assignment makes pointer >> from integer without a cast [-Wint-conversion] clk->ts64 = devm_ioremap(&pdev->dev, res->start, resource_size(res)); ^ drivers/misc/flexcard_posixclock.c:104:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion] clk->reset = devm_ioremap(&pdev->dev, res->start, resource_size(res)); ^ cc1: some warnings being treated as errors vim +/readl +55 drivers/misc/flexcard_posixclock.c 49 { 50 struct flexcard_clk *clk = container_of(pc, struct flexcard_clk, clock); 51 u64 now; 52 u32 upper, rem; 53 54 retry: > 55 upper = readl(clk->ts64); 56 now = ((u64) upper << 32) | readl(clk->ts64 + 4); 57 if (upper != readl(clk->ts64)) 58 goto retry; 59 60 tp->tv_sec = div_u64_rem(now, 100, &rem); 61 tp->tv_nsec = rem * 1000; 62 63 return 0; 64 } 65 66 static int flexcard_clk_settime(struct posix_clock *pc, 67const struct timespec *tp) 68 { 69 struct flexcard_clk *clk = container_of(pc, struct flexcard_clk, clock); 70 71 /* The FlexCard posix clock could only be reset to 0 and not set */ 72 if (tp->tv_sec || tp->tv_nsec) 73 return -EINVAL; 74 > 75 writel(FLEXCARD_RST_TS, clk->reset); 76 77 return 0; 78 } 79 80 static struct posix_clock_operations flexcard_clk_ops = { 81 .owner = THIS_MODULE, 82 .clock_getres = flexcard_clk_getres, 83 .clock_gettime = flexcard_clk_gettime, 84 .clock_settime = flexcard_clk_settime, 85 }; 86 87 static int flexcard_clk_iomap(struct platform_device *pdev) 88 { 89 struct flexcard_clk *clk = platform_get_drvdata(pdev); 90 struct resource *res; 91 92 res = platform_get_resource(pdev, IORESOURCE_MEM, 0); 93 if (!res) 94 return -ENXIO; 95 > 96 clk->ts64 = devm_ioremap(&pdev->dev, res->start, resource_size(res)); 97 if (!clk->ts64) 98 return -ENOMEM; 99 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 1/2] x86/boot/64: use 'push' instead of 'call' in start_cpu()
start_cpu() pushes a text address on the stack so that stack traces from idle tasks will show start_cpu() at the end. But it uses a call instruction to do that, which is rather obtuse. Use a straightforward push instead. Suggested-by: Borislav Petkov Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/head_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 90de288..1facaf4 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -298,7 +298,7 @@ ENTRY(start_cpu) * REX.W + FF /5 JMP m16:64 Jump far, absolute indirect, * address given in m16:64. */ - call1f # put return address on stack for unwinder + pushq $1f # put return address on stack for unwinder 1: xorq%rbp, %rbp # clear frame pointer movqinitial_code(%rip), %rax pushq $__KERNEL_CS# set correct cs -- 2.7.4
[PATCH 2/2] x86/boot/64: push correct start_cpu() return address
start_cpu() pushes a text address on the stack so that stack traces from idle tasks will show start_cpu() at the end. But it currently shows the wrong function offset. It's more correct to show the address immediately after the 'lretq' instruction. Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/head_64.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 1facaf4..b467b14 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -298,12 +298,13 @@ ENTRY(start_cpu) * REX.W + FF /5 JMP m16:64 Jump far, absolute indirect, * address given in m16:64. */ - pushq $1f # put return address on stack for unwinder -1: xorq%rbp, %rbp # clear frame pointer + pushq $.Lafter_lret # put return address on stack for unwinder + xorq%rbp, %rbp # clear frame pointer movqinitial_code(%rip), %rax pushq $__KERNEL_CS# set correct cs pushq %rax# target address in negative space lretq +.Lafter_lret: ENDPROC(start_cpu) #include "verify_cpu.S" -- 2.7.4
[PATCH 0/2] x86/boot/64: a couple of start_cpu() cleanups
Josh Poimboeuf (2): x86/boot/64: use 'push' instead of 'call' in start_cpu() x86/boot/64: push correct start_cpu() return address arch/x86/kernel/head_64.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.7.4
Re: [PATCH] Add +~800M crashkernel explaination
On 12/14/2016 at 11:08 AM, Xunlei Pang wrote: > On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote: >> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: >>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote: When trying to configure crashkernel greater than about 800 MB, the kernel fails to allocate memory on x86 and x86_64. This is due to an undocumented limit that the crashkernel and other low memory items must be allocated below 896 MB unless the ",high" option is given. This updates the documentation to explain this and what I understand the limitations to be on the option. >>> This is true, but not very accurate. You found it's about 800M, it's >>> becasue usually the current kernel need about 40M space to run, and some >>> extra reservation before reserve_crashkernel invocation, another ~10M. >>> However it's normal case, people may build modules into or have some >>> special code to bloat kernel. This patch makes sense to address the >>> low|high issue, it might be not good so determined to say ~800M. >> My testing showed that I could go anywhere from about 830M to 880M, >> depending on distro, kernel version, and stuff that you mentioned. I >> just thought some rule of thumb of when to consider using high would >> be good. People may not think that 800 MB is 'large' when you have 512 >> GB of RAM for instance. I thought about making 512 MB be the rule of >> thumb, but you can do a lot with ~300 MB. > Hi Robert, > > I think you are correct. > > For x86, the kernel uses memblock to locate the proper range starts from 16MB > to some "end", > without "high" prefix, "end" is CRASH_ADDR_LOW_MAX, otherwise > CRASH_ADDR_HIGH_MAX. > > You can find the definition for both 32-bit and 64-bit: > #ifdef CONFIG_X86_32 > # define CRASH_ADDR_LOW_MAX (512 << 20) > # define CRASH_ADDR_HIGH_MAX(512 << 20) > #else > # define CRASH_ADDR_LOW_MAX (896UL << 20) > # define CRASH_ADDR_HIGH_MAXMAXMEM > #endif > > as some memory was already allocated by the kernel, which means it's highly > likely to get a reservation > failure after specifying a crashkernel value near 800MB(for x86_64) which was > what you met. But we can't > get the exact threshold, but it would be better if there is some explanation > accordingly in the document. But there is another point: If you specify the base using crashkernel=size[KMG][@offset[KMG]], for example "crashkernel=1024M@0x1000", there is no such limitation, and you may get a successful reservation. I have no idea why the design is so different. Regards, Xunlei > >> I'm happy to adjust the wording, what would you recommend? Also, I'm >> not 100% sure that I got the cases covered correctly. I was surprised >> that I could not get it to work with the "new" format with the >> multiple ranges, and that specifying an offset would't work either, >> although the offset kind of makes sense. Do you know for sure that it >> doesn't work with ranges? >> >> I tried, >> >> crashkernel=256M-1G:128M,high,1G-4G:256M,high,4G-:512M,high >> >> and >> >> crashkernel=256M-1G:128M,1G-4G:256M,4G-:512M,high >> >> and neither worked. It seems that a better separator would be ';' >> instead of ',' for ranges, then you could specify options better. Kind >> of hard to change now. > For "crashkernel=range1:size1[,range2:size2,...][@offset]" > I'm afraid it doesn't support "high" prefix in the current implementation, so > there is no guarantee. > I guess we can drop a note to eliminate the confusion. > > Regards, > Xunlei > Signed-off-by: Robert LeBlanc --- Documentation/kdump/kdump.txt | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index b0eb27b..aa3efa8 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" syntax is sufficient for most configurations, sometimes it's handy to have the reserved memory dependent on the value of System RAM -- that's mostly for distributors that pre-setup the kernel command line to avoid a unbootable system after some memory has -been removed from the machine. +been removed from the machine. If you need to allocate more than ~800M +for x86 or x86_64 then you must use the simple format as the format +',high' conflicts with the separators of ranges. The syntax is: @@ -282,11 +284,21 @@ Boot into System Kernel 1) Update the boot loader (such as grub, yaboot, or lilo) configuration files as necessary. -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", +2) Boot the system kernel with the boot parameter "crashkernel=Y[@X | ,high]", where Y specifies how much memory to reserve for the dump-capture kernel - and X specifies the beginning of this reserved memory. For example,
[PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon TFT's as an active switching devices. It can be supported by the simple-panel driver. Read the panel default edid information: EDID MODE DETAILS name = pixel_clock = 71900 lvds_dual_channel = 0 refresh = 0 ha = 1280 hbl = 160 hso = 48 hspw = 32 hborder = 0 va = 800 vbl = 32 vso = 3 vspw = 5 vborder = 0 phsync = + pvsync = - x_mm = 0 y_mm = 0 drm_display_mode .hdisplay = 1280 .hsync_start = 1328 .hsync_end = 1360 .htotal = 1440 .vdisplay = 800 .vsync_start = 803 .vsync_end = 808 .vtotal = 832 There are two modes in the edid: Detailed mode1: Clock 71.900 MHz, 216 mm x 135 mm 1280 1328 1360 1440 hborder 0 800 803 808 832 vborder 0 +hsync -vsync Detailed mode2: Clock 57.500 MHz, 216 mm x 135 mm 1280 1328 1360 1440 hborder 0 800 803 808 832 vborder 0 +hsync -vsync Add the both edid to support more modes for BOE nv101wxmn51. Signed-off-by: Caesar Wang --- Changes in v3: - As Stéphane commented on https://patchwork.kernel.org/patch/9465911, add downclock mode for edid. Changes in v2: - fix the vsync_start and vsync_end from the edid. - change the commit. drivers/gpu/drm/panel/panel-simple.c | 45 1 file changed, 45 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..1ce25b5 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,48 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_modes[] = { + { + .clock = 71900, + .hdisplay = 1280, + .hsync_start = 1280 + 48, + .hsync_end = 1280 + 48 + 32, + .htotal = 1280 + 48 + 32 + 80, + .vdisplay = 800, + .vsync_start = 800 + 3, + .vsync_end = 800 + 3 + 5, + .vtotal = 800 + 3 + 5 + 24, + .vrefresh = 60, + }, + { + .clock = 57500, + .hdisplay = 1280, + .hsync_start = 1280 + 48, + .hsync_end = 1280 + 48 + 32, + .htotal = 1280 + 48 + 32 + 80, + .vdisplay = 800, + .vsync_start = 800 + 3, + .vsync_end = 800 + 3 + 5, + .vtotal = 800 + 3 + 5 + 24, + .vrefresh = 48, + }, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = boe_nv101wxmn51_modes, + .num_modes = ARRAY_SIZE(boe_nv101wxmn51_modes), + .bpc = 8, + .size = { + .width = 217, + .height = 136, + }, + .delay = { + .prepare = 210, + .enable = 50, + .unprepare = 160, + }, +}; + static const struct drm_display_mode chunghwa_claa070wp03xg_mode = { .clock = 66770, .hdisplay = 800, @@ -1748,6 +1790,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4
[PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. Signed-off-by: Caesar Wang --- Changes in v3: None Changes in v2: None .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000..b258d6a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4
Re: [PATCH V4] i2c: designware: fix wrong Tx/Rx FIFO for ACPI
On Tue, Dec 13, 2016 at 6:25 PM, Andy Shevchenko wrote: > On Tue, 2016-12-13 at 17:03 +0700, Tin Huynh wrote: >> ACPI always sets Tx/Rx FIFO to 32. This configuration will >> cause problem if the IP core supports a FIFO size of less than 32. >> The driver should read the FIFO size from the IP and select the >> smaller >> one of the two. >> >> Signed-off-by: Tin Huynh >> > > One comment below, after addressing it > > Reviewed-by: Andy Shevchenko > >> --- >> drivers/i2c/busses/i2c-designware-platdrv.c | 27 >> --- >> 1 files changed, 20 insertions(+), 7 deletions(-) >> >> Change from V3: >> -Use uppercase of FIFO instead of lowercase. >> -Fix the problem when IP core return 0 of FIFO. >> >> Change from V2: >> -Add a helper function to set FIFO size. >> >> Change from V1: >> -Revert the default 32 for FIFO, read parameter from IP core >> and pick the smaller one of the two. >> -Correct the title to describe new approach. >> >> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c >> b/drivers/i2c/busses/i2c-designware-platdrv.c >> index 0b42a12..24032d6 100644 >> --- a/drivers/i2c/busses/i2c-designware-platdrv.c >> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c >> @@ -150,6 +150,25 @@ static int i2c_dw_plat_prepare_clk(struct >> dw_i2c_dev *i_dev, bool prepare) >> return 0; >> } >> >> +static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev, int id) >> +{ >> + u32 param, tx_fifo_depth, rx_fifo_depth; >> + >> > > /* > * Try to detect the FIFO depth if not > set by interface driver, > * the depth could be from 2 to 256 from > HW spec. > */ > I will add your comment to the driver. >> + param = i2c_dw_read_comp_param(dev); >> + tx_fifo_depth = ((param >> 16) & 0xff) + 1; >> + rx_fifo_depth = ((param >> 8) & 0xff) + 1; >> + if (!dev->tx_fifo_depth) { >> + dev->tx_fifo_depth = tx_fifo_depth; >> + dev->rx_fifo_depth = rx_fifo_depth; >> + dev->adapter.nr = id; >> + } else if (tx_fifo_depth > 1) { > > This makes sense now, though I would add a comment here and use >= 2 to > reflect datasheet. > > /* > * Choose minimum values between HW and interface > * driver provided. > */ > I will implement as your comment. However , because adding 1 to the value , can i use > 2 or >=3 ? >> + dev->tx_fifo_depth = min_t(u32, dev->tx_fifo_depth, >> + tx_fifo_depth); >> + dev->rx_fifo_depth = min_t(u32, dev->rx_fifo_depth, >> + rx_fifo_depth); >> + } >> +} >> + >> static int dw_i2c_plat_probe(struct platform_device *pdev) >> { >> struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev- >> >dev); >> @@ -246,13 +265,7 @@ static int dw_i2c_plat_probe(struct >> platform_device *pdev) >> 100); >> } >> >> - if (!dev->tx_fifo_depth) { >> - u32 param1 = i2c_dw_read_comp_param(dev); >> - >> - dev->tx_fifo_depth = ((param1 >> 16) & 0xff) + 1; >> - dev->rx_fifo_depth = ((param1 >> 8) & 0xff) + 1; >> - dev->adapter.nr = pdev->id; >> - } >> + dw_i2c_set_fifo_size(dev, pdev->id); >> >> adap = &dev->adapter; >> adap->owner = THIS_MODULE; > > -- > Andy Shevchenko > Intel Finland Oy Thank you and regards, Tin
[PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long
This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase diffusion. The previous md5 algorithm used a per-cpu md5 state, which caused successive calls to the function to chain upon each other. While it's not entirely clear that this kind of chaining is absolutely necessary when using a secure PRF like siphash24, it can't hurt, and the timing of the call chain does add a degree of natural entropy. So, in keeping with this design, instead of the massive per-cpu 64-byte md5 state, there is instead a per-cpu previously returned value for chaining. Signed-off-by: Jason A. Donenfeld Cc: Jean-Philippe Aumasson --- drivers/char/random.c | 50 +++--- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d6876d506220..25f96f074da5 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -262,6 +262,7 @@ #include #include #include +#include #include #include @@ -2042,7 +2043,7 @@ struct ctl_table random_table[] = { }; #endif /* CONFIG_SYSCTL */ -static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] cacheline_aligned; +static u8 random_int_secret[SIPHASH24_KEY_LEN]; int random_int_secret_init(void) { @@ -2050,8 +2051,7 @@ int random_int_secret_init(void) return 0; } -static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) - __aligned(sizeof(unsigned long)); +static DEFINE_PER_CPU(u64, get_random_int_chaining); /* * Get a random word for internal kernel use only. Similar to urandom but @@ -2061,19 +2061,25 @@ static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash) */ unsigned int get_random_int(void) { - __u32 *hash; + uint64_t *chaining; unsigned int ret; + struct { + uint64_t chaining; + unsigned long ts; + unsigned long entropy; + pid_t pid; + } __packed combined; if (arch_get_random_int(&ret)) return ret; - hash = get_cpu_var(get_random_int_hash); - - hash[0] += current->pid + jiffies + random_get_entropy(); - md5_transform(hash, random_int_secret); - ret = hash[0]; - put_cpu_var(get_random_int_hash); - + chaining = &get_cpu_var(get_random_int_chaining); + combined.chaining = *chaining; + combined.ts = jiffies; + combined.entropy = random_get_entropy(); + combined.pid = current->pid; + ret = *chaining = siphash24((u8 *)&combined, sizeof(combined), random_int_secret); + put_cpu_var(chaining); return ret; } EXPORT_SYMBOL(get_random_int); @@ -2083,19 +2089,25 @@ EXPORT_SYMBOL(get_random_int); */ unsigned long get_random_long(void) { - __u32 *hash; + uint64_t *chaining; unsigned long ret; + struct { + uint64_t chaining; + unsigned long ts; + unsigned long entropy; + pid_t pid; + } __packed combined; if (arch_get_random_long(&ret)) return ret; - hash = get_cpu_var(get_random_int_hash); - - hash[0] += current->pid + jiffies + random_get_entropy(); - md5_transform(hash, random_int_secret); - ret = *(unsigned long *)hash; - put_cpu_var(get_random_int_hash); - + chaining = &get_cpu_var(get_random_int_chaining); + combined.chaining = *chaining; + combined.ts = jiffies; + combined.entropy = random_get_entropy(); + combined.pid = current->pid; + ret = *chaining = siphash24((u8 *)&combined, sizeof(combined), random_int_secret); + put_cpu_var(chaining); return ret; } EXPORT_SYMBOL(get_random_long); -- 2.11.0
Re: [LKP] [ext4] e2ae766c1b: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c
Jan Kara writes: > On Tue 13-12-16 09:27:51, Huang, Ying wrote: >> Jan Kara writes: >> >> > On Mon 12-12-16 18:13:21, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> >> >> commit: e2ae766c1b030271b5099b25674e2131d1d1e8c1 ("ext4: convert DAX >> >> faults to iomap infrastructure") >> >> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev >> >> >> >> in testcase: nvml >> >> with following parameters: >> >> >> >> group: vmem >> >> test: pmem >> >> nr_pmem: 1 >> >> fs: ext4 >> >> mount_option: dax >> >> >> >> >> >> >> >> on test machine: 64 threads Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz with >> >> 64G memory >> >> >> >> caused below changes: >> >> >> >> >> >> ++++ >> >> || 96f8ba3dd6 | >> >> e2ae766c1b | >> >> ++++ >> >> | boot_successes | 2 | 2 >> >> | >> >> | boot_failures | 2 | 2 >> >> | >> >> | BUG:kernel_hang_in_test_stage | 2 | >> >> | >> >> | WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup | 0 | 2 >> >> | >> >> | calltrace:parport_pc_init | 0 | 2 >> >> | >> >> | calltrace:SyS_finit_module | 0 | 2 >> >> | >> >> | WARNING:at_lib/kobject.c:#kobject_add_internal | 0 | 2 >> >> | >> >> ++++ >> >> >> >> >> >> >> >> user :notice: [ 325.592182] vmem_aligned_alloc/TEST1: SETUP >> >> (check/pmem/debug) >> >> >> >> user :notice: [ 325.603973] vmem_aligned_alloc/TEST1: START: >> >> vmem_aligned_alloc >> >> kern :err : [ 325.608906] BUG: sleeping function called from invalid >> >> context at kernel/locking/rwsem.c:51 >> >> kern :err : [ 325.608908] in_atomic(): 1, irqs_disabled(): 0, pid: >> >> 24813, name: vmem_aligned_al >> >> kern :warn : [ 325.608914] CPU: 44 PID: 24813 Comm: vmem_aligned_al >> >> Tainted: G O4.9.0-rc4-00045-ge2ae766 #1 >> >> kern :warn : [ 325.608916] Hardware name: Intel Corporation LH >> >> Pass/S4600LH, BIOS SE5C600.86B.99.02.1047.032320122259 03/23/2012 >> >> kern :warn : [ 325.608922] c9002c1f7be0 >> >> kern :warn : [ 325.608923] 81466af9 >> >> kern :warn : [ 325.608924] 880fea2425c0 >> > >> > I think this is actually a bug introduced by Ross' PMD support. Attached >> > patch should fix it. Ross, can you check it please? >> >> Hi, Jan >> >> Could you provide a git tree commit for me to test it? If you want it >> to be tested by 0day. > > Thanks for the offer! I've pushed out the latest version of my DAX patches > including the above fix to > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git dax The test result of the head and its parent is as follow, = compiler/fs/group/kconfig/mount_option/nr_pmem/rootfs/tbox_group/test/testcase: gcc-6/ext4/vmem/x86_64-rhel-7.2/dax/1/debian-x86_64-2016-08-31.cgz/lkp-sbx04/pmem/nvml commit: c6207e9b753f466bc2e41455dc7611869d439d4e 4393b9bdd5043e550f1bcaf7f4e9c413d0088425 c6207e9b753f466b 4393b9bdd5043e550f1bcaf7f4 -- fail:runs %reproductionfail:runs | | | 3:3 -100%:3 dmesg.BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c 3:3 -100%:3 kmsg.in_atomic():#,irqs_disabled():#,pid:#,name:vmem_aligned_al 3:3 -100%:3 kmsg.in_atomic():#,irqs_disabled():#,pid:#,name:vmem_multiple_p The bug has been fixed. Feel free to add, Tested-by: "Huang, Ying" Best Regards, Huang, Ying
Re: [PATCH 05/12] mfd: flexcard: add DMA interrupts
Hi Holger, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9] [cannot apply to ljones-mfd/for-mfd-next next-20161213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Holger-Dengler/Eberspaecher-Flexcard-PMC-II-base-support/20161214-082350 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/mfd/flexcard_irq.c: In function 'flexcard_demux': drivers/mfd/flexcard_irq.c:135:3: error: implicit declaration of function 'generic_handle_irq' [-Werror=implicit-function-declaration] generic_handle_irq(cur); ^~ drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_ack': drivers/mfd/flexcard_irq.c:143:33: error: implicit declaration of function 'irq_data_get_irq_chip_data' [-Werror=implicit-function-declaration] struct flexcard_device *priv = irq_data_get_irq_chip_data(d); ^~ drivers/mfd/flexcard_irq.c:143:33: warning: initialization makes pointer from integer without a cast [-Wint-conversion] drivers/mfd/flexcard_irq.c:144:51: error: dereferencing pointer to incomplete type 'struct irq_data' const struct fc_irq_tab *tp = &flexcard_irq_tab[d->hwirq]; ^~ drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_mask': drivers/mfd/flexcard_irq.c:152:33: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct flexcard_device *priv = irq_data_get_irq_chip_data(d); ^~ drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_unmask': drivers/mfd/flexcard_irq.c:165:33: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct flexcard_device *priv = irq_data_get_irq_chip_data(d); ^~ drivers/mfd/flexcard_irq.c: At top level: drivers/mfd/flexcard_irq.c:199:15: error: variable 'flexcard_irq_chip' has initializer but incomplete type static struct irq_chip flexcard_irq_chip = { ^~~~ drivers/mfd/flexcard_irq.c:200:2: error: unknown field 'name' specified in initializer .name = "flexcard_irq", ^ drivers/mfd/flexcard_irq.c:200:11: warning: excess elements in struct initializer .name = "flexcard_irq", ^~ drivers/mfd/flexcard_irq.c:200:11: note: (near initialization for 'flexcard_irq_chip') drivers/mfd/flexcard_irq.c:201:2: error: unknown field 'irq_ack' specified in initializer .irq_ack = flexcard_irq_ack, ^ drivers/mfd/flexcard_irq.c:201:13: warning: excess elements in struct initializer .irq_ack = flexcard_irq_ack, ^~~~ drivers/mfd/flexcard_irq.c:201:13: note: (near initialization for 'flexcard_irq_chip') drivers/mfd/flexcard_irq.c:202:2: error: unknown field 'irq_mask' specified in initializer .irq_mask = flexcard_irq_mask, ^ drivers/mfd/flexcard_irq.c:202:14: warning: excess elements in struct initializer .irq_mask = flexcard_irq_mask, ^ drivers/mfd/flexcard_irq.c:202:14: note: (near initialization for 'flexcard_irq_chip') drivers/mfd/flexcard_irq.c:203:2: error: unknown field 'irq_unmask' specified in initializer .irq_unmask = flexcard_irq_unmask, ^ drivers/mfd/flexcard_irq.c:203:16: warning: excess elements in struct initializer .irq_unmask = flexcard_irq_unmask, ^~~ drivers/mfd/flexcard_irq.c:203:16: note: (near initialization for 'flexcard_irq_chip') drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_domain_map': drivers/mfd/flexcard_irq.c:211:2: error: implicit declaration of function 'irq_set_chip_and_handler_name' [-Werror=implicit-function-declaration] irq_set_chip_and_handler_name(irq, &flexcard_irq_chip, ^ drivers/mfd/flexcard_irq.c:212:11: error: 'handle_level_irq' undeclared (first use in this function) handle_level_irq, "flexcard"); ^~~~ drivers/mfd/flexcard_irq.c:212:11: note: each undeclared identifier is reported only once for each function it appears in drivers/
[PATCH] block_dev: don't update file access position for sync direct IO
For sync direct IO, generic_file_direct_write/generic_file_read_iter will update file access position. Don't duplicate the update in .direct_IO. This cause my raid array can't assemble. Cc: Christoph Hellwig Cc: Jens Axboe Signed-off-by: Shaohua Li --- fs/block_dev.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index 95acbd2..1eb7dcf 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -264,7 +264,6 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter, if (unlikely(bio.bi_error)) return bio.bi_error; - iocb->ki_pos += ret; return ret; } @@ -411,10 +410,8 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages) __set_current_state(TASK_RUNNING); ret = dio->bio.bi_error; - if (likely(!ret)) { + if (likely(!ret)) ret = dio->size; - iocb->ki_pos += ret; - } bio_put(&dio->bio); return ret; -- 2.9.3
Re: [PATCH] Add +~800M crashkernel explaination
On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote: > On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: >> On 12/09/16 at 05:22pm, Robert LeBlanc wrote: >>> When trying to configure crashkernel greater than about 800 MB, the >>> kernel fails to allocate memory on x86 and x86_64. This is due to an >>> undocumented limit that the crashkernel and other low memory items must >>> be allocated below 896 MB unless the ",high" option is given. This >>> updates the documentation to explain this and what I understand the >>> limitations to be on the option. >> This is true, but not very accurate. You found it's about 800M, it's >> becasue usually the current kernel need about 40M space to run, and some >> extra reservation before reserve_crashkernel invocation, another ~10M. >> However it's normal case, people may build modules into or have some >> special code to bloat kernel. This patch makes sense to address the >> low|high issue, it might be not good so determined to say ~800M. > My testing showed that I could go anywhere from about 830M to 880M, > depending on distro, kernel version, and stuff that you mentioned. I > just thought some rule of thumb of when to consider using high would > be good. People may not think that 800 MB is 'large' when you have 512 > GB of RAM for instance. I thought about making 512 MB be the rule of > thumb, but you can do a lot with ~300 MB. Hi Robert, I think you are correct. For x86, the kernel uses memblock to locate the proper range starts from 16MB to some "end", without "high" prefix, "end" is CRASH_ADDR_LOW_MAX, otherwise CRASH_ADDR_HIGH_MAX. You can find the definition for both 32-bit and 64-bit: #ifdef CONFIG_X86_32 # define CRASH_ADDR_LOW_MAX (512 << 20) # define CRASH_ADDR_HIGH_MAX(512 << 20) #else # define CRASH_ADDR_LOW_MAX (896UL << 20) # define CRASH_ADDR_HIGH_MAXMAXMEM #endif as some memory was already allocated by the kernel, which means it's highly likely to get a reservation failure after specifying a crashkernel value near 800MB(for x86_64) which was what you met. But we can't get the exact threshold, but it would be better if there is some explanation accordingly in the document. > > I'm happy to adjust the wording, what would you recommend? Also, I'm > not 100% sure that I got the cases covered correctly. I was surprised > that I could not get it to work with the "new" format with the > multiple ranges, and that specifying an offset would't work either, > although the offset kind of makes sense. Do you know for sure that it > doesn't work with ranges? > > I tried, > > crashkernel=256M-1G:128M,high,1G-4G:256M,high,4G-:512M,high > > and > > crashkernel=256M-1G:128M,1G-4G:256M,4G-:512M,high > > and neither worked. It seems that a better separator would be ';' > instead of ',' for ranges, then you could specify options better. Kind > of hard to change now. For "crashkernel=range1:size1[,range2:size2,...][@offset]" I'm afraid it doesn't support "high" prefix in the current implementation, so there is no guarantee. I guess we can drop a note to eliminate the confusion. Regards, Xunlei >>> Signed-off-by: Robert LeBlanc >>> --- >>> Documentation/kdump/kdump.txt | 22 +- >>> 1 file changed, 17 insertions(+), 5 deletions(-) >>> >>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >>> index b0eb27b..aa3efa8 100644 >>> --- a/Documentation/kdump/kdump.txt >>> +++ b/Documentation/kdump/kdump.txt >>> @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" syntax is >>> sufficient for most >>> configurations, sometimes it's handy to have the reserved memory dependent >>> on the value of System RAM -- that's mostly for distributors that pre-setup >>> the kernel command line to avoid a unbootable system after some memory has >>> -been removed from the machine. >>> +been removed from the machine. If you need to allocate more than ~800M >>> +for x86 or x86_64 then you must use the simple format as the format >>> +',high' conflicts with the separators of ranges. >>> >>> The syntax is: >>> >>> @@ -282,11 +284,21 @@ Boot into System Kernel >>> 1) Update the boot loader (such as grub, yaboot, or lilo) configuration >>> files as necessary. >>> >>> -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", >>> +2) Boot the system kernel with the boot parameter "crashkernel=Y[@X | >>> ,high]", >>> where Y specifies how much memory to reserve for the dump-capture kernel >>> - and X specifies the beginning of this reserved memory. For example, >>> - "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory >>> - starting at physical address 0x0100 (16MB) for the dump-capture >>> kernel. >>> + and X specifies the beginning of this reserved memory or ',high' to >>> load in >>> + high memory. For example, "crashkernel=64M@16M" tells the system >>> + kernel to reserve 64 MB of memory starting at physical address >>> + 0x0100 (16MB) for the dump-capture kernel.
Re: [PATCH] mm-add-vfree_atomic-fix
On Tue, Dec 13, 2016 at 11:21 AM, Andrey Ryabinin wrote: > On 12/13/2016 09:15 PM, Andy Lutomirski wrote: > > But not quite acked by me. What happened to the vfree code that causes vfree_deferred to be called in a preemptable context? That sounds like a bug. >>> >>> Not sure I understand but the above stack points to a preemptible >>> context (copy_process). My stack was different and it looks preemptible as >>> well. >>> free_thread_stack calls vfree_atomic unconditionally. So I am not sure >>> why do you think this is a bug? >>> (This code doesn't exist in Linus' tree. What tree does this apply to.) >>> >>> Anyway, now that I am looking at Andrew's tree I can see [1] which >>> doesn't have this_cpu_ptr. So I am not sure where this this_cpu_ptr came >>> from. Maybe the previous version of the patch which has shown up in the >>> linux-next and Andrew has picked up [2] in the meantime. /me confused >>> >>> [1] http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-add-vfree_atomic.patch >>> [2] >>> http://lkml.kernel.org/r/1481553981-3856-1-git-send-email-aryabi...@virtuozzo.com >> >> The underlying issue seems to be that we have this shiny new function >> vfree_atomic() which doesn't work in *non-atomic* context and that we > > It does work non-atomic context. It's fixed now. > >> have "kernel/fork: use vfree_atomic() to free thread stack" that calls >> vfree_atomic() from non-atomic context. > > From both context actually. Usually task stack is freed from atomic context: > > http://lkml.kernel.org/r/20161019111541.gq29...@nuc-i3427.alporthouse.com > > http://lkml.kernel.org/r/calcetrvqjejgpqvudem8rk3uxdegfozy4cojqjqjcltbdnj...@mail.gmail.com > > On rare occasions it can be freed from non-atomic context, e.g. error path in > copy_process(). > >> I'm not sure what the motivation of the latter patch was, but ISTM we >> should revert it. TBH I'm not quite sure what the purpose of >> splitting vfree() and vfree_atomic() was, but I'm not seeing any >> reason that the common case of freeing stacks from non-atomic context >> should defer the free instead of just doing it right away. >> >> Andrey, Johannes, why should task stack freeing use vfree_atomic() in >> the first place? > > Because vfree() now can sleep and task stack freeing usually done in atomic > context. > > Fair enough. -- Andy Lutomirski AMA Capital Management, LLC
Re: [PATCH v2 2/2] drm/panel: simple: Add support BOE nv101wxmn51
在 2016年12月13日 04:22, Stéphane Marchesin 写道: On Wed, Dec 7, 2016 at 11:26 PM, Caesar Wang wrote: 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon TFT's as an active switching devices. It can be supported by the simple-panel driver. Read the panel edid information; EDID MODE DETAILS name = pixel_clock = 71900 lvds_dual_channel = 0 refresh = 0 ha = 1280 hbl = 160 hso = 48 hspw = 32 hborder = 0 va = 800 vbl = 32 vso = 3 vspw = 5 vborder = 0 phsync = + pvsync = - x_mm = 0 y_mm = 0 drm_display_mode .hdisplay = 1280 .hsync_start = 1328 .hsync_end = 1360 .htotal = 1440 .vdisplay = 800 .vsync_start = 803 .vsync_end = 808 .vtotal = 832 Signed-off-by: Caesar Wang --- Changes in v2: - fix the vsync_start and vsync_end from the edid. - change the commit. drivers/gpu/drm/panel/panel-simple.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 06aaf79..7c90f16 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -668,6 +668,34 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode boe_nv101wxmn51_mode = { + .clock = 71900, + .hdisplay = 1280, + .hsync_start = 1280 + 48, + .hsync_end = 1280 + 48 + 32, + .htotal = 1280 + 48 + 32 + 80, + .vdisplay = 800, + .vsync_start = 800 + 3, + .vsync_end = 800 + 3 + 5, + .vtotal = 800 + 3 + 5 + 24, + .vrefresh = 60, +}; + +static const struct panel_desc boe_nv101wxmn51 = { + .modes = &boe_nv101wxmn51_mode, + .num_modes = 1, There are two modes in the EDID (there is a downclock one). Can you add both modes? Yup, I will add them for next version. Thanks. -Caesar Stéphane + .bpc = 8, + .size = { + .width = 217, + .height = 136, + }, + .delay = { + .prepare = 210, + .enable = 50, + .unprepare = 160, + }, +}; + static const struct drm_display_mode chunghwa_claa070wp03xg_mode = { .clock = 66770, .hdisplay = 800, @@ -1748,6 +1776,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "boe,nv101wxmn51", + .data = &boe_nv101wxmn51, + }, { .compatible = "chunghwa,claa070wp03xg", .data = &chunghwa_claa070wp03xg, }, { -- 2.7.4 ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
linux-next: build warning after merge of the drivers-x86 tree
Hi Darren, After merging the drivers-x86 tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from include/linux/kernel.h:13:0, from drivers/platform/x86/thinkpad_acpi.c:52: drivers/platform/x86/thinkpad_acpi.c: In function 'hotkey_init': include/linux/printk.h:299:2: warning: 'type' may be used uninitialized in this function [-Wmaybe-uninitialized] printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) ^ drivers/platform/x86/thinkpad_acpi.c:3147:8: note: 'type' was declared here char *type; ^ In file included from include/linux/kernel.h:13:0, from drivers/platform/x86/thinkpad_acpi.c:52: include/linux/printk.h:299:2: warning: 'in_tablet_mode' may be used uninitialized in this function [-Wmaybe-uninitialized] printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) ^ drivers/platform/x86/thinkpad_acpi.c:3146:6: note: 'in_tablet_mode' was declared here int in_tablet_mode, res; ^ Introduced by commit b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into separate function") I can't tell if this is a false positive or not. -- Cheers, Stephen Rothwell
Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs
On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote: > The driver put a constant buffer of all zeros on the stack and > pointed a scatterlist entry at it in two places. This doesn't work > with virtual stacks. Use ZERO_PAGE instead. Wait a second... > - sg_set_buf(&sg_out[1], pad, sizeof pad); > + sg_set_buf(&sg_out[1], empty_zero_page, 16); My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what exactly is the code trying to do? The old code makes no sense. It's setting the *output* buffer to zeroed padding. --Andy
Re: [PATCH] vfio/pci: Support error recovery
On Wed, 14 Dec 2016 03:58:17 +0200 "Michael S. Tsirkin" wrote: > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote: > > On Tue, 13 Dec 2016 18:12:34 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote: > > > > On Tue, 13 Dec 2016 05:15:13 +0200 > > > > "Michael S. Tsirkin" wrote: > > > > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote: > > > > > > > So just don't do it then. Topology must match between host and > > > > > > > guest, > > > > > > > except maybe for the case of devices with host driver (e.g. PF) > > > > > > > which we might be able to synchronize against. > > > > > > > > > > > > We're talking about host kernel level handling here. The host > > > > > > kernel > > > > > > cannot defer the link reset to the user under the assumption that > > > > > > the > > > > > > user is handling the devices in a very specific way. The moment we > > > > > > do > > > > > > that, we've lost. > > > > > > > > > > The way is same as baremetal though, so why not? > > > > > > > > How do we know this? What if the user is dpdk? The kernel is > > > > responsible for maintaining the integrity of the system and devices, > > > > not the user. > > > > > > > > > And if user doesn't do what's expected, we can > > > > > do the full link reset on close. > > > > > > > > That's exactly my point, if we're talking about multiple devices, > > > > there's no guarantee that the close() for each is simultaneous. If one > > > > function is released before the other we cannot do a bus reset. If > > > > that device is then opened by another user before its sibling is > > > > released, then we once again cannot perform a link reset. I don't > > > > think it would be reasonable to mark the released device quarantined > > > > until the sibling is released, that would be a terrible user > > > > experience. > > > > > > Not sure why you find it so terrible, and I don't think there's another > > > way. > > > > If we can't do it without regressing the support we currently have, > > let's not do it at all. > > Why would we regress? As long as there are no unrecoverable errors, > there's no need to change behaviour at all. Currently if a fatal error occurs we allow the host to reset the device, so to the best of our knowledge, the device is always reset. The proposal here allows gaps where we assume a particular guest behavior that allows the device to be returned to the host or opened by other users without that reset. Any plan that relies on a specific user behavior is fundamentally wrong imo. > Alex, do you have a picture of how error recovery can work in your mind? > Your answers seem to imply you do, and these patches don't implement > this correctly. I'm not sure about others, but I for one am unable to > piece it together from the comments you provide. If yes, could you > maybe do a short writeup of an architecture you would be comfortable > with? Clearly I have issues with this skip-the-host-reset plan, I don't think it works. We cannot assume the user will do error recovery. As I stated previously we should enable the user to do error recovery without depending on the user to do error recovery. I'm a bit lost why we're focusing on this approach when the v9 approach of blocking user access to the device during the host recovery seemed like a better solution. I don't think I've said anything bad about that approach, but it does need further testing and debugging. Nobody seems to be interested in debugging why it wasn't quite working to understand whether that was an implementation issue or a design issue. That's currently the leading approach from my perspective. Thanks, Alex
[PATCH v2] wusbcore: Fix one more crypto-on-the-stack bug
The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers Signed-off-by: Andy Lutomirski --- drivers/usb/wusbcore/crypto.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/wusbcore/crypto.c b/drivers/usb/wusbcore/crypto.c index 79451f7ef1b7..062c205f0046 100644 --- a/drivers/usb/wusbcore/crypto.c +++ b/drivers/usb/wusbcore/crypto.c @@ -216,7 +216,6 @@ static int wusb_ccm_mac(struct crypto_skcipher *tfm_cbc, struct scatterlist sg[4], sg_dst; void *dst_buf; size_t dst_size; - const u8 bzero[16] = { 0 }; u8 iv[crypto_skcipher_ivsize(tfm_cbc)]; size_t zero_padding; @@ -261,7 +260,7 @@ static int wusb_ccm_mac(struct crypto_skcipher *tfm_cbc, sg_set_buf(&sg[1], &scratch->b1, sizeof(scratch->b1)); sg_set_buf(&sg[2], b, blen); /* 0 if well behaved :) */ - sg_set_buf(&sg[3], bzero, zero_padding); + sg_set_page(&sg[3], ZERO_PAGE(0), zero_padding, 0); sg_init_one(&sg_dst, dst_buf, dst_size); skcipher_request_set_tfm(req, tfm_cbc); -- 2.9.3
[no subject]
Good Day, This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer
[RESEND PATCH v4 0/2] change the proc handler for nsm_use_hostnames
Resend the v4 since I didn't add --to=linux-kernel@vger.kernel.org,sorry about it nsm_use_hostnames is a module parameter and it will be exported to sysctl procfs. This is to let user sometimes change it from userspace. But the minimal unit for sysctl procfs read/write it sizeof(int). In big endian system, the converting from/to bool to/from int will cause error for proc items. This patch introduces a new proc handler proc_dobool for nsm_use_hostnames. Changes: v4: Change (u8 *) to (bool *) v3: Introduce a new proc handler proc_dou8vec(suggested by Xinhui Pan) v2: Change extern type in lockd.h The test case I used: /***/ #include #include #include bool __read_mostly nsm_use_hostnames; module_param(nsm_use_hostnames, bool, 0644); static struct ctl_table my_sysctl[] = { { .procname = "nsm_use_hostnames", .data = &nsm_use_hostnames, .maxlen = sizeof(int), .mode = 0644, .proc_handler = &proc_dointvec, }, {} }; static struct ctl_table my_root[] = { { .procname = "mysysctl", .mode = 0555, .child = my_sysctl, }, {} }; static struct ctl_table_header * my_ctl_header; static int __init sysctl_exam_init(void) { my_ctl_header = register_sysctl_table(&my_root); if (my_ctl_header == NULL) printk("error regiester sysctl"); return 0; } static void __exit sysctl_exam_exit(void) { unregister_sysctl_table(my_ctl_header); } module_init(sysctl_exam_init); module_exit(sysctl_exam_exit); MODULE_LICENSE("GPL"); // [root@bigendian my]# insmod -f /root/my/hello.ko nsm_use_hostnames=1 [root@bigendian my]# cat /proc/sys/mysysctl/nsm_use_hostnames 16777216 After I change the proc_dointvec to new handler proc_dou8vec with the patch: [root@bigendian my]# insmod -f /root/my/hello.ko nsm_use_hostnames=1 [root@bigendian my]# cat /proc/sys/mysysctl/nsm_use_hostnames 1 In little endian system, there is no such issue. Already tested v4 in both of big and little endian(ppc64 and ppc64le) Jia He (2): sysctl: introduce new proc handler proc_dobool lockd: change the proc_handler for nsm_use_hostnames fs/lockd/svc.c | 2 +- include/linux/sysctl.h | 2 ++ kernel/sysctl.c| 35 +++ 3 files changed, 38 insertions(+), 1 deletion(-) -- 2.5.5
[RESEND PATCH v4 1/2] sysctl: introduce new proc handler proc_dobool
This is to let bool variable could be correctly displayed in big/little endian sysctl procfs. sizeof(bool) is arch dependent, proc_dobool should work in all arches. Suggested-by: Pan Xinhui Signed-off-by: Jia He --- include/linux/sysctl.h | 2 ++ kernel/sysctl.c| 35 +++ 2 files changed, 37 insertions(+) diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h index adf4e51..255a9c7 100644 --- a/include/linux/sysctl.h +++ b/include/linux/sysctl.h @@ -41,6 +41,8 @@ typedef int proc_handler (struct ctl_table *ctl, int write, extern int proc_dostring(struct ctl_table *, int, void __user *, size_t *, loff_t *); +extern int proc_dobool(struct ctl_table *, int, + void __user *, size_t *, loff_t *); extern int proc_dointvec(struct ctl_table *, int, void __user *, size_t *, loff_t *); extern int proc_douintvec(struct ctl_table *, int, diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 706309f..69f93cd 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -2112,6 +2112,20 @@ static int proc_put_char(void __user **buf, size_t *size, char c) return 0; } +static int do_proc_dobool_conv(bool *negp, unsigned long *lvalp, + int *valp, + int write, void *data) +{ + if (write) + *(bool *)valp = *lvalp; + else { + int val = *(bool *)valp; + + *lvalp = (unsigned long)val; + } + return 0; +} + static int do_proc_dointvec_conv(bool *negp, unsigned long *lvalp, int *valp, int write, void *data) @@ -2258,6 +2272,26 @@ static int do_proc_dointvec(struct ctl_table *table, int write, } /** + * proc_dobool - read/write a bool + * @table: the sysctl table + * @write: %TRUE if this is a write to the sysctl file + * @buffer: the user buffer + * @lenp: the size of the user buffer + * @ppos: file position + * + * Reads/writes up to table->maxlen/sizeof(unsigned int) integer + * values from/to the user buffer, treated as an ASCII string. + * + * Returns 0 on success. + */ +int proc_dobool(struct ctl_table *table, int write, + void __user *buffer, size_t *lenp, loff_t *ppos) +{ + return do_proc_dointvec(table, write, buffer, lenp, ppos, + do_proc_dobool_conv, NULL); +} + +/** * proc_dointvec - read a vector of integers * @table: the sysctl table * @write: %TRUE if this is a write to the sysctl file @@ -2941,6 +2975,7 @@ int proc_doulongvec_ms_jiffies_minmax(struct ctl_table *table, int write, * No sense putting this after each symbol definition, twice, * exception granted :-) */ +EXPORT_SYMBOL(proc_dobool); EXPORT_SYMBOL(proc_dointvec); EXPORT_SYMBOL(proc_douintvec); EXPORT_SYMBOL(proc_dointvec_jiffies); -- 2.5.5
[RESEND PATCH v4 2/2] lockd: change the proc_handler for nsm_use_hostnames
nsm_use_hostnames is a module parameter and it will be exported to sysctl procfs. This is to let user sometimes change it from userspace. But the minimal unit for sysctl procfs read/write it sizeof(int). In big endian system, the converting from/to bool to/from int will cause error for proc items. This patch use a new proc_handler proc_dobool. Signed-off-by: Jia He --- fs/lockd/svc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c index fc4084e..bd6fcf9 100644 --- a/fs/lockd/svc.c +++ b/fs/lockd/svc.c @@ -561,7 +561,7 @@ static struct ctl_table nlm_sysctls[] = { .data = &nsm_use_hostnames, .maxlen = sizeof(int), .mode = 0644, - .proc_handler = proc_dointvec, + .proc_handler = proc_dobool, }, { .procname = "nsm_local_state", -- 2.5.5
[PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs
The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it in two places. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: sta...@vger.kernel.org # 4.9 only Reported-by: Eric Biggers Signed-off-by: Andy Lutomirski --- security/keys/encrypted-keys/encrypted.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c index 17a06105ccb6..e963160ed26a 100644 --- a/security/keys/encrypted-keys/encrypted.c +++ b/security/keys/encrypted-keys/encrypted.c @@ -481,7 +481,6 @@ static int derived_key_encrypt(struct encrypted_key_payload *epayload, unsigned int encrypted_datalen; u8 iv[AES_BLOCK_SIZE]; unsigned int padlen; - char pad[16]; int ret; encrypted_datalen = roundup(epayload->decrypted_datalen, blksize); @@ -493,11 +492,10 @@ static int derived_key_encrypt(struct encrypted_key_payload *epayload, goto out; dump_decrypted_data(epayload); - memset(pad, 0, sizeof pad); sg_init_table(sg_in, 2); sg_set_buf(&sg_in[0], epayload->decrypted_data, epayload->decrypted_datalen); - sg_set_buf(&sg_in[1], pad, padlen); + sg_set_page(&sg_in[1], ZERO_PAGE(0), padlen, 0); sg_init_table(sg_out, 1); sg_set_buf(sg_out, epayload->encrypted_data, encrypted_datalen); @@ -584,7 +582,6 @@ static int derived_key_decrypt(struct encrypted_key_payload *epayload, struct skcipher_request *req; unsigned int encrypted_datalen; u8 iv[AES_BLOCK_SIZE]; - char pad[16]; int ret; encrypted_datalen = roundup(epayload->decrypted_datalen, blksize); @@ -594,13 +591,12 @@ static int derived_key_decrypt(struct encrypted_key_payload *epayload, goto out; dump_encrypted_data(epayload, encrypted_datalen); - memset(pad, 0, sizeof pad); sg_init_table(sg_in, 1); sg_init_table(sg_out, 2); sg_set_buf(sg_in, epayload->encrypted_data, encrypted_datalen); sg_set_buf(&sg_out[0], epayload->decrypted_data, epayload->decrypted_datalen); - sg_set_buf(&sg_out[1], pad, sizeof pad); + sg_set_buf(&sg_out[1], empty_zero_page, 16); memcpy(iv, epayload->iv, sizeof(iv)); skcipher_request_set_crypt(req, sg_in, sg_out, encrypted_datalen, iv); -- 2.9.3
Re: [PATCH 04/12] mfd: flexcard: add interrupt support
Hi Holger, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9] [cannot apply to ljones-mfd/for-mfd-next next-20161213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Holger-Dengler/Eberspaecher-Flexcard-PMC-II-base-support/20161214-082350 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All error/warnings (new ones prefixed by >>): drivers/mfd/flexcard_irq.c: In function 'flexcard_demux': >> drivers/mfd/flexcard_irq.c:111:3: error: implicit declaration of function >> 'generic_handle_irq' [-Werror=implicit-function-declaration] generic_handle_irq(cur); ^~ drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_ack': >> drivers/mfd/flexcard_irq.c:119:33: error: implicit declaration of function >> 'irq_data_get_irq_chip_data' [-Werror=implicit-function-declaration] struct flexcard_device *priv = irq_data_get_irq_chip_data(d); ^~ >> drivers/mfd/flexcard_irq.c:119:33: warning: initialization makes pointer >> from integer without a cast [-Wint-conversion] >> drivers/mfd/flexcard_irq.c:120:51: error: dereferencing pointer to >> incomplete type 'struct irq_data' const struct fc_irq_tab *tp = &flexcard_irq_tab[d->hwirq]; ^~ drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_mask': drivers/mfd/flexcard_irq.c:128:33: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct flexcard_device *priv = irq_data_get_irq_chip_data(d); ^~ drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_unmask': drivers/mfd/flexcard_irq.c:141:33: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct flexcard_device *priv = irq_data_get_irq_chip_data(d); ^~ drivers/mfd/flexcard_irq.c: At top level: >> drivers/mfd/flexcard_irq.c:175:15: error: variable 'flexcard_irq_chip' has >> initializer but incomplete type static struct irq_chip flexcard_irq_chip = { ^~~~ >> drivers/mfd/flexcard_irq.c:176:2: error: unknown field 'name' specified in >> initializer .name = "flexcard_irq", ^ >> drivers/mfd/flexcard_irq.c:176:11: warning: excess elements in struct >> initializer .name = "flexcard_irq", ^~ drivers/mfd/flexcard_irq.c:176:11: note: (near initialization for 'flexcard_irq_chip') >> drivers/mfd/flexcard_irq.c:177:2: error: unknown field 'irq_ack' specified >> in initializer .irq_ack = flexcard_irq_ack, ^ drivers/mfd/flexcard_irq.c:177:13: warning: excess elements in struct initializer .irq_ack = flexcard_irq_ack, ^~~~ drivers/mfd/flexcard_irq.c:177:13: note: (near initialization for 'flexcard_irq_chip') >> drivers/mfd/flexcard_irq.c:178:2: error: unknown field 'irq_mask' specified >> in initializer .irq_mask = flexcard_irq_mask, ^ drivers/mfd/flexcard_irq.c:178:14: warning: excess elements in struct initializer .irq_mask = flexcard_irq_mask, ^ drivers/mfd/flexcard_irq.c:178:14: note: (near initialization for 'flexcard_irq_chip') >> drivers/mfd/flexcard_irq.c:179:2: error: unknown field 'irq_unmask' >> specified in initializer .irq_unmask = flexcard_irq_unmask, ^ drivers/mfd/flexcard_irq.c:179:16: warning: excess elements in struct initializer .irq_unmask = flexcard_irq_unmask, ^~~ drivers/mfd/flexcard_irq.c:179:16: note: (near initialization for 'flexcard_irq_chip') drivers/mfd/flexcard_irq.c: In function 'flexcard_irq_domain_map': >> drivers/mfd/flexcard_irq.c:187:2: error: implicit declaration of function >> 'irq_set_chip_and_handler_name' [-Werror=implicit-function-declaration] irq_set_chip_and_handler_name(irq, &flexcard_irq_chip, ^ >> drivers/mfd/flexcard_irq.c:188:11: error: 'handle_level_irq' undeclared >> (first use in this function)
Re: [PATCH] pci-error-recover: doc cleanup
On Fri, Dec 09, 2016 at 05:50:17PM +1100, Andrew Donnellan wrote: >On 09/12/16 17:24, Linas Vepstas wrote: >>I suppose I'm confused, but I recall that link resets are non-fatal. >>Fatal errors typically require that the the pci adapter be completely >>reset, any adapter firmware to be reloaded from scratch, the device >>driver has to kill all device state and start from scratch. Its huge. > >Is there a difference in terminology between an AER fatal error and what >EEH/IBM people think of as a fatal error? > They are different things. AER fatal error can lead to frozen PE error, not fenced PHB error basing on the configuration on PHB. >>If the fatal error is on pci device that is under a block device >>holding a file system, then (usually) there is no way to recover, >>because the block layer (and file system) cannot deal with a block >>device that disappeared and then reappeared some few seconds later. >>(maybe some future zfs or lvm or btrfs might be able to deal with >>this, but not today) > >Is this still true? I'm not at all familiar with the block device side of it, >but the cxlflash driver has reasonably full EEH support, including surviving >a full PHB fence and complete reset. > It's still true, especially when the recovery is going to affect the rootfs. On completion of error recovery, the driver (if necessary) and filesystem needs to be reloaded which depends on script or daemon and they are unavailable in this scenario. Thanks, Gavin
Re: [PATCH] binder: replace kzalloc with kmem_cache
Hi, Greg: Sorry for the late response. On Tue, Nov 22, 2016 at 02:53:02PM +0100, Greg KH wrote: > On Tue, Nov 22, 2016 at 07:17:30PM +0800, Ganesh Mahendran wrote: > > This patch use kmem_cache to allocate/free binder objects. > > Why do this? I am not very familiar with kmem_cache. I think if we have thousands of active binder objects in system, kmem_cache would be better. Below is binder object number in my android system: - $ cat /d/binder/stats ... proc: active 100 total 6735 thread: active 1456 total 180807 node: active 5668 total 1027387 ref: active 7141 total 1214877 death: active 844 total 468056 transaction: active 0 total 54736890 transaction_complete: active 0 total 54736890 - binder objects are allocated/freed frequently. > > > It will have better memory efficiency. > > Really? How? It should be the same, if not a bit worse. Have you > tested this? What is the results? kzalloc will use object with size 2^n to store user data. Take "struct binder_thread" as example, its size is 296 bytes. If use kzalloc(), slab system will use 512 object size to store the 296 bytes. But if use kmem_cache to create a seperte(may be merged with other slab allocator) allocator, it will use 304 object size to store the 296 bytes. Below is information get from /proc/slabinfo : -- name binder_thread 858 858 304 26 2 memmory efficiency is : (296 * 26) / (2 * 4096) = 93.9% > > > And we can also get object usage details in /sys/kernel/slab/* for > > futher analysis. > > Why do we need this? Who needs this information and what are you going > to do with it? This is only for debug purpuse to see how much memory is used by binder. > > > Signed-off-by: Ganesh Mahendran > > --- > > drivers/android/binder.c | 127 > > ++- > > 1 file changed, 104 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > > index 3c71b98..f1f8362 100644 > > --- a/drivers/android/binder.c > > +++ b/drivers/android/binder.c > > @@ -54,6 +54,14 @@ > > static HLIST_HEAD(binder_deferred_list); > > static HLIST_HEAD(binder_dead_nodes); > > > > +static struct kmem_cache *binder_proc_cachep; > > +static struct kmem_cache *binder_thread_cachep; > > +static struct kmem_cache *binder_node_cachep; > > +static struct kmem_cache *binder_ref_cachep; > > +static struct kmem_cache *binder_transaction_cachep; > > +static struct kmem_cache *binder_work_cachep; > > +static struct kmem_cache *binder_ref_death_cachep; > > That's a lot of different caches, are you sure they don't just all get > merged together anyway for most allocators? If binder kmem_cache have the same flag with other allocator, it may be merged with other allocator. But I think it would be better than using kzalloc(). > > Don't create lots of little caches for no good reason, and without any > benchmark numbers, I'd prefer to leave this alone. You are going to > have to prove this is a win to allow this type of churn. I test binder with this patch. There is no performance regression. --- I run 10 times with below command: $binderThroughputTest -w 100 Beforeafter(with patch) avg: 9848.4 9878.8 Thanks. > > thanks, > > greg k-h
Re: undefined reference to `_text'
On Wed, Dec 14, 2016 at 05:00:22AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: b78b499a67c3f77aeb6cd0b54724bc38b141255d > commit: 7c7808ce107d63e158dbbc3af085980985a0c3c4 openrisc: prevent VGA > console, fix builds > date: 31 hours ago > config: openrisc-alldefconfig (attached as .config) > compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1 > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 7c7808ce107d63e158dbbc3af085980985a0c3c4 > # save the attached .config to linux build tree > make.cross ARCH=openrisc > > All errors (new ones prefixed by >>): > >.tmp_kallsyms1.o: In function `kallsyms_relative_base': > >> (.rodata+0x8a18): undefined reference to `_text' > I can reproduce this. Sorry about it never noticed before it seems specifically related to 'make alldefconfig' not happending with my config. Having a look. -Stafford
Re: [PATCH 09/10] s390/cputime: delayed accounting of system time
On Tue, Dec 13, 2016 at 02:21:21PM +0100, Martin Schwidefsky wrote: > On Tue, 13 Dec 2016 12:13:22 +0100 > Martin Schwidefsky wrote: > > > On Mon, 12 Dec 2016 16:02:30 +0100 > > Frederic Weisbecker wrote: > > > > > On Mon, Dec 12, 2016 at 11:27:54AM +0100, Martin Schwidefsky wrote: > > > > 3) The call to vtime_flush in account_process_tick is done in irq > > > > context from > > > >update_process_times. hardirq_offset==1 is also correct. > > > > > > Let's see this for example: > > > > > > + if ((tsk->flags & PF_VCPU) && (irq_count() - hardirq_offset == 0)) > > > + S390_lowcore.guest_timer += timer; > > > > > > If the tick is interrupting guest, we have accounted the guest time on > > > tick IRQ entry. > > > Now we are in the middle of the tick interrupt and since hardirq_offset > > > is 1, we > > > are taking the above path by accounting half of the tick-IRQ time as > > > guest, which is wrong, > > > it's actually IRQ time. > > > > Hmm, you got me there. The system time from irq_enter until > > account_process_tick > > is reached is indeed IRQ time. It is not much but it is incorrect. The best > > fix > > would be to rip out the accounting of the system time from > > account_process_tick > > as irq_enter / irq_exit will do system time accounting anyway. To do that > > do_account_vtime needs to be split, because for the task switch we need to > > account the system time of the previous task. > > New patch for the delayed cputime account. I can not just rip out system time > accounting from account_process_tick after all, I need a sync point for the > steal time calculation. It basically is the same patch as before but with a > new > helper update_tsk_timer, the removal of hardirq_offset and a simplification > for do_account_vtime: the last accounting delta is either hardirq time for > the tick or system time for the task switch. > > Keeping my finger crossed.. The patch looks good. But you might want to remove the hardirq_offset in a separate patch to queue for this merge window (I'm not sure if it needs a stable tag, the argument may be there since the beginning). Because the rest depends on the series that is unlikely to be queued in this merge window at this stage. Thanks!
[PATCH v3 0/2] FPGA: TS-7300 FPGA manager
Hi all, This patch series adds support for loading bitstreams into the Altera Cyclone II connected to an EP9302 on a TS-7300 board. Changes in v3: - fix write_init and write_complete signatures Changes in v2: - rebased against fpga/for-next - added defines for configuration bits and delays - added error mesage if ioremap() fails - detailed how the configuration through CPLD is done Florian Fainelli (2): ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300 FPGA: Add TS-7300 FPGA manager arch/arm/mach-ep93xx/ts72xx.c | 26 +++ drivers/fpga/Kconfig | 7 ++ drivers/fpga/Makefile | 1 + drivers/fpga/ts73xx-fpga.c| 163 ++ 4 files changed, 197 insertions(+) create mode 100644 drivers/fpga/ts73xx-fpga.c -- 2.9.3
[PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
Register the TS-7300 FPGA manager device drivers which allows us to load bitstreams into the on-board Altera Cyclone II FPGA. Signed-off-by: Florian Fainelli --- arch/arm/mach-ep93xx/ts72xx.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c index 3b39ea353d30..acf72ea670ef 100644 --- a/arch/arm/mach-ep93xx/ts72xx.c +++ b/arch/arm/mach-ep93xx/ts72xx.c @@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = { .phy_id = 1, }; +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX) + +/* Relative to EP93XX_CS1_PHYS_BASE */ +#define TS73XX_FPGA_LOADER_BASE0x03c0 + +static struct resource ts73xx_fpga_resources[] = { + { + .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE, + .end= EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1, + .flags = IORESOURCE_MEM, + }, +}; + +static struct platform_device ts73xx_fpga_device = { + .name = "ts73xx-fpga-mgr", + .id = -1, + .resource = ts73xx_fpga_resources, + .num_resources = ARRAY_SIZE(ts73xx_fpga_resources), +}; + +#endif + static void __init ts72xx_init_machine(void) { ep93xx_init_devices(); @@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void) platform_device_register(&ts72xx_wdt_device); ep93xx_register_eth(&ts72xx_eth_data, 1); +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX) + if (board_is_ts7300()) + platform_device_register(&ts73xx_fpga_device); +#endif } MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC") -- 2.9.3
[PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
Add support for loading bitstreams on the Altera Cyclone II FPGA populated on the TS-7300 board. This is done through the configuration and data registers offered through a memory interface between the EP93xx SoC and the FPGA via an intermediate CPLD device. The EP93xx SoC on the TS-7300 does not have direct means of configuring the on-board FPGA other than by using the special memory mapped interface to the CPLD. No other entity on the system can control the FPGA bitstream. Signed-off-by: Florian Fainelli --- drivers/fpga/Kconfig | 7 ++ drivers/fpga/Makefile | 1 + drivers/fpga/ts73xx-fpga.c | 163 + 3 files changed, 171 insertions(+) create mode 100644 drivers/fpga/ts73xx-fpga.c diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index ce861a2853a4..d9cbef60db80 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -33,6 +33,13 @@ config FPGA_MGR_SOCFPGA_A10 help FPGA manager driver support for Altera Arria10 SoCFPGA. +config FPGA_MGR_TS73XX + tristate "Technologic Systems TS-73xx SBC FPGA Manager" + depends on ARCH_EP93XX && MACH_TS72XX + help + FPGA manager driver support for the Altera Cyclone II FPGA + present on the TS-73xx SBC boards. + config FPGA_MGR_ZYNQ_FPGA tristate "Xilinx Zynq FPGA" depends on ARCH_ZYNQ || COMPILE_TEST diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index 8df07bcf42a6..a1160169e6d9 100644 --- a/drivers/fpga/Makefile +++ b/drivers/fpga/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o # FPGA Manager Drivers obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o # FPGA Bridge Drivers diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c new file mode 100644 index ..38d78d8c6b1e --- /dev/null +++ b/drivers/fpga/ts73xx-fpga.c @@ -0,0 +1,163 @@ +/* + * Technologic Systems TS-73xx SBC FPGA loader + * + * Copyright (C) 2016 Florian Fainelli + * + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on + * TS-7300, heavily based on load_fpga.c in their vendor tree. + * + * 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; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include + +#define TS73XX_FPGA_DATA_REG 0 +#define TS73XX_FPGA_CONFIG_REG 1 + +#define TS73XX_FPGA_WRITE_DONE 0x1 +#define TS73XX_FPGA_WRITE_DONE_TIMEOUT 1000/* us */ +#define TS73XX_FPGA_RESET 0x2 +#define TS73XX_FPGA_RESET_LOW_DELAY30 /* us */ +#define TS73XX_FPGA_RESET_HIGH_DELAY 80 /* us */ +#define TS73XX_FPGA_LOAD_OK0x4 +#define TS73XX_FPGA_CONFIG_LOAD0x8 + +struct ts73xx_fpga_priv { + void __iomem*io_base; + struct device *dev; +}; + +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr) +{ + return FPGA_MGR_STATE_UNKNOWN; +} + +static int ts73xx_fpga_write_init(struct fpga_manager *mgr, + struct fpga_image_info *info, + const char *buf, size_t count) +{ + struct ts73xx_fpga_priv *priv = mgr->priv; + + /* Reset the FPGA */ + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG); + udelay(TS73XX_FPGA_RESET_LOW_DELAY); + writeb(TS73XX_FPGA_RESET, priv->io_base + TS73XX_FPGA_CONFIG_REG); + udelay(TS73XX_FPGA_RESET_HIGH_DELAY); + + return 0; +} + +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf, +size_t count) +{ + struct ts73xx_fpga_priv *priv = mgr->priv; + size_t i = 0; + int ret; + u8 reg; + + while (count--) { + ret = readb_poll_timeout(priv->io_base + TS73XX_FPGA_CONFIG_REG, +reg, !(reg & TS73XX_FPGA_WRITE_DONE), +1, TS73XX_FPGA_WRITE_DONE_TIMEOUT); + if (ret < 0) + return ret; + + writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG); + i++; + } + + usleep_range(1000, 2000); + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG); + reg |= TS73XX_FPGA_CONFIG_LOAD; + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG); + usleep_range(1000, 2000); + + reg = readb(priv->io_base + TS73XX_FP
Re: [PATCH v2 0/2] FPGA: TS-7300 FPGA manager
On 12/13/2016 06:28 PM, Florian Fainelli wrote: > Hi all, > > This patch series adds support for loading bitstreams into the Altera Cyclone > II > connected to an EP9302 on a TS-7300 board. > > Changes in v2: > > - rebased against fpga/for-next > - added defines for configuration bits and delays > - added error mesage if ioremap() fails > - detailed how the configuration through CPLD is done I forgot to fix a function signature while rebasing, let me resubmit this. > > Florian Fainelli (2): > ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300 > FPGA: Add TS-7300 FPGA manager > > arch/arm/mach-ep93xx/ts72xx.c | 26 +++ > drivers/fpga/Kconfig | 7 ++ > drivers/fpga/Makefile | 1 + > drivers/fpga/ts73xx-fpga.c| 162 > ++ > 4 files changed, 196 insertions(+) > create mode 100644 drivers/fpga/ts73xx-fpga.c > -- Florian
Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management
On Saturday, December 10, 2016 12:52:28 AM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Enabling ACPI CPPC on x86 causes a NULL pointer dereference to occur > (on boot on a "default" KVM setup) in acpi_cppc_processor_exit() due > to a missing check against NULL in there: > > |BUG: unable to handle kernel NULL pointer dereference at (null) > |IP: [] acpi_cppc_processor_exit+0x40/0x60 > |PGD 0 [0.577616] > |Oops: [#1] SMP > |Modules linked in: > |CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51 > |task: 88003f878000 task.stack: c9008000 > |RIP: 0010:[] [] > acpi_cppc_processor_exit+0x40/0x60 > |RSP: :c900bd48 EFLAGS: 00010296 > |RAX: 000137e0 RBX: RCX: 0001 > |RDX: 88003fc0 RSI: RDI: 88003fbca130 > |RBP: c900bd60 R08: 0514 R09: > |R10: 0001 R11: R12: 0002 > |R13: 0020 R14: 8167cb00 R15: > |FS: () GS:88003fcc() knlGS: > |CS: 0010 DS: ES: CR0: 80050033 > |CR2: CR3: 01618000 CR4: 000406e0 > |Stack: > | 88003f939848 88003fbca130 0001 c900bd80 > | 812a4ccb 88003fc0cee8 c900bdb8 > | 812dc20d 88003fc0cee8 8167cb00 88003fc0cf48 > |Call Trace: > | [] acpi_processor_stop+0xb2/0xc5 > | [] driver_probe_device+0x14d/0x2f0 > | [] __driver_attach+0x6e/0x90 > | [] bus_for_each_dev+0x54/0x90 > | [] driver_attach+0x19/0x20 > | [] bus_add_driver+0xe6/0x200 > | [] driver_register+0x83/0xc0 > | [] acpi_processor_driver_init+0x20/0x94 > | [] do_one_initcall+0x97/0x180 > | [] kernel_init_freeable+0x112/0x1a6 > | [] kernel_init+0x9/0xf0 > | [] ret_from_fork+0x25/0x30 > |Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 > 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 > 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8 > |RIP [] acpi_cppc_processor_exit+0x40/0x60 > | RSP > |CR2: > > Fix that and while at it, fix a possible use-after-free scenario in > acpi_cppc_processor_probe() that can happen if the function returns > without cleaning up the per-CPU pointer set by it previously. > > Reported-by: Sebastian Andrzej Siewior > Original-by: Sebastian Andrzej Siewior > Signed-off-by: Rafael J. Wysocki > --- > > Hi Thomas, > > The crash fixed by this is exposed by the ITMT (asymmetric packing) series > (which involves using ACPI CPPC on x86), so IMO it would be good to route it > through tip along with that series. The problematic commit has gone in already, so I'll route the fix through the ACPI tree. Thanks, Rafael
[PATCH v2 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
Register the TS-7300 FPGA manager device drivers which allows us to load bitstreams into the on-board Altera Cyclone II FPGA. Signed-off-by: Florian Fainelli --- arch/arm/mach-ep93xx/ts72xx.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c index 3b39ea353d30..acf72ea670ef 100644 --- a/arch/arm/mach-ep93xx/ts72xx.c +++ b/arch/arm/mach-ep93xx/ts72xx.c @@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = { .phy_id = 1, }; +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX) + +/* Relative to EP93XX_CS1_PHYS_BASE */ +#define TS73XX_FPGA_LOADER_BASE0x03c0 + +static struct resource ts73xx_fpga_resources[] = { + { + .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE, + .end= EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1, + .flags = IORESOURCE_MEM, + }, +}; + +static struct platform_device ts73xx_fpga_device = { + .name = "ts73xx-fpga-mgr", + .id = -1, + .resource = ts73xx_fpga_resources, + .num_resources = ARRAY_SIZE(ts73xx_fpga_resources), +}; + +#endif + static void __init ts72xx_init_machine(void) { ep93xx_init_devices(); @@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void) platform_device_register(&ts72xx_wdt_device); ep93xx_register_eth(&ts72xx_eth_data, 1); +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX) + if (board_is_ts7300()) + platform_device_register(&ts73xx_fpga_device); +#endif } MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC") -- 2.9.3
[PATCH v2 2/2] FPGA: Add TS-7300 FPGA manager
Add support for loading bitstreams on the Altera Cyclone II FPGA populated on the TS-7300 board. This is done through the configuration and data registers offered through a memory interface between the EP93xx SoC and the FPGA via an intermediate CPLD device. The EP93xx SoC on the TS-7300 does not have direct means of configuring the on-board FPGA other than by using the special memory mapped interface to the CPLD. No other entity on the system can control the FPGA bitstream. Signed-off-by: Florian Fainelli --- drivers/fpga/Kconfig | 7 ++ drivers/fpga/Makefile | 1 + drivers/fpga/ts73xx-fpga.c | 162 + 3 files changed, 170 insertions(+) create mode 100644 drivers/fpga/ts73xx-fpga.c diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index ce861a2853a4..d9cbef60db80 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -33,6 +33,13 @@ config FPGA_MGR_SOCFPGA_A10 help FPGA manager driver support for Altera Arria10 SoCFPGA. +config FPGA_MGR_TS73XX + tristate "Technologic Systems TS-73xx SBC FPGA Manager" + depends on ARCH_EP93XX && MACH_TS72XX + help + FPGA manager driver support for the Altera Cyclone II FPGA + present on the TS-73xx SBC boards. + config FPGA_MGR_ZYNQ_FPGA tristate "Xilinx Zynq FPGA" depends on ARCH_ZYNQ || COMPILE_TEST diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index 8df07bcf42a6..a1160169e6d9 100644 --- a/drivers/fpga/Makefile +++ b/drivers/fpga/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o # FPGA Manager Drivers obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o # FPGA Bridge Drivers diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c new file mode 100644 index ..c004be5954ae --- /dev/null +++ b/drivers/fpga/ts73xx-fpga.c @@ -0,0 +1,162 @@ +/* + * Technologic Systems TS-73xx SBC FPGA loader + * + * Copyright (C) 2016 Florian Fainelli + * + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on + * TS-7300, heavily based on load_fpga.c in their vendor tree. + * + * 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; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include + +#define TS73XX_FPGA_DATA_REG 0 +#define TS73XX_FPGA_CONFIG_REG 1 + +#define TS73XX_FPGA_WRITE_DONE 0x1 +#define TS73XX_FPGA_WRITE_DONE_TIMEOUT 1000/* us */ +#define TS73XX_FPGA_RESET 0x2 +#define TS73XX_FPGA_RESET_LOW_DELAY30 /* us */ +#define TS73XX_FPGA_RESET_HIGH_DELAY 80 /* us */ +#define TS73XX_FPGA_LOAD_OK0x4 +#define TS73XX_FPGA_CONFIG_LOAD0x8 + +struct ts73xx_fpga_priv { + void __iomem*io_base; + struct device *dev; +}; + +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr) +{ + return FPGA_MGR_STATE_UNKNOWN; +} + +static int ts73xx_fpga_write_init(struct fpga_manager *mgr, u32 flags, + const char *buf, size_t count) +{ + struct ts73xx_fpga_priv *priv = mgr->priv; + + /* Reset the FPGA */ + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG); + udelay(TS73XX_FPGA_RESET_LOW_DELAY); + writeb(TS73XX_FPGA_RESET, priv->io_base + TS73XX_FPGA_CONFIG_REG); + udelay(TS73XX_FPGA_RESET_HIGH_DELAY); + + return 0; +} + +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf, +size_t count) +{ + struct ts73xx_fpga_priv *priv = mgr->priv; + size_t i = 0; + int ret; + u8 reg; + + while (count--) { + ret = readb_poll_timeout(priv->io_base + TS73XX_FPGA_CONFIG_REG, +reg, !(reg & TS73XX_FPGA_WRITE_DONE), +1, TS73XX_FPGA_WRITE_DONE_TIMEOUT); + if (ret < 0) + return ret; + + writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG); + i++; + } + + usleep_range(1000, 2000); + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG); + reg |= TS73XX_FPGA_CONFIG_LOAD; + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG); + usleep_range(1000, 2000); + + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG); + reg &= ~TS73XX_FPGA_CONFIG_LO