Re: [PATCH] base: power: runtime.c: Remove a unnecessary space
On Sun, 2021-04-18 at 06:08 +, Sebastian Fricke wrote: > Remove a redundant space to improve the quality of the comment. I think this patch is not useful. It's not redundant. Two spaces after a period is commonly used to separate sentences. It's especially common when used with fixed pitch fonts. A trivial grep seems to show it's used about 50K times in comments. Though single space after period may be used about twice as often. $ git grep '^\s*\*.*\. [A-Z]' | wc -l 54439 $ git grep '^\s*\*.*\. [A-Z]' | wc -l 110003 For drivers/base/power/runtime.c, that 2 space after period style is used dozens of times and changing a single instance of it isn't very useful. > --- > Side-note: > I found this while reading the code, I don't believe it is important but > I thought it doesn't hurt to fix it. > --- > drivers/base/power/runtime.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c > index 18b82427d0cb..499434b84171 100644 > --- a/drivers/base/power/runtime.c > +++ b/drivers/base/power/runtime.c > @@ -786,7 +786,7 @@ static int rpm_resume(struct device *dev, int rpmflags) > } > > > /* > - * See if we can skip waking up the parent. This is safe only if > + * See if we can skip waking up the parent. This is safe only if > * power.no_callbacks is set, because otherwise we don't know whether > * the resume will actually succeed. > */
[PATCH] scsi: ufs: Check for bkops in runtime suspend
The UFS driver allowed BKOPS and WB Flush operations to be completed on Runtime suspend. Adding the DeepSleep support, this is no longer true: the driver will ignore BKOPS and WB Flush states, and force a link state transition to UIC_LINK_OFF_STATE. Do not ignore BKOPS and WB Flush on runtme suspend flow. fixes: fe1d4c2ebcae (scsi: ufs: Add DeepSleep feature) Suggested-by: Alex Lemberg Signed-off-by: Avri Altman --- drivers/scsi/ufs/ufshcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 58d7f264c664..1a0cac670aba 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -8755,7 +8755,8 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) * In the case of DeepSleep, the device is expected to remain powered * with the link off, so do not check for bkops. */ - check_for_bkops = !ufshcd_is_ufs_dev_deepsleep(hba); + check_for_bkops = !ufshcd_is_ufs_dev_deepsleep(hba) || + hba->dev_info.b_rpm_dev_flush_capable; ret = ufshcd_link_state_transition(hba, req_link_state, check_for_bkops); if (ret) goto set_dev_active; -- 2.25.1
[PATCH] powerpc/papr_scm: trivial: fix typo in a comment
There is a spelling mistake "byes" -> "bytes" in a comment of function drc_pmem_query_stats(). Fix that typo. Signed-off-by: Kajol Jain --- arch/powerpc/platforms/pseries/papr_scm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c index 835163f54244..ba4faa513a74 100644 --- a/arch/powerpc/platforms/pseries/papr_scm.c +++ b/arch/powerpc/platforms/pseries/papr_scm.c @@ -227,7 +227,7 @@ static int drc_pmem_query_n_bind(struct papr_scm_priv *p) * Query the Dimm performance stats from PHYP and copy them (if returned) to * provided struct papr_scm_perf_stats instance 'stats' that can hold atleast * (num_stats + header) bytes. - * - If buff_stats == NULL the return value is the size in byes of the buffer + * - If buff_stats == NULL the return value is the size in bytes of the buffer * needed to hold all supported performance-statistics. * - If buff_stats != NULL and num_stats == 0 then we copy all known * performance-statistics to 'buff_stat' and expect to be large enough to -- 2.27.0
Fair Pay Language
The Quran recommends a good language. On is well suited for Norwegian translation. And Alla' (in cursive mode latin) is well suited for English translation. This should be a final conclusion on fair pay philosophy in n*X space. My channel is here: https://www.youtube.com/channel/UCtneL5MyJSURptIpRhHJzXw Supports LCPU. Serenity, Ywe Cærlyn.
Re: [PATCH] brcmsmac: fix shift on 4 bit masked value
On Sun, 2021-04-18 at 06:10 +, Kalle Valo wrote:
> Colin King wrote:
>
> > From: Colin Ian King
> >
> > The calculation of offtune_val seems incorrect, the u16 value in
> > pi->tx_rx_cal_radio_saveregs[2] is being masked with 0xf0 and then
> > shifted 8 places right so that always ends up as a zero result. I
> > believe the intended shift was 4 bits to the right. Fix this.
> >
> > [Note: not tested, I don't have the H/W]
> >
> > Addresses-Coverity: ("Operands don't affect result")
> > Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
> > Signed-off-by: Colin Ian King
>
> I think this needs review from someone familiar with the hardware.
>
> Patch set to Changes Requested.
What "change" are you requesting here?
Likely there needs to be some other setting for the patch.
Perhaps "deferred" as you seem to be requesting a review
and there's no actual change necessary, just approval from
someone with the hardware and that someone test the patch.
[PATCH 1/1] lib: scatterlist: Fix SGL length in sg_split() if !CONFIG_NEED_SG_DMA_LENGTH
If CONFIG_NEED_SG_DMA_LENGTH is NOT enabled then sg_dma_len() is an alias for the length field in a SGL. In that case sg_split() wrongly resets the length of split SGLs to zero after it was set correctly before. Signed-off-by: Alexander Egorenkov --- lib/sg_split.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/sg_split.c b/lib/sg_split.c index 60a0babebf2e..3d9b32084d78 100644 --- a/lib/sg_split.c +++ b/lib/sg_split.c @@ -92,7 +92,8 @@ static void sg_split_phys(struct sg_splitter *splitters, const int nb_splits) out_sg->offset = 0; } sg_dma_address(out_sg) = 0; - sg_dma_len(out_sg) = 0; + if (IS_ENABLED(CONFIG_NEED_SG_DMA_LENGTH)) + sg_dma_len(out_sg) = 0; in_sg = sg_next(in_sg); } out_sg[-1].length = split->length_last_sg; -- 2.31.1
RE: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
> -Original Message- > From: Viktor Mihajlovski > Sent: Saturday, April 17, 2021 4:18 PM > To: K, Narendra; Niklas Schnelle; Bjorn Helgaas > Cc: Stefan Raspl; Peter Oberparleiter; linux-net...@vger.kernel.org; linux- > p...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index > > > [EXTERNAL EMAIL] > > > > On 4/16/21 7:58 PM, K, Narendra wrote: > >> -Original Message- > >> From: Niklas Schnelle > >> Sent: Thursday, April 15, 2021 12:55 PM > >> To: Bjorn Helgaas > >> Cc: K, Narendra; Viktor Mihajlovski; Stefan Raspl; Peter > >> Oberparleiter; linux- net...@vger.kernel.org; > >> linux-...@vger.kernel.org; linux- ker...@vger.kernel.org; > >> linux-s...@vger.kernel.org > >> Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its > >> index > >> > >> > >> [EXTERNAL EMAIL] > >> > >> On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote: > >>> On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote: > On s390 each PCI device has a user-defined ID (UID) exposed under > /sys/bus/pci/devices//uid. This ID was designed to serve as > the PCI device's primary index and to match the device within Linux > to the device configured in the hypervisor. To serve as a primary > identifier the UID must be unique within the Linux instance, this > is guaranteed by the platform if and only if the UID Uniqueness > Checking flag is set within the CLP List PCI Functions response. > > In this sense the UID serves an analogous function as the SMBIOS > instance number or ACPI index exposed as the "index" respectively > "acpi_index" device attributes and used by e.g. systemd to set > interface names. As s390 does not use and will likely never use > ACPI nor SMBIOS there is no conflict and we can just expose the UID > under the > >> "index" > attribute whenever UID Uniqueness Checking is active and get > systemd's interface naming support for free. > > Signed-off-by: Niklas Schnelle > Acked-by: Viktor Mihajlovski > >>> > >>> This seems like a nice solution to me. > >>> > >>> Acked-by: Bjorn Helgaas > >> > >> Thanks! Yes I agree it's a simple solution that also makes sense from > >> a design point. I'll wait for Narendra's opinion of course. > > > > Hi Niklas, > > > > It seems like the UID and the index are not equivalent in their meaning. > > > Hi Narendra, > > the reasoning behind the wish to reuse index is that we think it's similar in > the > sense that it provides a stable, firmware-reported interface identifier. > Some background: s390 is a highly virtualized platform. There's no traditional > bare metal mode of operation, neither for the computer system nor the I/O > subsystem. > The equivalent to a standalone system is a logical partition (LPAR) which in > essence is a kind of virtual machine. LPARs access I/O devices in a > virtualized > fashion as well. E.g., for PCI devices the I/O subsystem is responsible for > the > management of PCI hardware and will provide the PCI functions to the LPARs. > This is where UID and function_id come into play. Each PCI function will > carry a > function_id attribute which defines it uniquely within the entire s390 > system. If > a UID is configured for the function, it must be unique within an LPAR, but > doesn't need to be unique system-wide. > For instance, the admistrator may want to ensure that for every LPAR the > primary ethernet interface has the same identifier, to allow miigration of > Linux > instances accross LPARs. > This can't be achieved with a slot-based name. > > The index SMBIOS type 41 device type instance indicates that > > > > 1. The device is an onboard device. > > 2. A specific order of the onboard devices. > > > > The UID described seems to indicate that the PCI device is unique within the > Linux instance (sufficient for naming). > > But it does not indicate that PCI device is onboard and any order. > > > > As all devices with UID will be named as eno (Ethernet onboard), > > names are not in sync with how each PCI function is exposed on a PCI slot > (appears closer to SMBIOS type 9 record) as described below. > > > > https://urldefense.com/v3/__https://github.com/systemd/systemd/pull/19 > > 017__;!!LpKI!zDeT5hnnMp8tFNAzwNWtW3- > C6w7p4FBLldAu705T3EPicJZNI7TewsdZa > > LDBMQ$ [github[.]com] > > > https://urldefense.com/v3/__https://github.com/systemd/systemd/commit/ > > > a496a238e8ee66ce25ad13a3f46549b2e2e979fc__;!!LpKI!zDeT5hnnMp8tFNAz > wNWt > > W3-C6w7p4FBLldAu705T3EPicJZNI7TewsfDTU8TaQ$ [github[.]com] > > > > In summary, it seems like the eno names on s390 will be unique > names, but may not match the meaning of the index. > > > > Also, > > > > a) Will UID remain unique/same as initially exposed across reboots ? > Yes, the UID is the primary identifier for a PCI function and part of the LPAR > configuration. Even hotplug wil
Re: [PATCH] irqchip/xilinx: Expose Kconfig option
Hi Robert, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/irq/core] [also build test ERROR on v5.12-rc7 next-20210416] [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/Robert-Hancock/irqchip-xilinx-Expose-Kconfig-option/20210416-080610 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 7c07012eb1be8b4a95d3502fd30795849007a40e config: s390-allmodconfig (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://github.com/0day-ci/linux/commit/4ece2fff79c8d47de22ecca7c8d18d96525bfa43 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Robert-Hancock/irqchip-xilinx-Expose-Kconfig-option/20210416-080610 git checkout 4ece2fff79c8d47de22ecca7c8d18d96525bfa43 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 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: kernel/dma/coherent.o: in function `dma_init_coherent_memory': coherent.c:(.text+0x3bc): undefined reference to `memremap' s390-linux-ld: coherent.c:(.text+0x500): undefined reference to `memunmap' s390-linux-ld: kernel/dma/coherent.o: in function `dma_declare_coherent_memory': coherent.c:(.text+0xae6): undefined reference to `memunmap' s390-linux-ld: drivers/irqchip/irq-al-fic.o: in function `al_fic_init_dt': irq-al-fic.c:(.init.text+0x98): undefined reference to `of_iomap' s390-linux-ld: irq-al-fic.c:(.init.text+0x596): undefined reference to `iounmap' s390-linux-ld: drivers/irqchip/irq-xilinx-intc.o: in function `xilinx_intc_of_init': >> irq-xilinx-intc.c:(.init.text+0x9e): undefined reference to `of_iomap' >> s390-linux-ld: irq-xilinx-intc.c:(.init.text+0x5f6): undefined reference to >> `iounmap' s390-linux-ld: drivers/clk/clk-fixed-mmio.o: in function `fixed_mmio_clk_setup': clk-fixed-mmio.c:(.text+0x9a): undefined reference to `of_iomap' s390-linux-ld: clk-fixed-mmio.c:(.text+0xe6): undefined reference to `iounmap' s390-linux-ld: drivers/clocksource/timer-of.o: in function `timer_of_init': timer-of.c:(.init.text+0xcc): undefined reference to `of_iomap' s390-linux-ld: timer-of.c:(.init.text+0x8ee): undefined reference to `iounmap' s390-linux-ld: drivers/clocksource/timer-of.o: in function `timer_of_cleanup': timer-of.c:(.init.text+0xb9a): undefined reference to `iounmap' s390-linux-ld: drivers/clocksource/timer-microchip-pit64b.o: in function `mchp_pit64b_dt_init_timer': timer-microchip-pit64b.c:(.init.text+0x150): undefined reference to `of_iomap' s390-linux-ld: timer-microchip-pit64b.c:(.init.text+0xc78): undefined reference to `iounmap' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] net/wireless/bcom: constify ieee80211_get_response_rate return
It's not modified so make it const with the eventual goal of moving
data to text for various static struct ieee80211_rate arrays.
Signed-off-by: Joe Perches
---
drivers/net/wireless/broadcom/b43/main.c | 2 +-
drivers/net/wireless/broadcom/b43legacy/main.c | 2 +-
include/net/cfg80211.h | 2 +-
net/wireless/util.c| 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/main.c
b/drivers/net/wireless/broadcom/b43/main.c
index 150a366e8f62..17bcec5f3ff7 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -4053,7 +4053,7 @@ static void b43_update_basic_rates(struct b43_wldev *dev,
u32 brates)
{
struct ieee80211_supported_band *sband =
dev->wl->hw->wiphy->bands[b43_current_band(dev->wl)];
- struct ieee80211_rate *rate;
+ const struct ieee80211_rate *rate;
int i;
u16 basic, direct, offset, basic_offset, rateptr;
diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c
b/drivers/net/wireless/broadcom/b43legacy/main.c
index 7692a2618c97..f64ebff68308 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -2762,7 +2762,7 @@ static void b43legacy_update_basic_rates(struct
b43legacy_wldev *dev, u32 brates
{
struct ieee80211_supported_band *sband =
dev->wl->hw->wiphy->bands[NL80211_BAND_2GHZ];
- struct ieee80211_rate *rate;
+ const struct ieee80211_rate *rate;
int i;
u16 basic, direct, offset, basic_offset, rateptr;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 911fae42b0c0..ed07590bc72d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5606,7 +5606,7 @@ static inline bool cfg80211_channel_is_psc(struct
ieee80211_channel *chan)
* which is, for this function, given as a bitmap of indices of
* rates in the band's bitrate table.
*/
-struct ieee80211_rate *
+const struct ieee80211_rate *
ieee80211_get_response_rate(struct ieee80211_supported_band *sband,
u32 basic_rates, int bitrate);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 1bf0200f562a..382c5262d997 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -24,7 +24,7 @@
#include "rdev-ops.h"
-struct ieee80211_rate *
+const struct ieee80211_rate *
ieee80211_get_response_rate(struct ieee80211_supported_band *sband,
u32 basic_rates, int bitrate)
{
Re: [PATCH v8 1/2] Added AMS tsl2591 driver implementation
On Fri, 16 Apr 2021 18:49:01 +0100
Joe Sandom wrote:
> Driver implementation for AMS/TAOS tsl2591 ambient light sensor.
>
> This driver supports configuration via device tree and sysfs.
> Supported channels for raw infrared light intensity,
> raw combined light intensity and illuminance in lux.
> The driver additionally supports iio events on lower and
> upper thresholds.
>
> This is a very-high sensitivity light-to-digital converter that
> transforms light intensity into a digital signal.
>
> Datasheet: https://ams.com/tsl25911#tab/documents
> Signed-off-by: Joe Sandom
Hi Joe,
I was in two minds about whether to just apply this and roll in the below
suggestions + those Andy made or whether to ask you to do a v9.
The naming and units things below are complex enough that I'm not 100% sure
I'd get the right so please take a look and clean up those last few
corners!
Thanks,
Jonathan
> ---
> Changes in v8;
> - tsl2591_write_raw() - goto after tsl2591_set_als_gain_int_time() not
> necessary
> - tsl2591_read_event_value() and tsl2591_write_event_value() - break instead
> of goto in default case
> - Introduced tsl2591_info_no_irq iio_info structure which is used when the
> interrupt is disabled.
> This variant doesn't expose anything that can't be used when the interrupt
> is disabled
> - Corrected ordering of includes for
> - Renamed TSL2591_FVAL_TO_ATIME to TSL2591_MSEC_TO_ATIME
> - Renamed TSL2591_ATIME_TO_FVAL to TSL2591_ATIME_TO_MSEC
> - Changed TSL2591_STS_ALS* defines to all use BIT for consistency
> - Use (BIT(4) - 1) instead of value from list for
> TSL2591_PRST_ALS_INT_CYCLE_MAX
> - Cleaned up a few blank lines that were unneccesary
> - Use sysfs_emit() instead of snprintf() in
> tsl2591_in_illuminance_period_available_show()
> - Use err_unlock branch instead of err to be clear on mutex_unlock cases
> - Tidied up use of goto err_unlock in tsl2591_read_raw() to be consistent
> with other functions
>
> NOTE;
> - tsl2591_set_als_lower_threshold() and tsl2591_set_als_upper_threshold()
> forward declaration needed
> because tsl2591_set_als_lower_threshold() calls
> tsl2591_set_als_upper_threshold() and vice versa
>
> drivers/iio/light/Kconfig | 11 +
> drivers/iio/light/Makefile |1 +
> drivers/iio/light/tsl2591.c | 1227 +++
> 3 files changed, 1239 insertions(+)
> create mode 100644 drivers/iio/light/tsl2591.c
>
...
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index ea376deaca54..d10912faf964 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_ST_UVIS25_SPI) += st_uvis25_spi.o
> obj-$(CONFIG_TCS3414)+= tcs3414.o
> obj-$(CONFIG_TCS3472)+= tcs3472.o
> obj-$(CONFIG_TSL2583)+= tsl2583.o
> +obj-$(CONFIG_TSL2591)+= tsl2591.o
> obj-$(CONFIG_TSL2772)+= tsl2772.o
> obj-$(CONFIG_TSL4531)+= tsl4531.o
> obj-$(CONFIG_US5182D)+= us5182d.o
> diff --git a/drivers/iio/light/tsl2591.c b/drivers/iio/light/tsl2591.c
> new file mode 100644
> index ..4f9c5e19ee35
> --- /dev/null
> +++ b/drivers/iio/light/tsl2591.c
> @@ -0,0 +1,1227 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Joe Sandom
Update perhaps?
> + *
> + * Datasheet: https://ams.com/tsl25911#tab/documents
> + *
> + * Device driver for the TAOS TSL2591. This is a very-high sensitivity
> + * light-to-digital converter that transforms light intensity into a digital
> + * signal.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* ADC integration time, field value to time in ms */
> +#define TSL2591_MSEC_TO_ATIME(x) (((x) + 1) * 100)
Naming here seems backwards. I'd assume that at MSEC_TO_ATIME
function went msecs -> atime but it seems to be doing the opposite.
> +/* ADC integration time, time in ms to field value */
> +#define TSL2591_ATIME_TO_MSEC(x) (((x) / 100) - 1)
> +
...
> +
> +/*
> + * Period table is ALS persist cycle x integration time setting
> + * Integration times: 100ms, 200ms, 300ms, 400ms, 500ms, 600ms
> + * ALS cycles: 1, 2, 3, 5, 10, 20, 25, 30, 35, 40, 45, 50, 55, 60
> + */
> +static const char * const tsl2591_als_period_list[] = {
> + "0.1 0.2 0.3 0.5 1.0 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0",
> + "0.2 0.4 0.6 1.0 2.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0",
> + "0.3 0.6 0.9 1.5 3.0 6.0 7.5 9.0 10.5 12.0 13.5 15.0 16.5 18.0",
> + "0.4 0.8 1.2 2.0 4.0 8.0 10.0 12.0 14.0 16.0 18.0 20.0 22.0 24.0",
> + "0.5 1.0 1.5 2.5 5.0 10.0 12.5 15.0 17.5 20.0 22.5 25.0 27.5 30.0",
> + "0.6 1.2 1.8 3.0 6.0 12.0 15.0 18.0 21.0 24.0 27.0 30.0 33.0 36.0",
> +};
> +
> +static const int tsl2591_int_time_available[] = {
> + 100, 200, 300, 400, 500, 6
Re: [PATCH] base: power: runtime.c: Remove a unnecessary space
Hey Joe, On 18.04.2021 00:09, Joe Perches wrote: On Sun, 2021-04-18 at 06:08 +, Sebastian Fricke wrote: Remove a redundant space to improve the quality of the comment. I think this patch is not useful. It's not redundant. Thank you, I actually found this pattern a few more times but I wanted to check first if this is a mistake or chosen consciously. Sorry for the noise. Two spaces after a period is commonly used to separate sentences. It's especially common when used with fixed pitch fonts. A trivial grep seems to show it's used about 50K times in comments. Though single space after period may be used about twice as often. $ git grep '^\s*\*.*\. [A-Z]' | wc -l 54439 $ git grep '^\s*\*.*\. [A-Z]' | wc -l 110003 For drivers/base/power/runtime.c, that 2 space after period style is used dozens of times and changing a single instance of it isn't very useful. True and if I understand you correctly you would rather keep it as is right? Greetings, Sebastian --- Side-note: I found this while reading the code, I don't believe it is important but I thought it doesn't hurt to fix it. --- drivers/base/power/runtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 18b82427d0cb..499434b84171 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -786,7 +786,7 @@ static int rpm_resume(struct device *dev, int rpmflags) } /* -* See if we can skip waking up the parent. This is safe only if +* See if we can skip waking up the parent. This is safe only if * power.no_callbacks is set, because otherwise we don't know whether * the resume will actually succeed. */
Re: [PATCH] base: power: runtime.c: Remove a unnecessary space
On Sun 2021-04-18 09:11:43, Sebastian Fricke wrote: > Hey Joe, > > On 18.04.2021 00:09, Joe Perches wrote: > >On Sun, 2021-04-18 at 06:08 +, Sebastian Fricke wrote: > >>Remove a redundant space to improve the quality of the comment. > > > >I think this patch is not useful. > > > >It's not redundant. > > Thank you, I actually found this pattern a few more times but I wanted > to check first if this is a mistake or chosen consciously. It is okay as it is. No need to remove extra space. No need to add it, either. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote: > Optimization could be done on dsa_skb_tx_timestamp(), and dsa device > drivers should adapt to it. > > - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in > port_txtstamp, so that most skbs not requiring tx timestamp just return. Agree that this is a trivial performance optimization with no downside that we should be making. > - No longer to identify PTP packets, and limit tx timestamping only for PTP > packets. If device driver likes, let device driver do. Agree that DSA has a way too heavy hand in imposing upon the driver which packets should be timestampable and which ones shouldn't. For example, I have a latency measurement tool called isochron which is based on hardware timestamping of non-PTP packets (in order to not disturb the PTP state machines): https://github.com/vladimiroltean/tsn-scripts I can't use it on DSA interfaces, for rather artificial reasons. > - It is a waste to clone skb directly in dsa_skb_tx_timestamp(). > For one-step timestamping, a clone is not needed. For any failure of > port_txtstamp (this may usually happen), the skb clone has to be freed. > So put skb cloning into port_txtstamp where it really needs. Mostly agree. For two-step timestamping, it is an operation which all drivers need to do, so it is in the common potion. If we want to support one-step, we need to avoid cloning the PTP packets. > Signed-off-by: Yangbo Lu > --- > Documentation/networking/timestamping.rst | 7 +-- > .../net/dsa/hirschmann/hellcreek_hwtstamp.c | 20 -- > .../net/dsa/hirschmann/hellcreek_hwtstamp.h | 2 +- > drivers/net/dsa/mv88e6xxx/hwtstamp.c | 21 +-- > drivers/net/dsa/mv88e6xxx/hwtstamp.h | 6 +++--- > drivers/net/dsa/ocelot/felix.c| 11 ++ > drivers/net/dsa/sja1105/sja1105_ptp.c | 6 +- > drivers/net/dsa/sja1105/sja1105_ptp.h | 2 +- > include/net/dsa.h | 2 +- > net/dsa/slave.c | 20 +- > 10 files changed, 57 insertions(+), 40 deletions(-) > > diff --git a/Documentation/networking/timestamping.rst > b/Documentation/networking/timestamping.rst > index f682e88fa87e..7f04a699a5d1 100644 > --- a/Documentation/networking/timestamping.rst > +++ b/Documentation/networking/timestamping.rst > @@ -635,8 +635,8 @@ in generic code: a BPF classifier (``ptp_classify_raw``) > is used to identify > PTP event messages (any other packets, including PTP general messages, are > not > timestamped), and provides two hooks to drivers: > > -- ``.port_txtstamp()``: The driver is passed a clone of the timestampable skb > - to be transmitted, before actually transmitting it. Typically, a switch > will > +- ``.port_txtstamp()``: A clone of the timestampable skb to be transmitted > + is needed, before actually transmitting it. Typically, a switch will >have a PTP TX timestamp register (or sometimes a FIFO) where the timestamp >becomes available. There may be an IRQ that is raised upon this timestamp's >availability, or the driver might have to poll after invoking > @@ -645,6 +645,9 @@ timestamped), and provides two hooks to drivers: >later use (when the timestamp becomes available). Each skb is annotated > with >a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the driver's >job of keeping track of which clone belongs to which skb. > + But one-step timestamping request is handled differently with above > two-step > + timestamping. The skb clone is no longer needed since hardware will insert > + TX time information on packet during egress. Bonus points for updating the documentation, but I don't quite like the end result. Please feel free to restructure more, in order to have a clearer and more coherent explanation. Also, this paragraph from right above is no longer true: In code, DSA provides for most of the infrastructure for timestamping already, in generic code: a BPF classifier (``ptp_classify_raw``) is used to identify PTP event messages (any other packets, including PTP general messages, are not timestamped), and provides two hooks to drivers: It's nothing like that anymore. It's more of a passthrough now with your changes, the BPF classifier is not run by the DSA core but optionally by individual taggers. Here is my attempt of rewriting this documentation paragraph, feel free to take which parts you consider relevant: -[cut here]- In the generic layer, DSA provides the following infrastructure for PTP timestamping: - ``.port_txtstamp()``: a hook called prior to the transmission of packets with a hardware TX timestamping request from user space. This is required for two-step timestamping, since the hardware timestamp becomes available after the actual MAC transmission, so t
Re: [PATCH] base: power: runtime.c: Remove a unnecessary space
On Sun, 2021-04-18 at 09:11 +, Sebastian Fricke wrote: > Hey Joe, Hi Sebastian. > On 18.04.2021 00:09, Joe Perches wrote: > > On Sun, 2021-04-18 at 06:08 +, Sebastian Fricke wrote: > > > Remove a redundant space to improve the quality of the comment. > > I think this patch is not useful. > > It's not redundant. > > Thank you, I actually found this pattern a few more times but I wanted > to check first if this is a mistake or chosen consciously. [] > > For drivers/base/power/runtime.c, that 2 space after period style is used > > dozens of times and changing a single instance of it isn't very useful. Even in that single file it's not consistent. It's something like 3:1 for 2 spaces over 1 space after period. I believe it's done more by habit and author age than anything. If you learned to type using a typewriter and not a keyboard, then you likely still use 2 spaces after a period. > True and if I understand you correctly you would rather keep it as is > right? Yes. IMO: Whitespace in comments like this should not be changed unless there's some other significant benefit like better alignment. cheers, Joe > > > --- > > > Side-note: > > > I found this while reading the code, I don't believe it is important but > > > I thought it doesn't hurt to fix it. [] > > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c [] > > > @@ -786,7 +786,7 @@ static int rpm_resume(struct device *dev, int > > > rpmflags) > > > } > > > > > > /* > > > - * See if we can skip waking up the parent. This is safe only if > > > + * See if we can skip waking up the parent. This is safe only if > > > * power.no_callbacks is set, because otherwise we don't know whether > > > * the resume will actually succeed. > > > */
Re: [net-next 2/3] net: mscc: ocelot: convert to ocelot_port_txtstamp_request()
On Fri, Apr 16, 2021 at 08:36:54PM +0800, Yangbo Lu wrote:
> Convert to a common ocelot_port_txtstamp_request() for TX timestamp
> request handling.
>
> Signed-off-by: Yangbo Lu
> ---
> drivers/net/dsa/ocelot/felix.c | 14 +-
> drivers/net/ethernet/mscc/ocelot.c | 24 +---
> drivers/net/ethernet/mscc/ocelot_net.c | 18 +++---
> include/soc/mscc/ocelot.h | 5 +++--
> 4 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
> index cdec2f5e271c..5f2cf0f31253 100644
> --- a/drivers/net/dsa/ocelot/felix.c
> +++ b/drivers/net/dsa/ocelot/felix.c
> @@ -1399,18 +1399,14 @@ static bool felix_txtstamp(struct dsa_switch *ds, int
> port,
> struct sk_buff *skb, struct sk_buff **clone)
> {
> struct ocelot *ocelot = ds->priv;
> - struct ocelot_port *ocelot_port = ocelot->ports[port];
>
> - if (ocelot->ptp && ocelot_port->ptp_cmd == IFH_REW_OP_TWO_STEP_PTP) {
> - *clone = skb_clone_sk(skb);
> - if (!(*clone))
> - return false;
> + if (!ocelot->ptp)
> + return false;
>
> - ocelot_port_add_txtstamp_skb(ocelot, port, *clone);
> - return true;
> - }
> + if (ocelot_port_txtstamp_request(ocelot, port, skb, clone))
> + return false;
>
> - return false;
> + return true;
Considering the changes you'll have to make to patch 1 (changing the
return value and populating DSA_SKB_CB(skb)->clone at the end of this
function:
Reviewed-by: Vladimir Oltean
Re: [PATCH v3] serial: omap: fix rs485 half-duplex filtering
> Il 16/04/2021 08:46 Greg Kroah-Hartman ha
> scritto:
>
>
> On Thu, Apr 15, 2021 at 11:02:52PM +0200, Dario Binacchi wrote:
> > Data received during half-duplex transmission must be filtered.
> > If the target device responds quickly, emptying the FIFO at the end of
> > the transmission can erase not only the echo characters but also part of
> > the response message.
> > By keeping the receive interrupt enabled even during transmission, it
> > allows you to filter each echo character and only in a number equal to
> > those transmitted.
> > The issue was generated by a target device that started responding
> > 240us later having received a request in communication at 115200bps.
> > Sometimes, some messages received by the target were missing some of the
> > first bytes.
> >
> > Fixes: 3a13884abea0 ("tty/serial: omap: empty the RX FIFO at the end of
> > half-duplex TX")
> > Signed-off-by: Dario Binacchi
> >
> >
> > ---
> >
> > Changes in v3:
> > - Add 'Fixes' tag
> >
> > Changes in v2:
> > - Fix compiling error
> >
> > drivers/tty/serial/omap-serial.c | 39
> > 1 file changed, 24 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/tty/serial/omap-serial.c
> > b/drivers/tty/serial/omap-serial.c
> > index 76b94d0ff586..c0df22b7ea5e 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -159,6 +159,8 @@ struct uart_omap_port {
> > u32 calc_latency;
> > struct work_struct qos_work;
> > boolis_suspending;
> > +
> > + atomic_trs485_tx_filter_count;
>
> Why are you using an atomic variable? What do you think this is
> "protected from"?
You are right. They are already protected. All the functions affected by the
patch
are already protected by a lock, even going up in the serial_core for the
serial_omap_start_tx().
Thanks and regards,
Dario
>
> > };
> >
> > #define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
> > port)))
> > @@ -328,19 +330,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
> > serial_out(up, UART_IER, up->ier);
> > }
> >
> > - if ((port->rs485.flags & SER_RS485_ENABLED) &&
> > - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) {
> > - /*
> > -* Empty the RX FIFO, we are not interested in anything
> > -* received during the half-duplex transmission.
> > -*/
> > - serial_out(up, UART_FCR, up->fcr | UART_FCR_CLEAR_RCVR);
> > - /* Re-enable RX interrupts */
> > - up->ier |= UART_IER_RLSI | UART_IER_RDI;
> > - up->port.read_status_mask |= UART_LSR_DR;
> > - serial_out(up, UART_IER, up->ier);
> > - }
> > -
> > pm_runtime_mark_last_busy(up->dev);
> > pm_runtime_put_autosuspend(up->dev);
> > }
> > @@ -366,6 +355,10 @@ static void transmit_chars(struct uart_omap_port *up,
> > unsigned int lsr)
> > serial_out(up, UART_TX, up->port.x_char);
> > up->port.icount.tx++;
> > up->port.x_char = 0;
> > + if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
> > + !(up->port.rs485.flags & SER_RS485_RX_DURING_TX))
> > + atomic_inc(&up->rs485_tx_filter_count);
> > +
> > return;
> > }
> > if (uart_circ_empty(xmit) || uart_tx_stopped(&up->port)) {
> > @@ -377,6 +370,10 @@ static void transmit_chars(struct uart_omap_port *up,
> > unsigned int lsr)
> > serial_out(up, UART_TX, xmit->buf[xmit->tail]);
> > xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> > up->port.icount.tx++;
> > + if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
> > + !(up->port.rs485.flags & SER_RS485_RX_DURING_TX))
> > + atomic_inc(&up->rs485_tx_filter_count);
> > +
> > if (uart_circ_empty(xmit))
> > break;
> > } while (--count > 0);
> > @@ -420,7 +417,7 @@ static void serial_omap_start_tx(struct uart_port *port)
> >
> > if ((port->rs485.flags & SER_RS485_ENABLED) &&
> > !(port->rs485.flags & SER_RS485_RX_DURING_TX))
> > - serial_omap_stop_rx(port);
> > + atomic_set(&up->rs485_tx_filter_count, 0);
> >
> > serial_omap_enable_ier_thri(up);
> > pm_runtime_mark_last_busy(up->dev);
> > @@ -491,8 +488,13 @@ static void serial_omap_rlsi(struct uart_omap_port
> > *up, unsigned int lsr)
> > * Read one data character out to avoid stalling the receiver according
> > * to the table 23-246 of the omap4 TRM.
> > */
> > - if (likely(lsr & UART_LSR_DR))
> > + if (likely(lsr & UART_LSR_DR)) {
> > serial_in(up, UART_RX);
> > + if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
> > + !(up->port.rs485.flags & SER_RS485_RX_DURING_TX) &&
> > + atomic_read(&up->rs485_tx_filter_count))
> > +
[RFT PATCH] MIPS: Octeon: drop dependency on CONFIG_HOLES_IN_ZONE
From: Mike Rapoport
CAVIUM_OCTEON_SOC configuration selects HOLES_IN_ZONE option to cope with
memory crashes that were happening in 2011.
This option effectively aliases pfn_valid_within() to pfn_valid() when
enabled and hardwires it to 1 when disabled. The check for
pfn_valid_within() is only relevant in case the memory map may have holes
or undefined struct page instances inside MAX_ORDER chunks.
Since 2011 memory management initialization in general and memory map
initialization particularly became much more robust so the check for
pfn_valid_within() is not required on Octeon even despite its, hmm, unusual
memory setup.
Remove the selection of HOLES_IN_ZONE by CAVIUM_OCTEON_SOC and drop the
HOLES_IN_ZONE configuration option entirely as Octeon was the only MIPS
platform to use it.
Signed-off-by: Mike Rapoport
---
Hi,
I've tried to find why Octeon needed CONFIG_HOLES_IN_ZONE in the first
place, but there is nothing except the changelog in commit 465aaed0030b
("MIPS: Octeon: Select CONFIG_HOLES_IN_ZONE"):
Current Octeon systems do in fact have holes in their memory zones.
We need to select HOLES_IN_ZONE. If we do not, some memory configurations
will result in crashes at boot time
Since then there were too many changes around memory management
initialization both in the generic mm and on the MIPS side to track what
exactly could case the crashes.
I'm pretty confident that HOLES_IN_ZONE is not required for Octeon systems
anymore and can be removed.
I'd really appreciate if somebody with access to an Octeon system could
test this patch.
arch/mips/Kconfig | 4
1 file changed, 4 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..96b08cd3b442 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -990,7 +990,6 @@ config CAVIUM_OCTEON_SOC
select HAVE_PLAT_FW_INIT_CMDLINE
select HAVE_PLAT_MEMCPY
select ZONE_DMA32
- select HOLES_IN_ZONE
select GPIOLIB
select USE_OF
select ARCH_SPARSEMEM_ENABLE
@@ -1226,9 +1225,6 @@ config HAVE_PLAT_MEMCPY
config ISA_DMA_API
bool
-config HOLES_IN_ZONE
- bool
-
config SYS_SUPPORTS_RELOCATABLE
bool
help
--
2.28.0
Re: [PATCH] iio: light: gp2ap002: Fix rumtime PM imbalance on error
On Mon, 12 Apr 2021 13:47:58 +0200 Linus Walleij wrote: > On Mon, Apr 12, 2021 at 12:16 PM Jonathan Cameron > wrote: > > > An example would be the bmc150_magn driver which does exactly the > > same call sequence as this one, but without the reference count increment > > and decrement. Basically I want to know if there is a problem in > > those other drivers that is being protected against here! > > The bmc150_magn driver does not look like I would have done it. > > That said, I think it works, because the only thing it is calling is > bmc150_magn_set_power_mode() and that seems stateless, > just poking some regmap bits. The state is tracked by the driver > AFAICT and we don't need pm_runtime_get_noresume() because > it doesn't really matter if the pm_runtime_suspend() callback > gets called immediately or randomly out of sync with what we are > doing from this point. > > I would anyways patch it like the gp2ap002 driver because it > is easier to follow the code. Including using only runtime PM > att setting SET_SYSTEM_SLEEP_PM_OPS() to the > pm_runtime_force_suspend and pm_runtime_force_resume > functions, everything just get so much easier when you use > only one type of PM and not two orthogonal ones. > > drivers/iio/light/bh1780.c > should be a good example of how to do it idiomatically > because it was reviewed by Ulf Hansson who knows this > runtime PM stuff better than me. > > A sequence like this: > >pm_runtime_get_noresume(&client->dev); >pm_runtime_set_active(&client->dev); >pm_runtime_enable(&client->dev); >pm_runtime_set_autosuspend_delay(&client->dev, 5000); >pm_runtime_use_autosuspend(&client->dev); >pm_runtime_put(&client->dev); > > is very nice because you can clearly see that it will not race > and after the last put() unless something happens the > runtime suspend will kick in after 5000 ms. > > Likewise when disabling: > > pm_runtime_get_sync(&client->dev); > pm_runtime_put_noidle(&client->dev); > pm_runtime_disable(&client->dev); > > same thing: crystal clear there are no races, the device is > definately runtime resumed and we can proceed to > shut down resources explicitly after this point. > > If you then add: > > SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, > pm_runtime_force_resume) > > Now you have ordinary sleep PM for free. It will just > force the same suspend/resume callbacks and they are > guaranteed to be race free. > > This doesn't work for everyone but surprisingly often this is > what you want. I'm still far from completely convinced that it is 'necessary' to take the reference whilst going through this sequence because there is nothing to kick off the suspend until we tell it to use autosuspend. However, I appreciate (much like taking locks in general in probe) that it makes it easy to see there is no race. Anyhow, fix is still valid either way so applied to the fixes togreg branch of iio.git with a fixes tag added to the initial introduction of the driver (which I think is where this came in). Thanks, Jonathan > > Yours, > Linus Walleij
Re: [PATCH] [v2] iio: proximity: pulsedlight: Fix rumtime PM imbalance on error
On Mon, 12 Apr 2021 12:23:43 +0300
Andy Shevchenko wrote:
> On Mon, Apr 12, 2021 at 8:32 AM Dinghao Liu wrote:
> >
> > When lidar_write_control() fails, a pairing PM usage counter
> > decrement is needed to keep the counter balanced.
>
> You forgot to collect given tags.
>
> > Fixes: 4ac4e086fd8c5 ("iio: pulsedlight-lidar-lite: add runtime PM")
> > Signed-off-by: Dinghao Liu
I gathered up the tags by hand and applied to the fixes-togreg branch of iio.git
Thanks,
Jonathan
> > ---
> >
> > Changelog:
> >
> > v2: - Add the fix tag.
> > ---
> > drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > index c685f10b5ae4..cc206bfa09c7 100644
> > --- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > +++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > @@ -160,6 +160,7 @@ static int lidar_get_measurement(struct lidar_data
> > *data, u16 *reg)
> > ret = lidar_write_control(data, LIDAR_REG_CONTROL_ACQUIRE);
> > if (ret < 0) {
> > dev_err(&client->dev, "cannot send start measurement
> > command");
> > + pm_runtime_put_noidle(&client->dev);
> > return ret;
> > }
> >
> > --
> > 2.17.1
> >
>
>
Re: [net-next 3/3] net: mscc: ocelot: support PTP Sync one-step timestamping
On Fri, Apr 16, 2021 at 08:36:55PM +0800, Yangbo Lu wrote:
> Although HWTSTAMP_TX_ONESTEP_SYNC existed in ioctl for hardware timestamp
> configuration, the PTP Sync one-step timestamping had never been supported.
>
> This patch is to truely support it.
Actually the ocelot switchdev driver does support one-step timestamping,
just the felix DSA driver does not.
> The hardware timestamp request type is
> stored in DSA_SKB_CB_PRIV first byte per skb, so that corresponding
> configuration could be done during transmitting. Non-onestep-Sync packet
> with one-step timestamp request should fall back to use two-step timestamp.
>
> Signed-off-by: Yangbo Lu
> ---
> drivers/net/ethernet/mscc/ocelot.c | 57 ++
> drivers/net/ethernet/mscc/ocelot_net.c | 5 +--
> include/soc/mscc/ocelot.h | 1 +
> net/dsa/tag_ocelot.c | 25 ++-
> net/dsa/tag_ocelot_8021q.c | 39 +-
> 5 files changed, 72 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/net/ethernet/mscc/ocelot.c
> b/drivers/net/ethernet/mscc/ocelot.c
> index 541d3b4076be..69d36b6241ff 100644
> --- a/drivers/net/ethernet/mscc/ocelot.c
> +++ b/drivers/net/ethernet/mscc/ocelot.c
> @@ -6,6 +6,7 @@
> */
> #include
> #include
> +#include
> #include
> #include "ocelot.h"
> #include "ocelot_vcap.h"
> @@ -546,6 +547,50 @@ static void ocelot_port_add_txtstamp_skb(struct ocelot
> *ocelot, int port,
> spin_unlock(&ocelot_port->ts_id_lock);
> }
>
> +bool ocelot_ptp_rew_op(struct sk_buff *skb, struct sk_buff *clone, u32
> *rew_op)
> +{
> + /* For two-step timestamp, retrieve ptp_cmd in DSA_SKB_CB_PRIV
> + * and timestamp ID in clone->cb[0].
> + * For one-step timestamp, retrieve ptp_cmd in DSA_SKB_CB_PRIV.
> + */
> + u8 *ptp_cmd = DSA_SKB_CB_PRIV(skb);
This is fine in the sense that it works, but please consider creating
something similar to sja1105:
struct ocelot_skb_cb {
u8 ptp_cmd; /* For both one-step and two-step timestamping */
u8 ts_id; /* Only for two-step timestamping */
};
#define OCELOT_SKB_CB(skb) \
((struct ocelot_skb_cb *)DSA_SKB_CB_PRIV(skb))
And then access as OCELOT_SKB_CB(skb)->ptp_cmd, OCELOT_SKB_CB(clone)->ts_id.
and put a comment to explain that this is done in order to have common
code between Felix DSA and Ocelot switchdev. Basically Ocelot will not
use the first 8 bytes of skb->cb, but there's enough space for this to
not make any difference. The original skb will hold only ptp_cmd, the
clone will only hold ts_id, but it helps to have the same structure in
place.
If you create this ocelot_skb_cb structure, I expect the comment above
to be fairly redundant, you can consider removing it.
> +
> + if (clone) {
> + *rew_op = *ptp_cmd;
> + *rew_op |= clone->cb[0] << 3;
> + } else if (*ptp_cmd) {
> + *rew_op = *ptp_cmd;
> + } else {
> + return false;
> + }
> +
> + return true;
Just make this function return an u32. If the packet isn't PTP, the
rew_op will be 0.
> +}
> +EXPORT_SYMBOL(ocelot_ptp_rew_op);
> +
> +static bool ocelot_ptp_is_onestep_sync(struct sk_buff *skb)
> +{
> + struct ptp_header *hdr;
> + unsigned int ptp_class;
> + u8 msgtype, twostep;
> +
> + ptp_class = ptp_classify_raw(skb);
> + if (ptp_class == PTP_CLASS_NONE)
> + return false;
> +
> + hdr = ptp_parse_header(skb, ptp_class);
> + if (!hdr)
> + return false;
> +
> + msgtype = ptp_get_msgtype(hdr, ptp_class);
> + twostep = hdr->flag_field[0] & 0x2;
> +
> + if (msgtype == PTP_MSGTYPE_SYNC && twostep == 0)
> + return true;
> +
> + return false;
> +}
> +
This is generic, but if you were to move it to net/core/ptp_classifier.c,
I think you would have to pass the output of ptp_classify_raw() as an
"unsigned int type" argument. So I think I would leave it the way it is
for now - inside of ocelot - until somebody else needs something
similar, and we see what is the required prototype.
> int ocelot_port_txtstamp_request(struct ocelot *ocelot, int port,
>struct sk_buff *skb,
>struct sk_buff **clone)
> @@ -553,12 +598,24 @@ int ocelot_port_txtstamp_request(struct ocelot *ocelot,
> int port,
> struct ocelot_port *ocelot_port = ocelot->ports[port];
> u8 ptp_cmd = ocelot_port->ptp_cmd;
>
> + /* Store ptp_cmd in first byte of DSA_SKB_CB_PRIV per skb */
> + if (ptp_cmd == IFH_REW_OP_ORIGIN_PTP) {
> + if (ocelot_ptp_is_onestep_sync(skb)) {
> + *(u8 *)DSA_SKB_CB_PRIV(skb) = ptp_cmd;
> + return 0;
> + }
> +
> + /* Fall back to two-step timestamping */
> + ptp_cmd = IFH_REW_OP_TWO_STEP_PTP;
> + }
> +
> if (ptp_cmd == IFH_REW_OP_TWO_STEP_PTP) {
> *clone = skb_clone_sk(skb);
> i
[PATCH v4] serial: omap: fix rs485 half-duplex filtering
Data received during half-duplex transmission must be filtered.
If the target device responds quickly, emptying the FIFO at the end of
the transmission can erase not only the echo characters but also part of
the response message.
By keeping the receive interrupt enabled even during transmission, it
allows you to filter each echo character and only in a number equal to
those transmitted.
The issue was generated by a target device that started responding
240us later having received a request in communication at 115200bps.
Sometimes, some messages received by the target were missing some of the
first bytes.
Fixes: 3a13884abea0 ("tty/serial: omap: empty the RX FIFO at the end of
half-duplex TX")
Signed-off-by: Dario Binacchi
---
Changes in v4:
- Change the type of the rs485_tx_filter_count variable from atomic_t
to unsigned int and related read / write accesses.
Changes in v3:
- Add 'Fixes' tag
Changes in v2:
- Fix compiling error
drivers/tty/serial/omap-serial.c | 39
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 76b94d0ff586..f8fafceb5803 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -159,6 +159,8 @@ struct uart_omap_port {
u32 calc_latency;
struct work_struct qos_work;
boolis_suspending;
+
+ unsigned intrs485_tx_filter_count;
};
#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
@@ -328,19 +330,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
- if ((port->rs485.flags & SER_RS485_ENABLED) &&
- !(port->rs485.flags & SER_RS485_RX_DURING_TX)) {
- /*
-* Empty the RX FIFO, we are not interested in anything
-* received during the half-duplex transmission.
-*/
- serial_out(up, UART_FCR, up->fcr | UART_FCR_CLEAR_RCVR);
- /* Re-enable RX interrupts */
- up->ier |= UART_IER_RLSI | UART_IER_RDI;
- up->port.read_status_mask |= UART_LSR_DR;
- serial_out(up, UART_IER, up->ier);
- }
-
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
}
@@ -366,6 +355,10 @@ static void transmit_chars(struct uart_omap_port *up,
unsigned int lsr)
serial_out(up, UART_TX, up->port.x_char);
up->port.icount.tx++;
up->port.x_char = 0;
+ if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
+ !(up->port.rs485.flags & SER_RS485_RX_DURING_TX))
+ up->rs485_tx_filter_count++;
+
return;
}
if (uart_circ_empty(xmit) || uart_tx_stopped(&up->port)) {
@@ -377,6 +370,10 @@ static void transmit_chars(struct uart_omap_port *up,
unsigned int lsr)
serial_out(up, UART_TX, xmit->buf[xmit->tail]);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
up->port.icount.tx++;
+ if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
+ !(up->port.rs485.flags & SER_RS485_RX_DURING_TX))
+ up->rs485_tx_filter_count++;
+
if (uart_circ_empty(xmit))
break;
} while (--count > 0);
@@ -420,7 +417,7 @@ static void serial_omap_start_tx(struct uart_port *port)
if ((port->rs485.flags & SER_RS485_ENABLED) &&
!(port->rs485.flags & SER_RS485_RX_DURING_TX))
- serial_omap_stop_rx(port);
+ up->rs485_tx_filter_count = 0;
serial_omap_enable_ier_thri(up);
pm_runtime_mark_last_busy(up->dev);
@@ -491,8 +488,13 @@ static void serial_omap_rlsi(struct uart_omap_port *up,
unsigned int lsr)
* Read one data character out to avoid stalling the receiver according
* to the table 23-246 of the omap4 TRM.
*/
- if (likely(lsr & UART_LSR_DR))
+ if (likely(lsr & UART_LSR_DR)) {
serial_in(up, UART_RX);
+ if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
+ !(up->port.rs485.flags & SER_RS485_RX_DURING_TX) &&
+ up->rs485_tx_filter_count)
+ up->rs485_tx_filter_count--;
+ }
up->port.icount.rx++;
flag = TTY_NORMAL;
@@ -543,6 +545,13 @@ static void serial_omap_rdi(struct uart_omap_port *up,
unsigned int lsr)
return;
ch = serial_in(up, UART_RX);
+ if ((up->port.rs485.flags & SER_RS485_ENABLED) &&
+ !(up->port.rs485.flags & SER_RS485_RX_DURING_TX) &&
+ up->rs485_tx_filter_count) {
+ up->rs485_tx_filter_count--;
+ return;
+ }
+
flag = TTY_NORMAL;
up->port.icount.rx++;
--
Re: [PATCH v4 2/2] iio: temperature: add driver support for ti tmp117
On Sun, 11 Apr 2021 21:08:29 +0300 Andy Shevchenko wrote: > On Sun, Apr 11, 2021 at 9:07 PM Andy Shevchenko > wrote: > > On Sun, Apr 11, 2021 at 5:53 PM Jonathan Cameron wrote: > > > On Wed, 7 Apr 2021 23:51:47 +0530 > > > Puranjay Mohan wrote: > > > Good point, but better is to use clamp_t(s16, ...) rather than explicit > > casting. > > Sorry, I meant clamp_t(int, ...) of course, otherwise it will give wrong > values. I've switched it over to this which is indeed nicer. Jonathan > > > I always consider explicit casting in C (and esp. in Linux kernel) is > > a red flag. Should be really rarely needed. > > >
Re: [RFC V2 PATCH 11/12] HV/Netvsc: Add Isolation VM support for netvsc driver
On Tue, Apr 13, 2021 at 11:22:16AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> pagebuffer() still need to handle. Use DMA API to map/umap these
> memory during sending/receiving packet and Hyper-V DMA ops callback
> will use swiotlb fucntion to allocate bounce buffer and copy data
> from/to bounce buffer.
>
> Signed-off-by: Tianyu Lan
> ---
> drivers/net/hyperv/hyperv_net.h | 11 +++
> drivers/net/hyperv/netvsc.c | 137 --
> drivers/net/hyperv/rndis_filter.c | 3 +
> 3 files changed, 144 insertions(+), 7 deletions(-)
<...>
> + packet->dma_range = kzalloc(sizeof(struct dma_range) * page_count,
> + GFP_KERNEL);
> + if (!packet->dma_range)
> + return -ENOMEM;
> +
> + for (i = 0; i < page_count; i++) {
> + char *src = phys_to_virt((pb[i].pfn << HV_HYP_PAGE_SHIFT)
> + + pb[i].offset);
> + u32 len = pb[i].len;
> +
> + dma = dma_map_single(&hv_dev->device, src, len,
> + DMA_TO_DEVICE);
> + if (dma_mapping_error(&hv_dev->device, dma))
> + return -ENOMEM;
Don't you leak dma_range here?
BTW, It will be easier if you CC all on all patches, so we will be able
to get whole context.
Thanks
Re: [PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Fri, 16 Apr 2021 15:21:14 +0300 Tomas Melin wrote: > Updated email-address for Alexandru. > > > On 4/16/21 3:17 PM, Tomas Melin wrote: > > On 4/15/21 11:41 AM, Tomas Melin wrote: > > > >> > >> While working on updates I did notice something new which I cannot > >> > >> reproduce on older (5.10.17 kernel) version. If compiling this as a > >> module, getting error while > >> > >> unloading module: > >> > >> [ 40.200084] Unable to handle kernel NULL pointer dereference at > >> virtual address 0104 > >> ... > >> > >> [ 40.510054] Backtrace: > >> [ 40.512502] [] (iio_device_ioctl_handler_unregister) > >> from [] (iio_buffers_free_sysfs_and_mask+0x2c/0x6c) > >> [ 40.523735] [] (iio_buffers_free_sysfs_and_mask) from > >> [] (iio_device_unregister+0xa8/0xac) > >> [ 40.533746] r5:c1811228 r4:c1811000 > >> [ 40.537318] [] (iio_device_unregister) from [] > >> (devm_iio_device_unreg+0x1c/0x20) > >> [ 40.546461] r5:c2415000 r4:c25bab80 > >> [ 40.550025] [] (devm_iio_device_unreg) from [] > >> (release_nodes+0x1c0/0x1f0) > >> [ 40.558654] [] (release_nodes) from [] > >> (devres_release_all+0x40/0x60) > >> [ 40.566847] r10:0081 r9:c235 r8:c0100264 r7:0081 > >> r6:bf00c010 r5:c19be000 > >> [ 40.574669] r4:c1a91c00 > >> [ 40.577194] [] (devres_release_all) from [] > >> (device_release_driver_internal+0x120/0x1cc) > >> [ 40.587031] r5:c19be000 r4:c1a91c00 > >> [ 40.590596] [] (device_release_driver_internal) from > >> [] (driver_detach+0x54/0x90) > >> [ 40.599828] r7:0081 r6: r5:bf00c010 r4:c1a91c00 > >> [ 40.605482] [] (driver_detach) from [] > >> (bus_remove_driver+0x5c/0xb0) > >> [ 40.613583] r5:0800 r4:bf00c010 > >> [ 40.617148] [] (bus_remove_driver) from [] > >> (driver_unregister+0x38/0x5c) > >> [ 40.625596] r5:0800 r4:bf00c010 > >> [ 40.629161] [] (driver_unregister) from [] > >> (sca3300_driver_exit+0x14/0x8b4 [sca3300]) > >> [ 40.638747] r5:0800 r4:bf00c080 > >> [ 40.642311] [] (sca3300_driver_exit [sca3300]) from > >> [] (sys_delete_module+0x16c/0x238) > >> [ 40.651990] [] (sys_delete_module) from [] > >> (__sys_trace_return+0x0/0x1c) > >> [ 40.660435] Exception stack(0xc2351fa8 to 0xc2351ff0) > >> [ 40.665484] 1fa0: 0050e5a8 0050e5e4 > >> 0800 081d4b00 bec18af4 > >> [ 40.673661] 1fc0: 0050e5a8 bec18b50 0081 bec18e51 > >> 0050e190 0001 bec18d3c > >> [ 40.681834] 1fe0: 0050cf70 bec18afc 004f1ec8 b6ecb27c > >> [ 40.686887] r6:bec18b50 r5: r4:0050e5a8 > >> [ 40.691507] Code: e8bd4000 e1c020d0 e3a0cc01 e3001122 (e5823004) > >> [ 40.707675] ---[ end trace 189882b050077333 ]--- > >> > >> This happens when building against linux-next > >> 5.12.0-rc6-next-20210409. I'm failing to see what is wrong. Any ideas? > >> > >> Thanks, > >> > >> Tomas > > > > > > Tested further that for this driver, loading and unloading as module > > works fine until commit: > > > > commit f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 > > Author: Alexandru Ardelean > > Date: Mon Feb 15 12:40:39 2021 +0200 > > > > iio: buffer: add ioctl() to support opening extra buffers for IIO > > device > > > > > > Any thoughts what causes this issue? Is this still happening after fixing the ordering in probe / remove? (devm_iio_triggered_buffer_setup() being easiest way) As driver currently stands it's calling iio_triggered_buffer_cleanup before the managed cleanup of the iio_device_register() call. That should never happen so would be where I'd look for problems here. It is possible Alex's work is relying on that ordering being correct a little more than we previously were. I could be wrong though and could be something else going on! Jonathan +CC Alex's other email address. > > > > Thanks, > > > > Tomas > > > > > > > >> > >> > >>> > --- > drivers/iio/accel/Kconfig | 13 ++ > drivers/iio/accel/Makefile | 1 + > drivers/iio/accel/sca3300.c | 434 > > 3 files changed, 448 insertions(+) > create mode 100644 drivers/iio/accel/sca3300.c > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > index cceda3cecbcf..0dbf7b648e8a 100644 > --- a/drivers/iio/accel/Kconfig > +++ b/drivers/iio/accel/Kconfig > @@ -450,6 +450,19 @@ config SCA3000 > To compile this driver as a module, say M here: the module > will be > called sca3000. > +config SCA3300 > + tristate "Murata SCA3300 3-Axis Accelerometer Driver" > + depends on SPI > + select CRC8 > + select IIO_BUFFER > + select IIO_TRIGGERED_BUFFER > + help > + Say yes here to build support for Murata SCA3300 3-Axis > + accelerometer. > + > + To compile this driver as a module, choose M here: the > module will be > + called sca3300. > + > con
Re: [PATCH v2 1/1] iio: adc: ad7298: Enable on Intel Galileo Gen 1
On Mon, 12 Apr 2021 16:18:35 +0300
Andy Shevchenko wrote:
> Enable ADC on Intel Galileo Gen 1 board.
>
> Signed-off-by: Andy Shevchenko
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to hopefully not notice we did anything ;)
Jonathan
> ---
> v2: fixed typo in ID
> drivers/iio/adc/ad7298.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/ad7298.c b/drivers/iio/adc/ad7298.c
> index 689ecd5dd563..e7e866433090 100644
> --- a/drivers/iio/adc/ad7298.c
> +++ b/drivers/iio/adc/ad7298.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -352,6 +353,12 @@ static int ad7298_probe(struct spi_device *spi)
> return devm_iio_device_register(&spi->dev, indio_dev);
> }
>
> +static const struct acpi_device_id ad7298_acpi_ids[] = {
> + { "INT3494", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, ad7298_acpi_ids);
> +
> static const struct spi_device_id ad7298_id[] = {
> {"ad7298", 0},
> {}
> @@ -361,6 +368,7 @@ MODULE_DEVICE_TABLE(spi, ad7298_id);
> static struct spi_driver ad7298_driver = {
> .driver = {
> .name = "ad7298",
> + .acpi_match_table = ad7298_acpi_ids,
> },
> .probe = ad7298_probe,
> .id_table = ad7298_id,
BUSINESS PROPOSAL
-- Hello, Can I write you here? I have an urgent proposal for you. Regards, General Director, Zanina Ivanovna Lyubova LLC "PUBLISHING HOUSE" OIL AND GAS ™ 119991, Moscow, Leninskiy Avenue 65, bldg 4, office 1706. E-mail: i...@pliable-oil-gas.ru Skype: zaninaivanovna OGRN: 5067746402610 / TIN:7736545221
Re: [PATCH] iio: hid-sensors: select IIO_TRIGGERED_BUFFER under HID_SENSOR_IIO_TRIGGER
On Thu, 15 Apr 2021 09:58:33 -0700
Srinivas Pandruvada wrote:
> On Wed, 2021-04-14 at 11:49 +0300, Alexandru Ardelean wrote:
> > During commit 067fda1c065ff ("iio: hid-sensors: move triggered buffer
> > setup into hid_sensor_setup_trigger"), the
> > iio_triggered_buffer_{setup,cleanup}() functions got moved under the
> > hid-sensor-trigger module.
> >
> > The above change works fine, if any of the sensors get built.
> > However, when
> > only the common hid-sensor-trigger module gets built (and none of the
> > drivers), then the IIO_TRIGGERED_BUFFER symbol isn't
> > selected/enforced.
> >
> > Previously, each driver would enforce/select the IIO_TRIGGERED_BUFFER
> > symbol. With this change the HID_SENSOR_IIO_TRIGGER (for the
> > hid-sensor-trigger module) will enforce that IIO_TRIGGERED_BUFFER
> > gets
> > selected.
> >
> > All HID sensor drivers select the HID_SENSOR_IIO_TRIGGER symbol. So,
> > this
> > change removes the IIO_TRIGGERED_BUFFER enforcement from each driver.
> >
> > Fixes: 067fda1c065ff ("iio: hid-sensors: move triggered buffer setup
> > into hid_sensor_setup_trigger")
> > Reported-by: Thomas Deutschmann
> > Cc: Srinivas Pandruvada
> > Signed-off-by: Alexandru Ardelean
> Acked-by: Srinivas Pandruvada
Applied to the fixes-togreg branch of iio.git.
Always good to see the autobuilders can find corners no one sane would ever
hit :)
Jonathan
>
> > ---
> > drivers/iio/accel/Kconfig | 1 -
> > drivers/iio/common/hid-sensors/Kconfig | 1 +
> > drivers/iio/gyro/Kconfig | 1 -
> > drivers/iio/humidity/Kconfig | 1 -
> > drivers/iio/light/Kconfig | 2 --
> > drivers/iio/magnetometer/Kconfig | 1 -
> > drivers/iio/orientation/Kconfig| 2 --
> > drivers/iio/pressure/Kconfig | 1 -
> > drivers/iio/temperature/Kconfig| 1 -
> > 9 files changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> > index cceda3cecbcf..8b1723635cce 100644
> > --- a/drivers/iio/accel/Kconfig
> > +++ b/drivers/iio/accel/Kconfig
> > @@ -229,7 +229,6 @@ config DMARD10
> > config HID_SENSOR_ACCEL_3D
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID Accelerometers 3D"
> > diff --git a/drivers/iio/common/hid-sensors/Kconfig
> > b/drivers/iio/common/hid-sensors/Kconfig
> > index 24d492567336..2a3dd3b907be 100644
> > --- a/drivers/iio/common/hid-sensors/Kconfig
> > +++ b/drivers/iio/common/hid-sensors/Kconfig
> > @@ -19,6 +19,7 @@ config HID_SENSOR_IIO_TRIGGER
> > tristate "Common module (trigger) for all HID Sensor IIO
> > drivers"
> > depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON &&
> > IIO_BUFFER
> > select IIO_TRIGGER
> > + select IIO_TRIGGERED_BUFFER
> > help
> > Say yes here to build trigger support for HID sensors.
> > Triggers will be send if all requested attributes were read.
> > diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig
> > index 5824f2edf975..20b5ac7ab66a 100644
> > --- a/drivers/iio/gyro/Kconfig
> > +++ b/drivers/iio/gyro/Kconfig
> > @@ -111,7 +111,6 @@ config FXAS21002C_SPI
> > config HID_SENSOR_GYRO_3D
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID Gyroscope 3D"
> > diff --git a/drivers/iio/humidity/Kconfig
> > b/drivers/iio/humidity/Kconfig
> > index 6549fcf6db69..2de5494e7c22 100644
> > --- a/drivers/iio/humidity/Kconfig
> > +++ b/drivers/iio/humidity/Kconfig
> > @@ -52,7 +52,6 @@ config HID_SENSOR_HUMIDITY
> > tristate "HID Environmental humidity sensor"
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > help
> > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> > index 33ad4dd0b5c7..917f9becf9c7 100644
> > --- a/drivers/iio/light/Kconfig
> > +++ b/drivers/iio/light/Kconfig
> > @@ -256,7 +256,6 @@ config ISL29125
> > config HID_SENSOR_ALS
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID ALS"
> > @@ -270,7 +269,6 @@ config HID_SENSOR_ALS
> > config HID_SENSOR_PROX
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID PROX"
> > diff --git a/drivers/iio/magnetometer/Kconfig
> > b/drivers/iio/magnetometer/Kconfig
> > index 5d4ffd66032e..74ad5701c6c2 100644
> > --- a/drivers/iio/magnetometer/Kconfig
> > +++ b/drivers/iio/magnetometer/Kconfig
> > @@ -95,7 +95,6 @@ config MAG3110
> > config HID_SEN
[PATCH] fs/ext4: prevent the CPU from being 100% occupied in ext4_mb_discard_group_preallocations
The kworker has occupied 100% of the CPU for several days: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 68086 root 20 0 00 0 R 100.0 0.0 9718:18 kworker/u64:11 And the stack obtained through sysrq is as follows: [20613144.850426] task: 8800b5e08000 task.stack: c9001342c000 [20613144.850427] RIP: 0010:[] ^Ac [] ext4_mb_discard_group_preallocations+0x1b3/0x480 [ext4] ... [20613144.850435] Stack: [20613144.850435] 881942d6a6e8^Ac 8813bb5f72d0^Ac 0001a02427cf^Ac 0140^Ac [20613144.850436] 880f80618000^Ac ^Ac c9001342f770^Ac c9001342f770^Ac [20613144.850437] ea0056360dc0^Ac 88158d837000^Ac ea0045155f80^Ac 88114557e000^Ac [20613144.850438] Call Trace: [20613144.850439] [] ext4_mb_new_blocks+0x429/0x550 [ext4] [20613144.850439] [] ext4_ext_map_blocks+0xb5e/0xf30 [ext4] [20613144.850440] [] ? numa_zonelist_order_handler+0xa1/0x1c0 [20613144.850441] [] ext4_map_blocks+0x172/0x620 [ext4] [20613144.850441] [] ? ext4_writepages+0x4cd/0xf00 [ext4] [20613144.850442] [] ext4_writepages+0x7e5/0xf00 [ext4] [20613144.850442] [] ? wb_position_ratio+0x1f0/0x1f0 [20613144.850443] [] do_writepages+0x1e/0x30 [20613144.850444] [] __writeback_single_inode+0x45/0x320 [20613144.850444] [] writeback_sb_inodes+0x272/0x600 [20613144.850445] [] __writeback_inodes_wb+0x92/0xc0 [20613144.850445] [] wb_writeback+0x268/0x300 [20613144.850446] [] wb_workfn+0xb4/0x380 [20613144.850447] [] process_one_work+0x189/0x420 [20613144.850447] [] worker_thread+0x4e/0x4b0 [20613144.850448] [] ? process_one_work+0x420/0x420 [20613144.850448] [] kthread+0xe6/0x100 [20613144.850449] [] ? kthread_park+0x60/0x60 [20613144.850450] [] ret_from_fork+0x39/0x50 The thread that references this pa has been waiting for IO to return: PID: 15140 TASK: 88004d6dc300 CPU: 16 COMMAND: "kworker/u64:1" [c900273e7518] __schedule at 8173ca3b [c900273e75a0] schedule at 8173cfb6 [c900273e75b8] io_schedule at 810bb75a [c900273e75e0] bit_wait_io at 8173d8d1 [c900273e75f8] __wait_on_bit_lock at 8173d4e9 [c900273e7638] out_of_line_wait_on_bit_lock at 8173d742 [c900273e76b0] __lock_buffer at 81288c32 [c900273e76c8] do_get_write_access at a00dd177 [jbd2] [c900273e7728] jbd2_journal_get_write_access at a00dd3a3 [jbd2] [c900273e7750] __ext4_journal_get_write_access at a023b37b [ext4] [c900273e7788] ext4_mb_mark_diskspace_used at a0242a0b [ext4] [c900273e77f0] ext4_mb_new_blocks at a0244100 [ext4] [c900273e7860] ext4_ext_map_blocks at a02389ae [ext4] [c900273e7950] ext4_map_blocks at a0204b52 [ext4] [c900273e79d0] ext4_writepages at a0208675 [ext4] [c900273e7b30] do_writepages at 811c487e [c900273e7b40] __writeback_single_inode at 81280265 [c900273e7b90] writeback_sb_inodes at 81280ab2 [c900273e7c90] __writeback_inodes_wb at 81280ed2 [c900273e7cd8] wb_writeback at 81281238 [c900273e7d80] wb_workfn at 812819f4 [c900273e7e18] process_one_work at 810a5dc9 [c900273e7e60] worker_thread at 810a60ae [c900273e7ec0] kthread at 810ac696 [c900273e7f50] ret_from_fork at 81741dd9 On the bare metal server, we will use multiple hard disks, the Linux kernel will run on the system disk, and business programs will run on several hard disks virtualized by the BM hypervisor. The reason why IO has not returned here is that the process handling IO in the BM hypervisor has failed. The cpu resources of the cloud server are precious, and the server cannot be restarted after running for a long time. So it's slightly optimized here to prevent the CPU from being 100% occupied. Signed-off-by: Wen Yang Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc: Ritesh Harjani Cc: Baoyou Xie Cc: linux-e...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- fs/ext4/mballoc.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index a02fadf..c73f212 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -351,6 +351,8 @@ static void ext4_mb_generate_from_freelist(struct super_block *sb, void *bitmap, ext4_group_t group); static void ext4_mb_new_preallocation(struct ext4_allocation_context *ac); +static inline void ext4_mb_show_pa(struct super_block *sb); + /* * The algorithm using this percpu seq counter goes below: * 1. We sample the percpu discard_pa_seq counter before trying for block @@ -4217,9 +4219,9 @@ static void ext4_mb_new_preallocation(struct ext4_allocation_context *ac) struct ext4_prealloc_space *pa, *tmp; struct list_head list; struct ext4_buddy e4b; + int free_total = 0; + int busy, free; int err; - int busy =
[PATCH] media: rkisp1: rksip1-capture.c: Improve comments and fix typos
Improve the wording of the function description to increase readability.
Fix three typos:
s/during processing a frame/while processing a frame/
s/it also update/it also updates/
s/there's not buf in shadow/there's no buffer in a shadow register/
Replace the abbreviation 'buf' with the full word buffer, the
abbreviation 'config' with the verb configure, and 'regs' with registers.
The goal of this change is to ease the reading flow of the comment.
Signed-off-by: Sebastian Fricke
---
Side-note:
I also believe there should be a description for the abbreviation FE, as
it is not described anywhere. I think it means frame end, right?.
---
.../platform/rockchip/rkisp1/rkisp1-capture.c| 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 5f6c9d1623e4..9643bdd05b7b 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -830,8 +830,8 @@ static void rkisp1_return_all_buffers(struct rkisp1_capture
*cap,
}
/*
- * Most of registers inside rockchip ISP1 have shadow register since
- * they must be not be changed during processing a frame.
+ * Most registers inside the rockchip ISP1 have shadow register since
+ * they must not be changed while processing a frame.
* Usually, each sub-module updates its shadow register after
* processing the last pixel of a frame.
*/
@@ -847,14 +847,14 @@ static void rkisp1_cap_stream_enable(struct
rkisp1_capture *cap)
spin_lock_irq(&cap->buf.lock);
rkisp1_set_next_buf(cap);
cap->ops->enable(cap);
- /* It's safe to config ACTIVE and SHADOW regs for the
+ /* It's safe to configure ACTIVE and SHADOW registers for the
* first stream. While when the second is starting, do NOT
-* force update because it also update the first one.
+* force update because it also updates the first one.
*
-* The latter case would drop one more buf(that is 2) since
-* there's not buf in shadow when the second FE received. This's
-* also required because the second FE maybe corrupt especially
-* when run at 120fps.
+* The latter case would drop one more buffer(that is 2) since
+* there's no buffer in a shadow register when the second FE received.
+* This's also required because the second FE maybe corrupt
+* especially when run at 120fps.
*/
if (!other->is_streaming) {
/* force cfg update */
--
2.25.1
Re: mmu.c:undefined reference to `patch__hash_page_A0'
Le 18/04/2021 à 02:02, Randy Dunlap a écrit : HI-- I no longer see this build error. Fixed by https://github.com/torvalds/linux/commit/acdad8fb4a1574323db88f98a38b630691574e16 However: On 2/27/21 2:24 AM, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3fb6d0e00efc958d01c2f109c8453033a2d96796 commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash code when CONFIG_PPC_BOOK3S_604 is selected date: 4 weeks ago config: powerpc64-randconfig-r013-20210227 (attached as .config) ktr/lkp, this is a PPC32 .config file that is attached, not PPC64. Also: compiler: powerpc-linux-gcc (GCC) 9.3.0 ... I do see this build error: powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress': decompress.c:(.text+0x1f0): undefined reference to `__decompress' when either CONFIG_KERNEL_LZO=y or CONFIG_KERNEL_LZMA=y but the build succeeds when either CONFIG_KERNEL_GZIP=y or CONFIG_KERNEL_XZ=y I guess that is due to arch/powerpc/boot/decompress.c doing this: #ifdef CONFIG_KERNEL_GZIP # include "decompress_inflate.c" #endif #ifdef CONFIG_KERNEL_XZ # include "xz_config.h" # include "../../../lib/decompress_unxz.c" #endif It would be nice to require one of KERNEL_GZIP or KERNEL_XZ to be set/enabled (maybe unless a uImage is being built?). Can you test by https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a74fce4dfc9fa32da6ce3470bbedcecf795de1ec.1591189069.git.christophe.le...@csgroup.eu/ ? Thanks Christophe
Re: [PATCH v1 4/7] iio: st_sensors: Call st_sensors_power_enable() from bus drivers
On Wed, 14 Apr 2021 22:54:51 +0300
Andy Shevchenko wrote:
> In case we would initialize two IIO devices from one physical device,
> we shouldn't have a clash on regulators. That's why move
> st_sensors_power_enable() call from core to bus drivers.
Why is this a problem? The two instances would double up and both get +
enable + disable the regulators. However, that shouldn't matter as
they are reference counted anyway.
Perhaps an example? Even in patch 6 I can only see that it is wasteful
to do it twice, rather than wrong as such.
Jonathan
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/iio/accel/st_accel_core.c | 21 +
> drivers/iio/accel/st_accel_i2c.c| 17 +++--
> drivers/iio/accel/st_accel_spi.c| 17 +++--
> drivers/iio/gyro/st_gyro_core.c | 15 +++
> drivers/iio/gyro/st_gyro_i2c.c | 17 +++--
> drivers/iio/gyro/st_gyro_spi.c | 17 +++--
> drivers/iio/magnetometer/st_magn_core.c | 15 +++
> drivers/iio/magnetometer/st_magn_i2c.c | 14 +-
> drivers/iio/magnetometer/st_magn_spi.c | 14 +-
> drivers/iio/pressure/st_pressure_core.c | 15 +++
> drivers/iio/pressure/st_pressure_i2c.c | 17 +++--
> drivers/iio/pressure/st_pressure_spi.c | 17 +++--
> 12 files changed, 130 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/iio/accel/st_accel_core.c
> b/drivers/iio/accel/st_accel_core.c
> index a1bd7e3b912e..5c258c1ca62d 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -1260,13 +1260,9 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = &accel_info;
>
> - err = st_sensors_power_enable(indio_dev);
> - if (err)
> - return err;
> -
> err = st_sensors_verify_id(indio_dev);
> if (err < 0)
> - goto st_accel_power_off;
> + return err;
>
> adata->num_data_channels = ST_ACCEL_NUMBER_DATA_CHANNELS;
> indio_dev->num_channels = ST_SENSORS_NUMBER_ALL_CHANNELS;
> @@ -1275,10 +1271,8 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
> channels = devm_kmemdup(&indio_dev->dev,
> adata->sensor_settings->ch,
> channels_size, GFP_KERNEL);
> - if (!channels) {
> - err = -ENOMEM;
> - goto st_accel_power_off;
> - }
> + if (!channels)
> + return -ENOMEM;
>
> if (apply_acpi_orientation(indio_dev, channels))
> dev_warn(&indio_dev->dev,
> @@ -1293,11 +1287,11 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
>
> err = st_sensors_init_sensor(indio_dev, pdata);
> if (err < 0)
> - goto st_accel_power_off;
> + return err;
>
> err = st_accel_allocate_ring(indio_dev);
> if (err < 0)
> - goto st_accel_power_off;
> + return err;
>
> if (adata->irq > 0) {
> err = st_sensors_allocate_trigger(indio_dev,
> @@ -1320,9 +1314,6 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
> st_sensors_deallocate_trigger(indio_dev);
> st_accel_probe_trigger_error:
> st_accel_deallocate_ring(indio_dev);
> -st_accel_power_off:
> - st_sensors_power_disable(indio_dev);
> -
> return err;
> }
> EXPORT_SYMBOL(st_accel_common_probe);
> @@ -1331,8 +1322,6 @@ void st_accel_common_remove(struct iio_dev *indio_dev)
> {
> struct st_sensor_data *adata = iio_priv(indio_dev);
>
> - st_sensors_power_disable(indio_dev);
> -
> iio_device_unregister(indio_dev);
> if (adata->irq > 0)
> st_sensors_deallocate_trigger(indio_dev);
> diff --git a/drivers/iio/accel/st_accel_i2c.c
> b/drivers/iio/accel/st_accel_i2c.c
> index 360e16f2cadb..95e305b88d5e 100644
> --- a/drivers/iio/accel/st_accel_i2c.c
> +++ b/drivers/iio/accel/st_accel_i2c.c
> @@ -174,16 +174,29 @@ static int st_accel_i2c_probe(struct i2c_client *client)
> if (ret < 0)
> return ret;
>
> + ret = st_sensors_power_enable(indio_dev);
> + if (ret)
> + return ret;
> +
> ret = st_accel_common_probe(indio_dev);
> if (ret < 0)
> - return ret;
> + goto st_accel_power_off;
>
> return 0;
> +
> +st_accel_power_off:
> + st_sensors_power_disable(indio_dev);
> +
> + return ret;
> }
>
> static int st_accel_i2c_remove(struct i2c_client *client)
> {
> - st_accel_common_remove(i2c_get_clientdata(client));
> + struct iio_dev *indio_dev = i2c_get_clientdata(client);
> +
> + st_sensors_power_disable(indio_dev);
> +
> + st_accel_common_remove(indio_dev);
>
> return 0;
> }
> diff --git a/drivers/iio/accel/st_accel_spi.c
> b/drivers/iio/accel/st_accel_spi.c
> index 568ff1bae0ee..83d3308ce5cc 100644
>
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Wed, 14 Apr 2021 22:54:53 +0300
Andy Shevchenko wrote:
> We can utilize separate drivers for accelerometer and magnetometer,
> so here is the glue driver to enable LSM9DS0 IMU support.
>
> The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
> was sent as RFC due to race condition concerns, which are indeed possible.
If you are going to mention races, good to give some flavour in here!
This driver makes me very nervous indeed. I haven't 'found' any places
where the fact we'll write the same registers from each of the drivers
causes problems (e.g. int pin setup etc) but perhaps I'm missing something.
Shall we say that makes me rather keener to get eyes (and thought) on this
patch than normal :)
>
> In order to amend the initial change, I went further by providing a specific
> multi-instantiate probe driver that reuses existing accelerometer and
> magnetometer.
>
> [1]: https://lore.kernel.org/patchwork/patch/670353/
>
> Suggested-by: Crestez Dan Leonard
> Cc: mr.laho...@laposte.net
> Cc: Matija Podravec
> Cc: Sergey Borishchenko
> Signed-off-by: Andy Shevchenko
A few comments in here, though mostly about stuff related to the origin code
you are copying so perhaps not tidying them up is preferable because it would
complicate comparison of the two cases.
> ---
> drivers/iio/accel/st_accel_core.c| 89 +-
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/Makefile | 1 +
> drivers/iio/imu/st_lsm9ds0/Kconfig | 28
> drivers/iio/imu/st_lsm9ds0/Makefile | 5 +
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h | 23 +++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c | 163 +++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c | 84 ++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c | 83 ++
> drivers/iio/magnetometer/st_magn_core.c | 98 +++
> include/linux/iio/common/st_sensors.h| 2 +
> 11 files changed, 576 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/imu/st_lsm9ds0/Kconfig
> create mode 100644 drivers/iio/imu/st_lsm9ds0/Makefile
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c
>
> diff --git a/drivers/iio/accel/st_accel_core.c
> b/drivers/iio/accel/st_accel_core.c
> index 5c258c1ca62d..dc32ebefe3fc 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -980,7 +980,94 @@ static const struct st_sensor_settings
> st_accel_sensors_settings[] = {
> .multi_read_bit = true,
> .bootime = 2,
> },
> -
> + {
> + .wai = 0x49,
> + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS,
> + .sensors_supported = {
> + [0] = LSM9DS0_IMU_DEV_NAME,
What does the name attribute report for these?
Previously we've had the _accel etc postfix to differentiate the devices. I
don't
suppose it matters to much though as easy enough to identify the accelerometer
etc from what channels are present.
Of course driver may get name from somewhere different anyway, I haven't
checked,
just noticed this was different and wondered what the affect might be.
>
> /* Default accel DRDY is available on INT1 pin */
> diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> index f02883b08480..001ca2c3ff95 100644
> --- a/drivers/iio/imu/Kconfig
> +++ b/drivers/iio/imu/Kconfig
> @@ -94,6 +94,7 @@ config KMX61
> source "drivers/iio/imu/inv_icm42600/Kconfig"
> source "drivers/iio/imu/inv_mpu6050/Kconfig"
> source "drivers/iio/imu/st_lsm6dsx/Kconfig"
> +source "drivers/iio/imu/st_lsm9ds0/Kconfig"
>
> endmenu
>
> diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
> index 13e9ff442b11..c82748096c77 100644
> --- a/drivers/iio/imu/Makefile
> +++ b/drivers/iio/imu/Makefile
> @@ -26,3 +26,4 @@ obj-y += inv_mpu6050/
> obj-$(CONFIG_KMX61) += kmx61.o
>
> obj-y += st_lsm6dsx/
> +obj-y += st_lsm9ds0/
> diff --git a/drivers/iio/imu/st_lsm9ds0/Kconfig
> b/drivers/iio/imu/st_lsm9ds0/Kconfig
> new file mode 100644
> index ..53b7017014f8
> --- /dev/null
> +++ b/drivers/iio/imu/st_lsm9ds0/Kconfig
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config IIO_ST_LSM9DS0
> + tristate "STMicroelectronics LSM9DS0 IMU driver"
> + depends on (I2C || SPI_MASTER) && SYSFS
> + depends on !SENSORS_LIS3_I2C
> + depends on !SENSORS_LIS3_SPI
> + select IIO_ST_LSM9DS0_I2C if I2C
> + select IIO_ST_LSM9DS0_SPI if SPI_MASTER
> + select IIO_ST_ACCEL_3AXIS
> + select IIO_ST_MAGN_3AXIS
> +
> + help
> + Say yes here to build support for STMicroelectronics LSM9DS0 IMU
> + sensor. Supported devices: accelerometer/magnetometer of lsm9ds0.
> +
>
Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hi Uwe, On Sat, Apr 17, 2021 at 05:50:09PM +0200, Uwe Kleine-König wrote: > Hello Nobuhiro, > > On Fri, Apr 16, 2021 at 09:15:23PM +0900, Nobuhiro Iwamatsu wrote: > > > > > For me the critical (and only) difference between "off" and > > > > > "duty cycle = 0" is that when a new configuration is to be applied. In > > > > > the "off" state a new period can (and should) start immediately, while > > > > > with "duty_cycle = 0" the rising edge should be delayed until the > > > > > currently running period is over.[1] > > > > > > > > > > So the thing to do here (IMHO) is: > > > > > > > > > > Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized > > > > > with writing a non-zero value to PIPGM_PCSR) completes the currently > > > > > running period, then always assume the PWM as enabled. > > > > > > > > Yes, this device works that way. > > > > > > OK, then please use > > > > > > state->enabled = true > > > > > > unconditionally in visconti_pwm_get_state(). > > > > Please let me check. > > If I unconditionally add 'state->enabled = true' to > > visconti_pwm_get_state(), > > state->enabled is set to true because visconti_pwm_get_state() is called > > when > > the device is created (this is when I write the device number to the export > > of > > /sys/class/pwm/pwmchip0 ). > > And since PIPGM_PCSR is 0 in this state, the pulse by PWM is not output. > > A PWM that is currently configured with .enabled = true and .duty_cycle > = 0 doesn't have a pulse, so this is fine. > I understood, thanks. > > However, I think this means that the device is working as this driver. > > I don't understand this sentence. The description of the struct pwm_state says "PWM enabled status". I thought 'state-> enabled' would hold the working state of the hardware. > > Best regards > Uwe Best regards, Nobuhiro
[PATCH v5 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hi, This series is the PWM driver for Toshiba's ARM SoC, Visconti[0]. This provides DT binding documentation and device driver. [0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html Updates: dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller v4 -> v5: - No update. v3 -> v4: - No update. v2 -> v3: - Change compatible to toshiba,visconti-pwm - Change filename to toshiba,visconti-pwm.yaml. - Add Reviewed-by tag from Rob. v1 -> v2: - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause. - Set compatible toshiba,pwm-visconti only. - Drop unnecessary comments. pwm: visconti: Add Toshiba Visconti SoC PWM support v4 -> v5: - Droped checking PIPGM_PCSR from visconti_pwm_get_state. - Changed from to_visconti_chip to visconti_pwm_from_chip. - Removed pwmchip_remove return value management. - Add limitations of this device. - Add 'state->enabled = true' to visconti_pwm_get_state(). v3 -> v4: - Sorted alphabetically include files. - Changed container_of to using static inline functions. - Dropped unnecessary dev_dbg(). - Drop Initialization of chip.base. - Drop commnet "period too small". - Rebased for-next. v2 -> v3: - Change compatible to toshiba,visconti-pwm. - Fix MODULE_ALIAS to platform:pwm-visconti, again. - Align continuation line to the opening parenthesis. - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe. v1 -> v2: - Change SPDX-License-Identifier to GPL-2.0-only. - Add prefix for the register defines. - Drop struct device from struct visconti_pwm_chip. - Use '>>' instead of '/'. - Drop error message by devm_platform_ioremap_resource(). - Use dev_err_probe instead of dev_err. - Change dev_info to dev_dbg. - Remove some empty lines. - Fix MODULE_ALIAS to platform:pwm-visconti. - Add .get_state() function. - Use the author name and email address to MODULE_AUTHOR. - Add more comment to function of the hardware. - Support .get_status() function. - Use NSEC_PER_USEC instead of 1000. - Alphabetically sorted for Makefile and Kconfig. - Added check for set value in visconti_pwm_apply(). Nobuhiro Iwamatsu (2): dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller pwm: visconti: Add Toshiba Visconti SoC PWM support .../bindings/pwm/toshiba,pwm-visconti.yaml| 43 drivers/pwm/Kconfig | 9 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-visconti.c| 188 ++ 4 files changed, 241 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml create mode 100644 drivers/pwm/pwm-visconti.c -- 2.30.0.rc2
[PATCH v5 1/2] dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
Add bindings for the Toshiba Visconti PWM Controller.
Signed-off-by: Nobuhiro Iwamatsu
Reviewed-by: Rob Herring
---
.../bindings/pwm/toshiba,pwm-visconti.yaml| 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
new file mode 100644
index ..d350f5edfb67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/toshiba,pwm-visconti.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti PWM Controller
+
+maintainers:
+ - Nobuhiro Iwamatsu
+
+properties:
+ compatible:
+items:
+ - const: toshiba,visconti-pwm
+
+ reg:
+maxItems: 1
+
+ '#pwm-cells':
+const: 2
+
+required:
+ - compatible
+ - reg
+ - '#pwm-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+pwm: pwm@241c {
+compatible = "toshiba,visconti-pwm";
+reg = <0 0x241c 0 0x1000>;
+pinctrl-names = "default";
+pinctrl-0 = <&pwm_mux>;
+#pwm-cells = <2>;
+};
+};
--
2.30.0.rc2
[PATCH v5 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Add driver for the PWM controller on Toshiba Visconti ARM SoC.
Signed-off-by: Nobuhiro Iwamatsu
---
drivers/pwm/Kconfig| 9 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-visconti.c | 188 +
3 files changed, 198 insertions(+)
create mode 100644 drivers/pwm/pwm-visconti.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 9a4f66ae8070..8ae68d6203fb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -601,6 +601,15 @@ config PWM_TWL_LED
To compile this driver as a module, choose M here: the module
will be called pwm-twl-led.
+config PWM_VISCONTI
+ tristate "Toshiba Visconti PWM support"
+ depends on ARCH_VISCONTI || COMPILE_TEST
+ help
+ PWM Subsystem driver support for Toshiba Visconti SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-visconti.
+
config PWM_VT8500
tristate "vt8500 PWM support"
depends on ARCH_VT8500 || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 6374d3b1d6f3..d43b1e17e8e1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
obj-$(CONFIG_PWM_TWL) += pwm-twl.o
obj-$(CONFIG_PWM_TWL_LED) += pwm-twl-led.o
+obj-$(CONFIG_PWM_VISCONTI) += pwm-visconti.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
new file mode 100644
index ..166b18ac1a3a
--- /dev/null
+++ b/drivers/pwm/pwm-visconti.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Toshiba Visconti pulse-width-modulation controller driver
+ *
+ * Copyright (c) 2020 TOSHIBA CORPORATION
+ * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
+ *
+ * Authors: Nobuhiro Iwamatsu
+ *
+ * Limitations:
+ * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8).
+ * - Fixed input clock running at 1 MHz.
+ * - When the settings of the PWM are modified, the new values are shadowed
+ * in hardware until the PIPGM_PCSR register is written and the currently
+ * running period is completed. This way the hardware switches atomically
+ * from the old setting to the new.
+ * - Disabling the hardware completes the currently running period and keeps
+ * the output at low level at all times.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
+#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
+#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
+
+#define PIPGM_PWMC_PWMACT BIT(5)
+#define PIPGM_PWMC_CLK_MASKGENMASK(1, 0)
+#define PIPGM_PWMC_POLARITY_MASK GENMASK(5, 5)
+
+struct visconti_pwm_chip {
+ struct pwm_chip chip;
+ void __iomem *base;
+};
+
+static inline struct visconti_pwm_chip *visconti_pwm_from_chip(struct pwm_chip
*chip)
+{
+ return container_of(chip, struct visconti_pwm_chip, chip);
+}
+
+static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct visconti_pwm_chip *priv = visconti_pwm_from_chip(chip);
+ u32 period, duty_cycle, pwmc0;
+
+ if (!state->enabled) {
+ writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
+ return 0;
+ }
+
+ /*
+* The biggest period the hardware can provide is
+* (0x << 3) * 1000 ns
+* This value fits easily in an u32, so simplify the maths by
+* capping the values to 32 bit integers.
+*/
+ if (state->period > (0x << 3) * 1000)
+ period = (0x << 3) * 1000;
+ else
+ period = state->period;
+
+ if (state->duty_cycle > period)
+ duty_cycle = period;
+ else
+ duty_cycle = state->duty_cycle;
+
+ /*
+* The input clock runs fixed at 1 MHz, so we have only
+* microsecond resolution and so can divide by
+* NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
+*/
+ period /= 1000;
+ duty_cycle /= 1000;
+
+ if (!period)
+ return -ERANGE;
+
+ /*
+* PWMC controls a divider that divides the input clk by a
+* power of two between 1 and 8. As a smaller divider yields
+* higher precision, pick the smallest possible one.
+*/
+ if (period > 0x) {
+ pwmc0 = ilog2(period >> 16);
+ BUG_ON(pwmc0 > 3);
+ } else
+ pwmc0 = 0;
+
+ period >>= pwmc0;
+ duty_cycle >>= pwmc0;
+
+ if (state->polarity == PWM_POLARITY_INVERSED)
+ pwmc0 |= PIPGM_PWMC_PWMACT;
+ writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
+ writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
+ wri
Re: [PATCH 1/2] HID: hid-sensor-hub: Return error for hid_set_field() failure
On Thu, 15 Apr 2021 11:52:31 -0700
Srinivas Pandruvada wrote:
> In the function sensor_hub_set_feature(), return error when hid_set_field()
> fails.
>
> Signed-off-by: Srinivas Pandruvada
Series applied to the to greg branch of iio.git. Note these won't make the
coming merge window, so will turn up in next sometime after rc1.
thanks,
Jonathan
> ---
> drivers/hid/hid-sensor-hub.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index 3dd7d3246737..f9983145d4e7 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -210,16 +210,21 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device
> *hsdev, u32 report_id,
> buffer_size = buffer_size / sizeof(__s32);
> if (buffer_size) {
> for (i = 0; i < buffer_size; ++i) {
> - hid_set_field(report->field[field_index], i,
> - (__force __s32)cpu_to_le32(*buf32));
> + ret = hid_set_field(report->field[field_index], i,
> + (__force __s32)cpu_to_le32(*buf32));
> + if (ret)
> + goto done_proc;
> +
> ++buf32;
> }
> }
> if (remaining_bytes) {
> value = 0;
> memcpy(&value, (u8 *)buf32, remaining_bytes);
> - hid_set_field(report->field[field_index], i,
> - (__force __s32)cpu_to_le32(value));
> + ret = hid_set_field(report->field[field_index], i,
> + (__force __s32)cpu_to_le32(value));
> + if (ret)
> + goto done_proc;
> }
> hid_hw_request(hsdev->hdev, report, HID_REQ_SET_REPORT);
> hid_hw_wait(hsdev->hdev);
Re: [PATCH] ttyprintk: Add TTY hangup callback.
Dne 15.04.2021 (čet) ob 09:22 +0900 je Tetsuo Handa napisal(a):
> syzbot is reporting hung task due to flood of
>
> tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__,
>port->count);
>
> message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from
> decrementing port->count due to tty_hung_up_p() == true.
>
> --
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int i;
> int fd[10];
>
> for (i = 0; i < 10; i++)
> fd[i] = open("/dev/ttyprintk", O_WRONLY);
> ioctl(fd[0], TIOCVHANGUP);
> for (i = 0; i < 10; i++)
> close(fd[i]);
> close(open("/dev/ttyprintk", O_WRONLY));
> return 0;
> }
> --
>
> When TTY hangup happens, port->count needs to be reset via
> "struct tty_operations"->hangup callback.
>
> [1]
> https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
>
> Reported-by: syzbot
> Reported-by: syzbot
> Tested-by: syzbot
> Signed-off-by: Tetsuo Handa
> Fixes: 24b4b67d17c308aa ("add ttyprintk driver")
> ---
> drivers/char/ttyprintk.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/char/ttyprintk.c b/drivers/char/ttyprintk.c
> index 6a0059e508e3..93f5d11c830b 100644
> --- a/drivers/char/ttyprintk.c
> +++ b/drivers/char/ttyprintk.c
> @@ -158,12 +158,23 @@ static int tpk_ioctl(struct tty_struct *tty,
> return 0;
> }
>
> +/*
> + * TTY operations hangup function.
> + */
> +static void tpk_hangup(struct tty_struct *tty)
> +{
> + struct ttyprintk_port *tpkp = tty->driver_data;
> +
> + tty_port_hangup(&tpkp->port);
> +}
> +
> static const struct tty_operations ttyprintk_ops = {
> .open = tpk_open,
> .close = tpk_close,
> .write = tpk_write,
> .write_room = tpk_write_room,
> .ioctl = tpk_ioctl,
> + .hangup = tpk_hangup,
> };
>
> static const struct tty_port_operations null_ops = { };
Using the supplied test code, i've tested the patch on my desktop running the
5.4 kernel. After applying the patch, the kernel warnings like "ttyprintk:
tty_port_close_start: tty->count = 1 port count = 11" do not appear any more,
when the test code is run.
I think the patch is ok.
best regards, Samo
Re: [PATCH 1/2] HID: hid-sensor-hub: Return error for hid_set_field() failure
On Sun, 18 Apr 2021 12:12:44 +0100
Jonathan Cameron wrote:
> On Thu, 15 Apr 2021 11:52:31 -0700
> Srinivas Pandruvada wrote:
>
> > In the function sensor_hub_set_feature(), return error when hid_set_field()
> > fails.
> >
> > Signed-off-by: Srinivas Pandruvada
> Series applied to the to greg branch of iio.git. Note these won't make the
> coming merge window, so will turn up in next sometime after rc1.
And dropped again. Not enough caffeine today. Not in IIO obviously so instead:
Acked-by: Jonathan Cameron
for both patches.
>
> thanks,
>
> Jonathan
>
> > ---
> > drivers/hid/hid-sensor-hub.c | 13 +
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> > index 3dd7d3246737..f9983145d4e7 100644
> > --- a/drivers/hid/hid-sensor-hub.c
> > +++ b/drivers/hid/hid-sensor-hub.c
> > @@ -210,16 +210,21 @@ int sensor_hub_set_feature(struct
> > hid_sensor_hub_device *hsdev, u32 report_id,
> > buffer_size = buffer_size / sizeof(__s32);
> > if (buffer_size) {
> > for (i = 0; i < buffer_size; ++i) {
> > - hid_set_field(report->field[field_index], i,
> > - (__force __s32)cpu_to_le32(*buf32));
> > + ret = hid_set_field(report->field[field_index], i,
> > + (__force __s32)cpu_to_le32(*buf32));
> > + if (ret)
> > + goto done_proc;
> > +
> > ++buf32;
> > }
> > }
> > if (remaining_bytes) {
> > value = 0;
> > memcpy(&value, (u8 *)buf32, remaining_bytes);
> > - hid_set_field(report->field[field_index], i,
> > - (__force __s32)cpu_to_le32(value));
> > + ret = hid_set_field(report->field[field_index], i,
> > + (__force __s32)cpu_to_le32(value));
> > + if (ret)
> > + goto done_proc;
> > }
> > hid_hw_request(hsdev->hdev, report, HID_REQ_SET_REPORT);
> > hid_hw_wait(hsdev->hdev);
>
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
On Sat, Apr 17, 2021 at 09:22:40PM +0100, Matthew Wilcox wrote:
> On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote:
> > > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t
> > > addr)
> > > +{
> > > + page->dma_addr[0] = addr;
> > > + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > > + page->dma_addr[1] = addr >> 16 >> 16;
> >
> > The 'error' that was reported will never trigger right?
> > I assume this was compiled with dma_addr_t as 32bits (so it triggered the
> > compilation error), but the if check will never allow this codepath to run.
> > If so can we add a comment explaining this, since none of us will remember
> > why
> > in 6 months from now?
>
> That's right. I compiled it all three ways -- 32-bit, 64-bit dma, 32-bit long
> and 64-bit. The 32/64 bit case turn into:
>
> if (0)
> page->dma_addr[1] = addr >> 16 >> 16;
>
> which gets elided. So the only case that has to work is 64-bit dma and
> 32-bit long.
>
> I can replace this with upper_32_bits().
>
Ok up to you, I don't mind either way and thanks for solving this!
Acked-by: Ilias Apalodimas
Re: [PATCH v2 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Sat, 17 Apr 2021 15:39:12 +0300 Andy Shevchenko wrote: > On Fri, Apr 16, 2021 at 5:21 PM Tomas Melin wrote: > > > > Add initial support for Murata SCA3300 3-axis industrial > > accelerometer with digital SPI interface. This device also > > provides a temperature measurement. > > > > Device product page including datasheet can be found at: > > https://www.murata.com/en-global/products/sensor/accel/sca3300 > > Can you create a tag out of it, i.e. > > Datasheet: > > ? > > > Signed-off-by: Tomas Melin > > ... > > > obj-$(CONFIG_SCA3000) += sca3000.o > > +obj-$(CONFIG_SCA3300) += sca3300.o > > How much difference between them? Enormous :) The sca3000 series were much more exciting parts with fifos and other fun a long time before anyone else had them. That part drove a lot of the weirder corners of IIO in the early days and had features that didn't show up anywhere else for quite a few years. The sca3100 onwards were much simpler (from software point of view) - I guess Murata have a different focus than VTI did. Jonathan
[PATCH] riscv: Remove 32b kernel mapping from page table dump
The 32b kernel mapping lies in the linear mapping, there is no point in
printing its address in page table dump, so remove this leftover that
comes from moving the kernel mapping outside the linear mapping for 64b
kernel.
Fixes: e9efb21fe352 ("riscv: Prepare ptdump for vm layout dynamic addresses")
Signed-off-by: Alexandre Ghiti
---
arch/riscv/mm/ptdump.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
index 0aba4421115c..a4ed4bdbbfde 100644
--- a/arch/riscv/mm/ptdump.c
+++ b/arch/riscv/mm/ptdump.c
@@ -76,8 +76,8 @@ enum address_markers_idx {
PAGE_OFFSET_NR,
#ifdef CONFIG_64BIT
MODULES_MAPPING_NR,
-#endif
KERNEL_MAPPING_NR,
+#endif
END_OF_SPACE_NR
};
@@ -99,8 +99,8 @@ static struct addr_marker address_markers[] = {
{0, "Linear mapping"},
#ifdef CONFIG_64BIT
{0, "Modules mapping"},
-#endif
{0, "Kernel mapping (kernel, BPF)"},
+#endif
{-1, NULL},
};
@@ -379,8 +379,8 @@ static int ptdump_init(void)
address_markers[PAGE_OFFSET_NR].start_address = PAGE_OFFSET;
#ifdef CONFIG_64BIT
address_markers[MODULES_MAPPING_NR].start_address = MODULES_VADDR;
-#endif
address_markers[KERNEL_MAPPING_NR].start_address = kernel_virt_addr;
+#endif
kernel_ptd_info.base_addr = KERN_VIRT_START;
--
2.20.1
Re: [PATCH v5 1/3] riscv: Move kernel mapping outside of linear mapping
Hi Palmer,
Le 4/15/21 à 2:00 PM, Alex Ghiti a écrit :
Le 4/15/21 à 12:54 AM, Alex Ghiti a écrit :
Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit :
On Sun, 11 Apr 2021 09:41:44 PDT (-0700), a...@ghiti.fr wrote:
This is a preparatory patch for relocatable kernel and sv48 support.
The kernel used to be linked at PAGE_OFFSET address therefore we
could use
the linear mapping for the kernel mapping. But the relocated kernel
base
address will be different from PAGE_OFFSET and since in the linear
mapping,
two different virtual addresses cannot point to the same physical
address,
the kernel mapping needs to lie outside the linear mapping so that
we don't
have to copy it at the same physical offset.
The kernel mapping is moved to the last 2GB of the address space, BPF
is now always after the kernel and modules use the 2GB memory range
right
before the kernel, so BPF and modules regions do not overlap. KASLR
implementation will simply have to move the kernel in the last 2GB
range
and just take care of leaving enough space for BPF.
In addition, by moving the kernel to the end of the address space, both
sv39 and sv48 kernels will be exactly the same without needing to be
relocated at runtime.
Suggested-by: Arnd Bergmann
Signed-off-by: Alexandre Ghiti
---
arch/riscv/boot/loader.lds.S | 3 +-
arch/riscv/include/asm/page.h | 17 +-
arch/riscv/include/asm/pgtable.h | 37
arch/riscv/include/asm/set_memory.h | 1 +
arch/riscv/kernel/head.S | 3 +-
arch/riscv/kernel/module.c | 6 +-
arch/riscv/kernel/setup.c | 5 ++
arch/riscv/kernel/vmlinux.lds.S | 3 +-
arch/riscv/mm/fault.c | 13 +
arch/riscv/mm/init.c | 87 ++---
arch/riscv/mm/kasan_init.c | 9 +++
arch/riscv/mm/physaddr.c | 2 +-
12 files changed, 146 insertions(+), 40 deletions(-)
diff --git a/arch/riscv/boot/loader.lds.S
b/arch/riscv/boot/loader.lds.S
index 47a5003c2e28..62d94696a19c 100644
--- a/arch/riscv/boot/loader.lds.S
+++ b/arch/riscv/boot/loader.lds.S
@@ -1,13 +1,14 @@
/* SPDX-License-Identifier: GPL-2.0 */
#include
+#include
OUTPUT_ARCH(riscv)
ENTRY(_start)
SECTIONS
{
- . = PAGE_OFFSET;
+ . = KERNEL_LINK_ADDR;
.payload : {
*(.payload)
diff --git a/arch/riscv/include/asm/page.h
b/arch/riscv/include/asm/page.h
index adc9d26f3d75..22cfb2be60dc 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -90,15 +90,28 @@ typedef struct page *pgtable_t;
#ifdef CONFIG_MMU
extern unsigned long va_pa_offset;
+extern unsigned long va_kernel_pa_offset;
extern unsigned long pfn_base;
#define ARCH_PFN_OFFSET (pfn_base)
#else
#define va_pa_offset 0
+#define va_kernel_pa_offset 0
#define ARCH_PFN_OFFSET (PAGE_OFFSET >> PAGE_SHIFT)
#endif /* CONFIG_MMU */
-#define __pa_to_va_nodebug(x) ((void *)((unsigned long) (x) +
va_pa_offset))
-#define __va_to_pa_nodebug(x) ((unsigned long)(x) - va_pa_offset)
+extern unsigned long kernel_virt_addr;
+
+#define linear_mapping_pa_to_va(x) ((void *)((unsigned long)(x)
+ va_pa_offset))
+#define kernel_mapping_pa_to_va(x) ((void *)((unsigned long)(x)
+ va_kernel_pa_offset))
+#define __pa_to_va_nodebug(x) linear_mapping_pa_to_va(x)
+
+#define linear_mapping_va_to_pa(x) ((unsigned long)(x) -
va_pa_offset)
+#define kernel_mapping_va_to_pa(x) ((unsigned long)(x) -
va_kernel_pa_offset)
+#define __va_to_pa_nodebug(x) ({ \
+ unsigned long _x = x; \
+ (_x < kernel_virt_addr) ? \
+ linear_mapping_va_to_pa(_x) :
kernel_mapping_va_to_pa(_x); \
+ })
#ifdef CONFIG_DEBUG_VIRTUAL
extern phys_addr_t __virt_to_phys(unsigned long x);
diff --git a/arch/riscv/include/asm/pgtable.h
b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..80e63a93e903 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -11,23 +11,30 @@
#include
-#ifndef __ASSEMBLY__
-
-/* Page Upper Directory not used in RISC-V */
-#include
-#include
-#include
-#include
+#ifndef CONFIG_MMU
+#define KERNEL_LINK_ADDR PAGE_OFFSET
+#else
-#ifdef CONFIG_MMU
+#define ADDRESS_SPACE_END (UL(-1))
+/*
+ * Leave 2GB for kernel and BPF at the end of the address space
+ */
+#define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1)
#define VMALLOC_SIZE (KERN_VIRT_SIZE >>1)
#define VMALLOC_END (PAGE_OFFSET - 1)
#define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE)
+/* KASLR should leave at least 128MB for BPF after the kernel */
#define BPF_JIT_REGION_SIZE (SZ_128M)
-#define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
-#define BPF_JIT_REGION_END (VMALLOC_END)
+#define BPF_JIT_REGION_START PFN_ALIGN((unsigned long)&_end)
+#define BPF_JIT_REGION_END (BPF_JIT_REGION_START +
BPF_JIT_REGION_SIZE)
+
+/* Modules always live before the
[PATCH net] gro: fix napi_gro_frags() Fast GRO breakage due to IP alignment check
Commit 38ec4944b593 ("gro: ensure frag0 meets IP header alignment")
did the right thing, but missed the fact that napi_gro_frags() logics
calls for skb_gro_reset_offset() *before* pulling Ethernet header
to the skb linear space.
That said, the introduced check for frag0 address being aligned to 4
always fails for it as Ethernet header is obviously 14 bytes long,
and in case with NET_IP_ALIGN its start is not aligned to 4.
Fix this by adding @nhoff argument to skb_gro_reset_offset() which
tells if an IP header is placed right at the start of frag0 or not.
This restores Fast GRO for napi_gro_frags() that became very slow
after the mentioned commit, and preserves the introduced check to
avoid silent unaligned accesses.
Fixes: 38ec4944b593 ("gro: ensure frag0 meets IP header alignment")
Signed-off-by: Alexander Lobakin
---
net/core/dev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 1f79b9aa9a3f..965d5f9b6fee 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5914,7 +5914,7 @@ static struct list_head *gro_list_prepare(struct
napi_struct *napi,
return head;
}
-static void skb_gro_reset_offset(struct sk_buff *skb)
+static void skb_gro_reset_offset(struct sk_buff *skb, u32 nhoff)
{
const struct skb_shared_info *pinfo = skb_shinfo(skb);
const skb_frag_t *frag0 = &pinfo->frags[0];
@@ -5925,7 +5925,7 @@ static void skb_gro_reset_offset(struct sk_buff *skb)
if (!skb_headlen(skb) && pinfo->nr_frags &&
!PageHighMem(skb_frag_page(frag0)) &&
- (!NET_IP_ALIGN || !(skb_frag_off(frag0) & 3))) {
+ (!NET_IP_ALIGN || !((skb_frag_off(frag0) + nhoff) & 3))) {
NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
skb_frag_size(frag0),
@@ -6143,7 +6143,7 @@ gro_result_t napi_gro_receive(struct napi_struct *napi,
struct sk_buff *skb)
skb_mark_napi_id(skb, napi);
trace_napi_gro_receive_entry(skb);
- skb_gro_reset_offset(skb);
+ skb_gro_reset_offset(skb, 0);
ret = napi_skb_finish(napi, skb, dev_gro_receive(napi, skb));
trace_napi_gro_receive_exit(ret);
@@ -6232,7 +6232,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct
*napi)
napi->skb = NULL;
skb_reset_mac_header(skb);
- skb_gro_reset_offset(skb);
+ skb_gro_reset_offset(skb, hlen);
if (unlikely(skb_gro_header_hard(skb, hlen))) {
eth = skb_gro_header_slow(skb, hlen, 0);
--
2.31.1
Aw: [PATCH] thermal: mediatek: add sensors-support
Hi, any opinion (except typo)? thermanl => thermal regards Frank > Gesendet: Samstag, 20. März 2021 um 10:06 Uhr > Von: "Frank Wunderlich" > add HWMON-support to mediateks thermanl driver to allow lm-sensors > userspace tools read soc temperature
Re: [PATCH v2 bpf-next 0/2] xsk: introduce generic almost-zerocopy xmit
From: Magnus Karlsson
Date: Tue, 13 Apr 2021 09:14:02 +0200
Hi!
I've finally done with a kinda comfy setup after moving to another
country and can finally continue working on patches and stuff.
> On Tue, Apr 13, 2021 at 3:49 AM Xuan Zhuo wrote:
> >
> > On Mon, 12 Apr 2021 16:13:12 +0200, Magnus Karlsson
> > wrote:
> > > On Wed, Mar 31, 2021 at 2:27 PM Alexander Lobakin wrote:
> > > >
> > > > This series is based on the exceptional generic zerocopy xmit logics
> > > > initially introduced by Xuan Zhuo. It extends it the way that it
> > > > could cover all the sane drivers, not only the ones that are capable
> > > > of xmitting skbs with no linear space.
> > > >
> > > > The first patch is a random while-we-are-here improvement over
> > > > full-copy path, and the second is the main course. See the individual
> > > > commit messages for the details.
> > > >
> > > > The original (full-zerocopy) path is still here and still generally
> > > > faster, but for now it seems like virtio_net will remain the only
> > > > user of it, at least for a considerable period of time.
> > > >
> > > > From v1 [0]:
> > > > - don't add a whole SMP_CACHE_BYTES because of only two bytes
> > > >(NET_IP_ALIGN);
> > > > - switch to zerocopy if the frame is 129 bytes or longer, not 128.
> > > >128 still fit to kmalloc-512, while a zerocopy skb is always
> > > >kmalloc-1024 -> can potentially be slower on this frame size.
> > > >
> > > > [0]
> > > > https://lore.kernel.org/netdev/20210330231528.546284-1-aloba...@pm.me
> > > >
> > > > Alexander Lobakin (2):
> > > > xsk: speed-up generic full-copy xmit
> > >
> > > I took both your patches for a spin on my machine and for the first
> > > one I do see a small but consistent drop in performance. I thought it
> > > would go the other way, but it does not so let us put this one on the
> > > shelf for now.
This is kinda strange as the solution is pretty straightforward.
But sure, if the performance dropped after this one, it should not
be considered for taking.
I might have a look at it later.
> > > > xsk: introduce generic almost-zerocopy xmit
> > >
> > > This one wreaked havoc on my machine ;-). The performance dropped with
> > > 75% for packets larger than 128 bytes when the new scheme kicks in.
> > > Checking with perf top, it seems that we spend much more time
> > > executing the sendmsg syscall. Analyzing some more:
> > >
> > > $ sudo bpftrace -e 'kprobe:__sys_sendto { @calls = @calls + 1; }
> > > interval:s:1 {printf("calls/sec: %d\n", @calls); @calls = 0;}'
> > > Attaching 2 probes...
> > > calls/sec: 1539509 with your patch compared to
> > >
> > > calls/sec: 105796 without your patch
> > >
> > > The application spends a lot of more time trying to get the kernel to
> > > send new packets, but the kernel replies with "have not completed the
> > > outstanding ones, so come back later" = EAGAIN. Seems like the
> > > transmission takes longer when the skbs have fragments, but I have not
> > > examined this any further. Did you get a speed-up?
> >
> > Regarding this solution, I actually tested it on my mlx5 network card, but
> > the
> > performance was severely degraded, so I did not continue this solution
> > later. I
> > guess it might have something to do with the physical network card. We can
> > try
> > other network cards.
>
> I tried it on a third card and got a 40% degradation, so let us scrap
> this idea. It should stay optional as it is today as the (software)
> drivers that benefit from this can turn it on explicitly.
Thank you guys a lot for the testing!
I think the main reason is the DMA mapping of one additional frag
(14 bytes of MAC header, which is excessive). It can take a lot of
CPU cycles, especially when the device is behind an IOMMU, and seems
like memcpying is faster here.
Moreover, if Xuan tested it as one of the steps towards his
full-zerocopy and found it to be a bad idea, this should not
go further.
So I'm burying this.
> > links: https://www.spinics.net/lists/netdev/msg710918.html
> >
> > Thanks.
> >
> > >
> > > > net/xdp/xsk.c | 32 ++--
> > > > 1 file changed, 22 insertions(+), 10 deletions(-)
> > > >
> > > > --
> > > > Well, this is untested. I currently don't have an access to my setup
> > > > and is bound by moving to another country, but as I don't know for
> > > > sure at the moment when I'll get back to work on the kernel next time,
> > > > I found it worthy to publish this now -- if any further changes will
> > > > be required when I already will be out-of-sight, maybe someone could
> > > > carry on to make a another revision and so on (I'm still here for any
> > > > questions, comments, reviews and improvements till the end of this
> > > > week).
> > > > But this *should* work with all the sane drivers. If a particular
> > > > one won't handle this, it's likely ill. Any tests are highly
> > > > appreciated. Thanks!
> > > > --
> > > > 2.31.1
Thanks,
Al
Re: [PATCH v2 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Fri, 16 Apr 2021 16:45:46 +0300
Tomas Melin wrote:
> Add initial support for Murata SCA3300 3-axis industrial
> accelerometer with digital SPI interface. This device also
> provides a temperature measurement.
>
> Device product page including datasheet can be found at:
> https://www.murata.com/en-global/products/sensor/accel/sca3300
>
> Signed-off-by: Tomas Melin
A few things inline. Mostly looks pretty good
Jonathan
> ---
> drivers/iio/accel/Kconfig | 13 +
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/sca3300.c | 468
> 3 files changed, 482 insertions(+)
> create mode 100644 drivers/iio/accel/sca3300.c
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index cceda3cecbcf..0dbf7b648e8a 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -450,6 +450,19 @@ config SCA3000
> To compile this driver as a module, say M here: the module will be
> called sca3000.
>
> +config SCA3300
> + tristate "Murata SCA3300 3-Axis Accelerometer Driver"
> + depends on SPI
> + select CRC8
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for Murata SCA3300 3-Axis
> + accelerometer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sca3300.
> +
> config STK8312
> tristate "Sensortek STK8312 3-Axis Accelerometer Driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 32cd1342a31a..4b56527a2b97 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_MXC4005) += mxc4005.o
> obj-$(CONFIG_MXC6255)+= mxc6255.o
>
> obj-$(CONFIG_SCA3000)+= sca3000.o
> +obj-$(CONFIG_SCA3300)+= sca3300.o
>
> obj-$(CONFIG_STK8312)+= stk8312.o
> obj-$(CONFIG_STK8BA50) += stk8ba50.o
> diff --git a/drivers/iio/accel/sca3300.c b/drivers/iio/accel/sca3300.c
> new file mode 100644
> index ..79c3c60f9fab
> --- /dev/null
> +++ b/drivers/iio/accel/sca3300.c
> @@ -0,0 +1,468 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 Vaisala Oyj. All rights reserved.
> + */
> +#include
Slight preference for 'specific' includes such asm after the generic
linux ones.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SCA3300_ALIAS "sca3300"
> +
> +#define SCA3300_REG_STATUS 0x6
> +#define SCA3300_REG_MODE 0xd
> +#define SCA3300_REG_WHOAMI 0x10
> +#define SCA3300_VALUE_SW_RESET 0x20
> +#define SCA3300_CRC8_POLYNOMIAL 0x1d
> +#define SCA3300_DEVICE_ID 0x51
> +#define SCA3300_RS_ERROR 0x3
> +#define SCA3300_SELBANK 0x1f
> +#define SCA3300_STATUS_MASK 0x1ff
> +
> +enum sca3300_scan_indexes {
> + SCA3300_ACC_X = 0,
> + SCA3300_ACC_Y,
> + SCA3300_ACC_Z,
> + SCA3300_TEMP,
> + SCA3300_TIMESTAMP,
> +};
> +
> +#define SCA3300_ACCEL_CHANNEL(index, reg, axis) {\
> + .type = IIO_ACCEL, \
> + .address = reg, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> + .info_mask_shared_by_type_available = \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> + .scan_index = index,\
> + .scan_type = { \
> + .sign = 's',\
> + .realbits = 16, \
> + .storagebits = 16, \
> + .shift = 0, \
> + .endianness = IIO_CPU, \
> + }, \
> + }
Alignment done something odd here and above. Editors get confused by
macros so you might need to tweak this carefully!
> +
> +static const struct iio_chan_spec sca3300_channels[] = {
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_X, 0x1, X),
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_Y, 0x2, Y),
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_Z, 0x3, Z),
> + {
> + .type = IIO_TEMP,
> + .address =
Re: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
On 01.04.21 16:52, Jan Kiszka wrote:
> On 01.04.21 13:42, Michal Simek wrote:
>> Hi Jan,
>>
>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>> On 07.11.19 10:44, Rajan Vaja wrote:
Add clock nodes for zynqmp based on CCF.
Signed-off-by: Rajan Vaja
---
arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 222
+
arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 2 +-
.../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 4 +-
.../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 4 +-
.../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 4 +-
.../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 4 +-
.../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 4 +-
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++-
15 files changed, 270 insertions(+), 26 deletions(-)
create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
new file mode 100644
index 000..9868ca1
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Clock specification for Xilinx ZynqMP
+ *
+ * (C) Copyright 2017 - 2019, Xilinx, Inc.
+ *
+ * Michal Simek
+ */
+
+#include
+/ {
+ pss_ref_clk: pss_ref_clk {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <>;
+ };
+
+ video_clk: video_clk {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2700>;
+ };
+
+ pss_alt_ref_clk: pss_alt_ref_clk {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ gt_crx_ref_clk: gt_crx_ref_clk {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <10800>;
+ };
+
+ aux_ref_clk: aux_ref_clk {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2700>;
+ };
+};
+
+&can0 {
+ clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&can1 {
+ clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&cpu0 {
+ clocks = <&zynqmp_clk ACPU>;
+};
+
+&fpd_dma_chan1 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan2 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan3 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan4 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan5 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan6 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan7 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&fpd_dma_chan8 {
+ clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan1 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan2 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan3 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan4 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan5 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan6 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan7 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&lpd_dma_chan8 {
+ clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+};
+
+&gem0 {
+ clocks = <&zynqmp_clk
[PATCH v2 0/5] Samsung Galaxy S III Neo Initial DTS
Enable booting of Samsung Galaxy S III Neo mobile phone with MSM8226 SoC. Implemented clocks are on top of MSM8974 GCC driver because there is really little difference between them. UART serial communication is working. Changes in v2: - Removed alphabet sort includes in MSM8974 GCC driver - Keep using qcom_cc_probe() function instead of qcom_cc_really_probe() - Add only MSM8226 SoC related includes to qcom GCC clock bindings - Changed DTS files license to BSD 3 Clause - Made changes in qcom-msm8226.dtsi DTS file: > Remove occurrences of clock-frequency property from timer nodes > Removed model and compatible properties > Renamed pin controller label to "tlmm" > Moved compatible and reg properties first in the nodes > Lowercase hex address values > Fix make dtbs_check warning in memory node Bartosz Dudziak (5): dt-bindings: clock: qcom: Add MSM8226 GCC clock bindings clk: qcom: gcc: Add support for Global Clock controller found on MSM8226 arm: dts: qcom: Add support for MSM8226 SoC dt-bindings: arm: qcom: Document MSM8226 SoC binding arm: dts: qcom: Add initial DTS file for Samsung Galaxy S III Neo phone .../devicetree/bindings/arm/qcom.yaml | 6 + .../devicetree/bindings/clock/qcom,gcc.yaml | 5 +- arch/arm/boot/dts/Makefile| 1 + .../boot/dts/qcom-msm8226-samsung-s3ve3g.dts | 25 +++ arch/arm/boot/dts/qcom-msm8226.dtsi | 147 +++ drivers/clk/qcom/gcc-msm8974.c| 169 +- 6 files changed, 344 insertions(+), 9 deletions(-) create mode 100644 arch/arm/boot/dts/qcom-msm8226-samsung-s3ve3g.dts create mode 100644 arch/arm/boot/dts/qcom-msm8226.dtsi -- 2.25.1
[PATCH v2 1/5] dt-bindings: clock: qcom: Add MSM8226 GCC clock bindings
Add compatible device strings and the include files for the MSM8226 GCC. Signed-off-by: Bartosz Dudziak --- Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index ee0467fb5e..eddf10e6a4 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -26,8 +26,8 @@ description: | - dt-bindings/reset/qcom,gcc-msm8939.h - dt-bindings/clock/qcom,gcc-msm8660.h - dt-bindings/reset/qcom,gcc-msm8660.h - - dt-bindings/clock/qcom,gcc-msm8974.h - - dt-bindings/reset/qcom,gcc-msm8974.h + - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) + - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - dt-bindings/clock/qcom,gcc-msm8994.h - dt-bindings/clock/qcom,gcc-mdm9615.h - dt-bindings/reset/qcom,gcc-mdm9615.h @@ -41,6 +41,7 @@ properties: - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 + - qcom,gcc-msm8226 - qcom,gcc-msm8660 - qcom,gcc-msm8916 - qcom,gcc-msm8939 -- 2.25.1
[PATCH v2 2/5] clk: qcom: gcc: Add support for Global Clock controller found on MSM8226
Modify existing MSM8974 driver to support MSM8226 SoC. Override frequencies
which are different in this older chip. Register all the clocks to the
framework for the clients to be able to request for them.
Signed-off-by: Bartosz Dudziak
---
drivers/clk/qcom/gcc-msm8974.c | 169 +++--
1 file changed, 162 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 740d3c44c0..bf305fa9e5 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -719,6 +719,12 @@ static struct clk_rcg2 blsp2_uart6_apps_clk_src = {
},
};
+static const struct freq_tbl ftbl_gcc_ce1_clk_msm8226[] = {
+ F(5000, P_GPLL0, 12, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ { }
+};
+
static const struct freq_tbl ftbl_gcc_ce1_clk[] = {
F(5000, P_GPLL0, 12, 0, 0),
F(7500, P_GPLL0, 8, 0, 0),
@@ -761,6 +767,11 @@ static struct clk_rcg2 ce2_clk_src = {
},
};
+static const struct freq_tbl ftbl_gcc_gp_clk_msm8226[] = {
+ F(1920, P_XO, 1, 0, 0),
+ { }
+};
+
static const struct freq_tbl ftbl_gcc_gp_clk[] = {
F(480, P_XO, 4, 0, 0),
F(600, P_GPLL0, 10, 1, 10),
@@ -1955,6 +1966,10 @@ static struct clk_branch gcc_mss_q6_bimc_axi_clk = {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_mss_q6_bimc_axi_clk",
+ .parent_names = (const char *[]){
+ "system_noc_clk_src",
+ },
+ .num_parents = 1,
.ops = &clk_branch2_ops,
},
},
@@ -1993,6 +2008,20 @@ static struct clk_branch gcc_pdm_ahb_clk = {
},
};
+static struct clk_branch gcc_pdm_xo4_clk = {
+ .halt_reg = 0x0cc8,
+ .clkr = {
+ .enable_reg = 0x0cc8,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_pdm_xo4_clk",
+ .parent_names = (const char *[]){ "xo" },
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_prng_ahb_clk = {
.halt_reg = 0x0d04,
.halt_check = BRANCH_HALT_VOTED,
@@ -2430,6 +2459,121 @@ static struct gdsc usb_hs_hsic_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
};
+static struct clk_regmap *gcc_msm8226_clocks[] = {
+ [GPLL0] = &gpll0.clkr,
+ [GPLL0_VOTE] = &gpll0_vote,
+ [GPLL1] = &gpll1.clkr,
+ [GPLL1_VOTE] = &gpll1_vote,
+ [CONFIG_NOC_CLK_SRC] = &config_noc_clk_src.clkr,
+ [PERIPH_NOC_CLK_SRC] = &periph_noc_clk_src.clkr,
+ [SYSTEM_NOC_CLK_SRC] = &system_noc_clk_src.clkr,
+ [BLSP1_QUP1_I2C_APPS_CLK_SRC] = &blsp1_qup1_i2c_apps_clk_src.clkr,
+ [BLSP1_QUP1_SPI_APPS_CLK_SRC] = &blsp1_qup1_spi_apps_clk_src.clkr,
+ [BLSP1_QUP2_I2C_APPS_CLK_SRC] = &blsp1_qup2_i2c_apps_clk_src.clkr,
+ [BLSP1_QUP2_SPI_APPS_CLK_SRC] = &blsp1_qup2_spi_apps_clk_src.clkr,
+ [BLSP1_QUP3_I2C_APPS_CLK_SRC] = &blsp1_qup3_i2c_apps_clk_src.clkr,
+ [BLSP1_QUP3_SPI_APPS_CLK_SRC] = &blsp1_qup3_spi_apps_clk_src.clkr,
+ [BLSP1_QUP4_I2C_APPS_CLK_SRC] = &blsp1_qup4_i2c_apps_clk_src.clkr,
+ [BLSP1_QUP4_SPI_APPS_CLK_SRC] = &blsp1_qup4_spi_apps_clk_src.clkr,
+ [BLSP1_QUP5_I2C_APPS_CLK_SRC] = &blsp1_qup5_i2c_apps_clk_src.clkr,
+ [BLSP1_QUP5_SPI_APPS_CLK_SRC] = &blsp1_qup5_spi_apps_clk_src.clkr,
+ [BLSP1_QUP6_I2C_APPS_CLK_SRC] = &blsp1_qup6_i2c_apps_clk_src.clkr,
+ [BLSP1_QUP6_SPI_APPS_CLK_SRC] = &blsp1_qup6_spi_apps_clk_src.clkr,
+ [BLSP1_UART1_APPS_CLK_SRC] = &blsp1_uart1_apps_clk_src.clkr,
+ [BLSP1_UART2_APPS_CLK_SRC] = &blsp1_uart2_apps_clk_src.clkr,
+ [BLSP1_UART3_APPS_CLK_SRC] = &blsp1_uart3_apps_clk_src.clkr,
+ [BLSP1_UART4_APPS_CLK_SRC] = &blsp1_uart4_apps_clk_src.clkr,
+ [BLSP1_UART5_APPS_CLK_SRC] = &blsp1_uart5_apps_clk_src.clkr,
+ [BLSP1_UART6_APPS_CLK_SRC] = &blsp1_uart6_apps_clk_src.clkr,
+ [CE1_CLK_SRC] = &ce1_clk_src.clkr,
+ [GP1_CLK_SRC] = &gp1_clk_src.clkr,
+ [GP2_CLK_SRC] = &gp2_clk_src.clkr,
+ [GP3_CLK_SRC] = &gp3_clk_src.clkr,
+ [PDM2_CLK_SRC] = &pdm2_clk_src.clkr,
+ [SDCC1_APPS_CLK_SRC] = &sdcc1_apps_clk_src.clkr,
+ [SDCC2_APPS_CLK_SRC] = &sdcc2_apps_clk_src.clkr,
+ [SDCC3_APPS_CLK_SRC] = &sdcc3_apps_clk_src.clkr,
+ [USB_HS_SYSTEM_CLK_SRC] = &usb_hs_system_clk_src.clkr,
+ [USB_HSIC_CLK_SRC] = &usb_hsic_clk_src.clkr,
+ [USB_HSIC_IO_CAL_CLK_SRC] = &usb_hsic_io_cal_clk_src.clkr,
+ [USB_HSIC_SYSTEM_CLK_SRC] = &usb_hsic_system_clk_src.clkr,
+ [GCC_BAM_DMA_AHB_CLK] = &gcc_bam_dma_ahb_clk.clkr,
+ [GCC_BLSP1_AHB_CLK] = &gcc_blsp1_ahb_clk.clkr,
+ [GCC_BLSP1_QUP1_I2C_APPS_CLK] = &gcc_blsp1_qup1_i2c_apps_clk.
[PATCH v2 4/5] dt-bindings: arm: qcom: Document MSM8226 SoC binding
Document the MSM8226 SoC device-tree binding. Signed-off-by: Bartosz Dudziak --- Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 11ec349d56..73902ce46f 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -31,6 +31,7 @@ description: | ipq6018 ipq8074 mdm9615 +msm8226 msm8916 msm8974 msm8992 @@ -111,6 +112,11 @@ properties: - qcom,apq8084-sbc - const: qcom,apq8084 + - items: + - enum: + - samsung,s3ve3g + - const: qcom,msm8226 + - items: - enum: - qcom,msm8960-cdp -- 2.25.1
[PATCH v2 5/5] arm: dts: qcom: Add initial DTS file for Samsung Galaxy S III Neo phone
Add DTS support for the Samsung Galaxy S III Neo (codenamed s3ve3g) phone.
Initial version have just a working serial console.
Signed-off-by: Bartosz Dudziak
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/qcom-msm8226-samsung-s3ve3g.dts | 25 +++
2 files changed, 26 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-msm8226-samsung-s3ve3g.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e7..080ff37fdb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk07.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-ipq8064-rb3011.dtb \
+ qcom-msm8226-samsung-s3ve3g.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
qcom-msm8974-fairphone-fp2.dtb \
diff --git a/arch/arm/boot/dts/qcom-msm8226-samsung-s3ve3g.dts
b/arch/arm/boot/dts/qcom-msm8226-samsung-s3ve3g.dts
new file mode 100644
index 00..d159188c8b
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8226-samsung-s3ve3g.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include "qcom-msm8226.dtsi"
+
+/ {
+ model = "Samsung Galaxy S III Neo";
+ compatible = "samsung,s3ve3g", "qcom,msm8226";
+
+ aliases {
+ serial0 = &blsp1_uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&soc {
+ serial@f991f000 {
+ status = "ok";
+ };
+};
--
2.25.1
[PATCH v2 3/5] arm: dts: qcom: Add support for MSM8226 SoC
Implement basic device tree support for MSM8226 SoC which belongs to the
Snapdragon 400 family. For now, this file adds the basic nodes like gcc,
pinctrl and other required configuration for booting up to the serial
console.
Signed-off-by: Bartosz Dudziak
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 147
1 file changed, 147 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-msm8226.dtsi
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-msm8226.dtsi
new file mode 100644
index 00..2de69d5687
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include
+#include
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ chosen { };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0>;
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ intc: interrupt-controller@f900 {
+ compatible = "qcom,msm-qgic2";
+ reg = <0xf900 0x1000>,
+ <0xf9002000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ gcc: clock-controller@fc40 {
+ compatible = "qcom,gcc-msm8226";
+ reg = <0xfc40 0x4000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ tlmm: pinctrl@fd51 {
+ compatible = "qcom,msm8226-pinctrl";
+ reg = <0xfd51 0x4000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 117>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = ;
+ };
+
+ blsp1_uart3: serial@f991f000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0xf991f000 0x1000>;
+ interrupts = ;
+ clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>, <&gcc
GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
+ restart@fc4ab000 {
+ compatible = "qcom,pshold";
+ reg = <0xfc4ab000 0x4>;
+ };
+
+ rng@f9bff000 {
+ compatible = "qcom,prng";
+ reg = <0xf9bff000 0x200>;
+ clocks = <&gcc GCC_PRNG_AHB_CLK>;
+ clock-names = "core";
+ };
+
+ timer@f902 {
+ compatible = "arm,armv7-timer-mem";
+ reg = <0xf902 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ frame@f9021000 {
+ frame-number = <0>;
+ interrupts = ,
+;
+ reg = <0xf9021000 0x1000>,
+ <0xf9022000 0x1000>;
+ };
+
+ frame@f9023000 {
+ frame-number = <1>;
+ interrupts = ;
+ reg = <0xf9023000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9024000 {
+ frame-number = <2>;
+ interrupts = ;
+ reg = <0xf9024000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9025000 {
+ frame-number = <3>;
+ interrupts = ;
+ reg = <0xf9025000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9026000 {
+ frame-number = <4>;
+ interrupts = ;
+ reg = <0xf9026000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9027000 {
+ frame-number = <5>;
+ interrupts = ;
+
Re: [EXTERNAL] Re: [PATCH 4.19 013/247] cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.
Hi Greg,
On Mon, Apr 12, 2021 at 10:01:33AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 08, 2021 at 01:41:05PM +0200, Salvatore Bonaccorso wrote:
> > Hi Shyam,
> >
> > On Tue, Apr 06, 2021 at 05:01:17PM +0200, Salvatore Bonaccorso wrote:
> > > Hi,
> > >
> > > On Tue, Apr 06, 2021 at 02:00:48PM +, Shyam Prasad wrote:
> > > > Hi Greg,
> > > > We'll need to debug this further to understand what's going on.
> > >
> > > Greg asked it the same happens with 5.4 as well, I do not know I was
> > > not able to test 5.4.y (yet) but only 5.10.y and 4.19.y.
> > > >
> > > > Hi Salvatore,
> > > > Any chance that you'll be able to provide us the cifsFYI logs from the
> > > > time of mount failure?
> > > > https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging
> > >
> > > Please find it attached. Is this enough information?
> > >
> > > The mentioned home DFS link 'home' is a DFS link to
> > > msdfs:SECONDHOST\REDACTED on a Samba host.
> > >
> > > The mount is triggered as
> > >
> > > mount -t cifs //HOSTIP/REDACTED/home /mnt --verbose -o
> > > username='REDACTED,domain=DOMAIN'
> >
> > So I can confirm the issue is both present in 4.19.185 and 5.4.110
> > upstream (without any Debian patches applied, we do not anyway apply
> > any cifs related one on top of the respetive upstream version).
> >
> > The issue is not present in 5.10.28.
> >
> > So I think there are commits as dependency of a738c93fb1c1 ("cifs: Set
> > CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.") which
> > are required and not applied in the released before 5.10.y which make
> > introducing the regression.
>
> Ok, I've dropped this from 5.4 and older kernel trees now, thanks for
> the report.
Thanks Greg! Shyam, Steven, now the commit was reverted for the older
brnaches. But did you got a chance to find why it breaks for the older
series?
Regards,
Salvatore
Re: [PATCH v3 1/2] KVM: selftests: Sync data verify of dirty logging with guest sync
On Sat, Apr 17, 2021 at 10:36:01AM -0400, Peter Xu wrote:
> This fixes a bug that can trigger with e.g. "taskset -c 0 ./dirty_log_test" or
> when the testing host is very busy.
>
> A similar previous attempt is done [1] but that is not enough, the reason is
> stated in the reply [2].
>
> As a summary (partly quotting from [2]):
>
> The problem is I think one guest memory write operation (of this specific
> test)
> contains a few micro-steps when page is during kvm dirty tracking (here I'm
> only considering write-protect rather than pml but pml should be similar at
> least when the log buffer is full):
>
> (1) Guest read 'iteration' number into register, prepare to write, page
> fault
> (2) Set dirty bit in either dirty bitmap or dirty ring
> (3) Return to guest, data written
>
> When we verify the data, we assumed that all these steps are "atomic", say,
> when (1) happened for this page, we assume (2) & (3) must have happened. We
> had some trick to workaround "un-atomicity" of above three steps, as previous
> version of this patch wanted to fix atomicity of step (2)+(3) by explicitly
> letting the main thread wait for at least one vmenter of vcpu thread, which
> should work. However what I overlooked is probably that we still have race
> when (1) and (2) can be interrupted.
>
> One example calltrace when it could happen that we read an old interation, got
> interrupted before even setting the dirty bit and flushing data:
>
> __schedule+1742
> __cond_resched+52
> __get_user_pages+530
> get_user_pages_unlocked+197
> hva_to_pfn+206
> try_async_pf+132
> direct_page_fault+320
> kvm_mmu_page_fault+103
> vmx_handle_exit+288
> vcpu_enter_guest+2460
> kvm_arch_vcpu_ioctl_run+325
> kvm_vcpu_ioctl+526
> __x64_sys_ioctl+131
> do_syscall_64+51
> entry_SYSCALL_64_after_hwframe+68
>
> It means iteration number cached in vcpu register can be very old when dirty
> bit set and data flushed.
>
> So far I don't see an easy way to guarantee all steps 1-3 atomicity but to
> sync
> at the GUEST_SYNC() point of guest code when we do verification of the dirty
> bits as what this patch does.
>
> [1] https://lore.kernel.org/lkml/20210413213641.23742-1-pet...@redhat.com/
> [2] https://lore.kernel.org/lkml/20210417140956.GV4440@xz-x1/
>
> Cc: Paolo Bonzini
> Cc: Sean Christopherson
> Cc: Andrew Jones
> Signed-off-by: Peter Xu
> ---
> tools/testing/selftests/kvm/dirty_log_test.c | 60
> 1 file changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/dirty_log_test.c
> b/tools/testing/selftests/kvm/dirty_log_test.c
> index bb2752d78fe3..510884f0eab8 100644
> --- a/tools/testing/selftests/kvm/dirty_log_test.c
> +++ b/tools/testing/selftests/kvm/dirty_log_test.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include "kvm_util.h"
> #include "test_util.h"
> @@ -137,12 +138,20 @@ static uint64_t host_clear_count;
> static uint64_t host_track_next_count;
>
> /* Whether dirty ring reset is requested, or finished */
> -static sem_t dirty_ring_vcpu_stop;
> -static sem_t dirty_ring_vcpu_cont;
> +static sem_t sem_vcpu_stop;
> +static sem_t sem_vcpu_cont;
> +/*
> + * This is only set by main thread, and only cleared by vcpu thread. It is
> + * used to request vcpu thread to stop at the next GUEST_SYNC, since
> GUEST_SYNC
> + * is the only place that we'll guarantee both "dirty bit" and "dirty data"
> + * will match. E.g., SIG_IPI won't guarantee that (e.g., when vcpu
> interrupted
> + * after setting dirty bit but before data flushed).
> + */
> +static atomic_t vcpu_sync_stop_requested;
> /*
> * This is updated by the vcpu thread to tell the host whether it's a
> * ring-full event. It should only be read until a sem_wait() of
> - * dirty_ring_vcpu_stop and before vcpu continues to run.
> + * sem_vcpu_stop and before vcpu continues to run.
> */
> static bool dirty_ring_vcpu_ring_full;
> /*
> @@ -234,6 +243,17 @@ static void clear_log_collect_dirty_pages(struct kvm_vm
> *vm, int slot,
> kvm_vm_clear_dirty_log(vm, slot, bitmap, 0, num_pages);
> }
>
> +/* Should only be called after a GUEST_SYNC */
> +static void vcpu_handle_sync_stop(void)
> +{
> + if (atomic_read(&vcpu_sync_stop_requested)) {
> + /* It means main thread is sleeping waiting */
> + atomic_set(&vcpu_sync_stop_requested, false);
> + sem_post(&sem_vcpu_stop);
> + sem_wait_until(&sem_vcpu_cont);
> + }
> +}
> +
> static void default_after_vcpu_run(struct kvm_vm *vm, int ret, int err)
> {
> struct kvm_run *run = vcpu_state(vm, VCPU_ID);
> @@ -244,6 +264,8 @@ static void default_after_vcpu_run(struct kvm_vm *vm, int
> ret, int err)
> TEST_ASSERT(get_ucall(vm, VCPU_ID, NULL) == UCALL_SYNC,
> "Invalid guest sync status: exit_reason=%s\n",
> exit_reason_str(run->exit_reason));
> +
> +
Re: [PATCH 0/5] Samsung Galaxy S III Neo Initial DTS
On Fri, Mar 26, 2021 at 03:58:11PM +0100, Bartosz Dudziak wrote: > This series of patches enables to boot MSM8226 SoC in Samsung Galaxy S III Neo > mobile phone. Implemented clocks are on top of MSM8974 GCC driver because > there > is really little difference between them. UART serial communication is > working. > I have working patches for the regulators, EMMC, multithreading and Wifi for > this device but they are not clean and ready to submit. > > Bartosz Dudziak (5): > dt-bindings: clock: qcom: Add MSM8226 GCC clock bindings > clk: qcom: gcc: Add support for Global Clock controller found on > MSM8226 > arm: dts: qcom: Add support for MSM8226 SoC > dt-bindings: arm: qcom: Document MSM8226 SoC binding > arm: dts: qcom: Add initial DTS file for Samsung Galaxy S III Neo > phone > > .../devicetree/bindings/arm/qcom.yaml | 6 + > .../devicetree/bindings/clock/qcom,gcc.yaml | 13 +- > arch/arm/boot/dts/Makefile| 1 + > .../boot/dts/qcom-msm8226-samsung-s3ve3g.dts | 25 +++ > arch/arm/boot/dts/qcom-msm8226.dtsi | 152 ++ > drivers/clk/qcom/gcc-msm8974.c| 185 -- > 6 files changed, 364 insertions(+), 18 deletions(-) > create mode 100644 arch/arm/boot/dts/qcom-msm8226-samsung-s3ve3g.dts > create mode 100644 arch/arm/boot/dts/qcom-msm8226.dtsi > > -- > 2.25.1 > I have sent version V2 of the patches
Re: [PATCH v3 0/3] Drivers: hv: vmbus: Introduce CHANNELMSG_MODIFYCHANNEL_RESPONSE
On Fri, Apr 16, 2021 at 04:34:46PM +0200, Andrea Parri (Microsoft) wrote: > Changes since v2[1]: > - fix VMbus protocol version name > - add Reviewed-by: tag > - refactor/simplyfy changes in hv_synic_cleanup() > > Changes since v1[2]: > - rebase on hyperv-next > - split changes into three patches > - fix&simplify error handling in send_modifychannel_with_ack() > - remove rescind checks in send_modifychannel_with_ack() > - remove unneeded test in hv_synic_event_pending() > - add/amend inline comments > - style changes > > [1] https://lkml.kernel.org/r/20210414150118.2843-1-parri.and...@gmail.com > [2] https://lkml.kernel.org/r/20201126191210.13115-1-parri.and...@gmail.com > > Andrea Parri (Microsoft) (3): > Drivers: hv: vmbus: Introduce and negotiate VMBus protocol version 5.3 > Drivers: hv: vmbus: Drivers: hv: vmbus: Introduce > CHANNELMSG_MODIFYCHANNEL_RESPONSE > Drivers: hv: vmbus: Check for pending channel interrupts before taking > a CPU offline Applied to hyperv-next. Thanks. Wei.
[ANNOUNCE] 4.4.267-rt221
Hello RT-list! I'm pleased to announce the 4.4.267-rt221 stable release. This is just an update to the latest stable release. No RT specific changes. Known issue: - locktorture reports a might_sleep warning for spin_locks test You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.4-rt Head SHA1: e65ae24c8623270657748609d1bf099019dd2635 Or to build 4.4.267-rt221 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.267.xz Enjoy! Daniel Changes from v4.4.262-rt219: --- Adrian Hunter (1): perf auxtrace: Fix auxtrace queue conflict Alexander Aring (8): net: ieee802154: nl-mac: fix check on panid net: ieee802154: fix nl802154 del llsec key net: ieee802154: fix nl802154 del llsec dev net: ieee802154: fix nl802154 add llsec key net: ieee802154: fix nl802154 del llsec devkey net: ieee802154: forbid monitor for set llsec params net: ieee802154: forbid monitor for del llsec seclevel net: ieee802154: stop dump llsec params for monitors Alexander Gordeev (1): s390/cpcmd: fix inline assembly register clobbering Alexey Dobriyan (1): scsi: qla2xxx: Fix broken #endif placement Angelo Dureghello (1): can: flexcan: flexcan_chip_freeze(): fix chip freeze for missing bitrate Arnaldo Carvalho de Melo (1): perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches Arnd Bergmann (2): x86/build: Turn off -fcf-protection for realmode targets drm/imx: imx-ldb: fix out of bounds array access warning Atul Gopinathan (2): staging: rtl8192e: Fix incorrect source in memcpy() staging: rtl8192e: Change state information from u16 to u8 Benjamin Rood (1): ASoC: sgtl5000: set DAP_AVC_CTRL register to correct default value on probe Borislav Petkov (1): x86/tlb: Flush global mappings when KAISER is disabled Claudiu Manoil (1): gianfar: Handle error code at MAC address change Dan Carpenter (1): scsi: lpfc: Fix some error codes in debugfs Daniel Wagner (4): Merge tag 'v4.4.263' into v4.4-rt Linux 4.4.263-rt220 Merge tag 'v4.4.267' into v4.4-rt Linux 4.4.267-rt221 David Brazdil (1): selinux: vsock: Set SID for socket returned by accept() Denis Efremov (1): sun/niu: fix wrong RXMAC_BC_FRM_CNT_COUNT count Dinghao Liu (2): e1000e: Fix error handling in e1000_set_d0_lplu_state_82571 extcon: Fix error handling in extcon_dev_register Doug Brown (1): appletalk: Fix skb allocation size in loopback case Du Cheng (1): cfg80211: remove WARN_ON() in cfg80211_sme_connect Eric Dumazet (3): macvlan: macvlan_count_rx() needs to be aware of preemption net: sched: validate stab values sch_red: fix off-by-one checks in red_check_params() Filipe Manana (1): btrfs: fix race when cloning extent buffer during rewind of an old root Florian Fainelli (1): net: dsa: bcm_sf2: Qualify phydev->dev_flags based on port Florian Westphal (1): netfilter: x_tables: fix compat match/target pad out-of-bound write Frank Sorenson (1): NFS: Correct size calculation for create reply length Greg Kroah-Hartman (5): Linux 4.4.263 Linux 4.4.264 Linux 4.4.265 Linux 4.4.266 Linux 4.4.267 Grygorii Strashko (1): bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD Gwendal Grignou (1): platform/chrome: cros_ec_dev - Fix security issue Hans de Goede (2): ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10 ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10 Heiko Carstens (1): init/Kconfig: make COMPILE_TEST depend on !S390 Heiko Thiery (1): net: fec: ptp: avoid register access when ipg clock is disabled Helge Deller (1): parisc: parisc-agp requires SBA IOMMU driver Hui Wang (1): ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook Ikjoon Jang (1): ALSA: usb-audio: Apply sample rate quirk to Logitech Connect Ilya Lipnitskiy (1): mm: fix race by making init_zero_pfn() early_initcall J. Bruce Fields (2): nfs: we don't support removing system.nfs4_acl rpc: fix NULL dereference on kmalloc failure Jack Qiu (1): fs: direct-io: fix missing sdio->boundary Jakub Kicinski (1): ipv6: weaken the v4mapped source check Jan Beulich (1): xen-blkback: don't leak persistent grants from xen_blkbk_map() Jan Kara (3): ext4: handle error of ext4_setup_system_zone() on remount ext4: don't allow overlapping system zones ext4: check journal inode extents more carefully Jia-Ju Bai (1): net: tehuti: fix error return code in bdx_probe() Jim Lin (1): usb: gadget: configfs: Fix KASAN use-after-free Joe Korty (1): NFSD:
Re: [PATCH 1/2] x86/hyperv: Move hv_do_rep_hypercall to asm-generic
On Fri, Apr 16, 2021 at 05:43:02PM -0700, Joseph Salisbury wrote:
> From: Joseph Salisbury
>
> This patch makes no functional changes. It simply moves hv_do_rep_hypercall()
> out of arch/x86/include/asm/mshyperv.h and into asm-generic/mshyperv.h
>
> hv_do_rep_hypercall() is architecture independent, so it makes sense that it
> should be in the architecture independent mshyperv.h, not in the x86-specific
> mshyperv.h.
>
> This is done in preperation for a follow up patch which creates a consistent
> pattern for checking Hyper-V hypercall status.
>
> Signed-off-by: Joseph Salisbury
> ---
[...]
> +static inline u64 hv_do_rep_hypercall(u16 code, u16 rep_count, u16
> varhead_size,
> + void *input, void *output)
> +{
> + u64 control = code;
> + u64 status;
> + u16 rep_comp;
> +
> + control |= (u64)varhead_size << HV_HYPERCALL_VARHEAD_OFFSET;
> + control |= (u64)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
> +
> + do {
> + status = hv_do_hypercall(control, input, output);
> + if ((status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS)
> + return status;
> +
> + /* Bits 32-43 of status have 'Reps completed' data. */
> + rep_comp = (status & HV_HYPERCALL_REP_COMP_MASK) >>
> + HV_HYPERCALL_REP_COMP_OFFSET;
> +
> + control &= ~HV_HYPERCALL_REP_START_MASK;
> + control |= (u64)rep_comp << HV_HYPERCALL_REP_START_OFFSET;
> +
> + touch_nmi_watchdog();
This seems to be missing in Arm. Does it compile?
Wei.
> + } while (rep_comp < rep_count);
> +
> + return status;
> +}
>
> /* Generate the guest OS identifier as described in the Hyper-V TLFS */
> static inline __u64 generate_guest_id(__u64 d_info1, __u64 kernel_version,
> --
> 2.17.1
>
Re: [PATCH v8 4/8] dt-bindings: pwm: Support new PWM_USAGE_POWER flag
Hello Thierry,
On Fri, Apr 16, 2021 at 12:45:10PM +0200, Thierry Reding wrote:
> On Fri, Apr 16, 2021 at 11:32:12AM +0200, Uwe Kleine-König wrote:
> > On Thu, Apr 15, 2021 at 06:27:02PM +0200, Thierry Reding wrote:
> > > On Tue, Apr 13, 2021 at 07:56:31PM +0200, Uwe Kleine-König wrote:
> > > > Please define a rule that allows to judge if any given implementation is
> > > > correct or not. For the record neither "within reasonable bounds" nor "a
> > > > factor of 10 is not within reason" is good enough.
> > >
> > > We haven't had any rules thus far and I have yet to see a single report
> > > that drivers get this completely wrong. So "within reason", which I
> > > think is what driver authors will do by default, is good enough in
> > > practice.
> >
> > For me commit 11fc4edc483b ("pwm: bcm2835: Improve precision of PWM")
> > indicates that there is a problem. Someone used the pwm-ir-tx driver on
> > top of pwm-bcm2835. The former driver's expectation is that
> >
> > period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, pwm_ir->carrier);
> > duty = DIV_ROUND_CLOSEST(pwm_ir->duty_cycle * period, 100);
> > pwm_config(pwm, duty, period);
> >
> > yields a frequency near pwm_ir->carrier (minimizing
> >
> > abs(1 / implemented_freq - 1 / pwm_ir->carrier)
> >
> > (or should it minimize abs(implemented_freq - pwm_ir->carrier) instead?
> > Not entirely sure.). The result was that the pwm-bcm2835 driver was
> > changed to implement a different rounding. I took the time to look at
> > the drivers in 11fc4edc483b^, with the following result:
> >
> > - pwm-ab8500.c: ignores period_ns in .config
> > - pwm-atmel.c: rounds down period
> > - pwm-atmel-hlcdc.c: rounds up period (unsure)
> > - pwm-atmel-tcb.c: rounds down period (unsure)
> > - pwm-bcm2835.c: rounds down period
> > - pwm-bcm-iproc.c: rounds down period
> > - pwm-bcm-kona.c: rounds down period
> > - pwm-berlin.c: rounds down period
> > - pwm-brcmstb.c: rounds down period
> > - pwm-clps711x.c: doesn't support changing period (IMHO in a buggy way
> >because the period in the dts is just overwritten)
> > - pwm-crc: rounds down period
> > - pwm-cros-ec.c: doesn't support changing period
> > - pwm-ep93xx.c: rounds down period
> > - pwm-fsl-ftm.c: rounds down period
> > - pwm-hibvt.c: rounds down period
> > o pwm-img.c: confusing rounding behaviour
> > - pwm-imx1.c: just implements relative duty cycle
> > - pwm-imx27.c: rounds down period
> > + pwm-imx-tpm.c: rounds to nearest period (unsure)
> > - pwm-jz4740.c: rounds down period
> > - pwm-lp3943.c: rounds down period (apart from corner cases)
> > - pwm-lpc18xx-sct.c: rounds down period
> > - pwm-lpc32xx.c: rounds down period
> > - pwm-lpss.c: rounds up period
> > + pwm-mediatek.c: tries to implement round-nearest
> > - pwm-meson.c: tries to round down period
> > o pwm-mtk-disp.c: confusing rounding behaviour
> > - pwm-mxs.c: rounds down period
> > + pwm-omap-dmtimer.c: rounds to closest period
> > + pwm-pca9685.c: rounds to closest period
> > - pwm-puv3.c: rounds down period
> > - pwm-pxa.c: rounds down period
> > - pwm-rcar.c: rounds down period
> > o pwm-renesas-tpu.c: confusing rounding behaviour
> > + pwm-rockchip.c: rounds closest period
> > - pwm-samsung.c: rounds down period (unsure)
> > - pwm-sifive.c: rounds down period
> > - pwm-spear.c: rounds down period
> > - pwm-sti.c: rounds down period
> > - pwm-stm32.c: rounds down period
> > - pwm-stm32-lp.c: rounds down period
> > - pwm-stmpe.c: just implements relative duty cycle
> > + pwm-sun4i.c: rounds closest period
> > + pwm-tegra.c: tries to round nearest period
> > - pwm-tiecap.c: rounds down period
> > - pwm-tiehrpwm.c: rounds down period
> > - pwm-twl.c: just implements relative duty cycle
> > - pwm-twl-led.c: just implements relative duty cycle
> > - pwm-vt8500.c: rounds down period
> > - pwm-zx.c: rounds down period
> >
> > (- = doesn't behave "reasonable" to be used by pwm-ir-tx, + = behaves
> > "reasonable" for pwm-ir-tx, o = don't know, too complicated for me to
> > understand quickly (should we count that as -?))
>
> I'm not sure I understand correctly, but aren't you actually making a
> point against always using round-down now?
Not really. This is indeed a case where round-down isn't the right thing
for a consumer. As there are also use cases where round-down is
right, the conclusion has to be: Currently the PWM API isn't powerful
enough to map the different needs of different consumers. IMHO we need
pwm_round_nearest_state() here.
And the reason I mentioned this was to contradict your position that
there isn't any problem. (You said "I have yet to see a single report
that drivers get this completely wrong." It depends on what you consider
"completely wrong", but I'd say
https://lore.kernel.org/linux-pwm/20190603090058.qd3tbiffmdgqm...@gofer.mess.org/
was a report about a driver that gets it wrong enough to actually hurt
and in reply to that report the driver was change
Re: [PATCH v1 4/7] iio: st_sensors: Call st_sensors_power_enable() from bus drivers
On Sun, Apr 18, 2021 at 1:54 PM Jonathan Cameron wrote: > On Wed, 14 Apr 2021 22:54:51 +0300 > Andy Shevchenko wrote: > > > In case we would initialize two IIO devices from one physical device, > > we shouldn't have a clash on regulators. That's why move > > st_sensors_power_enable() call from core to bus drivers. > > Why is this a problem? You can't have two regulators of the same name on the same device. IIRC the regulator framework produces a good splat for this. > The two instances would double up and both get + > enable + disable the regulators. However, that shouldn't matter as > they are reference counted anyway. > > Perhaps an example? Even in patch 6 I can only see that it is wasteful > to do it twice, rather than wrong as such. Believe me, I would like to avoid that, but it seems a limitation of the regulator framework. It simply produces a splat. I'll try to reproduce it again (because this series started like a couple of years ago, just eventually I found a time to clean up and submit) and will tell you how it is going. -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hello,
just a few smaller issues left to fix.
On Sun, Apr 18, 2021 at 08:09:04PM +0900, Nobuhiro Iwamatsu wrote:
> diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> new file mode 100644
> index ..166b18ac1a3a
> --- /dev/null
> +++ b/drivers/pwm/pwm-visconti.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Toshiba Visconti pulse-width-modulation controller driver
> + *
> + * Copyright (c) 2020 TOSHIBA CORPORATION
> + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
We're in 2021, so you might want to adapt the year in the copy right
notice.
> + *
> + * Authors: Nobuhiro Iwamatsu
> + *
> + * Limitations:
> + * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8).
This is too detailed for the purpose of this section. Please either drop
it or make this:
- The fixed input clock is running at 1 MHz and is divided by either 1,
2, 4 or 8.
> + * - Fixed input clock running at 1 MHz.
> + * - When the settings of the PWM are modified, the new values are shadowed
> + * in hardware until the PIPGM_PCSR register is written and the currently
> + * running period is completed. This way the hardware switches atomically
> + * from the old setting to the new.
> + * - Disabling the hardware completes the currently running period and keeps
> + * the output at low level at all times.
> + */
> +
> [...]
> + /*
> + * PWMC controls a divider that divides the input clk by a
> + * power of two between 1 and 8. As a smaller divider yields
> + * higher precision, pick the smallest possible one.
> + */
> + if (period > 0x) {
> + pwmc0 = ilog2(period >> 16);
> + BUG_ON(pwmc0 > 3);
> + } else
> + pwmc0 = 0;
The linux coding style mandates that you should use braces for both
branches. (i.e.
+ if (period > 0x) {
+ pwmc0 = ilog2(period >> 16);
+ BUG_ON(pwmc0 > 3);
+ } else {
+ pwmc0 = 0;
+ }
)
> + period >>= pwmc0;
> + duty_cycle >>= pwmc0;
> +
> + if (state->polarity == PWM_POLARITY_INVERSED)
> + pwmc0 |= PIPGM_PWMC_PWMACT;
> + writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> + writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
> + writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> +
> + return 0;
> +}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Sun, Apr 18, 2021 at 2:07 PM Jonathan Cameron wrote:
Thanks for review, my answers below.
> On Wed, 14 Apr 2021 22:54:53 +0300
> Andy Shevchenko wrote:
>
> > We can utilize separate drivers for accelerometer and magnetometer,
> > so here is the glue driver to enable LSM9DS0 IMU support.
> >
> > The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
> > was sent as RFC due to race condition concerns, which are indeed possible.
>
> If you are going to mention races, good to give some flavour in here!
I meant that the initial idea is racy due to different devices
communicating to the same i2c address.
So, any sequence of transfers are not serialized and you may end up with
drv1 -> i2c
drv2 -> i2c
drv1 <- i2c # garbage
> This driver makes me very nervous indeed.
Why?! This one is race free as far as I can see. Or maybe I interpret
this wrongly and you are talking about initial RFC?
> I haven't 'found' any places
> where the fact we'll write the same registers from each of the drivers
> causes problems (e.g. int pin setup etc) but perhaps I'm missing something.
>
> Shall we say that makes me rather keener to get eyes (and thought) on this
> patch than normal :)
How should I amend the commit message to state:
1. First idea (RFC by the link) *is* racy AFAIU
2. This one *is not* racy.
> > In order to amend the initial change,
You see, *in order to amend*, so here is the *amended* version.
> I went further by providing a specific
> > multi-instantiate probe driver that reuses existing accelerometer and
> > magnetometer.
> >
> > [1]: https://lore.kernel.org/patchwork/patch/670353/
> >
> > Suggested-by: Crestez Dan Leonard
> > Cc: mr.laho...@laposte.net
> > Cc: Matija Podravec
> > Cc: Sergey Borishchenko
> > Signed-off-by: Andy Shevchenko
>
> A few comments in here, though mostly about stuff related to the origin code
> you are copying so perhaps not tidying them up is preferable because it would
> complicate comparison of the two cases.
...
> > + {
> > + .wai = 0x49,
> > + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS,
> > + .sensors_supported = {
> > + [0] = LSM9DS0_IMU_DEV_NAME,
>
> What does the name attribute report for these?
>
> Previously we've had the _accel etc postfix to differentiate the devices. I
> don't
> suppose it matters to much though as easy enough to identify the accelerometer
> etc from what channels are present.
>
> Of course driver may get name from somewhere different anyway, I haven't
> checked,
> just noticed this was different and wondered what the affect might be.
Yes, it has a postfix, that's why I leave it like this.
...
> > +static int st_lsm9ds0_power_enable(struct device *dev, struct st_lsm9ds0
> > *lsm9ds0)
> > +{
> > + int ret;
> > +
> > + /* Regulators not mandatory, but if requested we should enable them.
> > */
>
> That's a bit of a missleading comment though cut and paste from the other
> driver
> code. Key is that they will be handled by stub regulators if we don't provide
> the which is not really what that comment implies.
I see. I will remove it.
> > + lsm9ds0->vdd = devm_regulator_get(dev, "vdd");
> > + if (IS_ERR(lsm9ds0->vdd)) {
> > + dev_err(dev, "unable to get Vdd supply\n");
> > + return PTR_ERR(lsm9ds0->vdd);
> > + }
> > + ret = regulator_enable(lsm9ds0->vdd);
> > + if (ret) {
> > + dev_warn(dev, "Failed to enable specified Vdd supply\n");
>
> Given we fail to probe if this is true, dev_warn seems a bit soft.
Right. I'll move to dev_err().
> > + return ret;
> > + }
> > +
> > + lsm9ds0->vdd_io = devm_regulator_get(dev, "vddio");
> > + if (IS_ERR(lsm9ds0->vdd_io)) {
> > + dev_err(dev, "unable to get Vdd_IO supply\n");
> > + regulator_disable(lsm9ds0->vdd);
> > + return PTR_ERR(lsm9ds0->vdd_io);
> > + }
> > + ret = regulator_enable(lsm9ds0->vdd_io);
> > + if (ret) {
> > + dev_warn(dev, "Failed to enable specified Vdd_IO supply\n");
Ditto.
> > + regulator_disable(lsm9ds0->vdd);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
--
With Best Regards,
Andy Shevchenko
[PATCH rdma-next 0/3] CMA fixes
From: Leon Romanovsky Another round of fixes to cma.c Parav Pandit (1): RDMA/cma: Skip device which doesn't support CM Shay Drory (2): RDMA/core: Fix check of device in rdma_listen() RDMA/core: Add CM to restrack after successful attachment to a device drivers/infiniband/core/cma.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) -- 2.30.2
[PATCH] arm64: remove HAVE_DEBUG_BUGVERBOSE
From: Jisheng Zhang
After commit 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic
BUG traps"), arm64 has switched to generic BUG implementation, so
there's no need to select HAVE_DEBUG_BUGVERBOSE.
Signed-off-by: Jisheng Zhang
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..f0e6ee157840 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -159,7 +159,6 @@ config ARM64
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
select HAVE_CONTEXT_TRACKING
- select HAVE_DEBUG_BUGVERBOSE
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
--
2.31.0
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Sun, Apr 18, 2021 at 4:49 PM Andy Shevchenko wrote: > > On Sun, Apr 18, 2021 at 2:07 PM Jonathan Cameron wrote: > > Thanks for review, my answers below. > > > On Wed, 14 Apr 2021 22:54:53 +0300 > > Andy Shevchenko wrote: > > > > > We can utilize separate drivers for accelerometer and magnetometer, > > > so here is the glue driver to enable LSM9DS0 IMU support. > > > > > > The idea was suggested by Crestez Dan Leonard in [1]. The proposed change > > > was sent as RFC due to race condition concerns, which are indeed possible. > > > > If you are going to mention races, good to give some flavour in here! > > I meant that the initial idea is racy due to different devices > communicating to the same i2c address. > So, any sequence of transfers are not serialized and you may end up with > > drv1 -> i2c > drv2 -> i2c > drv1 <- i2c # garbage > > > This driver makes me very nervous indeed. > > Why?! This one is race free as far as I can see. Or maybe I interpret > this wrongly and you are talking about initial RFC? > > > I haven't 'found' any places > > where the fact we'll write the same registers from each of the drivers > > causes problems (e.g. int pin setup etc) but perhaps I'm missing something. > > > > Shall we say that makes me rather keener to get eyes (and thought) on this > > patch than normal :) > > How should I amend the commit message to state: > 1. First idea (RFC by the link) *is* racy AFAIU > 2. This one *is not* racy. I re-read this and now understand better what you meant. So, it may be that the initial proposal may work without any amendment, but since I haven't investigated much, I should rather use the phrase "potentially racy". In my variant it's using one regmap for both drivers (not two), which makes the register state consistent. Am I wrong? Do we have some places where we may write to the same register concurrently? -- With Best Regards, Andy Shevchenko
Re: PROBLEM: DoS Attack on Fragment Cache
Should the default, though, be so low? If someone is still using a old modem they can crank up the sysctl, it does seem like such things are pretty rare these days :). Its rather trivial to, without any kind of attack, hit 1Mbps of lost fragments in today's networks, at which point all fragments are dropped. After all, I submitted the patch to "scratch my own itch" :). Matt On 4/18/21 00:39, Willy Tarreau wrote: I do agree that we shouldn't keep them that long nowadays, we can't go too low without risking to break some slow transmission stacks (SLIP/PPP over modems for example).
[PATCH 1/2] lib: scatterlist: Fix loop termination condition in sg_calculate_split()
nb_splits was decremented one time too much becoming negative. This
leads to the failure of the loop termination conditions which checks
only for nb_splits being zero. Move the loop termination condition
a couple of lines up before nb_splits is decremented again and potentially
becomes negative.
Signed-off-by: Alexander Egorenkov
---
lib/sg_split.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lib/sg_split.c b/lib/sg_split.c
index 3d9b32084d78..0920affd12ee 100644
--- a/lib/sg_split.c
+++ b/lib/sg_split.c
@@ -60,15 +60,16 @@ static int sg_calculate_split(struct scatterlist *in, int
nents, int nb_splits,
curr->length_last_sg = len;
size -= len;
}
- skip = 0;
-
- if (!size && --nb_splits > 0) {
- curr++;
- size = *(++sizes);
- }
if (!nb_splits)
break;
+
+ skip = 0;
+
+ if (!size && --nb_splits > 0) {
+ curr++;
+ size = *(++sizes);
+ }
}
return (size || !splitters[0].in_sg0) ? -EINVAL : 0;
--
2.31.1
[PATCH 2/2] lib: scatterlist: Fix incorrect SG offset in sg_split_phys()
sg_split_phys() incorrectly resets the offset of all split SGLs but the
first one to 0. This is wrong because one of the original SGLs might have
the offset != 0.
Signed-off-by: Alexander Egorenkov
---
lib/sg_split.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/sg_split.c b/lib/sg_split.c
index 0920affd12ee..4e91547a898d 100644
--- a/lib/sg_split.c
+++ b/lib/sg_split.c
@@ -89,8 +89,6 @@ static void sg_split_phys(struct sg_splitter *splitters,
const int nb_splits)
if (!j) {
out_sg->offset += split->skip_sg0;
out_sg->length -= split->skip_sg0;
- } else {
- out_sg->offset = 0;
}
sg_dma_address(out_sg) = 0;
if (IS_ENABLED(CONFIG_NEED_SG_DMA_LENGTH))
--
2.31.1
Re: [PATCH] kernel:irq:manage: request threaded irq with a specified priority
Daniel & tglx, Points taken and thanks a lot for such detailed explanations. BR Song On 2021/4/16 下午5:09, Thomas Gleixner wrote: On Fri, Apr 16 2021 at 12:57, chensong wrote: On 2021/4/13 下午4:39, Thomas Gleixner wrote: It breaks because the system designer failed to assign proper priorities to the irq threads int_a, int_b and to the user space process task_a. yes, it's designers' responsibility to assign proper priorities, but kernel is also obliged to provide interfaces for those designers. The interface exists. sched_setscheduler(2) chrt can help designers in this case, however, the truth is lot of customers are not familiar with it. The truth is that real-time systems need to be carefully designed and parametrized. And that's only possible when _all_ of the system components and their constraints are known. Trying to solve it at the device driver level of a single device is impossible and a guarantee for fail. If the customer does not know how to do it, then I really have to ask why he's trying to use a real-time system at all. There is no real-time system which magically tunes itself by pulling the overall system constraints out of thin air. what's more, chrt can also apply to userspace rt task, but userspace also has sched_setscheduler to assgin proper priority inside code like cyclictest, why can't driver writers have another choice? There is a very simple reason: The driver writer cannot know about the requirements of the complete system which is composed of kernel, drivers and user space applications, unless the driver writer is fully aware of the overall system design and constraints. How is that supposed to work on a general purpose kernel which is utilized for a gazillion of different use cases which all have different expectations? It simply cannot work because default A will only work for usecase A and be completely wrong for all others. Further, what if irq handlear thread has to run on the expected priority at the very beginning? This patch helps. There is no such thing as the expected priority of an interrupt thread which can be applied upfront. There are ~5400 instances of request*irq() in the kernel source and there is no way to make priority decisions for them which work for every RT system out there. The kernel sets a default and the system designer, admin, user has to take care of tuning it to match the expectations and constraints of his particular application scenario. The kernel provides an userspace interface to do that. That interface might be a bit awkward to use, but there are tools out there which help with that, and if at all we can think about providing a better and easier to use interface for this. Trying to solve that at the kernel level is putting the cart before the horse. Thanks, tglx
Re: [PATCH] extcon: maxim: Fix missing IRQF_ONESHOT as only threaded handler
On 16/04/2021 16:43, Krzysztof Kozlowski wrote: On 15/04/2021 13:36, zhuguangqin...@gmail.com wrote: From: Guangqing Zhu Coccinelle noticed: 1. drivers/extcon/extcon-max14577.c:699:8-33: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT 2. drivers/extcon/extcon-max77693.c:1143:8-33: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT 3. drivers/extcon/extcon-max77843.c:907:8-33: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT 4. drivers/extcon/extcon-max8997.c:665:8-28: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT Signed-off-by: Guangqing Zhu --- drivers/extcon/extcon-max14577.c | 2 +- drivers/extcon/extcon-max77693.c | 2 +- drivers/extcon/extcon-max77843.c | 3 ++- drivers/extcon/extcon-max8997.c | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c index ace523924e58..af15a9e00ee9 100644 --- a/drivers/extcon/extcon-max14577.c +++ b/drivers/extcon/extcon-max14577.c @@ -698,7 +698,7 @@ static int max14577_muic_probe(struct platform_device *pdev) ret = devm_request_threaded_irq(&pdev->dev, virq, NULL, max14577_muic_irq_handler, - IRQF_NO_SUSPEND, + IRQF_NO_SUSPEND | IRQF_ONESHOT, The same with all other patches for IRQF_ONESHOT which are send recently: 1. On what board did you test it? I didn't test it. 2. Is this just blind patch from Coccinelle without investigation whether it is needed (hint: it's not needed here, it does not use default primary handler). I found the error notice from Coccinelle and I saw the code. Maybe I'm mistaken, I think it's needed here. Because handler == NULL and thread_fn != NULL, it use irq_default_primary_handler() in request_threaded_irq(). 3. If you think otherwise, please explain. Best regards, Krzysztof Thanks for your review. Best regards, Guangqing Zhu
RE: [PATCH 1/2] x86/hyperv: Move hv_do_rep_hypercall to asm-generic
From: Wei Liu Sent: Sunday, April 18, 2021 6:09 AM
> On Fri, Apr 16, 2021 at 05:43:02PM -0700, Joseph Salisbury wrote:
> > From: Joseph Salisbury
> >
> > This patch makes no functional changes. It simply moves
> > hv_do_rep_hypercall()
> > out of arch/x86/include/asm/mshyperv.h and into asm-generic/mshyperv.h
> >
> > hv_do_rep_hypercall() is architecture independent, so it makes sense that it
> > should be in the architecture independent mshyperv.h, not in the
> > x86-specific
> > mshyperv.h.
> >
> > This is done in preperation for a follow up patch which creates a consistent
> > pattern for checking Hyper-V hypercall status.
> >
> > Signed-off-by: Joseph Salisbury
> > ---
> [...]
> > +static inline u64 hv_do_rep_hypercall(u16 code, u16 rep_count, u16
> > varhead_size,
> > + void *input, void *output)
> > +{
> > + u64 control = code;
> > + u64 status;
> > + u16 rep_comp;
> > +
> > + control |= (u64)varhead_size << HV_HYPERCALL_VARHEAD_OFFSET;
> > + control |= (u64)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
> > +
> > + do {
> > + status = hv_do_hypercall(control, input, output);
> > + if ((status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS)
> > + return status;
> > +
> > + /* Bits 32-43 of status have 'Reps completed' data. */
> > + rep_comp = (status & HV_HYPERCALL_REP_COMP_MASK) >>
> > + HV_HYPERCALL_REP_COMP_OFFSET;
> > +
> > + control &= ~HV_HYPERCALL_REP_START_MASK;
> > + control |= (u64)rep_comp << HV_HYPERCALL_REP_START_OFFSET;
> > +
> > + touch_nmi_watchdog();
>
> This seems to be missing in Arm. Does it compile?
>
> Wei.
touch_nmi_watchdog() is defined as "static inline" in include/linux/nmi.h. So
it should be present in all architectures. It calls arch_touch_nmi_watchdog,
which is an empty function if CONFIG_HAVE_NMI_WATCHDOG is not defined,
as is the case on ARM64.
Michael
>
> > + } while (rep_comp < rep_count);
> > +
> > + return status;
> > +}
> >
> > /* Generate the guest OS identifier as described in the Hyper-V TLFS */
> > static inline __u64 generate_guest_id(__u64 d_info1, __u64 kernel_version,
> > --
> > 2.17.1
> >
[PATCH] media: atomisp: pci: remove unneeded variable 'err'
Fix the following coccicheck warning:
drivers/staging/media/atomisp/pci/sh_css_mipi.c:39:5-8:
Unneeded variable: "err". Return "0" on line 44
Signed-off-by: Saurav Girepunje
---
drivers/staging/media/atomisp/pci/sh_css_mipi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
index d5ae7f0b5864..708903a31b08 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
@@ -36,12 +36,11 @@ ref_count_mipi_allocation[N_CSI_PORTS]; /* Initialized in
mipi_init */
int
ia_css_mipi_frame_specify(const unsigned int size_mem_words,
const bool contiguous) {
- int err = 0;
my_css.size_mem_words = size_mem_words;
(void)contiguous;
- return err;
+ return 0;
}
/*
--
2.25.1
[PATCH v6 00/12] Fix bugs and add support for new Ingenic SoCs.
v1->v2: 1.Split [1/3] in v1 to [1/6] [2/6] [3/6] [4/6] in v2. 2.Fix the uninitialized warning. v2->v3: Split [6/6] in v2 to [6/10] [7/10] [8/10] [9/10] [10/10] in v3. v3->v4: 1.Modify the format of comment. 2.Split lcd pins into several groups. 3.Drop "lcd-no-pins" which is pointless. 4.Improve the structure of some functions. 5.Adjust function names to avoid confusion. 6.Use "lcd-special" and "lcd-generic" instead "lcd-xxbit-tft". 7.Replace "lcd-rgb-xxx" with "lcd-tft-xxx" to avoid confusion. v4->v5: Add support for schmitt and slew. v5->v6: 1.Add the missing lcd-24bit group. 2.Add DMIC pins support for Ingenic SoCs. 3.Adjust and simplify the code. 周琰杰 (Zhou Yanjie) (12): pinctrl: Ingenic: Add missing pins to the JZ4770 MAC MII group. pinctrl: Ingenic: Add support for read the pin configuration of X1830. pinctrl: Ingenic: Adjust the sequence of X1830 SSI pin groups. pinctrl: Ingenic: Improve LCD pins related code. pinctrl: Ingenic: Add DMIC pins support for Ingenic SoCs. pinctrl: Ingenic: Reformat the code. dt-bindings: pinctrl: Add bindings for new Ingenic SoCs. pinctrl: Ingenic: Add pinctrl driver for JZ4730. pinctrl: Ingenic: Add pinctrl driver for JZ4750. pinctrl: Ingenic: Add pinctrl driver for JZ4755. pinctrl: Ingenic: Add pinctrl driver for JZ4775. pinctrl: Ingenic: Add pinctrl driver for X2000. .../bindings/pinctrl/ingenic,pinctrl.yaml | 23 +- drivers/pinctrl/pinctrl-ingenic.c | 1645 ++-- 2 files changed, 1533 insertions(+), 135 deletions(-) -- 2.7.4
[PATCH v6 01/12] pinctrl: Ingenic: Add missing pins to the JZ4770 MAC MII group.
The MII group of JZ4770's MAC should have 7 pins, add missing
pins to the MII group.
Fixes: 5de1a73e78ed ("Pinctrl: Ingenic: Add missing parts for JZ4770 and
JZ4780.")
Cc:
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add fixes tag.
v3->v4:
1.Add Cc: .
2.Add Andy Shevchenko's Reviewed-by.
3.Add Paul Cercueil's Reviewed-by.
v4->v5:
No change.
v5->v6:
No change.
drivers/pinctrl/pinctrl-ingenic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index f274612..05dfa0a 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -667,7 +667,9 @@ static int jz4770_pwm_pwm7_pins[] = { 0x6b, };
static int jz4770_mac_rmii_pins[] = {
0xa9, 0xab, 0xaa, 0xac, 0xa5, 0xa4, 0xad, 0xae, 0xa6, 0xa8,
};
-static int jz4770_mac_mii_pins[] = { 0xa7, 0xaf, };
+static int jz4770_mac_mii_pins[] = {
+ 0x7b, 0x7a, 0x7d, 0x7c, 0xa7, 0x24, 0xaf,
+};
static const struct group_desc jz4770_groups[] = {
INGENIC_PIN_GROUP("uart0-data", jz4770_uart0_data, 0),
--
2.7.4
[PATCH v6 02/12] pinctrl: Ingenic: Add support for read the pin configuration of X1830.
Add X1830 support in "ingenic_pinconf_get()", so that it can read the
configuration of X1830 SoC correctly.
Fixes: d7da2a1e4e08 ("pinctrl: Ingenic: Add pinctrl driver for X1830.")
Cc:
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
1.Add fixes tag.
2.Adjust the code, simplify the ingenic_pinconf_get() function.
v3->v4:
1.Add parentheses around the '%' to make it more obvious.
2.Add Cc: .
3.Add Andy Shevchenko's Reviewed-by.
4.Add Paul Cercueil's Reviewed-by.
v4->v5:
No change.
v5->v6:
No change.
drivers/pinctrl/pinctrl-ingenic.c | 40 ++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 05dfa0a..3de0f76 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -2109,26 +2109,48 @@ static int ingenic_pinconf_get(struct pinctrl_dev
*pctldev,
enum pin_config_param param = pinconf_to_config_param(*config);
unsigned int idx = pin % PINS_PER_GPIO_CHIP;
unsigned int offt = pin / PINS_PER_GPIO_CHIP;
- bool pull;
+ unsigned int bias;
+ bool pull, pullup, pulldown;
- if (jzpc->info->version >= ID_JZ4770)
- pull = !ingenic_get_pin_config(jzpc, pin, JZ4770_GPIO_PEN);
- else
- pull = !ingenic_get_pin_config(jzpc, pin, JZ4740_GPIO_PULL_DIS);
+ if (jzpc->info->version >= ID_X1830) {
+ unsigned int half = PINS_PER_GPIO_CHIP / 2;
+ unsigned int idxh = (pin % half) * 2;
+
+ if (idx < half)
+ regmap_read(jzpc->map, offt * jzpc->info->reg_offset +
+ X1830_GPIO_PEL, &bias);
+ else
+ regmap_read(jzpc->map, offt * jzpc->info->reg_offset +
+ X1830_GPIO_PEH, &bias);
+
+ bias = (bias >> idxh) & (GPIO_PULL_UP | GPIO_PULL_DOWN);
+
+ pullup = (bias == GPIO_PULL_UP) && (jzpc->info->pull_ups[offt]
& BIT(idx));
+ pulldown = (bias == GPIO_PULL_DOWN) &&
(jzpc->info->pull_downs[offt] & BIT(idx));
+
+ } else {
+ if (jzpc->info->version >= ID_JZ4770)
+ pull = !ingenic_get_pin_config(jzpc, pin,
JZ4770_GPIO_PEN);
+ else
+ pull = !ingenic_get_pin_config(jzpc, pin,
JZ4740_GPIO_PULL_DIS);
+
+ pullup = pull && (jzpc->info->pull_ups[offt] & BIT(idx));
+ pulldown = pull && (jzpc->info->pull_downs[offt] & BIT(idx));
+ }
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- if (pull)
+ if (pullup || pulldown)
return -EINVAL;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- if (!pull || !(jzpc->info->pull_ups[offt] & BIT(idx)))
+ if (!pullup)
return -EINVAL;
break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- if (!pull || !(jzpc->info->pull_downs[offt] & BIT(idx)))
+ if (!pulldown)
return -EINVAL;
break;
@@ -2146,7 +2168,7 @@ static void ingenic_set_bias(struct ingenic_pinctrl *jzpc,
if (jzpc->info->version >= ID_X1830) {
unsigned int idx = pin % PINS_PER_GPIO_CHIP;
unsigned int half = PINS_PER_GPIO_CHIP / 2;
- unsigned int idxh = pin % half * 2;
+ unsigned int idxh = (pin % half) * 2;
unsigned int offt = pin / PINS_PER_GPIO_CHIP;
if (idx < half) {
--
2.7.4
[PATCH v6 03/12] pinctrl: Ingenic: Adjust the sequence of X1830 SSI pin groups.
Adjust the sequence of X1830's SSI related codes to make it consistent
with other Ingenic SoCs.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add Paul Cercueil's Reviewed-by.
v3->v4:
Add Andy Shevchenko's Reviewed-by.
v4->v5:
No change.
v5->v6:
No change.
drivers/pinctrl/pinctrl-ingenic.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 3de0f76..72d9daa 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -1473,16 +1473,16 @@ static int x1830_ssi0_gpc_pins[] = { 0x4d, };
static int x1830_ssi0_ce0_pins[] = { 0x50, };
static int x1830_ssi0_ce1_pins[] = { 0x4e, };
static int x1830_ssi1_dt_c_pins[] = { 0x53, };
-static int x1830_ssi1_dr_c_pins[] = { 0x54, };
-static int x1830_ssi1_clk_c_pins[] = { 0x57, };
-static int x1830_ssi1_gpc_c_pins[] = { 0x55, };
-static int x1830_ssi1_ce0_c_pins[] = { 0x58, };
-static int x1830_ssi1_ce1_c_pins[] = { 0x56, };
static int x1830_ssi1_dt_d_pins[] = { 0x62, };
+static int x1830_ssi1_dr_c_pins[] = { 0x54, };
static int x1830_ssi1_dr_d_pins[] = { 0x63, };
+static int x1830_ssi1_clk_c_pins[] = { 0x57, };
static int x1830_ssi1_clk_d_pins[] = { 0x66, };
+static int x1830_ssi1_gpc_c_pins[] = { 0x55, };
static int x1830_ssi1_gpc_d_pins[] = { 0x64, };
+static int x1830_ssi1_ce0_c_pins[] = { 0x58, };
static int x1830_ssi1_ce0_d_pins[] = { 0x67, };
+static int x1830_ssi1_ce1_c_pins[] = { 0x56, };
static int x1830_ssi1_ce1_d_pins[] = { 0x65, };
static int x1830_mmc0_1bit_pins[] = { 0x24, 0x25, 0x20, };
static int x1830_mmc0_4bit_pins[] = { 0x21, 0x22, 0x23, };
--
2.7.4
[PATCH v6 04/12] pinctrl: Ingenic: Improve LCD pins related code.
1.In the JZ4740 part, remove pointless "lcd-no-pins", use "lcd-special"
and "lcd-generic" instead "lcd-18bit-tft". Currently, in the mainline,
no other devicetree out there is using the "lcd-18bit-tft" ABI, so we
should be able to replace it safely.
2.In the JZ4725B part, adjust the location of the LCD pins related code
to keep them consistent with the style of other parts.
3.In the JZ4760 part, add the missing comma and adjust element order in
"jz4760_lcd_special_pins[]", keep them in the order of CLS/SPL/PS/REV
like other "lcd_special_pins" arrays. And adjust the location of the
"jz4760_lcd_generic" related code to keep them consistent with the
style of other parts.
4.In the JZ4770 part, remove pointless "lcd-no-pins", add the missing
"lcd-16bit", "lcd-18bit", "lcd-special", "lcd-generic".
5.In the X1000 part and the X1500 part, remove pointless "lcd-no-pins".
6.In the X1830 part, replace "lcd-rgb-18bit" with "lcd-tft-8bit" and
"lcd-tft-24bit", because of the description of the TRANS_CONFIG.MODE
register bits in the PM manual of the X1830, shows that the X1830 only
supppots 24bit mode and 8bit mode for tft interface, only 18 pins in
the GPIO table are because of the data[17:16], the data[9:8], and the
data[1:0] has not been connected. And according to the description,
the two interfaces supported by X1830 are respectively referred to as
"TFT interface" and "SLCD interface", so the "lcd-rgb-xxx" is replaced
with "lcd-tft-xxx" to avoid confusion.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Paul Cercueil
---
Notes:
v4:
New patch.
v4->v5:
No change.
v5->v6:
Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 110 +-
1 file changed, 61 insertions(+), 49 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 72d9daa..8ed62a4 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -113,13 +113,15 @@ static int jz4740_uart0_data_pins[] = { 0x7a, 0x79, };
static int jz4740_uart0_hwflow_pins[] = { 0x7e, 0x7f, };
static int jz4740_uart1_data_pins[] = { 0x7e, 0x7f, };
static int jz4740_lcd_8bit_pins[] = {
- 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x52, 0x53, 0x54,
+ 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
+ 0x52, 0x53, 0x54,
};
static int jz4740_lcd_16bit_pins[] = {
- 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x55,
+ 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
};
static int jz4740_lcd_18bit_pins[] = { 0x50, 0x51, };
-static int jz4740_lcd_18bit_tft_pins[] = { 0x56, 0x57, 0x31, 0x32, };
+static int jz4740_lcd_special_pins[] = { 0x31, 0x32, 0x56, 0x57, };
+static int jz4740_lcd_generic_pins[] = { 0x55, };
static int jz4740_nand_cs1_pins[] = { 0x39, };
static int jz4740_nand_cs2_pins[] = { 0x3a, };
static int jz4740_nand_cs3_pins[] = { 0x3b, };
@@ -155,8 +157,8 @@ static const struct group_desc jz4740_groups[] = {
INGENIC_PIN_GROUP("lcd-8bit", jz4740_lcd_8bit, 0),
INGENIC_PIN_GROUP("lcd-16bit", jz4740_lcd_16bit, 0),
INGENIC_PIN_GROUP("lcd-18bit", jz4740_lcd_18bit, 0),
- INGENIC_PIN_GROUP("lcd-18bit-tft", jz4740_lcd_18bit_tft, 0),
- { "lcd-no-pins", },
+ INGENIC_PIN_GROUP("lcd-special", jz4740_lcd_special, 0),
+ INGENIC_PIN_GROUP("lcd-generic", jz4740_lcd_generic, 0),
INGENIC_PIN_GROUP("nand-cs1", jz4740_nand_cs1, 0),
INGENIC_PIN_GROUP("nand-cs2", jz4740_nand_cs2, 0),
INGENIC_PIN_GROUP("nand-cs3", jz4740_nand_cs3, 0),
@@ -176,7 +178,7 @@ static const char *jz4740_mmc_groups[] = { "mmc-1bit",
"mmc-4bit", };
static const char *jz4740_uart0_groups[] = { "uart0-data", "uart0-hwflow", };
static const char *jz4740_uart1_groups[] = { "uart1-data", };
static const char *jz4740_lcd_groups[] = {
- "lcd-8bit", "lcd-16bit", "lcd-18bit", "lcd-18bit-tft", "lcd-no-pins",
+ "lcd-8bit", "lcd-16bit", "lcd-18bit", "lcd-special", "lcd-generic",
};
static const char *jz4740_nand_groups[] = {
"nand-cs1", "nand-cs2", "nand-cs3", "nand-cs4", "nand-fre-fwe",
@@ -223,6 +225,17 @@ static int jz4725b_mmc0_4bit_pins[] = { 0x5d, 0x5b, 0x56,
};
static int jz4725b_mmc1_1bit_pins[] = { 0x7a, 0x7b, 0x7c, };
static int jz4725b_mmc1_4bit_pins[] = { 0x7d, 0x7e, 0x7f, };
static int jz4725b_uart_data_pins[] = { 0x4c, 0x4d, };
+static int jz4725b_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x72, 0x73, 0x74,
+};
+static int jz4725b_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+};
+static int jz4725b_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4725b_lcd_24bit_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4725b_lcd_special_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4725b_lcd_generic_pins[] = { 0x75, };
static int jz4725b_nand_cs1_pins[] = { 0x55, };
static int jz4725b_nand_cs2_pins[] = { 0x56, };
[PATCH v6 05/12] pinctrl: Ingenic: Add DMIC pins support for Ingenic SoCs.
1.Add DMIC pins support for the JZ4780 SoC.
2.Add DMIC pins support for the X1000 SoC.
3.Add DMIC pins support for the X1500 SoC.
4.Add DMIC pins support for the X1830 SoC.
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v6:
New patch.
drivers/pinctrl/pinctrl-ingenic.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 8ed62a4..b57433d 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -941,6 +941,7 @@ static int jz4780_i2s_data_rx_pins[] = { 0x86, };
static int jz4780_i2s_clk_txrx_pins[] = { 0x6c, 0x6d, };
static int jz4780_i2s_clk_rx_pins[] = { 0x88, 0x89, };
static int jz4780_i2s_sysclk_pins[] = { 0x85, };
+static int jz4780_dmic_pins[] = { 0x32, 0x33, };
static int jz4780_hdmi_ddc_pins[] = { 0xb9, 0xb8, };
static u8 jz4780_i2s_clk_txrx_funcs[] = { 1, 0, };
@@ -1039,6 +1040,7 @@ static const struct group_desc jz4780_groups[] = {
jz4780_i2s_clk_txrx_funcs),
INGENIC_PIN_GROUP("i2s-clk-rx", jz4780_i2s_clk_rx, 1),
INGENIC_PIN_GROUP("i2s-sysclk", jz4780_i2s_sysclk, 2),
+ INGENIC_PIN_GROUP("dmic", jz4780_dmic, 1),
INGENIC_PIN_GROUP("hdmi-ddc", jz4780_hdmi_ddc, 0),
INGENIC_PIN_GROUP("cim-data", jz4770_cim_8bit, 0),
INGENIC_PIN_GROUP("cim-data-12bit", jz4770_cim_12bit, 0),
@@ -1095,6 +1097,7 @@ static const char *jz4780_i2c4_groups[] = {
"i2c4-data-e", "i2c4-data-f", };
static const char *jz4780_i2s_groups[] = {
"i2s-data-tx", "i2s-data-rx", "i2s-clk-txrx", "i2s-clk-rx",
"i2s-sysclk",
};
+static const char *jz4780_dmic_groups[] = { "dmic", };
static const char *jz4780_cim_groups[] = { "cim-data", };
static const char *jz4780_hdmi_ddc_groups[] = { "hdmi-ddc", };
@@ -1122,6 +1125,7 @@ static const struct function_desc jz4780_functions[] = {
{ "i2c3", jz4780_i2c3_groups, ARRAY_SIZE(jz4780_i2c3_groups), },
{ "i2c4", jz4780_i2c4_groups, ARRAY_SIZE(jz4780_i2c4_groups), },
{ "i2s", jz4780_i2s_groups, ARRAY_SIZE(jz4780_i2s_groups), },
+ { "dmic", jz4780_dmic_groups, ARRAY_SIZE(jz4780_dmic_groups), },
{ "cim", jz4780_cim_groups, ARRAY_SIZE(jz4780_cim_groups), },
{ "lcd", jz4770_lcd_groups, ARRAY_SIZE(jz4770_lcd_groups), },
{ "pwm0", jz4770_pwm0_groups, ARRAY_SIZE(jz4770_pwm0_groups), },
@@ -1207,6 +1211,8 @@ static int x1000_i2s_data_tx_pins[] = { 0x24, };
static int x1000_i2s_data_rx_pins[] = { 0x23, };
static int x1000_i2s_clk_txrx_pins[] = { 0x21, 0x22, };
static int x1000_i2s_sysclk_pins[] = { 0x20, };
+static int x1000_dmic0_pins[] = { 0x35, 0x36, };
+static int x1000_dmic1_pins[] = { 0x25, };
static int x1000_cim_pins[] = {
0x08, 0x09, 0x0a, 0x0b,
0x13, 0x12, 0x11, 0x10, 0x0f, 0x0e, 0x0d, 0x0c,
@@ -1272,6 +1278,8 @@ static const struct group_desc x1000_groups[] = {
INGENIC_PIN_GROUP("i2s-data-rx", x1000_i2s_data_rx, 1),
INGENIC_PIN_GROUP("i2s-clk-txrx", x1000_i2s_clk_txrx, 1),
INGENIC_PIN_GROUP("i2s-sysclk", x1000_i2s_sysclk, 1),
+ INGENIC_PIN_GROUP("dmic0", x1000_dmic0, 0),
+ INGENIC_PIN_GROUP("dmic1", x1000_dmic1, 1),
INGENIC_PIN_GROUP("cim-data", x1000_cim, 2),
INGENIC_PIN_GROUP("lcd-8bit", x1000_lcd_8bit, 1),
INGENIC_PIN_GROUP("lcd-16bit", x1000_lcd_16bit, 1),
@@ -1315,6 +1323,7 @@ static const char *x1000_i2c2_groups[] = { "i2c2-data", };
static const char *x1000_i2s_groups[] = {
"i2s-data-tx", "i2s-data-rx", "i2s-clk-txrx", "i2s-sysclk",
};
+static const char *x1000_dmic_groups[] = { "dmic0", "dmic1", };
static const char *x1000_cim_groups[] = { "cim-data", };
static const char *x1000_lcd_groups[] = { "lcd-8bit", "lcd-16bit", };
static const char *x1000_pwm0_groups[] = { "pwm0", };
@@ -1339,6 +1348,7 @@ static const struct function_desc x1000_functions[] = {
{ "i2c1", x1000_i2c1_groups, ARRAY_SIZE(x1000_i2c1_groups), },
{ "i2c2", x1000_i2c2_groups, ARRAY_SIZE(x1000_i2c2_groups), },
{ "i2s", x1000_i2s_groups, ARRAY_SIZE(x1000_i2s_groups), },
+ { "dmic", x1000_dmic_groups, ARRAY_SIZE(x1000_dmic_groups), },
{ "cim", x1000_cim_groups, ARRAY_SIZE(x1000_cim_groups), },
{ "lcd", x1000_lcd_groups, ARRAY_SIZE(x1000_lcd_groups), },
{ "pwm0", x1000_pwm0_groups, ARRAY_SIZE(x1000_pwm0_groups), },
@@ -1378,6 +1388,8 @@ static int x1500_i2s_data_tx_pins[] = { 0x24, };
static int x1500_i2s_data_rx_pins[] = { 0x23, };
static int x1500_i2s_clk_txrx_pins[] = { 0x21, 0x22, };
static int x1500_i2s_sysclk_pins[] = { 0x20, };
+static int x1500_dmic0_pins[] = { 0x35, 0x36, };
+static int x1500_dmic1_pins[] = { 0x25, };
static int x1500_cim_pins[] = {
0x08, 0x09, 0x0a, 0x0b,
0x13, 0x12, 0x11, 0x10, 0x0f, 0x0e, 0x0d, 0x0c,
@@ -1407,6 +1419,8 @@ static const struct group_desc x1500_groups[] = {
INGENIC_PIN_GROUP("i2s-data-rx", x1500_i2s_data_rx, 1),
INGENI
[PATCH v6 07/12] dt-bindings: pinctrl: Add bindings for new Ingenic SoCs.
Add the pinctrl bindings for the JZ4730 SoC, the JZ4750 SoC, the JZ4755 SoC, the JZ4775 SoC and the X2000 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) Reviewed-by: Rob Herring --- Notes: v2: New patch. v2->v3: No change. v3->v4: 1.Add a description of JZ4725B. 2.Add Rob Herring's Reviewed-by. v4->v5: No change. v5->v6: No change. .../bindings/pinctrl/ingenic,pinctrl.yaml | 23 ++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index 44c04d1..a4846d78 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -17,10 +17,12 @@ description: > naming scheme "PxN" where x is a character identifying the GPIO port with which the pin is associated and N is an integer from 0 to 31 identifying the pin within that GPIO port. For example PA0 is the first pin in GPIO port A, - and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830 - contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the - JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192 - pins. + and PB31 is the last pin in GPIO port B. The JZ4730, the JZ4740, the JZ4725B, + the X1000 and the X1830 contains 4 GPIO ports, PA to PD, for a total of 128 + pins. The X2000 contains 5 GPIO ports, PA to PE, for a total of 160 pins. + The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains 6 GPIO + ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO ports, + PA to PG, for a total of 224 pins. maintainers: - Paul Cercueil @@ -32,20 +34,28 @@ properties: compatible: oneOf: - enum: + - ingenic,jz4730-pinctrl - ingenic,jz4740-pinctrl - ingenic,jz4725b-pinctrl + - ingenic,jz4750-pinctrl + - ingenic,jz4755-pinctrl - ingenic,jz4760-pinctrl - ingenic,jz4770-pinctrl + - ingenic,jz4775-pinctrl - ingenic,jz4780-pinctrl - ingenic,x1000-pinctrl - ingenic,x1500-pinctrl - ingenic,x1830-pinctrl + - ingenic,x2000-pinctrl - items: - const: ingenic,jz4760b-pinctrl - const: ingenic,jz4760-pinctrl - items: - const: ingenic,x1000e-pinctrl - const: ingenic,x1000-pinctrl + - items: + - const: ingenic,x2000e-pinctrl + - const: ingenic,x2000-pinctrl reg: maxItems: 1 @@ -62,14 +72,19 @@ patternProperties: properties: compatible: enum: + - ingenic,jz4730-gpio - ingenic,jz4740-gpio - ingenic,jz4725b-gpio + - ingenic,jz4750-gpio + - ingenic,jz4755-gpio - ingenic,jz4760-gpio - ingenic,jz4770-gpio + - ingenic,jz4775-gpio - ingenic,jz4780-gpio - ingenic,x1000-gpio - ingenic,x1500-gpio - ingenic,x1830-gpio + - ingenic,x2000-gpio reg: items: -- 2.7.4
[PATCH v6 06/12] pinctrl: Ingenic: Reformat the code.
1.Move the "INGENIC_PIN_GROUP_FUNCS" to the macro definition section.
2.Add tabs before values to align the code in the macro definition section.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v2:
New patch.
v2->v3:
Add Paul Cercueil's Reviewed-by.
v3->v4:
Add Andy Shevchenko's Reviewed-by.
v4->v5:
No change.
v5->v6:
No change.
drivers/pinctrl/pinctrl-ingenic.c | 71 +++
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index b57433d..e78f144 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -26,37 +26,48 @@
#include "pinconf.h"
#include "pinmux.h"
-#define GPIO_PIN 0x00
-#define GPIO_MSK 0x20
+#define GPIO_PIN 0x00
+#define GPIO_MSK 0x20
-#define JZ4740_GPIO_DATA 0x10
-#define JZ4740_GPIO_PULL_DIS 0x30
-#define JZ4740_GPIO_FUNC 0x40
-#define JZ4740_GPIO_SELECT 0x50
-#define JZ4740_GPIO_DIR0x60
-#define JZ4740_GPIO_TRIG 0x70
-#define JZ4740_GPIO_FLAG 0x80
+#define JZ4740_GPIO_DATA 0x10
+#define JZ4740_GPIO_PULL_DIS 0x30
+#define JZ4740_GPIO_FUNC 0x40
+#define JZ4740_GPIO_SELECT 0x50
+#define JZ4740_GPIO_DIR0x60
+#define JZ4740_GPIO_TRIG 0x70
+#define JZ4740_GPIO_FLAG 0x80
-#define JZ4770_GPIO_INT0x10
-#define JZ4770_GPIO_PAT1 0x30
-#define JZ4770_GPIO_PAT0 0x40
-#define JZ4770_GPIO_FLAG 0x50
-#define JZ4770_GPIO_PEN0x70
+#define JZ4770_GPIO_INT0x10
+#define JZ4770_GPIO_PAT1 0x30
+#define JZ4770_GPIO_PAT0 0x40
+#define JZ4770_GPIO_FLAG 0x50
+#define JZ4770_GPIO_PEN0x70
-#define X1830_GPIO_PEL 0x110
-#define X1830_GPIO_PEH 0x120
+#define X1830_GPIO_PEL 0x110
+#define X1830_GPIO_PEH 0x120
-#define REG_SET(x) ((x) + 0x4)
-#define REG_CLEAR(x) ((x) + 0x8)
+#define REG_SET(x) ((x) + 0x4)
+#define REG_CLEAR(x) ((x) + 0x8)
-#define REG_PZ_BASE(x) ((x) * 7)
-#define REG_PZ_GID2LD(x) ((x) * 7 + 0xf0)
+#define REG_PZ_BASE(x) ((x) * 7)
+#define REG_PZ_GID2LD(x) ((x) * 7 + 0xf0)
-#define GPIO_PULL_DIS 0
-#define GPIO_PULL_UP 1
-#define GPIO_PULL_DOWN 2
+#define GPIO_PULL_DIS 0
+#define GPIO_PULL_UP 1
+#define GPIO_PULL_DOWN 2
-#define PINS_PER_GPIO_CHIP 32
+#define PINS_PER_GPIO_CHIP 32
+
+#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
+ { \
+ name, \
+ id##_pins, \
+ ARRAY_SIZE(id##_pins), \
+ funcs, \
+ }
+
+#define INGENIC_PIN_GROUP(name, id, func) \
+ INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
enum jz_version {
ID_JZ4740,
@@ -136,18 +147,6 @@ static int jz4740_pwm_pwm5_pins[] = { 0x7c, };
static int jz4740_pwm_pwm6_pins[] = { 0x7e, };
static int jz4740_pwm_pwm7_pins[] = { 0x7f, };
-
-#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
- { \
- name, \
- id##_pins, \
- ARRAY_SIZE(id##_pins), \
- funcs, \
- }
-
-#define INGENIC_PIN_GROUP(name, id, func) \
- INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
-
static const struct group_desc jz4740_groups[] = {
INGENIC_PIN_GROUP("mmc-1bit", jz4740_mmc_1bit, 0),
INGENIC_PIN_GROUP("mmc-4bit", jz4740_mmc_4bit, 0),
--
2.7.4
[PATCH v6 08/12] pinctrl: Ingenic: Add pinctrl driver for JZ4730.
Add support for probing the pinctrl-ingenic driver on the
JZ4730 SoC from Ingenic.
This driver is derived from Paul Boddie. It is worth to
noting that the JZ4730 SoC is special in having two control
registers (upper/lower), so add code to handle the JZ4730
specific register offsets and some register pairs which have
2 bits for each GPIO pin.
Tested-by: H. Nikolaus Schaller # on Letux400
Co-developed-by: Paul Boddie
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v3:
New patch.
v3->v4:
1.Use "lcd-special" and "lcd-generic" instead "lcd-16bit-tft".
2.Adjust function names to avoid confusion.
3.Improve the structure of some functions.
4.Modify the format of comment.
5.Simplify code using GENMASK.
6.Drop unnecessary mask.
v4->v5:
No change.
v5->v6:
Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 232 +++---
1 file changed, 216 insertions(+), 16 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index e78f144..19c3646 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -3,8 +3,8 @@
* Ingenic SoCs pinctrl driver
*
* Copyright (c) 2017 Paul Cercueil
- * Copyright (c) 2019 周琰杰 (Zhou Yanjie)
* Copyright (c) 2017, 2019 Paul Boddie
+ * Copyright (c) 2019, 2020 周琰杰 (Zhou Yanjie)
*/
#include
@@ -29,6 +29,17 @@
#define GPIO_PIN 0x00
#define GPIO_MSK 0x20
+#define JZ4730_GPIO_DATA 0x00
+#define JZ4730_GPIO_GPDIR 0x04
+#define JZ4730_GPIO_GPPUR 0x0c
+#define JZ4730_GPIO_GPALR 0x10
+#define JZ4730_GPIO_GPAUR 0x14
+#define JZ4730_GPIO_GPIDLR 0x18
+#define JZ4730_GPIO_GPIDUR 0x1c
+#define JZ4730_GPIO_GPIER 0x20
+#define JZ4730_GPIO_GPIMR 0x24
+#define JZ4730_GPIO_GPFR 0x28
+
#define JZ4740_GPIO_DATA 0x10
#define JZ4740_GPIO_PULL_DIS 0x30
#define JZ4740_GPIO_FUNC 0x40
@@ -57,6 +68,7 @@
#define GPIO_PULL_DOWN 2
#define PINS_PER_GPIO_CHIP 32
+#define JZ4730_PINS_PER_PAIRED_REG 16
#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
{ \
@@ -70,6 +82,7 @@
INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
enum jz_version {
+ ID_JZ4730,
ID_JZ4740,
ID_JZ4725B,
ID_JZ4760,
@@ -110,6 +123,99 @@ struct ingenic_gpio_chip {
unsigned int irq, reg_base;
};
+static const u32 jz4730_pull_ups[4] = {
+ 0x3fa3320f, 0xf200, 0x, 0x,
+};
+
+static const u32 jz4730_pull_downs[4] = {
+ 0x0df0, 0x0dff, 0x, 0x,
+};
+
+static int jz4730_mmc_1bit_pins[] = { 0x27, 0x26, 0x22, };
+static int jz4730_mmc_4bit_pins[] = { 0x23, 0x24, 0x25, };
+static int jz4730_uart0_data_pins[] = { 0x7e, 0x7f, };
+static int jz4730_uart1_data_pins[] = { 0x18, 0x19, };
+static int jz4730_uart2_data_pins[] = { 0x6f, 0x7d, };
+static int jz4730_uart3_data_pins[] = { 0x10, 0x15, };
+static int jz4730_uart3_hwflow_pins[] = { 0x11, 0x17, };
+static int jz4730_lcd_8bit_pins[] = {
+ 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+ 0x3a, 0x39, 0x38,
+};
+static int jz4730_lcd_16bit_pins[] = {
+ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+};
+static int jz4730_lcd_special_pins[] = { 0x3d, 0x3c, 0x3e, 0x3f, };
+static int jz4730_lcd_generic_pins[] = { 0x3b, };
+static int jz4730_nand_cs1_pins[] = { 0x53, };
+static int jz4730_nand_cs2_pins[] = { 0x54, };
+static int jz4730_nand_cs3_pins[] = { 0x55, };
+static int jz4730_nand_cs4_pins[] = { 0x56, };
+static int jz4730_nand_cs5_pins[] = { 0x57, };
+static int jz4730_pwm_pwm0_pins[] = { 0x5e, };
+static int jz4730_pwm_pwm1_pins[] = { 0x5f, };
+
+static u8 jz4730_lcd_8bit_funcs[] = { 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, };
+
+static const struct group_desc jz4730_groups[] = {
+ INGENIC_PIN_GROUP("mmc-1bit", jz4730_mmc_1bit, 1),
+ INGENIC_PIN_GROUP("mmc-4bit", jz4730_mmc_4bit, 1),
+ INGENIC_PIN_GROUP("uart0-data", jz4730_uart0_data, 1),
+ INGENIC_PIN_GROUP("uart1-data", jz4730_uart1_data, 1),
+ INGENIC_PIN_GROUP("uart2-data", jz4730_uart2_data, 1),
+ INGENIC_PIN_GROUP("uart3-data", jz4730_uart3_data, 1),
+ INGENIC_PIN_GROUP("uart3-hwflow", jz4730_uart3_hwflow, 1),
+ INGENIC_PIN_GROUP_FUNCS("lcd-8bit", jz4730_lcd_8bit,
jz4730_lcd_8bit_funcs),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4730_lcd_16bit, 1),
+ INGENIC_PIN_GROUP("lcd-special", jz4730_lcd_special, 1),
[PATCH v6 09/12] pinctrl: Ingenic: Add pinctrl driver for JZ4750.
Add support for probing the pinctrl-ingenic driver on the
JZ4750 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v3:
New patch.
v3->v4:
1.Use "lcd-special" and "lcd-generic" instead "lcd-18bit-tft".
2.Drop "lcd-no-pins" which is pointless.
v4->v5:
No change.
v5->v6:
1.Add the missing lcd-24bit group.
2.Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 142 ++
1 file changed, 142 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 19c3646..6154e481 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -85,6 +85,7 @@ enum jz_version {
ID_JZ4730,
ID_JZ4740,
ID_JZ4725B,
+ ID_JZ4750,
ID_JZ4760,
ID_JZ4770,
ID_JZ4780,
@@ -427,6 +428,143 @@ static const struct ingenic_chip_info jz4725b_chip_info =
{
.pull_downs = jz4740_pull_downs,
};
+static const u32 jz4750_pull_ups[6] = {
+ 0x, 0x, 0x3fff, 0x7fff, 0x1fff3fff, 0x00ff,
+};
+
+static const u32 jz4750_pull_downs[6] = {
+ 0x, 0x, 0x, 0x, 0x, 0x,
+};
+
+static int jz4750_uart0_data_pins[] = { 0xa4, 0xa5, };
+static int jz4750_uart0_hwflow_pins[] = { 0xa6, 0xa7, };
+static int jz4750_uart1_data_pins[] = { 0x90, 0x91, };
+static int jz4750_uart1_hwflow_pins[] = { 0x92, 0x93, };
+static int jz4750_uart2_data_pins[] = { 0x9b, 0x9a, };
+static int jz4750_uart3_data_pins[] = { 0xb0, 0xb1, };
+static int jz4750_uart3_hwflow_pins[] = { 0xb2, 0xb3, };
+static int jz4750_mmc0_1bit_pins[] = { 0xa8, 0xa9, 0xa0, };
+static int jz4750_mmc0_4bit_pins[] = { 0xa1, 0xa2, 0xa3, };
+static int jz4750_mmc0_8bit_pins[] = { 0xa4, 0xa5, 0xa6, 0xa7, };
+static int jz4750_mmc1_1bit_pins[] = { 0xae, 0xaf, 0xaa, };
+static int jz4750_mmc1_4bit_pins[] = { 0xab, 0xac, 0xad, };
+static int jz4750_i2c_pins[] = { 0x8c, 0x8d, };
+static int jz4750_cim_pins[] = {
+ 0x89, 0x8b, 0x8a, 0x88,
+ 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+};
+static int jz4750_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x72, 0x73, 0x74,
+};
+static int jz4750_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+};
+static int jz4750_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4750_lcd_24bit_pins[] = { 0x76, 0x77, 0x78, 0x79, 0xb2, 0xb3, };
+static int jz4750_lcd_special_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4750_lcd_generic_pins[] = { 0x75, };
+static int jz4750_nand_cs1_pins[] = { 0x55, };
+static int jz4750_nand_cs2_pins[] = { 0x56, };
+static int jz4750_nand_cs3_pins[] = { 0x57, };
+static int jz4750_nand_cs4_pins[] = { 0x58, };
+static int jz4750_nand_fre_fwe_pins[] = { 0x5c, 0x5d, };
+static int jz4750_pwm_pwm0_pins[] = { 0x94, };
+static int jz4750_pwm_pwm1_pins[] = { 0x95, };
+static int jz4750_pwm_pwm2_pins[] = { 0x96, };
+static int jz4750_pwm_pwm3_pins[] = { 0x97, };
+static int jz4750_pwm_pwm4_pins[] = { 0x98, };
+static int jz4750_pwm_pwm5_pins[] = { 0x99, };
+
+static const struct group_desc jz4750_groups[] = {
+ INGENIC_PIN_GROUP("uart0-data", jz4750_uart0_data, 1),
+ INGENIC_PIN_GROUP("uart0-hwflow", jz4750_uart0_hwflow, 1),
+ INGENIC_PIN_GROUP("uart1-data", jz4750_uart1_data, 0),
+ INGENIC_PIN_GROUP("uart1-hwflow", jz4750_uart1_hwflow, 0),
+ INGENIC_PIN_GROUP("uart2-data", jz4750_uart2_data, 1),
+ INGENIC_PIN_GROUP("uart3-data", jz4750_uart3_data, 0),
+ INGENIC_PIN_GROUP("uart3-hwflow", jz4750_uart3_hwflow, 0),
+ INGENIC_PIN_GROUP("mmc0-1bit", jz4750_mmc0_1bit, 0),
+ INGENIC_PIN_GROUP("mmc0-4bit", jz4750_mmc0_4bit, 0),
+ INGENIC_PIN_GROUP("mmc0-8bit", jz4750_mmc0_8bit, 0),
+ INGENIC_PIN_GROUP("mmc1-1bit", jz4750_mmc1_1bit, 0),
+ INGENIC_PIN_GROUP("mmc1-4bit", jz4750_mmc1_4bit, 0),
+ INGENIC_PIN_GROUP("i2c-data", jz4750_i2c, 0),
+ INGENIC_PIN_GROUP("cim-data", jz4750_cim, 0),
+ INGENIC_PIN_GROUP("lcd-8bit", jz4750_lcd_8bit, 0),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4750_lcd_16bit, 0),
+ INGENIC_PIN_GROUP("lcd-18bit", jz4750_lcd_18bit, 0),
+ INGENIC_PIN_GROUP("lcd-24bit", jz4750_lcd_24bit, 1),
+ INGENIC_PIN_GROUP("lcd-special", jz4750_lcd_special, 0),
+ INGENIC_PIN_GROUP("lcd-generic", jz4750_lcd_generic, 0),
+ INGENIC_PIN_GROUP("nand-cs1", jz4750_nand_cs1, 0),
+ INGENIC_PIN_GROUP("nand-cs2", jz4750_nand_cs2, 0),
+ INGENIC_PIN_GROUP("nand-cs3", jz4750_nand_cs3, 0),
+ INGENIC_PIN_GROUP("nand-cs4", jz4750_nand_cs4, 0),
+ INGENIC_PIN_GROUP("nand-fre-fwe", jz4750_nand_fre_fwe, 0),
+ INGENIC_PIN_GROUP("pwm0", jz4750_pwm_pwm0, 0),
+ INGENIC_PIN_GROUP("pwm1", jz4750_pwm_pwm1, 0),
+ INGENIC_PIN_GROUP("pwm2", jz4750_pwm_pwm2, 0),
+
[PATCH v6 10/12] pinctrl: Ingenic: Add pinctrl driver for JZ4755.
Add support for probing the pinctrl-ingenic driver on the
JZ4755 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v3:
New patch.
v3->v4:
1.Split LCD pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
v4->v5:
No change.
v5->v6:
Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 139 ++
1 file changed, 139 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 6154e481..0c0f163 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -86,6 +86,7 @@ enum jz_version {
ID_JZ4740,
ID_JZ4725B,
ID_JZ4750,
+ ID_JZ4755,
ID_JZ4760,
ID_JZ4770,
ID_JZ4780,
@@ -565,6 +566,138 @@ static const struct ingenic_chip_info jz4750_chip_info = {
.pull_downs = jz4750_pull_downs,
};
+static const u32 jz4755_pull_ups[6] = {
+ 0x, 0x, 0x0fff, 0x, 0x33dc3fff, 0xfc00,
+};
+
+static const u32 jz4755_pull_downs[6] = {
+ 0x, 0x, 0x, 0x, 0x, 0x,
+};
+
+static int jz4755_uart0_data_pins[] = { 0x7c, 0x7d, };
+static int jz4755_uart0_hwflow_pins[] = { 0x7e, 0x7f, };
+static int jz4755_uart1_data_pins[] = { 0x97, 0x99, };
+static int jz4755_uart2_data_pins[] = { 0x9f, };
+static int jz4755_mmc0_1bit_pins[] = { 0x2f, 0x50, 0x5c, };
+static int jz4755_mmc0_4bit_pins[] = { 0x5d, 0x5b, 0x51, };
+static int jz4755_mmc1_1bit_pins[] = { 0x3a, 0x3d, 0x3c, };
+static int jz4755_mmc1_4bit_pins[] = { 0x3b, 0x3e, 0x3f, };
+static int jz4755_i2c_pins[] = { 0x8c, 0x8d, };
+static int jz4755_cim_pins[] = {
+ 0x89, 0x8b, 0x8a, 0x88,
+ 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+};
+static int jz4755_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x72, 0x73, 0x74,
+};
+static int jz4755_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+};
+static int jz4755_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4755_lcd_24bit_pins[] = { 0x76, 0x77, 0x78, 0x79, 0x7a, 0x7b, };
+static int jz4755_lcd_special_pins[] = { 0x76, 0x77, 0x78, 0x79, };
+static int jz4755_lcd_generic_pins[] = { 0x75, };
+static int jz4755_nand_cs1_pins[] = { 0x55, };
+static int jz4755_nand_cs2_pins[] = { 0x56, };
+static int jz4755_nand_cs3_pins[] = { 0x57, };
+static int jz4755_nand_cs4_pins[] = { 0x58, };
+static int jz4755_nand_fre_fwe_pins[] = { 0x5c, 0x5d, };
+static int jz4755_pwm_pwm0_pins[] = { 0x94, };
+static int jz4755_pwm_pwm1_pins[] = { 0xab, };
+static int jz4755_pwm_pwm2_pins[] = { 0x96, };
+static int jz4755_pwm_pwm3_pins[] = { 0x97, };
+static int jz4755_pwm_pwm4_pins[] = { 0x98, };
+static int jz4755_pwm_pwm5_pins[] = { 0x99, };
+
+static u8 jz4755_mmc0_1bit_funcs[] = { 2, 2, 1, };
+static u8 jz4755_mmc0_4bit_funcs[] = { 1, 0, 1, };
+static u8 jz4755_lcd_24bit_funcs[] = { 1, 1, 1, 1, 0, 0, };
+
+static const struct group_desc jz4755_groups[] = {
+ INGENIC_PIN_GROUP("uart0-data", jz4755_uart0_data, 0),
+ INGENIC_PIN_GROUP("uart0-hwflow", jz4755_uart0_hwflow, 0),
+ INGENIC_PIN_GROUP("uart1-data", jz4755_uart1_data, 0),
+ INGENIC_PIN_GROUP("uart2-data", jz4755_uart2_data, 1),
+ INGENIC_PIN_GROUP_FUNCS("mmc0-1bit", jz4755_mmc0_1bit,
+ jz4755_mmc0_1bit_funcs),
+ INGENIC_PIN_GROUP_FUNCS("mmc0-4bit", jz4755_mmc0_4bit,
+ jz4755_mmc0_4bit_funcs),
+ INGENIC_PIN_GROUP("mmc1-1bit", jz4755_mmc1_1bit, 1),
+ INGENIC_PIN_GROUP("mmc1-4bit", jz4755_mmc1_4bit, 1),
+ INGENIC_PIN_GROUP("i2c-data", jz4755_i2c, 0),
+ INGENIC_PIN_GROUP("cim-data", jz4755_cim, 0),
+ INGENIC_PIN_GROUP("lcd-8bit", jz4755_lcd_8bit, 0),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4755_lcd_16bit, 0),
+ INGENIC_PIN_GROUP("lcd-18bit", jz4755_lcd_18bit, 0),
+ INGENIC_PIN_GROUP_FUNCS("lcd-24bit", jz4755_lcd_24bit,
+ jz4755_lcd_24bit_funcs),
+ INGENIC_PIN_GROUP("lcd-special", jz4755_lcd_special, 0),
+ INGENIC_PIN_GROUP("lcd-generic", jz4755_lcd_generic, 0),
+ INGENIC_PIN_GROUP("nand-cs1", jz4755_nand_cs1, 0),
+ INGENIC_PIN_GROUP("nand-cs2", jz4755_nand_cs2, 0),
+ INGENIC_PIN_GROUP("nand-cs3", jz4755_nand_cs3, 0),
+ INGENIC_PIN_GROUP("nand-cs4", jz4755_nand_cs4, 0),
+ INGENIC_PIN_GROUP("nand-fre-fwe", jz4755_nand_fre_fwe, 0),
+ INGENIC_PIN_GROUP("pwm0", jz4755_pwm_pwm0, 0),
+ INGENIC_PIN_GROUP("pwm1", jz4755_pwm_pwm1, 1),
+ INGENIC_PIN_GROUP("pwm2", jz4755_pwm_pwm2, 0),
+ INGENIC_PIN_GROUP("pwm3", jz4755_pwm_pwm3, 0),
+ INGENIC_PIN_GROUP("pwm4", jz4755_pwm_pwm4, 0),
+ INGENIC_PIN_GROUP("pwm5", jz4755_pwm_pwm5, 0),
+};
+
+static const char *jz4755_uart0_groups[] = { "uart0-data",
[PATCH v6 11/12] pinctrl: Ingenic: Add pinctrl driver for JZ4775.
Add support for probing the pinctrl-ingenic driver on the
JZ4775 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v3:
New patch.
v3->v4:
1.Split LCD pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
v4->v5:
No change.
v5->v6:
1.Add DMIC pins support for JZ4775.
2.Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 279 ++
1 file changed, 279 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 0c0f163..58e90f5 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -89,6 +89,7 @@ enum jz_version {
ID_JZ4755,
ID_JZ4760,
ID_JZ4770,
+ ID_JZ4775,
ID_JZ4780,
ID_X1000,
ID_X1500,
@@ -1264,6 +1265,279 @@ static const struct ingenic_chip_info jz4770_chip_info
= {
.pull_downs = jz4770_pull_downs,
};
+static const u32 jz4775_pull_ups[7] = {
+ 0x28ff00ff, 0xf030f3fc, 0x0fff, 0xfffe4000, 0xf0fc, 0xf00f,
0xf3c0,
+};
+
+static const u32 jz4775_pull_downs[7] = {
+ 0x, 0x00030c03, 0x, 0x8000, 0x0403, 0x0ff0,
0x00030c00,
+};
+
+static int jz4775_uart0_data_pins[] = { 0xa0, 0xa3, };
+static int jz4775_uart0_hwflow_pins[] = { 0xa1, 0xa2, };
+static int jz4775_uart1_data_pins[] = { 0x7a, 0x7c, };
+static int jz4775_uart1_hwflow_pins[] = { 0x7b, 0x7d, };
+static int jz4775_uart2_data_c_pins[] = { 0x54, 0x4a, };
+static int jz4775_uart2_data_f_pins[] = { 0xa5, 0xa4, };
+static int jz4775_uart3_data_pins[] = { 0x1e, 0x1f, };
+static int jz4775_ssi_dt_a_pins[] = { 0x13, };
+static int jz4775_ssi_dt_d_pins[] = { 0x75, };
+static int jz4775_ssi_dr_a_pins[] = { 0x14, };
+static int jz4775_ssi_dr_d_pins[] = { 0x74, };
+static int jz4775_ssi_clk_a_pins[] = { 0x12, };
+static int jz4775_ssi_clk_d_pins[] = { 0x78, };
+static int jz4775_ssi_gpc_pins[] = { 0x76, };
+static int jz4775_ssi_ce0_a_pins[] = { 0x17, };
+static int jz4775_ssi_ce0_d_pins[] = { 0x79, };
+static int jz4775_ssi_ce1_pins[] = { 0x77, };
+static int jz4775_mmc0_1bit_a_pins[] = { 0x12, 0x13, 0x14, };
+static int jz4775_mmc0_4bit_a_pins[] = { 0x15, 0x16, 0x17, };
+static int jz4775_mmc0_8bit_a_pins[] = { 0x04, 0x05, 0x06, 0x07, };
+static int jz4775_mmc0_1bit_e_pins[] = { 0x9c, 0x9d, 0x94, };
+static int jz4775_mmc0_4bit_e_pins[] = { 0x95, 0x96, 0x97, };
+static int jz4775_mmc1_1bit_d_pins[] = { 0x78, 0x79, 0x74, };
+static int jz4775_mmc1_4bit_d_pins[] = { 0x75, 0x76, 0x77, };
+static int jz4775_mmc1_1bit_e_pins[] = { 0x9c, 0x9d, 0x94, };
+static int jz4775_mmc1_4bit_e_pins[] = { 0x95, 0x96, 0x97, };
+static int jz4775_mmc2_1bit_b_pins[] = { 0x3c, 0x3d, 0x34, };
+static int jz4775_mmc2_4bit_b_pins[] = { 0x35, 0x3e, 0x3f, };
+static int jz4775_mmc2_1bit_e_pins[] = { 0x9c, 0x9d, 0x94, };
+static int jz4775_mmc2_4bit_e_pins[] = { 0x95, 0x96, 0x97, };
+static int jz4775_nemc_8bit_data_pins[] = {
+ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+};
+static int jz4775_nemc_16bit_data_pins[] = {
+ 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd1,
+};
+static int jz4775_nemc_cle_ale_pins[] = { 0x20, 0x21, };
+static int jz4775_nemc_addr_pins[] = { 0x22, 0x23, 0x24, 0x25, };
+static int jz4775_nemc_rd_we_pins[] = { 0x10, 0x11, };
+static int jz4775_nemc_frd_fwe_pins[] = { 0x12, 0x13, };
+static int jz4775_nemc_wait_pins[] = { 0x1b, };
+static int jz4775_nemc_cs1_pins[] = { 0x15, };
+static int jz4775_nemc_cs2_pins[] = { 0x16, };
+static int jz4775_nemc_cs3_pins[] = { 0x17, };
+static int jz4775_i2c0_pins[] = { 0x7e, 0x7f, };
+static int jz4775_i2c1_pins[] = { 0x9e, 0x9f, };
+static int jz4775_i2c2_pins[] = { 0x80, 0x83, };
+static int jz4775_i2s_data_tx_pins[] = { 0xa3, };
+static int jz4775_i2s_data_rx_pins[] = { 0xa2, };
+static int jz4775_i2s_clk_txrx_pins[] = { 0xa0, 0xa1, };
+static int jz4775_i2s_sysclk_pins[] = { 0x83, };
+static int jz4775_dmic_pins[] = { 0xaa, 0xab, };
+static int jz4775_cim_pins[] = {
+ 0x26, 0x27, 0x28, 0x29,
+ 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31,
+};
+static int jz4775_lcd_8bit_pins[] = {
+ 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x4c, 0x4d,
+ 0x48, 0x52, 0x53,
+};
+static int jz4775_lcd_16bit_pins[] = {
+ 0x4e, 0x4f, 0x50, 0x51, 0x56, 0x57, 0x58, 0x59,
+};
+static int jz4775_lcd_18bit_pins[] = {
+ 0x5a, 0x5b,
+};
+static int jz4775_lcd_24bit_pins[] = {
+ 0x40, 0x41, 0x4a, 0x4b, 0x54, 0x55,
+};
+static int jz4775_lcd_special_pins[] = { 0x54, 0x4a, 0x41, 0x40, };
+static int jz4775_lcd_generic_pins[] = { 0x49, };
+static int jz4775_pwm_pwm0_pins[] = { 0x80, };
+static int jz4775_pwm_pwm1_pins[] = { 0x81, };
+static int jz4775_pwm_pwm2_pins[] = { 0x82, };
+static int jz4775_pwm_pwm3_pins[] = { 0x83, };
+static int jz4775_mac_rmii_pins[] = {
+ 0xa9, 0xab, 0xaa, 0xac, 0xa5, 0xa4, 0xad, 0
[PATCH v6 12/12] pinctrl: Ingenic: Add pinctrl driver for X2000.
Add support for probing the pinctrl-ingenic driver on the
X2000 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
---
Notes:
v3:
New patch.
v3->v4:
1.Split LCD pins into several groups.
2.Drop "lcd-no-pins" which is pointless.
3.Replace "lcd-rgb-xxx" with "lcd-tft-xxx" to avoid confusion.
v4->v5:
Add support for schmitt and slew.
v5->v6:
1.Adjust and simplify the code.
2.Add DMIC pins support for X2000.
3.Add Paul Cercueil's Reviewed-by.
drivers/pinctrl/pinctrl-ingenic.c | 592 +-
1 file changed, 579 insertions(+), 13 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 58e90f5..41ada1d 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -56,6 +56,14 @@
#define X1830_GPIO_PEL 0x110
#define X1830_GPIO_PEH 0x120
+#define X1830_GPIO_SR 0x150
+#define X1830_GPIO_SMT 0x160
+
+#define X2000_GPIO_EDG 0x70
+#define X2000_GPIO_PEPU0x80
+#define X2000_GPIO_PEPD0x90
+#define X2000_GPIO_SR 0xd0
+#define X2000_GPIO_SMT 0xe0
#define REG_SET(x) ((x) + 0x4)
#define REG_CLEAR(x) ((x) + 0x8)
@@ -94,6 +102,7 @@ enum jz_version {
ID_X1000,
ID_X1500,
ID_X1830,
+ ID_X2000,
};
struct ingenic_chip_info {
@@ -2342,6 +2351,456 @@ static const struct ingenic_chip_info x1830_chip_info =
{
.pull_downs = x1830_pull_downs,
};
+static const u32 x2000_pull_ups[5] = {
+ 0x0003, 0x, 0x1ff0, 0xc7fe3f3f, 0x8fff003f,
+};
+
+static const u32 x2000_pull_downs[5] = {
+ 0x0003, 0x, 0x1ff0, 0x, 0x8fff003f,
+};
+
+static int x2000_uart0_data_pins[] = { 0x77, 0x78, };
+static int x2000_uart0_hwflow_pins[] = { 0x79, 0x7a, };
+static int x2000_uart1_data_pins[] = { 0x57, 0x58, };
+static int x2000_uart1_hwflow_pins[] = { 0x55, 0x56, };
+static int x2000_uart2_data_pins[] = { 0x7e, 0x7f, };
+static int x2000_uart3_data_c_pins[] = { 0x59, 0x5a, };
+static int x2000_uart3_data_d_pins[] = { 0x62, 0x63, };
+static int x2000_uart3_hwflow_c_pins[] = { 0x5b, 0x5c, };
+static int x2000_uart3_hwflow_d_pins[] = { 0x60, 0x61, };
+static int x2000_uart4_data_a_pins[] = { 0x02, 0x03, };
+static int x2000_uart4_data_c_pins[] = { 0x4b, 0x4c, };
+static int x2000_uart4_hwflow_a_pins[] = { 0x00, 0x01, };
+static int x2000_uart4_hwflow_c_pins[] = { 0x49, 0x4a, };
+static int x2000_uart5_data_a_pins[] = { 0x04, 0x05, };
+static int x2000_uart5_data_c_pins[] = { 0x45, 0x46, };
+static int x2000_uart6_data_a_pins[] = { 0x06, 0x07, };
+static int x2000_uart6_data_c_pins[] = { 0x47, 0x48, };
+static int x2000_uart7_data_a_pins[] = { 0x08, 0x09, };
+static int x2000_uart7_data_c_pins[] = { 0x41, 0x42, };
+static int x2000_uart8_data_pins[] = { 0x3c, 0x3d, };
+static int x2000_uart9_data_pins[] = { 0x3e, 0x3f, };
+static int x2000_sfc0_d_pins[] = { 0x73, 0x74, 0x75, 0x76, 0x71, 0x72, };
+static int x2000_sfc0_e_pins[] = { 0x92, 0x93, 0x94, 0x95, 0x90, 0x91, };
+static int x2000_sfc1_pins[] = { 0x77, 0x78, 0x79, 0x7a, };
+static int x2000_ssi0_dt_b_pins[] = { 0x3e, };
+static int x2000_ssi0_dt_d_pins[] = { 0x69, };
+static int x2000_ssi0_dr_b_pins[] = { 0x3d, };
+static int x2000_ssi0_dr_d_pins[] = { 0x6a, };
+static int x2000_ssi0_clk_b_pins[] = { 0x3f, };
+static int x2000_ssi0_clk_d_pins[] = { 0x68, };
+static int x2000_ssi0_ce0_b_pins[] = { 0x3c, };
+static int x2000_ssi0_ce0_d_pins[] = { 0x6d, };
+static int x2000_ssi1_dt_c_pins[] = { 0x4b, };
+static int x2000_ssi1_dt_d_pins[] = { 0x72, };
+static int x2000_ssi1_dt_e_pins[] = { 0x91, };
+static int x2000_ssi1_dr_c_pins[] = { 0x4a, };
+static int x2000_ssi1_dr_d_pins[] = { 0x73, };
+static int x2000_ssi1_dr_e_pins[] = { 0x92, };
+static int x2000_ssi1_clk_c_pins[] = { 0x4c, };
+static int x2000_ssi1_clk_d_pins[] = { 0x71, };
+static int x2000_ssi1_clk_e_pins[] = { 0x90, };
+static int x2000_ssi1_ce0_c_pins[] = { 0x49, };
+static int x2000_ssi1_ce0_d_pins[] = { 0x76, };
+static int x2000_ssi1_ce0_e_pins[] = { 0x95, };
+static int x2000_mmc0_1bit_pins[] = { 0x71, 0x72, 0x73, };
+static int x2000_mmc0_4bit_pins[] = { 0x74, 0x75, 0x75, };
+static int x2000_mmc0_8bit_pins[] = { 0x77, 0x78, 0x79, 0x7a, };
+static int x2000_mmc1_1bit_pins[] = { 0x68, 0x69, 0x6a, };
+static int x2000_mmc1_4bit_pins[] = { 0x6b, 0x6c, 0x6d, };
+static int x2000_mmc2_1bit_pins[] = { 0x80, 0x81, 0x82, };
+static int x2000_mmc2_4bit_pins[] = { 0x83, 0x84, 0x85, };
+static int x2000_emc_8bit_data_pins[] = {
+ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+};
+static int x2000_emc_16bit_data_pins[] = {
+
Re: [PATCH v4 5/5] clk: ti: add am33xx/am43xx spread spectrum clock support
Hi Tero,
> Il 16/04/2021 14:43 Tero Kristo ha scritto:
>
>
> Hi Dario,
>
> Spent some time looking at this, had to read through the TRM chapter of
> it also in quite detailed level to figure out how this is supposed to
> work out.
>
> Other than couple of minor nits below, the code seems ok to me. What is
> the testing that has been done with this?
The patch has been tested with laboratory instrumentation and is currently
used on a custom board based on a AM335x SOC with a TI 4.1.6 kernel. It was
born
from the need to reduce the electromagnetic emissions of the display to pass the
EMI certifications. The current patch is a port of that to the mainline kernel.
The corrections to be made were minimal and not significant. I'm testing it on
a
beaglebone black board, verifying with devmem that the DPLL registers are
correctly
set.
>
> On 01/04/2021 22:37, Dario Binacchi wrote:
> > The patch enables spread spectrum clocking (SSC) for MPU and LCD PLLs.
> > As reported by the TI spruh73x/spruhl7x RM, SSC is only supported for
> > the DISP/LCD and MPU PLLs on am33xx/am43xx. SSC is not supported for
> > DDR, PER, and CORE PLLs.
> >
> > Calculating the required values and setting the registers accordingly
> > was taken from the set_mpu_spreadspectrum routine contained in the
> > arch/arm/mach-omap2/am33xx/clock_am33xx.c file of the u-boot project.
> >
> > In locked condition, DPLL output clock = CLKINP *[M/N]. In case of
> > SSC enabled, the reference manual explains that there is a restriction
> > of range of M values. Since the omap2_dpll_round_rate routine attempts
> > to select the minimum possible N, the value of M obtained is not
> > guaranteed to be within the range required. With the new "ti,min-div"
> > parameter it is possible to increase N and consequently M to satisfy the
> > constraint imposed by SSC.
> >
> > Signed-off-by: Dario Binacchi
> >
> > ---
>
>
>
> > /* REVISIT: Set ramp-up delay? */
> > diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
> > index c62f6fa6763d..cba093de62d8 100644
> > --- a/include/linux/clk/ti.h
> > +++ b/include/linux/clk/ti.h
> > @@ -63,6 +63,18 @@ struct clk_omap_reg {
> >* @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
> >* @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration
> > IRQs
> >* @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration
> > IRQs
> > + * @ssc_deltam_reg: register containing the DPLL SSC frequency spreading
> > + * @ssc_modfreq_reg: register containing the DPLL SSC modulation frequency
> > + * @ssc_modfreq_mant_mask: mask of the mantissa component in
> > @ssc_modfreq_reg
> > + * @ssc_modfreq_exp_mask: mask of the exponent component in
> > @ssc_modfreq_reg
> > + * @ssc_enable_mask: mask of the DPLL SSC enable bit in @control_reg
> > + * @ssc_ack_mask: mask of the DPLL SSC turned on/off bit in @control_reg
> > + * @ssc_downspread_mask: mask of the DPLL SSC low frequency only bit in
> > + * @control_reg
> > + * @ssc_modfreq: the DPLL SSC frequency modulation in kHz
> > + * @ssc_deltam: the DPLL SSC frequency spreading in permille (10th of
> > percent)
> > + * @ssc_downspread: require the only low frequency spread of the DPLL in
> > SSC
> > + * mode
> >* @flags: DPLL type/features (see below)
> >*
> >* Possible values for @flags:
> > @@ -110,6 +122,18 @@ struct dpll_data {
> > u8 auto_recal_bit;
> > u8 recal_en_bit;
> > u8 recal_st_bit;
> > + struct clk_omap_reg ssc_deltam_reg;
> > + struct clk_omap_reg ssc_modfreq_reg;
> > + u32 ssc_deltam_int_mask;
> > + u32 ssc_deltam_frac_mask;
> > + u32 ssc_modfreq_mant_mask;
> > + u32 ssc_modfreq_exp_mask;
> > + u32 ssc_enable_mask;
> > + u32 ssc_ack_mask;
>
> ssc_ack_mask is not used for anything in the code.
Ok, I will remove it.
>
> > + u32 ssc_downspread_mask;
> > + u32 ssc_modfreq;
> > + u32 ssc_deltam;
> > + u8 ssc_downspread;
>
> ssc_downspread should be boolean?
Yes.
Thanks and regards,
Dario
>
> > u8 flags;
> > };
> >
> >
[PATCH v5 1/5] clk: ti: fix typo in routine description
Replace _omap3_noncore_dpll_program with omap3_noncore_dpll_program. Signed-off-by: Dario Binacchi Reviewed-by: Stephen Boyd --- (no changes since v4) Changes in v4: - Add Stephen Boyd review tag. drivers/clk/ti/dpll3xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c index 6097b099a5df..94d5b5fe9a2b 100644 --- a/drivers/clk/ti/dpll3xxx.c +++ b/drivers/clk/ti/dpll3xxx.c @@ -292,7 +292,7 @@ static void _lookup_sddiv(struct clk_hw_omap *clk, u8 *sd_div, u16 m, u8 n) } /** - * _omap3_noncore_dpll_program - set non-core DPLL M,N values directly + * omap3_noncore_dpll_program - set non-core DPLL M,N values directly * @clk: struct clk * of DPLL to set * @freqsel: FREQSEL value to set * -- 2.17.1
[PATCH v5 4/5] ARM: dts: am43xx-clocks: add spread spectrum support
Registers for adjusting the spread spectrum clocking (SSC) have been
added. As reported by the TI spruhl7x RM, SSC is supported only for LCD
and MPU PLLs, but the PRCM_CM_SSC_DELTAMSTEP_DPLL_XXX and
PRCM_CM_SSC_MODFREQDIV_DPLL_XXX registers, as well as the enable field
in the PRCM_CM_CLKMODE_DPLL_XXX registers are mapped for all PLLs (CORE,
MPU, DDR, PER, DISP, EXTDEV).
Signed-off-by: Dario Binacchi
---
(no changes since v1)
arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index c726cd8dbdf1..314fc5975acb 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -204,7 +204,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-core-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x2d20>, <0x2d24>, <0x2d2c>;
+ reg = <0x2d20>, <0x2d24>, <0x2d2c>, <0x2d48>, <0x2d4c>;
};
dpll_core_x2_ck: dpll_core_x2_ck {
@@ -250,7 +250,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x2d60>, <0x2d64>, <0x2d6c>;
+ reg = <0x2d60>, <0x2d64>, <0x2d6c>, <0x2d88>, <0x2d8c>;
};
dpll_mpu_m2_ck: dpll_mpu_m2_ck@2d70 {
@@ -276,7 +276,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x2da0>, <0x2da4>, <0x2dac>;
+ reg = <0x2da0>, <0x2da4>, <0x2dac>, <0x2dc8>, <0x2dcc>;
};
dpll_ddr_m2_ck: dpll_ddr_m2_ck@2db0 {
@@ -294,7 +294,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x2e20>, <0x2e24>, <0x2e2c>;
+ reg = <0x2e20>, <0x2e24>, <0x2e2c>, <0x2e48>, <0x2e4c>;
};
dpll_disp_m2_ck: dpll_disp_m2_ck@2e30 {
@@ -313,7 +313,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-j-type-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x2de0>, <0x2de4>, <0x2dec>;
+ reg = <0x2de0>, <0x2de4>, <0x2dec>, <0x2e08>, <0x2e0c>;
};
dpll_per_m2_ck: dpll_per_m2_ck@2df0 {
@@ -557,7 +557,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x2e60>, <0x2e64>, <0x2e6c>;
+ reg = <0x2e60>, <0x2e64>, <0x2e6c>, <0x2e88>, <0x2e8c>;
};
dpll_extdev_m2_ck: dpll_extdev_m2_ck@2e70 {
--
2.17.1
[PATCH v5 0/5] clk: ti: add am33xx spread spectrum clock support
As reported by the TI spruh73x/spruhl7x RM, MPU and LCD modules support spread spectrum clocking (SSC) on their output clocks. SSC is used to spread the spectral peaking of the clock to reduce any electromagnetic interference (EMI) that may be caused due to the clock’s fundamental or any of its harmonics. The series allows you to enable and adjust the spread spectrum clocking for all am33xx/am43xx PLLs for which it is supported. All these issues have been fixed. Previous versions of the series did not supported SSC for am43xx SOCs, causing clock registration failure for DPLLs. Furthermore, for am33xx SOCs, clock registration failed for DPLLs for which SSC is not supported. Changes in v5: - Remove ssc_ack_mask field from dpll_data structure. It was not used. - Change ssc_downspread type from u8 to bool in dpll_data structure. Changes in v4: - Add Stephen Boyd review tag. - Add Rob Herring review tag. - Add SSC registers for CORE, DDR and PER PLLs. - Update commit message. - Update commit message. Changes in v3: - Add '-hz' suffix to "ti,ssc-modfreq" binding. - Add Tony Lindgren acked tag. - Use "ti,ssc-modfreq-hz" binding instead of "ti,ssc-modfreq". Changes in v2: - Remove SSC registers from dpll_core_ck@490 node (SSC is not supported) - Add SSC registers to dpll_mpu_ck@488 node. - Move the DT changes to the previous patch in the series. Dario Binacchi (5): clk: ti: fix typo in routine description dt-bindings: ti: dpll: add spread spectrum support ARM: dts: am33xx-clocks: add spread spectrum support ARM: dts: am43xx-clocks: add spread spectrum support clk: ti: add am33xx/am43xx spread spectrum clock support .../devicetree/bindings/clock/ti/dpll.txt | 20 + arch/arm/boot/dts/am33xx-clocks.dtsi | 10 +-- arch/arm/boot/dts/am43xx-clocks.dtsi | 12 +-- drivers/clk/ti/dpll.c | 39 + drivers/clk/ti/dpll3xxx.c | 87 ++- include/linux/clk/ti.h| 22 + 6 files changed, 178 insertions(+), 12 deletions(-) -- 2.17.1
[PATCH v5 5/5] clk: ti: add am33xx/am43xx spread spectrum clock support
The patch enables spread spectrum clocking (SSC) for MPU and LCD PLLs.
As reported by the TI spruh73x/spruhl7x RM, SSC is only supported for
the DISP/LCD and MPU PLLs on am33xx/am43xx. SSC is not supported for
DDR, PER, and CORE PLLs.
Calculating the required values and setting the registers accordingly
was taken from the set_mpu_spreadspectrum routine contained in the
arch/arm/mach-omap2/am33xx/clock_am33xx.c file of the u-boot project.
In locked condition, DPLL output clock = CLKINP *[M/N]. In case of
SSC enabled, the reference manual explains that there is a restriction
of range of M values. Since the omap2_dpll_round_rate routine attempts
to select the minimum possible N, the value of M obtained is not
guaranteed to be within the range required. With the new "ti,min-div"
parameter it is possible to increase N and consequently M to satisfy the
constraint imposed by SSC.
Signed-off-by: Dario Binacchi
---
Changes in v5:
- Remove ssc_ack_mask field from dpll_data structure. It was not used.
- Change ssc_downspread type from u8 to bool in dpll_data structure.
Changes in v4:
- Update commit message.
Changes in v3:
- Use "ti,ssc-modfreq-hz" binding instead of "ti,ssc-modfreq".
Changes in v2:
- Move the DT changes to the previous patch in the series.
drivers/clk/ti/dpll.c | 39 ++
drivers/clk/ti/dpll3xxx.c | 85 +++
include/linux/clk/ti.h| 22 ++
3 files changed, 146 insertions(+)
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index d6f1ac5b53e1..e9f9aee936ae 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -290,7 +290,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
struct clk_init_data *init = NULL;
const char **parent_names = NULL;
struct dpll_data *dd = NULL;
+ int ssc_clk_index;
u8 dpll_mode = 0;
+ u32 min_div;
dd = kmemdup(ddt, sizeof(*dd), GFP_KERNEL);
clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
@@ -345,6 +347,27 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dd->autoidle_mask) {
if (ti_clk_get_reg_addr(node, 3, &dd->autoidle_reg))
goto cleanup;
+
+ ssc_clk_index = 4;
+ } else {
+ ssc_clk_index = 3;
+ }
+
+ if (dd->ssc_deltam_int_mask && dd->ssc_deltam_frac_mask &&
+ dd->ssc_modfreq_mant_mask && dd->ssc_modfreq_exp_mask) {
+ if (ti_clk_get_reg_addr(node, ssc_clk_index++,
+ &dd->ssc_deltam_reg))
+ goto cleanup;
+
+ if (ti_clk_get_reg_addr(node, ssc_clk_index++,
+ &dd->ssc_modfreq_reg))
+ goto cleanup;
+
+ of_property_read_u32(node, "ti,ssc-modfreq-hz",
+&dd->ssc_modfreq);
+ of_property_read_u32(node, "ti,ssc-deltam", &dd->ssc_deltam);
+ dd->ssc_downspread =
+ of_property_read_bool(node, "ti,ssc-downspread");
}
if (of_property_read_bool(node, "ti,low-power-stop"))
@@ -356,6 +379,10 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (of_property_read_bool(node, "ti,lock"))
dpll_mode |= 1 << DPLL_LOCKED;
+ if (!of_property_read_u32(node, "ti,min-div", &min_div) &&
+ min_div > dd->min_divider)
+ dd->min_divider = min_div;
+
if (dpll_mode)
dd->modes = dpll_mode;
@@ -585,8 +612,14 @@ static void __init of_ti_am3_no_gate_dpll_setup(struct
device_node *node)
const struct dpll_data dd = {
.idlest_mask = 0x1,
.enable_mask = 0x7,
+ .ssc_enable_mask = 0x1 << 12,
+ .ssc_downspread_mask = 0x1 << 14,
.mult_mask = 0x7ff << 8,
.div1_mask = 0x7f,
+ .ssc_deltam_int_mask = 0x3 << 18,
+ .ssc_deltam_frac_mask = 0x3,
+ .ssc_modfreq_mant_mask = 0x7f,
+ .ssc_modfreq_exp_mask = 0x7 << 8,
.max_multiplier = 2047,
.max_divider = 128,
.min_divider = 1,
@@ -645,8 +678,14 @@ static void __init of_ti_am3_dpll_setup(struct device_node
*node)
const struct dpll_data dd = {
.idlest_mask = 0x1,
.enable_mask = 0x7,
+ .ssc_enable_mask = 0x1 << 12,
+ .ssc_downspread_mask = 0x1 << 14,
.mult_mask = 0x7ff << 8,
.div1_mask = 0x7f,
+ .ssc_deltam_int_mask = 0x3 << 18,
+ .ssc_deltam_frac_mask = 0x3,
+ .ssc_modfreq_mant_mask = 0x7f,
+ .ssc_modfreq_exp_mask = 0x7 << 8,
.max_multiplier = 2047,
.max_divider = 128,
.min_divider = 1,
diff --git a/drivers/clk/ti/dpll3xxx.c b/
[PATCH v5 2/5] dt-bindings: ti: dpll: add spread spectrum support
DT bindings for enabling and adjusting spread spectrum clocking have
been added.
Signed-off-by: Dario Binacchi
Reviewed-by: Rob Herring
---
(no changes since v4)
Changes in v4:
- Add Rob Herring review tag.
Changes in v3:
- Add '-hz' suffix to "ti,ssc-modfreq" binding.
.../devicetree/bindings/clock/ti/dpll.txt | 20 +++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index df57009ff8e7..37a7cb6ad07d 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -42,6 +42,11 @@ Required properties:
"idlest" - contains the idle status register base address
"mult-div1" - contains the multiplier / divider register base address
"autoidle" - contains the autoidle register base address (optional)
+ "ssc-deltam" - DPLL supports spread spectrum clocking (SSC), contains
+ the frequency spreading register base address (optional)
+ "ssc-modfreq" - DPLL supports spread spectrum clocking (SSC), contains
+ the modulation frequency register base address
+ (optional)
ti,am3-* dpll types do not have autoidle register
ti,omap2-* dpll type does not support idlest / autoidle registers
@@ -51,6 +56,14 @@ Optional properties:
- ti,low-power-stop : DPLL supports low power stop mode, gating output
- ti,low-power-bypass : DPLL output matches rate of parent bypass clock
- ti,lock : DPLL locks in programmed rate
+ - ti,min-div : the minimum divisor to start from to round the DPLL
+ target rate
+ - ti,ssc-deltam : DPLL supports spread spectrum clocking, frequency
+ spreading in permille (10th of a percent)
+ - ti,ssc-modfreq-hz : DPLL supports spread spectrum clocking, spread
+ spectrum modulation frequency
+ - ti,ssc-downspread : DPLL supports spread spectrum clocking, boolean
+ to enable the downspread feature
Examples:
dpll_core_ck: dpll_core_ck@44e00490 {
@@ -83,3 +96,10 @@ Examples:
clocks = <&sys_ck>, <&sys_ck>;
reg = <0x0500>, <0x0540>;
};
+
+ dpll_disp_ck: dpll_disp_ck {
+ #clock-cells = <0>;
+ compatible = "ti,am3-dpll-no-gate-clock";
+ clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
+ reg = <0x0498>, <0x0448>, <0x0454>, <0x044c>, <0x0450>;
+ };
--
2.17.1
[PATCH v5 3/5] ARM: dts: am33xx-clocks: add spread spectrum support
Registers for adjusting the spread spectrum clocking (SSC) have been
added. As reported by the TI spruh73x RM, SSC is supported only for LCD
and MPU PLLs, but the CM_SSC_DELTAMSTEP_DPLL_XXX and
CM_SSC_MODFREQDIV_DPLL_XXX registers, as well as the enable field in the
CM_CLKMODE_DPLL_XXX registers are mapped for all PLLs (CORE, MPU, DDR,
PER, DISP).
Signed-off-by: Dario Binacchi
Acked-by: Tony Lindgren
---
(no changes since v4)
Changes in v4:
- Add SSC registers for CORE, DDR and PER PLLs.
- Update commit message.
Changes in v3:
- Add Tony Lindgren acked tag.
Changes in v2:
- Remove SSC registers from dpll_core_ck@490 node (SSC is not supported)
- Add SSC registers to dpll_mpu_ck@488 node.
arch/arm/boot/dts/am33xx-clocks.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index dced92a8970e..b7b7106f2dee 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -164,7 +164,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-core-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x0490>, <0x045c>, <0x0468>;
+ reg = <0x0490>, <0x045c>, <0x0468>, <0x0460>, <0x0464>;
};
dpll_core_x2_ck: dpll_core_x2_ck {
@@ -204,7 +204,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x0488>, <0x0420>, <0x042c>;
+ reg = <0x0488>, <0x0420>, <0x042c>, <0x0424>, <0x0428>;
};
dpll_mpu_m2_ck: dpll_mpu_m2_ck@4a8 {
@@ -220,7 +220,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-no-gate-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x0494>, <0x0434>, <0x0440>;
+ reg = <0x0494>, <0x0434>, <0x0440>, <0x0438>, <0x043c>;
};
dpll_ddr_m2_ck: dpll_ddr_m2_ck@4a0 {
@@ -244,7 +244,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-no-gate-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x0498>, <0x0448>, <0x0454>;
+ reg = <0x0498>, <0x0448>, <0x0454>, <0x044c>, <0x0450>;
};
dpll_disp_m2_ck: dpll_disp_m2_ck@4a4 {
@@ -261,7 +261,7 @@
#clock-cells = <0>;
compatible = "ti,am3-dpll-no-gate-j-type-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
- reg = <0x048c>, <0x0470>, <0x049c>;
+ reg = <0x048c>, <0x0470>, <0x049c>, <0x0474>, <0x0478>;
};
dpll_per_m2_ck: dpll_per_m2_ck@4ac {
--
2.17.1
Re: [PATCH v4 3/7] media: i2c: max9286: Use "maxim,gpio-poc" property
Hi Laurent,
On Thu, Apr 15, 2021 at 10:19:30PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thu, Apr 15, 2021 at 02:25:58PM +0200, Jacopo Mondi wrote:
> > The 'maxim,gpio-poc' property is used when the remote camera
> > power-over-coax is controlled by one of the MAX9286 gpio lines,
> > to instruct the driver about which line to use and what the line
> > polarity is.
> >
> > Add to the max9286 driver support for parsing the newly introduced
> > property and use it if available in place of the usual supply, as it is
> > not possible to establish one as consumer of the max9286 gpio
> > controller.
> >
> > If the new property is present, no gpio controller is registered and
> > 'poc-supply' is ignored.
> >
> > In order to maximize code re-use, break out the max9286 gpio handling
> > function so that they can be used by the gpio controller through the
> > gpio-consumer API, or directly by the driver code.
> >
> > Wrap the power up and power down routines to their own function to
> > be able to use either the gpio line directly or the supply. This will
> > make it easier to control the remote camera power at run time.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/media/i2c/max9286.c | 119
> > 1 file changed, 93 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
> > index 6fd4d59fcc72..a8b37783d2ef 100644
> > --- a/drivers/media/i2c/max9286.c
> > +++ b/drivers/media/i2c/max9286.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -165,6 +166,9 @@ struct max9286_priv {
> >
> > u32 reverse_channel_mv;
> >
> > + u32 gpio_poc;
> > + u32 gpio_poc_flags;
> > +
> > struct v4l2_ctrl_handler ctrls;
> > struct v4l2_ctrl *pixelrate;
> >
> > @@ -1022,8 +1026,19 @@ static int max9286_setup(struct max9286_priv *priv)
> > return 0;
> > }
> >
> > -static void max9286_gpio_set(struct gpio_chip *chip,
> > -unsigned int offset, int value)
> > +static int max9286_gpio_set(struct max9286_priv *priv, unsigned int offset,
> > + int value)
> > +{
> > + int ret = max9286_read(priv, 0x0f);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = value ? (ret & 0x3) | BIT(offset) : (ret & 0x3) & ~BIT(offset);
> > + return max9286_write(priv, 0x0f, MAX9286_0X0F_RESERVED | ret);
> > +}
>
> Was there anything wrong with v3, sharing the implementation between the
Yes, my understanding that your comment about not mixing the two
cases as they're mutually exclusive :)
I found that it actually made sense, as my reasoning was to support
both at the same time, but it was actually not possible. I then
thought it was a good idea to keep them separate
> gpio-controller and non gpio-controller cases ? In particular, caching
> the state locally seems better, max9286_read() goes over I2C and is thus
> slow.
At the expense of an additional i2c read... The gpio is only toggled
at power-up/down, so I considered this acceptable...
Both solutions are ok with me, I can restore the usage of gpio->state
or keep what I have here...
The only argument in favour of using gpio->state is that it paves the
way for the usage of 'gpio-poc' and for registering a gpio-controller
on the other gpio line at the same time, in future.. I think I'll
switch back to that solution then...
Thanks
j
>
> > +
> > +static void max9286_gpiochip_set(struct gpio_chip *chip,
> > +unsigned int offset, int value)
> > {
> > struct max9286_priv *priv = gpiochip_get_data(chip);
> >
> > @@ -1035,7 +1050,7 @@ static void max9286_gpio_set(struct gpio_chip *chip,
> > max9286_write(priv, 0x0f, MAX9286_0X0F_RESERVED | priv->gpio_state);
> > }
> >
> > -static int max9286_gpio_get(struct gpio_chip *chip, unsigned int offset)
> > +static int max9286_gpiochip_get(struct gpio_chip *chip, unsigned int
> > offset)
> > {
> > struct max9286_priv *priv = gpiochip_get_data(chip);
> >
> > @@ -1055,8 +1070,8 @@ static int max9286_register_gpio(struct max9286_priv
> > *priv)
> > gpio->of_node = dev->of_node;
> > gpio->ngpio = 2;
> > gpio->base = -1;
> > - gpio->set = max9286_gpio_set;
> > - gpio->get = max9286_gpio_get;
> > + gpio->set = max9286_gpiochip_set;
> > + gpio->get = max9286_gpiochip_get;
> > gpio->can_sleep = true;
> >
> > /* GPIO values default to high */
> > @@ -1069,6 +1084,71 @@ static int max9286_register_gpio(struct max9286_priv
> > *priv)
> > return ret;
> > }
> >
> > +static int max9286_parse_gpios(struct max9286_priv *priv)
> > +{
> > + struct device *dev = &priv->client->dev;
> > + u32 gpio_poc[2];
> > + int ret;
> > +
> > + /*
> > +* Parse the "gpio-poc" vendor property. If the camera power is
> > +* controlled by one of the MAX9286 gpio lines, do not register
> > +* the gpio c
[rcu:dev.2021.04.13a] BUILD SUCCESS 431ded55d9d86084c398c33d900356a7d1587f78
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2021.04.13a branch HEAD: 431ded55d9d86084c398c33d900356a7d1587f78 rcu: Point to documentation of ordering guarantees elapsed time: 723m configs tested: 105 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig mips bigsur_defconfig powerpcklondike_defconfig ia64generic_defconfig archsdk_defconfig sparc64 defconfig powerpc pmac32_defconfig powerpc obs600_defconfig mips xway_defconfig mipsqi_lb60_defconfig arm netwinder_defconfig m68kmvme147_defconfig mips ci20_defconfig sh se7750_defconfig sh microdev_defconfig powerpc mpc832x_mds_defconfig xtensa audio_kc705_defconfig powerpc mpc85xx_cds_defconfig arm pxa3xx_defconfig nios2alldefconfig sh sh7785lcr_32bit_defconfig armtrizeps4_defconfig powerpc iss476-smp_defconfig powerpc ep88xc_defconfig sh rsk7264_defconfig sh sdk7786_defconfig mips rb532_defconfig sh se7619_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210418 i386 randconfig-a001-20210418 i386 randconfig-a006-20210418 i386 randconfig-a005-20210418 i386 randconfig-a004-20210418 i386 randconfig-a002-20210418 x86_64 randconfig-a014-20210418 x86_64 randconfig-a015-20210418 x86_64 randconfig-a013-20210418 x86_64 randconfig-a011-20210418 x86_64 randconfig-a012-20210418 x86_64 randconfig-a016-20210418 i386 randconfig-a015-20210418 i386 randconfig-a013-20210418 i386 randconfig-a014-20210418 i386 randconfig-a016-20210418 i386 randconfig-a012-20210418 i386 randconfig-a011-20210418 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig
Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote: > Optimization could be done on dsa_skb_tx_timestamp(), and dsa device > drivers should adapt to it. > > - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in > port_txtstamp, so that most skbs not requiring tx timestamp just return. > > - No longer to identify PTP packets, and limit tx timestamping only for PTP > packets. If device driver likes, let device driver do. > > - It is a waste to clone skb directly in dsa_skb_tx_timestamp(). > For one-step timestamping, a clone is not needed. For any failure of > port_txtstamp (this may usually happen), the skb clone has to be freed. > So put skb cloning into port_txtstamp where it really needs. This patch changes three things ^^^ at once. These are AFAICT independent changes, and so please break this one patch into three for easier review. Thanks, Richard
Re: [PATCH] media: atomisp: pci: remove unneeded variable 'err'
On Sun, Apr 18, 2021 at 08:13:23PM +0530, Saurav Girepunje wrote:
> Fix the following coccicheck warning:
>
> drivers/staging/media/atomisp/pci/sh_css_mipi.c:39:5-8:
> Unneeded variable: "err". Return "0" on line 44
>
> Signed-off-by: Saurav Girepunje
> ---
> drivers/staging/media/atomisp/pci/sh_css_mipi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
> b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
> index d5ae7f0b5864..708903a31b08 100644
> --- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
> +++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
> @@ -36,12 +36,11 @@ ref_count_mipi_allocation[N_CSI_PORTS]; /* Initialized in
> mipi_init */
> int
> ia_css_mipi_frame_specify(const unsigned int size_mem_words,
> const bool contiguous) {
> - int err = 0;
>
> my_css.size_mem_words = size_mem_words;
> (void)contiguous;
>
> - return err;
> + return 0;
> }
>
> /*
> --
> 2.25.1
>
>
Hi Saurav,
this ia_css_mipi_frame_specify seems to be unused. On
header file, before the prototype it is said that it could
be removed only when all drivers moved to a new API.
Is that comment obsolete?
thank you,
fabio
Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> @@ -628,9 +620,7 @@ static netdev_tx_t dsa_slave_xmit(struct sk_buff *skb,
> struct net_device *dev)
>
> DSA_SKB_CB(skb)->clone = NULL;
>
> - /* Identify PTP protocol packets, clone them, and pass them to the
> - * switch driver
> - */
> + /* Handle tx timestamp request if has */
"if has" what?
> dsa_skb_tx_timestamp(p, skb);
>
> if (dsa_realloc_skb(skb, dev)) {
> --
> 2.25.1
>
Thanks,
Richard
Re: [syzbot] unexpected kernel reboot (4)
On 2021/04/17 12:19, Tetsuo Handa wrote:
> On 2021/04/15 0:39, Andrey Konovalov wrote:
>> On Wed, Apr 14, 2021 at 7:45 AM Dmitry Vyukov wrote:
>>> The reproducer connects some USB HID device and communicates with the
>>> driver.
>>> Previously we observed reboots because HID devices can trigger reboot
>>> SYSRQ, but we disable it with "CONFIG_MAGIC_SYSRQ is not set".
>>> How else can a USB device reboot the machine? Is it possible to disable it?
>>> I don't see any direct includes of in drivers/usb/*
>>
>> This happens when a keyboard sends the Ctrl+Alt+Del sequence, see
>> fn_boot_it()->ctrl_alt_del() in drivers/tty/vt/keyboard.c.
>>
>
> Regarding ctrl_alt_del() problem, doing
>
> sh -c 'echo 0 > /proc/sys/kernel/ctrl-alt-del; echo $$ >
> /proc/sys/kernel/cad_pid'
>
> as root before start fuzzing might help.
>
> Also, with the command above, reproducer still triggers suspend operation
> which freezes userspace processes.
> This could possibly be one of causes for no output / lost connections. Try
> disabling freeze/suspend related configs?
>
I tried
# CONFIG_HIBERNATION is not set
# CONFIG_SUSPEND is not set
# CONFIG_PM is not set
but the reproducer still shutdowns the system.
The reproducer can be simplified to single threaded.
int main(int argc, char *argv[])
{
uint64_t r[1] = { 0x };
syscall(__NR_mmap, 0x2000ul, 0x100ul, 7ul, 0x32ul, -1, 0ul);
memcpy((void*)0x2200,
"\x12\x01\x00\x00\x00\x00\x00\x40\x26\x09\x33\x33\x40\x00\x00\x00\x00"
"\x01\x09\x02\x24\x00\x01\x00\x00\x00\x00\x09\x04\x00\x00\x01\x03\x01"
"\x00\x00\x09\x21\x00\x00\x00\x01\x22\x01\x00\x09\x05\x81\x03\x08",
50);
r[0] = syz_usb_connect(0, 0x36, 0x2200, 0);
syz_usb_control_io(r[0], 0, 0);
*(uint32_t*)0x2300 = 0x24;
*(uint64_t*)0x2304 = 0;
*(uint64_t*)0x230c = 0;
*(uint64_t*)0x2314 = 0x21c0;
*(uint8_t*)0x21c0 = 0;
*(uint8_t*)0x21c1 = 0x22;
*(uint32_t*)0x21c2 = 5;
STORE_BY_BITMASK(uint8_t, , 0x21c6, 3, 0, 2);
STORE_BY_BITMASK(uint8_t, , 0x21c6, 0, 2, 2);
STORE_BY_BITMASK(uint8_t, , 0x21c6, 0, 4, 4);
memcpy((void*)0x21c7, "\x65\xe9\x5e\x9d", 4);
*(uint64_t*)0x231c = 0;
syz_usb_control_io(r[0], 0x2300, 0);
syz_usb_ep_write(r[0], 0, 5, (long) "\x8e\xc5\x44\xbc\x66");
return 0;
}
Since applying below diff does not help, I don't think that
this problem can be avoided by modifying tty code.
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 77638629c562..25e6d52f5de6 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -323,12 +323,14 @@ int kbd_rate(struct kbd_repeat *rpt)
*/
static void put_queue(struct vc_data *vc, int ch)
{
+ return;
tty_insert_flip_char(&vc->port, ch, 0);
tty_schedule_flip(&vc->port);
}
static void puts_queue(struct vc_data *vc, const char *cp)
{
+ return;
tty_insert_flip_string(&vc->port, cp, strlen(cp));
tty_schedule_flip(&vc->port);
}
@@ -657,7 +659,7 @@ static void k_spec(struct vc_data *vc, unsigned char value,
char up_flag)
kbd->kbdmode == VC_OFF) &&
value != KVAL(K_SAK))
return; /* SAK is allowed even in raw mode */
- fn_handler[value](vc);
+ //fn_handler[value](vc);
}
static void k_lowercase(struct vc_data *vc, unsigned char value, char up_flag)
@@ -1393,6 +1395,7 @@ static void kbd_keycode(unsigned int keycode, int down,
bool hw_raw)
struct keyboard_notifier_param param = { .vc = vc, .value = keycode,
.down = down };
int rc;
+ return;
tty = vc->port.tty;
if (tty && (!tty->driver_data)) {
@@ -1509,7 +1512,7 @@ static void kbd_keycode(unsigned int keycode, int down,
bool hw_raw)
if ((raw_mode || kbd->kbdmode == VC_OFF) && type != KT_SPEC && type !=
KT_SHIFT)
return;
- (*k_handler[type])(vc, keysym & 0xff, !down);
+ //(*k_handler[type])(vc, keysym & 0xff, !down);
param.ledstate = kbd->ledflagstate;
atomic_notifier_call_chain(&keyboard_notifier_list, KBD_POST_KEYSYM,
¶m);
Running the reproducer with
dbus-monitor --system > /dev/ttyprintk
reports that systemd's shutdown service is requested when syz_usb_ep_write() is
called.
I can't understand why the command "\x8e\xc5\x44\xbc\x66" leads to this result.
[ 62.382763][ T47] usb 5-1: new high-speed USB device number 2 using
dummy_hcd
[ 62.745091][ T47] usb 5-1: config 0 interface 0 altsetting 0 endpoint 0x81
has an invalid bInterval 0, changing to 7
[ 62.749179][
