Re: [PATCH v4 2/5] clk: aspeed: Register core clocks
On Tue, 2017-10-03 at 17:25 +1030, Joel Stanley wrote:
> This registers the core clocks; those which are required to calculate
> the rate of the timer peripheral so the system can load a clocksource
> driver.
>
> Signed-off-by: Joel Stanley
>
> ---
> v4:
> - Add defines to document the BIT() macros
> v3:
> - Fix ast2400 ahb calculation
> - Remove incorrect 'this is wrong' comment
> - Separate out clkin calc to be per platform
> - Support 48MHz clkin on ast2400
> ---
> drivers/clk/clk-aspeed.c | 177
> +++
> 1 file changed, 177 insertions(+)
>
> diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
> index a45eb351bb05..d39cf51a5114 100644
> --- a/drivers/clk/clk-aspeed.c
> +++ b/drivers/clk/clk-aspeed.c
> @@ -20,7 +20,23 @@
>
> #include
>
> +#define ASPEED_RESET_CTRL0x04
> +#define ASPEED_CLK_SELECTION 0x08
> +#define ASPEED_CLK_STOP_CTRL 0x0c
> +#define ASPEED_MPLL_PARAM0x20
> +#define ASPEED_HPLL_PARAM0x24
> +#define AST2500_HPLL_BYPASS_EN BIT(20)
> +#define AST2400_HPLL_STRAPPED BIT(18)
> +#define AST2400_HPLL_BYPASS_EN BIT(17)
> +#define ASPEED_MISC_CTRL 0x2c
> +#define UART_DIV13_EN BIT(12)
> #define ASPEED_STRAP 0x70
> +#define CLKIN_25MHZ_EN BIT(23)
> +#define AST2400_CLK_SOURCE_SEL BIT(18)
> +#define ASPEED_CLK_SELECTION_2 0xd8
> +
> +/* Globally visible clocks */
> +static DEFINE_SPINLOCK(aspeed_clk_lock);
>
> /* Keeps track of all clocks */
> static struct clk_hw_onecell_data *aspeed_clk_data;
> @@ -98,6 +114,160 @@ static const struct aspeed_gate_data aspeed_gates[]
> __initconst = {
> [ASPEED_CLK_GATE_LHCCLK] = { 28, -1, "lhclk-gate",
> "lhclk", 0 }, /* LPC master/LPC+ */
> };
>
> +static const struct clk_div_table ast2400_div_table[] = {
> + { 0x0, 2 },
> + { 0x1, 4 },
> + { 0x2, 6 },
> + { 0x3, 8 },
> + { 0x4, 10 },
> + { 0x5, 12 },
> + { 0x6, 14 },
> + { 0x7, 16 },
> + { 0 }
> +};
> +
> +static const struct clk_div_table ast2500_div_table[] = {
> + { 0x0, 4 },
> + { 0x1, 8 },
> + { 0x2, 12 },
> + { 0x3, 16 },
> + { 0x4, 20 },
> + { 0x5, 24 },
> + { 0x6, 28 },
> + { 0x7, 32 },
> + { 0 }
> +};
> +
> +static struct clk_hw *aspeed_ast2400_calc_pll(const char *name, u32 val)
> +{
> + unsigned int mult, div;
> +
> + if (val & AST2400_HPLL_BYPASS_EN) {
> + /* Pass through mode */
> + mult = div = 1;
> + } else {
> + /* F = 24Mhz * (2-OD) * [(N + 2) / (D + 1)] */
> + u32 n = (val >> 5) & 0x3f;
> + u32 od = (val >> 4) & 0x1;
> + u32 d = val & 0xf;
> +
> + mult = (2 - od) * (n + 2);
> + div = d + 1;
> + }
> + return clk_hw_register_fixed_factor(NULL, name, "clkin", 0,
> + mult, div);
> +};
> +
> +static struct clk_hw *aspeed_ast2500_calc_pll(const char *name, u32 val)
> +{
> + unsigned int mult, div;
> +
> + if (val & AST2500_HPLL_BYPASS_EN) {
> + /* Pass through mode */
> + mult = div = 1;
> + } else {
> + /* F = clkin * [(M+1) / (N+1)] / (P + 1) */
> + u32 p = (val >> 13) & 0x3f;
> + u32 m = (val >> 5) & 0xff;
> + u32 n = val & 0x1f;
> +
> + mult = (m + 1) / (n + 1);
> + div = p + 1;
> + }
> +
> + return clk_hw_register_fixed_factor(NULL, name, "clkin", 0,
> + mult, div);
> +}
> +
> +static void __init aspeed_ast2400_cc(struct regmap *map)
> +{
> + struct clk_hw *hw;
> + u32 val, freq, div;
> +
> + /*
> + * CLKIN is the crystal oscillator, 24, 48 or 25MHz selected by
> + * strapping
> + */
> + regmap_read(map, ASPEED_STRAP, &val);
> + if (val & CLKIN_25MHZ_EN)
> + freq = 2500;
> + else if (val & AST2400_CLK_SOURCE_SEL)
> + freq = 4800;
> + else
> + freq = 2400;
> + hw = clk_hw_register_fixed_rate(NULL, "clkin", NULL, 0, freq);
> + pr_debug("clkin @%u MHz\n", freq / 100);
> +
> + /*
> + * High-speed PLL clock derived from the crystal. This the CPU clock,
> + * and we assume that it is enabled
> + */
> + regmap_read(map, ASPEED_HPLL_PARAM, &val);
> + WARN(val & AST2400_HPLL_STRAPPED, "hpll is strapped not configured");
> + aspeed_clk_data->hws[ASPEED_CLK_HPLL] = aspeed_ast2400_calc_pll("hpll",
> val);
> +
> + /*
> + * Strap bits 11:10 define the CPU/AHB clock frequency ratio (aka HCLK)
> + * 00: Select CPU:AHB = 1:1
> + * 01: Select CPU:AHB = 2:1
> + * 10: Select CPU:AHB = 4:1
> + * 11: Select CPU:AHB = 3:1
> + */
> + regmap_read(map, ASPEED_STRAP, &val);
> + val = (val >> 10) & 0x3;
> + div = val + 1;
> + if (div == 3)
> + div = 4;
> + else if (div == 4)
> + d
Re: [PATCH] scsi: fcoe: Convert timers to use timer_setup()
Looks good, Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: spi-atmel.c: regression
Hello! Hello! please help to manage issue with data corruption by PDC of SPI. I have compared operation of Linux-2.6.39 and linux4sam kernel 4.9.36+ on the AT91SAM9G20 (Stamp9G20 SOM from Taskit.de) and found regression in the spi-atmel.c. New spi-atmel.c driver works very bad with SPI speeds above 6 MHz. I see corruption in data received by Linux and SPI overruns when OS has big CPI and IO load. Old kernel works fine at 22 MHz with the same device driver and hardware. Can somebody comment and/or help on how to resolve this issue? Best wishes. -- Igor Plyatov For those, who has same interest or encountered the same issue as I had... Notes: A) My "gs_mgms_dsp" linux driver is the same for linux-2.6.39 and linux-4.9.36 and communicates with DSP through SPI-bus, where data packets are 32 byte long and last byte is CRC8 to check data integrity. B) CPU is AT91SAM9G20. I have encoutered SPI data corruption during receiving of data from DSP by linux-4.9.36 if SPI-bus has big traffic in parallel with big traffic at MMC interface. Old linux-2.6.39 does not suffer from such issue, because atmel-mci.c driver has PIO access to MMC interface. While new kernel has changed the atmel-mci.c driver for use of PDC (Peripheral DMA Controller) for access to MMC interface. Both kernels have Atmel SPI driver where PDC used for SPI data transfers. SPI data corruption looks like duplication of one of received bytes. Such bytes surrounded by "**" at log below. gs_mgms_dsp spi32766.0: CRC error. gs_mgms_dsp spi32766.0: <- 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 gs_mgms_dsp spi32766.0: <- 45 46 47 48 49 4A 4B 4C 4D *4F 4F* 50 51 52 53 A4 gs_mgms_dsp spi32766.0: -> EIO=0x05 gs_mgms_dsp spi32766.0: CRC error. gs_mgms_dsp spi32766.0: <- 0F C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 gs_mgms_dsp spi32766.0: <- D1 D2 D3 D4 D5 D6 D7 D8 D9 *DB DB* DC DD DE DF 02 gs_mgms_dsp spi32766.0: -> EIO=0x05 gs_mgms_dsp spi32766.0: CRC error. gs_mgms_dsp spi32766.0: <- 03 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 gs_mgms_dsp spi32766.0: <- *6A 6A* 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 25 gs_mgms_dsp spi32766.0: -> EIO=0x05 gs_mgms_dsp spi32766.0: CRC error. gs_mgms_dsp spi32766.0: <- 15 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 gs_mgms_dsp spi32766.0: <- 85 86 87 88 89 8A *8C 8C* 8D 8E 8F 90 91 92 93 00 gs_mgms_dsp spi32766.0: -> EIO=0x05 gs_mgms_dsp spi32766.0: CRC error. gs_mgms_dsp spi32766.0: <- 2A EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA gs_mgms_dsp spi32766.0: <- FB FC FD FE FF 00 01 *03 03* 04 05 06 07 08 09 0A gs_mgms_dsp spi32766.0: -> EIO=0x05 This looks like silent SPI overruns not detected by AT91SAM9G20 HW. At the end, after some seconds or milliseconds of communication, HW SPI overrun flag detected by the spi-atmel.c driver: "atmel_spi fffcc000.spi: overrun (0/0 remaining)". Strictly speaking this is not a regression of spi-atmel.c, but unfortunate combination with atmel-mmc.c, where PDC used too and I suppose a HW bug in AT91SAM9G20 CPU. Please help to answer on questions: 1) How to modify atmel-mci.c driver to have option for PIO access to MMC interface? 2) Why SPI overrun flag does not asserted each time? I have not found such HW bug in the Errata for AT91SAM9G20 CPU. Best wishes. -- Igor Plyatov
Re: [RFC] mmap(MAP_CONTIG)
On 10/04/2017 01:56 AM, Mike Kravetz wrote: Hi, > At Plumbers this year, Guy Shattah and Christoph Lameter gave a presentation > titled 'User space contiguous memory allocation for DMA' [1]. The slides Hm I didn't find slides on that link, are they available? > point out the performance benefits of devices that can take advantage of > larger physically contiguous areas. > > When such physically contiguous allocations are done today, they are done > within drivers themselves in an ad-hoc manner. As Michal N. noted, the drivers might have different requirements. Is contiguity (without extra requirements) so common that it would benefit from a userspace API change? Also how are the driver-specific allocations done today? mmap() on the driver's device? Maybe we could provide some in-kernel API/library to make them less "ad-hoc". Conversion to MAP_ANONYMOUS would at first seem like an improvement in that userspace would be able to use a generic allocation API and all the generic treatment of anonymous pages (LRU aging, reclaim, migration etc), but the restrictions you listed below eliminate most of that? (It's likely that I just don't have enough info about how it works today so it's difficult to judge) > In addition to allocations > for DMA, allocations of this type are also performed for buffers used by > coprocessors and other acceleration engines. > > As mentioned in the presentation, posix specifies an interface to obtain > physically contiguous memory. This is via typed memory objects as described > in the posix_typed_mem_open() man page. Since Linux today does not follow > the posix typed memory object model, adding infrastructure for contiguous > memory allocations seems to be overkill. Instead, a proposal was suggested > to add support via a mmap flag: MAP_CONTIG. > > mmap(MAP_CONTIG) would have the following semantics: > - The entire mapping (length size) would be backed by physically contiguous > pages. > - If 'length' physically contiguous pages can not be allocated, then mmap > will fail. > - MAP_CONTIG only works with MAP_ANONYMOUS mappings. > - MAP_CONTIG will lock the associated pages in memory. As such, the same > privileges and limits that apply to mlock will also apply to MAP_CONTIG. > - A MAP_CONTIG mapping can not be expanded. > - At fork time, private MAP_CONTIG mappings will be converted to regular > (non-MAP_CONTIG) mapping in the child. As such a COW fault in the child > will not require a contiguous allocation. > > Some implementation considerations: > - alloc_contig_range() or similar will be used for allocations larger > than MAX_ORDER. > - MAP_CONTIG should imply MAP_POPULATE. At mmap time, all pages for the > mapping must be 'pre-allocated', and they can only be used for the mapping, > so it makes sense to 'fault in' all pages. > - Using 'pre-allocated' pages in the fault paths may be intrusive. > - We need to keep keep track of those pre-allocated pages until the vma is > tore down, especially if free_contig_range() must be called. > > Thoughts? > - Is such an interface useful? > - Any other ideas on how to achieve the same functionality? > - Any thoughts on implementation? > > I have started down the path of pre-allocating contiguous pages at mmap > time and hanging those off the vma(vm_private_data) with some kludges to > use the pages at fault time. It is really ugly, which is why I am not > sharing the code. Hoping for some comments/suggestions. > > [1] https://www.linuxplumbersconf.org/2017/ocw/proposals/4669 >
Re: [PATCH] staging: ccree: local variable "dev" not required
Hi Suniel,
On Wed, Oct 4, 2017 at 10:12 PM, wrote:
> From: Suniel Mahesh
>
> There is no need to create a local pointer variable "dev" and
> pass it various API's, instead use plat_dev which is enumerated
> by platform core on successful probe.
>
> Signed-off-by: Suniel Mahesh
> ---
I'm sorry but I don't understand what is the problem you are trying to solve or
what is the improvement suggested.
Why is having a local variable undesirable? I think having it makes
the code more
readable, not less.
Thanks,
Gilad
> Note:
> - Patch was tested and built(ARCH=arm) on staging-testing.
> - No build issues reported, however it was not tested on
> real hardware.
> ---
> drivers/staging/ccree/ssi_driver.c | 63
> +++---
> 1 file changed, 31 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/staging/ccree/ssi_driver.c
> b/drivers/staging/ccree/ssi_driver.c
> index 5f03c25..eb907ce 100644
> --- a/drivers/staging/ccree/ssi_driver.c
> +++ b/drivers/staging/ccree/ssi_driver.c
> @@ -205,12 +205,11 @@ static int init_cc_resources(struct platform_device
> *plat_dev)
> struct resource *req_mem_cc_regs = NULL;
> void __iomem *cc_base = NULL;
> struct ssi_drvdata *new_drvdata;
> - struct device *dev = &plat_dev->dev;
> - struct device_node *np = dev->of_node;
> + struct device_node *np = plat_dev->dev.of_node;
> u32 signature_val;
> int rc = 0;
>
> - new_drvdata = devm_kzalloc(dev, sizeof(*new_drvdata), GFP_KERNEL);
> + new_drvdata = devm_kzalloc(&plat_dev->dev, sizeof(*new_drvdata),
> GFP_KERNEL);
> if (!new_drvdata) {
> rc = -ENOMEM;
> goto post_drvdata_err;
> @@ -225,16 +224,16 @@ static int init_cc_resources(struct platform_device
> *plat_dev)
> /* First CC registers space */
> req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
> /* Map registers space */
> - new_drvdata->cc_base = devm_ioremap_resource(dev, req_mem_cc_regs);
> + new_drvdata->cc_base = devm_ioremap_resource(&plat_dev->dev,
> req_mem_cc_regs);
> if (IS_ERR(new_drvdata->cc_base)) {
> - dev_err(dev, "Failed to ioremap registers");
> + dev_err(&plat_dev->dev, "Failed to ioremap registers");
> rc = PTR_ERR(new_drvdata->cc_base);
> goto post_drvdata_err;
> }
>
> - dev_dbg(dev, "Got MEM resource (%s): %pR\n", req_mem_cc_regs->name,
> + dev_dbg(&plat_dev->dev, "Got MEM resource (%s): %pR\n",
> req_mem_cc_regs->name,
> req_mem_cc_regs);
> - dev_dbg(dev, "CC registers mapped from %pa to 0x%p\n",
> + dev_dbg(&plat_dev->dev, "CC registers mapped from %pa to 0x%p\n",
> &req_mem_cc_regs->start, new_drvdata->cc_base);
>
> cc_base = new_drvdata->cc_base;
> @@ -242,120 +241,120 @@ static int init_cc_resources(struct platform_device
> *plat_dev)
> /* Then IRQ */
> new_drvdata->irq = platform_get_irq(plat_dev, 0);
> if (new_drvdata->irq < 0) {
> - dev_err(dev, "Failed getting IRQ resource\n");
> + dev_err(&plat_dev->dev, "Failed getting IRQ resource\n");
> rc = new_drvdata->irq;
> goto post_drvdata_err;
> }
>
> - rc = devm_request_irq(dev, new_drvdata->irq, cc_isr,
> + rc = devm_request_irq(&plat_dev->dev, new_drvdata->irq, cc_isr,
> IRQF_SHARED, "arm_cc7x", new_drvdata);
> if (rc) {
> - dev_err(dev, "Could not register to interrupt %d\n",
> + dev_err(&plat_dev->dev, "Could not register to interrupt
> %d\n",
> new_drvdata->irq);
> goto post_drvdata_err;
> }
> - dev_dbg(dev, "Registered to IRQ: %d\n", new_drvdata->irq);
> + dev_dbg(&plat_dev->dev, "Registered to IRQ: %d\n", new_drvdata->irq);
>
> rc = cc_clk_on(new_drvdata);
> if (rc)
> goto post_drvdata_err;
>
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> + if (!plat_dev->dev.dma_mask)
> + plat_dev->dev.dma_mask = &plat_dev->dev.coherent_dma_mask;
>
> - if (!dev->coherent_dma_mask)
> - dev->coherent_dma_mask = DMA_BIT_MASK(DMA_BIT_MASK_LEN);
> + if (!plat_dev->dev.coherent_dma_mask)
> + plat_dev->dev.coherent_dma_mask =
> DMA_BIT_MASK(DMA_BIT_MASK_LEN);
>
> /* Verify correct mapping */
> signature_val = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF,
> HOST_SIGNATURE));
> if (signature_val != DX_DEV_SIGNATURE) {
> - dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X !=
> expected=0x%08X\n",
> + dev_err(&plat_dev->dev, "Invalid CC signature:
> SIGNATURE=0x%08X != expected=0x%08X\n",
> signature_val, (u32)DX_DEV_SIGNATURE);
>
Re: [PATCH v8 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor
Hi Leon, On Thu, Oct 05, 2017 at 12:06:16AM -0700, Leon Luo wrote: >Hi Sakari, >I just got an email saying the patch is accepted. Do I still need to do >anything here? Do I need to add MEDIA_CAMERA_SUPPORT dependency to >Kconfig and submit a new version? Please don't send HTML e-mail. I've added the Kconfig dependency so there's no need to send further versions of the patch. -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver
On Thu, Oct 05, 2017 at 08:29:10AM +0300, Andy Shevchenko wrote:
> On Thu, Oct 5, 2017 at 4:09 AM, Darren Hart wrote:
> > On Wed, Oct 04, 2017 at 05:48:31PM -0500, Mario Limonciello wrote:
> >> All communication on individual GUIDs should occur in separate drivers.
> >> Allowing a driver to communicate with the bus to another GUID is just
> >> a hack that discourages drivers to adopt the bus model.
> >>
> >> The information found from the WMI descriptor driver is now exported
> >> for use by other drivers.
>
> > You'll want to add something like:
> >
> > #ifdef CONFIG_DELL_WMI_DESCRIPTOR_MODULE
> > if (request_module("dell_wmi_descriptor"))
> > /* FAIL */
> > #endif
> >
> > During init.
>
> I don't think #ifdef is needed.
Without the ifdef, we can't distinguish between request_module failing
to load the module because it isn't available and because it is
built-in.
>
> We may just request module.
>
> But looking in the code it seems that we simple need to select that
> module. No request_module will be needed.
The select will ensure the module is built, but there is not guarantee
to module load order. The intent of the above is to ensure the symbols
from the required module are loaded.
> Did I miss something?
Or I did :-) Is there something about this module which ensures
dell_wmi_descriptor is loaded first?
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH v4 4/5] cramfs: add mmap support
On Wed, Oct 04, 2017 at 04:47:52PM -0400, Nicolas Pitre wrote:
> The only downside so far is the lack of visibility from user space to
> confirm it actually works as intended. With the vma splitting approach
> you clearly see what gets directly mapped in /proc/*/maps thanks to
> remap_pfn_range() storing the actual physical address in vma->vm_pgoff.
> With VM_MIXEDMAP things are no longer visible. Any opinion for the best
> way to overcome this?
Add trace points that allow you to trace it using trace-cmd, perf
or just tracefs?
>
> Anyway, here's a replacement for patch 4/5 below:
This looks much better, and is about 100 lines less than the previous
version. More (mostly cosmetic) comments below:
> + blockptrs = (u32 *)(sbi->linear_virt_addr + OFFSET(inode) + pgoff*4);
missing psaces around the *
>
> + blockaddr = blockptrs[0] & ~CRAMFS_BLK_FLAGS;
> + i = 0;
> + do {
> + u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
There are a lot of magic numbers in here. It seems like that's standard
for cramfs, but if you really plan to bring it back to live it would be
create to sort that out..
> + expect |=
> CRAMFS_BLK_FLAG_DIRECT_PTR|CRAMFS_BLK_FLAG_UNCOMPRESSED;
Too long line.
Just turn this into:
u32 expect = blockaddr + i * (PAGE_SIZE >> 2) |
CRAMFS_BLK_FLAG_DIRECT_PTR |
CRAMFS_BLK_FLAG_UNCOMPRESSED;
and it will be a lot more readable.
> +static int cramfs_physmem_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct inode *inode = file_inode(file);
> + struct super_block *sb = inode->i_sb;
> + struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
> + unsigned int pages, vma_pages, max_pages, offset;
> + unsigned long address;
> + char *fail_reason;
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_MMU))
> + return vma->vm_flags & (VM_SHARED | VM_MAYSHARE) ? 0 : -ENOSYS;
Given that you have a separate #ifndef CONFIG_MMU section below just
have a separate implementation of cramfs_physmem_mmap for it, which
makes the code a lot more obvious.
> + /* Could COW work here? */
> + fail_reason = "vma is writable";
> + if (vma->vm_flags & VM_WRITE)
> + goto fail;
The fail_reaosn is a rather unusable style, is there any good reason
why you need it here? We generall don't add a debug printk for every
pssible failure case.
> + vma_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE - 1) >> PAGE_SHIFT;
Just use vma_pages - the defintion is different, but given that vm_end
and vm_stat must be page aligned anyway it should not make a difference.
> + if (pages > max_pages - vma->vm_pgoff)
> + pages = max_pages - vma->vm_pgoff;
Use min() or min_t().
> + /* Don't map the last page if it contains some other data */
> + if (unlikely(vma->vm_pgoff + pages == max_pages)) {
> + unsigned int partial = offset_in_page(inode->i_size);
> + if (partial) {
> + char *data = sbi->linear_virt_addr + offset;
> + data += (max_pages - 1) * PAGE_SIZE + partial;
> + while ((unsigned long)data & 7)
> + if (*data++ != 0)
> + goto nonzero;
> + while (offset_in_page(data)) {
> + if (*(u64 *)data != 0) {
> + nonzero:
> + pr_debug("mmap: %s: last page is
> shared\n",
> +
> file_dentry(file)->d_name.name);
> + pages--;
> + break;
> + }
> + data += 8;
> + }
The nonzer label is in a rather unusual space, both having weird
indentation and being in the middle of the loop.
It seems like this whole partial section should just go into a little
helper where the nonzero case is at the end of said helper to make it
readable. Also lots of magic numbers again, and generally a little
too much magic for the code to be easily understandable: why do you
operate on pointers casted to longs, increment in 8-byte steps?
Why is offset_in_page used for an operation that doesn't operate on
struct page at all? Any reason you can't just use memchr_inv?
> + if (!pages) {
> + fail_reason = "no suitable block remaining";
> + goto fail;
> + } else if (pages != vma_pages) {
No if else please if you goto a different label, that just confuses the
user.
> + /*
> + * Let's create a mixed map if we can't map it all.
> + * The normal paging machinery will take care of the
> + * unpopulated vma via cramfs_readpage().
> + */
> + int i;
> + vma->vm_flags |= VM_MIXEDMAP;
> +
Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when requested by drivers
On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace that the results from the method call
> belong to the data request to the method call. Sysfs attributes don't
> work well in this scenario because two userspace processes may be
> competing at reading/writing an attribute and step on each other's
> data.
And you protect this from happening in the ioctl? I didn't see it, but
ok, I'll take your word for it :)
> When a WMI vendor driver declares an ioctl in a file_operations object
> the WMI bus driver will create a character device that maps to those
> file operations.
>
> That character device will correspond to this path:
> /dev/wmi/$driver
>
> The WMI bus driver will interpret the IOCTL calls, test them for
> a valid instance and pass them on to the vendor driver to run.
>
> This creates an implicit policy that only driver per character
> device. If a module matches multiple GUID's, the wmi_devices
> will need to be all handled by the same wmi_driver if the same
> character device is used.
Interesting "way out" but ok, I can buy it...
> The WMI vendor drivers will be responsible for managing access to
> this character device and proper locking on it.
>
> When a WMI vendor driver is unloaded the WMI bus driver will clean
> up the character device.
>
> Signed-off-by: Mario Limonciello
> ---
> MAINTAINERS| 1 +
> drivers/platform/x86/wmi.c | 67
> +-
> include/linux/wmi.h| 2 ++
> include/uapi/linux/wmi.h | 10 +++
> 4 files changed, 79 insertions(+), 1 deletion(-)
> create mode 100644 include/uapi/linux/wmi.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0357e9b1cfaf..6db1d84999bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -372,6 +372,7 @@ ACPI WMI DRIVER
> L: platform-driver-...@vger.kernel.org
> S: Orphan
> F: drivers/platform/x86/wmi.c
> +F: include/uapi/linux/wmi.h
>
> AD1889 ALSA SOUND DRIVER
> M: Thibaut Varene
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index bcb41c1c7f52..5aef052b4aab 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -38,6 +38,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -69,6 +70,7 @@ struct wmi_block {
> struct wmi_device dev;
> struct list_head list;
> struct guid_block gblock;
> + struct miscdevice misc_dev;
> struct acpi_device *acpi_device;
> wmi_notify_handler handler;
> void *handler_data;
> @@ -765,22 +767,80 @@ static int wmi_dev_match(struct device *dev, struct
> device_driver *driver)
> return 0;
> }
>
> +static long wmi_ioctl(struct file *filp, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct wmi_driver *wdriver;
> + struct wmi_block *wblock;
> + const char *driver_name;
> + struct list_head *p;
> + bool found = false;
> +
> + if (_IOC_TYPE(cmd) != WMI_IOC)
> + return -ENOTTY;
> +
> + driver_name = filp->f_path.dentry->d_iname;
> +
> + list_for_each(p, &wmi_block_list) {
> + wblock = list_entry(p, struct wmi_block, list);
> + wdriver = container_of(wblock->dev.dev.driver,
> + struct wmi_driver, driver);
> + if (strcmp(driver_name, wdriver->driver.name) == 0) {
> + found = true;
> + break;
> + }
> + }
You can provide an open() call to handle this type of logic for you, so
you don't have to do it on every ioctl() call, but I guess it's not
really a big deal, right?
> + if (!found ||
> + !wdriver->file_operations ||
> + !wdriver->file_operations->unlocked_ioctl)
> + return -ENODEV;
Shouldn't you check for unlocked_ioctl() already? No need to check it
here, right?
And if you are only passing down unlocked_ioctl, there's no need for a
whole empty file_operations structure in the driver, right? Just have
an ioctl callback to make things smaller and simpler to understand.
> + /* make sure we're not calling a higher instance */
> + if (_IOC_NR(cmd) > wblock->gblock.instance_count)
> + return -EINVAL;
What exactly does this protect from?
> + /* driver wants a character device made */
> + if (wdriver->file_operations) {
Check for unlocked_ioctl here, actually, drop the file_operations
entirely, and just have that one callback.
> + buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
No unwinding of other logic needed?
> + strcpy(buf, "wmi/");
> + strcpy(buf + 4, wdriver->driver.name);
> +
Re: [RESEND PATCH v5 10/16] mtd: nand: qcom: add command elements in BAM transaction
On Mon, 25 Sep 2017 13:21:25 +0530
Abhishek Sahu wrote:
> All the QPIC register read/write through BAM DMA requires
> command descriptor which contains the array of command elements.
>
> Reviewed-by: Archit Taneja
> Signed-off-by: Abhishek Sahu
Applied both.
Thanks,
Boris
> ---
>
> * Changes from v4: None
>
> The BAM DMA patches [1] got merged in 4.14-rc1 so now all the build
> dependencies are solved and this patch can be merged.
> This patch can be cleanly applied over v4.14-rc1.
>
> [1] http://www.spinics.net/lists/dmaengine/msg13665.html
>
> drivers/mtd/nand/qcom_nandc.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
> index 7977a70..b0a4734 100644
> --- a/drivers/mtd/nand/qcom_nandc.c
> +++ b/drivers/mtd/nand/qcom_nandc.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> /* NANDc reg offsets */
> #define NAND_FLASH_CMD 0x00
> @@ -199,6 +200,7 @@
> */
> #define dev_cmd_reg_addr(nandc, reg) ((nandc)->props->dev_cmd_reg_start +
> (reg))
>
> +#define QPIC_PER_CW_CMD_ELEMENTS 32
> #define QPIC_PER_CW_CMD_SGL 32
> #define QPIC_PER_CW_DATA_SGL 8
>
> @@ -221,8 +223,13 @@
> /*
> * This data type corresponds to the BAM transaction which will be used for
> all
> * NAND transfers.
> + * @bam_ce - the array of BAM command elements
> * @cmd_sgl - sgl for NAND BAM command pipe
> * @data_sgl - sgl for NAND BAM consumer/producer pipe
> + * @bam_ce_pos - the index in bam_ce which is available for next sgl
> + * @bam_ce_start - the index in bam_ce which marks the start position ce
> + * for current sgl. It will be used for size calculation
> + * for current sgl
> * @cmd_sgl_pos - current index in command sgl.
> * @cmd_sgl_start - start index in command sgl.
> * @tx_sgl_pos - current index in data sgl for tx.
> @@ -231,8 +238,11 @@
> * @rx_sgl_start - start index in data sgl for rx.
> */
> struct bam_transaction {
> + struct bam_cmd_element *bam_ce;
> struct scatterlist *cmd_sgl;
> struct scatterlist *data_sgl;
> + u32 bam_ce_pos;
> + u32 bam_ce_start;
> u32 cmd_sgl_pos;
> u32 cmd_sgl_start;
> u32 tx_sgl_pos;
> @@ -462,7 +472,8 @@ static void free_bam_transaction(struct
> qcom_nand_controller *nandc)
>
> bam_txn_size =
> sizeof(*bam_txn) + num_cw *
> - ((sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL) +
> + ((sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS) +
> + (sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL) +
> (sizeof(*bam_txn->data_sgl) * QPIC_PER_CW_DATA_SGL));
>
> bam_txn_buf = devm_kzalloc(nandc->dev, bam_txn_size, GFP_KERNEL);
> @@ -472,6 +483,10 @@ static void free_bam_transaction(struct
> qcom_nand_controller *nandc)
> bam_txn = bam_txn_buf;
> bam_txn_buf += sizeof(*bam_txn);
>
> + bam_txn->bam_ce = bam_txn_buf;
> + bam_txn_buf +=
> + sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS * num_cw;
> +
> bam_txn->cmd_sgl = bam_txn_buf;
> bam_txn_buf +=
> sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL * num_cw;
> @@ -489,6 +504,8 @@ static void clear_bam_transaction(struct
> qcom_nand_controller *nandc)
> if (!nandc->props->is_bam)
> return;
>
> + bam_txn->bam_ce_pos = 0;
> + bam_txn->bam_ce_start = 0;
> bam_txn->cmd_sgl_pos = 0;
> bam_txn->cmd_sgl_start = 0;
> bam_txn->tx_sgl_pos = 0;
Re: [PATCH v4 4/8] mtd: nand: atmel: Avoid ECC errors when leaving backup mode
On Thu, 28 Sep 2017 11:46:23 +0200
Romain Izard wrote:
> During backup mode, the contents of all registers will be cleared as the
> SoC will be completely powered down. For a product that boots on NAND
> Flash memory, the bootloader will obviously use the related controller
> to read the Flash and correct any detected error in the memory, before
> handling back control to the kernel's resuming entry point.
>
> But it does not clean the NAND controller registers after use and on its
> side the kernel driver expects the error locator to be powered down and
> in a clean state. Add a resume hook for the PMECC error locator, and
> reset its registers.
>
> Signed-off-by: Romain Izard
Applied.
Thanks,
Boris
> ---
> Changes in v3:
> * keep the PMECC disabled when not in use, and use atmel_pmecc_resume to
> reset the controller after the bootloader has left it enabled.
>
> Changes in v4:
> * export atmel_pmecc_reset instead of atmel_pmecc_resume
> * use the correct pointer in atmel_nand_controller_resume
>
> drivers/mtd/nand/atmel/nand-controller.c | 3 +++
> drivers/mtd/nand/atmel/pmecc.c | 17 +
> drivers/mtd/nand/atmel/pmecc.h | 1 +
> 3 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mtd/nand/atmel/nand-controller.c
> b/drivers/mtd/nand/atmel/nand-controller.c
> index f25eca79f4e5..8afcff9a66ea 100644
> --- a/drivers/mtd/nand/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/atmel/nand-controller.c
> @@ -2530,6 +2530,9 @@ static __maybe_unused int
> atmel_nand_controller_resume(struct device *dev)
> struct atmel_nand_controller *nc = dev_get_drvdata(dev);
> struct atmel_nand *nand;
>
> + if (nc->pmecc)
> + atmel_pmecc_reset(nc->pmecc);
> +
> list_for_each_entry(nand, &nc->chips, node) {
> int i;
>
> diff --git a/drivers/mtd/nand/atmel/pmecc.c b/drivers/mtd/nand/atmel/pmecc.c
> index 146af8218314..0a3f12141c45 100644
> --- a/drivers/mtd/nand/atmel/pmecc.c
> +++ b/drivers/mtd/nand/atmel/pmecc.c
> @@ -765,6 +765,13 @@ void atmel_pmecc_get_generated_eccbytes(struct
> atmel_pmecc_user *user,
> }
> EXPORT_SYMBOL_GPL(atmel_pmecc_get_generated_eccbytes);
>
> +void atmel_pmecc_reset(struct atmel_pmecc *pmecc)
> +{
> + writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> +}
> +EXPORT_SYMBOL_GPL(atmel_pmecc_reset);
> +
> int atmel_pmecc_enable(struct atmel_pmecc_user *user, int op)
> {
> struct atmel_pmecc *pmecc = user->pmecc;
> @@ -797,10 +804,7 @@ EXPORT_SYMBOL_GPL(atmel_pmecc_enable);
>
> void atmel_pmecc_disable(struct atmel_pmecc_user *user)
> {
> - struct atmel_pmecc *pmecc = user->pmecc;
> -
> - writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> - writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + atmel_pmecc_reset(user->pmecc);
> mutex_unlock(&user->pmecc->lock);
> }
> EXPORT_SYMBOL_GPL(atmel_pmecc_disable);
> @@ -855,10 +859,7 @@ static struct atmel_pmecc *atmel_pmecc_create(struct
> platform_device *pdev,
>
> /* Disable all interrupts before registering the PMECC handler. */
> writel(0x, pmecc->regs.base + ATMEL_PMECC_IDR);
> -
> - /* Reset the ECC engine */
> - writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> - writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + atmel_pmecc_reset(pmecc);
>
> return pmecc;
> }
> diff --git a/drivers/mtd/nand/atmel/pmecc.h b/drivers/mtd/nand/atmel/pmecc.h
> index a8ddbfca2ea5..817e0dd9fd15 100644
> --- a/drivers/mtd/nand/atmel/pmecc.h
> +++ b/drivers/mtd/nand/atmel/pmecc.h
> @@ -61,6 +61,7 @@ atmel_pmecc_create_user(struct atmel_pmecc *pmecc,
> struct atmel_pmecc_user_req *req);
> void atmel_pmecc_destroy_user(struct atmel_pmecc_user *user);
>
> +void atmel_pmecc_reset(struct atmel_pmecc *pmecc);
> int atmel_pmecc_enable(struct atmel_pmecc_user *user, int op);
> void atmel_pmecc_disable(struct atmel_pmecc_user *user);
> int atmel_pmecc_wait_rdy(struct atmel_pmecc_user *user);
Re: [PATCH v4 3/5] clk: aspeed: Add platform driver and register PLLs
On Tue, 2017-10-03 at 17:25 +1030, Joel Stanley wrote:
> This registers a platform driver to set up all of the non-core clocks.
>
> The clocks that have configurable rates are now registered.
>
> Signed-off-by: Joel Stanley
>
> --
> v4:
> - Add eclk div table to fix ast2500 calculation
> - Add defines to document the BIT() macros
> - Pass dev where we can when registering clocks
> - Check for errors when registering clk_hws
> v3:
> - Fix bclk and eclk calculation
> - Seperate out ast2400 and ast25000 for pll calculation
>
> Signed-off-by: Joel Stanley
> ---
> drivers/clk/clk-aspeed.c | 163
> +++
> 1 file changed, 163 insertions(+)
>
> diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
> index d39cf51a5114..adb295292189 100644
> --- a/drivers/clk/clk-aspeed.c
> +++ b/drivers/clk/clk-aspeed.c
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -114,6 +116,32 @@ static const struct aspeed_gate_data aspeed_gates[]
> __initconst = {
> [ASPEED_CLK_GATE_LHCCLK] = { 28, -1, "lhclk-gate",
> "lhclk", 0 }, /* LPC master/LPC+ */
> };
>
> +static const char * const eclk_parents[] = {"d1pll", "hpll", "mpll"};
Hate to throw a spanner in the works, but I think we need some extra bits here
for handling the AST2400. ECLK with M-PLL as the parent divides the clock rate
by 2, there are four cases to handle where the last two cases are inverted, and
d1pll isn't a valid parent.
Also this table looks to be in reverse order to the field defined in the
datasheet.
> +
> +static const struct clk_div_table ast2500_eclk_div_table[] = {
> + { 0x0, 2 },
> + { 0x1, 2 },
> + { 0x2, 3 },
> + { 0x3, 4 },
> + { 0x4, 5 },
> + { 0x5, 6 },
> + { 0x6, 7 },
> + { 0x7, 8 },
> + { 0 }
> +};
> +
> +static const struct clk_div_table ast2500_mac_div_table[] = {
> + { 0x0, 4 }, /* Yep, really. Aspeed confirmed this is correct */
> + { 0x1, 4 },
> + { 0x2, 6 },
> + { 0x3, 8 },
> + { 0x4, 10 },
> + { 0x5, 12 },
> + { 0x6, 14 },
> + { 0x7, 16 },
> + { 0 }
> +};
> +
> static const struct clk_div_table ast2400_div_table[] = {
> { 0x0, 2 },
> { 0x1, 4 },
> @@ -179,6 +207,141 @@ static struct clk_hw *aspeed_ast2500_calc_pll(const
> char *name, u32 val)
> mult, div);
> }
>
> +struct aspeed_clk_soc_data {
> + const struct clk_div_table *div_table;
> + const struct clk_div_table *mac_div_table;
> + const struct clk_div_table *eclk_div_table;
> + struct clk_hw *(*calc_pll)(const char *name, u32 val);
As a note, I just discovered the D-PLL (and D2-PLL where applicable) frequency
function is slightly different to M-PLL and H-PLL on both the AST2400 and
AST2500. I don't think that is significant yet, but it's something to watch out
for. The point is this callback isn't a general-purpose "calculate a PLL
frequency" function, so the name might be inappropriate.
> +};
> +
> +static const struct aspeed_clk_soc_data ast2500_data = {
> + .div_table = ast2500_div_table,
> + .mac_div_table = ast2500_mac_div_table,
> + .eclk_div_table = ast2500_eclk_div_table,
> + .calc_pll = aspeed_ast2500_calc_pll,
> +};
> +
> +static const struct aspeed_clk_soc_data ast2400_data = {
> + .div_table = ast2400_div_table,
> + .mac_div_table = ast2400_div_table,
> + .eclk_div_table = ast2400_div_table,
> + .calc_pll = aspeed_ast2400_calc_pll,
> +};
> +
> +static int aspeed_clk_probe(struct platform_device *pdev)
> +{
> + const struct aspeed_clk_soc_data *soc_data;
> + struct device *dev = &pdev->dev;
> + struct regmap *map;
> + struct clk_hw *hw;
> + u32 val, rate;
> +
> + map = syscon_node_to_regmap(dev->of_node);
> + if (IS_ERR(map)) {
> + dev_err(dev, "no syscon regmap\n");
> + return PTR_ERR(map);
> + }
> +
> + /* SoC generations share common layouts but have different divisors */
> + soc_data = of_device_get_match_data(dev);
> + if (!soc_data) {
> + dev_err(dev, "no match data for platform\n");
> + return -EINVAL;
> + }
> +
> + /* UART clock div13 setting */
> + regmap_read(map, ASPEED_MISC_CTRL, &val);
> + if (val & UART_DIV13_EN)
> + rate = 2400 / 13;
> + else
> + rate = 2400;
> + /* TODO: Find the parent data for the uart clock */
> + hw = clk_hw_register_fixed_rate(dev, "uart", NULL, 0, rate);
> + if (IS_ERR(hw))
> + return PTR_ERR(hw);
> + aspeed_clk_data->hws[ASPEED_CLK_UART] = hw;
> +
> + /*
> + * Memory controller (M-PLL) PLL. This clock is configured by the
> + * bootloader, and is exposed to Linux as a read-only clock rate.
> + */
> + regmap_read(map, ASPEED_MPLL_PARAM, &val);
> + hw = soc_data->calc_pll("mpll", val);
> + if (IS_ERR(hw))
> +
[RFH] 4.9.52: task blocked for more than 300 seconds - xen_clocksource_get_cycles?
Hello, in a VM running linux-4.9.52 on Debian-Wheezy with Xen-4.1 I observed several stuck processes: Here is one (truncated) dump of the Linux kernel messages: > [] ? __schedule+0x23d/0x6d0 > [] ? bit_wait_timeout+0x90/0x90 > [] ? schedule+0x32/0x80 > [] ? schedule_timeout+0x1ec/0x360 > [] ? __blk_mq_run_hw_queue+0x327/0x3e0 *** see below > [] ? xen_clocksource_get_cycles+0x11/0x20 > [] ? bit_wait_timeout+0x90/0x90 > [] ? io_schedule_timeout+0xb4/0x130 > [] ? prepare_to_wait+0x57/0x80 > [] ? bit_wait_io+0x17/0x60 > [] ? __wait_on_bit+0x5c/0x90 > [] ? bit_wait_timeout+0x90/0x90 > [] ? out_of_line_wait_on_bit+0x7e/0xa0 > [] ? autoremove_wake_function+0x40/0x40 > [] ? jbd2_journal_commit_transaction+0xd48/0x17e0 [jbd2] > [] ? __switch_to+0x2c9/0x720 > [] ? try_to_del_timer_sync+0x4d/0x80 > [] ? kjournald2+0xdd/0x280 [jbd2] > [] ? wake_up_atomic_t+0x30/0x30 > [] ? commit_timeout+0x10/0x10 [jbd2] > [] ? kthread+0xf0/0x110 > [] ? __switch_to+0x2c9/0x720 > [] ? kthread_park+0x60/0x60 > [] ? ret_from_fork+0x25/0x30 > NMI backtrace for cpu 2 > CPU: 2 PID: 35 Comm: khungtaskd Not tainted 4.9.0-ucs105-amd64 #1 Debian > 4.9.30-2A~4.2.0.201709271649 > 81331935 0002 > 81335e60 0002 8104cb70 8801f0c90e80 > 81335f6a 8801f0c90e80 003fffbc 81128048 > Call Trace: > [] ? dump_stack+0x5c/0x77 > [] ? nmi_cpu_backtrace+0x90/0xa0 > [] ? irq_force_complete_move+0x140/0x140 > [] ? nmi_trigger_cpumask_backtrace+0xfa/0x130 > [] ? watchdog+0x2b8/0x330 > [] ? reset_hung_task_detector+0x10/0x10 > [] ? kthread+0xf0/0x110 > [] ? __switch_to+0x2c9/0x720 > [] ? kthread_park+0x60/0x60 > [] ? ret_from_fork+0x25/0x30 > Sending NMI from CPU 2 to CPUs 0-1,3: > NMI backtrace for cpu 1 > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0-ucs105-amd64 #1 Debian > 4.9.30-2A~4.2.0.201709271649 > task: 8801f4a02ec0 task.stack: c90040ca4000 > RIP: e030:[] [] > xen_hypercall_sched_op+0xa/0x20 > RSP: e02b:c90040ca7ed0 EFLAGS: 0246 > RAX: RBX: 8801f4a02ec0 RCX: 810013aa > RDX: 81c4ba70 RSI: RDI: 0001 > RBP: 0001 R08: R09: > R10: 7ff0 R11: 0246 R12: > R13: R14: 8801f4a02ec0 R15: 8801f4a02ec0 > FS: 7f23ac595700() GS:8801f5a8() knlGS: > CS: e033 DS: 002b ES: 002b CR0: 80050033 > CR2: 7f52537d6d46 CR3: 0001bba23000 CR4: 2660 > Stack: > 8801bb832201 0001 8101b55c 81611ec8 > 8801f4a02ec0 0001 810bc280 8801f4a02ec0 > 8801f4a02ec0 c0a995961d41240f addce6dcadd009c9 > Call Trace: > [] ? xen_safe_halt+0xc/0x20 > [] ? default_idle+0x18/0xd0 > [] ? cpu_startup_entry+0x1f0/0x260 > Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc > cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > NMI backtrace for cpu 3 > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.0-ucs105-amd64 #1 Debian > 4.9.30-2A~4.2.0.201709271649 > task: 8801f4a24f00 task.stack: c90040cb4000 > RIP: e030:[] [] > xen_hypercall_sched_op+0xa/0x20 > RSP: e02b:c90040cb7ed0 EFLAGS: 0246 > RAX: RBX: 8801f4a24f00 RCX: 810013aa > RDX: 81c4ba70 RSI: RDI: 0001 > RBP: 0003 R08: R09: > R10: 7ff0 R11: 0246 R12: > R13: R14: 8801f4a24f00 R15: 8801f4a24f00 > FS: 7f1a2af19700() GS:8801f5b8() knlGS: > CS: e033 DS: 002b ES: 002b CR0: 80050033 > CR2: 7f4a5416b000 CR3: 0001d83ec000 CR4: 2660 > Stack: > 0001 0001 8101b55c 81611ec8 > 8801f4a24f00 0003 810bc280 8801f4a24f00 > 8801f4a24f00 77816deb133b9979 addce6dcadd009c9 > Call Trace: > [] ? xen_safe_halt+0xc/0x20 > [] ? default_idle+0x18/0xd0 > [] ? cpu_startup_entry+0x1f0/0x260 > Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc > cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > NMI backtrace for cpu 0 > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-ucs105-amd64 #1 Debian > 4.9.30-2A~4.2.0.201709271649 > task: 81c0e540 task.stack: 81c0 > RIP: e030:[] [] > xen_hypercall_sched_op+0xa/0x20 > RSP: e02b:81c03e90 EFLAGS: 0246 > RAX: RBX: 81c0e540 RCX: 810013aa > RDX: 81c4ba70 RSI: RDI: 0001 > RBP: R08: 00
Re: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface
On Wed, Oct 04, 2017 at 05:48:39PM -0500, Mario Limonciello wrote:
> This userspace character device will be used to perform SMBIOS calls
> from any applications.
>
> It provides an ioctl that will allow passing the 32k WMI calling
> interface buffer between userspace and kernel space.
{sigh} Did you really test this? It feels like it wasn't, due to the
api you are using here. Did you run it with a 32bit userspace and 64bit
kernel? 32bit kernel/userspace? How well did your userspace developer
fall down crying when you tried that? :)
> This character device is intended to deprecate the dcdbas kernel module
> and the interface that it provides to userspace.
At least that driver has a well-documented api to userspace, you are
throwing all of that away here, are you _sure_ you want to do that?
Seems like you just made things much harder.
> It's important for the driver to provide a R/W ioctl to ensure that
> two competing userspace processes don't race to provide or read each
> others data.
The whole goal of this patch is to provide that ioctl, right? So of
course it is "important" :)
> The API for interacting with this interface is defined in documentation
> as well as a uapi header provides the format of the structures.
Ok, let's _just_ review that api please:
> diff --git a/include/uapi/linux/dell-smbios-wmi.h
> b/include/uapi/linux/dell-smbios-wmi.h
> new file mode 100644
> index ..0d0d09b04021
> --- /dev/null
> +++ b/include/uapi/linux/dell-smbios-wmi.h
> @@ -0,0 +1,25 @@
> +#ifndef _UAPI_DELL_SMBIOS_WMI_H_
> +#define _UAPI_DELL_SMBIOS_WMI_H_
> +
> +#include
> +#include
> +
> +struct wmi_calling_interface_buffer {
> + u16 class;
> + u16 select;
> + u32 input[4];
> + u32 output[4];
> + u32 argattrib;
> + u32 blength;
> + u8 *data;
> +} __packed;
{sigh}
For structures that cross the user/kernel boundry, you _HAVE_ to use the
correct types. For some things, that is easy, u16 needs to be __u16,
u32 needs to be __u32, but u8*? Hah, good luck! Remember what I
mentioned above about 32/64 bit issues?
Why do you need a pointer here at all? You are providing a huge chunk
of memory to the ioctl, what's the use of a pointer? How are you
dereferenceing this pointer (remember, it's a userspace pointer, which
you are not saying here, so odds are the kernel code is wrong...)
> +struct wmi_smbios_ioctl {
> + u32 length;
__u32.
And why not __u64? Is 32 bits always going to be ok?
> + struct wmi_calling_interface_buffer *buf;
Another pointer? 2 pointer dereferences in the same ioctl structure?
Crazy, you are wanting to make your life harder than it has to be...
> +};
> +
> +/* only offers on the single instance */
> +#define DELL_WMI_SMBIOS_CMD WMI_IOWR(0)
I don't understand the comment, please explain it better.
Please sit down and work out your api here, I don't think you have
thought it through properly, given the number of pointers alone.
thanks,
greg k-h
Re: [PATCH v2] mtd: nand: pxa3xx_nand: Update Kconfig information
On Fri, 29 Sep 2017 15:34:24 +0200 Gregory CLEMENT wrote: > More and more SoCs use the pxa3xx_nand driver for their controller but > the list of them was not updated. This patch add the last SoCs using the > driver. > Applied. Thanks, Boris > Signed-off-by: Gregory CLEMENT > --- > Changelog v1->v2: > > - Improve wording thanks to Thomas Petazzoni > > drivers/mtd/nand/Kconfig | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 3f2036f31da4..bb48aafed9a2 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -317,8 +317,11 @@ config MTD_NAND_PXA3xx > tristate "NAND support on PXA3xx and Armada 370/XP" > depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU > help > + > This enables the driver for the NAND flash device found on > - PXA3xx processors (NFCv1) and also on Armada 370/XP (NFCv2). > + PXA3xx processors (NFCv1) and also on 32-bit Armada > + platforms (XP, 370, 375, 38x, 39x) and 64-bit Armada > + platforms (7K, 8K) (NFCv2). > > config MTD_NAND_SLC_LPC32XX > tristate "NXP LPC32xx SLC Controller"
Re: [PATCH] mwifiex: Use put_unaligned_le32
Himanshu Jha writes: > Use put_unaligned_le32 rather than using byte ordering function and > memcpy which makes code clear. > Also, add the header file where it is declared. > > Done using Coccinelle and semantic patch used is : > > @ rule1 @ > identifier tmp; expression ptr,x; type T; > @@ > > - tmp = cpu_to_le32(x); > > <+... when != tmp > - memcpy(ptr, (T)&tmp, ...); > + put_unaligned_le32(x,ptr); > ...+> > > @ depends on rule1 @ > type j; identifier tmp; > @@ > > - j tmp; > ...when != tmp > > Signed-off-by: Himanshu Jha > --- > drivers/net/wireless/marvell/mwifiex/cmdevt.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c > b/drivers/net/wireless/marvell/mwifiex/cmdevt.c > index 0edc5d6..e28e119 100644 > --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c > +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c > @@ -17,6 +17,7 @@ > * this warranty disclaimer. > */ > > +#include I don't think this is correct. Should it be asm/unaligned.h? -- Kalle Valo
Re: [PATCH v3] mtd: nand: denali: fix setup_data_interface to meet tCCS delay
On Fri, 29 Sep 2017 23:12:57 +0900 Masahiro Yamada wrote: > The WE_2_RE register specifies the number of clock cycles inserted > between the rising edge of #WE and the falling edge of #RE. > > The current setup_data_interface implementation takes care of tWHR, > but tCCS is missing. Wait for max(tCSS, tWHR) to meet the spec. > > With setup_data_interface() properly programmed, the Denali NAND > controller can observe the timing, so NAND_WAIT_TCCS flag is unneeded. > Clarify this in the comment block. Applied. Thanks, Boris > > Signed-off-by: Masahiro Yamada > --- > > Changes in v3: > - Remove comment abount NAND_WAIT_TWHR because 1/2 seems NACK > > Changes in v2: > - newly added > > drivers/mtd/nand/denali.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c > index 0b268ec..5124f8a 100644 > --- a/drivers/mtd/nand/denali.c > +++ b/drivers/mtd/nand/denali.c > @@ -1004,8 +1004,14 @@ static int denali_setup_data_interface(struct mtd_info > *mtd, int chipnr, > tmp |= FIELD_PREP(RE_2_RE__VALUE, re_2_re); > iowrite32(tmp, denali->reg + RE_2_RE); > > - /* tWHR -> WE_2_RE */ > - we_2_re = DIV_ROUND_UP(timings->tWHR_min, t_clk); > + /* > + * tCCS, tWHR -> WE_2_RE > + * > + * With WE_2_RE properly set, the Denali controller automatically takes > + * care of the delay; the driver need not set NAND_WAIT_TCCS. > + */ > + we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min), > +t_clk); > we_2_re = min_t(int, we_2_re, TWHR2_AND_WE_2_RE__WE_2_RE); > > tmp = ioread32(denali->reg + TWHR2_AND_WE_2_RE);
Re: [PATCH -next v2] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)
On 2017/09/27 6:15, Boris Brezillon wrote:
> On Tue, 26 Sep 2017 18:18:04 +0900
> KOBAYASHI Yoshitake wrote:
>
>> On 2017/09/21 16:28, Boris Brezillon wrote:
>>> On Thu, 21 Sep 2017 14:32:02 +0900
>>> KOBAYASHI Yoshitake wrote:
>>>
This patch enables support for Toshiba BENAND.
The current implementation does not support vondor specific command
>>>
>>>^ vendor
>>>
TOSHIBA_NAND_CMD_ECC_STATUS. I would like to add the command, when
the exec_op() [1] infrastructure is implemented.
>>>
>>> It's not a good idea to reference a branch that is likely to disappear
>>> in a commit message. Just say that you can't properly support the
>>> TOSHIBA_NAND_CMD_ECC_STATUS operation right and that it might be
>>> addressed in the future.
>>
>> Thanks. I'll change the comment.
>>
+ */
+ if (status & NAND_STATUS_FAIL) {
+ /* uncorrectable */
+ mtd->ecc_stats.failed++;
+ } else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
+ /* correctable */
+ max_bitflips = mtd->bitflip_threshold;
+ mtd->ecc_stats.corrected += max_bitflips;
+ }
>>>
>>> Is this working correctly when you read more than one ECC chunk? The
>>> ECC step size is 512 bytes and the page is bigger than that, which means
>>> you have more than one ECC chunk per page. What happens to the
>>> NAND_STATUS_FAIL flag if the first chunk is uncorrectable but
>>> following ones are correctable (or do not contain bitflips at all)?
>>
>> As you mentioned, the ECC step size is 512 byte. But when 0x70 command is
>> used
>> a simplified ECC status per page is generated.
>
> I'm fine with that as long as uncorrectable errors are detected
> correctly and TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED is set as soon as
> one of the ECC chunk exposes too many bitflips.
>
>> In case the first chunk is uncorrectable but the following ones are
>> correctable,
>> the 0x70 command can only check the status of the uncorrectable one.
>
> Sounds good.
>
>> Each ECC chunk status can be checked by using the 0x7A command.
>>
@@ -39,9 +105,43 @@ static void toshiba_nand_decode_id(struct nand_chip
*chip)
static int toshiba_nand_init(struct nand_chip *chip)
{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
if (nand_is_slc(chip))
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
+ if (nand_is_slc(chip) && (chip->id.data[4] & 0x80)) {
+ /* BENAND */
+
+ /*
+ * We can't disable the internal ECC engine, the user
+ * has to use on-die ECC, there is no alternative.
+ */
+ if (chip->ecc.mode != NAND_ECC_ON_DIE) {
+ pr_err("On-die ECC should be selected.\n");
+ return -EINVAL;
+ }
>>>
>>> According to your previous explanation that's not exactly true. Since
>>> ECC bytes are stored in a separate area, the user can decide to use
>>> another mode without trouble. Just skip the BENAND initialization when
>>> mode != NAND_ECC_ON_DIE and we should be good, or am I missing something?
>>
>> I am asking to product department to confirm it.
>
> I'm almost sure this is the case ;-).
According to the command sequence written in BENAND's datasheet, the status
of the internal ECC must be checked after reading. To do that, ecc.mode has been
set to NAND_ECC_ON_DIE and the status of the internal ECC is checked through
the 0x70 or 0x7A command. That's the reason we are returning EINVAL here.
-- Yoshi
Re: [RFC PATCH 1/2] kbuild: Add a cache for generated variables
Hi Douglas, 2017-10-05 7:38 GMT+09:00 Doug Anderson : > Hi, > > On Tue, Oct 3, 2017 at 9:05 PM, Masahiro Yamada > wrote: >> Thanks for the patches. The idea is interesting. >> >> I am not a Chrome developer, but cc-option could be improved somehow. >> >> >> I examined two approaches to mitigate the pain. >> >> [1] Skip cc-option completely when we run non-build targets >> such as "make help", "make clean", etc. >> >> [2] Cache the result of cc-option like this patch >> >> >> I wrote some patches for [1] >> https://patchwork.kernel.org/patch/9983825/ >> https://patchwork.kernel.org/patch/9983829/ >> https://patchwork.kernel.org/patch/9983833/ >> https://patchwork.kernel.org/patch/9983827/ >> >> Comments are welcome. :) > > OK, I'll take a look at them. I'm not massively familiar with the > kernel Makefiles, but hopefully I can figure some of it out. :-P > > >> [1] does not solve the slowness in the incremental build. >> Instead, it makes non-build targets faster >> from a clean source tree because cc-option is zero cost. >> >> >> [2] solves the issues in the incremental build. >> One funny thing is, it computes cc-option and store the cache file >> even for "make clean", where we know the cache file will be >> immediately deleted. >> >> >> We can apply [1] or [2], or maybe both of them >> because [1] and [2] are trying to solve the different issues. > > Yeah, I'm much more interested in [2] than [1]. I run incremental > builds almost constantly and hate the slowness. :( I can certainly > appreciate that the inefficient compiler setup in Chrome OS isn't your > problem and that an extra .5 seconds for an incremental build for most > people isn't that huge, though. ...but I'l probably move forward with > [2] since it still helps me a lot and still should help others. > Solving [1] seems worthwhile too, though... I agree. [2] is more helpful because developers spend most of time for the incremental build. [1] can improve it even more, but it just addresses some minor issues. > >> The cache approach seemed clever, but I do not like the implementation. >> The code is even more unreadable with lots of escape sequence. >> >> >> Here is my suggestion for simpler implementation (including bike-shed) >> >> >> Implement a new function "shell-cache". It works like $(shell ...) >> >> The difference is >> $(call shell-cached,...) returns the cached result, or run the command >> if not cached. >> >> >> >> Also, add try-run-cached. This is a cached variant of try-run. >> >> >> I just played with it, and seems working. >> (I did not have spend much time for testing, more wider test is needed.) >> >> >> The code is like something like this: >> >> >> >> make-cache := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/,$(if >> $(obj),$(obj)/)).cache.mk >> >> -include $(make-cache) > > Thanks, this is much better! :) > > >> define __run-and-store >> ifeq ($(origin $(1)),undefined) >> $$(eval $(1) := $$(shell $$2)) >> $$(shell echo '$(1) := $$($(1))' >> $(make-cache)) >> endif >> endef > > I like your idea. Essentially you're saying that we can just defer > the shell command, which was the really essential part that needed to > be deferred. Nice! It seems much nicer / cleaner. Still a tiny bit > of voodoo, but with all of your improvements the voodoo is at least > contained to a very small part of the file. > > OK, things seem pretty nice with this and I'll submit out a new patch. > I'm a bit conflicted about whether I should put myself as authorship > or you, since mostly the patch is your code now. ;-) For now I'll > leave my authorship but feel free to claim it and change me to just > "Suggested-by". :-) No worry. Without your patches, I would have never come up with this. The code improvement happened in general review process. > NOTE: one thing I noticed about your example code is that you weren't > always consistent about $(1) vs. $1. I've changed things to be > consistent at the expense of extra parenthesis. If you hate it, let > me know. I accept your choice. Keeping the consistent coding style is good. If we decide to use $1 instead of $(1), we should convert all instances tree-wide for consistency. >> >> __set-and-store takes two arguments, >> but here, it is called with one argument __cached_$(1) >> >> Probably, $$(try-run, ...) will be passed as $2, >> but I do not know why this works. > > Whew! It's not just me that's confused by all this... ;-) It looks > like you continued to use this in your suggestion, so I guess you > thought it was useful, at least... Yeah, it's a bit of magic. The > goal was to have one less set of evaluating and passing going around. > > So really '__set-and-store' takes _1_ argument. It outputs a string > where it uses this argument. Also part of the output string is a > reference to $(2). This will refer to the caller's second variable. > > === > > Maybe a "simpler" example? > > define example > $$(eval $(1) := $$(2)) > endef > > ex_usage = $(eva
Re: [PATCH -next v2] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)
On Thu, 5 Oct 2017 16:24:08 +0900
KOBAYASHI Yoshitake wrote:
> On 2017/09/27 6:15, Boris Brezillon wrote:
> > On Tue, 26 Sep 2017 18:18:04 +0900
> > KOBAYASHI Yoshitake wrote:
> >
> >> On 2017/09/21 16:28, Boris Brezillon wrote:
> >>> On Thu, 21 Sep 2017 14:32:02 +0900
> >>> KOBAYASHI Yoshitake wrote:
> >>>
> This patch enables support for Toshiba BENAND.
> The current implementation does not support vondor specific command
> >>>
> >>> ^ vendor
> >>>
> TOSHIBA_NAND_CMD_ECC_STATUS. I would like to add the command, when
> the exec_op() [1] infrastructure is implemented.
> >>>
> >>> It's not a good idea to reference a branch that is likely to disappear
> >>> in a commit message. Just say that you can't properly support the
> >>> TOSHIBA_NAND_CMD_ECC_STATUS operation right and that it might be
> >>> addressed in the future.
> >>
> >> Thanks. I'll change the comment.
> >>
> + */
> +if (status & NAND_STATUS_FAIL) {
> +/* uncorrectable */
> +mtd->ecc_stats.failed++;
> +} else if (status & TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED) {
> +/* correctable */
> +max_bitflips = mtd->bitflip_threshold;
> +mtd->ecc_stats.corrected += max_bitflips;
> +}
> >>>
> >>> Is this working correctly when you read more than one ECC chunk? The
> >>> ECC step size is 512 bytes and the page is bigger than that, which means
> >>> you have more than one ECC chunk per page. What happens to the
> >>> NAND_STATUS_FAIL flag if the first chunk is uncorrectable but
> >>> following ones are correctable (or do not contain bitflips at all)?
> >>
> >> As you mentioned, the ECC step size is 512 byte. But when 0x70 command is
> >> used
> >> a simplified ECC status per page is generated.
> >
> > I'm fine with that as long as uncorrectable errors are detected
> > correctly and TOSHIBA_NAND_STATUS_REWRITE_RECOMMENDED is set as soon as
> > one of the ECC chunk exposes too many bitflips.
> >
> >> In case the first chunk is uncorrectable but the following ones are
> >> correctable,
> >> the 0x70 command can only check the status of the uncorrectable one.
> >
> > Sounds good.
> >
> >> Each ECC chunk status can be checked by using the 0x7A command.
> >>
> @@ -39,9 +105,43 @@ static void toshiba_nand_decode_id(struct nand_chip
> *chip)
>
> static int toshiba_nand_init(struct nand_chip *chip)
> {
> +struct mtd_info *mtd = nand_to_mtd(chip);
> +
> if (nand_is_slc(chip))
> chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
>
> +if (nand_is_slc(chip) && (chip->id.data[4] & 0x80)) {
> +/* BENAND */
> +
> +/*
> + * We can't disable the internal ECC engine, the user
> + * has to use on-die ECC, there is no alternative.
> + */
> +if (chip->ecc.mode != NAND_ECC_ON_DIE) {
> +pr_err("On-die ECC should be selected.\n");
> +return -EINVAL;
> +}
> >>>
> >>> According to your previous explanation that's not exactly true. Since
> >>> ECC bytes are stored in a separate area, the user can decide to use
> >>> another mode without trouble. Just skip the BENAND initialization when
> >>> mode != NAND_ECC_ON_DIE and we should be good, or am I missing something?
> >>>
> >>
> >> I am asking to product department to confirm it.
> >
> > I'm almost sure this is the case ;-).
>
> According to the command sequence written in BENAND's datasheet, the status
> of the internal ECC must be checked after reading. To do that, ecc.mode has
> been
> set to NAND_ECC_ON_DIE and the status of the internal ECC is checked through
> the 0x70 or 0x7A command. That's the reason we are returning EINVAL here.
But the status will anyway be retrieved, and what's the point of
checking the ECC flags if the user wants to use its own ECC engine? I
mean, since you have the whole OOB area exposed why would you prevent
existing setup from working (by existing setup I mean those that already
have a BENAND but haven't modified their driver to accept ON_DIE_ECC).
Maybe I'm missing something, but AFAICT it's safe to allow users to
completely ignore the on-die ECC engine and use their own, even if
that means duplicating the work since on-die ECC cannot be disabled on
BENAND devices.
[PATCH] INSTALL: Update dependency list and configure with libxtables support
Add configure with lixtables in INSTALL and required dependencies for the same Signed-off-by: Harsha Sharma --- INSTALL | 11 +++ 1 file changed, 11 insertions(+) diff --git a/INSTALL b/INSTALL index 3e9a6ad..04981f1 100644 --- a/INSTALL +++ b/INSTALL @@ -18,6 +18,12 @@ Installation instructions for nftables - libreadline + - pkg-config + + - libtool + + - optional: libxtables: required for libxtables support + - optional: docbook2x: required for building man-page - optional: docbook-utils: required for building PDF man-page @@ -51,6 +57,11 @@ Installation instructions for nftables having no other use for libgmp. Note: This decreases the debugging verbosity in some files. + --with-xtables + + For libxtables support which allow input of tables with -f + option in nft. + Suggested configuration options: --prefix=/ --datarootdir=/usr/share Run "make" to compile nftables, "make install" to install it in the -- 2.11.0
Re: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface
On Wed, Oct 04, 2017 at 05:48:39PM -0500, Mario Limonciello wrote:
> +static long dell_smbios_wmi_ioctl(struct file *filp, unsigned int cmd,
> + unsigned long arg)
> +{
> + void __user *p = (void __user *) arg;
> + struct wmi_smbios_ioctl *input;
> + struct wmi_smbios_priv *priv;
> + struct wmi_device *wdev;
> + size_t ioctl_size;
> + int ret = 0;
> +
> + switch (cmd) {
> + /* we only operate on first instance */
> + case DELL_WMI_SMBIOS_CMD:
> + wdev = get_first_wmi_device();
> + if (!wdev) {
> + pr_err("No WMI devices bound\n");
dev_err(), you are a driver, never use "raw" pr_ calls.
> + return -ENODEV;
> + }
> + ioctl_size = sizeof(struct wmi_smbios_ioctl);
> + priv = dev_get_drvdata(&wdev->dev);
> + input = kmalloc(ioctl_size, GFP_KERNEL);
> + if (!input)
> + return -ENOMEM;
> + mutex_lock(&wmi_mutex);
> + if (!access_ok(VERIFY_READ, p, ioctl_size)) {
Hm, any time I see an access_ok() call, I get scared. You should almost
never need to make that call if you are using the correct kernel apis.
> + pr_err("Unsafe userspace pointer passed\n");
dev_err().
> + return -EFAULT;
Memory leak!
> + }
> + if (copy_from_user(input, p, ioctl_size)) {
> + ret = -EFAULT;
So, why did you call access_ok() followed by copy_from_user()?
copy_from/to() handle all of that for you automatically.
> + goto fail_smbios_cmd;
> + }
> + if (input->length != priv->buffer_size) {
> + pr_err("Got buffer size %d expected %d\n",
> + input->length, priv->buffer_size);
length is user provided, it can be whatever anyone sets it to. I don't
understand this error.
> + ret = -EINVAL;
> + goto fail_smbios_cmd;
> + }
> + if (!access_ok(VERIFY_WRITE, input->buf, priv->buffer_size)) {
> + pr_err("Unsafe userspace pointer passed\n");
Again, don't need this.
> + ret = -EFAULT;
> + goto fail_smbios_cmd;
> + }
> + if (copy_from_user(priv->buf, input->buf, priv->buffer_size)) {
Wait, input->buf is a user pointer? Ick, see my previous email about
your crazy api here being a mess. This should not be needed.
And as you "know" the buffer size already, why do you have userspace
specify it? What good is it?
> + ret = -EFAULT;
> + goto fail_smbios_cmd;
> + }
> + ret = run_smbios_call(wdev);
No other checking of the values in the structure? You just "trust"
userspace to get it all right? Hah!
> + if (ret != 0)
> + goto fail_smbios_cmd;
You didn't run this through checkpatch :(
> + if (copy_to_user(input->buf, priv->buf, priv->buffer_size))
> + ret = -EFAULT;
> +fail_smbios_cmd:
> + kfree(input);
> + mutex_unlock(&wmi_mutex);
> + break;
> + default:
> + pr_err("unsupported ioctl: %d.\n", cmd);
> + ret = -ENOIOCTLCMD;
> + }
> + return ret;
> +}
> +
> +static ssize_t buffer_size_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct wmi_smbios_priv *priv = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%d\n", priv->buffer_size);
> +}
> +static DEVICE_ATTR_RO(buffer_size);
> +
> +static struct attribute *smbios_wmi_attrs[] = {
> + &dev_attr_buffer_size.attr,
> + NULL
> +};
> +
> +static const struct attribute_group smbios_wmi_attribute_group = {
> + .attrs = smbios_wmi_attrs,
> +};
> +
> static int dell_smbios_wmi_probe(struct wmi_device *wdev)
> {
> struct wmi_smbios_priv *priv;
> @@ -127,6 +209,11 @@ static int dell_smbios_wmi_probe(struct wmi_device *wdev)
> if (!priv->buf)
> return -ENOMEM;
>
> + ret = sysfs_create_group(&wdev->dev.kobj,
> + &smbios_wmi_attribute_group);
Hint, if a driver ever makes a call to sysfs_*(), something is wrong, it
should never be needed.
Also, you just raced with userspace and lost :(
There is a way to fix all of this, in a simple way, I'll leave that as
an exercise for the reader, I've reviewed enough of this code for
today...
> +static const struct file_operations dell_smbios_wmi_fops = {
> + .owner = THIS_MODULE,
And who uses that field? Hint, no one is, which is another issue that I
forgot to review in your previous patch where you use this structure.
What is protecting this module from being unloaded while the ioctl call
is running? (hint, nothing...)
I need more coffee...
greg k-h
Re: RISC-V Linux Port v9
On Thu, Oct 5, 2017 at 2:21 AM, Palmer Dabbelt wrote: > On Tue, 26 Sep 2017 23:08:02 PDT (-0700), Arnd Bergmann wrote: >> On Tue, Sep 26, 2017 at 6:56 PM, Palmer Dabbelt wrote: >>> As per suggestions on our v8 patch set, I've split the core architecture >>> code >>> out from our drivers and would like to submit this patch set to be included >>> into linux-next, with the goal being to be merged in during the next merge >>> window. This patch set is based on 4.14-rc2, but if it's better to have it >>> based on something else then I can change it around. >> >> -rc2 is good, just don't rebase it any more. I'd suggest that at the point >> this >> becomes part of linux-next, you stop modifying the patches further and >> move to adding any additional changes as patches on top. > > Sounds good. I've gotten a kernel.org account now, so I've gone ahead and > signed a "for-linux-next" tag that contains this patch set. I'm going to > treat > what's here as an official pull request into linux-next and therefor I won't > be > rewriting history any more. If I understand everything correctly, once I'm in > linux-next I'm meant to update that tag with commits that are ready to go? > > Is there anything further I should do in order to get that tag merged into > linux-next? Please be aware that Stephen has announced that there won't be any linux-next trees until the end of the month, which will be the kernel summit in Prague. https://lkml.org/lkml/2017/9/29/13 It may be worth sending him a request to include your tree when he returns, I assume there will be a long email backlog and he might miss it otherwise. >>> * I cleaned up the defconfigs -- there's actually now just one, and it's >>>empty. For now I think we're OK with what the kernel sets as defaults, >>> but >>>I anticipate we'll begin to expand this as people start to use the port >>>more. >> >> The kernel defaults are not really as sensible as one would hope. Maybe >> go through your previous defconfig once more and pick up the items that >> made sense. > > I was a bit surprised at the defaults: for example, I'd expect things like > CONFIG_PCI and CONFIG_NET to be enabled by default. I guess I just assumed > that since technically we have a working kernel without those that it was fine > to just stick with the defaults. Some of the defaults are really pretty random and are only like this for historic reasons. > Looking at our old defconfig, I'd pick > > CONFIG_PCI=y > CONFIG_NAMESPACES=y > CONFIG_NET=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_DEVTMPFS=y > CONFIG_EXT2_FS=y > CONFIG_TMPFS=y > > does that seem reasonable? Mostly yes, but please disable ext2 and use ext4 instead. Arnd
Re: [PATCH v4 4/5] clk: aspeed: Register gated clocks
On Tue, 2017-10-03 at 17:25 +1030, Joel Stanley wrote:
> The majority of the clocks in the system are gates paired with a reset
> controller that holds the IP in reset.
>
> This borrows from clk_hw_register_gate, but registers two 'gates', one
> to control the clock enable register and the other to control the reset
> IP. This allows us to enforce the ordering:
>
> 1. Place IP in reset
> 2. Enable clock
> 3. Delay
> 4. Release reset
>
> There are some gates that do not have an associated reset; these are
> handled by using -1 as the index for the reset.
>
> Signed-off-by: Joel Stanley
>
> ---
> v4:
> - Drop useless 'disable clock' comment
> - Drop CLK_IS_BASIC flag
> - Fix 'there are a number of clocks...' comment
> - Pass device to clk registration functions
> - Check for errors when registering clk_hws
> v3:
> - Remove gates offset as gates are now at the start of the list
> ---
> drivers/clk/clk-aspeed.c | 130
> +++
> 1 file changed, 130 insertions(+)
>
> diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
> index adb295292189..a424b056e767 100644
> --- a/drivers/clk/clk-aspeed.c
> +++ b/drivers/clk/clk-aspeed.c
> @@ -228,6 +228,107 @@ static const struct aspeed_clk_soc_data ast2400_data = {
> .calc_pll = aspeed_ast2400_calc_pll,
> };
>
> +static int aspeed_clk_enable(struct clk_hw *hw)
> +{
> + struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
> + unsigned long flags;
> + u32 clk = BIT(gate->clock_idx);
> + u32 rst = BIT(gate->reset_idx);
> +
> + spin_lock_irqsave(gate->lock, flags);
> +
> + if (gate->reset_idx >= 0) {
> + /* Put IP in reset */
> + regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, rst);
> +
> + /* Delay 100us */
> + udelay(100);
> + }
> +
> + /* Enable clock */
> + regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, 0);
> +
> + if (gate->reset_idx >= 0) {
> + /* Delay 10ms */
> + /* TODO: can we sleep here? */
> + msleep(10);
> +
> + /* Take IP out of reset */
> + regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, 0);
> + }
> +
> + spin_unlock_irqrestore(gate->lock, flags);
> +
> + return 0;
> +}
> +
> +static void aspeed_clk_disable(struct clk_hw *hw)
> +{
> + struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
> + unsigned long flags;
> + u32 clk = BIT(gate->clock_idx);
> +
> + spin_lock_irqsave(gate->lock, flags);
> +
> + regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, clk);
> +
> + spin_unlock_irqrestore(gate->lock, flags);
> +}
> +
> +static int aspeed_clk_is_enabled(struct clk_hw *hw)
> +{
> + struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
> + u32 clk = BIT(gate->clock_idx);
> + u32 reg;
> +
> + regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, ®);
> +
> + return (reg & clk) ? 0 : 1;
Kill a branch, save the internet: return !(reg & clk);
But regardless, the patch seems sensible to me modulo the power domain
discussion. However as it's more clk-y than Aspeed-y I don't feel entirely
qualified to provide a r-b, so instead:
Acked-by: Andrew Jeffery
> +}
> +
> +static const struct clk_ops aspeed_clk_gate_ops = {
> + .enable = aspeed_clk_enable,
> + .disable = aspeed_clk_disable,
> + .is_enabled = aspeed_clk_is_enabled,
> +};
> +
> +static struct clk_hw *aspeed_clk_hw_register_gate(struct device *dev,
> + const char *name, const char *parent_name, unsigned long flags,
> + struct regmap *map, u8 clock_idx, u8 reset_idx,
> + u8 clk_gate_flags, spinlock_t *lock)
> +{
> + struct aspeed_clk_gate *gate;
> + struct clk_init_data init;
> + struct clk_hw *hw;
> + int ret;
> +
> + gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> + if (!gate)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &aspeed_clk_gate_ops;
> + init.flags = flags;
> + init.parent_names = parent_name ? &parent_name : NULL;
> + init.num_parents = parent_name ? 1 : 0;
> +
> + gate->map = map;
> + gate->clock_idx = clock_idx;
> + gate->reset_idx = reset_idx;
> + gate->flags = clk_gate_flags;
> + gate->lock = lock;
> + gate->hw.init = &init;
> +
> + hw = &gate->hw;
> + ret = clk_hw_register(dev, hw);
> + if (ret) {
> + kfree(gate);
> + hw = ERR_PTR(ret);
> + }
> +
> + return hw;
> +}
> +
> static int aspeed_clk_probe(struct platform_device *pdev)
> {
> const struct aspeed_clk_soc_data *soc_data;
> @@ -235,6 +336,7 @@ static int aspeed_clk_probe(struct platform_device *pdev)
> struct regmap *map;
> struct clk_hw *hw;
> u32 val, rate;
> + int i;
>
> map = syscon_node_to_regmap(dev->of_node);
> if (IS_ERR(map)) {
> @@ -323,6 +425,34 @@ static int aspeed_clk_probe(struct platform_devi
Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()
On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote:
> The alt_max_short() macro in asm/alternative.h does not work as
> intended, leading to nasty bugs. E.g. alt_max_short("1", "3")
> evaluates to 3, but alt_max_short("3", "1") evaluates to 1 -- not
> exactly the maximum of 1 and 3.
>
> In fact, I had to learn it the hard way by crashing my kernel in not
> so funny ways by attempting to make use of the ALTENATIVE_2 macro
> with alternatives where the first one was larger than the second
> one.
>
> According to [1] and commit dbe4058a6a44 ("x86/alternatives: Fix
> ALTERNATIVE_2 padding generation properly") the right handed side
> should read "-(-(a < b))" not "-(-(a - b))". Fix that, to make the
> macro work as intended.
>
> While at it, fix up the comment regarding the additional "-", too.
> It's not about gas' usage of s32 but brain dead logic of having a
> "true" value of -1 for the < operator ... *sigh*
>
> Btw., the one in asm/alternative-asm.h is correct. And, apparently,
> all current users of ALTERNATIVE_2() pass same sized alternatives,
> avoiding to hit the bug.
>
> [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
>
> Fixes: dbe4058a6a44 ("x86/alternatives: Fix ALTERNATIVE_2 padding generation
> properly")
> Signed-off-by: Mathias Krause
> Cc: Borislav Petkov
> ---
> arch/x86/include/asm/alternative.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index c096624137ae..7c553f48f163 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -106,9 +106,9 @@ static inline int alternatives_text_reserved(void *start,
> void *end)
> * max without conditionals. Idea adapted from:
^
You did read this part, right?
AFAIR, gas can't stomach conditionals but I don't remember the details
anymore. Could be that -1 representation of "true". Let me add Micha to
CC.
Anyway, how can I reproduce your observation? Code snippet and compiler
pls.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] net: tulip: de2104x: Convert timers to use
On 2017-10-05 at 02:50:48 +0200, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: "David S. Miller" > Cc: "yuval.sh...@oracle.com" > Cc: Tobias Klauser > Cc: Jarod Wilson > Cc: Philippe Reynes > Cc: net...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: Thomas Gleixner > Signed-off-by: Kees Cook Reviewed-by: Tobias Klauser
Re: [PATCH] net: dl2k: Convert timers to use timer_setup()
On 2017-10-05 at 02:51:50 +0200, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: "David S. Miller" > Cc: Jarod Wilson > Cc: Tobias Klauser > Cc: Philippe Reynes > Cc: net...@vger.kernel.org > Cc: Thomas Gleixner > Signed-off-by: Kees Cook Reviewed-by: Tobias Klauser
[PATCH] ARM: dts: omap3: Replace deprecated mcp prefix
The devicetree prefix mcp is deprecated in favour of microchip. Thus
this replaces mcp with microchip for the mcp23017 gpio expander chip.
Signed-off-by: Lars Poeschel
---
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5e4850..343a36d8031d 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -257,7 +257,7 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c3_pins>;
gpiom1: gpio@20 {
- compatible = "mcp,mcp23017";
+ compatible = "microchip,mcp23017";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
--
2.14.2
Re: [PATCH v3 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants.
Hello Kalyan, On Thu, 28 Sep 2017 13:57:56 +1300 Kalyan Kinthada wrote: > When the arbitration between NOR and NAND flash is enabled > the field bit[21] in the Data Flash Control Register > needs to be set to 1 according to guidleine GL-5830741 mentioned Typo: guideline ^ > in Marvell Errata document MV-S501377-00, Rev. D. Thanks for that, I checked it. > > This commit sets the FORCE_CSX bit to 1 for all > ARMADA370 variants as the arbitration is always enabled by default. > This change does not apply for pxa3xx variants because the FORCE_CSX > bit does not exist/reserved on the NFCv1. Sorry to bother you again but I am reworking the pxa3xx_nand driver and so I would like to deeply understand why this is needed because I will have to integrate it in my work too. So please tell me what is your setup, do you really use NAND/NOR arbitration? Do you have not-Don't Care CS NAND chips? I have some doubts because even if the spec precises in the NAND controller chapter that arbitration is always enabled by default, the bit 27 (NfArbiterEn) in the SoC Device Multiplex Register at offset 0x00018208 is actually at 0 by default (disabled). Did you enable this bit manually ? I checked with devmem on my setup and this bit was unset. Thank you for your time, Miquèl > > The NDCR_ND_MODE conflicts with the new NDCR_FORCE_CSX but is unused > so remove it along with NDCR_NAND_MODE. > > Signed-off-by: Kalyan Kinthada > --- > drivers/mtd/nand/pxa3xx_nand.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c > b/drivers/mtd/nand/pxa3xx_nand.c index 85cff68643e0..a6a7a5af7bed > 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c > +++ b/drivers/mtd/nand/pxa3xx_nand.c > @@ -67,8 +67,7 @@ > #define NDCR_DWIDTH_M(0x1 << 26) > #define NDCR_PAGE_SZ (0x1 << 24) > #define NDCR_NCSX(0x1 << 23) > -#define NDCR_ND_MODE (0x3 << 21) > -#define NDCR_NAND_MODE (0x0) > +#define NDCR_FORCE_CSX (0x1 << 21) > #define NDCR_CLR_PG_CNT (0x1 << 20) > #define NFCV1_NDCR_ARB_CNTL (0x1 << 19) > #define NFCV2_NDCR_STOP_ON_UNCOR (0x1 << 19) > @@ -1464,6 +1463,9 @@ static int pxa3xx_nand_config_ident(struct > pxa3xx_nand_info *info) info->chunk_size = PAGE_CHUNK_SIZE; > info->reg_ndcr = 0x0; /* enable all interrupts */ > info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : > 0; > + /* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: > GL-5830741 */ > + if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) > + info->reg_ndcr |= NDCR_FORCE_CSX; > info->reg_ndcr |= NDCR_RD_ID_CNT(READ_ID_BYTES); > info->reg_ndcr |= NDCR_SPARE_EN; > > @@ -1498,6 +1500,9 @@ static void pxa3xx_nand_detect_config(struct > pxa3xx_nand_info *info) info->reg_ndcr = ndcr & > ~(NDCR_INT_MASK | NDCR_ND_ARB_EN | > NFCV1_NDCR_ARB_CNTL); info->reg_ndcr |= (pdata->enable_arbiter) ? > NDCR_ND_ARB_EN : 0; > + /* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: > GL-5830741 */ > + if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) > + info->reg_ndcr |= NDCR_FORCE_CSX; > info->ndtr0cs0 = nand_readl(info, NDTR0CS0); > info->ndtr1cs0 = nand_readl(info, NDTR1CS0); > } -- Miquel Raynal, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH] test: shell: execute shell/run-tests.sh from any directory
Update shell/run-tests.sh to refer /src/nft with a relative path
Signed-off-by: Harsha Sharma
---
tests/shell/run-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/shell/run-tests.sh b/tests/shell/run-tests.sh
index 4eba0a8..dbddd8d 100755
--- a/tests/shell/run-tests.sh
+++ b/tests/shell/run-tests.sh
@@ -3,7 +3,7 @@
# Configuration
TESTDIR="./"
RETURNCODE_SEPARATOR="_"
-SRC_NFT="../../src/nft"
+SRC_NFT="$(dirname $0)/../../src/nft"
msg_error() {
echo "E: $1 ..." >&2
--
2.11.0
Re: [PATCH v4 5/5] clk: aspeed: Add reset controller
On Tue, 2017-10-03 at 17:25 +1030, Joel Stanley wrote:
> There are some resets that are not associated with gates. These are
> represented by a reset controller.
>
> Signed-off-by: Joel Stanley
With respect to the Aspeed hardware reset bits:
Reviewed-by: Andrew Jeffery
>
> ---
> v3:
> - Add named initalisers for the reset defines
> - Add define for ADC
> ---
> drivers/clk/clk-aspeed.c | 82
> +++-
> include/dt-bindings/clock/aspeed-clock.h | 10
> 2 files changed, 91 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
> index a424b056e767..de491dc7f955 100644
> --- a/drivers/clk/clk-aspeed.c
> +++ b/drivers/clk/clk-aspeed.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -292,6 +293,68 @@ static const struct clk_ops aspeed_clk_gate_ops = {
> .is_enabled = aspeed_clk_is_enabled,
> };
>
> +/**
> + * struct aspeed_reset - Aspeed reset controller
> + * @map: regmap to access the containing system controller
> + * @rcdev: reset controller device
> + */
> +struct aspeed_reset {
> + struct regmap *map;
> + struct reset_controller_dev rcdev;
> +};
> +
> +#define to_aspeed_reset(p) container_of((p), struct aspeed_reset, rcdev)
> +
> +static const u8 aspeed_resets[] = {
> + [ASPEED_RESET_XDMA] = 25,
> + [ASPEED_RESET_MCTP] = 24,
> + [ASPEED_RESET_ADC] = 23,
> + [ASPEED_RESET_JTAG_MASTER] = 22,
> + [ASPEED_RESET_MIC] = 18,
> + [ASPEED_RESET_PWM] = 9,
> + [ASPEED_RESET_PCIVGA] = 8,
> + [ASPEED_RESET_I2C] = 2,
> + [ASPEED_RESET_AHB] = 1,
> +};
> +
> +static int aspeed_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct aspeed_reset *ar = to_aspeed_reset(rcdev);
> + u32 rst = BIT(aspeed_resets[id]);
> +
> + return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, 0);
> +}
> +
> +static int aspeed_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct aspeed_reset *ar = to_aspeed_reset(rcdev);
> + u32 rst = BIT(aspeed_resets[id]);
> +
> + return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, rst);
> +}
> +
> +static int aspeed_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct aspeed_reset *ar = to_aspeed_reset(rcdev);
> + u32 val, rst = BIT(aspeed_resets[id]);
> + int ret;
> +
> + ret = regmap_read(ar->map, ASPEED_RESET_CTRL, &val);
> + if (ret)
> + return ret;
> +
> + return !!(val & rst);
> +}
> +
> +static const struct reset_control_ops aspeed_reset_ops = {
> + .assert = aspeed_reset_assert,
> + .deassert = aspeed_reset_deassert,
> + .status = aspeed_reset_status,
> +};
> +
> static struct clk_hw *aspeed_clk_hw_register_gate(struct device *dev,
> const char *name, const char *parent_name, unsigned long flags,
> struct regmap *map, u8 clock_idx, u8 reset_idx,
> @@ -333,10 +396,11 @@ static int aspeed_clk_probe(struct platform_device
> *pdev)
> {
> const struct aspeed_clk_soc_data *soc_data;
> struct device *dev = &pdev->dev;
> + struct aspeed_reset *ar;
> struct regmap *map;
> struct clk_hw *hw;
> u32 val, rate;
> - int i;
> + int i, ret;
>
> map = syscon_node_to_regmap(dev->of_node);
> if (IS_ERR(map)) {
> @@ -344,6 +408,22 @@ static int aspeed_clk_probe(struct platform_device *pdev)
> return PTR_ERR(map);
> }
>
> + ar = devm_kzalloc(dev, sizeof(*ar), GFP_KERNEL);
> + if (!ar)
> + return -ENOMEM;
> +
> + ar->map = map;
> + ar->rcdev.owner = THIS_MODULE;
> + ar->rcdev.nr_resets = ARRAY_SIZE(aspeed_resets);
> + ar->rcdev.ops = &aspeed_reset_ops;
> + ar->rcdev.of_node = dev->of_node;
> +
> + ret = devm_reset_controller_register(dev, &ar->rcdev);
> + if (ret) {
> + dev_err(dev, "could not register reset controller\n");
> + return ret;
> + }
> +
> /* SoC generations share common layouts but have different divisors */
> soc_data = of_device_get_match_data(dev);
> if (!soc_data) {
> diff --git a/include/dt-bindings/clock/aspeed-clock.h
> b/include/dt-bindings/clock/aspeed-clock.h
> index 4a99421d77c8..8e19646d8025 100644
> --- a/include/dt-bindings/clock/aspeed-clock.h
> +++ b/include/dt-bindings/clock/aspeed-clock.h
> @@ -39,4 +39,14 @@
>
> #define ASPEED_NUM_CLKS 35
>
> +#define ASPEED_RESET_XDMA0
> +#define ASPEED_RESET_MCTP1
> +#define ASPEED_RESET_ADC 2
> +#define ASPEED_RESET_JTAG_MASTER 3
> +#define ASPEED_RESET_MIC 4
> +#define ASPEED_RESET_PWM 5
> +#define ASPEED_RESET_PCIVGA 6
>
Re: [PATCH] arm: dts: gr-peach: Reduce extal_clk resolution
Hi Geert
On Wed, Oct 04, 2017 at 05:54:46PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, Oct 4, 2017 at 5:40 PM, Jacopo Mondi
> wrote:
> > The system clock described by extal_clk is reported to have a frequency
> > of 13.333 Mhz and is correctly described by gr-peach device tree.
> >
> > However, when enabling a RIIC device the following error is reported by
> > drivers/i2c/busses/i2c-riic.c
> >
> > "invalid parent clk (2500). Must be 33325000Hz"
> >
> > As RIIC devices have a clock source obtained by dividing by 12 the
> > system clock, the resulting value is not accepted by the driver
> > (which clearly states not to support any frequency except the reported
> > 33325000Hz one).
> >
> > Hence, reduce the system clock accuracy to a value which makes
> > frequencies obtained through division accepted by RIIC driver.
> >
> > Please note that other r7s72100 boards, such as Genmai, report the same
> > "reduced accuracy" frequency, even if their external clock sources are
> > effectively 13.333Mhz as gr-peach one.
> >
> > Signed-off-by: Jacopo Mondi
>
> There's no need to do this, Chris already proposed a fix, cfr.
> "[PATCH v2] i2c: riic: remove fixed clock restriction"
> (https://www.spinics.net/lists/linux-renesas-soc/msg18573.html).
Oh that's even better!
Do you see any value in augmenting the frequency resolution in Genmai
DTS then?
Thanks
j
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH] powerpc: Default to enabling STRICT_KERNEL_RWX
Le 05/10/2017 à 05:45, Kees Cook a écrit : When available, CONFIG_KERNEL_RWX should be default-enabled. On PPC32, this option implies deactivating BATs and/or LTLB mapping of the linear kernel address space, hence a significant performance degradation. So at least on PPC32, it should remain unselected by default. Christophe Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linuxppc-...@lists.ozlabs.org Signed-off-by: Kees Cook --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 809c468edab1..9a549bbfc278 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -178,6 +178,7 @@ config PPC select HAVE_ARCH_TRACEHOOK select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !RELOCATABLE && !HIBERNATION) select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX + select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT select HAVE_CBPF_JITif !PPC64 select HAVE_CONTEXT_TRACKINGif PPC64 select HAVE_DEBUG_KMEMLEAK
[PATCH] dt-bindings: pinctrl: Move mcp23s08 from gpio
The mcp23s08 driver was moved from gpio to pinctrl. This moves it's
devicetree binding doc as well. So driver and binding doc are in sync
again.
Signed-off-by: Lars Poeschel
---
.../bindings/{gpio/gpio-mcp23s08.txt => pinctrl/pinctrl-mcp23s08.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{gpio/gpio-mcp23s08.txt =>
pinctrl/pinctrl-mcp23s08.txt} (100%)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
similarity index 100%
rename from Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
rename to Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
--
2.14.2
Re: [PATCH v2 0/2] kbuild: Cache exploratory calls to the compiler
* Douglas Anderson wrote: > This two-patch series attempts to speed incremental builds of the > kernel up by a bit. How much of a speedup you get depends a lot on > your environment, specifically the speed of your workstation and how > fast it takes to invoke the compiler. > > In the Chrome OS build environment you get a really big win. For an > incremental build (via emerge) I measured a speedup from ~1 minute to > ~35 seconds. Very impressive! > [...] ...but Chrome OS calls the compiler through a number of wrapper > scripts > and also calls the kernel make at least twice for an emerge (during compile > stage and install stage), so it's a bit of a worst case. I don't think that's a worst case: incremental builds are very commonly used during kernel development and kernel testing. (I'd even argue that the performnace of incremental builds is one of the most important features of a build system.) That it's called twice in the Chrome OS build system does not change the proportion of the speedup. > Perhaps a more realistic measure of the speedup others might see is > running "time make help > /dev/null" outside of the Chrome OS build > environment on my system. When I do this I see that it took more than > 1.0 seconds before and less than 0.2 seconds after. So presumably > this has the ability to shave ~0.8 seconds off an incremental build > for most folks out there. While 0.8 seconds savings isn't huge, it > does make incremental builds feel a lot snappier. This is a huge deal! FWIIW I have tested your patches and they work fine here. Here's the before/after performance testing of various styles of build times of the scheduler. First the true worst case is a full rebuild: [ before ] triton:~/tip> perf stat --null --repeat 3 --pre "make clean 2>/dev/null 2>&1" make kernel/sched/ >/dev/null Performance counter stats for 'make kernel/sched/' (3 runs): 4.693974827 seconds time elapsed ( +- 0.05% ) [ after ] triton:~/tip> perf stat --null --repeat 3 --pre "make clean 2>/dev/null 2>&1" make kernel/sched/ >/dev/null Performance counter stats for 'make kernel/sched/' (3 runs): 4.391769610 seconds time elapsed ( +- 0.21% ) Still a ~6% speedup which is nice to have. Then the best case, a fully cached rebuild of a specific subsystem - which I personally do all the time when I don't remember whether I already built the kernel or not: [ before ] triton:~/tip> taskset 1 perf stat --null --pre "sync" --repeat 10 make kernel/sched/ >/dev/null Performance counter stats for 'make kernel/sched/' (10 runs): 0.439517157 seconds time elapsed ( +- 0.14% ) [ after ] triton:~/tip> taskset 1 perf stat --null --pre "sync" --repeat 10 make kernel/sched/ >/dev/null Performance counter stats for 'make kernel/sched/' (10 runs): 0.148483807 seconds time elapsed ( +- 0.57% ) A 300% speedup on my system! So I wholeheartedly endorse the whole concept of caching build environment invariants: Tested-by: Ingo Molnar Thanks, Ingo
Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers
* Masami Hiramatsu wrote: > On Wed, 4 Oct 2017 12:41:01 +0200 > Ingo Molnar wrote: > > > > > * Masami Hiramatsu wrote: > > > > > Hmm, actually we can not disable jprobe, that has no separate Kconfig. > > > So we need to introduce new kconfig for that. > > > > > > And, there are several network protocols using jprobe to trace events. > > > (e.g. NET_DCCPPROBE and NET_TCPPROBE) > > > I think they need to migrate to trace-event at first. > > > > > > So, how about below idea? > > > > > > 1. Introduce CONFIG_JPROBE_API which only separate jprobe general parts > > > (no arch dependent code involves) and make it default n. > > > 2. Mark break_handler and jprobe APIs deprecated so that no new user > > > comes up. > > > 3. migrate in-kernel jprobe user to trace-event or ftrace. > > >(may take some time) > > > > So my suggestion would be to just return from register_jprobe() and don't > > register > > anything. > > with CONFIG_JPROBE_API=n, is that right? No, unconditionally off with a WARN_ON_ONCE() warning in the registry function and the deactivation of all in-kernel uses (such as self-tests). The point is to make people that _truly_ rely on it complain - not just make them silently turn on a Kconfig option ... > > Yes, there are usecases of jprobes in the kernel, but they all look > > pretty ancient and unused. > > Hmm, in that case, should we also remove those users? If we disable such way > those features are just useless. My hypothesis is that those features are not used (hence useless), but we should first test whether there's any reliance before we remove code. Thanks, Ingo
Re: [PATCH] mm, arch: remove empty_bad_page*
* Michal Hocko wrote: > From: Michal Hocko > > empty_bad_page and empty_bad_pte_table seems to be a relict from old > days which is not used by any code for a long time. I have tried to find > when exactly but this is not really all that straightforward due to many > code movements - traces disappear around 2.4 times. > > Anyway no code really references neither empty_bad_page nor > empty_bad_pte_table. We only allocate the storage which is not used by > anybody so remove them. > > Cc: Yoshinori Sato > Cc: Ralf Baechle > Cc: David Howells > Cc: Rich Felker > Cc: Jeff Dike > Cc: Richard Weinberger > Cc: Ingo Molnar > Cc: > Cc: > Cc: > Signed-off-by: Michal Hocko For the x86 bits: Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()
On 5 October 2017 at 09:38, Borislav Petkov wrote:
> On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote:
>> The alt_max_short() macro in asm/alternative.h does not work as
>> intended, leading to nasty bugs. E.g. alt_max_short("1", "3")
>> evaluates to 3, but alt_max_short("3", "1") evaluates to 1 -- not
>> exactly the maximum of 1 and 3.
>>
>> In fact, I had to learn it the hard way by crashing my kernel in not
>> so funny ways by attempting to make use of the ALTENATIVE_2 macro
>> with alternatives where the first one was larger than the second
>> one.
>>
>> According to [1] and commit dbe4058a6a44 ("x86/alternatives: Fix
>> ALTERNATIVE_2 padding generation properly") the right handed side
>> should read "-(-(a < b))" not "-(-(a - b))". Fix that, to make the
>> macro work as intended.
>>
>> While at it, fix up the comment regarding the additional "-", too.
>> It's not about gas' usage of s32 but brain dead logic of having a
>> "true" value of -1 for the < operator ... *sigh*
>>
>> Btw., the one in asm/alternative-asm.h is correct. And, apparently,
>> all current users of ALTERNATIVE_2() pass same sized alternatives,
>> avoiding to hit the bug.
>>
>> [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
>>
>> Fixes: dbe4058a6a44 ("x86/alternatives: Fix ALTERNATIVE_2 padding generation
>> properly")
>> Signed-off-by: Mathias Krause
>> Cc: Borislav Petkov
>> ---
>> arch/x86/include/asm/alternative.h |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/alternative.h
>> b/arch/x86/include/asm/alternative.h
>> index c096624137ae..7c553f48f163 100644
>> --- a/arch/x86/include/asm/alternative.h
>> +++ b/arch/x86/include/asm/alternative.h
>> @@ -106,9 +106,9 @@ static inline int alternatives_text_reserved(void
>> *start, void *end)
>> * max without conditionals. Idea adapted from:
> ^
>
> You did read this part, right?
Yes. But it's just wrong the way it is right now. It's a crap number
generator instead of being a "max without conditionals".
> AFAIR, gas can't stomach conditionals but I don't remember the details
> anymore.
Can't be as arch/x86/include/asm/alternative.h itself makes use of
them for the implementation of ALTERNATIVE[_2], see, e.g. __OLDINSTR()
and OLDINSTR_2().
> Could be that -1 representation of "true". Let me add Micha to
> CC.
>
> Anyway, how can I reproduce your observation? Code snippet and compiler
> pls.
Here you go:
$ cat alt_max.c
#ifdef VANILLA
# define alt_max_short(a, b) \
"((" a ") ^ (((" a ") ^ (" b ")) & -(-((" a ") - (" b ")"
#else
# define alt_max_short(a, b) \
"((" a ") ^ (((" a ") ^ (" b ")) & -(-((" a ") < (" b ")"
#endif
#define ams(a, b) \
"ams_" #a "_" #b " = " alt_max_short(#a, #b) "\n\t"
asm(ams(1, 3)
ams(3, 1)
ams(1, 6));
$ gcc -DVANILLA -c alt_max.c && nm alt_max.o
0003 a ams_1_3
0002 a ams_1_6
0001 a ams_3_1
$ gcc -c alt_max.c && nm alt_max.o
0003 a ams_1_3
0006 a ams_1_6
0003 a ams_3_1
Note not only how it gets the max(3,1) case wrong but generates even
more insane crap for max(1,6).
$ as --version | head -1
GNU assembler (GNU Binutils for Debian) 2.25
Cheers,
Mathias
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] isdn/gigaset: Convert timers to use timer_setup()
Hi Kees, On Wed, 2017-10-04 at 17:52 -0700, Kees Cook wrote: > Also uses kzmalloc to replace open-coded field assignments to NULL and zero. If I'm allowed to whine (chances that I'm allowed to do that are not so great as Dave tends to apply gigaset patches before I even have a chance to look at them properly!): I'd prefer it if that was done separately in a preceding patch. Would that bother you? Thanks, Paul Bolle
Linux 3.18.73
I'm announcing the release of the 3.18.73 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - arch/arm/xen/mm.c |1 arch/arm64/kernel/head.S |1 arch/powerpc/kvm/book3s_64_vio.c | 46 +- arch/powerpc/platforms/pseries/mobility.c |4 +- arch/x86/kernel/i387.c| 11 +++ arch/x86/kernel/xsave.c |4 +- arch/x86/kvm/vmx.c|5 +++ block/bsg-lib.c |1 drivers/crypto/talitos.c |4 +- drivers/pci/pci-sysfs.c | 11 +-- drivers/scsi/scsi_transport_iscsi.c |2 - drivers/video/fbdev/aty/atyfb_base.c |2 - drivers/xen/swiotlb-xen.c | 19 fs/btrfs/ioctl.c |4 ++ fs/cifs/cifsfs.c |2 - fs/cifs/connect.c |8 + fs/cifs/file.c|7 fs/cifs/smb2pdu.c | 17 +++ fs/read_write.c |4 +- include/linux/key.h |2 + include/xen/swiotlb-xen.h |5 +++ kernel/trace/trace.c | 12 +-- net/mac80211/offchannel.c |2 + net/wireless/nl80211.c|3 + security/keys/internal.h |2 - security/keys/key.c |2 + security/keys/keyctl.c|5 +++ security/keys/keyring.c | 37 security/keys/process_keys.c |8 +++-- 30 files changed, 172 insertions(+), 61 deletions(-) Andreas Gruenbacher (1): vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets Arnd Bergmann (1): fix xen_swiotlb_dma_mmap prototype Avraham Stern (1): mac80211: flush hw_roc_start work before cancelling the ROC Bo Yan (1): tracing: Erase irqsoff trace with empty write Christoph Hellwig (1): bsg-lib: don't free job in bsg_prepare_job Eric Biggers (4): KEYS: fix writing past end of user-supplied buffer in keyring_read() KEYS: prevent creating a different user's keyrings KEYS: prevent KEYCTL_READ on negative key x86/fpu: Don't let userspace set bogus xcomp_bv Greg Kroah-Hartman (1): Linux 3.18.73 Jim Mattson (1): kvm: nVMX: Don't allow L2 to access the hardware CR8 LEROY Christophe (1): crypto: talitos - fix sha224 Marc Zyngier (1): arm64: Make sure SPsel is always set Nicolai Stange (1): PCI: Fix race condition with driver_override Paul Mackerras (1): KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce() Shu Wang (2): cifs: release cifs root_cred after exit_cifs cifs: release auth_key.response for reconnect. Stefano Stabellini (1): swiotlb-xen: implement xen_swiotlb_dma_mmap callback Steve French (2): SMB: Validate negotiate (to protect against downgrade) even if signing off SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags Tahsin Erdogan (1): tracing: Fix trace_pipe behavior for instance traces Tyrel Datwyler (1): powerpc/pseries: Fix parent_dn reference leak in add_dt_node() Vladis Dronov (2): nl80211: check for the required netlink attributes presence video: fbdev: aty: do not leak uninitialized padding in clk to userspace Xin Long (1): scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly satoru takeuchi (1): btrfs: prevent to set invalid default subvolid signature.asc Description: PGP signature
Linux 4.4.90
I'm announcing the release of the 4.4.90 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/boot/dts/pxa27x.dtsi |1 arch/arm/boot/dts/pxa3xx.dtsi |1 arch/arm/mach-pxa/devices.c |4 + arch/arm/mach-pxa/pxa25x.c|2 arch/arm/mach-pxa/pxa27x.c|2 arch/arm/mach-pxa/pxa3xx.c|2 arch/arm/plat-pxa/include/plat/dma.h |2 arch/arm/xen/mm.c |1 arch/arm64/kernel/head.S |1 arch/arm64/mm/fault.c |2 arch/powerpc/kvm/book3s_64_vio.c | 46 - arch/powerpc/platforms/pseries/mobility.c |4 + arch/x86/kernel/fpu/regset.c | 11 + arch/x86/kernel/fpu/signal.c |4 + arch/x86/kvm/vmx.c| 65 ++ block/bsg-lib.c |1 drivers/crypto/talitos.c |7 +-- drivers/md/raid5.c| 13 -- drivers/misc/cxl/api.c|4 + drivers/misc/cxl/file.c |8 +++ drivers/pci/pci-sysfs.c | 11 - drivers/scsi/scsi_transport_iscsi.c |2 drivers/video/fbdev/aty/atyfb_base.c |2 drivers/xen/swiotlb-xen.c | 19 fs/btrfs/ioctl.c |6 ++ fs/btrfs/relocation.c |2 fs/cifs/connect.c |8 +++ fs/cifs/file.c|7 +++ fs/cifs/smb2pdu.c | 19 ++-- fs/gfs2/glock.c | 21 - fs/read_write.c |4 - include/linux/key.h |2 include/linux/platform_data/mmp_dma.h |1 include/xen/swiotlb-xen.h |5 ++ kernel/seccomp.c | 23 +++--- kernel/sysctl.c |2 kernel/time/timer.c |2 kernel/trace/trace.c | 12 - net/mac80211/offchannel.c |2 net/wireless/nl80211.c|3 + security/keys/internal.h |2 security/keys/key.c |2 security/keys/keyctl.c|5 ++ security/keys/keyring.c | 37 - security/keys/process_keys.c |8 ++- 46 files changed, 271 insertions(+), 119 deletions(-) Andreas Gruenbacher (2): vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets gfs2: Fix debugfs glocks dump Arnd Bergmann (1): fix xen_swiotlb_dma_mmap prototype Avraham Stern (1): mac80211: flush hw_roc_start work before cancelling the ROC Bo Yan (1): tracing: Erase irqsoff trace with empty write Christoph Hellwig (1): bsg-lib: don't free job in bsg_prepare_job Dennis Yang (1): md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list Eric Biggers (4): KEYS: fix writing past end of user-supplied buffer in keyring_read() KEYS: prevent creating a different user's keyrings KEYS: prevent KEYCTL_READ on negative key x86/fpu: Don't let userspace set bogus xcomp_bv Frederic Barrat (1): cxl: Fix driver use count Greg Kroah-Hartman (1): Linux 4.4.90 Haozhong Zhang (2): KVM: VMX: do not change SN bit in vmx_update_pi_irte() KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt Jan H. Schönherr (1): KVM: VMX: Do not BUG() on out-of-bounds guest IRQ Jim Mattson (1): kvm: nVMX: Don't allow L2 to access the hardware CR8 LEROY Christophe (2): crypto: talitos - Don't provide setkey for non hmac hashing algs. crypto: talitos - fix sha224 Marc Zyngier (1): arm64: Make sure SPsel is always set Myungho Jung (1): timer/sysclt: Restrict timer migration sysctl values to 0 and 1 Naohiro Aota (2): btrfs: fix NULL pointer dereference from free_reloc_roots() btrfs: propagate error to btrfs_cmp_data_prepare caller Nicolai Stange (1): PCI: Fix race condition with driver_override Oleg Nesterov (1): seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter() Paolo Bonzini (1): KVM: VMX: use cmpxchg64 Paul Mackerras (1): KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce() Robert Jarzmik (3): dmaengine: mmp-pdma: add number of requestors ARM: pxa: add the number of DMA req
Re: Linux 3.18.73
diff --git a/Makefile b/Makefile
index 9b82f279ef1d..f5e683464cd4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 72
+SUBLEVEL = 73
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index f8a576b1d9bb..5409d70ffe6f 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -59,6 +59,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+ .mmap = xen_swiotlb_dma_mmap,
};
int __init xen_mm_init(void)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 2877dd818977..5c4b8d6e8ba0 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -264,6 +264,7 @@ ENDPROC(stext)
* booted in EL1 or EL2 respectively.
*/
ENTRY(el2_setup)
+ msr SPsel, #1 // We want to use SP_EL{1,2}
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.ne1f
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 54cf9bc94dad..3a095670b0c4 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -101,22 +101,17 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args)
{
struct kvmppc_spapr_tce_table *stt = NULL;
+ struct kvmppc_spapr_tce_table *siter;
long npages;
int ret = -ENOMEM;
int i;
- /* Check this LIOBN hasn't been previously allocated */
- list_for_each_entry(stt, &kvm->arch.spapr_tce_tables, list) {
- if (stt->liobn == args->liobn)
- return -EBUSY;
- }
-
npages = kvmppc_stt_npages(args->window_size);
stt = kzalloc(sizeof(*stt) + npages * sizeof(struct page *),
GFP_KERNEL);
if (!stt)
- goto fail;
+ return ret;
stt->liobn = args->liobn;
stt->window_size = args->window_size;
@@ -128,23 +123,36 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
goto fail;
}
- kvm_get_kvm(kvm);
-
mutex_lock(&kvm->lock);
- list_add(&stt->list, &kvm->arch.spapr_tce_tables);
+
+ /* Check this LIOBN hasn't been previously allocated */
+ ret = 0;
+ list_for_each_entry(siter, &kvm->arch.spapr_tce_tables, list) {
+ if (siter->liobn == args->liobn) {
+ ret = -EBUSY;
+ break;
+ }
+ }
+
+ if (!ret)
+ ret = anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
+ stt, O_RDWR | O_CLOEXEC);
+
+ if (ret >= 0) {
+ list_add(&stt->list, &kvm->arch.spapr_tce_tables);
+ kvm_get_kvm(kvm);
+ }
mutex_unlock(&kvm->lock);
- return anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
- stt, O_RDWR | O_CLOEXEC);
+ if (ret >= 0)
+ return ret;
-fail:
- if (stt) {
- for (i = 0; i < npages; i++)
- if (stt->pages[i])
- __free_page(stt->pages[i]);
+ fail:
+ for (i = 0; i < npages; i++)
+ if (stt->pages[i])
+ __free_page(stt->pages[i]);
- kfree(stt);
- }
+ kfree(stt);
return ret;
}
diff --git a/arch/powerpc/platforms/pseries/mobility.c
b/arch/powerpc/platforms/pseries/mobility.c
index f8c9ff7886e1..b86408e91e8b 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -225,8 +225,10 @@ static int add_dt_node(__be32 parent_phandle, __be32
drc_index)
return -ENOENT;
dn = dlpar_configure_connector(drc_index, parent_dn);
- if (!dn)
+ if (!dn) {
+ of_node_put(parent_dn);
return -ENOENT;
+ }
rc = dlpar_attach_node(dn);
if (rc)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 8d6e954db2a7..9c9f4c0b0106 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -388,11 +388,22 @@ int xstateregs_set(struct task_struct *target, const
struct user_regset *regset,
xsave_hdr = &target->thread.fpu.state->xsave.xsave_hdr;
xsave_hdr->xstate_bv &= pcntxt_mask;
+
+ /* xcomp_bv must be 0 when using uncompacted format */
+ if (!ret && xsave_hdr->xcomp_bv)
+ ret = -EINVAL;
+
/*
* These bits must be zero.
*/
memset(xsave_hdr->reserved, 0, 48);
+ /*
+* In case of failure, mark all states as init:
+*/
+ if (ret)
+ fpu_finit(&target->thread.fpu);
+
return ret;
}
diff --git a/arch/x86/kernel/xsave.c b/arc
Re: Linux 4.4.90
diff --git a/Makefile b/Makefile
index 7e4c46b375b3..ca5aaaf4aef7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 89
+SUBLEVEL = 90
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 7f68a1ee7073..210192c38df3 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -13,6 +13,7 @@
interrupts = <25>;
#dma-channels = <32>;
#dma-cells = <2>;
+ #dma-requests = <75>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index 564341af7e97..fec47bcd8292 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -12,6 +12,7 @@
interrupts = <25>;
#dma-channels = <32>;
#dma-cells = <2>;
+ #dma-requests = <100>;
status = "okay";
};
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 2a6e0ae2b920..614e9d8f0a54 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -1203,6 +1203,7 @@ void __init pxa2xx_set_spi_info(unsigned id, struct
pxa2xx_spi_master *info)
static struct mmp_dma_platdata pxa_dma_pdata = {
.dma_channels = 0,
+ .nb_requestors = 0,
};
static struct resource pxa_dma_resource[] = {
@@ -1231,8 +1232,9 @@ static struct platform_device pxa2xx_pxa_dma = {
.resource = pxa_dma_resource,
};
-void __init pxa2xx_set_dmac_info(int nb_channels)
+void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
{
pxa_dma_pdata.dma_channels = nb_channels;
+ pxa_dma_pdata.nb_requestors = nb_requestors;
pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);
}
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 1dc85ffc3e20..049b9cc22720 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -206,7 +206,7 @@ static int __init pxa25x_init(void)
register_syscore_ops(&pxa_irq_syscore_ops);
register_syscore_ops(&pxa2xx_mfp_syscore_ops);
- pxa2xx_set_dmac_info(16);
+ pxa2xx_set_dmac_info(16, 40);
pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
ret = platform_add_devices(pxa25x_devices,
ARRAY_SIZE(pxa25x_devices));
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index ffc424028557..2fb6430b7a34 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -309,7 +309,7 @@ static int __init pxa27x_init(void)
if (!of_have_populated_dt()) {
pxa_register_device(&pxa27x_device_gpio,
&pxa27x_gpio_info);
- pxa2xx_set_dmac_info(32);
+ pxa2xx_set_dmac_info(32, 75);
ret = platform_add_devices(devices,
ARRAY_SIZE(devices));
}
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 20ce2d386f17..ca06f082497c 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -450,7 +450,7 @@ static int __init pxa3xx_init(void)
if (of_have_populated_dt())
return 0;
- pxa2xx_set_dmac_info(32);
+ pxa2xx_set_dmac_info(32, 100);
ret = platform_add_devices(devices, ARRAY_SIZE(devices));
if (ret)
return ret;
diff --git a/arch/arm/plat-pxa/include/plat/dma.h
b/arch/arm/plat-pxa/include/plat/dma.h
index 28848b344e2d..ceba3e4184fc 100644
--- a/arch/arm/plat-pxa/include/plat/dma.h
+++ b/arch/arm/plat-pxa/include/plat/dma.h
@@ -95,6 +95,6 @@ static inline int pxad_toggle_reserved_channel(int
legacy_channel)
}
#endif
-extern void __init pxa2xx_set_dmac_info(int nb_channels);
+extern void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors);
#endif /* __PLAT_DMA_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index c5f9a9e3d1f3..28d83f536e93 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -199,6 +199,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+ .mmap = xen_swiotlb_dma_mmap,
};
int __init xen_mm_init(void)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 20ceb5edf7b8..d019c3a58cc2 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -446,6 +446,7 @@ ENDPROC(__mmap_switched)
* booted in EL1 or EL2 respectively.
*/
ENTRY(el2_setup)
Re: Linux 4.9.53
diff --git a/Makefile b/Makefile
index c53de1e38c6a..98e3be659b21 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 52
+SUBLEVEL = 53
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d062f08f5020..4b24964a520a 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -199,6 +199,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+ .mmap = xen_swiotlb_dma_mmap,
};
int __init xen_mm_init(void)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 332e33193ccf..539bebc1222f 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -486,6 +486,7 @@ ENTRY(kimage_vaddr)
* booted in EL1 or EL2 respectively.
*/
ENTRY(el2_setup)
+ msr SPsel, #1 // We want to use SP_EL{1,2}
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.ne1f
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fec5b1ce97f8..403fe9e57135 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -509,7 +509,7 @@ static const struct fault_info fault_info[] = {
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 0 translation
fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 1 translation
fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 2 translation
fault" },
- { do_page_fault,SIGSEGV, SEGV_MAPERR, "level 3 translation
fault" },
+ { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation
fault" },
{ do_bad, SIGBUS, 0, "unknown 8"
},
{ do_page_fault,SIGSEGV, SEGV_ACCERR, "level 1 access flag
fault" },
{ do_page_fault,SIGSEGV, SEGV_ACCERR, "level 2 access flag
fault" },
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 767ef6d68c9e..caa659671599 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1235,10 +1235,14 @@ _GLOBAL(ftrace_caller)
stdur1,-SWITCH_FRAME_SIZE(r1)
/* Save all gprs to pt_regs */
- SAVE_8GPRS(0,r1)
- SAVE_8GPRS(8,r1)
- SAVE_8GPRS(16,r1)
- SAVE_8GPRS(24,r1)
+ SAVE_GPR(0, r1)
+ SAVE_10GPRS(2, r1)
+ SAVE_10GPRS(12, r1)
+ SAVE_10GPRS(22, r1)
+
+ /* Save previous stack pointer (r1) */
+ addir8, r1, SWITCH_FRAME_SIZE
+ std r8, GPR1(r1)
/* Load special regs for save below */
mfmsr r8
@@ -1292,10 +1296,10 @@ ftrace_call:
#endif
/* Restore gprs */
- REST_8GPRS(0,r1)
- REST_8GPRS(8,r1)
- REST_8GPRS(16,r1)
- REST_8GPRS(24,r1)
+ REST_GPR(0,r1)
+ REST_10GPRS(2,r1)
+ REST_10GPRS(12,r1)
+ REST_10GPRS(22,r1)
/* Restore callee's TOC */
ld r2, 24(r1)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index dcbb9144c16d..d97370866a5f 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -131,7 +131,7 @@ static void flush_tmregs_to_thread(struct task_struct *tsk)
* in the appropriate thread structures from live.
*/
- if (tsk != current)
+ if ((!cpu_has_feature(CPU_FTR_TM)) || (tsk != current))
return;
if (MSR_TM_SUSPENDED(mfmsr())) {
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index c379ff5a4438..da2a7eccb10a 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -129,8 +129,11 @@ static int kvm_spapr_tce_mmap(struct file *file, struct
vm_area_struct *vma)
static int kvm_spapr_tce_release(struct inode *inode, struct file *filp)
{
struct kvmppc_spapr_tce_table *stt = filp->private_data;
+ struct kvm *kvm = stt->kvm;
+ mutex_lock(&kvm->lock);
list_del_rcu(&stt->list);
+ mutex_unlock(&kvm->lock);
kvm_put_kvm(stt->kvm);
@@ -150,6 +153,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce_64 *args)
{
struct kvmppc_spapr_tce_table *stt = NULL;
+ struct kvmppc_spapr_tce_table *siter;
unsigned long npages, size;
int ret = -ENOMEM;
int i;
@@ -157,24 +161,16 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
if (!args->size)
return -EINVAL;
- /* Check this LIOBN hasn't been previously allocated */
- list_for_each_entry(stt, &kvm->arch.spapr_tce_tables, list) {
- if (stt->liobn == args->liobn)
- return -EBUSY;
- }
-
size = args->size;
npages = kvmppc_tce_pages(size);
ret = kvmppc_account_memlim
Linux 4.9.53
I'm announcing the release of the 4.9.53 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/xen/mm.c |1 arch/arm64/kernel/head.S |1 arch/arm64/mm/fault.c |2 arch/powerpc/kernel/entry_64.S| 20 +- arch/powerpc/kernel/ptrace.c |2 arch/powerpc/kvm/book3s_64_vio.c | 57 +++--- arch/powerpc/platforms/pseries/mobility.c |4 arch/s390/mm/gup.c|7 arch/x86/kernel/fpu/regset.c |9 arch/x86/kernel/fpu/signal.c |4 arch/x86/kernel/kvm.c |3 arch/x86/kvm/vmx.c| 240 +- arch/x86/mm/fault.c | 47 ++--- block/bsg-lib.c |1 crypto/drbg.c |8 drivers/base/power/main.c |9 drivers/crypto/talitos.c |9 drivers/gpu/drm/etnaviv/etnaviv_gem.c |3 drivers/gpu/drm/radeon/radeon_device.c|2 drivers/infiniband/hw/cxgb4/cm.c |4 drivers/md/raid5.c| 13 + drivers/misc/cxl/api.c|4 drivers/misc/cxl/file.c |8 drivers/net/wireless/mac80211_hwsim.c |2 drivers/pci/pci-sysfs.c | 11 - drivers/scsi/scsi_transport_iscsi.c |2 drivers/video/fbdev/aty/atyfb_base.c |2 drivers/xen/swiotlb-xen.c | 19 ++ fs/btrfs/ioctl.c |6 fs/btrfs/relocation.c |2 fs/cifs/cifsfs.c |2 fs/cifs/connect.c |8 fs/cifs/file.c|7 fs/cifs/smb2pdu.c | 21 +- fs/gfs2/glock.c | 16 - fs/proc/array.c |9 fs/read_write.c |4 fs/xfs/xfs_ioctl.c|3 include/linux/key.h |2 include/net/mac80211.h| 15 - include/xen/swiotlb-xen.h |5 kernel/irq/irqdesc.c | 24 -- kernel/seccomp.c | 23 +- kernel/sysctl.c |2 kernel/time/timer.c |2 kernel/trace/trace.c | 12 - net/mac80211/iface.c | 17 + net/mac80211/offchannel.c |2 net/mac80211/tx.c | 36 +++ net/wireless/nl80211.c|3 security/keys/Kconfig |4 security/keys/big_key.c | 138 ++ security/keys/internal.h |2 security/keys/key.c |2 security/keys/keyctl.c|5 security/keys/keyring.c | 37 ++-- security/keys/process_keys.c |6 tools/testing/selftests/seccomp/seccomp_bpf.c | 18 + 59 files changed, 548 insertions(+), 381 deletions(-) Alex Deucher (1): drm/radeon: disable hard reset in hibernate for APUs Andreas Gruenbacher (2): vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets gfs2: Fix debugfs glocks dump Avraham Stern (1): mac80211: flush hw_roc_start work before cancelling the ROC Beni Lev (1): mac80211_hwsim: Use proper TX power Bo Yan (1): tracing: Erase irqsoff trace with empty write Boqun Feng (1): kvm/x86: Handle async PF in RCU read-side critical sections Christoph Hellwig (1): bsg-lib: don't free job in bsg_prepare_job Dennis Yang (1): md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list Eric Biggers (4): KEYS: fix writing past end of user-supplied buffer in keyring_read() KEYS: prevent creating a different user's keyrings KEYS: prevent KEYCTL_READ on negative key x86/fpu: Don't let userspace set bogus xcomp_bv Frederic Barrat (1): cxl: Fix driver use count Gerald Schaefer (1): s390/mm: fix write access check in gup_huge_pmd() Greg Kroah-Hartman (1): Linux 4.9.53 Gustavo Romero (1): powerpc/tm: Flush TM only if CPU has TM feature Haozhong Zhang (2): KVM: VMX: do n
Linux 4.13.5
I'm announcing the release of the 4.13.5 kernel. All users of the 4.13 kernel series must upgrade. The updated 4.13.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.13.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm64/include/asm/pgtable.h |2 arch/arm64/kernel/head.S |1 arch/arm64/mm/fault.c |2 arch/mips/kernel/perf_event_mipsxx.c |3 arch/powerpc/kernel/eeh.c |4 arch/powerpc/kernel/eeh_dev.c | 18 - arch/powerpc/kernel/ptrace.c |2 arch/powerpc/kvm/book3s_hv.c |2 arch/powerpc/kvm/book3s_hv_rm_xive.c |1 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 17 + arch/powerpc/kvm/book3s_xive.c|1 arch/powerpc/kvm/book3s_xive_template.c |7 arch/powerpc/platforms/pseries/mobility.c |4 arch/s390/include/asm/pgtable.h |4 arch/s390/kernel/perf_cpum_sf.c |9 arch/s390/mm/gup.c|7 arch/x86/kernel/fpu/regset.c |9 arch/x86/kernel/fpu/signal.c |4 arch/x86/kernel/kvm.c |3 arch/x86/kvm/vmx.c| 256 +- arch/x86/mm/fault.c | 47 ++-- block/bsg-lib.c |1 crypto/drbg.c |8 drivers/base/power/main.c |9 drivers/base/power/opp/core.c |7 drivers/block/brd.c |2 drivers/crypto/talitos.c |9 drivers/dax/super.c | 21 +- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 189 +++ drivers/gpu/drm/etnaviv/etnaviv_gem.c |3 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |6 drivers/gpu/drm/exynos/exynos_drm_drv.c |4 drivers/gpu/drm/i915/gvt/cfg_space.c | 113 --- drivers/gpu/drm/i915/intel_dsi.c | 11 - drivers/gpu/drm/radeon/radeon_device.c|2 drivers/infiniband/hw/cxgb4/cm.c |9 drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 - drivers/md/dm-integrity.c |6 drivers/md/dm-linear.c| 15 - drivers/md/dm-stripe.c| 20 -- drivers/md/dm.c | 19 - drivers/md/md.c | 72 --- drivers/md/md.h |1 drivers/md/raid5.c| 13 + drivers/mmc/core/queue.c |7 drivers/mmc/host/sdhci-pci-core.c | 15 + drivers/mtd/mtdpart.c |8 drivers/mtd/nand/atmel/pmecc.c|2 drivers/net/wireless/mac80211_hwsim.c |2 drivers/nvdimm/namespace_devs.c |9 drivers/nvdimm/pmem.c |7 drivers/nvme/host/pci.c | 66 -- drivers/pci/pci-sysfs.c | 11 - drivers/platform/x86/fujitsu-laptop.c | 10 - drivers/scsi/aacraid/aachba.c | 12 - drivers/scsi/aacraid/aacraid.h|5 drivers/scsi/aacraid/src.c|2 drivers/scsi/scsi_transport_fc.c |2 drivers/scsi/scsi_transport_iscsi.c |2 drivers/video/fbdev/aty/atyfb_base.c |2 fs/btrfs/inode.c | 20 ++ fs/btrfs/ioctl.c |6 fs/btrfs/relocation.c |2 fs/cifs/cifsfs.c |2 fs/cifs/cifsglob.h|6 fs/cifs/connect.c | 32 ++- fs/cifs/file.c|7 fs/cifs/inode.c | 15 + fs/cifs/smb2ops.c | 40 fs/cifs/smb2pdu.c | 111 +-- fs/cifs/smb2pdu.h |2 fs/dax.c |4 fs/gfs2/glock.c | 14 - fs/proc/array.c |9 fs/read_write.c |4 fs/xfs/xfs_ioctl.c|3 include/linux/dax.h |5 include/linux/device-mapper.h |3 include/linux/key.h |2 include/net/mac80211.h| 15 - kernel/exit.c
Re: zstd kernel and initrd compression
Hi Nick, On Oct 5, 2017, at 1:29, Nick Terrell wrote: > On 10/4/17, 3:01 AM, "linux-kernel-ow...@vger.kernel.org on behalf of René > Rebe" > wrote: >> Hi, >> >> I noticed zstd compression was recently added for btrfs and squashfs. >> Are there actually already patches floating around for zstd kernel and >> intird compression? >> Looks like that would be a quite nice fit regarding speed and compression >> ratio, … >> >> Regards, >> René > > I started working on some patches yesterday, and just got zstd kernel, > initrd, and initramfs compression working today. I think I'll be ready to > send the patches out within a week. awesome, if you have something to test I could give it a try on my test bench, too. Regards, René -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec
Hi Mauro, My apologies for the late reply. On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 29 Aug 2017 10:47:48 +0300 > Sakari Ailus escreveu: > > > Hi Mauro, > > > > Thanks for the update. A few comments below. > > > > On Mon, Aug 28, 2017 at 09:53:55AM -0300, Mauro Carvalho Chehab wrote: > > > Add a glossary of terms for V4L2, as several concepts are complex > > > enough to cause misunderstandings. > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > --- > > > Documentation/media/uapi/v4l/glossary.rst | 147 > > > ++ > > > Documentation/media/uapi/v4l/v4l2.rst | 1 + > > > 2 files changed, 148 insertions(+) > > > create mode 100644 Documentation/media/uapi/v4l/glossary.rst > > > > > > diff --git a/Documentation/media/uapi/v4l/glossary.rst > > > b/Documentation/media/uapi/v4l/glossary.rst > > > new file mode 100644 > > > index ..0b6ab5adec81 > > > --- /dev/null > > > +++ b/Documentation/media/uapi/v4l/glossary.rst > > > @@ -0,0 +1,147 @@ > > > + > > > +Glossary > > > + > > > + > > > +.. note:: > > > + > > > + This goal of section is to standardize the terms used within the V4L2 > > > + documentation. It is written incrementally as they are standardized in > > > + the V4L2 documentation. So, it is a Work In Progress. > > > > I'd leave the WiP part out. > > IMO, it is important to mention it, as the glossary, right now, covers > only what's used on the first two sections of the API book. There are > a lot more to be covered. Works for me. > > > > > > + > > > +.. Please keep the glossary entries in alphabetical order > > > + > > > +.. glossary:: > > > + > > > +Bridge driver > > > + The same as V4L2 main driver. > > > > I've understood bridges being essentially a bus receiver + DMA. Most ISPs > > contain both but have more than that. How about: > > > > A driver for a bus (e.g. parallel, CSI-2) receiver and DMA. Bridge drivers > > typically act as V4L2 main drivers. > > No, only on some drivers the bridge driver has DMA. A vast amount of > drivers (USB ones) don't implement any DMA inside the driver, as it is > up to the USB host driver to implement support for DMA. > > There are even some USB host drivers that don't always use DMA for I/O > transfers, using direct I/O if the message is smaller than a threshold > or not multiple of the bus word. This is pretty common on SoC USB host > drivers. > > In any case, for the effect of this spec, and for all discussions we > ever had about it, bridge driver == V4L2 main driver. I don't > see any reason why to distinguish between them. I think you should precisely define what a bridge driver means. Generally ISP drivers aren't referred to as bridge drivers albeit they, too, function as V4L2 main drivers. > > > > > > + > > > +Device Node > > > + A character device node in the file system used to control and do > > > + input/output data transfers from/to a Kernel driver. > > > + > > > +Digital Signal Processor - DSP > > > + A specialized microprocessor, with its architecture optimized for > > > + the operational needs of digital signal processing. > > > + > > > +Driver > > > + The part of the Linux Kernel that implements support > > > + for a hardware component. > > > + > > > +Field-programmable Gate Array - FPGA > > > + A field-programmable gate array (FPGA) is an integrated circuit > > > + designed to be configured by a customer or a designer after > > > + manufacturing. > > > + > > > + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. > > > + > > > +Hardware component > > > + A subset of the media hardware. For example an I²C or SPI device, > > > + or an IP block inside an SoC or FPGA. > > > + > > > +Hardware peripheral > > > + A group of hardware components that together make a larger > > > + user-facing functional peripheral. For instance the SoC ISP IP > > > + cores and external camera sensors together make a > > > + camera hardware peripheral. > > > + > > > + Also known as peripheral. > > > > Aren't peripherals usually understood to be devices that you can plug into > > a computer? Such as a printer, or a... floppy drive? > > That is the common sense, although, technically, peripherals are any > I/O component. It is "peripheral" in the sense that it is not part of > the CPU's internal circuits. Instead, it is a data that should be sent > in or out the CPU. > > On such concept, even an I/O hardware integrated inside a SoC is a > peripheral. > > Yet, Hans argued already against using it. I opened a separate > thread for us to discuss about it. > > > I certainly wouldn't call this a peripheral. How about "aggregate device"? > > We haven't used that before, but I think it relatively well catches the > > meaning without being excessively elaborate. > > "aggregate device" means nothing to me ;-) I propose "media hardware" instead. Hardware is substance such as milk. You can't say "a m
Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers
On Thu, 5 Oct 2017 09:57:04 +0200 Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > > > On Wed, 4 Oct 2017 12:41:01 +0200 > > Ingo Molnar wrote: > > > > > > > > * Masami Hiramatsu wrote: > > > > > > > Hmm, actually we can not disable jprobe, that has no separate Kconfig. > > > > So we need to introduce new kconfig for that. > > > > > > > > And, there are several network protocols using jprobe to trace events. > > > > (e.g. NET_DCCPPROBE and NET_TCPPROBE) > > > > I think they need to migrate to trace-event at first. > > > > > > > > So, how about below idea? > > > > > > > > 1. Introduce CONFIG_JPROBE_API which only separate jprobe general parts > > > > (no arch dependent code involves) and make it default n. > > > > 2. Mark break_handler and jprobe APIs deprecated so that no new user > > > > comes up. > > > > 3. migrate in-kernel jprobe user to trace-event or ftrace. > > > >(may take some time) > > > > > > So my suggestion would be to just return from register_jprobe() and don't > > > register > > > anything. > > > > with CONFIG_JPROBE_API=n, is that right? > > No, unconditionally off with a WARN_ON_ONCE() warning in the registry > function and > the deactivation of all in-kernel uses (such as self-tests). > > The point is to make people that _truly_ rely on it complain - not just make > them > silently turn on a Kconfig option ... Hmm, but in that case, anyway we have to remove or rename the function like register_jprobe. Or would that "unconditionally" mean "#if 0"? > > > Yes, there are usecases of jprobes in the kernel, but they all look > > > pretty ancient and unused. > > > > Hmm, in that case, should we also remove those users? If we disable such way > > those features are just useless. > > My hypothesis is that those features are not used (hence useless), but we > should > first test whether there's any reliance before we remove code. Agreed. Thank you, > > Thanks, > > Ingo -- Masami Hiramatsu
Re: [PATCH] reset: uniphier: add PXs3 reset data
On Thu, 2017-10-05 at 11:30 +0900, Masahiro Yamada wrote:
> Add basic reset data for Socionext's new SoC PXs3.
>
> Signed-off-by: Masahiro Yamada
Thanks, applied to the reset/next branch.
regards
Philipp
> ---
>
> .../devicetree/bindings/reset/uniphier-reset.txt | 3 +++
> drivers/reset/reset-uniphier.c | 26
> ++
> 2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-
> reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index 68a6f48..93efed6 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -13,6 +13,7 @@ Required properties:
> "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
> "socionext,uniphier-ld11-reset" - for LD11 SoC
> "socionext,uniphier-ld20-reset" - for LD20 SoC
> +"socionext,uniphier-pxs3-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> @@ -44,6 +45,7 @@ Required properties:
> "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
> "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD)
> "socionext,uniphier-ld20-sd-reset" - for LD20 SoC
> +"socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> @@ -74,6 +76,7 @@ Required properties:
> "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
> "socionext,uniphier-ld11-peri-reset" - for LD11 SoC
> "socionext,uniphier-ld20-peri-reset" - for LD20 SoC
> +"socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-
> uniphier.c
> index bda2dd1..6ed808d 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -114,6 +114,20 @@ static const struct uniphier_reset_data
> uniphier_ld20_sys_reset_data[] = {
> UNIPHIER_RESET_END,
> };
>
> +static const struct uniphier_reset_data
> uniphier_pxs3_sys_reset_data[] = {
> + UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
> + UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
> + UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
> + UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link
> (GIO0) */
> + UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link
> (GIO1) */
> + UNIPHIER_RESETX(16, 0x200c, 16),/* USB30-PHY0 */
> + UNIPHIER_RESETX(17, 0x200c, 18),/* USB30-PHY1 */
> + UNIPHIER_RESETX(18, 0x200c, 20),/* USB30-PHY2 */
> + UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY0 */
> + UNIPHIER_RESETX(21, 0x200c, 19),/* USB31-PHY1 */
> + UNIPHIER_RESET_END,
> +};
> +
> /* Media I/O reset data */
> #define UNIPHIER_MIO_RESET_SD(id, ch)\
> UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
> @@ -359,6 +373,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-reset",
> .data = uniphier_ld20_sys_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-reset",
> + .data = uniphier_pxs3_sys_reset_data,
> + },
> /* Media I/O reset, SD reset */
> {
> .compatible = "socionext,uniphier-ld4-mio-reset",
> @@ -392,6 +410,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-sd-reset",
> .data = uniphier_pro5_sd_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> + },
> /* Peripheral reset */
> {
> .compatible = "socionext,uniphier-ld4-peri-reset",
> @@ -421,6 +443,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-peri-reset",
> .data = uniphier_pro4_peri_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-peri-reset",
> + .data = uniphier_pro4_peri_reset_data,
> + },
> /* Analog signal amplifiers reset */
> {
> .compatible = "socionext,uniphier-ld11-adamv-reset",
Re: [PATCH] arm: dts: gr-peach: Reduce extal_clk resolution
Hi Jacopo,
On Thu, Oct 5, 2017 at 9:48 AM, jacopo mondi wrote:
> On Wed, Oct 04, 2017 at 05:54:46PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Oct 4, 2017 at 5:40 PM, Jacopo Mondi
>> wrote:
>> > The system clock described by extal_clk is reported to have a frequency
>> > of 13.333 Mhz and is correctly described by gr-peach device tree.
>> >
>> > However, when enabling a RIIC device the following error is reported by
>> > drivers/i2c/busses/i2c-riic.c
>> >
>> > "invalid parent clk (2500). Must be 33325000Hz"
>> >
>> > As RIIC devices have a clock source obtained by dividing by 12 the
>> > system clock, the resulting value is not accepted by the driver
>> > (which clearly states not to support any frequency except the reported
>> > 33325000Hz one).
>> >
>> > Hence, reduce the system clock accuracy to a value which makes
>> > frequencies obtained through division accepted by RIIC driver.
>> >
>> > Please note that other r7s72100 boards, such as Genmai, report the same
>> > "reduced accuracy" frequency, even if their external clock sources are
>> > effectively 13.333Mhz as gr-peach one.
>> >
>> > Signed-off-by: Jacopo Mondi
>>
>> There's no need to do this, Chris already proposed a fix, cfr.
>> "[PATCH v2] i2c: riic: remove fixed clock restriction"
>> (https://www.spinics.net/lists/linux-renesas-soc/msg18573.html).
>
> Oh that's even better!
> Do you see any value in augmenting the frequency resolution in Genmai
> DTS then?
The Genmai documentation says EXTAL is 13.33 MHz (which matches
r7s72100-genmai.dts) everywhere, except in the schematics, where it says
13. MHz. Sigh...
The difference is slightly larger than 100 ppm, so still insignificant, I think.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/12] of: overlay: clean up device tree overlay code
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 10/05/17 09:53, Tomi Valkeinen wrote: > On 04/10/17 17:56, Rob Herring wrote: >> On Mon, Oct 2, 2017 at 10:53 PM, wrote: >>> From: Frank Rowand >>> >>> I have found the device tree overlay code to be difficult to read and >>> maintain. This patch series attempts to improve that situation. >>> >>> The cleanup includes some changes visible to users of overlays. The >>> only in kernel user of overlays is fixed up for those changes. The >>> in kernel user is: >>> >>>drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c >> >> At what point can we remove this? I'm assuming at some point users >> will need to update their dtb's for other reasons and this becomes >> obsolete. > > To be honest, I have no idea, or how to find that out. > I think the first approach could be setting the DRM_TILCDC_SLAVE_COMPAT default to n and listen if there is any reports about breakage. > Do we need to get rid of it? Afaik, we haven't do much (or any?) > maintenance on tilcdc_slave_compat.c since it was written, so from our > perspective it's been a minimal burden. Is it creating burden for others? > > Is the approach done with tilcdc_slave_compat.c something that's not > recommended? I'm sure similar situations happen with other drivers too, > and I think it's a good idea to have a recommended way of keeping > compatibility. > For tilcdc I would say that we soon need a similar mechanism to get rid off tilcdc internal panel driver and to start using generic panel drivers instead. That is, if we want to keep the kernel compatible with old devicetree blobs. Best regards, Jyri
Re: [PATCH] mwifiex: Use put_unaligned_le32
On Thu, Oct 05, 2017 at 10:23:37AM +0300, Kalle Valo wrote: > Himanshu Jha writes: > > > Use put_unaligned_le32 rather than using byte ordering function and > > memcpy which makes code clear. > > Also, add the header file where it is declared. > > > > Done using Coccinelle and semantic patch used is : > > > > @ rule1 @ > > identifier tmp; expression ptr,x; type T; > > @@ > > > > - tmp = cpu_to_le32(x); > > > > <+... when != tmp > > - memcpy(ptr, (T)&tmp, ...); > > + put_unaligned_le32(x,ptr); > > ...+> > > > > @ depends on rule1 @ > > type j; identifier tmp; > > @@ > > > > - j tmp; > > ...when != tmp > > > > Signed-off-by: Himanshu Jha > > --- > > drivers/net/wireless/marvell/mwifiex/cmdevt.c | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c > > b/drivers/net/wireless/marvell/mwifiex/cmdevt.c > > index 0edc5d6..e28e119 100644 > > --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c > > +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c > > @@ -17,6 +17,7 @@ > > * this warranty disclaimer. > > */ > > > > +#include > > I don't think this is correct. Should it be asm/unaligned.h? Would mind explainig me as to why it is incorrect! Also, it defined in both the header files but, why is asm/unaligned.h preferred ? Thanks > -- > Kalle Valo
Re: [PATCH] epoll: account epitem and eppoll_entry to kmemcg
On Wed 04-10-17 12:33:14, Shakeel Butt wrote: > > > > I am not objecting to the patch I would just like to understand the > > runaway case. ep_insert seems to limit the maximum number of watches to > > max_user_watches which should be ~4% of lowmem if I am following the > > code properly. pwq_cache should be bound by the number of watches as > > well, or am I misunderstanding the code? > > > > You are absolutely right that there is a per-user limit (~4% of total > memory if no highmem) on these caches. I think it is too generous > particularly in the scenario where jobs of multiple users are running > on the system and the administrator is reducing cost by overcomitting > the memory. This is unaccounted kernel memory and will not be > considered by the oom-killer. I think by accounting it to kmemcg, for > systems with kmem accounting enabled, we can provide better isolation > between jobs of different users. Thanks for the clarification. For some reason I didn't figure that the limit is per user, even though the name suggests so. -- Michal Hocko SUSE Labs
[PATCH] lightnvm: pblk: remove spinlock when freeing line metadata
From: Hans Holmberg
Lockdep complains about being in atomic context while freeing line
metadata - and rightly so as we take a spinlock and end up calling
vfree that might sleep(in pblk_mfree).
There is no need for holding the line manager free_lock while
freeing line metadata, so remove the lock.
Signed-off-by: Hans Holmberg
---
This patch is for:
https://github.com/OpenChannelSSD/linux branch for-4.15/pblk
drivers/lightnvm/pblk-init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index c452478..a645117 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -393,13 +393,11 @@ static void pblk_line_meta_free(struct pblk *pblk)
kfree(l_mg->bb_aux);
kfree(l_mg->vsc_list);
- spin_lock(&l_mg->free_lock);
for (i = 0; i < PBLK_DATA_LINES; i++) {
kfree(l_mg->sline_meta[i]);
pblk_mfree(l_mg->eline_meta[i]->buf, l_mg->emeta_alloc_type);
kfree(l_mg->eline_meta[i]);
}
- spin_unlock(&l_mg->free_lock);
kfree(pblk->lines);
}
--
2.7.4
Re: [v10 3/6] mm, oom: cgroup-aware OOM killer
On Wed, 4 Oct 2017, Johannes Weiner wrote: > > By only considering leaf memcgs, does this penalize users if their memcg > > becomes oc->chosen_memcg purely because it has aggregated all of its > > processes to be members of that memcg, which would otherwise be the > > standard behavior? > > > > What prevents me from spreading my memcg with N processes attached over N > > child memcgs instead so that memcg_oom_badness() becomes very small for > > each child memcg specifically to avoid being oom killed? > > It's no different from forking out multiple mm to avoid being the > biggest process. > It is, because it can quite clearly be a DoS, and was prevented with Roman's earlier design of iterating usage up the hierarchy and comparing siblings based on that criteria. I know exactly why he chose that implementation detail early on, and it was to prevent cases such as this and to not let userspace hide from the oom killer. > It's up to the parent to enforce limits on that group and prevent you > from being able to cause global OOM in the first place, in particular > if you delegate to untrusted and potentially malicious users. > Let's resolve that global oom is a real condition and getting into that situation is not a userspace problem. It's the result of overcommiting the system, and is used in the enterprise to address business goals. If the above is true, and its up to memcg to prevent global oom in the first place, then this entire patchset is absolutely pointless. Limit userspace to 95% of memory and when usage is approaching that limit, let userspace attached to the root memcg iterate the hierarchy itself and kill from the largest consumer. This patchset exists because overcommit is real, exactly the same as overcommit within memcg hierarchies is real. 99% of the time we don't run into global oom because people aren't using their limits so it just works out. 1% of the time we run into global oom and we need a decision to made based for forward progress. Using Michal's earlier example of admins and students, a student can easily use all of his limit and also, with v10 of this patchset, 99% of the time avoid being oom killed just by forking N processes over N cgroups. It's going to oom kill an admin every single time. I know exactly why earlier versions of this patchset iterated that usage up the tree so you would pick from students, pick from this troublemaking student, and then oom kill from his hierarchy. Roman has made that point himself. My suggestion was to add userspace influence to it so that enterprise users and users with business goals can actually define that we really do want 80% of memory to be used by this process or this hierarchy, it's in our best interest. Earlier iterations of this patchset did this, and did it correctly. Userspace influence over the decisionmaking makes it a very powerful combination because you _can_ specify what your goals are or choose to leave the priorities as default so you can compare based solely on usage. It was a beautiful solution to the problem.
Re: [PATCH] intel_ips: Convert timers to use timer_setup()
On Thu, Oct 5, 2017 at 3:54 AM, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Moves timer structure off stack and
> into struct ips_driver.
Pushed to my testing queue, thanks!
>
> Cc: Darren Hart
> Cc: Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org
> Cc: Thomas Gleixner
> Signed-off-by: Kees Cook
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.
> ---
> drivers/platform/x86/intel_ips.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/platform/x86/intel_ips.c
> b/drivers/platform/x86/intel_ips.c
> index 58dcee562d64..056afb731d79 100644
> --- a/drivers/platform/x86/intel_ips.c
> +++ b/drivers/platform/x86/intel_ips.c
> @@ -300,6 +300,7 @@ struct ips_driver {
> struct task_struct *monitor;
> struct task_struct *adjust;
> struct dentry *debug_root;
> + struct timer_list timer;
>
> /* Average CPU core temps (all averages in .01 degrees C for
> precision) */
> u16 ctv1_avg_temp;
> @@ -942,9 +943,10 @@ static u32 calc_avg_power(struct ips_driver *ips, u32
> *array)
> return avg;
> }
>
> -static void monitor_timeout(unsigned long arg)
> +static void monitor_timeout(struct timer_list *t)
> {
> - wake_up_process((struct task_struct *)arg);
> + struct ips_driver *ips = from_timer(ips, t, timer);
> + wake_up_process(ips->monitor);
> }
>
> /**
> @@ -961,7 +963,6 @@ static void monitor_timeout(unsigned long arg)
> static int ips_monitor(void *data)
> {
> struct ips_driver *ips = data;
> - struct timer_list timer;
> unsigned long seqno_timestamp, expire, last_msecs, last_sample_period;
> int i;
> u32 *cpu_samples, *mchp_samples, old_cpu_power;
> @@ -1049,8 +1050,7 @@ static int ips_monitor(void *data)
> schedule_timeout_interruptible(msecs_to_jiffies(IPS_SAMPLE_PERIOD));
> last_sample_period = IPS_SAMPLE_PERIOD;
>
> - setup_deferrable_timer_on_stack(&timer, monitor_timeout,
> - (unsigned long)current);
> + timer_setup(&ips->timer, monitor_timeout, TIMER_DEFERRABLE);
> do {
> u32 cpu_val, mch_val;
> u16 val;
> @@ -1107,7 +1107,7 @@ static int ips_monitor(void *data)
> expire = jiffies + msecs_to_jiffies(IPS_SAMPLE_PERIOD);
>
> __set_current_state(TASK_INTERRUPTIBLE);
> - mod_timer(&timer, expire);
> + mod_timer(&ips->timer, expire);
> schedule();
>
> /* Calculate actual sample period for power averaging */
> @@ -1116,8 +1116,7 @@ static int ips_monitor(void *data)
> last_sample_period = 1;
> } while (!kthread_should_stop());
>
> - del_timer_sync(&timer);
> - destroy_timer_on_stack(&timer);
> + del_timer_sync(&ips->timer);
>
> dev_dbg(&ips->dev->dev, "ips-monitor thread stopped\n");
>
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] mwifiex: Use put_unaligned_le32
Himanshu Jha writes: >> > --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c >> > +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c >> > @@ -17,6 +17,7 @@ >> > * this warranty disclaimer. >> > */ >> > >> > +#include >> >> I don't think this is correct. Should it be asm/unaligned.h? > > Would mind explainig me as to why it is incorrect! Also, it defined in > both the header files but, why is asm/unaligned.h preferred ? asm/unaligned.h seems to be the toplevel header file which includes header files based on arch configuration. Also grepping the sources support that, nobody from drivers/ include access_ok.h directly. But I can't say that I fully understand how the header files work so please do correct me if I have mistaken. -- Kalle Valo
Re: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver
On Thu, Oct 5, 2017 at 10:11 AM, Darren Hart wrote:
> On Thu, Oct 05, 2017 at 08:29:10AM +0300, Andy Shevchenko wrote:
>> On Thu, Oct 5, 2017 at 4:09 AM, Darren Hart wrote:
>> > You'll want to add something like:
>> >
>> > #ifdef CONFIG_DELL_WMI_DESCRIPTOR_MODULE
>> > if (request_module("dell_wmi_descriptor"))
>> > /* FAIL */
>> > #endif
>> >
>> > During init.
>>
>> I don't think #ifdef is needed.
>
> Without the ifdef, we can't distinguish between request_module failing
> to load the module because it isn't available and because it is
> built-in.
>
>>
>> We may just request module.
>>
>> But looking in the code it seems that we simple need to select that
>> module. No request_module will be needed.
>
> The select will ensure the module is built, but there is not guarantee
> to module load order. The intent of the above is to ensure the symbols
> from the required module are loaded.
>
>> Did I miss something?
>
> Or I did :-) Is there something about this module which ensures
> dell_wmi_descriptor is loaded first?
If there is an optional *run-time* dependency we need to use somelike
request_module(). For example, this is the case for idma64
(drivers/dma) vs intel-lpss (drivers/mfd).
If it's mandatory run-time dependency, then we need to add stubs to
the header and select the callee's module in Kconfig.
In case they are both modules, depmod keeps an ordering.
So, the corner case here is when the caller is builtin while callee is module.
This is a bit tricky to add to Kconfig (we also have such cases
between I2C DesignWare and acpi_lpss AFAIR).
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v4 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens
On Thu, Oct 5, 2017 at 1:48 AM, Mario Limonciello wrote: > Currently userspace tools can access system tokens via the dcdbas > kernel module and a SMI call that will cause the platform to execute > SMM code. > > With a goal in mind of deprecating the dcdbas kernel module a different > method for accessing these tokens from userspace needs to be created. > > This is intentionally marked to only be readable as root as it can > contain sensitive information about the platform's configuration. > > MAINTAINERS was missing for this driver. Add myself and Pali to > maintainers list for it. > > Signed-off-by: Mario Limonciello > Suggested-by: Andy Shevchenko To be clear I just suggested the output format in ->show() callback. -- With Best Regards, Andy Shevchenko
Re: [PATCH v4 0/6] perf report/script: Support percent and multiple range in --time option
On Tue, Oct 03, 2017 at 10:22:32PM +0800, Jin Yao wrote: > v4: > --- > 1. Use perf script time style for timestamp printing. Also add with >the printing of sample duration. For example: > >perf report --header > >time of first sample : 5276531.323099 >time of last sample : 5276555.345625 >sample duration : 24022.526 ms > > 2. Fix an invalid time string issue. For example, > >perf script --time 10%/10x12321xsdfdasfdsafdsafdsa > >Now in code, it uses strtol to replace atoi. for the patchset: Acked-by: Jiri Olsa thanks, jirka
Re: [PATCH v2] soc: mediatek: place Kconfig for all SoC drivers under menu
Hi Sean, On Thu, 5 Oct 2017 11:17:49 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add cleanup for placing all Kconfig for all MediaTek SoC drivers under > the independent menu as other SoCs vendor usually did. Since the menu > would be shown depending on "ARCH_MEDIATEK || COMPILE_TEST" selected and > MTK_PMIC_WRAP is still safe compiling with the case of "COMPILE_TEST" > only, the superfluous dependency for those items under the menu also is > also being removed for the sake of simplicity. > > Signed-off-by: Sean Wang > --- > drivers/soc/mediatek/Kconfig | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > index 609bb34..a7d0667 100644 > --- a/drivers/soc/mediatek/Kconfig > +++ b/drivers/soc/mediatek/Kconfig > @@ -1,9 +1,11 @@ > # > # MediaTek SoC drivers > # > +menu "MediaTek SoC drivers" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + > config MTK_INFRACFG > bool "MediaTek INFRACFG Support" > - depends on ARCH_MEDIATEK || COMPILE_TEST > select REGMAP > help > Say yes here to add support for the MediaTek INFRACFG controller. The > @@ -12,7 +14,6 @@ config MTK_INFRACFG > > config MTK_PMIC_WRAP > tristate "MediaTek PMIC Wrapper Support" > - depends on ARCH_MEDIATEK > depends on RESET_CONTROLLER > select REGMAP > help > @@ -22,7 +23,6 @@ config MTK_PMIC_WRAP > > config MTK_SCPSYS > bool "MediaTek SCPSYS Support" > - depends on ARCH_MEDIATEK || COMPILE_TEST > default ARCH_MEDIATEK > select REGMAP > select MTK_INFRACFG > @@ -30,3 +30,5 @@ config MTK_SCPSYS > help > Say yes here to add support for the MediaTek SCPSYS power domain > driver. > + > +endmenu While trying to test this, I found that I am not able to test-compile these drivers. The problem is in drivers/soc/Makefile: obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ So while Kconfig lets me select the drivers when COMPILE_TEST is enabled, the build system itself ignores the directory in which these drivers reside and they aren't built. If you really want your drivers to be test-compilable then you must change the above to: obj-y += mediatek/ I'll send a patch. Your patch itself looks good to me. Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support
r8169 Wake-on-LAN causes immediate ACPI GPE wakeup
Hi,
On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell
ENTE69AP and Gateway NE533, we are seeing a problem where the system
immediately wakes up after being put into S3 suspend.
This problem has been seen on all kernel versions that we have tried,
including 4.14-rc3.
After disabling wakeup sources one by one, we found that the r8169
ethernet is responsible for these wakeups here, the hardware is:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
Subsystem: Acer Incorporated [ALI] Device 1084
Flags: bus master, fast devsel, latency 0, IRQ 124
I/O ports at 1000 [size=256]
Memory at 91204000 (64-bit, non-prefetchable) [size=4K]
Memory at 9120 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Capabilities: [178] L1 PM Substates
Kernel driver in use: r8169
This driver enables WOL by default. The system wakes up immediately
when it is put into S3 suspend, even if there is no ethernet cable
plugged in.
The problem was also reproduced with the r8168 vendor driver, however
it does not occur under Windows, where we can suspend the system just
fine and also wake it up with a magic WOL packet.
Further investigation takes us into ACPI-land. The complete DSDT is here:
https://gist.github.com/dsd/62293b6d8c30a5204128709813a55ffb
Both Windows and Linux associate PCI0.RP05.PXSX with this device, so
let's consider this part of the DSDT:
Device (RP05)
{
Method (_ADR, 0, NotSerialized) // _ADR: Address
{
If (RPA5 != Zero)
{
Return (RPA5) /* \RPA5 */
}
Else
{
Return (0x00130002)
}
}
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x09, 0x04))
}
Device (PXSX)
{
Name (_ADR, Zero) // _ADR: Address
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x08,
0x04
})
}
}
RP05 corresponds to
00:13.0 PCI bridge: Intel Corporation Device 5ada (rev fb)
I am not familiar with this subdevice approach, where PXSX (with
address 0) is detected as a child of the PCI bridge, however both
Windows and Linux associate PXSX with the ethernet device, so I guess
it is correct.
Now to focus on the _PRW power resource for wakeup. The PXSX
(ethernet) device says that it will wake up the system using GPE08.
However if you look at the _L08 GPE08 event handler, you will see that
it does not do anything related to RP05/PXSX (it instead calls into
RP02, which does not even physically exist on this platform) -
suspicious.
On the other hand, the RP05 (root port) _PRW says it will wake up the
system via GPE09, and the _L09 handler at least has one codepath which
could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.
But in testing:
- If GPE08 is enabled as a wakeup source, the system will always wake
up as soon as it goes to sleep
- I have never seen a wakeup on GPE09
- Disabling GPE08 and all other GPE wakeups, the system sleeps fine,
and Wake-on-LAN works fine too
So in summary, the messy situation is that the DSDT suggests that
GPE08 will be used for ethernet wakeups, however that GPE seems to
fire instantly during suspend, and actually wake-on-LAN does not
appear to use ACPI GPEs to wake the system it all - it must use some
other mechanism. Windows is for some reason ignoring the ethernet
device _PRW information so it does not suffer this issue.
Does anyone have suggestions for how Linux should work with this?
What logic should we use to ignore the _PRW in this case, or how can
we quirk it?
Also, is there a standard behaviour defined for ethernet drivers
regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
if it believes the hardware is capable of it, but other ethernet
drivers seem to default to WOL off. (I don't expect users of the
affected consumer laptops here to care about WOL support.)
Daniel
[GIT PULL] HID fixes
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus to receive HID subsystem fixes = - buffer management size fix for i2c-hid driver, from Adrian Salido - tool ID regression fixes for Wacom driver from Jason Gerecke - a few small assorted fixes and a few device ID additions = Thanks. Aaron Armstrong Skomra (1): HID: wacom: leds: Don't try to control the EKR's read-only LEDs Adrian Salido (1): HID: i2c-hid: allocate hid buffers for real worst case Dmitry Torokhov (1): HID: hidraw: fix power sequence when closing device Hans de Goede (1): HID: multitouch: Fix system-control buttons not working Jason Gerecke (5): HID: wacom: Properly report negative values from Intuos Pro 2 Bluetooth HID: wacom: Correct coordinate system of touchring and pen twist HID: wacom: generic: Send MSC_SERIAL and ABS_MISC when leaving prox HID: wacom: generic: Clear ABS_MISC when tool leaves proximity HID: wacom: Always increment hdev refcount within wacom_get_hdev_data Kai-Heng Feng (1): Revert "HID: multitouch: Support ALPS PTP stick with pid 0x120A" Lyude (1): HID: rmi: Make sure the HID device is opened on resume Nicholas Bishop (1): HID: add multi-input quirk for IDC6680 touchscreen Pavel Tatashin (1): HID: multitouch: support buttons and trackpoint on Lenovo X1 Tab Gen2 Ping Cheng (1): HID: wacom: bits shifted too much for 9th and 10th buttons Shrirang Bagul (1): HID: multitouch: Support ALPS PTP stick with pid 0x120A drivers/hid/hid-ids.h | 2 + drivers/hid/hid-multitouch.c| 7 +++ drivers/hid/hid-rmi.c | 13 +++-- drivers/hid/hidraw.c| 2 +- drivers/hid/i2c-hid/i2c-hid.c | 3 +- drivers/hid/usbhid/hid-quirks.c | 1 + drivers/hid/wacom_sys.c | 7 ++- drivers/hid/wacom_wac.c | 110 8 files changed, 118 insertions(+), 27 deletions(-) -- Jiri Kosina SUSE Labs
[PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
MTU2 multi-function/multi-channel timer/counter is not enabled for
GR-Peach board. The timer is used as clock event source to schedule
wake-ups, and without this enabled all sleeps not performed through busy
waiting hang the board.
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 20309ac..ad6a627 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -78,6 +78,10 @@
clock-frequency = <4800>;
};
+&mtu2 {
+ status = "okay";
+};
+
&scif2 {
pinctrl-names = "default";
pinctrl-0 = <&scif2_pins>;
--
2.7.4
Re: [PATCH v4 00/14] Introduce support for Dell SMBIOS over WMI
On Thu, Oct 5, 2017 at 3:09 AM, Darren Hart wrote: > On Wed, Oct 04, 2017 at 05:48:26PM -0500, Mario Limonciello wrote: >> >> NOTE: This patch is intended to go on top of the 6 patches already in >> Darren's review tree. > > I pushed these to for-next today, they should be available in linux-next > shortly. Not before beginning of November. P.S. This month no linux-next. -- With Best Regards, Andy Shevchenko
Re: [PATCH v6 4/6] lib/dlock-list: Make sibling CPUs share the same linked list
On Wed 04-10-17 17:20:05, Waiman Long wrote:
> int alloc_dlock_list_heads(struct dlock_list_heads *dlist)
> {
> - int idx;
> + int idx, cnt = nr_dlock_lists ? nr_dlock_lists : nr_cpu_ids;
Hum, is this there for the case where alloc_dlock_list_heads() is called
before nr_dlock_lists is initialized? But how can the dlist be used later
when it has larger number of lists and you don't know how many?
Honza
--
Jan Kara
SUSE Labs, CR
[PATCH 1/3] ARM: dts: gr-peach: Fix 'leds' node name indent
Fix 'leds' node name indent as it was wrongly aligned.
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index f2ddd11..20309ac 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -53,7 +53,7 @@
};
};
-leds {
+ leds {
status = "okay";
compatible = "gpio-leds";
--
2.7.4
[PATCH 0/3] ARM: dts: gr-peach: Mix DTS fixes/updates
Hello, this series includes three patches for GR-Peach DTS. The first, very trivial one is the re-proposal of the already sent patch, with the commit message updated as suggested by Sergei. The second just enables the Multi-function timer/counter unit which was disabled and is actually used for timer event generations and wake-ups. After enabling the MTU unit, ETHER is now working properly, so I am re-proposing this patch, which had been left out from previous gr-peach DTS series because the interface was not working correctly. Thanks j Jacopo Mondi (3): ARM: dts: gr-peach: Fix 'leds' node name indent ARM: dts: gr-peach: Enable MTU2 timer pulse unit ARM: dts: gr-peach: Add ETHER pin group arch/arm/boot/dts/r7s72100-gr-peach.dts | 44 - 1 file changed, 43 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
Add pin configuration subnode for ETHER pin group and enable the interface.
Signed-off-by: Jacopo Mondi
---
arch/arm/boot/dts/r7s72100-gr-peach.dts | 38 +
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index ad6a627..8b5a2c5 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -68,6 +68,28 @@
/* P6_2 as RxD2; P6_3 as TxD2 */
pinmux = , ;
};
+
+ ether_pins: ether {
+ /* Ethernet on Ports 1,3,5,10 */
+ pinmux = , /* P1_14 = ET_COL */
+, /* P3_0 = ET_TXCLK */
+, /* P3_3 = ET_MDIO */
+, /* P3_4 = ET_RXCLK */
+, /* P3_5 = ET_RXER */
+, /* P3_6 = ET_RXDV */
+, /* P5_9 = ET_MDC*/
+, /* P10_1 = ET_TXER */
+, /* P10_2 = ET_TXEN */
+, /* P10_3 = ET_CRS */
+, /* P10_4 = ET_TXD0 */
+, /* P10_5 = ET_TXD1 */
+, /* P10_6 = ET_TXD2 */
+, /* P10_7 = ET_TXD3 */
+, /* P10_8 = ET_RXD0 */
+, /* P10_9 = ET_RXD1 */
+,/* P10_10 = ET_RXD2 */
+;/* P10_11 = ET_RXD3 */
+ };
};
&extal_clk {
@@ -88,3 +110,19 @@
status = "okay";
};
+
+ðer {
+ pinctrl-names = "default";
+ pinctrl-0 = <ðer_pins>;
+
+ status = "okay";
+
+ reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <5>;
+
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
--
2.7.4
Re: [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi wrote:
> MTU2 multi-function/multi-channel timer/counter is not enabled for
> GR-Peach board. The timer is used as clock event source to schedule
> wake-ups, and without this enabled all sleeps not performed through busy
> waiting hang the board.
>
> Signed-off-by: Jacopo Mondi
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
On Wed 04-10-17 14:59:06, Johannes Weiner wrote:
> This reverts commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb and
> commit 171012f561274784160f666f8398af8b42216e1f.
>
> 5d17a73a2ebe ("vmalloc: back off when the current task is killed")
> made all vmalloc allocations from a signal-killed task fail. We have
> seen crashes in the tty driver from this, where a killed task exiting
> tries to switch back to N_TTY, fails n_tty_open because of the vmalloc
> failing, and later crashes when dereferencing tty->disc_data.
>
> Arguably, relying on a vmalloc() call to succeed in order to properly
> exit a task is not the most robust way of doing things. There will be
> a follow-up patch to the tty code to fall back to the N_NULL ldisc.
>
> But the justification to make that vmalloc() call fail like this isn't
> convincing, either. The patch mentions an OOM victim exhausting the
> memory reserves and thus deadlocking the machine. But the OOM killer
> is only one, improbable source of fatal signals. It doesn't make sense
> to fail allocations preemptively with plenty of memory in most cases.
>
> The patch doesn't mention real-life instances where vmalloc sites
> would exhaust memory, which makes it sound more like a theoretical
> issue to begin with. But just in case, the OOM access to memory
> reserves has been restricted on the allocator side in cd04ae1e2dc8
> ("mm, oom: do not rely on TIF_MEMDIE for memory reserves access"),
> which should take care of any theoretical concerns on that front.
>
> Revert this patch, and the follow-up that suppresses the allocation
> warnings when we fail the allocations due to a signal.
>
> Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/vmalloc.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 8a43db6284eb..673942094328 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1695,11 +1695,6 @@ static void *__vmalloc_area_node(struct vm_struct
> *area, gfp_t gfp_mask,
> for (i = 0; i < area->nr_pages; i++) {
> struct page *page;
>
> - if (fatal_signal_pending(current)) {
> - area->nr_pages = i;
> - goto fail_no_warn;
> - }
> -
> if (node == NUMA_NO_NODE)
> page = alloc_page(alloc_mask|highmem_mask);
> else
> @@ -1723,7 +1718,6 @@ static void *__vmalloc_area_node(struct vm_struct
> *area, gfp_t gfp_mask,
> warn_alloc(gfp_mask, NULL,
> "vmalloc: allocation failure, allocated %ld of %ld
> bytes",
> (area->nr_pages*PAGE_SIZE), area->size);
> -fail_no_warn:
> vfree(area->addr);
> return NULL;
> }
> --
> 2.14.1
--
Michal Hocko
SUSE Labs
[PATCH V10 13/15] mmc: block: Add CQE and blk-mq support
Add CQE support to the block driver, including:
- optionally using DCMD for flush requests
- "manually" issuing discard requests
- issuing read / write requests to the CQE
- supporting block-layer timeouts
- handling recovery
- supporting re-tuning
CQE offers 25% - 50% better random multi-threaded I/O. There is a slight
(e.g. 2%) drop in sequential read speed but no observable change to sequential
write.
CQE automatically sends the commands to complete requests. However it only
supports reads / writes and so-called "direct commands" (DCMD). Furthermore
DCMD is limited to one command at a time, but discards require 3 commands.
That makes issuing discards through CQE very awkward, but some CQE's don't
support DCMD anyway. So for discards, the existing non-CQE approach is
taken, where the mmc core code issues the 3 commands one at a time i.e.
mmc_erase(). Where DCMD is used, is for issuing flushes.
For host controllers without CQE support, blk-mq support is extended to
synchronous reads/writes or, if the host supports CAP_WAIT_WHILE_BUSY,
asynchonous reads/writes. The advantage of asynchronous reads/writes is
that it allows the preparation of the next request while the current
request is in progress.
Signed-off-by: Adrian Hunter
---
Changes since V9:
- reinstate mq support for REQ_OP_DRV_IN/OUT that was removed because
it was incorrectly assumed to be handled by the rpmb character device
- don't check for rpmb block device anymore
drivers/mmc/core/block.c | 739 ++-
drivers/mmc/core/block.h | 8 +
drivers/mmc/core/queue.c | 425 +--
drivers/mmc/core/queue.h | 52
4 files changed, 1194 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index ea80ff4cd7f9..51a7aea2caea 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -112,6 +112,7 @@ struct mmc_blk_data {
#define MMC_BLK_WRITE BIT(1)
#define MMC_BLK_DISCARDBIT(2)
#define MMC_BLK_SECDISCARD BIT(3)
+#define MMC_BLK_CQE_RECOVERY BIT(4)
/*
* Only set in main mmc_blk_data associated
@@ -1264,7 +1265,10 @@ static void mmc_blk_issue_drv_op(struct mmc_queue *mq,
struct request *req)
break;
}
mq_rq->drv_op_result = ret;
- blk_end_request_all(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
+ if (req->mq_ctx)
+ blk_mq_end_request(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
+ else
+ blk_end_request_all(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
}
static void mmc_blk_issue_discard_rq(struct mmc_queue *mq, struct request *req)
@@ -1307,7 +1311,10 @@ static void mmc_blk_issue_discard_rq(struct mmc_queue
*mq, struct request *req)
else
mmc_blk_reset_success(md, type);
fail:
- blk_end_request(req, status, blk_rq_bytes(req));
+ if (req->mq_ctx)
+ blk_mq_end_request(req, status);
+ else
+ blk_end_request(req, status, blk_rq_bytes(req));
}
static void mmc_blk_issue_secdiscard_rq(struct mmc_queue *mq,
@@ -1377,7 +1384,10 @@ static void mmc_blk_issue_secdiscard_rq(struct mmc_queue
*mq,
if (!err)
mmc_blk_reset_success(md, type);
out:
- blk_end_request(req, status, blk_rq_bytes(req));
+ if (req->mq_ctx)
+ blk_mq_end_request(req, status);
+ else
+ blk_end_request(req, status, blk_rq_bytes(req));
}
static void mmc_blk_issue_flush(struct mmc_queue *mq, struct request *req)
@@ -1387,7 +1397,10 @@ static void mmc_blk_issue_flush(struct mmc_queue *mq,
struct request *req)
int ret = 0;
ret = mmc_flush_cache(card);
- blk_end_request_all(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
+ if (req->mq_ctx)
+ blk_mq_end_request(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
+ else
+ blk_end_request_all(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
}
/*
@@ -1413,15 +1426,18 @@ static inline void mmc_apply_rel_rw(struct
mmc_blk_request *brq,
}
}
-#define CMD_ERRORS \
- (R1_OUT_OF_RANGE | /* Command argument out of range */ \
-R1_ADDRESS_ERROR | /* Misaligned address */\
+#define CMD_ERRORS_EXCL_OOR\
+ (R1_ADDRESS_ERROR | /* Misaligned address */\
R1_BLOCK_LEN_ERROR | /* Transferred block length incorrect */\
R1_WP_VIOLATION | /* Tried to write to protected block */ \
R1_CARD_ECC_FAILED | /* Card ECC failed */ \
R1_CC_ERROR | /* Card controller error */ \
R1_ERROR) /* General/unknown error */
+#define CMD_ERRORS \
+ (CMD_ERRORS_EXCL_OOR |
Re: [PATCH v2 14/17] phy: qcom-qusb2: Set vbus sw-override signal in device mode
Hi Jack,
On 9/28/2017 10:23 PM, Jack Pham wrote:
> Hi Manu,
>
> On Thu, Sep 28, 2017 at 09:30:38AM +0530, Manu Gautam wrote:
>> On 9/28/2017 12:46 AM, Jack Pham wrote:
>>> On Wed, Sep 27, 2017 at 10:57:41AM -0700, Jack Pham wrote:
On Wed, Sep 27, 2017 at 02:29:10PM +0530, Manu Gautam wrote:
> VBUS signal coming from PHY must be asserted in device for
> controller to start operation or assert pull-up. For some
> platforms where VBUS line is not connected to PHY there is
> HS_PHY_CTRL register in QSCRATCH wrapper that can be used
> by software to override VBUS signal going to controller.
>
> Signed-off-by: Manu Gautam
> ---
>
> +static int qusb2_phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct qusb2_phy *qphy = phy_get_drvdata(phy);
> +
> + qphy->mode = mode;
> +
> + /* Update VBUS override in qscratch register */
> + if (qphy->qscratch_base) {
> + if (mode == PHY_MODE_USB_DEVICE)
> + qusb2_setbits(qphy->qscratch_base, QSCRATCH_HS_PHY_CTRL,
> + UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
> + else
> + qusb2_clrbits(qphy->qscratch_base, QSCRATCH_HS_PHY_CTRL,
> + UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
Wouldn't this be better off handled in the controller glue driver? Two
reasons I think this patch is unattractive:
- qscratch_base is part of the controller's register space. Your later
patch 16/17 ("phy: qcom-qmp: Override lane0_power_present signal in
device mode") does a similar thing and hence both drivers have to
ioremap() the same register resource while at the same time avoiding
request_mem_region() (called by devm_ioremap_resource) to allow it to
be mapped in both places.
>> Right. There is one more reason why qusb2 driver needs qscratch:
>> - During runtime suspend, it has to check linestate to set correct polarity
>> for dp/dm
>> wakeup interrupt in order to detect disconnect/resume ion LS and FS/HS
>> modes.
> Ugh, oh yeah. The way I understand we did it in our downstream driver
> is still to have the controller driver read the linestate but then pass
> the information via additional set_mode() flags which the PHY driver
> could use to correctly arm the interrupt trigger polarity.
>
> An alternative would be to access a couple of the debug QUSB2PHY
> registers that also provide a reading of the current UTMI linestate. The
> HPG mentions them vaguely, and I can't remember if we tested that
> interface or not. Assuming it works, would that be preferable to reading
> a non-PHY register here?
it looks like newer QUSB2 PHY doesn't have a register to read linestate.
QSCRATCH is the only option.
However, setting dp/dm wakeup interrupt polarity based on current linestate
isn't perfect either. It could race with any change in linestate while it was
being
read, resulting in missed wakeup interrupt.
Same is the case with QMP PHY when trying to check for RX terminations on
suspend.
IMO PHY driver should get this info from platform glue or controller driver.
E.g. current speed -> SS, HS/FS, LS or NONE (if not in session).
Kishon,
What would you suggest here?
Should we add new calls e.g. phy_get/set_current_speed like::
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 78bb0d7..41d9ec2 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -29,6 +29,14 @@ enum phy_mode {
PHY_MODE_USB_OTG,
};
+enum phy_speed {
+ PHY_SPEED_INVALID,
+ PHY_SPEED_USB_LS,
+ PHY_SPEED_USB_FS_HS,
+ PHY_SPEED_USB_SS,
+};
+
/**
* struct phy_ops - set of function pointers for performing phy operations
* @init: operation to be performed for initializing phy
@@ -45,6 +53,7 @@ struct phy_ops {
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
int (*set_mode)(struct phy *phy, enum phy_mode mode);
+ int (*set_speed)(struct phy *phy, enum phy_speed speed);
int (*reset)(struct phy *phy);
struct module *owner;
};
- VBUS override bit becomes asserted simply because the mode is changed
to device mode but this is irrespective of the actual VBUS state. This
could break some test setups which perform a logical disconnect by
switching off/on VBUS while leaving data lines connected. Controller
would go merrily along thinking it is still attached to the host.
Instead maybe this could be tied to EXTCON_USB handling in the glue
driver; though it would need to be an additional notifier on top of
dwc3/drd.c which already handles extcon for host/device mode.
>> Yes, dwc3/drd.c currently deals with only EXTCON_USB_HOST. So, for platforms
>> where role swap happens using only Vbus or single GPIO this should take care
>> of.
>>
>>
>>> That is to say, we'd probably need to split
Re: [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
Hi Jacopo,
On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi wrote:
> Add pin configuration subnode for ETHER pin group and enable the interface.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -88,3 +110,19 @@
>
> status = "okay";
> };
> +
> +ðer {
> + pinctrl-names = "default";
> + pinctrl-0 = <ðer_pins>;
> +
> + status = "okay";
> +
> + reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> + reset-delay-us = <5>;
I'm afraid the PHY people (not CCed ;-) will want you to move these reset
properties to the phy subnode these days, despite
Documentation/devicetree/bindings/net/mdio.txt...
> +
> + renesas,no-ether-link;
> + phy-handle = <&phy0>;
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] net: qcom/emac: make function emac_isr static
From: Colin Ian King
The function emac_isr is local to the source and does not need to
be in global scope, so make it static.
Cleans up sparse warnings:
symbol 'emac_isr' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/qualcomm/emac/emac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c
b/drivers/net/ethernet/qualcomm/emac/emac.c
index 759543512117..f477ba29c569 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -130,7 +130,7 @@ static int emac_start_xmit(struct sk_buff *skb, struct
net_device *netdev)
return emac_mac_tx_buf_send(adpt, &adpt->tx_q, skb);
}
-irqreturn_t emac_isr(int _irq, void *data)
+static irqreturn_t emac_isr(int _irq, void *data)
{
struct emac_irq *irq = data;
struct emac_adapter *adpt =
--
2.14.1
Re: [PATCH] MAINTAINERS: Add git repository to Renesas clock driver section
On Wed, Oct 04, 2017 at 01:34:24PM +0200, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 61d77c8037a1faf9..d23f4fba728d091a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11476,6 +11476,7 @@ F:include/linux/rpmsg/ > RENESAS CLOCK DRIVERS > M: Geert Uytterhoeven > L: linux-renesas-...@vger.kernel.org > +T: git > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git > clk-renesas > S: Supported > F: drivers/clk/renesas/ > > -- > 2.7.4 >
Re: [PATCH] MAINTAINERS: Add git repository to Renesas pinctrl driver section
On Wed, Oct 04, 2017 at 01:35:12PM +0200, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6e018e720152c98c..61d77c8037a1faf9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10675,6 +10675,7 @@ PIN CONTROLLER - RENESAS > M: Laurent Pinchart > M: Geert Uytterhoeven > L: linux-renesas-...@vger.kernel.org > +T: git > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git sh-pfc > S: Maintained > F: drivers/pinctrl/sh-pfc/ > > -- > 2.7.4 >
[PATCH v2] perf callchain: Compare dsos (as well) for CCKEY_FUNCTION
Two functions from different binaries can have same start
address. Thus, comparing only start address in match_chain()
leads to inconsistent callchains. Fix this by adding a check
for dsos as well.
Ex, https://www.spinics.net/lists/linux-perf-users/msg04067.html
Reported-by: Alexander Pozdneev
Signed-off-by: Ravi Bangoria
---
Changes in v2:
- Remove unnecessary checks for 'map'
tools/perf/util/callchain.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index be09d77..a971caf 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -685,6 +685,8 @@ static enum match_result match_chain(struct
callchain_cursor_node *node,
{
struct symbol *sym = node->sym;
u64 left, right;
+ struct dso *left_dso = NULL;
+ struct dso *right_dso = NULL;
if (callchain_param.key == CCKEY_SRCLINE) {
enum match_result match = match_chain_srcline(node, cnode);
@@ -696,12 +698,14 @@ static enum match_result match_chain(struct
callchain_cursor_node *node,
if (cnode->ms.sym && sym && callchain_param.key == CCKEY_FUNCTION) {
left = cnode->ms.sym->start;
right = sym->start;
+ left_dso = cnode->ms.map->dso;
+ right_dso = node->map->dso;
} else {
left = cnode->ip;
right = node->ip;
}
- if (left == right) {
+ if (left == right && left_dso == right_dso) {
if (node->branch) {
cnode->branch_count++;
--
1.8.3.1
Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
On Thu 05-10-17 02:08:48, Yang Shi wrote:
>
>
> On 10/4/17 7:27 AM, Michal Hocko wrote:
> > On Wed 04-10-17 02:06:17, Yang Shi wrote:
> > > +static bool is_dump_unreclaim_slabs(void)
> > > +{
> > > + unsigned long nr_lru;
> > > +
> > > + nr_lru = global_node_page_state(NR_ACTIVE_ANON) +
> > > + global_node_page_state(NR_INACTIVE_ANON) +
> > > + global_node_page_state(NR_ACTIVE_FILE) +
> > > + global_node_page_state(NR_INACTIVE_FILE) +
> > > + global_node_page_state(NR_ISOLATED_ANON) +
> > > + global_node_page_state(NR_ISOLATED_FILE) +
> > > + global_node_page_state(NR_UNEVICTABLE);
> > > +
> > > + return (global_node_page_state(NR_SLAB_UNRECLAIMABLE) > nr_lru);
> > > +}
> >
> > I am sorry I haven't pointed this earlier (I was following only half
> > way) but this should really be memcg aware. You are checking only global
> > counters. I do not think it is an absolute must to provide per-memcg
> > data but you should at least check !is_memcg_oom(oc).
>
> BTW, I saw there is already such check in dump_header that looks like the
> below code:
>
> if (oc->memcg)
> mem_cgroup_print_oom_info(oc->memcg, p);
> else
> show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
>
> I'm supposed it'd better to replace "oc->memcg" to "is_memcg_oom(oc)" since
> they do the same check and "is_memcg_oom" interface sounds preferable.
Yes, is_memcg_oom is better
> Then I'm going to move unreclaimable slabs dump to the "else" block.
makes sense.
--
Michal Hocko
SUSE Labs
Re: [PATCH v6 5/6] lib/dlock-list: Enable faster lookup with hashing
On Wed 04-10-17 17:20:06, Waiman Long wrote: > Insertion and deletion is relatively cheap and mostly contention > free for dlock-list. Lookup, on the other hand, can be rather costly > because all the lists in a dlock-list will have to be iterated. > > Currently dlock-list insertion is based on the cpu that the task is > running on. So a given object can be inserted into any one of the > lists depending on what the current cpu is. > > This patch provides an alternative way of list selection. The caller > can provide a object context which will be hashed to one of the list > in a dlock-list. The object can then be added into that particular > list. Lookup can be done by iterating elements in the provided list > only instead of all the lists in a dlock-list. > > The new APIs are: > > struct dlock_list_head *dlock_list_hash(struct dlock_list_heads *, void *); > void dlock_list_add(struct dlock_list_node *, struct dlock_list_head *); > > Signed-off-by: Waiman Long OK, this makes sense but do you have any particular user in mind? In particular I'm not sure how big advantage this API brings over an existing one in include/linux/list_bl.h. Sure it's a tradeoff between bitlock / spinlock but is there a user where it matters? Honza -- Jan Kara SUSE Labs, CR
Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
On Wed 04-10-17 19:18:21, Johannes Weiner wrote: > On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote: [...] > > You don't think they should be backported into -stables? > > Good point. For this one, it makes sense to CC stable, for 4.11 and > up. The second patch is more of a fortification against potential > future issues, and probably shouldn't go into stable. I am not against. It is true that the memory reserves depletion fix was theoretical because I haven't seen any real life bug. I would argue that the more robust allocation failure behavior is a stable candidate as well, though, because the allocation can fail regardless of the vmalloc revert. It is less likely but still possible. -- Michal Hocko SUSE Labs
Re: [PATCH] s390: qdio: Convert timers to use timer_setup()
On Wed, 4 Oct 2017, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> -void qdio_outbound_timer(unsigned long data)
> +void qdio_outbound_timer(struct timer_list *t)
> {
> - struct qdio_q *q = (struct qdio_q *)data;
> + struct qdio_q *q = from_timer(q, t, o.out.timer);
^
this should be u.out.timer
Will be applied to s390/linux.git
Thanks,
Sebastian
Re: stable-rc build: 132 warnings 0 failures (stable-rc/v4.9.52-65-gaceea42)
On Wed, Oct 04, 2017 at 04:39:06PM +0200, Arnd Bergmann wrote:
> On Wed, Oct 4, 2017 at 9:50 AM, Olof's autobuilder wrote:
>
> It seems a couple of warnings are now present due to the use of gcc-7,
> here are the respective patches we want backported:
>
> > Warnings:
> >
> > 1 include/asm-generic/bitops/non-atomic.h:105:34: warning: 'shadow'
> > may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> f6aafac184a3 ("IB/qib: fix false-postive maybe-uninitialized warning")
>
> > 4 arch/arm/mach-bcm/bcm_kona_smc.c:36:34: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
> > 5 arch/arm/mach-omap2/prm_common.c:716:34: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
> > 5 arch/arm/mach-omap2/vc.c:562:35: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
> > 7 arch/arm/mach-spear/time.c:207:34: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
> > 8 arch/arm/mach-at91/pm.c:338:34: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
> > 2 arch/arm/mach-cns3xxx/core.c:349:36: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
>
> 0527873b29b0 ("ARM: remove duplicate 'const' annotations'")
>
> > 2 sound/soc/codecs/rt5514.c:398:14: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
>
> 03ba791df98d ("ASoC: rt5514: fix gcc-7 warning")
>
> > 2 sound/soc/codecs/rt5659.c:1153:14: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
>
> eae39b5f4269 ("ASoC: rt5659: drop double const")
>
> > 2 sound/soc/codecs/rt5660.c:529:14: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
> > 2 sound/soc/codecs/rt5660.c:532:14: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
>
> 4281fcc02ed9 ("ASoC: rt5660: remove double const")
>
> > 3 sound/pci/au88x0/au88x0_core.c:2304:68: warning: 'mix[0]' may be
> > used uninitialized in this function [-Wmaybe-uninitialized]
> > 3 sound/pci/au88x0/au88x0_core.c:2305:58: warning: 'src[0]' may be
> > used uninitialized in this function [-Wmaybe-uninitialized]
>
> 13f99ebdd602 ("ALSA: au88x0: avoid theoretical uninitialized access")
Thanks for these, all now queued up.
greg k-h
[PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs with DPAA2 (DataPath Acceleration Architecture v2). The driver manages switch objects discovered on the fsl-mc bus. A description of the driver can be found in the associated README file. The patchset consists of: * A set of libraries containing APIs for configuring and controlling Management Complex (MC) switch objects * The DPAA2 Ethernet Switch driver * Patch adding ethtool support Limitations: * no support for control traffic to/from CPU * only DPSW ports can be added to a bridge Changelog: v2: addressed comments from Bogdan P. v3: addressed comments from Andrew L. (patch 3/6 updated) Razvan Stefanescu (6): staging: fsl-dpaa2/ethsw: Add APIs for DPSW object staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver staging: fsl-dpaa2/ethsw: Add ethtool support staging: fsl-dpaa2/ethsw: Add maintainer for Ethernet Switch driver staging: fsl-dpaa2/ethsw: Add README staging: fsl-dpaa2/ethsw: Add TODO MAINTAINERS |6 + drivers/staging/fsl-dpaa2/Kconfig |8 + drivers/staging/fsl-dpaa2/Makefile |1 + drivers/staging/fsl-dpaa2/ethsw/Makefile|7 + drivers/staging/fsl-dpaa2/ethsw/README | 106 ++ drivers/staging/fsl-dpaa2/ethsw/TODO| 14 + drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h | 371 ++ drivers/staging/fsl-dpaa2/ethsw/dpsw.c | 1147 + drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 611 + drivers/staging/fsl-dpaa2/ethsw/ethsw-ethtool.c | 206 +++ drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 1532 +++ drivers/staging/fsl-dpaa2/ethsw/ethsw.h | 90 ++ 12 files changed, 4099 insertions(+) create mode 100644 drivers/staging/fsl-dpaa2/ethsw/Makefile create mode 100644 drivers/staging/fsl-dpaa2/ethsw/README create mode 100644 drivers/staging/fsl-dpaa2/ethsw/TODO create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw.c create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw.h create mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw-ethtool.c create mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw.c create mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw.h -- 1.9.1
[PATCH v3 2/6] staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver
Introduce the DPAA2 Ethernet Switch driver, which manages Datapath Switch
(DPSW) objects discovered on the MC bus.
Suggested-by: Alexandru Marginean
Signed-off-by: Razvan Stefanescu
---
Changelog:
v2:
- fix PVID cleanup in ethsw_port_add_vlan()
- rename err2 to ret in ethsw_port_add/del_vlan()
- avoid duplicate code in ethsw_probe()
- move destroy_workqueue to ethsw_takedown()
- have a function for unregistering notifiers
- above changes implement review comments for v1 from Bogdan P.
v3:
- no changes
drivers/staging/fsl-dpaa2/ethsw/Makefile |2 +-
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 1531 ++
drivers/staging/fsl-dpaa2/ethsw/ethsw.h | 88 ++
3 files changed, 1620 insertions(+), 1 deletion(-)
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw.c
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw.h
diff --git a/drivers/staging/fsl-dpaa2/ethsw/Makefile
b/drivers/staging/fsl-dpaa2/ethsw/Makefile
index db137f7..a6d72d1 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/Makefile
+++ b/drivers/staging/fsl-dpaa2/ethsw/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_FSL_DPAA2_ETHSW) += dpaa2-ethsw.o
-dpaa2-ethsw-objs := dpsw.o
+dpaa2-ethsw-objs := ethsw.o dpsw.o
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
new file mode 100644
index 000..f45e5bb
--- /dev/null
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -0,0 +1,1531 @@
+/* Copyright 2014-2016 Freescale Semiconductor Inc.
+ * Copyright 2017 NXP
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of the above-listed copyright holders nor the
+ * names of any contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include "../../fsl-mc/include/mc.h"
+
+#include "ethsw.h"
+
+static struct workqueue_struct *ethsw_owq;
+
+/* Minimal supported DPSW version */
+#define DPSW_MIN_VER_MAJOR 8
+#define DPSW_MIN_VER_MINOR 0
+
+#define DEFAULT_VLAN_ID1
+
+static int ethsw_add_vlan(struct ethsw_core *ethsw, u16 vid)
+{
+ int err;
+
+ struct dpsw_vlan_cfgvcfg = {
+ .fdb_id = 0,
+ };
+
+ if (ethsw->vlans[vid]) {
+ dev_err(ethsw->dev, "VLAN already configured\n");
+ return -EEXIST;
+ }
+
+ err = dpsw_vlan_add(ethsw->mc_io, 0,
+ ethsw->dpsw_handle, vid, &vcfg);
+ if (err) {
+ dev_err(ethsw->dev, "dpsw_vlan_add err %d\n", err);
+ return err;
+ }
+ ethsw->vlans[vid] = ETHSW_VLAN_MEMBER;
+
+ return 0;
+}
+
+static int ethsw_port_add_vlan(struct ethsw_port_priv *port_priv,
+ u16 vid, u16 flags)
+{
+ struct ethsw_core *ethsw = port_priv->ethsw_data;
+ struct net_device *netdev = port_priv->netdev;
+ struct dpsw_vlan_if_cfg vcfg;
+ bool is_oper;
+ int err, ret;
+
+ if (port_priv->vlans[vid]) {
+ netdev_warn(netdev, "VLAN %d already configured\n", vid);
+ return -EEXIST;
+ }
+
+ vcfg.num_ifs = 1;
+ vcfg.if_id[0] = port_priv->idx;
+ err = dpsw_vlan_add_if(ethsw->mc_io, 0, ethsw->dpsw_handle, vid, &vcfg);
+ if (err) {
+ netdev_err(netdev, "d
Re: [PATCH] irqchip/renesas-intc-irqpin: Use of_device_get_match_data() helper
On Wed, Oct 04, 2017 at 02:17:58PM +0200, Geert Uytterhoeven wrote: > Use the of_device_get_match_data() helper instead of open coding. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman
[PATCH v3 5/6] staging: fsl-dpaa2/ethsw: Add README
Add a README file describing the driver architecture, components and interfaces. Signed-off-by: Razvan Stefanescu --- Changelog: v2: - no changes v3: - no changes drivers/staging/fsl-dpaa2/ethsw/README | 106 + 1 file changed, 106 insertions(+) create mode 100644 drivers/staging/fsl-dpaa2/ethsw/README diff --git a/drivers/staging/fsl-dpaa2/ethsw/README b/drivers/staging/fsl-dpaa2/ethsw/README new file mode 100644 index 000..f6fc07f --- /dev/null +++ b/drivers/staging/fsl-dpaa2/ethsw/README @@ -0,0 +1,106 @@ +DPAA2 Ethernet Switch driver + + +This file provides documentation for the DPAA2 Ethernet Switch driver + + +Contents + + Supported Platforms + Architecture Overview + Creating an Ethernet Switch + Features + + + Supported Platforms +=== +This driver provides networking support for Freescale LS2085A, LS2088A +DPAA2 SoCs. + + +Architecture Overview += +The Ethernet Switch in the DPAA2 architecture consists of several hardware +resources that provide the functionality. These are allocated and +configured via the Management Complex (MC) portals. MC abstracts most of +these resources as DPAA2 objects and exposes ABIs through which they can +be configured and controlled. + +For a more detailed description of the DPAA2 architecture and its object +abstractions see: + drivers/staging/fsl-mc/README.txt + +The Ethernet Switch is built on top of a Datapath Switch (DPSW) object. + +Configuration interface: + + - + | DPAA2 Switch driver | + - + . + . + -- + | DPSW API | + -- + . software + = . == + . hardware + - + | MC hardware portals | + - + . + . + -- +| DPSW | + -- + +Driver uses the switch device driver model and exposes each switch port as +a network interface, which can be included in a bridge. Traffic switched +between ports is offloaded into the hardware. Exposed network interfaces +are not used for I/O, they are used just for configuration. This +limitation is going to be addressed in the future. + +The DPSW can have ports connected to DPNIs or to PHYs via DPMACs. + + + [ethA] [ethB] [ethC] [ethD] [ethE] [ethF] +: : : : : : +: : : : : : +[eth drv] [eth drv] [ethsw drv ] +: : : : : :kernel + +: : : : : :hardware + [DPNI] [DPNI] [= DPSW =] +| | | | | | +| -- | [DPMAC][DPMAC] + ---| | +| | + [PHY] [PHY] + +For a more detailed description of the Ethernet switch device driver model +see: + Documentation/networking/switchdev.txt + +Creating an Ethernet Switch +=== +A device is created for the switch objects probed on the MC bus. Each DPSW +has a number of properties which determine the configuration options and +associated hardware resources. + +A DPSW object (and the other DPAA2 objects needed for a DPAA2 switch) can +be added to a container on the MC bus in one of two ways: statically, +through a Datapath Layout Binary file (DPL) that is parsed by MC at boot +time; or created dynamically at runtime, via the DPAA2 objects APIs. + +Features + +Driver configures DPSW to perform hardware switching offload of +unicast/multicast/broadcast (VLAN tagged or untagged) traffic between its +ports. + +It allows configuration of hardware learning, flooding, multicast groups, +port VLAN configuration and STP state. + +Static entries can be added/removed from the FDB. + +Hardware statistics for each port are provided through ethtool -S option. -- 1.9.1
[PATCH v3 4/6] staging: fsl-dpaa2/ethsw: Add maintainer for Ethernet Switch driver
Signed-off-by: Razvan Stefanescu --- Changelog: v2: - no changes v3: - no changes MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2281af4..cfd4f74 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4297,6 +4297,12 @@ L: linux-kernel@vger.kernel.org S: Maintained F: drivers/staging/fsl-dpaa2/ethernet +DPAA2 ETHERNET SWITCH DRIVER +M: Razvan Stefanescu +L: linux-kernel@vger.kernel.org +S: Maintained +F: drivers/staging/fsl-dpaa2/ethsw + DPT_I2O SCSI RAID DRIVER M: Adaptec OEM Raid Solutions L: linux-s...@vger.kernel.org -- 1.9.1
[PATCH v3 6/6] staging: fsl-dpaa2/ethsw: Add TODO
Add a TODO file describing what needs to be added/changed before the driver can be moved out of staging. Signed-off-by: Razvan Stefanescu --- Changelog: v2: - no changes v3: - no changes drivers/staging/fsl-dpaa2/ethsw/TODO | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 drivers/staging/fsl-dpaa2/ethsw/TODO diff --git a/drivers/staging/fsl-dpaa2/ethsw/TODO b/drivers/staging/fsl-dpaa2/ethsw/TODO new file mode 100644 index 000..d3f12c3 --- /dev/null +++ b/drivers/staging/fsl-dpaa2/ethsw/TODO @@ -0,0 +1,14 @@ +* Add I/O capabilities on switch port netdevices. This will allow control +traffic to reach the CPU. +* Add ACL to redirect control traffic to CPU. +* Add support for displaying learned FDB entries +* MC firmware uprev; the DPAA2 objects used by the Ethernet Switch driver +need to be kept in sync with binary interface changes in MC +* refine README file +* cleanup + +NOTE: At least first three of the above are required before getting the +DPAA2 Ethernet Switch driver out of staging. Another requirement is that +the fsl-mc bus driver is moved to drivers/bus and dpio driver is moved to +drivers/soc (this is required for I/O). + -- 1.9.1
Re: stable-rc build: 6 warnings 0 failures (stable-rc/v3.18.72-22-g11fceae)
On Wed, Oct 04, 2017 at 09:31:25PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 3, 2017 at 2:25 PM, Olof's autobuilder wrote:
>
> > Warnings:
> >
> > 2 drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy':
> > specified size between 18446744071562067968 and 18446744073709551615
> > exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
>
> This was fixed in linux-4.11:
>
> 69d3973af1ac ("[media] ttpci: address stringop overflow warning")
>
> > 4 drivers/staging/nvec/nvec_ps2.c:168:14: warning: duplicate 'const'
> > declaration specifier [-Wduplicate-decl-specifier]
>
> and this was fixed in linux-4.2:
>
> 716baa7b430c ("staging: nvec: remove duplicated const")
>
> Both warnings show up for Olof's build bot in 3.18, but the fixes should
> also apply to the later kernels.
Thanks for these, all now queued up.
greg k-h
[PATCH v3 3/6] staging: fsl-dpaa2/ethsw: Add ethtool support
Add driver information, link details and hardware statistics to be
reported via ethtool -S.
Signed-off-by: Razvan Stefanescu
---
Changelog:
v2:
- no changes
v3:
- removed driver version
drivers/staging/fsl-dpaa2/ethsw/Makefile| 2 +-
drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h | 13 ++
drivers/staging/fsl-dpaa2/ethsw/dpsw.c | 32
drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 32
drivers/staging/fsl-dpaa2/ethsw/ethsw-ethtool.c | 206
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 1 +
drivers/staging/fsl-dpaa2/ethsw/ethsw.h | 2 +
7 files changed, 287 insertions(+), 1 deletion(-)
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw-ethtool.c
diff --git a/drivers/staging/fsl-dpaa2/ethsw/Makefile
b/drivers/staging/fsl-dpaa2/ethsw/Makefile
index a6d72d1..de92cd9 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/Makefile
+++ b/drivers/staging/fsl-dpaa2/ethsw/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_FSL_DPAA2_ETHSW) += dpaa2-ethsw.o
-dpaa2-ethsw-objs := ethsw.o dpsw.o
+dpaa2-ethsw-objs := ethsw.o ethsw-ethtool.o dpsw.o
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
index ddfd820..06b71122 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
@@ -74,6 +74,8 @@
#define DPSW_CMDID_IF_SET_FLOODING DPSW_CMD_ID(0x047)
#define DPSW_CMDID_IF_SET_BROADCAST DPSW_CMD_ID(0x048)
+#define DPSW_CMDID_IF_SET_LINK_CFG DPSW_CMD_ID(0x04C)
+
#define DPSW_CMDID_VLAN_ADD DPSW_CMD_ID(0x060)
#define DPSW_CMDID_VLAN_ADD_IF DPSW_CMD_ID(0x061)
#define DPSW_CMDID_VLAN_ADD_IF_UNTAGGED DPSW_CMD_ID(0x062)
@@ -262,6 +264,17 @@ struct dpsw_cmd_if_set_max_frame_length {
__le16 frame_length;
};
+struct dpsw_cmd_if_set_link_cfg {
+ /* cmd word 0 */
+ __le16 if_id;
+ u8 pad[6];
+ /* cmd word 1 */
+ __le32 rate;
+ __le32 pad1;
+ /* cmd word 2 */
+ __le64 options;
+};
+
struct dpsw_cmd_if_get_link_state {
__le16 if_id;
};
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
b/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
index e65b6f5..f1a1fac 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.c
@@ -383,6 +383,38 @@ int dpsw_get_attributes(struct fsl_mc_io *mc_io,
}
/**
+ * dpsw_if_set_link_cfg() - Set the link configuration.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSW object
+ * @if_id: Interface id
+ * @cfg: Link configuration
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpsw_if_set_link_cfg(struct fsl_mc_io *mc_io,
+u32 cmd_flags,
+u16 token,
+u16 if_id,
+struct dpsw_link_cfg *cfg)
+{
+ struct mc_command cmd = { 0 };
+ struct dpsw_cmd_if_set_link_cfg *cmd_params;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPSW_CMDID_IF_SET_LINK_CFG,
+ cmd_flags,
+ token);
+ cmd_params = (struct dpsw_cmd_if_set_link_cfg *)cmd.params;
+ cmd_params->if_id = cpu_to_le16(if_id);
+ cmd_params->rate = cpu_to_le32(cfg->rate);
+ cmd_params->options = cpu_to_le64(cfg->options);
+
+ /* send command to mc*/
+ return mc_send_command(mc_io, &cmd);
+}
+
+/**
* dpsw_if_get_link_state - Return the link state
* @mc_io: Pointer to MC portal's I/O object
* @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
index 7fa8a61..87369a5 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h
@@ -245,6 +245,38 @@ enum dpsw_action {
};
/**
+ * Enable auto-negotiation
+ */
+#define DPSW_LINK_OPT_AUTONEG 0x0001ULL
+/**
+ * Enable half-duplex mode
+ */
+#define DPSW_LINK_OPT_HALF_DUPLEX 0x0002ULL
+/**
+ * Enable pause frames
+ */
+#define DPSW_LINK_OPT_PAUSE0x0004ULL
+/**
+ * Enable a-symmetric pause frames
+ */
+#define DPSW_LINK_OPT_ASYM_PAUSE 0x0008ULL
+
+/**
+ * struct dpsw_link_cfg - Structure representing DPSW link configuration
+ * @rate: Rate
+ * @options: Mask of available options; use 'DPSW_LINK_OPT_' values
+ */
+struct dpsw_link_cfg {
+ u32 rate;
+ u64 options;
+};
+
+int dpsw_if_set_link_cfg(struct fsl_mc_io *mc_io,
+u32 cmd_flags,
+u16 token,
+u16 if_id,
+struct dpsw_link_cfg *cfg);
+/**
* struct dpsw_link_state - Structure representing DPSW link state
* @rate: Rate
* @options: Mask of avai
Re: [PATCH] HID: hid-multitouch: forward MSC_TIMESTAMP
On Tue, 22 Aug 2017, Nicolas Boichat wrote: > Computes and forwards the device timestamp according to the > specification. > > Many devices use a 16-bit timestamp field, with a resolution > of 100us, therefore rolling around very frequently (every > 6.5 seconds). To make sure there is no ambiguity, the > timestamp reported to the input stack reset to 0 whenever > the time between 2 received events is greater than > MAX_TIMESTAMP_INTERVAL (1 second). > > Signed-off-by: Nicolas Boichat > --- > > Inspired from Benjamin Tissoires's patch here: > https://patchwork.kernel.org/patch/1742181/, and changing the > logic to resynchronize the timestamps to use received time > instead of a potentially more fragile difference between > the 2 deltas. Applied to for-4.15/multitouch. -- Jiri Kosina SUSE Labs
[PATCH v3 1/6] staging: fsl-dpaa2/ethsw: Add APIs for DPSW object
Add the command build/parse APIs for operating on DPSW objects through
the DPAA2 Management Complex.
Signed-off-by: Razvan Stefanescu
---
Changelog:
v2:
- use u8 for en parameter of dpsw_if_set_flooding/broadcast()
v3:
- no changes
drivers/staging/fsl-dpaa2/Kconfig |8 +
drivers/staging/fsl-dpaa2/Makefile |1 +
drivers/staging/fsl-dpaa2/ethsw/Makefile |7 +
drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h | 358 +
drivers/staging/fsl-dpaa2/ethsw/dpsw.c | 1115
drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 579 +++
6 files changed, 2068 insertions(+)
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/Makefile
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw.c
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/dpsw.h
diff --git a/drivers/staging/fsl-dpaa2/Kconfig
b/drivers/staging/fsl-dpaa2/Kconfig
index dfff675..8a508ef 100644
--- a/drivers/staging/fsl-dpaa2/Kconfig
+++ b/drivers/staging/fsl-dpaa2/Kconfig
@@ -16,3 +16,11 @@ config FSL_DPAA2_ETH
---help---
Ethernet driver for Freescale DPAA2 SoCs, using the
Freescale MC bus driver
+
+config FSL_DPAA2_ETHSW
+ tristate "Freescale DPAA2 Ethernet Switch"
+ depends on FSL_DPAA2
+ depends on NET_SWITCHDEV
+ ---help---
+ Driver for Freescale DPAA2 Ethernet Switch. Select
+ BRIDGE to have support for bridge tools.
diff --git a/drivers/staging/fsl-dpaa2/Makefile
b/drivers/staging/fsl-dpaa2/Makefile
index 0836ba8..6cfd76b 100644
--- a/drivers/staging/fsl-dpaa2/Makefile
+++ b/drivers/staging/fsl-dpaa2/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_FSL_DPAA2_ETH)+= ethernet/
+obj-$(CONFIG_FSL_DPAA2_ETHSW) += ethsw/
diff --git a/drivers/staging/fsl-dpaa2/ethsw/Makefile
b/drivers/staging/fsl-dpaa2/ethsw/Makefile
new file mode 100644
index 000..db137f7
--- /dev/null
+++ b/drivers/staging/fsl-dpaa2/ethsw/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the Freescale DPAA2 Ethernet Switch
+#
+
+obj-$(CONFIG_FSL_DPAA2_ETHSW) += dpaa2-ethsw.o
+
+dpaa2-ethsw-objs := dpsw.o
diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
new file mode 100644
index 000..ddfd820
--- /dev/null
+++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw-cmd.h
@@ -0,0 +1,358 @@
+/* Copyright 2013-2016 Freescale Semiconductor Inc.
+ * Copyright 2017 NXP
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of the above-listed copyright holders nor the
+ * names of any contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef __FSL_DPSW_CMD_H
+#define __FSL_DPSW_CMD_H
+
+/* DPSW Version */
+#define DPSW_VER_MAJOR 8
+#define DPSW_VER_MINOR 0
+
+#define DPSW_CMD_BASE_VERSION 1
+#define DPSW_CMD_ID_OFFSET 4
+
+#define DPSW_CMD_ID(id)(((id) << DPSW_CMD_ID_OFFSET) |
DPSW_CMD_BASE_VERSION)
+
+/* Command IDs */
+#define DPSW_CMDID_CLOSEDPSW_CMD_ID(0x800)
+#define DPSW_CMDID_OPEN DPSW_CMD_ID(0x802)
+
+#define DPSW_CMDID_GET_API_VERSION DPSW_CMD_ID(0xa02)
+
+#define DPSW_CMDID_ENABLE DPSW_CMD_ID(0x002)
+#define DPSW_CMDID_DISABLE DPSW_CMD_ID(0x003)
+#define DPSW_CMDID_GET_ATTR DPSW_CMD_ID(0x00
Re: [PATCH 1/3] ARM: dts: gr-peach: Fix 'leds' node name indent
On Thu, Oct 05, 2017 at 10:58:18AM +0200, Jacopo Mondi wrote: > Fix 'leds' node name indent as it was wrongly aligned. > > Signed-off-by: Jacopo Mondi Thanks, applied.
Re: [PATCH v2] perf callchain: Compare dsos (as well) for CCKEY_FUNCTION
On Thu, Oct 05, 2017 at 02:42:34PM +0530, Ravi Bangoria wrote:
> Two functions from different binaries can have same start
> address. Thus, comparing only start address in match_chain()
> leads to inconsistent callchains. Fix this by adding a check
> for dsos as well.
>
> Ex, https://www.spinics.net/lists/linux-perf-users/msg04067.html
>
> Reported-by: Alexander Pozdneev
> Signed-off-by: Ravi Bangoria
> ---
> Changes in v2:
> - Remove unnecessary checks for 'map'
Acked-by: Jiri Olsa
thanks,
jirka
>
> tools/perf/util/callchain.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index be09d77..a971caf 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -685,6 +685,8 @@ static enum match_result match_chain(struct
> callchain_cursor_node *node,
> {
> struct symbol *sym = node->sym;
> u64 left, right;
> + struct dso *left_dso = NULL;
> + struct dso *right_dso = NULL;
>
> if (callchain_param.key == CCKEY_SRCLINE) {
> enum match_result match = match_chain_srcline(node, cnode);
> @@ -696,12 +698,14 @@ static enum match_result match_chain(struct
> callchain_cursor_node *node,
> if (cnode->ms.sym && sym && callchain_param.key == CCKEY_FUNCTION) {
> left = cnode->ms.sym->start;
> right = sym->start;
> + left_dso = cnode->ms.map->dso;
> + right_dso = node->map->dso;
> } else {
> left = cnode->ip;
> right = node->ip;
> }
>
> - if (left == right) {
> + if (left == right && left_dso == right_dso) {
> if (node->branch) {
> cnode->branch_count++;
>
> --
> 1.8.3.1
>
Re: [PATCH 2/3] ARM: dts: gr-peach: Enable MTU2 timer pulse unit
On Thu, Oct 05, 2017 at 11:02:30AM +0200, Geert Uytterhoeven wrote: > On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi > wrote: > > MTU2 multi-function/multi-channel timer/counter is not enabled for > > GR-Peach board. The timer is used as clock event source to schedule > > wake-ups, and without this enabled all sleeps not performed through busy > > waiting hang the board. > > > > Signed-off-by: Jacopo Mondi > > Acked-by: Geert Uytterhoeven Thanks, applied.
Re: [PATCH] HID: hyperv: pr_err() strings should end with newlines
On Mon, 25 Sep 2017, Arvind Yadav wrote: > pr_err() messages should terminated with a new-line to avoid > other messages being concatenated onto the end. > > Signed-off-by: Arvind Yadav Applied to for-4.15/hyperv. -- Jiri Kosina SUSE Labs
Re: [PATCH] x86/mce: Convert timers to use timer_setup()
On Wed, Oct 04, 2017 at 05:54:25PM -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Adjust sanity-check WARN to make sure
> the triggering timer matches the current CPU timer.
>
> Cc: Tony Luck
> Cc: Borislav Petkov
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: linux-e...@vger.kernel.org
> Cc: Thomas Gleixner
> Signed-off-by: Kees Cook
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.
> ---
> arch/x86/kernel/cpu/mcheck/mce.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v3] HID: hid-multitouch: support fine-grain orientation reporting
[ adding Benjamin to CC ]
On Thu, 28 Sep 2017, Wei-Ning Huang wrote:
> The current hid-multitouch driver only allow the report of two
> orientations, vertical and horizontal. We use the Azimuth orientation
> usage 0x3F under the Digitizer usage page to report orientation if the
> device supports it.
>
> Changelog:
> v1 -> v2:
>- Fix commit message.
>- Remove resolution reporting for ABS_MT_ORIENTATION.
> v2 -> v3:
>- Fix commit message.
>
> Signed-off-by: Wei-Ning Huang
> Reviewed-by: Dmitry Torokhov
> ---
> drivers/hid/hid-multitouch.c | 35 +--
> include/linux/hid.h | 1 +
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..f9801d1b1eae 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
> #define MT_IO_FLAGS_PENDING_SLOTS2
>
> struct mt_slot {
> - __s32 x, y, cx, cy, p, w, h;
> + __s32 x, y, cx, cy, p, w, h, a;
> __s32 contactid;/* the device ContactID assigned to this slot */
> bool touch_state; /* is the touch valid? */
> bool inrange_state; /* is the finger in proximity of the sensor? */
> bool confidence_state; /* is the touch made by a finger? */
> + bool has_azimuth; /* the contact reports azimuth */
> };
>
> struct mt_class {
> @@ -591,6 +592,20 @@ static int mt_touch_input_mapping(struct hid_device
> *hdev, struct hid_input *hi,
> td->cc_index = field->index;
> td->cc_value_index = usage->usage_index;
> return 1;
> + case HID_DG_AZIMUTH:
> + hid_map_usage(hi, usage, bit, max,
> + EV_ABS, ABS_MT_ORIENTATION);
> + /*
> + * Azimuth has the range of [0, MAX) representing a full
> + * revolution. Set ABS_MT_ORIENTATION to a quarter of
> + * MAX according the definition of ABS_MT_ORIENTATION
> + */
> + input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> + 0, field->logical_maximum / 4,
> + cls->sn_move ?
> + field->logical_maximum / cls->sn_move : 0, 0);
> + mt_store_field(usage, td, hi);
> + return 1;
> case HID_DG_CONTACTMAX:
> /* we don't set td->last_slot_field as contactcount and
>* contact max are global to the report */
> @@ -683,6 +698,10 @@ static void mt_complete_slot(struct mt_device *td,
> struct input_dev *input)
> int wide = (s->w > s->h);
> int major = max(s->w, s->h);
> int minor = min(s->w, s->h);
> + int orientation = wide;
> +
> + if (s->has_azimuth)
> + orientation = s->a;
>
> /*
>* divided by two to match visual scale of touch
> @@ -699,7 +718,8 @@ static void mt_complete_slot(struct mt_device *td, struct
> input_dev *input)
> input_event(input, EV_ABS, ABS_MT_TOOL_Y, s->cy);
> input_event(input, EV_ABS, ABS_MT_DISTANCE,
> !s->touch_state);
> - input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
> + input_event(input, EV_ABS, ABS_MT_ORIENTATION,
> + orientation);
> input_event(input, EV_ABS, ABS_MT_PRESSURE, s->p);
> input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major);
> input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor);
> @@ -789,6 +809,17 @@ static void mt_process_mt_event(struct hid_device *hid,
> struct hid_field *field,
> break;
> case HID_DG_CONTACTCOUNT:
> break;
> + case HID_DG_AZIMUTH:
> + /*
> + * Azimuth is counter-clockwise and ranges from [0, MAX)
> + * (a full revolution). Convert it to clockwise ranging
> + * [-MAX/2, MAX/2].
> + */
> + if (value > field->logical_maximum / 2)
> + value -= field->logical_maximum;
> + td->curdata.a = -value;
> + td->curdata.has_azimuth = true;
> + break;
> case HID_DG_TOUCH:
> /* do nothing */
> break;
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index ab05a86269dc..d81b9b6fd83a 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -281,6 +281,7
