* [PATCH 2/2] block: add support for async simple direct-io for bdevs
From: Jens Axboe @ 2016-11-14 17:28 UTC (permalink / raw)
To: axboe, linux-block; +Cc: hch, Jens Axboe
In-Reply-To: <1479144519-15738-1-git-send-email-axboe@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
---
fs/block_dev.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 66 insertions(+), 10 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2010997fd326..62ca4ce21222 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -176,9 +176,68 @@ static struct inode *bdev_file_inode(struct file *file)
return file->f_mapping->host;
}
+static void blkdev_bio_end_io_async(struct bio *bio)
+{
+ struct kiocb *iocb = bio->bi_private;
+
+ iocb->ki_complete(iocb, bio->bi_error, 0);
+
+ if (bio_op(bio) == REQ_OP_READ)
+ bio_check_pages_dirty(bio);
+ else
+ bio_put(bio);
+}
+
+static ssize_t
+__blkdev_direct_IO_async(struct kiocb *iocb, struct iov_iter *iter,
+ int nr_pages)
+{
+ struct file *file = iocb->ki_filp;
+ struct block_device *bdev = I_BDEV(bdev_file_inode(file));
+ unsigned blkbits = blksize_bits(bdev_logical_block_size(bdev));
+ loff_t pos = iocb->ki_pos;
+ struct bio *bio;
+ ssize_t ret;
+
+ if ((pos | iov_iter_alignment(iter)) & ((1 << blkbits) - 1))
+ return -EINVAL;
+
+ bio = bio_alloc(GFP_KERNEL, nr_pages);
+ if (!bio)
+ return -ENOMEM;
+
+ bio->bi_bdev = bdev;
+ bio->bi_iter.bi_sector = pos >> blkbits;
+ bio->bi_private = iocb;
+ bio->bi_end_io = blkdev_bio_end_io_async;
+
+ ret = bio_iov_iter_get_pages(bio, iter);
+ if (unlikely(ret))
+ return ret;
+
+ /*
+ * Overload bio size in error. If it gets set, we lose the
+ * size, but we don't need the size for that case. IO is limited
+ * to BIO_MAX_PAGES, so we can't overflow.
+ */
+ ret = bio->bi_error = bio->bi_iter.bi_size;
+
+ if (iov_iter_rw(iter) == READ) {
+ bio_set_op_attrs(bio, REQ_OP_READ, 0);
+ bio_set_pages_dirty(bio);
+ } else {
+ bio_set_op_attrs(bio, REQ_OP_WRITE, REQ_SYNC | REQ_IDLE);
+ task_io_account_write(ret);
+ }
+
+ submit_bio(bio);
+ iocb->ki_pos += ret;
+ return -EIOCBQUEUED;
+}
+
#define DIO_INLINE_BIO_VECS 4
-static void blkdev_bio_end_io_simple(struct bio *bio)
+static void blkdev_bio_end_io_sync(struct bio *bio)
{
struct task_struct *waiter = bio->bi_private;
@@ -187,8 +246,7 @@ static void blkdev_bio_end_io_simple(struct bio *bio)
}
static ssize_t
-__blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
- int nr_pages)
+__blkdev_direct_IO_sync(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
{
struct file *file = iocb->ki_filp;
struct block_device *bdev = I_BDEV(bdev_file_inode(file));
@@ -218,7 +276,7 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
bio.bi_bdev = bdev;
bio.bi_iter.bi_sector = pos >> blkbits;
bio.bi_private = current;
- bio.bi_end_io = blkdev_bio_end_io_simple;
+ bio.bi_end_io = blkdev_bio_end_io_sync;
ret = bio_iov_iter_get_pages(&bio, iter);
if (unlikely(ret))
@@ -263,18 +321,16 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
static ssize_t
blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
{
- struct file *file = iocb->ki_filp;
- struct inode *inode = bdev_file_inode(file);
int nr_pages;
nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
if (!nr_pages)
return 0;
+
if (is_sync_kiocb(iocb))
- return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
- return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
- blkdev_get_block, NULL, NULL,
- DIO_SKIP_DIO_COUNT);
+ return __blkdev_direct_IO_sync(iocb, iter, nr_pages);
+
+ return __blkdev_direct_IO_async(iocb, iter, nr_pages);
}
int __sync_blockdev(struct block_device *bdev, int wait)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] block: support any sized IO for simplified bdev direct-io
From: Jens Axboe @ 2016-11-14 17:28 UTC (permalink / raw)
To: axboe, linux-block; +Cc: hch, Jens Axboe
In-Reply-To: <1479144519-15738-1-git-send-email-axboe@fb.com>
Just alloc the bio_vec array if we exceed the inline limit.
Signed-off-by: Jens Axboe <axboe@fb.com>
---
fs/block_dev.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 7c3ec6049073..2010997fd326 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -193,7 +193,7 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
struct file *file = iocb->ki_filp;
struct block_device *bdev = I_BDEV(bdev_file_inode(file));
unsigned blkbits = blksize_bits(bdev_logical_block_size(bdev));
- struct bio_vec inline_vecs[DIO_INLINE_BIO_VECS], *bvec;
+ struct bio_vec inline_vecs[DIO_INLINE_BIO_VECS], *vecs, *bvec;
loff_t pos = iocb->ki_pos;
bool should_dirty = false;
struct bio bio;
@@ -204,9 +204,17 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
if ((pos | iov_iter_alignment(iter)) & ((1 << blkbits) - 1))
return -EINVAL;
+ if (nr_pages <= DIO_INLINE_BIO_VECS)
+ vecs = inline_vecs;
+ else {
+ vecs = kmalloc(nr_pages * sizeof(struct bio_vec), GFP_KERNEL);
+ if (!vecs)
+ return -ENOMEM;
+ }
+
bio_init(&bio);
bio.bi_max_vecs = nr_pages;
- bio.bi_io_vec = inline_vecs;
+ bio.bi_io_vec = vecs;
bio.bi_bdev = bdev;
bio.bi_iter.bi_sector = pos >> blkbits;
bio.bi_private = current;
@@ -243,6 +251,9 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
put_page(bvec->bv_page);
}
+ if (vecs != inline_vecs)
+ kfree(vecs);
+
if (unlikely(bio.bi_error))
return bio.bi_error;
iocb->ki_pos += ret;
@@ -259,7 +270,7 @@ blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
if (!nr_pages)
return 0;
- if (is_sync_kiocb(iocb) && nr_pages <= DIO_INLINE_BIO_VECS)
+ if (is_sync_kiocb(iocb))
return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
blkdev_get_block, NULL, NULL,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] ARM64: configs: Activate Internal PHY for Meson GXL
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: Neil Armstrong; +Cc: carlo, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20161114094250.25059-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/configs/defconfig | 3 +++
> 1 file changed, 3 insertions(+)
Appled to v4.10/defconfig,
Kevin
^ permalink raw reply
* [PATCHSET] Add support for simplified async direct-io
From: Jens Axboe @ 2016-11-14 17:28 UTC (permalink / raw)
To: axboe, linux-block; +Cc: hch
This is on top of for-4.10/dio, which has Christophs simplified sync
O_DIRECT support and the IO poll bits.
The restriction on 4 inline vecs is removed on the sync support, we
just allocate the bio_vec array if we have to. I realize this negates
parts of the win of the patch for sync, but it's still a lot leaner
than the old code. And it means we use the same path for any type
of sync O_DIRECT, instead of potentially bouncing between the two.
Second patch is adding async support for the code base. Lightly
tested. Performance results, from fio:
Before patch:
Treads x QD IOPS usr sys
=============================================
1x1 113K 19.8% 24.6%
1x4 321K 30.9% 65.9%
4x4 759K 19.9% 42.2%
After patch:
Treads x QD IOPS usr sys
=============================================
1x1 116K 21.8% 20.2%
1x4 365K 25.3% 72.9%
4x4 818K 20.7% 42.3%
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] driver: ublox: fix memory leak in release
From: Denis Kenzior @ 2016-11-14 17:28 UTC (permalink / raw)
To: ofono
In-Reply-To: <1479137074-7587-1-git-send-email-dragos@endocode.com>
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
Hi Dragos,
On 11/14/2016 09:24 AM, Dragos Tatulea wrote:
> ---
> drivers/ubloxmodem/gprs-context.c | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH v4 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Rob Herring @ 2016-11-14 17:28 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, linux-arm-kernel,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman
In-Reply-To: <20161109115715.2557-4-romain.perier@free-electrons.com>
On Wed, Nov 09, 2016 at 12:57:15PM +0100, Romain Perier wrote:
> This commit documents the compatible string to have the compatibility for
> the I2C unit found in the Armada 3700.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>
> Changes in v2:
> - Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
> and not "marvell,armada-3700".
>
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM64: configs: Activate Internal PHY for Meson GXL
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094250.25059-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/configs/defconfig | 3 +++
> 1 file changed, 3 insertions(+)
Appled to v4.10/defconfig,
Kevin
^ permalink raw reply
* [PATCH] ARM64: configs: Activate Internal PHY for Meson GXL
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <20161114094250.25059-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/configs/defconfig | 3 +++
> 1 file changed, 3 insertions(+)
Appled to v4.10/defconfig,
Kevin
^ permalink raw reply
* [PATCH v4 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Rob Herring @ 2016-11-14 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109115715.2557-4-romain.perier@free-electrons.com>
On Wed, Nov 09, 2016 at 12:57:15PM +0100, Romain Perier wrote:
> This commit documents the compatible string to have the compatibility for
> the I2C unit found in the Armada 3700.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>
> Changes in v2:
> - Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
> and not "marvell,armada-3700".
>
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/3] ARM64: dts: meson-gxl: Enable Ethernet
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: Neil Armstrong
Cc: carlo, linux-amlogic, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20161107104357.24428-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
> external RGMII pins.
>
> The internal PHY is added in the GXL dtsi and support for each
> board is added in intermediate board family dtsi or final dts.
Tested external phy and internal phy (using p231 DT) on my p230 board.
Applied to v4.10/dt64
Kevin
^ permalink raw reply
* [PATCH 0/3] ARM64: dts: meson-gxl: Enable Ethernet
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107104357.24428-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
> external RGMII pins.
>
> The internal PHY is added in the GXL dtsi and support for each
> board is added in intermediate board family dtsi or final dts.
Tested external phy and internal phy (using p231 DT) on my p230 board.
Applied to v4.10/dt64
Kevin
^ permalink raw reply
* [PATCH 0/3] ARM64: dts: meson-gxl: Enable Ethernet
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <20161107104357.24428-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
> external RGMII pins.
>
> The internal PHY is added in the GXL dtsi and support for each
> board is added in intermediate board family dtsi or final dts.
Tested external phy and internal phy (using p231 DT) on my p230 board.
Applied to v4.10/dt64
Kevin
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Rob Herring @ 2016-11-14 17:27 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd, David Woodhouse, Brian Norris, Boris Brezillon,
Marek Vasut, Richard Weinberger, Cyrille Pitchen, devicetree,
Mark Rutland, Joel Stanley
In-Reply-To: <1478688149-4554-1-git-send-email-clg@kaod.org>
On Wed, Nov 09, 2016 at 11:42:29AM +0100, Cédric Le Goater wrote:
> This driver adds mtd support for spi-nor attached to either or both of
> the Firmware Memory Controller or the SPI Flash Controller (AST2400
> only).
>
> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
> ones found on the AST2400. The differences are on the number of
> supported flash modules and their default mappings in the SoC address
> space.
>
> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
> for the host firmware. All controllers have now the same set of
> registers compatible with the AST2400 FMC controller and the legacy
> 'SMC' controller is fully gone.
>
> Each controller has a memory range on which it maps its flash module
> slaves. Each slave is assigned a memory window for its mapping that
> can be changed at bootime with the Segment Address Register.
>
> Each SPI flash slave can then be accessed in two modes: Command and
> User. When in User mode, accesses to the memory segment of the slaves
> are translated in SPI transfers. When in Command mode, the HW
> generates the SPI commands automatically and the memory segment is
> accessed as if doing a MMIO.
>
> Currently, only the User mode is supported. Command mode needs a
> little more work to check that the memory window on the AHB bus fits
> the module size.
>
> Based on previous work from Milton D. Miller II <miltonm@us.ibm.com>
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> Tested on:
>
> * OpenPOWER Palmetto (AST2400) with
> FMC controller : n25q256a
> SPI controller : mx25l25635e and n25q512ax3
>
> * Evaluation board (AST2500) with
> FMC controller : w25q256
> SPI controller : w25q256
>
> * OpenPOWER Witherspoon (AST2500) with
> FMC controller : mx25l25635e * 2
> SPI controller : mx66l1g45g
>
> Changes since v2:
>
> - added a set4b ops to handle difference in the controllers
> - simplified the IO routines
> - prepared for fast read using dummy cycles
>
> Work in progress:
>
> - read optimization using higher SPI clock frequencies
> - command mode to direct reads from AHB
> - DMA support
>
> .../devicetree/bindings/mtd/aspeed-smc.txt | 72 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/mtd/spi-nor/Kconfig | 12 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/aspeed-smc.c | 783 +++++++++++++++++++++
> 4 files changed, 868 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
> create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
^ permalink raw reply
* Re: [alsa-devel] [RFC 05/14] SoundWire: Add SoundWire bus driver interfaces
From: Pierre-Louis Bossart @ 2016-11-14 17:28 UTC (permalink / raw)
To: Mark Brown, Hardik Shah
Cc: alsa-devel, tiwai, plai, lgirdwood, linux-kernel, patches.audio,
Sanyog Kale
In-Reply-To: <20161114131726.qo5gqfqoey5usxiy@sirena.org.uk>
Thanks for the reviews Mark, comment below:
On 11/14/16 7:17 AM, Mark Brown wrote:
> On Fri, Oct 21, 2016 at 06:11:03PM +0530, Hardik Shah wrote:
>> This patch adds the SoundWire bus driver interfaces for following.
>>
>> 1. APIs to register/unregister SoundWire Master device and driver.
>> 2. APIs to register/unregister SoundWire Slave driver.
>> 3. API to Read/Write Slave registers.
>> 4. API for Master driver to update Slave status to bus driver.
>> 5. APIs for Master driver to prepare and initiate clock stop.
>> 6. APIs for SoundWire stream configuration.
>> 7. APIs to prepare, enable, deprepare and disable SoundWire stream.
>
> This is a very large patch (85K, 2000 lines) and the changelog is just a
> long list of different things being added. This suggests that you could
> easily split the patch up along the lines you've given above which would
> make it a lot more digestable, as it is it's really hard to review. It
> is also very hard to review because it's pure header, there's none of
> the implementation in here, which makes it hard to see how things are
> going to be used.
I am probably to blame for this since I wanted to a have all prototypes
in a single file to make my review easier and check that the exposed
functionality matches the spec requirements. If the spec is implemented
in various increments it makes it more difficult to check for
consistency, but you are correct that for someone looking at code for
the first time without prior experience with SoundWire it may be too
complicated.
>
> At a very high level this doesn't look or feel like normal Linux code,
> there's some obvious coding style stuff, a bunch of things that look
> like this was copied from legacy code and perhaps most worryingly all
> the stuff about a "bus driver" which doesn't seem to fit with the normal
> Linux models at all.
Yes agree. The patches were released ahead of the Audio Miniconference
and there are known issues with the coding style that will be fixed. And
the 'bus driver' part will be fixed as well, i don't view it as a
fundamental design issue but more awkward wording.
>
>> +/**
>> + * sdw_slave_addr: Structure representing the read-only unique device ID
>> + * and the SoundWire logical device number (assigned by bus driver).
>
> With the name of this structure I was expecting it to represent an
> address in the same way that an in_addr is an IP address but really it's
> a bundle of several different addresses and runtime state associated
> with them. This is going to cause confusion I imagine, it seems better
> to rename it or bundle it into the slave struct.
It really is the mapping between the read-only information exposed by
the Slave and the logical address configured by the bus. Maybe we can
rename it but that mapping is required.
>
>> +/**
>> + * sdw_dpn_caps: Capabilities of the Data Port, other than Data Port 0 for
>> + * SoundWire Master and Slave. This follows the definitions in the
>
> Why not just _dp_caps?
SoundWire makes a distinction between Port0 and PortN (1..15). the
former is to reclaim parts of the audio transport bandwidth for fast
control/configurations, the latter are for true audio transports. there
are different configurations/capabilities for DP0 and DPN.
>
>> + * @max_bps: Maximum bits per sample supported by Port. This is same as word
>> + * length in SoundWire Spec.
>
> Might be better to rename all these _bps variables to _wl or something -
> bps looks like bits per second which is going to confuse people.
That's what we used in the SoundWire DisCo document (in press). Word
Length is equally confusing for folks who believe a word is 16 bits.
>
>> +/**
>> + * sdw_prepare_ch: Prepare/De-prepare the Data Port channel. This is similar
>> + * to the prepare API of Alsa, where most of the hardware interfaces
>> + * are prepared for the playback/capture to start. All the parameters
>> + * are known to the hardware at this point for starting
>> + * playback/capture next.
>
> This is information used for preparing or depreparing, the description
> reads like this is a function.
Yes, will be fixed.
>
>> + * @num: Port number.
>> + * @ch_mask: Channels to be prepared/deprepared specified by ch_mask.
>> + * @prepare: Prepare/de-prepare channel, true (prepare) or false
>> + * (de-prepare).
>
> Do actual implementations look like something other than an if
> statement with two unrelated halves?
There is a prepare register field which is either set or cleared. there
aren't two parts in the function. We should clarify this.
>
>> + * @bank: Register bank, which bank Slave/Master driver should program for
>> + * implementation defined registers. This is the inverted value of the
>> + * current bank.
>
> If this is the inverted value of the current bank should we not just
> look at the current bank?
We should update the wording, the intent is that you program the new
setup in the alternate bank then switch banks.
>
>> + * @r_w_flag: Read/Write operation. Read(0) or Write(1) based on above #def
>
> Which above #define? (please write out #define fully too). I'm also
> noticing lots of random capitalisation in the comments in this patch.
Most of the capitalisation isn't random but follows the SoundWire spec
definitions. I think this was mentioned upfront in the header, if this
was missed then we need to clarify.
>
>> +/**
>> + * sdw_msg: Message to be sent on bus. This is similar to i2c_msg on I2C
>> + * bus. Message is sent from the bus driver to the Slave device. Slave
>> + * driver can also initiate transfer of the message to program
>> + * implementation defined registers. Message is formatted and
>> + * transmitted on to the bus by Master interface in hardware-specific
>> + * way. Bus driver initiates the Master interface callback to transmit
>> + * the message on bus.
>> + *
>> + * @addr: Address of the register to be read.
>
> Only reads?
no, this should be accessed for read or write.
>
>> + * @frame_rate: Audio frame rate of the stream (not the bus frame rate
>> + * defining command bandwidth).
>
> In units of...?
Hz. will be corrected.
>
>> +/**
>> + * snd_sdw_alloc_stream_tag: Allocates unique stream_tag. Stream tag is
>> + * a unique identifier for each SoundWire stream across all SoundWire
>> + * bus instances. Stream tag is a software concept defined by bus
>> + * driver for stream management and not by MIPI SoundWire Spec. Each
>> + * SoundWire Stream is individually configured and controlled using the
>> + * stream tag. Multiple Master(s) and Slave(s) associated with the
>> + * stream, uses stream tag as an identifier. All the operations on the
>> + * stream e.g. stream configuration, port configuration, prepare and
>> + * enable of the ports are done based on stream tag. This API shall be
>> + * called once per SoundWire stream either by the Master or Slave
>> + * associated with the stream.
>> + *
>> + * @stream_tag: Stream tag returned by bus driver.
>> + */
>> +int snd_sdw_alloc_stream_tag(unsigned int *stream_tag);
>
> In Linux we put documentation for functions next to their
> implementation not their prototype. This also doesn't look like good
> kerneldoc - normally we'd have a separate paragraph for the summary.
>
> This sort of stylistic stuff is important not just for itself but also
> because it's a warning sign that the code hasn't been written by someone
> who's really familiar with how things are expected to look and work in
> terms of the kernel internal abstractions.
yes Vinod made that comment as well but I asked that the patches be
shared without additional delays. This will be fixed.
>
>> + * @slv_list: List of SoundWire Slaves registered to the bus.
>
> The driver model already maintains a list of devices on a bus, why are
> we maintaining a separate one?
>
>> + * @sdw_addr: Array containing Slave SoundWire bus Slave address
>> + * information. Its a part of Slave list as well, but for easier access
>> + * its part of array to find the Slave reference by directly indexing
>> + * the Slave number into the array.
>
> This seems like a worrying idea... I'd be entirely unsurprised if this
> cache went wrong, are we sure we need the optimisation?
There will be additional changes to simplify the master/slave
definitions. It's not clear to me if all these optimizations are needed
either, if they create confusion or concern then we should really fix this.
>
>> + * @num_slv: Number of SoundWire Slaves assigned DeviceNumber after
>> + * enumeration. The SoundWire specification does not place a
>> + * restriction on how many Slaves are physically connected, as long as
>> + * only 11 are active concurrently. This bus driver adds a pragmatic
>> + * restriction to 11 Slaves, the current implementation assigns a
>> + * DeviceNumber once and will never use the same DeviceNumber for
>> + * different devices.
>
> This is not a driver, it is a bus. Please do not refer to it as a
> driver, that's at best confusing and at worst worrying. It's also
> unclear why we're maintaining this count separately to the driver model.
Point taken.
>
>> + char name[SOUNDWIRE_NAME_SIZE];
>> + struct sdw_slave_addr sdw_addr[SDW_MAX_DEVICES];
>
> Best to use SDW_ consistently.
Yes.
>
>> +/**
>> + * sdw_master_driver: Manage SoundWire Master device driver.
>> + *
>> + * @driver_type: To distinguish between Master and Slave driver. This should
>> + * be set by driver based on its handling Slave or Master SoundWire
>> + * interface.
>> + *
>> + * @probe: Binds this driver to a SoundWire Master.
>> + * @remove: Unbinds this driver from the SoundWire Master.
>> + * @shutdown: Standard shutdown callback used during power down/halt.
>> + * @suspend: Standard suspend callback used during system suspend
>> + * @resume: Standard resume callback used during system resume
>
> Modern buses have moved to using dev_pm_ops which enables them to use a
> lot of generic code for power management implementation.
Point taken.
>
>> + * @driver: SoundWire device drivers should initialize name and owner field
>> + * of this structure.
>
> Initializing .owner shouldn't be required with kernels from the past few
> years.
yes the comment is bad and 0-day flags this.
>
>> +/**
>> + * snd_sdw_master_get: Return the Master handle from Master number.
>> + * Increments the reference count of the module. Similar to
>> + * i2c_get_adapter.
>> + *
>> + * @nr: Master number.
>> + *
>> + * Returns Master handle on success, else NULL
>> + */
>> +struct sdw_master *snd_sdw_master_get(int nr);
>
> This is a legacy interface for I2C, why are we adding it for a new bus?
Good point, this was missed.
>
>> + * @portn_mask: Implementation defined mask for Slave Ports other than port0.
>> + * Mask bits are exactly same as defined in MIPI Spec 1.1. Array size
>> + * shall be same as number of Ports in Slave. For bidirectional ports,
>> + * masks can be different for Source and Sink ports.
>
> Is this implementation defined or spec defined? It's really non-obvious
> what these implementation defined things actually mean or do.
Yes the wording was bad, it's not implementation defined. It's a
standard feature but implementations can select a single-direction port
or dual-direction port (one direction at a time). In the latter case the
direction is set prior to enabling transport. This functionality was
added to help designers save gates.
>
>> +struct sdw_slave {
>> + struct device dev;
>> + struct sdw_master *mstr;
>
> Why do we have a direct reference to the master here? Shouldn't this
> just be the parent of the device?
yes this will be simplified/corrected.
^ permalink raw reply
* Re: [PATCH net 2/2] r8152: rx descriptor check
From: David Miller @ 2016-11-14 17:27 UTC (permalink / raw)
To: hayeswang; +Cc: mlord, netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB20104EBCC@RTITMBSV03.realtek.com.tw>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 14 Nov 2016 07:23:51 +0000
> Mark Lord [mailto:mlord@pobox.com]
>> Sent: Monday, November 14, 2016 4:34 AM
> [...]
>> Perhaps the driver
>> is somehow accessing the buffer space again after doing usb_submit_urb()?
>> That would certainly produce this kind of behaviour.
>
> I don't think so. First, the driver only read the received buffer.
> That is, the driver would not change (or write) the data. Second,
> The driver would lose the point address of the received buffer
> after submitting the urb to the USB host controller, until the
> transfer is completed by the USB host controller. That is, the
> driver doesn't how to access the buffer after calling usb_submit_urb().
This is why it's most likely some DMA implementation issue or similar.
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Rob Herring @ 2016-11-14 17:27 UTC (permalink / raw)
To: Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Joel Stanley
In-Reply-To: <1478688149-4554-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Wed, Nov 09, 2016 at 11:42:29AM +0100, Cédric Le Goater wrote:
> This driver adds mtd support for spi-nor attached to either or both of
> the Firmware Memory Controller or the SPI Flash Controller (AST2400
> only).
>
> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
> ones found on the AST2400. The differences are on the number of
> supported flash modules and their default mappings in the SoC address
> space.
>
> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
> for the host firmware. All controllers have now the same set of
> registers compatible with the AST2400 FMC controller and the legacy
> 'SMC' controller is fully gone.
>
> Each controller has a memory range on which it maps its flash module
> slaves. Each slave is assigned a memory window for its mapping that
> can be changed at bootime with the Segment Address Register.
>
> Each SPI flash slave can then be accessed in two modes: Command and
> User. When in User mode, accesses to the memory segment of the slaves
> are translated in SPI transfers. When in Command mode, the HW
> generates the SPI commands automatically and the memory segment is
> accessed as if doing a MMIO.
>
> Currently, only the User mode is supported. Command mode needs a
> little more work to check that the memory window on the AHB bus fits
> the module size.
>
> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
> Tested on:
>
> * OpenPOWER Palmetto (AST2400) with
> FMC controller : n25q256a
> SPI controller : mx25l25635e and n25q512ax3
>
> * Evaluation board (AST2500) with
> FMC controller : w25q256
> SPI controller : w25q256
>
> * OpenPOWER Witherspoon (AST2500) with
> FMC controller : mx25l25635e * 2
> SPI controller : mx66l1g45g
>
> Changes since v2:
>
> - added a set4b ops to handle difference in the controllers
> - simplified the IO routines
> - prepared for fast read using dummy cycles
>
> Work in progress:
>
> - read optimization using higher SPI clock frequencies
> - command mode to direct reads from AHB
> - DMA support
>
> .../devicetree/bindings/mtd/aspeed-smc.txt | 72 ++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/mtd/spi-nor/Kconfig | 12 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/aspeed-smc.c | 783 +++++++++++++++++++++
> 4 files changed, 868 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
> create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 0/5] net: thunderx: Miscellaneous fixes
From: Sunil Kovvuri @ 2016-11-14 17:27 UTC (permalink / raw)
To: Matthias Brugger
Cc: Linux Netdev List, Sunil Goutham, LKML, LAKML, Robert Richter
In-Reply-To: <2948c47d-0f15-8153-440b-7a2c753b7251@suse.com>
>>If so, please add "Cc: stable@vger.kernel.org" to the Sigend-off list.
Yes they are, thanks, will do that along with resubmission.
Sunil.
^ permalink raw reply
* Re: [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: Sunil Kovvuri @ 2016-11-14 17:27 UTC (permalink / raw)
To: Matthias Brugger
Cc: Robert Richter, Linux Netdev List, Sunil Goutham, LKML, LAKML
In-Reply-To: <2948c47d-0f15-8153-440b-7a2c753b7251@suse.com>
>>If so, please add "Cc: stable@vger.kernel.org" to the Sigend-off list.
Yes they are, thanks, will do that along with resubmission.
Sunil.
^ permalink raw reply
* [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: Sunil Kovvuri @ 2016-11-14 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2948c47d-0f15-8153-440b-7a2c753b7251@suse.com>
>>If so, please add "Cc: stable at vger.kernel.org" to the Sigend-off list.
Yes they are, thanks, will do that along with resubmission.
Sunil.
^ permalink raw reply
* Re: [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: Moritz Fischer @ 2016-11-14 17:26 UTC (permalink / raw)
To: atull
Cc: Linux Kernel Mailing List, moritz.fischer.private, Michal Simek,
Sören Brinkmann, linux-arm-kernel, Julia Cartwright
In-Reply-To: <alpine.DEB.2.10.1611140801480.2786@atull-VirtualBox>
Hi Alan,
On Mon, Nov 14, 2016 at 6:06 AM, atull <atull@opensource.altera.com> wrote:
> On Mon, 7 Nov 2016, Moritz Fischer wrote:
>
>> Add FPGA capabilities as a way to express the capabilities
>> of a given FPGA manager.
>>
>> Removes code duplication by comparing the low-level driver's
>> capabilities at the framework level rather than having each driver
>> check for supported operations in the write_init() callback.
>>
>> This allows for extending with additional capabilities, similar
>> to the the dmaengine framework's implementation.
>>
>> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
>> Cc: Alan Tull <atull@opensource.altera.com>
>> Cc: Michal Simek <michal.simek@xilinx.com>
>> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> ---
>>
>> Changes from RFC:
>> * in the RFC the caps weren't actually stored into the struct fpga_mgr
>>
>> Note:
>>
>> If people disagree on the typedef being a 'false positive' I can fix
>> that in a future rev of the patchset.
>>
>> Thanks,
>>
>> Moritz
>>
>> ---
>> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
>> drivers/fpga/socfpga.c | 10 +++++-----
>> drivers/fpga/zynq-fpga.c | 7 ++++++-
>> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
>> 4 files changed, 71 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
>> index 953dc91..ed57c17 100644
>> --- a/drivers/fpga/fpga-mgr.c
>> +++ b/drivers/fpga/fpga-mgr.c
>> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
>> struct device *dev = &mgr->dev;
>> int ret;
>>
>> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
>> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
>> + dev_err(dev, "Partial reconfiguration not supported\n");
>> + return -ENOTSUPP;
>> + }
>> +
>> + if (flags & FPGA_MGR_FULL_RECONFIG &&
>> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
>> + dev_err(dev, "Full reconfiguration not supported\n");
>> + return -ENOTSUPP;
>> + }
>> +
>
> Could you move the checks to their own function like
> 'fpga_mgr_check_caps()' or something? I really like it if we can keep
> the functions short, like a screen or so where it's practicle to do
> so and I could see the number of caps growing here.
Absolutely. Great suggestion.
> The only counter argument I could think of is if a cap affects the sequence
> in this function. Hmmm...
Oh you mean the cap being there affecting the sequence in *this* function?
I'd suggest we address that when we run into a cap that requires this.
Cheers,
Moritz
^ permalink raw reply
* Re: [PATCH v4] staging: lustre: mdc: manage number of modify RPCs in flight
From: James Simmons @ 2016-11-14 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Andreas Dilger, Linux Kernel Mailing List, Gregoire Pichon,
Oleg Drokin, Lustre Development List
In-Reply-To: <20161114172047.GA4989@kroah.com>
> On Mon, Nov 14, 2016 at 04:59:48PM +0000, James Simmons wrote:
> >
> > > On Thu, Nov 10, 2016 at 10:51:13AM -0500, James Simmons wrote:
> > > > From: Gregoire Pichon <gregoire.pichon@bull.net>
> > > >
> > > > This patch is the main client part of a new feature that supports
> > > > multiple modify metadata RPCs in parallel. Its goal is to improve
> > > > metadata operations performance of a single client, while maintening
> > > > the consistency of MDT reply reconstruction and MDT recovery
> > > > mechanisms.
> > > >
> > > > It allows to manage the number of modify RPCs in flight within
> > > > the client obd structure and to assign a virtual index (the tag) to
> > > > each modify RPC to help server side cleaning of reply data.
> > > >
> > > > The mdc component uses this feature to send multiple modify RPCs
> > > > in parallel.
> > >
> > > Is this a new feature? Why should we take this now and not just wait
> > > until the code is out of staging?
> >
> > Yes on the server side. So the problem on our meta data servers couldn't
> > handle writing mulitiple bits of data to the back end disk at ths same
> > time.
> >
> > One client side the issue was the metadata operations were being
> > serialized by a mutex in the MDC layer. That is what this patch fixed.
> > So for the client it would be a performance improvement patch.
>
> So, it's a "performance" patch, which isn't functionality, so why should
> we merge this to staging now? Why aren't people working on the known
> coding issues to get this out of staging instead of working on
> performance stuff?
Because the primary goal which the people at my company, not Intel by
the way, wanted was to get this to what is running in production
environments so people would actually use the staging client. When it was
old and broken no one would touch it with a 10 foot pole. The currently
supported verison in production is lustre 2.8.0 so we are only about 30
patches away from reaching the goal. I'm going to respond to your other
email in length about leaving staging. It would be really nice for the
user base if we can reach that goal.
^ permalink raw reply
* Re: [PATCH tip/core/rcu 0/7] Miscellaneous fixes for 4.10
From: Josh Triplett @ 2016-11-14 17:26 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, tglx, peterz, rostedt, dhowells, edumazet,
dvhart, fweisbec, oleg, bobby.prani
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 08:56:48AM -0800, Paul E. McKenney wrote:
> Hello!
>
> This series contains miscellaneous fixes to RCU:
>
> 1. Tighten up __call_rcu's alignment check for the rcu_head structure
> now that no arch does two-byte alignment of pointers.
>
> 2. Remove obsolete comment about when rcu_check_callbacks() was invoked.
>
> 3. Remove obsolete comment about which function opportunistically
> notes grace periods beginnings and endings.
>
> 4. Update the RCU_TRACE Kconfig option's help text to note that
> it enables event tracing in addition to debugfs, courtesy of
> Nikolay Borisov.
>
> 5. Add event tracing for long read-side delays in rcutorture
> in order to better debug too-short grace periods.
>
> 6. Make expedited grace periods recheck dyntick-idle state to avoid
> sending needless IPIs.
>
> 7. Don't kick CPUs unless there is grace-period activity currently
> in progress.
I replied to patches 5 and 6 with comments. For 1-4 and 7:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
^ permalink raw reply
* [lustre-devel] [PATCH v4] staging: lustre: mdc: manage number of modify RPCs in flight
From: James Simmons @ 2016-11-14 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Andreas Dilger, Linux Kernel Mailing List, Gregoire Pichon,
Oleg Drokin, Lustre Development List
In-Reply-To: <20161114172047.GA4989@kroah.com>
> On Mon, Nov 14, 2016 at 04:59:48PM +0000, James Simmons wrote:
> >
> > > On Thu, Nov 10, 2016 at 10:51:13AM -0500, James Simmons wrote:
> > > > From: Gregoire Pichon <gregoire.pichon@bull.net>
> > > >
> > > > This patch is the main client part of a new feature that supports
> > > > multiple modify metadata RPCs in parallel. Its goal is to improve
> > > > metadata operations performance of a single client, while maintening
> > > > the consistency of MDT reply reconstruction and MDT recovery
> > > > mechanisms.
> > > >
> > > > It allows to manage the number of modify RPCs in flight within
> > > > the client obd structure and to assign a virtual index (the tag) to
> > > > each modify RPC to help server side cleaning of reply data.
> > > >
> > > > The mdc component uses this feature to send multiple modify RPCs
> > > > in parallel.
> > >
> > > Is this a new feature? Why should we take this now and not just wait
> > > until the code is out of staging?
> >
> > Yes on the server side. So the problem on our meta data servers couldn't
> > handle writing mulitiple bits of data to the back end disk at ths same
> > time.
> >
> > One client side the issue was the metadata operations were being
> > serialized by a mutex in the MDC layer. That is what this patch fixed.
> > So for the client it would be a performance improvement patch.
>
> So, it's a "performance" patch, which isn't functionality, so why should
> we merge this to staging now? Why aren't people working on the known
> coding issues to get this out of staging instead of working on
> performance stuff?
Because the primary goal which the people at my company, not Intel by
the way, wanted was to get this to what is running in production
environments so people would actually use the staging client. When it was
old and broken no one would touch it with a 10 foot pole. The currently
supported verison in production is lustre 2.8.0 so we are only about 30
patches away from reaching the goal. I'm going to respond to your other
email in length about leaving staging. It would be really nice for the
user base if we can reach that goal.
^ permalink raw reply
* [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: Moritz Fischer @ 2016-11-14 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1611140801480.2786@atull-VirtualBox>
Hi Alan,
On Mon, Nov 14, 2016 at 6:06 AM, atull <atull@opensource.altera.com> wrote:
> On Mon, 7 Nov 2016, Moritz Fischer wrote:
>
>> Add FPGA capabilities as a way to express the capabilities
>> of a given FPGA manager.
>>
>> Removes code duplication by comparing the low-level driver's
>> capabilities at the framework level rather than having each driver
>> check for supported operations in the write_init() callback.
>>
>> This allows for extending with additional capabilities, similar
>> to the the dmaengine framework's implementation.
>>
>> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
>> Cc: Alan Tull <atull@opensource.altera.com>
>> Cc: Michal Simek <michal.simek@xilinx.com>
>> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> ---
>>
>> Changes from RFC:
>> * in the RFC the caps weren't actually stored into the struct fpga_mgr
>>
>> Note:
>>
>> If people disagree on the typedef being a 'false positive' I can fix
>> that in a future rev of the patchset.
>>
>> Thanks,
>>
>> Moritz
>>
>> ---
>> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
>> drivers/fpga/socfpga.c | 10 +++++-----
>> drivers/fpga/zynq-fpga.c | 7 ++++++-
>> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
>> 4 files changed, 71 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
>> index 953dc91..ed57c17 100644
>> --- a/drivers/fpga/fpga-mgr.c
>> +++ b/drivers/fpga/fpga-mgr.c
>> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
>> struct device *dev = &mgr->dev;
>> int ret;
>>
>> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
>> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
>> + dev_err(dev, "Partial reconfiguration not supported\n");
>> + return -ENOTSUPP;
>> + }
>> +
>> + if (flags & FPGA_MGR_FULL_RECONFIG &&
>> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
>> + dev_err(dev, "Full reconfiguration not supported\n");
>> + return -ENOTSUPP;
>> + }
>> +
>
> Could you move the checks to their own function like
> 'fpga_mgr_check_caps()' or something? I really like it if we can keep
> the functions short, like a screen or so where it's practicle to do
> so and I could see the number of caps growing here.
Absolutely. Great suggestion.
> The only counter argument I could think of is if a cap affects the sequence
> in this function. Hmmm...
Oh you mean the cap being there affecting the sequence in *this* function?
I'd suggest we address that when we run into a cap that requires this.
Cheers,
Moritz
^ permalink raw reply
* [Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Alexey Brodkin @ 2016-11-14 17:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114171516.GB3399@free.fr>
Hi Yann,
On Mon, 2016-11-14 at 18:15 +0100, Yann E. MORIN wrote:
> Alexey, All,
>
> On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly:
> [--SNIP--]
> >
> > The point is we were sitting on the patch for quite some time and when we saw
> > RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
>
> "Unexpectedly" is a bit of untrue: we've been doing releases every three
> months since February 2009, 7 years ago, with a one-month freeze before
> the release.
>
> So, anything that comes on-or-after the first day of the release month is
> not guaranteed to go in master, unless it is a fix.
>
> This is far from "unexpected". ;-)
I think you understood my sarcasm.
Frankly on my first submission of defconfigs for ARC boards I intentionally left
kernel version unspecified, i.e. the most recent kernel in BR was used
implicitly there. The reason was to stick to latest because all development
for ARC happens upstream and there's really no reason to use anything except
latest stable.
Well I may foresee very rare situations when latest stable is broken for us and so we
will urgently change version... but usually that's not the case.
Instead now we have to bump kernel version either every month so users of BR from
its master branch use latest kernel or at least right before RC1 so we have latest
in the release... IMHO that's a bit of overhead.
I'm not sure if described approach makes sense for many defconfigs in BR,
probably this is only ARC issue but I'd prefer it to be solved in some
"automated" way instead of following:
?a) Bumps in stable repo and then
?b) Bumps of default kernel version in BR
Any thoughts?
-Alexey
^ 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.