Re: [PATCH] ALSA: hda: Enable runtime PM when codec probe fails
On Mon, 14 Dec 2020 07:06:20 +0100,
Kai-Heng Feng wrote:
>
> When codec probe fails, it doesn't enable runtime suspend, and can
> prevent graphics card from getting powered down:
> [4.280991] snd_hda_intel :01:00.1: no codecs initialized
>
> $ cat /sys/bus/pci/devices/:01:00.1/power/runtime_status
> active
>
> So enable runtime PM when codec probe fails, to let graphics card be
> able to runtime suspend again.
Well, the runtime status is also active if the driver isn't probed at
all. In that sense, keeping the status active at the driver load
failure is rather consistent, IMO. If the driver fails or unloaded,
it should restore the status as if it were beforehand.
thanks,
Takashi
>
> Merge azx_probe_continue() into azx_probe() and just let probe fail for
> this case could be a better approach. However that's a much bigger task
> so let's settle with a quirk workaround.
>
> BugLink: https://bugs.launchpad.net/bugs/1907212
> Signed-off-by: Kai-Heng Feng
> ---
> sound/pci/hda/hda_intel.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 6852668f1bcb..3fd920069268 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -2328,7 +2328,7 @@ static int azx_probe_continue(struct azx *chip)
> if (bus->codec_mask) {
> err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]);
> if (err < 0)
> - goto out_free;
> + goto out_enable_rpm;
> }
>
> #ifdef CONFIG_SND_HDA_PATCH_LOADER
> @@ -2360,6 +2360,7 @@ static int azx_probe_continue(struct azx *chip)
>
> set_default_power_save(chip);
>
> +out_enable_rpm:
> if (azx_has_pm_runtime(chip)) {
> pm_runtime_use_autosuspend(&pci->dev);
> pm_runtime_allow(&pci->dev);
> --
> 2.29.2
>
[PATCH] scripts: add more corrections to spelling.txt
Analyzing misspellings over the past 10k commit messages, a few more corrections are added to spelling.txt Signed-off-by: Dwaipayan Ray --- scripts/spelling.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 953f4a2de1e5..cf2453ddb216 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -315,6 +315,7 @@ commited||committed commiting||committing committ||commit commoditiy||commodity +comon||common comsume||consume comsumer||consumer comsuming||consuming @@ -347,6 +348,7 @@ condtion||condition conected||connected conector||connector configration||configuration +configred||configured configuartion||configuration configuation||configuration configued||configured @@ -437,6 +439,7 @@ dependant||dependent dependend||dependent depreacted||deprecated depreacte||deprecate +derefencing||dereferencing desactivate||deactivate desciptor||descriptor desciptors||descriptors @@ -608,6 +611,7 @@ failue||failure failuer||failure failng||failing faireness||fairness +falg||flag falied||failed faliure||failure fallbck||fallback @@ -722,6 +726,7 @@ implemntation||implementation implentation||implementation implmentation||implementation implmenting||implementing +improvments||improvements incative||inactive incomming||incoming incompatabilities||incompatibilities @@ -801,6 +806,7 @@ intialise||initialise intialization||initialization intialized||initialized intialize||initialize +intead||instead intregral||integral intrerrupt||interrupt intrrupt||interrupt @@ -1151,6 +1157,7 @@ recyle||recycle redircet||redirect redirectrion||redirection redundacy||redundancy +reenable||re-enable reename||rename refcounf||refcount refence||reference @@ -1253,6 +1260,7 @@ senarios||scenarios sentivite||sensitive separatly||separately sepcify||specify +seperate||separate seperated||separated seperately||separately seperate||separate @@ -1334,6 +1342,7 @@ substract||subtract submited||submitted submition||submission suceed||succeed +suceeded||succeeded succesfully||successfully succesful||successful successed||succeeded @@ -1354,6 +1363,7 @@ suppoted||supported suppported||supported suppport||support supress||suppress +suprising||surprising surpressed||suppressed surpresses||suppresses susbsystem||subsystem @@ -1475,6 +1485,7 @@ unsinged||unsigned unstabel||unstable unsolicitied||unsolicited unsuccessfull||unsuccessful +unsued||unused unsuported||unsupported untill||until ununsed||unused @@ -1482,6 +1493,8 @@ unuseful||useless unvalid||invalid upate||update upsupported||unsupported +upto|| up to +uptodate||up-to-date usefule||useful usefull||useful usege||usage @@ -1499,10 +1512,12 @@ vaild||valid valide||valid variantions||variations varible||variable +varibles||variables varient||variant vaule||value verbse||verbose veify||verify +vender||vendor verisons||versions verison||version verson||version @@ -1528,8 +1543,11 @@ wiil||will wirte||write withing||within wnat||want +wont||won't workarould||workaround +wraper||wrapper writeing||writing +writen||written writting||writing wtih||with zombe||zombie -- 2.27.0
[PATCH v2] scripts: add more corrections to spelling.txt
Analyzing misspellings over the past 10k commit messages, a few more corrections are added to spelling.txt Signed-off-by: Dwaipayan Ray --- Changes in v2: - Fix additional whitespace before "up to" scripts/spelling.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 953f4a2de1e5..cf2453ddb216 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -315,6 +315,7 @@ commited||committed commiting||committing committ||commit commoditiy||commodity +comon||common comsume||consume comsumer||consumer comsuming||consuming @@ -347,6 +348,7 @@ condtion||condition conected||connected conector||connector configration||configuration +configred||configured configuartion||configuration configuation||configuration configued||configured @@ -437,6 +439,7 @@ dependant||dependent dependend||dependent depreacted||deprecated depreacte||deprecate +derefencing||dereferencing desactivate||deactivate desciptor||descriptor desciptors||descriptors @@ -608,6 +611,7 @@ failue||failure failuer||failure failng||failing faireness||fairness +falg||flag falied||failed faliure||failure fallbck||fallback @@ -722,6 +726,7 @@ implemntation||implementation implentation||implementation implmentation||implementation implmenting||implementing +improvments||improvements incative||inactive incomming||incoming incompatabilities||incompatibilities @@ -801,6 +806,7 @@ intialise||initialise intialization||initialization intialized||initialized intialize||initialize +intead||instead intregral||integral intrerrupt||interrupt intrrupt||interrupt @@ -1151,6 +1157,7 @@ recyle||recycle redircet||redirect redirectrion||redirection redundacy||redundancy +reenable||re-enable reename||rename refcounf||refcount refence||reference @@ -1253,6 +1260,7 @@ senarios||scenarios sentivite||sensitive separatly||separately sepcify||specify +seperate||separate seperated||separated seperately||separately seperate||separate @@ -1334,6 +1342,7 @@ substract||subtract submited||submitted submition||submission suceed||succeed +suceeded||succeeded succesfully||successfully succesful||successful successed||succeeded @@ -1354,6 +1363,7 @@ suppoted||supported suppported||supported suppport||support supress||suppress +suprising||surprising surpressed||suppressed surpresses||suppresses susbsystem||subsystem @@ -1475,6 +1485,7 @@ unsinged||unsigned unstabel||unstable unsolicitied||unsolicited unsuccessfull||unsuccessful +unsued||unused unsuported||unsupported untill||until ununsed||unused @@ -1482,6 +1493,8 @@ unuseful||useless unvalid||invalid upate||update upsupported||unsupported +upto||up to +uptodate||up-to-date usefule||useful usefull||useful usege||usage @@ -1499,10 +1512,12 @@ vaild||valid valide||valid variantions||variations varible||variable +varibles||variables varient||variant vaule||value verbse||verbose veify||verify +vender||vendor verisons||versions verison||version verson||version @@ -1528,8 +1543,11 @@ wiil||will wirte||write withing||within wnat||want +wont||won't workarould||workaround +wraper||wrapper writeing||writing +writen||written writting||writing wtih||with zombe||zombie -- 2.27.0
Re: [PATCH v4] Serial: silabs si4455 serial driver
On 12. 12. 20, 8:09, József Horváth wrote:
This is a serial port driver for
Silicon Labs Si4455 Sub-GHz transciver.
The goal of this driver is to removing wires
between central(linux) device and remote serial devices/sensors,
but keeping the original user software.
It represents regular serial interface for the user space.
Datasheet: https://www.silabs.com/documents/public/data-sheets/Si4455.pdf
A description of changes between v1..v4 here, please.
Signed-off-by: József Horváth
...
--- /dev/null
+++ b/drivers/tty/serial/si4455.c
@@ -0,0 +1,1328 @@
...
+struct si4455_one {
What is this si4455_one good for? I mean, why not just inline these two
in si4455_port?
+ struct uart_port port;
+ struct work_struct tx_work;
+};
+
+struct si4455_port {
+ struct mutex mutex; /* For syncing access to device */
+ int power_count;
+ bool connected;
If you put this int and bool after u32s below, the structure won't
contain holes AFAICS.
+ struct gpio_desc *shdn_gpio;
+ struct si4455_part_info part_info;
+ struct si4455_modem_status modem_status;
+ u32 tx_channel;
+ u32 rx_channel;
+ u32 package_size;
+ bool configured;
+ bool tx_pending;
+ bool rx_pending;
+ u32 current_rssi;
+ struct si4455_one one;
+};
...
+static int si4455_get_response(struct uart_port *port, int length, u8 *data)
+{
+ int ret;
+ u8 data_out[] = { SI4455_CMD_ID_READ_CMD_BUFF };
+ u8 *data_in = NULL;
A useless initialization.
+ struct spi_transfer xfer[2];
+ int timeout = 1;
+
+ if (length > 0 && !data)
+ return -EINVAL;
+
+ data_in = kzalloc(1 + length, GFP_KERNEL);
+ if (!data_in)
+ return -ENOMEM;
+
+ memset(&xfer, 0x00, sizeof(xfer));
+ xfer[0].tx_buf = data_out;
+ xfer[0].len = sizeof(data_out);
+ xfer[1].rx_buf = data_in;
+ xfer[1].len = 1 + length;
+
+ while (--timeout > 0) {
+ data_out[0] = SI4455_CMD_ID_READ_CMD_BUFF;
+ ret = spi_sync_transfer(to_spi_device(port->dev), xfer,
+ ARRAY_SIZE(xfer));
+ if (ret) {
+ dev_err(port->dev, "%s: spi_sync_transfer error(%i)",
__func__, ret);
Missing \n. And a space before (.
+ break;
+ }
+
+ if (data_in[0] == 0xFF) {
+ if (length > 0 && data)
+ memcpy(data, &data_in[1], length);
+
+ break;
+ }
+ usleep_range(100, 200);
+ }
+ if (timeout == 0) {
+ dev_err(port->dev, "%s:timeout==%i", __func__, timeout);
+ ret = -EIO;
+ }
+ kfree(data_in);
+ return ret;
+}
...
+static int si4455_send_command(struct uart_port *port, int length, u8 *data)
+{
+ int ret;
+
+ ret = si4455_poll_cts(port);
+ if (ret) {
+ dev_err(port->dev,
+ "%s: si4455_poll_cts error(%i)", __func__, ret);
+ return ret;
+ }
Put a newline here.
+ ret = spi_write(to_spi_device(port->dev), data, length);
+ if (ret) {
+ dev_err(port->dev,
+ "%s: spi_write error(%i)", __func__, ret);
+ }
And here.
+ return ret;
+}
+
+static int si4455_send_command_get_response(struct uart_port *port,
+ int out_length, u8 *data_out,
+ int in_length, u8 *data_in)
+{
+ int ret;
+
+ ret = si4455_send_command(port, out_length, data_out);
+ if (ret) {
+ dev_err(port->dev,
+ "%s: si4455_send_command error(%i)", __func__, ret);
+ return ret;
+ }
+
+ ret = si4455_get_response(port, in_length, data_in);
+
+ return ret;
Simplify by return si4455_get_response() directly.
+}
+
+static int si4455_read_data(struct uart_port *port, u8 command, int poll,
+ int length, u8 *data)
+{
+ int ret = 0;
+ u8 data_out[] = { command };
+ struct spi_transfer xfer[] = {
+ {
+ .tx_buf = data_out,
+ .len = sizeof(data_out),
+ }, {
+ .rx_buf = data,
+ .len = length,
+ }
+ };
+
+ if (poll) {
+ ret = si4455_poll_cts(port);
+ if (ret)
+ return ret;
+ }
+
+ ret = spi_sync_transfer(to_spi_device(port->dev),
+ xfer,
+ ARRAY_SIZE(xfer));
+ if (ret) {
+ dev_err(port->dev,
+ "%s: spi_sync_transfer error(%i)", __func__, ret);
\n here. And in all the other dev_errs all around.
+ }
A newline
linux-next: manual merge of the rtc tree with the tip tree
Hi all,
Today's linux-next merge of the rtc tree got a conflict in:
include/linux/rtc.h
between commit:
33e62e832384 ("ntp, rtc: Move rtc_set_ntp_time() to ntp code")
from the tip tree and commit:
fdcfd854333b ("rtc: rework rtc_register_device() resource management")
from the rtc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/rtc.h
index b829382de6c3,55e7beed066c..
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@@ -110,43 -110,14 +110,37 @@@ struct rtc_device
/* Some hardware can't support UIE mode */
int uie_unsupported;
- /* Number of nsec it takes to set the RTC clock. This influences when
- * the set ops are called. An offset:
- * - of 0.5 s will call RTC set for wall clock time 10.0 s at 9.5 s
- * - of 1.5 s will call RTC set for wall clock time 10.0 s at 8.5 s
- * - of -0.5 s will call RTC set for wall clock time 10.0 s at 10.5 s
+ /*
+ * This offset specifies the update timing of the RTC.
+ *
+ * tsched t1 write(t2.tv_sec - 1sec)) t2 RTC increments seconds
+ *
+ * The offset defines how tsched is computed so that the write to
+ * the RTC (t2.tv_sec - 1sec) is correct versus the time required
+ * for the transport of the write and the time which the RTC needs
+ * to increment seconds the first time after the write (t2).
+ *
+ * For direct accessible RTCs tsched ~= t1 because the write time
+ * is negligible. For RTCs behind slow busses the transport time is
+ * significant and has to be taken into account.
+ *
+ * The time between the write (t1) and the first increment after
+ * the write (t2) is RTC specific. For a MC146818 RTC it's 500ms,
+ * for many others it's exactly 1 second. Consult the datasheet.
+ *
+ * The value of this offset is also used to calculate the to be
+ * written value (t2.tv_sec - 1sec) at tsched.
+ *
+ * The default value for this is NSEC_PER_SEC + 10 msec default
+ * transport time. The offset can be adjusted by drivers so the
+ * calculation for the to be written value at tsched becomes
+ * correct:
+ *
+ * newval = tsched + set_offset_nsec - NSEC_PER_SEC
+ * and (tsched + set_offset_nsec) % NSEC_PER_SEC == 0
*/
- long set_offset_nsec;
+ unsigned long set_offset_nsec;
- bool registered;
-
- /* Old ABI support */
- bool nvram_old_abi;
- struct bin_attribute *nvram;
-
time64_t range_min;
timeu64_t range_max;
time64_t start_secs;
@@@ -227,8 -199,41 +221,8 @@@ static inline bool is_leap_year(unsigne
return (!(year % 4) && (year % 100)) || !(year % 400);
}
- #define rtc_register_device(device) \
- __rtc_register_device(THIS_MODULE, device)
-/* Determine if we can call to driver to set the time. Drivers can only be
- * called to set a second aligned time value, and the field set_offset_nsec
- * specifies how far away from the second aligned time to call the driver.
- *
- * This also computes 'to_set' which is the time we are trying to set, and has
- * a zero in tv_nsecs, such that:
- *to_set - set_delay_nsec == now +/- FUZZ
- *
- */
-static inline bool rtc_tv_nsec_ok(s64 set_offset_nsec,
-struct timespec64 *to_set,
-const struct timespec64 *now)
-{
- /* Allowed error in tv_nsec, arbitarily set to 5 jiffies in ns. */
- const unsigned long TIME_SET_NSEC_FUZZ = TICK_NSEC * 5;
- struct timespec64 delay = {.tv_sec = 0,
- .tv_nsec = set_offset_nsec};
-
- *to_set = timespec64_add(*now, delay);
-
- if (to_set->tv_nsec < TIME_SET_NSEC_FUZZ) {
- to_set->tv_nsec = 0;
- return true;
- }
-
- if (to_set->tv_nsec > NSEC_PER_SEC - TIME_SET_NSEC_FUZZ) {
- to_set->tv_sec++;
- to_set->tv_nsec = 0;
- return true;
- }
- return false;
-}
-
+ #define devm_rtc_register_device(device) \
+ __devm_rtc_register_device(THIS_MODULE, device)
#ifdef CONFIG_RTC_HCTOSYS_DEVICE
extern int rtc_hctosys_ret;
pgp_T6llZo09b.pgp
Description: OpenPGP digital signature
Re: [PATCH] scripts: add more corrections to spelling.txt
On Mon, 2020-12-14 at 13:28 +0530, Dwaipayan Ray wrote: > Analyzing misspellings over the past 10k commit messages, > a few more corrections are added to spelling.txt I don't agree with all of these. > diff --git a/scripts/spelling.txt b/scripts/spelling.txt [] > @@ -1253,6 +1260,7 @@ senarios||scenarios > sentivite||sensitive > separatly||separately > sepcify||specify > +seperate||separate > seperated||separated > seperately||separately > seperate||separate seperate is already here. > @@ -1482,6 +1493,8 @@ unuseful||useless > unvalid||invalid > upate||update > upsupported||unsupported > +upto|| up to No space before correction > +uptodate||up-to-date This one is fairly commonly used as an identifier so it should not be added here. > @@ -1528,8 +1543,11 @@ wiil||will > wirte||write > withing||within > wnat||want > +wont||won't wont is a properly spelled word and also should not be added here.
Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
On Fri, 11 Dec 2020 at 23:50, Mel Gorman wrote: > > On Fri, Dec 11, 2020 at 11:19:05PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2020 at 08:43:37PM +, Mel Gorman wrote: > > > One bug is in __select_idle_core() though. It's scanning the SMT mask, > > > not select_idle_mask so it can return an idle candidate that is not in > > > p->cpus_ptr. > > > > D'0h.. luckily the benchmarks don't hit that :-) > > > > Yep, neither do mine for the most part which is why I ran it as-is but > eventually someone would complain that sched_setscheduler was being > ignored. > > Trick is whether a failed check should continue searching for an idle core > or terminate early and just pick an allowed idle CPU. I tend to favour > the latter but it's hard to predict what sort of reasonable workloads > would be affected. > > > > There are some other potential caveats. > > > > > > This is a single pass so when test_idle_cores() is true, > > > __select_idle_core > > > is used to to check all the siblings even if the core is not idle. That > > > could have been cut short if __select_idle_core checked *idle_cpu == > > > 1 and terminated the SMT scan if an idle candidate had already been found. > > > > So I did that on purpose, so as to track the last/most-recent idle cpu, > > with the thinking that that cpu has the higher chance of still being > > idle vs one we checked earlier/longer-ago. > > > > I suppose we benchmark both and see which is liked best. > > > > I originally did something like that on purpose too but Vincent called > it out so it is worth mentioning now to avoid surprises. That said, I'm > at the point where anything SIS-related simply needs excessive exposure > because no matter what it does, someone is unhappy with it. Yeah, I don't like extending the idle core search loop for something that is not related to the idle core search. This adds more work out of control of the sis_prop. So I'm still against hiding some idle cpu search in idle core search. > > > > Second downside is related. If test_idle_cpus() was true but no idle > > > CPU is found then __select_idle_core has been called enough to scan > > > the entire domain. In this corner case, the new code does *more* work > > > because the old code would have failed select_idle_core() quickly and > > > then select_idle_cpu() would be throttled by SIS_PROP. I think this will > > > only be noticable in the heavily overloaded case but if the corner case > > > hits enough then the new code will be slower than the old code for the > > > over-saturated case (i.e. hackbench with lots of groups). > > > > Right, due to scanning siblings, even if the first inspected thread is > > not idle, we scan more. > > > > Yep. > > > > The third potential downside is that the SMT sibling is not guaranteed to > > > be checked due to SIS_PROP throttling but in the old code, that would have > > > been checked by select_idle_smt(). That might result in premature stacking > > > of runnable tasks on the same CPU. Similarly, as __select_idle_core may > > > find multiple idle candidates, it will not pick the targets SMT sibling > > > if it is idle like select_idle_smt would have. > > > > > > That said, I am skeptical that select_idle_smt() matters all that often. > > > > This, I didn't really believe in it either. > > > > Good because I think any benefit from select_idle_smt is so marginal > that it should be ignored if the full scan is simpler overall. > > > The benchmarks I started are mostly noise, with a few wins for > > TCP_STREAM and UDP_RR around the 50% mark. Although I should run > > longer variants to make sure. > > So far I have one benchmark from one machine. It's tbench again because > it's a reasonable communicating workload that is trivial to vary the > level of utilisation. > > 80-cpu CascadeLake, 2 sockets, HT enabled > tbench4 > 5.10.0-rc6 5.10.0-rc6 > 5.10.0-rc6 >baseline-v1r1singlescan-v1r1 > singlescan-v1r3 > Hmean 1503.90 ( 0.00%) 505.19 * 0.26%* 499.20 * > -0.93%* > Hmean 2980.80 ( 0.00%) 975.15 * -0.58%* 983.79 * > 0.31%* > Hmean 4 1912.37 ( 0.00%) 1883.25 * -1.52%* 1923.76 * > 0.60%* > Hmean 8 3741.47 ( 0.00%) 3568.66 * -4.62%* 3690.60 * > -1.36%* > Hmean 16 6552.90 ( 0.00%) 6549.97 * -0.04%* 6478.37 * > -1.14%* > Hmean 32 10217.34 ( 0.00%)10266.66 * 0.48%*10291.60 * > 0.73%* > Hmean 64 13604.93 ( 0.00%)11240.88 * -17.38%*12045.87 * > -11.46%* > Hmean 12821194.11 ( 0.00%)21316.08 * 0.58%*21868.39 * > 3.18%* > Hmean 25621163.19 ( 0.00%)20989.14 * -0.82%*20831.20 * > -1.57%* > Hmean 32020906.29 ( 0.00%)21024.11 * 0.56%*20756.88 * > -0.71%* > Stddev1 3.14 ( 0.00%)1.17 ( 62.93%)1.05 ( > 66.61%) > Stddev2
[PATCH 0/2] dmaengine: ti: k3-udma: memcpy throughput improvement
Hi, Newer members of the KS3 family (after AM654) have support for burst_size configuration for each DMA channel. The HW default value is 64 bytes but on higher throughput channels it can be increased to 256 bytes (UCHANs) or 128 byes (HCHANs). Aligning the buffers and length of the transfer to the burst size also increases the throughput. Numbers gathered on j721e (UCHAN pair): echo 800 > /sys/module/dmatest/parameters/test_buf_size echo 2000 > /sys/module/dmatest/parameters/timeout echo 50 > /sys/module/dmatest/parameters/iterations echo 1 > /sys/module/dmatest/parameters/max_channels Prior to this patch: ~1.3 GB/s After this patch: ~1.8 GB/s with 1 byte alignment: ~1.7 GB/s The patches are on top of the AM64 support series: https://lore.kernel.org/lkml/20201208090440.31792-1-peter.ujfal...@ti.com/ Regards, Peter --- Peter Ujfalusi (2): dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem drivers/dma/ti/k3-udma.c | 115 -- include/linux/dmaengine.h | 2 + 2 files changed, 112 insertions(+), 5 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 1/2] dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes
Some DMA device can benefit with higher order of alignment than the maximum
of 64 bytes currently defined.
Define 128 and 256 bytes alignment for these devices.
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 68130f5f599e..004736b6a9c8 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -745,6 +745,8 @@ enum dmaengine_alignment {
DMAENGINE_ALIGN_16_BYTES = 4,
DMAENGINE_ALIGN_32_BYTES = 5,
DMAENGINE_ALIGN_64_BYTES = 6,
+ DMAENGINE_ALIGN_128_BYTES = 7,
+ DMAENGINE_ALIGN_256_BYTES = 8,
};
/**
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 2/2] dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem
The UDMA and BCDMA can provide higher throughput if the burst_size of the
channel is changed from it's default (which is 64 bytes) for Ultra-high
and high capacity channels.
This performance benefit is even more visible when the buffers are aligned
with the burst_size configuration.
The am654 does not have a way to change the burst size, but it is using
64 bytes burst, so increasing the copy_align from 8 bytes to 64 (and
clients taking that into account) can increase the throughput as well.
Numbers gathered on j721e:
echo 800 > /sys/module/dmatest/parameters/test_buf_size
echo 2000 > /sys/module/dmatest/parameters/timeout
echo 50 > /sys/module/dmatest/parameters/iterations
echo 1 > /sys/module/dmatest/parameters/max_channels
Prior this patch: ~1.3 GB/s
After this patch: ~1.8 GB/s
with 1 byte alignment: ~1.7 GB/s
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 115 +--
1 file changed, 110 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 87157cbae1b8..54e4ccb1b37e 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -121,6 +121,11 @@ struct udma_oes_offsets {
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
#define UDMA_FLAG_TDTYPE BIT(2)
+#define UDMA_FLAG_BURST_SIZE BIT(3)
+#define UDMA_FLAGS_J7_CLASS(UDMA_FLAG_PDMA_ACC32 | \
+UDMA_FLAG_PDMA_BURST | \
+UDMA_FLAG_TDTYPE | \
+UDMA_FLAG_BURST_SIZE)
struct udma_match_data {
enum k3_dma_type type;
@@ -128,6 +133,7 @@ struct udma_match_data {
bool enable_memcpy_support;
u32 flags;
u32 statictr_z_mask;
+ u8 burst_size[3];
};
struct udma_soc_data {
@@ -436,6 +442,18 @@ static void k3_configure_chan_coherency(struct dma_chan
*chan, u32 asel)
}
}
+static u8 udma_get_chan_tpl_index(struct udma_tpl *tpl_map, int chan_id)
+{
+ int i;
+
+ for (i = 0; i < tpl_map->levels; i++) {
+ if (chan_id >= tpl_map->start_idx[i])
+ return i;
+ }
+
+ return 0;
+}
+
static void udma_reset_uchan(struct udma_chan *uc)
{
memset(&uc->config, 0, sizeof(uc->config));
@@ -1811,6 +1829,7 @@ static int udma_tisci_m2m_channel_config(struct udma_chan
*uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct udma_tchan *tchan = uc->tchan;
struct udma_rchan *rchan = uc->rchan;
+ u8 burst_size = 0;
int ret = 0;
/* Non synchronized - mem to mem type of transfer */
@@ -1818,6 +1837,12 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
+ if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
+ u8 tpl = udma_get_chan_tpl_index(&ud->tchan_tpl, tchan->id);
+
+ burst_size = ud->match_data->burst_size[tpl];
+ }
+
req_tx.valid_params = TISCI_UDMA_TCHAN_VALID_PARAMS;
req_tx.nav_id = tisci_rm->tisci_dev_id;
req_tx.index = tchan->id;
@@ -1825,6 +1850,10 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
req_tx.tx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
req_tx.txcq_qnum = tc_ring;
req_tx.tx_atype = ud->atype;
+ if (burst_size) {
+ req_tx.valid_params |=
TI_SCI_MSG_VALUE_RM_UDMAP_CH_BURST_SIZE_VALID;
+ req_tx.tx_burst_size = burst_size;
+ }
ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, &req_tx);
if (ret) {
@@ -1839,6 +1868,10 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
req_rx.rxcq_qnum = tc_ring;
req_rx.rx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
req_rx.rx_atype = ud->atype;
+ if (burst_size) {
+ req_rx.valid_params |=
TI_SCI_MSG_VALUE_RM_UDMAP_CH_BURST_SIZE_VALID;
+ req_rx.rx_burst_size = burst_size;
+ }
ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, &req_rx);
if (ret)
@@ -1854,12 +1887,23 @@ static int bcdma_tisci_m2m_channel_config(struct
udma_chan *uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct udma_bchan *bchan = uc->bchan;
+ u8 burst_size = 0;
int ret = 0;
+ if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
+ u8 tpl = udma_get_chan_tpl_index(&ud->bchan_tpl, bchan->id);
+
+ burst_size = ud->match_data->burst_size[tpl];
+ }
+
req_tx.valid_params = TISCI_BCDMA_BCHAN_VALID_PARAMS;
req_tx.nav_id = tisci_rm->tisci_dev_id;
req_tx.extended_ch_type = TI_SCI_RM_BCDM
Re: [PATCH net-next v3 0/4] vsock: Add flags field in the vsock address
On Sat, Dec 12, 2020 at 09:16:08AM -0800, Jakub Kicinski wrote:
On Fri, 11 Dec 2020 16:24:13 +0100 Stefano Garzarella wrote:
On Fri, Dec 11, 2020 at 12:32:37PM +0200, Andra Paraschiv wrote:
>vsock enables communication between virtual machines and the host they are
>running on. Nested VMs can be setup to use vsock channels, as the multi
>transport support has been available in the mainline since the v5.5 Linux
kernel
>has been released.
>
>Implicitly, if no host->guest vsock transport is loaded, all the vsock packets
>are forwarded to the host. This behavior can be used to setup communication
>channels between sibling VMs that are running on the same host. One example can
>be the vsock channels that can be established within AWS Nitro Enclaves
>(see Documentation/virt/ne_overview.rst).
>
>To be able to explicitly mark a connection as being used for a certain use
case,
>add a flags field in the vsock address data structure. The value of the flags
>field is taken into consideration when the vsock transport is assigned. This
way
>can distinguish between different use cases, such as nested VMs / local
>communication and sibling VMs.
>
>The flags field can be set in the user space application connect logic. On the
>listen path, the field can be set in the kernel space logic.
>
I reviewed all the patches and they are in a good shape!
Maybe the last thing to add is a flags check in the
vsock_addr_validate(), to avoid that flags that we don't know how to
handle are specified.
For example if in the future we add new flags that this version of the
kernel is not able to satisfy, we should return an error to the
application.
I mean something like this:
diff --git a/net/vmw_vsock/vsock_addr.c b/net/vmw_vsock/vsock_addr.c
index 909de26cb0e7..73bb1d2fa526 100644
--- a/net/vmw_vsock/vsock_addr.c
+++ b/net/vmw_vsock/vsock_addr.c
@@ -22,6 +22,8 @@ EXPORT_SYMBOL_GPL(vsock_addr_init);
int vsock_addr_validate(const struct sockaddr_vm *addr)
{
+ unsigned short svm_valid_flags = VMADDR_FLAG_TO_HOST;
+
if (!addr)
return -EFAULT;
@@ -31,6 +33,9 @@ int vsock_addr_validate(const struct sockaddr_vm *addr)
if (addr->svm_zero[0] != 0)
return -EINVAL;
Strictly speaking this check should be superseded by the check below
(AKA removed). We used to check svm_zero[0], with the new field added
this now checks svm_zero[2]. Old applications may have not initialized
svm_zero[2] (we're talking about binary compatibility here, apps built
with old headers).
+ if (addr->svm_flags & ~svm_valid_flags)
+ return -EINVAL;
The flags should also probably be one byte (we can define a "more
flags" flag to unlock further bytes) - otherwise on big endian the
new flag will fall into svm_zero[1] so the v3 improvements are moot
for big endian, right?
Right, I assumed the entire svm_zero[] was zeroed out, but we can't be
sure.
So, I agree to change the svm_flags to 1 byte (__u8), and remove the
superseded check that you pointed out.
With these changes we should be fully binary compatibility.
Thanks,
Stefano
return 0;
}
EXPORT_SYMBOL_GPL(vsock_addr_validate);
Re: [PATCH] scripts: add more corrections to spelling.txt
On Mon, Dec 14, 2020 at 1:39 PM Joe Perches wrote: > > On Mon, 2020-12-14 at 13:28 +0530, Dwaipayan Ray wrote: > > Analyzing misspellings over the past 10k commit messages, > > a few more corrections are added to spelling.txt > > I don't agree with all of these. > > > diff --git a/scripts/spelling.txt b/scripts/spelling.txt > [] > > @@ -1253,6 +1260,7 @@ senarios||scenarios > > sentivite||sensitive > > separatly||separately > > sepcify||specify > > +seperate||separate > > seperated||separated > > seperately||separately > > seperate||separate > > seperate is already here. > > > @@ -1482,6 +1493,8 @@ unuseful||useless > > unvalid||invalid > > upate||update > > upsupported||unsupported > > +upto|| up to > > No space before correction > > > +uptodate||up-to-date > > This one is fairly commonly used as an identifier so it should not > be added here. > > > @@ -1528,8 +1543,11 @@ wiil||will > > wirte||write > > withing||within > > wnat||want > > +wont||won't > > wont is a properly spelled word and also should not be added here. > Okay thanks, will replace those. Also please ignore the v2 of this patch. That was sent earlier your review. I will send in a v3 to fix these. Thank you, Dwaipayan.
[GIT PULL for v5.11-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.11-1 For media updates for Kernel 5.11, containing: - some rework at the uAPI pixel format docs; - the smiapp driver has started to gain support for MIPI CSS camera sensors and was renamed; - Two new sensor drivers: ov02a10 and ov9734; - Meson gained a driver for the 2D acceleration unit; - Rockchip rkisp1 driver was promoted from staging; - Cedrus driver gained support for VP8; - Two new remote controller keymaps were added; - An usual set of fixes cleanups and driver improvements. Regards, Mauro The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.11-1 for you to fetch changes up to 7ea4d23293300ca2f225595849a4fe444fb80ea4: media: ccs: Add support for obtaining C-PHY configuration from firmware (2020-12-07 17:05:16 +0100) media updates for v5.11-rc1 Alain Volmat (1): media: stm32-dcmi: add 8-bit Bayer formats support Alan Stern (1): media: gspca: Fix memory leak in probe Alexander A. Klimov (1): media: Replace HTTP links with HTTPS ones: SI2165 MEDIA DRIVER Alexandre Courbot (1): media: venus: vdec: return parsed crop information from stream Andrey Konovalov (2): media: Revert "media: camss: Make use of V4L2_CAP_IO_MC" media: camss: Make use of V4L2_CAP_IO_MC Andy Shevchenko (1): media: ipu3-cio2: Use macros from mm.h AngeloGioacchino Del Regno (7): media: camss: ispif: Correctly reset based on the VFE ID media: camss: vfe-4-7: Rename get_ub_size, set_qos, set_ds, wm_enable media: camss: vfe: Add support for VFE 4.8 media: dt-bindings: media: qcom,camss: Add bindings for SDM660 camss media: camss: Add support for SDM630/636/660 camera subsystem media: camss: csiphy-3ph: Add support for SDM630/660 media: camss: csiphy: Set rate on csiX_phy clock on SDM630/660 Antti Palosaari (1): media: msi2500: assign SPI bus number dynamically Arnd Bergmann (10): media: v4l2: prepare compat-ioctl rework media: v4l2: remove unneeded compat ioctl handlers media: v4l2: move v4l2_ext_controls conversion media: v4l2: move compat handling for v4l2_buffer media: v4l2: allocate v4l2_clip objects early media: v4l2: convert v4l2_format compat ioctls media: v4l2: remaining compat handlers media: v4l2: remove remaining compat_ioctl media: i2c: fix an uninitialized error code media: ccs: avoid printing an uninitialized variable Baskov Evgeniy (1): media: s5p-jpeg: handle error condition in s5p_jpeg_probe Bingbu Cao (4): media: ov2740: change the minimal exposure value to 4 media: ov2740: only do OTP data read on demand from user media: ov2740: allow OTP data access during streaming media: ov9734: hold lock to check streaming state Bixuan Cui (1): media: tuners: reduce stack usage in mxl5005s_reconfigure Christian Hewitt (2): media: rc: add keymap for KHAMSIN remote media: meson: vdec: add G12/SM1 to module description Christophe JAILLET (7): media: b2c2: switch from 'pci_' to 'dma_' API media: bt8xx: switch from 'pci_' to 'dma_' API media: bt8xx: avoid a useless memset media: dm1105: switch from 'pci_' to 'dma_' API media: solo6x10: switch from 'pci_' to 'dma_' API media: ttpci: switch from 'pci_' to 'dma_' API media: saa7146: switch from 'pci_' to 'dma_' API Colin Ian King (5): media: zoran: fix spelling mistake and make error message more meaningful media: tm6000: Fix sizeof() mismatches media: staging: rkisp1: rsz: make const array static, makes object smaller media: mantis: remove redundant assignment to variable err media: ov2740: fix dereference before null check on pointer nvm Dafna Hirschfeld (11): media: staging: rkisp1: remove TODO item to document quantization handling media: staging: rkisp1: validate links before powering and streaming media: staging: rkisp1: params: in stop_streaming, use list_splice_init to move the buffers media: staging: rkisp1: initialize buffer lists only on probe media: staging: rkisp1: remove the 'is_streaming' field from stats and params media: staging: rkisp1: params: remove unnecessary "!!" media: staging: rkisp1: params: remove unnecessary parentheses media: staging: rkisp1: uapi: add "WITH Linux-syscall-note" media: staging: rkisp1: capture: set default quantization on 'set_fmt' media: uapi: add MEDIA_BUS_FMT_METADATA_FIXED media bus format. media: staging: rkisp1: isp: set met
RE: [PATCH v2 04/10] regulator: bd9571mwv: Add BD9574MWF support
Hello Matti-san,
> From: Vaittinen, Matti, Sent: Monday, December 14, 2020 4:13 PM
>
> Hello Shimoda-san,
>
> On Mon, 2020-12-14 at 04:57 +, Yoshihiro Shimoda wrote:
> > Hello Matti-san,
> >
> > > From: Vaittinen, Matti, Sent: Friday, December 11, 2020 9:34 PM
> > >
> > > Hello again Shimada-san,
> > >
> > > On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > > > Add support for BD9574MWF which is silimar chip with BD9571MWV.
> > > > Note that BD9574MWF doesn't support AVS and VID.
> > >
> > > I'd like to understand what is VID?
> >
> > It seems reading some voltages from registers.
> > For example, BD9571 has "VD18_VID" register which
> > is prohibit to write. But, BD9574 doesn't have this
> > register. Also, the driver names "vid_ops",
> > so I described "VID" here. Perhaps, we should revise
> > the description to clear. (Please look "Updated description" in this
> > email.)
>
> Thank you for detailed explanation. So as far as I understood - VID is
> a register which displays the current output voltage, right?
Yes.
> If I am
> not mistaken, this is different from register where (initial) voltage
> is set?
Yes. I checked on my environment (H3 Salvator-XS).
> > > > Signed-off-by: Yoshihiro Shimoda <
> > > > yoshihiro.shimoda...@renesas.com>
> > > > ---
> > > > drivers/regulator/bd9571mwv-regulator.c | 10 --
> > > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/regulator/bd9571mwv-regulator.c
> > > > b/drivers/regulator/bd9571mwv-regulator.c
> > > > index 02120b0..041339b 100644
> > > > --- a/drivers/regulator/bd9571mwv-regulator.c
> > > > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > > > @@ -1,6 +1,6 @@
> > > > // SPDX-License-Identifier: GPL-2.0
> > > > /*
> > > > - * ROHM BD9571MWV-M regulator driver
> > > > + * ROHM BD9571MWV-M and BD9574MWF-M regulator driver
> > > > *
> > > > * Copyright (C) 2017 Marek Vasut > > > >
> > > > *
> > > > @@ -9,6 +9,7 @@
> > > > * NOTE: VD09 is missing
> > > > */
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -277,6 +278,7 @@ static int bd9571mwv_regulator_probe(struct
> > > > platform_device *pdev)
> > > > struct regulator_dev *rdev;
> > > > unsigned int val;
> > > > int i;
> > > > + enum rohm_chip_type chip = platform_get_device_id(pdev)-
> > > > > driver_data;
> > > >
> > > > bdreg = devm_kzalloc(&pdev->dev, sizeof(*bdreg), GFP_KERNEL);
> > > > if (!bdreg)
> > > > @@ -292,6 +294,9 @@ static int bd9571mwv_regulator_probe(struct
> > > > platform_device *pdev)
> > > > config.regmap = bdreg->regmap;
> > > >
> > > > for (i = 0; i < ARRAY_SIZE(regulators); i++) {
> > > > + /* BD9574MWF supports DVFS only */
> > > > + if (chip == ROHM_CHIP_TYPE_BD9574 && regulators[i].id
> > > > != DVFS)
> > > > + continue;
> > >
> > > Does this mean that reading VD09 voltage is not supported by
> > > driver?
> >
> > Yes. Also, reading VD{18,25,33} voltage are not supported.
>
> I think that would be excellent comment here. Maybe something like: "We
> don't support voltage rails VD{09,18,25,33} by this driver on BD9574."
Thank you for the suggestion! I'll use this comment.
> > > (I
> > > assumed VD09 initial voltage can be set from eeprom(?) and read by
> > > driver - I may be wrong though). Perhaps it is worth mentioning in
> > > the
> > > commit message as a driver restriction?
> >
> > Yes, these voltage can be set from eeprom and read by driver.
> > So, I updated the description like below.
> >
> > -- Updated description --
> > Add support for BD9574MWF which is similar chip with BD9571MWV.
> > Note that since BD9574MWF doesn't have avs_ops and vid_ops
> > related registers, this driver avoids to use these registers
> > if BD9574MWF is used.
> >
>
> Thank you :) What I was after is that I would like to leave a note
> about 'what could be improved' or about what is the 'software
> limitation' here so that if anyone later needs the other voltage rails
> he would have a hint about what could be done.
>
> Do you think mentioning that "the VD09 voltage could be read from PMIC
> but that is not supported by this commit" in commit message would be
> Ok?
I think OK because VD09 could be read from "BD9574MWF_VD09_VINIT"
register, but that is not supported but this commit.
> > > And just asking out of the curiosity - are the other voltage rails
> > > listed in data-sheet (VD18, DDR0, VD33, VD09 and LDO1,...,LDO4)
> > > set-up
> > > from DT as fixed-regulators? Any reason why they are not set-up
> > > here?
> >
> > TBH, I don't know why. Perhaps, the driver cannot read DDR0, LDO[1-4]
> > values?
>
> I also think that all voltages can't be read. I was just thinking that
> it might make sense to always create the fixed regulators from PMIC
> driver - because if PMIC is used - then these voltage rails do exist.
> (This was jus
[PATCH v2 3/3] arm64: defconfig: enable GPIO_HISI
Enable GPIO controller for HiSilicon's ARM SoC. GPIO is common driver for HiSilicon's ARM SoC and it provide support for some function of I2C and SPI. Signed-off-by: Luo Jiaxing --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 5cfe3cf..b5cdf5e 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -498,6 +498,7 @@ CONFIG_PINCTRL_SM8150=y CONFIG_PINCTRL_SM8250=y CONFIG_GPIO_ALTERA=m CONFIG_GPIO_DWAPB=y +CONFIG_GPIO_HISI=y CONFIG_GPIO_MB86S7X=y CONFIG_GPIO_MPC8XXX=y CONFIG_GPIO_MXC=y -- 2.7.4
[PATCH v2 2/3] MAINTAINERS: Add maintainer for HiSilicon GPIO driver
Here add maintainer information for HiSilicon GPIO driver. Signed-off-by: Luo Jiaxing --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee..8d13419a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7896,6 +7896,13 @@ L: dmaeng...@vger.kernel.org S: Maintained F: drivers/dma/hisi_dma.c +HISILICON GPIO DRIVER +M: Luo Jiaxing +L: linux-g...@vger.kernel.org +S: Maintained +F: drivers/gpio/gpio-hisi.c +F: include/linux/platform_data/gpio-hisi.h + HISILICON HIGH PERFORMANCE RSA ENGINE DRIVER (HPRE) M: Zaibo Xu L: linux-cry...@vger.kernel.org -- 2.7.4
[PATCH v2 1/3] gpio: gpio-hisi: Add HiSilicon GPIO support
This GPIO driver is for HiSilicon's ARM SoC.
HiSilicon's GPIO controller support double-edge interrupt and multi-core
concurrent access.
ACPI table example for this GPIO controller:
Device (GPO0)
{
Name (_HID, "HISI0184")
Device (PRTA)
{
Name (_ADR, Zero)
Name (_UID, Zero)
Name (_DSD, Package (0x01)
{
Package (0x02)
{
"ngpios",
0x20
}
})
}
}
Signed-off-by: Luo Jiaxing
---
drivers/gpio/Kconfig | 11 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-hisi.c | 328 +++
3 files changed, 340 insertions(+)
create mode 100644 drivers/gpio/gpio-hisi.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 5d4de5c..2598209 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -296,6 +296,17 @@ config GPIO_GRGPIO
Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
VHDL IP core library.
+config GPIO_HISI
+ tristate "HiSilicon GPIO controller driver"
+ depends on (ARM64 || COMPILE_TEST) && ACPI
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say Y or M here to build support for the HiSilicon GPIO controller
+ driver GPIO block.
+ This GPIO controller support double-edge interrupt and multi-core
+ concurrent access.
+
config GPIO_HLWD
tristate "Nintendo Wii (Hollywood) GPIO"
depends on OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 09dada8..260ae25 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_GPIO_GE_FPGA)+= gpio-ge.o
obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
obj-$(CONFIG_GPIO_GW_PLD) += gpio-gw-pld.o
+obj-$(CONFIG_GPIO_HISI) += gpio-hisi.o
obj-$(CONFIG_GPIO_HLWD)+= gpio-hlwd.o
obj-$(CONFIG_HTC_EGPIO)+= gpio-htc-egpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
diff --git a/drivers/gpio/gpio-hisi.c b/drivers/gpio/gpio-hisi.c
new file mode 100644
index 000..a389780
--- /dev/null
+++ b/drivers/gpio/gpio-hisi.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2020 HiSilicon Limited. */
+#include
+#include
+#include
+#include
+#include
+
+#define HISI_GPIO_SWPORT_DR_SET_WX 0x000
+#define HISI_GPIO_SWPORT_DR_CLR_WX 0x004
+#define HISI_GPIO_SWPORT_DDR_SET_WX0x010
+#define HISI_GPIO_SWPORT_DDR_CLR_WX0x014
+#define HISI_GPIO_SWPORT_DDR_ST_WX 0x018
+#define HISI_GPIO_INTEN_SET_WX 0x020
+#define HISI_GPIO_INTEN_CLR_WX 0x024
+#define HISI_GPIO_INTMASK_SET_WX 0x030
+#define HISI_GPIO_INTMASK_CLR_WX 0x034
+#define HISI_GPIO_INTTYPE_EDGE_SET_WX 0x040
+#define HISI_GPIO_INTTYPE_EDGE_CLR_WX 0x044
+#define HISI_GPIO_INT_POLARITY_SET_WX 0x050
+#define HISI_GPIO_INT_POLARITY_CLR_WX 0x054
+#define HISI_GPIO_DEBOUNCE_SET_WX 0x060
+#define HISI_GPIO_DEBOUNCE_CLR_WX 0x064
+#define HISI_GPIO_INTSTATUS_WX 0x070
+#define HISI_GPIO_PORTA_EOI_WX 0x078
+#define HISI_GPIO_EXT_PORT_WX 0x080
+#define HISI_GPIO_INTCOMB_MASK_WX 0x0a0
+#define HISI_GPIO_INT_DEDGE_SET0x0b0
+#define HISI_GPIO_INT_DEDGE_CLR0x0b4
+#define HISI_GPIO_INT_DEDGE_ST 0x0b8
+
+#define HISI_GPIO_LINE_NUM_MAX 32
+#define HISI_GPIO_DRIVER_NAME "gpio-hisi"
+
+struct hisi_gpio {
+ struct gpio_chipchip;
+ struct device *dev;
+ void __iomem*reg_base;
+ unsigned intline_num;
+ struct irq_chip irq_chip;
+ int irq;
+};
+
+static inline u32 hisi_gpio_read_reg(struct gpio_chip *chip,
+unsigned int off)
+{
+ struct hisi_gpio *hisi_gpio =
+ container_of(chip, struct hisi_gpio, chip);
+ void __iomem *reg = hisi_gpio->reg_base + off;
+
+ return readl(reg);
+}
+
+static inline void hisi_gpio_write_reg(struct gpio_chip *chip,
+ unsigned int off, u32 val)
+{
+ struct hisi_gpio *hisi_gpio =
+ container_of(chip, struct hisi_gpio, chip);
+ void __iomem *reg = hisi_gpio->reg_base + off;
+
+ writel(val, reg);
+}
+
+static void hisi_gpio_set_debounce(struct gpio_chip *chip, unsigned int off,
+ u32 debounce)
+{
+ if (debounce)
+ hisi_gpio_write_reg(chip, HISI_GPIO_DEBOUNCE_SET_WX, BIT(off));
+ else
+ hisi_gpio_write_reg(chip, HISI_GPIO_DEBOUNCE_CLR_WX, BIT(off));
+}
+
+static int hisi_gpio_set_config(struct gpio_chip *chip,
[PATCH v2 0/3] gpio: gpio-hisi: Add HiSilicon GPIO support
This series is the GPIO driver for HiSilicon's ARM SoC. It provide patches for device driver, MAINTAINER file, and enable gpio-hisi at defconfig. Thanks Jiaxing --- v1->v2: 1. set (ARM64 || COMPILE_TEST) && ACPI at kconfig. 2. Delete some useless header files. 3. Replace "hisi-ngpio" with "ngpios", fix firmware too 4. Direction setting is modified to be handle by generic GPIO 5. Add error code print 6. Some tiny clean up --- Luo Jiaxing (3): gpio: gpio-hisi: Add HiSilicon GPIO support MAINTAINERS: Add maintainer for HiSilicon GPIO driver arm64: defconfig: enable GPIO_HISI MAINTAINERS | 7 + arch/arm64/configs/defconfig | 1 + drivers/gpio/Kconfig | 11 ++ drivers/gpio/Makefile| 1 + drivers/gpio/gpio-hisi.c | 328 +++ 5 files changed, 348 insertions(+) create mode 100644 drivers/gpio/gpio-hisi.c -- 2.7.4
Re: [PATCH RT 2/4] Revert "hrtimer: Allow raw wakeups during boot"
On 2020-12-11 16:41:05 [-0500], Steven Rostedt wrote:
> 5.4.82-rt46-rc1 stable review patch.
> If anyone has any objections, please let me know.
>
> --
>
> From: Sebastian Andrzej Siewior
>
> This change is no longer needed since commit
>26c7295be0c5e ("kthread: Do not preempt current task if it is going to
> call schedule()")
This patch has been integrated in v5.7-rc1 and it made its way into
v5.4.61. Okay, why not.
> Signed-off-by: Sebastian Andrzej Siewior
> Signed-off-by: Steven Rostedt (VMware)
Sebastian
[PATCH v3] scripts: add more corrections to spelling.txt
Analyzing misspellings over the past 10k commit messages, a few more corrections are added to spelling.txt Signed-off-by: Dwaipayan Ray --- Changes in v3: - Remove duplicate correction for "seperate" - Remove corrections for "uptodate", "wont" Changes in v2: - Fix additional whitespace before "up to" scripts/spelling.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 953f4a2de1e5..8b27dcf67d0c 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -315,6 +315,7 @@ commited||committed commiting||committing committ||commit commoditiy||commodity +comon||common comsume||consume comsumer||consumer comsuming||consuming @@ -347,6 +348,7 @@ condtion||condition conected||connected conector||connector configration||configuration +configred||configured configuartion||configuration configuation||configuration configued||configured @@ -437,6 +439,7 @@ dependant||dependent dependend||dependent depreacted||deprecated depreacte||deprecate +derefencing||dereferencing desactivate||deactivate desciptor||descriptor desciptors||descriptors @@ -608,6 +611,7 @@ failue||failure failuer||failure failng||failing faireness||fairness +falg||flag falied||failed faliure||failure fallbck||fallback @@ -722,6 +726,7 @@ implemntation||implementation implentation||implementation implmentation||implementation implmenting||implementing +improvments||improvements incative||inactive incomming||incoming incompatabilities||incompatibilities @@ -772,6 +777,7 @@ instal||install instanciate||instantiate instanciated||instantiated insufficent||insufficient +intead||instead inteface||interface integreated||integrated integrety||integrity @@ -1151,6 +1157,7 @@ recyle||recycle redircet||redirect redirectrion||redirection redundacy||redundancy +reenable||re-enable reename||rename refcounf||refcount refence||reference @@ -1334,6 +1341,7 @@ substract||subtract submited||submitted submition||submission suceed||succeed +suceeded||succeeded succesfully||successfully succesful||successful successed||succeeded @@ -1354,6 +1362,7 @@ suppoted||supported suppported||supported suppport||support supress||suppress +suprising||surprising surpressed||suppressed surpresses||suppresses susbsystem||subsystem @@ -1475,6 +1484,7 @@ unsinged||unsigned unstabel||unstable unsolicitied||unsolicited unsuccessfull||unsuccessful +unsued||unused unsuported||unsupported untill||until ununsed||unused @@ -1482,6 +1492,7 @@ unuseful||useless unvalid||invalid upate||update upsupported||unsupported +upto||up to usefule||useful usefull||useful usege||usage @@ -1499,10 +1510,12 @@ vaild||valid valide||valid variantions||variations varible||variable +varibles||variables varient||variant vaule||value verbse||verbose veify||verify +vender||vendor verisons||versions verison||version verson||version @@ -1529,7 +1542,9 @@ wirte||write withing||within wnat||want workarould||workaround +wraper||wrapper writeing||writing +writen||written writting||writing wtih||with zombe||zombie -- 2.27.0
[RFC PATCH v6] mm: Optional full ASLR for mmap(), mremap(), vdso, stack and heap
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space enables full randomization of memory mappings. With 2, the base of the VMA used for such mappings is random, but the mappings are created in predictable places within the VMA and in sequential order. With 3, new VMAs are created to fully randomize the mappings. Mappings created with mmap(NULL, ...) are randomized and mremap(..., MREMAP_MAYMOVE) will move the mappings even if not necessary. The locations of heap (memory allocated with brk()), stack and vdso are also randomized. On 32 bit systems this may cause problems due to increased VM fragmentation if the address space gets crowded. On all systems, it will reduce performance and increase memory and cache usage due to less efficient use of page tables and inability to merge adjacent VMAs with compatible attributes. On x86_64 with 5 level page tables, in the worst case, additional page table entries of up to 4 pages are created for each mapping, so with small mappings there's considerable penalty. By lowering the lowest address for mapping the main executable from 2/3 of the address space to sysctl.vm.mmap_min_addr, it's possible to use the full 35 bits available on x86_64 for ASLR. The method is to randomize the new address without considering VMAs. If the address fails checks because of overlap with the stack area (or in case of mremap(), overlap with the old mapping), the operation is retried a few times before falling back to old method. In this example with sysctl.kernel.randomize_va_space = 2, main executable, heap allocated with brk(), locale-archive, libc, dynamic loader, some anonymous memory reserved with mmap(), stack and vdso are located in three groups and inside each group the mappings are close to each other: $ cat /proc/self/maps (only first line for each object shown for brevity) 55d61f2ac000-55d61f2ae000 r--p fe:0c 1868624 /usr/bin/cat 7f9124f4-7f91254a2000 r--p fe:0c 2474005 /usr/lib/locale/locale-archive 7f91254a2000-7f91255a2000 rw-p 00:00 0 7f91255a2000-7f91255c7000 r--p fe:0c 2402332 /usr/lib/x86_64-linux-gnu/libc-2.31.so 7f9125763000-7f9125769000 rw-p 00:00 0 7f9125795000-7f9125796000 r--p fe:0c 2400754 /usr/lib/x86_64-linux-gnu/ld-2.31.so 7f91257c1000-7f91257c2000 rw-p 00:00 0 7ffdf983d000-7ffdf985e000 rw-p 00:00 0 [stack] 7ffdf9897000-7ffdf989b000 r--p 00:00 0 [vvar] 7ffdf989b000-7ffdf989d000 r-xp 00:00 0 [vdso] With sysctl.kernel.randomize_va_space = 3, they are located at unrelated addresses and the order is random: $ echo 3 > /proc/sys/kernel/randomize_va_space $ cat /proc/self/maps (only first line for each object shown for brevity) bc5ed961000-bc5eda61000 rw-p 00:00 0 2968e14a4000-2968e14c5000 rw-p 00:00 0 [stack] 30f80fb63000-30f80fb65000 r--p fe:0c 1868624 /usr/bin/cat 381de5bfa000-381de5bfe000 r--p 00:00 0 [vvar] 381de5bfe000-381de5c0 r-xp 00:00 0 [vdso] 42cd1060d000-42cd10632000 r--p fe:0c 2402332 /usr/lib/x86_64-linux-gnu/libc-2.31.so 42cd107ce000-42cd107d2000 rw-p 00:00 0 547f9c21b000-547f9c21c000 r--p fe:0c 2400754 /usr/lib/x86_64-linux-gnu/ld-2.31.so 547f9c247000-547f9c248000 rw-p 00:00 0 743548368000-7435488ca000 r--p fe:0c 2474005 /usr/lib/locale/locale-archive 7dd3a185f000-7dd3a1861000 rw-p 00:00 0 CC: Andrew Morton CC: Jann Horn CC: Kees Cook CC: Matthew Wilcox CC: Mike Rapoport CC: Linux API Signed-off-by: Topi Miettinen --- v2: also randomize mremap(..., MREMAP_MAYMOVE) v3: avoid stack area and retry in case of bad random address (Jann Horn), improve description in kernel.rst (Matthew Wilcox) v4: - use /proc/$pid/maps in the example (Mike Rapaport) - CCs (Andrew Morton) - only check randomize_va_space == 3 v5: randomize also vdso and stack v6: - randomize also heap - use 35 bits for ASLR on x86_64 - RFC due to temporarily disabling mremap() randomization --- Documentation/admin-guide/hw-vuln/spectre.rst | 6 ++--- Documentation/admin-guide/sysctl/kernel.rst | 22 + arch/x86/Kconfig | 2 +- arch/x86/entry/vdso/vma.c | 7 +- arch/x86/kernel/process.c | 5 +++- arch/x86/mm/mmap.c| 3 +++ fs/binfmt_elf.c | 7 +- init/Kconfig | 2 +- mm/mmap.c | 24 ++- mm/mremap.c | 10 mm/util.c | 14 ++- 11 files changed, 92 i
[PATCH v4] usb: xhci-mtk: fix unreleased bandwidth data
xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
to handle its own sw bandwidth managements and stores bandwidth data
into internal table every time add_endpoint() is called,
so when bandwidth allocation fails at one endpoint, all earlier
allocation from the same interface could still remain at the table.
This patch adds two more hooks from check_bandwidth() and
reset_bandwidth(), and make mtk-xhci to releases all failed endpoints
from reset_bandwidth().
Fixes: 4b0f7a77fb3c ("usb: xhci-mtk: supports bandwidth scheduling with
multi-TT")
Signed-off-by: Ikjoon Jang
---
Changes in v4:
- bugfix in v3, check_bandwidth() returns an uninitialized
value when no endpoints were newly added.
Changes in v3:
- drop unrelated code cleanups
- change Fixes tag to keep dependency
Changes in v2:
- fix a 0-day warning from unused variable
- split one big patch into three patches
- fix wrong offset in mediatek hw flags
drivers/usb/host/xhci-mtk-sch.c | 124 ++--
drivers/usb/host/xhci-mtk.h | 13
drivers/usb/host/xhci.c | 9 +++
3 files changed, 109 insertions(+), 37 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index 45c54d56ecbd..95d20de9fd1f 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_sch_ep(struct
usb_device *udev,
sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(&sch_ep->tt_endpoint);
return sch_ep;
}
@@ -583,6 +584,8 @@ int xhci_mtk_sch_init(struct xhci_hcd_mtk *mtk)
mtk->sch_array = sch_array;
+ INIT_LIST_HEAD(&mtk->bw_ep_list_new);
+
return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_sch_init);
@@ -601,19 +604,14 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_ep_ctx *ep_ctx;
struct xhci_slot_ctx *slot_ctx;
struct xhci_virt_device *virt_dev;
- struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep;
- struct mu3h_sch_bw_info *sch_array;
unsigned int ep_index;
- int bw_index;
- int ret = 0;
xhci = hcd_to_xhci(hcd);
virt_dev = xhci->devs[udev->slot_id];
ep_index = xhci_get_endpoint_index(&ep->desc);
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
- sch_array = mtk->sch_array;
xhci_dbg(xhci, "%s() type:%d, speed:%d, mpkt:%d, dir:%d, ep:%p\n",
__func__, usb_endpoint_type(&ep->desc), udev->speed,
@@ -632,39 +630,34 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
return 0;
}
- bw_index = get_bw_index(xhci, udev, ep);
- sch_bw = &sch_array[bw_index];
-
sch_ep = create_sch_ep(udev, ep, ep_ctx);
if (IS_ERR_OR_NULL(sch_ep))
return -ENOMEM;
setup_sch_info(udev, ep_ctx, sch_ep);
- ret = check_sch_bw(udev, sch_bw, sch_ep);
- if (ret) {
- xhci_err(xhci, "Not enough bandwidth!\n");
- if (is_fs_or_ls(udev->speed))
- drop_tt(udev);
-
- kfree(sch_ep);
- return -ENOSPC;
- }
+ list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_list_new);
- list_add_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
- | EP_BCSCOUNT(sch_ep->cs_count) | EP_BBM(sch_ep->burst_mode));
- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
- | EP_BREPEAT(sch_ep->repeat));
+static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
+struct mu3h_sch_ep_info *sch_ep)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+ int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ struct mu3h_sch_bw_info *sch_bw = &mtk->sch_array[bw_index];
- xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
- sch_ep->pkts, sch_ep->cs_count, sch_ep->burst_mode,
- sch_ep->offset, sch_ep->repeat);
+ update_bus_bw(sch_bw, sch_ep, 0);
+ list_del(&sch_ep->endpoint);
- return 0;
+ if (sch_ep->sch_tt) {
+ list_del(&sch_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
}
-EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
@@ -675,7 +668,7 @@ void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_virt_device *virt_dev;
struct mu3h_sch_bw_info *sch_array;
struct mu3h_sch_bw_info *sch_bw;
- struct mu3h_sch_ep_info *sch_
[rcu:dev.2020.12.11a] BUILD SUCCESS 457a888fb6f529c50eb5bcaf1efe416f58d89d6f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.12.11a branch HEAD: 457a888fb6f529c50eb5bcaf1efe416f58d89d6f squash! torture: Compress KASAN vmlinux files elapsed time: 723m configs tested: 94 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 sh se7705_defconfig sh rts7751r2d1_defconfig sh se7206_defconfig powerpcsam440ep_defconfig arc allyesconfig powerpc cm5200_defconfig xtensa audio_kc705_defconfig shdreamcast_defconfig arm cm_x300_defconfig openrisc alldefconfig arm at91_dt_defconfig arm netwinder_defconfig arm ixp4xx_defconfig arm pxa910_defconfig mips fuloong2e_defconfig mips db1xxx_defconfig arm ezx_defconfig mips bmips_be_defconfig shmigor_defconfig powerpc mpc85xx_cds_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig nios2 defconfig nds32 allnoconfig c6x allyesconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20201214 i386 randconfig-a004-20201214 i386 randconfig-a003-20201214 i386 randconfig-a002-20201214 i386 randconfig-a006-20201214 i386 randconfig-a005-20201214 i386 randconfig-a014-20201213 i386 randconfig-a013-20201213 i386 randconfig-a012-20201213 i386 randconfig-a011-20201213 i386 randconfig-a016-20201213 i386 randconfig-a015-20201213 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a016-20201213 x86_64 randconfig-a012-20201213 x86_64 randconfig-a013-20201213 x86_64 randconfig-a015-20201213 x86_64 randconfig-a014-20201213 x86_64 randconfig-a011-20201213 x86_64 randconfig-a003-20201214 x86_64 randconfig-a006-20201214 x86_64 randconfig-a002-20201214 x86_64 randconfig-a005-20201214 x86_64 randconfig-a004-20201214 x86_64 randconfig-a001-20201214 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] trace: drop unneeded assignment in ring_buffer_resize()
Since commit 0a1754b2a97e ("ring-buffer: Return 0 on success from
ring_buffer_resize()"), computing the size is not needed anymore.
Drop unneeded assignment in ring_buffer_resize().
Signed-off-by: Lukas Bulwahn
---
kernel/trace/ring_buffer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 91db9d032a0c..95ecfb107e3e 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1974,8 +1974,6 @@ int ring_buffer_resize(struct trace_buffer *buffer,
unsigned long size,
if (nr_pages < 2)
nr_pages = 2;
- size = nr_pages * BUF_PAGE_SIZE;
-
/* prevent another thread from changing buffer sizes */
mutex_lock(&buffer->mutex);
--
2.17.1
[PATCH v2] drivers/perf: Enable PID_IN_CONTEXTIDR with SPE
Enable PID_IN_CONTEXTIDR by default when Arm SPE is enabled. This flag is required to get PID data in the SPE trace. Without it the perf tool will report 0 for PID which isn't very useful, especially when doing system wide profiling or profiling applications that fork. There is a small performance overhead when enabling PID_IN_CONTEXTIDR, but SPE itself is optional and not enabled by default so the impact is minimised. Cc: Will Deacon Cc: Mark Rutland Cc: Al Grant Cc: Leo Yan Cc: John Garry Cc: Suzuki K Poulose Cc: Mathieu Poirier Cc: Catalin Marinas Signed-off-by: James Clark --- arch/arm64/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug index 265c4461031f..b030bb21a0bb 100644 --- a/arch/arm64/Kconfig.debug +++ b/arch/arm64/Kconfig.debug @@ -2,6 +2,7 @@ config PID_IN_CONTEXTIDR bool "Write the current PID to the CONTEXTIDR register" + default y if ARM_SPE_PMU help Enabling this option causes the kernel to write the current PID to the CONTEXTIDR register, at the expense of some additional -- 2.28.0
Re: [v2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase
On Thu, 2020-12-10 at 15:03 +0200, Grygorii Strashko wrote:
>
> On 10/12/2020 03:56, Qii Wang wrote:
> > On Mon, 2020-12-07 at 18:35 +0200, Grygorii Strashko wrote:
> >>
> >>>
> >>> On Thu, 2020-12-03 at 10:01 +0200, Grygorii Strashko wrote:
>
> On 03/12/2020 03:25, Qii Wang wrote:
> > On Wed, 2020-12-02 at 16:35 +0100, Wolfram Sang wrote:
> >> Hi,
> >>
> >>> Some i2c device driver indirectly uses I2C driver when it is now
> >>> being suspended. The i2c devices driver is suspended during the
> >>> NOIRQ phase and this cannot be changed due to other dependencies.
> >>> Therefore, we also need to move the suspend handling for the I2C
> >>> controller driver to the NOIRQ phase as well.
> >>>
> >>> Signed-off-by: Qii Wang
> >>
> >> Is this a bugfix and should go into 5.10? Or can it wait for 5.11?
> >>
> >
> > Yes, Can you help to apply it into 5.10? Thanks
>
> To be honest if you still do have any i2c device which accessing i2c
> buss after _noirq
> stage and your driver does not implement .master_xfer_atomic() - you
> definitely have a bigger problem.
> So adding IRQF_NO_SUSPEND sound like a hack and probably works just by
> luck.
>
> >>>
> >>> At present, it is only a problem caused by missing interrupts,
> >>> and .master_xfer_atomic() just a implement in polling mode. Why not set
> >>> the interrupt to a state that can always be triggered?
> >>>
> >>>
> >>
> >> Because you must not use any IRQ driven operations after _noirq suspend
> >> state as it might (and most probably will)
> >> cause unpredictable behavior later in suspend_enter():
> >>
> >>arch_suspend_disable_irqs();
> >>BUG_ON(!irqs_disabled());
> >> ^after this point any IRQ driven I2C transfer will cause IRQ to be
> >> re-enabled
> >>
> >> if you need turn off device from platform callbacks -
> >> .master_xfer_atomic() has to be implemented and used.
> >>
> > Maybe my comment is a bit disturbing.Our purpose is not to call i2c and
> > use interrupts after _noirq pauses.So We use
> > i2c_mark_adapter_suspended&i2c_mark_adapter_resumed to block these i2c
> > transfers， There will not have any IRQ driven I2C transfer after this
> > point:
> > arch_suspend_disable_irqs();
> > BUG_ON(!irqs_disabled());
> > But some device driver will do i2c transfer after
> > dpm_noirq_resume_devices in dpm_resume_noirq(PMSG_RESUME) when our
> > driver irq hasn't resume.
> > void dpm_resume_noirq(pm_message_t state)
> > {
> > dpm_noirq_resume_devices(state);
>
> Just to clarify. You have resume sequence in dpm_noirq_resume_devices
> dpm_noirq_resume_devices -> resume I2C -> resume some device -> do i2c
> transfer after?
>
Yes.
> Is "some device" in Kernel mainline?
>
The problematic device driver is drivers/regulator/da9211-regulator.c in
Kernel mainline.
> > resume_device_irqs();
> > device_wakeup_disarm_wake_irqs();
> > cpuidle_resume();
> > }
> > .master_xfer_atomic() seems to be invalid for this question at this
> > time?
> >
>
Build regressions/improvements in v5.10
Below is the list of build error/warning regressions/improvements in
v5.10[1] compared to v5.9[2].
Summarized:
- build errors: +2/-7
- build warnings: +21/-30
JFYI, when comparing v5.10[1] to v5.10-rc7[3], the summaries are:
- build errors: +0/-0
- build warnings: +2/-6
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/2c85ebc57b3e1817b6ce1a6b703928e113a90442/
(all 192 configs)
[2]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bbf5c979011a099af5dc76498918ed7df445635b/
(all 192 configs)
[3]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/0477e92881850d44910a7e94fc2c46f96faa131f/
(all 192 configs)
*** ERRORS ***
2 error regressions:
+ /kisskb/src/arch/powerpc/platforms/powermac/smp.c: error: implicit
declaration of function 'cleanup_cpu_mmu_context'
[-Werror=implicit-function-declaration]: => 914:2
+ {standard input}: Error: inappropriate arguments for opcode 'adc': => 170
7 error improvements:
- error: modpost: "devm_ioremap" [drivers/net/ethernet/xilinx/ll_temac.ko]
undefined!: N/A =>
- error: modpost: "devm_ioremap_resource"
[drivers/net/ethernet/xilinx/xilinx_emac.ko] undefined!: N/A =>
- error: modpost: "devm_of_iomap" [drivers/net/ethernet/xilinx/ll_temac.ko]
undefined!: N/A =>
- error: modpost: "devm_platform_ioremap_resource"
[drivers/iio/adc/adi-axi-adc.ko] undefined!: N/A =>
- error: modpost: "devm_platform_ioremap_resource" [drivers/ptp/ptp_ines.ko]
undefined!: N/A =>
- error: modpost: "devm_platform_ioremap_resource_byname"
[drivers/net/ethernet/xilinx/ll_temac.ko] undefined!: N/A =>
- error: modpost: "fw_arg3" [drivers/mtd/parsers/bcm63xxpart.ko] undefined!:
N/A =>
*** WARNINGS ***
21 warning regressions:
+ /kisskb/src/arch/nds32/kernel/setup.c: warning: unused variable 'region'
[-Wunused-variable]: => 247:26
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/navi10_ppt.c:
warning: (near initialization for 'nv12_metrics.CurrClock') [-Wmissing-braces]:
=> 2539:2
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/navi10_ppt.c:
warning: missing braces around initializer [-Wmissing-braces]: => 2539:2
+ /kisskb/src/drivers/media/pci/intel/ipu3/ipu3-cio2.h: warning: large
integer implicitly truncated to unsigned type [-Woverflow]: => 22:28
+ /kisskb/src/drivers/net/ethernet/chelsio/cxgb4/sge.c: warning: (near
initialization for 'buf[0]') [-Wmissing-braces]: => 910:9
+ /kisskb/src/drivers/net/ethernet/chelsio/cxgb4/sge.c: warning: missing
braces around initializer [-Wmissing-braces]: => 910:9
+ /kisskb/src/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.c:
warning: 'wait_for_states.constprop' uses dynamic stack allocation: => 441:1
+ /kisskb/src/drivers/net/ethernet/mscc/ocelot_vcap.c: warning: (near
initialization for 'etype.value') [-Wmissing-braces]: => 755:11
+ /kisskb/src/drivers/net/ethernet/mscc/ocelot_vcap.c: warning: missing
braces around initializer [-Wmissing-braces]: => 755:11
+ /kisskb/src/drivers/target/iscsi/cxgbit/cxgbit_target.c: warning:
'cxgbit_tx_datain_iso.isra.40' uses dynamic stack allocation: => 482:1
+ /kisskb/src/fs/btrfs/tree-checker.c: warning: (near initialization for
'ri.inode') [-Wmissing-braces]: => 1056:9
+ /kisskb/src/fs/btrfs/tree-checker.c: warning: missing braces around
initializer [-Wmissing-braces]: => 1056:9
+ /kisskb/src/kernel/bpf/cpumap.c: warning:
'cpu_map_bpf_prog_run_xdp.isra.14' uses dynamic stack allocation: => 295:1
+ /kisskb/src/kernel/rcu/tasks.h: warning: 'show_rcu_tasks_rude_gp_kthread'
defined but not used [-Wunused-function]: => 710:13
+ /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.60' uses dynamic
stack allocation: => 2295:1
+ /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.59' uses dynamic
stack allocation: => 1992:1
+ /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.58' uses dynamic
stack allocation: => 2363:1
+ arch/ia64/configs/generic_defconfig: warning: override: reassigning to
symbol ATA: => 58
+ arch/ia64/configs/generic_defconfig: warning: override: reassigning to
symbol ATA_PIIX: => 59
+ warning: 4 bad relocations: => N/A
+ warning: unmet direct dependencies detected for MFD_CORE: => N/A
30 warning improvements:
- /kisskb/src/arch/mips/include/asm/page.h: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]: 249:53 =>
- /kisskb/src/drivers/crypto/chelsio/chtls/chtls_cm.c: warning:
'wait_for_states.constprop' uses dynamic stack allocation: 435:1 =>
- /kisskb/src/drivers/crypto/sa2ul.c: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]: 1486:33 =>
- /kisskb/src/drivers/media/platform/fsl-viu.c: warning: "in_be32" redefined:
37 =>
- /kisskb/src/drivers/media/platform/fsl-viu.c: warning: "out_be32"
redefined: 36 =>
- /kisskb/src/drivers/misc/habanalabs/common/habanalabs_i
Re: [PATCH] drivers/perf: Enable PID_IN_CONTEXTIDR with SPE
On 02/12/2020 01:09, Will Deacon wrote: > On Tue, Dec 01, 2020 at 12:10:40PM +0800, Leo Yan wrote: >> On Mon, Nov 30, 2020 at 04:46:51PM +, Will Deacon wrote: >>> On Mon, Nov 30, 2020 at 06:24:54PM +0200, James Clark wrote: Enable PID_IN_CONTEXTIDR by default when Arm SPE is enabled. This flag is required to get PID data in the SPE trace. Without it the perf tool will report 0 for PID which isn't very useful, especially when doing system wide profiling or profiling applications that fork. >>> >>> Can perf not figure out the pid some other way? (e.g. by tracing context >>> switches and correlating that with the SPE data?). >> >> For perf 'per-thread' mode, we can use context switch trace event as >> assisted info to select thread context. But for "system wide" mode and >> "snapshot" mode in perf tool, since the trace data is continuous, I >> think we cannot use context switch trace event to correlate the SPE >> trace data. > > Is there no way to correlate them with something like CNTVCT? > >>> Also, how does this work with pid namespaces? >> >> Here we are studying the implemetation of Intel-PT and Arm CoreSight. >> >> The context ID is stored into the hardware trace data when record; >> afterwards when perf tool decodes the trace data and detects the >> packet for context ID, it will select the machine's thread context in >> perf [1]. Since the perf tool gathers all the threads infomation in >> perf data file, based on the context ID, it can find the corresponding >> thread pointer with function machine__find_thread() [2]. >> >> Since your question is for "pid namespace", to be honest, I don't know >> how perf tool to handle any confliction for differrent processes share >> the same PID, and I am not sure if you are asking CGroup related stuff >> or not. If this cannot answer your question, please let me know. > > My point was that the pid value written to CONTEXTIDR is a global pid > and does not take namespacing into account. If perf is run inside a pid > namespace, it will therefore not work. That's an interesting point, but I think we should improve this for the simple use case without namespaces first just to improve the user experience, so I've sent v2 of the patch with the change you suggested about using "default y". One other thing that is an issue that I'd like to ask about is this line in arm_spe_pmu.c: if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); This means that the user has to be root to get the context saved with SPE. Is this a necessary security feature? I thought that PIDs are viewable by all users anyway? Do you think there is any way we could remove the perfmon_capable() requirement? James
Re: [PATCH v5 3/7] media: videobuf2: Expose helpers to implement the _ext_fmt and _ext_buf hooks
Hi Helen,
On Tue, Aug 04, 2020 at 04:29:35PM -0300, Helen Koike wrote:
> The VB2 layer is used by a lot of drivers. Patch it to support the
> _EXT_PIX_FMT and _EXT_BUF ioctls in order to ease conversion of existing
> drivers to these new APIs.
>
> Note that internally, the VB2 core is now only using ext structs and old
> APIs are supported through conversion wrappers.
We decided to only support V4L2_BUF_TYPE_VIDEO* for the ext structs. Still,
existing drivers may use vb2 with the other, legacy, buf types. How would
they be handled with this change?
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Helen Koike
> ---
> Changes in v5:
> - Update with new format and buffer structs
> - Updated commit message with the uAPI prefix
>
> Changes in v4:
> - Update with new format and buffer structs
> - Fix some bugs caught by v4l2-compliance
> - Rebased on top of media/master (post 5.8-rc1)
>
> Changes in v3:
> - Rebased on top of media/master (post 5.4-rc1)
>
> Changes in v2:
> - New patch
> ---
> .../media/common/videobuf2/videobuf2-core.c | 2 +
> .../media/common/videobuf2/videobuf2-v4l2.c | 560 ++
> include/media/videobuf2-core.h| 6 +-
> include/media/videobuf2-v4l2.h| 21 +-
> 4 files changed, 345 insertions(+), 244 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index f544d3393e9d6..d719b1e9c148b 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -1270,6 +1270,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
> vb->planes[plane].length = 0;
> vb->planes[plane].m.fd = 0;
> vb->planes[plane].data_offset = 0;
> + vb->planes[plane].dbuf_offset = 0;
>
> /* Acquire each plane's memory */
> mem_priv = call_ptr_memop(vb, attach_dmabuf,
> @@ -1313,6 +1314,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
> vb->planes[plane].length = planes[plane].length;
> vb->planes[plane].m.fd = planes[plane].m.fd;
> vb->planes[plane].data_offset = planes[plane].data_offset;
> + vb->planes[plane].dbuf_offset = planes[plane].dbuf_offset;
> }
>
> if (reacquired) {
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 30caad27281e1..911681d24b3ae 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -56,72 +57,39 @@ module_param(debug, int, 0644);
>V4L2_BUF_FLAG_TIMECODE | \
>V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF)
>
> -/*
> - * __verify_planes_array() - verify that the planes array passed in struct
> - * v4l2_buffer from userspace can be safely used
> - */
> -static int __verify_planes_array(struct vb2_buffer *vb, const struct
> v4l2_buffer *b)
> -{
> - if (!V4L2_TYPE_IS_MULTIPLANAR(b->type))
> - return 0;
> -
> - /* Is memory for copying plane information present? */
> - if (b->m.planes == NULL) {
> - dprintk(vb->vb2_queue, 1,
> - "multi-planar buffer passed but planes array not
> provided\n");
> - return -EINVAL;
> - }
> -
> - if (b->length < vb->num_planes || b->length > VB2_MAX_PLANES) {
> - dprintk(vb->vb2_queue, 1,
> - "incorrect planes array length, expected %d, got %d\n",
> - vb->num_planes, b->length);
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> static int __verify_planes_array_core(struct vb2_buffer *vb, const void *pb)
> {
> - return __verify_planes_array(vb, pb);
> + return 0;
> }
>
> /*
> * __verify_length() - Verify that the bytesused value for each plane fits in
> * the plane length and that the data offset doesn't exceed the bytesused
> value.
> */
> -static int __verify_length(struct vb2_buffer *vb, const struct v4l2_buffer
> *b)
> +static int __verify_length(struct vb2_buffer *vb,
> +const struct v4l2_ext_buffer *b)
> {
> unsigned int length;
> unsigned int bytesused;
> - unsigned int plane;
> + unsigned int i;
>
> if (V4L2_TYPE_IS_CAPTURE(b->type))
> return 0;
>
> - if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
> - for (plane = 0; plane < vb->num_planes; ++plane) {
> - length = (b->memory == VB2_MEMORY_USERPTR ||
> - b->memory == VB2_MEMORY_DMABUF)
> -? b->m.planes[plane].length
> - : vb->planes[plane].length;
> - bytesused = b->m.planes[plane].bytesused
> -
Re: [PATCH] jump_label: Do not profile branch annotations
On Fri, Dec 11, 2020 at 04:37:54PM -0500, Steven Rostedt wrote: > From: Steven Rostedt (VMware) > > While running my branch profiler that checks for incorrect "likely" and > "unlikely"s around the kernel, there's a large number of them that are > incorrect due to being "static_branches". > > As static_branches are rather special, as they are likely or unlikely for > other reasons than normal annotations are used for, there's no reason to > have them be profiled. > > Expose the "unlikely_notrace" and "likely_notrace" so that the > static_branch can use them, and have them be ignored by the branch > profilers. The less that abomination does the better ;-), I'll take it through tip then?
Re: [PATCH bpf-next] xsk: save the undone skb
On Sat, Dec 12, 2020 at 9:47 AM Xuan Zhuo wrote:
>
> On Fri, 11 Dec 2020 16:32:06 +0100, Magnus Karlsson
> wrote:
> > On Fri, Dec 11, 2020 at 2:12 PM Xuan Zhuo
> > wrote:
> > >
> > > We can reserve the skb. When sending fails, NETDEV_TX_BUSY or
> > > xskq_prod_reserve fails. As long as skb is successfully generated and
> > > successfully configured, we can reserve skb if we encounter exceptions
> > > later.
> > >
> > > Especially when NETDEV_TX_BUSY fails, there is no need to deal with
> > > the problem that xskq_prod_reserve has been updated.
> > >
> > > Signed-off-by: Xuan Zhuo
> > > ---
> > > include/net/xdp_sock.h | 3 +++
> > > net/xdp/xsk.c | 36 +++-
> > > 2 files changed, 30 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
> > > index 4f4e93b..fead0c9 100644
> > > --- a/include/net/xdp_sock.h
> > > +++ b/include/net/xdp_sock.h
> > > @@ -76,6 +76,9 @@ struct xdp_sock {
> > > struct mutex mutex;
> > > struct xsk_queue *fq_tmp; /* Only as tmp storage before bind */
> > > struct xsk_queue *cq_tmp; /* Only as tmp storage before bind */
> > > +
> > > + struct sk_buff *skb_undone;
> > > + bool skb_undone_reserve;
> > > };
> > >
> > > #ifdef CONFIG_XDP_SOCKETS
> > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > index e28c682..1051024 100644
> > > --- a/net/xdp/xsk.c
> > > +++ b/net/xdp/xsk.c
> > > @@ -435,6 +435,19 @@ static int xsk_generic_xmit(struct sock *sk)
> > > if (xs->queue_id >= xs->dev->real_num_tx_queues)
> > > goto out;
> > >
> > > + if (xs->skb_undone) {
> > > + if (xs->skb_undone_reserve) {
> > > + if (xskq_prod_reserve(xs->pool->cq))
> > > + goto out;
> > > +
> > > + xs->skb_undone_reserve = false;
> > > + }
> > > +
> > > + skb = xs->skb_undone;
> > > + xs->skb_undone = NULL;
> > > + goto xmit;
> > > + }
> > > +
> > > while (xskq_cons_peek_desc(xs->tx, &desc, xs->pool)) {
> > > char *buffer;
> > > u64 addr;
> > > @@ -454,12 +467,7 @@ static int xsk_generic_xmit(struct sock *sk)
> > > addr = desc.addr;
> > > buffer = xsk_buff_raw_get_data(xs->pool, addr);
> > > err = skb_store_bits(skb, 0, buffer, len);
> > > - /* This is the backpressure mechanism for the Tx path.
> > > -* Reserve space in the completion queue and only proceed
> > > -* if there is space in it. This avoids having to
> > > implement
> > > -* any buffering in the Tx path.
> > > -*/
> > > - if (unlikely(err) || xskq_prod_reserve(xs->pool->cq)) {
> > > + if (unlikely(err)) {
> > > kfree_skb(skb);
> > > goto out;
> > > }
> > > @@ -470,12 +478,22 @@ static int xsk_generic_xmit(struct sock *sk)
> > > skb_shinfo(skb)->destructor_arg = (void *)(long)desc.addr;
> > > skb->destructor = xsk_destruct_skb;
> > >
> > > + /* This is the backpressure mechanism for the Tx path.
> > > +* Reserve space in the completion queue and only proceed
> > > +* if there is space in it. This avoids having to
> > > implement
> > > +* any buffering in the Tx path.
> > > +*/
> > > + if (xskq_prod_reserve(xs->pool->cq)) {
> > > + xs->skb_undone_reserve = true;
> > > + xs->skb_undone = skb;
> > > + goto out;
> > > + }
> > > +
> > > +xmit:
> >
> > This will not work in the general case since we cannot guarantee that
> > the application does not replace the packet in the Tx ring before it
> > calls send() again. This is fully legal. I also do not like to
> > introduce state between calls. Much simpler to have it stateless which
> > means less error prone.
> >
> > On the positive side, I will submit a patch that improves performance
> > of this transmit function by using the new batch interfaces I
> > introduced a month ago. With this patch I get a throughput improvement
> > of between 15 and 25% for the txpush benchmark in xdpsock. This is
> > much more than you will get from this patch. It also avoids the
> > problem you are addressing here completely. I will submit the patch
> > next week after the bug fix in this code has trickled down to
> > bpf-next. Hope you will like the throughput improvement that it
> > provides.
>
> In fact, we can also call xskq_cons_release before save the undone skb and
> exiting this function, so do not worry about the users modifying the data
> in tx. Of course, I understand that you want to have it stateless.
> I agree with this. I will give up this idea tem
Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support
On Sat, Dec 12, 2020 at 01:03:32AM +0100, Linus Walleij wrote: > On Thu, Dec 10, 2020 at 9:53 AM Johan Hovold wrote: > > On Wed, Dec 09, 2020 at 05:25:32PM +0100, Linus Walleij wrote: > > > I just replied to that thread, but to summarize, you can't rely on > > having the sysfs code detect collisions since that will trigger a bunch > > of nasty warnings and backtraces. We also don't want the sysfs interface > > for a specific USB device to depend on probe order (only the first one > > plugged in gets to use the line names). And adding line names now could > > in fact be what breaks currently working scripts. > > Yes the sysfs ABI is very volatile and easy to break. > > As pointed out in the other reply, sysfs base GPIO number is all > wibbly-wobbly on anything hot-pluggable so in a way I feel it > is the right thing to disallow sysfs altogether on hotpluggable > devices. No, the gpio numbers will of course vary, but since gpiolib exports the base number for the chip, a scripts can easily determine the right gpio number as base + offset. Having probe order break that by sometimes exporting the line using it's name is what would be a problem. > > Just did a super quick check and it seems libgpiod still assumes a flat > > name space. For example, gpiod_chip_find_line() returns only the first > > line found that matches a name. Shouldn't be impossible to extend, but > > just want to make sure this flat namespace assumption hasn't been to > > heavily relied upon. > > The unique way to identify a GPIO is gpiochip instance (with > topology from sysfs) and then a line number on that chip. > This is done e.g. in the example tool > tools/gpio/gpio-hammer.c > > As you can see the tool doesn't use these line names. > > The line names are really like symbolic links or something. > But they are indeed in a flat namespace so we should try to > at least make them unique if it turns out people love to use > these. Not necessarily, they could be unique per chip as we're discussing here with respect to hotpluggable controllers. We just can't have it both ways. > As it is now system designers mostly use device tree to assign > line names and they try to make these unique because they don't > like the nasty warnings from gpiolib. > > If I google for the phrase "Detected name collision for GPIO name" > I just find the code, our discussions and some USB serial devices > warning about this so far. > > Maybe we should just make a patch to disallow it? That would make it impossible to provide name lines on hotpluggable controllers, which would be nice to support. Johan
Re: [PATCH v2 1/2] kconfig.h: Add IF_ENABLED() macro
On Mon, Dec 14, 2020 at 12:54 AM Paul Cercueil wrote: > IF_ENABLED(CONFIG_FOO, ptr) evaluates to (ptr) if CONFIG_FOO is set to 'y' > or 'm', NULL otherwise. The (ptr) argument must be a pointer. > > The IF_ENABLED() macro can be very useful to help GCC drop dead code. I can apply this with the other patch to the pinctrl subsystem if Arnd or someone else who is good at KConfig provides an ACK. Yours, Linus Walleij
Re: [PATCH] gpio: sysfs: Try numbered exports if symbolic names fail
On Sat, Dec 12, 2020 at 12:41:50AM +0100, Linus Walleij wrote: > On Thu, Dec 10, 2020 at 9:33 AM Johan Hovold wrote: > > > I suggested having the driver set a flag which determines whether to use > > the line names in sysfs or not. > > Aha I get it. > > I need to think about if I can fix that in some good way. > > > The above will trigger a bunch of nasty warnings and backtraces in the > > sysfs code (for every gpio line!), which is not something we want for > > normal operation. > > At this point I feel any use of sysfs kind of deserves that but OK > it's a bit nasty. It would be a bug in gpiolib as the warnings are due to collisions when trying to register two sysfs files using the same path. > > Having the sysfs interface for the same USB device > > depend on probe order is not very nice either. > > The sysfs for a USB device is already very dependent on probe order. > Since all dynamic gpio_chips pass -1 as base they will be allocated > some global GPIO numbers at random (well, semi-random) > depending on probe order. > > The user will not have any idea whatsoever what to echo into the sysfs > export file without inspecting other things such as debugfs. > That's how unstable this interface is, and one of the reasons we > are trying to get rid of the global GPIO numberspace to begin with... That's not true. The gpiochip has a "base" sysfs attribute from which any user can construct the gpio number by simply adding an offset. Having the lines sometimes show up using their names and sometimes using this number, is what would be a problem. > Maybe that is actually an argument for any multi-instance GPIO > devices to > depends on !GPIO_SYSFS No, not at all. Just suppress the rename of the sysfs directories based on line names, which was a bad idea from the start (the names should have been exported through a separate name attribute). Johan
linux-next: build warnings after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (htmldocs)
produced these warnings:
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:1759: warning: Cannot understand * @struct
cfg80211_sar_chan_ranges - sar frequency ranges
on line 1759 - I thought it was a doc line
include/net/cfg80211.h:5073: warning: Function parameter or member 'sar_capa'
not described in 'wiphy'
Introduced by commit
6bdb68cef7bf ("nl80211: add common API to configure SAR power limitations")
--
Cheers,
Stephen Rothwell
pgpzx0wogJ9a_.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 2/3] MAINTAINERS: Add maintainer for HiSilicon GPIO driver
On Mon, Dec 14, 2020 at 9:24 AM Luo Jiaxing wrote: > Here add maintainer information for HiSilicon GPIO driver. > > Signed-off-by: Luo Jiaxing Patch applied! Yours, Linus Walleij
Re: [PATCH v2 1/3] gpio: gpio-hisi: Add HiSilicon GPIO support
On Mon, Dec 14, 2020 at 9:24 AM Luo Jiaxing wrote: > This GPIO driver is for HiSilicon's ARM SoC. Patch applied, any further issues can certainly be fixed in-tree. Thanks for your excellent work on this driver! Yours, Linus Walleij
Re: [PATCH v2 3/3] arm64: defconfig: enable GPIO_HISI
On Mon, Dec 14, 2020 at 9:24 AM Luo Jiaxing wrote: > Enable GPIO controller for HiSilicon's ARM SoC. > > GPIO is common driver for HiSilicon's ARM SoC and it provide support for > some function of I2C and SPI. > > Signed-off-by: Luo Jiaxing Looks good, take this through the SoC tree with other platform support. Yours, Linus Walleij
memory leak in dlfb_usb_probe
Hello, syzbot found the following issue on: HEAD commit:a68a0262 mm/madvise: remove racy mm ownership check git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1538046b50 kernel config: https://syzkaller.appspot.com/x/.config?x=4305fa9ea70c7a9f dashboard link: https://syzkaller.appspot.com/bug?extid=c9e365d7f450e8aa615d compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1779cc1350 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1173d00f50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c9e365d7f450e8aa6...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x88810adde100 (size 32): comm "kworker/1:0", pid 17, jiffies 4294947788 (age 19.520s) hex dump (first 32 bytes): 10 30 c3 0d 81 88 ff ff c0 fa 63 12 81 88 ff ff .0c. 00 30 c3 0d 81 88 ff ff 80 d1 3a 08 81 88 ff ff .0:. backtrace: [<19512953>] kmalloc include/linux/slab.h:552 [inline] [<19512953>] kzalloc include/linux/slab.h:664 [inline] [<19512953>] dlfb_alloc_urb_list drivers/video/fbdev/udlfb.c:1892 [inline] [<19512953>] dlfb_usb_probe.cold+0x289/0x988 drivers/video/fbdev/udlfb.c:1704 [<72160152>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] really_probe+0x159/0x480 drivers/base/dd.c:554 [ ] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [ ] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<463fbcb4>] __device_attach+0x122/0x250 drivers/base/dd.c:912 [ ] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<364bbda5>] device_add+0x5ac/0xc30 drivers/base/core.c:2936 [ ] usb_set_configuration+0x9de/0xb90 drivers/usb/core/message.c:2159 [ ] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<1830872b>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [ ] really_probe+0x159/0x480 drivers/base/dd.c:554 [ ] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [ ] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 BUG: memory leak unreferenced object 0x8881083ad180 (size 192): comm "kworker/1:0", pid 17, jiffies 4294947788 (age 19.520s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 d1 3a 08 81 88 ff ff ..:. backtrace: [ ] kmalloc include/linux/slab.h:557 [inline] [ ] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<82822843>] dlfb_alloc_urb_list drivers/video/fbdev/udlfb.c:1897 [inline] [<82822843>] dlfb_usb_probe.cold+0x2aa/0x988 drivers/video/fbdev/udlfb.c:1704 [<72160152>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [ ] really_probe+0x159/0x480 drivers/base/dd.c:554 [ ] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [ ] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<463fbcb4>] __device_attach+0x122/0x250 drivers/base/dd.c:912 [ ] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<364bbda5>] device_add+0x5ac/0xc30 drivers/base/core.c:2936 [ ] usb_set_configuration+0x9de/0xb90 drivers/usb/core/message.c:2159 [ ] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<1830872b>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [ ] really_probe+0x159/0x480 drivers/base/dd.c:554 [ ] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 BUG: memory leak unreferenced object 0x88811263fb20 (size 32): comm "kworker/1:0", pid 17, jiffies 4294947788 (age 19.530s) hex dump (first 32 bytes): 00 fb 63 12 81 88 ff ff 10 30 c3 0d 81 88 ff ff ..c..0.. 00 30 c3 0d 81 88 ff ff c0 53 c8 0b 81 88 ff ff .0...S.. backtrace: [<19512953>] kmalloc include/linux/slab.h:552 [inline] [<19512953>] kzalloc include/linux/slab.h:664 [inline] [<19512953>] dlfb_alloc_urb_list drivers/video/fbdev/udlfb.c:1892 [inline] [<19512953>] dlfb_usb_probe.cold+0x289/0x988 drivers/video/fbdev/udlfb.c:1704 [<72160152>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<0
Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check
On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas wrote: > > [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM > issue with I211 or Realtek NICs. Beginning of thread: > https://lore.kernel.org/r/20201024205548.1837770-1-ian.kuml...@gmail.com > > Short story: Ian has: > > Root Port --- Switch --- I211 NIC >\-- multifunction Realtek NIC, etc > > and the I211 performance is poor with ASPM L1 enabled on both links > in the path to it. The patch here disables ASPM on the upstream link > and fixes the performance, but AFAICT the devices in that path give us > no reason to disable L1. If I understand the spec correctly, the > Realtek device should not be relevant to the I211 path.] > > On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote: > > On Sun, Dec 13, 2020 at 12:47 AM Bjorn Helgaas wrote: > > > On Sat, Oct 24, 2020 at 10:55:46PM +0200, Ian Kumlien wrote: > > > > Make pcie_aspm_check_latency comply with the PCIe spec, specifically: > > > > "5.4.1.2.2. Exit from the L1 State" > > > > > > > > Which makes it clear that each switch is required to initiate a > > > > transition within 1μs from receiving it, accumulating this latency and > > > > then we have to wait for the slowest link along the path before > > > > entering L0 state from L1. > > > > ... > > > > > > > On my specific system: > > > > 03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network > > > > Connection (rev 03) > > > > 04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device > > > > 816e (rev 1a) > > > > > > > > Exit latency Acceptable latency > > > > Tree: L1 L0s L1 L0s > > > > -- --- - --- -- > > > > 00:01.2 <32 us - > > > > | 01:00.0 <32 us - > > > > |- 02:03.0 <32 us - > > > > | \03:00.0 <16 us <2us <64 us <512ns > > > > | > > > > \- 02:04.0 <32 us - > > > > \04:00.0 <64 us unlimited <64 us <512ns > > > > > > > > 04:00.0's latency is the same as the maximum it allows so as we walk > > > > the path > > > > the first switchs startup latency will pass the acceptable latency limit > > > > for the link, and as a side-effect it fixes my issues with 03:00.0. > > > > > > > > Without this patch, 03:00.0 misbehaves and only gives me ~40 mbit/s over > > > > links with 6 or more hops. With this patch I'm back to a maximum of ~933 > > > > mbit/s. > > > > > > There are two paths here that share a Link: > > > > > > 00:01.2 --- 01:00.0 -- 02:03.0 --- 03:00.0 I211 NIC > > > 00:01.2 --- 01:00.0 -- 02:04.0 --- 04:00.x multifunction Realtek > > > > > > 1) The path to the I211 NIC includes four Ports and two Links (the > > >connection between 01:00.0 and 02:03.0 is internal Switch routing, > > >not a Link). > > > > >The Ports advertise L1 exit latencies of <32us, <32us, <32us, > > ><16us. If both Links are in L1 and 03:00.0 initiates L1 exit at T, > > >01:00.0 initiates L1 exit at T + 1. A TLP from 03:00.0 may see up > > >to 1 + 32 = 33us of L1 exit latency. > > > > > >The NIC can tolerate up to 64us of L1 exit latency, so it is safe > > >to enable L1 for both Links. > > > > > > 2) The path to the Realtek device is similar except that the Realtek > > >L1 exit latency is <64us. If both Links are in L1 and 04:00.x > > >initiates L1 exit at T, 01:00.0 again initiates L1 exit at T + 1, > > >but a TLP from 04:00.x may see up to 1 + 64 = 65us of L1 exit > > >latency. > > > > > >The Realtek device can only tolerate 64us of latency, so it is not > > >safe to enable L1 for both Links. It should be safe to enable L1 > > >on the shared link because the exit latency for that link would be > > ><32us. > > > > 04:00.0: > > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us > > LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s > > unlimited, L1 <64us > > > > So maximum latency for the entire link has to be <64 us > > For the device to leave L1 ASPM takes <64us > > > > So the device itself is the slowest entry along the link, which > > means that nothing else along that path can have ASPM enabled > > Yes. That's what I said above: "it is not safe to enable L1 for both > Links." Unless I'm missing something, we agree on that. > > I also said that it should be safe to enable L1 on the shared Link > (from 00:01.2 to 01:00.0) because if the downstream Link is always in > L0, the exit latency of the shared Link should be <32us, and 04:00.x > can tolerate 64us. Exit latency of shared link would be max of link, ie 64 + L1-hops, not 32 > > > > The original code path did: > > > > 04:00:0-02:04.0 max latency 64-> ok > > > > 02:04.0-01:00.0 max latency 32 +1 -> ok > > > > 01:00.0-00:01.2 max latency 32 +2 -> ok > > > > > > > > And thus didn't see any L1 ASPM latency issues. > > > > > > > > The new code does: > > > > 04:00:0-02:04.0 max latency 64-> ok > > > > 02:04.0-01:00.0 max
[PATCH 03/25] dt-bindings: net: dwmac: Fix the TSO property declaration
Indeed the STMMAC driver doesn't take the vendor-specific compatible string into account to parse the "snps,tso" boolean property. It just makes sure the node is compatible with DW MAC 4.x, 5.x and DW xGMAC IP-cores. Fix the conditional statement so the TSO-property would be evaluated for the compatibles having the corresponding IP-core version. While at it move the whole allOf-block from the tail of the binding file to the head of it, as it's normally done in the most of the DT schemas. Signed-off-by: Serge Semin --- Note this won't break the bindings description, since the "snps,tso" property isn't parsed by the Allwinner SunX GMAC glue driver, but only by the generic platform DT-parser. --- .../devicetree/bindings/net/snps,dwmac.yaml | 52 +-- 1 file changed, 24 insertions(+), 28 deletions(-) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index e084fbbf976e..0dd543c6c08e 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -37,6 +37,30 @@ select: required: - compatible +allOf: + - $ref: "ethernet-controller.yaml#" + - if: + properties: +compatible: + contains: +enum: + - snps,dwmac-4.00 + - snps,dwmac-4.10a + - snps,dwmac-4.20a + - snps,dwmac-5.10a + - snps,dwxgmac + - snps,dwxgmac-2.10 + + required: +- compatible +then: + properties: +snps,tso: + $ref: /schemas/types.yaml#definitions/flag + description: +Enables the TSO feature otherwise it will be managed by +MAC HW capability register. + properties: # We need to include all the compatibles from schemas that will @@ -314,34 +338,6 @@ dependencies: snps,reset-active-low: ["snps,reset-gpio"] snps,reset-delay-us: ["snps,reset-gpio"] -allOf: - - $ref: "ethernet-controller.yaml#" - - if: - properties: -compatible: - contains: -enum: - - allwinner,sun7i-a20-gmac - - allwinner,sun8i-a83t-emac - - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac - - allwinner,sun8i-v3s-emac - - allwinner,sun50i-a64-emac - - snps,dwmac-4.00 - - snps,dwmac-4.10a - - snps,dwmac-4.20a - - snps,dwxgmac - - snps,dwxgmac-2.10 - - st,spear600-gmac - -then: - properties: -snps,tso: - $ref: /schemas/types.yaml#definitions/flag - description: -Enables the TSO feature otherwise it will be managed by -MAC HW capability register. - additionalProperties: true examples: -- 2.29.2
[PATCH 02/25] dt-bindings: net: dwmac: Extend number of PBL values
In accordance with [1] the permitted PBL values can be set as one of [1, 2, 4, 8, 16, 32]. The rest of the values results in undefined behavior. At the same time some of the permitted values can be also invalid depending on the controller FIFOs size and the data bus width. Seeing due to having too many variables all the possible PBL property constraints can't be implemented in the bindings schema, let's extend the set of permitted PBL values to be as much as the configuration register supports leaving the undefined behaviour cases for developers to handle. [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, October 2013, p. 380. Signed-off-by: Serge Semin --- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 4b672499f20d..e084fbbf976e 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -264,23 +264,26 @@ properties: snps,pbl: description: - Programmable Burst Length (tx and rx) + Programmable Burst Length (tx and rx). Note some of these values + can be still invalid due to HW limitations connected with the data + bus width and the FIFOs depth, so a total length of a single DMA + burst shouldn't exceed half the FIFO depth. $ref: /schemas/types.yaml#definitions/uint32 -enum: [2, 4, 8] +enum: [1, 2, 4, 8, 16, 32] snps,txpbl: description: Tx Programmable Burst Length. If set, DMA tx will use this value rather than snps,pbl. $ref: /schemas/types.yaml#definitions/uint32 -enum: [2, 4, 8] +enum: [1, 2, 4, 8, 16, 32] snps,rxpbl: description: Rx Programmable Burst Length. If set, DMA rx will use this value rather than snps,pbl. $ref: /schemas/types.yaml#definitions/uint32 -enum: [2, 4, 8] +enum: [1, 2, 4, 8, 16, 32] snps,no-pbl-x8: $ref: /schemas/types.yaml#definitions/flag -- 2.29.2
[PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties
Currently the "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" properties are declared as a single phandle reference
to a node with corresponding parameters defined. That's not good for
several reasons. First of all scattering around a device tree some
particular device-specific configs with no visual relation to that device
isn't suitable from maintainability point of view. That leads to a
disturbed representation of the actual device tree mixing actual device
nodes and some vendor-specific configs. Secondly using the same configs
set for several device nodes doesn't represent well the devices structure,
since the interfaces these configs describe in hardware belong to
different devices and may actually differ. In the later case having the
configs node separated from the corresponding device nodes gets to be
even unjustified.
So instead of having a separate DW *MAC configs nodes we suggest to
define them as sub-nodes of the device nodes, which interfaces they
actually describe. By doing so we'll make the DW *MAC nodes visually
correct describing all the aspects of the IP-core configuration. Thus
we'll be able to describe the configs sub-nodes bindings right in the
snps,dwmac.yaml file.
Note the former "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" bindings have been marked as deprecated.
Signed-off-by: Serge Semin
---
Note the current DT schema tool requires the vendor-specific properties to be
defined in accordance with the schema: dtschema/meta-schemas/vendor-props.yaml
It means the property can be;
- boolean,
- string,
- defined with $ref and additional constraints,
- defined with allOf: [ $ref ] and additional constraints.
The modification provided by this commit needs to extend that definition to
make the DT schema tool correctly parse this schema. That is we need to let
the vendors-specific properties to also accept the oneOf-based combined
sub-schema. Like this:
--- a/dtschema/meta-schemas/vendor-props.yaml
+++ b/dtschema/meta-schemas/vendor-props.yaml
@@ -48,15 +48,24 @@
- properties: # A property with a type and additional constraints
$ref:
pattern: "types.yaml#[\/]{0,1}definitions\/.*"
- allOf:
-items:
- - properties:
+
+if:
+ not:
+required:
+ - $ref
+then:
+ patternProperties:
+"^(all|one)Of$":
+ contains:
+properties:
$ref:
pattern: "types.yaml#[\/]{0,1}definitions\/.*"
required:
- $ref
-oneOf:
+
+anyOf:
- required: [ $ref ]
- required: [ allOf ]
+ - required: [ oneOf ]
...
---
.../devicetree/bindings/net/snps,dwmac.yaml | 380 +-
1 file changed, 288 insertions(+), 92 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 0dd543c6c08e..44aa88151cba 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -150,69 +150,251 @@ properties:
in a different mode than the PHY in order to function.
snps,axi-config:
-$ref: /schemas/types.yaml#definitions/phandle
-description:
- AXI BUS Mode parameters. Phandle to a node that can contain the
- following properties
-* snps,lpi_en, enable Low Power Interface
-* snps,xit_frm, unlock on WoL
-* snps,wr_osr_lmt, max write outstanding req. limit
-* snps,rd_osr_lmt, max read outstanding req. limit
-* snps,kbbe, do not cross 1KiB boundary.
-* snps,blen, this is a vector of supported burst length.
-* snps,fb, fixed-burst
-* snps,mb, mixed-burst
-* snps,rb, rebuild INCRx Burst
+description: AXI BUS Mode parameters
+oneOf:
+ - deprecated: true
+$ref: /schemas/types.yaml#definitions/phandle
+ - type: object
+properties:
+ snps,lpi_en:
+$ref: /schemas/types.yaml#definitions/flag
+description: Enable Low Power Interface
+
+ snps,xit_frm:
+$ref: /schemas/types.yaml#definitions/flag
+description: Unlock on WoL
+
+ snps,wr_osr_lmt:
+$ref: /schemas/types.yaml#definitions/uint32
+description: Max write outstanding req. limit
+default: 1
+minimum: 0
+maximum: 15
+
+ snps,rd_osr_lmt:
+$ref: /schemas/types.yaml#definitions/uint32
+description: Max read outstanding req. limit
+default: 1
+minimum: 0
+maximum: 15
+
+ snps,kbbe:
+$ref: /schemas/types.yaml#definitions/flag
+description: Do not cross 1KiB boundary
+
+ snps,blen:
+$ref: /schemas/types.yaml#definitions/uint32-array
+
[PATCH 00/25] net: stmmac: Fix clocks/reset-related procedures
Baikal-T1 SoC is equipped with two Synopsys DesignWare GMAC v3.73a-based
ethernet interfaces with no internal Ethernet PHY attached. The IP-cores
are configured as GMAC-AXI with CSR interface clocked by a dedicated
signal. Each of which has got Rx/Tx FIFOs of 16KB, up to 8 MAC addresses
capability, no embedded filter hash table logic, EEE enabled, IEEE 1588
and 1588-2008 Advanced timestamping capabilities, power management with
remote wake-up, IP CSUM hardware acceleration, a single PHY interface -
RGMII with MDIO bus, 1xGPI and 1xGPO.
This is a very first series of patches with fixes we've found to be
required in order to make things working well for our setup. The series
has turned to be rather large, but most of the patches are trivial and
some of them are just cleanups, so it shouldn't be that hard to review.
The series starts with fixes of the PBL (Programmable DMA Burst length)
DT-property, which is supposed to be defined for each DW *MAC IP-core, but
not only for a Allwinner sun* GMAC and DW xGMAC. The number of possible
PBL values need to be also extended in accordance with the DW *MAC manual.
Then the TSO flag property should be also declared free of the
vendor-specific conditional schema, because the driver expects the
compatible string to have the IP-core version specified anyway and none of
the glue-drivers refer to the property directly.
Then we suggest to refactor the "snps,{axi,mtl-rx,mtl-tx}-config"
properties/nodes declaration, so the configs would be able to be defined
as the sub-nodes of the DW *MAC DT nodes. The reason is that the DW MAC
DT-schema doesn't validate them at the moment and having them defined as
separate from the DW MAC nodes isn't descriptive at all. (Please note the
patch log, since the DT-schema tool needs to be fixed in order to make the
change working).
Another big modification of the DW *MAC bindings file is the generic
DT-properties and generic DT-nodes schema splitting up. So in order to
improve the DW *MAC bindings maintainability we suggest to leave the
generic DW *MAC properties definition in the "snps,dwmac.yaml" file and
move the bindings for the generic DW *MAC DT-nodes validation in the
dedicated DT-schema "snps,dwmac-generic.yaml".
Another concern has been related with the System/CSR clocks. We have
discovered that currently the "stmmaceth" clocks are considered by the
driver as the combined system+CSR clocks, while in fact CSR interface can
be equipped with a dedicated clock source (this is our case). If so then
the clock with "pclk" can be used to define the later one. But neither
bindings are descriptive enough nor the DW *MAC driver is fixed to support
that feature. So first we suggest to elaborate stmmaceth/pclk description
in the bindings file and then fix the MDIO-bus clock selection procedure
so pclk would be used there if specified. The DW QoS Eth MAC driver is
also fixed in accordance with that modification.
The biggest part of the series concerns adding the generic Tx/Rx clocks
support to the DT-schema and to the DW MAC drivers and with fixed related
to that. It is really a good decision to add the generic Tx/Rx clocks,
because a lot of the glue-drivers expect them to be specified in the
DT-node. So first we add the "tx"/"rx" clocks declaration in the generic
DW MAC DT-schema. Then the glue-drivers like
dwmac-rk/dwmac-sti/dwmac-stm32 remove() callbacks need to be fixed to call
stmmac_remove_config_dt() otherwise the resources allocated in the
stmmac_probe_config_dt() won't be freed on the device removal. A small
modification needs to be provided for the cleanup-on-failure path of the
stmmac_probe_config_dt() method in order to improve its maintainability.
Then we've discovered that the "stmmaceth" and "pclk" clocks while being
acquired and enabled in the stmmac_probe_config_dt() method are disabled
in the stmmac_dvr_remove() function, which is erroneous for every
cleanup-on-failure path of the glue-driver probe methods. Finally before
adding the Tx/Rx clocks support we provide a set of optimizations of the
"stmmaceth"/"pclk"/"ptp_clk" clocks and the "stmmaceth" reset procedures
by removing the manual optional resources acquisition/enable/disable
implementation with the one provided by the corresponding subsystems.
Since the generic Tx/Rx clocks have been added we can freely remove the
similar clocks handling from the glue-drivers.
(Please note I have also discovered, but didn't try to fix the Allwinner
Sun8i cleanup-on-failure path implemented in the DW MAC probe() procedure.
It has been broken since don't know what time and it's a bit too
complicated to be fixed with no hardware at hands.)
That's it for now. The next series will concern the GPIOs support and
Baikal-T1 SoC specific bindings.
Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev
leaks")
Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst
to platform structure")
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Pavel
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
Hello, Il giorno dom 13 dic 2020 alle ore 15:22 Manivannan Sadhasivam ha scritto: > > On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote: > > On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote: > > > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same > > > level) > > > > > > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI. > > > > Why do we need a different QMI-over-X for every X? If you say there > > are already chardev interfaces to configure WWAN why not provide one > > of those? > > > > Just because the underlying PHY is different and it offers more services than > just configuring the modem (downloading crash dump, firmware download etc...) > > The existing chardev nodes are closely tied to the physical interfaces. For > instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really > can't > reuse it for MHI/PCIe. > let me also add that the current MHI UCI approach makes sense because it makes the switch USB -> PCIe smooth, since all the current open-source userspace tools (e.g. libqmi and qmicli), according to my testing until now, properly works without any need for a change, behaving the UCI QMI char device like cdc-wdm. While a different solution (which one?) would maybe cause to re-think the userspace side for having the same high-level behavior. Thanks, Daniele > > > It's not networking data plane. It's WWAN device configuration. > > > > Ack. Not that network config doesn't fall under networking, but eh. > > I wonder - did DaveM ever ack this, or was it just out of his sight > > enough, behind the cdev, to never trigger a nack? > > > > > There are no current kernel APIs for this, and I really don't think we > > > want there to be. The API surface is *huge* and we definitely don't > > > want that in-kernel. > > > > It is what it is today for WWAN. I don't think anyone in the > > development community or among users is particularly happy about > > the situation. Which makes it rather self evident why there is > > so much apprehension about this patch set. It's going to be > > a user space channel for everything Qualcomm - AI accelerator etc. > > Widening the WWAN status quo to more device types. > > Well not everything Qualcomm but for just the subsystems where there is no > standardization right now. I think we went too far ahead for standardizing > the modems. > > Thanks, > Mani >
[PATCH 11/25] net: stmmac: dwmac-stm32: Cleanup STMMAC DT-config in remove cb
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.
Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev
leaks")
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 5d4df4c5254e..b45aab38c7b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -426,6 +426,8 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+ stmmac_remove_config_dt(pdev, priv->plat);
+
if (dwmac->irq_pwr_wakeup >= 0) {
dev_pm_clear_wake_irq(&pdev->dev);
device_init_wakeup(&pdev->dev, false);
--
2.29.2
[PATCH 07/25] dt-bindings: net: dwmac: Detach Generic DW MAC bindings
Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes
describing generic DW MAC devices and as DT schema with common properties
to be evaluated against a vendor-specific DW MAC IP-cores. Due to such
dual-purpose design the "compatible" property of the common DW MAC schema
needs to contain the vendor-specific strings to successfully pass the
schema evaluation in case if it's referenced from the vendor-specific DT
bindings. That's a bad design from maintainability point of view, since
adding/removing any DW MAC-based device bindings requires the common
schema modification. In order to fix that let's detach the schema which
provides the generic DW MAC DT nodes evaluation into a dedicated DT
bindings file preserving the common DW MAC properties declaration in the
snps,dwmac.yaml file. By doing so we'll still provide a common properties
evaluation for each vendor-specific MAC bindings which refer to the
common bindings file, while the generic DW MAC DT nodes will be checked
against the new snps,dwmac-generic.yaml DT schema.
Signed-off-by: Serge Semin
---
.../bindings/net/snps,dwmac-generic.yaml | 148 ++
.../devicetree/bindings/net/snps,dwmac.yaml | 139 +---
2 files changed, 149 insertions(+), 138 deletions(-)
create mode 100644
Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
new file mode 100644
index ..f1b387911390
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare Generic MAC Device Tree Bindings
+
+maintainers:
+ - Alexandre Torgue
+ - Giuseppe Cavallaro
+ - Jose Abreu
+
+# Select the DT nodes, which have got compatible strings either as just a
+# single string with IP-core name optionally followed by the IP version or
+# two strings: one with IP-core name plus the IP version, another as just
+# the IP-core name.
+select:
+ properties:
+compatible:
+ oneOf:
+- items:
+- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$"
+- items:
+- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$"
+- const: snps,dwmac
+- items:
+- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$"
+- const: snps,dwxgmac
+
+ required:
+- compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - description: Generic Synopsys DW MAC
+oneOf:
+ - items:
+ - enum:
+ - snps,dwmac-3.50a
+ - snps,dwmac-3.610
+ - snps,dwmac-3.70a
+ - snps,dwmac-3.710
+ - snps,dwmac-4.00
+ - snps,dwmac-4.10a
+ - snps,dwmac-4.20a
+ - const: snps,dwmac
+ - const: snps,dwmac
+ - description: Generic Synopsys DW xGMAC
+oneOf:
+ - items:
+ - enum:
+ - snps,dwxgmac-2.10
+ - const: snps,dwxgmac
+ - const: snps,dwxgmac
+ - description: ST SPEAr SoC Family GMAC
+deprecated: true
+const: st,spear600-gmac
+
+ reg:
+maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+gmac0: ethernet@e080 {
+ compatible = "snps,dwxgmac-2.10", "snps,dwxgmac";
+ reg = <0xe080 0x8000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <24 23 22>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ mac-address = []; /* Filled in by U-Boot */
+ max-frame-size = <3800>;
+ phy-mode = "gmii";
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ rx-fifo-depth = <16384>;
+ tx-fifo-depth = <16384>;
+ clocks = <&clock>;
+ clock-names = "stmmaceth";
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ mdio0 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "snps,dwmac-mdio";
+phy1: ethernet-phy@0 {
+ reg = <0>;
+};
+ };
+};
+ - |
+gmac1: ethernet@f801 {
+ compatible = "snps,dwmac-4.10a", "snps,dwmac";
+ reg = <0xf801 0x4000>;
+ interrupts = <0 98 4>;
+ interrupt-names = "macirq";
+ clock-names = "stmmaceth", "ptp_ref";
+ clocks = <&clock 4>, <&clock 5>;
+ phy-mode = "rgmii";
+ snps,txpbl = <8>;
+ snps,rxpbl = <2>;
+ snps,aal;
+ snps,tso;
+
+ snps,axi-config {
+snps,wr_osr_lmt = <0xf>;
+snps,rd_osr_lmt = <0xf>;
+snps,blen = <256 128 64 32 0 0 0>;
+ };
+
+
[PATCH 09/25] net: stmmac: dwmac-rk: Cleanup STMMAC DT-config in remove cb
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.
Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev
leaks")
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 6ef30252bfe0..01c10ca80f1a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1433,11 +1433,14 @@ static int rk_gmac_probe(struct platform_device *pdev)
static int rk_gmac_remove(struct platform_device *pdev)
{
+ struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct rk_priv_data *bsp_priv = get_stmmac_bsp_priv(&pdev->dev);
int ret = stmmac_dvr_remove(&pdev->dev);
rk_gmac_powerdown(bsp_priv);
+ stmmac_remove_config_dt(pdev, priv->plat);
+
return ret;
}
--
2.29.2
[PATCH 20/25] net: stmmac: Add Tx/Rx platform clocks support
Depending on the DW *MAC configuration it can be at least connected to an
external Transmit clock, but in some cases to an external Receive clock
generator. In order to simplify/unify the sub-drivers code and to prevent
having the same clocks named differently add the Tx/Rx clocks support to
the generic STMMAC DT-based platform data initialization method under the
names "tx" and "rx" respectively. The bindings schema has already been
altered in accordance with that.
Signed-off-by: Serge Semin
---
.../ethernet/stmicro/stmmac/stmmac_platform.c | 24 +++
include/linux/stmmac.h| 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 38e8836861c4..943498d57e3a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -588,6 +588,24 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
clk_prepare_enable(plat->pclk);
+ plat->tx_clk = devm_clk_get_optional(&pdev->dev, "tx");
+ if (IS_ERR(plat->tx_clk)) {
+ rc = PTR_ERR(plat->tx_clk);
+ dev_err_probe(&pdev->dev, rc, "Cannot get Tx clock\n");
+ goto error_tx_clk_get;
+ }
+
+ clk_prepare_enable(plat->tx_clk);
+
+ plat->rx_clk = devm_clk_get_optional(&pdev->dev, "rx");
+ if (IS_ERR(plat->rx_clk)) {
+ rc = PTR_ERR(plat->rx_clk);
+ dev_err_probe(&pdev->dev, rc, "Cannot get Rx clock\n");
+ goto error_rx_clk_get;
+ }
+
+ clk_prepare_enable(plat->rx_clk);
+
/* Fall-back to main clock in case of no PTP ref is passed */
plat->clk_ptp_ref = devm_clk_get_optional(&pdev->dev, "ptp_ref");
if (IS_ERR(plat->clk_ptp_ref)) {
@@ -613,6 +631,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
return plat;
error_hw_init:
+ clk_disable_unprepare(plat->rx_clk);
+error_rx_clk_get:
+ clk_disable_unprepare(plat->tx_clk);
+error_tx_clk_get:
clk_disable_unprepare(plat->pclk);
error_pclk_get:
clk_disable_unprepare(plat->stmmac_clk);
@@ -634,6 +656,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
void stmmac_remove_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat)
{
+ clk_disable_unprepare(plat->rx_clk);
+ clk_disable_unprepare(plat->tx_clk);
clk_disable_unprepare(plat->pclk);
clk_disable_unprepare(plat->stmmac_clk);
of_node_put(plat->phy_node);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 628e28903b8b..b75cf13d088c 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -185,6 +185,8 @@ struct plat_stmmacenet_data {
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
+ struct clk *tx_clk;
+ struct clk *rx_clk;
struct clk *clk_ptp_ref;
unsigned int clk_ptp_rate;
unsigned int clk_ref_rate;
--
2.29.2
[PATCH 16/25] net: stmmac: Use optional clock request method to get ptp_clk
Let's replace the manual implementation of the optional ptp_clk
functionality with method devm_clk_get_optional() provided by the common
clock kernel framework. First of all it will be better from
maintainability point of view. Secondly by doing so we'll also fix a
potential problem, which will come out if the PTP clock has been actually
specified, but the clock framework failed to request it.
Note since we are switching the code to using the optional common clock
API, then there is no need in checking the clk_ptp_ref pointer for being
not NULL before calling the clk_prepare_enable() method. The later will
correctly handle it. So just discard the conditional statement of
priv->plat->clk_ptp_ref pointer value testing in the stmmac_resume()
method.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 13681027dd09..e9003684efc8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5230,8 +5230,7 @@ int stmmac_resume(struct device *dev)
/* enable the clk previously disabled */
clk_prepare_enable(priv->plat->stmmac_clk);
clk_prepare_enable(priv->plat->pclk);
- if (priv->plat->clk_ptp_ref)
- clk_prepare_enable(priv->plat->clk_ptp_ref);
+ clk_prepare_enable(priv->plat->clk_ptp_ref);
/* reset the phy so that it's ready */
if (priv->mii)
stmmac_mdio_reset(priv->mii);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3809b00d3077..367d1458d66d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -589,10 +589,13 @@ stmmac_probe_config_dt(struct platform_device *pdev,
const char **mac)
clk_prepare_enable(plat->pclk);
/* Fall-back to main clock in case of no PTP ref is passed */
- plat->clk_ptp_ref = devm_clk_get(&pdev->dev, "ptp_ref");
+ plat->clk_ptp_ref = devm_clk_get_optional(&pdev->dev, "ptp_ref");
if (IS_ERR(plat->clk_ptp_ref)) {
+ rc = PTR_ERR(plat->clk_ptp_ref);
+ dev_err_probe(&pdev->dev, rc, "Cannot get PTP clock\n");
+ goto error_hw_init;
+ } else if (!plat->clk_ptp_ref) {
plat->clk_ptp_rate = clk_get_rate(plat->stmmac_clk);
- plat->clk_ptp_ref = NULL;
dev_info(&pdev->dev, "PTP uses main clock\n");
} else {
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
--
2.29.2
[PATCH 05/25] dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description
Current clocks description doesn't provide a comprehensive notion about what "stmmaceth" and "pclk" actually represent from the IP-core manual point of view. The bindings file states: stmmaceth - "GMAC main clock", apb - "Peripheral registers interface clock". It isn't that easy to understand what they actually mean especially seeing the DW *MAC manual operates with clock definitions like Application, System, Host, CSR, Transmit, Receive, etc clocks. Moreover the clocks usage in the driver doesn't shade a full light on their essence. What inferred from there is that the "stmmaceth" name has been assigned to the common clock, which feeds both system and CSR interfaces. But what about "apb"? The bindings defines it as the clock for "peripheral registers interface". So it's close to the CSR clock in the IP-core manual notation. If so then when "apb" clock is specified aside with the "stmmaceth", it represents a case when the DW *MAC is synthesized with CSR_SLV_CLK=y (separate system and CSR clocks). But even though the "apb" clock is requested in the MAC driver, the driver doesn't actually use it as a separate CSR clock where the IP-core manual requires. All of that makes me thinking that the case of separate system and CSR clocks isn't correctly implemented in the driver. Let's start with elaborating the clocks description so anyone reading the DW *MAC bindings file would understand that "stmmaceth" is the system clock and "pclk" is actually the CSR clock. Indeed in accordance with sheets depicted in [1]: system/application clock can be either of: hclk_i, aclk_i, clk_app_i; CSR clock can be either of: hclk_i, aclk_i, clk_app_i, clk_csr_i. (Most likely the similar definitions present in the others IP-core manuals.) So the CSR clock can be tied to the application clock considering the later as the main clock, but not the other way around. In case if there is only "stmmaceth" clock specified in a DT node, then it will be considered as a source of clocks for both application and CSR. But if "pclk" is also specified in the list of the device clocks, then it will be perceived as the separate CSR clock. [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, October 2013, p. 564. Signed-off-by: Serge Semin --- .../devicetree/bindings/net/snps,dwmac.yaml | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 44aa88151cba..e1ebe5c8b1da 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -116,8 +116,16 @@ properties: maxItems: 5 additionalItems: true items: - - description: GMAC main clock - - description: Peripheral registers interface clock + - description: + GMAC main clock, also called as system/application clock. + This clock is used to provide a periodic signal for the DMA/MTL + interface and optionally for CSR, if the later isn't separately + clocked. + - description: + Peripheral registers interface clock, also called as CSR clock. + MCI, CSR and SMA interfaces run on this clock. If it's omitted, + the CSR interfaces are considered as synchronous to the system + clock domain. - description: PTP reference clock. This clock is used for programming the Timestamp Addend Register. If not passed then the system -- 2.29.2
[PATCH 12/25] net: stmmac: Directly call reverse methods in stmmac_probe_config_dt()
Calling an antagonistic method from the corresponding protagonist isn't
good from maintainability point of view, since prevents us from directly
adding a functionality in the later, which needs to be reverted in the
former. Since that's what we are about to do in order to fix the commit
573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to
platform structure"), let's replace the stmmac_remove_config_dt() method
invocation in stmmac_probe_config_dt() with direct reversal procedures.
Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst
to platform structure")
Signed-off-by: Serge Semin
---
.../ethernet/stmicro/stmmac/stmmac_platform.c | 26 ---
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index b4720e477d90..5110545090d2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -457,7 +457,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
/* To Configure PHY by using all device-tree supported properties */
rc = stmmac_dt_phy(plat, np, &pdev->dev);
if (rc)
- return ERR_PTR(rc);
+ goto error_dt_phy_parse;
of_property_read_u32(np, "tx-fifo-depth", &plat->tx_fifo_size);
@@ -535,8 +535,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*dma_cfg),
GFP_KERNEL);
if (!dma_cfg) {
- stmmac_remove_config_dt(pdev, plat);
- return ERR_PTR(-ENOMEM);
+ rc = -ENOMEM;
+ goto error_dma_cfg_alloc;
}
plat->dma_cfg = dma_cfg;
@@ -563,10 +563,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
plat->axi = stmmac_axi_setup(pdev);
rc = stmmac_mtl_setup(pdev, plat);
- if (rc) {
- stmmac_remove_config_dt(pdev, plat);
- return ERR_PTR(rc);
- }
+ if (rc)
+ goto error_dma_cfg_alloc;
/* clock setup */
if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
@@ -581,8 +579,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
plat->pclk = devm_clk_get(&pdev->dev, "pclk");
if (IS_ERR(plat->pclk)) {
- if (PTR_ERR(plat->pclk) == -EPROBE_DEFER)
+ if (PTR_ERR(plat->pclk) == -EPROBE_DEFER) {
+ rc = PTR_ERR(plat->pclk);
goto error_pclk_get;
+ }
plat->pclk = NULL;
}
@@ -602,8 +602,10 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
plat->stmmac_rst = devm_reset_control_get(&pdev->dev,
STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_rst)) {
- if (PTR_ERR(plat->stmmac_rst) == -EPROBE_DEFER)
+ if (PTR_ERR(plat->stmmac_rst) == -EPROBE_DEFER) {
+ rc = PTR_ERR(plat->stmmac_rst);
goto error_hw_init;
+ }
dev_info(&pdev->dev, "no reset control found\n");
plat->stmmac_rst = NULL;
@@ -615,8 +617,12 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
clk_disable_unprepare(plat->pclk);
error_pclk_get:
clk_disable_unprepare(plat->stmmac_clk);
+error_dma_cfg_alloc:
+ of_node_put(plat->mdio_node);
+error_dt_phy_parse:
+ of_node_put(plat->phy_node);
- return ERR_PTR(-EPROBE_DEFER);
+ return ERR_PTR(rc);
}
/**
--
2.29.2
[PATCH 17/25] net: stmmac: Use optional reset control API to work with stmmaceth
Replace the manual implementation of the optional device reset control
functionality with using the devm_reset_control_get_optional() method in
order to improve the code maintainability and fix a potential bug. It
will come out if the reset control handler has been specified, but the
reset framework failed to request it.
Note there is no need in checking the priv->plat->stmmac_rst pointer for
being not NULL in order to perform the reset control assertion/deassertion
because the passed NULL will be considered by the reset framework as
absent optional reset control handler anyway.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
.../ethernet/stmicro/stmmac/stmmac_platform.c | 14 +-
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e9003684efc8..7f4d54d2fc72 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4889,15 +4889,13 @@ int stmmac_dvr_probe(struct device *device,
if ((phyaddr >= 0) && (phyaddr <= 31))
priv->plat->phy_addr = phyaddr;
- if (priv->plat->stmmac_rst) {
- ret = reset_control_assert(priv->plat->stmmac_rst);
- reset_control_deassert(priv->plat->stmmac_rst);
- /* Some reset controllers have only reset callback instead of
-* assert + deassert callbacks pair.
-*/
- if (ret == -ENOTSUPP)
- reset_control_reset(priv->plat->stmmac_rst);
- }
+ ret = reset_control_assert(priv->plat->stmmac_rst);
+ reset_control_deassert(priv->plat->stmmac_rst);
+ /* Some reset controllers have only reset callback instead of
+* assert + deassert callbacks pair.
+*/
+ if (ret == -ENOTSUPP)
+ reset_control_reset(priv->plat->stmmac_rst);
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
@@ -5101,8 +5099,7 @@ int stmmac_dvr_remove(struct device *dev)
stmmac_exit_fs(ndev);
#endif
phylink_destroy(priv->phylink);
- if (priv->plat->stmmac_rst)
- reset_control_assert(priv->plat->stmmac_rst);
+ reset_control_assert(priv->plat->stmmac_rst);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 367d1458d66d..38e8836861c4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -602,16 +602,12 @@ stmmac_probe_config_dt(struct platform_device *pdev,
const char **mac)
dev_dbg(&pdev->dev, "PTP rate %d\n", plat->clk_ptp_rate);
}
- plat->stmmac_rst = devm_reset_control_get(&pdev->dev,
- STMMAC_RESOURCE_NAME);
+ plat->stmmac_rst = devm_reset_control_get_optional(&pdev->dev,
+
STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_rst)) {
- if (PTR_ERR(plat->stmmac_rst) == -EPROBE_DEFER) {
- rc = PTR_ERR(plat->stmmac_rst);
- goto error_hw_init;
- }
-
- dev_info(&pdev->dev, "no reset control found\n");
- plat->stmmac_rst = NULL;
+ rc = PTR_ERR(plat->stmmac_rst);
+ dev_err_probe(&pdev->dev, rc, "Cannot get reset control\n");
+ goto error_hw_init;
}
return plat;
--
2.29.2
[PATCH 23/25] net: stmmac: Call stmmaceth clock as system clock in warn-message
By all means of the stmmac_clk clock usage it isn't CSR clock, but the
system or application clock, which in particular cases can be used as a
clock source for the CSR interface. Make sure the warning message
correctly identify the clock.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 943498d57e3a..6e22036eab60 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -573,7 +573,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
STMMAC_RESOURCE_NAME);
if (IS_ERR(plat->stmmac_clk)) {
rc = PTR_ERR(plat->stmmac_clk);
- dev_err_probe(&pdev->dev, rc, "Cannot get CSR clock\n");
+ dev_err_probe(&pdev->dev, rc, "Cannot get system clock\n");
goto error_dma_cfg_alloc;
}
--
2.29.2
[PATCH 18/25] net: stmmac: dwc-qos: Cleanup STMMAC platform data clock pointers
The pointers need to be nullified otherwise the stmmac_remove_config_dt()
method called after them being initialized will disable the clocks. That
then will cause a WARN() backtrace being printed since the clocks would be
also disabled in the locally defined remove method.
Signed-off-by: Serge Semin
---
.../stmicro/stmmac/dwmac-dwc-qos-eth.c| 42 ++-
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 2342d497348e..31ca299a1cfd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -123,39 +123,46 @@ static void *dwc_qos_probe(struct platform_device *pdev,
struct plat_stmmacenet_data *plat_dat,
struct stmmac_resources *stmmac_res)
{
+ struct clk *clk;
int err;
- plat_dat->stmmac_clk = devm_clk_get(&pdev->dev, "apb_pclk");
- if (IS_ERR(plat_dat->stmmac_clk)) {
+ clk = devm_clk_get(&pdev->dev, "apb_pclk");
+ if (IS_ERR(clk)) {
dev_err(&pdev->dev, "apb_pclk clock not found.\n");
- return ERR_CAST(plat_dat->stmmac_clk);
+ return ERR_CAST(clk);
}
- err = clk_prepare_enable(plat_dat->stmmac_clk);
+ err = clk_prepare_enable(clk);
if (err < 0) {
dev_err(&pdev->dev, "failed to enable apb_pclk clock: %d\n",
err);
return ERR_PTR(err);
}
- plat_dat->pclk = devm_clk_get(&pdev->dev, "phy_ref_clk");
- if (IS_ERR(plat_dat->pclk)) {
+ plat_dat->stmmac_clk = clk;
+
+ clk = devm_clk_get(&pdev->dev, "phy_ref_clk");
+ if (IS_ERR(clk)) {
dev_err(&pdev->dev, "phy_ref_clk clock not found.\n");
- err = PTR_ERR(plat_dat->pclk);
+ err = PTR_ERR(clk);
goto disable;
}
- err = clk_prepare_enable(plat_dat->pclk);
+ err = clk_prepare_enable(clk);
if (err < 0) {
dev_err(&pdev->dev, "failed to enable phy_ref clock: %d\n",
err);
goto disable;
}
+ plat_dat->pclk = clk;
+
return NULL;
disable:
clk_disable_unprepare(plat_dat->stmmac_clk);
+ plat_dat->stmmac_clk = NULL;
+
return ERR_PTR(err);
}
@@ -164,8 +171,15 @@ static int dwc_qos_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
struct stmmac_priv *priv = netdev_priv(ndev);
+ /* Cleanup the pointers to the clock handlers hidden in the platform
+* data so the stmmac_remove_config_dt() method wouldn't have disabled
+* the clocks too.
+*/
clk_disable_unprepare(priv->plat->pclk);
+ priv->plat->pclk = NULL;
+
clk_disable_unprepare(priv->plat->stmmac_clk);
+ priv->plat->stmmac_clk = NULL;
return 0;
}
@@ -303,12 +317,12 @@ static void *tegra_eqos_probe(struct platform_device
*pdev,
goto disable_master;
}
- data->stmmac_clk = eqos->clk_slave;
-
err = clk_prepare_enable(eqos->clk_slave);
if (err < 0)
goto disable_master;
+ data->stmmac_clk = eqos->clk_slave;
+
eqos->clk_rx = devm_clk_get(&pdev->dev, "rx");
if (IS_ERR(eqos->clk_rx)) {
err = PTR_ERR(eqos->clk_rx);
@@ -381,6 +395,7 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
clk_disable_unprepare(eqos->clk_rx);
disable_slave:
clk_disable_unprepare(eqos->clk_slave);
+ data->stmmac_clk = NULL;
disable_master:
clk_disable_unprepare(eqos->clk_master);
error:
@@ -390,6 +405,7 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
static int tegra_eqos_remove(struct platform_device *pdev)
{
+ struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct tegra_eqos *eqos = get_stmmac_bsp_priv(&pdev->dev);
reset_control_assert(eqos->rst);
@@ -399,6 +415,12 @@ static int tegra_eqos_remove(struct platform_device *pdev)
clk_disable_unprepare(eqos->clk_slave);
clk_disable_unprepare(eqos->clk_master);
+ /* Cleanup the pointers to the clock handlers hidden in the platform
+* data so the stmmac_remove_config_dt() method wouldn't have disabled
+* the clocks too.
+*/
+ priv->plat->stmmac_clk = NULL;
+
return 0;
}
--
2.29.2
Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
On Fri, 11 Dec 2020 at 18:45, Peter Zijlstra wrote:
>
> On Thu, Dec 10, 2020 at 12:58:33PM +, Mel Gorman wrote:
> > The prequisite patch to make that approach work was rejected though
> > as on its own, it's not very helpful and Vincent didn't like that the
> > load_balance_mask was abused to make it effective.
>
> So last time I poked at all this, I found that using more masks was a
> performance issue as well due to added cache misses.
>
> Anyway, I finally found some time to look at all this, and while reading
> over the whole SiS crud to refresh the brain came up with the below...
>
> It's still naf, but at least it gets rid of a bunch of duplicate
> scanning and LoC decreases, so it should be awesome. Ofcourse, as
> always, benchmarks will totally ruin everything, we'll see, I started
> some.
>
> It goes on top of Mel's first two patches (which is about as far as I
> got)...
We have several different things that Aubrey and Mel patches are
trying to achieve:
Aubrey wants to avoid scanning busy cpus
- patch works well on busy system: I see a significant benefit with
hackbench on a lot of group on my 2 nodes * 28 cores * 4 smt
hackbench -l 2000 -g 128
tip 3.334
w/ patch 2.978 (+12%)
- Aubey also tried to not scan the cpus which are idle for a short
duration (when a tick not stopped) but there are problems because not
stopping a tick doesn't mean a short idle. In fact , something similar
to find_idlest_group_cpu() should be done in this case but then it's
no more a fast path search
Mel wants to minimize looping over the cpus
-patch 4 is an obvious win on light loaded system because it avoids
looping twice the cpus mask when some cpus are idle but no core
-But patch 3 generates perf régression
hackbench -l 2000 -g 1
tip 12.293
/w all Mel's patches 15.163 -14%
/w Aubrey + Mel patches minus patch 3 : 12.788 +3.8% But I think that
Aubreay's patch doesn't help here. Test without aubrey's patch are
running
-he also tried to used load_balance_mask to do something similar to the below
>
> ---
> fair.c | 124
> -
> 1 file changed, 47 insertions(+), 77 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6021,11 +6021,13 @@ static inline void set_idle_cores(int cp
>
> static inline bool test_idle_cores(int cpu, bool def)
> {
> - struct sched_domain_shared *sds;
> + if (static_branch_likely(&sched_smt_present)) {
> + struct sched_domain_shared *sds;
>
> - sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
> - if (sds)
> - return READ_ONCE(sds->has_idle_cores);
> + sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
> + if (sds)
> + return READ_ONCE(sds->has_idle_cores);
> + }
>
> return def;
> }
> @@ -6059,77 +6061,39 @@ void __update_idle_core(struct rq *rq)
> rcu_read_unlock();
> }
>
> -/*
> - * Scan the entire LLC domain for idle cores; this dynamically switches off
> if
> - * there are no idle cores left in the system; tracked through
> - * sd_llc->shared->has_idle_cores and enabled through update_idle_core()
> above.
> - */
> -static int select_idle_core(struct task_struct *p, struct sched_domain *sd,
> int target)
> +static int __select_idle_core(int core, struct cpumask *cpus, int *idle_cpu)
> {
> - struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
> - int core, cpu;
> -
> - if (!static_branch_likely(&sched_smt_present))
> - return -1;
> -
> - if (!test_idle_cores(target, false))
> - return -1;
> -
> - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> -
> - for_each_cpu_wrap(core, cpus, target) {
> - bool idle = true;
> + bool idle = true;
> + int cpu;
>
> - for_each_cpu(cpu, cpu_smt_mask(core)) {
> - if (!available_idle_cpu(cpu)) {
> - idle = false;
> - break;
> - }
> + for_each_cpu(cpu, cpu_smt_mask(core)) {
> + if (!available_idle_cpu(cpu)) {
> + idle = false;
> + continue;
By not breaking on the first not idle cpu of the core, you will
largely increase the number of loops. On my system, it increases 4
times from 28 up tu 112
> }
> -
> - if (idle)
> - return core;
> -
> - cpumask_andnot(cpus, cpus, cpu_smt_mask(core));
> + if (idle_cpu)
> + *idle_cpu = cpu;
> }
>
> - /*
> -* Failed to find an idle core; stop looking for one.
> -*/
> - set_idle_cores(target, 0);
> + if (idle)
> + return core;
>
> + cpumask_andnot(cpus, cpus, cpu_smt_mask(core));
> return -1;
> }
>
> -/*
> - * Scan the local SMT mask for id
Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support
On Mon, Dec 14, 2020 at 9:58 AM Johan Hovold wrote: > On Sat, Dec 12, 2020 at 01:03:32AM +0100, Linus Walleij wrote: > > If I google for the phrase "Detected name collision for GPIO name" > > I just find the code, our discussions and some USB serial devices > > warning about this so far. > > > > Maybe we should just make a patch to disallow it? > > That would make it impossible to provide name lines on hotpluggable > controllers, which would be nice to support. I merged a patch for this now, let's tighten this loose end up. Also: thanks for poking me about this, I should have looked into this ages ago :/ focus you know... Yours, Linus Walleij
[PATCH 13/25] net: stmmac: Fix clocks left enabled on glue-probes failure
The generic clocks request and preparation have been moved from
stmmac_dvr_probe()/stmmac_init_ptp() to the stmmac_probe_config_dt()
method in the framework of commit f573c0b9c4e0 ("stmmac: move stmmac_clk,
pclk, clk_ptp_ref and stmmac_rst to platform structure"). At the same time
the clocks disabling and reset assertion have been left in
stmmac_dvr_remove() instead of also being moved to the symmetric
antagonistic method - stmmac_remove_config_dt(). Due to that all the glue
drivers probe cleanup-on-failure paths don't perform the generic clocks
disable/unprepare procedure, which of course is wrong. Fix it by moving
the clocks disable/unprepare methods invocation to the
stmmac_remove_config_dt() function.
Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst
to platform structure")
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 2 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 --
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 81ee0a071b4e..884b8d661442 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -667,6 +667,8 @@ static void intel_eth_pci_remove(struct pci_dev *pdev)
pci_free_irq_vectors(pdev);
+ clk_disable_unprepare(priv->plat->stmmac_clk);
+
clk_unregister_fixed_rate(priv->plat->stmmac_clk);
pcim_iounmap_regions(pdev, BIT(0));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d833908b660a..13681027dd09 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5103,8 +5103,6 @@ int stmmac_dvr_remove(struct device *dev)
phylink_destroy(priv->phylink);
if (priv->plat->stmmac_rst)
reset_control_assert(priv->plat->stmmac_rst);
- clk_disable_unprepare(priv->plat->pclk);
- clk_disable_unprepare(priv->plat->stmmac_clk);
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5110545090d2..56419f511a48 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -630,11 +630,13 @@ stmmac_probe_config_dt(struct platform_device *pdev,
const char **mac)
* @pdev: platform_device structure
* @plat: driver data platform structure
*
- * Release resources claimed by stmmac_probe_config_dt().
+ * Disable and release resources claimed by stmmac_probe_config_dt().
*/
void stmmac_remove_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat)
{
+ clk_disable_unprepare(plat->pclk);
+ clk_disable_unprepare(plat->stmmac_clk);
of_node_put(plat->phy_node);
of_node_put(plat->mdio_node);
}
--
2.29.2
[PATCH 24/25] net: stmmac: Use pclk to set MDC clock frequency
In accordance with [1] the MDC clock frequency is supposed to be selected
with respect to the CSR clock frequency. CSR clock can be either tied to
the DW MAC system clock (GMAC main clock) or supplied via a dedicated
clk_csr_i signal. Current MDC clock selection procedure handles the former
case while having no support of the later one. That's wrong for the
devices which have separate system and CSR clocks. Let's fix it by first
trying to get the synchro-signal rate from the "pclk" clock, if it hasn't
been specified then fall-back to the "stmmaceth" clock.
[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 424.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7f4d54d2fc72..719b00fd2a70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -206,7 +206,12 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
{
u32 clk_rate;
- clk_rate = clk_get_rate(priv->plat->stmmac_clk);
+ /* If APB clock has been specified then it is supposed to be used
+* to select the CSR mode. Otherwise the application clock is the
+* source of the periodic signal for the CSR interface.
+*/
+ clk_rate = clk_get_rate(priv->plat->pclk) ?:
+ clk_get_rate(priv->plat->stmmac_clk);
/* Platform provided default clk_csr would be assumed valid
* for all other cases except for the below mentioned ones.
--
2.29.2
[PATCH 19/25] net: stmmac: dwc-qos: Use dev_err_probe() for probe errors handling
There is a very handy dev_err_probe() method to handle the deferred probe
error number. It reduces the code size, uniforms error handling, records
the defer probe reason, etc. Use it to print the probe callback error
message.
Signed-off-by: Serge Semin
Cc: Anson Huang
---
drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 31ca299a1cfd..57f957898b60 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -473,11 +473,8 @@ static int dwc_eth_dwmac_probe(struct platform_device
*pdev)
priv = data->probe(pdev, plat_dat, &stmmac_res);
if (IS_ERR(priv)) {
ret = PTR_ERR(priv);
-
- if (ret != -EPROBE_DEFER)
- dev_err(&pdev->dev, "failed to probe subdriver: %d\n",
- ret);
-
+ dev_err_probe(&pdev->dev, ret, "failed to probe subdriver:
%d\n",
+ ret);
goto remove_config;
}
--
2.29.2
[PATCH 14/25] net: stmmac: Use optional clock request method to get stmmaceth
The "stmmaceth" clock is expected to be optional by the current driver
design, but there are several problems in the implementation. First if the
clock is specified, but failed to be requested due to an internal error or
due to not being ready yet for configuration, then the DT-probe procedure
will just proceed with further initializations. It is erroneous in both
cases. Secondly if we'd use the clock API, which expect the clock being
optional we wouldn't have needed to avoid the clock request procedure for
the "snps,dwc-qos-ethernet-4.10"-compatible devices to prevent the error
message from being printed. All of that can be fixed by using the
devm_clk_get_optional() method here provided by the common clock
framework.
Signed-off-by: Serge Semin
---
.../ethernet/stmicro/stmmac/stmmac_platform.c | 20 ++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 56419f511a48..e79b3e3351a9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -566,17 +566,19 @@ stmmac_probe_config_dt(struct platform_device *pdev,
const char **mac)
if (rc)
goto error_dma_cfg_alloc;
- /* clock setup */
- if (!of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
- plat->stmmac_clk = devm_clk_get(&pdev->dev,
- STMMAC_RESOURCE_NAME);
- if (IS_ERR(plat->stmmac_clk)) {
- dev_warn(&pdev->dev, "Cannot get CSR clock\n");
- plat->stmmac_clk = NULL;
- }
- clk_prepare_enable(plat->stmmac_clk);
+ /* All clocks are optional since the sub-drivers can have a specific
+* clocks set and their naming.
+*/
+ plat->stmmac_clk = devm_clk_get_optional(&pdev->dev,
+STMMAC_RESOURCE_NAME);
+ if (IS_ERR(plat->stmmac_clk)) {
+ rc = PTR_ERR(plat->stmmac_clk);
+ dev_err_probe(&pdev->dev, rc, "Cannot get CSR clock\n");
+ goto error_dma_cfg_alloc;
}
+ clk_prepare_enable(plat->stmmac_clk);
+
plat->pclk = devm_clk_get(&pdev->dev, "pclk");
if (IS_ERR(plat->pclk)) {
if (PTR_ERR(plat->pclk) == -EPROBE_DEFER) {
--
2.29.2
[PATCH 06/25] dt-bindings: net: dwmac: Add Tx/Rx clock sources
Generic DW *MAC can be connected to an external Tramit and Receive clock generators. Add the corresponding clocks description and clock-names to the generic bindings schema so new DW *MAC-based bindings wouldn't declare its own names of the same clocks. Signed-off-by: Serge Semin --- .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index e1ebe5c8b1da..74820f491346 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -126,6 +126,18 @@ properties: MCI, CSR and SMA interfaces run on this clock. If it's omitted, the CSR interfaces are considered as synchronous to the system clock domain. + - description: + GMAC Tx clock or so called Transmit clock. The clock is supplied + by an external with respect to the DW MAC clock generator. + The clock source and its frequency depends on the DW MAC xMII mode. + In case if it's supplied by PHY/SerDes this property can be + omitted. + - description: + GMAC Rx clock or so called Receive clock. The clock is supplied + by an external with respect to the DW MAC clock generator. + The clock source and its frequency depends on the DW MAC xMII mode. + In case if it's supplied by PHY/SerDes or it's synchronous to + the Tx clock this property can be omitted. - description: PTP reference clock. This clock is used for programming the Timestamp Addend Register. If not passed then the system @@ -139,6 +151,8 @@ properties: enum: - stmmaceth - pclk +- tx +- rx - ptp_ref resets: -- 2.29.2
[PATCH 10/25] net: stmmac: dwmac-sti: Cleanup STMMAC DT-config in remove cb
The stmmac_remove_config_dt() method needs to be called on the device
remove procedure otherwise for at least some of device-nodes will be left
requested.
Fixes: d2ed0a7755fe ("net: ethernet: stmmac: fix of-node and fixed-link-phydev
leaks")
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
index e1b63df6f96f..3454c5eff822 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
@@ -370,11 +370,14 @@ static int sti_dwmac_probe(struct platform_device *pdev)
static int sti_dwmac_remove(struct platform_device *pdev)
{
+ struct stmmac_priv *priv = netdev_priv(platform_get_drvdata(pdev));
struct sti_dwmac *dwmac = get_stmmac_bsp_priv(&pdev->dev);
int ret = stmmac_dvr_remove(&pdev->dev);
clk_disable_unprepare(dwmac->clk);
+ stmmac_remove_config_dt(pdev, priv->plat);
+
return ret;
}
--
2.29.2
[PATCH 08/25] net: stmmac: Add snps,*-config sub-nodes support
Currently the "snps,axi-config", "snps,mtl-rx-config" and
"snps,mtl-tx-config" DT node properties are marked as deprecated when
being defined as a phandle reference to a node with parameters. The new
way of defining the DW MAC interfaces config is to add an eponymous
sub-nodes to the DW MAC device DT node. Make sure the STMMAC driver
supports it.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index af34a4cadbb0..b4720e477d90 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -95,7 +95,8 @@ static struct stmmac_axi *stmmac_axi_setup(struct
platform_device *pdev)
struct device_node *np;
struct stmmac_axi *axi;
- np = of_parse_phandle(pdev->dev.of_node, "snps,axi-config", 0);
+ np = of_parse_phandle(pdev->dev.of_node, "snps,axi-config", 0) ?:
+of_get_child_by_name(pdev->dev.of_node, "snps,axi-config");
if (!np)
return NULL;
@@ -150,11 +151,13 @@ static int stmmac_mtl_setup(struct platform_device *pdev,
plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
- rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0);
+ rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0)
?:
+ of_get_child_by_name(pdev->dev.of_node, "snps,mtl-rx-config");
if (!rx_node)
return ret;
- tx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-tx-config", 0);
+ tx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-tx-config", 0)
?:
+ of_get_child_by_name(pdev->dev.of_node, "snps,mtl-tx-config");
if (!tx_node) {
of_node_put(rx_node);
return ret;
--
2.29.2
[PATCH 21/25] net: stmmac: dwc-qos: Discard Tx/Rx clocks request
Since the Tx/Rx clocks with the same names are now requested and
enabled/disabled in the STMMAC DT-based platform config method, there is
no need in duplicating the same procedures in the DWC QoS Eth sub-driver.
Discard it then, but make sure the denoted clocks have been specified
for the platform.
Note also the deprecated clock "phy_ref_clk" have been defined as the Tx
clock in the DWC QoS Eth bindings. Let's use a pointer to the Tx clock
defined in the platform data then instead of the unrelated pclk pointer.
Signed-off-by: Serge Semin
---
.../stmicro/stmmac/dwmac-dwc-qos-eth.c| 44 +--
1 file changed, 11 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index 57f957898b60..f53a78448988 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -31,8 +31,6 @@ struct tegra_eqos {
struct reset_control *rst;
struct clk *clk_master;
struct clk *clk_slave;
- struct clk *clk_tx;
- struct clk *clk_rx;
struct gpio_desc *reset;
};
@@ -155,7 +153,7 @@ static void *dwc_qos_probe(struct platform_device *pdev,
goto disable;
}
- plat_dat->pclk = clk;
+ plat_dat->tx_clk = clk;
return NULL;
@@ -175,8 +173,8 @@ static int dwc_qos_remove(struct platform_device *pdev)
* data so the stmmac_remove_config_dt() method wouldn't have disabled
* the clocks too.
*/
- clk_disable_unprepare(priv->plat->pclk);
- priv->plat->pclk = NULL;
+ clk_disable_unprepare(priv->plat->tx_clk);
+ priv->plat->tx_clk = NULL;
clk_disable_unprepare(priv->plat->stmmac_clk);
priv->plat->stmmac_clk = NULL;
@@ -197,6 +195,7 @@ static int dwc_qos_remove(struct platform_device *pdev)
static void tegra_eqos_fix_speed(void *priv, unsigned int speed)
{
struct tegra_eqos *eqos = priv;
+ struct stmmac_priv *sp = netdev_priv(dev_get_drvdata(eqos->dev));
unsigned long rate = 12500;
bool needs_calibration = false;
u32 value;
@@ -262,7 +261,7 @@ static void tegra_eqos_fix_speed(void *priv, unsigned int
speed)
writel(value, eqos->regs + AUTO_CAL_CONFIG);
}
- err = clk_set_rate(eqos->clk_tx, rate);
+ err = clk_set_rate(sp->plat->tx_clk, rate);
if (err < 0)
dev_err(eqos->dev, "failed to set TX rate: %d\n", err);
}
@@ -301,6 +300,11 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
if (!is_of_node(dev->fwnode))
goto bypass_clk_reset_gpio;
+ if (!data->tx_clk || !data->rx_clk) {
+ err = -EINVAL;
+ goto error;
+ }
+
eqos->clk_master = devm_clk_get(&pdev->dev, "master_bus");
if (IS_ERR(eqos->clk_master)) {
err = PTR_ERR(eqos->clk_master);
@@ -323,30 +327,10 @@ static void *tegra_eqos_probe(struct platform_device
*pdev,
data->stmmac_clk = eqos->clk_slave;
- eqos->clk_rx = devm_clk_get(&pdev->dev, "rx");
- if (IS_ERR(eqos->clk_rx)) {
- err = PTR_ERR(eqos->clk_rx);
- goto disable_slave;
- }
-
- err = clk_prepare_enable(eqos->clk_rx);
- if (err < 0)
- goto disable_slave;
-
- eqos->clk_tx = devm_clk_get(&pdev->dev, "tx");
- if (IS_ERR(eqos->clk_tx)) {
- err = PTR_ERR(eqos->clk_tx);
- goto disable_rx;
- }
-
- err = clk_prepare_enable(eqos->clk_tx);
- if (err < 0)
- goto disable_rx;
-
eqos->reset = devm_gpiod_get(&pdev->dev, "phy-reset", GPIOD_OUT_HIGH);
if (IS_ERR(eqos->reset)) {
err = PTR_ERR(eqos->reset);
- goto disable_tx;
+ goto disable_slave;
}
usleep_range(2000, 4000);
@@ -389,10 +373,6 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
reset_control_assert(eqos->rst);
reset_phy:
gpiod_set_value(eqos->reset, 1);
-disable_tx:
- clk_disable_unprepare(eqos->clk_tx);
-disable_rx:
- clk_disable_unprepare(eqos->clk_rx);
disable_slave:
clk_disable_unprepare(eqos->clk_slave);
data->stmmac_clk = NULL;
@@ -410,8 +390,6 @@ static int tegra_eqos_remove(struct platform_device *pdev)
reset_control_assert(eqos->rst);
gpiod_set_value(eqos->reset, 1);
- clk_disable_unprepare(eqos->clk_tx);
- clk_disable_unprepare(eqos->clk_rx);
clk_disable_unprepare(eqos->clk_slave);
clk_disable_unprepare(eqos->clk_master);
--
2.29.2
Re: [PATCH] media: vsp1: Fix an error handling path in the probe function
Hi Christophe,
On 12/12/2020 17:41, Christophe JAILLET wrote:
> A previous 'rcar_fcp_get()' call must be undone in the error handling path,
> as already done in the remove function.
Reviewed-by: Kieran Bingham
> Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
> Signed-off-by: Christophe JAILLET
> ---
> drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> b/drivers/media/platform/vsp1/vsp1_drv.c
> index dc62533cf32c..aa66e4f5f3f3 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -882,8 +882,10 @@ static int vsp1_probe(struct platform_device *pdev)
> }
>
> done:
> - if (ret)
> + if (ret) {
> pm_runtime_disable(&pdev->dev);
> + rcar_fcp_put(vsp1->fcp);
> + }
>
> return ret;
> }
>
[RFC] net: stmmac: Problem with adding the native GPIOs support
Hello folks, I've got a problem, which has been blowing by head up for more than three weeks now, and I'm desperately need your help in that matter. See our Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core has been synthesized with two GPIOs: one as GPI and another as GPO. There are multiple Baikal-T1-based devices have been created so far with active GMAC interface usage and each of them has been designed like this: ++ | Baikal-T1 ++ ++ | SoC | DW GMAC| | Some PHY | | | Rx-clk+<--+Rx-clk | | || || | | GPI+<--+#IRQ| | || || | | RGMII+<->+RGMII | | |MDIO+<->+MDIO| | || || | | GPO+-->+#RST| | || || | | Tx-clk+-->+Tx-clk | | || || | ++ ++ ++ Each of such devices has got en external RGMII-PHY attached configured via the MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The main peculiarity of such configuration is that the DW GMAC GPIOs have been used to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't been added to the STMMAC driver it's the very first setup for now, which has been using them. Anyway the hardware setup depicted above doesn't seem problematic at the first glance, but in fact it is. See, the DW *MAC driver (STMMAC ethernet driver) is doing the MAC reset each time it performs the device open or resume by means of the call-chain: stmmac_open()---+ +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset(). stmmac_resume()-+ Such reset causes the whole interface reset: MAC, DMA and, what is more important, GPIOs as being exposed as part of the MAC registers. That in our case automatically causes the external PHY reset, what neither the STTMAC driver nor the PHY subsystem expect at all. Moreover the stmmac_reset() method polls the DMA_BUS_MODE.SFT_RESET flag state to be sure the MAC is successfully completed. But since the external PHY has got in reset state it doesn't generate the Rx-clk signal. Due to that the MAC-DMA won't get out of the reset state so the stmmac_reset() method will return timeout error. Of course I could manually restore the GPIOs state in the stmmac_reset() before start to poll the SFT_RESET flag, which may release the PHY reset. But that seems more like a workaround, because the PHY still has been in reset and need to be reinitialized anyway. Moreover some PHY may need to have more complicated reset cycle with certain delays between RST assertion/de-assertion, so the workaround won't work well for them. To sum it up my question is what is the right way to resolve the problem described above? My first idea was to just move the MAC reset from the net-device open()/close() callbacks to the stmmac_dvr_probe()/stmmac_dvr_remove() functions and don't reset the whole interface on each device open. The problems we may have in that case is due to the suspend/resume procedures, which for some reason require the MAC reset too. That's why I need your help in this matter. Do you have any idea how to gently add the GPIOs support and don't break the STMMAC driver? One more tiny question regarding the DW *MAC drivers available in kernel. Aside of the DW GMAC Baikal-T1 SoC has also got DW xGMAC v2.11a embedded with XPCS PHY attached. My question is what driver should we better use to handle our xGMAC interface? AFAICS there are three DW *MAC-related drivers the kernel currently provides: 1) drivers/net/ethernet/stmicro/stmmac 2) drivers/net/ethernet/amd/ 3) drivers/net/ethernet/synopsys/ xGBE interface is supported by the drivers 1) and 2). In accordance with https://www.spinics.net/lists/netdev/msg414148.html all xGMAC related parts should have been added to 2), but recently the XGMAC support has been added to 1). So I am confused what driver is now supposed to be used for new xGMACs? Regards, -Sergey
[PATCH 22/25] net: stmmac: dwmac-imx: Discard Tx clock request
Since the Tx clock is now requested and enabled/disabled in the STMMAC
DT-based platform config method, there is no need in duplicating the same
procedures in the DW MAC iMX sub-driver.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/dwmac-imx.c | 21 +--
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index efef5476a577..7b4590670b4e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -40,7 +40,6 @@ struct imx_dwmac_ops {
struct imx_priv_data {
struct device *dev;
- struct clk *clk_tx;
struct clk *clk_mem;
struct regmap *intf_regmap;
u32 intf_reg_off;
@@ -104,12 +103,6 @@ static int imx_dwmac_init(struct platform_device *pdev,
void *priv)
return ret;
}
- ret = clk_prepare_enable(dwmac->clk_tx);
- if (ret) {
- dev_err(&pdev->dev, "tx clock enable failed\n");
- goto clk_tx_en_failed;
- }
-
if (dwmac->ops->set_intf_mode) {
ret = dwmac->ops->set_intf_mode(plat_dat);
if (ret)
@@ -119,8 +112,6 @@ static int imx_dwmac_init(struct platform_device *pdev,
void *priv)
return 0;
intf_mode_failed:
- clk_disable_unprepare(dwmac->clk_tx);
-clk_tx_en_failed:
clk_disable_unprepare(dwmac->clk_mem);
return ret;
}
@@ -129,7 +120,6 @@ static void imx_dwmac_exit(struct platform_device *pdev,
void *priv)
{
struct imx_priv_data *dwmac = priv;
- clk_disable_unprepare(dwmac->clk_tx);
clk_disable_unprepare(dwmac->clk_mem);
}
@@ -162,7 +152,7 @@ static void imx_dwmac_fix_speed(void *priv, unsigned int
speed)
return;
}
- err = clk_set_rate(dwmac->clk_tx, rate);
+ err = clk_set_rate(plat_dat->tx_clk, rate);
if (err < 0)
dev_err(dwmac->dev, "failed to set tx rate %lu\n", rate);
}
@@ -176,10 +166,9 @@ imx_dwmac_parse_dt(struct imx_priv_data *dwmac, struct
device *dev)
if (of_get_property(np, "snps,rmii_refclk_ext", NULL))
dwmac->rmii_refclk_ext = true;
- dwmac->clk_tx = devm_clk_get(dev, "tx");
- if (IS_ERR(dwmac->clk_tx)) {
- dev_err(dev, "failed to get tx clock\n");
- return PTR_ERR(dwmac->clk_tx);
+ if (!dwmac->plat_dat->tx_clk) {
+ dev_err(dev, "no tx clock found\n");
+ return -EINVAL;
}
dwmac->clk_mem = NULL;
@@ -239,6 +228,7 @@ static int imx_dwmac_probe(struct platform_device *pdev)
dwmac->ops = data;
dwmac->dev = &pdev->dev;
+ dwmac->plat_dat = plat_dat;
ret = imx_dwmac_parse_dt(dwmac, &pdev->dev);
if (ret) {
@@ -257,7 +247,6 @@ static int imx_dwmac_probe(struct platform_device *pdev)
plat_dat->exit = imx_dwmac_exit;
plat_dat->fix_mac_speed = imx_dwmac_fix_speed;
plat_dat->bsp_priv = dwmac;
- dwmac->plat_dat = plat_dat;
ret = imx_dwmac_init(pdev, dwmac);
if (ret)
--
2.29.2
[PATCH 25/25] net: stmmac: dwc-qos: Save master/slave clocks in the plat-data
Currently the "master_bus" clock of the DW QoS Eth controller isn't
preserved in the STMMAC platform data, while the "slave_bus" clock is
assigned to the stmmaceth clock pointer. It isn't correct from the
platform clock bindings point of view. The "stmmaceth" clock is supposed
to be the system clock, which is responsible for clocking the DMA
transfers from/to the controller FIFOs to/from the system memory and the
CSR interface if the later isn't separately clocked. If it's clocked
separately then the STMMAC platform code expects to also have "pclk"
specified. So in order to have the STMMAC platform data properly
initialized we need to set the "master_bus" clock handler to the
"stmmaceth" clock pointer, and the "slave_bus" clock handler to the "pclk"
clock pointer.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index f53a78448988..b90d7e4c3d4a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -315,6 +315,8 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
if (err < 0)
goto error;
+ data->stmmac_clk = eqos->clk_master;
+
eqos->clk_slave = devm_clk_get(&pdev->dev, "slave_bus");
if (IS_ERR(eqos->clk_slave)) {
err = PTR_ERR(eqos->clk_slave);
@@ -325,7 +327,7 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
if (err < 0)
goto disable_master;
- data->stmmac_clk = eqos->clk_slave;
+ data->pclk = eqos->clk_slave;
eqos->reset = devm_gpiod_get(&pdev->dev, "phy-reset", GPIOD_OUT_HIGH);
if (IS_ERR(eqos->reset)) {
@@ -375,9 +377,10 @@ static void *tegra_eqos_probe(struct platform_device *pdev,
gpiod_set_value(eqos->reset, 1);
disable_slave:
clk_disable_unprepare(eqos->clk_slave);
- data->stmmac_clk = NULL;
+ data->pclk = NULL;
disable_master:
clk_disable_unprepare(eqos->clk_master);
+ data->stmmac_clk = NULL;
error:
eqos = ERR_PTR(err);
goto out;
@@ -397,6 +400,7 @@ static int tegra_eqos_remove(struct platform_device *pdev)
* data so the stmmac_remove_config_dt() method wouldn't have disabled
* the clocks too.
*/
+ priv->plat->pclk = NULL;
priv->plat->stmmac_clk = NULL;
return 0;
--
2.29.2
[PATCH 15/25] net: stmmac: Use optional clock request method to get pclk
Let's replace the manual implementation of the optional "pclk"
functionality with using devm_clk_get_optional(). By doing so we'll
improve the code maintainability, and fix a hidden bug which will cause
problems if the "pclk" clock has been actually passed to the device, but
the clock framework failed to request it.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c| 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index e79b3e3351a9..3809b00d3077 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -579,15 +579,13 @@ stmmac_probe_config_dt(struct platform_device *pdev,
const char **mac)
clk_prepare_enable(plat->stmmac_clk);
- plat->pclk = devm_clk_get(&pdev->dev, "pclk");
+ plat->pclk = devm_clk_get_optional(&pdev->dev, "pclk");
if (IS_ERR(plat->pclk)) {
- if (PTR_ERR(plat->pclk) == -EPROBE_DEFER) {
- rc = PTR_ERR(plat->pclk);
- goto error_pclk_get;
- }
-
- plat->pclk = NULL;
+ rc = PTR_ERR(plat->pclk);
+ dev_err_probe(&pdev->dev, rc, "Cannot get CSR clock\n");
+ goto error_pclk_get;
}
+
clk_prepare_enable(plat->pclk);
/* Fall-back to main clock in case of no PTP ref is passed */
--
2.29.2
Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
On Mon, Dec 14, 2020 at 12:28 AM Icenowy Zheng wrote: > > 在 2020-12-02星期三的 13:54 +，Andre Przywara写道： > > Port A is used for an internal connection to some analogue circuitry > > which looks like an AC200 IP (as in the H6), though this is not > > mentioned in the manual. > > When developing for V831, I found that PIO controller in H616 (and > V831) has the functionality of selecting IO voltage of PF bank (needed > to handle UHS-I). > > How should we model this in PIO driver? I suppose we could expose it as a regulator for the mmc node to consume as its vqmmc-supply? ChenYu
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/Makefile
between commit:
527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
from the risc-v tree and commits:
8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
tests")
17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for
KUnit tests")
23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
tests")
1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc lib/Makefile
index bcedd691ef63,dc623561ef9d..
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
# KUnit tests
obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
- obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
- obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
- obj-$(CONFIG_BITS_TEST) += test_bits.o
+ obj-$(CONFIG_BITS_TEST) += bits_kunit.o
+ obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
+ obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
+ obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
+
+obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
pgpAGuimyqnvg.pgp
Description: OpenPGP digital signature
[PATCH] f2fs: fix to tag FIEMAP_EXTENT_MERGED in f2fs_fiemap()
f2fs does not natively support extents in metadata, 'extent' in f2fs
is used as a virtual concept, so in f2fs_fiemap() interface, it needs
to tag FIEMAP_EXTENT_MERGED flag to indicated the extent status is a
result of merging.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 894c5680db4a..baa9ccf84e2c 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1971,6 +1971,7 @@ int f2fs_fiemap(struct inode *inode, struct
fiemap_extent_info *fieinfo,
}
if (size) {
+ flags |= FIEMAP_EXTENT_MERGED;
if (IS_ENCRYPTED(inode))
flags |= FIEMAP_EXTENT_DATA_ENCRYPTED;
--
2.29.2
Re: [PATCH] arm64: Kconfig: Add SYS_SUPPORTS_APM_EMULATION
Hi, Could any maintainer help review this? Thanks a lot for your help, BRs, Lecopzer > Although most of modern devices use ACPI, there still has combination > of APM + ARM64. > > In order to select CONFIG_APM_EMULATION, make SYS_SUPPORTS_APM_EMULATION > default is y if ACPI isn't configured. > > Signed-off-by: Lecopzer Chen > Suggested-by: YJ Chiang > --- > arch/arm64/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1515f6f153a0..5e9e3694015a 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -260,6 +260,9 @@ config NO_IOPORT_MAP > config STACKTRACE_SUPPORT > def_bool y > > +config SYS_SUPPORTS_APM_EMULATION > + def_bool y if !ACPI > + > config ILLEGAL_POINTER_VALUE > hex > default 0xdead
[PATCH 01/25] dt-bindings: net: dwmac: Validate PBL for all IP-cores
Indeed the maximum DMA burst length can be programmed not only for DW xGMACs, Allwinner EMACs and Spear SoC GMAC, but in accordance with [1] for Generic DW *MAC IP-cores. Moreover the STMMAC set of drivers parse the property and then apply the configuration for all supported DW MAC devices. All of that makes the property being available for all IP-cores the bindings supports. Let's make sure the PBL-related properties are validated for all of them by the common DW MAC DT schema. [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, October 2013, p. 380. Signed-off-by: Serge Semin --- .../devicetree/bindings/net/snps,dwmac.yaml | 69 +++ 1 file changed, 26 insertions(+), 43 deletions(-) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 11a6fdb657c9..4b672499f20d 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -262,6 +262,32 @@ properties: is supported. For example, this is used in case of SGMII and MAC2MAC connection. + snps,pbl: +description: + Programmable Burst Length (tx and rx) +$ref: /schemas/types.yaml#definitions/uint32 +enum: [2, 4, 8] + + snps,txpbl: +description: + Tx Programmable Burst Length. If set, DMA tx will use this + value rather than snps,pbl. +$ref: /schemas/types.yaml#definitions/uint32 +enum: [2, 4, 8] + + snps,rxpbl: +description: + Rx Programmable Burst Length. If set, DMA rx will use this + value rather than snps,pbl. +$ref: /schemas/types.yaml#definitions/uint32 +enum: [2, 4, 8] + + snps,no-pbl-x8: +$ref: /schemas/types.yaml#definitions/flag +description: + Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core + rev < 3.50, don\'t multiply the values by 4. + mdio: type: object description: @@ -287,49 +313,6 @@ dependencies: allOf: - $ref: "ethernet-controller.yaml#" - - if: - properties: -compatible: - contains: -enum: - - allwinner,sun7i-a20-gmac - - allwinner,sun8i-a83t-emac - - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac - - allwinner,sun8i-v3s-emac - - allwinner,sun50i-a64-emac - - snps,dwxgmac - - snps,dwxgmac-2.10 - - st,spear600-gmac - -then: - properties: -snps,pbl: - description: -Programmable Burst Length (tx and rx) - $ref: /schemas/types.yaml#definitions/uint32 - enum: [2, 4, 8] - -snps,txpbl: - description: -Tx Programmable Burst Length. If set, DMA tx will use this -value rather than snps,pbl. - $ref: /schemas/types.yaml#definitions/uint32 - enum: [2, 4, 8] - -snps,rxpbl: - description: -Rx Programmable Burst Length. If set, DMA rx will use this -value rather than snps,pbl. - $ref: /schemas/types.yaml#definitions/uint32 - enum: [2, 4, 8] - -snps,no-pbl-x8: - $ref: /schemas/types.yaml#definitions/flag - description: -Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core -rev < 3.50, don\'t multiply the values by 4. - - if: properties: compatible: -- 2.29.2
[PATCH -next] scsi: qla2xxx: tcm_qla2xxx: fix spelling mistakes
Signed-off-by: Zheng Yongjun --- drivers/scsi/qla2xxx/tcm_qla2xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c b/drivers/scsi/qla2xxx/tcm_qla2xxx.c index 61017acd3458..02d88117f423 100644 --- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c +++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c @@ -1474,7 +1474,7 @@ static int tcm_qla2xxx_check_initiator_node_acl( return -EINVAL; } /* -* Format the FCP Initiator port_name into colon seperated values to +* Format the FCP Initiator port_name into colon separated values to * match the format by tcm_qla2xxx explict ConfigFS NodeACLs. */ memset(&port_name, 0, 36); -- 2.22.0
Re: [PATCH] mm/memory_hotplug: quieting offline operation
Le 12/12/2020 à 16:04, Souptick Joarder a écrit :
On Fri, Dec 11, 2020 at 8:32 PM Laurent Dufour wrote:
On PowerPC, when dymically removing memory from a system we can see in the
console a
lot of messages like this:
[ 186.575389] Offlined Pages 4096
Is it specific to PowerPC ?
No, this applies to all architectures, but this is surfacing a bit more on
PowerPC where the memory block size is set to 256MB currently by the firmware.
This message is displayed on each LMB (256MB) removed, which means that we
removing 1TB of memory, this message is displayed 4096 times.
Moving it to DEBUG to not flood the console.
Signed-off-by: Laurent Dufour
---
mm/memory_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index b44d4c7ba73b..c47a53a16782 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1587,7 +1587,7 @@ int __ref offline_pages(unsigned long start_pfn, unsigned
long nr_pages)
/* Mark all sections offline and remove free pages from the buddy. */
__offline_isolated_pages(start_pfn, end_pfn);
- pr_info("Offlined Pages %ld\n", nr_pages);
+ pr_debug("Offlined Pages %ld\n", nr_pages);
/*
* The memory sections are marked offline, and the pageblock flags
--
2.29.2
Re: [PATCH v5 2/3] usb: serial: xr_serial: Add gpiochip support
On Mon, Dec 14, 2020 at 10:19:07AM +0100, Linus Walleij wrote: > On Mon, Dec 14, 2020 at 9:58 AM Johan Hovold wrote: > > On Sat, Dec 12, 2020 at 01:03:32AM +0100, Linus Walleij wrote: > > > > If I google for the phrase "Detected name collision for GPIO name" > > > I just find the code, our discussions and some USB serial devices > > > warning about this so far. > > > > > > Maybe we should just make a patch to disallow it? > > > > That would make it impossible to provide name lines on hotpluggable > > controllers, which would be nice to support. > > I merged a patch for this now, let's tighten this loose end up. > > Also: thanks for poking me about this, I should have looked into > this ages ago :/ focus you know... Yeah, tell me about it. :/ Johan
Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
On Fri, Dec 11, 2020 at 10:50:02PM +, Mel Gorman wrote: > > > The third potential downside is that the SMT sibling is not guaranteed to > > > be checked due to SIS_PROP throttling but in the old code, that would have > > > been checked by select_idle_smt(). That might result in premature stacking > > > of runnable tasks on the same CPU. Similarly, as __select_idle_core may > > > find multiple idle candidates, it will not pick the targets SMT sibling > > > if it is idle like select_idle_smt would have. > > > > > > That said, I am skeptical that select_idle_smt() matters all that often. > > > > This, I didn't really believe in it either. > > > > Good because I think any benefit from select_idle_smt is so marginal > that it should be ignored if the full scan is simpler overall. Perhaps we should start out with a simple patch removing that pass.. That should show, what, if anything, the effect of it is.
Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
On Mon, Dec 14, 2020 at 09:11:29AM +0100, Vincent Guittot wrote:
> On Fri, 11 Dec 2020 at 23:50, Mel Gorman wrote:
> > I originally did something like that on purpose too but Vincent called
> > it out so it is worth mentioning now to avoid surprises. That said, I'm
> > at the point where anything SIS-related simply needs excessive exposure
> > because no matter what it does, someone is unhappy with it.
>
> Yeah, I don't like extending the idle core search loop for something
> that is not related to the idle core search. This adds more work out
> of control of the sis_prop. So I'm still against hiding some idle cpu
> search in idle core search.
The idea, of course, is to do less. The current code is pretty crap in
that it will do a whole bunch of things multiple times.
Also, a possible follow up, would be something like the below (and
remove all the sds->has_idle_cores crud), which brings core scanning
under SIS_PROP.
But it all needs lots of benchmarking :/
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6095,6 +6095,9 @@ static inline bool test_idle_cores(int c
static inline int __select_idle_core(int core, struct cpumask *cpus, int
*idle_cpu)
{
+ if (idle_cpu && (available_idle_cpu(core) || sched_idle_cpu(cpu))
+ *idle_cpu = core;
+
return -1;
}
@@ -6109,7 +6112,6 @@ static int select_idle_cpu(struct task_s
{
struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
int this = smp_processor_id();
- bool smt = test_idle_cores(this, false);
int i, cpu, idle_cpu = -1, nr = INT_MAX;
struct sched_domain *this_sd;
u64 time;
@@ -6120,7 +6122,7 @@ static int select_idle_cpu(struct task_s
cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
- if (sched_feat(SIS_PROP) && !smt) {
+ if (sched_feat(SIS_PROP)) {
u64 avg_cost, avg_idle, span_avg;
/*
@@ -6140,26 +6142,17 @@ static int select_idle_cpu(struct task_s
}
for_each_cpu_wrap(cpu, cpus, target) {
- if (smt) {
- i = __select_idle_core(cpu, cpus, &idle_cpu);
- if ((unsigned)i < nr_cpumask_bits)
- return i;
-
- } else {
- if (!--nr)
- return -1;
-
- if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
- idle_cpu = cpu;
- break;
- }
+ if (!--nr)
+ break;
+
+ i = __select_idle_core(cpu, cpus, &idle_cpu);
+ if ((unsigned)i < nr_cpumask_bits) {
+ idle_cpu = i;
+ break;
}
}
- if (smt)
- set_idle_cores(this, false);
-
- if (sched_feat(SIS_PROP) && !smt) {
+ if (sched_feat(SIS_PROP)) {
time = cpu_clock(this) - time;
update_avg(&this_sd->avg_scan_cost, time);
}
[GIT PULL] m68k updates for 5.11
Hi Linus,
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
tags/m68k-for-v5.11-tag1
for you to fetch changes up to 2ae92e8b9b7eb042ccb7e9fc7ea9431f211a1bd3:
MAINTAINERS: Update m68k Mac entry (2020-12-07 10:48:16 +0100)
m68k updates for v5.11
- Fix WARNING splat in pmac_zilog driver,
- Fix ADB input device regression,
- Assume maintainership for adb-iop and via-macii,
- Minor fixes and improvements,
- Defconfig updates.
Thanks for pulling!
Arnd Bergmann (1):
m68k: Avoid xchg() warning
Finn Thain (8):
m68k: mac: Refactor iop_preinit() and iop_init()
m68k: mac: Remove dead code
m68k: mac: Remove redundant VIA register writes
m68k: mac: Update Kconfig help
m68k: Fix WARNING splat in pmac_zilog driver
macintosh/adb-iop: Always wait for reply message from IOP
macintosh/adb-iop: Send correct poll command
MAINTAINERS: Update m68k Mac entry
Geert Uytterhoeven (2):
m68k: defconfig: Update defconfigs for v5.10-rc1
m68k: defconfig: Enable KUnit tests
Laurent Vivier (1):
m68k: Remove unused mach_max_dma_address
Youling Tang (2):
m68k: Drop redundant NOTES in link script
m68k: Add a missing ELF_DETAILS in link script
MAINTAINERS | 2 ++
arch/m68k/Kconfig.machine| 8 ++
arch/m68k/amiga/config.c | 8 --
arch/m68k/apollo/config.c| 1 -
arch/m68k/atari/config.c | 1 -
arch/m68k/bvme6000/config.c | 1 -
arch/m68k/configs/amiga_defconfig| 9 --
arch/m68k/configs/apollo_defconfig | 9 --
arch/m68k/configs/atari_defconfig| 9 --
arch/m68k/configs/bvme6000_defconfig | 9 --
arch/m68k/configs/hp300_defconfig| 9 --
arch/m68k/configs/mac_defconfig | 9 --
arch/m68k/configs/multi_defconfig| 9 --
arch/m68k/configs/mvme147_defconfig | 9 --
arch/m68k/configs/mvme16x_defconfig | 9 --
arch/m68k/configs/q40_defconfig | 9 --
arch/m68k/configs/sun3_defconfig | 9 --
arch/m68k/configs/sun3x_defconfig| 9 --
arch/m68k/hp300/config.c | 1 -
arch/m68k/include/asm/cmpxchg.h | 10 +++
arch/m68k/include/asm/machdep.h | 1 -
arch/m68k/kernel/setup_mm.c | 1 -
arch/m68k/kernel/vmlinux-nommu.lds | 3 +-
arch/m68k/kernel/vmlinux-std.lds | 3 +-
arch/m68k/kernel/vmlinux-sun3.lds| 2 +-
arch/m68k/mac/config.c | 26 ++---
arch/m68k/mac/iop.c | 54 --
arch/m68k/mac/via.c | 21 --
arch/m68k/mvme147/config.c | 1 -
arch/m68k/mvme16x/config.c | 1 -
arch/m68k/q40/config.c | 5
arch/m68k/sun3x/config.c | 2 --
drivers/macintosh/adb-iop.c | 56
drivers/tty/serial/pmac_zilog.c | 14 +
34 files changed, 171 insertions(+), 159 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On Mon, Dec 14, 2020 at 5:02 AM Vijayanand Jitta wrote:
>
>
>
> On 12/11/2020 6:55 PM, Alexander Potapenko wrote:
> > On Fri, Dec 11, 2020 at 1:45 PM Vijayanand Jitta
> > wrote:
> >>
> >>
> >>
> >> On 12/11/2020 2:06 PM, Alexander Potapenko wrote:
> >>> On Thu, Dec 10, 2020 at 6:01 AM wrote:
>
> From: Yogesh Lal
>
> Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE.
>
> Aim is to have configurable value for STACK_HASH_SIZE, so that one
> can configure it depending on usecase there by reducing the static
> memory overhead.
>
> One example is of Page Owner, default value of STACK_HASH_SIZE lead
> stack depot to consume 8MB of static memory. Making it configurable
> and use lower value helps to enable features like CONFIG_PAGE_OWNER
> without any significant overhead.
> >>>
> >>> Can we go with a static CONFIG_ parameter instead?
> >>> Guess most users won't bother changing the default anyway, and for
> >>> CONFIG_PAGE_OWNER users changing the size at boot time is not strictly
> >>> needed.
> >>>
> >> Thanks for review.
> >>
> >> One advantage of having run time parameter is we can simply set it to a
> >> lower value at runtime if page_owner=off thereby reducing the memory
> >> usage or use default value if we want to use page owner so, we have some
> >> some flexibility here. This is not possible with static parameter as we
> >> have to have some predefined value.
> >
> > If we are talking about a configuration in which page_owner is the
> > only stackdepot user in the system, then for page_owner=off it
> > probably makes more sense to disable stackdepot completely instead of
> > setting it to a lower value. This is a lot easier to do in terms of
> > correctness.
> > But if there are other users (e.g. KASAN), their stackdepot usage may
> > actually dominate that of page_owner.
> >
> -static struct stack_record *stack_table[STACK_HASH_SIZE] = {
> - [0 ... STACK_HASH_SIZE - 1] = NULL
> +static unsigned int stack_hash_order = 20;
> >>>
> >>> Please initialize with MAX_STACK_HASH_ORDER instead.
> >>>
> >>
> >> Sure, will update this.
> >>
> >
> >
> +
> +static int __init init_stackdepot(void)
> +{
> + size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *));
> +
> + stack_table = vmalloc(size);
> + memcpy(stack_table, stack_table_def, size);
> >>>
> >>> Looks like you are assuming stack_table_def already contains some data
> >>> by this point.
> >>> But if STACK_HASH_SIZE shrinks this memcpy() above will just copy some
> >>> part of the table, whereas the rest will be lost.
> >>> We'll need to:
> >>> - either explicitly decide we can afford losing this data (no idea how
> >>> bad this can potentially be),
> >>> - or disallow storing anything prior to full stackdepot initialization
> >>> (then we don't need stack_table_def),
> >>> - or carefully move all entries to the first part of the table.
> >>>
> >>> Alex
> >>>
> >>
> >> The hash for stack_table_def is computed using the run time parameter
> >> stack_hash_order, though stack_table_def is a bigger array it will only
> >> use the entries that are with in the run time configured STACK_HASH_SIZE
> >> range. so, there will be no data loss during copy.
> >
> > Do we expect any data to be stored into stack_table_def before
> > setup_stack_hash_order() is called?
> > If the answer is no, then we could probably drop stack_table_def and
> > allocate the table right in setup_stack_hash_order()?
> >
>
> Yes, we do see an allocation from stack depot even before init is called
> from kasan, thats the reason for having stack_table_def.
> This is the issue reported due to that on v2, so i added stack_table_def.
> https://lkml.org/lkml/2020/12/3/839
But at that point STACK_HASH_SIZE is still equal to 1L <<
MAX_STACK_HASH_ORDER, isn't it?
Then we still need to take care of the records that fit into the
bigger array, but not the smaller one.
> Thanks,
> Vijay
>
> >> Thanks,
> >> Vijay
> >>
> >> --
> >> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> >> member of Code Aurora Forum, hosted by The Linux Foundation
> >
> >
> >
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of Code Aurora Forum, hosted by The Linux Foundation
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Re: [PATCH v12 00/31] Speculative page faults
Le 14/12/2020 à 03:03, Joel Fernandes a écrit : On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote: [..] Hi Laurent, We merged SPF v11 and some patches from v12 into our platforms. After several experiments, we observed SPF has obvious improvements on the launch time of applications, especially for those high-TLP ones, # launch time of applications(s): package version w/ SPF w/o SPF improve(%) -- Baidu maps10.13.3 0.887 0.98 9.49 Taobao8.4.0.35 1.227 1.2935.10 Meituan 9.12.401 1.107 1.54328.26 WeChat7.0.32.353 2.68 12.20 Honor of Kings1.43.1.6 6.636.7131.24 That's great news, thanks for reporting this! By the way, we have verified our platforms with those patches and achieved the goal of mass production. Another good news! For my information, what is your targeted hardware? Cheers, Laurent. Hi Laurent, Our targeted hardware belongs to ARM64 multi-core series. Hello! I was trying to develop an intuition about why does SPF give improvement for you on small CPU systems. This is just a high-level theory but: 1. Assume the improvement is because of elimination of "blocking" on mmap_sem. Could it be that the mmap_sem is acquired in write-mode unnecessarily in some places, thus causing blocking on mmap_sem in other paths? If so, is it feasible to convert such usages to acquiring them in read-mode? That's correct, and the goal of this series is to try not holding the mmap_sem in read mode during page fault processing. Converting mmap_sem holder from write to read mode is not so easy and that work as already been done in some places. If you think there are areas where this could be done, you're welcome to send patches fixing that. 2. Assume the improvement is because of lesser read-side contention on mmap_sem. On small CPU systems, I would not expect reducing cache-line bouncing to give such a dramatic improvement in performance as you are seeing. I don't think cache line bouncing reduction is the main sourcec of performance improvement, I would rather think this is the lower part here. I guess this is mainly because during loading time a lot of page fault is occuring and thus SPF is reducing the contention on the mmap_sem. Thanks for any insight on this! - Joel
Re: [PATCH v2 02/21] dt-bindings: pinctrl: Add Allwinner H616 compatible strings
On Fri, Dec 11, 2020 at 01:19:15AM +, Andre Przywara wrote: > A new SoC, a new compatible string. > Also we were too miserly with just allowing seven interrupt banks. > > Signed-off-by: Andre Przywara > --- > .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 18 -- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml > b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml > index 5240487dfe50..292b05d9ed08 100644 > --- > a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml > +++ > b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml > @@ -53,6 +53,8 @@ properties: >- allwinner,sun50i-h5-pinctrl >- allwinner,sun50i-h6-pinctrl >- allwinner,sun50i-h6-r-pinctrl > + - allwinner,sun50i-h616-pinctrl > + - allwinner,sun50i-h616-r-pinctrl >- allwinner,suniv-f1c100s-pinctrl >- nextthing,gr8-pinctrl > > @@ -61,7 +63,7 @@ properties: > >interrupts: > minItems: 1 > -maxItems: 7 > +maxItems: 8 > description: >One interrupt per external interrupt bank supported on the >controller, sorted by bank number ascending order. > @@ -91,7 +93,7 @@ properties: >bank found in the controller > $ref: /schemas/types.yaml#/definitions/uint32-array > minItems: 1 > -maxItems: 5 > +maxItems: 8 > > patternProperties: ># It's pretty scary, but the basic idea is that: > @@ -145,6 +147,18 @@ allOf: ># boards are defining it at the moment so it would generate a lot of ># warnings. > > + - if: > + properties: > +compatible: > + enum: > +- allwinner,sun50i-h616-pinctrl > + > +then: > + properties: > +interrupts: > + minItems: 8 > + maxItems: 8 > + You don't need to have both if they are equals, and in this particular case we already check that the maximum is 8 so there's no need to repeat that check here. Maxime signature.asc Description: PGP signature
Re: [PATCH] mm/vmalloc: Fix unlock order in s_stop()
On 13.12.20 19:08, Waiman Long wrote:
> When multiple locks are acquired, they should be released in reverse
> order. For s_start() and s_stop() in mm/vmalloc.c, that is not the
> case.
>
> s_start: mutex_lock(&vmap_purge_lock); spin_lock(&vmap_area_lock);
> s_stop : mutex_unlock(&vmap_purge_lock); spin_unlock(&vmap_area_lock);
>
> This unlock sequence, though allowed, is not optimal. If a waiter is
> present, mutex_unlock() will need to go through the slowpath of waking
> up the waiter with preemption disabled. Fix that by releasing the
> spinlock first before the mutex.
>
> Fixes: e36176be1c39 ("mm/vmalloc: rework vmap_area_lock")
I'm not sure if this classifies as "Fixes". As you correctly state "is
not optimal". But yeah, releasing a spinlock after releasing a mutex
looks weird already.
> Signed-off-by: Waiman Long
> ---
> mm/vmalloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 6ae491a8b210..75913f685c71 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3448,11 +3448,11 @@ static void *s_next(struct seq_file *m, void *p,
> loff_t *pos)
> }
>
> static void s_stop(struct seq_file *m, void *p)
> - __releases(&vmap_purge_lock)
> __releases(&vmap_area_lock)
> + __releases(&vmap_purge_lock)
> {
> - mutex_unlock(&vmap_purge_lock);
> spin_unlock(&vmap_area_lock);
> + mutex_unlock(&vmap_purge_lock);
> }
>
> static void show_numa_info(struct seq_file *m, struct vm_struct *v)
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH v2 03/21] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
On Fri, Dec 11, 2020 at 01:19:16AM +, Andre Przywara wrote: > + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "h_i2s2"),/* MCLK */ > + SUNXI_FUNCTION(0x3, "clock"), /* X32KFOUT */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 10)), /* PG_EINT10 */ It looks like there's no i2s vs h_i2s issue anymore? Maybe we can just do s/h_i2s/i2s > + SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 3), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac0"), /* ERXD0 */ > + SUNXI_FUNCTION(0x3, "dmic"), /* DATA2 */ > + SUNXI_FUNCTION(0x4, "h_i2s0"),/* DO0 */ > + SUNXI_FUNCTION(0x5, "h_i2s0_a"), /* DI1 */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 7, 3)), /* PI_EINT3 */ The way we dealt with this for the A100 is that we put the function as a suffix which is more natural, so h_i2s0_dout0 and h_i2s0_din1 Maxime signature.asc Description: PGP signature
Re: [PATCH] staging: greybus: audio: Fix possible leak free widgets in gbaudio_dapm_free_controls
On Fri, Dec 11, 2020 at 08:29:22PM +0800, wanghai (M) wrote: > > 在 2020/12/8 17:35, Johan Hovold 写道: > > On Sat, Dec 05, 2020 at 06:38:27PM +0800, Wang Hai wrote: > >> In gbaudio_dapm_free_controls(), if one of the widgets is not found, an > >> error > >> will be returned directly, which will cause the rest to be unable to be > >> freed, > >> resulting in leak. > >> > >> This patch fixes the bug. If if one of them is not found, just skip and > >> free the others. > > Apart from the typo, please break your lines at 72 columns or so (not > > needed for the Fixes tag). > > Thanks for review, Do I need to send a v2 patch to change the commit msg? I'm not sure your mail reached the lists since it contains HTML, but to answer your question: Please do resend. If you can make the maintainers' life any easier that's always a good idea. You should include the Reviewed-by tags you've gotten so far when resending as long as you only update the commit message. Johan
Re: [PATCH AUTOSEL 4.14 2/8] drm/nouveau: make sure ret is initialized in nouveau_ttm_io_mem_reserve
Hi Sasha, please don't apply this patch to any older kernel. The fix was only needed for a patch which went in with the 5.10 pull request. Thanks, Christian. Am 12.12.20 um 17:08 schrieb Sasha Levin: From: Christian König [ Upstream commit aea656b0d05ec5b8ed5beb2f94c4dd42ea834e9d ] This wasn't initialized for pre NV50 hardware. Signed-off-by: Christian König Reported-and-Tested-by: Mark Hounschell Reviewed-by: Karol Herbst Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F84298%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C664e6201322444b319e908d89eb83eda%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637433861463180140%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OQ2BSmlDxz%2BPGq6aDpQBaXjQgO0wdt6y6KlCzIIFVso%3D&reserved=0 Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nouveau_bo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index e427f80344c4d..fddbe66935464 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1375,6 +1375,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *reg) nvkm_vm_map(&mem->bar_vma, mem); reg->bus.offset = mem->bar_vma.offset; } + ret = 0; break; default: return -EINVAL;
Re: [PATCH 2/9] misc: Add Xilinx AI engine device driver
On Fri, Dec 11, 2020 at 06:27:05PM -0800, Jiaying Liang wrote: > > On 12/9/20 4:47 AM, Daniel Vetter wrote: > > On Tue, Dec 08, 2020 at 11:54:57AM -0800, Jiaying Liang wrote: > > > On 12/8/20 9:12 AM, Nicolas Dufresne wrote: > > > > Le mercredi 18 novembre 2020 à 00:06 -0800, Wendy Liang a écrit : > > > > > Create AI engine device/partition hierarchical structure. > > > > > > > > > > Each AI engine device can have multiple logical partitions(groups of > > > > > AI > > > > > engine tiles). Each partition is column based and has its own node ID > > > > > in the system. AI engine device driver manages its partitions. > > > > > > > > > > Applications can access AI engine partition through the AI engine > > > > > partition driver instance. AI engine registers write is moved to > > > > > kernel > > > > > as there are registers in the AI engine array needs privilege > > > > > permission. > > > > Hi there, it's nice to see an effort to upstream an AI driver. I'm a > > > > little > > > > worried this driver is not obvious to use from it's source code itself. > > > > So you > > > > have reference to some Open Source code that demonstrate it's usage ? > > > We have AI engine library which provides a cross platforms APIs for other > > > > > > libraries/application to use the hardware. Here is the source code: > > > > > > https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/aienginev2/src > > > > > > The cross platforms AI engine library runs in LInux userspace it defines > > > how > > > to > > > > > > configure, and the kernel driver controls if what can be access and manage > > > errors from device. > > So I kinda ignored this driver submission because in the past all these AI > > drivers had at best incomplete open source (usually the compiler is > > closed, often also large parts of the runtime). I think yours would be the > > first that breaks this trend, is that really the case? I.e. I could make > > full use of this hw without any closed source bits to run DNN workloads > > and things like that? > AI engine can be used for signaling processing or high performance computing > > the kernel driver works on the AI engine software library which I mentioned > above, > > which will be used by Xilinx runtime: > https://xilinx.github.io/XRT/2020.2/html/index.html > > Xilinx runtime is a layer for acceleration libraries or applications to use > Xilinx accelerators. Hm maybe I'm mixing things up, but it feels like there was a discussion about the xilinx runtime in the past with a drm driver even. The hangup was that the runtime is all open, but the offline compiler isn't. Is that still the case, or am I mixing things up here a bit? > e.g. it has OpenCL implementation > > If that's the case then I think there's nothing stopping us from doing the > > right thing and merging this driver into the right subsystem: The > > subsystem for accelerators which their own memory and who want dma-buf > > integration is drivers/gpu, not drivers/misc. > > The AI engine kernel driver is used for device runtime configuration update, > > and runtime monitoring, such as async errors detection. The buffer > management > > is out of the AI engine driver, but it is covered by Xilinx runtime: > > https://github.com/Xilinx/XRT/tree/master/src/runtime_src/core/edge/drm/zocl > > AI engine driver imports the DMA buf. > > > The AI engine device is quite different to the GPU devices. The AI engine > > operations are still needs driver specific ioctls. > > We have more than 100 cores tiles, each tiles functions can be defined at > compilation > > time, at runtime, we load the configuration (application defined I/O > commands) to > > configure each tiles registers to set up routing, set up DMAs, configure > local memories, > > and enable the tiles. Setting up DMA does sound like (buffer) memory management to me. Note that the memory management that the kernel does does not necessarily translate directly to client api buffers like opencl has. At least for gpu drivers you have memory management in both the kernel and userspace. > As the AI engine device hardware is different to the GPUs, > > we are not able to make use of functions abstracted for GPUs, and we don't > manage the > > buffers in this driver. I am not sure if it is ok to add the driver to > drivers/gpu but not > > using abstractions from the GPU abstraction. > > > There is another reply to the patch series to ask for clarification on the > overview of the > > driver, and I had some discussions with other team members. I will reply to > that email > > to provide more details on overall how this driver is used. Yeah I think that should help with understanding what's the best option here. -Daniel > > Any suggestions on how to fit the driver in the drivers/gpu or other drivers > framework > > will be much appreciated. > > > Thanks, > > Wendy > > > Apologies that I'm jumping with the really big arch review when v3 is > > already
Re: [PATCH v5 0/3] Add support for MaxLinear/Exar USB to serial converters
On Tue, Dec 08, 2020 at 04:21:28PM +0530, Manivannan Sadhasivam wrote: > On Sun, Nov 22, 2020 at 10:38:19PM +0530, Manivannan Sadhasivam wrote: > > From: Manivannan Sadhasivam > > > > Hello, > > > > This series adds support for MaxLinear/Exar USB to serial converters. > > This driver only supports XR21V141X series but it can easily be extended > > to other series in future. > > > > This driver is inspired from the initial one submitted by Patong Yang: > > https://lore.kernel.org/linux-usb/20180404070634.nhspvmxcjwfgjkcv@advantechmxl-desktop > > > > While the initial driver was a custom tty USB driver exposing whole > > new serial interface ttyXRUSBn, this version is completely based on USB > > serial core thus exposing the interfaces as ttyUSBn. This will avoid > > the overhead of exposing a new USB serial interface which the userspace > > tools are unaware of. > > > > This series has been tested with Hikey970 board hosting XR21V141X chip. > > > > NOTE: I've removed all reviews and tested-by tags as the code has gone > > through substantial rework. Greg, Linus, Mauro please consider reviewing > > again. > > > > Any chance to get this series into v5.11? No, sorry, reviewing this one again will be at the top of my list after the merge window opens. Hopefully we'll have reached some conclusions regarding the line names by then too. Johan
Re: [PATCH v2 15/21] phy: sun4i-usb: Add support for the H616 USB PHY
On Fri, Dec 11, 2020 at 01:19:28AM +, Andre Przywara wrote: > The USB PHY used in the Allwinner H616 SoC inherits some traits from its > various predecessors: it has four full PHYs like the H3, needs some > extra bits to be set like the H6, and clears a different bit in the > PMU_UNK1 register like the A100. > > Name all those properties in a new config struct and assign a new > compatible name to it. > > Signed-off-by: Andre Przywara It looks like you forgot the binding for that one? Maxime signature.asc Description: PGP signature
[PATCH v2] scsi: sd: remove obsolete variable in sd_remove()
Commit 140ea3bbf39a ("sd: use __register_blkdev to avoid a modprobe for an
unregistered dev_t") removed blk_register_region(devt, ...) in sd_remove()
and since then, devt is unused in sd_remove().
Hence, make W=1 warns:
drivers/scsi/sd.c:3516:8:
warning: variable 'devt' set but not used [-Wunused-but-set-variable]
Simply remove this obsolete variable.
Reviewed-by: Christoph Hellwig
Reviewed-by: Nathan Chancellor
Acked-by: Martin K. Petersen
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201113, next-20201211
The patch was submitted for inclusion in scsi:
https://lore.kernel.org/lkml/20201116070035.11870-1-lukas.bulw...@gmail.com/
v1 -> v2:
Christoph and Nathan reviewed, and I added the tags here.
Martin asked the patch to go through block.
Jens, can you please pick this minor non-urgent clean-up patch?
drivers/scsi/sd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 679c2c025047..21675a98620d 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3510,10 +3510,8 @@ static int sd_probe(struct device *dev)
static int sd_remove(struct device *dev)
{
struct scsi_disk *sdkp;
- dev_t devt;
sdkp = dev_get_drvdata(dev);
- devt = disk_devt(sdkp->disk);
scsi_autopm_get_device(sdkp->device);
async_synchronize_full_domain(&scsi_sd_pm_domain);
--
2.17.1
[PATCH v7 1/4] dt-bindings: Document the hi3559a clock bindings
Add DT bindings documentation for hi3559a SoC clock.
Signed-off-by: Dongjiu Geng
---
.../clock/hisilicon,hi3559av100-clock.yaml| 59 +++
include/dt-bindings/clock/hi3559av100-clock.h | 165 ++
2 files changed, 224 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml
create mode 100644 include/dt-bindings/clock/hi3559av100-clock.h
diff --git
a/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml
b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml
new file mode 100644
index ..3ceb29cec704
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/hisilicon,hi3559av100-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon SOC Clock for HI3559AV100
+
+maintainers:
+ - Dongjiu Geng
+
+description: |
+ Hisilicon SOC clock control module which supports the clocks, resets and
+ power domains on HI3559AV100.
+
+ See also:
+dt-bindings/clock/hi3559av100-clock.h
+
+properties:
+ compatible:
+enum:
+ - hisilicon,hi3559av100-clock
+ - hisilicon,hi3559av100-shub-clock
+
+ reg:
+minItems: 1
+maxItems: 2
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 2
+description: |
+ First cell is reset request register offset.
+ Second cell is bit offset in reset request register.
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+clock-controller@1201 {
+compatible = "hisilicon,hi3559av100-clock";
+#clock-cells = <1>;
+#reset-cells = <2>;
+reg = <0x0 0x1201 0x0 0x1>;
+};
+};
+...
diff --git a/include/dt-bindings/clock/hi3559av100-clock.h
b/include/dt-bindings/clock/hi3559av100-clock.h
new file mode 100644
index ..5fe7689010a0
--- /dev/null
+++ b/include/dt-bindings/clock/hi3559av100-clock.h
@@ -0,0 +1,165 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later or BSD-2-Clause */
+/*
+ * Copyright (c) 2019-2020, Huawei Tech. Co., Ltd.
+ *
+ * Author: Dongjiu Geng
+ */
+
+#ifndef __DTS_HI3559AV100_CLOCK_H
+#define __DTS_HI3559AV100_CLOCK_H
+
+/* fixed rate*/
+#define HI3559AV100_FIXED_1188M 1
+#define HI3559AV100_FIXED_1000M 2
+#define HI3559AV100_FIXED_842M 3
+#define HI3559AV100_FIXED_792M 4
+#define HI3559AV100_FIXED_750M 5
+#define HI3559AV100_FIXED_710M 6
+#define HI3559AV100_FIXED_680M 7
+#define HI3559AV100_FIXED_667M 8
+#define HI3559AV100_FIXED_631M 9
+#define HI3559AV100_FIXED_600M 10
+#define HI3559AV100_FIXED_568M 11
+#define HI3559AV100_FIXED_500M 12
+#define HI3559AV100_FIXED_475M 13
+#define HI3559AV100_FIXED_428M 14
+#define HI3559AV100_FIXED_400M 15
+#define HI3559AV100_FIXED_396M 16
+#define HI3559AV100_FIXED_300M 17
+#define HI3559AV100_FIXED_250M 18
+#define HI3559AV100_FIXED_198M 19
+#define HI3559AV100_FIXED_187p5M20
+#define HI3559AV100_FIXED_150M 21
+#define HI3559AV100_FIXED_148p5M22
+#define HI3559AV100_FIXED_125M 23
+#define HI3559AV100_FIXED_107M 24
+#define HI3559AV100_FIXED_100M 25
+#define HI3559AV100_FIXED_99M 26
+#define HI3559AV100_FIXED_74p25M27
+#define HI3559AV100_FIXED_72M 28
+#define HI3559AV100_FIXED_60M 29
+#define HI3559AV100_FIXED_54M 30
+#define HI3559AV100_FIXED_50M 31
+#define HI3559AV100_FIXED_49p5M 32
+#define HI3559AV100_FIXED_37p125M 33
+#define HI3559AV100_FIXED_36M 34
+#define HI3559AV100_FIXED_32p4M 35
+#define HI3559AV100_FIXED_27M 36
+#define HI3559AV100_FIXED_25M 37
+#define HI3559AV100_FIXED_24M 38
+#define HI3559AV100_FIXED_12M 39
+#define HI3559AV100_FIXED_3M40
+#define HI3559AV100_FIXED_1p6M 41
+#define HI3559AV100_FIXED_400K 42
+#define HI3559AV100_FIXED_100K 43
+#define HI3559AV100_FIXED_200M 44
+#define HI3559AV100_FIXED_75M 75
+
+#define HI3559AV100_I2C0_CLK50
+#define HI3559AV100_I2C1_CLK51
+#define HI3559AV100_I2C2_CLK52
+#define HI3559AV100_I2C3_CLK53
+#define HI3559AV100_I2C4_CLK54
+#define HI3559AV100_I2C5_CLK55
+#define HI3559AV100_I2C6_CLK56
+#define HI3559AV100_I2C7_CLK57
+#define HI3559AV100_I2C8_CLK58
+#define HI3559AV100_I2C9_CLK59
+#define HI3559AV100_I2C10_CLK 60
+#define HI3559AV100_I2C11_CLK 61
+
+#define HI3559AV100_SPI0_CLK62
+#define HI3559AV100_SPI1_CLK63
+#define HI3559AV100_SPI2_CLK64
+#define HI3559AV100_SPI3_CLK65
+#define HI3559AV100_SPI4_CLK66
+#define HI3559AV100_SPI5_CLK67
+#define HI3559AV100_SPI6_CLK68
+
[PATCH v7 0/4] Enable Hi3559A SOC clock and HiSilicon Hiedma Controller
v6->v7: 1. rename hisi,misc-control to hisi,misc-control to hisilicon,misc-control v5->v6: 1. Drop #size-cells and #address-cell in the hisilicon,hi3559av100-clock.yaml 2. Add discription for #reset-cells in the hisilicon,hi3559av100-clock.yaml 3. Remove #clock-cells in hisilicon,hiedmacv310.yaml 4. Merge property misc_ctrl_base and misc_regmap together for hiedmacv310 driver v4->v5: 1. change the patch author mail name v3->v4: 1. fix the 'make dt_binding_check' issues. 2. Combine the 'Enable HiSilicon Hiedma Controller' series patches to this series. 3. fix the 'make dt_binding_check' issues in 'Enable HiSilicon Hiedma Controller' patchset v2->v3: 1. change dt-bindings documents from txt to yaml format. 2. Add SHUB clock to access the devices of m7 Dongjiu Geng (4): dt-bindings: Document the hi3559a clock bindings clk: hisilicon: Add clock driver for hi3559A SoC dt: bindings: dma: Add DT bindings for HiSilicon Hiedma Controller dmaengine: dma: Add Hiedma Controller v310 Device Driver .../clock/hisilicon,hi3559av100-clock.yaml| 59 + .../bindings/dma/hisilicon,hiedmacv310.yaml | 94 ++ drivers/clk/hisilicon/Kconfig |7 + drivers/clk/hisilicon/Makefile|1 + drivers/clk/hisilicon/clk-hi3559a.c | 865 ++ drivers/dma/Kconfig | 14 + drivers/dma/Makefile |1 + drivers/dma/hiedmacv310.c | 1442 + drivers/dma/hiedmacv310.h | 136 ++ include/dt-bindings/clock/hi3559av100-clock.h | 165 ++ 10 files changed, 2784 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml create mode 100644 Documentation/devicetree/bindings/dma/hisilicon,hiedmacv310.yaml create mode 100644 drivers/clk/hisilicon/clk-hi3559a.c create mode 100644 drivers/dma/hiedmacv310.c create mode 100644 drivers/dma/hiedmacv310.h create mode 100644 include/dt-bindings/clock/hi3559av100-clock.h -- 2.17.1
[PATCH v7 4/4] dmaengine: dma: Add Hiedma Controller v310 Device Driver
Hisilicon EDMA Controller(EDMAC) directly transfers data
between a memory and a peripheral, between peripherals, or
between memories. This avoids the CPU intervention and reduces
the interrupt handling overhead of the CPU, this driver enables
this controller.
Reported-by: kernel test robot
Signed-off-by: Dongjiu Geng
---
drivers/dma/Kconfig | 14 +
drivers/dma/Makefile |1 +
drivers/dma/hiedmacv310.c | 1442 +
drivers/dma/hiedmacv310.h | 136
4 files changed, 1593 insertions(+)
create mode 100644 drivers/dma/hiedmacv310.c
create mode 100644 drivers/dma/hiedmacv310.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 90284ffda58a..3e5107120ff1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -327,6 +327,20 @@ config K3_DMA
Support the DMA engine for Hisilicon K3 platform
devices.
+config HIEDMACV310
+ tristate "Hisilicon EDMAC Controller support"
+ depends on ARCH_HISI
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ The Direction Memory Access(EDMA) is a high-speed data transfer
+ operation. It supports data read/write between peripherals and
+ memories without using the CPU.
+ Hisilicon EDMA Controller(EDMAC) directly transfers data between
+ a memory and a peripheral, between peripherals, or between memories.
+ This avoids the CPU intervention and reduces the interrupt handling
+ overhead of the CPU.
+
config LPC18XX_DMAMUX
bool "NXP LPC18xx/43xx DMA MUX for PL080"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 948a8da05f8b..28c7298b671e 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx_dma.o
obj-$(CONFIG_ST_FDMA) += st_fdma.o
obj-$(CONFIG_FSL_DPAA2_QDMA) += fsl-dpaa2-qdma/
+obj-$(CONFIG_HIEDMACV310) += hiedmacv310.o
obj-y += mediatek/
obj-y += qcom/
diff --git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..c0df5088a6a1
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1442 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2020, Huawei Tech. Co., Ltd.
+ *
+ * Author: Dongjiu Geng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hiedmacv310.h"
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+#define DRIVER_NAME "hiedmacv310"
+
+#define MAX_TSFR_LLIS 512
+#define EDMACV300_LLI_WORDS 64
+#define EDMACV300_POOL_ALIGN64
+#define BITS_PER_HALF_WORD 32
+
+struct hiedmac_lli {
+ u64 next_lli;
+ u32 reserved[5];
+ u32 count;
+ u64 src_addr;
+ u64 dest_addr;
+ u32 config;
+ u32 pad[3];
+};
+
+struct hiedmac_sg {
+ dma_addr_t src_addr;
+ dma_addr_t dst_addr;
+ size_t len;
+ struct list_head node;
+};
+
+struct transfer_desc {
+ struct virt_dma_desc virt_desc;
+ dma_addr_t llis_busaddr;
+ u64 *llis_vaddr;
+ u32 ccfg;
+ size_t size;
+ bool done;
+ bool cyclic;
+};
+
+enum edmac_dma_chan_state {
+ HIEDMAC_CHAN_IDLE,
+ HIEDMAC_CHAN_RUNNING,
+ HIEDMAC_CHAN_PAUSED,
+ HIEDMAC_CHAN_WAITING,
+};
+
+struct hiedmacv310_dma_chan {
+ bool slave;
+ int signal;
+ int id;
+ struct virt_dma_chan virt_chan;
+ struct hiedmacv310_phy_chan *phychan;
+ struct dma_slave_config cfg;
+ struct transfer_desc *at;
+ struct hiedmacv310_driver_data *host;
+ enum edmac_dma_chan_state state;
+};
+
+struct hiedmacv310_phy_chan {
+ unsigned int id;
+ void __iomem *base;
+ spinlock_t lock;
+ struct hiedmacv310_dma_chan *serving;
+};
+
+struct hiedmacv310_driver_data {
+ struct platform_device *dev;
+ struct dma_device slave;
+ struct dma_device memcpy;
+ void __iomem *base;
+ struct regmap *misc_regmap;
+ void __iomem *crg_ctrl;
+ struct hiedmacv310_phy_chan *phy_chans;
+ struct dma_pool *pool;
+ unsigned int misc_ctrl_base;
+ int irq;
+ struct clk *clk;
+ struct clk *axi_clk;
+ struct reset_control *rstc;
+ unsigned int channels;
+ unsigned int slave_requests;
+ unsigned int max_transfer_size;
+};
+
+#ifdef DEBUG_HIEDMAC
+static void dump_lli(const u64 *llis_vaddr, unsigned int num)
+{
+ struct hiedmac_lli *plli = (struct hiedmac_lli *)llis_vaddr;
+ unsigned int i;
+
+ hiedmacv310_trace(HIEDMACV310_CONFIG_TRACE_LEVEL, "lli num = 0%d", num);
+ for (i = 0; i < num; i++) {
+ hiedmacv310_
[PATCH v7 2/4] clk: hisilicon: Add clock driver for hi3559A SoC
Add clock drivers for hi3559A SoC, this driver
controls the SoC registers to supply different
clocks to different IPs in the SoC.
Signed-off-by: Dongjiu Geng
---
drivers/clk/hisilicon/Kconfig | 7 +
drivers/clk/hisilicon/Makefile | 1 +
drivers/clk/hisilicon/clk-hi3559a.c | 865
3 files changed, 873 insertions(+)
create mode 100644 drivers/clk/hisilicon/clk-hi3559a.c
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index 6a9e93a0bb95..5ecc37aaa118 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -15,6 +15,13 @@ config COMMON_CLK_HI3519
help
Build the clock driver for hi3519.
+config COMMON_CLK_HI3559A
+ bool "Hi3559A Clock Driver"
+ depends on ARCH_HISI || COMPILE_TEST
+ default ARCH_HISI
+ help
+ Build the clock driver for hi3559a.
+
config COMMON_CLK_HI3660
bool "Hi3660 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index b2441b99f3d5..bc101833b35e 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
obj-$(CONFIG_RESET_HISI) += reset.o
obj-$(CONFIG_STUB_CLK_HI6220) += clk-hi6220-stub.o
obj-$(CONFIG_STUB_CLK_HI3660) += clk-hi3660-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3559A) += clk-hi3559a.o
diff --git a/drivers/clk/hisilicon/clk-hi3559a.c
b/drivers/clk/hisilicon/clk-hi3559a.c
new file mode 100644
index ..d7693e488006
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3559a.c
@@ -0,0 +1,865 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Hisilicon Hi3559A clock driver
+ *
+ * Copyright (c) 2019-2020, Huawei Tech. Co., Ltd.
+ *
+ * Author: Dongjiu Geng
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk.h"
+#include "crg.h"
+#include "reset.h"
+
+#define CRG_BASE_ADDR 0x1802
+
+struct hi3559av100_pll_clock {
+ u32 id;
+ const char *name;
+ const char *parent_name;
+ u32 ctrl_reg1;
+ u8 frac_shift;
+ u8 frac_width;
+ u8 postdiv1_shift;
+ u8 postdiv1_width;
+ u8 postdiv2_shift;
+ u8 postdiv2_width;
+ u32 ctrl_reg2;
+ u8 fbdiv_shift;
+ u8 fbdiv_width;
+ u8 refdiv_shift;
+ u8 refdiv_width;
+};
+
+struct hi3559av100_clk_pll {
+ struct clk_hw hw;
+ u32 id;
+ void __iomem*ctrl_reg1;
+ u8 frac_shift;
+ u8 frac_width;
+ u8 postdiv1_shift;
+ u8 postdiv1_width;
+ u8 postdiv2_shift;
+ u8 postdiv2_width;
+ void __iomem*ctrl_reg2;
+ u8 fbdiv_shift;
+ u8 fbdiv_width;
+ u8 refdiv_shift;
+ u8 refdiv_width;
+};
+
+/* soc clk config */
+static const struct hisi_fixed_rate_clock hi3559av100_fixed_rate_clks_crg[] = {
+ { HI3559AV100_FIXED_1188M, "1188m", NULL, 0, 118800, },
+ { HI3559AV100_FIXED_1000M, "1000m", NULL, 0, 10, },
+ { HI3559AV100_FIXED_842M, "842m",NULL, 0, 84200, },
+ { HI3559AV100_FIXED_792M, "792m",NULL, 0, 79200, },
+ { HI3559AV100_FIXED_750M, "750m",NULL, 0, 75000, },
+ { HI3559AV100_FIXED_710M, "710m",NULL, 0, 71000, },
+ { HI3559AV100_FIXED_680M, "680m",NULL, 0, 68000, },
+ { HI3559AV100_FIXED_667M, "667m",NULL, 0, 66700, },
+ { HI3559AV100_FIXED_631M, "631m",NULL, 0, 63100, },
+ { HI3559AV100_FIXED_600M, "600m",NULL, 0, 6, },
+ { HI3559AV100_FIXED_568M, "568m",NULL, 0, 56800, },
+ { HI3559AV100_FIXED_500M, "500m",NULL, 0, 5, },
+ { HI3559AV100_FIXED_475M, "475m",NULL, 0, 47500, },
+ { HI3559AV100_FIXED_428M, "428m",NULL, 0, 42800, },
+ { HI3559AV100_FIXED_400M, "400m",NULL, 0, 4, },
+ { HI3559AV100_FIXED_396M, "396m",NULL, 0, 39600, },
+ { HI3559AV100_FIXED_300M, "300m",NULL, 0, 3, },
+ { HI3559AV100_FIXED_250M, "250m",NULL, 0, 25000, },
+ { HI3559AV100_FIXED_200M, "200m",NULL, 0, 2, },
+ { HI3559AV100_FIXED_198M, "198m",NULL, 0, 19800, },
+ { HI3559AV100_FIXED_187p5M, "187p5m", NULL, 0, 18750, },
+ { HI3559AV100_FIXED_150M, "150m",NULL, 0, 15000, },
+ { HI3559AV100_FIXED_148p5M, "148p5m", NULL, 0, 148500, },
+ { HI3559AV100_FIXED_125M, "125m",NULL, 0, 12500, },
+ { HI3559AV100_FIXED_107M, "107m",NULL, 0, 10700, },
+ { HI3559AV100_FIXED_100M, "100m",NULL, 0, 1, },
+ { HI3559AV100_FIXED_99M, "99m", NULL, 0, 9900, },
+ { HI3559AV100_FIXED_75M, "75m", NULL, 0, 7500, },
+ { HI3559AV100_
Re: [PATCH v2 19/21] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
On Fri, Dec 11, 2020 at 01:19:32AM +, Andre Przywara wrote:
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@4000 {
> + reg = <0x0 0x4000 0x0 0x8>;
> + no-map;
> + };
> + };
This should still be set by the firmware
> + mmc0: mmc@402 {
> + compatible = "allwinner,sun50i-h616-mmc",
> + "allwinner,sun50i-a100-mmc";
> + reg = <0x0402 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC0>;
> + reset-names = "ahb";
> + interrupts = ;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
Somewhat related: we shouldn't set the MMC speed flags in the drivers.
This is biting us on the already supported SoCs, so it would be great to
not repeat the same mistake with the new ones
Maxime
signature.asc
Description: PGP signature
Re: [PATCH RESEND v6 3/4] dt: bindings: dma: Add DT bindings for HiSilicon Hiedma Controller
On 2020/12/12 4:57, Rob Herring wrote:
> On Sat, 12 Dec 2020 13:11:14 +, Dongjiu Geng wrote:
>> The Hiedma Controller v310 Provides eight DMA channels, each
>> channel can be configured for one-way transfer. The data can
>> be transferred in 8-bit, 16-bit, 32-bit, or 64-bit mode. This
>> documentation describes DT bindings of this controller.
>>
>> Signed-off-by: Dongjiu Geng
>> ---
>> .../bindings/dma/hisilicon,hiedmacv310.yaml | 94 +++
>> 1 file changed, 94 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/dma/hisilicon,hiedmacv310.yaml
>>
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma/hisilicon,hiedmacv310.example.dt.yaml:
> dma-controller@1004: 'hisi,misc-control' does not match any of the
> regexes: '^#.*',
> '^(at25|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio|gpmc|hdmi|i2c-gpio),.*',
> '^(keypad|m25p|max8952|max8997|max8998|mpmc),.*',
> '^(pinctrl-single|#pinctrl-single|PowerPC),.*',
> '^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*',
> '^(simple-audio-card|st-plgpio|st-spics|ts),.*', '^70mai,.*', '^GEFanuc,.*',
> '^ORCL,.*', '^SUNW,.*', '^[a-zA-Z0-9#_][a-zA-Z0-9+\\-._@]{0,63}$',
> '^[a-zA-Z0-9+\\-._]*@[0-9a-zA-Z,]*$', '^abilis,.*', '^abracon,.*',
> '^acer,.*', '^acme,.*', '^actions,.*', '^active-semi,.*', '^ad,.*',
> '^adafruit,.*', '^adapteva,.*', '^adaptrum,.*', '^adh,.*', '^adi,.*',
> '^advantech,.*', '^aeroflexgaisler,.*', '^al,.*', '^allegro,.*', '^allo,.*',
> '^allwinner,.*', '^alphascale,.*', '^alps,.*', '^altr,.*', '^amarula,.*',
> '^amazon,.*', '^amcc,.*', '^amd,.*', '^amediatech,.*', '^amlogic,.*',
> '^ampire,.*', '^ams,.*', '^amstaos,.*', '^analogix,.*', '^andestech,.*',
> '^anvo,.*', '^apm,.*', '^aptina,.*', '^arasan,.*', '^archermind,.*',
> '^arctic,.*', '^arcx,.*', '^aries,.*', '^arm,.*', '^armadeus,.*',
> '^arrow,.*', '^artesyn,.*', '^asahi-kasei,.*', '^asc,.*', '^aspeed,.*',
> '^asus,.*', '^atlas,.*', '^atmel,.*', '^auo,.*', '^auvidea,.*', '^avago,.*',
> '^avia,.*', '^avic,.*', '^avnet,.*', '^awinic,.*', '^axentia,.*', '^axis,.*',
> '^azoteq,.*', '^azw,.*', '^baikal,.*', '^bananapi,.*', '^beacon,.*',
> '^beagle,.*', '^bhf,.*', '^bitmain,.*', '^boe,.*', '^bosch,.*',
> '^boundary,.*', '^brcm,.*', '^broadmobi,.*', '^bticino,.*', '^buffalo,.*',
> '^bur,.*', '^calaosystems,.*', '^calxeda,.*', '^caninos,.*', '^capella,.*',
> '^cascoda,.*', '^catalyst,.*', '^cavium,.*', '^cdns,.*', '^cdtech,.*',
> '^cellwise,.*', '^ceva,.*', '^checkpoint,.*', '^chefree,.*', '^chipidea,.*',
> '^chipone,.*', '^chipspark,.*', '^chrontel,.*', '^chrp,.*', '^chunghwa,.*',
> '^chuwi,.*', '^ciaa,.*', '^cirrus,.*', '^cloudengines,.*', '^cnm,.*',
> '^cnxt,.*', '^colorfly,.*', '^compulab,.*', '^coreriver,.*', '^corpro,.*',
> '^cortina,.*', '^cosmic,.*', '^crane,.*', '^creative,.*', '^crystalfontz,.*',
> '^csky,.*', '^csq,.*', '^cubietech,.*', '^cypress,.*', '^cznic,.*',
> '^dallas,.*', '^dataimage,.*', '^davicom,.*', '^dell,.*', '^delta,.*',
> '^denx,.*', '^devantech,.*', '^dfi,.*', '^dh,.*', '^difrnce,.*', '^digi,.*',
> '^digilent,.*', '^dioo,.*', '^dlc,.*', '^dlg,.*', '^dlink,.*', '^dmo,.*',
> '^domintech,.*', '^dongwoon,.*', '^dptechnics,.*', '^dragino,.*',
> '^dserve,.*', '^dynaimage,.*', '^ea,.*', '^ebs-systart,.*', '^ebv,.*',
> '^eckelmann,.*', '^edt,.*', '^eeti,.*', '^einfochips,.*', '^elan,.*',
> '^elgin,.*', '^elida,.*', '^embest,.*', '^emlid,.*', '^emmicro,.*',
> '^empire-electronix,.*', '^emtrion,.*', '^endless,.*', '^ene,.*',
> '^energymicro,.*', '^engicam,.*', '^epcos,.*', '^epfl,.*', '^epson,.*',
> '^esp,.*', '^est,.*', '^ettus,.*', '^eukrea,.*', '^everest,.*',
> '^everspin,.*', '^evervision,.*', '^exar,.*', '^excito,.*', '^ezchip,.*',
> '^facebook,.*', '^fairphone,.*', '^faraday,.*', '^fastrax,.*', '^fcs,.*',
> '^feixin,.*', '^feiyang,.*', '^firefly,.*', '^focaltech,.*', '^frida,.*',
> '^friendlyarm,.*', '^fsl,.*', '^fujitsu,.*', '^gardena,.*', '^gateworks,.*',
> '^gcw,.*', '^ge,.*', '^geekbuying,.*', '^gef,.*', '^gemei,.*',
> '^geniatech,.*', '^giantec,.*', '^giantplus,.*', '^globalscale,.*',
> '^globaltop,.*', '^gmt,.*', '^goodix,.*', '^google,.*', '^grinn,.*',
> '^grmn,.*', '^gumstix,.*', '^gw,.*', '^hannstar,.*', '^haoyu,.*',
> '^hardkernel,.*', '^hideep,.*', '^himax,.*', '^hisilicon,.*', '^hit,.*',
> '^hitex,.*', '^holt,.*', '^holtek,.*', '^honeywell,.*', '^hoperun,.*',
> '^hp,.*', '^hsg,.*', '^hugsun,.*', '^hwacom,.*', '^hydis,.*', '^hyundai,.*',
> '^i2se,.*', '^ibm,.*', '^icplus,.*', '^idt,.*', '^ifi,.*', '^ilitek,.*',
> '^img,.*', '^imi,.*', '^incircuit,.*', '^inet-tek,.*', '^infineon,.*',
> '^inforce,.*', '^ingenic,.*', '^innolux,.*', '^inside-secure,.*',
> '^inspur,.*', '^intel,.*', '^intercontrol,.*', '^invensense,.*',
> '^inversepath,.*', '^iom,.*', '^isee,.*', '^isil,.*', '^issi,.*', '^ite,.*',
> '^
Re: [PATCH v4 2/3] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
Hi CY
On Sat, Dec 12, 2020 at 12:33:43AM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
This patch got keyword filtered and brought to my attention
but the rest of the series did not.
If it was a backlight patch series you need to send it To: the
all the backlight maintainers.
Daniel.
> ---
> since v3
> - Move inlcude/dt-bindings/leds/rt4831-backlight.h from v3 mfd binding patch
> to here.
> - Add dual license tag in header and backlight binding document.
> - Left backlight dt-binding example only.
> ---
> .../leds/backlight/richtek,rt4831-backlight.yaml | 76
> ++
> include/dt-bindings/leds/rt4831-backlight.h| 23 +++
> 2 files changed, 99 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
> create mode 100644 include/dt-bindings/leds/rt4831-backlight.h
>
> diff --git
> a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
>
> b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
> new file mode 100644
> index ..f24c8d1
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/leds/backlight/richtek,rt4831-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Richtek RT4831 Backlight
> +
> +maintainers:
> + - ChiYuan Huang
> +
> +description: |
> + RT4831 is a mutifunctional device that can provide power to the LCD display
> + and LCD backlight.
> +
> + For the LCD backlight, it can provide four channel WLED driving capability.
> + Each channel driving current is up to 30mA
> +
> + Datasheet is available at
> + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf
> +
> +properties:
> + compatible:
> +const: richtek,rt4831-backlight
> +
> + default-brightness:
> +description: |
> + The default brightness that applied to the system on start-up.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 2048
> +
> + max-brightness:
> +description: |
> + The max brightness for the H/W limit
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 2048
> +
> + richtek,pwm-enable:
> +description: |
> + Specify the backlight dimming following by PWM duty or by SW control.
> +type: boolean
> +
> + richtek,bled-ovp-sel:
> +description: |
> + Backlight OVP level selection, currently support 17V/21V/25V/29V.
> +$ref: /schemas/types.yaml#/definitions/uint8
> +default: 1
> +minimum: 0
> +maximum: 3
> +
> + richtek,channel-use:
> +description: |
> + Backlight LED channel to be used.
> + BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable or disable.
> +$ref: /schemas/types.yaml#/definitions/uint8
> +minimum: 1
> +maximum: 15
> +
> +required:
> + - compatible
> + - richtek,channel-use
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +backlight {
> + compatible = "richtek,rt4831-backlight";
> + default-brightness = <1024>;
> + max-brightness = <2048>;
> + richtek,bled-ovp-sel = /bits/ 8 ;
> + richtek,channel-use = /bits/ 8 ;
> +};
> diff --git a/include/dt-bindings/leds/rt4831-backlight.h
> b/include/dt-bindings/leds/rt4831-backlight.h
> new file mode 100644
> index ..125c635
> --- /dev/null
> +++ b/include/dt-bindings/leds/rt4831-backlight.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * This header provides constants for rt4831 backlight bindings.
> + *
> + * Copyright (C) 2020, Richtek Technology Corp.
> + * Author: ChiYuan Huang
> + */
> +
> +#ifndef _DT_BINDINGS_RT4831_BACKLIGHT_H
> +#define _DT_BINDINGS_RT4831_BACKLIGHT_H
> +
> +#define RT4831_BLOVPLVL_17V 0
> +#define RT4831_BLOVPLVL_21V 1
> +#define RT4831_BLOVPLVL_25V 2
> +#define RT4831_BLOVPLVL_29V 3
> +
> +#define RT4831_BLED_CH1EN(1 << 0)
> +#define RT4831_BLED_CH2EN(1 << 1)
> +#define RT4831_BLED_CH3EN(1 << 2)
> +#define RT4831_BLED_CH4EN(1 << 3)
> +#define RT4831_BLED_ALLCHEN ((1 << 4) - 1)
> +
> +#endif /* _DT_BINDINGS_RT4831_BACKLIGHT_H */
> --
> 2.7.4
>
Re: [PATCH v2 21/21] arm64: dts: allwinner: Add OrangePi Zero 2 .dts
On Fri, Dec 11, 2020 at 01:19:34AM +, Andre Przywara wrote:
> The OrangePi Zero 2 is a development board with the new H616 SoC.
>
> It features the usual connectors used on those small boards, and comes
> with the AXP305, which seems to be compatible with the AXP805.
>
> For more details see: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero2
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../allwinner/sun50i-h616-orangepi-zero2.dts | 240 ++
> 2 files changed, 241 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index 211d1e9d4701..0cf8299b1ce7 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> new file mode 100644
> index ..2afc036059b4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2020 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "OrangePi Zero2";
> + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> +
> + aliases {
> + ethernet0 = &emac0;
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
This isn't a valid node name
Maxime
signature.asc
Description: PGP signature
