* Re: [PATCH] staging: ccree: local variable "dev" not required
From: Gilad Ben-Yossef @ 2017-10-05 7:07 UTC (permalink / raw)
To: Suniel Mahesh
Cc: Greg Kroah-Hartman, Linux Crypto Mailing List, driverdev-devel,
devel, Linux kernel mailing list, karthik
In-Reply-To: <1507144330-1672-1-git-send-email-sunil.m@techveda.org>
Hi Suniel,
On Wed, Oct 4, 2017 at 10:12 PM, <sunil.m@techveda.org> wrote:
> From: Suniel Mahesh <sunil.m@techveda.org>
>
> 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 <sunil.m@techveda.org>
> ---
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);
> rc = -EINVAL;
> goto post_clk_err;
> }
> - dev_dbg(dev, "CC SIGNATURE=0x%08X\n", signature_val);
> + dev_dbg(&plat_dev->dev, "CC SIGNATURE=0x%08X\n", signature_val);
>
> /* Display HW versions */
> - dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver version %s\n",
> + dev_info(&plat_dev->dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver version %s\n",
> SSI_DEV_NAME_STR,
> CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_VERSION)),
> DRV_MODULE_VERSION);
>
> rc = init_cc_regs(new_drvdata, true);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "init_cc_regs failed\n");
> + dev_err(&plat_dev->dev, "init_cc_regs failed\n");
> goto post_clk_err;
> }
>
> #ifdef ENABLE_CC_SYSFS
> - rc = ssi_sysfs_init(&dev->kobj, new_drvdata);
> + rc = ssi_sysfs_init(&plat_dev->dev.kobj, new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "init_stat_db failed\n");
> + dev_err(&plat_dev->dev, "init_stat_db failed\n");
> goto post_regs_err;
> }
> #endif
>
> rc = ssi_fips_init(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "SSI_FIPS_INIT failed 0x%x\n", rc);
> + dev_err(&plat_dev->dev, "SSI_FIPS_INIT failed 0x%x\n", rc);
> goto post_sysfs_err;
> }
> rc = ssi_sram_mgr_init(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "ssi_sram_mgr_init failed\n");
> + dev_err(&plat_dev->dev, "ssi_sram_mgr_init failed\n");
> goto post_fips_init_err;
> }
>
> new_drvdata->mlli_sram_addr =
> ssi_sram_mgr_alloc(new_drvdata, MAX_MLLI_BUFF_SIZE);
> if (unlikely(new_drvdata->mlli_sram_addr == NULL_SRAM_ADDR)) {
> - dev_err(dev, "Failed to alloc MLLI Sram buffer\n");
> + dev_err(&plat_dev->dev, "Failed to alloc MLLI Sram buffer\n");
> rc = -ENOMEM;
> goto post_sram_mgr_err;
> }
>
> rc = request_mgr_init(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "request_mgr_init failed\n");
> + dev_err(&plat_dev->dev, "request_mgr_init failed\n");
> goto post_sram_mgr_err;
> }
>
> rc = ssi_buffer_mgr_init(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "buffer_mgr_init failed\n");
> + dev_err(&plat_dev->dev, "buffer_mgr_init failed\n");
> goto post_req_mgr_err;
> }
>
> rc = ssi_power_mgr_init(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "ssi_power_mgr_init failed\n");
> + dev_err(&plat_dev->dev, "ssi_power_mgr_init failed\n");
> goto post_buf_mgr_err;
> }
>
> rc = ssi_ivgen_init(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "ssi_ivgen_init failed\n");
> + dev_err(&plat_dev->dev, "ssi_ivgen_init failed\n");
> goto post_power_mgr_err;
> }
>
> /* Allocate crypto algs */
> rc = ssi_ablkcipher_alloc(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "ssi_ablkcipher_alloc failed\n");
> + dev_err(&plat_dev->dev, "ssi_ablkcipher_alloc failed\n");
> goto post_ivgen_err;
> }
>
> /* hash must be allocated before aead since hash exports APIs */
> rc = ssi_hash_alloc(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "ssi_hash_alloc failed\n");
> + dev_err(&plat_dev->dev, "ssi_hash_alloc failed\n");
> goto post_cipher_err;
> }
>
> rc = ssi_aead_alloc(new_drvdata);
> if (unlikely(rc != 0)) {
> - dev_err(dev, "ssi_aead_alloc failed\n");
> + dev_err(&plat_dev->dev, "ssi_aead_alloc failed\n");
> goto post_hash_err;
> }
>
> @@ -392,7 +391,7 @@ static int init_cc_resources(struct platform_device *plat_dev)
> post_clk_err:
> cc_clk_off(new_drvdata);
> post_drvdata_err:
> - dev_err(dev, "ccree init error occurred!\n");
> + dev_err(&plat_dev->dev, "ccree init error occurred!\n");
> return rc;
> }
>
> --
> 1.9.1
>
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* Re: [PATCH 07/10] drm/i915: Gate engine stats collection with a static key
From: Tvrtko Ursulin @ 2017-10-05 7:07 UTC (permalink / raw)
To: Chris Wilson, Tvrtko Ursulin, Intel-gfx
In-Reply-To: <150713935609.27301.445690388468410037@mail.alporthouse.com>
On 04/10/2017 18:49, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-10-04 18:38:09)
>>
>> On 03/10/2017 11:17, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2017-09-29 13:34:57)
>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>
>>>> This reduces the cost of the software engine busyness tracking
>>>> to a single no-op instruction when there are no listeners.
>>>>
>>>> We add a new i915 ordered workqueue to be used only for tasks
>>>> not needing struct mutex.
>>>>
>>>> v2: Rebase and some comments.
>>>> v3: Rebase.
>>>> v4: Checkpatch fixes.
>>>> v5: Rebase.
>>>> v6: Use system_long_wq to avoid being blocked by struct_mutex
>>>> users.
>>>> v7: Fix bad conflict resolution from last rebase. (Dmitry Rogozhkin)
>>>> v8: Rebase.
>>>> v9:
>>>> * Fix race between unordered enable followed by disable.
>>>> (Chris Wilson)
>>>> * Prettify order of local variable declarations. (Chris Wilson)
>>>
>>> Ok, I can't see a downside to enabling the optimisation even if it will
>>> be global and not per-device/per-engine.
>>
>> For this one I did a quick test with gem_exec_nop and I've seen around
>> 0.5% reduction in time spend in intel_lrc_irq_handler in the case where
>> PMU is not active.
>
> Hmm, gem_exec_nop isn't going to be favourable as there we are just
> extending the busyness coverage of an engine. I think you want something
> like gem_sync/sequential (or gem_exec_whisper), as there each engine
> will be starting and stopping, and delays between engines will
> accumulate.
Not sure if we are on the same page. Here I was referring to the CPU
usage in the "irq" (tasklet) handler. gem_exec_nop generates a good
number of interrupts (8k/s) and shows up in the profile at ~1.8% CPU
without the static branch optimisation, and ~1.3% with it.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [RFC] mmap(MAP_CONTIG)
From: Vlastimil Babka @ 2017-10-05 7:06 UTC (permalink / raw)
To: Mike Kravetz, linux-mm, linux-kernel, linux-api
Cc: Marek Szyprowski, Michal Nazarewicz, Aneesh Kumar K.V,
Joonsoo Kim, Guy Shattah, Christoph Lameter
In-Reply-To: <21f1ec96-2822-1189-1c95-79a2bb491571@oracle.com>
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
>
^ permalink raw reply
* Re: [RFC] mmap(MAP_CONTIG)
From: Vlastimil Babka @ 2017-10-05 7:06 UTC (permalink / raw)
To: Mike Kravetz, linux-mm, linux-kernel, linux-api
Cc: Marek Szyprowski, Michal Nazarewicz, Aneesh Kumar K.V,
Joonsoo Kim, Guy Shattah, Christoph Lameter
In-Reply-To: <21f1ec96-2822-1189-1c95-79a2bb491571@oracle.com>
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
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor
From: Leon Luo @ 2017-10-05 7:06 UTC (permalink / raw)
To: Sakari Ailus
Cc: mchehab, robh+dt, mark.rutland, hans.verkuil, sakari.ailus,
linux-media, devicetree, linux-kernel, Sören Brinkmann
In-Reply-To: <20171005062901.ofexwxfnun45linq@valkosipuli.retiisi.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
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?
Regards,
Leon Luo
1130 Cadillac CT
Milpitas, CA 95035
Phone: (510)371-1169
Fax: (408) 217-1960
Email: leonl@leopardimaging.com
www.leopardimaging.com
On Wed, Oct 4, 2017 at 11:29 PM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> On Wed, Oct 04, 2017 at 05:06:21PM -0700, Leon Luo wrote:
> > The imx274 is a Sony CMOS image sensor that has 1/2.5 image size.
> > It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface
> > is 4-lane MIPI CSI-2 running at 1.44Gbps each.
> >
> > This driver has been tested on Xilinx ZCU102 platform with a Leopard
> > LI-IMX274MIPI-FMC camera board.
> >
> > Support for the following features:
> > -Resolutions: 3840x2160, 1920x1080, 1280x720
> > -Frame rate: 3840x2160 : 5 – 60fps
> > 1920x1080 : 5 – 120fps
> > 1280x720 : 5 – 120fps
> > -Exposure time: 16 – (frame interval) micro-seconds
> > -Gain: 1x - 180x
> > -VFLIP: enable/disabledrivers/media/i2c/imx274.c
> > -Test pattern: 12 test patterns
> >
> > Signed-off-by: Leon Luo <leonl@leopardimaging.com>
> > Tested-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
> > Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
>
> Thanks!
>
> Applied with MEDIA_CAMERA_SUPPORT dependency to Kconfig.
>
> --
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi
>
[-- Attachment #2: Type: text/html, Size: 2578 bytes --]
^ permalink raw reply
* Re: spi-atmel.c: regression
From: Igor Plyatov @ 2017-10-05 7:05 UTC (permalink / raw)
To: Nicolas Ferre, Mark Brown, linux-spi, linux-kernel,
Cyrille Pitchen, linux-mmc, Ludovic Desroches, Ulf Hansson
In-Reply-To: <0876ce0a-cb93-07b7-8019-e365d08cca2a@gmail.com>
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
^ permalink raw reply
* Re: spi-atmel.c: regression
From: Igor Plyatov @ 2017-10-05 7:05 UTC (permalink / raw)
To: Nicolas Ferre, Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cyrille Pitchen,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ludovic Desroches, Ulf Hansson
In-Reply-To: <0876ce0a-cb93-07b7-8019-e365d08cca2a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] scsi: fcoe: Convert timers to use timer_setup()
From: Johannes Thumshirn @ 2017-10-05 7:04 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, QLogic-Storage-Upstream, James E.J. Bottomley,
Martin K. Petersen, Johannes Thumshirn, linux-scsi, fcoe-devel,
Thomas Gleixner
In-Reply-To: <20171005004826.GA22983@beast>
Looks good,
Acked-by: Johannes Thumshirn <jth@kernel.org>
--
Johannes Thumshirn Storage
jthumshirn@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
^ permalink raw reply
* Re: [PATCH for-next 0/8] IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017
From: Leon Romanovsky @ 2017-10-05 7:04 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: Doug Ledford, Mike Marciniszyn, Jan Sokolowski, Jakub Byczkowski,
Andrzej Kacprowski, linux-rdma, Ira Weiny, Stable, Kaike Wan,
Michael J. Ruhl, Don Hiatt, Niranjana Vishwanathapura,
Sebastian Sanchez
In-Reply-To: <2e195006-92f1-0d6c-1418-5c541f38f8e3@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
On Wed, Oct 04, 2017 at 09:22:06PM -0400, Dennis Dalessandro wrote:
> On 10/4/2017 3:44 PM, Doug Ledford wrote:
> > On Mon, 2017-10-02 at 11:03 -0700, Dennis Dalessandro wrote:
> > > Hi Doug,
> > > There are a couple fixes in here that would have been nice to get
> > > into the RC
> > > cycle, including one marked stable. However I think you will find
> > > them to be
> > > too many LOC for an rc-4 submission so I have sent them in one series
> > > for-next.
> > > Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not
> > > really that
> > > important to the end user.
> > >
> > > There are some clean ups in here from Don from the 16B changes. One
> > > takes care
> > > of some sparse warnings and the other two are from a WARN_ON_ONCE
> > > that needed
> > > special cased for OPA.
> > >
> > > Patches can can also be found in my GitHub repo at:
> > > https://github.com/ddalessa/kernel/tree/for-4.15
> >
> > Hi Denny,
> >
> > I didn't process that you mixed for-rc and for-next stuff in a single
> > thread before I had gone through and looked at the patches and
> > processed them. So, this time they all went to for-next. In the
> > future, you really need patches you want in for-rc separate from the
> > patches intended for for-next.
>
> Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep
> for-next was the right target.
>
> I would have liked to get the fixes into -rc but they were just too complex
> for this late in the game is all I meant.
IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the
severity of fixes yes.
Thanks
>
> -Denny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ALSA: core: Add new ACCESS_TLV flag for coefficient TLV controls
From: Takashi Iwai @ 2017-10-05 7:04 UTC (permalink / raw)
To: Charles Keepax
Cc: alsa-devel, vinod.koul, patches, lgirdwood, o-takashi, broonie
In-Reply-To: <20171002160421.22696-1-ckeepax@opensource.cirrus.com>
On Mon, 02 Oct 2017 18:04:21 +0200,
Charles Keepax wrote:
>
> ASoC can use the TLV mechanism to pass coefficient data for
> controls that exceed the normal 512 byte limit. However, there
> is no mechanism to inform user-space the control expects data
> through the TLV mechanism. Currently amixer uses a combination
> of the absense of non-TLV read/write permissions and the type
> being BYTES. This is not ideal as it is not a clear signal and
> prevents controls that might support both access mechanisms.
>
> Add a specific flag SNDRV_CTL_ELEM_ACCESS_TLV_COEFF to let
> user-space know when it is dealing with a TLV control that is
> being used to pass actual coefficient data. Then add this flag
> to the controls generated by the current users of these types of
> controls.
>
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
>
> Hi,
>
> This builds on work done by Sakamoto-san [1] and the changes
> mentioned to amixer in the commit message are found in [2]. I
> think something like this should probably be added, what I am
> less clear on is where we go from here?
>
> Sakamoto-san's original patches also added a tag type
> SNDRV_CTL_TVLT_COEFF, to keep the data matching the normal format
> found in TLV controls. The trouble is neither of the two users
> really follow this convention at the moment. The ADSP code just
> takes the data as is with no additional headers and the Skylake
> code does have a tag and a length as part of the data passed
> through the TLV however the tag part looks like it is used for
> some internal purpose, so I am far from clear it would support a
> fixed value to identify the data without some changes as well.
>
> Changing the ADSP code is probably acceptable since we have had
> very few users in the field, and since this work has been done
> improvements in the firmware tool chains mean most firmwares are
> created with much smaller dedicated purpose controls rather than
> the large block ones that were initially the reason for using
> these controls on our side.
>
> Finally, since [3] tinymix has been updated to add some TLV
> information into control writes/reads which will break the ADSP
> code once it trickles down to users. So I would be keen to
> discuss this at this years conference and decide how we are going
> to handle these controls? As Mark says [4] maybe we should see if
> there is a better approach we should all migrate across to?
Currently I'm open for this although ideally we may have TLV COEFF
type for consistency as you noted.
Who should test the callback (whether in ASoC core or ALSA core) is
another open question, but it's a cosmetic issue.
In anyway, I'd happily discuss this at audio conf.
thanks,
Takashi
>
> Thanks,
> Charles
>
> [1] https://patchwork.kernel.org/patch/9304649/
> [2] https://patchwork.kernel.org/patch/8147001/
> [3] https://github.com/tinyalsa/tinyalsa/commit/3f813e47784674a3909fe1277bc10b70d03791e2
> [4] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-September/125743.html
>
>
> include/sound/soc.h | 3 ++-
> include/uapi/sound/asound.h | 1 +
> sound/core/control.c | 1 +
> sound/soc/codecs/wm_adsp.c | 3 ++-
> sound/soc/intel/skylake/skl-topology.c | 1 +
> sound/soc/soc-ops.c | 3 +++
> 6 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index d776cdee30d7..d82297a95caf 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -323,7 +323,8 @@
> #define SND_SOC_BYTES_TLV(xname, xcount, xhandler_get, xhandler_put) \
> { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
> .access = SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE | \
> - SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK, \
> + SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK | \
> + SNDRV_CTL_ELEM_ACCESS_TLV_COEFF, \
> .tlv.c = (snd_soc_bytes_tlv_callback), \
> .info = snd_soc_bytes_info_ext, \
> .private_value = (unsigned long)&(struct soc_bytes_ext) \
> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
> index 1949923a40bf..4bf0b2f835e9 100644
> --- a/include/uapi/sound/asound.h
> +++ b/include/uapi/sound/asound.h
> @@ -853,6 +853,7 @@ typedef int __bitwise snd_ctl_elem_iface_t;
> #define SNDRV_CTL_ELEM_ACCESS_TLV_WRITE (1<<5) /* TLV write is possible */
> #define SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE (SNDRV_CTL_ELEM_ACCESS_TLV_READ|SNDRV_CTL_ELEM_ACCESS_TLV_WRITE)
> #define SNDRV_CTL_ELEM_ACCESS_TLV_COMMAND (1<<6) /* TLV command is possible */
> +#define SNDRV_CTL_ELEM_ACCESS_TLV_COEFF (1<<7) /* Coefficient data is accepted */
> #define SNDRV_CTL_ELEM_ACCESS_INACTIVE (1<<8) /* control does actually nothing, but may be updated */
> #define SNDRV_CTL_ELEM_ACCESS_LOCK (1<<9) /* write lock */
> #define SNDRV_CTL_ELEM_ACCESS_OWNER (1<<10) /* write lock owner */
> diff --git a/sound/core/control.c b/sound/core/control.c
> index 56b3e2d49c82..e7a74d48633b 100644
> --- a/sound/core/control.c
> +++ b/sound/core/control.c
> @@ -266,6 +266,7 @@ struct snd_kcontrol *snd_ctl_new1(const struct snd_kcontrol_new *ncontrol,
> SNDRV_CTL_ELEM_ACCESS_INACTIVE |
> SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE |
> SNDRV_CTL_ELEM_ACCESS_TLV_COMMAND |
> + SNDRV_CTL_ELEM_ACCESS_TLV_COEFF |
> SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK);
>
> err = snd_ctl_new(&kctl, count, access, NULL);
> diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
> index 65c059b5ffd7..1d7fe0d8a18a 100644
> --- a/sound/soc/codecs/wm_adsp.c
> +++ b/sound/soc/codecs/wm_adsp.c
> @@ -1156,7 +1156,8 @@ static unsigned int wmfw_convert_flags(unsigned int in, unsigned int len)
> wr = SNDRV_CTL_ELEM_ACCESS_TLV_WRITE;
> vol = SNDRV_CTL_ELEM_ACCESS_VOLATILE;
>
> - out = SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK;
> + out = SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK |
> + SNDRV_CTL_ELEM_ACCESS_TLV_COEFF;
> } else {
> rd = SNDRV_CTL_ELEM_ACCESS_READ;
> wr = SNDRV_CTL_ELEM_ACCESS_WRITE;
> diff --git a/sound/soc/intel/skylake/skl-topology.c b/sound/soc/intel/skylake/skl-topology.c
> index 27bcb62568fb..01b01c6a2bf3 100644
> --- a/sound/soc/intel/skylake/skl-topology.c
> +++ b/sound/soc/intel/skylake/skl-topology.c
> @@ -2870,6 +2870,7 @@ static int skl_tplg_control_load(struct snd_soc_component *cmpnt,
> tplg_bc = container_of(hdr,
> struct snd_soc_tplg_bytes_control, hdr);
> if (kctl->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
> + kctl->access |= SNDRV_CTL_ELEM_ACCESS_TLV_COEFF;
> sb = (struct soc_bytes_ext *)kctl->private_value;
> if (tplg_bc->priv.size)
> return skl_init_algo_data(
> diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
> index 500f98c730b9..5ac2afe12b5d 100644
> --- a/sound/soc/soc-ops.c
> +++ b/sound/soc/soc-ops.c
> @@ -776,6 +776,9 @@ int snd_soc_bytes_tlv_callback(struct snd_kcontrol *kcontrol, int op_flag,
> unsigned int count = size < params->max ? size : params->max;
> int ret = -ENXIO;
>
> + if (!(kcontrol->vd[0].access & SNDRV_CTL_ELEM_ACCESS_TLV_COEFF))
> + return -ENXIO;
> +
> switch (op_flag) {
> case SNDRV_CTL_TLV_OP_READ:
> if (params->get)
> --
> 2.11.0
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD REGRESSION 80fa5f29e881d77e3a7a0c5f6ff8d76f3ec08ca7
From: kbuild test robot @ 2017-10-05 7:01 UTC (permalink / raw)
To: intel-wired-lan
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
80fa5f29e881d77e3a7a0c5f6ff8d76f3ec08ca7 ixgbe: fix crash when injecting AER after failed reset
ERROR: "__udivdi3" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
Error ids grouped by kconfigs:
recent_errors
??? i386-allmodconfig
??? ERROR:__udivdi3-drivers-net-ethernet-intel-i40e-i40e.ko-undefined
elapsed time: 632m
configs tested: 80
i386 tinyconfig
i386 randconfig-x013-201740
i386 randconfig-x014-201740
i386 randconfig-x015-201740
i386 randconfig-x019-201740
i386 randconfig-x011-201740
i386 randconfig-x018-201740
i386 randconfig-x010-201740
i386 randconfig-x017-201740
i386 randconfig-x012-201740
i386 randconfig-x016-201740
x86_64 randconfig-x001-201740
x86_64 randconfig-x000-201740
x86_64 randconfig-x004-201740
x86_64 randconfig-x008-201740
x86_64 randconfig-x006-201740
x86_64 randconfig-x007-201740
x86_64 randconfig-x005-201740
x86_64 randconfig-x009-201740
x86_64 randconfig-x003-201740
x86_64 randconfig-x002-201740
arm allnoconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
i386 allmodconfig
ia64 alldefconfig
ia64 allnoconfig
i386 randconfig-a0-201740
x86_64 allyesdebian
parisc allnoconfig
i386 alldefconfig
i386 allnoconfig
i386 defconfig
x86_64 rhel
x86_64 rhel-7.2
m68k m5475evb_defconfig
x86_64 allmodconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
sh allnoconfig
sh titan_defconfig
i386 randconfig-x001-201740
i386 randconfig-x008-201740
i386 randconfig-x004-201740
i386 randconfig-x003-201740
i386 randconfig-x002-201740
i386 randconfig-x006-201740
i386 randconfig-x007-201740
i386 randconfig-x009-201740
i386 randconfig-x000-201740
i386 randconfig-x005-201740
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
sparc64 allnoconfig
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
xtensa common_defconfig
i386 randconfig-x074-201740
i386 randconfig-x071-201740
i386 randconfig-x076-201740
i386 randconfig-x077-201740
i386 randconfig-x073-201740
i386 randconfig-x079-201740
i386 randconfig-x072-201740
i386 randconfig-x078-201740
i386 randconfig-x075-201740
i386 randconfig-x070-201740
tile tilegx_defconfig
Thanks,
Fengguang
^ permalink raw reply
* [PATCH v4 2/5] clk: aspeed: Register core clocks
From: Andrew Jeffery @ 2017-10-05 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171003065540.11722-3-joel@jms.id.au>
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 <joel@jms.id.au>
>?
> ---
> 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 <dt-bindings/clock/aspeed-clock.h>
> ?
> +#define ASPEED_RESET_CTRL 0x04
> +#define ASPEED_CLK_SELECTION 0x08
> +#define ASPEED_CLK_STOP_CTRL 0x0c
> +#define ASPEED_MPLL_PARAM 0x20
> +#define ASPEED_HPLL_PARAM 0x24
> +#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 = 25000000;
> + else if (val & AST2400_CLK_SOURCE_SEL)
> + freq = 48000000;
> + else
> + freq = 24000000;
> + hw = clk_hw_register_fixed_rate(NULL, "clkin", NULL, 0, freq);
> + pr_debug("clkin @%u MHz\n", freq / 1000000);
> +
> + /*
> + ?* 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)
> + div = 3;
> + hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
> + aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
> +
> + /* APB clock clock selection register SCU08 (aka PCLK) */
> + hw = clk_hw_register_divider_table(NULL, "apb", "hpll", 0,
> + scu_base + ASPEED_CLK_SELECTION, 23, 3, 0,
> + ast2400_div_table,
> + &aspeed_clk_lock);
> + aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;
> +}
> +
> +static void __init aspeed_ast2500_cc(struct regmap *map)
> +{
> + struct clk_hw *hw;
> + u32 val, freq, div;
> +
> + /* CLKIN is the crystal oscillator, 24 or 25MHz selected by strapping */
> + regmap_read(map, ASPEED_STRAP, &val);
> + if (val & CLKIN_25MHZ_EN)
> + freq = 25000000;
> + else
> + freq = 24000000;
> + hw = clk_hw_register_fixed_rate(NULL, "clkin", NULL, 0, freq);
> + pr_debug("clkin @%u MHz\n", freq / 1000000);
> +
> + /*
> + ?* 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);
> + aspeed_clk_data->hws[ASPEED_CLK_HPLL] = aspeed_ast2500_calc_pll("hpll", val);
> +
> + /* Strap bits 11:9 define the AXI/AHB clock frequency ratio (aka HCLK)*/
> + regmap_read(map, ASPEED_STRAP, &val);
> + val = (val >> 9) & 0x7;
> + WARN(val == 0, "strapping is zero: cannot determine ahb clock");
> + div = 2 * (val + 1);
> + hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
> + aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
> +
> + /* APB clock clock selection register SCU08 (aka PCLK) */
> + regmap_read(map, ASPEED_CLK_SELECTION, &val);
> + val = (val >> 23) & 0x7;
> + div = 4 * (val + 1);
> + hw = clk_hw_register_fixed_factor(NULL, "apb", "hpll", 0, 1, div);
> + aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;
> +};
> +
> ?static void __init aspeed_cc_init(struct device_node *np)
> ?{
> ? struct regmap *map;
> @@ -139,6 +309,13 @@ static void __init aspeed_cc_init(struct device_node *np)
> ? return;
> ? }
> ?
> + if (of_device_is_compatible(np, "aspeed,ast2400-scu"))
> + aspeed_ast2400_cc(map);
> + else if (of_device_is_compatible(np, "aspeed,ast2500-scu"))
> + aspeed_ast2500_cc(map);
> + else
> + pr_err("unknown platform, failed to add clocks\n");
> +
I'm still unsure about this approach with the scu compatible, but otherwise:
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> ? aspeed_clk_data->num = ASPEED_NUM_CLKS;
> ? ret = of_clk_add_hw_provider(np, of_clk_hw_onecell_get, aspeed_clk_data);
> ? if (ret)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171005/300aa628/attachment.sig>
^ permalink raw reply
* Re: [PATCH v4 2/5] clk: aspeed: Register core clocks
From: Andrew Jeffery @ 2017-10-05 7:00 UTC (permalink / raw)
To: Joel Stanley, Lee Jones, Michael Turquette, Stephen Boyd
Cc: linux-kernel, linux-clk, linux-arm-kernel, Benjamin Herrenschmidt,
Jeremy Kerr, Rick Altherr, Ryan Chen, Arnd Bergmann
In-Reply-To: <20171003065540.11722-3-joel@jms.id.au>
[-- Attachment #1: Type: text/plain, Size: 7212 bytes --]
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 <joel@jms.id.au>
>
> ---
> 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 <dt-bindings/clock/aspeed-clock.h>
>
> +#define ASPEED_RESET_CTRL 0x04
> +#define ASPEED_CLK_SELECTION 0x08
> +#define ASPEED_CLK_STOP_CTRL 0x0c
> +#define ASPEED_MPLL_PARAM 0x20
> +#define ASPEED_HPLL_PARAM 0x24
> +#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 = 25000000;
> + else if (val & AST2400_CLK_SOURCE_SEL)
> + freq = 48000000;
> + else
> + freq = 24000000;
> + hw = clk_hw_register_fixed_rate(NULL, "clkin", NULL, 0, freq);
> + pr_debug("clkin @%u MHz\n", freq / 1000000);
> +
> + /*
> + * 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)
> + div = 3;
> + hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
> + aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
> +
> + /* APB clock clock selection register SCU08 (aka PCLK) */
> + hw = clk_hw_register_divider_table(NULL, "apb", "hpll", 0,
> + scu_base + ASPEED_CLK_SELECTION, 23, 3, 0,
> + ast2400_div_table,
> + &aspeed_clk_lock);
> + aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;
> +}
> +
> +static void __init aspeed_ast2500_cc(struct regmap *map)
> +{
> + struct clk_hw *hw;
> + u32 val, freq, div;
> +
> + /* CLKIN is the crystal oscillator, 24 or 25MHz selected by strapping */
> + regmap_read(map, ASPEED_STRAP, &val);
> + if (val & CLKIN_25MHZ_EN)
> + freq = 25000000;
> + else
> + freq = 24000000;
> + hw = clk_hw_register_fixed_rate(NULL, "clkin", NULL, 0, freq);
> + pr_debug("clkin @%u MHz\n", freq / 1000000);
> +
> + /*
> + * 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);
> + aspeed_clk_data->hws[ASPEED_CLK_HPLL] = aspeed_ast2500_calc_pll("hpll", val);
> +
> + /* Strap bits 11:9 define the AXI/AHB clock frequency ratio (aka HCLK)*/
> + regmap_read(map, ASPEED_STRAP, &val);
> + val = (val >> 9) & 0x7;
> + WARN(val == 0, "strapping is zero: cannot determine ahb clock");
> + div = 2 * (val + 1);
> + hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
> + aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
> +
> + /* APB clock clock selection register SCU08 (aka PCLK) */
> + regmap_read(map, ASPEED_CLK_SELECTION, &val);
> + val = (val >> 23) & 0x7;
> + div = 4 * (val + 1);
> + hw = clk_hw_register_fixed_factor(NULL, "apb", "hpll", 0, 1, div);
> + aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;
> +};
> +
> static void __init aspeed_cc_init(struct device_node *np)
> {
> struct regmap *map;
> @@ -139,6 +309,13 @@ static void __init aspeed_cc_init(struct device_node *np)
> return;
> }
>
> + if (of_device_is_compatible(np, "aspeed,ast2400-scu"))
> + aspeed_ast2400_cc(map);
> + else if (of_device_is_compatible(np, "aspeed,ast2500-scu"))
> + aspeed_ast2500_cc(map);
> + else
> + pr_err("unknown platform, failed to add clocks\n");
> +
I'm still unsure about this approach with the scu compatible, but otherwise:
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> aspeed_clk_data->num = ASPEED_NUM_CLKS;
> ret = of_clk_add_hw_provider(np, of_clk_hw_onecell_get, aspeed_clk_data);
> if (ret)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Kalle Valo @ 2017-10-05 6:58 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, Maxime Ripard, Arend van Spriel, devicetree,
netdev, linux-sunxi, linux-wireless, linux-kernel, Chen-Yu Tsai,
Rob Herring
In-Reply-To: <C4895259-FCDE-4B21-BB15-8F150FC53BE3@aosc.io>
Icenowy Zheng <icenowy@aosc.io> writes:
> 于 2017年10月4日 GMT+08:00 下午6:11:45, Maxime Ripard
> <maxime.ripard@free-electrons.com> 写到:
>>On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
>>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>>> >
>>> >
>>> > 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo@codeaurora.org>
>>写到:
>>> > > Icenowy Zheng <icenowy@aosc.io> writes:
>>> > >
>>> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the
>>functionality to
>>> > > use
>>> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>> > > >
>>> > > > Add the device tree binding of this chip, in order to make it
>>> > > possible
>>> > > > to add this interrupt pin to device trees.
>>> > > >
>>> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> > > > Acked-by: Rob Herring <robh@kernel.org>
>>> > > > ---
>>> > > > Changes in v3:
>>> > > > - Renames the node name.
>>> > > > - Adds ACK from Rob.
>>> > > > Changes in v2:
>>> > > > - Removed status property in example.
>>> > > > - Added required property reg.
>>> > > >
>>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
>>> > > ++++++++++++++++++++++
>>> > > > 1 file changed, 38 insertions(+)
>>> > > > create mode 100644
>>> > >
>>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>>> > >
>>> > > Like I asked already last time, AFAICS there is no upstream xr819
>>> > > wireless driver in drivers/net/wireless directory. Do we still
>>accept
>>> > > bindings like this for out-of-tree drivers?
>>> >
>>> > See esp8089.
>>> >
>>> > There's also no in-tree driver for it.
>>>
>>> The question is whether we should. The above might be a precedent,
>>but it
>>> may not necessarily be the way to go. The commit message for esp8089
>>seems
>>> to hint that there is intent to have an in-tree driver:
>>>
>>> """
>>> Note that at this point there only is an out of tree driver for
>>this
>>> hardware, there is no clear timeline / path for merging this.
>>Still
>>> I believe it would be good to specify the binding for this in
>>tree
>>> now, so that any future migration to an in tree driver will not
>>cause
>>> compatiblity issues.
>>>
>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>> """
>>>
>>> Regardless the bindings are in principle independent of the kernel
>>and just
>>> describing hardware. I think there have been discussions to move the
>>> bindings to their own repository, but apparently it was decided
>>otherwise.
>>
>>Yeah, I guess especially how it could be merged with the cw1200 driver
>>would be very relevant to that commit log.
>
> The cw1200 driver seems to still have some legacy platform
> data. Maybe they should also be convert to DT.
> (Or maybe compatible = "allwinner,xr819" is enough, as
> xr819 is a specified variant of cw1200 family)
Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
that? Or does cw1200 more changes than just adding the DT support?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Kalle Valo @ 2017-10-05 6:58 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, Maxime Ripard, Arend van Spriel, devicetree,
netdev, linux-sunxi, linux-wireless, linux-kernel, Chen-Yu Tsai,
Rob Herring
In-Reply-To: <C4895259-FCDE-4B21-BB15-8F150FC53BE3@aosc.io>
Icenowy Zheng <icenowy@aosc.io> writes:
> =E4=BA=8E 2017=E5=B9=B410=E6=9C=884=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D=88=
6:11:45, Maxime Ripard
> <maxime.ripard@free-electrons.com> =E5=86=99=E5=88=B0:
>>On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
>>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>>> >=20
>>> >=20
>>> > =E4=BA=8E 2017=E5=B9=B410=E6=9C=884=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=
=8D=885:02:17, Kalle Valo <kvalo@codeaurora.org>
>>=E5=86=99=E5=88=B0:
>>> > > Icenowy Zheng <icenowy@aosc.io> writes:
>>> > >=20
>>> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the
>>functionality to
>>> > > use
>>> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>> > > >=20
>>> > > > Add the device tree binding of this chip, in order to make it
>>> > > possible
>>> > > > to add this interrupt pin to device trees.
>>> > > >=20
>>> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> > > > Acked-by: Rob Herring <robh@kernel.org>
>>> > > > ---
>>> > > > Changes in v3:
>>> > > > - Renames the node name.
>>> > > > - Adds ACK from Rob.
>>> > > > Changes in v2:
>>> > > > - Removed status property in example.
>>> > > > - Added required property reg.
>>> > > >=20
>>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
>>> > > ++++++++++++++++++++++
>>> > > > 1 file changed, 38 insertions(+)
>>> > > > create mode 100644
>>> > >
>>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>>> > >=20
>>> > > Like I asked already last time, AFAICS there is no upstream xr819
>>> > > wireless driver in drivers/net/wireless directory. Do we still
>>accept
>>> > > bindings like this for out-of-tree drivers?
>>> >=20
>>> > See esp8089.
>>> >=20
>>> > There's also no in-tree driver for it.
>>>=20
>>> The question is whether we should. The above might be a precedent,
>>but it
>>> may not necessarily be the way to go. The commit message for esp8089
>>seems
>>> to hint that there is intent to have an in-tree driver:
>>>=20
>>> """
>>> Note that at this point there only is an out of tree driver for
>>this
>>> hardware, there is no clear timeline / path for merging this.
>>Still
>>> I believe it would be good to specify the binding for this in
>>tree
>>> now, so that any future migration to an in tree driver will not
>>cause
>>> compatiblity issues.
>>>=20
>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>> """
>>>=20
>>> Regardless the bindings are in principle independent of the kernel
>>and just
>>> describing hardware. I think there have been discussions to move the
>>> bindings to their own repository, but apparently it was decided
>>otherwise.
>>
>>Yeah, I guess especially how it could be merged with the cw1200 driver
>>would be very relevant to that commit log.
>
> The cw1200 driver seems to still have some legacy platform
> data. Maybe they should also be convert to DT.
> (Or maybe compatible =3D "allwinner,xr819" is enough, as
> xr819 is a specified variant of cw1200 family)
Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
that? Or does cw1200 more changes than just adding the DT support?
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Kalle Valo @ 2017-10-05 6:58 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Arend van Spriel, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Rob Herring
In-Reply-To: <C4895259-FCDE-4B21-BB15-8F150FC53BE3-h8G6r0blFSE@public.gmane.org>
Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
> 于 2017年10月4日 GMT+08:00 下午6:11:45, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
>>On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
>>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>>> >
>>> >
>>> > 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>写到:
>>> > > Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
>>> > >
>>> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the
>>functionality to
>>> > > use
>>> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>> > > >
>>> > > > Add the device tree binding of this chip, in order to make it
>>> > > possible
>>> > > > to add this interrupt pin to device trees.
>>> > > >
>>> > > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> > > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> > > > ---
>>> > > > Changes in v3:
>>> > > > - Renames the node name.
>>> > > > - Adds ACK from Rob.
>>> > > > Changes in v2:
>>> > > > - Removed status property in example.
>>> > > > - Added required property reg.
>>> > > >
>>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
>>> > > ++++++++++++++++++++++
>>> > > > 1 file changed, 38 insertions(+)
>>> > > > create mode 100644
>>> > >
>>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>>> > >
>>> > > Like I asked already last time, AFAICS there is no upstream xr819
>>> > > wireless driver in drivers/net/wireless directory. Do we still
>>accept
>>> > > bindings like this for out-of-tree drivers?
>>> >
>>> > See esp8089.
>>> >
>>> > There's also no in-tree driver for it.
>>>
>>> The question is whether we should. The above might be a precedent,
>>but it
>>> may not necessarily be the way to go. The commit message for esp8089
>>seems
>>> to hint that there is intent to have an in-tree driver:
>>>
>>> """
>>> Note that at this point there only is an out of tree driver for
>>this
>>> hardware, there is no clear timeline / path for merging this.
>>Still
>>> I believe it would be good to specify the binding for this in
>>tree
>>> now, so that any future migration to an in tree driver will not
>>cause
>>> compatiblity issues.
>>>
>>> Cc: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> """
>>>
>>> Regardless the bindings are in principle independent of the kernel
>>and just
>>> describing hardware. I think there have been discussions to move the
>>> bindings to their own repository, but apparently it was decided
>>otherwise.
>>
>>Yeah, I guess especially how it could be merged with the cw1200 driver
>>would be very relevant to that commit log.
>
> The cw1200 driver seems to still have some legacy platform
> data. Maybe they should also be convert to DT.
> (Or maybe compatible = "allwinner,xr819" is enough, as
> xr819 is a specified variant of cw1200 family)
Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
that? Or does cw1200 more changes than just adding the DT support?
--
Kalle Valo
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Kalle Valo @ 2017-10-05 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C4895259-FCDE-4B21-BB15-8F150FC53BE3@aosc.io>
Icenowy Zheng <icenowy@aosc.io> writes:
> ? 2017?10?4? GMT+08:00 ??6:11:45, Maxime Ripard
> <maxime.ripard@free-electrons.com> ??:
>>On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
>>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>>> >
>>> >
>>> > ? 2017?10?4? GMT+08:00 ??5:02:17, Kalle Valo <kvalo@codeaurora.org>
>>??:
>>> > > Icenowy Zheng <icenowy@aosc.io> writes:
>>> > >
>>> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the
>>functionality to
>>> > > use
>>> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>> > > >
>>> > > > Add the device tree binding of this chip, in order to make it
>>> > > possible
>>> > > > to add this interrupt pin to device trees.
>>> > > >
>>> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> > > > Acked-by: Rob Herring <robh@kernel.org>
>>> > > > ---
>>> > > > Changes in v3:
>>> > > > - Renames the node name.
>>> > > > - Adds ACK from Rob.
>>> > > > Changes in v2:
>>> > > > - Removed status property in example.
>>> > > > - Added required property reg.
>>> > > >
>>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
>>> > > ++++++++++++++++++++++
>>> > > > 1 file changed, 38 insertions(+)
>>> > > > create mode 100644
>>> > >
>>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>>> > >
>>> > > Like I asked already last time, AFAICS there is no upstream xr819
>>> > > wireless driver in drivers/net/wireless directory. Do we still
>>accept
>>> > > bindings like this for out-of-tree drivers?
>>> >
>>> > See esp8089.
>>> >
>>> > There's also no in-tree driver for it.
>>>
>>> The question is whether we should. The above might be a precedent,
>>but it
>>> may not necessarily be the way to go. The commit message for esp8089
>>seems
>>> to hint that there is intent to have an in-tree driver:
>>>
>>> """
>>> Note that at this point there only is an out of tree driver for
>>this
>>> hardware, there is no clear timeline / path for merging this.
>>Still
>>> I believe it would be good to specify the binding for this in
>>tree
>>> now, so that any future migration to an in tree driver will not
>>cause
>>> compatiblity issues.
>>>
>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>> """
>>>
>>> Regardless the bindings are in principle independent of the kernel
>>and just
>>> describing hardware. I think there have been discussions to move the
>>> bindings to their own repository, but apparently it was decided
>>otherwise.
>>
>>Yeah, I guess especially how it could be merged with the cw1200 driver
>>would be very relevant to that commit log.
>
> The cw1200 driver seems to still have some legacy platform
> data. Maybe they should also be convert to DT.
> (Or maybe compatible = "allwinner,xr819" is enough, as
> xr819 is a specified variant of cw1200 family)
Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
that? Or does cw1200 more changes than just adding the DT support?
--
Kalle Valo
^ permalink raw reply
* ✓ Fi.CI.BAT: success for igt/kms_rotation_crc: Add horizontal flip subtest.
From: Patchwork @ 2017-10-05 6:57 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <1507164223-22598-1-git-send-email-anusha.srivatsa@intel.com>
== Series Details ==
Series: igt/kms_rotation_crc: Add horizontal flip subtest.
URL : https://patchwork.freedesktop.org/series/31407/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
7f93a2632aae7c5865823b4a2fa4cd8c2a1c0977 Update NEWS, bump version to 1.20.
with latest DRM-Tip kernel build CI_DRM_3178
fee2a7481241 drm-tip: 2017y-10m-05d-06h-10m-04s UTC integration manifest
Testlist changes:
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-90
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-90
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-270
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-270
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_300/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] gpio: mcp32s08: add support for mcp23018
From: Phil Reid @ 2017-10-05 6:56 UTC (permalink / raw)
To: linus.walleij, robh+dt, mark.rutland, linux-gpio, devicetree
In-Reply-To: <1507166615-4530-3-git-send-email-preid@electromag.com.au>
On 5/10/2017 09:23, Phil Reid wrote:
> This adds the required definitions for the mcp23018 which is the i2c
> variant of the mcp23s18.
>
> Signed-off-by: Phil Reid <preid@electromag.com.au>
> ---
> drivers/gpio/gpio-mcp23s08.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
I've just noticed that this needs to be rebased as mcp23s08 driver has moved.
Other that the new location the patch is the same so far.
I have a couple of queries regarding the driver in another email, will wait for that first..
>
> diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
> index 2a57d024..92751e5 100644
> --- a/drivers/gpio/gpio-mcp23s08.c
> +++ b/drivers/gpio/gpio-mcp23s08.c
> @@ -33,6 +33,7 @@
> #define MCP_TYPE_008 2
> #define MCP_TYPE_017 3
> #define MCP_TYPE_S18 4
> +#define MCP_TYPE_018 5
>
> /* Registers are all 8 bits wide.
> *
> @@ -595,6 +596,13 @@ static int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
> mcp->chip.ngpio = 16;
> mcp->chip.label = "mcp23017";
> break;
> +
> + case MCP_TYPE_018:
> + mcp->regmap = devm_regmap_init_i2c(data, &mcp23x17_regmap);
> + mcp->reg_shift = 1;
> + mcp->chip.ngpio = 16;
> + mcp->chip.label = "mcp23018";
> + break;
> #endif /* CONFIG_I2C */
>
> default:
> @@ -640,7 +648,7 @@ static int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
> if (mirror)
> status |= IOCON_MIRROR | (IOCON_MIRROR << 8);
>
> - if (type == MCP_TYPE_S18)
> + if (type == MCP_TYPE_S18 || type == MCP_TYPE_018)
> status |= IOCON_INTCC | (IOCON_INTCC << 8);
>
> ret = mcp_write(mcp, MCP_IOCON, status);
> @@ -729,6 +737,10 @@ static int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
> .compatible = "microchip,mcp23017",
> .data = (void *) MCP_TYPE_017,
> },
> + {
> + .compatible = "microchip,mcp23018",
> + .data = (void *) MCP_TYPE_018,
> + },
> /* NOTE: The use of the mcp prefix is deprecated and will be removed. */
> {
> .compatible = "mcp,mcp23008",
> @@ -812,6 +824,7 @@ static int mcp230xx_remove(struct i2c_client *client)
> static const struct i2c_device_id mcp230xx_id[] = {
> { "mcp23008", MCP_TYPE_008 },
> { "mcp23017", MCP_TYPE_017 },
> + { "mcp23018", MCP_TYPE_018 },
> { },
> };
> MODULE_DEVICE_TABLE(i2c, mcp230xx_id);
>
--
Regards
Phil Reid
^ permalink raw reply
* [U-Boot] [PATCH v2] armv8: ls1088a: Update MC boot sequence
From: Bogdan Purcareata @ 2017-10-05 6:56 UTC (permalink / raw)
To: u-boot
The MC boot sequence is contained in mc_env_boot. Update LS1088A boards
to use this function, and hook it to reset_phy so that it's called late
enough, after the ports have been initialized, for proper DPC / DPL
fixup.
Signed-off-by: Bogdan Purcareata <bogdan.purcareata@nxp.com>
---
This patch follows the work of previous commits:
5707dfb02e drivers: net: fsl-mc: Fixup MAC addresses in DPC
33a8991a87 drivers: net: fsl-mc: Link MC boot to PHY_RESET_R
1161dbcc0a drivers: net: fsl-mc: Include MAC addr fixup to DPL
v1 -> v2:
- Refactor commit message
board/freescale/ls1088a/eth_ls1088aqds.c | 14 ++++++++------
board/freescale/ls1088a/eth_ls1088ardb.c | 13 ++++++++-----
include/configs/ls1088a_common.h | 6 ++++++
3 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c b/board/freescale/ls1088a/eth_ls1088aqds.c
index c19f59a..de70aee 100644
--- a/board/freescale/ls1088a/eth_ls1088aqds.c
+++ b/board/freescale/ls1088a/eth_ls1088aqds.c
@@ -14,14 +14,13 @@
#include <fm_eth.h>
#include <i2c.h>
#include <miiphy.h>
+#include <fsl-mc/fsl_mc.h>
#include <fsl-mc/ldpaa_wriop.h>
#include "../common/qixis.h"
#include "ls1088a_qixis.h"
-#define MC_BOOT_ENV_VAR "mcinitcmd"
-
#ifdef CONFIG_FSL_MC_ENET
#define SFP_TX 0
@@ -612,7 +611,6 @@ static void ls1088a_handle_phy_interface_rgmii(int dpmac_id)
int board_eth_init(bd_t *bis)
{
int error = 0, i;
- char *mc_boot_env_var;
#ifdef CONFIG_FSL_MC_ENET
struct memac_mdio_info *memac_mdio0_info;
char *env_hwconfig = env_get("hwconfig");
@@ -655,9 +653,6 @@ int board_eth_init(bd_t *bis)
}
}
- mc_boot_env_var = env_get(MC_BOOT_ENV_VAR);
- if (mc_boot_env_var)
- run_command_list(mc_boot_env_var, -1, 0);
error = cpu_eth_init(bis);
if (hwconfig_f("xqsgmii", env_hwconfig)) {
@@ -681,3 +676,10 @@ int board_eth_init(bd_t *bis)
error = pci_eth_init(bis);
return error;
}
+
+#if defined(CONFIG_RESET_PHY_R)
+void reset_phy(void)
+{
+ mc_env_boot();
+}
+#endif /* CONFIG_RESET_PHY_R */
diff --git a/board/freescale/ls1088a/eth_ls1088ardb.c b/board/freescale/ls1088a/eth_ls1088ardb.c
index 853d815..97accc9 100644
--- a/board/freescale/ls1088a/eth_ls1088ardb.c
+++ b/board/freescale/ls1088a/eth_ls1088ardb.c
@@ -15,15 +15,14 @@
#include <asm/io.h>
#include <exports.h>
#include <asm/arch/fsl_serdes.h>
+#include <fsl-mc/fsl_mc.h>
#include <fsl-mc/ldpaa_wriop.h>
DECLARE_GLOBAL_DATA_PTR;
-#define MC_BOOT_ENV_VAR "mcinitcmd"
int board_eth_init(bd_t *bis)
{
#if defined(CONFIG_FSL_MC_ENET)
- char *mc_boot_env_var;
int i, interface;
struct memac_mdio_info mdio_info;
struct mii_dev *dev;
@@ -92,11 +91,15 @@ int board_eth_init(bd_t *bis)
dev = miiphy_get_dev_by_name(DEFAULT_WRIOP_MDIO2_NAME);
wriop_set_mdio(WRIOP1_DPMAC2, dev);
- mc_boot_env_var = env_get(MC_BOOT_ENV_VAR);
- if (mc_boot_env_var)
- run_command_list(mc_boot_env_var, -1, 0);
cpu_eth_init(bis);
#endif /* CONFIG_FMAN_ENET */
return pci_eth_init(bis);
}
+
+#if defined(CONFIG_RESET_PHY_R)
+void reset_phy(void)
+{
+ mc_env_boot();
+}
+#endif /* CONFIG_RESET_PHY_R */
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index 84e9b14..fa058f7 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -122,6 +122,12 @@ unsigned long long get_qixis_addr(void);
#define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET 0x00F20000
#define CONFIG_SYS_LS_MC_AIOP_IMG_MAX_LENGTH 0x200000
#define CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET 0x07000000
+
+/* Define phy_reset function to boot the MC based on mcinitcmd.
+ * This happens late enough to properly fixup u-boot env MAC addresses.
+ */
+#define CONFIG_RESET_PHY_R
+
/*
* Carve out a DDR region which will not be used by u-boot/Linux
*
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols
From: Naveen N . Rao @ 2017-10-05 6:56 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Michael Ellerman, Balbir Singh, Josh Poimboeuf, Jessica Yu,
Ananth N Mavinakayanahalli, Aravinda Prasad, linuxppc-dev,
live-patching
In-Reply-To: <20171004152516.25803-1-kamalesh@linux.vnet.ibm.com>
On 2017/10/04 03:25PM, Kamalesh Babulal wrote:
> With commit 425595a7fc20 ("livepatch: reuse module loader code to
> write relocations") livepatch uses module loader to write relocations
> of livepatch symbols, instead of managing them by arch-dependent
> klp_write_module_reloc() function.
>
> livepatch module managed relocation entries are written to sections
> marked with SHF_RELA_LIVEPATCH flag and livepatch symbols within the
> section are marked with SHN_LIVEPATCH symbol section index. When the
> livepatching module is loaded, the livepatch symbols are resolved
> before calling apply_relocate_add() to apply the relocations.
>
> R_PPC64_REL24 relocation type resolves to a function address, those may
> be local to the livepatch module or available in kernel/other modules.
> For every such non-local function, apply_relocate_add() constructs a
> stub (a.k.a trampoline) to branch to a function. Stub code is
> responsible to save toc onto the stack, before calling the function via
> the global entry point. A NOP instruction is expected after every non
> local function branch, i.e. after the REL24 relocation. Which in-turn
> is replaced by toc restore instruction by apply_relocate_add().
>
> Functions those were local to livepatched function previously, may have
> become global now or they might be out of range with current TOC base.
> During module load, apply_relocate_add() fails for such global
> functions, as it expect's a nop after a branch. Which does't exist for a
> non-local function accessed via local entry point.
>
> For example, consider the following livepatch relocations (the example
> is from livepatch module generated by kpatch tool):
>
> Relocation section '.klp.rela.vmlinux..text.meminfo_proc_show' at offset
> 0x84530 contains 44 entries:
>
> Offset Info Type Symbol's Value Symbol's Name + Addend
> ... ... R_PPC64_REL24 0x0 .klp.sym.vmlinux.si_swapinfo,0 + 0
> ... ... R_PPC64_REL24 0x0 .klp.sym.vmlinux.total_swapcache_pages,0 + 0
> ... ... R_PPC64_REL24 0x0 .klp.sym.vmlinux.show_val_kb,1 + 0
> [...]
>
> 1. .klp.sym.vmlinux.si_swapinfo and .klp.sym.vmlinux.total_swapcache_pages
> are not available within the livepatch module TOC range.
>
> 2. .klp.sym.vmlinux.show_val_kb livepatch symbol was previously local
> but now global w.r.t module call fs/proc/meminfo.c::meminfo_proc_show()
>
> While the livepatch module is loaded the livepatch symbols mentioned in
> case 1 will fail with an error:
> module_64: kpatch_meminfo: REL24 -1152921504751525976 out of range!
>
> and livepatch symbols mentioned in case 2 with fail with an error:
> module_64: kpatch_meminfo: Expect noop after relocate, got 3d220000
>
> Both the failures with REL24 livepatch symbols relocation, can be
> resolved by constructing a new livepatch stub. The newly setup klp_stub
> mimics the functionality of entry_64.S::livepatch_handler introduced by
> commit 85baa095497f ("powerpc/livepatch: Add live patching support on
> ppc64le").
>
> Which introduces a "livepatch stack" growing upwards from the base of
> the regular stack and is used to store/restore TOC/LR values, other than
> the stub setup and branch. The additional instructions sequences to
> handle klp_stub increases the stub size and current ppc64_stub_insn[]
> is not sufficient to hold them. This patch also introduces new
> ppc64le_klp_stub_entry[], along with the helpers to find/allocate
> livepatch stub.
>
> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> Cc: Balbir Singh <bsingharora@gmail.com>
> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> Cc: Jessica Yu <jeyu@kernel.org>
> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
> Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: live-patching@vger.kernel.org
> ---
> This patch applies on top of livepatch_handler fix posted at
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-September/163824.html
>
> v2:
> - Changed klp_stub construction to re-use livepatch_handler and
> additional patch code required for klp_stub, instead of duplicating it.
> - Minor comments and commit body edits.
>
> arch/powerpc/include/asm/module.h | 4 +
> arch/powerpc/kernel/module_64.c | 135 ++++++++++++++++++++++++-
> arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 31 ++++++
> 3 files changed, 167 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
> index 6c0132c7212f..de22c4c7aebc 100644
> --- a/arch/powerpc/include/asm/module.h
> +++ b/arch/powerpc/include/asm/module.h
> @@ -44,6 +44,10 @@ struct mod_arch_specific {
> unsigned long toc;
> unsigned long tramp;
> #endif
> +#ifdef CONFIG_LIVEPATCH
> + /* Count of kernel livepatch relocations */
> + unsigned long klp_relocs;
> +#endif
>
> #else /* powerpc64 */
> /* Indices of PLT sections within module. */
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index 0b0f89685b67..5be955e59162 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -140,6 +140,24 @@ static u32 ppc64_stub_insns[] = {
> 0x4e800420 /* bctr */
> };
>
> +#ifdef CONFIG_LIVEPATCH
> +extern u32 klp_stub_insn[], klp_stub_insn_end[];
> +extern u32 livepatch_handler[], livepatch_handler_end[];
> +
> +struct ppc64le_klp_stub_entry {
> + /*
> + * Other than setting up the stub and livepatch stub also needs to
> + * allocate extra instructions to allocate livepatch stack,
> + * storing/restoring TOC/LR values on/from the livepatch stack.
> + */
> + u32 jump[31];
> + /* Used by ftrace to identify stubs */
> + u32 magic;
> + /* Data for the above code */
> + func_desc_t funcdata;
> +};
> +#endif
> +
> #ifdef CONFIG_DYNAMIC_FTRACE
> int module_trampoline_target(struct module *mod, unsigned long addr,
> unsigned long *target)
> @@ -239,10 +257,19 @@ static void relaswap(void *_x, void *_y, int size)
>
> /* Get size of potential trampolines required. */
> static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
> - const Elf64_Shdr *sechdrs)
> + const Elf64_Shdr *sechdrs,
> + struct module *me)
> {
> /* One extra reloc so it's always 0-funcaddr terminated */
> unsigned long relocs = 1;
> + /*
> + * size of livepatch stub is 28 instructions, whereas the
> + * non-livepatch stub requires 7 instructions. Account for
> + * different stub sizes and track the livepatch relocation
> + * count in me->arch.klp_relocs.
> + */
> + unsigned long sec_relocs = 0;
> + unsigned long klp_relocs = 0;
> unsigned i;
>
> /* Every relocated section... */
> @@ -262,9 +289,14 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
> sechdrs[i].sh_size / sizeof(Elf64_Rela),
> sizeof(Elf64_Rela), relacmp, relaswap);
>
> - relocs += count_relocs((void *)sechdrs[i].sh_addr,
> + sec_relocs = count_relocs((void *)sechdrs[i].sh_addr,
> sechdrs[i].sh_size
> / sizeof(Elf64_Rela));
> + relocs += sec_relocs;
> +#ifdef CONFIG_LIVEPATCH
> + if (sechdrs[i].sh_flags & SHF_RELA_LIVEPATCH)
> + klp_relocs += sec_relocs;
> +#endif
> }
> }
>
> @@ -273,6 +305,15 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
> relocs++;
> #endif
>
> + relocs -= klp_relocs;
> +#ifdef CONFIG_LIVEPATCH
> + me->arch.klp_relocs = klp_relocs;
> +
> + pr_debug("Looks like a total of %lu stubs, (%lu) livepatch stubs, max\n",
> + relocs, klp_relocs);
> + return (relocs * sizeof(struct ppc64_stub_entry) +
> + klp_relocs * sizeof(struct ppc64le_klp_stub_entry));
> +#endif
> pr_debug("Looks like a total of %lu stubs, max\n", relocs);
> return relocs * sizeof(struct ppc64_stub_entry);
> }
> @@ -369,7 +410,7 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
> me->arch.toc_section = me->arch.stubs_section;
>
> /* Override the stubs size */
> - sechdrs[me->arch.stubs_section].sh_size = get_stubs_size(hdr, sechdrs);
> + sechdrs[me->arch.stubs_section].sh_size = get_stubs_size(hdr, sechdrs, me);
> return 0;
> }
>
> @@ -415,6 +456,56 @@ static inline int create_stub(const Elf64_Shdr *sechdrs,
> return 1;
> }
>
> +#ifdef CONFIG_LIVEPATCH
> +/* Patch livepatch stub to reference function and correct r2 value. */
> +static inline int create_klp_stub(const Elf64_Shdr *sechdrs,
> + struct ppc64le_klp_stub_entry *entry,
> + unsigned long addr,
> + struct module *me)
> +{
> + long reladdr;
> + unsigned long klp_stub_idx, klp_stub_idx_end;
> +
> + klp_stub_idx = (klp_stub_insn - livepatch_handler);
> + klp_stub_idx_end = (livepatch_handler_end - klp_stub_insn_end);
> +
> + /* Copy first half of livepatch_handler till klp_stub_insn */
> + memcpy(entry->jump, livepatch_handler, sizeof(u32) * klp_stub_idx);
> +
> + /* Stub uses address relative to r2. */
> + reladdr = (unsigned long)entry - my_r2(sechdrs, me);
> + if (reladdr > 0x7FFFFFFF || reladdr < -(0x80000000L)) {
> + pr_err("%s: Address %p of stub out of range of %p.\n",
> + me->name, (void *)reladdr, (void *)my_r2);
> + return 0;
> + }
> + pr_debug("Stub %p get data from reladdr %li\n", entry, reladdr);
> +
> + /*
> + * Patch the code required to load the trampoline address into r11,
> + * function global entry point into r12, ctr.
> + */
> + entry->jump[klp_stub_idx++] = (PPC_INST_ADDIS | ___PPC_RT(11) |
> + ___PPC_RA(2) | PPC_HA(reladdr));
> +
> + entry->jump[klp_stub_idx++] = (PPC_INST_ADDI | ___PPC_RT(11) |
> + ___PPC_RA(11) | PPC_LO(reladdr));
> +
> + entry->jump[klp_stub_idx++] = (PPC_INST_LD | ___PPC_RT(12) |
> + ___PPC_RA(11) | 128);
^^^
Better to use offsetof().
Apart from that, the stub handling itself looks good to me.
Thanks,
Naveen
> +
> + entry->jump[klp_stub_idx++] = PPC_INST_MTCTR | ___PPC_RT(12);
> +
> + /* Copy second half of livepatch_handler starting klp_stub_insn_end */
> + memcpy(entry->jump + klp_stub_idx, klp_stub_insn_end,
> + sizeof(u32) * klp_stub_idx_end);
> +
> + entry->funcdata = func_desc(addr);
> + entry->magic = STUB_MAGIC;
> + return 1;
> +}
> +#endif
> +
> /* Create stub to jump to function described in this OPD/ptr: we need the
> stub to set up the TOC ptr (r2) for the function. */
> static unsigned long stub_for_addr(const Elf64_Shdr *sechdrs,
> @@ -441,6 +532,38 @@ static unsigned long stub_for_addr(const Elf64_Shdr *sechdrs,
> return (unsigned long)&stubs[i];
> }
>
> +#ifdef CONFIG_LIVEPATCH
> +static unsigned long klp_stub_for_addr(const Elf64_Shdr *sechdrs,
> + unsigned long addr,
> + struct module *me)
> +{
> + struct ppc64le_klp_stub_entry *klp_stubs;
> + unsigned int num_klp_stubs = me->arch.klp_relocs;
> + unsigned int i, num_stubs;
> +
> + num_stubs = (sechdrs[me->arch.stubs_section].sh_size -
> + (num_klp_stubs * sizeof(*klp_stubs))) /
> + sizeof(struct ppc64_stub_entry);
> +
> + /*
> + * Create livepatch stubs after the regular stubs.
> + */
> + klp_stubs = (void *)sechdrs[me->arch.stubs_section].sh_addr +
> + (num_stubs * sizeof(struct ppc64_stub_entry));
> + for (i = 0; stub_func_addr(klp_stubs[i].funcdata); i++) {
> + BUG_ON(i >= num_klp_stubs);
> +
> + if (stub_func_addr(klp_stubs[i].funcdata) == func_addr(addr))
> + return (unsigned long)&klp_stubs[i];
> + }
> +
> + if (!create_klp_stub(sechdrs, &klp_stubs[i], addr, me))
> + return 0;
> +
> + return (unsigned long)&klp_stubs[i];
> +}
> +#endif
> +
> #ifdef CC_USING_MPROFILE_KERNEL
> static bool is_early_mcount_callsite(u32 *instruction)
> {
> @@ -622,6 +745,12 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
> return -ENOEXEC;
>
> squash_toc_save_inst(strtab + sym->st_name, value);
> +#ifdef CONFIG_LIVEPATCH
> + } else if (sym->st_shndx == SHN_LIVEPATCH) {
> + value = klp_stub_for_addr(sechdrs, value, me);
> + if (!value)
> + return -ENOENT;
> +#endif
> } else
> value += local_entry_offset(sym);
>
> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> index b4e2b7165f79..a4e97cb9da91 100644
> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> @@ -183,7 +183,10 @@ _GLOBAL(ftrace_stub)
> * - CTR holds the new NIP in C
> * - r0, r11 & r12 are free
> */
> +
> + .global livepatch_handler
> livepatch_handler:
> +
> CURRENT_THREAD_INFO(r12, r1)
>
> /* Allocate 3 x 8 bytes */
> @@ -201,8 +204,33 @@ livepatch_handler:
> ori r12, r12, STACK_END_MAGIC@l
> std r12, -8(r11)
>
> + /*
> + * klp_stub_insn/klp_stub_insn_end marks the beginning/end of the
> + * additional instructions, which gets patched by create_klp_stub()
> + * for livepatch symbol relocation stub. The instructions are:
> + *
> + * Load TOC relative address into r11. module_64.c::klp_stub_for_addr()
> + * identifies the available free stub slot and loads the address into
> + * r11 with two instructions.
> + *
> + * addis r11, r2, stub_address@ha
> + * addi r11, r11, stub_address@l
> + *
> + * Load global entry into r12 from entry->funcdata offset
> + * ld r12, 128(r11)
> + *
> + * Put r12 into ctr and branch there
> + * mtctr r12
> + */
> +
> + .global klp_stub_insn
> +klp_stub_insn:
> +
> /* Put ctr in r12 for global entry and branch there */
> mfctr r12
> +
> + .global klp_stub_insn_end
> +klp_stub_insn_end:
> bctrl
>
> /*
> @@ -234,6 +262,9 @@ livepatch_handler:
>
> /* Return to original caller of live patched function */
> blr
> +
> + .global livepatch_handler_end
> +livepatch_handler_end:
> #endif /* CONFIG_LIVEPATCH */
>
> #endif /* CONFIG_DYNAMIC_FTRACE */
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER
From: Kalle Valo @ 2017-10-05 6:54 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Arnd Bergmann,
Benjamin Herrenschmidt, Chris Metcalf, Geert Uytterhoeven,
Greg Kroah-Hartman, Guenter Roeck, Harish Patil, Heiko Carstens,
James E.J. Bottomley, John Stultz, Julian Wiedmann, Lai Jiangshan,
Len Brown, Manish Chopra, Mark Gross, Martin K. Petersen,
Martin Schwidefsky, Michael Ellerman, Michael Reed, netdev,
Oleg Nesterov, Paul Mackerras, Pavel Machek
In-Reply-To: <1507159627-127660-11-git-send-email-keescook@chromium.org>
Kees Cook <keescook@chromium.org> writes:
> Drop the arguments from the macro and adjust all callers with the
> following script:
>
> perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # for m68k parts
[...]
> drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
For wireless:
Acked-by: Kalle Valo <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* RFI: pinctrl & mcp32s08 driver
From: Phil Reid @ 2017-10-05 6:54 UTC (permalink / raw)
To: linus.walleij, linux-gpio@vger.kernel.org
G'day All,
The mcp32s08 driver was recently moved from the drivers/gpio to drivers/pinctlr.
My system (SOCFPGA) doesn't have a pinctrl so it never set kconfig PINCTRL variable.
So I can't get access to enable the new PINCTRL_MCP23S08 variable to enable the driver.
Not sure what I'm supposed to do here. Documentation suggests pinctrl is platform specific,
but the mcp32s08 driver isn't really soc specific being an i2c/spi device.
For testing I've edited the pinctrl/Kconfig to make PINCTRL a menuconfig variable same as GPIOLIB
In addition my hardware has a mcp23017 & mcp23018 sharing an irq line.
So this requires an active low open drain output.
This line is then routed via fpga fabric to the SOCFPGA arm processor generic interrupt input
which only accepts active high inputs. So it's inverted in the fpga fabric.
The mcp23s08 driver in mcp23s08_irq_setup forces the irq flag based on the chip
configuration. Which breaks this.
ie setting IRQ_TYPE_LEVEL_HIGH in the device tree for the mcp irq is effectively ignored.
What's the correct approach here. Shouldn't this just honour the device tree?
Also noticed when compiling the driver in new mcp_pinconf_set()
case PIN_CONFIG_BIAS_PULL_UP:
val = arg ? 0xFFFF : 0x0000;
mask = BIT(pin);
ret = mcp_set_bit(mcp, MCP_GPPU, pin, arg);
break;
val & mask aren't used.
I'm not sure which part is the typo.
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER
From: Kalle Valo @ 2017-10-05 6:54 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Arnd Bergmann,
Benjamin Herrenschmidt, Chris Metcalf, Geert Uytterhoeven,
Greg Kroah-Hartman, Guenter Roeck, Harish Patil, Heiko Carstens,
James E.J. Bottomley, John Stultz, Julian Wiedmann, Lai Jiangshan,
Len Brown, Manish Chopra, Mark Gross, Martin K. Petersen,
Martin Schwidefsky, Michael Ellerman, Michael Reed, netdev,
Oleg Nesterov, Paul Mackerras, Pavel Machek, cw.cz, Petr Mladek,
Rafael J. Wysocki, Ralf Baechle, Sebastian Reichel,
Stefan Richter, Stephen Boyd, Sudip Mukherjee, Tejun Heo,
Ursula Braun, Viresh Kumar, Wim Van Sebroeck, linux1394-devel,
linux-mips, linux-pm, linuxppc-dev, linux-s390, linux-scsi,
linux-watchdog, linux-wireless, linux-kernel
In-Reply-To: <1507159627-127660-11-git-send-email-keescook@chromium.org>
Kees Cook <keescook@chromium.org> writes:
> Drop the arguments from the macro and adjust all callers with the
> following script:
>
> perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # for m68k parts
[...]
> drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
For wireless:
Acked-by: Kalle Valo <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] x86/kvm: Move kvm_fastop_exception to .fixup section
From: Paolo Bonzini @ 2017-10-05 6:54 UTC (permalink / raw)
To: Josh Poimboeuf, Radim Krčmář
Cc: x86, linux-kernel, kvm, Guenter Roeck
In-Reply-To: <e974660207b99b822309c09365bf953080131791.1507131424.git.jpoimboe@redhat.com>
On 04/10/2017 17:39, Josh Poimboeuf wrote:
> When compiling the kernel with the '-frecord-gcc-switches' flag, objtool
> complains:
>
> arch/x86/kvm/emulate.o: warning: objtool: .GCC.command.line+0x0: special: can't find new instruction
>
> And also the kernel fails to link.
>
> The problem is that the 'kvm_fastop_exception' code gets placed into the
> throwaway '.GCC.command.line' section instead of '.text'.
>
> Exception fixup code is conventionally placed in the '.fixup' section,
> so put it there where it belongs.
>
> Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> arch/x86/kvm/emulate.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index a36254cbf776..d90cdc77e077 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -425,8 +425,10 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void (*fop)(struct fastop *));
> #op " %al \n\t" \
> FOP_RET
>
> -asm(".global kvm_fastop_exception \n"
> - "kvm_fastop_exception: xor %esi, %esi; ret");
> +asm(".pushsection .fixup, \"ax\"\n"
> + ".global kvm_fastop_exception \n"
> + "kvm_fastop_exception: xor %esi, %esi; ret\n"
> + ".popsection");
>
> FOP_START(setcc)
> FOP_SETCC(seto)
>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.