[PATCH for -next] docs: hwmon: rectify table in max16601.rst
Commit 90b0f71d62df ("hwmon: (pmbus/max16601) Determine and use number of
populated phases") adjusts content in the table of
./Documentation/hwmon/max16601.rst, but one row went beyond the column's
length.
Hence, make htmldocs warns:
Documentation/hwmon/max16601.rst:94: WARNING: Malformed table.
Adjust the column length of that table for this longer row to fit.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210129
Guenter, please pick this minor fixup for your hwmon-next tree.
Documentation/hwmon/max16601.rst | 143 +++
1 file changed, 71 insertions(+), 72 deletions(-)
diff --git a/Documentation/hwmon/max16601.rst b/Documentation/hwmon/max16601.rst
index d16792be7533..d265a2224354 100644
--- a/Documentation/hwmon/max16601.rst
+++ b/Documentation/hwmon/max16601.rst
@@ -53,75 +53,74 @@ Sysfs entries
The following attributes are supported.
-=== ===
-in1_label "vin1"
-in1_input VCORE input voltage.
-in1_alarm Input voltage alarm.
-
-in2_label "vout1"
-in2_input VCORE output voltage.
-in2_alarm Output voltage alarm.
-
-curr1_label"iin1"
-curr1_inputVCORE input current, derived from duty cycle and output
- current.
-curr1_max Maximum input current.
-curr1_max_alarmCurrent high alarm.
-
-curr[P+2]_label"iin1.P"
-curr[P+2]_inputVCORE phase P input current.
-
-curr[N+2]_label"iin2"
-curr[N+2]_inputVCORE input current, derived from sensor
element.
- 'N' is the number of enabled/populated phases.
-
-curr[N+3]_label"iin3"
-curr[N+3]_inputVSA input current.
-
-curr[N+4]_label"iout1"
-curr[N+4]_inputVCORE output current.
-curr[N+4]_crit Critical output current.
-curr[N+4]_crit_alarm Output current critical alarm.
-curr[N+4]_max Maximum output current.
-curr[N+4]_max_alarmOutput current high alarm.
-
-curr[N+P+5]_label "iout1.P"
-curr[N+P+5]_input VCORE phase P output current.
-
-curr[2*N+5]_label "iout3"
-curr[2*N+5]_input VSA output current.
-curr[2*N+5]_highestHistorical maximum VSA output current.
-curr[2*N+5]_reset_history
- Write any value to reset curr21_highest.
-curr[2*N+5]_crit Critical output current.
-curr[2*N+5]_crit_alarm Output current critical alarm.
-curr[2*N+5]_maxMaximum output current.
-curr[2*N+5]_max_alarm Output current high alarm.
-
-power1_label "pin1"
-power1_input Input power, derived from duty cycle and output current.
-power1_alarm Input power alarm.
-
-power2_label "pin2"
-power2_input Input power, derived from input current sensor.
-
-power3_label "pout"
-power3_input Output power.
-
-temp1_inputVCORE temperature.
-temp1_crit Critical high temperature.
-temp1_crit_alarm Chip temperature critical high alarm.
-temp1_max Maximum temperature.
-temp1_max_alarmChip temperature high alarm.
-
-temp2_inputTSENSE_0 temperature
-temp3_inputTSENSE_1 temperature
-temp4_inputTSENSE_2 temperature
-temp5_inputTSENSE_3 temperature
-
-temp6_inputVSA temperature.
-temp6_crit Critical high temperature.
-temp6_crit_alarm Chip temperature critical high alarm.
-temp6_max Maximum temperature.
-temp6_max_alarmChip temperature high alarm.
-=== ===
+=
===
+in1_label"vin1"
+in1_inputVCORE input voltage.
+in1_alarmInput voltage alarm.
+
+in2_label"vout1"
+in2_inputVCORE output voltage.
+in2_alarmOutput voltage alarm.
+
+curr1_label "iin1"
+curr1_input VCORE input current, derived from duty cycle and
output
+ current.
+curr1_maxMaximum input current.
+curr1_max_alarm Current high alarm.
+
+curr[P+2]_label "iin1.P"
+curr[P+2]_input VCORE phase P input current.
+
+curr[N+2]_label "iin2"
+curr[N+2]_input VCORE input current, derived from sensor
element.
+ 'N' is the number of enabled/populated phases.
+
+curr[N+3]_label "iin3"
+curr[N+3]_input VSA input current.
+
+curr[N+4]_label "iout1"
+curr[N+4]_input VCORE output current.
+curr[N+4]_crit Critical output current.
[PATCH for -next] docs: drop removed pti_intel_mid from driver-api index
Commit 8ba59e9dee31 ("misc: pti: Remove driver for deprecated platform")
removed ./Documentation/driver-api/pti_intel_mid.rst, but missed to remove
it from the index at ./Documentation/driver-api/index.rst.
Hence, make htmldocs warns:
WARNING: toctree contains reference to nonexisting document
'driver-api/pti_intel_mid'
Remove pti_intel_mid from driver-api index.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210129
Greg, please pick this minor fixup on top of the commit above.
Documentation/driver-api/index.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/driver-api/index.rst
b/Documentation/driver-api/index.rst
index 9d9af54d68c5..66c4c01eeec6 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -93,7 +93,6 @@ available subsections can be seen below.
pps
ptp
phy/index
- pti_intel_mid
pwm
pldmfw/index
rfkill
--
2.17.1
Re: [PATCH v2] iio: hid-sensor-prox: Fix scale not correct issue
On Sat, Jan 30, 2021 at 07:14:29PM +, Jonathan Cameron wrote:
> On Sat, 30 Jan 2021 18:25:30 +0800
> Ye Xiang wrote:
>
> > Currently, the proxy sensor scale is zero because it just return the
> > exponent directly. To fix this issue, this patch use
> > hid_sensor_format_scale to process the scale first then return the
> > output.
> >
> > Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver")
> > Signed-off-by: Ye Xiang
>
> Hi Ye Xiang,
>
> There was a bit of fuzz on this so please take a look at
> my fixes-togreg branch and check it went in cleanly.
Have checked fixes-toreg branch, the patch it's correct.
Thanks
Ye Xiang
>
>
> > ---
> > v2:
> > - Add Fixes tag
> >
> > ---
> > drivers/iio/light/hid-sensor-prox.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/light/hid-sensor-prox.c
> > b/drivers/iio/light/hid-sensor-prox.c
> > index 4ab285a418d5..4abcfe48f1d4 100644
> > --- a/drivers/iio/light/hid-sensor-prox.c
> > +++ b/drivers/iio/light/hid-sensor-prox.c
> > @@ -23,6 +23,9 @@ struct prox_state {
> > struct hid_sensor_common common_attributes;
> > struct hid_sensor_hub_attribute_info prox_attr;
> > u32 human_presence;
> > + int scale_pre_decml;
> > + int scale_post_decml;
> > + int scale_precision;
> > };
> >
> > static const u32 prox_sensitivity_addresses[] = {
> > @@ -98,8 +101,9 @@ static int prox_read_raw(struct iio_dev *indio_dev,
> > ret_type = IIO_VAL_INT;
> > break;
> > case IIO_CHAN_INFO_SCALE:
> > - *val = prox_state->prox_attr.units;
> > - ret_type = IIO_VAL_INT;
> > + *val = prox_state->scale_pre_decml;
> > + *val2 = prox_state->scale_post_decml;
> > + ret_type = prox_state->scale_precision;
> > break;
> > case IIO_CHAN_INFO_OFFSET:
> > *val = hid_sensor_convert_exponent(
> > @@ -221,6 +225,11 @@ static int prox_parse_report(struct platform_device
> > *pdev,
> > dev_dbg(>dev, "prox %x:%x\n", st->prox_attr.index,
> > st->prox_attr.report_id);
> >
> > + st->scale_precision = hid_sensor_format_scale(
> > + hsdev->usage,
> > + >prox_attr,
> > + >scale_pre_decml, >scale_post_decml);
> > +
> > return ret;
> > }
> >
>
Re: [PATCH 3/8] scsi: ufshpb: Add region's reads counter
On Sun, Jan 31, 2021 at 07:25:37AM +, Avri Altman wrote:
> > >
> > > + if (ufshpb_mode == HPB_HOST_CONTROL)
> > > + reads = atomic64_inc_return(>reads);
> > > +
> > > if (!ufshpb_is_support_chunk(transfer_len))
> > > return;
> > >
> > > + if (ufshpb_mode == HPB_HOST_CONTROL) {
> > > + /*
> > > + * in host control mode, reads are the main source for
> > > + * activation trials.
> > > + */
> > > + if (reads == ACTIVATION_THRSHLD) {
> Oops - this is a bug...
>
> > > +
> > > + /* region reads - for host mode */
> > > + atomic64_t reads;
> >
> > Why do you need an atomic variable for this? What are you trying to
> > "protect" here by flushing the cpus all the time? What protects this
> > variable from changing right after you have read from it (hint, you do
> > that above...)
> >
> > atomics are not race-free, use a real lock if you need that.
> We are on the data path here - this is called from queuecommand.
> The "reads" counter is being symmetrically read and written,
> so adding a spin lock here might become a source for contention.
And an atomic varible is not? You do know what spinlocks are made of,
right? :)
> Also I am not worried about the exact value of this counter, except of one
> place -
> See above. Will fix it.
So it's not really needed?
thanks,
greg k-h
RE: [PATCH 7/8] scsi: ufshpb: Add "Cold" regions timer
> > + /* region "cold" timer - for host mode */ > > + ktime_t read_timeout; > > + atomic_t read_timeout_expiries; > > Why does this have to be an atomic when you have a lock to protect this > structure already taken? Done. You are right, it is protected by the hpb state lock. Will fix it. Thanks, Avri
RE: [PATCH 3/8] scsi: ufshpb: Add region's reads counter
> >
> > + if (ufshpb_mode == HPB_HOST_CONTROL)
> > + reads = atomic64_inc_return(>reads);
> > +
> > if (!ufshpb_is_support_chunk(transfer_len))
> > return;
> >
> > + if (ufshpb_mode == HPB_HOST_CONTROL) {
> > + /*
> > + * in host control mode, reads are the main source for
> > + * activation trials.
> > + */
> > + if (reads == ACTIVATION_THRSHLD) {
Oops - this is a bug...
> > +
> > + /* region reads - for host mode */
> > + atomic64_t reads;
>
> Why do you need an atomic variable for this? What are you trying to
> "protect" here by flushing the cpus all the time? What protects this
> variable from changing right after you have read from it (hint, you do
> that above...)
>
> atomics are not race-free, use a real lock if you need that.
We are on the data path here - this is called from queuecommand.
The "reads" counter is being symmetrically read and written,
so adding a spin lock here might become a source for contention.
Also I am not worried about the exact value of this counter, except of one
place -
See above. Will fix it.
Thanks,
Avri
RE: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw
Thanks Johns. We could see a kernel crash while testing this patch. [ 246.724632] scsi host10: pm80xx [ 248.005258] sas: Enter sas_scsi_recover_host busy: 0 failed: 0 [ 248.168973] BUG: kernel NULL pointer dereference, address: 0110 [ 248.175926] #PF: supervisor read access in kernel mode [ 248.181065] #PF: error_code(0x) - not-present page [ 248.186196] PGD 0 P4D 0 [ 248.188736] Oops: [#1] SMP PTI [ 248.192230] CPU: 10 PID: 77 Comm: kworker/u26:2 Kdump: loaded Tainted: G S OE 5.11.0-rc3 #2 [ 248.201614] Hardware name: Supermicro Super Server/X10DRi-LN4+, BIOS 3.1 06/08/2018 [ 248.209258] Workqueue: events_unbound async_run_entry_fn [ 248.214571] RIP: 0010:pm80xx_chip_sata_req+0x7f/0x5e0 [pm80xx] [ 248.220413] Code: c1 7c c1 e9 03 4d 8b ac 24 80 01 00 00 48 c7 44 24 14 00 00 00 00 89 04 24 31 c0 48 c7 84 24 88 00 00 00 00 00 00 00 f3 48 ab <48> 8b ba 10 01 00 00 e8 35 35 c6 ef c1 e8 10 89 44 24 04 0f b6 43 [ 248.239157] RSP: 0018:b98d834979f0 EFLAGS: 00010046 [ 248.244384] RAX: RBX: 9523c321c000 RCX: [ 248.251516] RDX: RSI: 952450720048 RDI: b98d83497a80 [ 248.258641] RBP: 9523c742 R08: 0100 R09: 0001 [ 248.265764] R10: 0001 R11: 9523c9e4 R12: 9523ca1c3600 [ 248.272887] R13: 9523c9e4 R14: b98d83497a04 R15: 952450720048 [ 248.280013] FS: () GS:9527afd0() knlGS: [ 248.288090] CS: 0010 DS: ES: CR0: 80050033 [ 248.293826] CR2: 0110 CR3: 00029ac10001 CR4: 001706e0 [ 248.300952] Call Trace: [ 248.303402] pm8001_task_exec.isra.9+0x2a4/0x460 [pm80xx] [ 248.308805] sas_ata_qc_issue+0x187/0x220 [libsas] [ 248.313607] ata_qc_issue+0x107/0x1e0 [libata] [ 248.318069] ata_exec_internal_sg+0x2c8/0x580 [libata] [ 248.323217] ata_exec_internal+0x5f/0x90 [libata] [ 248.327931] ata_dev_read_id+0x306/0x480 [libata] [ 248.332647] ata_eh_recover+0x7ea/0x12a0 [libata] [ 248.337369] ? vprintk_emit+0x114/0x220 [ 248.341208] ? sas_ata_sched_eh+0x60/0x60 [libsas] [ 248.346002] ? sas_ata_prereset+0x50/0x50 [libsas] [ 248.350795] ? printk+0x58/0x6f [ 248.353941] ? sas_ata_sched_eh+0x60/0x60 [libsas] [ 248.358733] ? sas_ata_prereset+0x50/0x50 [libsas] [ 248.363525] ata_do_eh+0x40/0xb0 [libata] [ 248.367556] ata_scsi_port_error_handler+0x354/0x770 [libata] [ 248.373318] async_sas_ata_eh+0x44/0x7b [libsas] [ 248.377938] async_run_entry_fn+0x39/0x160 [ 248.382040] process_one_work+0x1cb/0x360 [ 248.386050] worker_thread+0x30/0x370 [ 248.389706] ? processe_work+0x360/0x360 [ 248.393884] kthread+0x116/0x130 [ 248.397116] ? kthread_park+0x80/0x80 [ 248.400773] ret_from_fork+0x22/0x30 [ 248.404355] Modules linked in: pm80xx(OE) libsas scsi_transport_sas xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun bridge stp llc rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass joydev crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ipmi_ssif iTCO_wdt iTCO_vendor_support mei_me rapl i2c_i801 intel_cstate mei acpi_ipmi lpc_ich intel_uncore pcspkr ipmi_si i2c_smbus ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad ioatdma ip_tables xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg ast drm_vram_helper drm_kms_helper syscopyarea igb sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm ahci libahci dca drm crc32c_intel libata i2c_algo_bit wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ 248.483431] CR2: 0110 [0.00] Linux version 5.11.0-rc3 (root@localhost.localdomain) (gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), GNU ld version 2.30-79.el8) #2 SMP Mon Jan 25 23:56:12 IST 2021 [0.00] Command line: elfcorehr=0x4500 BOOT_IMAGE=(hd14,gpt2)/vmlinuz-5.11.0-rc3 ro resume=/dev/mapper/rhel-swap rhgb console=ttyS1,115200 loglevel=7 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never nokaslr novmcoredd hest_disable disable_cpu_apicid=0 > -Original Message- > From: John Garry > Sent: Tuesday, January 5, 2021 4:47 PM > To: j...@linux.ibm.com; martin.peter...@oracle.com; > akshat...@google.com; Viswas G - I30667 ; > Ruksar Devadi - I52327 ; > ra...@google.com; bjashn...@google.com; vishakh...@google.com; > jinpu.w...@cloud.ionos.com; Ashokkumar N - X53535 > > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; h...@suse.de; > kashyap.de...@broadcom.com; ming@redhat.com; John Garry > > Subject: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is
RE: [PATCH 1/8] scsi: ufshpb: Cache HPB Control mode on init
> On Sun, Jan 31, 2021 at 07:08:00AM +, Avri Altman wrote: > > > > > > > > +static enum UFSHPB_MODE ufshpb_mode; > > > > > > How are you allowed to have a single variable for a device-specific > > > thing? What happens when you have two controllers or disks or whatever > > > you are binding to here? How does this work at all? > > > > > > This should be per-device, right? > > Right. Done. > > > > Not being bickering, AFAIK, there aren't, nor will be in the foreseen > > future, > any multi-ufs-hosts designs. > > Why not? What prevents someone from putting 2 PCI ufs host controllers > in a system tomorrow? > > > There were some talks in the past about ufs cards, but this is officially > > off > the table. > > Never say never :) > > Seriously, how can you somehow ensure that a random manufacturer will > not do this? Better let the platform vendors answer this. As for your comment - you are obviously right - I will fix this. Thanks, Avri
Re: [PATCH v2] iio: hid-sensor-prox: Fix scale not correct issue
On Sat, Jan 30, 2021 at 07:14:29PM +, Jonathan Cameron wrote:
> On Sat, 30 Jan 2021 18:25:30 +0800
> Ye Xiang wrote:
>
> > Currently, the proxy sensor scale is zero because it just return the
> > exponent directly. To fix this issue, this patch use
> > hid_sensor_format_scale to process the scale first then return the
> > output.
> >
> > Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver")
> > Signed-off-by: Ye Xiang
>
> Hi Ye Xiang,
>
> There was a bit of fuzz on this so please take a look at
> my fixes-togreg branch and check it went in cleanly.
Have checked, it's correct.
Thanks
Ye Xiang
>
>
> > ---
> > v2:
> > - Add Fixes tag
> >
> > ---
> > drivers/iio/light/hid-sensor-prox.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/light/hid-sensor-prox.c
> > b/drivers/iio/light/hid-sensor-prox.c
> > index 4ab285a418d5..4abcfe48f1d4 100644
> > --- a/drivers/iio/light/hid-sensor-prox.c
> > +++ b/drivers/iio/light/hid-sensor-prox.c
> > @@ -23,6 +23,9 @@ struct prox_state {
> > struct hid_sensor_common common_attributes;
> > struct hid_sensor_hub_attribute_info prox_attr;
> > u32 human_presence;
> > + int scale_pre_decml;
> > + int scale_post_decml;
> > + int scale_precision;
> > };
> >
> > static const u32 prox_sensitivity_addresses[] = {
> > @@ -98,8 +101,9 @@ static int prox_read_raw(struct iio_dev *indio_dev,
> > ret_type = IIO_VAL_INT;
> > break;
> > case IIO_CHAN_INFO_SCALE:
> > - *val = prox_state->prox_attr.units;
> > - ret_type = IIO_VAL_INT;
> > + *val = prox_state->scale_pre_decml;
> > + *val2 = prox_state->scale_post_decml;
> > + ret_type = prox_state->scale_precision;
> > break;
> > case IIO_CHAN_INFO_OFFSET:
> > *val = hid_sensor_convert_exponent(
> > @@ -221,6 +225,11 @@ static int prox_parse_report(struct platform_device
> > *pdev,
> > dev_dbg(>dev, "prox %x:%x\n", st->prox_attr.index,
> > st->prox_attr.report_id);
> >
> > + st->scale_precision = hid_sensor_format_scale(
> > + hsdev->usage,
> > + >prox_attr,
> > + >scale_pre_decml, >scale_post_decml);
> > +
> > return ret;
> > }
> >
>
RE: [PATCH 2/8] scsi: ufshpb: Add host control mode support to rsp_upiu
> > > On Wed, Jan 27, 2021 at 05:12:11PM +0200, Avri Altman wrote: > > There are some limitations to activations / inactivations in host > > control mode - Add those. > > I can not understand this changelog text, please make it more > descriptive as I have no way to know how to review this patch :( Done.
Re: [PATCH 1/8] scsi: ufshpb: Cache HPB Control mode on init
On Sun, Jan 31, 2021 at 07:08:00AM +, Avri Altman wrote: > > > > > > +static enum UFSHPB_MODE ufshpb_mode; > > > > How are you allowed to have a single variable for a device-specific > > thing? What happens when you have two controllers or disks or whatever > > you are binding to here? How does this work at all? > > > > This should be per-device, right? > Right. Done. > > Not being bickering, AFAIK, there aren't, nor will be in the foreseen > future, any multi-ufs-hosts designs. Why not? What prevents someone from putting 2 PCI ufs host controllers in a system tomorrow? > There were some talks in the past about ufs cards, but this is officially off > the table. Never say never :) Seriously, how can you somehow ensure that a random manufacturer will not do this? thanks, greg k-h
RE: [PATCH 1/8] scsi: ufshpb: Cache HPB Control mode on init
> > > > +static enum UFSHPB_MODE ufshpb_mode; > > How are you allowed to have a single variable for a device-specific > thing? What happens when you have two controllers or disks or whatever > you are binding to here? How does this work at all? > > This should be per-device, right? Right. Done. Not being bickering, AFAIK, there aren't, nor will be in the foreseen future, any multi-ufs-hosts designs. There were some talks in the past about ufs cards, but this is officially off the table. Thanks, Avri
RE: [PATCH net-next v1 2/6] lan743x: support rx multi-buffer packets
Hi Sven,
Looks good.
see comments below.
> static int lan743x_rx_process_packet(struct lan743x_rx *rx) {
It looks like this function no longer processes a packet, but rather only
processes a single buffer.
So perhaps it should be renamed to lan743x_rx_process_buffer, so it is not
misleading.
...
> + /* unmap from dma */
> + if (buffer_info->dma_ptr) {
> + dma_unmap_single(>adapter->pdev->dev,
> +buffer_info->dma_ptr,
> +buffer_info->buffer_length,
> +DMA_FROM_DEVICE);
> + buffer_info->dma_ptr = 0;
> + buffer_info->buffer_length = 0;
> + }
> + skb = buffer_info->skb;
>
> -process_extension:
> - if (extension_index >= 0) {
> - descriptor = >ring_cpu_ptr[extension_index];
> - buffer_info = >buffer_info[extension_index];
> -
> - ts_sec = le32_to_cpu(descriptor->data1);
> - ts_nsec = (le32_to_cpu(descriptor->data2) &
> - RX_DESC_DATA2_TS_NS_MASK_);
> - lan743x_rx_reuse_ring_element(rx, extension_index);
> - real_last_index = extension_index;
> - }
> + /* allocate new skb and map to dma */
> + if (lan743x_rx_init_ring_element(rx, rx->last_head)) {
If lan743x_rx_init_ring_element fails to allocate an skb,
Then lan743x_rx_reuse_ring_element will be called.
But that function expects the skb is already allocated and dma mapped.
But the dma was unmapped above.
Also if lan743x_rx_init_ring_element fails to allocate an skb.
Then control will jump to process_extension and therefor
the currently received skb will not be added to the skb list.
I assume that would corrupt the packet? Or am I missing something?
...
> - if (!skb) {
> - result = RX_PROCESS_RESULT_PACKET_DROPPED;
It looks like this return value is no longer used.
If there is no longer a case where a packet will be dropped
then maybe this return value should be deleted from the header file.
...
> move_forward:
> - /* push tail and head forward */
> - rx->last_tail = real_last_index;
> - rx->last_head = lan743x_rx_next_index(rx, real_last_index);
> - }
> + /* push tail and head forward */
> + rx->last_tail = rx->last_head;
> + rx->last_head = lan743x_rx_next_index(rx, rx->last_head);
> + result = RX_PROCESS_RESULT_PACKET_RECEIVED;
Since this function handles one buffer at a time,
The return value RX_PROCESS_RESULT_PACKET_RECEIVED is now misleading.
Can you change it to RX_PROCESS_RESULT_BUFFER_RECEIVED.
Re: [Patch v2 net-next 2/7] octeontx2-af: Add new CGX_CMD to get PHY FEC statistics
Hi Willem,
> -Original Message-
> From: Willem de Bruijn
> Sent: Saturday, January 30, 2021 7:57 PM
> To: Hariprasad Kelam
> Cc: Network Development ; LKML ker...@vger.kernel.org>; David Miller ; Jakub
> Kicinski ; Sunil Kovvuri Goutham
> ; Linu Cherian ;
> Geethasowjanya Akula ; Jerin Jacob Kollanukkaran
> ; Subbaraya Sundeep Bhatta ;
> Felix Manlunas ; Christina Jacob
> ; Sunil Kovvuri Goutham
>
> Subject: [EXT] Re: [Patch v2 net-next 2/7] octeontx2-af: Add new CGX_CMD
> to get PHY FEC statistics
> On Sat, Jan 30, 2021 at 4:53 AM Hariprasad Kelam
> wrote:
> >
> > Hi Willem,
> >
> > > -Original Message-
> > > From: Willem de Bruijn
> > > Sent: Thursday, January 28, 2021 1:50 AM
> > > To: Hariprasad Kelam
> > > Cc: Network Development ; LKML > > ker...@vger.kernel.org>; David Miller ; Jakub
> > > Kicinski ; Sunil Kovvuri Goutham
> > > ; Linu Cherian ;
> > > Geethasowjanya Akula ; Jerin Jacob Kollanukkaran
> > > ; Subbaraya Sundeep Bhatta
> > > ; Felix Manlunas ;
> > > Christina Jacob ; Sunil Kovvuri Goutham
> > >
> > > Subject: [EXT] Re: [Patch v2 net-next 2/7] octeontx2-af: Add new
> > > CGX_CMD to get PHY FEC statistics
> > >
> > > On Wed, Jan 27, 2021 at 4:04 AM Hariprasad Kelam
> > >
> > > wrote:
> > > >
> > > > From: Felix Manlunas
> > > >
> > > > This patch adds support to fetch fec stats from PHY. The stats are
> > > > put in the shared data struct fwdata. A PHY driver indicates that
> > > > it has FEC stats by setting the flag fwdata.phy.misc.has_fec_stats
> > > >
> > > > Besides CGX_CMD_GET_PHY_FEC_STATS, also add CGX_CMD_PRBS and
> > > > CGX_CMD_DISPLAY_EYE to enum cgx_cmd_id so that Linux's enum list
> > > > is in sync with firmware's enum list.
> > > >
> > > > Signed-off-by: Felix Manlunas
> > > > Signed-off-by: Christina Jacob
> > > > Signed-off-by: Sunil Kovvuri Goutham
> > > > Signed-off-by: Hariprasad Kelam
> > >
> > >
> > > > +struct phy_s {
> > > > + struct {
> > > > + u64 can_change_mod_type : 1;
> > > > + u64 mod_type: 1;
> > > > + u64 has_fec_stats : 1;
> > >
> > > this style is not customary
> >
> > These structures are shared with firmware and stored in a shared memory.
> Any change in size of structures will break compatibility. To avoid frequent
> compatible issues with new vs old firmware we have put spaces where ever
> we see that there could be more fields added in future.
> > So changing this to u8 can have an impact in future.
>
> My comment was intended much simpler: don't add whitespace between the
> bit-field variable name and its size expression.
>
> u64 mod_type:1;
>
> not
>
> u64 mod_type : 1;
>
> At least, I have not seen that style anywhere else in the kernel.
Got it . Will fix this in next version.
Thanks,
Hariprasad k
[PATCH v2 1/5] dt-bindings: arm: amlogic: sort SM1 bindings
Sort the bindings before adding new SM1 devices. Signed-off-by: Christian Hewitt Acked-by: Neil Armstrong --- Documentation/devicetree/bindings/arm/amlogic.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 6bef60ddda64..b21ba8ba23dd 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -164,9 +164,9 @@ properties: - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC items: - enum: - - seirobotics,sei610 - - khadas,vim3l - hardkernel,odroid-c4 + - khadas,vim3l + - seirobotics,sei610 - const: amlogic,sm1 - description: Boards with the Amlogic Meson A1 A113L SoC -- 2.17.1
[PATCH v2 5/5] arm64: dts: meson: add initial device-tree for ODROID-HC4
ODROID-HC4 is a derivative of the C4 with minor differences:
- 16MB XT25F128B SPI-NOR flash
- 2x SATA ports via ASM1061 PCIe to SATA controller
- 7-pin header with SPI and I2C for 1-inch OLED display and RTC
- 1x USB 2.0 host port
Signed-off-by: Christian Hewitt
Reviewed-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-odroid-hc4.dts | 96 +++
2 files changed, 97 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index f3c8a85fe987..78a569d7fa20 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -47,5 +47,6 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-a1-ad401.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts
b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts
new file mode 100644
index ..bf15700c4b15
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Dongjin Kim
+ */
+
+/dts-v1/;
+
+#include "meson-sm1-odroid.dtsi"
+
+/ {
+ compatible = "hardkernel,odroid-hc4", "amlogic,sm1";
+ model = "Hardkernel ODROID-HC4";
+
+ aliases {
+ rtc0 =
+ rtc1 =
+ };
+
+ fan0: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-min-state = <0>;
+ cooling-max-state = <3>;
+ cooling-levels = <0 120 170 220>;
+ pwms = <_cd 1 4 0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = <_ao GPIOAO_11 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ panic-indicator;
+ };
+
+ led-red {
+ color = ;
+ function = LED_FUNCTION_POWER;
+ gpios = <_ao GPIOAO_7 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ sound {
+ model = "ODROID-HC4";
+ };
+};
+
+_thermal {
+ cooling-maps {
+ map {
+ trip = <_passive>;
+ cooling-device = < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+ {
+ linux,rc-map-name = "rc-odroid";
+};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_sda_x_pins>, <_sck_x_pins>;
+ pinctrl-names = "default";
+
+ rtc: rtc@51 {
+ status = "okay";
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ wakeup-source;
+ };
+};
+
+ {
+ status = "okay";
+ reset-gpios = < GPIOH_4 GPIO_ACTIVE_LOW>;
+};
+
+_cd {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_d_x6_pins>;
+};
+
+_emmc_c {
+ status = "disabled";
+};
+
+ {
+ phys = <_phy0>, <_phy1>;
+ phy-names = "usb2-phy0", "usb2-phy1";
+};
--
2.17.1
[PATCH v2 3/5] arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi
Convert the ODROID-C4 dts to meson-sm1-odroid.dtsi and C4 board dts in
preparation for adding additional C4 family boards.
Signed-off-by: Christian Hewitt
Reviewed-by: Neil Armstrong
---
.../boot/dts/amlogic/meson-sm1-odroid-c4.dts | 427 +
.../boot/dts/amlogic/meson-sm1-odroid.dtsi| 441 ++
2 files changed, 442 insertions(+), 426 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
index eadd75e6e067..b2a4e823c1d8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
@@ -5,34 +5,12 @@
/dts-v1/;
-#include "meson-sm1.dtsi"
-#include
-#include
-#include
+#include "meson-sm1-odroid.dtsi"
/ {
compatible = "hardkernel,odroid-c4", "amlogic,sm1";
model = "Hardkernel ODROID-C4";
- aliases {
- serial0 = _AO;
- ethernet0 =
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x4000>;
- };
-
- emmc_pwrseq: emmc-pwrseq {
- compatible = "mmc-pwrseq-emmc";
- reset-gpios = < BOOT_12 GPIO_ACTIVE_LOW>;
- };
-
leds {
compatible = "gpio-leds";
@@ -45,96 +23,6 @@
};
};
- tflash_vdd: regulator-tflash_vdd {
- compatible = "regulator-fixed";
-
- regulator-name = "TFLASH_VDD";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
-
- gpio = <_ao GPIOAO_3 GPIO_OPEN_DRAIN>;
- enable-active-high;
- regulator-always-on;
- };
-
- tf_io: gpio-regulator-tf_io {
- compatible = "regulator-gpio";
-
- regulator-name = "TF_IO";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
-
- gpios = <_ao GPIOAO_6 GPIO_ACTIVE_HIGH>;
- gpios-states = <0>;
-
- states = <330 0>,
-<180 1>;
- };
-
- flash_1v8: regulator-flash_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "FLASH_1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- vin-supply = <_3v3>;
- regulator-always-on;
- };
-
- main_12v: regulator-main_12v {
- compatible = "regulator-fixed";
- regulator-name = "12V";
- regulator-min-microvolt = <1200>;
- regulator-max-microvolt = <1200>;
- regulator-always-on;
- };
-
- vcc_5v: regulator-vcc_5v {
- compatible = "regulator-fixed";
- regulator-name = "5V";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- regulator-always-on;
- vin-supply = <_12v>;
- };
-
- vcc_1v8: regulator-vcc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- vin-supply = <_3v3>;
- regulator-always-on;
- };
-
- vcc_3v3: regulator-vcc_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- vin-supply = <_3v3>;
- regulator-always-on;
- /* FIXME: actually controlled by VDDCPU_B_EN */
- };
-
- vddcpu: regulator-vddcpu {
- /*
-* MP8756GD Regulator.
-*/
- compatible = "pwm-regulator";
-
- regulator-name = "VDDCPU";
- regulator-min-microvolt = <721000>;
- regulator-max-microvolt = <1022000>;
-
- vin-supply = <_12v>;
-
- pwms = <_AO_cd 1 1250 0>;
- pwm-dutycycle-range = <100 0>;
-
- regulator-boot-on;
- regulator-always-on;
- };
-
hub_5v: regulator-hub_5v {
compatible = "regulator-fixed";
regulator-name = "HUB_5V";
@@ -147,215 +35,12 @@
enable-active-high;
};
- usb_pwr_en: regulator-usb_pwr_en {
- compatible = "regulator-fixed";
- regulator-name = "USB_PWR_EN";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <_5v>;
-
- /*
[PATCH v2 4/5] dt-bindings: arm: amlogic: add ODROID-HC4 bindings
Add the board bindings for the ODROID-HC4 device. Signed-off-by: Christian Hewitt --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index b21ba8ba23dd..5f6769bf45bd 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -165,6 +165,7 @@ properties: items: - enum: - hardkernel,odroid-c4 + - hardkernel,odroid-hc4 - khadas,vim3l - seirobotics,sei610 - const: amlogic,sm1 -- 2.17.1
[PATCH v2 2/5] arm64: dts: meson: sort Amlogic dtb Makefile
Sort the Makefile before adding new SM1 devices. Signed-off-by: Christian Hewitt Acked-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile index dce41cd3f347..f3c8a85fe987 100644 --- a/arch/arm64/boot/dts/amlogic/Makefile +++ b/arch/arm64/boot/dts/amlogic/Makefile @@ -45,7 +45,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-libretech-pc.dtb dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb -dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb +dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb dtb-$(CONFIG_ARCH_MESON) += meson-a1-ad401.dtb -- 2.17.1
[PATCH v2 0/5] arm64: dts: meson: add support for ODROID-HC4
This series fixes minor sort-order issues in the Amlogic bindings yaml and dtb Makefile, then converts the existing ODROID-C2 dts into dtsi so we can support its new sister product the ODROID-HC4. I've also given the devices different audio card names. This is partly cosmetic, but also because HC4 is HDMI-only while C4 can be used with other i2c audio devices via an expansion connector so users may want to use different alsa configs. Patches to support the spifc chip are still being upstreamed [0] so this will be addressed in a follow up. A WIP patch for the dts change can be found in my amlogic-5.11.y dev branch [1]. For reference, here's dmesg from LibreELEC on 5.11-rc5 [2]. Changes since v1: - fix ODRIOD typo in patch 3 - fix SPI-NOT size in patch 5 - add Neil's Acks/Reviews [0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20201220224314.2659-1-andr...@rammhold.de/ [1] https://github.com/chewitt/linux/commits/amlogic-5.11.y [2] http://ix.io/2NCi Christian Hewitt (5): dt-bindings: arm: amlogic: sort SM1 bindings arm64: dts: meson: sort Amlogic dtb Makefile arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi dt-bindings: arm: amlogic: add ODROID-HC4 bindings arm64: dts: meson: add initial device-tree for ODROID-HC4 .../devicetree/bindings/arm/amlogic.yaml | 5 +- arch/arm64/boot/dts/amlogic/Makefile | 3 +- .../boot/dts/amlogic/meson-sm1-odroid-c4.dts | 427 + .../boot/dts/amlogic/meson-sm1-odroid-hc4.dts | 96 .../boot/dts/amlogic/meson-sm1-odroid.dtsi| 441 ++ 5 files changed, 543 insertions(+), 429 deletions(-) create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi -- 2.17.1
Re: arm: sunxi: &83t: WARNING: CPU: 2 PID: 57 at drivers/thermal/thermal_core.c:563 thermal_zone_device_update
Hi, On Sun, Jan 31, 2021 at 12:54 AM Corentin Labbe wrote: > > Hello > > When booting next-20210128, I got the following warning on by bpim3 > 6.148421] [ cut here ] > [6.153145] WARNING: CPU: 2 PID: 57 at drivers/thermal/thermal_core.c:563 > thermal_zone_device_update+0x134/0x154 > [6.163378] 'thermal_zone_device_update' must not be called without > 'get_temp' ops set > [6.171300] Modules linked in: sha256_generic libsha256 > [6.176553] CPU: 2 PID: 57 Comm: kworker/2:1 Not tainted > 5.11.0-rc1-00042-gf3788af62cfe #399 > [6.184984] Hardware name: Allwinner A83t board > [6.189517] Workqueue: events deferred_probe_work_func > [6.194686] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [6.202438] [] (show_stack) from [] > (dump_stack+0x98/0xac) > [6.209666] [] (dump_stack) from [] (__warn+0xc0/0xd8) > [6.216545] [] (__warn) from [] > (warn_slowpath_fmt+0x98/0xc0) > [6.224030] [] (warn_slowpath_fmt) from [] > (thermal_zone_device_update+0x134/0x154) > [6.233426] [] (thermal_zone_device_update) from [] > (__thermal_cooling_device_register+0x334/0x35c) > [6.244204] [] (__thermal_cooling_device_register) from > [] (__cpufreq_cooling_register.constprop.0+0x184/0x294) > [6.256026] [] (__cpufreq_cooling_register.constprop.0) from > [] (of_cpufreq_cooling_register+0x40/0x7c) > [6.267153] [] (of_cpufreq_cooling_register) from [] > (cpufreq_online+0x2b4/0x8f4) > [6.276379] [] (cpufreq_online) from [] > (cpufreq_add_dev+0x6c/0x78) > [6.284383] [] (cpufreq_add_dev) from [] > (subsys_interface_register+0xa4/0xf0) > [6.293344] [] (subsys_interface_register) from [] > (cpufreq_register_driver+0x144/0x2dc) > [6.303169] [] (cpufreq_register_driver) from [] > (dt_cpufreq_probe+0x298/0x3b8) > [6.312215] [] (dt_cpufreq_probe) from [] > (platform_probe+0x5c/0xb8) > [6.320313] [] (platform_probe) from [] > (really_probe+0x1dc/0x3b8) > [6.328231] [] (really_probe) from [] > (driver_probe_device+0x5c/0xb4) > [6.336406] [] (driver_probe_device) from [] > (bus_for_each_drv+0x84/0xc8) > [6.344928] [] (bus_for_each_drv) from [] > (__device_attach+0xe8/0x154) > [6.353189] [] (__device_attach) from [] > (bus_probe_device+0x84/0x8c) > [6.361365] [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [6.370321] [] (deferred_probe_work_func) from [] > (process_one_work+0x1dc/0x438) > [6.379456] [] (process_one_work) from [] > (worker_thread+0x25c/0x55c) > [6.387632] [] (worker_thread) from [] > (kthread+0x124/0x150) > [6.395032] [] (kthread) from [] > (ret_from_fork+0x14/0x24) > [6.402256] Exception stack(0xc12d1fb0 to 0xc12d1ff8) > [6.407307] 1fa0: > > [6.415478] 1fc0: > > [6.423648] 1fe0: 0013 > [6.430301] ---[ end trace bd63a5c976f3611c ]--- > > I bisected the problem to > ARM: dts: sunxi: Remove thermal zones without trip points > > Reverting this commit remove the warning. The thermal subsystem seems to require a thermal zone be present for each thermal sensor that is registered. So maybe a better solution is not to remove the thermal zones without trip points, but just add the standard passive and critical trip points based on the SoC's thermal limits. ChenYu
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Sat, Jan 30, 2021 at 04:18:04PM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > our job is to make Linux work for everyone. > > But as your refusal to accept the purely additive (zero impact on > anything other than specific hw in question) patch adding support for > a new hardware device clearly indicates, your job is NOT to make Linux > work for everyone, but rather for a smaller subset of "everyone" > *other than* hardware designers who come to the maintainers in good > faith, asking to mainline support for new hardware they just made. Anything we take adds work to our overall effort to support that new feature added. And you are asking us to do that work for you, for free, for forever. Sorry, given that your attitude does not understand that this is a community and we need to work together, I don't think it's worth continuing here, sorry. If you change your mind in the future, you know how to contact us. greg k-h
Re: [PATCH v13 6/8] drm/mediatek: enable dither function
On Sun, Jan 31, 2021 at 11:40 AM Chun-Kuang Hu wrote:
>
> Hi, Hsin-Yi:
>
> Hsin-Yi Wang 於 2021年1月29日 週五 下午5:23寫道：
> >
> > From: Yongqiang Niu
> >
> > Enable dither function to improve the display quality for dither
> > supported bpc 4, 6, 8. For not supported bpc, use relay mode.
> >
> > Signed-off-by: Yongqiang Niu
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index ac2cb25620357..5761dd15eedf2 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -53,6 +53,7 @@
> > #define DITHER_EN BIT(0)
> > #define DISP_DITHER_CFG0x0020
> > #define DITHER_RELAY_MODE BIT(0)
> > +#define DITHER_ENGINE_EN BIT(1)
> > #define DISP_DITHER_SIZE 0x0030
> >
> > #define LUT_10BIT_MASK 0x03ff
> > @@ -314,9 +315,17 @@ static void mtk_dither_config(struct device *dev,
> > unsigned int w,
> > unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> > {
> > struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > -
> > - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> > DISP_DITHER_SIZE);
> > - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > priv->regs, DISP_DITHER_CFG);
> > + bool valid_bpc = (bpc == 4 || bpc == 6 || bpc == 8);
> > +
> > + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> > + DISP_DITHER_SIZE);
> > + if (valid_bpc)
> > + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> > + DISP_DITHER_CFG, DITHER_ENGINE_EN,
> > + cmdq_pkt);
> > + else
> > + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> > + priv->regs, DISP_DITHER_CFG);
>
> od has relay mode,
>
> static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
> unsigned int h, unsigned int vrefresh,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> {
> mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_OD_SIZE);
> mtk_ddp_write(cmdq_pkt, OD_RELAYMODE, comp, DISP_OD_CFG);
> mtk_dither_set(comp, bpc, DISP_OD_CFG, cmdq_pkt);
> }
>
> and it does not check valid bpc (I think drm core already set bpc to
> 4, 6, 8 or 0), so align implementation of mtk_dither_config() with
> mtk_od_config().
> gamma also has relay mode (refer to [1] page 689), but we need to
> enable gamma's gamma function, so we do not set gamma to relay mode.
> So I think maybe we could implement mtk_dither_config() as:
>
> mtk_dither_config()
> {
> mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
> priv->regs, DISP_DITHER_SIZE);
> mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> priv->regs, DISP_DITHER_CFG);
> mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> DISP_DITHER_CFG, DITHER_ENGINE_EN, cmdq_pkt);
> }
>
> [1]
> https://www.96boards.org/documentation/consumer/mediatekx20/additional-docs/docs/MT6797_Register_Table_Part_2.pdf
>
> Regards,
> Chun-Kuang.
>
Hi CK,
I send the patch here:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210131051058.3407985-1-hsi...@chromium.org/
as others are already merged to the tree.
Thanks
> > }
> >
> > static void mtk_dither_start(struct device *dev)
> > --
> > 2.30.0.365.g02bc693789-goog
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
[PATCH] drm/mediatek: enable dither function
From: Yongqiang Niu
Enable dither function to improve the display quality.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
---
Previous version:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210129092209.2584718-7-hsi...@chromium.org/
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index c730029ac8fc7..0444b429daf00 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -53,6 +53,7 @@
#define DITHER_EN BIT(0)
#define DISP_DITHER_CFG0x0020
#define DITHER_RELAY_MODE BIT(0)
+#define DITHER_ENGINE_EN BIT(1)
#define DISP_DITHER_SIZE 0x0030
#define LUT_10BIT_MASK 0x03ff
@@ -315,8 +316,12 @@ static void mtk_dither_config(struct device *dev, unsigned
int w,
{
struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
- mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
DISP_DITHER_SIZE);
- mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg, priv->regs,
DISP_DITHER_CFG);
+ mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
+ DISP_DITHER_SIZE);
+ mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg, priv->regs,
+ DISP_DITHER_CFG);
+ mtk_dither_set_common(priv->regs, >cmdq_reg, bpc, DISP_DITHER_CFG,
+ DITHER_ENGINE_EN, cmdq_pkt);
}
static void mtk_dither_start(struct device *dev)
--
2.30.0.365.g02bc693789-goog
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/clk/clk-fsl-flexspi.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 6642d600b541b81931fb1ab0c041b0d68f77be7e commit: fcf77be87eacb8f305528d24d892dfcf15cf0341 clk: fsl-flexspi: new driver date: 8 weeks ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf77be87eacb8f305528d24d892dfcf15cf0341 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout fcf77be87eacb8f305528d24d892dfcf15cf0341 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-devres.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-legacy.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-of.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpiolib-cdev.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-mmio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-74xx-mmio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-adnp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-adp5588.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-altera.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-amd-fch.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-xgs-iproc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-bd70528.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-bd71828.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-bd9571mwv.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-cadence.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-dln2.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-dwapb.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-eic-sprd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-ftgpio010.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-grgpio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-gw-pld.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-kempld.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-logicvc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-lp3943.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-lp873x.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-lp87565.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-max732x.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/gpio/gpio-max77620.o' being
Re: [PATCH net-next 9/9] net: ipa: don't disable NAPI in suspend
On 1/30/21 1:22 PM, Jakub Kicinski wrote: On Sat, 30 Jan 2021 10:25:16 -0500 Willem de Bruijn wrote: @@ -894,12 +894,16 @@ int gsi_channel_start(struct gsi *gsi, u32 channel_id) struct gsi_channel *channel = >channel[channel_id]; int ret; - /* Enable the completion interrupt */ + /* Enable NAPI and the completion interrupt */ + napi_enable(>napi); gsi_irq_ieob_enable_one(gsi, channel->evt_ring_id); ret = __gsi_channel_start(channel, true); - if (ret) - gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id); + if (!ret) + return 0; + + gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id); + napi_disable(>napi); return ret; } subjective, but easier to parse when the normal control flow is linear and the error path takes a branch (or goto, if reused). FWIW - fully agreed, I always thought this was part of the kernel coding style. That's fine. I will post a v2 of the series to fix this up. I'll wait a bit (maybe until Monday morning), in case there's any other input on the series to address. Thanks both of you for your comments. -Alex
Re: [kbuild-all] aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/trace_recursion_record.o' being placed in section `.eh_frame'
On Sun, Jan 31, 2021 at 10:09:22AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 > commit: 773c16705058e9be7b0f4ce124e89cd231c120a2 ftrace: Add recording of > functions that caused recursion > date: 3 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773c16705058e9be7b0f4ce124e89cd231c120a2 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 773c16705058e9be7b0f4ce124e89cd231c120a2 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot Sorry, kindly ignore this false positive > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/irq_sim.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/proc.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/cpuhotplug.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/msi.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/ipi.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/affinity.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/irq/debugfs.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/update.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/sync.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/srcutree.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/rcuscale.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/refscale.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/tree.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/rcu/rcu_segcblist.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/mapping.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/direct.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/ops_helpers.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/dummy.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/coherent.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/swiotlb.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/pool.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/dma/remap.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/freezer.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/profile.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `kernel/stacktrace.o' being placed in section `.eh_frame' >aarch64-linux-g
Re: [kbuild-all] aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/tty/serial/liteuart.o' being placed in section `.eh_frame'
On Sun, Jan 31, 2021 at 11:36:33AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 6642d600b541b81931fb1ab0c041b0d68f77be7e > commit: 1da81e5562fac8286567422cc56a7fbd0dc646d4 drivers/tty/serial: add > LiteUART driver > date: 3 months ago > config: arm64-randconfig-r013-20210130 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project > 275c6af7d7f1ed63a03d05b4484413e447133269) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1da81e5562fac8286567422cc56a7fbd0dc646d4 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 1da81e5562fac8286567422cc56a7fbd0dc646d4 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot Sorry, kindly ignore this false positive. > > All warnings (new ones prefixed by >>): > >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max77650-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8649.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8660.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8925-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max8952.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max77802-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/max77826-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mcp16502.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mp8859.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mpq7920.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mt6311-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mt6360-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/mt6397-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/qcom-labibb-regulator.o' being placed in section > `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/qcom_spmi-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/palmas-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pca9450-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pfuze100-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pv88060-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pv88090-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/tps51632-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/pcf50633-regulator.o' being placed in section `.eh_frame' >aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from > `drivers/regulator/rp
linux-next: Signed-off-by missing for commit in the parisc-hd tree
Hi all,
Commit
ca7222dcfff4 ("parisc: Bump 64-bit IRQ stack size to 64 KB")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpOlEOC_U0dq.pgp
Description: OpenPGP digital signature
Re: [PATCH net-next 9/9] net: ipa: don't disable NAPI in suspend
On 1/30/21 9:25 AM, Willem de Bruijn wrote: On Fri, Jan 29, 2021 at 3:29 PM Alex Elder wrote: The channel stop and suspend paths both call __gsi_channel_stop(), which quiesces channel activity, disables NAPI, and (on other than SDM845) stops the channel. Similarly, the start and resume paths share __gsi_channel_start(), which starts the channel and re-enables NAPI again. Disabling NAPI should be done when stopping a channel, but this should *not* be done when suspending. It's not necessary in the suspend path anyway, because the stopped channel (or suspended endpoint on SDM845) will not cause interrupts to schedule NAPI, and gsi_channel_trans_quiesce() won't return until there are no more transactions to process in the NAPI polling loop. But why is it incorrect to do so? Maybe it's not; I also thought it was fine before, but... Someone at Qualcomm asked me why I thought NAPI needed to be disabled on suspend. My response was basically that it was a lightweight operation, and it shouldn't really be a problem to do so. Then, when I posted two patches last month, Jakub's response told me he didn't understand why I was doing what I was doing, and I stepped back to reconsider the details of what was happening at suspend time. https://lore.kernel.org/netdev/20210107183803.47308...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/ Four things were happening to suspend a channel: quiesce activity; disable interrupt; disable NAPI; and stop the channel. It occurred to me that a stopped channel would not generate interrupts, so if the channel was stopped earlier there would be no need to disable the interrupt. Similarly there would be (essentially) no need to disable NAPI once a channel was stopped. Underlying all of this is that I started chasing a hang that was occurring on suspend over a month ago. It was hard to reproduce (hundreds or thousands of suspend/resume cycles without hitting it), and one of the few times I actually hit the problem it was stuck in napi_disable(), apparently waiting for NAPI_STATE_SCHED to get cleared by napi_complete(). My best guess about how this could occur was if there were a race of some kind between the interrupt handler (scheduling NAPI) and the poll function (completing it). I found a number of problems while looking at this, and in the past few weeks I've posted some fixes to improve things. Still, even with some of these fixes in place we have seen a hang (but now even more rarely). So this grand rework of suspending/stopping channels is an attempt to resolve this hang on suspend. The channel is now stopped early, and once stopped, everything that completed prior to the channel being stopped is polled before considering the suspend function done. A stopped channel won't interrupt, so we don't bother disabling the completion interrupt, with no interrupts, NAPI won't be scheduled, so there's no need to disable NAPI either. The net result is simpler, and seems logical, and should preclude any possible race between the interrupt handler and poll function. I'm trying to solve the hang problem analytically, because it takes *so* long to reproduce. I'm open to other suggestions. -Alex From a quick look, virtio-net disables on both remove and freeze, for instance. Instead, enable NAPI in gsi_channel_start(), when the completion interrupt is first enabled. Disable it again in gsi_channel_stop(), when finally disabling the interrupt. Add a call to napi_synchronize() to __gsi_channel_stop(), to ensure NAPI polling is done before moving on. Signed-off-by: Alex Elder --- = @@ -894,12 +894,16 @@ int gsi_channel_start(struct gsi *gsi, u32 channel_id) struct gsi_channel *channel = >channel[channel_id]; int ret; - /* Enable the completion interrupt */ + /* Enable NAPI and the completion interrupt */ + napi_enable(>napi); gsi_irq_ieob_enable_one(gsi, channel->evt_ring_id); ret = __gsi_channel_start(channel, true); - if (ret) - gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id); + if (!ret) + return 0; + + gsi_irq_ieob_disable_one(gsi, channel->evt_ring_id); + napi_disable(>napi); return ret; } subjective, but easier to parse when the normal control flow is linear and the error path takes a branch (or goto, if reused).
Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls
On Sat, 2021-01-30 at 19:36 -0800, Guenter Roeck wrote: > On 1/30/21 4:41 PM, James Bottomley wrote: > > On Sat, 2021-01-30 at 15:49 -0800, Guenter Roeck wrote: > > > On 1/29/21 2:59 PM, Jarkko Sakkinen wrote: > > > > On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łukasz Majczak wrote: > > > > > Hi Jarkko, Guenter > > > > > > > > > > Yes, here are the logs when failure occurs - > > > > > https://gist.github.com/semihalf-majczak-lukasz/1575461f585f1e7fb1e9366b8eceaab9 > > > > > Look for a phrase "TPM returned invalid status" > > > > > > > > > > Guenter - good suggestion - I will try to keep it as tight as > > > > > possible. > > > > > > > > > > Best regards, > > > > > Lukasz > > > > > > > > Is it possible for you try out with linux-next? Thanks. It's a > > > > known issue, which ought to be fixed by now. > > > > > > > > The log message is harmless, it'a warning not panic, and does > > > > not endanger system stability. WARN()'s always dump stack > > > > trace. No oops is happening. > > > > > > > > > > There is a note in the kernel documentation which states: > > > > > > Note that the WARN()-family should only be used for "expected to > > > be unreachable" situations. If you want to warn about "reachable > > > but undesirable" situations, please use the pr_warn()-family of > > > functions. > > > > It fits the definition. The warning only triggers if the access is > > in the wrong locality, which should be impossible, so the warning > > should be unreachable. > > > Thanks a lot for the clarification. So a warning traceback in the > kernel doesn't necessarily suggest that there is a serious problem > that should be fixed; it only means that some code is executed which > should not be reachable (but is otherwise harmless). > > That makes me wonder, though, if it would make sense to mark such > harmless tracebacks differently. The terms "warning" and "harmless" > sound like a bit of a contradiction to me (especially for systems > where panic_on_warn is set). Well, it's not harmless; because it occurs at start of day, it means we clear the ineffective command and use default values and those happen to work fine for the TPM in question, so the problem is pretty much covered up. If it had occurred anywhere else it would result in a loss of the command data with unknown ramifications to user space, possibly leading to a TPM failure. Hopefully this means this is the only place we screwed up, but you can see why a scary warning and stack trace is appropriate: if it triggers, something in the kernel violated the TPM command model. James
ERROR: modpost: ".bin2hex" undefined!
Hi Tuong, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 commit: f779bf792284fed78fedee61b46df2d4652636d3 tipc: optimize key switching time and logic date: 4 months ago config: powerpc64-randconfig-c003-20210130 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f779bf792284fed78fedee61b46df2d4652636d3 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout f779bf792284fed78fedee61b46df2d4652636d3 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: ".trace_seq_printf" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".kmem_cache_alloc" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".idr_alloc_u32" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".sock_alloc_file" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".kernel_read" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".printk" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".trace_event_ignore_this_pid" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".__list_del_entry_valid" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".trace_print_symbols_seq" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".remove_wait_queue" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".__stack_chk_fail" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp4" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".fget" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".make_kuid" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".strcmp" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".match_int" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".dump_stack" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".trace_handle_return" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".kmem_cache_destroy" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".match_strdup" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".recalc_sigpending" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".idr_find" [net/9p/9pnet.ko] undefined! ERROR: modpost: ".cancel_delayed_work_sync" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: "._raw_spin_unlock_irqrestore" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__warn_printk" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".input_open_device" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".mod_delayed_work_on" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_cmp4" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".kmem_cache_alloc_trace" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".device_add" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__mutex_init" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".input_close_device" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".strlen" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".led_trigger_register" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: "._copy_to_user" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".init_timer_key" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".input_register_handle" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_cmp1" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".capable" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".cancel_work_sync" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__init_waitqueue_head" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".stream_open" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp8" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".queue_delayed_work_on" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".__class_register" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".finish_wait" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".kstrtoull" [net/rfkill/rfkill.ko] undefined! ERROR: modpost: ".led_trigger_unregister" [net/rfkill/rfkill.ko] undefined! ERROR:
Re: [PATCH v4 5/8] drm/mediatek: separate ccorr module
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2021年1月29日 週五 下午3:35寫道：
>
> From: Yongqiang Niu
>
> ccorr ctm matrix bits will be different in mt8192
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 222
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 95 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 242 insertions(+), 96 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
>
[snip]
> +
> +void mtk_ccorr_config(struct device *dev, unsigned int w,
> +unsigned int h, unsigned int vrefresh,
> +unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_disp_ccorr *ccorr = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, ccorr->regs,
> + DISP_CCORR_SIZE);
You change w, h position here. Separate this modification to another patch.
> + mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, >cmdq_reg,
> ccorr->regs,
> + DISP_CCORR_CFG);
> +}
> +
[snip]
> -static void mtk_ccorr_config(struct device *dev, unsigned int w,
> -unsigned int h, unsigned int vrefresh,
> -unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> -{
> - struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> -
> - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> DISP_CCORR_SIZE);
> - mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, >cmdq_reg, priv->regs,
> DISP_CCORR_CFG);
> -}
> -
Re: [PATCH v4 4/8] drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
Hi, Hsin-Yi:
CK Hu 於 2021年1月29日 週五 下午4:21寫道：
>
> Hi, Hsin-Yi:
>
> On Fri, 2021-01-29 at 15:34 +0800, Hsin-Yi Wang wrote:
> > From: Yongqiang Niu
> >
> > enable OVL_LAYER_SMI_ID_EN for multi-layer usecase, without this patch,
> > ovl will hang up when more than 1 layer enabled.
>
> Reviewed-by: CK Hu
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> >
> > Signed-off-by: Yongqiang Niu
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index da7e38a28759b..961f87f8d4d15 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -24,6 +24,7 @@
> > #define DISP_REG_OVL_RST 0x0014
> > #define DISP_REG_OVL_ROI_SIZE0x0020
> > #define DISP_REG_OVL_DATAPATH_CON0x0024
> > +#define OVL_LAYER_SMI_ID_EN BIT(0)
> > #define OVL_BGCLR_SEL_IN BIT(2)
> > #define DISP_REG_OVL_ROI_BGCLR 0x0028
> > #define DISP_REG_OVL_SRC_CON 0x002c
> > @@ -62,6 +63,7 @@ struct mtk_disp_ovl_data {
> > unsigned int gmc_bits;
> > unsigned int layer_nr;
> > bool fmt_rgb565_is_0;
> > + bool smi_id_en;
> > };
> >
> > /**
> > @@ -134,6 +136,13 @@ void mtk_ovl_start(struct device *dev)
> > {
> > struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
> >
> > + if (ovl->data->smi_id_en) {
> > + unsigned int reg;
> > +
> > + reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> > + reg = reg | OVL_LAYER_SMI_ID_EN;
> > + writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> > + }
> > writel_relaxed(0x1, ovl->regs + DISP_REG_OVL_EN);
> > }
> >
> > @@ -142,6 +151,14 @@ void mtk_ovl_stop(struct device *dev)
> > struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
> >
> > writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_EN);
> > + if (ovl->data->smi_id_en) {
> > + unsigned int reg;
> > +
> > + reg = readl(ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> > + reg = reg & ~OVL_LAYER_SMI_ID_EN;
> > + writel_relaxed(reg, ovl->regs + DISP_REG_OVL_DATAPATH_CON);
> > + }
> > +
> > }
> >
> > void mtk_ovl_config(struct device *dev, unsigned int w,
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 6/8] drm/mediatek: enable dither function
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2021年1月29日 週五 下午5:23寫道：
>
> From: Yongqiang Niu
>
> Enable dither function to improve the display quality for dither
> supported bpc 4, 6, 8. For not supported bpc, use relay mode.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index ac2cb25620357..5761dd15eedf2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -53,6 +53,7 @@
> #define DITHER_EN BIT(0)
> #define DISP_DITHER_CFG0x0020
> #define DITHER_RELAY_MODE BIT(0)
> +#define DITHER_ENGINE_EN BIT(1)
> #define DISP_DITHER_SIZE 0x0030
>
> #define LUT_10BIT_MASK 0x03ff
> @@ -314,9 +315,17 @@ static void mtk_dither_config(struct device *dev,
> unsigned int w,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> {
> struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> -
> - mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> DISP_DITHER_SIZE);
> - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> priv->regs, DISP_DITHER_CFG);
> + bool valid_bpc = (bpc == 4 || bpc == 6 || bpc == 8);
> +
> + mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> + DISP_DITHER_SIZE);
> + if (valid_bpc)
> + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
> + DISP_DITHER_CFG, DITHER_ENGINE_EN,
> + cmdq_pkt);
> + else
> + mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
> + priv->regs, DISP_DITHER_CFG);
od has relay mode,
static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_OD_SIZE);
mtk_ddp_write(cmdq_pkt, OD_RELAYMODE, comp, DISP_OD_CFG);
mtk_dither_set(comp, bpc, DISP_OD_CFG, cmdq_pkt);
}
and it does not check valid bpc (I think drm core already set bpc to
4, 6, 8 or 0), so align implementation of mtk_dither_config() with
mtk_od_config().
gamma also has relay mode (refer to [1] page 689), but we need to
enable gamma's gamma function, so we do not set gamma to relay mode.
So I think maybe we could implement mtk_dither_config() as:
mtk_dither_config()
{
mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg,
priv->regs, DISP_DITHER_SIZE);
mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg,
priv->regs, DISP_DITHER_CFG);
mtk_dither_set_common(priv->regs, >cmdq_reg, bpc,
DISP_DITHER_CFG, DITHER_ENGINE_EN, cmdq_pkt);
}
[1]
https://www.96boards.org/documentation/consumer/mediatekx20/additional-docs/docs/MT6797_Register_Table_Part_2.pdf
Regards,
Chun-Kuang.
> }
>
> static void mtk_dither_start(struct device *dev)
> --
> 2.30.0.365.g02bc693789-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/tty/serial/liteuart.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 6642d600b541b81931fb1ab0c041b0d68f77be7e commit: 1da81e5562fac8286567422cc56a7fbd0dc646d4 drivers/tty/serial: add LiteUART driver date: 3 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1da81e5562fac8286567422cc56a7fbd0dc646d4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1da81e5562fac8286567422cc56a7fbd0dc646d4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max77650-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8649.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8660.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8925-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max8952.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max77802-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/max77826-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mcp16502.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mp8859.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mpq7920.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mt6311-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mt6360-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/mt6397-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/qcom-labibb-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/qcom_spmi-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/palmas-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pca9450-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pfuze100-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pv88060-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pv88090-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/tps51632-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/pcf50633-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/rpi-panel-attiny-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/rk808-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/rohm-regulator.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/regulator/rt5033-regulator.o' being placed in section `.eh_frame' aarch64-lin
Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls
On 1/30/21 4:41 PM, James Bottomley wrote: > On Sat, 2021-01-30 at 15:49 -0800, Guenter Roeck wrote: >> On 1/29/21 2:59 PM, Jarkko Sakkinen wrote: >>> On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łukasz Majczak wrote: Hi Jarkko, Guenter Yes, here are the logs when failure occurs - https://gist.github.com/semihalf-majczak-lukasz/1575461f585f1e7fb1e9366b8eceaab9 Look for a phrase "TPM returned invalid status" Guenter - good suggestion - I will try to keep it as tight as possible. Best regards, Lukasz >>> >>> Is it possible for you try out with linux-next? Thanks. It's a >>> known issue, which ought to be fixed by now. >>> >>> The log message is harmless, it'a warning not panic, and does not >>> endanger system stability. WARN()'s always dump stack trace. No >>> oops is happening. >>> >> >> There is a note in the kernel documentation which states: >> >> Note that the WARN()-family should only be used for "expected to >> be unreachable" situations. If you want to warn about "reachable >> but undesirable" situations, please use the pr_warn()-family of >> functions. > > It fits the definition. The warning only triggers if the access is in > the wrong locality, which should be impossible, so the warning should > be unreachable. > Thanks a lot for the clarification. So a warning traceback in the kernel doesn't necessarily suggest that there is a serious problem that should be fixed; it only means that some code is executed which should not be reachable (but is otherwise harmless). That makes me wonder, though, if it would make sense to mark such harmless tracebacks differently. The terms "warning" and "harmless" sound like a bit of a contradiction to me (especially for systems where panic_on_warn is set). Thanks, Guenter
Re: [RFC 00/20] TLB batching consolidation and enhancements
Excerpts from Nadav Amit's message of January 31, 2021 10:11 am:
> From: Nadav Amit
>
> There are currently (at least?) 5 different TLB batching schemes in the
> kernel:
>
> 1. Using mmu_gather (e.g., zap_page_range()).
>
> 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the
>ongoing deferred TLB flush and flushing the entire range eventually
>(e.g., change_protection_range()).
>
> 3. arch_{enter|leave}_lazy_mmu_mode() for sparc and powerpc (and Xen?).
>
> 4. Batching per-table flushes (move_ptes()).
>
> 5. By setting a flag on that a deferred TLB flush operation takes place,
>flushing when (try_to_unmap_one() on x86).
>
> It seems that (1)-(4) can be consolidated. In addition, it seems that
> (5) is racy. It also seems there can be many redundant TLB flushes, and
> potentially TLB-shootdown storms, for instance during batched
> reclamation (using try_to_unmap_one()) if at the same time mmu_gather
> defers TLB flushes.
>
> More aggressive TLB batching may be possible, but this patch-set does
> not add such batching. The proposed changes would enable such batching
> in a later time.
>
> Admittedly, I do not understand how things are not broken today, which
> frightens me to make further batching before getting things in order.
> For instance, why is ok for zap_pte_range() to batch dirty-PTE flushes
> for each page-table (but not in greater granularity). Can't
> ClearPageDirty() be called before the flush, causing writes after
> ClearPageDirty() and before the flush to be lost?
Because it's holding the page table lock which stops page_mkclean from
cleaning the page. Or am I misunderstanding the question?
I'll go through the patches a bit more closely when they all come
through. Sparc and powerpc of course need the arch lazy mode to get
per-page/pte information for operations that are not freeing pages,
which is what mmu gather is designed for.
I wouldn't mind using a similar API so it's less of a black box when
reading generic code, but it might not quite fit the mmu gather API
exactly (most of these paths don't want a full mmu_gather on stack).
>
> This patch-set therefore performs the following changes:
>
> 1. Change mprotect, task_mmu and mapping_dirty_helpers to use mmu_gather
>instead of {inc|dec}_tlb_flush_pending().
>
> 2. Avoid TLB flushes if PTE permission is not demoted.
>
> 3. Cleans up mmu_gather to be less arch-dependant.
>
> 4. Uses mm's generations to track in finer granularity, either per-VMA
>or per page-table, whether a pending mmu_gather operation is
>outstanding. This should allow to avoid some TLB flushes when KSM or
>memory reclamation takes place while another operation such as
>munmap() or mprotect() is running.
>
> 5. Changes try_to_unmap_one() flushing scheme, as the current seems
>broken to track in a bitmap which CPUs have outstanding TLB flushes
>instead of having a flag.
Putting fixes first, and cleanups and independent patches (like #2) next
would help with getting stuff merged and backported.
Thanks,
Nick
Re: [PATCH net] net: hdlc_x25: Use qdisc to queue outgoing LAPB frames
On Sat, Jan 30, 2021 at 11:16 AM Jakub Kicinski wrote: > > Sounds like too much afford for a sub-optimal workaround. > The qdisc semantics are borken in the proposed scheme (double > counting packets) - both in term of statistics and if user decides > to add a policer, filter etc. Hmm... Another solution might be creating another virtual device on top of the HDLC device (similar to what "hdlc_fr.c" does), so that we can first queue L3 packets in the virtual device's qdisc queue, and then queue the L2 frames in the actual HDLC device's qdisc queue. This way we can avoid the same outgoing data being queued to qdisc twice. But this would significantly change the way the user uses the hdlc_x25 driver. > Another worry is that something may just inject a packet with > skb->protocol == ETH_P_HDLC but unexpected structure (IDK if > that's a real concern). This might not be a problem. Ethernet devices also allow the user to inject raw frames with user constructed headers. "hdlc_fr.c" also allows the user to bypass the virtual circuit interfaces and inject raw frames directly on the HDLC interface. I think the receiving side should be able to recognize and drop invalid frames. > It may be better to teach LAPB to stop / start the internal queue. > The lower level drivers just needs to call LAPB instead of making > the start/wake calls directly to the stack, and LAPB can call the > stack. Would that not work? I think this is a good solution. But this requires changing a lot of code. The HDLC subsystem needs to be changed to allow HDLC Hardware Drivers to ask HDLC Protocol Drivers (like hdlc_x25.c) to stop/wake the TX queue. The hdlc_x25.c driver can then ask the LAPB module to stop/wake the queue. So this means new APIs need to be added to both the HDLC subsystem and the LAPB module, and a number of HDLC Hardware Drivers need to be changed to call the new API of the HDLC subsystem. Martin, do you have any suggestions?
Re: [PATCH v3 1/3] x509: Detect sm2 keys by their parameters OID
On 1/30/21 4:26 PM, Jarkko Sakkinen wrote:
On Wed, 2021-01-27 at 07:33 -0500, Stefan Berger wrote:
From: Stefan Berger
Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.
Signed-off-by: Stefan Berger
---
crypto/asymmetric_keys/x509_cert_parser.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..4643fe5ed69a 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -459,6 +459,7 @@ int x509_extract_key_data(void *context, size_t hdrlen,
const void *value, size_t vlen)
{
struct x509_parse_context *ctx = context;
+ enum OID oid;
ctx->key_algo = ctx->last_oid;
switch (ctx->last_oid) {
@@ -470,7 +471,17 @@ int x509_extract_key_data(void *context, size_t hdrlen,
ctx->cert->pub->pkey_algo = "ecrdsa";
break;
case OID_id_ecPublicKey:
- ctx->cert->pub->pkey_algo = "sm2";
+ if (ctx->params_size < 2)
Either a named constant, or at least a comment instead of just '2'.
I will look at the 2 entries whether they contain the expected values:
ASN1_OID and length
Thanks!
Stefan
Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion
On Sat, Jan 30, 2021 at 5:17 PM Nadav Amit wrote:
>
> > On Jan 30, 2021, at 5:07 PM, Andy Lutomirski wrote:
> >
> > Adding Andrew Cooper, who has a distressingly extensive understanding
> > of the x86 PTE magic.
> >
> > On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
> >> From: Nadav Amit
> >>
> >> Currently, using mprotect() to unprotect a memory region or uffd to
> >> unprotect a memory region causes a TLB flush. At least on x86, as
> >> protection is promoted, no TLB flush is needed.
> >>
> >> Add an arch-specific pte_may_need_flush() which tells whether a TLB
> >> flush is needed based on the old PTE and the new one. Implement an x86
> >> pte_may_need_flush().
> >>
> >> For x86, besides the simple logic that PTE protection promotion or
> >> changes of software bits does require a flush, also add logic that
> >> considers the dirty-bit. If the dirty-bit is clear and write-protect is
> >> set, no TLB flush is needed, as x86 updates the dirty-bit atomically
> >> on write, and if the bit is clear, the PTE is reread.
> >>
> >> Signed-off-by: Nadav Amit
> >> Cc: Andrea Arcangeli
> >> Cc: Andrew Morton
> >> Cc: Andy Lutomirski
> >> Cc: Dave Hansen
> >> Cc: Peter Zijlstra
> >> Cc: Thomas Gleixner
> >> Cc: Will Deacon
> >> Cc: Yu Zhao
> >> Cc: Nick Piggin
> >> Cc: x...@kernel.org
> >> ---
> >> arch/x86/include/asm/tlbflush.h | 44 +
> >> include/asm-generic/tlb.h | 4 +++
> >> mm/mprotect.c | 3 ++-
> >> 3 files changed, 50 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/include/asm/tlbflush.h
> >> b/arch/x86/include/asm/tlbflush.h
> >> index 8c87a2e0b660..a617dc0a9b06 100644
> >> --- a/arch/x86/include/asm/tlbflush.h
> >> +++ b/arch/x86/include/asm/tlbflush.h
> >> @@ -255,6 +255,50 @@ static inline void arch_tlbbatch_add_mm(struct
> >> arch_tlbflush_unmap_batch *batch,
> >>
> >> extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
> >>
> >> +static inline bool pte_may_need_flush(pte_t oldpte, pte_t newpte)
> >> +{
> >> + const pteval_t ignore_mask = _PAGE_SOFTW1 | _PAGE_SOFTW2 |
> >> +_PAGE_SOFTW3 | _PAGE_ACCESSED;
> >
> > Why is accessed ignored? Surely clearing the accessed bit needs a
> > flush if the old PTE is present.
>
> I am just following the current scheme in the kernel (x86):
>
> int ptep_clear_flush_young(struct vm_area_struct *vma,
>unsigned long address, pte_t *ptep)
> {
> /*
> * On x86 CPUs, clearing the accessed bit without a TLB flush
> * doesn't cause data corruption. [ It could cause incorrect
> * page aging and the (mistaken) reclaim of hot pages, but the
> * chance of that should be relatively low. ]
> *
If anyone ever implements the optimization of skipping the flush when
unmapping a !accessed page, then this will cause data corruption.
If nothing else, this deserves a nice comment in the new code.
> * So as a performance optimization don't flush the TLB when
> * clearing the accessed bit, it will eventually be flushed by
> * a context switch or a VM operation anyway. [ In the rare
> * event of it not getting flushed for a long time the delay
> * shouldn't really matter because there's no real memory
> * pressure for swapout to react to. ]
> */
> return ptep_test_and_clear_young(vma, address, ptep);
> }
>
>
> >
> >> + const pteval_t enable_mask = _PAGE_RW | _PAGE_DIRTY | _PAGE_GLOBAL;
> >> + pteval_t oldval = pte_val(oldpte);
> >> + pteval_t newval = pte_val(newpte);
> >> + pteval_t diff = oldval ^ newval;
> >> + pteval_t disable_mask = 0;
> >> +
> >> + if (IS_ENABLED(CONFIG_X86_64) || IS_ENABLED(CONFIG_X86_PAE))
> >> + disable_mask = _PAGE_NX;
> >> +
> >> + /* new is non-present: need only if old is present */
> >> + if (pte_none(newpte))
> >> + return !pte_none(oldpte);
> >> +
> >> + /*
> >> +* If, excluding the ignored bits, only RW and dirty are cleared
> >> and the
> >> +* old PTE does not have the dirty-bit set, we can avoid a flush.
> >> This
> >> +* is possible since x86 architecture set the dirty bit atomically
> >> while
> >
> > s/set/sets/
> >
> >> +* it caches the PTE in the TLB.
> >> +*
> >> +* The condition considers any change to RW and dirty as not
> >> requiring
> >> +* flush if the old PTE is not dirty or not writable for
> >> simplification
> >> +* of the code and to consider (unlikely) cases of changing
> >> dirty-bit of
> >> +* write-protected PTE.
> >> +*/
> >> + if (!(diff & ~(_PAGE_RW | _PAGE_DIRTY | ignore_mask)) &&
> >> + (!(pte_dirty(oldpte) || !pte_write(oldpte
> >> + return false;
> >
> > This logic seems confusing to me. Is your goal to say that, if the
> >
Re: [RFC 01/20] mm/tlb: fix fullmm semantics
On Sat, Jan 30, 2021 at 5:19 PM Nadav Amit wrote: > > > On Jan 30, 2021, at 5:02 PM, Andy Lutomirski wrote: > > > > On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: > >> From: Nadav Amit > >> > >> fullmm in mmu_gather is supposed to indicate that the mm is torn-down > >> (e.g., on process exit) and can therefore allow certain optimizations. > >> However, tlb_finish_mmu() sets fullmm, when in fact it want to say that > >> the TLB should be fully flushed. > > > > Maybe also rename fullmm? > > Possible. How about mm_torn_down? Sure. Or mm_exiting, perhaps? > > I should have also changed the comment in tlb_finish_mmu().
Re: [REGRESSION] x86/entry: TIF_SINGLESTEP handling is still broken
On Sat, Jan 30, 2021 at 5:56 PM Linus Torvalds wrote: > > On Sat, Jan 30, 2021 at 5:32 PM Kyle Huey wrote: > > > > I tested that with 2991552447707d791d9d81a5dc161f9e9e90b163 reverted > > and Yuxuan's patch applied to Linus's tip rr works and passes all > > tests. > > There's a patch in the -tip tree that hasn't been merged yet: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/urgent > > (there's only that one patch in that branch right now, commit ID > 41c1a06d1d1544bed9692ba72a5692454eee1945). > > It should be making its way my direction any day now, but in the > meantime if you can verify that it makes things work for you, that > would be great.. Right, I'm saying that that is not sufficient. 41c1a06d1d1544bed9692ba72a5692454eee1945 does indeed fix the bug introduced in 64eb35f701f04b30706e21d1b02636b5d31a37d2, but 2991552447707d791d9d81a5dc161f9e9e90b163 introduced another bug that remains unfixed. - Kyle
Re: [GIT] cifs fixes
The pull request you sent on Sat, 30 Jan 2021 12:49:45 -0600: > git://git.samba.org/sfrench/cifs-2.6.git tags/5.11-rc5-smb3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6642d600b541b81931fb1ab0c041b0d68f77be7e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SCSI fixes for 5.11-rc5
The pull request you sent on Sat, 30 Jan 2021 10:38:05 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ad8b3c1e637cf7b827d26917034fa686af74896b Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] OpenRISC fixes for 5.11-rc6
The pull request you sent on Sun, 31 Jan 2021 07:44:42 +0900: > git://github.com/openrisc/linux.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/03e319e5465a2da6fb188c77043775f2888df529 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/trace/trace_recursion_record.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 commit: 773c16705058e9be7b0f4ce124e89cd231c120a2 ftrace: Add recording of functions that caused recursion date: 3 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773c16705058e9be7b0f4ce124e89cd231c120a2 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 773c16705058e9be7b0f4ce124e89cd231c120a2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/irq_sim.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/proc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/cpuhotplug.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/msi.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/ipi.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/affinity.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/irq/debugfs.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/update.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/sync.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/srcutree.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/rcuscale.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/refscale.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/tree.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/rcu/rcu_segcblist.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/mapping.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/direct.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/ops_helpers.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/dummy.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/coherent.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/swiotlb.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/pool.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/dma/remap.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/freezer.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/profile.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/stacktrace.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/time/time.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/time/timer.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/time/hrtimer.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `kernel/time/timekeeping.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: w
Re: [PATCH] csky: change a Kconfig symbol name to fix e1000 build error
Acked-by Thx On Sun, Jan 31, 2021 at 7:50 AM Randy Dunlap wrote: > > e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in > arch/csky/Kconfig. > The symbol in e1000 has been around longer, so change arch/csky/ > to use DRAM_BASE instead of RAM_BASE to remove the conflict. > (although e1000 is also a 2-line change) > > Not tested: I don't have a build toolchain for CSKY. > > Signed-off-by: Randy Dunlap > Reported-by: kernel test robot > Cc: Jesse Brandeburg > Cc: Tony Nguyen > Cc: intel-wired-...@lists.osuosl.org > Cc: Guo Ren > Cc: Guo Ren > Cc: linux-c...@vger.kernel.org > --- > IMO "CONFIG_" namespace should belong to Kconfig files, not > individual drivers, but e1000 isn't the only driver that uses > CONFIG_ symbols. > > arch/csky/Kconfig|2 +- > arch/csky/include/asm/page.h |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > --- linux-next-20210129.orig/arch/csky/include/asm/page.h > +++ linux-next-20210129/arch/csky/include/asm/page.h > @@ -28,7 +28,7 @@ > #define SSEG_SIZE 0x2000 > #define LOWMEM_LIMIT (SSEG_SIZE * 2) > > -#define PHYS_OFFSET_OFFSET (CONFIG_RAM_BASE & (SSEG_SIZE - 1)) > +#define PHYS_OFFSET_OFFSET (CONFIG_DRAM_BASE & (SSEG_SIZE - 1)) > > #ifndef __ASSEMBLY__ > > --- linux-next-20210129.orig/arch/csky/Kconfig > +++ linux-next-20210129/arch/csky/Kconfig > @@ -314,7 +314,7 @@ config FORCE_MAX_ZONEORDER > int "Maximum zone order" > default "11" > > -config RAM_BASE > +config DRAM_BASE > hex "DRAM start addr (the same with memory-section in dts)" > default 0x0 > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [REGRESSION] x86/entry: TIF_SINGLESTEP handling is still broken
On Sat, Jan 30, 2021 at 5:32 PM Kyle Huey wrote: > > I tested that with 2991552447707d791d9d81a5dc161f9e9e90b163 reverted > and Yuxuan's patch applied to Linus's tip rr works and passes all > tests. There's a patch in the -tip tree that hasn't been merged yet: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/urgent (there's only that one patch in that branch right now, commit ID 41c1a06d1d1544bed9692ba72a5692454eee1945). It should be making its way my direction any day now, but in the meantime if you can verify that it makes things work for you, that would be great.. Linus
ERROR: ".snd_pcm_set_managed_buffer" undefined!
Hi Takashi, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0e9bcda5d286f4a26a5407bb38f55c55b453ecfb commit: 57e960f0020ec46db277426762ba5ffe77e03e3c ASoC: SOF: Use managed buffer allocation date: 1 year, 2 months ago config: powerpc-randconfig-c003-20210130 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57e960f0020ec46db277426762ba5ffe77e03e3c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 57e960f0020ec46db277426762ba5ffe77e03e3c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): ERROR: "._raw_spin_unlock" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".memset" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: "._dev_err" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".platform_get_irq" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".snd_interval_refine" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".snd_soc_add_dai_controls" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".syscon_regmap_lookup_by_phandle" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".snd_pcm_stream_lock" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".mutex_unlock" [sound/soc/sti/snd-soc-sti.ko] undefined! ERROR: ".sg_init_table" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".__warn_printk" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".devm_kmalloc" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".dma_set_coherent_mask" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".remap_pfn_range" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".devm_kfree" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".__platform_driver_register" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".snd_dma_alloc_pages" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".snd_soc_rtdcom_lookup" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".dma_request_slave_channel" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".snd_soc_set_runtime_hwparams" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".snd_dma_free_pages" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".dmam_alloc_attrs" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".dmam_free_coherent" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".snd_pcm_hw_constraint_integer" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".snd_pcm_hw_constraint_step" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".platform_driver_unregister" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".devm_snd_soc_register_component" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".__check_object_size" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: "._dev_warn" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".__wake_up" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".of_reserved_mem_device_init_by_idx" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: "._dev_err" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".dma_release_channel" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: "._copy_from_user" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".dma_set_mask" [sound/soc/sprd/snd-soc-sprd-platform.ko] undefined! ERROR: ".hex_dump_to_buffer" [sound/soc/sof/xtensa/snd-sof-xtensa-dsp.ko] undefined! ERROR: "._dev_err" [sound/soc/sof/xtensa/snd-sof-xtensa-dsp.ko] undefined! ERROR: ".devm_kmalloc" [sound/soc/sof/snd-sof-pci.ko] undefined! ERROR: ".pci_unregister_driver" [sound/soc/sof/snd-sof-pci.ko] undefined! ERROR: ".snd_intel_dsp_driver_probe" [sound/soc/sof/snd-sof-pci.ko] undefined! ERROR: ".__pci_register_driver" [sound/soc/sof/snd-sof-pci.ko] undefined! ER
[PATCH 02/18] arm64: dts: qcom: msm8994: Fix remaining BLSP errors/mistakes
From: Gustave Monce
* Move 35500 clock-frequency to kitakami (turns out it's a Sony specific)
* Add missing interfaces
* Fix the naming scheme
* Fix up pin assignments to make all BLSPs work
* Add DMA where previously omitted
Co-authored-by: Konrad Dybcio
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-cityman.dts | 2 +-
.../msm8994-sony-xperia-kitakami-karin.dts| 2 +-
.../qcom/msm8994-sony-xperia-kitakami.dtsi| 24 +--
arch/arm64/boot/dts/qcom/msm8994.dtsi | 163 ++
4 files changed, 149 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-cityman.dts
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-cityman.dts
index ed9034b96013..2d989a70e0b5 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-cityman.dts
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-cityman.dts
@@ -32,7 +32,7 @@ chosen {
};
};
-_i2c1 {
+_i2c1 {
status = "okay";
rmi4-i2c-dev@4b {
diff --git a/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-karin.dts
b/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-karin.dts
index 4dcf42eafb3a..a1d1a075941a 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-karin.dts
+++ b/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-karin.dts
@@ -12,7 +12,7 @@ / {
compatible = "sony,karin-row", "qcom,msm8994";
};
-_i2c5 {
+_i2c5 {
/*
* TI LP8557 backlight driver @ 2c
* AD AD7146 touch controller @ 2f
diff --git a/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami.dtsi
index 586d866188d7..48de66bf19c4 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami.dtsi
@@ -94,7 +94,7 @@ tzapp: memory@c780 {
};
};
-_spi0 {
+_spi1 {
status = "okay";
/* FPC fingerprint reader */
@@ -102,26 +102,23 @@ _spi0 {
/* I2C1 is disabled on this board */
-_i2c2 {
+_i2c2 {
status = "okay";
+ clock-frequency = <355000>;
/* NXP PN547 NFC */
};
-_i2c4 {
+_i2c4 {
status = "okay";
+ clock-frequency = <355000>;
/* Empty but active */
};
-_i2c5 {
- status = "okay";
-
- /* sii8620 HDMI/MHL bridge */
-};
-
-_i2c6 {
+_i2c6 {
status = "okay";
+ clock-frequency = <355000>;
touchscreen: rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
@@ -157,6 +154,13 @@ _uart2 {
status = "okay";
};
+_i2c5 {
+ status = "okay";
+ clock-frequency = <355000>;
+
+ /* sii8620 HDMI/MHL bridge */
+};
+
_uart2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index af1a9f7907b8..a6148b00e82c 100644
--- a/arch/arm64/boot/dts/qcom/msm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994.dtsi
@@ -507,7 +507,7 @@ blsp1_uart2: serial@f991e000 {
status = "disabled";
};
- blsp_i2c1: i2c@f9923000 {
+ blsp1_i2c1: i2c@f9923000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0xf9923000 0x500>;
interrupts = ;
@@ -515,6 +515,8 @@ blsp_i2c1: i2c@f9923000 {
<
GCC_BLSP1_QUP1_I2C_APPS_CLK>;
clock-names = "iface", "core";
clock-frequency = <40>;
+ dmas = <_dma 12>, <_dma 13>;
+ dma-names = "tx", "rx";
pinctrl-names = "default", "sleep";
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
@@ -523,7 +525,7 @@ blsp_i2c1: i2c@f9923000 {
status = "disabled";
};
- blsp_spi0: spi@f9923000 {
+ blsp1_spi1: spi@f9923000 {
compatible = "qcom,spi-qup-v2.2.1";
reg = <0xf9923000 0x500>;
interrupts = ;
@@ -534,21 +536,21 @@ blsp_spi0: spi@f9923000 {
dmas = <_dma 12>, <_dma 13>;
dma-names = "tx", "rx";
pinctrl-names = "default", "sleep";
- pinctrl-0 = <_spi0_default>;
- pinctrl-1 = <_spi0_sleep>;
+ pinctrl-0 = <_spi1_default>;
+ pinctrl-1 = <_spi1_sleep>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};
- blsp_i2c2: i2c@f9924000 {
+ blsp1_i2c2: i2c@f9924000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0xf9924000 0x500>;
interrupts = ;
[PATCH 09/18] arm64: dts: qcom: msm8994-octagon: Add QCA6174 bluetooth
From: Gustave Monce
Configure and enable QCA6174 Bluetooth and required pins.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index b8d89d64e2f1..78443f5a3881 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -45,6 +45,21 @@ chosen {
ranges;
};
+ clocks {
+ compatible = "simple-bus";
+
+ divclk4: divclk4 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+
+ clock-frequency = <32768>;
+ clock-output-names = "divclk4";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin_a>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
input-name = "gpio-keys";
@@ -291,6 +306,35 @@ _uart2 {
_uart2 {
status = "okay";
+
+ qca6174_bt: bluetooth {
+ compatible = "qcom,qca6174-bt";
+
+ enable-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
+ clocks = <>;
+ };
+};
+
+_gpios {
+ bt_en_gpios: bt_en_gpios {
+ pinconf {
+ pins = "gpio19";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ output-low;
+ power-source = ;
+ qcom,drive-strength = ;
+ bias-pull-down;
+ };
+ };
+
+ divclk4_pin_a: divclk4 {
+ pinconf {
+ pins = "gpio18";
+ function = PMIC_GPIO_FUNC_FUNC2;
+ power-source = ;
+ bias-disable;
+ };
+ };
};
_spmi_regulators {
--
2.30.0
[PATCH 10/18] arm64: dts: qcom: msm8994-octagon: Configure HD3SS460 Type-C mux pins
From: Gustave Monce
The driver is not available yet, so hardcode the pins.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 78443f5a3881..bf6e63a23600 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -337,6 +337,37 @@ pinconf {
};
};
+_gpios {
+ pinctrl-0 = <_pol _amsel _en>;
+ pinctrl-names = "default";
+
+ /*
+ * This device uses a TI HD3SS460 Type-C MUX
+ * As this device has no driver currently,
+ * the configuration for USB Face Up is set-up here.
+ *
+ * TODO: remove once a driver is available
+ * TODO: add VBUS GPIO 5
+ */
+ hd3ss460_pol: pol_low {
+ pins = "gpio8";
+ drive-strength = <3>;
+ bias-pull-down;
+ };
+
+ hd3ss460_amsel: amsel_high {
+ pins = "gpio9";
+ drive-strength = <1>;
+ bias-pull-up;
+ };
+
+ hd3ss460_en: en_high {
+ pins = "gpio10";
+ drive-strength = <1>;
+ bias-pull-up;
+ };
+};
+
_spmi_regulators {
vdd_gfx: s2@1700 {
reg = <0x1700 0x100>;
--
2.30.0
[PATCH 12/18] arm64: dts: qcom: msm8994-octagon: Configure Lattice iCE40 FPGA
From: Gustave Monce
Octagon devices have a Lattice iCE40 FPGA connected over SPI.
Configure it.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 21 +++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 004a42261cef..73af5265df9b 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -304,6 +304,27 @@ _uart2 {
status = "okay";
};
+_spi4 {
+ status = "okay";
+
+ /*
+* This device is a Lattice UC120 USB-C PD PHY.
+* It is actually a Lattice iCE40 FPGA pre-programmed by
+* the device firmware with a specific bitstream
+* enabling USB Type C PHY functionality.
+* Communication is done via a proprietary protocol over SPI.
+*
+* TODO: Once a proper driver is available, replace this.
+*/
+ uc120: ice5lp2k@0 {
+ compatible = "lattice,ice40-fpga-mgr";
+ reg = <0>;
+ spi-max-frequency = <500>;
+ cdone-gpios = < 95 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <_gpios 4 GPIO_ACTIVE_LOW>;
+ };
+};
+
_uart2 {
status = "okay";
--
2.30.0
[PATCH 13/18] arm64: dts: qcom: msm8994-octagon: Configure PON keys
From: Gustave Monce
Both the power key and the vol- key are connected over PON.
Configure them.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 16
arch/arm64/boot/dts/qcom/pm8994.dtsi | 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 73af5265df9b..097f8f6701e3 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -358,6 +358,22 @@ pinconf {
};
};
+_pon {
+ pwrkey {
+ compatible = "qcom,pm8941-pwrkey";
+ interrupts = <0 8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ linux,code = ;
+ };
+
+ volwnkey {
+ compatible = "qcom,pm8941-resin";
+ interrupts = <0 8 1 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ linux,code = ;
+ };
+};
+
_gpios {
pinctrl-0 = <_pol _amsel _en>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi
b/arch/arm64/boot/dts/qcom/pm8994.dtsi
index 5ffdf37d8e31..7f7ece49bdd3 100644
--- a/arch/arm64/boot/dts/qcom/pm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8994.dtsi
@@ -43,7 +43,7 @@ rtc@6000 {
interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
};
- pon@800 {
+ pm8994_pon: pon@800 {
compatible = "qcom,pm8916-pon";
reg = <0x800>;
--
2.30.0
[PATCH 11/18] arm64: dts: qcom: msm8994-octagon: Add uSD card and disable HS400 on eMMC
From: Gustave Monce
Lumia 950/XL, like other phones, ship with different storage chips.
Some of them are not capable of stable operation at HS400. Disable it.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 21 +++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index bf6e63a23600..004a42261cef 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -684,6 +684,27 @@ vph_pwr_bbyp: boost-bypass {
{
status = "okay";
+
+ /*
+* This device is shipped with HS400 capabable eMMCs
+* However various brands have been used in various product batches,
+* including a Samsung eMMC (BGND3R) which features a quirk with HS400.
+* Set the speed to HS200 as a safety measure.
+*/
+ mmc-hs200-1_8v;
+};
+
+ {
+ status = "okay";
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_clk_on _cmd_on _data_on>;
+ pinctrl-1 = <_clk_off _cmd_off _data_off>;
+
+ vmmc-supply = <_l21a_2p95>;
+ vqmmc-supply = <_l13a_2p95>;
+
+ cd-gpios = <_gpios 8 GPIO_ACTIVE_LOW>;
};
{
--
2.30.0
[PATCH 03/18] arm64: dts: qcom: msm8994: Sort hwlock properly
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index a6148b00e82c..60e04514af70 100644
--- a/arch/arm64/boot/dts/qcom/msm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994.dtsi
@@ -155,6 +155,12 @@ memory {
reg = <0 0 0 0>;
};
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <_mutex_regs 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+
pmu {
compatible = "arm,cortex-a53-pmu";
interrupts = ;
@@ -1003,12 +1009,6 @@ sdc2_data_off: sdc2-data-off {
};
};
- tcsr_mutex: hwlock {
- compatible = "qcom,tcsr-mutex";
- syscon = <_mutex_regs 0 0x80>;
- #hwlock-cells = <1>;
- };
-
timer {
compatible = "arm,armv8-timer";
interrupts = ,
--
2.30.0
[PATCH 15/18] arm64: dts: qcom: msm8994-octagon: Add NXP NFC node
From: Gustave Monce
Octagon devices use PN544 connected over I2C. Configure it.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 80e4ed48a1e3..e01c9dce187c 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -300,6 +300,22 @@ rmi4-f12@12 {
};
};
+_i2c6 {
+ status = "okay";
+
+ pn547: pn547@28 {
+ compatible = "nxp,pn544-i2c";
+
+ reg = <0x28>;
+
+ interrupt-parent = <>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+
+ enable-gpios = < 30 GPIO_ACTIVE_HIGH>;
+ firmware-gpios = < 94 GPIO_ACTIVE_HIGH>;
+ };
+};
+
_uart2 {
status = "okay";
};
--
2.30.0
[PATCH 14/18] arm64: dts: qcom: msm8994-octagon: Add FM Radio and DDR regulator nodes
FAN53526 and SI470X are both connected over blsp2_i2c5. Configure them.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 097f8f6701e3..80e4ed48a1e3 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -304,6 +304,32 @@ _uart2 {
status = "okay";
};
+_i2c5 {
+ status = "okay";
+
+ fm_radio: si4705@11 {
+ compatible = "silabs,si470x";
+ reg = <0x11>;
+
+ interrupt-parent = <>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = < 93 GPIO_ACTIVE_HIGH>;
+ };
+
+ vreg_lpddr_1p1: fan53526a@6c {
+ compatible = "fcs,fan53526";
+ reg = <0x6c>;
+
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ vin-supply = <_pwr>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on; /* Turning off DDR power doesn't sound
good. */
+ };
+
+ /* ANX7816 HDMI bridge (needs MDSS HDMI) */
+};
+
_spi4 {
status = "okay";
--
2.30.0
[PATCH 17/18] arm64: dts: qcom: msm8994-octagon: Add TAS2553 codec
From: Gustave Monce
Lumia 950/XL feature a TAS2553 codec. Configure it using the
TAS2552 driver.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 20 +++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 4aa33682f975..c0aa8cd80f7c 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -300,6 +300,26 @@ rmi4-f12@12 {
};
};
+_i2c2 {
+ status = "okay";
+
+ /*
+* This device uses the Texas Instruments TAS2553, however the TAS2552
driver
+* seems to work here. In the future a proper driver might need to
+* be written for this device.
+*/
+ tas2553: tas2553@40 {
+ compatible = "ti,tas2552";
+ reg = <0x40>;
+
+ vbat-supply = <_pwr>;
+ iovdd-supply = <_s4a_1p8>;
+ avdd-supply = <_s4a_1p8>;
+
+ enable-gpio = <_gpios 12 GPIO_ACTIVE_HIGH>;
+ };
+};
+
_i2c5 {
status = "okay";
--
2.30.0
[PATCH 04/18] arm64: dts: qcom: msm8992: Make the DT an overlay on top of 8994
This saves a good thousand lines of code, perhaps even
more in the long run.
Co-authored-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8992-bullhead-rev-101.dts | 2 +-
.../boot/dts/qcom/msm8992-xiaomi-libra.dts| 39 +-
arch/arm64/boot/dts/qcom/msm8992.dtsi | 772 +-
arch/arm64/boot/dts/qcom/msm8994.dtsi | 6 +-
4 files changed, 36 insertions(+), 783 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
index cacbfdbd69e3..23cdcc9f7c72 100644
--- a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
+++ b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
@@ -283,7 +283,7 @@ pmi8994_regulators: pmi8994-regulators {
};
};
-_1 {
+ {
status = "okay";
mmc-hs400-1_8v;
diff --git a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
index 5dab8ee0c7d3..357d55496e75 100644
--- a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
+++ b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts
@@ -70,21 +70,6 @@ ramoops@dfc0 {
pmsg-size = <0x2>;
};
- continuous_splash: framebuffer@3401000{
- reg = <0x0 0x3401000 0x0 0x220>;
- no-map;
- };
-
- dfps_data_mem: dfps_data_mem@340 {
- reg = <0x0 0x340 0x0 0x1000>;
- no-map;
- };
-
- peripheral_region: peripheral_region@740 {
- reg = <0x0 0x740 0x0 0x1c0>;
- no-map;
- };
-
modem_region: modem_region@900 {
reg = <0x0 0x900 0x0 0x5a0>;
no-map;
@@ -97,43 +82,49 @@ tzapp: modem_region@ea0 {
};
};
-_i2c2 {
+_i2c2 {
status = "okay";
/* Atmel or Synaptics touchscreen */
};
-_i2c5 {
+_i2c5 {
status = "okay";
- /* Silabs si4705 FM transmitter */
+ /* ST lsm6db0 gyro/accelerometer */
};
-_i2c6 {
+_i2c6 {
status = "okay";
- /* NCI NFC,
+ /*
+* NXP NCI NFC,
* TI USB320 Type-C controller,
* Pericom 30216a USB (de)mux switch
*/
};
-_i2c7 {
+_i2c1 {
status = "okay";
/* cm36686 proximity and ambient light sensor */
};
-_i2c13 {
+_i2c5 {
status = "okay";
- /* ST lsm6db0 gyro/accelerometer */
+ /* Silabs si4705 FM transmitter */
};
_uart2 {
status = "okay";
};
+_region {
+ reg = <0x0 0x740 0x0 0x1c0>;
+ no-map;
+};
+
_requests {
pm8994-regulators {
compatible = "qcom,rpm-pm8994-regulators";
@@ -364,7 +355,7 @@ pmi8994_bby: boost-bypass {
};
};
-_1 {
+ {
status = "okay";
mmc-hs400-1_8v;
diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi
b/arch/arm64/boot/dts/qcom/msm8992.dtsi
index b2046497dcaa..58fe58cc7703 100644
--- a/arch/arm64/boot/dts/qcom/msm8992.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8992.dtsi
@@ -2,767 +2,29 @@
/* Copyright (c) 2013-2016, The Linux Foundation. All rights reserved.
*/
-#include
-#include
-#include
+#include "msm8994.dtsi"
-/ {
- interrupt-parent = <>;
+/* 8992 only features 2 A57 cores. */
+/delete-node/
+/delete-node/
+/delete-node/ _map;
+/delete-node/ _map;
- #address-cells = <2>;
- #size-cells = <2>;
-
- chosen { };
-
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- CPU0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x0>;
- next-level-cache = <_0>;
- enable-method = "psci";
- L2_0: l2-cache {
- compatible = "cache";
- cache-level = <2>;
- };
- };
-
- CPU1: cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x1>;
- next-level-cache = <_0>;
- enable-method = "psci";
- };
-
- CPU2: cpu@2 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x2>;
- next-level-cache = <_0>;
- enable-method = "psci";
- };
-
- CPU3: cpu@3 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x0 0x3>;
- next-level-cache = <_0>;
- enable-method = "psci";
-
[PATCH 18/18] arm64: dts: qcom: msm8994-octagon: Add AD7147 and APDS9930 sensors
From: Gustave Monce
Add and configure AD7147 grip sensor and APDS9930 proximity sensor.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 50 +++
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index c0aa8cd80f7c..0b2a4afb34d6 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -376,6 +376,42 @@ _uart2 {
status = "okay";
};
+_i2c1 {
+ status = "okay";
+
+ sideinteraction: ad7147_captouch@2c {
+ compatible = "ad,ad7147_captouch";
+ reg = <0x2c>;
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_default>;
+ pinctrl-1 = <_sleep>;
+
+ interrupts = < 96 IRQ_TYPE_EDGE_FALLING>;
+
+ button_num = <8>;
+ touchpad_num = <0>;
+ wheel_num = <0>;
+ slider_num = <0>;
+
+ vcc-supply = <_l18a_2p85>;
+ };
+
+ /*
+* The QPDS-T900/QPDS-T930 is a customized part built for Nokia
+* by Avago. It is very similar to the Avago APDS-9930 with some
+* minor differences. In the future a proper driver might need to
+* be written for this device. For now this works fine.
+*/
+ qpdst900: qpdst900@39 {
+ compatible = "avago,apds9930";
+ reg = <0x39>;
+
+ interrupt-parent = <>;
+ interrupts = <40 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
_i2c5 {
status = "okay";
@@ -843,6 +879,20 @@ {
};
{
+ grip_default: grip-default {
+ pins = "gpio39";
+ function = "gpio";
+ drive-strength = <6>;
+ bias-pull-down;
+ };
+
+ grip_sleep: grip-sleep {
+ pins = "gpio39";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
hall_front_default: hall-front-default {
pins = "gpio42";
function = "gpio";
--
2.30.0
[PATCH 16/18] arm64: dts: qcom: msm8994-octagon: Add sensors on blsp1_i2c5
From: Gustave Monce
Add AK09912 magnetometer, ZPA2326 barometer and MPU6500 accelerometer
nodes.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index e01c9dce187c..4aa33682f975 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -300,6 +300,42 @@ rmi4-f12@12 {
};
};
+_i2c5 {
+ status = "okay";
+
+ ak09912: magnetometer@c {
+ compatible = "asahi-kasei,ak09912";
+ reg = <0xc>;
+
+ interrupt-parent = <>;
+ interrupts = <26 IRQ_TYPE_EDGE_RISING>;
+
+ vdd-supply = <_l18a_2p85>;
+ vid-supply = <_lvs2a_1p8>;
+ };
+
+ zpa2326: barometer@5c {
+ compatible = "murata,zpa2326";
+ reg = <0x5c>;
+
+ interrupt-parent = <>;
+ interrupts = <74 IRQ_TYPE_EDGE_RISING>;
+
+ vdd-supply = <_lvs2a_1p8>;
+ };
+
+ mpu6050: accelerometer@68 {
+ compatible = "invensense,mpu6500";
+ reg = <0x68>;
+
+ interrupt-parent = <>;
+ interrupts = <64 IRQ_TYPE_EDGE_RISING>;
+
+ vdd-supply = <_lvs2a_1p8>;
+ vddio-supply = <_lvs2a_1p8>;
+ };
+};
+
_i2c6 {
status = "okay";
--
2.30.0
[PATCH 06/18] arm64: dts: qcom: msm8994-octagon: Fix up the memory map
From: Gustave Monce
Windows-based devices have a far different memory map than
the standard LA one.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 166 ++
1 file changed, 166 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index b9e3e7821cbc..ff06b2161b10 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -10,6 +10,19 @@
#include "pm8994.dtsi"
#include "pmi8994.dtsi"
+/*
+ * Delete all generic (msm8994.dtsi) reserved
+ * memory mappings which are different in this device.
+ */
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _splash_mem;
+/delete-node/ _mem;
+/delete-node/ _mem;
+/delete-node/ _region;
+/delete-node/ _mem;
+/delete-node/ _mem;
+
/ {
/*
* Most Lumia 950/XL users use GRUB to load their kernels,
@@ -28,6 +41,159 @@ chosen {
#size-cells = <2>;
ranges;
};
+
+ reserved-memory {
+ /*
+* This device being a WP platform has a very different
+* memory layout than other Android based devices.
+* This memory layout is directly copied from the original
+* device UEFI firmware, and adapted based on observations
+* using JTAG for the Qualcomm Peripheral Image regions.
+*/
+
+ uefi_mem: memory@20 {
+ reg = <0 0x20 0 0x10>;
+ no-map;
+ };
+
+ mppark_mem: memory@30 {
+ reg = <0 0x30 0 0x8>;
+ no-map;
+ };
+
+ fbpt_mem: memory@38 {
+ reg = <0 0x38 0 0x1000>;
+ no-map;
+ };
+
+ dbg2_mem: memory@381000 {
+ reg = <0 0x381000 0 0x4000>;
+ no-map;
+ };
+
+ capsule_mem: memory@385000 {
+ reg = <0 0x385000 0 0x1000>;
+ no-map;
+ };
+
+ tpmctrl_mem: memory@386000 {
+ reg = <0 0x386000 0 0x3000>;
+ no-map;
+ };
+
+ uefiinfo_mem: memory@389000 {
+ reg = <0 0x389000 0 0x1000>;
+ no-map;
+ };
+
+ reset_mem: memory@389000 {
+ reg = <0 0x389000 0 0x1000>;
+ no-map;
+ };
+
+ resuncached_mem: memory@38e000 {
+ reg = <0 0x38e000 0 0x72000>;
+ no-map;
+ };
+
+ disp_mem: memory@40 {
+ reg = <0 0x40 0 0x80>;
+ no-map;
+ };
+
+ uefistack_mem: memory@c0 {
+ reg = <0 0xc0 0 0x4>;
+ no-map;
+ };
+
+ cpuvect_mem: memory@c4 {
+ reg = <0 0xc4 0 0x1>;
+ no-map;
+ };
+
+ rescached_mem: memory@40 {
+ reg = <0 0xc5 0 0xb>;
+ no-map;
+ };
+
+ tzapps_mem: memory@650 {
+ reg = <0 0x650 0 0x50>;
+ no-map;
+ };
+
+ smem_mem: memory@6a0 {
+ reg = <0 0x6a0 0 0x20>;
+ no-map;
+ };
+
+ hyp_mem: memory@6c0 {
+ reg = <0 0x6c0 0 0x10>;
+ no-map;
+ };
+
+ tz_mem: memory@6d0 {
+ reg = <0 0x6d0 0 0x16>;
+ no-map;
+ };
+
+ rfsa_adsp_mem: memory@6e6 {
+ reg = <0 0x6e6 0 0x1>;
+ no-map;
+ };
+
+ rfsa_mpss_mem: memory@6e7 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0 0x6e7 0 0x1>;
+ no-map;
+
+ qcom,client-id = <1>;
+ };
+
+ /*
+* Value obtained from the device original ACPI DSDT table
+* MPSS_EFS / SBL
+*/
+ mba_mem: memory@6e8 {
+ reg = <0 0x6e8 0 0x18>;
+ no-map;
+ };
+
+ /*
+* Peripheral Image loader region begin!
+* The region reserved for pil is 0x700-0xef0
+*/
[PATCH 07/18] arm64: dts: qcom: msm8994-octagon: Add gpio-keys and Hall sensor
From: Gustave Monce
This enables tje hardware keys as well as the Hall sensor.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 77 +++
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index ff06b2161b10..69016d769d90 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -9,6 +9,9 @@
#include "pm8994.dtsi"
#include "pmi8994.dtsi"
+#include
+#include
+#include
/*
* Delete all generic (msm8994.dtsi) reserved
@@ -42,6 +45,64 @@ chosen {
ranges;
};
+ gpio-keys {
+ compatible = "gpio-keys";
+ input-name = "gpio-keys";
+ autorepeat;
+
+ volupkey {
+ label = "Volume Up";
+ gpios = <_gpios 3 GPIO_ACTIVE_LOW>;
+ linux,input-type = <1>;
+ linux,code = ;
+ wakeup-source;
+ debounce-interval = <15>;
+ };
+
+ camsnapkey {
+ label = "Camera Snapshot";
+ gpios = <_gpios 4 GPIO_ACTIVE_LOW>;
+ linux,input-type = <1>;
+ linux,code = ;
+ wakeup-source;
+ debounce-interval = <15>;
+ };
+
+ camfocuskey {
+ label = "Camera Focus";
+ gpios = <_gpios 5 GPIO_ACTIVE_LOW>;
+ linux,input-type = <1>;
+ linux,code = ;
+ wakeup-source;
+ debounce-interval = <15>;
+ };
+ };
+
+ gpio-hall-sensor {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_front_default _back_default>;
+
+ label = "GPIO Hall Effect Sensor";
+
+ hall-front-sensor {
+ label = "Hall Effect Front Sensor";
+ gpios = < 42 GPIO_ACTIVE_HIGH>;
+ linux,input-type = ;
+ linux,code = ;
+ linux,can-disable;
+ };
+
+ hall-back-sensor {
+ label = "Hall Effect Back Sensor";
+ gpios = < 75 GPIO_ACTIVE_HIGH>;
+ linux,input-type = ;
+ linux,code = ;
+ linux,can-disable;
+ };
+ };
+
reserved-memory {
/*
* This device being a WP platform has a very different
@@ -235,3 +296,19 @@ _uart2 {
{
status = "okay";
};
+
+ {
+ hall_front_default: hall-front-default {
+ pins = "gpio42";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ hall_back_default: hall-back-default {
+ pins = "gpio75";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
--
2.30.0
[PATCH 01/18] arm64: dts: qcom: msm8994: Add SMP2P nodes
They will be required for bringup of remote processors.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index e694aaad3c99..af1a9f7907b8 100644
--- a/arch/arm64/boot/dts/qcom/msm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994.dtsi
@@ -276,6 +276,55 @@ smem {
hwlocks = <_mutex 3>;
};
+ smp2p-lpass {
+ compatible = "qcom,smp2p";
+ qcom,smem = <443>, <429>;
+
+ interrupts = ;
+
+ qcom,ipc = < 8 10>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <2>;
+
+ adsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ adsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ smp2p-modem {
+ compatible = "qcom,smp2p";
+ qcom,smem = <435>, <428>;
+
+ interrupt-parent = <>;
+ interrupts = ;
+
+ qcom,ipc = < 8 14>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <1>;
+
+ modem_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ modem_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
soc: soc {
#address-cells = <1>;
--
2.30.0
[PATCH 05/18] arm64: dts: qcom: msm8992/4-lumia*: Create a common DTS
From: Gustave Monce
Lumia 950 and 950XL are both based on the Octagon board, sharing
the vast majority of components, configuration etc. Commonize it.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/Makefile | 4 +-
.../msm8992-msft-lumia-octagon-talkman.dts| 15 +
.../dts/qcom/msm8992-msft-lumia-talkman.dts | 67 ---
.../msm8994-msft-lumia-octagon-cityman.dts| 15 +
...an.dts => msm8994-msft-lumia-octagon.dtsi} | 14 ++--
5 files changed, 38 insertions(+), 77 deletions(-)
create mode 100644
arch/arm64/boot/dts/qcom/msm8992-msft-lumia-octagon-talkman.dts
delete mode 100644 arch/arm64/boot/dts/qcom/msm8992-msft-lumia-talkman.dts
create mode 100644
arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dts
rename arch/arm64/boot/dts/qcom/{msm8994-msft-lumia-cityman.dts =>
msm8994-msft-lumia-octagon.dtsi} (83%)
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 6e784c7b0621..ff47d8c365ad 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -10,10 +10,10 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-samsung-a3u-eur.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-samsung-a5u-eur.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
-dtb-$(CONFIG_ARCH_QCOM)+= msm8992-msft-lumia-talkman.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8992-msft-lumia-octagon-talkman.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8992-xiaomi-libra.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
-dtb-$(CONFIG_ARCH_QCOM)+= msm8994-msft-lumia-cityman.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8994-msft-lumia-octagon-cityman.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8994-sony-xperia-kitakami-ivy.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8994-sony-xperia-kitakami-karin.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8994-sony-xperia-kitakami-satsuki.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-octagon-talkman.dts
b/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-octagon-talkman.dts
new file mode 100644
index ..ad8cf5bfa4e1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-octagon-talkman.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, Konrad Dybcio
+ * Copyright (c) 2020, Gustave Monce
+ */
+
+/dts-v1/;
+
+#include "msm8992.dtsi"
+#include "msm8994-msft-lumia-octagon.dtsi"
+
+/ {
+ model = "Microsoft Lumia 950";
+ compatible = "microsoft,talkman", "qcom,msm8992";
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-talkman.dts
b/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-talkman.dts
deleted file mode 100644
index c337a86a5c77..
--- a/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-talkman.dts
+++ /dev/null
@@ -1,67 +0,0 @@
-// SPDX-License-Identifier: BSD-3-Clause
-/*
- * Copyright (c) 2020, Konrad Dybcio
- */
-
-/dts-v1/;
-
-#include "msm8992.dtsi"
-#include "pm8994.dtsi"
-#include "pmi8994.dtsi"
-#include
-#include
-
-/ {
- model = "Microsoft Lumia 950";
- compatible = "microsoft,talkman", "qcom,msm8992";
-
- /* Most Lumia 950 users use GRUB to load their kernels,
-* hence there is no need for msm-id and friends.
-*/
-
- /* This enables graphical output via bootloader-enabled display.
-* acpi=no is required due to WP platforms having ACPI support, but
-* only for Windows-based OSes.
-*/
- chosen {
- bootargs = "earlycon=efifb console=efifb acpi=no";
-
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- };
-};
-
-_i2c1 {
- status = "okay";
-
- rmi4-i2c-dev@4b {
- compatible = "syna,rmi4-i2c";
- reg = <0x4b>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- interrupt-parent = <>;
- interrupts = <77 IRQ_TYPE_EDGE_FALLING>;
-
- rmi4-f01@1 {
- reg = <0x01>;
- syna,nosleep-mode = <1>;
- };
-
- rmi4-f12@12 {
- reg = <0x12>;
- syna,sensor-type = <1>;
- syna,clip-x-low = <0>;
- syna,clip-x-high = <1440>;
- syna,clip-y-low = <0>;
- syna,clip-y-high = <2560>;
- };
- };
-};
-
-_1 {
- status = "okay";
-
- mmc-hs200-1_8v;
-};
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dts
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dts
new file mode 100644
index ..33eb46f88ce8
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, Konrad Dybcio
+ *
[PATCH 08/18] arm64: dts: qcom: msm8994-octagon: Configure regulators
From: Gustave Monce
Configure the regulators to ensure proper voltages across
the board.
Signed-off-by: Gustave Monce
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 314 ++
1 file changed, 314 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
index 69016d769d90..b8d89d64e2f1 100644
--- a/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi
@@ -293,6 +293,320 @@ _uart2 {
status = "okay";
};
+_spmi_regulators {
+ vdd_gfx: s2@1700 {
+ reg = <0x1700 0x100>;
+ regulator-min-microvolt = <98>;
+ regulator-max-microvolt = <98>;
+ };
+};
+
+_requests {
+ /* These values were taken from the original firmware ACPI tables */
+ pm8994_regulators: pm8994-regulators {
+ compatible = "qcom,rpm-pm8994-regulators";
+
+ vdd_s1-supply = <_pwr>;
+ vdd_s2-supply = <_pwr>;
+ vdd_s3-supply = <_pwr>;
+ vdd_s4-supply = <_pwr>;
+ vdd_s5-supply = <_pwr>;
+ vdd_s6-supply = <_pwr>;
+ vdd_s7-supply = <_pwr>;
+ vdd_s8-supply = <_pwr>;
+ vdd_s9-supply = <_pwr>;
+ vdd_s10-supply = <_pwr>;
+ vdd_s11-supply = <_pwr>;
+ vdd_s12-supply = <_pwr>;
+ vdd_l1-supply = <_s1b_1p0>;
+ vdd_l2_l26_l28-supply = <_s3a_1p3>;
+ vdd_l3_l11-supply = <_s3a_1p3>;
+ vdd_l4_l27_l31-supply = <_s3a_1p3>;
+ vdd_l5_l7-supply = <_s5a_2p15>;
+ vdd_l6_l12_l32-supply = <_s5a_2p15>;
+ vdd_l8_l16_l30-supply = <_pwr>;
+ vdd_l9_l10_l18_l22-supply = <_pwr_bbyp>;
+ vdd_l13_l19_l23_l24-supply = <_pwr_bbyp>;
+ vdd_l14_l15-supply = <_s5a_2p15>;
+ vdd_l17_l29-supply = <_pwr_bbyp>;
+ vdd_l20_l21-supply = <_pwr_bbyp>;
+ vdd_l25-supply = <_s5a_2p15>;
+ vdd_lvs1_2-supply = <_s4a_1p8>;
+
+ /* S1, S2, S6 and S12 are managed by RPMPD */
+
+ vreg_s3a_1p3: s3 {
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <130>;
+ regulator-allow-set-load;
+ regulator-system-load = <30>;
+ };
+
+ vreg_s4a_1p8: s4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-allow-set-load;
+ regulator-always-on;
+ regulator-system-load = <325000>;
+ };
+
+ vreg_s5a_2p15: s5 {
+ regulator-min-microvolt = <215>;
+ regulator-max-microvolt = <215>;
+ regulator-allow-set-load;
+ regulator-system-load = <325000>;
+ };
+
+ vreg_s7a_1p0: s7 {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ };
+
+ /*
+* S8 - SPMI-managed VDD_APC0
+* S9, S10 and S11 (the main one) - SPMI-managed VDD_APC1
+*/
+
+ vreg_l1a_1p0: l1 {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ };
+
+ vreg_l2a_1p25: l2 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <125>;
+ regulator-allow-set-load;
+ regulator-system-load = <4160>;
+ };
+
+ vreg_l3a_1p2: l3 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ regulator-allow-set-load;
+ regulator-system-load = <8>;
+ };
+
+ vreg_l4a_1p225: l4 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+
+ /* L5 is inaccessible from RPM */
+
+ vreg_l6a_1p8: l6 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-allow-set-load;
+ regulator-system-load = <1000>;
+ };
+
+ /* L7 is inaccessible from RPM */
+
+ vreg_l8a_1p8: l8 {
+ regulator-min-microvolt = <180>;
+
[PATCH 00/18] 8992/4/Lumia 950/XL DTS updates
This series enabled already-supported hardware on Lumia 950/XL and adds SMP2P configuration on 8992/4, as well as cleaning up the DTs massively by transforming the 8992 dt into an overlay on top of 8994 (they are *almost* the same silicon). Gustave Monce (14): arm64: dts: qcom: msm8994: Fix remaining BLSP errors/mistakes arm64: dts: qcom: msm8992/4-lumia*: Create a common DTS arm64: dts: qcom: msm8994-octagon: Fix up the memory map arm64: dts: qcom: msm8994-octagon: Add gpio-keys and Hall sensor arm64: dts: qcom: msm8994-octagon: Configure regulators arm64: dts: qcom: msm8994-octagon: Add QCA6174 bluetooth arm64: dts: qcom: msm8994-octagon: Configure HD3SS460 Type-C mux pins arm64: dts: qcom: msm8994-octagon: Add uSD card and disable HS400 on eMMC arm64: dts: qcom: msm8994-octagon: Configure Lattice iCE40 FPGA arm64: dts: qcom: msm8994-octagon: Configure PON keys arm64: dts: qcom: msm8994-octagon: Add NXP NFC node arm64: dts: qcom: msm8994-octagon: Add sensors on blsp1_i2c5 arm64: dts: qcom: msm8994-octagon: Add TAS2553 codec arm64: dts: qcom: msm8994-octagon: Add AD7147 and APDS9930 sensors Konrad Dybcio (4): arm64: dts: qcom: msm8994: Add SMP2P nodes arm64: dts: qcom: msm8994: Sort hwlock properly arm64: dts: qcom: msm8992: Make the DT an overlay on top of 8994 arm64: dts: qcom: msm8994-octagon: Add FM Radio and DDR regulator nodes arch/arm64/boot/dts/qcom/Makefile | 4 +- .../dts/qcom/msm8992-bullhead-rev-101.dts | 2 +- .../msm8992-msft-lumia-octagon-talkman.dts| 15 + .../dts/qcom/msm8992-msft-lumia-talkman.dts | 67 -- .../boot/dts/qcom/msm8992-xiaomi-libra.dts| 39 +- arch/arm64/boot/dts/qcom/msm8992.dtsi | 772 +-- .../dts/qcom/msm8994-msft-lumia-cityman.dts | 73 -- .../msm8994-msft-lumia-octagon-cityman.dts| 15 + .../dts/qcom/msm8994-msft-lumia-octagon.dtsi | 909 ++ .../msm8994-sony-xperia-kitakami-karin.dts| 2 +- .../qcom/msm8994-sony-xperia-kitakami.dtsi| 24 +- arch/arm64/boot/dts/qcom/msm8994.dtsi | 230 - arch/arm64/boot/dts/qcom/pm8994.dtsi | 2 +- 13 files changed, 1181 insertions(+), 973 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/msm8992-msft-lumia-octagon-talkman.dts delete mode 100644 arch/arm64/boot/dts/qcom/msm8992-msft-lumia-talkman.dts delete mode 100644 arch/arm64/boot/dts/qcom/msm8994-msft-lumia-cityman.dts create mode 100644 arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dts create mode 100644 arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon.dtsi -- 2.30.0
[PATCH] soc: qcom: rpmpd: Add MDM9607 RPM Power Domains
This SoC while being from 8916 era, makes use of the
newer-style, floor-level management, instead of the older
floor-corner.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/soc/qcom/rpmpd.c | 22 +++
include/dt-bindings/power/qcom-rpmpd.h| 8 +++
3 files changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 64825128ee97..9422131b4236 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -16,6 +16,7 @@ description:
properties:
compatible:
enum:
+ - qcom,mdm9607-rpmpd
- qcom,msm8916-rpmpd
- qcom,msm8939-rpmpd
- qcom,msm8976-rpmpd
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 85d1207b72d7..ebf29a77c8b0 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -116,6 +116,27 @@ struct rpmpd_desc {
static DEFINE_MUTEX(rpmpd_lock);
+/* mdm9607 RPM Power Domains */
+DEFINE_RPMPD_PAIR(mdm9607, vddcx, vddcx_ao, SMPA, LEVEL, 3);
+DEFINE_RPMPD_VFL(mdm9607, vddcx_vfl, SMPA, 3);
+
+DEFINE_RPMPD_PAIR(mdm9607, vddmx, vddmx_ao, LDOA, LEVEL, 12);
+DEFINE_RPMPD_VFL(mdm9607, vddmx_vfl, LDOA, 12);
+static struct rpmpd *mdm9607_rpmpds[] = {
+ [MDM9607_VDDCX] = _vddcx,
+ [MDM9607_VDDCX_AO] =_vddcx_ao,
+ [MDM9607_VDDCX_VFL] = _vddcx_vfl,
+ [MDM9607_VDDMX] = _vddmx,
+ [MDM9607_VDDMX_AO] =_vddmx_ao,
+ [MDM9607_VDDMX_VFL] = _vddmx_vfl,
+};
+
+static const struct rpmpd_desc mdm9607_desc = {
+ .rpmpds = mdm9607_rpmpds,
+ .num_pds = ARRAY_SIZE(mdm9607_rpmpds),
+ .max_state = RPM_SMD_LEVEL_TURBO,
+};
+
/* msm8939 RPM Power Domains */
DEFINE_RPMPD_PAIR(msm8939, vddmd, vddmd_ao, SMPA, CORNER, 1);
DEFINE_RPMPD_VFC(msm8939, vddmd_vfc, SMPA, 1);
@@ -299,6 +320,7 @@ static const struct rpmpd_desc sdm660_desc = {
};
static const struct of_device_id rpmpd_match_table[] = {
+ { .compatible = "qcom,mdm9607-rpmpd", .data = _desc },
{ .compatible = "qcom,msm8916-rpmpd", .data = _desc },
{ .compatible = "qcom,msm8939-rpmpd", .data = _desc },
{ .compatible = "qcom,msm8976-rpmpd", .data = _desc },
diff --git a/include/dt-bindings/power/qcom-rpmpd.h
b/include/dt-bindings/power/qcom-rpmpd.h
index 7714487ac76b..9519eb38d695 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -69,6 +69,14 @@
#define RPMH_REGULATOR_LEVEL_TURBO 384
#define RPMH_REGULATOR_LEVEL_TURBO_L1 416
+/* MDM9607 Power Domains */
+#define MDM9607_VDDCX 0
+#define MDM9607_VDDCX_AO 1
+#define MDM9607_VDDCX_VFL 2
+#define MDM9607_VDDMX 3
+#define MDM9607_VDDMX_AO 4
+#define MDM9607_VDDMX_VFL 5
+
/* MSM8939 Power Domains */
#define MSM8939_VDDMDCX0
#define MSM8939_VDDMDCX_AO 1
--
2.30.0
[REGRESSION] x86/entry: TIF_SINGLESTEP handling is still broken
Yuxuan Shui previous reported a regression in single step reporting, introduced in 64eb35f701f04b30706e21d1b02636b5d31a37d2, with a patch to fix it. However, after that is fixed, there is another regression introduced later in the same series, in 2991552447707d791d9d81a5dc161f9e9e90b163, that again breaks the same code. The patch renames ARCH_SYSCALL_EXIT_WORK to ARCH_SYSCALL_WORK_EXIT, which orphans the definition of ARCH_SYSCALL_EXIT_WORK in arch/x86/include/asm/entry-common.h. No work was done to port TIF_SINGLESTEP to syscall_work. Despite the code in report_single_step that checks current_thread_info()->flags, because the code is no longer checking the TIF values at all to decide whether to enter syscall_exit_work, report_single_step will never be called and we will again fail to report the single step. I tested that with 2991552447707d791d9d81a5dc161f9e9e90b163 reverted and Yuxuan's patch applied to Linus's tip rr works and passes all tests. - Kyle
[PATCH] phy: qualcomm: usb28nm: Add MDM9607 init sequence
This is required to bring up the PHY on MDM9607-based boards.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/phy/qcom,usb-hs-28nm.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
b/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
index ca6a0836b53c..abcc4373f39e 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
@@ -16,6 +16,7 @@ properties:
compatible:
enum:
- qcom,usb-hs-28nm-femtophy
+ - qcom,usb-hs-28nm-mdm9607
reg:
maxItems: 1
diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
b/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
index a52a9bf13b75..8807e59a1162 100644
--- a/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
+++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-28nm.c
@@ -401,13 +401,26 @@ static const struct hsphy_init_seq init_seq_femtophy[] = {
HSPHY_INIT_CFG(0x90, 0x60, 0),
};
+static const struct hsphy_init_seq init_seq_mdm9607[] = {
+ HSPHY_INIT_CFG(0x80, 0x44, 0),
+ HSPHY_INIT_CFG(0x81, 0x38, 0),
+ HSPHY_INIT_CFG(0x82, 0x24, 0),
+ HSPHY_INIT_CFG(0x83, 0x13, 0),
+};
+
static const struct hsphy_data hsphy_data_femtophy = {
.init_seq = init_seq_femtophy,
.init_seq_num = ARRAY_SIZE(init_seq_femtophy),
};
+static const struct hsphy_data hsphy_data_mdm9607 = {
+ .init_seq = init_seq_mdm9607,
+ .init_seq_num = ARRAY_SIZE(init_seq_mdm9607),
+};
+
static const struct of_device_id qcom_snps_hsphy_match[] = {
{ .compatible = "qcom,usb-hs-28nm-femtophy", .data =
_data_femtophy, },
+ { .compatible = "qcom,usb-hs-28nm-mdm9607", .data =
_data_mdm9607, },
{ },
};
MODULE_DEVICE_TABLE(of, qcom_snps_hsphy_match);
--
2.30.0
[PATCH] clk: qcom: smd-rpm: Add mdm9607 clocks
Add support for RPM-managed clocks on the MDM9607 platform.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
drivers/clk/qcom/clk-smd-rpm.c| 32 +++
2 files changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
index b44a0622fb3a..5ac207d4b8ab 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
@@ -10,6 +10,7 @@ Required properties :
- compatible : shall contain only one of the following. The generic
compatible "qcom,rpmcc" should be also included.
+ "qcom,rpmcc-mdm9607", "qcom,rpmcc"
"qcom,rpmcc-msm8660", "qcom,rpmcc"
"qcom,rpmcc-apq8060", "qcom,rpmcc"
"qcom,rpmcc-msm8916", "qcom,rpmcc"
diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
index 0e1dfa89489e..ceea50bae8f8 100644
--- a/drivers/clk/qcom/clk-smd-rpm.c
+++ b/drivers/clk/qcom/clk-smd-rpm.c
@@ -406,6 +406,37 @@ static const struct clk_ops clk_smd_rpm_branch_ops = {
.unprepare = clk_smd_rpm_unprepare,
};
+/* mdm9607 */
+DEFINE_CLK_SMD_RPM_BRANCH(mdm9607, xo_clk_src, xo_a_clk_src,
QCOM_SMD_RPM_MISC_CLK, 0,
+ 1920);
+DEFINE_CLK_SMD_RPM(mdm9607, pcnoc_clk, pcnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);
+DEFINE_CLK_SMD_RPM(mdm9607, bimc_clk, bimc_a_clk, QCOM_SMD_RPM_MEM_CLK, 0);
+DEFINE_CLK_SMD_RPM(mdm9607, qpic_clk, qpic_a_clk, QCOM_SMD_RPM_QPIC_CLK, 0);
+DEFINE_CLK_SMD_RPM_QDSS(mdm9607, qdss_clk, qdss_a_clk, QCOM_SMD_RPM_MISC_CLK,
1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(mdm9607, bb_clk1, bb_clk1_a, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(mdm9607, bb_clk1_pin, bb_clk1_a_pin, 1);
+static struct clk_smd_rpm *mdm9607_clks[] = {
+ [RPM_SMD_XO_CLK_SRC]= _xo_clk_src,
+ [RPM_SMD_XO_A_CLK_SRC] = _xo_a_clk_src,
+ [RPM_SMD_PCNOC_CLK] = _pcnoc_clk,
+ [RPM_SMD_PCNOC_A_CLK] = _pcnoc_a_clk,
+ [RPM_SMD_BIMC_CLK] = _bimc_clk,
+ [RPM_SMD_BIMC_A_CLK]= _bimc_a_clk,
+ [RPM_SMD_QPIC_CLK] = _qpic_clk,
+ [RPM_SMD_QPIC_CLK_A]= _qpic_a_clk,
+ [RPM_SMD_QDSS_CLK] = _qdss_clk,
+ [RPM_SMD_QDSS_A_CLK]= _qdss_a_clk,
+ [RPM_SMD_BB_CLK1] = _bb_clk1,
+ [RPM_SMD_BB_CLK1_A] = _bb_clk1_a,
+ [RPM_SMD_BB_CLK1_PIN] = _bb_clk1_pin,
+ [RPM_SMD_BB_CLK1_A_PIN] = _bb_clk1_a_pin,
+};
+
+static const struct rpm_smd_clk_desc rpm_clk_mdm9607 = {
+ .clks = mdm9607_clks,
+ .num_clks = ARRAY_SIZE(mdm9607_clks),
+};
+
/* msm8916 */
DEFINE_CLK_SMD_RPM(msm8916, pcnoc_clk, pcnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);
DEFINE_CLK_SMD_RPM(msm8916, snoc_clk, snoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 1);
@@ -1060,6 +1091,7 @@ static const struct rpm_smd_clk_desc rpm_clk_sdm660 = {
};
static const struct of_device_id rpm_smd_clk_match_table[] = {
+ { .compatible = "qcom,rpmcc-mdm9607", .data = _clk_mdm9607 },
{ .compatible = "qcom,rpmcc-msm8916", .data = _clk_msm8916 },
{ .compatible = "qcom,rpmcc-msm8936", .data = _clk_msm8936 },
{ .compatible = "qcom,rpmcc-msm8974", .data = _clk_msm8974 },
--
2.30.0
[PATCH] firmware: qcom_scm: Add MDM9607 compatible
Add a compatible for MDM9607. It uses the "legacy" calling
convention.
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 +
drivers/firmware/qcom_scm.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 78456437df5f..df8379356021 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -12,6 +12,7 @@ Required properties:
* "qcom,scm-ipq4019"
* "qcom,scm-ipq806x"
* "qcom,scm-ipq8074"
+ * "qcom,scm-mdm9607"
* "qcom,scm-msm8660"
* "qcom,scm-msm8916"
* "qcom,scm-msm8960"
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 7be48c1bec96..b5b9b13d8d29 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -1265,6 +1265,9 @@ static const struct of_device_id qcom_scm_dt_match[] = {
SCM_HAS_BUS_CLK)
},
{ .compatible = "qcom,scm-ipq4019" },
+ { .compatible = "qcom,scm-mdm9607", .data = (void *)(SCM_HAS_CORE_CLK |
+SCM_HAS_IFACE_CLK |
+SCM_HAS_BUS_CLK) },
{ .compatible = "qcom,scm-msm8660", .data = (void *) SCM_HAS_CORE_CLK },
{ .compatible = "qcom,scm-msm8960", .data = (void *) SCM_HAS_CORE_CLK },
{ .compatible = "qcom,scm-msm8916", .data = (void *)(SCM_HAS_CORE_CLK |
--
2.30.0
Re: [RFC 01/20] mm/tlb: fix fullmm semantics
> On Jan 30, 2021, at 5:02 PM, Andy Lutomirski wrote: > > On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: >> From: Nadav Amit >> >> fullmm in mmu_gather is supposed to indicate that the mm is torn-down >> (e.g., on process exit) and can therefore allow certain optimizations. >> However, tlb_finish_mmu() sets fullmm, when in fact it want to say that >> the TLB should be fully flushed. > > Maybe also rename fullmm? Possible. How about mm_torn_down? I should have also changed the comment in tlb_finish_mmu().
Re: [RFC][PATCH 04/13] mm/numa: node demotion data structure and lookup
On Mon, 25 Jan 2021, Dave Hansen wrote:
> diff -puN mm/migrate.c~0006-node-Define-and-export-memory-migration-path
> mm/migrate.c
> --- a/mm/migrate.c~0006-node-Define-and-export-memory-migration-path
> 2021-01-25 16:23:09.553866709 -0800
> +++ b/mm/migrate.c2021-01-25 16:23:09.558866709 -0800
> @@ -1161,6 +1161,22 @@ out:
> return rc;
> }
>
> +static int node_demotion[MAX_NUMNODES] = {[0 ... MAX_NUMNODES - 1] =
> NUMA_NO_NODE};
__read_mostly?
> +
> +/**
> + * next_demotion_node() - Get the next node in the demotion path
> + * @node: The starting node to lookup the next node
> + *
> + * @returns: node id for next memory node in the demotion path hierarchy
> + * from @node; NUMA_NO_NODE if @node is terminal. This does not keep
> + * @node online or guarantee that it *continues* to be the next demotion
> + * target.
> + */
> +int next_demotion_node(int node)
> +{
> + return node_demotion[node];
> +}
> +
> /*
> * Obtain the lock on page, remove all ptes and migrate the page
> * to the newly allocated page in newpage.
> _
>
Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion
> On Jan 30, 2021, at 5:07 PM, Andy Lutomirski wrote:
>
> Adding Andrew Cooper, who has a distressingly extensive understanding
> of the x86 PTE magic.
>
> On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>> From: Nadav Amit
>>
>> Currently, using mprotect() to unprotect a memory region or uffd to
>> unprotect a memory region causes a TLB flush. At least on x86, as
>> protection is promoted, no TLB flush is needed.
>>
>> Add an arch-specific pte_may_need_flush() which tells whether a TLB
>> flush is needed based on the old PTE and the new one. Implement an x86
>> pte_may_need_flush().
>>
>> For x86, besides the simple logic that PTE protection promotion or
>> changes of software bits does require a flush, also add logic that
>> considers the dirty-bit. If the dirty-bit is clear and write-protect is
>> set, no TLB flush is needed, as x86 updates the dirty-bit atomically
>> on write, and if the bit is clear, the PTE is reread.
>>
>> Signed-off-by: Nadav Amit
>> Cc: Andrea Arcangeli
>> Cc: Andrew Morton
>> Cc: Andy Lutomirski
>> Cc: Dave Hansen
>> Cc: Peter Zijlstra
>> Cc: Thomas Gleixner
>> Cc: Will Deacon
>> Cc: Yu Zhao
>> Cc: Nick Piggin
>> Cc: x...@kernel.org
>> ---
>> arch/x86/include/asm/tlbflush.h | 44 +
>> include/asm-generic/tlb.h | 4 +++
>> mm/mprotect.c | 3 ++-
>> 3 files changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/tlbflush.h
>> b/arch/x86/include/asm/tlbflush.h
>> index 8c87a2e0b660..a617dc0a9b06 100644
>> --- a/arch/x86/include/asm/tlbflush.h
>> +++ b/arch/x86/include/asm/tlbflush.h
>> @@ -255,6 +255,50 @@ static inline void arch_tlbbatch_add_mm(struct
>> arch_tlbflush_unmap_batch *batch,
>>
>> extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
>>
>> +static inline bool pte_may_need_flush(pte_t oldpte, pte_t newpte)
>> +{
>> + const pteval_t ignore_mask = _PAGE_SOFTW1 | _PAGE_SOFTW2 |
>> +_PAGE_SOFTW3 | _PAGE_ACCESSED;
>
> Why is accessed ignored? Surely clearing the accessed bit needs a
> flush if the old PTE is present.
I am just following the current scheme in the kernel (x86):
int ptep_clear_flush_young(struct vm_area_struct *vma,
unsigned long address, pte_t *ptep)
{
/*
* On x86 CPUs, clearing the accessed bit without a TLB flush
* doesn't cause data corruption. [ It could cause incorrect
* page aging and the (mistaken) reclaim of hot pages, but the
* chance of that should be relatively low. ]
*
* So as a performance optimization don't flush the TLB when
* clearing the accessed bit, it will eventually be flushed by
* a context switch or a VM operation anyway. [ In the rare
* event of it not getting flushed for a long time the delay
* shouldn't really matter because there's no real memory
* pressure for swapout to react to. ]
*/
return ptep_test_and_clear_young(vma, address, ptep);
}
>
>> + const pteval_t enable_mask = _PAGE_RW | _PAGE_DIRTY | _PAGE_GLOBAL;
>> + pteval_t oldval = pte_val(oldpte);
>> + pteval_t newval = pte_val(newpte);
>> + pteval_t diff = oldval ^ newval;
>> + pteval_t disable_mask = 0;
>> +
>> + if (IS_ENABLED(CONFIG_X86_64) || IS_ENABLED(CONFIG_X86_PAE))
>> + disable_mask = _PAGE_NX;
>> +
>> + /* new is non-present: need only if old is present */
>> + if (pte_none(newpte))
>> + return !pte_none(oldpte);
>> +
>> + /*
>> +* If, excluding the ignored bits, only RW and dirty are cleared and
>> the
>> +* old PTE does not have the dirty-bit set, we can avoid a flush.
>> This
>> +* is possible since x86 architecture set the dirty bit atomically
>> while
>
> s/set/sets/
>
>> +* it caches the PTE in the TLB.
>> +*
>> +* The condition considers any change to RW and dirty as not
>> requiring
>> +* flush if the old PTE is not dirty or not writable for
>> simplification
>> +* of the code and to consider (unlikely) cases of changing
>> dirty-bit of
>> +* write-protected PTE.
>> +*/
>> + if (!(diff & ~(_PAGE_RW | _PAGE_DIRTY | ignore_mask)) &&
>> + (!(pte_dirty(oldpte) || !pte_write(oldpte
>> + return false;
>
> This logic seems confusing to me. Is your goal to say that, if the
> old PTE was clean and writable and the new PTE is write-protected,
> then no flush is needed?
Yes.
> If so, I would believe you're right, but I'm
> not convinced you've actually implemented this. Also, there may be
> other things going on that need flushing, e.g. a change of the address
> or an accessed bit or NX change.
The first part (diff & ~(_PAGE_RW | _PAGE_DIRTY | ignore_mask) is supposed
to capture changes of address, NX-bit, etc.
The second part is indeed
Re: [PATCH net] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
On Sun, Jan 31, 2021 at 8:39 AM Vladimir Oltean wrote: > > Tobias has a point in a way too, you should get used to adding the > 'master static' flags to your bridge fdb commands, otherwise weird > things like this could happen. The faulty code can only be triggered > when going through dsa_legacy_fdb_add, but it is still faulty > nonetheless. This bug is exposed when I try your patch series on kernel 5.4 https://lore.kernel.org/netdev/20210106095136.224739-1-olte...@gmail.com/ https://lore.kernel.org/netdev/20210116012515.3152-1-tob...@waldekranz.com/ Without this patch, DSA will add a new port bit to the existing portvec when a client moves to the software part of a bridge. When it moves away, DSA will clear the port bit but the existing one will remain static. This results in connection issues when the client moves to a different port of the switch, and the kernel log below. mv88e6085 f1072004.mdio-mii:00: ATU member violation for xx:xx:xx:xx:xx:xx portvec dc00 spid 0
Re: [RFC][PATCH 00/13] [v5] Migrate Pages in lieu of discard
On Mon, 25 Jan 2021, Dave Hansen wrote: > This also contains a few prerequisite patches that fix up an issue > with the vm.zone_reclaim_mode sysctl ABI. > I think these patches (patches 1-3) can be staged in -mm now since they fix vm.zone_reclaim_mode correctness and consistency. Andrew, would it be possible to take patches 1-3 now since they are fix an existing issue?
Re: [RFC][PATCH 03/13] mm/vmscan: replace implicit RECLAIM_ZONE checks with explicit checks
On Mon, 25 Jan 2021, Dave Hansen wrote: > > From: Dave Hansen > > RECLAIM_ZONE was assumed to be unused because it was never explicitly > used in the kernel. However, there were a number of places where it > was checked implicitly by checking 'node_reclaim_mode' for a zero > value. > > These zero checks are not great because it is not obvious what a zero > mode *means* in the code. Replace them with a helper which makes it > more obvious: node_reclaim_enabled(). > > This helper also provides a handy place to explicitly check the > RECLAIM_ZONE bit itself. Check it explicitly there to make it more > obvious where the bit can affect behavior. > > This should have no functional impact. > > Signed-off-by: Dave Hansen > Reviewed-by: Ben Widawsky > Acked-by: Christoph Lameter > Cc: Alex Shi > Cc: "Tobin C. Harding" > Cc: Christoph Lameter > Cc: Andrew Morton > Cc: Huang Ying > Cc: Dan Williams > Cc: Qian Cai > Cc: Daniel Wagner > Cc: osalvador Acked-by: David Rientjes
Re: [RFC 00/20] TLB batching consolidation and enhancements
> On Jan 30, 2021, at 4:39 PM, Andy Lutomirski wrote:
>
> On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>> From: Nadav Amit
>>
>> There are currently (at least?) 5 different TLB batching schemes in the
>> kernel:
>>
>> 1. Using mmu_gather (e.g., zap_page_range()).
>>
>> 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the
>> ongoing deferred TLB flush and flushing the entire range eventually
>> (e.g., change_protection_range()).
>>
>> 3. arch_{enter|leave}_lazy_mmu_mode() for sparc and powerpc (and Xen?).
>>
>> 4. Batching per-table flushes (move_ptes()).
>>
>> 5. By setting a flag on that a deferred TLB flush operation takes place,
>> flushing when (try_to_unmap_one() on x86).
>
> Are you referring to the arch_tlbbatch_add_mm/flush mechanism?
Yes.
Re: [RFC 03/20] mm/mprotect: do not flush on permission promotion
Adding Andrew Cooper, who has a distressingly extensive understanding
of the x86 PTE magic.
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>
> From: Nadav Amit
>
> Currently, using mprotect() to unprotect a memory region or uffd to
> unprotect a memory region causes a TLB flush. At least on x86, as
> protection is promoted, no TLB flush is needed.
>
> Add an arch-specific pte_may_need_flush() which tells whether a TLB
> flush is needed based on the old PTE and the new one. Implement an x86
> pte_may_need_flush().
>
> For x86, besides the simple logic that PTE protection promotion or
> changes of software bits does require a flush, also add logic that
> considers the dirty-bit. If the dirty-bit is clear and write-protect is
> set, no TLB flush is needed, as x86 updates the dirty-bit atomically
> on write, and if the bit is clear, the PTE is reread.
>
> Signed-off-by: Nadav Amit
> Cc: Andrea Arcangeli
> Cc: Andrew Morton
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Yu Zhao
> Cc: Nick Piggin
> Cc: x...@kernel.org
> ---
> arch/x86/include/asm/tlbflush.h | 44 +
> include/asm-generic/tlb.h | 4 +++
> mm/mprotect.c | 3 ++-
> 3 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index 8c87a2e0b660..a617dc0a9b06 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -255,6 +255,50 @@ static inline void arch_tlbbatch_add_mm(struct
> arch_tlbflush_unmap_batch *batch,
>
> extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
>
> +static inline bool pte_may_need_flush(pte_t oldpte, pte_t newpte)
> +{
> + const pteval_t ignore_mask = _PAGE_SOFTW1 | _PAGE_SOFTW2 |
> +_PAGE_SOFTW3 | _PAGE_ACCESSED;
Why is accessed ignored? Surely clearing the accessed bit needs a
flush if the old PTE is present.
> + const pteval_t enable_mask = _PAGE_RW | _PAGE_DIRTY | _PAGE_GLOBAL;
> + pteval_t oldval = pte_val(oldpte);
> + pteval_t newval = pte_val(newpte);
> + pteval_t diff = oldval ^ newval;
> + pteval_t disable_mask = 0;
> +
> + if (IS_ENABLED(CONFIG_X86_64) || IS_ENABLED(CONFIG_X86_PAE))
> + disable_mask = _PAGE_NX;
> +
> + /* new is non-present: need only if old is present */
> + if (pte_none(newpte))
> + return !pte_none(oldpte);
> +
> + /*
> +* If, excluding the ignored bits, only RW and dirty are cleared and
> the
> +* old PTE does not have the dirty-bit set, we can avoid a flush. This
> +* is possible since x86 architecture set the dirty bit atomically
> while
s/set/sets/
> +* it caches the PTE in the TLB.
> +*
> +* The condition considers any change to RW and dirty as not requiring
> +* flush if the old PTE is not dirty or not writable for
> simplification
> +* of the code and to consider (unlikely) cases of changing dirty-bit
> of
> +* write-protected PTE.
> +*/
> + if (!(diff & ~(_PAGE_RW | _PAGE_DIRTY | ignore_mask)) &&
> + (!(pte_dirty(oldpte) || !pte_write(oldpte
> + return false;
This logic seems confusing to me. Is your goal to say that, if the
old PTE was clean and writable and the new PTE is write-protected,
then no flush is needed? If so, I would believe you're right, but I'm
not convinced you've actually implemented this. Also, there may be
other things going on that need flushing, e.g. a change of the address
or an accessed bit or NX change.
Also, CET makes this extra bizarre.
> +
> + /*
> +* Any change of PFN and any flag other than those that we consider
> +* requires a flush (e.g., PAT, protection keys). To save flushes we
> do
> +* not consider the access bit as it is considered by the kernel as
> +* best-effort.
> +*/
> + return diff & ((oldval & enable_mask) |
> + (newval & disable_mask) |
> + ~(enable_mask | disable_mask | ignore_mask));
> +}
> +#define pte_may_need_flush pte_may_need_flush
> +
> #endif /* !MODULE */
>
> #endif /* _ASM_X86_TLBFLUSH_H */
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index eea113323468..c2deec0b6919 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -654,6 +654,10 @@ static inline void tlb_flush_p4d_range(struct mmu_gather
> *tlb,
> } while (0)
> #endif
>
> +#ifndef pte_may_need_flush
> +static inline bool pte_may_need_flush(pte_t oldpte, pte_t newpte) { return
> true; }
> +#endif
> +
> #endif /* CONFIG_MMU */
>
> #endif /* _ASM_GENERIC__TLB_H */
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 632d5a677d3f..b7473d2c9a1f 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -139,7 +139,8
Re: [PATCH] drm/ttm: Use __GFP_NOWARN for huge pages in ttm_pool_alloc_page
On Thu, 28 Jan 2021, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Without __GFP_NOWARN, attempts at allocating huge pages can trigger
> dmesg splats like below (which are essentially noise, since TTM falls
> back to normal pages if it can't get a huge one).
>
> [ 9556.710241] clinfo: page allocation failure: order:9,
> mode:0x194dc2(GFP_HIGHUSER|__GFP_RETRY_MAYFAIL|__GFP_NORETRY|__GFP_ZERO|__GFP_NOMEMALLOC),
> nodemask=(null),cpuset=user.slice,mems_allowed=0
> [ 9556.710259] CPU: 1 PID: 470821 Comm: clinfo Tainted: GE
> 5.10.10+ #4
> [ 9556.710264] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350
> TOMAHAWK (MS-7A34), BIOS 1.OR 11/29/2019
> [ 9556.710268] Call Trace:
> [ 9556.710281] dump_stack+0x6b/0x83
> [ 9556.710288] warn_alloc.cold+0x7b/0xdf
> [ 9556.710297] ? __alloc_pages_direct_compact+0x137/0x150
> [ 9556.710303] __alloc_pages_slowpath.constprop.0+0xc1b/0xc50
> [ 9556.710312] __alloc_pages_nodemask+0x2ec/0x320
> [ 9556.710325] ttm_pool_alloc+0x2e4/0x5e0 [ttm]
> [ 9556.710332] ? kvmalloc_node+0x46/0x80
> [ 9556.710341] ttm_tt_populate+0x37/0xe0 [ttm]
> [ 9556.710350] ttm_bo_handle_move_mem+0x142/0x180 [ttm]
> [ 9556.710359] ttm_bo_validate+0x11d/0x190 [ttm]
> [ 9556.710391] ? drm_vma_offset_add+0x2f/0x60 [drm]
> [ 9556.710399] ttm_bo_init_reserved+0x2a7/0x320 [ttm]
> [ 9556.710529] amdgpu_bo_do_create+0x1b8/0x500 [amdgpu]
> [ 9556.710657] ? amdgpu_bo_subtract_pin_size+0x60/0x60 [amdgpu]
> [ 9556.710663] ? get_page_from_freelist+0x11f9/0x1450
> [ 9556.710789] amdgpu_bo_create+0x40/0x270 [amdgpu]
> [ 9556.710797] ? _raw_spin_unlock+0x16/0x30
> [ 9556.710927] amdgpu_gem_create_ioctl+0x123/0x310 [amdgpu]
> [ 9556.711062] ? amdgpu_gem_force_release+0x150/0x150 [amdgpu]
> [ 9556.711098] drm_ioctl_kernel+0xaa/0xf0 [drm]
> [ 9556.711133] drm_ioctl+0x20f/0x3a0 [drm]
> [ 9556.711267] ? amdgpu_gem_force_release+0x150/0x150 [amdgpu]
> [ 9556.711276] ? preempt_count_sub+0x9b/0xd0
> [ 9556.711404] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> [ 9556.711411] __x64_sys_ioctl+0x83/0xb0
> [ 9556.711417] do_syscall_64+0x33/0x80
> [ 9556.711421] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: bf9eee249ac2 ("drm/ttm: stop using GFP_TRANSHUGE_LIGHT")
> Signed-off-by: Michel Dänzer
Acked-by: David Rientjes
Mikhail Gavrilov reported the same issue.
Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]
On Sat, 30 Jan 2021, David Rientjes wrote: > On Sun, 31 Jan 2021, Mikhail Gavrilov wrote: > > > The 5.11-rc5 (git 76c057c84d28) brought a new issue. > > Now the kernel log is flooded with the message "page allocation failure". > > > > Trace: > > msedge:cs0: page allocation failure: order:10, > > Order-10, wow! > > ttm_pool_alloc() will start at order-10 and back off trying smaller orders > if necessary. This is a regression introduced in > > commit bf9eee249ac2032521677dd74e31ede5429afbc0 > Author: Christian König > Date: Wed Jan 13 14:02:04 2021 +0100 > > drm/ttm: stop using GFP_TRANSHUGE_LIGHT > > Namely, it removed the __GFP_NOWARN that we otherwise require. I'll send > a patch in reply. > Looks like Michel Dänzer already sent a patch that should fix this: https://lore.kernel.org/lkml/20210128095346.2421-1-mic...@daenzer.net/
Re: [RFC 01/20] mm/tlb: fix fullmm semantics
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: > > From: Nadav Amit > > fullmm in mmu_gather is supposed to indicate that the mm is torn-down > (e.g., on process exit) and can therefore allow certain optimizations. > However, tlb_finish_mmu() sets fullmm, when in fact it want to say that > the TLB should be fully flushed. Maybe also rename fullmm?
Re: [bug] 5.11-rc5 brought page allocation failure issue [ttm][amdgpu]
On Sun, 31 Jan 2021, Mikhail Gavrilov wrote: > The 5.11-rc5 (git 76c057c84d28) brought a new issue. > Now the kernel log is flooded with the message "page allocation failure". > > Trace: > msedge:cs0: page allocation failure: order:10, Order-10, wow! ttm_pool_alloc() will start at order-10 and back off trying smaller orders if necessary. This is a regression introduced in commit bf9eee249ac2032521677dd74e31ede5429afbc0 Author: Christian König Date: Wed Jan 13 14:02:04 2021 +0100 drm/ttm: stop using GFP_TRANSHUGE_LIGHT Namely, it removed the __GFP_NOWARN that we otherwise require. I'll send a patch in reply. > mode:0x190cc2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_NOMEMALLOC), > nodemask=(null),cpuset=/,mems_allowed=0 > CPU: 18 PID: 4540 Comm: msedge:cs0 Tainted: GW > - --- 5.11.0-0.rc5.20210128git76c057c84d28.138.fc34.x86_64 #1 > Hardware name: System manufacturer System Product Name/ROG STRIX > X570-I GAMING, BIOS 3402 01/13/2021 > Call Trace: > dump_stack+0x8b/0xb0 > warn_alloc.cold+0x72/0xd6 > ? _cond_resched+0x16/0x50 > ? __alloc_pages_direct_compact+0x1a1/0x210 > __alloc_pages_slowpath.constprop.0+0xf64/0xf90 > ? kmem_cache_alloc+0x299/0x310 > ? lock_acquire+0x173/0x380 > ? trace_hardirqs_on+0x1b/0xe0 > ? lock_release+0x1e9/0x400 > __alloc_pages_nodemask+0x37d/0x400 > ttm_pool_alloc+0x2a3/0x630 [ttm] > ttm_tt_populate+0x37/0xe0 [ttm] > ttm_bo_handle_move_mem+0x142/0x180 [ttm] > ttm_bo_evict+0x12e/0x1b0 [ttm] > ? kfree+0xeb/0x660 > ? amdgpu_vram_mgr_new+0x34d/0x3d0 [amdgpu] > ttm_mem_evict_first+0x101/0x4d0 [ttm] > ttm_bo_mem_space+0x2c8/0x330 [ttm] > ttm_bo_validate+0x163/0x1c0 [ttm] > amdgpu_cs_bo_validate+0x82/0x190 [amdgpu] > amdgpu_cs_list_validate+0x105/0x150 [amdgpu] > amdgpu_cs_ioctl+0x803/0x1ef0 [amdgpu] > ? trace_hardirqs_off_caller+0x41/0xd0 > ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu] > drm_ioctl_kernel+0x8c/0xe0 [drm] > drm_ioctl+0x20f/0x3c0 [drm] > ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu] > ? selinux_file_ioctl+0x147/0x200 > ? lock_acquired+0x1fa/0x380 > ? lock_release+0x1e9/0x400 > ? trace_hardirqs_on+0x1b/0xe0 > amdgpu_drm_ioctl+0x49/0x80 [amdgpu] > __x64_sys_ioctl+0x82/0xb0 > do_syscall_64+0x33/0x40 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7f829c36c11b > Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c > c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 25 bd 0c 00 f7 d8 64 89 01 48 > RSP: 002b:7f8282c14f38 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7f8282c14fa0 RCX: 7f829c36c11b > RDX: 7f8282c14fa0 RSI: c0186444 RDI: 0018 > RBP: c0186444 R08: 7f8282c15640 R09: 7f8282c14f80 > R10: R11: 0246 R12: 1f592c0fe088 > R13: 0018 R14: R15: fffd > Mem-Info: > active_anon:24325 inactive_anon:3569299 isolated_anon:0 > active_file:704540 inactive_file:2709725 isolated_file:0 > unevictable:1230 dirty:256317 writeback:7074 > slab_reclaimable:222328 slab_unreclaimable:112852 > mapped:838359 shmem:469422 pagetables:47722 bounce:0 > free:107165 free_pcp:1298 free_cma:0 > Node 0 active_anon:97300kB inactive_anon:14277196kB > active_file:2818160kB inactive_file:10838900kB unevictable:4920kB > isolated(anon):0kB isolated(file):0kB mapped:3353436kB dirty:1025268kB > writeback:28296kB shmem:1877688kB shmem_thp: 0kB shmem_pmdmapped: 0kB > anon_thp: 0kB writeback_tmp:0kB kernel_stack:62528kB > pagetables:190888kB all_unreclaimable? no > Node 0 DMA free:11800kB min:32kB low:44kB high:56kB > reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB > active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB > present:15992kB managed:15900kB mlocked:0kB bounce:0kB free_pcp:0kB > local_pcp:0kB free_cma:0kB > lowmem_reserve[]: 0 3056 31787 31787 31787 > Node 0 DMA32 free:303044kB min:6492kB low:9620kB high:12748kB > reserved_highatomic:0KB active_anon:20kB inactive_anon:1322808kB > active_file:5136kB inactive_file:483136kB unevictable:0kB > writepending:220876kB present:3314552kB managed:3246620kB mlocked:0kB > bounce:0kB free_pcp:4kB local_pcp:0kB free_cma:0kB > lowmem_reserve[]: 0 0 28731 28731 28731 > Node 0 Normal free:113816kB min:61052kB low:90472kB high:119892kB > reserved_highatomic:0KB active_anon:97280kB inactive_anon:12953852kB > active_file:2812656kB inactive_file:10355000kB unevictable:4920kB > writepending:832688kB present:30133248kB managed:29421044kB > mlocked:4920kB bounce:0kB free_pcp:5180kB local_pcp:4kB free_cma:0kB > lowmem_reserve[]: 0 0 0 0 0 > Node 0 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) > 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 2*4096kB (M) = 11800kB > Node 0 DMA32: 1009*4kB (UME) 724*8kB (UME) 488*16kB (UME) *32kB > (UME) 950*64kB (UME) 620*128kB (UME) 223*256kB (UME) 74*512kB (M) > 11*1024kB (M) 2*2048kB (ME) 0*4096kB = 303684kB > Node
aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/firmware/arm_scmi/voltage.o' being placed in section `.eh_frame'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8c947645151cc2c279c75c7f640dd8f0fc0b9aa2 commit: 2add5cacff3531e54c50b0832128299faa9f0563 firmware: arm_scmi: Add voltage domain management protocol support date: 2 months ago config: arm64-randconfig-r013-20210130 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 275c6af7d7f1ed63a03d05b4484413e447133269) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2add5cacff3531e54c50b0832128299faa9f0563 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 2add5cacff3531e54c50b0832128299faa9f0563 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/speakup_dectlk.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/speakup_decext.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/speakup_soft.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/buffers.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/devsynth.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/i18n.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/fakekey.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/main.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/keyhelp.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/kobjects.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/selection.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/spk_ttyio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/synth.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/thread.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/accessibility/speakup/varhandlers.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/core.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/bus.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/host.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/mmc.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/mmc_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sd.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sd_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sdio.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sdio_ops.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sdio_bus.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: warning: orphan section `.eh_frame' from `drivers/mmc/core/sdio_cis.o' being placed in section `.eh_frame' aarch64-linux-gnu-ld: w
Re: [PATCH 8/8] gpio: sim: new testing module
On Sat, Jan 30, 2021 at 09:37:55PM +0100, Bartosz Golaszewski wrote: > On Fri, Jan 29, 2021 at 4:57 PM Andy Shevchenko > wrote: > > > > On Fri, Jan 29, 2021 at 02:46:24PM +0100, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski > > ... > > [snip] > > Honestly, I don't like the idea of Yet Another (custom) Parser in the > > kernel. > > > > Have you investigated existing parsers? We have cmdline.c, > > gpio-aggregator.c, > > etc. Besides the fact of test cases which are absent here. And who knows > > what > > we allow to be entered. > > > > Yes, I looked all around the kernel to find something I could reuse > but failed to find anything useful for this particular purpose. If you > have something you could point me towards, I'm open to alternatives. > > Once we agree on the form of the module, I'll port self-tests to using > it instead of gpio-mockup, so we'll have some tests in the tree. > Given the existing selftests focus on testing the gpio-mockup itself, it would be more appropriate that you add separate tests for gpio-sim. As an end user I'm interested in the concrete example of driving gpio-sim that selftests would provide, so I'm looking forward to seeing that. Cheers, Kent.
Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls
On Sat, 2021-01-30 at 15:49 -0800, Guenter Roeck wrote: > On 1/29/21 2:59 PM, Jarkko Sakkinen wrote: > > On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łukasz Majczak wrote: > > > Hi Jarkko, Guenter > > > > > > Yes, here are the logs when failure occurs - > > > https://gist.github.com/semihalf-majczak-lukasz/1575461f585f1e7fb1e9366b8eceaab9 > > > Look for a phrase "TPM returned invalid status" > > > > > > Guenter - good suggestion - I will try to keep it as tight as > > > possible. > > > > > > Best regards, > > > Lukasz > > > > Is it possible for you try out with linux-next? Thanks. It's a > > known issue, which ought to be fixed by now. > > > > The log message is harmless, it'a warning not panic, and does not > > endanger system stability. WARN()'s always dump stack trace. No > > oops is happening. > > > > There is a note in the kernel documentation which states: > > Note that the WARN()-family should only be used for "expected to > be unreachable" situations. If you want to warn about "reachable > but undesirable" situations, please use the pr_warn()-family of > functions. It fits the definition. The warning only triggers if the access is in the wrong locality, which should be impossible, so the warning should be unreachable. James > It seems to me that "harmless" doesn't really fit the expected > use of WARN(). Should it possibly be converted to pr_warn() ?
Re: [PATCH v7 2/2] Kbuild: implement support for DWARF v5
On Sun, Jan 31, 2021 at 1:37 AM Fāng-ruì Sòng wrote:
>
> On Sat, Jan 30, 2021 at 3:10 PM Sedat Dilek wrote:
> >
> > On Sat, Jan 30, 2021 at 1:44 AM Nick Desaulniers
> > wrote:
> > >
> > > DWARF v5 is the latest standard of the DWARF debug info format.
> > >
> > > Feature detection of DWARF5 is onerous, especially given that we've
> > > removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> > > support.
> > >
> > > The DWARF version of a binary can be validated with:
> > > $ llvm-dwarfdump vmlinux | head -n 4 | grep version
> > > or
> > > $ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version
> > >
> > > DWARF5 wins significantly in terms of size when mixed with compression
> > > (CONFIG_DEBUG_INFO_COMPRESSED).
> > >
> > > 363Mvmlinux.clang12.dwarf5.compressed
> > > 434Mvmlinux.clang12.dwarf4.compressed
> > > 439Mvmlinux.clang12.dwarf2.compressed
> > > 457Mvmlinux.clang12.dwarf5
> > > 536Mvmlinux.clang12.dwarf4
> > > 548Mvmlinux.clang12.dwarf2
> > >
> > > 515Mvmlinux.gcc10.2.dwarf5.compressed
> > > 599Mvmlinux.gcc10.2.dwarf4.compressed
> > > 624Mvmlinux.gcc10.2.dwarf2.compressed
> > > 630Mvmlinux.gcc10.2.dwarf5
> > > 765Mvmlinux.gcc10.2.dwarf4
> > > 809Mvmlinux.gcc10.2.dwarf2
> > >
> > > Though the quality of debug info is harder to quantify; size is not a
> > > proxy for quality.
> > >
> > > Jakub notes:
> > > All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
> > > option that enabled some small DWARF subset (initially only a few
> > > DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
> > > after DWARF 5 has been finalized) started emitting DWARF5 section
> > > headers and got most of the DWARF5 changes in...
> > >
> > > Version check GCC so that we don't need to worry about the difference in
> > > command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
> > > validate the DWARF Version in the assembler feature detection script.
> > >
> > > GNU `as` only recently gained support for specifying -gdwarf-5, so when
> > > compiling with Clang but without Clang's integrated assembler
> > > (LLVM_IAS=1 is not set), explicitly add -Wa,-gdwarf-5 to DEBUG_CFLAGS.
> > >
> > > Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
> > > recognize the new additions to the DWARF debug info. Thanks to Sedat for
> > > the report.
> > >
> > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> > > Reported-by: Sedat Dilek
> > > Suggested-by: Arvind Sankar
> > > Suggested-by: Caroline Tice
> > > Suggested-by: Fangrui Song
> > > Suggested-by: Jakub Jelinek
> > > Suggested-by: Masahiro Yamada
> > > Suggested-by: Nathan Chancellor
> > > Signed-off-by: Nick Desaulniers
> > > ---
> > > Makefile | 1 +
> > > include/asm-generic/vmlinux.lds.h | 7 ++-
> > > lib/Kconfig.debug | 18 ++
> > > scripts/test_dwarf5_support.sh| 8
> > > 4 files changed, 33 insertions(+), 1 deletion(-)
> > > create mode 100755 scripts/test_dwarf5_support.sh
> > >
> > > diff --git a/Makefile b/Makefile
> > > index d2b4980807e0..5387a6f2f62d 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -831,6 +831,7 @@ KBUILD_AFLAGS += -Wa,-gdwarf-2
> > > endif
> > >
> > > dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > > DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> > >
> > > ifdef CONFIG_DEBUG_INFO_REDUCED
> > > diff --git a/include/asm-generic/vmlinux.lds.h
> > > b/include/asm-generic/vmlinux.lds.h
> > > index 34b7e0d2346c..1e7cde4bd3f9 100644
> > > --- a/include/asm-generic/vmlinux.lds.h
> > > +++ b/include/asm-generic/vmlinux.lds.h
> > > @@ -842,8 +842,13 @@
> > > /* DWARF 4 */ \
> > > .debug_types0 : { *(.debug_types) } \
> > > /* DWARF 5 */ \
> > > + .debug_addr 0 : { *(.debug_addr) } \
> > > + .debug_line_str 0 : { *(.debug_line_str) } \
> > > + .debug_loclists 0 : { *(.debug_loclists) } \
> > > .debug_macro0 : { *(.debug_macro) } \
> > > - .debug_addr 0 : { *(.debug_addr) }
> > > + .debug_names0 : { *(.debug_names) } \
> > > + .debug_rnglists 0 : { *(.debug_rnglists) } \
> > > + .debug_str_offsets 0 : { *(.debug_str_offsets) }
> > >
> >
> > I just looked at binutils 2.36 in the Debian/experimental repositories.
> >
> > [1] says:
> >
> > + PR ld/27230
> > + * scripttempl/DWARF.sc: Add DWARF-5 .debug_* sections.
> >
> > ...
> >
> > - /* DWARF Extension. */
> > - .debug_macro0 : { *(.debug_macro) }
> > + /* DWARF 5. */
> >.debug_addr 0 : { *(.debug_addr) }
> > +
Re: [PATCH net] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
On Sat, Jan 30, 2021 at 09:43:34PM +0800, DENG Qingfang wrote:
> Having multiple destination ports for a unicast address does not make
> sense.
> Make port_db_load_purge override existent unicast portvec instead of
> adding a new port bit.
>
> Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU")
> Signed-off-by: DENG Qingfang
> ---
Reviewed-by: Vladimir Oltean
Tobias has a point in a way too, you should get used to adding the
'master static' flags to your bridge fdb commands, otherwise weird
things like this could happen. The faulty code can only be triggered
when going through dsa_legacy_fdb_add, but it is still faulty
nonetheless.
Re: [PATCH v4 1/2] x86/setup: always add the beginning of RAM as memblock.memory
On Sat, Jan 30, 2021 at 2:10 PM Mike Rapoport wrote: > > In either case, e820__memblock_setup() won't add the range 0x - 0x1000 > to memblock.memory and later during memory map initialization this range is > left outside any zone. Honestly, this just sounds like memblock being stupid in the first place. Why aren't these zones padded to sane alignments? This patch smells like working around the memblock code being fragile rather than a real fix. That's *particularly* true when the very line above it did a "memblock_reserve()" of the exact same range that the memblock_add() "adds". Linus
Re: [RFC 00/20] TLB batching consolidation and enhancements
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>
> From: Nadav Amit
>
> There are currently (at least?) 5 different TLB batching schemes in the
> kernel:
>
> 1. Using mmu_gather (e.g., zap_page_range()).
>
> 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the
>ongoing deferred TLB flush and flushing the entire range eventually
>(e.g., change_protection_range()).
>
> 3. arch_{enter|leave}_lazy_mmu_mode() for sparc and powerpc (and Xen?).
>
> 4. Batching per-table flushes (move_ptes()).
>
> 5. By setting a flag on that a deferred TLB flush operation takes place,
>flushing when (try_to_unmap_one() on x86).
Are you referring to the arch_tlbbatch_add_mm/flush mechanism?
Re: [PATCH v7 2/2] Kbuild: implement support for DWARF v5
On Sat, Jan 30, 2021 at 3:10 PM Sedat Dilek wrote:
>
> On Sat, Jan 30, 2021 at 1:44 AM Nick Desaulniers
> wrote:
> >
> > DWARF v5 is the latest standard of the DWARF debug info format.
> >
> > Feature detection of DWARF5 is onerous, especially given that we've
> > removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> > support.
> >
> > The DWARF version of a binary can be validated with:
> > $ llvm-dwarfdump vmlinux | head -n 4 | grep version
> > or
> > $ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version
> >
> > DWARF5 wins significantly in terms of size when mixed with compression
> > (CONFIG_DEBUG_INFO_COMPRESSED).
> >
> > 363Mvmlinux.clang12.dwarf5.compressed
> > 434Mvmlinux.clang12.dwarf4.compressed
> > 439Mvmlinux.clang12.dwarf2.compressed
> > 457Mvmlinux.clang12.dwarf5
> > 536Mvmlinux.clang12.dwarf4
> > 548Mvmlinux.clang12.dwarf2
> >
> > 515Mvmlinux.gcc10.2.dwarf5.compressed
> > 599Mvmlinux.gcc10.2.dwarf4.compressed
> > 624Mvmlinux.gcc10.2.dwarf2.compressed
> > 630Mvmlinux.gcc10.2.dwarf5
> > 765Mvmlinux.gcc10.2.dwarf4
> > 809Mvmlinux.gcc10.2.dwarf2
> >
> > Though the quality of debug info is harder to quantify; size is not a
> > proxy for quality.
> >
> > Jakub notes:
> > All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
> > option that enabled some small DWARF subset (initially only a few
> > DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
> > after DWARF 5 has been finalized) started emitting DWARF5 section
> > headers and got most of the DWARF5 changes in...
> >
> > Version check GCC so that we don't need to worry about the difference in
> > command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
> > validate the DWARF Version in the assembler feature detection script.
> >
> > GNU `as` only recently gained support for specifying -gdwarf-5, so when
> > compiling with Clang but without Clang's integrated assembler
> > (LLVM_IAS=1 is not set), explicitly add -Wa,-gdwarf-5 to DEBUG_CFLAGS.
> >
> > Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
> > recognize the new additions to the DWARF debug info. Thanks to Sedat for
> > the report.
> >
> > Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> > Reported-by: Sedat Dilek
> > Suggested-by: Arvind Sankar
> > Suggested-by: Caroline Tice
> > Suggested-by: Fangrui Song
> > Suggested-by: Jakub Jelinek
> > Suggested-by: Masahiro Yamada
> > Suggested-by: Nathan Chancellor
> > Signed-off-by: Nick Desaulniers
> > ---
> > Makefile | 1 +
> > include/asm-generic/vmlinux.lds.h | 7 ++-
> > lib/Kconfig.debug | 18 ++
> > scripts/test_dwarf5_support.sh| 8
> > 4 files changed, 33 insertions(+), 1 deletion(-)
> > create mode 100755 scripts/test_dwarf5_support.sh
> >
> > diff --git a/Makefile b/Makefile
> > index d2b4980807e0..5387a6f2f62d 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -831,6 +831,7 @@ KBUILD_AFLAGS += -Wa,-gdwarf-2
> > endif
> >
> > dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> >
> > ifdef CONFIG_DEBUG_INFO_REDUCED
> > diff --git a/include/asm-generic/vmlinux.lds.h
> > b/include/asm-generic/vmlinux.lds.h
> > index 34b7e0d2346c..1e7cde4bd3f9 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -842,8 +842,13 @@
> > /* DWARF 4 */ \
> > .debug_types0 : { *(.debug_types) } \
> > /* DWARF 5 */ \
> > + .debug_addr 0 : { *(.debug_addr) } \
> > + .debug_line_str 0 : { *(.debug_line_str) } \
> > + .debug_loclists 0 : { *(.debug_loclists) } \
> > .debug_macro0 : { *(.debug_macro) } \
> > - .debug_addr 0 : { *(.debug_addr) }
> > + .debug_names0 : { *(.debug_names) } \
> > + .debug_rnglists 0 : { *(.debug_rnglists) } \
> > + .debug_str_offsets 0 : { *(.debug_str_offsets) }
> >
>
> I just looked at binutils 2.36 in the Debian/experimental repositories.
>
> [1] says:
>
> + PR ld/27230
> + * scripttempl/DWARF.sc: Add DWARF-5 .debug_* sections.
>
> ...
>
> - /* DWARF Extension. */
> - .debug_macro0 : { *(.debug_macro) }
> + /* DWARF 5. */
>.debug_addr 0 : { *(.debug_addr) }
> + .debug_line_str 0 : { *(.debug_line_str) }
> + .debug_loclists 0 : { *(.debug_loclists) }
> + .debug_macro0 : { *(.debug_macro) }
> + .debug_names0 : { *(.debug_names) }
> + .debug_rnglists 0 : { *(.debug_rnglists) }
> + .debug_str_offsets 0 : { *(.debug_str_offsets) }
> +
Re: [PATCH net] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
On Sat, Jan 30, 2021 at 09:47:02PM +0100, Tobias Waldekranz wrote: > root@envoy:~# bridge fdb add 02:00:de:ad:00:01 dev eth1 static vlan 1 > Why does the second add operation succeed? Am I missing some magic flag? Yes, 'master'. We talked about this before. 'bridge fdb add' is implicitly 'self' which bypasses the bridge code and shoots straight for the .ndo_fdb_add that DSA implements. Maybe we should just kill that to avoid further confusion. $ bridge link 6: eth0: mtu 1500 master br0 state disabled priority 32 cost 100 7: eth1: mtu 1500 master br0 state disabled priority 32 cost 100 10: swp5@eth2: mtu 1500 master br0 state forwarding priority 32 cost 4 11: swp2@eth2: mtu 1500 master br0 state forwarding priority 32 cost 4 12: swp3@eth2: mtu 1500 master br0 state forwarding priority 32 cost 4 13: swp4@eth2: mtu 1500 master br0 state forwarding priority 32 cost 4 $ bridge fdb add 00:01:02:03:04:05 dev eth0 master static $ bridge fdb add 00:01:02:03:04:05 dev eth1 master static RTNETLINK answers: File exists
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
Greg K-H wrote: > our job is to make Linux work for everyone. But as your refusal to accept the purely additive (zero impact on anything other than specific hw in question) patch adding support for a new hardware device clearly indicates, your job is NOT to make Linux work for everyone, but rather for a smaller subset of "everyone" *other than* hardware designers who come to the maintainers in good faith, asking to mainline support for new hardware they just made. Johan Hovold wrote: > I couldn't find any such guarantee about the state of these pins when in > output mode in the document you refer to, but that's besides the point. The FTDI document in question shows when the pins in question transition between actively driving outputs and tristate, making it clear to hw engineers that the Hi-Z state must be handled gracefully, practically meaning that pull-up resistors to the I/O voltage rail need to the added. But as one can trivially confirm with an oscilloscope, the power-up transition is from tristate to driving HIGH, not low - the *only* time when the chip will drive low on these outputs is when the USB host explicitly commands it to, either by turning on DTR/RTS in UART mode or by switching to one of the non-UART modes in which these pins acquire different functions. > First, there are other serial devices than those from FTDI. The same principle applies to the initial power-up state of every other reasonable UART chip on the planet. Take the very original 8250 with good old +5V supply voltage - as you first apply power to the chip, the DTR and RTS outputs will be TTL high (corresponding to RS-232 inactive), and they *will not* drive low until and unless you write into the Modem Control Register to change their state. > Second, > these lines can be in any state when the OS boots (e.g. set by a > previous user or OS). If the user is specifically working with a special hardware device that does not tolerate DTR/RTS being randomly jerked around, it is that user's responsibility to ensure that there is NO "previous user or OS" anywhere in the picture. Right now the only active use case (active use case one meaning one with at least one live human actively campaigning for it in the present time) is my DUART28C, and in this active use case the USB-serial interface and the DTR/RTS-sensitive hardware behind this interface are inseparably integrated (a single PCB) into one special USB device. This special USB device does not exist at all to the host computer until the user plugs it in with the intent of operating on it - so there is *no* "previous user or OS" to talk about. > In fact, we already do provide such a way and perhaps that is what we > should use here. We can simply have the ftdi_sio driver not bind to > your control interface, which isn't a serial interface to begin with > anyway. > > Then you're free to use it in whatever way you prefer using libusb. Not acceptable: even though DTR and RTS lines from FT2232D Channel B are repurposed for a non-serial function, the main TxD & RxD lines on that FT2232D channel do form a standard serial interface, and it needs to work as such. Your proposal to use libusb for all serial communication on the secondary channel is unacceptable because it would require writing two versions of every userspace program that needs to talk to the second UART of the Calypso GSM chip: one special libusb-based version for use with DUART28C, and the other standard /dev/ttyXXX version for every other possible serial port to which the second UART of a Calypso GSM chip can be connected, of which there is a great multitude. One part that might not be obvious and probably needs clarification is that the second UART of the Calypso GSM chip (made by TI, not me) is a data-leads-only (TxD & RxD only) interface without any modem control or even hw flow control capability, hence whenever it is connected to any standard UART, that standard UART's modem control and flow control signals are left unconnected - thus DTR and RTS outputs go nowhere. "Standard" userspace software that talks to this UART interface (if one can use the word "standard" for software that is specifically written to speak the proprietary serial protocol of one particular chip vendor) thus does absolutely nothing regarding DTR and RTS - does not touch them in any way, beyond the kernel's automatic assertion on open and negation on close. My only innovation in the DUART28C adapter is to take these two otherwise unused outputs and repurpose them for a different useful function. My userspace programs take -Pdtr and -Prts options that cause these outputs to be pulsed; in the absence of these options (when the very same userspace program is used to talk to the very same TI chip going through a different hw path than my DUART28C), nothing special is done with DTR or RTS, and the kernel's automatic diddling of these lines poses no problem when they are unused and unconnected, as happens with every standard
[RFC 18/20] mm: make mm_cpumask() volatile
From: Nadav Amit
mm_cpumask() is volatile: a bit might be turned on or off at any given
moment, and it is not protected by any lock. While the kernel coding
guidelines are very prohibitive against the use of volatile, not marking
mm_cpumask() as volatile seems wrong.
Cpumask and bitmap manipulation functions may work fine, as they are
allowed to use either the new or old value. Apparently they do, as no
bugs were reported. However, the fact that mm_cpumask() is not volatile
might lead to theoretical bugs due to compiler optimizations.
For example, cpumask_next() uses _find_next_bit(). A compiler might add
to _find_next_bit() invented loads that would cause __ffs() to run on
different value than the one read before. Consequently, if something
like that happens, the result might be a CPU that was neither set on the
old nor the new mask. I could not find what might go wrong in such a
case, but it seems as an improper result.
Mark mm_cpumask() result as volatile and propagate the "volatile"
qualifier according to the compiler shouts.
Signed-off-by: Nadav Amit
Cc: Andrea Arcangeli
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Yu Zhao
Cc: x...@kernel.org
---
arch/arm/include/asm/bitops.h | 4 ++--
arch/x86/hyperv/mmu.c | 2 +-
arch/x86/include/asm/paravirt_types.h | 2 +-
arch/x86/include/asm/tlbflush.h | 2 +-
arch/x86/mm/tlb.c | 4 ++--
arch/x86/xen/mmu_pv.c | 2 +-
include/asm-generic/bitops/find.h | 8
include/linux/bitmap.h| 16 +++
include/linux/cpumask.h | 28 +--
include/linux/mm_types.h | 4 ++--
include/linux/smp.h | 6 +++---
kernel/smp.c | 8
lib/bitmap.c | 8
lib/cpumask.c | 8
lib/find_bit.c| 10 +-
15 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index c92e42a5c8f7..c8690c0ff15a 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -162,8 +162,8 @@ extern int _test_and_change_bit(int nr, volatile unsigned
long * p);
*/
extern int _find_first_zero_bit_le(const unsigned long *p, unsigned size);
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int
offset);
-extern int _find_first_bit_le(const unsigned long *p, unsigned size);
-extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+extern int _find_first_bit_le(const volatile unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const volatile unsigned long *p, int size, int
offset);
/*
* Big endian assembly bitops. nr = 0 -> byte 3 bit 0.
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index 2c87350c1fb0..76ce8a0f19ef 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -52,7 +52,7 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
return gva_n - offset;
}
-static void hyperv_flush_tlb_others(const struct cpumask *cpus,
+static void hyperv_flush_tlb_others(const volatile struct cpumask *cpus,
const struct flush_tlb_info *info)
{
int cpu, vcpu, gva_n, max_gvas;
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index b6b02b7c19cc..35b5696aedc7 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -201,7 +201,7 @@ struct pv_mmu_ops {
void (*flush_tlb_user)(void);
void (*flush_tlb_kernel)(void);
void (*flush_tlb_one_user)(unsigned long addr);
- void (*flush_tlb_others)(const struct cpumask *cpus,
+ void (*flush_tlb_others)(const volatile struct cpumask *cpus,
const struct flush_tlb_info *info);
void (*tlb_remove_table)(struct mmu_gather *tlb, void *table);
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 296a00545056..a4e7c90d11a8 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -208,7 +208,7 @@ struct flush_tlb_info {
void flush_tlb_local(void);
void flush_tlb_one_user(unsigned long addr);
void flush_tlb_one_kernel(unsigned long addr);
-void flush_tlb_others(const struct cpumask *cpumask,
+void flush_tlb_others(const volatile struct cpumask *cpumask,
const struct flush_tlb_info *info);
#ifdef CONFIG_PARAVIRT
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 48f4b56fc4a7..ba85d6bb4988 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -796,7 +796,7 @@ static bool tlb_is_not_lazy(int cpu, void *data)
return !per_cpu(cpu_tlbstate.is_lazy, cpu);
}
-STATIC_NOPV void native_flush_tlb_others(const struct cpumask
[RFC 16/20] mm/tlb: per-page table generation tracking
From: Nadav Amit
Detecting deferred TLB flushes per-VMA has two drawbacks:
1. It requires an atomic cmpxchg to record mm's TLB generation at the
time of the last TLB flush, as two deferred TLB flushes on the same VMA
can race.
2. It might be in coarse granularity for large VMAs.
On 64-bit architectures that have available space on page-struct, we can
resolve these two drawbacks by recording the TLB generation at the time
of the last deferred flush in page-struct of page-table whose TLB
flushes were deferred.
Introduce a new CONFIG_PER_TABLE_DEFERRED_FLUSHES config option. Record
when enabled the deferred TLB flush generation on page-struct, which is
protected by the page-table lock.
Signed-off-by: Nadav Amit
Cc: Andrea Arcangeli
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Yu Zhao
Cc: x...@kernel.org
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/pgtable.h | 23 ++--
fs/proc/task_mmu.c | 6 ++--
include/asm-generic/tlb.h | 65 ++
include/linux/mm.h | 13 +++
include/linux/mm_types.h | 22
init/Kconfig | 7
mm/huge_memory.c | 2 +-
mm/mapping_dirty_helpers.c | 4 +--
mm/mprotect.c | 2 +-
10 files changed, 113 insertions(+), 32 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d56b0f5cb00c..dfc6ee9dbe9c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -250,6 +250,7 @@ config X86
select X86_FEATURE_NAMESif PROC_FS
select PROC_PID_ARCH_STATUS if PROC_FS
select MAPPING_DIRTY_HELPERS
+ select PER_TABLE_DEFERRED_FLUSHES if X86_64
imply IMA_SECURE_AND_OR_TRUSTED_BOOTif EFI
config INSTRUCTION_DECODER
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index a0e069c15dbc..b380a849be90 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -774,17 +774,18 @@ static inline int pte_devmap(pte_t a)
}
#endif
-#define pte_accessible pte_accessible
-static inline bool pte_accessible(struct vm_area_struct *vma, pte_t *a)
-{
- if (pte_flags(*a) & _PAGE_PRESENT)
- return true;
-
- if ((pte_flags(*a) & _PAGE_PROTNONE) && pte_tlb_flush_pending(vma, a))
- return true;
-
- return false;
-}
+#define pte_accessible(vma, a) \
+ ({ \
+ pte_t *_a = (a);\
+ bool r = false; \
+ \
+ if (pte_flags(*_a) & _PAGE_PRESENT) \
+ r = true; \
+ else\
+ r = ((pte_flags(*_a) & _PAGE_PROTNONE) && \
+pte_tlb_flush_pending((vma), _a)); \
+ r; \
+ })
static inline int pmd_present(pmd_t pmd)
{
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index d0cce961fa5c..00e116feb62c 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1157,7 +1157,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long
addr,
/* Clear accessed and referenced bits. */
pmdp_test_and_clear_young(vma, addr, pmd);
test_and_clear_page_young(page);
- tlb_flush_pmd_range(>tlb, addr, HPAGE_PMD_SIZE);
+ tlb_flush_pmd_range(>tlb, pmd, addr, HPAGE_PMD_SIZE);
ClearPageReferenced(page);
out:
spin_unlock(ptl);
@@ -1174,7 +1174,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long
addr,
if (cp->type == CLEAR_REFS_SOFT_DIRTY) {
clear_soft_dirty(vma, addr, pte);
- tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
+ tlb_flush_pte_range(>tlb, pte, addr, PAGE_SIZE);
continue;
}
@@ -1188,7 +1188,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long
addr,
/* Clear accessed and referenced bits. */
ptep_test_and_clear_young(vma, addr, pte);
test_and_clear_page_young(page);
- tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
+ tlb_flush_pte_range(>tlb, pte, addr, PAGE_SIZE);
ClearPageReferenced(page);
}
tlb_end_ptes(>tlb);
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index f25d2d955076..74dbb56d816d 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -310,10
[RFC 19/20] lib/cpumask: introduce cpumask_atomic_or()
From: Nadav Amit
Introduce cpumask_atomic_or() and bitmask_atomic_or() to allow to
perform atomic or operations atomically on cpumasks. This will be used
by the next patch.
To be more efficient, skip atomic operations when no changes are needed.
Signed-off-by: Nadav Amit
Cc: Mel Gorman
Cc: Andrea Arcangeli
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Yu Zhao
Cc: x...@kernel.org
---
include/linux/bitmap.h | 5 +
include/linux/cpumask.h | 12
lib/bitmap.c| 25 +
3 files changed, 42 insertions(+)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 769b7a98e12f..c9a9b784b244 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -76,6 +76,7 @@
* bitmap_to_arr32(buf, src, nbits)Copy nbits from buf to u32[]
dst
* bitmap_get_value8(map, start) Get 8bit value from map at
start
* bitmap_set_value8(map, value, start)Set 8bit value to map at start
+ * bitmap_atomic_or(dst, src, nbits) *dst |= *src (atomically)
*
* Note, bitmap_zero() and bitmap_fill() operate over the region of
* unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -577,6 +578,10 @@ static inline void bitmap_set_value8(unsigned long *map,
unsigned long value,
map[index] |= value << offset;
}
+extern void bitmap_atomic_or(volatile unsigned long *dst,
+ const volatile unsigned long *bitmap, unsigned int bits);
+
+
#endif /* __ASSEMBLY__ */
#endif /* __LINUX_BITMAP_H */
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 3d7e418aa113..0567d73a0192 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -699,6 +699,18 @@ static inline unsigned int cpumask_size(void)
return BITS_TO_LONGS(nr_cpumask_bits) * sizeof(long);
}
+/**
+ * cpumask_atomic_or - *dstp |= *srcp (*dstp is set atomically)
+ * @dstp: the cpumask result (and source which is or'd)
+ * @srcp: the source input
+ */
+static inline void cpumask_atomic_or(volatile struct cpumask *dstp,
+const volatile struct cpumask *srcp)
+{
+ bitmap_atomic_or(cpumask_bits(dstp), cpumask_bits(srcp),
+nr_cpumask_bits);
+}
+
/*
* cpumask_var_t: struct cpumask for stack usage.
*
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 6df7b13727d3..50f1842ff891 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1310,3 +1310,28 @@ void bitmap_to_arr32(u32 *buf, const unsigned long
*bitmap, unsigned int nbits)
EXPORT_SYMBOL(bitmap_to_arr32);
#endif
+
+void bitmap_atomic_or(volatile unsigned long *dst,
+ const volatile unsigned long *bitmap, unsigned int bits)
+{
+ unsigned int k;
+ unsigned int nr = BITS_TO_LONGS(bits);
+
+ for (k = 0; k < nr; k++) {
+ unsigned long src = bitmap[k];
+
+ /*
+* Skip atomic operations when no bits are changed. Do not use
+* bitmap[k] directly to avoid redundant loads as bitmap
+* variable is volatile.
+*/
+ if (!(src & ~dst[k]))
+ continue;
+
+ if (BITS_PER_LONG == 64)
+ atomic64_or(src, (atomic64_t*)[k]);
+ else
+ atomic_or(src, (atomic_t*)[k]);
+ }
+}
+EXPORT_SYMBOL(bitmap_atomic_or);
--
2.25.1
[RFC 20/20] mm/rmap: avoid potential races
From: Nadav Amit
flush_tlb_batched_pending() appears to have a theoretical race:
tlb_flush_batched is being cleared after the TLB flush, and if in
between another core calls set_tlb_ubc_flush_pending() and sets the
pending TLB flush indication, this indication might be lost. Holding the
page-table lock when SPLIT_LOCK is set cannot eliminate this race.
The current batched TLB invalidation scheme therefore does not seem
viable or easily repairable.
Introduce a new scheme, in which a cpumask is maintained for pending
batched TLB flushes. When a full TLB flush is performed clear the
corresponding bit on the CPU the performs the TLB flush.
This scheme is only suitable for architectures that use IPIs for TLB
shootdowns. As x86 is the only architecture that currently uses batched
TLB flushes, this is not an issue.
Signed-off-by: Nadav Amit
Cc: Mel Gorman
Cc: Andrea Arcangeli
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Yu Zhao
Cc: x...@kernel.org
---
arch/x86/include/asm/tlbbatch.h | 15
arch/x86/include/asm/tlbflush.h | 2 +-
arch/x86/mm/tlb.c | 18 ++-
include/linux/mm.h | 7 ++
include/linux/mm_types_task.h | 13 ---
mm/rmap.c | 41 -
6 files changed, 40 insertions(+), 56 deletions(-)
delete mode 100644 arch/x86/include/asm/tlbbatch.h
diff --git a/arch/x86/include/asm/tlbbatch.h b/arch/x86/include/asm/tlbbatch.h
deleted file mode 100644
index 1ad56eb3e8a8..
--- a/arch/x86/include/asm/tlbbatch.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ARCH_X86_TLBBATCH_H
-#define _ARCH_X86_TLBBATCH_H
-
-#include
-
-struct arch_tlbflush_unmap_batch {
- /*
-* Each bit set is a CPU that potentially has a TLB entry for one of
-* the PFNs being flushed..
-*/
- struct cpumask cpumask;
-};
-
-#endif /* _ARCH_X86_TLBBATCH_H */
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index a4e7c90d11a8..0e681a565b78 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -240,7 +240,7 @@ static inline void flush_tlb_page(struct vm_area_struct
*vma, unsigned long a)
flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, PAGE_SHIFT, false);
}
-extern void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch);
+extern void arch_tlbbatch_flush(void);
static inline bool pte_may_need_flush(pte_t oldpte, pte_t newpte)
{
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index ba85d6bb4988..f7304d45e6b9 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -760,8 +760,15 @@ static void flush_tlb_func_common(const struct
flush_tlb_info *f,
count_vm_tlb_events(NR_TLB_LOCAL_FLUSH_ONE,
nr_invalidate);
trace_tlb_flush(reason, nr_invalidate);
} else {
+ int cpu = smp_processor_id();
+
/* Full flush. */
flush_tlb_local();
+
+ /* If there are batched TLB flushes, mark they are done */
+ if (cpumask_test_cpu(cpu, _flush_batched_cpumask))
+ cpumask_clear_cpu(cpu, _flush_batched_cpumask);
+
if (local)
count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
trace_tlb_flush(reason, TLB_FLUSH_ALL);
@@ -1143,21 +1150,20 @@ static const struct flush_tlb_info full_flush_tlb_info
= {
.end = TLB_FLUSH_ALL,
};
-void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
+void arch_tlbbatch_flush(void)
{
int cpu = get_cpu();
- if (cpumask_test_cpu(cpu, >cpumask)) {
+ if (cpumask_test_cpu(cpu, _flush_batched_cpumask)) {
lockdep_assert_irqs_enabled();
local_irq_disable();
flush_tlb_func_local(_flush_tlb_info, TLB_LOCAL_SHOOTDOWN);
local_irq_enable();
}
- if (cpumask_any_but(>cpumask, cpu) < nr_cpu_ids)
- flush_tlb_others(>cpumask, _flush_tlb_info);
-
- cpumask_clear(>cpumask);
+ if (cpumask_any_but(_flush_batched_cpumask, cpu) < nr_cpu_ids)
+ flush_tlb_others(_flush_batched_cpumask,
+_flush_tlb_info);
/*
* We cannot call mark_mm_tlb_gen_done() since we do not know which
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a8a5bf82bd03..e4985cf6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -3197,5 +3197,12 @@ unsigned long wp_shared_mapping_range(struct
address_space *mapping,
extern int sysctl_nr_trim_pages;
+#ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
+extern volatile cpumask_t tlb_flush_batched_cpumask;
+void tlb_batch_init(void);
+#else
+static inline void tlb_batch_init(void) { }
+#endif
+
#endif /* __KERNEL__ */
#endif /* _LINUX_MM_H */
diff --git
