[PATCH v2 net 1/1] net: stmmac: Use rtnl_lock/unlock on netif_set_real_num_rx_queues() call
Fix an issue where dump stack is printed on suspend resume flow due to
netif_set_real_num_rx_queues() is not called with rtnl_lock held().
Fixes: 686cff3d7022 ("net: stmmac: Fix incorrect location to set
real_num_rx|tx_queues")
Reported-by: Christophe ROULLIER
Tested-by: Christophe ROULLIER
Cc: Alexandre TORGUE
Reviewed-by: Ong Boon Leong
Signed-off-by: Wong Vee Khee
---
v2 changelog:
- Move rtnl_lock() before priv->lock and release it after to avoid a
possible ABBA deadlock scenario.
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ba855465a2db..c8770e9668a1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5272,6 +5272,7 @@ int stmmac_resume(struct device *dev)
return ret;
}
+ rtnl_lock();
mutex_lock(>lock);
stmmac_reset_queues_param(priv);
@@ -5287,6 +5288,7 @@ int stmmac_resume(struct device *dev)
stmmac_enable_all_queues(priv);
mutex_unlock(>lock);
+ rtnl_unlock();
if (!device_may_wakeup(priv->device) || !priv->plat->pmt) {
rtnl_lock();
--
2.17.0
[PATCH v1 net-next] net: dsa: qca: ar9331: add ethtool stats support
Add stats support for the ar9331 switch.
Signed-off-by: Oleksij Rempel
---
drivers/net/dsa/qca/ar9331.c | 113 +++
1 file changed, 113 insertions(+)
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index e24a99031b80..f6947fb0182f 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -101,6 +101,9 @@
AR9331_SW_PORT_STATUS_RX_FLOW_EN | AR9331_SW_PORT_STATUS_TX_FLOW_EN | \
AR9331_SW_PORT_STATUS_SPEED_M)
+/* MIB registers */
+#define AR9331_PORT_MIB_COUNTER(_i)(0x2 + (_i) * 0x100)
+
/* Phy bypass mode
*
* Bit: | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 |11 |12 |13 |14 |15 |
@@ -165,6 +168,61 @@ struct ar9331_sw_priv {
struct reset_control *sw_reset;
};
+struct ar9331_mib_desc {
+ unsigned int size;
+ unsigned int offset;
+ const char *name;
+};
+
+#define MIB_DESC(_s, _o, _n) \
+ { \
+ .size = (_s), \
+ .offset = (_o), \
+ .name = (_n), \
+ }
+
+static const struct ar9331_mib_desc ar9331_mib[] = {
+ MIB_DESC(1, 0x00, "RxBroad"),
+ MIB_DESC(1, 0x04, "RxPause"),
+ MIB_DESC(1, 0x08, "RxMulti"),
+ MIB_DESC(1, 0x0c, "RxFcsErr"),
+ MIB_DESC(1, 0x10, "RxAlignErr"),
+ MIB_DESC(1, 0x14, "RxRunt"),
+ MIB_DESC(1, 0x18, "RxFragment"),
+ MIB_DESC(1, 0x1c, "Rx64Byte"),
+ MIB_DESC(1, 0x20, "Rx128Byte"),
+ MIB_DESC(1, 0x24, "Rx256Byte"),
+ MIB_DESC(1, 0x28, "Rx512Byte"),
+ MIB_DESC(1, 0x2c, "Rx1024Byte"),
+ MIB_DESC(1, 0x30, "Rx1518Byte"),
+ MIB_DESC(1, 0x34, "RxMaxByte"),
+ MIB_DESC(1, 0x38, "RxTooLong"),
+ MIB_DESC(2, 0x3c, "RxGoodByte"),
+ MIB_DESC(2, 0x44, "RxBadByte"),
+ MIB_DESC(1, 0x4c, "RxOverFlow"),
+ MIB_DESC(1, 0x50, "Filtered"),
+ MIB_DESC(1, 0x54, "TxBroad"),
+ MIB_DESC(1, 0x58, "TxPause"),
+ MIB_DESC(1, 0x5c, "TxMulti"),
+ MIB_DESC(1, 0x60, "TxUnderRun"),
+ MIB_DESC(1, 0x64, "Tx64Byte"),
+ MIB_DESC(1, 0x68, "Tx128Byte"),
+ MIB_DESC(1, 0x6c, "Tx256Byte"),
+ MIB_DESC(1, 0x70, "Tx512Byte"),
+ MIB_DESC(1, 0x74, "Tx1024Byte"),
+ MIB_DESC(1, 0x78, "Tx1518Byte"),
+ MIB_DESC(1, 0x7c, "TxMaxByte"),
+ MIB_DESC(1, 0x80, "TxOverSize"),
+ MIB_DESC(2, 0x84, "TxByte"),
+ MIB_DESC(1, 0x8c, "TxCollision"),
+ MIB_DESC(1, 0x90, "TxAbortCol"),
+ MIB_DESC(1, 0x94, "TxMultiCol"),
+ MIB_DESC(1, 0x98, "TxSingleCol"),
+ MIB_DESC(1, 0x9c, "TxExcDefer"),
+ MIB_DESC(1, 0xa0, "TxDefer"),
+ MIB_DESC(1, 0xa4, "TxLateCol"),
+};
+
/* Warning: switch reset will reset last AR9331_SW_MDIO_PHY_MODE_PAGE request
* If some kind of optimization is used, the request should be repeated.
*/
@@ -475,6 +533,58 @@ static void ar9331_sw_phylink_mac_link_up(struct
dsa_switch *ds, int port,
dev_err_ratelimited(priv->dev, "%s: %i\n", __func__, ret);
}
+static void ar9331_get_strings(struct dsa_switch *ds, int port, u32 stringset,
+ uint8_t *data)
+{
+ int i;
+
+ if (stringset != ETH_SS_STATS)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(ar9331_mib); i++)
+ strncpy(data + i * ETH_GSTRING_LEN, ar9331_mib[i].name,
+ ETH_GSTRING_LEN);
+}
+
+static void ar9331_get_ethtool_stats(struct dsa_switch *ds, int port,
+uint64_t *data)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ const struct ar9331_mib_desc *mib;
+ u32 reg, i, stat;
+ u64 hi;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(ar9331_mib); i++) {
+ mib = _mib[i];
+ reg = AR9331_PORT_MIB_COUNTER(port) + mib->offset;
+
+ ret = regmap_read(regmap, reg, );
+ if (ret)
+ dev_err_ratelimited(priv->dev, "%s: %i\n", __func__,
+ ret);
+ data[i] = stat;
+ if (mib->size == 2) {
+ ret = regmap_read(regmap, reg + 4, );
+ if (ret)
+ dev_err_ratelimited(priv->dev, "%s: %i\n",
+ __func__, ret);
+
+ hi = stat;
+ data[i] |= hi << 32;
+ }
+ }
+}
+
+static int ar9331_get_sset_count(struct dsa_switch *ds, int port, int sset)
+{
+ if (sset != ETH_SS_STATS)
+ return 0;
+
+ return ARRAY_SIZE(ar9331_mib);
+}
+
static const struct dsa_switch_ops ar9331_sw_ops = {
.get_tag_protocol = ar9331_sw_get_tag_protocol,
.setup = ar9331_sw_setup,
@@
Re: [PATCH] iio: core: centralize ioctl() calls to the main chardev
On Sat, Nov 14, 2020 at 5:32 PM Jonathan Cameron
wrote:
>
> On Sat, 14 Nov 2020 15:30:23 +
> Jonathan Cameron wrote:
>
> > On Mon, 2 Nov 2020 08:59:57 +0200
> > Alexandru Ardelean wrote:
> >
> > > On Fri, Sep 25, 2020 at 3:38 PM Jonathan Cameron wrote:
> > > >
> > > > On Thu, 24 Sep 2020 11:41:55 +0300
> > > > Alexandru Ardelean wrote:
> > > >
> > > > > The aim of this is to improve a bit the organization of ioctl() calls
> > > > > in
> > > > > IIO core. Currently the chardev is split across IIO core
> > > > > sub-modules/files.
> > > > > The main chardev has to be able to handle ioctl() calls, and if we
> > > > > need to
> > > > > add buffer ioctl() calls, this would complicate things.
> > > > >
> > > > > The 'industrialio-core.c' file will provide a 'iio_device_ioctl()'
> > > > > which
> > > > > will iterate over a list of ioctls registered with the IIO device.
> > > > > These
> > > > > can be event ioctl() or buffer ioctl() calls, or something else.
> > > > >
> > > > > Each ioctl() handler will have to return a IIO_IOCTL_UNHANDLED code
> > > > > (which
> > > > > is positive 1), if the ioctl() did not handle the call in any. This
> > > > > eliminates any potential ambiguities about negative error codes, which
> > > > > should fail the call altogether.
> > > > >
> > > > > If any ioctl() returns 0, it was considered that it was serviced
> > > > > successfully and the loop will exit.
> > > > >
> > > > > This change also moves the handling of the IIO_GET_EVENT_FD_IOCTL
> > > > > command
> > > > > inside 'industrialio-event.c', where this is better suited.
> > > > >
> > > > > This patch is a combination of 2 other patches from an older series:
> > > > > Patch 1: iio: core: add simple centralized mechanism for ioctl()
> > > > > handlers
> > > > > Link:
> > > > > https://lore.kernel.org/linux-iio/20200427131100.50845-6-alexandru.ardel...@analog.com/
> > > > > Patch 2: iio: core: use new common ioctl() mechanism
> > > > > Link:
> > > > > https://lore.kernel.org/linux-iio/20200427131100.50845-7-alexandru.ardel...@analog.com/
> > > > >
> > > > > Signed-off-by: Alexandru Ardelean
> > > > > ---
> > > > >
> > > > > Note: since this is a change to the IIO core, we don't need to put
> > > > > this in
> > > > > right now; especially if there is a tight schedule, or we are too
> > > > > close to
> > > > > a merge window.
> > > >
> > > > Looks good to me. As you suggest, lets let this one sit on the list
> > > > for a
> > > > while though!
> > >
> > > ping on this
> >
> > Thanks. Was still on my list, but I've been lazy and not been clearing that
> > out for a while - too many scary things there :)
> >
> > Anyhow, applied to the togreg branch of iio.git and pushed out as testing
> > for
> > all the normal reasons.
> Hmm. I should really wait for local build tests to finish. Tweaked to
> remove the bonus @ where you have @@ in the docs.
>
> Note I'm build testing with W=1 these days that finds this sort of docs
> issue.
I should also start using W=1 that in my build-checks.
I think I am getting more often hit by these lately.
>
> thanks,
>
> Jonathan
>
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > thanks
> > > Alex
> > >
> > > >
> > > > Jonathan
> > > >
> > > > >
> > > > > drivers/iio/iio_core.h | 15 -
> > > > > drivers/iio/industrialio-core.c | 56
> > > > >
> > > > > drivers/iio/industrialio-event.c | 28 +++-
> > > > > include/linux/iio/iio-opaque.h | 2 ++
> > > > > 4 files changed, 85 insertions(+), 16 deletions(-)
> > > > >
> > > > > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > > > > index fd9a5f1d5e51..fced02cadcc3 100644
> > > > > --- a/drivers/iio/iio_core.h
> > > > > +++ b/drivers/iio/iio_core.h
> > > > > @@ -17,6 +17,20 @@ struct iio_dev;
> > > > >
> > > > > extern struct device_type iio_device_type;
> > > > >
> > > > > +#define IIO_IOCTL_UNHANDLED 1
> > > > > +struct iio_ioctl_handler {
> > > > > + struct list_head entry;
> > > > > + long (*ioctl)(struct iio_dev *indio_dev, struct file *filp,
> > > > > + unsigned int cmd, unsigned long arg);
> > > > > +};
> > > > > +
> > > > > +long iio_device_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > > > > + unsigned int cmd, unsigned long arg);
> > > > > +
> > > > > +void iio_device_ioctl_handler_register(struct iio_dev *indio_dev,
> > > > > +struct iio_ioctl_handler *h);
> > > > > +void iio_device_ioctl_handler_unregister(struct iio_ioctl_handler
> > > > > *h);
> > > > > +
> > > > > int __iio_add_chan_devattr(const char *postfix,
> > > > > struct iio_chan_spec const *chan,
> > > > > ssize_t (*func)(struct device *dev,
> > > > > @@ -74,7 +88,6 @@ static inline void iio_buffer_wakeup_poll(struct
> > > > > iio_dev *indio_dev) {}
> > > > > int iio_device_register_eventset(struct iio_dev *indio_dev);
> > > >
drivers/dma/sun6i-dma.c:244:45: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e28c0d7c92c89016c12a677616668957351e7542 commit: 005b73d0dd83c9cb9420a196bea8070cde30ecac m68knommu: __force type casts for raw IO access date: 4 months ago config: m68k-randconfig-s031-20201115 (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-107-gaf3512a6-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=005b73d0dd83c9cb9420a196bea8070cde30ecac git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 005b73d0dd83c9cb9420a196bea8070cde30ecac # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=m68k If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/dma/sun6i-dma.c: note: in included file (through arch/m68k/include/asm/io.h, include/linux/scatterlist.h, include/linux/dmaengine.h): arch/m68k/include/asm/io_no.h:96:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int volatile [usertype] @@ got restricted __le32 [usertype] @@ arch/m68k/include/asm/io_no.h:96:17: sparse: expected unsigned int volatile [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: got restricted __le32 [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int volatile [usertype] @@ got restricted __le32 [usertype] @@ arch/m68k/include/asm/io_no.h:96:17: sparse: expected unsigned int volatile [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: got restricted __le32 [usertype] arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:96:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int volatile [usertype] @@ got restricted __le32 [usertype] @@ arch/m68k/include/asm/io_no.h:96:17: sparse: expected unsigned int volatile [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: got restricted __le32 [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int volatile [usertype] @@ got restricted __le32 [usertype] @@ arch/m68k/include/asm/io_no.h:96:17: sparse: expected unsigned int volatile [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: got restricted __le32 [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int volatile [usertype] @@ got restricted __le32 [usertype] @@ arch/m68k/include/asm/io_no.h:96:17: sparse: expected unsigned int volatile [usertype] arch/m68k/include/asm/io_no.h:96:17: sparse: got restricted __le32 [usertype] arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32
[PATCH v2 1/1] page_frag: Recover from memory pressure
The ethernet driver may allocate skb (and skb->data) via napi_alloc_skb().
This ends up to page_frag_alloc() to allocate skb->data from
page_frag_cache->va.
During the memory pressure, page_frag_cache->va may be allocated as
pfmemalloc page. As a result, the skb->pfmemalloc is always true as
skb->data is from page_frag_cache->va. The skb will be dropped if the
sock (receiver) does not have SOCK_MEMALLOC. This is expected behaviour
under memory pressure.
However, once kernel is not under memory pressure any longer (suppose large
amount of memory pages are just reclaimed), the page_frag_alloc() may still
re-use the prior pfmemalloc page_frag_cache->va to allocate skb->data. As a
result, the skb->pfmemalloc is always true unless page_frag_cache->va is
re-allocated, even if the kernel is not under memory pressure any longer.
Here is how kernel runs into issue.
1. The kernel is under memory pressure and allocation of
PAGE_FRAG_CACHE_MAX_ORDER in __page_frag_cache_refill() will fail. Instead,
the pfmemalloc page is allocated for page_frag_cache->va.
2: All skb->data from page_frag_cache->va (pfmemalloc) will have
skb->pfmemalloc=true. The skb will always be dropped by sock without
SOCK_MEMALLOC. This is an expected behaviour.
3. Suppose a large amount of pages are reclaimed and kernel is not under
memory pressure any longer. We expect skb->pfmemalloc drop will not happen.
4. Unfortunately, page_frag_alloc() does not proactively re-allocate
page_frag_alloc->va and will always re-use the prior pfmemalloc page. The
skb->pfmemalloc is always true even kernel is not under memory pressure any
longer.
Fix this by freeing and re-allocating the page instead of recycling it.
References:
https://lore.kernel.org/lkml/20201103193239.1807-1-dongli.zh...@oracle.com/
References:
https://lore.kernel.org/linux-mm/20201105042140.5253-1-wi...@infradead.org/
Suggested-by: Matthew Wilcox (Oracle)
Cc: Aruna Ramakrishna
Cc: Bert Barbe
Cc: Rama Nichanamatlu
Cc: Venkat Venkatsubra
Cc: Manjunath Patil
Cc: Joe Jin
Cc: SRINIVAS
Cc: sta...@vger.kernel.org
Fixes: 79930f5892e ("net: do not deplete pfmemalloc reserve")
Signed-off-by: Dongli Zhang
Acked-by: Vlastimil Babka
---
Changed since v1:
- change author from Matthew to Dongli
- Add references to all prior discussions
- Add more details to commit message
mm/page_alloc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 23f5066bd4a5..91129ce75ed4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5103,6 +5103,11 @@ void *page_frag_alloc(struct page_frag_cache *nc,
if (!page_ref_sub_and_test(page, nc->pagecnt_bias))
goto refill;
+ if (nc->pfmemalloc) {
+ free_the_page(page, compound_order(page));
+ goto refill;
+ }
+
#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
/* if size can vary use size else just use PAGE_SIZE */
size = nc->size;
--
2.17.1
Re: [PATCH v3 01/10] Add auxiliary bus support
On Sat, Nov 14, 2020 at 12:21:39AM +0100, Greg KH wrote: > On Fri, Nov 13, 2020 at 04:07:57PM +, Ertman, David M wrote: > > > -Original Message- > > > From: Greg KH > > > Sent: Friday, November 13, 2020 7:50 AM > > > To: Ertman, David M > > > Cc: alsa-de...@alsa-project.org; ti...@suse.de; broo...@kernel.org; linux- > > > r...@vger.kernel.org; j...@nvidia.com; dledf...@redhat.com; > > > net...@vger.kernel.org; da...@davemloft.net; k...@kernel.org; > > > ranjani.sridha...@linux.intel.com; pierre-louis.boss...@linux.intel.com; > > > fred...@linux.intel.com; pa...@mellanox.com; Saleem, Shiraz > > > ; Williams, Dan J ; > > > Patil, Kiran ; linux-kernel@vger.kernel.org; > > > leo...@nvidia.com > > > Subject: Re: [PATCH v3 01/10] Add auxiliary bus support > > > > > > On Thu, Oct 22, 2020 at 05:33:29PM -0700, Dave Ertman wrote: > > > > Add support for the Auxiliary Bus, auxiliary_device and > > > > auxiliary_driver. > > > > It enables drivers to create an auxiliary_device and bind an > > > > auxiliary_driver to it. > > > > > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > > > Each auxiliary_device has a unique string based id; driver binds to > > > > an auxiliary_device based on this id through the bus. > > > > > > > > Co-developed-by: Kiran Patil > > > > Signed-off-by: Kiran Patil > > > > Co-developed-by: Ranjani Sridharan > > > > Signed-off-by: Ranjani Sridharan > > > > Co-developed-by: Fred Oh > > > > Signed-off-by: Fred Oh > > > > Co-developed-by: Leon Romanovsky > > > > Signed-off-by: Leon Romanovsky > > > > Reviewed-by: Pierre-Louis Bossart > > > > Reviewed-by: Shiraz Saleem > > > > Reviewed-by: Parav Pandit > > > > Reviewed-by: Dan Williams > > > > Signed-off-by: Dave Ertman > > > > --- > > > > > > Is this really the "latest" version of this patch submission? > > > > > > I see a number of comments on it already, have you sent out a newer one, > > > or is this the same one that the mlx5 driver conversion was done on top > > > of? > > > > > > thanks, > > > > > > greg k-h > > > > V3 is the latest sent so far. There was a suggestion that v3 might be > > merged and > > the documentation changes could be in a follow up patch. I have those > > changes done > > and ready though, so no reason not to merge them in and do a resend. > > > > Please expect v4 in just a little while. > > Thank you, follow-up patches aren't usually a good idea :) The changes were in documentation area that will be changed anyway after dust will settle and we all see real users and more or less stable in-kernel API. Thanks
Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH
Hi, Roman, On Sun, Nov 15, 2020 at 6:02 AM Roman Kiryanov wrote: > > Hi Hancai, > > do you know if CONFIG_GOLDFISH_AUDIO is required for MIPS? I sent a > patch to retire it. Not required for MIPS. Huacai > > Regards, > Roman. > > On Sat, Nov 14, 2020 at 12:06 AM 陈华才 wrote: > > > > Hi, All, > > > > Goldfish RTC works well on MIPS, and QEMU RISC-V emulator use Goldfish as > > well, so I think we should keep it in kernel. > > > > Huacai > > > > > > -- Original -- > > From: "Greg KH"; > > Date: Sat, Nov 14, 2020 07:43 AM > > To: "Roman Kiryanov"; > > Cc: "chenhc"; "Paul > > Walmsley"; "LKML"; > > "Lingfeng Yang"; "Rob Herring"; > > Subject: Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH > > > > > > > > On Fri, Nov 13, 2020 at 03:36:49PM -0800, Roman Kiryanov wrote: > > > +Greg KH > > > > > > On Fri, Nov 13, 2020 at 2:02 PM Roman Kiryanov wrote: > > > > > > > > Hi Hancai, > > > > > > > > I see you added > > > > /arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts which > > > > refers to goldfish-rtc in 39c1485c8baa47aa20caefc1ec0a3410fbad6c81. > > > > We (Android Studio Emulator aka "goldfish") do not support MIPS anymore. > > > > Do you know if goldfish-rtc still works and is assumed to be available? > > > > I've dropped this patch from my trees now, please feel free to resend > > when you have an updated version. > > > > thanks, > > > > greg k-h
Re: WARNING: can't access registers at asm_common_interrupt
On 14.11.20 19:10, Andy Lutomirski wrote: On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote: On 13.11.20 18:34, Andy Lutomirski wrote: On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper wrote: So I think there is at most one of these that wants anything more complicated than a plain ALTERNATIVE. Any volunteers to make it so? Juergen, if you do all of them except USERGS_SYSRET64, I hereby volunteer to do that one. Why is a plain alternative (either swapgs; sysretq or a jmp xen_sysret64 depending on X86_FEATURE_XENPV) no option? Its not as if this code would run before alternative patching. ALTERNATIVE would "work" in the sense that it would function and be just about as nonsensical as the current code. Fundamentally, Xen PV's sysret feature is not a drop-in replacement for SYSRET64, and pretending that it is seems unlikely to work well. I suspect that the current code is some combination of exceedingly slow, non-functional, and incorrect in subtle ways. We should just have a separate Xen PV exit path the same way we have a separate entry path in recent kernels. *This* is what I'm volunteering to do. I don't think there is much work needed. Xen PV does basically a return to user mode via IRET. I think it might work just to use swapgs_restore_regs_and_return_to_usermode() unconditionally for Xen PV. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[PATCH] btrfs: remove the useless value assignment in block_rsv_release_bytes
From: Kaixu Xia
The variable qgroup_to_release is overwritten by the following if/else
statement before it is used, so this assignment is useless. Remove it.
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
---
fs/btrfs/block-rsv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c
index bc920afe23bf..8638327069b7 100644
--- a/fs/btrfs/block-rsv.c
+++ b/fs/btrfs/block-rsv.c
@@ -109,10 +109,8 @@ static u64 block_rsv_release_bytes(struct btrfs_fs_info
*fs_info,
u64 ret;
spin_lock(_rsv->lock);
- if (num_bytes == (u64)-1) {
+ if (num_bytes == (u64)-1)
num_bytes = block_rsv->size;
- qgroup_to_release = block_rsv->qgroup_rsv_size;
- }
block_rsv->size -= num_bytes;
if (block_rsv->reserved >= block_rsv->size) {
num_bytes = block_rsv->reserved - block_rsv->size;
--
2.20.0
Re: PCI: Race condition in pci_create_sysfs_dev_files
Hello Pali! Sincere apologies for taking a long time to get back to you. On 20-11-04 17:29:31, Pali Rohár wrote: [...] > > Krzysztof, as Bjorn wrote, do you want to take this issue? > [...] Yes. I already talked to Bjorn about this briefly, and thus I am more than happy to take care about this. Most definitely. Krzysztof
Re: [PATCH] PCI: Add sysfs attribute for PCI device power state
Hi Maximilian,
On 20-11-02 15:15:20, Maximilian Luz wrote:
> While most PCI power-states can be queried from user-space via lspci,
> this has some limits. Specifically, lspci fails to provide an accurate
> value when the device is in D3cold as it has to resume the device before
> it can access its power state via the configuration space, leading to it
> reporting D0 or another on-state. Thus lspci can, for example, not be
> used to diagnose power-consumption issues for devices that can enter
> D3cold or to ensure that devices properly enter D3cold at all.
>
> To alleviate this issue, introduce a new sysfs device attribute for the
> PCI power state, showing the current power state as seen by the kernel.
Very nice! Thank you for adding this.
[...]
> +/* PCI power state */
> +static ssize_t power_state_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct pci_dev *pci_dev = to_pci_dev(dev);
> + pci_power_t state = READ_ONCE(pci_dev->current_state);
> +
> + return sprintf(buf, "%s\n", pci_power_name(state));
> +}
> +static DEVICE_ATTR_RO(power_state);
[...]
Curious, why did you decide to use the READ_ONCE() macro here? Some
other drivers exposing data through sysfs use, but certainly not all.
Krzysztof
[PATCH] bpf: don't fail kmalloc while releasing raw_tp
bpf_link_free is always called in process context, including from a
workqueue and from __fput. Neither of these have the ability to
propagate an -ENOMEM to the caller.
Reported-by: syzbot+83aa762ef23b6f0d1...@syzkaller.appspotmail.com
Reported-by: syzbot+d29e58bb557324e55...@syzkaller.appspotmail.com
Signed-off-by: Matt Mullins
---
I previously referenced a "pretty ugly" patch. This is not that one,
because I don't think there's any way I can make the caller of
->release() actually handle errors like ENOMEM.
It also looks like most of the other ways tracepoint_probe_unregister is
called also don't check the error code (e.g. just a quick grep found
blk_unregister_tracepoints). Should this just be upgraded to GFP_NOFAIL
across the board instead of passing around a gfp_t?
include/linux/trace_events.h | 6 --
include/linux/tracepoint.h | 7 +--
kernel/bpf/syscall.c | 2 +-
kernel/trace/bpf_trace.c | 6 --
kernel/trace/trace_events.c | 6 --
kernel/tracepoint.c | 20 ++--
6 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 5c6943354049..166ad7646a98 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -625,7 +625,8 @@ int perf_event_attach_bpf_prog(struct perf_event *event,
struct bpf_prog *prog);
void perf_event_detach_bpf_prog(struct perf_event *event);
int perf_event_query_prog_array(struct perf_event *event, void __user *info);
int bpf_probe_register(struct bpf_raw_event_map *btp, struct bpf_prog *prog);
-int bpf_probe_unregister(struct bpf_raw_event_map *btp, struct bpf_prog *prog);
+int bpf_probe_unregister(struct bpf_raw_event_map *btp, struct bpf_prog *prog,
+gfp_t flags);
struct bpf_raw_event_map *bpf_get_raw_tracepoint(const char *name);
void bpf_put_raw_tracepoint(struct bpf_raw_event_map *btp);
int bpf_get_perf_event_info(const struct perf_event *event, u32 *prog_id,
@@ -654,7 +655,8 @@ static inline int bpf_probe_register(struct
bpf_raw_event_map *btp, struct bpf_p
{
return -EOPNOTSUPP;
}
-static inline int bpf_probe_unregister(struct bpf_raw_event_map *btp, struct
bpf_prog *p)
+static inline int bpf_probe_unregister(struct bpf_raw_event_map *btp,
+ struct bpf_prog *p, gfp_t flags)
{
return -EOPNOTSUPP;
}
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 598fec9f9dbf..7b02f92f3b8f 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -12,6 +12,7 @@
* Heavily inspired from the Linux Kernel Markers.
*/
+#include
#include
#include
#include
@@ -40,7 +41,8 @@ extern int
tracepoint_probe_register_prio(struct tracepoint *tp, void *probe, void *data,
int prio);
extern int
-tracepoint_probe_unregister(struct tracepoint *tp, void *probe, void *data);
+tracepoint_probe_unregister(struct tracepoint *tp, void *probe, void *data,
+ gfp_t flags);
extern void
for_each_kernel_tracepoint(void (*fct)(struct tracepoint *tp, void *priv),
void *priv);
@@ -260,7 +262,8 @@ static inline struct tracepoint
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
unregister_trace_##name(void (*probe)(data_proto), void *data) \
{ \
return tracepoint_probe_unregister(&__tracepoint_##name,\
- (void *)probe, data); \
+ (void *)probe, data,\
+ GFP_KERNEL);\
} \
static inline void \
check_trace_callback_type_##name(void (*cb)(data_proto))\
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index b999e7ff2583..f6876681c4ab 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2601,7 +2601,7 @@ static void bpf_raw_tp_link_release(struct bpf_link *link)
struct bpf_raw_tp_link *raw_tp =
container_of(link, struct bpf_raw_tp_link, link);
- bpf_probe_unregister(raw_tp->btp, raw_tp->link.prog);
+ bpf_probe_unregister(raw_tp->btp, raw_tp->link.prog, GFP_KERNEL |
__GFP_NOFAIL);
bpf_put_raw_tracepoint(raw_tp->btp);
}
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index a8d4f253ed77..a4ea58c7506d 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1955,9 +1955,11 @@ int bpf_probe_register(struct bpf_raw_event_map *btp,
struct bpf_prog *prog)
return __bpf_probe_register(btp, prog);
}
-int bpf_probe_unregister(struct bpf_raw_event_map *btp, struct bpf_prog *prog)
+int bpf_probe_unregister(struct bpf_raw_event_map *btp, struct bpf_prog *prog,
+
aiu-encoder-spdif.c:undefined reference to `clk_set_parent'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e28c0d7c92c89016c12a677616668957351e7542 commit: 6ae9ca9ce986bffe71fd0fbf9595de8500891b52 ASoC: meson: aiu: add i2s and spdif support date: 9 months ago config: mips-randconfig-c003-20201104 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ae9ca9ce986bffe71fd0fbf9595de8500891b52 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 6ae9ca9ce986bffe71fd0fbf9595de8500891b52 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mipsel-linux-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x94c): undefined reference to `clk_set_parent' mipsel-linux-ld: drivers/gpu/drm/exynos/exynos_hdmi.o: in function `hdmi_clk_set_parents': exynos_hdmi.c:(.text+0x374): undefined reference to `clk_set_parent' mipsel-linux-ld: drivers/gpu/drm/ingenic/ingenic-drm.o: in function `ingenic_drm_probe': ingenic-drm.c:(.text+0xfa0): undefined reference to `clk_get_parent' mipsel-linux-ld: drivers/usb/phy/phy-tegra-usb.o: in function `tegra_usb_phy_init': phy-tegra-usb.c:(.text+0x1dd4): undefined reference to `clk_get_parent' mipsel-linux-ld: sound/soc/meson/aiu-encoder-spdif.o: in function `aiu_encoder_spdif_startup': >> aiu-encoder-spdif.c:(.text+0x3a0): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/meson/axg-tdm-formatter.o: in function `axg_tdm_formatter_event': (.text+0x7ec): undefined reference to `clk_set_parent' mipsel-linux-ld: (.text+0x940): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/sh/fsi.o: in function `fsi_clk_set_rate_external': fsi.c:(.text+0x26d8): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/stm/stm32_i2s.o: in function `stm32_i2s_hw_params': stm32_i2s.c:(.text+0x17f0): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/stm/stm32_i2s.o:stm32_i2s.c:(.text+0x195c): more undefined references to `clk_set_parent' follow mipsel-linux-ld: sound/soc/ti/omap-dmic.o: in function `omap_dmic_set_dai_sysclk': omap-dmic.c:(.text+0xa98): undefined reference to `clk_get_parent' mipsel-linux-ld: omap-dmic.c:(.text+0xadc): undefined reference to `clk_set_parent' mipsel-linux-ld: omap-dmic.c:(.text+0xbb8): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/ti/omap-mcbsp.o: in function `omap2_mcbsp_set_clks_src': omap-mcbsp.c:(.text+0x664): undefined reference to `clk_set_parent' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v2] sched/uclamp: Allow to reset a task uclamp constraint value
Hi Dietmar,
On Fri, Nov 13, 2020 at 12:34:54PM +0100, Dietmar Eggemann wrote:
> In case the user wants to stop controlling a uclamp constraint value
> for a task, use the magic value -1 in sched_util_{min,max} with the
> appropriate sched_flags (SCHED_FLAG_UTIL_CLAMP_{MIN,MAX}) to indicate
> the reset.
>
> The advantage over the 'additional flag' approach (i.e. introducing
> SCHED_FLAG_UTIL_CLAMP_RESET) is that no additional flag has to be
> exported via uapi. This avoids the need to document how this new flag
> has be used in conjunction with the existing uclamp related flags.
>
> The following subtle issue is fixed as well. When a uclamp constraint
> value is set on a !user_defined uclamp_se it is currently first reset
> and then set.
> Fix this by AND'ing !user_defined with !SCHED_FLAG_UTIL_CLAMP which
> stands for the 'sched class change' case.
> The related condition 'if (uc_se->user_defined)' moved from
> __setscheduler_uclamp() into uclamp_reset().
I think this is great, thanks!
Reviewed-by: Yun Hsiang
>
> Signed-off-by: Dietmar Eggemann
> ---
>
> v1 [1] -> v2:
>
> 1) Removed struct sched_attr (UAPI) change.
>
> 2) Use single branch range check in uclamp_validate().
>
> [1] https://lkml.kernel.org/r/f3b59aad-3d5d-039b-205d-024308b60...@arm.com
>
> include/uapi/linux/sched/types.h | 2 +
> kernel/sched/core.c | 70 +++-
> 2 files changed, 53 insertions(+), 19 deletions(-)
>
> diff --git a/include/uapi/linux/sched/types.h
> b/include/uapi/linux/sched/types.h
> index c852153ddb0d..f2c4589d4dbf 100644
> --- a/include/uapi/linux/sched/types.h
> +++ b/include/uapi/linux/sched/types.h
> @@ -96,6 +96,8 @@ struct sched_param {
> * on a CPU with a capacity big enough to fit the specified value.
> * A task with a max utilization value smaller than 1024 is more likely
> * scheduled on a CPU with no more capacity than the specified value.
> + *
> + * A task utilization boundary can be reset by setting the attribute to -1.
> */
> struct sched_attr {
> __u32 size;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3dc415f58bd7..a4805747b304 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1413,17 +1413,24 @@ int sysctl_sched_uclamp_handler(struct ctl_table
> *table, int write,
> static int uclamp_validate(struct task_struct *p,
> const struct sched_attr *attr)
> {
> - unsigned int lower_bound = p->uclamp_req[UCLAMP_MIN].value;
> - unsigned int upper_bound = p->uclamp_req[UCLAMP_MAX].value;
> + int util_min = p->uclamp_req[UCLAMP_MIN].value;
> + int util_max = p->uclamp_req[UCLAMP_MAX].value;
>
> - if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN)
> - lower_bound = attr->sched_util_min;
> - if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX)
> - upper_bound = attr->sched_util_max;
> + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
> + util_min = attr->sched_util_min;
>
> - if (lower_bound > upper_bound)
> - return -EINVAL;
> - if (upper_bound > SCHED_CAPACITY_SCALE)
> + if (util_min + 1 > SCHED_CAPACITY_SCALE + 1)
> + return -EINVAL;
> + }
> +
> + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) {
> + util_max = attr->sched_util_max;
> +
> + if (util_max + 1 > SCHED_CAPACITY_SCALE + 1)
> + return -EINVAL;
> + }
> +
> + if (util_min != -1 && util_max != -1 && util_min > util_max)
> return -EINVAL;
>
> /*
> @@ -1438,20 +1445,41 @@ static int uclamp_validate(struct task_struct *p,
> return 0;
> }
>
> +static bool uclamp_reset(const struct sched_attr *attr,
> + enum uclamp_id clamp_id,
> + struct uclamp_se *uc_se)
> +{
> + /* Reset on sched class change for a non user-defined clamp value. */
> + if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)) &&
> + !uc_se->user_defined)
> + return true;
> +
> + /* Reset on sched_util_{min,max} == -1. */
> + if (clamp_id == UCLAMP_MIN &&
> + attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN &&
> + attr->sched_util_min == -1) {
> + return true;
> + }
> +
> + if (clamp_id == UCLAMP_MAX &&
> + attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX &&
> + attr->sched_util_max == -1) {
> + return true;
> + }
> +
> + return false;
> +}
> +
> static void __setscheduler_uclamp(struct task_struct *p,
> const struct sched_attr *attr)
> {
> enum uclamp_id clamp_id;
>
> - /*
> - * On scheduling class change, reset to default clamps for tasks
> - * without a task-specific value.
> - */
> for_each_clamp_id(clamp_id) {
> struct uclamp_se *uc_se = >uclamp_req[clamp_id];
> + unsigned int value;
>
> - /*
[PATCH] Asoc: qcom: lpass-platform: Fix memory leak
lpass_pcm_data is not freed in error paths. Free it in
error paths to avoid memory leak.
Fixes: 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
Signed-off-by: Pavel Machek
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
sound/soc/qcom/lpass-platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 36d1512..7a3fdf8 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -122,8 +122,10 @@ static int lpass_platform_pcmops_open(struct
snd_soc_component *component,
else
dma_ch = 0;
- if (dma_ch < 0)
+ if (dma_ch < 0) {
+ kfree(data);
return dma_ch;
+ }
if (cpu_dai->driver->id == LPASS_DP_RX) {
map = drvdata->hdmiif_map;
@@ -147,6 +149,7 @@ static int lpass_platform_pcmops_open(struct
snd_soc_component *component,
ret = snd_pcm_hw_constraint_integer(runtime,
SNDRV_PCM_HW_PARAM_PERIODS);
if (ret < 0) {
+ kfree(data);
dev_err(soc_runtime->dev, "setting constraints failed: %d\n",
ret);
return -EINVAL;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH RT 1/5] net: Properly annotate the try-lock for the seqlock
On Sat, 2020-11-14 at 13:24 -0600, Tom Zanussi wrote: > On Sat, 2020-11-14 at 20:00 +0100, Mike Galbraith wrote: > > > __raw_write_seqcount_end() is an integral part of write_sequnlock(), > > but we do seem to be missing a seqcount_release() in 5.4-rt. > > > > Yep, you're right, it's just the missing seqcount_release() - I'll > resubmit with just that. Or just drop the backport, since it adds annotation, while the original was fixing existing annotation. __raw_write_seqcount_begin() called in 5.4-rt try_write_seqlock() is not annotated, while write_seqcount_begin() called by the 5.9-rt version leads to the broken annotation that the original then fixed. -Mike
Re: [RFC bpf-next 1/3] bpf: add module support to btf display helpers
On 11/14/20 8:04 AM, Alexei Starovoitov wrote:
On Fri, Nov 13, 2020 at 10:59 PM Andrii Nakryiko
wrote:
On Fri, Nov 13, 2020 at 10:11 AM Alan Maguire wrote:
bpf_snprintf_btf and bpf_seq_printf_btf use a "struct btf_ptr *"
argument that specifies type information about the type to
be displayed. Augment this information to include a module
name, allowing such display to support module types.
Signed-off-by: Alan Maguire
---
include/linux/btf.h| 8
include/uapi/linux/bpf.h | 5 -
kernel/bpf/btf.c | 18 ++
kernel/trace/bpf_trace.c | 42 --
tools/include/uapi/linux/bpf.h | 5 -
5 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 2bf6418..d55ca00 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -209,6 +209,14 @@ static inline const struct btf_var_secinfo
*btf_type_var_secinfo(
const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
const char *btf_name_by_offset(const struct btf *btf, u32 offset);
struct btf *btf_parse_vmlinux(void);
+#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
+struct btf *bpf_get_btf_module(const char *name);
+#else
+static inline struct btf *bpf_get_btf_module(const char *name)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+#endif
struct btf *bpf_prog_get_target_btf(const struct bpf_prog *prog);
#else
static inline const struct btf_type *btf_type_by_id(const struct btf *btf,
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 162999b..26978be 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -3636,7 +3636,8 @@ struct bpf_stack_build_id {
* the pointer data is carried out to avoid kernel crashes during
* operation. Smaller types can use string space on the stack;
* larger programs can use map data to store the string
- * representation.
+ * representation. Module-specific data structures can be
+ * displayed if the module name is supplied.
*
* The string can be subsequently shared with userspace via
* bpf_perf_event_output() or ring buffer interfaces.
@@ -5076,11 +5077,13 @@ struct bpf_sk_lookup {
* potentially to specify additional details about the BTF pointer
* (rather than its mode of display) - is included for future use.
* Display flags - BTF_F_* - are passed to bpf_snprintf_btf separately.
+ * A module name can be specified for module-specific data.
*/
struct btf_ptr {
void *ptr;
__u32 type_id;
__u32 flags;/* BTF ptr flags; unused at present. */
+ const char *module; /* optional module name. */
I think module name is a wrong API here, similarly how type name was
wrong API for specifying the type (and thus we use type_id here).
Using the module's BTF ID seems like a more suitable interface. That's
what I'm going to use for all kinds of existing BPF APIs that expect
BTF type to attach BPF programs.
Right now, we use only type_id and implicitly know that it's in
vmlinux BTF. With module BTFs, we now need a pair of BTF object ID +
BTF type ID to uniquely identify the type. vmlinux BTF now can be
specified in two different ways: either leaving BTF object ID as zero
(for simplicity and backwards compatibility) or specifying it's actual
BTF obj ID (which pretty much always should be 1, btw). This feels
like a natural extension, WDYT?
And similar to type_id, no one should expect users to specify these
IDs by hand, Clang built-in and libbpf should work together to figure
this out for the kernel to use.
BTW, with module names there is an extra problem for end users. Some
types could be either built-in or built as a module (e.g., XFS data
structures). Why would we require BPF users to care which is the case
on any given host?
+1.
As much as possible libbpf should try to hide the difference between
type in a module vs type in the vmlinux, since that difference most of the
time is irrelevant from bpf prog pov.
I just crafted a llvm patch where for __builtin_btf_type_id(), a 64bit
value is returned instead of a 32bit value. libbpf can use the lower
32bit as the btf_type_id and upper 32bit as the kernel module btf id.
https://reviews.llvm.org/D91489
feel free to experiment with it to see whether it helps.
Re: [PATCH net] net: x25: Correct locking for x25_kill_by_device and x25_kill_by_neigh
On Sat, Nov 14, 2020 at 2:36 AM Xie He wrote: > > This patch adds correct locking for x25_kill_by_device and > x25_kill_by_neigh, and removes the incorrect locking in x25_connect and > x25_disconnect. I see if I do this change, I need to make sure the sock lock is not held when calling x25_remove_socket, to prevent deadlock. Sorry. I'll deal with this issue and resubmit. I also see that in x25_find_listener and __x25_find_socket, when we traverse x25_list, we should probably also hold the sock lock when we read the element of the list, and continue to hold the lock when we find the sock we want.
Re: [PATCH v4] riscv: Enable per-task stack canaries
Hi Palmer,
Could you help move the patch into your next-tree with Kees' review added?
On Sat, Nov 14, 2020 at 6:57 AM Kees Cook wrote:
>
> On Sun, Oct 18, 2020 at 12:38:17PM +, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > This enables the use of per-task stack canary values if GCC has
> > support for emitting the stack canary reference relative to the
> > value of tp, which holds the task struct pointer in the riscv
> > kernel.
> >
> > After compare arm64 and x86 implementations, seems arm64's is more
> > flexible and readable. The key point is how gcc get the offset of
> > stack_canary from gs/el0_sp.
> >
> > x86: Use a fix offset from gs, not flexible.
> >
> > struct fixed_percpu_data {
> > /*
> >* GCC hardcodes the stack canary as %gs:40. Since the
> >* irq_stack is the object at %gs:0, we reserve the bottom
> >* 48 bytes of the irq stack for the canary.
> >*/
> > chargs_base[40]; // :(
> > unsigned long stack_canary;
> > };
> >
> > arm64: Use -mstack-protector-guard-offset & guard-reg
> > gcc options:
> > -mstack-protector-guard=sysreg
> > -mstack-protector-guard-reg=sp_el0
> > -mstack-protector-guard-offset=xxx
> >
> > riscv: Use -mstack-protector-guard-offset & guard-reg
> > gcc options:
> > -mstack-protector-guard=tls
> > -mstack-protector-guard-reg=tp
> > -mstack-protector-guard-offset=xxx
> >
> > GCC's implementation has been merged:
> > commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
> > Author: Cooper Qu
> > Date: Mon Jul 13 16:15:08 2020 +0800
> >
> > RISC-V: Add support for TLS stack protector canary access
> >
> > In the end, these codes are inserted by gcc before return:
> >
> > * 0xffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
> > * 0xffe00020b39a <+124>: xor a5,a5,a4
> > * 0xffe00020b39c <+126>: mv a0,s5
> > * 0xffe00020b39e <+128>: bneza5,0xffe00020b61c <_do_fork+766>
> >0xffe00020b3a2 <+132>: ld ra,136(sp)
> >0xffe00020b3a4 <+134>: ld s0,128(sp)
> >0xffe00020b3a6 <+136>: ld s1,120(sp)
> >0xffe00020b3a8 <+138>: ld s2,112(sp)
> >0xffe00020b3aa <+140>: ld s3,104(sp)
> >0xffe00020b3ac <+142>: ld s4,96(sp)
> >0xffe00020b3ae <+144>: ld s5,88(sp)
> >0xffe00020b3b0 <+146>: ld s6,80(sp)
> >0xffe00020b3b2 <+148>: ld s7,72(sp)
> >0xffe00020b3b4 <+150>: addisp,sp,144
> >0xffe00020b3b6 <+152>: ret
> >...
> > * 0xffe00020b61c <+766>: auipc ra,0x7f8
> > * 0xffe00020b620 <+770>: jalr-1764(ra) # 0xffe000a02f38
> > <__stack_chk_fail>
> >
> > Signed-off-by: Guo Ren
>
> Thanks for getting this working! It looks good to me. :)
>
> Reviewed-by: Kees Cook
>
> --
> Kees Cook
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
sprd_thermal.c:undefined reference to `devm_platform_ioremap_resource'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e28c0d7c92c89016c12a677616668957351e7542 commit: 554fdbaf19b188224d52d2fa80c049e4d42002e8 thermal: sprd: Add Spreadtrum thermal driver support date: 8 months ago config: s390-randconfig-r014-20201115 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=554fdbaf19b188224d52d2fa80c049e4d42002e8 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 554fdbaf19b188224d52d2fa80c049e4d42002e8 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): s390-linux-ld: aspeed-lpc-ctrl.c:(.text+0x184): undefined reference to `of_address_to_resource' s390-linux-ld: drivers/soc/aspeed/aspeed-p2a-ctrl.o: in function `aspeed_p2a_ctrl_probe': aspeed-p2a-ctrl.c:(.text+0x326): undefined reference to `of_address_to_resource' s390-linux-ld: drivers/soc/bcm/brcmstb/common.o: in function `brcmstb_soc_device_early_init': common.c:(.init.text+0x36): undefined reference to `of_iomap' s390-linux-ld: common.c:(.init.text+0x5e): undefined reference to `iounmap' s390-linux-ld: drivers/soc/bcm/brcmstb/biuctrl.o: in function `brcmstb_biuctrl_init': biuctrl.c:(.init.text+0x42): undefined reference to `of_iomap' s390-linux-ld: drivers/soc/fsl/dpaa2-console.o: in function `dpaa2_console_close': dpaa2-console.c:(.text+0x64): undefined reference to `iounmap' s390-linux-ld: drivers/soc/fsl/dpaa2-console.o: in function `dpaa2_console_probe': dpaa2-console.c:(.text+0xbc): undefined reference to `of_address_to_resource' s390-linux-ld: drivers/soc/fsl/dpaa2-console.o: in function `dpaa2_generic_console_open.isra.0.constprop.0': dpaa2-console.c:(.text+0x1be): undefined reference to `ioremap' s390-linux-ld: dpaa2-console.c:(.text+0x1e6): undefined reference to `iounmap' s390-linux-ld: dpaa2-console.c:(.text+0x1fa): undefined reference to `ioremap' s390-linux-ld: dpaa2-console.c:(.text+0x316): undefined reference to `iounmap' s390-linux-ld: drivers/soc/mediatek/mtk-pmic-wrap.o: in function `pwrap_probe': mtk-pmic-wrap.c:(.text+0x114e): undefined reference to `devm_ioremap_resource' s390-linux-ld: mtk-pmic-wrap.c:(.text+0x1424): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/soc/amlogic/meson-canvas.o: in function `meson_canvas_probe': meson-canvas.c:(.text+0x56): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/soc/qcom/qcom-geni-se.o: in function `geni_se_probe': qcom-geni-se.c:(.text+0x5c): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/soc/qcom/qcom_gsbi.o: in function `gsbi_probe': qcom_gsbi.c:(.text+0x6c): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/soc/qcom/smem.o: in function `qcom_smem_map_memory': smem.c:(.text+0xaa): undefined reference to `of_address_to_resource' s390-linux-ld: smem.c:(.text+0xe6): undefined reference to `devm_ioremap_wc' s390-linux-ld: drivers/soc/qcom/llcc-qcom.o: in function `qcom_llcc_init_mmio': llcc-qcom.c:(.text+0x1a2): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/soc/renesas/renesas-soc.o: in function `renesas_soc_init': renesas-soc.c:(.init.text+0x64): undefined reference to `of_iomap' s390-linux-ld: renesas-soc.c:(.init.text+0x7c): undefined reference to `iounmap' s390-linux-ld: renesas-soc.c:(.init.text+0xd0): undefined reference to `of_iomap' s390-linux-ld: renesas-soc.c:(.init.text+0xf4): undefined reference to `ioremap' s390-linux-ld: renesas-soc.c:(.init.text+0x108): undefined reference to `iounmap' s390-linux-ld: drivers/soc/renesas/rcar-sysc.o: in function `rcar_sysc_pd_init': rcar-sysc.c:(.init.text+0x7c): undefined reference to `of_iomap' s390-linux-ld: drivers/regulator/stm32-vrefbuf.o: in function `stm32_vrefbuf_probe': stm32-vrefbuf.c:(.text+0x2a0): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/regulator/stm32-pwr.o: in function `stm32_pwr_regulator_probe': stm32-pwr.c:(.text+0x250): undefined reference to `of_iomap' s390-linux-ld: drivers/regulator/uniphier-regulator.o: in function `uniphier_regulator_probe': uniphier-regulator.c:(.text+0xd0): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/reset/reset-ath79.o: in function `ath79_reset_probe': reset-ath79.c:(.text+0x8c): undefined
Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
Hi Russell, On 15.11.20 02:02, Russell King - ARM Linux admin wrote: > On Sun, Nov 15, 2020 at 01:41:51AM +0100, Andreas Färber wrote: >> Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta: >> Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX. >> >> In case a comphy is not provided, mvneta_validate()'s check >> state->interface == PHY_INTERFACE_MODE_2500BASEX >> could never be true (it would've returned with empty bitmask before), >> so that 2500baseT_Full and 2500baseX_Full do net get added to the mask. > > This makes me nervous. It was intentional that if there is no comphy > configured in DT for SoCs such as Armada 388, then there is no support > to switch between 1G and 2.5G speed. Unfortunately, the configuration > of the comphy is up to the board to do, not the SoC .dtsi, so we can't > rely on there being a comphy on Armada 388 systems. Please note that the if clause at the beginning of the validate function does not check for comphy at all. So even with comphy, if there is a code path that attempts to validate state 2500BASEX, it is broken, too. Do you consider the modification of both ifs (validate and power_up) as correct? Should they be split off from my main _NA change you discuss? > So, one of the side effects of this patch is it incorrectly opens up > the possibility of allowing 2.5G support on Armada 388 without a comphy > configured. > > We really need a better way to solve this; just relying on the lack of > comphy and poking at a register that has no effect on Armada 388 to > select 2.5G speed while allowing 1G and 2.5G to be arbitarily chosen > doesn't sound like a good idea to me. [snip] May I add that the comphy needs better documentation? Marek and I independently came up with < 2> in the end, but the DT binding doesn't explain what the index is supposed to be and how I might figure it out. It cost me days of reading U-Boot and kernel sources and playing around with values until I had the working one. Might be helpful to have a symbolic dt-bindings #define for this 2. U-Boot v2020.10 on Turris Omnia dumps this table: | Lane # | Speed | Type | | 0| 6 | SATA0 | | 1| 5 | USB3 HOST0 | | 2| 5 | PCIe1 | | 3| 5 | USB3 HOST1 | | 4| 5 | PCIe2 | | 5| 0 | SGMII2 | But IIUC the Linux comphy driver doesn't take any type ID as argument but rather an index into a table of "ports" which specifies another index to apply or look up? Terribly indirect and magic to non-experts. As a DT contributor I would need the binding to tell me that it's an enum with 2 meaning SGMII2. Not even the max of 2 is documented. The Linux driver talks of ports, but I don't see that term used in U-Boot, and U-Boot APIs appeared to pass very different args in the board code. The binding also still needs to be converted to YAML before we can extend it with any better explanations. (And before you suggest it: Since I obviously don't fully understand that hardware, I'm the wrong person to attempt documenting it. The 38x comphy seems not mentioned in MAINTAINERS, only the 3700 one.) Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Re: [PATCH v4 net-next 00/13] Add ethtool ntuple filters support
On Sat, Nov 14, 2020 at 11:53 AM Naveen Mamindlapalli wrote: > > This patch series adds support for ethtool ntuple filters, unicast > address filtering, VLAN offload and SR-IOV ndo handlers. All of the > above features are based on the Admin Function(AF) driver support to > install and delete the low level MCAM entries. Each MCAM entry is > programmed with the packet fields to match and what actions to take > if the match succeeds. The PF driver requests AF driver to allocate > set of MCAM entries to be used to install the flows by that PF. The > entries will be freed when the PF driver is unloaded. > > * The patches 1 to 4 adds AF driver infrastructure to install and > delete the low level MCAM flow entries. > * Patch 5 adds ethtool ntuple filter support. > * Patch 6 adds unicast MAC address filtering. > * Patch 7 adds support for dumping the MCAM entries via debugfs. > * Patches 8 to 10 adds support for VLAN offload. > * Patch 10 to 11 adds support for SR-IOV ndo handlers. > * Patch 12 adds support to read the MCAM entries. > > Misc: > * Removed redundant mailbox NIX_RXVLAN_ALLOC. > > Change-log: > v4: > - Fixed review comments from Alexander Duyck on v3. > - Added macros for KEX profile configuration values. > - TCP/UDP SPORT+DPORT extracted using single entry. > - Use eth_broadcast_addr() instead of memcpy to avoid one extra > variable. > - Fix "ether type" to "Ethertype" & "meta data" to "metadata" in > comments. > - Added more comments. > v3: > - Fixed Saeed's review comments on v2. > - Fixed modifying the netdev->flags from driver. > - Fixed modifying the netdev features and hw_features after > register_netdev. > - Removed unwanted ndo_features_check callback. > v2: > - Fixed the sparse issues reported by Jakub. All of the fixes look like they are in place. Reviewed-by: Alexander Duyck
Re: [PATCH v2] Documentation: Chinese translation of Documentation/arm64/perf.rst
在 2020/11/14 上午6:22, Jonathan Corbet 写道: > On Thu, 29 Oct 2020 21:05:41 -0700 > Bailu Lin wrote: > >> This is a Chinese translated version of >> Documentation/arm64/perf.rst >> >> Signed-off-by: Bailu Lin >> --- >> Changes in v2: >> - Modify a translation of 'guest/host/blackout window' as Alex sugguested. >> --- >> Documentation/arm64/perf.rst | 2 + >> .../translations/zh_CN/arm64/index.rst| 1 + >> .../translations/zh_CN/arm64/perf.rst | 86 +++ >> 3 files changed, 89 insertions(+) >> create mode 100644 Documentation/translations/zh_CN/arm64/perf.rst > > Applied, thanks. > > BTW, many thanks to Alex for reviewing all of these, it definitely > improves my confidence in applying them :) > My pleasure! I am very glad that's helpful. :) Thanks Alex
phy-tegra-usb.c:undefined reference to `clk_get_parent'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e28c0d7c92c89016c12a677616668957351e7542 commit: 91687c1926bcd6b80d669375d57331b7bf80bf99 usb: phy: Enable compile testing for some of drivers date: 11 months ago config: mips-randconfig-c003-20201104 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91687c1926bcd6b80d669375d57331b7bf80bf99 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 91687c1926bcd6b80d669375d57331b7bf80bf99 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mipsel-linux-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x97c): undefined reference to `clk_set_parent' mipsel-linux-ld: drivers/gpu/drm/exynos/exynos_hdmi.o: in function `hdmi_clk_set_parents': exynos_hdmi.c:(.text+0x374): undefined reference to `clk_set_parent' mipsel-linux-ld: drivers/gpu/drm/ingenic/ingenic-drm.o: in function `ingenic_drm_probe': ingenic-drm.c:(.text+0xf40): undefined reference to `clk_get_parent' mipsel-linux-ld: drivers/usb/phy/phy-tegra-usb.o: in function `tegra_usb_phy_probe': >> phy-tegra-usb.c:(.text+0x6cc): undefined reference to `clk_get_parent' mipsel-linux-ld: sound/soc/meson/axg-tdm-formatter.o: in function `axg_tdm_formatter_event': (.text+0x7ec): undefined reference to `clk_set_parent' mipsel-linux-ld: (.text+0x940): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/sh/fsi.o: in function `fsi_clk_set_rate_external': fsi.c:(.text+0x2728): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/stm/stm32_i2s.o: in function `stm32_i2s_hw_params': stm32_i2s.c:(.text+0x16b4): undefined reference to `clk_set_parent' mipsel-linux-ld: stm32_i2s.c:(.text+0x1820): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/ti/davinci-mcasp.o:davinci-mcasp.c:(.text+0x1f28): more undefined references to `clk_set_parent' follow mipsel-linux-ld: sound/soc/ti/omap-dmic.o: in function `omap_dmic_set_dai_sysclk': omap-dmic.c:(.text+0xa98): undefined reference to `clk_get_parent' mipsel-linux-ld: omap-dmic.c:(.text+0xadc): undefined reference to `clk_set_parent' mipsel-linux-ld: omap-dmic.c:(.text+0xbb8): undefined reference to `clk_set_parent' mipsel-linux-ld: sound/soc/ti/omap-mcbsp.o: in function `omap2_mcbsp_set_clks_src': omap-mcbsp.c:(.text+0x7ac): undefined reference to `clk_set_parent' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v2 2/4] clk: qcom: Add SDX55 GCC support
On Fri 06 Nov 03:38 CST 2020, Vinod Koul wrote:
> On 05-11-20, 16:18, Manivannan Sadhasivam wrote:
> > From: Naveen Yadav
> >
> > Add Global Clock Controller (GCC) support for SDX55 SoCs from Qualcomm.
> >
> > Signed-off-by: Naveen Yadav
> > [mani: converted to parent_data, commented critical clocks, cleanups]
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > drivers/clk/qcom/Kconfig |7 +
> > drivers/clk/qcom/Makefile|1 +
> > drivers/clk/qcom/gcc-sdx55.c | 1626 ++
> > 3 files changed, 1634 insertions(+)
> > create mode 100644 drivers/clk/qcom/gcc-sdx55.c
> >
> > diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> > index 3a965bd326d5..7897a3947e6d 100644
> > --- a/drivers/clk/qcom/Kconfig
> > +++ b/drivers/clk/qcom/Kconfig
> > @@ -413,6 +413,13 @@ config SDM_LPASSCC_845
> > Say Y if you want to use the LPASS branch clocks of the LPASS clock
> > controller to reset the LPASS subsystem.
> >
> > +config SDX_GCC_55
> > + tristate "SDX55 Global Clock Controller"
> > + help
> > + Support for the global clock controller on SDX55 devices.
> > + Say Y if you want to use peripheral devices such as UART,
> > + SPI, I2C, USB, SD/UFS, PCIe etc.
> > +
> > config SM_DISPCC_8250
> > tristate "SM8150 and SM8250 Display Clock Controller"
> > depends on SM_GCC_8150 || SM_GCC_8250
> > diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> > index 11ae86febe87..886b877e70c7 100644
> > --- a/drivers/clk/qcom/Makefile
> > +++ b/drivers/clk/qcom/Makefile
> > @@ -64,6 +64,7 @@ obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
> > obj-$(CONFIG_SDM_GPUCC_845) += gpucc-sdm845.o
> > obj-$(CONFIG_SDM_LPASSCC_845) += lpasscc-sdm845.o
> > obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
> > +obj-$(CONFIG_SDX_GCC_55) += gcc-sdx55.o
> > obj-$(CONFIG_SM_DISPCC_8250) += dispcc-sm8250.o
> > obj-$(CONFIG_SM_GCC_8150) += gcc-sm8150.o
> > obj-$(CONFIG_SM_GCC_8250) += gcc-sm8250.o
> > diff --git a/drivers/clk/qcom/gcc-sdx55.c b/drivers/clk/qcom/gcc-sdx55.c
> > new file mode 100644
> > index ..bf114165e24b
> > --- /dev/null
> > +++ b/drivers/clk/qcom/gcc-sdx55.c
> > @@ -0,0 +1,1626 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
> > + * Copyright (c) 2020, Linaro Ltd.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "common.h"
> > +#include "clk-alpha-pll.h"
> > +#include "clk-branch.h"
> > +#include "clk-pll.h"
> > +#include "clk-rcg.h"
> > +#include "clk-regmap.h"
> > +#include "reset.h"
> > +
> > +enum {
> > + P_BI_TCXO,
> > + P_CORE_BI_PLL_TEST_SE,
>
> This is for test and we removed this for upstream, so can you do that as
> well (not parent will decrease for clks below)
>
We have several other platforms that includes the bi_pll_test clock -
and it's there in the hardware, so I think we should just keep it.
Is it causing any issues?
Regards,
Bjorn
> With that updated:
>
> Reviewed-by: Vinod Koul
>
> --
> ~Vinod
Re: [PATCH v2 3/9] media: Rename stateful codec control macros
On Sat, 2020-11-14 at 13:53 +0100, Hans Verkuil wrote:
> On 13/11/2020 22:51, Ezequiel Garcia wrote:
> > For historical reasons, stateful codec controls are named
> > as {}_MPEG_{}. While we can't at this point sanely
> > change all control IDs (such as V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER),
> > we can least change the more meaningful macros such as classes
> > macros.
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
> > .../userspace-api/media/v4l/dev-mem2mem.rst | 2 +-
> > .../media/v4l/ext-ctrls-codec.rst | 4 +-
> > .../media/v4l/extended-controls.rst | 8 +-
> > .../media/v4l/vidioc-g-ext-ctrls.rst | 6 +-
> > drivers/media/common/cx2341x.c| 4 +-
> > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +-
> > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 2 +-
> > drivers/media/v4l2-core/v4l2-ctrls.c | 4 +-
> > include/media/fwht-ctrls.h| 2 +-
> > include/media/h264-ctrls.h| 16 +-
> > include/media/hevc-ctrls.h| 10 +-
> > include/media/mpeg2-ctrls.h | 4 +-
> > include/media/vp8-ctrls.h | 2 +-
> > include/uapi/linux/v4l2-controls.h| 409 +-
> > 14 files changed, 242 insertions(+), 233 deletions(-)
> >
>
>
>
> > @@ -1177,4 +1177,13 @@ enum v4l2_detect_md_mode {
> > #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_CLASS_BASE + 3)
> > #define V4L2_CID_DETECT_MD_REGION_GRID
> > (V4L2_CID_DETECT_CLASS_BASE + 4)
> >
> > +/* MPEG-compression definitions kept for backwards compatibility */
> > +#ifndef __KERNEL__
> > +#define V4L2_CTRL_CLASS_MPEGV4L2_CTRL_CLASS_CODEC
> > +#define V4L2_CID_MPEG_CLASS (V4L2_CTRL_CLASS_MPEG | 1)
> > +#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
> > +#define V4L2_CID_MPEG_CX2341X_BASE (V4L2_CTRL_CLASS_MPEG | 0x1000)
> > +#define V4L2_CID_MPEG_MFC51_BASE (V4L2_CTRL_CLASS_MPEG | 0x1100)
>
> Don't copy the offset value here, just keep this as a straight aliases, e.g.:
>
> #define V4L2_CID_MPEG_MFC51_BASE V4L2_CID_CODEC_MFC51_BASE
>
> It's safer that way.
>
Yes, indeed.
Thanks,
Ezequiel
Re: [PATCH v2 9/9] media: docs: Move the H264 stateless codec uAPI
On Sat, 2020-11-14 at 13:57 +0100, Hans Verkuil wrote: > On 13/11/2020 22:51, Ezequiel Garcia wrote: > > Now that we've destaged the H264 stateless codec controls, > > and with all the pieces in place, update the documentation > > and move it to its own section. > > > > Signed-off-by: Ezequiel Garcia > > --- > > .../userspace-api/media/v4l/common.rst| 1 + > > .../media/v4l/ext-ctrls-codec-stateless.rst | 674 + > > .../media/v4l/ext-ctrls-codec.rst | 692 -- > > .../media/v4l/pixfmt-compressed.rst | 14 +- > > 4 files changed, 682 insertions(+), 699 deletions(-) > > create mode 100644 > > Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst > > b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst > > index d585909bc4e2..32b91ce0f0d9 100644 > > --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst > > +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst > > @@ -59,14 +59,14 @@ Compressed Formats > > This format is adapted for stateless video decoders that implement an > > H264 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`). > > This pixelformat has two modifiers that must be set at least once > > - through the ``V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE`` > > -and ``V4L2_CID_MPEG_VIDEO_H264_START_CODE`` controls. > > + through the ``V4L2_CID_STATELESS_H264_DECODE_MODE`` > > +and ``V4L2_CID_STATELESS_H264_START_CODE`` controls. > > In addition, metadata associated with the frame to decode are > > - required to be passed through the ``V4L2_CID_MPEG_VIDEO_H264_SPS``, > > - ``V4L2_CID_MPEG_VIDEO_H264_PPS``, > > - ``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX``, > > - ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS`` and > > - ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS`` controls. See the > > + required to be passed through the ``V4L2_CID_STATELESS_H264_SPS``, > > + ``V4L2_CID_STATELESS_H264_PPS``, > > + ``V4L2_CID_STATELESS_H264_SCALING_MATRIX``, > > + ``V4L2_CID_STATELESS_H264_SLICE_PARAMS`` and > > + ``V4L2_CID_STATELESS_H264_DECODE_PARAMS`` controls. See the > > :ref:`associated Codec Control IDs `. Exactly > > one output and one capture buffer must be provided for use > > with this pixel format. The output buffer must contain the > > > > There is a note about this 'format not yet part of the public API' that > needs to be deleted as well. > Good catch. Thanks, Eze > > >
Re: [PATCH v3] net: openvswitch: use core API to update/provide stats
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Fri, 13 Nov 2020 23:53:36 +0200 you wrote:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
> function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
> stats.
>
> Use this function instead of own code.
>
> While on it, remove internal_get_stats() and replace it
> with dev_get_tstats64().
>
> [...]
Here is the summary with links:
- [v3] net: openvswitch: use core API to update/provide stats
https://git.kernel.org/netdev/net-next/c/865e6ae02dd7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v3] net: xfrm: use core API for updating/providing stats
On Fri, 13 Nov 2020 23:59:40 +0200 Lev Stipakov wrote:
> Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
> function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
> stats.
>
> Use this function instead of own code.
>
> While on it, remove xfrmi_get_stats64() and replace it with
> dev_get_tstats64().
>
> Signed-off-by: Lev Stipakov
> Reviewed-by: Heiner Kallweit
Since this is a follow up to Heiner's work I'll apply directly as well.
Thanks!
Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
On Sun, Nov 15, 2020 at 01:41:51AM +0100, Andreas Färber wrote: > Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta: > Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX. > > In case a comphy is not provided, mvneta_validate()'s check > state->interface == PHY_INTERFACE_MODE_2500BASEX > could never be true (it would've returned with empty bitmask before), > so that 2500baseT_Full and 2500baseX_Full do net get added to the mask. This makes me nervous. It was intentional that if there is no comphy configured in DT for SoCs such as Armada 388, then there is no support to switch between 1G and 2.5G speed. Unfortunately, the configuration of the comphy is up to the board to do, not the SoC .dtsi, so we can't rely on there being a comphy on Armada 388 systems. So, one of the side effects of this patch is it incorrectly opens up the possibility of allowing 2.5G support on Armada 388 without a comphy configured. We really need a better way to solve this; just relying on the lack of comphy and poking at a register that has no effect on Armada 388 to select 2.5G speed while allowing 1G and 2.5G to be arbitarily chosen doesn't sound like a good idea to me. Clearly there are differences in mvneta hardware in different SoCs. Maybe they should have used different compatibles, so the driver can know which variant of the hardware it is dealing with, rather than relying on presence/lack of comphy. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
Hi, Bilal:
Please help to test this patch on your Chromebook elm, thanks.
Regards,
Chun-Kuang Hu
Chun-Kuang Hu 於 2020年11月15日 週日 上午8:14寫道：
>
> From: CK Hu
>
> Using vm->hfront_porch + vm->hback_porch to calculate
> horizontal_backporch_byte would make it negtive, so
> use horizontal_backporch_byte itself to make it positive.
>
> Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel with small
> hfp or hbp")
>
> Signed-off-by: CK Hu
> Signed-off-by: Chun-Kuang Hu
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 53 ++
> 1 file changed, 18 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4a188a942c38..2a64fdaed9a7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -444,7 +444,10 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
> u32 horizontal_sync_active_byte;
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> + u32 horizontal_front_back_byte;
> + u32 data_phy_cycles_byte;
> u32 dsi_tmp_buf_bpp, data_phy_cycles;
> + u32 delta;
> struct mtk_phy_timing *timing = >phy_timing;
>
> struct videomode *vm = >vm;
> @@ -474,42 +477,22 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
> data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> timing->da_hs_zero + timing->da_hs_exit;
>
> - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> - if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
> - data_phy_cycles * dsi->lanes + 18) {
> - horizontal_frontporch_byte =
> - vm->hfront_porch * dsi_tmp_buf_bpp -
> - (data_phy_cycles * dsi->lanes + 18) *
> - vm->hfront_porch /
> - (vm->hfront_porch + vm->hback_porch);
> -
> - horizontal_backporch_byte =
> - horizontal_backporch_byte -
> - (data_phy_cycles * dsi->lanes + 18) *
> - vm->hback_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - } else {
> - DRM_WARN("HFP less than d-phy, FPS will under
> 60Hz\n");
> - horizontal_frontporch_byte = vm->hfront_porch *
> -dsi_tmp_buf_bpp;
> - }
> + delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 : 12;
> +
> + horizontal_frontporch_byte = vm->hfront_porch * dsi_tmp_buf_bpp;
> + horizontal_front_back_byte = horizontal_frontporch_byte +
> horizontal_backporch_byte;
> + data_phy_cycles_byte = data_phy_cycles * dsi->lanes + delta;
> +
> + if (horizontal_front_back_byte > data_phy_cycles_byte) {
> + horizontal_frontporch_byte -= data_phy_cycles_byte *
> + horizontal_frontporch_byte /
> + horizontal_front_back_byte;
> +
> + horizontal_backporch_byte -= data_phy_cycles_byte *
> +horizontal_backporch_byte /
> +horizontal_front_back_byte;
> } else {
> - if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
> - data_phy_cycles * dsi->lanes + 12) {
> - horizontal_frontporch_byte =
> - vm->hfront_porch * dsi_tmp_buf_bpp -
> - (data_phy_cycles * dsi->lanes + 12) *
> - vm->hfront_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - horizontal_backporch_byte = horizontal_backporch_byte
> -
> - (data_phy_cycles * dsi->lanes + 12) *
> - vm->hback_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - } else {
> - DRM_WARN("HFP less than d-phy, FPS will under
> 60Hz\n");
> - horizontal_frontporch_byte = vm->hfront_porch *
> -dsi_tmp_buf_bpp;
> - }
> + DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
> }
>
> writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> --
> 2.17.1
>
Re: [PATCH] rtc: at91rm9200: add correction support
On 10/11/2020 14:18:27+0100, Nicolas Ferre wrote:
> Hi Alexandre,
>
> Thanks you for adding this feature to newest at91 RTC IPs.
>
>
> On 09/11/2020 at 00:20, Alexandre Belloni wrote:
> > The sama5d4 and sama5d2 RTCs are able to correct for imprecise crystals, up
>
> FYI, sam9x60 RTC has the same correction capability.
>
> ... and I now realize that sam9x60 using sam9x5-rtc compatibility sting is
> maybe not the right choice...
>
I did see that when I reviewed the sam9x60 dtsi and it has its own
compatible string upstream.
> > to 1953 ppm.
> >
> > Signed-off-by: Alexandre Belloni
> > ---
> > drivers/rtc/rtc-at91rm9200.c | 103 +--
> > 1 file changed, 99 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
> > index 5e811e04cb21..1eea187d9850 100644
> > --- a/drivers/rtc/rtc-at91rm9200.c
> > +++ b/drivers/rtc/rtc-at91rm9200.c
> > @@ -36,6 +36,10 @@
> > #defineAT91_RTC_UPDCAL BIT(1) /* Update
> > Request Calendar Register */
> >
> > #defineAT91_RTC_MR 0x04/* Mode
> > Register */
> > +#defineAT91_RTC_HRMOD BIT(0) /* 12/24
> > hour mode */
> > +#defineAT91_RTC_NEGPPM BIT(4) /* Negative
> > PPM correction */
> > +#defineAT91_RTC_CORRECTION GENMASK(14, 8) /* Slow
> > clock correction */
> > +#defineAT91_RTC_HIGHPPMBIT(15) /* High PPM
> > correction */
> >
> > #defineAT91_RTC_TIMR 0x08/* Time
> > Register */
> > #defineAT91_RTC_SECGENMASK(6, 0) /* Current
> > Second */
> > @@ -77,6 +81,9 @@
> > #defineAT91_RTC_NVTIMALR BIT(2) /* Non
> > valid Time Alarm */
> > #defineAT91_RTC_NVCALALR BIT(3) /* Non
> > valid Calendar Alarm */
> >
> > +#define AT91_RTC_CORR_DIVIDEND 3906000
> > +#define AT91_RTC_CORR_LOW_RATIO20
>
> IMHO, it's worth telling here that these values are from the product
> datasheet in formula coming from explanation of HIGHPPM bit of register
> RTC_MR.
>
> > +static int at91_rtc_setoffset(struct device *dev, long offset)
> > +{
> > + long corr;
> > + u32 mr;
> > +
> > + if (offset > AT91_RTC_CORR_DIVIDEND / 2)
> > + return -ERANGE;
> > + if (offset < -AT91_RTC_CORR_DIVIDEND / 2)
> > + return -ERANGE;
> > +
> > + mr = at91_rtc_read(AT91_RTC_MR);
> > + mr &= ~(AT91_RTC_NEGPPM | AT91_RTC_CORRECTION | AT91_RTC_HIGHPPM);
> > +
> > + if (offset > 0)
> > + mr |= AT91_RTC_NEGPPM;
> > + else
> > + offset = -offset;
> > +
> > + /* offset less than 764 ppb, disable correction*/
>
> Does it correspond to the 1.5 ppm value of the datasheet?
> (sorry I'm not so used to these computations?)
>
Yes, 764ppb is closer to 1525ppb (the 1.5ppm from the datasheet) than 0
so at that point it starts to make sense to correct the offset.
> > + if (offset < 764) {
> > + at91_rtc_write(AT91_RTC_MR, mr & ~AT91_RTC_NEGPPM);
> > +
> > + return 0;
> > + }
> > +
> > + /*
> > +* 29208 ppb is the perfect cutoff between low range and high range
> > +* low range values are never better than high range value after
> > that.
>
> And here, I'm lost. Does it correspond to the sentence:
> "HIGHPPM set to 1 is recommended for 30 ppm correction and above." ? And
> rounding using register values, am I right?
>
The values in the datasheet are not that well rounded, the comment is
really the answer, starting with 29208ppb, with highppm = 1 the values
are a superset of the ones with highppm = 0
> > +*/
> > + if (offset < 29208) {
> > + corr = DIV_ROUND_CLOSEST(AT91_RTC_CORR_DIVIDEND, offset *
> > AT91_RTC_CORR_LOW_RATIO);
> > + } else {
> > + corr = DIV_ROUND_CLOSEST(AT91_RTC_CORR_DIVIDEND, offset);
> > + mr |= AT91_RTC_HIGHPPM;
> > + }
> > +
> > + if (corr > 128)
>
> Okay, it's maximized to the width of register field, got it.
>
Yes, this handles corrections between 764ppb and 1525ppb.
> > + corr = 128;
>
> I'm kind of following and don't know what other RTC drivers are doing... but
> would prefer more explanation on numerical values.
>
Well, there isn't much more to explain. However, I think the IP could be
a bit more friendly because high correction values means very little
correction is happening. Also, NEGPPM is reversed versus other RTCs and
it was not 100% clear from the datasheet.
> Alexandre, you know much more than me about the habits of RTC drivers
> writers. Even if I would like a little more documentation on values used, I
> absolutely won't hold this feature adoption, so here is my:
>
>
[PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta:
Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX.
In case a comphy is not provided, mvneta_validate()'s check
state->interface == PHY_INTERFACE_MODE_2500BASEX
could never be true (it would've returned with empty bitmask before),
so that 2500baseT_Full and 2500baseX_Full do net get added to the mask.
This causes phylink_sfp_config() to fail validation of 2.5G SFP support.
Address this by adding 2500baseX_Full and 2500baseT_Full to the mask for
state->interface == PHY_INTERFACE_MODE_NA
as well.
Also handle PHY_INTERFACE_MODE_2500BASEX in two checks for allowed modes
and update a comment.
Tested with 2.5G and 1G SFPs on Turris Omnia before assigning comphy.
Fixes: 1a642ca7f389 ("net: ethernet: mvneta: Add 2500BaseX support for SoCs
without comphy")
Cc: Sascha Hauer
Cc: David S. Miller
Cc: Marek Behún
Cc: Andrew Lunn
Cc: Uwe Kleine-König
Cc: Jason Cooper
Cc: Gregory CLEMENT
Signed-off-by: Andreas Färber
---
drivers/net/ethernet/marvell/mvneta.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 54b0bf574c05..c5016036de3a 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3812,10 +3812,11 @@ static void mvneta_validate(struct phylink_config
*config,
struct mvneta_port *pp = netdev_priv(ndev);
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
- /* We only support QSGMII, SGMII, 802.3z and RGMII modes */
+ /* We only support QSGMII, SGMII, HSGMII, 802.3z and RGMII modes */
if (state->interface != PHY_INTERFACE_MODE_NA &&
state->interface != PHY_INTERFACE_MODE_QSGMII &&
state->interface != PHY_INTERFACE_MODE_SGMII &&
+ state->interface != PHY_INTERFACE_MODE_2500BASEX &&
!phy_interface_mode_is_8023z(state->interface) &&
!phy_interface_mode_is_rgmii(state->interface)) {
bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
@@ -3834,7 +3835,8 @@ static void mvneta_validate(struct phylink_config *config,
phylink_set(mask, 1000baseT_Full);
phylink_set(mask, 1000baseX_Full);
}
- if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX) {
+ if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX
+ || state->interface == PHY_INTERFACE_MODE_NA) {
phylink_set(mask, 2500baseT_Full);
phylink_set(mask, 2500baseX_Full);
}
@@ -5038,6 +5040,7 @@ static int mvneta_port_power_up(struct mvneta_port *pp,
int phy_mode)
if (phy_mode != PHY_INTERFACE_MODE_QSGMII &&
phy_mode != PHY_INTERFACE_MODE_SGMII &&
+ phy_mode != PHY_INTERFACE_MODE_2500BASEX &&
!phy_interface_mode_is_8023z(phy_mode) &&
!phy_interface_mode_is_rgmii(phy_mode))
return -EINVAL;
--
2.28.0
drivers/usb/host/ehci-hcd.c:1286: warning: "PLATFORM_DRIVER" redefined
Hi Krzysztof,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
commit: 88eaaecc44461f9fb147bf7ee6ccc6d4e9fc23e0 usb: host: Enable compile
testing for some of drivers
date: 11 months ago
config: sparc-randconfig-r023-20201115 (attached as .config)
compiler: sparc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88eaaecc44461f9fb147bf7ee6ccc6d4e9fc23e0
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 88eaaecc44461f9fb147bf7ee6ccc6d4e9fc23e0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/usb/host/ehci-hcd.c:1286: warning: "PLATFORM_DRIVER" redefined
1286 | #define PLATFORM_DRIVER ehci_grlib_driver
|
drivers/usb/host/ehci-hcd.c:1261: note: this is the location of the previous
definition
1261 | #define PLATFORM_DRIVER ehci_hcd_sh_driver
|
In file included from drivers/usb/host/ehci-hcd.c:1260:
drivers/usb/host/ehci-sh.c:173:31: warning: 'ehci_hcd_sh_driver' defined but
not used [-Wunused-variable]
173 | static struct platform_driver ehci_hcd_sh_driver = {
| ^~
vim +/PLATFORM_DRIVER +1286 drivers/usb/host/ehci-hcd.c
22ced6874fc47bb Anoop 2011-02-24 1283
9be039298930636 Jan Andersson 2011-05-03 1284 #ifdef CONFIG_SPARC_LEON
9be039298930636 Jan Andersson 2011-05-03 1285 #include "ehci-grlib.c"
9be039298930636 Jan Andersson 2011-05-03 @1286 #define PLATFORM_DRIVER
ehci_grlib_driver
9be039298930636 Jan Andersson 2011-05-03 1287 #endif
9be039298930636 Jan Andersson 2011-05-03 1288
:: The code at line 1286 was first introduced by commit
:: 9be0392989306361d4a63a06a8ee281efbead548 USB: EHCI: Add bus glue for
GRLIB GRUSBHC controller
:: TO: Jan Andersson
:: CC: Greg Kroah-Hartman
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 net] devlink: Add missing genlmsg_cancel() in devlink_nl_sb_port_pool_fill()
On Fri, 13 Nov 2020 19:16:22 +0800 Wang Hai wrote:
> If sb_occ_port_pool_get() failed in devlink_nl_sb_port_pool_fill(),
> msg should be canceled by genlmsg_cancel().
>
> Fixes: df38dafd2559 ("devlink: implement shared buffer occupancy monitoring
> interface")
> Reported-by: Hulk Robot
> Signed-off-by: Wang Hai
Applied, thanks!
Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox
On Fri, Nov 13, 2020 at 5:09 PM Ben Widawsky wrote:
[..]
> > Unused, maybe move it to the patch that adds the use?
> >
>
> This is a remnant from when Dan gave me the basis to do the mmio work. I agree
> it can be removed now.
Yes.
> > > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > > +{
> > > + int pos;
> > > +
> > > + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > > + if (!pos)
> > > + return 0;
> > > +
> > > + while (pos) {
> > > + u16 vendor, id;
> > > +
> > > + pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET,
> > > );
> > > + pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, );
> > > + if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > > + return pos;
> > > +
> > > + pos = pci_find_next_ext_capability(pdev, pos,
> > > PCI_EXT_CAP_ID_DVSEC);
> > > + }
> > > +
> > > + return 0;
> > > +}
> >
> > I assume we'll refactor and move this into the PCI core after we
> > resolve the several places this is needed. When we do that, the
> > vendor would be passed in, so maybe we should do that here to make it
> > simpler to move this to the PCI core.
> >
>
> I think we'll need to keep this in order to try to keep the dream alive of
> loading a CXL kernel module on an older kernel. However, PCI code would
> benefit
> from having it (in an ideal world, it'd only be there).
So I think this is fine / expected to move standalone common code like
this to the PCI core. What I'm aiming to avoid with "the dream" Ben
references is unnecessary dependencies on core changes. CXL is large
enough that it will generate more backport pressure than ACPI NFIT /
LIBNVDIMM ever did. From a self interest perspective maximizing how
much of CXL can be enabled without core dependencies is a goal just to
lighten my own backport load. The internals of cxl_mem_dvsec() are
simple enough to backport.
>
> > > +static int cxl_mem_probe(struct pci_dev *pdev, const struct
> > > pci_device_id *id)
> > > +{
> > > + struct device *dev = >dev;
> > > + struct cxl_mem *cxlm;
> > > + int rc, regloc;
> > > +
> > > + rc = cxl_bus_prepared(pdev);
> > > + if (rc != 0) {
> > > + dev_err(dev, "failed to acquire interface\n");
> >
> > Interesting naming: apparently when cxl_bus_prepared() returns a
> > non-zero ("true") value, it is actually *not* prepared?
> >
>
> This looks like a rebase fail to me, but I'll let Dan answer.
Yeah, I originally envisioned this as a ternary result with
-EPROBE_DEFER as a possible return value, but now that we've found a
way to handle CXL _OSC without colliding with legacy PCIE _OSC this
can indeed move to a boolean result.
Will fix up.
>
> > > + return rc;
> > > + }
> > > +
> > > + regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > > + if (!regloc) {
> > > + dev_err(dev, "register location dvsec not found\n");
> > > + return -ENXIO;
> > > + }
> > > +
> > > + cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> > > + if (!cxlm)
> > > + return -ENOMEM;
> >
> > Unused. And [4/9] removes it before it's *ever* used :)
> >
>
> Same as a few above, I think Dan was providing this for me to implement the
> reset. It could go away...
Yes, a collaboration artifact that we can clean up.
>
> > > + return 0;
> > > +}
> > > +
> > > +static void cxl_mem_remove(struct pci_dev *pdev)
> > > +{
> > > +}
> > > +
> > > +static const struct pci_device_id cxl_mem_pci_tbl[] = {
> > > + /* PCI class code for CXL.mem Type-3 Devices */
> > > + { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > > + PCI_CLASS_MEMORY_CXL, 0xff, 0 },
> > > + { /* terminate list */ },
> > > +};
> > > +MODULE_DEVICE_TABLE(pci, cxl_mem_pci_tbl);
> > > +
> > > +static struct pci_driver cxl_mem_driver = {
> > > + .name = KBUILD_MODNAME,
> > > + .id_table = cxl_mem_pci_tbl,
> > > + .probe = cxl_mem_probe,
> > > + .remove = cxl_mem_remove,
> > > +};
> > > +
> > > +MODULE_LICENSE("GPL v2");
> > > +MODULE_AUTHOR("Intel Corporation");
> > > +module_pci_driver(cxl_mem_driver);
> > > +MODULE_IMPORT_NS(CXL);
> > > diff --git a/drivers/cxl/pci.h b/drivers/cxl/pci.h
> > > new file mode 100644
> > > index ..beb03921e6da
> > > --- /dev/null
> >
> > > +++ b/drivers/cxl/pci.h
> > > @@ -0,0 +1,15 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> >
> > /* SPDX-... */
> > /* Copyright ...*/
> >
> > The SPDX rules are a bit arcane and annoyingly hard to grep for, but
> > I found them in Documentation/process/license-rules.rst
Yes, I did not realize the header vs source /* */ vs // SPDX style.
> >
> > > +#ifndef __CXL_PCI_H__
> > > +#define __CXL_PCI_H__
> > > +
> > > +#define PCI_CLASS_MEMORY_CXL 0x050210
> > > +
> > > +#define PCI_EXT_CAP_ID_DVSEC 0x23
> > > +#define
[PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
From: CK Hu
Using vm->hfront_porch + vm->hback_porch to calculate
horizontal_backporch_byte would make it negtive, so
use horizontal_backporch_byte itself to make it positive.
Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel with small hfp
or hbp")
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 53 ++
1 file changed, 18 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4a188a942c38..2a64fdaed9a7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -444,7 +444,10 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_sync_active_byte;
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
+ u32 horizontal_front_back_byte;
+ u32 data_phy_cycles_byte;
u32 dsi_tmp_buf_bpp, data_phy_cycles;
+ u32 delta;
struct mtk_phy_timing *timing = >phy_timing;
struct videomode *vm = >vm;
@@ -474,42 +477,22 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
data_phy_cycles = timing->lpx + timing->da_hs_prepare +
timing->da_hs_zero + timing->da_hs_exit;
- if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
- if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
- data_phy_cycles * dsi->lanes + 18) {
- horizontal_frontporch_byte =
- vm->hfront_porch * dsi_tmp_buf_bpp -
- (data_phy_cycles * dsi->lanes + 18) *
- vm->hfront_porch /
- (vm->hfront_porch + vm->hback_porch);
-
- horizontal_backporch_byte =
- horizontal_backporch_byte -
- (data_phy_cycles * dsi->lanes + 18) *
- vm->hback_porch /
- (vm->hfront_porch + vm->hback_porch);
- } else {
- DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
- horizontal_frontporch_byte = vm->hfront_porch *
-dsi_tmp_buf_bpp;
- }
+ delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 : 12;
+
+ horizontal_frontporch_byte = vm->hfront_porch * dsi_tmp_buf_bpp;
+ horizontal_front_back_byte = horizontal_frontporch_byte +
horizontal_backporch_byte;
+ data_phy_cycles_byte = data_phy_cycles * dsi->lanes + delta;
+
+ if (horizontal_front_back_byte > data_phy_cycles_byte) {
+ horizontal_frontporch_byte -= data_phy_cycles_byte *
+ horizontal_frontporch_byte /
+ horizontal_front_back_byte;
+
+ horizontal_backporch_byte -= data_phy_cycles_byte *
+horizontal_backporch_byte /
+horizontal_front_back_byte;
} else {
- if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
- data_phy_cycles * dsi->lanes + 12) {
- horizontal_frontporch_byte =
- vm->hfront_porch * dsi_tmp_buf_bpp -
- (data_phy_cycles * dsi->lanes + 12) *
- vm->hfront_porch /
- (vm->hfront_porch + vm->hback_porch);
- horizontal_backporch_byte = horizontal_backporch_byte -
- (data_phy_cycles * dsi->lanes + 12) *
- vm->hback_porch /
- (vm->hfront_porch + vm->hback_porch);
- } else {
- DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
- horizontal_frontporch_byte = vm->hfront_porch *
-dsi_tmp_buf_bpp;
- }
+ DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
}
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
--
2.17.1
Re: [PATCH] net: stmmac: dwmac_lib: enlarge dma reset timeout
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 13 Nov 2020 09:09:02 +0800 you wrote: > If the phy enables power saving technology, the dwmac's software reset > needs more time to complete, enlarge dma reset timeout to 20us. > > Signed-off-by: Jisheng Zhang > --- > drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Here is the summary with links: - net: stmmac: dwmac_lib: enlarge dma reset timeout https://git.kernel.org/netdev/net/c/56311a315da7 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v2 0/9] Stateless H.264 de-staging
Hi Hans, Thanks for the quick review. On Sat, 2020-11-14 at 13:58 +0100, Hans Verkuil wrote: > On 13/11/2020 22:51, Ezequiel Garcia wrote: > > Now that H.264 stateless controls are solid, we can get it > > out of staging. > > > > Following some guidelines from Hans, this series creates a > > new stateless control class for the stable codec controls to land. > > > > While here, I'm including a patch from Jonas adding profiles > > and levels to Rkvdec, and also made a similar fix for Cedrus. > > > > This series was tested on a i.MX8MQ EVK board, using GStreamer: > > > > https://gitlab.freedesktop.org/ezequielgarcia/gst-plugins-bad/-/commits/h264_stable_uapi > > > > In case someone wants to give this a test. > > > > Note that v4l2-compliance isn't passing, as the Hantro driver > > doesn't set legal default values for the H264 SPS, PPS, etc > > controls. > > > > That's something we should fix, although it's since it's just > > meant to please v4l2-compliance, we could also argue that these > > controls shouldn't be expected to have any default value. > Looking into more detail, v4l2-compliance was failing due to checks in std_validate_compound for VP8 controls. H264 controls are not currently validated (but sounds like we'll want to, from below discussion). > This really needs to be fixed. I've ignored this issue since the API > was in staging and still changing, but when we move it out of staging, > then this issue should be tackled. > Sure. > It should likely be done in std_init_compound() in v4l2-ctrls.c. > Yes, MPEG2 controls are already initialized over there. > > It is probably a good idea to also verify std_validate_compound(), making > sure that everything there is still valid and up to date. > Indeed. I'm actually more concerned about std_validate_compound, which should do some parameter sanitization. Thanks for catching this. > And std_log() should be taught about these new controls. For compound > controls I would just log the type name, e.g. "H264_SPS" and not the > values of these compound controls. > I guess this makes some sense, if only for consistency. Is there any other reason to have this? The codec drivers are not implementing VIDIOC_LOG_STATUS. If we were to use v4l2_ctrl_log_status, we'd only get something like this: v4l2-ctrls: hantro-vpu 3830.video-codec: H264 Sequence Parameter Set: H264_SPS v4l2-ctrls: hantro-vpu 3830.video-codec: H264 Picture Parameter Set: H264_PPS ... v4l2-ctrls: hantro-vpu 3830.video-codec: H264 Decode Mode: Frame-Based v4l2-ctrls: hantro-vpu 3830.video-codec: H264 Start Code: Annex B Start Code v4l2-ctrls: hantro-vpu 3830.video-codec: H264 Profile: Main Also... Another thing I missed is here is driver destaging. I would really want to start getting the drivers out of staging as well. Can we have some VIDEO_V4L2_UNSTABLE_STATELESS option in media/staging, so we can use that in drivers? This way, we would not offer the staging controls and pixel formats unless the user explicitly enables that option. The core could also print a warning when the option is enabled, and controls are first created. So we'd move cedrus, hantro and rkvdec out of staging on this series as well, supporting H264 only, by default. Thanks! Ezequiel > Regards, > > Hans > > > Thanks, > > Ezequiel > > > > v2: > > * Split destage changes in several patches so it's easier to review. > > * Added missing changes to drivers/media/v4l2-core/v4l2-ctrls.c. > > * Renamed V4L2_CID_CODEC_CX2341X_ and V4L2_CID_MPEG_MFC51_ > > * Moved the compatibility macros for MPEG to the end of the header. > > > > Ezequiel Garcia (8): > > media: cedrus: h264: Support profile and level controls > > media: Rename stateful codec control macros > > media: Clean stateless control includes > > media: controls: Add the stateless codec control class > > media: uapi: Move parsed H264 pixel format out of staging > > media: uapi: Move the H264 stateless control types out of staging > > media: uapi: move H264 stateless controls out of staging > > media: docs: Move the H264 stateless codec uAPI > > > > Jonas Karlman (1): > > media: rkvdec: h264: Support profile and level controls > > > > .../userspace-api/media/v4l/common.rst| 1 + > > .../userspace-api/media/v4l/dev-mem2mem.rst | 2 +- > > .../media/v4l/ext-ctrls-codec-stateless.rst | 674 +++ > > .../media/v4l/ext-ctrls-codec.rst | 696 +--- > > .../media/v4l/extended-controls.rst | 8 +- > > .../media/v4l/pixfmt-compressed.rst | 14 +- > > .../media/v4l/vidioc-g-ext-ctrls.rst | 6 +- > > drivers/media/common/cx2341x.c| 4 +- > > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- > > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 2 +- > > drivers/media/v4l2-core/v4l2-ctrls.c | 45 +- > > drivers/staging/media/hantro/hantro_drv.c | 26 +- >
undefined reference to `start_isolate_page_range'
Hi Michal, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1 commit: 2602276d3d3811b1a48c48113042cd75fcbfc27d microblaze: Wire CMA allocator date: 10 months ago config: microblaze-randconfig-r022-20201115 (attached as .config) compiler: microblaze-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2602276d3d3811b1a48c48113042cd75fcbfc27d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 2602276d3d3811b1a48c48113042cd75fcbfc27d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=microblaze If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): microblaze-linux-ld: mm/page_alloc.o: in function `alloc_contig_range': >> (.text+0xbf44): undefined reference to `start_isolate_page_range' >> microblaze-linux-ld: (.text+0xbffc): undefined reference to >> `undo_isolate_page_range' >> microblaze-linux-ld: (.text+0xc15c): undefined reference to >> `test_pages_isolated' microblaze-linux-ld: (.text+0xc1cc): undefined reference to `undo_isolate_page_range' microblaze-linux-ld: (.text+0xc210): undefined reference to `undo_isolate_page_range' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH net v1] lan743x: fix issue causing intermittent kernel log warnings
On Sat, Nov 14, 2020 at 6:19 PM Jakub Kicinski wrote: > > The _irq() cases look a little strange, are you planning a refactor in > net-next? I'd like to, but I don't understand skbs/queues well enough (yet).
sun6i-msgbox.c:undefined reference to `devm_ioremap_resource'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1 commit: 25831c44b0b79ac6261d36d7e777a52bdf92f239 mailbox: sun6i-msgbox: Add a new mailbox driver date: 8 months ago config: s390-randconfig-r014-20201115 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=25831c44b0b79ac6261d36d7e777a52bdf92f239 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 25831c44b0b79ac6261d36d7e777a52bdf92f239 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): s390-linux-ld: renesas-soc.c:(.init.text+0xf4): undefined reference to `ioremap' s390-linux-ld: renesas-soc.c:(.init.text+0x108): undefined reference to `iounmap' s390-linux-ld: drivers/soc/renesas/rcar-sysc.o: in function `rcar_sysc_pd_init': rcar-sysc.c:(.init.text+0x7c): undefined reference to `of_iomap' s390-linux-ld: drivers/regulator/stm32-vrefbuf.o: in function `stm32_vrefbuf_probe': stm32-vrefbuf.c:(.text+0x290): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/regulator/stm32-pwr.o: in function `stm32_pwr_regulator_probe': stm32-pwr.c:(.text+0x250): undefined reference to `of_iomap' s390-linux-ld: drivers/regulator/uniphier-regulator.o: in function `uniphier_regulator_probe': uniphier-regulator.c:(.text+0xd0): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/reset/reset-ath79.o: in function `ath79_reset_probe': reset-ath79.c:(.text+0x8c): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-lpc18xx.o: in function `lpc18xx_rgu_probe': reset-lpc18xx.c:(.text+0x106): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-meson.o: in function `meson_reset_probe': reset-meson.c:(.text+0x86): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-meson-audio-arb.o: in function `meson_audio_arb_probe': reset-meson-audio-arb.c:(.text+0xd6): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-npcm.o: in function `npcm_rc_probe': reset-npcm.c:(.text+0x254): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/reset/reset-qcom-pdc.o: in function `qcom_pdc_reset_probe': reset-qcom-pdc.c:(.text+0x116): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-simple.o: in function `reset_simple_probe': reset-simple.c:(.text+0xa8): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-stm32mp1.o: in function `stm32_reset_probe': reset-stm32mp1.c:(.text+0x11a): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/reset/reset-sunxi.o: in function `sun6i_reset_init': reset-sunxi.c:(.init.text+0x6a): undefined reference to `of_address_to_resource' s390-linux-ld: reset-sunxi.c:(.init.text+0xb6): undefined reference to `ioremap' s390-linux-ld: drivers/reset/reset-uniphier-glue.o: in function `uniphier_glue_reset_probe': reset-uniphier-glue.c:(.text+0x11a): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/mfd/syscon.o: in function `syscon_probe': syscon.c:(.text+0x96): undefined reference to `devm_ioremap' s390-linux-ld: drivers/mfd/syscon.o: in function `of_syscon_register.isra.0': syscon.c:(.text+0x1a6): undefined reference to `of_address_to_resource' s390-linux-ld: syscon.c:(.text+0x1e6): undefined reference to `ioremap' s390-linux-ld: syscon.c:(.text+0x374): undefined reference to `iounmap' s390-linux-ld: drivers/mtd/nand/raw/mxic_nand.o: in function `mxic_nfc_probe': mxic_nand.c:(.text+0x1fc): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/mtd/nand/raw/stm32_fmc2_nand.o: in function `stm32_fmc2_probe': stm32_fmc2_nand.c:(.text+0x19ce): undefined reference to `devm_ioremap_resource' s390-linux-ld: stm32_fmc2_nand.c:(.text+0x1a3e): undefined reference to `devm_ioremap_resource' s390-linux-ld: stm32_fmc2_nand.c:(.text+0x1a88): undefined reference to `devm_ioremap_resource' s390-linux-ld: stm32_fmc2_nand.c:(.text+0x1ac6): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/mtd/nand/raw/meson_nand.o: in function `meson_nfc_probe': meson_nand.c:(.text+0x44e): undefined reference to `devm_ioremap_resource'
Re: [PATCH 0/2] Preserve goldfish rtc
On Sat, 14 Nov 2020 21:09:19 +0800, Jiaxun Yang wrote: > Cc: che...@lemote.com > Cc: gre...@linuxfoundation.org > > Jiaxun Yang (2): > rtc: goldfish: Remove GOLDFISH dependency > MAINTAINERS: Set myself as Goldfish RTC maintainer > > [...] Applied, thanks! [1/2] rtc: goldfish: Remove GOLDFISH dependency commit: 5022cfc112328e7fd489f5e3d41b7f352322880c [2/2] MAINTAINERS: Set myself as Goldfish RTC maintainer commit: 9844484eac2bff09ba3fcdebcf5a41d94df6b6c1 Best regards, -- Alexandre Belloni
[PATCH v2] counter: microchip-tcb-capture: Fix CMR value check
The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
for CMR. This patch fixes the action_get() callback to properly check
for these values rather than mask them.
Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Cc: Kamel Bouhara
Acked-by: Alexandre Belloni
Signed-off-by: William Breathitt Gray
---
drivers/counter/microchip-tcb-capture.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/counter/microchip-tcb-capture.c
b/drivers/counter/microchip-tcb-capture.c
index 039c54a78aa5..710acc0a3704 100644
--- a/drivers/counter/microchip-tcb-capture.c
+++ b/drivers/counter/microchip-tcb-capture.c
@@ -183,16 +183,20 @@ static int mchp_tc_count_action_get(struct counter_device
*counter,
regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), );
- *action = MCHP_TC_SYNAPSE_ACTION_NONE;
-
- if (cmr & ATMEL_TC_ETRGEDG_NONE)
+ switch (cmr & ATMEL_TC_ETRGEDG) {
+ default:
*action = MCHP_TC_SYNAPSE_ACTION_NONE;
- else if (cmr & ATMEL_TC_ETRGEDG_RISING)
+ break;
+ case ATMEL_TC_ETRGEDG_RISING:
*action = MCHP_TC_SYNAPSE_ACTION_RISING_EDGE;
- else if (cmr & ATMEL_TC_ETRGEDG_FALLING)
+ break;
+ case ATMEL_TC_ETRGEDG_FALLING:
*action = MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE;
- else if (cmr & ATMEL_TC_ETRGEDG_BOTH)
+ break;
+ case ATMEL_TC_ETRGEDG_BOTH:
*action = MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE;
+ break;
+ }
return 0;
}
--
2.29.2
Re: [PATCH net v1] lan743x: prevent entire kernel HANG on open, for some platforms
On Thu, 12 Nov 2020 15:47:41 -0500 Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck
>
> On arm imx6, when opening the chip's netdev, the whole Linux
> kernel intermittently hangs/freezes.
>
> This is caused by a bug in the driver code which tests if pcie
> interrupts are working correctly, using the software interrupt:
>
> 1. open: enable the software interrupt
> 2. open: tell the chip to assert the software interrupt
> 3. open: wait for flag
> 4. ISR: acknowledge s/w interrupt, set flag
> 5. open: notice flag, disable the s/w interrupt, continue
>
> Unfortunately the ISR only acknowledges the s/w interrupt, but
> does not disable it. This will re-trigger the ISR in a tight
> loop.
>
> On some (lucky) platforms, open proceeds to disable the s/w
> interrupt even while the ISR is 'spinning'. On arm imx6,
> the spinning ISR does not allow open to proceed, resulting
> in a hung Linux kernel.
>
> Fix minimally by disabling the s/w interrupt in the ISR, which
> will prevent it from spinning. This won't break anything because
> the s/w interrupt is used as a one-shot interrupt.
>
> Note that this is a minimal fix, overlooking many possible
> cleanups, e.g.:
> - lan743x_intr_software_isr() is completely redundant and reads
> INT_STS twice for no apparent reason
> - disabling the s/w interrupt in lan743x_intr_test_isr() is now
> redundant, but harmless
> - waiting on software_isr_flag can be converted from a sleeping
> poll loop to wait_event_timeout()
>
> Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
> Tested-by: Sven Van Asbroeck # arm imx6 lan7430
> Signed-off-by: Sven Van Asbroeck
Applied, thank you!
Re: [PATCH net v1] lan743x: fix issue causing intermittent kernel log warnings
On Thu, 12 Nov 2020 13:59:49 -0500 Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck
>
> When running this chip on arm imx6, we intermittently observe
> the following kernel warning in the log, especially when the
> system is under high load:
> The driver is calling dev_kfree_skb() from code inside a spinlock,
> where h/w interrupts are disabled. This is forbidden, as documented
> in include/linux/netdevice.h. The correct function to use
> dev_kfree_skb_irq(), or dev_kfree_skb_any().
>
> Fix by using the correct dev_kfree_skb_xxx() functions:
>
> in lan743x_tx_release_desc():
> called by lan743x_tx_release_completed_descriptors()
> called by in lan743x_tx_napi_poll()
> which holds a spinlock
> called by lan743x_tx_release_all_descriptors()
> called by lan743x_tx_close()
> which can-sleep
> conclusion: use dev_kfree_skb_any()
>
> in lan743x_tx_xmit_frame():
> which holds a spinlock
> conclusion: use dev_kfree_skb_irq()
>
> in lan743x_tx_close():
> which can-sleep
> conclusion: use dev_kfree_skb()
>
> in lan743x_rx_release_ring_element():
> called by lan743x_rx_close()
> which can-sleep
> called by lan743x_rx_open()
> which can-sleep
> conclusion: use dev_kfree_skb()
>
> Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
> Signed-off-by: Sven Van Asbroeck
Applied, thanks.
The _irq() cases look a little strange, are you planning a refactor in
net-next? Seems like the freeing can be moved outside the lock.
Also the driver could stop the queue when there is less than
MAX_SKB_FRAGS + 2 descriptors left, so it doesn't need the
"overflow_skb" thing.
RE: load_unaligned_zeropad() on x86-64
From: Linus Torvalds > Sent: 14 November 2020 18:02 > > On Sat, Nov 14, 2020 at 7:53 AM David Laight wrote: > > > > The change e419b4cc585680940bc42f8ca8a071d6023fb1bb added > > asm code for load_unaligned_zeropad(). > > > > However it doesn't look right for 64bit. > > It masks the address with ~3 not ~7 so the second > > access could still cross a page boundary and fault. > > Can you explain more what you think is wrong? > > It uses > > "and %3,%1\n\t" > > for the masking, but note how that's a "%3", not a "$3". Maybe I need to get better glasses. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v5 3/9] lib: zstd: Upgrade to latest upstream zstd version 1.4.6
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on kdave/for-next f2fs/dev-test linus/master v5.10-rc3
next-20201113]
[cannot apply to crypto/master squashfs/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nick-Terrell/lib-zstd-Add-zstd-compatibility-wrapper/20201103-150617
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: h8300-randconfig-r033-20201104 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/667e96565ce79ec24e0ced9ec4093e92647e4163
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Nick-Terrell/lib-zstd-Add-zstd-compatibility-wrapper/20201103-150617
git checkout 667e96565ce79ec24e0ced9ec4093e92647e4163
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
lib/zstd/compress/zstd_double_fast.c: In function
'ZSTD_compressBlock_doubleFast_extDict_generic':
>> lib/zstd/compress/zstd_double_fast.c:501:1: warning: the frame size of 1256
>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
501 | }
| ^
lib/zstd/compress/zstd_double_fast.c: In function
'ZSTD_compressBlock_doubleFast':
lib/zstd/compress/zstd_double_fast.c:336:1: warning: the frame size of 1224
bytes is larger than 1024 bytes [-Wframe-larger-than=]
336 | }
| ^
lib/zstd/compress/zstd_double_fast.c: In function
'ZSTD_compressBlock_doubleFast_dictMatchState':
lib/zstd/compress/zstd_double_fast.c:356:1: warning: the frame size of 1320
bytes is larger than 1024 bytes [-Wframe-larger-than=]
356 | }
| ^
--
lib/zstd/compress/zstd_fast.c: In function
'ZSTD_compressBlock_fast_extDict_generic':
>> lib/zstd/compress/zstd_fast.c:476:1: warning: the frame size of 1156 bytes
>> is larger than 1024 bytes [-Wframe-larger-than=]
476 | }
| ^
vim +501 lib/zstd/compress/zstd_double_fast.c
357
358
359 static size_t ZSTD_compressBlock_doubleFast_extDict_generic(
360 ZSTD_matchState_t* ms, seqStore_t* seqStore, U32
rep[ZSTD_REP_NUM],
361 void const* src, size_t srcSize,
362 U32 const mls /* template */)
363 {
364 ZSTD_compressionParameters const* cParams = >cParams;
365 U32* const hashLong = ms->hashTable;
366 U32 const hBitsL = cParams->hashLog;
367 U32* const hashSmall = ms->chainTable;
368 U32 const hBitsS = cParams->chainLog;
369 const BYTE* const istart = (const BYTE*)src;
370 const BYTE* ip = istart;
371 const BYTE* anchor = istart;
372 const BYTE* const iend = istart + srcSize;
373 const BYTE* const ilimit = iend - 8;
374 const BYTE* const base = ms->window.base;
375 const U32 endIndex = (U32)((size_t)(istart - base) + srcSize);
376 const U32 lowLimit = ZSTD_getLowestMatchIndex(ms, endIndex,
cParams->windowLog);
377 const U32 dictStartIndex = lowLimit;
378 const U32 dictLimit = ms->window.dictLimit;
379 const U32 prefixStartIndex = (dictLimit > lowLimit) ? dictLimit :
lowLimit;
380 const BYTE* const prefixStart = base + prefixStartIndex;
381 const BYTE* const dictBase = ms->window.dictBase;
382 const BYTE* const dictStart = dictBase + dictStartIndex;
383 const BYTE* const dictEnd = dictBase + prefixStartIndex;
384 U32 offset_1=rep[0], offset_2=rep[1];
385
386 DEBUGLOG(5, "ZSTD_compressBlock_doubleFast_extDict_generic
(srcSize=%zu)", srcSize);
387
388 /* if extDict is invalidated due to maxDistance, switch to
"regular" variant */
389 if (prefixStartIndex == dictStartIndex)
390 return ZSTD_compressBlock_doubleFast_generic(ms, seqStore, rep,
src, srcSize, mls, ZSTD_noDict);
391
392 /* Search Loop */
393 while (ip < ilimit) { /* < instead of <=, because (ip+1) */
394 const size_t hSmall = ZSTD_hashPtr(ip, hBitsS, mls);
395 const U32 matchIndex = hashSmall[hSmall];
396 const BYTE* const matchBase = matchIndex < prefixStartIndex ?
dictBase : base;
397 const BYTE* match = matchBase + matchIndex;
398
399 const size_t hLong = ZSTD_hashPtr(ip, hBitsL, 8);
400
drivers/usb/musb/musbhsdma.c:324:8: warning: variable 'devctl' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
commit: 0990366bab3c6afb93b276106e1e24d4bc69db7b usb: musb: Add support for
MediaTek musb controller
date: 10 months ago
config: microblaze-randconfig-r001-20201115 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0990366bab3c6afb93b276106e1e24d4bc69db7b
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 0990366bab3c6afb93b276106e1e24d4bc69db7b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=microblaze
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/usb/musb/musbhsdma.c: In function 'dma_controller_irq':
>> drivers/usb/musb/musbhsdma.c:324:8: warning: variable 'devctl' set but not
>> used [-Wunused-but-set-variable]
324 | u8 devctl;
|^~
vim +/devctl +324 drivers/usb/musb/musbhsdma.c
550a7375fe7209 Felipe Balbi2008-07-24 265
edce61776c7e21 Min Guo 2020-01-15 266 irqreturn_t
dma_controller_irq(int irq, void *private_data)
550a7375fe7209 Felipe Balbi2008-07-24 267 {
458e6a511f9dc9 Felipe Balbi2008-09-11 268 struct
musb_dma_controller *controller = private_data;
458e6a511f9dc9 Felipe Balbi2008-09-11 269 struct musb *musb =
controller->private_data;
458e6a511f9dc9 Felipe Balbi2008-09-11 270 struct musb_dma_channel
*musb_channel;
458e6a511f9dc9 Felipe Balbi2008-09-11 271 struct dma_channel
*channel;
458e6a511f9dc9 Felipe Balbi2008-09-11 272
458e6a511f9dc9 Felipe Balbi2008-09-11 273 void __iomem *mbase =
controller->base;
458e6a511f9dc9 Felipe Balbi2008-09-11 274
550a7375fe7209 Felipe Balbi2008-07-24 275 irqreturn_t retval =
IRQ_NONE;
458e6a511f9dc9 Felipe Balbi2008-09-11 276
550a7375fe7209 Felipe Balbi2008-07-24 277 unsigned long flags;
550a7375fe7209 Felipe Balbi2008-07-24 278
458e6a511f9dc9 Felipe Balbi2008-09-11 279 u8 bchannel;
458e6a511f9dc9 Felipe Balbi2008-09-11 280 u8 int_hsdma;
458e6a511f9dc9 Felipe Balbi2008-09-11 281
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 282 u32 addr, count;
458e6a511f9dc9 Felipe Balbi2008-09-11 283 u16 csr;
458e6a511f9dc9 Felipe Balbi2008-09-11 284
550a7375fe7209 Felipe Balbi2008-07-24 285
spin_lock_irqsave(>lock, flags);
550a7375fe7209 Felipe Balbi2008-07-24 286
9c93d7fd464e7a Min Guo 2020-01-15 287 int_hsdma =
musb_clearb(mbase, MUSB_HSDMA_INTR);
550a7375fe7209 Felipe Balbi2008-07-24 288
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 289 if (!int_hsdma) {
b99d3659b309b3 Bin Liu 2016-06-30 290 musb_dbg(musb,
"spurious DMA irq");
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 291
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 292 for (bchannel =
0; bchannel < MUSB_HSDMA_CHANNELS; bchannel++) {
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 293
musb_channel = (struct musb_dma_channel *)
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 294
&(controller->channel[bchannel]);
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 295 channel
= _channel->channel;
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 296 if
(channel->status == MUSB_DMA_STATUS_BUSY) {
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 297
count = musb_read_hsdma_count(mbase, bchannel);
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 298
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 299
if (count == 0)
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 300
int_hsdma |= (1 << bchannel);
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 301 }
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 302 }
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 303
b99d3659b309b3 Bin Liu 2016-06-30 304 musb_dbg(musb,
"int_hsdma = 0x%x", int_hsdma);
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 305
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 306 if (!int_hsdma)
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 307 goto
done;
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 308 }
f933a0c0fe0ea5 Anand Gadiyar 2009-12-28 309
Re: [PATCH AUTOSEL 4.19 18/21] kprobes: Tell lockdep about kprobe nesting
On Tue, Nov 10, 2020 at 03:44:58PM +0900, Masami Hiramatsu wrote:
Hi,
On Mon, 9 Nov 2020 22:55:38 -0500
Sasha Levin wrote:
From: "Steven Rostedt (VMware)"
[ Upstream commit 645f224e7ba2f4200bf163153d384ceb0de5462e ]
Since the kprobe handlers have protection that prohibits other handlers from
executing in other contexts (like if an NMI comes in while processing a
kprobe, and executes the same kprobe, it will get fail with a "busy"
return). Lockdep is unaware of this protection. Use lockdep's nesting api to
differentiate between locks taken in INT3 context and other context to
suppress the false warnings.
Link:
https://lore.kernel.org/r/20201102160234.fa0ae70915ad9e2b21c08...@kernel.org
This fixes a lockdep false positive warning comes from commit e03b4a084ea6
("kprobes: Remove NMI context check"). Does anyone report that happen on the
stable kernel?
If not, you do not need this patch for stable kernels.
I'll drop it, thanks!
--
Thanks,
Sasha
Re: [PATCH] counter: microchip-tcb-capture: Fix CMR value check
On Sat, Nov 14, 2020 at 11:51:13PM +0100, Alexandre Belloni wrote:
> On 14/11/2020 23:48:28+0100, Alexandre Belloni wrote:
> > On 11/11/2020 11:38:07-0500, William Breathitt Gray wrote:
> > > The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
> > > for CMR. This patch fixes the action_get() callback to properly check
> > > for these values rather than mask them.
> > >
> > > Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
> > > Cc: Kamel Bouhara
> > > Signed-off-by: William Breathitt Gray
> > Acked-by: Alexandre Belloni
> >
> > > ---
> > > drivers/counter/microchip-tcb-capture.c | 16 ++--
> > > 1 file changed, 10 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/counter/microchip-tcb-capture.c
> > > b/drivers/counter/microchip-tcb-capture.c
> > > index 039c54a78aa5..142b389fc9db 100644
> > > --- a/drivers/counter/microchip-tcb-capture.c
> > > +++ b/drivers/counter/microchip-tcb-capture.c
> > > @@ -183,16 +183,20 @@ static int mchp_tc_count_action_get(struct
> > > counter_device *counter,
> > >
> > > regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), );
> > >
> > > - *action = MCHP_TC_SYNAPSE_ACTION_NONE;
> > > -
> > > - if (cmr & ATMEL_TC_ETRGEDG_NONE)
> > > + switch (cmr & ATMEL_TC_ETRGEDG_BOTH) {
>
> BTW, this could be simply ATMEL_TC_ETRGEDG which is the mask.
You're right, let me resubmit this patch with that change since it'll be
much clearer.
By the way, microchip-tcb-capture.c is missing a MAINTAINERS entry. Is
Kamel the maintainer of this driver? I'd like to get a proper entry
added so we have a point of contact in case of future bugs and changes.
Thanks,
William Breathitt Gray
signature.asc
Description: PGP signature
Re: [PATCH] rtc: snvs: Remove NULL pointer check before clk_*
On Fri, 13 Nov 2020 08:03:05 +, Xu Wang wrote: > Because clk_* already checked NULL clock parameter, > so the additional checks are unnecessary, just remove them. Applied, thanks! [1/1] rtc: snvs: Remove NULL pointer check before clk_* commit: 081e2500df50c7f330b9346794c6759ea7f8fb81 Best regards, -- Alexandre Belloni
Re: [PATCH] counter: microchip-tcb-capture: Fix CMR value check
On 14/11/2020 23:48:28+0100, Alexandre Belloni wrote:
> On 11/11/2020 11:38:07-0500, William Breathitt Gray wrote:
> > The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
> > for CMR. This patch fixes the action_get() callback to properly check
> > for these values rather than mask them.
> >
> > Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
> > Cc: Kamel Bouhara
> > Signed-off-by: William Breathitt Gray
> Acked-by: Alexandre Belloni
>
> > ---
> > drivers/counter/microchip-tcb-capture.c | 16 ++--
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/counter/microchip-tcb-capture.c
> > b/drivers/counter/microchip-tcb-capture.c
> > index 039c54a78aa5..142b389fc9db 100644
> > --- a/drivers/counter/microchip-tcb-capture.c
> > +++ b/drivers/counter/microchip-tcb-capture.c
> > @@ -183,16 +183,20 @@ static int mchp_tc_count_action_get(struct
> > counter_device *counter,
> >
> > regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), );
> >
> > - *action = MCHP_TC_SYNAPSE_ACTION_NONE;
> > -
> > - if (cmr & ATMEL_TC_ETRGEDG_NONE)
> > + switch (cmr & ATMEL_TC_ETRGEDG_BOTH) {
BTW, this could be simply ATMEL_TC_ETRGEDG which is the mask.
> > + default:
> > *action = MCHP_TC_SYNAPSE_ACTION_NONE;
> > - else if (cmr & ATMEL_TC_ETRGEDG_RISING)
> > + break;
> > + case ATMEL_TC_ETRGEDG_RISING:
> > *action = MCHP_TC_SYNAPSE_ACTION_RISING_EDGE;
> > - else if (cmr & ATMEL_TC_ETRGEDG_FALLING)
> > + break;
> > + case ATMEL_TC_ETRGEDG_FALLING:
> > *action = MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE;
> > - else if (cmr & ATMEL_TC_ETRGEDG_BOTH)
> > + break;
> > + case ATMEL_TC_ETRGEDG_BOTH:
> > *action = MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE;
> > + break;
> > + }
> >
> > return 0;
> > }
> > --
> > 2.29.2
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH] rtc: brcmstb-waketimer: Remove redundant null check before clk_disable_unprepare
On Fri, 13 Nov 2020 07:45:38 +, Xu Wang wrote: > Because clk_disable_unprepare() already checked NULL clock parameter, > so the additional check is unnecessary, just remove it. Applied, thanks! [1/1] rtc: brcmstb-waketimer: Remove redundant null check before clk_disable_unprepare commit: 910d002d84df21da61cadba92dd510ece5e46312 Best regards, -- Alexandre Belloni
Re: [PATCH] counter: microchip-tcb-capture: Fix CMR value check
On 11/11/2020 11:38:07-0500, William Breathitt Gray wrote:
> The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
> for CMR. This patch fixes the action_get() callback to properly check
> for these values rather than mask them.
>
> Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
> Cc: Kamel Bouhara
> Signed-off-by: William Breathitt Gray
Acked-by: Alexandre Belloni
> ---
> drivers/counter/microchip-tcb-capture.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/counter/microchip-tcb-capture.c
> b/drivers/counter/microchip-tcb-capture.c
> index 039c54a78aa5..142b389fc9db 100644
> --- a/drivers/counter/microchip-tcb-capture.c
> +++ b/drivers/counter/microchip-tcb-capture.c
> @@ -183,16 +183,20 @@ static int mchp_tc_count_action_get(struct
> counter_device *counter,
>
> regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], CMR), );
>
> - *action = MCHP_TC_SYNAPSE_ACTION_NONE;
> -
> - if (cmr & ATMEL_TC_ETRGEDG_NONE)
> + switch (cmr & ATMEL_TC_ETRGEDG_BOTH) {
> + default:
> *action = MCHP_TC_SYNAPSE_ACTION_NONE;
> - else if (cmr & ATMEL_TC_ETRGEDG_RISING)
> + break;
> + case ATMEL_TC_ETRGEDG_RISING:
> *action = MCHP_TC_SYNAPSE_ACTION_RISING_EDGE;
> - else if (cmr & ATMEL_TC_ETRGEDG_FALLING)
> + break;
> + case ATMEL_TC_ETRGEDG_FALLING:
> *action = MCHP_TC_SYNAPSE_ACTION_FALLING_EDGE;
> - else if (cmr & ATMEL_TC_ETRGEDG_BOTH)
> + break;
> + case ATMEL_TC_ETRGEDG_BOTH:
> *action = MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE;
> + break;
> + }
>
> return 0;
> }
> --
> 2.29.2
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH] rtc: cpcap: Fix missing IRQF_ONESHOT as only threaded handler
On Tue, 10 Nov 2020 17:35:47 +0800, Tian Tao wrote: > Coccinelle noticed: > drivers/rtc/rtc-cpcap.c:271:7-32: ERROR: Threaded IRQ with no > primary handler requested without IRQF_ONESHOT > drivers/rtc/rtc-cpcap.c:287:7-32: ERROR: Threaded IRQ with no > primary handler requested without IRQF_ONESHOT Applied, thanks! [1/1] rtc: cpcap: Fix missing IRQF_ONESHOT as only threaded handler commit: bc06cfc1c41e3b60b159132e5bba4c059a2e7f83 Best regards, -- Alexandre Belloni
Re: [PATCH v2] rtc: hym8563: enable wakeup when applicable
On Fri, 6 Nov 2020 09:06:31 +, Guillaume Tucker wrote: > Enable wakeup in the hym8563 driver if the IRQ was successfully > requested or if wakeup-source is set in the devicetree. > > As per the description of device_init_wakeup(), it should be enabled > for "devices that everyone expects to be wakeup sources". One would > expect this to be the case with a real-time clock. > > [...] Applied, thanks! [1/1] rtc: hym8563: enable wakeup when applicable commit: c56ac7a0f468ceb38d24db41f4446d98ab94da2d Best regards, -- Alexandre Belloni
genirq/irqdomain: Make irq_domain_disassociate() static
No users outside of the core code.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdomain.h |2 --
kernel/irq/irqdomain.c|2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -387,8 +387,6 @@ extern int irq_domain_associate(struct i
extern void irq_domain_associate_many(struct irq_domain *domain,
unsigned int irq_base,
irq_hw_number_t hwirq_base, int count);
-extern void irq_domain_disassociate(struct irq_domain *domain,
- unsigned int irq);
extern unsigned int irq_create_mapping(struct irq_domain *host,
irq_hw_number_t hwirq);
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -496,7 +496,7 @@ static void irq_domain_set_mapping(struc
}
}
-void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
+static void irq_domain_disassociate(struct irq_domain *domain, unsigned int
irq)
{
struct irq_data *irq_data = irq_get_irq_data(irq);
irq_hw_number_t hwirq;
Re: [PATCH RFC v1 1/4] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
On Sat, Nov 14, 2020 at 09:01:01PM +0100, Martin Blumenstingl wrote:
> Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX
> delay register which allows picoseconds precision. Deprecate the old
> "amlogic,rx-delay-ns" in favour of a new "amlogic,rgmii-rx-delay-ps"
> property.
>
> For older SoCs the only known supported values were 0ns and 2ns. The new
> SoCs have 200ps precision and support RGMII RX delays between 0ps and
> 3000ps.
>
> Signed-off-by: Martin Blumenstingl
> ---
> .../bindings/net/amlogic,meson-dwmac.yaml | 52 ++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> index 6b057b117aa0..bafde1194193 100644
> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> @@ -74,18 +74,68 @@ allOf:
> Any configuration is ignored when the phy-mode is set to "rmii".
>
> amlogic,rx-delay-ns:
> + deprecated: true
>enum:
> - 0
> - 2
>default: 0
> + description:
> +The internal RGMII RX clock delay in nanoseconds. Deprecated, use
> +amlogic,rgmii-rx-delay-ps instead.
> +
> +amlogic,rgmii-rx-delay-ps:
> + default: 0
>description:
> The internal RGMII RX clock delay (provided by this IP block) in
> -nanoseconds. When phy-mode is set to "rgmii" then the RX delay
> +picoseconds. When phy-mode is set to "rgmii" then the RX delay
> should be explicitly configured. When the phy-mode is set to
> either "rgmii-id" or "rgmii-rxid" the RX clock delay is already
> provided by the PHY. Any configuration is ignored when the
> phy-mode is set to "rmii".
Hi Martin
I don't think the wording matches what the driver is actually doing:
if (dwmac->rx_delay_ns == 2)
rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
else
rx_dly_config = 0;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
delay_config = tx_dly_config | rx_dly_config;
break;
case PHY_INTERFACE_MODE_RGMII_RXID:
delay_config = tx_dly_config;
break;
case PHY_INTERFACE_MODE_RGMII_TXID:
delay_config = rx_dly_config;
break;
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RMII:
delay_config = 0;
break;
So rx_delay is used for both rgmii and rgmii-txid. The binding says
nothing about rgmii-txid.
And while i'm looking at the code, i wonder about this:
if (rx_dly_config & PRG_ETH0_ADJ_ENABLE) {
if (!dwmac->timing_adj_clk) {
dev_err(dwmac->dev,
"The timing-adjustment clock is mandatory for
the RX delay re-timing\n");
return -EINVAL;
}
/* The timing adjustment logic is driven by a separate clock */
ret = meson8b_devm_clk_prepare_enable(dwmac,
dwmac->timing_adj_clk);
if (ret) {
dev_err(dwmac->dev,
"Failed to enable the timing-adjustment
clock\n");
return ret;
}
}
It looks like it can be that rx_dly_config & PRG_ETH0_ADJ_ENABLE is
true, so the clock is enabled, but delay_config does not contain
rx_delay_config, so it is pointless turning it on.
Andrew
Re: [PATCH] rtc: sc27xx: Remove unnecessary conversion to bool
On Fri, 6 Nov 2020 15:30:54 +0800, xiakaixu1...@gmail.com wrote: > Here we could use the '!=' expression to fix the following coccicheck > warning: > > ./drivers/rtc/rtc-sc27xx.c:566:50-55: WARNING: conversion to bool not needed > here Applied, thanks! [1/1] rtc: sc27xx: Remove unnecessary conversion to bool commit: 825156a5eeded9bcb55e9c36d4b4b72bf20bcba6 Best regards, -- Alexandre Belloni
Re: [PATCH] rtc: da9063: Simplify bool comparison
On Fri, 6 Nov 2020 16:00:37 +0800, xiakaixu1...@gmail.com wrote: > Fix the following coccicheck warning: > > ./drivers/rtc/rtc-da9063.c:246:5-18: WARNING: Comparison to bool Applied, thanks! [1/1] rtc: da9063: Simplify bool comparison commit: a48c6224ae07bed02893c58073ca2942acb5c3d5 Best regards, -- Alexandre Belloni
pl353-smc.c:undefined reference to `amba_driver_register'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1 commit: ea0c0ad6b6eb36726088991d97a55b99cae456d0 memory: Enable compile testing for most of the drivers date: 3 months ago config: arm-randconfig-p002-20201115 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea0c0ad6b6eb36726088991d97a55b99cae456d0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout ea0c0ad6b6eb36726088991d97a55b99cae456d0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arm-linux-gnueabi-ld: drivers/memory/pl353-smc.o: in function `pl353_smc_driver_init': >> pl353-smc.c:(.init.text+0x10): undefined reference to `amba_driver_register' arm-linux-gnueabi-ld: drivers/memory/pl353-smc.o: in function `pl353_smc_driver_exit': >> pl353-smc.c:(.exit.text+0x10): undefined reference to >> `amba_driver_unregister' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] rtc: Fix memleak in sun6i_rtc_clk_init
Hi, Thank you for the patch. On 14/11/2020 12:18:21+0800, Youling Tang wrote: > When rtc->base or rtc->int_osc or rtc->losc or rtc->ext_losc is NULL, > we should free clk_data and rtc before the function returns to prevent > memleak. > I think this is fixed by 28d211919e422f58c1e6c900e5810eee4f1ce4c8 in my branch: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/commit/?id=28d211919e422f58c1e6c900e5810eee4f1ce4c8 -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH][V2] PCI: Fix a potential uninitentional integer overflow issue
On 14/11/2020 21:53, Bjorn Helgaas wrote:
> [+cc Dan]
>
> On Tue, Nov 10, 2020 at 10:10:48PM +, Colin King wrote:
>> From: Colin Ian King
>>
>> The shift of 1 by align_order is evaluated using 32 bit arithmetic
>> and the result is assigned to a resource_size_t type variable that
>> is a 64 bit unsigned integer on 64 bit platforms. Fix an overflow
>> before widening issue by making the 1 a ULL.
>>
>> Addresses-Coverity: ("Unintentional integer overflow")
>> Fixes: 07d8d7e57c28 ("PCI: Make specifying PCI devices in kernel parameters
>> reusable")
>> Signed-off-by: Colin Ian King
>
> Applied to pci/misc for v5.11 with Logan's Reviewed-by and also the
> Fixes: correction.
>
> I first applied the patch below to bounds-check the alignment as noted
> by Dan.
>
>> ---
>>
>> V2: Use ULL instead of BIT_ULL(), fix spelling mistake and capitalize first
>> word of patch subject.
>>
>> ---
>> drivers/pci/pci.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 3ef63a101fa1..248044a7ef8c 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -6214,7 +6214,7 @@ static resource_size_t
>> pci_specified_resource_alignment(struct pci_dev *dev,
>> if (align_order == -1)
>> align = PAGE_SIZE;
>> else
>> -align = 1 << align_order;
>> +align = 1ULL << align_order;
>> break;
>> } else if (ret < 0) {
>> pr_err("PCI: Can't parse resource_alignment parameter:
>> %s\n",
>
> commit d6ca242c448f ("PCI: Bounds-check command-line resource alignment
> requests")
> Author: Bjorn Helgaas
> Date: Thu Nov 5 14:51:36 2020 -0600
>
> PCI: Bounds-check command-line resource alignment requests
>
> 32-bit BARs are limited to 2GB size (2^31). By extension, I assume 64-bit
> BARs are limited to 2^63 bytes. Limit the alignment requested by the
> "pci=resource_alignment=" command-line parameter to 2^63.
>
> Link: https://lore.kernel.org/r/20201007123045.GS4282@kadam
> Reported-by: Dan Carpenter
> Signed-off-by: Bjorn Helgaas
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8b9bea8ba751..26c1b2d0bacd 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -6197,19 +6197,21 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> while (*p) {
> count = 0;
> if (sscanf(p, "%d%n", _order, ) == 1 &&
> - p[count] == '@') {
> + p[count] == '@') {
> p += count + 1;
> + if (align_order > 63) {
> + pr_err("PCI: Invalid requested alignment (order
> %d)\n",
> +align_order);
> + align_order = PAGE_SHIFT;
> + }
> } else {
> - align_order = -1;
> + align_order = PAGE_SHIFT;
> }
>
> ret = pci_dev_str_match(dev, p, );
> if (ret == 1) {
> *resize = true;
> - if (align_order == -1)
> - align = PAGE_SIZE;
> - else
> - align = 1 << align_order;
> + align = 1 << align_order;
> break;
> } else if (ret < 0) {
> pr_err("PCI: Can't parse resource_alignment parameter:
> %s\n",
>
Thanks.
Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH
Hi Hancai, do you know if CONFIG_GOLDFISH_AUDIO is required for MIPS? I sent a patch to retire it. Regards, Roman. On Sat, Nov 14, 2020 at 12:06 AM 陈华才 wrote: > > Hi, All, > > Goldfish RTC works well on MIPS, and QEMU RISC-V emulator use Goldfish as > well, so I think we should keep it in kernel. > > Huacai > > > -- Original -- > From: "Greg KH"; > Date: Sat, Nov 14, 2020 07:43 AM > To: "Roman Kiryanov"; > Cc: "chenhc"; "Paul Walmsley"; > "LKML"; "Lingfeng Yang"; "Rob > Herring"; > Subject: Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH > > > > On Fri, Nov 13, 2020 at 03:36:49PM -0800, Roman Kiryanov wrote: > > +Greg KH > > > > On Fri, Nov 13, 2020 at 2:02 PM Roman Kiryanov wrote: > > > > > > Hi Hancai, > > > > > > I see you added /arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts > > > which > > > refers to goldfish-rtc in 39c1485c8baa47aa20caefc1ec0a3410fbad6c81. > > > We (Android Studio Emulator aka "goldfish") do not support MIPS anymore. > > > Do you know if goldfish-rtc still works and is assumed to be available? > > I've dropped this patch from my trees now, please feel free to resend > when you have an updated version. > > thanks, > > greg k-h
Re: Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH
> > Thus I do think it shouldn't be retired as for now. If nobody comes in I'd > > also willing to maintain > > it. > > Ok, can someone submit a patch to update the MAINTAINERS file for this > so we know who to route issues to over time? I will send a patch to update MAINTAINERS for goldfish-rtc.
RF: SUPPORT FOR COVID-19 VICTIMS
Hello! A donation of $1,750,000 USD has been made to you by Mr Francois Pinault to support the victims of COVID-19 around you. Kindly reply this email for further information.As I wait for your response, I wish you a wonderful day. Yours Faithfully, Mr. Francois Pinault
Re: [PATCH][V2] PCI: Fix a potential uninitentional integer overflow issue
[+cc Dan]
On Tue, Nov 10, 2020 at 10:10:48PM +, Colin King wrote:
> From: Colin Ian King
>
> The shift of 1 by align_order is evaluated using 32 bit arithmetic
> and the result is assigned to a resource_size_t type variable that
> is a 64 bit unsigned integer on 64 bit platforms. Fix an overflow
> before widening issue by making the 1 a ULL.
>
> Addresses-Coverity: ("Unintentional integer overflow")
> Fixes: 07d8d7e57c28 ("PCI: Make specifying PCI devices in kernel parameters
> reusable")
> Signed-off-by: Colin Ian King
Applied to pci/misc for v5.11 with Logan's Reviewed-by and also the
Fixes: correction.
I first applied the patch below to bounds-check the alignment as noted
by Dan.
> ---
>
> V2: Use ULL instead of BIT_ULL(), fix spelling mistake and capitalize first
> word of patch subject.
>
> ---
> drivers/pci/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 3ef63a101fa1..248044a7ef8c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -6214,7 +6214,7 @@ static resource_size_t
> pci_specified_resource_alignment(struct pci_dev *dev,
> if (align_order == -1)
> align = PAGE_SIZE;
> else
> - align = 1 << align_order;
> + align = 1ULL << align_order;
> break;
> } else if (ret < 0) {
> pr_err("PCI: Can't parse resource_alignment parameter:
> %s\n",
commit d6ca242c448f ("PCI: Bounds-check command-line resource alignment
requests")
Author: Bjorn Helgaas
Date: Thu Nov 5 14:51:36 2020 -0600
PCI: Bounds-check command-line resource alignment requests
32-bit BARs are limited to 2GB size (2^31). By extension, I assume 64-bit
BARs are limited to 2^63 bytes. Limit the alignment requested by the
"pci=resource_alignment=" command-line parameter to 2^63.
Link: https://lore.kernel.org/r/20201007123045.GS4282@kadam
Reported-by: Dan Carpenter
Signed-off-by: Bjorn Helgaas
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8b9bea8ba751..26c1b2d0bacd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6197,19 +6197,21 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
while (*p) {
count = 0;
if (sscanf(p, "%d%n", _order, ) == 1 &&
- p[count] == '@') {
+ p[count] == '@') {
p += count + 1;
+ if (align_order > 63) {
+ pr_err("PCI: Invalid requested alignment (order
%d)\n",
+ align_order);
+ align_order = PAGE_SHIFT;
+ }
} else {
- align_order = -1;
+ align_order = PAGE_SHIFT;
}
ret = pci_dev_str_match(dev, p, );
if (ret == 1) {
*resize = true;
- if (align_order == -1)
- align = PAGE_SIZE;
- else
- align = 1 << align_order;
+ align = 1 << align_order;
break;
} else if (ret < 0) {
pr_err("PCI: Can't parse resource_alignment parameter:
%s\n",
[tip: irq/core] genirq: Remove GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
The following commit has been merged into the irq/core branch of tip:
Commit-ID: f296dcd629aa412a80a53215e46087f53af87f08
Gitweb:
https://git.kernel.org/tip/f296dcd629aa412a80a53215e46087f53af87f08
Author:Thomas Gleixner
AuthorDate:Sat, 14 Nov 2020 22:01:45 +01:00
Committer: Thomas Gleixner
CommitterDate: Sat, 14 Nov 2020 22:39:00 +01:00
genirq: Remove GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
Commit bb9d812643d8 ("arch: remove tile port") removed the last user of
this cruft two years ago...
Signed-off-by: Thomas Gleixner
Link: https://lore.kernel.org/r/87eekvac06@nanos.tec.linutronix.de
---
include/linux/irq.h | 15 +-
kernel/irq/Kconfig | 5 +
kernel/irq/irqdesc.c | 51 +---
3 files changed, 71 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index c543653..79ce314 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -954,21 +954,6 @@ static inline void irq_free_desc(unsigned int irq)
irq_free_descs(irq, 1);
}
-#ifdef CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
-unsigned int irq_alloc_hwirqs(int cnt, int node);
-static inline unsigned int irq_alloc_hwirq(int node)
-{
- return irq_alloc_hwirqs(1, node);
-}
-void irq_free_hwirqs(unsigned int from, int cnt);
-static inline void irq_free_hwirq(unsigned int irq)
-{
- return irq_free_hwirqs(irq, 1);
-}
-int arch_setup_hwirq(unsigned int irq, int node);
-void arch_teardown_hwirq(unsigned int irq);
-#endif
-
#ifdef CONFIG_GENERIC_IRQ_LEGACY
void irq_init_desc(unsigned int irq);
#endif
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 10a5aff..f2cda6b 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -26,11 +26,6 @@ config GENERIC_IRQ_SHOW_LEVEL
config GENERIC_IRQ_EFFECTIVE_AFF_MASK
bool
-# Facility to allocate a hardware interrupt. This is legacy support
-# and should not be used in new code. Use irq domains instead.
-config GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
- bool
-
# Support for delayed migration from interrupt context
config GENERIC_PENDING_IRQ
bool
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 1a77236..e810eb9 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -810,57 +810,6 @@ unlock:
}
EXPORT_SYMBOL_GPL(__irq_alloc_descs);
-#ifdef CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
-/**
- * irq_alloc_hwirqs - Allocate an irq descriptor and initialize the hardware
- * @cnt: number of interrupts to allocate
- * @node: node on which to allocate
- *
- * Returns an interrupt number > 0 or 0, if the allocation fails.
- */
-unsigned int irq_alloc_hwirqs(int cnt, int node)
-{
- int i, irq = __irq_alloc_descs(-1, 0, cnt, node, NULL, NULL);
-
- if (irq < 0)
- return 0;
-
- for (i = irq; cnt > 0; i++, cnt--) {
- if (arch_setup_hwirq(i, node))
- goto err;
- irq_clear_status_flags(i, _IRQ_NOREQUEST);
- }
- return irq;
-
-err:
- for (i--; i >= irq; i--) {
- irq_set_status_flags(i, _IRQ_NOREQUEST | _IRQ_NOPROBE);
- arch_teardown_hwirq(i);
- }
- irq_free_descs(irq, cnt);
- return 0;
-}
-EXPORT_SYMBOL_GPL(irq_alloc_hwirqs);
-
-/**
- * irq_free_hwirqs - Free irq descriptor and cleanup the hardware
- * @from: Free from irq number
- * @cnt: number of interrupts to free
- *
- */
-void irq_free_hwirqs(unsigned int from, int cnt)
-{
- int i, j;
-
- for (i = from, j = cnt; j > 0; i++, j--) {
- irq_set_status_flags(i, _IRQ_NOREQUEST | _IRQ_NOPROBE);
- arch_teardown_hwirq(i);
- }
- irq_free_descs(from, cnt);
-}
-EXPORT_SYMBOL_GPL(irq_free_hwirqs);
-#endif
-
/**
* irq_get_next_irq - get next allocated irq number
* @offset:where to start the search
Re: [PATCH 1/6] seq_file: add seq_read_iter
On Fri, Nov 13, 2020 at 04:54:53PM -0700, Nathan Chancellor wrote:
> Hi Al,
>
> On Wed, Nov 11, 2020 at 10:21:16PM +, Al Viro wrote:
> > On Wed, Nov 11, 2020 at 09:52:20PM +, Al Viro wrote:
> >
> > > That can be done, but I would rather go with
> > > n = copy_to_iter(m->buf + m->from, m->count, iter);
> > > m->count -= n;
> > > m->from += n;
> > > copied += n;
> > > if (!size)
> > > goto Done;
> > > if (m->count)
> > > goto Efault;
> > > if we do it that way. Let me see if I can cook something
> > > reasonable along those lines...
> >
> > Something like below (build-tested only):
> >
> > diff --git a/fs/seq_file.c b/fs/seq_file.c
> > index 3b20e21604e7..07b33c1f34a9 100644
> > --- a/fs/seq_file.c
> > +++ b/fs/seq_file.c
> > @@ -168,7 +168,6 @@ EXPORT_SYMBOL(seq_read);
> > ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
> > {
> > struct seq_file *m = iocb->ki_filp->private_data;
> > - size_t size = iov_iter_count(iter);
> > size_t copied = 0;
> > size_t n;
> > void *p;
> > @@ -208,14 +207,11 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct
> > iov_iter *iter)
> > }
> > /* if not empty - flush it first */
> > if (m->count) {
> > - n = min(m->count, size);
> > - if (copy_to_iter(m->buf + m->from, n, iter) != n)
> > - goto Efault;
> > + n = copy_to_iter(m->buf + m->from, m->count, iter);
> > m->count -= n;
> > m->from += n;
> > - size -= n;
> > copied += n;
> > - if (!size)
> > + if (!iov_iter_count(iter) || m->count)
> > goto Done;
> > }
> > /* we need at least one record in buffer */
> > @@ -249,6 +245,7 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct
> > iov_iter *iter)
> > goto Done;
> > Fill:
> > /* they want more? let's try to get some more */
> > + /* m->count is positive and there's space left in iter */
> > while (1) {
> > size_t offs = m->count;
> > loff_t pos = m->index;
> > @@ -263,7 +260,7 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct
> > iov_iter *iter)
> > err = PTR_ERR(p);
> > break;
> > }
> > - if (m->count >= size)
> > + if (m->count >= iov_iter_count(iter))
> > break;
> > err = m->op->show(m, p);
> > if (seq_has_overflowed(m) || err) {
> > @@ -273,16 +270,14 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct
> > iov_iter *iter)
> > }
> > }
> > m->op->stop(m, p);
> > - n = min(m->count, size);
> > - if (copy_to_iter(m->buf, n, iter) != n)
> > - goto Efault;
> > + n = copy_to_iter(m->buf, m->count, iter);
> > copied += n;
> > m->count -= n;
> > m->from = n;
> > Done:
> > - if (!copied)
> > - copied = err;
> > - else {
> > + if (unlikely(!copied)) {
> > + copied = m->count ? -EFAULT : err;
> > + } else {
> > iocb->ki_pos += copied;
> > m->read_pos += copied;
> > }
> > @@ -291,9 +286,6 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct
> > iov_iter *iter)
> > Enomem:
> > err = -ENOMEM;
> > goto Done;
> > -Efault:
> > - err = -EFAULT;
> > - goto Done;
> > }
> > EXPORT_SYMBOL(seq_read_iter);
> >
>
> This patch in -next (6a9f696d1627bacc91d1cebcfb177f474484e8ba) breaks
> WSL2's interoperability feature, where Windows paths automatically get
> added to PATH on start up so that Windows binaries can be accessed from
> within Linux (such as clip.exe to pipe output to the clipboard). Before,
> I would see a bunch of Linux + Windows folders in $PATH but after, I
> only see the Linux folders (I can give you the actual PATH value if you
> care but it is really long).
>
> I am not at all familiar with the semantics of this patch or how
> Microsoft would be using it to inject folders into PATH (they have some
> documentation on it here:
> https://docs.microsoft.com/en-us/windows/wsl/interop) and I am not sure
> how to go about figuring that out to see why this patch breaks something
> (unless you have an idea). I have added the Hyper-V maintainers and list
> to CC in case they know someone who could help.
FWIW, just to make sure:
1) does reverting just that commit recover the desired behaviour?
2) could you verify that your latest tests had been done with
the incremental I'd posted (shifting the if () goto Done; out of the if
body)?
3) does the build with that commit reverted produce any warnings
related to mountinfo?
4) your posted log with WARN_ON unfortunately starts *after*
the mountinfo accesses; could you check which process had been doing those?
The Comm: ... part in there, that is.
5) in the "I don't believe that could happen, but let's make sure"
[GIT PULL] percpu fix for v5.10-rc4
Hi Linus, A fix for a Wshadow warning in asm-generic percpu macros came in and then I tacked on the removal of flexible array initializers in the percpu allocator which was discussed in the 5.9 pull request. Thanks, Dennis The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu.git for-5.10-fixes for you to fetch changes up to 61cf93d3e14a29288e4d5522aecb6e58268eec62: percpu: convert flexible array initializers to use struct_size() (2020-10-30 23:02:28 +) Arnd Bergmann (1): asm-generic: percpu: avoid Wshadow warning Dennis Zhou (1): percpu: convert flexible array initializers to use struct_size() include/asm-generic/percpu.h | 18 +- mm/percpu.c | 8 2 files changed, 13 insertions(+), 13 deletions(-)
Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks
[+cc Rafael for question about ACPI method for PCI host bridge reset] On Sat, Nov 14, 2020 at 09:58:08PM +0100, Thomas Gleixner wrote: > On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote: > > On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote: > >> On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote: > >> > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote: > >> >> pci_device_shutdown() still clears the Bus Master Enable bit if we're > >> >> doing a kexec and the device is in D0-D3hot, which should also disable > >> >> MSI/MSI-X. Why doesn't this solve the problem? Is this because the > >> >> device causing the storm was in PCI_UNKNOWN state? > >> > > >> > That's indeed a really good question. > >> > >> So we do that on kexec, but is that true when starting a kdump kernel > >> from a kernel crash? I doubt it. > > > > Ah, right, I bet that's it, thanks. The kdump path is basically this: > > > > crash_kexec > > machine_kexec > > > > while the usual kexec path is: > > > > kernel_kexec > > kernel_restart_prepare > > device_shutdown > > while (!list_empty(_kset->list)) > > dev->bus->shutdown > > pci_device_shutdown# pci_bus_type.shutdown > > machine_kexec > > > > So maybe we need to explore doing some or all of device_shutdown() in > > the crash_kexec() path as well as in the kernel_kexec() path. > > The problem is that if the machine crashed anything you try to attempt > before starting the crash kernel is reducing the chance that the crash > kernel actually starts. Right. > Is there something at the root bridge level which allows to tell the > underlying busses to shut up, reset or go into a defined state? That > might avoid chasing lists which might be already unreliable. Maybe we need some kind of crash_device_shutdown() that does the minimal thing to protect the kdump kernel from devices. The programming model for conventional PCI host bridges and PCIe Root Complexes is device-specific since they're outside the PCI domain. There probably *are* ways to do those things, but you would need a native host bridge driver or something like an ACPI method. I'm not aware of an ACPI way to do this, but I added Rafael in case he is. A crash_device_shutdown() could do something at the host bridge level if that's possible, or reset/disable bus mastering/disable MSI/etc on individual PCI devices if necessary. Bjorn
Re: Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR
On Sat, Nov 14, 2020 at 4:14 PM Richard Cochran
wrote:
>
> On Fri, Nov 13, 2020 at 05:21:43PM +0100, Arnd Bergmann wrote:
> > I've prototyped a patch that I think makes this more sensible
> > again: https://pastebin.com/AQ5nWS9e
>
> I like the behavior described in the text.
>
> Instead of this ...
>
> - if a built-in driver calls PTP interface functions but fails
>to select HAVE_PTP_1588_CLOCK or depend on PTP_1588_CLOCK,
>and PTP support is a loadable module, we get a link error
>instead of having an unusable clock.
>
> how about simply deleting the #else clause of
>
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -173,7 +173,7 @@ struct ptp_clock_event {
> };
> };
>
> -#if IS_REACHABLE(CONFIG_PTP_1588_CLOCK)
> +#if IS_ENABLED(CONFIG_PTP_1588_CLOCK)
>
> so that invalid configurations throw a compile time error instead?
I was trying to still allow PTP clocks to be disabled, either when
building a kernel that doesn't need it, or when posix timers are
disabled. Leaving out the #else path would break all drivers that
have PTP support in the main ethernet driver file rather than
conditionally compiling it based on a Kconfig symbol that depends
on CONFIG_PTP_1588_CLOCK.
Arnd
Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
On Sat, Nov 14, 2020 at 10:34:30AM +, Christoph Hellwig wrote:
> On Thu, Nov 12, 2020 at 11:42:46PM +0100, Thomas Gleixner wrote:
> > DMI vendor name is pretty good final check when the bit is 0. The
> > strings I'm aware of are:
> >
> > QEMU, Bochs, KVM, Xen, VMware, VMW, VMware Inc., innotek GmbH, Oracle
> > Corporation, Parallels, BHYVE, Microsoft Corporation
> >
> > which is not complete but better than nothing ;)
>
> Which is why I really think we need explicit opt-ins for "native"
> SIOV handling and for paravirtualized SIOV handling, with the kernel
> not offering support at all without either or a manual override on
> the command line.
opt-in by device or kernel? The way we are planning to support this is:
Device support for IMS - Can discover in device specific means
Kernel support for IMS. - Supported by IOMMU driver.
each driver can check
if (dev_supports_ims() && iommu_supports_ims()) {
/* Then IMS is supported in the platform.*/
}
until we have vIOMMU support or a hypercall, iommu_supports_ims() will
check if X86_FEATURE_HYPERVISOR in addition to the platform id's Thomas
mentioned. or on intel platform check for cap.caching_mode=1 and return false.
When we add support for getting a native interrupt handle then we will plumb
that
appropriately.
Does this match what you wanted?
Re: [PATCH v1] clk: tegra30: Use 300MHz for video decoder by default
Quoting Dmitry Osipenko (2020-11-04 05:48:10)
> The 600MHz is a too high clock rate for some SoC versions for the video
> decoder hardware and this may cause stability issues. Use 300MHz for the
> video decoder by default, which is supported by all hardware versions.
>
> Fixes: ed1a2459e20c ("clk: tegra: Add Tegra20/30 EMC clock implementation")
> Signed-off-by: Dmitry Osipenko
> ---
Should this go to clk-fixes? Thierry?
Re: [PATCH v4 06/11] clk: at91: clk-sam9x60-pll: allow runtime changes for pll
Quoting Claudiu Beznea (2020-11-06 01:46:23)
> diff --git a/drivers/clk/at91/clk-sam9x60-pll.c
> b/drivers/clk/at91/clk-sam9x60-pll.c
> index 78f458a7b2ef..6fe5d8530a0c 100644
> --- a/drivers/clk/at91/clk-sam9x60-pll.c
> +++ b/drivers/clk/at91/clk-sam9x60-pll.c
> @@ -225,8 +225,51 @@ static int sam9x60_frac_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> unsigned long parent_rate)
> {
> struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
> + struct sam9x60_frac *frac = to_sam9x60_frac(core);
> + struct regmap *regmap = core->regmap;
> + unsigned long irqflags, clkflags = clk_hw_get_flags(hw);
> + unsigned int val, cfrac, cmul;
> + long ret;
> +
> + ret = sam9x60_frac_pll_compute_mul_frac(core, rate, parent_rate,
> true);
> + if (ret <= 0 || (clkflags & CLK_SET_RATE_GATE))
Is this function being called when the clk is enabled and it has the
CLK_SET_RATE_GATE flag set? I'm confused why this driver needs to check
this flag.
> + return ret;
> +
> + spin_lock_irqsave(core->lock, irqflags);
> +
> + regmap_update_bits(regmap, AT91_PMC_PLL_UPDT,
> AT91_PMC_PLL_UPDT_ID_MSK,
> + core->id);
> + regmap_read(regmap, AT91_PMC_PLL_CTRL1, );
> + cmul = (val & core->layout->mul_mask) >> core->layout->mul_shift;
> + cfrac = (val & core->layout->frac_mask) >> core->layout->frac_shift;
> +
> + if (cmul == frac->mul && cfrac == frac->frac)
> + goto unlock;
> +
> + regmap_write(regmap, AT91_PMC_PLL_CTRL1,
> +(frac->mul << core->layout->mul_shift) |
> +(frac->frac << core->layout->frac_shift));
> +
> + regmap_update_bits(regmap, AT91_PMC_PLL_UPDT,
> + AT91_PMC_PLL_UPDT_UPDATE |
> AT91_PMC_PLL_UPDT_ID_MSK,
> + AT91_PMC_PLL_UPDT_UPDATE | core->id);
> +
> + regmap_update_bits(regmap, AT91_PMC_PLL_CTRL0,
> + AT91_PMC_PLL_CTRL0_ENLOCK |
> AT91_PMC_PLL_CTRL0_ENPLL,
> + AT91_PMC_PLL_CTRL0_ENLOCK |
> + AT91_PMC_PLL_CTRL0_ENPLL);
> +
> + regmap_update_bits(regmap, AT91_PMC_PLL_UPDT,
> + AT91_PMC_PLL_UPDT_UPDATE |
> AT91_PMC_PLL_UPDT_ID_MSK,
> + AT91_PMC_PLL_UPDT_UPDATE | core->id);
>
> - return sam9x60_frac_pll_compute_mul_frac(core, rate, parent_rate,
> true);
> + while (!sam9x60_pll_ready(regmap, core->id))
> + cpu_relax();
> +
> +unlock:
> + spin_unlock_irqrestore(core->lock, irqflags);
> +
> + return ret;
> }
>
> static const struct clk_ops sam9x60_frac_pll_ops = {
> @@ -378,9 +421,39 @@ static int sam9x60_div_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> {
> struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
> struct sam9x60_div *div = to_sam9x60_div(core);
> + struct regmap *regmap = core->regmap;
> + unsigned long irqflags, clkflags = clk_hw_get_flags(hw);
> + unsigned int val, cdiv;
>
> div->div = DIV_ROUND_CLOSEST(parent_rate, rate) - 1;
>
> + if (clkflags & CLK_SET_RATE_GATE)
Same comment.
> diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
> index d685e22b2014..33faf7c6d9fb 100644
> --- a/drivers/clk/at91/sama7g5.c
> +++ b/drivers/clk/at91/sama7g5.c
> @@ -95,15 +95,15 @@ static const struct clk_pll_layout pll_layout_divio = {
> * @p: clock parent
> * @l: clock layout
> * @t: clock type
> - * @f: true if clock is critical and cannot be disabled
> + * @f: clock flags
> * @eid: export index in sama7g5->chws[] array
> */
> static const struct {
> const char *n;
> const char *p;
> const struct clk_pll_layout *l;
> + u32 f;
Why not unsigned long?
> u8 t;
> - u8 c;
> u8 eid;
> } sama7g5_plls[][PLL_ID_MAX] = {
> [PLL_ID_CPU] = {
> @@ -111,13 +111,13 @@ static const struct {
> .p = "mainck",
> .l = _layout_frac,
> .t = PLL_TYPE_FRAC,
> - .c = 1, },
> + .f = CLK_IS_CRITICAL, },
>
> { .n = "cpupll_divpmcck",
> .p = "cpupll_fracck",
> .l = _layout_divpmc,
> .t = PLL_TYPE_DIV,
> - .c = 1,
> + .f = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT,
> .eid = PMC_CPUPLL, },
> },
>
> @@ -126,13 +126,13 @@ static const struct {
> .p = "mainck",
> .l = _layout_frac,
> .t = PLL_TYPE_FRAC,
> - .c = 1, },
> + .f = CLK_IS_CRITICAL | CLK_SET_RATE_GATE, },
>
> { .n = "syspll_divpmcck",
> .p = "syspll_fracck",
> .l =
Re: [PATCH v2 5/5] clk: qcom: dispcc-sm8250: handle MMCX power domain
Quoting Dmitry Baryshkov (2020-10-23 06:19:25) > On SM8250 MMCX power domain is required to access MMDS_GDSC registers. > This power domain is expressed as mmcx-supply regulator property. Use > this regulator as MDSS_GDSC supply. > > Signed-off-by: Dmitry Baryshkov > --- Applied to clk-next
Re: [PATCH] perf test: Fix dwarf unwind for optimized builds.
On Fri, Nov 13, 2020 at 04:08:03PM -0800, Ian Rogers wrote:
> To ensure the stack frames are on the stack tail calls optimizations
> need to be inhibited. If your compiler supports an attribute use it,
> otherwise use an asm volatile barrier.
>
> The barrier fix was suggested here:
> https://lore.kernel.org/lkml/20201028081123.gt2...@hirez.programming.kicks-ass.net/
>
> Fixes: 9ae1e990f1ab ("perf tools: Remove broken __no_tail_call
>attribute")
missing SOB
LGTM and test is passing for me ;-)
Tested-by: Jiri Olsa
jirka
> ---
> tools/perf/tests/dwarf-unwind.c | 39 +++--
> 1 file changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
> index 83638097c3bc..c8ce86bceea8 100644
> --- a/tools/perf/tests/dwarf-unwind.c
> +++ b/tools/perf/tests/dwarf-unwind.c
> @@ -24,6 +24,23 @@
> /* For bsearch. We try to unwind functions in shared object. */
> #include
>
> +/*
> + * The test will assert frames are on the stack but tail call optimizations
> lose
> + * the frame of the caller. Clang can disable this optimization on a called
> + * function but GCC currently (11/2020) lacks this attribute. The barrier is
> + * used to inhibit tail calls in these cases.
> + */
> +#ifdef __has_attribute
> +#if __has_attribute(disable_tail_calls)
> +#define NO_TAIL_CALL_ATTRIBUTE __attribute__((disable_tail_calls))
> +#define NO_TAIL_CALL_BARRIER
> +#endif
> +#endif
> +#ifndef NO_TAIL_CALL_ATTRIBUTE
> +#define NO_TAIL_CALL_ATTRIBUTE
> +#define NO_TAIL_CALL_BARRIER __asm__ __volatile__("" : : : "memory");
> +#endif
> +
> static int mmap_handler(struct perf_tool *tool __maybe_unused,
> union perf_event *event,
> struct perf_sample *sample,
> @@ -95,7 +112,7 @@ static int unwind_entry(struct unwind_entry *entry, void
> *arg)
> return strcmp((const char *) symbol, funcs[idx]);
> }
>
> -noinline int test_dwarf_unwind__thread(struct thread *thread)
> +NO_TAIL_CALL_ATTRIBUTE noinline int test_dwarf_unwind__thread(struct thread
> *thread)
> {
> struct perf_sample sample;
> unsigned long cnt = 0;
> @@ -126,7 +143,7 @@ noinline int test_dwarf_unwind__thread(struct thread
> *thread)
>
> static int global_unwind_retval = -INT_MAX;
>
> -noinline int test_dwarf_unwind__compare(void *p1, void *p2)
> +NO_TAIL_CALL_ATTRIBUTE noinline int test_dwarf_unwind__compare(void *p1,
> void *p2)
> {
> /* Any possible value should be 'thread' */
> struct thread *thread = *(struct thread **)p1;
> @@ -145,7 +162,7 @@ noinline int test_dwarf_unwind__compare(void *p1, void
> *p2)
> return p1 - p2;
> }
>
> -noinline int test_dwarf_unwind__krava_3(struct thread *thread)
> +NO_TAIL_CALL_ATTRIBUTE noinline int test_dwarf_unwind__krava_3(struct thread
> *thread)
> {
> struct thread *array[2] = {thread, thread};
> void *fp =
> @@ -164,14 +181,22 @@ noinline int test_dwarf_unwind__krava_3(struct thread
> *thread)
> return global_unwind_retval;
> }
>
> -noinline int test_dwarf_unwind__krava_2(struct thread *thread)
> +NO_TAIL_CALL_ATTRIBUTE noinline int test_dwarf_unwind__krava_2(struct thread
> *thread)
> {
> - return test_dwarf_unwind__krava_3(thread);
> + int ret;
> +
> + ret = test_dwarf_unwind__krava_3(thread);
> + NO_TAIL_CALL_BARRIER;
> + return ret;
> }
>
> -noinline int test_dwarf_unwind__krava_1(struct thread *thread)
> +NO_TAIL_CALL_ATTRIBUTE noinline int test_dwarf_unwind__krava_1(struct thread
> *thread)
> {
> - return test_dwarf_unwind__krava_2(thread);
> + int ret;
> +
> + ret = test_dwarf_unwind__krava_2(thread);
> + NO_TAIL_CALL_BARRIER;
> + return ret;
> }
>
> int test__dwarf_unwind(struct test *test __maybe_unused, int subtest
> __maybe_unused)
> --
> 2.29.2.299.gdc1121823c-goog
>
genirq: Remove GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
Commit bb9d812643d8 ("arch: remove tile port") removed the last user of
this cruft two years ago...
Signed-off-by: Thomas Gleixner
---
include/linux/irq.h | 15 ---
kernel/irq/Kconfig |5 -
kernel/irq/irqdesc.c | 51 ---
3 files changed, 71 deletions(-)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -954,21 +954,6 @@ static inline void irq_free_desc(unsigne
irq_free_descs(irq, 1);
}
-#ifdef CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
-unsigned int irq_alloc_hwirqs(int cnt, int node);
-static inline unsigned int irq_alloc_hwirq(int node)
-{
- return irq_alloc_hwirqs(1, node);
-}
-void irq_free_hwirqs(unsigned int from, int cnt);
-static inline void irq_free_hwirq(unsigned int irq)
-{
- return irq_free_hwirqs(irq, 1);
-}
-int arch_setup_hwirq(unsigned int irq, int node);
-void arch_teardown_hwirq(unsigned int irq);
-#endif
-
#ifdef CONFIG_GENERIC_IRQ_LEGACY
void irq_init_desc(unsigned int irq);
#endif
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -26,11 +26,6 @@ config GENERIC_IRQ_SHOW_LEVEL
config GENERIC_IRQ_EFFECTIVE_AFF_MASK
bool
-# Facility to allocate a hardware interrupt. This is legacy support
-# and should not be used in new code. Use irq domains instead.
-config GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
- bool
-
# Support for delayed migration from interrupt context
config GENERIC_PENDING_IRQ
bool
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -810,57 +810,6 @@ int __ref
}
EXPORT_SYMBOL_GPL(__irq_alloc_descs);
-#ifdef CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
-/**
- * irq_alloc_hwirqs - Allocate an irq descriptor and initialize the hardware
- * @cnt: number of interrupts to allocate
- * @node: node on which to allocate
- *
- * Returns an interrupt number > 0 or 0, if the allocation fails.
- */
-unsigned int irq_alloc_hwirqs(int cnt, int node)
-{
- int i, irq = __irq_alloc_descs(-1, 0, cnt, node, NULL, NULL);
-
- if (irq < 0)
- return 0;
-
- for (i = irq; cnt > 0; i++, cnt--) {
- if (arch_setup_hwirq(i, node))
- goto err;
- irq_clear_status_flags(i, _IRQ_NOREQUEST);
- }
- return irq;
-
-err:
- for (i--; i >= irq; i--) {
- irq_set_status_flags(i, _IRQ_NOREQUEST | _IRQ_NOPROBE);
- arch_teardown_hwirq(i);
- }
- irq_free_descs(irq, cnt);
- return 0;
-}
-EXPORT_SYMBOL_GPL(irq_alloc_hwirqs);
-
-/**
- * irq_free_hwirqs - Free irq descriptor and cleanup the hardware
- * @from: Free from irq number
- * @cnt: number of interrupts to free
- *
- */
-void irq_free_hwirqs(unsigned int from, int cnt)
-{
- int i, j;
-
- for (i = from, j = cnt; j > 0; i++, j--) {
- irq_set_status_flags(i, _IRQ_NOREQUEST | _IRQ_NOPROBE);
- arch_teardown_hwirq(i);
- }
- irq_free_descs(from, cnt);
-}
-EXPORT_SYMBOL_GPL(irq_free_hwirqs);
-#endif
-
/**
* irq_get_next_irq - get next allocated irq number
* @offset:where to start the search
Re: [PATCH 0/2] clk: add devm variant of clk_notifier_register
Quoting Jerome Brunet (2020-10-21 09:38:45) > This patchset adds memory managed variant of clk_notifier_register and > a first usage of it the amlogic clock controller of the g12 SoC family. > > Jerome Brunet (2): > clk: add devm variant of clk_notifier_register I'm not sure if we want to document these in the devres document? Documentation/driver-api/driver-model/devres.rst It would be nice if that thing could auto-generate the list of devres APIs somehow.
Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks
Bjorn, On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote: > On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote: >> On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote: >> > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote: >> >> pci_device_shutdown() still clears the Bus Master Enable bit if we're >> >> doing a kexec and the device is in D0-D3hot, which should also disable >> >> MSI/MSI-X. Why doesn't this solve the problem? Is this because the >> >> device causing the storm was in PCI_UNKNOWN state? >> > >> > That's indeed a really good question. >> >> So we do that on kexec, but is that true when starting a kdump kernel >> from a kernel crash? I doubt it. > > Ah, right, I bet that's it, thanks. The kdump path is basically this: > > crash_kexec > machine_kexec > > while the usual kexec path is: > > kernel_kexec > kernel_restart_prepare > device_shutdown > while (!list_empty(_kset->list)) > dev->bus->shutdown > pci_device_shutdown# pci_bus_type.shutdown > machine_kexec > > So maybe we need to explore doing some or all of device_shutdown() in > the crash_kexec() path as well as in the kernel_kexec() path. The problem is that if the machine crashed anything you try to attempt before starting the crash kernel is reducing the chance that the crash kernel actually starts. Is there something at the root bridge level which allows to tell the underlying busses to shut up, reset or go into a defined state? That might avoid chasing lists which might be already unreliable. Thanks, tglx
Re: [PATCH 2/2] clk: meson: g12: use devm variant to register notifiers
Quoting Jerome Brunet (2020-10-21 09:38:47) > Until now, nothing was done to unregister the dvfs clock notifiers of the > Amlogic g12 SoC family. This is not great but this driver was not really > expected to be unloaded. With the ongoing effort to build everything as > module for this platform, this needs to be cleanly handled. > > Signed-off-by: Jerome Brunet > --- Applied to clk-next
Re: [PATCH 1/2] clk: add devm variant of clk_notifier_register
Quoting Jerome Brunet (2020-10-21 09:38:46) > Add a memory managed variant of clk_notifier_register() to make life easier > on clock consumers using notifiers > > Signed-off-by: Jerome Brunet > --- Applied to clk-next
v5.10-rc3 vs. Droid 4
Hi! Does anyone have Droid 4 working with 5.10-rc3? I tried it with the original config; I got message about culomb counter calibration done scrolling (and boot progressing very slowly or not at all) . So ... I disabled cpcap battery & charger support. But init still drops me to emergency shell. I may try some more, but if someone know what is going on, let me know. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: PGP signature
Re: [PATCH RFC v1 1/1] scsi: pm: Leave runtime resume along if block layer PM is enabled
On 11/12/20 10:30 PM, Can Guo wrote:
> If block layer runtime PM is enabled for one SCSI device, then there is
> no need to forcibly change the SCSI device and its request queue's runtime
> PM status to active in scsi_dev_type_resume(), since block layer PM shall
> resume the SCSI device on the demand of bios.
Please change "along" into "alone" in the subject of this patch (if that
is what you meant).
> + if (scsi_is_sdev_device(dev)) {
> + struct scsi_device *sdev;
>
> + sdev = to_scsi_device(dev);
A minor comment: I think that "struct scsi_device *sdev =
to_scsi_device(dev);" fits on a single line.
> + * If block layer runtime PM is enabled for the SCSI device,
> + * let block layer PM handle its runtime PM routines.
Please change "its runtime PM routines" into "runtime resume" or
similar. I think that will make the comment more clear.
> + if (sdev->request_queue->dev)
> + return err;
> + }
The 'dev' member only exists in struct request_queue if CONFIG_PM=y so
the above won't compile if CONFIG_PM=n. How about adding a function in
include/linux/blk-pm.h to check whether or not runtime PM has been enabled?
Otherwise this patch looks good to me.
Thanks,
Bart.
Re: [PATCH v2 2/3] clk: add api to get clk consumer from clk_hw
Quoting Jerome Brunet (2020-10-21 09:21:46) > clk_register() is deprecated. Using 'clk' member of struct clk_hw is > discouraged. With this constraint, it is difficult for driver to > register clocks using the clk_hw API and then use the clock with > the consumer API > > This adds a simple helper, clk_hw_get_clk(), to get a struct clk from > a struct clk_hw. Like other clk_get() variant, each call to this helper > must be balanced with a call to clk_put(). To make life easier on the > consumers, a memory managed version is provided as well. > > Cc: Martin Blumenstingl > Signed-off-by: Jerome Brunet > --- Applied to clk-next
Re: [PATCH v2 1/3] clk: avoid devm_clk_release name clash
Quoting Jerome Brunet (2020-10-21 09:21:45) > In clk-devres.c, devm_clk_release() is used to call clk_put() memory > managed clock. In clk.c the same name, in a different scope is used to call > clk_unregister(). > > As it stands, it is not really a problem but it does not readability, > especially if we need to call clk_put() on managed clock in clk.c > > Signed-off-by: Jerome Brunet > --- Applied to clk-next
Re: [PATCH v2 3/3] clk: meson: g12: drop use of __clk_lookup()
Quoting Jerome Brunet (2020-10-21 09:21:47) > g12 clock controller used __clk_lookup() to get struct clk from a > struct clk_hw. This type of hack is no longer required as CCF now provides > the necessary functions to get this. > > Signed-off-by: Jerome Brunet > --- Applied to clk-next
Re: [PATCH v2] perf data: Allow to use stdio functions for pipe mode
On Fri, Oct 30, 2020 at 02:47:42PM +0900, Namhyung Kim wrote:
> When perf data is in a pipe, it reads each event separately using
> read(2) syscall. This is a huge performance bottleneck when
> processing large data like in perf inject. Also perf inject needs to
> use write(2) syscall for the output.
>
> So convert it to use buffer I/O functions in stdio library for pipe
> data. This makes inject-build-id bench time drops from 20ms to 8ms.
>
> $ perf bench internals inject-build-id
> # Running 'internals/inject-build-id' benchmark:
> Average build-id injection took: 8.074 msec (+- 0.013 msec)
> Average time per event: 0.792 usec (+- 0.001 usec)
> Average memory usage: 8328 KB (+- 0 KB)
> Average build-id-all injection took: 5.490 msec (+- 0.008 msec)
> Average time per event: 0.538 usec (+- 0.001 usec)
> Average memory usage: 7563 KB (+- 0 KB)
>
> This patch enables it just for perf inject when used with pipe (it's a
> default behavior). Maybe we could do it for perf record and/or report
> later..
>
> Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> v2: check result of fdopen()
>
> tools/perf/builtin-inject.c | 2 ++
> tools/perf/util/data.c | 41 ++---
> tools/perf/util/data.h | 11 +-
> tools/perf/util/header.c| 8
> tools/perf/util/session.c | 7 ---
> 5 files changed, 58 insertions(+), 11 deletions(-)
>
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 452a75fe68e5..14d6c88fed76 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -853,10 +853,12 @@ int cmd_inject(int argc, const char **argv)
> .output = {
> .path = "-",
> .mode = PERF_DATA_MODE_WRITE,
> + .use_stdio = true,
> },
> };
> struct perf_data data = {
> .mode = PERF_DATA_MODE_READ,
> + .use_stdio = true,
> };
> int ret;
>
> diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
> index c47aa34fdc0a..05bbcb663c41 100644
> --- a/tools/perf/util/data.c
> +++ b/tools/perf/util/data.c
> @@ -174,8 +174,21 @@ static bool check_pipe(struct perf_data *data)
> is_pipe = true;
> }
>
> - if (is_pipe)
> - data->file.fd = fd;
> + if (is_pipe) {
> + if (data->use_stdio) {
> + const char *mode;
> +
> + mode = perf_data__is_read(data) ? "r" : "w";
> + data->file.fptr = fdopen(fd, mode);
> +
> + if (data->file.fptr == NULL) {
> + data->file.fd = fd;
> + data->use_stdio = false;
> + }
> + } else {
> + data->file.fd = fd;
> + }
> + }
>
> return data->is_pipe = is_pipe;
> }
> @@ -334,6 +347,9 @@ int perf_data__open(struct perf_data *data)
> if (check_pipe(data))
> return 0;
>
> + /* currently it allows stdio for pipe only */
> + data->use_stdio = false;
> +
> if (!data->path)
> data->path = "perf.data";
>
> @@ -353,7 +369,21 @@ void perf_data__close(struct perf_data *data)
> perf_data__close_dir(data);
>
> zfree(>file.path);
> - close(data->file.fd);
> +
> + if (data->use_stdio)
> + fclose(data->file.fptr);
> + else
> + close(data->file.fd);
> +}
> +
> +ssize_t perf_data__read(struct perf_data *data, void *buf, size_t size)
> +{
> + if (data->use_stdio) {
> + if (fread(buf, size, 1, data->file.fptr) == 1)
> + return size;
> + return feof(data->file.fptr) ? 0 : -1;
> + }
> + return readn(data->file.fd, buf, size);
> }
>
> ssize_t perf_data_file__write(struct perf_data_file *file,
> @@ -365,6 +395,11 @@ ssize_t perf_data_file__write(struct perf_data_file
> *file,
> ssize_t perf_data__write(struct perf_data *data,
> void *buf, size_t size)
> {
> + if (data->use_stdio) {
> + if (fwrite(buf, size, 1, data->file.fptr) == 1)
> + return size;
> + return -1;
> + }
> return perf_data_file__write(>file, buf, size);
> }
>
> diff --git a/tools/perf/util/data.h b/tools/perf/util/data.h
> index 75947ef6bc17..c563fcbb0288 100644
> --- a/tools/perf/util/data.h
> +++ b/tools/perf/util/data.h
> @@ -2,6 +2,7 @@
> #ifndef __PERF_DATA_H
> #define __PERF_DATA_H
>
> +#include
> #include
>
> enum perf_data_mode {
> @@ -16,7 +17,10 @@ enum perf_dir_version {
>
> struct perf_data_file {
> char*path;
> - int fd;
> + union {
> + int fd;
> + FILE*fptr;
> + };
> unsigned longsize;
> };
>
> @@ -26,6 +30,7 @@ struct
Re: [PATCH 1/6] seq_file: add seq_read_iter
On Sat, Nov 14, 2020 at 07:00:25AM +, Al Viro wrote:
> On Fri, Nov 13, 2020 at 11:19:34PM -0700, Nathan Chancellor wrote:
>
> > Assuming so, I have attached the output both with and without the
> > WARN_ON. Looks like mountinfo is what is causing the error?
>
> Cute... FWIW, on #origin + that commit with fix folded in I don't
> see anything unusual in reads from mountinfo ;-/ OTOH, they'd
> obviously been... creative with readv(2) arguments, so it would
> be very interesting to see what it is they are passing to it.
>
> I'm half-asleep right now; will try to cook something to gather
> that information tomorrow morning. 'Later...
OK, so let's do this: fix in seq_read_iter() + in do_loop_readv_writev()
(on entry) the following (racy as hell, but will do for debugging):
bool weird = false;
if (unlikely(memcmp(file->f_path.dentry->d_name.name, "mountinfo",
10))) {
int i;
for (i = 0; i < iter->nr_segs; i++)
if (!iter->iov[i].iov_len)
weird = true;
if (weird) {
printk(KERN_ERR "[%s]: weird readv on %p4D (%ld) ",
current->comm, filp, (long)filp->f_pos);
for (i = 0; i < iter->nr_segs; i++)
printk(KERN_CONT "%c%zd", i ? ':' : '<',
iter->iov[i].iov_len);
printk(KERN_CONT "> ");
}
}
and in the end (just before return)
if (weird)
printk(KERN_CONT "-> %zd\n", ret);
Preferably along with the results of cat /proc//mountinfo both
on that and on the working kernel...
Re: [GIT PULL] SCSI fixes for 5.10-rc3
The pull request you sent on Fri, 13 Nov 2020 16:20:13 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0c0451112b629946c93ed2102b7ae47d4d1dc0bc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SELinux fixes for v5.10 (#1)
The pull request you sent on Fri, 13 Nov 2020 18:29:23 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git > tags/selinux-pr-20201113 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/30636a59f4c1a40720156079cabcad60351949f2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] hwmon fixes for v5.10-rc4
The pull request you sent on Fri, 13 Nov 2020 17:51:11 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > hwmon-for-v5.10-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7e908b7461ec395293335852485a183c16765303 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] clk fixes for v5.10-rc3
The pull request you sent on Sat, 14 Nov 2020 11:39:34 -0800: > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > tags/clk-fixes-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/31908a604ced3c047022c2cc9f178d3287f06dfe Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] um fixes for 5.10-rc4
The pull request you sent on Fri, 13 Nov 2020 23:20:04 +0100 (CET): > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git > tags/for-linus-5.10-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4aea779d35120d5062647d288817678decb28c10 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [RESEND PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On Sat, Nov 14, 2020 at 12:10 PM Jonathan Marek wrote:
>
> On 11/14/20 2:39 PM, Rob Clark wrote:
> > On Sat, Nov 14, 2020 at 10:58 AM Jonathan Marek wrote:
> >>
> >> On 11/14/20 1:46 PM, Rob Clark wrote:
> >>> On Sat, Nov 14, 2020 at 8:24 AM Christoph Hellwig wrote:
>
> On Sat, Nov 14, 2020 at 10:17:12AM -0500, Jonathan Marek wrote:
> > +void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
> > + size_t range_start, size_t range_end)
> > +{
> > + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> > + struct device *dev = msm_obj->base.dev->dev;
> > +
> > + /* exit early if get_pages() hasn't been called yet */
> > + if (!msm_obj->pages)
> > + return;
> > +
> > + /* TODO: sync only the specified range */
> > +
> > + if (flags & MSM_GEM_SYNC_FOR_DEVICE) {
> > + dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
> > + msm_obj->sgt->nents, DMA_TO_DEVICE);
> > + }
> > +
> > + if (flags & MSM_GEM_SYNC_FOR_CPU) {
> > + dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
> > + msm_obj->sgt->nents, DMA_FROM_DEVICE);
> > + }
>
> Splitting this helper from the only caller is rather strange, epecially
> with the two unused arguments. And I think the way this is specified
> to take a range, but ignoring it is actively dangerous. User space will
> rely on it syncing everything sooner or later and then you are stuck.
> So just define a sync all primitive for now, and if you really need a
> range sync and have actually implemented it add a new ioctl for that.
> >>>
> >>> We do already have a split of ioctl "layer" which enforces valid ioctl
> >>> params, etc, and gem (or other) module code which is called by the
> >>> ioctl func. So I think it is fine to keep this split here. (Also, I
> >>> think at some point there will be a uring type of ioctl alternative
> >>> which would re-use the same gem func.)
> >>>
> >>> But I do agree that the range should be respected or added later..
> >>> drm_ioctl() dispatch is well prepared for extending ioctls.
> >>>
> >>> And I assume there should be some validation that the range is aligned
> >>> to cache-line? Or can we flush a partial cache line?
> >>>
> >>
> >> The range is intended to be "sync at least this range", so that
> >> userspace doesn't have to worry about details like that.
> >>
> >
> > I don't think userspace can *not* worry about details like that.
> > Consider a case where the cpu and gpu are simultaneously accessing
> > different parts of a buffer (for ex, sub-allocation). There needs to
> > be cache-line separation between the two.
> >
>
> Right.. and it also seems like we can't get away with just
> flushing/invalidating the whole thing.
>
> qcom's vulkan driver has nonCoherentAtomSize=1, and it looks like
> dma_sync_single_for_cpu() does deal in some way with the partial cache
> line case, although I'm not sure that means we can have a
> nonCoherentAtomSize=1.
>
flush/inv the whole thing could be a useful first step, or at least I
can think of some uses for it. But if it isn't useful for how vk sees
the world, then maybe we should just implement the range properly from
the get-go. (And I *think* requiring the range to be aligned to
cacheline boundaries.. it is always easy from a kernel uabi PoV to
loosen restrictions later, than the other way around.)
BR,
-R
Re: [PATCH net 1/1] net: stmmac: Use rtnl_lock/unlock on netif_set_real_num_rx_queues() call
On Thu, 12 Nov 2020 22:49:48 +0800 Wong Vee Khee wrote:
> Fix an issue where dump stack is printed on suspend resume flow due to
> netif_set_real_num_rx_queues() is not called with rtnl_lock held().
>
> Fixes: 686cff3d7022 ("net: stmmac: Fix incorrect location to set
> real_num_rx|tx_queues")
> Reported-by: Christophe ROULLIER
> Tested-by: Christophe ROULLIER
> Cc: Alexandre TORGUE
> Reviewed-by: Ong Boon Leong
> Signed-off-by: Wong Vee Khee
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index ba855465a2db..33e28004 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -5278,7 +5278,10 @@ int stmmac_resume(struct device *dev)
>
> stmmac_clear_descriptors(priv);
>
> + rtnl_lock();
> stmmac_hw_setup(ndev, false);
> + rtnl_unlock();
> +
> stmmac_init_coalesce(priv);
> stmmac_set_rx_mode(ndev);
>
Doesn't look quite right. This is under the priv->lock which is
sometimes taken under rtnl_lock. So theoretically there could be
a deadlock.
You should probably take rtnl_lock() before priv->lock and release
it after. It's pretty common for drivers to hold rtnl_lock around
most of the resume method.
With larger context:
mutex_lock(>lock);
stmmac_reset_queues_param(priv);
stmmac_clear_descriptors(priv);
+ rtnl_lock();
stmmac_hw_setup(ndev, false);
+ rtnl_unlock();
+
stmmac_init_coalesce(priv);
stmmac_set_rx_mode(ndev);
stmmac_restore_hw_vlan_rx_fltr(priv, ndev, priv->hw);
stmmac_enable_all_queues(priv);
mutex_unlock(>lock);
Re: [PATCH 24/24] perf record: Add --buildid-mmap option to enable mmap's build id
On Sat, Nov 14, 2020 at 09:31:56AM +0900, Namhyung Kim wrote:
> On Fri, Nov 13, 2020 at 8:09 PM Jiri Olsa wrote:
> >
> > On Fri, Nov 13, 2020 at 01:40:00PM +0900, Namhyung Kim wrote:
> > > On Mon, Nov 09, 2020 at 10:54:15PM +0100, Jiri Olsa wrote:
> > > > Adding --buildid-mmap option to enable build id in mmap2 events.
> > > > It will only work if there's kernel support for that and it disables
> > > > build id cache (implies --no-buildid).
> > > >
> > > > It's also possible to enable it permanently via config option
> > > > in ~.perfconfig file:
> > > >
> > > > [record]
> > > > build-id=mmap
> > >
> > > You also need to update the documentation.
> >
> > right, forgot doc for the config option
> >
> > SNIP
> >
> > > > "append timestamp to output filename"),
> > > > OPT_BOOLEAN(0, "timestamp-boundary", _boundary,
> > > > @@ -2657,6 +2662,21 @@ int cmd_record(int argc, const char **argv)
> > > >
> > > > }
> > > >
> > > > + if (rec->buildid_mmap) {
> > > > + if (!perf_can_record_build_id()) {
> > > > + pr_err("Failed: no support to record build id in
> > > > mmap events, update your kernel.\n");
> > > > + err = -EINVAL;
> > > > + goto out_opts;
> > > > + }
> > > > + pr_debug("Enabling build id in mmap2 events.\n");
> > > > + /* Enable mmap build id synthesizing. */
> > > > + symbol_conf.buildid_mmap2 = true;
> > > > + /* Enable perf_event_attr::build_id bit. */
> > > > + rec->opts.build_id = true;
> > > > + /* Disable build id cache. */
> > > > + rec->no_buildid = true;
> > >
> > > I'm afraid this can make it miss some build-id in the end because of
> > > the possibility of the failure.
> >
> > with following fix (already merged):
> > b33164f2bd1c bpf: Iterate through all PT_NOTE sections when looking for
> > build id
> >
> > I could see high rate of build id being retrieved
> >
> > I'll make new numbers for next version, but I think we can neglect
> > the failure, considering that we pick only 'hit' objects out of all
> > of them
> >
> > also enabling the build id cache for this would go against the
> > purpose why I'd like to have this.. so hopefuly the numbers
> > will be convincing ;-)
>
> Yeah, I think it'd be ok for most cases but we cannot guarantee..
> What about checking the dso list at the end of a record session
> and check all of them having build-id? Then we can safely skip
> the build-id collecting stage. Hmm.. but it won't work for the pipe.
how about inject command that would add missing buildids
to mmap2 events
jirka
drivers/media/platform/exynos4-is/fimc-isp-video.h:35:6: warning: no previous prototype for 'fimc_isp_video_device_unregister'
Hi Stephen,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
commit: bbd7ffdbef6888459f301c5889f3b14ada38b913 clk: Allow the common clk
framework to be selectable
date: 6 months ago
config: alpha-randconfig-r004-20201115 (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbd7ffdbef6888459f301c5889f3b14ada38b913
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout bbd7ffdbef6888459f301c5889f3b14ada38b913
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from drivers/media/platform/exynos4-is/fimc-isp.c:25:
>> drivers/media/platform/exynos4-is/fimc-isp-video.h:35:6: warning: no
>> previous prototype for 'fimc_isp_video_device_unregister'
>> [-Wmissing-prototypes]
35 | void fimc_isp_video_device_unregister(struct fimc_isp *isp,
| ^~~~
vim +/fimc_isp_video_device_unregister +35
drivers/media/platform/exynos4-is/fimc-isp-video.h
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 34
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 @35 void
fimc_isp_video_device_unregister(struct fimc_isp *isp,
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 36
enum v4l2_buf_type type)
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 37 {
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 38 }
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 39 #endif /*
!CONFIG_VIDEO_EXYNOS4_ISP_DMA_CAPTURE */
34947b8aebe3f2d Sylwester Nawrocki 2013-12-20 40
:: The code at line 35 was first introduced by commit
:: 34947b8aebe3f2d4eceb65fceafa92bf8dc97d96 [media] exynos4-is: Add the
FIMC-IS ISP capture DMA driver
:: TO: Sylwester Nawrocki
:: CC: Mauro Carvalho Chehab
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks
On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote: > Bjorn, > > On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote: > > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote: > >> pci_device_shutdown() still clears the Bus Master Enable bit if we're > >> doing a kexec and the device is in D0-D3hot, which should also disable > >> MSI/MSI-X. Why doesn't this solve the problem? Is this because the > >> device causing the storm was in PCI_UNKNOWN state? > > > > That's indeed a really good question. > > So we do that on kexec, but is that true when starting a kdump kernel > from a kernel crash? I doubt it. Ah, right, I bet that's it, thanks. The kdump path is basically this: crash_kexec machine_kexec while the usual kexec path is: kernel_kexec kernel_restart_prepare device_shutdown while (!list_empty(_kset->list)) dev->bus->shutdown pci_device_shutdown# pci_bus_type.shutdown machine_kexec So maybe we need to explore doing some or all of device_shutdown() in the crash_kexec() path as well as in the kernel_kexec() path.
