Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009
Hi, This patch is already tested and confirmed by our colleagues in Guatemala. Regards, Jian-Hong Pan . Jian-Hong Pan | +886 2 7712 8713 | Endless 2018-05-25 22:05 GMT+08:00 Jian-Hong Pan : > Hi Daniel, > > 2018-05-25 21:25 GMT+08:00 Daniel Drake : >> Hi Jian-Hong, >> >> On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan >> wrote: >>> >>> Without this patch we cannot turn on the Bluethooth adapter on HP >>> 14-bs007la. >> >> Please correct me if I'm wrong, but it looks like we are still waiting >> for the testing of this patch from our colleagues in Guatemala. >> >> There are unlikely to be any issues with such a trivial change, but we >> should probably wait for confirmation that it works before having it >> included upstream. > > Oh, sure! That will be better. Thanks for your reminder. > > Thanks, > Jian-Hong Pan > >> Thanks >> Daniel
Re: [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA
2018-04-03 17:04 GMT+08:00 Takashi Iwai : > On Tue, 03 Apr 2018 10:43:02 +0200, > Jian-Hong Pan wrote: >> >> 2018-04-02 19:29 GMT+08:00 Takashi Iwai : >> > >> > On Mon, 02 Apr 2018 09:33:13 +0200, >> > Jian-Hong Pan wrote: >> > > >> > > This ASUS D640SA desktop whose mother board is D640MB has >> > > - two jacks which are a headphone and a mic on the front panel, >> > > - three jacks which are a mic, a line out and a line in on the rear panel >> > > - one internal speaker. >> > > >> > > If I plug a headphone to the front headphone jack, there will be sound >> > > through the headphone jack, and no sound through the internal speaker. >> > > If I unplug the headphone from the the headphone jack, there will be >> > > sound through the internal speaker. And always no sound through rear >> > > line out, when I plug a headphone or an externel speaker to the rear >> > > line out jack. >> > > >> > > Besides, I had checked and toggled the Auto-Mute Mode in alsamixer, but >> > > the rear line out still was not working. Then I checked the sound >> > > settings in GUI, and found there was no "Line Out" could be chosen, only >> > > the "Headphones" and "HDMI/DisplayPort". >> > > However, system does know that there is an "Intel PCH Line Out". >> > > >> > > [ 10.089082] snd_hda_codec_realtek hdaudioC0D0: autoconfig for >> > > ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line >> > > [ 10.089083] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1 >> > > (0x1a/0x0/0x0/0x0/0x0) >> > > [ 10.089084] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 >> > > (0x1b/0x0/0x0/0x0/0x0) >> > > [ 10.089085] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 >> > > [ 10.089086] snd_hda_codec_realtek hdaudioC0D0:inputs: >> > > [ 10.089087] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 >> > > [ 10.089088] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 >> > > [ 10.089089] snd_hda_codec_realtek hdaudioC0D0: Line=0x15 >> > > [ 10.104387] input: HDA Intel PCH Rear Mic as >> > > /devices/pci:00/:00:1f.3/sound/card0/input9 >> > > [ 10.104416] input: HDA Intel PCH Front Mic as >> > > /devices/pci:00/:00:1f.3/sound/card0/input10 >> > > [ 10.104441] input: HDA Intel PCH Line as >> > > /devices/pci:00/:00:1f.3/sound/card0/input11 >> > > [ 10.104467] input: HDA Intel PCH Line Out as >> > > /devices/pci:00/:00:1f.3/sound/card0/input12 >> > > [ 10.104494] input: HDA Intel PCH Front Headphone as >> > > /devices/pci:00/:00:1f.3/sound/card0/input13 >> > > >> > > Consequently, I checked the pin widgets' default configuration values: >> > > - Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out >> > > Pin Default 0x01014010: [Jack] Line Out at Ext Rear >> > > >> > > - Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out >> > > Pin Default 0x02214030: [Jack] HP Out at Ext Front >> > > >> > > Because the headphone jack (Node ID:0x1b) locates on the desktop's front >> > > panel, not rear panel, I change the headphone jack's configuration from >> > > primary chassis to separate chassis. So, the configuration value of >> > > Node ID:0x1b should be 0x22214030. >> > >> > This is OK, but... >> > >> > > Additionally, I toggle the Auto-Mute Mode of Realtek codecs to “Speaker >> > > Only” which makes signal outputs through line out jack when the "Line >> > > Out" is chosen in the sound settings. >> > >> > ... this is a matter of taste, and I don't think it good to set a >> > different default from others. You can change it once and save it via >> > alsactl. >> >> The default state of Auto-Mute Mode of Realtek codec on this machine is >> "Line Out + Speaker". >> This disallows to output audio signal through the line out jack, even I >> already >> choose the "Line Out" as the audio output device in the sound settings. >> It means there is no way to use the line out jack in "Line Out + Speaker" >> state >> of Auto-Mute Mode on this machine. > > It's a setup issue by PA, and it's not specific to this device at > all.
[PATCH] platform/x86: asus-wmi: Simplify the keyboard brightness updating process
The original asus-wmi queues a work which calls the ACPI/WMI methods to
update the keyboard LED brightness. Similar drivers - acer-wmi,
dell-wmi-led just call the ACPI/WMI methods directly without workqueues.
This patch simplifies the keyboard brightness updating process which
calls the kbd_led_update function directly without workqueue in
asus-wmi.
Signed-off-by: Jian-Hong Pan
---
drivers/platform/x86/asus-wmi.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 2d6e272315a8..9441cce636e6 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -239,7 +239,6 @@ struct asus_wmi {
int lightbar_led_wk;
struct workqueue_struct *led_workqueue;
struct work_struct tpd_led_work;
- struct work_struct kbd_led_work;
struct work_struct wlan_led_work;
struct work_struct lightbar_led_work;
@@ -456,12 +455,9 @@ static enum led_brightness tpd_led_get(struct led_classdev
*led_cdev)
return read_tpd_led_state(asus);
}
-static void kbd_led_update(struct work_struct *work)
+static void kbd_led_update(struct asus_wmi *asus)
{
int ctrl_param = 0;
- struct asus_wmi *asus;
-
- asus = container_of(work, struct asus_wmi, kbd_led_work);
/*
* bits 0-2: level
@@ -516,7 +512,7 @@ static void do_kbd_led_set(struct led_classdev *led_cdev,
int value)
value = 0;
asus->kbd_led_wk = value;
- queue_work(asus->led_workqueue, &asus->kbd_led_work);
+ kbd_led_update(asus);
}
static void kbd_led_set(struct led_classdev *led_cdev,
@@ -671,8 +667,6 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
led_val = kbd_led_read(asus, NULL, NULL);
if (led_val >= 0) {
- INIT_WORK(&asus->kbd_led_work, kbd_led_update);
-
asus->kbd_led_wk = led_val;
asus->kbd_led.name = "asus::kbd_backlight";
asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
@@ -2310,7 +2304,7 @@ static int asus_hotk_resume(struct device *device)
struct asus_wmi *asus = dev_get_drvdata(device);
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
- queue_work(asus->led_workqueue, &asus->kbd_led_work);
+ kbd_led_update(asus);
return 0;
}
@@ -2346,7 +2340,7 @@ static int asus_hotk_restore(struct device *device)
rfkill_set_sw_state(asus->uwb.rfkill, bl);
}
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
- queue_work(asus->led_workqueue, &asus->kbd_led_work);
+ kbd_led_update(asus);
return 0;
}
--
2.11.0
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
Jonathan Cameron 於 2018年11月25日 週日 下午9:23寫道： > > On Wed, 21 Nov 2018 13:13:40 +0800 > Jian-Hong Pan wrote: > > > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > > > Hi Jian, > > > > > > Not clear to me why should be + instead of *. > > > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > > time) [s] > > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample > > > sampling time) [ms] > > > > > > In your case you assume bootime is in milliseconds. > > > > Yes, I assume that according to the original comment. > > > > >Maybe we can change the comment and use 'number of samples ...'. > > > > Making the meaning more clear is better. > > > > However, does the bootime of the measurement need as the long time to > > be enabled? > > If the sampling rate is 1Hz and n is 2, then they will do msleep with > > 2000 ms for each st_sensors_read_info_raw. > > Superficially that seems correct as we need to be sure that a reading > has occurred. If you want it to be quicker than the ODR should be set > faster so that the reading shows up reasonably quickly. At 1Hz and > you want to drop 2 samples, it will indeed take 2 seconds. Now, I understand with the description. Thank you. Jian-Hong Pan > > > -Original Message- > > > From: linux-iio-ow...@vger.kernel.org > > > On Behalf Of Jian-Hong Pan > > > Sent: Sunday, November 18, 2018 10:12 PM > > > To: Jonathan Cameron ; Hartmut Knaack > > > ; Lars-Peter Clausen ; Peter > > > Meerwald-Stadler ; Dominique Martinet > > > > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > li...@endlessm.com; Jian-Hong Pan > > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > > > According to the description of st_sensor_settings and st_sensor_data > > > structures' comments: > > > - bootime: samples to discard when sensor passing from power-down to > > > power-up. > > > - odr: Output data rate of the sensor [Hz]. > > > > > > The sleep time should be > > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > > > Signed-off-by: Jian-Hong Pan > > > --- > > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > > index 26fbd1bd9413..6b87ea657a92 100644 > > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev > > > *indio_dev, > > > if (err < 0) > > > goto out; > > > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > > sdata->odr); > > > + msleep(sdata->sensor_settings->bootime + 1000 / > > > sdata->odr); > > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > > if (err < 0) > > > goto out; > > > -- > > > 2.11.0 > > > >
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > Hi Jian, > > Not clear to me why should be + instead of *. > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > time) [s] > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample sampling > time) [ms] > > In your case you assume bootime is in milliseconds. Yes, I assume that according to the original comment. >Maybe we can change the comment and use 'number of samples ...'. Making the meaning more clear is better. However, does the bootime of the measurement need as the long time to be enabled? If the sampling rate is 1Hz and n is 2, then they will do msleep with 2000 ms for each st_sensors_read_info_raw. Regards, Jian-Hong Pan > > > -Original Message- > From: linux-iio-ow...@vger.kernel.org On > Behalf Of Jian-Hong Pan > Sent: Sunday, November 18, 2018 10:12 PM > To: Jonathan Cameron ; Hartmut Knaack ; > Lars-Peter Clausen ; Peter Meerwald-Stadler > ; Dominique Martinet > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > li...@endlessm.com; Jian-Hong Pan > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > According to the description of st_sensor_settings and st_sensor_data > structures' comments: > - bootime: samples to discard when sensor passing from power-down to power-up. > - odr: Output data rate of the sensor [Hz]. > > The sleep time should be > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > Signed-off-by: Jian-Hong Pan > --- > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > b/drivers/iio/common/st_sensors/st_sensors_core.c > index 26fbd1bd9413..6b87ea657a92 100644 > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev, > if (err < 0) > goto out; > > - msleep((sdata->sensor_settings->bootime * 1000) / sdata->odr); > + msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr); > err = st_sensors_read_axis_data(indio_dev, ch, val); > if (err < 0) > goto out; > -- > 2.11.0 >
[PATCH] iio: st_sensors: Fix the sleep time for sampling
According to the description of st_sensor_settings and st_sensor_data structures' comments: - bootime: samples to discard when sensor passing from power-down to power-up. - odr: Output data rate of the sensor [Hz]. The sleep time should be sdata->sensor_settings->bootime + 1000 / sdata->odr ms. Signed-off-by: Jian-Hong Pan --- drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c b/drivers/iio/common/st_sensors/st_sensors_core.c index 26fbd1bd9413..6b87ea657a92 100644 --- a/drivers/iio/common/st_sensors/st_sensors_core.c +++ b/drivers/iio/common/st_sensors/st_sensors_core.c @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev, if (err < 0) goto out; - msleep((sdata->sensor_settings->bootime * 1000) / sdata->odr); + msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr); err = st_sensors_read_axis_data(indio_dev, ch, val); if (err < 0) goto out; -- 2.11.0
[PATCH 1/4] ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880
From: Chris Chiu
Acer Aspire U27-880(AIO) with ALC286 codec can not detect headset mic
and internal mic not working either. It needs the similar quirk like
Sony laptops to fix headphone jack sensing and enables use of the
internal microphone.
Unfortunately jack sensing for the headset mic is still not working.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index c0b289ba397f..f21d52eb2ed3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5516,6 +5516,7 @@ enum {
ALC221_FIXUP_HP_HEADSET_MIC,
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
+ ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6393,6 +6394,15 @@ static const struct hda_fixup alc269_fixups[] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc_fixup_auto_mute_via_amp,
},
+ [ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x18, 0x01a1913c }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7071,6 +7081,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x19, 0x04a11040},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0286, 0x1025, "Acer",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x02211020}),
SND_HDA_PIN_QUIRK(0x10ec0288, 0x1028, "Dell",
ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
{0x12, 0x90a60120},
{0x14, 0x90170110},
--
2.11.0
[PATCH 2/4] ALSA: hda/realtek - Add support for Acer Aspire C24-860 headset mic
From: Chris Chiu
The Acer AIO Aspire C24-860 with ALC286 can't detect the headset
microphone. Just like another Acer AIO U27-880, it needs a different
pin value for 0x18 and the headset fixup to make headset mic work.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f21d52eb2ed3..5a7a297546db 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6417,6 +6417,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0762, "Acer Aspire E1-472",
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572",
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
+ SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.11.0
[PATCH 3/4] ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G
From: Chris Chiu
Acer AIO Veriton Z4660G with ALC286 codec has issue with the input
from external microphones connecting via 'Front Mic' jack. The fixup
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE enables the jack sensing of
the headset and fix the audio input issue of external microphone.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 5a7a297546db..98f0abaa3540 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6419,6 +6419,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
+ SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440",
ALC292_FIXUP_DELL_E7X),
--
2.11.0
[PATCH 4/4] ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G
From: Chris Chiu
Acer AIO Veriton Z4860G/Z6860G with the same ALC286 codec has issues
with the input from external microphone. The issue can be fixed by
the fixup ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE for Veriton Z4660G.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 98f0abaa3540..bb40624fb6d5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6419,6 +6419,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
+ SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.11.0
[PATCH 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
From: Chris Chiu
The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb40624fb6d5..bbae06267054 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5517,6 +5517,7 @@ enum {
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+ ALC294_FIXUP_ASUS_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6403,6 +6404,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC294_FIXUP_ASUS_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x13, 0x90a60160 }, /* use as internal mic */
+ { 0x19, 0x04a11120 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7152,6 +7163,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell",
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
+ {0x14, 0x90170110},
+ {0x1b, 0x90a70130},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
[PATCH 0/3] Add ALC294 quirks for ASUS laptops
Add Realtek ALC294 quirks for ASUS X542UN, UX533FD and UX433FN laptops. Chris Chiu (1): ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN Jian-Hong Pan (2): ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294 ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN with ALC294 sound/pci/hda/patch_realtek.c | 32 1 file changed, 32 insertions(+) -- 2.11.0
[PATCH 3/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN with ALC294
The ASUS UX433FN with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 5c25c8c3f703..56925140bfe6 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7180,6 +7180,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS",
ALC294_FIXUP_ASUS_SPK_NOISE,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
[PATCH 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
The ASUS UX533FD with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bbae06267054..5c25c8c3f703 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5518,6 +5518,7 @@ enum {
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
ALC294_FIXUP_ASUS_MIC,
+ ALC294_FIXUP_ASUS_SPK_NOISE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6414,6 +6415,17 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
},
+ [ALC294_FIXUP_ASUS_SPK_NOISE] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Set EAPD high */
+ {0x20, AC_VERB_SET_COEF_INDEX, 0x10},
+ {0x20, AC_VERB_SET_PROC_COEF, 0x14},
+ {}
+ },
+ .chained = true,
+ .chain_id = ALC255_FIXUP_ASUS_MIC_NO_PRESENCE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6556,6 +6568,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
+ SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD",
ALC294_FIXUP_ASUS_SPK_NOISE),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
--
2.11.0
Re: [PATCH 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
Kailang 於 2018年12月5日 週三 下午4:36寫道： > > Hi Jian-Hong, > > Could you test to change the model to ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC? > > .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to > ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC According to the comment https://patchwork.kernel.org/patch/10713087/#22360253 , should I try ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC on this model? Jian-Hong Pan
Re: [PATCH 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
> Kailang 於 2018年12月5日 週三 下午4:36寫道： > > > > Hi Jian-Hong, > > > > Could you test to change the model to ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC? > > > > .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to > > ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC We do not have ASUS X542UN in hand right now, but we have ASUS X542UQ which goes with the same quirk as X542UN. I tested with ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC, and it also works. So, I am going to send new patch set using ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC for ALC294. Thanks, Jian-Hong Pan
[PATCH v2 0/3] Add ALC294 quirks for ASUS laptops
Add Realtek ALC294 quirks for ASUS X542UN, UX533FD, UX433FN and UX333FA laptops. Chris Chiu (1): ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN Jian-Hong Pan (2): ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294 ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294 sound/pci/hda/patch_realtek.c | 44 +++ 1 file changed, 44 insertions(+) -- 2.11.0
[PATCH v2 3/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294
The ASUS UX433FN and UX333FA with ALC294 cannot detect the headset MIC
and output through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
v2:
- Add UX333FA support. ASUS UX533FD, UX433FN and UX333FA use the same quirk
now.
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1525bcdf96e8..97d1a4aaeccd 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7192,6 +7192,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS",
ALC294_FIXUP_ASUS_SPK_NOISE,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
[PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
The ASUS UX533FD with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
v2:
- Modify the HDA verbs for UX333FA support
- Make a new ALC294_FIXUP_ASUS_HEADSET_MIC quirk for ALC294 chain
- .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
sound/pci/hda/patch_realtek.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d32e50b1ed60..1525bcdf96e8 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5518,6 +5518,8 @@ enum {
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
ALC294_FIXUP_ASUS_MIC,
+ ALC294_FIXUP_ASUS_HEADSET_MIC,
+ ALC294_FIXUP_ASUS_SPK_NOISE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6414,6 +6416,28 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC294_FIXUP_ASUS_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1113c }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
+ [ALC294_FIXUP_ASUS_SPK_NOISE] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Set EAPD high */
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
+ { 0x20, 0x4c4, 0x20 },
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
+ { 0x20, 0x488, 0x00 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6556,6 +6580,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
+ SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD",
ALC294_FIXUP_ASUS_SPK_NOISE),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
--
2.11.0
[PATCH v2 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
From: Chris Chiu
The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
v2:
- .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
sound/pci/hda/patch_realtek.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb40624fb6d5..d32e50b1ed60 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5517,6 +5517,7 @@ enum {
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+ ALC294_FIXUP_ASUS_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6403,6 +6404,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC294_FIXUP_ASUS_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x13, 0x90a60160 }, /* use as internal mic */
+ { 0x19, 0x04a11120 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7152,6 +7163,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell",
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
+ {0x14, 0x90170110},
+ {0x1b, 0x90a70130},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
Re: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
Kailang 於 2018年12月7日 週五 上午11:32寫道：
>
> Hi Jian Hong,
>
> Could I know who give you the value as below?
>
> + { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
> + { 0x20, 0x4c4, 0x20 },
> + { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> + { 0x20, 0x488, 0x00 },
A module maker.
Regards,
Jian-Hong Pan
> -Original Message-
> From: Jian-Hong Pan
> Sent: Thursday, December 6, 2018 4:46 PM
> To: Jaroslav Kysela ; Takashi Iwai ; Kailang
>
> Cc: Hui Wang ; alsa-de...@alsa-project.org;
> linux-kernel@vger.kernel.org; li...@endlessm.com; Jian-Hong Pan
> ; Daniel Drake
> Subject: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD
> with ALC294
>
> The ASUS UX533FD with ALC294 cannot detect the headset MIC and output through
> the internal speaker and the headphone until ALC294_FIXUP_ASUS_SPK_NOISE
> quirk applied.
>
> Signed-off-by: Daniel Drake
> Signed-off-by: Jian-Hong Pan
> ---
> v2:
> - Modify the HDA verbs for UX333FA support
> - Make a new ALC294_FIXUP_ASUS_HEADSET_MIC quirk for ALC294 chain
> - .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
> ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
>
> sound/pci/hda/patch_realtek.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index d32e50b1ed60..1525bcdf96e8 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -5518,6 +5518,8 @@ enum {
> ALC295_FIXUP_HP_AUTO_MUTE,
> ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
> ALC294_FIXUP_ASUS_MIC,
> + ALC294_FIXUP_ASUS_HEADSET_MIC,
> + ALC294_FIXUP_ASUS_SPK_NOISE,
> };
>
> static const struct hda_fixup alc269_fixups[] = { @@ -6414,6 +6416,28 @@
> static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> },
> + [ALC294_FIXUP_ASUS_HEADSET_MIC] = {
> + .type = HDA_FIXUP_PINS,
> + .v.pins = (const struct hda_pintbl[]) {
> + { 0x19, 0x01a1113c }, /* use as headset mic, without
> its own jack detect */
> + { }
> + },
> + .chained = true,
> + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> + },
> + [ALC294_FIXUP_ASUS_SPK_NOISE] = {
> + .type = HDA_FIXUP_VERBS,
> + .v.verbs = (const struct hda_verb[]) {
> + /* Set EAPD high */
> + { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
> + { 0x20, 0x4c4, 0x20 },
> + { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> + { 0x20, 0x488, 0x00 },
> + { }
> + },
> + .chained = true,
> + .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
> + },
> };
>
> static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6556,6 +6580,7
> @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
> SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
> SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
> ALC269VB_FIXUP_ASUS_ZENBOOK),
> + SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD",
> +ALC294_FIXUP_ASUS_SPK_NOISE),
> SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
> ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
> SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
> SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
> --
> 2.11.0
>
Re: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
> Hi Jian Hong,
>
> I call our agent guy @ WTMEC.
> Please modify as bellowing then test again.
> Remove EAPD control by hidden.
> If this modify patch was pass audio test, please regenerate patch to Takashi.
> If this patch will solve the speaker no sound issue, I think the model name
> maybe could rename to ALC294_FIXUP_ASUS_SPK.
> Because it doesn't relate with Noise.
>
> > + [ALC294_FIXUP_ASUS_SPK_NOISE] = {
> > + .type = HDA_FIXUP_VERBS,
> > + .v.verbs = (const struct hda_verb[]) {
> > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x8800 },
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
> > + },
> > };
>
Thanks for the help!
I have tried the new verbs, and they work on the laptops.
I am going to send the new patches.
Regards,
Jian-Hong Pan
[PATCH v3 0/3] Add ALC294 quirks for ASUS laptops
Add Realtek ALC294 quirks for ASUS X542UN, UX533FD, UX433FN and UX333FA laptops. Chris Chiu (1): ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN Jian-Hong Pan (2): ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294 ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294 sound/pci/hda/patch_realtek.c | 42 ++ 1 file changed, 42 insertions(+) -- 2.11.0
[PATCH v3 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
From: Chris Chiu
The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
v2:
- .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
sound/pci/hda/patch_realtek.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb40624fb6d5..d32e50b1ed60 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5517,6 +5517,7 @@ enum {
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+ ALC294_FIXUP_ASUS_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6403,6 +6404,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC294_FIXUP_ASUS_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x13, 0x90a60160 }, /* use as internal mic */
+ { 0x19, 0x04a11120 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7152,6 +7163,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell",
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
+ {0x14, 0x90170110},
+ {0x1b, 0x90a70130},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
[PATCH v3 3/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294
The ASUS UX433FN and UX333FA with ALC294 cannot detect the headset MIC
and output through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK and ALC294_FIXUP_ASUS_HEADSET_MIC quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
v2:
- Add UX333FA support. ASUS UX533FD, UX433FN and UX333FA use the same quirk
now.
v3:
- Modify the quirk's entry name
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index aa7aabd6e09a..14c883a16290 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7190,6 +7190,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
[PATCH v3 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
The ASUS UX533FD with ALC294 cannot detect the headset MIC and outputs
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK and ALC294_FIXUP_ASUS_HEADSET_MIC quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
v2:
- Modify the HDA verbs for UX333FA support
- Make a new ALC294_FIXUP_ASUS_HEADSET_MIC quirk for ALC294 chain
- .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
v3:
- Modify the HDA verbs from Realtek's suggestion
- Modify the quirk's entry name
sound/pci/hda/patch_realtek.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d32e50b1ed60..aa7aabd6e09a 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5518,6 +5518,8 @@ enum {
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
ALC294_FIXUP_ASUS_MIC,
+ ALC294_FIXUP_ASUS_HEADSET_MIC,
+ ALC294_FIXUP_ASUS_SPK,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6414,6 +6416,26 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC294_FIXUP_ASUS_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1113c }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
+ [ALC294_FIXUP_ASUS_SPK] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Set EAPD high */
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x8800 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6556,6 +6578,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
+ SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", ALC294_FIXUP_ASUS_SPK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
--
2.11.0
Re: [PATCH V4 5/6] net: maclorawan: Implement maclorawan class module
I made a fake skb and passed it to lrw_parse_frame() function for
testing. I use print_hex_dump() function to show the skb's content.
Here is the original content in the skb->data and the length is 20 bytes.
[ 33.732033] : 40 04 03 02 01 00 00 00 00 27 76 d3 2d 1b 79
a0 @'v.-.y.
[ 33.732065] 0010: 18 38 fb a6 .8..
Byte 0: MHDR field, value is 0x40.
Byte 1 ~ 4: DevAddr field, value is 0x04 0x03 0x02 0x01.
Byte 5: FCtrl field, value is 0x00.
Byte 6 ~ 7: FCnt field, value is 0x00 0x00.
Byte 8: FPort field, value is 0x00.
Byte 9 ~ 15: Encrypted payload
Byte 16 ~ 19: MIC field value is 0x18 0x38 0xfb 0xa6.
> > +void
> > +lrw_parse_frame(struct lrw_session *ss, struct sk_buff *skb)
> > +{
> > + struct lrw_fhdr *fhdr = &ss->rx_fhdr;
> > + __le16 *p_fcnt;
> > +
> > + pr_debug("%s: %s\n", LORAWAN_MODULE_NAME, __func__);
> > +
> > + /* Get message type */
> > + fhdr->mtype = skb->data[0];
> > + skb_pull(skb, LRW_MHDR_LEN);
print_hex_dump skb here:
[ 33.732202] : 04 03 02 01 00 00 00 00 27 76 d3 2d 1b 79 a0
18 'v.-.y..
[ 33.732204] 0010: 38 fb a6
> This does not seem robust. There is no point at which you actually check
> the message size is valid etc
Thanks! It is a potential bug.
It should check skb->len >= length of MHDR + DevAddr + FCtrl + FCnt + MIC.
These are required fields for (Un)confirmed Data Up/Down messages.
print_hex_dump skb here:
[ 33.732211] : 00 27 76 d3 2d 1b 79 a0 18 38 fb a6
.'v.-.y..8..
> > + fhdr->fopts_len = fhdr->fctrl & 0xF;
> > + if (fhdr->fopts_len > 0) {
> > + memcpy(fhdr->fopts, skb->data, fhdr->fopts_len);
> > + skb_pull(skb, fhdr->fopts_len);
> > + }
print_hex_dump skb here:
[ 33.732213] : 00 27 76 d3 2d 1b 79 a0 18 38 fb a6
.'v.-.y..8..
> In fact you appear to copy random kernel memory into a buffer
It copied fhdr->fopts_len bytes from skb->data to fhdr->fopts if
fhdr->fopts_len > 0.
https://www.kernel.org/doc/html/latest/core-api/kernel-api.html?highlight=memcpy#c.memcpy
> > +
> > + /* TODO: Parse frame options */
> > +
> > + /* Remove message integrity code */
> > + skb_trim(skb, skb->len - LRW_MIC_LEN);
print_hex_dump skb here:
[ 33.732216] : 00 27 76 d3 2d 1b 79 a0
.'v.-.y.
> and then try and trim the buffer to a negative size ?
It removed 4 tail bytes (MIC). (skb->len - LRW_MIC_LEN) is the final
new length as skb_trim()'s 2nd argument len.
https://www.kernel.org/doc/html/latest/networking/kapi.html?highlight=skb_trim#c.skb_trim
I found another bug which did not initialize rx_skb_list. So,
lrw_parse_frame() may be passed a mystery skb.
Please keep reviewing. That is appreciated.
Thank you,
Jian-Hong Pan
[PATCH V4 5/6] net: maclorawan: Implement maclorawan class module
LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices.
This patch implements part of Class A end-devices SoftMAC defined in
LoRaWAN(TM) Specification Ver. 1.0.2:
1. End-device receive slot timing
2. Only single channel and single data rate for now
3. Unconfirmed data up/down message types
On the other side, it defines the basic interface and operation
functions for compatible LoRa device drivers.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Modify for Big/Little-Endian
- Use SPDX license identifiers
V3:
- Remove the decoration word - inline of the functions
- Order local variables from longest to shortest line in the functions
- Change the calling mac_cb function to lrw_get_mac_cb macro
V4:
- Fix the delay period between RX window#1 and window#2
- Fix by coding style report from scripts/checkpatch.pl
net/maclorawan/Kconfig | 14 +
net/maclorawan/Makefile | 2 +
net/maclorawan/mac.c| 518 ++
net/maclorawan/main.c | 605
4 files changed, 1139 insertions(+)
create mode 100644 net/maclorawan/Kconfig
create mode 100644 net/maclorawan/Makefile
create mode 100644 net/maclorawan/mac.c
create mode 100644 net/maclorawan/main.c
diff --git a/net/maclorawan/Kconfig b/net/maclorawan/Kconfig
new file mode 100644
index ..d700314edf26
--- /dev/null
+++ b/net/maclorawan/Kconfig
@@ -0,0 +1,14 @@
+config MACLORAWAN
+ tristate "Generic LoRaWAN Soft Networking Stack (maclorawan)"
+ depends on LORAWAN
+ select CRYPTO
+ select CRYPTO_CMAC
+ select CRYPTO_CBC
+ select CRYPTO_AES
+ help
+ This option enables the hardware independent LoRaWAN
+ networking stack for SoftMAC devices (the ones implementing
+ only PHY level of LoRa standard).
+
+ If you plan to use HardMAC LoRaWAN devices, you can say N
+ here. Alternatively you can say M to compile it as a module.
diff --git a/net/maclorawan/Makefile b/net/maclorawan/Makefile
new file mode 100644
index ..562831e66c82
--- /dev/null
+++ b/net/maclorawan/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_MACLORAWAN) += maclorawan.o
+maclorawan-objs:= main.o mac.o crypto.o
diff --git a/net/maclorawan/mac.c b/net/maclorawan/mac.c
new file mode 100644
index ..70e6923bf63e
--- /dev/null
+++ b/net/maclorawan/mac.c
@@ -0,0 +1,518 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*-
+ * LoRaWAN soft MAC
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "maclorawan.h"
+#include "crypto.h"
+
+static void rx_timeout_work(struct work_struct *work);
+
+struct lrw_session *
+lrw_alloc_ss(struct lrw_struct *lrw_st)
+{
+ struct lrw_session *ss;
+
+ ss = kzalloc(sizeof(*ss), GFP_KERNEL);
+ if (!ss)
+ goto lrw_alloc_ss_end;
+
+ ss->lrw_st = lrw_st;
+ ss->devaddr = lrw_st->devaddr;
+ INIT_LIST_HEAD(&ss->entry);
+
+ ss->tx_should_ack = false;
+ ss->retry = 3;
+ spin_lock_init(&ss->state_lock);
+ INIT_WORK(&ss->timeout_work, rx_timeout_work);
+
+lrw_alloc_ss_end:
+ return ss;
+}
+
+void
+lrw_free_ss(struct lrw_session *ss)
+{
+ netdev_dbg(ss->lrw_st->ndev, "%s\n", __func__);
+ if (ss->tx_skb)
+ consume_skb(ss->tx_skb);
+ netdev_dbg(ss->lrw_st->ndev, "%s: free rx skb\n", __func__);
+ if (ss->rx_skb)
+ consume_skb(ss->rx_skb);
+
+ netdev_dbg(ss->lrw_st->ndev, "%s: free ss\n", __func__);
+ kfree(ss);
+}
+
+void
+lrw_del_ss(struct lrw_session *ss)
+{
+ netdev_dbg(ss->lrw_st->ndev, "%s\n", __func__);
+ list_del(&ss->entry);
+ lrw_free_ss(ss);
+}
+
+void
+lrw_del_all_ss(struct lrw_struct *lrw_st)
+{
+ struct lrw_session *ss, *tmp;
+
+ mutex_lock(&lrw_st->ss_list_lock);
+ lrw_st->_cur_ss = NULL;
+ list_for_each_entry_safe(ss, tmp, &lrw_st->ss_list, entry) {
+ del_timer(&ss->timer);
+ lrw_del_ss(ss);
+ }
+ mutex_unlock(&lrw_st->ss_list_lock);
+}
+
+void
+lrw_ready_hw(struct lrw_struct *lrw_st)
+{
+ lrw_st->state = LRW_STATE_IDLE;
+}
+
+int
+lrw_start_hw(struct lrw_struct *lrw_st)
+{
+ int ret = 0;
+
+ netdev_dbg(lrw_st->ndev, "%s\n", __func__);
+ lrw_st->nwks_shash_tfm = lrw_mic_key_setup(lrw_st->nwkskey,
+ LRW_KEY_LEN);
+ lrw_st->nwks_skc_tfm = lrw_encrypt_key_setup(lrw_st->nwkskey,
+
[PATCH V4 3/6] net: maclorawan: Add maclorawan module declaration
Add the maclorawan header file for common APIs in the module.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Use SPDX license identifiers
V4:
- Fix typo in comments
- Fix by coding style report from scripts/checkpatch.pl
net/maclorawan/maclorawan.h | 200
1 file changed, 200 insertions(+)
create mode 100644 net/maclorawan/maclorawan.h
diff --git a/net/maclorawan/maclorawan.h b/net/maclorawan/maclorawan.h
new file mode 100644
index ..572c26c7cf40
--- /dev/null
+++ b/net/maclorawan/maclorawan.h
@@ -0,0 +1,200 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*-
+ * LoRaWAN soft MAC
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#ifndef __MAC_LORAWAN_H__
+#define __MAC_LORAWAN_H__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#defineLORAWAN_MODULE_NAME "maclorawan"
+
+/* List the message types of LoRaWAN */
+enum {
+ LRW_JOIN_REQUEST,
+ LRW_JOIN_ACCEPT,
+ LRW_UNCONFIRMED_DATA_UP,
+ LRW_UNCONFIRMED_DATA_DOWN,
+ LRW_CONFIRMED_DATA_UP,
+ LRW_CONFIRMED_DATA_DOWN,
+ LRW_RFU,
+ LRW_PROPRIETARY,
+};
+
+/* List the communication directions */
+enum {
+ LRW_UPLINK,
+ LRW_DOWNLINK,
+};
+
+/* States of LoRaWAN slot timing */
+enum {
+ LRW_INIT_SS,
+ LRW_XMITTING_SS,
+ LRW_XMITTED,
+ LRW_RX1_SS,
+ LRW_RX2_SS,
+ LRW_RXTIMEOUT_SS,
+ LRW_RXRECEIVED_SS,
+ LRW_RETRANSMIT_SS,
+};
+
+#defineLRW_MHDR_LEN1
+#defineLRW_FHDR_MAX_LEN22
+#defineLRW_FOPS_MAX_LEN15
+#defineLRW_FPORT_LEN 1
+#defineLRW_MIC_LEN 4
+
+/**
+ * lrw_fhdr - Hold the message's basic information of the frame
+ *
+ * @mtype: this message's type
+ * @fctrl: the frame control byte
+ * @fcnt: this message's frame counter value
+ * @fopts: this frame's options field
+ * @fopts_len: the length of the fopts
+ */
+struct lrw_fhdr {
+ u8 mtype;
+ u8 fctrl;
+ u16 fcnt;
+ u8 fopts[LRW_FPORT_LEN];
+ u8 fopts_len;
+};
+
+/**
+ * lrw_session - LoRaWAN session for Class A end device
+ *
+ * @lrw_st:points to the belonging lrw_st
+ * @entry: the entry of the ss_list in lrw_struct
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ * @fcnt_up: uplink frame counter
+ * @fcnt_down: downlink frame counter
+ * @fport: the LoRaWAN data message's port field
+ * @tx_skb:points to the TX skb, the frame
+ * @rx_skb:points to the RX skb, the frame
+ * @tx_fhdr: hold the message's basic information of the TX frame
+ * @rx_fhdr: hold the message's basic information of the RX frame
+ * @tx_should_ack: flag for determining the TX which should be acked or not
+ * @retry: retry times for xmitting failed
+ * @state: this session's current state
+ * @state_lock:lock of the session's state
+ * @timer: timing for this session and the state transition
+ * @timeout_work: work if waiting acknowledge time out
+ * @rx_delay1: RX1 delay time in seconds
+ * @rx_delay2: RX2 delay time in seconds
+ * @rx1_window:RX1 window opening time in milliseconds
+ * @rx2_window:RX2 window opening time in milliseconds
+ * @ack_timeout: time out time for waiting acknowledge in seconds
+ */
+struct lrw_session {
+ struct lrw_struct *lrw_st;
+ struct list_head entry;
+
+ u32 devaddr;
+ u16 fcnt_up;
+ u16 fcnt_down;
+ u8 fport;
+ struct sk_buff *tx_skb;
+ struct sk_buff *rx_skb;
+ struct lrw_fhdr tx_fhdr;
+ struct lrw_fhdr rx_fhdr;
+
+ u8 tx_should_ack;
+ u8 retry;
+ u8 state;
+ spinlock_t state_lock; /* lock of the session's state */
+
+ struct timer_list timer;
+ struct work_struct timeout_work;
+ unsigned long rx_delay1;
+ unsigned long rx_delay2;
+ unsigned long rx1_window;
+ unsigned long rx2_window;
+ unsigned long ack_timeout;
+};
+
+/**
+ * lrw_struct - The full LoRaWAN hardware to the LoRa device.
+ *
+ * @dev: this LoRa device registed in system
+ * @hw:the LoRa device of this LoRaWAN hardware
+ * @ops: handle of LoRa operations interfaces
+ * @rx_skb_list: the list of received frames
+ * @ss_list: LoRaWAN session list of this LoRaWAN hardware
+ * @ss_list_lock: lock of the session list
+ * @_cur_ss: pointer of the current processing session
+ * @rx_should_ack: represent the current session
Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009
Hi,
Just gently ping.
May this patch be reviewed and merged?
Thanks,
Jian-Hong Pan
2018-05-25 17:54 GMT+08:00 Jian-Hong Pan :
> Without this patch we cannot turn on the Bluethooth adapter on HP
> 14-bs007la.
>
> T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0bda ProdID=b009 Rev= 2.00
> S: Manufacturer=Realtek
> S: Product=802.11n WLAN Adapter
> S: SerialNumber=00e04c01
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Jian-Hong Pan
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3a477b6b3ce6..d93b25faeed9 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -374,6 +374,7 @@ static const struct usb_device_id blacklist_table[] = {
> { USB_DEVICE(0x7392, 0xa611), .driver_info = BTUSB_REALTEK },
>
> /* Additional Realtek 8723DE Bluetooth devices */
> + { USB_DEVICE(0x0bda, 0xb009), .driver_info = BTUSB_REALTEK },
> { USB_DEVICE(0x2ff8, 0xb011), .driver_info = BTUSB_REALTEK },
>
> /* Additional Realtek 8821AE Bluetooth devices */
> --
> 2.11.0
>
[PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009
Without this patch we cannot turn on the Bluethooth adapter on HP
14-bs007la.
T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=b009 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Jian-Hong Pan
---
drivers/bluetooth/btusb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3a477b6b3ce6..d93b25faeed9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -374,6 +374,7 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x7392, 0xa611), .driver_info = BTUSB_REALTEK },
/* Additional Realtek 8723DE Bluetooth devices */
+ { USB_DEVICE(0x0bda, 0xb009), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x2ff8, 0xb011), .driver_info = BTUSB_REALTEK },
/* Additional Realtek 8821AE Bluetooth devices */
--
2.11.0
Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009
Hi Daniel, 2018-05-25 21:25 GMT+08:00 Daniel Drake : > Hi Jian-Hong, > > On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: >> >> Without this patch we cannot turn on the Bluethooth adapter on HP >> 14-bs007la. > > Please correct me if I'm wrong, but it looks like we are still waiting > for the testing of this patch from our colleagues in Guatemala. > > There are unlikely to be any issues with such a trivial change, but we > should probably wait for confirmation that it works before having it > included upstream. Oh, sure! That will be better. Thanks for your reminder. Thanks, Jian-Hong Pan > Thanks > Daniel
Re: [RFC] net: Add new LoRaWAN subsystem
Hi Jiri and Marcel, 2018-05-11 23:39 GMT+08:00 Marcel Holtmann : > Hi Jian-Hong, > >> A Low-Power Wide-Area Network (LPWAN) is a type of wireless >> telecommunication wide area network designed to allow long range >> communications at a low bit rate among things (connected objects), such >> as sensors operated on a battery. It can be used widely in IoT area. >> LoRaWAN, which is one kind of implementation of LPWAN, is a medium >> access control (MAC) layer protocol for managing communication between >> LPWAN gateways and end-node devices, maintained by the LoRa Alliance. >> LoRaWAN™ Specification could be downloaded at: >> https://lora-alliance.org/lorawan-for-developers >> >> However, LoRaWAN is not implemented in Linux kernel right now, so I am >> trying to develop it. Here is my repository: >> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN >> >> Because it is a kind of network, the ideal usage in an user space >> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with >> other socket APIs. Therefore, the definitions like AF_LORAWAN, >> PF_LORAWAN ..., must be listed in the header files of glibc. >> For the driver in kernel space, the definitions also must be listed in >> the corresponding Linux socket header files. >> Especially, both are for the testing programs. >> >> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". >> Could or should we add the definitions into corresponding kernel header >> files now, if LoRaWAN will be accepted as a subsystem in Linux? > > when you submit your LoRaWAN subsystem to netdev for review, include a patch > that adds these new address family definitions. Just pick the next one > available. There will be no pre-allocation of numbers until your work has > been accepted upstream. Meaning, that the number might change if other > address families get merged before yours. So you have to keep updating. glibc > will eventually follow the number assigned by the kernel. Thanks for your guidance. I will follow the steps. Thanks a lot, Jian-Hong Pan > Regards > > Marcel >
[RFC PATCH] net: Remove a confusing comment of macro SIOCDEVPRIVATE
I have been reading the NET related header files recently. I found there is a macro "#define SIOCDEVPRIVATE 0x89F0" defined in include/uapi/linux/sockios.h which is useful for private controls of net devices. When I read this section: /* Device private ioctl calls */ /* * These 16 ioctls are available to devices via the do_ioctl() device * vector. Each device should include this file and redefine these names * as their own. Because these are device dependent it is a good idea * _NOT_ to issue them to random objects and hope. * * THESE IOCTLS ARE _DEPRECATED_ AND WILL DISAPPEAR IN 2.5.X -DaveM */ I notice there is a string in the comment: "THESE IOCTLS ARE _DEPRECATED_ AND WILL DISAPPEAR IN 2.5.X -DaveM" which makes me confused. Because, there are still a lot of devices or subsystems using this macro, for example, ethernet, appletalk, usb/rtl8150 ..., etc. Therefore, I make this patch to remove the confusing comment. Signed-off-by: Jian-Hong Pan --- include/uapi/linux/sockios.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/uapi/linux/sockios.h b/include/uapi/linux/sockios.h index d393e9ed3964..c166f8c6b20f 100644 --- a/include/uapi/linux/sockios.h +++ b/include/uapi/linux/sockios.h @@ -139,8 +139,6 @@ * vector. Each device should include this file and redefine these names * as their own. Because these are device dependent it is a good idea * _NOT_ to issue them to random objects and hope. - * - * THESE IOCTLS ARE _DEPRECATED_ AND WILL DISAPPEAR IN 2.5.X -DaveM */ #define SIOCDEVPRIVATE 0x89F0 /* to 89FF */ -- 2.17.0
[RFC PATCH] platform/x86: asus-wmi: Simplify the keyboard brightness updating process
The original asus-wmi queues a work which calls the ACPI/WMI methods to
update the keyboard LED brightness. Similar drivers - acer-wmi,
dell-wmi-led just call the ACPI/WMI methods directly without workqueues.
This patch simplifies the keyboard brightness updating process which
calls the kbd_led_update function directly without workqueue in
asus-wmi.
Signed-off-by: Jian-Hong Pan
---
drivers/platform/x86/asus-wmi.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 34dcc1aac4ea..d3d500851a7a 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -239,7 +239,6 @@ struct asus_wmi {
int lightbar_led_wk;
struct workqueue_struct *led_workqueue;
struct work_struct tpd_led_work;
- struct work_struct kbd_led_work;
struct work_struct wlan_led_work;
struct work_struct lightbar_led_work;
@@ -456,12 +455,9 @@ static enum led_brightness tpd_led_get(struct led_classdev
*led_cdev)
return read_tpd_led_state(asus);
}
-static void kbd_led_update(struct work_struct *work)
+static void kbd_led_update(struct asus_wmi *asus)
{
int ctrl_param = 0;
- struct asus_wmi *asus;
-
- asus = container_of(work, struct asus_wmi, kbd_led_work);
/*
* bits 0-2: level
@@ -516,7 +512,7 @@ static void do_kbd_led_set(struct led_classdev *led_cdev,
int value)
value = 0;
asus->kbd_led_wk = value;
- queue_work(asus->led_workqueue, &asus->kbd_led_work);
+ kbd_led_update(asus);
}
static void kbd_led_set(struct led_classdev *led_cdev,
@@ -671,8 +667,6 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
led_val = kbd_led_read(asus, NULL, NULL);
if (led_val >= 0) {
- INIT_WORK(&asus->kbd_led_work, kbd_led_update);
-
asus->kbd_led_wk = led_val;
asus->kbd_led.name = "asus::kbd_backlight";
asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
@@ -2314,7 +2308,7 @@ static int asus_hotk_resume(struct device *device)
struct asus_wmi *asus = dev_get_drvdata(device);
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
- queue_work(asus->led_workqueue, &asus->kbd_led_work);
+ kbd_led_update(asus);
return 0;
}
@@ -2350,7 +2344,7 @@ static int asus_hotk_restore(struct device *device)
rfkill_set_sw_state(asus->uwb.rfkill, bl);
}
if (!IS_ERR_OR_NULL(asus->kbd_led.dev))
- queue_work(asus->led_workqueue, &asus->kbd_led_work);
+ kbd_led_update(asus);
return 0;
}
--
2.11.0
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices. > > > >This patch implements part of Class A end-devices SoftMAC defined in > >LoRaWAN(TM) Specification Ver. 1.0.2: > >1. End-device receive slot timing > >2. Only single channel and single data rate for now > >3. Unconfirmed data up/down message types > > > >On the other side, it defines the basic interface and operation > >functions for compatible LoRa device drivers. > > > >Signed-off-by: Jian-Hong Pan > >--- > >V2: > >- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and > > LoRaWAN Soft MAC modules > >- Modify for Big/Little-Endian > >- Use SPDX license identifiers > > > >V3: > >- Remove the decoration word - inline of the functions > >- Order local variables from longest to shortest line in the functions > >- Change the calling mac_cb function to lrw_get_mac_cb macro > > > >V4: > >- Fix the delay period between RX window#1 and window#2 > >- Fix by coding style report from scripts/checkpatch.pl > > > >V5: > >- Initial rx_skb_list when it is allocated with LoRa hardware > >- Check the sk_buff's data length before access it > >- Deal FPort field and decrypt payload in lrw_parse_frame function > >- Drop the recieved frame if parse failed > >- Fix the bug which passes wrong skb properties from maclorawan to lorawan > >module > > > > net/maclorawan/Kconfig | 14 + > > net/maclorawan/Makefile | 2 + > > net/maclorawan/mac.c| 555 > > net/maclorawan/main.c | 606 > > 4 files changed, 1177 insertions(+) > > create mode 100644 net/maclorawan/Kconfig > > create mode 100644 net/maclorawan/Makefile > > create mode 100644 net/maclorawan/mac.c > > create mode 100644 net/maclorawan/main.c > > > I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > you add headers for "API" and here you implement functions. That is just > weird. Does it mean you can have other implementations? LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. This part is soft-MAC as Andreas mentioned http://lists.infradead.org/pipermail/linux-lpwan/2018-December/10.html > Also, you don't really have any user of this API in the set. Please > introduce at least 1 driver, preferably more (I see that Andreas has > multiple ones in his patchset). You cannot push kernel infrastructure > without kernel user. The soft-MAC is suitable for the LoRa chips' device drivers, like sx1276/77/78/79, RFM95/96/97/98W ... Still waiting for Andreas' sx1276 version 2 patch and more discussion. For example, how to make PF_LORA and PF_LORAWAN like Ethernet, PF_INET and PF_INET6 don't need separate devices either, both use eth0. https://lkml.org/lkml/2018/8/3/266 Jian-Hong Pan
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> Tue, Dec 18, 2018 at 03:27:09PM CET, starni...@g.ncu.edu.tw wrote: > >> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > >> >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices. > >> > > >> >This patch implements part of Class A end-devices SoftMAC defined in > >> >LoRaWAN(TM) Specification Ver. 1.0.2: > >> >1. End-device receive slot timing > >> >2. Only single channel and single data rate for now > >> >3. Unconfirmed data up/down message types > >> > > >> >On the other side, it defines the basic interface and operation > >> >functions for compatible LoRa device drivers. > >> > > >> >Signed-off-by: Jian-Hong Pan > >> >--- > >> >V2: > >> >- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and > >> > LoRaWAN Soft MAC modules > >> >- Modify for Big/Little-Endian > >> >- Use SPDX license identifiers > >> > > >> >V3: > >> >- Remove the decoration word - inline of the functions > >> >- Order local variables from longest to shortest line in the functions > >> >- Change the calling mac_cb function to lrw_get_mac_cb macro > >> > > >> >V4: > >> >- Fix the delay period between RX window#1 and window#2 > >> >- Fix by coding style report from scripts/checkpatch.pl > >> > > >> >V5: > >> >- Initial rx_skb_list when it is allocated with LoRa hardware > >> >- Check the sk_buff's data length before access it > >> >- Deal FPort field and decrypt payload in lrw_parse_frame function > >> >- Drop the recieved frame if parse failed > >> >- Fix the bug which passes wrong skb properties from maclorawan to > >> >lorawan module > >> > > >> > net/maclorawan/Kconfig | 14 + > >> > net/maclorawan/Makefile | 2 + > >> > net/maclorawan/mac.c| 555 > >> > net/maclorawan/main.c | 606 > >> > 4 files changed, 1177 insertions(+) > >> > create mode 100644 net/maclorawan/Kconfig > >> > create mode 100644 net/maclorawan/Makefile > >> > create mode 100644 net/maclorawan/mac.c > >> > create mode 100644 net/maclorawan/main.c > >> > >> > >> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > >> you add headers for "API" and here you implement functions. That is just > >> weird. Does it mean you can have other implementations? > > > >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. > >This part is soft-MAC as Andreas mentioned > >http://lists.infradead.org/pipermail/linux-lpwan/2018-December/10.html > > Okay, that does not answer my concern about header file in one patch and > the actual implementation of functions in another one. Just for clarification: - Patch "net: lorawan: Add LoRaWAN socket module" is for lorawan module - Patch "net: lorawan: Add LoRaWAN API declaration for LoRa devices" containes the header file "include/linux/lora/lorawan.h" which will be included by LoRa device drivers or other kernel modules. - Patches "net: maclorawan: Add maclorawan module declaration", "net: maclorawan: Implement the crypto of maclorawan module" and "net: maclorawan: Implement maclorawan class module" are for maclorawan module. Question 1: Should I marge "net: maclorawan: Add maclorawan module declaration", "net: maclorawan: Implement the crypto of maclorawan module" and "net: maclorawan: Implement maclorawan class module" into a single patch named "net: maclorawan: Add maclorawan as the soft-MAC module"? Then: For example, after a LoRa device driver includes the header "linux/lora/lorawan.h", the device driver will call "lrw_alloc_hw()" and pass with a "struct lrw_operations" type of variable's pointer. It gets a type of "struct lrw_hw *" pointer. Then, it will call "lrw_register_hw()" to register the device. The device driver implements the callback functions for the "struct lrw_operations" type of variable by it self before calls "lrw_alloc_hw()". Question 2: Should the patch "net: lorawan: Add LoRaWAN API declaration for LoRa devices" also be merged into "net: maclorawan: Add maclorawan as the soft-MAC module" or "net: maclorawan: Implement maclorawan class module"? Or, just leave it as a single patch?
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> > Am 18.12.18 um 15:27 schrieb Jian-Hong Pan: > > >> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > > >>> LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa > > devices. > > >>> > > >>> This patch implements part of Class A end-devices SoftMAC defined in > > >>> LoRaWAN(TM) Specification Ver. 1.0.2: > > >>> 1. End-device receive slot timing > > >>> 2. Only single channel and single data rate for now > > >>> 3. Unconfirmed data up/down message types > > >>> > > >>> On the other side, it defines the basic interface and operation > > >>> functions for compatible LoRa device drivers. > > >>> > > >>> Signed-off-by: Jian-Hong Pan > > [...] > > >>> net/maclorawan/Kconfig | 14 + > > >>> net/maclorawan/Makefile | 2 + > > >>> net/maclorawan/mac.c| 555 > > > > >>> net/maclorawan/main.c | 606 > > > > >>> 4 files changed, 1177 insertions(+) > > >>> create mode 100644 net/maclorawan/Kconfig > > >>> create mode 100644 net/maclorawan/Makefile > > >>> create mode 100644 net/maclorawan/mac.c > > >>> create mode 100644 net/maclorawan/main.c > > >> > > >> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > > >> you add headers for "API" and here you implement functions. That is just > > >> weird. Does it mean you can have other implementations? > > > > > > LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. > > > This part is soft-MAC as Andreas mentioned > > > http://lists.infradead.org/pipermail/linux-lpwan/2018- > > December/10.html > > > > > >> Also, you don't really have any user of this API in the set. Please > > >> introduce at least 1 driver, preferably more (I see that Andreas has > > >> multiple ones in his patchset). You cannot push kernel infrastructure > > >> without kernel user. > > > > > > The soft-MAC is suitable for the LoRa chips' device drivers, like > > > sx1276/77/78/79, RFM95/96/97/98W ... > > > Still waiting for Andreas' sx1276 version 2 patch and more discussion. > > > > sx1276 regmap conversion was pushed to my staging tree together with > > Ben's sx1301 final conversion last night, lightly tested. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux- > > lora.git/log/?h=lora-next > > > > TBD: rename to sx127x, implement regmap fields, only auto-detect reset > > when no OF node available (all low priority atm, patches welcome) > > > > (and for sx1301 I still need to update my DT overlays with the new clk) > > > > > For example, how to make PF_LORA and PF_LORAWAN like Ethernet, > > PF_INET > > > and PF_INET6 don't need separate devices either, both use eth0. > > > https://lkml.org/lkml/2018/8/3/266 > > > > Jiri, I am expecting the maclorawan driver to lower packets from > > ETH_P_LORAWAN to ETH_P_LORA in a generic way, so that any of the LoRa > > device drivers can benefit of it, with maclorawan using the LoRa netlink > > commands that the individual drivers implement. > > Not sure what if anything is missing for that in the current revision? > > Still dealing with the lower-level infrastructure and my test setup ... > > progressing slowly. > > > > I'll probably need to queue the remaining generic LoRaWAN part 1/6 in my > > tree to resolve this circular dependency between Jian-Hong and me, so > > that only the soft-MAC implementation remains a separate patch series. > > The hard-MAC implementations will be on my plate mostly, as both SX1276 > > and SX1301 need the soft-MAC. > > On the SX1301 side of things, the ability to send messages as a LoRaWAN > node device is a niche use case, the majority if not all people will use the > concentrator card as the pass through gateway to the node. > > In this mode of operation the parameters for transmission such as; frequency, > spreading factor / data rate, power, are given by a remote server and passed > in from the userspace application which received it. > Eventually in the kernel these need to be checked locally to ensure regulatory > compliance. > To that end I have experimented with framing, as CAN does, so that this > metadata can be provided on a write from userspac
[PATCH v5 1/6] net: lorawan: Add LoRaWAN socket module
This patch adds a new address/protocol family for LoRaWAN network.
It also implements the the functions and maps to Datagram socket for
LoRaWAN unconfirmed data messages.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Add lorawan_netdev.h header file for network address related
declaration
- Use SPDX license identifiers
V3:
- Change the inline functions to a single line macro or just remove the
decoration word - inline
- Order local variables from longest to shortest line in the functions
- Change mac_cb inline function to lrw_get_mac_cb macro
V4:
- Change lrw_get_mac_cb macro to an inline function
- Use pr_fmt() instead of defining new printing log macros
- Fix by coding style report from scripts/checkpatch.pl
V5:
- Fix the device address comparing bug which is caused by endianness
include/linux/lora/lorawan_netdev.h | 52 +++
net/lorawan/Kconfig | 10 +
net/lorawan/Makefile| 2 +
net/lorawan/socket.c| 686
4 files changed, 750 insertions(+)
create mode 100644 include/linux/lora/lorawan_netdev.h
create mode 100644 net/lorawan/Kconfig
create mode 100644 net/lorawan/Makefile
create mode 100644 net/lorawan/socket.c
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
new file mode 100644
index ..5bffb5164f95
--- /dev/null
+++ b/include/linux/lora/lorawan_netdev.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*-
+ * LoRaWAN stack related definitions
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#ifndef __LORAWAN_NET_DEVICE_H__
+#define __LORAWAN_NET_DEVICE_H__
+
+enum {
+ LRW_ADDR_APPEUI,
+ LRW_ADDR_DEVEUI,
+ LRW_ADDR_DEVADDR,
+};
+
+struct lrw_addr_in {
+ int addr_type;
+ union {
+ u64 app_eui;
+ u64 dev_eui;
+ u32 devaddr;
+ };
+};
+
+struct sockaddr_lorawan {
+ sa_family_t family; /* AF_LORAWAN */
+ struct lrw_addr_in addr_in;
+};
+
+/**
+ * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
+ *
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ */
+struct lrw_mac_cb {
+ u32 devaddr;
+};
+
+/**
+ * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
+ * @skb: the exchanging sk_buff
+ *
+ * Return: the pointer of LoRaWAN MAC control buffer
+ */
+static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
+{
+ return (struct lrw_mac_cb *)skb->cb;
+}
+
+#endif
diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig
new file mode 100644
index ..bf6c9b77573b
--- /dev/null
+++ b/net/lorawan/Kconfig
@@ -0,0 +1,10 @@
+config LORAWAN
+ tristate "LoRaWAN Network support"
+ help
+ LoRaWAN defines low data rate, low power and long range wireless
+ wide area networks. It was designed to organize networks of automation
+ devices, such as sensors, switches and actuators. It can operate
+ multiple kilometers wide.
+
+ Say Y here to compile LoRaWAN support into the kernel or say M to
+ compile it as a module.
diff --git a/net/lorawan/Makefile b/net/lorawan/Makefile
new file mode 100644
index ..8c923ca6541a
--- /dev/null
+++ b/net/lorawan/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_LORAWAN) += lorawan.o
+lorawan-objs := socket.o
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
new file mode 100644
index ..7ef106b877ca
--- /dev/null
+++ b/net/lorawan/socket.c
@@ -0,0 +1,686 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*-
+ * LoRaWAN stack related definitions
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#defineLORAWAN_MODULE_NAME "lorawan"
+
+#definepr_fmt(fmt) LORAWAN_MODULE_NAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include /* For TIOCOUTQ/INQ */
+#include
+#include
+
+/**
+ * dgram_sock - This structure holds the states of Datagram socket
+ *
+ * @sk:network layer representation of the socket
+ * sk must be the first member of dgram_sock
+ * @src_devaddr: the LoRaWAN device address for this connection
+ * @bound: this socket is bound or not
+ * @connected: this socket is connected to the destination or not
+ * @want_ack: this socket needs to ack for the connection or not
+ */
+struct dgram_sock {
+ struct sock sk;
+ u32 src_devaddr;
+
+ u8 bound:1;
+ u8 connected:1;
+};
+
+static HLIST_HEAD(dgram_head);
+static DEFINE_RWLOCK(dgram_lock);
+
+static struct dgram_sock *
+dgram_sk(const struct sock *sk)
+{
+ return container_of(sk, struct dgram_sock, sk);
+}
+
+static struct net_device *
+lrw_get_dev_by_addr(struct net *ne
[PATCH v5 2/6] net: lorawan: Add LoRaWAN API declaration for LoRa devices
Add public LoRaWAN API for compatible LoRa device drivers.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Merge the lrw_operations: set_bw, set_mod, set_sf into set_dr
- Use SPDX license identifiers
V3:
- Remove the unused lrw_random_addr function
V4:
- Fix by coding style report from scripts/checkpatch.pl
include/linux/lora/lorawan.h | 131 +++
1 file changed, 131 insertions(+)
create mode 100644 include/linux/lora/lorawan.h
diff --git a/include/linux/lora/lorawan.h b/include/linux/lora/lorawan.h
new file mode 100644
index ..201f27521655
--- /dev/null
+++ b/include/linux/lora/lorawan.h
@@ -0,0 +1,131 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*-
+ * LoRaWAN compatible hardware's definitions
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#ifndef __LORAWAN_H__
+#define __LORAWAN_H__
+
+#include
+
+/* List the role of the LoRaWAN hardware */
+enum {
+ LRW_GATEWAY,
+ LRW_CLASS_A_NODE,
+ LRW_CLASS_B_NODE,
+ LRW_CLASS_C_NODE,
+};
+
+/* List the RF modes */
+enum {
+ LRW_LORA,
+ LRW_FSK,
+};
+
+/**
+ * lrw_dr - This structure holds the RF related configuration of the data rate.
+ * @bw:
+ * Bandwidth in Hz
+ *
+ * @sf:
+ * Spread factor of CSS modulation used by LoRa mode
+ *
+ * @mode:
+ * LoRa or FSK mode
+ */
+struct lrw_dr {
+ u32 bw;
+ u8 sf;
+ u8 mode;
+};
+
+#defineLRW_DEVADDR_LEN (sizeof(__le32))
+
+/* List the LoRa device's states of LoRaWAN hardware */
+enum {
+ LRW_STOP,
+ LRW_START,
+ LRW_STATE_IDLE,
+ LRW_STATE_TX,
+ LRW_STATE_RX,
+};
+
+/**
+ * lrw_hw - This structure holds the LoRa device of LoRaWAN hardware.
+ * @priv:
+ * points to the private data of the LoRa device
+ */
+struct lrw_hw {
+ void *priv;
+};
+
+/**
+ * lrw_operations - Lists the LoRaWAN device/interface's operations.
+ * These are callback functions for the LoRaWAN module. Compatible LoRa device
+ * driver should implement some of them according to the usage. The
+ * unimplemented callback functions must be assigned as NULL.
+ *
+ * @start:
+ * called when the interface is being up state
+ *
+ * @stop:
+ * called when the interface is being down state
+ *
+ * @xmit_async:
+ * called to xmit the data through the interface asynchronously
+ *
+ * @set_txpower:
+ * called to set xmitting RF power in mBm of the interface
+ *
+ * @set_frq:
+ * called to set carrier frequency in Hz of the interface
+ *
+ * @set_dr:
+ * called to set related RF configuration of the LoRaWAN data rate
+ *
+ * @start_rx_window:
+ * called to ask the LoRa device open a receiving window
+ *
+ * @set_state:
+ * called to set the LoRa device's working state
+ */
+struct lrw_operations {
+ int (*start)(struct lrw_hw *hw);
+ void (*stop)(struct lrw_hw *hw);
+
+ int (*xmit_async)(struct lrw_hw *hw, struct sk_buff *skb);
+ int (*set_txpower)(struct lrw_hw *hw, s32 pwr);
+ int (*set_frq)(struct lrw_hw *hw, u32 frq);
+ int (*set_dr)(struct lrw_hw *hw, struct lrw_dr *dr);
+ int (*start_rx_window)(struct lrw_hw *hw, u32 delay);
+ int (*set_state)(struct lrw_hw *hw, u8 state);
+};
+
+struct lrw_hw *lrw_alloc_hw(size_t priv_data_len, struct lrw_operations *ops);
+void lrw_free_hw(struct lrw_hw *hw);
+int lrw_register_hw(struct lrw_hw *hw);
+void lrw_unregister_hw(struct lrw_hw *hw);
+void lrw_rx_irqsave(struct lrw_hw *hw, struct sk_buff *skb);
+void lrw_xmit_complete(struct lrw_hw *hw, struct sk_buff *skb);
+
+void lrw_set_deveui(struct lrw_hw *hw, u64 eui);
+u64 lrw_get_deveui(struct lrw_hw *hw);
+void lrw_set_appeui(struct lrw_hw *hw, u64 eui);
+u64 lrw_get_appeui(struct lrw_hw *hw);
+void lrw_set_devaddr(struct lrw_hw *hw, u32 eui);
+u32 lrw_get_devaddr(struct lrw_hw *hw);
+
+enum {
+ LRW_APPKEY,
+ LRW_NWKSKEY,
+ LRW_APPSKEY,
+};
+
+#defineLRW_KEY_LEN 16
+
+int lrw_set_key(struct lrw_hw *hw, u8 type, u8 *key, size_t key_len);
+
+#endif
--
2.20.0
[PATCH v5 0/6] net: lorawan: Add LoRaWAN soft MAC module
LoRaWAN(TM) is the MAC layer defined by LoRa Alliance(TM) over LoRa devices. LoRa is one of Low-Power Wide-Area Network (LPWAN) technology. LoRaWAN networks typically are laid out in a star-of-stars topology in which gateways relay messages between end-devices and a central network server at the backend. Gateways are connected to the network server via standard IP connections while end-devices use single hop LoRa(TM) or FSK communication to one or many gateways. A LoRa network distinguishes between a basic LoRaWAN (named Class A) and optional features (Class B, Class C ...): * Bi-directional end-devices (Class A) * Bi-directional end-devices with scheduled receive slots (Class B) * Bi-directional end-devices with maximal receive slots (Class C) This patch set add LoRaWAN class module implementing the stack, especially the soft MAC, between socket APIs and LoRa device drivers. socket APIs: send and receive the data LoRaWAN class module implements soft MAC: append the header/footer, encryption/decryption, timing slot and MAC commands LoRa device drivers: send and receive the messages for MAC layer LoRa devices This module starts from simple and implements partial Class A end-devices features defined in LoRaWAN(TM) Specification Ver. 1.0.2. More features and complexity, for example regional parameters, confirmed data messages, join request/accept messages for Over-The-Air Activation, MAC commands ... will be added in the future. Jian-Hong Pan (6): net: lorawan: Add LoRaWAN socket module net: lorawan: Add LoRaWAN API declaration for LoRa devices net: maclorawan: Add maclorawan module declaration net: maclorawan: Implement the crypto of maclorawan module net: maclorawan: Implement maclorawan class module net: lorawan: List LORAWAN in menuconfig include/linux/lora/lorawan.h| 131 ++ include/linux/lora/lorawan_netdev.h | 52 +++ net/Kconfig | 2 + net/Makefile| 2 + net/lorawan/Kconfig | 10 + net/lorawan/Makefile| 2 + net/lorawan/socket.c| 686 net/maclorawan/Kconfig | 14 + net/maclorawan/Makefile | 2 + net/maclorawan/crypto.c | 212 + net/maclorawan/crypto.h | 27 ++ net/maclorawan/mac.c| 555 ++ net/maclorawan/maclorawan.h | 202 net/maclorawan/main.c | 606 14 files changed, 2503 insertions(+) create mode 100644 include/linux/lora/lorawan.h create mode 100644 include/linux/lora/lorawan_netdev.h create mode 100644 net/lorawan/Kconfig create mode 100644 net/lorawan/Makefile create mode 100644 net/lorawan/socket.c create mode 100644 net/maclorawan/Kconfig create mode 100644 net/maclorawan/Makefile create mode 100644 net/maclorawan/crypto.c create mode 100644 net/maclorawan/crypto.h create mode 100644 net/maclorawan/mac.c create mode 100644 net/maclorawan/maclorawan.h create mode 100644 net/maclorawan/main.c -- 2.20.0
[PATCH v5 4/6] net: maclorawan: Implement the crypto of maclorawan module
Implement the crypto for encryption/decryption and message integrity
code (MIC) according to LoRaWAN(TM) Specification Ver. 1.0.2.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Rename the lrwsec files to crypto files
- Modify for Big/Little-Endian
- Use SPDX license identifiers
V3:
- Order local variables from longest to shortest line in the functions
V4:
- Fix by coding style report from scripts/checkpatch.pl
net/maclorawan/crypto.c | 212
net/maclorawan/crypto.h | 27 +
2 files changed, 239 insertions(+)
create mode 100644 net/maclorawan/crypto.c
create mode 100644 net/maclorawan/crypto.h
diff --git a/net/maclorawan/crypto.c b/net/maclorawan/crypto.c
new file mode 100644
index ..0ae9d211cd14
--- /dev/null
+++ b/net/maclorawan/crypto.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*-
+ * LoRaWAN soft MAC
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#include
+#include
+#include
+#include "crypto.h"
+
+struct crypto_shash *
+lrw_mic_key_setup(u8 *k, size_t k_len)
+{
+ struct crypto_shash *tfm;
+ char *algo = "cmac(aes)";
+ int err;
+
+ tfm = crypto_alloc_shash(algo, 0, 0);
+ if (!IS_ERR(tfm)) {
+ err = crypto_shash_setkey(tfm, k, k_len);
+ if (err) {
+ crypto_free_shash(tfm);
+ tfm = NULL;
+ }
+ }
+
+ return tfm;
+}
+
+int
+lrw_aes_cmac(struct crypto_shash *tfm, u8 *bz, u8 *data, size_t len, u8 *out)
+{
+ SHASH_DESC_ON_STACK(desc, tfm);
+ int err;
+
+ desc->tfm = tfm;
+
+ err = crypto_shash_init(desc);
+ if (err)
+ goto lrw_aes_cmac_end;
+
+ err = crypto_shash_update(desc, bz, 16);
+ if (err)
+ goto lrw_aes_cmac_end;
+
+ err = crypto_shash_update(desc, data, len);
+ if (err)
+ goto lrw_aes_cmac_end;
+
+ err = crypto_shash_final(desc, out);
+
+lrw_aes_cmac_end:
+ return err;
+}
+
+int
+lrw_set_bzero(u8 dir, u32 devaddr, u32 fcnt, u8 len, u8 *bz)
+{
+ __le32 le_devaddr = cpu_to_le32(devaddr);
+ __le32 le_fcnt = cpu_to_le32(fcnt);
+
+ bz[0] = 0x49;
+ memset(bz + 1, 0x00, 4);
+ bz[5] = dir;
+ memcpy(bz + 6, &le_devaddr, 4);
+ memcpy(bz + 10, &le_fcnt, 4);
+ bz[14] = 0x00;
+ bz[15] = len;
+
+ return 0;
+}
+
+int
+lrw_calc_mic(struct crypto_shash *tfm,
+u8 dir, u32 devaddr, u32 fcnt, u8 *buf, size_t len, u8 *mic4)
+{
+ u8 mic[16];
+ u8 bz[16];
+ int err;
+
+ /* According to LoRaWAN Specification Version 1.0.2
+* - 4.4 Massege Integrity Code (MIC)
+*/
+ lrw_set_bzero(dir, devaddr, fcnt, len, bz);
+ err = lrw_aes_cmac(tfm, bz, buf, len, mic);
+ if (!err)
+ memcpy(mic4, mic, 4);
+
+ return err;
+}
+
+void
+lrw_mic_key_free(struct crypto_shash *tfm)
+{
+ crypto_free_shash(tfm);
+}
+
+struct crypto_sync_skcipher *
+lrw_aes_enc_key_setup(char *algo, u8 *k, size_t k_len)
+{
+ struct crypto_sync_skcipher *tfm;
+ int err;
+
+ tfm = crypto_alloc_sync_skcipher(algo, 0, CRYPTO_ALG_ASYNC);
+ if (!IS_ERR(tfm)) {
+ err = crypto_sync_skcipher_setkey(tfm, k, k_len);
+ if (err) {
+ crypto_free_sync_skcipher(tfm);
+ tfm = NULL;
+ }
+ }
+
+ return tfm;
+}
+
+struct crypto_sync_skcipher *
+lrw_encrypt_key_setup(u8 *k, size_t k_len)
+{
+ return lrw_aes_enc_key_setup("cbc(aes)", k, k_len);
+}
+
+int
+lrw_aes_enc(struct crypto_sync_skcipher *tfm, u8 *in, size_t len, u8 *out)
+{
+ SYNC_SKCIPHER_REQUEST_ON_STACK(req, tfm);
+ struct scatterlist src, dst;
+ u8 iv[16];
+ int err;
+
+ memset(iv, 0, 16);
+ /* The buffer for sg_init_one cannot be a global or const local
+* (will confuse the scatterlist)
+*/
+ sg_init_one(&src, in, len);
+ sg_init_one(&dst, out, len);
+
+ skcipher_request_set_sync_tfm(req, tfm);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, &src, &dst, len, iv);
+ err = crypto_skcipher_encrypt(req);
+ skcipher_request_zero(req);
+
+ return err;
+}
+
+#defineLRW_SEQUENCE_OF_BLOCK_LEN 16
+
+int
+lrw_set_sob(u8 dir, u32 devaddr, u32 fcnt, u8 index, u8 *sob)
+{
+ __le32 le_devaddr = cpu_to_le32(devaddr);
+ __le32 _fcnt = cpu_to_le32(fcnt);
+
+ sob[0] = 0x01;
+ memset(sob + 1, 0x00, 4);
+ sob[5] = dir;
+ memcpy(sob + 6, &le_devaddr, 4);
+ memcpy(sob + 10, &_fcnt, 4);
+ sob[14] = 0x00;
+ sob[15] = index;
+
+ return 0;
+}
+
+int
+lrw_encrypt
[PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
List LORAWAN and MACLORAWAN in menuconfig and make they can be built. Signed-off-by: Jian-Hong Pan --- V2: - Split the LoRaWAN class module patch in V1 into LoRaWAN socket and LoRaWAN Soft MAC modules net/Kconfig | 2 ++ net/Makefile | 2 ++ 2 files changed, 4 insertions(+) diff --git a/net/Kconfig b/net/Kconfig index cf2e651ee31d..03b3ff306778 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -224,6 +224,8 @@ source "net/6lowpan/Kconfig" source "net/ieee802154/Kconfig" source "net/mac802154/Kconfig" source "net/lora/Kconfig" +source "net/lorawan/Kconfig" +source "net/maclorawan/Kconfig" source "net/sched/Kconfig" source "net/dcb/Kconfig" source "net/dns_resolver/Kconfig" diff --git a/net/Makefile b/net/Makefile index e80b84313851..9d5515965a8f 100644 --- a/net/Makefile +++ b/net/Makefile @@ -63,6 +63,8 @@ obj-$(CONFIG_6LOWPAN) += 6lowpan/ obj-$(CONFIG_IEEE802154) += ieee802154/ obj-$(CONFIG_MAC802154)+= mac802154/ obj-$(CONFIG_LORA) += lora/ +obj-$(CONFIG_LORAWAN) += lorawan/ +obj-$(CONFIG_MACLORAWAN) += maclorawan/ ifeq ($(CONFIG_NET),y) obj-$(CONFIG_SYSCTL) += sysctl_net.o -- 2.20.0
[PATCH v5 3/6] net: maclorawan: Add maclorawan module declaration
Add the maclorawan header file for common APIs in the module.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Use SPDX license identifiers
V4:
- Fix typo in comments
- Fix by coding style report from scripts/checkpatch.pl
V5:
- Add the frame control and frame count fields' length
net/maclorawan/maclorawan.h | 202
1 file changed, 202 insertions(+)
create mode 100644 net/maclorawan/maclorawan.h
diff --git a/net/maclorawan/maclorawan.h b/net/maclorawan/maclorawan.h
new file mode 100644
index ..024c394bebca
--- /dev/null
+++ b/net/maclorawan/maclorawan.h
@@ -0,0 +1,202 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*-
+ * LoRaWAN soft MAC
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#ifndef __MAC_LORAWAN_H__
+#define __MAC_LORAWAN_H__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#defineLORAWAN_MODULE_NAME "maclorawan"
+
+/* List the message types of LoRaWAN */
+enum {
+ LRW_JOIN_REQUEST,
+ LRW_JOIN_ACCEPT,
+ LRW_UNCONFIRMED_DATA_UP,
+ LRW_UNCONFIRMED_DATA_DOWN,
+ LRW_CONFIRMED_DATA_UP,
+ LRW_CONFIRMED_DATA_DOWN,
+ LRW_RFU,
+ LRW_PROPRIETARY,
+};
+
+/* List the communication directions */
+enum {
+ LRW_UPLINK,
+ LRW_DOWNLINK,
+};
+
+/* States of LoRaWAN slot timing */
+enum {
+ LRW_INIT_SS,
+ LRW_XMITTING_SS,
+ LRW_XMITTED,
+ LRW_RX1_SS,
+ LRW_RX2_SS,
+ LRW_RXTIMEOUT_SS,
+ LRW_RXRECEIVED_SS,
+ LRW_RETRANSMIT_SS,
+};
+
+#defineLRW_MHDR_LEN1
+#defineLRW_FHDR_MAX_LEN22
+#defineLRW_FCTRL_LEN 1
+#defineLRW_FCNT_LEN2
+#defineLRW_FOPS_MAX_LEN15
+#defineLRW_FPORT_LEN 1
+#defineLRW_MIC_LEN 4
+
+/**
+ * lrw_fhdr - Hold the message's basic information of the frame
+ *
+ * @mtype: this message's type
+ * @fctrl: the frame control byte
+ * @fcnt: this message's frame counter value
+ * @fopts: this frame's options field
+ * @fopts_len: the length of the fopts
+ */
+struct lrw_fhdr {
+ u8 mtype;
+ u8 fctrl;
+ u16 fcnt;
+ u8 fopts[LRW_FPORT_LEN];
+ u8 fopts_len;
+};
+
+/**
+ * lrw_session - LoRaWAN session for Class A end device
+ *
+ * @lrw_st:points to the belonging lrw_st
+ * @entry: the entry of the ss_list in lrw_struct
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ * @fcnt_up: uplink frame counter
+ * @fcnt_down: downlink frame counter
+ * @fport: the LoRaWAN data message's port field
+ * @tx_skb:points to the TX skb, the frame
+ * @rx_skb:points to the RX skb, the frame
+ * @tx_fhdr: hold the message's basic information of the TX frame
+ * @rx_fhdr: hold the message's basic information of the RX frame
+ * @tx_should_ack: flag for determining the TX which should be acked or not
+ * @retry: retry times for xmitting failed
+ * @state: this session's current state
+ * @state_lock:lock of the session's state
+ * @timer: timing for this session and the state transition
+ * @timeout_work: work if waiting acknowledge time out
+ * @rx_delay1: RX1 delay time in seconds
+ * @rx_delay2: RX2 delay time in seconds
+ * @rx1_window:RX1 window opening time in milliseconds
+ * @rx2_window:RX2 window opening time in milliseconds
+ * @ack_timeout: time out time for waiting acknowledge in seconds
+ */
+struct lrw_session {
+ struct lrw_struct *lrw_st;
+ struct list_head entry;
+
+ u32 devaddr;
+ u16 fcnt_up;
+ u16 fcnt_down;
+ u8 fport;
+ struct sk_buff *tx_skb;
+ struct sk_buff *rx_skb;
+ struct lrw_fhdr tx_fhdr;
+ struct lrw_fhdr rx_fhdr;
+
+ u8 tx_should_ack;
+ u8 retry;
+ u8 state;
+ spinlock_t state_lock; /* lock of the session's state */
+
+ struct timer_list timer;
+ struct work_struct timeout_work;
+ unsigned long rx_delay1;
+ unsigned long rx_delay2;
+ unsigned long rx1_window;
+ unsigned long rx2_window;
+ unsigned long ack_timeout;
+};
+
+/**
+ * lrw_struct - The full LoRaWAN hardware to the LoRa device.
+ *
+ * @dev: this LoRa device registed in system
+ * @hw:the LoRa device of this LoRaWAN hardware
+ * @ops: handle of LoRa operations interfaces
+ * @rx_skb_list: the list of received frames
+ * @ss_list: LoRaWAN session list of this LoRaWAN hardware
+ * @ss_list_lock:
[PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices.
This patch implements part of Class A end-devices SoftMAC defined in
LoRaWAN(TM) Specification Ver. 1.0.2:
1. End-device receive slot timing
2. Only single channel and single data rate for now
3. Unconfirmed data up/down message types
On the other side, it defines the basic interface and operation
functions for compatible LoRa device drivers.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Modify for Big/Little-Endian
- Use SPDX license identifiers
V3:
- Remove the decoration word - inline of the functions
- Order local variables from longest to shortest line in the functions
- Change the calling mac_cb function to lrw_get_mac_cb macro
V4:
- Fix the delay period between RX window#1 and window#2
- Fix by coding style report from scripts/checkpatch.pl
V5:
- Initial rx_skb_list when it is allocated with LoRa hardware
- Check the sk_buff's data length before access it
- Deal FPort field and decrypt payload in lrw_parse_frame function
- Drop the recieved frame if parse failed
- Fix the bug which passes wrong skb properties from maclorawan to lorawan
module
net/maclorawan/Kconfig | 14 +
net/maclorawan/Makefile | 2 +
net/maclorawan/mac.c| 555
net/maclorawan/main.c | 606
4 files changed, 1177 insertions(+)
create mode 100644 net/maclorawan/Kconfig
create mode 100644 net/maclorawan/Makefile
create mode 100644 net/maclorawan/mac.c
create mode 100644 net/maclorawan/main.c
diff --git a/net/maclorawan/Kconfig b/net/maclorawan/Kconfig
new file mode 100644
index ..d700314edf26
--- /dev/null
+++ b/net/maclorawan/Kconfig
@@ -0,0 +1,14 @@
+config MACLORAWAN
+ tristate "Generic LoRaWAN Soft Networking Stack (maclorawan)"
+ depends on LORAWAN
+ select CRYPTO
+ select CRYPTO_CMAC
+ select CRYPTO_CBC
+ select CRYPTO_AES
+ help
+ This option enables the hardware independent LoRaWAN
+ networking stack for SoftMAC devices (the ones implementing
+ only PHY level of LoRa standard).
+
+ If you plan to use HardMAC LoRaWAN devices, you can say N
+ here. Alternatively you can say M to compile it as a module.
diff --git a/net/maclorawan/Makefile b/net/maclorawan/Makefile
new file mode 100644
index ..562831e66c82
--- /dev/null
+++ b/net/maclorawan/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_MACLORAWAN) += maclorawan.o
+maclorawan-objs:= main.o mac.o crypto.o
diff --git a/net/maclorawan/mac.c b/net/maclorawan/mac.c
new file mode 100644
index ..459ab95ff52d
--- /dev/null
+++ b/net/maclorawan/mac.c
@@ -0,0 +1,555 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*-
+ * LoRaWAN soft MAC
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "maclorawan.h"
+#include "crypto.h"
+
+static void rx_timeout_work(struct work_struct *work);
+
+struct lrw_session *
+lrw_alloc_ss(struct lrw_struct *lrw_st)
+{
+ struct lrw_session *ss;
+
+ ss = kzalloc(sizeof(*ss), GFP_KERNEL);
+ if (!ss)
+ goto lrw_alloc_ss_end;
+
+ ss->lrw_st = lrw_st;
+ ss->devaddr = lrw_st->devaddr;
+ INIT_LIST_HEAD(&ss->entry);
+
+ ss->tx_should_ack = false;
+ ss->retry = 3;
+ spin_lock_init(&ss->state_lock);
+ INIT_WORK(&ss->timeout_work, rx_timeout_work);
+
+lrw_alloc_ss_end:
+ return ss;
+}
+
+void
+lrw_free_ss(struct lrw_session *ss)
+{
+ netdev_dbg(ss->lrw_st->ndev, "%s\n", __func__);
+ if (ss->tx_skb)
+ consume_skb(ss->tx_skb);
+ netdev_dbg(ss->lrw_st->ndev, "%s: free rx skb\n", __func__);
+ if (ss->rx_skb)
+ consume_skb(ss->rx_skb);
+
+ netdev_dbg(ss->lrw_st->ndev, "%s: free ss\n", __func__);
+ kfree(ss);
+}
+
+void
+lrw_del_ss(struct lrw_session *ss)
+{
+ netdev_dbg(ss->lrw_st->ndev, "%s\n", __func__);
+ list_del(&ss->entry);
+ lrw_free_ss(ss);
+}
+
+void
+lrw_del_all_ss(struct lrw_struct *lrw_st)
+{
+ struct lrw_session *ss, *tmp;
+
+ mutex_lock(&lrw_st->ss_list_lock);
+ lrw_st->_cur_ss = NULL;
+ list_for_each_entry_safe(ss, tmp, &lrw_st->ss_list, entry) {
+ del_timer(&ss->timer);
+ lrw_del_ss(ss);
+ }
+ mutex_unlock(&lrw_st->ss_list_lock);
+}
+
+void
+lrw_ready_hw(struct lrw_struct *lrw_st)
+{
+ lrw_st->state = LRW_STATE_IDLE;
+}
+
+i
Re: [PATCH v5 1/6] net: lorawan: Add LoRaWAN socket module
Andreas Färber 於 2018年12月29日 週六 下午3:27寫道：
>
> Hi Jian-Hong,
>
> Am 16.12.18 um 11:18 schrieb Jian-Hong Pan:
> > This patch adds a new address/protocol family for LoRaWAN network.
> > It also implements the the functions and maps to Datagram socket for
> > LoRaWAN unconfirmed data messages.
> >
> > Signed-off-by: Jian-Hong Pan
> [...]
> > include/linux/lora/lorawan_netdev.h | 52 +++
> > net/lorawan/Kconfig | 10 +
> > net/lorawan/Makefile| 2 +
> > net/lorawan/socket.c| 686
> > 4 files changed, 750 insertions(+)
> > create mode 100644 include/linux/lora/lorawan_netdev.h
> > create mode 100644 net/lorawan/Kconfig
> > create mode 100644 net/lorawan/Makefile
> > create mode 100644 net/lorawan/socket.c
>
> I'm not 100% happy with this yet, but to decouple it from the soft-MAC
> discussion (patches 2-6/6) and to allow reuse by Ben, I've staged it in
> linux-lora.git.
>
> We can clean it up with incremental patches there (and squash later).
>
> >
> > diff --git a/include/linux/lora/lorawan_netdev.h
> > b/include/linux/lora/lorawan_netdev.h
> > new file mode 100644
> > index ..5bffb5164f95
> > --- /dev/null
> > +++ b/include/linux/lora/lorawan_netdev.h
> > @@ -0,0 +1,52 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
>
> Is there any practical reason you dual-license your code? My LoRa code
> is only GPL - should I reconsider that?
I use dual-license due to the event "[Ksummit-discuss] [CORE TOPIC]
GPL defense issues"
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html
> > +/*-
>
> I assume the dash is a typo?
>
> > + * LoRaWAN stack related definitions
> > + *
> > + * Copyright (c) 2018 Jian-Hong, Pan
> > + *
>
> Leftover white line from old license header?
>
> > + */
> > +
> > +#ifndef __LORAWAN_NET_DEVICE_H__
> > +#define __LORAWAN_NET_DEVICE_H__
> > +
> > +enum {
> > + LRW_ADDR_APPEUI,
> > + LRW_ADDR_DEVEUI,
> > + LRW_ADDR_DEVADDR,
> > +};
> > +
> > +struct lrw_addr_in {
> > + int addr_type;
> > + union {
> > + u64 app_eui;
> > + u64 dev_eui;
>
> In my RFC and in linux-lora.git I have a lora_eui typedef - any reason
> you're not using it here?
lora_eui is defined as a type of u8 array with 8 bytes in
include/linux/lora/dev.h
typedef u8 lora_eui[8];
It is not a basic nor simple data type.
1. There is the endian issue. LoRaWAN uses little endian for
transmission. If u64 data type is used, we can call functions like
cpu_to_le64 and le64_to_cpu to deal the endian jobs directly.
2. We can compare the EUIs with relational operators directly if the
EUI is not a type of array.
> > + u32 devaddr;
> > + };
> > +};
> > +
> > +struct sockaddr_lorawan {
> > + sa_family_t family; /* AF_LORAWAN */
> > + struct lrw_addr_in addr_in;
> > +};
> > +
> > +/**
> > + * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
> > + *
> > + * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
> > + */
> > +struct lrw_mac_cb {
> > + u32 devaddr;
> > +};
> > +
> > +/**
> > + * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
> > + * @skb: the exchanging sk_buff
> > + *
> > + * Return: the pointer of LoRaWAN MAC control buffer
> > + */
> > +static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
> > +{
> > + return (struct lrw_mac_cb *)skb->cb;
> > +}
>
> For LoRa I have a separate lora/skb.h - suggest to split this off into
> its own header consistently.
Sounds good.
Do you prefer separate them into lora/skb.h or lora/lorawan_skb.h?
> > +
> > +#endif
> > diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig
> > new file mode 100644
> > index ..bf6c9b77573b
> > --- /dev/null
> > +++ b/net/lorawan/Kconfig
> > @@ -0,0 +1,10 @@
> > +config LORAWAN
> > + tristate "LoRaWAN Network support"
>
> The N in LoRaWAN is already for Network. :)
>
> > + help
> > + LoRaWAN defines low data rate, low power and long range wireless
> > + wide area networks. It was designed to organize networks of
> > automation
> > + devices, such as sensors, switches and actuators. It can operate
> > + multiple kilometers wide.
>
> The missing information here to distinguish
[PATCH] ALSA: hda/realtek: Enable the headset mic auto detection for ASUS laptops
The headset mic of ASUS laptops like UX533FD, UX433FN and UX333FA, whose
CODEC is Realtek ALC294 has jack auto detection feature. This patch
enables the feature.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a4f4a9dd488d..aee4cbd29d53 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6501,7 +6501,7 @@ static const struct hda_fixup alc269_fixups[] = {
[ALC294_FIXUP_ASUS_HEADSET_MIC] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
- { 0x19, 0x01a1113c }, /* use as headset mic, without
its own jack detect */
+ { 0x19, 0x01a1103c }, /* use as headset mic */
{ }
},
.chained = true,
--
2.11.0
Re: [PATCH V2 2/7] net: lorawan: Add LoRaWAN socket module
David Miller 於 2018年11月6日 週二 上午2:16寫道：
>
> From: Jian-Hong Pan
> Date: Tue, 6 Nov 2018 00:55:40 +0800
>
> > +static inline struct lrw_mac_cb * mac_cb(struct sk_buff *skb)
>
> "mac_cb()" is pretty generic for a name, and leads to namespace pollution,
> please use lrw_mac_cb() or similar.
>
> > +static inline struct dgram_sock *
> > +dgram_sk(const struct sock *sk)
> > +{
> > + return container_of(sk, struct dgram_sock, sk);
> > +}
> > +
> > +static inline struct net_device *
> > +lrw_get_dev_by_addr(struct net *net, u32 devaddr)
>
> Never use inline for functions in a foo.c file, let the compiler decide.
>
> > +{
> > + struct net_device *ndev = NULL;
> > + __be32 be_addr = cpu_to_be32(devaddr);
>
> Always order local variables from longest to shortest line.
>
> > +static int
> > +dgram_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
> > + int noblock, int flags, int *addr_len)
> > +{
> > + struct sk_buff *skb;
> > + size_t copied = 0;
> > + DECLARE_SOCKADDR(struct sockaddr_lorawan *, saddr, msg->msg_name);
> > + int err;
>
> Likewise.
>
> I'm not going to point out every single place where you have made these
> two errors.
>
> Please audit your entire submission and fix the problems wherever they
> occur.
Thanks for the reviewing. I will check the submission again.
Jian-Hong Pan
[PATCH V2 0/7] net: lorawan: Add LoRaWAN soft MAC module
LoRaWAN(TM) is the MAC layer defined by LoRa Alliance(TM) over LoRa devices. LoRa is one of Low-Power Wide-Area Network (LPWAN) technology. LoRaWAN networks typically are laid out in a star-of-stars topology in which gateways relay messages between end-devices and a central network server at the backend. Gateways are connected to the network server via standard IP connections while end-devices use single hop LoRa(TM) or FSK communication to one or many gateways. A LoRa network distinguishes between a basic LoRaWAN (named Class A) and optional features (Class B, Class C ...): * Bi-directional end-devices (Class A) * Bi-directional end-devices with scheduled receive slots (Class B) * Bi-directional end-devices with maximal receive slots (Class C) This patch set add LoRaWAN class module implementing the stack, especially the soft MAC, between socket APIs and LoRa device drivers. socket APIs: send and receive the data LoRaWAN class module implements soft MAC: append the header/footer, encryption/decryption, timing slot and MAC commands LoRa device drivers: send and receive the messages for MAC layer LoRa devices This module starts from simple and implements partial Class A end-devices features defined in LoRaWAN(TM) Specification Ver. 1.0.2. More features and complexity, for example regional parameters, confirmed data messages, join request/accept messages for Over-The-Air Activation, MAC commands ... will be added in the future. Jian-Hong Pan (7): net: lorawan: Add macro and definition for LoRaWAN net: lorawan: Add LoRaWAN socket module net: lorawan: Add LoRaWAN API declaration for LoRa devices net: maclorawan: Add maclorawan module declaration net: maclorawan: Implement the crypto of maclorawan module net: maclorawan: Implement maclorawan class module net: lorawan: List LORAWAN in menuconfig include/linux/lora/lorawan.h| 137 ++ include/linux/lora/lorawan_netdev.h | 52 +++ include/linux/socket.h | 5 +- include/uapi/linux/if_arp.h | 1 + include/uapi/linux/if_ether.h | 1 + net/Kconfig | 2 + net/Makefile| 2 + net/core/dev.c | 4 +- net/lorawan/Kconfig | 10 + net/lorawan/Makefile| 2 + net/lorawan/socket.c| 681 net/maclorawan/Kconfig | 14 + net/maclorawan/Makefile | 2 + net/maclorawan/crypto.c | 209 + net/maclorawan/crypto.h | 27 ++ net/maclorawan/mac.c| 522 + net/maclorawan/maclorawan.h | 199 net/maclorawan/main.c | 600 security/selinux/hooks.c| 4 +- security/selinux/include/classmap.h | 4 +- 20 files changed, 2473 insertions(+), 5 deletions(-) create mode 100644 include/linux/lora/lorawan.h create mode 100644 include/linux/lora/lorawan_netdev.h create mode 100644 net/lorawan/Kconfig create mode 100644 net/lorawan/Makefile create mode 100644 net/lorawan/socket.c create mode 100644 net/maclorawan/Kconfig create mode 100644 net/maclorawan/Makefile create mode 100644 net/maclorawan/crypto.c create mode 100644 net/maclorawan/crypto.h create mode 100644 net/maclorawan/mac.c create mode 100644 net/maclorawan/maclorawan.h create mode 100644 net/maclorawan/main.c -- 2.19.1
[PATCH V2 1/7] net: lorawan: Add macro and definition for LoRaWAN
This patch adds the macro and definition for the implementation of
LoRaWAN protocol.
Signed-off-by: Jian-Hong Pan
---
V2:
- Modify the commit message
include/linux/socket.h | 5 -
include/uapi/linux/if_arp.h | 1 +
include/uapi/linux/if_ether.h | 1 +
net/core/dev.c | 4 ++--
security/selinux/hooks.c| 4 +++-
security/selinux/include/classmap.h | 4 +++-
6 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index aa1e288b1659..e5c8381fd1aa 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -209,8 +209,9 @@ struct ucred {
*/
#define AF_XDP 44 /* XDP sockets */
#define AF_LORA45 /* LoRa sockets */
+#define AF_LORAWAN 46 /* LoRaWAN sockets */
-#define AF_MAX 46 /* For now.. */
+#define AF_MAX 47 /* For now.. */
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
@@ -261,6 +262,7 @@ struct ucred {
#define PF_SMC AF_SMC
#define PF_XDP AF_XDP
#define PF_LORAAF_LORA
+#define PF_LORAWAN AF_LORAWAN
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
@@ -343,6 +345,7 @@ struct ucred {
#define SOL_KCM281
#define SOL_TLS282
#define SOL_XDP283
+#define SOL_LORAWAN284
/* IPX options */
#define IPX_TYPE 1
diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
index 1ed7cb3f2129..2376f7839355 100644
--- a/include/uapi/linux/if_arp.h
+++ b/include/uapi/linux/if_arp.h
@@ -99,6 +99,7 @@
#define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */
#define ARPHRD_VSOCKMON826 /* Vsock monitor header
*/
#define ARPHRD_LORA827 /* LoRa */
+#define ARPHRD_LORAWAN 828 /* LoRaWAN */
#define ARPHRD_VOID 0x/* Void type, nothing is known */
#define ARPHRD_NONE 0xFFFE/* zero header length */
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 45644dcf5b39..b1ac70d4a377 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -148,6 +148,7 @@
* aggregation protocol
*/
#define ETH_P_LORA 0x00FA /* LoRa */
+#define ETH_P_LORAWAN 0x00FB /* LoRaWAN */
/*
* This is an Ethernet frame header.
diff --git a/net/core/dev.c b/net/core/dev.c
index f68122f0ab02..b95ce79ec5a8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -297,7 +297,7 @@ static const unsigned short netdev_lock_type[] = {
ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
-ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE};
+ARPHRD_IEEE802154, ARPHRD_LORAWAN, ARPHRD_VOID, ARPHRD_NONE};
static const char *const netdev_lock_name[] = {
"_xmit_NETROM", "_xmit_ETHER", "_xmit_EETHER", "_xmit_AX25",
@@ -314,7 +314,7 @@ static const char *const netdev_lock_name[] = {
"_xmit_IRDA", "_xmit_FCPP", "_xmit_FCAL", "_xmit_FCPL",
"_xmit_FCFABRIC", "_xmit_IEEE80211", "_xmit_IEEE80211_PRISM",
"_xmit_IEEE80211_RADIOTAP", "_xmit_PHONET", "_xmit_PHONET_PIPE",
- "_xmit_IEEE802154", "_xmit_VOID", "_xmit_NONE"};
+ "_xmit_IEEE802154", "_xmit_LORAWAN", "_xmit_VOID", "_xmit_NONE"};
static struct lock_class_key
netdev_xmit_lock_key[ARRAY_SIZE(netdev_lock_type)];
static struct lock_class_key
netdev_addr_lock_key[ARRAY_SIZE(netdev_lock_type)];
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index aaf520a689d8..0da3a1d69cb8 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1477,7 +1477,9 @@ static inline u16 socket_type_to_security_class(int
family, int type, int protoc
return SECCLASS_XDP_SOCKET;
case PF_LORA:
return SECCLASS_LORA_SOCKET;
-#if PF_MAX > 46
+ case PF_LORAWAN:
+ return SECCLASS_LORAWAN_SOCKET;
+#if PF_MAX > 47
#error New address family defined, please update this function.
#endif
}
diff --git a/security/selinux/include/classmap.h
b/security/selinux/include/classmap.h
index 060d4bf8385e..fa0151fe6f32 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/inclu
[PATCH V2 4/7] net: maclorawan: Add maclorawan module declaration
Add the maclorawan header file for common APIs in the module.
Signed-off-by: Jian-Hong Pan
---
V2:
- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and
LoRaWAN Soft MAC modules
- Use SPDX license identifiers
net/maclorawan/maclorawan.h | 199
1 file changed, 199 insertions(+)
create mode 100644 net/maclorawan/maclorawan.h
diff --git a/net/maclorawan/maclorawan.h b/net/maclorawan/maclorawan.h
new file mode 100644
index ..66b87f051d51
--- /dev/null
+++ b/net/maclorawan/maclorawan.h
@@ -0,0 +1,199 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*-
+ * LoRaWAN soft MAC
+ *
+ * Copyright (c) 2018 Jian-Hong, Pan
+ *
+ */
+
+#ifndef __MAC_LORAWAN_H__
+#define __MAC_LORAWAN_H__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#defineLORAWAN_MODULE_NAME "maclorawan"
+
+/* List the message types of LoRaWAN */
+enum {
+ LRW_JOIN_REQUEST,
+ LRW_JOIN_ACCEPT,
+ LRW_UNCONFIRMED_DATA_UP,
+ LRW_UNCONFIRMED_DATA_DOWN,
+ LRW_CONFIRMED_DATA_UP,
+ LRW_CONFIRMED_DATA_DOWN,
+ LRW_RFU,
+ LRW_PROPRIETARY,
+};
+
+/* List the communication directions */
+enum {
+ LRW_UPLINK,
+ LRW_DOWNLINK,
+};
+
+/* States of LoRaWAN slot timing */
+enum {
+ LRW_INIT_SS,
+ LRW_XMITTING_SS,
+ LRW_XMITTED,
+ LRW_RX1_SS,
+ LRW_RX2_SS,
+ LRW_RXTIMEOUT_SS,
+ LRW_RXRECEIVED_SS,
+ LRW_RETRANSMIT_SS,
+};
+
+#defineLRW_MHDR_LEN1
+#defineLRW_FHDR_MAX_LEN22
+#defineLRW_FOPS_MAX_LEN15
+#defineLRW_FPORT_LEN 1
+#defineLRW_MIC_LEN 4
+
+/**
+ * lrw_fhdr - Hold the message's basic information of the frame
+ *
+ * @mtype: this message's type
+ * @fctrl: the frame control byte
+ * @fcnt: this message's frame counter value
+ * @fopts: this frame's options field
+ * @fopts_len: the length of the fopts
+ */
+struct lrw_fhdr {
+ u8 mtype;
+ u8 fctrl;
+ u16 fcnt;
+ u8 fopts[LRW_FPORT_LEN];
+ u8 fopts_len;
+};
+
+/**
+ * lrw_session - LoRaWAN session for Class A end device
+ *
+ * @lrw_st:points to the belonging lrw_st
+ * @entry: the entry of the ss_list in lrw_struct
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ * @fcnt_up: uplink frame counter
+ * @fcnt_down: downlink frame counter
+ * @fport: the LoRaWAN data message's port field
+ * @tx_skb:points to the TX skb, the frame
+ * @rx_skb:points to the RX skb, the frame
+ * @tx_fhdr: hold the message's basic information of the TX frame
+ * @rx_fhdr: hold the message's basic information of the RX frame
+ * @tx_should_ack: flag for determining the TX which should be acked or not
+ * @retry: retry times for xmitting failed
+ * @state: this session's current state
+ * @state_lock:lock of the session's state
+ * @timer: timing for this session and the state transition
+ * @timeout_work: work if waiting acknowledge time out
+ * @rx_delay1: RX1 delay time in seconds
+ * @rx_delay2: RX2 delay time in seconds
+ * @rx1_window:RX1 window opening time in mini-seconds
+ * @rx2_window:RX2 window opening time in mini-seconds
+ * @ack_timeout: time out time for waiting acknowledge in seconds
+ */
+struct lrw_session {
+ struct lrw_struct *lrw_st;
+ struct list_head entry;
+
+ u32 devaddr;
+ u16 fcnt_up;
+ u16 fcnt_down;
+ u8 fport;
+ struct sk_buff *tx_skb;
+ struct sk_buff *rx_skb;
+ struct lrw_fhdr tx_fhdr;
+ struct lrw_fhdr rx_fhdr;
+
+ bool tx_should_ack;
+ u8 retry;
+ u8 state;
+ spinlock_t state_lock;
+
+ struct timer_list timer;
+ struct work_struct timeout_work;
+ unsigned long rx_delay1;
+ unsigned long rx_delay2;
+ unsigned long rx1_window;
+ unsigned long rx2_window;
+ unsigned long ack_timeout;
+};
+
+/**
+ * lrw_struct - The full LoRaWAN hardware to the LoRa device.
+ *
+ * @dev: this LoRa device registed in system
+ * @hw:the LoRa device of this LoRaWAN hardware
+ * @ops: handle of LoRa operations interfaces
+ * @rx_skb_list: the list of received frames
+ * @ss_list: LoRaWAN session list of this LoRaWAN hardware
+ * @_cur_ss: pointer of the current processing session
+ * @rx_should_ack: represent the current session should be acked or not
+ * @state: the state of this LoRaWAN hardware
+ * @app_eui: the LoRaWAN application EUI
+ * @dev_eui: the LoRaWA
Re: [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA
2018-04-02 19:29 GMT+08:00 Takashi Iwai : > > On Mon, 02 Apr 2018 09:33:13 +0200, > Jian-Hong Pan wrote: > > > > This ASUS D640SA desktop whose mother board is D640MB has > > - two jacks which are a headphone and a mic on the front panel, > > - three jacks which are a mic, a line out and a line in on the rear panel > > - one internal speaker. > > > > If I plug a headphone to the front headphone jack, there will be sound > > through the headphone jack, and no sound through the internal speaker. > > If I unplug the headphone from the the headphone jack, there will be > > sound through the internal speaker. And always no sound through rear > > line out, when I plug a headphone or an externel speaker to the rear > > line out jack. > > > > Besides, I had checked and toggled the Auto-Mute Mode in alsamixer, but > > the rear line out still was not working. Then I checked the sound > > settings in GUI, and found there was no "Line Out" could be chosen, only > > the "Headphones" and "HDMI/DisplayPort". > > However, system does know that there is an "Intel PCH Line Out". > > > > [ 10.089082] snd_hda_codec_realtek hdaudioC0D0: autoconfig for > > ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line > > [ 10.089083] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=1 > > (0x1a/0x0/0x0/0x0/0x0) > > [ 10.089084] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 > > (0x1b/0x0/0x0/0x0/0x0) > > [ 10.089085] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 > > [ 10.089086] snd_hda_codec_realtek hdaudioC0D0:inputs: > > [ 10.089087] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 > > [ 10.089088] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 > > [ 10.089089] snd_hda_codec_realtek hdaudioC0D0: Line=0x15 > > [ 10.104387] input: HDA Intel PCH Rear Mic as > > /devices/pci:00/:00:1f.3/sound/card0/input9 > > [ 10.104416] input: HDA Intel PCH Front Mic as > > /devices/pci:00/:00:1f.3/sound/card0/input10 > > [ 10.104441] input: HDA Intel PCH Line as > > /devices/pci:00/:00:1f.3/sound/card0/input11 > > [ 10.104467] input: HDA Intel PCH Line Out as > > /devices/pci:00/:00:1f.3/sound/card0/input12 > > [ 10.104494] input: HDA Intel PCH Front Headphone as > > /devices/pci:00/:00:1f.3/sound/card0/input13 > > > > Consequently, I checked the pin widgets' default configuration values: > > - Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out > > Pin Default 0x01014010: [Jack] Line Out at Ext Rear > > > > - Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out > > Pin Default 0x02214030: [Jack] HP Out at Ext Front > > > > Because the headphone jack (Node ID:0x1b) locates on the desktop's front > > panel, not rear panel, I change the headphone jack's configuration from > > primary chassis to separate chassis. So, the configuration value of > > Node ID:0x1b should be 0x22214030. > > This is OK, but... > > > Additionally, I toggle the Auto-Mute Mode of Realtek codecs to “Speaker > > Only” which makes signal outputs through line out jack when the "Line > > Out" is chosen in the sound settings. > > ... this is a matter of taste, and I don't think it good to set a > different default from others. You can change it once and save it via > alsactl. The default state of Auto-Mute Mode of Realtek codec on this machine is "Line Out + Speaker". This disallows to output audio signal through the line out jack, even I already choose the "Line Out" as the audio output device in the sound settings. It means there is no way to use the line out jack in "Line Out + Speaker" state of Auto-Mute Mode on this machine. To enhance the user experience, especially the new one who first uses Linux, changing this machine's Auto-Mute Mode to "Speaker Only" state, which allows to output the audio signal through the line out jack, will be the better choice. By the way, if the "Headphones" is chosen as the audio output device in the sound settings, the audio signal will not output through the line out jack automatically. Therefore, I think this part of the quirk is still needed on this machine. > And, the code to change this doesn't look good, either. If any, it'd > be easier to just set spec->gen.automute_speaker and > spec->gen.automute_lo in the fixup with HDA_FIXUP_ACT_PROBE (that is > performed after the parser call). Oh! This advice looks great and more directly! I will try this. Thanks for the suggestion. Jian-Hong > So, for n
Re: [PATCH] platform/x86: asus-wmi: Add keyboard backlight toggle support
2018-05-02 14:02 GMT+08:00 Chris Chiu :
> Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard
> backlight toggle. In this UX550GE, the hotkey incremet the level
> of brightness for each keypress from 1 to 3, and then switch it
> off when the brightness has been the max. This commit interprets
> the code 0xc7 generated from hotkey to KEY_KBDILLUMUP to increment
> the brightness, then pass KEY_KBDILLUMTOGGLE to user space after
> the brightness max been reached for switching the led off.
>
> https://phabricator.endlessm.com/T21390
>
Tested-by: Jian-Hong Pan
> Signed-off-by: Chris Chiu
> ---
> drivers/platform/x86/asus-nb-wmi.c | 1 +
> drivers/platform/x86/asus-wmi.c| 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/platform/x86/asus-nb-wmi.c
> b/drivers/platform/x86/asus-nb-wmi.c
> index 136ff2b..14c502e 100644
> --- a/drivers/platform/x86/asus-nb-wmi.c
> +++ b/drivers/platform/x86/asus-nb-wmi.c
> @@ -496,6 +496,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
> { KE_KEY, 0xC4, { KEY_KBDILLUMUP } },
> { KE_KEY, 0xC5, { KEY_KBDILLUMDOWN } },
> { KE_IGNORE, 0xC6, }, /* Ambient Light Sensor notification */
> + { KE_KEY, 0xC7, { KEY_KBDILLUMTOGGLE } },
> { KE_END, 0},
> };
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 1f6e68f..b64ff90 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -67,6 +67,7 @@ MODULE_LICENSE("GPL");
> #define NOTIFY_BRNDOWN_MAX 0x2e
> #define NOTIFY_KBD_BRTUP 0xc4
> #define NOTIFY_KBD_BRTDWN 0xc5
> +#define NOTIFY_KBD_BRTTOGGLE 0xc7
>
> /* WMI Methods */
> #define ASUS_WMI_METHODID_SPEC 0x43455053 /* BIOS SPECification */
> @@ -1745,6 +1746,13 @@ static void asus_wmi_notify(u32 value, void *context)
> }
> }
>
> + if (code == NOTIFY_KBD_BRTTOGGLE) {
> + if (asus->kbd_led_wk < asus->kbd_led.max_brightness)
> + code = NOTIFY_KBD_BRTUP;
> + else
> + code = NOTIFY_KBD_BRTTOGGLE;
> + }
> +
> if (is_display_toggle(code) &&
> asus->driver->quirks->no_display_toggle)
> goto exit;
> --
> 2.7.4
>
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate X514-51T with ALC255
The Acer TravelMate X514-51T with ALC255 cannot detect the headset MIC
until ALC255_FIXUP_ACER_HEADSET_MIC quirk applied. Although, the
internal DMIC uses another module - snd_soc_skl as the driver. We still
need the NID 0x1a in the quirk to enable the headset MIC.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Kailang Yang
---
sound/pci/hda/patch_realtek.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index c8413d44973c..8debd661e6f2 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5673,6 +5673,7 @@ enum {
ALC225_FIXUP_HEADSET_JACK,
ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE,
ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE,
+ ALC255_FIXUP_ACER_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6639,6 +6640,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC285_FIXUP_LENOVO_HEADPHONE_NOISE
},
+ [ALC255_FIXUP_ACER_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x03a11130 },
+ { 0x1a, 0x90a60140 }, /* use as internal mic */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC255_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6658,6 +6669,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440",
ALC292_FIXUP_DELL_E7X),
--
2.20.1
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC. This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a63670013943..b3fbad5a680f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5695,6 +5695,7 @@ enum {
ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE,
ALC255_FIXUP_ACER_HEADSET_MIC,
ALC295_FIXUP_CHROME_BOOK,
+ ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6677,6 +6678,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC225_FIXUP_HEADSET_JACK
},
+ [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0xd429 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6693,9 +6704,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
- SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
[PATCH v2] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC. This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
Signed-off-by: Jian-Hong Pan
---
v2: According to Realtek's suggestion, change the COEF 0x4f from 0xd429 to
0x5029. Thanks to Realtek!
sound/pci/hda/patch_realtek.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 384719d5c44e..191830d4fa40 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5687,6 +5687,7 @@ enum {
ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE,
ALC225_FIXUP_WYSE_AUTO_MUTE,
ALC225_FIXUP_WYSE_DISABLE_MIC_VREF,
+ ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6685,6 +6686,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x5029 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6701,9 +6712,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
- SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
Re: [PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256
於 2021年2月26日 週五 上午9:04寫道：
>
> From: Chris Chiu
>
> The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
> both the headset mic and the internal mic. Introduce new fixup
> to enable the jack sense and the headset mic. However, the internal
> mic actually connects to Intel SST audio. It still needs Intel SST
> support to make internal mic capture work.
>
> Signed-off-by: Chris Chiu
> ---
> v1 -> v2: remove unnecessary aamix fixup
>
> sound/pci/hda/patch_realtek.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 1927605f0f7e..4871507cd4bf 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -6406,6 +6406,7 @@ enum {
> ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
> ALC282_FIXUP_ACER_DISABLE_LINEOUT,
> ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
> + ALC256_FIXUP_ACER_HEADSET_MIC,
> };
>
> static const struct hda_fixup alc269_fixups[] = {
> @@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
> },
> + [ALC256_FIXUP_ACER_HEADSET_MIC] = {
> + .type = HDA_FIXUP_PINS,
> + .v.pins = (const struct hda_pintbl[]) {
> + { 0x19, 0x02a1113c }, /* use as headset mic, without
> its own jack detect */
> + { 0x1a, 0x90a1092f }, /* use as internal mic */
Since NID 0x1a is an internal DMIC, should this connection type be 0h?
Or, even the quirk of the internal DMIC is not needed for this case.
Because, it is Intel SST DMIC that does not connect to Realtek HDA
CODEC. (Not sure for this one)
The quirk of NID 0x19 is okay for me.
BR,
Jian-Hong Pan
> + { }
> + },
> + .chained = true,
> + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> + },
> };
>
> static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> @@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] =
> {
> SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
> ALC299_FIXUP_PREDATOR_SPK),
> SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
> ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
> SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
> ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
> + SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54",
> ALC256_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> + SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55",
> ALC256_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> ALC233_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> ALC255_FIXUP_ACER_HEADSET_MIC),
> --
> 2.20.1
>
Re: [PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256
Jian-Hong Pan 於 2021年2月26日 週五 上午10:05寫道：
>
> 於 2021年2月26日 週五 上午9:04寫道：
> >
> > From: Chris Chiu
> >
> > The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
> > both the headset mic and the internal mic. Introduce new fixup
> > to enable the jack sense and the headset mic. However, the internal
> > mic actually connects to Intel SST audio. It still needs Intel SST
> > support to make internal mic capture work.
> >
> > Signed-off-by: Chris Chiu
> > ---
> > v1 -> v2: remove unnecessary aamix fixup
> >
> > sound/pci/hda/patch_realtek.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 1927605f0f7e..4871507cd4bf 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -6406,6 +6406,7 @@ enum {
> > ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
> > ALC282_FIXUP_ACER_DISABLE_LINEOUT,
> > ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
> > + ALC256_FIXUP_ACER_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = {
> > @@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
> > },
> > + [ALC256_FIXUP_ACER_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_PINS,
> > + .v.pins = (const struct hda_pintbl[]) {
> > + { 0x19, 0x02a1113c }, /* use as headset mic,
> > without its own jack detect */
> > + { 0x1a, 0x90a1092f }, /* use as internal mic */
>
> Since NID 0x1a is an internal DMIC, should this connection type be 0h?
> Or, even the quirk of the internal DMIC is not needed for this case.
> Because, it is Intel SST DMIC that does not connect to Realtek HDA
> CODEC. (Not sure for this one)
>
> The quirk of NID 0x19 is okay for me.
After more discussion and test with Chris, found the NID 0x1a quirk is
still needed. Otherwise, the headset MIC 0x19 will not work any more.
So, I ack the version 2 patch.
Acked-by: Jian-Hong Pan
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
> > ALC299_FIXUP_PREDATOR_SPK),
> > SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
> > ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
> > SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
> > ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
> > + SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54",
> > ALC256_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55",
> > ALC256_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> > ALC233_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > --
> > 2.20.1
> >
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > Hi Daniel, > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote: > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if > > > you > > > want. > > > > That would be great, although given the potentially inconsistent > > results we've been seeing so far it would be great if you could > > additionally push a git branch somewhere. > > That way we can have higher confidence that we are applying exactly > > the same patches to the same base etc. > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry > for > that. > > I've pushed my current branch here: > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms Thanks to Maxime! I have tried your repository on branch rpi4-kms. The DRM VC4 is used! But got some issues: 1. Some weird error message in dmesg. Not sure it is related, or not [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get HDMI state machine clock https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 2. The screen flashes suddenly sometimes. 3. The higher resolutions, like 1920x1080 ... are lost after hot re-plug HDMI cable (HDMI0) Jian-Hong Pan
[PATCH] brcm: Add 4356 based AP6356S NVRAM for the khadas VIM2
Add a NVRAM file for the wireless module used in khadas VIM2. This
source comes from khadas fenix project's commit 022fdc3a1333 ("hwpacks:
wlan-firmware: add AP6356S firmware for mainline linux"). [1]
[1]:
https://github.com/khadas/fenix/commit/022fdc3a1333d2d16f84c2e59e4507c92a668a3d
Suggested-by: Nick Xie
Signed-off-by: Jian-Hong Pan
---
brcm/brcmfmac4356-sdio.khadas,vim2.txt | 128 +
1 file changed, 128 insertions(+)
create mode 100644 brcm/brcmfmac4356-sdio.khadas,vim2.txt
diff --git a/brcm/brcmfmac4356-sdio.khadas,vim2.txt
b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
new file mode 100644
index 000..4c286cc
--- /dev/null
+++ b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
@@ -0,0 +1,128 @@
+#AP6356SL_V1.1_NVRAM_20150805
+#Modified from AP6356SDP_V1.0_NVRAM_20150216
+NVRAMRev=$Rev: 373428 $
+sromrev=11
+boardrev=0x1121
+boardtype=0x073e
+boardflags=0x02400201
+boardflags2=0x00802000
+boardflags3=0x010a
+macaddr=00:90:4c:1a:10:01
+ccode=0x5855
+regrev=1
+antswitch=0
+pdgain5g=4
+pdgain2g=4
+tworangetssi2g=0
+tworangetssi5g=0
+paprdis=0
+femctrl=10
+vendid=0x14e4
+devid=0x43a3
+manfid=0x2d0
+nocrc=1
+otpimagesize=502
+xtalfreq=37400
+rxgains2gelnagaina0=0
+rxgains2gtrisoa0=7
+rxgains2gtrelnabypa0=0
+rxgains5gelnagaina0=0
+rxgains5gtrisoa0=11
+rxgains5gtrelnabypa0=0
+rxgains5gmelnagaina0=0
+rxgains5gmtrisoa0=13
+rxgains5gmtrelnabypa0=0
+rxgains5ghelnagaina0=0
+rxgains5ghtrisoa0=12
+rxgains5ghtrelnabypa0=0
+rxgains2gelnagaina1=0
+rxgains2gtrisoa1=7
+rxgains2gtrelnabypa1=0
+rxgains5gelnagaina1=0
+rxgains5gtrisoa1=10
+rxgains5gtrelnabypa1=0
+rxgains5gmelnagaina1=0
+rxgains5gmtrisoa1=11
+rxgains5gmtrelnabypa1=0
+rxgains5ghelnagaina1=0
+rxgains5ghtrisoa1=11
+rxgains5ghtrelnabypa1=0
+rxchain=3
+txchain=3
+aa2g=3
+aa5g=3
+agbg0=2
+agbg1=2
+aga0=2
+aga1=2
+tssipos2g=1
+extpagain2g=2
+tssipos5g=1
+extpagain5g=2
+tempthresh=255
+tempoffset=255
+rawtempsense=0x1ff
+pa2ga0=-135,5769,-647
+pa2ga1=-143,6023,-677
+pa5ga0=-183,5746,-697,-172,5801,-685,-176,5707,-680,-180,5445,-659
+pa5ga1=-186,5543,-669,-193,5506,-675,-210,5282,-661,-199,5367,-665
+subband5gver=0x4
+pdoffsetcckma0=0x4
+pdoffsetcckma1=0x4
+pdoffset40ma0=0x
+pdoffset80ma0=0x
+pdoffset40ma1=0x
+pdoffset80ma1=0x
+maxp2ga0=72
+maxp5ga0=69,70,69,68
+maxp2ga1=71
+maxp5ga1=67,67,67,67
+cckbw202gpo=0x1222
+cckbw20ul2gpo=0x
+mcsbw202gpo=0x99E644422
+mcsbw402gpo=0xE9744424
+dot11agofdmhrbw202gpo=0x
+ofdmlrbw202gpo=0x0022
+mcsbw205glpo=0xEEA86661
+mcsbw405glpo=0xEEB86663
+mcsbw805glpo=0xEEB86663
+mcsbw205gmpo=0xAAA86663
+mcsbw405gmpo=0xECB86663
+mcsbw805gmpo=0xEEA86663
+mcsbw205ghpo=0xCC986663
+mcsbw405ghpo=0xEEA86663
+mcsbw805ghpo=0xEEA86663
+mcslr5glpo=0x
+mcslr5gmpo=0x
+mcslr5ghpo=0x
+sb20in40hrpo=0x0
+sb20in80and160hr5glpo=0x0
+sb40and80hr5glpo=0x0
+sb20in80and160hr5gmpo=0x0
+sb40and80hr5gmpo=0x0
+sb20in80and160hr5ghpo=0x0
+sb40and80hr5ghpo=0x0
+sb20in40lrpo=0x0
+sb20in80and160lr5glpo=0x0
+sb40and80lr5glpo=0x0
+sb20in80and160lr5gmpo=0x0
+sb40and80lr5gmpo=0x0
+sb20in80and160lr5ghpo=0x0
+sb40and80lr5ghpo=0x0
+dot11agduphrpo=0x0
+dot11agduplrpo=0x0
+phycal_tempdelta=255
+temps_period=15
+temps_hysteresis=15
+rssicorrnorm_c0=4,4
+rssicorrnorm_c1=4,4
+rssicorrnorm5g_c0=1,2,3,1,2,3,6,6,8,6,6,8
+rssicorrnorm5g_c1=1,2,3,2,2,2,7,7,8,7,7,8
+
+swctrlmap_2g=0x1040,0x4010,0x4010,0x200010,0xff
+swctrlmap_5g=0x0202,0x0101,0x0101,0x00,0x47
+swctrlmapext_5g=0x,0x,0x,0x00,0x000
+swctrlmapext_2g=0x,0x,0x,0x00,0x000
+
+muxenab=0x10
+
--
2.28.0
Re: [PATCH v2] HID: Add Wireless Radio Control feature for Chicony devices
Jiri Kosina 於 2021年1月7日 週四 下午5:23寫道： > > On Wed, 23 Dec 2020, Jian-Hong Pan wrote: > > > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > > "Wireless Radio Control" feature. For example, the wireless keyboard > > [04f2:1236] shipped with ASUS all-in-one desktop. > > > > After consulting Chicony for this hotkey, learned the device will send > > with 0x11 as the report ID and 0x1 as the value when the key is pressed > > down. > > > > This patch maps the event as KEY_RFKILL. > > I don't know how exactly does the report descriptor of that device look > like, but is this not doable from userspace via setkeycode() (udev/systemd > is shipping a lot of such mappings already -- see evdev/keyboard > definitions in hwdb). Thanks for your suggestion! I have tested the key with evtest. But it has no response from all inputs. Nor response from xev. So, I tried usb monitor to see what does it send: $ lsusb -d 04f2:1236 Bus 001 Device 002: ID 04f2:1236 Chicony Electronics Co., Ltd $ sudo modprobe usbmon $ sudo cat /sys/kernel/debug/usb/usbmon/1u 9145e0dea6c0 348311963 C Ii:1:002:1 0:8 8 = 9145e0dea6c0 348311996 S Ii:1:002:1 -115:8 8 < 9145e0deaf00 352852533 C Ii:1:002:2 0:4 2 = 1101 9145e0deaf00 352852547 S Ii:1:002:2 -115:4 3 < It sends 0x1101 for the hotkey. The same response from hid events: $ sudo cat /sys/kernel/debug/hid/0003\:04F2\:1236.0002/events report (size 2) (numbered) = 11 01 Then, I notice there is the RFKILL event listed on the "Chicony USB Receiver Wireless Radio Control" device: $ sudo evtest /dev/input/event8 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x4f2 product 0x1236 version 0x111 Input device name: "Chicony USB Receiver Wireless Radio Control" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 103 (KEY_UP) Event code 105 (KEY_LEFT) Event code 106 (KEY_RIGHT) Event code 108 (KEY_DOWN) Event code 116 (KEY_POWER) Event code 138 (KEY_HELP) Event code 139 (KEY_MENU) Event code 142 (KEY_SLEEP) Event code 143 (KEY_WAKEUP) Event code 148 (KEY_PROG1) Event code 174 (KEY_EXIT) Event code 227 (KEY_SWITCHVIDEOMODE) Event code 247 (KEY_RFKILL) Event code 314 (BTN_SELECT) Event code 315 (BTN_START) Event code 353 (KEY_SELECT) Event code 356 (KEY_POWER2) Event code 408 (KEY_RESTART) Event code 438 (KEY_CONTEXT_MENU) Event type 2 (EV_REL) Event code 9 (REL_MISC) Event type 3 (EV_ABS) ... Also, after debugging, I found its HID application ID is HID_GD_WIRELESS_RADIO_CTLS 0x0001000c [1]. Then, I searched HID_GD_WIRELESS_RADIO_CTLS in the kernel. I found HID_GD_RFKILL_BTN [2] is mapped in hid-input. However, this key press on the Chicony keyboard maps to nothing, nor HID_GD_RFKILL_BTN. Only have the HID report with raw data 0x11 0x00 as mentioned above. It is more like ignored by the kernel and it even has no scancode. That's why I try to map it as KEY_RFKILL in the driver. [1] https://elixir.bootlin.com/linux/v5.10/source/include/linux/hid.h#L181 [2] https://elixir.bootlin.com/linux/v5.10/source/drivers/hid/hid-input.c#L743 Regards, Jian-Hong Pan
[PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
"Wireless Radio Control" feature. For example, the wireless keyboard
[04f2:1236] shipped with ASUS all-in-one desktop.
After consulting Chicony for this hotkey, learned the device will send
with 0x11 as the report ID and 0x1 as the value when the key is pressed
down.
This patch maps the event as KEY_RFKILL.
Signed-off-by: Jian-Hong Pan
---
drivers/hid/hid-chicony.c | 58 +++
drivers/hid/hid-ids.h | 1 +
2 files changed, 59 insertions(+)
diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
index 3f0ed6a95223..aca963aa0f1e 100644
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -21,6 +21,42 @@
#include "hid-ids.h"
+#define KEY_PRESSED0x01
+#define CH_WIRELESS_CTL_REPORT_ID 0x11
+
+static int ch_report_wireless(struct hid_report *report, u8 *data, int size)
+{
+ struct hid_device *hdev = report->device;
+ struct input_dev *input;
+
+ if (report->id != CH_WIRELESS_CTL_REPORT_ID ||
+ report->maxfield != 1 ||
+ *report->field[0]->value != KEY_PRESSED)
+ return 0;
+
+ input = report->field[0]->hidinput->input;
+ if (!input) {
+ hid_warn(hdev, "can't find wireless radio control's input");
+ return 0;
+ }
+
+ input_report_key(input, KEY_RFKILL, 1);
+ input_sync(input);
+ input_report_key(input, KEY_RFKILL, 0);
+ input_sync(input);
+
+ return 1;
+}
+
+static int ch_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
+ return ch_report_wireless(report, data, size);
+
+ return 0;
+}
+
#define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
EV_KEY, (c))
static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
@@ -77,10 +113,30 @@ static __u8 *ch_switch12_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
return rdesc;
}
+static int ch_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+
+ hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret) {
+ hid_err(hdev, "Chicony hw start failed: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
static const struct hid_device_id ch_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
{ }
};
@@ -91,6 +147,8 @@ static struct hid_driver ch_driver = {
.id_table = ch_devices,
.report_fixup = ch_switch12_report_fixup,
.input_mapping = ch_input_mapping,
+ .probe = ch_probe,
+ .raw_event = ch_raw_event,
};
module_hid_driver(ch_driver);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4c5f23640f9c..06d90301a3dc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -270,6 +270,7 @@
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
#define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
+#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
#define USB_DEVICE_ID_ASUS_AK1D0x1125
#define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
#define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
--
2.29.2
Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Chris Chiu 於 2020年12月23日 週三 上午12:41寫道：
>
> On Tue, Dec 22, 2020 at 3:41 PM Jian-Hong Pan wrote:
> >
> > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
> > "Wireless Radio Control" feature. For example, the wireless keyboard
> > [04f2:1236] shipped with ASUS all-in-one desktop.
> >
> > After consulting Chicony for this hotkey, learned the device will send
> > with 0x11 as the report ID and 0x1 as the value when the key is pressed
> > down.
> >
> > This patch maps the event as KEY_RFKILL.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > drivers/hid/hid-chicony.c | 58 +++
> > drivers/hid/hid-ids.h | 1 +
> > 2 files changed, 59 insertions(+)
> >
> > diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
> > index 3f0ed6a95223..aca963aa0f1e 100644
> > --- a/drivers/hid/hid-chicony.c
> > +++ b/drivers/hid/hid-chicony.c
> > @@ -21,6 +21,42 @@
> >
> > #include "hid-ids.h"
> >
> > +#define KEY_PRESSED0x01
> > +#define CH_WIRELESS_CTL_REPORT_ID 0x11
> > +
> > +static int ch_report_wireless(struct hid_report *report, u8 *data, int
> > size)
> > +{
> > + struct hid_device *hdev = report->device;
> > + struct input_dev *input;
> > +
> > + if (report->id != CH_WIRELESS_CTL_REPORT_ID ||
> > + report->maxfield != 1 ||
> > + *report->field[0]->value != KEY_PRESSED)
>
> Maybe replace this line with hid_check_keys_pressed() and the KEY_PRESSED
> is not required.
Thanks for your suggestion!
I tried hid_check_keys_pressed(). But, it always returns no key is
pressed in this case.
However, if the idea is: Since there is already a report, there must
be an event from the input. So, the key press checking is duplicated.
This idea makes sense. I will have a modification for this.
Thanks!
Jian-Hong Pan
> > + return 0;
> > +
> > + input = report->field[0]->hidinput->input;
> > + if (!input) {
> > + hid_warn(hdev, "can't find wireless radio control's input");
> > + return 0;
> > + }
> > +
> > + input_report_key(input, KEY_RFKILL, 1);
> > + input_sync(input);
> > + input_report_key(input, KEY_RFKILL, 0);
> > + input_sync(input);
> > +
> > + return 1;
> > +}
> > +
> > +static int ch_raw_event(struct hid_device *hdev,
> > + struct hid_report *report, u8 *data, int size)
> > +{
> > + if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
> > + return ch_report_wireless(report, data, size);
> > +
> > + return 0;
> > +}
> > +
> > #define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
> > EV_KEY, (c))
> > static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> > @@ -77,10 +113,30 @@ static __u8 *ch_switch12_report_fixup(struct
> > hid_device *hdev, __u8 *rdesc,
> > return rdesc;
> > }
> >
> > +static int ch_probe(struct hid_device *hdev, const struct hid_device_id
> > *id)
> > +{
> > + int ret;
> > +
> > + hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
> > + ret = hid_parse(hdev);
> > + if (ret) {
> > + hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> > + if (ret) {
> > + hid_err(hdev, "Chicony hw start failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> >
> > static const struct hid_device_id ch_devices[] = {
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_WIRELESS2) },
> > + { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_WIRELESS3) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
> > { }
> > };
> > @@ -91,6 +147,8 @@ static struct hid_driver ch_driver = {
> > .id_table = ch_devices,
> > .report_fixup = ch_switch12_report_fixup,
> > .input_mapping = ch_input_mapping,
> > + .probe = ch_probe,
> > + .raw_event = ch_raw_event,
> > };
> > module_hid_driver(ch_driver);
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 4c5f23640f9c..06d90301a3dc 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -270,6 +270,7 @@
> > #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
> > #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
> > #define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
> > +#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
> > #define USB_DEVICE_ID_ASUS_AK1D0x1125
> > #define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
> > #define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
> > --
> > 2.29.2
> >
[PATCH v2] HID: Add Wireless Radio Control feature for Chicony devices
Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
"Wireless Radio Control" feature. For example, the wireless keyboard
[04f2:1236] shipped with ASUS all-in-one desktop.
After consulting Chicony for this hotkey, learned the device will send
with 0x11 as the report ID and 0x1 as the value when the key is pressed
down.
This patch maps the event as KEY_RFKILL.
Signed-off-by: Jian-Hong Pan
---
v2: Remove the duplicated key pressed check.
drivers/hid/hid-chicony.c | 55 +++
drivers/hid/hid-ids.h | 1 +
2 files changed, 56 insertions(+)
diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
index 3f0ed6a95223..ca556d39da2a 100644
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -21,6 +21,39 @@
#include "hid-ids.h"
+#define CH_WIRELESS_CTL_REPORT_ID 0x11
+
+static int ch_report_wireless(struct hid_report *report, u8 *data, int size)
+{
+ struct hid_device *hdev = report->device;
+ struct input_dev *input;
+
+ if (report->id != CH_WIRELESS_CTL_REPORT_ID || report->maxfield != 1)
+ return 0;
+
+ input = report->field[0]->hidinput->input;
+ if (!input) {
+ hid_warn(hdev, "can't find wireless radio control's input");
+ return 0;
+ }
+
+ input_report_key(input, KEY_RFKILL, 1);
+ input_sync(input);
+ input_report_key(input, KEY_RFKILL, 0);
+ input_sync(input);
+
+ return 1;
+}
+
+static int ch_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
+ return ch_report_wireless(report, data, size);
+
+ return 0;
+}
+
#define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
EV_KEY, (c))
static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
@@ -77,10 +110,30 @@ static __u8 *ch_switch12_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
return rdesc;
}
+static int ch_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+
+ hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret) {
+ hid_err(hdev, "Chicony hw start failed: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
static const struct hid_device_id ch_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
{ }
};
@@ -91,6 +144,8 @@ static struct hid_driver ch_driver = {
.id_table = ch_devices,
.report_fixup = ch_switch12_report_fixup,
.input_mapping = ch_input_mapping,
+ .probe = ch_probe,
+ .raw_event = ch_raw_event,
};
module_hid_driver(ch_driver);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4c5f23640f9c..06d90301a3dc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -270,6 +270,7 @@
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
#define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
+#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
#define USB_DEVICE_ID_ASUS_AK1D0x1125
#define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
#define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
--
2.29.2
Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Pavel Machek 於 2020年12月25日 週五 上午3:06寫道： > > On Tue 2020-12-22 15:38:56, Jian-Hong Pan wrote: > > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > > "Wireless Radio Control" feature. For example, the wireless keyboard > > [04f2:1236] shipped with ASUS all-in-one desktop. > > > > After consulting Chicony for this hotkey, learned the device will send > > with 0x11 as the report ID and 0x1 as the value when the key is pressed > > down. > > Fun, how can airplane mode work on _wireless_ keyboard? :-). Hmm! It is a funny point for this USB wireless keyboard! But I guess this kind of combination (with the "desktop") will not be used on an airplane :) Jian-Hong Pan
[PATCH] ALSA: hda/realtek: Enable headset of ASUS UX482EG & B9400CEA with ALC294
Some laptops like ASUS UX482EG & B9400CEA's headset audio does not work
until the quirk ALC294_FIXUP_ASUS_HPE is applied.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 739dbaf54517..1aafc55f1505 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8585,6 +8585,9 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell",
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_HPE,
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
{0x14, 0x90170110},
{0x1b, 0x90a70130},
--
2.29.2
[PATCH] ALSA: hda/realtek: Enable headset of ASUS B1400CEPE with ALC256
ASUS B1400CEPE laptop's headset audio is not enabled until
ALC256_FIXUP_ASUS_HPE quirk is applied.
Here is the original pin node values:
0x12 0x4000
0x13 0x41f0
0x14 0x90170110
0x18 0x41f0
0x19 0x41f0
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x40461b45
0x1e 0x41f0
0x21 0x04211020
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ed5b6b894dc1..290645516313 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8006,6 +8006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x194e, "ASUS UX563FD", ALC294_FIXUP_ASUS_HPE),
+ SND_PCI_QUIRK(0x1043, 0x1982, "ASUS B1400CEPE", ALC256_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
--
2.30.0
Re: [PATCH v2] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Takashi Iwai 於 2019年3月15日 週五 下午7:24寫道：
>
> On Fri, 15 Mar 2019 10:51:09 +0100,
> Jian-Hong Pan wrote:
> >
> > Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
> > record sound from headset MIC. This patch adds the
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2: According to Realtek's suggestion, change the COEF 0x4f from 0xd429 to
> > 0x5029. Thanks to Realtek!
>
> It'd be nicer if we get either Acked-by or Reviewed-by tag from
> Realtek. Kailang?
Hi Kailang,
May we have your Acked-by or Reviewed-by tag for this patch?
Signed-off will also be great!
Thank you
Jian-Hong Pan
> thanks,
>
> Takashi
>
> >
> > sound/pci/hda/patch_realtek.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 384719d5c44e..191830d4fa40 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5687,6 +5687,7 @@ enum {
> > ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE,
> > ALC225_FIXUP_WYSE_AUTO_MUTE,
> > ALC225_FIXUP_WYSE_DISABLE_MIC_VREF,
> > + ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = {
> > @@ -6685,6 +6686,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > },
> > + [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_VERBS,
> > + .v.verbs = (const struct hda_verb[]) {
> > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x5029 },
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -6701,9 +6712,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
> > ALC282_FIXUP_ASPIRE_V5_PINS),
> > SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
> > ALC283_FIXUP_CHROME_BOOK),
> > - SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > - SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > - SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > + SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> > SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
> > ALC275_FIXUP_DELL_XPS),
> > --
> > 2.20.1
> >
> >
[PATCH] ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
Original pin node values of ASUS UX431FL with ALC294:
0x12 0xb7a60140
0x13 0x4000
0x14 0x90170110
0x15 0x41f0
0x16 0x41f0
0x17 0x90170111
0x18 0x41f0
0x19 0x41f0
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x4066852d
0x1e 0x41f0
0x1f 0x41f0
0x21 0x04211020
1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
route become confused. So, the output volume cannot be changed by
setting.
2. Misses the headset mic pin node.
This patch disables the confusing speaker (NID 0x14) and enables the
headset mic (NID 0x19).
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index e333b3e30e31..0a1fa99a6723 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5797,6 +5797,7 @@ enum {
ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC299_FIXUP_PREDATOR_SPK,
+ ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6837,6 +6838,16 @@ static const struct hda_fixup alc269_fixups[] = {
{ }
}
},
+ [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x14, 0x41f0 }, /* disable confusing internal
speaker */
+ { 0x19, 0x04a11150 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6995,6 +7006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
+ SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL",
ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
--
2.20.1
Re: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Kalle Valo 於 2019年9月2日 週一 下午8:18寫道： > > Tony Chuang writes: > > >> From: Jian-Hong Pan > >> Subject: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ > >> > >> There is a mass of jobs between spin lock and unlock in the hardware > >> IRQ which will occupy much time originally. To make system work more > >> efficiently, this patch moves the jobs to the soft IRQ (bottom half) to > >> reduce the time in hardware IRQ. > >> > >> Signed-off-by: Jian-Hong Pan > > > > Now it works fine with MSI interrupt enabled. > > > > But this patch is conflicting with MSI interrupt patch. > > Is there a better way we can make Kalle apply them more smoothly? > > I can rebase them and submit both if you're OK. The rebase work is appreciated. Thank you, Jian-Hong Pan > Yeah, submitting all the MSI patches in the same patchset is the easiest > approach. That way they apply cleanly to wireless-drivers-next. > > -- > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
Takashi Iwai 於 2019年9月2日 週一 下午7:41寫道：
>
> On Mon, 02 Sep 2019 12:00:56 +0200,
> Jian-Hong Pan wrote:
> >
> > Original pin node values of ASUS UX431FL with ALC294:
> >
> > 0x12 0xb7a60140
> > 0x13 0x4000
> > 0x14 0x90170110
> > 0x15 0x41f0
> > 0x16 0x41f0
> > 0x17 0x90170111
> > 0x18 0x41f0
> > 0x19 0x41f0
> > 0x1a 0x41f0
> > 0x1b 0x41f0
> > 0x1d 0x4066852d
> > 0x1e 0x41f0
> > 0x1f 0x41f0
> > 0x21 0x04211020
> >
> > 1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
> >route become confused. So, the output volume cannot be changed by
> >setting.
> > 2. Misses the headset mic pin node.
> >
> > This patch disables the confusing speaker (NID 0x14) and enables the
> > headset mic (NID 0x19).
>
> Is 0x14 really a dead pin? Or is a surround/bass speaker or such?
I checked Windows (updated to latest and including Realtek MEDIA) on
ASUS UX431FL laptop again. Although it has two internal speaker pins,
there is only one set of internal speaker including left/right
channels. And the audio test (Speaker Setup) only shows left/right
channels. So, NID 0x14 can be disabled.
Jain-Hong Pan
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > sound/pci/hda/patch_realtek.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index e333b3e30e31..0a1fa99a6723 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5797,6 +5797,7 @@ enum {
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
> > ALC299_FIXUP_PREDATOR_SPK,
> > + ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = {
> > @@ -6837,6 +6838,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > { }
> > }
> > },
> > + [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_PINS,
> > + .v.pins = (const struct hda_pintbl[]) {
> > + { 0x14, 0x41f0 }, /* disable confusing internal
> > speaker */
> > + { 0x19, 0x04a11150 }, /* use as headset mic, without
> > its own jack detect */
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -6995,6 +7006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
> > ALC269VB_FIXUP_ASUS_ZENBOOK),
> > SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
> > ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
> > SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
> > + SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL",
> > ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
> > SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
> > SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
> > --
> > 2.20.1
> >
> >
[PATCH] Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devices
The ASUS X412FA laptop contains a Realtek RTL8822CE device with an
associated BT chip using a USB ID of 04ca:4005. This ID is added to the
driver.
The /sys/kernel/debug/usb/devices portion for this device is:
T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=4005 Rev= 0.00
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c01
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204707
Signed-off-by: Jian-Hong Pan
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5cf0734eb31b..67c0ca9b1f63 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -384,6 +384,9 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3526), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x0b05, 0x185c), .driver_info = BTUSB_REALTEK },
+ /* Additional Realtek 8822CE Bluetooth devices */
+ { USB_DEVICE(0x04ca, 0x4005), .driver_info = BTUSB_REALTEK },
+
/* Silicon Wave based devices */
{ USB_DEVICE(0x0c10, 0x), .driver_info = BTUSB_SWAVE },
--
2.20.1
[PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
drivers/net/wireless/realtek/rtw88/pci.c | 36 +++-
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..355606b167c6 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
+ unsigned long flags;
- spin_lock(&rtwpci->irq_lock);
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(&rtwpci->irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1172,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1214,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月16日 週五 下午4:07寫道：
>
> Hi,
>
> A few more questions below
>
> > > From: Jian-Hong Pan [mailto:jian-h...@endlessm.com]
> > >
> > > There is a mass of jobs between spin lock and unlock in the hardware
> > > IRQ which will occupy much time originally. To make system work more
> > > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > > reduce the time in hardware IRQ.
> > >
> > > Signed-off-by: Jian-Hong Pan
> > > ---
> > > drivers/net/wireless/realtek/rtw88/pci.c | 36 +++-
> > > 1 file changed, 29 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > > b/drivers/net/wireless/realtek/rtw88/pci.c
> > > index 00ef229552d5..355606b167c6 100644
> > > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > > @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> > irq,
> > > void *dev)
> > > {
> > > struct rtw_dev *rtwdev = dev;
> > > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > > - u32 irq_status[4];
> > > + unsigned long flags;
> > >
> > > - spin_lock(&rtwpci->irq_lock);
> > > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
>
> I think you can use 'spin_lock()' here as it's in IRQ context?
Ah! You are right! The interrupts are already disabled in the
interrupt handler. So, there is no need to disable more once. I can
tweak it.
> > > if (!rtwpci->irq_enabled)
> > > goto out;
> > >
> > > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > > of
> > > +* thread function
> > > +*/
> > > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
>
> Why do we need rtw_pci_disable_interrupt() here.
> Have you done any experiment and decided to add this.
> If you have can you share your results to me?
I got this idea "Avoid back to back interrupt" from Intel WiFi's driver.
https://elixir.bootlin.com/linux/v5.3-rc4/source/drivers/net/wireless/intel/iwlwifi/pcie/rx.c#L2071
So, I disable rtw_pci interrupt here in first half IRQ. (Re-enable in
bottom half)
>
> > > +out:
> > > + spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
>
> spin_unlock()
>
> > > +
> > > + return IRQ_WAKE_THREAD;
> > > +}
> > > +
> > > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > > +{
> > > + struct rtw_dev *rtwdev = dev;
> > > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > > + unsigned long flags;
> > > + u32 irq_status[4];
> > > +
> > > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> > >
> > > if (irq_status[0] & IMR_MGNTDOK)
> > > @@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> > irq,
> > > void *dev)
> > > if (irq_status[0] & IMR_ROK)
> > > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> > >
> > > -out:
> > > - spin_unlock(&rtwpci->irq_lock);
> > > + /* all of the jobs for this interrupt have been done */
> > > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
> >
> > Shouldn't we protect the ISRs above?
> >
> > This patch could actually reduce the time of IRQ.
> > But I think I need to further test it with PCI MSI interrupt.
> > https://patchwork.kernel.org/patch/11081539/
> >
> > Maybe we could drop the "rtw_pci_[enable/disable]_interrupt" when MSI
> > Is enabled with this patch.
> >
> > > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> > > + rtw_pci_enable_interrupt(rtwdev, rtwpci);
Then, re-enable rtw_pci interrupt here in bottom half of the IRQ.
Here is the place where Intel WiFi re-enable interrupts.
https://elixir.bootlin.com/linux/v5.3-rc4/source/drivers/net/wireless/intel/iwlwifi/pcie/rx.c#L1959
Now, we can go back to the question "Shouldn't we protect the ISRs above?"
1. What does the lock: rtwpci->irq_lock protect for?
According to the code, seems only rtw_pci interrupt's state which is
enabled or not.
2. How about the ISRs you mentioned?
This part will only be executed if there is a fresh rtw_pci interrupt.
The first half already disabled rtw_pci interrupt, so there is no more
fresh rtw_pci interrupt until rtw_pci interrupt is enabled again.
Therefor, the rtwpci->irq_lock only wraps the rtw_pci interrupt
enablement.
If there is any more entry that I missed and will interfere, please let me know.
Thank you
Jian-Hong Pan
[PATCH v2] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..0740140d7e46 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,28 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(&rtwpci->irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(&rtwpci->irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +907,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(&rtwpci->irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
[PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
v3:
Extend the spin lock protecting area for the TX path in
rtw_pci_interrupt_threadfn by Realtek's suggestion
v4:
Remove the WiFi running check in rtw_pci_interrupt_threadfn to avoid AP
connection failed by Realtek's suggestion.
drivers/net/wireless/realtek/rtw88/pci.c | 32 +++-
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..955dd6c6fb57 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(&rtwpci->irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(&rtwpci->irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,9 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(&rtwpci->irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1170,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1212,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月21日 週三 下午4:16寫道：
>
> Hi,
>
> > From: Jian-Hong Pan [mailto:jian-h...@endlessm.com]
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2:
> > Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> > rtw_pci_interrupt_handler. Because the interrupts are already disabled
> > in the hardware interrupt handler.
> >
> > v3:
> > Extend the spin lock protecting area for the TX path in
> > rtw_pci_interrupt_threadfn by Realtek's suggestion
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..a8c17a01f318 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> >
> > spin_lock(&rtwpci->irq_lock);
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
> > +out:
> > + spin_unlock(&rtwpci->irq_lock);
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(&rtwpci->irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> > + rtw_pci_enable_interrupt(rtwdev, rtwpci);
>
> I've applied this patch and tested it.
> But I failed to connect to AP, it seems that the
> scan_result is empty. And when I failed to connect
> to the AP, I found that the IMR is not enabled.
> I guess the check bypass the interrupt enable function.
>
> And I also found that *without MSI*, the driver is
> able to connect to the AP. Could you please verify
> this patch again with MSI interrupt enabled and
> send a v4?
>
> You can find my MSI patch on
> https://patchwork.kernel.org/patch/11081539/
I have just sent v4 patch. Also tested the modified MSI patch like below:
The WiFi works fine on ASUS X512DK (including MSI enabled).
Jian-Hong Pan
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 955dd6c6fb57..d18f5aae1585 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -11,6 +11,10 @@
#include "fw.h"
#include "debug.h"
+static bool rtw_disable_msi;
+module_param_named(disable_msi, rtw_disable_msi, bool, 0644);
+MODULE_PARM_DESC(disable_msi, "Set Y to disable MSI interrupt support");
+
static u32 rtw_pci_tx_queue_idx_addr[] = {
[RTW_TX_QUEUE_BK]= RTK_PCI_TXBD_IDX_BKQ,
[RTW_TX_QUEUE_BE]= RTK_PCI_TXBD_IDX_BEQ,
@@ -1116,6 +1120,48 @@ static struct rtw_hci_ops rtw_pci_ops = {
.write_data_h2c = rtw_pci_write_data_h2c,
};
+static int rtw_pci_request_irq(struct rtw_dev *rtwdev, struct pci_dev *pdev)
+{
+struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+int ret;
+
+if (!rtw_disable_msi) {
+ret = pci_enable_msi(pdev);
+if (ret) {
+rtw_warn(rtwdev, "failed to enable msi %d, using legacy irq\n",
+ ret);
+} else {
+rtw_warn(rtwdev, "pci msi enabled\n");
+
[PATCH] PCI/MSI: Fix restoring of MSI-X vector control's mask bit
MSI-X vector control's bit 0 is the mask bit, which masks the
corresponding interrupt request, or not. Other reserved bits might be
used for other purpose by device vendors. For example, the values of
Kingston NVMe SSD's MSI-X vector control are neither 0, nor 1, but other
values [1].
The original restoring logic in system resuming uses the whole MSI-X
vector control value as the flag to set/clear the mask bit. However,
this logic conflicts the idea mentioned above. It may mislead system to
disable the MSI-X vector entries. That makes system get no interrupt
from Kingston NVMe SSD after resume and usually get NVMe I/O timeout
error.
[ 174.715534] nvme nvme0: I/O 978 QID 3 timeout, completion polled
This patch takes only the mask bit of original MSI-X vector control
value as the flag to fix this issue.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=204887#c8
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Fixed: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Jian-Hong Pan
---
drivers/pci/msi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0884bedcfc7a..deae3d5acaf6 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -433,6 +433,7 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
static void __pci_restore_msix_state(struct pci_dev *dev)
{
struct msi_desc *entry;
+ u32 flag;
if (!dev->msix_enabled)
return;
@@ -444,8 +445,10 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
PCI_MSIX_FLAGS_ENABLE | PCI_MSIX_FLAGS_MASKALL);
arch_restore_msi_irqs(dev);
- for_each_pci_msi_entry(entry, dev)
- msix_mask_irq(entry, entry->masked);
+ for_each_pci_msi_entry(entry, dev) {
+ flag = entry->masked & PCI_MSIX_ENTRY_CTRL_MASKBIT;
+ msix_mask_irq(entry, flag);
+ }
pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
}
--
2.23.0
[PATCH] nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T
Kingston NVME SSD with firmware version E8FK11.T has no interrupt after
resume with actions related to suspend to idle. This patch applied
NVME_QUIRK_SIMPLE_SUSPEND quirk to fix this issue.
Fixes: d916b1be94b6 ("nvme-pci: use host managed power state for suspend")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Signed-off-by: Jian-Hong Pan
---
drivers/nvme/host/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 1ede1763a5ee..84fe3c4059a2 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2298,6 +2298,16 @@ static const struct nvme_core_quirk_entry core_quirks[]
= {
.vid = 0x14a4,
.fr = "2230",
.quirks = NVME_QUIRK_SIMPLE_SUSPEND,
+ },
+ {
+ /*
+* This Kingston E8FK11.T firmware version has no interrupt
+* after resume with actions related to suspend to idle
+* https://bugzilla.kernel.org/show_bug.cgi?id=204887
+*/
+ .vid = 0x2646,
+ .fr = "E8FK11.T",
+ .quirks = NVME_QUIRK_SIMPLE_SUSPEND,
}
};
--
2.20.1
Re: [PATCH v2] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月16日 週五 下午6:44寫道：
>
> > From: Jian-Hong Pan
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2:
> > Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> > rtw_pci_interrupt_handler. Because the interrupts are already disabled
> > in the hardware interrupt handler.
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..0740140d7e46 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,28 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> >
> > spin_lock(&rtwpci->irq_lock);
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
> So basically it's to prevent back-to-back interrupts.
>
> Nothing wrong about it, I just wondering why we don't like
> back-to-back interrupts. Does it means that those interrupts
> fired between irq_handler and threadfin would increase
> much more time to consume them.
1. It is one of the reasons. Besides, the hardware interrupt has
higher priority than soft IRQ. If next hardware interrupt is coming
faster then the soft IRQ (BH), the software IRQ may always become
pended.
2. Keep the data's state until the interrupt is fully dealt.
3. The process of request_threaded_irq is documented:
https://www.kernel.org/doc/htmldocs/kernel-api/API-request-threaded-irq.html
> > +out:
> > + spin_unlock(&rtwpci->irq_lock);
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +907,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(&rtwpci->irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
>
> I suggest to protect the ISRs. Because next patches will require
> to check if the TX DMA path is empty. This means I will also add
> this rtwpci->irq_lock to the TX path, and check if the skb_queue
> does not have any pending SKBs not DMAed successfully.
Ah ... Okay for the TX path
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
>
> Why check the flag here? Is there any racing or something?
> Otherwise it looks to break the symmetry.
According to backtrace, I notice rtw_pci_stop will be invoked in
rtw_power_off, rtw_core_stop which clears the running state.
rtw_core_stop is invoked by rtw_enter_ips due to IEEE80211_CONF_IDLE.
If the stop command comes between the hardware interrupt and soft IRQ
(BH) and there is no start command again, I think user wants the WiFi
stop instead of becoming start again.
Jian-Hong Pan
[PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
v3:
Extend the spin lock protecting area for the TX path in
rtw_pci_interrupt_threadfn by Realtek's suggestion
drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..a8c17a01f318 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(&rtwpci->irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(&rtwpci->irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(&rtwpci->irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > Hi, > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > Hi Maxime, > > > > Thanks for your V2 patch series! I'm testing it. > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built. > > System can boot into console text mode, but no graphic UI. > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' > > already present! > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi > > mapping ok > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already > > present! > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi > > mapping ok > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops) > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops) > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops) > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops) > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops) > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 ) > > [5.589297] fb0: switching to vc4drmfb from simple > > [5.589433] Console: switching to colour dummy device 80x25 > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > [5.601079] [ cut here ] > > [5.601095] WARNING: CPU: 2 PID: 127 at > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601097] Modules linked in: > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > 5.7.0-rc2-00091-ga181df59a930 #7 > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > [5.601112] Workqueue: events deferred_probe_work_func > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > [5.601124] sp : 80001217b410 > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > [5.601129] x27: f650d400 x26: 8a50 > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > [5.601135] x23: 0a50 x22: 0300 > > [5.601137] x21: 08d9ee20 x20: ec535080 > > [5.601140] x19: 00010989e7c0 x18: > > [5.601142] x17: 0001 x16: 5207 > > [5.601145] x15: 4932ad293c92 x14: 0137 > > [5.601147] x13: 800010015000 x12: 0001 > > [5.601150] x11: 0001 x10: > > [5.601152] x9 : x8 : 800010015038 > > [5.601154] x7 : 0001 x6 : 80001217b368 > > [5.601157] x5 : x4 : 004c > > [5.601159] x3 : x2 : 8000113b4ac0 > > [5.601162] x1 : 8000120c5f44 x0 : dc8984ff > > [5.601164] Call trace: > > [5.601169] vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601172] vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > [5.601176] drm_atomic_helper_commit_modeset_enables+0x224/0x248 > > [5.601179] vc4_atomic_complete_commit+0x400/0x558 > > [5.601182] vc4_atomic_commit+0x1e0/0x200 > > [5.601185] drm_atomic_commit+0x4c/0x60 > > [5.601190] drm_client_modeset_commit_atomic.isra.0+0x17c/0x238 > > [5.601192] drm_client_modeset_commit_locked+0x5c/0x198 > > [5.601195] drm_client_modeset_commit+0x30/0x58 > > [5.601201] drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0 > > [5.601204] drm_fb_helper_set_par+0x30/0x68 > > [5.601208] fbcon_init+0x3d
[PATCH] drm/radeon: drm/amdgpu: Disable [1002:6611] in radeon
The AMD/ATI Oland [1002:6611]'s HDMI output status is not synchronous
as shown on UI after hot re-plug the HDMI cable, if it is radeon in
used. The amdgpu module does not hit this issue.
This patch disables [1002:6611] in radeon and enables it in amdgpu.
Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/1117
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
include/drm/drm_pciids.h| 1 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8ea86ffdea0d..1ad6f13a5bc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1017,6 +1017,15 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static struct drm_driver kms_driver;
+static void amdgpu_pci_fixup(struct pci_dev *pdev)
+{
+#ifdef CONFIG_DRM_AMDGPU_SI
+ /* [1002:6611] is disabled in radeon, so enable si_support in amdgpu. */
+ if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x6611)
+ amdgpu_si_support = 1;
+#endif
+}
+
static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1036,6 +1045,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+ amdgpu_pci_fixup(pdev);
+
#ifdef CONFIG_DRM_AMDGPU_SI
if (!amdgpu_si_support) {
switch (flags & AMD_ASIC_MASK) {
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index b7e899ce44f0..57368a0f5b82 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -171,7 +171,6 @@
{0x1002, 0x6607, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6608, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6610, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
- {0x1002, 0x6611, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6613, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6617, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6620, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
--
2.26.2
[PATCH] ALSA: hda/realtek: Enable audio jacks of ASUS UX362FA with ALC294
The ASUS UX362FA with ALC294 cannot detect the headset MIC and outputs
through the internal speaker and the headphone. This issue can be fixed
by the quirk in the commit 4e0511067 ALSA: hda/realtek: Enable audio
jacks of ASUS UX533FD with ALC294.
Besides, ASUS UX362FA and UX533FD have the same audio initial pin config
values. So, this patch replaces SND_PCI_QUIRK of UX533FD with a new
SND_HDA_PIN_QUIRK which benefits both UX362FA and UX533FD.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Ming Shuo Chiu
---
sound/pci/hda/patch_realtek.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1ffa36e987b4..6421864a8a0f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6771,7 +6771,6 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
- SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", ALC294_FIXUP_ASUS_SPK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
@@ -7388,6 +7387,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x03211020}),
SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK,
{0x12, 0x90a60130},
{0x17, 0x90170110},
--
2.20.1
[RFC PATCH 0/5] net: lorawan: Refine the lorawan protocol module
Jian-Hong Pan (5): net: lorawan: Refine the coding style net: lorawan: Remove unused lrw_dev_hard_header function net; lorawan: Fix net device leakage net: lorawan: Fulfill the help text of Kconfig net: lorawan: Split skb definitions into another header include/linux/lora/lorawan_netdev.h | 25 +-- include/linux/lora/lorawan_skb.h| 33 ++ net/lorawan/Kconfig | 3 +- net/lorawan/socket.c| 68 +++-- 4 files changed, 62 insertions(+), 67 deletions(-) create mode 100644 include/linux/lora/lorawan_skb.h -- 2.20.1
[RFC PATCH 1/5] net: lorawan: Refine the coding style
Signed-off-by: Jian-Hong Pan
---
include/linux/lora/lorawan_netdev.h | 5 ++--
net/lorawan/socket.c| 43 ++---
2 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
index 5bffb5164f95..a6c94cb96bf4 100644
--- a/include/linux/lora/lorawan_netdev.h
+++ b/include/linux/lora/lorawan_netdev.h
@@ -1,9 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
-/*-
+/*
* LoRaWAN stack related definitions
*
- * Copyright (c) 2018 Jian-Hong, Pan
- *
+ * Copyright (c) 2018 Jian-Hong Pan
*/
#ifndef __LORAWAN_NET_DEVICE_H__
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 7ef106b877ca..0ec2d2bf1682 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -1,36 +1,33 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
-/*-
+/*
* LoRaWAN stack related definitions
*
- * Copyright (c) 2018 Jian-Hong, Pan
- *
+ * Copyright (c) 2018 Jian-Hong Pan
*/
#defineLORAWAN_MODULE_NAME "lorawan"
#definepr_fmt(fmt) LORAWAN_MODULE_NAME ": " fmt
+#include
#include
-#include
#include
+#include
+#include
#include
-#include
#include /* For TIOCOUTQ/INQ */
#include
-#include
/**
* dgram_sock - This structure holds the states of Datagram socket
*
* @sk:network layer representation of the socket
- * sk must be the first member of dgram_sock
* @src_devaddr: the LoRaWAN device address for this connection
* @bound: this socket is bound or not
* @connected: this socket is connected to the destination or not
- * @want_ack: this socket needs to ack for the connection or not
*/
struct dgram_sock {
- struct sock sk;
+ struct sock sk; /* sk must be the first member of dgram_sock */
u32 src_devaddr;
u8 bound:1;
@@ -136,7 +133,7 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
size_t tlen;
int ret;
- pr_debug("%s: going to send %zu bytes", __func__, size);
+ pr_debug("%s: going to send %zu bytes\n", __func__, size);
if (msg->msg_flags & MSG_OOB) {
pr_debug("msg->msg_flags = 0x%x\n", msg->msg_flags);
return -EOPNOTSUPP;
@@ -532,7 +529,7 @@ static const struct proto_ops lrw_dgram_ops = {
};
static int
-lorawan_creat(struct net *net, struct socket *sock, int protocol, int kern)
+lrw_create(struct net *net, struct socket *sock, int protocol, int kern)
{
struct sock *sk;
int ret;
@@ -557,7 +554,7 @@ lorawan_creat(struct net *net, struct socket *sock, int
protocol, int kern)
ret = sk->sk_prot->hash(sk);
if (ret) {
sk_common_release(sk);
- goto lorawan_creat_end;
+ goto lrw_create_end;
}
}
@@ -567,14 +564,14 @@ lorawan_creat(struct net *net, struct socket *sock, int
protocol, int kern)
sk_common_release(sk);
}
-lorawan_creat_end:
+lrw_create_end:
return ret;
}
static const struct net_proto_family lorawan_family_ops = {
.owner = THIS_MODULE,
.family = PF_LORAWAN,
- .create = lorawan_creat,
+ .create = lrw_create,
};
static int
@@ -617,29 +614,29 @@ lrw_dgram_deliver(struct net_device *ndev, struct sk_buff
*skb)
}
static int
-lorawan_rcv(struct sk_buff *skb, struct net_device *ndev,
+lrw_rcv(struct sk_buff *skb, struct net_device *ndev,
struct packet_type *pt, struct net_device *orig_ndev)
{
if (!netif_running(ndev))
- goto lorawan_rcv_drop;
+ goto lrw_rcv_drop;
if (!net_eq(dev_net(ndev), &init_net))
- goto lorawan_rcv_drop;
+ goto lrw_rcv_drop;
if (ndev->type != ARPHRD_LORAWAN)
- goto lorawan_rcv_drop;
+ goto lrw_rcv_drop;
if (skb->pkt_type != PACKET_OTHERHOST)
return lrw_dgram_deliver(ndev, skb);
-lorawan_rcv_drop:
+lrw_rcv_drop:
kfree_skb(skb);
return NET_RX_DROP;
}
static struct packet_type lorawan_packet_type = {
.type = htons(ETH_P_LORAWAN),
- .func = lorawan_rcv,
+ .func = lrw_rcv,
};
static int __init
@@ -665,7 +662,7 @@ lrw_sock_init(void)
proto_unregister(&lrw_dgram_prot);
lrw_sock_init_end:
- return 0;
+ return ret;
}
static void __exit
@@ -680,7 +677,7 @@ lrw_sock_exit(void)
module_init(lrw_sock_init);
module_exit(lrw_sock_exit);
-MODULE_AUTHOR("Jian-Hong Pan, ");
-MODULE_DESCRIPTION("LoRaWAN socket kernel module");
+MODULE_AUTHOR("Jian-Hong Pan ");
+
[RFC PATCH 2/5] net: lorawan: Remove unused lrw_dev_hard_header function
The lorawan module is an abastraction layer over the LoRaWAN soft and
hard MAC. It passes the original buffer to the real MAC layer. So,
this patch removes the lrw_dev_hard_header function.
Signed-off-by: Jian-Hong Pan
---
net/lorawan/socket.c | 12
1 file changed, 12 deletions(-)
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 0ec2d2bf1682..9c0722379e25 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -115,14 +115,6 @@ dgram_bind(struct sock *sk, struct sockaddr *uaddr, int
len)
return ret;
}
-static int
-lrw_dev_hard_header(struct sk_buff *skb, struct net_device *ndev,
- const u32 src_devaddr, size_t len)
-{
- /* TODO: Prepare the LoRaWAN sending header here */
- return 0;
-}
-
static int
dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
{
@@ -176,10 +168,6 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
- ret = lrw_dev_hard_header(skb, ndev, 0, size);
- if (ret < 0)
- goto dgram_sendmsg_no_skb;
-
ret = memcpy_from_msg(skb_put(skb, size), msg, size);
if (ret > 0)
goto dgram_sendmsg_err_skb;
--
2.20.1
[RFC PATCH 3/5] net; lorawan: Fix net device leakage
The net device may be missed to be put after error check. This patch
fixes the issue to prevent the leakage.
Signed-off-by: Jian-Hong Pan
---
net/lorawan/socket.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 9c0722379e25..7139fab63159 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -51,8 +51,10 @@ lrw_get_dev_by_addr(struct net *net, u32 devaddr)
rcu_read_lock();
ndev = dev_getbyhwaddr_rcu(net, ARPHRD_LORAWAN, (char *)&be_addr);
- if (ndev)
+ if (ndev && ndev->type == ARPHRD_LORAWAN)
dev_hold(ndev);
+ else
+ ndev = NULL;
rcu_read_unlock();
return ndev;
@@ -99,11 +101,6 @@ dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
}
netdev_dbg(ndev, "%s: get ndev\n", __func__);
- if (ndev->type != ARPHRD_LORAWAN) {
- ret = -ENODEV;
- goto dgram_bind_end;
- }
-
ro->src_devaddr = addr->addr_in.devaddr;
ro->bound = 1;
ret = 0;
@@ -152,7 +149,7 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
if (size > ndev->mtu) {
netdev_dbg(ndev, "size = %zu, mtu = %u\n", size, ndev->mtu);
ret = -EMSGSIZE;
- goto dgram_sendmsg_end;
+ goto dgram_sendmsg_no_skb;
}
netdev_dbg(ndev, "%s: create skb\n", __func__);
@@ -189,7 +186,6 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
kfree_skb(skb);
dgram_sendmsg_no_skb:
dev_put(ndev);
-
dgram_sendmsg_end:
return ret;
}
--
2.20.1
[RFC PATCH 5/5] net: lorawan: Split skb definitions into another header
Split LoRaWAN related skb definitions from lora/lorawan_netdev.h into
another header lora/lorawan_skb.h.
Signed-off-by: Jian-Hong Pan
---
include/linux/lora/lorawan_netdev.h | 20 -
include/linux/lora/lorawan_skb.h| 33 +
net/lorawan/socket.c| 1 +
3 files changed, 34 insertions(+), 20 deletions(-)
create mode 100644 include/linux/lora/lorawan_skb.h
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
index a6c94cb96bf4..e515ba1ab508 100644
--- a/include/linux/lora/lorawan_netdev.h
+++ b/include/linux/lora/lorawan_netdev.h
@@ -28,24 +28,4 @@ struct sockaddr_lorawan {
struct lrw_addr_in addr_in;
};
-/**
- * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
- *
- * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
- */
-struct lrw_mac_cb {
- u32 devaddr;
-};
-
-/**
- * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
- * @skb: the exchanging sk_buff
- *
- * Return: the pointer of LoRaWAN MAC control buffer
- */
-static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
-{
- return (struct lrw_mac_cb *)skb->cb;
-}
-
#endif
diff --git a/include/linux/lora/lorawan_skb.h b/include/linux/lora/lorawan_skb.h
new file mode 100644
index ..ea4f900b37be
--- /dev/null
+++ b/include/linux/lora/lorawan_skb.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*
+ * LoRaWAN socket buffer related definitions
+ *
+ * Copyright (c) 2018 Jian-Hong Pan
+ */
+
+#ifndef __LORAWAN_SKB_H__
+#define __LORAWAN_SKB_H__
+
+#include
+
+/**
+ * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
+ *
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ */
+struct lrw_mac_cb {
+ u32 devaddr;
+};
+
+/**
+ * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
+ * @skb: the exchanging sk_buff
+ *
+ * Return: the pointer of LoRaWAN MAC control buffer
+ */
+static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
+{
+ return (struct lrw_mac_cb *)skb->cb;
+}
+
+#endif
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 7139fab63159..50559ba0c538 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include /* For TIOCOUTQ/INQ */
--
2.20.1
[RFC PATCH 4/5] net: lorawan: Fulfill the help text of Kconfig
Mention the LoRaWAN network feature to distinguish it from other Low-Power Wide-Area Network like Sigfox and NB-IoT. Signed-off-by: Jian-Hong Pan --- net/lorawan/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig index bf6c9b77573b..ce3ed6e6d11c 100644 --- a/net/lorawan/Kconfig +++ b/net/lorawan/Kconfig @@ -4,7 +4,8 @@ config LORAWAN LoRaWAN defines low data rate, low power and long range wireless wide area networks. It was designed to organize networks of automation devices, such as sensors, switches and actuators. It can operate - multiple kilometers wide. + multiple kilometers wide. The network is client/server technology + centered around gateways. Say Y here to compile LoRaWAN support into the kernel or say M to compile it as a module. -- 2.20.1
[RFC PATCH 5/5] net: lorawan: Split skb definitions into another header
Split LoRaWAN related skb definitions from lora/lorawan_netdev.h into
another header lora/lorawan_skb.h.
Signed-off-by: Jian-Hong Pan
---
include/linux/lora/lorawan_netdev.h | 20 -
include/linux/lora/lorawan_skb.h| 33 +
net/lorawan/socket.c| 1 +
3 files changed, 34 insertions(+), 20 deletions(-)
create mode 100644 include/linux/lora/lorawan_skb.h
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
index a6c94cb96bf4..e515ba1ab508 100644
--- a/include/linux/lora/lorawan_netdev.h
+++ b/include/linux/lora/lorawan_netdev.h
@@ -28,24 +28,4 @@ struct sockaddr_lorawan {
struct lrw_addr_in addr_in;
};
-/**
- * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
- *
- * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
- */
-struct lrw_mac_cb {
- u32 devaddr;
-};
-
-/**
- * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
- * @skb: the exchanging sk_buff
- *
- * Return: the pointer of LoRaWAN MAC control buffer
- */
-static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
-{
- return (struct lrw_mac_cb *)skb->cb;
-}
-
#endif
diff --git a/include/linux/lora/lorawan_skb.h b/include/linux/lora/lorawan_skb.h
new file mode 100644
index ..ea4f900b37be
--- /dev/null
+++ b/include/linux/lora/lorawan_skb.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*
+ * LoRaWAN socket buffer related definitions
+ *
+ * Copyright (c) 2018 Jian-Hong Pan
+ */
+
+#ifndef __LORAWAN_SKB_H__
+#define __LORAWAN_SKB_H__
+
+#include
+
+/**
+ * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
+ *
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ */
+struct lrw_mac_cb {
+ u32 devaddr;
+};
+
+/**
+ * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
+ * @skb: the exchanging sk_buff
+ *
+ * Return: the pointer of LoRaWAN MAC control buffer
+ */
+static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
+{
+ return (struct lrw_mac_cb *)skb->cb;
+}
+
+#endif
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 7139fab63159..50559ba0c538 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include /* For TIOCOUTQ/INQ */
--
2.20.1
Re: [RFC PATCH 1/5] net: lorawan: Refine the coding style
Andreas Färber 於 2019年1月16日 週三 下午11:07寫道： > > Am 16.01.19 um 15:33 schrieb Jiri Pirko: > > Wed, Jan 16, 2019 at 03:24:54PM CET, starni...@g.ncu.edu.tw wrote: > >> Signed-off-by: Jian-Hong Pan > >> --- > > > > Patches like this are in general frowned upon. Do one change in one > > patch. Put some patch description. > > This patch simply shouldn't have gone to netdev and LKML, as it is a > fixup against a non-stable tree (missing "lora-next"). Once squashed, it > doesn't matter whether it once had a verbose explanation or not. And I > prefer to not mix style and functional changes. Uh! I see. Regards, Jian-Hong Pan > I simply was too impatient to wait for more respins before being able to > base work on it. ;)
Re: [RFC PATCH 5/5] net: lorawan: Split skb definitions into another header
Andreas Färber 於 2019年1月16日 週三 下午10:50寫道： > > Am 16.01.19 um 15:36 schrieb Jiri Pirko: > > Wed, Jan 16, 2019 at 03:25:02PM CET, starni...@g.ncu.edu.tw wrote: > >> Split LoRaWAN related skb definitions from lora/lorawan_netdev.h into > >> another header lora/lorawan_skb.h. > > > > What is the motivation for this change? > > I suggested it because skbs could be used with either LoRa or LoRaWAN > netdevs. I have a lora/skb.h. > > In general the lorawan_foo.h looks ugly to me, so I thought I suggested > to avoid that by using [lora/]lorawan/skb.h? Seems we have some choices: 1. Split the lorawan skb stuff from lora/lorawan_netdev.h and merge into include/linux/lora/skb.h 2. Split the lorawan skb stuff from lora/lorawan_netdev.h to include/linux/lora/lorawan_skb.h 3. Split the lorawan skb stuff from lora/lorawan_netdev.h to include/linux/lora/lorawan/skb.h 4. Split the lorawan skb stuff from lora/lorawan_netdev.h to include/linux/lorawan/skb.h #1, #2 and #3 are good to me. So, the intersection is choice #3. Regards, Jian-Hong Pan
Re: [PATCH v5 1/6] net: lorawan: Add LoRaWAN socket module
Jian-Hong Pan 於 2019年1月7日 週一 下午10:47寫道：
>
> Andreas Färber 於 2018年12月29日 週六 下午3:27寫道：
> >
> > Hi Jian-Hong,
> >
> > Am 16.12.18 um 11:18 schrieb Jian-Hong Pan:
> > > This patch adds a new address/protocol family for LoRaWAN network.
> > > It also implements the the functions and maps to Datagram socket for
> > > LoRaWAN unconfirmed data messages.
> > >
> > > Signed-off-by: Jian-Hong Pan
> > [...]
> > > include/linux/lora/lorawan_netdev.h | 52 +++
> > > net/lorawan/Kconfig | 10 +
> > > net/lorawan/Makefile| 2 +
> > > net/lorawan/socket.c| 686
> > > 4 files changed, 750 insertions(+)
> > > create mode 100644 include/linux/lora/lorawan_netdev.h
> > > create mode 100644 net/lorawan/Kconfig
> > > create mode 100644 net/lorawan/Makefile
> > > create mode 100644 net/lorawan/socket.c
> >
> > I'm not 100% happy with this yet, but to decouple it from the soft-MAC
> > discussion (patches 2-6/6) and to allow reuse by Ben, I've staged it in
> > linux-lora.git.
> >
> > We can clean it up with incremental patches there (and squash later).
> >
> > >
> > > diff --git a/include/linux/lora/lorawan_netdev.h
> > > b/include/linux/lora/lorawan_netdev.h
> > > new file mode 100644
> > > index ..5bffb5164f95
> > > --- /dev/null
> > > +++ b/include/linux/lora/lorawan_netdev.h
> > > @@ -0,0 +1,52 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
> >
> > Is there any practical reason you dual-license your code? My LoRa code
> > is only GPL - should I reconsider that?
>
> I use dual-license due to the event "[Ksummit-discuss] [CORE TOPIC]
> GPL defense issues"
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html
>
> > > +/*-
> >
> > I assume the dash is a typo?
> >
> > > + * LoRaWAN stack related definitions
> > > + *
> > > + * Copyright (c) 2018 Jian-Hong, Pan
> > > + *
> >
> > Leftover white line from old license header?
> >
> > > + */
> > > +
> > > +#ifndef __LORAWAN_NET_DEVICE_H__
> > > +#define __LORAWAN_NET_DEVICE_H__
> > > +
> > > +enum {
> > > + LRW_ADDR_APPEUI,
> > > + LRW_ADDR_DEVEUI,
> > > + LRW_ADDR_DEVADDR,
> > > +};
> > > +
> > > +struct lrw_addr_in {
> > > + int addr_type;
> > > + union {
> > > + u64 app_eui;
> > > + u64 dev_eui;
> >
> > In my RFC and in linux-lora.git I have a lora_eui typedef - any reason
> > you're not using it here?
>
> lora_eui is defined as a type of u8 array with 8 bytes in
> include/linux/lora/dev.h
> typedef u8 lora_eui[8];
> It is not a basic nor simple data type.
>
> 1. There is the endian issue. LoRaWAN uses little endian for
> transmission. If u64 data type is used, we can call functions like
> cpu_to_le64 and le64_to_cpu to deal the endian jobs directly.
> 2. We can compare the EUIs with relational operators directly if the
> EUI is not a type of array.
>
> > > + u32 devaddr;
> > > + };
> > > +};
> > > +
> > > +struct sockaddr_lorawan {
> > > + sa_family_t family; /* AF_LORAWAN */
> > > + struct lrw_addr_in addr_in;
> > > +};
> > > +
> > > +/**
> > > + * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
> > > + *
> > > + * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
> > > + */
> > > +struct lrw_mac_cb {
> > > + u32 devaddr;
> > > +};
> > > +
> > > +/**
> > > + * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
> > > + * @skb: the exchanging sk_buff
> > > + *
> > > + * Return: the pointer of LoRaWAN MAC control buffer
> > > + */
> > > +static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
> > > +{
> > > + return (struct lrw_mac_cb *)skb->cb;
> > > +}
> >
> > For LoRa I have a separate lora/skb.h - suggest to split this off into
> > its own header consistently.
>
> Sounds good.
> Do you prefer separate them into lora/skb.h or lora/lorawan_skb.h?
>
> > > +
> > > +#endif
> > > diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig
> > > new file mode 10
Re: [PATCH] x86/reboot: Use efi reboot for Acer TravelMate X514-51T
Thomas Gleixner 於 2019年4月6日 週六 上午5:14寫道：
>
> On Mon, 1 Apr 2019, Jian-Hong Pan wrote:
> > +/*
> > + * Some machines require the "reboot=e" commandline options
> > + */
> > +static int __init set_efi_reboot(const struct dmi_system_id *d)
> > +{
> > + if (reboot_type != BOOT_EFI) {
> > + reboot_type = BOOT_EFI;
>
> So if EFI is disabled in the kernel this will fall through to BOOT_BIOS. Is
> that intended behaviour?
If not choose EFI as the reboot type, system will use APCI reboot type
on Acer TravelMate X514-51T.
If the reboot type is set as BIOS by appending "reboot=b", system
cannot reboot and hangs up when shutdown.
> > + pr_info("%s series board detected. Selecting %s-method for
> > reboot.\n",
> > + d->ident, "EFI");
>
> Is thee a reason not to write "EFI" in the string itself?
Just simply follow the format like functions: set_acpi_reboot, set_bios_reboot
https://elixir.bootlin.com/linux/v5.1-rc4/source/arch/x86/kernel/reboot.c#L60
BR,
Jian-Hong Pan
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate B114-21 with ALC233
The Acer TravelMate B114-21 laptop cannot detect and record sound from
headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC HDA verb
quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin quirk to fix
this issue.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a3fb3d4c5730..bdb2227be4eb 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5690,6 +5690,7 @@ enum {
ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC299_FIXUP_PREDATOR_SPK,
+ ALC233_FIXUP_ACER_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6713,6 +6714,15 @@ static const struct hda_fixup alc269_fixups[] = {
{ 0x21, 0x90170150 }, /* use as headset mic, without
its own jack detect */
{ }
}
+ [ALC233_FIXUP_ACER_HEADSET_MIC] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC233_FIXUP_ASUS_MIC_NO_PRESENCE
},
};
@@ -6737,6 +6747,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
[PATCH] x86/reboot: Use efi reboot for Acer TravelMate X514-51T
Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.
The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.
However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
arch/x86/kernel/reboot.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c0..145bdfb56a9a 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id
*d)
return 0;
}
+/*
+ * Some machines require the "reboot=e" commandline options
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+ if (reboot_type != BOOT_EFI) {
+ reboot_type = BOOT_EFI;
+ pr_info("%s series board detected. Selecting %s-method for
reboot.\n",
+ d->ident, "EFI");
+ }
+ return 0;
+}
+
void __noreturn machine_real_restart(unsigned int type)
{
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+ { /* Handle reboot issue on Acer TravelMate X514-51T */
+ .callback = set_efi_reboot,
+ .ident = "Acer TravelMate X514-51T",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+ },
+ },
/* Apple */
{ /* Handle problems with rebooting on Apple MacBook5 */
--
2.20.1
[PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
Each skb as the element in RX ring was expected with sized buffer 8216
(RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
16640 bytes for alignment after allocated, x86_64 for example. And, the
difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
To prevent that much wasted memory, this patch follows David's
suggestion [1] and uses general buffer arrays, instead of skbs as the
elements in RX ring.
[1] https://www.spinics.net/lists/linux-wireless/msg187870.html
Signed-off-by: Jian-Hong Pan
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 132 +--
drivers/net/wireless/realtek/rtw88/pci.h | 2 +-
2 files changed, 75 insertions(+), 59 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06afef3d..e953010f0179 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -111,25 +111,49 @@ static void rtw_pci_free_tx_ring(struct rtw_dev *rtwdev,
tx_ring->r.head = NULL;
}
+static struct rtw_pci_rx_buffer_desc *rtw_pci_get_rx_desc(
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx)
+{
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ u32 desc_sz = rx_ring->r.desc_size;
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+idx * desc_sz);
+ return buf_desc;
+}
+
+static dma_addr_t rtw_pci_get_rx_bufdma(struct rtw_pci_rx_ring *rx_ring,
+ u32 idx)
+{
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ dma_addr_t dma;
+
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
+ dma = le32_to_cpu(buf_desc->dma);
+
+ return dma;
+}
+
static void rtw_pci_free_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
- struct sk_buff *skb;
+ u8 *buf;
dma_addr_t dma;
u8 *head = rx_ring->r.head;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
int ring_sz = rx_ring->r.desc_size * rx_ring->r.len;
- int i;
+ u32 i;
for (i = 0; i < rx_ring->r.len; i++) {
- skb = rx_ring->buf[i];
- if (!skb)
+ buf = rx_ring->buf[i];
+ if (!buf)
continue;
- dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(pdev, dma, buf_sz, PCI_DMA_FROMDEVICE);
- dev_kfree_skb(skb);
+ dma = rtw_pci_get_rx_bufdma(rx_ring, i);
+ pci_unmap_single(pdev, dma, buf_sz, DMA_FROM_DEVICE);
+ devm_kfree(rtwdev->dev, buf);
rx_ring->buf[i] = NULL;
}
@@ -180,27 +204,24 @@ static int rtw_pci_init_tx_ring(struct rtw_dev *rtwdev,
return 0;
}
-static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
-struct rtw_pci_rx_ring *rx_ring,
-u32 idx, u32 desc_sz)
+static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, u8 *buf,
+struct rtw_pci_rx_ring *rx_ring, u32 idx)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
struct rtw_pci_rx_buffer_desc *buf_desc;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
dma_addr_t dma;
- if (!skb)
+ if (!buf)
return -EINVAL;
- dma = pci_map_single(pdev, skb->data, buf_sz, PCI_DMA_FROMDEVICE);
+ dma = pci_map_single(pdev, buf, buf_sz, DMA_FROM_DEVICE);
if (pci_dma_mapping_error(pdev, dma))
return -EBUSY;
- *((dma_addr_t *)skb->cb) = dma;
- buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
-idx * desc_sz);
- memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->total_pkt_size = cpu_to_le16(0);
buf_desc->dma = cpu_to_le32(dma);
return 0;
@@ -208,7 +229,7 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev,
struct sk_buff *skb,
static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
struct rtw_pci_rx_ring *rx_ring,
- u32 idx, u32 desc_sz)
+ u32 idx)
{
struct device *dev = rtwdev->dev;
struct rtw_pci_rx_buffer_desc *buf_desc;
@@ -216,10 +237,9 @@ static void rtw_pci_sync_rx_desc_device(struct rtw_dev
*rtwdev, dma_addr_t dma,
dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
- buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ri
Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
David Laight 於 2019年7月25日 週四 下午5:21寫道：
>
> From: Jian-Hong Pan
> > Sent: 25 July 2019 09:09
> > Each skb as the element in RX ring was expected with sized buffer 8216
> > (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
> > 16640 bytes for alignment after allocated, x86_64 for example. And, the
> > difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
> > To prevent that much wasted memory, this patch follows David's
> > suggestion [1] and uses general buffer arrays, instead of skbs as the
> > elements in RX ring.
> ...
> > for (i = 0; i < len; i++) {
> > - skb = dev_alloc_skb(buf_sz);
> > - if (!skb) {
> > + buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC);
>
> You should do this allocation somewhere than can sleep.
> So you don't need GFP_ATOMIC, making the allocate (and dma map)
> much less likely to fail.
> If they do fail using a smaller ring might be better than failing
> completely.
Ok, I can tweak and try it.
> I suspect that buf_sz gets rounded up somewhat.
> Also you almost certainly want 'buf' to be cache-line aligned.
> I don't think devm_kzalloc() guarantees that at all.
Sure
> While allocating all 512 buffers in one block (just over 4MB)
> is probably not a good idea, you may need to allocated (and dma map)
> then in groups.
Thanks for reviewing. But got questions here to double confirm the idea.
According to original code, it allocates 512 skbs for RX ring and dma
mapping one by one. So, the new code allocates memory buffer 512
times to get 512 buffer arrays. Will the 512 buffers arrays be in one
block? Do you mean aggregate the buffers as a scatterlist and use
dma_map_sg?
Thank you,
Jain-Hong Pan
Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
David Laight 於 2019年7月26日 週五 下午5:23寫道： > > From: Jian-Hong Pan > > Sent: 26 July 2019 07:18 > ... > > > While allocating all 512 buffers in one block (just over 4MB) > > > is probably not a good idea, you may need to allocated (and dma map) > > > then in groups. > > > > Thanks for reviewing. But got questions here to double confirm the idea. > > According to original code, it allocates 512 skbs for RX ring and dma > > mapping one by one. So, the new code allocates memory buffer 512 > > times to get 512 buffer arrays. Will the 512 buffers arrays be in one > > block? Do you mean aggregate the buffers as a scatterlist and use > > dma_map_sg? > > If you malloc a buffer of size (8192+32) the allocator will either > round it up to a whole number of (often 4k) pages or to a power of > 2 of pages - so either 12k of 16k. > I think the Linux allocator does the latter. > Some of the allocators also 'steal' a bit from the front of the buffer > for 'red tape'. > > OTOH malloc the space 15 buffers and the allocator will round the > 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the > buffers. > > You then dma_map the large buffer and split into the actual rx buffers. > Repeat until you've filled the entire ring. > The only complication is remembering the base address (and size) for > the dma_unmap and free. > Although there is plenty of padding to extend the buffer structure > significantly without using more memory. > Allocate in 15's and you (probably) have 512 bytes per buffer. > Allocate in 31's and you have 256 bytes. > > The problem is that larger allocates are more likely to fail > (especially if the system has been running for some time). > So you almost certainly want to be able to fall back to smaller > allocates even though they use more memory. > > I also wonder if you actually need 512 8k rx buffers to cover > interrupt latency? > I've not done any measurements for 20 years! Thanks for the explanation. I am not sure the combination of 512 8k RX buffers. Maybe Realtek folks can give us some idea. Tony Chuang any comment? Jian-Hong Pan
